Re: [LSF/MM TOPIC] [ATTEND] Container disk quota and lseek(2) upon shared extents

[Jeff Liu <jeff.liu@oracle.com>]

On 01/30/2013 10:41 AM, Dave Chinner wrote:
> On Wed, Jan 30, 2013 at 12:37:08AM +0800, Jeff Liu wrote:
>> On 01/29/2013 11:14 PM, Jan Kara wrote:
>>> On Tue 29-01-13 22:44:24, Jeff Liu wrote:
>>>> I'd like to discuss the following problems on LSF:
> ....
>>>> Still sounds nothing because we have FIEMAP...:( But consider the bad interface
>>>> and error prone when I improving cp(1) through it for sparse files, it will extends
>>>> the ugly tentacles of FIEMAP into du(1) again that the maintainer of coreutils(Jim, CC-ed)
>>>> don't like it at all, and I also want to avoid if possible...
>>>>
>>>> How about if we add a new whence type to lseek(2) for this function?  lseek has very clear
>>>> interface and works very well for SEEK_DATA/SEEK_HOLE, most likely could works fine for
>>>> shared extents IMHO.
>>>   Well, I can hardly imagine how such lseek(2) interface would look to be
>>> useful for identifying shared extents among different files. Do you have
>>> something particular in mind?
>> lseek(2) is not used for identifying shared extents among files.  It would be improved and
>> called to find out and return an desired extent which is reflinked or cloned with a particular
>> whence, the underlying file system should be improved accordingly.
>>
>> To say Btrfs, if we performed btrfs_ioctl_clone from source file A to target B, run du(1)
>> against both files, it would show double space although only 1/2 space is really used/reserved
>> upon COW.
>>
>> If we can mark the cloned extents of file with a special flag(to say EXTENT_MAP_CLONED), then
>> call lseek(fd, offset, SEEK_CLONE or ?), it would return the offset of a cloned extent which is
>> equal or beyond the given offset, so we can find out all the cloned extents upon a file which
>> would be used for the disk space accounting in user space tools.
> 
> Why do you need lseek to find this?
I had originally thought to call lseek to get the cloned extents only,
ranther than fetching different kinds of extents, and then call FIEMAP
to get the physical block offset upon the logical.
> Couldn't we just add a filter
> option to fiemap to ensure that it only returns extents in the file
> that match the filter? You could then implement what you want with a
> single call rather than having to indirectly iterate the extent map
> with lseek() and then calling FIEMAP on each of the 
> regions discovered by lseek.....
Really a nice point, thank you!

-Jeff