From: Pingfan Liu <kernelfans@gmail.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org, "Darrick J. Wong" <darrick.wong@oracle.com>
Subject: Re: [PATCH] xfs/log: protect the logging content under xc_ctx_lock
Date: Fri, 1 Nov 2019 12:02:34 +0800 [thread overview]
Message-ID: <20191101040234.GA7598@mypc> (raw)
In-Reply-To: <20191031113640.GA54006@bfoster>
On Thu, Oct 31, 2019 at 07:36:40AM -0400, Brian Foster wrote:
> Dropped linux-fsdevel from cc. There's no reason to spam -fsdevel with
> low level XFS patches.
>
> On Wed, Oct 30, 2019 at 09:37:11PM +0800, Pingfan Liu wrote:
[...]
>
> I'm not following how this is possible. The CIL push above, under
It turns out not to be a bug as I replied to Dave's mail in this thread.
> exclusive lock, removes each log item from ->xc_cil and pulls the log
> vectors off of the log items to form the lv chain on the CIL context.
> This means that the transB commit either updates the lv attached to the
> log item from transA with the latest in-core version or uses the new
> shadow buffer allocated in the commit path of transB. Either way is fine
> because there is no guarantee of per-transaction granularity in the
Yes, no guarantee of per-transaction granularity, but there is a
boundary placed on several effect-merged transactions. That is what
xc_ctx_lock and private chain ctx->lv_chain guarantee.
> on-disk log. The purpose of the on-disk log is to guarantee filesystem
> consistency after a crash.
>
> All in all, I can't really tell what problem you're describing here. If
> you believe there's an issue in this code, I'd suggest to either try and
> instrument it manually to reproduce a demonstrable problem and/or
> provide far more detailed of a description to explain it.
>
Sorry that I raise a false alarm. But thank you all for helping me to figure
out through this.
Regards,
Pingfan
next prev parent reply other threads:[~2019-11-01 4:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-30 6:29 [PATCH] xfs/log: protect xc_cil in xlog_cil_push() Pingfan Liu
2019-10-30 12:53 ` Brian Foster
2019-10-30 13:33 ` Pingfan Liu
2019-10-30 13:37 ` [PATCH] xfs/log: protect the logging content under xc_ctx_lock Pingfan Liu
2019-10-30 16:48 ` Darrick J. Wong
2019-10-31 3:48 ` Pingfan Liu
2019-10-31 11:36 ` Brian Foster
2019-11-01 4:02 ` Pingfan Liu [this message]
2019-10-31 21:40 ` Dave Chinner
2019-11-01 3:39 ` Pingfan Liu
2019-10-31 21:25 ` [PATCH] xfs/log: protect xc_cil in xlog_cil_push() Dave Chinner
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=20191101040234.GA7598@mypc \
--to=kernelfans@gmail.com \
--cc=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.