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

Posted Aug 24, 2021 23:07 UTC (Tue) by zblaxell (subscriber, #26385)
In reply to: The Btrfs inode-number epic (part 2: solutions) by wazoox
Parent article: The Btrfs inode-number epic (part 2: solutions)

Quote from bcachefs.org:

The functionality and userspace interface for snapshots and subvolumes are roughly modelled after btrfs...

I wouldn't expect anything different. For over a decade, btrfs has had the only viable implementation of this interface to build on in Linux. Even if other filesystems implement subvols and snapshots, they'll be strongly compelled to follow whatever trail btrfs blazes for them now.

I find all the worst-case O(N) searching for N snapshots in the design doc concerning.

This is what the bcachefs 'snapshot' branch does today:

# bcachefs subvolume create foo
# date > foo/bar
# bcachefs subvolume snapshot foo quux
# find -ls
     4096      0 drwxr-xr-x   3 root     root            0 Aug 24 18:40 .
     4098      0 drwxr-xr-x   2 root     root            0 Aug 24 18:40 ./foo
     4099      1 -rw-r--r--   1 root     root           29 Aug 24 18:40 ./foo/bar
     4098      0 drwxr-xr-x   2 root     root            0 Aug 24 18:40 ./quux
     4099      1 -rw-r--r--   1 root     root           29 Aug 24 18:40 ./quux/bar
     4097      0 drwx------   2 root     root            0 Aug 24 18:40 ./lost+found
# stat foo/bar quux/bar
  File: foo/bar
  Size: 29              Blocks: 1          IO Block: 512    regular file
Device: fd04h/64772d    Inode: 4099        Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-08-24 18:40:37.278101823 -0400
Modify: 2021-08-24 18:40:37.290101816 -0400
Change: 2021-08-24 18:40:37.290101816 -0400
 Birth: -
  File: quux/bar
  Size: 29              Blocks: 1          IO Block: 512    regular file
Device: fd04h/64772d    Inode: 4099        Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-08-24 18:40:37.278101823 -0400
Modify: 2021-08-24 18:40:37.290101816 -0400
Change: 2021-08-24 18:40:37.290101816 -0400
 Birth: -

Duplicate st_dev and st_ino, it's worse than btrfs. On the other hand:

# date > foo/second1
# date > quux/second2
# ls -li */second*
4100 -rw-r--r-- 1 root root 29 Aug 24 18:44 foo/second1
4101 -rw-r--r-- 1 root root 29 Aug 24 18:44 quux/second2

bcachefs will always give new files unique inode numbers, even in different subvols, because the code for creating a new file obtains a globally unique inode number. Possible point for bcachefs here--in this situation, btrfs uses a per-subvol inode number allocator, which would have given both new files inode 4100.