On 10/31/2012 07:31 PM, David Sterba wrote:
> On Wed, Oct 31, 2012 at 10:30:22AM +0800, Jeff Liu wrote:
>> One idea is to mark those cloned extents as FIEMAP_EXTENT_SHARED so that
>> we can go through a file to figure out how many extents are shared
>> through fiemap(2), and calculate the real storage(fs/subvolume) footprint
>> in the end.
> 
> This will cost at least one more seek per extent to find out that the
> extent is shared, could be quite expensive.
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

Do you means that the costs is very expensive for userland extent status 
checkup per file?
If yes, I have once tested an 50Gb OCFS2 partition filled with reflinked files 
on an old laptop,
it spent around 4 minutes to show the totally results if I recalled correct, 
but this definitely
depending on the real world scenarios.

> 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. 
:(

Thanks,
-Jeff
> 
> david
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to