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@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
