]> git.hungrycats.org Git - linux/commit
Btrfs: deal with duplciates during extent_map insertion in btrfs_get_extent
authorChris Mason <clm@fb.com>
Sat, 19 Sep 2015 18:28:25 +0000 (11:28 -0700)
committerZygo Blaxell <zblaxell@waya.furryterror.org>
Wed, 17 Aug 2016 02:38:17 +0000 (22:38 -0400)
commit1248065dfe76dbada42d47268a0bf34613c8eaaa
tree42fa1b43f6740caaee9b2ee673a48409e48c9093
parentc4ffe3772d96380da544207f8521da3fccdbb9e8
Btrfs: deal with duplciates during extent_map insertion in btrfs_get_extent

When dealing with inline extents, btrfs_get_extent will incorrectly try
to insert a duplicate extent_map.  The dup hits -EEXIST from
add_extent_map, but then we try to merge with the existing one and end
up trying to insert a zero length extent_map.

This actually works most of the time, except when there are extent maps
past the end of the inline extent.  rocksdb will trigger this sometimes
because it preallocates an extent and then truncates down.

Josef made a script to trigger with xfs_io:

#!/bin/bash

xfs_io -f -c "pwrite 0 1000" inline
xfs_io -c "falloc -k 4k 1M" inline
xfs_io -c "pread 0 1000" -c "fadvise -d 0 1000" -c "pread 0 1000" inline
xfs_io -c "fadvise -d 0 1000" inline
cat inline

You'll get EIOs trying to read inline after this because add_extent_map
is returning EEXIST

Signed-off-by: Chris Mason <clm@fb.com>
(cherry picked from commit 8dff9c85341032767d7b519217a79ea04cd676b0)
fs/btrfs/inode.c