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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to