[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PATCH: Forcible delaying of UFS (soft)updates
- Subject: PATCH: Forcible delaying of UFS (soft)updates
- From: rjc at caley.org.uk (Richard Caley)
- Date: Wed Apr 16 03:29:19 2003
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_
Visit your host, monkey.org