From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v2 02/12] libxfs: track largest metadata LSN in use via verifiers
Date: Wed, 23 Sep 2015 13:44:06 +1000 [thread overview]
Message-ID: <20150923034406.GR3902@dastard> (raw)
In-Reply-To: <1441997742-37160-3-git-send-email-bfoster@redhat.com>
On Fri, Sep 11, 2015 at 02:55:32PM -0400, Brian Foster wrote:
> The LSN validation helper is called in the I/O verifier codepath for
> metadata that embed a last-modification LSN. While the codepath exists,
> this is not used in userspace as in the kernel because the former
> doesn't have an active log.
>
> xfs_repair does need to check the validity of the LSN metadata with
> respect to the on-disk log, however. Use the LSN validation mechanism to
> track the largest LSN that has been seen. Export the value so repair can
> use it once it has processed the entire filesystem. Note that the helper
> continues to always return true to preserve existing behavior.
>
> Signed-off-by: Brian Foster <bfoster@redhat.com>
....
> +xfs_lsn_t libxfs_max_lsn = 0;
> +pthread_mutex_t libxfs_max_lsn_lock = PTHREAD_MUTEX_INITIALIZER;
> +
> void
> xfs_detect_invalid_lsn(
> struct xfs_mount *mp,
> xfs_lsn_t lsn)
> {
> + int cycle = CYCLE_LSN(lsn);
> + int block = BLOCK_LSN(lsn);
> + int max_cycle;
> + int max_block;
> +
> + if (lsn == NULLCOMMITLSN)
> + return;
> +
> + pthread_mutex_lock(&libxfs_max_lsn_lock);
> +
> + max_cycle = CYCLE_LSN(libxfs_max_lsn);
> + max_block = BLOCK_LSN(libxfs_max_lsn);
> +
> + if ((cycle > max_cycle) ||
> + (cycle == max_cycle && block > max_block))
> + libxfs_max_lsn = lsn;
> +
> + pthread_mutex_unlock(&libxfs_max_lsn_lock);
This will have the same lock contention problems that the kernel
code would have had - my repair scalablity tests regularly reach
over 1GB/s of metadata being prefetched through tens of threads, so
this is going have a significant impact on performance in those
tests....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-09-23 3:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-11 18:55 [PATCH v2 00/12] xfsprogs: format the log correctly on v5 supers Brian Foster
2015-09-11 18:55 ` [PATCH v2 01/12] libxfs: validate metadata LSNs against log on v5 superblocks Brian Foster
2015-09-11 18:55 ` [PATCH v2 02/12] libxfs: track largest metadata LSN in use via verifiers Brian Foster
2015-09-23 3:44 ` Dave Chinner [this message]
2015-09-23 13:18 ` Brian Foster
2015-09-23 22:36 ` Dave Chinner
2015-10-01 20:38 ` Brian Foster
2015-10-02 2:16 ` Dave Chinner
2015-10-02 11:33 ` Brian Foster
2015-09-11 18:55 ` [PATCH v2 03/12] libxfs: don't hardcode cycle 1 into unmount op header Brian Foster
2015-09-23 3:48 ` Dave Chinner
2015-09-23 13:22 ` Brian Foster
2015-09-24 0:37 ` Dave Chinner
2015-09-24 13:00 ` Brian Foster
2015-09-11 18:55 ` [PATCH v2 04/12] libxfs: pass lsn param to log clear and record header logging helpers Brian Foster
2015-09-11 18:55 ` [PATCH v2 05/12] libxfs: add ability to clear log to arbitrary log cycle Brian Foster
2015-09-11 18:55 ` [PATCH v2 06/12] libxlog: pull struct xlog out of xlog_is_dirty() Brian Foster
2015-09-11 18:55 ` [PATCH v2 07/12] xfs_repair: track log state throughout all recovery phases Brian Foster
2015-09-11 18:55 ` [PATCH v2 08/12] xfs_repair: process the log in no_modify mode Brian Foster
2015-09-11 18:55 ` [PATCH v2 09/12] xfs_repair: format the log with forward cycle number on v5 supers Brian Foster
2015-09-11 18:55 ` [PATCH v2 10/12] xfs_repair: don't clear the log by default Brian Foster
2015-09-11 18:55 ` [PATCH v2 11/12] xfs_db: do not reset current lsn from uuid command on v5 supers Brian Foster
2015-09-11 18:55 ` [PATCH v2 12/12] db/metadump: bump lsn when log is cleared " Brian Foster
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=20150923034406.GR3902@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=xfs@oss.sgi.com \
/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.