Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 4 Nov 2019 11:08:23 -0500
From:   "Theodore Y. Ts'o" <tytso@mit.edu>
To:     Matthew Bobrowski <mbobrowski@mbobrowski.org>
Cc:     Ritesh Harjani <riteshh@linux.ibm.com>, jack@suse.cz,
        linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC 0/5] Ext4: Add support for blocksize < pagesize for
 dioread_nolock
Message-ID: <20191104160823.GI28764@mit.edu>
References: <20191016073711.4141-1-riteshh@linux.ibm.com>
 <20191023232614.GB1124@mit.edu>
 <20191029071925.60AABA405B@b06wcsmtp001.portsmouth.uk.ibm.com>
 <20191103191606.GB8037@mit.edu>
 <20191104101623.GB27115@bobrowski>
 <20191104103759.4085C4C046@d06av22.portsmouth.uk.ibm.com>
 <20191104104913.GC27115@bobrowski>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191104104913.GC27115@bobrowski>
User-Agent: Mutt/1.12.2 (2019-09-21)
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

On Mon, Nov 04, 2019 at 09:49:14PM +1100, Matthew Bobrowski wrote:
> > It sure may be giving a merge conflict (due to io_end structure).
> > But this dioread_nolock series was not dependent over iomap series.
> 
> Uh ha. Well, there's been a chunk of code injected into
> ext4_end_io_dio() here and by me removing it, I'm not entirely sure
> what the downstream effects will be for this specific change...

Yeah, that was probably my failure to do the merge correctly; I'm
hoping that Ritesh will be able to fix that up.  If not we can throw
an "experimental" config to enable dioread_nolock on subpage
blocksizes, just to warn people that under some extreme workloads,
they might end up corrupting their allocation bitmap, which then might
lead to data loss.  I suspect it would actually work fine for most
users; but out of paranoia, if we can't figure out the generic/270
failure before the merge window, we can just make dioread_nolock_1k
experimental for now.

  	      	     	       		- Ted