Re: [PATCH 4/6] btrfs-progs: use a unified btrfs_make_subvol() implementation

[David Sterba <dsterba@suse.cz>]

On Wed, Oct 25, 2023 at 07:14:58AM +1030, Qu Wenruo wrote:
> 
> 
> On 2023/10/25 04:08, David Sterba wrote:
> > On Wed, Oct 18, 2023 at 10:20:57AM +1030, Qu Wenruo wrote:
> >>>>> We're moving towards a world where kernel-shared will be an exact-ish copy of
> >>>>> the kernel code.  Please put helpers like this in common/, I did this for
> >>>>> several of the extent tree related helpers we need for fsck, this is a good fit
> >>>>> for that.  Thanks,
> >>>>
> >>>> Sure, and this also reminds me to copy whatever we can from kernel.
> >>>
> >>> I do syncs from kernel before a release but all the low hanging fruit is
> >>> probably gone so it needs targeted updates.
> >>
> >> For the immediate target it's btrfs_inode and involved VFS structures
> >> for inodes/dir entries.
> >>
> >> In progs we don't have a structure to locate a unique inode (need both
> >> rootid and ino number), nor to do any path resolution.
> >>
> >> This makes it almost impossible to proper sync the code.
> >>
> >> But introduce btrfs_inode to btrfs-progs would also be a little
> >> overkilled, as we don't have that many users.
> >> (Only the new --rootdir with --subvol combination).
> >
> > I have an idea for using this functionality, but you may not like it -
> > we could implement FUSE.
> 
> In fact I really like it.
> 
> > The missing code is exactly about inodes, path
> > resolution and subvolumes. You have the other project, with a different
> > license, although there's a lot shared code. You can keep it so u-boot
> > can do the sync and keep the read-only support. I'd like to have full
> > read-write support with subvolumes and devices (if there's ioctl pass
> > through), but it's not urgent. Having the basic inode/path support would
> > be good for mkfs even in a smaller scope.
> 
> The existing blockage would be fsck.
> If we want FUSE, inode is super handy, but for fsck doing super low
> level fixes, it can be a burden instead.
> As it needs to repair INODE_REF/DIR_INDEX/DIR_ITEMs, sometimes even
> missing INODE_ITEMs, not sure how hard it would be to maintain both
> btrfs_inode and low-level code.

I'd have to look what exactly are the problems but yes check is special
in many ways. It could be possible to have an "enhanced" inode used in
check and regular inode everywhere else.

> There are one big limiting factor in FUSE, we can not control the device
> number, unlike kernel.
> This means even we implemented the subvolume code (like my btrfs-fuse
> project), there is no way to detect subvolume boundary.

This could be a problem. We can set the inode number to 256 but
comparing two random files if they're in the same subvolume would
require traversing the whole path. This would not work with 'find -xdev'
and similar.

> Then comes with some other super personal concerns:
> 
> - Can we go Rust instead of C?

I know rust on the very beginner level, and I don't think we have enough
rust knowledge in the developers group.  The language syntax or features
are still evolving, we'd lose the build support on any older distros or
distros that don't keep up with the versions. The C-rust
interoperability is good but it can become a burden. I'm peeking to the
kernel rust support from time to time and I can't comprehend what it's
doing.

> - Can we have a less restrict license to maximize the possibility of
>    code share?

The way it's now it's next to impossible. Sharing GPL code works among
GPL projects, anything else must be written from scratch. I don't know
how much you did that in the btrfs-fuse project

>    Well, I should ask this question to GRUB....
>    But a more hand-free license like MIT may really help for bootloaders.

You can keep your btrfs-fuse to be the code base with loose license for
bootloaders, but you can't copy any code.