7:29 a.m.
I have a directory I use to hold a Windows VM disk image
(/home/Windows/...), and would like to snapshot it before playing with
the QEMU settings. However it's already part of the /home subvolume, so
is there a way of splitting it off on its own without having to create
a new subvolume and sending the contents over? AFAIK subvolumes can be
hierarchical so it would seem like a useful thing to be able to convert
a subtree without all the copying, but the man page doesn't seem to
address it.
poc
8:29 a.m.
Patrick O'Callaghan <pocallaghan(a)gmail.com> 于2020年12月23日周三 下午9:29写道：
I have a directory I use to hold a Windows VM disk image
(/home/Windows/...), and would like to snapshot it before playing with
the QEMU settings. However it's already part of the /home subvolume, so
is there a way of splitting it off on its own without having to create
a new subvolume and sending the contents over? AFAIK subvolumes can be
hierarchical so it would seem like a useful thing to be able to convert
a subtree without all the copying, but the man page doesn't seem to
address it.
You could create a subvolume, use cp --reflink=always to create a
reflink, and delete the old directory, this turns a directory into
subvolume easily without actual copying. But I don't suggest you do
so, since using snapshot/reflink on VM images will make it
Copy-on-Write, VM images should be nocow for performance.
But can anyone figure out if creating a reflink then removing old
references before any write to the file happens turns on CoW for the
file? I am not sure. But writing after snapshot definitely turns on
CoW.
>
> poc
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
5:01 p.m.
On Wed, 2020-12-23 at 22:29 +0800, Qiyu Yan wrote:
Patrick O'Callaghan <pocallaghan(a)gmail.com> 于2020年12月23日周三
下午9:29写道：
>
> I have a directory I use to hold a Windows VM disk image
> (/home/Windows/...), and would like to snapshot it before playing with
> the QEMU settings. However it's already part of the /home subvolume, so
> is there a way of splitting it off on its own without having to create
> a new subvolume and sending the contents over? AFAIK subvolumes can be
> hierarchical so it would seem like a useful thing to be able to convert
> a subtree without all the copying, but the man page doesn't seem to
> address it.
You could create a subvolume, use cp --reflink=always to create a
reflink, and delete the old directory, this turns a directory into
subvolume easily without actual copying. But I don't suggest you do
so, since using snapshot/reflink on VM images will make it
Copy-on-Write, VM images should be nocow for performance.
But can anyone figure out if creating a reflink then removing old
references before any write to the file happens turns on CoW for the
file? I am not sure. But writing after snapshot definitely turns on
CoW.
So, if I understand correctly, I can't in fact snapshot a VM without
incurring a COW penalty, independently of how I do it?
poc
9:17 p.m.
On Wed, Dec 23, 2020 at 4:02 PM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
On Wed, 2020-12-23 at 22:29 +0800, Qiyu Yan wrote:
> Patrick O'Callaghan <pocallaghan(a)gmail.com> 于2020年12月23日周三 下午9:29写道：
> >
> > I have a directory I use to hold a Windows VM disk image
> > (/home/Windows/...), and would like to snapshot it before playing with
> > the QEMU settings. However it's already part of the /home subvolume, so
> > is there a way of splitting it off on its own without having to create
> > a new subvolume and sending the contents over? AFAIK subvolumes can be
> > hierarchical so it would seem like a useful thing to be able to convert
> > a subtree without all the copying, but the man page doesn't seem to
> > address it.
>
> You could create a subvolume, use cp --reflink=always to create a
> reflink, and delete the old directory, this turns a directory into
> subvolume easily without actual copying. But I don't suggest you do
> so, since using snapshot/reflink on VM images will make it
> Copy-on-Write, VM images should be nocow for performance.
>
> But can anyone figure out if creating a reflink then removing old
> references before any write to the file happens turns on CoW for the
> file? I am not sure. But writing after snapshot definitely turns on
> CoW.
So, if I understand correctly, I can't in fact snapshot a VM without
incurring a COW penalty, independently of how I do it?
Yep. Whether Btrfs snapshot, reflink copy on either Btrfs or XFS, or
LVM thinp snapshot, or qcow2 snapshot/backing file, there is COW.
There's COW because the snapshot makes the data you've snapshot
shared. You've got two copies pointing to the same data blocks, i.e.
shared blocks or shared extents. Neither file exclusively owns those
blocks. Therefore any write to any block in either file *must* be COW.
Another way to consider copy on write is "no overwrites".
Some folks who haven't suffered these giant text walls of mine by now,
might like some animated pictures :D
https://github.com/knorrie/btrfs-heatmap
You can create your own too.
--
Chris Murphy
9:09 p.m.
On Wed, Dec 23, 2020 at 7:30 AM Qiyu Yan <yanqiyu(a)fedoraproject.org> wrote:
Patrick O'Callaghan <pocallaghan(a)gmail.com> 于2020年12月23日周三 下午9:29写道：
>
> I have a directory I use to hold a Windows VM disk image
> (/home/Windows/...), and would like to snapshot it before playing with
> the QEMU settings. However it's already part of the /home subvolume, so
> is there a way of splitting it off on its own without having to create
> a new subvolume and sending the contents over? AFAIK subvolumes can be
> hierarchical so it would seem like a useful thing to be able to convert
> a subtree without all the copying, but the man page doesn't seem to
> address it.
You could create a subvolume, use cp --reflink=always to create a
reflink, and delete the old directory, this turns a directory into
subvolume easily without actual copying. But I don't suggest you do
so, since using snapshot/reflink on VM images will make it
Copy-on-Write, VM images should be nocow for performance.
But can anyone figure out if creating a reflink then removing old
references before any write to the file happens turns on CoW for the
file? I am not sure. But writing after snapshot definitely turns on
CoW.
They are immediately marked as shared upon snapshot or reflink copy.
But if nothing writes to either file, there's no issue. Once you
delete the original file, the extents become exclusive to the new
file. And thuse nodatacow applies.
And it COWs only writes that are intended to overwrite a shared
extent. That results in COW of a new exclusive extent. Subsequent
writes to that file for that same block are nocow.
--
Chris Murphy
8:51 p.m.
(I did read the whole thread but I'm gonna reply three times anyway :D)
On Wed, Dec 23, 2020 at 6:29 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
I have a directory I use to hold a Windows VM disk image
(/home/Windows/...), and would like to snapshot it before playing with
the QEMU settings. However it's already part of the /home subvolume, so
is there a way of splitting it off on its own without having to create
a new subvolume and sending the contents over? AFAIK subvolumes can be
hierarchical so it would seem like a useful thing to be able to convert
a subtree without all the copying, but the man page doesn't seem to
address it.
Direct answer:
cd /home
btrfs subvolume create Windows2
chattr +C Windows2
cp Windows/* Windows2/
rm -rf Windows
mv Windows2 Windows
Explanation:
The logic of this is to set the nodatacow attribute on Windows2, which
then means overwrites by the guest will overwrite those same areas in
the file, rather than COW. There's no direct COW penalty per se, it's
just a redirection. The issue is it can result in fragmentation and
that'll make subsequent reads slower due to having to seek for that
fragment. It's a bigger problem on rotational drives, the seek latency
is high and so is rotational latency. For all the libvirt locations,
this is done for you on default clean Btrfs installs, when the pool
(directory) is activated. Includes: virt-manager, gnome-boxes,
cockpit.
mv will fail between destinations with different nodatacow settings,
hence cp. If the source and destination can support reflink copy, then
reflink copy is used by default starting with Fedora 33 on both Btrfs
and XFS. Note that reflink copies cannot cross mount points, that's a
VFS limitation. So what'll happen is, cp falls back to regular copy,
rather than being efficient.
The reason for making /home/Windows a subvolume in my opinion is not
to snapshot /home/Windows. But so you can snapshot /home and *exclude*
/home/Windows. Snapshots aren't recursive (for developers they can be,
see libbtrfsutil C API and Python bindings). So this keeps your VM
images nodatacow.
Instead what I do is "snapshot" the VM files by reflink copy within
their own directory. And yes they get quite a lot more fragmented.
cp win10.raw win10-updated.raw
Again, it's a reflink copy because (a) that's the cp default on F33
and (b) the source and destination files are going to be nodatacow
since we're staying in the same directory. So this cp is fast. And if
you 'du' the ../Windows directory it'll hilariously count these files
twice, but if you use 'btrfs fi du -s' you'll be introduced to some
new terminology: exclusive and shared data.
You might prefer doing snapshots the qcow2 way, although I have no
idea what "qemu-img snapshot" does because I've never used it. I've
only used "qemu-img create -b" to create a new qcow2 file that points
to the original as a backing file. Why? *shrug* I don't know. But I
throw it out there as an option.
Whether you use 'cp' to make a reflink copy (fast copy, efficient
copy) or you 'btrfs sub snap /home/Windows /home/Windows.20201223' or
however you want to name them, there is a gotcha. Those nodatacow
extents now *cannot* be overwritten because they've been snapshot.
They are now cow again for any writes that would be an overwrite. But
it's only a one time redirect. It'll COW a shared block to a new
location (exclusive block) and any subsequent changes for that block
will be nodatacow again... unless you make another snapshot.
So yeah, no free lunch. There's always a tradeoff. And that's why you
might consider a different way to preserve the images.
Windows NTFS in particular has fairly remarkable write patterns that
result in a lot of fragmentation on any file system. But it is
especially bad on Btrfs. I speculate that the dual journaling
technique it uses just ends up being turned into piles of "appends"
onto a sparse raw file if it's COW. Your best bet really is to
fallocate a raw file in a subvolume or directory with chattr +C set
and don't snapshot or reflink copy it. That's very much like what you
get with a raw file on XFS or ext4. And perhaps a tiny bit more
overhead than a conventional LVM LV, which is really your best bet if
performance is the top concern.
Another thing I use in virt-manager is cache mode unsafe. I can't
recommend it because, I mean, it's not safe. But it's a lot faster. So
if you don't care about your data, and I definitely don't, and you
care about performance, unsafe cache mode is awesome. And worth
finding another way to mitigate the possibility of guest writes
happening when power is yanked from the host and totally trashes the
guest's file system. (I have had it trash NTFS in this scenario; but
never once have I damaged Btrfs in such a guest. The unsafeness does
come from the host crashing, not the guest. You can probably get away
with force quitting the guest all you want. I do this all the time
because (a) I hate my data and (b) I'm impatient. :D But yeah I also
backup my data other ways so if it goes kaboom, it's actually fun
because I get to use my backups.
I am the reason for my backups...
--
Chris Murphy
9:24 p.m.
On Wed, Dec 23, 2020 at 7:51 PM Chris Murphy <lists(a)colorremedies.com> wrote:
mv will fail between destinations with different nodatacow settings,
hence cp.
Sorry. This is wrong. mv also works.
mv tries three things in order: rename, reflink copy, traditional
copy. In the above case, it's the last one that works.
Rename fails because subvolumes are separate name spaces with their
own pile of inodes, similar to (in this case) separate file systems.
The reflink copy also fails because there is a cow nodatacow mismatch
between source and destination. It's not possible to have shared
extents that are both cow and nodatacow, so the file must be old
fashioned copied, so it has exclusive extents that are nodatacow. (The
copy task, once complete, is followed by an rm of the original file.
Hence it looks like a move except, yeah, it's slow because it's a big
VM file being copied.)
--
Chris Murphy
5:23 a.m.
On Wed, 2020-12-23 at 19:51 -0700, Chris Murphy wrote:
(I did read the whole thread but I'm gonna reply three times
anyway :D)
On Wed, Dec 23, 2020 at 6:29 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
>
> I have a directory I use to hold a Windows VM disk image
> (/home/Windows/...), and would like to snapshot it before playing with
> the QEMU settings. However it's already part of the /home subvolume, so
> is there a way of splitting it off on its own without having to create
> a new subvolume and sending the contents over? AFAIK subvolumes can be
> hierarchical so it would seem like a useful thing to be able to convert
> a subtree without all the copying, but the man page doesn't seem to
> address it.
I'm going to take some time to digest the full answer, but I'll just
reply to this part for now:
Your best bet really is to
fallocate a raw file in a subvolume or directory with chattr +C set
and don't snapshot or reflink copy it.
The Windows image file is in fact just an fallocated file used as a raw
disk, not a qcow. It's on an SSD and seems quite fast, so I wouldn't
worry overmuch about fragmentation. This system is basically only used
for gaming with GPU passthrough so pretty much everything can be lost.
My interest in snapshotting it is just to avoid the pain of a misconfig
in QEMU, which is notoriously picky (lomng story short, I'm trying to
modify it to use a Q35 CPU instead of the basic i440). The VM was set
up on virt-manager when the filesystem was ext4, so it won't have any
of the special BTRFS stuff unless I add it myself.
Expect further questions later :-)
poc
3:27 p.m.
On Thu, Dec 24, 2020 at 4:23 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
The Windows image file is in fact just an fallocated file used as a raw
disk, not a qcow. It's on an SSD and seems quite fast, so I wouldn't
worry overmuch about fragmentation. This system is basically only used
for gaming with GPU passthrough so pretty much everything can be lost.
Latencies are much lower on SSD.
My interest in snapshotting it is just to avoid the pain of a
misconfig
in QEMU, which is notoriously picky (lomng story short, I'm trying to
modify it to use a Q35 CPU instead of the basic i440). The VM was set
up on virt-manager when the filesystem was ext4, so it won't have any
of the special BTRFS stuff unless I add it myself.
Note that the VM image file contains no VM settings. So a snapshot of
the VM image only helps you preserve/rollback to a previous state of
that image. The image contains only file systems. So if the idea is to
roll back the guest's file system, then you're on the right track. If
the idea is to be able to rever qemu configuration, you want something
else.
My advice is to use:
virsh dumpxml $vmname > $vmname.xml
You can then make modifications, and dump that out as a separate name,
and you can diff the xml files.
You can also create a new vm from this exported xml using
virsh create $vmname.xml
Note that the name of the VM is in this file, so if you want to create
a new VM you need to edit the xml file and change the name of the VM
so it gets created with a new name.
Expect further questions later :-)
Welcome!
--
Chris Murphy
4:34 p.m.
On Thu, 2020-12-24 at 14:27 -0700, Chris Murphy wrote:
On Thu, Dec 24, 2020 at 4:23 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
>
> The Windows image file is in fact just an fallocated file used as a raw
> disk, not a qcow. It's on an SSD and seems quite fast, so I wouldn't
> worry overmuch about fragmentation. This system is basically only used
> for gaming with GPU passthrough so pretty much everything can be lost.
Latencies are much lower on SSD.
> My interest in snapshotting it is just to avoid the pain of a misconfig
> in QEMU, which is notoriously picky (lomng story short, I'm trying to
> modify it to use a Q35 CPU instead of the basic i440). The VM was set
> up on virt-manager when the filesystem was ext4, so it won't have any
> of the special BTRFS stuff unless I add it myself.
Note that the VM image file contains no VM settings. So a snapshot of
the VM image only helps you preserve/rollback to a previous state of
that image. The image contains only file systems. So if the idea is to
roll back the guest's file system, then you're on the right track. If
the idea is to be able to rever qemu configuration, you want something
else.
Yes, good point.
My advice is to use:
virsh dumpxml $vmname > $vmname.xml
You can then make modifications, and dump that out as a separate name,
and you can diff the xml files.
You can also create a new vm from this exported xml using
virsh create $vmname.xml
Note that the name of the VM is in this file, so if you want to create
a new VM you need to edit the xml file and change the name of the VM
so it gets created with a new name.
Yes.
poc
4:59 p.m.
On Thu, 2020-12-24 at 14:27 -0700, Chris Murphy wrote:
You can also create a new vm from this exported xml using
virsh create $vmname.xml
Note that the name of the VM is in this file, so if you want to create
a new VM you need to edit the xml file and change the name of the VM
so it gets created with a new name.
Looks like you also have to change the UUID, or virsh will complain
that it already exists. Fortunately it's just a matter of running
uuidgen and plugging in the result. You also have to globally change
pci to pcie, but I already knew that.
This seems to have worked and I'm now running the new VM. Unfortunately
it still has crackly sound (I was hoping a change to the Q35 would
improve this), but that's a separate issue.
Thanks for your help Chris.
poc
5:26 p.m.
Two other ideas:
You could create an "original" copy of the VM that you never touch,
and then clone it to restore. What I don't know is whether clone
implies duplicating all the storage too. If so then you might want the
original to have no file set for the virtual drive.
I've gotten somewhat adept at fiddling with the xml using 'virsh edit
$vm' but there's a somewhat recent feature you can enable in
virt-manager to directly edit xml in virt-manager. For every device on
the left side UI, there's GUI configuration on the right side, but at
the top there's a tab to see the xml. You have to go dig in
virt-manager preferences to enable xml editing, otherwise you just get
to look at the xml, not change it. I've started doing this rather than
editing the xml directly via virsh edit.
--
Chris Murphy
6:29 a.m.
On Thu, 2020-12-24 at 16:26 -0700, Chris Murphy wrote:
Two other ideas:
You could create an "original" copy of the VM that you never touch,
and then clone it to restore. What I don't know is whether clone
implies duplicating all the storage too. If so then you might want the
original to have no file set for the virtual drive.
I've gotten somewhat adept at fiddling with the xml using 'virsh edit
$vm' but there's a somewhat recent feature you can enable in
virt-manager to directly edit xml in virt-manager. For every device on
the left side UI, there's GUI configuration on the right side, but at
the top there's a tab to see the xml. You have to go dig in
virt-manager preferences to enable xml editing, otherwise you just get
to look at the xml, not change it. I've started doing this rather than
editing the xml directly via virsh edit.
Yes, I've used that. My current difficulty (annoyance really) is that
having edited the xml file in a local directory, I can run it using
'virsh create ...' and it duly appears in the virt-manager panel.
However if I close virt-manager or end my login session it doesn't show
up on restarting and I have to do the 'virsh create' again. I can't
figure out how to actually install the new VM where virt-manager will
find it (having deleted the original one). I've had a look at virt-
clone but haven't managed to find right incantation yet.
poc
PS This is now fairly OT w.r.t. the thread subject, but I'm taking the
liberty of abusing your forbearance :-)
7:37 p.m.
On Sat, Dec 26, 2020 at 5:29 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
On Thu, 2020-12-24 at 16:26 -0700, Chris Murphy wrote:
> Two other ideas:
>
> You could create an "original" copy of the VM that you never touch,
> and then clone it to restore. What I don't know is whether clone
> implies duplicating all the storage too. If so then you might want the
> original to have no file set for the virtual drive.
>
> I've gotten somewhat adept at fiddling with the xml using 'virsh edit
> $vm' but there's a somewhat recent feature you can enable in
> virt-manager to directly edit xml in virt-manager. For every device on
> the left side UI, there's GUI configuration on the right side, but at
> the top there's a tab to see the xml. You have to go dig in
> virt-manager preferences to enable xml editing, otherwise you just get
> to look at the xml, not change it. I've started doing this rather than
> editing the xml directly via virsh edit.
Yes, I've used that. My current difficulty (annoyance really) is that
having edited the xml file in a local directory, I can run it using
'virsh create ...' and it duly appears in the virt-manager panel.
However if I close virt-manager or end my login session it doesn't show
up on restarting and I have to do the 'virsh create' again. I can't
figure out how to actually install the new VM where virt-manager will
find it (having deleted the original one). I've had a look at virt-
clone but haven't managed to find right incantation yet.
I'm not sure I know of an elegant way to do it but you could create a
new VM in virt-manager, then use 'virsh edit VM' to edit it, and copy
paste your backup xml into that edit window and save it. Viola. I know
it'll work cuz I've done it, but yeah something more elegant might be
nice.
--
Chris Murphy
8:59 p.m.
virsh define vm.xml
> On Dec 26, 2020, at 20:38, Chris Murphy <lists(a)colorremedies.com> wrote:
>
> On Sat, Dec 26, 2020 at 5:29 AM Patrick O'Callaghan
> <pocallaghan(a)gmail.com> wrote:
>>
>>> On Thu, 2020-12-24 at 16:26 -0700, Chris Murphy wrote:
>>> Two other ideas:
>>>
>>> You could create an "original" copy of the VM that you never
touch,
>>> and then clone it to restore. What I don't know is whether clone
>>> implies duplicating all the storage too. If so then you might want the
>>> original to have no file set for the virtual drive.
>>>
>>> I've gotten somewhat adept at fiddling with the xml using 'virsh
edit
>>> $vm' but there's a somewhat recent feature you can enable in
>>> virt-manager to directly edit xml in virt-manager. For every device on
>>> the left side UI, there's GUI configuration on the right side, but at
>>> the top there's a tab to see the xml. You have to go dig in
>>> virt-manager preferences to enable xml editing, otherwise you just get
>>> to look at the xml, not change it. I've started doing this rather than
>>> editing the xml directly via virsh edit.
>>
>> Yes, I've used that. My current difficulty (annoyance really) is that
>> having edited the xml file in a local directory, I can run it using
>> 'virsh create ...' and it duly appears in the virt-manager panel.
>> However if I close virt-manager or end my login session it doesn't show
>> up on restarting and I have to do the 'virsh create' again. I can't
>> figure out how to actually install the new VM where virt-manager will
>> find it (having deleted the original one). I've had a look at virt-
>> clone but haven't managed to find right incantation yet.
>
>
> I'm not sure I know of an elegant way to do it but you could create a
> new VM in virt-manager, then use 'virsh edit VM' to edit it, and copy
> paste your backup xml into that edit window and save it. Viola. I know
> it'll work cuz I've done it, but yeah something more elegant might be
> nice.
>
>
> --
> Chris Murphy
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
12:22 p.m.
On Thu, 24 Dec 2020, 8:22 am Chris Murphy, <lists(a)colorremedies.com> wrote:
(I did read the whole thread but I'm gonna reply three times
anyway :D)
On Wed, Dec 23, 2020 at 6:29 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
> I have a directory I use to hold a Windows VM disk image
> (/home/Windows/...), and would like to snapshot it before playing with
> the QEMU settings. However it's already part of the /home subvolume, so
> is there a way of splitting it off on its own without having to create
> a new subvolume and sending the contents over? AFAIK subvolumes can be
> hierarchical so it would seem like a useful thing to be able to convert
> a subtree without all the copying, but the man page doesn't seem to
> address it.
Direct answer:
cd /home
btrfs subvolume create Windows2
chattr +C Windows2
cp Windows/* Windows2/
rm -rf Windows
mv Windows2 Windows
Explanation:
The logic of this is to set the nodatacow attribute on Windows2, which
then means overwrites by the guest will overwrite those same areas in
the file, rather than COW. There's no direct COW penalty per se, it's
just a redirection. The issue is it can result in fragmentation and
that'll make subsequent reads slower due to having to seek for that
fragment. It's a bigger problem on rotational drives, the seek latency
is high and so is rotational latency. For all the libvirt locations,
this is done for you on default clean Btrfs installs, when the pool
(directory) is activated. Includes: virt-manager, gnome-boxes,
cockpit.
mv will fail between destinations with different nodatacow settings,
hence cp. If the source and destination can support reflink copy, then
reflink copy is used by default starting with Fedora 33 on both Btrfs
and XFS. Note that reflink copies cannot cross mount points, that's a
VFS limitation. So what'll happen is, cp falls back to regular copy,
rather than being efficient.
The reason for making /home/Windows a subvolume in my opinion is not
to snapshot /home/Windows. But so you can snapshot /home and *exclude*
/home/Windows. Snapshots aren't recursive (for developers they can be,
see libbtrfsutil C API and Python bindings). So this keeps your VM
images nodatacow.
Instead what I do is "snapshot" the VM files by reflink copy within
their own directory. And yes they get quite a lot more fragmented.
cp win10.raw win10-updated.raw
Again, it's a reflink copy because (a) that's the cp default on F33
and (b) the source and destination files are going to be nodatacow
since we're staying in the same directory. So this cp is fast. And if
you 'du' the ../Windows directory it'll hilariously count these files
twice, but if you use 'btrfs fi du -s' you'll be introduced to some
new terminology: exclusive and shared data.
You might prefer doing snapshots the qcow2 way, although I have no
idea what "qemu-img snapshot" does because I've never used it. I've
only used "qemu-img create -b" to create a new qcow2 file that points
to the original as a backing file. Why? *shrug* I don't know. But I
throw it out there as an option.
Whether you use 'cp' to make a reflink copy (fast copy, efficient
copy) or you 'btrfs sub snap /home/Windows /home/Windows.20201223' or
however you want to name them, there is a gotcha. Those nodatacow
extents now *cannot* be overwritten because they've been snapshot.
They are now cow again for any writes that would be an overwrite. But
it's only a one time redirect. It'll COW a shared block to a new
location (exclusive block) and any subsequent changes for that block
will be nodatacow again... unless you make another snapshot.
So yeah, no free lunch. There's always a tradeoff. And that's why you
might consider a different way to preserve the images.
Windows NTFS in particular has fairly remarkable write patterns that
result in a lot of fragmentation on any file system. But it is
especially bad on Btrfs. I speculate that the dual journaling
technique it uses just ends up being turned into piles of "appends"
onto a sparse raw file if it's COW. Your best bet really is to
fallocate a raw file in a subvolume or directory with chattr +C set
and don't snapshot or reflink copy it. That's very much like what you
get with a raw file on XFS or ext4. And perhaps a tiny bit more
overhead than a conventional LVM LV, which is really your best bet if
performance is the top concern.
Another thing I use in virt-manager is cache mode unsafe. I can't
recommend it because, I mean, it's not safe. But it's a lot faster. So
if you don't care about your data, and I definitely don't, and you
care about performance, unsafe cache mode is awesome. And worth
finding another way to mitigate the possibility of guest writes
happening when power is yanked from the host and totally trashes the
guest's file system. (I have had it trash NTFS in this scenario; but
never once have I damaged Btrfs in such a guest. The unsafeness does
come from the host crashing, not the guest. You can probably get away
with force quitting the guest all you want. I do this all the time
because (a) I hate my data and (b) I'm impatient. :D But yeah I also
backup my data other ways so if it goes kaboom, it's actually fun
because I get to use my backups.
I am the reason for my backups...
Let me ask you how will snapshotting and restoration work with nested sub
volumes?
Let's say I snapshot my root subvolume which contains a subvolume which
contains my VM images.
What will happen to this volume when I restore my root snapshot?
3:32 p.m.
On Fri, Dec 25, 2020 at 11:27 AM Sreyan Chakravarty <sreyan32(a)gmail.com> wrote:
Let me ask you how will snapshotting and restoration work with nested sub volumes?
They have to be moved into the new position following the rollback.
This could be done either with a literal 'mv' or you could just
snapshot the old location to new location, then delete the snapshot
from the old location.
Let's say I snapshot my root subvolume which contains a subvolume
which contains my VM images.
The snapshot will stop at the nested subvolume boundary, i.e. it will
not be included.
What will happen to this volume when I restore my root snapshot?
The rolled back root subvolume will have an empty directory matching
the name of the nested subvolume.
--
Chris Murphy
1222
days inactive
1226
days old
17 comments
5 participants
participants (5)
-
Chris Murphy -
Nate Pearlstein -
Patrick O'Callaghan -
Qiyu Yan -
Sreyan Chakravarty