Re: Q: Why subvolumes?

[Gabriel de Perthuis <g2p.code@gmail.com>]

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.