[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0812040913510.6118@hs20-bc2-1.build.redhat.com>
Date: Thu, 4 Dec 2008 09:17:04 -0500 (EST)
From: Mikulas Patocka <mpatocka@...hat.com>
To: Andi Kleen <andi@...stfloor.org>
cc: linux-kernel@...r.kernel.org, xfs@....sgi.com,
Alasdair G Kergon <agk@...hat.com>,
Andi Kleen <andi-suse@...stfloor.org>,
Milan Broz <mbroz@...hat.com>
Subject: Re: Device loses barrier support (was: Fixed patch for simple
barriers.)
On Thu, 4 Dec 2008, Andi Kleen wrote:
> > the 1st write request ends with success
> > the 2nd write request ends with -EOPNOTSUPP
> > the 3rd write request ends with success
> >
> > --- when you first see -EOPNOTSUPP, you have already corrupted filesystem
> > (the 3rd write passed while the filesystem expected that it would be
>
> There's no passing of requests during pvmove. It's a really strong
> barrier.
You start pvmove. The filesystem doesn't know about pvmove.
The next time filesystem does somethig, it submits these 3 requests and
the 2nd fill unexpectedly fail.
So the fact that pvmove drains the request queue won't help you.
> > finished after the 2nd write) and you are in an interrupt context, where
> > you can't reissue -EOPNOTSUPP request. So what do you want to do?
>
> The barrier aware file systems I know of just resubmit synchronously when
> a barrier fails.
... and produce structure corruption for certain period in time, because
the writes meant to be ordered are submitted unordered.
Mikulas
> -Andi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists