> > Also, I apologize if I misunderstand it, but being ignored doesn't look a proper > > description here, it sounds to me something like 'we ignore the error and tell > > nobody about it", in unmount example, we shut down the filesystem if any error > > happens, for me it doesn't sound like ignoring an error, but I might be > > interpreting it in the wrong way. > > I think you're making the assumption that the only way we handle > errors once retries are exhausted is to trigger a filesystem shutdown. > That assumption was repeated throughout the documentation. > > While that may be true for /metadata write IO errors/, it is not > true for the generic error handling case. e.g. if we extend it to > memory allocation contexts, we may end up returning ENOMEM to > userspace. Or, in certain contexts, we might be able to fall back to > doing a single operation at a time using the stack for storage, in > which case there is no reason at all to report the allocation > failure to anyone. > > The infrastructure is generic, as is the documentation, and so it > shouldn't assume anything about what is going to happen once the > retries are exhausted and the error is propagated upwards. What > happens with that error after it is returned is a subsystem and > context dependent behaviour, not something that is defined by the > error retry configuration infrastructure.... > > Cheers, Thanks for the very detailed explanation Dave > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs -- Carlos _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
