Hello, On 08/24/2010 12:24 PM, Kiyoshi Ueda wrote: > Yes, checking whether it's a transport error in lower layer is > the right solution. > (Since I know it's not available yet, I just hoped if upper layers > had some other options.) > > Anyway, only reporting errors for REQ_FLUSH to upper layer without > such a solution would make dm-multipath almost unusable in real world, > although it's better than implicit data loss. I see. >>> Maybe just turn off barrier support in mpath for now? > > If it's possible, it could be a workaround for a short term. > But how can you do that? > > I think it's not enough to just drop REQ_FLUSH flag from q->flush_flags. > Underlying devices of a mpath device may have write-back cache and > it may be enabled. > So if a mpath device doesn't set REQ_FLUSH flag in q->flush_flags, it > becomes a device which has write-back cache but doesn't support flush. > Then, upper layer can do nothing to ensure cache flush? Yeah, I was basically suggesting to forget about cache flush w/ mpath until it can be fixed. You're saying that if mpath just passes REQ_FLUSH upwards without retrying, it will be almost unuseable, right? I'm not sure how to proceed here. How much work would discerning between transport and IO errors take? If it can't be done quickly enough the retry logic can be kept around to keep the old behavior but that already was a broken behavior, so... :-( Thanks. -- tejun -- 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
