On Thu, 2015-12-10 at 12:42 -0700, Chris Murphy wrote: > That isn't what I'm suggesting. In the multiple device volume case > where there are two exact (same UUID, same devid, same generation) > instances of one of the block devices, Btrfs could randomly choose > either one if it's an RO mount. No, for the same reasons as just stated in my mail few minutes ago. An attacker could probably find out the UUID/devid/generation... it would probably possible for him to craft a device with exactly those and try to use it. If then btrfs would select any of these, it may also select the wrong one - ro or rw, this may likely lead to problems.
> > About 1 and 2 ... if 3 gets fulfilled, why? > > DD itself is not a problem "if" the UUID is changed after it > > (which is a command as simple as dd), and if someone doesn't > > know that, he/she will notice when mount refuses to work > > because UUID duplicate. > > dd is not a copy operation. It's creating a 2nd original. You don't > end up with an original and a copy (or clone). A copy or clone has > some distinguishing difference. Volume UUID is used throughout Btrfs > metadata, it's not just in the superblocks. Changing volume UUID > requires a rewrite of all metadata. This is inefficient for two > reasons: one dd copies unused sectors; two it copies metadata that > will have to be completely rewritten by btrfstune to change volume > UUID; and also the subvolume UUIDs aren't changed, so it's an > incomplete solution that has problems (see other threads). Well dd is surely not the only thing that can be used to create a clone (i.e. a bitwise identical copy - I guess we don't really care which is the "original" and which are the "clones", or whether these are "2nd originals). We always just use it here as an example for scenarios in which bitwise identical copies are created. And even if internally it's a big thing, from the user's PoV, changing the UUID is pretty simple (I guess that's what S.J. meant). > If your workflow requires making an exact copy (for the shelf or for > an emergency) then dd might be OK. But most often it's used because > it's been easy, not because it's a good practice. Ufff.. I wouldn't got that far to call something here bad or good practice. At least, I do not see any reason to call it a bad practice, except that systems got over time much more complex and haven't dealt properly with the problems that can occur by using dd. Again, I don't demand magical "solutions" (i.e. the btrfs or LVM people getting code into all dd like tools, so that these auto-detect when the duplicate such data and auto-change the UUIDs)... they just should handle the situations gracefully. > Note that Btrfs is > not unique, XFS v5 does a very similar thing with volume UUID as > well, > and resulted in this change: > http://oss.sgi.com/pipermail/xfs/2015-April/041267.html Do you mean that xfs may suffer from the same issues that we're talking about here? If so, one should probably give them a notice. > Using dd also means the volume is offline. Not really, you could do it on a snapshotted LV, while the "original" is still running. Or in emergency cases one could do it on a ro-remounted... probably not guaranteed to work, but may do so in practise. Cheers, Chris. -- 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
