• Filipe Manana's avatar
    Btrfs: fix log tree corruption when fs mounted with -o discard · 372b2ac5
    Filipe Manana authored
    [ Upstream commit HEAD ]
    
    commit dcc82f47 upstream.
    
    While committing a transaction we free the log roots before we write the
    new super block. Freeing the log roots implies marking the disk location
    of every node/leaf (metadata extent) as pinned before the new super block
    is written. This is to prevent the disk location of log metadata extents
    from being reused before the new super block is written, otherwise we
    would have a corrupted log tree if before the new super block is written
    a crash/reboot happens and the location of any log tree metadata extent
    ended up being reused and rewritten.
    
    Even though we pinned the log tree's metadata extents, we were issuing a
    discard against them if the fs was mounted with the -o discard option,
    resulting in corruption of the log tree if a crash/reboot happened before
    writing the new super block - the next time the fs was mounted, during
    the log replay process we would find nodes/leafs of the log btree with
    a content full of zeroes, causing the process to fail and require the
    use of the tool btrfs-zero-log to wipeout the log tree (and all data
    previously fsynced becoming lost forever).
    
    Fix this by not doing a discard when pinning an extent. The discard will
    be done later when it's safe (after the new super block is committed) at
    extent-tree.c:btrfs_finish_extent_commit().
    
    Fixes: e688b725 (Btrfs: fix extent pinning bugs in the tree log)
    Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
    Signed-off-by: default avatarChris Mason <clm@fb.com>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    (cherry picked from commit 3909e5a9)
    Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
    372b2ac5
extent-tree.c 257 KB