From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: hal@deer-run.com
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs_db: add -R option
Date: Mon, 7 May 2018 18:21:36 -0700 [thread overview]
Message-ID: <20180508012136.GI11261@magnolia> (raw)
In-Reply-To: <20180507125621.GA2969@deer-run.com>
On Mon, May 07, 2018 at 07:56:21AM -0500, hal@deer-run.com wrote:
> Darrick's suggested patch to sb_logcheck() is the way to accomplish
> what I want with the minimum amount of code changes. But as I look at
> the code, I'm not sure doing it the way Darrick suggests actually
> expresses what we're trying to accomplish.
>
> Let's state the problem as "Recognize that the log is dirty but allow
> blockget to proceed if '-r' is used". If you accept that problem
> statement, then sb_logcheck() should just tell the caller whether the
> log is dirty or not. It's up to the caller to decide what to do with
> that information-- in this case the init() function in db/check.c.
>
> However, right now sb_logcheck() returns 0 for the case where
> there's a fatal error (like not being able to find the log) and for
> the log being dirty. init() would need to distinguish between those
> two cases and act appropriately. That means changing the return
> semantics of sb_logcheck() to something like -1 on error, 0 on dirty,
> and 1 on clean.
>
> Note that sb_logcheck() is also called by sb_logzero() and
> that code would have to be tweaked to handle the new return values.
Ultimately I defer to Eric on this one, but I don't see how sb_logzero
would run to completion in readonly mode, since the only caller of it is
uuid_f, which bails out if we're in readonly mode.
(Not to mention the buffer writes should fail in ro mode).
--D
>
> So the end result is more code changes to do it this way, but I
> feel like it's a more "correct" fix. I have patches created for
> both scenarios-- does anybody have a strong opinion about which way
> to proceed?
>
> --Hal
>
>
> On Mon May 07 06:35, hal@deer-run.com wrote:
> > > Why skip the warning? I think xfs_db should always warn on a dirty log,
> > > but perhaps we could relax the 'return 0' at the end of this hunk if the
> > > fs was opened readonly?
> > >
> > > i.e.
> > >
> > > dbprintf(_("ERROR: The filesystem has..."));
> > > return (x.isreadonly & LIBXFS_ISREADONLY) ? 1 : 0;
> > >
> > > which would also make adding the -R option unnecessary.
> >
> > I like this solution very much. I'll send in this patch in a
> > separate email.
> >
> > Hal Pomeranz
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-05-08 1:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-04 14:02 [PATCH] xfs_db: add -R option hal
2018-05-04 15:32 ` Darrick J. Wong
2018-05-07 11:35 ` hal
2018-05-07 12:56 ` hal
2018-05-08 1:21 ` Darrick J. Wong [this message]
2018-05-08 13:55 ` Eric Sandeen
2018-05-08 16:13 ` hal
2018-05-08 16:27 ` Eric Sandeen
2018-05-08 16:43 ` hal
2018-05-08 16:58 ` Darrick J. Wong
2018-05-09 0:14 ` 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=20180508012136.GI11261@magnolia \
--to=darrick.wong@oracle.com \
--cc=hal@deer-run.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