![]() | |||||||||||||
Messages in this thread |
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/ > > > - 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/ | ||||||||||||
| Last update: 2005-06-15 05:11 [from the cache] ©2003-2008 | |||||||||||||