All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhiqiang Liu <liuzhiqiang26@huawei.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Haotian Li <lihaotian9@huawei.com>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	"harshad shirwadkar," <harshadshirwadkar@gmail.com>,
	linfeilong <linfeilong@huawei.com>
Subject: Re: [PATCH] e2fsprogs: Try again to solve unreliable io case
Date: Sat, 24 Apr 2021 12:46:17 +0800	[thread overview]
Message-ID: <6bc8c1c2-9fff-bef9-c6f3-b2256a4888e1@huawei.com> (raw)
In-Reply-To: <YILrxJoOA1reNhMq@mit.edu>



On 2021/4/23 23:46, Theodore Ts'o wrote:
> On Fri, Apr 23, 2021 at 10:18:09AM +0800, Zhiqiang Liu wrote:
>> Thanks for your reply.
>> Actually, we have met the problem in ipsan situation.
>> When exec 'fsck -a <remote-device>', short-term fluctuations or
>> abnormalities may occur on the network. Despite the driver has
>> do the best effort, some IO errors may occur. So add retrying in
>> e2fsprogs can further improve the reliability of the repair
>> process.
> 
> But why doesn't this happen when the file system is mounted, and why
> is that acceptable?   And why not change the driver to do more retries?
> 
>    		      	      	  - Ted
> 
Actually, this may happen when the filesystem is mounted. The difference
is that the mounted filesystem can ensure the consistency with journal.

For example, if the IO error occurs when calling io_channel_write_byte()
to update superblock, the checksum may be not written to the disk successfully.
Then the checksum error will occur, and the filesystem cannot be
repaired with 'fsck -y|a|f'.

This situation has a very low probability. For improving the reliability of
the repair process, the retries in e2fsprogs may be necessary.

Regards
Zhiqiang Liu.

> .
> 


  reply	other threads:[~2021-04-24  4:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20  7:18 [PATCH] e2fsprogs: Try again to solve unreliable io case Haotian Li
2021-04-20 15:08 ` Darrick J. Wong
2021-04-22 13:03   ` Zhiqiang Liu
2021-04-20 16:19 ` Theodore Ts'o
2021-04-23  2:18   ` Zhiqiang Liu
2021-04-23 15:46     ` Theodore Ts'o
2021-04-24  4:46       ` Zhiqiang Liu [this message]
2021-05-10  3:35         ` Zhiqiang Liu

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=6bc8c1c2-9fff-bef9-c6f3-b2256a4888e1@huawei.com \
    --to=liuzhiqiang26@huawei.com \
    --cc=harshadshirwadkar@gmail.com \
    --cc=lihaotian9@huawei.com \
    --cc=linfeilong@huawei.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.