ckp@grebyn.com (Checkpoint Technologies) (10/16/89)
In article <8181@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >Each file header contains pointers to the first 72 data blocks. If a file >is longer than that, the file header will have a pointer to an extension >block, which points to the next 72 data blocks, and also has an extension >block. So to seek ahead 200K, the filesystem will have to move through >5 extension blocks to find the pointer that references the block at 200K. > >Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > Too much of everything is just enough May I then make a request for 1.5 (or 1.6 or whenever you decide to make incompatible changes to the filesystem): How about making the file index blocks in a tree? The first 72 pointers refer to data blocks, until there are more than 72. Then they point to the next level of index blocks, until there are more than 5184 (72 times 72). A linear search of the index blocks in a bad way to do things. Especially when on a hard disk with file sizes in the multi-megabytes.
ccplumb@rose.waterloo.edu (Colin Plumb) (10/19/89)
In article <14003@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: > May I then make a request for 1.5 (or 1.6 or whenever you decide to > make incompatible changes to the filesystem): How about making > the file index blocks in a tree? The first 72 pointers refer to data > blocks, until there are more than 72. Then they point to the next > level of index blocks, until there are more than 5184 (72 times 72). > A linear search of the index blocks in a bad way to do things. > Especially when on a hard disk with file sizes in the multi-megabytes. First of all, they made incompatible changes to the filesystem in 1.3, and everyone seems to be happy. Hooray for modular software! It's not that big a deal to add another file system. The other thing is, I'm sure the C-A crew are working on *much* more interesting changes to the file system than just that. One major complaint is that the in-memory bitmap is pretty big (eats RAM) and if it gets trashed by an errant program, it only gets detected later when the system corrupts your disk. Having the machine crash would be preferable. Making it a smaller target is another way. Using less than 1 bit per disk block to manage a disk involves some pretty major work. There are lots of possibilities. -- -Colin