Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rutgers!cbmvax!cbmehq!cbmger!peterk From: peterk@cbmger.UUCP (Peter Kittel GERMANY) Newsgroups: comp.sys.amiga.tech Subject: Re: FFS and hash chains Keywords: FFS Message-ID: <468@cbmger.UUCP> Date: 2 Oct 90 07:46:28 GMT References: <1348@cuenews.UUCP> Reply-To: peterk@cbmger.UUCP (Peter Kittel GERMANY) Organization: Commodore Bueromaschinen GmbH, West Germany Lines: 38 In article <1348@cuenews.UUCP> andrew@cuenews.UUCP (Andrew Folkins) writes: > >Now, under the FFS, I can't figure out what's going on. It's >definitely *not* the same, as printing the hash table values while >'list'ing produces something like: > > sector track sector head hash filename > 74375 364 17 3 52 list > 74868 367 00 0 59 list.lnk > 75259 368 17 5 47 list.c > 75274 368 32 5 59 list.o > 77000 377 24 2 0 skeleton.c > 77002 377 26 2 33 textmap.c > 77004 377 28 2 51 isqrt.c > 77006 377 30 2 54 textmap > 77008 377 32 2 5 textmap.lnk > 77178 378 32 1 52 conpackets.c > etc. Thank you for exploring these details. Please correct me if I'm wrong, but this seems to be a sort of elevator seeking already. Everytime the algorithm finds a new block number, it does not go to that sector immediately but puts it into a sorted list of sectors yet to search for. Thus you can avoid many of the head movements necessary with the older, dumber mechanism. If I understand it correctly, there may still arise problems when the blocks are spread too wildly, but also then it boils down to only a few passes of the head across the disk. (This is all only speculation, I don't know the source, but had thought about this one already long for myself, but didn't get time for it. So I'm very pleased that they've done it already at West Chester, thanks.) -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk