Re: Current linux-next status of UBI/UBIFS? Re: new UBI co-maintainer

[hujianyang <hujianyang@huawei.com>]

Hi Richard,

On 2015/1/28 23:47, Richard Weinberger wrote:
>>
>>    [PATCH] UBI: add ubi_err() to report the failure of leb read
> 
> IIRC I had some questions on that patch. If all questions are resolved I'm fine with it.
> 

Yes, I know that. OK... I'll re-check your comments and send this
patch again.

>>    [PATCH RFC 1/2] UBIFS: fix empty log leb error
> 
> These patches look okay to me but as they are posted as RFC I really want
> a comment from Artem on them.
>

I wish it could be soon, because there are some other patches about
mounting reliability improvement I want to send. Could I send them
together? But I haven't finished this work, so I think one by one
is the best way, and I can discuss the designing with you and Artem
in time.

>>    [PATCH] UBI: fix soft lockup in ubi_check_volume()
> 
> I'm also fine with that.
> 
>>    and ubidump v6
> 
> For ubidump I have to read the whole thread again as I got lost in it. :)
> 
>> The patch "UBI: fix soft lockup in ubi_check_volume()" solves a really
>> important problem, I wish it could be merged into stable soon.
> 
> Yes.
> 
>> I've discussed with Richard about the recovery of an corrupted UBIFS
>> image, for example, ECC error. And actually my colleagues and I had
>> worked out some features to improve the reliability of UBIFS. We are
>> happy to share our design and greatly aspire the help from community.
> 
> Nice.
> 
>> Also, I think we could start to add more functions to my ubidump to
>> make it a useful tool.
> 
> I have to look at ubidump in detail but it sounds good.
> To debug fastmap issues I have also a tool to analyze UBI images.
> Maybe we can merge. First I have to shape it up.
> 

I'm glad with it. I was using ubidump for debugging these days,
but I'm not sure if this v6 is OK. I'd fixed some tiny issues
after v5 so I don't know if there are still other issues left.
Thanks for your reviewing.

Actually I'm working on a 3.10-stable branch, new features like
ubiblock, ubifastmap are not introduced into my version. But
we will update kernel version soon and import these features.

I see ubifastmap is marked as "Experimental feature" now and
you'd introduced multi-queue for ubiblock. I think some works,
e.g. testing, are really needed before importing these feature
into our products.

I'd like to work with you for both dumping tool and features
in kernel.

>> I think the updating of UBI/UBIFS will re-start soon, am I right?
> 
> Correct. Currently I'm preparing the tree.
> 

I see more and more products in my company turn to use UBIFS
instead of Yaffs2/Jffs2. One of the prime reasons is the well
supporting by community. Thanks for the contributes from you,
Artem and other developers.

By the way, I found some products in my company are using
MTD_UBI_GLUEBI to implement a squashfs on top of UBI device.
UBI_GLUEBI or UBI_BLOCK, which is better in your considering,
and why?


Thanks,
Hu