All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Fasheh <mfasheh@suse.de>
To: Gang He <ghe@suse.com>
Cc: Junxiao Bi <junxiao.bi@oracle.com>,
	akpm@linux-foundation.org, ocfs2-devel@oss.oracle.com,
	rgoldwyn@suse.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check
Date: Fri, 18 Dec 2015 14:37:01 -0800	[thread overview]
Message-ID: <20151218223701.GJ11072@wotan.suse.de> (raw)
In-Reply-To: <56559BA5020000F90001FC8B@relay2.provo.novell.com>

On Tue, Nov 24, 2015 at 08:29:41PM -0700, Gang He wrote:
> Hi Mark and Junxiao,
> 
> 
> >>> 
> > On Tue, Nov 03, 2015 at 04:20:27PM +0800, Junxiao Bi wrote:
> >> Hi Gang,
> >> 
> >> On 11/03/2015 03:54 PM, Gang He wrote:
> >> > Hi Junxiao,
> >> > 
> >> > Thank for your reviewing.
> >> > Current design, we use a sysfile as a interface to check/fix a file (via 
> > pass a ino number).
> >> > But, this operation is manually triggered by user, instead of automatically 
> >  fix in the kernel.
> >> > Why?
> >> > 1) we should let users make this decision, since some users do not want to 
> > fix when encountering a file system corruption, maybe they want to keep the 
> > file system unchanged for a further investigation.
> >> If user don't want this, they should not use error=continue option, let
> >> fs go after a corruption is very dangerous.
> > 
> > Maybe we need another errors=XXX flag (maybe errors=fix)?
> > 
> > You both make good points, here's what I gather from the conversation:
> > 
> >  - Some customers would be sad if they have to manually fix corruptions.
> >    This takes effort on their part, and if the FS can handle it
> >    automatically, it should.
> > 
> >  - There are valid concerns that automatically fixing things is a change in
> >    behavior that might not be welcome, or worse might lead to unforseeable
> >    circumstances.
> > 
> >  - I will add that fixing things automatically implies checking them
> >    automatically which could introduce some performance impact depending on
> >    how much checking we're doing.
> > 
> > So if the user wants errors to be fixed automatically, they could mount with
> > errros=fix, and everyone else would have no change in behavior unless they
> > wanted to make use of the new feature.
> That is what I want to say, add a mount option to let users to decide. Here, I want to split "error=fix"
> mount option  task out from online file check feature, I think this part should be a independent feature.
> We can implement this feature after online file check is done, I want to split the feature into some more 
> detailed features, implement them one by one. Do you agree this point?

Yeah that's fine, I would have automatic checking turned off though until we
have a good plan in place for users who do / don't want this.
	--Mark

--
Mark Fasheh

WARNING: multiple messages have this Message-ID (diff)
From: Mark Fasheh <mfasheh@suse.de>
To: Gang He <ghe@suse.com>
Cc: Junxiao Bi <junxiao.bi@oracle.com>,
	akpm@linux-foundation.org, ocfs2-devel@oss.oracle.com,
	rgoldwyn@suse.de, linux-kernel@vger.kernel.org
Subject: [Ocfs2-devel] [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check
Date: Fri, 18 Dec 2015 14:37:01 -0800	[thread overview]
Message-ID: <20151218223701.GJ11072@wotan.suse.de> (raw)
In-Reply-To: <56559BA5020000F90001FC8B@relay2.provo.novell.com>

On Tue, Nov 24, 2015 at 08:29:41PM -0700, Gang He wrote:
> Hi Mark and Junxiao,
> 
> 
> >>> 
> > On Tue, Nov 03, 2015 at 04:20:27PM +0800, Junxiao Bi wrote:
> >> Hi Gang,
> >> 
> >> On 11/03/2015 03:54 PM, Gang He wrote:
> >> > Hi Junxiao,
> >> > 
> >> > Thank for your reviewing.
> >> > Current design, we use a sysfile as a interface to check/fix a file (via 
> > pass a ino number).
> >> > But, this operation is manually triggered by user, instead of automatically 
> >  fix in the kernel.
> >> > Why?
> >> > 1) we should let users make this decision, since some users do not want to 
> > fix when encountering a file system corruption, maybe they want to keep the 
> > file system unchanged for a further investigation.
> >> If user don't want this, they should not use error=continue option, let
> >> fs go after a corruption is very dangerous.
> > 
> > Maybe we need another errors=XXX flag (maybe errors=fix)?
> > 
> > You both make good points, here's what I gather from the conversation:
> > 
> >  - Some customers would be sad if they have to manually fix corruptions.
> >    This takes effort on their part, and if the FS can handle it
> >    automatically, it should.
> > 
> >  - There are valid concerns that automatically fixing things is a change in
> >    behavior that might not be welcome, or worse might lead to unforseeable
> >    circumstances.
> > 
> >  - I will add that fixing things automatically implies checking them
> >    automatically which could introduce some performance impact depending on
> >    how much checking we're doing.
> > 
> > So if the user wants errors to be fixed automatically, they could mount with
> > errros=fix, and everyone else would have no change in behavior unless they
> > wanted to make use of the new feature.
> That is what I want to say, add a mount option to let users to decide. Here, I want to split "error=fix"
> mount option  task out from online file check feature, I think this part should be a independent feature.
> We can implement this feature after online file check is done, I want to split the feature into some more 
> detailed features, implement them one by one. Do you agree this point?

Yeah that's fine, I would have automatic checking turned off though until we
have a good plan in place for users who do / don't want this.
	--Mark

--
Mark Fasheh

  parent reply	other threads:[~2015-12-18 22:37 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-28  6:25 [PATCH v2 0/4] Add online file check feature Gang He
2015-10-28  6:25 ` [Ocfs2-devel] " Gang He
2015-10-28  6:25 ` [PATCH v2 1/4] ocfs2: export ocfs2_kset for online file check Gang He
2015-10-28  6:25   ` [Ocfs2-devel] " Gang He
2015-11-24 21:47   ` Mark Fasheh
2015-11-24 21:47     ` [Ocfs2-devel] " Mark Fasheh
2015-10-28  6:25 ` [PATCH v2 2/4] ocfs2: sysfile interfaces " Gang He
2015-10-28  6:25   ` [Ocfs2-devel] " Gang He
2015-11-03  7:20   ` Junxiao Bi
2015-11-03  7:20     ` [Ocfs2-devel] " Junxiao Bi
2015-11-03  7:54     ` Gang He
2015-11-03  7:54       ` [Ocfs2-devel] " Gang He
2015-11-03  8:20       ` Junxiao Bi
2015-11-03  8:20         ` [Ocfs2-devel] " Junxiao Bi
2015-11-03  8:30         ` Gang He
2015-11-03  8:30           ` [Ocfs2-devel] " Gang He
2015-11-24 21:46         ` Mark Fasheh
2015-11-24 21:46           ` [Ocfs2-devel] " Mark Fasheh
2015-11-24 21:55           ` Srinivas Eeda
2015-11-24 21:55             ` Srinivas Eeda
2015-11-25  3:29           ` Gang He
2015-11-25  3:29             ` [Ocfs2-devel] " Gang He
2015-11-25  4:43             ` Junxiao Bi
2015-11-25  4:43               ` [Ocfs2-devel] " Junxiao Bi
2015-11-25  5:11               ` Gang He
2015-11-25  5:11                 ` [Ocfs2-devel] " Gang He
2015-12-18 22:37             ` Mark Fasheh [this message]
2015-12-18 22:37               ` Mark Fasheh
2015-11-25  4:33           ` Junxiao Bi
2015-11-25  4:33             ` [Ocfs2-devel] " Junxiao Bi
2015-11-24 21:52   ` Mark Fasheh
2015-11-24 21:52     ` Mark Fasheh
2015-10-28  6:26 ` [PATCH v2 3/4] ocfs2: create/remove sysfile " Gang He
2015-10-28  6:26   ` [Ocfs2-devel] " Gang He
2015-11-24 21:53   ` Mark Fasheh
2015-11-24 21:53     ` [Ocfs2-devel] " Mark Fasheh
2015-10-28  6:26 ` [PATCH v2 4/4] ocfs2: check/fix inode block " Gang He
2015-10-28  6:26   ` [Ocfs2-devel] " Gang He
2015-11-03  7:12   ` Junxiao Bi
2015-11-03  7:12     ` [Ocfs2-devel] " Junxiao Bi
2015-11-03  8:15     ` Gang He
2015-11-03  8:15       ` [Ocfs2-devel] " Gang He
2015-11-03  8:29       ` Junxiao Bi
2015-11-03  8:29         ` [Ocfs2-devel] " Junxiao Bi
2015-11-03  8:47         ` Gang He
2015-11-03  8:47           ` [Ocfs2-devel] " Gang He
2015-11-03  9:01           ` Junxiao Bi
2015-11-03  9:01             ` [Ocfs2-devel] " Junxiao Bi
2015-11-03  9:25             ` Gang He
2015-11-03  9:25               ` [Ocfs2-devel] " Gang He
2015-11-24 22:16     ` Mark Fasheh
2015-11-24 22:16       ` Mark Fasheh
2015-11-25  4:11       ` Junxiao Bi
2015-11-25  4:11         ` Junxiao Bi
2015-11-25  5:04         ` Gang He
2015-11-25  5:04           ` Gang He
2015-11-25  5:44           ` Junxiao Bi
2015-11-25  5:44             ` Junxiao Bi
2015-10-28 16:34 ` [Ocfs2-devel] [PATCH v2 0/4] Add online file check feature Srinivas Eeda
2015-10-28 16:34   ` Srinivas Eeda
2015-10-29  4:44   ` Gang He
2015-10-29  4:44     ` Gang He
2015-10-29  7:46     ` Srinivas Eeda
2015-10-29  7:46       ` Srinivas Eeda
2015-10-29  8:26       ` Gang He
2015-10-29  8:26         ` Gang He
2015-12-02 18:20 ` Pavel Machek
2015-12-02 18:20   ` [Ocfs2-devel] " Pavel Machek
2015-12-03  2:05   ` Gang He
2015-12-03  2:05     ` [Ocfs2-devel] " Gang He
2015-12-03  5:17     ` Greg KH
2015-12-03  5:17       ` [Ocfs2-devel] " Greg KH
2015-12-04  8:36       ` Gang He
2015-12-04  8:36         ` [Ocfs2-devel] " Gang He
2015-12-04  9:20         ` Pavel Machek
2015-12-04  9:20           ` [Ocfs2-devel] " Pavel Machek
2015-12-04 16:40         ` Greg KH
2015-12-04 16:40           ` [Ocfs2-devel] " Greg KH
2015-12-07  3:33           ` Gang He
2015-12-07  3:33             ` [Ocfs2-devel] " Gang He

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=20151218223701.GJ11072@wotan.suse.de \
    --to=mfasheh@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=ghe@suse.com \
    --cc=junxiao.bi@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ocfs2-devel@oss.oracle.com \
    --cc=rgoldwyn@suse.de \
    /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.