mwm@ucbopal.berkeley.edu (Mike (I'll be mellow when I'm dead) Meyer) (04/28/86)
In article <8604270910.AA26871@cory> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >(3) Linked list sector's went out a decade ago. Only commodore was >stupid enough to use linked list sector's in their disk format. Get Sorry, but Commodore weren't the only people to use linked list sectors. DRI (remember them? Used to be one of the three biggest names in the micro world?) used a sector allocation similar to AmigaDOS, with the added benefit of having a section of a disk that held all the directory entries. Ugly, slow and fragile. TRSDOS has (had?) the same problems. But for a real laugh, take a look at the early (and possibly still in use) Series 1 file systems. >Well I'm saying it.... the 4.2 BSD filesystem is fast, efficient, and one >of my favorites. You could fit most of its concepts in a file-system >fit for the Amiga. Fast? Efficient? Uh, then why is namei caching so high on the list of things that make 4.3 run fast? You should be able to make it fit into an Amiga; after all, MicroWare got most of the v7 file system into a CoCo. But it's not clear you want to take a 10+ year old file system design (the basics of the 4.2 FFS are still Unix), as opposed to try and incorporate some of the things that have been done since then. The file/block headers are a move in that direction; not perfect, for some things not as good as a Unix FS with the same lack of caching (I hope nobody ever really tried that!); but like I said before - it's nice to see the micro world exposed to soem of these things. <mike
cc1@ucla-cs.ARPA (UCLA Computer Club) (05/03/86)
In article <620@jade.BERKELEY.EDU> mwm@ucbopal.UUCP (Mike (I'll be mellow when I'm dead) Meyer) writes: >In article <8604270910.AA26871@cory> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>(3) Linked list sector's went out a decade ago. Only commodore was >>stupid enough to use linked list sector's in their disk format. Get > >Sorry, but Commodore weren't the only people to use linked list sectors. DRI >slow and fragile. TRSDOS has (had?) the same problems. But for a real laugh, *** GGGRRRRRRRR *** I don't like TRSDOS, but I will defend it were it deserves it (Besides, NeWDOS uses essentially the same system) A TRSDOS directory has one sector for the disk allocation map, one sector for all the file hash codes (quick yes/no test), and 8 more sectors with 8 files each. Each entry stores the name of the file and 4 extents (phisically continuous disk space), plus a pointer to the next entry (if there are more than 4. Very few files need more than 2 or 3). The File Control Block (sort of like a FILE structure) contained the 4 most recently used extents (in memory). Seeks were fast--they just updated pointers, and read the directory if the extent information wasn't in memory. TRSDOS has a fast file system. Disadvantages? 1. No directory support. Enough space to put it in, but its not in. 2. Limited # of files. NeWDOS 80 is best, but it maxes at 222 files. (But you could make that 222 per directory (ugg) 3. Granule allocation. 3, 5, or 6 sectors per gran in most systems. (Everyone but NeWDOS refused to let a gran cross tracks. NeWDOS used 'lumps' (logical tracks) and kept the original 5 sectors per gran. But you could say 8 grans per lump for large drives. Incidently, I still think granule allocation beats sector allocation. Much less fragmentation. Michael 'Floppies are cheap' Gersten. -- Views expressed here may not be those of the Computer Club, UCLA, or anyone.
emjej@uokvax.UUCP (05/07/86)
In article <8604270910.AA26871@cory> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >(3) Linked list sector's went out a decade ago. Only commodore was >stupid enough to use linked list sector's in their disk format. Get I guess this is more evidence of the 680x ghetto...look at FLEX. (Or better yet, don't.) It did/does linked lists of sectors. It even did run-length encoding on blanks behind the user's back, which always struck me as interesting. James Jones