Re: Filesystem snapshots

[Scott Wheeler <scott@directededge.com>]

On Apr 23, 2016, at 9:03 PM, John <john@commonpeople.uk> wrote:
> 
> But the second, it seems to me, requires a partition (or filesystem, or tree portion) to be copied to a large enough temporary space to hold the full dataset which is to be archived, before the next update can be accepted and the backup started side-by-side. If you think it can be achieved without a full data copy being taken while the updates are frozen then this will be a lightbulb-moment for me - continuing to update while creating the copy is no different to updating while backing up, it's just pushing the problem to one remove. I can see how it might be achieved instantly with a mirror dataset, freezing one and continuing to update the other, but we've not discussed those.

You don't have to copy the whole data set -- that's the whole notion behind "copy-on-write".  LLVM (or any copy-on-write system) only has to note the inode tree in the snapshot and then store the live data as a set of changes against that (i.e. update its inode tree to point to the changed blocks).  This makes snapshots fast.

(Note: I've never actually used LLVM to do this, but that's the basic logic behind copy-on-write systems.)

-Scott

--
Scott Wheeler | Co-founder | Directed Edge | www.directededge.com | @directededge