Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.unix.wizards Subject: Re: System V file systems Keywords: System V Message-ID: Date: 26 Oct 88 02:42:52 GMT References: <6413@daver.UUCP> <8332@alice.UUCP> Distribution: na Organization: Rutgers Univ., New Brunswick, N.J. Lines: 23 >Given a fast CPU, a not-very-intelligent disk controller and the optimal >interleaving and file system gapsize, the performance is roughly linearly >proportional to the block-size. Two problems: (1) To get really good performance, you have to use a block size so large that you waste lots of disk space on small files. The BSD file system can split the last block in a file into fragments. You get the benefits of a big block size on all but the last block, and don't waste the disk space. (2) System V (at least SVr2, and I think also SVr3) uses a free list, which it does not keep in order, so an active file system fragments very soon. The BSD file system is designed to avoid fragmentation. Of course this problem will not show if you do your tests right after creating the file system. The BSD fast file system is more than just larger block sizes. It makes sense for SVr4 to support both the old and new, to allow people to move between SVr3 and SVr4 during testing and conversion. However once you have committed to SVr4, I'd think you would want to move to the fast file system.