)]}'
{
  "commit": "2daea67e966dc0c42067ebea015ddac6834cef88",
  "tree": "0adef51c45c7dd31062824eb3ba102a349966608",
  "parents": [
    "18f2ee705d98034b0f229a3202d827468d4bffd9"
  ],
  "author": {
    "name": "Christoph Hellwig",
    "email": "hch@lst.de",
    "time": "Thu Sep 03 12:39:39 2009 +0200"
  },
  "committer": {
    "name": "Jan Kara",
    "email": "jack@suse.cz",
    "time": "Mon Sep 14 17:08:17 2009 +0200"
  },
  "message": "fsync: wait for data writeout completion before calling -\u003efsync\n\nCurrenly vfs_fsync(_range) first calls filemap_fdatawrite to write out\nthe data, the calls into -\u003efsync to write out the metadata and then finally\ncalls filemap_fdatawait to wait for the data I/O to complete.  What sounds\nlike a clever micro-optimization actually is nast trap for many filesystems.\n\nFor many modern filesystems i_size or other inode information is only\nupdated on I/O completion and we need to wait for I/O to finish before\nwe can write out the metadata.  For old fashionen filesystems that\ninstanciate blocks during the actual write and also update the metadata\nat that point it opens up a large window were we could expose uninitialized\nblocks after a crash.  While a few filesystems that need it already wait\nfor the I/O to finish inside their -\u003efsync methods it is rather suboptimal\nas it is done under the i_mutex and also always for the whole file instead\nof just a part as we could do for O_SYNC handling.\n\nHere is a small audit of all fsync instances in the tree:\n\n - spufs_mfc_fsync:\n - ps3flash_fsync:\n - vol_cdev_fsync:\n - printer_fsync:\n - fb_deferred_io_fsync:\n - bad_file_fsync:\n - simple_sync_file:\n\n\tdon\u0027t care - filesystems/drivers do\u0027t use the page cache or are\n\tpurely in-memory.\n\n - simple_fsync:\n - file_fsync:\n - affs_file_fsync:\n - fat_file_fsync:\n - jfs_fsync:\n - ubifs_fsync:\n - reiserfs_dir_fsync:\n - reiserfs_sync_file:\n\n\tnever touch pagecache themselves.  We need to wait before if we do\n\tnot want to expose stale data after an allocation.\n\n - afs_fsync:\n - fuse_fsync_common:\n\n\tdo the waiting writeback itself in awkward ways, would benefit from\n\tproper semantics\n\n - block_fsync:\n\n\tDoes a filemap_write_and_wait on the block device inode.  Because we\n\tnow have f_mapping that is the same inode we call it on in vfs_fsync.\n\tSo just removing it and letting the VFS do the work in one go would\n\tbe an improvement.\n\n - btrfs_sync_file:\n - cifs_fsync:\n - xfs_file_fsync:\n\n\tneed the wait first and currently do it themselves. would benefit from\n\tdoing it outside i_mutex.\n\n - coda_fsync:\n - ecryptfs_fsync:\n - exofs_file_fsync:\n - shm_fsync:\n\n\tonly passes the fsync through to the lower layer\n\n - ext3_sync_file:\n\n\tdoesn\u0027t seem to care, comments are confusing.\n\n - ext4_sync_file:\n\n\twould need the wait to work correctly for delalloc mode with late\n\ti_size updates.  Otherwise the ext3 comment applies.\n\n\tcurrently implemens it\u0027s own writeback and wait in an odd way,\n\tcould benefit from doing it properly.\n\n - gfs2_fsync:\n\n\tnot needed for journaled data mode, but probably harmless there.\n\tCurrently writes back data asynchronously itself.  Needs some\n\tmajor audit.\n\n - hostfs_fsync:\n\n\tjust calls fsync/datasync on the host FD.  Without the wait before\n\tdata might not even be inflight yet if we\u0027re unlucky.\n\n - hpfs_file_fsync:\n - ncp_fsync:\n\n\tno-ops.  Dangerous before and after.\n\n - jffs2_fsync:\n\n\tjust calls jffs2_flush_wbuf_gc, not sure how this relates to data.\n\n - nfs_fsync_dir:\n\n\tjust increments stats, claims all directory operations are synchronous\n\n - nfs_file_fsync:\n\n\tonly writes out data???  Looks very odd.\n\n - nilfs_sync_file:\n\n\tlooks like it expects all data done, but not sure from the code\n\n - ntfs_dir_fsync:\n - ntfs_file_fsync:\n\n\tappear to do their own data writeback.  Very convoluted code.\n\n - ocfs2_sync_file:\n\n\tdoes it\u0027s own data writeback, but no wait.  probably needs the wait.\n\n - smb_fsync:\n\n\taccording to a comment expects all pages written already, probably needs\n\tthe wait before.\n\nThis patch only changes vfs_fsync_range, removal of the wait in the methods\nthat have it is left to the filesystem maintainers.  Note that most\nfilesystems really do need an audit for their fsync methods given the\ngems found in this very brief audit.\n\nSigned-off-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Jan Kara \u003cjack@suse.cz\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "4e15da01923c0e6eb5480117886022b75a6133bb",
      "old_mode": 33188,
      "old_path": "fs/sync.c",
      "new_id": "192340930bb477f506eeee2eb132db06a1a6309f",
      "new_mode": 33188,
      "new_path": "fs/sync.c"
    }
  ]
}