xfs
[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
format.

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
    filesystems


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