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.
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.
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.
The linux source indicates that extX is little- endian on disk
(news to me), so the backward value is less surprising now,
anyway. Vbackup behavior suggests it's not getting byte sex
for free when reading the superblock magic.
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?
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.
Basics: /dev/hda is a 237MB ext3 filesystem. /var/tmp is a filesystem
with at least 3G and up to 10G of freespace, varied between tests.
vac(1)/vacfs(4) store blocks in venti and read them out fine.
$PLAN9/src/libdiskfs/ext2.h:14 Changed 0xEF53 to 0x53EF.
Ran INSTALL to rebuild p9p in the most naive possible way.
[EMAIL PROTECTED]:/usr/local/plan9# vbackup -D -V -v /dev/hda3
vbackup -> Thello tag 0 vers 02 uid anonymous strength 0 crypto 0:
codec 0:
vbackup <- Rhello tag 0 sid anonymous rcrypto 0 rcodec 0
cache 50 blocks
read scores into /var/tmp/vbackup.SgleQ3...
vbackup: Bwrite: Success
The change gets vbackup a little father. vbackup fills any free space
with the unlinked /var/tmp/vbackup.XXXXXX file, then prints "Bwrite:
Success" and exits.
Under gdb, repeated the above command, effects are the same
except that, interestingly, Bwrite returns with "No space left on
device"
when the disk fills.
Strace() doesn't show anything glaring enough to jump out at
my amateur eyes yet; here it is as vbackup fills the disk and
goes away quietly:
/usr/local/plan9/bin/vbackup: Bwrite: Success
"", 19) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
waitpid(20120, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0) = 20120
exit_group(1) = ?
Process 20119 detached
I am pretty sure I don't need 30x the backed-up fs of temp space on
our x86 linux systems. So I don't think I'll get away with just the
simple
hand-made byte-swap in ext2.h, as behavior doesn't seem even
basically correct after the change.
Thanks for replying, Russ. Ideas on any "other fields" that might
want a fiddle, as you mentioned? I'm curious enough to dig and report,
since powerpc is a listed platform for p9p, but also vac works, and
working vbackup on a couple powerpcs isn't any level of critical.
--
Josh
