[PATCH V4] xfs: Document error handlers behavior

Carlos Maiolino cmaiolino at redhat.com
Thu Sep 15 04:18:51 CDT 2016


> > 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 at fromorbit.com
> 
> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

-- 
Carlos



More information about the xfs mailing list