Re: [PATCH 14/17] xfs: use bios directly to read and write the log recovery buffers

[Christoph Hellwig <hch@lst.de>]

On Wed, May 22, 2019 at 08:24:34AM +1000, Dave Chinner wrote:
> Yeah, the log recovery code should probably be split in three - the
> kernel specific IO code/API, the log parsing code (the bit that
> finds head/tail and parses it into transactions for recovery) and
> then the bit that actually does the recovery. THe logprint code in
> userspace uses the parsing code, so that's the bit we need to share
> with userspace...

Actually one thing I have on my TODO list is to move the log item type
specific recovery code first into an ops vector, and then out to the
xfs_*_item.c together with the code creating those items.  That isn't
really all of the recovery code, but it seems like a useful split.

Note that the I/O code isn't really very log specific, it basically
just is trivial I/O to a vmalloc buffer code.  In fact I wonder if
I could just generalize it a little more and move it to the block layer.

> I've got a rough AIO implementation backing the xfs_buf.c code in
> userspace already. It works just fine and is massively faster than
> the existing code on SSDs, so I don't see a problem with porting IO
> code that assumes an AIO model anymore. i.e. Re-using the kernel AIO
> model for all the buffer code in userspace is one of the reasons I'm
> porting xfs-buf.c to userspace.

Given that we:

 a) do direct I/O everywhere
 b) tend to do it on either a block device, or a file where we don't
    need to allocate over holes

aio should be a win everywhere.  The only caveat is that CONFG_AIO
is kernel option and could be turned off in some low end configs.