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. ---
Attachment:
signature.asc
Description: Digital signature
