Subject: Re: Question: various bugs in sync()?
To: Greg A. Woods <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 01/15/1999 10:38:39
On Fri, 15 Jan 1999 11:58:45 -0500 (EST)
email@example.com (Greg A. Woods) wrote:
> This definition would not necessarily conflict with the requirement in a
> particular implementation that sync() return only after all buffers are
> written. I would certainly like to see NetBSD and others impose this
> requirement on sync(2).
...and for those of us to like to live fast-and-loose, please make it
a sysctl (vfs.generic.syncwait).
I.e. I won't want to impose arbitrary performance limitations on my system
by changing a semantic which hasn't bothered people for quite a long time.
I'm perfectly happy with the vnodes getting flushed when either:
(1) the file system has been unmounted,
(2) the system is rebooted.
Note, there's another problem with syncwait. You know how sometimes
a vnode can't get flushed? I.e. when you're rebooting and it reports
"giving up". This can happen for any number of reasons, like maybe
an NFS server being unreachable, etc. Or maybe a disk is having problems,
and isn't responding to commands.
Well, if you make sync(2) wait for that, think about what happens to
update(8). (Ok, I'll spill it... it'll still be asleep when it's time to
call sync(2) again, and thus won't make the call. Other files are going
to suffer at the hands of one which is having a hard time getting flushed
Jason R. Thorpe firstname.lastname@example.org
NASA Ames Research Center Home: +1 408 866 1912
NAS: M/S 258-5 Work: +1 650 604 0935
Moffett Field, CA 94035 Pager: +1 650 940 5942