From: Jeff Liu <jeff.liu@oracle.com>
To: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger@dilger.ca>,
Dave Chinner <david@fromorbit.com>,
Mark Fasheh <mfasheh@suse.com>, Joel Becker <jlbec@evilplan.org>,
Jan Kara <jack@suse.cz>, Chris Mason <chris.mason@fusionio.com>,
Christoph Hellwig <hch@infradead.org>,
ocfs2-devel@oss.oracle.com
Subject: [RFC PATCH 0/3] copy-on-write extents mapping
Date: Wed, 20 Feb 2013 11:59:17 +0800 [thread overview]
Message-ID: <51244A15.2060508@oracle.com> (raw)
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
next reply other threads:[~2013-02-20 4:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-20 3:59 Jeff Liu [this message]
2013-02-21 15:25 ` [RFC PATCH 0/3] copy-on-write extents mapping Jan Kara
2013-02-21 18:00 ` Zach Brown
2013-02-24 13:42 ` Jeff Liu
2013-02-25 13:28 ` Jan Kara
2013-02-25 14:19 ` Jeff Liu
2013-02-25 17:14 ` Zach Brown
2013-03-02 10:46 ` Joel Becker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51244A15.2060508@oracle.com \
--to=jeff.liu@oracle.com \
--cc=adilger@dilger.ca \
--cc=chris.mason@fusionio.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jlbec@evilplan.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mfasheh@suse.com \
--cc=ocfs2-devel@oss.oracle.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).