new UBI co-maintainer

new UBI co-maintainer

[Artem Bityutskiy]

Hi,

I'd like to give Richard Weinberger UBI tree push rights, so that he
could help us improving the QoS.

If no one objects, lets make it effective.

-- 
Best Regards,
Artem Bityutskiy

Re: new UBI co-maintainer

[Brian Norris]

On Thu, Jan 22, 2015 at 11:26:02AM +0200, Artem Bityutskiy wrote:
> I'd like to give Richard Weinberger UBI tree push rights, so that he
> could help us improving the QoS.
> 
> If no one objects, lets make it effective.

Ack! Thanks to both of you.

Brian

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

[hujianyang]

On 2015/1/22 17:26, Artem Bityutskiy wrote:
> Hi,
> 
> I'd like to give Richard Weinberger UBI tree push rights, so that he
> could help us improving the QoS.
> 
> If no one objects, lets make it effective.
> 

Hi Artem,

First, thank Richard for his contributions to UBI/UBIFS.


I regret to say the updating of UBI/UBIFS was blocked about 2 months.
So Richard could help us maintaining the improvement of UBIFS next?

I've sent some patches to MTD list these days, what's the opinion of
you and Richard about these pacthes?

   [PATCH] UBI: add ubi_err() to report the failure of leb read
   [PATCH RFC 1/2] UBIFS: fix empty log leb error
   [PATCH] UBI: fix soft lockup in ubi_check_volume()

   and ubidump v6

The patch "UBI: fix soft lockup in ubi_check_volume()" solves a really
important problem, I wish it could be merged into stable soon.

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.

Also, I think we could start to add more functions to my ubidump to
make it a useful tool.

I think the updating of UBI/UBIFS will re-start soon, am I right?

BR,
Hu

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

[Richard Weinberger]

Hi!

Am 28.01.2015 um 03:43 schrieb hujianyang:
> On 2015/1/22 17:26, Artem Bityutskiy wrote:
>> Hi,
>>
>> I'd like to give Richard Weinberger UBI tree push rights, so that he
>> could help us improving the QoS.
>>
>> If no one objects, lets make it effective.
>>
> 
> Hi Artem,
> 
> First, thank Richard for his contributions to UBI/UBIFS.
> 
> 
> I regret to say the updating of UBI/UBIFS was blocked about 2 months.
> So Richard could help us maintaining the improvement of UBIFS next?
> 
> I've sent some patches to MTD list these days, what's the opinion of
> you and Richard about these pacthes?
> 
>    [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.

>    [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.

>    [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 think the updating of UBI/UBIFS will re-start soon, am I right?

Correct. Currently I'm preparing the tree.

Thanks,
//richard

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

[hujianyang]

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

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

[Richard Weinberger]

Am 29.01.2015 um 04:28 schrieb hujianyang:
> 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.

Please send them and describe the issues in details, provide a test case, etc...
It is also important to tell us *how* this bug can happen.

>>>    [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.
> 
> 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.

Fastmap is experimental for good reasons. :)
With my current patches nobody was able to kill it, so maybe I'll
remove the experimental tag in v3.25.

> 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?

UBI Block, it was designed for that case.
Just compare the number of layers. :)

Thanks,
//richard