linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>, 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 05:09:02 -0700	[thread overview]
Message-ID: <20180613120902.GA28014@infradead.org> (raw)
In-Reply-To: <20180613074150.GA19934@dastard>

On Wed, Jun 13, 2018 at 05:41:50PM +1000, Dave Chinner wrote:
> > 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.
> 
> Ok, we're saying the same things - it wasn't clear to me that your
> proposal was to document both behaviours as valid...

Even if both are valid we should come to a conclusion which behavior
make more sense and switch everyone to it.

Right now we have two users of iomap_fiemap (gfs2 and xfs), and three
users of generic_block_fiemap (ext2, ext4 and hpfs), out of which two
already have iomap infrastructure and could be converted to the iomap
variant trivially, and three entirely open coded instances (f2fs, nilfs,
ocfs) which look like they could benefit a lot from using common code.

It doesn't make sense to have different implementations and different
behavior for no good reason.

  reply	other threads:[~2018-06-13 12:09 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
2018-06-13  7:41                   ` Dave Chinner
2018-06-13 12:09                     ` Christoph Hellwig [this message]
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=20180613120902.GA28014@infradead.org \
    --to=hch@infradead.org \
    --cc=cmaiolino@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mfasheh@suse.de \
    --cc=sandeen@sandeen.net \
    --cc=tytso@mit.edu \
    /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).