[Ocfs2-devel] [RFC PATCH 0/3] copy-on-write extents mapping

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

On 02/25/2013 09:28 PM, Jan Kara wrote:
>   Hi Jeff,
> 
> On Sun 24-02-13 21:42:30, Jeff Liu wrote:
>> Thanks for both of your comments and sorry for my too late response since
>> I have to think it over and run tests to gather the performance
>> statistics.
>   Sure, no problem.
> 
>>
>> No matter kernel is patched or not, there basically no performance
>> improvements although 12 times fiemap ioctl(2) are reduced
> <snip>
>   Yeah, I suspected that. As Zach said, kernel has to do all the work
> anyway so you just save some small overhead of additional syscalls. But
> those are rather cheap compared to other stuff you need to do.
> 
>> But I have another idea regarding the performance if considering the
>> practical situations.  Generally, the end user would run du(1) against a
>> partition with not only the reflinked files but also includes normal
>> files which are not contains any shared extents, or if the user check up
>> the shared extents for a previous reflinked file, but maybe this file has
>> already totally COWed, that is, now it does not contains any shared
>> extent at all.
>>
>> In either case, du(1) has to call fiemap to look through the extents
>> against this kind of files no matter it contains shared extents or not,
>> that's would be an overhead(Yes, du(1) is not a very performance critical
>> application).
>>
>> But with a prejudegement approach, we can bypass the normal files and
>> lookup shared extents against the COW file only.
>   Yes, that would be useful and as you showed it can bring noticeable
> speedup.
> 
>> Does the results above looks make sense?  If yes, I still felt that it's
>> not a formal approach to detect reflinked files.  IMHO, if we can improve
>> the stat(2)->getattr() to fill the mode member with a flag to indicate
>> that a file is reflinked/cow or not, it would be more convenient to check
>> as like S_ISREFLINK(stat.st_mode) from the user space since du(1) always
>> fetching the statistics per file disk space accounting.
>   I agree that adding filtering to FIEMAP just to accomodate the only
> practical use case of checking whether a file has any shared extent is
> really an overkill. But changing stat(2) the way you describe is ugly hack.
> st_mode has logically nothing to do with whether file has shared extents or
> not. If anything you could use ioctl IOC_GETFLAGS for that. I'm not 100%
> sure that's the right interface but at least it isn't that ugly.
Hi Jan,

Thanks for your quick response and thanks for pointing me out, I have
not realized this interface before, looks it's very nice in this
situation, I'll try it out. :)

Regards,
-Jeff