[Discuss] Issuing the 'sync' command more than once (and a tangent on how not to run a high-tech company)

[j.natowitz at rcn.com (Jerry Natowitz)]

I suggest using a floppy disk or a slow USB flash drive as a test.  You can write to it and then time how long a umount takes.  You can then test it again, timing a sync or two (or three) and then the umount.



---- Original message ----
>Date: Tue, 19 Jun 2012 14:11:39 -0500
>From: discuss-bounces+j.natowitz=rcn.com at blu.org (on behalf of Derek Martin <invalid at pizzashack.org>)
>Subject: Re: [Discuss] Issuing the 'sync' command more than once (and a tangent on how not to run a high-tech company)  
>To: MBR <mbr at arlsoft.com>
>Cc: L-blu Unix <discuss at blu.org>
>
>On Sat, Jun 16, 2012 at 12:59:44PM -0400, MBR wrote:
>> On 6/12/2012 11:22 PM, Jack Coats wrote:
>> >In old SunOS days, we could issue the 'sync' command, twice, to ensure
>> >all system
>> >buffers had been written to disk.  You could experiment to see if
>> >issuing it occasionally
>> >in your script helps.  Or issue it outside the script, even in a chron
>> >might help.
>> 
>> Actually, calling 'sync' multiple times from a script really won't
>> help.  To the best of my knowledge, no Unix kernel has ever
>> contained code that counts the number of times sync() (the system
>> call that the 'sync' command issues) has been called.  
>
>The reason I was taught to do this differs from what you put forth,
>and regardless it's certainly true that no modern Unix should ever
>require a user to run sync manually, except possibly in very rare
>circumstances.
>
>I don't claim to know the veracity of this, but I was taught (by a
>college professor who taught Unix system adminsistration as a course,
>for whatever that's worth) that the reason to sync twice (not three
>times) is that, as you say, the first call to sync schedules the
>kernel to sync the buffers, but does not necessarily complete before
>the system call returns; however (as I was told) a SUBSEQUENT call to
>the sync() system call would block until any previously scheduled sync
>had completed.  Thus, the completion of the SECOND sync command
>guarantees that the FIRST sync completed flushing the buffers to disk.
>
>Now, I certainly have not spent the time to look at the code to any
>antiquated Unix kernels to confirm whether this was ever actually true,
>anywhere.  And I don't intend to.  But it's at least plausible that it
>was true at one point in some popular Unix.  As you yourself said, for
>quite a long while now on Linux (since August of 1995), sync() actually
>does wait until the buffers are flushed.  But even that is mostly
>irrelevant as the kernel forces the buffers to be flushed periodically
>and flushes them prior to system shutdown (assuming it can, of
>course).
>
>-- 
>Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
>-=-=-=-=-
>This message is posted from an invalid address.  Replying to it will result in
>undeliverable mail due to spam prevention.  Sorry for the inconvenience.
>
>________________
>_______________________________________________
>Discuss mailing list
>Discuss at blu.org
>http://lists.blu.org/mailman/listinfo/discuss