PATCH: Forcible delaying of UFS (soft)updates

[Oliver Fromme]

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.

 > - 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).

 > - invoking sync() causes flushing of softupdates buffers to follow
 > immediately, which was not the case before;

That's cool.  I always disliked the fact I had to type
sync several times and still couldn't be sure that
everything was really synced.  (Yeah, I know, it's the
way it works, it always worked like that, and it's
documented to work like that ...  but I still dislike
it.)

 > - 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.)

 > Nevertheless, my laptop runs without glitches for the last two weeks
 > with the extra delaying enabled, while happily achieving 5-10% longer
 > battery operated periods, depending on disk utilization patterns.

Awesome.  That would mean about 45 minutes more mobility
with my laptop.  :)

Regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"Clear perl code is better than unclear awk code; but NOTHING
comes close to unclear perl code"  (taken from comp.lang.awk FAQ)