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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 1059BC0650F for ; Thu, 8 Aug 2019 08:17:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D6F0E2187F for ; Thu, 8 Aug 2019 08:17:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732003AbfHHIR6 (ORCPT ); Thu, 8 Aug 2019 04:17:58 -0400 Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:47740 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731281AbfHHIR5 (ORCPT ); Thu, 8 Aug 2019 04:17:57 -0400 Received: from dread.disaster.area (pa49-181-167-148.pa.nsw.optusnet.com.au [49.181.167.148]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 2411843E618; Thu, 8 Aug 2019 18:17:54 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92) (envelope-from ) id 1hvdbL-0001Bg-NE; Thu, 08 Aug 2019 18:16:47 +1000 Date: Thu, 8 Aug 2019 18:16:47 +1000 From: Dave Chinner To: Gao Xiang , Goldwyn Rodrigues , "hch@lst.de" , "darrick.wong@oracle.com" , "linux-btrfs@vger.kernel.org" , "ruansy.fnst@cn.fujitsu.com" , "linux-fsdevel@vger.kernel.org" , linux-erofs@lists.ozlabs.org, miaoxie@huawei.com Subject: Re: [PATCH 10/13] iomap: use a function pointer for dio submits Message-ID: <20190808081647.GI7689@dread.disaster.area> References: <20190802220048.16142-1-rgoldwyn@suse.de> <20190802220048.16142-11-rgoldwyn@suse.de> <20190804234321.GC7689@dread.disaster.area> <1565021323.13240.14.camel@suse.com> <20190805215458.GH7689@dread.disaster.area> <20190808042640.GA28630@138> <20190808054936.GA5319@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190808054936.GA5319@sol.localdomain> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=gu9DDhuZhshYSb5Zs/lkOA==:117 a=gu9DDhuZhshYSb5Zs/lkOA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=FmdZ9Uzk2mMA:10 a=7-415B0cAAAA:8 a=TBOsBtRu_f-vuJ8yFLgA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Wed, Aug 07, 2019 at 10:49:36PM -0700, Eric Biggers wrote: > FWIW, the only order that actually makes sense is decrypt->decompress->verity. *nod* Especially once we get the inline encryption support for fscrypt so the storage layer can offload the encrypt/decrypt to hardware via the bio containing plaintext. That pretty much forces fscrypt to be the lowest layer of the filesystem transformation stack. This hardware offload capability also places lots of limits on what you can do with block-based verity layers below the filesystem. e.g. using dm-verity when you don't know if there's hardware encryption below or software encryption on top becomes problematic... So really, from a filesystem and iomap perspective, What Eric says is the right - it's the only order that makes sense... Cheers, Dave. -- Dave Chinner david@fromorbit.com