>> > + default:
>> > + if (!nfs_error_is_fatal(PTR_ERR(lseg))) {
>> > + pnfs_layout_clear_fail_bit(lo, pnfs_iomode_to_fail_bit(iomode));
>> > + lseg = NULL;
>> > + }
>> Seems like in the past, a non-fatal-error used to trigger the opposite
>> behavior, where this would set the fail_bit? Shouldn't that be the
>> behavior for -NFS4ERR_LAYOUTUNAVAILABLE (which is mapped to -ENODATA)
>> etc...?
>>
>
> Yes, and I think that was a bug. See commit
> d03ab29dbbe905c6c7c5abd78e02547fa954ec07 for where that actually
> changed.
I think you mean:
0bcbf039f6b2bcefe4f5dada76079080edf9ecd0
?
...and I was looking at this one:
d600ad1f2bdbf97c4818dcc85b174f72c90c21bd
> You do have a good point about LAYOUTUNAVAILABLE though. That probably
> should stop further attempts to get a layout. That said, the error
> mapping here is fiendishly complex. I always have to wonder whether
> there other errors that get turned into ENODATA? It may be safest to
> change the error mapping there to something more specific.
If setting the fail_bit is the right way to go, that could be done
with less confusion in nfs4_layoutget_handle_exception()...?
--
Andrew W. Elble
aweits@xxxxxxxxxxxxxxxxxx
Infrastructure Engineer, Communications Technical Lead
Rochester Institute of Technology
PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
