Re: Device loses barrier support (was: Fixed patch for simple barriers.)

[Andi Kleen <andi@firstfloor.org>]

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

Again the file systems handle failing barriers and they expect it.

> 
> So the fact that pvmove drains the request queue won't help you.

Help you against what? 

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

No there is nothing unordered. The file system path typically looks like

commit of a transaction
	if (i have never seen a barrier failing) 
		write block with barrier
		if (EOPNOTSUPP) {
			record failure
			submit synchronously
		}
	} else
		submit synchronously


So if a pvmove barrier fails it will just submit synchronously.

The write block with barrier bit varies, jbd/gfs2 do it synchronously
too and xfs does it asynchronously (with io done callbacks), but
in both cases they handle an EOPNOTSUPP comming out in the final
io done.

When the pvmove migrates from no barrier support to barrier support
there won't be any barrier on the file system for the time of the
current mount, but that's also fine.

-Andi