• Chris Mason's avatar
    Btrfs: add extra flushing for renames and truncates · 5a3f23d5
    Chris Mason authored
    Renames and truncates are both common ways to replace old data with new
    data.  The filesystem can make an effort to make sure the new data is
    on disk before actually replacing the old data.
    This is especially important for rename, which many application use as
    though it were atomic for both the data and the metadata involved.  The
    current btrfs code will happily replace a file that is fully on disk
    with one that was just created and still has pending IO.
    If we crash after transaction commit but before the IO is done, we'll end
    up replacing a good file with a zero length file.  The solution used
    here is to create a list of inodes that need special ordering and force
    them to disk before the commit is done.  This is similar to the
    ext3 style data=ordering, except it is only done on selected files.
    Btrfs is able to get away with this because it does not wait on commits
    very often, even for fsync (which use a sub-commit).
    For renames, we order the file when it wasn't already
    on disk and when it is replacing an existing file.  Larger files
    are sent to filemap_flush right away (before the transaction handle is
    For truncates, we order if the file goes from non-zero size down to
    zero size.  This is a little different, because at the time of the
    truncate the file has no dirty bytes to order.  But, we flag the inode
    so that it is added to the ordered list on close (via release method).  We
    also immediately add it to the ordered list of the current transaction
    so that we can try to flush down any writes the application sneaks in
    before commit.
    Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>