The Btrfs inode-number epic (part 2: solutions)

Posted Aug 24, 2021 6:21 UTC (Tue) by eru (subscriber, #2753)
Parent article: The Btrfs inode-number epic (part 2: solutions)

A warning example of the trouble you get when you break a very old assumption. Or should it be even be called an invariant: Every mounted file system shall have inode numbers that are unique within it. In hindsight, at least, the correct solution would have been to not merge btrfs until it obeys this rule.

The Btrfs inode-number epic (part 2: solutions)

Posted Aug 29, 2021 4:55 UTC (Sun) by patrakov (subscriber, #97174) [Link] (2 responses)

This requirement is not really useful, as it applies to the whole filesystem and assumes that there is no concurrent mutation of the whole filesystem. It would be necessary to make a stronger requirement, that can at least apply to subtrees and tolerate mutations outside of the subtrees. And ideally, specify what happens with inode numbers now and in the past, if the subtree being walked through is also being mutated concurrently.

The Btrfs inode-number epic (part 2: solutions)

Posted Aug 31, 2021 13:44 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

Yup. I've been puzzled by this and I think I've hit on part of the problem ...

The *obvious* fix is to make i-nodes unique at the root file-system level. It's not a problem to think of a snapshots sharing i-nodes if they're sharing the same file ...

BUT. As soon as you break the link by modifying the file in one snapshot, that means you need to change the i-node number. No problem? Until the user has been using hardlinks to avoid having multiple identical copies of large files. You're now forcing "create temp files, copy over original" behaviour onto user space and that breaks hard links ...

I'm guessing there's plenty more problems where that came from, so where do we go from here? It ain't simple ...

Cheers,
Wol

The Btrfs inode-number epic (part 2: solutions)

Posted Aug 31, 2021 14:02 UTC (Tue) by patrakov (subscriber, #97174) [Link]

Correct. And this is even mentioned in other comments: "btrfs snapshots are a lazy version of 'cp -a --reflink'". Same inode numberss indicate hardlinks, and reflinks are a different beast. So it looks like a solution would involve generating inode numbers lazily when someone stats a file in the snapshot.