Commit 8dff9c85 authored Sep 19, 2015 by Chris Mason

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>

parent f881dd29

fs/btrfs/inode.c

+12 −1

Original line number	Diff line number	Diff line
		@@ -6979,7 +6979,18 @@ insert:
		* existing will always be non-NULL, since there must be
		* extent causing the -EEXIST.
		*/
		if (start >= extent_map_end(existing) \|\|
		if (existing->start == em->start &&
		extent_map_end(existing) == extent_map_end(em) &&
		em->block_start == existing->block_start) {
		/*
		* these two extents are the same, it happens
		* with inlines especially
		*/
		free_extent_map(em);
		em = existing;
		err = 0;

		} else if (start >= extent_map_end(existing) \|\|
		start <= existing->start) {
		/*
		* The existing extent map is the one nearest to

Admin message