Why not just create the new dev_id on the destination snapshot of any directory? That way the snapshot can share inodes with is source. On Tue, Jul 23, 2013 at 2:30 PM, Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: > On Tue, Jul 23, 2013 at 07:47:41PM +0200, Gabriel de Perthuis wrote: >> > Now... since the snapshot's FS tree is a direct duplicate of the >> > original FS tree (actually, it's the same tree, but they look like >> > different things to the outside world), they share everything -- >> > including things like inode numbers. This is OK within a subvolume, >> > because we have the semantics that subvolumes have their own distinct >> > inode-number spaces. If we could snapshot arbitrary subsections of the >> > FS, we'd end up having to fix up inode numbers to ensure that they >> > were unique -- which can't really be an atomic operation (unless you >> > want to have the FS locked while the kernel updates the inodes of the >> > billion files you just snapshotted). >> >> I don't think so; I just checked some snapshots and the inos are the same. >> Btrfs just changes the dev_id of subvolumes (somehow the vfs allows this). > > That's what I said. Our current implementation allows different > subvolumes to have the same inode numbers, which is what makes it > work. If you threw out the concept of subvolumes, or allowed snapshots > within subvolumes, then you'd be duplicating inodes within a > subvolume, which is one reason it doesn't work. > > Hugo. > > -- > === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === > PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk > --- Unix: For controlling fungal diseases in crops. --- -- 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
