public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Matteo Frigo <athena@fftw.org>
To: Dave Chinner <david@fromorbit.com>
Cc: dm-devel@redhat.com, xfs@oss.sgi.com
Subject: Re: [dm-devel] [BUG] pvmove corrupting XFS filesystems (was Re: [BUG] Internal error xfs_dir2_data_reada_verify)
Date: Thu, 07 Mar 2013 07:13:27 -0500	[thread overview]
Message-ID: <87k3pjs908.fsf@fftw.org> (raw)
In-Reply-To: <87y5eah4xz.fsf@fftw.org> (Matteo Frigo's message of "Tue, 26 Feb 2013 21:21:44 -0500")

Matteo Frigo <athena@fftw.org> writes:

> Well, I don't really know anything about this topic, so I may be
> completely off the mark, but dm-raid1.c:mirror_map() does indeed return
> EWOULDBLOCK, and EWOULDBLOCK is #define'd to be EAGAIN, so it seems to
> me that dm-raid1 does indeed return EAGAIN for "rw == READA" (which I
> assume is read-ahead) if the "region is not in-sync":
>
> 	/*
> 	 * If region is not in-sync queue the bio.
> 	 */
> 	if (!r || (r == -EWOULDBLOCK)) {
> 		if (rw == READA)
> 			return -EWOULDBLOCK;
>
> 		queue_bio(ms, bio, rw);
> 		return DM_MAPIO_SUBMITTED;
> 	}

Dave (and others),

do you have any suggestion on what should be done to fix this bug?

I have tried returning -EIO instead of -EWOULDBLOCK, but xfs does not
like that.  dm-zero.c:zero_map() appears to return -EIO too, so this is
another potential issue.

I have verified that removing the READA special case, treating READA
like READ, fixes the problem:

 		if(0) if (rw == READA)
 			return -EWOULDBLOCK;

Of course this "fix" throws away the baby with the bath water.

I am willing to write and submit a patch, but I would appreciate
directions as to what the correct protocol between xfs and dm is
supposed to be.

Regards,
MF

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2013-03-07 12:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-26  0:47 [BUG] Internal error xfs_dir2_data_reada_verify Matteo Frigo
2013-02-26  4:40 ` [BUG] pvmove corrupting XFS filesystems (was Re: [BUG] Internal error xfs_dir2_data_reada_verify) Dave Chinner
2013-02-26 11:29   ` Matteo Frigo
2013-02-27  1:04   ` [dm-devel] " Alasdair G Kergon
2013-02-27  1:49     ` Dave Chinner
2013-02-27  2:21       ` Matteo Frigo
2013-02-27  2:29         ` Dave Chinner
2013-03-07 12:13         ` Matteo Frigo [this message]
2013-03-07 22:31           ` Dave Chinner
2013-03-07 22:50             ` Dave Chinner
2013-03-08  0:09             ` Matteo Frigo
2013-03-08  1:57               ` Dave Chinner
2013-03-08 11:38                 ` Matteo Frigo
2013-02-27 15:07       ` Mike Snitzer
2013-02-27 15:10         ` Matteo Frigo
2013-02-27 23:07         ` 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=87k3pjs908.fsf@fftw.org \
    --to=athena@fftw.org \
    --cc=david@fromorbit.com \
    --cc=dm-devel@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