All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: Re: [PATCH 0/9] xfs: configurable error behaviour
Date: Sat, 13 Feb 2016 13:52:43 +1100	[thread overview]
Message-ID: <20160213025243.GE14668@dastard> (raw)
In-Reply-To: <1454635407-22276-1-git-send-email-david@fromorbit.com>

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@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2016-02-13  2:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05  1:23 [PATCH 0/9] xfs: configurable error behaviour Dave Chinner
2016-02-05  1:23 ` [PATCH 1/9] xfs: configurable error behaviour via sysfs Dave Chinner
2016-02-05  1:23 ` [PATCH 2/9] xfs: introduce metadata IO error class Dave Chinner
2016-02-05  1:23 ` [PATCH 3/9] xfs: add configurable error support to metadata buffers Dave Chinner
2016-02-05  1:23 ` [PATCH 4/9] xfs: introduce table-based init for error behaviours Dave Chinner
2016-02-05  1:23 ` [PATCH 5/9] xfs: add configuration of error failure speed Dave Chinner
2016-02-16 16:44   ` Brian Foster
2016-02-05  1:23 ` [PATCH 6/9] xfs: add "fail at unmount" error handling configuration Dave Chinner
2016-02-16 16:44   ` Brian Foster
2016-02-16 17:09     ` Eric Sandeen
2016-02-05  1:23 ` [PATCH 7/9] xfs: add configuration handles for specific errors Dave Chinner
2016-02-05  1:23 ` [PATCH 8/9] xfs: disable specific error configurations Dave Chinner
2016-02-16 16:45   ` Brian Foster
2016-02-05  1:23 ` [PATCH 9/9] xfs: add kmem error configuration class Dave Chinner
2016-02-13  2:52 ` Dave Chinner [this message]
2016-03-15 10:16 ` [PATCH 0/9] xfs: configurable error behaviour Carlos Maiolino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160213025243.GE14668@dastard \
    --to=david@fromorbit.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.