strange yaffs2 state / corruption (hard links pointing to parent ?)

[Jerome Lacoste]

I've been playing a bit too much with Cyanogenmod on my ADP1, and I
have the following issue:

# pwd
/data/data/com.android.vending/cache

# ls -ail
536 drwxrwx--x 1 app_30 app_30 2048 Jul 24 11:40
536 drwxrwx--x 1 app_30 app_30 2048 Jul 24 11:40
536 drwxrwx--x 1 app_30 app_30 2048 Jul 24 11:40 .
421 drwxr-xr-x 1 app_30 app_30 2048 Jul 13 09:29 ..

I.e. some files have no name but same inode. they point to their
parent. I thus can't delete recursively nor move it away. Some sort of
unnamed hard link ?
I can't use find -inum to remove them individually as busybox isn't
compiled with the proper option in cyanogenmod. Not even sure that
would have helped.

I can't fsck (no fsck.yaffs2 ?)

Any idea how to get rid of this problem ? (apart from formatting the
partition).

[Jerome Lacoste]

Not finding a way to solve it at the file system level, I wiped /data
and restored it using a nandroid backup.

Thanks,

Jerome

[Dan Christensen]

Jerome Lacoste <jerome....@gmail.com>
writes:

I just installed cyanogen 5.0.8 for the first time a couple of days ago,
and noticed the same problem in the same directory. Here's the output
using adb shell while in the recovery screen [which explains the numeric
user and group ids]:

# ls -ail
801 drwxrwx--x 1 10033 10033 2048 Aug 10 23:07
801 drwxrwx--x 1 10033 10033 2048 Aug 10 23:07 .
1 drwxrwx--x 1 1000 1000 2048 Aug 10 23:05 ..

The filename is truly empty, as can be seen by running 'ls | od -a'.

It causes any program that tries to recursively search the filesystem to
loop, and I can't get rid of the bad directory entry.

Can I use tar to backup everything in my /data partition (except the one
corrupt directory) to a file on my sdcard, then reformat the data
partition, and then untar to restore? I'm not familiar with yaffs2,
so I don't know whether that would save everything correctly.

Thanks for any suggestions.

Dan

[Patrick Jacques]

I've been seeing a lot of reports about this and found:

http://yaffs.net/gitweb?p=yaffs2/.git;a=commit;h=66dfee0783bfda493d1b8f8f900906f103b23c6b

CM5 and 6 use 2.6.34.  I'm building a test kernel with the recent changes pushed by Charles, if they prove to be safe I'll do a pull request to the cm-kernel. 

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[Dan Christensen]

Thanks. In the meantime, is tar + reformat + untar a safe way to
proceed? I just got stuck on the boot screen and fixed that by
clearing /data/dalvik-cache, so I suspect further corruption of
that partition.

Thanks for any advice.

Dan

[Patrick Jacques]

Correct, tar or even nandroid or bart via recovery menu would back up (whats left) properly. 

I ended up merging all of Charles Manning's recent fixes earlier and it's working great:

http://github.com/kernelzilla/cm-kernel/commit/14d258c123156c9c6e5de138f4649edfa635b2ae

I've noticed faster bootup, lower load wait times, & no corruption so far, after filling /data up with random files & symlinks, (md5s match).  It's been merged into cyanogen's kernel too, so it should be in the next nightly builds.

Cheers

Dan

[Dan Christensen]

Patrick Jacques
<pat...@kinetic-computing.net> writes:

> Correct, tar or even nandroid or bart via recovery menu would back up
> (whats left) properly. 

I thought that nandroid and bart created an image of the partition, so
using them would preserve the corrupted filesystem. With tar I can
exclude the damaged directory, but what I don't know is whether it
preserves all attributes that files have on a yaffs2 filesystem.

> I ended up merging all of Charles Manning's recent fixes earlier and
> it's working great:
>
> http://github.com/kernelzilla/cm-kernel/commit/14d258c123156c9c6e5de138f4649edfa635b2ae
>
> I've noticed faster bootup, lower load wait times, & no corruption so
> far, after filling /data up with random files & symlinks, (md5s
> match).  It's been merged into cyanogen's kernel too, so it should be
> in the next nightly builds.

That's great to hear!

Dan

[Disconnect]

There is currently no way to get the flash metadata out of the flash partition, so what nandroid does is create a new fs image based on the mounted filesystem. (So no corruption beyond what is in the files themselves.)

Dunno bart, but I suspect it is the same if it runs in recovery mode.

Dan

[Dan Christensen]

Disconnect <dc.dis...@gmail.com>
writes:

> There is currently no way to get the flash metadata out of the flash
> partition, so what nandroid does is create a new fs image based on the
> mounted filesystem. (So no corruption beyond what is in the files
> themselves.)

Ah, I had assumed it was just "cat /dev/block/mtdblock5 > data.img" or
something like that. But looking at the nandroid script in the recovery
ram disk image, I see that it is actually constructing a fresh image
from the existing files.

However, I just tried this, using the nandroid script from the
recovery-RA-dream-v1.7.0R-cyan.img recovery image, and it appears that
the extra bad directory links *are* stored in the image: when I wiped
the /data partition and flashed it with "fastboot flash userdata data.img"
the corrupt link was still there.

On the other hand, if I restore the image using the nandroid script
from the recovery menu, it uses unyaffs to do the restore, and unyaffs
seems to skip over the corrupt link and all is fine.

I hope this will be helpful to others needing to repair a corrupt
yaffs partition. It would be much easier if there was something like
e2fsck that could repair things in place.

Dan