Re: [RFC] UBIFS recovery

[Richard Weinberger <richard@nod.at>]

Am 06.02.2015 um 18:40 schrieb Artem Bityutskiy:
> On Fri, 2015-02-06 at 18:33 +0100, 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.
> 
> The user-space tool would turn a corrupted FS into an uncorrupted FS.

This is what fsck.ubifs should to. I was talking about a debugfs.ubifs which
is able to extract files, ask questions, and tell the user what exactly is going
wrong. Like "yes, I can dump you file /foo/bar.dat but rage 5m to 10m maybe be corrupted and the xattrs are gone".

Thanks,
//richard