[RFC] UBIFS recovery

Artem Bityutskiy dedekind1 at gmail.com
Fri Feb 6 09:26:11 PST 2015

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.

I can see a potential problem of reading "insane" data from flash (some
circular never ending references, etc) - the driver should be very
careful about those. On the other hand, the driver should be careful
even if we are not talking about corruptions.


More information about the linux-mtd mailing list