>> I have never tried to run the ext2 reading code on a
>> little-endian machine.
>
> I assumed above was a typo and that we're talking about
> big-endian powerpc.
Yes, sorry.
> I would too -- doesn't the filesystem's inode lookup method
> usually (on Unix) do any endianness swap for inode numbers
> and metadata? I guess I'd expect that to apply for superblock
> metadata as well.
Actually I thought that the file systems just stored in the
host byte order on disk, so that powerpc ext2 would be different
from 386 ext2. But apparently that's not true and they're
all little-endian.
>> It's possible that the superblock magic code
>> is really two bytes and not a short,
>
> I didn't intend to imply the magic was two bytes; the linux source
> seems to make it an unsigned short, yes. I must not follow you here;
> isn't a short in this context also 16 bits/2 bytes, and always at least
> that long, so still subject to endianness?
What I meant was that if you define
struct Super {
uchar magic1;
uchar magic2;
};
vs
struct Super {
ushort magic;
}:
then in the first if you fill in the bytes magic1 = 0x53 and
magic2 = 0xEF, you are byte-order independent, but in the
second if you fill in magic = 0xEF53 then you're not.
If the magic was the only field on disk that ended up in the
wrong order, then I was suggesting that maybe it should
look like the former instead of the latter.
But it's all the fields that are screwed up. The disk filled up
because vbackup thought the file system was some ridiculous
size because something like 0x12345 blocks
becomes 0x45230100 blocks if you read it backward.
I've changed libdiskfs to read the data in little-endian order
no matter what the underlying architecture.
Try running
cd /usr/local/plan9/src/libdiskfs; cvs up
mk
cd ../cmd/vbackup
mk clean
mk all
mk install
mk clean
and then try again.
Russ
