I've changed libdiskfs to read the data in little-endian order
no matter what the underlying architecture.
And it works for me in the previously-described situation. I can
vbackup(8), am returned an ext2:... score and a vnfs mount line as
is expected behavior. Vnfs works with that mount line, btw.
Haven't tried the raw vcat back out to the partition yet.
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.
I think the data is usually in host order, but it seems
popular to define metadata in one or the other order. So
on linux there is some proliferation; ext3, jfs are always
little-endian on disk; xfs is big (if I'm reading it right).
By the way, from (Plan9) fossil code and a comment in file.c:597
that I just found, it looks like fossil has a kind of magic number
similar
to this, and always stores it as a big-endian integer on disk, no matter
the arch. Am I misunderstanding this? (File.c implies it for venti, too,
but I haven't looked there yet.)
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.
Now I understand what you were saying, and thank you for spelling
it out. I found that a couple filesystems do take that approach; AIX
JFS,
for one, stores the magic number as a character string and not an
integer.
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.
... Because all the metadata is little-endian. I did eventually reach
that stage
of enlightenment, but that didn't imply the competence to fix it very
quickly.
The diff from the cvs up I just did from your source is awfully
instructive
versus how I had started groping toward a solution. Thanks for both
the code and the discussion, Russ.
--
Josh
