Re: [RFC] UBIFS recovery

[hujianyang <hujianyang@huawei.com>]

Hi Artem and Richard,

On 2015/2/9 15:57, Richard Weinberger wrote:
> Am 09.02.2015 um 08:51 schrieb Artem Bityutskiy:
>> On Mon, 2015-02-09 at 10:34 +0800, hujianyang wrote:
>>> Good suggestions. I will try to realize periodically commit first. But I
>>> don't know if this feature is really needed. Switch to R/O and revert to
>>> last comitted state? But we just consider about log before, never think
>>> about index.
>>
>> I think the right way to approach this problem is to come up with a high
>> level summary of the problems we are trying to solve, and the solutions,
>> along with some analysis of the solutions. This does not have to be very
>> detailed, but it should put everyone involved into the same page.
> 
> Agreed. I fear we're talking about different things. :)
> 

I'm afraid I didn't express the use case of the corruption recovery feature.
UBIFS is used mostly in embedded environment. After products selling out,
it's hard to debug it. So the production team may consider any failure that
could happen and put the recovery method into their operation scripts/utilities.

Flash corruption is a problem they need to care about. Using high quality
cell is not enough, ECC error could not be avoid. So a recovery method which
is provided by filesystem itself is required. This feature is not used by
us, the developer of kernel, but the production team. They know little about
linux kernel. So the easier interface we provide, the much effective recovery
method of the products they could make. So, Artem, I'm agree with your another
email mail about R-gadget and H-gadget.

I think mount R/O is a good beginning. We don't need consider much about how
to recover but can provide a usable(in some cases) file-system. And a R/O
mount means we could do some cleanup to revert to this R/O state. This R/O
mount should be provided by driver itself without any userspace tools.

Thanks,
Hu