Path: utzoo!utgpu!water!watmath!clyde!att!gargoyle!tank!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.unix.wizards Subject: Re: System V file systems Message-ID: <14235@mimsy.UUCP> Date: 29 Oct 88 04:40:41 GMT References: <6413@daver.UUCP> <8332@alice.UUCP> <1988Oct27.173247.2789@utzoo.uucp> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 43 >In article >hedrick@geneva.rutgers.edu (Charles Hedrick) notes that >>... The BSD file system is designed to avoid fragmentation [of the free list, eventually resulting in blocks being allocated `at random']. >>Of course this problem will not show if you do your tests right after >>creating the file system. In article <1988Oct27.173247.2789@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Or if you run your tests in a time-sharing environment, where the disk >heads are always on their way to somewhere else anyway. If you read >the fine print, all the Berkeley performance tests were run single-user!! >We conjectured a long time ago that the only feature of the 4.2 filesystem >that matters much in a timesharing environment is the big block size; I >haven't yet seen any solid results (numbers, not anecdotes) that would >contradict this. I actually agree with this (in spite of the point others have noted as to the weak definition of `time shared'). But it is important to consider several things. Not the least is that workstations (e.g., Suns) are virtually single-user. Certainly there are servers and daemons running, and you may be multiprocessing, but `on the average' you tend not to have more than one process doing file system I/O. Second, read-ahead blocks are moved into the buffer cache at the same time as the block actually being read; if these are adjacent, the r.a. block will come in more or less immediately, even if the disk then has to move the heads elsewhere for someone else's page-outs. So you get `two for the price of one', as it were. Also---and to us, this is not the least important point---often, when the machine really *is* in single user mode, you will want file reading to be as fast as possible, so that your backups will finish soon and you can allow the next batch of news to flow in. The BSD FFS allocation policies do a fair job of keeping files straight even in the presence of multiprocessed/timeshared writes. In other words, while I think that the large blocks are the most important factor, I am not unhappy about all the rest of it. (After all, *I* did not have to write the code . . . :-) ---and I have not had to do much to `maintain' it, either; Kirk did a good job of the code [think that is a hint, Mike? :-) ]) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris