Received:  by oss.sgi.com id <S305176AbQDDACu>;
	Mon, 3 Apr 2000 17:02:50 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:59956 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305168AbQDDACm>; Mon, 3 Apr 2000 17:02:42 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id RAA00502
	for <linux-xfs@oss.sgi.com>; Mon, 3 Apr 2000 17:06:25 -0700 (PDT)
	mail_from (kenmcd@melbourne.sgi.com)
Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13140; Tue, 4 Apr 2000 10:01:23 +1000
Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id KAA04574; Tue, 4 Apr 2000 10:01:20 +1000 (EST)
Date:   Tue, 4 Apr 2000 10:01:20 +1000
From:   Ken McDonell <kenmcd@melbourne.sgi.com>
To:     Jim Mostek <mostek@sgi.com>
cc:     Stefan Smietanowski <stefan@hanse.com>,
        Linux XFS mailinglist <linux-xfs@oss.sgi.com>
Subject: Re: XFS architecture ?
In-Reply-To: <200004032306.SAA34634@fsgi344.americas.sgi.com>
Message-ID: <Pine.SGI.4.10.10004040955050.4328-100000@rattle.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, 3 Apr 2000, Jim Mostek wrote:
> 
> 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.

Let me strongly disagree.

OK, Jim and I are in a deadly disagree-disagree embrace now ... 8^)>

Well not really ... I said "small additional _development_ effort".

I should have stressed that beyond the development effort there is:

- code obfuscation and complexity (we need to change internal interfaces
  to push down the "architecture" from the mount structure into places
  it has not been needed before)
- run-time overhead
- testing complexity
- additional support and debugging pain
- log recovery (an unsolved problem)

Jim and I are in a deadly agree-agree embrace on the proposition that
big endian everywhere is the preferred position provided any
performance penalties are acceptably low.