> Well, the switch is simple characterisation. What we do with that
> error type can be much more complex, and that's why I haven't tried
> to address those issues here. When we've sorted out what we need
> and how we are going to configure the error handling, then we can
> add it.
> e.g. if we need configurable error handling, it needs to be
> configurable for different error types, and it needs to be
> configurable on a per-mount basis. And it needs to be configurable
> at runtime, not just at mount time. That kind of leads to using
> sysfs for this. e.g. for each error type we ned to handle different
> behaviour for:
> $ cat /sys/fs/xfs/vda/meta_write_errors/enospc/type
> [transient] permanent
> $ cat /sys/fs/xfs/vda/meta_write_errors/enospc/perm_timeout_seconds
> $ cat /sys/fs/xfs/vda/meta_write_errors/enospc/perm_max_retry_attempts
> $ cat /sys/fs/xfs/vda/meta_write_errors/enospc/transient_fail_at_umount
> And then have generic infrastructure to set it up and handle the
> buffer errors according to the config?
> > (I think that's accurately summing up irc-and-side-channel discussions) ;)
> Pretty much.
talking about possible configurable error handlers, what about leave this choice
of failure to the sysadmin? Instead a time or type based configuration what
about something that the administrator could just say "next IO to device X
should fail permanently"?
Anyway, I know it would not be automatic, but it adds some flexibility to the
Anyway, just my 2 cents.