From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Andreas Dilger <adilger@dilger.ca>, Ted Ts'o <tytso@mit.edu>,
Eric Sandeen <sandeen@sandeen.net>,
Yongqiang Yang <xiaoqiangnk@gmail.com>, xfs-oss <xfs@oss.sgi.com>,
"coreutils@gnu.org" <coreutils@gnu.org>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
P?draig Brady <P@draigbrady.com>,
Markus Trippelsdorf <markus@trippelsdorf.de>
Subject: Re: Files full of zeros with coreutils-8.11 and xfs (FIEMAP related?)
Date: Wed, 20 Apr 2011 11:29:56 -0400 [thread overview]
Message-ID: <20110420152956.GA24641@infradead.org> (raw)
In-Reply-To: <20110419210825.GJ23985@dastard>
On Wed, Apr 20, 2011 at 07:08:25AM +1000, Dave Chinner wrote:
> So, it logically follws that you need to use the SYNC flag for both
> unwritten extents and delalloc extents to find out where there data
> realy lies by converting them to real, written extents. i.e. the
> only extents you can trust contain data from FIEMAP are the real
> extents on disk....
Even more funny is that the bug report that started this thread involved
software that didn't actually care about the location on disk, at all.
cp from coreutils really just wanted an efficient way to skip holes
in sparse files, and we got into a chain reaction of various flaws
and oversights :
(1) Linux lacks the SEEK_HOLE/SEEK_DATA interface that would make
skipping holes trivial and thus coreutils has to use FIEMAP.
(2) ext4 and btrfs in some cases mishandled reporting delalloc
extents, which means coreutils had to add the sync flag,
despite not caring where data is on disk
(3) coreutils tried to treat unwrittent extents as holes. Which
makes some sense given their high-level description, although
probably not too much in practice given that we explicitly
allocated blocks to these "holes" to optimize performance.
But the main issue here is that there is no documentation
that clearly states that unwrittent extents reported by
FIEMAP may actually contain useful data. In fact there's
no useful documentation for FIEMAP outside the kernel tree.
And interface that complex really needs a manpage.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-04-20 15:26 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-14 10:26 Files full of zeros with coreutils-8.11 and xfs (FIEMAP related?) Markus Trippelsdorf
2011-04-14 12:06 ` Markus Trippelsdorf
2011-04-14 14:02 ` Markus Trippelsdorf
2011-04-14 14:59 ` Pádraig Brady
2011-04-14 15:50 ` Eric Sandeen
2011-04-14 15:52 ` Pádraig Brady
2011-04-14 15:56 ` Eric Sandeen
2011-04-14 16:03 ` Markus Trippelsdorf
2011-04-14 16:14 ` Eric Sandeen
2011-04-14 16:21 ` Yongqiang Yang
2011-04-14 16:28 ` Markus Trippelsdorf
2011-04-14 16:31 ` Eric Sandeen
2011-04-14 16:48 ` Markus Trippelsdorf
2011-04-14 16:49 ` Eric Sandeen
2011-04-14 16:04 ` Yongqiang Yang
2011-04-14 16:10 ` Yongqiang Yang
2011-05-05 11:29 ` Pádraig Brady
2011-05-05 11:47 ` Yongqiang Yang
2011-04-14 17:27 ` Jim Meyering
2011-04-14 19:13 ` Pádraig Brady
2011-04-14 19:39 ` Jim Meyering
2011-04-14 22:59 ` Dave Chinner
2011-04-14 23:29 ` Pádraig Brady
2011-04-15 0:09 ` Dave Chinner
2011-04-15 5:01 ` Andreas Dilger
2011-04-16 0:50 ` Dave Chinner
2011-04-16 5:11 ` Andreas Dilger
2011-04-16 12:21 ` Theodore Tso
2011-04-18 0:40 ` Dave Chinner
2011-04-18 2:45 ` Andreas Dilger
2011-04-19 1:58 ` Yongqiang Yang
2011-04-19 2:59 ` Ted Ts'o
2011-04-19 3:05 ` Eric Sandeen
2011-04-21 20:12 ` Jim Meyering
2011-04-19 3:30 ` Yongqiang Yang
2011-04-19 4:14 ` Dave Chinner
2011-04-19 5:27 ` Christoph Hellwig
2011-04-19 3:44 ` Dave Chinner
2011-04-19 6:53 ` Yongqiang Yang
2011-04-19 7:45 ` Dave Chinner
2011-04-19 8:11 ` Yongqiang Yang
2011-04-19 14:05 ` Eric Sandeen
2011-04-19 14:09 ` Ted Ts'o
2011-04-19 14:13 ` Eric Sandeen
2011-04-19 16:01 ` Ted Ts'o
2011-04-20 1:53 ` Yongqiang Yang
2011-04-20 15:21 ` Christoph Hellwig
2011-04-20 17:21 ` Ted Ts'o
2011-04-19 21:08 ` Dave Chinner
2011-04-20 15:29 ` Christoph Hellwig [this message]
2011-04-16 6:05 ` Yongqiang Yang
2011-04-18 0:35 ` Dave Chinner
2011-04-15 8:53 ` Jim Meyering
2011-04-15 17:16 ` Christoph Hellwig
2011-04-15 17:24 ` Eric Blake
2011-04-15 17:26 ` Christoph Hellwig
2011-04-15 22:28 ` Andreas Dilger
2011-04-16 0:25 ` Dave Chinner
2011-04-14 14:39 ` Eric Sandeen
2011-04-20 14:39 ` Jim Meyering
2011-04-21 20:01 ` Jim Meyering
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=20110420152956.GA24641@infradead.org \
--to=hch@infradead.org \
--cc=P@draigbrady.com \
--cc=adilger@dilger.ca \
--cc=coreutils@gnu.org \
--cc=david@fromorbit.com \
--cc=linux-ext4@vger.kernel.org \
--cc=markus@trippelsdorf.de \
--cc=sandeen@sandeen.net \
--cc=tytso@mit.edu \
--cc=xfs@oss.sgi.com \
--cc=xiaoqiangnk@gmail.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