On Sat, Mar 08, 2014 at 11:08:18AM -0500, Theodore Ts'o wrote: > On Wed, Mar 05, 2014 at 03:13:43PM +0100, Lucas Nussbaum wrote: > > TL;DR: we experience long temporary hangs when doing multiple mount -o > > remount at the same time as other I/O on an ext4 filesystem. > > > > When starting hundreds of LXC containers simultaneously on a system, the > > boot of some containers was hanging. We tracked this down to an > > initscript's use of mount -o remount, which was hanging in D state. > > > > We reproduced the problem outside of LXC, with the script available at > > [0]. That script initiates 1000 mount -o remount, and performs some > > writes using a big cp to the same filesystem during the remounts.... > > +linux-fsdevel since the patch modifies fs/super.c > > Lukas, can you try this patch? I'm pretty sure this is what's going > on. It turns out each "mount -o remount" is implying an fsync(), so > your test case is identical to copying a large file while having > thousand of processes calling syncfs() on the file system, with the > predictable results. > > Folks on linux-fsdevel, any objections if I carry this patch in the > ext4 tree? I don't think it should cause problems for other file > systems, since any file system that tries to rely on the implied > syncfs() is going to be subject to races, but it might make such a > race condition bug much more visible... IMO, I think that you should be looking to fix ext4 syncfs issues, not changing the VFS behaviour that might cause subtle and unnoticed problems for other filesystems. We should not be moving data inegrity operations without first auditing of all the filesystem remount operations for issues. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
