public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: sandeen@sandeen.net, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 5/8] xfs_db: check that metadata updates have been committed
Date: Thu, 20 Feb 2020 08:58:40 -0800	[thread overview]
Message-ID: <20200220165840.GX9506@magnolia> (raw)
In-Reply-To: <20200220140623.GC48977@bfoster>

On Thu, Feb 20, 2020 at 09:06:23AM -0500, Brian Foster wrote:
> On Wed, Feb 19, 2020 at 05:42:13PM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > Add a new function that will ensure that everything we scribbled on has
> > landed on stable media, and report the results.
> > 
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> >  db/init.c |   14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > 
> > diff --git a/db/init.c b/db/init.c
> > index 0ac37368..e92de232 100644
> > --- a/db/init.c
> > +++ b/db/init.c
> > @@ -184,6 +184,7 @@ main(
> >  	char	*input;
> >  	char	**v;
> >  	int	start_iocur_sp;
> > +	int	d, l, r;
> >  
> >  	init(argc, argv);
> >  	start_iocur_sp = iocur_sp;
> > @@ -216,6 +217,19 @@ main(
> >  	 */
> >  	while (iocur_sp > start_iocur_sp)
> >  		pop_cur();
> > +
> > +	libxfs_flush_devices(mp, &d, &l, &r);
> > +	if (d)
> > +		fprintf(stderr, _("%s: cannot flush data device (%d).\n"),
> > +				progname, d);
> > +	if (l)
> > +		fprintf(stderr, _("%s: cannot flush log device (%d).\n"),
> > +				progname, l);
> > +	if (r)
> > +		fprintf(stderr, _("%s: cannot flush realtime device (%d).\n"),
> > +				progname, r);
> > +
> > +
> 
> Seems like we could reduce some boilerplate by passing progname into
> libxfs_flush_devices() and letting it dump out of the error messages,
> unless there's some future code that cares about individual device error
> state.

Such a program could call libxfs_flush_devices directly, as we do here.

Also, progname is defined in libxfs so we don't even need to pass it as
an argument.

I had originally thought that we should try not to add fprintf calls to
libxfs because libraries aren't really supposed to be doing things like
that, but perhaps you're right that all of this should be melded into
something else.

> That said, it also seems the semantics of libxfs_flush_devices() are a
> bit different from convention. Just below we invoke
> libxfs_device_close() for each device (rather than for all three), and
> device_close() also happens to call fsync() and platform_flush_device()
> itself...

Yeah, the division of responsibilities is a little hazy here -- I would
think that unmounting a filesystem should flush all the memory caches
and then the disk cache, but OTOH it's the utility that opens the
devices and should therefore flush and close them.

I dunno.  My current thinking is that libxfs_umount should call
libxfs_flush_devices() and print error messages as necessary, and return
error codes as appropriate.  xfs_repair can then check the umount return
value and translate that into exit(1) as required.  The device_close
functions will fsync a second time, but that shouldn't be a big deal
because we haven't dirtied anything in the meantime.

Thoughts?

--D

> Brian
> 
> >  	libxfs_umount(mp);
> >  	if (x.ddev)
> >  		libxfs_device_close(x.ddev);
> > 
> 

  reply	other threads:[~2020-02-20 16:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20  1:41 [PATCH v2 0/8] xfsprogs: actually check that writes succeeded Darrick J. Wong
2020-02-20  1:41 ` [PATCH 1/8] libxfs: libxfs_buf_delwri_submit should write buffers immediately Darrick J. Wong
2020-02-20  1:41 ` [PATCH 2/8] libxfs: complain when write IOs fail Darrick J. Wong
2020-02-20  1:42 ` [PATCH 3/8] libxfs: return flush failures Darrick J. Wong
2020-02-20  1:42 ` [PATCH 4/8] libxfs: enable tools to check that metadata updates have been committed Darrick J. Wong
2020-02-20 14:06   ` Brian Foster
2020-02-20 16:46     ` Darrick J. Wong
2020-02-20 17:58       ` Brian Foster
2020-02-20 18:26         ` Darrick J. Wong
2020-02-20 18:50           ` Brian Foster
2020-02-20 23:40   ` Dave Chinner
2020-02-21  0:33     ` Darrick J. Wong
2020-02-20  1:42 ` [PATCH 5/8] xfs_db: " Darrick J. Wong
2020-02-20 14:06   ` Brian Foster
2020-02-20 16:58     ` Darrick J. Wong [this message]
2020-02-20 17:58       ` Brian Foster
2020-02-20 18:34         ` Darrick J. Wong
2020-02-21  0:01           ` Dave Chinner
2020-02-21  0:39             ` Darrick J. Wong
2020-02-21  1:17               ` Dave Chinner
2020-02-20  1:42 ` [PATCH 6/8] mkfs: " Darrick J. Wong
2020-02-20  1:42 ` [PATCH 7/8] xfs_repair: " Darrick J. Wong
2020-02-20  1:42 ` [PATCH 8/8] libfrog: always fsync when flushing a device Darrick J. Wong
2020-02-20 14:06   ` 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=20200220165840.GX9506@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=bfoster@redhat.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /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