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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 B1091C2D0E4 for ; Tue, 17 Nov 2020 17:31:41 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 156EB24199 for ; Tue, 17 Nov 2020 17:31:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="FsyTRt/V"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="kFm43R55" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 156EB24199 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kf4pO-00006C-TY; Tue, 17 Nov 2020 17:31:38 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kf4pM-0008OY-V3 for linux-f2fs-devel@lists.sourceforge.net; Tue, 17 Nov 2020 17:31:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; 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:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Zdh5lewhBVzLnXIlezHPpsXCdaW9+Zml0vPmNW9oRo0=; b=FsyTRt/V5EnlCRCPZSVnFMHM2w up9DyYGNNVI2hnTw3g8RwagHXsxJwlIhDmY7J2Fb0Cy/C0Mz/qgCWrefNOPDdk05ucppTn+bFMDBq m3K81MQf+tLGxF5Rv8G9nvONcC/5e0loXaR2R54KjsGFrz1uDMRUfJGSfO7SPE3og0gw=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; 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:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Zdh5lewhBVzLnXIlezHPpsXCdaW9+Zml0vPmNW9oRo0=; b=kFm43R55Qi7X4kHYDBuzHcLpbF YWc3R757Xj7Tn4+mK+BRPuFnovGDAUPZBgSFuUK3dh8rRojF6rPLikEV8TyCmrj9u9C9ZeUdW7ecz KkPbbaPzziZIf98IbazWukFQ3sNO20L4cVvbsDtJ9yWmqqGItTa6XSPx5I/dai4m7UBw=; Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1kf4a6-00ArAN-Vl for linux-f2fs-devel@lists.sourceforge.net; Tue, 17 Nov 2020 17:15:54 +0000 Received: from callcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AHHFQSN025997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Nov 2020 12:15:27 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 611CD420107; Tue, 17 Nov 2020 12:15:26 -0500 (EST) Date: Tue, 17 Nov 2020 12:15:26 -0500 From: "Theodore Y. Ts'o" To: Satya Tangirala Message-ID: <20201117171526.GD445084@mit.edu> References: <20201117140708.1068688-1-satyat@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201117140708.1068688-1-satyat@google.com> X-Headers-End: 1kf4a6-00ArAN-Vl Subject: Re: [f2fs-dev] [PATCH v7 0/8] add support for direct I/O with fscrypt using blk-crypto X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jens Axboe , linux-xfs@vger.kernel.org, "Darrick J . Wong" , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Eric Biggers , linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org, Jaegeuk Kim , linux-ext4@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net What is the expected use case for Direct I/O using fscrypt? This isn't a problem which is unique to fscrypt, but one of the really unfortunate aspects of the DIO interface is the silent fallback to buffered I/O. We've lived with this because DIO goes back decades, and the original use case was to keep enterprise databases happy, and the rules around what is necessary for DIO to work was relatively well understood. But with fscrypt, there's going to be some additional requirements (e.g., using inline crypto) required or else DIO silently fall back to buffered I/O for encrypted files. Depending on the intended use case of DIO with fscrypt, this caveat might or might not be unfortunately surprising for applications. I wonder if we should have some kind of interface so we can more explicitly allow applications to query exactly what the requirements might be for a particular file vis-a-vis Direct I/O. What are the memory alignment requirements, what are the file offset alignment requirements, what are the write size requirements, for a particular file. - Ted _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel