<div dir="ltr"><div>Thanks for that, it explained things rather nicely. I didn't know the snapshot was writeable (I was probably reading old docs) but using a R/W snapshot works exactly how I want.</div><div>I am going to presume it's a very similar trick with BTRFS/XFS/WhateverFS<br><br></div><div>Now just to find out how this VM has been deployed and see which solution works best for IT.</div><div><br></div><div><rant>Why are docs usually just lists of commands? Is a simple picture to provide some kind of context just too much to ask for></rant><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 10 Jun 2019 at 14:50, VM via Nottingham <<a href="mailto:nottingham@mailman.lug.org.uk" target="_blank">nottingham@mailman.lug.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A good explanation of different uses for read-write snapshots is at<br>
<a href="https://www.clevernetsystems.com/lvm-snapshots-explained/" rel="noreferrer" target="_blank">https://www.clevernetsystems.com/lvm-snapshots-explained/</a><br>
<br>
On June 10, 2019 1:27:54 PM UTC, VM via Nottingham <<a href="mailto:nottingham@mailman.lug.org.uk" target="_blank">nottingham@mailman.lug.org.uk</a>> wrote:<br>
>Martin, LVM snapshots can be mounted read-write and keep modifications<br>
>made. They also can be merged with the origin if changes are desired.<br>
>For instance, make a snapshot, mount it, upgrade, check everything is<br>
>fine, merge snapshot with the origin. It's another use of LVM<br>
>snapshots, different to read-only backups.<br>
><br>
>On June 10, 2019 12:37:55 PM UTC, Martin via Nottingham<br>
><<a href="mailto:nottingham@mailman.lug.org.uk" target="_blank">nottingham@mailman.lug.org.uk</a>> wrote:<br>
>>On 10/06/2019 12:06, J J via Nottingham wrote:<br>
>>> I must be misunderstanding something, I thought the snapshot<br>
>retained<br>
>>> the original data as things continued to get written to the source.<br>
>>> (This seems to be what LVM does at any rate)<br>
>><br>
>>On LVM, when you enable a snapshot device:<br>
>><br>
>>The source device is used as normal, unaffected, with data read and<br>
>new<br>
>>data written as normal.<br>
>><br>
>>While the LVM snapshot device is enabled, any disk blocks written to<br>
>>the<br>
>>source device first have the old block data copied to the snapshot<br>
>>device. Hence you get the original LVM source device in use as normal<br>
>>and a copy of the old data before being overwritten, block by block,<br>
>>copied across to the LVM snapshot device. I guess that can be called a<br>
>>sort of CoW but used instead for 'saving' the old data.<br>
>><br>
>>When reading from the LVM snapshot device, any blocks that are<br>
>>unchanged<br>
>>are read from the source device as normal. Any changed blocks are<br>
>>instead read from the copy saved on the snapshot device to make the<br>
>>source device appear to be unchanged.<br>
>><br>
>>Hence, you have the read-only snapshot view and additionally, the<br>
>>snapshot device area can be much smaller than the source device. (Only<br>
>>the changed data is stored...)<br>
>><br>
>><br>
>>> Which is great, but kinda the wrong way round for my use case.<br>
>>> I effectively want the changes written into the snapshot, leaving<br>
>the<br>
>>> source untouched.<br>
>>> Thus I can have as many snapshots as I need (parallel tests etc) and<br>
>>> then chuck them.<br>
>>> Much more like the differencing you get with Hypervisors (and<br>
>>OverlayFS,<br>
>>> just at the block level to reduce space requirements).<br>
>><br>
>>And that is exactly what you can do on btrfs with the inherent magic<br>
>of<br>
>>CoW:<br>
>><br>
>>Simplistically, all a btrfs snapshot is is an atomic snapshot of the<br>
>>b-tree indexing. The file data stays in place.<br>
>><br>
>>You then have, ready for the very next operation, two identical views<br>
>>of<br>
>>the same data and attributes. There is no distinction as to which is a<br>
>>snapshot of whichever. You have taken ' _a_ snapshot' whereby you now<br>
>>have two identical views with access from two different points on the<br>
>>filesystem.<br>
>><br>
>>Both views are read-writeable in whatever way you wish.<br>
>><br>
>>Or you can restrict whichever or both to read-only in whatever way<br>
>>wished.<br>
>><br>
>><br>
>>> If XFS or something can do that, awesome, and I'll start looking at<br>
>>it<br>
>>> as soon as Kubuntu gets itself out of whatever APT fankle it's<br>
>>managed<br>
>>> to get into!<br>
>><br>
>>No need for XFS (and in any case, I'm a little prejudiced against its<br>
>>block allocation ways of working and how that must fit your use case -<br>
>>whereas btrfs is more flexible for extremes of use cases).<br>
>><br>
>><br>
>>> Not sure how viable BTRFS would be as a choice, I thought the<br>
>project<br>
>>> was slowly dying off (I know RedHat has dropped it) and any<br>
>proposals<br>
>>> will need to be passed by Internal IT, so can't be too exotic.<br>
>><br>
>>btrfs is very much alive and is used by and supported by the big cloud<br>
>>providers including Facebook...<br>
>><br>
>>Red Hat only dropped support for some of their special Red Hat kernel<br>
>>versions for the sake of long term maintainability.<br>
>><br>
>>btrfs is still developing apace for new features. However, their main<br>
>>features and disk structure can be considered long stable.<br>
>><br>
>>I've been using btrfs for about a decade to good effect and without<br>
>any<br>
>>adverse issues and spanning many TBytes of data.<br>
>><br>
>><br>
>>Hope that's of help,<br>
>><br>
>>Cheers,<br>
>>Martin<br>
>><br>
>><br>
>>ps: Corrections welcomed!<br>
>><br>
>><br>
>>> On Mon, 10 Jun 2019 at 11:24, Martin via Nottingham<br>
>>> <<a href="mailto:nottingham@mailman.lug.org.uk" target="_blank">nottingham@mailman.lug.org.uk</a><br>
>><mailto:<a href="mailto:nottingham@mailman.lug.org.uk" target="_blank">nottingham@mailman.lug.org.uk</a>>><br>
>>> wrote:<br>
>>> <br>
>>>     Jason,<br>
>>> <br>
>>>     The obvious fix for that is to use btrfs whereby:<br>
>>> <br>
>>>     You have your pristine folders in one btrfs subvolume (can even<br>
>>be<br>
>>>     mounted or set to be read-only);<br>
>>> <br>
>>>     Then create a snapshot subvolume from that first subvolume;<br>
>>> <br>
>>>     Your new snapshot subvolume can then be used or mounted<br>
>>read-write.<br>
>>> <br>
>>> <br>
>>>     Aside: Note that you don't even need to mount the subvolumes as<br>
>>separate<br>
>>>     mounts: they can even appear as 'normal' directories on a<br>
>>(single)<br>
>>>     higher mount point.<br>
>>> <br>
>>> <br>
>>>     The snapshot volume is created with zero copying of files and is<br>
>>very<br>
>>>     fast and low resource to do. You'll see no increase in disk<br>
>>usage!<br>
>>> <br>
>>>     During use, the only file writing will be only for whatever new<br>
>>data is<br>
>>>     actually written. The magic of the btrfs CoW means that only new<br>
>>blocks<br>
>>>     of data get written. Unchanged file fragments remain unchanged<br>
>>and<br>
>>>     uncopied...<br>
>>> <br>
>>> <br>
>>>     Hope that fits your needs?<br>
>>> <br>
>>>     Cheers,<br>
>>>     Martin<br>
>>> <br>
>>> <br>
>>> <br>
>>>     On 10/06/2019 11:04, J J via Nottingham wrote:<br>
>>>     > I need read/write access to the new folder.<br>
>>>     > Mucking around with OverlayFS I can effectively have a<br>
>>"Template"<br>
>>>     folder<br>
>>>     > and then a "Working" folder (plus a couple of others for<br>
>>reasons) and<br>
>>>     > that works well. Except for the fact that full file copies<br>
>>still<br>
>>>     happen<br>
>>>     > and some of these files are big.<br>
>>>     > So the situation is definitely better, but far from ideal.<br>
>>>     ><br>
>>>     > I am going to see if I can grok XFS enough to do the similar<br>
>>>     thing, but<br>
>>>     > do some block-level magics.<br>
>>>     > LVM snapshots might also do it, but not sure if they would<br>
>>allow for<br>
>>>     > multiple, concurrent "Working" folders and AIUI that would<br>
>mean<br>
>>>     mucking<br>
>>>     > around with how the system is deployed, not something I have<br>
>>>     control over.<br>
>>>     ><br>
>>>     > The other wrinkle is that this needs t be done ad hoc.<br>
>>>     > But first things first...<br>
>><br>
>><br>
>>-- <br>
>>Nottingham mailing list<br>
>><a href="mailto:Nottingham@mailman.lug.org.uk" target="_blank">Nottingham@mailman.lug.org.uk</a><br>
>><a href="https://mailman.lug.org.uk/mailman/listinfo/nottingham" rel="noreferrer" target="_blank">https://mailman.lug.org.uk/mailman/listinfo/nottingham</a><br>
><br>
>--<br>
><a href="mailto:vadim@mankevich.co.uk" target="_blank">vadim@mankevich.co.uk</a> PGP key fingerprint<br>
>0xC046022A3A91455AF0C9BB2404BF882B1905C772<br>
>Retrieve from <a href="https://keybase.io/vmankevich" rel="noreferrer" target="_blank">https://keybase.io/vmankevich</a><br>
><br>
>"When we take away the right to figure out if something bad is going on<br>
>in our computers, the inevitable consequence is that bad things will<br>
>happen in our computers." (Cory Doctorow)<br>
><br>
><br>
>-- <br>
>Nottingham mailing list<br>
><a href="mailto:Nottingham@mailman.lug.org.uk" target="_blank">Nottingham@mailman.lug.org.uk</a><br>
><a href="https://mailman.lug.org.uk/mailman/listinfo/nottingham" rel="noreferrer" target="_blank">https://mailman.lug.org.uk/mailman/listinfo/nottingham</a><br>
<br>
--<br>
<a href="mailto:vadim@mankevich.co.uk" target="_blank">vadim@mankevich.co.uk</a> PGP key fingerprint<br>
0xC046022A3A91455AF0C9BB2404BF882B1905C772<br>
Retrieve from <a href="https://keybase.io/vmankevich" rel="noreferrer" target="_blank">https://keybase.io/vmankevich</a><br>
<br>
"When we take away the right to figure out if something bad is going on in our computers, the inevitable consequence is that bad things will happen in our computers." (Cory Doctorow)<br>
<br>
<br>
-- <br>
Nottingham mailing list<br>
<a href="mailto:Nottingham@mailman.lug.org.uk" target="_blank">Nottingham@mailman.lug.org.uk</a><br>
<a href="https://mailman.lug.org.uk/mailman/listinfo/nottingham" rel="noreferrer" target="_blank">https://mailman.lug.org.uk/mailman/listinfo/nottingham</a></blockquote></div>