Commit 25a50341 authored Oct 14, 2013 by Josef Bacik Committed by Chris Mason Nov 11, 2013

Btrfs: handle a missing extent for the first file extent

While trying to kill our hole extents I noticed I was seeing problems where we
seek into a file and then start writing and then try to fiemap that file later.
This is because we search for offset 0, don't find anything and so back up one
slot, which puts us at the inode ref or something like that, which means we goto
not_found and create an extent map for our entire search area. This isn't quite
what we want, we want to move forward one slot and see if there is an extent
there so we can limit our hole extent. This patch fixes this problem, I will
add a testcase for this as well. Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>

parent 96192499

fs/btrfs/inode.c

+9 −2

Original line number	Diff line number	Diff line
		@@ -5982,7 +5982,14 @@ again:
		found_type = btrfs_key_type(&found_key);
		if (found_key.objectid != objectid \|\|
		found_type != BTRFS_EXTENT_DATA_KEY) {
		goto not_found;
		/*
		* If we backup past the first extent we want to move forward
		* and see if there is an extent in front of us, otherwise we'll
		* say there is a hole for our whole search range which can
		* cause problems.
		*/
		extent_end = start;
		goto next;
		}

		found_type = btrfs_file_extent_type(leaf, item);
		@@ -5997,7 +6004,7 @@ again:
		size = btrfs_file_extent_inline_len(leaf, item);
		extent_end = ALIGN(extent_start + size, root->sectorsize);
		}

		next:
		if (start >= extent_end) {
		path->slots[0]++;
		if (path->slots[0] >= btrfs_header_nritems(leaf)) {

Admin message