linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Ritesh Harjani <riteshh@linux.ibm.com>
Cc: Christoph Hellwig <hch@infradead.org>, Jan Kara <jack@suse.cz>,
	tytso@mit.edu, "Darrick J. Wong" <darrick.wong@oracle.com>,
	adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, cmaiolino@redhat.com
Subject: Re: [RFCv2 0/4] ext4: bmap & fiemap conversion to use iomap
Date: Fri, 21 Feb 2020 12:47:09 +0100	[thread overview]
Message-ID: <20200221114709.GB27165@quack2.suse.cz> (raw)
In-Reply-To: <20200221041644.53A9852052@d06av21.portsmouth.uk.ibm.com>

On Fri 21-02-20 09:46:43, Ritesh Harjani wrote:
> 
> 
> On 2/20/20 10:39 PM, Christoph Hellwig wrote:
> > On Thu, Feb 20, 2020 at 10:33:03PM +0530, Ritesh Harjani wrote:
> > > So I was making some changes along the above lines and I think we can take
> > > below approach for filesystem which could determine the
> > > _EXTENT_LAST relatively easily and for cases if it cannot
> > > as Jan also mentioned we could keep the current behavior as is and let
> > > iomap core decide the last disk extent.
> > 
> > Well, given that _EXTENT_LAST never worked properly on any file system
> > since it was added this actually changes behavior and could break
> > existing users.  I'd rather update the documentation to match reality
> > rather than writing a lot of code for a feature no one obviously cared
> > about for years.
> 
> Well I agree to this. Since either ways the _EXTENT_LAST has never worked
> properly or in the same manner across different filesystems.
> In ext4 itself it works differently for extent v/s non-extent based FS.
> So updating the documentation would be a right way to go from here.
> 
> Ted/Jan - do you agree here:-
> Shall we move ahead with this patch series in converting ext4_fiemap to
> use iomap APIs, without worrying about how _EXTENT_LAST is being set via
> iomap core code?

Yes, I'd go ahead with the conversion and don't really bother with backward
compatibility here. In the unlikely case someone comes with a real breakage
this causes, we can always think about how to fix this.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2020-02-21 11:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-28 10:18 [RFCv2 0/4] ext4: bmap & fiemap conversion to use iomap Ritesh Harjani
2020-01-28 10:18 ` [RFCv2 1/4] ext4: Add IOMAP_F_MERGED for non-extent based mapping Ritesh Harjani
2020-01-28 10:18 ` [RFCv2 2/4] ext4: Optimize ext4_ext_precache for 0 depth Ritesh Harjani
2020-01-28 10:18 ` [RFCv2 3/4] ext4: Move ext4 bmap to use iomap infrastructure Ritesh Harjani
2020-01-28 10:18 ` [RFCv2 4/4] ext4: Move ext4_fiemap " Ritesh Harjani
2020-01-28 15:28   ` Darrick J. Wong
2020-01-29  6:19     ` Ritesh Harjani
2020-01-29 16:18       ` Darrick J. Wong
2020-01-29 23:54         ` Ritesh Harjani
2020-01-30 16:00 ` [RFCv2 0/4] ext4: bmap & fiemap conversion to use iomap Darrick J. Wong
2020-01-30 17:34   ` Ritesh Harjani
2020-02-05 12:47   ` Ritesh Harjani
2020-02-05 15:57     ` Darrick J. Wong
2020-02-06  5:26       ` Ritesh Harjani
2020-02-06 10:22         ` Jan Kara
2020-02-20 17:03           ` Ritesh Harjani
2020-02-20 17:09             ` Christoph Hellwig
2020-02-21  4:16               ` Ritesh Harjani
2020-02-21 11:47                 ` Jan Kara [this message]
2020-02-21  4:10             ` Ritesh Harjani

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=20200221114709.GB27165@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=adilger.kernel@dilger.ca \
    --cc=cmaiolino@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=riteshh@linux.ibm.com \
    --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).