On 5/28/19 8:42 AM, [email protected] wrote:
On Saturday, May 25, 2019 at 2:28:13 PM UTC-4, Chris Laprise wrote:
I think the only _good_ way to deal with COW metadata expansion, since
its always related to data fragmentation, is to keep expanding it and
let system performance degrade accordingly.
Yup.
One could argue that the same solution could be *actively* applied to prevent
running out of free space. :) My recollection is that my old Drobo used to do
this (for free space, though presumably both).
It would not be too presumptuous for Qubes to define thin lvm metadata
as being in the same class as, say, filesystem metadata and let the
system consume available vg space as needed. The best way to start this
process is to lay down a rule saying you should only create/use one thin
pool per volume group on a Qubes system. If the vg is dedicated to
housing the one pool, then the gnarly questions around competing for
storage space disappear.
There is already an implicit policy that the user has to keep their eye
on overall used space in the pool because of over-provisioning. Just
extend that policy to 'volume group' and you can keep expanding tmeta
automatically.
The best possible (or at least better) implementation of this is to have
a hook in lvm block layer itself that can briefly halt file operations
while tmeta is expanded.
This simply makes
de-fragmentation maintenance issue (defrag to shrink metadata and get
performance back). This is what Microsoft did with NTFS and it was the
right choice; clinging to fixed metadata sizes is merely a state of
denial that leads to peoples' disks suddenly becoming unusable.
Lack of COW aside, NTFS's odd "separation plus mixing" of storage and metadata
is fascinating. I mean, it works! And works pretty well! And is ancient!
In my view, NTFS has "COW++". Shouldn't we in Unix land change our
terminology and start calling the combination of COW and snapshots....
shadow copy? :)
It *does* keep you on your toes, though, mitigating for forensics..."NTFS: oh, you
have a small file? Well, I'll just store that over here in the metadata stream. You want
to delete it? Sure, I'll mark it deleted. Erasing free space? go right ahead, I'll be
over here waiting. Oh, it's still here? Well...better talk to Mr. Russinovich if you want
to figure out how to really destroy that file..."*
-Brendan
* upon review, I read that in the Q voice, for maximum nerdiness.
--
Chris Laprise, [email protected]
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/f6618f4d-e9f4-fac7-3ba6-136369e73305%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
