[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081205030938.GA6703@one.firstfloor.org>
Date: Fri, 5 Dec 2008 04:09:38 +0100
From: Andi Kleen <andi@...stfloor.org>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: Andi Kleen <andi@...stfloor.org>, 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.)
> The only one offender is "md".
I'm not sure. It wouldn't surprise me if it can happen with other setups
too. Perhaps Chris knows more.
> It is less overhead to change "md" to play
> nice and be reliable than to double-submit requests in all the places that
> needs write ordering.
They do that already anyways.
>
> > > * the filesystems developed hacks to work around this issue, the hacks
> > > involve not submitting more requests after the barrier request,
> >
> > I suspect the reason the file systems did it this way is that
> > it was a much simpler change than to rewrite the transaction
> > manager for this.
>
> It could be initial reason. But this unreliability also disallows any
> improvement in filesystems. No one can write asynchronous transaction
> manager because of that evil EOPNOTSUPP.
Doesn't seem right. It would be a simple state machine
to handle it fully asynchronous. Alternatively you could
always use empty barriers.
But we can worry about that when some in tree file system
actually tries to do that.
-Andi
--
ak@...ux.intel.com
--
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