Re: Why is one sync() not enough?

[jmerkey <jmerkey@utah-nac.org>]

There are cases where bitmaps can dirty themselves in the FS's (I have 
had to deal with several of these issues in 2.6) after a sync,
and I have found that:

#
# sync
# sync
#

is required on ext2 in some situations due to some race conditions with 
remote and local clients using device based FS's, so
there are some holes -- and comments in ext2 and several other FS's seem 
to bear this assumption out.

:-)

Jeff

Andrew Morton wrote:

>Nico Schottelius <nico-kernel@schottelius.org> wrote:
>  
>
>>Hello again!
>>
>>When my system shuts down and init calls sync() and after that
>>umount and then reboot, the filesystem is left in an unclean state.
>>
>>If I do sync() two times (one before umount, one after umount) it
>>seems to work.
>>
>>    
>>
>
>That's a bug.
>
>The standards say that sync() is supposed to "start" I/O, or something
>similarly vague and waffly.  The Linux implementation of sync() has always
>started all I/O and then waited upon all of it before returning from
>sync().
>
>And umount() itself will sync everything to disk, so the additional sync()
>calls should be unnecessary.
>
>That being said, if umount was leaving dirty filesystems then about 1000000
>people would be complaining.  So there's something unusual about your
>setup.
>
>What filesystem?  What kernel version?  Any unusual bind mounts, loopback
>mounts, etc?  There must be something there...
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>