> > 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. Agreed: avoiding the fiemap extent walk entirely is reasonable, and st_mode is a strange place to put a flag that indicates that some extents might have the SHARED bit :). GETFLAGS doesn't seem so bad. It seems like the real fix, though, is to have the fs track shared logical file offset regions with a counter in the inode like it does for size and blocks. Extending stat() to report this to userspace would probably be very annoying; maybe a synthetic xattr would work. - z -- 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
