From: Artem Bityutskiy <dedekind1@gmail.com>
To: Dongsheng Yang <dooooongsheng.yang@gmail.com>
Cc: Dongsheng Yang <dongsheng.yang@easystack.cn>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
starvik@axis.com, jesper.nilsson@axis.com,
Dongsheng Yang <yangds.fnst@cn.fujitsu.com>,
shengyong1@huawei.com, linux-cris-kernel@axis.com,
Brian Norris <computersforpeace@gmail.com>,
Richard Weinberger <richard@nod.at>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
jschultz@xes-inc.com, fabf@skynet.be, mtownsend1973@gmail.com,
linux-mtd@lists.infradead.org,
Colin King <colin.king@canonical.com>,
asierra@xes-inc.com, dmitry.torokhov@gmail.com,
Dongsheng Yang <dongsheng081251@gmail.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: MTD RAID
Date: Mon, 22 Aug 2016 17:54:06 +0300 [thread overview]
Message-ID: <1471877646.15722.61.camel@gmail.com> (raw)
In-Reply-To: <CAAp9bSh-geStbHpA6+vYdLfNLcinWkfVLOGmX4kdRbja+d2MdA@mail.gmail.com>
On Mon, 2016-08-22 at 18:55 +0800, Dongsheng Yang wrote:
>
>
> On Mon, Aug 22, 2016 at 3:27 PM, Artem Bityutskiy <dedekind1@gmail.co
> m> wrote:
> > On Mon, 2016-08-22 at 11:22 +0800, Dongsheng Yang wrote:
> > > As I explained above, MTD RAID is not just a solution for
> > reliability
> > > problem for MLC/TLC.
> >
> > Could you please answer these questions.
> >
> > 1. Does MTD raid work on MLC or is it SLC-only?
>
> Good question. No, it is based on MTD layer, so it should be fine for
> any MTD devices in theory, although we are using nand flash in our
> production.
> >
> > 2. If I am building RAID-0, I have 2 flash chips, one has every
> > even
> > block bad, the other has every odd block bad. What happens?
>
> All blocks would be marked as bad. Because we are combining the
> striping related blocks as a larger block, so if one of the blocks is
> bad, we will
> mark the virtual large block as bad. Example as RAID0 in my first
> email, I build a RAID0 device by 4 devices with block size of 16K.
> then the block
> size of the new RAID0 device is 64K. I am combining these 4 devices
> and do a striping on the new/larger block, for a better performance.
> >
> > 3. Same question, but for RAID-1.
>
> Same result but with different reason, In RAID1, we don't need to
> enlarge the block size. But we should make the blockes mirrored. If
> block of the
> master or mirror is bad, then the block for the RAID1 device should
> be marked as bad, because we can't promise requested number of copies
> of data in this case.
> >
> > 4. Suppose I have RAID-1 like in this picture:
> >
> > https://en.wikipedia.org/wiki/Standard_RAID_levels#/media/File:RAID
> > _1.svg
> >
> > Just assume we have flash chips, not disks, and eraseblocks, not
> > sectors.
> >
> > Suppose eraseblock A1 goes bad. What happens next?
>
> If A1 in disk0 goes bad, the data will be read out from disk1. But
> there would be a warning about this problem. Then we should noticed
> that our
> data in this section is not safe enough now. Then there are different
> scenario.
> (1) you are using ubi on this device, I mentioned once last week, we
> can enhance ubi to notice this kind of problem, then do a data
> migration.
So to make my data become mirrored again, MTD RAID needs help from
upper layers.
In case of RAID, you do not need this kind of help. All you need is
change the disk when it starts getting bad sectors.
I mean, this is a bit like: here is our MTD RAID which is not a RAID
unless it works with special SW like UBI on top of it.
Are you sure you want to call this MTD RAID?
If this was on top of UBI, the RAID would probably be a closer match,
because then you could assume you are on top of a "reliable" media.
Note, I am not insisting, just asking.
> (2) you are using some other application on this device, Then you can
> check the status of this MTD RAID device now by "mtd_raid scan <dev>"
> if this command report there is some blocks are bad, you can do a
> "mtd_raid replace <>" to replace the bad one.
How will the replacement work. What gets replaced - the entire flash
chip? Probably not, because bad blocks are natural for raw NAND. Then
how do you replace the blocks if there is an FS on top?
Artem.
next prev parent reply other threads:[~2016-08-22 14:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA+qeAOpuZ0CXZP8tCWdhoVvTEKAw26gtz63-UJmQ4XLSXAd=Yg@mail.gmail.com>
2016-08-19 6:49 ` MTD RAID Boris Brezillon
2016-08-19 7:08 ` Dongsheng Yang
2016-08-19 7:15 ` Dongsheng Yang
2016-08-19 7:28 ` Dongsheng Yang
2016-08-19 8:20 ` Boris Brezillon
[not found] ` <CA+qeAOrSAi9uTHGCi-5cAJpM_O45oJUihNP-rHHa1FWL7_ZKHQ@mail.gmail.com>
2016-08-19 9:37 ` Boris Brezillon
2016-08-19 10:22 ` Dongsheng Yang
2016-08-19 11:36 ` Boris Brezillon
[not found] ` <57B6CC7B.1060208@easystack.cn>
2016-08-19 9:47 ` Richard Weinberger
2016-08-19 10:30 ` Dongsheng Yang
2016-08-19 10:30 ` Artem Bityutskiy
2016-08-19 10:38 ` Dongsheng Yang
[not found] ` <AL*AZwAyAecQSM1UjjjNxao0.3.1471605640762.Hmail.dongsheng.yang@easystack.cn>
2016-08-19 11:55 ` Boris Brezillon
2016-08-22 4:01 ` Dongsheng Yang
2016-08-22 7:09 ` Boris Brezillon
[not found] ` <57BA6FFA.6000601@easystack.cn>
2016-08-22 7:07 ` Boris Brezillon
2016-08-22 7:27 ` Artem Bityutskiy
[not found] ` <CAAp9bSh-geStbHpA6+vYdLfNLcinWkfVLOGmX4kdRbja+d2MdA@mail.gmail.com>
2016-08-22 14:54 ` Artem Bityutskiy [this message]
2016-08-22 15:30 ` David Woodhouse
2016-08-23 3:44 ` Dongsheng Yang
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=1471877646.15722.61.camel@gmail.com \
--to=dedekind1@gmail.com \
--cc=ard.biesheuvel@linaro.org \
--cc=asierra@xes-inc.com \
--cc=boris.brezillon@free-electrons.com \
--cc=colin.king@canonical.com \
--cc=computersforpeace@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=dongsheng.yang@easystack.cn \
--cc=dongsheng081251@gmail.com \
--cc=dooooongsheng.yang@gmail.com \
--cc=dwmw2@infradead.org \
--cc=fabf@skynet.be \
--cc=jesper.nilsson@axis.com \
--cc=jschultz@xes-inc.com \
--cc=linux-cris-kernel@axis.com \
--cc=linux-mtd@lists.infradead.org \
--cc=mtownsend1973@gmail.com \
--cc=richard@nod.at \
--cc=shengyong1@huawei.com \
--cc=starvik@axis.com \
--cc=yangds.fnst@cn.fujitsu.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.