PATCH: Forcible delaying of UFS (soft)updates

[Marko Zec]

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.

Cheers,

Marko