<div dir="ltr"><div>I must be misunderstanding something, I thought the snapshot retained the original data as things continued to get written to the source. (This seems to be what LVM does at any rate)<br></div><div>Which is great, but kinda the wrong way round for my use case.</div><div>I effectively want the changes written into the snapshot, leaving the source untouched.</div><div>Thus I can have as many snapshots as I need (parallel tests etc) and then chuck them.<br></div><div>Much more like the differencing you get with Hypervisors (and OverlayFS, just at the block level to reduce space requirements).<br></div><div><br></div><div>If XFS or something can do that, awesome, and I'll start looking at it as soon as Kubuntu gets itself out of whatever APT fankle it's managed to get into!</div><div>Not sure how viable BTRFS would be as a choice, I thought the project was slowly dying off (I know RedHat has dropped it) and any proposals will need to be passed by Internal IT, so can't be too exotic.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 10 Jun 2019 at 11:24, Martin via Nottingham <<a href="mailto:nottingham@mailman.lug.org.uk">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">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 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 read-write.<br>
<br>
<br>
Aside: Note that you don't even need to mount the subvolumes as separate<br>
mounts: they can even appear as 'normal' directories on a (single)<br>
higher mount point.<br>
<br>
<br>
The snapshot volume is created with zero copying of files and is very<br>
fast and low resource to do. You'll see no increase in disk usage!<br>
<br>
During use, the only file writing will be only for whatever new data is<br>
actually written. The magic of the btrfs CoW means that only new blocks<br>
of data get written. Unchanged file fragments remain unchanged 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 "Template" folder<br>
> and then a "Working" folder (plus a couple of others for reasons) and<br>
> that works well. Except for the fact that full file copies still 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 thing, but<br>
> do some block-level magics.<br>
> LVM snapshots might also do it, but not sure if they would allow for<br>
> multiple, concurrent "Working" folders and AIUI that would mean mucking<br>
> around with how the system is deployed, not something I have 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></blockquote></div>