Christoph Hellwig <hch@xxxxxx> writes: > On Wed, Feb 24, 2010 at 05:56:46PM +0100, Jan Kara wrote: >> OK, I see that in theory a process can open file for writing after >> fs_may_remount_ro() before MS_RDONLY flag gets set. That could be really >> nasty. > > Not just in theory, but also in practice. We can easily hit this under > load with XFS. > >> But by no means we should solve this VFS problem by spilling error >> messages from the filesystem. > > Exactly. > >> Al, Christoph, do I miss something or there is really nothing which >> prevents a process from opening a file after the fs_may_remount_ro() check >> in do_remount_sb()? > > No, there is nothing. We really do need a multi-stage remount read-only > process: > > 1) stop any writes from userland, that is opening new files writeable This is not quite good idea because sync may take really long time, #fsstress -p32 -d /mnt/TEST -l9999999 -n99999999 -z -f creat=100 -f write=100 #sleep 60; #killall -9 fsstress #time mount mnt -oremount,ro it take several minutes to complete. And at the end it may fail but other reason. > 2) stop any periodic writeback from the VM or filesystem-internal > 3) write out all filesystem data and metadata > 4) mark the filesystem fully read-only I've tried to sole the issue in lightly another way Please take a look on this http://marc.info/?l=linux-fsdevel&m=126723036525624&w=2 1) Mark fs as GOING_TO_REMOUNT 2) any new writer will clear this flag This allow us to not block 3) check flag before fssync and after and return EBUSY in this case. 4) At this time we may to block writers (this is absent in my patch) It is acceptable to block writers at this time because later stages doesn't take too long. 5) perform fs-specific remount method. 6) Marks filesystem as MS_RDONLY. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
