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

Hello,

We have the user requests to show the real disk usage for OCFS2/Btrfs with
reflinked/cloned files.  AFAICS, integrate the existing fiemap interface to
du(1) is
fine to solve this issue because OCFS2 can return an extent in
FIEMAP_EXTENT_SHARED
state which is used to indicate the extent is reflinked, and Btrfs can be
improved
in the similar approach in the future.

Now another issue is regarding the performance when call fiemap ioctl(2) against
a
large file(like virtual disk images).  Assuming we created a 20Gb reflinked
file,
the first 19Gb has been written(COWed), and the left 1Gb is still in shared
status,
the user space has to call fiemap for multiple times to fetch the ending shared
extents,
that is not good if the target disk have many reflinked files in such
situations.

I'd like to introduce a new flag FIEMAP_FLAG_COW to the fiemap interface, if
this flag is
set, the kernel space will only return the mapped extents in shared state, as a
result, we
can reduce the overheads for calling fiemap again an again.

Test program to verify the FIEMAP_FLAG_COW flag:
https://github.com/pibroch/fiemap_cow/blob/master/cow_test.c

Create reflink file on OCFS2:
https://github.com/pibroch/fiemap_cow/blob/master/ocfs2_reflink.c


Any comments are appreciated, thanks!

-Jeff

Hello,

On Wed 20-02-13 11:59:17, Jeff Liu wrote:
> We have the user requests to show the real disk usage for OCFS2/Btrfs
> with reflinked/cloned files.  AFAICS, integrate the existing fiemap
> interface to du(1) is fine to solve this issue because OCFS2 can return
> an extent in FIEMAP_EXTENT_SHARED state which is used to indicate the
> extent is reflinked, and Btrfs can be improved in the similar approach in
> the future.
> 
> Now another issue is regarding the performance when call fiemap ioctl(2)
> against a large file (like virtual disk images).  Assuming we created a
> 20Gb reflinked file, the first 19Gb has been written(COWed), and the left
> 1Gb is still in shared status, the user space has to call fiemap for
> multiple times to fetch the ending shared extents, that is not good if
> the target disk have many reflinked files in such situations.
  Can you gather some performance numbers please - i.e. how long does it take
to map such file without FIEMAP_FLAG_COW and how long with it? I'm not
completely convinced it will make such a huge difference in practice (given
du(1) isn't very performance critical application).
> I'd like to introduce a new flag FIEMAP_FLAG_COW to the fiemap
interface,
> if this flag is set, the kernel space will only return the mapped extents
> in shared state, as a result, we can reduce the overheads for calling
> fiemap again an again.
  I'm a bit uneasy about this 'filtering' function of flags. But I
guess
there aren't that many extent types so that flags couldn't accomodate
that.
So if you show something like this is necessary to make du(1) application
practical, then I guess I can bear it.

								Honza
-- 
Jan Kara <jack at suse.cz>
SUSE Labs, CR