[Top] [All Lists]

Re: XFS architecture ?

To: Stefan Smietanowski <stefan@xxxxxxxxx>
Subject: Re: XFS architecture ?
From: Ken McDonell <kenmcd@xxxxxxxxxxxxxxxxx>
Date: Tue, 4 Apr 2000 07:45:23 +1000
Cc: Linux XFS mailinglist <linux-xfs@xxxxxxxxxxx>
In-reply-to: <38E8F90B.44E33FEE@hanse.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Mon, 3 Apr 2000, Stefan Smietanowski wrote:
> ...
> Linux had that before, with Big Endian machines having a Big Endian
> ext2, but that was dropped before 2.0.0 if I recall correctly, and now
> all linux machines use a little endian ext2 system. I can't remember the
> extra overhead needed to switch endianness though ...
> If it comes to using different formats based on the native endianness,
> will the IRIX XFS be extended also to support this feature?
> If it doesn't, that would mean that I cannot take my linux XFS partition
> and move it to the IRIX machine, which imho is one point with running a
> native XFS system on Linux.

Rest assured.  Our IRIX heritage and the very migration strategy you
describe mandate that XFS on Linux _will_ support the IRIX MIPS on-disk

The issue we still have to resolve (and this is the initial objective of the
endian work) is,

(a) will the XFS on-disk format be the IRIX MIPS format everywhere
    (the every XFS is big endian model), or
(b) will the Linux version of XFS support both a little endian on-disk
    format (what you see today with the released code on Intel
    platforms), _and_ the IRIX MIPS on-disk format

Note that most of the source code changes and effort go into moving
from the status today to (a).  If we end up with (b) this is a
relatively small additional development effort.

The way this work is being done, there may also be another option

(c) make the on-disk format the same as the in memory format ... this
    is the "convert nothing" model for those who care about nanocycles
    and don't care about media interoperability or clustered

<Prev in Thread] Current Thread [Next in Thread>