Subject: Re: Deleting files
To: Christian von Kleist <cvk@zybx.com>
From: Paul Mather <paul@gromit.dlib.vt.edu>
List: port-alpha
Date: 03/18/2003 08:59:36
On Tue, Mar 18, 2003 at 03:43:20AM -0500, Christian von Kleist wrote:

=>      Thanks for all the suggestions from everyone.  I wasn't using soft
=> dependencies and turning it on will increase performance, but should
=> I be using it?  I turned it on for my /storage and /software which
=> are partitions on separate drives that I use for compilation of
=> source and storage of the final product, respectively.  There's been
=> enough speculation about softdep crashes to scare me out of using it
=> on /usr, /home, etc....
[...]
=>      As you can see, turning on softdep made a huge speed-up in file
=> deletion, and I'm very happy about that.  Now, if I can just figure
=> out if softdep is stable enough to trust!

Just as another data point, I've been using softdep on my Alpha
literally for years now (even when it was considered "experimental")
and I can't remember having any filesystem lossage/corruption (and
that is with several power-related outages on my home system, too).
(I can't say the same with my experiences with the log structured file
system, alas.)

You have to remember that activities like "rm" are very metadata
intensive operations, and metadata operations to disk are
characterised by short reads and writes.  Such small I/O is dominated
by the physical characteristics of the underlying disk
drive---especially where seeking is involved (which is the slowest
part of any I/O operation).  With a sync-mounted file system, such
metadata activity has to go to disk, to ensure consistency.  The
penalty of this is time.  Soft updates mitigates this problem by only
writing to disk the dependent data to ensure consistency (which, I
guess is where "dep" of "softdep" comes from).  There is a paper by
Ganger and Patt that describes this in more detail.

The short vs. large I/O problem also explains why you get much better
I/O speeds out of your disk drive (as you observed in a previous
message).  The larger and more sequential the files being accessed, the
less time overheads are lost to large seeks.

Cheers,

Paul.

e-mail: paul@gromit.dlib.vt.edu

"Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid."
        --- Frank Vincent Zappa