On Thu, Mar 13, 2014 at 07:33:02PM -0500, Steve French wrote: > On Thu, Mar 13, 2014 at 9:20 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > Previously, the no-op "mount -o mount /dev/xxx" operation when the > > file system is already mounted read-write causes an implied, > > unconditional syncfs(). This seems pretty stupid, and it's certainly > > documented or guaraunteed to do this, nor is it particularly useful, > > except in the case where the file system was mounted rw and is getting > > remounted read-only. > > Is there a case where a file system, not mounted read-only, > would want to skip the syncfs on remount? I don't know > of any particular reason to do a syncfs on remount unless > caching behavior is changing (or moving to read-only mount), > but if as you say it is documented and guaranteed... If the file system is mounted read-write, and it is transitioning to read-only, i.e. "mount -o remount,ro /" then you do want to write out all dirty data before you transition it to be read-only (otherwise you would lose data). It is my belief that this is the _only_ data integrity issue which is implied by remount (and this is more about not losing work done by previous system calls). The background reason for this commit is that a user complained on the ext4 list that he is using containers in a virtualization environment, and due to the init scripts which the user doesn't want to change, it is causing gazillions of no-op remounts, and this is causing ext4 (and xfs) to do send CACHE FLUSH commands because it is required by the syncfs(2) system call, which also calls sync_filesystem. These CACHE FLUSH commands are unneeded for anything, especially for these no-op remounts, and so I want them to go away for remounts, but they should still be there in response to syncfs(2) requests. Cheers, - Ted _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
