[prev in list] [next in list] [prev in thread] [next in thread] 

List:       9fans
Subject:    Re: [9fans] p9p vbackup fs type endiannes
From:       Joshua Wood <josh () utopian ! net>
Date:       2007-11-27 18:09:05
Message-ID: 95590562-4E06-4DB5-A23D-35028C904313 () utopian ! net
[Download RAW message or body]

> 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
[prev in list] [next in list] [prev in thread] [next in thread]