On Sun, Jul 31, 2016 at 03:14:28PM -0400, Theodore Ts'o wrote:
>
> My suggestion at this point is to do an image copy of the entire
> contents of the sdhc card using either dd or ddrescue, to a known-good
> hard drive, and then run fsck.ext4 on that that image copy of your
> file system. I suspect the root cause of this is simple hardware
> failure of the sdhc card. So doing an image copy is a good idea
> before you do anything else, since it reduces the risk of (further)
> data loss.
First my apologies for the long silence: I was away from home.
I have done as you suggested. Taken an image of the sdhc card (on
another machine) and written that to a file (as it happens on an
usbstick). I then ran fsck.ext4 which claimed to correct a problem.
Next I loop-mounted that image. I also ran fsck.ext4 on the sdhc card
on the other machine) which similarly claimed to fix a problem and then
also mounted that.
I then tested using rsync as:
rsync -na /mnt/testing/ /sdhc/
^ ^
| |
loop mounted image faulty card
That is I asked rsync to do a dry run copy from the loop mounted image to the
card
so that it would read the image filesystem and not write to the card.
On a subset of files, I saw the warnings: Structure needs cleaning (117)
and /var/log/messages included
EXT4-fs error: 32 callbacks suppressed
Just to confirm, I used a simple cat of one of the problem files:-
# cat /mnt/testing/lost+found/#528000: Structure needs cleaning
So it seems that fsck.ext4 is unable to correct the problems even on the
image, although it claims to have done so.
It is possible that the original problem with the card was perhaps a
hardware fault (I have mentioned that it occasionally gets disturbed in
its slot), but whatever happened the current state of the file system
is confusing fsck.ext4. Or so it seems to me.
>
> At this point, unless you can replicate the problem after copying the
> file system image off the sdhc to something more reliable (and in
> particular, cheap sd cards in the checkout counter line of "The Micro
> Center", or deep discount cards purchased from a direct-from-a-no-name-
> Shenzhen manufacturer don't count as reliable), I very much doubt it
> is a software bug, but rather a hardware issue.
So yes, I can replicate the problem after copying: I am satisfied that
the usbstick is fine, but I can do similar tests using other disk
hardware if you remain suspicious.
Of course, I can just reformat the card, and I am confident that it will
then work, but this looks like an opportunity to uncover a "feature"
lurking somewhere. I imagine that you will ask for an dumpe2fs run next?
Thanks for the help so far.
