Linux ocfs2 filesystem development
 help / color / mirror / Atom feed
From: Junxiao Bi <junxiao.bi@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [RFC] Online File(system) check
Date: Mon, 04 May 2015 10:55:27 +0800	[thread overview]
Message-ID: <5546DF9F.8030106@oracle.com> (raw)
In-Reply-To: <5544C6DD.8000406@suse.de>

On 05/02/2015 08:45 PM, Goldwyn Rodrigues wrote:
> 
> 
> On 04/29/2015 02:59 AM, Junxiao Bi wrote:
>> On 04/28/2015 05:32 AM, Goldwyn Rodrigues wrote:
>>> On popular demand, here is an RFC. If you think there is a better
>>> way to communicate with the kernel module for the check, please
>>> let me know.
>>>
>>>
>>> Intro
>>> -----
>>> OCFS2 is often used in high-availaibility systems. However, ocfs2
>>> converts the filesystem to read-only at the drop of the hat. This
>>> may not be necessary, since turning the filesystem read-only would
>>> affect other running processes as well, decreasing availability.
>>>
>>> This attempt is to add errors=continue, which would return the EIO
>>> to the calling process and terminate furhter processing so that
>>> the filesystem is not corrupted further. However, the filesystem
>>> is not converted to read-only.
>> Is this safe, if detected an error when accessing an inode, how do you
>> know this is only inode internal error?
> 
> 
> Thanks for your comments. The error message would need to be modified to
> specify the inode(s) which need to be checked. It could be a regular
> file or the system inode.
> 
>> If there is corruptions in other
>> place, the fs will be corrupted further.
>>
> It there is a corruption in another place, the process will err at that
> location.
> 
> Could you provide a sample case to explain this situation? and how is it
> different from what is already present in the code?

For example, if a disk had some bit reversion error, some used bits in
local alloc are marked free and also an inode X's inline flag is
cleared, set fs read-only when detected the inode error at the first
time will stop more data corruption.

I think if want to continue for some inconsistent, we need to prove it's
safe, if can't then better stop at first time.

Thanks,
Junxiao.

> 

      reply	other threads:[~2015-05-04  2:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-27 21:32 [Ocfs2-devel] [RFC] Online File(system) check Goldwyn Rodrigues
2015-04-28  3:00 ` Gang He
2015-04-28 12:21   ` Goldwyn Rodrigues
2015-04-28 13:20     ` Joseph Qi
2015-04-29  2:37       ` Gang He
2015-04-30  2:29         ` Joseph Qi
2015-05-02 12:52         ` Goldwyn Rodrigues
2015-05-02 13:08       ` Goldwyn Rodrigues
2015-05-04  1:46         ` Joseph Qi
2015-04-29  7:59 ` Junxiao Bi
2015-05-02 12:45   ` Goldwyn Rodrigues
2015-05-04  2:55     ` Junxiao Bi [this message]

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=5546DF9F.8030106@oracle.com \
    --to=junxiao.bi@oracle.com \
    --cc=ocfs2-devel@oss.oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox