Hi, Michael > Thanks for the clarification. You're correct, it doesn't get called, > and it goes to read_complete. However, read_error should probably get > called. How would you suggest handling this-- should we initially set > read_dirty_data true and clear it if it is all clean? (and change the > condition to properly go into the error path). As it is, the patch > makes things no worse but the error path is very unsafe. Yes, init read_dirty_data to true is an option, but I think it is not so easy to judge whether it is all clean, because a read request may cover several keys(just as Coly mentioned in previous reply), probably some of them are dirty, others are clean, and cache_lookup_fn() was called on each of these keys when read request search them on btree, which means we should count and mark them in some place? Maybe we can set s->iop.status when metadata I/O error, and clear s->recoverable at the same time (add the code in cache_lookup(), after bch_btree_map_keys() returns), then it can goto the read_error path, and will not goto the recovery code. This option is just a idea, certainly, we should consider other exception cases. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
