On Apr 24, 2014, at 1:08 AM, Robert White <rwhite@xxxxxxxxx> wrote: > So the systems are "the same" but they aren't really the same according to this clearly visible symptom. I don't think of btrfs send/receive as sending/receiving whole subvolumes, but rather just their contents. Try btrfs sub show <subvol> on the original rw subvolume, its ro snapshot, and the sent/received ro snapshot on the target drive. It looks like this: Drive [a] [a]# btrfs sub show pictures /mnt/a/pictures Name: pictures uuid: f15ebd77-1151-1740-a7fb-7fd82a0de4aa Parent uuid: - Creation time: 2014-04-24 08:39:53 Object ID: 257 Generation (Gen): 11 Gen at creation: 7 [a]# btrfs sub show pictures_1ro /mnt/a/pictures_1ro Name: pictures_1ro uuid: 7bfc06b2-dcc1-0346-a36f-a6305d45934b Parent uuid: f15ebd77-1151-1740-a7fb-7fd82a0de4aa Creation time: 2014-04-24 08:45:58 Object ID: 260 Generation (Gen): 11 Gen at creation: 11 [send from drive a to drive b] [b]# btrfs sub show pictures_1ro/ /mnt/b/pictures_1ro Name: pictures_1ro uuid: a814808d-18f7-924b-ba11-68bd3e032bf6 Parent uuid: - Creation time: 2014-04-24 08:46:54 Object ID: 257 Generation (Gen): 8 Gen at creation: 7 Nothing except the name is the same between them. The subvolumes uuids, object ids, generation number, are all different. > > It's _impossible_ to strip Base of it's subvolume status on /driveb. If you delete the Base_BACKUP element so that Base is the only thing on the drive, it's still a shapshot according to -s. What does this status even mean if it's as meaningless as it seems. > > That seems like a second surprise. I don't know what the first sentence means. A subvolume isn't a state, it's an object, and so it either exists or not. It isn't a flag that can be set and unset. The snapshot state and parent uuid isn't exactly fool proof, it's easily spoofed. So I take it to mean "how it was created" - subvolume create vs subvolume snapshot. There is no actual difference between a subvolume and a snapshot. For example. Subvolume A with some files in it. I subvolume create B, and I --reflink files from A to B. I've just functionally made B a snapshot of A, yet its metadata doesn't indicate this. It's a subvolume that doesn't proclaim being a snapshot, nor does it have a parent uuid. Conversely, if I subvolume snapshot A C, and then rm -rf C/* and fill it with some new files, I have a subvolume claiming to be a snapshot with a parent uuid, but it has nothing at all in common with that parent. So the snapshot flag and parent uuid are conveniences, they indicate a truth at the time of creation. It's not a dynamic status. > > --- > > Is this a common case? It could easily be if you use NAS or movable USB to do your backups and restore-or-media-migration operations. > > Are we sure it doesn't matter? I find it problematic but fixable in concept. I've got no information whether the internal parentage relationship could be reversed so that the before and after of the subvolume list -s result are the same. > > No I'm not looking for byte-level identical status, I know that's ridiculous. > > I want semantically identical status. I don't see how that's presently possible since subvolumes themselves aren't being sent. Instead their contents are, with an efficient incremental/clone stream feature. We can't use send on a rw subvolume, so from the outset we have a semantic disconnect between source and destination. I really think what you're after is seed device. Or possibly some hybrid between seed and send. > > ==== > > Why it matters... > > If I am doing monthly and weekly archiving I don't want to interrupt the rolling archive(s) if I end up having to do a restore. I don't want to create a catastrophe point or an interrupting epoch in the archive history. > > It sounds like it doesn't matter once you know not to use the -s status for anything… I'd say it's not a status because the word status implies present state and thus is a dynamic indicator. Instead, -s indicates how the subvolume was created: empty or prefilled. And it's really mostly useful for ro snapshots because we're assured they haven't changed since they were created. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
