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

[Zach Brown]

> > 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