• Filipe Manana's avatar
    Btrfs: fix fsync data loss after a ranged fsync · 49dae1bc
    Filipe Manana authored
    While we're doing a full fsync (when the inode has the flag
    BTRFS_INODE_NEEDS_FULL_SYNC set) that is ranged too (covers only a
    portion of the file), we might have ordered operations that are started
    before or while we're logging the inode and that fall outside the fsync
    range.
    
    Therefore when a full ranged fsync finishes don't remove every extent
    map from the list of modified extent maps - as for some of them, that
    fall outside our fsync range, their respective ordered operation hasn't
    finished yet, meaning the corresponding file extent item wasn't inserted
    into the fs/subvol tree yet and therefore we didn't log it, and we must
    let the next fast fsync (one that checks only the modified list) see this
    extent map and log a matching file extent item to the log btree and wait
    for its ordered operation to finish (if it's still ongoing).
    
    A test case for xfstests follows.
    Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
    Signed-off-by: default avatarChris Mason <clm@fb.com>
    49dae1bc
tree-log.c 118 KB