From owner-linux-xfs@oss.sgi.com Sun Oct  1 03:53:26 2000
Received:  by oss.sgi.com id <S42426AbQJAKxG>;
	Sun, 1 Oct 2000 03:53:06 -0700
Received: from smtp5.xs4all.nl ([194.109.6.49]:22217 "EHLO smtp5.xs4all.nl")
	by oss.sgi.com with ESMTP id <S42232AbQJAKwp>;
	Sun, 1 Oct 2000 03:52:45 -0700
Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44])
	by smtp5.xs4all.nl (8.9.3/8.9.3) with ESMTP id MAA28249;
	Sun, 1 Oct 2000 12:52:43 +0200 (CEST)
Received: from localhost (knuffie@localhost)
	by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id MAA04373;
	Sun, 1 Oct 2000 12:52:43 +0200 (CEST)
Date:   Sun, 1 Oct 2000 12:52:43 +0200 (CEST)
From:   Seth Mos <knuffie@xs4all.nl>
To:     Thomas Graichen <graichen@innominate.de>,
        thomas.graichen@innominate.de
cc:     linux-xfs@oss.sgi.com
Subject: Re: RedHat 7.0 - unbootable
In-Reply-To: <news2mail-8r5vbh$p1v$4@mate.bln.innominate.de>
Message-ID: <Pine.BSI.4.10.10010011251390.4219-100000@xs3.xs4all.nl>
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 1 Oct 2000, Thomas Graichen wrote:

> i think a good idea would also be to compare clean 2.4.0-test5/8 and
> the xfs tree - maybe it is not really an xfs issuse and more an
> "redhat adds dozens of patches to its kernel" thing? - maybe
> the same problem also exists with clean 2.4.0 ... just an
> idea - maybe someone can try it out (have myself no 7.0
> set up so far to test it)
> 

Clean 240-test kernels boot without problems.
Steve also knows this, forgot to cc the list

> t
> 
> utz lehmann <xfs@s2y4n2c.de> wrote:
> > hello
> 
> > redhat 7.0 ist unbootable with my xfs kernel (old one, cvs from 2000-08-17,
> > compiled on redhat 6.2) with the same errors.
> > the redhat 7.0 installation is on a ext2 partition.
> 
> > i have bootet the original redhat 7.0 kernel (2.2.16-22) and the xfs kernel
> > (2.4.0-test5-xfs-20000817) with "init=/bin/bash" on lilo prompt. and done
> > following:
> 
> > mount -orw,remount /
> > strace -o ls.strace-`uname -r`
> 
> > i attached both strace outputs.
> 
> > i think the xfs kernel (all 2.4.0-test5 kernels?) returns the wrong error on
> > fstat64.
> 
> > original redhat 7.0 kernel:
> > [...]
> > open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4
> > fstat(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > fcntl64(4, F_SETFD, FD_CLOEXEC)         = -1 ENOSYS (Function not
> > implemented)
> > fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
> > brk(0x8059000)                          = 0x8059000
> > [...]
> 
> > xfs kernel:
> > [...]
> > open("/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4
> > fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > fcntl64(4, F_SETFD, FD_CLOEXEC)         = -1 EFAULT (Bad address)
> > close(4)                                = 0
> > write(2, "ls: ", 4)                     = 4
> > write(2, "/", 1)                        = 1
> > write(2, ": Bad address", 13)           = 13
> > write(2, "\n", 1)                       = 1
> > close(1)                                = 0
> > _exit(1)                                = ?
> 
> 
> 
> > hope that helps.
> 
> > utz lehmann
> 
> 
> -- 
> thomas.graichen@innominate.de
> technical director                                       innominate AG
> clustering & security                                networking people
> tel: +49.30.308806-13  fax: -77                   http://innominate.de
> 


From owner-linux-xfs@oss.sgi.com Sun Oct  1 03:58:36 2000
Received:  by oss.sgi.com id <S42427AbQJAK60>;
	Sun, 1 Oct 2000 03:58:26 -0700
Received: from smtp5.xs4all.nl ([194.109.6.49]:23755 "EHLO smtp5.xs4all.nl")
	by oss.sgi.com with ESMTP id <S42232AbQJAK6P>;
	Sun, 1 Oct 2000 03:58:15 -0700
Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44])
	by smtp5.xs4all.nl (8.9.3/8.9.3) with ESMTP id MAA29201;
	Sun, 1 Oct 2000 12:58:13 +0200 (CEST)
Received: from localhost (knuffie@localhost)
	by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id MAA04545;
	Sun, 1 Oct 2000 12:58:13 +0200 (CEST)
Date:   Sun, 1 Oct 2000 12:58:13 +0200 (CEST)
From:   Seth Mos <knuffie@xs4all.nl>
To:     utz lehmann <xfs@s2y4n2c.de>
cc:     Andi Kleen <ak@suse.de>,
        Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>,
        linux-xfs@oss.sgi.com
Subject: Re: RedHat 7.0 - unbootable
In-Reply-To: <20001001035544.A3641@s2y4n2c.de>
Message-ID: <Pine.BSI.4.10.10010011255410.4219-100000@xs3.xs4all.nl>
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 Sun, 1 Oct 2000, utz lehmann wrote:

> Andi Kleen [ak@suse.de] wrote:
> > 	.long SYMBOL_NAME(sys_ni_syscall)
> > 
> > for each attr line ? 
> > 
> > 
> > -Andi
> 
> yes, it work with my pre beta kernel from 2000-08-17.
> 
> and todays cvs kernel (2.4.0-test8 based) works too (without the change
> above).

Thomas can you put in the FAQ that for booting xfs kernels under redhat 7
you would need the cvs kernel (eg test8-xfs). ;-)

That should help people not to make their box unbootable after upgrading
from 6.2 to 7.

Bye Seth


From owner-linux-xfs@oss.sgi.com Sun Oct  1 04:49:16 2000
Received:  by oss.sgi.com id <S42428AbQJALtG>;
	Sun, 1 Oct 2000 04:49:06 -0700
Received: from Cantor.suse.de ([194.112.123.193]:8460 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42232AbQJALsc>;
	Sun, 1 Oct 2000 04:48:32 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 1ED7F1E27A; Sun,  1 Oct 2000 13:47:59 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id A726C3E450; Sun,  1 Oct 2000 13:47:55 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id DFA3B2F301; Sun,  1 Oct 2000 13:47:46 +0200 (MEST)
Date:   Sun, 1 Oct 2000 13:47:46 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Seth Mos <knuffie@xs4all.nl>
Cc:     utz lehmann <xfs@s2y4n2c.de>, Andi Kleen <ak@suse.de>,
        Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>,
        linux-xfs@oss.sgi.com
Subject: Re: RedHat 7.0 - unbootable
Message-ID: <20001001134746.A16566@gruyere.muc.suse.de>
References: <20001001035544.A3641@s2y4n2c.de> <Pine.BSI.4.10.10010011255410.4219-100000@xs3.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.BSI.4.10.10010011255410.4219-100000@xs3.xs4all.nl>; from knuffie@xs4all.nl on Sun, Oct 01, 2000 at 12:58:13PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sun, Oct 01, 2000 at 12:58:13PM +0200, Seth Mos wrote:
> On Sun, 1 Oct 2000, utz lehmann wrote:
> 
> > Andi Kleen [ak@suse.de] wrote:
> > > 	.long SYMBOL_NAME(sys_ni_syscall)
> > > 
> > > for each attr line ? 
> > > 
> > > 
> > > -Andi
> > 
> > yes, it work with my pre beta kernel from 2000-08-17.
> > 
> > and todays cvs kernel (2.4.0-test8 based) works too (without the change
> > above).
> 
> Thomas can you put in the FAQ that for booting xfs kernels under redhat 7
> you would need the cvs kernel (eg test8-xfs). ;-)

I guess it would be better to fix the beta: move the attr_* syscalls 
to the system call slots of test8-xfs (that is 2 slots moved) or even
better remove them until a stable interface is found [as far as I 
understand they're not very well tested yet anyways] 

-Andi

From owner-linux-xfs@oss.sgi.com Sun Oct  1 05:09:56 2000
Received:  by oss.sgi.com id <S42429AbQJAMJq>;
	Sun, 1 Oct 2000 05:09:46 -0700
Received: from pC19F0114.dip.t-dialin.net ([193.159.1.20]:10112 "EHLO
        kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP
	id <S42232AbQJAMJP>; Sun, 1 Oct 2000 05:09:15 -0700
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.9.3/8.9.3) id NAA01379;
	Sun, 1 Oct 2000 13:22:54 +0200
Date:   Sun, 1 Oct 2000 13:22:54 +0200
From:   utz lehmann <xfs@s2y4n2c.de>
To:     Andi Kleen <ak@suse.de>
Cc:     Seth Mos <knuffie@xs4all.nl>, utz lehmann <xfs@s2y4n2c.de>,
        Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>,
        linux-xfs@oss.sgi.com
Subject: Re: RedHat 7.0 - unbootable
Message-ID: <20001001132254.A1181@s2y4n2c.de>
References: <20001001035544.A3641@s2y4n2c.de> <Pine.BSI.4.10.10010011255410.4219-100000@xs3.xs4all.nl> <20001001134746.A16566@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20001001134746.A16566@gruyere.muc.suse.de>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Andi Kleen [ak@suse.de] wrote:
> > Thomas can you put in the FAQ that for booting xfs kernels under redhat 7
> > you would need the cvs kernel (eg test8-xfs). ;-)
> 
> I guess it would be better to fix the beta: move the attr_* syscalls 
> to the system call slots of test8-xfs (that is 2 slots moved) or even
> better remove them until a stable interface is found [as far as I 
> understand they're not very well tested yet anyways] 
> 
> -Andi

yes, fix the beta. perhaps with a config option to use the attr_* syscalls
or not.

utz

From owner-linux-xfs@oss.sgi.com Sun Oct  1 09:27:09 2000
Received:  by oss.sgi.com id <S42416AbQJAQ1A>;
	Sun, 1 Oct 2000 09:27:00 -0700
Received: from smtp5.xs4all.nl ([194.109.6.49]:60877 "EHLO smtp5.xs4all.nl")
	by oss.sgi.com with ESMTP id <S42232AbQJAQ0l>;
	Sun, 1 Oct 2000 09:26:41 -0700
Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44])
	by smtp5.xs4all.nl (8.9.3/8.9.3) with ESMTP id SAA05522;
	Sun, 1 Oct 2000 18:26:08 +0200 (CEST)
Received: from localhost (knuffie@localhost)
	by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id SAA15951;
	Sun, 1 Oct 2000 18:26:08 +0200 (CEST)
Date:   Sun, 1 Oct 2000 18:26:08 +0200 (CEST)
From:   Seth Mos <knuffie@xs4all.nl>
To:     linux-xfs@oss.sgi.com, ak@suse.de
Subject: Re: RedHat 7.0 - unbootable
In-Reply-To: <20001001134746.A16566@gruyere.muc.suse.de>
Message-ID: <Pine.BSI.4.10.10010011822360.15807-100000@xs3.xs4all.nl>
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 Sun, 1 Oct 2000, Andi Kleen wrote:

> On Sun, Oct 01, 2000 at 12:58:13PM +0200, Seth Mos wrote:
> > On Sun, 1 Oct 2000, utz lehmann wrote:
> > 
> > > Andi Kleen [ak@suse.de] wrote:
> > > > 	.long SYMBOL_NAME(sys_ni_syscall)
> > > > 
> > > > for each attr line ? 
> > > > 
> > > > 
> > > > -Andi
> > > 
> > > yes, it work with my pre beta kernel from 2000-08-17.
> > > 
> > > and todays cvs kernel (2.4.0-test8 based) works too (without the change
> > > above).
> > 
> > Thomas can you put in the FAQ that for booting xfs kernels under redhat 7
> > you would need the cvs kernel (eg test8-xfs). ;-)
> 
> I guess it would be better to fix the beta: move the attr_* syscalls 
> to the system call slots of test8-xfs (that is 2 slots moved) or even
> better remove them until a stable interface is found [as far as I 
> understand they're not very well tested yet anyways] 
> 
> -Andi

It would take some days (week) before they could ship a test8 beta. (??)

The solution you posted is probably the fastest way. But a mention of
it in the beta caveats page would be advisable :-)

Bye


From owner-linux-xfs@oss.sgi.com Sun Oct  1 10:08:21 2000
Received:  by oss.sgi.com id <S42414AbQJARIL>;
	Sun, 1 Oct 2000 10:08:11 -0700
Received: from mailout00.sul.t-online.com ([194.25.134.16]:4107 "EHLO
        mailout00.sul.t-online.com") by oss.sgi.com with ESMTP
	id <S42232AbQJARHw>; Sun, 1 Oct 2000 10:07:52 -0700
Received: from fwd03.sul.t-online.com 
	by mailout00.sul.t-online.com with smtp 
	id 13fmZz-0004bK-01; Sun, 01 Oct 2000 19:07:11 +0200
Received: from mailto.btx.dtag.de (320018173438-0001@[193.159.33.65]) by fwd03.sul.t-online.com
	with smtp id 13fmZi-16TS52C; Sun, 1 Oct 2000 19:06:54 +0200
Date:   Sun, 1 Oct 2000 19:07:08 +0200
From:   Familie.Cullmann@t-online.de (Cullmann Christoph)
To:     linux-xfs@oss.sgi.com
Subject: Re: Little Problem with XFS and Debian Woody
Message-ID: <20001001190708.A3037@babylon>
Reply-To: Christoph.Cullmann@gmx.de
References: <39D6A1B2.DBB2061@student.uni-kl.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
In-Reply-To: <39D6A1B2.DBB2061@student.uni-kl.de>; from sinoradz@student.uni-kl.de on Sun, Oct 01, 2000 at 04:30:10 +0200
X-Mailer: Balsa 0.8.1
X-Sender: 320018173438-0001@t-dialin.net
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On Sun, 01 Oct 2000 04:30:10 Ralf Sinoradzki wrote:
> Hi !
> Perhaps there are some DEBIAN users listening who could help me:
> 
> I've patched Kernel2.4.0-test5 with the XFS-beta-patch. After
> compiling with egcs 2.91.66 everything seemed to be OK.
> (gcc 2.95.2 did not work like it is mentioned in the FAQ)
> I'm using XFS on the /var,/usr,/home and /temp-partitions.
> When I install new packages with dselect, a lot of install-
> skripts fail ("cannot rmdir /var/lib/dpkg/tmp.ci"). There is
> a controlfile in it, that was not removed.
> If I remove it by hand, I can install the package but the next one stops
> with the same error. 
> xfs_check said, that everything was ok.
> Then I copied '/var/lib/dpkg' to an ext2fs-partition and mounted it with
> 'mount -t bind' in /var/lib/dpkg on the XFS-partition. Now everything
> works fine.
> I wonder, why the debian-skripts fail on an XFS-partition
> and work fine on ext2fs. I don't know, if there are bugs in the
> debian-package-system or if there is a bug in XFS.
> It's a bit strange, that the same file is removed on ext2fs-partitions
> and not on XFS-partitions.
> Nevertheless I'm very impressed by XFS.
> 
> Thanks, Ralf
> 
> P.S: My machine is an Athlon 800, 2 IDE-Drives, XFS compiled
> into the kernel.
> 

I have the same problem and this should show that
you have made no failure -> its a bug !
I hope anybody will write a bug. :-)


Thanks
Cullmann



From owner-linux-xfs@oss.sgi.com Sun Oct  1 10:14:51 2000
Received:  by oss.sgi.com id <S42417AbQJAROl>;
	Sun, 1 Oct 2000 10:14:41 -0700
Received: from Cantor.suse.de ([194.112.123.193]:36616 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42232AbQJAROa>;
	Sun, 1 Oct 2000 10:14:30 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 1442B1E28A; Sun,  1 Oct 2000 19:13:59 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 806F93E450; Sun,  1 Oct 2000 19:13:58 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 0E17D2F300; Sun,  1 Oct 2000 19:13:58 +0200 (MEST)
Date:   Sun, 1 Oct 2000 19:13:58 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Seth Mos <knuffie@xs4all.nl>
Cc:     linux-xfs@oss.sgi.com, ak@suse.de
Subject: Re: RedHat 7.0 - unbootable
Message-ID: <20001001191358.B21682@gruyere.muc.suse.de>
References: <20001001134746.A16566@gruyere.muc.suse.de> <Pine.BSI.4.10.10010011822360.15807-100000@xs3.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.BSI.4.10.10010011822360.15807-100000@xs3.xs4all.nl>; from knuffie@xs4all.nl on Sun, Oct 01, 2000 at 06:26:08PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sun, Oct 01, 2000 at 06:26:08PM +0200, Seth Mos wrote:
> On Sun, 1 Oct 2000, Andi Kleen wrote:
> 
> > On Sun, Oct 01, 2000 at 12:58:13PM +0200, Seth Mos wrote:
> > > On Sun, 1 Oct 2000, utz lehmann wrote:
> > > 
> > > > Andi Kleen [ak@suse.de] wrote:
> > > > > 	.long SYMBOL_NAME(sys_ni_syscall)
> > > > > 
> > > > > for each attr line ? 
> > > > > 
> > > > > 
> > > > > -Andi
> > > > 
> > > > yes, it work with my pre beta kernel from 2000-08-17.
> > > > 
> > > > and todays cvs kernel (2.4.0-test8 based) works too (without the change
> > > > above).
> > > 
> > > Thomas can you put in the FAQ that for booting xfs kernels under redhat 7
> > > you would need the cvs kernel (eg test8-xfs). ;-)
> > 
> > I guess it would be better to fix the beta: move the attr_* syscalls 
> > to the system call slots of test8-xfs (that is 2 slots moved) or even
> > better remove them until a stable interface is found [as far as I 
> > understand they're not very well tested yet anyways] 
> > 
> > -Andi
> 
> It would take some days (week) before they could ship a test8 beta. (??)

You don't need a test8 beta, just remove the bogus system calls or at least
move them to their test8 positions (2 up). It would probably be better to remove
them, because with the next system call added by Linus the same problem
will occur. 

-Andi

From owner-linux-xfs@oss.sgi.com Sun Oct  1 10:47:11 2000
Received:  by oss.sgi.com id <S42420AbQJARrB>;
	Sun, 1 Oct 2000 10:47:01 -0700
Received: from p3EE05276.dip.t-dialin.net ([62.224.82.118]:23939 "EHLO
        kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP
	id <S42232AbQJARqX>; Sun, 1 Oct 2000 10:46:23 -0700
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.9.3/8.9.3) id SAA05395;
	Sun, 1 Oct 2000 18:59:59 +0200
Date:   Sun, 1 Oct 2000 18:59:59 +0200
From:   utz@s2y4n2c.de
To:     Andi Kleen <ak@suse.de>
Cc:     Seth Mos <knuffie@xs4all.nl>, linux-xfs@oss.sgi.com
Subject: Re: RedHat 7.0 - unbootable
Message-ID: <20001001185959.A5235@s2y4n2c.de>
References: <20001001134746.A16566@gruyere.muc.suse.de> <Pine.BSI.4.10.10010011822360.15807-100000@xs3.xs4all.nl> <20001001191358.B21682@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20001001191358.B21682@gruyere.muc.suse.de>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Andi Kleen [ak@suse.de] wrote:
> > > I guess it would be better to fix the beta: move the attr_* syscalls 
> > > to the system call slots of test8-xfs (that is 2 slots moved) or even
> > > better remove them until a stable interface is found [as far as I 
> > > understand they're not very well tested yet anyways] 
> > > 
> > > -Andi
> > 
> > It would take some days (week) before they could ship a test8 beta. (??)
> 
> You don't need a test8 beta, just remove the bogus system calls or at least
> move them to their test8 positions (2 up). It would probably be better to remove
> them, because with the next system call added by Linus the same problem
> will occur. 
> 
> -Andi

i prefered a compile time option to use these system calls. as long as they
are not offical syscalls, it's an alpha feature. with every new offical
syscall you have to compile your userland tools again.
i doubt there is any linux application that use it. (i dont know any irix
application that use the extented attributes too.)

utz

From owner-linux-xfs@oss.sgi.com Sun Oct  1 19:47:25 2000
Received:  by oss.sgi.com id <S42431AbQJBCrG>;
	Sun, 1 Oct 2000 19:47:06 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:13693 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42232AbQJBCqf>;
	Sun, 1 Oct 2000 19:46:35 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA25653; Sun, 1 Oct 2000 19:38:00 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA23139;
	Sun, 1 Oct 2000 19:45:41 -0700 (PDT)
Date:   Sun, 1 Oct 2000 19:45:41 -0700 (PDT)
Message-Id: <200010020245.TAA23139@info.engr.sgi.com>
X-Pv-Incident: 797165 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: ADD 797165 - rationalise uuid kernel code for XFS
To:     btg@sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797165

 Status : open                         Priority : 4                         
 Assigned Engineer : btg               Submitter : nathans                  
*Modified User : dxm                  *Modified User Domain : engr          
*Description :
stick this in a bug so it isn't forgotten...

On Jul 21,  8:40am, Nathan Scott wrote:
> Subject: Re: LVM vs. kiobuf I/O
> > >         - Kernel uuid generation support
> > ...
> ...
> 
> I think there's a bunch of stuff which can be rationalised
> there too...

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: dxm@engr (BugWorks)
Date: Oct 01 2000 07:45:40PM
==========================

This idea has come up before, but I'm raising it again so
we can hopefully get a resolution.

We figure that having the kernel change the uuid of a FS on
mount is a bad idea. The implementation of that at the moment
is at least a little bit broken.

I've added a command to xfs_db which lets the user change
the uuid of a FS from userland, so I'd like to drop the
kernel equivalent.

Note we still need the uuidtab stuff so we can check for
duplicate mounts, but instead of forcing a new uuid, we'd
just fail to mount a duplicate FS.

Any objections to this idea?

From owner-linux-xfs@oss.sgi.com Sun Oct  1 19:47:36 2000
Received:  by oss.sgi.com id <S42432AbQJBCr1>;
	Sun, 1 Oct 2000 19:47:27 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40257 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42232AbQJBCrI>; Sun, 1 Oct 2000 19:47:08 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA04046; Sun, 1 Oct 2000 19:53:24 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA21054;
	Sun, 1 Oct 2000 19:46:22 -0700 (PDT)
Date:   Sun, 1 Oct 2000 19:46:22 -0700 (PDT)
Message-Id: <200010020246.TAA21054@info.engr.sgi.com>
X-Pv-Incident: 797165 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: REASSIGN 797165 - rationalise uuid kernel code for XFS
To:     dxm@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797165

 Status : open                         Priority : 4                         
*Assigned Engineer : dxm              *Assigned Domain : engr               
 Submitter : nathans                   Project : xfs-linux                  
 Assigned Group : xfs-linux            Opened Date : 07/24/00               
*Modified User : dxm                  *Modified User Domain : engr          
*Description :
stick this in a bug so it isn't forgotten...

On Jul 21,  8:40am, Nathan Scott wrote:
> Subject: Re: LVM vs. kiobuf I/O
> > >         - Kernel uuid generation support
> > ...
> ...
> 
> I think there's a bunch of stuff which can be rationalised
> there too...

.....


==========================
ADDITIONAL INFORMATION (REASSIGN)
From: dxm@engr (BugWorks)
Date: Oct 01 2000 07:46:22PM
==========================

From owner-linux-xfs@oss.sgi.com Sun Oct  1 22:44:46 2000
Received:  by oss.sgi.com id <S42258AbQJBFog>;
	Sun, 1 Oct 2000 22:44:36 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35141 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42232AbQJBFoD>; Sun, 1 Oct 2000 22:44:03 -0700
Received: from bruce.melbourne.sgi.com (root@bruce.melbourne.sgi.com [134.14.55.176]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA09113
	for <linux-xfs@oss.sgi.com>; Sun, 1 Oct 2000 22:50:06 -0700 (PDT)
	mail_from (fsgqa@bruce.melbourne.sgi.com)
Received: (from fsgqa@localhost)
	by bruce.melbourne.sgi.com (8.9.3/8.9.3) id QAA01311
	for linux-xfs@oss.sgi.com; Mon, 2 Oct 2000 16:43:54 +1100
Date:   Mon, 2 Oct 2000 16:43:54 +1100
From:   FSG QA <fsgqa@bruce.melbourne.sgi.com>
Message-Id: <200010020543.QAA01311@bruce.melbourne.sgi.com>
Subject: TAKE - test8 scsi duplicates devices
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

fix problem in test8 where non-modular scsi detects
devices twice. A full fix for this should be in test9.

I haven't fixed st.c yet.

Date:  Sun Oct  1 22:39:55 PDT 2000
Workarea:  bruce.melbourne.sgi.com:/home/fsgqa/qa-normal/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:75426a
linux/drivers/scsi/sd.c - 1.29
linux/drivers/scsi/hosts.c - 1.20
	- patch to fix problem in test8 where non-modular scsi duplicates
	  detected devices



From owner-linux-xfs@oss.sgi.com Sun Oct  1 23:40:16 2000
Received:  by oss.sgi.com id <S42317AbQJBGkG>;
	Sun, 1 Oct 2000 23:40:06 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:41750 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42232AbQJBGjf>;
	Sun, 1 Oct 2000 23:39:35 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA07661; Sun, 1 Oct 2000 23:31:07 -0700 (PDT)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA08310; Mon, 2 Oct 2000 17:36:14 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     kdb@oss.sgi.com, linux-xfs@oss.sgi.com,
        linux-kernel@vger.kernel.org,
        Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Subject: [Announce] kdb v1.5 is available 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 02 Oct 2000 17:36:11 +1100
Message-ID: <6414.970468571@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

http://oss.sgi.com/projects/kdb/download/ix86/ contains a patch for kdb
v1.5 against 2.4.0-test9-pre8.

Changes from kdb v1.5-beta2.

* Upgrade to 2.4.0-test9-pre8.

* Fix premature NMI oops on machines with large numbers of cpus.

This version of kdb also includes :-

* NMI oopser for uniprocessors.  This builds on Keir Fraser's excellent
  patch for activating the local APIC on P6 systems and (ab)uses the
  local APIC to generate NMI on systems which have a local APIC but no
  IO-APIC, typically any P6 and above uniprocessor.  So you poor
  developers with uniprocessors can now get diagnostics when the system
  gets into a spin loop.

  On the Processor configuration menu, select 'APIC and IO-APIC support
  on uniprocessors'.  That option will detect the local APIC if it
  exists.  See the help for 'NMI watchdog active for uniprocessors' and
  Documentation/nmi_watchdog.txt.

Expect the configuration method and the use of /proc/sys/kernel/nmi_watchdog
to change in future.  Ingo Molnar and I are discussing how much of the
NMI oopser for uniprocessors should go into the standard kernel.


From owner-linux-xfs@oss.sgi.com Sun Oct  1 23:42:35 2000
Received:  by oss.sgi.com id <S42433AbQJBGm0>;
	Sun, 1 Oct 2000 23:42:26 -0700
Received: from edge.coltex.nl ([194.151.97.115]:16646 "EHLO lsinet.coltex.nl")
	by oss.sgi.com with ESMTP id <S42232AbQJBGmB>;
	Sun, 1 Oct 2000 23:42:01 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by lsinet.coltex.nl (8.10.0/8.9.3) with ESMTP id e926f8E29492
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 08:41:08 +0200
Message-Id: <4.3.2.7.2.20001002083508.00b31e80@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Mon, 02 Oct 2000 08:40:42 +0200
To:     linux-xfs@oss.sgi.com
From:   Seth Mos <knuffie@xs4all.nl>
Subject: Mounting multiple partitions under one 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Why is it possible to mount two partitions under the same dir? (/test)

[root@stimpy /]# mkdir test
[root@stimpy /]# mkdir crash
[root@stimpy /]# mount -t xfs /dev/hda7 test
[root@stimpy /]# mount -t xfs /dev/hda8 test
[root@stimpy /]# mount
/dev/hda5 on / type ext2 (rw)
none on /proc type proc (rw)
/dev/hda1 on /boot type ext2 (rw)
/dev/hda6 on /tmp type ext2 (rw)
/dev/hda9 on /var type xfs (rw)
/dev/hda10 on /usr type ext2 (rw)
/dev/hda11 on /data type xfs (rw)
/dev/hda12 on /home type xfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda7 on /test type xfs (rw)
/dev/hda8 on /test type xfs (rw)
[root@stimpy /]#


[root@stimpy /]# uname -a
Linux stimpy.multiweb.nl 2.4.0-test5 #11 Wed Sep 27 18:29:24 CEST 2000 i686 
unknown
[root@stimpy /]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda5             486M   78M  383M  17% /
/dev/hda1              30M   19M   10M  65% /boot
/dev/hda6             486M   57k  461M   0% /tmp
/dev/hda9             999M  176M  823M  18% /var
/dev/hda10            2.9G  1.6G  1.1G  59% /usr
/dev/hda11             29G   10G   19G  35% /data
/dev/hda12             19G  6.6G   12G  35% /home
/dev/hda7             1.9G  144k  1.9G   0% /test
/dev/hda8             1.9G  144k  1.9G   0% /test
[root@stimpy /]#

This a shiny new 60GB IBM deskstar IDE drive :P
I just had to have one.

Bye
--
Seth
"Have you gone mad?"
"Well, yes, but that's beyond the scope of this email."


From owner-linux-xfs@oss.sgi.com Sun Oct  1 23:58:46 2000
Received:  by oss.sgi.com id <S42285AbQJBG6g>;
	Sun, 1 Oct 2000 23:58:36 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:26439 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42232AbQJBG6E>; Sun, 1 Oct 2000 23:58:04 -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 AAA00331
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 00:04:22 -0700 (PDT)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA08386; Mon, 2 Oct 2000 17:55:59 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Seth Mos <knuffie@xs4all.nl>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Mounting multiple partitions under one 
In-reply-to: Your message of "Mon, 02 Oct 2000 08:40:42 +0200."
             <4.3.2.7.2.20001002083508.00b31e80@pop.xs4all.nl> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 02 Oct 2000 17:55:56 +1100
Message-ID: <6753.970469756@kao2.melbourne.sgi.com>
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, 02 Oct 2000 08:40:42 +0200, 
Seth Mos <knuffie@xs4all.nl> wrote:
>Why is it possible to mount two partitions under the same dir? (/test)

Feature added in recent 2.4 kernels.  It obviously makes sense to the
fs developers, ask them or search the linux-kernel archives.


From owner-linux-xfs@oss.sgi.com Mon Oct  2 08:10:30 2000
Received:  by oss.sgi.com id <S42319AbQJBPKU>;
	Mon, 2 Oct 2000 08:10:20 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:39004 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42232AbQJBPKF>;
	Mon, 2 Oct 2000 08:10:05 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA13470
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 08:01:40 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA6731413; Mon, 2 Oct 2000 10:08:06 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id KAA81819; Mon, 2 Oct 2000 10:08:06 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id KAA10030;
	Mon, 2 Oct 2000 10:02:49 -0500
Message-Id: <200010021502.KAA10030@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     utz@s2y4n2c.de
cc:     Andi Kleen <ak@suse.de>, Seth Mos <knuffie@xs4all.nl>,
        linux-xfs@oss.sgi.com
Subject: Re: RedHat 7.0 - unbootable 
In-Reply-To: Message from utz@s2y4n2c.de 
   of "Sun, 01 Oct 2000 18:59:59 +0200." <20001001185959.A5235@s2y4n2c.de> 
Date:   Mon, 02 Oct 2000 10:02:49 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



So the summary seems to be that the library shipped with Redhat 7.0 uses
system calls not introduced until after 2.4.0-test5, but obviously copes
with them not being there - just not with something else being there instead.
Andi is correct in his statement that adding arbitary system calls is not a
good idea.

We are working on the best way to move forwards on this one, there are
difference consequences to all the different solutions, while there are
no external user's of extended attributes yet, we do have internal ones
in the works (DMAPI), so I really don't want to just remove the calls.

Thanks for everyone who dug into this over the weekend, hopefully we can get
the beta images respun soon. In the meantime it does appear that the cvs tree
works, provided you change the kernel compiler to kgcc.

By the way, if you want to use pcmcia on Redhat 7 with XFS please install all
the Redhat 2.4 kernel images first and then boot an XFS kernel, it died an
ugly death on me before I did this.


Steve


From owner-linux-xfs@oss.sgi.com Mon Oct  2 08:27:41 2000
Received:  by oss.sgi.com id <S42443AbQJBP1b>;
	Mon, 2 Oct 2000 08:27:31 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:48226 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42232AbQJBP1E>; Mon, 2 Oct 2000 08:27:04 -0700
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA00461; Mon, 2 Oct 2000 08:33:23 -0700 (PDT)
	mail_from (pv@feature.engr.sgi.com)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id IAA96134; Mon, 2 Oct 2000 08:25:04 -0700 (PDT)
Date:   Mon, 2 Oct 2000 08:25:04 -0700 (PDT)
Message-Id: <200010021525.IAA96134@feature.engr.sgi.com>
X-Pv-Incident: 797165 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (lord@sgi.com)
Subject: ADD 797165 - rationalise uuid kernel code for XFS
To:     dxm@cthulhu.engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

 Submitter : nathans                   Status : open                        
 Assigned Engineer : dxm               Priority : 4                         
*Modified Date : 10/02/00             *Modified User : lord                 
*Modified User Domain : sgi.com       *Description :
stick this in a bug so it isn't forgotten...

On Jul 21,  8:40am, Nathan Scott wrote:
> Subject: Re: LVM vs. kiobuf I/O
> > >         - Kernel uuid generation support
> > ...
> ...
> 
> I think there's a bunch of stuff which can be rationalised
> there too...

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: lord@sgi.com
Date: Oct 02 2000 08:25:03AM
[pvnews version: 1.71]
==========================

> ==========================
> ADDITIONAL INFORMATION (ADD)
> From: dxm@engr (BugWorks)
> Date: Oct 01 2000 07:45:40PM
> ==========================
> 
> This idea has come up before, but I'm raising it again so
> we can hopefully get a resolution.
> 
> We figure that having the kernel change the uuid of a FS on
> mount is a bad idea. The implementation of that at the moment
> is at least a little bit broken.
> 
> I've added a command to xfs_db which lets the user change
> the uuid of a FS from userland, so I'd like to drop the
> kernel equivalent.
> 
> Note we still need the uuidtab stuff so we can check for
> duplicate mounts, but instead of forcing a new uuid, we'd
> just fail to mount a duplicate FS.
> 
> Any objections to this idea?

This does seem like a reasonable thing to do, the one thing to be
aware of is the way SGI internally uses plexed filesystems to
create new ptools clones: Split a leg off a mirror and remount it
somewhere else as a new filesystem. I think Glen added some code
to the irix xfs_db commands to change the uuid as well - is your's
the same code?

Using the above scenario, the current approach will mount the filesystem
without any extra work, using the proposed change the mount would fail.
However, there were other issues with the plex splitting which led Glen
down the same path.

From owner-linux-xfs@oss.sgi.com Mon Oct  2 08:43:51 2000
Received:  by oss.sgi.com id <S42413AbQJBPnl>;
	Mon, 2 Oct 2000 08:43:41 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:48484 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42232AbQJBPnQ>; Mon, 2 Oct 2000 08:43:16 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA05609
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 08:49:34 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA6857179; Mon, 2 Oct 2000 10:41:16 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id KAA88628; Mon, 2 Oct 2000 10:41:15 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id KAA10327;
	Mon, 2 Oct 2000 10:35:59 -0500
Message-Id: <200010021535.KAA10327@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Ralf Sinoradzki <sinoradz@student.uni-kl.de>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Little Problem with XFS and Debian Woody 
In-Reply-To: Message from Ralf Sinoradzki <sinoradz@student.uni-kl.de> 
   of "Sun, 01 Oct 2000 02:30:10 -0000." <39D6A1B2.DBB2061@student.uni-kl.de> 
Date:   Mon, 02 Oct 2000 10:35:59 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Unfortunately we are somewhat debian challenged around here, i.e. we do not
have any debian boxes. Would it be possible to run strace with the /var/lib/dpkg
directory mounted on XFS and then on ext2. Since you say this is a script based
thing this may not be that straightforward, especially if vfork is
involved, strace does not follow that too well. You could try this.

strace -v -f -o /tmp/XXX failing command

>From your description it looks like we have broken operation in there
somewhere, but which one is going to be difficult to track down without
more info.

Thanks,

Steve

> Hi !
> Perhaps there are some DEBIAN users listening who could help me:
> 
> I've patched Kernel2.4.0-test5 with the XFS-beta-patch. After
> compiling with egcs 2.91.66 everything seemed to be OK.
> (gcc 2.95.2 did not work like it is mentioned in the FAQ)
> I'm using XFS on the /var,/usr,/home and /temp-partitions.
> When I install new packages with dselect, a lot of install-
> skripts fail ("cannot rmdir /var/lib/dpkg/tmp.ci"). There is
> a controlfile in it, that was not removed.
> If I remove it by hand, I can install the package but the next one stops
> with the same error. 
> xfs_check said, that everything was ok.
> Then I copied '/var/lib/dpkg' to an ext2fs-partition and mounted it with
> 'mount -t bind' in /var/lib/dpkg on the XFS-partition. Now everything
> works fine.
> I wonder, why the debian-skripts fail on an XFS-partition
> and work fine on ext2fs. I don't know, if there are bugs in the
> debian-package-system or if there is a bug in XFS.
> It's a bit strange, that the same file is removed on ext2fs-partitions
> and not on XFS-partitions.
> Nevertheless I'm very impressed by XFS.
> 
> Thanks, Ralf
> 
> P.S: My machine is an Athlon 800, 2 IDE-Drives, XFS compiled
> into the kernel.


From owner-linux-xfs@oss.sgi.com Mon Oct  2 11:38:01 2000
Received:  by oss.sgi.com id <S42446AbQJBShv>;
	Mon, 2 Oct 2000 11:37:51 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:1564 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42440AbQJBShc>;
	Mon, 2 Oct 2000 11:37:32 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA13307
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 11:29:07 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA6604101 for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 13:35:35 -0500 (CDT)
Received: from localhost.localdomain (root@eagdhcp-184-4.americas.sgi.com [128.162.184.194]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id NAA17762 for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 13:35:35 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: by localhost.localdomain (8.11.0/SGI-client-1.6c) id e92IiMc04443; Mon, 2 Oct 2000 13:44:22 -0500
Message-Id: <200010021844.e92IiMc04443@localhost.localdomain>
Date:   Mon, 2 Oct 2000 13:44:22 -0500
Subject: TAKE - fix filldir calls in test8
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This should fix some problems with removing directories, if glibc
is using getdents64 to read a directory we were failing to fill
in the filetype at all. This resulted in user space assuming that
a directory was not a directory and using unlink on it.

Date:  Mon Oct  2 11:29:06 PDT 2000
Workarea:  eagdhcp-184-4.americas.sgi.com:/usr/src/lord/2.4.0-test8

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:75464a
linux/fs/xfs/xfs_dir_leaf.c - 1.92
	- Pass DT_UNKNOWN into filldir during getdents calls

linux/fs/xfs/xfs_dir2.c - 1.24
	- Pass DT_UNKNOWN into filldir during getdents calls

linux/fs/xfs/linux/xfs_move.h - 1.2
	- extend interface for uio_copy since filldir changed



From owner-linux-xfs@oss.sgi.com Mon Oct  2 11:46:32 2000
Received:  by oss.sgi.com id <S42450AbQJBSqV>;
	Mon, 2 Oct 2000 11:46:21 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:27769 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42440AbQJBSqJ>; Mon, 2 Oct 2000 11:46:09 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA08707
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 11:52:28 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA6882831; Mon, 2 Oct 2000 13:44:11 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id NAA16928; Mon, 2 Oct 2000 13:44:10 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id NAA12073;
	Mon, 2 Oct 2000 13:38:53 -0500
Message-Id: <200010021838.NAA12073@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Ralf Sinoradzki <sinoradz@student.uni-kl.de>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Little Problem with XFS and Debian Woody 
In-Reply-To: Message from Ralf Sinoradzki <sinoradz@student.uni-kl.de> 
   of "Sun, 01 Oct 2000 02:30:10 -0000." <39D6A1B2.DBB2061@student.uni-kl.de> 
Date:   Mon, 02 Oct 2000 13:38:52 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> Hi !
> Perhaps there are some DEBIAN users listening who could help me:
> 

Can someone with a debian system try the latest cvs code, I have fixed
a problem with the getdents64 implementation. If the debian glibc uses
getdents64 this would probably explain the issue with failing to remove
directories during package installation.

Steve


From owner-linux-xfs@oss.sgi.com Mon Oct  2 11:59:02 2000
Received:  by oss.sgi.com id <S42448AbQJBS6w>;
	Mon, 2 Oct 2000 11:58:52 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:18210 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42440AbQJBS6e>;
	Mon, 2 Oct 2000 11:58:34 -0700
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA16337; Mon, 2 Oct 2000 11:50:10 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA63005; Mon, 2 Oct 2000 11:57:23 -0700 (PDT)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA26671;
	Mon, 2 Oct 2000 11:56:05 -0700 (PDT)
Date:   Mon, 2 Oct 2000 11:56:05 -0700 (PDT)
Message-Id: <200010021856.LAA26671@info.engr.sgi.com>
X-Pv-Incident: 797165 
webPV:  jen.americas.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (lord@sgi.com)
Subject: ADD 797165 - rationalise uuid kernel code for XFS
To:     dxm@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797165

 Status : open                         Priority : 4                         
 Assigned Engineer : dxm               Submitter : nathans                  
*Modified User : lord                 *Modified User Domain : sgi.com       
*Description :
stick this in a bug so it isn't forgotten...

On Jul 21,  8:40am, Nathan Scott wrote:
> Subject: Re: LVM vs. kiobuf I/O
> > >         - Kernel uuid generation support
> > ...
> ...
> 
> I think there's a bunch of stuff which can be rationalised
> there too...

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: lord@sgi.com (BugWorks)
Date: Oct 02 2000 11:56:05AM
==========================

I was wrong last time. Glen added code to print uuid code from
xfs_db, not change it.

So we have two conflicing tasks here:

1. turning an existing filesystem into two distinct filesystems.
   because of how they are created - they would be different
   devices, but have the same uuid.

2. prevent mounts of the same device when it has multiple paths

I think we can make one work automatically and the other require
some operator intervention.

From owner-linux-xfs@oss.sgi.com Mon Oct  2 13:09:32 2000
Received:  by oss.sgi.com id <S42434AbQJBUJW>;
	Mon, 2 Oct 2000 13:09:22 -0700
Received: from edge.coltex.nl ([194.151.97.115]:39439 "EHLO lsinet.coltex.nl")
	by oss.sgi.com with ESMTP id <S42449AbQJBUI4>;
	Mon, 2 Oct 2000 13:08:56 -0700
Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177])
	by lsinet.coltex.nl (8.10.0/8.9.3) with ESMTP id e92K8CE31617
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 22:08:13 +0200
Message-Id: <4.3.2.7.2.20001002214412.02537238@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Mon, 02 Oct 2000 22:07:45 +0200
To:     linux-xfs@oss.sgi.com
From:   Seth Mos <knuffie@xs4all.nl>
Subject: crash
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

Not to much info I could resolve here, just a vague description.
I almost migrated my home system over safely to xfs but got bitten by ext2 
this night trying to turn on DMA for the IDE drive.

Some programs started to oops and in the end I got an IO error from XFS (it 
was trying to run a cron job so it hit /var).
XFS did not like what was happening so I got a IO error.

I can't remember the exact error because something fell over on my box to 
make it reboot instantly after that.
ugh. Crud there went /usr (which was ext2).
I now have reformatted /usr with xfs. (lucky me had the old disks)

Is it supposed to reboot on a IO error?

btw test8 broke my scsi in a weird way. cdrecord now claims I don't have 
scsi bus anymore. Building the sym53c8xx as a module and loading it results 
in a loop of detecting my cdrom drive. I never knew I could hook up 999999> 
CD Roms ;-).
Oh well building it in the kernel solves that.

This a standard redhat 6.2 box (stimpy.multiweb.nl) the box at work is a 
redhat 7.0 box. Migration of the redhat 7.0 machine will start tommorow.

This all from just latest CVS i checked out.

Bye
Results to follow shortly.
--
Seth
"Have you gone mad?"
"Well, yes, but that's beyond the scope of this email."


From owner-linux-xfs@oss.sgi.com Mon Oct  2 13:41:33 2000
Received:  by oss.sgi.com id <S42458AbQJBUlX>;
	Mon, 2 Oct 2000 13:41:23 -0700
Received: from edge.coltex.nl ([194.151.97.115]:42511 "EHLO lsinet.coltex.nl")
	by oss.sgi.com with ESMTP id <S42449AbQJBUlC>;
	Mon, 2 Oct 2000 13:41:02 -0700
Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177])
	by lsinet.coltex.nl (8.10.0/8.9.3) with ESMTP id e92KeFE31640
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 22:40:15 +0200
Message-Id: <4.3.2.7.2.20001002223211.025a76f0@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Mon, 02 Oct 2000 22:39:48 +0200
To:     linux-xfs@oss.sgi.com
From:   Seth Mos <knuffie@xs4all.nl>
Subject: crash - extra info
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

just read up on my linux-kernel mail.

The scsi problem I have is a known issue is test8 because they seem to be 
busy reworking scsi
<snippet>

The scsi routines had an overhaul that wasn't completely fixed in test8.

</snippet>

The IDE code is also broken in test8 with regard to bus mastering DMA.... 
shame shame shame.
I got a $600 drive and its slower then my old maxtor ;-(

They fixed some of those issues in test9-pre7.
The only problems you get VM deadlocks for it in return.

Bye


--
Seth
"Have you gone mad?"
"Well, yes, but that's beyond the scope of this email."


From owner-linux-xfs@oss.sgi.com Mon Oct  2 14:46:13 2000
Received:  by oss.sgi.com id <S42449AbQJBVqD>;
	Mon, 2 Oct 2000 14:46:03 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:64079 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42261AbQJBVpW>;
	Mon, 2 Oct 2000 14:45:22 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA09948
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 14:36:57 -0700 (PDT)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id QAA6939326 for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 16:43:25 -0500 (CDT)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id QAA70251 for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 16:43:25 -0500 (CDT)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.10.1/8.10.1) id e92LhPH00355
	for linux-xfs@oss.sgi.com; Mon, 2 Oct 2000 16:43:25 -0500
Date:   Mon, 2 Oct 2000 16:43:25 -0500
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200010022143.e92LhPH00355@gibble.americas.sgi.com>
Subject: TAKE - add kgcc line for RH 7.0 
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Mon Oct  2 14:42:35 PDT 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-devel

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

Also changed extraversion to XFS-test8 

Modid:  2.4.x-xfs:slinx:75481a
linux/Makefile - 1.68
	- Add compile line "kgcc"  for RH 7.0
	  with comment explaining such.



From owner-linux-xfs@oss.sgi.com Mon Oct  2 15:05:54 2000
Received:  by oss.sgi.com id <S42453AbQJBWFo>;
	Mon, 2 Oct 2000 15:05:44 -0700
Received: from hermes.mixx.net ([212.84.196.2]:41489 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S42261AbQJBWFL>;
	Mon, 2 Oct 2000 15:05:11 -0700
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 3557CF85F
	for <linux-xfs@oss.sgi.com>; Tue,  3 Oct 2000 00:04:18 +0200 (CEST)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 15D582CA6D; Tue,  3 Oct 2000 00:04:18 +0200 (CEST)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: RedHat 7.0 - unbootable
Date:   2 Oct 2000 22:04:18 GMT
Organization: innominate AG, Berlin, Germany
Lines:  17
Distribution: local
Message-ID: <news2mail-8rb0p2$td3$1@mate.bln.innominate.de>
References: <20001001185959.A5235@s2y4n2c.de> <200010021502.KAA10030@jen.americas.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 970524258 30115 10.0.0.69 (2 Oct 2000 22:04:18 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-test8 (i586))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Steve Lord <lord@sgi.com> wrote:

> So the summary seems to be that the library shipped with Redhat 7.0 uses
> system calls not introduced until after 2.4.0-test5, but obviously copes
> with them not being there - just not with something else being there instead.
> Andi is correct in his statement that adding arbitary system calls is not a
> good idea.

i have added an entry into the faq for this now

t

-- 
thomas.graichen@innominate.de
technical director                                       innominate AG
clustering & security                                networking people
tel: +49.30.308806-13  fax: -77                   http://innominate.de

From owner-linux-xfs@oss.sgi.com Mon Oct  2 15:18:23 2000
Received:  by oss.sgi.com id <S42455AbQJBWSN>;
	Mon, 2 Oct 2000 15:18:13 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:53847 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42261AbQJBWRs>;
	Mon, 2 Oct 2000 15:17:48 -0700
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA14037; Mon, 2 Oct 2000 15:08:41 -0700 (PDT)
	mail_from (pv@feature.engr.sgi.com)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA05401; Mon, 2 Oct 2000 15:15:05 -0700 (PDT)
Date:   Mon, 2 Oct 2000 15:15:05 -0700 (PDT)
Message-Id: <200010022215.PAA05401@feature.engr.sgi.com>
X-Pv-Incident: 797165 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (dxm@melbourne.sgi.com)
Subject: ADD 797165 - rationalise uuid kernel code for XFS
To:     dxm@cthulhu.engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

 Submitter : nathans                   Status : open                        
 Assigned Engineer : dxm               Priority : 4                         
*Modified Date : 10/02/00             *Modified User : dxm                  
*Modified User Domain : melbourne     *Description :
stick this in a bug so it isn't forgotten...

On Jul 21,  8:40am, Nathan Scott wrote:
> Subject: Re: LVM vs. kiobuf I/O
> > >         - Kernel uuid generation support
> > ...
> ...
> 
> I think there's a bunch of stuff which can be rationalised
> there too...

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: daniel moore <dxm@clouds.melbourne.sgi.com>
Date: Oct 02 2000 03:15:05PM
[pvnews version: 1.71]
==========================

 => I was wrong last time. Glen added code to print uuid code from
 => xfs_db, not change it.
 => 
 => So we have two conflicing tasks here:
 => 
 => 1. turning an existing filesystem into two distinct filesystems.
 =>    because of how they are created - they would be different
 =>    devices, but have the same uuid.
 => 
 => 2. prevent mounts of the same device when it has multiple paths
 => 
 => I think we can make one work automatically and the other require
 => some operator intervention.

(irix6.5f-melb:irix:62215a)

Looks like he modified the write command so its possible to write the uuid
in the superblock (write wouldn't handle > 64 bit before). I made a similar
change to linux-xfs.

In the same mod he fixed up the code to change the UUID so it would work
properly on dirty filesystems (where log recovery could wipe out the
changed uuid).

His first change wouldn't work with the new log uuid code - it only
lets you write to individual superblocks. My "uuid" command sets all
superblocks and the log.

The second change would get dropped with the code to allow the kernel
to change the uuid on mount.

We don't lose any functionality here - we move task one to userspace
with a nice interface to pick a new uuid and we make task two work.


-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------

From owner-linux-xfs@oss.sgi.com Mon Oct  2 15:29:44 2000
Received:  by oss.sgi.com id <S42456AbQJBW3d>;
	Mon, 2 Oct 2000 15:29:33 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:11543 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42261AbQJBW25>; Mon, 2 Oct 2000 15:28:57 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA05233
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 15:35:16 -0700 (PDT)
	mail_from (ajag@snort.melbourne.sgi.com)
Received: (from ajag@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA56854;
	Tue, 3 Oct 2000 09:25:38 +1100 (EST)
Date:   Tue, 3 Oct 2000 09:25:38 +1100 (EST)
From:   Andrew Gildfind <ajag@snort.melbourne.sgi.com>
Message-Id: <200010022225.JAA56854@snort.melbourne.sgi.com>
To:     ptg_fsg@larry.melbourne.sgi.com, slinx-xfs@engr.sgi.com,
        linux-xfs@oss.sgi.com
Subject: TAKE - xfs_read_buf NULL dereference
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75484a
Date:  Mon Oct  2 15:22:55 PDT 2000
Workarea:  snort:/build5/ajag/slinx
Author:  ajag

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/xfs_rw.c - 1.328
	- Call to xfs_buf_read from xfs_read_buf can return NULL.
	  Pointer was always dereferenced through XFS_BUF_GETERROR (causing
	  a kernel fault) code now checks for this case and returns error on 
          NULL.


From owner-linux-xfs@oss.sgi.com Mon Oct  2 15:46:44 2000
Received:  by oss.sgi.com id <S42460AbQJBWq2>;
	Mon, 2 Oct 2000 15:46:28 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38424 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42459AbQJBWqC>; Mon, 2 Oct 2000 15:46:02 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09664
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 15:52:21 -0700 (PDT)
	mail_from (ajag@snort.melbourne.sgi.com)
Received: (from ajag@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA81227
	for linux-xfs@oss.sgi.com; Tue, 3 Oct 2000 09:42:48 +1100 (EST)
Date:   Tue, 3 Oct 2000 09:42:48 +1100 (EST)
From:   Andrew Gildfind <ajag@snort.melbourne.sgi.com>
Message-Id: <200010022242.JAA81227@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xfs_growfs endian issue
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75486a
Date:  Mon Oct  2 15:42:24 PDT 2000
Workarea:  snort:/build5/ajag/slinx
Author:  ajag

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/xfs_fsops.c - 1.59
	- When writing redundant superblocks to an expanded filesystem
	  xfs_growfs_data_private was writing non-endian converted data to disk.
	  This mod adds a call to xfs_xlatesb to convert the data.


From owner-linux-xfs@oss.sgi.com Mon Oct  2 15:51:04 2000
Received:  by oss.sgi.com id <S42457AbQJBWuo>;
	Mon, 2 Oct 2000 15:50:44 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:52760 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42261AbQJBWuW>; Mon, 2 Oct 2000 15:50:22 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA03622
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 15:56:12 -0700 (PDT)
	mail_from (ajag@snort.melbourne.sgi.com)
Received: (from ajag@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA20870
	for linux-xfs@oss.sgi.com; Tue, 3 Oct 2000 09:46:38 +1100 (EST)
Date:   Tue, 3 Oct 2000 09:46:38 +1100 (EST)
From:   Andrew Gildfind <ajag@snort.melbourne.sgi.com>
Message-Id: <200010022246.JAA20870@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fill2fs syntax error
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75487a
Date:  Mon Oct  2 15:46:04 PDT 2000
Workarea:  snort:/build5/ajag/slinx
Author:  ajag

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/src/fill2fs - 1.2
	- Fix typo.


From owner-linux-xfs@oss.sgi.com Mon Oct  2 16:11:14 2000
Received:  by oss.sgi.com id <S42261AbQJBXLE>;
	Mon, 2 Oct 2000 16:11:04 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:27674 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42461AbQJBXKg>; Mon, 2 Oct 2000 16:10:36 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA00092
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 16:16:55 -0700 (PDT)
	mail_from (ajag@snort.melbourne.sgi.com)
Received: (from ajag@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA02803
	for linux-xfs@oss.sgi.com; Tue, 3 Oct 2000 10:08:36 +1100 (EST)
Date:   Tue, 3 Oct 2000 10:08:36 +1100 (EST)
From:   Andrew Gildfind <ajag@snort.melbourne.sgi.com>
Message-Id: <200010022308.KAA02803@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fsr QA improvment
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75490a
Date:  Mon Oct  2 16:07:55 PDT 2000
Workarea:  snort:/build5/ajag/slinx
Author:  ajag

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/042 - 1.2
	- Ensure that available free space is fragmented - ie fsr_xfs must 
          move a file from m to n extents where m >> n (ie m is thousands and 
          n is now 16).


From owner-linux-xfs@oss.sgi.com Mon Oct  2 16:45:04 2000
Received:  by oss.sgi.com id <S42463AbQJBXoy>;
	Mon, 2 Oct 2000 16:44:54 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47388 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42461AbQJBXoZ>; Mon, 2 Oct 2000 16:44:25 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA07898
	for <linux-xfs@oss.sgi.com>; Mon, 2 Oct 2000 16:50:44 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA31304
	for linux-xfs@oss.sgi.com; Tue, 3 Oct 2000 10:40:41 +1100 (EST)
Date:   Tue, 3 Oct 2000 10:40:41 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200010022340.KAA31304@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - 801613 Log format changes (Heads Up)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Please Note:

	- You won't be able to recover DIRTY filesystems created
	  prior to this change - clean ones should be fine.
	  xfs_repair will get a dirty FS going again (but wipe
	  the log)
	- If you have any filesystems with external logs, you
	  should run xfs_repair on them before mounting.
	- Please make sure you do a full rebuild of the tools.
	  This change touches mkfs, db, logprint and repair.

Modid:  2.4.x-xfs:slinx:75492a
Date:  Mon Oct  2 16:35:37 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/db/uuid.c - 1.4
cmd/xfs/include/libxfs.h - 1.19
	- pv 801613 - remove log footer, use new libxfs_log_clear

cmd/xfs/include/xfs_log_priv.h - 1.4
	- pv 801613 - remove log footer add new uuid and format fields

cmd/xfs/libxfs/rdwr.c - 1.16
	- pv 801613 - remove log footer, use new libxfs_log_clear

cmd/xfs/logprint/log_misc.c - 1.71
cmd/xfs/logprint/log_print_trans.c - 1.34
cmd/xfs/logprint/logprint.c - 1.50
cmd/xfs/logprint/logprint.h - 1.9
	- pv 801613 - display new fields, cleanup, make "stop on error" default,
	  don't display "overwrites" data by default

cmd/xfs/logprint/xfs_log_recover.c - 1.4
	- pv 801613 - match kernel code

cmd/xfs/mkfs/xfs_mkfs.c - 1.178
cmd/xfs/repair/phase2.c - 1.31
	- pv 801613 - remove log footer, use new libxfs_log_clear

cmd/xfs/stress/016 - 1.4
cmd/xfs/stress/018 - 1.4
cmd/xfs/stress/018.out - 1.4
cmd/xfs/stress/029 - 1.3
cmd/xfs/stress/029.out - 1.2
	- pv 801613 - handle new log format

cmd/xfs/stress/src/Makefile - 1.17
	- pv 801613 - add loggen

linux/fs/xfs/xfs_log.c - 1.225
	- pv 801613 - set new fields

linux/fs/xfs/xfs_log_priv.h - 1.76
linux/fs/xfs/xfs_log_recover.c - 1.193
	- pv 801613 - remove log footer add new uuid and format fields

cmd/xfs/stress/src/loggen.c - 1.1
	- pv 801613 - generate fake log entries


From owner-linux-xfs@oss.sgi.com Mon Oct  2 16:52:34 2000
Received:  by oss.sgi.com id <S42472AbQJBXwZ>;
	Mon, 2 Oct 2000 16:52:25 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1821 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42461AbQJBXwN>; Mon, 2 Oct 2000 16:52:13 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA06216; Mon, 2 Oct 2000 16:58:33 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA04894;
	Mon, 2 Oct 2000 16:51:32 -0700 (PDT)
Date:   Mon, 2 Oct 2000 16:51:32 -0700 (PDT)
Message-Id: <200010022351.QAA04894@info.engr.sgi.com>
X-Pv-Incident: 803625 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (ajag@melbourne.sgi.com)
Subject: BUG 803625 - xfs_growfs QA failure and possible pagebuf problem
To:     ananth@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=803625

Submitter : ajag                      Submitter Domain : melbourne          
Assigned Engineer : ananth            Assigned Domain : engr                
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 2                          
Project : xfs-linux                   Status : open                         
Description :
The growfs QA test creates a 16Mb filesystem with one allocation group and
sucessively grows its size to 17, 33, 35 and 48 megabyte (3 ags) with four calls to
xfs_growfs. The first growfs appears to succeed, however, subsequents calls fail
on a call to xfs_read_buf (line 336 xfs_fsops.c) while writing out the redundant
superblocks for the filesystem. The call sequence looks like:
 
xfs_growfs_data_private
  xfs_read_buf (function)
    xfs_buf_read (macro)
      pagebuf_get (function call at line 747 page_buf.c)
        _pagebuf_get_lockable_buffer (function) page_buf_locking.c 
>>>       _pagebuf_find_lockable_buffer (f) returns EBUSY at line 426

(note my line numbers may be off by a couple as I've stuffed a few printks in...)

It appears that the pagebuf allocated in the first call to growfs is hanging around
in the kernel not being correctly freed up - or at least there is some delay which
is being hit because these growfs's are happening in quick succession.

When the xfs_read_buf call fails, xfs_growfs simply gives up trying to write out
the redundant superblocks, and (I think) this is what then triggers the ASSERT
in the third growfs below.

The following is a sequence which shows most of the calls, and in particular where
pagebufs are being created for regions of the disk, the problem first appears when a
region of the disk is touched twice (ie the superblock at 32768 basic blocks).
Finally, note that I haven't yet tried to reproduce these errors on a test8 kernel.

*** xfs_ioctl: cmd is 1074550894
*** copy from user... done
*** call xfs_growfs_data...
*** xfs_growfs_data
        *** acquire lock... done
        *** xfs_growfs_data_private:
                old: agcount: 1; blocks: 4096
                new: 1; nb_mod: 256; nagcount: 2
        *** xfs_growfs_data_private: agno is 1, writing AGF at:
                32769 basic blocks; length: 1
        *** xfs_growfs_data_private: agno is 1, writing AGI at:
                32770 basic blocks; length: 1
        *** xfs_growfs_data_private: agno is 1, writing BNO btree at:
                32776 basic blocks; length: 8
        *** xfs_growfs_data_private: agno is 1, writing CNT btree at:
                32784 basic blocks; length: 8
        *** xfs_growfs_data_private: agno is 1, writing INO btree at:
                32792 basic blocks; length: 8
        *** xfs_growfs_data_private: agno is 1, writing superblock at:
                32768 basic blocks; length: 8
done

Start mounting filesystem: ide0(3,9)
Ending clean XFS mount for filesystem: ide0(3,9)
*** xfs_ioctl: cmd is 1074550894
*** copy from user... done
*** call xfs_growfs_data...
*** xfs_growfs_data
        *** acquire lock... done
        *** xfs_growfs_data_private:
                old: agcount: 2; blocks: 4096
                new: 2; nb_mod: 256; nagcount: 3
        *** xfs_growfs_data_private: agno is 2, writing AGF at:
                65537 basic blocks; length: 1
        *** xfs_growfs_data_private: agno is 2, writing AGI at:
                65538 basic blocks; length: 1
        *** xfs_growfs_data_private: agno is 2, writing BNO btree at:
                65544 basic blocks; length: 8
        *** xfs_growfs_data_private: agno is 2, writing CNT btree at:
                65552 basic blocks; length: 8
        *** xfs_growfs_data_private: agno is 2, writing INO btree at:
                65560 basic blocks; length: 8
        *** xfs_growfs_data_private: agno is 1, writing superblock at:
                32768 basic blocks; length: 8:

                *** _pagebuf_find_lockable_buffer: letting go of the buffer...
                        [ Returns EBUSY at line 426 in page_buf_locking.c ]
                *** _pagebuf_get_lockable_buffer returning status: -16
                        [ Return at line 454 in page_buf_locking.c ]
                *** pagebuf_get: Error: _pagebuf_get_lockable_buffer failed
                        [ Returns at 757 ]

        cmn_err level 4 Filesystem "ide0(3,9)": error 5 reading secondary 
        superblock for ag 1
done

Start mounting filesystem: ide0(3,9)
Ending clean XFS mount for filesystem: ide0(3,9)
*** xfs_ioctl: cmd is 1074550894
*** copy from user... done
*** call xfs_growfs_data...
*** xfs_growfs_data
*** acquire lock... done
*** xfs_growfs_data_private:
        old: agcount: 3; blocks: 4096
        new: 2; nb_mod: 768; nagcount: 3

XFS assertion failed: agno < mp->m_sb.sb_agcount - 1 || 
        INT_GET(agi->agi_length, ARCH_CONVERT) == mp->m_sb.sb_agblocks,
        file: xfs_fsops.c, line: 336
kernel BUG at xfs_debug.c:45!

Entering kdb (current=0xc5e68000, pid 3298) Panic: invalid operand
due to panic @ 0xc01c7409
eax = 0x0000001e ebx = 0x00000000 ecx = 0xc030a8cc edx = 0x00000000 
esi = 0xc534f400 edi = 0xc64a7000 esp = 0xc5e69b38 eip = 0xc01c7409 
ebp = 0xc5e69b44  ss = 0x00000018  cs = 0x00000010 eflags = 0x00010246 
 ds = 0x00000018  es = 0x00000018 origeax = 0xffffffff &regs = 0xc5e69b04
kdb>

From owner-linux-xfs@oss.sgi.com Mon Oct  2 16:56:04 2000
Received:  by oss.sgi.com id <S42465AbQJBXzo>;
	Mon, 2 Oct 2000 16:55:44 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:48236 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42461AbQJBXzR>;
	Mon, 2 Oct 2000 16:55:17 -0700
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA25097; Mon, 2 Oct 2000 16:46:52 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA23224; Mon, 2 Oct 2000 16:54:35 -0700 (PDT)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA04527;
	Mon, 2 Oct 2000 16:53:18 -0700 (PDT)
Date:   Mon, 2 Oct 2000 16:53:18 -0700 (PDT)
Message-Id: <200010022353.QAA04527@info.engr.sgi.com>
X-Pv-Incident: 803625 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (ajag@melbourne.sgi.com)
Subject: ADD 803625 - xfs_growfs QA failure and possible pagebuf problem
To:     ananth@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=803625

 Status : open                         Priority : 2                         
 Assigned Engineer : ananth            Submitter : ajag                     
*Modified User : ajag                 *Modified User Domain : melbourne     
*Description :
The growfs QA test creates a 16Mb filesystem with one allocation group and
sucessively grows its size to 17, 33, 35 and 48 megabyte (3 ags) with four calls to
xfs_growfs. The first growfs appears to succeed, however, subsequents calls fail
on a call to xfs_read_buf (line 336 xfs_fsops.c) while writing out the redundant
superblocks for the filesystem. The call sequence looks like:
 
xfs_growfs_data_private
  xfs_read_buf (function)
    xfs_buf_read (macro)
      pagebuf_get (function call at line 747 page_buf.c)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: ajag@melbourne (BugWorks)
Date: Oct 02 2000 04:53:18PM
==========================

NOTE: Also the QA test in question is xfs/cmd/stress/041, it
is not currently in the auto qa group and doesn't have a verified
output (as I have got it to work successfully yet).

From owner-linux-xfs@oss.sgi.com Mon Oct  2 18:18:25 2000
Received:  by oss.sgi.com id <S42473AbQJCBSF>;
	Mon, 2 Oct 2000 18:18:05 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:40315 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42461AbQJCBRn>;
	Mon, 2 Oct 2000 18:17:43 -0700
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA03145; Mon, 2 Oct 2000 18:09:18 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id SAA70349; Mon, 2 Oct 2000 18:17:01 -0700 (PDT)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA74216;
	Mon, 2 Oct 2000 18:15:43 -0700 (PDT)
Date:   Mon, 2 Oct 2000 18:15:43 -0700 (PDT)
Message-Id: <200010030115.SAA74216@info.engr.sgi.com>
X-Pv-Incident: 801613 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: CLOSE 801613 - external log footer is incompatible with IRIX XFS
To:     dxm@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801613

*Status : closed                       Priority : 3                         
 Assigned Engineer : dxm               Submitter : dxm                      
 Opened Date : 09/12/00               *Closed Date : 10/02/00               
*Fixed By : dxm                       *Fixed By Domain : engr               
*Modified Date : 10/02/00             *Modified User : dxm                  
*Modified User Domain : engr          *Fix Description :
==========================
ADDITIONAL INFORMATION (CLOSE)
From: dxm@engr (BugWorks)
Date: Oct 02 2000 06:15:42PM
==========================

Modid:  2.4.x-xfs:slinx:75492a
Date:  Mon Oct  2 16:35:37 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/db/uuid.c - 1.4
cmd/xfs/include/libxfs.h - 1.19
	- pv 801613 - remove log footer, use new libxfs_log_clear

cmd/xfs/include/xfs_log_priv.h - 1.4
	- pv 801613 - remove log footer add new uuid and format fields

cmd/xfs/libxfs/rdwr.c - 1.16
	- pv 801613 - remove log footer, use new libxfs_log_clear

cmd/xfs/logprint/log_misc.c - 1.71
cmd/xfs/logprint/log_print_trans.c - 1.34
cmd/xfs/logprint/logprint.c - 1.50
cmd/xfs/logprint/logprint.h - 1.9
	- pv 801613 - display new fields, cleanup, make "stop on error" default,
	  don't display "overwrites" data by default

cmd/xfs/logprint/xfs_log_recover.c - 1.4
	- pv 801613 - match kernel code

cmd/xfs/mkfs/xfs_mkfs.c - 1.178
cmd/xfs/repair/phase2.c - 1.31
	- pv 801613 - remove log footer, use new libxfs_log_clear

cmd/xfs/stress/016 - 1.4
cmd/xfs/stress/018 - 1.4
cmd/xfs/stress/018.out - 1.4
cmd/xfs/stress/029 - 1.3
cmd/xfs/stress/029.out - 1.2
	- pv 801613 - handle new log format

cmd/xfs/stress/src/Makefile - 1.17
	- pv 801613 - add loggen

linux/fs/xfs/xfs_log.c - 1.225
	- pv 801613 - set new fields

linux/fs/xfs/xfs_log_priv.h - 1.76
linux/fs/xfs/xfs_log_recover.c - 1.193
	- pv 801613 - remove log footer add new uuid and format fields

cmd/xfs/stress/src/loggen.c - 1.1
	- pv 801613 - generate fake log entries

From owner-linux-xfs@oss.sgi.com Tue Oct  3 02:21:39 2000
Received:  by oss.sgi.com id <S42461AbQJCJV3>;
	Tue, 3 Oct 2000 02:21:29 -0700
Received: from edge.coltex.nl ([194.151.97.115]:17682 "EHLO lsinet.coltex.nl")
	by oss.sgi.com with ESMTP id <S42459AbQJCJVB>;
	Tue, 3 Oct 2000 02:21:01 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by lsinet.coltex.nl (8.10.0/8.9.3) with ESMTP id e939K4E00829
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 11:20:08 +0200
Message-Id: <4.3.2.7.2.20001003111445.0286a688@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Tue, 03 Oct 2000 11:19:38 +0200
To:     linux-xfs@oss.sgi.com
From:   Seth Mos <knuffie@xs4all.nl>
Subject: test8-xfs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

I am experiencing a lot of weird behaviour on my home machine with test8.
It seems like I have just about all the hardware that test8 doesn't like.

I can't keep my home machine running for more then one hour without some 
sort crash oops or panic. The crashes on itself don't seem related to XFS 
in any way.
I don't think I have the messages anymore. I'm just an amateur. ;-)

Here's my dmesg of test5-xfs which can keep running for more then a week.

Linux version 2.4.0-test5 (root@stimpy.multiweb.nl) (gcc version 
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #11 Wed Sep 27 18:29:24 
CEST 2000
BIOS-provided physical RAM map:
  e820: 000000000009fc00 @ 0000000000000000 (usable)
  e820: 0000000000000400 @ 000000000009fc00 (reserved)
  e820: 0000000000004000 @ 00000000000dc000 (reserved)
  e820: 0000000000010000 @ 00000000000f0000 (reserved)
  e820: 000000000bef0000 @ 0000000000100000 (usable)
  e820: 0000000000008000 @ 000000000bff0000 (ACPI data)
  e820: 0000000000008000 @ 000000000bff8000 (ACPI NVS)
  e820: 0000000000010000 @ 00000000ffff0000 (reserved)
On node 0 totalpages: 49136
zone(0): 4096 pages.
zone(1): 45040 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=linux-240-test5 ro root=305
Initializing CPU#0
Detected 503536364 Hz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1002.70 BogoMIPS
Memory: 191180k/196544k available (1205k kernel code, 4976k reserved, 87k 
data, 208k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
VFS: Diskquotas version dquot_6.4.0 initialized
CPU: L1 I Cache: 64K  L1 D Cache: 64K (64 bytes/line)
CPU: L2 Cache: 512K
CPU: AMD-K7(tm) Processor stepping 02
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.36 (20000221) Richard Gooch (rgooch@atnf.csiro.au)
PCI: PCI BIOS revision 2.10 entry at 0xfd9e1, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router VIA [1106/0586] at 00:04.0
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.3
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
Initializing RT netlink socket
Starting kswapd v1.7
pty: 256 Unix98 ptys configured
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: registered device at major 7
loop: enabling 8 loop devices
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 21
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
hda: IBM-DTLA-307060, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 120103200 sectors (61493 MB) w/1916KiB Cache, CHS=7476/255/63
Partition check:
  hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
sym53c8xx: at PCI bus 0, device 15, function 0
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
sym53c8xx: 53c875J detected with Symbios NVRAM
sym53c875J-0: rev 0x4 on pci bus 0 device 15 function 0 irq 10
sym53c875J-0: Symbios format NVRAM, ID 7, Fast-20, Parity Checking
sym53c875J-0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/4e/80/01/00/24
sym53c875J-0: final   SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/46/80/00/08/24
sym53c875J-0: on-chip RAM at 0xefffe000
sym53c875J-0: resetting, command processing suspended for 2 seconds
sym53c875J-0: restart (scsi reset).
sym53c875J-0: enabling clock multiplier
sym53c875J-0: Downloading SCSI SCRIPTS.
scsi0 : sym53c8xx - version 1.6b
scsi : 1 host.
sym53c875J-0: command processing resumed
   Vendor: PLEXTOR   Model: CD-ROM PX-32TS    Rev: 1.02
   Type:   CD-ROM                             ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 2, lun 0
   Vendor: PHILIPS   Model: CDD2600           Rev: 1.07
   Type:   CD-ROM                             ANSI SCSI revision: 02
Detected scsi CD-ROM sr1 at scsi0, channel 0, id 3, lun 0
scsi : detected 2 SCSI cdroms total.
sym53c875J-0-<2,0>: sync msgout: 1-3-1-c-10.
sym53c875J-0-<2,0>: sync msg in: 1-3-1-c-f.
sym53c875J-0-<2,0>: sync: per=12 scntl3=0x90 scntl4=0x0 ofs=15 fak=0 chg=0.
sym53c875J-0-<2,*>: FAST-20 SCSI 20.0 MB/s (50 ns, offset 15)
sym53c875J-0-<2,0>: sync msgout: 1-3-1-c-10.
sym53c875J-0-<2,0>: sync msg in: 1-3-1-c-f.
sym53c875J-0-<2,0>: sync: per=12 scntl3=0x90 scntl4=0x0 ofs=15 fak=0 chg=0.
sym53c875J-0-<2,0>: sync msgout: 1-3-1-c-10.
sym53c875J-0-<2,0>: sync msg in: 1-3-1-c-f.
sym53c875J-0-<2,0>: sync: per=12 scntl3=0x90 scntl4=0x0 ofs=15 fak=0 chg=0.
Uniform CD-ROM driver Revision: 3.11
sym53c875J-0-<3,*>: target did not report SYNC.
Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ 
SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 208k freed
Adding Swap: 530136k swap-space (priority -1)
page_buf module - Copyright (C) by Silicon Graphics Inc. 2000
Start mounting filesystem: ide0(3,9)
Ending clean XFS mount for filesystem: ide0(3,9)
Start mounting filesystem: ide0(3,10)
Ending clean XFS mount for filesystem: ide0(3,10)
Start mounting filesystem: ide0(3,11)
Ending clean XFS mount for filesystem: ide0(3,11)
Start mounting filesystem: ide0(3,12)
Ending clean XFS mount for filesystem: ide0(3,12)
8139too Fast Ethernet driver 0.9.7 loaded
eth0: RealTek RTL8139 Fast Ethernet board found at 0xeffffe00, IRQ 11
eth0:   Chip is 'RTL-8139B'
eth0:   MAC address 00:00:b4:a7:e2:b8.
eepro100.c:v1.09j-t 9/29/99 Donald Becker 
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.33 $ 2000/05/24 Modified by Andrey V. Savochkin 
<saw@saw.sw.com.sg> and others
eth1: Intel Corporation 82557 [Ethernet Pro 100], 00:D0:B7:B2:B2:EA, IRQ 9.
   Receiver lock-up bug exists -- enabling work-around.
   Board assembly 721383-009, Physical connectors present: RJ45
   Primary interface chip i82555 PHY #1.
   General self-test: passed.
   Serial sub-system self-test: passed.
   Internal registers self-test: passed.
   ROM checksum self-test: passed (0x04f4518b).
ip_conntrack (1535 buckets, 12280 max)


Bye
--
Seth
"Have you gone mad?"
"Well, yes, but that's beyond the scope of this email."


From owner-linux-xfs@oss.sgi.com Tue Oct  3 04:55:20 2000
Received:  by oss.sgi.com id <S42475AbQJCLzK>;
	Tue, 3 Oct 2000 04:55:10 -0700
Received: from sun.rhrk.uni-kl.de ([131.246.137.50]:52463 "HELO
        sun.rhrk.uni-kl.de") by oss.sgi.com with SMTP id <S42367AbQJCLyu>;
	Tue, 3 Oct 2000 04:54:50 -0700
Received: from aixs1.rhrk.uni-kl.de
           ( exim@aixs1.rhrk.uni-kl.de [131.246.137.3] ) by sun.rhrk.uni-kl.de
          id aa19880 for <linux-xfs@oss.sgi.com>; 3 Oct 2000 13:54 MESZ
Received: from trip210.wohnheim.uni-kl.de ([131.246.188.10] helo=student.uni-kl.de)
	by aixs1.rhrk.uni-kl.de with esmtp (Exim 3.03 #2)
	id 13gQe6-000Hq0-00
	for linux-xfs@oss.sgi.com; Tue, 03 Oct 2000 13:54:06 +0200
Message-ID: <39D9C99A.1CFC430C@student.uni-kl.de>
Date:   Tue, 03 Oct 2000 11:57:14 +0000
From:   Ralf Sinoradzki <sinoradz@student.uni-kl.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC:     linux-xfs@oss.sgi.com
Subject: Re: Little Problem with XFS and Debian Woody
References: <200010021838.NAA12073@jen.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Thanks :)
I'll try out the latest cvs code ...

Ralf

From owner-linux-xfs@oss.sgi.com Tue Oct  3 05:13:00 2000
Received:  by oss.sgi.com id <S42476AbQJCMMu>;
	Tue, 3 Oct 2000 05:12:50 -0700
Received: from Cantor.suse.de ([194.112.123.193]:38924 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42367AbQJCMMY>;
	Tue, 3 Oct 2000 05:12:24 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 5B90F1E090; Tue,  3 Oct 2000 14:11:41 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id CE2083E44F; Tue,  3 Oct 2000 14:11:40 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 5438E2F300; Tue,  3 Oct 2000 14:11:40 +0200 (MEST)
Date:   Tue, 3 Oct 2000 14:11:40 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Russell Cattelan <cattelan@sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - add kgcc line for RH 7.0
Message-ID: <20001003141140.A25453@gruyere.muc.suse.de>
References: <200010022143.e92LhPH00355@gibble.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200010022143.e92LhPH00355@gibble.americas.sgi.com>; from cattelan@sgi.com on Mon, Oct 02, 2000 at 04:43:25PM -0500
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, Oct 02, 2000 at 04:43:25PM -0500, Russell Cattelan wrote:
> Date:  Mon Oct  2 14:42:35 PDT 2000
> Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-devel
> 
> The following file(s) were checked into:
>   bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs
> 
> Also changed extraversion to XFS-test8 
> 
> Modid:  2.4.x-xfs:slinx:75481a
> linux/Makefile - 1.68
> 	- Add compile line "kgcc"  for RH 7.0
> 	  with comment explaining such.

Hallo Russell,

Could you please put somewhere into the XFS Beta module something like

#if __GNUC__==2 && __GNUC_MINOR__==95
#error "does not compile properly with gcc 2.95. get egcs 1.1." 
#endif

This should save the users of distributions which come with 
2.95 by default (SuSE, newer Debian, probably others) some grief and you
many bug reports. Not all the world is RedHat.


-Andi



From owner-linux-xfs@oss.sgi.com Tue Oct  3 06:58:41 2000
Received:  by oss.sgi.com id <S42312AbQJCN6a>;
	Tue, 3 Oct 2000 06:58:30 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:57952 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42299AbQJCN6R>;
	Tue, 3 Oct 2000 06:58:17 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA26310
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 06:49:52 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id IAA7108073; Tue, 3 Oct 2000 08:55:03 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id IAA86162; Tue, 3 Oct 2000 08:55:02 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id IAA16493;
	Tue, 3 Oct 2000 08:49:37 -0500
Message-Id: <200010031349.IAA16493@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Ralf Sinoradzki <sinoradz@student.uni-kl.de>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Little Problem with XFS and Debian Woody 
In-Reply-To: Message from Ralf Sinoradzki <sinoradz@student.uni-kl.de> 
   of "Tue, 03 Oct 2000 11:57:14 -0000." <39D9C99A.1CFC430C@student.uni-kl.de> 
Date:   Tue, 03 Oct 2000 08:49:32 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



> Thanks :)
> I'll try out the latest cvs code ...
> 
> Ralf


It turns out it will not fix debian, I think we need some more information,
the strace output I mentioned before would be a real help here.

Steve


From owner-linux-xfs@oss.sgi.com Tue Oct  3 07:02:10 2000
Received:  by oss.sgi.com id <S42363AbQJCOCA>;
	Tue, 3 Oct 2000 07:02:00 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:26721 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42299AbQJCOBk>;
	Tue, 3 Oct 2000 07:01:40 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA26634
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 06:53:02 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id IAA7077341; Tue, 3 Oct 2000 08:58:03 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id IAA54646; Tue, 3 Oct 2000 08:58:03 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id IAA16504;
	Tue, 3 Oct 2000 08:52:37 -0500
Message-Id: <200010031352.IAA16504@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Seth Mos <knuffie@xs4all.nl>
cc:     linux-xfs@oss.sgi.com
Subject: Re: test8-xfs 
In-Reply-To: Message from Seth Mos <knuffie@xs4all.nl> 
   of "Tue, 03 Oct 2000 11:19:38 +0200." <4.3.2.7.2.20001003111445.0286a688@pop.xs4all.nl> 
Date:   Tue, 03 Oct 2000 08:52:36 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> I am experiencing a lot of weird behaviour on my home machine with test8.
> It seems like I have just about all the hardware that test8 doesn't like.

Unfortunately because we are lugging xfs changes around in the main line kernel
when we move to a new kernel version we are stuck with all the other junk
which comes with that kernel. I think we should have some reworked test5
images which will work with RedHat 7 shortly, they may be your best bet until
we have moved on to a more stable kernel would be to stick to test5 for a
while.

Steve


> 
> I can't keep my home machine running for more then one hour without some 
> sort crash oops or panic. The crashes on itself don't seem related to XFS 
> in any way.
> I don't think I have the messages anymore. I'm just an amateur. ;-)
> 



From owner-linux-xfs@oss.sgi.com Tue Oct  3 08:52:01 2000
Received:  by oss.sgi.com id <S42459AbQJCPvv>;
	Tue, 3 Oct 2000 08:51:51 -0700
Received: from hermes.mixx.net ([212.84.196.2]:15120 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S42299AbQJCPvd>;
	Tue, 3 Oct 2000 08:51:33 -0700
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 1ADACF841
	for <linux-xfs@oss.sgi.com>; Tue,  3 Oct 2000 17:51:31 +0200 (CEST)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id C8A8B2CA6D; Tue,  3 Oct 2000 17:51:30 +0200 (CEST)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: TAKE - add kgcc line for RH 7.0
Date:   3 Oct 2000 15:51:30 GMT
Organization: innominate AG, Berlin, Germany
Lines:  43
Distribution: local
Message-ID: <news2mail-8rcva2$m81$2@mate.bln.innominate.de>
References: <200010022143.e92LhPH00355@gibble.americas.sgi.com> <20001003141140.A25453@gruyere.muc.suse.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 970588290 22785 10.0.0.69 (3 Oct 2000 15:51:30 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-test8 (i586))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

"Andi Kleen" <ak@suse.de> wrote:
> On Mon, Oct 02, 2000 at 04:43:25PM -0500, Russell Cattelan wrote:
>> Date:  Mon Oct  2 14:42:35 PDT 2000
>> Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-devel
>> 
>> The following file(s) were checked into:
>>   bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs
>> 
>> Also changed extraversion to XFS-test8 
>> 
>> Modid:  2.4.x-xfs:slinx:75481a
>> linux/Makefile - 1.68
>> 	- Add compile line "kgcc"  for RH 7.0
>> 	  with comment explaining such.

> Hallo Russell,

> Could you please put somewhere into the XFS Beta module something like

> #if __GNUC__==2 && __GNUC_MINOR__==95
> #error "does not compile properly with gcc 2.95. get egcs 1.1." 
> #endif

> This should save the users of distributions which come with 
> 2.95 by default (SuSE, newer Debian, probably others) some grief and you
> many bug reports. Not all the world is RedHat.

maybe the same for 2.96 (redhat 7.0) too which as far as i remember
from here also has problems ...

t

p.s.: maybe we should also add an arch check there too - because on
      ppc it seems to work (without any big testing) with 2.95 (and
      i think there is no egcs precompiled available for this arch
      in most distribs) ... i think alpha is about the same - but
      on the other hand - who is playing with XFS on those arches :-)

-- 
thomas.graichen@innominate.de
technical director                                       innominate AG
clustering & security                                networking people
tel: +49.30.308806-13  fax: -77                   http://innominate.de

From owner-linux-xfs@oss.sgi.com Tue Oct  3 08:56:41 2000
Received:  by oss.sgi.com id <S42477AbQJCP4b>;
	Tue, 3 Oct 2000 08:56:31 -0700
Received: from hermes.mixx.net ([212.84.196.2]:21776 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S42299AbQJCP41>;
	Tue, 3 Oct 2000 08:56:27 -0700
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 121A6F84A
	for <linux-xfs@oss.sgi.com>; Tue,  3 Oct 2000 17:56:25 +0200 (CEST)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 93C5F2CA6F; Tue,  3 Oct 2000 17:56:24 +0200 (CEST)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: XFS aware miniroot for linux
Date:   3 Oct 2000 15:56:24 GMT
Organization: innominate AG, Berlin, Germany
Lines:  25
Distribution: local
Message-ID: <news2mail-8rcvj8$m81$3@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 970588584 22785 10.0.0.69 (3 Oct 2000 15:56:24 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-test8 (i586))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

for all of you here playing around with XFS the following might be
interesting:

i have put together a miniroot system for linux which contains all
the stuff needed to convert the root fs to XFS or to xfs_repair an
non mounted XFS root fs or to restore a backup from the network if
anything else fails ... the idea of that this is a simple ramdisk
image booted via the initrd mechanism and containing (hopefully :-)
all you need for the above tasks ... all you need is a separate
ext2 /boot partition and a minute to try it out ... all that to-
gether with a small README you may find at

  http://innominate.org/~graichen/projects/miniroot

all comments and suggestions please to me ...

hope that this is in any way useful

t

-- 
thomas.graichen@innominate.de
technical director                                       innominate AG
clustering & security                                networking people
tel: +49.30.308806-13  fax: -77                   http://innominate.de

From owner-linux-xfs@oss.sgi.com Tue Oct  3 09:14:20 2000
Received:  by oss.sgi.com id <S42480AbQJCQOL>;
	Tue, 3 Oct 2000 09:14:11 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:45831 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42299AbQJCQNw>;
	Tue, 3 Oct 2000 09:13:52 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA15097
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 09:05:26 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id LAA7098612; Tue, 3 Oct 2000 11:10:35 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id LAA14852; Tue, 3 Oct 2000 11:10:34 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id LAA06973;
	Tue, 3 Oct 2000 11:05:08 -0500
Message-Id: <200010031605.LAA06973@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Daniel Moore <dxm@snort.melbourne.sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - 801613 Log format changes (Heads Up) 
In-Reply-To: Message from Daniel Moore <dxm@snort.melbourne.sgi.com> 
   of "Tue, 03 Oct 2000 10:40:41 +1100." <200010022340.KAA31304@snort.melbourne.sgi.com> 
Date:   Tue, 03 Oct 2000 11:05:07 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> Please Note:
> 
> 	- You won't be able to recover DIRTY filesystems created
> 	  prior to this change - clean ones should be fine.
> 	  xfs_repair will get a dirty FS going again (but wipe
> 	  the log)
> 	- If you have any filesystems with external logs, you
> 	  should run xfs_repair on them before mounting.
> 	- Please make sure you do a full rebuild of the tools.
> 	  This change touches mkfs, db, logprint and repair.
> 


Maybe we should bump the version number on the command RPM?

Steve


From owner-linux-xfs@oss.sgi.com Tue Oct  3 11:25:11 2000
Received:  by oss.sgi.com id <S42249AbQJCSYv>;
	Tue, 3 Oct 2000 11:24:51 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:27949 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42299AbQJCSY0>;
	Tue, 3 Oct 2000 11:24:26 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA04447; Tue, 3 Oct 2000 11:16:01 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA91128; Tue, 3 Oct 2000 11:23:44 -0700 (PDT)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA46428;
	Tue, 3 Oct 2000 11:22:28 -0700 (PDT)
Date:   Tue, 3 Oct 2000 11:22:28 -0700 (PDT)
Message-Id: <200010031822.LAA46428@info.engr.sgi.com>
X-Pv-Incident: 803625 
webPV:  jen.americas.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (lord@sgi.com)
Subject: ADD 803625 - xfs_growfs QA failure and possible pagebuf problem
To:     ananth@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=803625

 Status : open                         Priority : 2                         
 Assigned Engineer : ananth            Submitter : ajag                     
*Modified User : lord                 *Modified User Domain : sgi.com       
*Description :
The growfs QA test creates a 16Mb filesystem with one allocation group and
sucessively grows its size to 17, 33, 35 and 48 megabyte (3 ags) with four calls to
xfs_growfs. The first growfs appears to succeed, however, subsequents calls fail
on a call to xfs_read_buf (line 336 xfs_fsops.c) while writing out the redundant
superblocks for the filesystem. The call sequence looks like:
 
xfs_growfs_data_private
  xfs_read_buf (function)
    xfs_buf_read (macro)
      pagebuf_get (function call at line 747 page_buf.c)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: lord@sgi.com (BugWorks)
Date: Oct 03 2000 11:22:27AM
==========================

It looks like the pagebuf written out for the first superblock
update has not been written yet - it should get unlocked at the
end of the write to disk. If you turn on pagebuf tracing,
and call BUG() where the EBUSY error is happening the pbtrace
will tell you who did what with the buffer.

From owner-linux-xfs@oss.sgi.com Tue Oct  3 11:51:11 2000
Received:  by oss.sgi.com id <S42306AbQJCSvA>;
	Tue, 3 Oct 2000 11:51:00 -0700
Received: from sun.rhrk.uni-kl.de ([131.246.137.50]:25489 "HELO
        sun.rhrk.uni-kl.de") by oss.sgi.com with SMTP id <S42274AbQJCSuZ>;
	Tue, 3 Oct 2000 11:50:25 -0700
Received: from aixs1.rhrk.uni-kl.de
           ( exim@aixs1.rhrk.uni-kl.de [131.246.137.3] ) by sun.rhrk.uni-kl.de
          id aa27162 ; 3 Oct 2000 20:49 MESZ
Received: from trip210.wohnheim.uni-kl.de ([131.246.188.10] helo=student.uni-kl.de)
	by aixs1.rhrk.uni-kl.de with esmtp (Exim 3.03 #2)
	id 13gX8C-000Fqa-00; Tue, 03 Oct 2000 20:49:37 +0200
Message-ID: <39DA2B00.E51789F3@student.uni-kl.de>
Date:   Tue, 03 Oct 2000 18:52:48 +0000
From:   Ralf Sinoradzki <sinoradz@student.uni-kl.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Steve Lord <lord@sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: Little Problem with XFS and Debian Woody
References: <200010031349.IAA16493@jen.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi !

I think, I have found out, why the dpkg-skripts
behave different on XFS and ext2fs.
'rmdir' returns different results on non-empty directories:

ext2fs: rmdir: `foo': Directory not empty
XFS:    rmdir foo -> rmdir: `foo': File exists

I have testet this with the beta-kernel-patch.
Don't know, if its the same with the latest snapshot.

I hope, this helps.

Ralf

From owner-linux-xfs@oss.sgi.com Tue Oct  3 12:01:10 2000
Received:  by oss.sgi.com id <S42481AbQJCTBB>;
	Tue, 3 Oct 2000 12:01:01 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38239 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42274AbQJCTAc>; Tue, 3 Oct 2000 12:00:32 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA08783
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 12:06:32 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA6177453; Tue, 3 Oct 2000 13:58:13 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id NAA34493; Tue, 3 Oct 2000 13:58:13 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id NAA10064;
	Tue, 3 Oct 2000 13:52:45 -0500
Message-Id: <200010031852.NAA10064@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Ralf Sinoradzki <sinoradz@student.uni-kl.de>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Little Problem with XFS and Debian Woody 
In-Reply-To: Message from Ralf Sinoradzki <sinoradz@student.uni-kl.de> 
   of "Tue, 03 Oct 2000 18:52:48 -0000." <39DA2B00.E51789F3@student.uni-kl.de> 
Date:   Tue, 03 Oct 2000 13:52:45 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> Hi !
> 
> I think, I have found out, why the dpkg-skripts
> behave different on XFS and ext2fs.
> 'rmdir' returns different results on non-empty directories:
> 
> ext2fs: rmdir: `foo': Directory not empty
> XFS:    rmdir foo -> rmdir: `foo': File exists
> 
> I have testet this with the beta-kernel-patch.
> Don't know, if its the same with the latest snapshot.
> 
> I hope, this helps.
> 
> Ralf

This will be the same between the two trees, here is some code to try out
and see if it fixes it:

===========================================================================
Index: linux/fs/xfs/xfs_vnodeops.c
===========================================================================

--- /usr/tmp/TmpDir.9993-0/linux/fs/xfs/xfs_vnodeops.c_1.475    Tue Oct  3 13:55:03 2000
+++ linux/fs/xfs/xfs_vnodeops.c Tue Oct  3 13:49:24 2000
@@ -4179,11 +4179,11 @@
        }
        ASSERT(cdp->i_d.di_nlink >= 2);
        if (cdp->i_d.di_nlink != 2) {
-               error = XFS_ERROR(EEXIST);
+               error = XFS_ERROR(ENOTEMPTY);
                goto error_return;
         }
        if (!XFS_DIR_ISEMPTY(mp, cdp)) {
-               error = XFS_ERROR(EEXIST);
+               error = XFS_ERROR(ENOTEMPTY);
                goto error_return;
        }

This does appear to be a difference between the system call error codes in
irix and linux.

Irix rmdir(2):

     EEXIST              The directory contains entries other than those for
                         ``.'' and ``..''.

Linux rmdir(2):

       ENOENT A directory component in pathname does not exist or
              is a dangling symbolic link.

       ENOTEMPTY
              pathname contains entries other than . and .. .


Thanks for the diagnosis, let me know if this fixes it.

Steve


From owner-linux-xfs@oss.sgi.com Tue Oct  3 12:24:31 2000
Received:  by oss.sgi.com id <S42276AbQJCTYV>;
	Tue, 3 Oct 2000 12:24:21 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:21309 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42274AbQJCTXl>;
	Tue, 3 Oct 2000 12:23:41 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA12641
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 12:14:56 -0700 (PDT)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA7139978 for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 14:20:09 -0500 (CDT)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id OAA35771 for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 14:20:09 -0500 (CDT)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.10.1/8.10.1) id e93JK8211719
	for linux-xfs@oss.sgi.com; Tue, 3 Oct 2000 14:20:08 -0500
Date:   Tue, 3 Oct 2000 14:20:08 -0500
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200010031920.e93JK8211719@gibble.americas.sgi.com>
Subject: TAKE - Remove extended attr calls from beta tree.
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


The beta tree does boot on a RH 7.0 system with these changes
removed.

Note it appears the 7.0 version of gpm doesn't work with
the beta kernel.

I'll try and track it down.


Date:  Tue Oct  3 12:14:48 PDT 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-beta

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-beta


Modid:  2.4.x-xfs-beta:slinx:75541a
linux/include/asm-sparc64/unistd.h - 1.11
linux/include/asm-sparc/unistd.h - 1.9
linux/include/asm-ppc/unistd.h - 1.9
linux/include/asm-mips/unistd.h - 1.7
linux/include/asm-m68k/unistd.h - 1.7
linux/include/asm-i386/unistd.h - 1.12
linux/include/asm-arm/unistd.h - 1.12
linux/include/asm-alpha/unistd.h - 1.11
linux/arch/sparc64/kernel/systbls.S - 1.17
linux/arch/sparc/kernel/systbls.S - 1.14
linux/arch/ppc/kernel/misc.S - 1.19
linux/arch/mips/kernel/syscalls.h - 1.7
linux/arch/mips/kernel/irix5sys.h - 1.6
linux/arch/m68k/kernel/entry.S - 1.10
linux/arch/i386/kernel/entry.S - 1.24
linux/arch/arm/kernel/calls.S - 1.11
linux/arch/alpha/kernel/entry.S - 1.15
linux/arch/sh/kernel/entry.S - 1.11
linux/include/asm-sh/unistd.h - 1.8
linux/arch/ia64/kernel/entry.S - 1.7
linux/arch/ia64/ia32/ia32_entry.S - 1.7
linux/include/asm-ia64/unistd.h - 1.6
linux/include/asm-mips64/unistd.h - 1.4
linux/arch/mips64/kernel/scall_64.S - 1.4
linux/include/asm-s390/unistd.h - 1.3
	- Remove added syscalls from beta tree.



From owner-linux-xfs@oss.sgi.com Tue Oct  3 12:42:31 2000
Received:  by oss.sgi.com id <S42474AbQJCTmV>;
	Tue, 3 Oct 2000 12:42:21 -0700
Received: from sun.rhrk.uni-kl.de ([131.246.137.50]:21653 "HELO
        sun.rhrk.uni-kl.de") by oss.sgi.com with SMTP id <S42274AbQJCTlm>;
	Tue, 3 Oct 2000 12:41:42 -0700
Received: from aixs1.rhrk.uni-kl.de
           ( exim@aixs1.rhrk.uni-kl.de [131.246.137.3] ) by sun.rhrk.uni-kl.de
          id aa01451 ; 3 Oct 2000 21:40 MESZ
Received: from trip210.wohnheim.uni-kl.de ([131.246.188.10] helo=student.uni-kl.de)
	by aixs1.rhrk.uni-kl.de with esmtp (Exim 3.03 #2)
	id 13gXvj-000HKw-00; Tue, 03 Oct 2000 21:40:48 +0200
Message-ID: <39DA36FF.82F46171@student.uni-kl.de>
Date:   Tue, 03 Oct 2000 19:43:59 +0000
From:   Ralf Sinoradzki <sinoradz@student.uni-kl.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Steve Lord <lord@sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: Little Problem with XFS and Debian Woody
References: <200010031852.NAA10064@jen.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi again :)

I've applied your patch and recompiled the kernel.
Now everythings works fine.

Thanks,
Ralf

From owner-linux-xfs@oss.sgi.com Tue Oct  3 12:49:30 2000
Received:  by oss.sgi.com id <S42482AbQJCTtV>;
	Tue, 3 Oct 2000 12:49:21 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:3140 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42274AbQJCTtA>;
	Tue, 3 Oct 2000 12:49:00 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA16580
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 12:40:33 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA7101334 for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 14:47:01 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id OAA38199 for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 14:47:00 -0500 (CDT)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id OAA19189
	for linux-xfs@oss.sgi.com; Tue, 3 Oct 2000 14:41:32 -0500
Date:   Tue, 3 Oct 2000 14:41:32 -0500
From:   Steve Lord <lord@sgi.com>
Message-Id: <200010031941.OAA19189@jen.americas.sgi.com>
Subject: TAKE - fix rmdir to return correct error on non empty dir
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Tue Oct  3 12:46:33 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:75546a
linux/fs/xfs/xfs_vnodeops.c - 1.476
	- fix error return values for rmdir to be correct for linux



From owner-linux-xfs@oss.sgi.com Tue Oct  3 13:00:01 2000
Received:  by oss.sgi.com id <S42483AbQJCT7v>;
	Tue, 3 Oct 2000 12:59:51 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:44133 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42274AbQJCT7P>; Tue, 3 Oct 2000 12:59:15 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA05230
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 13:05:36 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA7140344 for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 14:57:18 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id OAA39241 for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 14:57:18 -0500 (CDT)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id OAA19616
	for linux-xfs@oss.sgi.com; Tue, 3 Oct 2000 14:51:50 -0500
Date:   Tue, 3 Oct 2000 14:51:50 -0500
From:   Steve Lord <lord@sgi.com>
Message-Id: <200010031951.OAA19616@jen.americas.sgi.com>
Subject: TAKE - merge fix into beta tree
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Tue Oct  3 12:52:43 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-beta
Author:  lord
Merged by:  lord
Merged mods:  2.4.x-xfs:slinx:75546a

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-beta


Modid:  2.4.x-xfs-beta:slinx:75546a
linux/fs/xfs/xfs_vnodeops.c - 1.473
	- Merge of 2.4.x-xfs:slinx:75546a by lord.
	  fix error return values for rmdir to be correct for linux



From owner-linux-xfs@oss.sgi.com Tue Oct  3 15:00:40 2000
Received:  by oss.sgi.com id <S42485AbQJCWAU>;
	Tue, 3 Oct 2000 15:00:20 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:6515 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42274AbQJCV76>; Tue, 3 Oct 2000 14:59:58 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA05819
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 15:06:18 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA66106
	for linux-xfs@oss.sgi.com; Wed, 4 Oct 2000 08:57:58 +1100 (EST)
Date:   Wed, 4 Oct 2000 08:57:58 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010032157.IAA66106@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - version
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75555a
Date:  Tue Oct  3 14:57:37 PDT 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/CHANGELOG - 1.6
cmd/xfs/VERSION - 1.7
	- bump version number for external log format changes.


From owner-linux-xfs@oss.sgi.com Tue Oct  3 16:30:52 2000
Received:  by oss.sgi.com id <S42486AbQJCXam>;
	Tue, 3 Oct 2000 16:30:42 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:31236 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42274AbQJCXaR>;
	Tue, 3 Oct 2000 16:30:17 -0700
Received: from bruce.melbourne.sgi.com (root@bruce.melbourne.sgi.com [134.14.55.176]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA17552
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 16:21:51 -0700 (PDT)
	mail_from (fsgqa@bruce.melbourne.sgi.com)
Received: (from fsgqa@localhost)
	by bruce.melbourne.sgi.com (8.9.3/8.9.3) id KAA01258
	for linux-xfs@oss.sgi.com; Wed, 4 Oct 2000 10:28:32 +1100
Date:   Wed, 4 Oct 2000 10:28:32 +1100
From:   FSG QA <fsgqa@bruce.melbourne.sgi.com>
Message-Id: <200010032328.KAA01258@bruce.melbourne.sgi.com>
Subject: TAKE - fix for st.c
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Tue Oct  3 16:26:39 PDT 2000
Workarea:  bruce.melbourne.sgi.com:/home/fsgqa/qa-normal/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:75562a
linux/drivers/scsi/st.c - 1.24
	- patch to fix doubled up scsi devices problem in test8. This is fixed
	  in test9



From owner-linux-xfs@oss.sgi.com Tue Oct  3 18:00:02 2000
Received:  by oss.sgi.com id <S42484AbQJDA7w>;
	Tue, 3 Oct 2000 17:59:52 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:50815 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42274AbQJDA7Q>; Tue, 3 Oct 2000 17:59:16 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA07307
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 18:05:36 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA18736
	for linux-xfs@oss.sgi.com; Wed, 4 Oct 2000 11:57:16 +1100 (EST)
Date:   Wed, 4 Oct 2000 11:57:16 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200010040057.LAA18736@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - MOUNT_OPTIONS for qa
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75629a
Date:  Tue Oct  3 17:57:02 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/check - 1.12
cmd/xfs/stress/common.rc - 1.35
	- check $MOUNT_OPTIONS for extra options to specify on each mount


From owner-linux-xfs@oss.sgi.com Tue Oct  3 18:06:01 2000
Received:  by oss.sgi.com id <S42487AbQJDBFw>;
	Tue, 3 Oct 2000 18:05:52 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:64021 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42274AbQJDBFZ>;
	Tue, 3 Oct 2000 18:05:25 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA26626
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 17:56:59 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA22694 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 12:02:11 +1100
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id MAA22432 for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 12:02:10 +1100 (EST)
Message-Id: <200010040102.MAA22432@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
Subject: XFS mount options?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 04 Oct 2000 12:02:09 +1100
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Is there some reason that XFS ignores mount options it doesn't
know? Shouldn't it fail like ext2 does when it sees an unknown
option?

I can fix it, but perhaps theres a reason?

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Tue Oct  3 19:53:03 2000
Received:  by oss.sgi.com id <S42274AbQJDCww>;
	Tue, 3 Oct 2000 19:52:52 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23048 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42267AbQJDCwW>; Tue, 3 Oct 2000 19:52:22 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA08258
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 19:58:42 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA86944
	for linux-xfs@oss.sgi.com; Wed, 4 Oct 2000 13:50:19 +1100 (EST)
Date:   Wed, 4 Oct 2000 13:50:19 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200010040250.NAA86944@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xfs qa
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75635a
Date:  Tue Oct  3 19:49:41 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/004 - 1.6
	- use $AWK_PROG not awk

cmd/xfs/stress/040 - 1.3
	- use _notrun

cmd/xfs/stress/044 - 1.4
	- use _require_logdev

cmd/xfs/stress/common.config - 1.10
	- fix checking of $SCRATCH_DEV

cmd/xfs/stress/common.rc - 1.36
	- add _require_logdev, _notrun and fix _require_scratch

cmd/xfs/stress/group - 1.46
	- add test 045

cmd/xfs/stress/045 - 1.1
	- check mount of two FSes with identical UUIDs fails

cmd/xfs/stress/045.out - 1.1
	- output for 045


From owner-linux-xfs@oss.sgi.com Tue Oct  3 20:03:03 2000
Received:  by oss.sgi.com id <S42275AbQJDDCx>;
	Tue, 3 Oct 2000 20:02:53 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:39974 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42267AbQJDDC3>;
	Tue, 3 Oct 2000 20:02:29 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA05448
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 19:54:01 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA74337
	for linux-xfs@oss.sgi.com; Wed, 4 Oct 2000 14:00:25 +1100 (EST)
Date:   Wed, 4 Oct 2000 14:00:25 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200010040300.OAA74337@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: PARTIAL TAKE 797165 uuid rationalization
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75637a
Date:  Tue Oct  3 19:59:56 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/xfs_inode.c - 1.306
	- pv 797165 remove inactive code

linux/fs/xfs/xfs_mount.c - 1.243
	- pv 797165 fail mount on duplicate uuid

linux/fs/xfs/xfs_mount.h - 1.118
	- pv 797165 don't need copies of old/new uuid


From owner-linux-xfs@oss.sgi.com Tue Oct  3 20:34:02 2000
Received:  by oss.sgi.com id <S42287AbQJDDdw>;
	Tue, 3 Oct 2000 20:33:52 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:25642 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42267AbQJDDdZ>;
	Tue, 3 Oct 2000 20:33:25 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA07862
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 20:25:00 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id WAA7125038; Tue, 3 Oct 2000 22:31:00 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id WAA62292; Tue, 3 Oct 2000 22:31:00 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id WAA02102;
	Tue, 3 Oct 2000 22:25:29 -0500
Message-Id: <200010040325.WAA02102@jen.americas.sgi.com>
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS mount options? 
From:   lord@sgi.com
In-reply-to: Your message of "Wed, 04 Oct 2000 12:02:09 +1100
Date:   Tue, 03 Oct 2000 22:25:29 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
> Is there some reason that XFS ignores mount options it doesn't
> know? Shouldn't it fail like ext2 does when it sees an unknown
> option?
> 
> I can fix it, but perhaps theres a reason?
> 


I cannot think why not, Irix parses the options in user space and
passes a structure into the kernel, it could have either behavior
their, I think I have seen cases where it skipped bogus options,
but they were cxfs ones. In the normal xfs case I suspect it 
will fail the mount on a parsing error. The linux kernel code
should do the same.

Steve


From owner-linux-xfs@oss.sgi.com Tue Oct  3 20:44:22 2000
Received:  by oss.sgi.com id <S42283AbQJDDoM>;
	Tue, 3 Oct 2000 20:44:12 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:11274 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42267AbQJDDne>; Tue, 3 Oct 2000 20:43:34 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA00824
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 20:49:53 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA28024
	for linux-xfs@oss.sgi.com; Wed, 4 Oct 2000 14:40:17 +1100 (EST)
Date:   Wed, 4 Oct 2000 14:40:17 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200010040340.OAA28024@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fail on bad mount option
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75639a
Date:  Tue Oct  3 20:40:04 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/045 - 1.2
	- test for mount fail on bad mount option

cmd/xfs/stress/045.out - 1.2
	- rev

linux/fs/xfs/linux/xfs_mount_opt.c - 1.15
	- fail on bad mount option


From owner-linux-xfs@oss.sgi.com Tue Oct  3 20:45:53 2000
Received:  by oss.sgi.com id <S42297AbQJDDpn>;
	Tue, 3 Oct 2000 20:45:43 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29962 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42267AbQJDDpV>; Tue, 3 Oct 2000 20:45:21 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA02646
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 20:51:40 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA95423
	for linux-xfs@oss.sgi.com; Wed, 4 Oct 2000 14:42:05 +1100 (EST)
Date:   Wed, 4 Oct 2000 14:42:05 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200010040342.OAA95423@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - stress/src/usemem.c
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75640a
Date:  Tue Oct  3 20:41:47 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/src/Makefile - 1.18
	- add usemem

cmd/xfs/stress/src/usemem.c - 1.1
	- tool to allocate and lock chunk of memory


From owner-linux-xfs@oss.sgi.com Tue Oct  3 21:23:13 2000
Received:  by oss.sgi.com id <S42314AbQJDEXD>;
	Tue, 3 Oct 2000 21:23:03 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:36107 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42267AbQJDEW2>; Tue, 3 Oct 2000 21:22:28 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA03081
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 21:28:46 -0700 (PDT)
	mail_from (ajag@snort.melbourne.sgi.com)
Received: (from ajag@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA19873
	for linux-xfs@oss.sgi.com; Wed, 4 Oct 2000 15:20:25 +1100 (EST)
Date:   Wed, 4 Oct 2000 15:20:25 +1100 (EST)
From:   Andrew Gildfind <ajag@snort.melbourne.sgi.com>
Message-Id: <200010040420.PAA19873@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - 
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75642a
Date:  Tue Oct  3 21:19:50 PDT 2000
Workarea:  snort:/build5/ajag/slinx
Author:  ajag

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/src/fill2.c - 1.2
cmd/xfs/stress/src/fill2fs - 1.3
cmd/xfs/stress/src/fill2fs_check - 1.2
	- Add copyrights.


From owner-linux-xfs@oss.sgi.com Tue Oct  3 21:38:24 2000
Received:  by oss.sgi.com id <S42304AbQJDEiO>;
	Tue, 3 Oct 2000 21:38:14 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:4146 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42267AbQJDEhn>;
	Tue, 3 Oct 2000 21:37:43 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA12240; Tue, 3 Oct 2000 21:29:18 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id VAA03870;
	Tue, 3 Oct 2000 21:37:00 -0700 (PDT)
Date:   Tue, 3 Oct 2000 21:37:00 -0700 (PDT)
Message-Id: <200010040437.VAA03870@info.engr.sgi.com>
X-Pv-Incident: 797165 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: ADD 797165 - rationalise uuid kernel code for XFS
To:     dxm@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797165

 Status : open                         Priority : 4                         
 Assigned Engineer : dxm               Submitter : nathans                  
*Modified User : dxm                  *Modified User Domain : engr          
*Description :
stick this in a bug so it isn't forgotten...

On Jul 21,  8:40am, Nathan Scott wrote:
> Subject: Re: LVM vs. kiobuf I/O
> > >         - Kernel uuid generation support
> > ...
> ...
> 
> I think there's a bunch of stuff which can be rationalised
> there too...

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: dxm@engr (BugWorks)
Date: Oct 03 2000 09:36:59PM
==========================


Modid:  2.4.x-xfs:slinx:75637a
Date:  Tue Oct  3 19:59:56 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/xfs_inode.c - 1.306
	- pv 797165 remove inactive code

linux/fs/xfs/xfs_mount.c - 1.243
	- pv 797165 fail mount on duplicate uuid

linux/fs/xfs/xfs_mount.h - 1.118
	- pv 797165 don't need copies of old/new uuid

From owner-linux-xfs@oss.sgi.com Tue Oct  3 21:46:13 2000
Received:  by oss.sgi.com id <S42489AbQJDEqE>;
	Tue, 3 Oct 2000 21:46:04 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:48434 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42267AbQJDEpk>;
	Tue, 3 Oct 2000 21:45:40 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA12696; Tue, 3 Oct 2000 21:37:11 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id VAA22820;
	Tue, 3 Oct 2000 21:44:54 -0700 (PDT)
Date:   Tue, 3 Oct 2000 21:44:54 -0700 (PDT)
Message-Id: <200010040444.VAA22820@info.engr.sgi.com>
X-Pv-Incident: 797165 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: CLOSE 797165 - rationalise uuid kernel code for XFS
To:     dxm@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797165

*Status : closed                       Priority : 4                         
 Assigned Engineer : dxm               Submitter : nathans                  
 Opened Date : 07/24/00               *Closed Date : 10/03/00               
*Fixed By : dxm                       *Fixed By Domain : engr               
*Modified Date : 10/03/00             *Modified User : dxm                  
*Modified User Domain : engr          *Fix Description :
==========================
ADDITIONAL INFORMATION (CLOSE)
From: dxm@engr (BugWorks)
Date: Oct 03 2000 09:44:53PM
==========================

I've moved the unused stuff to the end of the file and 
#if'd it out on Steve's advice. This way it's easier to
find when it's needed again elsewhere.

Modid:  2.4.x-xfs:slinx:75643a
Date:  Tue Oct  3 21:43:41 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/linux/xfs_super.c - 1.93
        - pv 797165 remove call to uuid_init

linux/fs/xfs/linux/xfs_uuid.c - 1.22
        - pv 797165 move unused stuff out of the way. rewrite uuid_getnodeuniq
          so it's endian safe

linux/fs/xfs/linux/xfs_uuid.h - 1.2
        - pv 797165 hide unused stuff

From owner-linux-xfs@oss.sgi.com Tue Oct  3 22:28:44 2000
Received:  by oss.sgi.com id <S42490AbQJDF2e>;
	Tue, 3 Oct 2000 22:28:34 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:61751 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42267AbQJDF1z>;
	Tue, 3 Oct 2000 22:27:55 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA15797
	for <linux-xfs@oss.sgi.com>; Tue, 3 Oct 2000 22:19:19 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA03104
	for linux-xfs@oss.sgi.com; Wed, 4 Oct 2000 16:25:45 +1100 (EST)
Date:   Wed, 4 Oct 2000 16:25:45 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200010040525.QAA03104@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - logprint
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75645a
Date:  Tue Oct  3 22:25:37 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/logprint/log_misc.c - 1.72
cmd/xfs/logprint/log_print_trans.c - 1.35
	- fix handling of other format logs


From owner-linux-xfs@oss.sgi.com Tue Oct  3 22:29:14 2000
Received:  by oss.sgi.com id <S42491AbQJDF3E>;
	Tue, 3 Oct 2000 22:29:04 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:56 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42267AbQJDF2l>;
	Tue, 3 Oct 2000 22:28:41 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA15828; Tue, 3 Oct 2000 22:20:16 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA02056;
	Tue, 3 Oct 2000 22:27:58 -0700 (PDT)
Date:   Tue, 3 Oct 2000 22:27:58 -0700 (PDT)
Message-Id: <200010040527.WAA02056@info.engr.sgi.com>
X-Pv-Incident: 802017 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: REOPEN 802017 - ASSERT fail in xlog_get_bp on small mem machine
To:     dxm@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017

*Status : open                         Priority : 3                         
 Assigned Engineer : dxm               Submitter : dxm                      
 Project : xfs-linux                   Assigned Group : xfs-linux           
 Opened Date : 09/17/00               *Closed Date :                        
*Fixed By :                           *Fixed By Domain :                    
*Verified Date :                      *Modified User : dxm                  
*Modified User Domain : engr          *Description :
I haven't seen this problem for ages on my 64Mb crash box,
but the problem is still there.

I installed XFS on my home machine last night and was very
happy with its performance (P100, 32Mb RAM, 32Gb disk) until 
I tried to cleanly remount my XFS partition and tripped an 
ASSERT in xlog_get_bp.

My home machine is very tight on memory, but I don't think
it's an unreasonable machine to try to run XFS on. Unfortunately,

.....


==========================
ADDITIONAL INFORMATION (REOPEN)
From: dxm@engr (BugWorks)
Date: Oct 03 2000 10:27:57PM
==========================

This fix has slowed down the usual case (non-small-mem machine)
and could be made faster.

From owner-linux-xfs@oss.sgi.com Tue Oct  3 22:41:23 2000
Received:  by oss.sgi.com id <S42492AbQJDFlO>;
	Tue, 3 Oct 2000 22:41:14 -0700
Received: from lips.borg.umn.edu ([160.94.232.50]:54792 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S42267AbQJDFkm>;
	Tue, 3 Oct 2000 22:40:42 -0700
Received: from thebarn.com (boyne.borg.umn.edu [160.94.232.8])
	by lips.borg.umn.edu (8.11.0/8.10.1) with ESMTP id e945dgI07220;
	Wed, 4 Oct 2000 00:39:42 -0500 (CDT)
Message-ID: <39DAC29C.9F7E0435@thebarn.com>
Date:   Wed, 04 Oct 2000 00:39:41 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.6 [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: XFS mount options?
References: <200010040102.MAA22432@clouds.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Daniel Moore wrote:

> Is there some reason that XFS ignores mount options it doesn't
> know? Shouldn't it fail like ext2 does when it sees an unknown
> option?

It's a broken mess!

I've banged my head again this one before.


>
>
> I can fix it, but perhaps theres a reason?

Sure... want to fix the irix version also? :-)

>
>
> -----------------------------------------------------
>  Daniel Moore                  dxm@sgi.com
>  R&D Software Engineer         Phone: +61-3-98348209
>  SGI Performance Tools Group   Fax:   +61-3-98132378
> -----------------------------------------------------

--
Russell Cattelan




From owner-linux-xfs@oss.sgi.com Tue Oct  3 22:58:55 2000
Received:  by oss.sgi.com id <S42493AbQJDF6p>;
	Tue, 3 Oct 2000 22:58:45 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57614 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42267AbQJDF6K>; Tue, 3 Oct 2000 22:58:10 -0700
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA02958; Tue, 3 Oct 2000 23:04:32 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id WAA97555; Tue, 3 Oct 2000 22:57:29 -0700 (PDT)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id WAA75268;
	Tue, 3 Oct 2000 22:56:11 -0700 (PDT)
Date:   Tue, 3 Oct 2000 22:56:11 -0700 (PDT)
Message-Id: <200010040556.WAA75268@info.engr.sgi.com>
X-Pv-Incident: 797165 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: ADD 797165 - rationalise uuid kernel code for XFS
To:     dxm@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=797165

 Status : closed                       Priority : 4                         
 Assigned Engineer : dxm               Submitter : nathans                  
*Modified User : dxm                  *Modified User Domain : engr          
*Description :
stick this in a bug so it isn't forgotten...

On Jul 21,  8:40am, Nathan Scott wrote:
> Subject: Re: LVM vs. kiobuf I/O
> > >         - Kernel uuid generation support
> > ...
> ...
> 
> I think there's a bunch of stuff which can be rationalised
> there too...

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: dxm@engr (BugWorks)
Date: Oct 03 2000 10:56:10PM
==========================

Modid:  2.4.x-xfs:slinx:75647a
Date:  Tue Oct  3 22:55:57 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/include/xfs_mount.h - 1.4
        - pv 797165 match kernel header

From owner-linux-xfs@oss.sgi.com Tue Oct  3 23:19:14 2000
Received:  by oss.sgi.com id <S42494AbQJDGTF>;
	Tue, 3 Oct 2000 23:19:05 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24591 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42267AbQJDGSe>; Tue, 3 Oct 2000 23:18:34 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA03032; Tue, 3 Oct 2000 23:24:56 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id XAA96642;
	Tue, 3 Oct 2000 23:17:52 -0700 (PDT)
Date:   Tue, 3 Oct 2000 23:17:52 -0700 (PDT)
Message-Id: <200010040617.XAA96642@info.engr.sgi.com>
X-Pv-Incident: 802017 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: CLOSE 802017 - ASSERT fail in xlog_get_bp on small mem machine
To:     dxm@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017

*Status : closed                       Priority : 3                         
 Assigned Engineer : dxm               Submitter : dxm                      
 Opened Date : 09/17/00               *Closed Date : 10/03/00               
*Fixed By : dxm                       *Fixed By Domain : engr               
*Modified Date : 10/03/00             *Modified User : dxm                  
*Modified User Domain : engr          *Fix Description :
==========================
ADDITIONAL INFORMATION (CLOSE)
From: dxm@engr (BugWorks)
Date: Sep 25 2000 05:59:42PM
==========================

Modid:  2.4.x-xfs:slinx:75004a
Date:  Mon Sep 25 17:59:23 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs-tot
Author:  dxm

.....


==========================
ADDITIONAL INFORMATION (CLOSE)
From: dxm@engr (BugWorks)
Date: Oct 03 2000 11:17:51PM
==========================

Modid:  2.4.x-xfs:slinx:75648a
Date:  Tue Oct  3 23:17:04 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/logprint/xfs_log_recover.c - 1.5
        - pv 802017 match kernel code

cmd/xfs/stress/044 - 1.5
cmd/xfs/stress/044.out - 1.3
        - pv 802017 add test for large dirty log recover

linux/fs/xfs/xfs_log_recover.c - 1.194
        - pv 802017 add fast path - most of the time we'll get the full buffers
          we want, so try to do single large buffer reads/writes first.

~

From owner-linux-xfs@oss.sgi.com Wed Oct  4 00:01:45 2000
Received:  by oss.sgi.com id <S42495AbQJDHBf>;
	Wed, 4 Oct 2000 00:01:35 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42256 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42267AbQJDHBD>; Wed, 4 Oct 2000 00:01:03 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA07151
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 00:07:18 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA94570
	for linux-xfs@oss.sgi.com; Wed, 4 Oct 2000 17:57:42 +1100 (EST)
Date:   Wed, 4 Oct 2000 17:57:42 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010040657.RAA94570@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - cmds
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Still a bunch of warnings from a redhat 7 commands build
- I'll look at them tomorrow.  This gets Makepkgs functional
again.


Modid:  2.4.x-xfs:slinx:75651a
Date:  Tue Oct  3 23:56:12 PDT 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/configure.in - 1.16
	- fix the rh7 man page build problem.


From owner-linux-xfs@oss.sgi.com Wed Oct  4 00:12:35 2000
Received:  by oss.sgi.com id <S42496AbQJDHMZ>;
	Wed, 4 Oct 2000 00:12:25 -0700
Received: from thorium.uunet.be ([194.7.1.46]:15880 "EHLO thorium.uunet.be")
	by oss.sgi.com with ESMTP id <S42267AbQJDHLx>;
	Wed, 4 Oct 2000 00:11:53 -0700
Received: from gate.vum.be (firewall.vum.be [194.7.240.162])
	by thorium.uunet.be (8.9.1/8.9.3) with SMTP id JAA16862
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 09:11:11 +0200 (CEST)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id JAA21801 for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 09:12:54 +0200 (METDST)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id JAA32308
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 09:10:39 +0200
Message-ID: <39DAD7EF.2DD1D715@vum.be>
Date:   Wed, 04 Oct 2000 09:10:39 +0200
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - add kgcc line for RH 7.0
References: <200010022143.e92LhPH00355@gibble.americas.sgi.com> <20001003141140.A25453@gruyere.muc.suse.de> <news2mail-8rcva2$m81$2@mate.bln.innominate.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

VGhvbWFzIEdyYWljaGVuIHdyb3RlOg0KDQo+DQo+DQo+ID4gQ291bGQgeW91IHBsZWFzZSBw
dXQgc29tZXdoZXJlIGludG8gdGhlIFhGUyBCZXRhIG1vZHVsZSBzb21ldGhpbmcgbGlrZQ0K
Pg0KPiA+ICNpZiBfX0dOVUNfXz09MiAmJiBfX0dOVUNfTUlOT1JfXz09OTUNCj4gPiAjZXJy
b3IgImRvZXMgbm90IGNvbXBpbGUgcHJvcGVybHkgd2l0aCBnY2MgMi45NS4gZ2V0IGVnY3Mg
MS4xLiINCj4gPiAjZW5kaWYNCj4NCj4gPiBUaGlzIHNob3VsZCBzYXZlIHRoZSB1c2VycyBv
ZiBkaXN0cmlidXRpb25zIHdoaWNoIGNvbWUgd2l0aA0KPiA+IDIuOTUgYnkgZGVmYXVsdCAo
U3VTRSwgbmV3ZXIgRGViaWFuLCBwcm9iYWJseSBvdGhlcnMpIHNvbWUgZ3JpZWYgYW5kIHlv
dQ0KPiA+IG1hbnkgYnVnIHJlcG9ydHMuIE5vdCBhbGwgdGhlIHdvcmxkIGlzIFJlZEhhdC4N
Cg0KSSB3b25kZXIgd2hhdCB0aGUgcHJvYmxlbSBpcyAuLi4NCiMgZ2NjIC0tdmVyc2lvbg0K
IDIuOTUuMg0KDQpBbmQgSSBoYXZlIGJ1aWx0IGFsbCB2ZXJzaW9ucyBzaW5jZSB0aGUgZmly
c3Qgb3NzIHJlbGVhc2Ugb2YgWEZTLi4uID8NCkkgaGF2ZW50IG1ldCBhbnkgcHJvYmxlbXMg
Li4uIGRvaW5nIGp1c3QgYW4gWEZTIGNvbXBpbGUuLi4NCkkgYmVsaWV2ZSB0aGUgaXNzdWVz
IGFyZSBtb3JlIGNvbmNlcm5pbmcga2RiIGFuZCB0aGUgbGlrZXMuLi4gSSBrbm93IGRlY2Vu
dA0KZGVidWdnaW5nIGNhbnQgYmUgZG9uZSB3aXRob3V0IGl0IC4uLg0KQXMgSSBhbSBubyBw
cm9ncmFtbWVyLi4uIG15IGNvbnRyaWJ1dGlvbiBpcyBvbmx5IHZhbGlkIGZvciBwZXJmb3Jt
YW5jZSBhbmQNCnN0YWJpbGl0eSB0ZXN0aW5nLg0KDQpCdXQgWEZTIGNvbXBpbGVzIGZpbmUg
Li4uIGFuZCB3b3JrcyBzdGFibGUuLi4NCkkgZ290IGF0IGhvbWUgcmVjZW50bHkgcmVtYWRl
IGEgTGludXggdXNpbmcgdGhlIG1vc3QgcmVjZW50IE1hbmRyYWtlIGRpc3QsDQp3aXRoIGEg
ZmV3IG1pbm9yIHByb2JsZW1zIChuZWVkZWQgdG8gdXBkYXRlIHNvbWUgc3R1ZmYgbGlrZSBt
b2R1dGlscywgcnBtIGFuZA0KZTJmc3Byb2ctZGV2IC4uLikgIGFuZCBidWlsdCBzdWNjZXNz
ZnVsbHkgdGhlIHRyZWUgdGhhdCB3YXMgY3VycmVudCBsYXN0DQpmcmlkYXkuLi4NCg0KSGVy
ZSBhdCB3b3JrIEkgZG8gYSBidWlsZCBldmVyeSBkYXkgYWZ0ZXIgdXBkYXRpbmcgd2l0aCBj
dnMuLi4gd2l0aA0KZ2NjLTIuOTUuMi4uLiBhbmQgaGF2ZSBubyBpc3N1ZXNzIHdoYXRzb2V2
ZXIuLi4NCg0Kc28gSSB3b3VsZCBhZHZpc2UgcGVvcGxlIHRvIHVzZSB0aGUgY29ycmVjdCBn
Y2MgaWYgdGhleSByZWFsbHkgd2FudCB0byB0ZXN0DQphbmQgaGVscCBkZWJ1ZyB0aGUgWEZT
IGNvZGUgLi4uIGJ1dCB0byBnaXZlIGl0ICBhIHNwaW4gdG8gc2VlIHdoYXQgaXRzDQp3b3J0
aC4uLiBhbnkgZ2NjIHNob3VsZCBkbyBpZiBpdHMgYSBiaXQgcmVjZW50Li4uDQoNCg0KDQpn
cmVldGluZ3MuLi4gYW5kIGtlZXAgdXAgdGhlIGdvb2Qgd29yaw0KDQpwLnMuIEkgaGF2ZSBh
IERFTEwgcG93ZXJlZGdlIHNlcnZlciB3aXRoIGhhcmR3YXJlIHJhaWQgY29udHJvbGxlciAu
Li4gaXQgaGFzDQphIGRhdGEgcGFydGl0aW9uIHdpdGggWEZTIGFuZCBvbiBpdCBzaXRzIGFu
IE9yYWNsZSBEQi4uLiBpdCBoYXNudCBoYWQgYW55DQp0cm91YmxlIHNpbmNlIDEtMSw1IG1v
bnRocyBvbmx5IHVwZ3JhZGluZyB0aGUgdmVyc2lvbiB3aGVuIHRoZSB0ZXN0IGJ1aWxkDQp3
b3JrcyBhbmQgcHJvdmVzIHRvIGJlIHN0YWJsZSB1bmRlciBhIGZldyBkaXNrdGVzdCBydW5z
Li4uDQpQZXJmb3JtYW5jZSBpcyBub3QgYmV0dGVyIHRoYW4gZXh0MiBidXQgcmVib290aW5n
IGFmdGVyIGZhaWx1cmUgaXMgYSBkcmVhbQ0KLi4uIEkgaGF2ZSBzaW11bGF0ZWQgbG9jay11
cHMsIHBvd2VyIGZhaWxsdXJlcyAuLi4gdGhlIDUwR0J5dGUgcGFydGl0aW9uDQp3b3VsZCB0
YWtlICszMCBtaW51dGVzIHRvIGZzY2sgb24gZXh0Miwgd2l0aCBYRlMgaXQgaXMgbWVyZSBz
ZWNvbmRzIHRvIGJlIHVwDQphbmQgcnVubmluZyBhZ2Fpbi4NCihidXQgSSBiZWxpZXZlIHdl
IHNob3VsZCBzZWUgYSBwZXJmb3JtYW5jZSBpbmNyZWFzZSB3aGVuIHRoZSB0cmVlIHdpbGwg
bW92ZQ0KdG8gdGVzdDkgb3IgaGlnaGVyKQ0K

From owner-linux-xfs@oss.sgi.com Wed Oct  4 04:49:49 2000
Received:  by oss.sgi.com id <S42252AbQJDLtj>;
	Wed, 4 Oct 2000 04:49:39 -0700
Received: from edge.coltex.nl ([194.151.97.115]:18186 "EHLO lsinet.coltex.nl")
	by oss.sgi.com with ESMTP id <S42239AbQJDLtM>;
	Wed, 4 Oct 2000 04:49:12 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by lsinet.coltex.nl (8.10.0/8.9.3) with ESMTP id e94BmBE04918
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 13:48:11 +0200
Message-Id: <4.3.2.7.2.20001004131050.02875f28@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Wed, 04 Oct 2000 13:47:36 +0200
To:     linux-xfs@oss.sgi.com
From:   Seth Mos <knuffie@xs4all.nl>
Subject: Kernel patch for 2.4.0-test9
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

No warranty.

I had some stuff deciding the order in arch/i386/kernel/entry.S about the 
numbers.
I have kept them sync to the other files where I noticed them.

That should be checked.

http://www.xs4all.nl/~knuffie/kernel/

I have to test compile this tree to make sure.
But I think there could only be "minor" issues. ;-) (ugh)

I have patch against the CVS tree of this morning and a clean patch against 
a clean 2.4.0-test9.

Bye
--
Seth
"Have you gone mad?"
"Well, yes, but that's beyond the scope of this email."


From owner-linux-xfs@oss.sgi.com Wed Oct  4 04:52:58 2000
Received:  by oss.sgi.com id <S42259AbQJDLwt>;
	Wed, 4 Oct 2000 04:52:49 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:25955 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42239AbQJDLwa>;
	Wed, 4 Oct 2000 04:52:30 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id EAA10107
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 04:44:04 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id WAA23901;
	Wed, 4 Oct 2000 22:51:22 +1100
Date:   Wed, 4 Oct 2000 22:51:22 +1100
From:   Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200010041151.WAA23901@sherman.melbourne.sgi.com>
Subject: TAKE - Upgrade xfs test to kdb v1.5
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Upgrade xfs test to kdb v1.5.  This includes the NMI oopser for
uniprocessors, see Documentation/nmi_watchdog.txt.  This update also
includes dummy versions of include/asm-xxx/kdb.h so you should be able
to compile XFS without kdb compile errors on any architecture using
CONFIG_KDB=n.  CONFIG_KDB=y is only supported for i386.


Date:  Wed Oct  4 04:42:46 PDT 2000
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:75658a
linux/mm/vmalloc.c - 1.21
linux/kernel/sysctl.c - 1.30
linux/kernel/module.c - 1.16
linux/kernel/ksyms.c - 1.61
linux/kernel/Makefile - 1.19
linux/init/main.c - 1.41
linux/include/linux/sysctl.h - 1.27
linux/include/linux/module.h - 1.14
linux/include/asm-i386/ptrace.h - 1.6
linux/include/asm-i386/msr.h - 1.7
linux/include/asm-i386/keyboard.h - 1.7
linux/drivers/video/vgacon.c - 1.11
linux/drivers/char/serial.c - 1.32
linux/drivers/char/keyboard.c - 1.19
linux/drivers/char/Makefile - 1.35
linux/arch/sparc64/vmlinux.lds - 1.8
linux/arch/sparc/vmlinux.lds - 1.8
linux/arch/ppc/vmlinux.lds - 1.7
linux/arch/m68k/vmlinux.lds - 1.8
linux/arch/i386/vmlinux.lds - 1.11
linux/arch/i386/kernel/traps.c - 1.27
linux/arch/i386/kernel/smp.c - 1.27
linux/arch/i386/kernel/setup.c - 1.36
linux/arch/i386/kernel/process.c - 1.25
linux/arch/i386/kernel/irq.c - 1.30
linux/arch/i386/kernel/io_apic.c - 1.20
linux/arch/i386/kernel/entry.S - 1.25
linux/arch/i386/kernel/apm.c - 1.26
linux/arch/i386/config.in - 1.47
linux/arch/i386/Makefile - 1.17
linux/Makefile - 1.69
linux/Documentation/Configure.help - 1.61
linux/include/asm-i386/apic.h - 1.9
linux/include/asm-i386/hw_irq.h - 1.17
linux/arch/i386/kernel/i8259.c - 1.18
linux/arch/i386/kernel/semaphore.c - 1.12
linux/arch/arm/vmlinux-armv.lds.in - 1.10
linux/arch/arm/vmlinux-armo.lds.in - 1.10
linux/arch/sh/vmlinux.lds.S - 1.9
linux/arch/m68k/vmlinux-sun3.lds - 1.5
linux/arch/i386/kernel/smpboot.c - 1.15
linux/Documentation/nmi_watchdog.txt - 1.3
linux/arch/i386/kernel/apic.c - 1.11
linux/arch/i386/kernel/msr.c - 1.3
linux/Documentation/kdb/kdb_rd.man - 1.5
linux/Documentation/kdb/kdb_env.man - 1.4
linux/kdb/kdb_bt.c - 1.6
linux/Documentation/kdb/kdb_ll.man - 1.4
linux/kdb/kdb_bp.c - 1.6
linux/kdb/modules/kdbm_vm.c - 1.9
linux/kdb/Makefile - 1.5
linux/include/linux/kdbprivate.h - 1.6
linux/Documentation/kdb/kdb_md.man - 1.5
linux/include/linux/kdb.h - 1.9
linux/kdb/modules/Makefile - 1.8
linux/kdb/kdbsupport.c - 1.6
linux/kdb/kdbmain.c - 1.11
linux/include/linux/dis-asm.h - 1.4
linux/include/asm-i386/kdb.h - 1.5
linux/kdb/kdb_io.c - 1.6
linux/Documentation/kdb/kdb_ss.man - 1.4
linux/include/asm-i386/kdbprivate.h - 1.6
linux/arch/i386/kdb/kdba_id.c - 1.5
linux/Documentation/kdb/kdb.mm - 1.9
linux/Documentation/kdb/kdb_bp.man - 1.5
linux/Documentation/kdb/kdb_bt.man - 1.6
linux/kdb/kdb_id.c - 1.5
linux/arch/i386/kdb/kdbasupport.c - 1.9
linux/arch/i386/kdb/i386-dis.c - 1.5
linux/arch/i386/kdb/kdba_io.c - 1.7
linux/arch/i386/kdb/Makefile - 1.7
linux/arch/i386/kdb/kdba_bt.c - 1.9
linux/arch/i386/kdb/kdba_bp.c - 1.7
linux/kernel/kallsyms.c - 1.4
linux/include/linux/kallsyms.h - 1.4
linux/kdb/modules/kdbm_pg.c - 1.20
linux/arch/alpha/vmlinux.lds.in - 1.3
linux/include/asm-alpha/kdb.h - 1.2
linux/include/asm-arm/kdb.h - 1.2
linux/include/asm-generic/kdb.h - 1.2
linux/include/asm-ia64/kdb.h - 1.2
linux/include/asm-m68k/kdb.h - 1.2
linux/include/asm-mips/kdb.h - 1.2
linux/include/asm-mips64/kdb.h - 1.2
linux/include/asm-ppc/kdb.h - 1.2
linux/include/asm-s390/kdb.h - 1.2
linux/include/asm-sh/kdb.h - 1.2
linux/include/asm-sparc/kdb.h - 1.2
linux/include/asm-sparc64/kdb.h - 1.2
linux/kdb/ChangeLog - 1.2
linux/kdb/kdb_cmds - 1.2


From owner-linux-xfs@oss.sgi.com Wed Oct  4 04:57:49 2000
Received:  by oss.sgi.com id <S42267AbQJDL5j>;
	Wed, 4 Oct 2000 04:57:39 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16666 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42239AbQJDL5Y>; Wed, 4 Oct 2000 04:57:24 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id FAA08787
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 05:03:45 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id WAA23991;
	Wed, 4 Oct 2000 22:56:38 +1100
Date:   Wed, 4 Oct 2000 22:56:38 +1100
From:   Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200010041156.WAA23991@sherman.melbourne.sgi.com>
Subject: TAKE - Upgrade xfs test to kdb v1.5
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Missed one file.

Date:  Wed Oct  4 04:52:30 PDT 2000
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:75659a
linux/arch/i386/kernel/i386_ksyms.c - 1.31


From owner-linux-xfs@oss.sgi.com Wed Oct  4 06:39:21 2000
Received:  by oss.sgi.com id <S42288AbQJDNjK>;
	Wed, 4 Oct 2000 06:39:10 -0700
Received: from edge.coltex.nl ([194.151.97.115]:56077 "EHLO lsinet.coltex.nl")
	by oss.sgi.com with ESMTP id <S42239AbQJDNij>;
	Wed, 4 Oct 2000 06:38:39 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by lsinet.coltex.nl (8.10.0/8.9.3) with ESMTP id e94DblE05312
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 15:37:47 +0200
Message-Id: <4.3.2.7.2.20001004153027.027c9f18@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Wed, 04 Oct 2000 15:37:12 +0200
To:     linux-xfs@oss.sgi.com
From:   Seth Mos <knuffie@xs4all.nl>
Subject: Patch for test9
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

OK it sucked.

Should have a better (working) one soon.
Build testing it first.

Slight miscalculation. Sorry.
(pledge for forgiveness)

Next time I will build it before I bug all of you.

Bye
--
Seth
"Have you gone mad?"
"Well, yes, but that's beyond the scope of this email."


From owner-linux-xfs@oss.sgi.com Wed Oct  4 06:56:20 2000
Received:  by oss.sgi.com id <S42309AbQJDN4L>;
	Wed, 4 Oct 2000 06:56:11 -0700
Received: from cmbsyb.hqw.ihs.gov ([161.223.90.2]:54793 "EHLO
        cmbsyb.hqw.ihs.gov") by oss.sgi.com with ESMTP id <S42239AbQJDNzo>;
	Wed, 4 Oct 2000 06:55:44 -0700
Received: from mplaptop ([161.223.91.138]) by cmbsyb.hqw.ihs.gov (AIX4.2/UCB 8.7/8.7) with SMTP id HAA47472 for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 07:53:43 -0600 (MDT)
Message-ID: <003c01c02e0a$b1d8cce0$8a5bdfa1@hqw.ihs.gov>
From:   "Michael Pike" <mpike@iqintermedia.com>
To:     "XFS Mailing List" <linux-xfs@oss.sgi.com>
Subject: Redhat RPM Builds on SMP Platform
Date:   Wed, 4 Oct 2000 07:55:02 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Greetings all... let me first say you are the biggest bunch of geniouses I
have met :)  After messing with several large file system packages for
Linux, XFS, even though in beta, has been the best out of them all, and a
true life saver in my organization! :)

The docs on the page were great, and the install went perfect... and XFS is
what I am pushing to all of our clients (and we have a lot).

I do have one question though, my expertise does not lie in Kernel
compilations and such, so here we go....

On our production machine we run VMWare for thin client access.... after I
installed the Kernel 2.4.test with XFS support from the RPMS rpms on the sgi
website, the system came up, and ran fine... VMWare needed to be recompiled
though... so, during the recompile it tells me the Kernel headers I have are
not compatible with my current running Kernel (I was at 2.2.14 - now at
2.4.test-XFSi686smp) which makes sense... so when I loaded the
xfsi386kernelheaders.rpm file, and tried to compile again, I got the same
error message, only this time is said the headers were for 2.4.test-XFSi386,
and I was running 2.4.testi686SMP)  (the key being here SMP)...

Do you guys have available kernel headers for the SMP kernel, or should I go
ahead and just use the single processor kernel and stick with the stock
kernel header rpms?

It's a Dell PowerEdge 6300, 1 gig of ram, and 4 18 gig drives, dual PIII
Xeon's... I would prefer to keep the SMP, but the file size issue is more
important at this stage so I could give up SMP if I had to...

Any help appreciated, and keep up the great work!

Mike



From owner-linux-xfs@oss.sgi.com Wed Oct  4 06:59:40 2000
Received:  by oss.sgi.com id <S42239AbQJDN7b>;
	Wed, 4 Oct 2000 06:59:31 -0700
Received: from hermes.mixx.net ([212.84.196.2]:54024 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S42316AbQJDN7M>;
	Wed, 4 Oct 2000 06:59:12 -0700
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id AF2EEF802
	for <linux-xfs@oss.sgi.com>; Wed,  4 Oct 2000 15:58:15 +0200 (CEST)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 005B72CA6D; Wed,  4 Oct 2000 15:58:14 +0200 (CEST)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: Patch for test9
Date:   4 Oct 2000 13:58:14 GMT
Organization: innominate AG, Berlin, Germany
Lines:  25
Distribution: local
Message-ID: <news2mail-8rfd1m$bdr$1@mate.bln.innominate.de>
References: <4.3.2.7.2.20001004153027.027c9f18@pop.xs4all.nl>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 970667894 11707 10.0.0.69 (4 Oct 2000 13:58:14 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-test8 (i586))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Seth Mos <knuffie@xs4all.nl> wrote:
> OK it sucked.

> Should have a better (working) one soon.
> Build testing it first.

> Slight miscalculation. Sorry.
> (pledge for forgiveness)

> Next time I will build it before I bug all of you.

but be careful with this ... if i remember coccretly - there are big
changes in the vm (at least steve said so) whichdoes not make it trivial
to port it from test8 to test9 - so it might be more required aside
from getting the rejects fixed ... just wanted to point this out be-
fore you waste a lot time ... but steve may have more details or prove
me wrong in this :-)

t

-- 
thomas.graichen@innominate.de
technical director                                       innominate AG
clustering & security                                networking people
tel: +49.30.308806-13  fax: -77                   http://innominate.de

From owner-linux-xfs@oss.sgi.com Wed Oct  4 07:03:00 2000
Received:  by oss.sgi.com id <S42320AbQJDOCv>;
	Wed, 4 Oct 2000 07:02:51 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:6262 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42316AbQJDOC1>;
	Wed, 4 Oct 2000 07:02:27 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA19679
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 06:53:52 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id IAA7125413; Wed, 4 Oct 2000 08:59:03 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id IAA01895; Wed, 4 Oct 2000 08:59:03 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id IAA06528;
	Wed, 4 Oct 2000 08:53:27 -0500
Message-Id: <200010041353.IAA06528@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Seth Mos <knuffie@xs4all.nl>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Patch for test9 
In-Reply-To: Message from Seth Mos <knuffie@xs4all.nl> 
   of "Wed, 04 Oct 2000 15:37:12 +0200." <4.3.2.7.2.20001004153027.027c9f18@pop.xs4all.nl> 
Date:   Wed, 04 Oct 2000 08:53:27 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> OK it sucked.
> 
> Should have a better (working) one soon.
> Build testing it first.
> 
> Slight miscalculation. Sorry.
> (pledge for forgiveness)
> 
> Next time I will build it before I bug all of you.
> 
> Bye
> --
> Seth
> "Have you gone mad?"
> "Well, yes, but that's beyond the scope of this email."

Since we have hooks into the VM, I expect this one to be more like minor
brain surgery than an appendectomy. You need to watch out for the PG_delalloc
flag on pages - there are calls into pagebuf to deal with these pages as
they cannot be directly written to disk. There is a proposed extension to
the VM in test9 where the filesystem will get a flush call when the VM
wants to write out a page, this is where the real fun is.

Steve

in merge process instead of just being


From owner-linux-xfs@oss.sgi.com Wed Oct  4 07:39:20 2000
Received:  by oss.sgi.com id <S42329AbQJDOjL>;
	Wed, 4 Oct 2000 07:39:11 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:60543 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42316AbQJDOix>;
	Wed, 4 Oct 2000 07:38:53 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA24338
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 07:30:28 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA7129827; Wed, 4 Oct 2000 09:35:40 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id JAA24235; Wed, 4 Oct 2000 09:35:40 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id JAA09074;
	Wed, 4 Oct 2000 09:30:04 -0500
Message-Id: <200010041430.JAA09074@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     chait@engr.sgi.com
cc:     linux-xfs@oss.sgi.com
Subject: Lilo hanging in XFS development tree
Date:   Wed, 04 Oct 2000 09:30:04 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Chait,

I want to send this one your way, not sure why, but the latest kernels
from the development tree cause a hang in lilo.

0xc0e40000 00001226 00001215  0  000  stop  0xc0e40340 lilo
[1]kdb> 
[1]kdb> 
[1]kdb> btp 1226
    EBP       EIP         Function(args)
0xc0e41ec4 0xc01172a8 schedule+0x420 (0x1b4)
                               kernel .text 0xc0100000 0xc0116e88 0xc0117560
0xc0e41ee4 0xc0131c5d __wait_on_buffer+0x4d (0xc2b9ed20)
                               kernel .text 0xc0100000 0xc0131c10 0xc0131cf0
           0xc0131dac sync_buffers+0xbc (0x300, 0x1)
                               kernel .text 0xc0100000 0xc0131cf0 0xc0131f18
           0xc0131fbd fsync_dev+0x81 (0x300)
                               kernel .text 0xc0100000 0xc0131f3c 0xc0131fc4
           0xc0138b5d blkdev_put+0x61 (0xc7d79ba0, 0x0)
                               kernel .text 0xc0100000 0xc0138afc 0xc0138c10
           0xc0138c22 blkdev_close+0x12 (0xc7d71b60, 0xc03a9bc0)
                               kernel .text 0xc0100000 0xc0138c10 0xc0138c28
           0xc01319af __fput+0x23 (0xc03a9bc0, 0xc03a9bc0)
                               kernel .text 0xc0100000 0xc013198c 0xc0131a28
           0xc0131a39 _fput+0x11 (0xc03a9bc0)
                               kernel .text 0xc0100000 0xc0131a28 0xc0131a7c
           0xc0131a8f fput+0x13 (0xc03a9bc0, 0xc16f60a0)
                               kernel .text 0xc0100000 0xc0131a7c 0xc0131a94
           0xc0130966 filp_close+0xa6 (0xc03a9bc0, 0xc16f60a0)
                               kernel .text 0xc0100000 0xc01308c0 0xc0130970
           0xc01309cf sys_close+0x5f (0x4, 0x8059b80, 0x4010a1ec, 0x4000ae60, 0x
bffffa74)
                               kernel .text 0xc0100000 0xc0130970 0xc01309e4
[1]more> 
           0xc010a8cb system_call+0x33
                               kernel .text 0xc0100000 0xc010a898 0xc010a8d0

buffer_head at 0xc2b9ed20
  next 0x00000000 bno 0 rsec 0 size 1024 dev 0x300 rdev 0x300
  count 2 state 0x1d [Uptodate Lock Req Mapped] ftime 0xed44
  b_page 0xc10b95c4 b_this_page 0xc2b9ed80 b_private 0x00000000

This buffer has no block number - or being as this is lilo it could
be block zero. However, if I follow the b_this_page pointer around I get
these buffers:

[0]kdb> bh 0xc2b9ed20
buffer_head at 0xc2b9ed20
  next 0x00000000 bno 0 rsec 0 size 1024 dev 0x300 rdev 0x300
  count 2 state 0x1d [Uptodate Lock Req Mapped] ftime 0xed44
  b_page 0xc10b95c4 b_this_page 0xc2b9ed80 b_private 0x00000000
[0]kdb> bh 0xc2b9ed80
buffer_head at 0xc2b9ed80
  next 0xc2bd0480 bno 106505 rsec 213010 size 1024 dev 0x801 rdev 0x801
  count 0 state 0x19 [Uptodate Req Mapped] ftime 0xed3c
  b_page 0xc10b95c4 b_this_page 0xc2b9ede0 b_private 0x00000000
[0]kdb> bh 0xc2b9ede0
buffer_head at 0xc2b9ede0
  next 0x00000000 bno 0 rsec 0 size 1024 dev 0x800 rdev 0x800
  count 0 state 0x19 [Uptodate Req Mapped] ftime 0x0
  b_page 0xc10b95c4 b_this_page 0xc2b9ecc0 b_private 0x00000000
[0]kdb> bh 0xc2b9ecc0
buffer_head at 0xc2b9ecc0
  next 0x00000000 bno 106508 rsec 213016 size 1024 dev 0x801 rdev 0x801
  count 0 state 0x19 [Uptodate Req Mapped] ftime 0xed4b
  b_page 0xc10b95c4 b_this_page 0xc2b9ed20 b_private 0x00000000

All the same page, but different devices and block numbers - this could
be a red herring though.

This is repeatable - even on a kernel where XFS has not even been loaded
in. Something in ll_rw_blk.c is probably at fault here. Root and /boot are
both on ext2 on /dev/sda.

Steve




From owner-linux-xfs@oss.sgi.com Wed Oct  4 08:06:10 2000
Received:  by oss.sgi.com id <S42402AbQJDPGB>;
	Wed, 4 Oct 2000 08:06:01 -0700
Received: from hermes.mixx.net ([212.84.196.2]:58634 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S42316AbQJDPF2>;
	Wed, 4 Oct 2000 08:05:28 -0700
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 0A3AFF808
	for <linux-xfs@oss.sgi.com>; Wed,  4 Oct 2000 17:04:46 +0200 (CEST)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id B43552CA6D; Wed,  4 Oct 2000 17:04:45 +0200 (CEST)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: xfs BUG at page_buf_io.c:1061
Date:   4 Oct 2000 15:04:45 GMT
Organization: innominate AG, Berlin, Germany
Lines:  34
Distribution: local
Message-ID: <news2mail-8rfgud$ndh$1@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 970671885 23985 10.0.0.69 (4 Oct 2000 15:04:45 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test8 (i586))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

just want to let you know about the following i see from time to time
(mostly even reproducable) on halting an all except /boot XFS machine

  kernel BUG at page_buf_io.c:1061

the backtrace looks something like

  pagebuf_read_full_page
  linvfs_read_full_page
  do_generic_file_read
  pagebuf_generic_file_read
  xfs_rdwr
  xfs_read
  linvfs_read
  sys_read
  system_call

i now see it on two machines: rh 6.2, egcs, 64mb, ide disk,
no kiosomething, latest sources (problem exists since the test8
integration), it mostly happens while shutting down cron or
something like, otherwise the system run stable - this _only_
happens on halt

maybe someone else has seen this too?

t

p.s.: up machine with smp kernel, p200 cpu

-- 
thomas.graichen@innominate.de
technical director                                       innominate AG
clustering & security                                networking people
tel: +49.30.308806-13  fax: -77                   http://innominate.de

From owner-linux-xfs@oss.sgi.com Wed Oct  4 08:13:20 2000
Received:  by oss.sgi.com id <S42425AbQJDPNL>;
	Wed, 4 Oct 2000 08:13:11 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:15628 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42316AbQJDPMz>;
	Wed, 4 Oct 2000 08:12:55 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA28616
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 08:04:30 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA7133439; Wed, 4 Oct 2000 10:09:41 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id KAA30465; Wed, 4 Oct 2000 10:09:41 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id KAA09285;
	Wed, 4 Oct 2000 10:04:05 -0500
Message-Id: <200010041504.KAA09285@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     "Michael Pike" <mpike@iqintermedia.com>
cc:     "XFS Mailing List" <linux-xfs@oss.sgi.com>
Subject: Re: Redhat RPM Builds on SMP Platform 
In-Reply-To: Message from "Michael Pike" <mpike@iqintermedia.com> 
   of "Wed, 04 Oct 2000 07:55:02 MDT." <003c01c02e0a$b1d8cce0$8a5bdfa1@hqw.ihs.gov> 
Date:   Wed, 04 Oct 2000 10:04:05 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> Greetings all... let me first say you are the biggest bunch of geniouses I
> have met :)  After messing with several large file system packages for
> Linux, XFS, even though in beta, has been the best out of them all, and a
> true life saver in my organization! :)

The one thing about XFS is that most of the filesystem code has been running
for years on thousands of machines.


> 
> The docs on the page were great, and the install went perfect... and XFS is
> what I am pushing to all of our clients (and we have a lot).

Having said what I just did, I would add a word of caution here - because
we are tied to a 2.4 test kernel you are also recommending to your
customers that they use the rest of the 2.4 kernel in production. This
may not be a wise move just yet.


> 
> I do have one question though, my expertise does not lie in Kernel
> compilations and such, so here we go....
> 
> On our production machine we run VMWare for thin client access.... after I
> installed the Kernel 2.4.test with XFS support from the RPMS rpms on the sgi
> website, the system came up, and ran fine... VMWare needed to be recompiled
> though... so, during the recompile it tells me the Kernel headers I have are
> not compatible with my current running Kernel (I was at 2.2.14 - now at
> 2.4.test-XFSi686smp) which makes sense... so when I loaded the
> xfsi386kernelheaders.rpm file, and tried to compile again, I got the same
> error message, only this time is said the headers were for 2.4.test-XFSi386,
> and I was running 2.4.testi686SMP)  (the key being here SMP)...
> 
> Do you guys have available kernel headers for the SMP kernel, or should I go
> ahead and just use the single processor kernel and stick with the stock
> kernel header rpms?

The header files are not themselves changed by SMP vs non-SMP in the
kernel build, so the actual contents of the rpm would be the same. I
am not familiar with vmware beyond what it is, especially not how you
can build it. I suspect vmware does not currently support a 2.4 kernel
in any shape or form. It sounds like you are hitting some checks early
in the build process - and once you got past them, then, depending on
what is really getting rebuilt here, I suspect there could be compile
errors all over the place. These sound more like questions to ask of
vmware than us.

> 
> It's a Dell PowerEdge 6300, 1 gig of ram, and 4 18 gig drives, dual PIII
> Xeon's... I would prefer to keep the SMP, but the file size issue is more
> important at this stage so I could give up SMP if I had to...
> 
> Any help appreciated, and keep up the great work!

Thanks for trying XFS.

Steve


> 
> Mike
> 


From owner-linux-xfs@oss.sgi.com Wed Oct  4 08:20:30 2000
Received:  by oss.sgi.com id <S42430AbQJDPUV>;
	Wed, 4 Oct 2000 08:20:21 -0700
Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:528 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S42406AbQJDPT7>;
	Wed, 4 Oct 2000 08:19:59 -0700
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e94FJ9C04754;
	Wed, 4 Oct 2000 10:19:10 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <39DB4A6C.69668AA2@thebarn.com>
Date:   Wed, 04 Oct 2000 10:19:09 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     thomas.graichen@innominate.de
CC:     linux-xfs@oss.sgi.com
Subject: Re: xfs BUG at page_buf_io.c:1061
References: <news2mail-8rfgud$ndh$1@mate.bln.innominate.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Thomas Graichen wrote:

> just want to let you know about the following i see from time to time
> (mostly even reproducable) on halting an all except /boot XFS machine
>
>   kernel BUG at page_buf_io.c:1061
>
> the backtrace looks something like
>
>   pagebuf_read_full_page
>   linvfs_read_full_page
>   do_generic_file_read
>   pagebuf_generic_file_read
>   xfs_rdwr
>   xfs_read
>   linvfs_read
>   sys_read
>   system_call
>
> i now see it on two machines: rh 6.2, egcs, 64mb, ide disk,
> no kiosomething, latest sources (problem exists since the test8
> integration), it mostly happens while shutting down cron or
> something like, otherwise the system run stable - this _only_
> happens on halt
>
> maybe someone else has seen this too?

Yes I hit this one yesterday... unfortunately it was on a laptop
machine without a  serial console connected.

I'm in the process of hooking one up, and digging into it a bit
farther.


>
>
> t
>
> p.s.: up machine with smp kernel, p200 cpu
>
> --
> thomas.graichen@innominate.de
> technical director                                       innominate AG
> clustering & security                                networking people
> tel: +49.30.308806-13  fax: -77                  http://innominate.de

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Wed Oct  4 11:47:23 2000
Received:  by oss.sgi.com id <S42344AbQJDSrN>;
	Wed, 4 Oct 2000 11:47:13 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:1368 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42310AbQJDSqy>;
	Wed, 4 Oct 2000 11:46:54 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA29641
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 11:38:29 -0700 (PDT)
	mail_from (chait@getafix.engr.sgi.com)
Received: from getafix.engr.sgi.com (getafix.engr.sgi.com [163.154.5.110])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA10854;
	Wed, 4 Oct 2000 11:45:55 -0700 (PDT)
	mail_from (chait@getafix.engr.sgi.com)
Received: from getafix.engr.sgi.com (IDENT:chait@localhost.localdomain [127.0.0.1])
	by getafix.engr.sgi.com (8.9.3/8.9.3) with ESMTP id LAA21566;
	Wed, 4 Oct 2000 11:45:48 -0400
Message-Id: <200010041545.LAA21566@getafix.engr.sgi.com>
To:     Steve Lord <lord@sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: Lilo hanging in XFS development tree 
In-reply-to: Your message of "Wed, 04 Oct 2000 09:30:04 CDT."
             <200010041430.JAA09074@jen.americas.sgi.com> 
Date:   Wed, 04 Oct 2000 11:45:48 -0400
From:   Chaitanya Tumuluri <chait@getafix.engr.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On Wed, 04 Oct 2000 09:30:04 CDT, Steve Lord <lord@sgi.com> wrote:
>Chait,
>
>I want to send this one your way, not sure why, but the latest kernels
>from the development tree cause a hang in lilo.
>
>		<stuff deleted>
>
>All the same page, but different devices and block numbers - this could
>be a red herring though.
>
>This is repeatable - even on a kernel where XFS has not even been loaded
>in. Something in ll_rw_blk.c is probably at fault here. Root and /boot are
>both on ext2 on /dev/sda.
>

Steve,

I've been trying for a while to reproduce this with t-o-t kernels from the
development tree and haven't had much success. Among the possiblities you
mentioned earlier, I'm starting to think that its something localized to 
your workarea ?

Has anyone else seen this lilo weirdness with the latest kernels?

Thanks,
-Chait.

From owner-linux-xfs@oss.sgi.com Wed Oct  4 11:57:53 2000
Received:  by oss.sgi.com id <S42345AbQJDS5o>;
	Wed, 4 Oct 2000 11:57:44 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:14941 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42310AbQJDS5a>;
	Wed, 4 Oct 2000 11:57:30 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA01318
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 11:49:01 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA7133486; Wed, 4 Oct 2000 13:54:01 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id NAA76796; Wed, 4 Oct 2000 13:54:01 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id NAA29072;
	Wed, 4 Oct 2000 13:48:24 -0500
Message-Id: <200010041848.NAA29072@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Chaitanya Tumuluri <chait@getafix.engr.sgi.com>
cc:     Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Lilo hanging in XFS development tree 
In-Reply-To: Message from Chaitanya Tumuluri <chait@getafix.engr.sgi.com> 
   of "Wed, 04 Oct 2000 11:45:48 EDT." <200010041545.LAA21566@getafix.engr.sgi.com> 
Date:   Wed, 04 Oct 2000 13:48:24 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
> On Wed, 04 Oct 2000 09:30:04 CDT, Steve Lord <lord@sgi.com> wrote:
> >Chait,
> >
> >I want to send this one your way, not sure why, but the latest kernels
> >from the development tree cause a hang in lilo.
> >
> >		<stuff deleted>
> >
> >All the same page, but different devices and block numbers - this could
> >be a red herring though.
> >
> >This is repeatable - even on a kernel where XFS has not even been loaded
> >in. Something in ll_rw_blk.c is probably at fault here. Root and /boot are
> >both on ext2 on /dev/sda.
> >
> 
> Steve,
> 
> I've been trying for a while to reproduce this with t-o-t kernels from the
> development tree and haven't had much success. Among the possiblities you
> mentioned earlier, I'm starting to think that its something localized to 
> your workarea ?
> 
> Has anyone else seen this lilo weirdness with the latest kernels?
> 
> Thanks,
> -Chait.


I just got a clean top of trunk kernel up on the machine in a new workarea.
I hit the hang again.

[root@lord lord]# lilo
Added xfs-2.4 *
Added xfs-root
Added sgilinux

hangs here for ever....


0xc51a0000 00001217 00001205  0  000  stop  0xc51a0340 lilo
[1]kdb> btp 1217
    EBP       EIP         Function(args)
0xc51a1ec4 0xc01172a8 schedule+0x420 (0x1a4)
                               kernel .text 0xc0100000 0xc0116e88 0xc0117560
0xc51a1ee4 0xc0131c5d __wait_on_buffer+0x4d (0xc66c7140)
                               kernel .text 0xc0100000 0xc0131c10 0xc0131cf0
           0xc0131dac sync_buffers+0xbc (0x300, 0x1)
                               kernel .text 0xc0100000 0xc0131cf0 0xc0131f18
           0xc0131fbd fsync_dev+0x81 (0x300)
                               kernel .text 0xc0100000 0xc0131f3c 0xc0131fc4
           0xc0138b5d blkdev_put+0x61 (0xc7d6bba0, 0x0)
                               kernel .text 0xc0100000 0xc0138afc 0xc0138c10
           0xc0138c22 blkdev_close+0x12 (0xc7d653e0, 0xc5a5c900)
                               kernel .text 0xc0100000 0xc0138c10 0xc0138c28
           0xc01319af __fput+0x23 (0xc5a5c900, 0xc5a5c900)
                               kernel .text 0xc0100000 0xc013198c 0xc0131a28
           0xc0131a39 _fput+0x11 (0xc5a5c900)
                               kernel .text 0xc0100000 0xc0131a28 0xc0131a7c
           0xc0131a8f fput+0x13 (0xc5a5c900, 0xc5b2a040)
                               kernel .text 0xc0100000 0xc0131a7c 0xc0131a94
           0xc0130966 filp_close+0xa6 (0xc5a5c900, 0xc5b2a040)
                               kernel .text 0xc0100000 0xc01308c0 0xc0130970
           0xc01309cf sys_close+0x5f (0x4, 0x8059b80, 0x4010a1ec, 0x4000ae60, 0xbffffa74)
                               kernel .text 0xc0100000 0xc0130970 0xc01309e4
[1]more> 
           0xc010a8cb system_call+0x33
                               kernel .text 0xc0100000 0xc010a898 0xc010a8d0
[1]kdb> bh 0xc66c7140
buffer_head at 0xc66c7140
  next 0x00000000 bno 0 rsec 0 size 1024 dev 0x300 rdev 0x300
  count 2 state 0x1d [Uptodate Lock Req Mapped] ftime 0x5587
  b_page 0xc11b4868 b_this_page 0xc66c71a0 b_private 0x00000000

Here is the partition table for the machine (running devfs)

major minor  #blocks  name     rio rmerge rsect ruse wio wmerge wsect wuse running use aveq

   8     0    8891620 scsi/host0/bus0/target1/lun0/disc 26884 203259 460294 99760 1569 6090 15348 320290 0 97510 420050
   8     1     530113 scsi/host0/bus0/target1/lun0/part1 1135 8198 18666 13550 1061 175 2498 21520 0 14120 35070
   8     2     136552 scsi/host0/bus0/target1/lun0/part2 1 0 8 10 0 0 0 0 0 10 10
   8     3    3445942 scsi/host0/bus0/target1/lun0/part3 25747 195061 441618 86210 508 5915 12850 298770 0 87930 384960
   8     4    4771305 scsi/host0/bus0/target1/lun0/part4 0 0 0 0 0 0 0 0 0 0 0
   3     0   10002825 ide/host0/bus0/target0/lun0/disc 1 0 2 10 0 0 2 0 1 49070 49070
   3     1     530113 ide/host0/bus0/target0/lun0/part1 0 0 0 0 0 0 0 0 0 0 0
   3     2     273105 ide/host0/bus0/target0/lun0/part2 0 0 0 0 0 0 0 0 0 0 0
   3     3    9197212 ide/host0/bus0/target0/lun0/part3 0 0 0 0 0 0 0 0 0 0 0

Mounted filesystems are on:

/dev/scsi/host0/bus0/target1/lun0/part1 on / type ext2 (rw)
/dev/scsi/host0/bus0/target1/lun0/part3 on /usr type ext2 (rw)

plus some automounted NFS filesystems. This device is not even mounted.

I am now about to try a kernel with the last set of kiobuf changes
backed out.

Steve



From owner-linux-xfs@oss.sgi.com Wed Oct  4 12:09:34 2000
Received:  by oss.sgi.com id <S42350AbQJDTJY>;
	Wed, 4 Oct 2000 12:09:24 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:15201 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42310AbQJDTIx>;
	Wed, 4 Oct 2000 12:08:53 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA03049
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 12:00:27 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA7132438; Wed, 4 Oct 2000 14:06:55 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id OAA78415; Wed, 4 Oct 2000 14:06:54 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id OAA29708;
	Wed, 4 Oct 2000 14:01:17 -0500
Message-Id: <200010041901.OAA29708@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Steve Lord <lord@sgi.com>
cc:     Chaitanya Tumuluri <chait@getafix.engr.sgi.com>,
        linux-xfs@oss.sgi.com
Subject: Re: Lilo hanging in XFS development tree 
In-Reply-To: Message from Steve Lord <lord@sgi.com> 
   of "Wed, 04 Oct 2000 13:48:24 CDT." <200010041848.NAA29072@jen.americas.sgi.com> 
Date:   Wed, 04 Oct 2000 14:01:17 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


> 
> I am now about to try a kernel with the last set of kiobuf changes
> backed out.
> 
> Steve
> 


OK, with the mod removed, everything works again. lilo and xfs_repair (which
was also wedged up).

Maybe the combo of ide and scsi in one box is the kicker. Unless we can
find a fix quickly I think the mod needs to go out again until this setup
works.

Steve



From owner-linux-xfs@oss.sgi.com Wed Oct  4 13:43:34 2000
Received:  by oss.sgi.com id <S42365AbQJDUnZ>;
	Wed, 4 Oct 2000 13:43:25 -0700
Received: from ppp0.ocs.com.au ([203.34.97.3]:5901 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S42310AbQJDUmw>;
	Wed, 4 Oct 2000 13:42:52 -0700
Received: (qmail 23372 invoked from network); 4 Oct 2000 20:41:56 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 4 Oct 2000 20:41:56 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: xfs BUG at page_buf_io.c:1061 
In-reply-to: Your message of "Wed, 04 Oct 2000 10:19:09 CDT."
             <39DB4A6C.69668AA2@thebarn.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 05 Oct 2000 07:41:54 +1100
Message-ID: <16062.970692114@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Wed, 04 Oct 2000 10:19:09 -0500, 
Russell Cattelan <cattelan@thebarn.com> wrote:
>Yes I hit this one yesterday... unfortunately it was on a laptop
>machine without a  serial console connected.

kdb supports logging of its output via syslog, set LOGGING=1 and all
new output goes via syslog.  The data is written to disk when you exit
kdb via 'go'.  Since the log buffers have limited size, only the last
8K or so iof output is saved.  And obviously your kernel needs to be
capable of writing to disk after the oops.


From owner-linux-xfs@oss.sgi.com Wed Oct  4 14:36:44 2000
Received:  by oss.sgi.com id <S42346AbQJDVgf>;
	Wed, 4 Oct 2000 14:36:35 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:61202 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42310AbQJDVgF>;
	Wed, 4 Oct 2000 14:36:05 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA23490; Wed, 4 Oct 2000 14:27:40 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA16460;
	Wed, 4 Oct 2000 14:35:21 -0700 (PDT)
Date:   Wed, 4 Oct 2000 14:35:21 -0700 (PDT)
Message-Id: <200010042135.OAA16460@info.engr.sgi.com>
X-Pv-Incident: 803884 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: BUG 803884 - double-fault with HIGHMEM
To:     nb@sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=803884

Submitter : dxm                       Submitter Domain : engr               
Assigned Engineer : nb                Assigned Domain : sgi.com             
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 3                          
Project : xfs-linux                   Status : open                         
Description :
This is very unlikely to be related to XFS.

However, running the auto-qa suite on a 1Gb machine with
HIGHMEM enabled can cause a process to hang up and render
the machine pretty much useless.

I've seen a couple of different variants but the problem 
has always occured below load_elf_binary, padzero and
clear_user.

Posting this because it's bound to bite someone who tries
to use our kernel on a HIGHMEM machine and because it's 
stopping me from running auto-qa on this config.

[0]kdb> btp 5552
    EBP       EIP         Function(args)
0xf49db8bc 0xc011721d schedule+0x415 (0xf49da000, 0xf49da000, 0xf5447220)
                               kernel .text 0xc0100000 0xc0116e08 0xc01177f0
0xf49db8e4 0xc0107a84 __down+0x6c
                               kernel .text 0xc0100000 0xc0107a18 0xc0107adc
0xf49db8f8 0xc0107c27 __down_failed+0xb (0xf49da000, 0x0, 0xf5447220, 
0xf49db98c, 0xf532231c)
                               kernel .text 0xc0100000 0xc0107c1c 0xc0107c30
           0xc01f7cd6 stext_lock+0x4de
                               kernel .text.lock 0xc01f77f8 0xc01f77f8 
0xc01fd5a0
0xf49db99c 0xc0112acc do_page_fault+0x60 (0xf49db9ac, 0x0, 0x100000, 
0xf54263ac, 0xf5426360)
                               kernel .text 0xc0100000 0xc0112a6c 0xc0112ea0
           0xc0109169 error_code+0x2d
                               kernel .text 0xc0100000 0xc010913c 0xc0109174
Interrupt registers:
eax = 0x00000000 ebx = 0x00100000 ecx = 0xf54263ac edx = 0xf5426360 
esi = 0x00000000 edi = 0xf5447220 esp = 0xf49db9e0 eip = 0xc0153ce5 
ebp = 0xf49dba18  ss = 0x00000018  cs = 0x00000010 eflags = 0x00010286 
 ds = 0xf5420018  es = 0x00000018 origeax = 0xffffffff &regs = 0xf49db9ac
           0xc0153ce5 ext2_get_block+0x119 (0xf5447220, 0xc, 0xf53429c0, 0x0)
                               kernel .text 0xc0100000 0xc0153bcc 0xc0154150
0xf49dba98 0xc0135300 block_read_full_page+0x124 (0xc1ff1fac, 0xc0153bcc)
                               kernel .text 0xc0100000 0xc01351dc 0xc01354a0
0xf49dbaa8 0xc0154349 ext2_readpage+0x11 (0xf5ac7200, 0xc1ff1fac)
[0]more> 
                               kernel .text 0xc0100000 0xc0154338 0xc0154350
0xf49dbacc 0xc0126ee4 read_cluster_nonblocking+0xdc (0xf5ac7200, 0x2, 0x18)
                               kernel .text 0xc0100000 0xc0126e08 0xc0126f20
0xf49dbb0c 0xc01282ac filemap_nopage+0x254 (0xf5aadaa0, 0x804b000, 0x1)
                               kernel .text 0xc0100000 0xc0128058 0xc0128464
0xf49dbb2c 0xc01249ed do_no_page+0x51 (0xf5322300, 0xf5aadaa0, 0x804b9cc, 0x1, 
0xf45a212c)
                               kernel .text 0xc0100000 0xc012499c 0xc0124a4c
0xf49dbb5c 0xc0124b56 handle_mm_fault+0x10a (0xf5322300, 0xf5aadaa0, 
0x804b9cc, 0x1, 0xf49da000)
                               kernel .text 0xc0100000 0xc0124a4c 0xc0124bec
0xf49dbc10 0xc0112bce do_page_fault+0x162 (0xf49dbc20, 0x2, 0x634, 0x18d, 
0x18d)
                               kernel .text 0xc0100000 0xc0112a6c 0xc0112ea0
           0xc0109169 error_code+0x2d
                               kernel .text 0xc0100000 0xc010913c 0xc0109174
Interrupt registers:
eax = 0x00000000 ebx = 0x00000634 ecx = 0x0000018d edx = 0x0000018d 
esi = 0x00000000 edi = 0x0804b9cc esp = 0xf49dbc54 eip = 0xc01f1117 
ebp = 0xf49dbc64  ss = 0x00000018  cs = 0x00000010 eflags = 0x00010246 
 ds = 0x00000018  es = 0x00000018 origeax = 0xffffffff &regs = 0xf49dbc20
           0xc01f1117 clear_user+0x37 (0x804b9cc, 0x634)
                               kernel .text 0xc0100000 0xc01f10e0 0xc01f112c
0xf49dbc74 0xc014974e padzero+0x1e (0x804b9cc, 0x804b9cc, 0x804bc10, 
0xc02b8630, 0xc0149e14)
                               kernel .text 0xc0100000 0xc0149730 0xc0149754
0xf49dbe0c 0xc014a874 load_elf_binary+0xa60 (0xf49dbe68, 0xf49dbfc4, 
0xf49dbe68)
[0]more> 
                               kernel .text 0xc0100000 0xc0149e14 0xc014a9d8
0xf49dbe44 0xc013c848 search_binary_handler+0x68 (0xf49dbe68, 0xf49dbfc4, 
0xe95e2000, 0xe95e2000, 0x80a2c78)
                               kernel .text 0xc0100000 0xc013c7e0 0xc013c990
0xf49dbf9c 0xc013cad8 do_execve+0x148 (0xe95e2000, 0x80a2c30, 0x80a3a70, 
0xf49dbfc4)
                               kernel .text 0xc0100000 0xc013c990 0xc013cb30
0xf49dbfbc 0xc010795b sys_execve+0x2f (0x80a2c78, 0x80a2c30, 0x80a3a70, 
0x80a2c30, 0x80a2c78)
                               kernel .text 0xc0100000 0xc010792c 0xc0107988
           0xc0109040 system_call+0x34
                               kernel .text 0xc0100000 0xc010900c 0xc0109044

The "ps" command I ran is now hung waiting for some lock:

    EBP       EIP         Function(args)
0xf429bee4 0xc011721d schedule+0x415 (0xf49da000, 0xf5322300, 0xf49da000)
                               kernel .text 0xc0100000 0xc0116e08 0xc01177f0
0xf429bf0c 0xc0107a84 __down+0x6c
                               kernel .text 0xc0100000 0xc0107a18 0xc0107adc
0xf429bf20 0xc0107c27 __down_failed+0xb (0xf5c063a0, 0xf4e8c000, 0xf49da000, 
0x0, 0x33e8c)
                               kernel .text 0xc0100000 0xc0107c1c 0xc0107c30
           0xc01fa49c stext_lock+0x2ca4
                               kernel .text.lock 0xc01f77f8 0xc01f77f8 
0xc01fd5a0
0xf429bf64 0xc014e4c3 proc_pid_stat+0x6f (0xf49da000, 0xf4e8c000, 0xf5433380, 
0xffffffea)
                               kernel .text 0xc0100000 0xc014e454 0xc014e6d8
0xf429bf98 0xc014c497 proc_info_read+0x5b (0xf5433380, 0x40015000, 0x1000, 
0xf54333a0, 0xf429a000)
                               kernel .text 0xc0100000 0xc014c43c 0xc014c55c
0xf429bfbc 0xc01326b8 sys_read+0xa4 (0x4, 0x40015000, 0x1000, 0x804bf90, 0x0)
                               kernel .text 0xc0100000 0xc0132614 0xc01326d0
           0xc0109040 system_call+0x34
                               kernel .text 0xc0100000 0xc010900c 0xc0109044

Here's another trace of the same problem. This time I dumped
some pages and buffer heads below.

[0]kdb> btp 5732
    EBP       EIP         Function(args)
0xf4919864 0xc0117048 schedule+0x420 (0xf4918000, 0xf4918000, 0xf49199e8)
                               kernel .text 0xc0100000 0xc0116c28 0xc0117300
0xf491988c 0xc0107a84 __down+0x6c
                               kernel .text 0xc0100000 0xc0107a18 0xc0107adc
0xf49198a0 0xc0107c27 __down_failed+0xb (0xf4918000, 0xf52f03c0, 0xf49199e8, 
0xc01abdc7, 0xf53e0e9c)
                               kernel .text 0xc0100000 0xc0107c1c 0xc0107c30
           0xc01fb528 stext_lock+0x4ec
                               kernel .text.lock 0xc01fb03c 0xc01fb03c 
0xc0200f00
0xf4919944 0xc0112a2c do_page_fault+0x60 (0xf4919954, 0x0, 0xf49199ec, 0x0, 
0xf49199e8)
                               kernel .text 0xc0100000 0xc01129cc 0xc0112e00
           0xc0109164 error_code+0x2c
                               kernel .text 0xc0100000 0xc0109138 0xc010916c
Interrupt registers:
eax = 0x00000000 ebx = 0xf49199ec ecx = 0x00000000 edx = 0xf49199e8 
esi = 0xf52f03c0 edi = 0xf49199e8 esp = 0xf4919988 eip = 0xc0153c89 
ebp = 0xf4919a1c  ss = 0x00000018  cs = 0x00000010 eflags = 0x00010246 
 ds = 0xf4910018  es = 0x00000018 origeax = 0xffffffff &regs = 0xf4919954
           0xc0153c89 ext2_get_block+0x13d (0xf53efe40, 0xc, 0xf534ec80, 0x0)
                               kernel .text 0xc0100000 0xc0153b4c 0xc0154074
0xf4919a9c 0xc0134800 block_read_full_page+0x124 (0xc202a028, 0xc0153b4c)
                               kernel .text 0xc0100000 0xc01346dc 0xc01349a0
0xf4919aac 0xc0154269 ext2_readpage+0x11 (0xf5afdd80, 0xc202a028)
[0]more> 
                               kernel .text 0xc0100000 0xc0154258 0xc0154270
0xf4919ad0 0xc01260b4 read_cluster_nonblocking+0xe0 (0xf5afdd80, 0x2, 0x15)
                               kernel .text 0xc0100000 0xc0125fd4 0xc01260f0
0xf4919b10 0xc012741c filemap_nopage+0x254 (0xf4b4eaa0, 0x804b000, 0x1)
                               kernel .text 0xc0100000 0xc01271c8 0xc01275d4
0xf4919b30 0xc0123c6d do_no_page+0x51 (0xf53e0e80, 0xf4b4eaa0, 0x804b2b0, 0x1, 
0xf481f12c)
                               kernel .text 0xc0100000 0xc0123c1c 0xc0123ccc
0xf4919b60 0xc0123dd6 handle_mm_fault+0x10a (0xf53e0e80, 0xf4b4eaa0, 
0x804b2b0, 0x1, 0xf4918000)
                               kernel .text 0xc0100000 0xc0123ccc 0xc0123e6c
0xf4919c14 0xc0112b2e do_page_fault+0x162 (0xf4919c24, 0x2, 0xd50, 0x354, 
0x354)
                               kernel .text 0xc0100000 0xc01129cc 0xc0112e00
           0xc0109164 error_code+0x2c
                               kernel .text 0xc0100000 0xc0109138 0xc010916c
Interrupt registers:
eax = 0x00000000 ebx = 0x00000d50 ecx = 0x00000354 edx = 0x00000354 
esi = 0x00000000 edi = 0x0804b2b0 esp = 0xf4919c58 eip = 0xc01f48e7 
ebp = 0xf4919c68  ss = 0x00000018  cs = 0x00000010 eflags = 0x00010246 
 ds = 0x00000018  es = 0x00000018 origeax = 0xffffffff &regs = 0xf4919c24
           0xc01f48e7 clear_user+0x37 (0x804b2b0, 0xd50)
                               kernel .text 0xc0100000 0xc01f48b0 0xc01f48fc
0xf4919c78 0xc014977e padzero+0x1e (0x804b2b0, 0x804b2b0, 0x804b4cc, 
0xc02bcaf0, 0xc0149e44)
                               kernel .text 0xc0100000 0xc0149760 0xc0149784
0xf4919e10 0xc014a8b4 load_elf_binary+0xa70 (0xf4919e68, 0xf4919fc4, 
0xf4919e68)
[0]more> 
                               kernel .text 0xc0100000 0xc0149e44 0xc014aa18
0xf4919e48 0xc013c158 search_binary_handler+0x68 (0xf4919e68, 0xf4919fc4)
                               kernel .text 0xc0100000 0xc013c0f0 0xc013c2a0
0xf4919f9c 0xc013c3e8 do_execve+0x148 (0xf4c93000, 0x809f4c8, 0x80a7540, 
0xf4919fc4)
                               kernel .text 0xc0100000 0xc013c2a0 0xc013c43c
0xf4919fbc 0xc010795f sys_execve+0x2f (0x80a4ec8, 0x809f4c8, 0x80a7540, 
0x809f4c8, 0x80a4ec8)
                               kernel .text 0xc0100000 0xc0107930 0xc010798c
           0xc010903b system_call+0x33
                               kernel .text 0xc0100000 0xc0109008 0xc0109040
[0]kdb> 
[0]kdb> 
[0]kdb> bh 0xf534ec80
buffer_head at 0xf534ec80
  next 0x00000000 bno 0 rsec 0 size 4096 dev 0x806 rdev 0x0
  count 0 state 0x0 [] ftime 0x0
  b_page 0xc202a028 b_this_page 0xf534ec80 b_private 0x00000000
[0]kdb> page 0xc202a028
struct page at 0xc202a028
  next 0xc1f212a4 prev 0xf53efedc addr space 0xf53efedc index 12 (offset 
0xc000)
  count 3 flags PG_locked PG_highmem virtual 0xfe072000
  buffers 0xf534ec80  block_map 11111111000000000000000000000000
[0]kdb> page 0xf534ec80
struct page at 0xf534ec80
  next 0x00000000 prev 0x00000000 addr space 0x00001000 index 2054 (offset 
0x806000)
  count 0 flags  virtual 0xc202a028
  buffers 0x00000000  block_map 00000000000000000000000000000000
[0]kdb> reboot

From owner-linux-xfs@oss.sgi.com Wed Oct  4 17:56:36 2000
Received:  by oss.sgi.com id <S42369AbQJEA40>;
	Wed, 4 Oct 2000 17:56:26 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23913 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42316AbQJEAz6>; Wed, 4 Oct 2000 17:55:58 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA00140
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 18:02:20 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA76448
	for linux-xfs@oss.sgi.com; Thu, 5 Oct 2000 11:53:59 +1100 (EST)
Date:   Thu, 5 Oct 2000 11:53:59 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010050053.LAA76448@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - warnings
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This fixes most of the warnings from xfs-cmd compilation
using more recent versions of libc and gcc (rh7).


Modid:  2.4.x-xfs:slinx:75755a
Date:  Wed Oct  4 17:52:00 PDT 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/bmap/xfs_bmap.c - 1.8
cmd/xfs/copy/xfs_copy.c - 1.19
cmd/xfs/db/flist.c - 1.18
cmd/xfs/db/init.c - 1.30
cmd/xfs/db/io.c - 1.28
cmd/xfs/db/malloc.c - 1.10
cmd/xfs/db/uuid.c - 1.5
cmd/xfs/db/write.c - 1.20
cmd/xfs/dump/common/getdents.c - 1.9
	- remove unused headers.

cmd/xfs/dump/common/mlog.c - 1.10
cmd/xfs/dump/inventory/inv_api.c - 1.11
	- fix getsubopts warnings.

cmd/xfs/estimate/xfs_estimate.c - 1.2
cmd/xfs/fsr/fsr_xfs.c - 1.11
cmd/xfs/growfs/xfs_growfs.c - 1.5
cmd/xfs/handle/jdm.c - 1.3
	- remove unused headers.

cmd/xfs/include/builddefs.in - 1.13
	- install as root.root like everyone else, not root.bin (uid.gid).

cmd/xfs/include/platform_defs.h.in - 1.12
	- add string.h - everyone needs it now, conditionally define constpp
	  depending on libc version to workaround getsubopts prototype change.

cmd/xfs/libxfs/init.c - 1.14
cmd/xfs/libxfs/rdwr.c - 1.17
cmd/xfs/logprint/log_misc.c - 1.73
cmd/xfs/mkfile/xfs_mkfile.c - 1.8
cmd/xfs/mkfs/maxtrres.c - 1.2
cmd/xfs/mkfs/mountinfo.c - 1.3
cmd/xfs/mkfs/proto.c - 1.4
	- remove unused headers.

cmd/xfs/mkfs/xfs_mkfs.c - 1.179
	- fix getsubopts warnings.

cmd/xfs/repair/agheader.c - 1.23
cmd/xfs/repair/attr_repair.c - 1.21
cmd/xfs/repair/dinode.c - 1.83
cmd/xfs/repair/dir.c - 1.59
cmd/xfs/repair/dir2.c - 1.15
cmd/xfs/repair/incore.c - 1.36
cmd/xfs/repair/incore_bmc.c - 1.13
cmd/xfs/repair/incore_ino.c - 1.24
cmd/xfs/repair/phase4.c - 1.50
cmd/xfs/repair/phase5.c - 1.44
cmd/xfs/repair/phase6.c - 1.61
cmd/xfs/repair/sb.c - 1.36
	- remove unused headers.

cmd/xfs/repair/xfs_repair.c - 1.52
	- fix getsubopts warnings.

cmd/xfs/stress/src/bstat.c - 1.2
cmd/xfs/stress/src/devzero.c - 1.8
cmd/xfs/stress/src/fill.c - 1.3
	- remove unused headers.

cmd/xfs/stress/src/fill2.c - 1.3
	- fix getsubopts warnings.

From owner-linux-xfs@oss.sgi.com Wed Oct  4 19:27:06 2000
Received:  by oss.sgi.com id <S42372AbQJEC04>;
	Wed, 4 Oct 2000 19:26:56 -0700
Received: from ns1.feed.co.jp ([210.145.130.50]:49722 "EHLO ns1.feed.co.jp") convert rfc822-to-8bit
	by oss.sgi.com with ESMTP id <S42316AbQJEC00>;
	Wed, 4 Oct 2000 19:26:26 -0700
Received: from saqkllk (cranston-ip-1-100.dynamic.ziplink.net [209.206.4.100])
	by ns1.feed.co.jp (8.8.5+2.7Wbeta5/3.6Wbeta6) with ESMTP id LAA00501;
	Thu, 5 Oct 2000 11:14:08 +0900
Message-Id: <200010050214.LAA00501@ns1.feed.co.jp>
From:   "Viv Charles" <bbwx@dog.com>
Subject: Take Them All #473A
To:     today2w92@ns1.feed.co.jp
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date:   Wed, 04 Oct 2000 21:02:08 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

              
Accepting credit cards for your business 
Has never been so easy & affordable!

Our specialty is establishing your merchant account!

NO APPLICATION FEE!
NO PROGRAMMING FEE!
$9.95 PROCESSING FEE

If you already accept credit cards we can save you $$$. We offer the
absolute lowest rates in the industry! Please call today for a no
obligation merchant statement analysis.

Call today and apply:
(888) 264-9272

Now you can design your web site with our
complete software package, which offers:
· Domain Registration
· Web Hosting Services
· Web Design Tools
· Online Shopping Cart
· Credit Card Processing Integration
Quick, Easy and Affordable at just $99.00!
Call (888) 264-9272 and order today!


************************************************************
If you receive this message and have never joined one of our 
email lists you can be removed  by replying to:
mailto:bbwx@corpusmail.com?subject=remove
************************************************************




From owner-linux-xfs@oss.sgi.com Wed Oct  4 20:27:46 2000
Received:  by oss.sgi.com id <S42316AbQJED1g>;
	Wed, 4 Oct 2000 20:27:36 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:29019 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42362AbQJED1H>;
	Wed, 4 Oct 2000 20:27:07 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA00170
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 20:18:41 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA35198
	for linux-xfs@oss.sgi.com; Thu, 5 Oct 2000 14:25:07 +1100 (EST)
Date:   Thu, 5 Oct 2000 14:25:07 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010050325.OAA35198@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - stress
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This should fix the problem you saw with 002, Eric.

cheers.


Modid:  2.4.x-xfs:slinx:75767a
Date:  Wed Oct  4 20:24:09 PDT 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/src/lstat64.c - 1.3
	- make formatting cleaner - don't put loads of extra spaces in.


From owner-linux-xfs@oss.sgi.com Wed Oct  4 20:38:16 2000
Received:  by oss.sgi.com id <S42371AbQJEDiG>;
	Wed, 4 Oct 2000 20:38:06 -0700
Received: from davida.com ([204.107.144.130]:61963 "EHLO davida.com")
	by oss.sgi.com with ESMTP id <S42362AbQJEDhc>;
	Wed, 4 Oct 2000 20:37:32 -0700
Received: (from jd@localhost)
	by davida.com (8.11.0/8.11.0) id e953aoA69934
	for linux-xfs@oss.sgi.com; Wed, 4 Oct 2000 22:36:50 -0500 (CDT)
	(envelope-from jd)
Date:   Wed, 4 Oct 2000 22:36:50 -0500 (CDT)
From:   Joseph Davida <jd@davida.com>
Message-Id: <200010050336.e953aoA69934@davida.com>
To:     linux-xfs@oss.sgi.com
Subject:  mount.xfs
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


        I built latest XFS-test8 (both kernel
        and xfs cmds). After making an xfs 
        file system, I was unable to mount
        it because the build no longer
        installs mount.xfs in /sbin.

        Joe


From owner-linux-xfs@oss.sgi.com Wed Oct  4 20:42:15 2000
Received:  by oss.sgi.com id <S42375AbQJEDl4>;
	Wed, 4 Oct 2000 20:41:56 -0700
Received: from davida.com ([204.107.144.130]:62219 "EHLO davida.com")
	by oss.sgi.com with ESMTP id <S42364AbQJEDlf>;
	Wed, 4 Oct 2000 20:41:35 -0700
Received: (from jd@localhost)
	by davida.com (8.11.0/8.11.0) id e953erN69943
	for linux-xfs@oss.sgi.com; Wed, 4 Oct 2000 22:40:53 -0500 (CDT)
	(envelope-from jd)
Date:   Wed, 4 Oct 2000 22:40:53 -0500 (CDT)
From:   Joseph Davida <jd@davida.com>
Message-Id: <200010050340.e953erN69943@davida.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: mount.xfs
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

	To clarify my previous message further, test8 no longer
	builds mount.xfs.

	Joe



>I built latest XFS-test8 (both kernel
>and xfs cmds). After making an xfs 
>file system, I was unable to mount
>it because the build no longer
>installs mount.xfs in /sbin.
>
>Joe

From owner-linux-xfs@oss.sgi.com Wed Oct  4 20:48:45 2000
Received:  by oss.sgi.com id <S42364AbQJEDs0>;
	Wed, 4 Oct 2000 20:48:26 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:11358 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42362AbQJEDr4>;
	Wed, 4 Oct 2000 20:47:56 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA01585
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 20:39:30 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA02108; Thu, 5 Oct 2000 14:44:42 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA52942; Thu, 5 Oct 2000 14:44:41 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10010051444.ZM51534@wobbly.melbourne.sgi.com>
Date:   Thu, 5 Oct 2000 14:44:40 -0400
In-Reply-To: Joseph Davida <jd@davida.com>
        "mount.xfs" (Oct  4, 10:36pm)
References: <200010050336.e953aoA69934@davida.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Joseph Davida <jd@davida.com>, linux-xfs@oss.sgi.com
Subject: Re: mount.xfs
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 Oct 4, 10:36pm, Joseph Davida wrote:
> Subject: mount.xfs
> 
>         I built latest XFS-test8 (both kernel
>         and xfs cmds). After making an xfs 
>         file system, I was unable to mount
>         it because the build no longer
>         installs mount.xfs in /sbin.
> 

There never was a mount.xfs - you need to either get the
latest version of the package containing mount (which has 
Martins changes to autodetect xfs) or you'll need to give
"-t xfs" to mount.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed Oct  4 21:10:16 2000
Received:  by oss.sgi.com id <S42376AbQJEEKG>;
	Wed, 4 Oct 2000 21:10:06 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:48224 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42362AbQJEEJh>;
	Wed, 4 Oct 2000 21:09:37 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA02951
	for <linux-xfs@oss.sgi.com>; Wed, 4 Oct 2000 21:01:11 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA23238
	for linux-xfs@oss.sgi.com; Thu, 5 Oct 2000 15:07:37 +1100 (EST)
Date:   Thu, 5 Oct 2000 15:07:37 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010050407.PAA23238@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - stress
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75768a
Date:  Wed Oct  4 21:07:23 PDT 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/002 - 1.4
	- ensure work is done on an XFS filesystem, the root may be
	  something else.


From owner-linux-xfs@oss.sgi.com Thu Oct  5 16:44:22 2000
Received:  by oss.sgi.com id <S42478AbQJEXoM>;
	Thu, 5 Oct 2000 16:44:12 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:51809 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42389AbQJEXnz>; Thu, 5 Oct 2000 16:43:55 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA08157
	for <linux-xfs@oss.sgi.com>; Thu, 5 Oct 2000 16:50:58 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id SAA7161712; Thu, 5 Oct 2000 18:42:37 -0500 (CDT)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id SAA20160; Thu, 5 Oct 2000 18:42:37 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e95NgaQ20210;
	Thu, 5 Oct 2000 18:42:36 -0500
Message-ID: <39DD11EB.16FD1B8C@thebarn.com>
Date:   Thu, 05 Oct 2000 18:42:35 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-whipme5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "h.a." <heid.a@swol.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: xfs on linux/alpha
References: <39DD2604.658B1664@swol.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

"h.a." wrote:

> hi xfs-team,
>
> during compilation of the linux-kernel with your current xfs devel
> '09262000XFSdevel' the following
> errors occured.
>
>
> -----------------------
>
> make[2]: Entering directory `/usr/src/kernel/2.4.0-test5/linux/fs/xfs'
>
> gcc -D__KERNEL__ -I/usr/src/kernel/2.4.0-test5/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mno-fp-regs -ffixed-8 -mcpu=ev56 -Wa,-mev6 -fno-strict-aliasing -DMODULE -g3 -Wno-unused  -Wno-parentheses -Wno-uninitialized -I. -funsigned-char  -Wno-unknown-pragmas  -c -o xfsrtstubs.o xfsrtstubs.c
>
> In file included from xfs.h:140,
>
>                  from xfsrtstubs.c:33:
>
> linux/xfs_globals.h:43: conflicting types for `xfs_panic_mask'
>
> xfs_error.h:139: previous declaration of `xfs_panic_mask'
>
> make[2]: *** [xfsrtstubs.o] Error 1
>
>
>
>
>
>
>
> imho i think i got this because of the unnecessary declaration
>
> extern __uint64_t       xfs_panic_mask;
>
> at line 139 in file
>
> linux-2.4.0-test5/linux/fs/xfs/xfs_error.h
>
> . it doesn't make sense here.

Hmm I'm not sure if both are necessary, but for the moment I would
just change the type back to a uint64_t, or change xfs_globals.h to
__uint64_t.

That should get you rolling again.


>
>
>
>
> -----------------------
>
> and look in the file
>
> linux-2.4.0-test5/linux/include/linux/kdb.h
>
> at line 32.  there is only a asm/kdb.h for i386 machines.

That's correct currently only the x86 architecture is supported by kdb.
You will need to make sure your .config has it turned off.

>
>
>
> -----------------------
>
> and in file
>
> linux-2.4.0-test5/linux/fs/xfs/xfs_error.c
>
> at line 232 the first parameter of  function
>
> void
>
> xfs_cmn_err(uint64_t panic_tag, int level, xfs_mount_t *mp, char *fmt, ...)
>
> have to be __uint64 i think.

Ahh more type problems

Thanks we'll have to take a close look at this.


>
>
>
>
> have a nice day.
> andre
>


From owner-linux-xfs@oss.sgi.com Thu Oct  5 19:30:32 2000
Received:  by oss.sgi.com id <S42508AbQJFCaX>;
	Thu, 5 Oct 2000 19:30:23 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:53261 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42507AbQJFC37>;
	Thu, 5 Oct 2000 19:29:59 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA18718
	for <linux-xfs@oss.sgi.com>; Thu, 5 Oct 2000 19:22:13 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA56615
	for linux-xfs@oss.sgi.com; Fri, 6 Oct 2000 13:28:39 +1100 (EST)
Date:   Fri, 6 Oct 2000 13:28:39 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200010060228.NAA56615@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xfs_db
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

subtle xfs_db bug (score 1 db-walk)

Modid:  2.4.x-xfs:slinx:75840a
Date:  Thu Oct  5 19:27:55 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/db/field.c - 1.30
cmd/xfs/db/inode.c - 1.36
	- dev in dinode is an xfs_dev_t (32 bit) not a dev_t (64 bit)


From owner-linux-xfs@oss.sgi.com Fri Oct  6 00:04:44 2000
Received:  by oss.sgi.com id <S42399AbQJFHE0>;
	Fri, 6 Oct 2000 00:04:26 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:1329 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42325AbQJFHED>;
	Fri, 6 Oct 2000 00:04:03 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA29067
	for <linux-xfs@oss.sgi.com>; Thu, 5 Oct 2000 22:03:22 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA26906
	for linux-xfs@oss.sgi.com; Fri, 6 Oct 2000 16:09:48 +1100 (EST)
Date:   Fri, 6 Oct 2000 16:09:48 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200010060509.QAA26906@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - remove stale externs
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:75843a
Date:  Thu Oct  5 22:09:32 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/include/xfs_fs.h - 1.5
linux/include/linux/xfs_fs.h - 1.16
	- remove stale externs


From owner-linux-xfs@oss.sgi.com Fri Oct  6 14:27:00 2000
Received:  by oss.sgi.com id <S42330AbQJFV0k>;
	Fri, 6 Oct 2000 14:26:40 -0700
Received: from twingo.tiscalinet.it ([195.130.224.85]:59807 "EHLO
        twingo.tiscalinet.it") by oss.sgi.com with ESMTP id <S42325AbQJFV0b>;
	Fri, 6 Oct 2000 14:26:31 -0700
Received: from lenstra (62.11.106.48) by twingo.tiscalinet.it; 6 Oct 2000 18:17:06 +0200
Message-Id: <3.0.1.32.20001006182304.00967510@pop.tiscalinet.it>
X-Sender: lenstra@pop.tiscalinet.it (Unverified)
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date:   Fri, 06 Oct 2000 18:23:04 +0200
To:     linux-xfs@oss.sgi.com
From:   Lorenzo Allegrucci <lenstra@tiscalinet.it>
Subject: XFS on a small partition
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


I tried XFS on a small free partition of 100Mb.
Copying a linux source tree seems very slow and cp remains in D state
almost all the time, idem for rm. No other process was running.
Is it normal? Maybe the partition is too small for XFS?


--
Lorenzo

From owner-linux-xfs@oss.sgi.com Fri Oct  6 17:09:11 2000
Received:  by oss.sgi.com id <S42272AbQJGAJC>;
	Fri, 6 Oct 2000 17:09:02 -0700
Received: from sun.rhrk.uni-kl.de ([131.246.137.50]:32690 "HELO
        sun.rhrk.uni-kl.de") by oss.sgi.com with SMTP id <S42210AbQJGAIk>;
	Fri, 6 Oct 2000 17:08:40 -0700
Received: from aixs1.rhrk.uni-kl.de
           ( exim@aixs1.rhrk.uni-kl.de [131.246.137.3] ) by sun.rhrk.uni-kl.de
          id aa22903 ; 7 Oct 2000 02:08 MESZ
Received: from trip210.wohnheim.uni-kl.de ([131.246.188.10] helo=student.uni-kl.de)
	by aixs1.rhrk.uni-kl.de with esmtp (Exim 3.03 #2)
	id 13hhXX-0008u4-00; Sat, 07 Oct 2000 02:08:36 +0200
Message-ID: <39DE6A69.27B3547B@student.uni-kl.de>
Date:   Sat, 07 Oct 2000 00:12:25 +0000
From:   Ralf Sinoradzki <sinoradz@student.uni-kl.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Lorenzo Allegrucci <lenstra@tiscalinet.it>, linux-xfs@oss.sgi.com
Subject: Re: XFS on a small partition
References: <3.0.1.32.20001006182304.00967510@pop.tiscalinet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Lorenzo Allegrucci wrote:
> 
> I tried XFS on a small free partition of 100Mb.
> Copying a linux source tree seems very slow and cp remains in D state
> almost all the time, idem for rm. No other process was running.
> Is it normal? Maybe the partition is too small for XFS?
> 
> --
> Lorenzo

Sure that you compiled with egcs 2.91.66 ?
Not gcc2.95.2 or something like that ?

From owner-linux-xfs@oss.sgi.com Fri Oct  6 17:16:52 2000
Received:  by oss.sgi.com id <S42342AbQJGAQm>;
	Fri, 6 Oct 2000 17:16:42 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:13340 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42210AbQJGAQe>;
	Fri, 6 Oct 2000 17:16:34 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA27273
	for <linux-xfs@oss.sgi.com>; Fri, 6 Oct 2000 17:08:48 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16300; Sat, 7 Oct 2000 11:14:00 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA54132; Sat, 7 Oct 2000 11:13:58 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10010071113.ZM56614@wobbly.melbourne.sgi.com>
Date:   Sat, 7 Oct 2000 11:13:56 -0400
In-Reply-To: Ralf Sinoradzki <sinoradz@student.uni-kl.de>
        "Re: XFS on a small partition" (Oct  7, 12:12am)
References: <3.0.1.32.20001006182304.00967510@pop.tiscalinet.it> 
	<39DE6A69.27B3547B@student.uni-kl.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Ralf Sinoradzki <sinoradz@student.uni-kl.de>,
        Lorenzo Allegrucci <lenstra@tiscalinet.it>,
        linux-xfs@oss.sgi.com
Subject: Re: XFS on a small partition
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

hi,

On Oct 7, 12:12am, Ralf Sinoradzki wrote:
> Subject: Re: XFS on a small partition
> Lorenzo Allegrucci wrote:
> > 
> > I tried XFS on a small free partition of 100Mb.
> > Copying a linux source tree seems very slow and cp remains in D state
> > almost all the time, idem for rm. No other process was running.
> > Is it normal? Maybe the partition is too small for XFS?
> > 


100Mb is not too small - I use smaller XFS filesystems quite
frequently, without problems.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Fri Oct  6 17:45:02 2000
Received:  by oss.sgi.com id <S42351AbQJGAow>;
	Fri, 6 Oct 2000 17:44:52 -0700
Received: from Cantor.suse.de ([194.112.123.193]:36626 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42257AbQJGAoj>;
	Fri, 6 Oct 2000 17:44:39 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id CBAC91E238; Sat,  7 Oct 2000 02:44:37 +0200 (MEST)
Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 9BCE83E459; Sat,  7 Oct 2000 02:44:37 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 1A8C02F300; Sat,  7 Oct 2000 02:44:32 +0200 (MEST)
Date:   Sat, 7 Oct 2000 02:44:32 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Lorenzo Allegrucci <lenstra@tiscalinet.it>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS on a small partition
Message-ID: <20001007024431.A9818@gruyere.muc.suse.de>
References: <3.0.1.32.20001006182304.00967510@pop.tiscalinet.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <3.0.1.32.20001006182304.00967510@pop.tiscalinet.it>; from lenstra@tiscalinet.it on Fri, Oct 06, 2000 at 06:23:04PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Fri, Oct 06, 2000 at 06:23:04PM +0200, Lorenzo Allegrucci wrote:
> 
> I tried XFS on a small free partition of 100Mb.
> Copying a linux source tree seems very slow and cp remains in D state
> almost all the time, idem for rm. No other process was running.
> Is it normal? Maybe the partition is too small for XFS?

It sounds like your log is too small. Try increasing it.


-Andi


From owner-linux-xfs@oss.sgi.com Sat Oct  7 01:14:05 2000
Received:  by oss.sgi.com id <S42181AbQJGINq>;
	Sat, 7 Oct 2000 01:13:46 -0700
Received: from twingo.tiscalinet.it ([195.130.224.85]:37075 "EHLO
        twingo.tiscalinet.it") by oss.sgi.com with ESMTP id <S42173AbQJGINa>;
	Sat, 7 Oct 2000 01:13:30 -0700
Received: from lenstra (62.11.104.4) by twingo.tiscalinet.it; 7 Oct 2000 10:08:17 +0200
Message-Id: <3.0.1.32.20001007101420.0098c390@pop.tiscalinet.it>
X-Sender: lenstra@pop.tiscalinet.it
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date:   Sat, 07 Oct 2000 10:14:20 +0200
To:     linux-xfs@oss.sgi.com
From:   Lorenzo Allegrucci <lenstra@tiscalinet.it>
Subject: Re: XFS on a small partition
In-Reply-To: <39DE6A69.27B3547B@student.uni-kl.de>
References: <3.0.1.32.20001006182304.00967510@pop.tiscalinet.it>
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

At 00.12 07/10/00 +0000, you wrote:
>Lorenzo Allegrucci wrote:
>> 
>> I tried XFS on a small free partition of 100Mb.
>> Copying a linux source tree seems very slow and cp remains in D state
>> almost all the time, idem for rm. No other process was running.
>> Is it normal? Maybe the partition is too small for XFS?
>> 
>> --
>> Lorenzo
>
>Sure that you compiled with egcs 2.91.66 ?
>Not gcc2.95.2 or something like that ?

Oops, I compiled with GCC 2.95.2, sorry :-)

--
Lorenzo

From owner-linux-xfs@oss.sgi.com Sat Oct  7 21:31:44 2000
Received:  by oss.sgi.com id <S42184AbQJHEbe>;
	Sat, 7 Oct 2000 21:31:34 -0700
Received: from mplspop3.mpls.uswest.net ([204.147.80.13]:39947 "HELO
        mplspop3.mpls.uswest.net") by oss.sgi.com with SMTP
	id <S42173AbQJHEbR>; Sat, 7 Oct 2000 21:31:17 -0700
Received: (qmail 38795 invoked by alias); 8 Oct 2000 04:31:11 -0000
Delivered-To: fixup-linux-xfs@oss.sgi.com@fixme
Received: (qmail 38786 invoked by uid 0); 8 Oct 2000 04:31:11 -0000
Received: from wdskppp234.mpls.uswest.net (HELO ?10.0.0.4?) (63.226.148.234)
  by mplspop3.mpls.uswest.net with SMTP; 8 Oct 2000 04:31:11 -0000
Date:   Sat, 7 Oct 2000 22:26:01 -0500 (CDT)
From:   Nitebirdz <nitebirdz@uswest.net>
X-Sender: nitebirdz@localhost.localdomain
To:     linux-xfs@oss.sgi.com
Subject: Problems installing ProPack 1.3 on TurboLinux 6.0 (fwd)
Message-ID: <Pine.LNX.4.21.0010072225190.1609-100000@localhost.localdomain>
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

I also sent this message to the freeware-sgi list, but then I realized that
may have been the wrong place to send it to.  Sorry.  Could someone provide
some help on this issue, please?  Thanks in advance.

-------------------------------
Nitebirdz
http://www.linuxnovice.org
Your place for tips, news, etc.

---------- Forwarded message ----------
Date: Sat, 7 Oct 2000 22:16:59 -0500 (CDT)
From: Nitebirdz <nitebirdz@uswest.net>
To: freeware@cthulhu.engr.sgi.com
Subject: Problems installing ProPack 1.3 on TurboLinux 6.0

I just installed TurboLinux 6.0 Workstation on an Intel box in order to
play with XFS a little bit.  However, when I tried to install the SGI
ProPack 1.3 on the system, the installer came up with the following:

 Traceback (innermost last):                     # x
             x   File                                          a x
             x "/mnt/cdrom/SGI/instimage/usr/bin/anaconda",    a x
             x line 237, in ?                                  a x
             x     intf.run(todo, test = test)                 a x
             x   File "/mnt/cdrom/SGI/sgi-packages/text.py",   a x
             x line 1092, in run                               a x
             x     rc = apply (step[1](), step[2])             a x
             x   File                                          a x
             x "/mnt/cdrom/SGI/instimage/usr/lib/python1.5/si  a x
             x te-packages/textw/packages.py", line 11, in     a x
             x __call__                                        a x
             x     todo.getCompsList()                         a x
             x   File "/mnt/cdrom/SGI/sgi-packages/todo.py",   a x
             x line 939, in getCompsList                       a x
             x     self.comps =                                a x
             x self.method.readComps(self.hdList)              a x
             x   File "/mnt/cdrom/SGI/sgi-packages/image.py",  a x
             x line 8, in readComps                            a x
             x     return ComponentSet(self.tree +             a x
             x '/SGI/base/comps', hdlist)                      a x
             x   File "/mnt/cdrom/SGI/sgi-packages/comps.py",  a x
             x line 284, in __init__                           a x
             x     raise RuntimeError, msg % (str              a x
             x (missingPackages), file)                        a x
             x RuntimeError: Missing RPM's for packages        a x
             x <['kernel-smp-bigmem']> listed in comps file    a x
             x </mnt/cdrom/SGI/base/comps>                     # 


Any idea what's going on here?  Anybody aware of a bug/incompatiblity?  I'm
trying to install from the official SGI CD.  

-------------------------------
Nitebirdz
http://www.linuxnovice.org
Your place for tips, news, etc.



From owner-linux-xfs@oss.sgi.com Sun Oct  8 06:05:46 2000
Received:  by oss.sgi.com id <S42189AbQJHNFh>;
	Sun, 8 Oct 2000 06:05:37 -0700
Received: from hermes.mixx.net ([212.84.196.2]:22801 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S42188AbQJHNFS>;
	Sun, 8 Oct 2000 06:05:18 -0700
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id D1CE0F84B
	for <linux-xfs@oss.sgi.com>; Sun,  8 Oct 2000 15:05:12 +0200 (CEST)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 172552CA6D; Sun,  8 Oct 2000 15:05:12 +0200 (CEST)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: crashes
Date:   Sun, 8 Oct 2000 15:04:20 +0200
Organization: innominate AG, Berlin, Germany
Lines:  25
Distribution: local
Message-ID: <news2mail-kcrpr8.u61.ln@liquid.bln.innominate.de>
X-Trace: mate.bln.innominate.de 971010311 31274 10.0.0.1 (8 Oct 2000 13:05:12 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test8 (i686))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

again - just as an info: i see crashes since the test8 thing very
often (or better don't see them because the machine is in x at
the time of the crash - i only see the blinking lights on the
keyboard from kdb :-) ... does someone else see this too?

it mostly happens after a while of uptime on an unused machine
(mostly in the evening everything is fine - but then i come
back in the morning it has crashed) ... also i see it on
several machines - one thing they all have in common is
the xfs root fs and quite up to date xfs sources (now
at about the point since that it says -XFS-test8 -
will test newer sources now - but i think there
were not many changes inbetween)

i also still get (on different machines) the kdb on shutting
down the machines quite reproducable like posted a few days
before

t

-- 
thomas.graichen@innominate.de
technical director                                       innominate AG
clustering & security                                networking people
tel: +49.30.308806-13  fax: -77                   http://innominate.de

From owner-linux-xfs@oss.sgi.com Sun Oct  8 06:11:46 2000
Received:  by oss.sgi.com id <S42191AbQJHNLg>;
	Sun, 8 Oct 2000 06:11:36 -0700
Received: from Cantor.suse.de ([194.112.123.193]:37394 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42188AbQJHNLd>;
	Sun, 8 Oct 2000 06:11:33 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 970F51E376; Sun,  8 Oct 2000 15:11:31 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 0FF6E3E669; Sun,  8 Oct 2000 15:11:31 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 89E3B2F300; Sun,  8 Oct 2000 15:11:30 +0200 (MEST)
Date:   Sun, 8 Oct 2000 15:11:30 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Thomas Graichen <graichen@innominate.de>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: crashes
Message-ID: <20001008151130.A25978@gruyere.muc.suse.de>
References: <news2mail-kcrpr8.u61.ln@liquid.bln.innominate.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <news2mail-kcrpr8.u61.ln@liquid.bln.innominate.de>; from news-innominate.list.sgi.xfs@innominate.de on Sun, Oct 08, 2000 at 03:04:20PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sun, Oct 08, 2000 at 03:04:20PM +0200, Thomas Graichen wrote:
> again - just as an info: i see crashes since the test8 thing very
> often (or better don't see them because the machine is in x at
> the time of the crash - i only see the blinking lights on the
> keyboard from kdb :-) ... does someone else see this too?

I have the same problem. My xfs test machine in the office has locked up
over the weekend, with serial console dead.

It may be possible that it is not entirely XFS fault though: 
I catched a crash earlier in kdb that was in the Realtek driver interrupt
handler. I didn't investigate it unfortunately, just recompiled the modules.


> it mostly happens after a while of uptime on an unused machine
> (mostly in the evening everything is fine - but then i come
> back in the morning it has crashed) ... also i see it on

Same here. Machine was unused and it doesn't even have a XFS root,
just mounted XFS [maybe the 0:00 cron job crashed it]



-Andi

From owner-linux-xfs@oss.sgi.com Sun Oct  8 12:28:38 2000
Received:  by oss.sgi.com id <S42194AbQJHT22>;
	Sun, 8 Oct 2000 12:28:28 -0700
Received: from hermes.mixx.net ([212.84.196.2]:9480 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S42188AbQJHT2I>;
	Sun, 8 Oct 2000 12:28:08 -0700
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 51783F854
	for <linux-xfs@oss.sgi.com>; Sun,  8 Oct 2000 21:28:06 +0200 (CEST)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 2963D2CA6D; Sun,  8 Oct 2000 21:28:05 +0200 (CEST)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: ot: anyone from here in atlanta?
Date:   Sun, 8 Oct 2000 20:22:17 +0200
Organization: innominate AG, Berlin, Germany
Lines:  12
Distribution: local
Message-ID: <news2mail-p0eqr8.b92.ln@liquid.bln.innominate.de>
X-Trace: mate.bln.innominate.de 971033285 27028 10.0.0.1 (8 Oct 2000 19:28:05 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.4.0-XFS-test8 (i686))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

sorry for the a bit off topic: is anyone of the xfs and sourrounding
psople in atlanta?

sorry again :-)

t

-- 
thomas.graichen@innominate.de
technical director                                       innominate AG
clustering & security                                networking people
tel: +49.30.308806-13  fax: -77                   http://innominate.de

From owner-linux-xfs@oss.sgi.com Sun Oct  8 15:01:59 2000
Received:  by oss.sgi.com id <S42204AbQJHWBs>;
	Sun, 8 Oct 2000 15:01:48 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54393 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42188AbQJHWBi>; Sun, 8 Oct 2000 15:01:38 -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 PAA02923
	for <linux-xfs@oss.sgi.com>; Sun, 8 Oct 2000 15:08:43 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA24441; Mon, 9 Oct 2000 09:00:19 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA47513; Mon, 9 Oct 2000 09:00:17 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10010090900.ZM55829@wobbly.melbourne.sgi.com>
Date:   Mon, 9 Oct 2000 09:00:15 -0400
In-Reply-To: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
        "(Fwd) Problems installing ProPack 1.3 on TurboLinux 6.0 (fwd)" (Oct  8,  3:40pm)
References: <10010081540.ZM57549@wobbly.melbourne.sgi.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Nitebirdz <nitebirdz@uswest.net>
Subject: Re: Problems installing ProPack 1.3 on TurboLinux 6.0 (fwd)
Cc:     linux-xfs@oss.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

hi,

>From the author of the ProPack installer...

--- Forwarded mail from Paul Jackson
Date: Sun, 8 Oct 2000 12:27:39 -0700 (PDT)
Subject: Re:  (Fwd) Problems installing ProPack 1.3 on TurboLinux 6.0 (fwd)

             x RuntimeError: Missing RPM's for packages        a x
             x <['kernel-smp-bigmem']> listed in comps file    a x
             x </mnt/cdrom/SGI/base/comps>                     #

See bug 795210 - ProPack 1.3 fails to install on a
big memory system with 586 or less cpu's.

I'd try installing ProPack 1.4.
---End of forwarded mail from Paul Jackson


If you were after the XFS beta you'll need ProPack 1.4,
see:  http://oss.sgi.com/projects/xfs/beta_propack.html

cheers.


> ---------- Forwarded message ----------
> Date: Sat, 7 Oct 2000 22:16:59 -0500 (CDT)
> From: Nitebirdz <nitebirdz@uswest.net>
> To: freeware@cthulhu.engr.sgi.com
> Subject: Problems installing ProPack 1.3 on TurboLinux 6.0
> 
> I just installed TurboLinux 6.0 Workstation on an Intel box in order to
> play with XFS a little bit.  However, when I tried to install the SGI
> ProPack 1.3 on the system, the installer came up with the following:
> ...
> Any idea what's going on here?  Anybody aware of a bug/incompatiblity?  I'm
> trying to install from the official SGI CD.  
> 
> -------------------------------
> Nitebirdz
> http://www.linuxnovice.org
> Your place for tips, news, etc.
> 
> ---End of forwarded mail from Nitebirdz <nitebirdz@uswest.net>

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Sun Oct  8 18:07:13 2000
Received:  by oss.sgi.com id <S42198AbQJIBHD>;
	Sun, 8 Oct 2000 18:07:03 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:48145 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42188AbQJIBGm>;
	Sun, 8 Oct 2000 18:06:42 -0700
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA27151
	for <linux-xfs@oss.sgi.com>; Sun, 8 Oct 2000 17:58:56 -0700 (PDT)
	mail_from (ananth@sgi.com)
Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA50985; Sun, 8 Oct 2000 18:01:19 -0700 (PDT)
Message-ID: <39E119A5.C97D3917@sgi.com>
Date:   Sun, 08 Oct 2000 18:04:37 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Thomas Graichen <graichen@innominate.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: ot: anyone from here in atlanta?
References: <news2mail-p0eqr8.b92.ln@liquid.bln.innominate.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Thomas Graichen wrote:
> 
> sorry for the a bit off topic: is anyone of the xfs and sourrounding
> psople in atlanta?
> 

There are few people from SGI at Atlanta (ALS), but
I don't believe anyone directly working on XFS is there.
There are several of us going to the Storage Management
Workshop in Miami next week (15-19th October 2000).

regards,

-- 
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Sun Oct  8 18:25:13 2000
Received:  by oss.sgi.com id <S42200AbQJIBZD>;
	Sun, 8 Oct 2000 18:25:03 -0700
Received: from cmbsyb.hqw.ihs.gov ([161.223.90.2]:2067 "EHLO
        cmbsyb.hqw.ihs.gov") by oss.sgi.com with ESMTP id <S42188AbQJIBYy>;
	Sun, 8 Oct 2000 18:24:54 -0700
Received: from mplaptop (dialup397.nmia.com [64.42.130.212]) by cmbsyb.hqw.ihs.gov (AIX4.2/UCB 8.7/8.7) with SMTP id TAA48108 for <linux-xfs@oss.sgi.com>; Sun, 8 Oct 2000 19:23:31 -0600 (MDT)
Message-ID: <004701c0318f$b355c180$0200a8c0@mshome.net>
From:   "Michael Pike" <mpike@iqintermedia.com>
To:     "XFS Mailing List" <linux-xfs@oss.sgi.com>
Subject: Kernel 2.4 and XFS
Date:   Sun, 8 Oct 2000 19:24:40 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Is there any idea when 2.4 will officially be released, and how long
thereafter an XFS kernel?

The XFS i downloaded was vey simple to install on my redhat, just load the
rpms and go!!! Much easier than any other large file system out there...
will SGI provide an easy install for the final release as well???

I've got a large client base of hospitals using our Linux help desk and
patient record software, and currently out work around for large file
systems is multiple database files... once XFS is officially released, we
will make the 2.4 XFS kernel the standard implementation for all of our
sites....

We're running your latest beta (non on-the-fly changes) and the thing has
been rock solid!!!

SGI Rules! :)

Mike

------------
IQ Intermedia Corporation



From owner-linux-xfs@oss.sgi.com Sun Oct  8 18:26:03 2000
Received:  by oss.sgi.com id <S42202AbQJIBZx>;
	Sun, 8 Oct 2000 18:25:53 -0700
Received: from aus-dsl-dhcp1-26.customer.jump.net ([63.163.168.26]:12787 "EHLO
        Porter") by oss.sgi.com with ESMTP id <S42188AbQJIBZo>;
	Sun, 8 Oct 2000 18:25:44 -0700
Received: (from sandeen@localhost)
	by Porter (8.9.3/8.9.3) id UAA01249
	for linux-xfs@oss.sgi.com; Sun, 8 Oct 2000 20:25:46 -0500
Date:   Sun, 8 Oct 2000 20:24:45 -0500
From:   Eric Sandeen <sandeen@sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: crashes
Message-ID: <20001008202445.A1245@Porter>
References: <news2mail-kcrpr8.u61.ln@liquid.bln.innominate.de> <20001008151130.A25978@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
In-Reply-To: <20001008151130.A25978@gruyere.muc.suse.de>; from ak@suse.de on Sun, Oct 08, 2000 at 08:11:30 -0500
X-Mailer: Balsa 1.0.pre2
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On Sun, 08 Oct 2000 08:11:30 Andi Kleen wrote:

> I have the same problem. My xfs test machine in the office has locked up
> over the weekend, with serial console dead.

<snip>

> Same here. Machine was unused and it doesn't even have a XFS root,
> just mounted XFS [maybe the 0:00 cron job crashed it]

Same here... office machine died this weekend around Saturday night, XFS
filesystem mounted (but not being used).

Haven't been in to the office, so no idea what's gone wrong at this point.

-Eric

From owner-linux-xfs@oss.sgi.com Sun Oct  8 20:06:05 2000
Received:  by oss.sgi.com id <S42205AbQJIDFz>;
	Sun, 8 Oct 2000 20:05:55 -0700
Received: from c166.h203149147.is.net.tw ([203.149.147.166]:7942 "EHLO convert rfc822-to-8bit
        ms1.ladder.com.tw") by oss.sgi.com with ESMTP id <S42188AbQJIDFb>;
	Sun, 8 Oct 2000 20:05:31 -0700
Received: from ddwjwdj ([209.206.4.179]) by ms1.ladder.com.tw
          (post.office MTA v1.9.1 ID# 12-11304) with ESMTP id AAA228;
          Mon, 9 Oct 2000 11:15:02 +0800
From:   "Dennis Drankle" <bknk@coolmail.net>
Subject: Open One Today # 167
To:     gold29sd@oss.sgi.com
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date:   Sun, 08 Oct 2000 22:02:31 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Message-Id: <20001009030537Z42188-31377+1535@oss.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

              
Accepting credit cards for your business 
Has never been so easy & affordable!

Our specialty is establishing your merchant account!

NO APPLICATION FEE!
NO PROGRAMMING FEE!
$9.95 PROCESSING FEE

If you already accept credit cards we can save you $$$. We offer the
absolute lowest rates in the industry! Please call today for a no
obligation merchant statement analysis.

Call today and apply:
(888) 264-9272

Now you can design your web site with our
complete software package, which offers:
· Domain Registration
· Web Hosting Services
· Web Design Tools
· Online Shopping Cart
· Credit Card Processing Integration
Quick, Easy and Affordable at just $99.00!
Call (888) 264-9272 and order today!


************************************************************
If you receive this message and have never joined one of our 
email lists you can be removed  by replying to:
mailto:bknk@168city.com?subject=remove
************************************************************




From owner-linux-xfs@oss.sgi.com Mon Oct  9 10:48:41 2000
Received:  by oss.sgi.com id <S42199AbQJIRsa>;
	Mon, 9 Oct 2000 10:48:30 -0700
Received: from spica.cc.utexas.edu ([129.116.206.20]:49123 "EHLO
        spica.cc.utexas.edu") by oss.sgi.com with ESMTP id <S42192AbQJIRsU>;
	Mon, 9 Oct 2000 10:48:20 -0700
Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194])
	by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id MAA21693
	for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 12:48:17 -0500 (CDT)
Message-Id: <4.2.0.58.20001009124907.01a55590@127.0.0.1>
X-Sender: jones@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date:   Mon, 09 Oct 2000 12:50:50 -0500
To:     linux-xfs@oss.sgi.com
From:   "William L. Jones" <jones@tacc.cc.utexas.edu>
Subject: LVM not working
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I cannot mount a lvm file system uner linux-2.4-XFS-TEST8.  I noticed
their was a patch ll_rw_blk.c to fix a lvm problem.  Could it be that
it did not make into the public cvs source?

Bill Jones

From owner-linux-xfs@oss.sgi.com Mon Oct  9 10:58:40 2000
Received:  by oss.sgi.com id <S42208AbQJIR6b>;
	Mon, 9 Oct 2000 10:58:31 -0700
Received: from tux.mkp.net ([130.225.60.11]:44807 "EHLO tux.mkp.net")
	by oss.sgi.com with ESMTP id <S42192AbQJIR61>;
	Mon, 9 Oct 2000 10:58:27 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=tyra.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 13ih4x-0003zP-00; Mon, 09 Oct 2000 19:51:12 +0200
Received: (from mkp@localhost)
	by tyra.mkp.net (8.9.3/8.9.3) id NAA12019;
	Mon, 9 Oct 2000 13:58:37 -0400
X-Authentication-Warning: tyra.mkp.net: mkp set sender to mkp@mkp.net using -f
To:     "William L. Jones" <jones@tacc.cc.utexas.edu>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: LVM not working
References: <4.2.0.58.20001009124907.01a55590@127.0.0.1>
From:   "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date:   09 Oct 2000 13:58:37 -0400
In-Reply-To: "William L. Jones"'s message of "Mon, 09 Oct 2000 12:50:50 -0500"
Message-ID: <yq1vgv1522a.fsf@tyra.mkp.net>
Lines:  17
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
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

>>>>> "Bill" == William L Jones <jones@tacc.cc.utexas.edu> writes:

Bill> I cannot mount a lvm file system uner linux-2.4-XFS-TEST8.  I
Bill> noticed their was a patch ll_rw_blk.c to fix a lvm problem.
Bill> Could it be that it did not make into the public cvs source?

I'm seeing all kinds of funnies with LVM in test8 after we applied the
latest block I/O changes.  Doesn't seem to be a problem in test5 +
latest-but-one kiobuf patch.  Diff didn't reveal anything obvious, so
I'm still investigating (Not today, though.  Thanksgiving here in
Canada).

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.


From owner-linux-xfs@oss.sgi.com Mon Oct  9 11:01:40 2000
Received:  by oss.sgi.com id <S42209AbQJISBU>;
	Mon, 9 Oct 2000 11:01:20 -0700
Received: from chynpop1.chyn.uswest.net ([209.181.12.1]:21002 "HELO
        chynpop1.chyn.uswest.net") by oss.sgi.com with SMTP
	id <S42192AbQJISBS>; Mon, 9 Oct 2000 11:01:18 -0700
Received: (qmail 9771 invoked by alias); 9 Oct 2000 18:01:15 -0000
Delivered-To: fixup-linux-xfs@oss.sgi.com@fixme
Received: (qmail 9760 invoked by uid 0); 9 Oct 2000 18:01:14 -0000
Received: from chyndslgw1poola164.chyn.uswest.net (HELO roujin.gargoylecc.com) (63.227.165.164)
  by chynpop1.chyn.uswest.net with SMTP; 9 Oct 2000 18:01:14 -0000
Date:   Mon, 9 Oct 2000 12:00:58 -0600 (MDT)
From:   Russel Ingram <ringram@roujin.roundthestars.net>
X-Sender: ringram@roujin.gargoylecc.com
To:     linux-xfs@oss.sgi.com
Subject: XFS filesystem corrupts on umount
Message-ID: <Pine.LNX.4.21.0010091150080.10473-100000@roujin.gargoylecc.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

I have seen umount related things in the archives but nothing that seems
to match what I am experiencing here.  I just installed the kernel and xfs
utils that come on the ProPack 1.4 CD.  I created an xfs filesytem on
/dev/hda4 (now /dev/ide/host0/bus0/target0/lun0/part4) after having copied
everything out of it to a temp dir.  The filesystem created fine and
mounted fine.  I was even able to copy the old fs back to it with no
problems.  I unmounted the new fs to mount it back into its normal mount
point in the dir tree (/home), but when I went to mount it back in it gave
be a bad superblock or too many filesystems mounted error.  xfs_check
didn't report anything, but after running xfs_repair on it it mounted
ok.  I umounted it again to see if the error was going to occur again and
it did.  It seems the filesystem becomes corrupt every time umount is run
on it.  Is this a known problem?  Is there an easy way around it?

Thanx,
Russ

Russ Ingram
Gargoyle Computer Consulting
www.gargoylecc.com


From owner-linux-xfs@oss.sgi.com Mon Oct  9 11:03:40 2000
Received:  by oss.sgi.com id <S42211AbQJISDU>;
	Mon, 9 Oct 2000 11:03:20 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:63793 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42192AbQJISDP>;
	Mon, 9 Oct 2000 11:03:15 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA20366
	for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 10:55:29 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA7201323; Mon, 9 Oct 2000 13:01:57 -0500 (CDT)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id NAA45068; Mon, 9 Oct 2000 13:01:56 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e99I1uQ07000;
	Mon, 9 Oct 2000 13:01:56 -0500
Message-ID: <39E20813.A6CEFC1A@thebarn.com>
Date:   Mon, 09 Oct 2000 13:01:55 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-whipme5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "William L. Jones" <jones@tacc.cc.utexas.edu>
CC:     linux-xfs@oss.sgi.com
Subject: Re: LVM not working
References: <4.2.0.58.20001009124907.01a55590@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

"William L. Jones" wrote:

> I cannot mount a lvm file system uner linux-2.4-XFS-TEST8.  I noticed
> their was a patch ll_rw_blk.c to fix a lvm problem.  Could it be that
> it did not make into the public cvs source?

I haven't tested test8 and lvm yet...
What problem are you seeing with lvm?

I check the tree's to make sure everything is up-to-date.



From owner-linux-xfs@oss.sgi.com Mon Oct  9 11:23:40 2000
Received:  by oss.sgi.com id <S42196AbQJISXb>;
	Mon, 9 Oct 2000 11:23:31 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:64572 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42192AbQJISXM>; Mon, 9 Oct 2000 11:23:12 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA01008
	for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 11:30:19 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA7171350; Mon, 9 Oct 2000 13:21:53 -0500 (CDT)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id NAA50549; Mon, 9 Oct 2000 13:21:53 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e99ILqQ07071;
	Mon, 9 Oct 2000 13:21:52 -0500
Message-ID: <39E20CBF.FD764BA8@thebarn.com>
Date:   Mon, 09 Oct 2000 13:21:51 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-whipme5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Russel Ingram <ringram@roujin.roundthestars.net>
CC:     linux-xfs@oss.sgi.com
Subject: Re: XFS filesystem corrupts on umount
References: <Pine.LNX.4.21.0010091150080.10473-100000@roujin.gargoylecc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Russel Ingram wrote:

> I have seen umount related things in the archives but nothing that seems
> to match what I am experiencing here.  I just installed the kernel and xfs
> utils that come on the ProPack 1.4 CD.  I created an xfs filesytem on
> /dev/hda4 (now  after having copied
> everything out of it to a temp dir.  The filesystem created fine and
> mounted fine.  I was even able to copy the old fs back to it with no
> problems.  I unmounted the new fs to mount it back into its normal mount
> point in the dir tree (/home), but when I went to mount it back in it gave
> be a bad superblock or too many filesystems mounted error.  xfs_check
> didn't report anything, but after running xfs_repair on it it mounted
> ok.  I umounted it again to see if the error was going to occur again and
> it did.  It seems the filesystem becomes corrupt every time umount is run
> on it.  Is this a known problem?  Is there an easy way around it?

Hmm as long a the FS was cleanly un-mounted this should be occurring.
Run the theca command after un-mounting the file system.
xfs_logprint -t /dev/ide/host0/bus0/target0/lun0/part4

send us the output.

>
> Russ Ingram
> Gargoyle Computer Consulting
> www.gargoylecc.com


From owner-linux-xfs@oss.sgi.com Mon Oct  9 11:30:40 2000
Received:  by oss.sgi.com id <S42212AbQJISaV>;
	Mon, 9 Oct 2000 11:30:21 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:54588 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42192AbQJISaS>;
	Mon, 9 Oct 2000 11:30:18 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA24632
	for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 11:22:32 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id NAA7216572; Mon, 9 Oct 2000 13:27:41 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id NAA40346; Mon, 9 Oct 2000 13:27:41 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id NAA28619;
	Mon, 9 Oct 2000 13:21:15 -0500
Message-Id: <200010091821.NAA28619@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     "William L. Jones" <jones@tacc.cc.utexas.edu>
cc:     linux-xfs@oss.sgi.com
Subject: Re: LVM not working 
In-Reply-To: Message from "William L. Jones" <jones@tacc.cc.utexas.edu> 
   of "Mon, 09 Oct 2000 12:50:50 CDT." <4.2.0.58.20001009124907.01a55590@127.0.0.1> 
Date:   Mon, 09 Oct 2000 13:21:14 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
> I cannot mount a lvm file system uner linux-2.4-XFS-TEST8.  I noticed
> their was a patch ll_rw_blk.c to fix a lvm problem.  Could it be that
> it did not make into the public cvs source?
> 
> Bill Jones


We have some problems with changes to the ide code at the moment in test8
these are about to get backed out, so the burning question is, are you using
ide drives?

Steve



From owner-linux-xfs@oss.sgi.com Mon Oct  9 11:34:30 2000
Received:  by oss.sgi.com id <S42192AbQJISeU>;
	Mon, 9 Oct 2000 11:34:20 -0700
Received: from spica.cc.utexas.edu ([129.116.206.20]:60390 "EHLO
        spica.cc.utexas.edu") by oss.sgi.com with ESMTP id <S42213AbQJISeJ>;
	Mon, 9 Oct 2000 11:34:09 -0700
Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194])
	by spica.cc.utexas.edu (8.9.1/8.9.1) with ESMTP id NAA22482;
	Mon, 9 Oct 2000 13:33:41 -0500 (CDT)
Message-Id: <4.2.0.58.20001009133513.019e6de0@127.0.0.1>
X-Sender: jones@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date:   Mon, 09 Oct 2000 13:36:12 -0500
To:     Steve Lord <lord@sgi.com>,
        "William L. Jones" <jones@tacc.cc.utexas.edu>
From:   "William L. Jones" <jones@tacc.cc.utexas.edu>
Subject: Re: LVM not working 
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <200010091821.NAA28619@jen.americas.sgi.com>
References: <Message from "William L. Jones" <jones@tacc.cc.utexas.edu>
 <4.2.0.58.20001009124907.01a55590@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At 01:21 PM 10/9/00 -0500, Steve Lord wrote:
> >
> > I cannot mount a lvm file system uner linux-2.4-XFS-TEST8.  I noticed
> > their was a patch ll_rw_blk.c to fix a lvm problem.  Could it be that
> > it did not make into the public cvs source?
> >
> > Bill Jones
>
>
>We have some problems with changes to the ide code at the moment in test8
>these are about to get backed out, so the burning question is, are you using
>ide drives?
>
>Steve

Yes I am using IDE.  I will try to remember to include that important
little fact next time.

Bill Jones

From owner-linux-xfs@oss.sgi.com Mon Oct  9 12:06:01 2000
Received:  by oss.sgi.com id <S42216AbQJITFv>;
	Mon, 9 Oct 2000 12:05:51 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:38476 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42213AbQJITF1>;
	Mon, 9 Oct 2000 12:05:27 -0700
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA29807
	for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 11:57:42 -0700 (PDT)
	mail_from (chait@getafix.engr.sgi.com)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA23361 for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 12:04:56 -0700 (PDT)
Received: from getafix.engr.sgi.com (getafix.engr.sgi.com [163.154.5.110])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA89055;
	Mon, 9 Oct 2000 12:03:21 -0700 (PDT)
	mail_from (chait@getafix.engr.sgi.com)
Received: from getafix.engr.sgi.com (IDENT:chait@localhost.localdomain [127.0.0.1])
	by getafix.engr.sgi.com (8.9.3/8.9.3) with ESMTP id IAA02699;
	Mon, 9 Oct 2000 08:02:56 -0400
Message-Id: <200010091202.IAA02699@getafix.engr.sgi.com>
To:     "William L. Jones" <jones@tacc.cc.utexas.edu>
Cc:     linux-xfs@oss.sgi.com, mkp@linuxcare.com, axboe@suse.de
Subject: Re: LVM not working 
In-reply-to: Your message of "Mon, 09 Oct 2000 13:36:12 CDT."
             <4.2.0.58.20001009133513.019e6de0@127.0.0.1> 
Date:   Mon, 09 Oct 2000 08:02:56 -0400
From:   Chaitanya Tumuluri <chait@getafix.engr.sgi.com>
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, 09 Oct 2000 13:36:12 CDT, "William L. Jones" <jones@tacc.cc.utexas.edu> wrote:
>At 01:21 PM 10/9/00 -0500, Steve Lord wrote:
>> >
>> > I cannot mount a lvm file system uner linux-2.4-XFS-TEST8.  I noticed
>> > their was a patch ll_rw_blk.c to fix a lvm problem.  Could it be that
>> > it did not make into the public cvs source?
>> >
>> > Bill Jones
>>
>>
>>We have some problems with changes to the ide code at the moment in test8
>>these are about to get backed out, so the burning question is, are you using
>>ide drives?
>>
>>Steve
>
>Yes I am using IDE.  I will try to remember to include that important
>little fact next time.
>
>Bill Jones

Hi,

Okay. I'll be pulling out the combined changes to support [highmem & ide] for 
kiobuf I/O. Expect a check-in into the tree this afternoon (after I've pulled 
them out and had a chance to test these changes).

I will be checking in _only_ the highmem support for kiobuf I/O back (later
today or tomorrow) while we work out the kinks in the ide support for kiobuf 
I/O.

-Chait.

From owner-linux-xfs@oss.sgi.com Mon Oct  9 12:08:11 2000
Received:  by oss.sgi.com id <S42217AbQJITIB>;
	Mon, 9 Oct 2000 12:08:01 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:21581 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42213AbQJITHv>;
	Mon, 9 Oct 2000 12:07:51 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA00160
	for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 12:00:05 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA7211338; Mon, 9 Oct 2000 14:06:29 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id OAA41647; Mon, 9 Oct 2000 14:06:29 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id NAA29395;
	Mon, 9 Oct 2000 13:59:58 -0500
Message-Id: <200010091859.NAA29395@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     Russel Ingram <ringram@roujin.roundthestars.net>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS filesystem corrupts on umount 
In-Reply-To: Message from Russel Ingram <ringram@roujin.roundthestars.net> 
   of "Mon, 09 Oct 2000 12:00:58 MDT." <Pine.LNX.4.21.0010091150080.10473-100000@roujin.gargoylecc.com> 
Date:   Mon, 09 Oct 2000 13:59:58 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> I have seen umount related things in the archives but nothing that seems
> to match what I am experiencing here.  I just installed the kernel and xfs
> utils that come on the ProPack 1.4 CD.  I created an xfs filesytem on

Hmm, I was not aware ProPack 1.4 was actually released yet, you probably have
a beta version. We have at least one case of someone using a copy of ProPack
which predated the XFS beta. Could you please use the images from the XFS
website at http://oss.sgi.com/projects/xfs and see if this helps. Or if this
is what you are actually using please let us know.

Steve


> /dev/hda4 (now /dev/ide/host0/bus0/target0/lun0/part4) after having copied
> everything out of it to a temp dir.  The filesystem created fine and
> mounted fine.  I was even able to copy the old fs back to it with no
> problems.  I unmounted the new fs to mount it back into its normal mount
> point in the dir tree (/home), but when I went to mount it back in it gave
> be a bad superblock or too many filesystems mounted error.  xfs_check
> didn't report anything, but after running xfs_repair on it it mounted
> ok.  I umounted it again to see if the error was going to occur again and
> it did.  It seems the filesystem becomes corrupt every time umount is run
> on it.  Is this a known problem?  Is there an easy way around it?
> 
> Thanx,
> Russ
> 
> Russ Ingram
> Gargoyle Computer Consulting
> www.gargoylecc.com



From owner-linux-xfs@oss.sgi.com Mon Oct  9 12:13:51 2000
Received:  by oss.sgi.com id <S42218AbQJITNl>;
	Mon, 9 Oct 2000 12:13:41 -0700
Received: from chyndslgw1poolA164.chyn.uswest.net ([63.227.165.164]:39802 "EHLO
        roujin.gargoylecc.com") by oss.sgi.com with ESMTP id <S42213AbQJITNh>;
	Mon, 9 Oct 2000 12:13:37 -0700
Received: (from nobody@localhost)
	by roujin.gargoylecc.com (8.9.3/8.9.3) id NAA10616;
	Mon, 9 Oct 2000 13:13:16 -0600
Date:   Mon, 9 Oct 2000 13:13:16 -0600
Message-Id: <200010091913.NAA10616@roujin.gargoylecc.com>
From:   "Russel Ingram" <ringram@gargoylecc.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: Re: XFS filesystem corrupts on umount
X-Mailer: BasiliX v0.9.7 -- http://www.basilix.org
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On 10/09/2000 - 12:23, Russell Cattelan wrote:

> Hmm as long a the FS was cleanly un-mounted this should be occurring.
> Run the theca command after un-mounting the file system.
> xfs_logprint -t /dev/ide/host0/bus0/target0/lun0/part4
> 
> send us the output.

Here is the output of the xfs_logprint command:

xfs_logprint:
    data device: 0x304
    log device: 0x304 daddr: 489920 length: 9600

    log tail: 2 head: 2 state: <CLEAN>





Russ Ingram
Gargoyle Computer Consulting
(307)742-1361
www.gargoylecc.com

From owner-linux-xfs@oss.sgi.com Mon Oct  9 12:37:01 2000
Received:  by oss.sgi.com id <S42219AbQJITgv>;
	Mon, 9 Oct 2000 12:36:51 -0700
Received: from chyndslgw1poolA164.chyn.uswest.net ([63.227.165.164]:41850 "EHLO
        roujin.gargoylecc.com") by oss.sgi.com with ESMTP id <S42213AbQJITgj>;
	Mon, 9 Oct 2000 12:36:39 -0700
Received: (from nobody@localhost)
	by roujin.gargoylecc.com (8.9.3/8.9.3) id NAA10651;
	Mon, 9 Oct 2000 13:36:17 -0600
Date:   Mon, 9 Oct 2000 13:36:17 -0600
Message-Id: <200010091936.NAA10651@roujin.gargoylecc.com>
From:   "Russel Ingram" <ringram@gargoylecc.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: Re: XFS filesystem corrupts on umount 
X-Mailer: BasiliX v0.9.7 -- http://www.basilix.org
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On 10/09/2000 - 13:08, Steve Lord wrote:

> Hmm, I was not aware ProPack 1.4 was actually released yet, you probably have
> a beta version. We have at least one case of someone using a copy of ProPack
> which predated the XFS beta. Could you please use the images from the XFS
> website at http://oss.sgi.com/projects/xfs and see if this helps. Or if this
> is what you are actually using please let us know.
> 
> Steve
> 

The CD I have is the one mentioned on this page:

http://oss.sgi.com/projects/xfs/beta_propack.html

I just burned it to a CD instead of mounting it to a loopback device.

Russ
Russ Ingram
Gargoyle Computer Consulting
(307)742-1361
www.gargoylecc.com

From owner-linux-xfs@oss.sgi.com Mon Oct  9 12:41:01 2000
Received:  by oss.sgi.com id <S42220AbQJITkl>;
	Mon, 9 Oct 2000 12:40:41 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:36941 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42213AbQJITk3>; Mon, 9 Oct 2000 12:40:29 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA00412
	for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 12:47:36 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id OAA7221424; Mon, 9 Oct 2000 14:39:11 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id OAA42491; Mon, 9 Oct 2000 14:39:11 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id OAA02127;
	Mon, 9 Oct 2000 14:32:44 -0500
Message-Id: <200010091932.OAA02127@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     "Russel Ingram" <ringram@gargoylecc.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS filesystem corrupts on umount 
In-Reply-To: Message from "Russel Ingram" <ringram@gargoylecc.com> 
   of "Mon, 09 Oct 2000 13:36:17 MDT." <200010091936.NAA10651@roujin.gargoylecc.com> 
Date:   Mon, 09 Oct 2000 14:32:44 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
> On 10/09/2000 - 13:08, Steve Lord wrote:
> 
> > Hmm, I was not aware ProPack 1.4 was actually released yet, you probably ha
ve
> > a beta version. We have at least one case of someone using a copy of ProPac
k
> > which predated the XFS beta. Could you please use the images from the XFS
> > website at http://oss.sgi.com/projects/xfs and see if this helps. Or if thi
s
> > is what you are actually using please let us know.
> > 
> > Steve
> > 
> 
> The CD I have is the one mentioned on this page:
> 
> http://oss.sgi.com/projects/xfs/beta_propack.html
> 
> I just burned it to a CD instead of mounting it to a loopback device.

OK, just checking, in that case looks like you have the correct code....

Steve


> 
> Russ
> Russ Ingram
> Gargoyle Computer Consulting
> (307)742-1361
> www.gargoylecc.com



From owner-linux-xfs@oss.sgi.com Mon Oct  9 14:28:51 2000
Received:  by oss.sgi.com id <S42222AbQJIV2l>;
	Mon, 9 Oct 2000 14:28:41 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:20597 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42213AbQJIV2W>;
	Mon, 9 Oct 2000 14:28:22 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA20756
	for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 14:20:36 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id QAA7192824; Mon, 9 Oct 2000 16:26:59 -0500 (CDT)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id QAA33614; Mon, 9 Oct 2000 16:26:59 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e99LQxQ07485;
	Mon, 9 Oct 2000 16:26:59 -0500
Message-ID: <39E23822.4775662B@thebarn.com>
Date:   Mon, 09 Oct 2000 16:26:58 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-whipme5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Russel Ingram <ringram@gargoylecc.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: XFS filesystem corrupts on umount
References: <200010091913.NAA10616@roujin.gargoylecc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Russel Ingram wrote:

> On 10/09/2000 - 12:23, Russell Cattelan wrote:
>
> > Hmm as long a the FS was cleanly un-mounted this should be occurring.
> > Run the theca command after un-mounting the file system.
> > xfs_logprint -t /dev/ide/host0/bus0/target0/lun0/part4
> >
> > send us the output.
>
> Here is the output of the xfs_logprint command:
>
> xfs_logprint:
>     data device: 0x304
>     log device: 0x304 daddr: 489920 length: 9600
>
>     log tail: 2 head: 2 state: <CLEAN>

Ok good.
at least the log is indicating a clean unmount.

Guess we have to track down what else is going wrong.

BTW do you have "kio"  turned on in the mount options?
(that option isn't supported on ide drives yet)

Ok where to start.
Send us the output from xfs_repair, maybe that will give us a starting
point.

Other questions any special mkfs options? what type of ide drive do you
have?
any special partitioning?











From owner-linux-xfs@oss.sgi.com Mon Oct  9 14:41:21 2000
Received:  by oss.sgi.com id <S42225AbQJIVlC>;
	Mon, 9 Oct 2000 14:41:02 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:55416 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42213AbQJIVkv>;
	Mon, 9 Oct 2000 14:40:51 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id OAA22587
	for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 14:33:04 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA02071; Tue, 10 Oct 2000 08:38:17 +1100
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id IAA48049; Tue, 10 Oct 2000 08:38:14 +1100 (EST)
Message-Id: <200010092138.IAA48049@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     "Russel Ingram" <ringram@gargoylecc.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS filesystem corrupts on umount 
In-reply-to: Your message of "Mon, 09 Oct 2000 16:26:58 CDT."
             <39E23822.4775662B@thebarn.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 10 Oct 2000 08:38:14 +1100
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Russell Cattelan writes:

 => Ok good.
 => at least the log is indicating a clean unmount.

Also note that mount always gives the same 'wrong fs type, bad option,
bad superblock' message when the mount fails (for whatever reason). 
You'll get a better idea of what really happened by checking the messages
printed to the console or syslog when the mount failed.

Basically any more info you could send including these messages would
help us out here.

Ta
-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Mon Oct  9 14:43:32 2000
Received:  by oss.sgi.com id <S42226AbQJIVnW>;
	Mon, 9 Oct 2000 14:43:22 -0700
Received: from fepF.post.tele.dk ([195.41.46.135]:26290 "EHLO
        fepF.post.tele.dk") by oss.sgi.com with ESMTP id <S42213AbQJIVnD>;
	Mon, 9 Oct 2000 14:43:03 -0700
Received: from burns.home.kernel.dk ([195.249.94.204]) by fepF.post.tele.dk
          (InterMail vM.4.01.03.00 201-229-121) with ESMTP
          id <20001009214302.ZRGH336.fepF.post.tele.dk@burns.home.kernel.dk>;
          Mon, 9 Oct 2000 23:43:02 +0200
Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian))
	id 13ikhP-0002Q4-00; Mon, 09 Oct 2000 23:43:07 +0200
Date:   Mon, 9 Oct 2000 23:43:07 +0200
From:   Jens Axboe <axboe@suse.de>
To:     Chaitanya Tumuluri <chait@getafix.engr.sgi.com>
Cc:     "William L. Jones" <jones@tacc.cc.utexas.edu>,
        linux-xfs@oss.sgi.com, mkp@linuxcare.com
Subject: Re: LVM not working
Message-ID: <20001009234307.C9152@suse.de>
References: <4.2.0.58.20001009133513.019e6de0@127.0.0.1> <200010091202.IAA02699@getafix.engr.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200010091202.IAA02699@getafix.engr.sgi.com>; from chait@getafix.engr.sgi.com on Mon, Oct 09, 2000 at 08:02:56AM -0400
X-OS:   Linux 2.4.0-test9 i686
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, Oct 09 2000, Chaitanya Tumuluri wrote:
> I will be checking in _only_ the highmem support for kiobuf I/O back (later
> today or tomorrow) while we work out the kinks in the ide support for kiobuf 
> I/O.

Just so everyone knows exactly what kinks -- the IDE kiobuf code had
"issues" in pure pio transfers due to some imaginative request handling
in those cases. It's mostly nailed down, I'm nursing it to not change
too much of the lowlevel IDE path.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs

From owner-linux-xfs@oss.sgi.com Mon Oct  9 17:11:42 2000
Received:  by oss.sgi.com id <S42227AbQJJALd>;
	Mon, 9 Oct 2000 17:11:33 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40038 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42213AbQJJAK7>; Mon, 9 Oct 2000 17:10:59 -0700
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA04035
	for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 17:17:27 -0700 (PDT)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA86017 for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 17:05:19 -0700 (PDT)
Message-ID: <39E25E97.A936D463@sgi.com>
Date:   Mon, 09 Oct 2000 17:11:03 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: kmap_high/flush_tlb_all/smp_call_function problem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


[ I sent this mail out to linux-kernel earlier, since
  it seems to be a generic kernel/X86 problem. Wondering
  if anyone on the xfs mailing list has any ideas on
  how to proceed ... ]


We are running some fairly intensive tests with XFS
and with HIGHMEM on an X86 machine with 4G of memory and
4 cpus. The linux-kernel version is test8. The code
also contains Stephen Tweedie's highmem-kiobuf.

What we see is that after a while of running,
smp_call_function getting stuck in the loop below:

---------- arch/i386/kernel/smp.c -----------
    463         /* Wait for response */
    464         while (atomic_read(&data.started) != cpus)
    465                 barrier();
---------------------------------------------

The cpu is stuck because the number of cpus which have
joined the barrier is not 3 (n-1 == 4-1 == 3) ... this
smells of a race. As can be seen below, all the cpus are fine,
and in fact have responded to the IPI which kdb generated
subsequent to the NMI watchdog ...

The kdb stack trace on the stuck cpu (cpu 0) is as follows.
The other cpus are stuck on the kmap_lock. The system
got into kdb because of the NMI watchdog kicking-in on
cpu 1 because of the long wait on the kmap_lock.
Are there any known problems being pursued w.r.t
flush_tlb_all/kmap_high? If you need any more info, please
let me know.

Backtraces:
---------------------------------------------
[0]kdb> bt
    EBP       EIP         Function(args)
           0xc0278abd stext_lock+0x1955
                               kernel .text.lock 0xc0277168 0xc0277168 0xc027dac0
0xe3571eb4 0xc013350b kmap_high+0xb (0x2a2, 0xc324f978, 0x2a2)
                               kernel .text 0xc0100000 0xc0133500 0xc0133674
0xe3571ef4 0xc0137e88 __block_prepare_write+0x5c (0xe9629820, 0xc324f978, 0x2a2, 0x2fc,
0xc0156a4c)
                               kernel .text 0xc0100000 0xc0137e2c 0xc013803c
0xe3571f18 0xc01386c1 block_prepare_write+0x21 (0xc324f978, 0x2a2, 0x2fc, 0xc0156a4c)
                               kernel .text 0xc0100000 0xc01386a0 0xc0138724
0xe3571f30 0xc0157189 ext2_prepare_write+0x19 (0xf69618c0, 0xc324f978, 0x2a2, 0x2fc, 0xf69618c0)
                               kernel .text 0xc0100000 0xc0157170 0xc0157190
0xe3571f98 0xc012c461 generic_file_write+0x2b9 (0xf69618c0, 0x40019000, 0x5a, 0xf69618e0,
0xe3570000)
                               kernel .text 0xc0100000 0xc012c1a8 0xc012c5c0
0xe3571fbc 0xc0135658 sys_write+0x98 (0x6f, 0x40019000, 0x5a, 0x5a, 0x40019000)
                               kernel .text 0xc0100000 0xc01355c0 0xc0135670
           0xc010a77b system_call+0x33
                               kernel .text 0xc0100000 0xc010a748 0xc010a780
[0]kdb> 
[0]kdb> cpu 1

Entering kdb (current=0xe15f4000, pid 8178) on processor 1 due to cpu switch
[1]kdb> bt
    EBP       EIP         Function(args)
           0xc0278add stext_lock+0x1975
                               kernel .text.lock 0xc0277168 0xc0277168 0xc027dac0
0xe15f5cd8 0xc0133679 kunmap_high+0x5
                               kernel .text 0xc0100000 0xc0133674 0xc0133710
0xe15f5d00 0xc0166472 _pagebuf_handle_iovecs+0x2b2 (0xe15f5ee0, 0xc314c754, 0x1000, 0x31000,
0x0)
                               kernel .text 0xc0100000 0xc01661c0 0xc016648c
0xe15f5d2c 0xc01664b2 _pagebuf_iomove_apply+0x26 (0xe15f5ee0, 0xd9493540, 0x31000, 0x0,
0xc314c754)
                               kernel .text 0xc0100000 0xc016648c 0xc01664bc
0xe15f5d90 0xc01657c4 pagebuf_segment_apply+0x234 (0xc016648c, 0xe15f5ee0, 0xd9493540, 0x0,
0x20000)
                               kernel .text 0xc0100000 0xc0165590 0xc016581c
0xe15f5dbc 0xc01667ad _pb_buffered_read+0xed (0xe0e19860, 0x30000, 0x0, 0x10000, 0xe15f5e30)
                               kernel .text 0xc0100000 0xc01666c0 0xc01667c4
0xe15f5e4c 0xc0166b61 pagebuf_file_read+0x225 (0xe218dce0, 0xe15f5ee0, 0xe16d5304, 0x1,
0xe0e19860)
                               kernel .text 0xc0100000 0xc016693c 0xc0166c08
0xe15f5e74 0xc01c0a12 linvfs_file_read+0x32 (0xe218dce0, 0xe15f5ee0)
                               kernel .text 0xc0100000 0xc01c09e0 0xc01c0a30
0xe15f5eac 0xc012a1fc do_generic_file_read+0xe8 (0xe218dce0, 0xe218dd00, 0xe15f5ee0, 0xc0166c08)
                               kernel .text 0xc0100000 0xc012a114 0xc012a618
0xe15f5f1c 0xc0166cfb pagebuf_generic_file_read+0xc3 (0xe218dce0, 0x41dc9200, 0x38000,
0xe218dd00)
                               kernel .text 0xc0100000 0xc0166c38 0xc0166d4c
0xe15f5f44 0xc01c12a8 xfs_rdwr+0x48 (0xe16d5304, 0xe218dce0, 0x41dc9200, 0x38000, 0xe218dd00)
                               kernel .text 0xc0100000 0xc01c1260 0xc01c12d4
[1]more> 
0xe15f5f70 0xc01c1325 xfs_read+0x51 (0xe16d5304, 0xe218dce0, 0x41dc9200, 0x38000, 0xe218dd00)
                               kernel .text 0xc0100000 0xc01c12d4 0xc01c1330
0xe15f5f98 0xc01be202 linvfs_read+0x62 (0xe218dce0, 0x41dc9200, 0x38000, 0xe218dd00, 0xe15f4000)
                               kernel .text 0xc0100000 0xc01be1a0 0xc01be20c
0xe15f5fbc 0xc01355a8 sys_read+0x94 (0x3d, 0x41dc9200, 0x38000, 0x38000, 0x41dc9200)
                               kernel .text 0xc0100000 0xc0135514 0xc01355c0
           0xc010a77b system_call+0x33
                               kernel .text 0xc0100000 0xc010a748 0xc010a780
[1]kdb> cpu 2

Entering kdb (current=0xe24dc000, pid 8180) on processor 2 due to cpu switch
[2]kdb> bt
    EBP       EIP         Function(args)
0xe24ddc74 0xc0112f48 smp_call_function+0x84 (0xc0112db8, 0x0, 0x1, 0x1)
                               kernel .text 0xc0100000 0xc0112ec4 0xc0112f7c
0xe24ddc90 0xc0112e1c flush_tlb_all+0x14
                               kernel .text 0xc0100000 0xc0112e08 0xc0112e68
0xe24ddca4 0xc01334f6 flush_all_zero_pkmaps+0x7a (0x0)
                               kernel .text 0xc0100000 0xc013347c 0xc0133500
0xe24ddcd8 0xc01335c6 kmap_high+0xc6
                               kernel .text 0xc0100000 0xc0133500 0xc0133674
0xe24ddd00 0xc0166248 _pagebuf_handle_iovecs+0x88 (0xe24ddee0, 0xc3118940, 0x0, 0x39000, 0x0)
                               kernel .text 0xc0100000 0xc01661c0 0xc016648c
0xe24ddd2c 0xc01664b2 _pagebuf_iomove_apply+0x26 (0xe24ddee0, 0xe0294a20, 0x39000, 0x0,
0xc3118940)
                               kernel .text 0xc0100000 0xc016648c 0xc01664bc
0xe24ddd90 0xc01657c4 pagebuf_segment_apply+0x234 (0xc016648c, 0xe24ddee0, 0xe0294a20, 0x0,
0x8000)
                               kernel .text 0xc0100000 0xc0165590 0xc016581c
0xe24dddbc 0xc01667ad _pb_buffered_read+0xed (0xe0b98c60, 0x32000, 0x0, 0x8000, 0xe24dde30)
                               kernel .text 0xc0100000 0xc01666c0 0xc01667c4
0xe24dde4c 0xc0166b61 pagebuf_file_read+0x225 (0xe20ce140, 0xe24ddee0, 0xe1785ab4, 0x1,
0xe0b98c60)
                               kernel .text 0xc0100000 0xc016693c 0xc0166c08
0xe24dde74 0xc01c0a12 linvfs_file_read+0x32 (0xe20ce140, 0xe24ddee0)
                               kernel .text 0xc0100000 0xc01c09e0 0xc01c0a30
0xe24ddeac 0xc012a1fc do_generic_file_read+0xe8 (0xe20ce140, 0xe20ce160, 0xe24ddee0, 0xc0166c08)
                               kernel .text 0xc0100000 0xc012a114 0xc012a618
[2]more> 
0xe24ddf1c 0xc0166cfb pagebuf_generic_file_read+0xc3 (0xe20ce140, 0x41dc9200, 0x38000,
0xe20ce160)
                               kernel .text 0xc0100000 0xc0166c38 0xc0166d4c
0xe24ddf44 0xc01c12a8 xfs_rdwr+0x48 (0xe1785ab4, 0xe20ce140, 0x41dc9200, 0x38000, 0xe20ce160)
                               kernel .text 0xc0100000 0xc01c1260 0xc01c12d4
0xe24ddf70 0xc01c1325 xfs_read+0x51 (0xe1785ab4, 0xe20ce140, 0x41dc9200, 0x38000, 0xe20ce160)
                               kernel .text 0xc0100000 0xc01c12d4 0xc01c1330
0xe24ddf98 0xc01be202 linvfs_read+0x62 (0xe20ce140, 0x41dc9200, 0x38000, 0xe20ce160, 0xe24dc000)
                               kernel .text 0xc0100000 0xc01be1a0 0xc01be20c
0xe24ddfbc 0xc01355a8 sys_read+0x94 (0x3a, 0x41dc9200, 0x38000, 0x38000, 0x41dc9200)
                               kernel .text 0xc0100000 0xc0135514 0xc01355c0
           0xc010a77b system_call+0x33
                               kernel .text 0xc0100000 0xc010a748 0xc010a780
[2]kdb> cpu 3

Entering kdb (current=0xe2668000, pid 8182) on processor 3 due to cpu switch
[3]kdb> bt
    EBP       EIP         Function(args)
           0xc0278abd stext_lock+0x1955
                               kernel .text.lock 0xc0277168 0xc0277168 0xc027dac0
0xe2669e14 0xc013350b kmap_high+0xb
                               kernel .text 0xc0100000 0xc0133500 0xc0133674
0xe2669e3c 0xc0166248 _pagebuf_handle_iovecs+0x88 (0xe2669ee0, 0xc3064d54, 0x0, 0x8000, 0x0)
                               kernel .text 0xc0100000 0xc01661c0 0xc016648c
0xe2669e6c 0xc0166c2d _pagebuf_read_helper+0x25 (0xe2669ee0, 0xc3064d54, 0x0, 0x1000)
                               kernel .text 0xc0100000 0xc0166c08 0xc0166c38
0xe2669eac 0xc012a334 do_generic_file_read+0x220 (0xe34c74a0, 0xe34c74c0, 0xe2669ee0,
0xc0166c08)
                               kernel .text 0xc0100000 0xc012a114 0xc012a618
0xe2669f1c 0xc0166cfb pagebuf_generic_file_read+0xc3 (0xe34c74a0, 0x41d88200, 0x38000,
0xe34c74c0)
                               kernel .text 0xc0100000 0xc0166c38 0xc0166d4c
0xe2669f44 0xc01c12a8 xfs_rdwr+0x48 (0xe180d470, 0xe34c74a0, 0x41d88200, 0x38000, 0xe34c74c0)
                               kernel .text 0xc0100000 0xc01c1260 0xc01c12d4
0xe2669f70 0xc01c1325 xfs_read+0x51 (0xe180d470, 0xe34c74a0, 0x41d88200, 0x38000, 0xe34c74c0)
                               kernel .text 0xc0100000 0xc01c12d4 0xc01c1330
0xe2669f98 0xc01be202 linvfs_read+0x62 (0xe34c74a0, 0x41d88200, 0x38000, 0xe34c74c0, 0xe2668000)
                               kernel .text 0xc0100000 0xc01be1a0 0xc01be20c
0xe2669fbc 0xc01355a8 sys_read+0x94 (0x31, 0x41d88200, 0x38000, 0x38000, 0x41d88200)
                               kernel .text 0xc0100000 0xc0135514 0xc01355c0
           0xc010a77b system_call+0x33
                               kernel .text 0xc0100000 0xc010a748 0xc010a780


-- 
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Mon Oct  9 22:48:53 2000
Received:  by oss.sgi.com id <S42231AbQJJFsn>;
	Mon, 9 Oct 2000 22:48:43 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:12890 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42213AbQJJFsP>;
	Mon, 9 Oct 2000 22:48:15 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA11041
	for <linux-xfs@oss.sgi.com>; Mon, 9 Oct 2000 22:39:48 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA15679
	for linux-xfs@oss.sgi.com; Tue, 10 Oct 2000 16:46:16 +1100 (EST)
Date:   Tue, 10 Oct 2000 16:46:16 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010100546.QAA15679@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - quota
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

I need to start tracking my changes to the quota utilities for
XFS - this is the current Linux source, with no changes as yet.


$ cat README.xfs

This is the current version of the Linux quota utilities - I'll be
making changes to support XFS here, then sending the patches on to
Marco when it's complete.  This version (2.00pre10) was downloaded
on October 10th, '00 from:
        ftp://ftp.cistron.nl/pub/people/mvw/quota/

Marco van Wieringen <mvw@planets.elm.net> is the Linux quota utilities
maintainer.  Send mail to <linux-xfs@oss.sgi.com> for any queries
about the changes to support XFS.



Modid:  2.4.x-xfs:slinx:75972a
Date:  Mon Oct  9 22:40:25 PDT 2000
Workarea:  snort:/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/quota/README.xfs - 1.1
	- notes about the current version of the quota utilities.

cmd/quota/Changelog - 1.1
cmd/quota/Makefile.in - 1.1
cmd/quota/README.gettext - 1.1
cmd/quota/bylabel.c - 1.1
cmd/quota/bylabel.h - 1.1
cmd/quota/configure - 1.1
cmd/quota/configure.in - 1.1
cmd/quota/doc/edquota(8).html - 1.1
cmd/quota/doc/fstab(5).html - 1.1
cmd/quota/doc/quota(1).html - 1.1
cmd/quota/doc/quota.html - 1.1
cmd/quota/doc/quota4th.fig - 1.1
cmd/quota/doc/quotacheck(8).html - 1.1
cmd/quota/doc/quotactl(2).html - 1.1
cmd/quota/doc/quotaon(8).html - 1.1
cmd/quota/doc/quotas-1.eps - 1.1
cmd/quota/doc/quotas.ms - 1.1
cmd/quota/doc/quotas.preformated - 1.1
cmd/quota/doc/repquota(8).html - 1.1
cmd/quota/doc/rquotad(8).html - 1.1
cmd/quota/dqblk.h - 1.1
cmd/quota/edquota.8 - 1.1
cmd/quota/edquota.c - 1.1
cmd/quota/hasquota.c - 1.1
cmd/quota/install-sh - 1.1
cmd/quota/mntent.h - 1.1
cmd/quota/po/pl.mo - 1.1
cmd/quota/po/pl.po - 1.1
cmd/quota/pot.c - 1.1
cmd/quota/pot.h - 1.1
cmd/quota/quota.1 - 1.1
cmd/quota/quota.c - 1.1
cmd/quota/quotacheck.8 - 1.1
cmd/quota/quotacheck.c - 1.1
cmd/quota/quotactl.2 - 1.1
cmd/quota/quotactl.c - 1.1
cmd/quota/quotaio.c - 1.1
cmd/quota/quotaon.8 - 1.1
cmd/quota/quotaon.c - 1.1
cmd/quota/quotaops.c - 1.1
cmd/quota/quotaops.h - 1.1
cmd/quota/quotastats.c - 1.1
cmd/quota/repquota.8 - 1.1
cmd/quota/repquota.c - 1.1
cmd/quota/rquota.3 - 1.1
cmd/quota/rquota.h - 1.1
cmd/quota/rquota.x - 1.1
cmd/quota/rquota_client.c - 1.1
cmd/quota/rquota_clnt.c - 1.1
cmd/quota/rquota_server.c - 1.1
cmd/quota/rquota_svc.c - 1.1
cmd/quota/rquota_xdr.c - 1.1
cmd/quota/rquotad.8 - 1.1
cmd/quota/set_limits_example.c - 1.1
cmd/quota/setquota.8 - 1.1
cmd/quota/setquota.c - 1.1
cmd/quota/setup_quota_group - 1.1
cmd/quota/warnquota.c - 1.1
	- source from Linux quota utilities, version 2.00pre10.
	  refer to the source for full licensing details of each file.


From owner-linux-xfs@oss.sgi.com Tue Oct 10 01:12:23 2000
Received:  by oss.sgi.com id <S42230AbQJJIMN>;
	Tue, 10 Oct 2000 01:12:13 -0700
Received: from plutonium.uunet.be ([194.7.1.47]:62983 "EHLO plutonium.uunet.be")
	by oss.sgi.com with ESMTP id <S42213AbQJJILo>;
	Tue, 10 Oct 2000 01:11:44 -0700
Received: from gate.vum.be (firewall.vum.be [194.7.240.162])
	by plutonium.uunet.be (8.9.1/8.9.3) with SMTP id KAA14321
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 10:11:00 +0200 (CEST)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id KAA24879 for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 10:12:47 +0200 (METDST)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id KAA18112
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 10:10:29 +0200
Message-ID: <39E2CEF5.7F7ADF7@vum.be>
Date:   Tue, 10 Oct 2000 10:10:29 +0200
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: RE: LVM not working...in my case xfs_growfs trouble
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

SGksDQoNCg0KZmlyc3Qgb2ZmIGFsbCwgSSBoYXZlIHNlZW4gdHJvdWJsZSB3aXRoIGx2bSBv
biBhIHNjc2kgZGlzay4NCkFmdGVyIEkgaGF2ZSBtYWRlIHN1Y2Nlc3NmdWxseSBhIGxvZ2lj
YWwgdm9sdW1lIG9uIGEgSmF6IGRpc2ssIEkgbWFkZSBhbg0KWEZTIGZpbGVzeXN0ZW0gb24g
aXQuDQpUaGlzIHdhcyBhbGwgb2sgLi4uDQpOZXh0IEkgdHJpZWQgdG8gZXh0ZW5kbHYgKCB0
byBtYWtlIHRoZSBsb2dpY2FsIHZvbHVtZSBiaWdnZXIpIHRoYXQNCndvcmtlZC4NCg0KYnV0
IHRoZW4gSSB0cmllZCB4ZnNfZ3Jvd2ZzLi4uIHRoaXMgcmVzdWx0ZWQgaW4gYSBuby1vcCwg
YW5kIGEgaGFuZyBvbg0KdGhhdCBwcm9jZXNzLCBJIGNvdWxkIHVubW91bnQgaXQgb3IgbW91
bnQgaXQgYWdhaW4sIGJ1dCBub3RoaW5nIG1vdmVkLi4uDQoNCklzIHRoaXMgZnVsbHkgZnVu
Y3Rpb25hbCBhdCB0aGUgbW9tZW50IG9yIGFyZSB0aGVlciBhbnkgaXNzdWVzID8NCg0KYnR3
LCBJIGFtIHVzaW5nIGdjYyAyLjk1LjIgYW5kIGFuIHhmcyB2b2x1bWUgKHdpdGhvdXQgTFZN
KSB3b3JrcyBmaW5lDQouLi4NCg0KDQoNCg0K

From owner-linux-xfs@oss.sgi.com Tue Oct 10 07:26:35 2000
Received:  by oss.sgi.com id <S42235AbQJJO00>;
	Tue, 10 Oct 2000 07:26:26 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49166 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42215AbQJJO0B>; Tue, 10 Oct 2000 07:26:01 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA03402
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 07:32:29 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA7214881 for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 09:24:04 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id JAA89301 for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 09:24:04 -0500 (CDT)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id JAA22449
	for linux-xfs@oss.sgi.com; Tue, 10 Oct 2000 09:17:29 -0500
Date:   Tue, 10 Oct 2000 09:17:29 -0500
From:   Steve Lord <lord@sgi.com>
Message-Id: <200010101417.JAA22449@jen.americas.sgi.com>
Subject: TAKE - fix the way xfs does module reference counting
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

XFS was using the old racey style of module reference counting

Date:  Tue Oct 10 07:23:25 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-clean

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:75981a
linux/fs/xfs/linux/xfs_super.c - 1.94
	- Make xfs do module reference counting the correct way (from outside the
	  module)



From owner-linux-xfs@oss.sgi.com Tue Oct 10 07:27:55 2000
Received:  by oss.sgi.com id <S42236AbQJJO1q>;
	Tue, 10 Oct 2000 07:27:46 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:59150 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42215AbQJJO1c>; Tue, 10 Oct 2000 07:27:32 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA02480
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 07:34:00 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA7101858 for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 09:25:35 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id JAA89700 for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 09:25:35 -0500 (CDT)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id JAA22520
	for linux-xfs@oss.sgi.com; Tue, 10 Oct 2000 09:18:55 -0500
Date:   Tue, 10 Oct 2000 09:18:55 -0500
From:   Steve Lord <lord@sgi.com>
Message-Id: <200010101418.JAA22520@jen.americas.sgi.com>
Subject: TAKE - fix to sv_wait implementation
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Tue Oct 10 07:25:11 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-clean

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:75982a
linux/fs/xfs/linux/xfs_locks.c - 1.22
	- Make sv_wait and sv_signal operate as a FIFO rather than as a LIFO



From owner-linux-xfs@oss.sgi.com Tue Oct 10 07:43:06 2000
Received:  by oss.sgi.com id <S42237AbQJJOm4>;
	Tue, 10 Oct 2000 07:42:56 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:26167 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42215AbQJJOm3>;
	Tue, 10 Oct 2000 07:42:29 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA20617
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 07:34:03 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id JAA6518406 for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 09:39:17 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id JAA90429 for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 09:39:17 -0500 (CDT)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id JAA23176
	for linux-xfs@oss.sgi.com; Tue, 10 Oct 2000 09:32:42 -0500
Date:   Tue, 10 Oct 2000 09:32:42 -0500
From:   Steve Lord <lord@sgi.com>
Message-Id: <200010101432.JAA23176@jen.americas.sgi.com>
Subject: TAKE - some linvfs layer cleanup
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

The linvfs layer is supposed to be XFS neutral, this heads it back in
that direction, there had been some xfs creep appearing. the bmap call
is still xfs specific though.

Date:  Tue Oct 10 07:38:27 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-clean

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:75983a
linux/fs/xfs/xfs_rw.h - 1.57
	- remove dead prototypes

linux/fs/xfs/xfs_vnodeops.c - 1.477
	- Extensions to rwlock interface for trylock variants

linux/fs/xfs/linux/xfs_lrw.c - 1.60
	- Make VOP_BMAP use the PBF_BMAP_TRY_ILOCK call directly.

linux/fs/xfs/linux/xfs_file.c - 1.35
	- Remove some unneeded dir ops

linux/fs/xfs/linux/xfs_iops.c - 1.73
	- Remove direct references to xfs structures from several linvfs functions,
	  more still to come.

linux/fs/pagebuf/page_buf_io.c - 1.31
	- Look for EAGAIN as a negative return code since it was previously the
	  only error returned as a positive value.

linux/fs/xfs/linux/xfs_vnode.h - 1.4
	- Extensions to rwlock interface for trylock variants



From owner-linux-xfs@oss.sgi.com Tue Oct 10 11:01:26 2000
Received:  by oss.sgi.com id <S42251AbQJJSBQ>;
	Tue, 10 Oct 2000 11:01:16 -0700
Received: from [62.208.77.1] ([62.208.77.1]:14930 "EHLO
        desdc01.globalnewmedia.de") by oss.sgi.com with ESMTP
	id <S42215AbQJJSAs>; Tue, 10 Oct 2000 11:00:48 -0700
Received: from 192.168.102.10 (docs.globalnewmedia.de [62.208.77.200]) by desdc01.globalnewmedia.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3)
	id TVBG0QVZ; Tue, 10 Oct 2000 00:03:45 +0200
Content-type: text/html
Date:   Mon, 09 Oct 2000 18:12:38 +0200
From:   affiliation@digitall.fr
Subject: programme d'affiliation
To:     linux-xfs@oss.sgi.com
Message-Id: <20001010180051Z42215-31375+1516@oss.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


<html>
<head><title></title></head>
<body bgcolor="FFFFFF" leftmargin=0 rightmargin=0 topmargin=0 marginwidth=0 marginheight=0>
<table border=0 cellspacing=0 cellpadding=0 bgcolor="white" width=640>
<tr>
<td rowspan=10 width=20><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=20 height=30></td>
	<td valign="middle" height="90" align="left">
		<img src="http://www.digitall.fr/images/mailing/logo-aff.gif" width="156" height="67" border="0">
	</td>
</tr>

<tr><td><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=1 height=25></td></tr>
<tr><td><font face="verdana,arial,geneva" color="black" size=2>Madame, Monsieur,</font></td></tr>
<tr><td><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=1 height=15></td></tr>
<tr>
<td>
<img src="http://www.digitall.fr/images/mailing/qui.gif" border=0><br>
<img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=1 height=15><br>
<font face="verdana,arial,geneva" color="black" size=2>Activit&eacute; multim&eacute;dia du groupe Lagard&egrave;re,
 digitall.fr vous fait profiter de l'exp&eacute;rience d'un des premiers groupes mondiaux du multim&eacute;dia. Le catalogue
digitall.fr vous offre la plus large vision des loisirs num&eacute;riques et des nouveaut&eacute;s dans tous les secteurs
 avec plus de 600 000 produits r&eacute;f&eacute;renc&eacute;s.
</font><br>
<img src="http://www.digitall.fr/images/mailing/fleche-rond.gif" border=0>&nbsp;&nbsp;<font face="verdana,arial,geneva" color="black" size=3><b>Vous avez un site Web personnel ou professionnel ?</b><br><br>
<font size=2>Offrez la possibilité à vos visiteurs de gagner du temps en leur proposant directement sur votre site les produits dont ils ont besoin. 
Enrichissez son contenu et augmentez votre offre en proposant de la musique, des DVD, des jeux vidéos et CD-Rom parmi plus de 600000 références multimédias !!!
<br><br>
<b>Pour chaque vente générée, vous toucherez bien sûr une commission proportionnelle au montant d'affaires que vous réaliserez chaque mois. </b><br><br>
Le programme digitall est un programme d'affiliation qui vous permet de pointer vers des références extraites de <a href="http://www.digitall.fr"><font color="ff6600">digitall.fr</font></a>. Pour chaque vente générée depuis votre site Web, vous touchez une commission selon le bar&ecirc;me ci-dessous:<br><br>

</font>
</font>
</td>
</tr>
</table>

<table border=0 cellspacing=0 cellpadding=0 bgcolor="white" width=200>
<tr>
<td rowspan=6><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=50 height=1></td>
<td colspan=2><font color="black" size=1 face="verdana,arial,geneva"><b>CA mensuel g&eacute;n&eacute;r&eacute;</b></font><br><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=1 height=5></td>
</tr>
<tr>
<td width=150 bgcolor="white"><font color="black" size=2 face="verdana,arial,geneva"><b>&nbsp;&nbsp; 0 &agrave; 7500 F</b></font></td>
<th width=50 bgcolor="white"><font color="black" size=2 face="verdana,arial,geneva"><b> 5 %</b></font></th>
</tr>
<tr><td colspan=2><img src="http://www.digitall.fr/images/mailing/filet-rond.gif" border=0 width=200 height=5></td></tr>
<tr>
<td width=150 bgcolor="white"><font color="black" size=2 face="verdana,arial,geneva"><b>&nbsp;&nbsp; 7501 &agrave; 30 000 F</b></font></td>
<th width=50 bgcolor="white"><font color="black" size=2 face="verdana,arial,geneva"><b> 8 %</b></font></th>
</tr>
<tr><td colspan=2><img src="http://www.digitall.fr/images/mailing/filet-rond.gif" border=0 width=200 height=5></td></tr>
<tr>
<td width=150 bgcolor="white"><font color="black" size=2 face="verdana,arial,geneva"><b>&nbsp;&nbsp; > 30 000 F</b></font></td>
<th width=50 bgcolor="white"><font color="black" size=2 face="verdana,arial,geneva"><b> 10 %</b></font></th>
</tr>
</table>

<table border=0 cellspacing=0 cellpadding=0 bgcolor="white" width=640>
<tr>
<td rowspan=4 width=20><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=20 height=30></td>
<td><br></td>
</tr>
<tr>
<td>
<font face="verdana,arial,geneva" color="black" size=2>
De plus digitall vous donne &eacute;galement la possibilit&eacute; d'&ecirc;tre r&eacute;mun&eacute;r&eacute; sur des demandes faites par vos internautes du catalogue digitall :
 pour tout bon de commande dûment rempli via un lien ad&eacute;quat mis en place sur votre site, vous toucherez 5 F.
</font>
</td>
</tr>

</table>

<table border=0 cellspacing=0 cellpadding=0 bgcolor="white" width=640>
<tr><td rowspan=20 width=20><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=20 height=30></td><td colspan=2><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=1 height=40></td></tr>
<tr>
<td colspan=2><img src="http://www.digitall.fr/images/mailing/plus.gif" border=0><br>
<font face="verdana,arial,geneva" size=2 color="black"><b>Un internaute achète très rarement lors de sa première visite, vous serez donc rémunéré pour toutes les commandes passées directement sur digitall.fr des  internautes ayant été au préalable identifiés via votre site sur une durée de deux mois !</b></font><br><br><br>
</td>
</tr>
<tr>
<td colspan=2><img src="http://www.digitall.fr/images/mailing/partenaire.gif" border=0><br><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=1 height=15><br></td>
</tr>
<tr>
<td valign="top"><img src="http://www.digitall.fr/images/mailing/bloc-fleche.gif" border=0><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=10 height=1></td>
<td valign="top"><font face="verdana,arial,geneva" size=2 color="black">
Donnez la possibilité à vos internautes d'accéder en quelques clics au plus grand catalogue de produits multimédias du marché sans vous soucier des aspects fastidieux de la vente en ligne !
</font></td>
</tr>
<tr><td><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=1 height=15></td></tr>
<tr>
<td valign="top"><img src="http://www.digitall.fr/images/mailing/bloc-fleche.gif" border=0><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=10 height=1></td>
<td valign="top"><font face="verdana,arial,geneva" size=2 color="black">
bénéficiez d'un système de rémunération attrayant et unique sur le marché : vous percevez non seulement des commissions sur les ventes conclues à partir de votre site mais également sur les ventes conclues directement  sur le site de digitall.fr  pendant une période de deux mois par des internautes identifiés au préalable via votre site !
</font></td>
</tr>
<tr><td><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=1 height=15></td></tr>
<tr>
<td valign="top"><img src="http://www.digitall.fr/images/mailing/bloc-fleche.gif" border=0><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=10 height=1></td>
<td valign="top"><font face="verdana,arial,geneva" size=2 color="black">
Consultez au jour le jour le montant de vos commissions dues grâce à l'espace reporting " digitall affilié " que nous mettons gracieusement à votre disposition.
</font></td>
</tr>
<tr><td><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=1 height=15></td></tr>
<tr>
<td valign="top" ><img src="http://www.digitall.fr/images/mailing/bloc-fleche.gif" border=0><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=10 height=1></td>
<td valign="top"><font face="verdana,arial,geneva" size=2 color="black">
Enrichissez gratuitement et facilement le contenu de votre site et dopez son image en l'associant à celle de digitall.fr. La qualité de notre service et la richesse de notre offre éditoriale sont des atouts qui séduiront et fidéliseront vos visiteurs.
</font></td>
</tr>
<tr><td><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=1 height=15></td></tr>
<tr>
<td valign="top" ><img src="http://www.digitall.fr/images/mailing/bloc-fleche.gif" border=0><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=10 height=1></td>
<td valign="top"><font face="verdana,arial,geneva" size=2 color="black">
C'est simple, gratuit et cela ne vous engage à rien : vous pouvez quitter notre programme d'affiliation quand vous le désirez !
</font></td>
</tr>
<tr><td colspan=2><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=1 height=15></td></tr>

<tr><td colspan=2><font face="verdana,arial,geneva" size=2 color="black"><b>Vous voulez vous inscrire ou tout simplement b&eacute;n&eacute;ficier d'informations suppl&eacute;mentaires? </b>
Rien de plus simple! Je vous engage &agrave; vous connecter sur <a href="http://www.digitall.fr"><font color="ff6600">www.digitall.fr</font></a> et cliquer sur notre "espace affili&eacute;".<br><br>
En vous souhaitant bonne r&eacute;ception.<br><br>
Cordialement.<br><br>
Benjamin Lohou<br><br>
Chef de Projet Marketing<br><br>
benjamin.lohou@grolier.fr<br><br>
 <a href="http://www.digitall.fr"><font color="ff6600">www.digitall.fr</font></a><br><br>
</font></td></tr>
<tr><td><br></td></tr>

<tr width="20"><td><img src="http://www.digitall.fr/images/mailing/1pixel-trans.gif" border=0 width=1 height=20></td></tr>


</table>

</body>
</html>



From owner-linux-xfs@oss.sgi.com Tue Oct 10 12:01:06 2000
Received:  by oss.sgi.com id <S42253AbQJJTA4>;
	Tue, 10 Oct 2000 12:00:56 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:59652 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42215AbQJJTAZ>;
	Tue, 10 Oct 2000 12:00:25 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA25935; Tue, 10 Oct 2000 11:51:44 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id LAA55402;
	Tue, 10 Oct 2000 11:59:29 -0700 (PDT)
Date:   Tue, 10 Oct 2000 11:59:29 -0700 (PDT)
Message-Id: <200010101859.LAA55402@info.engr.sgi.com>
X-Pv-Incident: 804398 
webPV:  gibble.americas.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (cattelan@engr.sgi.com)
Subject: BUG 804398 - XFS hits BUG call in pagebuf_read_full_page
To:     cattelan@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804398

Submitter : cattelan                  Submitter Domain : engr               
Assigned Engineer : cattelan          Assigned Domain : engr                
Assigned Group : xfs-linux            Category : software                   
Customer Reported : T                 Priority : 2                          
Project : xfs-linux                   Status : open                         
Description :
The problem appears to be a page that was orginaly delay alloc
(the underlying disk blocks cam back as zero) but has either
been reused or its state has been cleared.

I don't have all the kbd output... I;ll add to it as
I capture more traces.

[0]kdb> bt
    EBP       EIP         Function(args)
0xc4c13e58 0xc880c914 [pagebuf]pagebuf_read_full_page+0x198 (0xc49eeb60, 0xc11939ac)
                               pagebuf .text 0xc8809060 0xc880c77c 0xc880ca90
0xc4c13e74 0xc886b06a [xfs]linvfs_read_full_page+0xb2 (0xc49eeb60, 0xc11939ac)
                               xfs .text 0xc8814060 0xc886afb8 0xc886b080
0xc4c13eac 0xc0126f80 do_generic_file_read+0x2bc (0xc49eeb60, 0xc49eeb80, 0xc4c13ee0, 0xc880c4a8)
                               kernel .text 0xc0100000 0xc0126cc4 0xc01271c8
0xc4c13f1c 0xc880c59b [pagebuf]pagebuf_generic_file_read+0xc3 (0xc49eeb60, 0xbfffecbc, 0x1000, 0xc49eeb80)
                               pagebuf .text 0xc8809060 0xc880c4d8 0xc880c5ec
0xc4c13f44 0xc886ba08 [xfs]xfs_rdwr+0x48 (0xc4587304, 0xc49eeb60, 0xbfffecbc, 0x1000, 0xc49eeb80)
                               xfs .text 0xc8814060 0xc886b9c0 0xc886ba34
0xc4c13f70 0xc886ba85 [xfs]xfs_read+0x51 (0xc4587304, 0xc49eeb60, 0xbfffecbc, 0x1000, 0xc49eeb80)
                               xfs .text 0xc8814060 0xc886ba34 0xc886ba90
0xc4c13f98 0xc8868962 [xfs]linvfs_read+0x62 (0xc49eeb60, 0xbfffecbc, 0x1000, 0xc49eeb80, 0xc4c12000)
                               xfs .text 0xc8814060 0xc8868900 0xc886896c
0xc4c13fbc 0xc01314a8 sys_read+0x94 (0x3, 0xbfffecbc, 0x1000, 0x1000, 0xbfffecbc)
                               kernel .text 0xc0100000 0xc0131414 0xc01314c0
           0xc010912f system_call+0x33
                               kernel .text 0xc0100000 0xc01090fc 0xc0109134

From owner-linux-xfs@oss.sgi.com Tue Oct 10 12:03:05 2000
Received:  by oss.sgi.com id <S42254AbQJJTC4>;
	Tue, 10 Oct 2000 12:02:56 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:63789 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42250AbQJJTCi>; Tue, 10 Oct 2000 12:02:38 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA01502; Tue, 10 Oct 2000 12:09:07 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id MAA07250;
	Tue, 10 Oct 2000 12:01:56 -0700 (PDT)
Date:   Tue, 10 Oct 2000 12:01:56 -0700 (PDT)
Message-Id: <200010101901.MAA07250@info.engr.sgi.com>
X-Pv-Incident: 804398 
webPV:  gibble.americas.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (cattelan@engr.sgi.com)
Subject: UPDATE 804398 - XFS hits BUG call in pagebuf_read_full_page
To:     cattelan@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804398

 Status : open                         Priority : 2                         
 Assigned Engineer : cattelan          Submitter : cattelan                 
 Opened Date : 10/10/00               *Modified User : cattelan             
*Modified User Domain : engr          *Description :
The problem appears to be a page that was orginaly delay alloc
(the underlying disk blocks cam back as zero) but has either
been reused or its state has been cleared.

I don't have all the kbd output... I;ll add to it as
I capture more traces.

[0]kdb> bt
    EBP       EIP         Function(args)
0xc4c13e58 0xc880c914 [pagebuf]pagebuf_read_full_page+0x198 (0xc49eeb60, 0xc11939ac)

.....


==========================
ADDITIONAL INFORMATION (UPDATE)
From: cattelan@engr (BugWorks)
Date: Oct 10 2000 12:01:55PM
==========================

Ohh one small note: this is happening in the developement
(test8) XFS tree. It does NOT occur in the beta tree.

From owner-linux-xfs@oss.sgi.com Tue Oct 10 12:14:26 2000
Received:  by oss.sgi.com id <S42256AbQJJTOR>;
	Tue, 10 Oct 2000 12:14:17 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:10505 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42250AbQJJTNv>;
	Tue, 10 Oct 2000 12:13:51 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA28205; Tue, 10 Oct 2000 12:05:25 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA76818; Tue, 10 Oct 2000 12:13:10 -0700 (PDT)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id MAA46748;
	Tue, 10 Oct 2000 12:11:52 -0700 (PDT)
Date:   Tue, 10 Oct 2000 12:11:52 -0700 (PDT)
Message-Id: <200010101911.MAA46748@info.engr.sgi.com>
X-Pv-Incident: 804398 
webPV:  sgigate.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (ananth@engr.sgi.com)
Subject: ADD 804398 - XFS hits BUG call in pagebuf_read_full_page
To:     cattelan@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804398

 Status : open                         Priority : 2                         
 Assigned Engineer : cattelan          Submitter : cattelan                 
*Modified User : ananth               *Modified User Domain : engr          
*Description :
The problem appears to be a page that was orginaly delay alloc
(the underlying disk blocks cam back as zero) but has either
been reused or its state has been cleared.

I don't have all the kbd output... I;ll add to it as
I capture more traces.

[0]kdb> bt
    EBP       EIP         Function(args)
0xc4c13e58 0xc880c914 [pagebuf]pagebuf_read_full_page+0x198 (0xc49eeb60, 0xc11939ac)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: ananth@engr (BugWorks)
Date: Oct 10 2000 12:11:51PM
==========================


Couple of quick suggestions: Can you please
dump out the page struct (both by using the "page"
command & as raw memory) and the "map" in
page_buf_read_full_page ... you can use "pbmap"
kdb command for the map.

thanks,

ananth.

From owner-linux-xfs@oss.sgi.com Tue Oct 10 12:27:46 2000
Received:  by oss.sgi.com id <S42257AbQJJT1h>;
	Tue, 10 Oct 2000 12:27:37 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:4621 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42250AbQJJT1K>;
	Tue, 10 Oct 2000 12:27:10 -0700
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA00340; Tue, 10 Oct 2000 12:18:44 -0700 (PDT)
	mail_from (pv@feature.engr.sgi.com)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA41250; Tue, 10 Oct 2000 12:25:10 -0700 (PDT)
Date:   Tue, 10 Oct 2000 12:25:10 -0700 (PDT)
Message-Id: <200010101925.MAA41250@feature.engr.sgi.com>
X-Pv-Incident: 804398 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (cattelan@thebarn.com)
Subject: ADD 804398 - XFS hits BUG call in pagebuf_read_full_page
To:     cattelan@cthulhu.engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

 Submitter : cattelan                  Status : open                        
 Assigned Engineer : cattelan          Priority : 2                         
*Modified Date : 10/10/00             *Modified User : cattelan             
*Modified User Domain : thebarn.com   *Description :
The problem appears to be a page that was orginaly delay alloc
(the underlying disk blocks cam back as zero) but has either
been reused or its state has been cleared.

I don't have all the kbd output... I;ll add to it as
I capture more traces.

[0]kdb> bt
    EBP       EIP         Function(args)
0xc4c13e58 0xc880c914 [pagebuf]pagebuf_read_full_page+0x198 (0xc49eeb60, 0xc11939ac)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: russell cattelan <cattelan@thebarn.com>
Date: Oct 10 2000 12:25:10PM
[pvnews version: 1.71]
==========================
"ananth@engr.sgi.com" wrote:

> View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804398
>
>  Status : open                         Priority : 2
>  Assigned Engineer : cattelan          Submitter : cattelan
> *Modified User : ananth               *Modified User Domain : engr
> *Description :
> The problem appears to be a page that was orginaly delay alloc
> (the underlying disk blocks cam back as zero) but has either
> been reused or its state has been cleared.
>
> I don't have all the kbd output... I;ll add to it as
> I capture more traces.
>
> [0]kdb> bt
>     EBP       EIP         Function(args)
> 0xc4c13e58 0xc880c914 [pagebuf]pagebuf_read_full_page+0x198 (0xc49eeb60, 0xc11939ac)
>
> .....
>
> ==========================
> ADDITIONAL INFORMATION (ADD)
> From: ananth@engr (BugWorks)
> Date: Oct 10 2000 12:11:51PM
> ==========================
>
> Couple of quick suggestions: Can you please
> dump out the page struct (both by using the "page"
> command & as raw memory) and the "map" in
> page_buf_read_full_page ... you can use "pbmap"
> kdb command for the map.

that is what  "I don't have all the kbd output... I;ll add to it as
I capture more traces"  means

I didn't capture all that
kdb crashed and I was forced to reboot.
The points of interest though
page flags: PG_locked

xextlist showed the extent to be delay alloc.

>
>
> thanks,
>
> ananth.

From owner-linux-xfs@oss.sgi.com Tue Oct 10 14:32:55 2000
Received:  by oss.sgi.com id <S42250AbQJJVcq>;
	Tue, 10 Oct 2000 14:32:46 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:26928 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42258AbQJJVcY>;
	Tue, 10 Oct 2000 14:32:24 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id OAA17973
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 14:23:58 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA10529; Wed, 11 Oct 2000 08:29:11 +1100
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id IAA05934; Wed, 11 Oct 2000 08:29:09 +1100 (EST)
Message-Id: <200010102129.IAA05934@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     kris buggenhout <gast6@vum.be>
cc:     linux-xfs@oss.sgi.com
Subject: Re: LVM not working...in my case xfs_growfs trouble 
In-reply-to: Your message of "Tue, 10 Oct 2000 10:10:29 +0200."
             <39E2CEF5.7F7ADF7@vum.be> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 11 Oct 2000 08:29:09 +1100
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


kris buggenhout writes:

=> but then I tried xfs_growfs... this resulted in a no-op, and a hang on
=> that process, I could unmount it or mount it again, but nothing moved...

xfs_growfs has at least one outstanding bug which causes this kind of 
behaviour. It's not ready for use yet.

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Tue Oct 10 14:59:36 2000
Received:  by oss.sgi.com id <S42264AbQJJV7Z>;
	Tue, 10 Oct 2000 14:59:25 -0700
Received: from chyndslgw1poolA164.chyn.uswest.net ([63.227.165.164]:47143 "EHLO
        roujin.gargoylecc.com") by oss.sgi.com with ESMTP id <S42263AbQJJV7J>;
	Tue, 10 Oct 2000 14:59:09 -0700
Received: (from nobody@localhost)
	by roujin.gargoylecc.com (8.9.3/8.9.3) id PAA12713;
	Tue, 10 Oct 2000 15:57:55 -0600
Date:   Tue, 10 Oct 2000 15:57:55 -0600
Message-Id: <200010102157.PAA12713@roujin.gargoylecc.com>
From:   "Russel Ingram" <ringram@gargoylecc.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: Re: XFS filesystem corrupts on umount
X-Mailer: BasiliX v0.9.7 -- http://www.basilix.org
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On 10/09/2000 - 15:27, Russell Cattelan wrote:

> Ok good.
> at least the log is indicating a clean unmount.
> 
> Guess we have to track down what else is going wrong.
> 
> BTW do you have "kio"  turned on in the mount options?
> (that option isn't supported on ide drives yet)
> 
> Ok where to start.
> Send us the output from xfs_repair, maybe that will give us a starting
> point.
> 
> Other questions any special mkfs options? what type of ide drive do you
> have?
> any special partitioning?
> 
here is the output from xfs_repair

[root@godzilla /root]# xfs_repair /dev/hda4
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - clear lost+found (if it exists) ...
        - clearing existing "lost+found" inode
        - deleting existing "lost+found" entry
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - ensuring existence of lost+found directory
        - traversing filesystem starting at / ...
        - traversal finished ...
        - traversing all unattached subtrees ...
        - traversals finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done


The drive is a Quantum Bigfoot 1.2G EIDE drive.  I realize that these drives can be problematic, but I have not had any problems with them thus far with other filesystems (I've used reiserfs and FAT filesystems on them as well as the ext2).  The partition structure is just a plain 4 primary partition setup as follows:

Device Size Mount
/dev/hda1  21M /boot
/dev/hda2 591M /
/dev/hda3 127M swap
/dev/hda4 474M /home

the command I gave to create the xfs fs was just a plain mkfs -t xfs /dev/hda4

Hope that helps,
Russ

Russ Ingram
Gargoyle Computer Consulting
(307)742-1361
www.gargoylecc.com

From owner-linux-xfs@oss.sgi.com Tue Oct 10 15:05:26 2000
Received:  by oss.sgi.com id <S42260AbQJJWFP>;
	Tue, 10 Oct 2000 15:05:15 -0700
Received: from chyndslgw1poolA164.chyn.uswest.net ([63.227.165.164]:49447 "EHLO
        roujin.gargoylecc.com") by oss.sgi.com with ESMTP id <S42258AbQJJWEx>;
	Tue, 10 Oct 2000 15:04:53 -0700
Received: (from nobody@localhost)
	by roujin.gargoylecc.com (8.9.3/8.9.3) id QAA12739;
	Tue, 10 Oct 2000 16:03:43 -0600
Date:   Tue, 10 Oct 2000 16:03:43 -0600
Message-Id: <200010102203.QAA12739@roujin.gargoylecc.com>
From:   "Russel Ingram" <ringram@gargoylecc.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: Re: XFS filesystem corrupts on umount 
X-Mailer: BasiliX v0.9.7 -- http://www.basilix.org
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On 10/09/2000 - 15:41, Daniel Moore wrote:

> You'll get a better idea of what really happened by checking the messages
> printed to the console or syslog when the mount failed.
> 
> Basically any more info you could send including these messages would
> help us out here.

Here are the messages from the time I umounted the fs to the time I got it remounted (after the xfs_repair):

Oct 10 03:20:20 godzilla kernel: Start mounting filesystem: ide0(3,4)
Oct 10 03:20:21 godzilla kernel: XFS: empty log check failed
Oct 10 03:20:21 godzilla kernel: XFS: log mount/recovery failed
Oct 10 03:20:21 godzilla kernel:
Oct 10 03:20:21 godzilla kernel: XFS: log mount failed
Oct 10 03:37:34 godzilla kernel: Start mounting filesystem: ide0(3,4)


Russ
Russ Ingram
Gargoyle Computer Consulting
(307)742-1361
www.gargoylecc.com

From owner-linux-xfs@oss.sgi.com Tue Oct 10 15:08:25 2000
Received:  by oss.sgi.com id <S42261AbQJJWIQ>;
	Tue, 10 Oct 2000 15:08:16 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:14395 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42258AbQJJWHy>;
	Tue, 10 Oct 2000 15:07:54 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA23262
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 14:59:27 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id RAA7242597; Tue, 10 Oct 2000 17:04:40 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id RAA52872; Tue, 10 Oct 2000 17:04:40 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id RAA26466;
	Tue, 10 Oct 2000 17:04:39 -0500
Message-Id: <200010102204.RAA26466@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     "Russel Ingram" <ringram@gargoylecc.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS filesystem corrupts on umount 
In-Reply-To: Message from "Russel Ingram" <ringram@gargoylecc.com> 
   of "Tue, 10 Oct 2000 15:57:55 MDT." <200010102157.PAA12713@roujin.gargoylecc.com> 
Date:   Tue, 10 Oct 2000 17:04:39 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


The one thing missing from this info is any console messages generated
by the failing mount. A successful XFS mount comes out with something
like this:

Start mounting filesystem: sd(8,4)
Starting XFS recovery on filesystem: sd(8,4) (dev: 8/4)
Ending XFS recovery on filesystem: sd(8,4) (dev: 8/4)

or

XFS (dev: 8/4) mounting with KIOBUFIO (clustering)
Start mounting filesystem: sd(8,4)
Ending clean XFS mount for filesystem: sd(8,4)

Your repair output indicates no problems with the filesystem - which from
the logprint info appears to have been correctly unmounted. Without the
console messages from mount we still don't have anything to go on.


Steve

> 
> On 10/09/2000 - 15:27, Russell Cattelan wrote:
> 
> > Ok good.
> > at least the log is indicating a clean unmount.
> > 
> > Guess we have to track down what else is going wrong.
> > 
> > BTW do you have "kio"  turned on in the mount options?
> > (that option isn't supported on ide drives yet)
> > 
> > Ok where to start.
> > Send us the output from xfs_repair, maybe that will give us a starting
> > point.
> > 
> > Other questions any special mkfs options? what type of ide drive do you
> > have?
> > any special partitioning?
> > 
> here is the output from xfs_repair
> 
> [root@godzilla /root]# xfs_repair /dev/hda4
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
>         - zero log...
>         - scan filesystem freespace and inode maps...
>         - found root inode chunk
> Phase 3 - for each AG...
>         - scan and clear agi unlinked lists...
>         - process known inodes and perform inode discovery...
>         - agno = 0
>         - agno = 1
>         - agno = 2
>         - agno = 3
>         - agno = 4
>         - agno = 5
>         - agno = 6
>         - agno = 7
>         - process newly discovered inodes...
> Phase 4 - check for duplicate blocks...
>         - setting up duplicate extent list...
>         - clear lost+found (if it exists) ...
>         - clearing existing "lost+found" inode
>         - deleting existing "lost+found" entry
>         - check for inodes claiming duplicate blocks...
>         - agno = 0
>         - agno = 1
>         - agno = 2
>         - agno = 3
>         - agno = 4
>         - agno = 5
>         - agno = 6
>         - agno = 7
> Phase 5 - rebuild AG headers and trees...
>         - reset superblock...
> Phase 6 - check inode connectivity...
>         - resetting contents of realtime bitmap and summary inodes
>         - ensuring existence of lost+found directory
>         - traversing filesystem starting at / ...
>         - traversal finished ...
>         - traversing all unattached subtrees ...
>         - traversals finished ...
>         - moving disconnected inodes to lost+found ...
> Phase 7 - verify and correct link counts...
> done
> 
> 
> The drive is a Quantum Bigfoot 1.2G EIDE drive.  I realize that these drives 
can be problematic, but I have not had any problems with them thus far with oth
er filesystems (I've used reiserfs and FAT filesystems on them as well as the e
xt2).  The partition structure is just a plain 4 primary partition setup as fol
lows:
> 
> Device Size Mount
> /dev/hda1  21M /boot
> /dev/hda2 591M /
> /dev/hda3 127M swap
> /dev/hda4 474M /home
> 
> the command I gave to create the xfs fs was just a plain mkfs -t xfs /dev/hda
4
> 
> Hope that helps,
> Russ
> 
> Russ Ingram
> Gargoyle Computer Consulting
> (307)742-1361
> www.gargoylecc.com



From owner-linux-xfs@oss.sgi.com Tue Oct 10 15:09:36 2000
Received:  by oss.sgi.com id <S42263AbQJJWJ0>;
	Tue, 10 Oct 2000 15:09:26 -0700
Received: from chyndslgw1poolA164.chyn.uswest.net ([63.227.165.164]:50727 "EHLO
        roujin.gargoylecc.com") by oss.sgi.com with ESMTP id <S42258AbQJJWJK>;
	Tue, 10 Oct 2000 15:09:10 -0700
Received: (from nobody@localhost)
	by roujin.gargoylecc.com (8.9.3/8.9.3) id QAA12764;
	Tue, 10 Oct 2000 16:08:01 -0600
Date:   Tue, 10 Oct 2000 16:08:01 -0600
Message-Id: <200010102208.QAA12764@roujin.gargoylecc.com>
From:   "Russel Ingram" <ringram@gargoylecc.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: Re: XFS filesystem corrupts on umount 
X-Mailer: BasiliX v0.9.7 -- http://www.basilix.org
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I missed the very last line of the log on that last post.  Here it is:

Oct 10 03:37:34 godzilla kernel: Ending clean XFS mount for filesystem: ide0(3,4)


Russ
Russ Ingram
Gargoyle Computer Consulting
(307)742-1361
www.gargoylecc.com

From owner-linux-xfs@oss.sgi.com Tue Oct 10 15:15:26 2000
Received:  by oss.sgi.com id <S42265AbQJJWPQ>;
	Tue, 10 Oct 2000 15:15:16 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:21821 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42258AbQJJWOy>;
	Tue, 10 Oct 2000 15:14:54 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA24410
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 15:06:28 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA10778; Wed, 11 Oct 2000 09:12:56 +1100
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id JAA06137; Wed, 11 Oct 2000 09:12:56 +1100 (EST)
Message-Id: <200010102212.JAA06137@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     "Russel Ingram" <ringram@gargoylecc.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS filesystem corrupts on umount 
In-reply-to: Your message of "Tue, 10 Oct 2000 16:03:43 MDT."
             <200010102203.QAA12739@roujin.gargoylecc.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 11 Oct 2000 09:12:55 +1100
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


"Russel Ingram" writes:

 => > You'll get a better idea of what really happened by checking the messages
 => > printed to the console or syslog when the mount failed.

 => Here are the messages from the time I umounted the fs to the time I got it 
 => remounted (after the xfs_repair):
 => 
 => Oct 10 03:20:20 godzilla kernel: Start mounting filesystem: ide0(3,4)
 => Oct 10 03:20:21 godzilla kernel: XFS: empty log check failed
 => Oct 10 03:20:21 godzilla kernel: XFS: log mount/recovery failed
 => Oct 10 03:20:21 godzilla kernel:
 => Oct 10 03:20:21 godzilla kernel: XFS: log mount failed
 => Oct 10 03:37:34 godzilla kernel: Start mounting filesystem: ide0(3,4)

What type of machine is this and how much memory do you have in it?
I'll bet the memory allocations are failing in the log recovery.

If this is the case, the development version has a workaround for this
that will solve your problem.

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Tue Oct 10 15:25:16 2000
Received:  by oss.sgi.com id <S42266AbQJJWZG>;
	Tue, 10 Oct 2000 15:25:06 -0700
Received: from chyndslgw1poolA164.chyn.uswest.net ([63.227.165.164]:54567 "EHLO
        roujin.gargoylecc.com") by oss.sgi.com with ESMTP id <S42258AbQJJWYq>;
	Tue, 10 Oct 2000 15:24:46 -0700
Received: (from nobody@localhost)
	by roujin.gargoylecc.com (8.9.3/8.9.3) id QAA12816;
	Tue, 10 Oct 2000 16:23:36 -0600
Date:   Tue, 10 Oct 2000 16:23:36 -0600
Message-Id: <200010102223.QAA12816@roujin.gargoylecc.com>
From:   "Russel Ingram" <ringram@gargoylecc.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: Re: XFS filesystem corrupts on umount 
X-Mailer: BasiliX v0.9.7 -- http://www.basilix.org
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On 10/10/2000 - 16:10, lord@sgi.com wrote:

> OK, can you run xfs_logprint again - only this time without the -t option,
> this should print the whole log as just disk blocks.
> 
> Thanks,
> 
>    Steve
> 
[root@godzilla /root]# xfs_logprint /dev/hda4
xfs_logprint:
    data device: 0x304
    log device: 0x304 daddr: 489920 length: 9600

xfs_logprint: skipped 9600 zeroed blocks
xfs_logprint: totally zeroed log
xfs_logprint: physical end of log
============================================================================
xfs_logprint: logical end of log
============================================================================
[root@godzilla /root]#

Russ Ingram
Gargoyle Computer Consulting
(307)742-1361
www.gargoylecc.com

From owner-linux-xfs@oss.sgi.com Tue Oct 10 15:31:25 2000
Received:  by oss.sgi.com id <S42268AbQJJWbP>;
	Tue, 10 Oct 2000 15:31:15 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2886 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42258AbQJJWaw>; Tue, 10 Oct 2000 15:30:52 -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 PAA06847
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 15:37:20 -0700 (PDT)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA10899; Wed, 11 Oct 2000 09:28:52 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     cattelan@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com
Subject: Re: ADD 804398 - XFS hits BUG call in pagebuf_read_full_page 
In-reply-to: Your message of "Tue, 10 Oct 2000 12:25:10 PDT."
             <200010101925.MAA41250@feature.engr.sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 11 Oct 2000 09:28:51 +1100
Message-ID: <1674.971216931@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, 10 Oct 2000 12:25:10 -0700 (PDT), 
pv@fddi-odin.corp.sgi.com (cattelan@thebarn.com) wrote:
>that is what  "I don't have all the kbd output... I;ll add to it as
>I capture more traces"  means
>
>I didn't capture all that
>kdb crashed and I was forced to reboot.

How did kdb crash?


From owner-linux-xfs@oss.sgi.com Tue Oct 10 15:34:45 2000
Received:  by oss.sgi.com id <S42269AbQJJWef>;
	Tue, 10 Oct 2000 15:34:35 -0700
Received: from chyndslgw1poolA164.chyn.uswest.net ([63.227.165.164]:56103 "EHLO
        roujin.gargoylecc.com") by oss.sgi.com with ESMTP id <S42258AbQJJWeI>;
	Tue, 10 Oct 2000 15:34:08 -0700
Received: (from nobody@localhost)
	by roujin.gargoylecc.com (8.9.3/8.9.3) id QAA12842;
	Tue, 10 Oct 2000 16:32:58 -0600
Date:   Tue, 10 Oct 2000 16:32:58 -0600
Message-Id: <200010102232.QAA12842@roujin.gargoylecc.com>
From:   "Russel Ingram" <ringram@gargoylecc.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: Re: XFS filesystem corrupts on umount 
X-Mailer: BasiliX v0.9.7 -- http://www.basilix.org
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On 10/10/2000 - 16:16, Daniel Moore wrote:

> What type of machine is this and how much memory do you have in it?
> I'll bet the memory allocations are failing in the log recovery.
> 
> If this is the case, the development version has a workaround for this
> that will solve your problem.
> 

This had also occured to me but I had nothing to base it on.  The system is a 486 running an Evergreen 100MHz processor with 32M RAM.  

Russ

Russ Ingram
Gargoyle Computer Consulting
(307)742-1361
www.gargoylecc.com

From owner-linux-xfs@oss.sgi.com Tue Oct 10 15:37:25 2000
Received:  by oss.sgi.com id <S42271AbQJJWhP>;
	Tue, 10 Oct 2000 15:37:15 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:32071 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42270AbQJJWg5>; Tue, 10 Oct 2000 15:36:57 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA07986
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 15:43:25 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id RAA7166952; Tue, 10 Oct 2000 17:34:50 -0500 (CDT)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id RAA84749; Tue, 10 Oct 2000 17:34:50 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e9AMYnQ11575;
	Tue, 10 Oct 2000 17:34:49 -0500
Message-ID: <39E39988.3A61C4A0@thebarn.com>
Date:   Tue, 10 Oct 2000 17:34:48 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-whipme5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Keith Owens <kaos@melbourne.sgi.com>
CC:     cattelan@cthulhu.engr.sgi.com, linux-xfs@oss.sgi.com
Subject: Re: ADD 804398 - XFS hits BUG call in pagebuf_read_full_page
References: <1674.971216931@kao2.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Keith Owens wrote:

> On Tue, 10 Oct 2000 12:25:10 -0700 (PDT),
> pv@fddi-odin.corp.sgi.com (cattelan@thebarn.com) wrote:
> >that is what  "I don't have all the kbd output... I;ll add to it as
> >I capture more traces"  means
> >
> >I didn't capture all that
> >kdb crashed and I was forced to reboot.
>
> How did kdb crash?

it wasn't that kdb it self crashed, rather I entered a bad address into
the xinode command with cause a null reference which cause
kdb to do a re enter.
After that any info I was going after was lost.
kdb it self did keep running

sorry about the confusion.





From owner-linux-xfs@oss.sgi.com Tue Oct 10 15:41:55 2000
Received:  by oss.sgi.com id <S42270AbQJJWlp>;
	Tue, 10 Oct 2000 15:41:45 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24136 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42258AbQJJWlY>; Tue, 10 Oct 2000 15:41:24 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA05134
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 15:47:42 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id RAA7229226; Tue, 10 Oct 2000 17:39:16 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id RAA41462; Tue, 10 Oct 2000 17:39:16 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id RAA26803;
	Tue, 10 Oct 2000 17:39:14 -0500
Message-Id: <200010102239.RAA26803@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     "Russel Ingram" <ringram@gargoylecc.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS filesystem corrupts on umount 
In-Reply-To: Message from "Russel Ingram" <ringram@gargoylecc.com> 
   of "Tue, 10 Oct 2000 16:32:58 MDT." <200010102232.QAA12842@roujin.gargoylecc.com> 
Date:   Tue, 10 Oct 2000 17:39:14 -0500
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> 
> On 10/10/2000 - 16:16, Daniel Moore wrote:
> 
> > What type of machine is this and how much memory do you have in it?
> > I'll bet the memory allocations are failing in the log recovery.
> > 
> > If this is the case, the development version has a workaround for this
> > that will solve your problem.
> > 
> 
> This had also occured to me but I had nothing to base it on.  The system is a
 486 running an Evergreen 100MHz processor with 32M RAM. 

Funny, I have a guy in my office right now who is trying to kill a system with
only 32 Mbytes of ram and cannot make it happen - this is using the test cvs
tree though. Daniel, maybe the XFS recovery code from test8 should go back into
the beta tree.

Steve

 


From owner-linux-xfs@oss.sgi.com Tue Oct 10 15:43:45 2000
Received:  by oss.sgi.com id <S42277AbQJJWnf>;
	Tue, 10 Oct 2000 15:43:35 -0700
Received: from chyndslgw1poolA164.chyn.uswest.net ([63.227.165.164]:58407 "EHLO
        roujin.gargoylecc.com") by oss.sgi.com with ESMTP id <S42258AbQJJWnL>;
	Tue, 10 Oct 2000 15:43:11 -0700
Received: (from nobody@localhost)
	by roujin.gargoylecc.com (8.9.3/8.9.3) id QAA12874;
	Tue, 10 Oct 2000 16:42:01 -0600
Date:   Tue, 10 Oct 2000 16:42:01 -0600
Message-Id: <200010102242.QAA12874@roujin.gargoylecc.com>
From:   "Russel Ingram" <ringram@gargoylecc.com>
To:     linux-xfs@oss.sgi.com
Subject: Re: Re: XFS filesystem corrupts on umount 
X-Mailer: BasiliX v0.9.7 -- http://www.basilix.org
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On 10/10/2000 - 16:33, lord@sgi.com wrote:

> > 
> Thanks, in that case Daniel is correct - this is probably a memory problem,
> the code in the beta will want to allocate a fairly large chunk of memory
> in the kernel during mount (128K bytes).  The output of /proc/slabinfo
> and the free command will probably tell us something here. 
> 
> Steve
> 
output from free:

[root@godzilla /root]# free
             total       used       free     shared    buffers     cached
Mem:         29624      29024        600          0       2076       3860
-/+ buffers/cache:      23088       6536
Swap:       129016       3940     125076
[root@godzilla /root]#

Contents of /proc/slabinfo:

[root@godzilla /root]# cat /proc/slabinfo
slabinfo - version: 1.1
kmem_cache            67     78    100    2    2    1
xfs_chashlist          5    203     16    1    1    1
xfs_ili                0      0    136    0    0    1
xfs_ifork              0      0     56    0    0    1
xfs_efi_item           0      0    260    0    0    1
xfs_efd_item           0      0    260    0    0    1
xfs_buf_item           0      0    148    0    0    1
xfs_dabuf              0      0     16    0    0    1
xfs_da_state           0      0    340    0    0    1
xfs_gap                0      0     16    0    0    1
xfs_trans              0      0    320    0    0    1
xfs_inode              6      7    524    1    1    1
xfs_btree_cur          0      0    140    0    0    1
xfs_bmap_free_item      0      0     16    0    0    1
page_buf_t             4     24    160    1    1    1
page_buf_reg_t         1    203     16    1    1    1
avl_object_t           2    113     32    1    1    1
avl_entry_t            1    113     32    1    1    1
blkdev_requests     1024   1050    112   30   30    1
file lock cache        3     44     88    1    1    1
tcp_tw_bucket          0      0    128    0    0    1
tcp_bind_bucket       15    203     16    1    1    1
tcp_open_request       0      0     96    0    0    1
inet_peer_cache        0      0     48    0    0    1
ip_fib_hash           11    203     16    1    1    1
ip_dst_cache           3     24    160    1    1    1
arp_cache              2     35    112    1    1    1
skbuff_head_cache     42     48    160    2    2    1
sock                  37     39   1200   13   13    1
inode_cache        37125  40190    368 4019 4019    1
bdev_cache           312    312     48    4    4    1
signal_queue           1     29    132    1    1    1
kiobuf                 9     30    128    1    1    1
mm_struct             27     54    144    2    2    1
vm_area_struct       433    531     64    9    9    1
dentry_cache       16235  23940    112  684  684    1
dquot                  0      0     96    0    0    1
filp                 337    360     96    9    9    1
files_cache           26     36    416    4    4    1
names_cache            0      2   4096    0    2    1
buffer_head         4081   4960     96  122  124    1
uid_cache              4    203     16    1    1    1
size-131072(DMA)       0      0 131072    0    0   32
size-131072            0      0 131072    0    0   32
size-65536(DMA)        0      0  65536    0    0   16
size-65536             0      0  65536    0    0   16
size-32768(DMA)        0      0  32768    0    0    8
size-32768             2      2  32768    2    2    8
size-16384(DMA)        0      0  16384    0    0    4
size-16384             1      1  16384    1    1    4
size-8192(DMA)         0      0   8192    0    0    2
size-8192              2      2   8192    2    2    2
size-4096(DMA)         0      0   4096    0    0    1
size-4096             10     10   4096   10   10    1
size-2048(DMA)         0      0   2048    0    0    1
size-2048             50     52   2048   26   26    1
size-1024(DMA)         0      0   1024    0    0    1
size-1024             14     16   1024    4    4    1
size-512(DMA)          0      0    512    0    0    1
size-512              46     48    512    6    6    1
size-256(DMA)          0      0    256    0    0    1
size-256              16     30    256    2    2    1
size-128(DMA)          0      0    128    0    0    1
size-128            1889   1890    128   63   63    1
size-64(DMA)           0      0     64    0    0    1
size-64              315    354     64    6    6    1
size-32(DMA)           0      0     32    0    0    1
size-32             2830   4407     32   39   39    1


I hope that's not overload of info.  Thank you guys so much for your attention to this problem.  I am really looking forward to being able to use XFS on Linux and installed this system (puny as it is) specifically for the purpose of finding out where the XFS port stands.

Thanx again,
Russ
Russ Ingram
Gargoyle Computer Consulting
(307)742-1361
www.gargoylecc.com

From owner-linux-xfs@oss.sgi.com Tue Oct 10 15:43:55 2000
Received:  by oss.sgi.com id <S42258AbQJJWnp>;
	Tue, 10 Oct 2000 15:43:45 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:49991 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42276AbQJJWna>;
	Tue, 10 Oct 2000 15:43:30 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA29617
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 15:35:03 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA11016; Wed, 11 Oct 2000 09:40:17 +1100
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id JAA06333; Wed, 11 Oct 2000 09:40:16 +1100 (EST)
Message-Id: <200010102240.JAA06333@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     "Russel Ingram" <ringram@gargoylecc.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS filesystem corrupts on umount 
In-reply-to: Your message of "Tue, 10 Oct 2000 16:32:58 MDT."
             <200010102232.QAA12842@roujin.gargoylecc.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 11 Oct 2000 09:40:16 +1100
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


"Russel Ingram" writes:

 => This had also occured to me but I had nothing to base it on.  The system is
 =>  a 486 running an Evergreen 100MHz processor with 32M RAM.  

You and I must be the only two people who still have only 32M of RAM :)

The problem here is that the recovery fails to allocate a big chunk of
RAM it requests when recovering a filesystem with a non-empty log. This
means that the first mount of a new filesystem is ok, the first mount
after running xfs_repair is ok, but all others fail.

The development release has a work-around for this problem which should
get you going - unfortunately it didn't quite make it into the beta release.

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Tue Oct 10 15:50:45 2000
Received:  by oss.sgi.com id <S42279AbQJJWug>;
	Tue, 10 Oct 2000 15:50:36 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:1354 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42276AbQJJWuE>;
	Tue, 10 Oct 2000 15:50:04 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA00853
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 15:41:37 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA11098; Wed, 11 Oct 2000 09:48:06 +1100
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id JAA06403; Wed, 11 Oct 2000 09:48:06 +1100 (EST)
Message-Id: <200010102248.JAA06403@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     Steve Lord <lord@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS filesystem corrupts on umount 
In-reply-to: Your message of "Tue, 10 Oct 2000 17:39:14 CDT."
             <200010102239.RAA26803@jen.americas.sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 11 Oct 2000 09:48:06 +1100
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Steve Lord writes:

 => Funny, I have a guy in my office right now who is trying to kill a system w
 => ith
 => only 32 Mbytes of ram and cannot make it happen - this is using the test cv
 => s
 => tree though. Daniel, maybe the XFS recovery code from test8 should go back 
 => into
 => the beta tree.
 
I'd say it's ready for it now - I'll see what I can do.
Are we expecting to spin another beta soon?


-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------



From owner-linux-xfs@oss.sgi.com Tue Oct 10 16:06:15 2000
Received:  by oss.sgi.com id <S42276AbQJJXF4>;
	Tue, 10 Oct 2000 16:05:56 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:48206 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42273AbQJJXFd>;
	Tue, 10 Oct 2000 16:05:33 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA03263
	for <linux-xfs@oss.sgi.com>; Tue, 10 Oct 2000 15:57:02 -0700 (PDT)
	mail_from (ajag@snort.melbourne.sgi.com)
Received: (from ajag@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA62874
	for linux-xfs@oss.sgi.com; Wed, 11 Oct 2000 10:03:30 +1100 (EST)
Date:   Wed, 11 Oct 2000 10:03:30 +1100 (EST)
From:   Andrew Gildfind <ajag@snort.melbourne.sgi.com>
Message-Id: <200010102303.KAA62874@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - XFS QA 042
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:76021a
Date:  Tue Oct 10 16:03:09 PDT 2000
Workarea:  snort:/build5/ajag/slinx
Author:  ajag

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/042.out - 1.2
	- Update verified output.


From owner-linux-xfs@oss.sgi.com Tue Oct 10 19:27:15 2000
Received:  by oss.sgi.com id <S42262AbQJKC1G>;
	Tue, 10 Oct 2000 19:27:06 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23642 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42215AbQJKC0h>; Tue, 10 Oct 2000 19:26:37 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA08052; Tue, 10 Oct 2000 19:33:06 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA66428;
	Tue, 10 Oct 2000 19:25:55 -0700 (PDT)
Date:   Tue, 10 Oct 2000 19:25:55 -0700 (PDT)
Message-Id: <200010110225.TAA66428@info.engr.sgi.com>
X-Pv-Incident: 804475 
webPV:  wobbly.melbourne.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (nathans@engr.sgi.com)
Subject: BUG 804475 - chown -h doesn't work on xfs
To:     nb@sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804475

Submitter : nathans                   Submitter Domain : engr               
Assigned Engineer : nb                Assigned Domain : sgi.com             
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 3                          
Project : xfs-linux                   Status : open                         
Description :
>From a quick test, chown+XFS on IRIX seems to behave the
way Marco describes (below), but on Linux, XFS doesn't seem
to allow this ... is this expected or is something amiss?

irix/xfs:
$ touch foo
$ ln -s foo bar
$ ls -ld foo bar
lrwxr-xr-x    1 nathans  ptg            3 Oct 11 11:48 bar -> foo
-rw-r--r--    1 nathans  ptg            0 Oct 11 11:48 foo
$ sudo chown -h pcpqa bar
$ ls -ld foo bar
lrwxr-xr-x    1 pcpqa    ptg            3 Oct 11 11:48 bar -> foo
-rw-r--r--    1 nathans  ptg            0 Oct 11 11:48 foo

linux/ext2:
$ touch foo
$ ln -s foo bar
$ ls -ld foo bar
lrwxrwxrwx    1 nathans  ptg             3 Oct 11 11:49 bar -> foo
-rw-r--r--    1 nathans  ptg             0 Oct 11 11:49 foo
$ sudo chown -h pcpqa bar
$ ls -ld foo bar
lrwxrwxrwx    1 pcpqa    ptg             3 Oct 11 11:49 bar -> foo
-rw-r--r--    1 nathans  ptg             0 Oct 11 11:49 foo

linux/xfs:
$ touch foo
$ ln -s foo bar
$ ls -ld foo bar
lrwxr-xr-x    1 nathans  ptg             3 Oct 11 11:51 bar -> foo
-rw-r--r--    1 nathans  ptg             0 Oct 11 11:51 foo
$ sudo chown -h pcpqa bar
$ ls -ld foo bar
lrwxr-xr-x    1 nathans  ptg             3 Oct 11 11:51 bar -> foo
-rw-r--r--    1 nathans  ptg             0 Oct 11 11:51 foo



--- Forwarded mail from Marco van Wieringen <mvw@mars.planets.elm.net>

Date: Tue, 10 Oct 2000 20:07:26 +0200 (MEST)
From: Marco van Wieringen <mvw@mars.planets.elm.net>
Reply-To: Marco van Wieringen <mvw@mars.planets.elm.net>
Subject: Re: Linux quota tools
To: Nathan Scott <nathans>

...

B.T.W. I just installed XFS on one of my development systems and it looks
good and more or less stable. But I have a question is it so that
one cannot change the owner on a symlink like it works on ext2
when you do a chown -h username.group <symlink-name>.

Marco.

---End of forwarded mail from Marco van Wieringen <mvw@mars.planets.elm.net>

From owner-linux-xfs@oss.sgi.com Wed Oct 11 07:12:39 2000
Received:  by oss.sgi.com id <S42292AbQJKOMa>;
	Wed, 11 Oct 2000 07:12:30 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:11386 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42267AbQJKOMD>; Wed, 11 Oct 2000 07:12:03 -0700
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA04649; Wed, 11 Oct 2000 07:18:32 -0700 (PDT)
	mail_from (pv@feature.engr.sgi.com)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA65490; Wed, 11 Oct 2000 07:10:04 -0700 (PDT)
Date:   Wed, 11 Oct 2000 07:10:04 -0700 (PDT)
Message-Id: <200010111410.HAA65490@feature.engr.sgi.com>
X-Pv-Incident: 804475 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (lord@sgi.com)
Subject: TAKE 804475 - chown -h doesn't work on xfs
To:     nb@sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

 Submitter : nathans                  *Status : closed                      
 Assigned Engineer : nb               *Fixed By : lord                      
*Fixed By Domain : sgi.com            *Closed Date : 10/11/00               
 Priority : 3                         *Modified Date : 10/11/00             
*Modified User : lord                 *Modified User Domain : sgi.com       
*Fix Description :
From: steve lord <lord@sgi.com> (TAKE)
Date: Oct 11 2000 07:10:03AM
[pvnews version: 1.71]
----------------------------

A missing ops vector for symlinks meant you could not do a
permission change on them.

Date:  Wed Oct 11 07:05:23 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-clean

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76046a
linux/fs/xfs/linux/xfs_iops.c - 1.74
	- Add notify change call for symlinks so that chown -h works
Description :
>From a quick test, chown+XFS on IRIX seems to behave the
way Marco describes (below), but on Linux, XFS doesn't seem
to allow this ... is this expected or is something amiss?

irix/xfs:
$ touch foo
$ ln -s foo bar
$ ls -ld foo bar
lrwxr-xr-x    1 nathans  ptg            3 Oct 11 11:48 bar -> foo
-rw-r--r--    1 nathans  ptg            0 Oct 11 11:48 foo
$ sudo chown -h pcpqa bar
$ ls -ld foo bar
lrwxr-xr-x    1 pcpqa    ptg            3 Oct 11 11:48 bar -> foo
-rw-r--r--    1 nathans  ptg            0 Oct 11 11:48 foo

linux/ext2:
$ touch foo
$ ln -s foo bar
$ ls -ld foo bar
lrwxrwxrwx    1 nathans  ptg             3 Oct 11 11:49 bar -> foo
-rw-r--r--    1 nathans  ptg             0 Oct 11 11:49 foo
$ sudo chown -h pcpqa bar
$ ls -ld foo bar
lrwxrwxrwx    1 pcpqa    ptg             3 Oct 11 11:49 bar -> foo
-rw-r--r--    1 nathans  ptg             0 Oct 11 11:49 foo

linux/xfs:
$ touch foo
$ ln -s foo bar
$ ls -ld foo bar
lrwxr-xr-x    1 nathans  ptg             3 Oct 11 11:51 bar -> foo
-rw-r--r--    1 nathans  ptg             0 Oct 11 11:51 foo
$ sudo chown -h pcpqa bar
$ ls -ld foo bar
lrwxr-xr-x    1 nathans  ptg             3 Oct 11 11:51 bar -> foo
-rw-r--r--    1 nathans  ptg             0 Oct 11 11:51 foo



--- Forwarded mail from Marco van Wieringen <mvw@mars.planets.elm.net>

Date: Tue, 10 Oct 2000 20:07:26 +0200 (MEST)
From: Marco van Wieringen <mvw@mars.planets.elm.net>
Reply-To: Marco van Wieringen <mvw@mars.planets.elm.net>
Subject: Re: Linux quota tools
To: Nathan Scott <nathans>

...

B.T.W. I just installed XFS on one of my development systems and it looks
good and more or less stable. But I have a question is it so that
one cannot change the owner on a symlink like it works on ext2
when you do a chown -h username.group <symlink-name>.

Marco.

---End of forwarded mail from Marco van Wieringen <mvw@mars.planets.elm.net>

From owner-linux-xfs@oss.sgi.com Wed Oct 11 07:24:09 2000
Received:  by oss.sgi.com id <S42267AbQJKOYA>;
	Wed, 11 Oct 2000 07:24:00 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:613 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42278AbQJKOXV>;
	Wed, 11 Oct 2000 07:23:21 -0700
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA16784; Wed, 11 Oct 2000 07:14:56 -0700 (PDT)
	mail_from (pv@feature.engr.sgi.com)
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA18477; Wed, 11 Oct 2000 07:22:40 -0700 (PDT)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA65995; Wed, 11 Oct 2000 07:20:04 -0700 (PDT)
Date:   Wed, 11 Oct 2000 07:20:04 -0700 (PDT)
Message-Id: <200010111420.HAA65995@feature.engr.sgi.com>
X-Pv-Incident: 804475 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (lord@sgi.com)
Subject: TAKE 804475 - chown -h doesn't work on xfs
To:     nb@sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

 Submitter : nathans                  *Status : closed                      
 Assigned Engineer : nb               *Fixed By : lord                      
*Fixed By Domain : sgi.com            *Closed Date : 10/11/00               
 Priority : 3                         *Modified Date : 10/11/00             
*Modified User : lord                 *Modified User Domain : sgi.com       
*Fix Description :
From: steve lord <lord@sgi.com> (TAKE)
Date: Oct 11 2000 07:10:03AM
[pvnews version: 1.71]
----------------------------

A missing ops vector for symlinks meant you could not do a
permission change on them.

Date:  Wed Oct 11 07:05:23 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-clean

.....


==========================
ADDITIONAL INFORMATION (TAKE)
From: steve lord <lord@sgi.com>
Date: Oct 11 2000 07:20:04AM
[pvnews version: 1.71]
==========================
push mod back into beta tree

Date:  Wed Oct 11 07:14:19 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-beta
Author:  lord
Merged by:  lord
Merged mods:  2.4.x-xfs:slinx:76046a

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-beta


Modid:  2.4.x-xfs-beta:slinx:76046a
linux/fs/xfs/linux/xfs_iops.c - 1.70
	- Merge of 2.4.x-xfs:slinx:76046a by lord.
	  Add notify change call for symlinks so that chown -h works
Description :
>From a quick test, chown+XFS on IRIX seems to behave the
way Marco describes (below), but on Linux, XFS doesn't seem
to allow this ... is this expected or is something amiss?

irix/xfs:
$ touch foo
$ ln -s foo bar
$ ls -ld foo bar
lrwxr-xr-x    1 nathans  ptg            3 Oct 11 11:48 bar -> foo
-rw-r--r--    1 nathans  ptg            0 Oct 11 11:48 foo
$ sudo chown -h pcpqa bar
$ ls -ld foo bar
lrwxr-xr-x    1 pcpqa    ptg            3 Oct 11 11:48 bar -> foo
-rw-r--r--    1 nathans  ptg            0 Oct 11 11:48 foo

linux/ext2:
$ touch foo
$ ln -s foo bar
$ ls -ld foo bar
lrwxrwxrwx    1 nathans  ptg             3 Oct 11 11:49 bar -> foo
-rw-r--r--    1 nathans  ptg             0 Oct 11 11:49 foo
$ sudo chown -h pcpqa bar
$ ls -ld foo bar
lrwxrwxrwx    1 pcpqa    ptg             3 Oct 11 11:49 bar -> foo
-rw-r--r--    1 nathans  ptg             0 Oct 11 11:49 foo

linux/xfs:
$ touch foo
$ ln -s foo bar
$ ls -ld foo bar
lrwxr-xr-x    1 nathans  ptg             3 Oct 11 11:51 bar -> foo
-rw-r--r--    1 nathans  ptg             0 Oct 11 11:51 foo
$ sudo chown -h pcpqa bar
$ ls -ld foo bar
lrwxr-xr-x    1 nathans  ptg             3 Oct 11 11:51 bar -> foo
-rw-r--r--    1 nathans  ptg             0 Oct 11 11:51 foo



--- Forwarded mail from Marco van Wieringen <mvw@mars.planets.elm.net>

Date: Tue, 10 Oct 2000 20:07:26 +0200 (MEST)
From: Marco van Wieringen <mvw@mars.planets.elm.net>
Reply-To: Marco van Wieringen <mvw@mars.planets.elm.net>
Subject: Re: Linux quota tools
To: Nathan Scott <nathans>

...

B.T.W. I just installed XFS on one of my development systems and it looks
good and more or less stable. But I have a question is it so that
one cannot change the owner on a symlink like it works on ext2
when you do a chown -h username.group <symlink-name>.

Marco.

---End of forwarded mail from Marco van Wieringen <mvw@mars.planets.elm.net>

From owner-linux-xfs@oss.sgi.com Wed Oct 11 13:44:42 2000
Received:  by oss.sgi.com id <S42197AbQJKUoc>;
	Wed, 11 Oct 2000 13:44:32 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:63581 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42180AbQJKUoF>;
	Wed, 11 Oct 2000 13:44:05 -0700
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA11619; Wed, 11 Oct 2000 13:35:29 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA37267; Wed, 11 Oct 2000 13:42:43 -0700 (PDT)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id NAA28844;
	Wed, 11 Oct 2000 13:41:26 -0700 (PDT)
Date:   Wed, 11 Oct 2000 13:41:26 -0700 (PDT)
Message-Id: <200010112041.NAA28844@info.engr.sgi.com>
X-Pv-Incident: 804570 
webPV:  fzr600.americas.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (coreym@sgi.com)
Subject: BUG 804570 - The elevator bug
To:     nb@sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804570

Submitter : coreym                    Submitter Domain : sgi.com            
Assigned Engineer : nb                Assigned Domain : sgi.com             
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 3                          
Project : xfs-linux                   Status : open                         
Description :
I ran rwtest on a xfs-linux filesystem on the machine permit:

rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &

This caused df, ls -l, fdisk, and top all to hang.

Permit is running Redhat 6.2 with a 2.4.0-test5 kernel

From owner-linux-xfs@oss.sgi.com Wed Oct 11 15:42:32 2000
Received:  by oss.sgi.com id <S42247AbQJKWmW>;
	Wed, 11 Oct 2000 15:42:22 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47927 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42207AbQJKWmF>; Wed, 11 Oct 2000 15:42:05 -0700
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA06064; Wed, 11 Oct 2000 15:48:34 -0700 (PDT)
	mail_from (pv@feature.engr.sgi.com)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA78681; Wed, 11 Oct 2000 15:40:05 -0700 (PDT)
Date:   Wed, 11 Oct 2000 15:40:05 -0700 (PDT)
Message-Id: <200010112240.PAA78681@feature.engr.sgi.com>
X-Pv-Incident: 803625 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (lord@sgi.com)
Subject: TAKE 803625 - xfs_growfs QA failure and possible pagebuf problem
To:     ananth@cthulhu.engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

 Submitter : ajag                     *Status : closed                      
 Assigned Engineer : ananth           *Fixed By : lord                      
*Fixed By Domain : sgi.com            *Closed Date : 10/11/00               
 Priority : 2                         *Modified Date : 10/11/00             
*Modified User : lord                 *Modified User Domain : sgi.com       
*Fix Description :
From: steve lord <lord@sgi.com> (TAKE)
Date: Oct 11 2000 03:40:05PM
[pvnews version: 1.71]
----------------------------

In updating the secondary superblocks in growfs we ended up requesting
a buffer which overlapped with a previously written agf block. The
pagebuf module bounces this request. This is a difference in behavior
from irix, but we may as well ask for a buffer of the correct size
here and just update the secondary superblock.

Date:  Wed Oct 11 15:32:07 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76090a
linux/fs/xfs/xfs_fsops.c - 1.60
	- When updating super blocks in growfs ask for a superblock sized
	  buffer rather than an fs block size buffer. This prevents us from
	  overlapping with other buffers previously written.
Description :
The growfs QA test creates a 16Mb filesystem with one allocation group and
sucessively grows its size to 17, 33, 35 and 48 megabyte (3 ags) with four calls to
xfs_growfs. The first growfs appears to succeed, however, subsequents calls fail
on a call to xfs_read_buf (line 336 xfs_fsops.c) while writing out the redundant
superblocks for the filesystem. The call sequence looks like:
 
xfs_growfs_data_private
  xfs_read_buf (function)
    xfs_buf_read (macro)
      pagebuf_get (function call at line 747 page_buf.c)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: lord@sgi.com (BugWorks)
Date: Oct 03 2000 11:22:27AM
==========================

It looks like the pagebuf written out for the first superblock
update has not been written yet - it should get unlocked at the
end of the write to disk. If you turn on pagebuf tracing,
and call BUG() where the EBUSY error is happening the pbtrace
will tell you who did what with the buffer.

From owner-linux-xfs@oss.sgi.com Wed Oct 11 17:06:41 2000
Received:  by oss.sgi.com id <S42193AbQJLAGc>;
	Wed, 11 Oct 2000 17:06:32 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:18714 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42180AbQJLAF6>;
	Wed, 11 Oct 2000 17:05:58 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA09209; Wed, 11 Oct 2000 16:57:27 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA33629;
	Wed, 11 Oct 2000 17:05:11 -0700 (PDT)
Date:   Wed, 11 Oct 2000 17:05:11 -0700 (PDT)
Message-Id: <200010120005.RAA33629@info.engr.sgi.com>
X-Pv-Incident: 802017 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: REOPEN 802017 - ASSERT fail in xlog_get_bp on small mem machine
To:     dxm@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017

*Status : open                         Priority : 3                         
 Assigned Engineer : dxm               Submitter : dxm                      
 Project : xfs-linux                   Assigned Group : xfs-linux           
 Opened Date : 09/17/00               *Closed Date :                        
*Fixed By :                           *Fixed By Domain :                    
*Verified Date :                      *Modified User : dxm                  
*Modified User Domain : engr          *Description :
I haven't seen this problem for ages on my 64Mb crash box,
but the problem is still there.

I installed XFS on my home machine last night and was very
happy with its performance (P100, 32Mb RAM, 32Gb disk) until 
I tried to cleanly remount my XFS partition and tripped an 
ASSERT in xlog_get_bp.

My home machine is very tight on memory, but I don't think
it's an unreasonable machine to try to run XFS on. Unfortunately,

.....


==========================
ADDITIONAL INFORMATION (REOPEN)
From: dxm@engr (BugWorks)
Date: Oct 11 2000 05:05:10PM
==========================

Want to push this into the next beta.

From owner-linux-xfs@oss.sgi.com Wed Oct 11 17:39:02 2000
Received:  by oss.sgi.com id <S42203AbQJLAiw>;
	Wed, 11 Oct 2000 17:38:52 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:8993 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42180AbQJLAiZ>;
	Wed, 11 Oct 2000 17:38:25 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA12513; Wed, 11 Oct 2000 17:29:59 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA22404;
	Wed, 11 Oct 2000 17:37:42 -0700 (PDT)
Date:   Wed, 11 Oct 2000 17:37:42 -0700 (PDT)
Message-Id: <200010120037.RAA22404@info.engr.sgi.com>
X-Pv-Incident: 802017 
webPV:  proxy2.melbourne.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: UPDATE 802017 - non-empty log recover fails on small memory machine
To:     dxm@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=802017

*Summary : non-empty log recover fails on small memory machine
 Status : open                        
 Priority : 3                          Assigned Engineer : dxm              
 Submitter : dxm                       Opened Date : 09/17/00               
*Modified User : dxm                  *Modified User Domain : engr          
*Description :
I haven't seen this problem for ages on my 64Mb crash box,
but the problem is still there.

I installed XFS on my home machine last night and was very
happy with its performance (P100, 32Mb RAM, 32Gb disk) until 
I tried to cleanly remount my XFS partition and tripped an 
ASSERT in xlog_get_bp.

My home machine is very tight on memory, but I don't think
it's an unreasonable machine to try to run XFS on. Unfortunately,

.....


==========================
ADDITIONAL INFORMATION (UPDATE)
From: dxm@engr (BugWorks)
Date: Oct 11 2000 05:37:41PM
==========================

I've attached the patch to push this fix into the beta.
QA passes ok.

--- /usr/tmp/p_rdiff_a0sZoC/xfs_log_recover.c   Thu Oct 12 11:11:44 2000
+++ /build1/people/dxm/isms/slinx-xfs/linux/fs/xfs/xfs_log_recover.c    Wed Oct 11 14:12:05 2000
@@ -149,6 +149,7 @@
        xfs_buf_t   *bp;
 
        ASSERT(num_bblks > 0);
+
        bp = XFS_ngetrbuf(BBTOB(num_bblks),mp);
        return bp;
 }      /* xlog_get_bp */
@@ -294,24 +295,52 @@
  * Return -1 if we encounter no errors.  This is an invalid block number
  * since we don't ever expect logs to get this large.
  */
+
 STATIC xfs_daddr_t
-xlog_find_verify_cycle(xfs_caddr_t     *bap,           /* update ptr as we go */
-                      xfs_daddr_t      start_blk,
-                      int      nbblks,
-                      uint     stop_on_cycle_no)
+xlog_find_verify_cycle( xlog_t                 *log,
+                       xfs_daddr_t     start_blk,
+                       int             nbblks,
+                       uint            stop_on_cycle_no)
 {
-       int     i;
-       uint    cycle;
+       int                     i;
+       uint                    cycle;
+       xfs_buf_t               *bp;
+       char                    *buf        = NULL;
+       int                     error       = 0;
+       int                     smallmem    = 0;
+
+       if (!(bp = xlog_get_bp(nbblks, log->l_mp))) {
+                /* can't get enough memory to do everything in one big buffer */
+               if (!(bp = xlog_get_bp(1, log->l_mp)))
+                       return -ENOMEM;
+                smallmem = 1;
+        } else {
+               if ((error = xlog_bread(log, start_blk, nbblks, bp)))
+                       goto out;
+        }
+        
+        buf = XFS_BUF_PTR(bp);
 
-       for (i=0; i<nbblks; i++) {
-               cycle = GET_CYCLE(*bap, ARCH_CONVERT);
-               if (cycle != stop_on_cycle_no) {
-                       (*bap) += BBSIZE;
-               } else {
-                       return (start_blk+i);
+       for (i=start_blk; i< start_blk + nbblks; i++) {
+                if (smallmem && (error = xlog_bread(log, i, 1, bp)))
+                       goto out;
+
+               cycle = GET_CYCLE(buf, ARCH_CONVERT);
+               if (cycle == stop_on_cycle_no) {
+                       error = i;
+                       goto out;
                }
+                
+                if (!smallmem)
+                        buf += BBSIZE;
        }
-       return -1;
+
+       error = -1;
+
+out:
+       xlog_put_bp(bp);
+
+       return error;
 }      /* xlog_find_verify_cycle */
 
 
@@ -327,29 +356,55 @@
  * extra_bblks is the number of blocks potentially verified on a previous
  * call to this routine.
  */
+
 STATIC int
-xlog_find_verify_log_record(xfs_caddr_t        ba,          /* update ptr as we go */
+xlog_find_verify_log_record(xlog_t     *log,
                            xfs_daddr_t start_blk,
                            xfs_daddr_t *last_blk,
                            int         extra_bblks)
 {
-    xlog_rec_header_t *rhead;
-    xfs_daddr_t           i;
+    xfs_daddr_t         i;
+    xfs_buf_t          *bp;
+    char                *buf        = NULL;
+    xlog_rec_header_t  *head;
+    int                        error       = 0;
+    int                 smallmem    = 0;
+    int                 num_blks    = *last_blk - start_blk;
 
     ASSERT(start_blk != 0 || *last_blk != start_blk);
 
-    ba -= BBSIZE;
+    if (!(bp = xlog_get_bp(num_blks, log->l_mp))) {
+        if (!(bp = xlog_get_bp(1, log->l_mp))) 
+           return -ENOMEM;
+        smallmem = 1;
+        buf = XFS_BUF_PTR(bp);
+    } else {
+       if ((error = xlog_bread(log, start_blk, num_blks, bp)))
+           goto out;
+        buf = XFS_BUF_PTR(bp) + (num_blks - 1) * BBSIZE;
+    }
+    
+
     for (i=(*last_blk)-1; i>=0; i--) {
        if (i < start_blk) {
            /* legal log record not found */
-           xlog_warn("XFS: xlog_find_verify_log_record: need to back-up");
+           xlog_warn("XFS: Log inconsistent (didn't find previous header)");
+#ifdef __KERNEL__
            ASSERT(0);
-           return XFS_ERROR(EIO);
+#endif
+           error = XFS_ERROR(EIO);
+           goto out;
        }
-       if (INT_GET(*(uint *)ba, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM) {
+
+       if (smallmem && (error = xlog_bread(log, i, 1, bp)))
+           goto out;
+       head = (xlog_rec_header_t*)buf;
+       
+       if (INT_GET(head->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM)
            break;
-       }
-       ba -= BBSIZE;
+        
+        if (!smallmem)
+            buf -= BBSIZE;
     }
 
     /*
@@ -357,8 +412,10 @@
      * to caller.  If caller can handle a return of -1, then this routine
      * will be called again for the end of the physical log.
      */
-    if (i == -1)
-           return -1;
+    if (i == -1) {
+       error = -1;
+       goto out;
+    }
 
     /*
      * We may have found a log record header before we expected one.
@@ -367,12 +424,15 @@
      * reset last_blk.  Only when last_blk points in the middle of a log
      * record do we update last_blk.
      */
-    rhead = (xlog_rec_header_t *)ba;
-    if (*last_blk - i + extra_bblks != BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT))+1)
+    if (*last_blk - i + extra_bblks 
+               != BTOBB(INT_GET(head->h_len, ARCH_CONVERT))+1)
            *last_blk = i;
-    return 0;
-}      /* xlog_find_verify_log_record */
+
+out:
+    xlog_put_bp(bp);
 
+    return error;
+}      /* xlog_find_verify_log_record */
 
 /*
  * Head is defined to be the point of the log where the next log write
@@ -393,15 +453,14 @@
 xlog_find_head(xlog_t  *log,
               xfs_daddr_t *return_head_blk)
 {
-    xfs_buf_t   *bp, *big_bp;
+    xfs_buf_t   *bp;
     xfs_daddr_t new_blk, first_blk, start_blk, last_blk, head_blk;
     int     num_scan_bblks;
     uint    first_half_cycle, last_half_cycle;
     uint    stop_on_cycle;
-    xfs_caddr_t ba;
     int     error, log_bbnum = log->l_logBBsize;
 
-    /* special case freshly mkfs'ed filesystem; return immediately */
+    /* Is the end of the log device zeroed? */
     if ((error = xlog_find_zeroed(log, &first_blk)) == -1) {
        *return_head_blk = first_blk;
        return 0;
@@ -413,7 +472,7 @@
     first_blk = 0;                             /* get cycle # of 1st block */
     bp = xlog_get_bp(1,log->l_mp);
     if (!bp)
-        return -ENOMEM;
+       return -ENOMEM;
     if (error = xlog_bread(log, 0, 1, bp))
        goto bp_err;
     first_half_cycle = GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT);
@@ -495,12 +554,6 @@
      * we actually look at the block size of the filesystem.
      */
     num_scan_bblks = BTOBB(XLOG_MAX_ICLOGS<<XLOG_MAX_RECORD_BSHIFT);
-    big_bp = xlog_get_bp(num_scan_bblks,log->l_mp);
-    if (!big_bp) {
-        error = -ENOMEM;
-        goto bp_err;
-    }
-        
     if (head_blk >= num_scan_bblks) {
        /*
         * We are guaranteed that the entire check can be performed
@@ -507,10 +560,7 @@
         * in one buffer.
         */
        start_blk = head_blk - num_scan_bblks;
-       if (error = xlog_bread(log, start_blk, num_scan_bblks, big_bp))
-           goto big_bp_err;
-       ba = XFS_BUF_PTR(big_bp);
-       new_blk = xlog_find_verify_cycle(&ba, start_blk, num_scan_bblks,
+       new_blk = xlog_find_verify_cycle(log, start_blk, num_scan_bblks,
                                         stop_on_cycle);
        if (new_blk != -1)
            head_blk = new_blk;
@@ -542,11 +592,7 @@
         */
        start_blk = log_bbnum - num_scan_bblks + head_blk;
        ASSERT(head_blk <= INT_MAX && (xfs_daddr_t) num_scan_bblks-head_blk >= 0);
-       if (error = xlog_bread(log, start_blk,
-                       num_scan_bblks-(int)head_blk, big_bp))
-           goto big_bp_err;
-       ba = XFS_BUF_PTR(big_bp);
-       new_blk= xlog_find_verify_cycle(&ba, start_blk,
+       new_blk= xlog_find_verify_cycle(log, start_blk,
                     num_scan_bblks-(int)head_blk, (stop_on_cycle - 1));
        if (new_blk != -1) {
            head_blk = new_blk;
@@ -560,10 +606,7 @@
         */
        start_blk = 0;
        ASSERT(head_blk <= INT_MAX);
-       if (error = xlog_bread(log, start_blk, (int) head_blk, big_bp))
-           goto big_bp_err;
-       ba = XFS_BUF_PTR(big_bp);
-       new_blk = xlog_find_verify_cycle(&ba, start_blk, (int) head_blk,
+       new_blk = xlog_find_verify_cycle(log, start_blk, (int) head_blk,
                                         stop_on_cycle);
        if (new_blk != -1)
            head_blk = new_blk;
@@ -577,26 +620,20 @@
     num_scan_bblks = BTOBB(XLOG_MAX_RECORD_BSIZE);
     if (head_blk >= num_scan_bblks) {
        start_blk = head_blk - num_scan_bblks;  /* don't read head_blk */
-       if (error = xlog_bread(log, start_blk, num_scan_bblks, big_bp))
-           goto big_bp_err;
 
        /* start ptr at last block ptr before head_blk */
-       ba = XFS_BUF_PTR(big_bp) + XLOG_MAX_RECORD_BSIZE;
-       if ((error = xlog_find_verify_log_record(ba,
+       if ((error = xlog_find_verify_log_record(log,
                                                 start_blk,
                                                 &head_blk,
                                                 0)) == -1) {
            error = XFS_ERROR(EIO);
-           goto big_bp_err;
+           goto bp_err;
        } else if (error)
-           goto big_bp_err;
+           goto bp_err;
     } else {
        start_blk = 0;
        ASSERT(head_blk <= INT_MAX);
-       if (error = xlog_bread(log, start_blk, (int)head_blk, big_bp))
-           goto big_bp_err;
-       ba = XFS_BUF_PTR(big_bp) + BBTOB(head_blk);
-       if ((error = xlog_find_verify_log_record(ba,
+       if ((error = xlog_find_verify_log_record(log,
                                                 start_blk,
                                                 &head_blk,
                                                 0)) == -1) {
@@ -604,26 +641,21 @@
            start_blk = log_bbnum - num_scan_bblks + head_blk;
            new_blk = log_bbnum;
            ASSERT(start_blk <= INT_MAX && (xfs_daddr_t) log_bbnum-start_blk >= 0);
-           if (error = xlog_bread(log, start_blk, log_bbnum - (int)start_blk,
-                                  big_bp))
-               goto big_bp_err;
-           ba = XFS_BUF_PTR(big_bp) + BBTOB(log_bbnum - start_blk);
            ASSERT(head_blk <= INT_MAX);
-           if ((error = xlog_find_verify_log_record(ba,
+           if ((error = xlog_find_verify_log_record(log,
                                                     start_blk,
                                                     &new_blk,
                                                     (int)head_blk)) == -1) {
                error = XFS_ERROR(EIO);
-               goto big_bp_err;
+               goto bp_err;
            } else if (error)
-               goto big_bp_err;
+               goto bp_err;
            if (new_blk != log_bbnum)
                head_blk = new_blk;
        } else if (error)
-           goto big_bp_err;
+           goto bp_err;
     }
 
-    xlog_put_bp(big_bp);
     xlog_put_bp(bp);
     if (head_blk == log_bbnum)
            *return_head_blk = 0;
@@ -637,8 +669,6 @@
      */
     return 0;
 
-big_bp_err:
-       xlog_put_bp(big_bp);
 bp_err:
        xlog_put_bp(bp);
 
@@ -755,8 +785,8 @@
                return error;
 
        bp = xlog_get_bp(1,log->l_mp);
-        if (!bp) 
-            return -ENOMEM;
+       if (!bp)
+               return -ENOMEM;
        if (*head_blk == 0) {                           /* special case */
                if (error = xlog_bread(log, 0, 1, bp))
                        goto bread_err;
@@ -907,18 +937,17 @@
 xlog_find_zeroed(struct log    *log,
                 xfs_daddr_t    *blk_no)
 {
-       xfs_buf_t       *bp, *big_bp;
-       uint    first_cycle, last_cycle;
+       xfs_buf_t       *bp;
+       uint            first_cycle, last_cycle;
        xfs_daddr_t     new_blk, last_blk, start_blk;
-       xfs_daddr_t num_scan_bblks;
-       xfs_caddr_t     ba;
-       int     error, log_bbnum = log->l_logBBsize;
+       xfs_daddr_t     num_scan_bblks;
+       int             error, log_bbnum = log->l_logBBsize;
 
        error = 0;
        /* check totally zeroed log */
        bp = xlog_get_bp(1,log->l_mp);
-        if (!bp)
-            return -ENOMEM;
+       if (!bp)
+               return -ENOMEM;
        if (error = xlog_bread(log, 0, 1, bp))
                goto bp_err;
        first_cycle = GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT);
@@ -937,11 +966,11 @@
                return 0;
        } else if (first_cycle != 1) {
                /*
-                * Hopefully, this will catch the case where someone mkfs's
-                * over a log partition.
+                * If the cycle of the last block is zero, the cycle of
+                 * the first block must be 1. If it's not, maybe we're
+                 * not looking at a log... Bail out.
                 */
-       xlog_warn("XFS: (xlog_find_zeroed): last cycle = 0; first cycle != 1");
-               ASSERT(first_cycle == 1);
+               xlog_warn("XFS: Log inconsistent or not a log (last==0, first!=1)");
                return XFS_ERROR(EINVAL);
        }
         
@@ -958,21 +987,11 @@
         */
        num_scan_bblks = BTOBB(XLOG_MAX_ICLOGS<<XLOG_MAX_RECORD_BSHIFT);
        ASSERT(num_scan_bblks <= INT_MAX);
-       big_bp = xlog_get_bp((int)num_scan_bblks,log->l_mp);
-        if (!big_bp) {
-            error = -ENOMEM;
-            goto bp_err;
-        }
-        ASSERT(big_bp);
         
        if (last_blk < num_scan_bblks)
                num_scan_bblks = last_blk;
        start_blk = last_blk - num_scan_bblks;
-        
-       if (error = xlog_bread(log, start_blk, (int)num_scan_bblks, big_bp))
-               goto big_bp_err;
-       ba = XFS_BUF_PTR(big_bp);
-        
+     
        /*
         * We search for any instances of cycle number 0 that occur before
         * our current estimate of the head.  What we're trying to detect is
@@ -979,8 +998,7 @@
         *        1 ... | 0 | 1 | 0...
         *                       ^ binary search ends here
         */
-       new_blk = xlog_find_verify_cycle(&ba, start_blk,
-                                        (int)num_scan_bblks, 0);
+       new_blk = xlog_find_verify_cycle(log, start_blk, (int)num_scan_bblks,0);
        if (new_blk != -1)
                last_blk = new_blk;
 
@@ -988,12 +1006,11 @@
         * Potentially backup over partial log record write.  We don't need
         * to search the end of the log because we know it is zero.
         */
-       if (error = xlog_find_verify_log_record(ba, start_blk, &last_blk, 0))
-           goto big_bp_err;
+       if (error = xlog_find_verify_log_record(log, start_blk, 
+                               &last_blk, 0))
+           goto bp_err;
 
        *blk_no = last_blk;
-big_bp_err:
-       xlog_put_bp(big_bp);
 bp_err:
        xlog_put_bp(bp);
        if (error)
@@ -1014,32 +1031,56 @@
        int     start_block,
        int     blocks,
        int     tail_cycle,
-       int     tail_block,                    
-       xfs_buf_t       *bp)
+       int     tail_block)
 {
        xlog_rec_header_t       *recp;
        int                     i;
-       int                     curr_block;
-       int                     error;
+       int                     error       = 0;
+       xfs_buf_t               *bp;
+       char                    *buf;
+        int                     smallmem    = 0;
 
-       recp = (xlog_rec_header_t*)(XFS_BUF_PTR(bp));
-       curr_block = start_block;
-       for (i = 0; i < blocks; i++) {
-               INT_SET(recp->h_magicno, ARCH_CONVERT, XLOG_HEADER_MAGIC_NUM);
-               INT_SET(recp->h_cycle, ARCH_CONVERT, cycle);
-               INT_SET(recp->h_version, ARCH_CONVERT, 1);
-               INT_ZERO(recp->h_len, ARCH_CONVERT);
-               ASSIGN_ANY_LSN(recp->h_lsn, cycle, curr_block, ARCH_CONVERT);
-               ASSIGN_ANY_LSN(recp->h_tail_lsn, tail_cycle, tail_block, ARCH_CONVERT);
-               INT_ZERO(recp->h_chksum, ARCH_CONVERT);
-               INT_ZERO(recp->h_prev_block, ARCH_CONVERT);     /* unused */
-               INT_ZERO(recp->h_num_logops, ARCH_CONVERT);
-               
-               curr_block++;
-               recp = (xlog_rec_header_t*)(((char *)recp) + BBSIZE);
-       }
+        if (!(bp = xlog_get_bp(blocks, log->l_mp))) {
+                if (!(bp = xlog_get_bp(1, log->l_mp)))
+                       return -ENOMEM;
+                smallmem = 1;
+        }
+        
+        buf = XFS_BUF_PTR(bp);
+       recp = (xlog_rec_header_t*)buf;
 
-       error = xlog_bwrite(log, start_block, blocks, bp);
+        memset(buf, 0, BBSIZE);
+        INT_SET(recp->h_magicno, ARCH_CONVERT, XLOG_HEADER_MAGIC_NUM);
+        INT_SET(recp->h_cycle, ARCH_CONVERT, cycle);
+        INT_SET(recp->h_version, ARCH_CONVERT, 1);
+        INT_ZERO(recp->h_len, ARCH_CONVERT);
+        ASSIGN_ANY_LSN(recp->h_tail_lsn, tail_cycle, tail_block, ARCH_CONVERT);
+        INT_ZERO(recp->h_chksum, ARCH_CONVERT);
+        INT_ZERO(recp->h_prev_block, ARCH_CONVERT);    /* unused */
+        INT_ZERO(recp->h_num_logops, ARCH_CONVERT);
+        
+        if (smallmem) {
+                /* for small mem, we keep modifying the block and writing */
+               for (i = start_block; i < start_block + blocks; i++) {
+                       ASSIGN_ANY_LSN(recp->h_lsn, cycle, i, ARCH_CONVERT);
+                       if ((error = xlog_bwrite(log, i, 1, bp)))
+                               break;
+               }
+        } else {
+               ASSIGN_ANY_LSN(recp->h_lsn, cycle, start_block, ARCH_CONVERT);
+               for (i = start_block+1; i < start_block + blocks; i++) {
+                        /* with plenty of memory, we duplicate the block
+                         * right through the buffer and modify each entry
+                         */
+                        buf += BBSIZE;
+                       recp = (xlog_rec_header_t*)buf;
+                        memcpy(buf, XFS_BUF_PTR(bp), BBSIZE);
+                       ASSIGN_ANY_LSN(recp->h_lsn, cycle, i, ARCH_CONVERT);
+                }
+                /* then write the whole lot out at once */
+               error = xlog_bwrite(log, start_block, blocks, bp);
+        }
+       xlog_put_bp(bp);
 
        return error;
 }
@@ -1072,7 +1113,6 @@
        int                     tail_distance;
        int                     max_distance;
        int                     distance;
-       xfs_buf_t               *bp;
        int                     error;
 
        tail_cycle = CYCLE_LSN(tail_lsn, ARCH_NOCONVERT);
@@ -1127,9 +1167,6 @@
         * for no reason.
         */
        max_distance = MIN(max_distance, tail_distance);
-       bp = xlog_get_bp(max_distance,log->l_mp);
-        if (!bp)
-            return -ENOMEM;
        
        if ((head_block + max_distance) <= log->l_logBBsize) {
                /*
@@ -1141,11 +1178,7 @@
                 */
                error = xlog_write_log_records(log, (head_cycle - 1),
                                head_block, max_distance, tail_cycle,
-                               tail_block, bp);
-               if (error) {
-                       xlog_put_bp(bp);
-                       return error;
-               }
+                               tail_block);
        } else {
                /*
                 * We need to wrap around the end of the physical log in
@@ -1157,11 +1190,10 @@
                distance = log->l_logBBsize - head_block;
                error = xlog_write_log_records(log, (head_cycle - 1),
                                head_block, distance, tail_cycle,
-                               tail_block, bp);
-               if (error) {
-                       xlog_put_bp(bp);
+                               tail_block);
+
+               if (error)
                        return error;
-               }
 
                /*
                 * Now write the blocks at the start of the physical log.
@@ -1173,15 +1205,9 @@
                 */
                distance = max_distance - (log->l_logBBsize - head_block);
                error = xlog_write_log_records(log, head_cycle, 0, distance,
-                               tail_cycle, tail_block, bp);
-               if (error) {
-                       xlog_put_bp(bp);
-                       return error;
-               }
+                               tail_cycle, tail_block);
        }
 
-       xlog_put_bp(bp);
-
        return 0;
 }
 #endif /* SIM */
@@ -3135,11 +3161,11 @@
     error = 0;
     hbp = xlog_get_bp(1,log->l_mp);
     if (!hbp)
-        return -ENOMEM;
+       return -ENOMEM;
     dbp = xlog_get_bp(BTOBB(XLOG_MAX_RECORD_BSIZE),log->l_mp);
     if (!dbp) {
-        xlog_put_bp(hbp);
-        return -ENOMEM;
+       xlog_put_bp(hbp);
+       return -ENOMEM;
     }
     bzero(rhash, sizeof(rhash));
     if (tail_blk <= head_blk) {
@@ -3175,7 +3201,7 @@
                goto bread_err;
            rhead = (xlog_rec_header_t *)XFS_BUF_PTR(hbp);
            ASSERT(INT_GET(rhead->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM);
-           ASSERT(BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT) <= INT_MAX));
+           ASSERT(BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT) <= INT_MAX));            
            bblks = (int) BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT));
 
            /* LR body must have data or it wouldn't have been written */

From owner-linux-xfs@oss.sgi.com Thu Oct 12 04:13:54 2000
Received:  by oss.sgi.com id <S42182AbQJLLNp>;
	Thu, 12 Oct 2000 04:13:45 -0700
Received: from akira.ep-ag.com ([194.120.231.250]:10362 "EHLO akira.ep-ka.de")
	by oss.sgi.com with ESMTP id <S42180AbQJLLNJ>;
	Thu, 12 Oct 2000 04:13:09 -0700
Received: from ep-ag.com (sol10.ep-ka.de [194.120.231.11])
	by akira.ep-ka.de (8.9.1/8.9.3) with ESMTP id MAA11364
	for <linux-xfs@oss.sgi.com>; Thu, 12 Oct 2000 12:12:27 +0200
Received: from ep-ag.com (stb@crusher.ep-ka.de [194.120.231.18])
	by ep-ag.com (8.9.3/8.9.3) with ESMTP id NAA27576
	for <linux-xfs@oss.sgi.com>; Thu, 12 Oct 2000 13:12:27 +0200 (MET DST)
Message-ID: <39E59C9B.68DEE06B@ep-ag.com>
Date:   Thu, 12 Oct 2000 13:12:27 +0200
From:   Klaus Strebel <stb@ep-ag.com>
Organization: EIGNER+PARTNER AG
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS-test8 i686)
X-Accept-Language: de, en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: LVM brocken
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi !

i just pulled out an actual source-tree for linux-2.4-xfs (hm, about 10
MEST), built it and found a problem with lvm. Any filesystem on a
logical volumn can't be mounted - superblocks cannot be read (for ext2,
reiserfs, xfs  ;-). Probably a problem with ll_rw_block (can't track
this down, rm'ed my sources from 10/10/2000 that worked so far, but
couldnd umount xfs :-( ).

Another 'issue' for me is, that the mountoption 'nokio' is not treated
in fs/xfs/linux/xfs_mount_opt.c. I'd liked something like this added :

                } else if (!strcmp(this_char, MNTOPT_KIOCLUSTER)) {
                        args->flags |= MS_KIOBUFIO|MS_KIOCLUSTER;
                } else if (!strcmp(this_char, MNTOPT_NOKIO)) {
                        args->flags &= !MS_KIOBUFIO;
                        args->flags &= !MS_KIOCLUSTER;
                } else {

Without it, you get the message "mount: unknown mount option "nokio"."

Cheers
Klaus
-- 
Klaus Strebel
stb@ep-ag.com
EIGNER + PARTNER AG   - The e-Engineering Company -
<http://www.ep-ag.com>

From owner-linux-xfs@oss.sgi.com Thu Oct 12 07:50:24 2000
Received:  by oss.sgi.com id <S42183AbQJLOuE>;
	Thu, 12 Oct 2000 07:50:04 -0700
Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:25866 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S42207AbQJLOtl>;
	Thu, 12 Oct 2000 07:49:41 -0700
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e9CEmBT12029;
	Thu, 12 Oct 2000 09:48:16 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <39E5CF2B.4C0BB26E@thebarn.com>
Date:   Thu, 12 Oct 2000 09:48:11 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Klaus Strebel <stb@ep-ag.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: LVM brocken
References: <39E59C9B.68DEE06B@ep-ag.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Klaus Strebel wrote:

> Hi !
>
> i just pulled out an actual source-tree for linux-2.4-xfs (hm, about 10
> MEST), built it and found a problem with lvm. Any filesystem on a
> logical volumn can't be mounted - superblocks cannot be read (for ext2,
> reiserfs, xfs  ;-). Probably a problem with ll_rw_block (can't track
> this down, rm'ed my sources from 10/10/2000 that worked so far, but
> couldnd umount xfs :-( ).

Yes it seems the latest test8 version of ll_rw_block has broken
lvm. We are looking into it hopefully it will be fixed soon.
Recommend going to the beta tree if you want to use lvm support.
"linux-2.4-xfs-beta" in the oss cvs repository.


>
>
> Another 'issue' for me is, that the mountoption 'nokio' is not treated
> in fs/xfs/linux/xfs_mount_opt.c. I'd liked something like this added :
>
>                 } else if (!strcmp(this_char, MNTOPT_KIOCLUSTER)) {
>                         args->flags |= MS_KIOBUFIO|MS_KIOCLUSTER;
>                 } else if (!strcmp(this_char, MNTOPT_NOKIO)) {
>                         args->flags &= !MS_KIOBUFIO;
>                         args->flags &= !MS_KIOCLUSTER;
>                 } else {
>
> Without it, you get the message "mount: unknown mount option "nokio"."

That option isn't supported yet.
I may be used  in the future to change an existing  mount to a not kio  FS
via a remount.

For the moment specifying a mount without the kio flag is the same
semantics of
having the nokio flag in the mount flags.


>
>
> Cheers
> Klaus
> --
> Klaus Strebel
> stb@ep-ag.com
> EIGNER + PARTNER AG   - The e-Engineering Company -
> <http://www.ep-ag.com>

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Thu Oct 12 07:52:54 2000
Received:  by oss.sgi.com id <S42207AbQJLOwe>;
	Thu, 12 Oct 2000 07:52:34 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:18474 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42195AbQJLOwD>;
	Thu, 12 Oct 2000 07:52:03 -0700
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA19161; Thu, 12 Oct 2000 07:43:37 -0700 (PDT)
	mail_from (pv@feature.engr.sgi.com)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA98138; Thu, 12 Oct 2000 07:50:04 -0700 (PDT)
Date:   Thu, 12 Oct 2000 07:50:04 -0700 (PDT)
Message-Id: <200010121450.HAA98138@feature.engr.sgi.com>
X-Pv-Incident: 802017 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (lord@sgi.com)
Subject: TAKE 802017 - non-empty log recover fails on small memory machine
To:     dxm@cthulhu.engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

 Submitter : dxm                      *Status : closed                      
 Assigned Engineer : dxm              *Fixed By : lord                      
*Fixed By Domain : sgi.com            *Closed Date : 10/12/00               
 Priority : 3                         *Modified Date : 10/12/00             
*Modified User : lord                 *Modified User Domain : sgi.com       
*Fix Description :
==========================
ADDITIONAL INFORMATION (CLOSE)
From: dxm@engr (BugWorks)
Date: Sep 25 2000 05:59:42PM
==========================

Modid:  2.4.x-xfs:slinx:75004a
Date:  Mon Sep 25 17:59:23 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs-tot
Author:  dxm

.....


==========================
ADDITIONAL INFORMATION (TAKE)
From: steve lord <lord@sgi.com>
Date: Oct 12 2000 07:50:03AM
[pvnews version: 1.71]
==========================
This should allow the beta release to work well on low memory machines.

Date:  Thu Oct 12 07:45:02 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-beta

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-beta


Modid:  2.4.x-xfs-beta:slinx:76107a
linux/fs/xfs/xfs_log_recover.c - 1.190
	- Backport of fixes for low memory xfs log recovery and mount from PV 802017
Description :
I haven't seen this problem for ages on my 64Mb crash box,
but the problem is still there.

I installed XFS on my home machine last night and was very
happy with its performance (P100, 32Mb RAM, 32Gb disk) until 
I tried to cleanly remount my XFS partition and tripped an 
ASSERT in xlog_get_bp.

My home machine is very tight on memory, but I don't think
it's an unreasonable machine to try to run XFS on. Unfortunately,

.....


==========================
ADDITIONAL INFORMATION (UPDATE)
From: dxm@engr (BugWorks)
Date: Oct 11 2000 05:37:41PM
==========================

I've attached the patch to push this fix into the beta.
QA passes ok.

--- /usr/tmp/p_rdiff_a0sZoC/xfs_log_recover.c   Thu Oct 12 11:11:44 2000
+++ /build1/people/dxm/isms/slinx-xfs/linux/fs/xfs/xfs_log_recover.c    Wed Oct 11 14:12:05 2000
@@ -149,6 +149,7 @@
        xfs_buf_t   *bp;
 
        ASSERT(num_bblks > 0);
+
        bp = XFS_ngetrbuf(BBTOB(num_bblks),mp);
        return bp;
 }      /* xlog_get_bp */
@@ -294,24 +295,52 @@
  * Return -1 if we encounter no errors.  This is an invalid block number
  * since we don't ever expect logs to get this large.
  */
+
 STATIC xfs_daddr_t
-xlog_find_verify_cycle(xfs_caddr_t     *bap,           /* update ptr as we go */
-                      xfs_daddr_t      start_blk,
-                      int      nbblks,
-                      uint     stop_on_cycle_no)
+xlog_find_verify_cycle( xlog_t                 *log,
+                       xfs_daddr_t     start_blk,
+                       int             nbblks,
+                       uint            stop_on_cycle_no)
 {
-       int     i;
-       uint    cycle;
+       int                     i;
+       uint                    cycle;
+       xfs_buf_t               *bp;
+       char                    *buf        = NULL;
+       int                     error       = 0;
+       int                     smallmem    = 0;
+
+       if (!(bp = xlog_get_bp(nbblks, log->l_mp))) {
+                /* can't get enough memory to do everything in one big buffer */
+               if (!(bp = xlog_get_bp(1, log->l_mp)))
+                       return -ENOMEM;
+                smallmem = 1;
+        } else {
+               if ((error = xlog_bread(log, start_blk, nbblks, bp)))
+                       goto out;
+        }
+        
+        buf = XFS_BUF_PTR(bp);
 
-       for (i=0; i<nbblks; i++) {
-               cycle = GET_CYCLE(*bap, ARCH_CONVERT);
-               if (cycle != stop_on_cycle_no) {
-                       (*bap) += BBSIZE;
-               } else {
-                       return (start_blk+i);
+       for (i=start_blk; i< start_blk + nbblks; i++) {
+                if (smallmem && (error = xlog_bread(log, i, 1, bp)))
+                       goto out;
+
+               cycle = GET_CYCLE(buf, ARCH_CONVERT);
+               if (cycle == stop_on_cycle_no) {
+                       error = i;
+                       goto out;
                }
+                
+                if (!smallmem)
+                        buf += BBSIZE;
        }
-       return -1;
+
+       error = -1;
+
+out:
+       xlog_put_bp(bp);
+
+       return error;
 }      /* xlog_find_verify_cycle */
 
 
@@ -327,29 +356,55 @@
  * extra_bblks is the number of blocks potentially verified on a previous
  * call to this routine.
  */
+
 STATIC int
-xlog_find_verify_log_record(xfs_caddr_t        ba,          /* update ptr as we go */
+xlog_find_verify_log_record(xlog_t     *log,
                            xfs_daddr_t start_blk,
                            xfs_daddr_t *last_blk,
                            int         extra_bblks)
 {
-    xlog_rec_header_t *rhead;
-    xfs_daddr_t           i;
+    xfs_daddr_t         i;
+    xfs_buf_t          *bp;
+    char                *buf        = NULL;
+    xlog_rec_header_t  *head;
+    int                        error       = 0;
+    int                 smallmem    = 0;
+    int                 num_blks    = *last_blk - start_blk;
 
     ASSERT(start_blk != 0 || *last_blk != start_blk);
 
-    ba -= BBSIZE;
+    if (!(bp = xlog_get_bp(num_blks, log->l_mp))) {
+        if (!(bp = xlog_get_bp(1, log->l_mp))) 
+           return -ENOMEM;
+        smallmem = 1;
+        buf = XFS_BUF_PTR(bp);
+    } else {
+       if ((error = xlog_bread(log, start_blk, num_blks, bp)))
+           goto out;
+        buf = XFS_BUF_PTR(bp) + (num_blks - 1) * BBSIZE;
+    }
+    
+
     for (i=(*last_blk)-1; i>=0; i--) {
        if (i < start_blk) {
            /* legal log record not found */
-           xlog_warn("XFS: xlog_find_verify_log_record: need to back-up");
+           xlog_warn("XFS: Log inconsistent (didn't find previous header)");
+#ifdef __KERNEL__
            ASSERT(0);
-           return XFS_ERROR(EIO);
+#endif
+           error = XFS_ERROR(EIO);
+           goto out;
        }
-       if (INT_GET(*(uint *)ba, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM) {
+
+       if (smallmem && (error = xlog_bread(log, i, 1, bp)))
+           goto out;
+       head = (xlog_rec_header_t*)buf;
+       
+       if (INT_GET(head->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM)
            break;
-       }
-       ba -= BBSIZE;
+        
+        if (!smallmem)
+            buf -= BBSIZE;
     }
 
     /*
@@ -357,8 +412,10 @@
      * to caller.  If caller can handle a return of -1, then this routine
      * will be called again for the end of the physical log.
      */
-    if (i == -1)
-           return -1;
+    if (i == -1) {
+       error = -1;
+       goto out;
+    }
 
     /*
      * We may have found a log record header before we expected one.
@@ -367,12 +424,15 @@
      * reset last_blk.  Only when last_blk points in the middle of a log
      * record do we update last_blk.
      */
-    rhead = (xlog_rec_header_t *)ba;
-    if (*last_blk - i + extra_bblks != BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT))+1)
+    if (*last_blk - i + extra_bblks 
+               != BTOBB(INT_GET(head->h_len, ARCH_CONVERT))+1)
            *last_blk = i;
-    return 0;
-}      /* xlog_find_verify_log_record */
+
+out:
+    xlog_put_bp(bp);
 
+    return error;
+}      /* xlog_find_verify_log_record */
 
 /*
  * Head is defined to be the point of the log where the next log write
@@ -393,15 +453,14 @@
 xlog_find_head(xlog_t  *log,
               xfs_daddr_t *return_head_blk)
 {
-    xfs_buf_t   *bp, *big_bp;
+    xfs_buf_t   *bp;
     xfs_daddr_t new_blk, first_blk, start_blk, last_blk, head_blk;
     int     num_scan_bblks;
     uint    first_half_cycle, last_half_cycle;
     uint    stop_on_cycle;
-    xfs_caddr_t ba;
     int     error, log_bbnum = log->l_logBBsize;
 
-    /* special case freshly mkfs'ed filesystem; return immediately */
+    /* Is the end of the log device zeroed? */
     if ((error = xlog_find_zeroed(log, &first_blk)) == -1) {
        *return_head_blk = first_blk;
        return 0;
@@ -413,7 +472,7 @@
     first_blk = 0;                             /* get cycle # of 1st block */
     bp = xlog_get_bp(1,log->l_mp);
     if (!bp)
-        return -ENOMEM;
+       return -ENOMEM;
     if (error = xlog_bread(log, 0, 1, bp))
        goto bp_err;
     first_half_cycle = GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT);
@@ -495,12 +554,6 @@
      * we actually look at the block size of the filesystem.
      */
     num_scan_bblks = BTOBB(XLOG_MAX_ICLOGS<<XLOG_MAX_RECORD_BSHIFT);
-    big_bp = xlog_get_bp(num_scan_bblks,log->l_mp);
-    if (!big_bp) {
-        error = -ENOMEM;
-        goto bp_err;
-    }
-        
     if (head_blk >= num_scan_bblks) {
        /*
         * We are guaranteed that the entire check can be performed
@@ -507,10 +560,7 @@
         * in one buffer.
         */
        start_blk = head_blk - num_scan_bblks;
-       if (error = xlog_bread(log, start_blk, num_scan_bblks, big_bp))
-           goto big_bp_err;
-       ba = XFS_BUF_PTR(big_bp);
-       new_blk = xlog_find_verify_cycle(&ba, start_blk, num_scan_bblks,
+       new_blk = xlog_find_verify_cycle(log, start_blk, num_scan_bblks,
                                         stop_on_cycle);
        if (new_blk != -1)
            head_blk = new_blk;
@@ -542,11 +592,7 @@
         */
        start_blk = log_bbnum - num_scan_bblks + head_blk;
        ASSERT(head_blk <= INT_MAX && (xfs_daddr_t) num_scan_bblks-head_blk >= 0);
-       if (error = xlog_bread(log, start_blk,
-                       num_scan_bblks-(int)head_blk, big_bp))
-           goto big_bp_err;
-       ba = XFS_BUF_PTR(big_bp);
-       new_blk= xlog_find_verify_cycle(&ba, start_blk,
+       new_blk= xlog_find_verify_cycle(log, start_blk,
                     num_scan_bblks-(int)head_blk, (stop_on_cycle - 1));
        if (new_blk != -1) {
            head_blk = new_blk;
@@ -560,10 +606,7 @@
         */
        start_blk = 0;
        ASSERT(head_blk <= INT_MAX);
-       if (error = xlog_bread(log, start_blk, (int) head_blk, big_bp))
-           goto big_bp_err;
-       ba = XFS_BUF_PTR(big_bp);
-       new_blk = xlog_find_verify_cycle(&ba, start_blk, (int) head_blk,
+       new_blk = xlog_find_verify_cycle(log, start_blk, (int) head_blk,
                                         stop_on_cycle);
        if (new_blk != -1)
            head_blk = new_blk;
@@ -577,26 +620,20 @@
     num_scan_bblks = BTOBB(XLOG_MAX_RECORD_BSIZE);
     if (head_blk >= num_scan_bblks) {
        start_blk = head_blk - num_scan_bblks;  /* don't read head_blk */
-       if (error = xlog_bread(log, start_blk, num_scan_bblks, big_bp))
-           goto big_bp_err;
 
        /* start ptr at last block ptr before head_blk */
-       ba = XFS_BUF_PTR(big_bp) + XLOG_MAX_RECORD_BSIZE;
-       if ((error = xlog_find_verify_log_record(ba,
+       if ((error = xlog_find_verify_log_record(log,
                                                 start_blk,
                                                 &head_blk,
                                                 0)) == -1) {
            error = XFS_ERROR(EIO);
-           goto big_bp_err;
+           goto bp_err;
        } else if (error)
-           goto big_bp_err;
+           goto bp_err;
     } else {
        start_blk = 0;
        ASSERT(head_blk <= INT_MAX);
-       if (error = xlog_bread(log, start_blk, (int)head_blk, big_bp))
-           goto big_bp_err;
-       ba = XFS_BUF_PTR(big_bp) + BBTOB(head_blk);
-       if ((error = xlog_find_verify_log_record(ba,
+       if ((error = xlog_find_verify_log_record(log,
                                                 start_blk,
                                                 &head_blk,
                                                 0)) == -1) {
@@ -604,26 +641,21 @@
            start_blk = log_bbnum - num_scan_bblks + head_blk;
            new_blk = log_bbnum;
            ASSERT(start_blk <= INT_MAX && (xfs_daddr_t) log_bbnum-start_blk >= 0);
-           if (error = xlog_bread(log, start_blk, log_bbnum - (int)start_blk,
-                                  big_bp))
-               goto big_bp_err;
-           ba = XFS_BUF_PTR(big_bp) + BBTOB(log_bbnum - start_blk);
            ASSERT(head_blk <= INT_MAX);
-           if ((error = xlog_find_verify_log_record(ba,
+           if ((error = xlog_find_verify_log_record(log,
                                                     start_blk,
                                                     &new_blk,
                                                     (int)head_blk)) == -1) {
                error = XFS_ERROR(EIO);
-               goto big_bp_err;
+               goto bp_err;
            } else if (error)
-               goto big_bp_err;
+               goto bp_err;
            if (new_blk != log_bbnum)
                head_blk = new_blk;
        } else if (error)
-           goto big_bp_err;
+           goto bp_err;
     }
 
-    xlog_put_bp(big_bp);
     xlog_put_bp(bp);
     if (head_blk == log_bbnum)
            *return_head_blk = 0;
@@ -637,8 +669,6 @@
      */
     return 0;
 
-big_bp_err:
-       xlog_put_bp(big_bp);
 bp_err:
        xlog_put_bp(bp);
 
@@ -755,8 +785,8 @@
                return error;
 
        bp = xlog_get_bp(1,log->l_mp);
-        if (!bp) 
-            return -ENOMEM;
+       if (!bp)
+               return -ENOMEM;
        if (*head_blk == 0) {                           /* special case */
                if (error = xlog_bread(log, 0, 1, bp))
                        goto bread_err;
@@ -907,18 +937,17 @@
 xlog_find_zeroed(struct log    *log,
                 xfs_daddr_t    *blk_no)
 {
-       xfs_buf_t       *bp, *big_bp;
-       uint    first_cycle, last_cycle;
+       xfs_buf_t       *bp;
+       uint            first_cycle, last_cycle;
        xfs_daddr_t     new_blk, last_blk, start_blk;
-       xfs_daddr_t num_scan_bblks;
-       xfs_caddr_t     ba;
-       int     error, log_bbnum = log->l_logBBsize;
+       xfs_daddr_t     num_scan_bblks;
+       int             error, log_bbnum = log->l_logBBsize;
 
        error = 0;
        /* check totally zeroed log */
        bp = xlog_get_bp(1,log->l_mp);
-        if (!bp)
-            return -ENOMEM;
+       if (!bp)
+               return -ENOMEM;
        if (error = xlog_bread(log, 0, 1, bp))
                goto bp_err;
        first_cycle = GET_CYCLE(XFS_BUF_PTR(bp), ARCH_CONVERT);
@@ -937,11 +966,11 @@
                return 0;
        } else if (first_cycle != 1) {
                /*
-                * Hopefully, this will catch the case where someone mkfs's
-                * over a log partition.
+                * If the cycle of the last block is zero, the cycle of
+                 * the first block must be 1. If it's not, maybe we're
+                 * not looking at a log... Bail out.
                 */
-       xlog_warn("XFS: (xlog_find_zeroed): last cycle = 0; first cycle != 1");
-               ASSERT(first_cycle == 1);
+               xlog_warn("XFS: Log inconsistent or not a log (last==0, first!=1)");
                return XFS_ERROR(EINVAL);
        }
         
@@ -958,21 +987,11 @@
         */
        num_scan_bblks = BTOBB(XLOG_MAX_ICLOGS<<XLOG_MAX_RECORD_BSHIFT);
        ASSERT(num_scan_bblks <= INT_MAX);
-       big_bp = xlog_get_bp((int)num_scan_bblks,log->l_mp);
-        if (!big_bp) {
-            error = -ENOMEM;
-            goto bp_err;
-        }
-        ASSERT(big_bp);
         
        if (last_blk < num_scan_bblks)
                num_scan_bblks = last_blk;
        start_blk = last_blk - num_scan_bblks;
-        
-       if (error = xlog_bread(log, start_blk, (int)num_scan_bblks, big_bp))
-               goto big_bp_err;
-       ba = XFS_BUF_PTR(big_bp);
-        
+     
        /*
         * We search for any instances of cycle number 0 that occur before
         * our current estimate of the head.  What we're trying to detect is
@@ -979,8 +998,7 @@
         *        1 ... | 0 | 1 | 0...
         *                       ^ binary search ends here
         */
-       new_blk = xlog_find_verify_cycle(&ba, start_blk,
-                                        (int)num_scan_bblks, 0);
+       new_blk = xlog_find_verify_cycle(log, start_blk, (int)num_scan_bblks,0);
        if (new_blk != -1)
                last_blk = new_blk;
 
@@ -988,12 +1006,11 @@
         * Potentially backup over partial log record write.  We don't need
         * to search the end of the log because we know it is zero.
         */
-       if (error = xlog_find_verify_log_record(ba, start_blk, &last_blk, 0))
-           goto big_bp_err;
+       if (error = xlog_find_verify_log_record(log, start_blk, 
+                               &last_blk, 0))
+           goto bp_err;
 
        *blk_no = last_blk;
-big_bp_err:
-       xlog_put_bp(big_bp);
 bp_err:
        xlog_put_bp(bp);
        if (error)
@@ -1014,32 +1031,56 @@
        int     start_block,
        int     blocks,
        int     tail_cycle,
-       int     tail_block,                    
-       xfs_buf_t       *bp)
+       int     tail_block)
 {
        xlog_rec_header_t       *recp;
        int                     i;
-       int                     curr_block;
-       int                     error;
+       int                     error       = 0;
+       xfs_buf_t               *bp;
+       char                    *buf;
+        int                     smallmem    = 0;
 
-       recp = (xlog_rec_header_t*)(XFS_BUF_PTR(bp));
-       curr_block = start_block;
-       for (i = 0; i < blocks; i++) {
-               INT_SET(recp->h_magicno, ARCH_CONVERT, XLOG_HEADER_MAGIC_NUM);
-               INT_SET(recp->h_cycle, ARCH_CONVERT, cycle);
-               INT_SET(recp->h_version, ARCH_CONVERT, 1);
-               INT_ZERO(recp->h_len, ARCH_CONVERT);
-               ASSIGN_ANY_LSN(recp->h_lsn, cycle, curr_block, ARCH_CONVERT);
-               ASSIGN_ANY_LSN(recp->h_tail_lsn, tail_cycle, tail_block, ARCH_CONVERT);
-               INT_ZERO(recp->h_chksum, ARCH_CONVERT);
-               INT_ZERO(recp->h_prev_block, ARCH_CONVERT);     /* unused */
-               INT_ZERO(recp->h_num_logops, ARCH_CONVERT);
-               
-               curr_block++;
-               recp = (xlog_rec_header_t*)(((char *)recp) + BBSIZE);
-       }
+        if (!(bp = xlog_get_bp(blocks, log->l_mp))) {
+                if (!(bp = xlog_get_bp(1, log->l_mp)))
+                       return -ENOMEM;
+                smallmem = 1;
+        }
+        
+        buf = XFS_BUF_PTR(bp);
+       recp = (xlog_rec_header_t*)buf;
 
-       error = xlog_bwrite(log, start_block, blocks, bp);
+        memset(buf, 0, BBSIZE);
+        INT_SET(recp->h_magicno, ARCH_CONVERT, XLOG_HEADER_MAGIC_NUM);
+        INT_SET(recp->h_cycle, ARCH_CONVERT, cycle);
+        INT_SET(recp->h_version, ARCH_CONVERT, 1);
+        INT_ZERO(recp->h_len, ARCH_CONVERT);
+        ASSIGN_ANY_LSN(recp->h_tail_lsn, tail_cycle, tail_block, ARCH_CONVERT);
+        INT_ZERO(recp->h_chksum, ARCH_CONVERT);
+        INT_ZERO(recp->h_prev_block, ARCH_CONVERT);    /* unused */
+        INT_ZERO(recp->h_num_logops, ARCH_CONVERT);
+        
+        if (smallmem) {
+                /* for small mem, we keep modifying the block and writing */
+               for (i = start_block; i < start_block + blocks; i++) {
+                       ASSIGN_ANY_LSN(recp->h_lsn, cycle, i, ARCH_CONVERT);
+                       if ((error = xlog_bwrite(log, i, 1, bp)))
+                               break;
+               }
+        } else {
+               ASSIGN_ANY_LSN(recp->h_lsn, cycle, start_block, ARCH_CONVERT);
+               for (i = start_block+1; i < start_block + blocks; i++) {
+                        /* with plenty of memory, we duplicate the block
+                         * right through the buffer and modify each entry
+                         */
+                        buf += BBSIZE;
+                       recp = (xlog_rec_header_t*)buf;
+                        memcpy(buf, XFS_BUF_PTR(bp), BBSIZE);
+                       ASSIGN_ANY_LSN(recp->h_lsn, cycle, i, ARCH_CONVERT);
+                }
+                /* then write the whole lot out at once */
+               error = xlog_bwrite(log, start_block, blocks, bp);
+        }
+       xlog_put_bp(bp);
 
        return error;
 }
@@ -1072,7 +1113,6 @@
        int                     tail_distance;
        int                     max_distance;
        int                     distance;
-       xfs_buf_t               *bp;
        int                     error;
 
        tail_cycle = CYCLE_LSN(tail_lsn, ARCH_NOCONVERT);
@@ -1127,9 +1167,6 @@
         * for no reason.
         */
        max_distance = MIN(max_distance, tail_distance);
-       bp = xlog_get_bp(max_distance,log->l_mp);
-        if (!bp)
-            return -ENOMEM;
        
        if ((head_block + max_distance) <= log->l_logBBsize) {
                /*
@@ -1141,11 +1178,7 @@
                 */
                error = xlog_write_log_records(log, (head_cycle - 1),
                                head_block, max_distance, tail_cycle,
-                               tail_block, bp);
-               if (error) {
-                       xlog_put_bp(bp);
-                       return error;
-               }
+                               tail_block);
        } else {
                /*
                 * We need to wrap around the end of the physical log in
@@ -1157,11 +1190,10 @@
                distance = log->l_logBBsize - head_block;
                error = xlog_write_log_records(log, (head_cycle - 1),
                                head_block, distance, tail_cycle,
-                               tail_block, bp);
-               if (error) {
-                       xlog_put_bp(bp);
+                               tail_block);
+
+               if (error)
                        return error;
-               }
 
                /*
                 * Now write the blocks at the start of the physical log.
@@ -1173,15 +1205,9 @@
                 */
                distance = max_distance - (log->l_logBBsize - head_block);
                error = xlog_write_log_records(log, head_cycle, 0, distance,
-                               tail_cycle, tail_block, bp);
-               if (error) {
-                       xlog_put_bp(bp);
-                       return error;
-               }
+                               tail_cycle, tail_block);
        }
 
-       xlog_put_bp(bp);
-
        return 0;
 }
 #endif /* SIM */
@@ -3135,11 +3161,11 @@
     error = 0;
     hbp = xlog_get_bp(1,log->l_mp);
     if (!hbp)
-        return -ENOMEM;
+       return -ENOMEM;
     dbp = xlog_get_bp(BTOBB(XLOG_MAX_RECORD_BSIZE),log->l_mp);
     if (!dbp) {
-        xlog_put_bp(hbp);
-        return -ENOMEM;
+       xlog_put_bp(hbp);
+       return -ENOMEM;
     }
     bzero(rhash, sizeof(rhash));
     if (tail_blk <= head_blk) {
@@ -3175,7 +3201,7 @@
                goto bread_err;
            rhead = (xlog_rec_header_t *)XFS_BUF_PTR(hbp);
            ASSERT(INT_GET(rhead->h_magicno, ARCH_CONVERT) == XLOG_HEADER_MAGIC_NUM);
-           ASSERT(BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT) <= INT_MAX));
+           ASSERT(BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT) <= INT_MAX));            
            bblks = (int) BTOBB(INT_GET(rhead->h_len, ARCH_CONVERT));
 
            /* LR body must have data or it wouldn't have been written */

From owner-linux-xfs@oss.sgi.com Thu Oct 12 12:31:50 2000
Received:  by oss.sgi.com id <S42224AbQJLTbb>;
	Thu, 12 Oct 2000 12:31:31 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:7699 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42195AbQJLTbI>; Thu, 12 Oct 2000 12:31:08 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA07276; Thu, 12 Oct 2000 12:37:37 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id MAA93300;
	Thu, 12 Oct 2000 12:30:25 -0700 (PDT)
Date:   Thu, 12 Oct 2000 12:30:25 -0700 (PDT)
Message-Id: <200010121930.MAA93300@info.engr.sgi.com>
X-Pv-Incident: 804570 
webPV:  fzr600.americas.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (coreym@sgi.com)
Subject: ADD 804570 - The elevator bug
To:     nb@sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804570

 Status : open                         Priority : 3                         
 Assigned Engineer : nb                Submitter : coreym                   
*Modified User : coreym               *Modified User Domain : sgi.com       
*Description :
I ran rwtest on a xfs-linux filesystem on the machine permit:

rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &

This caused df, ls -l, fdisk, and top all to hang.

Permit is running Redhat 6.2 with a 2.4.0-test5 kernel

==========================
ADDITIONAL INFORMATION (ADD)
From: coreym@sgi.com (BugWorks)
Date: Oct 12 2000 12:30:25PM
==========================

Once the elevator bug is found, any additional rwtests (I/O) run
to the file system also hang.

From owner-linux-xfs@oss.sgi.com Thu Oct 12 22:29:50 2000
Received:  by oss.sgi.com id <S553751AbQJMF3k>;
	Thu, 12 Oct 2000 22:29:40 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:39445 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553715AbQJMF33>;
	Thu, 12 Oct 2000 22:29:29 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA13678
	for <linux-xfs@oss.sgi.com>; Thu, 12 Oct 2000 22:21:42 -0700 (PDT)
	mail_from (tes@sherman.melbourne.sgi.com)
Received: (from tes@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA24732
	for linux-xfs@oss.sgi.com; Fri, 13 Oct 2000 16:27:25 +1100
Date:   Fri, 13 Oct 2000 16:27:25 +1100
From:   Tim Shimmin <tes@sherman.melbourne.sgi.com>
Message-Id: <200010130527.QAA24732@sherman.melbourne.sgi.com>
Subject: TAKE - xfsrestore
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Fixes a bug in xfsrestore caused by different status returned in the
Linux scsi tape driver versus the IRIX scsi tape driver.
A scary error msg should no longer occur when doing multiple 
(sequential) tape restores from a Linux scsi tape drive. 

--Tim
 
Date:  Thu Oct 12 22:22:07 PDT 2000
Workarea:  sherman.melbourne.sgi.com:/hosts/snort/build4/tes/slinx-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76140a
cmd/xfs/dump/common/drive_scsitape.c - 1.27
	- Fixes xfsrestore for reading tapes on Linux when one gets to the
	  end of the tape (EOT). Prior to this fix, one would get a worrying
	  error message.  In the scsi tape driver on Linux, coming to
	  the end of the tape when reading is signified by <EOF,EOD> whereas
	  on IRIX one gets early warning (EW) status. Thus an extra condition
	  has been added for this case.  Also a comment of a table of expected status's 
	  for reaching the normal end of the dump (at EOD) and reaching premature
	  end, when one runs out of tape (at EOT), has been added for the Linux
	  case and IRIX case (needed for rmt to IRIX).



From owner-linux-xfs@oss.sgi.com Fri Oct 13 03:46:41 2000
Received:  by oss.sgi.com id <S553768AbQJMKqV>;
	Fri, 13 Oct 2000 03:46:21 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:58705 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553759AbQJMKqB>;
	Fri, 13 Oct 2000 03:46:01 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id DAA21553; Fri, 13 Oct 2000 03:38:14 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id DAA91198;
	Fri, 13 Oct 2000 03:45:59 -0700 (PDT)
Date:   Fri, 13 Oct 2000 03:45:59 -0700 (PDT)
Message-Id: <200010131045.DAA91198@info.engr.sgi.com>
X-Pv-Incident: 795642 
webPV:  192.82.201.103 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (lord@sgi.com)
Subject: CLOSE 795642 - remount -o remount,ro doesn't leave FS consistent
To:     cattelan@engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=795642

*Status : closed                       Priority : 3                         
 Assigned Engineer : cattelan          Submitter : dxm                      
 Opened Date : 07/06/00               *Closed Date : 10/13/00               
*Fixed By : lord                      *Fixed By Domain : sgi.com            
*Modified Date : 10/13/00             *Modified User : lord                 
*Modified User Domain : sgi.com       *Fix Description :
From: steve lord <lord@sgi.com> (PARTIAL)
Date: Sep 14 2000 07:00:04AM
[pvnews version: 1.71]
----------------------------


The remount readonly code path needs to go through sync twice. Unlinked inodes
have two phases of work to go through before they are clean on disk. These
are both handled via sync, and will not be handled in the same pass.


.....


==========================
ADDITIONAL INFORMATION (CLOSE)
From: lord@sgi.com (BugWorks)
Date: Oct 13 2000 03:45:58AM
==========================

I think this is long since fixed - a little slow maybe, but fixed.

From owner-linux-xfs@oss.sgi.com Fri Oct 13 04:52:31 2000
Received:  by oss.sgi.com id <S553764AbQJMLwW>;
	Fri, 13 Oct 2000 04:52:22 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10575 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553757AbQJMLwC>; Fri, 13 Oct 2000 04:52:02 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id EAA06120
	for <linux-xfs@oss.sgi.com>; Fri, 13 Oct 2000 04:59:11 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id GAA7282277 for <linux-xfs@oss.sgi.com>; Fri, 13 Oct 2000 06:50:44 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id GAA53519 for <linux-xfs@oss.sgi.com>; Fri, 13 Oct 2000 06:50:44 -0500 (CDT)
Received: (from lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) id GAA09066
	for linux-xfs@oss.sgi.com; Fri, 13 Oct 2000 06:50:17 -0500
Date:   Fri, 13 Oct 2000 06:50:17 -0500
From:   Steve Lord <lord@sgi.com>
Message-Id: <200010131150.GAA09066@jen.americas.sgi.com>
Subject: TAKE - more linvfs layer cleanup
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Check in Daniel's rewrite of linvfs_bmap which does not need
to look inside an xfs inode directly.

Date:  Fri Oct 13 04:49:46 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76144a
linux/fs/xfs/linux/xfs_iops.c - 1.75
	- Make linvfs_bmap function without knowledge of xfs internals.



From owner-linux-xfs@oss.sgi.com Fri Oct 13 09:01:41 2000
Received:  by oss.sgi.com id <S553788AbQJMQBb>;
	Fri, 13 Oct 2000 09:01:31 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:30997 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553785AbQJMQBW>;
	Fri, 13 Oct 2000 09:01:22 -0700
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA28829; Fri, 13 Oct 2000 08:53:36 -0700 (PDT)
	mail_from (pv@feature.engr.sgi.com)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA27227; Fri, 13 Oct 2000 09:00:04 -0700 (PDT)
Date:   Fri, 13 Oct 2000 09:00:04 -0700 (PDT)
Message-Id: <200010131600.JAA27227@feature.engr.sgi.com>
X-Pv-Incident: 804398 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (lord@sgi.com)
Subject: TAKE 804398 - XFS hits BUG call in pagebuf_read_full_page
To:     cattelan@cthulhu.engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

 Submitter : cattelan                 *Status : closed                      
 Assigned Engineer : cattelan         *Fixed By : lord                      
*Fixed By Domain : sgi.com            *Closed Date : 10/13/00               
 Priority : 2                         *Modified Date : 10/13/00             
*Modified User : lord                 *Modified User Domain : sgi.com       
*Fix Description :
From: steve lord <lord@sgi.com> (TAKE)
Date: Oct 13 2000 09:00:03AM
[pvnews version: 1.71]
----------------------------

This was the cause of panics during shutdown for systems with
an XFS root disk.

Date:  Fri Oct 13 08:56:54 PDT 2000
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76152a
linux/mm/filemap.c - 1.55
	- Do not call convert page on the partial page in truncate_inode_pages,
	  this causes us to clear the delalloc bit and never flush the page to disk.
Description :
The problem appears to be a page that was orginaly delay alloc
(the underlying disk blocks cam back as zero) but has either
been reused or its state has been cleared.

I don't have all the kbd output... I;ll add to it as
I capture more traces.

[0]kdb> bt
    EBP       EIP         Function(args)
0xc4c13e58 0xc880c914 [pagebuf]pagebuf_read_full_page+0x198 (0xc49eeb60, 0xc11939ac)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: russell cattelan <cattelan@thebarn.com>
Date: Oct 10 2000 12:25:10PM
[pvnews version: 1.71]
==========================
"ananth@engr.sgi.com" wrote:

> View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804398
>
>  Status : open                         Priority : 2
>  Assigned Engineer : cattelan          Submitter : cattelan
> *Modified User : ananth               *Modified User Domain : engr
> *Description :
> The problem appears to be a page that was orginaly delay alloc
> (the underlying disk blocks cam back as zero) but has either
> been reused or its state has been cleared.
>
> I don't have all the kbd output... I;ll add to it as
> I capture more traces.
>
> [0]kdb> bt
>     EBP       EIP         Function(args)
> 0xc4c13e58 0xc880c914 [pagebuf]pagebuf_read_full_page+0x198 (0xc49eeb60, 0xc11939ac)
>
> .....
>
> ==========================
> ADDITIONAL INFORMATION (ADD)
> From: ananth@engr (BugWorks)
> Date: Oct 10 2000 12:11:51PM
> ==========================
>
> Couple of quick suggestions: Can you please
> dump out the page struct (both by using the "page"
> command & as raw memory) and the "map" in
> page_buf_read_full_page ... you can use "pbmap"
> kdb command for the map.

that is what  "I don't have all the kbd output... I;ll add to it as
I capture more traces"  means

I didn't capture all that
kdb crashed and I was forced to reboot.
The points of interest though
page flags: PG_locked

xextlist showed the extent to be delay alloc.

>
>
> thanks,
>
> ananth.

From owner-linux-xfs@oss.sgi.com Fri Oct 13 13:52:45 2000
Received:  by oss.sgi.com id <S553805AbQJMUwf>;
	Fri, 13 Oct 2000 13:52:35 -0700
Received: from tux.mkp.net ([130.225.60.11]:20492 "EHLO tux.mkp.net")
	by oss.sgi.com with ESMTP id <S553655AbQJMUwQ>;
	Fri, 13 Oct 2000 13:52:16 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 13kBgx-0006S3-00; Fri, 13 Oct 2000 22:44:36 +0200
Received: (from mkp@localhost)
	by jaguar.mkp.net (8.9.3/8.9.3) id IAA01472;
	Thu, 12 Oct 2000 08:43:23 -0400
X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f
To:     Klaus Strebel <stb@ep-ag.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: LVM brocken
References: <39E59C9B.68DEE06B@ep-ag.com>
From:   "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date:   12 Oct 2000 08:43:21 -0400
In-Reply-To: Klaus Strebel's message of "Thu, 12 Oct 2000 13:12:27 +0200"
Message-ID: <yq1em1ms00m.fsf@jaguar.mkp.net>
Lines:  19
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
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

>>>>> "Klaus" == Klaus Strebel <stb@ep-ag.com> writes:

Klaus> i just pulled out an actual source-tree for linux-2.4-xfs (hm,
Klaus> about 10 MEST), built it and found a problem with lvm. Any
Klaus> filesystem on a logical volumn can't be mounted - superblocks
Klaus> cannot be read (for ext2, reiserfs, xfs ;-). Probably a problem
Klaus> with ll_rw_block (can't track this down, rm'ed my sources from
Klaus> 10/10/2000 that worked so far, but couldnd umount xfs :-( ).

Correct.  The changes to ll_rw_block.c introduced between test5 and
test8 causes LVM to fail.

We're working on this...

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.


From owner-linux-xfs@oss.sgi.com Sat Oct 14 09:23:34 2000
Received:  by oss.sgi.com id <S553846AbQJNQXY>;
	Sat, 14 Oct 2000 09:23:24 -0700
Received: from [212.93.138.220] ([212.93.138.220]:23308 "EHLO
        server.export2000.ro") by oss.sgi.com with ESMTP id <S553839AbQJNQXO>;
	Sat, 14 Oct 2000 09:23:14 -0700
Received: from cosmin (cosmin.export2000.ro [192.168.0.10])
	by server.export2000.ro (8.9.3/8.9.3) with SMTP id TAA06074
	for linux-xfs@oss.sgi.com; Sat, 14 Oct 2000 19:59:14 +0300
Date:   Sat, 14 Oct 2000 19:59:14 +0300
From:   mc5@export2000.ro
To:     linux-xfs@oss.sgi.com
Subject: Romanian Business Opportunity
Message-Id: <eaep.3.0.reg.CorMKN.36813.8085375@mail.export2000.ro>
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


To:   linux-xfs@oss.sgi.com
Attn: Marketing Department
From: S.C. SPICUL S.A. - Bucharest
Ref.: Romanian Business Opportunity

------------------------------------------------------------------------
                 Our anti-spamming company policy:
                      NEVER BOTHER YOU AGAIN

           To remove your E-mail address from the present
           contact list JUST DO NOT REPLY to this message.

 If you receive this message by mistake and/or you are not interested
   in the following brief presentation, please accept our apologies.

This is a world-wide promotion campaign. The selected E-mail addresses
are extracted only FROM THE COMMERCIAL WEBSITES of the targeted markets.
------------------------------------------------------------------------

We would like to offer you for consideration our brief presentation.
         We are looking for a marketplace in your country.

             To communicate with us please reply using
         the plain text format in the body of the message

             >>> mentioning your Specific Inquiry <<<

              and your detailed contact information:

>>> company name, address, phone & fax numbers, contact person. <<<

     Simple replies and advertisements will not be considered.
               We do not open any PC applications.

If you answer to this message, we will contact you every 3 months in
order to update our partner service database. Thank you for your time.

Best regards,
 
SPICUL Staff


                        EXPORT PRESENTATION

S.C. SPICUL S.A. is one of the most important producers from Romania
in milling and bakery field, with an old tradition and a high
professionalism.

Following the investment program between 1997-1999, S.C. SPICUL S.A.
acquired modern equipment, obtaining products of superior quality.

Thus: grain processing is made by a German production line - BUHLER, with
a capacity of 220 to./24h, pastas lines are Italian - PAVAN, with a 
capacity of 12 to/24h., their quality being appreciated on the Lebanese 
market and the biscuits line POLIN with a capacity of 2.5 to/24h.
is producing miscellaneous shapes of sugary biscuits and over 90 shapes
of fancy cookies.

Our present offer includes:

Product           Weight[kg]  Packing type                        Price/ton
                                                                  [USD]

"Eugenia Altfel"  0.032       BOPP foil, transparent and printed  1005.26
Biscuits          1.000       Printed cardboard box               1151.57
with cacao cream  1.920       Printed cardboard box               1042.14
                  9.570       Not printed cardboard box           908.67

"Eugenia Altfel"  0.032       BOPP foil, transparent and printed  1005.26
Biscuits          1.000       Printed cardboard box               1151.57
with vanilla      1.920       Printed cardboard box               1042.14
cream             9.570       Not printed cardboard box           908.67

"Eugenia Altfel"  0.032       BOPP foil, transparent and printed  1005.26
Biscuits          1.000       Printed cardboard box               1151.57
with fruit cream  1.920       Printed cardboard box               1042.14
(raspberry, lemon,9.570       Not printed cardboard box           908.67
orange)

"Octogon"         0.200       Pealy foil bag                      878.42
Biscuits          1.000       Printed cardboard box               1023.64
                  2.000       Printed cardboard box               973.97
                  Bulk        Not printed cardboard box           767.94

"Octogon"
Biscuits for      2.000       Printed cardboard box               975.88
Lent and for
Advent

"Spicul"          Bulk        Not printed cardboard box           725.55
Biscuits

Medium pastas     0.200       BOPP transparent bag in
                              polyethylene sack                   506.03
                  0.350       BOPP transparent bag in
                              polyethylene sack                   460.42
                  Bulk        Polyethylene sack                   352.63

Short pastas      0.200       BOPP transparent bag in
                              polyethylene sack                   455.10
                  0.350       BOPP transparent bag in
                              polyethylene sack                   433.30
                  Bulk 8/10 kg.Polyethylene sack                  338.35

Wheat flour,      50.000      Raffia sack                         227.79
ash.0.48%         2.000       Printed paper bag                   239.02
                  1.000       Printed paper bag                   281.77

Wheat flour,      50.000      Raffia sack                         210.64
ash.0.65%         5.000       Printed paper bag                   214.29
                  1.000       Printed paper bag                   266.66
                  Bulk                                            205.50

Wheat bran for    30.000      Raffia sack                         107.91
human consumption 25.000      Polyethylene bag                    109.74
                  1           Polyethylene bag                    142.91


From owner-linux-xfs@oss.sgi.com Sat Oct 14 15:56:50 2000
Received:  by oss.sgi.com id <S553856AbQJNW4k>;
	Sat, 14 Oct 2000 15:56:40 -0700
Received: from [12.128.7.23] ([12.128.7.23]:6419 "EHLO mail.argosmail.com.ar")
	by oss.sgi.com with ESMTP id <S553853AbQJNW4e>;
	Sat, 14 Oct 2000 15:56:34 -0700
Received: from 12.128.7.23 [63.21.182.102] by mail.argosmail.com.ar
  (SMTPD32-5.05) id AC8D5BA40100; Sat, 14 Oct 2000 19:55:09 -0300
Date:   Sat, 14 Oct 00 17:46:32 EST
From:   mppm2@parsmail.com
To:     hslye@fd4ghg.com
Subject: Work From Home!! Change you Life Now!!
Message-Id: <200010141955155.SM00135@12.128.7.23>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Work from Home--This is not a Gimmick!!

 Are you in debt, do you need a part-time job to help supplement your
income? This may be the janswer you have been looking for.

 I was in credit card debt and had $25,000 dollars to pay off.  I had a
good job, but I was strapped every month.  I was e-mailed with an opportunity
to make money and I took the chance and have now paid off half of my debt!!
 This endeavor is entirely legal, and there are no strings attached.  If
you are willing to put in the effort, for a minimum cost, there is no reason
you cannot make money.

 I put in an hour of week each day and began reaping the benefits within a
week.  If you are diligent and determined you can change your life.

 I purchased 4 separate reports at $5 each for a total of $20.  I was wary
of buying anything from the internet and was a skeptic, but I thought I
spend almost that amount at the movie theater or on a hard-back book.  I took a
chance and was not disappointed with the results.  These reports contain
strategies to start and maintain a home business.

 Report #1--The Insider's Guide to Advertising for Free on the Internet.
 Report#2--The Insider's Guide to Sending Bulk E-Mail on the Internet.
 Report #3--The Secrets to Multi-Level Marketing on the Internet.
 Report #4--How to Become a Millionaire Utilizing the Power of Multi-Level
 Marketing and the Internet.

 You are buying a product.  A product that you can then use and sell over
the Internet.  I began by advertising in free space on the Web.  There are
hundreds of sites that host free classifieds!!  If you sit diligently,
you can place fifty ads in one sitting.  I then sat and e-mailed by using the
tips in report #1.  The world is your oyster.  Believe, there are people
out there who are interested in making money--I am not the only one.  If you
are willing to put in effort, you can reap the rewards as well!!

Send $20 cash wrapped in an envelope to:
 Anastasia Lerma
 20 Egerton Road
 Arlington, MA 02474

 BE SURE TO SEND YOUR E-MAIL ADDRESS

 Upon receipt of payment, you will immediately receive all four reports
and you can begin your new business.  I will also be available to answer any
question and help you get off the ground.

/////////////////////////////////////////////////////////////////
Remove at mppm2@boardermail.com
/////////////////////////////////////////////////////////////////









From owner-linux-xfs@oss.sgi.com Sun Oct 15 22:43:47 2000
Received:  by oss.sgi.com id <S553733AbQJPFnh>;
	Sun, 15 Oct 2000 22:43:37 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:64027 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553645AbQJPFnY>;
	Sun, 15 Oct 2000 22:43:24 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA07878
	for <linux-xfs@oss.sgi.com>; Sun, 15 Oct 2000 22:35:36 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA17547 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 16 Oct 2000 16:40:51 +1100
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id QAA25336 for <linux-xfs@oss.sgi.com>; Mon, 16 Oct 2000 16:40:49 +1100 (EST)
Message-Id: <200010160540.QAA25336@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
Subject: IRIX clean-ups
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 16 Oct 2000 16:40:49 +1100
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I'd like to do some global changes to the tree. Primarily, I'd
like to switch XFS over to using the standard linux fixed sized
types.

	__int8_t				-> 	__s8
	__uint8_t				->	__u8
	__int16_t				-> 	__s16
	__uint16_t	&	u_int16_t	->	__u16
	__int32_t				-> 	__s32
	__uint32_t	&	u_int32_t	->	__u32
	__int64_t				-> 	__s64
	__uint64_t				->	__u64

	ulong_t					->	unsigned long
	uchar_t					->	unsigned char

And clean up some aliases:

	linux_off_t				-> 	__kernel_off_t
	linux_ino_t				->	__kernel_ino_t

Also, I'd like to replace the bzero, bcopy etc calls with
their libc style equivalents:

	bzero(p,s) 				->	memset((p), 0, (s))
	bcopy(s,d,n) 				->	memcpy((d),(s),(n))
	bcmp(s1,s2,l) 				->	memcmp(s1,s2,l)
	ovbcopy(from,to,count)         		->	memmove(to,from,count)

This is of course all done with header magic now and it'd be 
nice to lose it.

Objections &&|| comments?

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Mon Oct 16 00:31:57 2000
Received:  by oss.sgi.com id <S553777AbQJPHbr>;
	Mon, 16 Oct 2000 00:31:47 -0700
Received: from HSE-Kitchener-ppp84733.sympatico.ca ([216.209.97.48]:5117 "EHLO
        KernelPatches.ORG") by oss.sgi.com with ESMTP id <S553769AbQJPHbn>;
	Mon, 16 Oct 2000 00:31:43 -0700
Received: (from lethal@localhost)
	by KernelPatches.ORG (8.9.3/8.9.3) id DAA08630
	for linux-xfs@oss.sgi.com; Mon, 16 Oct 2000 03:31:38 -0400
Date:   Mon, 16 Oct 2000 03:31:38 -0400
From:   Paul Mundt <lethal@chaoticdreams.org>
To:     linux-xfs@oss.sgi.com
Subject: patches
Message-ID: <20001016033138.A8525@chaoticdreams.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hello,

Is anyone currently archiving XFS patches against the linux
kernel? I would like to set up a mirror but as far as I can
tell all that is being posted on the site are links to the
cvs repository.

Also, are there any historic patches available? Beta work
against 2.2 for instance?

-- 
,----------------------------------------------------,
|       Paul Mundt | Email: lethal@chaoticdreams.org |
|   Head Developer | URL:   http://www.u4x.org       |
| Head of Security | URL:   http://www.stampede.org  |
`----------------------------------------------------'


From owner-linux-xfs@oss.sgi.com Mon Oct 16 03:55:08 2000
Received:  by oss.sgi.com id <S553780AbQJPKy6>;
	Mon, 16 Oct 2000 03:54:58 -0700
Received: from uscmail.usc.es ([193.144.75.8]:16339 "EHLO uscmail.usc.es")
	by oss.sgi.com with ESMTP id <S553774AbQJPKye>;
	Mon, 16 Oct 2000 03:54:34 -0700
Received: from qogolem (qogolem.usc.es [193.144.74.235])
	by uscmail.usc.es (8.9.1/8.9.1) with SMTP id MAA22696
	for <linux-xfs@oss.sgi.com>; Mon, 16 Oct 2000 12:54:23 +0200 (MET DST)
Message-ID: <000901c0375e$da674b70$eb4a90c1@qogolem.usc.es>
From:   "Armando Navarro" <qoajnv@usc.es>
To:     <linux-xfs@oss.sgi.com>
Subject: xfs_repair problem
Date:   Mon, 16 Oct 2000 12:50:08 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0006_01C0376F.9D27C260"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C0376F.9D27C260
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Sir:
I have installed the beta release of xfs for linux as a patch on =
2.4.0-test5 kernel. I have compiled succesfully the kernel and the xfs =
tools.
I tried to read an old IRIX xfs disk. The problem is that by a mistake =
the disk was signed by NT, so the first sector is corrupted.
I tried to use the xfs_repair utility.  A bad magic number in first =
superblock is found, so the program tried to find a secondary =
superblock. xfs_repair says that a candidate secondary superblock was =
found but it could not verify it.

Is there any possibility to repair the disk with xfs_repair?

Thanks in Advance
Armando Navarro=20
Facultade de quimica
Departamento de quimica Organica
Universidade de Santiago de Compostela



------=_NextPart_000_0006_01C0376F.9D27C260
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Dear Sir:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>I have installed the beta release of =
xfs for=20
linux as a patch on 2.4.0-test5 kernel. I have compiled succesfully the =
kernel=20
and the xfs tools.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>I tried to read an old IRIX xfs =
disk. The=20
problem is that by a mistake the disk was signed by NT, so the first =
sector is=20
corrupted.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>I tried to use the xfs_repair =
utility.&nbsp; A=20
bad magic number in first superblock is found, so the program tried to =
find a=20
secondary superblock. xfs_repair says that a candidate secondary =
superblock was=20
found but it could not verify it.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Is there any possibility to repair =
the disk with=20
xfs_repair?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Thanks in Advance</FONT></DIV>
<DIV><FONT size=3D2>Armando Navarro </FONT></DIV>
<DIV><FONT size=3D2>Facultade de quimica</FONT></DIV>
<DIV><FONT size=3D2>Departamento de quimica Organica</FONT></DIV>
<DIV><FONT size=3D2>Universidade de Santiago de Compostela</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0006_01C0376F.9D27C260--


From owner-linux-xfs@oss.sgi.com Mon Oct 16 09:35:32 2000
Received:  by oss.sgi.com id <S553787AbQJPQfM>;
	Mon, 16 Oct 2000 09:35:12 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:50208 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553790AbQJPQeq>;
	Mon, 16 Oct 2000 09:34:46 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA23343
	for <linux-xfs@oss.sgi.com>; Mon, 16 Oct 2000 09:26:59 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA7303809; Mon, 16 Oct 2000 11:32:09 -0500 (CDT)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id LAA98571; Mon, 16 Oct 2000 11:32:09 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e9GGW8Q10130;
	Mon, 16 Oct 2000 11:32:08 -0500
Message-ID: <39EB2D84.1F13D99@thebarn.com>
Date:   Mon, 16 Oct 2000 11:32:05 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-whipme5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: IRIX clean-ups
References: <200010160540.QAA25336@clouds.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Daniel Moore wrote:

> I'd like to do some global changes to the tree. Primarily, I'd
> like to switch XFS over to using the standard linux fixed sized
> types.

The intrinsic types should be if any thing: posix compliant.
With other ports of  CXFS starting up anything we do in the
linux XFS tree should remain as portable as possible.
Hopefully this will allow future ports to leverage off the work
we have done.  Also to many linux'ism may discourage any
external developers from doing a new platform.

>
>
>         __int8_t                                ->      __s8
>         __uint8_t                               ->      __u8
>         __int16_t                               ->      __s16
>         __uint16_t      &       u_int16_t       ->      __u16
>         __int32_t                               ->      __s32
>         __uint32_t      &       u_int32_t       ->      __u32
>         __int64_t                               ->      __s64
>         __uint64_t                              ->      __u64
>
>         ulong_t                                 ->      unsigned long
>         uchar_t                                 ->      unsigned char
>
> And clean up some aliases:
>
>         linux_off_t                             ->      __kernel_off_t
>         linux_ino_t                             ->      __kernel_ino_t

I would really really  prefer these not be touched just yet.
We spent a bit of time discussing these types.
Anything internal to XFS use xfs_<type>
on the linux side linux_<type>
This  was only applied to overlapping types eg off_t and ino_t
Also since the size of __kernel_<type> may not be fixed across all
architectures it was ruled out for inclusion in actual code.
When and if somebody does port X to architecture X the ino_t and
off_t may need some fiddling with.

The size of ino_t and off_t may be changed in linux at some point
soon. Putting off  changing these types may be a good idea, at least
until there is a direction set by the rest of the community.

>
>
> Also, I'd like to replace the bzero, bcopy etc calls with
> their libc style equivalents:
>
>         bzero(p,s)                              ->      memset((p), 0, (s))
>         bcopy(s,d,n)                            ->      memcpy((d),(s),(n))
>         bcmp(s1,s2,l)                           ->      memcmp(s1,s2,l)
>         ovbcopy(from,to,count)                  ->      memmove(to,from,count)
>
> This is of course all done with header magic now and it'd be
> nice to lose it.

The mem* functions are fairly standard... probably  wouldn't cause any
portability problems.

>
>
> Objections &&|| comments?

>
>
> -----------------------------------------------------
>  Daniel Moore                  dxm@sgi.com
>  R&D Software Engineer         Phone: +61-3-98348209
>  SGI Performance Tools Group   Fax:   +61-3-98132378
> -----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Mon Oct 16 09:40:02 2000
Received:  by oss.sgi.com id <S553794AbQJPQjm>;
	Mon, 16 Oct 2000 09:39:42 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:55074 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553792AbQJPQji>;
	Mon, 16 Oct 2000 09:39:38 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA24633
	for <linux-xfs@oss.sgi.com>; Mon, 16 Oct 2000 09:31:51 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA7302433; Mon, 16 Oct 2000 11:38:19 -0500 (CDT)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id LAA98973; Mon, 16 Oct 2000 11:38:19 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e9GGcJQ10157;
	Mon, 16 Oct 2000 11:38:19 -0500
Message-ID: <39EB2EFA.78FAAA3A@thebarn.com>
Date:   Mon, 16 Oct 2000 11:38:18 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-whipme5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Paul Mundt <lethal@chaoticdreams.org>
CC:     linux-xfs@oss.sgi.com
Subject: Re: patches
References: <20001016033138.A8525@chaoticdreams.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Paul Mundt wrote:

> Hello,
>
> Is anyone currently archiving XFS patches against the linux
> kernel? I would like to set up a mirror but as far as I can
> tell all that is being posted on the site are links to the
> cvs repository.

Are you looking for the ftp site?
ftp://oss.sgi.com/projects/xfs/download

Old patches have not been archived.. since they were just snap shots of
the CVS repository they can be recreated based on a particular date.

>
>
> Also, are there any historic patches available? Beta work
> against 2.2 for instance?

The complete source for the 2.2 work was never released due to
the encumbrance review not being done.

At this point everything has changed significantly from  2.2 stuff.
It wouldn't  do you any good.

>
>
> --
> ,----------------------------------------------------,
> |       Paul Mundt | Email: lethal@chaoticdreams.org |
> |   Head Developer | URL:   http://www.u4x.org       |
> | Head of Security | URL:   http://www.stampede.org  |
> `----------------------------------------------------'


From owner-linux-xfs@oss.sgi.com Mon Oct 16 15:59:36 2000
Received:  by oss.sgi.com id <S553695AbQJPW70>;
	Mon, 16 Oct 2000 15:59:26 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:37946 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553657AbQJPW7I>; Mon, 16 Oct 2000 15:59:08 -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 QAA06947
	for <linux-xfs@oss.sgi.com>; Mon, 16 Oct 2000 16:06:22 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA24672; Tue, 17 Oct 2000 09:57:49 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA71725; Tue, 17 Oct 2000 09:57:45 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10010170957.ZM72825@wobbly.melbourne.sgi.com>
Date:   Tue, 17 Oct 2000 09:57:43 -0400
In-Reply-To: "Armando Navarro" <qoajnv@usc.es>
        "xfs_repair problem" (Oct 16, 12:50pm)
References: <000901c0375e$da674b70$eb4a90c1@qogolem.usc.es>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     "Armando Navarro" <qoajnv@usc.es>
Subject: Re: xfs_repair problem
Cc:     linux-xfs@oss.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

Hi Armando,

On Oct 16, 12:50pm, Armando Navarro wrote:
> Subject: xfs_repair problem
> 
> Dear Sir:
> I have installed the beta release of xfs for linux as a
> patch on 2.4.0-test5 kernel. I have compiled succesfully
> the kernel and the xfs tools.  I tried to read an old IRIX
> xfs disk. The problem is that by a mistake the disk 
> was signed by NT, so the first sector is corrupted.

Unfortunately thats probably the worst possible place to
overwrite on an XFS filesystem.  xfs_repair can usually
recover it though, provided you have enough good secondary
superblocks (sounds like you don't though)...

> I tried to use the xfs_repair utility.  A bad magic number
> in first superblock is found, so the program tried to find
> a secondary superblock. xfs_repair says that a candidate
> secondary superblock was found but it could not verify it.
> 

Can you send the actual xfs_repair output?  It will help
with understanding exactly where repair is giving up.
I'm guessing its around line 741 of repair/sb.c - but
would want to know for sure.

> Is there any possibility to repair the disk with xfs_repair?
> 

_if_ the only thing that has been overwritten is the
primary superblock (first 512 bytes), _and_ we have
at least one other good secondary superblock, it should
be possible to recover.  If we cannot get xfs_repair to do
the recovery, but we know we have one good secondary SB,
then there is always xfs_db in expert mode... (i.e. "if
at first you don't succeed - use a bigger hammer"),
and then repair later once we've written as much of the
primary SB back as we can... this would be a non-trivial,
error-prone exercise though, so I wouldn't recommend it.

It would involve using gdb to break into repair to dump
the contents of the secondary SB when it finds one, then
using the xfs_db write command (expert mode) to reset each
field in the first superblock, and afterward running repair
again to see if it can stitch together the rest of the SB.

Its something you'd want to practice on an empty spare disk
first though, but in theory it should be possible -
# mkfs.xfs /dev/scratch
# dd if=/dev/zero of=/dev/scratch count=1 bs=512
# gdb xfs_repair
...break in "verify_sb"; run /dev/scratch; print sb
# xfs_db -x /dev/scratch
...sb 0, help write, write, write, write...
# xfs_repair /dev/scratch

... and if that works, and you really only overwrote the
first 512 bytes on your real filesystem, then xfs_repair
might be able to recover the rest on your real filesystem
too.

I'd consider that approach an absolute last resort though.

hope this helps.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Mon Oct 16 16:39:57 2000
Received:  by oss.sgi.com id <S553719AbQJPXjr>;
	Mon, 16 Oct 2000 16:39:47 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:54312 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553683AbQJPXjc>;
	Mon, 16 Oct 2000 16:39:32 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA09182
	for <linux-xfs@oss.sgi.com>; Mon, 16 Oct 2000 16:31:44 -0700 (PDT)
	mail_from (tes@boing.melbourne.sgi.com)
Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25064 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 17 Oct 2000 10:36:58 +1100
Received: (from tes@localhost) by boing.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA53883 for linux-xfs@oss.sgi.com; Tue, 17 Oct 2000 10:36:57 +1100 (EDT)
From:   tes@boing.melbourne.sgi.com (Timothy Shimmin)
Message-Id: <200010162336.KAA53883@boing.melbourne.sgi.com>
Subject: Re: IRIX clean-ups
To:     linux-xfs@oss.sgi.com
Date:   Tue, 17 Oct 2000 10:36:56 +1100 (EDT)
In-Reply-To: <39EB2D84.1F13D99@thebarn.com> from "Russell Cattelan" at Oct 16, 2000 11:32:05 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> > Also, I'd like to replace the bzero, bcopy etc calls with
> > their libc style equivalents:
> >
> >         bzero(p,s)                              ->      memset((p), 0, (s))
> >         bcopy(s,d,n)                            ->      memcpy((d),(s),(n))
> >         bcmp(s1,s2,l)                           ->      memcmp(s1,s2,l)
> >         ovbcopy(from,to,count)                  ->      memmove(to,from,count)
> >
> > This is of course all done with header magic now and it'd be
> > nice to lose it.
> 
> The mem* functions are fairly standard... probably  wouldn't cause any
> portability problems.
> 
The mem* functions are also part of POSIX (the b* functions aren't). 

--Tim

From owner-linux-xfs@oss.sgi.com Mon Oct 16 18:10:27 2000
Received:  by oss.sgi.com id <S553721AbQJQBKR>;
	Mon, 16 Oct 2000 18:10:17 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:4934 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553659AbQJQBJy>; Mon, 16 Oct 2000 18:09:54 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA04753
	for <linux-xfs@oss.sgi.com>; Mon, 16 Oct 2000 18:17:08 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA7281314 for <linux-xfs@oss.sgi.com>; Mon, 16 Oct 2000 20:08:37 -0500 (CDT)
Received: from laptop.americas.sgi.com (IDENT:root@[192.82.201.252]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id UAA93613 for <linux-xfs@oss.sgi.com>; Mon, 16 Oct 2000 20:08:34 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: by laptop.americas.sgi.com (8.11.0/SGI-client-1.6c) id e9H1I5U01328; Mon, 16 Oct 2000 20:18:05 -0500
Message-Id: <200010170118.e9H1I5U01328@laptop.americas.sgi.com>
Date:   Mon, 16 Oct 2000 20:18:05 -0500
Subject: TAKE - get loopfs and XFS to play together
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This has had very minimal testing, but I have build a loopfs device
on top of xfs and created both an ext2 filesystem and an xfs filesystem
within it.

There are almost certainly kinks to work out, but this gets things
off the ground with loopfs.

Date:  Mon Oct 16 18:05:45 PDT 2000
Workarea:  192.82.201.252:/usr/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76298a
linux/fs/xfs/linux/xfs_iops.c - 1.76
	- Add prepare_write and commit_write methods to xfs

linux/include/linux/page_buf.h - 1.66
	- Prototypes for pagebuf_prepare_write and pagebuf_commit_write

linux/fs/pagebuf/page_buf.c - 1.39
	- When passing a buffer to generic_make_request, make sure the lock bit
	  is set.

linux/fs/pagebuf/page_buf_io.c - 1.32
	- Implement pagebuf_commit_write and pagebuf_prepare_write



From owner-linux-xfs@oss.sgi.com Tue Oct 17 09:15:45 2000
Received:  by oss.sgi.com id <S553714AbQJQQPf>;
	Tue, 17 Oct 2000 09:15:35 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:63357 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553687AbQJQQPZ>; Tue, 17 Oct 2000 09:15:25 -0700
Received: from eric1.austin.sgi.com (root@eric1.austin.sgi.com [169.238.86.142]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA03703
	for <linux-xfs@oss.sgi.com>; Tue, 17 Oct 2000 09:22:41 -0700 (PDT)
	mail_from (root@eric1.austin.sgi.com)
Received: (from root@localhost)
	by eric1.austin.sgi.com (8.11.0/8.11.0) id e9HGF0K08067
	for linux-xfs@oss.sgi.com; Tue, 17 Oct 2000 11:15:00 -0500
Date:   Tue, 17 Oct 2000 11:15:00 -0500
From:   root <root@eric1.austin.sgi.com>
Message-Id: <200010171615.e9HGF0K08067@eric1.austin.sgi.com>
Subject: TAKE - 
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Tue Oct 17 09:13:13 PDT 2000
Workarea:  eric1.austin.sgi.com:/home/eric/xfs/workarea-clean

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76320a
cmd/xfs/stress/common.rc - 1.37
	- _is_block_dev() modified to work w/ stat output from RH7 as well as RH6



From owner-linux-xfs@oss.sgi.com Tue Oct 17 16:49:52 2000
Received:  by oss.sgi.com id <S553675AbQJQXtm>;
	Tue, 17 Oct 2000 16:49:42 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57656 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553665AbQJQXtY>; Tue, 17 Oct 2000 16:49:24 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA00370
	for <linux-xfs@oss.sgi.com>; Tue, 17 Oct 2000 16:56:39 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA79535
	for linux-xfs@oss.sgi.com; Wed, 18 Oct 2000 10:46:49 +1100 (EST)
Date:   Wed, 18 Oct 2000 10:46:49 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010172346.KAA79535@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - quota
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:76373a
Date:  Tue Oct 17 16:45:36 PDT 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/quota/Changelog - 1.2
cmd/quota/README.xfs - 1.2
cmd/quota/quota.1 - 1.2
cmd/quota/quota.c - 1.2
cmd/quota/quotaops.c - 1.2
cmd/quota/repquota.c - 1.2
cmd/quota/setquota.8 - 1.2
cmd/quota/setquota.c - 1.2
cmd/quota/warnquota.c - 1.2
cmd/quota/warnquota.conf - 1.1
	- merge changes from Marco's 2.00pre11 source.


From owner-linux-xfs@oss.sgi.com Tue Oct 17 23:33:54 2000
Received:  by oss.sgi.com id <S553705AbQJRGdo>;
	Tue, 17 Oct 2000 23:33:44 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:58216 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553699AbQJRGda>; Tue, 17 Oct 2000 23:33:30 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA09987
	for <linux-xfs@oss.sgi.com>; Tue, 17 Oct 2000 23:40:46 -0700 (PDT)
	mail_from (tes@sherman.melbourne.sgi.com)
Received: (from tes@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id RAA30786
	for linux-xfs@oss.sgi.com; Wed, 18 Oct 2000 17:32:27 +1100
Date:   Wed, 18 Oct 2000 17:32:27 +1100
From:   Tim Shimmin <tes@sherman.melbourne.sgi.com>
Message-Id: <200010180632.RAA30786@sherman.melbourne.sgi.com>
Subject: TAKE - xfsrestore/xfsdump/xfsinvutil
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Fixes for xfsrestore to allow it to handle large tape blocks 
(up to 2Mb) which are bigger than the default buffer size of 1 Mb.
The point of this is to make it easier to restore IRIX dumps
onto Linux - so won't explicitly need to set buffer size (-b).

This problem normally causes ENOMEM which wasn't handled very well.
Note: 1Mb buffer has greater chance of working with the 
Linux scsi tape driver default config which is why we chose it
as the default.
- 2Mb often causes EOVERFLOW to be produced by tape driver 
(need to set max_sg_segs=64, as mentioned in docs).

As a byproduct of the above, a bug was found in the linux
scsi tape driver. That is, after finding out that it has got
the wrong buffersize, it attempts to back space and try again.
However, backspacing in the first media file caused the
status flags to be stuffed - so a rewind is done in this instance.
Arggh.

Also fixes stupid bug in xfsinvutil.

Some associated qa tests.

--Tim

Date:  Tue Oct 17 23:14:41 PDT 2000
Workarea:  sherman.melbourne.sgi.com:/hosts/snort/build4/tes/slinx-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76390a
cmd/xfs/stress/046.out - 1.1
	- Shows that listing of dump/restore dirs match.

cmd/xfs/stress/047.out - 1.1
	- Shows results of pruning inventory.

cmd/xfs/stress/047 - 1.1
	- Tests out invutil in interactive mode.

cmd/xfs/stress/046 - 1.1
	- Checks that the owner/group and permissions are xfsrestored correctly
	  for symlinks. This would have shown up the lchown problem on symlinks.
	  I thought I'd noticed this problem before but hadn't written the test yet.

cmd/xfs/stress/group - 1.48
	- Add 046, 047.

cmd/xfs/dump/common/drive_minrmt.c - 1.24
	- Add code to handle having tape blocks which are bigger
	  than the allocated buffer.
	  (handles ENOMEM in Linux)

cmd/xfs/dump/common/drive_scsitape.c - 1.28
	- 1. Add code to handle having tape blocks which are bigger
	  than the allocated buffer.
	  (handles ENOMEM in Linux)
	  2. Modify backspace code to handle the case when it is in
	  the first media file. If it is in the first media file then
	  do a rewind instead of a bsf. This is a workaround for a
	  bug in the linux scsi tape driver where bsp'ing in the first
	  file does not set the status flags correctly (should be at BOT).
	  Kai Makisara suggested the workaround.

cmd/xfs/dump/invutil/invutil.c - 1.9
	- Fix stupid porting bug - when changing gets() to fgets() - oops.
	  Added qa test 047 to test this. Previously my qa testing of invutil
	  used the -n option which didn't require interactive input.

cmd/xfs/dump/restore/content.c - 1.18
	- Add a diagnostic mlog message that shows the session uuid obtained
	  from the inventory compared with the session uuid obtained from
	  the global header off the tape.
	  This was used to find out why xfsrestore wasn't finding the session
	  that I specified using the label - b/c it uses the session label
	  from the inventory which may have a different uuid !

cmd/xfs/stress/common.dump - 1.17
	- Add _create_dumpdir_symlinks to create files and symlinks of
	  various permissions and ownerships/groupships for use by
	  046.



From owner-linux-xfs@oss.sgi.com Wed Oct 18 18:19:48 2000
Received:  by oss.sgi.com id <S553652AbQJSBT2>;
	Wed, 18 Oct 2000 18:19:28 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:58974 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553648AbQJSBTI>;
	Wed, 18 Oct 2000 18:19:08 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA23220
	for <linux-xfs@oss.sgi.com>; Wed, 18 Oct 2000 18:11:21 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA7323317 for <linux-xfs@oss.sgi.com>; Wed, 18 Oct 2000 20:16:36 -0500 (CDT)
Received: from laptop.americas.sgi.com (IDENT:root@[192.82.201.203]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.6mw-e) with ESMTP id UAA17589 for <linux-xfs@oss.sgi.com>; Wed, 18 Oct 2000 20:16:34 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: by laptop.americas.sgi.com (8.11.0/SGI-client-1.6c) id e9J1QBQ01316; Wed, 18 Oct 2000 20:26:11 -0500
Message-Id: <200010190126.e9J1QBQ01316@laptop.americas.sgi.com>
Date:   Wed, 18 Oct 2000 20:26:11 -0500
Subject: TAKE - fix redhat 7 command build
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Note that an optimized compile still fails - but by via a compiler core
dump! Using the kgcc compiler on redhat 7 works around that.

Date:  Wed Oct 18 18:11:31 PDT 2000
Workarea:  192.82.201.203:/usr/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76433a
cmd/xfs/dump/librmt/rmtdev.c - 1.2
	- Fixed redhat 7 command build.



From owner-linux-xfs@oss.sgi.com Thu Oct 19 11:06:55 2000
Received:  by oss.sgi.com id <S553692AbQJSSGg>;
	Thu, 19 Oct 2000 11:06:36 -0700
Received: from sun.rhrk.uni-kl.de ([131.246.137.50]:5855 "HELO
        sun.rhrk.uni-kl.de") by oss.sgi.com with SMTP id <S553647AbQJSSGX>;
	Thu, 19 Oct 2000 11:06:23 -0700
Received: from aixs1.rhrk.uni-kl.de
           ( exim@aixs1.rhrk.uni-kl.de [131.246.137.3] ) by sun.rhrk.uni-kl.de
          id aa00595 for <linux-xfs@oss.sgi.com>; 19 Oct 2000 20:06 MESZ
Received: from trip210.wohnheim.uni-kl.de ([131.246.188.10] helo=student.uni-kl.de)
	by aixs1.rhrk.uni-kl.de with esmtp (Exim 3.03 #2)
	id 13mK55-0007vW-00
	for linux-xfs@oss.sgi.com; Thu, 19 Oct 2000 20:06:19 +0200
Message-ID: <39EF3966.812685ED@student.uni-kl.de>
Date:   Thu, 19 Oct 2000 18:11:50 +0000
From:   Ralf Sinoradzki <sinoradz@student.uni-kl.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-XFS-test8 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC:     linux-xfs@oss.sgi.com
Subject: Random crashes with Realtek
References: <200010172346.KAA79535@snort.melbourne.sgi.com>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

I had a lot of random crashes with the current
xfs-kernel (2.4-test8). First, I thought it was the 
cron job or unloading of modules. Sometimes the
machine did a reboot or hang after 15 minutes, sometimes
I had no problems vor almost a day. I think it was only
a bug in the Realtek-8139 driver. I have installed the
latest version 0.9.10 and it seems to work now.
You can download it at 

http://gtf.org/garzik/drivers/8139too/

Perhaps this should be updated to the cvs-tree if we don't
use a newer kernel release. I don't know if anyone had
the same problems.

ciao, Ralf

From owner-linux-xfs@oss.sgi.com Thu Oct 19 17:21:07 2000
Received:  by oss.sgi.com id <S553755AbQJTAU6>;
	Thu, 19 Oct 2000 17:20:58 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:59453 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553752AbQJTAUg>;
	Thu, 19 Oct 2000 17:20:36 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA09122
	for <linux-xfs@oss.sgi.com>; Thu, 19 Oct 2000 17:12:47 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA96035
	for linux-xfs@oss.sgi.com; Fri, 20 Oct 2000 11:19:16 +1100 (EST)
Date:   Fri, 20 Oct 2000 11:19:16 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010200019.LAA96035@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - quota
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

First set of changes to support journalled dquot updates in XFS.
Plenty to do still, far from complete (panics alot less though).


Modid:  2.4.x-xfs:slinx:76496a
Date:  Thu Oct 19 17:13:00 PDT 2000
Workarea:  snort:/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/Documentation/Configure.help - 1.62
	- Add some text about XFS and quota.

linux/fs/Config.in - 1.42
	- Add config option for XFS quota support.

linux/fs/dquot.c - 1.16
linux/fs/noquot.c - 1.5
	- intercept quotactl commands for XFS quota manager & dispatch.

linux/fs/xfs/linux/Makefile - 1.26
	- add xfs_quotactl.o.

linux/fs/xfs/linux/xfs_super.c - 1.96
	- ensure dq_op is initialized.

linux/fs/xfs/xfs.h - 1.6
	- add xqm.h, remove pseudo-inc version.

linux/fs/xfs/xfs_dquot.h - 1.17
	- formatting changes, fix a debug macro.

linux/fs/xfs/xfs_qm.c - 1.56
	- correct a comment, fix a debug macro.

linux/fs/xfs/xfs_qm_syscalls.c - 1.43
	- remove IRIX-specificness from the quotactl interface, remove
	  unsupported stuff (stub routine), minor tidying.

linux/fs/xfs/xfs_quota.h - 1.22
	- update interface to xfs_quotactl.

linux/fs/xfs/xfs_quota_priv.h - 1.14
	- ensure vflag has purge bit set before attempting to purge- fixes a
	  panic on unmount with quota on.

linux/fs/xfs/xfsquotasstubs.c - 1.12
	- update interface to xfs_quotactl.

linux/fs/xfs/linux/xfs_quotactl.c - 1.1
	- wrap up Linux quotactl specifics before calling down into generic
	  XFS quota code.

linux/include/linux/xqm.h - 1.1
	- XFS quota manager header - macros, ondisk types, etc. needed by
	  userspace and the kernel.


From owner-linux-xfs@oss.sgi.com Thu Oct 19 20:56:38 2000
Received:  by oss.sgi.com id <S553763AbQJTD4R>;
	Thu, 19 Oct 2000 20:56:17 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21097 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553756AbQJTDzy>; Thu, 19 Oct 2000 20:55:54 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA00195
	for <linux-xfs@oss.sgi.com>; Thu, 19 Oct 2000 21:03:11 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA78736
	for linux-xfs@oss.sgi.com; Fri, 20 Oct 2000 14:54:33 +1100 (EST)
Date:   Fri, 20 Oct 2000 14:54:33 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010200354.OAA78736@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - quot.xfs
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:76509a
Date:  Thu Oct 19 20:52:24 PDT 2000
Workarea:  snort:/build4/nathans/base-linux-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/Makefile - 1.32
	- add quot.xfs

cmd/xfs/man/man8/quot.xfs.8 - 1.1
cmd/xfs/quot/Makefile - 1.1
cmd/xfs/quot/xfs_quot.c - 1.1
	- trivial utility common to many os'es which simply walks a filesystem
	  and reports on disk space usage by all users.  this is the xfs
	  version that uses the bulkstat ioctl to go faster.

cmd/xfs/fsr/Makefile - 1.8
cmd/xfs/stress/042 - 1.3
cmd/xfs/stress/042.out - 1.3
cmd/xfs/man/man8/fsr.xfs.8 - 1.1
	- follow established naming conventions in case other extent-based fs's
	  want to use an fsr also.


From owner-linux-xfs@oss.sgi.com Thu Oct 19 23:06:28 2000
Received:  by oss.sgi.com id <S553761AbQJTGGS>;
	Thu, 19 Oct 2000 23:06:18 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16750 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553715AbQJTGGF>; Thu, 19 Oct 2000 23:06:05 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA08301
	for <linux-xfs@oss.sgi.com>; Thu, 19 Oct 2000 23:13:23 -0700 (PDT)
	mail_from (ajag@snort.melbourne.sgi.com)
Received: (from ajag@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA16109
	for linux-xfs@oss.sgi.com; Fri, 20 Oct 2000 17:04:29 +1100 (EST)
Date:   Fri, 20 Oct 2000 17:04:29 +1100 (EST)
From:   Andrew Gildfind <ajag@snort.melbourne.sgi.com>
Message-Id: <200010200604.RAA16109@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - new attrctl(2) system call
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:76513a
Date:  Thu Oct 19 23:03:15 PDT 2000
Workarea:  snort:/build5/ajag/slinx
Author:  ajag

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/Makefile - 1.33
	- Add libattr to default build.

cmd/xfs/include/attributes.h - 1.8
	- New attrctl(2) system call, typedefs, and IRIX API.

cmd/xfs/include/builddefs.in - 1.17
	- Define LIBATTR

cmd/xfs/libattr/attr.c - 1.2
	- Layer IRIX attr_* API on new attrctl system call.

cmd/xfs/libxfs/xfs.h - 1.8
	- Delete CULL_SYSCALLS

linux/arch/alpha/kernel/entry.S - 1.16
linux/arch/arm/kernel/calls.S - 1.12
	- Replace attr_get, attr_set, with attrctl syscall

linux/arch/i386/kernel/entry.S - 1.26
linux/arch/ia64/ia32/ia32_entry.S - 1.8
	- Replace attr_get, attr_set, with attrctl syscall
	  Use syscall number 250 to buy some breathing space.

linux/arch/ia64/kernel/entry.S - 1.8
	- Replace attr_get, attr_set, with attrctl syscall

linux/arch/ia64/kernel/ivt.S - 1.6
	- Replace attr_get, attr_set, with attrctl syscall
	  Use syscall number 250 to buy some breathing space.

linux/arch/m68k/kernel/entry.S - 1.11
linux/arch/mips/kernel/syscalls.h - 1.8
linux/arch/mips64/kernel/scall_64.S - 1.5
linux/arch/ppc/kernel/misc.S - 1.20
linux/arch/s390/kernel/entry.S - 1.4
linux/arch/sh/kernel/entry.S - 1.12
linux/arch/sparc/kernel/systbls.S - 1.15
linux/arch/sparc64/kernel/systbls.S - 1.18
	- Replace attr_get, attr_set, with attrctl syscall

linux/fs/stat.c - 1.14
	- Rip out existing 4 attr_get/set/list/remove system calls.
	  Replace with single attrctl interface which calls the attrctl iop.
	  Calls are now farmed out below the VFS layer.

linux/fs/xfs/linux/xfs_iops.c - 1.77
	- Rip out existing 4 attr_get/set/list/remove iops.
	  Replace with single attrctl interface which farms out extended attribute operations
	  to existing VFS VOPs.

linux/fs/xfs/xfs.h - 1.7
	- Remove pseudo-inc/attributes.h replace with linux/attributes.h

linux/include/asm-alpha/unistd.h - 1.12
linux/include/asm-arm/unistd.h - 1.13
linux/include/asm-i386/unistd.h - 1.13
linux/include/asm-ia64/unistd.h - 1.7
linux/include/asm-m68k/unistd.h - 1.8
linux/include/asm-mips/unistd.h - 1.8
linux/include/asm-mips64/unistd.h - 1.5
linux/include/asm-ppc/unistd.h - 1.10
linux/include/asm-s390/unistd.h - 1.4
linux/include/asm-sh/unistd.h - 1.9
linux/include/asm-sparc/unistd.h - 1.10
linux/include/asm-sparc64/unistd.h - 1.12
	- Replace attr_get, attr_set, with attrctl syscall

linux/include/linux/fs.h - 1.65
	- Update the extended attribute interface.
	  Replace attr_get, attr_set, attr_remove, and attr_list with
	  attrctl inode operation.

linux/include/linux/attributes.h - 1.1
	- New attrctl(2) system call, typedefs, and IRIX API.


From owner-linux-xfs@oss.sgi.com Fri Oct 20 08:09:32 2000
Received:  by oss.sgi.com id <S553669AbQJTPJX>;
	Fri, 20 Oct 2000 08:09:23 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:9076 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553659AbQJTPJU>;
	Fri, 20 Oct 2000 08:09:20 -0700
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA05144; Fri, 20 Oct 2000 08:01:33 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id IAA35154;
	Fri, 20 Oct 2000 08:09:19 -0700 (PDT)
Date:   Fri, 20 Oct 2000 08:09:19 -0700 (PDT)
Message-Id: <200010201509.IAA35154@info.engr.sgi.com>
X-Pv-Incident: 801246 
webPV:  jen.americas.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (lord@sgi.com)
Subject: CLOSE 801246 - XFS on loopback mount doesn't work
To:     nb@sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801246

*Status : closed                       Priority : 3                         
 Assigned Engineer : nb                Submitter : dxm                      
 Opened Date : 09/07/00               *Closed Date : 10/20/00               
*Fixed By : lord                      *Fixed By Domain : sgi.com            
*Modified Date : 10/20/00             *Modified User : lord                 
*Modified User Domain : sgi.com       *Fix Description :
==========================
ADDITIONAL INFORMATION (CLOSE)
From: lord@sgi.com (BugWorks)
Date: Oct 20 2000 08:09:19AM
==========================

I checked in some basic code to make loopback at least function.
I suspect there will be holes in the implementation. I have
mounted an ext2 filesystem in a file on an xfs filesystem,
I also mounted an xfs filesystem in a file on an xfs filesystem.

From owner-linux-xfs@oss.sgi.com Fri Oct 20 20:19:29 2000
Received:  by oss.sgi.com id <S553722AbQJUDTU>;
	Fri, 20 Oct 2000 20:19:20 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49494 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553682AbQJUDTI>; Fri, 20 Oct 2000 20:19:08 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA05909
	for <linux-xfs@oss.sgi.com>; Fri, 20 Oct 2000 20:26:27 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA81000
	for linux-xfs@oss.sgi.com; Sat, 21 Oct 2000 14:16:34 +1100 (EST)
Date:   Sat, 21 Oct 2000 14:16:34 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010210316.OAA81000@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - 
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:76581a
Date:  Fri Oct 20 20:16:03 PDT 2000
Workarea:  snort:/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/quot/xfs_quot.c - 1.2
	- report on errno, not ioctl return value, dopey.

linux/fs/xfs/linux/xfs_ioctl.c - 1.23
	- ensure bulkstat and growfs operations only allow privileged user access.


From owner-linux-xfs@oss.sgi.com Sat Oct 21 14:18:58 2000
Received:  by oss.sgi.com id <S553724AbQJUVSs>;
	Sat, 21 Oct 2000 14:18:48 -0700
Received: from c1042494-a.stcla1.sfba.home.com ([24.15.93.106]:36877 "HELO
        mail.kaxis.cx") by oss.sgi.com with SMTP id <S553694AbQJUVSc>;
	Sat, 21 Oct 2000 14:18:32 -0700
Received: (qmail 17620 invoked by uid 1000); 21 Oct 2000 21:20:56 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 21 Oct 2000 21:20:56 -0000
Date:   Sat, 21 Oct 2000 14:20:56 -0700 (PDT)
From:   Andrew Edem <aedem@kaxis.cx>
To:     linux-xfs@oss.sgi.com
Subject: GCC Issues
Message-ID: <Pine.LNX.4.21.0010211417400.17563-100000@gate.kaxis.cx>
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

OK, I really want to use XFS. I've got an SMP system, (dual 733 PIII's),
and a 45 GB drive on a Promise UDMA 100 controller.

The problem is this, after compiling with GCC 2.95.2 (on Debian woody),
processes hang when accessing the XFS disk. So, I RTFM, and got EGCS
1.1.2, which only compiled after some serious hacking to the libio code,
which was rediculous, because I didn't need C++ anyway. I then boot with a
kernel compiled with GCC 2.91.66, and my machine hangs because of the USB
drivers. This might be related to SMP, MPS, or something of the
sort. Anyhow, I tried again with GCC 2.7.2.3, and the kernel doesn't even
compile, the assembler pukes. Any ideas?

-Andrew


From owner-linux-xfs@oss.sgi.com Sat Oct 21 18:17:59 2000
Received:  by oss.sgi.com id <S553744AbQJVBRt>;
	Sat, 21 Oct 2000 18:17:49 -0700
Received: from ppp0.ocs.com.au ([203.34.97.3]:14607 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553740AbQJVBR1>;
	Sat, 21 Oct 2000 18:17:27 -0700
Received: (qmail 22778 invoked from network); 22 Oct 2000 01:17:22 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 22 Oct 2000 01:17:22 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Andrew Edem <aedem@kaxis.cx>
cc:     linux-xfs@oss.sgi.com
Subject: Re: GCC Issues 
In-reply-to: Your message of "Sat, 21 Oct 2000 14:20:56 PDT."
             <Pine.LNX.4.21.0010211417400.17563-100000@gate.kaxis.cx> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Sun, 22 Oct 2000 12:17:21 +1100
Message-ID: <18756.972177441@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sat, 21 Oct 2000 14:20:56 -0700 (PDT), 
Andrew Edem <aedem@kaxis.cx> wrote:
>OK, I really want to use XFS. I've got an SMP system, (dual 733 PIII's),
>The problem is this, after compiling with GCC 2.95.2 (on Debian woody),
>processes hang when accessing the XFS disk. So, I RTFM, and got EGCS
>1.1.2, which only compiled after some serious hacking to the libio code,
>which was rediculous, because I didn't need C++ anyway. I then boot with a
>kernel compiled with GCC 2.91.66, and my machine hangs because of the USB
>drivers. This might be related to SMP, MPS, or something of the
>sort. Anyhow, I tried again with GCC 2.7.2.3, and the kernel doesn't even
>compile, the assembler pukes. Any ideas?

The best option is egcs 1.1.2 (gcc 2.91.66) and binutils >= 2.9.1.0.25,
the assembler problems come from "as" which is in binutils, not gcc.
Newer versions of gcc are unreliable for the kernel, newer versions of
binutils are OK, I run binutils 2.9.5.0.22.  If at all possible, get a
Debian binary for these instead of trying to compile them yourself,
much more reliable.

The USB hang is probably SMP related, there is still a lot of work
going on the USB source.  Can you compile the kernel without USB or
make all of USB a module instead of builtin?


From owner-linux-xfs@oss.sgi.com Sat Oct 21 20:24:29 2000
Received:  by oss.sgi.com id <S553750AbQJVDYT>;
	Sat, 21 Oct 2000 20:24:19 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21623 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553743AbQJVDX6>; Sat, 21 Oct 2000 20:23:58 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA05475
	for <linux-xfs@oss.sgi.com>; Sat, 21 Oct 2000 20:31:18 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA86117
	for linux-xfs@oss.sgi.com; Sun, 22 Oct 2000 14:22:40 +1100 (EST)
Date:   Sun, 22 Oct 2000 14:22:40 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010220322.OAA86117@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - cmds
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

an initial pass at supporting Debian packages natively
in the commands build.  generating a binary .deb Works
For Me (tm) on 2.2 - theres a few areas which could use
some improvement still, but after an install everything
looks to be in kinda the right spot & dpkg -l gives:

||/ Name           Version        Description
+++-==============-==============-======================================
ii  xfs-cmds       1.0.6          XFS file system commands and utilities

... so thats a start!

cheers.


Modid:  2.4.x-xfs:slinx:76587a
Date:  Sat Oct 21 20:06:29 PDT 2000
Workarea:  snort:/build4/nathans/linux-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/Makefile - 1.34
	- add to LDIRT for things which build leaves around (for make clean).

cmd/xfs/build/rpm/xfs-cmds.spec.in - 1.3
	- make all the blurbs about xfs consistent.

cmd/xfs/build/Makefile - 1.4
cmd/xfs/configure.in - 1.17
cmd/xfs/build/deb/Makefile - 1.1
cmd/xfs/build/deb/changelog.pl - 1.1
cmd/xfs/build/deb/control.in - 1.1
cmd/xfs/build/deb/copyright - 1.1
cmd/xfs/build/deb/rules - 1.1
	- add support for generating debian packages.


From owner-linux-xfs@oss.sgi.com Sun Oct 22 18:32:23 2000
Received:  by oss.sgi.com id <S553783AbQJWBcC>;
	Sun, 22 Oct 2000 18:32:02 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:23063 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553673AbQJWBbe>;
	Sun, 22 Oct 2000 18:31:34 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA15425
	for <linux-xfs@oss.sgi.com>; Sun, 22 Oct 2000 18:23:44 -0700 (PDT)
	mail_from (tes@sherman.melbourne.sgi.com)
Received: (from tes@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id MAA29648
	for linux-xfs@oss.sgi.com; Mon, 23 Oct 2000 12:29:29 +1100
Date:   Mon, 23 Oct 2000 12:29:29 +1100
From:   Tim Shimmin <tes@sherman.melbourne.sgi.com>
Message-Id: <200010230129.MAA29648@sherman.melbourne.sgi.com>
Subject: TAKE - xfsdump stress back in auto
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Sun Oct 22 18:25:53 PDT 2000
Workarea:  sherman.melbourne.sgi.com:/hosts/snort/build4/tes/slinx-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76589a
cmd/xfs/stress/group - 1.49
	- Put xfsdump related tests back in to auto-qa group
	  for nightly qa.

From owner-linux-xfs@oss.sgi.com Mon Oct 23 00:33:26 2000
Received:  by oss.sgi.com id <S553753AbQJWHdQ>;
	Mon, 23 Oct 2000 00:33:16 -0700
Received: from plutonium.uunet.be ([194.7.1.47]:3082 "EHLO plutonium.uunet.be")
	by oss.sgi.com with ESMTP id <S553696AbQJWHdG>;
	Mon, 23 Oct 2000 00:33:06 -0700
Received: from gate.vum.be (firewall.vum.be [194.7.240.162])
	by plutonium.uunet.be (8.9.1/8.9.3) with SMTP id JAA03701
	for <linux-xfs@oss.sgi.com>; Mon, 23 Oct 2000 09:33:04 +0200 (CEST)
Received: from pcgx14500003.vum.be (pcgx14500003 [83.105.1.4]) by leonidas.vum.be with ESMTP (8.7.6/8.7.1) id JAA25971 for <linux-xfs@oss.sgi.com>; Mon, 23 Oct 2000 09:34:59 +0200 (METDST)
Received: from vum.be (IDENT:kris@localhost.localdomain [127.0.0.1])
	by pcgx14500003.vum.be (8.9.3/8.8.7) with ESMTP id JAA03436
	for <linux-xfs@oss.sgi.com>; Mon, 23 Oct 2000 09:32:32 +0200
Message-ID: <39F3E990.65557D8@vum.be>
Date:   Mon, 23 Oct 2000 09:32:32 +0200
From:   kris buggenhout <gast6@vum.be>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: GCC Issues
References: <18756.972177441@ocs3.ocs-net>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

S2VpdGggT3dlbnMgd3JvdGU6DQoNCj4NCj4gVGhlIFVTQiBoYW5nIGlzIHByb2JhYmx5IFNN
UCByZWxhdGVkLCB0aGVyZSBpcyBzdGlsbCBhIGxvdCBvZiB3b3JrDQo+IGdvaW5nIG9uIHRo
ZSBVU0Igc291cmNlLiAgQ2FuIHlvdSBjb21waWxlIHRoZSBrZXJuZWwgd2l0aG91dCBVU0Ig
b3INCj4gbWFrZSBhbGwgb2YgVVNCIGEgbW9kdWxlIGluc3RlYWQgb2YgYnVpbHRpbj8NCg0K
c3RyYW5nZS4uLiBJIGhhdmUgZG9uZSB0aGlzIG9uIGEgRGVsbCBQb3dlcmVkZ2UgNjQwMCB3
aXRoIDRDUFUncyA0R0IgcmFtIGFuZA0KaGFkIG5vIHByb2JsZW0gd2hhdHNvZXZlci4uLg0K
SSB1c2VkIHRoZSBycG0ncyBmb3IgdGhlIGJldGEgYXMgd2VsbCBhcyB0aGUga2VybmVsIHJl
Y29tcGlsZS4NCg0KSXQgZXZlbiBoYWQgbm8gIm5vcm1hbCIgaWRlIG9yIHNjc2kgZGlza3Ms
IG9ubHkgYSBoYXJkd2FyZSByYWlkIGNvbnRyb2xlci4uLg0KQW5kIHRoYXQgd29ya3MgdG9v
IC4uLiA6KQ0KDQpJIGNvbXBpbGVkIHdpdGggdGhlIG1vc3QgcmVjZW50IGJpbnV0aWxzIGFu
ZCB0aGUgZ2NjIHRoYXQgY29tZXMgd2l0aCBSSCA2LjIgKA0Kb24gb2YgdGhlIGNvbmRlbW5l
ZCB2ZXJzaW9ucykNCmFuZCBoYXZlIGEgY2xlYW4gY29tcGlsZSA5OSBvdXQgb2YgMTAwLg0K
DQoNCkkgaGFkIHNpbWlsYXIgdHJvdWJsZSBvbiBhbiBzaW5nbGUgY3B1IHN5c3RlbS4uLiBk
dWUgdG8gYSBzZXR0aW5nIGluDQpwb3dlcm1hbmFnZW1lbnQgd2FrZSBvbiBVU0IuLi4gdGhh
dCBtZXNzZWQgdXAgdGhlIGJvb3QgcHJvY2VkdXJlIC4uLg0KDQouLi4NCg0KDQo=

From owner-linux-xfs@oss.sgi.com Mon Oct 23 00:43:26 2000
Received:  by oss.sgi.com id <S553769AbQJWHnQ>;
	Mon, 23 Oct 2000 00:43:16 -0700
Received: from c1042494-a.stcla1.sfba.home.com ([24.15.93.106]:13582 "HELO
        mail.kaxis.cx") by oss.sgi.com with SMTP id <S553733AbQJWHmv>;
	Mon, 23 Oct 2000 00:42:51 -0700
Received: (qmail 24014 invoked by uid 1000); 23 Oct 2000 07:45:24 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 23 Oct 2000 07:45:24 -0000
Date:   Mon, 23 Oct 2000 00:45:23 -0700 (PDT)
From:   Andrew Edem <aedem@kaxis.cx>
To:     kris buggenhout <gast6@vum.be>
cc:     linux-xfs@oss.sgi.com
Subject: Re: GCC Issues
In-Reply-To: <39F3E990.65557D8@vum.be>
Message-ID: <Pine.LNX.4.21.0010230043270.24012-100000@gate.kaxis.cx>
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

I always keep USB a module, and I've set MPS to 1.1, and disabled power
management. The system works for a while, but locks up whenever a usb
event occurs, which is bad, because i've got a usb mouse. The lock ups
start at about 1 second, and increase in length exponentially, until the
system locks indefinatly. Has anyone tried GCC 2.97?

On Mon, 23 Oct 2000, kris buggenhout wrote:

> Keith Owens wrote:
> 
> >
> > The USB hang is probably SMP related, there is still a lot of work
> > going on the USB source.  Can you compile the kernel without USB or
> > make all of USB a module instead of builtin?
> 
> strange... I have done this on a Dell Poweredge 6400 with 4CPU's 4GB ram and
> had no problem whatsoever...
> I used the rpm's for the beta as well as the kernel recompile.
> 
> It even had no "normal" ide or scsi disks, only a hardware raid controler...
> And that works too ... :)
> 
> I compiled with the most recent binutils and the gcc that comes with RH 6.2 (
> on of the condemned versions)
> and have a clean compile 99 out of 100.
> 
> 
> I had similar trouble on an single cpu system... due to a setting in
> powermanagement wake on USB... that messed up the boot procedure ...
> 
> ...
> 
> 
> 


From owner-linux-xfs@oss.sgi.com Mon Oct 23 07:14:41 2000
Received:  by oss.sgi.com id <S553795AbQJWOOb>;
	Mon, 23 Oct 2000 07:14:31 -0700
Received: from nic-25-c125-118.mn.mediaone.net ([24.25.125.118]:56075 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S553791AbQJWOOO>;
	Mon, 23 Oct 2000 07:14:14 -0700
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.0/8.11.0) with ESMTP id e9NEDFT86985;
	Mon, 23 Oct 2000 09:13:23 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <39F4477B.43DC592@thebarn.com>
Date:   Mon, 23 Oct 2000 09:13:15 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andrew Edem <aedem@kaxis.cx>
CC:     kris buggenhout <gast6@vum.be>, linux-xfs@oss.sgi.com
Subject: Re: GCC Issues
References: <Pine.LNX.4.21.0010230043270.24012-100000@gate.kaxis.cx>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Andrew Edem wrote:

> I always keep USB a module, and I've set MPS to 1.1, and disabled power
> management. The system works for a while, but locks up whenever a usb
> event occurs, which is bad, because i've got a usb mouse. The lock ups
> start at about 1 second, and increase in length exponentially, until the
> system locks indefinatly.

My laptop is running fine with a usb mouse attached, but it is not a SMP system.

If I get a chance I'll slap a usb mouse on one of the smp systems, see what
happens.

> Has anyone tried GCC 2.97?

2.96.x wouldn't even compile the kernel.
I doubt 2.97 will have much better luck.

Since most recommendations for kernel compilation seem to suggest using 2.91.66
I doubt we will spend much time trying to beat the code in submission.
Especially since other parts of the kernel may not work.


>
>
> On Mon, 23 Oct 2000, kris buggenhout wrote:
>
> > Keith Owens wrote:
> >
> > >
> > > The USB hang is probably SMP related, there is still a lot of work
> > > going on the USB source.  Can you compile the kernel without USB or
> > > make all of USB a module instead of builtin?
> >
> > strange... I have done this on a Dell Poweredge 6400 with 4CPU's 4GB ram and
> > had no problem whatsoever...
> > I used the rpm's for the beta as well as the kernel recompile.
> >
> > It even had no "normal" ide or scsi disks, only a hardware raid controler...
> > And that works too ... :)
> >
> > I compiled with the most recent binutils and the gcc that comes with RH 6.2 (
> > on of the condemned versions)
> > and have a clean compile 99 out of 100.
> >
> >
> > I had similar trouble on an single cpu system... due to a setting in
> > powermanagement wake on USB... that messed up the boot procedure ...
> >
> > ...
> >
> >
> >

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Mon Oct 23 17:22:47 2000
Received:  by oss.sgi.com id <S553683AbQJXAWh>;
	Mon, 23 Oct 2000 17:22:37 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:61960 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553657AbQJXAWL>; Mon, 23 Oct 2000 17:22:11 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA06510
	for <linux-xfs@oss.sgi.com>; Mon, 23 Oct 2000 17:29:33 -0700 (PDT)
	mail_from (kenmcd@snort.melbourne.sgi.com)
Received: (from kenmcd@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA36209;
	Tue, 24 Oct 2000 11:20:51 +1100 (EST)
Date:   Tue, 24 Oct 2000 11:20:51 +1100 (EST)
From:   Ken McDonell <kenmcd@snort.melbourne.sgi.com>
Message-Id: <200010240020.LAA36209@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Cc:     sandeen@sgi.com
Subject: TAKE - xfs stress script changes
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

We've re-run QA after these changes have been made, and see no
consequential failures ... let me know if anything else bad happens!

Rework I/O redirection, particularly of stderr to make syntax
compatible with the Bourne shell rules

Modid:  2.4.x-xfs:slinx:76679a
Date:  Mon Oct 23 16:03:11 PDT 2000
Workarea:  snort:/root_65/kenmcd/slinx-xfs
Author:  kenmcd

The following file(s) were checked into:
  bonnie.engr.sgi.com:/depot/slinx/2.4.x-xfs

cmd/xfs/stress/003 - 1.6
cmd/xfs/stress/004 - 1.7
cmd/xfs/stress/007 - 1.3
cmd/xfs/stress/008 - 1.5
cmd/xfs/stress/009 - 1.5
cmd/xfs/stress/011 - 1.5
cmd/xfs/stress/012 - 1.4
cmd/xfs/stress/013 - 1.8
cmd/xfs/stress/014 - 1.4
cmd/xfs/stress/016 - 1.5
cmd/xfs/stress/017 - 1.7
cmd/xfs/stress/018 - 1.5
cmd/xfs/stress/019 - 1.10
cmd/xfs/stress/020 - 1.4
cmd/xfs/stress/021 - 1.3
cmd/xfs/stress/031 - 1.6
cmd/xfs/stress/034 - 1.2
cmd/xfs/stress/041 - 1.2
cmd/xfs/stress/042 - 1.4
cmd/xfs/stress/044 - 1.6
cmd/xfs/stress/045 - 1.4
cmd/xfs/stress/check - 1.13
cmd/xfs/stress/common.config - 1.11
cmd/xfs/stress/common.dump - 1.18
cmd/xfs/stress/common.filter - 1.8
cmd/xfs/stress/common.rc - 1.38
cmd/xfs/stress/soak - 1.7

From owner-linux-xfs@oss.sgi.com Mon Oct 23 17:27:37 2000
Received:  by oss.sgi.com id <S553690AbQJXA11>;
	Mon, 23 Oct 2000 17:27:27 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16137 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553663AbQJXA1R>; Mon, 23 Oct 2000 17:27:17 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA03508
	for <linux-xfs@oss.sgi.com>; Mon, 23 Oct 2000 17:34:39 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA96213
	for linux-xfs@oss.sgi.com; Tue, 24 Oct 2000 11:25:58 +1100 (EST)
Date:   Tue, 24 Oct 2000 11:25:58 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010240025.LAA96213@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - nopkg()
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:76684a
Date:  Mon Oct 23 17:25:26 PDT 2000
Workarea:  snort:/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/linux/xfs_linux.h - 1.33
linux/fs/xfs/xfs_log_recover.c - 1.195
	- use ENOSYS in preference to ENOPKG.


From owner-linux-xfs@oss.sgi.com Mon Oct 23 18:04:47 2000
Received:  by oss.sgi.com id <S553700AbQJXBE1>;
	Mon, 23 Oct 2000 18:04:27 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:60265 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553660AbQJXBET>;
	Mon, 23 Oct 2000 18:04:19 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA00983
	for <linux-xfs@oss.sgi.com>; Mon, 23 Oct 2000 17:56:29 -0700 (PDT)
	mail_from (tes@snort.melbourne.sgi.com)
Received: (from tes@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA07842
	for linux-xfs@oss.sgi.com; Tue, 24 Oct 2000 12:02:57 +1100 (EST)
Date:   Tue, 24 Oct 2000 12:02:57 +1100 (EST)
From:   Timothy Shimmin <tes@snort.melbourne.sgi.com>
Message-Id: <200010240102.MAA07842@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - stress/common.dump
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:76688a
Date:  Mon Oct 23 18:02:13 PDT 2000
Workarea:  snort:/build4/tes/slinx-xfs
Author:  tes

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/common.dump - 1.19
	- Speed up the dump tests which are "not-run" -
	  no need for fs consistency check or any sleeping.


From owner-linux-xfs@oss.sgi.com Mon Oct 23 18:28:48 2000
Received:  by oss.sgi.com id <S553721AbQJXB2i>;
	Mon, 23 Oct 2000 18:28:38 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:18030 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553717AbQJXB2a>;
	Mon, 23 Oct 2000 18:28:30 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA03507
	for <linux-xfs@oss.sgi.com>; Mon, 23 Oct 2000 18:20:39 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id MAA03545;
	Tue, 24 Oct 2000 12:27:16 +1100
Date:   Tue, 24 Oct 2000 12:27:16 +1100
From:   Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200010240127.MAA03545@sherman.melbourne.sgi.com>
Subject: TAKE - Synchronize to current kdb v1.5
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Synchronize to current kdb v1.5

Date:  Mon Oct 23 18:24:59 PDT 2000
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76690a
linux/init/main.c - 1.43
linux/arch/i386/kernel/traps.c - 1.29
linux/arch/i386/kernel/entry.S - 1.28
linux/include/linux/kdb.h - 1.10
linux/arch/i386/kernel/bluesmoke.c - 1.2


From owner-linux-xfs@oss.sgi.com Mon Oct 23 23:07:30 2000
Received:  by oss.sgi.com id <S553720AbQJXGHV>;
	Mon, 23 Oct 2000 23:07:21 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:45090 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553712AbQJXGHA>;
	Mon, 23 Oct 2000 23:07:00 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA29288
	for <linux-xfs@oss.sgi.com>; Mon, 23 Oct 2000 22:59:11 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id RAA32616;
	Tue, 24 Oct 2000 17:06:53 +1100
Date:   Tue, 24 Oct 2000 17:06:53 +1100
From:   Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200010240606.RAA32616@sherman.melbourne.sgi.com>
Subject: TAKE - Backport recent kdb fixes
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

kdb is being updated to IA64.  As part of that work, some minor
problems were found in kdb for ix86, this backports the fixes to XFS.

Date:  Mon Oct 23 23:04:47 PDT 2000
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76694a
linux/kdb/Makefile - 1.6
linux/kdb/kdbmain.c - 1.12
linux/kdb/ChangeLog - 1.3


From owner-linux-xfs@oss.sgi.com Tue Oct 24 00:07:40 2000
Received:  by oss.sgi.com id <S553735AbQJXHHa>;
	Tue, 24 Oct 2000 00:07:30 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57120 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553719AbQJXHHH>; Tue, 24 Oct 2000 00:07:07 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA04868
	for <linux-xfs@oss.sgi.com>; Tue, 24 Oct 2000 00:14:23 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id SAA14741;
	Tue, 24 Oct 2000 18:05:56 +1100
Date:   Tue, 24 Oct 2000 18:05:56 +1100
From:   Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200010240705.SAA14741@sherman.melbourne.sgi.com>
Subject: TAKE - Remove unnecessary include asm/kdb.h
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

fs/xfs/xfs.h included asm/kdb.h which meant that any kdb changes
recompiled all of XFS.  Only one routine (xfsidbg) actually uses kdb
and that already has its own includes.  asm/kdb.h removed from xfs.h.

Date:  Tue Oct 24 00:02:41 PDT 2000
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:76698a
linux/fs/xfs/xfs_da_btree.c - 1.114
linux/fs/xfs/xfs.h - 1.8


From owner-linux-xfs@oss.sgi.com Wed Oct 25 16:03:15 2000
Received:  by oss.sgi.com id <S553773AbQJYXCz>;
	Wed, 25 Oct 2000 16:02:55 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:9478 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553762AbQJYXC2>;
	Wed, 25 Oct 2000 16:02:28 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA28433
	for <linux-xfs@oss.sgi.com>; Wed, 25 Oct 2000 15:54:39 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA17566
	for linux-xfs@oss.sgi.com; Thu, 26 Oct 2000 10:01:09 +1100 (EST)
Date:   Thu, 26 Oct 2000 10:01:09 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010252301.KAA17566@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - build
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:76873a
Date:  Wed Oct 25 16:00:08 PDT 2000
Workarea:  snort:/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/linux/Makefile - 1.27
linux/fs/xfs/linux/xfs_quotactl.c - 1.4
	- fix quota for xfs-as-a-module builds.


From owner-linux-xfs@oss.sgi.com Wed Oct 25 18:54:54 2000
Received:  by oss.sgi.com id <S553775AbQJZByq>;
	Wed, 25 Oct 2000 18:54:46 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39803 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553648AbQJZByd>; Wed, 25 Oct 2000 18:54:33 -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 TAA04903
	for <linux-xfs@oss.sgi.com>; Wed, 25 Oct 2000 19:01:51 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04246; Thu, 26 Oct 2000 12:53:08 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA93221; Thu, 26 Oct 2000 12:53:01 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10010261253.ZM84523@wobbly.melbourne.sgi.com>
Date:   Thu, 26 Oct 2000 12:53:00 -0400
In-Reply-To: "Stephen C. Tweedie" <sct@redhat.com>
        "Quota mods needed for journaled quota" (Oct 25,  6:42pm)
References: <20001025184239.U6085@redhat.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     "Stephen C. Tweedie" <sct@redhat.com>, Jan Kara <jack@suse.cz>,
        jank@redhat.com, Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Quota mods needed for journaled quota
Cc:     linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-xfs@oss.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

hi Stephen,

On Oct 25,  6:42pm, Stephen C. Tweedie wrote:
> Subject: Quota mods needed for journaled quota
> ...
> All of these could be fixed very easily (at least for ext3) if it were
> possible for ext3 to install its own version of the superblock->dq_ops
> quota operations (which would just be simple wrappers around the
> existing quota calls).  However, the current sys_quotactl installs the
> default quota_ops into the superblock on quota_on without any chance
> for the filesystem to override it.
> 
> The addition of an "init_quota" method to the super_operations struct,
> with quota_on calling this and defaulting to installing the default
> quota_ops if the method is NULL, ought to be sufficient to let ext3
> get quotas right in all cases as far as I can see.
> 
> Comments?
> 

It might also/alternatively be generally useful to allow a
filesystem-specific implementation of quotactl itself - through
an additional member in the dquot_operations set of functions?

This would allow ext3 to do that which it needs to do differently
at Q_QUOTAON and would also allow Jan's changes to work in such
a way that both the current form of dquot structure and his new
version of dquots could be used together (his patches currently
change the ondisk dquot definition, which means the existing user
tools get back different structures to what they were expecting,
after issuing certain quotactl commands).

XFS also has its own, different ondisk format for dquots, which
it would like to pass over the quotactl interface - I imagine
filesystems coming from other OSs would too.  The quotactl
syscall is sufficiently generic - its alot like ioctl ;-) -
to allow any size/form of dquot to be passed back to userspace,
so a few new quotactl commands for Jan's new dquot structure
would allow the existing tools to continue to work & new user
tools could take advantage of his extensions (same again for XFS).

Anyway, hope this is useful input.


cheers.

ps: hmm - just realized something... is jank@redhat == jack@suse?

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu Oct 26 03:05:47 2000
Received:  by oss.sgi.com id <S553778AbQJZKF2>;
	Thu, 26 Oct 2000 03:05:28 -0700
Received: from dukat.scot.redhat.com ([195.89.149.246]:34564 "EHLO
        dukat.scot.redhat.com") by oss.sgi.com with ESMTP
	id <S553711AbQJZKFB>; Thu, 26 Oct 2000 03:05:01 -0700
Received: (from sct@localhost)
	by dukat.scot.redhat.com (8.9.3/8.9.3) id LAA12508;
	Thu, 26 Oct 2000 11:00:30 +0100
Date:   Thu, 26 Oct 2000 11:00:29 +0100
From:   "Stephen C. Tweedie" <sct@redhat.com>
To:     Nathan Scott <nathans@wobbly.melbourne.sgi.com>
Cc:     "Stephen C. Tweedie" <sct@redhat.com>, Jan Kara <jack@suse.cz>,
        jank@redhat.com, Linus Torvalds <torvalds@transmeta.com>,
        linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-xfs@oss.sgi.com
Subject: Re: Quota mods needed for journaled quota
Message-ID: <20001026110029.K20050@redhat.com>
References: <20001025184239.U6085@redhat.com> <sct@redhat.com> <10010261253.ZM84523@wobbly.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <10010261253.ZM84523@wobbly.melbourne.sgi.com>; from nathans@wobbly.melbourne.sgi.com on Thu, Oct 26, 2000 at 12:53:00PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

On Thu, Oct 26, 2000 at 12:53:00PM -0400, Nathan Scott wrote:

> > The addition of an "init_quota" method to the super_operations struct,
> > with quota_on calling this and defaulting to installing the default
> > quota_ops if the method is NULL, ought to be sufficient to let ext3
> > get quotas right in all cases as far as I can see.
> 
> It might also/alternatively be generally useful to allow a
> filesystem-specific implementation of quotactl itself - through
> an additional member in the dquot_operations set of functions?

I'm not sure how useful that addition would be --- for quota_on and
quota_off, at least, the setting up of the dquot structures around the
superblock or their destruction after quota_off can probably stay as
common code, with calls into the filesystem for init_quota (and
perhaps destroy_quota?) at the appropriate places.

> This would allow ext3 to do that which it needs to do differently
> at Q_QUOTAON and would also allow Jan's changes to work in such
> a way that both the current form of dquot structure and his new
> version of dquots could be used together

Adding the init_quota hook would do that, as the filesystem will be
able to install its own dq_ops methods during the init so we get the
flexibility you are asking for anyway.

Cheers,
 Stephen

From owner-linux-xfs@oss.sgi.com Thu Oct 26 09:48:59 2000
Received:  by oss.sgi.com id <S553788AbQJZQst>;
	Thu, 26 Oct 2000 09:48:49 -0700
Received: from ibbrain.ibb.waw.pl ([212.87.28.4]:37670 "EHLO
        ibbrain.ibb.waw.pl") by oss.sgi.com with ESMTP id <S553647AbQJZQsl>;
	Thu, 26 Oct 2000 09:48:41 -0700
Received: (from gigo@localhost)
	by ibbrain.ibb.waw.pl (SGI-8.9.3/8.9.3) id QAA06839;
	Thu, 26 Oct 2000 16:49:10 GMT
Date:   Thu, 26 Oct 2000 18:49:10 +0200 (MDT)
From:   gigo@ibbrain.ibb.waw.pl
To:     linux-xfs@oss.sgi.com
Subject: Large files
Message-ID: <Pine.SGI.3.91.1001026183726.202050A-100000@ibbrain.ibb.waw.pl>
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

 Hi,
I'm a newbie in this field, so my question will seem dummy for many, 
think. I've just compiled xfs into my kernel, because I need to operate 
on large data files. First thing I've done after mounting my new xfs was:
> dd if=/dev/zero of=BIG_FILE
Great. Now I have file, that I can not stat even (so rm does not work, he 
he). So, how can I use large files, since maximum filesize in linux is 
limited to 0x7fffffff ??? Just increasing this number in kernel sources 
isn't the best idea, is it ??? Thanks in advance,
Grzegorz Wieczorek

From owner-linux-xfs@oss.sgi.com Thu Oct 26 10:44:09 2000
Received:  by oss.sgi.com id <S553793AbQJZRnt>;
	Thu, 26 Oct 2000 10:43:49 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:30012 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553692AbQJZRnX>; Thu, 26 Oct 2000 10:43:23 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA00654
	for <linux-xfs@oss.sgi.com>; Thu, 26 Oct 2000 10:50:48 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA7435559; Thu, 26 Oct 2000 12:42:05 -0500 (CDT)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA14804; Thu, 26 Oct 2000 12:42:05 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e9QHg4k10441;
	Thu, 26 Oct 2000 12:42:04 -0500
Message-ID: <39F86CEB.82360CC0@thebarn.com>
Date:   Thu, 26 Oct 2000 12:42:03 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-whipme5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     gigo@ibbrain.ibb.waw.pl
CC:     linux-xfs@oss.sgi.com
Subject: Re: Large files
References: <Pine.SGI.3.91.1001026183726.202050A-100000@ibbrain.ibb.waw.pl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

gigo@ibbrain.ibb.waw.pl wrote:

>  Hi,
> I'm a newbie in this field, so my question will seem dummy for many,
> think. I've just compiled xfs into my kernel, because I need to operate
> on large data files. First thing I've done after mounting my new xfs was:
> > dd if=/dev/zero of=BIG_FILE
> Great. Now I have file, that I can not stat even (so rm does not work, he
> he). So, how can I use large files, since maximum filesize in linux is
> limited to 0x7fffffff ??? Just increasing this number in kernel sources
> isn't the best idea, is it ??? Thanks in advance,
> Grzegorz Wieczorek

How big is this file?
Linux  does support files larger than 2gig; (the traditional 2^31
limitation)

Please send more info, like size of file, output/errors from ls or rm.

-Russell



From owner-linux-xfs@oss.sgi.com Thu Oct 26 11:38:50 2000
Received:  by oss.sgi.com id <S553798AbQJZSik>;
	Thu, 26 Oct 2000 11:38:40 -0700
Received: from ibbrain.ibb.waw.pl ([212.87.28.4]:61478 "EHLO
        ibbrain.ibb.waw.pl") by oss.sgi.com with ESMTP id <S553794AbQJZSid>;
	Thu, 26 Oct 2000 11:38:33 -0700
Received: (from gigo@localhost)
	by ibbrain.ibb.waw.pl (SGI-8.9.3/8.9.3) id SAA06117;
	Thu, 26 Oct 2000 18:39:02 GMT
Date:   Thu, 26 Oct 2000 20:39:01 +0200 (MDT)
From:   gigo@ibbrain.ibb.waw.pl
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Large files
In-Reply-To: <39F86CEB.82360CC0@thebarn.com>
Message-ID: <Pine.SGI.3.91.1001026202559.204061A-100000@ibbrain.ibb.waw.pl>
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 Thu, 26 Oct 2000, Russell Cattelan wrote:

> 
> How big is this file?
> Linux  does support files larger than 2gig; (the traditional 2^31
> limitation)
> 
> Please send more info, like size of file, output/errors from ls or rm.
> 
> -Russell
> 

 Well, after reformatting my test partition ( it is 6Gb only ) I did the 
following:
> dd if=/dev/zero of=BIG_FILE bs=10M count=300
> df .
/dev/hdb1              6292648   3072144   3220504  49% /mnt/mnt1
> ls -l BIG_FILE
/bin/ls: BIG_FILE: Value too large for defined data type
> strace ls -l BIG_FILE
(...)
lstat("BIG_FILE", 0xbffffa88)           = -1 EOVERFLOW (Value too large for defi
ned data type)
>

When filesystem was created:
> /sbin/mkfs -t xfs -f /dev/hdb1
meta-data=/dev/hdb1              isize=256    agcount=8, agsize=196796 blks
data     =                       bsize=4096   blocks=1574362, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0 
>

Unfortunately it is an IDE disk...
In real life I have to work with files 8G...
Thank You for attention, Russel.
G.


From owner-linux-xfs@oss.sgi.com Thu Oct 26 12:19:30 2000
Received:  by oss.sgi.com id <S553800AbQJZTTK>;
	Thu, 26 Oct 2000 12:19:10 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38984 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553797AbQJZTSl>; Thu, 26 Oct 2000 12:18:41 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA08182
	for <linux-xfs@oss.sgi.com>; Thu, 26 Oct 2000 12:26:06 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA7312484; Thu, 26 Oct 2000 14:17:23 -0500 (CDT)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA35847; Thu, 26 Oct 2000 14:17:23 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e9QJHMk16429;
	Thu, 26 Oct 2000 14:17:22 -0500
Message-ID: <39F88340.74F0B7B8@thebarn.com>
Date:   Thu, 26 Oct 2000 14:17:20 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.4.0-whipme5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     gigo@ibbrain.ibb.waw.pl
CC:     linux-xfs@oss.sgi.com
Subject: Re: Large files
References: <Pine.SGI.3.91.1001026202559.204061A-100000@ibbrain.ibb.waw.pl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

gigo@ibbrain.ibb.waw.pl wrote:

This is probably a libc incompatibility, what Linux distribution are you running?

> On Thu, 26 Oct 2000, Russell Cattelan wrote:
>
> >
> > How big is this file?
> > Linux  does support files larger than 2gig; (the traditional 2^31
> > limitation)
> >
> > Please send more info, like size of file, output/errors from ls or rm.
> >
> > -Russell
> >
>
>  Well, after reformatting my test partition ( it is 6Gb only ) I did the
> following:
> > dd if=/dev/zero of=BIG_FILE bs=10M count=300
> > df .
> /dev/hdb1              6292648   3072144   3220504  49% /mnt/mnt1
> > ls -l BIG_FILE
> /bin/ls: BIG_FILE: Value too large for defined data type
> > strace ls -l BIG_FILE
> (...)
> lstat("BIG_FILE", 0xbffffa88)           = -1 EOVERFLOW (Value too large for defi
> ned data type)
> >
>
> When filesystem was created:
> > /sbin/mkfs -t xfs -f /dev/hdb1
> meta-data=/dev/hdb1              isize=256    agcount=8, agsize=196796 blks
> data     =                       bsize=4096   blocks=1574362, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal log           bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> >
>
> Unfortunately it is an IDE disk...
> In real life I have to work with files 8G...
> Thank You for attention, Russel.
> G.


From owner-linux-xfs@oss.sgi.com Thu Oct 26 13:32:12 2000
Received:  by oss.sgi.com id <S553811AbQJZUcB>;
	Thu, 26 Oct 2000 13:32:01 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:33614 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553807AbQJZUb4>;
	Thu, 26 Oct 2000 13:31:56 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA14268
	for <linux-xfs@oss.sgi.com>; Thu, 26 Oct 2000 13:24:08 -0700 (PDT)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA7433191; Thu, 26 Oct 2000 15:29:23 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA98377; Thu, 26 Oct 2000 15:29:22 -0500 (CDT)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id PAA00742;
	Thu, 26 Oct 2000 15:26:43 -0500
Message-Id: <200010262026.PAA00742@jen.americas.sgi.com>
To:     gigo@ibbrain.ibb.waw.pl
cc:     Russell Cattelan <cattelan@thebarn.com>, linux-xfs@oss.sgi.com
Subject: Re: Large files 
From:   lord@sgi.com
In-reply-to: Your message of "Thu, 26 Oct 2000 20:39:01 +0200
Date:   Thu, 26 Oct 2000 15:26:43 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


You need a glibc with the large file support included, and associated
unix utils. This is probably more to do with your linux distribution
than anything else.

I have created files with a size of 2^43 - 1 bytes on Redhat 6.2 and
7.0:


laptop{lord}: ls -l
total 4
-rw-r--r--    1 lord     lord     8796093022207 Oct 26 15:28 bigfile
laptop{lord}: uname -a
Linux laptop.americas.sgi.com 2.4.0-XFS-test10 #5 Thu Oct 26 14:33:44 CDT 2000 i686 unknown

Steve

> 
> 
> On Thu, 26 Oct 2000, Russell Cattelan wrote:
> 
> > 
> > How big is this file?
> > Linux  does support files larger than 2gig; (the traditional 2^31
> > limitation)
> > 
> > Please send more info, like size of file, output/errors from ls or rm.
> > 
> > -Russell
> > 
> 
>  Well, after reformatting my test partition ( it is 6Gb only ) I did the 
> following:
> > dd if=/dev/zero of=BIG_FILE bs=10M count=300
> > df .
> /dev/hdb1              6292648   3072144   3220504  49% /mnt/mnt1
> > ls -l BIG_FILE
> /bin/ls: BIG_FILE: Value too large for defined data type
> > strace ls -l BIG_FILE
> (...)
> lstat("BIG_FILE", 0xbffffa88)           = -1 EOVERFLOW (Value too large for d
efi
> ned data type)
> >
> 
> When filesystem was created:
> > /sbin/mkfs -t xfs -f /dev/hdb1
> meta-data=/dev/hdb1              isize=256    agcount=8, agsize=196796 blks
> data     =                       bsize=4096   blocks=1574362, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal log           bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0 
> >
> 
> Unfortunately it is an IDE disk...
> In real life I have to work with files 8G...
> Thank You for attention, Russel.
> G.

From owner-linux-xfs@oss.sgi.com Thu Oct 26 16:06:24 2000
Received:  by oss.sgi.com id <S553782AbQJZXGO>;
	Thu, 26 Oct 2000 16:06:14 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:1545 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553757AbQJZXF4>;
	Thu, 26 Oct 2000 16:05:56 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA12331
	for <linux-xfs@oss.sgi.com>; Thu, 26 Oct 2000 15:58:06 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA11505; Fri, 27 Oct 2000 10:03:22 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA95065; Fri, 27 Oct 2000 10:03:20 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10010271003.ZM95697@wobbly.melbourne.sgi.com>
Date:   Fri, 27 Oct 2000 10:03:19 -0400
In-Reply-To: "Stephen C. Tweedie" <sct@redhat.com>
        "Re: Quota mods needed for journaled quota" (Oct 26, 11:00am)
References: <20001025184239.U6085@redhat.com>  <sct@redhat.com> 
	<10010261253.ZM84523@wobbly.melbourne.sgi.com> 
	<20001026110029.K20050@redhat.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     "Stephen C. Tweedie" <sct@redhat.com>
Subject: Re: Quota mods needed for journaled quota
Cc:     Jan Kara <jack@suse.cz>, jank@redhat.com,
        Linus Torvalds <torvalds@transmeta.com>,
        linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-xfs@oss.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

hi Stephen,

On Oct 26, 11:00am, Stephen C. Tweedie wrote:
> Subject: Re: Quota mods needed for journaled quota
> ...
> > This would allow ext3 to do that which it needs to do differently
> > at Q_QUOTAON and would also allow Jan's changes to work in such
> > a way that both the current form of dquot structure and his new
> > version of dquots could be used together
> 
> Adding the init_quota hook would do that, as the filesystem will be
> able to install its own dq_ops methods during the init so we get the
> flexibility you are asking for anyway.
> 

Hmmm ... I'm not so sure.  In order to have the flexibility
of filesystem-specific dquot formats, the struct dquot would
need to become more like struct inode/super_block, i.e. not
hardcoding the ondisk structure into the incore structure
(using a union and a generic pointer, as inode/super_block do).

The DQUOT_SYNC mechanism would need to be able to be overridden
per-filesystem also.  It isn't really as cut-and-dried as "per-
filesystem" either, because an ext2/3 filesystem might make use
of either the original dquot format or Jan's newer format, either
at mount time or even after doing a quota_off & quota_on with a
new quota file format (that would be quite clean).

But I've sidetracked completely from what you were originally
talking about now, which had nothing to do with a different
ondisk format at all.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Fri Oct 27 05:31:19 2000
Received:  by oss.sgi.com id <S553785AbQJ0MbA>;
	Fri, 27 Oct 2000 05:31:00 -0700
Received: from ibbrain.ibb.waw.pl ([212.87.28.4]:21050 "EHLO
        ibbrain.ibb.waw.pl") by oss.sgi.com with ESMTP id <S553761AbQJ0Maj>;
	Fri, 27 Oct 2000 05:30:39 -0700
Received: (from gigo@localhost)
	by ibbrain.ibb.waw.pl (SGI-8.9.3/8.9.3) id MAA11232;
	Fri, 27 Oct 2000 12:30:58 GMT
Date:   Fri, 27 Oct 2000 14:30:57 +0200 (MDT)
From:   gigo@ibbrain.ibb.waw.pl
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Large files
In-Reply-To: <39F88340.74F0B7B8@thebarn.com>
Message-ID: <Pine.SGI.3.91.1001027142942.214398A-100000@ibbrain.ibb.waw.pl>
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 Thu, 26 Oct 2000, Russell Cattelan wrote:

> 
> This is probably a libc incompatibility, what Linux distribution are you running?
> 

Yeah. I have slackware 7.0. I'm compiling glibc right now. Thanks. G.

From owner-linux-xfs@oss.sgi.com Fri Oct 27 14:21:15 2000
Received:  by oss.sgi.com id <S553835AbQJ0VUz>;
	Fri, 27 Oct 2000 14:20:55 -0700
Received: from taz.cs.utah.edu ([155.99.203.51]:13851 "HELO taz.cs.utah.edu")
	by oss.sgi.com with SMTP id <S553832AbQJ0VU2>;
	Fri, 27 Oct 2000 14:20:28 -0700
Received: by taz.cs.utah.edu (Mailer, from userid 1363)
	id 33482B3928E; Fri, 27 Oct 2000 15:20:35 -0600 (MDT)
To:     linux-xfs@oss.sgi.com
Subject: Corrupt FS
Message-Id: <20001027212035.33482B3928E@taz.cs.utah.edu>
Date:   Fri, 27 Oct 2000 15:20:35 -0600 (MDT)
From:   sparker@cs.utah.edu (Steven G. Parker)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

I somehow managed to corrupt my 18 gig XFS filesystem.  It ran
fine for several months, but now it is quite trashed.  I filled it up
with a huge write() call, and then shortly thereafter things started
failing.  I got I/O error reading ".", and couldn't really do much
so I rebooted.

The first time I rebooted, it wouldn't mount the partition.  So I
ran xfs_check on it and got 485k lines of crud.  xfs_repair core
dumped in phase 3, agno = 0 after several "imap claims a free inode..."
and "bad version number 0x0..." and "bad magic number 0x0..." messages.

After subsequent reboots, I can now mount the filesystem, but xfs_repair
still dumps core.  The mounted filesystem has now lost much of it's
contents, and I get messages like this from ls:
ls: /home/sparker/News: No such file or directory

So the question is:  How can I turn this catastrophe into something
useful for the XFS team?  Do you want a copy of the filesystem image?
Will you be able to do anythign useful with it if I send it? It may take
me a few days to get it there, so could I give somebody an account on
this machine to poke at it?  Do you want the output of xfs_check?  

Please let me know how I can be useful.

Thanks,
Steve

From owner-linux-xfs@oss.sgi.com Mon Oct 30 01:37:51 2000
Received:  by oss.sgi.com id <S553844AbQJ3Jhm>;
	Mon, 30 Oct 2000 01:37:42 -0800
Received: from oe10.law10.hotmail.com ([64.4.14.114]:10501 "EHLO hotmail.com")
	by oss.sgi.com with ESMTP id <S553733AbQJ3Jh1>;
	Mon, 30 Oct 2000 01:37:27 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 30 Oct 2000 01:37:22 -0800
X-Originating-IP: [61.141.207.120]
From:   "yxy_oversea" <yxy_oversea@hotmail.com>
To:     <linux-xfs@oss.sgi.com>
Cc:     <majordomo@oss.sgi.com>
Subject: why xfs not supported here
Date:   Mon, 30 Oct 2000 17:34:52 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_0005_01C04297.B61E2E20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Message-ID: <OE10YBTUA93Nii59RkI00000bc6@hotmail.com>
X-OriginalArrivalTime: 30 Oct 2000 09:37:22.0429 (UTC) FILETIME=[0116AAD0:01C04255]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C04297.B61E2E20
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

DQpEZWFyIGZyaWVuZHM6DQogICAgVGhhbmtzIHZlcnkgbXVjaCB0byByZWFkIHRoaXMuDQoNCiAg
ICBJIGNhbid0IHVzZSB4ZnMgb24gbXkgY29tcHV0ZXIsIHdoeT8gZGV0YWlscyBmb2xsb3dlZDoN
Cg0KMS4gSSBpbnN0YWxsZWQgYSBSZWRIYXQgNi4yLCBubyBwcm9ibGVtIG9jY3VyOw0KMi4gZ290
IFByb1BhY2sxLjQuaXNvKDI4Mk0pIGZyb20gIGZ0cDovL3BhdGNoZXMuc2dpLmNvbS9wdWIvbGlu
dXgvUHJvUGFjazEuNC9JU08vLCBubyBwcm9ibGVtIG9jY3VyOw0KMy4gbW91bnQgLi9Qcm9QYWNr
MS40LmlzbyCoQ3QgaXNvOTY2MCCoQ28gbG9vcCAvbW50L2Nkcm9tLCBubyBwcm9ibGVtDQo0LiBj
ZCAvbW50L2Nkcm9tOyAuL0lOU1RBTEw7DQo1LiBjaG9vc2UgZm91ciBwYWNrYWdlIKGwUmVkSGF0
IFNwZWNpZmljobEsIKGwTXVsdGlwcm9jZXNzb3KhsSwgobBLZXJuZWwgRGV2ZWxvcG1lbnShsSwg
obBYRlMgQ29tbWFuZHOhsSB0byBpbnN0YWxsLCBubyBwcm9ibGVtIG9jY3VyOw0KNi4gcnVuIGNv
bW1hbmQgIyBta2ZzLnhmcyAvZGV2L2hkYTYsIGdvdCBlcnJvcjoNCm1rZnMueGZzOiB3YXJuaW5n
IC0gY2Fubm90IHNldCBibG9ja3NpemUgb24gYmxvY2sgZGV2aWNlIC9kZXYvaGRhNjogSW5wdXQv
b3V0cHV0IGVycm9yDQptZXRhLWRhdGE9L2Rldi9oZGE2ICAgICAgICAgICAgICBpc2l6ZT0yNTYg
ICAgYWdjb3VudD04LCBhZ3NpemU9MjIzMTUyIGJsa3MNCmRhdGEgICAgID0gICAgICAgICAgICAg
ICAgICAgICAgIGJzaXplPTQwOTYgICBibG9ja3M9MTc4NTIxNSwgaW1heHBjdD0yNQ0KICAgICAg
ICAgPSAgICAgICAgICAgICAgICAgICAgICAgc3VuaXQ9MCAgICAgIHN3aWR0aD0wIGJsa3MsIHVu
d3JpdHRlbj0wDQpuYW1pbmcgICA9dmVyc2lvbiAyICAgICAgICAgICAgICBic2l6ZT00MDk2DQps
b2cgICAgICA9aW50ZXJuYWwgbG9nICAgICAgICAgICBic2l6ZT00MDk2ICAgYmxvY2tzPTEyMDAN
CnJlYWx0aW1lID1ub25lICAgICAgICAgICAgICAgICAgIGV4dHN6PTY1NTM2ICBibG9ja3M9MCwg
cnRleHRlbnRzPTANCjcuIHJ1biBjb21tYW5kICMgbW91bnQgL2Rldi9oZGE2IKhDdCB4ZnMgL21u
dCwgZ290IGVycm9yOg0KbW91bnQ6IGZzIHR5cGUgeGZzIG5vdCBzdXBwb3J0ZWQgYnkga2VybmVs
DQoNCjguIENoZWNrIC9ldGMvbGlsby5jb25mLCAvYm9vdC92bWxpbnV6LTIuMi4xNi00U0dJXzM5
c21wIGlzIGFscmVhZHkgc3RhcnRlZC4NCjkuIENoZWNrIC9saWIvbW9kdWxlcy8yLjIuMTYtNFNH
SV8zOXNtcC9mcywgSSBmb3VuZCBubyB4ZnMuDQo/Pz8/IHdoYXQgaGFwcGVuZWQgPz8/Pw0KDQpC
dXQgSSBtdXN0IHVzZSB2ZXJ5IGxhcmdlIGZpbGVzIG9uIG15IExpbnV4LCB4ZnMgbWF5YmUgdGhl
IGJlc3QgY2hvaWNlLiBXaGF0IHNoYWxsIEkgZG8/DQpQbGVhc2UgaGVscCBtZSEgSSBhbSBzbyBh
bnhpb3VzLg0KDQpUaGFua3MuDQogICAgICAgICAgICB5YW5neHkgMjAwMC8xMC8zMA0KDQoNCg0K

------=_NextPart_000_0005_01C04297.B61E2E20
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi
MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w
MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E
WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+
DQo8RElWPjxGT05UIHNpemU9Mj5EZWFyIGZyaWVuZHM6PC9GT05UPjwvRElWPg0KPERJVj48Rk9O
VCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyB2ZXJ5IG11Y2ggdG8gcmVhZCB0aGlz
LjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJz
cDsmbmJzcDsmbmJzcDsgSSBjYW4ndCB1c2UgeGZzIG9uIG15IGNvbXB1dGVyLCANCndoeT8mbmJz
cDtkZXRhaWxzIGZvbGxvd2VkOjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW
PjxGT05UIHNpemU9Mj4xLiBJIGluc3RhbGxlZCBhIFJlZEhhdCA2LjIsIG5vIHByb2JsZW0gb2Nj
dXI7PEJSPjIuIGdvdCANClByb1BhY2sxLjQuaXNvKDI4Mk0pIGZyb20mbmJzcDsgPEEgDQpocmVm
PSJmdHA6Ly9wYXRjaGVzLnNnaS5jb20vcHViL2xpbnV4L1Byb1BhY2sxLjQvSVNPLyI+ZnRwOi8v
cGF0Y2hlcy5zZ2kuY29tL3B1Yi9saW51eC9Qcm9QYWNrMS40L0lTTy88L0E+LCANCm5vIHByb2Js
ZW0gb2NjdXI7PEJSPjMuIG1vdW50IC4vUHJvUGFjazEuNC5pc28gqEN0IGlzbzk2NjAgqENvIGxv
b3AgL21udC9jZHJvbSwgbm8gDQpwcm9ibGVtPEJSPjQuIGNkIC9tbnQvY2Ryb207IC4vSU5TVEFM
TDs8QlI+NS4gY2hvb3NlIGZvdXIgcGFja2FnZSChsFJlZEhhdCANClNwZWNpZmljobEsIKGwTXVs
dGlwcm9jZXNzb3KhsSwgobBLZXJuZWwgRGV2ZWxvcG1lbnShsSwgobBYRlMgQ29tbWFuZHOhsSB0
byBpbnN0YWxsLCBubyANCnByb2JsZW0gb2NjdXI7PEJSPjYuIHJ1biBjb21tYW5kICMgbWtmcy54
ZnMgL2Rldi9oZGE2LCBnb3QgZXJyb3I6PEJSPm1rZnMueGZzOiANCndhcm5pbmcgLSBjYW5ub3Qg
c2V0IGJsb2Nrc2l6ZSBvbiBibG9jayBkZXZpY2UgL2Rldi9oZGE2OiBJbnB1dC9vdXRwdXQgDQpl
cnJvcjxCUj5tZXRhLWRhdGE9L2Rldi9oZGE2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KaXNpemU9
MjU2Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFnY291bnQ9OCwgYWdzaXplPTIyMzE1MiANCmJsa3M8QlI+
ZGF0YSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCj0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpic2l6
ZT00MDk2Jm5ic3A7Jm5ic3A7IGJsb2Nrcz0xNzg1MjE1LCANCmltYXhwY3Q9MjU8QlI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPSZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyANCnN1bml0PTAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3dpZHRoPTAg
YmxrcywgDQp1bndyaXR0ZW49MDxCUj5uYW1pbmcmbmJzcDsmbmJzcDsgPXZlcnNpb24gDQoyJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KYnNpemU9NDA5NjxCUj5sb2cmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgPWludGVybmFsIA0KbG9nJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KYnNpemU9NDA5NiZuYnNwOyZuYnNwOyBi
bG9ja3M9MTIwMDxCUj5yZWFsdGltZSANCj1ub25lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KZXh0c3o9NjU1MzYmbmJzcDsgYmxvY2tzPTAsIHJ0
ZXh0ZW50cz0wPEJSPjcuIHJ1biBjb21tYW5kICMgbW91bnQgL2Rldi9oZGE2IKhDdCANCnhmcyAv
bW50LCBnb3QgZXJyb3I6PEJSPm1vdW50OiBmcyB0eXBlIHhmcyBub3Qgc3VwcG9ydGVkIGJ5IGtl
cm5lbDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj44
LiBDaGVjayAvZXRjL2xpbG8uY29uZiwgL2Jvb3Qvdm1saW51ei0yLjIuMTYtNFNHSV8zOXNtcCBp
cyANCmFscmVhZHkgc3RhcnRlZC48QlI+OS4gQ2hlY2sgL2xpYi9tb2R1bGVzLzIuMi4xNi00U0dJ
XzM5c21wL2ZzLCBJIGZvdW5kIG5vIA0KeGZzLjxCUj4/Pz8/IHdoYXQgaGFwcGVuZWQgPz8/Pzwv
Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5CdXQgSSBt
dXN0IHVzZSB2ZXJ5IGxhcmdlIGZpbGVzIG9uIG15IExpbnV4LCB4ZnMgbWF5YmUgdGhlIA0KYmVz
dCBjaG9pY2UuIFdoYXQgc2hhbGwgSSBkbz88QlI+UGxlYXNlIGhlbHAgbWUhIEkgYW0gc28gYW54
aW91cy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIA0Kc2l6ZT0yPjxCUj5UaGFua3MuPEJSPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO3lhbmd4eSANCjIwMDAvMTAvMzA8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNw
OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PEJSPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JPRFk+
PC9IVE1MPg0K

------=_NextPart_000_0005_01C04297.B61E2E20--

From owner-linux-xfs@oss.sgi.com Mon Oct 30 07:10:54 2000
Received:  by oss.sgi.com id <S553863AbQJ3PKo>;
	Mon, 30 Oct 2000 07:10:44 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:41590 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553860AbQJ3PKh>;
	Mon, 30 Oct 2000 07:10:37 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA01352; Mon, 30 Oct 2000 07:02:48 -0800 (PST)
	mail_from (lord@jen.americas.sgi.com)
Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA7477599; Mon, 30 Oct 2000 09:08:04 -0600 (CST)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA58592; Mon, 30 Oct 2000 09:08:04 -0600 (CST)
Received: from jen.americas.sgi.com (lord@localhost)
	by jen.americas.sgi.com (8.9.3/8.9.3) with ESMTP id JAA19739;
	Mon, 30 Oct 2000 09:04:47 -0600
Message-Id: <200010301504.JAA19739@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To:     "yxy_oversea" <yxy_oversea@hotmail.com>
cc:     linux-xfs@oss.sgi.com, majordomo@oss.sgi.com
Subject: Re: why xfs not supported here 
In-Reply-To: Message from "yxy_oversea" <yxy_oversea@hotmail.com> 
   of "Mon, 30 Oct 2000 17:34:52 +0800." <OE10YBTUA93Nii59RkI00000bc6@hotmail.com> 
Content-Transfer-Encoding: 8bit
Date:   Mon, 30 Oct 2000 09:04:47 -0600
From:   Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



yxy_oversea@hotmail.com said:
>> 8. Check /etc/lilo.conf, /boot/vmlinuz-2.2.16-4SGI_39smp is already
>> started. 9. Check /lib/modules/2.2.16-4SGI_39smp/fs, I found no xfs.
>> ???? what happened ???? 
>> But I must use very large files on my Linux,
>> xfs maybe the best choice. What shall I do? Please help me! I am so
>> anxious.

The xfs support is in the 2.4 kernel, not the 2.2 kernel - you need to install
the 2.4 kernel rpm and have your system boot this.

As for large file support, this tends to be more of an issue with glibc than
anything else. If glibc does not have large file support built in then
user space will not be able to access beyond 4 Gbytes of data in a file.
The glibc in Redhat 6.2 and beyond has the large file support built in.


Steve





From owner-linux-xfs@oss.sgi.com Mon Oct 30 09:11:05 2000
Received:  by oss.sgi.com id <S553872AbQJ3RKz>;
	Mon, 30 Oct 2000 09:10:55 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:17961 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553869AbQJ3RKe>;
	Mon, 30 Oct 2000 09:10:34 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA25060; Mon, 30 Oct 2000 09:02:45 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id JAA82563; Mon, 30 Oct 2000 09:08:48 -0800 (PST)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id JAA17626;
	Mon, 30 Oct 2000 09:07:30 -0800 (PST)
Date:   Mon, 30 Oct 2000 09:07:30 -0800 (PST)
Message-Id: <200010301707.JAA17626@info.engr.sgi.com>
X-Pv-Incident: 803884 
webPV:  fsgi604.americas.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (dxm@engr.sgi.com)
Subject: CLOSE 803884 - double-fault with HIGHMEM
To:     nb@sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=803884

*Status : closed                       Priority : 3                         
 Assigned Engineer : nb                Submitter : dxm                      
 Opened Date : 10/04/00               *Closed Date : 10/30/00               
*Fixed By : dxm                       *Fixed By Domain : engr               
*Modified Date : 10/30/00             *Modified User : dxm                  
*Modified User Domain : engr          *Fix Description :
==========================
ADDITIONAL INFORMATION (CLOSE)
From: dxm@engr (BugWorks)
Date: Oct 30 2000 09:07:30AM
==========================

This bug appears to have been fixed in the base linux
kernel. hoorah

From owner-linux-xfs@oss.sgi.com Mon Oct 30 16:00:02 2000
Received:  by oss.sgi.com id <S553905AbQJ3X7v>;
	Mon, 30 Oct 2000 15:59:51 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:831 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553900AbQJ3X7Z>; Mon, 30 Oct 2000 15:59:25 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA07392
	for <linux-xfs@oss.sgi.com>; Mon, 30 Oct 2000 16:03:52 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA45856
	for linux-xfs@oss.sgi.com; Tue, 31 Oct 2000 10:50:45 +1100 (EST)
Date:   Tue, 31 Oct 2000 10:50:45 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010302350.KAA45856@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - quota
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:77157a
Date:  Mon Oct 30 15:49:57 PST 2000
Workarea:  snort:/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/xfs_qm_syscalls.c - 1.44
	- tidy up some formatting.

linux/fs/xfs/xfs_quota_priv.h - 1.15
	- fix attempt to purge a vnode which has already been removed... was
	  causing panics on unmount, now passes thru a qa run cleanly with
	  quota enabled.


From owner-linux-xfs@oss.sgi.com Mon Oct 30 19:53:42 2000
Received:  by oss.sgi.com id <S553908AbQJaDxW>;
	Mon, 30 Oct 2000 19:53:22 -0800
Received: from oe29.law10.hotmail.com ([64.4.14.86]:44814 "EHLO hotmail.com")
	by oss.sgi.com with ESMTP id <S553721AbQJaDxM>;
	Mon, 30 Oct 2000 19:53:12 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 30 Oct 2000 19:53:07 -0800
X-Originating-IP: [61.141.207.120]
From:   "yxy_oversea" <yxy_oversea@hotmail.com>
To:     <linux-xfs@oss.sgi.com>
Cc:     <majordomo@oss.sgi.com>
References: <200010301504.JAA19739@jen.americas.sgi.com>
Subject: fseek64 failed
Date:   Tue, 31 Oct 2000 11:53:54 +0800
MIME-Version: 1.0
Content-Type: text/plain;	charset="gb2312"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Message-ID: <OE29cJse1fTvOSQeSOz000018bd@hotmail.com>
X-OriginalArrivalTime: 31 Oct 2000 03:53:07.0378 (UTC) FILETIME=[1421C120:01C042EE]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

RGVhciBmcmllbmRzOg0KDQogICAgVGhhbmtzIHZlcnkgbXVjaCB0byBhbnN3ZXIgbXkgcXVlc3Rp
b24gb2YgIndoeSB4ZnMgbm90IHN1cHBvcnRlZCBoZXJlIi4NCkZvbGxvdyB5b3Ugd29yZHMsIEkg
Y2hhbmdlIG15IGtlcm5lbCB0byAgMi40LjAtNFNHSV80NCwgdGhlbiBJIGNhbiB1c2UgeGZzIGZp
bGVzeXN0ZW0gYW5kIGNyZWF0ZSBmaWxlcyBsYXJnZXIgdGhhbiAyLjFHLiBTbyBncmVhdCwgdGhh
bmtzIQ0KDQogICAgQW5kIG5vdywgSSdtIGxvb2tpbmcgZm9yIHNvbWUgc3lzdGVtIGNhbGxzIHdo
aWNoIHN1cHBvcnQgbGFyZ2UgZmlsZSBJIA0KY2FuIHVzZSBpbiBjLXByb2dyYW1zLiBJIHVzZSBm
b3BlbjY0KCkgc3VjY2VzcywgYnV0IGZzZWVrNjQoKSBmYWlsLCBjb21waWxlIG9rLCBleGVjdXRl
IHJlc3VsdCBzYXlzIGZzZWVrNjQoKSB1c2UgIkludmFsaWQgYXJndW1lbnQiLiBJIHRoZW4gdHJp
ZWQgdGhhdCBhcmd1bWVudCB3aXRoIGZzZWVrKCkgYW5kIGZzZWVrbygpLCBpdCBzdWNjZWVkLg0K
DQogICAgTXkgcXVlc3Rpb24gaXM6IA0KICAgICAgICBIb3cgY2FuIEkgdXNlIGZzZWVrNjQoKSBz
dWNjZXNzZnVsbHk/DQogICAgICAgIElzIHRoZXJlIGFueSBjYWxsIGxpa2UgbHNlZWs2NCgpIGFz
IHRoYXQgaW4gSVJJWD8NCg0KICAgIFRoYW5rcy4NCg0KDQo=

From owner-linux-xfs@oss.sgi.com Tue Oct 31 07:25:59 2000
Received:  by oss.sgi.com id <S553735AbQJaPZt>;
	Tue, 31 Oct 2000 07:25:49 -0800
Received: from atrey.karlin.mff.cuni.cz ([195.113.31.123]:19726 "EHLO
        atrey.karlin.mff.cuni.cz") by oss.sgi.com with ESMTP
	id <S553698AbQJaPZf>; Tue, 31 Oct 2000 07:25:35 -0800
Received: (from jack@localhost)
	by atrey.karlin.mff.cuni.cz (8.8.8/8.8.8) id QAA21632;
	Tue, 31 Oct 2000 16:25:12 +0100
Date:   Tue, 31 Oct 2000 16:25:12 +0100
From:   Jan Kara <jack@suse.cz>
To:     Nathan Scott <nathans@wobbly.melbourne.sgi.com>
Cc:     "Stephen C. Tweedie" <sct@redhat.com>, Jan Kara <jack@suse.cz>,
        jank@redhat.com, Linus Torvalds <torvalds@transmeta.com>,
        linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-xfs@oss.sgi.com
Subject: Re: Quota mods needed for journaled quota
Message-ID: <20001031162512.E14635@atrey.karlin.mff.cuni.cz>
References: <20001025184239.U6085@redhat.com> <sct@redhat.com> <10010261253.ZM84523@wobbly.melbourne.sgi.com> <20001026110029.K20050@redhat.com> <sct@redhat.com> <10010271003.ZM95697@wobbly.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <10010271003.ZM95697@wobbly.melbourne.sgi.com>; from nathans@wobbly.melbourne.sgi.com on Fri, Oct 27, 2000 at 10:03:19AM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

  Hello.

> On Oct 26, 11:00am, Stephen C. Tweedie wrote:
> > Subject: Re: Quota mods needed for journaled quota
> > ...
> > > This would allow ext3 to do that which it needs to do differently
> > > at Q_QUOTAON and would also allow Jan's changes to work in such
> > > a way that both the current form of dquot structure and his new
> > > version of dquots could be used together
> > 
> > Adding the init_quota hook would do that, as the filesystem will be
> > able to install its own dq_ops methods during the init so we get the
> > flexibility you are asking for anyway.
> > 
> 
> Hmmm ... I'm not so sure.  In order to have the flexibility
> of filesystem-specific dquot formats, the struct dquot would
> need to become more like struct inode/super_block, i.e. not
> hardcoding the ondisk structure into the incore structure
> (using a union and a generic pointer, as inode/super_block do).
> 
> The DQUOT_SYNC mechanism would need to be able to be overridden
> per-filesystem also.  It isn't really as cut-and-dried as "per-
> filesystem" either, because an ext2/3 filesystem might make use
> of either the original dquot format or Jan's newer format, either
> at mount time or even after doing a quota_off & quota_on with a
> new quota file format (that would be quite clean).
  Hmm. Probably I wouldn't allow to override quotactl() but make it like
other callbacks - operations like quota_on() quota_off() and so
could be overridden (or better filesystem could specify callback to be called
after some generic work), quotactl() will call foo_quotactl() if it won't
recognize the operation number.
  But I don't feel urgent need of this redesign so I would wait for some
time so current fixes can settle down...

								Honza


From owner-linux-xfs@oss.sgi.com Tue Oct 31 11:21:41 2000
Received:  by oss.sgi.com id <S553898AbQJaTVb>;
	Tue, 31 Oct 2000 11:21:31 -0800
Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:478 "EHLO
        ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP
	id <S553753AbQJaTVP>; Tue, 31 Oct 2000 11:21:15 -0800
Received: from techno.informatik.uni-stuttgart.de (techno [129.69.218.24]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id UAA12818 for <linux-xfs@oss.sgi.com>; Tue, 31 Oct 2000 20:19:28 +0100 (MET)
Received: (from magallon@localhost) by techno.informatik.uni-stuttgart.de (8.9.3/2.2) id UAA26804 for linux-xfs@oss.sgi.com; Tue, 31 Oct 2000 20:21:11 +0100
Date:   Tue, 31 Oct 2000 20:21:11 +0100
From:   "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>
To:     linux-xfs@oss.sgi.com
Subject: stress scripts patches
Message-ID: <20001031202111.A26772@techno.informatik.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6"
Content-Disposition: inline
User-Agent: Mutt/1.1.14i
X-Operating-System: Linux techno 2.2.18pre17
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

    attached is a patch for the stress test scripts.  The first one (002)
 works arround a bug in bash (in case /bin/sh is bash) where it doesn't
 discard trailing whitespace when comparing two numbers.  lstat64 will
 always output a line containing "Links:", so $x should never be empty.

 The second one (004) adds a "_require_scratch" to the test, otherwise
 it fails when run as patch of a batch because the scratch partition is
 still mounted from the previous test.

 The last one was the product of me trying to figure out if a failure
 (see other email) was because of the script or a real failure.  It just
 moves the RESTORE_DIR and RESTORE_SUBDIR (this one is not really
 needed) to the top of the substitution list, otherwise you end up with
 something like "SCRATCH_MNT/some/random/directory".

 Thanks,

--
Marcelo

--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="stress.patch"

diff -ru /proj/marcelo/xfs/user-space/stress/002 ./002
--- /proj/marcelo/xfs/user-space/stress/002	Tue Oct 10 11:03:55 2000
+++ ./002	Tue Oct 31 12:15:53 2000
@@ -64,7 +64,7 @@
 do
     ln $TEST_DIR/$tmp.1 $TEST_DIR/$tmp.$l
     x=`src/lstat64 $TEST_DIR/$tmp.1 | sed -n -e '/ Links: /s/.*Links: *//p'`
-    if [ "$l" -ne "$x" ]
+    if [ "$l" -ne $x ]
     then
 	echo "Arrgh, created link #$l and lstat64 looks like ..."
 	src/lstat64 $TEST_DIR/$tmp.1
@@ -75,7 +75,7 @@
 for l in 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
 do
     x=`src/lstat64 $TEST_DIR/$tmp.1 | sed -n -e '/ Links: /s/.*Links: *//p'`
-    if [ "$l" -ne "$x" ]
+    if [ "$l" -ne $x ]
     then
 	echo "Arrgh, about to remove link #$l and lstat64 looks like ..."
 	src/lstat64 $TEST_DIR/$tmp.1
diff -ru /proj/marcelo/xfs/user-space/stress/004 ./004
--- /proj/marcelo/xfs/user-space/stress/004	Thu Oct 26 12:43:58 2000
+++ ./004	Tue Oct 31 12:18:56 2000
@@ -73,6 +73,7 @@
 . ./common.filter
 
 _need_to_be_root
+_require_scratch
 
 # real QA test starts here
 
diff -ru /proj/marcelo/xfs/user-space/stress/common.dump ./common.dump
--- /proj/marcelo/xfs/user-space/stress/common.dump	Thu Oct 26 12:43:58 2000
+++ ./common.dump	Tue Oct 31 13:30:02 2000
@@ -602,13 +602,13 @@
 {
   sed \
     -e "s#$dump_file#DUMP_FILE#"      \
+    -e "s#$restore_dir#RESTORE_DIR#g" \
+    -e "s#$restore_sdir#RESTORE_SUBDIR#g" \
     -e "s#$SCRATCH_DEV#SCRATCH_DEV#"        \
     -e "s#$dumptape#TAPE_DEV#"         \
     -e "s#$dump_dir#DUMP_DIR#g"       \
-    -e "s#$restore_dir#RESTORE_DIR#g" \
     -e "s#$SCRATCH_MNT#SCRATCH_MNT#g"       \
     -e "s#$dump_sdir#DUMP_SUBDIR#g"   \
-    -e "s#$restore_sdir#RESTORE_SUBDIR#g" \
 
 }
 

--IJpNTDwzlM2Ie8A6--

From owner-linux-xfs@oss.sgi.com Tue Oct 31 11:49:41 2000
Received:  by oss.sgi.com id <S553918AbQJaTtb>;
	Tue, 31 Oct 2000 11:49:31 -0800
Received: from ifi.informatik.uni-stuttgart.de ([129.69.211.1]:52704 "EHLO
        ifi.informatik.uni-stuttgart.de") by oss.sgi.com with ESMTP
	id <S553858AbQJaTtN>; Tue, 31 Oct 2000 11:49:13 -0800
Received: from techno.informatik.uni-stuttgart.de (techno [129.69.218.24]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id UAA13223 for <linux-xfs@oss.sgi.com>; Tue, 31 Oct 2000 20:47:27 +0100 (MET)
Received: (from magallon@localhost) by techno.informatik.uni-stuttgart.de (8.9.3/2.2) id UAA26925 for linux-xfs@oss.sgi.com; Tue, 31 Oct 2000 20:49:10 +0100
Date:   Tue, 31 Oct 2000 20:49:10 +0100
From:   "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>
To:     linux-xfs@oss.sgi.com
Subject: stress test failures
Message-ID: <20001031204910.B26772@techno.informatik.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.14i
X-Operating-System: Linux techno 2.2.18pre17
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

 I've been running the stress tests on a daily basis for a while now and
 most failures have dissapered lately.  A couple of them are errors in
 the test scripts, but I've got six that look like either errors in the
 xfs utils or actual failures.  They are tests 020, 026, 027, 028, 046
 and 047 (I haven't really checked the last two, I ran out of time) 
 
 020 isn't actually an issue, it just assumes /tmp is not an xfs
 partition (the test system only has xfs partitions, I could add ext2
 partitions, but I really need to take disks *out* of that system) and
 fails.

 026 fails with:

| Restoring from file...
| xfsrestore  -f DUMP_FILE  -L stress_026 RESTORE_DIR
| xfsrestore: version 3.0 - Running single-threaded
| xfsrestore: ERROR: could not map persistent state file hdr SCRATCH_MNT/restore.27046/xfsrestorehousekeepingdir/state: Invalid argument
 
 027:

| xfsdump|xfsrestore ...
| xfsdump  -s DUMP_SUBDIR - SCRATCH_MNT | xfsrestore  - RESTORE_DIR
| xfsrestore: version 3.0 - Running single-threaded
| xfsrestore: ERROR: could not map persistent state file hdr SCRATCH_MNT/restore.27323/xfsrestorehousekeepingdir/state: Invalid argument

 028:

| xfsdump: dump complete: SECS seconds elapsed
| xfsinvutil: error in mmap at 383 with errno 22 for file /var/xfsdump/inventory/b79bc4da-f1da-4adb-9976-09be3cef39a9.InvIndex
| xfsinvutil: abnormal termination
| mmap: Invalid argument

 046:

| Restoring from file...
| xfsrestore  -f DUMP_FILE  -L stress_046 RESTORE_DIR
| xfsrestore: version 3.0 - Running single-threaded
| xfsrestore: ERROR: could not map persistent state file hdr SCRATCH_MNT/restore.26844/xfsrestorehousekeepingdir/state: Invalid argument

 047:

| xfsdump: dump complete: SECS seconds elapsed
| xfsinvutil: error in mmap at 383 with errno 22 for file /var/xfsdump/inventory/aba05139-a42a-42fc-989b-965d98509c61.InvIndex xfsinvutil: abnormal termination
| mmap: Invalid argument

 libc is libc-2.1.3-154 (this is SuSE, I have no idea what that 154
 really means) and the kernel and xfs utils where pulled from cvs and
 compiled yesterday arround 2:00 UTC.

--
Marcelo

From owner-linux-xfs@oss.sgi.com Tue Oct 31 14:19:02 2000
Received:  by oss.sgi.com id <S553928AbQJaWSx>;
	Tue, 31 Oct 2000 14:18:53 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:6766 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553925AbQJaWSi>;
	Tue, 31 Oct 2000 14:18:38 -0800
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id OAA19257
	for <linux-xfs@oss.sgi.com>; Tue, 31 Oct 2000 14:10:47 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA15191; Wed, 1 Nov 2000 09:17:19 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA04461; Wed, 1 Nov 2000 09:17:03 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10011010917.ZM105071@wobbly.melbourne.sgi.com>
Date:   Wed, 1 Nov 2000 09:17:02 -0400
In-Reply-To: "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>
        "stress scripts patches" (Oct 31,  8:21pm)
References: <20001031202111.A26772@techno.informatik.uni-stuttgart.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>,
        tes@larry.melbourne.sgi.com, ivanr@larry.melbourne.sgi.com
Subject: Re: stress scripts patches
Cc:     linux-xfs@oss.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

hi Marcelo,

On Oct 31,  8:21pm, Marcelo E. Magallon wrote:
> Subject: stress scripts patches
> 
> Hi,
> 
>     attached is a patch for the stress test scripts.  The first one (002)

great - thanks.

>  works arround a bug in bash (in case /bin/sh is bash) where it doesn't
>  discard trailing whitespace when comparing two numbers.  lstat64 will
>  always output a line containing "Links:", so $x should never be empty.
> 

ok, fixed.

>  The second one (004) adds a "_require_scratch" to the test, otherwise
>  it fails when run as patch of a batch because the scratch partition is
>  still mounted from the previous test.
> 

fixed.

>  The last one was the product of me trying to figure out if a failure
>  (see other email) was because of the script or a real failure.  It just
>  moves the RESTORE_DIR and RESTORE_SUBDIR (this one is not really
>  needed) to the top of the substitution list, otherwise you end up with
>  something like "SCRATCH_MNT/some/random/directory".
> 

I'll leave this for Tim/Ivan to apply while they're looking
into the other dump/restore failures.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Tue Oct 31 14:20:23 2000
Received:  by oss.sgi.com id <S553930AbQJaWUD>;
	Tue, 31 Oct 2000 14:20:03 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:55406 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553927AbQJaWT7>;
	Tue, 31 Oct 2000 14:19:59 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA19620
	for <linux-xfs@oss.sgi.com>; Tue, 31 Oct 2000 14:12:09 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA62985
	for linux-xfs@oss.sgi.com; Wed, 1 Nov 2000 09:18:35 +1100 (EST)
Date:   Wed, 1 Nov 2000 09:18:35 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200010312218.JAA62985@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - stress
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

first couple of Marcelo's stress test fixes.


Modid:  2.4.x-xfs:slinx:77252a
Date:  Tue Oct 31 14:12:46 PST 2000
Workarea:  snort:/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/002 - 1.5
	- improve whitespace handling for bash.

cmd/xfs/stress/004 - 1.8
	- add _require_scratch call cos test requires a scratch dev.


From owner-linux-xfs@oss.sgi.com Tue Oct 31 16:49:56 2000
Received:  by oss.sgi.com id <S553929AbQKAAtq>;
	Tue, 31 Oct 2000 16:49:46 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33054 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553696AbQKAAtV>; Tue, 31 Oct 2000 16:49:21 -0800
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 QAA01172
	for <linux-xfs@oss.sgi.com>; Tue, 31 Oct 2000 16:53:23 -0800 (PST)
	mail_from (tes@boing.melbourne.sgi.com)
Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16388 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 1 Nov 2000 11:43:04 +1100
Received: (from tes@localhost) by boing.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA82839 for linux-xfs@oss.sgi.com; Wed, 1 Nov 2000 11:43:03 +1100 (EDT)
From:   tes@boing.melbourne.sgi.com (Timothy Shimmin)
Message-Id: <200011010043.LAA82839@boing.melbourne.sgi.com>
Subject: Re: stress scripts patches
To:     linux-xfs@oss.sgi.com
Date:   Wed, 1 Nov 2000 11:43:02 +1100 (EDT)
In-Reply-To: <20001031202111.A26772@techno.informatik.uni-stuttgart.de> from "Marcelo E. Magallon" at Oct 31, 2000 08:21:11 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Marcelo wrote:
>  The last one was the product of me trying to figure out if a failure
>  (see other email) was because of the script or a real failure.  It just
>  moves the RESTORE_DIR and RESTORE_SUBDIR (this one is not really
>  needed) to the top of the substitution list, otherwise you end up with
>  something like "SCRATCH_MNT/some/random/directory".
> 
I don't think your filter change has any use.
I presume this is what you meant by "this one is not really needed".


Consider:
    _dir_filter()
    {
      sed \
        -e "s#$dump_file#DUMP_FILE#"      \
        -e "s#$SCRATCH_DEV#SCRATCH_DEV#"        \
        -e "s#$dumptape#TAPE_DEV#"         \
        -e "s#$dump_dir#DUMP_DIR#g"       \
        -e "s#$restore_dir#RESTORE_DIR#g" \
        -e "s#$SCRATCH_MNT#SCRATCH_MNT#g"       \
        -e "s#$dump_sdir#DUMP_SUBDIR#g"   \
        -e "s#$restore_sdir#RESTORE_SUBDIR#g" \

    } 

Only DUMP_SUBDIR and RESTORE_SUBDIR are after SCRATCH_MNT.
And as you can see below, these are just one word relative
paths which don't include SCRATCH_MNT.

    dump_file=$tmp.dumpfile
    dump_dir=$SCRATCH_MNT/dump.$$
    restore_dir=$SCRATCH_MNT/restore.$$
    dump_sdir=dump.$$
    restore_sdir=restore.$$

The message you saw for the xfsrestore and xfsinvutil failure
has SCRATCH_MNT/restore......
because there is no attempt to filter it out (only see it on failure).
The filtering used after xfsdump/xfsrestore/xfsinvutil
is by _dump_filter.

Thanks.

Ciao,
Tim.

From owner-linux-xfs@oss.sgi.com Tue Oct 31 22:43:27 2000
Received:  by oss.sgi.com id <S553932AbQKAGnS>;
	Tue, 31 Oct 2000 22:43:18 -0800
Received: from oe43.law10.hotmail.com ([64.4.14.15]:33293 "EHLO hotmail.com")
	by oss.sgi.com with ESMTP id <S553922AbQKAGm7>;
	Tue, 31 Oct 2000 22:42:59 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 31 Oct 2000 22:42:52 -0800
X-Originating-IP: [61.141.207.120]
From:   "yxy_oversea" <yxy_oversea@hotmail.com>
To:     <linux-xfs@oss.sgi.com>
Subject: fseeko64() suspended
Date:   Wed, 1 Nov 2000 14:43:13 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_0031_01C04412.10253D70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Message-ID: <OE437hx27kBnccYTjr80000016f@hotmail.com>
X-OriginalArrivalTime: 01 Nov 2000 06:42:52.0144 (UTC) FILETIME=[F5237700:01C043CE]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01C04412.10253D70
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

RGVhciBmcmllbmRzOg0KICAgVGhhbmtzIGV2ZXJ5IG11Y2ggZm9yIHlvdXIga2luZG5lc3MsIG15
IHF1ZXN0aW9ucyB3ZXJlIGdyYWR1YWxseSBzb2x2ZWQgaGVyZS4NCg0KICAgTm93IEkgY2FuIHVz
ZSBmc2Vla282NCgpIG5vdywgYnV0IGluIGZhY3QgaXQgdGFrZXMgdmVyeSBsb25nIHRpbWUgDQpm
b3IgYSBmc2Vla282NCgpIGNhbGwgYXMgaWYgdGhlIGNhbGwgaXMgc3VzcGVuZGVkLiBEdXJpbmcg
dGhlIGNhbGwsDQprc3dhcGQgdXNlIENQVSBtYWRseSwgc3RhdGlzdGljcyBhcyBmb2xsb3dzOg0K
DQogIDI6MzBwbSAgdXAgIDM6MTcsICA0IHVzZXJzLCAgbG9hZCBhdmVyYWdlOiAwLjIzLCAwLjA1
LCAwLjAyDQo0NSBwcm9jZXNzZXM6IDQxIHNsZWVwaW5nLCA0IHJ1bm5pbmcsIDAgem9tYmllLCAw
IHN0b3BwZWQNCkNQVSBzdGF0ZXM6ICAxLjklIHVzZXIsIDk4LjAlIHN5c3RlbSwgIDAuMCUgbmlj
ZSwgIDAuMCUgaWRsZQ0KTWVtOiAgIDEyNjEwNEsgYXYsICAxMjM5OTJLIHVzZWQsICAgIDIxMTJL
IGZyZWUsICAgICAgIDBLIHNocmQsICAgIDY3ODBLIGJ1ZmYNClN3YXA6ICAgNTYxODhLIGF2LCAg
ICAgICAwSyB1c2VkLCAgIDU2MTg4SyBmcmVlICAgICAgICAgICAgICAgICAgIDk4NzA0SyBjYWNo
ZWQNCg0KICBQSUQgVVNFUiAgICAgUFJJICBOSSAgU0laRSAgUlNTIFNIQVJFIFNUQVQgIExJQiAl
Q1BVICVNRU0gICBUSU1FIENPTU1BTkQNCiAgICAzIHJvb3QgICAgICAxNyAgIDAgICAgIDAgICAg
MCAgICAgMCBSVyAgICAgIDAgOTAuMCAgMC4wICAgMzoxMiBrc3dhcGQNCiAyMTEyIHJvb3QgICAg
ICAgOSAgIDAgICA0MjggIDQyOCAgIDMwNCBSICAgICAgIDAgIDYuNyAgMC4zICAgMDowMCBhLm91
dA0KIDIxMTMgcm9vdCAgICAgIDEyICAgMCAgIDg3MiAgODcyICAgNjg0IFIgICAgICAgMCAgMy44
ICAwLjYgICAwOjAwIHRvcA0KICAgIDEgcm9vdCAgICAgICA4ICAgMCAgIDQ3NiAgNDc2ICAgNDA0
IFMgICAgICAgMCAgMC4wICAwLjMgICAwOjA1IGluaXQNCiAgICAyIHJvb3QgICAgICAgOSAgIDAg
ICAgIDAgICAgMCAgICAgMCBTVyAgICAgIDAgIDAuMCAgMC4wICAgMDowMCBrYXBtZA0KICAgIDQg
cm9vdCAgICAgICA5ICAgMCAgICAgMCAgICAwICAgICAwIFNXICAgICAgMCAgMC4wICAwLjAgICAw
OjAwIGtmbHVzaGQNCiAgICA1IHJvb3QgICAgICAgOSAgIDAgICAgIDAgICAgMCAgICAgMCBTVyAg
ICAgIDAgIDAuMCAgMC4wICAgMDowMyBrdXBkYXRlDQogICAgNiByb290ICAgICAgLTEgLTIwICAg
ICAwICAgIDAgICAgIDAgU1c8ICAgICAwICAwLjAgIDAuMCAgIDA6MDAgbWRyZWNvdmVyeWQNCiAg
IDE5IHJvb3QgICAgICAgOSAgIDAgICA1NDggIDU0OCAgIDQ1MiBTICAgICAgIDAgIDAuMCAgMC40
ICAgMDowMCBkZXZmc2QNCiAxMDI4IHJvb3QgICAgICAgOSAgIDAgICAgIDAgICAgMCAgICAgMCBT
VyAgICAgIDAgIDAuMCAgMC4wICAgMDowMCBwYWdlYnVmX2RhZW1vbg0KIDEwMjkgcm9vdCAgICAg
ICA5ICAgMCAgICAgMCAgICAwICAgICAwIFNXICAgICAgMCAgMC4wICAwLjAgICAwOjAwIHBhZ2Vf
ZGFlbW9uDQogMTI5MSBiaW4gICAgICAgIDkgICAwICAgNDk2ICA0OTYgICA0MDQgUyAgICAgICAw
ICAwLjAgIDAuMyAgIDA6MDAgcG9ydG1hcA0KIDEyOTEgYmluICAgICAgICA5ICAgMCAgIDQ5NiAg
NDk2ICAgNDA0IFMgICAgICAgMCAgMC4wICAwLjMgICAwOjAwIHBvcnRtYXANCiAxMzE0IHJvb3Qg
ICAgICAgOSAgIDAgICA1NjAgIDU2MCAgIDQ3MiBTICAgICAgIDAgIDAuMCAgMC40ICAgMDowMCBy
cGMuc3RhdGQNCiAxMzI4IHJvb3QgICAgICAgOSAgIDAgICA0ODAgIDQ4MCAgIDQxMiBTICAgICAg
IDAgIDAuMCAgMC4zICAgMDowMCBhcG1kDQogMTM4NCByb290ICAgICAgIDkgICAwICAgNTUyICA1
NTIgICA0NTIgUyAgICAgICAwICAwLjAgIDAuNCAgIDA6MDAgc3lzbG9nZA0KIDEzOTMgcm9vdCAg
ICAgICA5ICAgMCAgMTA4MCAxMDgwICAgMzg4IFMgICAgICAgMCAgMC4wICAwLjggICAwOjAwIGts
b2dkDQogMTQwNyBub2JvZHkgICAgIDkgICAwICAgNjI4ICA2MjggICA1MjAgUyAgICAgICAwICAw
LjAgIDAuNCAgIDA6MDAgaWRlbnRkDQoNCg0KICAgIGEub3V0IGlzIG15IHRlc3QgcHJvZ3JhbSwg
d2hpY2ggb3BlbnMgYSBiaWcgZmlsZSg0LjdHKSBvbiB4ZnMgZmlsZXN5c3RlbQ0KYnkgdXNpbmcg
Zm9wZW42NCgpOyBhbmQgdGhlbiB1c2UgZnNlZWtvNjQoKSB0byBsb2NhdGUgdG8gMi4xRy4gVGhl
IHN0YXRpc3RpY3MgDQppcyBnb3Qgd2hlbiB0aGUgcHJvZ3JhbSBleGVjdXRpbmcgZnNlZWtvNjQo
KSwgaXQgdG9vayBtb3JlIHRoYW4gMiBtaW51dGVzLiBBZnRlcg0KMiBtaW51dGVzLCB0aGUgY2Fs
bCByZXR1cm4gc3VjY2Vzc2Z1bGx5Lg0KDQogICAgTXkgcXVlc3Rpb25zIGFyZToNCiAgICAgICB3
aHkgaXQgdG9vayBzbyBtYW55IHRpbWUgZm9yIGEgc2VlayBjYWxsPyBJJ3YgbmV2ZXIgbWV0IGl0
IG9uIGV4dDIgb3IgeGZzDQpvbiBJUklYLg0KICAgICAgIHdoeSBrc3dhcGQgYXRlIGFsbCBteSBD
UFUgcmVzb3VyY2UgYW5kIG1lbW9yeSByZXNvdXJjZSB3aGVuIEkgY2FsbCBmc2Vla282NCgpPw0K
DQogICAgICAgTXkgZGVzdGluYXRpb24gaXMgdG8gdXNlIGJpZyBmaWxlcyBpbiBteSBwcm9ncmFt
LCBvcGVuL3JlYWQvc2VlaywgdmVyeSBzaW1wbGUNCm5lZWRzLCBidXQgaG93IGNhbiBJIGRvIHRo
aXM/DQoNCiAgICAgIFRoYW5rcyBhIGxvdCENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHlhbmd4eS4NCg0KICAgDQo=

------=_NextPart_000_0031_01C04412.10253D70
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi
MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w
MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E
WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5EZWFyIGZyaWVuZHM6PC9GT05U
PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7IFRoYW5rcyBldmVyeSBtdWNo
IGZvciB5b3VyIGtpbmRuZXNzLCZuYnNwO215IA0KcXVlc3Rpb25zIHdlcmUgZ3JhZHVhbGx5IHNv
bHZlZCBoZXJlLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp
emU9Mj4mbmJzcDsmbmJzcDsmbmJzcDtOb3cgSSBjYW4gdXNlIGZzZWVrbzY0KCkgbm93LCBidXQg
aW4gZmFjdCBpdCANCnRha2VzIHZlcnkgbG9uZyB0aW1lIDwvRk9OVD48L0RJVj4NCjxESVY+PEZP
TlQgc2l6ZT0yPmZvciBhIGZzZWVrbzY0KCkgY2FsbCBhcyBpZiB0aGUgY2FsbCBpcyBzdXNwZW5k
ZWQuIER1cmluZyB0aGUgDQpjYWxsLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmtz
d2FwZCB1c2UgQ1BVIG1hZGx5LCBzdGF0aXN0aWNzIGFzIGZvbGxvd3M6PC9GT05UPjwvRElWPg0K
PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyAyOjMwcG0mbmJzcDsg
dXAmbmJzcDsgMzoxNywmbmJzcDsgNCB1c2VycywmbmJzcDsgbG9hZCANCmF2ZXJhZ2U6IDAuMjMs
IDAuMDUsIDAuMDI8QlI+NDUgcHJvY2Vzc2VzOiA0MSBzbGVlcGluZywgNCBydW5uaW5nLCAwIHpv
bWJpZSwgMCANCnN0b3BwZWQ8QlI+Q1BVIHN0YXRlczombmJzcDsgMS45JSB1c2VyLCA5OC4wJSBz
eXN0ZW0sJm5ic3A7IDAuMCUgbmljZSwmbmJzcDsgDQowLjAlIGlkbGU8QlI+TWVtOiZuYnNwOyZu
YnNwOyAxMjYxMDRLIGF2LCZuYnNwOyAxMjM5OTJLIHVzZWQsJm5ic3A7Jm5ic3A7Jm5ic3A7IA0K
MjExMksgZnJlZSwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMEsgc2hyZCwm
bmJzcDsmbmJzcDsmbmJzcDsgNjc4MEsgDQpidWZmPEJSPlN3YXA6Jm5ic3A7Jm5ic3A7IDU2MTg4
SyBhdiwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMEsgDQp1c2VkLCZuYnNw
OyZuYnNwOyA1NjE4OEsgDQpmcmVlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IA0KOTg3MDRLIGNhY2hlZDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7
PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsgUElEIFVTRVImbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgUFJJJm5ic3A7IE5JJm5ic3A7IA0KU0laRSZuYnNwOyBSU1MgU0hBUkUgU1RBVCZu
YnNwOyBMSUIgJUNQVSAlTUVNJm5ic3A7Jm5ic3A7IFRJTUUgDQpDT01NQU5EPEJSPiZuYnNwOyZu
YnNwOyZuYnNwOyAzIHJvb3QmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQoxNyZuYnNw
OyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsmbmJzcDsgDQow
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAgUlcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgMCA5MC4wJm5ic3A7IA0KMC4wJm5ic3A7Jm5ic3A7IDM6MTIga3N3YXBkPEJSPiZuYnNwOzIx
MTIgDQpyb290Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDkmbmJzcDsmbmJz
cDsgMCZuYnNwOyZuYnNwOyA0MjgmbmJzcDsgDQo0MjgmbmJzcDsmbmJzcDsgMzA0IFImbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyA2LjcmbmJzcDsgDQowLjMmbmJz
cDsmbmJzcDsgMDowMCBhLm91dDxCUj4mbmJzcDsyMTEzIHJvb3QmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgDQoxMiZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7IDg3MiZuYnNwOyA4NzIm
bmJzcDsmbmJzcDsgNjg0IA0KUiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAw
Jm5ic3A7IDMuOCZuYnNwOyAwLjYmbmJzcDsmbmJzcDsgMDowMCANCnRvcDxCUj4mbmJzcDsmbmJz
cDsmbmJzcDsgMSByb290Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KOCZu
YnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7IDQ3NiZuYnNwOyA0NzYmbmJzcDsmbmJzcDsgNDA0IA0K
UyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7IDAuMCZuYnNwOyAw
LjMmbmJzcDsmbmJzcDsgMDowNSANCmluaXQ8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIgcm9vdCZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjkmbmJzcDsmbmJzcDsgMCZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMCZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyAwIFNXJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsgMC4w
Jm5ic3A7IA0KMC4wJm5ic3A7Jm5ic3A7IDA6MDAga2FwbWQ8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IDQgDQpyb290Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDkmbmJzcDsmbmJz
cDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjAmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAwIFNXJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K
MCZuYnNwOyAwLjAmbmJzcDsgMC4wJm5ic3A7Jm5ic3A7IDA6MDAga2ZsdXNoZDxCUj4mbmJzcDsm
bmJzcDsmbmJzcDsgNSANCnJvb3QmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
OSZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMCZuYnNwOyZuYnNwOyZu
YnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAgU1cmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgDQowJm5ic3A7IDAuMCZuYnNwOyAwLjAmbmJzcDsmbmJzcDsgMDowMyBrdXBkYXRl
PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyA2IA0Kcm9vdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAtMSAtMjAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQowJm5ic3A7Jm5ic3A7Jm5ic3A7
IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCBTVyZsdDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgDQowJm5ic3A7IDAuMCZuYnNwOyAwLjAmbmJzcDsmbmJzcDsgMDowMCBtZHJlY292ZXJ5ZDxC
Uj4mbmJzcDsmbmJzcDsgMTkgDQpyb290Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IDkmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyA1NDgmbmJzcDsgDQo1NDgmbmJzcDsmbmJz
cDsgNDUyIFMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyAwLjAm
bmJzcDsgDQowLjQmbmJzcDsmbmJzcDsgMDowMCBkZXZmc2Q8QlI+Jm5ic3A7MTAyOCANCnJvb3Qm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOSZuYnNwOyZuYnNwOyAwJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMCZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IDAgU1cmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQowJm5ic3A7IDAu
MCZuYnNwOyAwLjAmbmJzcDsmbmJzcDsgMDowMCBwYWdlYnVmX2RhZW1vbjxCUj4mbmJzcDsxMDI5
IA0Kcm9vdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA5Jm5ic3A7Jm5ic3A7
IDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQowJm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgMCBTVyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjAm
bmJzcDsgMC4wJm5ic3A7IDAuMCZuYnNwOyZuYnNwOyAwOjAwIHBhZ2VfZGFlbW9uPEJSPiZuYnNw
OzEyOTEgDQpiaW4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOSZu
YnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7IA0KNDk2Jm5ic3A7IDQ5NiZuYnNwOyZuYnNwOyA0MDQg
UyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7IA0KMC4wJm5ic3A7
IDAuMyZuYnNwOyZuYnNwOyAwOjAwIHBvcnRtYXA8QlI+Jm5ic3A7MTI5MSANCmJpbiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA5Jm5ic3A7Jm5ic3A7IDAmbmJzcDsm
bmJzcDsgDQo0OTYmbmJzcDsgNDk2Jm5ic3A7Jm5ic3A7IDQwNCBTJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJzcDsgDQowLjAmbmJzcDsgMC4zJm5ic3A7Jm5ic3A7IDA6
MDAgcG9ydG1hcDxCUj4mbmJzcDsxMzE0IA0Kcm9vdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyA5Jm5ic3A7Jm5ic3A7IDAmbmJzcDsmbmJzcDsgNTYwJm5ic3A7IA0KNTYwJm5i
c3A7Jm5ic3A7IDQ3MiBTJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAmbmJz
cDsgMC4wJm5ic3A7IA0KMC40Jm5ic3A7Jm5ic3A7IDA6MDAgcnBjLnN0YXRkPEJSPiZuYnNwOzEz
MjggDQpyb290Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDkmbmJzcDsmbmJz
cDsgMCZuYnNwOyZuYnNwOyA0ODAmbmJzcDsgDQo0ODAmbmJzcDsmbmJzcDsgNDEyIFMmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyAwLjAmbmJzcDsgDQowLjMmbmJz
cDsmbmJzcDsgMDowMCBhcG1kPEJSPiZuYnNwOzEzODQgcm9vdCZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyANCjkmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyA1NTImbmJzcDsg
NTUyJm5ic3A7Jm5ic3A7IDQ1MiANClMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgMCZuYnNwOyAwLjAmbmJzcDsgMC40Jm5ic3A7Jm5ic3A7IDA6MDAgDQpzeXNsb2dkPEJSPiZu
YnNwOzEzOTMgcm9vdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA5Jm5ic3A7
Jm5ic3A7IA0KMCZuYnNwOyAxMDgwIDEwODAmbmJzcDsmbmJzcDsgMzg4IFMmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyANCjAuMCZuYnNwOyAwLjgmbmJzcDsmbmJz
cDsgMDowMCBrbG9nZDxCUj4mbmJzcDsxNDA3IA0Kbm9ib2R5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IDkmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyA2MjgmbmJzcDsgDQo2MjgmbmJzcDsmbmJz
cDsgNTIwIFMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyAwLjAm
bmJzcDsgDQowLjQmbmJzcDsmbmJzcDsgMDowMCBpZGVudGQ8QlI+PC9GT05UPjwvRElWPg0KPERJ
Vj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyBhLm91
dCBpcyZuYnNwO215IHRlc3QgcHJvZ3JhbSwgDQp3aGljaCZuYnNwO29wZW5zIGEgYmlnIGZpbGUo
NC43Rykgb24geGZzIGZpbGVzeXN0ZW08L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5i
eSB1c2luZyBmb3BlbjY0KCk7IDwvRk9OVD48Rk9OVCBzaXplPTI+YW5kIHRoZW4gdXNlIA0KZnNl
ZWtvNjQoKSB0byBsb2NhdGUgdG8gMi4xRy4gVGhlIHN0YXRpc3RpY3MgPC9GT05UPjwvRElWPg0K
PERJVj48Rk9OVCBzaXplPTI+aXMgZ290IHdoZW4gdGhlIHByb2dyYW0gZXhlY3V0aW5nIGZzZWVr
bzY0KCksIGl0IHRvb2sgbW9yZSANCnRoYW4gMiBtaW51dGVzLiBBZnRlcjwvRk9OVD48L0RJVj4N
CjxESVY+PEZPTlQgc2l6ZT0yPjIgbWludXRlcywgdGhlIGNhbGwgcmV0dXJuIHN1Y2Nlc3NmdWxs
eS48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7IE15IHF1ZXN0aW9ucyBhcmU6PC9GT05UPjwvRElWPg0KPERJVj48Rk9O
VCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoeSBpdCB0b29r
IHNvIG1hbnkgdGltZSANCmZvciBhIHNlZWsgY2FsbD8gSSd2IG5ldmVyIG1ldCBpdCBvbiBleHQy
IG9yIHhmczwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPm9uIElSSVguPC9GT05UPjwv
RElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHdoeSBrc3dhcGQgYXRlIGFsbCBteSBDUFUgDQpyZXNvdXJjZSBhbmQgbWVtb3J5IHJlc291
cmNlIHdoZW4gSSBjYWxsIGZzZWVrbzY0KCk/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ
Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBNeSBkZXN0aW5hdGlvbiBpcyB0byB1c2UgDQpiaWcgZmlsZXMgaW4gbXkgcHJvZ3JhbSwgb3Bl
bi9yZWFkL3NlZWssIHZlcnkgc2ltcGxlPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+
bmVlZHMsIGJ1dCBob3cgY2FuIEkgZG8gdGhpcz88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwv
RElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo
YW5rcyBhIGxvdCE8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIA0Kc2l6ZT0yPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnlhbmd4eS48L0ZPTlQ+PC9ESVY+DQo8RElW
PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7IDwvRk9OVD48L0RJ
Vj48L0JPRFk+PC9IVE1MPg0K

------=_NextPart_000_0031_01C04412.10253D70--