Hi Lee,
On Thu, Jul 22, 2021 at 12:23:47PM +0100, Lee Jones wrote:
>
> No review after 7 weeks on the list.
>
> Is there anything Satya can do to help expedite this please?
>
This series is basically ready, but I can't apply it because it depends on the
other patch series
"[PATCH v4 0/9] ensure bios aren't split in middle of crypto data unit"
(https://lkml.kernel.org/linux-block/[email protected]/T/#u).
I will be re-reviewing that other patch series soon, but it primary needs review
by the people who work more regularly with the block layer, and it will have to
go in through the block tree (I can't apply it to the fscrypt tree).
The original version of this series didn't require so many block layer changes,
but it would have only allowed direct I/O with user buffer pointers aligned to
the filesystem block size, which was too controversial with other filesystem
developers; see the long discussion at
https://lkml.kernel.org/linux-fscrypt/[email protected]/T/#u.
In addition, it was requested that we not add features to the "legacy" direct
I/O implementation (fs/direct-io.c), so I have a patch series in progress
"[PATCH 0/9] f2fs: use iomap for direct I/O"
(https://lkml.kernel.org/linux-f2fs-devel/[email protected]/T/#u)
which will change f2fs to use iomap.
Also please understand that Satya has left Google, so any further work from him
on this is happening on a personal capacity in his free time.
- Eric
On Thu, 22 Jul 2021, Eric Biggers wrote:
> Hi Lee,
>
> On Thu, Jul 22, 2021 at 12:23:47PM +0100, Lee Jones wrote:
> >
> > No review after 7 weeks on the list.
> >
> > Is there anything Satya can do to help expedite this please?
> >
>
> This series is basically ready, but I can't apply it because it depends on the
> other patch series
> "[PATCH v4 0/9] ensure bios aren't split in middle of crypto data unit"
> (https://lkml.kernel.org/linux-block/[email protected]/T/#u).
> I will be re-reviewing that other patch series soon, but it primary needs review
> by the people who work more regularly with the block layer, and it will have to
> go in through the block tree (I can't apply it to the fscrypt tree).
>
> The original version of this series didn't require so many block layer changes,
> but it would have only allowed direct I/O with user buffer pointers aligned to
> the filesystem block size, which was too controversial with other filesystem
> developers; see the long discussion at
> https://lkml.kernel.org/linux-fscrypt/[email protected]/T/#u.
>
> In addition, it was requested that we not add features to the "legacy" direct
> I/O implementation (fs/direct-io.c), so I have a patch series in progress
> "[PATCH 0/9] f2fs: use iomap for direct I/O"
> (https://lkml.kernel.org/linux-f2fs-devel/[email protected]/T/#u)
> which will change f2fs to use iomap.
>
> Also please understand that Satya has left Google, so any further work from him
> on this is happening on a personal capacity in his free time.
Thanks for the update Eric. I'll push this to the back of my queue
and check back with you at a later date. Hopefully we see some
interest from the other maintainers sooner, rather than later.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog