Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!news.hawaii.edu!ames!lll-winken.llnl.gov!sol.ctr.columbia.edu!hamblin.math.byu.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 20:50:14 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 120
Message-ID: <4giku8$7k8@park.uvsc.edu>
References: <4ggc9k$kbv@park.uvsc.edu> <4ggj2f$mej@park.uvsc.edu> <4ggo5v$mon@park.uvsc.edu> <4gic4k$6rt@park.uvsc.edu>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14217 comp.os.linux.development.system:17834
mday@park.uvsc.edu (Matt Day) wrote:
] >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.
My initial posting to which you were replying was a defense of
the use of synchronus writes to ensure ordering. I think that
any possible lack of determinism in crash recovery is simply
unacceptable for all but a few cases, and those cases have been
adequately explored in other posts.
That said, I'm not going to defend sync updates as the *best*
method of ensuring structure integrity, only as *a* method,
and a irrefutably better than async updates in all cases.
[ ... rm and POSIX semantics adding to the overhead ... ]
] >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.
[ ... ]
] 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.
I agree for these operations.
BSD also does a sync update of the directory change time in the
directory inode. It was this "metadata", not the directory
entry itself, to which I was referring when I said this was an
unnecessary overhead.
I know that you and I disagree on whether the POSIX semantic
"shall be updated" means "shall be committed to disk" or not.
I know that "shall be marked for update" means that it is
permissible to use a delayed write (modify the value in memory
and mark the structure dirty). I disagree about the "shall
be updated" requiring only a commit to memory rather than to
permanent storage.
From my perspective, then, POSIX adds unnecessary overhead for
preserving what seem to be VMS or other historical semantics
for no other apparent reason, other than history. 8-(.
] 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.
Three. See above.
] 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.
Certainly for you and me. 8-). I believe that computers won't
be fast enough until the computer precomputes all posible actions
by the user at any given point, and then responds instantly with
the right response when the user hits return. Including recompiling
the world, or whatever.
Even then, I'll probably be annoyed at having to wait for the
log output to scroll by. 8-).
] >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).
I calculated my percentages incorrectly as percentage difference
instead of percentage increase (which is what the paper correctly
reports.
In any case, anything over 15% would probably represent a
significant result.
] 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. :-)
8-).
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.