[ On Friday, November 30, 2001 at 00:46:42 (-0000), David Laight wrote: ]
> Subject: Re: Crash-resilience of FFS (w/softdeps)
>
> > > I wonder if a close() of the last descriptor to a file should do an implicit
> > > flush()
> > 
> > If you mean fsync(), then no.
> 
> How much of a performance hit would scheduling the write of blocks associated
> with a file (including the inode) when the file is closed actually be?

Scheduling the writes wouldn't be so much overhead, though they are in
effect scheduled immediately anyway.  However a forced fsync() on
close() would introduce far far more delay than I would be willing to
tolerate, and I venture that many people would agree too.

I suspect compiles without '-pipe' would crawl MUCH slower, for example.

(I've not actually tried this, though it shouldn't be hard to simulate
by just adding fsync() in the shared libc)

> I suspect that these writes will have to be done anyway!

Eventually -- but not right away.

> Clearly there is no need to do them synchronously on the close.

It all depends on how much was written, and sometimes even what will be
done with the data in the next few moment.

Since we are talking about softdeps here another good example is
unlink(2).  If you've ever compared the time it takes to remove a large
tree of large files with and without softdeps then you'll even further
appreciate the benefits of delayed writes.  Sure they have to happen
eventually, and in the right order, but if you can schedule them all
very quickly and then give control back to the user as quickly as
possible the overall throughput of the system can at least appear to be
much higher (and with some application loads it will actually be much
higher, eg. compiles without '-pipe' where the data can be written and
then deleted again before it ever touches the disk).

> FYI adding:
> 
> all:    sync <targets>
>         sync
> 
> sync:
>         sync
> 
> to a makefile tends to protect your source files...

If I'm not mistaken 'sync' still only schedules an update in NetBSD.
They happen every 30 seconds anyway.

If your build machine is so unstable that 30 seconds really matters that
much then you should probably look for more stable hardware (or power or
operators or whatever's the cause of the instability)!  :-)

I've been known to reduce the ioflush/update cycle time to 300 seconds
or more and with certain application loads (eg. usenet news processing,
and sometimes even compiling) the improvement in performance is quite
dramatic.  The default of 30 seconds is a "safe" common default suitable
for any range of system and application, but it's far from optimum.
With a UPS and stable reilable hardware there's no harm in increasing it
reasonably.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>