linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>
Cc: Mark Fasheh <mfasheh@suse.de>,
	Carlos Maiolino <cmaiolino@redhat.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Eric Sandeen <sandeen@sandeen.net>,
	linux-fsdevel@vger.kernel.org, hch@infradead.org
Subject: Re: Ext4 fiemap implementation
Date: Wed, 13 Jun 2018 01:04:53 -0400	[thread overview]
Message-ID: <20180613050453.GA3808@thunk.org> (raw)
In-Reply-To: <20180613033204.GC5651@dastard>

On Wed, Jun 13, 2018 at 01:32:04PM +1000, Dave Chinner wrote:
> > Well, or the FIEMAP specs could be changed.  If I recall correctly the
> > FIEMAP implementation by the various file systems predates the
> > documentation.  I suspect whoever wrote the docs looked at the
> > ext2/ext3/ext4 implementation and used that to write the
> > documentation.  If other file systems were doing something else, I'd
> > be in favor of allowing either behavior, since userspace programs who
> > care will need to accomodate either behavior.  Fortunately, I suspect
> > it matters for very few (if any) userspace programs.
> 
> The horse has bolted - we can't redefine the expected behaviour as
> that might break apps like cp (yes, it's still using FIEMAP for
> sparse file optimisations).

As far as I know cp is working with the FIEMAP behavior as implemented
by ext4 and xfs w/o any problems.  Given that ext4 and xfs have been
doing different things for a *very* long time now, in that sense the
horse has already bolted.  There may be some applications that
expecting things the way ext4 has implemnted FIEMAP (and which is
either allowed or required by the documentation -- I read it as
mandated; others think it's a "you can do it either way"); and there
may be some applications that are expecting things the way XFS has
historically implemented FIEMAP.

So my proposal was to change the docs to make it clear that Eric
Sandeen's reading (that either way is fine) is the correct
interpretation.

                                        - Ted

  reply	other threads:[~2018-06-13  5:05 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-01 12:36 Ext4 fiemap implementation Carlos Maiolino
2018-06-01 15:01 ` Eric Sandeen
2018-06-03  3:28   ` Theodore Y. Ts'o
2018-06-04 16:43     ` Darrick J. Wong
2018-06-06 13:13       ` Carlos Maiolino
2018-06-06 14:40         ` Darrick J. Wong
2018-06-07  8:31           ` Carlos Maiolino
2018-06-07 16:25             ` Darrick J. Wong
2018-06-08  8:18               ` Carlos Maiolino
2018-06-08 22:41       ` Mark Fasheh
2018-06-11  7:28         ` Carlos Maiolino
2018-06-12 23:52           ` Mark Fasheh
2018-06-13  3:06             ` Theodore Y. Ts'o
2018-06-13  3:32               ` Dave Chinner
2018-06-13  5:04                 ` Theodore Y. Ts'o [this message]
2018-06-13  7:41                   ` Dave Chinner
2018-06-13 12:09                     ` Christoph Hellwig
2018-06-14  8:14                       ` Carlos Maiolino
2018-06-01 18:57 ` Andreas Dilger

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=20180613050453.GA3808@thunk.org \
    --to=tytso@mit.edu \
    --cc=cmaiolino@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mfasheh@suse.de \
    --cc=sandeen@sandeen.net \
    /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).