Chris Mason wrote: > On Thu, Aug 05, 2010 at 05:11:56PM +0400, Vladislav Bolkhovitin wrote: >> Chris Mason, on 08/02/2010 09:39 PM wrote: >>> I regret putting the ordering into the original barrier code...it >>> definitely did help reiserfs back in the day but it stinks of magic and >>> voodoo. >> But if the ordering isn't in the common (block) code, how to >> implement the "hardware offload" for ordering, i.e. ORDERED >> commands, in an acceptable way? >> >> I believe, the decision was right, but the flags and magic requests >> based interface (and, hence, implementation) was wrong. That's it >> which stinks of magic and voodoo. > > The interface definitely has flaws. We didn't expand it because James > popped up with a long list of error handling problems. Basically how > do the hardware and the kernel deal with a failed request at the start > of the chain. Somehow the easy way of failing them all turned out to be > extremely difficult. > > Even if that part had been refined, I think trusting the ordering down > to the lower layers was a doomed idea. The list of ways it could go > wrong is much much longer (and harder to debug) than the list of > benefits. > > With all of that said, I did go ahead and benchmark real ordered tags > extensively on a scsi drive in the initial implementation. There was > very little performance difference. > Care to dig it up? I'd wanted to give it a try, and if someone already did some work in that area it'll make things easier here. I still think that implementing ordered tags is the correct way of doing things, implementation details notwithstanding. It looks better conceptually than using FUA, and would be easier from the request-queue side of things. (Or course, as the entire logic is pushed down to the SCSI layer :-) Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
