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

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

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.


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.


Then comes with some other super personal concerns:

- Can we go Rust instead of C?

- Can we have a less restrict license to maximize the possibility of
   code share?
   Well, I should ask this question to GRUB....
   But a more hand-free license like MIT may really help for bootloaders.

Thanks,
Qu