Re: [9fans] p9p vbackup fs type endiannes

Re: [9fans] p9p vbackup fs type endiannes

[Russ Cox]

>> 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

[9fans] p9p vbackup fs type endiannes

[Joshua Wood]

I'm trying to use p9p's vbackup(8) on a linux powerpc system.

	# vbackup -m /boot /dev/hda3
	vbackup: ffsopen: bad magic 0x53ef wanted 0xef53

Linux statfs(2) says 0xef53 is a linux ext2 partition type. There
is an ext3 partition at /dev/hda3, so vbackup (its call to fsysopen())
is expecting the right fs type, but seems to be getting the endian
obverse of that value.

(The kernel is debian's stock 2.6.18-5-powerpc. P9p is dated 11/08
from http://swtch.com/plan9port/.)

Anyone else attempting to doubly edify linux in this fashion
and seeing likewise?

--
Josh

Re: [9fans] p9p vbackup fs type endiannes

[Russ Cox]

> I'm trying to use p9p's vbackup(8) on a linux powerpc system.
> 
> 	# vbackup -m /boot /dev/hda3
> 	vbackup: ffsopen: bad magic 0x53ef wanted 0xef53
> 
> Linux statfs(2) says 0xef53 is a linux ext2 partition type. There
> is an ext3 partition at /dev/hda3, so vbackup (its call to fsysopen())
> is expecting the right fs type, but seems to be getting the endian
> obverse of that value.
> 
> (The kernel is debian's stock 2.6.18-5-powerpc. P9p is dated 11/08
> from http://swtch.com/plan9port/.)
> 
> Anyone else attempting to doubly edify linux in this fashion
> and seeing likewise?

I have never tried to run the ext2 reading code on a
little-endian machine.  I don't know what changes
and what doesn't.  I would have expected that everything
was in native byte order, so that the "load disk contents
into memory and interpret" strategy would have worked
just fine.  It's possible that the superblock magic code
is really two bytes and not a short, and that if you change
SUPERMAGIC in src/libdiskfs/ext2.h then everything else
will just work.  But it's also possible that you'll have to 
fiddle with other fields.  

Please let me know what you find out.

Thanks.
Russ