ping? On Fri, Feb 05, 2016 at 12:23:18PM +1100, Dave Chinner wrote: > 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. > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs > -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
