From: Dave Chinner <david@fromorbit.com>
To: jim owens <jowens@hp.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2
Date: Fri, 4 Jul 2008 08:51:24 +1000 [thread overview]
Message-ID: <20080703225124.GB29319@disturbed> (raw)
In-Reply-To: <486CC1FA.10003@hp.com>
On Thu, Jul 03, 2008 at 08:11:38AM -0400, jim owens wrote:
> Dave Chinner wrote:
>
>> xfs_bmap provides an atomic sync and mapping. If the
>> FIEMAP_FLAG_SYNC is pushed down to the filesystem, then XFS
>> and all other filesystems can provide that same atomicity if
>> desired.
>
> That is exactly what I was afraid of.
Why? Have you ever used an extent mapping interface before?
> We are back to the "because XFS has it" argument.
Given that one of the original desires was to have the fiemap ioctl
*replace the XFS ioctl*, I'm kinda getting sick of people saying "we
don't want this because only it's only an XFS feature" depsite the
fact that wإat we are doing here is re-implemented long standing XFS
interfaces. XFS is going to have to maintain two extent mapping
interfaces forever more because we don't have everything in fiemap
that we need to replace the XFS ioctl.
The point of this SYNC flag is to ensure that you get nothing other
than blocks mapped to disk - no delalloc regions, etc. The only sane
way to do that is an atomic 'sync+map' operation. This is not a
filesystem specific feature - it's what the SYNC flag should be
defined as providing.
The fact that it's only implemented in XFS right now has absolutely
*zero* consideration in determining this feature is necessary or
not. The fact that the only existing extent mapping interface in
Linux already defines it this way and it is in use by existing
userspace utilities that *expect this semantic* is much, much more
important.
Speaking of which, some of the features in fiemap are currently
OCFS2 specific, some that are Lustre(!) specific or not even used
by current filesystems or implementations of fiemap. However,
nobody is complaining that they should be ripped out just because
they are only implemented in filesystem X....
FWIW, if ext4 had this atomic sync+map (which it could do), would
you still be complaining about it?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-07-03 22:51 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-25 22:18 [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2 Mark Fasheh
2008-06-26 3:03 ` Andreas Dilger
2008-06-26 9:36 ` Jamie Lokier
2008-06-26 10:24 ` Andreas Dilger
2008-06-26 11:37 ` Anton Altaparmakov
2008-06-26 12:19 ` Jamie Lokier
2008-06-26 13:16 ` Dave Chinner
2008-06-26 13:27 ` Jamie Lokier
2008-06-26 13:48 ` Eric Sandeen
2008-06-26 14:16 ` Jamie Lokier
2008-06-26 16:56 ` Andreas Dilger
2008-06-29 19:12 ` Anton Altaparmakov
2008-06-29 21:45 ` Dave Chinner
2008-06-30 22:57 ` Jamie Lokier
2008-06-30 23:07 ` Mark Fasheh
2008-07-01 2:01 ` Brad Boyer
2008-07-02 6:38 ` Andreas Dilger
2008-07-02 6:33 ` Andreas Dilger
2008-07-02 14:26 ` Jamie Lokier
2008-06-26 17:17 ` Andreas Dilger
2008-06-26 14:03 ` Eric Sandeen
2008-06-27 1:41 ` Dave Chinner
2008-06-27 9:41 ` Jamie Lokier
2008-06-27 10:01 ` Dave Chinner
2008-06-27 10:32 ` Jamie Lokier
2008-06-27 22:48 ` Andreas Dilger
2008-06-28 4:21 ` Eric Sandeen
2008-07-02 6:26 ` Andreas Dilger
2008-07-02 14:28 ` Jamie Lokier
2008-07-02 21:20 ` Mark Fasheh
2008-07-03 14:45 ` Jamie Lokier
2008-06-26 14:04 ` Dave Kleikamp
2008-06-26 14:15 ` Eric Sandeen
2008-06-26 14:27 ` Dave Kleikamp
2008-07-02 23:48 ` jim owens
2008-07-03 11:17 ` Dave Chinner
2008-07-03 12:11 ` jim owens
2008-07-03 22:51 ` Dave Chinner [this message]
2008-07-04 8:31 ` Andreas Dilger
2008-07-04 12:13 ` Jamie Lokier
2008-07-07 7:40 ` Dave Chinner
2008-07-07 16:53 ` Jamie Lokier
2008-07-07 22:51 ` Dave Chinner
2008-07-07 21:16 ` jim owens
2008-07-08 3:01 ` Dave Chinner
2008-07-07 22:02 ` jim owens
2008-07-09 2:03 ` Jamie Lokier
2008-07-03 12:21 ` jim owens
2008-07-03 12:42 ` Andi Kleen
2008-07-04 20:32 ` Anton Altaparmakov
2008-07-05 10:49 ` Jamie Lokier
2008-07-05 21:44 ` Anton Altaparmakov
2008-07-07 23:01 ` jim owens
2008-07-08 1:51 ` Dave Chinner
2008-07-08 13:02 ` jim owens
2008-07-08 14:03 ` jim owens
2008-07-08 14:39 ` jim owens
2008-07-08 14:30 ` Theodore Tso
2008-07-09 1:50 ` Jamie Lokier
2008-06-26 17:01 ` Andreas Dilger
2008-07-03 14:37 ` jim owens
2008-07-03 15:17 ` Jamie Lokier
2008-07-04 8:49 ` Andreas Dilger
2008-07-04 11:28 ` Jamie Lokier
2008-07-03 23:00 ` Dave Chinner
2008-07-04 9:00 ` Andreas Dilger
2008-07-07 23:28 ` jim owens
2008-07-09 1:53 ` Jamie Lokier
2008-07-09 15:01 ` jim owens
2008-07-08 0:06 ` jim owens
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=20080703225124.GB29319@disturbed \
--to=david@fromorbit.com \
--cc=jowens@hp.com \
--cc=linux-fsdevel@vger.kernel.org \
/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).