Re: [RFC] Converging userspace and kernel code

[Anand Jain <anand.jain@oracle.com>]

>>>>>> Goldwyn,
>>>>>>
>>>>>>  Could you add a list what functionality in btrfs-progs will
>>>>>>  be using the 'core'. ?
>>>>>
>>>>>
>>>>> There are too many to list. It would contain the algorithmic functions
>>>>> of btrfs which would be able to interact with both kernel and
>>>>> btrfs-progs.
>>>>
>>>>  I am getting confused. How about a few from the btrfs-progs ?
>>>>
>>>>
>>>
>>> Functions such as open_ctree(), or the set/get functions. The idea is to
>>> keep the codebase of this core component the same in btrfs-progs and
>>> kernel.
>>
>>  The btrfs-progs open_ctree() is used for the offline functionality
>>  such as fsck...
>>
>>> As an example, see how XFS have done using libxfs. Something around the
>>> same lines.
>>>
>>
>>  Does XFS progs access the disks directly (without going through the
>>  kernel) while kernel has mounted the disk ? If yes, how does it
>>  maintain the consistency ? Calling sync for the sake of read access
>>  by the progs, is not a good idea as it causes jitters in the steady
>>  state IOPS for the applications. I have investigated these concerns
>>  at the data centers earlier.
>>
>
> I think you are misunderstanding the effort. The effort is not to use
> the common code simultaneously between the kernel and the progs, but to
> keep a common *codebase*. Both kernel and userspace would provide the
> same functionality as it is currently, though independently in their own
> right. IOW, this is not a data sync but a codebase sync.
>
> The objective (besides others) is to have faster bug resolution, and
> better "transfer" of logic from kernel to user space and vice versa.
>
> xfsprogs, depending on the operation used acts on the disk directly
> without the kernel mounting it (say mkfs or xfs_repair), or disk being
> mounted (say xfs_growfs)

  Thanks for clarifying. Once we had progs and kernel simultaneous
  disk access. Its been fixed now. Good, that idea is not coming
  back with this.

  Indeed this a nice effort to have it organized.

  Just a note: fsck, which is a strong consumer of open_ctree() in
  the unmounted mode, should go obsolete per the plan. Its an area
  which needs some help though.

Thanks, Anand