Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!news.ci.com.au!metro!metro!munnari.OZ.AU!news.mel.connect.com.au!yarrina.connect.com.au!news.mel.aone.net.au!imci4!newsfeed.internetmci.com!inet-nntp-gw-1.us.oracle.com!news.caldera.com!news.cc.utah.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
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 03:33:19 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 152
Message-ID: <4ggo5v$mon@park.uvsc.edu>
References: <4g5ivp$28m@park.uvsc.edu> <4ge2qa$2gm@park.uvsc.edu> <4ggc9k$kbv@park.uvsc.edu> <4ggj2f$mej@park.uvsc.edu>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14513 comp.os.linux.development.system:18226
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 maintain that ~92% of all user operations are read or write
or single directory lookup. Synchronus metadata updates do not
impact perceived speed in these cases, IMO.
The number 92% comes from the top 5 operations agains Novell
file servers by client machines. I'm sure there is some
lattitude in the remaining 8% because of the difference, but
no more than a factor of 2 (say a max of 16% of "other"
operations).
This does not make the problem unreal or trivial; it simply
affects average user perception.
Synchronus I/O causes two types of delays: latency and concurrency.
For a single user (typical usage of PC hardware), the concurrency
is not a problem [before you respond: you are not a typical user).
The latency in the most frequent cases is negligible. In the
FreeBSD case, the latency is compensated by the faster I/O and
the unified cache. Bonnie and IOzone both bear this out.
Of the benchamarks in the Ganger/Patt paper, the first is a 4 user
copy (not applicable to a single desktop user), the second is a 4
user remove (again, concurrency effect make it non-applicable).
The third (a)/(b)/(c) is mass creation (frequently only at
install time), mass remove (not frequent at all), and mass
create/remove (the artificial lmbench "benchmark"). I argue
that such operations are infrequent enough as to not be user
perceptible.
There is a case to be made for the Andrew benchmark (table 3).
I claim that the only place the effects exceed 6% between the
implementations in the single user benchamrk is in the creation
of directories and copying of files.
In both cases, we can subtract out half the directory create
time from the copy file time, since the create directory
manipulates two inodes synchronously, and we see that the
copy files benchmark is most profoundly impacted by the need
to allocate a new inode (as in the directory create).
Note that the overall time once again is attributable to multiple
agregate operation (the create and copy are on a plurarlity of
files)... a concurrency issue.
] As I hope you can now see, my disagreement had nothing to do
] with whether or not the lmbench create/delete test is a correct
] benchmark.
I see this. And I agree completely with you -- in a multiuser
environment. The effects are certainly perceptible in a server
machine of any kind.
I'm not trying to trivialize the importance of the speed
improvements possible to be made. I'm just trying to point
out that your average user sitting at a keyboard isn't going
to see a real difference.
] >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.
] >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).
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).
A software developer would definitely see a difference. I agree
that soft updates should be implemented.
Note that there is not a significiant difference in the numbers
they present for a delayed-ordered write vs. sync implementation.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.