Skip to contentSkip to conversation

Heavy nocow'd VM image fragmentation

DISCUSSION Duncan 1 participant 1 message Oct 25, 2014 Btrfs file system

lore
Share & tools
lore

Duncan

author
#0 lore raw

Begin forwarded message (forgot to send to list):

Date: Sat, 25 Oct 2014 03:57:41 -0700
From: Duncan <[email protected]>
To: Marc MERLIN <[email protected]>
Subject: Re: Heavy nocow'd VM image fragmentation

Quoted 9 lines · On Fri, 24 Oct 2014 21:48:56 -0700 Marc MERLIN <[email protected]> wrote:
Quoted 4 lines · Duncan

Yes, but the OP said he hadn't snapshotted since creating the file, and MM's a regular that actually wrote much of the wiki documentation on raid56 modes, so he better know about the snapshotting problem too.

Yes and no. I use btrfs send receive, so I have to use snapshots on the subvolume my VM file is on.

That kinds screws things, since you can delete the snapshots afterward, but if anything changed while it was there it still forces a 1cow on it. As long as the send doesn't take "forever" the time in question can be reasonably short, but if the VM must remain active over that period, there's likely to still be /some/ effect.

The only thing you can do about that, I guess, is periodically defrag them, but of course without snapshot-aware-defrag that breaks any snapshot sharing, multiplying the space required. And with send/receive requiring a reference snapshot for incrementals, there's the snapshot, thus space-doubling on anything actually defragged is unfortunately a given. =:^(

Quoted 2 lines

Can you reply to this post to show my reply to others since my Android post to the list will get rejected?

Dug out of the trash here too due to the HTML, but OK...

Signature · 4 lines
Duncan - HTML messages treated as spam
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin