Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!cornell!uw-beaver!microsoft!w-colinp From: w-colinp@microsoft.UUCP (Colin Plumb) Newsgroups: comp.sys.amiga.tech Subject: Re: Faster File Systems Keywords: BOOH Message-ID: <88@microsoft.UUCP> Date: 16 Dec 88 09:16:37 GMT References: <55@microsoft.UUCP> <65@microsoft.UUCP> <5512@cbmvax.UUCP> Reply-To: w-colinp@microsoft.UUCP (Colin Plumb) Organization: Microsoft Corp., Redmond WA Lines: 84 Confusion: Microsoft Corp., Redmond WA Thanks for the comments... I'm still looking for someone to disagree on implementation points. I've convinced myself it'll work, but just today failed to convince someone else I'd thought it through properly. And if I can't describe it to a person, I might not do too well describing it to a computer. Did anyone else get totally lost? In article limonce@pilot.njin.net (Tom Limoncelli) writes: >I really like your idea. If you combine that with full track cacheing >you'd have something. The only problem is that: >1. it only works for floppies -- people are moving to hard drives Sigh. I know. I will, as soon as I can find a cheap A1000->Zorro II adapter. I'm not planning on selling this as a commercial product or anything, I just want to mess around inside Amy. (Kinky!) It's for fun. Utility would be a nice side-effect. >2. Getting people to convert will be difficult unless you can >convince all the non-hard drive people to convert. Of course, when >they can affort hard drives they'll switch to the FFS. I wasn't really planning on taking the world by storm, more providing a nifty hack which the more adventurous might like to use. If it's widely adopted, I'll be most gratified, but I'm not planning that far ahead. >It does make for a very interesting project. Possibly a good project >that could get yourself published in the ACM and get some people >thinking about file systems that aren't sector based. I say.. my hacking, a research paper? I wonder if I could... In article <5512@cbmvax.UUCP> steveb@cbmvax.UUCP (Steve Beats) writes: >I did take a brief scan over your original posting and will grant that it >has a few nice features *FOR FLOPPIES*. The point is that the filing >system really makes minimal use of the tracks/sectors/heads information. True, true, this is not at all a general-purpose thing. But, given that I only have floppy drives to play with, I decided to see what I could do with them. I was rather hoping someone would take issue with *how* I do this, not my decision to restrict myself to floppies. Even if it does not turn out to benefit mankind in any great way, I think it would be a fun thing to play with, and hope some other people would like to contribute ideas. I'd be delighted if it turned out to be useful, but the hacking is the important part. >If I were to take your filing system and >try to hook it up to some remote device driver (one that gets its data >across a network for instance) all of the optimisations you mentioned >would do nothing but waste time! Even ramdrive.device (although it does >present itself as a disk) would not benefit from this scheme. The beauty >of the filing system as it stands now, is that it can interface to just >about any device that takes a logical offset for read and write commands. I know. Over a network, you want to minimise the amount of data sent, and where it is physically located doesn't make much difference; the network is the bottleneck. The ramdrive has constant-time access, so any attempt to cluster data is a waste of cycles. I have my own ideas about how to write a general-purpose file system, better than the FFS. However, they're somewhat better for hard drives, where crossing a track from block n to n+1 isn't particularly expensive; if you set things up right, the one-track seek time equals the rotational latency, and isn't much more than the rotational latency on one track. Since I only have a floppy to try things out on, I decided to try and optimise the design for that. Is this decision all that horrible? >I still maintian that the driver (which *HAS* to know about the media it >is accessing) should be responsible for bad block mapping. In the same >vein, the driver should be responsible for local speed optimisations >based on the hardware it is controlling. I too like hardware that does this for me. But if I go to all sorts of trouble to cluster my seeks and find the disk has mapped cylinder 5 to cylinder 1001, I'm pissed. Most file systems' jobs is to find space among a bunch of already-allocated blocks. It only takes a little bit of tweaking to consider bad blocks as permanently allocated, so why not use this ability? You can argue both sides. Your side seems to be winning. It's not really worth losing sleep over. (One in the morning? *I*'m losing sleep over it. G'night, all.) -- -Colin (uunet!microsof!w-colinp)