[RFC] UBIFS recovery

hujianyang hujianyang at huawei.com
Sun Feb 8 18:48:18 PST 2015

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.


More information about the linux-mtd mailing list