| Message ID | 20201117140708.1068688-1-satyat@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | add support for direct I/O with fscrypt using blk-crypto | expand |
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
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
On Tue, Nov 17, 2020 at 02:07:00PM +0000, Satya Tangirala wrote: > This patch series was tested by running xfstests with test_dummy_encryption > with and without the 'inlinecrypt' mount option, and there were no > meaningful regressions. One regression was for generic/587 on ext4, > but that test isn't compatible with test_dummy_encryption in the first > place, and the test "incorrectly" passes without the 'inlinecrypt' mount > option - a patch will be sent out to exclude that test when > test_dummy_encryption is turned on with ext4 (like the other quota related > tests that use user visible quota files). It would be helpful to have some more testing results that show that the direct I/O support is really working as intended, especially in the new case where logical_block_size < data_unit_size and buffers are only logical_block_size aligned --- both with real hardware and with blk-crypto-fallback. Using my patchset https://lkml.kernel.org/r/20201112194011.103774-1-ebiggers@kernel.org it should be possible to test with real eMMC inline encryption hardware on Snapdragon 630; it has logical_block_size=512. Also note, generic/587 was already added to the ext4/encrypt and ext4/encrypt_1k exclusion lists by xfstests-bld commit 02e4bfe628b4. - Eric
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. > (Credit to Eric for the description of use cases that I'm copying/summarizing here). The primary motivation for this patch series is Android - some devices use zram with cold page writeback enabled to an encrypted swap file, so direct I/O is needed to avoid double-caching the data in the swap file. In general, this patch is useful for avoiding double caching any time a loopback device is created in an encrypted directory. We also expect this to be useful for databases that want to use direct I/O but also want to encrypt data at the FS level. I do think having a good way to tell userspace about the DIO requirements would be great to have. Userspace does have ways to access to most, but not all, of the information it needs to figure out the DIO requirements (I don't think userspace has any way of figuring out if inline encryption hardware is available right now), so it would be nice if there was a good/unified API for getting those requirements. Do you think we'll need that before these patches can go in though? I do think the patches as is are useful for their primary use case even without the ability to explicitly query for the DIO requirements, because Android devices are predictable w.r.t inline encryption support (devices ship with either blk-crypto-fallback or have inline encryption hardware, and the patchset's requirements are met in either case). And even when used on machines without such predictability, this patch is at worst the same as the current situation, and at best an improvement. > - Ted