Re: [RFC] UBIFS recovery

[Richard Weinberger <richard@nod.at>]

Am 09.02.2015 um 04:00 schrieb hujianyang:
>> 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".
>>
> 
> Er, maybe I know what you mean.
> 
> So you think by debugfs.ubifs, we could get wanted file out from a partition
> without mounting it? and do other things like (?)

This is the use case of a debugfs. See debugfs.ext2/3/4, etc...
You can debug (analyze, get files your, etc...) from a broken filesystem
without mounting it.

> Moving less files out maybe simpler than mounting the whole partition in some
> cases. But is it acceptable for scripts? If someone want to perform some binary
> files on the corrupted ubifs. I think mounting a R/O partition is better than
> moving the request file out and then run it.

Scripts?
debugfs is meant for _manual_ forensics/recovery.
Mounting R/O is not always an option, we cannot make UBIFS that smart that you
can always turn it into a state where you can safely get everything out of it.
And as I wrote in a previous mail, the interaction between kernel and user is almost zero.
Debugfs can ask questions and give you a much better overall overview of the filesystem.
This is exactly why debugfs was invented. You can also manually fix/transform the filesystem...

Thanks,
//richard