From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:10 2000
Received:  by oss.sgi.com id <S305159AbQDYSzw>;
	Tue, 25 Apr 2000 11:55:52 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:30064 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305157AbQDYSzg>;
	Tue, 25 Apr 2000 11:55:36 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA29722
	for <linux-xfs@oss.sgi.com>; Tue, 25 Apr 2000 11:50:50 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA13017 for <linux-xfs@oss.sgi.com>; Tue, 25 Apr 2000 13:53:04 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA14964 for <linux-xfs@oss.sgi.com>; Tue, 25 Apr 2000 13:52:56 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id NAA21757; Tue, 25 Apr 2000 13:53:03 -0500
Date:   Tue, 25 Apr 2000 13:52:57 -0500
Message-ID: <14597.59785.326824.27143Y@gibble.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: CVS tree up to date again.
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Mime-Version: 1.0 (generated by tm-edit 7.108)
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

There was a small break down in the automated chain that pushes the
cvs tree out to oss. There was a route change that caused one of the rsh's
to fail since the host name didn't match the the entire in the .rhost file.


The cvs tree should be update on an hourly basis again.

-Russell



From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:10 2000
Received:  by oss.sgi.com id <S305165AbQDYXHQ>;
	Tue, 25 Apr 2000 16:07:16 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:8501 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305157AbQDYXHA>; Tue, 25 Apr 2000 16:07:00 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA02741
	for <linux-xfs@oss.sgi.com>; Tue, 25 Apr 2000 16:11:03 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA77146; Tue, 25 Apr 2000 18:05:39 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id SAA25046; Tue, 25 Apr 2000 18:05:30 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id SAA22089; Tue, 25 Apr 2000 18:05:37 -0500
Date:   Tue, 25 Apr 2000 18:05:35 -0500
Message-ID: <14598.9407.127158.25959D@gibble.americas.sgi.com>
To:     Kip_Macy@Maxtor.com
CC:     linux-xfs@oss.sgi.com
Subject: RE: assertion failure in xfs_vnode.c:890
In-Reply-To: In your message of "Tue, 25 Apr 2000 16:33:31 -0600"
	<09D1E9BD9C30D311919200A0C9DD5C2C016226F8@mcaexc01.msj.maxtor.com>
References: <09D1E9BD9C30D311919200A0C9DD5C2C016226F8@mcaexc01.msj.maxtor.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Mime-Version: 1.0 (generated by tm-edit 7.108)
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 Tue, 25 Apr 2000 16:33:31 -0600,
Macy, Kip <Kip_Macy@Maxtor.com> wrote:
> 
> 
> [1  <text/plain; iso-8859-1 (7bit)>]
> You will have to excuse me for being a bit slow - but what is different
> about XFS that
> makes it necessary for the Linux inode to know about the xfs vnode? I don't
> believe that
> any of the other file systems that Linux supports require that violation of
> the abstraction
> barrier. 
I breaks down to a simple answer and a complicated one.
XFS was written on a vnode based system,  linux on the other hand has
something of it's own abstraction layer; the linux inode.

The way thing currently operate XFS allocates a vnode whenever a file
is looked up, a back pointer is set up to reference the linux inode, 
finally an xfs inode is created with the vnode pointing at it.

There are several reasons for this: First 
XFS references members of the structure vnode_t throught the code,
changing everything to reference something different (say the linux
inode) requires A-LOT of work. (look at xfs_buf.h, which was done to 
remove the buf_t).
Second vnode's are where the VOP_<calls> exist, which is how
stackable file-system hook together; a requirement for CXFS.

The linvfs stuff was created to bridge the linux
fs independent layer and a vnode based independent layer. But as you 
can see adding another layer isn't without it problems.

Fixing this count problem is high on the priority list. In
looking at the problem we have discovered it will involve "major
surgery" to fix. 

-Russell 
> 
> Thanks.
> 
> 
> 							-Kip
> 
> 
> -----Original Message-----
> From: Russell Cattelan [mailto:cattelan@thebarn.com]
> Sent: Monday, April 24, 2000 11:32 PM
> To: Macy, Kip
> Cc: 'linux-xfs@oss.sgi.com'
> Subject: Re: assertion failure in xfs_vnode.c:890
> 
> 
> "Macy, Kip" wrote:
> 
> >
> >
> > The following just occurred when trying to mount an XFS partition over
> > NFS (on the local
> > machine). This is the most recent source.
> >
> > XFS assertion failed:vp->v_count > 0, file: xfs_vnode.c:890
> 
> Yup this is know problem.
> The problem occurs when ever the linux inode reference count gets
> bumped,
> iget does not  communicate down to the xfs vnode if the count it already
> 1 or greater
> that the count has been incremented
> iput  on the other hand will always communicate down  to decrement the
> count thus giving us a v_count of 0 when it should be at least one.
> 
> We are currently talking about how to fix this problem; which involves
> trying to merge the linux inode and the xfs vnode... which should prove
> to be a lot of work. :-(
> 
> > ...
> > kernel BUG at xfs_debug.c:86!
> > due to panic@0xc01e2ef9
> >
> > kdb> bt
> >
> > assfail
> > vn_rele
> > linvfs_put_inode
> > iput
> > nfsd_iget
> > find_fh_dentry
> > fh_verify
> > nfsd_statfs
> > nfsd_proc_statfs
> > nfsd_dispatch
> > svc_process
> > nfsd
> > kernel_thread
> 
> --
> Russell Cattelan
> cattelan@thebarn.com
> 
> 
> [2  <text/html; iso-8859-1 (quoted-printable)>]

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:10 2000
Received:  by oss.sgi.com id <S305166AbQDYXNq>;
	Tue, 25 Apr 2000 16:13:46 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:46901 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305157AbQDYXNc>; Tue, 25 Apr 2000 16:13:32 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA08871
	for <linux-xfs@oss.sgi.com>; Tue, 25 Apr 2000 16:17:40 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA53931; Tue, 25 Apr 2000 18:12:16 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id SAA25174; Tue, 25 Apr 2000 18:12:06 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id SAA22097; Tue, 25 Apr 2000 18:11:47 -0500
Date:   Tue, 25 Apr 2000 18:11:44 -0500
Message-ID: <14598.9776.784148.99788R@gibble.americas.sgi.com>
To:     ananth@sgi.com
Cc:     linux-xfs@oss.sgi.com
Subject: Re: mkfs output
In-Reply-To: In your message of "Tue, 25 Apr 2000 15:20:23 -0700"
	<39061A27.E3DEA363@sgi.com>
References: <39061A27.E3DEA363@sgi.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Mime-Version: 1.0 (generated by tm-edit 7.108)
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


Yup that is a standard log size... 
I am running with that now.

I have 5 source tree's on one xfs file system all running 
make clean depend bzImage modules

Plus I have your doio test running another file system, sucking down 
all my memory I might add.
  6:11pm  up 4 days, 45 min,  5 users,  load average: 8.64, 6.57, 4.82
81 processes: 74 sleeping, 7 running, 0 zombie, 0 stopped
CPU states: 41.5% user, 58.4% system,  0.0% nice,  0.0% idle
Mem:   126116K av,  124060K used,    2056K free,       0K shrd,     256K buff
Swap:  136512K av,   24748K used,  111764K free                   75112K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
22553 cattelan  15   0  167M 167M  167M R       0 18.4 136.1  69:22 doio
22554 cattelan  15   0  165M 165M  165M R       0 18.4 134.2  69:23 doio
27382 cattelan   2   0   444  444   304 R       0  3.7  0.3   0:00 mkdep
27385 cattelan   2   0   472  472   332 R       0  3.4  0.3   0:00 mkdep
27392 cattelan   3   0  1456 1456   464 S       0  3.4  1.1   0:00 make
27387 cattelan   1   0   448  448   308 D       0  3.0  0.3   0:00 mkdep
27409 cattelan   9   0  1280 1280   464 S       0  2.0  1.0   0:00 make
    3 root       2   0     0    0     0 SW      0  1.6  0.0   4:04 kflushd
    2 root       0   0     0    0     0 DW      0  1.5  0.0   1:14 kswapd
27415 cattelan  19   0  1276 1276   440 R       0  1.5  1.0   0:00 make


So far I haven't seen any pb_hold counts < 2 messages.

At Tue, 25 Apr 2000 15:20:23 -0700,
Rajagopal Ananthanarayanan <ananth@sgi.com> wrote:
> 
> 
> 
> As suggested in the meeting:
> 
> ---------
> /sbin/mkfs_xfs -f -b size=4096 /dev/sdb1
> meta-data=/dev/sdb1              isize=256    agcount=8, agsize=131030 blks
> data     =                       bsize=4096   blocks=1048233, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=1
> naming   =version 2              bsize=4096
> log      =internal log           bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> arch     =1                                   mode=NATIVE, SIM MODE=NATIVE 
> --------------------
> 
>            
> --------------------------------------------------------------------------
> Rajagopal Ananthanarayanan ("ananth")
> Member Technical Staff, SGI.
> --------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:10 2000
Received:  by oss.sgi.com id <S305177AbQDYXX1>;
	Tue, 25 Apr 2000 16:23:27 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:27958 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305157AbQDYXXE>; Tue, 25 Apr 2000 16:23:04 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA06216
	for <linux-xfs@oss.sgi.com>; Tue, 25 Apr 2000 16:27:11 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA23388 for <linux-xfs@oss.sgi.com>; Tue, 25 Apr 2000 18:21:47 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id SAA25422 for <linux-xfs@oss.sgi.com>; Tue, 25 Apr 2000 18:21:39 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id SAA22104; Tue, 25 Apr 2000 18:21:46 -0500
Date:   Tue, 25 Apr 2000 18:21:44 -0500
Message-ID: <14598.10376.52500.2586A@gibble.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: Manpages
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Mime-Version: 1.0 (generated by tm-edit 7.108)
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

FYI 
I put the xfs manpages on the web site.

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

These are the irix manpages and have not been updated
to reflect any changes to the linux version of the commands.
But it is a good reference none the less.


-Russell

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:11 2000
Received:  by oss.sgi.com id <S305178AbQDZCEI>;
	Tue, 25 Apr 2000 19:04:08 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:9050 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305157AbQDZCDo>;
	Tue, 25 Apr 2000 19:03:44 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA14789
	for <linux-xfs@oss.sgi.com>; Tue, 25 Apr 2000 18:58:58 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id VAA25807; Tue, 25 Apr 2000 21:01:11 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id VAA28120; Tue, 25 Apr 2000 21:01:03 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id VAA73431; Tue, 25 Apr 2000 21:01:10 -0500 (CDT)
Message-Id: <200004260201.VAA73431@tiki.americas.sgi.com>
Date:   Tue, 25 Apr 2000 21:01:10 -0500 (CDT)
To:     slinx-xfs@engr.sgi.com, linux-xfs@oss.sgi.com
Subject: TAKE - Fix missing trace entry in vntrace.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

The AtomicIncWithWrap() routine was returning the post-
increment value, it's supposed to return pre-increment.

This only affects vnode tracing & AG selection.

Modid:  2.3.99pre2-xfs:slinx:59815a
Date:  Tue Apr 25 18:58:14 PDT 2000
Workarea:  tiki.americas.sgi.com:/data/clink/io/jtk/work-linux2.3-99

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

linux/fs/xfs/linux/xfs_sema.h - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_sema.h.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
	- Fix the return value provided by atomicIncWithWrap().


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:11 2000
Received:  by oss.sgi.com id <S305179AbQDZCqj>;
	Tue, 25 Apr 2000 19:46:39 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:43106 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305157AbQDZCqX>;
	Tue, 25 Apr 2000 19:46:23 -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 TAA17683
	for <linux-xfs@oss.sgi.com>; Tue, 25 Apr 2000 19:41:30 -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 MAA01451; Wed, 26 Apr 2000 12:44:47 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id MAA23361; Wed, 26 Apr 2000 12:44:43 +1000 (EST)
Message-Id: <200004260244.MAA23361@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
cc:     Russell Cattelan <cattelan@thebarn.com>
Subject: Re: NULL dereference on mount 
In-reply-to: Your message of "Thu, 20 Apr 2000 02:14:14 EST."
             <38FEAE45.F6D83F4A@thebarn.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 26 Apr 2000 12:44:43 +1000
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:
 => Daniel Moore wrote:

 => > Anyway, there it is. Anyone have any thoughts?
 => 
 => Yup, I've been looking into this.
 => What are you doing to blow the 128k  cache?

To test other changes I've been making, I've been doing nasty
things like making 20000 files and then unlinking every second
one, then unmounting and remounting.

 => A "clean" file-system shouldn't be in reovery code, you must
 => have crashed the system at some point.

To check that a FS is clean, the head and tail of the log need
to be located. xlog_recover gets called, and from it xlog_find_tail
and xlog_find_head get called.

Once the head and tail are located, the cleanliness of the FS
is known, but the log needs to be checked to find the ends...

 => kmalloc failures are a know problem...

yup. 

-----------------------------------------------------
 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 May  2 15:53:11 2000
Received:  by oss.sgi.com id <S305188AbQDZP00>;
	Wed, 26 Apr 2000 08:26:26 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:14921 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305182AbQDZP0D>;
	Wed, 26 Apr 2000 08:26:03 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA07963
	for <linux-xfs@oss.sgi.com>; Wed, 26 Apr 2000 08:21:16 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA84035; Wed, 26 Apr 2000 10:23:30 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id KAA21789; Wed, 26 Apr 2000 10:23:22 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id KAA23640; Wed, 26 Apr 2000 10:23:29 -0500
Date:   Wed, 26 Apr 2000 10:23:27 -0500
Message-ID: <14599.2543.798830.22528W@gibble.americas.sgi.com>
To:     ananth@madurai.engr.sgi.com
Cc:     linux-xfs@oss.sgi.com
nSubject: Re: Likely source of corruption
In-Reply-To: In your message of "Wed, 26 Apr 100 00:43:16 -0700 (PDT)"
	<200004260743.AAA42400@madurai.engr.sgi.com>
References: <200004260743.AAA42400@madurai.engr.sgi.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Mime-Version: 1.0 (generated by tm-edit 7.108)
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 Wed, 26 Apr 100 00:43:16 -0700 (PDT),
Ananth Ananthanarayanan <ananth@madurai.engr.sgi.com> wrote:
> 
> 
> 
> Here are my findings in an effort to track down the corruption.
> 
> I backed up all the way to a tree as of 3/30/2000.6:00.
> You can do that sort of thing with '-t' option to p_tupdate.
> This is the time I know kernel compilation was working fine
> when PAGEBUF_META was off.
> 
> However, today I tried 3/30/2000 with PAGEBUF_META turned on,
> and the corruption showed up.  With the config turned off as
> I tried about 4 weeks back, the corruption went away.
> 
> Switching to my tot workarea with page-cleaner stuff compiled in,
> but run-time turned off, and with PAGEBUF_META off,
> I can now compile the kernel again. 
> 
> So there is a strong correlation between PAGEBUF_META and corruption.
> My own hunch is that either the 'block no' calculation in
> pagebuf is wrong, or the 'rele/hold problem' is doing an I/O
> when it shouldn't be.
> 
> Suggestion #1 is to ensure that the kernel compiles cleanly
> in several tries with a tot kernel and PAGEBUF_META off.
> 
> I'm likely going back to working on delalloc tomorrow,
> 
> ananth.

Hmm very odd. 
So if the block number was wrong on a meta data write, thus 
possibly dropping meta data into file data, the data in
the file should be meta data... which it doesn't seem to be.

A hold/rele shouldn't be dropping data in a file either, corrupting
the meta data aspect of the file system maybe?

Hmm very strange...

BTW the a 2 thread version of doio ran all night! 
I also ran 5 compiles at the same time on a different file system
(same system) they all ran to completion.

I also haven't seem any pb_hold count to low messages.


-Russell





From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:11 2000
Received:  by oss.sgi.com id <S305198AbQDZRVS>;
	Wed, 26 Apr 2000 10:21:18 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:48744 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305182AbQDZRVC>;
	Wed, 26 Apr 2000 10:21:02 -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 KAA23590
	for <linux-xfs@oss.sgi.com>; Wed, 26 Apr 2000 10:16:16 -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 KAA38972; Wed, 26 Apr 2000 10:18:24 -0700 (PDT)
Message-ID: <39072505.35775DAD@sgi.com>
Date:   Wed, 26 Apr 2000 10:19:01 -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:     cattelan@thebarn.com
CC:     linux-xfs@oss.sgi.com
Subject: Re: corruption
References: <200004260743.AAA42400@madurai.engr.sgi.com> <14599.2543.798830.22528W@gibble.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

cattelan@thebarn.com wrote:
> 
> At Wed, 26 Apr 100 00:43:16 -0700 (PDT),
> Ananth Ananthanarayanan <ananth@madurai.engr.sgi.com> wrote:
> >
> >
> >
> > Here are my findings in an effort to track down the corruption.
> >
> > I backed up all the way to a tree as of 3/30/2000.6:00.
> > You can do that sort of thing with '-t' option to p_tupdate.
> > This is the time I know kernel compilation was working fine
> > when PAGEBUF_META was off.
> >
> > However, today I tried 3/30/2000 with PAGEBUF_META turned on,
> > and the corruption showed up.  With the config turned off as
> > I tried about 4 weeks back, the corruption went away.
> >
> > Switching to my tot workarea with page-cleaner stuff compiled in,
> > but run-time turned off, and with PAGEBUF_META off,
> > I can now compile the kernel again.
> >
> > So there is a strong correlation between PAGEBUF_META and corruption.
> > My own hunch is that either the 'block no' calculation in
> > pagebuf is wrong, or the 'rele/hold problem' is doing an I/O
> > when it shouldn't be.
> >
> > Suggestion #1 is to ensure that the kernel compiles cleanly
> > in several tries with a tot kernel and PAGEBUF_META off.
> >
> > I'm likely going back to working on delalloc tomorrow,
> >
> > ananth.
> 
> Hmm very odd.
> So if the block number was wrong on a meta data write, thus
> possibly dropping meta data into file data, the data in
> the file should be meta data... which it doesn't seem to be.

You're right on that aspect.

> 
> A hold/rele shouldn't be dropping data in a file either, corrupting
> the meta data aspect of the file system maybe?

Don't know on that. If I/O is initiated on a free'd pagebuf,
then the contents of the I/O is unknown. So the corruption
doesn't necessarily have to show meta-data in it.

> 
> Hmm very strange...
> 
> BTW the a 2 thread version of doio ran all night!
> I also ran 5 compiles at the same time on a different file system
> (same system) they all ran to completion.
> 
> I also haven't seem any pb_hold count to low messages.

Note that as I said originally, it is lmbench which consistently
reproduces the hold problem. I've seen it on kernel compiles
only occasionally.

ananth.

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:11 2000
Received:  by oss.sgi.com id <S305200AbQDZSP2>;
	Wed, 26 Apr 2000 11:15:28 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:30327 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305182AbQDZSPW>;
	Wed, 26 Apr 2000 11:15:22 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA01053
	for <linux-xfs@oss.sgi.com>; Wed, 26 Apr 2000 11:10:36 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA20516; Wed, 26 Apr 2000 13:14:04 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA29619; Wed, 26 Apr 2000 13:13:56 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id NAA31495; Wed, 26 Apr 2000 13:12:41 -0500
Message-Id: <200004261812.NAA31495@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     cattelan@thebarn.com, linux-xfs@oss.sgi.com
Subject: Re: corruption 
In-Reply-To: Message from Rajagopal Ananthanarayanan <ananth@sgi.com> 
   of "Wed, 26 Apr 2000 10:19:01 PDT." <39072505.35775DAD@sgi.com> 
Date:   Wed, 26 Apr 2000 13:12:41 -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


> 
> Note that as I said originally, it is lmbench which consistently
> reproduces the hold problem. I've seen it on kernel compiles
> only occasionally.
> 
> ananth.


So what options are you passing into lmbench, specifically, are you running
more than one copy at once?

Steve


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:11 2000
Received:  by oss.sgi.com id <S305209AbQDZSfJ>;
	Wed, 26 Apr 2000 11:35:09 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:58492 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305182AbQDZSek>;
	Wed, 26 Apr 2000 11:34:40 -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 LAA03731
	for <linux-xfs@oss.sgi.com>; Wed, 26 Apr 2000 11:29:53 -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 LAA41358 for <linux-xfs@oss.sgi.com>; Wed, 26 Apr 2000 11:32:23 -0700 (PDT)
Message-ID: <3907365C.A32D4D33@sgi.com>
Date:   Wed, 26 Apr 2000 11:33:00 -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:     linux-xfs@oss.sgi.com
Subject: Re: corruption
References: <200004261812.NAA31495@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

Steve Lord wrote:
> 
> >
> > Note that as I said originally, it is lmbench which consistently
> > reproduces the hold problem. I've seen it on kernel compiles
> > only occasionally.
> >
> > ananth.
> 
> So what options are you passing into lmbench, specifically, are you running
> more than one copy at once?
> 

I don't run multiple copies. Here't the CONFIG file,
found under "bin/i686-linux/CONFIG.<machine>":

----------
DISKS=""
DISK_DESC=""
ENOUGH=5000
FASTMEM="NO"
FILE=/mnt/XXX
FSDIR=/mnt
INFO=INFO.delilah
LOOP_O=0.00000122
MAIL=no
MB=16
MHZ="267 MHz, 3.75 nanosec clock"
MOTHERBOARD=""
NETWORKS=""
PROCESSORS=""
REMOTE=""
SLOWFS="NO"
SYNC_MAX="1"
TIMING_O=1
VERSION=lmbench-2alpha11
---------------

ananth.

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:11 2000
Received:  by oss.sgi.com id <S305191AbQD0BGv>;
	Wed, 26 Apr 2000 18:06:51 -0700
Received: from host196.creativedesign.com ([207.135.94.196]:2054 "HELO
        host196.creativedesign.com") by oss.sgi.com with SMTP
	id <S305182AbQD0BGf>; Wed, 26 Apr 2000 18:06:35 -0700
Received: from eventdriven.org (IDENT:root@localhost.localdomain [127.0.0.1])
	by host196.creativedesign.com (8.9.3/8.9.3) with ESMTP id SAA03092
	for <linux-xfs@oss.sgi.com>; Wed, 26 Apr 2000 18:06:35 -0700
Message-ID: <3907929B.8E1F4097@eventdriven.org>
Date:   Wed, 26 Apr 2000 18:06:35 -0700
From:   Kip Matthew Macy <kip@eventdriven.org>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: kernel panic on umount
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 just tried to unmount a 200GB hardware RAID XFS partition and got

Size 452224 doing a vfree 0xe0890000
entering kdb @....  Panic: divide error

the backtrace is :

schedule
reschedule


Any idea what happened?

                                                                    -Kip


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:11 2000
Received:  by oss.sgi.com id <S305197AbQD0DCr>;
	Wed, 26 Apr 2000 20:02:47 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:25715 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305182AbQD0DCV>;
	Wed, 26 Apr 2000 20:02:21 -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 TAA29117
	for <linux-xfs@oss.sgi.com>; Wed, 26 Apr 2000 19:57:33 -0700 (PDT)
	mail_from (ivanr@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA09299 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 13:01:03 +1000
Received: (from ivanr@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA00334 for linux-xfs@oss.sgi.com; Thu, 27 Apr 2000 13:01:01 +1000 (EST)
Date:   Thu, 27 Apr 2000 13:01:01 +1000 (EST)
From:   ivanr@snort.melbourne.sgi.com (Ivan Rayner)
Message-Id: <200004270301.NAA00334@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - endian conversion for bmap
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

endian conversion support for bmap stuff

Modid:  2.3.99pre2-xfs:slinx:59943a
Date:  Wed Apr 26 19:57:45 PDT 2000
Workarea:  snort:/hosts/bruce/home/ivanr/isms/slinx-xfs-tot

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

cmd/xfs/logprint/log_print_trans.c - 1.24
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/logprint/log_print_trans.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h
linux/fs/xfs/xfs_bmap.c - 1.249
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap.c.diff?r1=text&tr1=1.249&r2=text&tr2=1.248&f=h
linux/fs/xfs/xfs_bmap_btree.c - 1.108
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap_btree.c.diff?r1=text&tr1=1.108&r2=text&tr2=1.107&f=h
linux/fs/xfs/xfs_bmap_btree.h - 1.46
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap_btree.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h
linux/fs/xfs/xfsidbg.c - 1.137
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.137&r2=text&tr2=1.136&f=h

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:11 2000
Received:  by oss.sgi.com id <S305199AbQD0DfH>;
	Wed, 26 Apr 2000 20:35:07 -0700
Received: from nic-31-c26-223.mn.mediaone.net ([24.31.26.223]:43526 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S305182AbQD0Den>;
	Wed, 26 Apr 2000 20:34:43 -0700
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.9.3/8.9.1) with ESMTP id WAA41533;
	Wed, 26 Apr 2000 22:34:39 -0500 (CDT)
Message-ID: <3907B54E.D1A92C0F@thebarn.com>
Date:   Wed, 26 Apr 2000 22:34:39 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Kip Matthew Macy <kip@eventdriven.org>
CC:     linux-xfs@oss.sgi.com
Subject: Re: kernel panic on umount
References: <3907929B.8E1F4097@eventdriven.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

Kip Matthew Macy wrote:

> I just tried to unmount a 200GB hardware RAID XFS partition and got
>
> Size 452224 doing a vfree 0xe0890000
> entering kdb @....  Panic: divide error

Wow that's a new one.

That's a  big chunk of memory... wonder there that one is coming from.
did you see a corresponding vmalloc message earlier?

>
>
> the backtrace is :
>
> schedule
> reschedule
>
> Any idea what happened?
>
>                                                                     -Kip

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:12 2000
Received:  by oss.sgi.com id <S305211AbQD0F01>;
	Wed, 26 Apr 2000 22:26:27 -0700
Received: from adsl-63-203-38-107.dsl.snfc21.pacbell.net ([63.203.38.107]:12928
        "EHLO goober.extendedsolutions.com") by oss.sgi.com with ESMTP
	id <S305204AbQD0FZ5>; Wed, 26 Apr 2000 22:25:57 -0700
Received: from eventdriven.org (IDENT:root@localhost.localdomain [127.0.0.1])
	by goober.extendedsolutions.com (8.9.3/8.9.3) with ESMTP id WAA00886;
	Wed, 26 Apr 2000 22:25:11 -0700
Message-ID: <3907CF37.38459DAF@eventdriven.org>
Date:   Wed, 26 Apr 2000 22:25:11 -0700
From:   Kip Macy <kip@eventdriven.org>
Organization: Extended Solutions Inc.
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Russell Cattelan <cattelan@thebarn.com>, linux-xfs@oss.sgi.com
Subject: Re: kernel panic on umount
References: <3907929B.8E1F4097@eventdriven.org> <3907B54E.D1A92C0F@thebarn.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

> 
> That's a  big chunk of memory... wonder there that one is coming from.
> did you see a corresponding vmalloc message earlier?

Now that you mention it I did. I did not mention it previously because I
did not
see the connection.


					-Kip

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:12 2000
Received:  by oss.sgi.com id <S305218AbQD0M1T>;
	Thu, 27 Apr 2000 05:27:19 -0700
Received: from alum.etsii.upm.es ([138.100.71.70]:13582 "HELO
        alum.etsii.upm.es") by oss.sgi.com with SMTP id <S305212AbQD0M1M>;
	Thu, 27 Apr 2000 05:27:12 -0700
Received: (qmail 2750 invoked by uid 33); 27 Apr 2000 12:28:08 -0000
Message-ID: <956838488.390832580fe19@alum.etsii.upm.es>
Date:   Thu, 27 Apr 2000 14:28:08 +0200
To:     linux-xfs@oss.sgi.com
From:   Enrique Alonso de Armas <ealonso@alum.etsii.upm.es>
Subject: compile errors
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.0
X-Originating-IP: 138.100.73.27
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi all,
I'm trying to compile linux-xfs.
I have gcc version 2.7.2.3. Do I  need to upgrade?
I get the following while compiling:
........................................................
make[2]: Entering directory `/images1/enrique/xfs/cvsxfs/linux-2.3-xfs/linux/fs/xfs'
make[2]: Circular pseudo-inc/sys/vfs.h <- pseudo-inc/sys/vnode.h dependency dropped.
gcc -D__KERNEL__ -I/images1/enrique/xfs/cvsxfs/linux-2.3-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce  -DCPU=686   -DMODULE -DMODVERSIONS -include /images1/enrique/xfs/cvsxfs/linux-2.3-xfs/linux/include/linux/modversions.h -g3 -Wno-unused  -Wno-unknown-pragmas -Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL -funsigned-char   -DEXPORT_SYMTAB -c xfs_alloc.c
cc1: Invalid option `-Wno-unknown-pragmas'
make[2]: *** [xfs_alloc.o] Error 1
make[2]: Leaving directory `/images1/enrique/xfs/cvsxfs/linux-2.3-xfs/linux/fs/xfs'
make[1]: *** [_modsubdir_xfs] Error 2
make[1]: Leaving directory `/images1/enrique/xfs/cvsxfs/linux-2.3-xfs/linux/fs'
make: *** [_mod_fs] Error 2
Exit 2
..........................................................

thank you

------------------------------------
Enrique Alonso de Armas
ealonso@alum.etsii.upm.es
enrique@dorka.bindar.es
http://www.bindar.es
http://www.alum.etsii.upm.es/pgp.txt
Network/Unix Adm
------------------------------------


Linux rules!
(this is a .signature virus, please add me to your signature
file and help me to live)


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:12 2000
Received:  by oss.sgi.com id <S305219AbQD0Mg7>;
	Thu, 27 Apr 2000 05:36:59 -0700
Received: from file.phys.tohoku.ac.jp ([130.34.117.125]:31129 "HELO
        file.phys.tohoku.ac.jp") by oss.sgi.com with SMTP
	id <S305212AbQD0Mgb>; Thu, 27 Apr 2000 05:36:31 -0700
Received: (qmail 12000 invoked by uid 239); 27 Apr 2000 12:36:26 -0000
Message-ID: <20000427123626.11999.qmail@file.phys.tohoku.ac.jp>
Date:   27 Apr 2000 21:36:26 +0900
Date:   Thu, 27 Apr 2000 21:36:26 +0900
From:   suzukis@file.phys.tohoku.ac.jp
To:     linux-xfs@oss.sgi.com
Cc:     ealonso@alum.etsii.upm.es
In-reply-to: Enrique Alonso de Armas 's message of Thu, 27 Apr 2000 14:28:08 +0200<956838488.390832580fe19@alum.etsii.upm.es>
Subject: Re: compile errors
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Mailer: addmail [version 2.0.12]
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 gcc version 2.7.2.3. Do I  need to upgrade?

Yes, it's a bit too old to try SGI Linux kernel source.
Please try egcs-1.1.2. egcs-1.0.x can compile too,
but I recommend egcs-1.1.2.

# It was the first question of me when I got the source :-).

It's not impossible to compile by older gcc by some
modification of Makefile, I suppose. But, it's difficult
to know whether the problems comes from old gcc or kernel
source itself, so building the kernel by old gcc will
bring you to the world with small number of people...

suzuki

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:12 2000
Received:  by oss.sgi.com id <S305212AbQD0NNT>;
	Thu, 27 Apr 2000 06:13:19 -0700
Received: from nic-31-c26-223.mn.mediaone.net ([24.31.26.223]:43783 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S305187AbQD0NNC>;
	Thu, 27 Apr 2000 06:13:02 -0700
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.9.3/8.9.1) with ESMTP id IAA42262;
	Thu, 27 Apr 2000 08:11:12 -0500 (CDT)
Message-ID: <39083C70.A3691AD0@thebarn.com>
Date:   Thu, 27 Apr 2000 08:11:12 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Enrique Alonso de Armas <ealonso@alum.etsii.upm.es>
CC:     linux-xfs@oss.sgi.com
Subject: Re: compile errors
References: <956838488.390832580fe19@alum.etsii.upm.es>
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

Enrique Alonso de Armas wrote:
you could try removing the -Wno-unknown-pragmas option.
you will get some warning messages but it shouldn't fail the compile.

The easiest thing would be to upgrade gcc.



> Hi all,
> I'm trying to compile linux-xfs.
> I have gcc version 2.7.2.3. Do I  need to upgrade?
> I get the following while compiling:
> ........................................................
> make[2]: Entering directory `/images1/enrique/xfs/cvsxfs/linux-2.3-xfs/linux/fs/xfs'
> make[2]: Circular pseudo-inc/sys/vfs.h <- pseudo-inc/sys/vnode.h dependency dropped.
> gcc -D__KERNEL__ -I/images1/enrique/xfs/cvsxfs/linux-2.3-xfs/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce  -DCPU=686   -DMODULE -DMODVERSIONS -include /images1/enrique/xfs/cvsxfs/linux-2.3-xfs/linux/include/linux/modversions.h -g3 -Wno-unused  -Wno-unknown-pragmas -Wno-parentheses -Wno-uninitialized -I./linux -I./pseudo-inc -I. -D_KERNEL -funsigned-char   -DEXPORT_SYMTAB -c xfs_alloc.c
> cc1: Invalid option `'
> make[2]: *** [xfs_alloc.o] Error 1
> make[2]: Leaving directory `/images1/enrique/xfs/cvsxfs/linux-2.3-xfs/linux/fs/xfs'
> make[1]: *** [_modsubdir_xfs] Error 2
> make[1]: Leaving directory `/images1/enrique/xfs/cvsxfs/linux-2.3-xfs/linux/fs'
> make: *** [_mod_fs] Error 2
> Exit 2
> ..........................................................
>
> thank you
>
> ------------------------------------
> Enrique Alonso de Armas
> ealonso@alum.etsii.upm.es
> enrique@dorka.bindar.es
> http://www.bindar.es
> http://www.alum.etsii.upm.es/pgp.txt
> Network/Unix Adm
> ------------------------------------
>
> Linux rules!
> (this is a .signature virus, please add me to your signature
> file and help me to live)

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:12 2000
Received:  by oss.sgi.com id <S305223AbQD0Nr3>;
	Thu, 27 Apr 2000 06:47:29 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:5956 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305222AbQD0NrS>;
	Thu, 27 Apr 2000 06:47:18 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA07508
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 06:42:32 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA86181; Thu, 27 Apr 2000 08:44:45 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA00594; Thu, 27 Apr 2000 08:44:37 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA32620; Thu, 27 Apr 2000 08:43:15 -0500
Message-Id: <200004271343.IAA32620@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Kip Matthew Macy <kip@eventdriven.org>
cc:     linux-xfs@oss.sgi.com
Subject: Re: kernel panic on umount 
In-Reply-To: Message from Kip Matthew Macy <kip@eventdriven.org> 
   of "Wed, 26 Apr 2000 18:06:35 PDT." <3907929B.8E1F4097@eventdriven.org> 
Date:   Thu, 27 Apr 2000 08:43: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 just tried to unmount a 200GB hardware RAID XFS partition and got
> 
> Size 452224 doing a vfree 0xe0890000
> entering kdb @....  Panic: divide error
> 
> the backtrace is :
> 
> schedule
> reschedule
> 
> 
> Any idea what happened?
> 
>                                                                     -Kip

Are you running on a 2 cpu machine? If you were and you were using kdb to
dump the stack back trace, can you get a backtrace from the other cpu?
kdb has an annoying habit of setting the default processor to the opposite
one to the one which crashed.

Steve



From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:12 2000
Received:  by oss.sgi.com id <S305224AbQD0QCb>;
	Thu, 27 Apr 2000 09:02:31 -0700
Received: from adsl-63-203-38-107.dsl.snfc21.pacbell.net ([63.203.38.107]:1665
        "EHLO goober.extendedsolutions.com") by oss.sgi.com with ESMTP
	id <S305187AbQD0QCS>; Thu, 27 Apr 2000 09:02:18 -0700
Received: from eventdriven.org (IDENT:root@localhost.localdomain [127.0.0.1])
	by goober.extendedsolutions.com (8.9.3/8.9.3) with ESMTP id JAA01313;
	Thu, 27 Apr 2000 09:01:22 -0700
Message-ID: <39086452.FC2DBC10@eventdriven.org>
Date:   Thu, 27 Apr 2000 09:01:22 -0700
From:   Kip Macy <kip@eventdriven.org>
Organization: Extended Solutions Inc.
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: kernel panic on umount
References: <200004271343.IAA32620@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

It is SMP capable - but it currently only has one processor in it.


					-Kip



Steve Lord wrote:
> 
> > I just tried to unmount a 200GB hardware RAID XFS partition and got
> >
> > Size 452224 doing a vfree 0xe0890000
> > entering kdb @....  Panic: divide error
> >
> > the backtrace is :
> >
> > schedule
> > reschedule
> >
> >
> > Any idea what happened?
> >
> >                                                                     -Kip
> 
> Are you running on a 2 cpu machine? If you were and you were using kdb to
> dump the stack back trace, can you get a backtrace from the other cpu?
> kdb has an annoying habit of setting the default processor to the opposite
> one to the one which crashed.
> 
> Steve

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:12 2000
Received:  by oss.sgi.com id <S305225AbQD0QTv>;
	Thu, 27 Apr 2000 09:19:51 -0700
Received: from marvin.cdf.toronto.edu ([128.100.31.3]:60408 "HELO
        marvin.cdf.toronto.edu") by oss.sgi.com with SMTP
	id <S305187AbQD0QTf>; Thu, 27 Apr 2000 09:19:35 -0700
Received: by marvin.cdf.toronto.edu (Postfix, from userid 605)
	id E38593C06; Thu, 27 Apr 2000 12:18:45 -0400 (EDT)
Date:   Thu, 27 Apr 2000 12:18:44 -0400 (EDT)
From:   Andrew Park <apark@cdf.toronto.edu>
X-Sender: apark@misty.cdf
To:     linux-xfs@oss.sgi.com
Cc:     suzukis@file.phys.tohoku.ac.jp, ealonso@alum.etsii.upm.es
Subject: Re: compile errors
In-Reply-To: <20000427123626.11999.qmail@file.phys.tohoku.ac.jp>
Message-ID: <Pine.SOL.4.21.0004271205440.23546-100000@misty.cdf>
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 27 Apr 2000 suzukis@file.phys.tohoku.ac.jp wrote:

> > I have gcc version 2.7.2.3. Do I  need to upgrade?
> 
> Yes, it's a bit too old to try SGI Linux kernel source.
> Please try egcs-1.1.2. egcs-1.0.x can compile too,
> but I recommend egcs-1.1.2.

Well, some may say that it is old, but gcc 2.7.2.3 IS the official
compiler of the linux Kernel.  I (IMHO) think it is rather stupid if
XFS wouldn't compile with the official linux kernel compiler.  I'd like to
know the following then

	1.  Is SGI pushing to have XFS accepted into official linux kernel
	    sources?

	2.  If so, then why create extra work now, by having things that'll
	    break with official kernel compiler?

	3.  If not (of #1) what is SGI intending?

Thank you


Andrew Park
           
___________________________________________________________________________ 
CDFlab Systems Administrator                          www.cdf.utoronto.ca |
Team BlueShirt Developer			      www.blueshirt.org   |
---------------------------------------------------------------------------



From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:12 2000
Received:  by oss.sgi.com id <S305226AbQD0Qll>;
	Thu, 27 Apr 2000 09:41:41 -0700
Received: from adsl-63-203-38-107.dsl.snfc21.pacbell.net ([63.203.38.107]:4481
        "EHLO goober.extendedsolutions.com") by oss.sgi.com with ESMTP
	id <S305187AbQD0Qlb>; Thu, 27 Apr 2000 09:41:31 -0700
Received: from eventdriven.org (IDENT:root@localhost.localdomain [127.0.0.1])
	by goober.extendedsolutions.com (8.9.3/8.9.3) with ESMTP id JAA01337;
	Thu, 27 Apr 2000 09:40:44 -0700
Message-ID: <39086D8C.4A61B193@eventdriven.org>
Date:   Thu, 27 Apr 2000 09:40:44 -0700
From:   Kip Macy <kip@eventdriven.org>
Organization: Extended Solutions Inc.
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andrew Park <apark@cdf.toronto.edu>
CC:     linux-xfs@oss.sgi.com
Subject: Re: compile errors
References: <Pine.SOL.4.21.0004271205440.23546-100000@misty.cdf>
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 Park wrote:
> 
> On 27 Apr 2000 suzukis@file.phys.tohoku.ac.jp wrote:
> 
> > > I have gcc version 2.7.2.3. Do I  need to upgrade?
> >
> > Yes, it's a bit too old to try SGI Linux kernel source.
> > Please try egcs-1.1.2. egcs-1.0.x can compile too,
> > but I recommend egcs-1.1.2.
> 
> Well, some may say that it is old, but gcc 2.7.2.3 IS the official
> compiler of the linux Kernel.  I (IMHO) think it is rather stupid if
> XFS wouldn't compile with the official linux kernel compiler.  I'd like to
> know the following then
> 
>         1.  Is SGI pushing to have XFS accepted into official linux kernel
>             sources?
> 
>         2.  If so, then why create extra work now, by having things that'll
>             break with official kernel compiler?
> 
>         3.  If not (of #1) what is SGI intending?



gcc-2.7.x is 5 years old. Redhat happily uses egcs-1.1.2 and it is a
safe bet 
that the community will go that way in the not too distant future.

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:12 2000
Received:  by oss.sgi.com id <S305227AbQD0Qpl>;
	Thu, 27 Apr 2000 09:45:41 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:56180 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305190AbQD0Qpb>;
	Thu, 27 Apr 2000 09:45:31 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA28969
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 09:40:43 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA14808; Thu, 27 Apr 2000 11:44:12 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id LAA09588; Thu, 27 Apr 2000 11:44:04 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id LAA25851; Thu, 27 Apr 2000 11:44:11 -0500
Date:   Thu, 27 Apr 2000 11:44:07 -0500
Message-ID: <14600.28247.933023.71662T@gibble.americas.sgi.com>
To:     apark@cdf.toronto.edu
Cc:     linux-xfs@oss.sgi.com, suzukis@file.phys.tohoku.ac.jp,
        ealonso@alum.etsii.upm.es
Subject: Re: compile errors
In-Reply-To: In your message of "Thu, 27 Apr 2000 12:18:44 -0400 (EDT)"
	<Pine.SOL.4.21.0004271205440.23546-100000@misty.cdf>
References: <20000427123626.11999.qmail@file.phys.tohoku.ac.jp>
	<Pine.SOL.4.21.0004271205440.23546-100000@misty.cdf>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Thu, 27 Apr 2000 12:18:44 -0400 (EDT),
Andrew Park <apark@cdf.toronto.edu> wrote:
> 
> 
> On 27 Apr 2000 suzukis@file.phys.tohoku.ac.jp wrote:
> 
> > > I have gcc version 2.7.2.3. Do I  need to upgrade?
> > 
> > Yes, it's a bit too old to try SGI Linux kernel source.
> > Please try egcs-1.1.2. egcs-1.0.x can compile too,
> > but I recommend egcs-1.1.2.
> 
> Well, some may say that it is old, but gcc 2.7.2.3 IS the official
> compiler of the linux Kernel.  I (IMHO) think it is rather stupid if
> XFS wouldn't compile with the official linux kernel compiler.  I'd like to
> know the following then
> 
> 	1.  Is SGI pushing to have XFS accepted into official linux kernel
> 	    sources?
Pushing at this point is overstating the current state of things.
Our primary concern is to finish the initial implementation and
stablize it. 
Acceptance is understandably a ways beyond that, and who knows
what will be "official" at that point. To use and old
saying "well cross that bridge when we get to it"

Developemnt has been done primarily on RH 6.1 6.2 the default version
that comes with RH just happened to supoort the pragma flag.


> 	2.  If so, then why create extra work now, by having things that'll
> 	    break with official kernel compiler?
> 
> 	3.  If not (of #1) what is SGI intending?
> 
> Thank you
> 
> 
> Andrew Park
>            
> ___________________________________________________________________________ 
> CDFlab Systems Administrator                          www.cdf.utoronto.ca |
> Team BlueShirt Developer			      www.blueshirt.org   |
> ---------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:12 2000
Received:  by oss.sgi.com id <S305190AbQD0QtM>;
	Thu, 27 Apr 2000 09:49:12 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:60277 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305187AbQD0Qsy>;
	Thu, 27 Apr 2000 09:48:54 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA29527
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 09:44:07 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA77357; Thu, 27 Apr 2000 11:47:37 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id LAA09689; Thu, 27 Apr 2000 11:47:28 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id LAA00417; Thu, 27 Apr 2000 11:46:05 -0500
Message-Id: <200004271646.LAA00417@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Andrew Park <apark@cdf.toronto.edu>
cc:     linux-xfs@oss.sgi.com, suzukis@file.phys.tohoku.ac.jp,
        ealonso@alum.etsii.upm.es
Subject: Re: compile errors 
In-Reply-To: Message from Andrew Park <apark@cdf.toronto.edu> 
   of "Thu, 27 Apr 2000 12:18:44 EDT." <Pine.SOL.4.21.0004271205440.23546-100000@misty.cdf> 
Date:   Thu, 27 Apr 2000 11:46: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




> On 27 Apr 2000 suzukis@file.phys.tohoku.ac.jp wrote:
> 
> > > I have gcc version 2.7.2.3. Do I  need to upgrade?
> > 
> > Yes, it's a bit too old to try SGI Linux kernel source.
> > Please try egcs-1.1.2. egcs-1.0.x can compile too,
> > but I recommend egcs-1.1.2.
> 
> Well, some may say that it is old, but gcc 2.7.2.3 IS the official
> compiler of the linux Kernel.  I (IMHO) think it is rather stupid if
> XFS wouldn't compile with the official linux kernel compiler.  I'd like to
> know the following then
> 
> 	1.  Is SGI pushing to have XFS accepted into official linux kernel
> 	    sources?
> 
> 	2.  If so, then why create extra work now, by having things that'll
> 	    break with official kernel compiler?
> 
> 	3.  If not (of #1) what is SGI intending?
> 
> Thank you

We are not pushing to get into the official tree yet. We know we have a number
of things to cleanup before we do that - some of which are much bigger than
the compiler issue. Currently we are concentrating on functionality and
correctness, after that comes performance, after that comes getting into
the official tree.

I you really want to build with an older compiler then I think all you have
to do is remove the  -Wno-unknown-pragmas from the xfs/Makefile and
xfs/linux/Makefile, and then go remove all the pragmas which it starts
complaining about.

The pragmas are still there because I want to find a way to tell gcc that
this is an infrequently executed code path. If you know how to do that I
will change them all.

Basically it comes down to having bigger fish to fry right now.

Steve Lord


> 
> 
> Andrew Park
>            
> ___________________________________________________________________________ 
> CDFlab Systems Administrator                          www.cdf.utoronto.ca |
> Team BlueShirt Developer			      www.blueshirt.org   |
> ---------------------------------------------------------------------------
> 



From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:13 2000
Received:  by oss.sgi.com id <S305228AbQD0Q4B>;
	Thu, 27 Apr 2000 09:56:01 -0700
Received: from Cantor.suse.de ([194.112.123.193]:23560 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305187AbQD0Qzv>;
	Thu, 27 Apr 2000 09:55:51 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 3E3601E12B; Thu, 27 Apr 2000 18:55:49 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 8691F10A03E; Thu, 27 Apr 2000 18:55:48 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id DEC992F36B; Thu, 27 Apr 2000 18:55:46 +0200 (MEST)
Date:   Thu, 27 Apr 2000 18:55:46 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Steve Lord <lord@sgi.com>
Cc:     Andrew Park <apark@cdf.toronto.edu>, linux-xfs@oss.sgi.com,
        suzukis@file.phys.tohoku.ac.jp, ealonso@alum.etsii.upm.es
Subject: Re: compile errors
Message-ID: <20000427185546.A2956@gruyere.muc.suse.de>
References: <apark@cdf.toronto.edu> <200004271646.LAA00417@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200004271646.LAA00417@jen.americas.sgi.com>; from lord@sgi.com on Thu, Apr 27, 2000 at 11:46:05AM -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 Thu, Apr 27, 2000 at 11:46:05AM -0500, Steve Lord wrote:
> The pragmas are still there because I want to find a way to tell gcc that
> this is an infrequently executed code path. If you know how to do that I
> will change them all.

This is only supported in gcc-current (since about two weeks or so) and 
in the latest GnuPRO release from cygnus. You do it via __builtin_expect(),
e.g.:

	ptr = function(); 
	if (__builtin_expect(ptr == NULL, 0)) { 
		/* error path */
	} 

At least for == NULL checks gcc-current (the upcoming gcc 3.0) will default
to not predicted. When you compile with -freorder-blocks it should also
move the error path out of line (in theory, -freorder-blocks seems to be
still rather buggy). I don't know what GnuPro does exactly with 
__builtin_expect, apparently it is a different implementation.

I'm guess it'll be quite some time until gcc 3.0 is released and accepted
generally for Linux kernel development (the later is probably years away)


-Andi


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:13 2000
Received:  by oss.sgi.com id <S305230AbQD0Q7B>;
	Thu, 27 Apr 2000 09:59:01 -0700
Received: from file.phys.tohoku.ac.jp ([130.34.117.125]:42138 "HELO
        file.phys.tohoku.ac.jp") by oss.sgi.com with SMTP
	id <S305229AbQD0Q6u>; Thu, 27 Apr 2000 09:58:50 -0700
Received: (qmail 13188 invoked by uid 239); 27 Apr 2000 16:58:47 -0000
Message-ID: <20000427165847.13187.qmail@file.phys.tohoku.ac.jp>
Date:   28 Apr 2000 01:58:47 +0900
Date:   Fri, 28 Apr 2000 01:58:47 +0900
From:   suzukis@file.phys.tohoku.ac.jp
To:     owner-linux-xfs@oss.sgi.com
Cc:     ealonso@alum.etsii.upm.es, linux-xfs@oss.sgi.com
In-reply-to: Andrew Park 's message of Thu, 27 Apr 2000 12:18:44 -0400 (EDT)<Pine.SOL.4.21.0004271205440.23546-100000@misty.cdf>
Subject: Re: compile errors
Mime-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Mailer: addmail [version 2.0.12]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

>Well, some may say that it is old, but gcc 2.7.2.3 IS
>the official compiler of the linux Kernel.

Yes, the documentation in the official Linux kernel source
(Documentation/Changes) tells as "at least gcc-2.7.2.3".
But I don't think the documentation does not push
gcc-2.7.2.3 than later. How do you think?

>I (IMHO) think it is rather stupid if XFS wouldn't compile
>with the official linux kernel compiler.

Of course, I agree enabling linux-xfs to be compiled
with gcc-2.7.2.3 is expected - but I don't think yet
it's not time for the linux-xfs core developpers to
check the back compatibilities. Today linux-xfs is
in bleeding-edge status, Possibly still there might
be bugs due to the implementation itself (SORRY!),
realized in any versions of gcc. For the core developpers
of SGI, now it's time to fix such bugs.

So, please don't ask the gcc-version-independency yet.
If you wish NOW - you (and me :-)) should do it.
But, keeping (at least) 1 environment similar to the
core developpers is not bad to find a bug, I think.
Don't you think so?

suzuki

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:13 2000
Received:  by oss.sgi.com id <S305231AbQD0RdM>;
	Thu, 27 Apr 2000 10:33:12 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:61960 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305187AbQD0RdF>;
	Thu, 27 Apr 2000 10:33:05 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA05711
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 10:28:18 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA51782; Thu, 27 Apr 2000 12:31:47 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA11666; Thu, 27 Apr 2000 12:31:38 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id MAA62387; Thu, 27 Apr 2000 12:31:44 -0500 (CDT)
Message-Id: <200004271731.MAA62387@fsgi344.americas.sgi.com>
Subject: Re: compile errors
To:     suzukis@file.phys.tohoku.ac.jp
Date:   Thu, 27 Apr 2000 12:31:44 -0500 (CDT)
Cc:     ealonso@alum.etsii.upm.es, linux-xfs@oss.sgi.com
In-Reply-To: <20000427165847.13187.qmail@file.phys.tohoku.ac.jp> from "suzukis@file.phys.tohoku.ac.jp" at Apr 28, 2000 01:58:47 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


You hit the nail on the head.
We are focusing on getting XFS working now and will deal with
compatability issues later.

It would be great if you could provide some patches with fixes
to work with the the gcc version you have. We would integrate these
after some study.

Thanks,

Jim

>
>>Well, some may say that it is old, but gcc 2.7.2.3 IS
>>the official compiler of the linux Kernel.
>
>Yes, the documentation in the official Linux kernel source
>(Documentation/Changes) tells as "at least gcc-2.7.2.3".
>But I don't think the documentation does not push
>gcc-2.7.2.3 than later. How do you think?
>
>>I (IMHO) think it is rather stupid if XFS wouldn't compile
>>with the official linux kernel compiler.
>
>Of course, I agree enabling linux-xfs to be compiled
>with gcc-2.7.2.3 is expected - but I don't think yet
>it's not time for the linux-xfs core developpers to
>check the back compatibilities. Today linux-xfs is
>in bleeding-edge status, Possibly still there might
>be bugs due to the implementation itself (SORRY!),
>realized in any versions of gcc. For the core developpers
>of SGI, now it's time to fix such bugs.
>
>So, please don't ask the gcc-version-independency yet.
>If you wish NOW - you (and me :-)) should do it.
>But, keeping (at least) 1 environment similar to the
>core developpers is not bad to find a bug, I think.
>Don't you think so?
>
>suzuki
>


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:13 2000
Received:  by oss.sgi.com id <S305232AbQD0RlM>;
	Thu, 27 Apr 2000 10:41:12 -0700
Received: from ns.hanse.com ([212.209.57.34]:50958 "EHLO ns.hanse.com")
	by oss.sgi.com with ESMTP id <S305187AbQD0RlA>;
	Thu, 27 Apr 2000 10:41:00 -0700
Received: from hanse.com (voyager.stesmi.com [212.209.57.67])
	by ns.hanse.com (8.9.3/8.8.7) with ESMTP id TAA15808
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 19:40:47 +0200
Message-ID: <39087B1F.833C1B7C@hanse.com>
Date:   Thu, 27 Apr 2000 19:38:39 +0200
From:   Stefan Smietanowski <stefan@hanse.com>
Organization: Hanse Communication
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC:     linux-xfs@oss.sgi.com
Subject: Re: compile errors
References: <956838488.390832580fe19@alum.etsii.upm.es> <39083C70.A3691AD0@thebarn.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

Hi Russell.

<snip compilation problem with gcc 2.7.2.3>

> you could try removing the -Wno-unknown-pragmas option.
> you will get some warning messages but it shouldn't fail the compile.
> The easiest thing would be to upgrade gcc.

The recommended compiler is still gcc 2.7.2.3 with the others not being
recommended right now...

// Stefan

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:13 2000
Received:  by oss.sgi.com id <S305233AbQD0Rlm>;
	Thu, 27 Apr 2000 10:41:42 -0700
Received: from marvin.cdf.toronto.edu ([128.100.31.3]:56316 "HELO
        marvin.cdf.toronto.edu") by oss.sgi.com with SMTP
	id <S305187AbQD0Rli>; Thu, 27 Apr 2000 10:41:38 -0700
Received: by marvin.cdf.toronto.edu (Postfix, from userid 605)
	id 307B33C11; Thu, 27 Apr 2000 13:40:57 -0400 (EDT)
Date:   Thu, 27 Apr 2000 13:40:56 -0400 (EDT)
From:   Andrew Park <apark@cdf.toronto.edu>
X-Sender: apark@misty.cdf
To:     linux-xfs@oss.sgi.com
Subject: Re: compile errors
In-Reply-To: <20000427165847.13187.qmail@file.phys.tohoku.ac.jp>
Message-ID: <Pine.SOL.4.21.0004271301550.23599-100000@misty.cdf>
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

Man ...  I've been trying to reply for last half an hour or so, but 
I keep getting more replies ... :)
I appreciate the following people's feed back.

	Kip Macy
	cattelan@thebarn.com
	Steve Lord
	Andi Kleen
	suzukis@file.phys.tohoku.ac.jp

who graciously commented on my question.  Now it's my turn. :)
I'm not asking for backward compatibility I'm asking whether XFS will
be current(ward) compatible (is that even a word?) :) when it comes
down to it.  If XFS is in ready-state and official linux kernel compiler
is gcc 2.7.2.x still, would XFS be adjusted to compile under it then?
or as some companies might exhibit "Too Bad! You do it our way or no way!"
is the type of statement I'll be hearing from this mailing list?
(just wondering ... no offense intended)

My apologies for misunderstanding the status of XFS, but from the Linux
University sponsored by SGI that I attended in Toronto it sounded quite
like as if it is ready for experiment in semi-production environment.
Knowing the XFS status now I understand (not quite agreeing though) why
compiling under gcc2.7.2x is not much of issue.

[cont. below]


On 28 Apr 2000 suzukis@file.phys.tohoku.ac.jp wrote:

> >I (IMHO) think it is rather stupid if XFS wouldn't compile
> >with the official linux kernel compiler.
> 
> Of course, I agree enabling linux-xfs to be compiled
> with gcc-2.7.2.3 is expected - but I don't think yet
> it's not time for the linux-xfs core developpers to
> check the back compatibilities. Today linux-xfs is
> in bleeding-edge status, Possibly still there might
> be bugs due to the implementation itself (SORRY!),
> realized in any versions of gcc. For the core developpers
> of SGI, now it's time to fix such bugs.
> 
> So, please don't ask the gcc-version-independency yet.
> If you wish NOW - you (and me :-)) should do it.

It may take me a while, but I'll see what I can do.


> But, keeping (at least) 1 environment similar to the
> core developpers is not bad to find a bug, I think.
> Don't you think so?

Agreed, and thanks again for the reply.


Andrew Park
           
___________________________________________________________________________ 
CDFlab Systems Administrator                          www.cdf.utoronto.ca |
Team BlueShirt Developer			      www.blueshirt.org   |
---------------------------------------------------------------------------


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:13 2000
Received:  by oss.sgi.com id <S305187AbQD0R5W>;
	Thu, 27 Apr 2000 10:57:22 -0700
Received: from host196.creativedesign.com ([207.135.94.196]:9222 "HELO
        host196.creativedesign.com") by oss.sgi.com with SMTP
	id <S305161AbQD0R45>; Thu, 27 Apr 2000 10:56:57 -0700
Received: from eventdriven.org (IDENT:root@localhost.localdomain [127.0.0.1])
	by host196.creativedesign.com (8.9.3/8.9.3) with ESMTP id KAA04515
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 10:56:42 -0700
Message-ID: <39087F5A.5C9DB3E5@eventdriven.org>
Date:   Thu, 27 Apr 2000 10:56:42 -0700
From:   Kip Matthew Macy <kip@eventdriven.org>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: some more information on umount panic
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

You asked if I saw a corresponding vmalloc:


prompt >  mount -t xfs /dev/rd/c0d0  /xfs
XFS Mode = NATIVE, arch = 1
kmem_alloc doing a vmalloc 452224 size & PAGE_SIZE 0 rval=0xe089600
start mounting filesystem: dac960(48, 0)
Ending clean XFS mount for filesystme: dac960(48,0)

I hope this helps. Any further suggestions are welcome.


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:13 2000
Received:  by oss.sgi.com id <S305234AbQD0R7c>;
	Thu, 27 Apr 2000 10:59:32 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:32601 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305161AbQD0R7Q>; Thu, 27 Apr 2000 10:59:16 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA00939
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 11:03:24 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA87338; Thu, 27 Apr 2000 12:57:57 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA12756; Thu, 27 Apr 2000 12:57:49 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id MAA25909; Thu, 27 Apr 2000 12:57:56 -0500
Date:   Thu, 27 Apr 2000 12:57:53 -0500
Message-ID: <14600.32673.447389.1404B@gibble.americas.sgi.com>
To:     apark@cdf.toronto.edu
Cc:     linux-xfs@oss.sgi.com
Subject: Re: compile errors
In-Reply-To: In your message of "Thu, 27 Apr 2000 13:40:56 -0400 (EDT)"
	<Pine.SOL.4.21.0004271301550.23599-100000@misty.cdf>
References: <20000427165847.13187.qmail@file.phys.tohoku.ac.jp>
	<Pine.SOL.4.21.0004271301550.23599-100000@misty.cdf>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Thu, 27 Apr 2000 13:40:56 -0400 (EDT),
Andrew Park <apark@cdf.toronto.edu> wrote:
> 
> 
> Man ...  I've been trying to reply for last half an hour or so, but 
> I keep getting more replies ... :)
> I appreciate the following people's feed back.
> 
> 	Kip Macy
> 	cattelan@thebarn.com
> 	Steve Lord
> 	Andi Kleen
> 	suzukis@file.phys.tohoku.ac.jp
> 
> who graciously commented on my question.  Now it's my turn. :)
> I'm not asking for backward compatibility I'm asking whether XFS will
> be current(ward) compatible (is that even a word?) :) when it comes
> down to it.  If XFS is in ready-state and official linux kernel compiler
> is gcc 2.7.2.x still, would XFS be adjusted to compile under it then?
> or as some companies might exhibit "Too Bad! You do it our way or no way!"
> is the type of statement I'll be hearing from this mailing list?
> (just wondering ... no offense intended)

I don't know for sure; again it isn't something we have investigated..
Unless there is some techincal issue that really really can not be
solved by means other than upgrading gcc, XFS will comply with
whatever version of gcc is recommended. 


> 
> My apologies for misunderstanding the status of XFS, but from the Linux
> University sponsored by SGI that I attended in Toronto it sounded quite
> like as if it is ready for experiment in semi-production
environment.
That's up to the individual to determine their own risk factor.
I would just use the term experimental right now... semi-production...
hmm not quite yet, but it's getting closer every day.


> Knowing the XFS status now I understand (not quite agreeing though) why
> compiling under gcc2.7.2x is not much of issue.
> 
> [cont. below]
> 
> 
> On 28 Apr 2000 suzukis@file.phys.tohoku.ac.jp wrote:
> 
> > >I (IMHO) think it is rather stupid if XFS wouldn't compile
> > >with the official linux kernel compiler.
> > 
> > Of course, I agree enabling linux-xfs to be compiled
> > with gcc-2.7.2.3 is expected - but I don't think yet
> > it's not time for the linux-xfs core developpers to
> > check the back compatibilities. Today linux-xfs is
> > in bleeding-edge status, Possibly still there might
> > be bugs due to the implementation itself (SORRY!),
> > realized in any versions of gcc. For the core developpers
> > of SGI, now it's time to fix such bugs.
> > 
> > So, please don't ask the gcc-version-independency yet.
> > If you wish NOW - you (and me :-)) should do it.
> 
> It may take me a while, but I'll see what I can do.
> 
> 
> > But, keeping (at least) 1 environment similar to the
> > core developpers is not bad to find a bug, I think.
> > Don't you think so?
> 
> Agreed, and thanks again for the reply.
> 
> 
> Andrew Park
>            
> ___________________________________________________________________________ 
> CDFlab Systems Administrator                          www.cdf.utoronto.ca |
> Team BlueShirt Developer			      www.blueshirt.org   |
> ---------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:13 2000
Received:  by oss.sgi.com id <S305235AbQD0SBD>;
	Thu, 27 Apr 2000 11:01:03 -0700
Received: from Cantor.suse.de ([194.112.123.193]:42507 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305161AbQD0SAm>;
	Thu, 27 Apr 2000 11:00:42 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 1E4841E153; Thu, 27 Apr 2000 20:00:39 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 8161710A03E; Thu, 27 Apr 2000 20:00:38 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 8DB732F36B; Thu, 27 Apr 2000 20:00:37 +0200 (MEST)
Date:   Thu, 27 Apr 2000 20:00:37 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Jim Mostek <mostek@sgi.com>
Cc:     suzukis@file.phys.tohoku.ac.jp, ealonso@alum.etsii.upm.es,
        linux-xfs@oss.sgi.com
Subject: Re: compile errors
Message-ID: <20000427200037.A3662@gruyere.muc.suse.de>
References: <20000427165847.13187.qmail@file.phys.tohoku.ac.jp> <200004271731.MAA62387@fsgi344.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200004271731.MAA62387@fsgi344.americas.sgi.com>; from mostek@sgi.com on Thu, Apr 27, 2000 at 12:31:44PM -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 Thu, Apr 27, 2000 at 12:31:44PM -0500, Jim Mostek wrote:
> 
> You hit the nail on the head.
> We are focusing on getting XFS working now and will deal with
> compatability issues later.
> 
> It would be great if you could provide some patches with fixes
> to work with the the gcc version you have. We would integrate these
> after some study.

Try this patch (the same technique is used in other places of the 2.3
kernel): 


--- linux/fs/xfs/Makefile-o	Fri Apr 28 03:51:41 2000
+++ linux/fs/xfs/Makefile	Fri Apr 28 04:04:33 2000
@@ -44,9 +44,12 @@
 EXTRA_FIND_DIRECTORIES = linux pseudo-inc
 EXTRA_INCLUDE_DIRECTORIES = -I./linux -I./pseudo-inc -I.
 
-EXTRA_CFLAGS += -g3 -Wno-unused  -Wno-unknown-pragmas -Wno-parentheses \
+EXTRA_CFLAGS += -g3 -Wno-unused  -Wno-parentheses \
                 -Wno-uninitialized ${EXTRA_INCLUDE_DIRECTORIES} -D_KERNEL \
 		-funsigned-char 
+
+EXTRA_CFLAGS += $(shell if $(CC) -Wno-unknown-pragmas -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-Wno-unknown-pragmas"; fi)
+
 
 # EXTRA_CFLAGS += -DDEBUG -DXFSDEBUG
 



-Andi

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:13 2000
Received:  by oss.sgi.com id <S305236AbQD0SEL>;
	Thu, 27 Apr 2000 11:04:11 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10330 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305161AbQD0SEE>; Thu, 27 Apr 2000 11:04:04 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA03089
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 11:08:13 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA63273; Thu, 27 Apr 2000 13:02:47 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA13079; Thu, 27 Apr 2000 13:02:39 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id NAA25927; Thu, 27 Apr 2000 13:02:46 -0500
Date:   Thu, 27 Apr 2000 13:02:42 -0500
Message-ID: <14600.32962.977764.44959U@gibble.americas.sgi.com>
To:     kip@eventdriven.org
Cc:     linux-xfs@oss.sgi.com
Subject: Re: some more information on umount panic
In-Reply-To: In your message of "Thu, 27 Apr 2000 10:56:42 -0700"
	<39087F5A.5C9DB3E5@eventdriven.org>
References: <39087F5A.5C9DB3E5@eventdriven.org>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Thu, 27 Apr 2000 10:56:42 -0700,
Kip Matthew Macy <kip@eventdriven.org> wrote:
> 
> 
> You asked if I saw a corresponding vmalloc:
> 
> 
> prompt >  mount -t xfs /dev/rd/c0d0  /xfs
> XFS Mode = NATIVE, arch = 1
> kmem_alloc doing a vmalloc 452224 size & PAGE_SIZE 0 rval=0xe089600
> start mounting filesystem: dac960(48, 0)
> Ending clean XFS mount for filesystme: dac960(48,0)
I don't think this is related to your problem then.
I just wanted to make sure the free code wasn't trying to release
something it shouldn't have.


We are probably going to need a backtrace of the unmount command.
from kdb do a ps, find the umount pid, then btp that pid.

We have known container size mismatches, I have a feeling you have
found one.

I need to start working on our type problems very soon. :-)


-Russell


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:13 2000
Received:  by oss.sgi.com id <S305238AbQD0SMC>;
	Thu, 27 Apr 2000 11:12:02 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2907 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305161AbQD0SLv>; Thu, 27 Apr 2000 11:11:51 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA08057
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 11:16:00 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA46019 for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 13:10:34 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA13464 for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 13:10:26 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id NAA23905; Thu, 27 Apr 2000 13:10:32 -0500 (CDT)
Message-Id: <200004271810.NAA23905@nt8.americas.sgi.com>
Date:   Thu, 27 Apr 2000 13:10:32 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - small makefile fix
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.3.99pre2-xfs:slinx:59962a
Date:  Thu Apr 27 11:10:12 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs

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

linux/fs/xfs/Makefile - 1.101
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/Makefile.diff?r1=text&tr1=1.101&r2=text&tr2=1.100&f=h
	- Check for no-unknown-pragma option on gcc


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:14 2000
Received:  by oss.sgi.com id <S305239AbQD0SNm>;
	Thu, 27 Apr 2000 11:13:42 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16219 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305161AbQD0SN2>; Thu, 27 Apr 2000 11:13:28 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA06987
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 11:17:37 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA13205; Thu, 27 Apr 2000 13:12:10 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA13557; Thu, 27 Apr 2000 13:12:02 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id NAA27370; Thu, 27 Apr 2000 13:12:09 -0500
Date:   Thu, 27 Apr 2000 13:12:06 -0500
Message-ID: <14600.33526.536765.12581O@gibble.americas.sgi.com>
To:     ak@suse.de
Cc:     mostek@sgi.com, suzukis@file.phys.tohoku.ac.jp,
        ealonso@alum.etsii.upm.es, linux-xfs@oss.sgi.com
Subject: Re: compile errors
In-Reply-To: In your message of "Thu, 27 Apr 2000 20:00:37 +0200"
	<20000427200037.A3662@gruyere.muc.suse.de>
References: <20000427165847.13187.qmail@file.phys.tohoku.ac.jp>
	<200004271731.MAA62387@fsgi344.americas.sgi.com>
	<20000427200037.A3662@gruyere.muc.suse.de>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Doesn't break anything... I check it in.

reports from 2.7 would be appreciated.

Thanks Andi
At Thu, 27 Apr 2000 20:00:37 +0200,
Andi Kleen <ak@suse.de> wrote:
> 
> 
> On Thu, Apr 27, 2000 at 12:31:44PM -0500, Jim Mostek wrote:
> > 
> > You hit the nail on the head.
> > We are focusing on getting XFS working now and will deal with
> > compatability issues later.
> > 
> > It would be great if you could provide some patches with fixes
> > to work with the the gcc version you have. We would integrate these
> > after some study.
> 
> Try this patch (the same technique is used in other places of the 2.3
> kernel): 
> 
> 
> --- linux/fs/xfs/Makefile-o	Fri Apr 28 03:51:41 2000
> +++ linux/fs/xfs/Makefile	Fri Apr 28 04:04:33 2000
> @@ -44,9 +44,12 @@
>  EXTRA_FIND_DIRECTORIES = linux pseudo-inc
>  EXTRA_INCLUDE_DIRECTORIES = -I./linux -I./pseudo-inc -I.
>  
> -EXTRA_CFLAGS += -g3 -Wno-unused  -Wno-unknown-pragmas -Wno-parentheses \
> +EXTRA_CFLAGS += -g3 -Wno-unused  -Wno-parentheses \
>                  -Wno-uninitialized ${EXTRA_INCLUDE_DIRECTORIES} -D_KERNEL \
>  		-funsigned-char 
> +
> +EXTRA_CFLAGS += $(shell if $(CC) -Wno-unknown-pragmas -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-Wno-unknown-pragmas"; fi)
> +
>  
>  # EXTRA_CFLAGS += -DDEBUG -DXFSDEBUG
>  
> 
> 
> 
> -Andi

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:14 2000
Received:  by oss.sgi.com id <S305222AbQD0Snc>;
	Thu, 27 Apr 2000 11:43:32 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23903 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305161AbQD0Sm7>; Thu, 27 Apr 2000 11:42:59 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA00850
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 11:47:08 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA86239 for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 13:41:42 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id NAA14977 for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 13:41:34 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id NAA23955; Thu, 27 Apr 2000 13:41:40 -0500 (CDT)
Message-Id: <200004271841.NAA23955@nt8.americas.sgi.com>
Date:   Thu, 27 Apr 2000 13:41:40 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Other make file
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.3.99pre2-xfs:slinx:59963a
Date:  Thu Apr 27 11:39:33 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs

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

linux/fs/xfs/linux/Makefile - 1.19
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/Makefile.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h
	- check for no-unknown-pragma flag


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:14 2000
Received:  by oss.sgi.com id <S305221AbQD0UwE>;
	Thu, 27 Apr 2000 13:52:04 -0700
Received: from host196.creativedesign.com ([207.135.94.196]:33542 "HELO
        host196.creativedesign.com") by oss.sgi.com with SMTP
	id <S305185AbQD0Uvg>; Thu, 27 Apr 2000 13:51:36 -0700
Received: from eventdriven.org (IDENT:root@localhost.localdomain [127.0.0.1])
	by host196.creativedesign.com (8.9.3/8.9.3) with ESMTP id NAA04712;
	Thu, 27 Apr 2000 13:50:54 -0700
Message-ID: <3908A82E.4B3124DF@eventdriven.org>
Date:   Thu, 27 Apr 2000 13:50:54 -0700
From:   Kip Matthew Macy <kip@eventdriven.org>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     cattelan@thebarn.com, linux-xfs@oss.sgi.com
Subject: Re: some more information on umount panic
References: <39087F5A.5C9DB3E5@eventdriven.org> <14600.32962.977764.44959U@gibble.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



>
> We have known container size mismatches, I have a feeling you have
> found one.
>
> I need to start working on our type problems very soon. :-)
>
> -Russell

btp is not that useful for umount:

kdb> btp 885
kdb: Bad user address 0x0
0x0 0xc01156c2      schedule+0x2ba



From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:14 2000
Received:  by oss.sgi.com id <S305243AbQD0Viy>;
	Thu, 27 Apr 2000 14:38:54 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:34891 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305185AbQD0Vik>;
	Thu, 27 Apr 2000 14:38:40 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA07432
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 14:33:53 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA57592; Thu, 27 Apr 2000 16:36:07 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id QAA23197; Thu, 27 Apr 2000 16:35:59 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id QAA05320; Thu, 27 Apr 2000 16:36:06 -0500
Date:   Thu, 27 Apr 2000 16:36:04 -0500
Message-ID: <14600.45764.882840.63473O@gibble.americas.sgi.com>
To:     kip@eventdriven.org
Cc:     linux-xfs@oss.sgi.com
Subject: Re: some more information on umount panic
In-Reply-To: In your message of "Thu, 27 Apr 2000 13:50:54 -0700"
	<3908A82E.4B3124DF@eventdriven.org>
References: <39087F5A.5C9DB3E5@eventdriven.org>
	<14600.32962.977764.44959U@gibble.americas.sgi.com>
	<3908A82E.4B3124DF@eventdriven.org>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Thu, 27 Apr 2000 13:50:54 -0700,
Kip Matthew Macy <kip@eventdriven.org> wrote:
> 
> 
> 
> 
> >
> > We have known container size mismatches, I have a feeling you have
> > found one.
> >
> > I need to start working on our type problems very soon. :-)
> >
> > -Russell
> 
> btp is not that useful for umount:
> 
> kdb> btp 885
> kdb: Bad user address 0x0
> 0x0 0xc01156c2      schedule+0x2ba

I'm not sure what else to have you look at off hand.

Do you have debug turned on in the Makefiles?

Do you have a serial line hooked up to the console?

I would be helpfull if we could see the actual output from the 
panics.



From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:14 2000
Received:  by oss.sgi.com id <S305185AbQD0V5z>;
	Thu, 27 Apr 2000 14:57:55 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:18001 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305176AbQD0V5v>;
	Thu, 27 Apr 2000 14:57:51 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA09782
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 14:53:03 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA84276 for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 16:55:19 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id QAA23787 for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 16:55:10 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id QAA88117; Thu, 27 Apr 2000 16:55:17 -0500 (CDT)
Message-Id: <200004272155.QAA88117@fsgi344.americas.sgi.com>
Subject: Work Items for XFS port (UPDATED)
To:     linux-xfs@oss.sgi.com
Date:   Thu, 27 Apr 2000 16:55:16 -0500 (CDT)
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




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

has been updated to reflect the last month's work and new items, ...

We still need to organize this a bit more:

	break items up into first release/second release/...
	prioritize
	...

If you see any problems or want more items added, let me know.

Thanks,

Jim

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:14 2000
Received:  by oss.sgi.com id <S305242AbQD0WVf>;
	Thu, 27 Apr 2000 15:21:35 -0700
Received: from Cantor.suse.de ([194.112.123.193]:35337 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305176AbQD0WVV>;
	Thu, 27 Apr 2000 15:21:21 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id E105A1E1DA; Fri, 28 Apr 2000 00:21:16 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id B0BBD10A03E; Fri, 28 Apr 2000 00:21:16 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 9489E2F36B; Fri, 28 Apr 2000 00:21:15 +0200 (MEST)
Date:   Fri, 28 Apr 2000 00:21:15 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Jim Mostek <mostek@sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: Work Items for XFS port (UPDATED)
Message-ID: <20000428002115.A8685@gruyere.muc.suse.de>
References: <200004272155.QAA88117@fsgi344.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200004272155.QAA88117@fsgi344.americas.sgi.com>; from mostek@sgi.com on Thu, Apr 27, 2000 at 04:55:16PM -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 Thu, Apr 27, 2000 at 04:55:16PM -0500, Jim Mostek wrote:
> If you see any problems or want more items added, let me know.

XFS/pagebuf never checks for Linux signals ATM when it sleeps. I guess 
Irix signal handling is a bit different. It should be probably fixed though.
Currently e.g. find /xfs is very hard to Ctrl-C. 
I started with adding a few signal checks, but it seems to require
a lot more work.

-Andi

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:14 2000
Received:  by oss.sgi.com id <S305244AbQD0WcZ>;
	Thu, 27 Apr 2000 15:32:25 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:27993 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305176AbQD0WcY>;
	Thu, 27 Apr 2000 15:32:24 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA13782
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 15:27:37 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA27770; Thu, 27 Apr 2000 17:29:51 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id RAA24690; Thu, 27 Apr 2000 17:29:42 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id RAA02893; Thu, 27 Apr 2000 17:28:16 -0500
Message-Id: <200004272228.RAA02893@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     "Andi Kleen" <ak@suse.de>
cc:     Jim Mostek <mostek@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Work Items for XFS port (UPDATED) 
In-Reply-To: Message from "Andi Kleen" <ak@suse.de> 
   of "Fri, 28 Apr 2000 00:21:15 +0200." <20000428002115.A8685@gruyere.muc.suse.de> 
Date:   Thu, 27 Apr 2000 17:28:16 -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 Thu, Apr 27, 2000 at 04:55:16PM -0500, Jim Mostek wrote:
> > If you see any problems or want more items added, let me know.
> 
> XFS/pagebuf never checks for Linux signals ATM when it sleeps. I guess 
> Irix signal handling is a bit different. It should be probably fixed though.
> Currently e.g. find /xfs is very hard to Ctrl-C. 
> I started with adding a few signal checks, but it seems to require
> a lot more work.
> 
> -Andi

How is this different from other filesystems which will sit in wait_on_buffer
using TASK_UNINTERRUPTIBLE? My finds interrupt very quickly.

I did try out a couple of things after you last mentioned this, but I never
managed to find anything which was slow to interrupt. This rather implies
that you have a very long running system call stuck in xfs, I suspect the
problem is not so much that we do not pay attention to interrupts, but that
something is taking much longer than it should. It is possible you found
another case of the missing run_task_queue(&tq_disk). Do things behave
better if you have activity in other filesystems on going at the same time?

Steve








From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:14 2000
Received:  by oss.sgi.com id <S305247AbQD0WuO>;
	Thu, 27 Apr 2000 15:50:14 -0700
Received: from f215.law9.hotmail.com ([64.4.9.215]:54795 "HELO hotmail.com")
	by oss.sgi.com with SMTP id <S305176AbQD0WuG>;
	Thu, 27 Apr 2000 15:50:06 -0700
Received: (qmail 95654 invoked by uid 0); 27 Apr 2000 22:50:01 -0000
Message-ID: <20000427225001.95653.qmail@hotmail.com>
Received: from 209.101.115.162 by www.hotmail.com with HTTP;
	Thu, 27 Apr 2000 15:50:01 PDT
X-Originating-IP: [209.101.115.162]
From:   "Lindanne Metley" <mlindanne@hotmail.com>
To:     linux-xfs@oss.sgi.com
Subject: DM-API? Re: XFS for Linux
Date:   Thu, 27 Apr 2000 15:50:01 PDT
Mime-Version: 1.0
Content-Type: text/plain; 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 heard SGI has already implemented the DM-API for the XFS being ported to 
Linux. I'm working with some people who are also thinking about doing the 
DM-API for Linux. If SGI cannot yet release the source code, could you still 
talk about the user space<-->kernel space protocol so that we could be 
compatiable?

I was thinking of turning each function+parameter list into a struct with a 
function code, and then use ioctl to move the struct back and forth, but if 
you can discuss a better method I would be happy to hear about it.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:14 2000
Received:  by oss.sgi.com id <S305245AbQD0X1Z>;
	Thu, 27 Apr 2000 16:27:25 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:51557 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305176AbQD0X1J>;
	Thu, 27 Apr 2000 16:27:09 -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 QAA19749
	for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 16:22:23 -0700 (PDT)
	mail_from (ananth@dbear.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 QAA00390 for <linux-xfs@oss.sgi.com>; Thu, 27 Apr 2000 16:25:24 -0700 (PDT)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA13100
	for <linux-xfs@oss.sgi.com>;
	Thu, 27 Apr 2000 16:23:49 -0700 (PDT)
	mail_from (ananth@dbear.engr.sgi.com)
Received: (from ananth@localhost)
	by dbear.engr.sgi.com (8.9.3/8.8.7) id QAA02093
	for linux-xfs@oss.sgi.com; Thu, 27 Apr 2000 16:22:58 -0700
Date:   Thu, 27 Apr 2000 16:22:58 -0700
From:   Ananth Ananthanarayanan <ananth@dbear.engr.sgi.com>
Message-Id: <200004272322.QAA02093@dbear.engr.sgi.com>
Subject: TAKE - delayed allocation
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

With delayed allocation, allocation of blocks
on disk are deferred until an I/O is necessary ... 

This is a proof-of-concept implementation,
with lots more stuff to be worked out.

Delayed allocation is turned OFF by default.
But, you are encouraged to turn it on,
by changing delay_alloc to 1 at
this line in 'fs/page_buf.c':

-------
     84 int delay_alloc = 0;
--------

In my tests so far delay_alloc = 1
passes more tests than with it OFF.
Specifically, doio with 2 threads passes OK,
and kernel compilation on a XFS file-system
gets a lot further than without delay_alloc.


Modid:  2.3.99pre2-xfs:slinx:60008a
Date:  Thu Apr 27 16:13:02 PDT 2000
Workarea:  bonnie.engr.sgi.com:/build2/ananth/slinx23-xfs

The following file(s) were checked into:
  bonnie:/isms/slinx/2.3.99pre2-xfs

linux/fs/buffer.c - 1.30
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/buffer.c.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h
linux/fs/inode.c - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/inode.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
linux/fs/page_buf.c - 1.81
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.81&r2=text&tr2=1.80&f=h
linux/fs/xfs/linux/xfs_iops.c - 1.47
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h
linux/fs/xfs/linux/xfs_lrw.c - 1.36
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h
linux/fs/xfs/linux/xfs_super.c - 1.63
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h
linux/include/linux/mm.h - 1.29
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/mm.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h
linux/include/linux/page_buf.h - 1.43
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/page_buf.h.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h
linux/kdb/modules/kdbm_pb.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/modules/kdbm_pb.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
linux/mm/filemap.c - 1.35
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/mm/filemap.c.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h
linux/mm/memory.c - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/mm/memory.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
linux/mm/page_alloc.c - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/mm/page_alloc.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
linux/mm/vmscan.c - 1.25
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/mm/vmscan.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h
	- Changes for XFS delayed allocation and page-cleaner daemon.


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:14 2000
Received:  by oss.sgi.com id <S305246AbQD0XwZ>;
	Thu, 27 Apr 2000 16:52:25 -0700
Received: from Cantor.suse.de ([194.112.123.193]:49676 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305176AbQD0XwC>;
	Thu, 27 Apr 2000 16:52:02 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 157CC1E20C; Fri, 28 Apr 2000 01:51:59 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 3D5D810A03E; Fri, 28 Apr 2000 01:51:59 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 9EC292F36B; Fri, 28 Apr 2000 01:51:58 +0200 (MEST)
Date:   Fri, 28 Apr 2000 01:51:58 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Steve Lord <lord@sgi.com>
Cc:     "Andi Kleen" <ak@suse.de>, Jim Mostek <mostek@sgi.com>,
        linux-xfs@oss.sgi.com
Subject: Re: Work Items for XFS port (UPDATED)
Message-ID: <20000428015158.A9533@gruyere.muc.suse.de>
References: <ak@suse.de> <200004272228.RAA02893@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200004272228.RAA02893@jen.americas.sgi.com>; from lord@sgi.com on Thu, Apr 27, 2000 at 05:28:16PM -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 Thu, Apr 27, 2000 at 05:28:16PM -0500, Steve Lord wrote:
> I did try out a couple of things after you last mentioned this, but I never
> managed to find anything which was slow to interrupt. This rather implies
> that you have a very long running system call stuck in xfs, I suspect the
> problem is not so much that we do not pay attention to interrupts, but that
> something is taking much longer than it should. It is possible you found
> another case of the missing run_task_queue(&tq_disk). Do things behave
> better if you have activity in other filesystems on going at the same time?

Yes, getdents is not interruptible. /xfs contains some very long directories,
which can take a lot of time to readdir(). At least my find passes
big buffers to it, so it has lots of space to play with.


-Andi

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:15 2000
Received:  by oss.sgi.com id <S305192AbQD1Cn1>;
	Thu, 27 Apr 2000 19:43:27 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42004 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305175AbQD1Cm5>; Thu, 27 Apr 2000 19:42:57 -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 TAA03052
	for <xfs@oss.sgi.com>; Thu, 27 Apr 2000 19:47:06 -0700 (PDT)
	mail_from (kenmcd@melbourne.sgi.com)
Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA17715; Fri, 28 Apr 2000 12:41:29 +1000
Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA14988; Fri, 28 Apr 2000 12:41:28 +1000 (EST)
Date:   Fri, 28 Apr 2000 12:41:27 +1000
From:   Ken McDonell <kenmcd@melbourne.sgi.com>
To:     xfs@oss.sgi.com
cc:     ptg@larry.melbourne.sgi.com
Subject: Major milestone in endian work
Message-ID: <Pine.SGI.4.10.10004281107360.114339-100000@rattle.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Thanks mainly to the efforts of Daniel Moore, Nathan Scott and Ivan
Rayner, the XFS endian work has progressed to the point where we can
perform the following tasks:

+ on Irix/MIPS make a default 20 Mbyte filesystem, then populate it as
  follows:
	- files of 200, 100 and 50 Kbytes
	- some scripts
	- 1000 files with names test.0001 thru test.1000 and sizes
	  increasing from 16, 32, ... 16,000 bytes
	- allocate the 1000 files in a cascading hierarchy with 20
	  files and 1 dir at the top level, 40 files and 1 dir at the
	  next level, 80 files and 1 dir at the next level, ....
	- compute and save the checksum for every file

+ run an exerciser script (show-me) that runs some simple commands,
  then recursively descends the file system recomputing and checking
  the checksums ... and capture the output

+ copy the Irix/MIPS filesystem byte-for-byte to a disk partition on
  a Linux/Intel system

+ mount the filesytem read-only on Linux with a kernel that includes:
	- big endian mode for XFS
	- a special hack to avoid log recovery (not done yet, although
	  clean log detection is almost there)

+ run show-me on the Linux system, and hey presto, the same output
  as on the Irix system.

So this demonstrates that basic functions like:
	- superblocks
	- inodes
	- type 1 directories (in several variants)
	- file data blocks for assorted smallish file sizes
are working correctly and compatible between Irix and big endian XFS on
Linux.

Next we expect to be able to exercise the write-side of the endian
changes (all of the code changes have been done), but first there
are some remaining wrinkles in handling the XFS log that need to be
worked through.

Then more regression and coverage testing before the expected
performance bake-off between little and big endian XFS on Linux.

Attached is the output from show-me.


---------- Forwarded message ----------
Date: Fri, 28 Apr 2000 10:54:38 +1000 (EST)
From: Ivan Rayner <ivanr@omen>

=== setup ===
#!/bin/sh
#
# populate files on the IRIX system
#

case `uname`
in
    IRIX*)
	;;
    *)
	echo "Only run setup on IRIX, bozo!"
	exit 1
	;;
esac

rm -rf a b out

dd if=/unix ibs=1024 count=100 of=a 2>/dev/null

# dirs are b, b/b, b/b/b, b/b/b/b, ... each populated with
# $q files, where $q starts at 10 and doubles with each level
# each file in the series is larger than the previous file by 16 bytes
#
top=`pwd`
q=10
nexti=10
mkdir b
cd b
i=1
nfile=1000
while [ $i -le $nfile ]
do
	dd if=/unix ibs=16 count=$i of=test.`printf "%04d" $i` 2>/dev/null
	t=`expr $i % 50`
	if [ $t -eq 0 ]
	then
		echo " $i of $nfile"
	else
		echo -n .
	fi
	if [ $i -eq $nexti ]
	then
		mkdir b
		cd b
		echo -n D
		q=`expr $q + $q`
		nexti=`expr $nexti + $q`
	fi
	i=`expr $i + 1`
done
echo

cd $top

dd if=/unix ibs=1024 count=50 of=c 2>/dev/null
dd if=/unix ibs=1024 count=200 of=d 2>/dev/null

find . -type f -print \
| sed -e '/^\.\/out$/d' \
| xargs sum \
| sort -r +2 -3 >out

=== show-me ===
#!/bin/sh
#
# demo on either system
#

case `uname`
in
    IRIX*)
	SUM="sum"
	;;
    *)
	# assume Linux
	#
	SUM="sum -s"
	;;
esac

echo "=== setup ==="
cat setup

echo
echo "=== show-me ==="
cat show-me

echo
echo "=== top level ls ==="
ls -la .

echo
echo "=== directories ==="
find . -type d -print \
| while read d
do
    echo "$d: `ls $d | wc -l | sed -e 's/ //g'` entries"
done

echo
echo "=== head and tail of checksums ==="
head -5 out
echo "..."
tail -5 out

echo
echo "=== sum and diff ==="
find . -type f -print \
| sed -e '/^\.\/out$/d' \
| xargs $SUM \
| sort -r +2 -3 \
| diff - out

=== top level ls ===
total 800
drwxr-xr-x    3 root     sys          107 Apr 28 12:02 .
drwxr-xr-x    5 root     sys           51 Feb 21 10:48 ..
-rw-r--r--    1 root     sys       102400 Apr 28 12:02 a
drwxr-xr-x    3 root     sys         4096 Apr 28 12:02 b
-rw-r--r--    1 root     sys        51200 Apr 28 12:02 c
-rwxr-xr-x    1 root     sys          151 Apr 28 11:46 cleanup
-rw-r--r--    1 root     sys       204800 Apr 28 12:02 d
-rw-r--r--    1 root     sys        32136 Apr 28 12:02 out
-rwxr-xr-x    1 root     sys          962 Apr 28 12:01 setup
-rwxr-xr-x    1 root     sys          596 Apr 28 11:46 show-me

=== directories ===
.: 8 entries
./b: 11 entries
./b/b: 21 entries
./b/b/b: 41 entries
./b/b/b/b: 81 entries
./b/b/b/b/b: 161 entries
./b/b/b/b/b/b: 321 entries
./b/b/b/b/b/b/b: 370 entries

=== head and tail of checksums ===
44002 2 ./show-me
7323 2 ./setup
55375 400 ./d
10818 1 ./cleanup
32056 100 ./c
...
7514 20 ./b/b/b/b/b/b/b/test.0634
6758 20 ./b/b/b/b/b/b/b/test.0633
5676 20 ./b/b/b/b/b/b/b/test.0632
5042 20 ./b/b/b/b/b/b/b/test.0631
15288 200 ./a

=== sum and diff ===



From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:15 2000
Received:  by oss.sgi.com id <S305201AbQD1OIE>;
	Fri, 28 Apr 2000 07:08:04 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:20501 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305175AbQD1OIB>;
	Fri, 28 Apr 2000 07:08:01 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA10663
	for <linux-xfs@oss.sgi.com>; Fri, 28 Apr 2000 07:03:13 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA26616; Fri, 28 Apr 2000 09:06:44 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id JAA14710; Fri, 28 Apr 2000 09:06:35 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id JAA07096; Fri, 28 Apr 2000 09:05:02 -0500
Message-Id: <200004281405.JAA07096@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     ananth@cthulhu.engr.sgi.com (R. Ananthanarayanan)
cc:     linux-xfs@oss.sgi.com
Subject: DELALLOC code broke module builds
Date:   Fri, 28 Apr 2000 09:05:02 -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


Ananth, 

It looks like we cannot build pagebuf as a module after your checkin, there
are direct references to variables in the pagebuf code from
truncate_inode_pages.

Steve



From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:15 2000
Received:  by oss.sgi.com id <S305205AbQD1RXZ>;
	Fri, 28 Apr 2000 10:23:25 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:40525 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305202AbQD1RXF>;
	Fri, 28 Apr 2000 10:23:05 -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 KAA07669
	for <linux-xfs@oss.sgi.com>; Fri, 28 Apr 2000 10:18:18 -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 KAA43205 for <linux-xfs@oss.sgi.com>; Fri, 28 Apr 2000 10:19:31 -0700 (PDT)
Message-ID: <3909C839.B5EE1B9F@sgi.com>
Date:   Fri, 28 Apr 2000 10:19:53 -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:     linux-xfs@oss.sgi.com
Subject: Re: DELALLOC code broke module builds
References: <200004281405.JAA07096@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

Steve Lord wrote:
> 
> Ananth,
> 
> It looks like we cannot build pagebuf as a module after your checkin, there
> are direct references to variables in the pagebuf code from
> truncate_inode_pages.
> 

Yes, pagebuf won't build as a module. I'll have to think
about encapsulating the opertions used by shrink_mmap,
truncate_inode_pages, etc. into a suitable function.
Perphaps, kick_pcd() is the thing to do, and make that as
part of inode or super operations? I'll fix it in the next few days.

regards,

ananth.

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:15 2000
Received:  by oss.sgi.com id <S305206AbQD1Rap>;
	Fri, 28 Apr 2000 10:30:45 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:3675 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305202AbQD1Rai>; Fri, 28 Apr 2000 10:30:38 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA08561
	for <linux-xfs@oss.sgi.com>; Fri, 28 Apr 2000 10:34:49 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA79100; Fri, 28 Apr 2000 12:28:05 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id MAA26702; Fri, 28 Apr 2000 12:27:56 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id MAA09282; Fri, 28 Apr 2000 12:26:22 -0500
Message-Id: <200004281726.MAA09282@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: DELALLOC code broke module builds 
In-Reply-To: Message from Rajagopal Ananthanarayanan <ananth@sgi.com> 
   of "Fri, 28 Apr 2000 10:19:53 PDT." <3909C839.B5EE1B9F@sgi.com> 
Date:   Fri, 28 Apr 2000 12:26:22 -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


> 
> Yes, pagebuf won't build as a module. I'll have to think
> about encapsulating the opertions used by shrink_mmap,
> truncate_inode_pages, etc. into a suitable function.
> Perphaps, kick_pcd() is the thing to do, and make that as
> part of inode or super operations? I'll fix it in the next few days.
> 
> regards,
> 
> ananth.

How about just moving the defines of the two variables out to mm/filemap.c
and exporting them to pagebuf?

The code which looks at them will not get triggered unless we have a page
in the right state - which will not happen without someone using pagebuf.

I am building this as I type.

Steve



From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:15 2000
Received:  by oss.sgi.com id <S305207AbQD1SNZ>;
	Fri, 28 Apr 2000 11:13:25 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:7267 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305202AbQD1SNA>; Fri, 28 Apr 2000 11:13:00 -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 LAA06580
	for <linux-xfs@oss.sgi.com>; Fri, 28 Apr 2000 11:17:11 -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 LAA41100; Fri, 28 Apr 2000 11:10:33 -0700 (PDT)
Message-ID: <3909D43A.2FA0ACF3@sgi.com>
Date:   Fri, 28 Apr 2000 11:11:06 -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:     Steve Lord <lord@sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: DELALLOC code broke module builds
References: <200004281726.MAA09282@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

Steve Lord wrote:
> 
> >
> > Yes, pagebuf won't build as a module. I'll have to think
> > about encapsulating the opertions used by shrink_mmap,
> > truncate_inode_pages, etc. into a suitable function.
> > Perphaps, kick_pcd() is the thing to do, and make that as
> > part of inode or super operations? I'll fix it in the next few days.
> >
> > regards,
> >
> > ananth.
> 
> How about just moving the defines of the two variables out to mm/filemap.c
> and exporting them to pagebuf?
> 
> The code which looks at them will not get triggered unless we have a page
> in the right state - which will not happen without someone using pagebuf.
> 
> I am building this as I type.


That should be ok for the time being.

thanks,

ananth.

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:15 2000
Received:  by oss.sgi.com id <S305210AbQD1Stf>;
	Fri, 28 Apr 2000 11:49:35 -0700
Received: from [128.162.8.102] ([128.162.8.102]:54208 "EHLO timbuk.cray.com")
	by oss.sgi.com with ESMTP id <S305208AbQD1StX>;
	Fri, 28 Apr 2000 11:49:23 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id NAA19664 for <linux-xfs@oss.sgi.com>; Fri, 28 Apr 2000 13:49:19 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id NAA76559 for linux-xfs@oss.sgi.com; Fri, 28 Apr 2000 13:49:20 -0500 (CDT)
Date:   Fri, 28 Apr 2000 13:49:20 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Message-Id: <200004281849.NAA76559@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - allow pagebuf to build as a module again
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.3.99pre2-xfs:slinx:60088a
Date:  Fri Apr 28 11:49:01 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux

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

linux/fs/page_buf.c - 1.82
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.82&r2=text&tr2=1.81&f=h
	- Move symbols used by rest of kernel out to rest of kernel, a couple of
	  minor tweaks to pagebufs.

linux/include/linux/mm.h - 1.30
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/mm.h.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h
	- Declarations for pb_delalloc_pages and pcd_waitq

linux/kernel/ksyms.c - 1.41
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kernel/ksyms.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h
	- export pb_delalloc_pages and pcd_waitq to modules

linux/mm/filemap.c - 1.36
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/mm/filemap.c.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h
	- Declare pb_delalloc_pages and pcd_waitq here 


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:15 2000
Received:  by oss.sgi.com id <S305202AbQD1W06>;
	Fri, 28 Apr 2000 15:26:58 -0700
Received: from host196.creativedesign.com ([207.135.94.196]:53256 "HELO
        host196.creativedesign.com") by oss.sgi.com with SMTP
	id <S305163AbQD1W0r>; Fri, 28 Apr 2000 15:26:47 -0700
Received: from eventdriven.org (IDENT:root@localhost.localdomain [127.0.0.1])
	by host196.creativedesign.com (8.9.3/8.9.3) with ESMTP id PAA08380
	for <linux-xfs@oss.sgi.com>; Fri, 28 Apr 2000 15:26:53 -0700
Message-ID: <390A102C.9EBA238E@eventdriven.org>
Date:   Fri, 28 Apr 2000 15:26:52 -0700
From:   Kip Matthew Macy <kip@eventdriven.org>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: no more crash on umount
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

Now that I have compiled in the debug code and taken the time to set up
the serial console
XFS will no longer crash on umount. It still does the large vmalloc and
large vfree but the
system no longer crashes.


-Kip


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:15 2000
Received:  by oss.sgi.com id <S305208AbQD1Wn6>;
	Fri, 28 Apr 2000 15:43:58 -0700
Received: from nic-31-c26-223.mn.mediaone.net ([24.31.26.223]:8713 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S305163AbQD1Wnn>;
	Fri, 28 Apr 2000 15:43:43 -0700
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.9.3/8.9.1) with ESMTP id RAA44552;
	Fri, 28 Apr 2000 17:43:40 -0500 (CDT)
Message-ID: <390A141C.BFF83FCB@thebarn.com>
Date:   Fri, 28 Apr 2000 17:43:40 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Kip Matthew Macy <kip@eventdriven.org>
CC:     linux-xfs@oss.sgi.com
Subject: Re: no more crash on umount
References: <390A102C.9EBA238E@eventdriven.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

Kip Matthew Macy wrote:

> Now that I have compiled in the debug code and taken the time to set up
> the serial console
> XFS will no longer crash on umount. It still does the large vmalloc and
> large vfree but the

The vmalloc and vfree are expected... the messages are debug messages.
I don't think it is related to the crash at unmount.
I would be better if XFS didn't need to use vm alloc'ed memory. but it
wasn't designed around a memory system that could fail to allocate
memory.
The printk's will give us an idea just how many times XFS will go over
the 128k limit currently imposed by the slab allocater.

>
> system no longer crashes.

Hmm ok, don't know if this is good or bad.

At least you have the serial line hooked up, at least you will be able to
capture
more of the debug info.


>
>
> -Kip

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:15 2000
Received:  by oss.sgi.com id <S305237AbQD1W5i>;
	Fri, 28 Apr 2000 15:57:38 -0700
Received: from nic-31-c26-223.mn.mediaone.net ([24.31.26.223]:14089 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S305163AbQD1W5V>;
	Fri, 28 Apr 2000 15:57:21 -0700
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.9.3/8.9.1) with ESMTP id RAA44599;
	Fri, 28 Apr 2000 17:57:16 -0500 (CDT)
Message-ID: <390A174C.75D1393E@thebarn.com>
Date:   Fri, 28 Apr 2000 17:57:16 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: New Bug... 
Content-Type: multipart/mixed;
 boundary="------------418DE3B8CD1757F96C9E7BCC"
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.
--------------418DE3B8CD1757F96C9E7BCC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I haven't looked at it...
any ideas of hand before I go digging to far.



--
Russell Cattelan
cattelan@thebarn.com



--------------418DE3B8CD1757F96C9E7BCC
Content-Type: text/plain; charset=us-ascii;
 name="bug"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="bug"

XFS assertion failed: INT_GET(*XFS_DIR2_DATA_UNUSED_TAG_P_ARCH(dup, ARCH_UNKNOWN), ARCH_UNKNOWN) == (char *)dup - (char *)d, file: xfs_dir2_data.c, line: 155
kernel BUG at xfs_debug.c:86!
Entering kdb (0xc3614000) Panic: invalid operand
due to panic @ 0xc8916215
eax = 0x0000001e ebx = 0x0000000e ecx = 0xc028c6bc edx = 0xc028c6bc
esi = 0xc0ba0160 edi = 0x00000029 esp = <kernel>   eip = 0xc8916215
ebp = 0xc3615ba0  ss = 0xc893752e  cs = 0x00000010 eflags = 0x00010282
 ds = <kernel>    es = 0x00000018 origeax = 0xffffffff &regs = 0xc3615b60
kdb> bt
    EBP       EIP         Function(args)
0xc3615ba0 0xc8916215  assfail+0x2d( 0xc8927c60, 0xc8927a37, 0x9b, 0x160, 0xc0e9b014 )
0xc3615be4 0xc88d93d7  xfs_dir2_data_check+0x217( 0xc58b0010, 0xc6a76000, 0xc0e9b014, 0xc6a76000, 0xc0ba0160 )
0xc3615c64 0xc88d8058  xfs_dir2_block_addname+0x6b8( 0xc3615c80, 0xc3615d5c, 0xc3615d68, 0x4, 0x1 )
0xc3615ce8 0xc88d6bd1  xfs_dir_node_replace+0x489( 0xc0e9b014, 0xc58b0010, 0xc0aac7a0, 0x9, 0x20ffff )
0xc3615da4 0xc890eab1  xfs_create+0x515( 0xc58b0028, 0xc0aac7a0, 0xc3615e98, 0x0, 0x0 )
0xc3615f08 0xc8917f2b  linvfs_common_cr+0x10b( 0xc0abb0c0, 0xc0aac740, 0x8124, 0x1, 0x0 )
0xc3615f24 0xc891803c  linvfs_create+0x18( 0xc0abb0c0, 0xc0aac740, 0x8124, 0xc0abb114, 0xc0aac040 )
0xc3615f48 0xc0136c32  vfs_create+0xbe( 0xc0abb0c0, 0xc0aac740, 0x124, 0xc78c3e00, 0xffffffe9 )
0xc3615f74 0xc0136e19  __open_namei+0x191( 0xc0b4c000, 0x8e42, 0x124, 0x0, 0x4 )
0xc3615f9c 0xc012f282  filp_open+0x56( 0xc0b4c000, 0x8e41, 0x124, 0x0, 0xc3614000 )
0xc3615fbc 0xc012f4ec  sys_open+0x3c( 0x80737a8, 0x8e41, 0x124, 0xe41, 0x21 )
0xc3615fd8 0xc010ace4  system_call+0x34    


--------------418DE3B8CD1757F96C9E7BCC--


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:15 2000
Received:  by oss.sgi.com id <S305240AbQD1XTJ>;
	Fri, 28 Apr 2000 16:19:09 -0700
Received: from f224.law9.hotmail.com ([64.4.9.224]:39951 "HELO hotmail.com")
	by oss.sgi.com with SMTP id <S305163AbQD1XSl>;
	Fri, 28 Apr 2000 16:18:41 -0700
Received: (qmail 63190 invoked by uid 0); 28 Apr 2000 23:18:36 -0000
Message-ID: <20000428231836.63189.qmail@hotmail.com>
Received: from 209.101.115.162 by www.hotmail.com with HTTP;
	Fri, 28 Apr 2000 16:18:36 PDT
X-Originating-IP: [209.101.115.162]
From:   "Lindanne Metley" <mlindanne@hotmail.com>
To:     linux-xfs@oss.sgi.com
Subject: RE: DM-API? Re: XFS for Linux
Date:   Fri, 28 Apr 2000 16:18:36 PDT
Mime-Version: 1.0
Content-Type: text/plain; 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

Obviously I'm not using my company's email address yet. I'm sort of 
exploring this on my own at the moment. We are going to try to implement DM, 
and the plan is to make our work open sourced. So if you would like us to 
port your code to Linux and make it open, I think that can be arranged. (It 
would make at least my life easier.)


>Hi - we have not done the DMAPI work yet but would
>really like the help!
>
>Kevan - can you answer the questions ?
>
>Perhaps we can work something out to give you our
>IRIX code to port ?
>
>Brian
>
> > -----Original Message-----
> > From: Lindanne Metley [mailto:mlindanne@hotmail.com]
> > Sent: Thursday, April 27, 2000 5:50 PM
> > To: linux-xfs@oss.sgi.com
> > Subject: DM-API? Re: XFS for Linux
> >
> >
> > I heard SGI has already implemented the DM-API for the XFS
> > being ported to
> > Linux. I'm working with some people who are also thinking
> > about doing the
> > DM-API for Linux. If SGI cannot yet release the source code,
> > could you still
> > talk about the user space<-->kernel space protocol so that we
> > could be
> > compatiable?
> >
> > I was thinking of turning each function+parameter list into a
> > struct with a
> > function code, and then use ioctl to move the struct back and
> > forth, but if
> > you can discuss a better method I would be happy to hear about it.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:16 2000
Received:  by oss.sgi.com id <S305176AbQEAHiF>;
	Mon, 1 May 2000 00:38:05 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:22565 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305163AbQEAHhg>;
	Mon, 1 May 2000 00:37:36 -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 AAA14014; Mon, 1 May 2000 00:32:49 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id AAA76284; Mon, 1 May 2000 00:37:31 -0700 (PDT)
Date:   Mon, 1 May 2000 00:37:31 -0700 (PDT)
Message-Id: <200005010737.AAA76284@info.engr.sgi.com>
X-Pv-Incident: 789427 
webPV:  wobbly.melbourne.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (nathans@engr.sgi.com)
Subject: BUG 789427 - vp->v_count > 0 on unlink
To:     mostek@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=789427

Submitter : nathans                   Submitter Domain : engr               
Assigned Engineer : mostek            Assigned Domain : sgi.com             
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 1                          
Project : xfs-linux                   Status : open                         
Description :
On Apr 15,  5:04am, Jim Mostek wrote:
> Subject: Re: vp->v_count > 0 on unlink
> Can you open a PV for this?
> 

here it is - sorry about the delay - i've been away over easter.

cheers.


--- Forwarded mail from <nathans@wobbly.melbourne.sgi.com> ("Nathan Scott")

From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Date: Fri, 14 Apr 2000 08:58:47 -0500
To: slinx-xfs@engr
Subject: vp->v_count > 0 on unlink

hi,

I somehow managed to trip this assertion yesterday, but have been
unable to reproduce it since.  this was after creating a few
hundred directories with several files of varying size in each,
then iteratively removing them (files and directories).

this was with yesterdays top-of-tree source.  not sure whether its
useful to anyone, but here it is anyway...


[root@troppo ~]# XFS assertion failed: vp->v_count > 0, file: xfs_vnode.c, line: 890
kernel BUG at xfs_debug.c:86!
Entering kdb (0xc4a96000) on processor 0 Panic: invalid operand
due to panic @ 0xc01f3b39
eax = 0x0000001e ebx = 0x00000202 ecx = 0xc03859e4 edx = 0xc4c55f6c
esi = 0xc038c680 edi = 0xc3f3d5b8 esp = <kernel>   eip = 0xc01f3b39
ebp = 0xc4a97e0c  ss = 0xc02d702e  cs = 0x00000010 eflags = 0x00010086
 ds = <kernel>    es = 0x00000018 origeax = 0xffffffff &regs = 0xc4a97dcc
[0]kdb> bt
    EBP       EIP         Function(args)
0xc4a97e0c 0xc01f3b39  assfail+0x2d( 0xc02daeec, 0xc02daa89, 0x37a, 0xc3f3d5b8, 0xc038c680 )
0xc4a97e40 0xc01ff709  vn_rele+0x85( 0xc3f3d5b8, 0xc54bce40, 0xc4a97e6c, 0xc015cea8 )
0xc4a97e50 0xc01fc023  linvfs_put_inode+0x17( 0xc54bce40, 0xc0f8b000, 0xc54bce40, 0xc4fd6b00 )
0xc4a97e6c 0xc015cea8  iput+0x38( 0xc54bce40, 0x0, 0xc54bce40, 0xc4a97f54 )
0xc4a97e80 0xc015af4d  d_delete+0x49( 0xc0f8b000, 0xffffffff, 0xc4fd6b00, 0xc4fd6b98 )
0xc4a97f54 0xc01f508a  linvfs_unlink+0x96( 0xc4fd6b00, 0xc0f8b000, 0xc0f8b080, 0xfffffffe, 0x0 )
0xc4a97f78 0xc01543ab  vfs_unlink+0x12b( 0xc4fd6b00, 0xc0f8b000, 0xc4a96000, 0xc14b1000, 0x0 )
0xc4a97f98 0xc015448f  do_unlink+0x97( 0xc14b1000, 0x0, 0xc4a96000, 0x0, 0xbffffc55 )
0xc4a97fbc 0xc0154587  sys_unlink+0x8b( 0xbffffc55, 0xbffffab0, 0xbffffaa0, 0x0, 0xbffffc55 )
0xc4a97fd8 0xc010a538  system_call+0x34
[0]kdb>


-- 
Nathan


---End of forwarded mail from <nathans@wobbly.melbourne.sgi.com> ("Nathan Scott")

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:16 2000
Received:  by oss.sgi.com id <S305193AbQEANJ5>;
	Mon, 1 May 2000 06:09:57 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:57450 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305163AbQEANJb>;
	Mon, 1 May 2000 06:09:31 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA20806
	for <linux-xfs@oss.sgi.com>; Mon, 1 May 2000 06:04:39 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA78776; Mon, 1 May 2000 08:07:56 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA00731; Mon, 1 May 2000 08:07:46 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id IAA69586; Mon, 1 May 2000 08:07:53 -0500 (CDT)
Message-Id: <200005011307.IAA69586@fsgi344.americas.sgi.com>
Subject: Re: New Bug...
To:     cattelan@thebarn.com (Russell Cattelan), overby@sgi.com,
        dpd@whidbey.com (Doug Doucette)
Date:   Mon, 1 May 2000 08:07:52 -0500 (CDT)
Cc:     dxm@clouds.melbourne.sgi.com (Daniel Moore), linux-xfs@oss.sgi.com
In-Reply-To: <390A174C.75D1393E@thebarn.com> from "Russell Cattelan" at Apr 28, 2000 05:57:16 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


Glen Overby knows the dir2 format the best after
Doug Doucette.

Glen, Doug, any suggestions on what to look for
when hitting the last assert below:

        /*
         * Loop over the data/unused entries.
         */
        while (p < endp) {
                dup = (xfs_dir2_data_unused_t *)p;
                /*
                 * If it's unused, look for the space in the bestfree table.
                 * If we find it, account for that, else make sure it
                 * doesn't need to be there.
                 */
                if (INT_GET(dup->freetag, ARCH_UNKNOWN) == XFS_DIR2_DATA_FREE_TAG) {
                        ASSERT(lastfree == 0);
                        ASSERT(INT_GET(*XFS_DIR2_DATA_UNUSED_TAG_P_ARCH(dup, ARCH_UNK
NOWN), ARCH_UNKNOWN) ==
                               (char *)dup - (char *)d);


Jim

>
>This is a multi-part message in MIME format.
>--------------418DE3B8CD1757F96C9E7BCC
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>I haven't looked at it...
>any ideas of hand before I go digging to far.
>
>
>
>--
>Russell Cattelan
>cattelan@thebarn.com
>
>
>
>--------------418DE3B8CD1757F96C9E7BCC
>Content-Type: text/plain; charset=us-ascii;
> name="bug"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline;
> filename="bug"
>
>XFS assertion failed: INT_GET(*XFS_DIR2_DATA_UNUSED_TAG_P_ARCH(dup, ARCH_UNKNOWN), ARCH_UNKNOWN) == (char *)dup - (char *)d, file: xfs_dir2_data.c, line: 155
>kernel BUG at xfs_debug.c:86!
>Entering kdb (0xc3614000) Panic: invalid operand
>due to panic @ 0xc8916215
>eax = 0x0000001e ebx = 0x0000000e ecx = 0xc028c6bc edx = 0xc028c6bc
>esi = 0xc0ba0160 edi = 0x00000029 esp = <kernel>   eip = 0xc8916215
>ebp = 0xc3615ba0  ss = 0xc893752e  cs = 0x00000010 eflags = 0x00010282
> ds = <kernel>    es = 0x00000018 origeax = 0xffffffff &regs = 0xc3615b60
>kdb> bt
>    EBP       EIP         Function(args)
>0xc3615ba0 0xc8916215  assfail+0x2d( 0xc8927c60, 0xc8927a37, 0x9b, 0x160, 0xc0e9b014 )
>0xc3615be4 0xc88d93d7  xfs_dir2_data_check+0x217( 0xc58b0010, 0xc6a76000, 0xc0e9b014, 0xc6a76000, 0xc0ba0160 )
>0xc3615c64 0xc88d8058  xfs_dir2_block_addname+0x6b8( 0xc3615c80, 0xc3615d5c, 0xc3615d68, 0x4, 0x1 )
>0xc3615ce8 0xc88d6bd1  xfs_dir_node_replace+0x489( 0xc0e9b014, 0xc58b0010, 0xc0aac7a0, 0x9, 0x20ffff )
>0xc3615da4 0xc890eab1  xfs_create+0x515( 0xc58b0028, 0xc0aac7a0, 0xc3615e98, 0x0, 0x0 )
>0xc3615f08 0xc8917f2b  linvfs_common_cr+0x10b( 0xc0abb0c0, 0xc0aac740, 0x8124, 0x1, 0x0 )
>0xc3615f24 0xc891803c  linvfs_create+0x18( 0xc0abb0c0, 0xc0aac740, 0x8124, 0xc0abb114, 0xc0aac040 )
>0xc3615f48 0xc0136c32  vfs_create+0xbe( 0xc0abb0c0, 0xc0aac740, 0x124, 0xc78c3e00, 0xffffffe9 )
>0xc3615f74 0xc0136e19  __open_namei+0x191( 0xc0b4c000, 0x8e42, 0x124, 0x0, 0x4 )
>0xc3615f9c 0xc012f282  filp_open+0x56( 0xc0b4c000, 0x8e41, 0x124, 0x0, 0xc3614000 )
>0xc3615fbc 0xc012f4ec  sys_open+0x3c( 0x80737a8, 0x8e41, 0x124, 0xe41, 0x21 )
>0xc3615fd8 0xc010ace4  system_call+0x34    
>
>
>--------------418DE3B8CD1757F96C9E7BCC--
>


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:16 2000
Received:  by oss.sgi.com id <S305265AbQEARKI>;
	Mon, 1 May 2000 10:10:08 -0700
Received: from c008-h019.c008.sfo.cp.net ([209.228.14.208]:10957 "HELO
        c008.sfo.cp.net") by oss.sgi.com with SMTP id <S305163AbQEARJv>;
	Mon, 1 May 2000 10:09:51 -0700
Received: (cpmta 12931 invoked from network); 1 May 2000 10:09:44 -0700
Received: from bh-cw131-055.pool.dircon.co.uk (HELO Penguin) (194.112.62.55)
  by smtp.revelation.net with SMTP; 1 May 2000 10:09:44 -0700
X-Sent: 1 May 2000 17:09:44 GMT
From:   Ralph Pickering <ralph@revelation.net>
To:     linux-xfs@oss.sgi.com
Subject: Well done
Date:   Tue, 2 May 2000 00:22:15 +0100
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <38F36DC2.29E6EAF7@opensourcegroup.com>
In-Reply-To: <38F36DC2.29E6EAF7@opensourcegroup.com>
MIME-Version: 1.0
Message-Id: <00050200385100.00967@Penguin>
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

I have been waiting with bated breath for XFS since SGI announced it's
intention to release it for Linux, and finally plucked up courage to install it
on my system yesterday. As it is not even at Beta stage, I expected no end of
compile problems etc, and was blown away when it compiled and installed
flawlessly. I am not exactly a Linux newbie, but my knowledge of filesystems
etc could cover a postage stamp, and even so, it only took about two hours to
install a fresh copy of Redhat, compile the kernel, and create the filesystem.

I'm not sure how one goes about creating a root filesystem as XFS. Can you
convert from ext2, or do you have to install on top of an existing XFS
filesystem? Perhaps I'll leave that on ice for a while... but it's something
for the FAQ when that comes about.

In any case I for one would like to say "well done" to all the developers and
testers.

Thanks

Ralph.


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:16 2000
Received:  by oss.sgi.com id <S305270AbQEASmS>;
	Mon, 1 May 2000 11:42:18 -0700
Received: from nwcst312.netaddress.usa.net ([204.68.23.57]:60587 "HELO convert rfc822-to-8bitN ORCPTii
        nwcst312.netaddress.usa.net") by oss.sgi.com with SMTP
	id <S305268AbQEASmJ>; Mon, 1 May 2000 11:42:09 -0700
Received: (qmail 13209 invoked by uid 60001); 1 May 2000 18:42:08 -0000
Message-ID: <20000501184208.13208.qmail@nwcst312.netaddress.usa.net>
Received: from 204.68.23.57 by nwcst312 for [129.13.73.14] via web-mailer(M3.4.0.33) on Mon May  1 18:42:08 GMT 2000
Date:   1 May 00 12:42:08 MDT
From:   <jhatala@usa.net>
To:     linux-xfs@oss.sgi.com
Subject: Bug :   xfs mount via loop panics
X-Mailer: USANET web-mailer (M3.4.0.33)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
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

I used the latest CVS-version of XFS that I retrieved yesterday (30.3.2k).

mount -t xfs -o loop file /mnt

resulted in an immediate kernel panic (no oops):

Kernel panic: loop: block not locked

The file resides on an ext2 partition of an IDE drive.  I created that
file by simply copying a small partition.  mount of that partition
goes fine.  Well I guess that's all I need to report.

BTW Is there a backport for 2.2.x kernels?

Bye,

jh


PS. please use CC jhatala@usa.net in an eventual reply

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:16 2000
Received:  by oss.sgi.com id <S305272AbQEAS6s>;
	Mon, 1 May 2000 11:58:48 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23911 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305268AbQEAS6h>; Mon, 1 May 2000 11:58:37 -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 MAA05350; Mon, 1 May 2000 12:02:51 -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 LAA64440; Mon, 1 May 2000 11:58:06 -0700 (PDT)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA81363; Mon, 1 May 2000 11:56:46 -0700 (PDT)
Date:   Mon, 1 May 2000 11:56:46 -0700 (PDT)
Message-Id: <200005011856.LAA81363@info.engr.sgi.com>
X-Pv-Incident: 789427 
webPV:  tiki.cray.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (jtk@sgi.com)
Subject: UPDATE 789427 - vp->v_count > 0 on unlink
To:     jtk@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=789427

 Status : open                         Priority : 1                         
*Assigned Engineer : jtk               Submitter : nathans                  
 Opened Date : 05/01/00               *Modified User : jtk                  
*Modified User Domain : sgi.com       *Description :
On Apr 15,  5:04am, Jim Mostek wrote:
> Subject: Re: vp->v_count > 0 on unlink
> Can you open a PV for this?
> 

here it is - sorry about the delay - i've been away over easter.

cheers.



.....


==========================
ADDITIONAL INFORMATION (UPDATE)
From: jtk@sgi.com (BugWorks)
Date: May 01 2000 11:56:45AM
==========================

Assign this one to Ted..

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:16 2000
Received:  by oss.sgi.com id <S305268AbQEAVWA>;
	Mon, 1 May 2000 14:22:00 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:51983 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305275AbQEAVV3>;
	Mon, 1 May 2000 14:21:29 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA03090
	for <linux-xfs@oss.sgi.com>; Mon, 1 May 2000 14:16:41 -0700 (PDT)
	mail_from (overby@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA65384; Mon, 1 May 2000 16:20:12 -0500 (CDT)
Received: from zhadum.americas.sgi.com (zhadum.americas.sgi.com [128.162.184.32]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id QAA27847; Mon, 1 May 2000 16:20:02 -0500 (CDT)
Received: by zhadum.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id QAA71967; Mon, 1 May 2000 16:20:08 -0500 (CDT)
Message-Id: <200005012120.QAA71967@zhadum.americas.sgi.com>
Date:   Mon, 1 May 2000 16:20:08 -0500 (CDT)
From:   Glen Overby <overby@sgi.com>
To:     Jim Mostek <mostek@sgi.com>
Cc:     cattelan@thebarn.com (Russell Cattelan),
        dpd@whidbey.com (Doug Doucette),
        dxm@clouds.melbourne.sgi.com (Daniel Moore),
        linux-xfs@oss.sgi.com
Subject: Re: New Bug...
In-Reply-To: message from Jim Mostek sent 1 May 2000
References: <390A174C.75D1393E@thebarn.com>
	<200005011307.IAA69586@fsgi344.americas.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

Jim Mostek wrote:
> 
> Glen Overby knows the dir2 format the best after
> Doug Doucette.
> 
> Glen, Doug, any suggestions on what to look for
> when hitting the last assert below:
> 
>         /*
>          * Loop over the data/unused entries.
>          */
>         while (p < endp) {
>                 dup = (xfs_dir2_data_unused_t *)p;
>                 /*
>                  * If it's unused, look for the space in the bestfree table.
>                  * If we find it, account for that, else make sure it
>                  * doesn't need to be there.
>                  */
>                 if (INT_GET(dup->freetag, ARCH_UNKNOWN) == XFS_DIR2_DATA_FREE_TAG) {
>                         ASSERT(lastfree == 0);
>                         ASSERT(INT_GET(*XFS_DIR2_DATA_UNUSED_TAG_P_ARCH(dup, ARCH_UNK
> NOWN), ARCH_UNKNOWN) ==
>                                (char *)dup - (char *)d);

Its a block format directory.  Its a small directory that has a
single-level b+tree and the directory entries in one directory block.

The XFS_DIR2_DATA_UNUSED_TAG_P_ARCH and INT_GET aren't in Irix; I
assume this is mac's big-endian / little-endian code.

So the ASSERT is comparing the tag values of an unused directory entry
and its offset into the data block.  It's checking if the unused
directory entry's 'tag' field is correct.  Bug could be a bad tag
value or a bad assert.

To know I'd need to know what those two macros do.  Tell me where your
ism is; the last time I looked for it, I couldn't find it.

If you've got a dump, get the values of: dup, d and *dup (it's an
xfs_dir2_data_unused_t).  While you're at it, dump *d
(xfs_dir2_data_hdr_t) so we can see the bestfree entries.  After that
we'll look at the remove-name code that sets the tag value.

Glen

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:16 2000
Received:  by oss.sgi.com id <S305279AbQEAVYA>;
	Mon, 1 May 2000 14:24:00 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:31504 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305275AbQEAVXt>;
	Mon, 1 May 2000 14:23:49 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA03384
	for <linux-xfs@oss.sgi.com>; Mon, 1 May 2000 14:19:02 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA55067; Mon, 1 May 2000 16:22:26 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id QAA27958; Mon, 1 May 2000 16:22:18 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id QAA79624; Mon, 1 May 2000 16:22:25 -0500 (CDT)
Message-Id: <200005012122.QAA79624@fsgi344.americas.sgi.com>
Subject: Re: New Bug...
To:     overby@sgi.com (Glen Overby)
Date:   Mon, 1 May 2000 16:22:24 -0500 (CDT)
Cc:     mostek@sgi.com (Jim Mostek),
        cattelan@thebarn.com (Russell Cattelan),
        dpd@whidbey.com (Doug Doucette),
        dxm@clouds.melbourne.sgi.com (Daniel Moore),
        linux-xfs@oss.sgi.com
In-Reply-To: <200005012120.QAA71967@zhadum.americas.sgi.com> from "Glen Overby" at May 01, 2000 04:20:08 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


Here is the start of my .workarea:

workarea.sm_tree_alias : 2.3.99pre2-xfs
workarea.sm_machine : bonnie.engr.sgi.com
workarea.sm_location : /isms/slinx/2.3.99pre2-xfs

Thanks,

Jim

>
>Jim Mostek wrote:
>> 
>> Glen Overby knows the dir2 format the best after
>> Doug Doucette.
>> 
>> Glen, Doug, any suggestions on what to look for
>> when hitting the last assert below:
>> 
>>         /*
>>          * Loop over the data/unused entries.
>>          */
>>         while (p < endp) {
>>                 dup = (xfs_dir2_data_unused_t *)p;
>>                 /*
>>                  * If it's unused, look for the space in the bestfree table.
>>                  * If we find it, account for that, else make sure it
>>                  * doesn't need to be there.
>>                  */
>>                 if (INT_GET(dup->freetag, ARCH_UNKNOWN) == XFS_DIR2_DATA_FREE_TAG) {
>>                         ASSERT(lastfree == 0);
>>                         ASSERT(INT_GET(*XFS_DIR2_DATA_UNUSED_TAG_P_ARCH(dup, ARCH_UNK
>> NOWN), ARCH_UNKNOWN) ==
>>                                (char *)dup - (char *)d);
>
>Its a block format directory.  Its a small directory that has a
>single-level b+tree and the directory entries in one directory block.
>
>The XFS_DIR2_DATA_UNUSED_TAG_P_ARCH and INT_GET aren't in Irix; I
>assume this is mac's big-endian / little-endian code.
>
>So the ASSERT is comparing the tag values of an unused directory entry
>and its offset into the data block.  It's checking if the unused
>directory entry's 'tag' field is correct.  Bug could be a bad tag
>value or a bad assert.
>
>To know I'd need to know what those two macros do.  Tell me where your
>ism is; the last time I looked for it, I couldn't find it.
>
>If you've got a dump, get the values of: dup, d and *dup (it's an
>xfs_dir2_data_unused_t).  While you're at it, dump *d
>(xfs_dir2_data_hdr_t) so we can see the bestfree entries.  After that
>we'll look at the remove-name code that sets the tag value.
>
>Glen
>


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:16 2000
Received:  by oss.sgi.com id <S305280AbQEAV7a>;
	Mon, 1 May 2000 14:59:30 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:37145 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305275AbQEAV7D>;
	Mon, 1 May 2000 14:59:03 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA07432
	for <linux-xfs@oss.sgi.com>; Mon, 1 May 2000 14:54:15 -0700 (PDT)
	mail_from (overby@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA75947; Mon, 1 May 2000 16:57:46 -0500 (CDT)
Received: from zhadum.americas.sgi.com (zhadum.americas.sgi.com [128.162.184.32]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id QAA29193; Mon, 1 May 2000 16:57:37 -0500 (CDT)
Received: by zhadum.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id QAA71435; Mon, 1 May 2000 16:57:44 -0500 (CDT)
Message-Id: <200005012157.QAA71435@zhadum.americas.sgi.com>
Date:   Mon, 1 May 2000 16:57:44 -0500 (CDT)
From:   Glen Overby <overby@sgi.com>
To:     Jim Mostek <mostek@sgi.com>
Cc:     cattelan@thebarn.com (Russell Cattelan),
        dpd@whidbey.com (Doug Doucette),
        dxm@clouds.melbourne.sgi.com (Daniel Moore),
        linux-xfs@oss.sgi.com
Subject: Re: New Bug...
In-Reply-To: message from Jim Mostek sent 1 May 2000
References: <200005012120.QAA71967@zhadum.americas.sgi.com>
	<200005012122.QAA79624@fsgi344.americas.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


If you're building XFS_ARCH_MODE_NATIVE, all the endian macros turn
into no-ops.  Otherwise (XFS_ARCH_MODE_MIPS), they do swapping of
unsigned so I think the macros are okay.

So this check caught a bug somewhere else in dir2.  Lets get the
pointer values & directory block out of the dump.

Glen

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:16 2000
Received:  by oss.sgi.com id <S305283AbQEAXuu>;
	Mon, 1 May 2000 16:50:50 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:32522 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305275AbQEAXu3>; Mon, 1 May 2000 16:50:29 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA09405
	for <linux-xfs@oss.sgi.com>; Mon, 1 May 2000 16:54:38 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From:   cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA81574; Mon, 1 May 2000 18:49:07 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id SAA01584; Mon, 1 May 2000 18:48:57 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id SAA24263; Mon, 1 May 2000 18:49:04 -0500
Date:   Mon, 01 May 2000 18:49:02 -0500
Message-ID: <14606.6126.666632.79708G@gibble.americas.sgi.com>
To:     overby@sgi.com
Cc:     mostek@sgi.com, dpd@whidbey.com, dxm@clouds.melbourne.sgi.com,
        linux-xfs@oss.sgi.com
Subject: Re: New Bug...
In-Reply-To: In your message of "Mon, 1 May 2000 16:20:08 -0500 (CDT)"
	<200005012120.QAA71967@zhadum.americas.sgi.com>
References: <390A174C.75D1393E@thebarn.com>
	<200005011307.IAA69586@fsgi344.americas.sgi.com>
	<200005012120.QAA71967@zhadum.americas.sgi.com>
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I'm begining to think this has more to do with our corruption problem
than anything else.

This is what I got from the latest panic.





0x10 entry inumber 17202865 namelen 1 name "." tag 0x10
0x20 entry inumber 836488 namelen 2 name ".." tag 0x20
0x30 entry inumber 21699385 namelen 3 name "arc" tag 0x30
0x40 entry inumber 25916672 namelen 3 name "pci" tag 0x40
0x50 unused freetag 0xffff length 0x1cb tag 0x51
0x21b entry inumber 32768 namelen 0 name "" tag 0xc500
0x22b entry inumber 23065554927484928 namelen 0 name "" tag 0x0
0x23b entry inumber -3314508588250947072 namelen 0 name "" tag 0x52
0x24b entry inumber 32768 namelen 0 name "" tag 0xe700
0x25b entry inumber 23349228927451136 namelen 0 name "" tag 0x0
0x26b entry inumber 1008947054024794112 namelen 1 name "" tag 0x53
0x27b entry inumber 4563435520 namelen 0 name "" tag 0x1300
0x28b entry inumber 23546041508823041 namelen 0 name "" tag 0x0
0x29b entry inumber 1585407806328263680 namelen 1 name "" tag 0x54
0x2ab entry inumber 4697653248 namelen 0 name "" tag 0x1900
0x2bb entry inumber 23731858973917185 namelen 0 name "" tag 0x0
0x2cb entry inumber 2161868558631730688 namelen 1 name "" tag 0x54
0x2db entry inumber 4815093760 namelen 0 name "" tag 0x2000
0x2eb entry inumber 23931970090172417 namelen 0 name "" tag 0x0
0x2fb entry inumber 2594214122859344896 namelen 1 name "" tag 0x55
0x30b entry inumber 4915757056 namelen 0 name "" tag 0x2700
0x31b entry inumber 24133180718055425 namelen 0 name "" tag 0x0
0x32b entry inumber 3026559687086959616 namelen 1 name "" tag 0x56
0x33b entry inumber 5016420352 namelen 0 name "" tag 0x2c00
0x34b entry inumber 24339888904077313 namelen 0 name "" tag 0x0
0x35b entry inumber 3314790063238719488 namelen 1 name "" tag 0x56
0x36b entry inumber 5083529216 namelen 0 name "" tag 0x3000
0x37b entry inumber 24526805880799233 namelen 0 name "" tag 0x0
0x38b entry inumber 3963308409580114176 namelen 1 name "" tag 0x57
0x39b entry inumber 5234524160 namelen 0 name "" tag 0x3a00
0x3ab entry inumber 24734613578448897 namelen 0 name "" tag 0x0
0x3bb entry inumber 4395653973807731456 namelen 1 name "" tag 0x58
0x3cb entry inumber 5351964672 namelen 0 name "" tag 0x4000
0x3db entry inumber 24968809555165185 namelen 0 name "" tag 0x0
0x3eb entry inumber 4755941943997426944 namelen 1 name "" tag 0x59
0x3fb entry inumber 5419073536 namelen 0 name "" tag 0x4400
0x40b entry inumber 25185413345837057 namelen 0 name "" tag 0x0
0x41b entry inumber 5044172320149187840 namelen 1 name "" tag 0x59
0x42b entry inumber 32768 namelen 0 name "" tag 0x6f00
0x43b entry inumber 26502628275912705 namelen 0 name "" tag 0x0
0x44b entry inumber -6917388290146421504 namelen 2 name "" tag 0x60
0x45b entry inumber 32768 namelen 0 name "" tag 0xf500
0x46b entry inumber 27349252229300226 namelen 0 name "" tag 0x0
0x47b entry inumber 4323596379770420480 namelen 3 name "" tag 0x0
0x48b entry inumber 41472 namelen 0 name "" tag 0x0
0x49b entry inumber 27541666764161024 namelen 0 name "" tag 0x0
0x4ab entry inumber 140737494775552 namelen 0 name "" tag 0x63
0x4bb entry inumber 1627422720 namelen 0 name "" tag 0x0
0x4cb entry inumber 28032048950149120 namelen 0 name "" tag 0x0
0x4db entry inumber -5836524379577186560 namelen 0 name "" tag 0x0
0x4eb entry inumber 41472 namelen 0 name "" tag 0x0
0x4fb entry inumber 28475152136142848 namelen 0 name "" tag 0x0
0x50b entry inumber 178120883699712 namelen 0 name "" tag 0x65
0x51b entry inumber 33280 namelen 0 name "" tag 0x4e00
0x52b entry inumber 0 namelen 0 name "" tag 0x0
0x53b entry inumber 142936518276096 namelen 0 name "" tag 0x65
0x54b entry inumber 1224769536 namelen 0 name "" tag 0x4d00
0x55b entry inumber 28770920764014592 namelen 0 name "" tag 0x0
0x56b entry inumber 140737495061760 namelen 0 name "" tag 0x66
0x57b entry inumber 1677754368 namelen 0 name "" tag 0x0
0x58b entry inumber 29078784019791872 namelen 0 name "" tag 0x0
0x59b entry inumber 140737495135232 namelen 0 name "" tag 0x68
0x5ab entry inumber 2298511360 namelen 0 name "" tag 0x0
0x5bb entry inumber 29470210159280128 namelen 0 name "" tag 0x0
0x5cb entry inumber -7854137012638919680 namelen 0 name "" tag 0x68
0x5db entry inumber 32768 namelen 0 name "" tag 0xe200
0x5eb entry inumber 30024364019679232 namelen 0 name "" tag 0x0
0x5fb entry inumber -720435202883916288 namelen 0 name "" tag 0x6b
0x60b entry inumber 4194336768 namelen 0 name "" tag 0xfc00
0x61b entry inumber 30247564880117760 namelen 0 name "" tag 0x0
0x62b entry inumber 1297177430178215680 namelen 1 name "" tag 0x6d
0x63b entry inumber 32768 namelen 0 name "" tag 0x5000
0x64b entry inumber 30987536205611009 namelen 0 name "" tag 0x0
0x65b entry inumber 6125036230719463680 namelen 1 name "" tag 0x6e
0x66b entry inumber 5955944448 namelen 0 name "" tag 0x0
0x67b entry inumber 31161259042799616 namelen 0 name "" tag 0x0
0x68b entry inumber 140737495617280 namelen 0 name "" tag 0x6f
0x69b entry inumber 6744473600 namelen 0 name "" tag 0x0
0x6ab entry inumber 31298697996271616 namelen 0 name "" tag 0x0
0x6bb entry inumber 142936518904320 namelen 0 name "" tag 0x6f
0x6cb entry inumber 32768 namelen 0 name "" tag 0x5300
0x6db entry inumber 0 namelen 0 name "" tag 0x0
0x6eb entry inumber 178120883699712 namelen 0 name "" tag 0x73
0x6fb entry inumber 33280 namelen 0 name "" tag 0x4c00
0x70b entry inumber 32423498391486464 namelen 0 name "" tag 0x0
0x71b entry inumber 5620633072454290432 namelen 0 name "" tag 0x73
0x72b entry inumber 1325432832 namelen 0 name "" tag 0x5000
0x73b entry inumber 32545544182169600 namelen 0 name "" tag 0x0
0x74b entry inumber 5908863448606030336 namelen 0 name "" tag 0x73
0x75b entry inumber 1409318912 namelen 0 name "" tag 0x5500
0x76b entry inumber 32664291437969408 namelen 0 name "" tag 0x0
0x77b entry inumber 6341209012833625344 namelen 0 name "" tag 0x74
0x78b entry inumber 1509982208 namelen 0 name "" tag 0x5b00
0x79b entry inumber 32779740158885888 namelen 0 name "" tag 0x0
0x7ab entry inumber 7133842547250859776 namelen 0 name "" tag 0x74
0x7bb entry inumber 1677754368 namelen 0 name "" tag 0x6500
0x7cb entry inumber 32901785949569024 namelen 0 name "" tag 0x0
0x7db entry inumber 7422072923402600704 namelen 0 name "" tag 0x75
0x7eb entry inumber 1828749312 namelen 0 name "" tag 0x6e00
0x7fb entry inumber 33031528321646592 namelen 0 name "" tag 0x0
0x80b entry inumber 8070591269743982336 namelen 0 name "" tag 0x75
0x81b entry inumber 2013298688 namelen 0 name "" tag 0x7900
0x82b entry inumber 33160171182096384 namelen 0 name "" tag 0x0
0x83b entry inumber -9151173705320764416 namelen 0 name "" tag 0x76
0x84b entry inumber 32768 namelen 0 name "" tag 0x9f00
0x85b entry inumber 33325097926262784 namelen 0 name "" tag 0x0
0x86b entry inumber -6629157913993230336 namelen 0 name "" tag 0x0
0x87b entry inumber 41472 namelen 0 name "" tag 0x0
0x88b entry inumber 33477930042523648 namelen 0 name "" tag 0x0
0x89b entry inumber 3242732469202913280 namelen 0 name "" tag 0x77
0x8ab entry inumber 889225216 namelen 0 name "" tag 0x0
0x8bb entry inumber 33563691949490176 namelen 0 name "" tag 0x0
0x8cb entry inumber 140737496172288 namelen 0 name "" tag 0x7b
0x8db entry inumber 2432729088 namelen 0 name "" tag 0x0
0x8eb entry inumber 35816591274803200 namelen 0 name "" tag 0x0
0x8fb entry inumber 178120883699712 namelen 0 name "" tag 0x7f
0x90b entry inumber 33280 namelen 0 name "" tag 0x0
0x91b entry inumber 35884760995725312 namelen 0 name "" tag 0x0
0x92b entry inumber 178120883699712 namelen 0 name "" tag 0x0
0x93b entry inumber 41472 namelen 0 name "" tag 0x0
0x94b entry inumber 35983717042225152 namelen 0 name "" tag 0x0
0x95b entry inumber -8862943329168394752 namelen 0 name "" tag 0x80
0x96b entry inumber 32768 namelen 0 name "" tag 0x8f00
0x97b entry inumber 0 namelen 0 name "" tag 0x0
0x98b entry inumber 142936520043264 namelen 0 name "" tag 0x80
0x99b entry inumber 32768 namelen 0 name "" tag 0x3500
0x9ab entry inumber 36366347088691200 namelen 0 name "" tag 0x0
0x9bb entry inumber 4683884349962169344 namelen 0 name "" tag 0x81
0x9cb entry inumber 32768 namelen 0 name "" tag 0x5100
0x9db entry inumber 36920500949090304 namelen 0 name "" tag 0x0
0x9eb entry inumber -6701215508030233088 namelen 0 name "" tag 0x85
0x9fb entry inumber 32768 namelen 0 name "" tag 0xc700
0xa0b entry inumber 37621989367611392 namelen 0 name "" tag 0x0
0xa1b entry inumber -2810105429982034432 namelen 0 name "" tag 0x86
0xa2b entry inumber 5217746944 namelen 0 name "" tag 0x0
0xa3b entry inumber 38026609646632960 namelen 0 name "" tag 0x0
0xa4b entry inumber 140737497218304 namelen 0 name "" tag 0x8b
0xa5b entry inumber 6274711552 namelen 0 name "" tag 0x0
0xa6b entry inumber 39316336786014208 namelen 0 name "" tag 0x0
0xa7b entry inumber 5332402696304179200 namelen 0 name "" tag 0x8b
0xa8b entry inumber 1258323968 namelen 0 name "" tag 0x4e00
0xa9b entry inumber 39481263530180608 namelen 0 name "" tag 0x0
0xaab entry inumber 6557381794949003776 namelen 0 name "" tag 0x8c
0xabb entry inumber 1677754368 namelen 0 name "" tag 0x7400
0xacb entry inumber 39694568785969152 namelen 0 name "" tag 0x0
0xadb entry inumber -9007058517243385600 namelen 0 name "" tag 0x8d
0xaeb entry inumber 2231402496 namelen 0 name "" tag 0x8600
0xafb entry inumber 39935361832452096 namelen 0 name "" tag 0x0
0xb0b entry inumber -7133561072257126400 namelen 0 name "" tag 0x0
0xb1b entry inumber 41472 namelen 0 name "" tag 0x0
0xb2b entry inumber 40349877716123648 namelen 0 name "" tag 0x0
0xb3b entry inumber 6629439388987263232 namelen 0 name "" tag 0x91
0xb4b entry inumber 1711308800 namelen 0 name "" tag 0x6700
0xb5b entry inumber 41092048064872448 namelen 0 name "" tag 0x0
0xb6b entry inumber 7854418487632080128 namelen 0 name "" tag 0x92
0xb7b entry inumber 1845526528 namelen 0 name "" tag 0x6f00
0xb8b entry inumber 41296557227638784 namelen 0 name "" tag 0x0
0xb9b entry inumber 8142648863783841280 namelen 0 name "" tag 0x93
0xbab entry inumber 1912635392 namelen 0 name "" tag 0x7300
0xbbb entry inumber 41501066390405120 namelen 0 name "" tag 0x0
0xbcb entry inumber 8430879239935598080 namelen 0 name "" tag 0x93
0xbdb entry inumber 1979744256 namelen 0 name "" tag 0x7700
0xbeb entry inumber 41685784343871488 namelen 0 name "" tag 0x0
0xbfb entry inumber 140737498069248 namelen 0 name "" tag 0x96
0xc0b entry inumber 2399174656 namelen 0 name "" tag 0x0
0xc1b entry inumber 45197624482988032 namelen 0 name "" tag 0x0
0xc2b entry inumber 140737498886144 namelen 0 name "" tag 0xa0
0xc3b entry inumber 7281344512 namelen 0 name "" tag 0x0
0xc4b entry inumber 45337262459715584 namelen 0 name "" tag 0x0
0xc5b entry inumber 3747069656762941440 namelen 0 name "" tag 0x0
0xc6b entry inumber 13194139542528 namelen 0 name "" tag 0x3500
0xc7b entry inumber 0 namelen 0 name "" tag 0x0
0xc8b entry inumber 39582418599936 namelen 0 name "" tag 0xa1
0xc9b entry inumber 905978880 namelen 0 name "" tag 0x3600
0xcab entry inumber 0 namelen 0 name "" tag 0x0
0xcbb entry inumber 3963207254515211520 namelen 0 name "" tag 0x0
0xccb entry inumber 922764288 namelen 0 name "" tag 0x0
0xcdb entry inumber 45447213622496256 namelen 0 name "" tag 0x0
0xceb entry inumber 4179516376070852096 namelen 0 name "" tag 0x0
0xcfb entry inumber 989873152 namelen 0 name "" tag 0x3c00
0xd0b entry inumber 1536 namelen 0 name "" tag 0x0
0xd1b entry inumber 4395588003104292864 namelen 0 name "" tag 0xa1
0xd2b entry inumber 973094912 namelen 0 name "" tag 0x0
0xd3b entry inumber 45507686762030592 namelen 0 name "" tag 0x0
0xd4b entry inumber 4755977128374290176 namelen 0 name "" tag 0x0
0xd5b entry inumber 1124090880 namelen 0 name "" tag 0x4400
0xd6b entry inumber 1536 namelen 0 name "" tag 0x0
0xd7b entry inumber 4972048755407716352 namelen 0 name "" tag 0xa1
0xd8b entry inumber 1107312640 namelen 0 name "" tag 0x0
0xd9b entry inumber 7936 namelen 0 name "" tag 0x0
0xdab entry inumber 8319400251626094592 namelen 116 name "ubs.c/data/clink/io/cattelan/x2.3-99-xfs/linux/fs/xfs/xfsrtstubs.cgcc2_compiled.int:t(0,1)=r(0,1);0020000000000;" tag 0x3130
0xe2b entry inumber 3978709506094217015 namelen 55 name "7;char:t(0,2)=r(0,2);0;255;long int:t(0,3)=r(0,1);002" tag 0x3030
0xe73 entry inumber 3978702878842499120 namelen 55 name "7777777;unsigned int:t(0,4)=r(0,1);0000000000000;00377" tag 0x3737
0xebb entry inumber 8439859425705721915 namelen 110 name "signed int:t(0,5)=r(0,1);0000000000000;0037777777777;long long int:t(0,6)=r(0,1);01000000000000000000000;0777" tag 0x3737
0xf3b entry inumber 3978709506094217015 namelen 55 name ";long long unsigned int:t(0,7)=r(0,1);0000000000000;01" tag 0x3737
0xf83 entry inumber 3978709506094217015 namelen 55 name "77(..n9
                                                                cyiis


At Mon, 1 May 2000 16:20:08 -0500 (CDT),
Glen Overby <overby@sgi.com> wrote:
> 
> 
> Jim Mostek wrote:
> > 
> > Glen Overby knows the dir2 format the best after
> > Doug Doucette.
> > 
> > Glen, Doug, any suggestions on what to look for
> > when hitting the last assert below:
> > 
> >         /*
> >          * Loop over the data/unused entries.
> >          */
> >         while (p < endp) {
> >                 dup = (xfs_dir2_data_unused_t *)p;
> >                 /*
> >                  * If it's unused, look for the space in the bestfree table.
> >                  * If we find it, account for that, else make sure it
> >                  * doesn't need to be there.
> >                  */
> >                 if (INT_GET(dup->freetag, ARCH_UNKNOWN) == XFS_DIR2_DATA_FREE_TAG) {
> >                         ASSERT(lastfree == 0);
> >                         ASSERT(INT_GET(*XFS_DIR2_DATA_UNUSED_TAG_P_ARCH(dup, ARCH_UNK
> > NOWN), ARCH_UNKNOWN) ==
> >                                (char *)dup - (char *)d);
> 
> Its a block format directory.  Its a small directory that has a
> single-level b+tree and the directory entries in one directory block.
> 
> The XFS_DIR2_DATA_UNUSED_TAG_P_ARCH and INT_GET aren't in Irix; I
> assume this is mac's big-endian / little-endian code.
> 
> So the ASSERT is comparing the tag values of an unused directory entry
> and its offset into the data block.  It's checking if the unused
> directory entry's 'tag' field is correct.  Bug could be a bad tag
> value or a bad assert.
> 
> To know I'd need to know what those two macros do.  Tell me where your
> ism is; the last time I looked for it, I couldn't find it.
> 
> If you've got a dump, get the values of: dup, d and *dup (it's an
> xfs_dir2_data_unused_t).  While you're at it, dump *d
> (xfs_dir2_data_hdr_t) so we can see the bestfree entries.  After that
> we'll look at the remove-name code that sets the tag value.
> 
> Glen

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:17 2000
Received:  by oss.sgi.com id <S305285AbQEBA2U>;
	Mon, 1 May 2000 17:28:20 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:4366 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305275AbQEBA2G>; Mon, 1 May 2000 17:28:06 -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 RAA00509
	for <linux-xfs@oss.sgi.com>; Mon, 1 May 2000 17:32:18 -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 KAA18682 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 2 May 2000 10:26:32 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id KAA44548 for <linux-xfs@oss.sgi.com>; Tue, 2 May 2000 10:26:26 +1000 (EST)
Message-Id: <200005020026.KAA44548@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
Subject: page_buf leak...
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 02 May 2000 10:26:26 +1000
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


Problem:

   - make a clean fs
   - mount, unmount at least twice

128k slabs get alloced and not freed (see /proc/slabinfo) eventually
causing an allocation failure.

When the page_bufs in question are passed to _pagebuf_free_object,
their pointers are wiped by pagebuf_mapout_locked and the now NULL
pointer is passed to kfree (kfree doesn't care).

pagebuf_mapout_locked clears the pointers of any page_buf with
PBF_MAPPED set, but only returns the pointers of page_bufs with
_PBF_ADDR_ALLOCATED set.

The page_bufs in question have PBF_MAPPED set but not _PBF_ADDR_ALLOCATED
and hence their pointers get cleared and a NULL pointer is returned.

My fix is to change _pagebuf_free_object:

=>                 /* release any virtual mapping */ ;
=>                 if (pb->pb_flags & PBF_MAPPED)
=>                         vaddr = pagebuf_mapout_locked(pb); 

to

=> 		/* release any virtual mapping */ ;
=> 		if (pb->pb_flags & _PBF_ADDR_ALLOCATED)
=> 			vaddr = pagebuf_mapout_locked(pb); 

It fixes my problem but it might not be the "right thing" to do. 
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 Tue May  2 15:53:17 2000
Received:  by oss.sgi.com id <S305275AbQEBCkx>;
	Mon, 1 May 2000 19:40:53 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:30489 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305164AbQEBCkh>; Mon, 1 May 2000 19:40:37 -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 TAA04458
	for <linux-xfs@oss.sgi.com>; Mon, 1 May 2000 19:44:50 -0700 (PDT)
	mail_from (ivanr@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA19613 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 2 May 2000 12:39:12 +1000
Received: (from ivanr@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA92135 for linux-xfs@oss.sgi.com; Tue, 2 May 2000 12:39:11 +1000 (EST)
Date:   Tue, 2 May 2000 12:39:11 +1000 (EST)
From:   ivanr@snort.melbourne.sgi.com (Ivan Rayner)
Message-Id: <200005020239.MAA92135@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix bmap endian bug
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

fix bmap endian bug

Modid:  2.3.99pre2-xfs:slinx:60308a
Date:  Mon May  1 19:30:46 PDT 2000
Workarea:  snort:/hosts/bruce/home/ivanr/isms/slinx-xfs-tot

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

linux/fs/xfs/xfs_bmap.c - 1.250
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap.c.diff?r1=text&tr1=1.250&r2=text&tr2=1.249&f=h

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:17 2000
Received:  by oss.sgi.com id <S305287AbQEBDeD>;
	Mon, 1 May 2000 20:34:03 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:44884 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305164AbQEBDdg>;
	Mon, 1 May 2000 20:33:36 -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 UAA06685
	for <linux-xfs@oss.sgi.com>; Mon, 1 May 2000 20:28:45 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA19992; Tue, 2 May 2000 13:30:53 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA89072; Tue, 2 May 2000 13:30:53 +1000 (EST)
Date:   Tue, 2 May 2000 13:30:53 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005020330.NAA89072@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Cc:     dxm@snort.melbourne.sgi.com
Subject: TAKE - Architecture changes for clean log mount
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

With these changes, Linux XFS in MIPS mode should be able to
mount and modify clean MIPS XFS filesystems and vice-versa.

Note if you try to mount a dirty FS you can be fairly sure
you won't like the results.

Anyway, you should be able to move FSes between IRIX and
Linux and get pretty much full functionality (minus 
quotas and attributes).

(of course the appropriate CONFIG_ option must be enabled
to use MIPS mode)

Modid:  2.3.99pre2-xfs:slinx:60309a
Date:  Mon May  1 20:18:10 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/linux/xfs_lrw.c - 1.37
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h
linux/fs/xfs/xfs_os_defs.h - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_os_defs.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
linux/fs/xfs/xfs_utils.c - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_utils.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
linux/fs/xfs/xfsidbg.c - 1.138
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.138&r2=text&tr2=1.137&f=h
linux/fs/xfs/xfsrtstubs.c - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsrtstubs.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h

	fix includes

Modid:  2.3.99pre2-xfs:slinx:60310a
Date:  Mon May  1 20:20:46 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

cmd/xfs/repair/incore.h - 1.32
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/incore.h.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h

	arch bug fix

Modid:  2.3.99pre2-xfs:slinx:60311a
Date:  Mon May  1 20:23:45 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_log.c - 1.211
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.211&r2=text&tr2=1.210&f=h
linux/fs/xfs/xfs_log.h - 1.46
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h
linux/fs/xfs/xfs_log_print.c - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_print.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
linux/fs/xfs/xfs_log_priv.h - 1.69
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_priv.h.diff?r1=text&tr1=1.69&r2=text&tr2=1.68&f=h
linux/fs/xfs/xfs_log_recover.c - 1.176
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.176&r2=text&tr2=1.175&f=h

	arch work for clean log mount

Modid:  2.3.99pre2-xfs:slinx:60312a
Date:  Mon May  1 20:25:34 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

cmd/xfs/logprint/log_misc.c - 1.56
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/logprint/log_misc.c.diff?r1=text&tr1=1.56&r2=text&tr2=1.55&f=h
cmd/xfs/logprint/log_print_trans.c - 1.25
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/logprint/log_print_trans.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h
cmd/xfs/logprint/logprint.c - 1.35
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/logprint/logprint.c.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h
cmd/xfs/sim/src/sim.random.c - 1.105
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/sim.random.c.diff?r1=text&tr1=1.105&r2=text&tr2=1.104&f=h

	arch changes to logprint

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:17 2000
Received:  by oss.sgi.com id <S305289AbQEBKFf>;
	Tue, 2 May 2000 03:05:35 -0700
Received: from smtp7.xs4all.nl ([194.109.127.50]:17397 "EHLO smtp7.xs4all.nl")
	by oss.sgi.com with ESMTP id <S305164AbQEBKFe>;
	Tue, 2 May 2000 03:05:34 -0700
Received: from asterix.xs4all.nl (asterix.xs4all.nl [194.109.6.11])
	by smtp7.xs4all.nl (8.9.3/8.9.3) with ESMTP id MAA17302
	for <linux-xfs@oss.sgi.com>; Tue, 2 May 2000 12:05:26 +0200 (CEST)
Received: from ramoth.xs4all.nl (uucp@localhost)
	by asterix.xs4all.nl (8.9.1/8.9.1) with UUCP id MAA28056
	for oss.sgi.com!linux-xfs; Tue, 2 May 2000 12:05:06 +0200 (CEST)
Received: by ladystrange.bluehorizon.nl
	id m12mYPi-0005AZC
	(Debian Smail-3.2.0.102 1998-Aug-2 #2); Tue, 2 May 2000 10:52:18 +0200 (CEST)
Date:   Tue, 2 May 2000 10:52:18 +0200
From:   "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>
To:     linux-xfs@oss.sgi.com
Subject: Transition to more recent Linux kernel?
Message-ID: <20000502105218.A18735@ladystrange.bluehorizon.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.1i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Ha!

I'm following the XFS development with great enthusiasm, but the current
version is only based on the 2.3.99pre2 rel. of the Linux kernel. I've
seen some core developpers mention the transition to pre5.

I'll try another (self) port to 2.3.99pre7 this evening.

Thanx in advance!

Best regards,

	Pascal van Dam
	

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:17 2000
Received:  by oss.sgi.com id <S305290AbQEBMgU>;
	Tue, 2 May 2000 05:36:20 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:26 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305164AbQEBMf7>;
	Tue, 2 May 2000 05:35:59 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA06943
	for <linux-xfs@oss.sgi.com>; Tue, 2 May 2000 05:31:10 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id HAA17876; Tue, 2 May 2000 07:33:19 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id HAA23283; Tue, 2 May 2000 07:32:30 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id HAA06963; Tue, 2 May 2000 07:30:19 -0500
Message-Id: <200005021230.HAA06963@jen.americas.sgi.com>
To:     cattelan@thebarn.com
cc:     overby@sgi.com, mostek@sgi.com, dpd@whidbey.com,
        dxm@clouds.melbourne.sgi.com, linux-xfs@oss.sgi.com
Subject: Re: New Bug... 
In-reply-to: Your message of "Mon, 01 May 2000 18:49:02 CDT
Date:   Tue, 02 May 2000 07:30:19 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Yes, this looks familiar, I have hit directories like this using
the gtags/htags programs. I do not think we are going to find this
by trying to find a test case. It is going to take a good hard read of
the code.


Something is writing to a block it should not be, Once a filesystem is in
this state, looking at the disk around the corruption might give us some clues.
This will take someone familiar with xfs_db I think.

Steve

> 
> I'm begining to think this has more to do with our corruption problem
> than anything else.
> 
> This is what I got from the latest panic.
> 
> 
> 
> 
> 
> 0x10 entry inumber 17202865 namelen 1 name "." tag 0x10
> 0x20 entry inumber 836488 namelen 2 name ".." tag 0x20
> 0x30 entry inumber 21699385 namelen 3 name "arc" tag 0x30
> 0x40 entry inumber 25916672 namelen 3 name "pci" tag 0x40
> 0x50 unused freetag 0xffff length 0x1cb tag 0x51
> 0x21b entry inumber 32768 namelen 0 name "" tag 0xc500
> 0x22b entry inumber 23065554927484928 namelen 0 name "" tag 0x0
> 0x23b entry inumber -3314508588250947072 namelen 0 name "" tag 0x52
> 0x24b entry inumber 32768 namelen 0 name "" tag 0xe700
> 0x25b entry inumber 23349228927451136 namelen 0 name "" tag 0x0
> 0x26b entry inumber 1008947054024794112 namelen 1 name "" tag 0x53
> 0x27b entry inumber 4563435520 namelen 0 name "" tag 0x1300
> 0x28b entry inumber 23546041508823041 namelen 0 name "" tag 0x0
> 0x29b entry inumber 1585407806328263680 namelen 1 name "" tag 0x54
> 0x2ab entry inumber 4697653248 namelen 0 name "" tag 0x1900
> 0x2bb entry inumber 23731858973917185 namelen 0 name "" tag 0x0
> 0x2cb entry inumber 2161868558631730688 namelen 1 name "" tag 0x54
> 0x2db entry inumber 4815093760 namelen 0 name "" tag 0x2000
> 0x2eb entry inumber 23931970090172417 namelen 0 name "" tag 0x0
> 0x2fb entry inumber 2594214122859344896 namelen 1 name "" tag 0x55
> 0x30b entry inumber 4915757056 namelen 0 name "" tag 0x2700
> 0x31b entry inumber 24133180718055425 namelen 0 name "" tag 0x0
> 0x32b entry inumber 3026559687086959616 namelen 1 name "" tag 0x56
> 0x33b entry inumber 5016420352 namelen 0 name "" tag 0x2c00
> 0x34b entry inumber 24339888904077313 namelen 0 name "" tag 0x0
> 0x35b entry inumber 3314790063238719488 namelen 1 name "" tag 0x56
> 0x36b entry inumber 5083529216 namelen 0 name "" tag 0x3000
> 0x37b entry inumber 24526805880799233 namelen 0 name "" tag 0x0
> 0x38b entry inumber 3963308409580114176 namelen 1 name "" tag 0x57
> 0x39b entry inumber 5234524160 namelen 0 name "" tag 0x3a00
> 0x3ab entry inumber 24734613578448897 namelen 0 name "" tag 0x0
> 0x3bb entry inumber 4395653973807731456 namelen 1 name "" tag 0x58
> 0x3cb entry inumber 5351964672 namelen 0 name "" tag 0x4000
> 0x3db entry inumber 24968809555165185 namelen 0 name "" tag 0x0
> 0x3eb entry inumber 4755941943997426944 namelen 1 name "" tag 0x59
> 0x3fb entry inumber 5419073536 namelen 0 name "" tag 0x4400
> 0x40b entry inumber 25185413345837057 namelen 0 name "" tag 0x0
> 0x41b entry inumber 5044172320149187840 namelen 1 name "" tag 0x59
> 0x42b entry inumber 32768 namelen 0 name "" tag 0x6f00
> 0x43b entry inumber 26502628275912705 namelen 0 name "" tag 0x0
> 0x44b entry inumber -6917388290146421504 namelen 2 name "" tag 0x60
> 0x45b entry inumber 32768 namelen 0 name "" tag 0xf500
> 0x46b entry inumber 27349252229300226 namelen 0 name "" tag 0x0
> 0x47b entry inumber 4323596379770420480 namelen 3 name "" tag 0x0
> 0x48b entry inumber 41472 namelen 0 name "" tag 0x0
> 0x49b entry inumber 27541666764161024 namelen 0 name "" tag 0x0
> 0x4ab entry inumber 140737494775552 namelen 0 name "" tag 0x63
> 0x4bb entry inumber 1627422720 namelen 0 name "" tag 0x0
> 0x4cb entry inumber 28032048950149120 namelen 0 name "" tag 0x0
> 0x4db entry inumber -5836524379577186560 namelen 0 name "" tag 0x0
> 0x4eb entry inumber 41472 namelen 0 name "" tag 0x0
> 0x4fb entry inumber 28475152136142848 namelen 0 name "" tag 0x0
> 0x50b entry inumber 178120883699712 namelen 0 name "" tag 0x65
> 0x51b entry inumber 33280 namelen 0 name "" tag 0x4e00
> 0x52b entry inumber 0 namelen 0 name "" tag 0x0
> 0x53b entry inumber 142936518276096 namelen 0 name "" tag 0x65
> 0x54b entry inumber 1224769536 namelen 0 name "" tag 0x4d00
> 0x55b entry inumber 28770920764014592 namelen 0 name "" tag 0x0
> 0x56b entry inumber 140737495061760 namelen 0 name "" tag 0x66
> 0x57b entry inumber 1677754368 namelen 0 name "" tag 0x0
> 0x58b entry inumber 29078784019791872 namelen 0 name "" tag 0x0
> 0x59b entry inumber 140737495135232 namelen 0 name "" tag 0x68
> 0x5ab entry inumber 2298511360 namelen 0 name "" tag 0x0
> 0x5bb entry inumber 29470210159280128 namelen 0 name "" tag 0x0
> 0x5cb entry inumber -7854137012638919680 namelen 0 name "" tag 0x68
> 0x5db entry inumber 32768 namelen 0 name "" tag 0xe200
> 0x5eb entry inumber 30024364019679232 namelen 0 name "" tag 0x0
> 0x5fb entry inumber -720435202883916288 namelen 0 name "" tag 0x6b
> 0x60b entry inumber 4194336768 namelen 0 name "" tag 0xfc00
> 0x61b entry inumber 30247564880117760 namelen 0 name "" tag 0x0
> 0x62b entry inumber 1297177430178215680 namelen 1 name "" tag 0x6d
> 0x63b entry inumber 32768 namelen 0 name "" tag 0x5000
> 0x64b entry inumber 30987536205611009 namelen 0 name "" tag 0x0
> 0x65b entry inumber 6125036230719463680 namelen 1 name "" tag 0x6e
> 0x66b entry inumber 5955944448 namelen 0 name "" tag 0x0
> 0x67b entry inumber 31161259042799616 namelen 0 name "" tag 0x0
> 0x68b entry inumber 140737495617280 namelen 0 name "" tag 0x6f
> 0x69b entry inumber 6744473600 namelen 0 name "" tag 0x0
> 0x6ab entry inumber 31298697996271616 namelen 0 name "" tag 0x0
> 0x6bb entry inumber 142936518904320 namelen 0 name "" tag 0x6f
> 0x6cb entry inumber 32768 namelen 0 name "" tag 0x5300
> 0x6db entry inumber 0 namelen 0 name "" tag 0x0
> 0x6eb entry inumber 178120883699712 namelen 0 name "" tag 0x73
> 0x6fb entry inumber 33280 namelen 0 name "" tag 0x4c00
> 0x70b entry inumber 32423498391486464 namelen 0 name "" tag 0x0
> 0x71b entry inumber 5620633072454290432 namelen 0 name "" tag 0x73
> 0x72b entry inumber 1325432832 namelen 0 name "" tag 0x5000
> 0x73b entry inumber 32545544182169600 namelen 0 name "" tag 0x0
> 0x74b entry inumber 5908863448606030336 namelen 0 name "" tag 0x73
> 0x75b entry inumber 1409318912 namelen 0 name "" tag 0x5500
> 0x76b entry inumber 32664291437969408 namelen 0 name "" tag 0x0
> 0x77b entry inumber 6341209012833625344 namelen 0 name "" tag 0x74
> 0x78b entry inumber 1509982208 namelen 0 name "" tag 0x5b00
> 0x79b entry inumber 32779740158885888 namelen 0 name "" tag 0x0
> 0x7ab entry inumber 7133842547250859776 namelen 0 name "" tag 0x74
> 0x7bb entry inumber 1677754368 namelen 0 name "" tag 0x6500
> 0x7cb entry inumber 32901785949569024 namelen 0 name "" tag 0x0
> 0x7db entry inumber 7422072923402600704 namelen 0 name "" tag 0x75
> 0x7eb entry inumber 1828749312 namelen 0 name "" tag 0x6e00
> 0x7fb entry inumber 33031528321646592 namelen 0 name "" tag 0x0
> 0x80b entry inumber 8070591269743982336 namelen 0 name "" tag 0x75
> 0x81b entry inumber 2013298688 namelen 0 name "" tag 0x7900
> 0x82b entry inumber 33160171182096384 namelen 0 name "" tag 0x0
> 0x83b entry inumber -9151173705320764416 namelen 0 name "" tag 0x76
> 0x84b entry inumber 32768 namelen 0 name "" tag 0x9f00
> 0x85b entry inumber 33325097926262784 namelen 0 name "" tag 0x0
> 0x86b entry inumber -6629157913993230336 namelen 0 name "" tag 0x0
> 0x87b entry inumber 41472 namelen 0 name "" tag 0x0
> 0x88b entry inumber 33477930042523648 namelen 0 name "" tag 0x0
> 0x89b entry inumber 3242732469202913280 namelen 0 name "" tag 0x77
> 0x8ab entry inumber 889225216 namelen 0 name "" tag 0x0
> 0x8bb entry inumber 33563691949490176 namelen 0 name "" tag 0x0
> 0x8cb entry inumber 140737496172288 namelen 0 name "" tag 0x7b
> 0x8db entry inumber 2432729088 namelen 0 name "" tag 0x0
> 0x8eb entry inumber 35816591274803200 namelen 0 name "" tag 0x0
> 0x8fb entry inumber 178120883699712 namelen 0 name "" tag 0x7f
> 0x90b entry inumber 33280 namelen 0 name "" tag 0x0
> 0x91b entry inumber 35884760995725312 namelen 0 name "" tag 0x0
> 0x92b entry inumber 178120883699712 namelen 0 name "" tag 0x0
> 0x93b entry inumber 41472 namelen 0 name "" tag 0x0
> 0x94b entry inumber 35983717042225152 namelen 0 name "" tag 0x0
> 0x95b entry inumber -8862943329168394752 namelen 0 name "" tag 0x80
> 0x96b entry inumber 32768 namelen 0 name "" tag 0x8f00
> 0x97b entry inumber 0 namelen 0 name "" tag 0x0
> 0x98b entry inumber 142936520043264 namelen 0 name "" tag 0x80
> 0x99b entry inumber 32768 namelen 0 name "" tag 0x3500
> 0x9ab entry inumber 36366347088691200 namelen 0 name "" tag 0x0
> 0x9bb entry inumber 4683884349962169344 namelen 0 name "" tag 0x81
> 0x9cb entry inumber 32768 namelen 0 name "" tag 0x5100
> 0x9db entry inumber 36920500949090304 namelen 0 name "" tag 0x0
> 0x9eb entry inumber -6701215508030233088 namelen 0 name "" tag 0x85
> 0x9fb entry inumber 32768 namelen 0 name "" tag 0xc700
> 0xa0b entry inumber 37621989367611392 namelen 0 name "" tag 0x0
> 0xa1b entry inumber -2810105429982034432 namelen 0 name "" tag 0x86
> 0xa2b entry inumber 5217746944 namelen 0 name "" tag 0x0
> 0xa3b entry inumber 38026609646632960 namelen 0 name "" tag 0x0
> 0xa4b entry inumber 140737497218304 namelen 0 name "" tag 0x8b
> 0xa5b entry inumber 6274711552 namelen 0 name "" tag 0x0
> 0xa6b entry inumber 39316336786014208 namelen 0 name "" tag 0x0
> 0xa7b entry inumber 5332402696304179200 namelen 0 name "" tag 0x8b
> 0xa8b entry inumber 1258323968 namelen 0 name "" tag 0x4e00
> 0xa9b entry inumber 39481263530180608 namelen 0 name "" tag 0x0
> 0xaab entry inumber 6557381794949003776 namelen 0 name "" tag 0x8c
> 0xabb entry inumber 1677754368 namelen 0 name "" tag 0x7400
> 0xacb entry inumber 39694568785969152 namelen 0 name "" tag 0x0
> 0xadb entry inumber -9007058517243385600 namelen 0 name "" tag 0x8d
> 0xaeb entry inumber 2231402496 namelen 0 name "" tag 0x8600
> 0xafb entry inumber 39935361832452096 namelen 0 name "" tag 0x0
> 0xb0b entry inumber -7133561072257126400 namelen 0 name "" tag 0x0
> 0xb1b entry inumber 41472 namelen 0 name "" tag 0x0
> 0xb2b entry inumber 40349877716123648 namelen 0 name "" tag 0x0
> 0xb3b entry inumber 6629439388987263232 namelen 0 name "" tag 0x91
> 0xb4b entry inumber 1711308800 namelen 0 name "" tag 0x6700
> 0xb5b entry inumber 41092048064872448 namelen 0 name "" tag 0x0
> 0xb6b entry inumber 7854418487632080128 namelen 0 name "" tag 0x92
> 0xb7b entry inumber 1845526528 namelen 0 name "" tag 0x6f00
> 0xb8b entry inumber 41296557227638784 namelen 0 name "" tag 0x0
> 0xb9b entry inumber 8142648863783841280 namelen 0 name "" tag 0x93
> 0xbab entry inumber 1912635392 namelen 0 name "" tag 0x7300
> 0xbbb entry inumber 41501066390405120 namelen 0 name "" tag 0x0
> 0xbcb entry inumber 8430879239935598080 namelen 0 name "" tag 0x93
> 0xbdb entry inumber 1979744256 namelen 0 name "" tag 0x7700
> 0xbeb entry inumber 41685784343871488 namelen 0 name "" tag 0x0
> 0xbfb entry inumber 140737498069248 namelen 0 name "" tag 0x96
> 0xc0b entry inumber 2399174656 namelen 0 name "" tag 0x0
> 0xc1b entry inumber 45197624482988032 namelen 0 name "" tag 0x0
> 0xc2b entry inumber 140737498886144 namelen 0 name "" tag 0xa0
> 0xc3b entry inumber 7281344512 namelen 0 name "" tag 0x0
> 0xc4b entry inumber 45337262459715584 namelen 0 name "" tag 0x0
> 0xc5b entry inumber 3747069656762941440 namelen 0 name "" tag 0x0
> 0xc6b entry inumber 13194139542528 namelen 0 name "" tag 0x3500
> 0xc7b entry inumber 0 namelen 0 name "" tag 0x0
> 0xc8b entry inumber 39582418599936 namelen 0 name "" tag 0xa1
> 0xc9b entry inumber 905978880 namelen 0 name "" tag 0x3600
> 0xcab entry inumber 0 namelen 0 name "" tag 0x0
> 0xcbb entry inumber 3963207254515211520 namelen 0 name "" tag 0x0
> 0xccb entry inumber 922764288 namelen 0 name "" tag 0x0
> 0xcdb entry inumber 45447213622496256 namelen 0 name "" tag 0x0
> 0xceb entry inumber 4179516376070852096 namelen 0 name "" tag 0x0
> 0xcfb entry inumber 989873152 namelen 0 name "" tag 0x3c00
> 0xd0b entry inumber 1536 namelen 0 name "" tag 0x0
> 0xd1b entry inumber 4395588003104292864 namelen 0 name "" tag 0xa1
> 0xd2b entry inumber 973094912 namelen 0 name "" tag 0x0
> 0xd3b entry inumber 45507686762030592 namelen 0 name "" tag 0x0
> 0xd4b entry inumber 4755977128374290176 namelen 0 name "" tag 0x0
> 0xd5b entry inumber 1124090880 namelen 0 name "" tag 0x4400
> 0xd6b entry inumber 1536 namelen 0 name "" tag 0x0
> 0xd7b entry inumber 4972048755407716352 namelen 0 name "" tag 0xa1
> 0xd8b entry inumber 1107312640 namelen 0 name "" tag 0x0
> 0xd9b entry inumber 7936 namelen 0 name "" tag 0x0
> 0xdab entry inumber 8319400251626094592 namelen 116 name "ubs.c/data/clink/io
/cattelan/x2.3-99-xfs/linux/fs/xfs/xfsrtstubs.cgcc2_compiled.int:t(0,1)=r(0,1);
0020000000000;" tag 0x3130
> 0xe2b entry inumber 3978709506094217015 namelen 55 name "7;char:t(0,2)=r(0,2)
;0;255;long int:t(0,3)=r(0,1);002" tag 0x3030
> 0xe73 entry inumber 3978702878842499120 namelen 55 name "7777777;unsigned int
:t(0,4)=r(0,1);0000000000000;00377" tag 0x3737
> 0xebb entry inumber 8439859425705721915 namelen 110 name "signed int:t(0,5)=r
(0,1);0000000000000;0037777777777;long long int:t(0,6)=r(0,1);01000000000000000
000000;0777" tag 0x3737
> 0xf3b entry inumber 3978709506094217015 namelen 55 name ";long long unsigned 
int:t(0,7)=r(0,1);0000000000000;01" tag 0x3737
> 0xf83 entry inumber 3978709506094217015 namelen 55 name "77(..n9
>                                                                 cyiis
> 
> 
> At Mon, 1 May 2000 16:20:08 -0500 (CDT),
> Glen Overby <overby@sgi.com> wrote:
> > 
> > 
> > Jim Mostek wrote:
> > > 
> > > Glen Overby knows the dir2 format the best after
> > > Doug Doucette.
> > > 
> > > Glen, Doug, any suggestions on what to look for
> > > when hitting the last assert below:
> > > 
> > >         /*
> > >          * Loop over the data/unused entries.
> > >          */
> > >         while (p < endp) {
> > >                 dup = (xfs_dir2_data_unused_t *)p;
> > >                 /*
> > >                  * If it's unused, look for the space in the bestfree tab
le.
> > >                  * If we find it, account for that, else make sure it
> > >                  * doesn't need to be there.
> > >                  */
> > >                 if (INT_GET(dup->freetag, ARCH_UNKNOWN) == XFS_DIR2_DATA_
FREE_TAG) {
> > >                         ASSERT(lastfree == 0);
> > >                         ASSERT(INT_GET(*XFS_DIR2_DATA_UNUSED_TAG_P_ARCH(d
up, ARCH_UNK
> > > NOWN), ARCH_UNKNOWN) ==
> > >                                (char *)dup - (char *)d);
> > 
> > Its a block format directory.  Its a small directory that has a
> > single-level b+tree and the directory entries in one directory block.
> > 
> > The XFS_DIR2_DATA_UNUSED_TAG_P_ARCH and INT_GET aren't in Irix; I
> > assume this is mac's big-endian / little-endian code.
> > 
> > So the ASSERT is comparing the tag values of an unused directory entry
> > and its offset into the data block.  It's checking if the unused
> > directory entry's 'tag' field is correct.  Bug could be a bad tag
> > value or a bad assert.
> > 
> > To know I'd need to know what those two macros do.  Tell me where your
> > ism is; the last time I looked for it, I couldn't find it.
> > 
> > If you've got a dump, get the values of: dup, d and *dup (it's an
> > xfs_dir2_data_unused_t).  While you're at it, dump *d
> > (xfs_dir2_data_hdr_t) so we can see the bestfree entries.  After that
> > we'll look at the remove-name code that sets the tag value.
> > 
> > Glen

From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:17 2000
Received:  by oss.sgi.com id <S305291AbQEBMuK>;
	Tue, 2 May 2000 05:50:10 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:34587 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305164AbQEBMtt>;
	Tue, 2 May 2000 05:49:49 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA07672
	for <linux-xfs@oss.sgi.com>; Tue, 2 May 2000 05:45:01 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id HAA16139; Tue, 2 May 2000 07:47:13 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id HAA23601; Tue, 2 May 2000 07:47:04 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id HAA09130; Tue, 2 May 2000 07:44:53 -0500
Message-Id: <200005021244.HAA09130@jen.americas.sgi.com>
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: page_buf leak... 
In-reply-to: Your message of "Tue, 02 May 2000 10:26:26 +1000
Date:   Tue, 02 May 2000 07:44:53 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



This looks mostly correct, but I prefer to save the address from pb_addr for the
kfree call rather than change when we call pagebuf_mapout_locked();

Steve

> 
> Problem:
> 
>    - make a clean fs
>    - mount, unmount at least twice
> 
> 128k slabs get alloced and not freed (see /proc/slabinfo) eventually
> causing an allocation failure.
> 
> When the page_bufs in question are passed to _pagebuf_free_object,
> their pointers are wiped by pagebuf_mapout_locked and the now NULL
> pointer is passed to kfree (kfree doesn't care).
> 
> pagebuf_mapout_locked clears the pointers of any page_buf with
> PBF_MAPPED set, but only returns the pointers of page_bufs with
> _PBF_ADDR_ALLOCATED set.
> 
> The page_bufs in question have PBF_MAPPED set but not _PBF_ADDR_ALLOCATED
> and hence their pointers get cleared and a NULL pointer is returned.
> 
> My fix is to change _pagebuf_free_object:
> 
> =>                 /* release any virtual mapping */ ;
> =>                 if (pb->pb_flags & PBF_MAPPED)
> =>                         vaddr = pagebuf_mapout_locked(pb); 
> 
> to
> 
> => 		/* release any virtual mapping */ ;
> => 		if (pb->pb_flags & _PBF_ADDR_ALLOCATED)
> => 			vaddr = pagebuf_mapout_locked(pb); 
> 
> It fixes my problem but it might not be the "right thing" to do. 
> 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 Tue May  2 15:53:17 2000
Received:  by oss.sgi.com id <S305292AbQEBNLA>;
	Tue, 2 May 2000 06:11:00 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:20255 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305164AbQEBNKk>;
	Tue, 2 May 2000 06:10:40 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA09164
	for <linux-xfs@oss.sgi.com>; Tue, 2 May 2000 06:05:52 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA50244; Tue, 2 May 2000 08:08:01 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id IAA24463; Tue, 2 May 2000 08:07:53 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA11104; Tue, 2 May 2000 08:05:42 -0500
Message-Id: <200005021305.IAA11104@jen.americas.sgi.com>
To:     dxm@snort.melbourne.sgi.com (Daniel Moore)
cc:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - Architecture changes for clean log mount 
In-reply-to: Your message of "Tue, 02 May 2000 13:30:53 +1000
Date:   Tue, 02 May 2000 08:05:42 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> With these changes, Linux XFS in MIPS mode should be able to
> mount and modify clean MIPS XFS filesystems and vice-versa.
> 
> Note if you try to mount a dirty FS you can be fairly sure
> you won't like the results.
> 
> Anyway, you should be able to move FSes between IRIX and
> Linux and get pretty much full functionality (minus 
> quotas and attributes).
> 
> (of course the appropriate CONFIG_ option must be enabled
> to use MIPS mode)
> 

Something nasty crept in with this mod - it may be as simple as a bad
assert. A debug build using native format now blows up in the transaction 
code:

XFS assertion failed: log->l_grant_write_cycle-1 == CYCLE_LSN(tail_lsn, ARCH_NOCONVERT), file: xfs_log.c, line: 2366
kernel BUG at xfs_debug.c:86!
Entering kdb (0xc12e8000) on processor 1 Panic: invalid operand
due to panic @ 0xc88a5489
eax = 0x0000001e ebx = 0x00000003 ecx = 0xc02f4124 edx = 0xc02f4124 
esi = 0xc48ee120 edi = 0xc48ee1c8 esp = <kernel>   eip = 0xc88a5489 
ebp = 0xc12e9e38  ss = 0xc88cbf0e  cs = 0x00000010 eflags = 0x00010086 
 ds = <kernel>    es = 0x00000018 origeax = 0xffffffff &regs = 0xc12e9df8
[E1]ntkderbi> ng kdb (0xc0ee0000) on processor 0 due to NonMaskable Interrupt @ 0xc0223ca4
eax = 0x00000000 ebx = 0xc13d1c80 ecx = 0xc0ee0000 edx = 0x00000001 
esi = 0x00000000 edi = 0xc13d1c80 esp = <kernel>   eip = 0xc0223ca4 
ebp = 0xc0ee1f50  ss = 0x00000001  cs = 0x00000010 eflags = 0x00000202 
 ds = <kernel>    es = 0xc13d0018 origeax = 0x00000000 &regs = 0xc0ee1ed4
[0]kdb> cpu 1
Entering kdb (0xc12e8000) on processor 1 due to cpu switch
[1]kdb> bt
    EBP       EIP         Function(args)
0xc12e9c10 0xc021de54  kdb_getscancode+0x90( 0xc12e9c80, 0xff, 0xc12e9c30, 0xc0183fe0, 0xc12e9c80 )
0xc12e9c20 0xc021e024  kdba_read+0x10( 0xc12e9c80, 0xff, 0xc12e9c50, 0xc018400a, 0xc12e9c80 )
0xc12e9c30 0xc0183fe0  kdb_read+0x10( 0xc12e9c80, 0xff, 0xc024c019, 0x1, 0x0 )
0xc12e9c50 0xc018400a  kdb_getstr+0x26( 0xc12e9c80, 0xff, 0xc024c019, 0xc024c2240xc12e9d80 0xc0182220  kdb+0x488( 0x4, 0x0, 0xc12e9df8, 0xc12e9db8, 0xc010c545 )
0xc12e9d94 0xc021ebb3  kdba_callback_die+0x1b( 0xc12e9df8, 0x0, 0xffffffff, 0xc0229646, 0xc12e9df8 )
0xc12e9db8 0xc010c545  die+0x79( 0xc0229646, 0xc12e9df8, 0x0, 0xc12e8000, 0xc12e9de8 )
0xc12e9dd0 0xc010c68e  die_if_no_fixup+0x3a( 0xc0229646, 0xc12e9df8, 0x0, 0xc12e8000, 0xc12e9e38 )
0xc12e9de8 0xc010ca81  do_invalid_op+0x2d( 0xc12e9df8, 0x0, 0x3, 0xc02f4124, 0xc02f4124 )
0xc12e9e38 0xc010bff1  error_code+0x2d( 0xc88c4680, 0xc88c3dd6, 0x93e, 0xc7fa20cc, 0xc48ee120 )
0xc12e9e7c 0xc8880cd1  xlog_grant_log_space+0x321( 0xc48ee120, 0xc7fa20cc, 0xc2d15000, 0x0, 0xc48ee120 )
0xc12e9eb4 0xc887dfb3  xfs_log_reserve+0x133( 0xc2d15000, 0x638, 0x0, 0xc2e1f174, 0x69 )
0xc12e9ee0 0xc88921a6  xfs_trans_reserve+0x12a( 0xc2e1f140, 0x0, 0x638, 0x0, 0x0 )
0xc12e9f70 0xc8899ec6  xfs_syncsub+0x1046( 0xc2d15000, 0x31, 0x0, 0x0, 0xc2d15000 )
0xc12e9f90 0xc8898e77  xfs_sync+0x1b( 0xc2d15000, 0x31, 0xc88d81a0, 0xc2d15400, 0xc12e9fbc )
0xc12e9fa8 0xc88aeecc  linvfs_write_super+0x24( 0xc2d15400, 0xc12e8000, 0xc12e8000, 0xc12e9fd4 )
0xc12e9fbc 0xc0146884  sync_supers+0x68( 0x0, 0xc12e8000, 0xc12e84a8, 0xc12e84a8 )
0xc12e9fd4 0xc0140e06  sync_old_buffers+0x6e( 0xf00, 0xc1293f98, 0xc1292000, 0x78 )
0xc12e9fec 0xc014135e  kupdate+0x20e
0xc1293fa0 0xc0108f93  kernel_thread+0x23

Can someone fix this - I am on vacation!

Steve


From owner-linux-xfs@oss.sgi.com Tue May  2 15:53:17 2000
Received:  by oss.sgi.com id <S305293AbQEBNLV>;
	Tue, 2 May 2000 06:11:21 -0700
Received: from [128.162.8.102] ([128.162.8.102]:20660 "EHLO timbuk.cray.com")
	by oss.sgi.com with ESMTP id <S305164AbQEBNLI>;
	Tue, 2 May 2000 06:11:08 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id IAA05844 for <linux-xfs@oss.sgi.com>; Tue, 2 May 2000 08:11:04 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id IAA51328 for linux-xfs@oss.sgi.com; Tue, 2 May 2000 08:11:05 -0500 (CDT)
Date:   Tue, 2 May 2000 08:11:05 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Message-Id: <200005021311.IAA51328@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix memory leak in pagebuf
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.3.99pre2-xfs:slinx:60320a
Date:  Tue May  2 06:08:28 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux

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

linux/fs/page_buf.c - 1.83
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.83&r2=text&tr2=1.82&f=h
	- Fix memory leak in page_buf, we later use pb_addr which is zeroed
	  by the call to pagebuf_mapout_locked();


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:41 2000
Received:  by oss.sgi.com id <S305155AbQECAjV>;
	Tue, 2 May 2000 17:39:21 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:20350 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQECAjE>;
	Tue, 2 May 2000 17:39: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 RAA17952
	for <linux-xfs@oss.sgi.com>; Tue, 2 May 2000 17:34:14 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA28692 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 3 May 2000 10:36:30 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA94025 for linux-xfs@oss.sgi.com; Wed, 3 May 2000 10:36:28 +1000 (EST)
Date:   Wed, 3 May 2000 10:36:28 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005030036.KAA94025@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - sim log bug fix
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.3.99pre2-xfs:slinx:60412a
Date:  Tue May  2 17:36:04 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs-tot

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

cmd/xfs/sim/src/sim.random.c - 1.106
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/sim.random.c.diff?r1=text&tr1=1.106&r2=text&tr2=1.105&f=h
	- bug fix


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:42 2000
Received:  by oss.sgi.com id <S305158AbQECB5C>;
	Tue, 2 May 2000 18:57:02 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:58381 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQECB4q>;
	Tue, 2 May 2000 18:56:46 -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 SAA23580
	for <linux-xfs@oss.sgi.com>; Tue, 2 May 2000 18:51:56 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA29380 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 3 May 2000 11:55:25 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA80167 for linux-xfs@oss.sgi.com; Wed, 3 May 2000 11:55:22 +1000 (EST)
Date:   Wed, 3 May 2000 11:55:22 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005030155.LAA80167@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - native log stuff-up fix
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

That's fixing the stuff-up, not stuffing up the fix, of course.

Logic stuff up in xfs_log.h - ARCH_UNKNOWN != ARCH_NOCONVERT...
Fine for MIPS, but fubar for NATIVE.

Modid:  2.3.99pre2-xfs:slinx:60426a
Date:  Tue May  2 18:52:48 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_log.c - 1.212
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.212&r2=text&tr2=1.211&f=h
linux/fs/xfs/xfs_log.h - 1.47
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h

From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:42 2000
Received:  by oss.sgi.com id <S305165AbQECGch>;
	Tue, 2 May 2000 23:32:37 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:12050 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQECGcV>; Tue, 2 May 2000 23:32:21 -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 XAA01187
	for <linux-xfs@oss.sgi.com>; Tue, 2 May 2000 23:36:36 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA01449 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 3 May 2000 16:31:02 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id QAA13560 for linux-xfs@oss.sgi.com; Wed, 3 May 2000 16:31:00 +1000 (EST)
Date:   Wed, 3 May 2000 16:31:00 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005030631.QAA13560@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix "xlog_verify_iclog: illegal client" messages
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

solve a truly ugly endian issue. new macro to extract field
correctly for different architectures

(copy of four bytes from within a structure - memory contains
three different fields. copy is then shifted/masked to extract
one field based on its location within the four byte region.
urgh.)

Modid:  2.3.99pre2-xfs:slinx:60431a
Date:  Tue May  2 23:28:09 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_arch.h - 1.24
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_arch.h.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h
	- set ARCH_UNKNOWN depending on mode, so ARCH_UNKNOWN == ARCH_NOCONVERT
	  for native case and == ARCH_MIPS for MIPS case.
	  (allow simpler checks against == ARCH_NOCONVERT)

linux/fs/xfs/xfs_log.c - 1.213
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.213&r2=text&tr2=1.212&f=h
	- use new macro GET_CLIENT_ID to solve ugly endian issue

linux/fs/xfs/xfs_log.h - 1.48
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h
	- remove work around for ARCH_UNKNOWN != ARCH_NOCONVERT in native mode

linux/fs/xfs/xfs_log_priv.h - 1.70
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_priv.h.diff?r1=text&tr1=1.70&r2=text&tr2=1.69&f=h
	- add GET_CLIENT_ID macro to solve ugly endian issue


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:43 2000
Received:  by oss.sgi.com id <S305166AbQECMnF>;
	Wed, 3 May 2000 05:43:05 -0700
Received: from alum.etsii.upm.es ([138.100.71.70]:57348 "HELO
        alum.etsii.upm.es") by oss.sgi.com with SMTP id <S305154AbQECMms>;
	Wed, 3 May 2000 05:42:48 -0700
Received: (qmail 25418 invoked by uid 33); 3 May 2000 12:43:36 -0000
Message-ID: <957357816.39101ef859380@alum.etsii.upm.es>
Date:   Wed, 03 May 2000 14:43:36 +0200
To:     linux-xfs@oss.sgi.com
From:   Enrique Alonso de Armas <ealonso@alum.etsii.upm.es>
Subject: Re: compile errors
References: <20000427165847.13187.qmail@file.phys.tohoku.ac.jp>
In-Reply-To: <20000427165847.13187.qmail@file.phys.tohoku.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.0
X-Originating-IP: 138.100.73.27
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi all.
thanks for your help.
I compiled the kernel using egcs.
And all worked fine.
Now I have some problems with the find program: it just stop when starts searching.
I could not compile utilities neither.

Do not worry. I will wait for one month or so to try the sources again.
now I'm busy at school : ( 
I hope I will help soon

bye

------------------------------------
Enrique Alonso de Armas
ealonso@alum.etsii.upm.es
enrique@dorka.bindar.es
http://www.bindar.es
http://www.alum.etsii.upm.es/pgp.txt
Network/Unix Adm
------------------------------------


Linux rules!
(this is a .signature virus, please add me to your signature
file and help me to live)


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:43 2000
Received:  by oss.sgi.com id <S305179AbQECUeS>;
	Wed, 3 May 2000 13:34:18 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:56086 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQECUeH>;
	Wed, 3 May 2000 13:34:07 -0700
Received: from postofc.csd.sgi.com (postofc.csd.sgi.com [150.166.101.23]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA02720
	for <linux-xfs@oss.sgi.com>; Wed, 3 May 2000 13:29:19 -0700 (PDT)
	mail_from (jbarnes@sgi.com)
Received: from sgi.com (tinky.engr.sgi.com [163.154.10.30]) by postofc.csd.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA36190 for <linux-xfs@oss.sgi.com>; Wed, 3 May 2000 13:32:51 -0700 (PDT)
Message-ID: <39108BB9.16C6C15C@sgi.com>
Date:   Wed, 03 May 2000 13:27:37 -0700
From:   Jesse Barnes <jbarnes@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.13-2SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Newer kernels
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

Is there a patch somewhere for the XFS stuff against a recent kernel,
like pre5 or pre6?  I'm interested in seeing if I can get it to run on
an IA64 box, but it looks like pre2 doesn't have complete ia64 support.

Thanks,
Jesse

From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:43 2000
Received:  by oss.sgi.com id <S305180AbQEDDsX>;
	Wed, 3 May 2000 20:48:23 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:2421 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEDDsC>;
	Wed, 3 May 2000 20:48:02 -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 UAA16634
	for <linux-xfs@oss.sgi.com>; Wed, 3 May 2000 20:43:12 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA10083 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 4 May 2000 13:45:27 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA14219 for linux-xfs@oss.sgi.com; Thu, 4 May 2000 13:45:26 +1000 (EST)
Date:   Thu, 4 May 2000 13:45:26 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005040345.NAA14219@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix GET_CLIENT_ID
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Was actually broken on ARCH_MIPS this time

Modid:  2.3.99pre2-xfs:slinx:60510a
Date:  Wed May  3 20:44:44 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_log_priv.h - 1.71
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_priv.h.diff?r1=text&tr1=1.71&r2=text&tr2=1.70&f=h
	- fix GET_CLIENT_ID


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:43 2000
Received:  by oss.sgi.com id <S305183AbQEDF4y>;
	Wed, 3 May 2000 22:56:54 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:62987 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEDF4W>;
	Wed, 3 May 2000 22:56:22 -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 WAA25647
	for <linux-xfs@oss.sgi.com>; Wed, 3 May 2000 22:51:32 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA10967 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 4 May 2000 15:55:01 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA61312 for linux-xfs@oss.sgi.com; Thu, 4 May 2000 15:55:00 +1000 (EST)
Date:   Thu, 4 May 2000 15:55:00 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005040555.PAA61312@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix wrapping of di_next_unlinked
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.3.99pre2-xfs:slinx:60511a
Date:  Wed May  3 22:54:42 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_ialloc.c - 1.134
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc.c.diff?r1=text&tr1=1.134&r2=text&tr2=1.133&f=h
linux/fs/xfs/xfs_inode.c - 1.281
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.281&r2=text&tr2=1.280&f=h
	- fix wrapping of di_next_unlinked


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:43 2000
Received:  by oss.sgi.com id <S305178AbQEDXLP>;
	Thu, 4 May 2000 16:11:15 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:30590 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEDXLJ>;
	Thu, 4 May 2000 16:11:09 -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 QAA14991
	for <linux-xfs@oss.sgi.com>; Thu, 4 May 2000 16:06:18 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA17857 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 5 May 2000 09:09:47 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA31091 for linux-xfs@oss.sgi.com; Fri, 5 May 2000 09:09:46 +1000 (EST)
Date:   Fri, 5 May 2000 09:09:46 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005042309.JAA31091@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - PLEASE NOTE : cycle/block confusion in LSN
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

In my recent checkin of architecture mods on the log code, I flipped
the order of the cycle/block number components within the LSN on
native intel xfs.

The new order was logically correct, but unintentional.

This change reverts to the ordering that existed before my checkin
and should allow people to mount older filesystems again. Of course
the downside is that filesystems made between the two checkins won't
be mountable.

Hopefully this is the lesser of two evils.

Modid:  2.3.99pre2-xfs:slinx:60651a
Date:  Thu May  4 16:02:26 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_log.h - 1.49
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.h.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h
	- change back to original ordering of cycle & block within LSN


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:43 2000
Received:  by oss.sgi.com id <S305185AbQEDXsZ>;
	Thu, 4 May 2000 16:48:25 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:62051 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEDXsF>; Thu, 4 May 2000 16:48:05 -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 QAA04631
	for <linux-xfs@oss.sgi.com>; Thu, 4 May 2000 16:51:57 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA18080 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 5 May 2000 09:46:19 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA52543 for linux-xfs@oss.sgi.com; Fri, 5 May 2000 09:46:18 +1000 (EST)
Date:   Fri, 5 May 2000 09:46:18 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005042346.JAA52543@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - LSN on MIPS fix
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

A fix to a fix, whaddaya know.

Modid:  2.3.99pre2-xfs:slinx:60655a
Date:  Thu May  4 16:45:24 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_log.h - 1.50
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.h.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h
	- fix MIPS mode


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:43 2000
Received:  by oss.sgi.com id <S305186AbQEEAM4>;
	Thu, 4 May 2000 17:12:56 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:10509 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEEAMf>;
	Thu, 4 May 2000 17:12: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 RAA20275
	for <linux-xfs@oss.sgi.com>; Thu, 4 May 2000 17:07:46 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA18309 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 5 May 2000 10:10:02 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA98484 for linux-xfs@oss.sgi.com; Fri, 5 May 2000 10:10:01 +1000 (EST)
Date:   Fri, 5 May 2000 10:10:01 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005050010.KAA98484@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - remaining architecture mods for xfs_bmbt_ptr_t
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.3.99pre2-xfs:slinx:60659a
Date:  Thu May  4 17:09:45 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_bmap_btree.c - 1.109
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap_btree.c.diff?r1=text&tr1=1.109&r2=text&tr2=1.108&f=h
linux/fs/xfs/xfsidbg.c - 1.139
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.139&r2=text&tr2=1.138&f=h
	- remaining architecture mods for xfs_bmbt_ptr_t


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:44 2000
Received:  by oss.sgi.com id <S305164AbQEEOP7>;
	Fri, 5 May 2000 07:15:59 -0700
Received: from uwast.astro.wisc.edu ([144.92.179.130]:1553 "EHLO
        uwast.astro.wisc.edu") by oss.sgi.com with ESMTP id <S305154AbQEEOPm>;
	Fri, 5 May 2000 07:15:42 -0700
Received: from astro.wisc.edu (jansen@voodoo.astro.wisc.edu [144.92.179.132])
	by uwast.astro.wisc.edu (8.10.1/8.10.1) with ESMTP id e45EFV41336308
	for <linux-xfs@oss.sgi.com>; Fri, 5 May 2000 09:15:31 -0500 (CDT)
Message-ID: <3912D783.FA6D843F@astro.wisc.edu>
Date:   Fri, 05 May 2000 09:15:31 -0500
From:   jansen <jansen@astro.wisc.edu>
X-Mailer: Mozilla 4.7 [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: IRIX xfs code?
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,

This is pretty much unrelated to linux-xfs (sorry!) but I'd really
like to have a look at the IRIX versions of some of the xfs code,
in particular the sim stuff, especially libdisk.c.  It looks like
this file may have either been rewritten for linux or cleaned of
IRIX specific code.  I could easily be wrong, of course.

I'm trying to figure out why our Origin refuses to mkfs_xfs any newly
created XLV volumes (xlv_make creates them without error and they
assemble OK).  mkfs_xfs always complains with something like:

mkfs_xfs: attempt to use partition that is already in use

mkfs_xfs: devname             seq owner   state
mkfs_xfs: /dev/rdsk/dks3d2s7    1 xlv     already in use

I do have three XLV volumes on this machine that work without
problems.

I can also not mount XLV volumes created on other machines (after
changing the xlv hostname).  It gives the same error.  I know
that these partitions are not in use.

Sorry for posting this here but I posted to USENET, sent email to 
my Varsity support person and tried everything I can think of to
fix this problem without success.

-- 


------- Stephan

From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:44 2000
Received:  by oss.sgi.com id <S305188AbQEESyh>;
	Fri, 5 May 2000 11:54:37 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:46641 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEESyU>; Fri, 5 May 2000 11:54:20 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA04261
	for <linux-xfs@oss.sgi.com>; Fri, 5 May 2000 11:58:38 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA18939 for <linux-xfs@oss.sgi.com>; Fri, 5 May 2000 13:53:01 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id NAA02783 for <linux-xfs@oss.sgi.com>; Fri, 5 May 2000 13:53:01 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id NAA30616; Fri, 5 May 2000 13:53:01 -0500 (CDT)
Message-Id: <200005051853.NAA30616@tiki.americas.sgi.com>
Date:   Fri, 5 May 2000 13:53:01 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Vntrace memory allocation fixes + minor cleanups.
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.3.99pre2-xfs:slinx:60688a
Date:  Fri May  5 11:51:15 PDT 2000
Workarea:  tiki.americas.sgi.com:/data/clink/io/jtk/work-linux2.3-99

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

linux/fs/xfs/linux/xfs_aclstubs.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_aclstubs.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
	- Fix compiler warning.

linux/fs/xfs/linux/xfs_fs_bio.c - 1.31
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_fs_bio.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h
	- Rename 'rbufs' to 'xfs_rbufs'.

linux/fs/xfs/linux/xfs_random.c - 1.35
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h
	- Add debug code to catch times where kmem_alloc callers
	  with KM_SLEEP set would've gotten a NULL return.

linux/fs/xfs/macstubs.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/macstubs.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
	- Fix compiler warning.

linux/fs/xfs/pseudo-inc/sys/kmem.h - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/kmem.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
	- Previously KM_SLEEP was defined as a '0', which when and'd
	  with just about anything rarely comes up non-zero.

linux/fs/xfs/xfs_buf_item.c - 1.100
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.c.diff?r1=text&tr1=1.100&r2=text&tr2=1.99&f=h
linux/fs/xfs/xfs_dquot.c - 1.46
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dquot.c.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h
linux/fs/xfs/xfs_inode.c - 1.282
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.282&r2=text&tr2=1.281&f=h
linux/fs/xfs/xfs_log.c - 1.214
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.214&r2=text&tr2=1.213&f=h
	- Add a specific KM_SLEEP flag to the ktrace_alloc()
	  invocations.

linux/fs/xfs/xfs_vfsops.c - 1.264
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vfsops.c.diff?r1=text&tr1=1.264&r2=text&tr2=1.263&f=h
	- Add a specific KM_SLEEP flag to the ktrace_alloc()
	  invocations.
	  Return the 'rbufs' zone at module unload time.



From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:44 2000
Received:  by oss.sgi.com id <S305191AbQEET61>;
	Fri, 5 May 2000 12:58:27 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35386 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEET6U>; Fri, 5 May 2000 12:58:20 -0700
Received: from eag-eaga002e--n.americas.sgi.com (eag-eaga002e--n.cray.com [128.162.194.227]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA03321
	for <linux-xfs@oss.sgi.com>; Fri, 5 May 2000 13:02:38 -0700 (PDT)
	mail_from (btg@SGI.com)
Received: by eag-eaga002e--n.americas.sgi.com with Internet Mail Service (5.5.2650.21)
	id <KKN8JDC3>; Fri, 5 May 2000 14:57:26 -0500
Message-ID: <ED373A183611D311A6220060943F134CC1929F@eag-eaga002e--n.americas.sgi.com>
From:   Brian Gaffey <btg@SGI.com>
To:     "'jansen'" <jansen@astro.wisc.edu>, linux-xfs@oss.sgi.com
Subject: RE: IRIX xfs code?
Date:   Fri, 5 May 2000 14:57:25 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi - this is not really the forum for XLV on IRIX 
issues. However, I'll send your note to our support
folks.

Brian

> -----Original Message-----
> From: jansen [mailto:jansen@astro.wisc.edu]
> Sent: Friday, May 05, 2000 9:16 AM
> To: linux-xfs@oss.sgi.com
> Subject: IRIX xfs code?
> 
> 
> 
> Hi,
> 
> This is pretty much unrelated to linux-xfs (sorry!) but I'd really
> like to have a look at the IRIX versions of some of the xfs code,
> in particular the sim stuff, especially libdisk.c.  It looks like
> this file may have either been rewritten for linux or cleaned of
> IRIX specific code.  I could easily be wrong, of course.
> 
> I'm trying to figure out why our Origin refuses to mkfs_xfs any newly
> created XLV volumes (xlv_make creates them without error and they
> assemble OK).  mkfs_xfs always complains with something like:
> 
> mkfs_xfs: attempt to use partition that is already in use
> 
> mkfs_xfs: devname             seq owner   state
> mkfs_xfs: /dev/rdsk/dks3d2s7    1 xlv     already in use
> 
> I do have three XLV volumes on this machine that work without
> problems.
> 
> I can also not mount XLV volumes created on other machines (after
> changing the xlv hostname).  It gives the same error.  I know
> that these partitions are not in use.
> 
> Sorry for posting this here but I posted to USENET, sent email to 
> my Varsity support person and tried everything I can think of to
> fix this problem without success.
> 
> -- 
> 
> 
> ------- Stephan
> 

From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:44 2000
Received:  by oss.sgi.com id <S305192AbQEEUKH>;
	Fri, 5 May 2000 13:10:07 -0700
Received: from rf-mail1.echostar.com ([205.172.144.40]:60423 "EHLO
        rf-exch2.echostar.com") by oss.sgi.com with ESMTP
	id <S305154AbQEEUJq>; Fri, 5 May 2000 13:09:46 -0700
Received: from echostar.com (linux10.echostar.com [172.20.50.110]) by rf-exch2.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id KKY893PM; Fri, 5 May 2000 14:09:39 -0600
Message-ID: <39132A9C.F21AA67E@echostar.com>
Date:   Fri, 05 May 2000 14:10:04 -0600
From:   "Ian S. Nelson" <ian.nelson@echostar.com>
Reply-To: ian.nelson@echostar.com
Organization: Echostar
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Problems running on Cyrix Media GX
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


Two questions:  I'm building an embedded system and we're going to put
XFS in to it.  Right now the processor is a National Semiconductor/Cyrix
MediaGX integrated part.  When I try to run the XFS kernel on it it
panics during the WP bit check at boot up.  I don't believe this has
anything to do with XFS but some of the other goodies in the XFS kernel
like the debugger.  Is there any way to get just the XFS code in a
patch?

We like the debugger and will probably do what it takes to make it work
with our hardware but first thing's first.

Second:  a couple weeks ago I was causing XFS crashes with NFS,
I promised to post a stack trace but then I got pulled on to more
pressing matters here.  Is that still being worked on or has it been
sniffed out or what?  Early next week I should have some more bandwidth
to work on XFS issues.

thanks,
Ian Nelson


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:44 2000
Received:  by oss.sgi.com id <S305194AbQEEWtb>;
	Fri, 5 May 2000 15:49:31 -0700
Received: from rf-mail1.echostar.com ([205.172.144.40]:19207 "EHLO
        rf-exch2.echostar.com") by oss.sgi.com with ESMTP
	id <S305154AbQEEWtN>; Fri, 5 May 2000 15:49:13 -0700
Received: from echostar.com (linux10.echostar.com [172.20.50.110]) by rf-exch2.echostar.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id KKY89RCC; Fri, 5 May 2000 16:49:06 -0600
Message-ID: <39134FFB.CDEF0D96@echostar.com>
Date:   Fri, 05 May 2000 16:49:32 -0600
From:   "Ian S. Nelson" <ian.nelson@echostar.com>
Reply-To: ian.nelson@echostar.com
Organization: Echostar
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Fixed problems running on Cyrix MediaGX..
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 ripped out enough of the non-XFS code to get it working on our MediaGX
machine,  I think it might be that etherboot stuff now and not the
kernel debugger.  Hopefully Monday or Tuesday I can put some effort in
to tracking that down.

Now I have another question...

I'm not sure how much of this is secret and how much isn't but the scene
looks something like this:  We are building an embedded machine that has
a huge harddrive in it.  Our current requirements are to be able to
stream 3 streams of data at 2.5 MBytes/sec, to writers and one reader.

With Ext2 we can shoulder that load with our MediaGX.  We have a test
harness that measures it.  With standard system I/O we can sustain that
data rate with 13% CPU load.  With mapped I/O we can do it with 9% CPU
load.  The drive is tricked out with full UDMA.

So I hacked the XFS kernel up so it would run on the MediaGX and the
numbers were stunning.  With standard I/O it couldn't sustain that data
rate with our default test settings (we can adjust a few parameters and
since the 5th and final game of the western conference semis between the
Detriot DeadWings and the Colorado Avs is on in about an hour I'm going
to do it another time and not today..)  and it used ~70% CPU load, it
missed the mark by about 30%.  With mapped I/O it really couldn't
sustain that data rate and took ~81% CPU load, it took over twice as
long as it should.

Our test isn't scientific yet, I just hacked a kernel and ran it.  I
also have tuned anything, but what kinds of performance work is there to
be done on XFS.  I understand that it's still way ahead of release but
is there any sort of estimate on how it should performance and what
kinds of CPU use it should take?  I would expect XFS to outperform Ext2
in throughput but will that cost a lot of CPU cycles?

thanks, and have a great weekend.

Ian Nelson



From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:44 2000
Received:  by oss.sgi.com id <S305195AbQEEWxV>;
	Fri, 5 May 2000 15:53:21 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24397 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEEWxM>; Fri, 5 May 2000 15:53:12 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA06779
	for <linux-xfs@oss.sgi.com>; Fri, 5 May 2000 15:57:31 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA63291 for <linux-xfs@oss.sgi.com>; Fri, 5 May 2000 17:51:54 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id RAA12019 for <linux-xfs@oss.sgi.com>; Fri, 5 May 2000 17:51:55 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id RAA12217; Fri, 5 May 2000 17:51:54 -0500 (CDT)
Message-Id: <200005052251.RAA12217@nt8.americas.sgi.com>
Date:   Fri, 5 May 2000 17:51:54 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Changes to help reduce corruptions.
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.3.99pre2-xfs:slinx:59964a
Date:  Thu Apr 27 11:46:30 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs

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

cmd/xfs/sim/src/Makefile - 1.76
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/Makefile.diff?r1=text&tr1=1.76&r2=text&tr2=1.75&f=h
	- check for no-unknown-pragmas

Subject: TAKE - 

Modid:  2.3.99pre2-xfs:slinx:60726a
Date:  Fri May  5 15:50:05 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs

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

linux/fs/page_buf.c - 1.85
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h
	- use correct function to lookup up cached pages
	  grab_cache_page. seems to help reduce the corruptions.
	  Still seeing some corruption.

linux/fs/xfs/linux/xfs_file.c - 1.27
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_file.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h
linux/fs/xfs/linux/xfs_lrw.c - 1.38
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h
	- Change the position updates for case APPEND, protect via the inode lock.


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:44 2000
Received:  by oss.sgi.com id <S305160AbQEHDhu>;
	Sun, 7 May 2000 20:37:50 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21273 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEHDhb>; Sun, 7 May 2000 20:37:31 -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 UAA03612
	for <linux-xfs@oss.sgi.com>; Sun, 7 May 2000 20:41:50 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA09126 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 8 May 2000 13:36:11 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA38512 for linux-xfs@oss.sgi.com; Mon, 8 May 2000 13:36:09 +1000 (EST)
Date:   Mon, 8 May 2000 13:36:09 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005080336.NAA38512@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - add mount failure diagnostics
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.3.99pre2-xfs:slinx:60970a
Date:  Sun May  7 20:35:52 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_log.c - 1.215
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.215&r2=text&tr2=1.214&f=h
linux/fs/xfs/xfs_log_recover.c - 1.177
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.177&r2=text&tr2=1.176&f=h
linux/fs/xfs/xfs_mount.c - 1.218
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.218&r2=text&tr2=1.217&f=h

From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:44 2000
Received:  by oss.sgi.com id <S305162AbQEHEHj>;
	Sun, 7 May 2000 21:07:39 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:60180 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEHEHP>;
	Sun, 7 May 2000 21:07:15 -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 VAA03716
	for <linux-xfs@oss.sgi.com>; Sun, 7 May 2000 21:02:25 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA09306 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 8 May 2000 14:04:41 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA23456 for linux-xfs@oss.sgi.com; Mon, 8 May 2000 14:04:41 +1000 (EST)
Date:   Mon, 8 May 2000 14:04:41 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005080404.OAA23456@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - arch bugfix in 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

Modid:  2.3.99pre2-xfs:slinx:60971a
Date:  Sun May  7 21:04:24 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

cmd/xfs/db/bmap.c - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/bmap.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
	- arch bugfix


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:45 2000
Received:  by oss.sgi.com id <S305163AbQEHF6v>;
	Sun, 7 May 2000 22:58:51 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:44572 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEHF6q>; Sun, 7 May 2000 22:58:46 -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 XAA08212
	for <linux-xfs@oss.sgi.com>; Sun, 7 May 2000 23:03:04 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA09949 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 8 May 2000 15:57:25 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA77552 for linux-xfs@oss.sgi.com; Mon, 8 May 2000 15:57:20 +1000 (EST)
Date:   Mon, 8 May 2000 15:57:20 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005080557.PAA77552@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix subtle bmbt arch bug
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.3.99pre2-xfs:slinx:60972a
Date:  Sun May  7 22:56:59 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs

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

linux/fs/xfs/xfs_bmap_btree.c - 1.110
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap_btree.c.diff?r1=text&tr1=1.110&r2=text&tr2=1.109&f=h
	- fix arch bug


From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:45 2000
Received:  by oss.sgi.com id <S305168AbQEHQLe>;
	Mon, 8 May 2000 09:11:34 -0700
Received: from [216.208.98.2] ([216.208.98.2]:54768 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305154AbQEHQLM>;
	Mon, 8 May 2000 09:11:12 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id MAA02615
	for linux-xfs@oss.sgi.com; Mon, 8 May 2000 12:11:10 -0400
Date:   Mon, 8 May 2000 12:11:10 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     linux-xfs@oss.sgi.com
Subject: xfs_bmapi
Message-ID: <20000508121110.A2426@linuxcare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Am I correct in seeing that xfs_bmapi() treats argument 3 (block
number) as pagesize blocks?  (If not, the rest of my questions don't
really apply...)

Is there a rational way to make it treat these as 512 byte disk
blocks, or am I going to have to hack around this in the code that
calls into it?  If I have to hack around it, is it possible to have a
page-aligned, page-sized piece of file data sit on (pagesize/512)
non-contiguous blocks?  Even if that's not possible, how can this
bmapi code handle this situation when a disk is moved to a machine
with a larger pagesize, where it may now sit on discontiguous blocks?

The reason I ask is because I have a patch that makes lilo load
kernels from XFS FSes, but I really doubt it'll work yet on
non-4k-pagesize machines (I guess none of them use lilo, but I hate to
leave broken interfaces in there regardless).

-Phil

From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:45 2000
Received:  by oss.sgi.com id <S305170AbQEHQqE>;
	Mon, 8 May 2000 09:46:04 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:41029 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEHQpi>; Mon, 8 May 2000 09:45:38 -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 JAA08501
	for <linux-xfs@oss.sgi.com>; Mon, 8 May 2000 09:50:00 -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 JAA54879; Mon, 8 May 2000 09:42:58 -0700 (PDT)
Message-ID: <3916EEA5.CA068CB4@sgi.com>
Date:   Mon, 08 May 2000 09:43:17 -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:     Phil Schwan <phil@linuxcare.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: xfs_bmapi
References: <20000508121110.A2426@linuxcare.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

Phil Schwan wrote:
> 
> Am I correct in seeing that xfs_bmapi() treats argument 3 (block
> number) as pagesize blocks?  (If not, the rest of my questions don't
> really apply...)

I don't think so. xfs_bmapi & in fact most of xfs works
with 512-byte blocks. The exception is fs/page_buf.c,
where the I/O paths work on PAGE_SIZE sized buffers.

> 
> Is there a rational way to make it treat these as 512 byte disk
> blocks, or am I going to have to hack around this in the code that
> calls into it?  If I have to hack around it, is it possible to have a
> page-aligned, page-sized piece of file data sit on (pagesize/512)
> non-contiguous blocks?  Even if that's not possible, how can this
> bmapi code handle this situation when a disk is moved to a machine
> with a larger pagesize, where it may now sit on discontiguous blocks?
> 
> The reason I ask is because I have a patch that makes lilo load
> kernels from XFS FSes, but I really doubt it'll work yet on
> non-4k-pagesize machines (I guess none of them use lilo, but I hate to
> leave broken interfaces in there regardless).

Yes, I agree: non-4K sized buffers may not work. This is not
a deliberate choice, more like, its not been tested. Non-PAGE_SIZED
buffers won't work.


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

From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:45 2000
Received:  by oss.sgi.com id <S305171AbQEHRDD>;
	Mon, 8 May 2000 10:03:03 -0700
Received: from [216.208.98.2] ([216.208.98.2]:64755 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305154AbQEHRCn>;
	Mon, 8 May 2000 10:02:43 -0700
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id NAA02782;
	Mon, 8 May 2000 13:02:43 -0400
Date:   Mon, 8 May 2000 13:02:43 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: xfs_bmapi
Message-ID: <20000508130243.C2426@linuxcare.com>
References: <20000508121110.A2426@linuxcare.com> <3916EEA5.CA068CB4@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <3916EEA5.CA068CB4@sgi.com>; from Rajagopal Ananthanarayanan on Mon, May 08, 2000 at 09:43:17AM -0700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On May 08, Rajagopal Ananthanarayanan wrote:
> Phil Schwan wrote:
> > Am I correct in seeing that xfs_bmapi() treats argument 3 (block
> > number) as pagesize blocks?  (If not, the rest of my questions don't
> > really apply...)
> 
> I don't think so. xfs_bmapi & in fact most of xfs works
> with 512-byte blocks. The exception is fs/page_buf.c,
> where the I/O paths work on PAGE_SIZE sized buffers.

Hmm, this is very odd then.

xfs_bmapi(bno=x) returns y, and xfs_bmapi(bno=x+1) returns y + 8, and
I continue along those lines and reach the end of the file 8 times
faster than expected.

In the end, I do something like this:

        xfsblock = block >> 3;

        error = xfs_bmapi(NULL, xfs_inode, xfsblock, 1, 0, NULL, 0, &mval,
                          &nmaps, NULL);
        return XFS_FSB_TO_DB(xfs_inode, mval.br_startblock) + (block & 7);

and it seems to work.  Oh well, I guess I can slather it in FIXMEs and
cross that bridge when we come to it.

-Phil

From owner-linux-xfs@oss.sgi.com Mon May  8 23:07:45 2000
Received:  by oss.sgi.com id <S305172AbQEHRyy>;
	Mon, 8 May 2000 10:54:54 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:34640 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEHRye>; Mon, 8 May 2000 10:54:34 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA08751
	for <linux-xfs@oss.sgi.com>; Mon, 8 May 2000 10:58:56 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA50769; Mon, 8 May 2000 12:53:15 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id MAA13614; Mon, 8 May 2000 12:53:15 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id MAA06908; Mon, 8 May 2000 12:53:11 -0500 (CDT)
Message-Id: <200005081753.MAA06908@fsgi344.americas.sgi.com>
Subject: Re: xfs_bmapi
To:     phil@linuxcare.com (Phil Schwan)
Date:   Mon, 8 May 2000 12:53:09 -0500 (CDT)
Cc:     ananth@sgi.com (Rajagopal Ananthanarayanan), linux-xfs@oss.sgi.com
In-Reply-To: <20000508130243.C2426@linuxcare.com> from "Phil Schwan" at May 08, 2000 01:02:43 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


Your assumption is wrong. xfs_bmapi takes the 3rd parameter as a file system
block number.

Look at xfs_iomap_read(). It converts the given offset into
the offset_fsb by using:

        offset_fsb = XFS_B_TO_FSBT(mp, offset);

This is what is passed to XFS_BMAPI.

The macro does:

#define XFS_B_TO_FSBT(mp,b)     (((__uint64_t)(b)) >> (mp)->m_sb.sb_blocklog)

This is:

	__uint8_t       sb_blocklog;    /* log2 of sb_blocksize */

sb_blocklog is 12 when your file system blocksize is 4096.  We can create
other file system block sizes which are bigger/smaller (hasn't been tested
yet on Linux and there is a work item for this).

Anywho, the offset gets converted to the file system block # using
the above macro and xfs_bmapi returns an array of imap's that are once
again in sb_blocksize units (for startblock). This then gets converted
in _xfs_imap_to_bmap into the sector size units (512 byte units) using

		pbmapp->pbm_bn = XFS_FSB_TO_DB_IO(io, start_block);

This is really just doing:

XFS_FSB_TO_DADDR()

which is doing:

XFS_AGB_TO_DADDR(mp, XFS_FSB_TO_AGNO(mp,fsbno), XFS_FSB_TO_AGBNO(mp,fsbno))

which is doing:

#define XFS_AGB_TO_DADDR(mp,agno,agbno) \
	((daddr_t)(XFS_FSB_TO_BB(mp, (xfs_fsblock_t)(agno) * (mp)->m_sb.sb_agblocks + (agbno))))

which is doing:

XFS_FSB_TO_BB(mp,fsbno) ((fsbno) << (mp)->m_blkbb_log)

Note that XFS_AGB_TO_DADDR adds some for each ag header space beyond the zeroth
AG.

The m_blkbb_log is really sb_blocklog - BBSHIFT.
BBSHIFT (basic block shift) is always 9 since 2^9 is 512.
sb_blocklog varies with the file system block size. In the current default
case, sb_blocklog is 12 so XFS_FSB_TO_DB_IO will left shift by 3 in the zeroth
AG and will add a header area and then left shift by 3 for other ags.

Summarizing, the input to xfs_bmapi's 3rd parameter is in file system block
units which varies depending on the file system block size. see mkfs' output.

The output from xfs_bmapi are xfs_bmbt_irec_t structures which contain
a block number in file system block units without adjustment for all but
the zeroth AG headers. XFS_FSB_TO_DB_IO() converts these block numbers into
512 units such that one can find the block on disk.

The pagebuf_bmap routine handles all this conversion. It's input is
byte offset and the output is actual 512 block number to read.

Jim


>
>On May 08, Rajagopal Ananthanarayanan wrote:
>> Phil Schwan wrote:
>> > Am I correct in seeing that xfs_bmapi() treats argument 3 (block
>> > number) as pagesize blocks?  (If not, the rest of my questions don't
>> > really apply...)
>> 
>> I don't think so. xfs_bmapi & in fact most of xfs works
>> with 512-byte blocks. The exception is fs/page_buf.c,
>> where the I/O paths work on PAGE_SIZE sized buffers.
>
>Hmm, this is very odd then.
>
>xfs_bmapi(bno=x) returns y, and xfs_bmapi(bno=x+1) returns y + 8, and
>I continue along those lines and reach the end of the file 8 times
>faster than expected.
>
>In the end, I do something like this:
>
>        xfsblock = block >> 3;
>
>        error = xfs_bmapi(NULL, xfs_inode, xfsblock, 1, 0, NULL, 0, &mval,
>                          &nmaps, NULL);
>        return XFS_FSB_TO_DB(xfs_inode, mval.br_startblock) + (block & 7);
>
>and it seems to work.  Oh well, I guess I can slather it in FIXMEs and
>cross that bridge when we come to it.
>
>-Phil
>


From owner-linux-xfs@oss.sgi.com Tue May  9 18:42:28 2000
Received:  by oss.sgi.com id <S305155AbQEID4v>;
	Tue, 9 May 2000 03:56:51 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:15882 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEID4f>; Tue, 9 May 2000 03:56:35 +0000
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 VAA08883
	for <linux-xfs@oss.sgi.com>; Mon, 8 May 2000 21:00:56 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA18115 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 9 May 2000 13:55:16 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA58123 for linux-xfs@oss.sgi.com; Tue, 9 May 2000 13:55:15 +1000 (EST)
Date:   Tue, 9 May 2000 13:55:15 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005090355.NAA58123@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - change INT_COPY definition
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

- clean up confusing semantics and definition for INT_COPY
- change uses
- (change uses in mangle - though mangle is no longer useful)

Modid:  2.3.99pre2-xfs:slinx:61084a
Date:  Mon May  8 20:51:48 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.3.99pre2-xfs

cmd/xfs/mangle/agf.c - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/agf.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
cmd/xfs/mangle/agi.c - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/agi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
cmd/xfs/mangle/btree.c - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/btree.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
cmd/xfs/mangle/dirs.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/dirs.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
cmd/xfs/mangle/inodes.c - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/inodes.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
cmd/xfs/mangle/sb.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/sb.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
cmd/xfs/mangle/xfs_mangle.h - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/xfs_mangle.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/fs/xfs/xfs_arch.h - 1.25
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_arch.h.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h
linux/fs/xfs/xfs_inode.c - 1.283
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.283&r2=text&tr2=1.282&f=h
linux/fs/xfs/xfs_mount.c - 1.219
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.219&r2=text&tr2=1.218&f=h

From owner-linux-xfs@oss.sgi.com Tue May  9 18:42:28 2000
Received:  by oss.sgi.com id <S305157AbQEIEnl>;
	Tue, 9 May 2000 04:43:41 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:64582 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEIEnM>;
	Tue, 9 May 2000 04:43:12 +0000
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 VAA07037
	for <linux-xfs@oss.sgi.com>; Mon, 8 May 2000 21:38:21 -0700 (PDT)
	mail_from (ivanr@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA18402 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 9 May 2000 14:40:33 +1000
Received: (from ivanr@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA36977 for linux-xfs@oss.sgi.com; Tue, 9 May 2000 14:40:32 +1000 (EST)
Date:   Tue, 9 May 2000 14:40:32 +1000 (EST)
From:   ivanr@snort.melbourne.sgi.com (Ivan Rayner)
Message-Id: <200005090440.OAA36977@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - endian convert bmap btree key
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

endian convert bmap btree key

Modid:  2.3.99pre2-xfs:slinx:61085a
Date:  Mon May  8 21:39:04 PDT 2000
Workarea:  snort:/hosts/bruce/home/ivanr/isms/slinx-xfs-mips
Author:  ivanr

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

linux/fs/xfs/xfs_bmap.c - 1.251
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap.c.diff?r1=text&tr1=1.251&r2=text&tr2=1.250&f=h
linux/fs/xfs/xfs_bmap_btree.c - 1.111
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap_btree.c.diff?r1=text&tr1=1.111&r2=text&tr2=1.110&f=h
linux/fs/xfs/xfs_btree.c - 1.83
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_btree.c.diff?r1=text&tr1=1.83&r2=text&tr2=1.82&f=h
linux/fs/xfs/xfsidbg.c - 1.140
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.140&r2=text&tr2=1.139&f=h

From owner-linux-xfs@oss.sgi.com Tue May  9 18:42:28 2000
Received:  by oss.sgi.com id <S305158AbQEIGiB>;
	Tue, 9 May 2000 06:38:01 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:35668 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEIGhf>;
	Tue, 9 May 2000 06:37:35 +0000
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 XAA17195
	for <linux-xfs@oss.sgi.com>; Mon, 8 May 2000 23:32:44 -0700 (PDT)
	mail_from (ivanr@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA19070 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 9 May 2000 16:36:16 +1000
Received: (from ivanr@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id QAA24582 for linux-xfs@oss.sgi.com; Tue, 9 May 2000 16:36:14 +1000 (EST)
Date:   Tue, 9 May 2000 16:36:14 +1000 (EST)
From:   ivanr@snort.melbourne.sgi.com (Ivan Rayner)
Message-Id: <200005090636.QAA24582@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - endian convert bmap btree key
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

forgot a file...

Modid:  2.3.99pre2-xfs:slinx:61086a
Date:  Mon May  8 23:35:42 PDT 2000
Workarea:  snort:/hosts/bruce/home/ivanr/isms/slinx-xfs-mips
Author:  ivanr

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

cmd/xfs/db/bmap.c - 1.27
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/bmap.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h
	- endian convert bmap key


From owner-linux-xfs@oss.sgi.com Tue May  9 18:42:28 2000
Received:  by oss.sgi.com id <S305160AbQEIJXy>;
	Tue, 9 May 2000 09:23:54 +0000
Received: from expanse.dds.nl ([194.109.10.118]:42505 "EHLO expanse.dds.nl")
	by oss.sgi.com with ESMTP id <S305154AbQEIJX3>;
	Tue, 9 May 2000 09:23:29 +0000
Received: (from ookhoi@localhost)
	by expanse.dds.nl (8.9.3/8.9.3) id LAA09377;
	Tue, 9 May 2000 11:22:23 +0200
Date:   Tue, 9 May 2000 11:22:23 +0200
From:   Ookhoi <ookhoi@dds.nl>
To:     cattelan@thebarn.com
Cc:     lord@sgi.com, linux-xfs@oss.sgi.com
Subject: Re: Hmmm out of memory error
Message-ID: <20000509112223.M14895@ookhoi.dds.nl>
Reply-To: ookhoi@dds.nl
References: <14590.17759.41450.64144V@gibble.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.14i
In-Reply-To: <14590.17759.41450.64144V@gibble.americas.sgi.com>; from cattelan@thebarn.com on Wed, Apr 19, 2000 at 06:46:39PM -0500
X-Uptime: 12:29pm  up 36 days, 16 min, 33 users,  load average: 0.46, 0.65, 0.62
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> FYI
> 
> 
> cmn_err level 1 Filesystem "ide0(3,1)": xfs_log_write: reservation ran out. Need to up reservation
> Corruption of in-memory data detected.  Shutting down filesystem: ide0(3,1)
> Please umount the filesystem, and rectify the problem(s)
> 
> Haven't looked into it yet.
> Will tomorrow...

Hi guys. Look at this:


[cut]
Received: from oss.sgi.com (oss.sgi.com [216.32.174.118])
	by alladin.dds.nl (8.9.1/8.9.1) with ESMTP id BAA23151
	for <ookhoi@dds.nl>; Tue, 9 May 2000 01:08:04 +0200 (MET DST)
Received:  by oss.sgi.com with SMTP id <S305162AbQEHXHv>;
	Mon, 8 May 2000 23:07:51 +0000
Received: by oss.sgi.com (bulk_mailer v1.12); Mon, 8 May 2000 23:07:51 +0000
Received:  by oss.sgi.com id <S305174AbQDSXt0>;
	Wed, 19 Apr 2000 16:49:26 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:30575 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305163AbQDSXtQ>;
	Wed, 19 Apr 2000 16:49:16 -0700

==========
20 days, how is dat possible? And I think I've seen this message before?

		Ookhoi


Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA28127
	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 16:44:30 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
From: cattelan@thebarn.com
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA89980 for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 18:46:44 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id SAA20286; Wed, 19 Apr 2000 18:46:34 -0500 (CDT)
Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id SAA30673; Wed, 19 Apr 2000 18:46:41 -0500
Date:   Wed, 19 Apr 2000 18:46:39 -0500
Message-ID: <14590.17759.41450.64144V@gibble.americas.sgi.com>
To: lord@sgi.com
cc: linux-xfs@oss.sgi.com
Subject: Hmmm out of memory error	
User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
Sender: owner-linux-xfs@oss.sgi.com
X-Orcpt: rfc822;linux-xfs-outgoing
Status: RO
Content-Length: 284
Lines: 9

FYI


cmn_err level 1 Filesystem "ide0(3,1)": xfs_log_write: reservation ran out. Need to up reservation
Corruption of in-memory data detected.  Shutting down filesystem: ide0(3,1)
Please umount the filesystem, and rectify the problem(s)

Haven't looked into it yet.
Will tomorrow...


From owner-linux-xfs@oss.sgi.com Tue May  9 18:42:28 2000
Received:  by oss.sgi.com id <S305162AbQEINMw>;
	Tue, 9 May 2000 13:12:52 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:38156 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEINMT>;
	Tue, 9 May 2000 13:12:19 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA24558
	for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 06:07:28 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA91565; Tue, 9 May 2000 08:11:00 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id IAA19593; Tue, 9 May 2000 08:10:59 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id IAA21314; Tue, 9 May 2000 08:10:58 -0500 (CDT)
Message-Id: <200005091310.IAA21314@fsgi344.americas.sgi.com>
Subject: Re: Hmmm out of memory error
To:     ookhoi@dds.nl
Date:   Tue, 9 May 2000 08:10:52 -0500 (CDT)
Cc:     cattelan@thebarn.com, lord@sgi.com, linux-xfs@oss.sgi.com
In-Reply-To: <20000509112223.M14895@ookhoi.dds.nl> from "Ookhoi" at May 09, 2000 11:22:23 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



It would be really good to have more info on this.
When xfs_log_write says "reservation ran out" it probably means
that we didn't reserve enough in the xfs_trans_reserve call.

Can you figure out what transaction type this is?
If you are running with kdb, you could print the stack after setting
a break point at xfs_cmn_err() or icmn_err().

If you load the xfsidbg module, you can then print out some
of the structures including the xfs_trans structure. You should see
xfs_trans_commit() on the stack. The first parameter (tp) is a
pointer to the trans structure. This structure will contain the
t_type
and the amount of space reserved and ...

This can then help us determine if we need to bump the reservation amount
or if there is some other problem.

The tp also points at all the "log items", t_items.

If you could get this info, it would be great.

Thanks,

Jim

>
>> FYI
>> 
>> 
>> cmn_err level 1 Filesystem "ide0(3,1)": xfs_log_write: reservation ran out. Need to up reservation
>> Corruption of in-memory data detected.  Shutting down filesystem: ide0(3,1)
>> Please umount the filesystem, and rectify the problem(s)
>> 
>> Haven't looked into it yet.
>> Will tomorrow...
>
>Hi guys. Look at this:
>
>
>[cut]
>Received: from oss.sgi.com (oss.sgi.com [216.32.174.118])
>	by alladin.dds.nl (8.9.1/8.9.1) with ESMTP id BAA23151
>	for <ookhoi@dds.nl>; Tue, 9 May 2000 01:08:04 +0200 (MET DST)
>Received:  by oss.sgi.com with SMTP id <S305162AbQEHXHv>;
>	Mon, 8 May 2000 23:07:51 +0000
>Received: by oss.sgi.com (bulk_mailer v1.12); Mon, 8 May 2000 23:07:51 +0000
>Received:  by oss.sgi.com id <S305174AbQDSXt0>;
>	Wed, 19 Apr 2000 16:49:26 -0700
>Received: from deliverator.sgi.com ([204.94.214.10]:30575 "EHLO
>        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305163AbQDSXtQ>;
>	Wed, 19 Apr 2000 16:49:16 -0700
>
>==========
>20 days, how is dat possible? And I think I've seen this message before?
>
>		Ookhoi
>
>
>Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA28127
>	for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 16:44:30 -0700 (PDT)
>	mail_from (cattelan@thebarn.com)
>From: cattelan@thebarn.com
>Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA89980 for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 18:46:44 -0500 (CDT)
>Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id SAA20286; Wed, 19 Apr 2000 18:46:34 -0500 (CDT)
>Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id SAA30673; Wed, 19 Apr 2000 18:46:41 -0500
>Date:   Wed, 19 Apr 2000 18:46:39 -0500
>Message-ID: <14590.17759.41450.64144V@gibble.americas.sgi.com>
>To: lord@sgi.com
>cc: linux-xfs@oss.sgi.com
>Subject: Hmmm out of memory error	
>User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
>Sender: owner-linux-xfs@oss.sgi.com
>X-Orcpt: rfc822;linux-xfs-outgoing
>Status: RO
>Content-Length: 284
>Lines: 9
>
>FYI
>
>
>cmn_err level 1 Filesystem "ide0(3,1)": xfs_log_write: reservation ran out. Need to up reservation
>Corruption of in-memory data detected.  Shutting down filesystem: ide0(3,1)
>Please umount the filesystem, and rectify the problem(s)
>
>Haven't looked into it yet.
>Will tomorrow...
>


From owner-linux-xfs@oss.sgi.com Tue May  9 18:42:28 2000
Received:  by oss.sgi.com id <S305156AbQEIPtB>;
	Tue, 9 May 2000 15:49:01 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:9263 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEIPsx>;
	Tue, 9 May 2000 15:48:53 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA16439
	for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 08:44:04 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA29156; Tue, 9 May 2000 10:46:20 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id KAA28568; Tue, 9 May 2000 10:46:19 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.10.1/SGI-client.1.6) via ESMTP id e49FkFo06483; Tue, 9 May 2000 10:46:15 -0500
Message-ID: <391832C7.2FA4B434@thebarn.com>
Date:   Tue, 09 May 2000 10:46:15 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     ookhoi@dds.nl
CC:     linux-xfs@oss.sgi.com
Subject: Re: Hmmm out of memory error
References: <14590.17759.41450.64144V@gibble.americas.sgi.com> <20000509112223.M14895@ookhoi.dds.nl>
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

Ookhoi wrote:
oss got rebooted yesterday...  that must have kicked loose some queued email.





> > FYI
> >
> >
> > cmn_err level 1 Filesystem "ide0(3,1)": xfs_log_write: reservation ran out. Need to up reservation
> > Corruption of in-memory data detected.  Shutting down filesystem: ide0(3,1)
> > Please umount the filesystem, and rectify the problem(s)
> >
> > Haven't looked into it yet.
> > Will tomorrow...
>
> Hi guys. Look at this:
>
> [cut]
> Received: from oss.sgi.com (oss.sgi.com [216.32.174.118])
>         by alladin.dds.nl (8.9.1/8.9.1) with ESMTP id BAA23151
>         for <ookhoi@dds.nl>; Tue, 9 May 2000 01:08:04 +0200 (MET DST)
> Received:  by oss.sgi.com with SMTP id <S305162AbQEHXHv>;
>         Mon, 8 May 2000 23:07:51 +0000
> Received: by oss.sgi.com (bulk_mailer v1.12); Mon, 8 May 2000 23:07:51 +0000
> Received:  by oss.sgi.com id <S305174AbQDSXt0>;
>         Wed, 19 Apr 2000 16:49:26 -0700
> Received: from deliverator.sgi.com ([204.94.214.10]:30575 "EHLO
>         deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305163AbQDSXtQ>;
>         Wed, 19 Apr 2000 16:49:16 -0700
>
> ==========
> 20 days, how is dat possible? And I think I've seen this message before?
>
>                 Ookhoi
>
> Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA28127
>         for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 16:44:30 -0700 (PDT)
>         mail_from (cattelan@thebarn.com)
> From: cattelan@thebarn.com
> Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA89980 for <linux-xfs@oss.sgi.com>; Wed, 19 Apr 2000 18:46:44 -0500 (CDT)
> Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.4) with ESMTP id SAA20286; Wed, 19 Apr 2000 18:46:34 -0500 (CDT)
> Received: from gibble.americas.sgi.com by gibble.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id SAA30673; Wed, 19 Apr 2000 18:46:41 -0500
> Date:   Wed, 19 Apr 2000 18:46:39 -0500
> Message-ID: <14590.17759.41450.64144V@gibble.americas.sgi.com>
> To: lord@sgi.com
> cc: linux-xfs@oss.sgi.com
> Subject: Hmmm out of memory error
> User-Agent: Wanderlust/1.0.3 (Notorious) tm/7.108 XEmacs/21.1 (Bryce Canyon)
> Sender: owner-linux-xfs@oss.sgi.com
> X-Orcpt: rfc822;linux-xfs-outgoing
> Status: RO
> Content-Length: 284
> Lines: 9
>
> FYI
>
> cmn_err level 1 Filesystem "ide0(3,1)": xfs_log_write: reservation ran out. Need to up reservation
> Corruption of in-memory data detected.  Shutting down filesystem: ide0(3,1)
> Please umount the filesystem, and rectify the problem(s)
>
> Haven't looked into it yet.
> Will tomorrow...


From owner-linux-xfs@oss.sgi.com Tue May  9 18:42:29 2000
Received:  by oss.sgi.com id <S305159AbQEIR4Y>;
	Tue, 9 May 2000 17:56:24 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:35667 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEIR4J>;
	Tue, 9 May 2000 17:56:09 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA08059
	for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 10:51:20 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA54229 for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 12:54:53 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id MAA05319 for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 12:54:51 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id MAA30275; Tue, 9 May 2000 12:54:51 -0500 (CDT)
Message-Id: <200005091754.MAA30275@nt8.americas.sgi.com>
Date:   Tue, 9 May 2000 12:54:51 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - back out fridays changes. 
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.3.99pre2-xfs:slinx:61117a
Date:  Tue May  9 10:53:09 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs
Author:  cattelan

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

linux/fs/page_buf.c - 1.88
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.88&r2=text&tr2=1.87&f=h
	- Back out the calls to grab_cache_page
	  grab_cache_page will allocate a page if it doesn't exist, which 
	  isn't correct at this point.
	  _pagebuf_file_write will call pagebguf_get 
	  which will do the page allocation.


From owner-linux-xfs@oss.sgi.com Tue May  9 18:42:29 2000
Received:  by oss.sgi.com id <S305164AbQEISGZ>;
	Tue, 9 May 2000 18:06:25 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:43350 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEISGK>;
	Tue, 9 May 2000 18:06:10 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA09918
	for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 11:01:21 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA42444 for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 13:04:54 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id NAA05907 for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 13:04:52 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.10.1/SGI-client.1.6) via ESMTP id e49I4mo07609; Tue, 9 May 2000 13:04:48 -0500
Message-ID: <39185340.126DDBD2@thebarn.com>
Date:   Tue, 09 May 2000 13:04:48 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: [Fwd: TAKE - bug fix.]
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




There is a limit on the number of attempts to lock down all
pages in the kiobuf (before issuing the request to the driver
layers) in pagebuf_kiobuf_io(). There was a bug in the code to 
unlock these pages for the case where this limit was exceeded. 
Fixed.

Modid:  2.3.99pre2-xfs:slinx:61114a
Date:  Tue May  9 10:43:05 PDT 2000
Workarea:  bonnie.engr.sgi.com:/build1/chait/2.3xfs-tot
Author:  chait

The following file(s) were checked into:
  bonnie:/isms/slinx/2.3.99pre2-xfs

linux/fs/page_buf.c - 1.87
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.87&r2=text&tr2=1.86&f=h
	- Bug fix in pagebuf_kiobuf_io(). Wasn't unlocking all pages on failing
	  attempt to lock pages before sending I/O request. Fixed.

From owner-linux-xfs@oss.sgi.com Tue May  9 20:42:15 2000
Received:  by oss.sgi.com id <S305155AbQEIUl4>;
	Tue, 9 May 2000 20:41:56 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33871 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEIUlZ>; Tue, 9 May 2000 20:41:25 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA00774
	for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 13:45:48 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA08822 for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 15:40:08 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id PAA15070 for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 15:40:08 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id PAA27414; Tue, 9 May 2000 15:40:07 -0500 (CDT)
Message-Id: <200005092040.PAA27414@nt8.americas.sgi.com>
Date:   Tue, 9 May 2000 15:40:07 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix kdbm_pb builds when page_buf is a module
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.3.99pre2-xfs:slinx:61126a
Date:  Tue May  9 13:39:29 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs
Author:  cattelan

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

linux/kdb/modules/kdbm_pb.c - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/modules/kdbm_pb.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
	- Added defined(CONFIG_PAGE_BUF_MODULE)


From owner-linux-xfs@oss.sgi.com Wed May 10 01:29:12 2000
Received:  by oss.sgi.com id <S305156AbQEJB2w>;
	Wed, 10 May 2000 01:28:52 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:41325 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEJB2e>; Wed, 10 May 2000 01:28:34 +0000
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 SAA06980
	for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 18:32:56 -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 LAA24950 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 10 May 2000 11:27:15 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id LAA73225 for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 11:27:14 +1000 (EST)
Message-Id: <200005100127.LAA73225@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
Subject: xfs_cmountfs bug
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 10 May 2000 11:27:13 +1000
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


The error return code in xfs_cmountfs checks three vnode_t pointers
to see if the coresponding buftargs in xfs_mount_t should be freed.

ldevvp, rdevvp and ddevvp are initialized to NULL, potentially set
to NULL a couple of times but never _set to non-NULL_ values. Hence
xfs_binval and linvfs_release_inode are never called on the allocated
objects.

Attached is an ugly hack that fixes the problem. I'll leave it up
to someone who knows what's meant to happen to fix it properly.

(to test: modprobe xfs, lsmod, try to mount a non-mounted, non-xfs
FS as an XFS fs, then lsmod again and check the usage counts - they
should increase for each failed mount)

dxm@sherman ~/isms/slinx-xfs> p_rdiff linux/fs/xfs/xfs_vfsops.c
503a504
>         ddevvp=(vnode_t*)1; /* XXX DXM hack */
505a507
>                 ldevvp=(vnode_t*)1; /* XXX DXM hack */
508a511
>                 rdevvp=(vnode_t*)1; /* XXX DXM hack */



-----------------------------------------------------
 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 Wed May 10 06:04:58 2000
Received:  by oss.sgi.com id <S305157AbQEJGEj>;
	Wed, 10 May 2000 06:04:39 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:13682 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEJGEK>;
	Wed, 10 May 2000 06:04:10 +0000
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 WAA21227
	for <linux-xfs@oss.sgi.com>; Tue, 9 May 2000 22:59:18 -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 QAA26511 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 10 May 2000 16:01:33 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id QAA72713 for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 16:01:29 +1000 (EST)
Message-Id: <200005100601.QAA72713@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
Subject: race in unmount code.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 10 May 2000 16:01:29 +1000
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 finally found a way of tickling an problem I've been seeing
every-so-often during my testing:

   yes cat /proc/mounts | tcsh & mount /dev/hda6 /mnt/arch0 -t xfs ; 
       umount /dev/hda6 ; kill %

    (one line - ie cat /proc/mounts repeatedly in the background whilst
     unmounting)

try it a couple of times until you get a NULL pointer dereference
in d_path.

I'm pretty sure the problem is because d_umount (called from do_umount in 
super.c) sets s_root to NULL then does other stuff which causes the
kernel to sleep and allows entry to get_filesystem_info from a
syscall while the superblock is in a screwy state.

After that, I'm lost - it does seem to be XFS specific.

(yes it's a contrived example, but it demonstrates a bug I've been
seeing in more or less normal operation)

Any ideas people? I've got to get back to testing.

-----------------------------------------------------
 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 Wed May 10 08:58:09 2000
Received:  by oss.sgi.com id <S305156AbQEJI6A>;
	Wed, 10 May 2000 08:58:00 +0000
Received: from Cantor.suse.de ([194.112.123.193]:65042 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S305154AbQEJI55>;
	Wed, 10 May 2000 08:57:57 +0000
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 344E31E167; Wed, 10 May 2000 10:57:55 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 959A110A026; Wed, 10 May 2000 10:57:54 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 09DCF2F36E; Wed, 10 May 2000 10:57:54 +0200 (MEST)
Date:   Wed, 10 May 2000 10:57:54 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: race in unmount code.
Message-ID: <20000510105753.A30364@gruyere.muc.suse.de>
References: <200005100601.QAA72713@clouds.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200005100601.QAA72713@clouds.melbourne.sgi.com>; from dxm@clouds.melbourne.sgi.com on Wed, May 10, 2000 at 04:01:29PM +1000
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, May 10, 2000 at 04:01:29PM +1000, Daniel Moore wrote:
> I'm pretty sure the problem is because d_umount (called from do_umount in 
> super.c) sets s_root to NULL then does other stuff which causes the
> kernel to sleep and allows entry to get_filesystem_info from a
> syscall while the superblock is in a screwy state.
> 
> After that, I'm lost - it does seem to be XFS specific.
> 
> (yes it's a contrived example, but it demonstrates a bug I've been
> seeing in more or less normal operation)
> 
> Any ideas people? I've got to get back to testing.

The vfsmnt stuff is very new in linux -- it was introduced only a few
patchlevels before the XFS kernel branched. So it is entirely possible
that the generic code is buggy. Maybe this patch will help:

--- linux/fs/super.c-o	Mon Mar 27 20:31:13 2000
+++ linux/fs/super.c	Wed May 10 10:58:32 2000
@@ -384,6 +384,8 @@
 	if (!buffer) return 0;
 	for (tmp = vfsmntlist; tmp && len < PAGE_SIZE - 160;
 	    tmp = tmp->mnt_next) {
+		if (!tmp->mnt_sb || !tmp->mnt_sb->s_root)
+			continue;
 		path = d_path(tmp->mnt_sb->s_root, buffer, PAGE_SIZE);
 		if (!path)
 			continue;

-Andi

From owner-linux-xfs@oss.sgi.com Wed May 10 17:36:53 2000
Received:  by oss.sgi.com id <S305160AbQEJRgn>;
	Wed, 10 May 2000 17:36:43 +0000
Received: from [216.208.98.2] ([216.208.98.2]:54522 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305154AbQEJRgj>;
	Wed, 10 May 2000 17:36:39 +0000
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id NAA13356;
	Wed, 10 May 2000 13:35:45 -0400
Date:   Wed, 10 May 2000 13:35:45 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: xfs_cmountfs bug
Message-ID: <20000510133544.A13139@linuxcare.com>
References: <200005100127.LAA73225@clouds.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="u3/rZRmxL6MmkK24"
X-Mailer: Mutt 0.95.4us
In-Reply-To: <200005100127.LAA73225@clouds.melbourne.sgi.com>; from Daniel Moore on Wed, May 10, 2000 at 11:27:13AM +1000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii

On May 10, Daniel Moore wrote:
> Attached is an ugly hack that fixes the problem. I'll leave it up
> to someone who knows what's meant to happen to fix it properly.
> 
> (to test: modprobe xfs, lsmod, try to mount a non-mounted, non-xfs
> FS as an XFS fs, then lsmod again and check the usage counts - they
> should increase for each failed mount)
> 
> dxm@sherman ~/isms/slinx-xfs> p_rdiff linux/fs/xfs/xfs_vfsops.c
> 503a504
> >         ddevvp=(vnode_t*)1; /* XXX DXM hack */
> 505a507
> >                 ldevvp=(vnode_t*)1; /* XXX DXM hack */
> 508a511
> >                 rdevvp=(vnode_t*)1; /* XXX DXM hack */

As far as I can tell, the sole purpose of {dd,ld,rd}evvp is to know
whether the inodes need freed in the case of an error.  I don't think
we need these variables at all.  It's impossible to get to that bit of
error cleanup code until after the buftargs are filled--thus, we can
just free them under the same conditions that we allocated them.

I prefer this patch.  If there's no objections, I'll commit it
tomorrow.

-Phil

-- 
Phil Schwan, Captain Popetastic, Linuxcare Canada

--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=vfsopspatch

--- /usr/tmp/TmpDir.788-0/linux/fs/xfs/xfs_vfsops.c_1.264	Wed May 10 09:36:03 2000
+++ linux/fs/xfs/xfs_vfsops.c	Wed May 10 09:35:59 2000
@@ -476,7 +476,6 @@
 	struct cred	*cr)
 {
 	xfs_mount_t	*mp;
-	vnode_t 	*ddevvp = NULL, *rdevvp = NULL, *ldevvp = NULL;
 	int		error = 0;
 	int		vfs_flags;
 	size_t		n;
@@ -526,7 +525,6 @@
 	}
 	if (logdev != 0) {
 		if (logdev == ddev) {
-			ldevvp = NULL;
 			mp->m_logdev_targ = mp->m_ddev_targ;
 		} else {
 			/* Ensure that logdev isn't already mounted */
@@ -580,8 +578,6 @@
 			else
 				strcpy(mp->m_fsname, "/");
 		}
-	} else {
-		ldevvp = NULL;
 	}
 	if (rtdev != 0) {
 		if (rtdev == ddev || rtdev == logdev) {
@@ -739,17 +735,16 @@
 	 * Be careful not to clobber the value of 'error' here.
 	 */
  error3:
-	if (ldevvp) {
+	/* It's impossible to get here before buftargs are filled */
+	xfs_binval(mp->m_ddev_targ);
+	linvfs_release_inode(mp->m_ddev_targ.inode);
+	if (logdev && logdev != ddev) {
 		xfs_binval(mp->m_logdev_targ);
 		linvfs_release_inode(mp->m_logdev_targ.inode);
 	}
-	if (rdevvp) {
+	if (rtdev != 0) {
 		xfs_binval(mp->m_rtdev_targ);
 		linvfs_release_inode(mp->m_rtdev_targ.inode);
-	}
-	if (ddevvp) {
-		xfs_binval(mp->m_ddev_targ);
-		linvfs_release_inode(mp->m_ddev_targ.inode);
 	}
 	if (error) {
 #ifdef CELL_CAPABLE

--u3/rZRmxL6MmkK24--

From owner-linux-xfs@oss.sgi.com Wed May 10 17:53:24 2000
Received:  by oss.sgi.com id <S305162AbQEJRxO>;
	Wed, 10 May 2000 17:53:14 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49704 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEJRxB>; Wed, 10 May 2000 17:53:01 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA07516
	for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 10:57:25 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA26105; Wed, 10 May 2000 12:51:27 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id MAA24351; Wed, 10 May 2000 12:51:26 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.10.1/SGI-client.1.6) via ESMTP id e4AHpLo11777; Wed, 10 May 2000 12:51:21 -0500
Message-ID: <3919A199.BE4F151@thebarn.com>
Date:   Wed, 10 May 2000 12:51:21 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Phil Schwan <phil@linuxcare.com>
CC:     Daniel Moore <dxm@clouds.melbourne.sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: xfs_cmountfs bug
References: <200005100127.LAA73225@clouds.melbourne.sgi.com> <20000510133544.A13139@linuxcare.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

Phil Schwan wrote:

> On May 10, Daniel Moore wrote:
> > Attached is an ugly hack that fixes the problem. I'll leave it up
> > to someone who knows what's meant to happen to fix it properly.
> >
> > (to test: modprobe xfs, lsmod, try to mount a non-mounted, non-xfs
> > FS as an XFS fs, then lsmod again and check the usage counts - they
> > should increase for each failed mount)
> >
> > dxm@sherman ~/isms/slinx-xfs> p_rdiff linux/fs/xfs/xfs_vfsops.c
> > 503a504
> > >         ddevvp=(vnode_t*)1; /* XXX DXM hack */
> > 505a507
> > >                 ldevvp=(vnode_t*)1; /* XXX DXM hack */
> > 508a511
> > >                 rdevvp=(vnode_t*)1; /* XXX DXM hack */
>
> As far as I can tell, the sole purpose of {dd,ld,rd}evvp is to know
> whether the inodes need freed in the case of an error.  I don't think
> we need these variables at all.  It's impossible to get to that bit of
> error cleanup code until after the buftargs are filled--thus, we can
> just free them under the same conditions that we allocated them.
>
> I prefer this patch.  If there's no objections, I'll commit it
> tomorrow.

Ted has mad a lot changes to the vnode/ linux inode's
I might be best to wait until his changes are done
before we chase the problem to much.


>
>
> -Phil
>
> --
> Phil Schwan, Captain Popetastic, Linuxcare Canada
>
>   ------------------------------------------------------------------------
>
>    vfsopspatchName: vfsopspatch
>               Type: Plain Text (text/plain)


From owner-linux-xfs@oss.sgi.com Wed May 10 12:43:04 2000
Received:  by oss.sgi.com id <S305154AbQEJTmy>;
	Wed, 10 May 2000 19:42:54 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:43273 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305165AbQEJTmg>;
	Wed, 10 May 2000 19:42:36 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA00224
	for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 12:37:46 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA21766; Wed, 10 May 2000 14:40:03 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id OAA00522; Wed, 10 May 2000 14:40:01 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.10.1/SGI-client.1.6) via ESMTP id e4AJduo12005; Wed, 10 May 2000 14:39:56 -0500
Message-ID: <3919BB0C.87D22D9B@thebarn.com>
Date:   Wed, 10 May 2000 14:39:56 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Ananth Ananthanarayanan <ananth@dbear.engr.sgi.com>,
        linux-xfs@oss.sgi.com
Subject: Re: TAKE - turn on delayed allocation
References: <200005101926.MAA17364@dbear.engr.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

Ananth Ananthanarayanan wrote:

> Since delay_alloc ON and PAGEBUF_META off
> seems to not hit the corruption problems,
> I'm turning delay_alloc on by default.

The corruption problem occurs with PAGEBUF_META off as well
as on.

Please don't through more variables in the mix just yet.


>
>
> Modid:  2.3.99pre2-xfs:slinx:61211a
> Date:  Wed May 10 12:21:37 PDT 2000
> Workarea:  bonnie.engr.sgi.com:/build2/ananth/slinx23-xfs
> Author:  ananth
>
> The following file(s) were checked into:
>   bonnie:/isms/slinx/2.3.99pre2-xfs
>
> linux/fs/page_buf.c - 1.89
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/page_buf.c.diff?r1=text&tr1=1.89&r2=text&tr2=1.88&f=h
>         - Cleanup handling of pbm_offset.
>           Turn on delayed allocation by default.


From owner-linux-xfs@oss.sgi.com Wed May 10 12:55:24 2000
Received:  by oss.sgi.com id <S305169AbQEJTzF>;
	Wed, 10 May 2000 19:55:05 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:51764 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305168AbQEJTzB>; Wed, 10 May 2000 19:55:01 +0000
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 MAA00384
	for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 12:59:25 -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 MAA03602; Wed, 10 May 2000 12:49:47 -0700 (PDT)
Message-ID: <3919BE06.CC3C76F1@sgi.com>
Date:   Wed, 10 May 2000 12:52:38 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Russell Cattelan <cattelan@thebarn.com>
CC:     Ananth Ananthanarayanan <ananth@dbear.engr.sgi.com>,
        linux-xfs@oss.sgi.com
Subject: Re: TAKE - turn on delayed allocation
References: <200005101926.MAA17364@dbear.engr.sgi.com> <3919BB0C.87D22D9B@thebarn.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

Russell Cattelan wrote:
> 
> Ananth Ananthanarayanan wrote:
> 
> > Since delay_alloc ON and PAGEBUF_META off
> > seems to not hit the corruption problems,
> > I'm turning delay_alloc on by default.
> 
> The corruption problem occurs with PAGEBUF_META off as well
> as on.
> 
> Please don't through more variables in the mix just yet.


Well, it may not have to do with PAGEBUF_META.
The corruption does seem to go away with delay_alloc ON.
I'd like to get as much exposure with delay allocation:
it's been in there for 3 weeks now ... and like I said
earlier the corruption has been there since 3/30/2000
(6 weeks!) at least. We can't stop changing because of
long-standing unresolved issues.


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

From owner-linux-xfs@oss.sgi.com Wed May 10 13:08:24 2000
Received:  by oss.sgi.com id <S305166AbQEJUIF>;
	Wed, 10 May 2000 20:08:05 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:31249 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305165AbQEJUHs>;
	Wed, 10 May 2000 20:07:48 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA05010
	for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 13:02:58 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA98893; Wed, 10 May 2000 15:05:14 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id PAA01858; Wed, 10 May 2000 15:05:13 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.10.1/SGI-client.1.6) via ESMTP id e4AK58o12057; Wed, 10 May 2000 15:05:08 -0500
Message-ID: <3919C0F3.E8F97889@thebarn.com>
Date:   Wed, 10 May 2000 15:05:07 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
CC:     Ananth Ananthanarayanan <ananth@dbear.engr.sgi.com>,
        linux-xfs@oss.sgi.com
Subject: Re: TAKE - turn on delayed allocation
References: <200005101926.MAA17364@dbear.engr.sgi.com> <3919BB0C.87D22D9B@thebarn.com> <3919BE06.CC3C76F1@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

Rajagopal Ananthanarayanan wrote:

> Russell Cattelan wrote:
> >
> > Ananth Ananthanarayanan wrote:
> >
> > > Since delay_alloc ON and PAGEBUF_META off
> > > seems to not hit the corruption problems,
> > > I'm turning delay_alloc on by default.
> >
> > The corruption problem occurs with PAGEBUF_META off as well
> > as on.
> >
> > Please don't through more variables in the mix just yet.
>
> Well, it may not have to do with PAGEBUF_META.
> The corruption does seem to go away with delay_alloc ON.

Can you verify that?
I'm looking at the pagebuf_file_write path ...
delayed alloc short circutes a lot code.... maks me
wonder it the problem isn't someplace within the code that
is then truned off.


>
> I'd like to get as much exposure with delay allocation:
> it's been in there for 3 weeks now ... and like I said
> earlier the corruption has been there since 3/30/2000

I'm not convinced it hasn't always been there.
It takes some strange circumstances to fnd the corruption.
Generally a lot of inode activity  and a lot reads and writes.

>
> (6 weeks!) at least. We can't stop changing because of
> long-standing unresolved issues.
>
> --------------------------------------------------------------------------
> Rajagopal Ananthanarayanan ("ananth")
> Member Technical Staff, SGI.
> --------------------------------------------------------------------------


From owner-linux-xfs@oss.sgi.com Wed May 10 13:17:54 2000
Received:  by oss.sgi.com id <S305168AbQEJURf>;
	Wed, 10 May 2000 20:17:35 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:22839 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305165AbQEJURW>; Wed, 10 May 2000 20:17:22 +0000
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 NAA03723
	for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 13:21:46 -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 NAA03854 for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 13:12:50 -0700 (PDT)
Message-ID: <3919C36D.1B01981A@sgi.com>
Date:   Wed, 10 May 2000 13:15:41 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
Reply-To: linux-xfs@oss.sgi.com
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - turn on delayed allocation
References: <200005101926.MAA17364@dbear.engr.sgi.com> <3919BB0C.87D22D9B@thebarn.com> <3919BE06.CC3C76F1@sgi.com> <3919C0F3.E8F97889@thebarn.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

Russell Cattelan wrote:
> 
> Rajagopal Ananthanarayanan wrote:
> 
> > Russell Cattelan wrote:
> > >
> > > Ananth Ananthanarayanan wrote:
> > >
> > > > Since delay_alloc ON and PAGEBUF_META off
> > > > seems to not hit the corruption problems,
> > > > I'm turning delay_alloc on by default.
> > >
> > > The corruption problem occurs with PAGEBUF_META off as well
> > > as on.
> > >
> > > Please don't through more variables in the mix just yet.
> >
> > Well, it may not have to do with PAGEBUF_META.
> > The corruption does seem to go away with delay_alloc ON.
> 
> Can you verify that?
> I'm looking at the pagebuf_file_write path ...
> delayed alloc short circutes a lot code.... maks me
> wonder it the problem isn't someplace within the code that
> is then truned off.

I know one thing for sure: withe delay_alloc ON
and PAGEBUF_META off I've never seen corruption.

With a 3/30/2000 snap shot (before the days of
delalloc):

	(a) Corruption with PAGEBUF_META ON
        (b) NO corruption with PAGEBUF_META OFF

> 
> >
> > I'd like to get as much exposure with delay allocation:
> > it's been in there for 3 weeks now ... and like I said
> > earlier the corruption has been there since 3/30/2000
> 
> I'm not convinced it hasn't always been there.

No. A 3/30/2000 tree easily produces corruption
with PAGEBUF_META ON.

[ Trimming replies to only TO: linux-xfs;
I get enough mail already ... getting three copies of
the same thing doesn't make it easy ... Thanks! ]


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

From owner-linux-xfs@oss.sgi.com Wed May 10 13:35:54 2000
Received:  by oss.sgi.com id <S305170AbQEJUfp>;
	Wed, 10 May 2000 20:35:45 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:37657 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305165AbQEJUfY>;
	Wed, 10 May 2000 20:35:24 +0000
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 NAA10003
	for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 13:30:35 -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 NAA03873 for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 13:29:38 -0700 (PDT)
Message-ID: <3919C75D.8F4FF8F1@sgi.com>
Date:   Wed, 10 May 2000 13:32:29 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
Reply-To: linux-xfs@oss.sgi.com
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - turn on delayed allocation
References: <200005101926.MAA17364@dbear.engr.sgi.com> <3919BB0C.87D22D9B@thebarn.com> <3919BE06.CC3C76F1@sgi.com> <3919C0F3.E8F97889@thebarn.com> <3919C36D.1B01981A@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



Another symptom I've seen with PAGEBUF_META
turned on is that sometimes the machine freezes hard ...
can't into kdb either when this happens.

I've not seen any hard hangs with PAGEBUF_META off.


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

From owner-linux-xfs@oss.sgi.com Wed May 10 13:42:25 2000
Received:  by oss.sgi.com id <S305172AbQEJUmP>;
	Wed, 10 May 2000 20:42:15 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:15899 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305165AbQEJUmC>;
	Wed, 10 May 2000 20:42:02 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA11015
	for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 13:37:13 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA63632; Wed, 10 May 2000 15:40:18 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id PAA03593; Wed, 10 May 2000 15:40:16 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id PAA60818; Wed, 10 May 2000 15:40:15 -0500 (CDT)
Message-Id: <200005102040.PAA60818@tiki.americas.sgi.com>
Subject: Re: xfs_cmountfs bug
To:     cattelan@thebarn.com (Russell Cattelan)
Date:   Wed, 10 May 2000 15:40:15 -0500 (CDT)
Cc:     phil@linuxcare.com (Phil Schwan),
        dxm@clouds.melbourne.sgi.com (Daniel Moore),
        linux-xfs@oss.sgi.com
In-Reply-To: <3919A199.BE4F151@thebarn.com> from "Russell Cattelan" at May 10, 2000 12:51:21 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

> 
> Phil Schwan wrote:
> 
> > On May 10, Daniel Moore wrote:
> > > Attached is an ugly hack that fixes the problem. I'll leave it up
> > > to someone who knows what's meant to happen to fix it properly.
> > >
> > > (to test: modprobe xfs, lsmod, try to mount a non-mounted, non-xfs
> > > FS as an XFS fs, then lsmod again and check the usage counts - they
> > > should increase for each failed mount)
> > >
> > > dxm@sherman ~/isms/slinx-xfs> p_rdiff linux/fs/xfs/xfs_vfsops.c
> > > 503a504
> > > >         ddevvp=(vnode_t*)1; /* XXX DXM hack */
> > > 505a507
> > > >                 ldevvp=(vnode_t*)1; /* XXX DXM hack */
> > > 508a511
> > > >                 rdevvp=(vnode_t*)1; /* XXX DXM hack */
> >
> > As far as I can tell, the sole purpose of {dd,ld,rd}evvp is to know
> > whether the inodes need freed in the case of an error.  I don't think
> > we need these variables at all.  It's impossible to get to that bit of
> > error cleanup code until after the buftargs are filled--thus, we can
> > just free them under the same conditions that we allocated them.
> >
> > I prefer this patch.  If there's no objections, I'll commit it
> > tomorrow.
> 
> Ted has mad a lot changes to the vnode/ linux inode's
> I might be best to wait until his changes are done
> before we chase the problem to much.

I'm okay with this, am already handling the special linvfs_release_.. case..


	-Ted

From owner-linux-xfs@oss.sgi.com Wed May 10 13:53:25 2000
Received:  by oss.sgi.com id <S305171AbQEJUxP>;
	Wed, 10 May 2000 20:53:15 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:60957 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305165AbQEJUww>;
	Wed, 10 May 2000 20:52:52 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA12697
	for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 13:48:02 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA35133 for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 15:51:35 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id PAA04085 for <linux-xfs@oss.sgi.com>; Wed, 10 May 2000 15:51:34 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.10.1/SGI-client.1.6) via ESMTP id e4AKpTo12420; Wed, 10 May 2000 15:51:29 -0500
Message-ID: <3919CBD1.D460A5B9@thebarn.com>
Date:   Wed, 10 May 2000 15:51:29 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - turn on delayed allocation
References: <200005101926.MAA17364@dbear.engr.sgi.com> <3919BB0C.87D22D9B@thebarn.com> <3919BE06.CC3C76F1@sgi.com> <3919C0F3.E8F97889@thebarn.com> <3919C36D.1B01981A@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

Rajagopal Ananthanarayanan wrote:

> Russell Cattelan wrote:
> >
> > Rajagopal Ananthanarayanan wrote:
> >
> > > Russell Cattelan wrote:
> > > >
> > > > Ananth Ananthanarayanan wrote:
> > > >
> > > > > Since delay_alloc ON and PAGEBUF_META off
> > > > > seems to not hit the corruption problems,
> > > > > I'm turning delay_alloc on by default.
> > > >
> > > > The corruption problem occurs with PAGEBUF_META off as well
> > > > as on.
> > > >
> > > > Please don't through more variables in the mix just yet.
> > >
> > > Well, it may not have to do with PAGEBUF_META.
> > > The corruption does seem to go away with delay_alloc ON.
> >
> > Can you verify that?
> > I'm looking at the pagebuf_file_write path ...
> > delayed alloc short circutes a lot code.... maks me
> > wonder it the problem isn't someplace within the code that
> > is then truned off.
>
> I know one thing for sure: withe delay_alloc ON
> and PAGEBUF_META off I've never seen corruption.

It probably changes the timing enough.

>
>
> With a 3/30/2000 snap shot (before the days of
> delalloc):
>
>         (a) Corruption with PAGEBUF_META ON
>         (b) NO corruption with PAGEBUF_META OFF
>
> >
> > >
> > > I'd like to get as much exposure with delay allocation:
> > > it's been in there for 3 weeks now ... and like I said
> > > earlier the corruption has been there since 3/30/2000
> >
> > I'm not convinced it hasn't always been there.
>
> No. A 3/30/2000 tree easily produces corruption
> with PAGEBUF_META ON.

Page buf meta data had leakage problems at that time, which would
cause other forms of corruption,  hard to say what was causing what at
that point.

Corruption doesn't occur as often with PB META off but
with enough kernel makes running currently; typically 5, corruption
will occur with P B META off.

PB Meta data is probably using  the same broken interface that the
user data path uses, the increased activity would probably cause
the corruption to show up sooner.

What we know for sure at this point; pages are getting re used by
other processes before they are written out to disk. It may have
something to do with the delay write path.... that is just a guess at
this point.


The best way at this point to get corruption:

cd <xfs partition>
mkdir 1 2 3 4 5
foreach i ( 1 2 3 4 5)
rsync -av <xfs source tree> $i/

foreach i ( 1 2 3 4 5)
(cd $i/<xfs source tree> ; make clean depend bzImage modules >& m.out ) &

the m.out files will get corrupted.

the fact that the pages of the m.out files fill slowy, cause the corruption
to show up.

>
>
> [ Trimming replies to only TO: linux-xfs;
> I get enough mail already ... getting three copies of
> the same thing doesn't make it easy ... Thanks! ]
>
> --------------------------------------------------------------------------
> Rajagopal Ananthanarayanan ("ananth")
> Member Technical Staff, SGI.
> --------------------------------------------------------------------------


From owner-linux-xfs@oss.sgi.com Wed May 10 16:49:23 2000
Received:  by oss.sgi.com id <S305160AbQEJXtN>;
	Wed, 10 May 2000 23:49:13 +0000
Received: from rdmc.milliyet.com.tr ([212.58.20.10]:29708 "EHLO convert rfc822-to-8bit
        rdmc.milliyet.com.tr") by oss.sgi.com with ESMTP id <S305154AbQEJXs4>;
	Wed, 10 May 2000 23:48:56 +0000
Received: from dsqio (cranston-ip-2-125.dynamic.ziplink.net [209.206.5.125]) by rdmc.milliyet.com.tr (8.8.8/SCO5) with ESMTP id CAA10547; Thu, 11 May 2000 02:05:36 +0200 (TSI)
Message-Id: <200005110005.CAA10547@rdmc.milliyet.com.tr>
From:   "Darrel Vanski" <r2td@valise.com>
Subject: All Orders
To:     take29d@rdmc.milliyet.com.tr
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date:   Wed, 10 May 2000 19:01:19 -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

              
WE MAKE IT EASY & AFFORDABLE TO ACCEPT CREDIT CARDS FOR YOUR BUSINESS
 
INTERNET (Auction Vendors & Online Mall Stores Too!)
STOREFRONT OR MAIL ORDER MERCHANTS

WE SPECIALIZE IN APPROVING YOU!
 

APPLY TODAY AND START FOR JUST $9.95!

FREE APPLICATION!!
FREE PROGRAMMING!!

DON'T LOSE ANOTHER SALE!

APPLY TO ACCEPT CREDIT CARDS 
AND CALL (888) 264-9272 
 

DON'T FORGET TO ASK ABOUT OUR WEB DESIGN AND HOSTING PACKAGE !!!



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




From owner-linux-xfs@oss.sgi.com Thu May 11 09:09:07 2000
Received:  by oss.sgi.com id <S305166AbQEKQIs>;
	Thu, 11 May 2000 16:08:48 +0000
Received: from [216.208.98.2] ([216.208.98.2]:42229 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305154AbQEKQIc>;
	Thu, 11 May 2000 16:08:32 +0000
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id MAA19936
	for linux-xfs@oss.sgi.com; Thu, 11 May 2000 12:08:12 -0400
Date:   Thu, 11 May 2000 12:08:12 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fixed xfs_cmountfs bug
Message-ID: <20000511120812.B15836@linuxcare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
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.3.99pre2-xfs:slinx:61302a
Date:  Thu May 11 12:08:11 EDT 2000
Author:  nn100003

The following file(s) were checked into:
  bonnie:/isms/slinx/2.3.99pre2-xfs

linux/fs/xfs/xfs_vfsops.c - 1.264
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vfsops.c.diff?r1=text&tr1=1.264&r2=text&tr2=1.263&f=h
	- Fixed Daniel Moore's bug report about not cleaning up in
	  xfs_cmountfs after an error.  Instead of setting local
	  variables to indicate whether the inodes are allocated, free
	  them under the same conditions that they were allocated.

From owner-linux-xfs@oss.sgi.com Thu May 11 11:05:20 2000
Received:  by oss.sgi.com id <S305168AbQEKSFK>;
	Thu, 11 May 2000 18:05:10 +0000
Received: from [216.208.98.2] ([216.208.98.2]:2044 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305154AbQEKSFH>;
	Thu, 11 May 2000 18:05:07 +0000
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id OAA20282
	for linux-xfs@oss.sgi.com; Thu, 11 May 2000 14:04:47 -0400
Date:   Thu, 11 May 2000 14:04:47 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - linvfs_bmap() added for lilo
Message-ID: <20000511140446.C15836@linuxcare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

My changes to make lilo work on xfs FSes.  Had to #include a number of
things, but they're all generic XFS headers, so I don't anticipate
problems.

Modid:  2.3.99pre2-xfs:slinx:61319a
Date:  Thu May 11 14:03:45 EDT 2000
Author:  nn100003

The following file(s) were checked into:
  bonnie:/isms/slinx/2.3.99pre2-xfs

linux/fs/xfs/linux/xfs_iops.c - 1.47
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h
	- Added linvfs_bmap() function for lilo to use


From owner-linux-xfs@oss.sgi.com Thu May 11 18:52:37 2000
Received:  by oss.sgi.com id <S305171AbQELBw2>;
	Fri, 12 May 2000 01:52:28 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:17770 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQELBwP>;
	Fri, 12 May 2000 01:52:15 +0000
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 SAA24756
	for <linux-xfs@oss.sgi.com>; Thu, 11 May 2000 18:47:24 -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 LAA12898; Fri, 12 May 2000 11:49:41 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id LAA89767; Fri, 12 May 2000 11:49:37 +1000 (EST)
Message-Id: <200005120149.LAA89767@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     "Andi Kleen" <ak@suse.de>
cc:     linux-xfs@oss.sgi.com
Subject: Re: race in unmount code. 
In-reply-to: Your message of "Wed, 10 May 2000 10:57:54 +0200."
             <20000510105753.A30364@gruyere.muc.suse.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Fri, 12 May 2000 11:49:37 +1000
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


"Andi Kleen" writes:

 => The vfsmnt stuff is very new in linux -- it was introduced only a few
 => patchlevels before the XFS kernel branched. So it is entirely possible
 => that the generic code is buggy. Maybe this patch will help:
 => 
 => --- linux/fs/super.c-o	Mon Mar 27 20:31:13 2000
 => +++ linux/fs/super.c	Wed May 10 10:58:32 2000
 => @@ -384,6 +384,8 @@
 =>  	if (!buffer) return 0;
 =>  	for (tmp = vfsmntlist; tmp && len < PAGE_SIZE - 160;
 =>  	    tmp = tmp->mnt_next) {
 => +		if (!tmp->mnt_sb || !tmp->mnt_sb->s_root)
 => +			continue;
 =>  		path = d_path(tmp->mnt_sb->s_root, buffer, PAGE_SIZE);
 =>  		if (!path)
 =>  			continue;

Thanks Andi, this does the trick. I just had a look at the
2.3.99-pre5 release and the same patch is in there.

-----------------------------------------------------
 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 Thu May 11 19:25:08 2000
Received:  by oss.sgi.com id <S305172AbQELCY6>;
	Fri, 12 May 2000 02:24:58 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:4470 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQELCYg>;
	Fri, 12 May 2000 02:24:36 +0000
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 TAA00735
	for <linux-xfs@oss.sgi.com>; Thu, 11 May 2000 19:19:45 -0700 (PDT)
	mail_from (ivanr@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA13104 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 12 May 2000 12:23:18 +1000
Received: (from ivanr@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA17764 for linux-xfs@oss.sgi.com; Fri, 12 May 2000 12:23:17 +1000 (EST)
Date:   Fri, 12 May 2000 12:23:17 +1000 (EST)
From:   ivanr@snort.melbourne.sgi.com (Ivan Rayner)
Message-Id: <200005120223.MAA17764@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - add sard patch
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

add sard patch

Modid:  2.3.99pre2-xfs:slinx:61469a
Date:  Thu May 11 19:22:02 PDT 2000
Workarea:  snort:/hosts/bruce/home/ivanr/isms/slinx-xfs-native
Author:  ivanr

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

linux/drivers/block/ll_rw_blk.c - 1.29
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/drivers/block/ll_rw_blk.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h
linux/drivers/scsi/scsi_lib.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/drivers/scsi/scsi_lib.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
linux/fs/block_dev.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/block_dev.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
linux/fs/buffer.c - 1.31
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/buffer.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h
linux/fs/partitions/check.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/partitions/check.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/include/linux/blkdev.h - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/blkdev.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
linux/include/linux/genhd.h - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/genhd.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h

From owner-linux-xfs@oss.sgi.com Thu May 11 19:43:58 2000
Received:  by oss.sgi.com id <S305173AbQELCnk>;
	Fri, 12 May 2000 02:43:40 +0000
Received: from isgood.centertel.pl ([194.9.223.77]:32415 "EHLO convert rfc822-to-8bit
        isgood.centertel.pl") by oss.sgi.com with ESMTP id <S305154AbQELCnM>;
	Fri, 12 May 2000 02:43:12 +0000
Received: from asdhjdjk (cranston-ip-1-223.dynamic.ziplink.net [209.206.4.223])
	by isgood.centertel.pl (8.9.2/8.9.2) with ESMTP id EAA26524;
	Fri, 12 May 2000 04:39:45 +0200 (MET DST)
Message-Id: <200005120239.EAA26524@isgood.centertel.pl>
From:   "Drew Kerry" <r2td@valise.com>
Subject: One...
To:     two202@isgood.centertel.pl
X-Mailer: Mozilla 4.70 [en] (Win95; I)
Mime-Version: 1.0
Date:   Thu, 11 May 2000 21:50:12 -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

FREE E-COMMERCE WHEN YOU HOST WITH US!!
 
Tired of expensive e-commerce software, set up fees and leasing
contracts? Here is the deal: You host your site with us and you get
free E-Commerce, including a merchant account, real-time software and
shopping cart.
 
NO ONE CAN BEAT OUR PRICE! IF YOU FIND A BETTER DEAL FOR OUR PACKAGE
ANYWHERE ELSE, WE WILL MATCH OUR COMPETITOR'S PRICE PLUS GIVE YOU THE
FIRST MONTH FOR FREE. 
 
While others charge you hundreds of dollars to get a merchant account
or put you on a 48 months non-cancelable lease agreement we charge
you NOTHING for E-commerce when you sign up for our e-commerce
hosting plan. If you wish to stay with your current hosting company
or have already a merchant account our offer is even better. We have
7 different E-Commerce plans to suit your individual needs. We have a
solution for U.S. beased merchants and international merchants. No
matter where in the world you are, we get your online store up and
running within a few days.
 
Check it out first and make an informed decision. You have never seen
a package deal like this before:
 
* Your own merchant account with one of the lowest rates in the
industry
* Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS
,
DINERSCLUB/CARTE BLANCHE, JCB
* Direct deposit within 48 hrs into your checking account
* Shopping Cart store front software with an easy to use web based
interface
* Real-Time Credit Card Processing software
* Virtual terminal for phone/fax/mail orders
* Automated E-mail receipts to your clients
* Recurring billing feature with batch uploads
* Automatic batch closing
* Address verification system (AVS)
* Back office to 24/7 access account history
* 75 MB (megabytes) of disk space
* 30 GB (gigabyte) of data transfer per month
* 25 POP3 E-mail accounts
* Unlimited alias E-mail addresses
* Live web site statistics
* Unlimited FTP uploads
* Anonymous FTP
* CGI directory for your own scripts
* Site control panel
* Installation included
* Tech support included
 
All this and more when you sign up for our E-Commerce Hosting plan
for ONLY $69.95 per month and a one time set up fee of $199.00.  That
's right. NO ADDITIONAL SET UP FEES or application fees for your
merchant account, real-time software or shopping cart storefront. A
one-stop E-Commerce solution. And the best is:
 
NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME.
 
In addition you get a FREE listing in our mall and FREE advertising
to promote your store. We drive traffic to your site and help you to
become a successful online business.
 
Please reply to:
 
mailto:ckmm@planetall.com?subject=INFO-PLEASE to receive our FREE e
-mail information package without obligations.
 
*********************************************************
Remove at mailto:ck67p@dbzmail.com?subject=remove
*********************************************************





From owner-linux-xfs@oss.sgi.com Thu May 11 21:59:19 2000
Received:  by oss.sgi.com id <S305174AbQELE7A>;
	Fri, 12 May 2000 04:59:00 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:64059 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQELE6e>;
	Fri, 12 May 2000 04:58:34 +0000
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 VAA03996
	for <linux-xfs@oss.sgi.com>; Thu, 11 May 2000 21:53:41 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA13819 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 12 May 2000 14:55:53 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA01896 for linux-xfs@oss.sgi.com; Fri, 12 May 2000 14:55:51 +1000 (EST)
Date:   Fri, 12 May 2000 14:55:51 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005120455.OAA01896@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix kmallocs of pagebuf_marker_t
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

sizeof took size of pointer, not structure

Modid:  2.3.99pre2-xfs:slinx:61478a
Date:  Thu May 11 21:55:18 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.3.99pre2-xfs

linux/fs/page_buf.c - 1.91
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.91&r2=text&tr2=1.90&f=h
	- fix kmallocs of pagebuf_marker_t


From owner-linux-xfs@oss.sgi.com Fri May 12 05:14:21 2000
Received:  by oss.sgi.com id <S305175AbQELMOB>;
	Fri, 12 May 2000 12:14:01 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:64594 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQELMNg>; Fri, 12 May 2000 12:13:36 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id FAA05043
	for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 05:18:02 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id HAA09325; Fri, 12 May 2000 07:12:15 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id HAA25390; Fri, 12 May 2000 07:11:53 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id HAA29943; Fri, 12 May 2000 07:10:25 -0500 (CDT)
Message-Id: <200005121210.HAA29943@fsgi344.americas.sgi.com>
Subject: Re: TAKE - fix kmallocs of pagebuf_marker_t
To:     dxm@snort.melbourne.sgi.com (Daniel Moore)
Date:   Fri, 12 May 2000 07:10:24 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <200005120455.OAA01896@snort.melbourne.sgi.com> from "Daniel Moore" at May 12, 2000 02:55:51 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


Good find!!!

It certainly seems like this could explain some of the
corruption we have been seeing. Is this how you came to find
it or did you find it with code inspection?

THANKS!

Jim

>
>sizeof took size of pointer, not structure
>
>Modid:  2.3.99pre2-xfs:slinx:61478a
>Date:  Thu May 11 21:55:18 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.3.99pre2-xfs
>
>linux/fs/page_buf.c - 1.91
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/>linux/fs/page_buf.c.diff?r1=text&tr1=1.91&r2=text&tr2=1.90&f=h
>	- fix kmallocs of pagebuf_marker_t
>


From owner-linux-xfs@oss.sgi.com Fri May 12 11:51:10 2000
Received:  by oss.sgi.com id <S305176AbQELSvB>;
	Fri, 12 May 2000 18:51:01 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:55165 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQELSut>; Fri, 12 May 2000 18:50:49 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA09064
	for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 11:55:14 -0700 (PDT)
	mail_from (n8994@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA59760 for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 13:49:32 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id NAA03680 for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 13:49:31 -0500 (CDT)
From:   Russell Cattelan <n8994@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id NAA42742; Fri, 12 May 2000 13:49:30 -0500 (CDT)
Message-Id: <200005121849.NAA42742@nt8.americas.sgi.com>
Date:   Fri, 12 May 2000 13:49:30 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Corruption fix.
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.3.99pre2-xfs:slinx:61503a
Date:  Fri May 12 11:49:04 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs
Author:  cattelan

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

linux/fs/page_buf.c - 1.92
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.92&r2=text&tr2=1.91&f=h
	- Fix for file long outstanding file corruption.
	  Need to set invalid bits on new page returned from grab_cache_page
	  so prepare_file_write will know to read the page from disk 
	  if not on a page boundry.
	  Also turn off delay alloc; it has problems in the same area 
	  and will currently cause file corruption.


From owner-linux-xfs@oss.sgi.com Fri May 12 12:05:30 2000
Received:  by oss.sgi.com id <S305177AbQELTFL>;
	Fri, 12 May 2000 19:05:11 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42367 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQELTEv>; Fri, 12 May 2000 19:04:51 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA04443
	for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 12:09:16 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA60239; Fri, 12 May 2000 14:03:34 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id OAA06284; Fri, 12 May 2000 14:03:32 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id OAA22181; Fri, 12 May 2000 14:03:31 -0500 (CDT)
Message-Id: <200005121903.OAA22181@fsgi344.americas.sgi.com>
Subject: delay alloc broken?
To:     ananth@sgi.com
Date:   Fri, 12 May 2000 14:03:29 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
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


First, we (Russell and I) have fixed a data corruption bug that has
been plauging us for so long. It was a problem in that prepare_write
would sometimes not read a page. There were two coding errors,
	first the valid bits are always true when we allocate
a new page. __pb_block_prepare_write sets the buffer up to date state
if the valid bits are set. This is always done even if the buffer really
isn't up to date.
	second, when at_eof is true during a write, __pb_block_prepare_write()
would never read a page. A page must be read first (before modifying) if
the user's write does not start on the page boundary containing EOF.
Russell just checked this in.

The delay_alloc path is broken in a similar way (I think).

Try running the test:

	bonnie.engr:~mostek/mmap_l.c
	bonnie.engr:~mostek/mmap_l

Run it like:

	mmap_l /tmp/a
	mmap_l /xfs/a

then cmp the two.

With delay_alloc set, we are not correctly zero'ing the parts of
pages which are not written by a user's write.

The problem comes in the same area where Russell and I found a
data corruption bug (in the delwri path).

The bug is that the block_map invalid bits are never set when we calls
grab_cche_page . It returns a page with the block_map all zeros (i.e.
Valid).

__pb_block_prepare_write_async checks early on:

        if (PageBlockAllValid(page)) {
                dprintk(pbpw_debug, ("pbpw: page all valid\n"));
                goto out;
        }

which will always get one to goto out.
We tried fixing this by calling:

	PageBlockSetAllInvalid(page);

right after grab_cache_page but this breaks doio with 5 threads.

Do you want to pick this up?

Jim

From owner-linux-xfs@oss.sgi.com Fri May 12 13:18:41 2000
Received:  by oss.sgi.com id <S305178AbQELUSb>;
	Fri, 12 May 2000 20:18:31 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:45647 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQELUSQ>;
	Fri, 12 May 2000 20:18:16 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA15417
	for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 13:13:25 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA16628 for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 15:15:43 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id PAA17154 for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 15:15:42 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.10.1/SGI-client.1.6) via ESMTP id e4CKFZo07235; Fri, 12 May 2000 15:15:35 -0500
Message-ID: <391C6667.5AAF4A80@thebarn.com>
Date:   Fri, 12 May 2000 15:15:35 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - Corruption fix.
References: <200005121849.NAA42742@nt8.americas.sgi.com> <391C55AE.AA03EBAA@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

Rajagopal Ananthanarayanan wrote:

> Russell Cattelan wrote:
> >
> > Modid:  2.3.99pre2-xfs:slinx:61503a
> > Date:  Fri May 12 11:49:04 PDT 2000
> > Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs
> > Author:  cattelan
> >
> > The following file(s) were checked into:
> >   bonnie.engr.sgi.com:/isms/slinx/2.3.99pre2-xfs
> >
> > linux/fs/page_buf.c - 1.92
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> > linux/fs/page_buf.c.diff?r1=text&tr1=1.92&r2=text&tr2=1.91&f=h
> >         - Fix for file long outstanding file corruption.
> >           Need to set invalid bits on new page returned from grab_cache_page
> >           so prepare_file_write will know to read the page from disk
> >           if not on a page boundry.
> >           Also turn off delay alloc; it has problems in the same area
> >           and will currently cause file corruption.
>
> You may have something here. But grab_page_cache
> can return an existing page .. in which case
> you can't set blocks invalid. That would be
> equivalent to throwing away dirty pages.

yes... in fact I commented about that.
But given the io lock is held and pb_generic_write_file looks at the
hash first, the only time we should be calling grab_cache_page is when
a new pages is needed.

We need to look at what pg_lookup_pages does, and possibly implement
a pb_grab_cache_page.

Also the delay alloc code needs to be looked at since it seems to
looking at the vaild bits wrong. It appears to assume a page is
Valid when is it allocated which is true because we are
never setting it invalid. But the rest of the code works
the otherway around...


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


From owner-linux-xfs@oss.sgi.com Fri May 12 14:39:22 2000
Received:  by oss.sgi.com id <S305179AbQELVjD>;
	Fri, 12 May 2000 21:39:03 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:6248 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQELVif>;
	Fri, 12 May 2000 21:38:35 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA25433
	for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 14:33:45 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA73925 for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 16:37:19 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id QAA26639 for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 16:37:17 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.10.1/SGI-client.1.6) via ESMTP id e4CLbBo07342; Fri, 12 May 2000 16:37:11 -0500
Message-ID: <391C7987.FF7DBD7F@thebarn.com>
Date:   Fri, 12 May 2000 16:37:11 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - Corruption fix.
References: <200005121849.NAA42742@nt8.americas.sgi.com> <391C55AE.AA03EBAA@sgi.com> <391C6667.5AAF4A80@thebarn.com> <391C727D.FF6BE468@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

Rajagopal Ananthanarayanan wrote:

> Russell Cattelan wrote:
> >
> > Rajagopal Ananthanarayanan wrote:
> >
> > > Russell Cattelan wrote:
> > > >
> > > > Modid:  2.3.99pre2-xfs:slinx:61503a
> > > > Date:  Fri May 12 11:49:04 PDT 2000
> > > > Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs
> > > > Author:  cattelan
> > > >
> > > > The following file(s) were checked into:
> > > >   bonnie.engr.sgi.com:/isms/slinx/2.3.99pre2-xfs
> > > >
> > > > linux/fs/page_buf.c - 1.92
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> > > > linux/fs/page_buf.c.diff?r1=text&tr1=1.92&r2=text&tr2=1.91&f=h
> > > >         - Fix for file long outstanding file corruption.
> > > >           Need to set invalid bits on new page returned from grab_cache_page
> > > >           so prepare_file_write will know to read the page from disk
> > > >           if not on a page boundry.
> > > >           Also turn off delay alloc; it has problems in the same area
> > > >           and will currently cause file corruption.
> > >
> > > You may have something here. But grab_page_cache
> > > can return an existing page .. in which case
> > > you can't set blocks invalid. That would be
> > > equivalent to throwing away dirty pages.
> >
> > yes... in fact I commented about that.
> > But given the io lock is held and pb_generic_write_file looks at the
> > hash first, the only time we should be calling grab_cache_page is when
> > a new pages is needed.
> >
> > We need to look at what pg_lookup_pages does, and possibly implement
> > a pb_grab_cache_page.
> >
> > Also the delay alloc code needs to be looked at since it seems to
> > looking at the vaild bits wrong. It appears to assume a page is
> > Valid when is it allocated which is true because we are
> > never setting it invalid. But the rest of the code works
> > the otherway around...
> >
>
> [ Taking this discussion back to slinx-xfs; linux-xfs@oss doesn't
>   deliver messages in time ]
>
> To simplify things, lets deal only with non-delalloc cases.
>
> With the above change & tot tree, I'm still seeing corruption
> with doio running with only 2 threads, and with kernel makes.
> The corruption signatures are the same as its always been.
> doio-2 fails a mmap-write data check. Kernel make is seeing
> source corruption.

Is the source file on disk corrupted or just cached buffer?
in other words if you unmount the file system and remount it is the source file still
corrupted?

I haven't been able to get doio to corrupt... I know jim was running with 5 threads
successfully.

>
>
> Are you running with only 64M of memory?

no



From owner-linux-xfs@oss.sgi.com Fri May 12 15:01:22 2000
Received:  by oss.sgi.com id <S305180AbQELWBD>;
	Fri, 12 May 2000 22:01:03 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:13845 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQELWAv>; Fri, 12 May 2000 22:00:51 +0000
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 PAA03467
	for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 15:05:18 -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 OAA06517 for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 14:56:21 -0700 (PDT)
Message-ID: <391C7EAF.2A101BC5@sgi.com>
Date:   Fri, 12 May 2000 14:59:11 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
Reply-To: linux-xfs@oss.sgi.com
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - Corruption fix.
References: <200005121849.NAA42742@nt8.americas.sgi.com> <391C55AE.AA03EBAA@sgi.com> <391C6667.5AAF4A80@thebarn.com> <391C727D.FF6BE468@sgi.com> <391C7987.FF7DBD7F@thebarn.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

Russell Cattelan wrote:

[ For some reason, you want to communicate thorough
  a slower mailing list. Keeping it on linux-xfs@oss ]

> 
> Is the source file on disk corrupted or just cached buffer?
> in other words if you unmount the file system and remount it is the source file still
> corrupted?

Unmount removes some corruption, but not all of it.

> 
> I haven't been able to get doio to corrupt... I know jim was running with 5 threads
> successfully.
> 
> >
> >
> > Are you running with only 64M of memory?
> 
> no


Why not? I think smaller memory configs reproduce
corruption with greater probability. Can you atleast
verify that you either see or don't see when you switch
to smaller memory size?

From owner-linux-xfs@oss.sgi.com Fri May 12 15:42:24 2000
Received:  by oss.sgi.com id <S305181AbQELWmG>;
	Fri, 12 May 2000 22:42:06 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42264 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQELWli>; Fri, 12 May 2000 22:41:38 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA03390
	for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 15:46:04 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA44144 for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 17:40:22 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id RAA06139 for <linux-xfs@oss.sgi.com>; Fri, 12 May 2000 17:40:21 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.10.1/SGI-client.1.6) via ESMTP id e4CMeEo07536; Fri, 12 May 2000 17:40:14 -0500
Message-ID: <391C884E.8D886F32@thebarn.com>
Date:   Fri, 12 May 2000 17:40:14 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - Corruption fix.
References: <200005121849.NAA42742@nt8.americas.sgi.com> <391C55AE.AA03EBAA@sgi.com> <391C6667.5AAF4A80@thebarn.com> <391C727D.FF6BE468@sgi.com> <391C7987.FF7DBD7F@thebarn.com> <391C7EAF.2A101BC5@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

Rajagopal Ananthanarayanan wrote:

> Russell Cattelan wrote:
>
> [ For some reason, you want to communicate thorough
>   a slower mailing list. Keeping it on linux-xfs@oss ]
>
> >
> > Is the source file on disk corrupted or just cached buffer?
> > in other words if you unmount the file system and remount it is the source file still
> > corrupted?
>
> Unmount removes some corruption, but not all of it.

Hmm ok that's a read path bug then...
Where would that be comming from I wonder?

>
>
> >
> > I haven't been able to get doio to corrupt... I know jim was running with 5 threads
> > successfully.
> >
> > >
> > >
> > > Are you running with only 64M of memory?
> >
> > no
>
> Why not? I think smaller memory configs reproduce
> corruption with greater probability. Can you atleast
> verify that you either see or don't see when you switch
> to smaller memory size?

Just haven't gotten that far yet.

OSS is taking a bit tim right now... we are trying to deply the new box by monday.



From owner-linux-xfs@oss.sgi.com Sun May 14 17:08:10 2000
Received:  by oss.sgi.com id <S305156AbQEOAHu>;
	Mon, 15 May 2000 00:07:50 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:62740 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEOAHY>;
	Mon, 15 May 2000 00:07:24 +0000
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 RAA26847
	for <linux-xfs@oss.sgi.com>; Sun, 14 May 2000 17:02:31 -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 KAA28235 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 15 May 2000 10:06:04 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id KAA01300 for <linux-xfs@oss.sgi.com>; Mon, 15 May 2000 10:06:03 +1000 (EST)
Message-Id: <200005150006.KAA01300@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
Subject: remaining corruption
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 15 May 2000 10:06:02 +1000
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


The fixes over the last couple of days have made the stuff I've been
running here behave a whole heap better. However there's still
corruption occuring.

I have a simple test program that seems to reproducably tickle the 
problem I'm seeing - if someone's interested I can pass it on.

As I suspected from trying to get the kernel build test working, 
previously written pages are getting passed back as newly read pages
(incorrectly). I'm pretty sure this only happens when the written
pages get flushed to disk and it can happen down to single 4k blocks
at a time.

The test case is single threaded and only starts to fail (reliably) when 
it is set to read and write big enough files such that it can't operate 
entirely out of buffered pages.

I've never seen meta data/junk returned - only file data that's probably
still buffered.

-----------------------------------------------------
 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 May 15 09:09:01 2000
Received:  by oss.sgi.com id <S305161AbQEOQIw>;
	Mon, 15 May 2000 16:08:52 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:64773 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEOQIm>; Mon, 15 May 2000 16:08:42 +0000
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 JAA04995
	for <linux-xfs@oss.sgi.com>; Mon, 15 May 2000 09:13:11 -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 JAA09467; Mon, 15 May 2000 09:03:44 -0700 (PDT)
Message-ID: <3920200E.E855C9D8@sgi.com>
Date:   Mon, 15 May 2000 09:04:30 -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:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: remaining corruption
References: <200005150006.KAA01300@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:
> 
> The fixes over the last couple of days have made the stuff I've been
> running here behave a whole heap better. However there's still
> corruption occuring.
> 
> I have a simple test program that seems to reproducably tickle the
> problem I'm seeing - if someone's interested I can pass it on.
> 
> As I suspected from trying to get the kernel build test working,
> previously written pages are getting passed back as newly read pages
> (incorrectly). I'm pretty sure this only happens when the written
> pages get flushed to disk and it can happen down to single 4k blocks
> at a time.
> 
> The test case is single threaded and only starts to fail (reliably) when
> it is set to read and write big enough files such that it can't operate
> entirely out of buffered pages.
> 
> I've never seen meta data/junk returned - only file data that's probably
> still buffered.

My experience with all the latest changes:

(1) Corruption in kernel makes same as before
(2) doio-2 threads corrruption same as before

On Chait's system (booted with 64M) & his kernel:

(3) doio-2 threads corruption same as (2)

Daniel, I'd be interested in your tests. Please send
all the relevant details.

thanks,

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

From owner-linux-xfs@oss.sgi.com Mon May 15 14:21:22 2000
Received:  by oss.sgi.com id <S305162AbQEOVVD>;
	Mon, 15 May 2000 21:21:03 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:14412 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEOVUz>;
	Mon, 15 May 2000 21:20:55 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA00066
	for <linux-xfs@oss.sgi.com>; Mon, 15 May 2000 14:16:04 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA29309; Mon, 15 May 2000 16:19:36 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id QAA12639; Mon, 15 May 2000 16:19:34 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id QAA22105; Mon, 15 May 2000 16:19:32 -0500 (CDT)
Message-Id: <200005152119.QAA22105@fsgi344.americas.sgi.com>
Subject: Re: remaining corruption
To:     ananth@sgi.com (Rajagopal Ananthanarayanan),
        cattelan@thebarn.com (Russell Cattelan)
Date:   Mon, 15 May 2000 16:19:28 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <3920200E.E855C9D8@sgi.com> from "Rajagopal Ananthanarayanan" at May 15, 2000 09:04:30 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


I think it is time to make two changes to get the project more focused:

	1.) remove all non pagebuf meta data code. linux/xfs_fs_bio.c
	2.) remove the delwri data write path.

These were both temporary and since their "real" counterparts are working
most of the time, let's focus on making the real thing work.

Russell, can you remove the non pagebuf meta data code and remove the config option.
Ananth, can you remove the delwri code path and have delay_alloc always on?
This shouldn't be done 'till the test I sent you works (mmap_l). OK?

Thanks,

Jim


>
>Daniel Moore wrote:
>> 
>> The fixes over the last couple of days have made the stuff I've been
>> running here behave a whole heap better. However there's still
>> corruption occuring.
>> 
>> I have a simple test program that seems to reproducably tickle the
>> problem I'm seeing - if someone's interested I can pass it on.
>> 
>> As I suspected from trying to get the kernel build test working,
>> previously written pages are getting passed back as newly read pages
>> (incorrectly). I'm pretty sure this only happens when the written
>> pages get flushed to disk and it can happen down to single 4k blocks
>> at a time.
>> 
>> The test case is single threaded and only starts to fail (reliably) when
>> it is set to read and write big enough files such that it can't operate
>> entirely out of buffered pages.
>> 
>> I've never seen meta data/junk returned - only file data that's probably
>> still buffered.
>
>My experience with all the latest changes:
>
>(1) Corruption in kernel makes same as before
>(2) doio-2 threads corrruption same as before
>
>On Chait's system (booted with 64M) & his kernel:
>
>(3) doio-2 threads corruption same as (2)
>
>Daniel, I'd be interested in your tests. Please send
>all the relevant details.
>
>thanks,
>
>--------------------------------------------------------------------------
>Rajagopal Ananthanarayanan ("ananth")
>Member Technical Staff, SGI.
>--------------------------------------------------------------------------
>


From owner-linux-xfs@oss.sgi.com Mon May 15 16:15:43 2000
Received:  by oss.sgi.com id <S305164AbQEOXPe>;
	Mon, 15 May 2000 23:15:34 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:64632 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEOXP1>;
	Mon, 15 May 2000 23:15:27 +0000
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 QAA16514
	for <linux-xfs@oss.sgi.com>; Mon, 15 May 2000 16:10:37 -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 QAA09894; Mon, 15 May 2000 16:09:04 -0700 (PDT)
Message-ID: <39208434.908DB823@sgi.com>
Date:   Mon, 15 May 2000 16:11:48 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jim Mostek <mostek@sgi.com>
CC:     Russell Cattelan <cattelan@thebarn.com>, linux-xfs@oss.sgi.com
Subject: Re: remaining corruption
References: <200005152119.QAA22105@fsgi344.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

Jim Mostek wrote:
> 
> I think it is time to make two changes to get the project more focused:
> 
>         1.) remove all non pagebuf meta data code. linux/xfs_fs_bio.c
>         2.) remove the delwri data write path.
> 
> These were both temporary and since their "real" counterparts are working
> most of the time, let's focus on making the real thing work.
> 
> Russell, can you remove the non pagebuf meta data code and remove the config option.
> Ananth, can you remove the delwri code path and have delay_alloc always on?
> This shouldn't be done 'till the test I sent you works (mmap_l). OK?
> 


Yes, that sounds good. Although I am trying to debug the doio-2
corruption as currently seen. Note that this problem is near 100%
reproducible with the system I'm using (64M).


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

From owner-linux-xfs@oss.sgi.com Mon May 15 22:12:40 2000
Received:  by oss.sgi.com id <S305156AbQEPFMT>;
	Tue, 16 May 2000 05:12:19 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54603 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQEPFMD>; Tue, 16 May 2000 05:12:03 +0000
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 WAA09952
	for <linux-xfs@oss.sgi.com>; Mon, 15 May 2000 22:16:32 -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 PAA07890 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 16 May 2000 15:10:44 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id PAA07016 for <linux-xfs@oss.sgi.com>; Tue, 16 May 2000 15:10:42 +1000 (EST)
Message-Id: <200005160510.PAA07016@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
Subject: bug related to do with ioctl(XFS_IOC_RESVSP64)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 16 May 2000 15:10:42 +1000
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


on an XFS FS, run "mkfile 1M test" and duck.

so far I've seen:
(running in MIPS mode with pagebuf meta data on)
   a tripped ASSERT in xfs_bmapi

or
(running in native mode (ie it's not an endian issue) 
with pagebuf meta data off)     
   a spew of messages from page_buf saying:
 
May 16 14:59:44 bruce kernel: pbfwa: HOLE ro 0x0 size 0x40000
May 16 14:59:44 bruce kernel: PBFWA: short write written 0 ilen 262144 status 0
May 16 14:59:44 bruce kernel: PBGFWA: short write written 0 ilen 262144 status 
0
May 16 14:59:44 bruce kernel: pbfwa: HOLE ro 0x0 size 0x40000
May 16 14:59:44 bruce kernel: PBFWA: short write written e
May 16 14:59:44 bruce kernel: PBF<4>PBGFWA: short write written 0 ilen 262144 
status 0
May 16 14:59:44 bruce kernel: pbfwa: HOLE ro 0x0 size 0x40000
May 16 14:59:44 bruce kernel: PBFWA: short write written 0 ilen 262144 status 0
May 16 14:59:44 bruce kernel: PBGFWA: short write written 0 ilen 262144 status 
0

mkfile does an ioctl(XFS_IOC_RESVSP64) to reserve space but if the
reserved space is used, things go haywire.

-----------------------------------------------------
 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 May 16 13:47:42 2000
Received:  by oss.sgi.com id <S305169AbQEPUrc>;
	Tue, 16 May 2000 20:47:32 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:21816 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEPUrU>;
	Tue, 16 May 2000 20:47:20 +0000
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 NAA26084
	for <xfs@oss.sgi.com>; Tue, 16 May 2000 13:42:28 -0700 (PDT)
	mail_from (kenmcd@melbourne.sgi.com)
Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA13836; Wed, 17 May 2000 06:44:46 +1000
Received: from localhost (kenmcd@localhost) by rattle.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id GAA77343; Wed, 17 May 2000 06:44:45 +1000 (EST)
Date:   Wed, 17 May 2000 06:44:45 +1000
From:   Ken McDonell <kenmcd@melbourne.sgi.com>
To:     xfs-linux@cthulhu.engr.sgi.com
cc:     xfs@oss.sgi.com
Subject: Endian experiments and a proposal ...
Message-ID: <Pine.SGI.4.10.10005170611160.467342-100000@rattle.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

We've completed much of the endian conversion.  Not yet converted is
log recovery (except in the degenerate clean log case), extended
attributes and quotas.

We've conducted a number of experiments on a range of IA32 systems,
falling into 2 categories:
    (a) small (1p or 2p, 64-128 Mb)
    (b) not small (2p, 1 Gb)

The experimental method involved making a new native (little-endian)
XFS filesystem, running the benchmark until a set of statistically
stable results were produced (this is not strictly possible in some
cases because the benchmarks are so poorly engineered, or their
measurement methodology is so bad) ... then do it all again for a new
MIPS (big-endian) XFS filesystem.

If the test is I/O bound, we compared the user+system CPU times (since
the endian conversions consume CPU time, not I/O time) ... this gives a
pessimistic comparison, as the slow-down (if any) would be less dramatic
if elapsed times were compared.

For CPU-bound tests (yes, many of these so-called "filesystem" tests do
not do much I/O!) we used either elapsed or CPU times, whichever was
more easily available (some tests report throughput which is inversely
proportional to elapsed time for fixed amounts of work).

The tests and analysis are as follows:

1. AIM Suite IX (or at least the FS intensive parts, creat-clo, disk_*,
   link_test, sync_disk_*)

   No significant differences.

2. lmbench (or at least the *delete, *create and mmaplat tests) ... 
   you need to run this one 20+ times to get numbers that are even
   close to useful (others please note ... variance analysis is your
   friend).

   No significant differences.

3. Compiling parts of XFS after make clean.  There were troubles
   getting this to complete, so on the small system the build was confined
   to the user commands (including the sim library), and on the not small
   system the build involved the kernel, modules and XFS user commands.

   1% degradation for the big endian case.

4. find-corruption. A single-threaded test that starts with 50+ files
   with sizes in the range 1 byte to 8+ Mbytes (roughly a logarithmic
   distribution), then treats each file as a chain, chooses a chain at
   random copies the last file on the chain to make a new file on the
   end of the chain ... repeat this 300 times ... compare the last file
   in the chain with the head of the chain ... remove all but the head
   of each chain ... repeat 5 times

   1% degradation for the big endian case.

5. dbench. Abandoned as we could not get close to reproducible numbers.

We have one last test to try and this will be a simulated multi-user
workload for a mail-server.  But I do not expect this to show a
different trend, so we are proposing that ...

  +--------------------------------------------------------------+
  | XFS become the Irix MIPS format, i.e. BIG endian, everywhere |
  +--------------------------------------------------------------+

We've already demonstrated that the Linux big endian format is
interchangeable with Irix by migrating filesystems between an Irix
box and an IA32 Linux box and back again.

Note, when we make the necessary changes in the XFS open source tree to
turn on this as the default and remove the little endian support ...
all existing XFS filesystems on Linux will become unmountable, so
everyone will have to recreate their XFS filesystems ... which is why
we want this to happen as soon as possible.

Feedback welcome.


From owner-linux-xfs@oss.sgi.com Tue May 16 19:31:51 2000
Received:  by oss.sgi.com id <S305162AbQEQCbl>;
	Wed, 17 May 2000 02:31:41 +0000
Received: from logic1.csk.pl ([212.244.171.199]:10502 "EHLO convert rfc822-to-8bit
        logic-home.logic.pl") by oss.sgi.com with ESMTP id <S305154AbQEQCbU>;
	Wed, 17 May 2000 02:31:20 +0000
Received: from host (01-045.044.popsite.net [216.126.163.45])
	by logic-home.logic.pl (8.9.3/8.9.3) with ESMTP id EAA04450;
	Wed, 17 May 2000 04:17:32 +0200
Message-Id: <200005170217.EAA04450@logic-home.logic.pl>
From:   "Scott Angel" <gmn2@bettergolf.net>
Subject: Your Call
To:     it87y@logic-home.logic.pl
X-Mailer: Microsoft Outlook Express 4..72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date:   Tue, 16 May 2000 21:48:34 -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

*Earn $2000 - $5000 weekly-starting within 1-4 weeks
*78% Profit Paid Daily
*No Selling
*No Risk Guarantee
*Work from home, No overhead, or employees.
*High Tech Training & Support
*Not MLM, 100x more profitable
*Multibillion Dollar Travel Industry
 
The most incredible part of our business
is that ALL MY CLIENTS CALL ME!
 
DO YOU QUALIFY FOR OUR MENTOR PROGRAM?
ACCEPTING ONLY 12 NEW ASSOCIATES
 
This is not a hobby!  Serious Inquires Only!!

Please reply with the following information 
NAME:
EMAIL ADDRESS:
PHONE:             (Required)
BEST TIME TO CALL:

TO:

mailto:brin23@bigfoot.com?subject=more_info


///////////////////////////////////////////////////////
If you would like to be removed from our list reply to:
mailto:gmn2@popmail.com?subject=remove
///////////////////////////////////////////////////////






From owner-linux-xfs@oss.sgi.com Tue May 16 22:18:03 2000
Received:  by oss.sgi.com id <S305165AbQEQFRx>;
	Wed, 17 May 2000 05:17:53 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:61968 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEQFRj>;
	Wed, 17 May 2000 05:17:39 +0000
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 WAA11764
	for <linux-xfs@oss.sgi.com>; Tue, 16 May 2000 22:12:47 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA17109 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 17 May 2000 15:16:20 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA27989 for linux-xfs@oss.sgi.com; Wed, 17 May 2000 15:16:20 +1000 (EST)
Date:   Wed, 17 May 2000 15:16:20 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005170516.PAA27989@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix broken prdev
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.3.99pre2-xfs:slinx:61884a
Date:  Tue May 16 22:15:35 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.3.99pre2-xfs

linux/fs/xfs/linux/xfs_random.c - 1.36
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h
	- remove broken prdev function (no way to pass varargs to printk from
	  a function)

linux/fs/xfs/linux/xfs_sim.h - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_sim.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
	- only prototype prdev if it's not a macro

linux/fs/xfs/pseudo-inc/sys/systm.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/systm.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
	- define macro version of prdev to pass args to printk

linux/fs/xfs/xfs_inode.c - 1.284
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.284&r2=text&tr2=1.283&f=h
linux/fs/xfs/xfs_mount.c - 1.220
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.220&r2=text&tr2=1.219&f=h
linux/fs/xfs/xfs_rename.c - 1.23
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_rename.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h
	- %Ld for inode number


From owner-linux-xfs@oss.sgi.com Wed May 17 01:09:44 2000
Received:  by oss.sgi.com id <S305167AbQEQIJY>;
	Wed, 17 May 2000 08:09:24 +0000
Received: from file.phys.tohoku.ac.jp ([130.34.117.125]:8158 "HELO
        file.phys.tohoku.ac.jp") by oss.sgi.com with SMTP
	id <S305154AbQEQII4>; Wed, 17 May 2000 08:08:56 +0000
Received: (qmail 25230 invoked by uid 239); 17 May 2000 08:08:51 -0000
Message-ID: <20000517080851.25229.qmail@file.phys.tohoku.ac.jp>
Date:   17 May 2000 17:08:51 +0900
Date:   Wed, 17 May 2000 17:08:51 +0900
From:   suzukis@file.phys.tohoku.ac.jp
To:     linux-xfs@oss.sgi.com
Subject: please export new symbols ll_rw_blk.c
Mime-Version: 1.0
Content-type: text/plain; charset=ISO-2022-JP
X-Mailer: addmail [version 2.0.12]
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 a bit too late report.

Now drivers/block/ll_rw_blk.c of linux-2.3-xfs has
kiobuf-based I/O request funcstions:
	req_new_io(),
	req_finished_io().

It seems that SCSI driver calls these functions,
but ll_rw_blk.c does not export them.
Thus, when I modularize SCSI driver, scsi_mod.o
includes unresolvable symbol: req_finished_io.

If it's not harmful, I wish if additional EXPORT
of symbols is added to the end of ll_rw_brk.c,
aslike:

#if CONFIG_SCSI == m
EXPORT_SYMBOL(req_new_io);
EXPORT_SYMBOL(req_finished_io);
#endif

Best wishes,

suzuki

From owner-linux-xfs@oss.sgi.com Wed May 17 10:33:08 2000
Received:  by oss.sgi.com id <S305171AbQEQRcs>;
	Wed, 17 May 2000 17:32:48 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:7451 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEQRc3>;
	Wed, 17 May 2000 17:32:29 +0000
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 KAA21342
	for <linux-xfs@oss.sgi.com>; Wed, 17 May 2000 10:27:39 -0700 (PDT)
	mail_from (chait@getafix.engr.sgi.com)
Received: from getafix.engr.sgi.com (getafix.engr.sgi.com [163.154.5.110]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id KAA27093 for <linux-xfs@oss.sgi.com>; Wed, 17 May 2000 10:31:59 -0700 (PDT)
Received: from localhost (chait@localhost) by getafix.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id KAA69298; Wed, 17 May 2000 10:27:51 -0700 (PDT)
Message-Id: <200005171727.KAA69298@getafix.engr.sgi.com>
To:     suzukis@file.phys.tohoku.ac.jp
cc:     linux-xfs@oss.sgi.com
Subject: Re: please export new symbols ll_rw_blk.c 
In-reply-to: Your message of "Wed, 17 May 2000 17:08:51 +0900."
             <20000517080851.25229.qmail@file.phys.tohoku.ac.jp> 
Date:   Wed, 17 May 2000 10:27:50 -0700
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, 17 May 2000 17:08:51 +0900, suzukis@file.phys.tohoku.ac.jp wrote:
>Sorry for a bit too late report.
>
>Now drivers/block/ll_rw_blk.c of linux-2.3-xfs has
>kiobuf-based I/O request funcstions:
>	req_new_io(),
>	req_finished_io().
>
>It seems that SCSI driver calls these functions,
>but ll_rw_blk.c does not export them.
>Thus, when I modularize SCSI driver, scsi_mod.o
>includes unresolvable symbol: req_finished_io.
>
>If it's not harmful, I wish if additional EXPORT
>of symbols is added to the end of ll_rw_brk.c,
>aslike:
>
>#if CONFIG_SCSI == m
>EXPORT_SYMBOL(req_new_io);
>EXPORT_SYMBOL(req_finished_io);
>#endif
>
>Best wishes,
>
>suzuki

How does this integrate with the path thats already there for
doing kiobuf-based I/O requests for scsi devices? See the code
for ll_rw_kio() and __make_kio_request() thats in ll_rw_blk.c.

>From what I understand of the code, the new functions you're
talking about (req_new_io and req_finished_io) enhance the elevator 
timing and disk utilization statistics (general I/O accounting).
They don't actually enable a kiobuf-based request to be passed to 
the scsi mid-layers (i.e. fucntions scsi_lib.c and scsi_merge.c). Am
I right?

Thanks,
-Chait.

From owner-linux-xfs@oss.sgi.com Wed May 17 10:56:09 2000
Received:  by oss.sgi.com id <S305174AbQEQRz7>;
	Wed, 17 May 2000 17:55:59 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:32289 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEQRzq>;
	Wed, 17 May 2000 17:55:46 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA24479
	for <linux-xfs@oss.sgi.com>; Wed, 17 May 2000 10:50:55 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA41098; Wed, 17 May 2000 12:53:11 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id MAA12927; Wed, 17 May 2000 12:53:10 -0500 (CDT)
Received: from thebarn.com by gibble.americas.sgi.com (8.10.1/SGI-client.1.6) via ESMTP id e4HHr9s10500; Wed, 17 May 2000 12:53:09 -0500
Message-ID: <3922DC84.C7E4C15B@thebarn.com>
Date:   Wed, 17 May 2000 12:53:08 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: Upcoming changes ...
References: <3922DB08.FD77148D@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

Rajagopal Ananthanarayanan wrote:

> Heads up on what I'm about to change:
>
> 1. Properly initialize invalid bits when page is allocated.
>    Note that SetAllInvalid is broken ... it sets all 32-bits
>    to 1. A subsequent SetRangeValid will only clear, say 8 bits,
>    corresponding to the 8 valid blocks in a page. Thus, a later
>    check for page validity, such as PageBlockAllValid() which
>    checks for ALL 32 bits to be zero, will not find it so. Chaos.

I'm fixing that rright now.
Basically inverting the bits has show some serious problems
with the way the bits are being used.


>
>
> 2. (1) will enable the fix to delalloc case
>
> 3. (2) will allow delwri to be removed.
>
> All changes to be verified with tests as Jim indicated.
>
> --
> --------------------------------------------------------------------------
> Rajagopal Ananthanarayanan ("ananth")
> Member Technical Staff, SGI.
> --------------------------------------------------------------------------


From owner-linux-xfs@oss.sgi.com Wed May 17 12:18:59 2000
Received:  by oss.sgi.com id <S305175AbQEQTSj>;
	Wed, 17 May 2000 19:18:39 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:45880 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQEQTSV>;
	Wed, 17 May 2000 19:18:21 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA06283
	for <linux-xfs@oss.sgi.com>; Wed, 17 May 2000 12:13:30 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA61747; Wed, 17 May 2000 14:16:53 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id OAA17722; Wed, 17 May 2000 14:16:53 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id OAA07695; Wed, 17 May 2000 14:16:53 -0500 (CDT)
Message-Id: <200005171916.OAA07695@fsgi344.americas.sgi.com>
Subject: Re: Fixed problems running on Cyrix MediaGX..
To:     ian.nelson@echostar.com
Date:   Wed, 17 May 2000 14:16:52 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com (linux-xfs@oss.sgi.com)
In-Reply-To: <39134FFB.CDEF0D96@echostar.com> from "Ian S. Nelson" at May 05, 2000 04:49:32 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


Sorry for the slow response:

The performance of XFS on Linux is not where it should be yet.
We are working on improving the read and write performance numbers
and will have these up when we hit our beta in the next month or two.
We expect to be better than ext2 in some cases and slower in others.
It will depend on the application/data layout/size/...

I'm assuming you were doing standard read/write calls and standard
mmap'ed access. We are about to turn on delay_alloc which will speed
up writing. Also, if you are writing lots of data per file where
the cache gets blown away, we may have direct I/O ready by release. How much
are you reading/writing?

Jim


>
>I ripped out enough of the non-XFS code to get it working on our MediaGX
>machine,  I think it might be that etherboot stuff now and not the
>kernel debugger.  Hopefully Monday or Tuesday I can put some effort in
>to tracking that down.
>
>Now I have another question...
>
>I'm not sure how much of this is secret and how much isn't but the scene
>looks something like this:  We are building an embedded machine that has
>a huge harddrive in it.  Our current requirements are to be able to
>stream 3 streams of data at 2.5 MBytes/sec, to writers and one reader.
>
>With Ext2 we can shoulder that load with our MediaGX.  We have a test
>harness that measures it.  With standard system I/O we can sustain that
>data rate with 13% CPU load.  With mapped I/O we can do it with 9% CPU
>load.  The drive is tricked out with full UDMA.
>
>So I hacked the XFS kernel up so it would run on the MediaGX and the
>numbers were stunning.  With standard I/O it couldn't sustain that data
>rate with our default test settings (we can adjust a few parameters and
>since the 5th and final game of the western conference semis between the
>Detriot DeadWings and the Colorado Avs is on in about an hour I'm going
>to do it another time and not today..)  and it used ~70% CPU load, it
>missed the mark by about 30%.  With mapped I/O it really couldn't
>sustain that data rate and took ~81% CPU load, it took over twice as
>long as it should.
>
>Our test isn't scientific yet, I just hacked a kernel and ran it.  I
>also have tuned anything, but what kinds of performance work is there to
>be done on XFS.  I understand that it's still way ahead of release but
>is there any sort of estimate on how it should performance and what
>kinds of CPU use it should take?  I would expect XFS to outperform Ext2
>in throughput but will that cost a lot of CPU cycles?
>
>thanks, and have a great weekend.
>
>Ian Nelson
>
>


From owner-linux-xfs@oss.sgi.com Wed May 17 20:54:56 2000
Received:  by oss.sgi.com id <S305158AbQERDyf>;
	Thu, 18 May 2000 03:54:35 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:280 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQERDyF>; Thu, 18 May 2000 03:54:05 +0000
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 UAA00939
	for <linux-xfs@oss.sgi.com>; Wed, 17 May 2000 20:58:35 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA27058 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 18 May 2000 13:52:45 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA49779 for linux-xfs@oss.sgi.com; Thu, 18 May 2000 13:52:42 +1000 (EST)
Date:   Thu, 18 May 2000 13:52:42 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005180352.NAA49779@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - super.c bugfix
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

kernel bugfix - fixed in later kernel releases

Modid:  2.3.99pre2-xfs:slinx:62012a
Date:  Wed May 17 20:51:53 PDT 2000
Workarea:  snort:/build1/people/dxm/isms/slinx-xfs-only
Author:  dxm

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

linux/fs/super.c - 1.25
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/super.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h
	- core linux bugfix - fixed in later releases


From owner-linux-xfs@oss.sgi.com Thu May 18 04:03:40 2000
Received:  by oss.sgi.com id <S305159AbQERLDV>;
	Thu, 18 May 2000 11:03:21 +0000
Received: from moutvdom00.kundenserver.de ([195.20.224.149]:36949 "EHLO
        moutvdom00.kundenserver.de") by oss.sgi.com with ESMTP
	id <S305154AbQERLDR>; Thu, 18 May 2000 11:03:17 +0000
Received: from [195.20.224.208] (helo=mrvdom01.kundenserver.de)
	by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2)
	id 12sO5E-0002Fv-00
	for linux-xfs@oss.sgi.com; Thu, 18 May 2000 13:03:16 +0200
Received: from p3ee0146f.dip0.t-ipconnect.de ([62.224.20.111] helo=axxteq.de)
	by mrvdom01.kundenserver.de with esmtp (Exim 2.12 #2)
	id 12sO57-0008LH-00
	for linux-xfs@oss.sgi.com; Thu, 18 May 2000 13:03:09 +0200
Message-ID: <3923CF5A.7CD235DB@axxteq.de>
Date:   Thu, 18 May 2000 13:09:14 +0200
From:   Anes Lihovac <al@axxteq.de>
Organization: Axxteq GmbH
X-Mailer: Mozilla 4.72 [de] (X11; I; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: XFS anf existing Partitions
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

Hello !


I wanted to know if there will be a tool to convert existing Linux ext2
partitions to XFS !


Thank you in advance and best regards
Anes

From owner-linux-xfs@oss.sgi.com Thu May 18 04:24:31 2000
Received:  by oss.sgi.com id <S305176AbQERLYL>;
	Thu, 18 May 2000 11:24:11 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:34147 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305154AbQERLXm>;
	Thu, 18 May 2000 11:23:42 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id EAA06395
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 04:18:50 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id GAA31971; Thu, 18 May 2000 06:22:22 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id GAA24662; Thu, 18 May 2000 06:22:21 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id GAA20913; Thu, 18 May 2000 06:17:25 -0500
Message-Id: <200005181117.GAA20913@jen.americas.sgi.com>
To:     Anes Lihovac <al@axxteq.de>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS anf existing Partitions 
In-reply-to: Your message of "Thu, 18 May 2000 13:09:14 +0200
Date:   Thu, 18 May 2000 06:17:25 -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> Hello !
> 
> 
> I wanted to know if there will be a tool to convert existing Linux ext2
> partitions to XFS !
> 
> 
> Thank you in advance and best regards
> Anes

Someone is working on dump restore, but beyond that, I do not think there will
be a convert in place type operation. The filesystem layouts are so radically
different as to make this an very difficult thing to do. We would need to
start laying down XFS on disk structures whilst there were still ext2
structures on disk.

Steve


From owner-linux-xfs@oss.sgi.com Thu May 18 06:06:20 2000
Received:  by oss.sgi.com id <S305178AbQERNGA>;
	Thu, 18 May 2000 13:06:00 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47658 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305154AbQERNFi>; Thu, 18 May 2000 13:05:38 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA07288
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 06:10:10 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA44191; Thu, 18 May 2000 08:04:19 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id IAA01523; Thu, 18 May 2000 08:04:18 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id IAA09210; Thu, 18 May 2000 08:04:18 -0500 (CDT)
Message-Id: <200005181304.IAA09210@fsgi344.americas.sgi.com>
Subject: Re: XFS anf existing Partitions
To:     lord@sgi.com (Steve Lord)
Date:   Thu, 18 May 2000 08:04:17 -0500 (CDT)
Cc:     al@axxteq.de (Anes Lihovac), linux-xfs@oss.sgi.com
In-Reply-To: <200005181117.GAA20913@jen.americas.sgi.com> from "Steve Lord" at May 18, 2000 06:17:25 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


The easiest and most obvious thing to do is to add a new disk
and make that an XFS file system. Then, copy all the files/directories
over using a tool like tar or cpio. That works today assuming you
don't hit one of the bugs in our code.

Then, unmount the ext2 file system, remount the XFS file system
on the same mount point as the ext2 file system.

Now you have a spare disk which is a back-up to keep around in
the XFS disk goes bad.

Jim

>
>> Hello !
>> 
>> 
>> I wanted to know if there will be a tool to convert existing Linux ext2
>> partitions to XFS !
>> 
>> 
>> Thank you in advance and best regards
>> Anes
>
>Someone is working on dump restore, but beyond that, I do not think there will
>be a convert in place type operation. The filesystem layouts are so radically
>different as to make this an very difficult thing to do. We would need to
>start laying down XFS on disk structures whilst there were still ext2
>structures on disk.
>
>Steve
>


From owner-linux-xfs@oss.sgi.com Thu May 18 06:20:50 2000
Received:  by oss.sgi.com id <S305179AbQERNUb>;
	Thu, 18 May 2000 13:20:31 +0000
Received: from dns.eng.auburn.edu ([131.204.10.13]:45219 "EHLO Eng.Auburn.EDU")
	by oss.sgi.com with ESMTP id <S305154AbQERNUJ>;
	Thu, 18 May 2000 13:20:09 +0000
Received: from eng.auburn.edu (IDENT:carlisle@gink.cse.eng.auburn.edu [131.204.27.2])
	by Eng.Auburn.EDU (8.9.3/8.9.3) with ESMTP id IAA19533
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 08:20:05 -0500 (CDT)
Message-ID: <3923EE04.EF4658D3@eng.auburn.edu>
Date:   Thu, 18 May 2000 08:20:04 -0500
From:   "W.H.Carlisle" <carlisle@Eng.Auburn.EDU>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: compile failure
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

made and booted a kernel....no real problems
then needed the utilities...so

cd linux-2.3pxfs/cmd/xfs
make

and fail off with XFS_MODE undeclared  and can't seem to find any
documentation
regarding this.




From owner-linux-xfs@oss.sgi.com Thu May 18 06:53:31 2000
Received:  by oss.sgi.com id <S305180AbQERNxV>;
	Thu, 18 May 2000 13:53:21 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40750 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305182AbQERNxM>; Thu, 18 May 2000 13:53:12 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA00169
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 06:57:44 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA72628; Thu, 18 May 2000 08:51:48 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id IAA03780; Thu, 18 May 2000 08:51:48 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA23724; Thu, 18 May 2000 08:51:46 -0500
Message-Id: <200005181351.IAA23724@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     "W.H.Carlisle" <carlisle@Eng.Auburn.EDU>
cc:     linux-xfs@oss.sgi.com
Subject: Re: compile failure 
In-Reply-To: Message from "W.H.Carlisle" <carlisle@Eng.Auburn.EDU> 
   of "Thu, 18 May 2000 08:20:04 CDT." <3923EE04.EF4658D3@eng.auburn.edu> 
Date:   Thu, 18 May 2000 08:51:46 -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

> made and booted a kernel....no real problems
> then needed the utilities...so
> 
> cd linux-2.3pxfs/cmd/xfs
> make
> 
> and fail off with XFS_MODE undeclared  and can't seem to find any
> documentation
> regarding this.
> 
> 

The commands use kernel header files, XFS_MODE is defined in fs/xfs/xfs_arch.h
based upon configuration options. Under the filesystems section of kernel
configuration options there are several options for XFS, the supported
architecture field is one of these, you need to pick Native or MIPS.
Also note that unless you turn on experimental kernel options, none of the
xfs options will be available. 

As a side note to this, the initial xfs on linux was not compatible with disks
from Irix systems, the work to do the endian conversion has been on going. We
will shortly be switching over from 'native' to mips format. This will mean
that any filesystems formatted as 'native' on an i386 will become unreadable.

Steve



From owner-linux-xfs@oss.sgi.com Thu May 18 11:07:33 2000
Received:  by oss.sgi.com id <S305192AbQERSHX>;
	Thu, 18 May 2000 18:07:23 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:47437 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305191AbQERSHI>;
	Thu, 18 May 2000 18:07:08 +0000
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 LAA25276
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 11:02:17 -0700 (PDT)
	mail_from (ananth@dbear.engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA98326;
	Thu, 18 May 2000 11:06:42 -0700 (PDT)
	mail_from (ananth@dbear.engr.sgi.com)
Received: (from ananth@localhost)
	by dbear.engr.sgi.com (8.9.3/8.8.7) id LAA15351;
	Thu, 18 May 2000 11:05:05 -0700
Date:   Thu, 18 May 2000 11:05:05 -0700
From:   Ananth Ananthanarayanan <ananth@dbear.engr.sgi.com>
Message-Id: <200005181805.LAA15351@dbear.engr.sgi.com>
Subject: TAKE - fix corruption
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

These fixes are for the the non delalloc case.
Delalloc uses a different prepare_write
(where the following bug was found), so things
were working when delalloc was turned ON.
Still, the mmap_l test hasn't been tested
with delalloc.

More to come: collapse the delwri and delalloc paths.


Modid:  2.3.99pre2-xfs:slinx:62045a
Date:  Thu May 18 11:00:08 PDT 2000
Workarea:  bonnie.engr.sgi.com:/build2/ananth/slinx23-xfs-tot
Author:  ananth

The following file(s) were checked into:
  bonnie:/isms/slinx/2.3.99pre2-xfs

linux/fs/page_buf.c - 1.93
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.93&r2=text&tr2=1.92&f=h
	- Fix a corruption because a NEW allocation over a HOLE was
	  overwriting valid data over the HOLE. Move block_map/invalid
	  bit initialization over to mm/filemap.c ...

linux/fs/xfs/linux/xfs_lrw.c - 1.39
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h
	- Enhance debug code.

linux/mm/filemap.c - 1.37
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/mm/filemap.c.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h
	- Initialize block_map/invalid bits of page as it is
	  being added to the page cache. This may move to rmqueue()
	  to include non-page-cache meta data.


From owner-linux-xfs@oss.sgi.com Thu May 18 11:17:23 2000
Received:  by oss.sgi.com id <S305190AbQERSRO>;
	Thu, 18 May 2000 18:17:14 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:62799 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305188AbQERSQ5>;
	Thu, 18 May 2000 18:16:57 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA26467
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 11:12:03 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA82417 for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 13:14:21 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id NAA18921 for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 13:14:22 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id NAA04125; Thu, 18 May 2000 13:14:21 -0500 (CDT)
Message-Id: <200005181814.NAA04125@tiki.americas.sgi.com>
Date:   Thu, 18 May 2000 13:14:21 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Fix for the XFS_bwrite() routine.
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.3.99pre2-xfs:slinx:62048a
Date:  Thu May 18 11:13:37 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linux2.3-99

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

linux/fs/xfs/xfs_buf.h - 1.50
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_buf.h.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h
	- Fix for the XFS_bwrite() routine.
	  Call xfs_buf_undelay & xfs_trigger_io out of XFS_bwrite.
	  Remove no-longer-necessary printk from xfs_buf_undelay.



From owner-linux-xfs@oss.sgi.com Thu May 18 12:25:43 2000
Received:  by oss.sgi.com id <S305193AbQERTZY>;
	Thu, 18 May 2000 19:25:24 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:21350 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305188AbQERTZB>;
	Thu, 18 May 2000 19:25:01 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA06920
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 12:20:09 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA33867 for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 14:23:42 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id OAA22568 for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 14:23:43 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id OAA08654; Thu, 18 May 2000 14:23:42 -0500 (CDT)
Message-Id: <200005181923.OAA08654@tiki.americas.sgi.com>
Date:   Thu, 18 May 2000 14:23:42 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Add 'shake' routines for kmem_alloc & kmem_zone_alloc.
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.3.99pre2-xfs:slinx:62061a
Date:  Thu May 18 12:22:17 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linux2.3-99

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

linux/kernel/ksyms.c - 1.42
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kernel/ksyms.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h
	- Export 'prune_icache', used by kmem_shake.

linux/fs/xfs/xfs_vfsops.c - 1.266
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vfsops.c.diff?r1=text&tr1=1.266&r2=text&tr2=1.265&f=h
	- Change the 'ktrace' mechanism to use 'zones'.

linux/fs/xfs/pseudo-inc/sys/kmem.h - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/kmem.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
	- Minor cleanup.

linux/fs/xfs/linux/xfs_random.c - 1.37
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h
	- Add 'shake' routines for the kmem_alloc & kmem_zone_alloc
	  interfaces.  Make sure we never return a NULL if KM_SLEEP
	  was set.
	  Change ktrace_alloc/free to use the 'ktrace' zones.



From owner-linux-xfs@oss.sgi.com Thu May 18 13:02:14 2000
Received:  by oss.sgi.com id <S305194AbQERUCF>;
	Thu, 18 May 2000 20:02:05 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:35441 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305188AbQERUBm>;
	Thu, 18 May 2000 20:01:42 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA12348
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 12:56:49 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA44903 for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 15:00:21 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id PAA24492 for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 15:00:22 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id PAA09488; Thu, 18 May 2000 15:00:21 -0500 (CDT)
Message-Id: <200005182000.PAA09488@tiki.americas.sgi.com>
Date:   Thu, 18 May 2000 15:00:21 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Correct compile error when DEBUG is on & VNODE_TRACING is off
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.3.99pre2-xfs:slinx:62065a
Date:  Thu May 18 12:59:28 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linux2.3-99

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

linux/fs/xfs/xfs_vfsops.c - 1.267
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vfsops.c.diff?r1=text&tr1=1.267&r2=text&tr2=1.266&f=h
linux/fs/xfs/linux/xfs_random.c - 1.38
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h
	- Correct compile error when DEBUG is on & VNODE_TRACING is off.



From owner-linux-xfs@oss.sgi.com Thu May 18 13:07:44 2000
Received:  by oss.sgi.com id <S305195AbQERUHZ>;
	Thu, 18 May 2000 20:07:25 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:32627 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305188AbQERUHP>;
	Thu, 18 May 2000 20:07:15 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA13261
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 13:02:22 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA57916 for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 15:05:57 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id PAA24746 for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 15:05:55 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id PAA08273; Thu, 18 May 2000 15:05:55 -0500 (CDT)
Message-Id: <200005182005.PAA08273@tiki.americas.sgi.com>
Date:   Thu, 18 May 2000 15:05:55 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Change 'static' to 'STATIC' for better back-traces in DEBUG mode
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.3.99pre2-xfs:slinx:62067a
Date:  Thu May 18 13:04:50 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linux2.3-99

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

linux/fs/xfs/linux/xfs_fs_bio.c - 1.32
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_fs_bio.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h
linux/fs/xfs/linux/xfs_vfs.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_vfs.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
linux/fs/xfs/linux/xfs_file.c - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_file.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
	- Change 'static' to 'STATIC' for better back-traces in DEBUG mode.



From owner-linux-xfs@oss.sgi.com Thu May 18 15:04:05 2000
Received:  by oss.sgi.com id <S305196AbQERWDp>;
	Thu, 18 May 2000 22:03:45 +0000
Received: from [216.208.98.2] ([216.208.98.2]:24573 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305188AbQERWDS>;
	Thu, 18 May 2000 22:03:18 +0000
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id SAA21573
	for linux-xfs@oss.sgi.com; Thu, 18 May 2000 18:01:57 -0400
Date:   Thu, 18 May 2000 18:01:57 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     linux-xfs@oss.sgi.com
Subject: header dependency patch
Message-ID: <20000518180157.E15745@linuxcare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

While hacking files from scratch, I noticed the huge number of
dependencies that #includes don't resolve for themselves.  Is there
some reason for this, or did it just happen over time?  Does anyone
mind if I apply this patch?  It doesn't fix them all, but it gets the
ones that I've run into so far.

-Phil


===========================================================================
linux/fs/xfs/xfs_attr_sf.h
===========================================================================

--- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_attr_sf.h_1.11	Thu May 18 14:00:40 2000
+++ linux/fs/xfs/xfs_attr_sf.h	Thu May 18 13:00:43 2000
@@ -34,6 +34,9 @@
 
 #ident	"$Revision: 1.11 $"
 
+#include "xfs_types.h"
+#include "xfs_dir_sf.h"
+
 /*
  * xfs_attr_sf.h
  *

===========================================================================
linux/fs/xfs/xfs_bmap_btree.h
===========================================================================

--- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_bmap_btree.h_1.46	Thu May 18 14:00:40 2000
+++ linux/fs/xfs/xfs_bmap_btree.h	Thu May 18 13:01:21 2000
@@ -34,6 +34,7 @@
 
 #ident "$Revision: 1.46 $"
 
+#include "xfs_types.h"
 #include "xfs_buf.h"
 
 #define	XFS_BMAP_MAGIC	0x424d4150	/* 'BMAP' */

===========================================================================
linux/fs/xfs/xfs_dinode.h
===========================================================================

--- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_dinode.h_1.55	Thu May 18 14:00:40 2000
+++ linux/fs/xfs/xfs_dinode.h	Thu May 18 13:00:09 2000
@@ -36,6 +36,12 @@
 
 #ident "$Revision: 1.55 $"
 
+#include <sys/uuid.h>
+#include "xfs_inum.h"
+#include "xfs_bmap_btree.h"
+#include "xfs_attr_sf.h"
+#include "xfs_dir2_sf.h"
+
 struct xfs_buf;
 struct xfs_mount;
 

===========================================================================
linux/fs/xfs/xfs_dir_sf.h
===========================================================================

--- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_dir_sf.h_1.17	Thu May 18 14:00:40 2000
+++ linux/fs/xfs/xfs_dir_sf.h	Thu May 18 13:01:03 2000
@@ -34,6 +34,8 @@
 
 #ident	"$Revision: 1.17 $"
 
+#include "xfs_types.h"
+
 /*
  * xfs_dir_sf.h
  *

===========================================================================
linux/fs/xfs/xfs_mount.h
===========================================================================

--- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_mount.h_1.110	Thu May 18 14:00:40 2000
+++ linux/fs/xfs/xfs_mount.h	Thu May 18 12:58:02 2000
@@ -34,6 +34,11 @@
 
 #ident	"$Revision: 1.110 $"
 
+#include "xfs_sb.h"
+#include "ksys/behavior.h"
+#include "xfs_trans.h"
+#include "xfs_dir.h"
+
 struct cred;
 struct mounta;
 struct vfs;

===========================================================================
linux/fs/xfs/xfs_sb.h
===========================================================================

--- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_sb.h_1.44	Thu May 18 14:00:40 2000
+++ linux/fs/xfs/xfs_sb.h	Thu May 18 12:59:15 2000
@@ -34,6 +34,10 @@
 
 #ident	"$Revision: 1.44 $"
 
+#include <sys/uuid.h>
+#include "xfs_inum.h"
+#include "xfs_dinode.h"
+
 /*
  * Super block
  * Fits into a 512-byte buffer at daddr_t 0 of each allocation group.

===========================================================================
linux/fs/xfs/xfs_trans.h
===========================================================================

--- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_trans.h_1.104	Thu May 18 14:00:40 2000
+++ linux/fs/xfs/xfs_trans.h	Thu May 18 12:58:43 2000
@@ -34,6 +34,8 @@
 
 #ident "$Revision: 1.104 $"
 
+#include "xfs_log.h"
+
 struct xfs_buf;
 struct buftarg;
 struct xfs_efd_log_item;

From owner-linux-xfs@oss.sgi.com Thu May 18 15:17:05 2000
Received:  by oss.sgi.com id <S305197AbQERWQp>;
	Thu, 18 May 2000 22:16:45 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:26729 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305188AbQERWQ1>; Thu, 18 May 2000 22:16:27 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA02381
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 15:21:00 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA05582; Thu, 18 May 2000 17:15:09 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id RAA00855; Thu, 18 May 2000 17:15:09 -0500 (CDT)
Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e4IMF7723813;
	Thu, 18 May 2000 17:15:07 -0500
Message-ID: <39246B6B.23C4278@thebarn.com>
Date:   Thu, 18 May 2000 17:15:07 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Phil Schwan <phil@linuxcare.com>
CC:     linux-xfs@oss.sgi.com, slinx-xfs@engr.sgi.com
Subject: Re: header dependency patch
References: <20000518180157.E15745@linuxcare.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

Phil Schwan wrote:

> While hacking files from scratch, I noticed the huge number of
> dependencies that #includes don't resolve for themselves.  Is there
> some reason for this, or did it just happen over time?  Does anyone
> mind if I apply this patch?  It doesn't fix them all, but it gets the
> ones that I've run into so far.
> \

What does this fix?

xfs_types.h should be in xfs_os_defs.h already.
Which should be included by about everything.

The rest shouldn't really matter, as long as it doesn't break either
one of the build paths.




>
> -Phil
>
> ===========================================================================
> linux/fs/xfs/xfs_attr_sf.h
> ===========================================================================
>
> --- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_attr_sf.h_1.11      Thu May 18 14:00:40 2000
> +++ linux/fs/xfs/xfs_attr_sf.h  Thu May 18 13:00:43 2000
> @@ -34,6 +34,9 @@
>
>  #ident "$Revision: 1.11 $"
>
> +#include "xfs_types.h"
> +#include "xfs_dir_sf.h"
> +
>  /*
>   * xfs_attr_sf.h
>   *
>
> ===========================================================================
> linux/fs/xfs/xfs_bmap_btree.h
> ===========================================================================
>
> --- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_bmap_btree.h_1.46   Thu May 18 14:00:40 2000
> +++ linux/fs/xfs/xfs_bmap_btree.h       Thu May 18 13:01:21 2000
> @@ -34,6 +34,7 @@
>
>  #ident "$Revision: 1.46 $"
>
> +#include "xfs_types.h"
>  #include "xfs_buf.h"
>
>  #define        XFS_BMAP_MAGIC  0x424d4150      /* 'BMAP' */
>
> ===========================================================================
> linux/fs/xfs/xfs_dinode.h
> ===========================================================================
>
> --- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_dinode.h_1.55       Thu May 18 14:00:40 2000
> +++ linux/fs/xfs/xfs_dinode.h   Thu May 18 13:00:09 2000
> @@ -36,6 +36,12 @@
>
>  #ident "$Revision: 1.55 $"
>
> +#include <sys/uuid.h>
> +#include "xfs_inum.h"
> +#include "xfs_bmap_btree.h"
> +#include "xfs_attr_sf.h"
> +#include "xfs_dir2_sf.h"
> +
>  struct xfs_buf;
>  struct xfs_mount;
>
>
> ===========================================================================
> linux/fs/xfs/xfs_dir_sf.h
> ===========================================================================
>
> --- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_dir_sf.h_1.17       Thu May 18 14:00:40 2000
> +++ linux/fs/xfs/xfs_dir_sf.h   Thu May 18 13:01:03 2000
> @@ -34,6 +34,8 @@
>
>  #ident "$Revision: 1.17 $"
>
> +#include "xfs_types.h"
> +
>  /*
>   * xfs_dir_sf.h
>   *
>
> ===========================================================================
> linux/fs/xfs/xfs_mount.h
> ===========================================================================
>
> --- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_mount.h_1.110       Thu May 18 14:00:40 2000
> +++ linux/fs/xfs/xfs_mount.h    Thu May 18 12:58:02 2000
> @@ -34,6 +34,11 @@
>
>  #ident "$Revision: 1.110 $"
>
> +#include "xfs_sb.h"
> +#include "ksys/behavior.h"
> +#include "xfs_trans.h"
> +#include "xfs_dir.h"
> +
>  struct cred;
>  struct mounta;
>  struct vfs;
>
> ===========================================================================
> linux/fs/xfs/xfs_sb.h
> ===========================================================================
>
> --- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_sb.h_1.44   Thu May 18 14:00:40 2000
> +++ linux/fs/xfs/xfs_sb.h       Thu May 18 12:59:15 2000
> @@ -34,6 +34,10 @@
>
>  #ident "$Revision: 1.44 $"
>
> +#include <sys/uuid.h>
> +#include "xfs_inum.h"
> +#include "xfs_dinode.h"
> +
>  /*
>   * Super block
>   * Fits into a 512-byte buffer at daddr_t 0 of each allocation group.
>
> ===========================================================================
> linux/fs/xfs/xfs_trans.h
> ===========================================================================
>
> --- /usr/tmp/TmpDir.6064-0/linux/fs/xfs/xfs_trans.h_1.104       Thu May 18 14:00:40 2000
> +++ linux/fs/xfs/xfs_trans.h    Thu May 18 12:58:43 2000
> @@ -34,6 +34,8 @@
>
>  #ident "$Revision: 1.104 $"
>
> +#include "xfs_log.h"
> +
>  struct xfs_buf;
>  struct buftarg;
>  struct xfs_efd_log_item;


From owner-linux-xfs@oss.sgi.com Thu May 18 15:35:45 2000
Received:  by oss.sgi.com id <S305198AbQERWff>;
	Thu, 18 May 2000 22:35:35 +0000
Received: from [216.208.98.2] ([216.208.98.2]:21230 "EHLO moiraine.off.net")
	by oss.sgi.com with ESMTP id <S305188AbQERWfT>;
	Thu, 18 May 2000 22:35:19 +0000
Received: (from phil@localhost)
	by moiraine.off.net (8.9.3/8.9.3) id SAA21698;
	Thu, 18 May 2000 18:33:48 -0400
Date:   Thu, 18 May 2000 18:33:48 -0400
From:   Phil Schwan <phil@linuxcare.com>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     linux-xfs@oss.sgi.com, slinx-xfs@engr.sgi.com
Subject: Re: header dependency patch
Message-ID: <20000518183348.F15745@linuxcare.com>
References: <20000518180157.E15745@linuxcare.com> <39246B6B.23C4278@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <39246B6B.23C4278@thebarn.com>; from Russell Cattelan on Thu, May 18, 2000 at 05:15:07PM -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 May 18, Russell Cattelan wrote:
> Phil Schwan wrote:
> 
> > While hacking files from scratch, I noticed the huge number of
> > dependencies that #includes don't resolve for themselves.  Is there
> > some reason for this, or did it just happen over time?  Does anyone
> > mind if I apply this patch?  It doesn't fix them all, but it gets the
> > ones that I've run into so far.
> 
> What does this fix?

It fixes insane scenarios like this, which was previously in dump.h:

#  include <sys/uuid.h>        /* resolve xfs_dinode and xfs_sb deps */
#  include "xfs_inum.h"        /* resolve xfs_dinode and xfs_sb deps */
#   include "xfs_types.h"      /* resolve xfs_attr_sf, xfs_bmap_btree, and xfs_dir_sf deps */
#    include "xfs_buf.h"       /* resolve xfs_bmap_btree dep */
#   include "xfs_bmap_btree.h" /* resolve xfs_dinode dep */
#    include "xfs_dir_sf.h"    /* resolve xfs_attr_sf dep */
#   include "xfs_attr_sf.h"    /* resolve xfs_dinode dep */
#   include "xfs_dir2_sf.h"    /* resolve xfs_dinode dep */
#  include "xfs_dinode.h"      /* resolve xfs_sb dep */
# include "xfs_sb.h"           /* resolve xfs_mount dep */
# include "ksys/behavior.h"    /* resolve xfs_mount dep */
#  include "xfs_log.h"         /* resolve xfs_trans dep */
# include "xfs_trans.h"        /* resolve xfs_mount dep */
# include "xfs_dir.h"          /* resolve xfs_mount dep */
#include "xfs_mount.h"         /* for xfs_mount_t */

> The rest shouldn't really matter, as long as it doesn't break either
> one of the build paths.

By this do you mean the module and non-module build path, or the
native and non-native build path, or the delalloc and non-delalloc
build path...?

-Phil

From owner-linux-xfs@oss.sgi.com Thu May 18 15:45:34 2000
Received:  by oss.sgi.com id <S305199AbQERWpZ>;
	Thu, 18 May 2000 22:45:25 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:36716 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305188AbQERWpG>; Thu, 18 May 2000 22:45:06 +0000
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA02023
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 15:49:34 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA35954; Thu, 18 May 2000 17:43:43 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id RAA01644; Thu, 18 May 2000 17:43:43 -0500 (CDT)
Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e4IMhf727121;
	Thu, 18 May 2000 17:43:41 -0500
Message-ID: <3924721D.6DC4B1A5@thebarn.com>
Date:   Thu, 18 May 2000 17:43:41 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Phil Schwan <phil@linuxcare.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: header dependency patch
References: <20000518180157.E15745@linuxcare.com> <39246B6B.23C4278@thebarn.com> <20000518183348.F15745@linuxcare.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

Phil Schwan wrote:

> On May 18, Russell Cattelan wrote:
> > Phil Schwan wrote:
> >
> > > While hacking files from scratch, I noticed the huge number of
> > > dependencies that #includes don't resolve for themselves.  Is there
> > > some reason for this, or did it just happen over time?  Does anyone
> > > mind if I apply this patch?  It doesn't fix them all, but it gets the
> > > ones that I've run into so far.
> >
> > What does this fix?
>
> It fixes insane scenarios like this, which was previously in dump.h:
>
> #  include <sys/uuid.h>        /* resolve xfs_dinode and xfs_sb deps */
> #  include "xfs_inum.h"        /* resolve xfs_dinode and xfs_sb deps */
> #   include "xfs_types.h"      /* resolve xfs_attr_sf, xfs_bmap_btree, and xfs_dir_sf deps */
> #    include "xfs_buf.h"       /* resolve xfs_bmap_btree dep */
> #   include "xfs_bmap_btree.h" /* resolve xfs_dinode dep */
> #    include "xfs_dir_sf.h"    /* resolve xfs_attr_sf dep */
> #   include "xfs_attr_sf.h"    /* resolve xfs_dinode dep */
> #   include "xfs_dir2_sf.h"    /* resolve xfs_dinode dep */
> #  include "xfs_dinode.h"      /* resolve xfs_sb dep */
> # include "xfs_sb.h"           /* resolve xfs_mount dep */
> # include "ksys/behavior.h"    /* resolve xfs_mount dep */
> #  include "xfs_log.h"         /* resolve xfs_trans dep */
> # include "xfs_trans.h"        /* resolve xfs_mount dep */
> # include "xfs_dir.h"          /* resolve xfs_mount dep */
> #include "xfs_mount.h"         /* for xfs_mount_t */
>
> > The rest shouldn't really matter, as long as it doesn't break either
> > one of the build paths.
>
> By this do you mean the module and non-module build path, or the
> native and non-native build path, or the delalloc and non-delalloc
> build path...?

pagebuf_meta_data on and off.

if thinks look like they should go in xfs_os_defs.h do that


>
>
> -Phil


From owner-linux-xfs@oss.sgi.com Thu May 18 17:53:16 2000
Received:  by oss.sgi.com id <S305201AbQESAxF>;
	Fri, 19 May 2000 00:53:05 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:22903 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305200AbQESAwu>; Fri, 19 May 2000 00:52:50 +0000
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 RAA03339
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 17:57:14 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA05601 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 19 May 2000 10:51:21 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA61824 for linux-xfs@oss.sgi.com; Fri, 19 May 2000 10:51:17 +1000 (EST)
Date:   Fri, 19 May 2000 10:51:17 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005190051.KAA61824@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - tiny validation on read failure bugfix
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.3.99pre2-xfs:slinx:62137a
Date:  Thu May 18 17:50:46 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.3.99pre2-xfs

linux/fs/page_buf.c - 1.94
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.94&r2=text&tr2=1.93&f=h
	- fix page validation on read failure


From owner-linux-xfs@oss.sgi.com Thu May 18 19:03:19 2000
Received:  by oss.sgi.com id <S305209AbQESCDA>;
	Fri, 19 May 2000 02:03:00 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:13389 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305205AbQESCCw>;
	Fri, 19 May 2000 02:02:52 +0000
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 SAA26527
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 18:57:54 -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 MAA06591 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 19 May 2000 12:01:26 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id MAA24637 for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 12:01:25 +1000 (EST)
Message-Id: <200005190201.MAA24637@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
Subject: Intel -> MIPS switcheroo
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Fri, 19 May 2000 12:01:25 +1000
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


We have reached a point in the architecture conversion work
where we are satisfied with both the performance and stability
of linux XFS in MIPS compatible mode.

The proposal has been made that we should shortly adopt the
'XFS is big-endian' approach and make MIPS compatible mode
the only available mode.

This change involves not just changing the default mode, but
removing multiple architecture support and a large amount of
simplification that can go with that.

The first stage of that process is basically ready to go ahead.
It's a pretty hefty commit, touching every file that the
architecture work has touched so far and removing support for
all existing intel-xfs filesystems.

Our proposal is to go ahead with this on our Monday.

If anyone has any objections to this idea, please let me know.
We can certainly change the timing to work around people who
are hunting corruption/getting ready to do other big commits
etc...

** this change will remove support for your existing XFS FSes  **

** some userland tools will be broken (not mkfs_xfs or xfs_db) **

PS:

You might like to try switching to MIPS mode, rebuilding your
kernel, tools and XFS filesystems and trying the tests you're 
using now to see how this will impact you.

-----------------------------------------------------
 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 Thu May 18 21:05:09 2000
Received:  by oss.sgi.com id <S305200AbQESEEv>;
	Fri, 19 May 2000 04:04:51 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:27263 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305164AbQESEEd>; Fri, 19 May 2000 04:04:33 +0000
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA01123
	for <linux-xfs@oss.sgi.com>; Thu, 18 May 2000 21:09:06 -0700 (PDT)
	mail_from (owner-slinx-xfs@cthulhu.engr.sgi.com)
Received: (from majordomo-owner@localhost)
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	id VAA79654;
	Thu, 18 May 2000 21:04:11 -0700 (PDT)
	mail_from (owner-slinx-xfs@relay.engr.sgi.com)
Date:   Thu, 18 May 2000 21:04:11 -0700 (PDT)
Message-Id: <200005190404.VAA79654@cthulhu.engr.sgi.com>
To:     linux-xfs@oss.sgi.com
From:   Majordomo@cthulhu.engr.sgi.com
Subject: Welcome to slinx-xfs
Reply-To: Majordomo@cthulhu.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

--

Welcome to the slinx-xfs mailing list!

Please save this message for future reference.  Thank you.

If you ever want to remove yourself from this mailing list,
send the following command in email to
<slinx-xfs-request@relay.engr.sgi.com>:

    unsubscribe

Or you can send mail to <Majordomo@relay.engr.sgi.com> with the following
command in the body of your email message:

    unsubscribe slinx-xfs

or from another account, besides linux-xfs@oss.sgi.com:

    unsubscribe slinx-xfs linux-xfs@oss.sgi.com

If you ever need to get in contact with the owner of the list,
(if you have trouble unsubscribing, or have questions about the
list itself) send email to <owner-slinx-xfs@relay.engr.sgi.com> .
This is the general rule for most mailing lists when you need
to contact a human.

 Here's the general information for the list you've subscribed to,
 in case you don't already have it:

[Last updated on: Mon Aug  2 19:30:00 PDT 1999]
The slinx-xfs list is for discussion of development issues in regard
to XFS on Linux. It includes developers both inside and outside SGI.

From owner-linux-xfs@oss.sgi.com Fri May 19 07:11:35 2000
Received:  by oss.sgi.com id <S305156AbQESOLZ>;
	Fri, 19 May 2000 14:11:25 +0000
Received: from deliverator.sgi.com ([204.94.214.10]:44614 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S305155AbQESOLQ>;
	Fri, 19 May 2000 14:11:16 +0000
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 HAA27344
	for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 07:01:44 -0700 (PDT)
	mail_from (owner-slinx-xfs@cthulhu.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 HAA57743 for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 07:03:36 -0700 (PDT)
Received: (from majordomo-owner@localhost)
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	id HAA56043
	for slinx-xfs-list;
	Fri, 19 May 2000 07:01:14 -0700 (PDT)
	mail_from (owner-slinx-xfs@relay.engr.sgi.com)
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA53413;
	Fri, 19 May 2000 07:01:07 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA27641; Fri, 19 May 2000 09:00:53 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id JAA15923; Fri, 19 May 2000 09:00:50 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id JAA02815; Fri, 19 May 2000 09:00:38 -0500
Message-Id: <200005191400.JAA02815@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     slinx-xfs@cthulhu.engr.sgi.com
Subject: Re: xfs_lock_dir_and_entry problem 
In-Reply-To: Message from Rajagopal Ananthanarayanan <ananth@sgi.com> 
   of "Thu, 18 May 2000 18:39:07 PDT." <39249B3B.A60E7494@sgi.com> 
Date:   Fri, 19 May 2000 09:00:37 -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 think we need a better implementation of delay than this:

void
delay(long ticks)
{
  unsigned long timeout = jiffies + ((ticks * HZ) / 1000);
  while (jiffies < timeout);
}

Say this:

void
delay(long ticks)
{
        current->state = TASK_INTERRUPTIBLE; /* Probably should be
					        uninterruptable */
        schedule_timeout(ticks);
}


We need to get off the cpu - this might fix things - since we would
drop the kernel lock in the process. 

And now back to cxfs.......

Steve


> 
> while running dbench on a tot kernel with delalloc ON,
> I'm seeing that one of the processes gets stuck as follows:
> 
> ------------
> [1]kdb> bt
>     EBP       EIP         Function(args)
> 0xc1a9bd94 0xc48515c6  xfs_iunlock+0x56( 0xc36bf2e8, 0x4, 0x0, 0xc3e05000, 0x
c36bf2e8 )
> 0xc1a9bdf0 0xc486e7d5  xfs_lock_dir_and_entry+0x101( 0xc36bf2e8, 0xc3882f20, 
0xc06387d8, 0x23,
> 0xc1a9be5c )
> 0xc1a9be74 0xc486ecb9  xfs_remove+0x261( 0xc36bf300, 0xc3882f20, 0xc1a9be98, 
0xffffffff,
> 0xc3179e40 )
> 0xc1a9bf54 0xc4876bf5  linvfs_unlink+0x41( 0xc3179e40, 0xc3882ec0, 0xc33dd700
, 0xfffffffe, 0x0 )
> 0xc1a9bf78 0xc0155aeb  vfs_unlink+0x12b( 0xc3179e40, 0xc3882ec0, 0xc1a9a000, 
0xc1997000, 0x0 )
> 0xc1a9bf98 0xc0155bcf  do_unlink+0x97( 0xc1997000, 0x0, 0xc1a9a000, 0xbffff85
e, 0x804a0b1 )
> 0xc1a9bfbc 0xc0155cc7  sys_unlink+0x8b( 0xbffffc54, 0xbffffc7c, 0xbffffc54, 0
xbffff85e,
> 0x804a0b1 )
> 0xc1a9bfd8 0xc010a538  system_call+0x34
> -------------------
> 
> Apparently, the xfs_lock_dir_and_entry() keeps doing the "again:"
> loop ... down in the stack, sys_unlink took the kernel lock
> and the process is still hanging on to that. On another cpu,
> a thread active in XFS code is spinning while trying to get the
> kernel lock. It's trace is as follows:
> 
> ----------------
> [0]kdb> bt
>     EBP       EIP         Function(args)
> 0xc1a57988 0xc0209265  kdb_bt: confused
> stext_lock+0x711( 0xc0369778, 0xc0368e90, 0xc3df1aa0, 0xc0368e90, 0xc1a579d8 
)
> 0xc1a579e0 0xc01b42db  __get_request_wait+0x297( 0xaa, 0x811, 0xc3df1aa0, 0x5
, 0xc3df1aa0 )
> 0xc1a57a38 0xc01b4fbc  generic_make_request+0x728( 0xc11ff3a4, 0x5, 0xc3df1aa
0, 0x811,
> 0xc3df1ae8 )
> 0xc1a57a58 0xc01b4889  make_request+0x1d( 0x8, 0x5, 0xc3df1aa0, 0x401f6e, 0xc
10adc40 )
> 0xc1a57ab0 0xc0140ef8  _pagebuf_page_io+0x328( 0xc10adc40, 0xc22f51e0, 0x401f
6f, 0x811, 0xe00 )
> 0xc1a57af8 0xc0141062  _page_buf_page_apply+0x112( 0x0, 0xc22f51e0, 0x0, 0x0,
 0xc10adc40 )
> 0xc1a57b48 0xc0141c2c  pagebuf_segment_apply+0xfc( 0xc0140f50, 0x0, 0xc22f51e
0, 0x0, 0x0 )
> 0xc1a57bac 0xc01414ac  pagebuf_iorequest+0x43c( 0xc22f51e0, 0xc11b14e4, 0xc11
b14a0, 0xc22c0000 )
> 0xc1a57bd4 0xc4858a2c  xlog_sync+0x120( 0xc11b14a0, 0xc22c0000, 0x0, 0xc22c00
00, 0xc11b14e4 )
> 0xc1a57c00 0xc485a969  xlog_state_release_iclog+0x155( 0xc11b14a0, 0xc22c0000
, 0xc11b14a0, 0x3,
> 0xc1481b20 )
> 0xc1a57c24 0xc485aeb2  xlog_state_sync+0x1ea( 0xc11b14a0, 0x34, 0x248e, 0x3, 
0xc3e05000 )
> 0xc1a57c44 0xc4857739  xfs_log_force+0x49( 0xc3e05000, 0x34, 0x248e, 0x3, 0x2
 )
> 0xc1a57d04 0xc4866d05  xfs_trans_commit+0x315( 0xc1481328, 0x0, 0x0, 0xc14813
28, 0xffffffff )
> 0xc1a57d38 0xc4834534  xfs_bmap_finish+0x8c( 0xc1a57e08, 0xc1a57da4, 0xffffff
ff, 0xffffffff,
> 0xc1a57d94 )
> 0xc1a57db0 0xc4852f19  xfs_itruncate_finish+0x211( 0xc1a57e08, 0xc215a7d8, 0x
0, 0x0, 0x0 )
> 0xc1a57e0c 0xc486d87c  xfs_inactive+0x210( 0xc215a7f0, 0x0, 0xc2a332fc, 0xc48
8c8e0, 0xc292ce40 )
> 0xc1a57e3c 0xc48801a1  vn_rele+0xed( 0xc2a332fc, 0xc30ded00, 0xc1a57e68, 0xc0
15e5e8 )
> 0xc1a57e4c 0xc487d117  linvfs_put_inode+0x17( 0xc30ded00, 0xc3882540, 0xc30de
d00, 0xc292ce40 )
> 0xc1a57e68 0xc015e5e8  iput+0x38( 0xc30ded00, 0x0, 0xc30ded00, 0xc1a57f54 )
> 0xc1a57e7c 0xc015c68d  d_delete+0x49( 0xc3882540, 0xffffffff, 0xc292ce40, 0xc
292ced8 )
> 0xc1a57f54 0xc4876c2f  linvfs_unlink+0x7b( 0xc292ce40, 0xc3882540, 0xc33dde80
, 0xfffffffe, 0x0 )
> 0xc1a57f78 0xc0155aeb  vfs_unlink+0x12b( 0xc292ce40, 0xc3882540, 0xc1a56000, 
0xc1907000, 0x0 )
> [0]more> 
> 0xc1a57f98 0xc0155bcf  do_unlink+0x97( 0xc1907000, 0x0, 0xc1a56000, 0xbffff85
e, 0x804a0b1 )
> 0xc1a57fbc 0xc0155cc7  sys_unlink+0x8b( 0xbffffc54, 0xbffffc7d, 0xbffffc54, 0
xbffff85e,
> 0x804a0b1 )
> 0xc1a57fd8 0xc010a538  system_call+0x34
> -----------------
> 
> Basically, while doing a make_request as part of pagebuf_page_io,
> it ran out of request structures, went to sleep, now has the
> request structure ... and is trying to reacquire the kernel lock
> which it originally aquired (also) in sys_unlink.
> 
> In the meantime, the page-cleaner daemon is trying to convert
> a delalloc extent. Its backtrace is as follows:
> 
> ------------
> [0]kdb> btp 560
>     EBP       EIP         Function(args)
> 0xc22e76f4 0xc0118304  schedule+0x4b4( 0xc22f5860, 0xc22f5880, 0xc22f5880, 0x
c22f5878,
> 0xc22e7744 )
> 0xc22e774c 0xc0107def  __down+0x257( 0xc22f5860, 0xc1160000, 0xc22f5800 )
> 0xc22e7760 0xc0108487  __down_failed+0xb( 0x1ff, 0xbff04200, 0xc2656740, 0xc4
825eb9, 0xc148147c
> )
> 0xc22e780c 0xc020a7db  _pagebuf_get_lockable_buffer+0x38e( 0xc2656740, 0xc267
6000, 0xbff04200,
> 0x0, 0x200 )
> 0xc22e7844 0xc013f734  pagebuf_get+0xc0( 0xc2656740, 0xbff04200, 0x0, 0x200, 
0x2005 )
> 0xc22e7870 0xc48681e6  xfs_trans_read_buf+0x1be( 0xc3e05000, 0xc14811d4, 0xc3
e05188, 0x5ff821,
> 0x0 )
> 0xc22e78bc 0xc4825ff8  xfs_alloc_read_agf+0x54( 0xc3e05000, 0xc14811d4, 0x6, 
0x1, 0xc22e7900 )
> 0xc22e7954 0xc4825ba3  xfs_alloc_fix_freelist+0x133( 0xc22e7b44, 0x1, 0xc3e05
1fc, 0x1, 0xa )
> 0xc22e79a8 0xc48263c1  xfs_alloc_vextent+0x305( 0xc22e7b44, 0x1, 0x16, 0xc3e0
5000 )
> 0xc22e7b94 0xc4832616  xfs_bmap_alloc+0x1c42( 0xc22e7c9c, 0x9, 0xc0638950, 0x
c3e0500c )
> 0xc22e7ce8 0xc4835430  xfs_bmapi+0x690( 0xc14811d4, 0xc06387d8, 0x9, 0x0, 0x1
 )
> 0xc22e7e04 0xc487b0a2  xfs_iomap_write_convert+0x33e( 0xc0638950, 0x9000, 0x0
, 0x1000,
> 0xc22e7fac )
> 0xc22e7ed0 0xc487a0fe  xfs_iomap_write+0x10e( 0xc0638950, 0x9000, 0x0, 0x1000
, 0xc22e7fac )
> 0xc22e7f10 0xc4879b66  xfs_bmap+0xfe( 0xc06387f0, 0x9000, 0x0, 0x1000, 0x1001
0002 )
> 0xc22e7f58 0xc487741d  linvfs_pb_bmap+0x79( 0xc0c7bd80, 0x9000, 0x0, 0x1000, 
0xc22e7fac )
> 0xc22e7fc0 0xc0145b27  pb_delalloc_convert+0xa3( 0xc1034610, 0xc22e7fea, 0x10
000000, 0x100,
> 0xc2691c50 )
> 0xc22e7fec 0xc0145f6f  page_cleaner_daemon+0x29b
> 0xc2691c58 0xc0107603  kernel_thread+0x23
> ------------------
> 
> 
> Ted, do you think the stuff you're working on has anything to do with this?
> 
> 
> -- 
> --------------------------------------------------------------------------
> Rajagopal Ananthanarayanan ("ananth")
> Member Technical Staff, SGI.
> --------------------------------------------------------------------------



From owner-linux-xfs@oss.sgi.com Fri May 19 10:15:55 2000
Received:  by oss.sgi.com id <S305163AbQESRPq>;
	Fri, 19 May 2000 17:15:46 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:9281 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305155AbQESRPm>; Fri, 19 May 2000 17:15:42 +0000
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA05163
	for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 10:20:15 -0700 (PDT)
	mail_from (ananth@dbear.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 KAA97471 for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 10:13:55 -0700 (PDT)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA95340
	for <linux-xfs@oss.sgi.com>;
	Fri, 19 May 2000 10:13:35 -0700 (PDT)
	mail_from (ananth@dbear.engr.sgi.com)
Received: (from ananth@localhost)
	by dbear.engr.sgi.com (8.9.3/8.8.7) id KAA20500
	for linux-xfs@oss.sgi.com; Fri, 19 May 2000 10:11:57 -0700
Date:   Fri, 19 May 2000 10:11:57 -0700
From:   Ananth Ananthanarayanan <ananth@dbear.engr.sgi.com>
Message-Id: <200005191711.KAA20500@dbear.engr.sgi.com>
Subject: TAKE - couple of delalloc changes
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


Pick up changes from Steve for handling flush on delalloc.

Delalloc is still turned off by default.

However, PLEASE TURN IT ON for testing purposes.
This will enable us to find bugs before
the switch from delwri -> delalloc is thrown
for good.



Modid:  2.3.99pre2-xfs:slinx:62229a
Date:  Fri May 19 10:10:18 PDT 2000
Workarea:  bonnie.engr.sgi.com:/build2/ananth/slinx23-xfs-tot
Author:  ananth

The following file(s) were checked into:
  bonnie:/isms/slinx/2.3.99pre2-xfs

linux/fs/page_buf.c - 1.95
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.95&r2=text&tr2=1.94&f=h
	- Fix flush code to convert delalloc extents. Attempt at handling
	  unwritten extents, also under delalloc. Use STATIC for better debugging.


From owner-linux-xfs@oss.sgi.com Fri May 19 10:21:55 2000
Received:  by oss.sgi.com id <S305166AbQESRVq>;
	Fri, 19 May 2000 17:21:46 +0000
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2370 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S305155AbQESRVe>; Fri, 19 May 2000 17:21:34 +0000
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA08425
	for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 10:26:04 -0700 (PDT)
	mail_from (owner-slinx-xfs@cthulhu.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 KAA98074 for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 10:19:45 -0700 (PDT)
Received: (from majordomo-owner@localhost)
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	id KAA04687
	for slinx-xfs-list;
	Fri, 19 May 2000 10:18:36 -0700 (PDT)
	mail_from (owner-slinx-xfs@relay.engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA14931
	for <slinx-xfs@cthulhu.engr.sgi.com>;
	Fri, 19 May 2000 10:18:35 -0700 (PDT)
	mail_from (ananth@dbear.engr.sgi.com)
Received: (from ananth@localhost)
	by dbear.engr.sgi.com (8.9.3/8.8.7) id KAA21584
	for slinx-xfs@engr; Fri, 19 May 2000 10:16:57 -0700
Date:   Fri, 19 May 2000 10:16:57 -0700
From:   Ananth Ananthanarayanan <ananth@dbear.engr.sgi.com>
Message-Id: <200005191716.KAA21584@dbear.engr.sgi.com>
Subject: TAKE - fix non-XFS 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


Although xfs tree is not slinx, other people
are using it since the xfs tree has all
the goodies like kdb, profiling, etc. ...


Modid:  2.3.99pre2-xfs:slinx:62230a
Date:  Fri May 19 10:15:59 PDT 2000
Workarea:  bonnie.engr.sgi.com:/build2/ananth/slinx23-xfs-tot
Author:  ananth

The following file(s) were checked into:
  bonnie:/isms/slinx/2.3.99pre2-xfs

linux/mm/filemap.c - 1.38
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/mm/filemap.c.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h
	- Fix non-XFS build.


From owner-linux-xfs@oss.sgi.com Fri May 19 11:43:50 2000
Received: (from majordomo@localhost)
	by oss.sgi.com (8.10.1/8.10.1) id e4JIhoV00889
	for linux-xfs-outgoing; Fri, 19 May 2000 11:43:50 -0700
X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f
Received: from timbuk.cray.com ([128.162.8.102])
	by oss.sgi.com (8.10.1/8.10.1) with ESMTP id e4JIhms00886
	for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 11:43:49 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id OAA17405 for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 14:43:45 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id OAA85151 for linux-xfs@oss.sgi.com; Fri, 19 May 2000 14:43:47 -0500 (CDT)
Date: Fri, 19 May 2000 14:43:47 -0500 (CDT)
From: Steve Lord <lord@cray.com>
Message-Id: <200005191943.OAA85151@clink.americas.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - misc fixes
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Make pagebuf load as a module again and change the delay implementation
so that it will sleep.

Modid:  2.3.99pre2-xfs:slinx:62291a
Date:  Fri May 19 12:41:41 PDT 2000
Workarea:  jen.cray.com:/data/clink/io/lord/xfs-linux

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

linux/kernel/ksyms.c - 1.43
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kernel/ksyms.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h
	- export pagecache_lock to modules so that pagebuf can be loaded


Subject: TAKE - 

Modid:  2.3.99pre2-xfs:slinx:62292a
Date:  Fri May 19 12:42:50 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
Author:  lord

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

linux/fs/xfs/linux/xfs_random.c - 1.39
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h
	- Change delay implementation so something which sleeps


From owner-linux-xfs@oss.sgi.com Fri May 19 11:45:14 2000
Received: (from majordomo@localhost)
	by oss.sgi.com (8.10.1/8.10.1) id e4JIjEw00964
	for linux-xfs-outgoing; Fri, 19 May 2000 11:45:14 -0700
X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f
Received: from timbuk.cray.com ([128.162.8.102])
	by oss.sgi.com (8.10.1/8.10.1) with ESMTP id e4JIjCs00961
	for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 11:45:12 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id OAA17414 for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 14:45:08 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id OAA40869 for linux-xfs@oss.sgi.com; Fri, 19 May 2000 14:45:10 -0500 (CDT)
Date: Fri, 19 May 2000 14:45:10 -0500 (CDT)
From: Steve Lord <lord@cray.com>
Message-Id: <200005191945.OAA40869@clink.americas.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - fix locking on super block in xfs
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Modid:  2.3.99pre2-xfs:slinx:62293a
Date:  Fri May 19 12:44:50 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
Author:  lord

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

linux/fs/xfs/linux/xfs_super.c - 1.64
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c.diff?r1=text&tr1=1.64&r2=text&tr2=1.63&f=h
	- Do not mess with lock state of super block in read_super
	  method, this is all handled in the VFS now.


From owner-linux-xfs@oss.sgi.com Fri May 19 11:48:32 2000
Received: (from majordomo@localhost)
	by oss.sgi.com (8.10.1/8.10.1) id e4JImWO01061
	for linux-xfs-outgoing; Fri, 19 May 2000 11:48:32 -0700
X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f
Received: from timbuk.cray.com ([128.162.8.102])
	by oss.sgi.com (8.10.1/8.10.1) with ESMTP id e4JImUs01058
	for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 11:48:30 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id OAA17418 for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 14:48:27 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id OAA79385 for linux-xfs@oss.sgi.com; Fri, 19 May 2000 14:48:29 -0500 (CDT)
Date: Fri, 19 May 2000 14:48:29 -0500 (CDT)
From: Steve Lord <lord@cray.com>
Message-Id: <200005191948.OAA79385@clink.americas.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - more page validity changes
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Modid:  2.3.99pre2-xfs:slinx:62295a
Date:  Fri May 19 12:48:09 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
Author:  lord

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

linux/fs/page_buf.c - 1.96
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.96&r2=text&tr2=1.95&f=h
	- Fix setting of page validity bits in _pagebuf_handle_iovecs


From owner-linux-xfs@oss.sgi.com Fri May 19 11:55:21 2000
Received: (from majordomo@localhost)
	by oss.sgi.com (8.10.1/8.10.1) id e4JItLv01207
	for linux-xfs-outgoing; Fri, 19 May 2000 11:55:21 -0700
X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.10.1/8.10.1) with ESMTP id e4JItKU01204
	for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 11:55:20 -0700
Received: (from cattelan@localhost)
	by lips.borg.umn.edu (8.10.0/8.10.0) id e4JJtJV45477
	for linux-xfs@oss.sgi.com; Fri, 19 May 2000 14:55:19 -0500 (CDT)
Date: Fri, 19 May 2000 14:55:19 -0500 (CDT)
From: Russell Cattelan <cattelan@thebarn.com>
Message-Id: <200005191955.e4JJtJV45477@lips.borg.umn.edu>
To: linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

new oss... testing the list

From owner-linux-xfs@oss.sgi.com Fri May 19 12:00:48 2000
Received: (from majordomo@localhost)
	by oss.sgi.com (8.10.1/8.10.1) id e4JJ0ms01333
	for linux-xfs-outgoing; Fri, 19 May 2000 12:00:48 -0700
X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f
Received: from timbuk.cray.com ([128.162.8.102])
	by oss.sgi.com (8.10.1/8.10.1) with ESMTP id e4JJ0lU01330
	for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 12:00:47 -0700
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by timbuk.cray.com (8.8.8/CRI-gate-news-1.3) with ESMTP id PAA17518 for <linux-xfs@oss.sgi.com>; Fri, 19 May 2000 15:00:44 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id PAA53554 for linux-xfs@oss.sgi.com; Fri, 19 May 2000 15:00:46 -0500 (CDT)
Date: Fri, 19 May 2000 15:00:46 -0500 (CDT)
From: Steve Lord <lord@cray.com>
Message-Id: <200005192000.PAA53554@clink.americas.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - pagebuf metadata locking fixes
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Modid:  2.3.99pre2-xfs:slinx:62296a
Date:  Fri May 19 13:00:23 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
Author:  lord

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

linux/fs/page_buf_locking.c - 1.24
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf_locking.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h
	- Cleanup spinlock handling around pagebuf creation/removal


From owner-linux-xfs@oss.sgi.com Sat May 20 08:22:34 2000
Received: (from majordomo@localhost)
	by oss.sgi.com (8.10.1/8.10.1) id e4KFMYD10073
	for linux-xfs-outgoing; Sat, 20 May 2000 08:22:34 -0700
X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f
Received: from ns.hanse.com (IDENT:root@ns.hanse.com [212.209.57.34])
	by oss.sgi.com (8.10.1/8.10.1) with ESMTP id e4KFMVn10070
	for <linux-xfs@oss.sgi.com>; Sat, 20 May 2000 08:22:32 -0700
Received: from hanse.com (voyager.stesmi.com [212.209.57.67])
	by ns.hanse.com (8.9.3/8.8.7) with ESMTP id OAA13117;
	Sat, 20 May 2000 14:30:27 +0200
Message-ID: <39268517.C2B0943F@hanse.com>
Date: Sat, 20 May 2000 14:29:11 +0200
From: Stefan Smietanowski <stefan@hanse.com>
Organization: Hanse Communication
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Daniel Moore <dxm@clouds.melbourne.sgi.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Intel -> MIPS switcheroo
References: <200005190201.MAA24637@clouds.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi!

<snip use only MIPS XFS format (big endian)>

> Our proposal is to go ahead with this on our Monday.
> 
> If anyone has any objections to this idea, please let me know.
> We can certainly change the timing to work around people who
> are hunting corruption/getting ready to do other big commits
> etc...

As long as XFS/IRIX and XFS/Linux work the same, ie are
mountable/workable under the other, then go ahead.

That should be the most logical way to do it.

Ext2 used local before as well, for example the m68k port used Big
Endian EXT2, but they changed to using little endian instead, with
little performance impact.

// Stefan

From majordomo@oss.sgi.com Sun May 21 19:13:59 2000
Received: (from localhost user: 'majordomo', uid#102) by oss.sgi.com
	id <S42246AbQEVCNj>; Sun, 21 May 2000 19:13:39 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:30291 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42239AbQEVCN1>; Sun, 21 May 2000 19:13:27 -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 SAA08096
	for <linux-xfs@oss.sgi.com>; Sun, 21 May 2000 18:04:32 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25883; Mon, 22 May 2000 10:58:35 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA21014; Mon, 22 May 2000 10:58:34 +1000 (EST)
Date:   Mon, 22 May 2000 10:58:34 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005220058.KAA21014@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com, slinx-xfs@engr.sgi.com
Subject: TAKE - As advised: Major architecture change
Sender: Majordomo List Manager <majordomo@oss.sgi.com>
Fake-Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <majordomo@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This mod makes MIPS-XFS the default, and indeed the ONLY
supported architecture for XFS.

One you check this mod out, you'll need to:

   - rebuild your kernel/XFS modules (and reboot/reload)
   - rebuild your user tools (and reinstall them)
   - rebuild your XFS filesystems (ie mkfs them with your rebuilt mkfs)

As of this mod, XFS on Linux-Intel and IRIX-MIPS should be compatible.

The caveats on this are that extended attributes and quotas are not
supported yet, and only cleanly unmounted filesystems may be moved
between architectures.

Enjoy!

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

Modid:  2.3.99pre2-xfs:slinx:62350a
Date:  Sun May 21 17:48:08 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.3.99pre2-xfs

cmd/xfs/db/Makefile - 1.42
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/Makefile.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h
cmd/xfs/db/bit.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/bit.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
cmd/xfs/db/bmap.c - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/bmap.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
cmd/xfs/db/bmapbt.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/bmapbt.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
cmd/xfs/db/bmroot.c - 1.20
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/bmroot.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h
cmd/xfs/db/bnobt.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/bnobt.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
cmd/xfs/db/check.c - 1.50
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/check.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h
cmd/xfs/db/cntbt.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/cntbt.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
cmd/xfs/db/command.c - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/command.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
cmd/xfs/db/dir.c - 1.23
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/dir.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h
cmd/xfs/db/dir2.c - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/dir2.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
cmd/xfs/db/frag.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/frag.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
cmd/xfs/db/freesp.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/freesp.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
cmd/xfs/db/inobt.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/inobt.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
cmd/xfs/db/inode.c - 1.32
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/inode.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h
cmd/xfs/db/mount.c - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/mount.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
cmd/xfs/db/sb.c - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/sb.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
cmd/xfs/logprint/log_misc.c - 1.57
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/logprint/log_misc.c.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h
cmd/xfs/logprint/log_print_trans.c - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/logprint/log_print_trans.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
cmd/xfs/maxtrres/xfs_maxtrres.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/maxtrres/xfs_maxtrres.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
cmd/xfs/mkfile/xfs_mkfile.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mkfile/xfs_mkfile.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
cmd/xfs/mkfs/xfs_mkfs.c - 1.161
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.161&r2=text&tr2=1.160&f=h
cmd/xfs/repair/attr_repair.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/attr_repair.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
cmd/xfs/repair/dinode.c - 1.74
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dinode.c.diff?r1=text&tr1=1.74&r2=text&tr2=1.73&f=h
cmd/xfs/repair/dir.c - 1.53
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dir.c.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h
cmd/xfs/repair/dir2.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dir2.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
cmd/xfs/repair/incore.h - 1.33
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/incore.h.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h
cmd/xfs/repair/phase4.c - 1.44
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase4.c.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h
cmd/xfs/repair/phase6.c - 1.52
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase6.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h
cmd/xfs/sim/src/libdisk.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/libdisk.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
cmd/xfs/sim/src/linux_fs.h - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/linux_fs.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
cmd/xfs/sim/src/sim.random.c - 1.107
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/sim.random.c.diff?r1=text&tr1=1.107&r2=text&tr2=1.106&f=h
linux/fs/Config.in - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/Config.in.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
linux/fs/xfs/xfs_ag.h - 1.34
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ag.h.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h
linux/fs/xfs/xfs_alloc.c - 1.132
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_alloc.c.diff?r1=text&tr1=1.132&r2=text&tr2=1.131&f=h
linux/fs/xfs/xfs_alloc_btree.c - 1.60
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_alloc_btree.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h
linux/fs/xfs/xfs_arch.h - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_arch.h.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
linux/fs/xfs/xfs_bmap.c - 1.252
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap.c.diff?r1=text&tr1=1.252&r2=text&tr2=1.251&f=h
linux/fs/xfs/xfs_bmap_btree.c - 1.112
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap_btree.c.diff?r1=text&tr1=1.112&r2=text&tr2=1.111&f=h
linux/fs/xfs/xfs_bmap_btree.h - 1.47
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap_btree.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h
linux/fs/xfs/xfs_btree.c - 1.84
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_btree.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h
linux/fs/xfs/xfs_da_btree.c - 1.107
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.c.diff?r1=text&tr1=1.107&r2=text&tr2=1.106&f=h
linux/fs/xfs/xfs_dir.c - 1.125
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir.c.diff?r1=text&tr1=1.125&r2=text&tr2=1.124&f=h
linux/fs/xfs/xfs_dir2.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
linux/fs/xfs/xfs_dir2_block.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_block.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
linux/fs/xfs/xfs_dir2_data.c - 1.10
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_data.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h
linux/fs/xfs/xfs_dir2_leaf.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_leaf.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
linux/fs/xfs/xfs_dir2_node.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_node.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
linux/fs/xfs/xfs_dir2_sf.c - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_sf.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
linux/fs/xfs/xfs_dir_leaf.c - 1.84
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir_leaf.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h
linux/fs/xfs/xfs_fsops.c - 1.52
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_fsops.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h
linux/fs/xfs/xfs_ialloc.c - 1.135
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc.c.diff?r1=text&tr1=1.135&r2=text&tr2=1.134&f=h
linux/fs/xfs/xfs_ialloc_btree.c - 1.57
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc_btree.c.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h
linux/fs/xfs/xfs_ialloc_btree.h - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc_btree.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
linux/fs/xfs/xfs_inode.c - 1.285
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.285&r2=text&tr2=1.284&f=h
linux/fs/xfs/xfs_itable.c - 1.84
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_itable.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h
linux/fs/xfs/xfs_log.c - 1.216
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.216&r2=text&tr2=1.215&f=h
linux/fs/xfs/xfs_log.h - 1.51
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.h.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h
linux/fs/xfs/xfs_log_print.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_print.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
linux/fs/xfs/xfs_log_recover.c - 1.178
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.178&r2=text&tr2=1.177&f=h
linux/fs/xfs/xfs_mount.c - 1.221
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.221&r2=text&tr2=1.220&f=h
linux/fs/xfs/xfs_mount.h - 1.111
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.h.diff?r1=text&tr1=1.111&r2=text&tr2=1.110&f=h
linux/fs/xfs/xfs_sb.h - 1.45
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_sb.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h
linux/fs/xfs/xfs_trans.c - 1.113
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_trans.c.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h
linux/fs/xfs/xfsidbg.c - 1.141
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.141&r2=text&tr2=1.140&f=h

From owner-linux-xfs@oss.sgi.com Sun May 21 19:28:26 2000
Received:  by oss.sgi.com id <S42241AbQEVC2G>;
	Sun, 21 May 2000 19:28:06 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:52821 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42239AbQEVC1r>;
	Sun, 21 May 2000 19:27:47 -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 TAA29649
	for <linux-xfs@oss.sgi.com>; Sun, 21 May 2000 19:22:54 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA26440 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 22 May 2000 12:25:12 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA37344 for linux-xfs@oss.sgi.com; Mon, 22 May 2000 12:25:12 +1000 (EST)
Date:   Mon, 22 May 2000 12:25:12 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005220225.MAA37344@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xlatesb changes
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

change definition of xlatesb to remove hacks in user-tools.

Modid:  2.3.99pre2-xfs:slinx:62351a
Date:  Sun May 21 19:24:39 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.3.99pre2-xfs

cmd/xfs/db/mount.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/mount.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
	- remove xlatesb hack

cmd/xfs/mkfs/xfs_mkfs.c - 1.162
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.162&r2=text&tr2=1.161&f=h
cmd/xfs/sim/src/sim.random.c - 1.108
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/sim.random.c.diff?r1=text&tr1=1.108&r2=text&tr2=1.107&f=h
	- remove xlatesb hack 

linux/fs/xfs/xfs_mount.c - 1.222
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.222&r2=text&tr2=1.221&f=h
	- change xlatesb definition to remove user tools hacks


From owner-linux-xfs@oss.sgi.com Sun May 21 22:44:35 2000
Received:  by oss.sgi.com id <S42249AbQEVFoZ>;
	Sun, 21 May 2000 22:44:25 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:11353 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42248AbQEVFoH>; Sun, 21 May 2000 22:44:07 -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 WAA02907
	for <linux-xfs@oss.sgi.com>; Sun, 21 May 2000 22:48:42 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA27401 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Mon, 22 May 2000 15:42:48 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA69048 for linux-xfs@oss.sgi.com; Mon, 22 May 2000 15:42:47 +1000 (EST)
Date:   Mon, 22 May 2000 15:42:47 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005220542.PAA69048@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - arch bugfix
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

need INT_GET/INT_SET on copy if types are different.
hurumph.

Modid:  2.3.99pre2-xfs:slinx:62352a
Date:  Sun May 21 22:42:00 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.3.99pre2-xfs

linux/fs/xfs/xfs_dir2_data.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_data.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
linux/fs/xfs/xfs_dir2_leaf.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_leaf.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
linux/fs/xfs/xfs_dir2_node.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_node.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
linux/fs/xfs/xfs_dir_leaf.c - 1.85
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir_leaf.c.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h

From owner-linux-xfs@oss.sgi.com Mon May 22 08:05:08 2000
Received:  by oss.sgi.com id <S42254AbQEVPE6>;
	Mon, 22 May 2000 08:04:58 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:64601 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42242AbQEVPE2>;
	Mon, 22 May 2000 08:04:28 -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 HAA26317; Mon, 22 May 2000 07:59:36 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id IAA98585; Mon, 22 May 2000 08:04:22 -0700 (PDT)
Date:   Mon, 22 May 2000 08:04:22 -0700 (PDT)
Message-Id: <200005221504.IAA98585@info.engr.sgi.com>
X-Pv-Incident: 768256 
webPV:  jen.cray.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (lord@sgi.com)
Subject: CLOSE 768256 - Map XFS lower level interface to Linux (buffer/page/block devices)
To:     lord@sgi.com
Cc:     slinx-xfs@cthulhu.engr.sgi.com, 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=768256

*Status : closed                       Priority : 1                         
 Assigned Engineer : lord              Submitter : mostek                   
 Opened Date : 09/23/99               *Closed Date : 05/22/00               
*Fixed By : lord                      *Fixed By Domain : sgi.com            
*Modified Date : 05/22/00             *Modified User : lord                 
*Modified User Domain : sgi.com       *Fix Description :
==========================
ADDITIONAL INFORMATION (CLOSE)
From: lord@sgi.com (BugWorks)
Date: May 22 2000 08:04:22AM
==========================

This was done a long time ago

From owner-linux-xfs@oss.sgi.com Mon May 22 08:05:28 2000
Received:  by oss.sgi.com id <S42255AbQEVPFS>;
	Mon, 22 May 2000 08:05:18 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33649 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42242AbQEVPFC>; Mon, 22 May 2000 08:05:02 -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 IAA02159; Mon, 22 May 2000 08:09:39 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id IAA78671; Mon, 22 May 2000 08:04:56 -0700 (PDT)
Date:   Mon, 22 May 2000 08:04:56 -0700 (PDT)
Message-Id: <200005221504.IAA78671@info.engr.sgi.com>
X-Pv-Incident: 768271 
webPV:  jen.cray.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (lord@sgi.com)
Subject: CLOSE 768271 - Implement file ops for XFS on Linux.
To:     lord@sgi.com
Cc:     slinx-xfs@cthulhu.engr.sgi.com, 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=768271

*Status : closed                       Priority : 1                         
 Assigned Engineer : lord              Submitter : mostek                   
 Opened Date : 09/23/99               *Closed Date : 05/22/00               
*Fixed By : lord                      *Fixed By Domain : sgi.com            
*Modified Date : 05/22/00             *Modified User : lord                 
*Modified User Domain : sgi.com       *Fix Description :
==========================
ADDITIONAL INFORMATION (CLOSE)
From: lord@sgi.com (BugWorks)
Date: May 22 2000 08:04:56AM
==========================

Completed a long time ago

From owner-linux-xfs@oss.sgi.com Mon May 22 08:08:28 2000
Received:  by oss.sgi.com id <S42256AbQEVPIS>;
	Mon, 22 May 2000 08:08:18 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:64858 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42242AbQEVPIO>;
	Mon, 22 May 2000 08:08:14 -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 IAA26842; Mon, 22 May 2000 08:03:22 -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 IAA18813; Mon, 22 May 2000 08:07:43 -0700 (PDT)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id IAA40041; Mon, 22 May 2000 08:06:21 -0700 (PDT)
Date:   Mon, 22 May 2000 08:06:21 -0700 (PDT)
Message-Id: <200005221506.IAA40041@info.engr.sgi.com>
X-Pv-Incident: 787427 
webPV:  jen.cray.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (lord@sgi.com)
Subject: CLOSE 787427 - file system corrupts with page buf meta data on after unmount/mount
To:     lord@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=787427

*Status : closed                       Priority : 1                         
 Assigned Engineer : lord              Submitter : mostek                   
 Opened Date : 04/07/00               *Closed Date : 05/22/00               
*Fixed By : lord                      *Fixed By Domain : sgi.com            
*Modified Date : 05/22/00             *Modified User : lord                 
*Modified User Domain : sgi.com       *Fix Description :
==========================
ADDITIONAL INFORMATION (CLOSE)
From: lord@sgi.com (BugWorks)
Date: May 22 2000 08:06:21AM
==========================

This is fixed

From owner-linux-xfs@oss.sgi.com Mon May 22 12:44:42 2000
Received:  by oss.sgi.com id <S42263AbQEVTod>;
	Mon, 22 May 2000 12:44:33 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:10551 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42260AbQEVTn7>;
	Mon, 22 May 2000 12:43:59 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA06400
	for <linux-xfs@oss.sgi.com>; Mon, 22 May 2000 12:39:07 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA73305 for <linux-xfs@oss.sgi.com>; Mon, 22 May 2000 14:42:43 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id OAA15177 for <linux-xfs@oss.sgi.com>; Mon, 22 May 2000 14:42:42 -0500 (CDT)
Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e4MJge724812
	for <linux-xfs@oss.sgi.com>; Mon, 22 May 2000 14:42:40 -0500
Message-ID: <39298DB0.9663DECC@thebarn.com>
Date:   Mon, 22 May 2000 14:42:40 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
CC:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - As advised: Major architecture change
References: <200005220058.KAA21014@snort.melbourne.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

Daniel Moore wrote:


Hmm something is amiss in the recovery code.
Starting XFS recovery on filesystem: sd(8,2) (dev: 8/8)
cmn_err level 1 Filesystem "sd(8,2)": xfs_inode_recover: Bad inode magic
number, dino ptr = 0xc490a500, dino bp = 0xc2beb560, ino = 4810117
XFS assertion failed: log->l_buf_cancel_table[i] == NULL, file:
xfs_log_recover.c, line: 3271
kernel BUG at xfs_debug.c:86!
Entering kdb (0xc1e14000) Panic: invalid operand
due to panic @ 0xc48c6389
eax = 0x0000001e ebx = 0x00000010 ecx = 0xc028ce7c edx = 0xc028ce7c
esi = 0xc0f7d360 edi = 0x000003f2 esp = <kernel>   eip = 0xc48c6389
ebp = 0xc1e15988  ss = 0xc48e7dae  cs = 0x00000010 eflags = 0x00010282
 ds = <kernel>    es = 0x00000018 origeax = 0xffffffff &regs =
0xc1e15948
kdb> md 0xc490a500
c490a500: 8100494e 00010201 0000716f 00000419  NI......oq......
c490a510: 00000001 00000000 00000000 00000000  ................
c490a520: 3929790e 19523550 3929790e 19523550  .y)9P5R..y)9P5R.
c490a530: 3929790e 19523550 00000000 00000000  .y)9P5R.........
c490a540: 00000000 00000000 00000000 00000000  ................
c490a550: 02000000 000hlep' 00000000 00000000  ................
kdb> help ffffffff 00000000 00000000 92000000  ............


> This mod makes MIPS-XFS the default, and indeed the ONLY
> supported architecture for XFS.
>
> One you check this mod out, you'll need to:
>
>    - rebuild your kernel/XFS modules (and reboot/reload)
>    - rebuild your user tools (and reinstall them)
>    - rebuild your XFS filesystems (ie mkfs them with your rebuilt mkfs)
>
> As of this mod, XFS on Linux-Intel and IRIX-MIPS should be compatible.
>
> The caveats on this are that extended attributes and quotas are not
> supported yet, and only cleanly unmounted filesystems may be moved
> between architectures.
>
> Enjoy!
>
> -----------------------------------------------------
>  Daniel Moore                  dxm@sgi.com
>  R&D Software Engineer         Phone: +61-3-98348209
>  SGI Performance Tools Group   Fax:   +61-3-98132378
> -----------------------------------------------------
>
> Modid:  2.3.99pre2-xfs:slinx:62350a
> Date:  Sun May 21 17:48:08 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.3.99pre2-xfs
>
> cmd/xfs/db/Makefile - 1.42
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/Makefile.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h
> cmd/xfs/db/bit.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/bit.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
> cmd/xfs/db/bmap.c - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/bmap.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
> cmd/xfs/db/bmapbt.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/bmapbt.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
> cmd/xfs/db/bmroot.c - 1.20
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/bmroot.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h
> cmd/xfs/db/bnobt.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/bnobt.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
> cmd/xfs/db/check.c - 1.50
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/check.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h
> cmd/xfs/db/cntbt.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/cntbt.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
> cmd/xfs/db/command.c - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/command.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
> cmd/xfs/db/dir.c - 1.23
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/dir.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h
> cmd/xfs/db/dir2.c - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/dir2.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
> cmd/xfs/db/frag.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/frag.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
> cmd/xfs/db/freesp.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/freesp.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
> cmd/xfs/db/inobt.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/inobt.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
> cmd/xfs/db/inode.c - 1.32
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/inode.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h
> cmd/xfs/db/mount.c - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/mount.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
> cmd/xfs/db/sb.c - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/sb.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
> cmd/xfs/logprint/log_misc.c - 1.57
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/logprint/log_misc.c.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h
> cmd/xfs/logprint/log_print_trans.c - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/logprint/log_print_trans.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
> cmd/xfs/maxtrres/xfs_maxtrres.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/maxtrres/xfs_maxtrres.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
> cmd/xfs/mkfile/xfs_mkfile.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/mkfile/xfs_mkfile.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
> cmd/xfs/mkfs/xfs_mkfs.c - 1.161
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.161&r2=text&tr2=1.160&f=h
> cmd/xfs/repair/attr_repair.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/attr_repair.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
> cmd/xfs/repair/dinode.c - 1.74
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/dinode.c.diff?r1=text&tr1=1.74&r2=text&tr2=1.73&f=h
> cmd/xfs/repair/dir.c - 1.53
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/dir.c.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h
> cmd/xfs/repair/dir2.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/dir2.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
> cmd/xfs/repair/incore.h - 1.33
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/incore.h.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h
> cmd/xfs/repair/phase4.c - 1.44
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/phase4.c.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h
> cmd/xfs/repair/phase6.c - 1.52
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/phase6.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h
> cmd/xfs/sim/src/libdisk.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/sim/src/libdisk.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
> cmd/xfs/sim/src/linux_fs.h - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/sim/src/linux_fs.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
> cmd/xfs/sim/src/sim.random.c - 1.107
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/sim/src/sim.random.c.diff?r1=text&tr1=1.107&r2=text&tr2=1.106&f=h
> linux/fs/Config.in - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/Config.in.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
> linux/fs/xfs/xfs_ag.h - 1.34
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_ag.h.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h
> linux/fs/xfs/xfs_alloc.c - 1.132
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_alloc.c.diff?r1=text&tr1=1.132&r2=text&tr2=1.131&f=h
> linux/fs/xfs/xfs_alloc_btree.c - 1.60
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_alloc_btree.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h
> linux/fs/xfs/xfs_arch.h - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_arch.h.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
> linux/fs/xfs/xfs_bmap.c - 1.252
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_bmap.c.diff?r1=text&tr1=1.252&r2=text&tr2=1.251&f=h
> linux/fs/xfs/xfs_bmap_btree.c - 1.112
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_bmap_btree.c.diff?r1=text&tr1=1.112&r2=text&tr2=1.111&f=h
> linux/fs/xfs/xfs_bmap_btree.h - 1.47
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_bmap_btree.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h
> linux/fs/xfs/xfs_btree.c - 1.84
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_btree.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h
> linux/fs/xfs/xfs_da_btree.c - 1.107
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_da_btree.c.diff?r1=text&tr1=1.107&r2=text&tr2=1.106&f=h
> linux/fs/xfs/xfs_dir.c - 1.125
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir.c.diff?r1=text&tr1=1.125&r2=text&tr2=1.124&f=h
> linux/fs/xfs/xfs_dir2.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir2.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
> linux/fs/xfs/xfs_dir2_block.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir2_block.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
> linux/fs/xfs/xfs_dir2_data.c - 1.10
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir2_data.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h
> linux/fs/xfs/xfs_dir2_leaf.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir2_leaf.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
> linux/fs/xfs/xfs_dir2_node.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir2_node.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
> linux/fs/xfs/xfs_dir2_sf.c - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir2_sf.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
> linux/fs/xfs/xfs_dir_leaf.c - 1.84
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir_leaf.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h
> linux/fs/xfs/xfs_fsops.c - 1.52
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_fsops.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h
> linux/fs/xfs/xfs_ialloc.c - 1.135
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_ialloc.c.diff?r1=text&tr1=1.135&r2=text&tr2=1.134&f=h
> linux/fs/xfs/xfs_ialloc_btree.c - 1.57
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_ialloc_btree.c.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h
> linux/fs/xfs/xfs_ialloc_btree.h - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_ialloc_btree.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
> linux/fs/xfs/xfs_inode.c - 1.285
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.285&r2=text&tr2=1.284&f=h
> linux/fs/xfs/xfs_itable.c - 1.84
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_itable.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h
> linux/fs/xfs/xfs_log.c - 1.216
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.216&r2=text&tr2=1.215&f=h
> linux/fs/xfs/xfs_log.h - 1.51
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_log.h.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h
> linux/fs/xfs/xfs_log_print.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_log_print.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
> linux/fs/xfs/xfs_log_recover.c - 1.178
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.178&r2=text&tr2=1.177&f=h
> linux/fs/xfs/xfs_mount.c - 1.221
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.221&r2=text&tr2=1.220&f=h
> linux/fs/xfs/xfs_mount.h - 1.111
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_mount.h.diff?r1=text&tr1=1.111&r2=text&tr2=1.110&f=h
> linux/fs/xfs/xfs_sb.h - 1.45
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_sb.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h
> linux/fs/xfs/xfs_trans.c - 1.113
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_trans.c.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h
> linux/fs/xfs/xfsidbg.c - 1.141
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.141&r2=text&tr2=1.140&f=h

From owner-linux-xfs@oss.sgi.com Mon May 22 12:44:43 2000
Received:  by oss.sgi.com id <S42262AbQEVTeW>;
	Mon, 22 May 2000 12:34:22 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:53044 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42260AbQEVTd7>;
	Mon, 22 May 2000 12:33:59 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA05201
	for <linux-xfs@oss.sgi.com>; Mon, 22 May 2000 12:29:07 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA49060; Mon, 22 May 2000 14:32:36 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id OAA14784; Mon, 22 May 2000 14:32:34 -0500 (CDT)
Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e4MJWW724803;
	Mon, 22 May 2000 14:32:32 -0500
Message-ID: <39298B50.33E4B4E3@thebarn.com>
Date:   Mon, 22 May 2000 14:32:32 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Daniel Moore <dxm@snort.melbourne.sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - As advised: Major architecture change
References: <200005220058.KAA21014@snort.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:


Hmm something is amiss in the recovery code.
Starting XFS recovery on filesystem: sd(8,2) (dev: 8/8)
cmn_err level 1 Filesystem "sd(8,2)": xfs_inode_recover: Bad inode magic
number, dino ptr = 0xc490a500, dino bp = 0xc2beb560, ino = 4810117
XFS assertion failed: log->l_buf_cancel_table[i] == NULL, file:
xfs_log_recover.c, line: 3271
kernel BUG at xfs_debug.c:86!
Entering kdb (0xc1e14000) Panic: invalid operand
due to panic @ 0xc48c6389
eax = 0x0000001e ebx = 0x00000010 ecx = 0xc028ce7c edx = 0xc028ce7c
esi = 0xc0f7d360 edi = 0x000003f2 esp = <kernel>   eip = 0xc48c6389
ebp = 0xc1e15988  ss = 0xc48e7dae  cs = 0x00000010 eflags = 0x00010282
 ds = <kernel>    es = 0x00000018 origeax = 0xffffffff &regs = 0xc1e15948
kdb> md 0xc490a500
c490a500: 8100494e 00010201 0000716f 00000419  NI......oq......
c490a510: 00000001 00000000 00000000 00000000  ................
c490a520: 3929790e 19523550 3929790e 19523550  .y)9P5R..y)9P5R.
c490a530: 3929790e 19523550 00000000 00000000  .y)9P5R.........
c490a540: 00000000 00000000 00000000 00000000  ................
c490a550: 02000000 000hlep' 00000000 00000000  ................
kdb> help ffffffff 00000000 00000000 92000000  ............


> This mod makes MIPS-XFS the default, and indeed the ONLY
> supported architecture for XFS.
>
> One you check this mod out, you'll need to:
>
>    - rebuild your kernel/XFS modules (and reboot/reload)
>    - rebuild your user tools (and reinstall them)
>    - rebuild your XFS filesystems (ie mkfs them with your rebuilt mkfs)
>
> As of this mod, XFS on Linux-Intel and IRIX-MIPS should be compatible.
>
> The caveats on this are that extended attributes and quotas are not
> supported yet, and only cleanly unmounted filesystems may be moved
> between architectures.
>
> Enjoy!
>
> -----------------------------------------------------
>  Daniel Moore                  dxm@sgi.com
>  R&D Software Engineer         Phone: +61-3-98348209
>  SGI Performance Tools Group   Fax:   +61-3-98132378
> -----------------------------------------------------
>
> Modid:  2.3.99pre2-xfs:slinx:62350a
> Date:  Sun May 21 17:48:08 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.3.99pre2-xfs
>
> cmd/xfs/db/Makefile - 1.42
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/Makefile.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h
> cmd/xfs/db/bit.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/bit.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
> cmd/xfs/db/bmap.c - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/bmap.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
> cmd/xfs/db/bmapbt.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/bmapbt.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
> cmd/xfs/db/bmroot.c - 1.20
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/bmroot.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h
> cmd/xfs/db/bnobt.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/bnobt.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
> cmd/xfs/db/check.c - 1.50
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/check.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h
> cmd/xfs/db/cntbt.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/cntbt.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
> cmd/xfs/db/command.c - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/command.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
> cmd/xfs/db/dir.c - 1.23
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/dir.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h
> cmd/xfs/db/dir2.c - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/dir2.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
> cmd/xfs/db/frag.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/frag.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
> cmd/xfs/db/freesp.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/freesp.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
> cmd/xfs/db/inobt.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/inobt.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
> cmd/xfs/db/inode.c - 1.32
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/inode.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h
> cmd/xfs/db/mount.c - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/mount.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
> cmd/xfs/db/sb.c - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/db/sb.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
> cmd/xfs/logprint/log_misc.c - 1.57
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/logprint/log_misc.c.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h
> cmd/xfs/logprint/log_print_trans.c - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/logprint/log_print_trans.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
> cmd/xfs/maxtrres/xfs_maxtrres.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/maxtrres/xfs_maxtrres.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
> cmd/xfs/mkfile/xfs_mkfile.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/mkfile/xfs_mkfile.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
> cmd/xfs/mkfs/xfs_mkfs.c - 1.161
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.161&r2=text&tr2=1.160&f=h
> cmd/xfs/repair/attr_repair.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/attr_repair.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
> cmd/xfs/repair/dinode.c - 1.74
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/dinode.c.diff?r1=text&tr1=1.74&r2=text&tr2=1.73&f=h
> cmd/xfs/repair/dir.c - 1.53
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/dir.c.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h
> cmd/xfs/repair/dir2.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/dir2.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
> cmd/xfs/repair/incore.h - 1.33
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/incore.h.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h
> cmd/xfs/repair/phase4.c - 1.44
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/phase4.c.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h
> cmd/xfs/repair/phase6.c - 1.52
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/repair/phase6.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h
> cmd/xfs/sim/src/libdisk.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/sim/src/libdisk.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
> cmd/xfs/sim/src/linux_fs.h - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/sim/src/linux_fs.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
> cmd/xfs/sim/src/sim.random.c - 1.107
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/sim/src/sim.random.c.diff?r1=text&tr1=1.107&r2=text&tr2=1.106&f=h
> linux/fs/Config.in - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/Config.in.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
> linux/fs/xfs/xfs_ag.h - 1.34
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_ag.h.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h
> linux/fs/xfs/xfs_alloc.c - 1.132
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_alloc.c.diff?r1=text&tr1=1.132&r2=text&tr2=1.131&f=h
> linux/fs/xfs/xfs_alloc_btree.c - 1.60
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_alloc_btree.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h
> linux/fs/xfs/xfs_arch.h - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_arch.h.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
> linux/fs/xfs/xfs_bmap.c - 1.252
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_bmap.c.diff?r1=text&tr1=1.252&r2=text&tr2=1.251&f=h
> linux/fs/xfs/xfs_bmap_btree.c - 1.112
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_bmap_btree.c.diff?r1=text&tr1=1.112&r2=text&tr2=1.111&f=h
> linux/fs/xfs/xfs_bmap_btree.h - 1.47
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_bmap_btree.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h
> linux/fs/xfs/xfs_btree.c - 1.84
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_btree.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h
> linux/fs/xfs/xfs_da_btree.c - 1.107
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_da_btree.c.diff?r1=text&tr1=1.107&r2=text&tr2=1.106&f=h
> linux/fs/xfs/xfs_dir.c - 1.125
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir.c.diff?r1=text&tr1=1.125&r2=text&tr2=1.124&f=h
> linux/fs/xfs/xfs_dir2.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir2.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
> linux/fs/xfs/xfs_dir2_block.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir2_block.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
> linux/fs/xfs/xfs_dir2_data.c - 1.10
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir2_data.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h
> linux/fs/xfs/xfs_dir2_leaf.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir2_leaf.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
> linux/fs/xfs/xfs_dir2_node.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir2_node.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
> linux/fs/xfs/xfs_dir2_sf.c - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir2_sf.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
> linux/fs/xfs/xfs_dir_leaf.c - 1.84
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_dir_leaf.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h
> linux/fs/xfs/xfs_fsops.c - 1.52
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_fsops.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h
> linux/fs/xfs/xfs_ialloc.c - 1.135
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_ialloc.c.diff?r1=text&tr1=1.135&r2=text&tr2=1.134&f=h
> linux/fs/xfs/xfs_ialloc_btree.c - 1.57
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_ialloc_btree.c.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h
> linux/fs/xfs/xfs_ialloc_btree.h - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_ialloc_btree.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
> linux/fs/xfs/xfs_inode.c - 1.285
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.285&r2=text&tr2=1.284&f=h
> linux/fs/xfs/xfs_itable.c - 1.84
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_itable.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h
> linux/fs/xfs/xfs_log.c - 1.216
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.216&r2=text&tr2=1.215&f=h
> linux/fs/xfs/xfs_log.h - 1.51
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_log.h.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h
> linux/fs/xfs/xfs_log_print.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_log_print.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
> linux/fs/xfs/xfs_log_recover.c - 1.178
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.178&r2=text&tr2=1.177&f=h
> linux/fs/xfs/xfs_mount.c - 1.221
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.221&r2=text&tr2=1.220&f=h
> linux/fs/xfs/xfs_mount.h - 1.111
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_mount.h.diff?r1=text&tr1=1.111&r2=text&tr2=1.110&f=h
> linux/fs/xfs/xfs_sb.h - 1.45
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_sb.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h
> linux/fs/xfs/xfs_trans.c - 1.113
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_trans.c.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h
> linux/fs/xfs/xfsidbg.c - 1.141
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.141&r2=text&tr2=1.140&f=h


From owner-linux-xfs@oss.sgi.com Mon May 22 14:03:44 2000
Received:  by oss.sgi.com id <S42264AbQEVVDY>;
	Mon, 22 May 2000 14:03:24 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:59421 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42260AbQEVVDT>; Mon, 22 May 2000 14:03:19 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA08160
	for <linux-xfs@oss.sgi.com>; Mon, 22 May 2000 14:07:56 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA70168; Mon, 22 May 2000 16:01:57 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id QAA19544; Mon, 22 May 2000 16:01:56 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id QAA23076; Mon, 22 May 2000 16:01:47 -0500
Message-Id: <200005222101.QAA23076@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     dxm@snort.melbourne.sgi.com
cc:     linux-xfs@oss.sgi.com
Subject: Re: endian conversion work
Date:   Mon, 22 May 2000 16:01:47 -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


Daniel,

Looks like we have some work cut out to make recovery work correctly now.

As an example look at the code for recovering inodes from the log:

It reads in the inode buffer and gets the inode log item, it then
directly copies one onto the other and writes it back out to disk.

The inode log item is recorded in xfs_inode_item_format() from the ip->i_d
part of the incore inode - which is in machine byte order. During recovery
this is directly copied into the inode buffer and written out to disk - so
we just byte flipped the inode core.

We could just use xfs_xlate_dinode_core() on the inode core to convert it,
we then need to look at all the other fields in the inode which can get logged
and do the byte flipping on those too, which looks like a lot of the
contents of xfs_iflush_fork(). I don't know if structures other than the 
inode will have this problem.

I think we were under the impression that recovery was working when run on
the same architecture as previously mounted on, the only issues being when
we moved a disk from one architecture to another. As it stands, development
on the rest of xfs got more painful at the moment - since we cannot recovery
from the crashes we invariably create!

Steve





From owner-linux-xfs@oss.sgi.com Mon May 22 16:42:03 2000
Received:  by oss.sgi.com id <S42266AbQEVXly>;
	Mon, 22 May 2000 16:41:54 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:49532 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42260AbQEVXll>;
	Mon, 22 May 2000 16:41:41 -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 QAA07066
	for <linux-xfs@oss.sgi.com>; Mon, 22 May 2000 16:36:48 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02695 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 23 May 2000 09:40:23 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA32965 for linux-xfs@oss.sgi.com; Tue, 23 May 2000 09:40:22 +1000 (EST)
Date:   Tue, 23 May 2000 09:40:22 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005222340.JAA32965@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - log recovery fix
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This gets log recovery going for me. It needs a bit more testing
but I'm on to it.

Modid:  2.3.99pre2-xfs:slinx:62421a
Date:  Mon May 22 16:38:23 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.3.99pre2-xfs

linux/fs/xfs/xfs_log_recover.c - 1.179
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.179&r2=text&tr2=1.178&f=h
	- temporary recovery fix


From owner-linux-xfs@oss.sgi.com Mon May 22 16:50:04 2000
Received:  by oss.sgi.com id <S42267AbQEVXty>;
	Mon, 22 May 2000 16:49:54 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:558 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42260AbQEVXtp>; Mon, 22 May 2000 16:49:45 -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 QAA05499
	for <linux-xfs@oss.sgi.com>; Mon, 22 May 2000 16:54:21 -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 JAA02769; Tue, 23 May 2000 09:48:27 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id JAA37777; Tue, 23 May 2000 09:48:26 +1000 (EST)
Message-Id: <200005222348.JAA37777@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: endian conversion work 
In-reply-to: Your message of "Mon, 22 May 2000 16:01:47 EST."
             <200005222101.QAA23076@jen.americas.sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 23 May 2000 09:48:26 +1000
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:
 => 
 => Daniel,

 => We could just use xfs_xlate_dinode_core() on the inode core to convert it,
 => we then need to look at all the other fields in the inode which can get 
...

Happily, the dinode_core is the only part of the dinode that is stored
in in-core format at any time. So currently, the inode log records
consist of an in-core inode core and the on-disk version of the rest of
the inode. The dinode_core is easy to move between in-core and on-disk
forms but the rest would be nasty.

For now, I've fixed the recovery to convert the core to on-disk before
writing it out. This is an efficient way of doing things, but if we
ever want to be able to move dirty disks between architecture, we'll
have to make sure the whole log is in on-disk format.

 => I think we were under the impression that recovery was working when run on
 => the same architecture as previously mounted on, the only issues being when
 => we moved a disk from one architecture to another. As it stands, development
 => on the rest of xfs got more painful at the moment - since we cannot recover
 => from the crashes we invariably create!

XFS crashes?! surely not...

(let me know if my TAKE fixes things - I'll keep working on log
recovery today)

-----------------------------------------------------
 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 May 22 17:03:53 2000
Received:  by oss.sgi.com id <S42268AbQEWADe>;
	Mon, 22 May 2000 17:03:34 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:24582 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42260AbQEWADR>;
	Mon, 22 May 2000 17:03:17 -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 QAA09458
	for <linux-xfs@oss.sgi.com>; Mon, 22 May 2000 16:58:24 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA02855 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 23 May 2000 10:00:44 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA35953 for linux-xfs@oss.sgi.com; Tue, 23 May 2000 10:00:44 +1000 (EST)
Date:   Tue, 23 May 2000 10:00:44 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005230000.KAA35953@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - make arch.* in db unused
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.3.99pre2-xfs:slinx:62452a
Date:  Mon May 22 16:59: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.3.99pre2-xfs

cmd/xfs/db/arch.h - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/arch.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
cmd/xfs/db/arch.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/arch.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
	now unused

From owner-linux-xfs@oss.sgi.com Mon May 22 23:11:06 2000
Received:  by oss.sgi.com id <S42270AbQEWGK4>;
	Mon, 22 May 2000 23:10:56 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33613 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42269AbQEWGKq>; Mon, 22 May 2000 23:10:46 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA01881; Mon, 22 May 2000 23:15:24 -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 XAA90575; Mon, 22 May 2000 23:10:15 -0700 (PDT)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id XAA26291; Mon, 22 May 2000 23:08:53 -0700 (PDT)
Date:   Mon, 22 May 2000 23:08:53 -0700 (PDT)
Message-Id: <200005230608.XAA26291@info.engr.sgi.com>
X-Pv-Incident: 791621 
webPV:  wobbly.melbourne.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (nathans@engr.sgi.com)
Subject: BUG 791621 - panic in xfs_inobp_check
To:     mostek@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=791621

Submitter : nathans                   Submitter Domain : engr               
Assigned Engineer : mostek            Assigned Domain : sgi.com             
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 1                          
Project : xfs-linux                   Status : open                         
Description :
I've seen this panic in the XFS code a few times now, in both
big-endian and little-endian builds (just before Daniel's
BE-only checkin).  Only happens under very high load (test is
using sendmail to queue-remote/save-local mail messages to an
xfs fs), and only happens sporadically (increased load seems
to increase the chance of it happening).

kernel is built with debug on, pagebuf meta on.


Unable to handle kernel NULL pointer dereference at virtual address 00000060
 printing eip:
c01c5c73
*pde = 00000000
Entering kdb (0xc2c6a000) on processor 0 Panic: Oops
due to panic @ 0xc01c5c73
eax = 0xc551dd40 ebx = 0x00000000 ecx = 0x00000008 edx = 0x00000000 
esi = 0x00000000 edi = 0x00000020 esp = <kernel>   eip = 0xc01c5c73 
ebp = 0xc2c6be10  ss = 0xc37727e4  cs = 0x00000010 eflags = 0x00010246 
 ds = <kernel>    es = 0x00000018 origeax = 0xffffffff &regs = 0xc2c6bdd0
[0]kdb> bt
    EBP       EIP         Function(args)
0xc2c6be10 0xc01c5c73  xfs_inobp_check+0x33( 0xc4a9d000, 0xc551dd40, 0xc37727e4, 0xc551d480, 0x1560 )
0xc2c6be78 0xc01c9395  xfs_iunlink_remove+0x5c9( 0xc37727e4, 0xc22413c0, 0xc4a9d000, 0xc22413c0, 0xc251f3b4 )
0xc2c6be94 0xc01c9518  xfs_ifree+0x174( 0xc37727e4, 0xc22413c0, 0xc0394400, 0x0, 0xc251f3b4 )
0xc2c6bec0 0xc01eef8c  xfs_inactive+0x470( 0xc22413d8, 0x0, 0xc251f3b4, 0xc0394740, 0xc28e59c0 )
0xc2c6bef0 0xc0205241  vn_rele+0x13d( 0xc251f3b4, 0xc1f73100, 0xc2c6bf1c, 0xc015f6b8 )
0xc2c6bf00 0xc02019c7  linvfs_put_inode+0x17( 0xc1f73100, 0xc28e59c0, 0xc1f73100, 0xc28e59c0 )
0xc2c6bf1c 0xc015f6b8  iput+0x38( 0xc1f73100, 0xc2f9bd80, 0xc1f73100, 0xc2c6bf48 )
0xc2c6bf30 0xc015ce67  dput+0xa7( 0xc28e59c0, 0xc2c6a000, 0xc2f9bd80, 0xc2c6a000 )
0xc2c6bf48 0xc014c330  __fput+0x40( 0xc2f9bd80, 0xc2f9bd80, 0xc2f9bd80, 0xc28e59c0, 0x0 )
0xc2c6bf64 0xc014c3ab  _fput+0x6f( 0xc2f9bd80, 0xc24ac8e4, 0xc2c6a000, 0xc2f9bd80 )
0xc2c6bf7c 0xc014ac1c  filp_close+0x64( 0xc2f9bd80, 0xc24ac8e0, 0xc2c6a000, 0x80f49f0, 0x80aa7a0 )
0xc2c6bfac 0xc014ad8b  do_close+0x163( 0x3, 0x1, 0xbfffd650, 0xc010a538, 0x3 )
0xc2c6bfbc 0xc014ae3a  sys_close+0xe( 0x3, 0x0, 0x4016848c, 0x80f49f0, 0x80aa7a0 )
0xc2c6bfd8 0xc010a538  system_call+0x34
[0]kdb> id xfs_inobp_check
xfs_inobp_check:   pushl  %ebp
xfs_inobp_check+0x1:   movl   %esp,%ebp
xfs_inobp_check+0x3:   pushl  %edi
xfs_inobp_check+0x4:   pushl  %esi
xfs_inobp_check+0x5:   pushl  %ebx
xfs_inobp_check+0x6:   movl   0x8(%ebp),%eax
xfs_inobp_check+0x9:   xorl   %esi,%esi
xfs_inobp_check+0xb:   movzwl 0x1aa(%eax),%edi
xfs_inobp_check+0x12:   movzbl 0xa2(%eax),%ecx
xfs_inobp_check+0x19:   sarl   %cl,%edi
xfs_inobp_check+0x1b:   cmpl   %edi,%esi
xfs_inobp_check+0x1d:   jnl    xfs_inobp_check+0x78
xfs_inobp_check+0x1f:   nop    
xfs_inobp_check+0x20:   movl   0x8(%ebp),%eax
xfs_inobp_check+0x23:   movzwl 0x90(%eax),%ebx
xfs_inobp_check+0x2a:   movl   0xc(%ebp),%eax
[0]kdb> id
xfs_inobp_check+0x2d:   imull  %esi,%ebx
xfs_inobp_check+0x30:   addl   0x28(%eax),%ebx
xfs_inobp_check+0x33:   cmpl   $0x0,0x60(%ebx)
^^^^^^^^^^^^^^^^^^^^                ^^^^^^^^^^
xfs_inobp_check+0x37:   jne    xfs_inobp_check+0x73
xfs_inobp_check+0x39:   pushl  %eax
xfs_inobp_check+0x3a:   pushl  $0xc02d3a40
xfs_inobp_check+0x3f:   movl   0x8(%ebp),%eax
xfs_inobp_check+0x42:   pushl  %eax
xfs_inobp_check+0x43:   pushl  $0x1
xfs_inobp_check+0x45:   call   xfs_fs_cmn_err
xfs_inobp_check+0x4a:   addl   $0x10,%esp
xfs_inobp_check+0x4d:   cmpl   $0x0,0xc03946c8
xfs_inobp_check+0x54:   je     xfs_inobp_check+0x73
xfs_inobp_check+0x56:   cmpl   $0x0,0x60(%ebx)
xfs_inobp_check+0x5a:   jne    xfs_inobp_check+0x73
xfs_inobp_check+0x5c:   pushl  $0xd6

void
xfs_inobp_check(
        xfs_mount_t     *mp,
        xfs_buf_t               *bp)
{
        int             i;
        int             j;
        xfs_dinode_t    *dip;

        j = mp->m_inode_cluster_size >> mp->m_sb.sb_inodelog;

        for (i = 0; i < j; i++) {
                dip = (xfs_dinode_t *)((char *)XFS_BUF_PTR(bp) +
                                       (i * mp->m_sb.sb_inodesize));
                if (INT_ISZERO(dip->di_next_unlinked, ARCH_UNKNOWN))  {
                               ^^^^^^^^^^^^^^^^^^^^^

adding a conditional printk in the while loop (before the "if")
reveals that the panic happens when i==0, mp->m_sb.sb_inodesize==256,
bp=0xc3f37800 and dip==0x00000000 (urk).

and with CONFIG_PAGE_BUF_META defined, we compile with
	#define XFS_BUF_PTR(bp) (caddr_t)((bp)->pb_addr)

so, looks like a pagebuf bug.


and on a possibly-related note, the same kernel also panics
when running the test on ext2, but in that case I get a bunch
of "Bad slab magic" errors before it falls over (also on the
close() syscall path)...

troppo.melbourne.sgi.com login: kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
Unable to handle kernel paging request at virtual address 08069e58
 printing eip:
c0135305
*pde = 013bf067
*pte = 00000000
Entering kdb (0xc2ad0000) on processor 0 Panic: Oops
due to panic @ 0xc0135305
eax = 0x08069e48 ebx = 0xc4553ee0 ecx = 0xc41a1fe0 edx = 0x08069e48 
esi = 0xc11e5be0 edi = 0xc11e5c00 esp = <kernel>   eip = 0xc0135305 
ebp = 0xc2ad1efc  ss = 0xc0166624  cs = 0x00000010 eflags = 0x00010046 
 ds = <kernel>    es = 0x00000018 origeax = 0xffffffff &regs = 0xc2ad1eb0
[0]kdb> bt
    EBP       EIP         Function(args)
0xc2ad1efc 0xc0135305  kmem_cache_free+0x159( 0xc11e5be0, 0xc41a1e40, 0xc5d794e0, 0xc41a1e40, 0xc5d794e0 )
0xc2ad1f1c 0xc015fa5b  iput+0x3db( 0xc41a1e40, 0xc1cd0a80, 0xc41a1e40, 0xc2ad1f48 )
0xc2ad1f30 0xc015ce67  dput+0xa7( 0xc5d794e0, 0xc2ad0000, 0xc1cd0a80, 0xc2ad0000 )
0xc2ad1f48 0xc014c330  __fput+0x40( 0xc1cd0a80, 0xc1cd0a80, 0xc1cd0a80, 0xc5d794e0, 0x0 )
0xc2ad1f64 0xc014c3ab  _fput+0x6f( 0xc1cd0a80, 0xc209f004, 0xc2ad0000, 0xc1cd0a80 )
0xc2ad1f7c 0xc014ac1c  filp_close+0x64( 0xc1cd0a80, 0xc209f000, 0xc2ad0000, 0x40166ba0, 0x808905c )
0xc2ad1fac 0xc014ad8b  do_close+0x163( 0x0, 0x1, 0xbfffe7e0, 0xc010a538, 0x0 )
0xc2ad1fbc 0xc014ae3a  sys_close+0xe( 0x0, 0x0, 0x4016848c, 0x40166ba0, 0x808905c )
0xc2ad1fd8 0xc010a538  system_call+0x34
[0]kdb> ps
Task Addr    Pid     Parent  [*] cpu  State    Thread   Command
0xc11fa000 00000001 00000000  0  000  stop  0xc11fa344 init
0xc5fc4000 00000002 00000001  0  000  stop  0xc5fc4344 kswapd
0xc5fc2000 00000003 00000001  0  000  stop  0xc5fc2344 kflushd
0xc5fc0000 00000004 00000001  0  000  stop  0xc5fc0344 kupdate
0xc5d0e000 00000400 00000001  0  000  stop  0xc5d0e344 portmap
0xc4450000 00000440 00000001  0  000  stop  0xc4450344 rpciod
0xc44a6000 00000441 00000001  0  000  stop  0xc44a6344 lockd
0xc4722000 00000460 00000001  0  000  stop  0xc4722344 syslogd
0xc45b0000 00000471 00000001  0  000  stop  0xc45b0344 klogd
0xc4684000 00000487 00000001  0  000  stop  0xc4684344 atd
0xc4bcc000 00000503 00000001  0  000  stop  0xc4bcc344 crond
0xc5d1a000 00000523 00000001  0  000  stop  0xc5d1a344 inetd
0xc431c000 00000558 00000001  0  000  stop  0xc431c344 rpc.rquotad
0xc46ae000 00000569 00000001  0  000  stop  0xc46ae344 rpc.mountd
0xc470c000 00000580 00000001  0  000  stop  0xc470c344 nfsd
0xc46f2000 00000581 00000001  0  000  stop  0xc46f2344 nfsd
0xc476c000 00000582 00000001  0  000  stop  0xc476c344 nfsd
0xc47aa000 00000583 00000001  0  000  stop  0xc47aa344 nfsd
0xc47a8000 00000584 00000001  0  000  stop  0xc47a8344 nfsd
0xc47b6000 00000585 00000001  0  000  stop  0xc47b6344 nfsd
0xc47b0000 00000586 00000001  0  000  stop  0xc47b0344 nfsd
0xc47d6000 00000587 00000001  0  000  stop  0xc47d6344 nfsd
[0]more> 
0xc4e34000 00000652 00000001  0  000  stop  0xc4e34344 pmcd
0xc0580000 00000664 00000652  0  000  stop  0xc0580344 pmdasimple
0xc4568000 00000672 00000652  0  000  stop  0xc4568344 pmdatrace
0xc5e74000 00000837 00000001  0  000  stop  0xc5e74344 pmlogger
0xc0556000 00000839 00000001  0  000  stop  0xc0556344 nsrexecd
0xc437e000 00000859 00000001  0  000  stop  0xc437e344 mingetty
0xc4a6e000 00000860 00000001  0  000  stop  0xc4a6e344 mingetty
0xc4a6c000 00000861 00000001  0  000  stop  0xc4a6c344 mingetty
0xc4a6a000 00000862 00000001  0  000  stop  0xc4a6a344 mingetty
0xc4a66000 00000863 00000001  0  000  stop  0xc4a66344 mingetty
0xc0546000 00000864 00000001  0  000  stop  0xc0546344 mingetty
0xc0fba000 00000865 00000001  0  000  stop  0xc0fba344 getty
0xc480a000 00000907 00000523  0  000  stop  0xc480a344 in.rlogind
0xc419a000 00000908 00000907  0  000  stop  0xc419a344 login
0xc4160000 00000909 00000908  0  000  stop  0xc4160344 tcsh
0xc4102000 00000941 00000909  0  000  stop  0xc4102344 sh
0xc5b5c000 00008851 00000941  0  000  stop  0xc5b5c344 sudo
0xc33ce000 00008852 00008851  0  000  stop  0xc33ce344 run_sendmail
0xc43cc000 00008870 00008852  0  000  stop  0xc43cc344 lpbm
0xc1d98000 00009055 00008870  0  000  stop  0xc1d98344 time
0xc481e000 00009065 00008870  0  000  stop  0xc481e344 time
0xc2dae000 00009105 00008870  0  000  stop  0xc2dae344 time
0xc0b5a000 00009107 00009105  0  000  stop  0xc0b5a344 lpbm_user_run
[0]more> 
0xc0fe4000 00009286 00000001  0  000  stop  0xc0fe4344 sendmail
0xc3b2c000 00009292 00000001  0  000  stop  0xc3b2c344 sendmail
0xc2da6000 00009294 00000001  0  000  stop  0xc2da6344 sendmail
0xc3a88000 00009299 00000001  0  000  stop  0xc3a88344 sendmail
0xc2d90000 00009317 00000001  0  000  stop  0xc2d90344 sendmail
0xc0086000 00009320 00000001  0  000  stop  0xc0086344 sendmail
0xc05b2000 00009326 00000001  0  000  stop  0xc05b2344 sendmail
0xc1cfa000 00009328 00000001  0  000  stop  0xc1cfa344 sendmail
0xc5716000 00009333 00000001  0  000  stop  0xc5716344 sendmail
0xc5092000 00009335 00000001  0  000  stop  0xc5092344 sendmail
0xc5d4e000 00009339 00000001  0  000  stop  0xc5d4e344 sendmail
0xc527e000 00009341 00000001  0  000  stop  0xc527e344 sendmail
0xc2c10000 00009347 00000001  0  000  stop  0xc2c10344 sendmail
0xc055c000 00009349 00000001  0  000  stop  0xc055c344 sendmail
0xc0ab8000 00009352 00000001  0  000  stop  0xc0ab8344 sendmail
0xc4ce6000 00009353 00000001  0  000  stop  0xc4ce6344 sendmail
0xc3dcc000 00009355 00000001  0  000  stop  0xc3dcc344 sendmail
0xc5662000 00009371 00000001  0  000  stop  0xc5662344 sendmail
0xc2460000 00009375 00000001  0  000  stop  0xc2460344 sendmail
0xc27dc000 00009379 00000001  0  000  stop  0xc27dc344 sendmail
0xc0a88000 00009380 00000001  0  000  stop  0xc0a88344 sendmail
0xc1292000 00009390 00000001  0  000  stop  0xc1292344 sendmail
0xc51a6000 00009394 00000001  0  000  stop  0xc51a6344 sendmail
[0]more> 
0xc3574000 00009396 00000001  0  000  stop  0xc3574344 sendmail
0xc165c000 00009398 00000001  0  000  stop  0xc165c344 sendmail
0xc1512000 00009400 00000001  0  000  stop  0xc1512344 sendmail
0xc2296000 00009402 00000001  0  000  stop  0xc2296344 sendmail
0xc208c000 00009404 00000001  0  000  stop  0xc208c344 sendmail
0xc3eb8000 00009406 00000001  0  000  stop  0xc3eb8344 sendmail
0xc2be6000 00009408 00000001  0  000  stop  0xc2be6344 sendmail
0xc4144000 00009410 00000001  0  000  stop  0xc4144344 sendmail
0xc5c80000 00009412 00000001  0  000  stop  0xc5c80344 sendmail
0xc254c000 00009414 00000001  0  000  stop  0xc254c344 sendmail
0xc13ba000 00009418 00000001  0  000  stop  0xc13ba344 sendmail
0xc18ea000 00009419 00000001  0  000  stop  0xc18ea344 sendmail
0xc370a000 00009438 00000001  0  000  stop  0xc370a344 sendmail
0xc42c2000 00009440 00000001  0  000  stop  0xc42c2344 sendmail
0xc42a6000 00009442 00000001  0  000  stop  0xc42a6344 sendmail
0xc0a1a000 00009444 00000001  0  000  stop  0xc0a1a344 sendmail
0xc0c7c000 00009446 00000001  0  000  stop  0xc0c7c344 sendmail
0xc56e0000 00009448 00000001  0  000  stop  0xc56e0344 sendmail
0xc3672000 00009450 00000001  0  000  stop  0xc3672344 sendmail
0xc58d8000 00009451 00000001  0  000  stop  0xc58d8344 sendmail
0xc5cf4000 00009455 00000001  0  000  stop  0xc5cf4344 sendmail
0xc42c6000 00009457 00000001  0  000  stop  0xc42c6344 sendmail
0xc4fac000 00009458 00000001  0  000  stop  0xc4fac344 sendmail
[0]more> 
0xc562c000 00009460 00000001  0  000  stop  0xc562c344 sendmail
0xc3fc8000 00009463 00000001  0  000  stop  0xc3fc8344 sendmail
0xc2656000 00009465 00000001  0  000  stop  0xc2656344 sendmail
0xc5dec000 00009466 00000001  0  000  stop  0xc5dec344 sendmail
0xc14a8000 00009469 00000001  0  000  stop  0xc14a8344 sendmail
0xc294c000 00009471 00000001  0  000  stop  0xc294c344 sendmail
0xc4c0e000 00009473 00000001  0  000  stop  0xc4c0e344 sendmail
0xc453c000 00009474 00000001  0  000  stop  0xc453c344 sendmail
0xc486a000 00009476 00000001  0  000  stop  0xc486a344 sendmail
0xc163e000 00009477 00000001  0  000  stop  0xc163e344 sendmail
0xc42e6000 00009479 00000001  0  000  stop  0xc42e6344 sendmail
0xc3188000 00009481 00000001  0  000  stop  0xc3188344 sendmail
0xc5080000 00009484 00000001  0  000  stop  0xc5080344 sendmail
0xc4946000 00009486 00000001  0  000  stop  0xc4946344 sendmail
0xc1d5c000 00009487 00000001  0  000  stop  0xc1d5c344 sendmail
0xc5d04000 00009490 00000001  0  000  stop  0xc5d04344 sendmail
0xc45de000 00009491 00000001  0  000  stop  0xc45de344 sendmail
0xc5754000 00009493 00000001  0  000  stop  0xc5754344 sendmail
0xc5140000 00009495 00000001  0  000  stop  0xc5140344 sendmail
0xc147c000 00009496 00000001  0  000  stop  0xc147c344 sendmail
0xc3354000 00009497 00000001  0  000  stop  0xc3354344 sendmail
0xc1c1a000 00009499 00000001  0  000  stop  0xc1c1a344 sendmail
0xc1b42000 00009504 00000001  0  000  stop  0xc1b42344 sendmail
[0]more> 
0xc56de000 00009505 00000001  0  000  stop  0xc56de344 sendmail
0xc5762000 00009506 00000001  0  000  stop  0xc5762344 sendmail
0xc1cca000 00009508 00000001  0  000  stop  0xc1cca344 sendmail
0xc58e8000 00009510 00000001  0  000  stop  0xc58e8344 sendmail
0xc47b8000 00009511 00000001  0  000  stop  0xc47b8344 sendmail
0xc24d6000 00009514 00000001  0  000  stop  0xc24d6344 sendmail
0xc2732000 00009517 00000001  0  000  stop  0xc2732344 sendmail
0xc379c000 00009519 00000001  0  000  stop  0xc379c344 sendmail
0xc064e000 00009522 00000001  0  000  stop  0xc064e344 sendmail
0xc2bb2000 00009523 00000001  0  000  stop  0xc2bb2344 sendmail
0xc32bc000 00009526 00000001  0  000  stop  0xc32bc344 sendmail
0xc40cc000 00009529 00000001  0  000  stop  0xc40cc344 sendmail
0xc12c0000 00009531 00000001  0  000  stop  0xc12c0344 sendmail
0xc5270000 00009533 00000001  0  000  stop  0xc5270344 sendmail
0xc1c70000 00009534 00000001  0  000  stop  0xc1c70344 sendmail
0xc14a0000 00009537 00000001  0  000  stop  0xc14a0344 sendmail
0xc1cb2000 00009539 00000001  0  000  stop  0xc1cb2344 sendmail
0xc523a000 00009540 00000001  0  000  stop  0xc523a344 sendmail
0xc16ea000 00009542 00000001  0  000  stop  0xc16ea344 sendmail
0xc1eb8000 00009544 00000001  0  000  stop  0xc1eb8344 sendmail
0xc42f8000 00009546 00000001  0  000  stop  0xc42f8344 sendmail
0xc4042000 00009549 00000001  0  000  stop  0xc4042344 sendmail
0xc4ba8000 00009551 00000001  0  000  stop  0xc4ba8344 sendmail
[0]more> 
0xc1b5c000 00009553 00000001  0  000  stop  0xc1b5c344 sendmail
0xc51f8000 00009555 00000001  0  000  stop  0xc51f8344 sendmail
0xc3e9c000 00009557 00000001  0  000  stop  0xc3e9c344 sendmail
0xc4700000 00009559 00000001  0  000  stop  0xc4700344 sendmail
0xc2a5c000 00009560 00000001  0  000  stop  0xc2a5c344 sendmail
0xc3320000 00009561 00000001  0  000  stop  0xc3320344 sendmail
0xc2fd0000 00009562 00000001  0  000  stop  0xc2fd0344 sendmail
0xc368e000 00009567 00000001  0  000  stop  0xc368e344 sendmail
0xc264c000 00009569 00000001  0  000  stop  0xc264c344 sendmail
0xc5572000 00009571 00000001  0  000  stop  0xc5572344 sendmail
0xc5998000 00009573 00000001  0  000  stop  0xc5998344 sendmail
0xc0660000 00009574 00000001  0  000  stop  0xc0660344 sendmail
0xc5a68000 00009577 00000001  0  000  stop  0xc5a68344 sendmail
0xc1d18000 00009578 00000001  0  000  stop  0xc1d18344 sendmail
0xc2766000 00009580 00000001  0  000  stop  0xc2766344 sendmail
0xc18c2000 00009583 00000001  0  000  stop  0xc18c2344 sendmail
0xc2c24000 00009585 00000001  0  000  stop  0xc2c24344 sendmail
0xc3d6a000 00009587 00000001  0  000  stop  0xc3d6a344 sendmail
0xc4020000 00009588 00000001  0  000  stop  0xc4020344 sendmail
0xc3ba0000 00009589 00000001  0  000  stop  0xc3ba0344 sendmail
0xc48b8000 00009594 00000001  0  000  stop  0xc48b8344 sendmail
0xc3476000 00009595 00000001  0  000  stop  0xc3476344 sendmail
0xc215c000 00009596 00000001  0  000  stop  0xc215c344 sendmail
[0]more> 
0xc207a000 00009598 00000001  0  000  stop  0xc207a344 sendmail
0xc5744000 00009603 00000001  0  000  stop  0xc5744344 sendmail
0xc35fc000 00009605 00000001  0  000  stop  0xc35fc344 sendmail
0xc3e58000 00009606 00000001  0  000  stop  0xc3e58344 sendmail
0xc459a000 00009608 00000001  0  000  stop  0xc459a344 sendmail
0xc309e000 00009610 00000001  0  000  stop  0xc309e344 sendmail
0xc3698000 00009612 00000001  0  000  stop  0xc3698344 sendmail
0xc433e000 00009614 00000001  0  000  stop  0xc433e344 sendmail
0xc4338000 00009615 00000001  0  000  stop  0xc4338344 sendmail
0xc4bf6000 00009618 00000001  0  000  stop  0xc4bf6344 sendmail
0xc225e000 00009619 00000001  0  000  stop  0xc225e344 sendmail
0xc1782000 00009621 00000001  0  000  stop  0xc1782344 sendmail
0xc4dac000 00009623 00000001  0  000  stop  0xc4dac344 sendmail
0xc22d4000 00009624 00000001  0  000  stop  0xc22d4344 sendmail
0xc38a4000 00009626 00000001  0  000  stop  0xc38a4344 sendmail
0xc22f6000 00009629 00000001  0  000  stop  0xc22f6344 sendmail
0xc3a34000 00009632 00000001  0  000  stop  0xc3a34344 sendmail
0xc479a000 00009633 00000001  0  000  stop  0xc479a344 sendmail
0xc1ae4000 00009636 00000001  0  000  stop  0xc1ae4344 sendmail
0xc3560000 00009638 00000001  0  000  stop  0xc3560344 sendmail
0xc4ad4000 00009639 00000001  0  000  stop  0xc4ad4344 sendmail
0xc1642000 00009641 00000001  0  000  stop  0xc1642344 sendmail
0xc1380000 00009643 00000001  0  000  stop  0xc1380344 sendmail
[0]more> 
0xc05a4000 00009646 00000001  0  000  stop  0xc05a4344 sendmail
0xc1640000 00009648 00000001  0  000  stop  0xc1640344 sendmail
0xc43d2000 00009649 00000001  0  000  stop  0xc43d2344 sendmail
0xc1b14000 00009650 00000001  0  000  stop  0xc1b14344 sendmail
0xc0acc000 00009652 00000001  0  000  stop  0xc0acc344 sendmail
0xc3b38000 00009654 00000001  0  000  stop  0xc3b38344 sendmail
0xc0d8a000 00009656 00000001  0  000  stop  0xc0d8a344 sendmail
0xc05ea000 00009657 00000001  0  000  stop  0xc05ea344 sendmail
0xc1e04000 00009660 00000001  0  000  stop  0xc1e04344 sendmail
0xc2dc2000 00009661 00000001  0  000  stop  0xc2dc2344 sendmail
0xc0ffe000 00009663 00000001  0  000  stop  0xc0ffe344 sendmail
0xc136a000 00009665 00000001  0  000  stop  0xc136a344 sendmail
0xc1978000 00009667 00000001  0  000  stop  0xc1978344 sendmail
0xc14e6000 00009669 00000001  0  000  stop  0xc14e6344 sendmail
0xc5070000 00009671 00000001  0  000  stop  0xc5070344 sendmail
0xc5684000 00009673 00000001  0  000  stop  0xc5684344 sendmail
0xc2b84000 00009675 00000001  0  000  stop  0xc2b84344 sendmail
0xc2cba000 00009677 00000001  0  000  stop  0xc2cba344 sendmail
0xc4ea4000 00009679 00000001  0  000  stop  0xc4ea4344 sendmail
0xc094c000 00009682 00000001  0  000  stop  0xc094c344 sendmail
0xc2e8e000 00009685 00000001  0  000  stop  0xc2e8e344 sendmail
0xc0566000 00009688 00000001  0  000  stop  0xc0566344 sendmail
0xc2836000 00009690 00000001  0  000  stop  0xc2836344 sendmail
[0]more> 
0xc3756000 00009691 00000001  0  000  stop  0xc3756344 sendmail
0xc3ed6000 00009693 00000001  0  000  stop  0xc3ed6344 sendmail
0xc4b8c000 00009695 00000001  0  000  stop  0xc4b8c344 sendmail
0xc2956000 00009701 00000001  0  000  stop  0xc2956344 sendmail
0xc1492000 00009702 00000001  0  000  stop  0xc1492344 sendmail
0xc54d6000 00009703 00000001  0  000  stop  0xc54d6344 sendmail
0xc2e4c000 00009704 00000001  0  000  stop  0xc2e4c344 sendmail
0xc2c52000 00009706 00000001  0  000  stop  0xc2c52344 sendmail
0xc15a4000 00009707 00000001  0  000  stop  0xc15a4344 sendmail
0xc396c000 00009710 00000001  0  000  stop  0xc396c344 sendmail
0xc1ab8000 00009712 00000001  0  000  stop  0xc1ab8344 sendmail
0xc14de000 00009715 00000001  0  000  stop  0xc14de344 sendmail
0xc583c000 00009716 00000001  0  000  stop  0xc583c344 sendmail
0xc1846000 00009717 00000001  0  000  stop  0xc1846344 sendmail
0xc5002000 00009718 00000001  0  000  stop  0xc5002344 sendmail
0xc5bf8000 00009720 00000001  0  000  stop  0xc5bf8344 sendmail
0xc160c000 00009722 00000001  0  000  stop  0xc160c344 sendmail
0xc29d2000 00009723 00000001  0  000  stop  0xc29d2344 sendmail
0xc23b6000 00009726 00000001  0  000  stop  0xc23b6344 sendmail
0xc4b86000 00009730 00000001  0  000  stop  0xc4b86344 sendmail
0xc5320000 00009732 00000001  0  000  stop  0xc5320344 sendmail
0xc07ea000 00009734 00000001  0  000  stop  0xc07ea344 sendmail
0xc31b6000 00009735 00000001  0  000  stop  0xc31b6344 sendmail
[0]more> 
0xc1be0000 00009738 00000001  0  000  stop  0xc1be0344 sendmail
0xc5ad4000 00009741 00000001  0  000  stop  0xc5ad4344 sendmail
0xc525a000 00009742 00000001  0  000  stop  0xc525a344 sendmail
0xc4536000 00009744 00000001  0  000  stop  0xc4536344 sendmail
0xc5a02000 00009747 00000001  0  000  stop  0xc5a02344 sendmail
0xc3074000 00009749 00000001  0  000  stop  0xc3074344 sendmail
0xc1f5e000 00009752 00000001  0  000  stop  0xc1f5e344 sendmail
0xc5b42000 00009758 00009107  0  000  stop  0xc5b42344 lpbm_user_run
0xc2ad0000 00009760 00000001  1  000  run   0xc2ad0344*sendmail
0xc5a3c000 00009761 00009400  0  000  run   0xc5a3c344 sendmail
0xc3cb0000 00009762 00009379  0  000  run   0xc3cb0344 sendmail
0xc5006000 00009763 00009762  0  000  stop  0xc5006344 sendmail
0xc09e8000 00009764 00009761  0  000  stop  0xc09e8344 sendmail
0xc0a0a000 00009765 00009380  0  000  run   0xc0a0a344 sendmail
0xc09e2000 00009766 00009765  0  000  stop  0xc09e2344 sendmail
0xc5470000 00009767 00009451  0  000  run   0xc5470344 sendmail
0xc3204000 00009768 00009410  0  000  run   0xc3204344 sendmail
0xc3040000 00009769 00009768  0  000  stop  0xc3040344 sendmail
0xc3946000 00009770 00009767  0  000  stop  0xc3946344 sendmail
[0]kdb> 


I haven't seen this second panic on an XFS filesystem, however.

cheers.

From owner-linux-xfs@oss.sgi.com Tue May 23 00:17:58 2000
Received:  by oss.sgi.com id <S42271AbQEWHRt>;
	Tue, 23 May 2000 00:17:49 -0700
Received: from lips.borg.umn.edu ([160.94.232.50]:30990 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S42269AbQEWHRd>;
	Tue, 23 May 2000 00:17:33 -0700
Received: from thebarn.com (nic-25-c125-118.mn.mediaone.net [24.25.125.118])
	by lips.borg.umn.edu (8.10.0/8.10.0) with ESMTP id e4N7HTO30839;
	Tue, 23 May 2000 02:17:29 -0500 (CDT)
Message-ID: <392A3088.84918B35@thebarn.com>
Date:   Tue, 23 May 2000 02:17:29 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 4.0-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     sgi.bugs.xfs@fido.engr.sgi.com
CC:     linux-xfs@oss.sgi.com
Subject: Re: BUG 791621 - panic in xfs_inobp_check
References: <200005230608.XAA26291@info.engr.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

"nathans@engr.sgi.com" wrote:

Yes this could very well be the same problem... first very high level
glance I would say you loaded the system down till kmalloc failed.
We don't do a very good job of checking to see if the allocation fails,
if it does it would leave the pb_addr field with a null pointer.

I've seen the slab magic error before, mostly when writing into areas of memory
that weren't mine at the time. I wonder if ext2 also has some merry little code
paths that don't check for failed kmallocs.

The may also be the case where the linux vfs has already free'ed an inode and
is trying to do is again. Ted's changes to the inode/vnode counts should fix that case.

> View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=791621
>
> Submitter : nathans                   Submitter Domain : engr
> Assigned Engineer : mostek            Assigned Domain : sgi.com
> Assigned Group : xfs-linux            Category : software
> Customer Reported : F                 Priority : 1
> Project : xfs-linux                   Status : open
> Description :
> I've seen this panic in the XFS code a few times now, in both
> big-endian and little-endian builds (just before Daniel's
> BE-only checkin).  Only happens under very high load (test is
> using sendmail to queue-remote/save-local mail messages to an
> xfs fs), and only happens sporadically (increased load seems
> to increase the chance of it happening).
>
> kernel is built with debug on, pagebuf meta on.
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000060
>  printing eip:
> c01c5c73
> *pde = 00000000
> Entering kdb (0xc2c6a000) on processor 0 Panic: Oops
> due to panic @ 0xc01c5c73
> eax = 0xc551dd40 ebx = 0x00000000 ecx = 0x00000008 edx = 0x00000000
> esi = 0x00000000 edi = 0x00000020 esp = <kernel>   eip = 0xc01c5c73
> ebp = 0xc2c6be10  ss = 0xc37727e4  cs = 0x00000010 eflags = 0x00010246
>  ds = <kernel>    es = 0x00000018 origeax = 0xffffffff &regs = 0xc2c6bdd0
> [0]kdb> bt
>     EBP       EIP         Function(args)
> 0xc2c6be10 0xc01c5c73  xfs_inobp_check+0x33( 0xc4a9d000, 0xc551dd40, 0xc37727e4, 0xc551d480, 0x1560 )
> 0xc2c6be78 0xc01c9395  xfs_iunlink_remove+0x5c9( 0xc37727e4, 0xc22413c0, 0xc4a9d000, 0xc22413c0, 0xc251f3b4 )
> 0xc2c6be94 0xc01c9518  xfs_ifree+0x174( 0xc37727e4, 0xc22413c0, 0xc0394400, 0x0, 0xc251f3b4 )
> 0xc2c6bec0 0xc01eef8c  xfs_inactive+0x470( 0xc22413d8, 0x0, 0xc251f3b4, 0xc0394740, 0xc28e59c0 )
> 0xc2c6bef0 0xc0205241  vn_rele+0x13d( 0xc251f3b4, 0xc1f73100, 0xc2c6bf1c, 0xc015f6b8 )
> 0xc2c6bf00 0xc02019c7  linvfs_put_inode+0x17( 0xc1f73100, 0xc28e59c0, 0xc1f73100, 0xc28e59c0 )
> 0xc2c6bf1c 0xc015f6b8  iput+0x38( 0xc1f73100, 0xc2f9bd80, 0xc1f73100, 0xc2c6bf48 )
> 0xc2c6bf30 0xc015ce67  dput+0xa7( 0xc28e59c0, 0xc2c6a000, 0xc2f9bd80, 0xc2c6a000 )
> 0xc2c6bf48 0xc014c330  __fput+0x40( 0xc2f9bd80, 0xc2f9bd80, 0xc2f9bd80, 0xc28e59c0, 0x0 )
> 0xc2c6bf64 0xc014c3ab  _fput+0x6f( 0xc2f9bd80, 0xc24ac8e4, 0xc2c6a000, 0xc2f9bd80 )
> 0xc2c6bf7c 0xc014ac1c  filp_close+0x64( 0xc2f9bd80, 0xc24ac8e0, 0xc2c6a000, 0x80f49f0, 0x80aa7a0 )
> 0xc2c6bfac 0xc014ad8b  do_close+0x163( 0x3, 0x1, 0xbfffd650, 0xc010a538, 0x3 )
> 0xc2c6bfbc 0xc014ae3a  sys_close+0xe( 0x3, 0x0, 0x4016848c, 0x80f49f0, 0x80aa7a0 )
> 0xc2c6bfd8 0xc010a538  system_call+0x34
> [0]kdb> id xfs_inobp_check
> xfs_inobp_check:   pushl  %ebp
> xfs_inobp_check+0x1:   movl   %esp,%ebp
> xfs_inobp_check+0x3:   pushl  %edi
> xfs_inobp_check+0x4:   pushl  %esi
> xfs_inobp_check+0x5:   pushl  %ebx
> xfs_inobp_check+0x6:   movl   0x8(%ebp),%eax
> xfs_inobp_check+0x9:   xorl   %esi,%esi
> xfs_inobp_check+0xb:   movzwl 0x1aa(%eax),%edi
> xfs_inobp_check+0x12:   movzbl 0xa2(%eax),%ecx
> xfs_inobp_check+0x19:   sarl   %cl,%edi
> xfs_inobp_check+0x1b:   cmpl   %edi,%esi
> xfs_inobp_check+0x1d:   jnl    xfs_inobp_check+0x78
> xfs_inobp_check+0x1f:   nop
> xfs_inobp_check+0x20:   movl   0x8(%ebp),%eax
> xfs_inobp_check+0x23:   movzwl 0x90(%eax),%ebx
> xfs_inobp_check+0x2a:   movl   0xc(%ebp),%eax
> [0]kdb> id
> xfs_inobp_check+0x2d:   imull  %esi,%ebx
> xfs_inobp_check+0x30:   addl   0x28(%eax),%ebx
> xfs_inobp_check+0x33:   cmpl   $0x0,0x60(%ebx)
> ^^^^^^^^^^^^^^^^^^^^                ^^^^^^^^^^
> xfs_inobp_check+0x37:   jne    xfs_inobp_check+0x73
> xfs_inobp_check+0x39:   pushl  %eax
> xfs_inobp_check+0x3a:   pushl  $0xc02d3a40
> xfs_inobp_check+0x3f:   movl   0x8(%ebp),%eax
> xfs_inobp_check+0x42:   pushl  %eax
> xfs_inobp_check+0x43:   pushl  $0x1
> xfs_inobp_check+0x45:   call   xfs_fs_cmn_err
> xfs_inobp_check+0x4a:   addl   $0x10,%esp
> xfs_inobp_check+0x4d:   cmpl   $0x0,0xc03946c8
> xfs_inobp_check+0x54:   je     xfs_inobp_check+0x73
> xfs_inobp_check+0x56:   cmpl   $0x0,0x60(%ebx)
> xfs_inobp_check+0x5a:   jne    xfs_inobp_check+0x73
> xfs_inobp_check+0x5c:   pushl  $0xd6
>
> void
> xfs_inobp_check(
>         xfs_mount_t     *mp,
>         xfs_buf_t               *bp)
> {
>         int             i;
>         int             j;
>         xfs_dinode_t    *dip;
>
>         j = mp->m_inode_cluster_size >> mp->m_sb.sb_inodelog;
>
>         for (i = 0; i < j; i++) {
>                 dip = (xfs_dinode_t *)((char *)XFS_BUF_PTR(bp) +
>                                        (i * mp->m_sb.sb_inodesize));
>                 if (INT_ISZERO(dip->di_next_unlinked, ARCH_UNKNOWN))  {
>                                ^^^^^^^^^^^^^^^^^^^^^
>
> adding a conditional printk in the while loop (before the "if")
> reveals that the panic happens when i==0, mp->m_sb.sb_inodesize==256,
> bp=0xc3f37800 and dip==0x00000000 (urk).
>
> and with CONFIG_PAGE_BUF_META defined, we compile with
>         #define XFS_BUF_PTR(bp) (caddr_t)((bp)->pb_addr)
>
> so, looks like a pagebuf bug.
>
> and on a possibly-related note, the same kernel also panics
> when running the test on ext2, but in that case I get a bunch
> of "Bad slab magic" errors before it falls over (also on the
> close() syscall path)...
>
> troppo.melbourne.sgi.com login: kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> Unable to handle kernel paging request at virtual address 08069e58
>  printing eip:
> c0135305
> *pde = 013bf067
> *pte = 00000000
> Entering kdb (0xc2ad0000) on processor 0 Panic: Oops
> due to panic @ 0xc0135305
> eax = 0x08069e48 ebx = 0xc4553ee0 ecx = 0xc41a1fe0 edx = 0x08069e48
> esi = 0xc11e5be0 edi = 0xc11e5c00 esp = <kernel>   eip = 0xc0135305
> ebp = 0xc2ad1efc  ss = 0xc0166624  cs = 0x00000010 eflags = 0x00010046
>  ds = <kernel>    es = 0x00000018 origeax = 0xffffffff &regs = 0xc2ad1eb0
> [0]kdb> bt
>     EBP       EIP         Function(args)
> 0xc2ad1efc 0xc0135305  kmem_cache_free+0x159( 0xc11e5be0, 0xc41a1e40, 0xc5d794e0, 0xc41a1e40, 0xc5d794e0 )
> 0xc2ad1f1c 0xc015fa5b  iput+0x3db( 0xc41a1e40, 0xc1cd0a80, 0xc41a1e40, 0xc2ad1f48 )
> 0xc2ad1f30 0xc015ce67  dput+0xa7( 0xc5d794e0, 0xc2ad0000, 0xc1cd0a80, 0xc2ad0000 )
> 0xc2ad1f48 0xc014c330  __fput+0x40( 0xc1cd0a80, 0xc1cd0a80, 0xc1cd0a80, 0xc5d794e0, 0x0 )
> 0xc2ad1f64 0xc014c3ab  _fput+0x6f( 0xc1cd0a80, 0xc209f004, 0xc2ad0000, 0xc1cd0a80 )
> 0xc2ad1f7c 0xc014ac1c  filp_close+0x64( 0xc1cd0a80, 0xc209f000, 0xc2ad0000, 0x40166ba0, 0x808905c )
> 0xc2ad1fac 0xc014ad8b  do_close+0x163( 0x0, 0x1, 0xbfffe7e0, 0xc010a538, 0x0 )
> 0xc2ad1fbc 0xc014ae3a  sys_close+0xe( 0x0, 0x0, 0x4016848c, 0x40166ba0, 0x808905c )
> 0xc2ad1fd8 0xc010a538  system_call+0x34
> [0]kdb> ps
> Task Addr    Pid     Parent  [*] cpu  State    Thread   Command
> 0xc11fa000 00000001 00000000  0  000  stop  0xc11fa344 init
> 0xc5fc4000 00000002 00000001  0  000  stop  0xc5fc4344 kswapd
> 0xc5fc2000 00000003 00000001  0  000  stop  0xc5fc2344 kflushd
> 0xc5fc0000 00000004 00000001  0  000  stop  0xc5fc0344 kupdate
> 0xc5d0e000 00000400 00000001  0  000  stop  0xc5d0e344 portmap
> 0xc4450000 00000440 00000001  0  000  stop  0xc4450344 rpciod
> 0xc44a6000 00000441 00000001  0  000  stop  0xc44a6344 lockd
> 0xc4722000 00000460 00000001  0  000  stop  0xc4722344 syslogd
> 0xc45b0000 00000471 00000001  0  000  stop  0xc45b0344 klogd
> 0xc4684000 00000487 00000001  0  000  stop  0xc4684344 atd
> 0xc4bcc000 00000503 00000001  0  000  stop  0xc4bcc344 crond
> 0xc5d1a000 00000523 00000001  0  000  stop  0xc5d1a344 inetd
> 0xc431c000 00000558 00000001  0  000  stop  0xc431c344 rpc.rquotad
> 0xc46ae000 00000569 00000001  0  000  stop  0xc46ae344 rpc.mountd
> 0xc470c000 00000580 00000001  0  000  stop  0xc470c344 nfsd
> 0xc46f2000 00000581 00000001  0  000  stop  0xc46f2344 nfsd
> 0xc476c000 00000582 00000001  0  000  stop  0xc476c344 nfsd
> 0xc47aa000 00000583 00000001  0  000  stop  0xc47aa344 nfsd
> 0xc47a8000 00000584 00000001  0  000  stop  0xc47a8344 nfsd
> 0xc47b6000 00000585 00000001  0  000  stop  0xc47b6344 nfsd
> 0xc47b0000 00000586 00000001  0  000  stop  0xc47b0344 nfsd
> 0xc47d6000 00000587 00000001  0  000  stop  0xc47d6344 nfsd
> [0]more>
> 0xc4e34000 00000652 00000001  0  000  stop  0xc4e34344 pmcd
> 0xc0580000 00000664 00000652  0  000  stop  0xc0580344 pmdasimple
> 0xc4568000 00000672 00000652  0  000  stop  0xc4568344 pmdatrace
> 0xc5e74000 00000837 00000001  0  000  stop  0xc5e74344 pmlogger
> 0xc0556000 00000839 00000001  0  000  stop  0xc0556344 nsrexecd
> 0xc437e000 00000859 00000001  0  000  stop  0xc437e344 mingetty
> 0xc4a6e000 00000860 00000001  0  000  stop  0xc4a6e344 mingetty
> 0xc4a6c000 00000861 00000001  0  000  stop  0xc4a6c344 mingetty
> 0xc4a6a000 00000862 00000001  0  000  stop  0xc4a6a344 mingetty
> 0xc4a66000 00000863 00000001  0  000  stop  0xc4a66344 mingetty
> 0xc0546000 00000864 00000001  0  000  stop  0xc0546344 mingetty
> 0xc0fba000 00000865 00000001  0  000  stop  0xc0fba344 getty
> 0xc480a000 00000907 00000523  0  000  stop  0xc480a344 in.rlogind
> 0xc419a000 00000908 00000907  0  000  stop  0xc419a344 login
> 0xc4160000 00000909 00000908  0  000  stop  0xc4160344 tcsh
> 0xc4102000 00000941 00000909  0  000  stop  0xc4102344 sh
> 0xc5b5c000 00008851 00000941  0  000  stop  0xc5b5c344 sudo
> 0xc33ce000 00008852 00008851  0  000  stop  0xc33ce344 run_sendmail
> 0xc43cc000 00008870 00008852  0  000  stop  0xc43cc344 lpbm
> 0xc1d98000 00009055 00008870  0  000  stop  0xc1d98344 time
> 0xc481e000 00009065 00008870  0  000  stop  0xc481e344 time
> 0xc2dae000 00009105 00008870  0  000  stop  0xc2dae344 time
> 0xc0b5a000 00009107 00009105  0  000  stop  0xc0b5a344 lpbm_user_run
> [0]more>
> 0xc0fe4000 00009286 00000001  0  000  stop  0xc0fe4344 sendmail
> 0xc3b2c000 00009292 00000001  0  000  stop  0xc3b2c344 sendmail
> 0xc2da6000 00009294 00000001  0  000  stop  0xc2da6344 sendmail
> 0xc3a88000 00009299 00000001  0  000  stop  0xc3a88344 sendmail
> 0xc2d90000 00009317 00000001  0  000  stop  0xc2d90344 sendmail
> 0xc0086000 00009320 00000001  0  000  stop  0xc0086344 sendmail
> 0xc05b2000 00009326 00000001  0  000  stop  0xc05b2344 sendmail
> 0xc1cfa000 00009328 00000001  0  000  stop  0xc1cfa344 sendmail
> 0xc5716000 00009333 00000001  0  000  stop  0xc5716344 sendmail
> 0xc5092000 00009335 00000001  0  000  stop  0xc5092344 sendmail
> 0xc5d4e000 00009339 00000001  0  000  stop  0xc5d4e344 sendmail
> 0xc527e000 00009341 00000001  0  000  stop  0xc527e344 sendmail
> 0xc2c10000 00009347 00000001  0  000  stop  0xc2c10344 sendmail
> 0xc055c000 00009349 00000001  0  000  stop  0xc055c344 sendmail
> 0xc0ab8000 00009352 00000001  0  000  stop  0xc0ab8344 sendmail
> 0xc4ce6000 00009353 00000001  0  000  stop  0xc4ce6344 sendmail
> 0xc3dcc000 00009355 00000001  0  000  stop  0xc3dcc344 sendmail
> 0xc5662000 00009371 00000001  0  000  stop  0xc5662344 sendmail
> 0xc2460000 00009375 00000001  0  000  stop  0xc2460344 sendmail
> 0xc27dc000 00009379 00000001  0  000  stop  0xc27dc344 sendmail
> 0xc0a88000 00009380 00000001  0  000  stop  0xc0a88344 sendmail
> 0xc1292000 00009390 00000001  0  000  stop  0xc1292344 sendmail
> 0xc51a6000 00009394 00000001  0  000  stop  0xc51a6344 sendmail
> [0]more>
> 0xc3574000 00009396 00000001  0  000  stop  0xc3574344 sendmail
> 0xc165c000 00009398 00000001  0  000  stop  0xc165c344 sendmail
> 0xc1512000 00009400 00000001  0  000  stop  0xc1512344 sendmail
> 0xc2296000 00009402 00000001  0  000  stop  0xc2296344 sendmail
> 0xc208c000 00009404 00000001  0  000  stop  0xc208c344 sendmail
> 0xc3eb8000 00009406 00000001  0  000  stop  0xc3eb8344 sendmail
> 0xc2be6000 00009408 00000001  0  000  stop  0xc2be6344 sendmail
> 0xc4144000 00009410 00000001  0  000  stop  0xc4144344 sendmail
> 0xc5c80000 00009412 00000001  0  000  stop  0xc5c80344 sendmail
> 0xc254c000 00009414 00000001  0  000  stop  0xc254c344 sendmail
> 0xc13ba000 00009418 00000001  0  000  stop  0xc13ba344 sendmail
> 0xc18ea000 00009419 00000001  0  000  stop  0xc18ea344 sendmail
> 0xc370a000 00009438 00000001  0  000  stop  0xc370a344 sendmail
> 0xc42c2000 00009440 00000001  0  000  stop  0xc42c2344 sendmail
> 0xc42a6000 00009442 00000001  0  000  stop  0xc42a6344 sendmail
> 0xc0a1a000 00009444 00000001  0  000  stop  0xc0a1a344 sendmail
> 0xc0c7c000 00009446 00000001  0  000  stop  0xc0c7c344 sendmail
> 0xc56e0000 00009448 00000001  0  000  stop  0xc56e0344 sendmail
> 0xc3672000 00009450 00000001  0  000  stop  0xc3672344 sendmail
> 0xc58d8000 00009451 00000001  0  000  stop  0xc58d8344 sendmail
> 0xc5cf4000 00009455 00000001  0  000  stop  0xc5cf4344 sendmail
> 0xc42c6000 00009457 00000001  0  000  stop  0xc42c6344 sendmail
> 0xc4fac000 00009458 00000001  0  000  stop  0xc4fac344 sendmail
> [0]more>
> 0xc562c000 00009460 00000001  0  000  stop  0xc562c344 sendmail
> 0xc3fc8000 00009463 00000001  0  000  stop  0xc3fc8344 sendmail
> 0xc2656000 00009465 00000001  0  000  stop  0xc2656344 sendmail
> 0xc5dec000 00009466 00000001  0  000  stop  0xc5dec344 sendmail
> 0xc14a8000 00009469 00000001  0  000  stop  0xc14a8344 sendmail
> 0xc294c000 00009471 00000001  0  000  stop  0xc294c344 sendmail
> 0xc4c0e000 00009473 00000001  0  000  stop  0xc4c0e344 sendmail
> 0xc453c000 00009474 00000001  0  000  stop  0xc453c344 sendmail
> 0xc486a000 00009476 00000001  0  000  stop  0xc486a344 sendmail
> 0xc163e000 00009477 00000001  0  000  stop  0xc163e344 sendmail
> 0xc42e6000 00009479 00000001  0  000  stop  0xc42e6344 sendmail
> 0xc3188000 00009481 00000001  0  000  stop  0xc3188344 sendmail
> 0xc5080000 00009484 00000001  0  000  stop  0xc5080344 sendmail
> 0xc4946000 00009486 00000001  0  000  stop  0xc4946344 sendmail
> 0xc1d5c000 00009487 00000001  0  000  stop  0xc1d5c344 sendmail
> 0xc5d04000 00009490 00000001  0  000  stop  0xc5d04344 sendmail
> 0xc45de000 00009491 00000001  0  000  stop  0xc45de344 sendmail
> 0xc5754000 00009493 00000001  0  000  stop  0xc5754344 sendmail
> 0xc5140000 00009495 00000001  0  000  stop  0xc5140344 sendmail
> 0xc147c000 00009496 00000001  0  000  stop  0xc147c344 sendmail
> 0xc3354000 00009497 00000001  0  000  stop  0xc3354344 sendmail
> 0xc1c1a000 00009499 00000001  0  000  stop  0xc1c1a344 sendmail
> 0xc1b42000 00009504 00000001  0  000  stop  0xc1b42344 sendmail
> [0]more>
> 0xc56de000 00009505 00000001  0  000  stop  0xc56de344 sendmail
> 0xc5762000 00009506 00000001  0  000  stop  0xc5762344 sendmail
> 0xc1cca000 00009508 00000001  0  000  stop  0xc1cca344 sendmail
> 0xc58e8000 00009510 00000001  0  000  stop  0xc58e8344 sendmail
> 0xc47b8000 00009511 00000001  0  000  stop  0xc47b8344 sendmail
> 0xc24d6000 00009514 00000001  0  000  stop  0xc24d6344 sendmail
> 0xc2732000 00009517 00000001  0  000  stop  0xc2732344 sendmail
> 0xc379c000 00009519 00000001  0  000  stop  0xc379c344 sendmail
> 0xc064e000 00009522 00000001  0  000  stop  0xc064e344 sendmail
> 0xc2bb2000 00009523 00000001  0  000  stop  0xc2bb2344 sendmail
> 0xc32bc000 00009526 00000001  0  000  stop  0xc32bc344 sendmail
> 0xc40cc000 00009529 00000001  0  000  stop  0xc40cc344 sendmail
> 0xc12c0000 00009531 00000001  0  000  stop  0xc12c0344 sendmail
> 0xc5270000 00009533 00000001  0  000  stop  0xc5270344 sendmail
> 0xc1c70000 00009534 00000001  0  000  stop  0xc1c70344 sendmail
> 0xc14a0000 00009537 00000001  0  000  stop  0xc14a0344 sendmail
> 0xc1cb2000 00009539 00000001  0  000  stop  0xc1cb2344 sendmail
> 0xc523a000 00009540 00000001  0  000  stop  0xc523a344 sendmail
> 0xc16ea000 00009542 00000001  0  000  stop  0xc16ea344 sendmail
> 0xc1eb8000 00009544 00000001  0  000  stop  0xc1eb8344 sendmail
> 0xc42f8000 00009546 00000001  0  000  stop  0xc42f8344 sendmail
> 0xc4042000 00009549 00000001  0  000  stop  0xc4042344 sendmail
> 0xc4ba8000 00009551 00000001  0  000  stop  0xc4ba8344 sendmail
> [0]more>
> 0xc1b5c000 00009553 00000001  0  000  stop  0xc1b5c344 sendmail
> 0xc51f8000 00009555 00000001  0  000  stop  0xc51f8344 sendmail
> 0xc3e9c000 00009557 00000001  0  000  stop  0xc3e9c344 sendmail
> 0xc4700000 00009559 00000001  0  000  stop  0xc4700344 sendmail
> 0xc2a5c000 00009560 00000001  0  000  stop  0xc2a5c344 sendmail
> 0xc3320000 00009561 00000001  0  000  stop  0xc3320344 sendmail
> 0xc2fd0000 00009562 00000001  0  000  stop  0xc2fd0344 sendmail
> 0xc368e000 00009567 00000001  0  000  stop  0xc368e344 sendmail
> 0xc264c000 00009569 00000001  0  000  stop  0xc264c344 sendmail
> 0xc5572000 00009571 00000001  0  000  stop  0xc5572344 sendmail
> 0xc5998000 00009573 00000001  0  000  stop  0xc5998344 sendmail
> 0xc0660000 00009574 00000001  0  000  stop  0xc0660344 sendmail
> 0xc5a68000 00009577 00000001  0  000  stop  0xc5a68344 sendmail
> 0xc1d18000 00009578 00000001  0  000  stop  0xc1d18344 sendmail
> 0xc2766000 00009580 00000001  0  000  stop  0xc2766344 sendmail
> 0xc18c2000 00009583 00000001  0  000  stop  0xc18c2344 sendmail
> 0xc2c24000 00009585 00000001  0  000  stop  0xc2c24344 sendmail
> 0xc3d6a000 00009587 00000001  0  000  stop  0xc3d6a344 sendmail
> 0xc4020000 00009588 00000001  0  000  stop  0xc4020344 sendmail
> 0xc3ba0000 00009589 00000001  0  000  stop  0xc3ba0344 sendmail
> 0xc48b8000 00009594 00000001  0  000  stop  0xc48b8344 sendmail
> 0xc3476000 00009595 00000001  0  000  stop  0xc3476344 sendmail
> 0xc215c000 00009596 00000001  0  000  stop  0xc215c344 sendmail
> [0]more>
> 0xc207a000 00009598 00000001  0  000  stop  0xc207a344 sendmail
> 0xc5744000 00009603 00000001  0  000  stop  0xc5744344 sendmail
> 0xc35fc000 00009605 00000001  0  000  stop  0xc35fc344 sendmail
> 0xc3e58000 00009606 00000001  0  000  stop  0xc3e58344 sendmail
> 0xc459a000 00009608 00000001  0  000  stop  0xc459a344 sendmail
> 0xc309e000 00009610 00000001  0  000  stop  0xc309e344 sendmail
> 0xc3698000 00009612 00000001  0  000  stop  0xc3698344 sendmail
> 0xc433e000 00009614 00000001  0  000  stop  0xc433e344 sendmail
> 0xc4338000 00009615 00000001  0  000  stop  0xc4338344 sendmail
> 0xc4bf6000 00009618 00000001  0  000  stop  0xc4bf6344 sendmail
> 0xc225e000 00009619 00000001  0  000  stop  0xc225e344 sendmail
> 0xc1782000 00009621 00000001  0  000  stop  0xc1782344 sendmail
> 0xc4dac000 00009623 00000001  0  000  stop  0xc4dac344 sendmail
> 0xc22d4000 00009624 00000001  0  000  stop  0xc22d4344 sendmail
> 0xc38a4000 00009626 00000001  0  000  stop  0xc38a4344 sendmail
> 0xc22f6000 00009629 00000001  0  000  stop  0xc22f6344 sendmail
> 0xc3a34000 00009632 00000001  0  000  stop  0xc3a34344 sendmail
> 0xc479a000 00009633 00000001  0  000  stop  0xc479a344 sendmail
> 0xc1ae4000 00009636 00000001  0  000  stop  0xc1ae4344 sendmail
> 0xc3560000 00009638 00000001  0  000  stop  0xc3560344 sendmail
> 0xc4ad4000 00009639 00000001  0  000  stop  0xc4ad4344 sendmail
> 0xc1642000 00009641 00000001  0  000  stop  0xc1642344 sendmail
> 0xc1380000 00009643 00000001  0  000  stop  0xc1380344 sendmail
> [0]more>
> 0xc05a4000 00009646 00000001  0  000  stop  0xc05a4344 sendmail
> 0xc1640000 00009648 00000001  0  000  stop  0xc1640344 sendmail
> 0xc43d2000 00009649 00000001  0  000  stop  0xc43d2344 sendmail
> 0xc1b14000 00009650 00000001  0  000  stop  0xc1b14344 sendmail
> 0xc0acc000 00009652 00000001  0  000  stop  0xc0acc344 sendmail
> 0xc3b38000 00009654 00000001  0  000  stop  0xc3b38344 sendmail
> 0xc0d8a000 00009656 00000001  0  000  stop  0xc0d8a344 sendmail
> 0xc05ea000 00009657 00000001  0  000  stop  0xc05ea344 sendmail
> 0xc1e04000 00009660 00000001  0  000  stop  0xc1e04344 sendmail
> 0xc2dc2000 00009661 00000001  0  000  stop  0xc2dc2344 sendmail
> 0xc0ffe000 00009663 00000001  0  000  stop  0xc0ffe344 sendmail
> 0xc136a000 00009665 00000001  0  000  stop  0xc136a344 sendmail
> 0xc1978000 00009667 00000001  0  000  stop  0xc1978344 sendmail
> 0xc14e6000 00009669 00000001  0  000  stop  0xc14e6344 sendmail
> 0xc5070000 00009671 00000001  0  000  stop  0xc5070344 sendmail
> 0xc5684000 00009673 00000001  0  000  stop  0xc5684344 sendmail
> 0xc2b84000 00009675 00000001  0  000  stop  0xc2b84344 sendmail
> 0xc2cba000 00009677 00000001  0  000  stop  0xc2cba344 sendmail
> 0xc4ea4000 00009679 00000001  0  000  stop  0xc4ea4344 sendmail
> 0xc094c000 00009682 00000001  0  000  stop  0xc094c344 sendmail
> 0xc2e8e000 00009685 00000001  0  000  stop  0xc2e8e344 sendmail
> 0xc0566000 00009688 00000001  0  000  stop  0xc0566344 sendmail
> 0xc2836000 00009690 00000001  0  000  stop  0xc2836344 sendmail
> [0]more>
> 0xc3756000 00009691 00000001  0  000  stop  0xc3756344 sendmail
> 0xc3ed6000 00009693 00000001  0  000  stop  0xc3ed6344 sendmail
> 0xc4b8c000 00009695 00000001  0  000  stop  0xc4b8c344 sendmail
> 0xc2956000 00009701 00000001  0  000  stop  0xc2956344 sendmail
> 0xc1492000 00009702 00000001  0  000  stop  0xc1492344 sendmail
> 0xc54d6000 00009703 00000001  0  000  stop  0xc54d6344 sendmail
> 0xc2e4c000 00009704 00000001  0  000  stop  0xc2e4c344 sendmail
> 0xc2c52000 00009706 00000001  0  000  stop  0xc2c52344 sendmail
> 0xc15a4000 00009707 00000001  0  000  stop  0xc15a4344 sendmail
> 0xc396c000 00009710 00000001  0  000  stop  0xc396c344 sendmail
> 0xc1ab8000 00009712 00000001  0  000  stop  0xc1ab8344 sendmail
> 0xc14de000 00009715 00000001  0  000  stop  0xc14de344 sendmail
> 0xc583c000 00009716 00000001  0  000  stop  0xc583c344 sendmail
> 0xc1846000 00009717 00000001  0  000  stop  0xc1846344 sendmail
> 0xc5002000 00009718 00000001  0  000  stop  0xc5002344 sendmail
> 0xc5bf8000 00009720 00000001  0  000  stop  0xc5bf8344 sendmail
> 0xc160c000 00009722 00000001  0  000  stop  0xc160c344 sendmail
> 0xc29d2000 00009723 00000001  0  000  stop  0xc29d2344 sendmail
> 0xc23b6000 00009726 00000001  0  000  stop  0xc23b6344 sendmail
> 0xc4b86000 00009730 00000001  0  000  stop  0xc4b86344 sendmail
> 0xc5320000 00009732 00000001  0  000  stop  0xc5320344 sendmail
> 0xc07ea000 00009734 00000001  0  000  stop  0xc07ea344 sendmail
> 0xc31b6000 00009735 00000001  0  000  stop  0xc31b6344 sendmail
> [0]more>
> 0xc1be0000 00009738 00000001  0  000  stop  0xc1be0344 sendmail
> 0xc5ad4000 00009741 00000001  0  000  stop  0xc5ad4344 sendmail
> 0xc525a000 00009742 00000001  0  000  stop  0xc525a344 sendmail
> 0xc4536000 00009744 00000001  0  000  stop  0xc4536344 sendmail
> 0xc5a02000 00009747 00000001  0  000  stop  0xc5a02344 sendmail
> 0xc3074000 00009749 00000001  0  000  stop  0xc3074344 sendmail
> 0xc1f5e000 00009752 00000001  0  000  stop  0xc1f5e344 sendmail
> 0xc5b42000 00009758 00009107  0  000  stop  0xc5b42344 lpbm_user_run
> 0xc2ad0000 00009760 00000001  1  000  run   0xc2ad0344*sendmail
> 0xc5a3c000 00009761 00009400  0  000  run   0xc5a3c344 sendmail
> 0xc3cb0000 00009762 00009379  0  000  run   0xc3cb0344 sendmail
> 0xc5006000 00009763 00009762  0  000  stop  0xc5006344 sendmail
> 0xc09e8000 00009764 00009761  0  000  stop  0xc09e8344 sendmail
> 0xc0a0a000 00009765 00009380  0  000  run   0xc0a0a344 sendmail
> 0xc09e2000 00009766 00009765  0  000  stop  0xc09e2344 sendmail
> 0xc5470000 00009767 00009451  0  000  run   0xc5470344 sendmail
> 0xc3204000 00009768 00009410  0  000  run   0xc3204344 sendmail
> 0xc3040000 00009769 00009768  0  000  stop  0xc3040344 sendmail
> 0xc3946000 00009770 00009767  0  000  stop  0xc3946344 sendmail
> [0]kdb>
>
> I haven't seen this second panic on an XFS filesystem, however.
>
> cheers.

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue May 23 00:21:58 2000
Received:  by oss.sgi.com id <S42272AbQEWHVj>;
	Tue, 23 May 2000 00:21:39 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:64847 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42269AbQEWHVa>;
	Tue, 23 May 2000 00:21:30 -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 AAA12964; Tue, 23 May 2000 00:16:38 -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 AAA06033; Tue, 23 May 2000 00:20:06 -0700 (PDT)
Date:   Tue, 23 May 2000 00:20:06 -0700 (PDT)
Message-Id: <200005230720.AAA06033@feature.engr.sgi.com>
X-Pv-Incident: 791621 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (cattelan@thebarn.com)
Subject: ADD 791621 - panic in xfs_inobp_check
To:     mostek@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 : mostek            Priority : 1                         
*Modified Date : 05/23/00             *Modified User : cattelan             
*Modified User Domain : thebarn.com   *Description :
I've seen this panic in the XFS code a few times now, in both
big-endian and little-endian builds (just before Daniel's
BE-only checkin).  Only happens under very high load (test is
using sendmail to queue-remote/save-local mail messages to an
xfs fs), and only happens sporadically (increased load seems
to increase the chance of it happening).

kernel is built with debug on, pagebuf meta on.



.....


==========================
ADDITIONAL INFORMATION (ADD)
From: russell cattelan <cattelan@thebarn.com>
Date: May 23 2000 12:20:05AM
[pvnews version: 1.71]
==========================
"nathans@engr.sgi.com" wrote:

Yes this could very well be the same problem... first very high level
glance I would say you loaded the system down till kmalloc failed.
We don't do a very good job of checking to see if the allocation fails,
if it does it would leave the pb_addr field with a null pointer.

I've seen the slab magic error before, mostly when writing into areas of memory
that weren't mine at the time. I wonder if ext2 also has some merry little code
paths that don't check for failed kmallocs.

The may also be the case where the linux vfs has already free'ed an inode and
is trying to do is again. Ted's changes to the inode/vnode counts should fix that case.

> View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=791621
>
> Submitter : nathans                   Submitter Domain : engr
> Assigned Engineer : mostek            Assigned Domain : sgi.com
> Assigned Group : xfs-linux            Category : software
> Customer Reported : F                 Priority : 1
> Project : xfs-linux                   Status : open
> Description :
> I've seen this panic in the XFS code a few times now, in both
> big-endian and little-endian builds (just before Daniel's
> BE-only checkin).  Only happens under very high load (test is
> using sendmail to queue-remote/save-local mail messages to an
> xfs fs), and only happens sporadically (increased load seems
> to increase the chance of it happening).
>
> kernel is built with debug on, pagebuf meta on.
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000060
>  printing eip:
> c01c5c73
> *pde = 00000000
> Entering kdb (0xc2c6a000) on processor 0 Panic: Oops
> due to panic @ 0xc01c5c73
> eax = 0xc551dd40 ebx = 0x00000000 ecx = 0x00000008 edx = 0x00000000
> esi = 0x00000000 edi = 0x00000020 esp = <kernel>   eip = 0xc01c5c73
> ebp = 0xc2c6be10  ss = 0xc37727e4  cs = 0x00000010 eflags = 0x00010246
>  ds = <kernel>    es = 0x00000018 origeax = 0xffffffff &regs = 0xc2c6bdd0
> [0]kdb> bt
>     EBP       EIP         Function(args)
> 0xc2c6be10 0xc01c5c73  xfs_inobp_check+0x33( 0xc4a9d000, 0xc551dd40, 0xc37727e4, 0xc551d480, 0x1560 )
> 0xc2c6be78 0xc01c9395  xfs_iunlink_remove+0x5c9( 0xc37727e4, 0xc22413c0, 0xc4a9d000, 0xc22413c0, 0xc251f3b4 )
> 0xc2c6be94 0xc01c9518  xfs_ifree+0x174( 0xc37727e4, 0xc22413c0, 0xc0394400, 0x0, 0xc251f3b4 )
> 0xc2c6bec0 0xc01eef8c  xfs_inactive+0x470( 0xc22413d8, 0x0, 0xc251f3b4, 0xc0394740, 0xc28e59c0 )
> 0xc2c6bef0 0xc0205241  vn_rele+0x13d( 0xc251f3b4, 0xc1f73100, 0xc2c6bf1c, 0xc015f6b8 )
> 0xc2c6bf00 0xc02019c7  linvfs_put_inode+0x17( 0xc1f73100, 0xc28e59c0, 0xc1f73100, 0xc28e59c0 )
> 0xc2c6bf1c 0xc015f6b8  iput+0x38( 0xc1f73100, 0xc2f9bd80, 0xc1f73100, 0xc2c6bf48 )
> 0xc2c6bf30 0xc015ce67  dput+0xa7( 0xc28e59c0, 0xc2c6a000, 0xc2f9bd80, 0xc2c6a000 )
> 0xc2c6bf48 0xc014c330  __fput+0x40( 0xc2f9bd80, 0xc2f9bd80, 0xc2f9bd80, 0xc28e59c0, 0x0 )
> 0xc2c6bf64 0xc014c3ab  _fput+0x6f( 0xc2f9bd80, 0xc24ac8e4, 0xc2c6a000, 0xc2f9bd80 )
> 0xc2c6bf7c 0xc014ac1c  filp_close+0x64( 0xc2f9bd80, 0xc24ac8e0, 0xc2c6a000, 0x80f49f0, 0x80aa7a0 )
> 0xc2c6bfac 0xc014ad8b  do_close+0x163( 0x3, 0x1, 0xbfffd650, 0xc010a538, 0x3 )
> 0xc2c6bfbc 0xc014ae3a  sys_close+0xe( 0x3, 0x0, 0x4016848c, 0x80f49f0, 0x80aa7a0 )
> 0xc2c6bfd8 0xc010a538  system_call+0x34
> [0]kdb> id xfs_inobp_check
> xfs_inobp_check:   pushl  %ebp
> xfs_inobp_check+0x1:   movl   %esp,%ebp
> xfs_inobp_check+0x3:   pushl  %edi
> xfs_inobp_check+0x4:   pushl  %esi
> xfs_inobp_check+0x5:   pushl  %ebx
> xfs_inobp_check+0x6:   movl   0x8(%ebp),%eax
> xfs_inobp_check+0x9:   xorl   %esi,%esi
> xfs_inobp_check+0xb:   movzwl 0x1aa(%eax),%edi
> xfs_inobp_check+0x12:   movzbl 0xa2(%eax),%ecx
> xfs_inobp_check+0x19:   sarl   %cl,%edi
> xfs_inobp_check+0x1b:   cmpl   %edi,%esi
> xfs_inobp_check+0x1d:   jnl    xfs_inobp_check+0x78
> xfs_inobp_check+0x1f:   nop
> xfs_inobp_check+0x20:   movl   0x8(%ebp),%eax
> xfs_inobp_check+0x23:   movzwl 0x90(%eax),%ebx
> xfs_inobp_check+0x2a:   movl   0xc(%ebp),%eax
> [0]kdb> id
> xfs_inobp_check+0x2d:   imull  %esi,%ebx
> xfs_inobp_check+0x30:   addl   0x28(%eax),%ebx
> xfs_inobp_check+0x33:   cmpl   $0x0,0x60(%ebx)
> ^^^^^^^^^^^^^^^^^^^^                ^^^^^^^^^^
> xfs_inobp_check+0x37:   jne    xfs_inobp_check+0x73
> xfs_inobp_check+0x39:   pushl  %eax
> xfs_inobp_check+0x3a:   pushl  $0xc02d3a40
> xfs_inobp_check+0x3f:   movl   0x8(%ebp),%eax
> xfs_inobp_check+0x42:   pushl  %eax
> xfs_inobp_check+0x43:   pushl  $0x1
> xfs_inobp_check+0x45:   call   xfs_fs_cmn_err
> xfs_inobp_check+0x4a:   addl   $0x10,%esp
> xfs_inobp_check+0x4d:   cmpl   $0x0,0xc03946c8
> xfs_inobp_check+0x54:   je     xfs_inobp_check+0x73
> xfs_inobp_check+0x56:   cmpl   $0x0,0x60(%ebx)
> xfs_inobp_check+0x5a:   jne    xfs_inobp_check+0x73
> xfs_inobp_check+0x5c:   pushl  $0xd6
>
> void
> xfs_inobp_check(
>         xfs_mount_t     *mp,
>         xfs_buf_t               *bp)
> {
>         int             i;
>         int             j;
>         xfs_dinode_t    *dip;
>
>         j = mp->m_inode_cluster_size >> mp->m_sb.sb_inodelog;
>
>         for (i = 0; i < j; i++) {
>                 dip = (xfs_dinode_t *)((char *)XFS_BUF_PTR(bp) +
>                                        (i * mp->m_sb.sb_inodesize));
>                 if (INT_ISZERO(dip->di_next_unlinked, ARCH_UNKNOWN))  {
>                                ^^^^^^^^^^^^^^^^^^^^^
>
> adding a conditional printk in the while loop (before the "if")
> reveals that the panic happens when i==0, mp->m_sb.sb_inodesize==256,
> bp=0xc3f37800 and dip==0x00000000 (urk).
>
> and with CONFIG_PAGE_BUF_META defined, we compile with
>         #define XFS_BUF_PTR(bp) (caddr_t)((bp)->pb_addr)
>
> so, looks like a pagebuf bug.
>
> and on a possibly-related note, the same kernel also panics
> when running the test on ext2, but in that case I get a bunch
> of "Bad slab magic" errors before it falls over (also on the
> close() syscall path)...
>
> troppo.melbourne.sgi.com login: kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> kmem_alloc: Bad slab magic (corrupt) (name=inode_cache)
> Unable to handle kernel paging request at virtual address 08069e58
>  printing eip:
> c0135305
> *pde = 013bf067
> *pte = 00000000
> Entering kdb (0xc2ad0000) on processor 0 Panic: Oops
> due to panic @ 0xc0135305
> eax = 0x08069e48 ebx = 0xc4553ee0 ecx = 0xc41a1fe0 edx = 0x08069e48
> esi = 0xc11e5be0 edi = 0xc11e5c00 esp = <kernel>   eip = 0xc0135305
> ebp = 0xc2ad1efc  ss = 0xc0166624  cs = 0x00000010 eflags = 0x00010046
>  ds = <kernel>    es = 0x00000018 origeax = 0xffffffff &regs = 0xc2ad1eb0
> [0]kdb> bt
>     EBP       EIP         Function(args)
> 0xc2ad1efc 0xc0135305  kmem_cache_free+0x159( 0xc11e5be0, 0xc41a1e40, 0xc5d794e0, 0xc41a1e40, 0xc5d794e0 )
> 0xc2ad1f1c 0xc015fa5b  iput+0x3db( 0xc41a1e40, 0xc1cd0a80, 0xc41a1e40, 0xc2ad1f48 )
> 0xc2ad1f30 0xc015ce67  dput+0xa7( 0xc5d794e0, 0xc2ad0000, 0xc1cd0a80, 0xc2ad0000 )
> 0xc2ad1f48 0xc014c330  __fput+0x40( 0xc1cd0a80, 0xc1cd0a80, 0xc1cd0a80, 0xc5d794e0, 0x0 )
> 0xc2ad1f64 0xc014c3ab  _fput+0x6f( 0xc1cd0a80, 0xc209f004, 0xc2ad0000, 0xc1cd0a80 )
> 0xc2ad1f7c 0xc014ac1c  filp_close+0x64( 0xc1cd0a80, 0xc209f000, 0xc2ad0000, 0x40166ba0, 0x808905c )
> 0xc2ad1fac 0xc014ad8b  do_close+0x163( 0x0, 0x1, 0xbfffe7e0, 0xc010a538, 0x0 )
> 0xc2ad1fbc 0xc014ae3a  sys_close+0xe( 0x0, 0x0, 0x4016848c, 0x40166ba0, 0x808905c )
> 0xc2ad1fd8 0xc010a538  system_call+0x34
> [0]kdb> ps
> Task Addr    Pid     Parent  [*] cpu  State    Thread   Command
> 0xc11fa000 00000001 00000000  0  000  stop  0xc11fa344 init
> 0xc5fc4000 00000002 00000001  0  000  stop  0xc5fc4344 kswapd
> 0xc5fc2000 00000003 00000001  0  000  stop  0xc5fc2344 kflushd
> 0xc5fc0000 00000004 00000001  0  000  stop  0xc5fc0344 kupdate
> 0xc5d0e000 00000400 00000001  0  000  stop  0xc5d0e344 portmap
> 0xc4450000 00000440 00000001  0  000  stop  0xc4450344 rpciod
> 0xc44a6000 00000441 00000001  0  000  stop  0xc44a6344 lockd
> 0xc4722000 00000460 00000001  0  000  stop  0xc4722344 syslogd
> 0xc45b0000 00000471 00000001  0  000  stop  0xc45b0344 klogd
> 0xc4684000 00000487 00000001  0  000  stop  0xc4684344 atd
> 0xc4bcc000 00000503 00000001  0  000  stop  0xc4bcc344 crond
> 0xc5d1a000 00000523 00000001  0  000  stop  0xc5d1a344 inetd
> 0xc431c000 00000558 00000001  0  000  stop  0xc431c344 rpc.rquotad
> 0xc46ae000 00000569 00000001  0  000  stop  0xc46ae344 rpc.mountd
> 0xc470c000 00000580 00000001  0  000  stop  0xc470c344 nfsd
> 0xc46f2000 00000581 00000001  0  000  stop  0xc46f2344 nfsd
> 0xc476c000 00000582 00000001  0  000  stop  0xc476c344 nfsd
> 0xc47aa000 00000583 00000001  0  000  stop  0xc47aa344 nfsd
> 0xc47a8000 00000584 00000001  0  000  stop  0xc47a8344 nfsd
> 0xc47b6000 00000585 00000001  0  000  stop  0xc47b6344 nfsd
> 0xc47b0000 00000586 00000001  0  000  stop  0xc47b0344 nfsd
> 0xc47d6000 00000587 00000001  0  000  stop  0xc47d6344 nfsd
> [0]more>
> 0xc4e34000 00000652 00000001  0  000  stop  0xc4e34344 pmcd
> 0xc0580000 00000664 00000652  0  000  stop  0xc0580344 pmdasimple
> 0xc4568000 00000672 00000652  0  000  stop  0xc4568344 pmdatrace
> 0xc5e74000 00000837 00000001  0  000  stop  0xc5e74344 pmlogger
> 0xc0556000 00000839 00000001  0  000  stop  0xc0556344 nsrexecd
> 0xc437e000 00000859 00000001  0  000  stop  0xc437e344 mingetty
> 0xc4a6e000 00000860 00000001  0  000  stop  0xc4a6e344 mingetty
> 0xc4a6c000 00000861 00000001  0  000  stop  0xc4a6c344 mingetty
> 0xc4a6a000 00000862 00000001  0  000  stop  0xc4a6a344 mingetty
> 0xc4a66000 00000863 00000001  0  000  stop  0xc4a66344 mingetty
> 0xc0546000 00000864 00000001  0  000  stop  0xc0546344 mingetty
> 0xc0fba000 00000865 00000001  0  000  stop  0xc0fba344 getty
> 0xc480a000 00000907 00000523  0  000  stop  0xc480a344 in.rlogind
> 0xc419a000 00000908 00000907  0  000  stop  0xc419a344 login
> 0xc4160000 00000909 00000908  0  000  stop  0xc4160344 tcsh
> 0xc4102000 00000941 00000909  0  000  stop  0xc4102344 sh
> 0xc5b5c000 00008851 00000941  0  000  stop  0xc5b5c344 sudo
> 0xc33ce000 00008852 00008851  0  000  stop  0xc33ce344 run_sendmail
> 0xc43cc000 00008870 00008852  0  000  stop  0xc43cc344 lpbm
> 0xc1d98000 00009055 00008870  0  000  stop  0xc1d98344 time
> 0xc481e000 00009065 00008870  0  000  stop  0xc481e344 time
> 0xc2dae000 00009105 00008870  0  000  stop  0xc2dae344 time
> 0xc0b5a000 00009107 00009105  0  000  stop  0xc0b5a344 lpbm_user_run
> [0]more>
> 0xc0fe4000 00009286 00000001  0  000  stop  0xc0fe4344 sendmail
> 0xc3b2c000 00009292 00000001  0  000  stop  0xc3b2c344 sendmail
> 0xc2da6000 00009294 00000001  0  000  stop  0xc2da6344 sendmail
> 0xc3a88000 00009299 00000001  0  000  stop  0xc3a88344 sendmail
> 0xc2d90000 00009317 00000001  0  000  stop  0xc2d90344 sendmail
> 0xc0086000 00009320 00000001  0  000  stop  0xc0086344 sendmail
> 0xc05b2000 00009326 00000001  0  000  stop  0xc05b2344 sendmail
> 0xc1cfa000 00009328 00000001  0  000  stop  0xc1cfa344 sendmail
> 0xc5716000 00009333 00000001  0  000  stop  0xc5716344 sendmail
> 0xc5092000 00009335 00000001  0  000  stop  0xc5092344 sendmail
> 0xc5d4e000 00009339 00000001  0  000  stop  0xc5d4e344 sendmail
> 0xc527e000 00009341 00000001  0  000  stop  0xc527e344 sendmail
> 0xc2c10000 00009347 00000001  0  000  stop  0xc2c10344 sendmail
> 0xc055c000 00009349 00000001  0  000  stop  0xc055c344 sendmail
> 0xc0ab8000 00009352 00000001  0  000  stop  0xc0ab8344 sendmail
> 0xc4ce6000 00009353 00000001  0  000  stop  0xc4ce6344 sendmail
> 0xc3dcc000 00009355 00000001  0  000  stop  0xc3dcc344 sendmail
> 0xc5662000 00009371 00000001  0  000  stop  0xc5662344 sendmail
> 0xc2460000 00009375 00000001  0  000  stop  0xc2460344 sendmail
> 0xc27dc000 00009379 00000001  0  000  stop  0xc27dc344 sendmail
> 0xc0a88000 00009380 00000001  0  000  stop  0xc0a88344 sendmail
> 0xc1292000 00009390 00000001  0  000  stop  0xc1292344 sendmail
> 0xc51a6000 00009394 00000001  0  000  stop  0xc51a6344 sendmail
> [0]more>
> 0xc3574000 00009396 00000001  0  000  stop  0xc3574344 sendmail
> 0xc165c000 00009398 00000001  0  000  stop  0xc165c344 sendmail
> 0xc1512000 00009400 00000001  0  000  stop  0xc1512344 sendmail
> 0xc2296000 00009402 00000001  0  000  stop  0xc2296344 sendmail
> 0xc208c000 00009404 00000001  0  000  stop  0xc208c344 sendmail
> 0xc3eb8000 00009406 00000001  0  000  stop  0xc3eb8344 sendmail
> 0xc2be6000 00009408 00000001  0  000  stop  0xc2be6344 sendmail
> 0xc4144000 00009410 00000001  0  000  stop  0xc4144344 sendmail
> 0xc5c80000 00009412 00000001  0  000  stop  0xc5c80344 sendmail
> 0xc254c000 00009414 00000001  0  000  stop  0xc254c344 sendmail
> 0xc13ba000 00009418 00000001  0  000  stop  0xc13ba344 sendmail
> 0xc18ea000 00009419 00000001  0  000  stop  0xc18ea344 sendmail
> 0xc370a000 00009438 00000001  0  000  stop  0xc370a344 sendmail
> 0xc42c2000 00009440 00000001  0  000  stop  0xc42c2344 sendmail
> 0xc42a6000 00009442 00000001  0  000  stop  0xc42a6344 sendmail
> 0xc0a1a000 00009444 00000001  0  000  stop  0xc0a1a344 sendmail
> 0xc0c7c000 00009446 00000001  0  000  stop  0xc0c7c344 sendmail
> 0xc56e0000 00009448 00000001  0  000  stop  0xc56e0344 sendmail
> 0xc3672000 00009450 00000001  0  000  stop  0xc3672344 sendmail
> 0xc58d8000 00009451 00000001  0  000  stop  0xc58d8344 sendmail
> 0xc5cf4000 00009455 00000001  0  000  stop  0xc5cf4344 sendmail
> 0xc42c6000 00009457 00000001  0  000  stop  0xc42c6344 sendmail
> 0xc4fac000 00009458 00000001  0  000  stop  0xc4fac344 sendmail
> [0]more>
> 0xc562c000 00009460 00000001  0  000  stop  0xc562c344 sendmail
> 0xc3fc8000 00009463 00000001  0  000  stop  0xc3fc8344 sendmail
> 0xc2656000 00009465 00000001  0  000  stop  0xc2656344 sendmail
> 0xc5dec000 00009466 00000001  0  000  stop  0xc5dec344 sendmail
> 0xc14a8000 00009469 00000001  0  000  stop  0xc14a8344 sendmail
> 0xc294c000 00009471 00000001  0  000  stop  0xc294c344 sendmail
> 0xc4c0e000 00009473 00000001  0  000  stop  0xc4c0e344 sendmail
> 0xc453c000 00009474 00000001  0  000  stop  0xc453c344 sendmail
> 0xc486a000 00009476 00000001  0  000  stop  0xc486a344 sendmail
> 0xc163e000 00009477 00000001  0  000  stop  0xc163e344 sendmail
> 0xc42e6000 00009479 00000001  0  000  stop  0xc42e6344 sendmail
> 0xc3188000 00009481 00000001  0  000  stop  0xc3188344 sendmail
> 0xc5080000 00009484 00000001  0  000  stop  0xc5080344 sendmail
> 0xc4946000 00009486 00000001  0  000  stop  0xc4946344 sendmail
> 0xc1d5c000 00009487 00000001  0  000  stop  0xc1d5c344 sendmail
> 0xc5d04000 00009490 00000001  0  000  stop  0xc5d04344 sendmail
> 0xc45de000 00009491 00000001  0  000  stop  0xc45de344 sendmail
> 0xc5754000 00009493 00000001  0  000  stop  0xc5754344 sendmail
> 0xc5140000 00009495 00000001  0  000  stop  0xc5140344 sendmail
> 0xc147c000 00009496 00000001  0  000  stop  0xc147c344 sendmail
> 0xc3354000 00009497 00000001  0  000  stop  0xc3354344 sendmail
> 0xc1c1a000 00009499 00000001  0  000  stop  0xc1c1a344 sendmail
> 0xc1b42000 00009504 00000001  0  000  stop  0xc1b42344 sendmail
> [0]more>
> 0xc56de000 00009505 00000001  0  000  stop  0xc56de344 sendmail
> 0xc5762000 00009506 00000001  0  000  stop  0xc5762344 sendmail
> 0xc1cca000 00009508 00000001  0  000  stop  0xc1cca344 sendmail
> 0xc58e8000 00009510 00000001  0  000  stop  0xc58e8344 sendmail
> 0xc47b8000 00009511 00000001  0  000  stop  0xc47b8344 sendmail
> 0xc24d6000 00009514 00000001  0  000  stop  0xc24d6344 sendmail
> 0xc2732000 00009517 00000001  0  000  stop  0xc2732344 sendmail
> 0xc379c000 00009519 00000001  0  000  stop  0xc379c344 sendmail
> 0xc064e000 00009522 00000001  0  000  stop  0xc064e344 sendmail
> 0xc2bb2000 00009523 00000001  0  000  stop  0xc2bb2344 sendmail
> 0xc32bc000 00009526 00000001  0  000  stop  0xc32bc344 sendmail
> 0xc40cc000 00009529 00000001  0  000  stop  0xc40cc344 sendmail
> 0xc12c0000 00009531 00000001  0  000  stop  0xc12c0344 sendmail
> 0xc5270000 00009533 00000001  0  000  stop  0xc5270344 sendmail
> 0xc1c70000 00009534 00000001  0  000  stop  0xc1c70344 sendmail
> 0xc14a0000 00009537 00000001  0  000  stop  0xc14a0344 sendmail
> 0xc1cb2000 00009539 00000001  0  000  stop  0xc1cb2344 sendmail
> 0xc523a000 00009540 00000001  0  000  stop  0xc523a344 sendmail
> 0xc16ea000 00009542 00000001  0  000  stop  0xc16ea344 sendmail
> 0xc1eb8000 00009544 00000001  0  000  stop  0xc1eb8344 sendmail
> 0xc42f8000 00009546 00000001  0  000  stop  0xc42f8344 sendmail
> 0xc4042000 00009549 00000001  0  000  stop  0xc4042344 sendmail
> 0xc4ba8000 00009551 00000001  0  000  stop  0xc4ba8344 sendmail
> [0]more>
> 0xc1b5c000 00009553 00000001  0  000  stop  0xc1b5c344 sendmail
> 0xc51f8000 00009555 00000001  0  000  stop  0xc51f8344 sendmail
> 0xc3e9c000 00009557 00000001  0  000  stop  0xc3e9c344 sendmail
> 0xc4700000 00009559 00000001  0  000  stop  0xc4700344 sendmail
> 0xc2a5c000 00009560 00000001  0  000  stop  0xc2a5c344 sendmail
> 0xc3320000 00009561 00000001  0  000  stop  0xc3320344 sendmail
> 0xc2fd0000 00009562 00000001  0  000  stop  0xc2fd0344 sendmail
> 0xc368e000 00009567 00000001  0  000  stop  0xc368e344 sendmail
> 0xc264c000 00009569 00000001  0  000  stop  0xc264c344 sendmail
> 0xc5572000 00009571 00000001  0  000  stop  0xc5572344 sendmail
> 0xc5998000 00009573 00000001  0  000  stop  0xc5998344 sendmail
> 0xc0660000 00009574 00000001  0  000  stop  0xc0660344 sendmail
> 0xc5a68000 00009577 00000001  0  000  stop  0xc5a68344 sendmail
> 0xc1d18000 00009578 00000001  0  000  stop  0xc1d18344 sendmail
> 0xc2766000 00009580 00000001  0  000  stop  0xc2766344 sendmail
> 0xc18c2000 00009583 00000001  0  000  stop  0xc18c2344 sendmail
> 0xc2c24000 00009585 00000001  0  000  stop  0xc2c24344 sendmail
> 0xc3d6a000 00009587 00000001  0  000  stop  0xc3d6a344 sendmail
> 0xc4020000 00009588 00000001  0  000  stop  0xc4020344 sendmail
> 0xc3ba0000 00009589 00000001  0  000  stop  0xc3ba0344 sendmail
> 0xc48b8000 00009594 00000001  0  000  stop  0xc48b8344 sendmail
> 0xc3476000 00009595 00000001  0  000  stop  0xc3476344 sendmail
> 0xc215c000 00009596 00000001  0  000  stop  0xc215c344 sendmail
> [0]more>
> 0xc207a000 00009598 00000001  0  000  stop  0xc207a344 sendmail
> 0xc5744000 00009603 00000001  0  000  stop  0xc5744344 sendmail
> 0xc35fc000 00009605 00000001  0  000  stop  0xc35fc344 sendmail
> 0xc3e58000 00009606 00000001  0  000  stop  0xc3e58344 sendmail
> 0xc459a000 00009608 00000001  0  000  stop  0xc459a344 sendmail
> 0xc309e000 00009610 00000001  0  000  stop  0xc309e344 sendmail
> 0xc3698000 00009612 00000001  0  000  stop  0xc3698344 sendmail
> 0xc433e000 00009614 00000001  0  000  stop  0xc433e344 sendmail
> 0xc4338000 00009615 00000001  0  000  stop  0xc4338344 sendmail
> 0xc4bf6000 00009618 00000001  0  000  stop  0xc4bf6344 sendmail
> 0xc225e000 00009619 00000001  0  000  stop  0xc225e344 sendmail
> 0xc1782000 00009621 00000001  0  000  stop  0xc1782344 sendmail
> 0xc4dac000 00009623 00000001  0  000  stop  0xc4dac344 sendmail
> 0xc22d4000 00009624 00000001  0  000  stop  0xc22d4344 sendmail
> 0xc38a4000 00009626 00000001  0  000  stop  0xc38a4344 sendmail
> 0xc22f6000 00009629 00000001  0  000  stop  0xc22f6344 sendmail
> 0xc3a34000 00009632 00000001  0  000  stop  0xc3a34344 sendmail
> 0xc479a000 00009633 00000001  0  000  stop  0xc479a344 sendmail
> 0xc1ae4000 00009636 00000001  0  000  stop  0xc1ae4344 sendmail
> 0xc3560000 00009638 00000001  0  000  stop  0xc3560344 sendmail
> 0xc4ad4000 00009639 00000001  0  000  stop  0xc4ad4344 sendmail
> 0xc1642000 00009641 00000001  0  000  stop  0xc1642344 sendmail
> 0xc1380000 00009643 00000001  0  000  stop  0xc1380344 sendmail
> [0]more>
> 0xc05a4000 00009646 00000001  0  000  stop  0xc05a4344 sendmail
> 0xc1640000 00009648 00000001  0  000  stop  0xc1640344 sendmail
> 0xc43d2000 00009649 00000001  0  000  stop  0xc43d2344 sendmail
> 0xc1b14000 00009650 00000001  0  000  stop  0xc1b14344 sendmail
> 0xc0acc000 00009652 00000001  0  000  stop  0xc0acc344 sendmail
> 0xc3b38000 00009654 00000001  0  000  stop  0xc3b38344 sendmail
> 0xc0d8a000 00009656 00000001  0  000  stop  0xc0d8a344 sendmail
> 0xc05ea000 00009657 00000001  0  000  stop  0xc05ea344 sendmail
> 0xc1e04000 00009660 00000001  0  000  stop  0xc1e04344 sendmail
> 0xc2dc2000 00009661 00000001  0  000  stop  0xc2dc2344 sendmail
> 0xc0ffe000 00009663 00000001  0  000  stop  0xc0ffe344 sendmail
> 0xc136a000 00009665 00000001  0  000  stop  0xc136a344 sendmail
> 0xc1978000 00009667 00000001  0  000  stop  0xc1978344 sendmail
> 0xc14e6000 00009669 00000001  0  000  stop  0xc14e6344 sendmail
> 0xc5070000 00009671 00000001  0  000  stop  0xc5070344 sendmail
> 0xc5684000 00009673 00000001  0  000  stop  0xc5684344 sendmail
> 0xc2b84000 00009675 00000001  0  000  stop  0xc2b84344 sendmail
> 0xc2cba000 00009677 00000001  0  000  stop  0xc2cba344 sendmail
> 0xc4ea4000 00009679 00000001  0  000  stop  0xc4ea4344 sendmail
> 0xc094c000 00009682 00000001  0  000  stop  0xc094c344 sendmail
> 0xc2e8e000 00009685 00000001  0  000  stop  0xc2e8e344 sendmail
> 0xc0566000 00009688 00000001  0  000  stop  0xc0566344 sendmail
> 0xc2836000 00009690 00000001  0  000  stop  0xc2836344 sendmail
> [0]more>
> 0xc3756000 00009691 00000001  0  000  stop  0xc3756344 sendmail
> 0xc3ed6000 00009693 00000001  0  000  stop  0xc3ed6344 sendmail
> 0xc4b8c000 00009695 00000001  0  000  stop  0xc4b8c344 sendmail
> 0xc2956000 00009701 00000001  0  000  stop  0xc2956344 sendmail
> 0xc1492000 00009702 00000001  0  000  stop  0xc1492344 sendmail
> 0xc54d6000 00009703 00000001  0  000  stop  0xc54d6344 sendmail
> 0xc2e4c000 00009704 00000001  0  000  stop  0xc2e4c344 sendmail
> 0xc2c52000 00009706 00000001  0  000  stop  0xc2c52344 sendmail
> 0xc15a4000 00009707 00000001  0  000  stop  0xc15a4344 sendmail
> 0xc396c000 00009710 00000001  0  000  stop  0xc396c344 sendmail
> 0xc1ab8000 00009712 00000001  0  000  stop  0xc1ab8344 sendmail
> 0xc14de000 00009715 00000001  0  000  stop  0xc14de344 sendmail
> 0xc583c000 00009716 00000001  0  000  stop  0xc583c344 sendmail
> 0xc1846000 00009717 00000001  0  000  stop  0xc1846344 sendmail
> 0xc5002000 00009718 00000001  0  000  stop  0xc5002344 sendmail
> 0xc5bf8000 00009720 00000001  0  000  stop  0xc5bf8344 sendmail
> 0xc160c000 00009722 00000001  0  000  stop  0xc160c344 sendmail
> 0xc29d2000 00009723 00000001  0  000  stop  0xc29d2344 sendmail
> 0xc23b6000 00009726 00000001  0  000  stop  0xc23b6344 sendmail
> 0xc4b86000 00009730 00000001  0  000  stop  0xc4b86344 sendmail
> 0xc5320000 00009732 00000001  0  000  stop  0xc5320344 sendmail
> 0xc07ea000 00009734 00000001  0  000  stop  0xc07ea344 sendmail
> 0xc31b6000 00009735 00000001  0  000  stop  0xc31b6344 sendmail
> [0]more>
> 0xc1be0000 00009738 00000001  0  000  stop  0xc1be0344 sendmail
> 0xc5ad4000 00009741 00000001  0  000  stop  0xc5ad4344 sendmail
> 0xc525a000 00009742 00000001  0  000  stop  0xc525a344 sendmail
> 0xc4536000 00009744 00000001  0  000  stop  0xc4536344 sendmail
> 0xc5a02000 00009747 00000001  0  000  stop  0xc5a02344 sendmail
> 0xc3074000 00009749 00000001  0  000  stop  0xc3074344 sendmail
> 0xc1f5e000 00009752 00000001  0  000  stop  0xc1f5e344 sendmail
> 0xc5b42000 00009758 00009107  0  000  stop  0xc5b42344 lpbm_user_run
> 0xc2ad0000 00009760 00000001  1  000  run   0xc2ad0344*sendmail
> 0xc5a3c000 00009761 00009400  0  000  run   0xc5a3c344 sendmail
> 0xc3cb0000 00009762 00009379  0  000  run   0xc3cb0344 sendmail
> 0xc5006000 00009763 00009762  0  000  stop  0xc5006344 sendmail
> 0xc09e8000 00009764 00009761  0  000  stop  0xc09e8344 sendmail
> 0xc0a0a000 00009765 00009380  0  000  run   0xc0a0a344 sendmail
> 0xc09e2000 00009766 00009765  0  000  stop  0xc09e2344 sendmail
> 0xc5470000 00009767 00009451  0  000  run   0xc5470344 sendmail
> 0xc3204000 00009768 00009410  0  000  run   0xc3204344 sendmail
> 0xc3040000 00009769 00009768  0  000  stop  0xc3040344 sendmail
> 0xc3946000 00009770 00009767  0  000  stop  0xc3946344 sendmail
> [0]kdb>
>
> I haven't seen this second panic on an XFS filesystem, however.
>
> cheers.

--
Russell Cattelan
cattelan@thebarn.com

From owner-linux-xfs@oss.sgi.com Tue May 23 05:53:40 2000
Received:  by oss.sgi.com id <S42274AbQEWMxb>;
	Tue, 23 May 2000 05:53:31 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:55644 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42269AbQEWMxR>; Tue, 23 May 2000 05:53:17 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id FAA05531; Tue, 23 May 2000 05:57:55 -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 FAA41258; Tue, 23 May 2000 05:52:46 -0700 (PDT)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id FAA15965; Tue, 23 May 2000 05:50:05 -0700 (PDT)
Date:   Tue, 23 May 2000 05:50:05 -0700 (PDT)
Message-Id: <200005231250.FAA15965@feature.engr.sgi.com>
X-Pv-Incident: 791621 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (jtk@sgi.com)
Subject: ADD 791621 - panic in xfs_inobp_check
To:     mostek@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 : mostek            Priority : 1                         
*Modified Date : 05/23/00             *Modified User : jtk                  
*Modified User Domain : sgi.com       *Description :
I've seen this panic in the XFS code a few times now, in both
big-endian and little-endian builds (just before Daniel's
BE-only checkin).  Only happens under very high load (test is
using sendmail to queue-remote/save-local mail messages to an
xfs fs), and only happens sporadically (increased load seems
to increase the chance of it happening).

kernel is built with debug on, pagebuf meta on.



.....


==========================
ADDITIONAL INFORMATION (ADD)
From: ted kline <jtk@sgi.com>
Date: May 23 2000 05:50:04AM
[pvnews version: 1.71]
==========================
> I've seen this panic in the XFS code a few times now, in both
> big-endian and little-endian builds (just before Daniel's
> BE-only checkin).  Only happens under very high load (test is
> using sendmail to queue-remote/save-local mail messages to an
> xfs fs), and only happens sporadically (increased load seems
> to increase the chance of it happening).
> 
> kernel is built with debug on, pagebuf meta on.
> 
> 
>     EBP       EIP         Function(args)
> 0xc2c6be10 0xc01c5c73  xfs_inobp_check+0x33( 0xc4a9d000, 0xc551dd40, 0xc37727e4, 0xc551d480, 0x1560 )
> 0xc2c6be78 0xc01c9395  xfs_iunlink_remove+0x5c9( 0xc37727e4, 0xc22413c0, 0xc4a9d000, 0xc22413c0, 0xc251f3b4 )

I have a fix for the inobp_check problem, will check it in shortly.

	-Ted

From owner-linux-xfs@oss.sgi.com Tue May 23 06:55:31 2000
Received:  by oss.sgi.com id <S42276AbQEWNzV>;
	Tue, 23 May 2000 06:55:21 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:4383 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42275AbQEWNzC>;
	Tue, 23 May 2000 06:55:02 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA13312
	for <linux-xfs@oss.sgi.com>; Tue, 23 May 2000 06:50:10 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA52125; Tue, 23 May 2000 08:52:16 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id IAA17483; Tue, 23 May 2000 08:52:15 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id IAA28916; Tue, 23 May 2000 08:51:58 -0500
Message-Id: <200005231351.IAA28916@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
cc:     Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: endian conversion work 
In-Reply-To: Message from Daniel Moore <dxm@clouds.melbourne.sgi.com> 
   of "Tue, 23 May 2000 09:48:26 +1000." <200005222348.JAA37777@clouds.melbourne.sgi.com> 
Date:   Tue, 23 May 2000 08:51: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

> 
> Steve Lord writes:
>  => 
>  => Daniel,
> 
>  => We could just use xfs_xlate_dinode_core() on the inode core to convert it
,
>  => we then need to look at all the other fields in the inode which can get 
> ...
> 
> Happily, the dinode_core is the only part of the dinode that is stored
> in in-core format at any time. So currently, the inode log records
> consist of an in-core inode core and the on-disk version of the rest of
> the inode. The dinode_core is easy to move between in-core and on-disk
> forms but the rest would be nasty.
> 
> For now, I've fixed the recovery to convert the core to on-disk before
> writing it out. This is an efficient way of doing things, but if we
> ever want to be able to move dirty disks between architecture, we'll
> have to make sure the whole log is in on-disk format.
> 


I think your pointer arithmetic is broken:

        bcopy(item->ri_buf[1].i_addr + sizeof(xfs_dinode_core_t),
              dip                    + sizeof(xfs_dinode_core_t),
              item->ri_buf[1].i_len  - sizeof(xfs_dinode_core_t));

dip is a xfs_dinode_t pointer, just adding to it like this will walk a
long way down memory, however, since the size of the field is always
sizeof(xfs_dinode_core_t) this does not matter.

from xfs_inode_item_format():

        vecp->i_addr = (caddr_t)&ip->i_d;
        vecp->i_len  = sizeof(xfs_dinode_core_t);
        vecp++;


So I think we can lose the bcopy. Also what about the line:

	dip->di_u.di_dev = in_f->ilf_u.ilfu_rdev;

I think this needs to be:

	INT_SET(dip->di_u.di_dev, ARCH_CONVERT, in_f->ilf_u.ilfu_rdev);

I was running with similar code - I will fix this up and check in - there
was also a panic in the cleanup from failed mount path which was coming out.

Steve



From owner-linux-xfs@oss.sgi.com Tue May 23 07:32:21 2000
Received:  by oss.sgi.com id <S42275AbQEWOcL>;
	Tue, 23 May 2000 07:32:11 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:56363 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42269AbQEWObv>;
	Tue, 23 May 2000 07:31:51 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA17923
	for <linux-xfs@oss.sgi.com>; Tue, 23 May 2000 07:26:59 -0700 (PDT)
	mail_from (lord@cray.com)
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA41964 for <linux-xfs@oss.sgi.com>; Tue, 23 May 2000 09:29:20 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id JAA60437 for linux-xfs@oss.sgi.com; Tue, 23 May 2000 09:29:18 -0500 (CDT)
Date:   Tue, 23 May 2000 09:29:18 -0500 (CDT)
From:   Steve Lord <lord@cray.com>
Message-Id: <200005231429.JAA60437@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - more log recovery cleanups
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.3.99pre2-xfs:slinx:62475a
Date:  Tue May 23 07:24:51 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
Author:  lord

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

linux/fs/xfs/linux/xfs_super.c - 1.65
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h
	- Ensure pages on metadata inode are gone before we tear it down - needed
	  for failed mount case. Also before we disconnect the inode from the vnode,
	  flush all pages out.

linux/fs/xfs/xfs_inode.c - 1.286
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.286&r2=text&tr2=1.285&f=h
linux/fs/xfs/xfs_inode.h - 1.134
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.h.diff?r1=text&tr1=1.134&r2=text&tr2=1.133&f=h
	- make inode core translation function public

linux/fs/xfs/xfs_log_recover.c - 1.180
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.180&r2=text&tr2=1.179&f=h
	- minor tweaks to daniels changes for log playback byte ordering fixes

linux/fs/xfs/xfs_mount.c - 1.223
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.223&r2=text&tr2=1.222&f=h
linux/fs/xfs/xfs_mount.h - 1.112
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.h.diff?r1=text&tr1=1.112&r2=text&tr2=1.111&f=h
	- make super block translation public


From owner-linux-xfs@oss.sgi.com Tue May 23 11:54:42 2000
Received:  by oss.sgi.com id <S42278AbQEWSyd>;
	Tue, 23 May 2000 11:54:33 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:48391 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42277AbQEWSyR>;
	Tue, 23 May 2000 11:54:17 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA25247
	for <linux-xfs@oss.sgi.com>; Tue, 23 May 2000 11:49:24 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA69124 for <linux-xfs@oss.sgi.com>; Tue, 23 May 2000 13:53:01 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id NAA09252 for <linux-xfs@oss.sgi.com>; Tue, 23 May 2000 13:52:59 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id NAA55890; Tue, 23 May 2000 13:52:58 -0500 (CDT)
Message-Id: <200005231852.NAA55890@tiki.americas.sgi.com>
Date:   Tue, 23 May 2000 13:52:58 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - 791621 - Fix bogus xfs_inobp_check 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.3.99pre2-xfs:slinx:62495a
Date:  Tue May 23 11:51:55 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linux2.3-99

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

linux/fs/xfs/xfs_inode.c - 1.287
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.287&r2=text&tr2=1.286&f=h
	- Correct a bad call to xfs_inobp_check, wrong buffer.



From owner-linux-xfs@oss.sgi.com Tue May 23 15:26:51 2000
Received:  by oss.sgi.com id <S42279AbQEWVo0>;
	Tue, 23 May 2000 14:44:26 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:19536 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42277AbQEWVoI>;
	Tue, 23 May 2000 14:44:08 -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 OAA28519; Tue, 23 May 2000 14:39:16 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA10417; Tue, 23 May 2000 14:44:02 -0700 (PDT)
Date:   Tue, 23 May 2000 14:44:02 -0700 (PDT)
Message-Id: <200005232144.OAA10417@info.engr.sgi.com>
X-Pv-Incident: 791621 
webPV:  mostek.cray.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (mostek@sgi.com)
Subject: REASSIGN 791621 - panic in xfs_inobp_check
To:     jtk@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=791621

 Status : open                         Priority : 1                         
*Assigned Engineer : jtk               Submitter : nathans                  
 Project : xfs-linux                   Assigned Group : xfs-linux           
 Opened Date : 05/21/00               *Modified User : mostek               
*Modified User Domain : sgi.com       *Description :
I've seen this panic in the XFS code a few times now, in both
big-endian and little-endian builds (just before Daniel's
BE-only checkin).  Only happens under very high load (test is
using sendmail to queue-remote/save-local mail messages to an
xfs fs), and only happens sporadically (increased load seems
to increase the chance of it happening).

kernel is built with debug on, pagebuf meta on.



.....


==========================
ADDITIONAL INFORMATION (REASSIGN)
From: mostek@sgi.com (BugWorks)
Date: May 23 2000 02:44:01PM
==========================

Since you have a fix ...

From owner-linux-xfs@oss.sgi.com Tue May 23 15:47:57 2000
Received:  by oss.sgi.com id <S42280AbQEWWDG>;
	Tue, 23 May 2000 15:03:06 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:52820 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42277AbQEWWCr>;
	Tue, 23 May 2000 15:02:47 -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 OAA00681; Tue, 23 May 2000 14:57:55 -0700 (PDT)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA48320; Tue, 23 May 2000 15:02:41 -0700 (PDT)
Date:   Tue, 23 May 2000 15:02:41 -0700 (PDT)
Message-Id: <200005232202.PAA48320@info.engr.sgi.com>
X-Pv-Incident: 791621 
webPV:  tiki.cray.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (jtk@sgi.com)
Subject: CLOSE 791621 - panic in xfs_inobp_check
To:     jtk@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=791621

*Status : closed                       Priority : 1                         
 Assigned Engineer : jtk               Submitter : nathans                  
 Opened Date : 05/21/00               *Closed Date : 05/23/00               
*Fixed By : jtk                       *Fixed By Domain : sgi.com            
*Modified Date : 05/23/00             *Modified User : jtk                  
*Modified User Domain : sgi.com       *Fix Description :
==========================
ADDITIONAL INFORMATION (CLOSE)
From: jtk@sgi.com (BugWorks)
Date: May 23 2000 03:02:41PM
==========================

I checked in the fix earlier today, dunno where the "take"
mail went?

	-Ted

From owner-linux-xfs@oss.sgi.com Tue May 23 15:47:58 2000
Received:  by oss.sgi.com id <S42282AbQEWWVf>;
	Tue, 23 May 2000 15:21:35 -0700
Received: (from localhost user: 'cattelan', uid#10098) by oss.sgi.com
	id <S42277AbQEWWVT>; Tue, 23 May 2000 15:21:19 -0700
From:   Russell Cattelan <cattelan@oss.sgi.com>
To:     linux-xfs@oss.sgi.com
Message-Id: <20000523222130Z42277-28919+30@oss.sgi.com>
Date:   Tue, 23 May 2000 15:21:19 -0700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Sorry folks another test

From owner-linux-xfs@oss.sgi.com Wed May 24 12:15:12 2000
Received:  by oss.sgi.com id <S42284AbQEWWuG>;
	Tue, 23 May 2000 15:50:06 -0700
Received: (from localhost user: 'cattelan', uid#10098) by oss.sgi.com
	id <S42277AbQEWWuD>; Tue, 23 May 2000 15:50:03 -0700
From:   Russell Cattelan <cattelan@oss.sgi.com>
To:     linux-xfs@oss.sgi.com
Message-Id: <20000523225005Z42277-28921+42@oss.sgi.com>
Date:   Tue, 23 May 2000 15:50:03 -0700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Sorry folks another test

From owner-linux-xfs@oss.sgi.com Wed May 24 12:15:13 2000
Received:  by oss.sgi.com id <S42283AbQEWXVg>;
	Tue, 23 May 2000 16:21:36 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:57193 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42277AbQEWXVH>;
	Tue, 23 May 2000 16:21:07 -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 QAA10840
	for <linux-xfs@oss.sgi.com>; Tue, 23 May 2000 16:16:13 -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 JAA10244; Wed, 24 May 2000 09:19:48 +1000
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id JAA82172; Wed, 24 May 2000 09:19:47 +1000 (EST)
Message-Id: <200005232319.JAA82172@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: endian conversion work 
In-reply-to: Your message of "Tue, 23 May 2000 08:51:58 EST."
             <200005231351.IAA28916@jen.americas.sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 24 May 2000 09:19:46 +1000
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:

 => I think your pointer arithmetic is broken:
...
 => So I think we can lose the bcopy. Also what about the line:

You're right of course - broken but still working fine :)

 => 	INT_SET(dip->di_u.di_dev, ARCH_CONVERT, in_f->ilf_u.ilfu_rdev);

also correct.

I haven't seen a hiccup from log recovery yet. xfs_repair is
on its way too.

-----------------------------------------------------
 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 Wed May 24 12:15:13 2000
Received:  by oss.sgi.com id <S42285AbQEXAd4>;
	Tue, 23 May 2000 17:33:56 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:44350 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42277AbQEXAdb>; Tue, 23 May 2000 17:33:31 -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 RAA06215
	for <linux-xfs@oss.sgi.com>; Tue, 23 May 2000 17:38:08 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA10712 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 24 May 2000 10:32:12 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA93662 for linux-xfs@oss.sgi.com; Wed, 24 May 2000 10:32:10 +1000 (EST)
Date:   Wed, 24 May 2000 10:32:10 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005240032.KAA93662@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - xfs_repair endian conversion
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

xfs_repair should be usable now. 

YMMV - please backup your FS before use if it 
contains anything important and let us know
if any problems crop up.

Modid:  2.3.99pre2-xfs:slinx:62572a
Date:  Tue May 23 17:30:14 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.3.99pre2-xfs

cmd/xfs/repair/agheader.c - 1.20
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/agheader.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h
cmd/xfs/repair/attr_repair.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/attr_repair.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
cmd/xfs/repair/dino_chunks.c - 1.38
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dino_chunks.c.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h
cmd/xfs/repair/dinode.c - 1.75
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dinode.c.diff?r1=text&tr1=1.75&r2=text&tr2=1.74&f=h
cmd/xfs/repair/dir.c - 1.54
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dir.c.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h
cmd/xfs/repair/dir2.c - 1.10
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dir2.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h
cmd/xfs/repair/incore.h - 1.34
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/incore.h.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h
cmd/xfs/repair/phase2.c - 1.23
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase2.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h
cmd/xfs/repair/phase3.c - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase3.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
cmd/xfs/repair/phase4.c - 1.45
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase4.c.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h
cmd/xfs/repair/phase5.c - 1.40
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase5.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h
cmd/xfs/repair/phase6.c - 1.53
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase6.c.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h
cmd/xfs/repair/phase7.c - 1.21
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase7.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h
cmd/xfs/repair/rt.c - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/rt.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
cmd/xfs/repair/sb.c - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/sb.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
cmd/xfs/repair/scan.c - 1.40
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/scan.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h
cmd/xfs/repair/xfs_repair.c - 1.45
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/xfs_repair.c.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h

From owner-linux-xfs@oss.sgi.com Wed May 24 12:15:13 2000
Received:  by oss.sgi.com id <S42286AbQEXBWG>;
	Tue, 23 May 2000 18:22:06 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:32266 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42277AbQEXBVn>;
	Tue, 23 May 2000 18:21:43 -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 SAA24446
	for <linux-xfs@oss.sgi.com>; Tue, 23 May 2000 18:16:48 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11084 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Wed, 24 May 2000 11:19:08 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id LAA50989 for linux-xfs@oss.sgi.com; Wed, 24 May 2000 11:19:08 +1000 (EST)
Date:   Wed, 24 May 2000 11:19:08 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005240119.LAA50989@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - mkfs_xfs tweaks
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

remove some crud

Modid:  2.3.99pre2-xfs:slinx:62581a
Date:  Tue May 23 18:18: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.3.99pre2-xfs

cmd/xfs/mkfs/rdwr.c - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mkfs/rdwr.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
	- remove unused functions

cmd/xfs/mkfs/xfs_mkfs.c - 1.163
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.163&r2=text&tr2=1.162&f=h
	- remove funny character


From owner-linux-xfs@oss.sgi.com Wed May 24 12:15:13 2000
Received:  by oss.sgi.com id <S42288AbQEXEoJ>;
	Tue, 23 May 2000 21:44:09 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:51785 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42277AbQEXEnt>; Tue, 23 May 2000 21:43:49 -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 VAA00141
	for <linux-xfs@oss.sgi.com>; Tue, 23 May 2000 21:48:24 -0700 (PDT)
	mail_from (kaos@kao2.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 OAA12232; Wed, 24 May 2000 14:42:27 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
cc:     slinx-xfs@engr.sgi.com
Subject: TAKE 791546 - Upgrade slinx-xfs to kdb v1.2
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 24 May 2000 14:42:27 +1000
Message-ID: <7390.959143347@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

 Submitter : kaos                     *Status : closed                      
 Assigned Engineer : kaos             *Fixed By : kaos                      
*Fixed By Domain : melbourne          *Closed Date : 05/23/00               
 Priority : 3                         *Modified Date : 05/23/00             
*Modified User : kaos                 *Modified User Domain : melbourne     
*Fix Description :
From: keith owens <kaos@melbourne.sgi.com> (TAKE)
Date: May 23 2000 09:20:03PM
[pvnews version: 1.71]
----------------------------

Upgrade xfs to kdb v1.2.  This brings 2.3.99pre2-xfs in sync
with modid 2.3.99pre2-kdb:slinx:62587a.

NOTE: To compile a kernel using kdb v1.2 you must install
      modutils >= 2.3.11 on the compiling and the running systems.

Most of the kdb v1.2 changes are internal.  User visible changes
are in the backtrack command, see Documentation/kdb/kdb_bt.man.

Modid:  2.3.99pre2-xfs:slinx:62596a
Date:  Tue May 23 20:31:18 PDT 2000
Workarea:  kao1.melbourne.sgi.com:/hosts/sherman/home/kaos/2.3.99pre2-xfs
Author:  kaos

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

linux/Documentation/Configure.help - 1.47
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/Documentation/Configure.help.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h
linux/Documentation/kdb/kdb.mm - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/Documentation/kdb/kdb.mm.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/Documentation/kdb/kdb_bp.man - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/Documentation/kdb/kdb_bp.man.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/Documentation/kdb/kdb_bt.man - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/Documentation/kdb/kdb_bt.man.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/Makefile - 1.53
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/Makefile.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h
linux/arch/alpha/vmlinux.lds - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/alpha/vmlinux.lds.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
linux/arch/arm/vmlinux-armo.lds.in - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/arm/vmlinux-armo.lds.in.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
linux/arch/arm/vmlinux-armv.lds.in - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/arm/vmlinux-armv.lds.in.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
linux/arch/i386/Makefile - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/Makefile.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
linux/arch/i386/config.in - 1.35
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/config.in.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h
linux/arch/i386/kdb/Makefile - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/arch/i386/kdb/i386-dis.c - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/i386-dis.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/arch/i386/kdb/kdba_bp.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/kdba_bp.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/arch/i386/kdb/kdba_bt.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/kdba_bt.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/arch/i386/kdb/kdba_id.c - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/kdba_id.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/arch/i386/kdb/kdba_io.c - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/kdba_io.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/arch/i386/kdb/kdbasupport.c - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/kdbasupport.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
linux/arch/i386/kernel/entry.S - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kernel/entry.S.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
linux/arch/i386/kernel/semaphore.c - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kernel/semaphore.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
linux/arch/i386/kernel/traps.c - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kernel/traps.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
linux/arch/i386/lib/mcount.S - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/lib/mcount.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/arch/i386/vmlinux.lds - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/vmlinux.lds.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
linux/arch/ia64/config.in - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/ia64/config.in.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/arch/ia64/kdb/kdbsupport.c - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/ia64/kdb/kdbsupport.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
linux/arch/m68k/vmlinux-sun3.lds - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/m68k/vmlinux-sun3.lds.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/arch/m68k/vmlinux.lds - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/m68k/vmlinux.lds.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/arch/sh/vmlinux.lds.S - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/sh/vmlinux.lds.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/arch/sparc/vmlinux.lds - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/sparc/vmlinux.lds.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/arch/sparc64/vmlinux.lds - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/sparc64/vmlinux.lds.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/drivers/char/Makefile - 1.27
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/drivers/char/Makefile.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h
linux/drivers/char/defkeymap.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/drivers/char/defkeymap.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/fs/xfs/xfsidbg.c - 1.142
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.142&r2=text&tr2=1.141&f=h
linux/include/asm-i386/kdbprivate.h - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/asm-i386/kdbprivate.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
linux/include/linux/kdb.h - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kdb.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
linux/include/linux/kdbprivate.h - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kdbprivate.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/include/linux/module.h - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/module.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/init/main.c - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/init/main.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
linux/ipc/shm.c - 1.30
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/ipc/shm.c.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h
linux/kdb/Makefile - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/kdb/kdb_bp.c - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdb_bp.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
linux/kdb/kdb_bt.c - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdb_bt.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/kdb/kdb_id.c - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdb_id.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/kdb/kdb_io.c - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdb_io.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/kdb/kdbmain.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdbmain.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/kdb/kdbsupport.c - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdbsupport.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/kdb/modules/Makefile - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/modules/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/kdb/modules/kdbm_pb.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/modules/kdbm_pb.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
linux/kdb/modules/kdbm_vm.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/modules/kdbm_vm.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/kernel/Makefile - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kernel/Makefile.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
linux/kernel/ksyms.c - 1.44
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kernel/ksyms.c.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h
linux/kernel/module.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kernel/module.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
linux/kernel/profile.c - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kernel/profile.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/kernel/kallsyms.c - 1.1
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kernel/kallsyms.c.diff?r1=text&tr1=1.1&r2=text&tr2=1.0&f=h

Upgrade xfs to kdb v1.2

Modid:  2.3.99pre2-xfs:slinx:62597a
Date:  Tue May 23 20:39:41 PDT 2000
Workarea:  kao1.melbourne.sgi.com:/hosts/sherman/home/kaos/2.3.99pre2-xfs
Author:  kaos

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

linux/include/linux/kallsyms.h - 1.1
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kallsyms.h.diff?r1=text&tr1=1.1&r2=text&tr2=1.0&f=h

Upgrade xfs to kdb v1.2

Modid:  2.3.99pre2-xfs:slinx:62598a
Date:  Tue May 23 20:52:20 PDT 2000
Workarea:  kao1.melbourne.sgi.com:/hosts/sherman/home/kaos/2.3.99pre2-xfs
Author:  kaos

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

linux/arch/i386/vmlinux.lds - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/vmlinux.lds.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
Description :
Upgrade slinx-xfs to kdb v1.2.  Improved symbol handling, correct
bug with gdb interaction, correct bug when clearing int3
breakpoints, reduce syslog activity, add symbol lookup on
function arguments (env BTARGSYM).

NOTE:	You must install modutils >= 2.3.11 to compile a kernel
	with kdb v1.2.


From owner-linux-xfs@oss.sgi.com Wed May 24 12:15:13 2000
Received:  by oss.sgi.com id <S42291AbQEXPln>;
	Wed, 24 May 2000 08:41:43 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:18799 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42277AbQEXPlW>; Wed, 24 May 2000 08:41:22 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA03107
	for <linux-xfs@oss.sgi.com>; Wed, 24 May 2000 08:46:01 -0700 (PDT)
	mail_from (lord@cray.com)
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA57920 for <linux-xfs@oss.sgi.com>; Wed, 24 May 2000 10:40:06 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id KAA34371 for linux-xfs@oss.sgi.com; Wed, 24 May 2000 10:40:05 -0500 (CDT)
Date:   Wed, 24 May 2000 10:40:05 -0500 (CDT)
From:   Steve Lord <lord@cray.com>
Message-Id: <200005241540.KAA34371@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - restore lost kdb pagebuf commands
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.3.99pre2-xfs:slinx:62623a
Date:  Wed May 24 08:39:39 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
Author:  lord

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

linux/kdb/modules/kdbm_pb.c - 1.19
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/modules/kdbm_pb.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h
	- Put back the pagebuf commands we lost during the kdb upgrade


From owner-linux-xfs@oss.sgi.com Wed May 24 13:23:45 2000
Received:  by oss.sgi.com id <S42279AbQEXUXg>;
	Wed, 24 May 2000 13:23:36 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:25903 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42278AbQEXUXe>; Wed, 24 May 2000 13:23:34 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA04154
	for <linux-xfs@oss.sgi.com>; Wed, 24 May 2000 14:28:13 -0700 (PDT)
	mail_from (cattelan@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA03559 for <linux-xfs@oss.sgi.com>; Wed, 24 May 2000 16:22:17 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id QAA11379 for <linux-xfs@oss.sgi.com>; Wed, 24 May 2000 16:22:16 -0500 (CDT)
From:   Russell Cattelan <cattelan@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id QAA28137; Wed, 24 May 2000 16:22:15 -0500 (CDT)
Message-Id: <200005242122.QAA28137@nt8.americas.sgi.com>
Date:   Wed, 24 May 2000 16:22:15 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Subject: TAKE - small kdb makefile fix
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.3.99pre2-xfs:slinx:62670a
Date:  Wed May 24 14:21:39 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs
Author:  cattelan

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

linux/kdb/modules/Makefile - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/modules/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
	- Build Build kdbm_pb in CONFIG_PAGE_BUF = m case


From owner-linux-xfs@oss.sgi.com Wed May 24 14:20:15 2000
Received:  by oss.sgi.com id <S42278AbQEXVUG>;
	Wed, 24 May 2000 14:20:06 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:56884 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42238AbQEXVTx>;
	Wed, 24 May 2000 14:19:53 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA07132
	for <linux-xfs@oss.sgi.com>; Wed, 24 May 2000 15:15:00 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA79634 for <linux-xfs@oss.sgi.com>; Wed, 24 May 2000 17:17:21 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id RAA13308; Wed, 24 May 2000 17:17:19 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id RAA93146; Wed, 24 May 2000 17:17:18 -0500 (CDT)
Message-Id: <200005242217.RAA93146@tiki.americas.sgi.com>
Date:   Wed, 24 May 2000 17:17:18 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Cc:     jtk@sgi.com
Subject: TAKE 789427 - Move the XFS vnode into the linux inode.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Moving the XFS vnode into the linux inode, solving several major
issues with inode re-use.

Now, XFS can be NFS exported.

Some aspects of the unlink path seem to "push" the buffer/page_buf
complex fairly hard, encountering a locking bug that can also occur
without this change with sufficient stress.

This change has been run with DEBUG on/off, Vnode Tracing on/off,
and PageBufMetaData on/off.



Modid:  2.3.99pre2-xfs:slinx:62680a
Date:  Wed May 24 15:10:51 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linuxvnode

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

linux/include/linux/behavior.h - 1.1
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/behavior.h.diff?r1=text&tr1=1.1&r2=text&tr2=1.0&f=h
	- New file.  More visible definition of 'behavior' structures.

linux/include/linux/vnode.h - 1.1
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/vnode.h.diff?r1=text&tr1=1.1&r2=text&tr2=1.0&f=h
	- New file.  More visible definition of 'vnode' structures.

linux/net/sunrpc/sched.c - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/net/sunrpc/sched.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
	- Move an irritating printk under RPC_DEBUG.

linux/mm/filemap.c - 1.39
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/mm/filemap.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h
	- Define the wait_queue_head pbd_waitq.

linux/kernel/ksyms.c - 1.45
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kernel/ksyms.c.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h
	- Export 'pdb_waitq', used by pagebuf_daemon/XFS_pbflush.

linux/include/linux/mm.h - 1.31
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/mm.h.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h
	- Add extern for pbd_waitq.

cmd/xfs/sim/src/vnode.c - 1.53
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/vnode.c.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h
	- Change calling parameters on libsim's vn_get() & vn_alloc()
	  to match the kernel side.

linux/fs/page_buf.c - 1.97
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.97&r2=text&tr2=1.96&f=h
	- Clean up the pagebuf_delwri_flush routine, it had several
	  bugs that would cause looping on the queues.
	  Make the "walkq" traces more unique.

linux/fs/xfs/xfsidbg.c - 1.143
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.143&r2=text&tr2=1.142&f=h
	- Rework "vnode" & "vntrace" commands.
	  Add "vn" command: prints inode, vnode & vntrace all
	  from one vnode address.
	  Add "vntraceaddr" command to print the vntrace if
	  all you have is the trace buffer address.

linux/fs/xfs/xfs_log.c - 1.217
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.217&r2=text&tr2=1.216&f=h
	- Call XFS_bflush() out of xfs_log_force() to push out
	  the metadata pages when CONFIG_PAGE_BUF_META is true.

linux/fs/xfs/xfs_quota_priv.h - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_quota_priv.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
	- Change the XFS_PURGE_INODE macro to take the XFS
	  inode address instead of the vnode, change the
	  VMAP call made inside this macro.

linux/fs/xfs/xfs_rw.c - 1.314
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_rw.c.diff?r1=text&tr1=1.314&r2=text&tr2=1.313&f=h
	- Use 'vn_count()' to check the reference count.

linux/fs/xfs/xfs_buf.h - 1.51
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_buf.h.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h
	- Add definition/prototype for XFS_pbflush().

linux/fs/xfs/xfs_vnodeops.c - 1.452
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c.diff?r1=text&tr1=1.452&r2=text&tr2=1.451&f=h
	- Use 'vn_count()' to check the reference count.
	  Add some vn_trace_'s.

linux/fs/xfs/xfs_rtalloc.c - 1.60
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_rtalloc.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h
	- Add the XFS inode pointer to VMAP calls.

linux/fs/xfs/xfs_qm_syscalls.c - 1.37
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_qm_syscalls.c.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h
	- Change vn_get calls.

linux/fs/xfs/xfs_log_recover.c - 1.181
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.181&r2=text&tr2=1.180&f=h
	- Minor fix in a console message.

linux/fs/xfs/xfs_vfsops.c - 1.268
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vfsops.c.diff?r1=text&tr1=1.268&r2=text&tr2=1.267&f=h
	- Use 'vn_count()' to check the reference count.

linux/fs/xfs/xfs_iget.c - 1.115
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_iget.c.diff?r1=text&tr1=1.115&r2=text&tr2=1.114&f=h
	- Change vn_get/vn_alloc calls.

linux/fs/xfs/xfs_mount.c - 1.224
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.224&r2=text&tr2=1.223&f=h
	- Add the XFS inode pointer to VMAP calls.

linux/fs/xfs/xfs_qm.c - 1.49
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_qm.c.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h
linux/fs/xfs/xfs_inode.c - 1.288
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.288&r2=text&tr2=1.287&f=h
	- Use 'vn_count()' to check the reference count.

linux/fs/xfs/xfs_inode.h - 1.135
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.h.diff?r1=text&tr1=1.135&r2=text&tr2=1.134&f=h
	- Add XFS_IRECLAIM flag for debugging.

linux/fs/xfs/pseudo-inc/sys/vnode.h - 1.21
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/vnode.h.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h
	- Move a substantial portion to linux/include/linux/vnode.h

linux/fs/xfs/pseudo-inc/ksys/behavior.h - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/ksys/behavior.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
	- Move a substantial portion to linux/include/linux/behavior.h

linux/fs/xfs/linux/xfs_lrw.c - 1.40
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h
	- Add the XFS_pbflush() routine.
	  In xfs_trigger_io add a call to 'wake up' the
	  pagebuf daemon.

linux/fs/xfs/linux/xfs_file.c - 1.29
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_file.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h
	- Add ASSERT's after inode to vnode address conversion.

linux/fs/xfs/linux/xfs_vnode.c - 1.24
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_vnode.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h
	- Major gutting!  Remove all routines that were involved
	  in maintaining the vnode cache & vnode freelist mechanisms.
	  Vn_alloc now does a linux 'iget', vn_get does a linux 'igrab',
	  vn_put does a linux 'iput'.
	  Vn_hold/rele use the linux inode i_count.
	  Vn_count provides a 'sample' of the reference count.
	  Vn_address determines if it's 'safe' to return a vnode address.
	  Vn_initialize sets up an XFS vnode within the linux inode;
	  called out of 'read_inode'.
	  Vn_revalidate updates the linux inode from the XFS inode at
	  xfs_iget time.
	  Vn_remove tears down, purges, inactivates, flushes, and
	  otherwise disposes of an XFS vnode, leaving it unaddressable
	  out of the linux inode.
	  Change the vn_trace_ routines to trace inode->i_count.

linux/fs/xfs/linux/xfs_super.c - 1.66
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c.diff?r1=text&tr1=1.66&r2=text&tr2=1.65&f=h
	- Only use the 'read_inode', 'delete_inode' & 'clear_inode'
	  methds, anything else is 'advisory' in terms of when
	  the XFS vnode could be purged.
	  Minor changes in 'put_super' allowing for the different
	  reference counts held on the root inode/vnode.

linux/fs/xfs/linux/xfs_iops.c - 1.49
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h
	- Minor re-arrangement allowing for the differents
	  location/initialization of the vnode.
	  Add ASSERT's after inode to vnode address conversion.

linux/fs/xfs/linux/xfs_iops.h - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
	- Prototypes for linvfs_revalidate_core() and
	  linvfs_set_inode_ops().

linux/include/linux/xfs_fs_i.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/xfs_fs_i.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
	- Define the vnode within the inode 'file system private' union.

linux/kdb/modules/kdbm_pb.c - 1.20
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/modules/kdbm_pb.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h
	- Update the 'inode' kdb command.

linux/include/linux/page_buf_trace.h - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/page_buf_trace.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
	- Make the "walkq" traces more unique.

linux/fs/xfs/linux/xfs_ioctl.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_ioctl.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
	- Remove extraneous 'iget', made unnecessary now
	  that xfs_iget/vn_get/vn_alloc does it.



From owner-linux-xfs@oss.sgi.com Wed May 24 14:28:05 2000
Received:  by oss.sgi.com id <S42280AbQEXV1z>;
	Wed, 24 May 2000 14:27:55 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:50231 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42238AbQEXV1w>;
	Wed, 24 May 2000 14:27:52 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA08472
	for <linux-xfs@oss.sgi.com>; Wed, 24 May 2000 15:22:59 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA78531 for <linux-xfs@oss.sgi.com>; Wed, 24 May 2000 17:25:19 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id RAA13538; Wed, 24 May 2000 17:25:18 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id RAA76295; Wed, 24 May 2000 17:25:17 -0500 (CDT)
Message-Id: <200005242225.RAA76295@tiki.americas.sgi.com>
Date:   Wed, 24 May 2000 17:25:17 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Cc:     jtk@sgi.com
Subject: TAKE - Fix compiler warnings in kdbm_vm.
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.3.99pre2-xfs:slinx:62687a
Date:  Wed May 24 15:24:34 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linuxvnode

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

linux/kdb/modules/kdbm_vm.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/modules/kdbm_vm.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
	- Fix a bunch of compiler warning messages, all related to
	  the analysis of the printf string vs. arguments.



From owner-linux-xfs@oss.sgi.com Wed May 24 16:51:47 2000
Received:  by oss.sgi.com id <S42282AbQEXXvh>;
	Wed, 24 May 2000 16:51:37 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:50011 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42238AbQEXXvb>;
	Wed, 24 May 2000 16:51:31 -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 RAA24328
	for <linux-xfs@oss.sgi.com>; Wed, 24 May 2000 17:46:37 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA18682 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 25 May 2000 10:48:57 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA29272 for linux-xfs@oss.sgi.com; Thu, 25 May 2000 10:48:57 +1000 (EST)
Date:   Thu, 25 May 2000 10:48:57 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005250048.KAA29272@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix page_buf undefined symbol
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.3.99pre2-xfs:slinx:62706a
Date:  Wed May 24 17:48:36 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.3.99pre2-xfs

linux/fs/page_buf.c - 1.98
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.98&r2=text&tr2=1.97&f=h
	- fix undefined symbol


From owner-linux-xfs@oss.sgi.com Thu May 25 11:54:06 2000
Received:  by oss.sgi.com id <S42243AbQEYSx5>;
	Thu, 25 May 2000 11:53:57 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35092 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42238AbQEYSxY>; Thu, 25 May 2000 11:53:24 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA09124
	for <linux-xfs@oss.sgi.com>; Thu, 25 May 2000 12:57:35 -0700 (PDT)
	mail_from (ananth@dbear.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 MAA45205 for <linux-xfs@oss.sgi.com>; Thu, 25 May 2000 12:52:23 -0700 (PDT)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA22009
	for <linux-xfs@oss.sgi.com>;
	Thu, 25 May 2000 12:50:47 -0700 (PDT)
	mail_from (ananth@dbear.engr.sgi.com)
Received: (from ananth@localhost)
	by dbear.engr.sgi.com (8.9.3/8.8.7) id MAA25534
	for linux-xfs@oss.sgi.com; Thu, 25 May 2000 12:48:57 -0700
Date:   Thu, 25 May 2000 12:48:57 -0700
From:   Ananth Ananthanarayanan <ananth@dbear.engr.sgi.com>
Message-Id: <200005251948.MAA25534@dbear.engr.sgi.com>
Subject: TAKE - Turn ON delayed allocation
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

More stuff runs now without "VM killing process" problem.
I've tried: bonnie, aim, dbench, doio and kernel
compilation, all of which didn't show any problems.

There are a couple of water-marks which control
the amount of delayed allocation pages ...
these need to be a function of total memory
and/or amount of buffer memory. For now,
these water-marks are arbitrarily set.

ananth.


Modid:  2.3.99pre2-xfs:slinx:62763a
Date:  Thu May 25 12:47:52 PDT 2000
Workarea:  bonnie.engr.sgi.com:/build2/ananth/slinx23-xfs-tot
Author:  ananth

The following file(s) were checked into:
  bonnie:/isms/slinx/2.3.99pre2-xfs

linux/fs/page_buf.c - 1.99
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.99&r2=text&tr2=1.98&f=h
	- Fixes to delayed allocation code and better balancing of
	  memory usage. Turn ON delay_alloc.


From owner-linux-xfs@oss.sgi.com Fri May 26 09:57:48 2000
Received:  by oss.sgi.com id <S42244AbQEZQ50>;
	Fri, 26 May 2000 09:57:26 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:39800 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42250AbQEYTbm>;
	Thu, 25 May 2000 12:31:42 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA24182
	for <linux-xfs@oss.sgi.com>; Thu, 25 May 2000 13:26:19 -0700 (PDT)
	mail_from (lord@cray.com)
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA99709 for <linux-xfs@oss.sgi.com>; Thu, 25 May 2000 15:28:40 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id PAA45013 for linux-xfs@oss.sgi.com; Thu, 25 May 2000 15:28:39 -0500 (CDT)
Date:   Thu, 25 May 2000 15:28:39 -0500 (CDT)
From:   Steve Lord <lord@cray.com>
Message-Id: <200005252028.PAA45013@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - make mrlock debug code function again
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.3.99pre2-xfs:slinx:62773a
Date:  Thu May 25 13:28:17 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
Author:  lord

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

linux/fs/xfs/linux/xfs_locks.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_locks.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
linux/fs/xfs/linux/xfs_sema.h - 1.23
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_sema.h.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h
	- make the in interrupt code work again.


From owner-linux-xfs@oss.sgi.com Fri May 26 09:57:48 2000
Received:  by oss.sgi.com id <S42250AbQEZQ50>;
	Fri, 26 May 2000 09:57:26 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1580 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42302AbQEYWv1>; Thu, 25 May 2000 15:51:27 -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 QAA02261
	for <linux-xfs@oss.sgi.com>; Thu, 25 May 2000 16:55:38 -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 QAA20741 for <linux-xfs@oss.sgi.com>; Thu, 25 May 2000 16:46:23 -0700 (PDT)
Message-ID: <392DBBFF.7650739E@sgi.com>
Date:   Thu, 25 May 2000 16:49:19 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Moving XFS to 2.4.0-test1
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



Well, Linus has put out a preliminary 2.4 tree.
I just briefly looked at the difference between:

	2.3.99-pre9 -> 2.3.99-pre9 + pre10-3 patch
and     2.3.99-pre9 -> 2.4.0-test1

The changes don't look too elaborate (mostly signal
fixes, nfs fixes, some sparc update). Most importantly,
there are NO changes to core VM! Which, hopefully,
means that the VM problems are starting to get tackled.

XFS has been on pre2 almost exactly 2 months now.
And it seems 2.4.0-test1 is the next right kernel to move to.
Does anyone have opinions about vanilla 2.4.0-test1?


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

From owner-linux-xfs@oss.sgi.com Fri May 26 09:57:48 2000
Received:  by oss.sgi.com id <S42302AbQEZQ51>;
	Fri, 26 May 2000 09:57:27 -0700
Received: from lips.borg.umn.edu ([160.94.232.50]:16389 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S42316AbQEZBHK>;
	Thu, 25 May 2000 18:07:10 -0700
Received: (from cattelan@localhost)
	by lips.borg.umn.edu (8.10.0/8.10.0) id e4Q26dF48523
	for linux-xfs@oss.sgi.com; Thu, 25 May 2000 21:06:39 -0500 (CDT)
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by lips.borg.umn.edu (8.10.0/8.10.0) with ESMTP id e4Q26cO48515
	for <cattelan@thebarn.com>; Thu, 25 May 2000 21:06:38 -0500 (CDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA00721; Thu, 25 May 2000 19:11:18 -0700 (PDT)
	mail_from (owner-slinx-xfs@cthulhu.engr.sgi.com)
Received: (from majordomo-owner@localhost)
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	id TAA46430
	for slinx-xfs-list;
	Thu, 25 May 2000 19:06:26 -0700 (PDT)
	mail_from (owner-slinx-xfs@relay.engr.sgi.com)
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id TAA27425
	for <slinx-xfs@cthulhu.engr.sgi.com>;
	Thu, 25 May 2000 19:06:25 -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 TAA21713 for <slinx-xfs@engr>; Thu, 25 May 2000 19:03:07 -0700 (PDT)
Message-ID: <392DDC0A.E18A57FE@sgi.com>
Date:   Thu, 25 May 2000 19:06:02 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     slinx-xfs@cthulhu.engr.sgi.com
Subject: [Fwd: Moving XFS to 2.4.0-test1]
Content-Type: multipart/mixed;
 boundary="------------E2D38D1FD3271F911E91978F"
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.
--------------E2D38D1FD3271F911E91978F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


[ For some reason an earlier mail sent to linux-xfs@oss
  seems to have gone into the ether ... resending to slinx-xfs ]
--------------E2D38D1FD3271F911E91978F
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Message-ID: <392DBBFF.7650739E@sgi.com>
Date: Thu, 25 May 2000 16:49:19 -0700
From: Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Moving XFS to 2.4.0-test1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Well, Linus has put out a preliminary 2.4 tree.
I just briefly looked at the difference between:

	2.3.99-pre9 -> 2.3.99-pre9 + pre10-3 patch
and     2.3.99-pre9 -> 2.4.0-test1

The changes don't look too elaborate (mostly signal
fixes, nfs fixes, some sparc update). Most importantly,
there are NO changes to core VM! Which, hopefully,
means that the VM problems are starting to get tackled.

XFS has been on pre2 almost exactly 2 months now.
And it seems 2.4.0-test1 is the next right kernel to move to.
Does anyone have opinions about vanilla 2.4.0-test1?


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

--------------E2D38D1FD3271F911E91978F--


From owner-linux-xfs@oss.sgi.com Fri May 26 09:57:55 2000
Received:  by oss.sgi.com id <S42301AbQEZQ51>;
	Fri, 26 May 2000 09:57:27 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:17769 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42317AbQEZP4w>; Fri, 26 May 2000 08:56:52 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA04431
	for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 08:57:40 -0700 (PDT)
	mail_from (lord@cray.com)
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA35888 for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 10:51:42 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id KAA57421 for linux-xfs@oss.sgi.com; Fri, 26 May 2000 10:51:42 -0500 (CDT)
Date:   Fri, 26 May 2000 10:51:42 -0500 (CDT)
From:   Steve Lord <lord@cray.com>
Message-Id: <200005261551.KAA57421@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix page_buf module loading
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.3.99pre2-xfs:slinx:62897a
Date:  Fri May 26 08:51:18 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
Author:  lord

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

linux/kernel/ksyms.c - 1.46
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kernel/ksyms.c.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h
	- Added new symbol to exports for page_buf as a module


From owner-linux-xfs@oss.sgi.com Fri May 26 09:57:56 2000
Received:  by oss.sgi.com id <S42329AbQEZQ51>;
	Fri, 26 May 2000 09:57:27 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:17769 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42318AbQEZP4w>; Fri, 26 May 2000 08:56:52 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA05426
	for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 08:59:51 -0700 (PDT)
	mail_from (lord@cray.com)
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA73772; Fri, 26 May 2000 10:53:47 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id KAA48734; Fri, 26 May 2000 10:53:48 -0500 (CDT)
Date:   Fri, 26 May 2000 10:53:48 -0500 (CDT)
From:   Steve Lord <lord@cray.com>
Message-Id: <200005261553.KAA48734@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Cc:     kaos@melbourne.sgi.com
Subject: TAKE - make kdbm_pb module loadable again
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.3.99pre2-xfs:slinx:62898a
Date:  Fri May 26 08:53:11 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
Author:  lord

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

linux/arch/i386/kernel/i386_ksyms.c - 1.24
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kernel/i386_ksyms.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h
	- export kdb_print_symbol

linux/include/linux/kdb.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kdb.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
	- prototype for kdb_print_symbol


From owner-linux-xfs@oss.sgi.com Fri May 26 09:57:56 2000
Received:  by oss.sgi.com id <S42338AbQEZQ51>;
	Fri, 26 May 2000 09:57:27 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:17181 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42327AbQEZQVo>;
	Fri, 26 May 2000 09:21:44 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id EAA19558
	for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 04:25:16 -0700 (PDT)
	mail_from (lord@cray.com)
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id GAA01373 for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 06:28:52 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id GAA03671 for linux-xfs@oss.sgi.com; Fri, 26 May 2000 06:28:53 -0500 (CDT)
Date:   Fri, 26 May 2000 06:28:53 -0500 (CDT)
From:   Steve Lord <lord@cray.com>
Message-Id: <200005261128.GAA03671@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - merge kdb fixes into XFS tree
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Standardize on kdb_symbol_print
Correct bph/ss debug handling
Special case for error_code

Modid:  2.3.99pre2-xfs:slinx:62892a
Date:  Fri May 26 04:28:15 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/slinx
Author:  kaos
Merged by:  lord
Merged mods:  2.3.99pre2-kdb:slinx:62892a

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

linux/arch/i386/kdb/Makefile - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/arch/i386/kdb/kdba_bp.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/kdba_bp.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/arch/i386/kdb/kdba_bt.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/kdba_bt.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/arch/i386/kdb/kdba_id.c - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/kdba_id.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
linux/arch/i386/kdb/kdbasupport.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/kdbasupport.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/include/linux/kdb.h - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kdb.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/include/linux/kdbprivate.h - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kdbprivate.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
linux/kdb/kdb_bp.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdb_bp.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/kdb/kdbmain.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdbmain.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/kdb/kdbsupport.c - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdbsupport.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
linux/kdb/modules/kdbm_pb.c - 1.21
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/modules/kdbm_pb.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h
	- Merge of 2.3.99pre2-kdb:slinx:62892a by lord.


From owner-linux-xfs@oss.sgi.com Fri May 26 09:57:56 2000
Received:  by oss.sgi.com id <S42340AbQEZQ52>;
	Fri, 26 May 2000 09:57:28 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:18213 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42333AbQEZQm3>;
	Fri, 26 May 2000 09:42:29 -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 TAA08055
	for <linux-xfs@oss.sgi.com>; Thu, 25 May 2000 19:38:20 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA27890 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Fri, 26 May 2000 12:41:55 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA36117 for linux-xfs@oss.sgi.com; Fri, 26 May 2000 12:41:48 +1000 (EST)
Date:   Fri, 26 May 2000 12:41:48 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005260241.MAA36117@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix type warnings in xfs_log_recover
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.3.99pre2-xfs:slinx:62865a
Date:  Thu May 25 19:41:26 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.3.99pre2-xfs

linux/fs/xfs/xfs_log_recover.c - 1.182
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.182&r2=text&tr2=1.181&f=h
	- fix type warnings


From owner-linux-xfs@oss.sgi.com Fri May 26 09:57:57 2000
Received:  by oss.sgi.com id <S42251AbQEZQ53>;
	Fri, 26 May 2000 09:57:29 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:32119 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42249AbQEYT2r>;
	Thu, 25 May 2000 12:28:47 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA23730
	for <linux-xfs@oss.sgi.com>; Thu, 25 May 2000 13:23:13 -0700 (PDT)
	mail_from (lord@cray.com)
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA50404 for <linux-xfs@oss.sgi.com>; Thu, 25 May 2000 15:25:34 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id PAA54666 for linux-xfs@oss.sgi.com; Thu, 25 May 2000 15:25:34 -0500 (CDT)
Date:   Thu, 25 May 2000 15:25:34 -0500 (CDT)
From:   Steve Lord <lord@cray.com>
Message-Id: <200005252025.PAA54666@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - speed up remove path
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.3.99pre2-xfs:slinx:62770a
Date:  Thu May 25 13:25:10 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
Author:  lord

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

linux/fs/xfs/xfs_inode.c - 1.289
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.289&r2=text&tr2=1.288&f=h
	- A couple of changes to make the reclaim path faster when it follows
	  hard on the heels of an inactive on an unlinked file. The vnode in
	  the linux inode code makes this happen all the time when we remove
	  files, this speeds up removes a lot.


From owner-linux-xfs@oss.sgi.com Fri May 26 10:06:56 2000
Received:  by oss.sgi.com id <S42249AbQEZRGg>;
	Fri, 26 May 2000 10:06:36 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:16174 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42247AbQEZRG2>;
	Fri, 26 May 2000 10:06:28 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA05538
	for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 11:01:35 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA45502 for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 13:03:56 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id NAA25508; Fri, 26 May 2000 13:03:54 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id NAA23687; Fri, 26 May 2000 13:03:54 -0500 (CDT)
Message-Id: <200005261803.NAA23687@tiki.americas.sgi.com>
Date:   Fri, 26 May 2000 13:03:54 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Cc:     jtk@sgi.com
Subject: TAKE - Minor ifdef change to prevent BUG() call on unmount.
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.3.99pre2-xfs:slinx:62917a
Date:  Fri May 26 11:02:43 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linux2.3-99

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

linux/fs/xfs/linux/xfs_super.c - 1.67
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c.diff?r1=text&tr1=1.67&r2=text&tr2=1.66&f=h
	- #ifdef the call to pagebuf_delwri_flush on CONFIG_PAGE_BUF_META.
	  This will likely come back out in a few days, but for now is needed.



From owner-linux-xfs@oss.sgi.com Fri May 26 10:09:56 2000
Received:  by oss.sgi.com id <S42247AbQEZRJq>;
	Fri, 26 May 2000 10:09:46 -0700
Received: from puchatek.el.com.pl ([195.82.161.1]:49184 "EHLO convert rfc822-to-8bitt=ok3 [E	H
        puchatek.el.com.pl") by oss.sgi.com with ESMTP id <S42246AbQEZRJg>;
	Fri, 26 May 2000 10:09:36 -0700
Received: from host (sdn-ar-002riprovP276.dialsprint.net [168.191.126.206])
	by puchatek.el.com.pl (8.8.7/8.8.7) with ESMTP id DAA26697;
	Fri, 26 May 2000 03:45:23 +0200
Message-Id: <200005260145.DAA26697@puchatek.el.com.pl>
From:   "Sandy W." <hhtom23@bizland.com>
Subject: Your Choice... #7E3F
To:     today@puchatek.el.com.pl
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date:   Thu, 25 May 2000 21:44: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

Start your own 1-900 business or Adult Web Site Business!

People are making $$$ week, after week in the 1-900 business.  We'll
teach you all of our incredible secrets that will take your new
exciting business to a whole new level!

It's The Simplest and Most Exciting Business You Could Ever Start!

*You'll use our "state" of the art equipment!
*You'll use our "Live 1 on 1 Psychics" & "Chat Line" girls!
*You'll use our incredible Date Line program(s)!

No chargebacks! 
Quick payouts! 
No expertise needed!

Complete programs start at only $99 (no additional charges)

The only thing you'll have to do is advertise! This is an excellent 
turnkey business.

We also have excellent turnkey programs if you want to own your own 
"top" of the line adult web site.

ACT NOW!!!


For a free color brochure:
reply to: mailto:sawyr@yahoo.com?subject=brochure
With the following information:

          Name:_________________
       Address:_________________
City/State/Zip:_________________
 email address:_________________
     Telephone:_________________ (optional)

///////////////////////////////////////////////////
To be removed permanantly from this list reply to:
mailto:keyst2p@netscape.net?subject=remove
///////////////////////////////////////////////////




From owner-linux-xfs@oss.sgi.com Fri May 26 10:11:26 2000
Received:  by oss.sgi.com id <S42252AbQEZRLQ>;
	Fri, 26 May 2000 10:11:16 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:62256 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42246AbQEZRKz>;
	Fri, 26 May 2000 10:10:55 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA06586
	for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 11:06:02 -0700 (PDT)
	mail_from (lord@cray.com)
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA22064 for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 13:08:23 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id NAA22042 for linux-xfs@oss.sgi.com; Fri, 26 May 2000 13:08:23 -0500 (CDT)
Date:   Fri, 26 May 2000 13:08:23 -0500 (CDT)
From:   Steve Lord <lord@cray.com>
Message-Id: <200005261808.NAA22042@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix xfs locking code problems on SMP systems
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.3.99pre2-xfs:slinx:62918a
Date:  Fri May 26 11:07:48 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
Author:  lord

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

linux/fs/xfs/linux/xfs_locks.c - 1.19
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_locks.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h
	- add irq handling to mrlocks - we do unlocks from interrupt threads
	  and this was messing things up when two cpus went for the same
	  lock at the same time. Also fix sv_broadcast to really do broadcast.

linux/fs/xfs/linux/xfs_sema.h - 1.24
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_sema.h.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h
	- remove dead code


From owner-linux-xfs@oss.sgi.com Fri May 26 10:11:56 2000
Received:  by oss.sgi.com id <S42253AbQEZRLq>;
	Fri, 26 May 2000 10:11:46 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:22833 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42246AbQEZRL0>;
	Fri, 26 May 2000 10:11:26 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA06745
	for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 11:06:34 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA39927 for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 13:08:54 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id NAA25747; Fri, 26 May 2000 13:08:53 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id NAA25178; Fri, 26 May 2000 13:08:52 -0500 (CDT)
Message-Id: <200005261808.NAA25178@tiki.americas.sgi.com>
Date:   Fri, 26 May 2000 13:08:52 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Cc:     jtk@sgi.com
Subject: TAKE - Fix create/unlink race on the same inode #.
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.3.99pre2-xfs:slinx:62919a
Date:  Fri May 26 11:08:06 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linux2.3-99

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

linux/fs/xfs/xfs_iget.c - 1.116
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_iget.c.diff?r1=text&tr1=1.116&r2=text&tr2=1.115&f=h
	- In xfs_iget(), do the vn_get() under protection of the hash queue
	  lock in order to guarantee that the linux inode address is truly
	  valid at the moment we're looking for the I_FREEING flag.



From owner-linux-xfs@oss.sgi.com Fri May 26 10:17:26 2000
Received:  by oss.sgi.com id <S42254AbQEZRRQ>;
	Fri, 26 May 2000 10:17:16 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:28468 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42246AbQEZRRC>;
	Fri, 26 May 2000 10:17:02 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA08126
	for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 11:12:09 -0700 (PDT)
	mail_from (lord@cray.com)
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA53919 for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 13:14:29 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id NAA53265 for linux-xfs@oss.sgi.com; Fri, 26 May 2000 13:14:29 -0500 (CDT)
Date:   Fri, 26 May 2000 13:14:29 -0500 (CDT)
From:   Steve Lord <lord@cray.com>
Message-Id: <200005261814.NAA53265@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix possible log pauses
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 case where we ended up replying some other thread to come along
and push iclogs out to disk to wake us up again.

Modid:  2.3.99pre2-xfs:slinx:62921a
Date:  Fri May 26 11:12:55 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/xfs-linux
Author:  lord

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

linux/fs/xfs/xfs_log.c - 1.218
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.218&r2=text&tr2=1.217&f=h
	- When flushing the xfs log to disk and we find the iclog we are
	  interested in, but a previous log record has not yet started out
	  to disk, we sleep. However, we sleep on our iclog rather than
	  the one which must go to disk first. Change this to sleep on
	  the previous iclog, this way we do not rely on some other thread
	  coming along and pushing the log for us.


From owner-linux-xfs@oss.sgi.com Fri May 26 11:28:06 2000
Received:  by oss.sgi.com id <S42266AbQEZS14>;
	Fri, 26 May 2000 11:27:56 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:43644 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42246AbQEZS1s>; Fri, 26 May 2000 11:27:48 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA01171
	for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 12:32:30 -0700 (PDT)
	mail_from (cattelan@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA50363 for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 14:26:31 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id OAA29172 for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 14:26:30 -0500 (CDT)
From:   Russell Cattelan <cattelan@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id OAA37116; Fri, 26 May 2000 14:26:29 -0500 (CDT)
Message-Id: <200005261926.OAA37116@nt8.americas.sgi.com>
Date:   Fri, 26 May 2000 14:26:29 -0500 (CDT)
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.3.99pre2-xfs:slinx:62933a
Date:  Fri May 26 12:25:18 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs
Author:  cattelan

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

linux/fs/page_buf.c - 1.100
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.100&r2=text&tr2=1.99&f=h
	- Removed incorrect warning message.
	  moved and few debug flags and make them exported them.

linux/fs/xfs/linux/xfs_lrw.c - 1.41
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h
	- implemented the pb_iorequest call out that checks for
	  a "shutdown" file system.

linux/include/linux/mm.h - 1.32
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/mm.h.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h
	- flip the vaild bits on a page... 0 now means invalid, 1 means valid.


From owner-linux-xfs@oss.sgi.com Fri May 26 11:33:57 2000
Received:  by oss.sgi.com id <S42267AbQEZSdr>;
	Fri, 26 May 2000 11:33:47 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:11645 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42246AbQEZSdm>; Fri, 26 May 2000 11:33:42 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA08686
	for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 12:38:23 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA34104 for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 14:32:25 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id OAA29466 for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 14:32:25 -0500 (CDT)
Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e4QJWK719520
	for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 14:32:20 -0500
Message-ID: <392ED143.A72C5CF6@thebarn.com>
Date:   Fri, 26 May 2000 14:32:19 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: HEADS UP type fixes comming
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'm have most of XFS working the overlapping types changed to
xfs_<type>.
I will be check the changes in as soon as I resolve one problem with
fsid_t,
hopefully later today.


-Russell


From owner-linux-xfs@oss.sgi.com Fri May 26 12:05:37 2000
Received:  by oss.sgi.com id <S42268AbQEZTFR>;
	Fri, 26 May 2000 12:05:17 -0700
Received: from mta6.snfc21.pbi.net ([206.13.28.240]:54204 "EHLO
        mta6.snfc21.pbi.net") by oss.sgi.com with ESMTP id <S42246AbQEZTFC>;
	Fri, 26 May 2000 12:05:02 -0700
Received: from pacbell.net ([216.101.234.30])
 by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with ESMTP id <0FV600B8VNS2UT@mta6.snfc21.pbi.net> for linux-xfs@oss.sgi.com;
 Fri, 26 May 2000 13:04:50 -0700 (PDT)
Date:   Fri, 26 May 2000 12:55:45 -0700
From:   Nasser Abbasi <nabbasi@pacbell.net>
Subject: CVS access problem to xfs. please help.
To:     linux-xfs@oss.sgi.com
Message-id: <392ED6C1.6BA193BC@pacbell.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.3.99-pre5 i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <392ED143.A72C5CF6@thebarn.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hello, following instructions on :

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

I get lock error:

---- output---

>export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs'
>cvs login
(Logging in to cvs@oss.sgi.com)
CVS password:
>cvs -z3 checkout linux-2.3-xfs
cvs server: Updating linux-2.3-xfs
cvs server: Updating linux-2.3-xfs/SCRIPTS
cvs server: failed to create lock directory in repository `/cvs/linux-2.3-xfs/SCRIPTS': Permission denied
cvs server: failed to obtain dir lock in repository `/cvs/linux-2.3-xfs/SCRIPTS'
cvs [server aborted]: read lock failed - giving up
>

---- end of output---

I basically need the xfs source tree. Is there a place
I can get that? saw tha patch file, but need the actuall sources.
what is the best way to do that?

regards,
Nasser

From owner-linux-xfs@oss.sgi.com Fri May 26 12:46:27 2000
Received:  by oss.sgi.com id <S42270AbQEZTqS>;
	Fri, 26 May 2000 12:46:18 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:52067 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42265AbQEZTqL>;
	Fri, 26 May 2000 12:46:11 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA28829
	for <linux-xfs@oss.sgi.com>; Fri, 26 May 2000 13:41:18 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA83138; Fri, 26 May 2000 15:43:37 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id PAA03198; Fri, 26 May 2000 15:43:36 -0500 (CDT)
Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e4QKhV719623;
	Fri, 26 May 2000 15:43:31 -0500
Message-ID: <392EE1F2.B7E8CC17@thebarn.com>
Date:   Fri, 26 May 2000 15:43:30 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Nasser Abbasi <nabbasi@pacbell.net>
CC:     linux-xfs@oss.sgi.com
Subject: Re: CVS access problem to xfs. please help.
References: <392ED143.A72C5CF6@thebarn.com> <392ED6C1.6BA193BC@pacbell.net>
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

Nasser Abbasi wrote:

> hello, following instructions on :
>
>  http://oss.sgi.com/projects/xfs/cvs_download.html
>
> I get lock error:
>
>
Ok give me minute or so...
I'll get it fixed.

>
> ---- output---
>
> >export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs'
> >cvs login
> (Logging in to cvs@oss.sgi.com)
> CVS password:
> >cvs -z3 checkout linux-2.3-xfs
> cvs server: Updating linux-2.3-xfs
> cvs server: Updating linux-2.3-xfs/SCRIPTS
> cvs server: failed to create lock directory in repository `/cvs/linux-2.3-xfs/SCRIPTS': Permission denied
> cvs server: failed to obtain dir lock in repository `/cvs/linux-2.3-xfs/SCRIPTS'
> cvs [server aborted]: read lock failed - giving up
> >
>
> ---- end of output---
>
> I basically need the xfs source tree. Is there a place
> I can get that? saw tha patch file, but need the actuall sources.
> what is the best way to do that?
>
> regards,
> Nasser


From owner-linux-xfs@oss.sgi.com Fri May 26 19:36:21 2000
Received:  by oss.sgi.com id <S42272AbQE0CgB>;
	Fri, 26 May 2000 19:36:01 -0700
Received: from mta5.snfc21.pbi.net ([206.13.28.241]:45700 "EHLO
        mta5.snfc21.pbi.net") by oss.sgi.com with ESMTP id <S42271AbQE0Cfk>;
	Fri, 26 May 2000 19:35:40 -0700
Received: from pacbell.net ([216.101.234.30])
 by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with ESMTP id <0FV70060W8NBBT@mta5.snfc21.pbi.net> for linux-xfs@oss.sgi.com;
 Fri, 26 May 2000 20:35:35 -0700 (PDT)
Date:   Fri, 26 May 2000 20:26:33 -0700
From:   Nasser Abbasi <nabbasi@pacbell.net>
Subject: status of xfs cvs tree. link error building latest cvs.
 xfs_vfsops.c:466: undefined reference to `buf_zone'
To:     linux-xfs@oss.sgi.com
Message-id: <392F4069.2A727681@pacbell.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.3.99-pre5 i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <392ED143.A72C5CF6@thebarn.com> <392ED6C1.6BA193BC@pacbell.net>
 <392EE1F2.B7E8CC17@thebarn.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Hello,

I just started to look at xfs, and I'd like to learn the
status of the xfs in the cvs tree. I downloaded today 5/26/00 
the following:
 
export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs'
cvs -z3 checkout linux-2.3-xfs


Then turned on XFS using make xconfig (build in kernel), but 
when it builds, I get a build error. 

My question is, should not xfs in cvs tree always have a
clean build? 

I am using

>gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

>uname -a
Linux linux 2.3.99-pre5 #3 SMP Sun May 14 21:17:17 PDT 2000 i686 unknown

I did make dep; make at the linux directory level, and this is the
build error: (undefined symbol)

---------------
ar  rcs lib.a  checksum.o old-checksum.o delay.o usercopy.o getuser.o putuser.o iodebug.o divdi3.o
make[2]: Leaving directory `/export/g/nabbasi/download/linux-2.3-xfs/linux/arch/i386/lib'
make[1]: Leaving directory `/export/g/nabbasi/download/linux-2.3-xfs/linux/arch/i386/lib'
ld -m elf_i386 -T /export/g/nabbasi/download/linux-2.3-xfs/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/block/block.a drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/parport/parport.a  drivers/char/drm/drm.o drivers/ide/ide.a drivers/scsi/scsi.a drivers/cdrom/cdrom.a drivers/pci/pci.a
drivers/pcmcia/pcmcia.o drivers/net/pcmcia/pcmcia_net.o drivers/pnp/pnp.o drivers/video/video.o net/network.a /export/g/nabbasi/download/linux-2.3-xfs/linux/arch/i386/lib/lib.a /export/g/nabbasi/download/linux-2.3-xfs/linux/lib/lib.a /export/g/nabbasi/download/linux-2.3-xfs/linux/arch/i386/lib/lib.a --end-group  -o vmlinux
fs/fs.o: In function `xfs_cleanup':
/export/g/nabbasi/download/linux-2.3-xfs/linux/fs/xfs/xfs_vfsops.c:466: undefined reference to `buf_zone'
make: *** [vmlinux] Error 1
-------------------

thanks,
Nasser

From owner-linux-xfs@oss.sgi.com Fri May 26 23:18:02 2000
Received:  by oss.sgi.com id <S42274AbQE0GRn>;
	Fri, 26 May 2000 23:17:43 -0700
Received: from adsl-63-203-38-107.dsl.snfc21.pacbell.net ([63.203.38.107]:60040
        "EHLO adsl-63-203-38-107.dsl.snfc21.pacbell.net") by oss.sgi.com
	with ESMTP id <S42273AbQE0GRY>; Fri, 26 May 2000 23:17:24 -0700
Received: from eventdriven.org (IDENT:root@goober.extendedsolutions.com [63.203.38.107])
	by adsl-63-203-38-107.dsl.snfc21.pacbell.net (8.9.3/8.9.3) with ESMTP id AAA12570;
	Sat, 27 May 2000 00:17:29 -0700
Message-ID: <392F767C.533CDBBB@eventdriven.org>
Date:   Sat, 27 May 2000 00:17:16 -0700
From:   Kip Macy <kip@eventdriven.org>
Organization: Extended Solutions Inc.
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Nasser Abbasi <nabbasi@pacbell.net>
CC:     linux-xfs@oss.sgi.com
Subject: Re: status of xfs cvs tree. link error building latest 
 cvs.xfs_vfsops.c:466: undefined reference to `buf_zone'
References: <392ED143.A72C5CF6@thebarn.com> <392ED6C1.6BA193BC@pacbell.net>
	 <392EE1F2.B7E8CC17@thebarn.com> <392F4069.2A727681@pacbell.net>
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,
You need to turn "Use PAGEBUF for XFS metadata I/O" on
in order for it to compile.

				-Kip

Nasser Abbasi wrote:
> 
> Hello,
> 
> I just started to look at xfs, and I'd like to learn the
> status of the xfs in the cvs tree. I downloaded today 5/26/00
> the following:
> 
> export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs'
> cvs -z3 checkout linux-2.3-xfs
> 
> Then turned on XFS using make xconfig (build in kernel), but
> when it builds, I get a build error.
> 
> My question is, should not xfs in cvs tree always have a
> clean build?
> 
> I am using
> 
> >gcc -v
> Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/specs
> gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
> 
> >uname -a
> Linux linux 2.3.99-pre5 #3 SMP Sun May 14 21:17:17 PDT 2000 i686 unknown
> 
> I did make dep; make at the linux directory level, and this is the
> build error: (undefined symbol)
> 
> ---------------
> ar  rcs lib.a  checksum.o old-checksum.o delay.o usercopy.o getuser.o putuser.o iodebug.o divdi3.o
> make[2]: Leaving directory `/export/g/nabbasi/download/linux-2.3-xfs/linux/arch/i386/lib'
> make[1]: Leaving directory `/export/g/nabbasi/download/linux-2.3-xfs/linux/arch/i386/lib'
> ld -m elf_i386 -T /export/g/nabbasi/download/linux-2.3-xfs/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/block/block.a drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/parport/parport.a  drivers/char/drm/drm.o drivers/ide/ide.a drivers/scsi/scsi.a drivers/cdrom/cdrom.a drivers/pci/pci.a
> drivers/pcmcia/pcmcia.o drivers/net/pcmcia/pcmcia_net.o drivers/pnp/pnp.o drivers/video/video.o net/network.a /export/g/nabbasi/download/linux-2.3-xfs/linux/arch/i386/lib/lib.a /export/g/nabbasi/download/linux-2.3-xfs/linux/lib/lib.a /export/g/nabbasi/download/linux-2.3-xfs/linux/arch/i386/lib/lib.a --end-group  -o vmlinux
> fs/fs.o: In function `xfs_cleanup':
> /export/g/nabbasi/download/linux-2.3-xfs/linux/fs/xfs/xfs_vfsops.c:466: undefined reference to `buf_zone'
> make: *** [vmlinux] Error 1
> -------------------
> 
> thanks,
> Nasser

From owner-linux-xfs@oss.sgi.com Sat May 27 01:13:22 2000
Received:  by oss.sgi.com id <S42273AbQE0INC>;
	Sat, 27 May 2000 01:13:02 -0700
Received: from mta6.snfc21.pbi.net ([206.13.28.240]:16542 "EHLO
        mta6.snfc21.pbi.net") by oss.sgi.com with ESMTP id <S42271AbQE0IMo>;
	Sat, 27 May 2000 01:12:44 -0700
Received: from pacbell.net ([216.101.234.30])
 by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with ESMTP id <0FV70098SO84AT@mta6.snfc21.pbi.net> for linux-xfs@oss.sgi.com;
 Sat, 27 May 2000 02:12:05 -0700 (PDT)
Date:   Sat, 27 May 2000 02:03:04 -0700
From:   Nasser Abbasi <nabbasi@pacbell.net>
Subject: Re: status of xfs cvs tree. link error building
 latestcvs.xfs_vfsops.c:466: undefined reference to `buf_zone'
To:     linux-xfs@oss.sgi.com
Message-id: <392F8F48.EDCBBC30@pacbell.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.3.99-pre5 i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <392ED143.A72C5CF6@thebarn.com> <392ED6C1.6BA193BC@pacbell.net>
 <392EE1F2.B7E8CC17@thebarn.com> <392F4069.2A727681@pacbell.net>
 <392F767C.533CDBBB@eventdriven.org>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Kip Macy wrote:
> 
> Hi,
> You need to turn "Use PAGEBUF for XFS metadata I/O" on
> in order for it to compile.

thanks, that worked.

the make xconfig part for xfs seems not to behave in consistent way.

I do 

make mrproper
make xconfig

then click 'Y' for SGI XFS file system, you will see that 'Y' is
automatically turned on for the following 3 entries below it
(Page buffer support, Page buffer locking, Generic AVL).

But the 'use PAGEBUF for metadata I/O' is NOT turned on. Now click 'Y'
for 'use PAGBUF for metadata I/O'. 

Now click 'N' for "SGI XFS file system support", you will see 
that 'use PAGBUF for metadata I/O' is turned off, but the Page 
buffer support, Page buffer locking, Generic AVL remain turned
on showing 'Y' (bug).

Now, click 'Y' again for "SGI XFS file system support", now you will 
see "use PAGEBUF for metadata I/O" turn back to 'Y'. Which is not
the same behavior as before. (bug)

If "use PAGEBUF for mertadata I/O" is needed for clean build when
saying 'Y' to SGI file support, then it should automatically get
turned on to 'Y' first time.

Nasser

From owner-linux-xfs@oss.sgi.com Sat May 27 10:54:45 2000
Received:  by oss.sgi.com id <S42284AbQE0Ry0>;
	Sat, 27 May 2000 10:54:26 -0700
Received: from adsl-63-203-38-107.dsl.snfc21.pacbell.net ([63.203.38.107]:57994
        "EHLO adsl-63-203-38-107.dsl.snfc21.pacbell.net") by oss.sgi.com
	with ESMTP id <S42283AbQE0Rxy>; Sat, 27 May 2000 10:53:54 -0700
Received: from eventdriven.org (IDENT:root@goober.extendedsolutions.com [63.203.38.107])
	by adsl-63-203-38-107.dsl.snfc21.pacbell.net (8.9.3/8.9.3) with ESMTP id LAA13348
	for <linux-xfs@oss.sgi.com>; Sat, 27 May 2000 11:53:32 -0700
Message-ID: <393019AB.6C30471E@eventdriven.org>
Date:   Sat, 27 May 2000 11:53:32 -0700
From:   Kip Macy <kip@eventdriven.org>
Organization: Extended Solutions Inc.
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.99-pre2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: cvs not responding
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

cvs -z3 update -d hangs:

the tail of strace is:

connect(3, {sin_family=AF_INET, sin_port=htons(2401),
sin_addr=inet_addr("216.32.174.118")}}, 16) = 0
access("/root/.cvspass", F_OK)          = 0
chmod("/root/.cvspass", 0600)           = 0
open("/root/.cvspass", O_RDONLY)        = 4
fstat64(0x4, 0xbffff788)                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40015000
read(4, ":pserver:cvs@oss.sgi.com:/cvs Ah"..., 4096) = 35
close(4)                                = 0
munmap(0x40015000, 4096)                = 0
send(3, "BEGIN AUTH REQUEST\n", 19, 0)  = 19
send(3, "/cvs", 4, 0)                   = 4
send(3, "\n", 1, 0)                     = 1
send(3, "cvs", 3, 0)                    = 3
send(3, "\n", 1, 0)                     = 1
send(3, "Ah<Z", 4, 0)                   = 4
send(3, "\n", 1, 0)                     = 1
send(3, "END AUTH REQUEST\n", 17, 0)    = 17
recv(3,

From owner-linux-xfs@oss.sgi.com Mon May 29 18:06:25 2000
Received:  by oss.sgi.com id <S42327AbQE3BGH>;
	Mon, 29 May 2000 18:06:07 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:15672 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42306AbQE0XmL>; Sat, 27 May 2000 16:42:11 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA08266
	for <linux-xfs@oss.sgi.com>; Sat, 27 May 2000 17:46:24 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id TAA27413 for <linux-xfs@oss.sgi.com>; Sat, 27 May 2000 19:40:24 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id TAA29632; Sat, 27 May 2000 19:40:23 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id TAA25916; Sat, 27 May 2000 19:40:22 -0500 (CDT)
Message-Id: <200005280040.TAA25916@tiki.americas.sgi.com>
Date:   Sat, 27 May 2000 19:40:22 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Cc:     jtk@sgi.com
Subject: TAKE - Minor 'unresolved buf_zone' fix.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

For some strange reason, as a MODULE, the reference to buf_zone
was somehow resolved, but when built into the kernel, it was not.

Modid:  2.3.99pre2-xfs:slinx:62967a
Date:  Sat May 27 17:38:22 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linux2.3-99

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

linux/fs/xfs/xfs_vfsops.c - 1.269
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vfsops.c.diff?r1=text&tr1=1.269&r2=text&tr2=1.268&f=h
	- Don't destroy buf_zone if it wasn't allocated.

linux/fs/xfs/linux/xfs_fs_bio.c - 1.33
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_fs_bio.c.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h
	- Remove the 'static' from buf_zone.



From owner-linux-xfs@oss.sgi.com Mon May 29 18:06:25 2000
Received:  by oss.sgi.com id <S42335AbQE3BGG>;
	Mon, 29 May 2000 18:06:06 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:63095 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42334AbQE2XvR>; Mon, 29 May 2000 16:51:17 -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 RAA07353
	for <linux-xfs@oss.sgi.com>; Mon, 29 May 2000 17:48:05 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA23305 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 30 May 2000 10:42:01 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA02105 for linux-xfs@oss.sgi.com; Tue, 30 May 2000 10:42:00 +1000 (EST)
Date:   Tue, 30 May 2000 10:42:00 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200005300042.KAA02105@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix bug in vfs_busydev
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 the bug I just encountered, but isn't this function
just plain broken?

ie what happens if there _are_ multiple entries with the same
dev_t and the one with the type you want isn't returned by
lookup_vfsmnt? doesn't it get returned anyway?

Modid:  2.3.99pre2-xfs:slinx:62975a
Date:  Mon May 29 17:36:31 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.3.99pre2-xfs

linux/fs/xfs/linux/xfs_vfs.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_vfs.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
	- fix MKDEV


From owner-linux-xfs@oss.sgi.com Mon May 29 18:06:25 2000
Received:  by oss.sgi.com id <S42295AbQE3BGG>;
	Mon, 29 May 2000 18:06:06 -0700
Received: from Cantor.suse.de ([194.112.123.193]:33287 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42328AbQE2Xd4>;
	Mon, 29 May 2000 16:33:56 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP id 96E1C1E190
	for <linux-xfs@oss.sgi.com>; Sun, 28 May 2000 21:11:29 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP id 5E83A10A026
	for <linux-xfs@oss.sgi.com>; Sun, 28 May 2000 21:11:29 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id E0C412F300; Sun, 28 May 2000 21:11:27 +0200 (MEST)
Date:   Sun, 28 May 2000 21:11:27 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     linux-xfs@oss.sgi.com
Subject: [patch] fix endian for cross compilers
Message-ID: <20000528211127.A31824@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Cross compiling between different byte orders does not work with the current
tree, because XFS uses the byte order defines from the host's libc. This 
patch fixes it for Linux by making it use the kernel includes.


-Andi


--- linux/fs/xfs/xfs_arch.h-o	Sat May 27 12:15:23 2000
+++ linux/fs/xfs/xfs_arch.h	Sun May 28 21:04:47 2000
@@ -39,7 +39,11 @@
 
 #include <linux/autoconf.h>
 #include "xfs_types.h"
+#ifdef __KERNEL__
+#include <asm/byteorder.h> 
+#else
 #include <endian.h>
+#endif
 
 /* sanity checks */
 
--- linux/fs/xfs/xfs_bmap_btree.h-o	Sat May 27 12:15:24 2000
+++ linux/fs/xfs/xfs_bmap_btree.h	Sun May 28 21:05:20 2000
@@ -35,7 +35,11 @@
 #ident "$Revision: 1.47 $"
 
 #include "xfs_buf.h"
+#ifdef __KERNEL__
+#include <asm/byteorder.h>
+#else
 #include <endian.h>
+#endif
 
 #define	XFS_BMAP_MAGIC	0x424d4150	/* 'BMAP' */
 


From owner-linux-xfs@oss.sgi.com Mon May 29 18:06:26 2000
Received:  by oss.sgi.com id <S42275AbQE3BGG>;
	Mon, 29 May 2000 18:06:06 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:20792 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42307AbQE0XrD>; Sat, 27 May 2000 16:47:03 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA08520
	for <linux-xfs@oss.sgi.com>; Sat, 27 May 2000 17:51:16 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id TAA61959; Sat, 27 May 2000 19:45:14 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id TAA29659; Sat, 27 May 2000 19:45:14 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id TAA38341; Sat, 27 May 2000 19:45:14 -0500 (CDT)
Message-Id: <200005280045.TAA38341@tiki.americas.sgi.com>
Subject: Re: status of xfs cvs tree. link error building latest cvs.
To:     nabbasi@pacbell.net (Nasser Abbasi)
Date:   Sat, 27 May 2000 19:45:14 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <392F4069.2A727681@pacbell.net> from "Nasser Abbasi" at May 26, 2000 08:26:33 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

> 
> 
> fs/fs.o: In function `xfs_cleanup':
> /export/g/nabbasi/download/linux-2.3-xfs/linux/fs/xfs/xfs_vfsops.c:466: undefined reference to `buf_zone'


Somehow, the reference to 'buf_zone' was being resolved, even though
it was indeed 'static' in another file, when XFS was
built as a module, which is how all of us  have been running.

This has been fixed, even though shortly we'll be deleting the
code & choice, going completely with page_buf_metadata.

	-Ted Kline

From owner-linux-xfs@oss.sgi.com Mon May 29 18:32:15 2000
Received:  by oss.sgi.com id <S42250AbQE3BcG>;
	Mon, 29 May 2000 18:32:06 -0700
Received: from lips.borg.umn.edu ([160.94.232.50]:1548 "EHLO lips.borg.umn.edu")
	by oss.sgi.com with ESMTP id <S42243AbQE3Bbs>;
	Mon, 29 May 2000 18:31:48 -0700
Received: from lupo.thebarn.com (nic-25-c125-118.mn.mediaone.net [24.25.125.118])
	by lips.borg.umn.edu (8.10.0/8.10.0) with ESMTP id e4U2VlO72186
	for <linux-xfs@oss.sgi.com>; Mon, 29 May 2000 21:31:47 -0500 (CDT)
Received: from thebarn.com (phuck-wi0 [10.0.0.130])
	by lupo.thebarn.com (8.9.3/8.9.3) with ESMTP id VAA67144;
	Mon, 29 May 2000 21:31:46 -0500 (CDT)
Message-ID: <393327FB.F57A30DF@thebarn.com>
Date:   Mon, 29 May 2000 21:31:23 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
Organization: Moo Solutions
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Kip Macy <kip@eventdriven.org>
CC:     linux-xfs@oss.sgi.com
Subject: Re: cvs not responding
References: <393019AB.6C30471E@eventdriven.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

Kip Macy wrote:

> cvs -z3 update -d hangs

Hmm.. duno... I restarted inetd... give it another try.


>
> the tail of strace is:
>
> connect(3, {sin_family=AF_INET, sin_port=htons(2401),
> sin_addr=inet_addr("216.32.174.118")}}, 16) = 0
> access("/root/.cvspass", F_OK)          = 0
> chmod("/root/.cvspass", 0600)           = 0
> open("/root/.cvspass", O_RDONLY)        = 4
> fstat64(0x4, 0xbffff788)                = 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0x40015000
> read(4, ":pserver:cvs@oss.sgi.com:/cvs Ah"..., 4096) = 35
> close(4)                                = 0
> munmap(0x40015000, 4096)                = 0
> send(3, "BEGIN AUTH REQUEST\n", 19, 0)  = 19
> send(3, "/cvs", 4, 0)                   = 4
> send(3, "\n", 1, 0)                     = 1
> send(3, "cvs", 3, 0)                    = 3
> send(3, "\n", 1, 0)                     = 1
> send(3, "Ah<Z", 4, 0)                   = 4
> send(3, "\n", 1, 0)                     = 1
> send(3, "END AUTH REQUEST\n", 17, 0)    = 17
> recv(3,


From owner-linux-xfs@oss.sgi.com Mon May 29 19:14:15 2000
Received:  by oss.sgi.com id <S42240AbQE3CN4>;
	Mon, 29 May 2000 19:13:56 -0700
Received: from ppp0.ocs.com.au ([203.34.97.3]:34566 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S42238AbQE3CNj>;
	Mon, 29 May 2000 19:13:39 -0700
Received: (qmail 3264 invoked by uid 502); 30 May 2000 03:13:25 -0000
Received: (qmail 3244 invoked from network); 30 May 2000 03:13:19 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 30 May 2000 03:13:18 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Ted Kline <jtk@sgi.com>
cc:     nabbasi@pacbell.net (Nasser Abbasi), linux-xfs@oss.sgi.com
Subject: Re: status of xfs cvs tree. link error building latest cvs. 
In-reply-to: Your message of "Sat, 27 May 2000 19:45:14 EST."
             <200005280045.TAA38341@tiki.americas.sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 30 May 2000 13:13:17 +1000
Message-ID: <9222.959656397@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, 27 May 2000 19:45:14 -0500 (CDT), 
Ted Kline <jtk@sgi.com> wrote:
>> fs/fs.o: In function `xfs_cleanup':
>> /export/g/nabbasi/download/linux-2.3-xfs/linux/fs/xfs/xfs_vfsops.c:466: undefined reference to `buf_zone'
>
>Somehow, the reference to 'buf_zone' was being resolved, even though
>it was indeed 'static' in another file, when XFS was
>built as a module, which is how all of us  have been running.

For backward compatibility with 2.0 kernels, if a module contains
neither EXPORT_SYMBOL() nor EXPORT_NO_SYMBOLS then *all* symbols are
exported, including statics.  xfs as a module has all symbols visible
and a module is allowed to satisfy its own external references (to
handle multiple sources) so buf_zone got resolved.

IMNSHO, xfs should explicitly export any symbols required, if no
symbols are required it should EXPORT_NO_SYMBOLS.  I sent a mail a few
days ago about getting access to symbols for debugging without using
EXPORT_SYMBOL, I would like to see xfs do EXPORT_NO_SYMBOLS and xfsidbg
use kallsyms to get the data it needs.  This approach gives the same
symbol visibility for modules and code that is built into the kernel.

ps. Starting with kernel 2.5 (actually modutils 2.5) the default for
    any modules without EXPORT_SYMBOL will be EXPORT_NO_SYMBOLS.  That
    is, in 2.5 no symbols will be exported unless you make it explicit.

Keith Owens, modutils maintainer.


From owner-linux-xfs@oss.sgi.com Tue May 30 10:09:08 2000
Received:  by oss.sgi.com id <S42256AbQE3M43>;
	Tue, 30 May 2000 05:56:29 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:40537 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42254AbQE3Mzy>;
	Tue, 30 May 2000 05:55:54 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA17654
	for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 06:45:47 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA44389 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 08:48:08 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id IAA06387 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 08:48:08 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.9.3/SGI-client.1.6) id IAA01037; Tue, 30 May 2000 08:46:42 -0500
Message-Id: <200005301346.IAA01037@jen.americas.sgi.com>
Date:   Tue, 30 May 2000 08:46:42 -0500
Subject: TAKE - cut number of run_task_queue(&tq_disk) calls in xfs
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

Modid:  2.3.99pre2-xfs:slinx:62984a
Date:  Tue May 30 06:44:03 PDT 2000
Workarea:  jen.cray.com:/data/clink/io/lord/xfs-linux

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

linux/fs/xfs/xfs_log.c - 1.219
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.219&r2=text&tr2=1.218&f=h
	- Remove unneeded xfs_trigger_io() calls - fixes elsewhere in the system
	  make these unnecessary.



From owner-linux-xfs@oss.sgi.com Tue May 30 10:09:28 2000
Received:  by oss.sgi.com id <S42282AbQE3RJI>;
	Tue, 30 May 2000 10:09:08 -0700
Received: from Cantor.suse.de ([194.112.123.193]:527 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42266AbQE3Nga>;
	Tue, 30 May 2000 06:36:30 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id CC5C01E199; Tue, 30 May 2000 16:35:58 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 9D97710A026; Tue, 30 May 2000 16:35:58 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 592CA2F300; Tue, 30 May 2000 16:35:56 +0200 (MEST)
Date:   Tue, 30 May 2000 16:35:56 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     Kip Macy <kip@eventdriven.org>, linux-xfs@oss.sgi.com
Subject: Re: cvs not responding
Message-ID: <20000530163556.A29660@gruyere.muc.suse.de>
References: <393019AB.6C30471E@eventdriven.org> <393327FB.F57A30DF@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <393327FB.F57A30DF@thebarn.com>; from cattelan@thebarn.com on Mon, May 29, 2000 at 09:31:23PM -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, May 29, 2000 at 09:31:23PM -0500, Russell Cattelan wrote:
> Kip Macy wrote:
> 
> > cvs -z3 update -d hangs
> 
> Hmm.. duno... I restarted inetd... give it another try.

It still hangs (like for several days now) 

Same strace as Kip.


-Andi


From owner-linux-xfs@oss.sgi.com Tue May 30 10:09:28 2000
Received:  by oss.sgi.com id <S42291AbQE3RJI>;
	Tue, 30 May 2000 10:09:08 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:39025 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42280AbQE3OkM>;
	Tue, 30 May 2000 07:40:12 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA26028
	for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 08:32:10 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA86536 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 10:35:46 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id KAA12725 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 10:35:46 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.9.3/SGI-client.1.6) id KAA11779; Tue, 30 May 2000 10:34:19 -0500
Message-Id: <200005301534.KAA11779@jen.americas.sgi.com>
Date:   Tue, 30 May 2000 10:34:19 -0500
Subject: TAKE - vnode.h included vfs.h and vfs.h included vnode.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

Modid:  2.3.99pre2-xfs:slinx:62987a
Date:  Tue May 30 08:34:07 PDT 2000
Workarea:  128.162.184.86:/data/clink/io/lord/slinx

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

linux/fs/xfs/pseudo-inc/sys/vfs.h - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/vfs.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
	- Remove circular header file dependency



From owner-linux-xfs@oss.sgi.com Tue May 30 10:09:28 2000
Received:  by oss.sgi.com id <S42297AbQE3RJJ>;
	Tue, 30 May 2000 10:09:09 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:36 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42289AbQE3Pm0>; Tue, 30 May 2000 08:42:26 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA03235
	for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 09:29:16 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA07079 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 11:23:13 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id LAA15372 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 11:23:12 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.9.3/SGI-client.1.6) id LAA16822; Tue, 30 May 2000 11:21:46 -0500
Message-Id: <200005301621.LAA16822@jen.americas.sgi.com>
Date:   Tue, 30 May 2000 11:21:46 -0500
Subject: TAKE - merge in suggestion from Andi Kleen 
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

Cross architecture compilation fix

Modid:  2.3.99pre2-xfs:slinx:62991a
Date:  Tue May 30 09:22:07 PDT 2000
Workarea:  jen.cray.com:/data/clink/io/lord/slinx

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

linux/fs/xfs/xfs_bmap_btree.h - 1.48
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap_btree.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h
linux/fs/xfs/xfs_os_defs.h - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_os_defs.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
	- Remove unneeded endian.h include

linux/fs/xfs/xfs_arch.h - 1.27
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_arch.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h
	- For the kernel build, use kernel header files to work out architecture



From owner-linux-xfs@oss.sgi.com Tue May 30 10:09:38 2000
Received:  by oss.sgi.com id <S42270AbQE3RJJ>;
	Tue, 30 May 2000 10:09:09 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:16164 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42290AbQE3Pou>; Tue, 30 May 2000 08:44:50 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA02969
	for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 09:30:46 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA40108; Tue, 30 May 2000 11:24:35 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id LAA15445; Tue, 30 May 2000 11:24:35 -0500 (CDT)
Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e4UGOR704258;
	Tue, 30 May 2000 11:24:27 -0500
Message-ID: <3933EB3B.D755EEF7@thebarn.com>
Date:   Tue, 30 May 2000 11:24:27 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andi Kleen <ak@suse.de>
CC:     Kip Macy <kip@eventdriven.org>, linux-xfs@oss.sgi.com
Subject: Re: cvs not responding
References: <393019AB.6C30471E@eventdriven.org> <393327FB.F57A30DF@thebarn.com> <20000530163556.A29660@gruyere.muc.suse.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

Andi Kleen wrote:

> On Mon, May 29, 2000 at 09:31:23PM -0500, Russell Cattelan wrote:
> > Kip Macy wrote:
> >
> > > cvs -z3 update -d hangs
> >
> > Hmm.. duno... I restarted inetd... give it another try.
>
> It still hangs (like for several days now)

Well..?? . wonder what is wrong.
I did a successful checkout last night.

It might have something to do with the firewall rule that got installed.

The network to the ISP seems to be down right now. Once it is
back up I will flush that rules, and have you try it again.


>
>
> Same strace as Kip.
>
> -Andi


From owner-linux-xfs@oss.sgi.com Tue May 30 10:09:38 2000
Received:  by oss.sgi.com id <S42264AbQE3RJJ>;
	Tue, 30 May 2000 10:09:09 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:606 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42263AbQE3NLr>;
	Tue, 30 May 2000 06:11:47 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA17949
	for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 06:51:30 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id IAA47224 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 08:53:51 -0500 (CDT)
Received: from localhost.localdomain (root@eagdhcp-184-27.americas.sgi.com [128.162.184.177]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id IAA06606 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 08:53:51 -0500 (CDT)
Received: from laptop by localhost.localdomain (8.9.3/SGI-client.1.6) via ESMTP id IAA01491; Tue, 30 May 2000 08:55:22 -0500
Message-Id: <200005301355.IAA01491@localhost.localdomain>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix pageblock macros
Date:   Tue, 30 May 2000 08:55:22 -0500
From:   Stephen 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


These macros did not function correctly, potentially leading to extra
code getting executed, extra disk I/O and possibly meta-data corruption.

Modid:  2.3.99pre2-xfs:slinx:62968a
Date:  Sun May 28 07:05:57 PDT 2000
Workarea:  192.82.201.237:/mnt/usr/src/lord/linux-xfs

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

linux/include/linux/mm.h - 1.33
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/mm.h.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h
        - Fix PageBlockValid and PageBlockInvalid macros - these did not always
          function correctly due to testing for 1 or 0 return from test_bit.


From owner-linux-xfs@oss.sgi.com Tue May 30 10:13:38 2000
Received:  by oss.sgi.com id <S42319AbQE3RN2>;
	Tue, 30 May 2000 10:13:28 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:46367 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42318AbQE3RNC>;
	Tue, 30 May 2000 10:13:02 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA08326
	for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 10:52:08 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA29489 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 12:54:30 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id MAA19693 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 12:54:29 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.9.3/SGI-client.1.6) id MAA22290; Tue, 30 May 2000 12:54:28 -0500
Message-Id: <200005301754.MAA22290@jen.americas.sgi.com>
Date:   Tue, 30 May 2000 12:54:28 -0500
Subject: TAKE - do not export symbols from xfs when built as a module
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

Modid:  2.3.99pre2-xfs:slinx:62997a
Date:  Tue May 30 10:53:49 PDT 2000
Workarea:  jen.cray.com:/data/clink/io/lord/slinx

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

linux/fs/xfs/xfsidbg.c - 1.144
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.144&r2=text&tr2=1.143&f=h
	- Remove include of xfs_macros.h - the xfsidbg module then compiles with
	  all code as macros which removes the symbol dependency on xfs.

linux/fs/xfs/Makefile - 1.102
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/Makefile.diff?r1=text&tr1=1.102&r2=text&tr2=1.101&f=h
	- Switch from OX_OBJ to O_OBJ

linux/fs/xfs/linux/Makefile - 1.20
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/Makefile.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h
	- Switch from OX_OBJ to O_OBJ

linux/fs/xfs/linux/xfs_super.c - 1.68
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c.diff?r1=text&tr1=1.68&r2=text&tr2=1.67&f=h
	- add EXPORT_NO_SYMBOLS



From owner-linux-xfs@oss.sgi.com Tue May 30 11:35:27 2000
Received:  by oss.sgi.com id <S42266AbQE3SfS>;
	Tue, 30 May 2000 11:35:18 -0700
Received: from Cantor.suse.de ([194.112.123.193]:32018 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42263AbQE3SfA>;
	Tue, 30 May 2000 11:35:00 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 5954B1E297; Tue, 30 May 2000 21:34:59 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id C845610A026; Tue, 30 May 2000 21:34:57 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 1D8F82F300; Tue, 30 May 2000 21:34:56 +0200 (MEST)
Date:   Tue, 30 May 2000 21:34:56 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     Andi Kleen <ak@suse.de>, Kip Macy <kip@eventdriven.org>,
        linux-xfs@oss.sgi.com
Subject: Re: cvs not responding
Message-ID: <20000530213456.A1706@gruyere.muc.suse.de>
References: <393019AB.6C30471E@eventdriven.org> <393327FB.F57A30DF@thebarn.com> <20000530163556.A29660@gruyere.muc.suse.de> <3933EB3B.D755EEF7@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <3933EB3B.D755EEF7@thebarn.com>; from cattelan@thebarn.com on Tue, May 30, 2000 at 11:24:27AM -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 Tue, May 30, 2000 at 11:24:27AM -0500, Russell Cattelan wrote:
> Andi Kleen wrote:
> 
> > On Mon, May 29, 2000 at 09:31:23PM -0500, Russell Cattelan wrote:
> > > Kip Macy wrote:
> > >
> > > > cvs -z3 update -d hangs
> > >
> > > Hmm.. duno... I restarted inetd... give it another try.
> >
> > It still hangs (like for several days now)
> 
> Well..?? . wonder what is wrong.
> I did a successful checkout last night.
> 
> It might have something to do with the firewall rule that got installed.
> 
> The network to the ISP seems to be down right now. Once it is
> back up I will flush that rules, and have you try it again.

Thanks, it works now again.


-Andi


From owner-linux-xfs@oss.sgi.com Tue May 30 12:56:38 2000
Received:  by oss.sgi.com id <S42268AbQE3T4S>;
	Tue, 30 May 2000 12:56:18 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:13379 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42263AbQE3T4A>;
	Tue, 30 May 2000 12:56:00 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA18923
	for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 12:40:06 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id OAA77521; Tue, 30 May 2000 14:43:26 -0500 (CDT)
Received: from localhost.localdomain (root@eagdhcp-184-27.americas.sgi.com [128.162.184.177]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id OAA26062; Tue, 30 May 2000 14:43:24 -0500 (CDT)
From:   Steve Lord <lord@sgi.com>
Received: by localhost.localdomain (8.9.3/SGI-client.1.6) id OAA02852; Tue, 30 May 2000 14:44:56 -0500
Message-Id: <200005301944.OAA02852@localhost.localdomain>
Date:   Tue, 30 May 2000 14:44:56 -0500
Subject: TAKE - file missed from previous checkin
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

Modid:  2.3.99pre2-xfs:slinx:63013a
Date:  Tue May 30 12:42:50 PDT 2000
Workarea:  128.162.184.177:/usr/src/lord/linux-xfs

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

linux/fs/xfs/linux/xfs_lrw.c - 1.42
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h
	- remove pagebuf metadata config option



From owner-linux-xfs@oss.sgi.com Tue May 30 13:56:08 2000
Received:  by oss.sgi.com id <S42273AbQE3Uz6>;
	Tue, 30 May 2000 13:55:58 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10307 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42263AbQE3Uzi>; Tue, 30 May 2000 13:55:38 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA00267
	for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 13:51:53 -0700 (PDT)
	mail_from (cattelan@cray.com)
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA74484 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 15:45:51 -0500 (CDT)
Received: (from cattelan@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id PAA36695 for linux-xfs@oss.sgi.com; Tue, 30 May 2000 15:45:50 -0500 (CDT)
Date:   Tue, 30 May 2000 15:45:50 -0500 (CDT)
From:   Russell Cattelan <cattelan@cray.com>
Message-Id: <200005302045.PAA36695@clink.americas.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.3.99pre2-xfs:slinx:63026a
Date:  Tue May 30 13:40:09 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs-types
Author:  cattelan

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

cmd/xfs/copy/locks.h - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/copy/locks.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
cmd/xfs/copy/xfs_copy.c - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/copy/xfs_copy.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
cmd/xfs/db/convert.c - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/convert.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
cmd/xfs/db/io.c - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/io.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
cmd/xfs/db/io.h - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/db/io.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
cmd/xfs/logprint/log_misc.c - 1.58
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/logprint/log_misc.c.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h
cmd/xfs/logprint/log_print_trans.c - 1.27
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/logprint/log_print_trans.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h
cmd/xfs/logprint/logprint.c - 1.36
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/logprint/logprint.c.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h
cmd/xfs/mangle/dirs.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/dirs.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
cmd/xfs/mangle/inodes.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mangle/inodes.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
cmd/xfs/maxtrres/xfs_maxtrres.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/maxtrres/xfs_maxtrres.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
cmd/xfs/mkfs/rdwr.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mkfs/rdwr.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
cmd/xfs/mkfs/xfs_mkfs.c - 1.164
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.164&r2=text&tr2=1.163&f=h
cmd/xfs/repair/agheader.c - 1.21
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/agheader.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h
cmd/xfs/repair/attr_repair.c - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/attr_repair.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
cmd/xfs/repair/avl.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/avl.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
cmd/xfs/repair/avl64.c - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/avl64.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
cmd/xfs/repair/dino_chunks.c - 1.39
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dino_chunks.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h
cmd/xfs/repair/dinode.c - 1.76
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dinode.c.diff?r1=text&tr1=1.76&r2=text&tr2=1.75&f=h
cmd/xfs/repair/dir.c - 1.55
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dir.c.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h
cmd/xfs/repair/dir2.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dir2.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
cmd/xfs/repair/dir_stack.c - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/dir_stack.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
cmd/xfs/repair/efs.c - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/efs.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
cmd/xfs/repair/globals.c - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/globals.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
cmd/xfs/repair/incore.c - 1.33
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/incore.c.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h
cmd/xfs/repair/incore_bmc.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/incore_bmc.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
cmd/xfs/repair/incore_ext.c - 1.19
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/incore_ext.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h
cmd/xfs/repair/incore_ino.c - 1.21
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/incore_ino.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h
cmd/xfs/repair/init.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/init.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
cmd/xfs/repair/io.c - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/io.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
cmd/xfs/repair/phase1.c - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase1.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
cmd/xfs/repair/phase2.c - 1.24
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase2.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h
cmd/xfs/repair/phase3.c - 1.29
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase3.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h
cmd/xfs/repair/phase4.c - 1.46
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase4.c.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h
cmd/xfs/repair/phase5.c - 1.41
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase5.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h
cmd/xfs/repair/phase6.c - 1.54
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase6.c.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h
cmd/xfs/repair/phase7.c - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/phase7.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
cmd/xfs/repair/protos.h - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/protos.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
cmd/xfs/repair/rt.c - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/rt.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
cmd/xfs/repair/sb.c - 1.29
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/sb.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h
cmd/xfs/repair/scan.c - 1.41
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/scan.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h
cmd/xfs/repair/versions.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/versions.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
cmd/xfs/repair/xfs_repair.c - 1.46
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/repair/xfs_repair.c.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h
cmd/xfs/sim/src/behavior.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/behavior.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
cmd/xfs/sim/src/cxfs_stubs.c - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/cxfs_stubs.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
cmd/xfs/sim/src/fs_bio.c - 1.52
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/fs_bio.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h
cmd/xfs/sim/src/fs_subr.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/fs_subr.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
cmd/xfs/sim/src/ktrace.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/ktrace.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
cmd/xfs/sim/src/move.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/move.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
cmd/xfs/sim/src/page.c - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/page.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
cmd/xfs/sim/src/sim.dev.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/sim.dev.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
cmd/xfs/sim/src/sim.h - 1.71
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/sim.h.diff?r1=text&tr1=1.71&r2=text&tr2=1.70&f=h
cmd/xfs/sim/src/sim.lock.c - 1.36
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/sim.lock.c.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h
cmd/xfs/sim/src/sim.random.c - 1.109
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/sim.random.c.diff?r1=text&tr1=1.109&r2=text&tr2=1.108&f=h
cmd/xfs/sim/src/sim.rdwr.c - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/sim.rdwr.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
cmd/xfs/sim/src/sim.strat.c - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/sim.strat.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
cmd/xfs/sim/src/vfs.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/vfs.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
cmd/xfs/sim/src/vnode.c - 1.54
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/vnode.c.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h
cmd/xfs/sim/src/xfs_stubs.c - 1.25
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/xfs_stubs.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h
linux/Makefile - 1.54
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/Makefile.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h
linux/fs/page_buf.c - 1.102
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/page_buf.c.diff?r1=text&tr1=1.102&r2=text&tr2=1.101&f=h
linux/fs/xfs/linux/Makefile - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/Makefile.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
linux/fs/xfs/linux/xfs_aclstubs.c - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_aclstubs.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
linux/fs/xfs/linux/xfs_bdstrat.c - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_bdstrat.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
linux/fs/xfs/linux/xfs_behavior.c - 1.10
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_behavior.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h
linux/fs/xfs/linux/xfs_cred.c - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_cred.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
linux/fs/xfs/linux/xfs_debug.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_debug.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
linux/fs/xfs/linux/xfs_file.c - 1.30
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_file.c.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h
linux/fs/xfs/linux/xfs_fs_bio.c - 1.34
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_fs_bio.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h
linux/fs/xfs/linux/xfs_fs_subr.c - 1.19
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_fs_subr.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h
linux/fs/xfs/linux/xfs_globals.c - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_globals.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
linux/fs/xfs/linux/xfs_griostubs.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_griostubs.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/fs/xfs/linux/xfs_ioctl.c - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_ioctl.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
linux/fs/xfs/linux/xfs_iops.c - 1.50
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h
linux/fs/xfs/linux/xfs_locks.c - 1.20
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_locks.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h
linux/fs/xfs/linux/xfs_lrw.c - 1.43
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h
linux/fs/xfs/linux/xfs_lrw.h - 1.10
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_lrw.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h
linux/fs/xfs/linux/xfs_mount_opt.c - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_mount_opt.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
linux/fs/xfs/linux/xfs_move.c - 1.10
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_move.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h
linux/fs/xfs/linux/xfs_random.c - 1.40
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h
linux/fs/xfs/linux/xfs_super.c - 1.70
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c.diff?r1=text&tr1=1.70&r2=text&tr2=1.69&f=h
linux/fs/xfs/linux/xfs_vfs.c - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_vfs.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
linux/fs/xfs/linux/xfs_vnode.c - 1.25
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_vnode.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h
linux/fs/xfs/macstubs.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/macstubs.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/fs/xfs/pseudo-inc/ksys/as.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/ksys/as.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/fs/xfs/pseudo-inc/ksys/vfile.h - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/ksys/vfile.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/fs/xfs/pseudo-inc/sys/buf.h - 1.13
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/buf.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h
linux/fs/xfs/pseudo-inc/sys/capability.h - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/capability.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
linux/fs/xfs/pseudo-inc/sys/dirent.h - 1.3
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/dirent.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h
linux/fs/xfs/pseudo-inc/sys/dnlc.h - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/dnlc.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/fs/xfs/pseudo-inc/sys/fs_subr.h - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/fs_subr.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
linux/fs/xfs/pseudo-inc/sys/kmem.h - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/kmem.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/fs/xfs/pseudo-inc/sys/param.h - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/param.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
linux/fs/xfs/pseudo-inc/sys/sysmacros.h - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/sysmacros.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/fs/xfs/pseudo-inc/sys/systm.h - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/systm.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
linux/fs/xfs/pseudo-inc/sys/types.h - 1.16
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/types.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h
linux/fs/xfs/pseudo-inc/sys/uio.h - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/uio.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/fs/xfs/pseudo-inc/sys/vfs.h - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/vfs.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
linux/fs/xfs/pseudo-inc/sys/vnode.h - 1.22
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/vnode.h.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h
linux/fs/xfs/xfs_ag.h - 1.35
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ag.h.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h
linux/fs/xfs/xfs_alloc.c - 1.133
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_alloc.c.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h
linux/fs/xfs/xfs_alloc_btree.c - 1.61
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_alloc_btree.c.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h
linux/fs/xfs/xfs_attr.c - 1.75
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_attr.c.diff?r1=text&tr1=1.75&r2=text&tr2=1.74&f=h
linux/fs/xfs/xfs_attr_leaf.c - 1.48
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_attr_leaf.c.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h
linux/fs/xfs/xfs_bmap_btree.c - 1.113
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap_btree.c.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h
linux/fs/xfs/xfs_btree.c - 1.85
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_btree.c.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h
linux/fs/xfs/xfs_buf.h - 1.53
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_buf.h.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h
linux/fs/xfs/xfs_buf_item.c - 1.102
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.c.diff?r1=text&tr1=1.102&r2=text&tr2=1.101&f=h
linux/fs/xfs/xfs_buf_item.h - 1.29
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_buf_item.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h
linux/fs/xfs/xfs_da_btree.c - 1.108
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.c.diff?r1=text&tr1=1.108&r2=text&tr2=1.107&f=h
linux/fs/xfs/xfs_da_btree.h - 1.38
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_da_btree.h.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h
linux/fs/xfs/xfs_dfrag.h - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dfrag.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/fs/xfs/xfs_dir.c - 1.126
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir.c.diff?r1=text&tr1=1.126&r2=text&tr2=1.125&f=h
linux/fs/xfs/xfs_dir2.c - 1.19
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h
linux/fs/xfs/xfs_dir2.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/fs/xfs/xfs_dir2_sf.c - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir2_sf.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
linux/fs/xfs/xfs_dir_leaf.c - 1.86
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir_leaf.c.diff?r1=text&tr1=1.86&r2=text&tr2=1.85&f=h
linux/fs/xfs/xfs_dir_leaf.h - 1.28
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir_leaf.h.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h
linux/fs/xfs/xfs_dir_sf.h - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dir_sf.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
linux/fs/xfs/xfs_dmapi.h - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dmapi.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/fs/xfs/xfs_dquot.c - 1.47
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dquot.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h
linux/fs/xfs/xfs_dquot.h - 1.15
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dquot.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h
linux/fs/xfs/xfs_dquot_item.c - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_dquot_item.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
linux/fs/xfs/xfs_extfree_item.c - 1.41
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_extfree_item.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h
linux/fs/xfs/xfs_extfree_item.h - 1.12
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_extfree_item.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h
linux/fs/xfs/xfs_grio.c - 1.83
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_grio.c.diff?r1=text&tr1=1.83&r2=text&tr2=1.82&f=h
linux/fs/xfs/xfs_ialloc.c - 1.136
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc.c.diff?r1=text&tr1=1.136&r2=text&tr2=1.135&f=h
linux/fs/xfs/xfs_ialloc_btree.c - 1.58
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_ialloc_btree.c.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h
linux/fs/xfs/xfs_iget.c - 1.117
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_iget.c.diff?r1=text&tr1=1.117&r2=text&tr2=1.116&f=h
linux/fs/xfs/xfs_imap.h - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_imap.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
linux/fs/xfs/xfs_inode.c - 1.290
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.290&r2=text&tr2=1.289&f=h
linux/fs/xfs/xfs_inode.h - 1.136
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.h.diff?r1=text&tr1=1.136&r2=text&tr2=1.135&f=h
linux/fs/xfs/xfs_inode_item.c - 1.90
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode_item.c.diff?r1=text&tr1=1.90&r2=text&tr2=1.89&f=h
linux/fs/xfs/xfs_inum.h - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inum.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
linux/fs/xfs/xfs_iocore.c - 1.17
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_iocore.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h
linux/fs/xfs/xfs_itable.c - 1.85
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_itable.c.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h
linux/fs/xfs/xfs_itable.h - 1.30
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_itable.h.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h
linux/fs/xfs/xfs_log.c - 1.221
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.c.diff?r1=text&tr1=1.221&r2=text&tr2=1.220&f=h
linux/fs/xfs/xfs_log.h - 1.52
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log.h.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h
linux/fs/xfs/xfs_log_print.c - 1.19
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_print.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h
linux/fs/xfs/xfs_log_priv.h - 1.72
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_priv.h.diff?r1=text&tr1=1.72&r2=text&tr2=1.71&f=h
linux/fs/xfs/xfs_log_recover.c - 1.183
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_log_recover.c.diff?r1=text&tr1=1.183&r2=text&tr2=1.182&f=h
linux/fs/xfs/xfs_macros.c - 1.36
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_macros.c.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h
linux/fs/xfs/xfs_mount.c - 1.226
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.c.diff?r1=text&tr1=1.226&r2=text&tr2=1.225&f=h
linux/fs/xfs/xfs_mount.h - 1.113
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_mount.h.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h
linux/fs/xfs/xfs_os_defs.h - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_os_defs.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/fs/xfs/xfs_qm.c - 1.50
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_qm.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h
linux/fs/xfs/xfs_qm.h - 1.14
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_qm.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h
linux/fs/xfs/xfs_qm_syscalls.c - 1.38
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_qm_syscalls.c.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h
linux/fs/xfs/xfs_quota.h - 1.20
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_quota.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h
linux/fs/xfs/xfs_rpc_item.c - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_rpc_item.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
linux/fs/xfs/xfs_rtalloc.c - 1.61
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_rtalloc.c.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h
linux/fs/xfs/xfs_rw.c - 1.316
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_rw.c.diff?r1=text&tr1=1.316&r2=text&tr2=1.315&f=h
linux/fs/xfs/xfs_rw.h - 1.54
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_rw.h.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h
linux/fs/xfs/xfs_sb.h - 1.46
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_sb.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h
linux/fs/xfs/xfs_trans.c - 1.114
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_trans.c.diff?r1=text&tr1=1.114&r2=text&tr2=1.113&f=h
linux/fs/xfs/xfs_trans.h - 1.105
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_trans.h.diff?r1=text&tr1=1.105&r2=text&tr2=1.104&f=h
linux/fs/xfs/xfs_trans_buf.c - 1.84
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_trans_buf.c.diff?r1=text&tr1=1.84&r2=text&tr2=1.83&f=h
linux/fs/xfs/xfs_vfsops.c - 1.271
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vfsops.c.diff?r1=text&tr1=1.271&r2=text&tr2=1.270&f=h
linux/fs/xfs/xfs_vnodeops.c - 1.453
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vnodeops.c.diff?r1=text&tr1=1.453&r2=text&tr2=1.452&f=h
linux/fs/xfs/xfsidbg.c - 1.145
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.145&r2=text&tr2=1.144&f=h
linux/fs/xfs/xfsquotasstubs.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsquotasstubs.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
	- Massive type update 
	  daddr_t -> xfs_daddr_t
	  caddr_t -> xfs_caddr_t
	  off_t   -> xfs_off_t
	  off64_t -> xfs_off_t 
	  ino_t   -> xfs_ino_t
	  Removed need for files xfs_to_linux.h and lunux_to_xfs.h

Removed more references to xfs_linux.h replaced with xfs_os_defs.h
defined new types in xfs_os_defs.h.
Removed some dead code.

This checkin should clean up most type conflicts betwwen xfs type and linux types.
A few conflicts remain; fsid_t, bread, and brelse. Will clean these up soon.


From owner-linux-xfs@oss.sgi.com Tue May 30 16:08:18 2000
Received:  by oss.sgi.com id <S42276AbQE3XH5>;
	Tue, 30 May 2000 16:07:57 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:60937 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42263AbQE3XHe>;
	Tue, 30 May 2000 16:07:34 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA08815
	for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 16:00:11 -0700 (PDT)
	mail_from (cattelan@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA25213 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 18:02:31 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id SAA19243 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 18:02:31 -0500 (CDT)
From:   Russell Cattelan <cattelan@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id SAA73826; Tue, 30 May 2000 18:02:30 -0500 (CDT)
Message-Id: <200005302302.SAA73826@nt8.americas.sgi.com>
Date:   Tue, 30 May 2000 18:02:30 -0500 (CDT)
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.3.99pre2-xfs:slinx:63048a
Date:  Tue May 30 16:01:58 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs
Author:  cattelan

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

linux/Makefile - 1.55
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/Makefile.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h
	- Opps... remove my EXTRAVERSION tag.

linux/fs/xfs/linux/Makefile - 1.23
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/Makefile.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h
	- Accidently checked in code that was removed.


From owner-linux-xfs@oss.sgi.com Tue May 30 16:53:08 2000
Received:  by oss.sgi.com id <S42277AbQE3Xw6>;
	Tue, 30 May 2000 16:52:58 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:49688 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42263AbQE3Xwc>;
	Tue, 30 May 2000 16:52:32 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA11890
	for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 16:42:00 -0700 (PDT)
	mail_from (cattelan@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id SAA02382 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 18:44:23 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id SAA29147 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 18:44:21 -0500 (CDT)
From:   Russell Cattelan <cattelan@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id SAA76499; Tue, 30 May 2000 18:44:20 -0500 (CDT)
Message-Id: <200005302344.SAA76499@nt8.americas.sgi.com>
Date:   Tue, 30 May 2000 18:44:20 -0500 (CDT)
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.3.99pre2-xfs:slinx:63051a
Date:  Tue May 30 16:44:02 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs-types
Author:  cattelan

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

linux/fs/xfs/linux/xfs_super.c - 1.71
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c.diff?r1=text&tr1=1.71&r2=text&tr2=1.70&f=h
	- Forgot to remove the includes.Forgot to remove the includes linux_to_xfs xfs_to_linux


From owner-linux-xfs@oss.sgi.com Tue May 30 17:22:38 2000
Received:  by oss.sgi.com id <S42278AbQEaAW2>;
	Tue, 30 May 2000 17:22:28 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:15394 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42263AbQEaAWD>;
	Tue, 30 May 2000 17:22:03 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA14736
	for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 17:15:50 -0700 (PDT)
	mail_from (cattelan@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id TAA20515 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 19:19:27 -0500 (CDT)
Received: from nt8.americas.sgi.com (nt8.americas.sgi.com [128.162.195.8]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id TAA07203 for <linux-xfs@oss.sgi.com>; Tue, 30 May 2000 19:19:26 -0500 (CDT)
From:   Russell Cattelan <cattelan@sgi.com>
Received: by nt8.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id TAA77969; Tue, 30 May 2000 19:19:25 -0500 (CDT)
Message-Id: <200005310019.TAA77969@nt8.americas.sgi.com>
Date:   Tue, 30 May 2000 19:19:25 -0500 (CDT)
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.3.99pre2-xfs:slinx:63057a
Date:  Tue May 30 17:18:59 PDT 2000
Workarea:  nt8.americas.sgi.com:/data/clink/io/cattelan/x2.3-99-xfs
Author:  cattelan

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

linux/fs/xfs/xfs_bmap.c - 1.253
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_bmap.c.diff?r1=text&tr1=1.253&r2=text&tr2=1.252&f=h
	- Missed in the types upgrade.


From owner-linux-xfs@oss.sgi.com Wed May 31 00:38:39 2000
Received:  by oss.sgi.com id <S42274AbQEaHi3>;
	Wed, 31 May 2000 00:38:29 -0700
Received: from lips.borg.umn.edu ([160.94.232.50]:30990 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S42263AbQEaHiQ>;
	Wed, 31 May 2000 00:38:16 -0700
Received: from thebarn.com (nic-25-c125-118.mn.mediaone.net [24.25.125.118])
	by lips.borg.umn.edu (8.10.0/8.10.0) with ESMTP id e4V7dY680238;
	Wed, 31 May 2000 02:39:35 -0500 (CDT)
Message-ID: <3934C1B5.585651E3@thebarn.com>
Date:   Wed, 31 May 2000 02:39:34 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 4.0-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Moshe Bar <moshe@moelabs.com>
Subject: Re: Linux XFS.
References: <NDBBJIDABHDIEFPBCGOCCEHLEKAA.moshe@moelabs.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

Moshe Bar wrote:

> Dear Russel
>
> any thanks for writing. xfs might be ready for download, but it's still full
> of proprietary code with licencing restrictions.

Err I'm not sure where you are getting your information but
XFS is fully GPL'ed, released, and getting closer to stable every day.

>
>
> In my personal view sgi is not doing enough to aggressively open up xfs to
> the OpenSource community.

I would really like to understand what you feel SGI has failed to do in
terms of opening up XFS to the public.

The bell has rung, there is nothing SGI can do to unrelease the source code.

And more over SGI spent a great deal of money on lawyers and technical people
to do a full encumbrance review the XFS source code to ensure no AT&T (or
anybody
else) copyrights were violated.

Obviously there has been some mis communication, I think I would be in our
best interest to start clearing up some misconceptions that seem to have
propagated amounts the OpenSource community.

Include is the XFS copyright.

/*
 * Copyright (c) 2000 Silicon Graphics, Inc.  All Rights Reserved.
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of version 2 of the GNU General Public License as
 * published by the Free Software Foundation.
 *
 * This program is distributed in the hope that it would be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 *
 * Further, this software is distributed without any warranty that it is
 * free of the rightful claim of any third person regarding infringement
 * or the like.  Any license provided herein, whether implied or
 * otherwise, applies only to this software file.  Patent licenses, if
 * any, provided herein do not apply to combinations of this program with
 * other software, or any other product whatsoever.
 *
 * You should have received a copy of the GNU General Public License along
 * with this program; if not, write the Free Software Foundation, Inc., 59
 * Temple Place - Suite 330, Boston MA 02111-1307, USA.
 *
 * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy,
 * Mountain View, CA  94043, or:
 *
 * http://www.sgi.com
 *
 * For further information regarding this notice, see:
 *
 * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/
 */

>
>
> In the case of JFS, IBM is making true investements and efforts to give all
> of jfs to the public. It has in fact made all of jfs OpenSource.
>
> Many thanks
>
> Moshe Bar
>
> > -----Original Message-----
> > From: cattelan@sgi.com [mailto:cattelan@sgi.com]On Behalf Of Russell
> > Cattelan
> > Sent: Wednesday, May 31, 2000 2:30 AM
> > To: moshe@moelabs.com
> > Subject: Linux XFS.
> >
> >
> > Perhaps you missed  this little bit of info.
> >
> > http://oss.sgi.com/projects/xfs/news.html
> >
> > XFS for linux has been officially available since March 30th.
> >
> > And we are getting to close to declaring our first BETA release. (no
> > firm date yet).
> >
> > -Russell Cattelan
> >
> >

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Wed May 31 07:36:15 2000
Received:  by oss.sgi.com id <S42284AbQEaOfz>;
	Wed, 31 May 2000 07:35:55 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:43529 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42271AbQEaOfY>; Wed, 31 May 2000 07:35:24 -0700
Received: from zeus-fddi.cray.com (zeus-fddi.cray.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA05602
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 07:27:10 -0700 (PDT)
	mail_from (lord@cray.com)
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by zeus-fddi.cray.com (8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA2057062 for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 09:21:08 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id JAA01376 for linux-xfs@oss.sgi.com; Wed, 31 May 2000 09:21:07 -0500 (CDT)
Date:   Wed, 31 May 2000 09:21:07 -0500 (CDT)
From:   Steve Lord <lord@cray.com>
Message-Id: <200005311421.JAA01376@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - merge over fix from kdb tree
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Export symbol kdb_symbol_print

Modid:  2.3.99pre2-xfs:slinx:63065a
Date:  Wed May 31 07:20:42 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/slinx
Author:  kaos
Merged by:  lord
Merged mods:  2.3.99pre2-kdb:slinx:63065a

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

linux/arch/i386/kernel/i386_ksyms.c - 1.25
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kernel/i386_ksyms.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h
linux/include/asm-i386/kdb.h - 1.2
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/asm-i386/kdb.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h
linux/include/asm-i386/kdbprivate.h - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/asm-i386/kdbprivate.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
linux/include/linux/kdb.h - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kdb.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
linux/include/linux/kdbprivate.h - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kdbprivate.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
	- Merge of 2.3.99pre2-kdb:slinx:63065a by lord.


From owner-linux-xfs@oss.sgi.com Wed May 31 07:39:45 2000
Received:  by oss.sgi.com id <S42285AbQEaOjZ>;
	Wed, 31 May 2000 07:39:25 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:29205 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42271AbQEaOjJ>;
	Wed, 31 May 2000 07:39:09 -0700
Received: from zeus-fddi.cray.com (zeus-fddi.cray.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA12731
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 07:33:32 -0700 (PDT)
	mail_from (lord@cray.com)
Received: from clink.americas.sgi.com (clink.cray.com [128.162.84.70]) by zeus-fddi.cray.com (8.9.3/craymail-smart-nospam1.0) with ESMTP id JAA2058049 for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 09:35:54 -0500 (CDT)
Received: (from lord@localhost) by clink.americas.sgi.com (980427.SGI.8.8.8/CRI-news-1.3) id JAA65045 for linux-xfs@oss.sgi.com; Wed, 31 May 2000 09:35:53 -0500 (CDT)
Date:   Wed, 31 May 2000 09:35:53 -0500 (CDT)
From:   Steve Lord <lord@cray.com>
Message-Id: <200005311435.JAA65045@clink.americas.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - merge kdb fix into xfs tree
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Remove spurious NMI

Modid:  2.3.99pre2-xfs:slinx:63066a
Date:  Wed May 31 07:35:31 PDT 2000
Workarea:  clink.americas.sgi.com:/data/clink/io/lord/slinx
Author:  kaos
Merged by:  lord
Merged mods:  2.3.99pre2-kdb:slinx:63066a

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

linux/arch/i386/kernel/entry.S - 1.18
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kernel/entry.S.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h
linux/include/linux/kdb.h - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kdb.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
linux/kdb/kdbmain.c - 1.6
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdbmain.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h
	- Merge of 2.3.99pre2-kdb:slinx:63066a by lord.


From owner-linux-xfs@oss.sgi.com Wed May 31 08:40:05 2000
Received:  by oss.sgi.com id <S42292AbQEaPjp>;
	Wed, 31 May 2000 08:39:45 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:298 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42289AbQEaPjP>;
	Wed, 31 May 2000 08:39:15 -0700
Received: from zeus-fddi.cray.com (zeus-fddi.cray.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA16930
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 08:25:01 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by zeus-fddi.cray.com (8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA2062801 for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 10:28:38 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id KAA02162; Wed, 31 May 2000 10:28:37 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id KAA74594; Wed, 31 May 2000 10:28:36 -0500 (CDT)
Message-Id: <200005311528.KAA74594@tiki.americas.sgi.com>
Date:   Wed, 31 May 2000 10:28:36 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Cc:     jtk@sgi.com
Subject: TAKE - Fix unresolved symbol in DEBUG version of xfsidbg.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Date:  Wed May 31 08:27:42 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linux2.3-99

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


Modid:  2.3.99pre2-xfs:slinx:63078a
linux/fs/xfs/xfsidbg.c - 1.146
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfsidbg.c.diff?r1=text&tr1=1.146&r2=text&tr2=1.145&f=h
	- Replace ASSERT's with runtime checks, undef DEBUG & XFSDEBUG to
	  eliminate the need to export/import the "doass" & "assfail" parts
	  of the ASSERT implementation.



From owner-linux-xfs@oss.sgi.com Wed May 31 08:55:05 2000
Received:  by oss.sgi.com id <S42294AbQEaPyp>;
	Wed, 31 May 2000 08:54:45 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47888 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42289AbQEaPyc>; Wed, 31 May 2000 08:54:32 -0700
Received: from zeus-fddi.cray.com (zeus-fddi.cray.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA05096
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 08:43:21 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by zeus-fddi.cray.com (8.9.3/craymail-smart-nospam1.0) with ESMTP id KAA2076277 for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 10:37:18 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id KAA04831; Wed, 31 May 2000 10:37:16 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id KAA53389; Wed, 31 May 2000 10:37:15 -0500 (CDT)
Message-Id: <200005311537.KAA53389@tiki.americas.sgi.com>
Date:   Wed, 31 May 2000 10:37:15 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Cc:     jtk@sgi.com
Subject: TAKE - Implement the "/proc/sys/fs/xfs_stats" printout.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


XFS stats have been in the system for a long time; now they
can be printed by:

	cat /proc/sys/fs/xfs_stats



Date:  Wed May 31 08:34:53 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linux2.3-99

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


Modid:  2.3.99pre2-xfs:slinx:63085a
cmd/xfs/sim/src/vnode.c - 1.55
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfs/sim/src/vnode.c.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h
	- Remove extraneous XFSSTATS & VOPINFO stats.

linux/fs/xfs/xfs_vfsops.c - 1.272
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_vfsops.c.diff?r1=text&tr1=1.272&r2=text&tr2=1.271&f=h
	- Inintialize & cleanup the 'xfs_stats' /proc interface.

linux/fs/xfs/xfs_inode.c - 1.291
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c.diff?r1=text&tr1=1.291&r2=text&tr2=1.290&f=h
	- Additional XFSSTATS.

linux/fs/xfs/pseudo-inc/sys/ksa.h - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/pseudo-inc/sys/ksa.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
	- Use bigger stats containers.  Drop old & unused entries.

linux/fs/xfs/linux/xfs_random.c - 1.41
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h
	- Implement the 'xfs_stats' print interface via /proc/sys/fs/xfs_stats.

linux/fs/xfs/linux/xfs_file.c - 1.31
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_file.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h
	- Add XFSSTATS to read/write.

linux/fs/xfs/linux/xfs_vnode.c - 1.26
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_vnode.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h
	- Add VOPINFO stats for vn_active, vn_alloc, vn_free, vn_get,
	  vn_remove.



From owner-linux-xfs@oss.sgi.com Wed May 31 10:25:26 2000
Received:  by oss.sgi.com id <S42301AbQEaRZG>;
	Wed, 31 May 2000 10:25:06 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:14164 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42296AbQEaRZC>;
	Wed, 31 May 2000 10:25:02 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA27721
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 10:17:27 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA91022; Wed, 31 May 2000 12:19:48 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id MAA02647; Wed, 31 May 2000 12:19:47 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id MAA03607; Wed, 31 May 2000 12:19:47 -0500 (CDT)
Message-Id: <200005311719.MAA03607@fsgi344.americas.sgi.com>
Subject: Article in byte.com
To:     moshe@moelabs.com
Date:   Wed, 31 May 2000 12:19:46 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
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


Moshe,

	In your article http://www.byte.com/column/BYT20000524S0007, it
appears you are unaware that SGI has released the XFS code. This was done
a few months ago and the announcements appeared in slashdot and other
places.

Many thousands of people have downloaded XFS and are playing with it.
We have an entire 2.3 kernel tree available for download. (see
http://oss.sgi.com/projects/xfs).

All file system functionality is there, but there are all kinds
of bugs still in the code. We are also adding more XFS functionality
before first release. The current source even has "delayed" allocation
implemented where each writes do not result in an allocation. This is
pretty rough right now and needs more work, but the main code is there.

The implementation is not beta or alpha quality, yet.  We expect to have a
beta quality version in the coming months.

FYI,

Jim


From owner-linux-xfs@oss.sgi.com Wed May 31 10:39:36 2000
Received:  by oss.sgi.com id <S42304AbQEaRj0>;
	Wed, 31 May 2000 10:39:26 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:45144 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42296AbQEaRjL>;
	Wed, 31 May 2000 10:39:11 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA28881
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 10:34:54 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id MAA78989 for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 12:37:15 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id MAA07380; Wed, 31 May 2000 12:37:14 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id MAA03865; Wed, 31 May 2000 12:37:11 -0500
Message-Id: <200005311737.MAA03865@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     Ted Kline <jtk@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - Implement the "/proc/sys/fs/xfs_stats" printout. 
In-Reply-To: Message from Ted Kline <jtk@sgi.com> 
   of "Wed, 31 May 2000 10:37:15 CDT." <200005311537.KAA53389@tiki.americas.sgi.com> 
Date:   Wed, 31 May 2000 12:37:11 -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

> 
> XFS stats have been in the system for a long time; now they
> can be printed by:
> 
> 	cat /proc/sys/fs/xfs_stats
> 

Ted,

probably /proc/fs/xfs/xfs_stats is a better place to put this, /proc/sys
tends to consist of things which control kernel tunables.

Steve



From owner-linux-xfs@oss.sgi.com Wed May 31 10:05:47 2000
Received:  by oss.sgi.com id <S42307AbQEaRF1>;
	Wed, 31 May 2000 10:05:27 -0700
Received: from Cantor.suse.de ([194.112.123.193]:42758 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42296AbQEaRFG>;
	Wed, 31 May 2000 10:05:06 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 38C041E115; Wed, 31 May 2000 20:05:04 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 0253F10A026; Wed, 31 May 2000 20:05:04 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 9677C2F300; Wed, 31 May 2000 20:05:03 +0200 (MEST)
Date:   Wed, 31 May 2000 20:05:03 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Steve Lord <lord@sgi.com>
Cc:     Ted Kline <jtk@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: TAKE - Implement the "/proc/sys/fs/xfs_stats" printout.
Message-ID: <20000531200503.A31398@gruyere.muc.suse.de>
References: <jtk@sgi.com> <200005311737.MAA03865@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200005311737.MAA03865@jen.americas.sgi.com>; from lord@sgi.com on Wed, May 31, 2000 at 12:37:11PM -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 Wed, May 31, 2000 at 12:37:11PM -0500, Steve Lord wrote:
> > 
> > XFS stats have been in the system for a long time; now they
> > can be printed by:
> > 
> > 	cat /proc/sys/fs/xfs_stats
> > 
> 
> Ted,
> 
> probably /proc/fs/xfs/xfs_stats is a better place to put this, /proc/sys
> tends to consist of things which control kernel tunables.

Also the format is hard to parse by a program. I'm sure someone somewhere
will later curse you for that ;) 

-Andi

From owner-linux-xfs@oss.sgi.com Wed May 31 10:41:16 2000
Received:  by oss.sgi.com id <S42309AbQEaRlH>;
	Wed, 31 May 2000 10:41:07 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:4466 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42308AbQEaRku>;
	Wed, 31 May 2000 10:40:50 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA03936
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 11:25:43 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA27062; Wed, 31 May 2000 13:29:19 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id NAA21433; Wed, 31 May 2000 13:29:18 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id NAA03989; Wed, 31 May 2000 13:29:15 -0500
Message-Id: <200005311829.NAA03989@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     "Andi Kleen" <ak@suse.de>
cc:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - Implement the "/proc/sys/fs/xfs_stats" printout. 
In-Reply-To: Message from "Andi Kleen" <ak@suse.de> 
   of "Wed, 31 May 2000 20:05:03 +0200." <20000531200503.A31398@gruyere.muc.suse.de> 
Date:   Wed, 31 May 2000 13:29: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 Wed, May 31, 2000 at 12:37:11PM -0500, Steve Lord wrote:
> > > 
> > > XFS stats have been in the system for a long time; now they
> > > can be printed by:
> > > 
> > > 	cat /proc/sys/fs/xfs_stats
> > > 
> > 
> > Ted,
> > 
> > probably /proc/fs/xfs/xfs_stats is a better place to put this, /proc/sys
> > tends to consist of things which control kernel tunables.
> 
> Also the format is hard to parse by a program. I'm sure someone somewhere
> will later curse you for that ;) 
> 
> -Andi


I think we will be changing that, and there already is a program to display
this stuff, the performance copilot at http://oss.sgi.com/projects/pcp/
the Irix version can understand all these numbers, hooking up the linux
one should not be too hard.

Steve



From owner-linux-xfs@oss.sgi.com Wed May 31 10:41:16 2000
Received:  by oss.sgi.com id <S42313AbQEaRlH>;
	Wed, 31 May 2000 10:41:07 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:7026 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42309AbQEaRkx>;
	Wed, 31 May 2000 10:40:53 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA04125
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 11:27:46 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id NAA29863; Wed, 31 May 2000 13:31:22 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id NAA21989; Wed, 31 May 2000 13:31:22 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id NAA80815; Wed, 31 May 2000 13:31:21 -0500 (CDT)
Message-Id: <200005311831.NAA80815@tiki.americas.sgi.com>
Subject: Re: TAKE - Implement the "/proc/sys/fs/xfs_stats" printout.
To:     ak@suse.de (Andi Kleen)
Date:   Wed, 31 May 2000 13:31:20 -0500 (CDT)
Cc:     lord@sgi.com (Steve Lord), jtk@sgi.com (Ted Kline),
        linux-xfs@oss.sgi.com
In-Reply-To: <20000531200503.A31398@gruyere.muc.suse.de> from "Andi Kleen" at May 31, 2000 08:05:03 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

> 
> On Wed, May 31, 2000 at 12:37:11PM -0500, Steve Lord wrote:
> > > 
> > > XFS stats have been in the system for a long time; now they
> > > can be printed by:
> > > 
> > > 	cat /proc/sys/fs/xfs_stats
> > > 
> > 
> > Ted,
> > 
> > probably /proc/fs/xfs/xfs_stats is a better place to put this, /proc/sys
> > tends to consist of things which control kernel tunables.
> 
> Also the format is hard to parse by a program. I'm sure someone somewhere
> will later curse you for that ;) 
> 
> -Andi
> 

I'm open to moving it, /proc/fs/xfs/.. is a little more difficult, but
not much, I think we need to create the ..xfs.. directory..

How about 2 files?  One good for human eyes & xfs_stats.raw for "more
machine readable?

	-Ted Kline

From owner-linux-xfs@oss.sgi.com Wed May 31 10:51:37 2000
Received:  by oss.sgi.com id <S42308AbQEaRvR>;
	Wed, 31 May 2000 10:51:17 -0700
Received: from Cantor.suse.de ([194.112.123.193]:59656 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42296AbQEaRuu>;
	Wed, 31 May 2000 10:50:50 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 3F1801E1D9; Wed, 31 May 2000 20:50:49 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 9E6DD10A026; Wed, 31 May 2000 20:50:48 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 59BAB2F300; Wed, 31 May 2000 20:50:48 +0200 (MEST)
Date:   Wed, 31 May 2000 20:50:48 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Ted Kline <jtk@sgi.com>
Cc:     ak@suse.de (Andi Kleen), lord@sgi.com (Steve Lord),
        linux-xfs@oss.sgi.com
Subject: Re: TAKE - Implement the "/proc/sys/fs/xfs_stats" printout.
Message-ID: <20000531205048.A31883@gruyere.muc.suse.de>
References: <20000531200503.A31398@gruyere.muc.suse.de> <200005311831.NAA80815@tiki.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200005311831.NAA80815@tiki.americas.sgi.com>; from jtk@sgi.com on Wed, May 31, 2000 at 01:31:20PM -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 Wed, May 31, 2000 at 01:31:20PM -0500, Ted Kline wrote:
> > 
> > On Wed, May 31, 2000 at 12:37:11PM -0500, Steve Lord wrote:
> > > > 
> > > > XFS stats have been in the system for a long time; now they
> > > > can be printed by:
> > > > 
> > > > 	cat /proc/sys/fs/xfs_stats
> > > > 
> > > 
> > > Ted,
> > > 
> > > probably /proc/fs/xfs/xfs_stats is a better place to put this, /proc/sys
> > > tends to consist of things which control kernel tunables.
> > 
> > Also the format is hard to parse by a program. I'm sure someone somewhere
> > will later curse you for that ;) 
> > 
> > -Andi
> > 
> 
> I'm open to moving it, /proc/fs/xfs/.. is a little more difficult, but
> not much, I think we need to create the ..xfs.. directory..
> 
> How about 2 files?  One good for human eyes & xfs_stats.raw for "more
> machine readable?

For machine readable /proc/sys is actually good again (using the sysctl.h
infrastructure with one read only file / variable) 

I guess that would be overkill though, a simple file e.g. in the format
of /proc/cpuinfo that is friendly to both human and machine is probably 
enough.


-Andi

From owner-linux-xfs@oss.sgi.com Wed May 31 11:06:16 2000
Received:  by oss.sgi.com id <S42316AbQEaSGH>;
	Wed, 31 May 2000 11:06:07 -0700
Received: from Cantor.suse.de ([194.112.123.193]:35593 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42296AbQEaSFr>;
	Wed, 31 May 2000 11:05:47 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP id 309EC1E1EA
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 21:05:45 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP id C056710A026
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 21:05:44 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 7EDBF2F300; Wed, 31 May 2000 21:05:44 +0200 (MEST)
Date:   Wed, 31 May 2000 21:05:44 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     linux-xfs@oss.sgi.com
Subject: CONFIG_KIOBUF_IO broken on IDE
Message-ID: <20000531210544.A31694@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I updated a XFS kernel with today's tree, created a new file system
and tried to unpack a glibc-2.1 source rpm onto it. rpm -bp stopped
with EIO on write after writing a few hundred files.

The kernel log gave:

start mounting filesystem: ide1(22,5)       
Ending clean XFS mount for filesystem: ide1(22,5)
blocklog end: 12
linvfs_read_super: sb root ino/128 inode/0xc5a011a0 icnt/2 vp/0xc5a012b0
attempt to access beyond end of device
16:05: rw=0, want=38781096, limit=8191984
end_pg_buffer_io_async not uptodate 0 page 0xc119d150
attempt to access beyond end of device
16:05: rw=0, want=38781096, limit=8191984
end_pg_buffer_io_async not uptodate 0 page 0xc119d150
attempt to access beyond end of device
16:05: rw=0, want=38781096, limit=8191984
end_pg_buffer_io_async not uptodate 0 page 0xc119d150

fs/page_buf.c is version 1.102
fs/page_buf_locking.c is version 1.24

Relevant .config: 

ONFIG_XFS_FS=m
CONFIG_PAGE_BUF=y
CONFIG_PAGE_BUF_LOCKING=y
CONFIG_AVL=y
# CONFIG_XFS_VNODE_TRACING is not set
CONFIG_KIOBUF_IO=y
CONFIG_AVL=y

When CONFIG_KIOBUF_IO is disabled it seems to work. Looks like the support
for non SCSI devices (XFS is on a IDE disk) in page_buf.c is broken.

Now when trying to remove the directory tree created in the failed unpack
above after a reboot gives funny effects too: 

rm -rf glibc-2.1
rm: cannot remove directory `glibc-2.1/db': File exists
rm: cannot remove directory `glibc-2.1/db2/progs': File exists
rm: cannot remove directory `glibc-2.1/db2': File exists
rm: cannot remove directory `glibc-2.1': File exists
> find glibc-2.1 -ls
8388736    1 drwxr-xr-x   6 ak       users          46 Jun  1 04:44 glibc-2.1
find: glibc-2.1/argp: No such file or directory
12583042    1 drwxr-xr-x   3 ak       users          18 Jun  1 04:43 glibc-2.1/db
find: glibc-2.1/db/btree: No such file or directory
4194458    1 drwxr-xr-x   5 ak       users          40 Jun  1 04:43 glibc-2.1/db2
find: glibc-2.1/db2/common: No such file or directory
find: glibc-2.1/db2/mp: No such file or directory
29360271    1 drwxr-xr-x   3 ak       users          23 Jun  1 04:43 glibc-2.1/db2/progs
find: glibc-2.1/db2/progs/db_dump185: No such file or directory
find: glibc-2.1/elf: No such file or directory

Looks like the disk structure is corrupted now. It gets now 
new messages in the system log [after executing the commands above]:

ttempt to access beyond end of device
16:05: rw=0, want=38779324, limit=8191984
end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
attempt to access beyond end of device
16:05: rw=0, want=38779324, limit=8191984
end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
attempt to access beyond end of device
16:05: rw=0, want=38779324, limit=8191984
end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
attempt to access beyond end of device
16:05: rw=0, want=38779324, limit=8191984
end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
attempt to access beyond end of device
16:05: rw=0, want=38779324, limit=8191984
end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
attempt to access beyond end of device
16:05: rw=0, want=38779324, limit=8191984
end_pg_buffer_io_async not uptodate 0 page 0xc11e5720

The tree cannot be removed anymore.

When I recompile without CONFIG_KIOBUF_IO the scary messages do not appear
anymore, but it is still impossible to remove the tree. The libc unpack
works now too.

I would run fsck on it, but it seems to be impossible to umount a XFS 
file system now (umount gives EBUSY even when lsof shows nothing) 


-Andi


From owner-linux-xfs@oss.sgi.com Wed May 31 12:36:57 2000
Received:  by oss.sgi.com id <S42320AbQEaTgh>;
	Wed, 31 May 2000 12:36:37 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:6178 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42296AbQEaTgg>;
	Wed, 31 May 2000 12:36:36 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA15080
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 13:23:05 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA42920; Wed, 31 May 2000 15:26:29 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id PAA22491; Wed, 31 May 2000 15:26:28 -0500 (CDT)
Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e4VKQJ704499;
	Wed, 31 May 2000 15:26:19 -0500
Message-ID: <3935756B.E2DFFEF7@thebarn.com>
Date:   Wed, 31 May 2000 15:26:19 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andi Kleen <ak@suse.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: CONFIG_KIOBUF_IO broken on IDE
References: <20000531210544.A31694@gruyere.muc.suse.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

Andi Kleen wrote:

What version of the compiler are you using?
I found a bug with 2.95.3, I haven't tracked it down exactly, but it has something
to do with a particular area of code where we are bit shifting the buffer_head disk offset
field.

gcc version 2.91.66 works.


> I updated a XFS kernel with today's tree, created a new file system
> and tried to unpack a glibc-2.1 source rpm onto it. rpm -bp stopped
> with EIO on write after writing a few hundred files.
>
> The kernel log gave:
>
> start mounting filesystem: ide1(22,5)
> Ending clean XFS mount for filesystem: ide1(22,5)
> blocklog end: 12
> linvfs_read_super: sb root ino/128 inode/0xc5a011a0 icnt/2 vp/0xc5a012b0
> attempt to access beyond end of device
> 16:05: rw=0, want=38781096, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
> attempt to access beyond end of device
> 16:05: rw=0, want=38781096, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
> attempt to access beyond end of device
> 16:05: rw=0, want=38781096, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
>
> fs/page_buf.c is version 1.102
> fs/page_buf_locking.c is version 1.24
>
> Relevant .config:
>
> ONFIG_XFS_FS=m
> CONFIG_PAGE_BUF=y
> CONFIG_PAGE_BUF_LOCKING=y
> CONFIG_AVL=y
> # CONFIG_XFS_VNODE_TRACING is not set
> CONFIG_KIOBUF_IO=y
> CONFIG_AVL=y
>
> When CONFIG_KIOBUF_IO is disabled it seems to work. Looks like the support
> for non SCSI devices (XFS is on a IDE disk) in page_buf.c is broken.
>
> Now when trying to remove the directory tree created in the failed unpack
> above after a reboot gives funny effects too:
>
> rm -rf glibc-2.1
> rm: cannot remove directory `glibc-2.1/db': File exists
> rm: cannot remove directory `glibc-2.1/db2/progs': File exists
> rm: cannot remove directory `glibc-2.1/db2': File exists
> rm: cannot remove directory `glibc-2.1': File exists
> > find glibc-2.1 -ls
> 8388736    1 drwxr-xr-x   6 ak       users          46 Jun  1 04:44 glibc-2.1
> find: glibc-2.1/argp: No such file or directory
> 12583042    1 drwxr-xr-x   3 ak       users          18 Jun  1 04:43 glibc-2.1/db
> find: glibc-2.1/db/btree: No such file or directory
> 4194458    1 drwxr-xr-x   5 ak       users          40 Jun  1 04:43 glibc-2.1/db2
> find: glibc-2.1/db2/common: No such file or directory
> find: glibc-2.1/db2/mp: No such file or directory
> 29360271    1 drwxr-xr-x   3 ak       users          23 Jun  1 04:43 glibc-2.1/db2/progs
> find: glibc-2.1/db2/progs/db_dump185: No such file or directory
> find: glibc-2.1/elf: No such file or directory
>
> Looks like the disk structure is corrupted now. It gets now
> new messages in the system log [after executing the commands above]:
>
> ttempt to access beyond end of device
> 16:05: rw=0, want=38779324, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
> attempt to access beyond end of device
> 16:05: rw=0, want=38779324, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
> attempt to access beyond end of device
> 16:05: rw=0, want=38779324, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
> attempt to access beyond end of device
> 16:05: rw=0, want=38779324, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
> attempt to access beyond end of device
> 16:05: rw=0, want=38779324, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
> attempt to access beyond end of device
> 16:05: rw=0, want=38779324, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
>
> The tree cannot be removed anymore.
>
> When I recompile without CONFIG_KIOBUF_IO the scary messages do not appear
> anymore, but it is still impossible to remove the tree. The libc unpack
> works now too.
>
> I would run fsck on it, but it seems to be impossible to umount a XFS
> file system now (umount gives EBUSY even when lsof shows nothing)
>
> -Andi


From owner-linux-xfs@oss.sgi.com Wed May 31 12:40:07 2000
Received:  by oss.sgi.com id <S42321AbQEaTj5>;
	Wed, 31 May 2000 12:39:57 -0700
Received: from Cantor.suse.de ([194.112.123.193]:21774 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42296AbQEaTjs>;
	Wed, 31 May 2000 12:39:48 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id AC4FE1E217; Wed, 31 May 2000 22:39:46 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 7860210A026; Wed, 31 May 2000 22:39:46 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 0FB1F2F300; Wed, 31 May 2000 22:39:46 +0200 (MEST)
Date:   Wed, 31 May 2000 22:39:46 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     Andi Kleen <ak@suse.de>, linux-xfs@oss.sgi.com
Subject: Re: CONFIG_KIOBUF_IO broken on IDE
Message-ID: <20000531223946.A400@gruyere.muc.suse.de>
References: <20000531210544.A31694@gruyere.muc.suse.de> <3935756B.E2DFFEF7@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <3935756B.E2DFFEF7@thebarn.com>; from cattelan@thebarn.com on Wed, May 31, 2000 at 03:26:19PM -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 Wed, May 31, 2000 at 03:26:19PM -0500, Russell Cattelan wrote:
> Andi Kleen wrote:
> 
> What version of the compiler are you using?
> I found a bug with 2.95.3, I haven't tracked it down exactly, but it has something
> to do with a particular area of code where we are bit shifting the buffer_head disk offset
> field.

I was using gcc 2.95.2.

> 
> gcc version 2.91.66 works.

Thanks, I'll try it with that.

-Andi


From owner-linux-xfs@oss.sgi.com Wed May 31 12:43:07 2000
Received:  by oss.sgi.com id <S42322AbQEaTm5>;
	Wed, 31 May 2000 12:42:57 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:56612 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42296AbQEaTmv>;
	Wed, 31 May 2000 12:42:51 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA16352
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 13:33:33 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id PAA50963; Wed, 31 May 2000 15:37:09 -0500 (CDT)
Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.184.86]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id PAA25337; Wed, 31 May 2000 15:37:08 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.9.3/SGI-client.1.6) via ESMTP id PAA01805; Wed, 31 May 2000 15:37:04 -0500
Message-Id: <200005312037.PAA01805@jen.americas.sgi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To:     "Andi Kleen" <ak@suse.de>
cc:     linux-xfs@oss.sgi.com
Subject: Re: CONFIG_KIOBUF_IO broken on IDE 
In-Reply-To: Message from "Andi Kleen" <ak@suse.de> 
   of "Wed, 31 May 2000 21:05:44 +0200." <20000531210544.A31694@gruyere.muc.suse.de> 
Date:   Wed, 31 May 2000 15:37:03 -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 updated a XFS kernel with today's tree, created a new file system
> and tried to unpack a glibc-2.1 source rpm onto it. rpm -bp stopped
> with EIO on write after writing a few hundred files.

So far my attempts to duplicate this have failed, maybe the issue is more to
do with what rpm does than kiobuf support - it should fall back to other
methods if it is used on a device which does not support it.

I need to go dig out a source rpm and give that a whirl.

Steve

> 
> The kernel log gave:
> 
> start mounting filesystem: ide1(22,5)       
> Ending clean XFS mount for filesystem: ide1(22,5)
> blocklog end: 12
> linvfs_read_super: sb root ino/128 inode/0xc5a011a0 icnt/2 vp/0xc5a012b0
> attempt to access beyond end of device
> 16:05: rw=0, want=38781096, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
> attempt to access beyond end of device
> 16:05: rw=0, want=38781096, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
> attempt to access beyond end of device
> 16:05: rw=0, want=38781096, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
> 
> fs/page_buf.c is version 1.102
> fs/page_buf_locking.c is version 1.24
> 
> Relevant .config: 
> 
> ONFIG_XFS_FS=m
> CONFIG_PAGE_BUF=y
> CONFIG_PAGE_BUF_LOCKING=y
> CONFIG_AVL=y
> # CONFIG_XFS_VNODE_TRACING is not set
> CONFIG_KIOBUF_IO=y
> CONFIG_AVL=y
> 
> When CONFIG_KIOBUF_IO is disabled it seems to work. Looks like the support
> for non SCSI devices (XFS is on a IDE disk) in page_buf.c is broken.
> 
> Now when trying to remove the directory tree created in the failed unpack
> above after a reboot gives funny effects too: 
> 
> rm -rf glibc-2.1
> rm: cannot remove directory `glibc-2.1/db': File exists
> rm: cannot remove directory `glibc-2.1/db2/progs': File exists
> rm: cannot remove directory `glibc-2.1/db2': File exists
> rm: cannot remove directory `glibc-2.1': File exists
> > find glibc-2.1 -ls
> 8388736    1 drwxr-xr-x   6 ak       users          46 Jun  1 04:44 glibc-2.1
> find: glibc-2.1/argp: No such file or directory
> 12583042    1 drwxr-xr-x   3 ak       users          18 Jun  1 04:43 glibc-2.
1/db
> find: glibc-2.1/db/btree: No such file or directory
> 4194458    1 drwxr-xr-x   5 ak       users          40 Jun  1 04:43 glibc-2.1
/db2
> find: glibc-2.1/db2/common: No such file or directory
> find: glibc-2.1/db2/mp: No such file or directory
> 29360271    1 drwxr-xr-x   3 ak       users          23 Jun  1 04:43 glibc-2.
1/db2/progs
> find: glibc-2.1/db2/progs/db_dump185: No such file or directory
> find: glibc-2.1/elf: No such file or directory
> 
> Looks like the disk structure is corrupted now. It gets now 
> new messages in the system log [after executing the commands above]:
> 
> ttempt to access beyond end of device
> 16:05: rw=0, want=38779324, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
> attempt to access beyond end of device
> 16:05: rw=0, want=38779324, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
> attempt to access beyond end of device
> 16:05: rw=0, want=38779324, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
> attempt to access beyond end of device
> 16:05: rw=0, want=38779324, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
> attempt to access beyond end of device
> 16:05: rw=0, want=38779324, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
> attempt to access beyond end of device
> 16:05: rw=0, want=38779324, limit=8191984
> end_pg_buffer_io_async not uptodate 0 page 0xc11e5720
> 
> The tree cannot be removed anymore.
> 
> When I recompile without CONFIG_KIOBUF_IO the scary messages do not appear
> anymore, but it is still impossible to remove the tree. The libc unpack
> works now too.
> 
> I would run fsck on it, but it seems to be impossible to umount a XFS 
> file system now (umount gives EBUSY even when lsof shows nothing) 
> 
> 
> -Andi



From owner-linux-xfs@oss.sgi.com Wed May 31 13:24:27 2000
Received:  by oss.sgi.com id <S42323AbQEaUYR>;
	Wed, 31 May 2000 13:24:17 -0700
Received: from Cantor.suse.de ([194.112.123.193]:35344 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42296AbQEaUYD>;
	Wed, 31 May 2000 13:24:03 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id A3E3B1E222; Wed, 31 May 2000 23:24:01 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 23FCE10A026; Wed, 31 May 2000 23:24:01 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 78FC92F300; Wed, 31 May 2000 23:24:00 +0200 (MEST)
Date:   Wed, 31 May 2000 23:24:00 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     Andi Kleen <ak@suse.de>, linux-xfs@oss.sgi.com
Subject: Re: CONFIG_KIOBUF_IO broken on IDE
Message-ID: <20000531232400.A851@gruyere.muc.suse.de>
References: <20000531210544.A31694@gruyere.muc.suse.de> <3935756B.E2DFFEF7@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <3935756B.E2DFFEF7@thebarn.com>; from cattelan@thebarn.com on Wed, May 31, 2000 at 03:26:19PM -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 Wed, May 31, 2000 at 03:26:19PM -0500, Russell Cattelan wrote:
> Andi Kleen wrote:
> 
> What version of the compiler are you using?
> I found a bug with 2.95.3, I haven't tracked it down exactly, but it has something
> to do with a particular area of code where we are bit shifting the buffer_head disk offset
> field.
> 
> gcc version 2.91.66 works.

I recompiled with 2.91.66. Unfortunately I have managed to create a unbootable
(drops into kdb because of a unrelated problem) 
kernel now, and it seems Lilo's serial console entry got lost. I'm at home,
far away from the box, nobody at work, so I cannot test anymore for tonight.


-Andi

P.S.: at least the new backtracer in kdb looks much better than the old.
Unfortunately that does not help :-(. Sorry.

From owner-linux-xfs@oss.sgi.com Wed May 31 13:34:17 2000
Received:  by oss.sgi.com id <S42324AbQEaUd5>;
	Wed, 31 May 2000 13:33:57 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:7472 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42296AbQEaUdb>; Wed, 31 May 2000 13:33:31 -0700
Received: from getafix.engr.sgi.com (getafix.engr.sgi.com [163.154.5.110]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA03179
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 14:38:17 -0700 (PDT)
	mail_from (chait@getafix.engr.sgi.com)
Received: from localhost (chait@localhost) by getafix.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id OAA93306; Wed, 31 May 2000 14:30:15 -0700 (PDT)
Message-Id: <200005312130.OAA93306@getafix.engr.sgi.com>
To:     Steve Lord <lord@sgi.com>
cc:     "Andi Kleen" <ak@suse.de>, linux-xfs@oss.sgi.com, chait@sgi.com
Subject: Re: CONFIG_KIOBUF_IO broken on IDE 
In-reply-to: Your message of "Wed, 31 May 2000 15:37:03 CDT."
             <200005312037.PAA01805@jen.americas.sgi.com> 
Date:   Wed, 31 May 2000 14:30:14 -0700
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

First off, there is no support for IDE devices in CONFIG_KIOBUF_IO.
That option only works for scsi devices. And the code actually 
checks for that in ll_rw_blk.c, in the function ll_rw_kio():

	/*
	 * Only support SCSI disk for now.
	 *
	 * ENOSYS to indicate caller
	 * should try ll_rw_block()
	 * for non-SCSI (e.g. IDE) disks.
	 */
	if (!SCSI_DISK_MAJOR(MAJOR(dev))){
		*error = -ENOSYS;
		goto end_io;
	}

And the pagebuf_segment_apply() routine should then try the regular
buffer head patch if it gets an ENOSYS from trying a kiobuf-based
I/O request.

See below for further comments.

On Wed, 31 May 2000 15:37:03 CDT, Steve Lord <lord@sgi.com> wrote:
>> I updated a XFS kernel with today's tree, created a new file system
>> and tried to unpack a glibc-2.1 source rpm onto it. rpm -bp stopped
>> with EIO on write after writing a few hundred files.
>
>So far my attempts to duplicate this have failed, maybe the issue is more to
>do with what rpm does than kiobuf support - it should fall back to other
>methods if it is used on a device which does not support it.
>
>I need to go dig out a source rpm and give that a whirl.

I will probably do the same thing shortly.

>> The kernel log gave:
>> 
>> start mounting filesystem: ide1(22,5)       
>> Ending clean XFS mount for filesystem: ide1(22,5)
>> blocklog end: 12
>> linvfs_read_super: sb root ino/128 inode/0xc5a011a0 icnt/2 vp/0xc5a012b0
>> attempt to access beyond end of device
>> 16:05: rw=0, want=38781096, limit=8191984
>> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
>> attempt to access beyond end of device
>> 16:05: rw=0, want=38781096, limit=8191984
>> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
>> attempt to access beyond end of device
>> 16:05: rw=0, want=38781096, limit=8191984
>> end_pg_buffer_io_async not uptodate 0 page 0xc119d150

Hmmm..Its actually trying to go after a device with major number 16...that 
should be a cdrom device, unless I'm mistaken. This is definitely not in 
the new CONFIG_KIOBUF_IO codepath. Why should the  requests be generated to 
read past 8MB of the CD device? 

>> fs/page_buf.c is version 1.102
>> fs/page_buf_locking.c is version 1.24
>> 
>> Relevant .config: 
>> 
>> ONFIG_XFS_FS=m
>> CONFIG_PAGE_BUF=y
>> CONFIG_PAGE_BUF_LOCKING=y
>> CONFIG_AVL=y
>> # CONFIG_XFS_VNODE_TRACING is not set
>> CONFIG_KIOBUF_IO=y
>> CONFIG_AVL=y
>> 
>> When CONFIG_KIOBUF_IO is disabled it seems to work. Looks like the support
>> for non SCSI devices (XFS is on a IDE disk) in page_buf.c is broken.

I guess....I'll dig around the code.

-Chait.

From owner-linux-xfs@oss.sgi.com Wed May 31 13:37:57 2000
Received:  by oss.sgi.com id <S42325AbQEaUhr>;
	Wed, 31 May 2000 13:37:47 -0700
Received: from Cantor.suse.de ([194.112.123.193]:6417 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S42296AbQEaUha>;
	Wed, 31 May 2000 13:37:30 -0700
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 3EFC51E221; Wed, 31 May 2000 23:37:28 +0200 (MEST)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 01C7910A079; Wed, 31 May 2000 23:37:27 +0200 (MEST)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 858B22F300; Wed, 31 May 2000 23:37:27 +0200 (MEST)
Date:   Wed, 31 May 2000 23:37:27 +0200
From:   "Andi Kleen" <ak@suse.de>
To:     Chaitanya Tumuluri <chait@getafix.engr.sgi.com>
Cc:     Steve Lord <lord@sgi.com>, "Andi Kleen" <ak@suse.de>,
        linux-xfs@oss.sgi.com, chait@sgi.com
Subject: Re: CONFIG_KIOBUF_IO broken on IDE
Message-ID: <20000531233727.B939@gruyere.muc.suse.de>
References: <200005312037.PAA01805@jen.americas.sgi.com> <200005312130.OAA93306@getafix.engr.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200005312130.OAA93306@getafix.engr.sgi.com>; from chait@getafix.engr.sgi.com on Wed, May 31, 2000 at 02:30:14PM -0700
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, May 31, 2000 at 02:30:14PM -0700, Chaitanya Tumuluri wrote:
> First off, there is no support for IDE devices in CONFIG_KIOBUF_IO.
> That option only works for scsi devices. And the code actually 
> checks for that in ll_rw_blk.c, in the function ll_rw_kio():
> 
> 	/*
> 	 * Only support SCSI disk for now.
> 	 *
> 	 * ENOSYS to indicate caller
> 	 * should try ll_rw_block()
> 	 * for non-SCSI (e.g. IDE) disks.
> 	 */
> 	if (!SCSI_DISK_MAJOR(MAJOR(dev))){
> 		*error = -ENOSYS;
> 		goto end_io;
> 	}
> 
> And the pagebuf_segment_apply() routine should then try the regular
> buffer head patch if it gets an ENOSYS from trying a kiobuf-based
> I/O request.

Yes, I read that. My theory was that the fallback path is broken.
Unfortunately I cannot test it for tonight anymore, sorry.


> 
> >> The kernel log gave:
> >> 
> >> start mounting filesystem: ide1(22,5)       
> >> Ending clean XFS mount for filesystem: ide1(22,5)
> >> blocklog end: 12
> >> linvfs_read_super: sb root ino/128 inode/0xc5a011a0 icnt/2 vp/0xc5a012b0
> >> attempt to access beyond end of device
> >> 16:05: rw=0, want=38781096, limit=8191984
> >> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
> >> attempt to access beyond end of device
> >> 16:05: rw=0, want=38781096, limit=8191984
> >> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
> >> attempt to access beyond end of device
> >> 16:05: rw=0, want=38781096, limit=8191984
> >> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
> 
> Hmmm..Its actually trying to go after a device with major number 16...that 
> should be a cdrom device, unless I'm mistaken. This is definitely not in 
> the new CONFIG_KIOBUF_IO codepath. Why should the  requests be generated to 
> read past 8MB of the CD device? 

The HD is connected to the second controller, the HD is /dev/hdc
[was not my idea, I got it this way]



-Andi


From owner-linux-xfs@oss.sgi.com Wed May 31 13:46:16 2000
Received:  by oss.sgi.com id <S42326AbQEaUp4>;
	Wed, 31 May 2000 13:45:56 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29746 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42296AbQEaUps>; Wed, 31 May 2000 13:45:48 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA07569
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 14:50:34 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id QAA29538; Wed, 31 May 2000 16:43:59 -0500 (CDT)
Received: from gibble.americas.sgi.com (root@gibble.americas.sgi.com [128.162.195.80]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id QAA12788; Wed, 31 May 2000 16:43:59 -0500 (CDT)
Received: from thebarn.com (IDENT:cattelan@gibble.americas.sgi.com [128.162.195.80])
	by gibble.americas.sgi.com (8.10.1/8.10.1) with ESMTP id e4VLho714310;
	Wed, 31 May 2000 16:43:50 -0500
Message-ID: <39358795.E12AC45F@thebarn.com>
Date:   Wed, 31 May 2000 16:43:49 -0500
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.15-0.28mdksmp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Chaitanya Tumuluri <chait@getafix.engr.sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: CONFIG_KIOBUF_IO broken on IDE
References: <200005312130.OAA93306@getafix.engr.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

Chaitanya Tumuluri wrote:

I wouldn't dig into this to far.. I'm 90% sure it's the compiler bug.
I chased this for 2 day before I realized that adding a printk to debug the
problem
would actually cause the problem to go away; removing the printk caused
it reappear.

> First off, there is no support for IDE devices in CONFIG_KIOBUF_IO.
> That option only works for scsi devices. And the code actually
> checks for that in ll_rw_blk.c, in the function ll_rw_kio():
>
>         /*
>          * Only support SCSI disk for now.
>          *
>          * ENOSYS to indicate caller
>          * should try ll_rw_block()
>          * for non-SCSI (e.g. IDE) disks.
>          */
>         if (!SCSI_DISK_MAJOR(MAJOR(dev))){
>                 *error = -ENOSYS;
>                 goto end_io;
>         }
>
> And the pagebuf_segment_apply() routine should then try the regular
> buffer head patch if it gets an ENOSYS from trying a kiobuf-based
> I/O request.
>
> See below for further comments.
>
> On Wed, 31 May 2000 15:37:03 CDT, Steve Lord <lord@sgi.com> wrote:
> >> I updated a XFS kernel with today's tree, created a new file system
> >> and tried to unpack a glibc-2.1 source rpm onto it. rpm -bp stopped
> >> with EIO on write after writing a few hundred files.
> >
> >So far my attempts to duplicate this have failed, maybe the issue is more to
> >do with what rpm does than kiobuf support - it should fall back to other
> >methods if it is used on a device which does not support it.
> >
> >I need to go dig out a source rpm and give that a whirl.
>
> I will probably do the same thing shortly.
>
> >> The kernel log gave:
> >>
> >> start mounting filesystem: ide1(22,5)
> >> Ending clean XFS mount for filesystem: ide1(22,5)
> >> blocklog end: 12
> >> linvfs_read_super: sb root ino/128 inode/0xc5a011a0 icnt/2 vp/0xc5a012b0
> >> attempt to access beyond end of device
> >> 16:05: rw=0, want=38781096, limit=8191984
> >> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
> >> attempt to access beyond end of device
> >> 16:05: rw=0, want=38781096, limit=8191984
> >> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
> >> attempt to access beyond end of device
> >> 16:05: rw=0, want=38781096, limit=8191984
> >> end_pg_buffer_io_async not uptodate 0 page 0xc119d150
>
> Hmmm..Its actually trying to go after a device with major number 16...that
> should be a cdrom device, unless I'm mistaken. This is definitely not in
> the new CONFIG_KIOBUF_IO codepath. Why should the  requests be generated to
> read past 8MB of the CD device?
>
> >> fs/page_buf.c is version 1.102
> >> fs/page_buf_locking.c is version 1.24
> >>
> >> Relevant .config:
> >>
> >> ONFIG_XFS_FS=m
> >> CONFIG_PAGE_BUF=y
> >> CONFIG_PAGE_BUF_LOCKING=y
> >> CONFIG_AVL=y
> >> # CONFIG_XFS_VNODE_TRACING is not set
> >> CONFIG_KIOBUF_IO=y
> >> CONFIG_AVL=y
> >>
> >> When CONFIG_KIOBUF_IO is disabled it seems to work. Looks like the support
> >> for non SCSI devices (XFS is on a IDE disk) in page_buf.c is broken.
>
> I guess....I'll dig around the code.
>
> -Chait.


From owner-linux-xfs@oss.sgi.com Wed May 31 13:52:16 2000
Received:  by oss.sgi.com id <S42328AbQEaUv4>;
	Wed, 31 May 2000 13:51:56 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:62515 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42296AbQEaUvm>; Wed, 31 May 2000 13:51:42 -0700
Received: from getafix.engr.sgi.com (getafix.engr.sgi.com [163.154.5.110]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA07135
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 14:56:28 -0700 (PDT)
	mail_from (chait@getafix.engr.sgi.com)
Received: from localhost (chait@localhost) by getafix.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id OAA93646; Wed, 31 May 2000 14:49:06 -0700 (PDT)
Message-Id: <200005312149.OAA93646@getafix.engr.sgi.com>
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: CONFIG_KIOBUF_IO broken on IDE 
In-reply-to: Your message of "Wed, 31 May 2000 16:43:49 CDT."
             <39358795.E12AC45F@thebarn.com> 
Date:   Wed, 31 May 2000 14:49:06 -0700
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

Hogay. Thanks for the heads-up.....my mailer is acting up and 
I didn't get all the messages in order...I'll hold off digging 
into it for now.

-Chait.

On Wed, 31 May 2000 16:43:49 CDT, Russell Cattelan <cattelan@thebarn.com> wrote:
>Chaitanya Tumuluri wrote:
>
>I wouldn't dig into this to far.. I'm 90% sure it's the compiler bug.
>I chased this for 2 day before I realized that adding a printk to debug the
>problem
>would actually cause the problem to go away; removing the printk caused
>it reappear.
>

From owner-linux-xfs@oss.sgi.com Wed May 31 14:14:57 2000
Received:  by oss.sgi.com id <S42331AbQEaVOq>;
	Wed, 31 May 2000 14:14:46 -0700
Received: from lips.borg.umn.edu ([160.94.232.50]:25872 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S42296AbQEaVOm>;
	Wed, 31 May 2000 14:14:42 -0700
Received: (from cattelan@localhost)
	by lips.borg.umn.edu (8.10.0/8.10.0) id e4VMEgM84404
	for linux-xfs@oss.sgi.com; Wed, 31 May 2000 17:14:42 -0500 (CDT)
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by lips.borg.umn.edu (8.10.0/8.10.0) with ESMTP id e4VMEe684396
	for <cattelan@thebarn.com>; Wed, 31 May 2000 17:14:41 -0500 (CDT)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09082; Wed, 31 May 2000 15:19:25 -0700 (PDT)
	mail_from (owner-slinx-xfs@cthulhu.engr.sgi.com)
Received: (from majordomo-owner@localhost)
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	id PAA86979
	for slinx-xfs-list;
	Wed, 31 May 2000 15:14:30 -0700 (PDT)
	mail_from (owner-slinx-xfs@relay.engr.sgi.com)
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA16658
	for <slinx-xfs@cthulhu.engr.sgi.com>;
	Wed, 31 May 2000 15:14:29 -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 PAA27499 for <slinx-xfs@engr>; Wed, 31 May 2000 15:11:16 -0700 (PDT)
Message-ID: <39358EB8.1B6DA433@sgi.com>
Date:   Wed, 31 May 2000 15:14:16 -0700
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     slinx-xfs@cthulhu.engr.sgi.com
Subject: kdb problems
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


kdb is behaving odd of late while switching
cpus. Don't know when it started happening,
but I'm seeing this as of today. I have a completely
uptodate tree ...

On a running kernel, I entered kdb with a <cntrl>-a,
then trying to switch cpus hangs the system:

----------
Entering kdb (0xc02d8000) on processor 0 due to Keyboard Entry
[0]kdb> bt
    EBP       EIP         Function(args)
           0xc010730d default_idle+0x2d
                               kernel .text 0xc0100000 0xc01072e0 0xc0107314
           0xc0107352 cpu_idle+0x3e
                               kernel .text 0xc0100000 0xc0107314 0xc0107368
[0]kdb> cpu 1
Debugger re-entered, allowing event to proceed

wait_on_irq, CPU 1:
irq:  1 [ 1 0 ]
bh:   1 [ 0 1 ]
Stack dumps:
CPU 0: <unknown> 
CPU 1:c117bebc c0212413 00000001 00000000 00000020 c010c46d c0212428 c11b1380 
       00000003 00000001 c035b320 c018bdf4 00000004 c035f090 c117a000 c035f580 
       c01257c8 00000000 00000020 c117a000 c035f580 c030b4d0 00000020 c0123a3e 
Call Trace: [<c0212413>] [<c010c46d>] [<c0212428>] [<c018bdf4>] [<c01257c8>] [<c0123a3e>]
[<c0123945>] 
       [<c012376a>] [<c010ca11>] [<c01072e0>] [<c01072e0>] [<c010a5a0>] [<c01072e0>]
[<c01072e0>] [<c0100018>] 
       [<c010730d>] [<c0107352>] [<c010a5a0>] 
-----------------

The wait_on_irq symptom seems to repeat a few times
after long pauses, but I have seen the system hang
witouth any message at all.

Obviously, this is a big impediment to development work ...

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


From owner-linux-xfs@oss.sgi.com Wed May 31 14:23:46 2000
Received:  by oss.sgi.com id <S42332AbQEaVXg>;
	Wed, 31 May 2000 14:23:36 -0700
Received: from rising.starnet.gov.sg ([203.116.82.211]:24709 "EHLO
        rising.starnet.gov.sg") by oss.sgi.com with ESMTP id <S42296AbQEaVXQ>;
	Wed, 31 May 2000 14:23:16 -0700
Received: from aries (dyn1-166cable.bp1.singa.pore.net [202.169.229.166])
	by rising.starnet.gov.sg (8.9.1/8.9.1) with SMTP id GAA12143
	for <linux-xfs@oss.sgi.com>; Thu, 1 Jun 2000 06:23:08 +0800 (SGT)
Message-ID: <001e01bfcb4e$cb8bfd20$a6e5a9ca@aries>
From:   "Tan Pong Heng" <pongheng@starnet.gov.sg>
To:     <linux-xfs@oss.sgi.com>
Subject: FAT filesystem broken in CVS
Date:   Thu, 1 Jun 2000 06:23:06 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001B_01BFCB91.D96080E0"
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
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_001B_01BFCB91.D96080E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi, I just notice in my kernel boot log that the FAT filesystem is not =
working in=20
the recent CVS. I configured XFS as part of the kernel but FAT/VFAT as =
modules.
As I don't have SCSI devices, I did not configured KIO and also did not =
have any
of the debug related XFS options (no kdb too).

The log showed that the loading of the fat module had failed since a few =
days ago
with a message from init_module - can't remember the exact message as I =
am not
in Linux mode now.

Not that it is important - just want to report any problems that I =
encountered....

------=_NextPart_000_001B_01BFCB91.D96080E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3017.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi, I just notice in my kernel boot log =
that the=20
FAT filesystem is not working in </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>the recent CVS. I configured XFS as =
part of the=20
kernel but FAT/VFAT as modules.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>As I don't have SCSI devices, I did not =
configured=20
KIO and also did not have any</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>of the debug related XFS options (no =
kdb=20
too).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The log showed that the loading of the =
fat module=20
had failed since a few days ago</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>with a message from init_module - can't =
remember=20
the exact message as I am not</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>in Linux mode now.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Not that it is important - just want to =
report any=20
problems that I encountered....</FONT></DIV></BODY></HTML>

------=_NextPart_000_001B_01BFCB91.D96080E0--


From owner-linux-xfs@oss.sgi.com Wed May 31 15:52:57 2000
Received:  by oss.sgi.com id <S42283AbQEaWwr>;
	Wed, 31 May 2000 15:52:47 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:12135 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42272AbQEaWw3>;
	Wed, 31 May 2000 15:52:29 -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 QAA12336
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 16:47:34 -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 JAA09369; Thu, 1 Jun 2000 09:51:10 +1000
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA10644; Thu, 1 Jun 2000 09:51:08 +1000 (EST)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10006010951.ZM10643@wobbly.melbourne.sgi.com>
Date:   Thu, 1 Jun 2000 09:51:06 -0500
In-Reply-To: Steve Lord <lord@sgi.com>
        "Re: TAKE - Implement the "/proc/sys/fs/xfs_stats" printout." (Jun  1,  4:54am)
References: <200005311829.NAA03989@jen.americas.sgi.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     jtk@sgi.com, lord@sgi.com
Subject: Re: TAKE - Implement the "/proc/sys/fs/xfs_stats" printout.
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,

On Jun 1,  4:54am, Steve Lord wrote:
> Subject: Re: TAKE - Implement the "/proc/sys/fs/xfs_stats" printout.
> > On Wed, May 31, 2000 at 12:37:11PM -0500, Steve Lord wrote:
> > > > 
> > > > XFS stats have been in the system for a long time; now they
> > > > can be printed by:
> > > > 
> > > > 	cat /proc/sys/fs/xfs_stats
> > > > 
> > > 
> > > Ted,
> > > 
> > > probably /proc/fs/xfs/xfs_stats is a better place to put this, /proc/sys
> > > tends to consist of things which control kernel tunables.
> > 
> > Also the format is hard to parse by a program. I'm sure someone somewhere
> > will later curse you for that ;) 
> > 
> > -Andi
> 
> 
> I think we will be changing that, and there already is a program to display
> this stuff, the performance copilot at http://oss.sgi.com/projects/pcp/
> the Irix version can understand all these numbers, hooking up the linux
> one should not be too hard.
> 

We'll do this today & I'll send mail to linux-xfs@oss and pcp@oss
once we have an updated pcp rpm (I'm not sure how long that process
takes though).

Mark's (markgw) comments on file format etc (having done all the
existing pcp metrics which come from /proc on Linux) are that the
interface should be ascii-only - he suggests using /proc/stat as
a reference.

My 2c on the file name - I prefer /proc/fs/xfs/stat for both
consistency with nfs (/proc/fs/nfs/* subdir) and the option to
add new files to the subdir later, and the "stat" file name for
consistency with most of the other statistics files in procfs.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed May 31 16:31:16 2000
Received:  by oss.sgi.com id <S42303AbQEaXbG>;
	Wed, 31 May 2000 16:31:06 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:11073 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42290AbQEaXbA>; Wed, 31 May 2000 16:31:00 -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 RAA07021
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 17:35:45 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA09677 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 1 Jun 2000 10:29:40 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA02358 for linux-xfs@oss.sgi.com; Thu, 1 Jun 2000 10:29:40 +1000 (EST)
Date:   Thu, 1 Jun 2000 10:29:40 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200006010029.KAA02358@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - add sv_timedwait and sv_timedwait_sig
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Minimal implementation as part of grio work.

Modid:  2.3.99pre2-xfs:slinx:63144a
Date:  Wed May 31 17:28:42 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.3.99pre2-xfs

linux/fs/xfs/linux/xfs_locks.c - 1.21
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_locks.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h
	- add optional timeout to _sv_wait

linux/fs/xfs/linux/xfs_sema.h - 1.25
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_sema.h.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h
	- add definitions for sv_timedwait and sv_timedwait_sig


From owner-linux-xfs@oss.sgi.com Wed May 31 16:42:57 2000
Received:  by oss.sgi.com id <S42329AbQEaXmr>;
	Wed, 31 May 2000 16:42:47 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:1399 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42290AbQEaXmi>;
	Wed, 31 May 2000 16:42:38 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA18149
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 17:37:42 -0700 (PDT)
	mail_from (mostek@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id TAA56108; Wed, 31 May 2000 19:40:04 -0500 (CDT)
Received: from fsgi344.americas.sgi.com (fsgi344.americas.sgi.com [128.162.184.15]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id TAA23884; Wed, 31 May 2000 19:40:03 -0500 (CDT)
From:   Jim Mostek <mostek@sgi.com>
Received: by fsgi344.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id TAA03594; Wed, 31 May 2000 19:40:02 -0500 (CDT)
Message-Id: <200006010040.TAA03594@fsgi344.americas.sgi.com>
Subject: Re: Article in byte.com
To:     moshe@moelabs.com (Moshe Bar)
Date:   Wed, 31 May 2000 19:40:02 -0500 (CDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <NDBBJIDABHDIEFPBCGOCCEHPEKAA.moshe@moelabs.com> from "Moshe Bar" at May 31, 2000 11:43:03 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


SGI is pouring lots of $$ into getting XFS into the Open Source
community. There have been as many as 14 internal people working
on the project. Right now, there are engineers/contractors in Denmark,
Canada, Minnesota, California, and Australia working on this project.

Part of the XFS port involved making modification to Linux itself.
Have you heard of pagebuf? We have exchange e-mail/phone
conferences/... with the ReiserFS and JFS people about joining us
with the pagebuf work. Pagebuf should be usable by other file systems.

There are some (but few) "external hackers" helping with the code.
Since we open sourced, about 4-5 patches have come in from people
outside SGI.

All of the XFS code is now unencumbered. The final source files
were completed in March.

I don't think we should view the JFS, ReiserFS, XFS code as
being in competition. These groups should work together to make
Linux a better OS. Each file system will make its mark. XfS is
fully multi-threaded and highly scalable. It is also journaled
and has other capabilities like Direct I/O, extended attributes,
DMAPI, GRIO, ... Some of these capabilities require changes
outside the file system and this work should be done with others.

The XFS team is looking forward to working with others and
will be attending Usenix (Freenix track) and other conferences
where we should meet and discuss future joint work.

Jim


>
>Dear Jim
>
>I was actually aware of an early release of xfs, but I was told by sgi that
>it was still encumbered by licencing restrictions on parts of the code.
>
>Additioanlly, it seemed that contrary to IBM, sgi was putting very limited
>resources of its own into the project and was instead almost entirely
>relying on external hackers to complete the project.
>
>Is that true? Can you clarify?
>
>Many thanks for writing.
>
>Kind regards
>
>Moshe Bar
>
>
>
>> -----Original Message-----
>> From: Jim Mostek [mailto:mostek@sgi.com]
>> Sent: Wednesday, May 31, 2000 7:20 PM
>> To: moshe@moelabs.com
>> Cc: linux-xfs@oss.sgi.com
>> Subject: Article in byte.com
>>
>>
>>
>> Moshe,
>>
>> 	In your article http://www.byte.com/column/BYT20000524S0007, it
>> appears you are unaware that SGI has released the XFS code. This was done
>> a few months ago and the announcements appeared in slashdot and other
>> places.
>>
>> Many thousands of people have downloaded XFS and are playing with it.
>> We have an entire 2.3 kernel tree available for download. (see
>> http://oss.sgi.com/projects/xfs).
>>
>> All file system functionality is there, but there are all kinds
>> of bugs still in the code. We are also adding more XFS functionality
>> before first release. The current source even has "delayed" allocation
>> implemented where each writes do not result in an allocation. This is
>> pretty rough right now and needs more work, but the main code is there.
>>
>> The implementation is not beta or alpha quality, yet.  We expect to have a
>> beta quality version in the coming months.
>>
>> FYI,
>>
>> Jim
>>
>


From owner-linux-xfs@oss.sgi.com Wed May 31 17:52:58 2000
Received:  by oss.sgi.com id <S42336AbQFAAws>;
	Wed, 31 May 2000 17:52:48 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:9739 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42272AbQFAAwi>;
	Wed, 31 May 2000 17:52:38 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA24763
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 18:47:43 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id UAA97235; Wed, 31 May 2000 20:51:15 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id UAA11123; Wed, 31 May 2000 20:51:14 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id UAA94104; Wed, 31 May 2000 20:51:13 -0500 (CDT)
Message-Id: <200006010151.UAA94104@tiki.americas.sgi.com>
Subject: Re: TAKE - Implement the "/proc/sys/fs/xfs_stats" printout.
To:     nathans@wobbly.melbourne.sgi.com (Nathan Scott)
Date:   Wed, 31 May 2000 20:51:13 -0500 (CDT)
Cc:     jtk@sgi.com, lord@sgi.com, linux-xfs@oss.sgi.com
In-Reply-To: <10006010951.ZM10643@wobbly.melbourne.sgi.com> from "Nathan Scott" at Jun 01, 2000 09:51:06 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

> 
> > 
> > I think we will be changing that, and there already is a program to display
> > this stuff, the performance copilot at http://oss.sgi.com/projects/pcp/
> > the Irix version can understand all these numbers, hooking up the linux
> > one should not be too hard.
> > 
> 
> We'll do this today & I'll send mail to linux-xfs@oss and pcp@oss
> once we have an updated pcp rpm (I'm not sure how long that process
> takes though).
> 
> Mark's (markgw) comments on file format etc (having done all the
> existing pcp metrics which come from /proc on Linux) are that the
> interface should be ascii-only - he suggests using /proc/stat as
> a reference.
> 
> My 2c on the file name - I prefer /proc/fs/xfs/stat for both
> consistency with nfs (/proc/fs/nfs/* subdir) and the option to
> add new files to the subdir later, and the "stat" file name for
> consistency with most of the other statistics files in procfs.
> 

I have a change to checkin shortly, changes the path to:

	/proc/fs/xfs/stats

		&

	/proc/fs/xfs/stats.raw

The 'stats' file is easy on the eyes, the 'stats.raw' is simple, easy
to grok ascii, i.e:

	xs_foo	1235

one per line..

Was able to do this by using the same read routine with just a few
more 'if's thrown in..

	-Ted

From owner-linux-xfs@oss.sgi.com Wed May 31 18:15:18 2000
Received:  by oss.sgi.com id <S42338AbQFABO7>;
	Wed, 31 May 2000 18:14:59 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:41488 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42272AbQFABO3>;
	Wed, 31 May 2000 18:14:29 -0700
Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA26855
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 19:09:35 -0700 (PDT)
	mail_from (jtk@sgi.com)
Received: from ironwood-e185.americas.sgi.com (ironwood.cray.com [128.162.185.212]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id VAA85456 for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 21:13:12 -0500 (CDT)
Received: from tiki.americas.sgi.com (tiki.americas.sgi.com [128.162.195.11]) by ironwood-e185.americas.sgi.com (8.8.4/SGI-ironwood-e1.5) with ESMTP id VAA16080; Wed, 31 May 2000 21:13:10 -0500 (CDT)
From:   Ted Kline <jtk@sgi.com>
Received: by tiki.americas.sgi.com (980427.SGI.8.8.8/SGI-client.1.6) id VAA95446; Wed, 31 May 2000 21:13:09 -0500 (CDT)
Message-Id: <200006010213.VAA95446@tiki.americas.sgi.com>
Date:   Wed, 31 May 2000 21:13:09 -0500 (CDT)
To:     linux-xfs@oss.sgi.com
Cc:     jtk@sgi.com
Subject: TAKE - Move the stats file to /proc/fs/xfs/{stats,stats.raw}
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Provide two xfs_stats files, one easy on the eyes, another more
machine readable.  Both come from one read routine.

	/proc/fs/xfs/stats
	/proc/fs/xfs/stats.raw


Date:  Wed May 31 19:06:49 PDT 2000
Workarea:  tiki.cray.com:/data/clink/io/jtk/work-linux2.3-99

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


Modid:  2.3.99pre2-xfs:slinx:63151a
linux/fs/xfs/linux/xfs_random.c - 1.42
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h
	- Move the xfs_stats file to /proc/fs/xfs/stats.
	  Add a /proc/fs/xfs/stats.raw file that's more machine readable.



From owner-linux-xfs@oss.sgi.com Wed May 31 20:06:29 2000
Received:  by oss.sgi.com id <S42341AbQFADGT>;
	Wed, 31 May 2000 20:06:19 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21066 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42272AbQFADGQ>; Wed, 31 May 2000 20:06:16 -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 VAA08621
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 21:10:59 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10781 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 1 Jun 2000 14:04:53 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA06137 for linux-xfs@oss.sgi.com; Thu, 1 Jun 2000 14:04:52 +1000 (EST)
Date:   Thu, 1 Jun 2000 14:04:52 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200006010404.OAA06137@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - fix getf error message
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.3.99pre2-xfs:slinx:63156a
Date:  Wed May 31 21:04:33 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.3.99pre2-xfs

linux/fs/xfs/linux/xfs_random.c - 1.43
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h
	- fix getf error message


From owner-linux-xfs@oss.sgi.com Wed May 31 20:19:59 2000
Received:  by oss.sgi.com id <S42342AbQFADTt>;
	Wed, 31 May 2000 20:19:49 -0700
Received: from [212.41.208.24] ([212.41.208.24]:54021 "EHLO galactica.it")
	by oss.sgi.com with ESMTP id <S42272AbQFADTf>;
	Wed, 31 May 2000 20:19:35 -0700
Received: (apparently) from router ([212.41.207.16]) by galactica.it  with Microsoft SMTPSVC(5.5.1877.447.44);
	 Thu, 1 Jun 2000 06:20:55 +0200
From:   "Moshe Bar" <moshe@moelabs.com>
To:     "Jim Mostek" <mostek@sgi.com>
Cc:     <linux-xfs@oss.sgi.com>
Subject: RE: Article in byte.com
Date:   Thu, 1 Jun 2000 06:19:54 +0200
Message-ID: <NDBBJIDABHDIEFPBCGOCIEIAEKAA.moshe@moelabs.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200006010040.TAA03594@fsgi344.americas.sgi.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Jim,

This is indeed news for me. I shall in that case correct my view in a
seperate article on Byte and duly attribute xfs's achievments.

Many thanks for highlighting these issues.

Kind regards

Moshe Bar
www.moelabs.com



> -----Original Message-----
> From: Jim Mostek [mailto:mostek@sgi.com]
> Sent: Thursday, June 01, 2000 2:40 AM
> To: Moshe Bar
> Cc: linux-xfs@oss.sgi.com
> Subject: Re: Article in byte.com
>
>
>
> SGI is pouring lots of $$ into getting XFS into the Open Source
> community. There have been as many as 14 internal people working
> on the project. Right now, there are engineers/contractors in Denmark,
> Canada, Minnesota, California, and Australia working on this project.
>
> Part of the XFS port involved making modification to Linux itself.
> Have you heard of pagebuf? We have exchange e-mail/phone
> conferences/... with the ReiserFS and JFS people about joining us
> with the pagebuf work. Pagebuf should be usable by other file systems.
>
> There are some (but few) "external hackers" helping with the code.
> Since we open sourced, about 4-5 patches have come in from people
> outside SGI.
>
> All of the XFS code is now unencumbered. The final source files
> were completed in March.
>
> I don't think we should view the JFS, ReiserFS, XFS code as
> being in competition. These groups should work together to make
> Linux a better OS. Each file system will make its mark. XfS is
> fully multi-threaded and highly scalable. It is also journaled
> and has other capabilities like Direct I/O, extended attributes,
> DMAPI, GRIO, ... Some of these capabilities require changes
> outside the file system and this work should be done with others.
>
> The XFS team is looking forward to working with others and
> will be attending Usenix (Freenix track) and other conferences
> where we should meet and discuss future joint work.
>
> Jim
>
>
> >
> >Dear Jim
> >
> >I was actually aware of an early release of xfs, but I was told
> by sgi that
> >it was still encumbered by licencing restrictions on parts of the code.
> >
> >Additioanlly, it seemed that contrary to IBM, sgi was putting
> very limited
> >resources of its own into the project and was instead almost entirely
> >relying on external hackers to complete the project.
> >
> >Is that true? Can you clarify?
> >
> >Many thanks for writing.
> >
> >Kind regards
> >
> >Moshe Bar
> >
> >
> >
> >> -----Original Message-----
> >> From: Jim Mostek [mailto:mostek@sgi.com]
> >> Sent: Wednesday, May 31, 2000 7:20 PM
> >> To: moshe@moelabs.com
> >> Cc: linux-xfs@oss.sgi.com
> >> Subject: Article in byte.com
> >>
> >>
> >>
> >> Moshe,
> >>
> >> 	In your article http://www.byte.com/column/BYT20000524S0007, it
> >> appears you are unaware that SGI has released the XFS code.
> This was done
> >> a few months ago and the announcements appeared in slashdot and other
> >> places.
> >>
> >> Many thousands of people have downloaded XFS and are playing with it.
> >> We have an entire 2.3 kernel tree available for download. (see
> >> http://oss.sgi.com/projects/xfs).
> >>
> >> All file system functionality is there, but there are all kinds
> >> of bugs still in the code. We are also adding more XFS functionality
> >> before first release. The current source even has "delayed" allocation
> >> implemented where each writes do not result in an allocation. This is
> >> pretty rough right now and needs more work, but the main code is there.
> >>
> >> The implementation is not beta or alpha quality, yet.  We
> expect to have a
> >> beta quality version in the coming months.
> >>
> >> FYI,
> >>
> >> Jim
> >>
> >
>


From owner-linux-xfs@oss.sgi.com Wed May 31 21:06:39 2000
Received:  by oss.sgi.com id <S42343AbQFAEG3>;
	Wed, 31 May 2000 21:06:29 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:48972 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42272AbQFAEGO>; Wed, 31 May 2000 21:06:14 -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 WAA00640
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 22:10:58 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA11125 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 1 Jun 2000 15:04:38 +1000
Received: (from dxm@localhost) by snort.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA06839 for linux-xfs@oss.sgi.com; Thu, 1 Jun 2000 15:04:35 +1000 (EST)
Date:   Thu, 1 Jun 2000 15:04:35 +1000 (EST)
From:   dxm@snort.melbourne.sgi.com (Daniel Moore)
Message-Id: <200006010504.PAA06839@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - still return zero from getf 
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

duh

Modid:  2.3.99pre2-xfs:slinx:63158a
Date:  Wed May 31 22:04:06 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.3.99pre2-xfs

linux/fs/xfs/linux/xfs_random.c - 1.44
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/xfs/linux/xfs_random.c.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h
	- still return 0


From owner-linux-xfs@oss.sgi.com Wed May 31 23:04:49 2000
Received:  by oss.sgi.com id <S42344AbQFAGEj>;
	Wed, 31 May 2000 23:04:39 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:11591 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42272AbQFAGES>;
	Wed, 31 May 2000 23:04:18 -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 XAA17248
	for <linux-xfs@oss.sgi.com>; Wed, 31 May 2000 23:59:21 -0700 (PDT)
	mail_from (kaos@moomba.melbourne.sgi.com)
Received: from moomba.melbourne.sgi.com (moomba.melbourne.sgi.com [134.14.55.137]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA11675; Thu, 1 Jun 2000 17:01:28 +1000
Received: (from kaos@localhost) by moomba.melbourne.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id RAA09304; Thu, 1 Jun 2000 17:01:26 +1000 (EST)
Date:   Thu, 1 Jun 2000 17:01:26 +1000 (EST)
From:   kaos@moomba.melbourne.sgi.com (Keith Owens)
Message-Id: <200006010701.RAA09304@moomba.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com, slinx-xfs@cthulhu.engr.sgi.com,
        sgi.bugs.slinx@cthulhu.engr.sgi.com
Subject: TAKE - rewrite kdb SMP handling
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

The kdb SMP handling was convoluted and had no clear distinction between
local (per cpu) and global debugging states.  The logic flow through the
main kdb routine was difficult to follow with multiple return points.  This
is a major rewrite of kdb SMP handling.

Modid:  2.3.99pre2-kdb:slinx:63159a
Date:  Wed May 31 23:57:27 PDT 2000
Workarea:  moomba.melbourne.sgi.com:/tmp_mnt/hosts/sherman/home/kaos/isms/slinx/slinx_2.3.99pre2-kdb
Author:  kaos

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.3.99pre2-kdb

linux/arch/i386/kdb/kdbasupport.c - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/kdbasupport.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/arch/i386/kernel/smp.c - 1.20
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kernel/smp.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h
linux/include/linux/kdb.h - 1.9
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kdb.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h
linux/include/linux/kdbprivate.h - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kdbprivate.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
linux/kdb/kdb_bp.c - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdb_bp.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
linux/kdb/kdbmain.c - 1.11
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdbmain.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h
linux/kdb/kdbsupport.c - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdbsupport.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h

From owner-linux-xfs@oss.sgi.com Wed May 31 23:12:59 2000
Received:  by oss.sgi.com id <S42345AbQFAGMt>;
	Wed, 31 May 2000 23:12:49 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:65352 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42272AbQFAGMh>;
	Wed, 31 May 2000 23:12:37 -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 AAA18037
	for <linux-xfs@oss.sgi.com>; Thu, 1 Jun 2000 00:07:42 -0700 (PDT)
	mail_from (kaos@kao1.melbourne.sgi.com)
Received: from kao1.melbourne.sgi.com (kao1.melbourne.sgi.com [134.14.55.179]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA11742; Thu, 1 Jun 2000 17:11:15 +1000
Received: (from kaos@localhost) by kao1.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id RAA02138; Thu, 1 Jun 2000 17:11:15 +1000 (EST)
Date:   Thu, 1 Jun 2000 17:11:15 +1000 (EST)
From:   kaos@kao1.melbourne.sgi.com (Keith Owens)
Message-Id: <200006010711.RAA02138@kao1.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com, slinx-xfs@cthulhu.engr.sgi.com
Subject: TAKE - rewrite kdb SMP handling
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Rewrite kdb SMP handling

Modid:  2.3.99pre2-xfs:slinx:63159a
Date:  Thu Jun  1 00:09:45 PDT 2000
Workarea:  kao1.melbourne.sgi.com:/hosts/sherman/home/kaos/isms/slinx/slinx_2.3.99pre2-xfs
Author:  kaos
Merged by:  kaos
Merged mods:  2.3.99pre2-kdb:slinx:63159a

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

linux/arch/i386/kdb/kdbasupport.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kdb/kdbasupport.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/arch/i386/kernel/smp.c - 1.20
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/arch/i386/kernel/smp.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h
linux/include/linux/kdb.h - 1.8
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kdb.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h
linux/include/linux/kdbprivate.h - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/include/linux/kdbprivate.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/kdb/kdb_bp.c - 1.5
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdb_bp.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
linux/kdb/kdbmain.c - 1.7
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdbmain.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h
linux/kdb/kdbsupport.c - 1.4
http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/kdb/kdbsupport.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h
	- Merge of 2.3.99pre2-kdb:slinx:63159a by kaos.