* new UBI co-maintainer @ 2015-01-22 9:26 Artem Bityutskiy 2015-01-22 21:57 ` Brian Norris 2015-01-28 2:43 ` Current linux-next status of UBI/UBIFS? " hujianyang 0 siblings, 2 replies; 6+ messages in thread From: Artem Bityutskiy @ 2015-01-22 9:26 UTC (permalink / raw) To: linux-mtd 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: new UBI co-maintainer 2015-01-22 9:26 new UBI co-maintainer Artem Bityutskiy @ 2015-01-22 21:57 ` Brian Norris 2015-01-28 2:43 ` Current linux-next status of UBI/UBIFS? " hujianyang 1 sibling, 0 replies; 6+ messages in thread From: Brian Norris @ 2015-01-22 21:57 UTC (permalink / raw) To: Artem Bityutskiy; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Current linux-next status of UBI/UBIFS? Re: new UBI co-maintainer 2015-01-22 9:26 new UBI co-maintainer Artem Bityutskiy 2015-01-22 21:57 ` Brian Norris @ 2015-01-28 2:43 ` hujianyang 2015-01-28 15:47 ` Richard Weinberger 1 sibling, 1 reply; 6+ messages in thread From: hujianyang @ 2015-01-28 2:43 UTC (permalink / raw) To: artem.bityutskiy Cc: Richard Weinberger, Li Zefan, Brian Norris, linux-mtd, Sheng Yong 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Current linux-next status of UBI/UBIFS? Re: new UBI co-maintainer 2015-01-28 2:43 ` Current linux-next status of UBI/UBIFS? " hujianyang @ 2015-01-28 15:47 ` Richard Weinberger 2015-01-29 3:28 ` hujianyang 0 siblings, 1 reply; 6+ messages in thread From: Richard Weinberger @ 2015-01-28 15:47 UTC (permalink / raw) To: hujianyang, artem.bityutskiy Cc: Li Zefan, Brian Norris, linux-mtd, Sheng Yong 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Current linux-next status of UBI/UBIFS? Re: new UBI co-maintainer 2015-01-28 15:47 ` Richard Weinberger @ 2015-01-29 3:28 ` hujianyang 2015-01-29 9:08 ` Richard Weinberger 0 siblings, 1 reply; 6+ messages in thread From: hujianyang @ 2015-01-29 3:28 UTC (permalink / raw) To: Richard Weinberger Cc: Brian Norris, artem.bityutskiy, Li Zefan, linux-mtd, Sheng Yong 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Current linux-next status of UBI/UBIFS? Re: new UBI co-maintainer 2015-01-29 3:28 ` hujianyang @ 2015-01-29 9:08 ` Richard Weinberger 0 siblings, 0 replies; 6+ messages in thread From: Richard Weinberger @ 2015-01-29 9:08 UTC (permalink / raw) To: hujianyang Cc: Brian Norris, artem.bityutskiy, Li Zefan, linux-mtd, Sheng Yong 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-01-29 9:08 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-22 9:26 new UBI co-maintainer Artem Bityutskiy 2015-01-22 21:57 ` Brian Norris 2015-01-28 2:43 ` Current linux-next status of UBI/UBIFS? " hujianyang 2015-01-28 15:47 ` Richard Weinberger 2015-01-29 3:28 ` hujianyang 2015-01-29 9:08 ` Richard Weinberger
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.