linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH 0/4] xfs: miscellaneous log recovery fixes
Date: Mon, 23 Oct 2017 10:46:42 -0400	[thread overview]
Message-ID: <20171023144646.50107-1-bfoster@redhat.com> (raw)

Hi all,

These are several minor fixes that fell out of both Zorro's[1] and
Darrick's[2] recent reports. Patches 1 and 2 address the log cycle
underflow problem on filesystems with logs that are sized too small by
mfks. Patch 3 drains the lru after log recovery to prevent buffers from
lingering with NULL verifier ops after log recovery completes (on v4
fs'). Patch 4 adds a mount time check to enforce that the total log
buffer size does not exceed 1/2 the physical log size, as suggested by
Dave[3].

Note that patch 4 is RFC for a couple reasons. First, I don't quite grok
where the 1/2 log size restriction comes from, so I'd like to be able to
at least include a more descriptive commit log on that. Second, this
patch causes a couple xfstests failures (xfs/030, xfs/057) when testing
with larger log buf sizes on filesystems that otherwise have
sufficiently sized logs (i.e., logbufs=8,logbsize=256k w/ a 3MB log), so
I'm not totally convinced this restriction is necessary (or 50% is the
right restriction) without some further feedback on that. For example,
should we always enforce this restriction as the current patch does, or
only when the log happens to be under the (expected) minimum size?

Thoughts, reviews, flames appreciated.

Brian

[1] https://marc.info/?l=linux-xfs&m=150674214217044&w=2
[2] https://marc.info/?l=linux-xfs&m=150792056128414&w=2
[3] https://marc.info/?l=linux-xfs&m=150819276824933&w=2

Brian Foster (4):
  xfs: sanity check log record range parameters
  xfs: fix log block underflow during recovery cycle verification
  xfs: drain the buffer LRU on mount
  xfs: enforce a maximum total iclog buffer size

 fs/xfs/xfs_log.c         | 21 +++++++++++++++++++++
 fs/xfs/xfs_log_recover.c | 13 ++++++++++---
 2 files changed, 31 insertions(+), 3 deletions(-)

-- 
2.9.5


             reply	other threads:[~2017-10-23 14:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-23 14:46 Brian Foster [this message]
2017-10-23 14:46 ` [PATCH 1/4] xfs: sanity check log record range parameters Brian Foster
2017-10-23 23:49   ` Darrick J. Wong
2017-10-24 11:30     ` Brian Foster
2017-10-25  5:09       ` Darrick J. Wong
2017-10-23 14:46 ` [PATCH 2/4] xfs: fix log block underflow during recovery cycle verification Brian Foster
2017-10-23 23:50   ` Darrick J. Wong
2017-10-23 14:46 ` [PATCH 3/4] xfs: drain the buffer LRU on mount Brian Foster
2017-10-23 16:39   ` Darrick J. Wong
2017-10-23 16:54     ` Brian Foster
2017-10-24  0:23       ` Darrick J. Wong
2017-10-24 14:06         ` Brian Foster
2017-10-24 19:47           ` Brian Foster
2017-10-23 14:46 ` [PATCH RFC 4/4] xfs: enforce a maximum total iclog buffer size 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=20171023144646.50107-1-bfoster@redhat.com \
    --to=bfoster@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).