On Jan 27, 2014, at 11:50 AM, Hugo Mills <h...@carfax.org.uk> wrote:
> On Mon, Jan 27, 2014 at 11:44:24AM -0700, Chris Murphy wrote: >> >> On Jan 27, 2014, at 6:53 AM, KC <impacto...@googlemail.com> wrote: >>> 4. If I have a snapshot of /, can I completely erase this partition and >>> later restore it in full form that snapshot, or do snapshots work only if a >>> limited number of files has been changed? >>> If the former, then does it mean that snapshot size will be comparable to >>> the original data size? >> >> I'm confused by what you mean by completely erase this partitions and later >> restore it. What do you mean by partition? Taken literally I'd say no >> because a snapshot is a subvolume, it's a function of a Btrfs file system, >> and if you erase the partition you've erased the file system and everything >> on it. >> >> Otherwise, either the snapshot or its parent subvolume can be deleted at any >> time. At the moment the snapshot is taken, they are clones, but they behave >> as completely separate file systems. Any changes to one do not affect the >> other. > > Probably slightly more accurate to say "completely different file > trees", as they're part of the same filesystem (the single btrfs FS > that contains all of the subvolumes in this example). Yes good point. File system = volume; file tree = subvolume. > >>> 5. Can a snapshot be stored on a different partition? >> >> Yes Btrfs send/receive. > > Mmmm... debatable semantics again. You can transfer the data with > btrfs send/receive, but after that it's not really a snapshot in the > sense of being a CoW copy on the same filesystem… Ahh yes I was being very literal rather than thinking of a magical hard link that can work across file system boundaries. Maybe the question needs to be phrased in terms of a use case question, and possibly a seed-device would fit? https://btrfs.wiki.kernel.org/index.php/Seed-device Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html