On Tue, Nov 15, 2022 at 11:10:16AM -0500, rhkramer@gmail.com wrote: > Intentionally top-posting; Thanks to all who replied, I think I have a pretty > good understanding and I think the biggest thing I was missing was how a file > could be reconstructed using only the metadata, but I now see the explanation > that filesystems that can do snapshots are COW and now things make sense. The underlying mechanism for all that is, most of the time, some variant of a B-tree, where you just build up a modified B-tree up from the leaves up to the root. The new root is just the new file system's state. If you want to hold onto the old one (aka snapshot), you hold onto the old root. This is an idea which generated in the database world (called MVCC, Multi Version Concurrency Control); Postgres (PostgreSQL's grandma) was one of the pioneers in that area, AFAIK. Back then you could do "time travel", rolling back the whole database. Needless to say, it ate storage for breakfast. An expensive breakfast, back then ;-) Here's a paper [1] on how btrfs does that. I'd expect the other snapshot capable file systems to work similarly (they have some pretty pics :) So a snapshot itself is extremely fast and cheap -- just holding on to many of them will exhaust your disk at some point. Cheers [1] https://btrfs.wiki.kernel.org/images-btrfs/6/68/Btree_TOS.pdf -- t
Attachment:
signature.asc
Description: PGP signature