Le mar. 23 juil. 2013 21:30:13 CEST, Hugo Mills a écrit : > 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. Sorry for misreading you. Directory snapshots can work by giving a new device number to the snapshot. There is no need to update inode numbers in that case. -- 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
