Problems unmounting/fssyncking extern UFS filesystem
oberman at es.net
Tue Nov 28 11:56:31 PST 2006
> From: Chuck Swiger <cswiger at mac.com>
> Date: Tue, 28 Nov 2006 11:36:52 -0800
> On Nov 27, 2006, at 8:41 AM, Kevin Oberman wrote:
> >> As far as I know, that's not different from calling "sync"
> >> just once. It might make more sense to put a little sleep
> >> between the sync calls, though.
> > The traditional mantra was
> > sync
> > sync
> > sync
> > and not sync;sync;sync. The reason was timing. By entering the sync
> > command three times as fast as anyone could type, the sync could
> > reliably complete.
> Agreed. Although I've heard rumors that some systems treated 3 syncs
> as some sort of special case, but I've never seen anything in code to
> support the notion.
> > That mantra is about 25 years old, so its validity on modern
> > hardware is
> > questionable, but the need for a delay is very real. I would suggest
> > something like: sync && sleep 5
> The other choice would be to make sync [or the sync(2) system call,
> more precisely] blocking, so that it does not return until the buffer
> cache has been flushed and all dirty pages in VM have been written to
The magic phrase is "buffer cache has been flushed". In the real world
of discs with cache there is no way to be certain when the data is
REALLY on the disc. That is why things get clobbered if the power is
cycled to the disc too soon after syncing and why a sleep (or typing
sync three times) is still a good idea and probably always will be.
Of course, some day all discs may stop lying about when data is written,
but I'll be too busy ducking the flying pig.
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 224 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20061128/8757907b/attachment.pgp
More information about the freebsd-stable