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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
