From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 14/17] xfs: use bios directly to read and write the log recovery buffers
Date: Wed, 22 May 2019 08:24:34 +1000 [thread overview]
Message-ID: <20190521222434.GH29573@dread.disaster.area> (raw)
In-Reply-To: <20190521050943.GA29120@lst.de>
On Tue, May 21, 2019 at 07:09:43AM +0200, Christoph Hellwig wrote:
> On Tue, May 21, 2019 at 09:32:33AM +1000, Dave Chinner wrote:
> > So while it's easy to drop the uncached buffer API from the kernel
> > side, it leaves me with the question of what API do we use in
> > userspace to provide this same functionality? I suspect that we
> > probably need to separate all this log-to-bio code out into a
> > separate file (e.g. xfs_log_io.[ch]) to leave a set of API stubs
> > that we can reimplement in userspace to pread/pwrite directly to
> > the log buftarg device fd as I've done already for the buffer
> > code...
>
> For one we still keep the uncached buffers in xfs_buf.c as we have users
> of that outside of the log code, but I guess that is not what you mean.
>
> I can split the log recovery code into a separate file, as you said
> it should just be malloc + pread/pwrite in userspace, so implementing
> it should be trivial.
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...
> The xlog_sync case is pretty different in the
> kernel as it isn't synchonous, and it also doesn't currently exist in
> userspace. I'd rather keep that as-is unless you have plans to port
> the logging code to userspace?
That's fine, I have no plans to pull the full logging code into
userspace right now.
> Even in that case we'll probably want
> a different abstraction that maps to aio.
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.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2019-05-21 22:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 16:13 use bios directly in the log code Christoph Hellwig
2019-05-20 16:13 ` [PATCH 01/17] xfs: remove the no-op spinlock_destroy stub Christoph Hellwig
2019-05-20 16:13 ` [PATCH 02/17] xfs: remove the never used _XBF_COMPOUND flag Christoph Hellwig
2019-05-20 16:13 ` [PATCH 03/17] xfs: renumber XBF_WRITE_FAIL Christoph Hellwig
2019-05-20 16:13 ` [PATCH 04/17] xfs: reformat xlog_get_lowest_lsn Christoph Hellwig
2019-05-20 16:13 ` [PATCH 05/17] xfs: don't use REQ_PREFLUSH for split log writes Christoph Hellwig
2019-05-20 16:13 ` [PATCH 06/17] xfs: factor out log buffer writing Christoph Hellwig
2019-05-20 16:13 ` [PATCH 07/17] xfs: factor out splitting of an iclog from xlog_sync Christoph Hellwig
2019-05-20 16:13 ` [PATCH 08/17] xfs: split iclog size calculation out of xlog_sync Christoph Hellwig
2019-05-20 16:13 ` [PATCH 09/17] xfs: update both state counters together in xlog_sync Christoph Hellwig
2019-05-20 16:13 ` [PATCH 10/17] xfs: remove the syncing argument from xlog_verify_iclog Christoph Hellwig
2019-05-20 16:13 ` [PATCH 11/17] xfs: make use of the l_targ field in struct xlog Christoph Hellwig
2019-05-20 16:13 ` [PATCH 12/17] xfs: use bios directly to write log buffers Christoph Hellwig
2019-05-20 16:13 ` [PATCH 13/17] xfs: return an offset instead of a pointer from xlog_align Christoph Hellwig
2019-05-20 16:13 ` [PATCH 14/17] xfs: use bios directly to read and write the log recovery buffers Christoph Hellwig
2019-05-20 23:32 ` Dave Chinner
2019-05-21 5:09 ` Christoph Hellwig
2019-05-21 22:24 ` Dave Chinner [this message]
2019-05-22 5:12 ` Christoph Hellwig
2019-05-22 6:19 ` Dave Chinner
2019-05-22 17:31 ` Christoph Hellwig
2019-05-22 23:28 ` Dave Chinner
2019-05-23 6:22 ` Christoph Hellwig
2019-05-20 16:13 ` [PATCH 15/17] xfs: remove unused buffer cache APIs Christoph Hellwig
2019-05-20 16:13 ` [PATCH 16/17] xfs: properly type the b_log_item field in struct xfs_buf Christoph Hellwig
2019-05-20 16:13 ` [PATCH 17/17] xfs: remove the b_io_length " Christoph Hellwig
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=20190521222434.GH29573@dread.disaster.area \
--to=david@fromorbit.com \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
/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