PATCH: Forcible delaying of UFS (soft)updates
tlambert2 at mindspring.com
Thu Apr 17 18:09:14 PDT 2003
Marko Zec wrote:
> On Friday 18 April 2003 02:17, Terry Lambert wrote:
> > I think people would be happier if you just stopped the soft
> > updates sync clock, and then if someone actually fsync()'ed, or
> > the dependency list got too big, it spun up the disk, completed
> > all the I/O quickly, and then spun it down again.
> The updated patch does precisely what you just described above. It already
> includes a tunable vfs.ena_lazy_fsync (off by default) which allows choosing
> whether blocking (standard) or null- fsync() semantics apply. Check out
No, you are missing my previous point: the check for free space
should include a check for number of elements *TOTAL* in all slots
on the soft updates timer wheel. Otherwise it can eat all of
The free space check only works in the case that you've done a
delete and are allocating new space: the case where you are doing
more and more allocations/opverwrites of data is not handled, and
can grow to eat all available kernel memory. There was in fact a
bug, early on, that Matt Dillon worked around that caused it under
load, and it was in exactly the code you are touching.
Also, the "ena_lazy_fsync" needs to be overridable, based on
barriers in the dependency list: it's not acceptable to violate
the POSIX semantics over trying to delay fsync(). You insert a
dependency that is blocked by some other dependency already
there, and you're in semantic trouble. Normally, this would be
prevented by a write lock on the buffer in question, but it's
not queued for write, because the wheels not moving.
The "ena_lazy_fsync" is really a problem, if it permits an
operation, such as the update of a database index file to
point to a new record that has been written to the database
data file. At this point, fsync() is used for implied
contracts. The only way you can legitimately delay it is
if there isn't an implied contract, which you should be able
to see as a barrier in the soft update dependency list.
Under what circumstances you you find that delaying fsync()
helps you? What program are you running that calls fsync()?
I think that maybe you are running a program (like qmail)
that doesn't trust the FS to comply with POSIX, so it inserts
some extra fsync()'s "just in case we are running on ext2fs"
And it still needs a sysctl that counts the number of them
that actually get delayed. Even if you don't use it for a
statistical check, it will check you on the number of times
fsync() (and sync()) get called by someone. If it's a small
number, you need to fix the bogus program, rather than hack
the kernel. 8-).
More information about the freebsd-stable