From: "Pádraig Brady" <P@draigBrady.com>
To: Sunil Mushran <sunil.mushran@oracle.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Dave Chinner <david@fromorbit.com>,
Josef Bacik <josef@redhat.com>,
linux-fsdevel@vger.kernel.org, viro@ZenIV.linux.org.uk,
linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org,
xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests 255: add a seek_data/seek_hole tester
Date: Wed, 29 Jun 2011 22:29:57 +0100 [thread overview]
Message-ID: <4E0B9955.3040905@draigBrady.com> (raw)
In-Reply-To: <4E0B60DE.50908@oracle.com>
On 29/06/11 18:29, Sunil Mushran wrote:
> On 06/29/2011 03:42 AM, Pádraig Brady wrote:
>> There is the argument, that if this interface can distinguish
>> these dirty unwritten extents, then why can't the fiemap interface too?
>> The advantage of the fiemap interface is that it can distinguish
>> empty extents vs holes. Empty extents will become increasingly common
>> I think, given the fragmentation and space guarantee benefits they give.
>> It would be cool for cp for example to be able to efficiently copy
>> empty extents from source to dest.
>
> I'm not too sure about that. Atleast not enabled by default. Most users
> use cp to backup data. Not empty space. In this case, this empty extent
> may not even be de-dupable.
That's a fair point. On the other hand if
you wanted to start working with the backup copy,
you might want it allocated to avoid fragmentation and ENOSPC issues.
What we were going with was empty -> hole with cp --sparse=always
and empty -> empty otherwise. If empty and hole can not be
distinguished though, then this process will be impacted.
>
> Frankly I'd be happier of cp started to exploited fallocate() to create
> larger
> extents before copying data into them. Atleast for the large files.
Yes we definitely will start doing that.
That will help fragmentation and give early ENOSPC.
We can't use fiemap for this at the moment
(on XSF or ext4 (without a sync))
but the seek_data interface should allow us
to do this to some extent (pardon the pun).
cheers,
Pádraig.
next prev parent reply other threads:[~2011-06-29 21:30 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-28 15:33 [PATCH 1/4] fs: add SEEK_HOLE and SEEK_DATA flags Josef Bacik
2011-06-28 15:33 ` [PATCH 2/4] Btrfs: implement our own ->llseek Josef Bacik
2011-06-28 15:33 ` [PATCH 3/4] Ext4: handle SEEK_HOLE/SEEK_DATA generically Josef Bacik
2011-06-28 15:33 ` [PATCH 4/4] fs: handle SEEK_HOLE/SEEK_DATA properly in all fs's that define their own llseek Josef Bacik
2011-06-28 15:33 ` [PATCH] xfstests 255: add a seek_data/seek_hole tester Josef Bacik
2011-06-29 6:53 ` Dave Chinner
2011-06-29 7:40 ` Christoph Hellwig
2011-06-29 10:42 ` Pádraig Brady
2011-06-29 17:29 ` Sunil Mushran
2011-06-29 17:36 ` Christoph Hellwig
2011-06-29 17:40 ` Sunil Mushran
2011-06-29 21:29 ` Pádraig Brady [this message]
2011-07-01 9:37 ` Christoph Hellwig
2011-06-29 17:10 ` Sunil Mushran
2011-06-29 17:52 ` Josef Bacik
2011-06-29 13:19 ` Josef Bacik
2011-08-25 6:06 ` Christoph Hellwig
2011-08-25 6:40 ` Dave Chinner
2011-08-25 6:51 ` Andreas Dilger
2011-08-26 1:35 ` Dave Chinner
2011-08-26 6:24 ` Marco Stornelli
2011-08-26 14:41 ` Zach Brown
2011-08-27 8:30 ` Marco Stornelli
2011-08-28 10:17 ` Marco Stornelli
2011-08-30 17:42 ` Sunil Mushran
2011-08-31 1:17 ` Sunil Mushran
2011-08-31 3:29 ` Dave Chinner
2011-08-31 3:53 ` david
2011-08-31 4:43 ` Sunil Mushran
2011-08-31 9:05 ` Pádraig Brady
2011-08-31 4:48 ` Dan Merillat
2011-07-29 9:58 ` [PATCH 1/4] fs: add SEEK_HOLE and SEEK_DATA flags Marco Stornelli
2011-08-20 9:41 ` Marco Stornelli
2011-08-20 10:03 ` Marco Stornelli
2011-08-20 15:36 ` Sunil Mushran
2011-08-20 16:32 ` Marco Stornelli
2011-08-22 6:08 ` Sunil Mushran
2011-08-22 10:56 ` Marco Stornelli
2011-08-22 15:57 ` Sunil Mushran
2011-08-22 17:56 ` Marco Stornelli
2011-08-22 21:22 ` Sunil Mushran
2011-08-23 17:44 ` Marco Stornelli
2011-08-31 0:35 ` Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2011-06-27 18:02 Josef Bacik
2011-06-27 18:02 ` [PATCH] xfstests 255: add a seek_data/seek_hole tester Josef Bacik
2011-06-27 18:32 ` Andreas Dilger
2011-06-27 18:47 ` Josef Bacik
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=4E0B9955.3040905@draigBrady.com \
--to=p@draigbrady.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=josef@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sunil.mushran@oracle.com \
--cc=viro@ZenIV.linux.org.uk \
--cc=xfs@oss.sgi.com \
/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