From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Subject: [RFC v2 0/2] xfs: detect and warn about invalid metadata lsns
Date: Fri, 11 Sep 2015 14:53:53 -0400 [thread overview]
Message-ID: <1441997635-36644-1-git-send-email-bfoster@redhat.com> (raw)
Hi all,
Here's a second rfc pass at the kernel side of invalid metadata LSN
detection for v5 supers. This is an rfc simply because my understanding
is that the userspace code should probably go first so that the tools
for repair are available before the kernel starts detecting and warning
about this problem.
The primary change in this version is how the problem is handled once
detected. I've been a bit undecided on whether a shutdown is really
warranted because if the fs doesn't crash, it will eventually
self-correct. On the flipside, a WARN_ON_ONCE() is not sufficient
because it could suppress warnings on separate filesystems once one
filesystem has encountered the issue and fired a warning.
Therefore, this version uses something of a happy medium. The filesystem
is not shutdown but a mount flag is used to warn about the problem at
least once per-mount. Any instances thereafter are ratelimited to a once
per 24 hour period.
Brian
rfcv2:
- Refactored lsn validation and warning code into separate helpers.
- Updated warning mechanism to warn at least once per fs (ratelimited
thereafter).
- No longer shutdown the fs on invalid metadata lsn detection.
rfcv1: http://oss.sgi.com/pipermail/xfs/2015-August/043396.html
Brian Foster (2):
xfs: create a daily warning mechanism
xfs: validate metadata LSNs against log on v5 superblocks
fs/xfs/libxfs/xfs_alloc.c | 9 +++++--
fs/xfs/libxfs/xfs_attr_leaf.c | 2 ++
fs/xfs/libxfs/xfs_btree.c | 14 +++++++++--
fs/xfs/libxfs/xfs_da_btree.c | 3 +++
fs/xfs/libxfs/xfs_dir2_block.c | 1 +
fs/xfs/libxfs/xfs_dir2_data.c | 1 +
fs/xfs/libxfs/xfs_dir2_leaf.c | 1 +
fs/xfs/libxfs/xfs_dir2_node.c | 1 +
fs/xfs/libxfs/xfs_ialloc.c | 8 +++++--
fs/xfs/libxfs/xfs_sb.c | 8 +++++++
fs/xfs/libxfs/xfs_symlink_remote.c | 3 +++
fs/xfs/xfs_log.c | 1 -
fs/xfs/xfs_log_priv.h | 24 +++++++++++++++++++
fs/xfs/xfs_log_recover.c | 15 +++++++++++-
fs/xfs/xfs_message.h | 18 ++++++++++----
fs/xfs/xfs_mount.c | 49 ++++++++++++++++++++++++++++++++++++++
fs/xfs/xfs_mount.h | 3 +++
17 files changed, 149 insertions(+), 12 deletions(-)
--
2.1.0
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2015-09-11 18:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-11 18:53 Brian Foster [this message]
2015-09-11 18:53 ` [RFC v2 1/2] xfs: create a daily warning mechanism Brian Foster
2015-09-11 18:53 ` [RFC v2 2/2] xfs: validate metadata LSNs against log on v5 superblocks Brian Foster
2015-09-22 8:07 ` Dave Chinner
2015-09-22 14:21 ` 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=1441997635-36644-1-git-send-email-bfoster@redhat.com \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox