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
