steve@nuchat.UUCP (Steve Nuchia) (10/15/87)
I am considering writing a filesystem optimizer for the slow (AT+T) UNIX filesystem. This would run on a quiescent filesystem and would be proven to not do anything that fsck can't fix (without loss of data). I have access to fsck.c, so this would probably have to be a (&%#$% restricted distribution program, unless I can talk AT+T into giving me an indulgence of some kind. I am soliciting some input: If this program were available and I could convince you it was safe, would you use it? Would you pay money for it? If I could make, say, $50 from each of 50 sites I'd start this evening on it. If you are a binary vendor, would you make this available to your customers? What if it also included the functionality of fsck, ran faster than fsck for consistency checking, and did optimization (or fragmentation reporting) as an option? Would you pay, say, $1/copy binary royalty? I have read the Berkeley Fast Filesystem paper, and I have a pretty good idea what to optimize. Anyone who has studied the problem, from any viewpoint, is invited to contribute suggestions or observations. If anyone from AT+T feels like giving me dispensation to publish the source, I'd start on it real soon. Anyway, the correct place to put an optimizer is in the kernel as a scrubber task. I don't think that's a salable idea on the scale I'd like to see - it would be hard to help very many people that way. On the other hand, if a vendor is interrested in having that path investigated further, you have my number. -- Steve Nuchia | [...] but the machine would probably be allowed no mercy. uunet!nuchat!steve | In other words then, if a machine is expected to be (713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947