<div dir="auto">Hey Peter, thanks for the super quick reply, you're awesome!<div dir="auto"><br></div><div dir="auto">So you mean the first option would be to create a second disk instead of using snapshot for write, when it gets too big I can then unplug the disk, delete it (or wipe entire overlay fs) and recreate it to start fresh?</div><div dir="auto"><br></div><div dir="auto">OK I will try that, thanks for the tip!</div><div dir="auto"><br></div><div dir="auto">Option 2 with trim/discard I have to do some research, this seems a bit more challenging.</div><div dir="auto"><br></div><div dir="auto">Thank you SO much for the great advice. I will try everything out and report back. :-)</div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Nov 30, 2021, 3:25 PM Peter Krempa <<a href="mailto:pkrempa@redhat.com">pkrempa@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Nov 30, 2021 at 14:51:54 +0100, Elias Mobery wrote:<br>
> Hello Peter, thank you so much for that detailed info!<br>
> <br>
> Sorry, you were right, when trying to delete my external snapshot via<br>
> snapshot-delete, the error says "deletion of external snapshots unsupported"<br>
> <br>
> I can't merge the snapshot because the VM image is in a read-only<br>
> filesystem. Sorry I should've said, it's a live system. So the image is in<br>
> the read-only squashfs and external snapshot in overlay is used for writing.<br>
<br>
Okay, that changes the situation quite a bit:<br>
<br>
> <br>
> Now I would like the snapshot emptied or deleted/recreated when it reaches<br>
> 4GB.<br>
> <br>
> Is there even a way to do this with the image being read-only?<br>
<br>
If the base image is on a read-only filesystem you obviously can't<br>
commit to it.<br>
<br>
Now the question is what should happen to the data in the overlay.<br>
<br>
Discarding/recreating the overlay image is possible only once you turn<br>
off the VM because it basically rolls back the state of the disk back to<br>
the time when the overlay was created. This means that everything<br>
written to the disk will be lost.<br>
<br>
Filesystems obviously can't handle that so that's why it simply won't be<br>
possible to do live with the root image.<br>
<br>
You can have a second disk, which you hot-unplug, wipe the overlay and<br>
plug it back.<br>
<br>
Another possibility is to enable trim/discard and just simply delete the<br>
data in the VM which was added after the overlay was created. When<br>
trim/discard is enabled on all layers incluging the guest filesystem,<br>
then deleting stuff inside the VM will also mean that the overlay will<br>
shrink again.<br>
<br>
</blockquote></div></div>