On 2/16/16 10:44 AM, Brian Foster wrote:
> On Fri, Feb 05, 2016 at 12:23:24PM +1100, Dave Chinner wrote:
>> > From: Dave Chinner <dchinner@xxxxxxxxxx>
>> >
>> > If we take "retry forever" literally on metadata IO errors, we can
>> > hang an unmount retries those writes forever. This is the default
>> > behaviour, unfortunately. Add a error configuration option for this
>> > behaviour and default it to "fail" so that an unmount will trigger
>> > actual errors, a shutdown and allow the unmount to succeed. It will
>> > be noisy, though, as it will log the errors and shutdown that
>> > occurs.
>> >
>> > To do this, we need to mark the filesystem as being in the process
>> > of unmounting. Do this with a mount flag that is added at the
>> > appropriate time (i.e. before the blocking AIL sync). We also need
>> > to add this flag if mount fails after the initial phase of log
>> > recovery has been run.
>> >
>> > The config is done by a separate boolean sysfs option rather than a
>> > new fail_speed enum, as fail_at_unmount is relevant to both
>> > XFS_ERR_FAIL_NEVER and XFS_ERR_FAIL_SLOW options.
>> >
>> > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
>> > ---
> Similar question of scope/granularity here... why would one want to set
> this option for a particular error and not any others? In other words,
> it seems more useful as a global (or per-mount) option.
I guess my question here is higher-level than that. Why make this
(fail_at_unmount) configurable at all. When would one *want* unmount
blocked by pending failure retries?
I guess I could imagine it as sort of a safety net, "I told it to retry
for a day, and the day's not up yet, so we shouldn't stop trying
just because I said unmount!" - but that seems a bit contrived to me.
-Eric
|