MTD RAID

[Dongsheng Yang]

Okey, another idea about this. When we are writing data in ubi.
When we met a writing error like below.



ubi_eba_write_leb():

... ...
write_error:
     if (err != -EIO || !ubi->bad_allowed) {
         ubi_ro_mode(ubi);
         leb_write_unlock(ubi, vol_id, lnum);
         ubi_free_vid_hdr(ubi, vid_hdr);
         return err;
     }

     /*
      * Fortunately, this is the first write operation to this physical
      * eraseblock, so just put it and request a new one. We assume that if
      * this physical eraseblock went bad, the erase code will handle that.
      */
     err = ubi_wl_put_peb(ubi, vol_id, lnum, pnum, 1);
     if (err || ++tries > UBI_IO_RETRIES) {
         ubi_ro_mode(ubi);
         leb_write_unlock(ubi, vol_id, lnum);
         ubi_free_vid_hdr(ubi, vid_hdr);
         return err;
     }

     vid_hdr->sqnum = cpu_to_be64(ubi_next_sqnum(ubi));
     ubi_msg(ubi, "try another PEB");
     goto retry;
}

Okey, in this case, if this is the first writing on this block, that's
fortunate. But if not, we will lose our data.

But if we are using RAID-1 device, we can improve this case in
ubi. Then we can migrate data in this block at first and then
mark it as bad. Because we have mirrors in RAID-1, we can
read the data from it.

Sounds good?

Yang

On 08/19/2016 03:15 PM, Dongsheng Yang wrote:
> In addition, current implementation actually have a retry in reading.
>
>
>     if (++i_copy >= raid->ncopies)
>         goto out;
>
>     ret = mtd_raid_ctx_retry(ctx, i_copy);
>
>
> That means, we can read the good one copy from RAID-1 device even there
> is one bad device.
>
> Yang
>
> On 08/19/2016 03:08 PM, Dongsheng Yang wrote:
>>
>>
>> On 08/19/2016 02:49 PM, Boris Brezillon wrote:
>>> Hi Dongsheng,
>>>
>>> On Fri, 19 Aug 2016 14:34:54 +0800
>>> Dongsheng Yang <dongsheng081251 at gmail.com> wrote:
>>>
>>>> Hi guys,
>>>>      This is a email about MTD RAID.
>>>>
>>>> *Code:*
>>>>      kernel:
>>>> https://github.com/yangdongsheng/linux/tree/mtd_raid_v2-for-4.7
>>> Just had a quick look at the code, and I see at least one major problem
>>> in your RAID-1 implementation: you're ignoring the fact that NAND 
>>> blocks
>>> can be or become bad. What's the plan for that?
>>
>> Hi Boris,
>>     Thanx for your quick reply.
>>
>>     When you are using RAID-1, it would erase the all mirrored 
>> blockes when you are erasing.
>> if there is a bad block in them, mtd_raid_erase will return an error 
>> and the userspace tool
>> or ubi will mark this block as bad, that means, the 
>> mtd_raid_block_markbad() will mark the all
>>  mirrored blocks as bad, although some of it are good.
>>
>> In addition, when you have data in flash with RAID-1, if one block 
>> become bad. For example,
>> when the mtd0 and mtd1 are used to build a RAID-1 device mtd2. When 
>> you are using mtd2
>> and you found there is a block become bad. Don't worry about data 
>> losing, the data is still
>> saved in the good one mirror. you can replace the bad one device with 
>> another new mtd device.
>>
>> My plan about this feature is all on the userspace tool.
>> (1). mtd_raid scan mtd2 <---- this will show the status of RAID 
>> device and each member of it.
>> (2). mtd_raid replace mtd2 --old mtd1 --new mtd3.   <---- this will 
>> replace the bad one mtd1 with mtd3.
>>
>> What about this idea?
>>
>> Yang
>>>
>>> Regards,
>>>
>>> Boris
>>>
>>> ______________________________________________________
>>> Linux MTD discussion mailing list
>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>
>>
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>