From: Jeff Moyer <jmoyer@redhat.com>
To: Zheng Liu <gnehzuil.liu@gmail.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
"Theodore Ts'o" <tytso@mit.edu>,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH v1 0/5] ext4: Shut down block groups when damage is detected
Date: Mon, 29 Jul 2013 11:28:38 -0400 [thread overview]
Message-ID: <x49txjdbd21.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <20130721143226.GA13473@gmail.com> (Zheng Liu's message of "Sun, 21 Jul 2013 22:32:26 +0800")
Zheng Liu <gnehzuil.liu@gmail.com> writes:
> My idea is to let file system can ignore the currurted block. Namely,
> when we meet a currupted block, we will track it as bad block in bad
> block inode and find another block to save data. This currupted block
> will never be used. The first step in my mind is to detect a currpted
> block and mark it as bad block. After reading the thread and Darrick's
> original patch, I think Darrick's patch is a good start.
I think it's important to call out the exact failure scenario you're
trying to address. For hard disks, if you get a read error, it can
typically be recovered by re-writing the block. I imagine this is what
fsck would be doing for metadata repair. So, I'm not at all sure why
you'd want to track bad blocks in the file system itself. Could you
elaborate, please?
Cheers,
Jeff
next prev parent reply other threads:[~2013-07-29 15:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-19 23:55 [PATCH v1 0/5] ext4: Shut down block groups when damage is detected Darrick J. Wong
2013-07-19 23:55 ` [PATCH 1/5] ext4: Error out if verifying the block bitmap fails Darrick J. Wong
2013-08-28 19:36 ` Theodore Ts'o
2013-07-19 23:55 ` [PATCH 2/5] ext4: Fix type declaration of ext4_validate_block_bitmap Darrick J. Wong
2013-07-24 7:12 ` Zheng Liu
2013-07-26 16:06 ` Darrick J. Wong
2013-08-28 20:01 ` Theodore Ts'o
2013-07-19 23:55 ` [PATCH 3/5] ext4: Mark block group as corrupt on block bitmap error Darrick J. Wong
2013-07-23 3:38 ` Darrick J. Wong
2013-08-28 22:26 ` Theodore Ts'o
2013-07-19 23:55 ` [PATCH 4/5] ext4: Mark block group as corrupt on inode " Darrick J. Wong
2013-07-24 7:22 ` Zheng Liu
2013-08-28 22:45 ` Theodore Ts'o
2013-07-19 23:56 ` [PATCH 5/5] ext4: Mark group corrupt on group descriptor checksum error Darrick J. Wong
2013-08-28 22:49 ` Theodore Ts'o
2013-07-21 14:32 ` [PATCH v1 0/5] ext4: Shut down block groups when damage is detected Zheng Liu
2013-07-29 15:28 ` Jeff Moyer [this message]
2013-07-30 0:31 ` Zheng Liu
2013-07-31 18:52 ` Jan Kara
2013-07-31 21:28 ` Theodore Ts'o
2013-07-30 1:57 ` Theodore Ts'o
2013-08-10 6:02 ` Darrick J. Wong
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=x49txjdbd21.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=gnehzuil.liu@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).