Re: chattr +C on subvolume

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

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

On 2015-08-18 13:36, Timothy Normand Miller wrote:
> Maybe this is a dumb question, but there are always corner cases.
>
> I have a subvolume where I want to disable CoW for VM disks.  Maybe
> that's a dumb idea, but that's a recommendation I've seen here and
> there.  Now, in the docs I've seen, +C applies to a directory.  Does
> it apply to subvolumes?  And do I apply it to the subvolume within the
> main volume, or do I apply it to the mount point where I've mounted
> the subvolume separately?  Are there any cases where the flag applies
> or not depending on how you access the files?
>
> The same subvolume for me is accessible via /mnt/btrfs/vms (via the
> /mnt/btrfs mount point) and /mnt/vms (where the subvolume is mounted).
> I applied +C to /mnt/btrfs/vms.  So what I'm trying to find out is if
> it also applies when files are accessed via /mnt/vms.
>
> Thanks.
>
>
In theory, barring any undiscovered corner cases, yes that will work the 
way you want it to (assuming that I'm interpreting how you want it to 
work correctly).  As of right now, attributes changed via chattr on 
subvolumes work just like on directories, so the NOCOW attribute will be 
inherited by the files created in that directory.

One more bit of advice that I don't see mentioned very often, if you 
have the space, you should pre-allocate the VM disk image files before 
using them (although make sure it's after the NOCOW attribute is set on 
them), as this will significantly reduce the degree of fragmentation. 
If you do decide to do so, fallocate is preferable to dd for this, as it 
works a lot faster.

Depending on your use case though, I'd almost suggest storing the disk 
images on another FS still (ext4 would be my recommendation), or if 
possible, directly on block devices (LVM would be my recommendation in 
this case, as it still provides the same data migration abilities as 
btrfs (albeit slightly more convoluted in some cases)).  Btrfs has very 
poor overall performance compared to most other Linux filesystems still 
(except on SSD's when TRIM is working properly, as the COW nature of 
btrfs actually helps with the wear-leveling), and this can significantly 
hurt VM performance.


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