Date: 16 Apr 2003 11:28:49 +0100 From: Richard Caley <rjc@caley.org.uk> To: Marko Zec <zec@tel.fer.hr> Cc: freebsd-stable@freebsd.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates Message-ID: <87smsiohwe.fsf@pele.r.caley.org.uk> In-Reply-To: <3E9840B8.F00E018F@tel.fer.hr> References: <200304121438.h3CEct41030991@lurza.secnetix.de> <3E9840B8.F00E018F@tel.fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <3E9840B8.F00E018F@tel.fer.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@MYLASTNAME.org.uk _O_
|<
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87smsiohwe.fsf>