Re: [RFC] UBIFS recovery

[hujianyang <hujianyang@huawei.com>]

On 2015/2/7 1:33, Richard Weinberger wrote:
> Am 06.02.2015 um 18:26 schrieb Artem Bityutskiy:
>> On Thu, 2015-02-05 at 07:08 -0800, Steve deRosier wrote:
>>> I hear (and agree with) several valid arguments for a tool in
>>> userspace. And I'd like to throw my support towards an in-driver
>>> solution. Flash filesystems are different than on-disk filesystems, in
>>> particular in their usecase: they're generally both critical and
>>> exclusive to embedded systems. As such, the entire filesystem might be
>>> on the corrupted UBIFS, so even if the filesystem is recoverable, if
>>> we can't mount it and get at the userspace tool, then we're toast.
>>> Often the kernel itself is stored in a separate read-only partition as
>>> a blob directly on the flash, and thus the kernel itself would be
>>> fine. The better UBI & UBIFS can recover to a usable state in-kernel,
>>> the better off we are I think.
>>
>> Yes, being able to mount a corrupted FS R/O sounds like a good goal. We
>> are not speaking of recovery here, just about mounting R/O and providing
>> access to as much uncorrupted data as we can.
>>
>> If FS index is not corrupted, this sounds quite doable. If the index is
>> corrupted, though, this requires full scan and index rebuild. Other wise
>> we'd mount and show empty file-system.
> 
> While I agree that mounting RO to get access to data is a feasible goal
> I really think that this is the job of a debugfs.ubifs tool.
> The kernel cannot ask questions, such a tool can.
> 

Hi Richard,

What's the different between fsck.ubifs and debugfs.ubifs? Debugfs.ubifs
seems need to provide more debugging option, not just recovery. Could you
please talk more about your thinking?

For mounting R/O case, I think we could do it directly in kernel.

Thanks,
Hu