Re: Swapped endian filesystem issues

[John Klos <john%ziaspace.com@localhost>]

> > 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
> > CONTINUE? yes
>
> > 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.
>
> Personally?
>
> 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
> myself.

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

Thanks,
John