From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.133]:51834 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933262AbeFUMVV (ORCPT ); Thu, 21 Jun 2018 08:21:21 -0400 Date: Thu, 21 Jun 2018 05:21:16 -0700 From: Christoph Hellwig To: Jens Axboe Cc: Andrew Morton , linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk Subject: Re: [PATCHSET v3 0/4] Submit ->readpages() IO as read-ahead Message-ID: <20180621122116.GA14053@infradead.org> References: <1527691329-2371-1-git-send-email-axboe@kernel.dk> <20180619165640.0c36473a33e20ea6c0fda463@linux-foundation.org> <9b1d2225-104d-865f-d821-8670271d6d4a@kernel.dk> <20180620125801.6e563efc5ed6af2f12c27f07@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Jun 20, 2018 at 04:28:54PM -0600, Jens Axboe wrote: > The assumption has been true for a decade or more. The only problem with > it is that we have this ->readpages() interface that is only used for > readahead. Hence it should be ->readahead() or similar, that avoid the > fragility argument. Or just stop this whole bike shed. ->readpages doesn't keep the pages it reads locked, so it fundamentally is a readahead style operation. Now if we actually want do to anything with that information is another question that I already asked in reply to the first round of these patches. Especially as e.g. nvme actually sets hints based on the flag, that if hardware actually ever looked at them might be doing the wrong thing (fortunately for us I doubt any nvme hardware actually looks at that flag).