Re: Why is one sync() not enough?

[jmerkey]

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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/