Actually, I think we have two separate issues here:
1) The need of having more detailed I/O errors even in the fs layer. This
we've already discussed at the LSF, consensus here is to allow other
errors than just 'EIO'.
Instead of Mike's approach I would rather use existing error codes here;
this will make the transition somewhat easier.
Initially I would propose to return 'ENOLINK' for a transport failure,
'EIO' for a non-retryable failure on the target, and 'ENODEV' for a
retryable failure on the target.
2) The need to differentiate the various error conditions on the multipath
layer. Multipath needs to distinguish the three error types as specified
in 1)
Mike has been trying to solve 1) and 2) by introducing separate/new error
codes, and I have been trying to use 2) by parsing the sense codes directly
from multipathing.
Given that the fs people have expressed their desire to know about these
error classes, too, it makes sense to have them exposed to the fs layer.
I see if I can come up with a patch.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
