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.
