All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.