Skip to content
  • Sage Weil's avatar
    introduce sys_syncfs to sync a single file system · b7ed78f5
    Sage Weil authored
    It is frequently useful to sync a single file system, instead of all
    mounted file systems via sync(2):
    
     - On machines with many mounts, it is not at all uncommon for some of
       them to hang (e.g. unresponsive NFS server).  sync(2) will get stuck on
       those and may never get to the one you do care about (e.g., /).
     - Some applications write lots of data to the file system and then
       want to make sure it is flushed to disk.  Calling fsync(2) on each
       file introduces unnecessary ordering constraints that result in a large
       amount of sub-optimal writeback/flush/commit behavior by the file
       system.
    
    There are currently two ways (that I know of) to sync a single super_block:
    
     - BLKFLSBUF ioctl on the block device: That also invalidates the bdev
       mapping, which isn't usually desirable, and doesn't work for non-block
       file systems.
     - 'mount -o remount,rw' will call sync_filesystem as an artifact of the
       current implemention.  Relying on this little-known side effect for
       something like data safety sounds foolish.
    
    Both of these approaches require root privileges, which some applications
    do not have (nor should they need?) given that sync(2) is an unprivileged
    operation.
    
    This patch introduces a new system call syncfs(2) that takes an fd and
    syncs only the file system it references.  Maybe someday we can
    
     $ sync /some/path
    
    and not get
    
     sync: ignoring all arguments
    
    The syscall is motivated by comments by Al and Christoph at the last LSF.
    syncfs(2) seems like an appropriate name given statfs(2).
    
    A similar ioctl was also proposed a while back, see
    	http://marc.info/?l=linux-fsdevel&m=127970513829285&w=2
    
    
    
    Signed-off-by: default avatarSage Weil <sage@newdream.net>
    Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    b7ed78f5