On Wed, Oct 31, 2012 at 09:02:15PM +0800, Jeff Liu wrote:

I propose this because OCFS2 report shared space in this way combine with du(1).

An old patch set to teach du(1) aware of reflinked file:
https://oss.oracle.com/pipermail/ocfs2-devel/2010-September/007293.html

Patch looks ok, the shared size is requested by an option.

Do you means that the costs is very expensive for userland extent status checkup per file?

The most expensive part is IMO not in userspace, it does in-memory lookups.

quoted

And without any possibility to turn this off,I'm afraid this will render FIEMAP unusable in practice.

For OCFS2, the FIEMAP_EXTENT_SHARED flag will be set upon fiemap ioctl(2) if an extent
is OCFS2_EXT_REFCOUNTED(i.e. reflinked or cloned), which means that FIEMAP_EXTENT_SHARED
is not a persistent flag, but I have no idea how Btrfs would be in this point. :(

After some research, I think this could work for btrfs without
unwanted performance penalties.

There's the fiemap::fm_flags field that can be extended to request the
shared extent info from fiemap, so the information is not computed
unconditionally (that was my concern before). The rest is only
implementation details how to speed up the file extent -> refcount info
lookups.

david