Re: btrfs

[Christoph Anton Mitterer <calestyo@scientia.net>]

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

On Sun, 2016-06-05 at 22:39 +0200, Henk Slager wrote:
> > So the point I'm trying to make:
> > People do probably not care so much whether their VM image/etc. is
> > COWed or not, snapshots/etc. still work with that,... but they may
> > likely care if the integrity feature is lost.
> > So IMHO, nodatacow + checksumming deserves to be amongst the top
> > priorities.
> Have you tried blockdevice/HDD caching like bcache or dmcache in
> combination with VMs on BTRFS?
No yet,... my personal use case is just some VMs on the notebook, and
for this, the above would seem a bit overkill.
For the larger VM cluster at the institute,... puh to be honest I don't
know by hard what we do there.


>   Or ZVOL for VMs in ZFS with L2ARC?
Well but all this is an alternative solution,...


> I assume the primary reason for wanting nodatacow + checksumming is
> to
> avoid long seektimes on HDDs due to growing fragmentation of the VM
> images over time.
Well the primary reason is wanting to have overall checksumming in the
fs, regardless of which features one uses.

I think we already have some situations where tools use/set btrfs
features by themselves (i.e. automatically)... wasn't systemd creating
subvols per default in some locations, when there's btrfs?
So it's no big step to postgresql/etc. setting nodatacow, making people
loose integrity without them even knowing.


Of course, avoiding the fragmentation is the reason for the desire to
have nodatacow.


>  But even if you have nodatacow + checksumming
> implemented, it is then still HDD access and a VM imagefile itself is
> not guaranteed to be continuous.
Uhm... sure, but that's no difference to other filesystems?!


> It is clear that for VM images the amount of extents will be large
> over time (like 50k or so, autodefrag on),
Wasn't it said, that autodefrag performs bad for anything larger than
~1G?


>  but with a modern SSD used
> as cache, it doesn't matter. It is still way faster than just HDD(s),
> even with freshly copied image with <100 extents.
Well the fragmentation has also many other consequences and not just
seeks (assuming everyone would use SSDs, which is and probably won't be
the case for quite a while).
Most obviously you get much more IOPS and btrfs itself will, AFAIU,
also suffer from some issues due to the fragmentation.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]