On Tue, Aug 17, 2010 at 06:41:47PM +0200, Tejun Heo wrote: > > What other trees do you mean? > > I was mostly thinking about dm/md, drdb and stuff, but you're talking > about filesystem conversion patches being routed through block tree, > right? I think we really need all the conversions in one tree, block layer, remapping drivers and filesystems. Btw, I've done the conversion for all filesystems and I'm running tests over them now. Expect the series late today or tomorrow. > I might just resequence it to finish this part of discussion but what > does that really buy us? It's not really gonna help bisection. > Bisection won't be able to tell anything in higher resolution than > "the new implementation doesn't work". If you show me how it would > actually help, I'll happily reshuffle the patches. It's not bisecting to find bugs in the barrier conversion. We can't easily bisect it down anyway. The problem is when we try to bisect other problems and get into the middle of the series barriers suddenly are gone. Which is not very helpful for things like data integrity problems in filesystems. > >> I wasn't sure about that part. You removed store_flush_error(), but > >> DM_ENDIO_REQUEUE should still have higher priority than other > >> failures, no? > > > > Which priority? > > IIUC, when any of flushes get DM_ENDIO_REQUEUE (which tells the dm > core layer to retry the whole bio later), it trumps all other failures > and the bio is retried later. That was why DM_ENDIO_REQUEUE was > prioritized over other error codes, which actually is sort of > incorrect in that once a FLUSH fails, it _MUST_ be reported to upper > layers as FLUSH failure implies data already lost. So, > DM_ENDIO_REQUEUE actually should have lower priority than other > failures. But, then again, the error codes still need to be > prioritized. I think that's something we better leave to the DM team. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
