[RFC] UBIFS recovery

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

But if the driver could provide you read access to uncorrupted files
even though the file-system is corrupted, this would be useful. The
driver would not need to do any recovery - no write or erase operation
allowed.

I think this is hard in general, but probably doable for some cases.

Artem.