RE: [EXT] Re: [PATCH V1] mtd: core: Micron SLC NAND filling block

["Bean Huo (beanhuo)" <beanhuo@xxxxxxxxxx>]

Hi, Richard
thanks for your review.

>Am Mittwoch, 19. Dezember 2018, 12:03:06 CET schrieb Bean Huo (beanhuo):
>> +#define PARTIAL_FILLING_CHECKUP 1 /* Used to turn on/off partial filling
>> +		 block checkup before erasing this block.*/ #define
>> +LAST_CHECKPU_PAGE 13 struct ubifs_filling_head {
>> +	__le32 magic;
>> +	__le32 crc;
>> +	__le64 sqnum;
>> +	__le32 len;
>> +	__u8 node_type;
>> +	__u8 group_type;
>> +	__u8 padding[2];
>> +	__le32 pad_len;
>> +} __packed;
>
>I don't think this is needed anymore.
>

Thanks, I agree with you, and will be removed in next version.

>If you overwrite (sub)pages 0 and 1, UBI EC and VID headers are gone.
>In case of a power-cut before the erase operation, UBI will detect the
>corrupted EC and VID headers and re-erase the block.

This is actually what I want. Means always overwrite EC and VID headers, in order to 
let UBI to re-erase this block just because of this block contains my filling data (resulting from one power-cut after filling pages).
Otherwise, for the next boot, during attach stage, UBIFS will consider this block to be a corrupted block.

let me take one example, eg, the last programmed page is page8, and after the filling pages, 
before mtd->_erase, power-cut hits, so in this block, there will be below data layout, 

Page0 : EC header
Page1: VID header
Page2: not empty, valid data 
Page3: not empty, valid data
Page4: not empty, valid data
Page5: not empty, valid data
Page6: not empty, valid data
Page7: not empty, valid data
Page8: not empty, valid data

Page9: filled with padding data by the patch
Page10: empty, keep all 0xff
Page11: filled with padding data by the patch
Page12: empty, keep all 0xff
Page13: filled with padding data by the patch

As for the older UBIFS (eg, v4.2), there will result in attach failure, but for the latest
UBIFS, if I don't overwrite EC and VID header, will this condition happen?

>For a fastmap attach the story is different, it does not track unmap/erase
>operations. Therefore it will not notice that the block was scheduled for erase
>and got corrupted by overwriting the first pages.
>Users on top of UBIFS will face either ECC errors or UBIFS complains about
>corrupted empty space.
>This fastmap issue got fixed with:
>781932375ffc ("ubi: fastmap: Correctly handle interrupted erasures in EBA")
>
>So your ubifs_filling_head struct seems to work around an already fixed UBI
>bug. :-)
>

Thanks for your info.
"ubi: fastmap: Correctly handle interrupted erasures in EBA" patch is merged from v4.18.
So, I still need to firstly rebase patch to latest kernel, then let's have a look.

>Thanks,
>//richard
>

//Bean


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/