[Top] [All Lists]

Re: XFS architecture ?

To: kenmcd@xxxxxxxxxxxxxxxxx (Ken McDonell)
Subject: Re: XFS architecture ?
From: Jim Mostek <mostek@xxxxxxx>
Date: Mon, 3 Apr 2000 18:06:44 -0500 (CDT)
Cc: stefan@xxxxxxxxx (Stefan Smietanowski), linux-xfs@xxxxxxxxxxx (Linux XFS mailinglist)
In-reply-to: <Pine.SGI.4.10.10004040735500.3397-100000@rattle.melbourne.sgi.com> from "Ken McDonell" at Apr 04, 2000 07:45:23 AM
Sender: owner-linux-xfs@xxxxxxxxxxx
Let me strongly disagree with:

>If we end up with (b) this is a
>relatively small additional development effort.

The biggest part would come in all the support/testing/...  on the
different architecture combinations.  If the on-disk format and log format
are all fixed, it greatly simplifies things.

Longer term, with CXFS servers moving between architectures ...



>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
>    filesystems

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