From: jim owens <jowens@hp.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2
Date: Mon, 07 Jul 2008 18:02:15 -0400 [thread overview]
Message-ID: <48729267.6040604@hp.com> (raw)
In-Reply-To: <20080703225124.GB29319@disturbed>
Dave Chinner wrote:
> 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.
If the real need is to force allocation then the flag should
be something like FIEMAP_FLAG_ALLOC and not need to do fsync
or any data flush, just ensure there is assigned storage.
> Linux already defines it this way and it is in use by existing
> userspace utilities that *expect this semantic* is much, much more
> important.
From you and Anton, I understand the only critical semantic
is to never get back a delalloc from xfs. But, I still don't
see the critical need when in a later email you say:
> The only application that uses the XFS ioctls are
> xfs utilities, and they tend to work around the assumption
> that the mapping operation returns a consistent map at the
> time the call was made.
So... the situation is you are saying you must keep it
the same for the utilities that are XFS-specific and that
you must change anyway to use fiemap. As Jamie said, just
put in the code to skip any unknown extents.
Before replying, wait for the next email that says why
I think those utilities have semantic problems too.
jim
next prev parent reply other threads:[~2008-07-07 22:02 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
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 [this message]
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=48729267.6040604@hp.com \
--to=jowens@hp.com \
--cc=david@fromorbit.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).