Hi folks,
I need to restart the discussion and review of this patch series.
There was some discussion of it last time, but nothing really came
from that. I'm posting what I have in my tree right now - treat it
as though it's an initial posting of the code because I can't recall
what I've changed since the first posting.
What I'd like to have to for the next merge window is all the IO
error bits sorted out. The final patch (kmem failure behaviour)
needs more infrastructure (passing mp to every allocation) so that's
a secondary concern right now and I've only included it to
demonstrate how to apply this code ot a different subsystem.
Things that need to be nailed down before I can commit the series:
- sysfs layout
- naming conventions for errors and subsystems in sysfs
- how best to display/change default behaviour
Things that we can change/implement later:
- default behaviour
- additional error classes
- additional error types
- additional subsystems
- subsystem error handling implementation
- communication with other subsystems to dynamically change
error behaviour
IOWs, what is important right now is how we present this to
userspace, because we can't change that easily once we've decided on
a presentation structure.
Modifying the code to classify and handle all the different error
types is much less important, as we can change that to fix whatever
problems we have without impacting the presentation to userspace.
There is definite need for this (e.g. handling of ENOSPC on thin
provisioned devices), so I want to get quickly to a consensus on the
userspace facing aspects so that we can get this ball rolling.
The biggest unsolved issue is how to change the default behaviour
persistently. There is no infrastructure in this patch series to do
that, but it is someting that we have to consider so that we don't
require default behaviour to be changed after every mount of every
filesystem on a system. My thoughts on this is we store changes to
the defaults in xattrs on the root inode, but I'm open to ideas here
as there's no code written for it yet. Solving this problem,
however, is not necessary before commiting the initial code; it's
something we can add later once we've worked out all the details.
Discuss!
-Dave.
|