Re: [RFC PATCH 0/3] copy-on-write extents mapping

[Jan Kara <jack@suse.cz>]

  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@suse.cz>
SUSE Labs, CR