> > This is just a hunch, but maybe the handling of spare files (such as > .vdi) is not ideal or not what we're used to with extN. Normally > "skipped" blocks do not count towards the disk full size, but given > btrfs' nature they may count as a reservation that would certainly > cause an early ENOSPC. >
I don't think this is the case, since my .vdi is a dynamically expanding file, and isn't a sparse file that wants to reserve more space than it actually is taking up. So the vdi file is reported to be 5G by du, and it is indeed taking up 5G (and not 3G). > You can try to narrow down the problem using qemu-img or dd. Example: > > qemu-img create -f raw test.img 16G > > See if it counts towards the disk fill count and ENOSPC threshold. See > if it even completes at all :P > I tried a test like this for kicks after deleting my vdi file. I tried a while loop: while [ 1 ]; dd if=/dev/zero of=file.`date +%s` count=2097152; done My machine subsequently froze. Repeating the experiment unvieled that eventually the system get stuck on pdflush taking up 100% CPU. At this point, I had to turn off my laptop, as a soft reset was not possible, even with a "halt" command. At this point I'm wondering if this is a anomaly or if it has anything to do with using an SSD. It seems the pre-2.7.29-rc7 code had a hard stop at 85%. But the recent patch doesn't seem to have solve the issue for me. Is there another issue that makes btrfs want to reserve 2G free? I see another email with someone growing their filesystem from 48G to 70G because they ran out of space on their 50G disk, which should still have 2G free. -- 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
