linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org, Satya Tangirala <satyat@google.com>,
	Eric Biggers <ebiggers@kernel.org>,
	linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH v7 0/8] add support for direct I/O with fscrypt using blk-crypto
Date: Tue, 17 Nov 2020 09:20:56 -0800	[thread overview]
Message-ID: <20201117172056.GW9695@magnolia> (raw)
In-Reply-To: <20201117171526.GD445084@mit.edu>

On Tue, Nov 17, 2020 at 12:15:26PM -0500, Theodore Y. Ts'o wrote:
> 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.

In Ye Olde days there was XFS_IOC_DIOINFO to communicate all that (xfs
hardcodes 512b file offset alignment), but in this modern era perhaps
it's time to shovel that into statx...

--D

> 
> 						- Ted


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2020-11-17 17:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17 14:07 [f2fs-dev] [PATCH v7 0/8] add support for direct I/O with fscrypt using blk-crypto Satya Tangirala via Linux-f2fs-devel
2020-11-17 14:07 ` [f2fs-dev] [PATCH v7 1/8] block: ensure bios are not split in middle of crypto data unit Satya Tangirala via Linux-f2fs-devel
2020-11-17 23:31   ` Eric Biggers
2020-11-18  0:38     ` Satya Tangirala via Linux-f2fs-devel
2020-11-25 22:12       ` Eric Biggers
2020-12-02 22:52         ` Satya Tangirala via Linux-f2fs-devel
2020-11-25 22:15   ` Eric Biggers
2020-11-17 14:07 ` [f2fs-dev] [PATCH v7 2/8] blk-crypto: don't require user buffer alignment Satya Tangirala via Linux-f2fs-devel
2020-11-17 23:51   ` Eric Biggers
2020-11-17 14:07 ` [f2fs-dev] [PATCH v7 3/8] fscrypt: add functions for direct I/O support Satya Tangirala via Linux-f2fs-devel
2020-11-17 14:07 ` [f2fs-dev] [PATCH v7 4/8] direct-io: add support for fscrypt using blk-crypto Satya Tangirala via Linux-f2fs-devel
2020-11-17 14:07 ` [f2fs-dev] [PATCH v7 5/8] iomap: support direct I/O with " Satya Tangirala via Linux-f2fs-devel
2020-11-17 14:07 ` [f2fs-dev] [PATCH v7 6/8] ext4: " Satya Tangirala via Linux-f2fs-devel
2020-12-03 13:45   ` Theodore Y. Ts'o
2020-11-17 14:07 ` [f2fs-dev] [PATCH v7 7/8] f2fs: " Satya Tangirala via Linux-f2fs-devel
2020-11-17 14:07 ` [f2fs-dev] [PATCH v7 8/8] fscrypt: update documentation for direct I/O support Satya Tangirala via Linux-f2fs-devel
2020-11-18  2:38   ` Eric Biggers
2020-11-17 17:15 ` [f2fs-dev] [PATCH v7 0/8] add support for direct I/O with fscrypt using blk-crypto Theodore Y. Ts'o
2020-11-17 17:20   ` Darrick J. Wong [this message]
2020-12-03 23:57   ` Satya Tangirala via Linux-f2fs-devel
2020-11-18  2:51 ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201117172056.GW9695@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=axboe@kernel.dk \
    --cc=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=satyat@google.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).