Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!twg.com!david From: david@twg.com (David S. Herron) Newsgroups: comp.unix.sysv386 Subject: Re: File system performance Message-ID: <8257@gollum.twg.com> Date: 10 Nov 90 21:43:05 GMT References: <294@audfax.audiofax.com> <1990Nov3.124110.2155@metro.ucc.su.OZ.AU> <1990Nov3.222929.2164@servalan.uucp> <1990Nov5.222733.11408@unixland.uucp> Reply-To: david@twg.com (David S. Herron) Organization: The Wollongong Group, Palo Alto, CA Lines: 63 In article <1990Nov5.222733.11408@unixland.uucp> bill@unixland.uucp (Bill Heiser) writes: >In article <1990Nov3.222929.2164@servalan.uucp> rmtodd@servalan.uucp (Richard Todd) writes: >> Well, that's how FFS works on other machines (I've hit it on Apple Unix >>2.0, which includes Berkeley FFS). Hitting the no-free-blocks limit when >>you've got 5M free in fragments is a little unusual; I was hitting the That 10% limit is a heuristic invented when Berkeley invented FFS designed to help keep fragmentation down. >Is there something that can be done "on-line" to de-fragment Unix partitions? Theoretically, yes. It would work best if the disk were `unmounted' first which is easiest to do if the system were brought to single user. It would also require writing software which would first sort the free list, then reorder all the data blocks into as contiguous an order as possible. The method is left as an excercise to the reader. If Unix were multitasking internally (as Mach is) then I can imagine an addition to either the disk driver or file system driver which would run as a seperate `thread', at very low priority, and do file system optimization in the background. Since it would run at low priority it would only snarf up idle time ... >Or is the best bet to just backup and restore the partition using something >other than 'dump'? This will work -- assuming you're using `tar' or `cpio'. > (I haven't done anything with the Esix >"2K file system utility" yet -- I'm not sure what is on that disk-- been too >busy to experiment...) All the 2K file system is is the same old V7 file system with some constants changed to confuse the innocent. It's no great stride forward in understanding the Universe .. it has most of the same performance features & limitations (eg, it fragments quickly and doesn't work well with largeish partitions since the inodes are all stuck at one end of the partition) as the .5K and 1K file systems. The difference is that the basic unit of allocation is a 2Kbyte block. Therefore each each data block in an inode refers to twice as much data as a 1K file system. Therefore you can have more data in a file before you get to indirect or doubly indirect blocks. Therefore a read returns more data (inside the kernel) so you tend to get a little more read ahead effect. Therefore it's suitable for file systems where you intend to store lots of largeish files. Perhaps (guess) it would also be good for file systems where you intend to store lots of 1K<"file_size"<2K files since then all the data in the file would be stored in one data block. This might have a positive effect on fragmentation .. -- <- David Herron, an MMDF & WIN/MHS guy, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- Use the force Wes!