On 01/10/2017 08:23 PM, Anand Jain wrote: > > > On 01/11/17 00:04, Goldwyn Rodrigues wrote: >> >> >> On 01/10/2017 09:20 AM, Anand Jain wrote: >>> >>> >>> On 01/10/17 20:14, Goldwyn Rodrigues wrote: >>>> >>>> >>>> On 01/09/2017 09:28 PM, Anand Jain wrote: >>>>> >>>>> 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) -- Goldwyn -- 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
