Re: [PATCH] vfs: introduce FS_IOC_SYNCFS to sync a single super

On Thu, 26 Aug 2010, Andrew Morton wrote:

On Mon, 9 Aug 2010 07:33:57 -0700 (PDT)
Sage Weil [off-list ref] wrote:

quoted

Currently the only way to sync a single super_block (and not all of them 
via sync(2)) is via the BLKFLSBUF ioctl on the block device.  That also 
invalidates the bdev mapping, which isn't usually desireable

Actually you can do

	mount -o remount /dev/whatever

and it will sync the fs and retain caches.

quoted

and it 
doesn't work for non-block file systems.

And I guess remount will do that also.

Good to know.

quoted

 The ability to sync a single 
mount can be useful for both applications and administrators (e.g., when 
other mounts on the system are hung).

Introduce a simple ioctl to sync the super associated with an open file.
Pass any error returned by sync_filesystem() back to the user.

The changelog forgot to tell us why this is a useful thing to add. 
What is the use-case?

Two use cases:

 * An admin who wants to sync only one mount (e.g., 'sync /mnt/foo').  
I tend to need this on boxes with lots of NFS mounts where something gets 
hung up, I want to reboot, but want to make sure my local fs is synced 
first.  The remount trick handles this, although I doubt many are aware of 
that side-effect, and I'm not sure we should suggest they rely on it.

 * My use case is the Ceph storage daemon, which writes gobs of stuff to a 
single super and periodically wants to make sure it's synced so that it's 
application-level journal can be trimmed.  fsync() on individual files 
isn't practical (leads to bad IO patterns, ).  Ideally, this should 
be usable by a non-privileged user (just like sync(2)).

quoted

---
 fs/ioctl.c         |    9 +++++++++
 include/linux/fs.h |    1 +
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/fs/ioctl.c b/fs/ioctl.c
index 2d140a7..2aabb19 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c

@@ -593,6 +593,15 @@ int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd,
    case FS_IOC_FIEMAP:
            return ioctl_fiemap(filp, arg);

+   case FS_IOC_SYNCFS:
+   {
+           struct super_block *sb = filp->f_dentry->d_sb;
+           down_read(&sb->s_umount);
+           error = sync_filesystem(sb);
+           up_read(&sb->s_umount);
+           break;
+   }
+

`mount -o remount' is surely a Linux-specific side-effect and there's
really no guarantee that Linux will always retain that side-effect. 
OTOH FS_IOC_SYNCFS is linux-specific.

The key difference I see is that mount -o remount is root-only, whereas 
sync(2) and FS_IOC_SYNCFS are not.  Also, it seems like a bad idea for 
applications to rely on the current remount side effect, particularly for 
something as important as data integrity.

If we're going to add something like this then it will need to be
documented in manpages.  Supposedly, a cc to linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
will help make all that happen, but I'm not sure who if anyone is
answering the phone over there?

Where would this go in manpages?  ioctl_list(2)?  I'm happy to prepare a 
patch for that as well.

Thanks!
sage