Re: Unable to allocate for space usage in particular btrfs volume

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]

On 2015-11-06 15:15, Calvin Walton wrote:
> On Thu, 2015-11-05 at 10:44 +0000, OmegaPhil wrote:
>> On 05/11/15 04:18, Duncan wrote:
>>> OmegaPhil posted on Wed, 04 Nov 2015 21:53:09 +0000 as excerpted:
>>> VM image files (and large database files, for the same reason) are
>>> a bit
>>> of a problem on btrfs, and indeed, any COW-based filesystem, since
>>> the
>>> random rewrite pattern matching that use-case is pretty much the
>>> absolute
>>> worst-case match for a COW-based filesystem there is.
>>> Since you're not doing snapshotting (which conflicts with this
>>> option,
>>> with an imperfect workaround), setting nocow on those files may
>>> well
>>> eliminate the problem, but be aware if you aren't already that (1)
>>> nocow
>>> does turn off checksumming as well, in ordered to avoid a race that
>>> could
>>> easily lead to data corruption, and (2) you can't just activate
>
>> So a couple of gig still unaccountable but irrelevant. Thanks,
>> problem
>> solved! Although hopefully checksumming will be allowed on nocow
>> files
>> in the future as thats currently 17% of all data unprotected and will
>> get worse...
>
> There's actually an interesting workaround to this: Although the VM
> disk images aren't checksummed on the host filesystem, you can use
> btrfs *inside* the VMs and enable checksumming there. The downside is
> that you can only verify the VM data by booting the VM and running a
> scrub from inside.
Actually, by using a combination of loop devices and kpartx, it's fully 
possible to mount the FS and verify it without booting the VM.  Of 
course, doing this usually requires root access on the host system, but 
for most people I know, that's usually not an issue.  I do this on 
occasion when I need to pull a file off of one of my VM disks on my 
laptop and don't have the time to spin up the VM itself.

Another option if you're doing a direct boot of the kernel (for example, 
when using a fully paravirtualized domain on Xen, or using some of the 
QEMU ARM systems) is to just do the volume management (partitioning and 
such) on the host, and expose each filesystem to the guest as a separate 
disk.  I do this with most of my Linux VM's on my Xen system where I use 
LVM as the back-end storage for the virtual disk images, as it allows me 
to easily directly mount the VM's filesystems on the host if need be 
(and let's you do all kinds of cool things like using a cluster-aware 
filesystem for the VM's root so that you can mount it from the host 
safely while the VM is still online).



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]