PATCH: Forcible delaying of UFS (soft)updates

[rjc at caley.org.uk (Richard Caley)]

In article <3E9840B8_(_dot_)_F00E018F_(_at_)_tel_(_dot_)_fer_(_dot_)_hr>, Marko Zec (mz) writes:


mz> I agree that additional tunable for controlling fsync() behavior couldn't hurt,
mz> however as explained in previous note I see the fsync() as the most common
mz> initiator of disk spinnups, so a method for suppressing it must be made
mz> available, otherwise the whole patch wouldn't make much sense...

Would it make sense to make the fsync behaviour a per-process choice?
That way certain system processes could, if this delay behaviour is
enabled, use the null fsync. For instance, if syslog is one of the
things causing annoying spin-ups, then the user could tell syslog not
to really fsync, trading forensic information in the event of a crash
for battery life. 

Additionally there could be a really_really_fysnc call to be used to
make certain programs delay-aware. Eg, it might be acceptable for my
emacs checkpointing not to fsync, again I'm trading losing a little
more work in the event of a crash for battery life, but when I
explicitly save, I am saying I want that stuff on disk and stable NOW,
and damn battery.

-- 
Mail me as MYFIRSTNAME_(_at_)_MYLASTNAME_(_dot_)_org_(_dot_)_uk        _O_
                                                 |<