Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!act.news.telstra.net!psgrain!usenet.eel.ufl.edu!newsfeed.internetmci.com!in2.uu.net!news.new-york.net!news.columbia.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu!park.uvsc.edu!not-for-mail From: mday@park.uvsc.edu (Matt Day) Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux Date: 22 Feb 1996 11:20:04 -0700 Organization: Utah Valley State College, Orem, Utah Lines: 146 Message-ID: <4gic4k$6rt@park.uvsc.edu> References: <4ggc9k$kbv@park.uvsc.edu> <4ggj2f$mej@park.uvsc.edu> <4ggo5v$mon@park.uvsc.edu> NNTP-Posting-Host: park.uvsc.edu Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14327 comp.os.linux.development.system:17966 In article <4ggo5v$mon@park.uvsc.edu> Terry Lambert <terry@lambert.org> writes: >mday@park.uvsc.edu (Matt Day) wrote: >] I believe you have misunderstood me. You said synchronous metadata >] updates make no difference in user perception of speed, except for bogus >] benchmarks. I disagree with that statement. If synchronous metadata >] updates made no difference in user perception of speed except for bogus >] benchmarks, then the only people who would care about the problem would >] be the people who run bogus benchmarks, and that just isn't the case. >] Synchronous metadata updates have been identified as a file system >] performance problem by many researchers, including Ganger and Patt. [1] >] As their research indicates, the problem is real, not trivial. > >I think you are confusing "user perception of speed" with "file >system researcher perception of speed". I disagree. I think the impact of the speedup will go far beyond the tiny file system researcher community. See below for further support of my claim. >[..] > >] >The "rm" overhead is a result of POSIX semantic requirements; as >] >you yourself have pointed out, these requirements can be, in some >] >cases, more favorably interpreted than UFS chooses to interpret >] >them. >] >] No, you are completely wrong. The ``rm -r'' performance problem is >] caused by the use of synchronous writes to sequence metadata updates, >] thus protecting metadata integrity. [1] It has nothing to do with POSIX. > >The metadata would not need to be written if the access timestamp >did not need to occur, or did not need to "shall be updated" as >opposed to "shall be marked for update". > >The remove operation would modify the directory metadata >synchronously only in the case of the directory being truncated >back (a new feature of 4.4 UFS), causing the file size to need >to change, or in the case of the update actually taking place >when the update daemon fired. > >This is a far cry from modifying the atime on every read and the >on disk ctime on every write. > >It is POSIX semantics, not structural integrity semantics, that >cause the update to the time stamps to occur immediately rather >than causing them to be agregated and written together at a later >time. What you have said here is completely wrong! When removing a directory entry in the BSD FFS, the on-disk inode must not be reinitialized or pointed to by a new on-disk directory entry or free inode map before all previous on-disk directory entry pointers to it have been nullified. To implement this rule, 4.4BSD FFS synchronously updates the on-disk directory entry when removing a directory entry. You can verify this for yourself by looking at the ufs_dirremove() routine in ufs/ufs/ufs_lookup.c in FreeBSD. This occurs every time a directory entry is removed. Additionally, deallocated blocks must not be reused before previous on-disk pointers to them have been reset. To implement this rule when deleting a file, 4.4BSD FFS zeros the block pointers in the inode and then synchronously writes the inode to disk before calling any block deallocation routines (which, in the file deletion case, use delayed writes to deallocate the blocks). You can verify this for yourself by looking at the ffs_truncate() routine in ufs/ffs/ffs_inode.c in FreeBSD. This occurs every time a file is deleted. Both these rules exist to prevent irreparable metadata inconsistencies from occurring. This is all clearly described by both McKusick's Fsck paper and Ganger and Patt's Soft Updates paper. To summarize: every time you delete a file on FreeBSD, two separate synchronous metadata updates occur: one for the directory entry and one for the inode. The reason the updates are synchronous is to prevent irreparable metadata inconsistencies from occurring. It has absolutely nothing to do with POSIX semantics. >] >I believe your perception test to be atypical of common usage; >] >can you claim the FS operations you are performing to be typical, >] >or do they fall more into the category of "stress testing"? >] >] You want a more typical operation than ``rm -r''? How about compiling? >] Ganger and Patt measured a 5-7 percent performance improvement in the >] compile phase of the Andrew file system benchmark when running on a file >] system using soft updates to sequence metadata updates rather than >] synchronous writes. They go on to explain that the compilation >] techniques used by the benchmark were aggressive and time-consuming, >] while the CPU they ran the benchmark on was slower than the standards of >] the day, which means you could expect the performance improvement to >] significantly increase on systems with faster CPUs. They also saw a >] 50-70 percent improvement when running the Sdet benchmark from the SPEC >] SDM suite. (As Ganger and Patt explain it, Sdet concurrently executes >] one or more scripts of user commands designed to emulate a typical >] software-development environment (e.g., editing, compiling, file >] creation, and various UNIX utilities).) [2] >] >] Based on this evidence, I claim that synchronous writes to sequence >] metadata updates significantly slows down typical file system >] operations. > >I claim 5-7% isn't user perceptable (I don't think I could perceive >it unless I was trying). Please remember that the 5-7% performance improvement they measured was smaller than one could expect due to the speed of their CPU. The faster your CPU, the greater the performance improvement will be if you don't do synchronous metadata updates. I agree that 5-7% is on the edge of being user perceptible, thus if the improvement is greater on faster CPUs (for example, any Pentium), I believe the improvement will be quite perceptible. >The SDET is, I admit, more problematic. From the graph in their >first paper, however, the increas is from 35 to 52 sripts/hour for >a single user, and actualy is widest at 2 users (tending to converge >to a smaller difference as number of users increase from 3 on up. > >A 34% difference (narrowing to ~28% on the graph) is significant >enough to be perceptible (though nowhere near 50-70% claimed in >the text... the highest I see on the graph is 40 vs 60 on two >"users"... a 50% difference). The numbers they claimed in the text are correct. According to the graph, the difference in scripts/hour is 35 vs. 60 in the two user case (a 71.4% improvement) and 40 vs. 57 in the 8 user case (a 42.5% improvement). In any case, I agree with you, the Sdet numbers do indicate a significant win for soft updates over synchronous updates. >A software developer would definitely see a difference. I agree >that soft updates should be implemented. I believe software developers make up a significant portion of the FreeBSD and Linux user community. Could you call me a "typical" or "average" user of FreeBSD or Linux based on that? I think so. But I'm not interested in arguing the definitions of these words or exactly what percentage of the user community will notice the speedup. I think we agree that it is a significant percentage, and I know we agree that it is a general win. Anyway, I don't think there's a software developer on the planet that is satisfied with how fast his/her system compiles programs. And, by god, we're the software developers so we say what goes. :-) Matt Day <mday@park.uvsc.edu>