PATCH: Forcible delaying of UFS (soft)updates
zec at tel.fer.hr
Sat Apr 12 09:37:23 PDT 2003
Oliver Fromme wrote:
> Marko Zec <zec at tel.fer.hr> wrote:
> > Here's a patch against 4.8-RELEASE kernel that allows disk writes on
> > softupdates-enabled filesystems to be delayed for (theoretically)
> > arbitrarily long periods of time. The motivation for such updating
> > policy is surprisingly not purely suicidal - it can allow disks on
> > laptops to spin down immediately after I/O operations and stay idle for
> > longer periods of time, thus saving considerable amount of battery
> > power.
> It would be very cool if you could have different delay
> settings per filesystem. That would enable you to have
> a large delay on /tmp, a medium delay on /var, and the
> standard delay (i.e. more safety) on everything else.
That would certainly be cool, however I have no clue if and how such model
could be implemented. But what I can safely assume is that it wouldn't be
nearly as simple as the original patch.
> > - fsync() no longer flushes the buffers to disk, but returns immediately
> > instead;
> I see some issues with that. Better make that tunable
> separately (and probably default to off).
I agree that additional tunable for controlling fsync() behavior couldn't hurt,
however as explained in previous note I see the fsync() as the most common
initiator of disk spinnups, so a method for suppressing it must be made
available, otherwise the whole patch wouldn't make much sense...
> > - if one of the mounted filesystems becomes low on free space, which can
> > happen if lot of data is written to the FS but FS metadata buffers are
> > not updated to disk, flushing of all softupdates buffers is scheduled
> > automatically;
> That's cool, too. I've been bitten several times by the
> bogus "no space left on device", due to soft-updates
> delaying the freeing of file data.
> I assume that buffered data is also flushed to disk when
> the system runs low on RAM, right? (I'm not a VFS/VM
> expert, so that might be a stupid question.)
As far as I understand how softupdates work, the algorithm ensures the data is
_always_ written to disk before the metadata, so that shouldn't be a problem.
More information about the freebsd-stable