On Apr 23, 2016, at 9:03 PM, John <j...@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
