On Wed, Jul 18, 2018 at 11:06 AM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote: > On 2018-07-18 13:04, Chris Murphy wrote: >> >> On Wed, Jul 18, 2018 at 7:30 AM, Austin S. Hemmelgarn >> <ahferro...@gmail.com> wrote: >> >>> >>> I'm not sure. In this particular case, this will fail on BTRFS for any X >>> larger than just short of one third of the total free space. I would >>> expect >>> it to fail for any X larger than just short of half instead. >> >> >> I'm confused. I can't get it to fail when X is 3/4 of free space. >> >> lvcreate -V 2g -T vg/thintastic -n btrfstest >> mkfs.btrfs -M /dev/mapper/vg-btrfstest >> mount /dev/mapper/vg-btrfstest /mnt/btrfs >> cd /mnt/btrfs >> fallocate -l 1500m tmp >> dd if=/dev/zero of=/mnt/btrfs/tmp bs=1M count=1450 >> >> Succeeds. No enospc. This is on kernel 4.17.6. > > Odd, I could have sworn it would fail reliably. Unless something has > changed since I last tested though, doing it with X equal to the free space > on the filesystem will fail.
OK well X is being defined twice here so I can't tell if I'm doing this correctly. There's fallocate X and that's 75% of free space for the empty fs at the time of fallocate. And then there's dd which is 1450m which is ~2.67x the free space at the time of dd. I don't know for sure, but based on the addresses reported before and after dd for the fallocated tmp file, it looks like Btrfs is not using the originally fallocated addresses for dd. So maybe it is COWing into new blocks, but is just as quickly deallocating the fallocated blocks as it goes, and hence doesn't end up in enospc? -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
