Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Swapped endian filesystem issues

What do other people usually do about issues like this?

truck# fsck_ffs -y /dev/rsd1a
** /dev/rsd1a
** Swapped byte order

CANNOT READ: BLK 59336270274363392

Segmentation fault (core dumped)

What's the issue you're talking about?  That the filesystem got
corrupted?  That fsck didn't repair it?  That fsck segfaulted?

The filesystem got corrupted and I was wondering what could be done about it. The options are:

1) try to mount without checking

2) connect it to a big endian system and try to fsck it there

3) dd | xz the whole disk and hope that some tool in the future can make sense of it

59336270274363392 is 0x00d2ce0600000000, which is the byteswap of
0000000006ced200, which is suspicious.  It's possible there's a missing
byteswap, probably in a little-used (and thus little-tested) code path
(perhaps even just in the CANNOT READ printout!).  It's also possible
the 59336270274363392 is real and constitues the corruption that led to
the panic you mention.

It'd be neat if I had a disk with 26,983 petabytes, but I don't. Not yet, at least.

With this little information, it's anyone's guess whether there are
more than two bugs involved or not.  (We know there are at least two,
one that caused the panic and one that crashed fsck_ffs; while it seems
likely filesystem corruption related to the first one is what tickled
the second one, that's actually just a guess at this point.)

I really need to get serial consoles on my Pis.

Sounds to me as though something corrupted the filesystem worse than
fsck knows how to handle, turning up a bug in fsck.  But, as I noted
above, that is just a guess so far.

That's pretty much it.

I'll try a little endian filesystem, but I'm curious about what
others might do in a case like this if the filesystem had files that
were needed.


First, I'd check the backup.  (If I don't have a backup, whatever was
on there obviously wasn't very important to begin with.)

Luckily, not much since I was just starting to play with aarch64eb.

If that fails (it's possible the corruption got copied to the backup
before the crash), I'd try mounting it read-only, probably from a
single-user boot, and seeing if the system could survive copying the
important file(s) off of it.  If not, I'd drag out my tar variant,
which has its own FFS code; it can sometimes extract file contents from
damaged filesystems, and, if it can't, at least it's just a userland
program, which can crash without taking down the whole system.

In case of desperation, I'd start picking apart the FFS data structures

Good to know, in case this ever happens with stuff that matters :)


Home | Main Index | Thread Index | Old Index