• J
    Btrfs: fix bad extent logging · 09a2a8f9
    Josef Bacik 提交于
    A user sent me a btrfs-image of a file system that was panicing on mount during
    the log recovery.  I had originally thought these problems were from a bug in
    the free space cache code, but that was just a symptom of the problem.  The
    problem is if your application does something like this
    
    [prealloc][prealloc][prealloc]
    
    the internal extent maps will merge those all together into one extent map, even
    though on disk they are 3 separate extents.  So if you go to write into one of
    these ranges the extent map will be right since we use the physical extent when
    doing the write, but when we log the extents they will use the wrong sizes for
    the remainder prealloc space.  If this doesn't happen to trip up the free space
    cache (which it won't in a lot of cases) then you will get bogus entries in your
    extent tree which will screw stuff up later.  The data and such will still work,
    but everything else is broken.  This patch fixes this by not allowing extents
    that are on the modified list to be merged.  This has the side effect that we
    are no longer adding everything to the modified list all the time, which means
    we now have to call btrfs_drop_extents every time we log an extent into the
    tree.  So this allows me to drop all this speciality code I was using to get
    around calling btrfs_drop_extents.  With this patch the testcase I've created no
    longer creates a bogus file system after replaying the log.  Thanks,
    Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
    09a2a8f9
extent_map.h 2.1 KB