From pucc.princeton.edu!COCO Sat Mar 16 01:14:38 1991 Date: Thu, 14 Mar 91 17:15:19 EST Reply-To: microsoft!w-brianw%UUNET.UU.NET Sender: COCO - Tandy Color Computer List From: microsoft!w-brianw%UUNET.UU.NET Subject: Clusters To: Multiple recipients of list COCO Well, I did some poking around into "clusters", what they mean, and how to use them, so I decided to post it here for you and anyone else who is interested. First, a sector is always a sector, and an LSN (Logical Sector Number) is always an LSN. These two terms should never be confused with the word "cluster". The RBF manager that comes with OS-9 can access up to 2^24 or 16,777,216 unique 256-byte sectors for a grand total of 2^32 or 4,294,967,296 bytes (4 GigaBytes)... before needing to undergo partitioning :-) Therefore, LSN-0 is always 256 bytes, a file-descriptor is always 256 bytes, etc., etc. Anywhere these terms are used in the OS-9 manuals, they are used correctly. A "cluster" is a lot like the minimum sector allocation size except that it is the same for all types of files and it can't be changed on the fly. If the cluster size is set to 32, every file will allocate a multiple of 32 sectors (the first segment is actually 31 sectors plus 1 file-descriptor sector) and remain there until it needs another cluster. As far as how cluster size and sector allocation size (SAS) work together, he initial file size is always 1 cluster. On disks with 1-sector clusters, this is used exclusively by the file-descriptor. After that, as soon as data is written past the end of a segment, more space is allocated to the file in chunks of SAS rounded up to the next cluster size. (eg. if cluster size=$08 and SAS=$23, additional space is allocated in chunks of $28 sectors). When the file is closed, it is shrunk to the least used number of clusters. Changing the cluster size is not as easy as you might think. There is nothing about it in any of my device descriptors and 'format' has no option to that effect. To change it manually, you must: - FORMAT the disk normally - dEd/QTip the disk: - edit LSN-0: - change the cluster size to any power of 2 (bytes $06-$07) - divide the number of bytes in the allocation bitmap (bytes $04-$05) by the same power of 2 used above and round down to the next nearest byte. - edit root directory file-desciptor: (LSN of root fd is in LSN-0) - change the size of the first and only segment so the directory ends at the end of a cluster. For example, my hard disk has its root directory file-descriptor on sector $50 and the root directory itself starts on sector $51. If I wanted a cluster size of 32 ($20), the start of the next cluster would be $60, so I change the size of the root directory's segment, originally set to $07 by 'format', to $0F ($60-$51=$0F). If a cluster is not is not completely allocated within the file structure, dCheck assumes that none of it is allocated. OS-9/RBF will take care of all this allocation for you once the required manual setup is finished. - perform a dCheck on the disk - use a utility like BD/BA from the RePack software package to deallocate any clusters that dCheck mentions (or fool around with the first few bytes of LSN-1 by hand using dEd/QTip until dCheck reports a clean disk). DCheck always reports clusters by the LSN they start on. BA and BD handle these LSN's properly to fiddle with the correct bits in the allocation map. - You now have a disk with whatever cluster size you put in bytes $06-$07. (This is really easier than it sounds... honest!) While playing around with this, I discovered that 'dCheck' seems to have a small bug in it that causes it not to check the last byte of the allocation bitmap! So if you start playing around with more than is said above and find that dCheck is not bothering to mention the $400 allocated sectors at the end of the disk that should be free, it's dCheck's fault, not yours. RBF seems to handle everything just fine. 'Free' has a similar bug which causes it to analyze the entire last byte even if some of it's bits aren't used. Rounding down LSN0's bytes $04-$05 will cause up to 7 clusters never to be used, but will work around both of these bugs. I have moved files to my disk after setting it to various cluster sizes and have had no problems with OS-9/RBF in any way. This wonderful feature seems to be fully implemented except for turning it on. ----- ----- ----- Anyone who edits over multiple windows, saving from all of them often, knows that the files fragment into many 1-sector segments quite quickly. This cluster size can help solve that problem because a 1-sector file in a 32-sector cluster still has lots of space to expand into before another segment is needed. With the upcoming wide-spread use of OS-9/68000 (or OS-k), RBF has an added feature of being able to handle devices with sector sizes of larger than 256 bytes. How this will be handled, I don't know. I would guess, since the OS-k file structure is identical to that of OS-9, that it just internally splits each sector up into 256-byte chunks and then sets the cluster size ccordingly to avoid file fragmentation within a sector. (eg a 512-byte sector would get a min cluster size of 2 while a 2048-byte sector would get a min cluster size of 8, etc.). Hope all this is of use to someone... Brian ................................................................. . UUCP: uunet!microsoft!w-brianw . . Delphi: BrianWhite . ................................................................. If at first you don't succeed, so much for skydiving.