From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6BAEC432BE for ; Fri, 23 Jul 2021 19:41:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C12AD60EAF for ; Fri, 23 Jul 2021 19:41:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230124AbhGWTAr (ORCPT ); Fri, 23 Jul 2021 15:00:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229528AbhGWTAq (ORCPT ); Fri, 23 Jul 2021 15:00:46 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8AE78C061575; Fri, 23 Jul 2021 12:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=wLxpkipMgvxMPaddvglb23fn92nRwXLxVzoe/PF9JSQ=; b=DUvza/oQxDEBXJqJ5qe+4PTwXC ChPVxolPzM+XTosRn0XRvWFQ1OexQFajE9Z4o9uitWBobGl7UU32YrNCyj13LnbxrrY7sbjBM5sOR jem8Ki3m+t/iECfVFQlshxNX45nc/eyPN3oj8wmvTLfxkTpY33/OiXq+3GtkUPO3QkQoHn9w6nVwp uzii5hHtVnIYlPPFUwAKLO3vYU7S7rkj+XqvPCeK8GEQtCKAATVF/wDFqFQwJgz4us0q/h/xs0hY6 WtG0OT4Y1X0p3fVH2+2M05eariMyo6FgboYSkFr32VXkQ9kHDCOKAkAzitN4xwH7RALnAOMwdwUqX gIUnrWJQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m712R-00BgWf-O0; Fri, 23 Jul 2021 19:41:00 +0000 Date: Fri, 23 Jul 2021 20:40:51 +0100 From: Matthew Wilcox To: Gao Xiang Cc: linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, LKML , Christoph Hellwig , "Darrick J . Wong" , Andreas Gruenbacher , Huang Jianan Subject: Re: [PATCH v7] iomap: make inline data support more flexible Message-ID: References: <20210723174131.180813-1-hsiangkao@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210723174131.180813-1-hsiangkao@linux.alibaba.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 24, 2021 at 01:41:31AM +0800, Gao Xiang wrote: > Add support for reading inline data content into the page cache from > nonzero page-aligned file offsets. This enables the EROFS tailpacking > mode where the last few bytes of the file are stored right after the > inode. > > The buffered write path remains untouched since EROFS cannot be used > for testing. It'd be better to be implemented if upcoming real users > care and provide a real pattern rather than leave untested dead code > around. My one complaint with this version is the subject line. It's a bit vague. I went with: iomap: Support file tail packing I also wrote a changelog entry that reads: The existing inline data support only works for cases where the entire file is stored as inline data. For larger files, EROFS stores the initial blocks separately and then can pack a small tail adjacent to the inode. Generalise inline data to allow for tail packing. Tails may not cross a page boundary in memory. ... but I'm not sure that's necessarily better than what you've written here. > Cc: Christoph Hellwig > Cc: Darrick J. Wong > Cc: Matthew Wilcox > Cc: Andreas Gruenbacher > Tested-by: Huang Jianan # erofs > Signed-off-by: Gao Xiang Reviewed-by: Matthew Wilcox (Oracle)