Re: DUP dev_extent might overlap something next to it

[Hans van Kranenburg <hans.van.kranenburg@mendix.com>]

On 09/25/2018 02:05 AM, Hans van Kranenburg wrote:
> (I'm using v4.19-rc5 code here.)
> 
> Imagine allocating a DATA|DUP chunk.
> 
> [blub, see previous message]

Steps to reproduce DUP chunk beyond end of device:

First create a 6302M block device and fill it up.

mkdir bork
cd bork
dd if=/dev/zero of=image bs=1 count=0 seek=6302M
mkfs.btrfs -d dup -m dup image
losetup -f image
mkdir mountpoint
mount -o space_cache=v2 /dev/loop0 mountpoint
cp -a /usr mountpoint

After a while, this starts throwing: No space left on device

Now we extend the size of the image to 7880MiB so that the next dup data
chunk allocation will exactly try to use the 1578MiB free raw disk space
to trigger the bug.

dd if=/dev/zero of=image bs=1 count=0 seek=7880M
losetup -c /dev/loop0
btrfs fi resize max mountpoint/

Now we trigger the new DUP data chunk allocation:

cp /vmlinuz mountpoint/

Now I have a dev extent starting at 7446986752 on devid 1, with length
838860800. This means it ends at 8285847552, which is 7902, exactly
22MiB beyond the size of the device.

The only nice thing about this is that df shows me I still have more
than 8 exabyte of space in this image file.

Label: none  uuid: e711eea6-5332-44cf-9704-998a7a939970
	Total devices 1 FS bytes used 2.81GiB
	devid    1 size 7.70GiB used 7.72GiB path /dev/loop0

I didn't try filling it up and see what happens yet. Also, this can
probably done with a DUP chunk, but it's a bit harder to quickly prove.
And making this happen in the middle of a block device instead of at the
end is also a bit harder.

-- 
Hans van Kranenburg