From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Satya Tangirala <satyat@google.com>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-xfs@vger.kernel.org,
"Darrick J . Wong" <darrick.wong@oracle.com>,
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
Eric Biggers <ebiggers@kernel.org>,
linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH v7 0/8] add support for direct I/O with fscrypt using blk-crypto
Date: Tue, 17 Nov 2020 12:15:26 -0500 [thread overview]
Message-ID: <20201117171526.GD445084@mit.edu> (raw)
In-Reply-To: <20201117140708.1068688-1-satyat@google.com>
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
next prev parent reply other threads:[~2020-11-17 17:31 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 ` Theodore Y. Ts'o [this message]
2020-11-17 17:20 ` [f2fs-dev] [PATCH v7 0/8] add support for direct I/O with fscrypt using blk-crypto Darrick J. Wong
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=20201117171526.GD445084@mit.edu \
--to=tytso@mit.edu \
--cc=axboe@kernel.dk \
--cc=darrick.wong@oracle.com \
--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 \
/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).