From owner-linux-xfs@oss.sgi.com Fri Mar 1 00:01:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2181Dw07078 for linux-xfs-outgoing; Fri, 1 Mar 2002 00:01:13 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2180t907049 for ; Fri, 1 Mar 2002 00:00:56 -0800 Received: from lizard.webland.de (unknown [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx05)) with ESMTP id 50D16612D for ; Fri, 1 Mar 2002 07:43:07 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id HAA24511 for linux-xfs@oss.sgi.com; Fri, 1 Mar 2002 07:43:06 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 863F357306 for ; Fri, 1 Mar 2002 07:42:08 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id D2EF325835 for ; Fri, 1 Mar 2002 07:42:07 +0100 (CET) Message-ID: <3C7F22BF.3AFEA4AF@ch.sauter-bc.com> Date: Fri, 01 Mar 2002 07:42:07 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: fs.h patch in RH 2.4.9-31 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I'm right now compiling updated RedHat errata kernel-2.4.9-31 with XFS support which is then kernel-2.4.9-31SGI_XFS_1.0.2. You'll find the packages again on oss in the a contrib dir when Eric permits. Now I have two questions: 1) After downloading the original RedHat RPMS I found out that both 7.1 and 7.2 packages are exactly the same. So I decided to do the same and I decided to compile on RedHat 7.2 since 7.1 and 7.2 are almost the same but 7.2 has some newer version of compilers and libs and I thought it's a good thing to compile on 7.2. Is it good to compile 7.1 and 7.2 on 7.2 or am I missing something? 2) The jumbo xfs patch linux-2.4.9-RH7.2-xfs.patch.bz2 had two rejects in fs.h. Unfortunately I'm not a programmer so I'm kindly asking for advice whether I have correctly fixed the thing. Those two lines are new in 2.4.9-31 BH_Async, /* 1 if the buffer is under end_buffer_io_async I/O */ #define buffer_async(bh) __buffer_state(bh,Async) I've put them into the patch and the resulting patch looks like this: @@ -226,7 +233,8 @@ BH_New, /* 1 if the buffer is new and not yet written out */ BH_Protected, /* 1 if the buffer is protected */ BH_JBD, /* 1 if it has an attached journal_head */ BH_Async, /* 1 if the buffer is under end_buffer_io_async I/O */ + BH_Delay, /* 1 if the buffer is delayed allocate */ BH_PrivateStart,/* not a state bit, but the first bit available * for private allocation by other entities @@ -286,7 +294,8 @@ #define buffer_mapped(bh) __buffer_state(bh,Mapped) #define buffer_new(bh) __buffer_state(bh,New) #define buffer_protected(bh) __buffer_state(bh,Protected) #define buffer_async(bh) __buffer_state(bh,Async) +#define buffer_delay(bh) __buffer_state(bh,Delay) #define bh_offset(bh) ((unsigned long)(bh)->b_data & ~PAGE_MASK) Is this correct? Or do I have to recompile with a different patch? Thanks in advance. -Simon From owner-linux-xfs@oss.sgi.com Fri Mar 1 00:47:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g218lRC08354 for linux-xfs-outgoing; Fri, 1 Mar 2002 00:47:27 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g218lN908332 for ; Fri, 1 Mar 2002 00:47:23 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g218lHFH014243 for ; Fri, 1 Mar 2002 00:47:18 -0800 Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA94296 for linux-xfs@oss.sgi.com; Fri, 1 Mar 2002 18:46:00 +1100 (EST) Date: Fri, 1 Mar 2002 18:46:00 +1100 (EST) From: Timothy Shimmin Message-Id: <200203010746.SAA94296@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - doc/xfsdump.html Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Feb 28 23:45:12 PST 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:113060a cmd/xfsdump/doc/inode_map.obj - 1.2 - Add a box about the values for the inode state. cmd/xfsdump/doc/inode_map.gif - 1.2 - Add a box about the values for the inode state. cmd/xfsdump/doc/media_files.gif - 1.2 - Add a diagram showing a sequence of different media files. cmd/xfsdump/doc/media_files.obj - 1.2 - Add a diagram showing a sequence of different media files. cmd/xfsdump/doc/xfsdump.html - 1.3 - Reorganise a bit, add more info for xfsrestore and abstract out some info for the flow of xfsdump. --Tim From owner-linux-xfs@oss.sgi.com Fri Mar 1 00:52:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g218qXn08635 for linux-xfs-outgoing; Fri, 1 Mar 2002 00:52:33 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g218qR908612 for ; Fri, 1 Mar 2002 00:52:28 -0800 Received: from auto-nb1.xs4all.nl (213-84-127-168.adsl.xs4all.nl [213.84.127.168]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g217qP0m016694; Fri, 1 Mar 2002 08:52:25 +0100 (CET) Message-Id: <4.3.2.7.2.20020301084638.02b0cad0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Mar 2002 08:51:32 +0100 To: Simon Matter , linux-xfs From: Seth Mos Subject: Re: fs.h patch in RH 2.4.9-31 In-Reply-To: <3C7F22BF.3AFEA4AF@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 07:42 1-3-2002 +0100, Simon Matter wrote: >Hi > >I'm right now compiling updated RedHat errata kernel-2.4.9-31 with XFS >support which is then kernel-2.4.9-31SGI_XFS_1.0.2. You'll find the >packages again on oss in the a contrib dir when Eric permits. > >Now I have two questions: > >1) After downloading the original RedHat RPMS I found out that both 7.1 >and 7.2 packages are exactly the same. So I decided to do the same and I >decided to compile on RedHat 7.2 since 7.1 and 7.2 are almost the same >but 7.2 has some newer version of compilers and libs and I thought it's >a good thing to compile on 7.2. >Is it good to compile 7.1 and 7.2 on 7.2 or am I missing something? XFree86 updates are available which means that both 7.1 and 7.2 now have XFree86 4.1.0 This gets rid of the different DRI versions that would otherwise be neccesary. >2) The jumbo xfs patch linux-2.4.9-RH7.2-xfs.patch.bz2 had two rejects >in fs.h. Unfortunately I'm not a programmer so I'm kindly asking for >advice whether I have correctly fixed the thing. Those two lines are new >in 2.4.9-31 I don't see anything wrong with that. Seems logical. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Mar 1 01:01:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2191LL09165 for linux-xfs-outgoing; Fri, 1 Mar 2002 01:01:21 -0800 Received: from zeus.city.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2191H909140 for ; Fri, 1 Mar 2002 01:01:17 -0800 Received: by zeus.city.tvnet.hu (Postfix, from userid 500) id D0B633C21810; Fri, 1 Mar 2002 09:03:26 +0100 (CET) Subject: xfs compile error with gcc pre3.1 From: Sipos Ferenc To: "'Xfs Mailing \"List (E-mail)'\"" Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 (1.0.2-1) Date: 01 Mar 2002 09:03:26 +0100 Message-Id: <1014969806.8820.4.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! The stock kernel without xfs compiles fine, but with xfs doesn't. Here is the error: xfs_super.c:822: warning: `linvfs_dentry_to_fh' defined but not used xfs_super.c:859: warning: `linvfs_fh_to_dentry' defined but not used {standard input}: Assembler messages: {standard input}:1164: Error: suffix or operands invalid for `bsf' make[4]: *** [xfs_super.o] Error 1 make[3]: *** [first_rule] Error 2 make[2]: *** [_subdir_linux] Error 2 make[1]: *** [_subdir_xfs] Error 2 make: *** [_dir_fs] Error 2 It would be great, if someone would fix this, I'd like to throw out gcc 2.96. Thx. Paco From owner-linux-xfs@oss.sgi.com Fri Mar 1 02:27:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21ARW711863 for linux-xfs-outgoing; Fri, 1 Mar 2002 02:27:32 -0800 Received: from voyager.st-peter.stw.uni-erlangen.de (mail@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21ARS911837 for ; Fri, 1 Mar 2002 02:27:28 -0800 Received: from svetljo.st-peter.stw.uni-erlangen.de ([172.17.17.181] helo=st-peter.stw.uni-erlangen.de) by voyager.st-peter.stw.uni-erlangen.de with esmtp (Exim 3.12 #1 (Debian)) id 16gjJx-0002kF-00 for ; Fri, 01 Mar 2002 10:27:21 +0100 Message-ID: <3C7F49AE.90003@st-peter.stw.uni-erlangen.de> Date: Fri, 01 Mar 2002 10:28:14 +0100 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: compiling 2.5.6-pre1 xfs_dmapi.c Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16gjJx-0002kF-00*ma0Ryulmrkg* (Studentenwohnanlage Nuernberg St.-Peter) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk gcc -D__KERNEL__ -I/usr/src/linux-2.5.6-pre1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-point er -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/include -I. -funsigned-char -DKBUILD_BAS ENAME=xfs_dmapi -c -o xfs_dmapi.o xfs_dmapi.c xfs_dmapi.c: In function `prohibited_mr_events': xfs_dmapi.c:284: incompatible types in assignment xfs_dmapi.c:272: warning: `vma' might be used uninitialized in this function make[3]: *** [xfs_dmapi.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.5.6-pre1/fs/xfs' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux-2.5.6-pre1/fs/xfs' From owner-linux-xfs@oss.sgi.com Fri Mar 1 04:54:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21CsRq15193 for linux-xfs-outgoing; Fri, 1 Mar 2002 04:54:27 -0800 Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21CsJ915168 for ; Fri, 1 Mar 2002 04:54:19 -0800 Received: from starfleet.attglobal.net (slip-32-100-182-209.wi.us.prserv.net[32.100.182.209]) by prserv.net (out2) with ESMTP id <20020301115353202019qc3oe>; Fri, 1 Mar 2002 11:53:59 +0000 Received: (from skylar@localhost) by starfleet.attglobal.net (8.11.6/8.11.6) id g21BhkB28588 for linux-xfs@oss.sgi.com; Fri, 1 Mar 2002 05:43:46 -0600 Date: Fri, 1 Mar 2002 05:43:46 -0600 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 support? Message-ID: <20020301114346.GA28582@starfleet.attglobal.net> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020301015501.GA7814@starfleet.attglobal.net> <20020301125754.C193798@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <20020301125754.C193798@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.27i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: starfleet.attglobal.net X-Mailer: Mutt 1.3.27i (2002-01-22) X-System: Dual i686 Xeon 450MHz with 256MB ECC-SDRAM X-Machine: IBM Intellistation Z Pro 686522U X-Operating-System: Red Hat Linux 7.2 with kernel 2.4.16 Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.0-7.13 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 01, 2002 at 12:57:54PM +1100, Nathan Scott wrote: > On Thu, Feb 28, 2002 at 07:55:01PM -0600, Skylar Thompson wrote: > > I realize it is very soon, but how long will it take for XFS to be rele= ased > > for the 2.4.18 kernel? > >=20 > > --=20 > > -- Skylar Thompson (skylar@attglobal.net) >=20 > CVS has been at 2.4.18 for all of this week. The patches should > be available early next week, I believe. Wow. Less than three minute response time. Thanks! Anyway, I think I will sit on my hands until the snapshot, just to make sure that other people have the patch goes fine. Not that my stuff is critical, but just to be safe. --=20 -- Skylar Thompson (skylar@attglobal.net) --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8f2lynMU1m27tfjARAq9gAKC3Sy0mvUlAGQL9rhEZj74w9l3LCgCfR2YV NijtFkMeynWP6o8JkVstfag= =hHr7 -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-linux-xfs@oss.sgi.com Fri Mar 1 06:39:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21EdbC23900 for linux-xfs-outgoing; Fri, 1 Mar 2002 06:39:37 -0800 Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21EdT923875 for ; Fri, 1 Mar 2002 06:39:29 -0800 Received: from starfleet.attglobal.net (slip-32-100-182-146.wi.us.prserv.net[32.100.182.146]) by prserv.net (out2) with ESMTP id <200203011339242020359uufe>; Fri, 1 Mar 2002 13:39:24 +0000 Received: (from skylar@localhost) by starfleet.attglobal.net (8.11.6/8.11.6) id g21Cb9H30816 for linux-xfs@oss.sgi.com; Fri, 1 Mar 2002 06:37:09 -0600 Date: Fri, 1 Mar 2002 06:37:09 -0600 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: Re: xfs compile error with gcc pre3.1 Message-ID: <20020301123709.GA30809@starfleet.attglobal.net> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com References: <1014969806.8820.4.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <1014969806.8820.4.camel@zeus.city.tvnet.hu> User-Agent: Mutt/1.3.27i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: starfleet.attglobal.net X-Mailer: Mutt 1.3.27i (2002-01-22) X-System: Dual i686 Xeon 450MHz with 256MB ECC-SDRAM X-Machine: IBM Intellistation Z Pro 686522U X-Operating-System: Red Hat Linux 7.2 with kernel 2.4.16 Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.0-7.13 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 01, 2002 at 09:03:26AM +0100, Sipos Ferenc wrote: > Hi! >=20 > The stock kernel without xfs compiles fine, but with xfs doesn't. Here > is the error: >=20 > xfs_super.c:822: warning: `linvfs_dentry_to_fh' defined but not used > xfs_super.c:859: warning: `linvfs_fh_to_dentry' defined but not used > {standard input}: Assembler messages: > {standard input}:1164: Error: suffix or operands invalid for `bsf' > make[4]: *** [xfs_super.o] Error 1 > make[3]: *** [first_rule] Error 2 > make[2]: *** [_subdir_linux] Error 2 > make[1]: *** [_subdir_xfs] Error 2 > make: *** [_dir_fs] Error 2 >=20 > It would be great, if someone would fix this, I'd like to throw out gcc > 2.96. Thx. Could you give the stable gcc v3 (3.0.4, IIRC) a try? Also, what kernel version and patch version are you using? I've never had any trouble with gcc v3.02 and any XFS-enabled kernel. =20 > Paco --=20 -- Skylar Thompson (skylar@attglobal.net) --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8f3X1nMU1m27tfjARAoQqAJ9FDXF/aIlVDzoGViMqaujcHFgqBgCfXFJi efBNV0iScLzwtrrGTnR6oRI= =4ysA -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From owner-linux-xfs@oss.sgi.com Fri Mar 1 07:04:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21F4IS25466 for linux-xfs-outgoing; Fri, 1 Mar 2002 07:04:18 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21F4D925444 for ; Fri, 1 Mar 2002 07:04:13 -0800 Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA09877 for ; Fri, 1 Mar 2002 06:04:14 -0800 (PST) mail_from (xfs@wingenbach.org) Received: from user-uivf3d5.dsl.mindspring.com ([165.247.141.165] helo=sandbox.wingenbach.org) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16gnV0-0004bT-00; Fri, 01 Mar 2002 08:55:02 -0500 Received: from wingenbach.org (wiz.wingenbach.org [10.10.10.10]) by sandbox.wingenbach.org (8.11.4/8.11.4) with ESMTP id g21DkLT25404; Fri, 1 Mar 2002 08:46:24 -0500 (EST) Message-ID: <3C7F881F.6FD736E1@wingenbach.org> Date: Fri, 01 Mar 2002 08:54:39 -0500 From: John Wingenbach X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sipos Ferenc CC: "'Xfs Mailing \"List (E-mail)'\"" Subject: Re: xfs compile error with gcc pre3.1 References: <1014969806.8820.4.camel@zeus.city.tvnet.hu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I used gcc 3.0.2 with no problems. When I first installed my box I tossed away gcc-2.96 since it is buggy (optimization bug). My environment is Redhat 7.2 (i386) base. Upgraded kernel via xfs cvs. System now running LVM / xfs. -- John Sipos Ferenc wrote: > Hi! > > The stock kernel without xfs compiles fine, but with xfs doesn't. Here > is the error: > > xfs_super.c:822: warning: `linvfs_dentry_to_fh' defined but not used > xfs_super.c:859: warning: `linvfs_fh_to_dentry' defined but not used > {standard input}: Assembler messages: > {standard input}:1164: Error: suffix or operands invalid for `bsf' > make[4]: *** [xfs_super.o] Error 1 > make[3]: *** [first_rule] Error 2 > make[2]: *** [_subdir_linux] Error 2 > make[1]: *** [_subdir_xfs] Error 2 > make: *** [_dir_fs] Error 2 > > It would be great, if someone would fix this, I'd like to throw out gcc > 2.96. Thx. > > Paco From owner-linux-xfs@oss.sgi.com Fri Mar 1 07:41:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21FfRE29105 for linux-xfs-outgoing; Fri, 1 Mar 2002 07:41:27 -0800 Received: from zeus.city.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21FfB929082 for ; Fri, 1 Mar 2002 07:41:14 -0800 Received: by zeus.city.tvnet.hu (Postfix, from userid 500) id 3D1303C21810; Fri, 1 Mar 2002 15:43:05 +0100 (CET) Subject: Re: xfs compile error with gcc pre3.1 From: Sipos Ferenc To: Skylar Thompson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020301123709.GA30809@starfleet.attglobal.net> References: <1014969806.8820.4.camel@zeus.city.tvnet.hu> <20020301123709.GA30809@starfleet.attglobal.net> Content-Type: text/plain; charset=ISO-8859-2 X-Mailer: Evolution/1.0.2 (1.0.2-1) Date: 01 Mar 2002 15:43:05 +0100 Message-Id: <1014993785.8820.12.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g21FfL929084 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I'm using the 2.4.18 cvs kernel, no extra patches. I use gcc pre3.1 because it's in redhat rawhide, so it is the default compiler at the moment, that's why I'd like to compile my xfs kernel with it. Paco 2002-03-01, P keltezéssel Skylar Thompson ezt írta: > On Fri, Mar 01, 2002 at 09:03:26AM +0100, Sipos Ferenc wrote: > > Hi! > > > > The stock kernel without xfs compiles fine, but with xfs doesn't. Here > > is the error: > > > > xfs_super.c:822: warning: `linvfs_dentry_to_fh' defined but not used > > xfs_super.c:859: warning: `linvfs_fh_to_dentry' defined but not used > > {standard input}: Assembler messages: > > {standard input}:1164: Error: suffix or operands invalid for `bsf' > > make[4]: *** [xfs_super.o] Error 1 > > make[3]: *** [first_rule] Error 2 > > make[2]: *** [_subdir_linux] Error 2 > > make[1]: *** [_subdir_xfs] Error 2 > > make: *** [_dir_fs] Error 2 > > > > It would be great, if someone would fix this, I'd like to throw out gcc > > 2.96. Thx. > > Could you give the stable gcc v3 (3.0.4, IIRC) a try? Also, what kernel > version and patch version are you using? I've never had any trouble with > gcc v3.02 and any XFS-enabled kernel. > > > Paco > > -- > -- Skylar Thompson (skylar@attglobal.net) From owner-linux-xfs@oss.sgi.com Fri Mar 1 07:50:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21Foe929433 for linux-xfs-outgoing; Fri, 1 Mar 2002 07:50:40 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21FoX929411 for ; Fri, 1 Mar 2002 07:50:33 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA1065833 for ; Fri, 1 Mar 2002 15:53:24 +0100 (CET) mail_from (sandeen@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA59959; Fri, 1 Mar 2002 08:49:14 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:sandeen@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA20608; Fri, 1 Mar 2002 08:49:14 -0600 (CST) Date: Fri, 1 Mar 2002 08:48:57 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Sipos Ferenc cc: Skylar Thompson , Subject: Re: xfs compile error with gcc pre3.1 In-Reply-To: <1014993785.8820.12.camel@zeus.city.tvnet.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by yog-sothoth.sgi.com id PAA1065833 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g21FoY929412 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I found this on LKML... http://www.uwsg.iu.edu/hypermail/linux/kernel/0111.3/1332.html > Try changing the "g" in the definition of ffs() (asm/bitops.h) to > "rm"; the "g" constrains incorrectly allows immediate operands. but this is over my head, try it at your own risk. -Eric On 1 Mar 2002, Sipos Ferenc wrote: > Hi! > > I'm using the 2.4.18 cvs kernel, no extra patches. I use gcc pre3.1 > because it's in redhat rawhide, so it is the default compiler at the > moment, that's why I'd like to compile my xfs kernel with it. > > Paco > > 2002-03-01, P keltezéssel Skylar Thompson ezt írta: > > On Fri, Mar 01, 2002 at 09:03:26AM +0100, Sipos Ferenc wrote: > > > Hi! > > > > > > The stock kernel without xfs compiles fine, but with xfs doesn't. Here > > > is the error: > > > > > > xfs_super.c:822: warning: `linvfs_dentry_to_fh' defined but not used > > > xfs_super.c:859: warning: `linvfs_fh_to_dentry' defined but not used > > > {standard input}: Assembler messages: > > > {standard input}:1164: Error: suffix or operands invalid for `bsf' > > > make[4]: *** [xfs_super.o] Error 1 > > > make[3]: *** [first_rule] Error 2 > > > make[2]: *** [_subdir_linux] Error 2 > > > make[1]: *** [_subdir_xfs] Error 2 > > > make: *** [_dir_fs] Error 2 > > > > > > It would be great, if someone would fix this, I'd like to throw out gcc > > > 2.96. Thx. > > > > Could you give the stable gcc v3 (3.0.4, IIRC) a try? Also, what kernel > > version and patch version are you using? I've never had any trouble with > > gcc v3.02 and any XFS-enabled kernel. > > > > > Paco > > > > -- > > -- Skylar Thompson (skylar@attglobal.net) > From owner-linux-xfs@oss.sgi.com Fri Mar 1 08:09:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21G9jR30008 for linux-xfs-outgoing; Fri, 1 Mar 2002 08:09:45 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21G9W929985 for ; Fri, 1 Mar 2002 08:09:32 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA07130 for ; Fri, 1 Mar 2002 07:09:26 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA60642; Fri, 1 Mar 2002 09:08:08 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA72557; Fri, 1 Mar 2002 09:08:07 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g21F7nw07508; Fri, 1 Mar 2002 09:07:49 -0600 Subject: RE: oops umounting full LVM snapshots From: Steve Lord To: "FORRESTER,JUSTIN ""(HP-Loveland,ex1)" Cc: Eric Sandeen , "'Xfs Mailing \"List (E-mail)'\"" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Mar 2002 09:07:49 -0600 Message-Id: <1014995269.24545.173.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-28 at 22:18, FORRESTER,JUSTIN (HP-Loveland,ex1) wrote: > > I was able to get rid of the problem with a simple hack to clear out the > quota flags in the [in-core] sb if we're mounted ro. The fs shutdown > problem went away, as did the subsequent oops. fyi. We have to be very careful about how we fix this, what happens to the root filesystem if it has quotas on it? Quotas on root is possible with XFS, the flags in the superblock tell us we have quotas, but in that case we are mounted readonly. This is definitely on the right track though. Steve > > Justin > > > [lvjf4965 #19%] diff -C 15 xfs_mount.c.orig xfs_mount.c > *** xfs_mount.c.orig Fri Feb 22 19:47:23 2002 > --- xfs_mount.c Thu Feb 28 20:27:26 2002 > *************** > *** 942,971 **** > --- 942,980 ---- > cmn_err(CE_WARN, "XFS: failed to read RT inodes"); > rvp->v_flag |= VPURGE; > VMAP(rvp, rip, vmap); > VN_RELE(rvp); > vn_purge(rvp, &vmap); > goto error3; > } > > /* > * If fs is not mounted readonly, then update the superblock > * unit and width changes. > */ > if (update_flags && !(vfsp->vfs_flag & VFS_RDONLY)) > xfs_mount_log_sbunit(mp, update_flags); > > + /* > + * HACK - prevent quotas from being used in read-only mode. > + * xfs_qm_mount_quotas currently causes xact to occur, which fails > + * (badly) on a ro mount. Quick fix is to just disable quotas on > + * ro mounts for now by clearing qflags in in-core sb. --JustinF > + */ > + if (XFS_MTOVFS(mp)->vfs_flag & VFS_RDONLY) > + xfs_mount_reset_sbqflags(mp); > + > quotaflags = 0; > needquotamount = B_FALSE; > quotaondisk = XFS_SB_VERSION_HASQUOTA(&mp->m_sb) && > mp->m_sb.sb_qflags & (XFS_UQUOTA_ACCT|XFS_GQUOTA_ACCT); > /* > * Figure out if we'll need to do a quotacheck. > * The requirements are a little different depending on whether > * this fs is root or not. > */ > rootqcheck = (mp->m_dev == rootdev && quotaondisk && > ((mp->m_sb.sb_qflags & XFS_UQUOTA_ACCT && > (mp->m_sb.sb_qflags & XFS_UQUOTA_CHKD) == 0) || > (mp->m_sb.sb_qflags & XFS_GQUOTA_ACCT && > (mp->m_sb.sb_qflags & XFS_GQUOTA_CHKD) == 0))); > needquotacheck = rootqcheck || XFS_QM_NEED_QUOTACHECK(mp); > > > > > On 27 Feb 2002, Eric Sandeen wrote: > > > Ok, with Steve's help I think we're getting this narrowed down. There > > seem to be 2 issues: > > > > 1) umounting snapshot causes I/O error & filesystem shutdown > > 2) subsequent oops > > > > The first seems to be that when quota is enabled, _mount_ causes a > > transaction via xfs_qm_mount_quotas. Now the log is dirty, it must be > > flushed on umount, but we're ro -> error -> shutdown. > > > > The second seems to follow from the first, if after this error LVM frees > > a buffer that pagebuf subsequently wants to free again, things fall > > down. We've seen the oops in various unrelated places. Not as clear on > > this one yet, but I'll try error injection over an LVM volume and see > > what happens. But if we can fix the first problem, the second will go > > away in this _particular_ case. :) > > > > FWIW, I have not seen any compiler dependency for this problem yet... > > > > -Eric > > > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 1 08:14:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21GEkP30248 for linux-xfs-outgoing; Fri, 1 Mar 2002 08:14:46 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21GEh930222 for ; Fri, 1 Mar 2002 08:14:43 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA06965 for ; Fri, 1 Mar 2002 07:13:29 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA60862 for ; Fri, 1 Mar 2002 09:12:12 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA69168; Fri, 1 Mar 2002 09:10:50 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g21FAWM07527; Fri, 1 Mar 2002 09:10:32 -0600 Subject: Re: Fwd: Geocrawler.com - linux-kernel - Congrats Marcelo, From: Steve Lord To: Walt H Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C7EF0DC.5070101@mindspring.com> References: <3C7EF0DC.5070101@mindspring.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Mar 2002 09:10:32 -0600 Message-Id: <1014995432.24545.177.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-02-28 at 21:09, Walt H wrote: > Interesting post on lkml regarding XFS in the mainstream 2.4 kernel > series. Maybe alan is the man to talk to? I sure would like to see this > become part of the kernel as opposed to patching everytime. Although, I > must say, the folks at SGI have done a wonderful job of staying on top > of every release, bug fixes etc... > > So Marcello says he wants it stable in ac first, and Alan won't put it in until Linus does (at least some of the interface changes). Its all very complicated ..... Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 1 08:16:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21GGnV30448 for linux-xfs-outgoing; Fri, 1 Mar 2002 08:16:49 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21GGi930419 for ; Fri, 1 Mar 2002 08:16:44 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA04047 for ; Fri, 1 Mar 2002 07:18:17 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA59319; Fri, 1 Mar 2002 09:15:28 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA57649; Fri, 1 Mar 2002 09:15:28 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g21FFAt07559; Fri, 1 Mar 2002 09:15:10 -0600 Subject: Re: xfs compile error with gcc pre3.1 From: Steve Lord To: Sipos Ferenc Cc: "'Xfs \"Mailing \\ List \"\"(E-mail)'\\\"" In-Reply-To: <1014969806.8820.4.camel@zeus.city.tvnet.hu> References: <1014969806.8820.4.camel@zeus.city.tvnet.hu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Mar 2002 09:15:09 -0600 Message-Id: <1014995709.24545.180.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-03-01 at 02:03, Sipos Ferenc wrote: > Hi! > > The stock kernel without xfs compiles fine, but with xfs doesn't. Here > is the error: > > xfs_super.c:822: warning: `linvfs_dentry_to_fh' defined but not used > xfs_super.c:859: warning: `linvfs_fh_to_dentry' defined but not used > {standard input}: Assembler messages: > {standard input}:1164: Error: suffix or operands invalid for `bsf' > make[4]: *** [xfs_super.o] Error 1 > make[3]: *** [first_rule] Error 2 > make[2]: *** [_subdir_linux] Error 2 > make[1]: *** [_subdir_xfs] Error 2 > make: *** [_dir_fs] Error 2 > > It would be great, if someone would fix this, I'd like to throw out gcc > 2.96. Thx. For now you could change this: sb->s_blocksize_bits = ffs(sb->s_blocksize) - 1; to this: sb->s_blocksize_bits = BBSHIFT; That is the only ffs call in there. Steve > > Paco -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 1 11:20:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21JKZ301277 for linux-xfs-outgoing; Fri, 1 Mar 2002 11:20:35 -0800 Received: from voyager.st-peter.stw.uni-erlangen.de (mail@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21JK4901253 for ; Fri, 1 Mar 2002 11:20:04 -0800 Received: from svetljo.st-peter.stw.uni-erlangen.de ([172.17.17.181] helo=st-peter.stw.uni-erlangen.de) by voyager.st-peter.stw.uni-erlangen.de with esmtp (Exim 3.12 #1 (Debian)) id 16grdL-0006WD-00 for ; Fri, 01 Mar 2002 19:19:55 +0100 Message-ID: <3C7FC67F.30602@st-peter.stw.uni-erlangen.de> Date: Fri, 01 Mar 2002 19:20:47 +0100 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: REPOST: linux-2.5.5-xfs-dj1+ 2.5.5-xfs-dj2 (raid0_make_request bug) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16grdL-0006WD-00*k35sZR9x2S2* (Studentenwohnanlage Nuernberg St.-Peter) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi i merged the changes from linux-2.5-xfs cvs tree ( today about 5 hours ago) but the problems is still here and sadly i couldn't compile a clean xfs-tree can smbd please help me to get it working thanks Svetoslav Slavtchev and the old message: ----------------------------------------------------------------------------------------------- i'd like to ask you to CC me because i'm not subscribed to the lists i'm having some interesting troubles i have lvm over soft RAID-0 with LV's formated with XFS and JFS i can work with the JFS LV's, but i can not with the XFS one's, i can not mount them ( no troubles with XFS normal partitions) so i'd like to ask is this problem with XFS or with raid or lvm and is there a way to fix it thanks for your help here is what i found in dmesg ##################################################################################### id0: zone 2 raid0: checking ide/host2/bus0/target0/lun0/part8 ... contained as device 0 (2859456) is smallest!. raid0: checking ide/host3/bus0/target0/lun0/part10 ... nope. raid0: checking ide/host3/bus0/target1/lun0/part6 ... nope. raid0: zone->nb_dev: 1, size: 249024 raid0: current zone offset: 2859456 raid0: done. raid0 : md_size is 8064256 blocks. raid0 : conf->smallest->size is 32128 blocks. raid0 : nb_zone is 252. raid0 : Allocating 2016 bytes for hash. md: updating md0 RAID superblock on device md: ide/host3/bus0/target1/lun0/part6 [events: 000002f3]<6>(write) ide/host3/bus0/target1/lun0/part6's sb offset: 2610432 md: ide/host3/bus0/target0/lun0/part10 [events: 000002f3]<6>(write) ide/host3/bus0/target0/lun0/part10's sb offset: 2594368 md: ide/host2/bus0/target0/lun0/part8 [events: 000002f3]<6>(write) ide/host2/bus0/target0/lun0/part8's sb offset: 2859456 md: considering ide/host3/bus0/target1/lun0/part5 ... md: adding ide/host3/bus0/target1/lun0/part5 ... md: adding ide/host3/bus0/target0/lun0/part8 ... md: adding ide/host2/bus0/target0/lun0/part7 ... md: created md2 md: bind md: bind md: bind md: running: md: ide/host3/bus0/target1/lun0/part5's event counter: 0000031a md: ide/host3/bus0/target0/lun0/part8's event counter: 0000031a md: ide/host2/bus0/target0/lun0/part7's event counter: 0000031a md2: max total readahead window set to 744k md2: 3 data-disks, max readahead per data-disk: 248k raid0: looking at ide/host2/bus0/target0/lun0/part7 raid0: comparing ide/host2/bus0/target0/lun0/part7(4096448) with ide/host2/bus0/target0/lun0/part7(4096448) raid0: END raid0: ==> UNIQUE raid0: 1 zones raid0: looking at ide/host3/bus0/target0/lun0/part8 raid0: comparing ide/host3/bus0/target0/lun0/part8(4096448) with ide/host2/bus0/target0/lun0/part7(4096448) raid0: EQUAL raid0: looking at ide/host3/bus0/target1/lun0/part5 raid0: comparing ide/host3/bus0/target1/lun0/part5(4096448) with ide/host2/bus0/target0/lun0/part7(4096448) raid0: EQUAL raid0: FINAL 1 zones raid0: zone 0 raid0: checking ide/host2/bus0/target0/lun0/part7 ... contained as device 0 (4096448) is smallest!. raid0: checking ide/host3/bus0/target0/lun0/part8 ... contained as device 1 raid0: checking ide/host3/bus0/target1/lun0/part5 ... contained as device 2 raid0: zone->nb_dev: 3, size: 12289344 raid0: current zone offset: 4096448 raid0: done. raid0 : md_size is 12289344 blocks. raid0 : conf->smallest->size is 12289344 blocks. raid0 : nb_zone is 1. raid0 : Allocating 8 bytes for hash. md: updating md2 RAID superblock on device md: ide/host3/bus0/target1/lun0/part5 [events: 0000031b]<6>(write) ide/host3/bus0/target1/lun0/part5's sb offset: 4096448 md: ide/host3/bus0/target0/lun0/part8 [events: 0000031b]<6>(write) ide/host3/bus0/target0/lun0/part8's sb offset: 4096448 md: ide/host2/bus0/target0/lun0/part7 [events: 0000031b]<6>(write) ide/host2/bus0/target0/lun0/part7's sb offset: 4096448 md: considering ide/host3/bus0/target0/lun0/part12 ... md: adding ide/host3/bus0/target0/lun0/part12 ... md: adding ide/host3/bus0/target0/lun0/part6 ... md: adding ide/host3/bus0/target0/lun0/part5 ... md: adding ide/host3/bus0/target0/lun0/part1 ... md: created md6 md: bind md6: WARNING: ide/host3/bus0/target0/lun0/part5 appears to be on the same physical disk as ide/host3/bus0/target0/lun0/part1. True protection against single-disk failure might be compromised. md: bind md6: WARNING: ide/host3/bus0/target0/lun0/part6 appears to be on the same physical disk as ide/host3/bus0/target0/lun0/part5. True protection against single-disk failure might be compromised. md: bind md6: WARNING: ide/host3/bus0/target0/lun0/part12 appears to be on the same physical disk as ide/host3/bus0/target0/lun0/part6. True protection against single-disk failure might be compromised. md: bind md: running: md: ide/host3/bus0/target0/lun0/part12's event counter: 00000391 md: ide/host3/bus0/target0/lun0/part6's event counter: 00000391 md: ide/host3/bus0/target0/lun0/part5's event counter: 00000391 md: ide/host3/bus0/target0/lun0/part1's event counter: 00000391 md6: max total readahead window set to 124k md6: 1 data-disks, max readahead per data-disk: 124k md: updating md6 RAID superblock on device md: ide/host3/bus0/target0/lun0/part12 [events: 00000392]<6>(write) ide/host3/bus0/target0/lun0/part12's sb offset: 9759360 md: ide/host3/bus0/target0/lun0/part6 [events: 00000392]<6>(write) ide/host3/bus0/target0/lun0/part6's sb offset: 513984 md: ide/host3/bus0/target0/lun0/part5 [events: 00000392]<6>(write) ide/host3/bus0/target0/lun0/part5's sb offset: 2088320 md: ide/host3/bus0/target0/lun0/part1 [events: 00000392]<6>(write) ide/host3/bus0/target0/lun0/part1's sb offset: 2048192 md: considering ide/host2/bus0/target0/lun0/part11 ... md: adding ide/host2/bus0/target0/lun0/part11 ... md: adding ide/host2/bus0/target0/lun0/part6 ... md: created md7 md: bind md7: WARNING: ide/host2/bus0/target0/lun0/part11 appears to be on the same physical disk as ide/host2/bus0/target0/lun0/part6. True protection against single-disk failure might be compromised. md: bind md: running: md: ide/host2/bus0/target0/lun0/part11's event counter: 000003bf md: ide/host2/bus0/target0/lun0/part6's event counter: 000003bf md7: max total readahead window set to 124k md7: 1 data-disks, max readahead per data-disk: 124k md: updating md7 RAID superblock on device md: ide/host2/bus0/target0/lun0/part11 [events: 000003c0]<6>(write) ide/host2/bus0/target0/lun0/part11's sb offset: 10514432 md: ide/host2/bus0/target0/lun0/part6 [events: 000003c0]<6>(write) ide/host2/bus0/target0/lun0/part6's sb offset: 3421696 md: ... autorun DONE. LVM version 1.0.1-rc4(ish)(03/10/2001) IEEE 802.2 LLC for Linux 2.1 (c) 1996 Tim Alpaerts NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 131072 bind 65536) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. found reiserfs format "3.6" with standard journal Reiserfs journal params: device 22:4b, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 reiserfs: checking transaction log (ide3(34,75)) for (ide3(34,75)) Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 256k freed Real Time Clock Driver v1.10e loop: loaded (max 32 devices) mice: PS/2 mouse device common for all mice cdrom: open failed. VFS: Disk change detected on device ide1(22,0) Adding Swap: 473876k swap-space (priority 1) Adding Swap: 457812k swap-space (priority 1) Adding Swap: 473876k swap-space (priority 1) XFS mounting filesystem lvm(58,2) raid0_make_request bug: can't convert block across chunks or bigger than 16k 8323317 64 raid0_make_request bug: can't convert block across chunks or bigger than 16k 8323445 64 I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block 0x601f7d ("xlog_bread") error 5 buf count 131072 raid0_make_request bug: can't convert block across chunks or bigger than 16k 8324829 29 I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block 0x602565 ("xlog_bread") error 5 buf count 30208 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,3) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: lvm(58,3) (dev: 58/3) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,1) raid0_make_request bug: can't convert block across chunks or bigger than 16k 23610115 64 raid0_make_request bug: can't convert block across chunks or bigger than 16k 23610243 64 I/O error in filesystem ("lvm(58,1)") meta-data dev 0xc0223a01 block 0xa0218b ("xlog_bread") error 5 buf count 131072 raid0_make_request bug: can't convert block across chunks or bigger than 16k 23611101 29 I/O error in filesystem ("lvm(58,1)") meta-data dev 0xc0223a01 block 0xa02565 ("xlog_bread") error 5 buf count 30208 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,2) raid0_make_request bug: can't convert block across chunks or bigger than 16k 8323317 64 raid0_make_request bug: can't convert block across chunks or bigger than 16k 8323445 64 I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block 0x601f7d ("xlog_bread") error 5 buf count 131072 raid0_make_request bug: can't convert block across chunks or bigger than 16k 8324829 29 I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block 0x602565 ("xlog_bread") error 5 buf count 30208 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,3) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: lvm(58,3) (dev: 58/3) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,1) raid0_make_request bug: can't convert block across chunks or bigger than 16k 23610115 64 raid0_make_request bug: can't convert block across chunks or bigger than 16k 23610243 64 I/O error in filesystem ("lvm(58,1)") meta-data dev 0xc0223a01 block 0xa0218b ("xlog_bread") error 5 buf count 131072 raid0_make_request bug: can't convert block across chunks or bigger than 16k 23611101 29 I/O error in filesystem ("lvm(58,1)") meta-data dev 0xc0223a01 block 0xa02565 ("xlog_bread") error 5 buf count 30208 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed From owner-linux-xfs@oss.sgi.com Fri Mar 1 11:22:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g21JMtT01754 for linux-xfs-outgoing; Fri, 1 Mar 2002 11:22:55 -0800 Received: from zeus.city.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g21JMl901729 for ; Fri, 1 Mar 2002 11:22:47 -0800 Received: by zeus.city.tvnet.hu (Postfix, from userid 500) id 963443C24A84; Fri, 1 Mar 2002 19:25:12 +0100 (CET) Subject: Re: xfs compile error with gcc pre3.1 From: Sipos Ferenc To: Steve Lord Cc: "'Xfs \\ Mailing \\\\ List " "\\ \\ (E-mail)'\\\\\\" In-Reply-To: <1014995709.24545.180.camel@jen.americas.sgi.com> References: <1014969806.8820.4.camel@zeus.city.tvnet.hu> <1014995709.24545.180.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-2 X-Mailer: Evolution/1.0.2 (1.0.2-1) Date: 01 Mar 2002 19:25:12 +0100 Message-Id: <1015007112.1789.0.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g21JMn901730 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thx for your help. It works. Paco 2002-03-01, P keltezéssel Steve Lord ezt írta: > On Fri, 2002-03-01 at 02:03, Sipos Ferenc wrote: > > Hi! > > > > The stock kernel without xfs compiles fine, but with xfs doesn't. Here > > is the error: > > > > xfs_super.c:822: warning: `linvfs_dentry_to_fh' defined but not used > > xfs_super.c:859: warning: `linvfs_fh_to_dentry' defined but not used > > {standard input}: Assembler messages: > > {standard input}:1164: Error: suffix or operands invalid for `bsf' > > make[4]: *** [xfs_super.o] Error 1 > > make[3]: *** [first_rule] Error 2 > > make[2]: *** [_subdir_linux] Error 2 > > make[1]: *** [_subdir_xfs] Error 2 > > make: *** [_dir_fs] Error 2 > > > > It would be great, if someone would fix this, I'd like to throw out gcc > > 2.96. Thx. > > For now you could change this: > > sb->s_blocksize_bits = ffs(sb->s_blocksize) - 1; > > to this: > > sb->s_blocksize_bits = BBSHIFT; > > That is the only ffs call in there. > > Steve > > > > > > Paco > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > From owner-linux-xfs@oss.sgi.com Fri Mar 1 16:08:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g22085612117 for linux-xfs-outgoing; Fri, 1 Mar 2002 16:08:05 -0800 Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2207j912086 for ; Fri, 1 Mar 2002 16:07:46 -0800 Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8]) by ex1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g21N7p411617 for ; Fri, 1 Mar 2002 17:07:51 -0600 (CST) Received: from niri.ncsa.uiuc.edu (niri.ncsa.uiuc.edu [141.142.64.68]) by mx1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g21N7hq02050 for ; Fri, 1 Mar 2002 17:07:43 -0600 (CST) From: Stuart Levy Received: (from slevy@localhost) by niri.ncsa.uiuc.edu (8.8.5/8.8.5) id RAA20680 for linux-xfs@oss.sgi.com; Fri, 1 Mar 2002 17:07:42 -0600 (CST) Date: Fri, 1 Mar 2002 17:07:42 -0600 (CST) Message-Id: <200203012307.RAA20680@niri.ncsa.uiuc.edu> To: linux-xfs@oss.sgi.com Subject: xfs_alloc_lookup kernel oopses with snapshot-xfs-2.4.17-2002-01-23_04:32_UTC? Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've got a fairly large XFS filesystem with an external log: meta-data=/bd isize=256 agcount=188, agsize=1048576 blks data = bsize=4096 blocks=196796242, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 = imaxbits=32 naming =version 2 bsize=4096 log =external bsize=4096 blocks=18065 realtime =none extsz=65536 blocks=0, rtextents=0 Filesystem Size Used Avail Use% Mounted on /dev/sda1 751G 631G 120G 84% /bd running under a stock 2.4.17 kernel with the snapshot-xfs-2.4.17-2002-01-23_04:32_UTC xfs-2.4.17-all-i386 patch applied. XFS is built as a module; _RT, _QUOTA, _DMAPI all turned off. I'd also applied all of Trond Myklebust's NFS-related 2.4.17 patches from http://www.fys.uio.no/~trondmy/src/2.4.17/. Compiled under gcc 2.95.3 20010315. Filesystem built using xfsprogs-1.3.13. Hardware is a dual-processor Athlon MP, Tyan 2460, 3ware 7850 8-port IDE RAID (780GB) plus IDE disk on the motherboard (system disk, plus XFS external log partition). The whole thing worked well for a few days' fairly heavy use. But for the last couple of days -- the file system has become more than about half full -- I've been getting kernel oopses like those below, every 2-4 hours' use. After each crash I try mounting/unmounting the filesystem; xfs_check says all's well, and xfs_repair -l /dev/hda5 /dev/sda1 also does. (I had to tweak xfs_repair.c to accept a value for -l -- I see the same change was made in CVS recently too.) Files don't seem to be corrupted, except sometimes for 0-filled ones that were being written at crash time, i.e. all seems well. Does anything seem especially promising to try? Should I build from the live CVS copy (if so, which tag?)? Go back to 2.4.14 and use the 1.0.2 XFS release? Try another compiler? Mar 1 12:59:32 wallbits kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000030 Mar 1 12:59:32 wallbits kernel: f8c35ed2 Mar 1 12:59:32 wallbits kernel: *pde = 00000000 Mar 1 12:59:32 wallbits kernel: Oops: 0000 Mar 1 12:59:32 wallbits kernel: CPU: 0 Mar 1 12:59:32 wallbits kernel: EIP: 0010:[rtc:__insmod_rtc_S.bss_L24+4408630/24018534] Not tainted Mar 1 12:59:32 wallbits kernel: EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Mar 1 12:59:32 wallbits kernel: EFLAGS: 00010246 Mar 1 12:59:32 wallbits kernel: eax: 00000000 ebx: efbd5400 ecx: 00000000 edx: f431af3c Mar 1 12:59:32 wallbits kernel: esi: 00000000 edi: 00000000 ebp: f431aed8 esp: ef953700 Mar 1 12:59:32 wallbits kernel: ds: 0018 es: 0018 ss: 0018 Mar 1 12:59:32 wallbits kernel: Process mergemovie (pid: 2728, stackpage=ef953000) Mar 1 12:59:32 wallbits kernel: Stack: f431aed8 00000000 00000000 ef9537cc f1229a60 00000004 ef9537d0 00000000 Mar 1 12:59:32 wallbits kernel: 51000003 00000000 51000018 00000000 00000000 00000000 00000006 00000000 Mar 1 12:59:32 wallbits kernel: 000000a2 efbd5400 00000001 00000000 00000003 00000000 00000000 f8c37548 Mar 1 12:59:32 wallbits kernel: Call Trace: [rtc:__insmod_rtc_S.bss_L24+4414380/24012784] [rtc:__insmod_rtc_S.bss_L24+4398238/24028926] [rtc:__insmod_rtc_S.bss_L24+4395233/24031931] [rtc:__insmod_rtc_S.bss_L24+4401636/24025528] [rtc:__insmod_rtc_S.bss_L24+4734884/23692280] Mar 1 12:59:32 wallbits kernel: Call Trace: [] [] [] [] [] Mar 1 12:59:32 wallbits kernel: [] [] [] [] [] [] Mar 1 12:59:32 wallbits kernel: [] [] [] [] [] [] Mar 1 12:59:32 wallbits kernel: [] [] [] [] [] [] Mar 1 12:59:32 wallbits kernel: [] [] [] [] [] [] Mar 1 12:59:32 wallbits kernel: [] [] [] [] [] [] Mar 1 12:59:32 wallbits kernel: [] [] [] [] [] [] Mar 1 12:59:32 wallbits kernel: [] Mar 1 12:59:32 wallbits kernel: Code: 8b 50 30 89 54 24 4c 50 56 52 55 e8 5a 74 01 00 83 c4 1c 85 >>EIP; f8c35ed2 <[xfs]xfs_alloc_lookup+11a/340> <===== Trace; f8c37548 <[xfs]xfs_alloc_lookup_ge+20/28> Trace; f8c3363a <[xfs]xfs_alloc_ag_vextent_size+4a/394> Trace; f8c32a7d <[xfs]xfs_alloc_ag_vextent+31/c8> Trace; f8c34380 <[xfs]xfs_alloc_fix_freelist+390/408> Trace; f8c85940 <[xfs]avl_remove+b8/c8> Trace; f8c34b57 <[xfs]xfs_alloc_vextent+333/3d4> Trace; f8917bcb <[xfs_support]mrlock+13/24> Trace; f8c42241 <[xfs]xfs_bmap_alloc+17c1/1afc> Trace; c01e83cf Trace; c01e830c Trace; f8c4bf77 <[xfs]xfs_bmbt_get_state+33/3c> Trace; f8c4bf77 <[xfs]xfs_bmbt_get_state+33/3c> Trace; f8c45b76 <[xfs]xfs_bmapi+6e2/1048> Trace; f8c860ba <[xfs]_pagebuf_free_object+ca/f4> Trace; f8c6f376 <[xfs]xlog_grant_log_space+be/274> Trace; f8c8fdd5 <[xfs]xfs_strategy+605/854> Trace; c012ea0b <__alloc_pages+a3/164> Trace; c012ea0b <__alloc_pages+a3/164> Trace; f8c8e281 <[xfs]linvfs_pb_bmap+85/c4> Trace; f8c9cca0 <[xfs]xfs_vnodeops+0/a0> Trace; f8c89c36 <[xfs]pagebuf_delalloc_convert+42/ec> Trace; f8c88cc9 <[xfs]pagebuf_write_full_page+59/190> Trace; f8c8e1fc <[xfs]linvfs_pb_bmap+0/c4> Trace; f8c8e3fb <[xfs]linvfs_write_full_page+f/1c> Trace; f8c8e1fc <[xfs]linvfs_pb_bmap+0/c4> Trace; c012da0c Trace; c012dd20 Trace; c012dd7c Trace; c012e78e Trace; c012ea6d <__alloc_pages+105/164> Trace; c012e71e <_alloc_pages+16/18> Trace; c0126f6b Trace; c0127003 Trace; f8c89379 <[xfs]__pagebuf_do_delwri+c9/238> Trace; f8c89627 <[xfs]_pagebuf_file_write+13f/1f4> Trace; f8c89859 <[xfs]pagebuf_generic_file_write+17d/304> Trace; f8c8e1fc <[xfs]linvfs_pb_bmap+0/c4> Trace; f8c8f394 <[xfs]xfs_write+284/4b4> Trace; f8c8e1fc <[xfs]linvfs_pb_bmap+0/c4> Trace; f8c8ac90 <[xfs]linvfs_write+2bc/304> Trace; c013500b Trace; c0107043 Code; f8c35ed2 <[xfs]xfs_alloc_lookup+11a/340> 00000000 <_EIP>: Code; f8c35ed2 <[xfs]xfs_alloc_lookup+11a/340> <===== 0: 8b 50 30 mov 0x30(%eax),%edx <===== Code; f8c35ed5 <[xfs]xfs_alloc_lookup+11d/340> 3: 89 54 24 4c mov %edx,0x4c(%esp,1) Code; f8c35ed9 <[xfs]xfs_alloc_lookup+121/340> 7: 50 push %eax Code; f8c35eda <[xfs]xfs_alloc_lookup+122/340> 8: 56 push %esi Code; f8c35edb <[xfs]xfs_alloc_lookup+123/340> 9: 52 push %edx Code; f8c35edc <[xfs]xfs_alloc_lookup+124/340> a: 55 push %ebp Code; f8c35edd <[xfs]xfs_alloc_lookup+125/340> b: e8 5a 74 01 00 call 1746a <_EIP+0x1746a> f8c4d33c <[xfs]xfs_btree_check_sblock+0/dc> Code; f8c35ee2 <[xfs]xfs_alloc_lookup+12a/340> 10: 83 c4 1c add $0x1c,%esp Code; f8c35ee5 <[xfs]xfs_alloc_lookup+12d/340> 13: 85 00 test %eax,(%eax) Another Oops, also crashing within xfs_alloc_lookup: >>EIP; f8c35ed2 <[xfs]xfs_alloc_lookup+11a/340> <===== Trace; f8c37520 <[xfs]xfs_alloc_lookup_eq+20/28> Trace; f8c32845 <[xfs]xfs_alloc_fixup_trees+6d/20c> Trace; f8c338f1 <[xfs]xfs_alloc_ag_vextent_size+301/394> Trace; f8c32a7d <[xfs]xfs_alloc_ag_vextent+31/c8> Trace; f8c34b74 <[xfs]xfs_alloc_vextent+350/3d4> Trace; f8920bcb <[3w-xxxx].rodata.start+17ab/2b9f> Trace; f8c42241 <[xfs]xfs_bmap_alloc+17c1/1afc> Trace; f8c4bf77 <[xfs]xfs_bmbt_get_state+33/3c> Trace; f8c4bf77 <[xfs]xfs_bmbt_get_state+33/3c> Trace; f8c45b76 <[xfs]xfs_bmapi+6e2/1048> Trace; f8c6f376 <[xfs]xlog_grant_log_space+be/274> Trace; f8c8fdd5 <[xfs]xfs_strategy+605/854> ... From owner-linux-xfs@oss.sgi.com Fri Mar 1 16:12:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g220CMD12312 for linux-xfs-outgoing; Fri, 1 Mar 2002 16:12:22 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g220CH912289 for ; Fri, 1 Mar 2002 16:12:17 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA03579 for ; Fri, 1 Mar 2002 15:12:15 -0800 (PST) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA42565; Fri, 1 Mar 2002 17:10:58 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA91598; Fri, 1 Mar 2002 17:10:58 -0600 (CST) Subject: RE: oops umounting full LVM snapshots From: Eric Sandeen To: "FORRESTER,JUSTIN ""(HP-Loveland,ex1)" Cc: "'Steve Lord'" , "'Xfs Mailing \"List (E-mail)'\"" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Mar 2002 17:10:57 -0600 Message-Id: <1015024258.30251.115.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The issue here is changing the quota state on a read-only device - i.e. if quota's on in the superblock but mounted w/o quota, or vice versa. We can't do this on a read-only device because this will require a transaction. It's not the VFS flags we're worried about, it's the whether the device itself is read-only (as in the LVM snapshot case). So if we're trying to change quota state on a read-only device, we should fail. I have the basic code going to detect the situation, but I'm having trouble erroring out of the mount path cleanly, now. Each solution brings new problems. :) The quick fix for those of you experiencing this is to mount your snapshots with the same quota options as the original filesystem. -Eric On Thu, 2002-02-28 at 22:18, FORRESTER,JUSTIN (HP-Loveland,ex1) wrote: > > I was able to get rid of the problem with a simple hack to clear out the > quota flags in the [in-core] sb if we're mounted ro. The fs shutdown > problem went away, as did the subsequent oops. fyi. > > Justin -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Mar 1 16:47:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g220lsx12889 for linux-xfs-outgoing; Fri, 1 Mar 2002 16:47:54 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g220lk912861 for ; Fri, 1 Mar 2002 16:47:47 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA1127406 for ; Sat, 2 Mar 2002 00:50:42 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA67816; Fri, 1 Mar 2002 17:46:26 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA07179; Fri, 1 Mar 2002 17:46:25 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g21Nk4510736; Fri, 1 Mar 2002 17:46:04 -0600 Subject: Re: xfs_alloc_lookup kernel oopses with snapshot-xfs-2.4.17-2002-01-23_04:32_UTC? From: Steve Lord To: Stuart Levy Cc: linux-xfs@oss.sgi.com In-Reply-To: <200203012307.RAA20680@niri.ncsa.uiuc.edu> References: <200203012307.RAA20680@niri.ncsa.uiuc.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 01 Mar 2002 17:46:04 -0600 Message-Id: <1015026364.24566.249.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-03-01 at 17:07, Stuart Levy wrote: I think that translates into a Jan 23rd kernel .... > > The whole thing worked well for a few days' fairly heavy use. > But for the last couple of days -- the file system has become > more than about half full -- I've been getting kernel oopses > like those below, every 2-4 hours' use. > > After each crash I try mounting/unmounting the filesystem; > xfs_check says all's well, and > xfs_repair -l /dev/hda5 /dev/sda1 > also does. (I had to tweak xfs_repair.c to accept a value for -l -- > I see the same change was made in CVS recently too.) > > Files don't seem to be corrupted, except sometimes for > 0-filled ones that were being written at crash time, > i.e. all seems well. > > Does anything seem especially promising to try? > Should I build from the live CVS copy (if so, which tag?)? > Go back to 2.4.14 and use the 1.0.2 XFS release? > Try another compiler? > Hmm, difficult to detangle that one, but there is a chance you got a buffer with no memory in it down there. Could you possibly try the current cvs tree - or there will be new split patches for 2.4.18 in a day or so (probably Monday). I put some memory related fixes in - and a whole boat load of other stuff. If you are oopsing this frequently then a newer kernel cannot do any harm. You will need new commands if you care about acls, they are all available on the ftp site. Let us know if this helps and if not we will take it from there. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 1 17:44:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g221iu113700 for linux-xfs-outgoing; Fri, 1 Mar 2002 17:44:56 -0800 Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g221in913676 for ; Fri, 1 Mar 2002 17:44:49 -0800 Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8]) by ex1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g220it417375; Fri, 1 Mar 2002 18:44:55 -0600 (CST) Received: from niri.ncsa.uiuc.edu (niri.ncsa.uiuc.edu [141.142.64.68]) by mx1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g220imq18670; Fri, 1 Mar 2002 18:44:48 -0600 (CST) From: Stuart Levy Received: (from slevy@localhost) by niri.ncsa.uiuc.edu (8.8.5/8.8.5) id SAA21260; Fri, 1 Mar 2002 18:44:47 -0600 (CST) Date: Fri, 1 Mar 2002 18:44:47 -0600 (CST) Message-Id: <200203020044.SAA21260@niri.ncsa.uiuc.edu> To: Steve Lord Subject: Re: xfs_alloc_lookup kernel oopses with snapshot-xfs-2.4.17-2002-01-23_04:32_UTC? Cc: linux-xfs@oss.sgi.com References: <200203012307.RAA20680@niri.ncsa.uiuc.edu> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Hmm, difficult to detangle that one, but there is a chance you got a > buffer with no memory in it down there. Could you possibly try the > current cvs tree - or there will be new split patches for 2.4.18 > in a day or so (probably Monday). I put some memory related fixes > in - and a whole boat load of other stuff. If you are oopsing this > frequently then a newer kernel cannot do any harm. > > You will need new commands if you care about acls, they are all > available on the ftp site. > > Let us know if this helps and if not we will take it from there. > > Steve OK, thanks! It doesn't look good, though. After sending the last message, I tried building the raw CVS kernel (that calls itself 2.4.18-xfs), building it with the same .config settings as before (e.g. QUOTA and DMAPI off), and running the same sort of workload. It crashed within about an hour (!) with another similar-looking Oops: >>EIP; f8c3c1b2 <[xfs]xfs_alloc_lookup+11a/340> <===== Trace; f8c3d828 <[xfs]xfs_alloc_lookup_ge+20/28> Trace; f8c3965a <[xfs]xfs_alloc_ag_vextent_size+4a/394> Trace; f8c38a7d <[xfs]xfs_alloc_ag_vextent+31/e4> Trace; f8c3abc4 <[xfs]xfs_alloc_vextent+348/3cc> Trace; f8c34c47 <[xfs_support]mrlock+13/28> Trace; f8c487c1 <[xfs]xfs_bmap_alloc+17c1/1afc> Trace; f8c8c656 <[xfs]avl_lookup_next+6e/98> Trace; f8c52507 <[xfs]xfs_bmbt_get_state+33/3c> Trace; f8c52507 <[xfs]xfs_bmbt_get_state+33/3c> Trace; f8c4c0f6 <[xfs]xfs_bmapi+6e2/1048> Trace; f8c7c64b <[xfs]xfs_mod_incore_sb+2b/40> Trace; f8c759a6 <[xfs]xlog_grant_log_space+be/274> Trace; f8c961a5 <[xfs]xfs_strategy+605/854> Trace; f8ca2d60 <[xfs]xfs_vnodeops+0/80> Trace; c01989ac Trace; c0198a14 Trace; f8c94749 <[xfs]linvfs_pb_bmap+6d/d0> Trace; f8c946dc <[xfs]linvfs_pb_bmap+0/d0> Trace; f8c90706 <[xfs]pagebuf_delalloc_convert+3a/b4> Trace; f8c8f759 <[xfs]pagebuf_write_full_page+59/194> Trace; f8c946dc <[xfs]linvfs_pb_bmap+0/d0> Trace; f8c9490a <[xfs]linvfs_write_full_page+2e/48> Trace; f8c946dc <[xfs]linvfs_pb_bmap+0/d0> Maybe I will try the old egcs compiler, just in case... Stuart From owner-linux-xfs@oss.sgi.com Fri Mar 1 22:23:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g226N8c18827 for linux-xfs-outgoing; Fri, 1 Mar 2002 22:23:08 -0800 Received: from muaddib.localnet (wh6012.stw.uni-rostock.de [139.30.106.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g226N3918805 for ; Fri, 1 Mar 2002 22:23:03 -0800 Received: from ij by muaddib.localnet with local (Exim 3.34 #1 (Debian)) id 16h1tj-0004ot-00 for ; Sat, 02 Mar 2002 06:17:31 +0100 Date: Sat, 2 Mar 2002 06:17:31 +0100 To: linux-xfs@oss.sgi.com Subject: kernel panic booting from raid5 with external log Message-ID: <20020302051731.GC14671@muaddib.localnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i From: Ingo Juergensmann Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Well, changed my software raid5 / to external log now... copied system to another disk, rebooted from that disk, made new mkfs.xfs -f -l logdev=/dev/sde2 /dev/md0 && mount -t xfs -o logdev=/dev/sde2 /dev/md0 /mnt without any problems and tested its performance with bonnie++. Finally moved all the data back to fresh md0, edited /etc/fstab (i.e. /mnt/etc/fstab more exactly) and added logdev=/dev/sde2 to mount options. Great, I thought, and rebooted... et voila! Oooops... Mar 2 03:49:02 atreides kernel: XFS: filesystem is marked as having an external log; specify logdev on the Mar 2 03:49:02 atreides kernel: mount command line. Mar 2 03:49:02 atreides kernel: XFS: SB validate failed Kernel panic when mounting rootfs: root fs uses a external log and I should specify where the external logdev is within my mount command - but how?! I've put my nose into man lilo.conf, man mkfs.xfs and Boot-Howtos but found nothing that could help me. Did I missed a point when setting up logdev? 2.4.14-xfs with XFS 1.0.2 stable -- Ciao... // PowerAnimator & Maya Operator Ingo \X/ To boldly design where noone designed before! From owner-linux-xfs@oss.sgi.com Sat Mar 2 06:55:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g22EtO726687 for linux-xfs-outgoing; Sat, 2 Mar 2002 06:55:24 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g22EtD926661 for ; Sat, 2 Mar 2002 06:55:15 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16h9yg-0001QI-00; Sat, 02 Mar 2002 08:55:10 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g22Dt4Y18539; Sat, 2 Mar 2002 08:55:04 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: Ingo Juergensmann Cc: linux-xfs@oss.sgi.com Subject: Re: kernel panic booting from raid5 with external log From: "Martin K. Petersen" Organization: SGI XFS Team References: <20020302051731.GC14671@muaddib.localnet> Date: 02 Mar 2002 08:55:04 -0500 In-Reply-To: <20020302051731.GC14671@muaddib.localnet> Message-ID: Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Ingo" == Ingo Juergensmann writes: Ingo> Kernel panic when mounting rootfs: root fs uses a external log Ingo> and I should specify where the external logdev is within my Ingo> mount command - but how?! You need to add logdev=/dev/foo to the mount options. Ingo> I've put my nose into man lilo.conf, man mkfs.xfs and Ingo> Boot-Howtos but found nothing that could help me. man mount -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Sat Mar 2 07:49:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g22Fn6Q29158 for linux-xfs-outgoing; Sat, 2 Mar 2002 07:49:06 -0800 Received: from cellus.no (www.smsiden.com [193.91.191.71] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g22FmK929120 for ; Sat, 2 Mar 2002 07:48:20 -0800 Received: from christian ([193.69.127.56]) by cellus.no (8.9.3/8.9.3) with SMTP id PAA32365 for ; Sat, 2 Mar 2002 15:48:14 +0100 From: =?iso-8859-1?Q?Christian_R=F8snes?= To: Subject: Linux 2.4.18 freeze running dbench 1.3 Date: Sat, 2 Mar 2002 15:48:30 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C1C201.B39A1520" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C1C201.B39A1520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello Everytime I run dbench 1.3 on a linux kernel 2.4.18 from the XFS cvs checkout, I'm experiencing complete lockups on Compaq Proliant DL380 G2 servers. * Dual cpu 1266 Mhz, * SmartArray Raid controller * 2 x 36 GB HD in Raid 1 * 1256 MB RAM * eepro100 NIC (I've installed RedHat 7.2 with the SGI 1.0.2a installer.) Dbench works fine when running it with the 2.4.9-13SGI_XFS_1.0.2smp kernel from the SGI installer. The freeze happens evertime when I start dbench 1.3 with the 2.4.18 kernel: (I'm running it on my /usr partition which is xfs formatted and mounted) Eg: ./dbench 10 Starting 10 clients The system then becomes unresponsive, and reseting the machine is the only way to get it back on its feet. I've tested this on two different DL380 G2s, and it locks up on both. Is anyone else seeing this ? Is there any way I can debug this ? When the system freezes, there are no more entries in /var/log/messages. There are no Oopses. I've included my kernel config file (gzipped) and the message output found in /var/log/messages (also gzipped). Any help appreciated. Thank you. (I do not have physical access to the machines at the moment, but will on Monday) Christian -------------------------- CHECKOUT INFO ------------------------------- I've tried checkouts Thursday,Friday and today - all freeze up when running 2.4.18 and dbench 1.3: #!/bin/sh # export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs' cvs login # FULL CHECKOUT cvs -z3 checkout linux-2.4-xfs ------------------------------ XFS INFO -------------------------------- Here's the xfs info from the /usr partition in run dbench on. [root@dl01 xfs]# xfs_info /usr meta-data=/usr isize=256 agcount=14, agsize=262144 blks data = bsize=4096 blocks=3584280, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 ------------------------------ MOUNT INFO -------------------------------- I've tried to mount /usr with both default logbufs and logbsize values, and also the parameters listed for /usr below (logbufs=8,logbsize=32768). There are dbench lockups in both cases. [root@dl01 xfs]# mount /dev/cciss/c0d0p6 on / type xfs (rw) none on /proc type proc (rw) /dev/cciss/c0d0p1 on /boot type ext2 (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/cciss/c0d0p7 on /home type xfs (rw,logbufs=8,logbsize=32768) none on /dev/shm type tmpfs (rw) /dev/cciss/c0d0p2 on /usr type xfs (rw,logbufs=8,logbsize=32768) /dev/cciss/c0d0p3 on /var type xfs (rw,logbufs=8,logbsize=32768) ------=_NextPart_000_0000_01C1C201.B39A1520 Content-Type: application/x-gzip; name="messages.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="messages.gz" H4sICLLbgDwCA21lc3NhZ2VzAO1be2/iSLb//36KI82uFnTBlB88dzIaAkmH 203ChKSnV6NVZOxy8OLXuOwk9Kffc8oYCElsk8xc7ZVupG6w8fnVqVPnXeVz vgCtC6o20LUBM8D2mApiLbzw3gZVMRR1ADEXiRknyn+dv/3wYEskn00jEKll cW5z+3WyFY8D7g1gtRupAfgdRJjGFocTaEVxaLVWvrjPMLmtFENNAhFxK3GD e2gtwjBpzdci4b7im1Ex66tjGI/COEHEQf7l2AnP1/4i9CAxFx6HpSnADaww jpFxeOCxcMMAgtRf8FiBYqCRGQRhAo4b2EB8OK7HSyT0JTSRP2jjzIkJAU4c +qCCH9ppObEbpE9bHjVasV7zyRFQi1HYP9OzdajdW9beM/0OaAz/uroKtWsc +sJMNkBdRZUPNPu9eh1+UGE+ncGv+EjOhDpgnQHrwujshkC0Yu5OJ1fzJmrM g0szjJZr4VqmB9fDKQlnUEycUfOexgbADv6guX+r7xh4q5YKWr76u1AziGeo phyohobG4wduvw/XecGtyv4AXPVQCobjOBb7kBS2EDvUdi7u2nA0m4BtJuY7 gB1uHbKLt9QPi8Hh/CUur4YbR5aCPiKxf+uy9j8H8HVjHUzR0QTm5D3QZb1O GzjooazVYAdyrLt5dTbOoZTUrbZXlZLe06encDH5dDE9m4L5YLoeKUOJD3HC FL0VWfp01sxcIDoEYslwbFZMu/QbEJn3PHuceM1ZheTRtcqGfkbe/hi5dgT5 Wk4z870UmvCODB9VF/DZwPrRfF9hOAltpIYkTEyPkASuntbtdDtVWRYyjuLi BUl1vr+HAa+x+gAMhlFAjqtUoFCRQtPaWo9Vp9GQpt9D2RSSxGZghz6lCW7i mp77naaW3dxEXLjnAY/NJIyrT3MSJNyDaeol7gzzFS5EGMMc8xDXwQCUkKE/ YHZTYqT499VFs8aI9asbc7BCP0Liheu5yZrCc+kyoxFOxpgUXE1nw18QDpmx U8wp6Obs+urLZHh5I8cZziYjNDr0Bk/nZ2fS6Iuhd9P6QYcZDxI39WuJX6cf MrQ83qudykjsY0iT1lVG8ENv60/VrvQlOKuRnNWhxNpvQWivQqjlENv5oEVp rz8a8MTBX6fo92RiGiZL1DNK1TKjEgWadjDaZ/lJquGj0oLnBmiiKDjKvk5a Nn9oWZYrRMtiNos6JZPft4HR7PYHVvz8mCeYoKLLUbV2T9FZB6YX3yHK518i p1EYiJAcihV6mN3D10/D/4Yee9LaJXTI4QLtkZi0uWeusUAII0VRQGurTGEa nIb34XQymxfjTLkfxusB/trr6BpbtVRdZV1mrHZxC2pqV2uvNiTIqM0boOn9 fme19bcN6Hf6K5ma4G8GkrsoxgbofQRlK1i690uf+/ViZlb2Yi9BVmGxhrkV JpgWp3Fgm14DF9pNlnD1yAOhoOyidYzACcw/TRow9DCnpUsB1xu2ylYuSOJ1 0zKtpSw3lpvKg267FAq0jqYaBtTC2Obo9/o4Ndbvqm0NOUu4qJcpEkqqAF1K Wtui9xqgMqPX7nYK0c00Ccls6NMn0ynNeg5XnIgK2KL419ty1WnkUqgy5dPU cXhcfc7dBrQ1Q+v1CtGFWNqDbTaYXZZ4H4x1BVxsxnznuqJPwPivwgTkCDip zucG3Rjv3agCoeXPt1Xtc5kuUSj18XF0bYBEFhpojFfke1KMiiKNqOh+2Qio ABRzIiXR8oAEZQPan/R8JWBn9DjROaZI4Hx2C8J8wLQVXTA1RsKYk0OyMQ+p CpQGvilWyMF8Mh1LRP5k8UjmCpspVoQc0dQI8m9LL/kbuiORxBj0EYgArj6X xa+r+eQb+rrACWOMKRYHVAwpI3RKt5eT88m3YgA/iVG1KL/BwkGjMgINq44O ylqasQ2fwtBaYkVxT58/m0ngKJZw41Ax03oVYDuPOnQJyTrim7UtMqEyF5E9 9Z+j/bF1aPaVM4KP6XnnBcNsA1m7rm/TM/w6mUzoVzQA3/XWMolEjE6HUgDM YaKIRmNqMXyELpNAEtfnwsO6BSxy8g6K0uhoimZAKrglSpjM53T2lEwwn82n Vkx0Nr+GB9NLOSw4ajrPUIjpB1QvSvbz6rcqjukkmMW9E+YU8zWi2mZPoLYY cDeSrbJi2hd5W4nUN47mubjU/1PiencS2Pm4TXeOtenOBwxULTdQ9U800Btq D0DogLbTTAEmRpMHk3xwrc00FHd7K+56Cb9nl8PTL5PLTzC5aspCa3L9iygm mfNESqaHoQywUpJ93DvXvosoBw+Su5et/AME1AuMPcE9oeTjbpvBGRdjSEIc gTQoXCnVGNL+dIa0agwpys1kenY92BjRCXvSVcD1VU80+tBOWBn9dNakliAs 0nvMx7W2IV1yDLSXgKlAkEVc5GjDben0sLygySGF4Algjp7h1XC5WR2FFofp /VIKD0frD+U8S0HxmVrWLMRZAeLgnccwXpUFiDyBoeEmWYGvvP5XjLP/qzow 9DxWK1i2U9W3V9KTtexV9Pvh+w0YfNBKcJCAJ4obPRj43x162kfKmU6AVaWi xE2xuWOmXqLECOF65GdPQC1ByCZJU4l/Lxhwf7ZYwjvufRpnHUxZI0dmbPqY ocWiwpSxaEaPub+9I3/We9vtnQpM5NZoUU8coIYfpkfaVi+BLuNuf5C86bkR 7KZfexREzmcOQY1T5NZMWFOkgdqpVxDYPt4wc8IyQXxEXiLKFinLF0cC5Ywt Q5EEuHjyiSMxtjUH9Z329P4okGvu5+ZzCIPmHnPTbj7GWPfJ1ueRDJ67gVzA bFMTFyHigc0DS1bFpUiOoO0WuX88QEXjZtAAo91qUzswY7OBFH1mtDSm93sG LEgZxTGC2+v+vclOu8jjSL1/q4lYAWhbiR4Cwe8pZgFvw2m0HyvhnjChSezf ej3jnygmrPbueQC2KzcE7QauoB8+HOxqlfAiNVtEplW03u1NBZTToveROpQG Hn+Q21JvEKxS+3s6gNvIzuyoxROr5YjEXLw9VfUZ6Z8hkh3xa3Fnx4IbIZ5L 5n7upWJJEzA9DyuoOMYkBKePCyg7ElhDxeR2kBUbcpqjGLfNNXnUcsZfsDZC Y4n/M1kbRpEnk5T8Fup8zB+J0YzBo/jg1jKsvLB/ECWK7Z7kV3Hqx2QYBVQV M4w3eA6woFgdzXJhcrJ7HMehfHAX0zY3qqQlb63OE7fetzpeiPl95ZluWT8l c5EdwQg9GrLsoPdDsCLGjUoYPFmyY6cvlhzt4V3zj8U6sI72dUqFv1e7oAc4 t2IXy2RFlRUgUhpxGiWihN7a6zDs0b+sEV7jXxbeWUIqIpQ1uCLbJNOMbo92 ySqBUEKGFZl4gaRrimF0uhWArAiDFGtkCHIXQiPKBshu2wAMQzV6/WIM6gH+ eMMGGa3RuFEHvZ7W77DGeKC2G/NBBtIYbZ7o/lSBJ/XDPKkHPBFZVyOejOo8 PVPYap7pcDZ5AnczHwFpPJa2gfs92+Q3rTgUgrjFeUamEC93KQ7gfjXdbEs4 gEf8ekc5zZ1r014kFRzo+p60epW5cA+vjp4N7STuNXqWtKlBxgZbPqqMXSke H4w8G03kf/JoEtI8uPlmKJPbV+tsE95hrG80wDMz0zhR2Z/KUOZFrE2dmy0q bTnAYd+s99ps4nBB5DQr2vrAQMsrkI1dYYUPPKYTixxdDnkApr6XsFuFEKVt 0VmiAZYz8viobLIs1nIxjgNQPwqgfRRA/yAAeugjAbKzq5dnN4aC5WAYb25o L074HNCdmugQMEajUs0fzUBwE24DV54DSNYwCv0opcxqHmKZijdwAF3B+rIY 9NluwPUNJQVYSmH4QG/Lk2JaM/KzQ7M7CSjFFNtNqhWVanYJvEfxmDqJupad ypJFAF4slmJ3go0kSK26zdEJWCAf6JGKsb+ez6UFrLJqdXuawqbru45CS+Pm ouEljM4/TeDb+Rwe6czFcPQFy3sJ20C5YLmySLd9+mKcKFkPQGNGj9b1qd+j G2LrTkq5wDoWsxc7JpXYTqitsLaVbaw2WbfJevWMzYvb02YHpsPLf9zNrq5v 5jC9/XIzoa8wvxhen91Nrn+B+dn1ZPjljjxSpQkkyXqOPkG6XqY7Pai5MgE3 6pSImKB22m02LMa45jiJG3LBI5nHjDfzUdG1l/jDRXbOVdV6mByEiaANQ1wJ nvIGLMzEWp7oWsngw+l4Mv+cC3FPA2hrR54Ex8CwErTHQWcSP4PAH0FlWt7E wcviIXBpaas8O+7XnHlmIi/PmpPxWT7u9SaeDaCj6CW+3KXm1lCI1Ce70nW5 YZN1YsijZ2kg2chsciVbYeLvQG4/RsJMFVxSUXHy9FSqX0j2KzXQ4Wp+aqDv QI5RO5M49DzkGrWNNEXGEYZ6/wDd/rGQ1tKNaAtgG9HZsQjkilTG/vpXCDAA P+Ttv0c3y1UWmJzEvwtMCdBXFmPTH8oGi6DTaXM8HWZ6rVmMNeUH5qDS+Yms esScbWmbg8gNG/hlQV8q4asv8HsZvvMKvpXj2+X4xE1+mHM0bl5fTWF+2VQ1 45cGDG+wSsG7rfHX7BepeaWatrFt1SERqE63wZ50p0MrT4auGhUYykbWjG85 T3Jkaoj2Vqcwom3RBtRu6yiQaoa0D7NvOrqillj7uRdG0TqjrIn6ABybyYoJ 66VpCel4BCxzapcyz0OnNee+i+ZAR2bJ3Ea9rs46xTAUtM3fYTSZz3NHV3uQ 78W06+XKAxufcwJdVdW0dodlN+7IC53Q3nIVjCU3bYTQ2m2sqeSOIF7pGlZc a8wEbE6Xva5aMpOSnCnfbcgKoEEJX7tDqBgUVYgw/OsQGfAjRG2IOhB14adi CM7R1tENKNYAIwfr/6uZQL+l9Vv9PoxptWw4RUZQ3sskiQat1uPjoyJwxrZi hX5r0xppbWGWie9VHhH+stNCVdE78Bd5LKOlqi0Vy/DQdh2Xy2RxGNgxX8NX BebmQ2gtsTSEH4X5+DP+U8Qj8aKI+59k3iOP/ZakNVnPhg5yuz1c0G5LfvTQ IbaQNTgjCJxbI0udB8P24JwNTukVqQZtrWO2UKYxpyH1/6g29RfeGisN1tf1 JmYXDZjlW9KbLWAqCTd73BhZ/8dol2HPYtc3sXTb9aAoHGRTacPs4h/w8oDD C5BP8vy9h6rsOU3ayn2rlH5BuUmgRLpo5ttRR2PQ0YqYnEHM711BHcR3gJA7 k3aCQf0lOdQwuTIco632FnWlVB/Ud+lDJ9OH7v/rw/++PvRf6UlkF9uXDDRF V/T8ldYsi/PcxWNsRhDKQ6BCvv7h0tEgN3hjgD9E4V5jdp7zhS4UExd0gnuH 5Klqw9K5mKVULMiP5kJDrIA/5iF+mS5KqJeWS+S389O8QsYVuKD+6GiXrk62 WmXvSoxiYN+mf/nzTOkzLBOnw2930/Hd+Ozr/ARjcAPwYn56R3UE3uiWIw7T JMyOqcoafDgZgxnH5loo5bR0uj1Og1caza88TF3inGB8dXlWQhJZ7t0yTCKP TvlQZn+BqfUMr+TFiI71barMAb2IWKQYWwUuO4N/wAI1SfKGyc1o1prMMKBm TZOsf1JMjo/P4jAJrdDD7Hkyms4acDvG/xALHdyn6ayMnt6OSbMDI4en5LEE VDs67d6n1CqRe/q9z/JgfDEqDj6Aiy3QfoUPNXpPfuG5YokX+QsF9HY2Vs56 p14MnMkJJ+1TbWlR05O4l6rKMGvysDKbTabN+bSK1KkHAXbom5iTZN0gyoxZ i9683HWtsmUo0SRqjmwPa+wdFZB5HqupzGiUzU02bOTpBRSMPO9Ro/fGd2B1 eeQjDLx1CTPnMefZEfqUnNvmJJK/eb9HvpPj4CMlmjm05QGR+SO9h0lvRTB6 zYe6Wk15AAFqUeyGMXXmmmr9w+LpfhxC+ziEXgLhRncU65PYtFZQ66l9bWcc UoHBN58OMFS22bvlgY26hij5tzJnkVPeUxsS/yt9frN3asVYpA2yj1IabePG 6FUij4JRsNlvoRO4WHexw83lZxSkohVHMAPa/kFXuvlSmY68a4WXup/x5d4H oTxnIY+VRSbmD9zjPp22aKUibn1T1etOC1MK+taih7AcW8eu57kW1NKATE2+ tw9/8CDZDmzBCFp/9wpGLTL9uxTdVP03lXXk/jMXMj8KIx5s2l7yzIh0GFhv 1VLXPmHPNFAftLuvQ2JJfQTkvwFV8HfABkUAAA== ------=_NextPart_000_0000_01C1C201.B39A1520 Content-Type: application/x-gzip; name="kernel_config_file.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kernel_config_file.gz" H4sICEXbgDwCA2tlcm5lbF9jb25maWdfZmlsZQCUXF1z46jSvj+/wnX24p2p 2qn1Vxz7VOUCAbIZC0EEsp25UXknnpnUZuIcx9mz+fdvI/kDSYAzF7sZdT9A A03T3YB/+9dvHfS63/5c7x++rh8f3zrfN0+b3Xq/ue/8+db5uf5r0/m5eXr9 un369vD9P5377dP/7Tub+4f9v377FxZpzKbFajy6eTt+MIXg47fO4VNFueo8 vHSetvvOy2Z/ROWM9EwhqASg23toZL1/3T3s3zqPm783j53t8/5h+/RyboSu JM0Yp6lGybFgsl3fr/98hMLb+1f48/L6/LzdWZJxQfKEqrN0QFjQTDGRWsQ5 UI9Vyt326+blZbvr7N+eN531033n28aItnmpZD3UMxiP7G6dGUMf4yrA0Ap7 eZyv3LxRvcIjWcIQsZwzxux5OJKH7rrmHtnm1246TVDq5uAsV4K6eUuW4hmT eBRk94PcAfG0e5exFXTaMSSgn8VSFkuRzVUh5ueJNwyWLhI5rdMwlys8axBX iJA6JVJLJOskKSQiVRsn0bKloryY0hT0FxdKsjQReO6QswKalqGpAiVTkTE9 4/UWkl6BEZ7RQs1YrG+ubB6oUR08FQIqkqxBllNaJ+SKFlJmooCK8Vzl3JZf C2gqQs5hZ2NXRzjDmcCC0JufditcZXUClmAHgHSqLhUzNp1xyh2VHjjDqS3b gTgaTv0lassA6VlBeZ4gDTbAJbrOsvPYKC5rpfNEs9scEVdjaEELQnFhJvdo TaalLX00uNfns1lKqW4ooXDMElSEkgZd4tqqhk+Y44gJ5Zydik1YRrF2iFyx UXpXq78w1dUpVQ11Woq4bVhpw+5zjFyDJLRM8unJ2GKOGfoDr3f30euLZb6t HhiEXdOhIOvMtvvnx9fvHdU0+odGDmPVJhZYcIlubb1rc4t0kSGXGqo7tQAT dq45UqSApYOpUgXC9jABFOvE2mewyGhBk9geqIqIRO6aoYilMdcl97xyDsSq njqNM7AAJ6CsqT7C0mUcUQMlecGmqZEJjEJWqFzBzuG2uQZLREFTFCXUi4BF XjASABCmZILuigj2lLlbwiLTGDyLYsp1U1iUJGIJVlwrbwMZhXUEezzYOLGE Pok4bmkU3/zc7t46evP1x9P2cfv9rUM2fz+AK9D5wDX5WNv7NWkr5BqW+SP4 LUYV236IRJkUmbZV7kAClXMv3QMbcTZFQQSP8SBchUYZCyKmKiyEytNIyiBE 6BnNgohefzxsj5tZwcbJko/rt07lZL6C9wm+nzV6qbRHDiwNUFpVRY/br391 7qtZOxeOkjmY5UURE1tzjtQV8cnMiFtjTUksbwvism9HJmZgDAhytUgQnoy6 nrIGkAghrcV+oKYRaRPBQlkm4EwsFPtCb4bdyajJZCnT2cnZ5a+P+4dP1ZAd lbbzIUOMlHOSLPhHy5cm7bZsGidFwlKKrD0eSKaybovSa1GuapRyo5WwV7f7 DEIBsRQ/3ez/t9399fD0vR0uSITn9i5bfRec2x4b7MMgcllvjRizRNPMnr0T EbBR7nI2TmWOEU7KVlZUVNvymax6iJGqUxFZoBRTGBKw+HZtxxIyoYU25lbV eCW8iJccZXMHI0XaQT0PcpunhasBCJ0ioaiDk6Bsakl2XquyaKzV84ACk1ma XlGmGXWQiigTiLSGi5eN10iSccWLRc9F7Nf2jky63DgzUQXFqb2Lp+ATiDkr e1YqXqfD5H+M+n17eNxvdhDAOu0WtJzGUDZNdQbqd+5XxYi1bJJYhpuk25zm tIWTh6Fu0MG9xTNYhpxpN4sj7GNkcw+nVJNq93KwjaY4GQgcbSU9EtJ0ai/u WoXgMrkZWHLlaUxppKmblac4oSh1M8USorLWxFRLuUHVRsU1OBOfjS/sZnKW ZaJV0iy/Ngm0mxJKaopq1YQUzHyGCPXKcfDKHTWrlMsiQophF9ehZIbsUEeO 0mniE8Ax8SfZ27p0YCViWtvKbV4OTNeKrDXq1IHSZTemAs8QS9X7B/tUMF4i wt9XbjE67j/GDPw9epchGDmX8si3lkeBxTzyrubRhUU7Cuj9yG8KRu41MWpN a7OypvKM2jpyDoNmWktPmKG5k76AeKEYd/u9W3dqQq481aFk7uRA9A7W3+31 gT84dTuEq/6Vk54gGbkZidvbNjsPYbDHukWg8Ncj3RIGovIYvBXHsHeWEC9i tixiCKWAAsCk5V7fbpVxCv/Y7jrf1g+7zn9fN68bcL3syMhUo/CMtuMjvXnc PP/YPr1Z4frZ255Bz9x+uOEUbPU5zPWlCWCq/wA//g8e8z+yJGnHZcA87unw z99NgdLzhb8QLF+IKKrCLQd/RopQ7FBBAv4/FIaI2HbjKkK1pss41tXsEbWA aF1kweaP0Dj/zLTK34VlEX8XjqOVfmfztzlKdf6+ahVFU6Tpu7BLEoSBzec0 YygJojRbiEutYRWeRkw8EwXadbErsBalvLuEUlixgBCYk9Gw65Ki4hQ0nZUB R7idVsDdDDm/9Lrdbjs8BAFrSbjqu1AzBC49y26dJQhH9dTdkQc7tDOiFnEc CZQ5vflTdQXKtfC1V4tYzkWWzJ3zOEBSuixIBgYb9milWTpVwVFEFI/6K8+e VPEKDVFjOg1Xk7De1cqd8VkSHOSf6uDkeugTpeIVAjai7JIhK7VoFYbcjft4 NAkLhNXV1aAbtplSDzxNVaxyhmFeLtYyGgVUWTI7bDdfh0lxaV6qxtfD3lWw RSE1G/V7QYwkuN/16caRWUR5pnQYEosMh2dMLZbzsJ4qBpPRC8+XSvCkS0ej sAnNeH8SntQFQ6AdK0/PQfsKc+SnqFb+xX1Y2M3VyRZu76tcuSI1JwhB411u tMo16yafalJkwRVWYczMvAsHetnyXkrb3nJZDLWdFVNWdlCRgq50hgxD3Qy7 RzqeZRW2loc+UoVSOjAi5dFdWw8yh79xFCOridGSohYIml5VqbUqSnKraImq 3KAkd53elQD4t9LgWlgZrJIOQcq0Wsjn4X3c/u9TdeHgfvfw92ZXO+Q/9nKw LEBFV4V31svqr2ELBC/bs0RLCMKNbarBnqHeVX91ATDshwHXw24AgHCzFzU2 w9fQ07MuHQjG0KtClunPBcP0pn81aEIyqkwAQ81RDlc3vSsYjyYmyllCIJbM +BJcgNo9Eav5QiSBUSISAva+CPTRJFHVXUCFWNoH4QI18KsBnlwPA0pIpyg0 kFGuQN3K/Eu9oIBoHuIspGZSsDSgK1jexlgHOkH4atCb9EIjpfGgPw70k5p4 J8gtfBvqGSFZYC7iXOfg6xHBEUv9sCnRswD3cHUixdnVINQf2CpCk850SFTg o15IK6QMDAXj3M8sBcfD7ghdwlz/848fou6MXo5hgfQv1TOub6nOWqwdo1YQ 1nCMwMgWGk0tw90AQaBXAQZ9D0Ldpfim3/XJZw7NY+Y5F25AGeiPlJS8Bytv wVIR9R4oDIW57HBIAwZmHqneKMDGLGxPDKDf77IAQrH+MAS4Lc2JSeNcxDAl L9eDL0J6QdMRCsgrAOPXve4lZR6GxpXgwaQbmBYNIvq5eW9YDIZxAJCAd6J8 2YqzR9JyzOLXl4ftU4eDz1Y/O7WdhzhXjRtGDVYRCaFDfKZoqmgIgXUSYjfu 6FVpLkpppzeYDDsf4ofdZgn/fTwf/dqXLGt3HkyxslSrPtiJW4NwLNQXVvq3 L8qwvkaIystSNVJSO6oBQt3hLavJBG6cAXtlSKmuXJbT4R3K8NNmb6X1rCPB Zv73GDPknN9ZTrdIiXEkTwR6m0PY/cXOj0PQaPHN5QiN5FFouv+x2RkhPsAK 2e46sO3wPx/2H2tiV6Wqc+OzVuZpYhI27jgYbOQdp57MlrnEwRH28W6pjzOl 3Js0rrz/YgAW1JME9wlrlVYcX4Jk4DonnnR+79pje022CXkyBr6dvjxyVshz Yt26fgfEgXszRgRJTbE5mczA4fVcfwIHzSMIkuDyeAwEVuPJP+5iOk88WStC hyt3qoJMM+WJlSe9bt8xFpTCGux1a5nFJKUDT7gfg06m7rgmRVpRzjxz0Z8X jUDdYg76nv2FKi9rDEYMSy9LCxHieX3dIx9WPS30kinfUcwROO71J15AmVnM DhGVe1UyNfHoDZUMe93YPCXeBal9V7oXDBXZjHmOaE7cgnPP6CxZakxmMR76 15wU5n5Oa3uxLSV06mglrQVEU+a2HiTpu4/5+F3GWu8SzsKo8WDc73oMLBjQ mVsf76i5iBj7opz5ZJx4eDEh7ipnTErPxb3GIj+SpXWEDx9VrsRccbJSmkBu 3lUyNFS667XShlJofVenmqOJ2mULQ4wUMU50jShoLfptiFzOonE/HjcvLx2j ex+etk+ffqx/7tb3D9uPzXPFDJG6elXnitu/Nk+dzFwBc2zoOnAe6laaDPvs jYLdtb6oqx6snzoPT/vN7tu60fjS4X2hn+v95nXXyUwXXV4jaJi7o2xHUOfD w9O33Xq3uf/oKssy0j4CZYqkAP7z5e1lv/lZgxtOEy4e7zuYfMpgOz8kxMy0 7Mtk2e8llBFamxtMilS4jqKq5p+eX/edr9udyz1MpX2tufws5vQuMtfxGmQu ckUDdPASM0rTYnUDG9YwjLm7uR6N65DP4s5ROV1UxKq7P9a79VdzyaN1ILyw bqUtdJl/FIl1LU2Vx43Nbx/OZE3B6bEvnRwYHKV3hbnUoVos+0jtrLIVj1Dw Q8y1n1tXSuBQ9em+yPnGfB6NHLWlVXaVuA/czK3HybiQ+k7Vr0JWROhznuqb fnd4mgBwc9LazZJEtkdGSmsmWB871b+P27e6YaJqGd1cldrgevhh6FaL6kg4 b819DBFt0arAcgd7wJeoff3h8xaW38PXv2oGolKyKeLUDLz7BKSEpOrqahzg J2w6096DwwoDZs20FEBgNRz1VgEA5XmvO+8FEEZFRJh/oasoRY1bYE2A5/3X gevZSQ89FFGGAvxp7PEYDuzMdx5csks1RjjUO809x0GH4QErCr4S8fiOh2bK M74iV9FlUN8Tm1SgJcpgukJtcTQFr8bjFh5kluCCiSy6BIlQkoQw5vw82G8S TUJzA7qNRUhQnWeRmGYodqv4LcPdftG8mHHY4vdff9xvv3fMO6XGFq/xjHj1 VdOkyFLXncbycdHZ5GUa24aGaM8FtWwwGQ090SK4hL4gXIn0Trb35ni/ft78 3gEPu/Ptcfv8/NYxhGMmpdr+axmt5ugc255afh98VD0/m9KSNO516xSIG+oE ZD8mMAQIchqIhDUQ5ZPOM41ktbdM8Nk8SrI4EGTVShaaxFZO3FCyXn/coCBC RVqnlX2rUfgU2a6vIUFnXJvOEi3ocV8rX2P83Nw/rF2+7AKMgzDHb+15fDBP n0v/znJKbnOhrRGOFXgOiq0gYrKnJtcCOLF1+bQiDSvaWfMoA+NdQt2aeeSX D0jDEJO+Ax2JhSdv4m/lwCuypZsd+4vO/KyoxTo9OdeD2th8jmqvVeHT/xzE 3Ki2inJFRH2g8zZpcSp1Duf9cn+Ow7y+u1cYTI/dqOYyttZQg8uUmIxG3cKG fBYJq6clvwDM2Rhn4Ps1urRY+eVO9QWeZ+pn0jeJpbbFtYscsIj8rVRMbvzU AN837cCVWjXau01XQ3+DB66nYxCJBdSz32jJPE71tZOTOMTytJ/7Ba9YxTJj 2rUtVLNsS2comfZAj/aqhiYcOTauY86/NHyqafiwIKi2qkrHjNMvX0SNnB7l s74Xg9rDfSG0Ibs28Ni+cWO+qrLnRFtmvxE2xxyk8VkshvZD86ixSgwlTdTx MNa9IrD0LhZsVsTh1ZtiU294UAGZwDop5QrjzCXyIMCMYhoSSYBdCgIUB1eR iBAExiXALW8duQGVnXIvpy8JM3NgdqZDfuv4snf/YJ5zdPTb86b2wjDT5kZB enq1V39tLbL0jHFKI1R8AVG+/r2EMc97L2A4wm5EbXc6IeqP282l6gRFtktX mXWVR44iELmDQKr6oQmLfbYbUNZc/zlX7D46Ijwos5oyT/2JzkC6YNk8dfX2 sOYsm5Ccjg3T9R4c4k6yfvr+uv6+af/sgLVYb/798LIdj68mn3r/ttnmJzEk xFTFcHBtWQ+bc+3nXF95OOOrrpfT93L8tfkkGI+87Yx6Xo5XgtHAyxl6OV6p RyMvZ+LhTAa+MhPviE4Gvv5Mhr52xteN/oAVMtpRjD0Fen1v+8DquSvzkPtu 8sBN9gh65SaP3ORrN3nikdsjSs8jS68hzFywcZE5aHmdlut4fErmbp9eto8b 69Ln0TcFc9vKPlahl6JJ7UdQODlDD9XGu/XPzac/X7992+za+e44suJNc6PA aukcZEdFxhbuLBXwcDKlqY8ped9b7i6imfeSEgAWVHkbhUHxXNMB5mzqOixv DJldgCPwIVy304CHysMmGw2UYrryNW64zp+2McPYCNUreBXR23U0InObNSCx t+mFEESIno+tzdsJTwhhSrNM554bDXGELafC2TkDwHE0tnt3oPVGDmJ/6CCW lqzRaixSvWREz8aFSJO7gHwG6XKjDL0Y/zO2Ug8V5fx7b2r7+nRv5zYURFvt pLlJcbYWERBre72K2rFYg2tu//hCGABEKCVll72IBFzeQjNO3T/SYyD5zDwx SnRTNjHzHCcaJsqJJ11eypXkVEMEMvM0aW6uwY5gz6FFvjAqJxR4jzGKLuLi jFJfetHGMUV8F1pqzUp8ua6ZHENdm4s4RUjWnVyEfc65VDPPjZpyOgIyHU6p vPyZ52XAgddI29XY88hf1H/WZLhLFJoSgn0visqaCR6HJgqjNA30t/yFN03n /k5L+H/zSLg+pHSKVO5fl3O0pIFFiZHGfibB1PuDROV6VZHvMXXFVtf1OyAn i6Q2u4f1o/EgwHPY1/b5+gj635ie2cer7ZdgECPNPbdHLNRyxjSdUaQvAQmb mscoGLZn73mcBacc5uoSKNbEXPoVl3AL8OOySyAm0e1FzMVaKJm+q39zeqck goiQoHdC31tjrpDnirIPvPo1NPo1ePQL8N7kV8C/JHhvsvwF9PAymmNd5L7T TrvWJGCQDhiZ9AfdwSVU6VB//v85OnsTUhjhGYS34oSo8vf188RXIAV5+psa GGA586w0tSQ/vyQDWykEakBEYWjxBq2ny1HISEzOhpzeAB+5Bm2+8watOPZB HSwHiWM5lhNNRbAPjmYERNrTH9TkxTb05AjabBAcGYy6dgVqKO7DUiEKgBjj UCpvFycUDvwU4FxkQX83pOMTvR19fIIjfVFGq92CHH1BJwZiVPwA95I/3jNZ AAA= ------=_NextPart_000_0000_01C1C201.B39A1520-- From owner-linux-xfs@oss.sgi.com Sat Mar 2 08:48:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g22Gm3E30485 for linux-xfs-outgoing; Sat, 2 Mar 2002 08:48:03 -0800 Received: from muaddib.localnet (wh6012.stw.uni-rostock.de [139.30.106.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g22Glu930458; Sat, 2 Mar 2002 08:47:56 -0800 Received: from ij by muaddib.localnet with local (Exim 3.34 #1 (Debian)) id 16hBf6-0006Ro-00; Sat, 02 Mar 2002 16:43:04 +0100 Date: Sat, 2 Mar 2002 16:43:04 +0100 To: "Martin K. Petersen" Cc: linux-xfs@oss.sgi.com Subject: Re: kernel panic booting from raid5 with external log Message-ID: <20020302154304.GD14671@muaddib.localnet> References: <20020302051731.GC14671@muaddib.localnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i From: Ingo Juergensmann Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Mar 02, 2002 at 08:55:04AM -0500, Martin K. Petersen wrote: > Ingo> Kernel panic when mounting rootfs: root fs uses a external log > Ingo> and I should specify where the external logdev is within my > Ingo> mount command - but how?! > You need to add logdev=/dev/foo to the mount options. Ok, but tell me where or how? I mean there is already a logdev=/dev/sde2 option in /etc/fstab, but how can kernel read /etc/fstab when it is unable to mount rootfs on /? Booting from auxiallary disk and mounting the raid by hand with appropriate mount option actually works, but that was not my point. > Ingo> I've put my nose into man lilo.conf, man mkfs.xfs and > Ingo> Boot-Howtos but found nothing that could help me. > man mount man mount was too obvious for me, so I omitted this in my list of read man pages. Sorry, my fault. man rdev shows that option ro is currently the only option that can be passed to kernel for boot time. So, it seems as if one can not use a raid5 on / with a external logdev. Is this right? -- Ciao... // PowerAnimator & Maya Operator Ingo \X/ To boldly design where noone designed before! From owner-linux-xfs@oss.sgi.com Sat Mar 2 09:03:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g22H3Ff30965 for linux-xfs-outgoing; Sat, 2 Mar 2002 09:03:15 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g22H3B930943 for ; Sat, 2 Mar 2002 09:03:11 -0800 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16hBuj-0003EC-00; Sat, 02 Mar 2002 16:59:13 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Ingo Juergensmann" Date: Sat, 02 Mar 2002 16:59:13 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2472) For Windows 2000 (5.0.2195;2) In-Reply-To: <20020302154304.GD14671@muaddib.localnet> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: kernel panic booting from raid5 with external log Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 2 Mar 2002 16:43:04 +0100, Ingo Juergensmann wrote: [...] >So, it seems as if one can not use a raid5 on / with a external logdev. Is >this right? You should be able to use an initrd for this purpose. See initrd(4). -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sat Mar 2 15:43:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g22NhX105278 for linux-xfs-outgoing; Sat, 2 Mar 2002 15:43:33 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g22NhQ905256 for ; Sat, 2 Mar 2002 15:43:26 -0800 Received: (qmail 23225 invoked from network); 2 Mar 2002 22:43:21 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Mar 2002 22:43:21 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 325B93000BA; Sun, 3 Mar 2002 08:43:16 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id B1D78BA; Sun, 3 Mar 2002 09:43:16 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: =?iso-8859-1?Q?Christian_R=F8snes?= Cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.18 freeze running dbench 1.3 In-reply-to: Your message of "Sat, 02 Mar 2002 15:48:30 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Mar 2002 09:43:11 +1100 Message-ID: <11886.1015108991@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 2 Mar 2002 15:48:30 +0100, =?iso-8859-1?Q?Christian_R=F8snes?= wrote: >Everytime I run dbench 1.3 on a linux kernel 2.4.18 from the XFS cvs >checkout, >I'm experiencing complete lockups on Compaq Proliant DL380 G2 servers. > * Dual cpu 1266 Mhz, > * SmartArray Raid controller > * 2 x 36 GB HD in Raid 1 > * 1256 MB RAM > * eepro100 NIC > >Is there any way I can debug this ? >When the system freezes, there are no more entries in /var/log/messages. Compile with a serial console (Documentation/serial-console.txt) and with kdb. Boot with a serial console (e.g. console=ttyS1) and with nmi_watchdog=1. Run the serial console to a second machine and view the output on the second machine. I use minicom but any decent vt100 emulator will do. Capture the serial console output. Verify that kdb is active. cat /proc/sys/kernel/kdb must be 1. Read the kdb commands, man Documentation/kdb/kdb.mm and other man pages in that directory. Verify that you are getting NMI interrupts. cat /proc interrupts, NMI count must be changing. Reproduce the bug. When it hangs the nmi watchdog should trip after 5 seconds and drop into kdb. Use the cpu command to switch to each cpu in turn and use the bt command to trace the hung tasks on each cpu. Send that trace to linux-xfs. From owner-linux-xfs@oss.sgi.com Sun Mar 3 04:40:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23Cedw18583 for linux-xfs-outgoing; Sun, 3 Mar 2002 04:40:39 -0800 Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23CeY918561 for ; Sun, 3 Mar 2002 04:40:35 -0800 Received: from fwd08.sul.t-online.de by mailout06.sul.t-online.com with smtp id 16hTsL-0003yE-08; Sun, 03 Mar 2002 12:09:57 +0100 Received: from tower (340024412816-0001@[80.145.76.2]) by fwd08.sul.t-online.com with esmtp id 16hTsK-1uqycSC; Sun, 3 Mar 2002 12:09:56 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Hasch@t-online.de (Juergen Hasch) To: Ivan Rayner Subject: Re: xfsrestore not restoring Date: Sun, 3 Mar 2002 12:11:44 +0100 X-Mailer: KMail [version 1.3.9] Cc: linux-xfs@oss.sgi.com References: <200202262059.45518.hasch@t-online.de> In-Reply-To: <200202262059.45518.hasch@t-online.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200203031211.44638.hasch@t-online.de> X-Sender: 340024412816-0001@t-dialin.net Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Am Dienstag, 26. Februar 2002 20:59 schrieb Juergen Hasch: > I will try to create a Suse 7.1 system where I can boot from to see if > the tapes can be restored there. OK, I now have SuSe 7.1 and SuSe 7.3 on my system. The kernel binaries are exactly the same. The XFS libraries and binaries are also exactly the same. My tape has been written under Suse 7.1 SuSe 7.1: xfsrestore works Linux 2.4.18-XFS + XFS-tools from current CVS GLIBC 2.2 SuSe 7.3: xfsrestore fails Linux 2.4.18-XFS + XFS-tools from current CVS GLIBC 2.2.4 ...Juergen From owner-linux-xfs@oss.sgi.com Sun Mar 3 13:50:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23LohR24048 for linux-xfs-outgoing; Sun, 3 Mar 2002 13:50:43 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23LoX924026; Sun, 3 Mar 2002 13:50:33 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g23KoRbX011659; Sun, 3 Mar 2002 12:50:27 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA91695; Sun, 3 Mar 2002 14:49:12 -0600 (CST) Received: from sgi.com (HrBNtLya8aiGd2+CYIUoyTAEYjvZ5BBx@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA98316; Sun, 3 Mar 2002 14:49:10 -0600 (CST) Message-ID: <3C828CB7.7050505@sgi.com> Date: Sun, 03 Mar 2002 14:51:03 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Ingo Juergensmann CC: "Martin K. Petersen" , linux-xfs@oss.sgi.com Subject: Re: kernel panic booting from raid5 with external log References: <20020302051731.GC14671@muaddib.localnet> <20020302154304.GD14671@muaddib.localnet> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ingo Juergensmann wrote: >On Sat, Mar 02, 2002 at 08:55:04AM -0500, Martin K. Petersen wrote: > >>Ingo> Kernel panic when mounting rootfs: root fs uses a external log >>Ingo> and I should specify where the external logdev is within my >>Ingo> mount command - but how?! >>You need to add logdev=/dev/foo to the mount options. >> > >Ok, but tell me where or how? >I mean there is already a logdev=/dev/sde2 option in /etc/fstab, but how can >kernel read /etc/fstab when it is unable to mount rootfs on /? > >Booting from auxiallary disk and mounting the raid by hand with appropriate >mount option actually works, but that was not my point. > >>Ingo> I've put my nose into man lilo.conf, man mkfs.xfs and >>Ingo> Boot-Howtos but found nothing that could help me. >>man mount >> > >man mount was too obvious for me, so I omitted this in my list of read man >pages. Sorry, my fault. > >man rdev shows that option ro is currently the only option that can be >passed to kernel for boot time. > >So, it seems as if one can not use a raid5 on / with a external logdev. Is >this right? > Try passing mount options into the rootfs using the rootflags= boot option. Steve From owner-linux-xfs@oss.sgi.com Sun Mar 3 15:23:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23NN7k25251 for linux-xfs-outgoing; Sun, 3 Mar 2002 15:23:07 -0800 Received: from muaddib.localnet (wh6012.stw.uni-rostock.de [139.30.106.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23NN3925229 for ; Sun, 3 Mar 2002 15:23:03 -0800 Received: from ij by muaddib.localnet with local (Exim 3.34 #1 (Debian)) id 16heKB-00033Y-00 for ; Sun, 03 Mar 2002 23:19:23 +0100 Date: Sun, 3 Mar 2002 23:19:23 +0100 To: linux-xfs@oss.sgi.com Subject: Re: kernel panic booting from raid5 with external log Message-ID: <20020303221923.GE14671@muaddib.localnet> References: <20020302051731.GC14671@muaddib.localnet> <20020302154304.GD14671@muaddib.localnet> <3C828CB7.7050505@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C828CB7.7050505@sgi.com> User-Agent: Mutt/1.3.27i From: Ingo Juergensmann Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Mar 03, 2002 at 02:51:03PM -0600, Stephen Lord wrote: > Try passing mount options into the rootfs using the rootflags= boot option. Ok, tried at lilo prompt: linux rootflags=logdev=/dev/sde2 Sadly this results in a kernel panic as well. After the NET4 unix domain sockets message something like this appears: EXT2-fs: Unrecognized mount option logdev Unable to handle kernel NULL pointer dereference at virtual address 00000000 . . <0> Kernel panic: Attempted to kill init Bug? -- Ciao... // PowerAnimator & Maya Operator Ingo \X/ To boldly design where noone designed before! From owner-linux-xfs@oss.sgi.com Sun Mar 3 15:40:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23Ne1Q29996 for linux-xfs-outgoing; Sun, 3 Mar 2002 15:40:01 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23Ndv929971 for ; Sun, 3 Mar 2002 15:39:57 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g23NdqBA017649 for ; Sun, 3 Mar 2002 15:39:52 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA91413 for ; Sun, 3 Mar 2002 16:38:36 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA74457 for ; Sun, 3 Mar 2002 16:38:36 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g23Mcap20658; Sun, 3 Mar 2002 16:38:36 -0600 Message-Id: <200203032238.g23Mcap20658@stout.americas.sgi.com> Date: Sun, 3 Mar 2002 16:38:36 -0600 From: Eric Sandeen Subject: TAKE - Don't allow quota flag changes on ro device Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This actually started out as tracking down oopses from unmounting full LVM snapshots... this is part of the way there. Mounting the (readonly) lvm snapshot device with quota flags that differed from the source filesystem would cause an I/O error (since a transaction was needed on the ro device), shutting down the filesystem. Still need to track down the oops after the shutdown, but at least now the shutdown won't happen - the fs won't mount if the flags don't match (and you get a helpful error message in the logs). I tested this with overflowed snapshots (from the original problem) and things seem to work, except when unloading the module one of the xfs cache zones can't be freed, we leak something somewhere. This fix does address a problem by itself, though - now on to the next part. :) Date: Sun Mar 3 14:34:15 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113180a linux/fs/xfs/xfs_mount.c - 1.271 - Don't allow quota flag change on readonly device From owner-linux-xfs@oss.sgi.com Sun Mar 3 15:50:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g23NoxE30241 for linux-xfs-outgoing; Sun, 3 Mar 2002 15:50:59 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g23Nos930218 for ; Sun, 3 Mar 2002 15:50:54 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA24625 for ; Sun, 3 Mar 2002 14:46:26 -0800 (PST) mail_from (sandeen@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA54265; Sun, 3 Mar 2002 16:49:38 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:sandeen@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA16999; Sun, 3 Mar 2002 16:49:38 -0600 (CST) Date: Sun, 3 Mar 2002 16:49:37 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Ingo Juergensmann cc: Subject: Re: kernel panic booting from raid5 with external log In-Reply-To: <20020303221923.GE14671@muaddib.localnet> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 3 Mar 2002, Ingo Juergensmann wrote: > On Sun, Mar 03, 2002 at 02:51:03PM -0600, Stephen Lord wrote: > > > Try passing mount options into the rootfs using the rootflags= boot option. > > Ok, tried at lilo prompt: linux rootflags=logdev=/dev/sde2 I think you need rootflags="logdev=/dev/sda2" -Eric From owner-linux-xfs@oss.sgi.com Sun Mar 3 19:37:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g243bfZ00665 for linux-xfs-outgoing; Sun, 3 Mar 2002 19:37:41 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g243bc900642 for ; Sun, 3 Mar 2002 19:37:38 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA07445 for ; Sun, 3 Mar 2002 18:37:41 -0800 (PST) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA92232 for ; Sun, 3 Mar 2002 20:36:22 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA29175 for ; Sun, 3 Mar 2002 20:36:22 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g242aMX20974; Sun, 3 Mar 2002 20:36:22 -0600 Message-Id: <200203040236.g242aMX20974@stout.americas.sgi.com> Date: Sun, 3 Mar 2002 20:36:22 -0600 From: Eric Sandeen Subject: TAKE - simplify last fix a bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Per Nathan's suggestion, simplify that last fix a bit. Date: Sun Mar 3 18:33:10 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113183a linux/fs/xfs/xfs_mount.c - 1.272 - Simplify a bit by moving quota check above rt inode initialization From owner-linux-xfs@oss.sgi.com Sun Mar 3 19:51:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g243pWR00982 for linux-xfs-outgoing; Sun, 3 Mar 2002 19:51:32 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g243pF900959 for ; Sun, 3 Mar 2002 19:51:15 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id DAA1259806 for ; Mon, 4 Mar 2002 03:54:45 +0100 (CET) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id g242oB733937619 for ; Sun, 3 Mar 2002 18:50:12 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 308353000B8; Mon, 4 Mar 2002 12:50:09 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 9415EBA for ; Mon, 4 Mar 2002 13:50:09 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: XFS split patches for 2.4.18 are available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Mar 2002 13:50:04 +1100 Message-ID: <18490.1015210204@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ftp://oss.sgi.com/projects/xfs/download/patches/2.4.18 README: This directory contains a snapshot of the XFS CVS tree at the start of kernel 2.4.18. The snapshot can be downloaded as a single patch containing all the XFS kernel code, it has also been split into several patches to make it easier to port XFS to other architectures and for distributors to include XFS in their distributions. You can apply the -all-i386 (ia64) patch to get a snapshot of XFS for 2.4.18-i386 (ia64) as of 2002-03-04 02:45 UTC. Or you can selectively apply the -split patches. Do not mix the -all and -split patches, that will result in patch errors and/or duplicate code. The -all and -split patches are provided as a courtesy and are not supported. They are created after the initial upgrade to a new kernel and are not changed afterwards. In particular any bug fixes or XFS/kdb changes for pre-release kernels are _not_ reflected here. The main method of XFS distribution is via the XFS CVS tree, if you want an up to date version of XFS then use CVS. If you want patches for the -ac or other alternate trees you will have to do them yourself, using these patches as a starting point. SGI do not track the alternate kernel trees for XFS, there are too many differences. Apply just the xfs-2.4.18-all-i386 patch against a pristine 2.4.18 kernel to get a snapshot of XFS for 2.4.18-i386 as of 2002-03-04 02:45 UTC. Apply just the xfs-2.4.18-all-ia64-011226 patch against 2.4.18 + ia64-011226 patch to get a snapshot of XFS for 2.4.18-ia64-011226 as of 2002-03-04 02:45 UTC. This includes kdb for ia64 but excludes kbuild-2.5. Or apply the split patches in this order xfs-2.4.18-split-kdb-i386 xfs-2.4.18-split-only xfs-2.4.18-split-xattr xfs-2.4.18-split-quota32 xfs-2.4.18-split-kernel xfs-2.4.18-split-kbuild-2.5 xfs-2.4.18-split-misc xfs-2.4.18-split-acl-dmapi against a pristine 2.4.18 kernel to get a snapshot of XFS for 2.4.18-i386 as of 2002-03-04 02:45 UTC. In either case the result should be identical to CVS except for RCS identifiers and some generated files which are shipped but should not be. Running diff -urN -I '$[ABD-Z].*\$' -x CVS -x aic7xxx -x defkeymap.c between the result of applying these patches and the corresponding XFS CVS tree should find no differences. When using the -split patches, some are required, other patches are optional. Again, do not mix the -all and -split patches, use one or the other. Required -split patches. xfs-2.4.18-split-only All the new files added by XFS. No changes to existing files. xfs-2.4.18-split-xattr Changes to existing kernel files and new files to add the standard extended attribute code. This code has been agreed by the wider VFS community, it is already in 2.5 and has been sent to Marcelo for inclusion in 2.4. xfs-2.4.18-split-quota32 A local copy of Jan Kara's 32bit VFS quota patch plus some enhancements which have been agreed to by Jan. It consists of these patches, with a minor tweak to fit over the xattr patch :- ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/quota-patch-2.4.17-3.diff http://marc.theaimsgroup.com/?l=linux-kernel&m=101482642116590&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=100408429224866&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=100239281505587&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=100253769831940&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=100261128120074&w=2 If you are patching XFS against a 2.4.18-ac kernel then it will already contain the first patch. Reverse quota-patch-2.4.17-3.diff before applying xfs-2.4.18-split-quota32 to a 2.4.18-ac tree. xfs-2.4.18-split-kernel Changes to existing kernel files to build core XFS. Applying just the -only, -xattr, -quota32 and -kernel patches gets XFS support that excludes XFS access control lists (ACLs), DMAPI, debugging etc. If core XFS (-only, -xattr, -quota32, -kernel) does not compile, that is a bug. Optional -split patches. xfs-2.4.18-split-kdb-i386 The SGI kernel debugger for i386 is included in the XFS CVS tree, this patch is identical to the one in the kdb project area (kdb-v2.1-2.4.18-common-2 + i386-1). For XFS on architectures other than ix86 you must omit this patch. You can use the IA64 kdb patch if you are building XFS on IA64. xfs-2.4.18-split-kbuild-2.5 XFS is ready for compiling with kbuild 2.5. This patch contains the extra files and additions required to hook XFS into kbuild 2.5. See http://marc.theaimsgroup.com/?l=linux-xfs&m=100510835713728&w=2 for instructions on building XFS with kbuild 2.5. For technical reasons, some changes may be in both the kbuild 2.5 patch and in XFS so you may get duplicate patches, just say 'n' to "assume -R" and "apply anyway" messages. This patch assumes that you are applying the kdb and acl-dmapi patches, if not then you will have to edit the XFS for kbuild 2.5 patch accordingly. xfs-2.4.18-split-misc Miscellaneous patches for XFS, they all hit existing kernel files. This patch sets EXTRAVERSION=-xfs, adds XFS and KDB selections to default configs and ensures that XFS source does not include files from outside the kernel tree. Files that are shipped and overwritten (such as SCSI firmware) cause problems for the SGI source repository tools and have been deleted from the XFS CVS tree. The misc patch reflects those deletions. If Marcelo's tree contains bugs that prevent XFS from compiling or running then SGI will include fixes in XFS CVS, even though the bugs are nothing to do with XFS. If you have already fixed the Marcelo bugs then the misc patch will contain duplicate changes. xfs-2.4.18-split-acl-dmapi Add XFS ACL and DMAPI support. xfs-2.4.18-split-ia64 Add XFS support for IA64, apply after the base XFS patches. Note that some kernels may have syscall tkill in ia64 slot 1217. This is incorrect and will be removed by the IA64 maintainer, extended attribute syscalls start at 1217. From owner-linux-xfs@oss.sgi.com Sun Mar 3 19:56:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g243umw01150 for linux-xfs-outgoing; Sun, 3 Mar 2002 19:56:48 -0800 Received: from dns.securities.com (mail01.securities.com [57.69.12.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g243ui901128 for ; Sun, 3 Mar 2002 19:56:45 -0800 Received: from localhost (venevene@localhost) by dns.securities.com (8.11.6/8.11.6) with ESMTP id g242uY730120; Sun, 3 Mar 2002 21:56:34 -0500 Date: Sun, 3 Mar 2002 21:56:34 -0500 (EST) From: Benito Venegas To: Keith Owens cc: Subject: Re: XFS split patches for 2.4.18 are available In-Reply-To: <18490.1015210204@kao2.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks Keith. When do you think you will launch a new release for XFS (1.1 or something like that) -- Benito A. Venegas System Engineer, Technology 488 Madison Ave. New York, NY 10022 A Euromoney Institutional Investor company. *************************************************************************** This communication contains information which is confidential. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error please notify us by e-mail or by telephone (as above) and then delete the e-mail and all attachments and any copies thereof. *************************************************************************** From owner-linux-xfs@oss.sgi.com Mon Mar 4 00:45:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g248j9w06411 for linux-xfs-outgoing; Mon, 4 Mar 2002 00:45:09 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g248ii906378 for ; Mon, 4 Mar 2002 00:44:44 -0800 Received: from lizard.webland.de (unknown [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx14)) with ESMTP id 64F96C404; Mon, 4 Mar 2002 08:22:07 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA19742; Mon, 4 Mar 2002 08:22:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 274FD57306; Mon, 4 Mar 2002 08:21:29 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 7A55625835; Mon, 4 Mar 2002 08:21:28 +0100 (CET) Message-ID: <3C832077.7826C2E0@ch.sauter-bc.com> Date: Mon, 04 Mar 2002 08:21:27 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Christian =?iso-8859-1?Q?R=F8snes?= Cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.18 freeze running dbench 1.3 References: Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christian Rřsnes schrieb: > > Hello > > Everytime I run dbench 1.3 on a linux kernel 2.4.18 from the XFS cvs > checkout, > I'm experiencing complete lockups on Compaq Proliant DL380 G2 servers. > * Dual cpu 1266 Mhz, > * SmartArray Raid controller > * 2 x 36 GB HD in Raid 1 > * 1256 MB RAM > * eepro100 NIC > > (I've installed RedHat 7.2 with the SGI 1.0.2a installer.) > > Dbench works fine when running it with the 2.4.9-13SGI_XFS_1.0.2smp kernel > from the SGI installer. > > The freeze happens evertime when I start dbench 1.3 with the 2.4.18 kernel: > (I'm running it on my /usr partition which is xfs formatted and mounted) > > Eg: > ./dbench 10 > Starting 10 clients > Hi I was doing stress test with my own script on several 2.4.x kernels. The script generates some hundred cp processes copying a directory tree with some thousand files, while running heavy nfs traffick and some bonnie's in the background. I have used this to test performance of different filesystems on different kind of raid, both hard- and software. What came out was that 1) software raid performs extreemly weel, even raid5 with xfs if you have external log. Difference between ext2, ext3 and xfs was almost zero in this test. 2) Every 2.4.x kernel beside 2.4.9-XXSGI_XFS_1.0.2 crashed with this test on different hardware! Althought I didn't try too many kernels I tried newer kernels than 2.4.9 which was available as RPM and they crashed too. -Simon > > The system then becomes unresponsive, and reseting the machine > is the only way to get it back on its feet. > I've tested this on two different DL380 G2s, and it locks up on both. > > Is anyone else seeing this ? > > Is there any way I can debug this ? > When the system freezes, there are no more entries in /var/log/messages. > There are no Oopses. > > I've included my kernel config file (gzipped) and the message output found > in > /var/log/messages (also gzipped). > > Any help appreciated. Thank you. > > (I do not have physical access to the machines at the moment, > but will on Monday) > > Christian > > -------------------------- CHECKOUT INFO ------------------------------- > > I've tried checkouts Thursday,Friday and today - all freeze up > when running 2.4.18 and dbench 1.3: > > #!/bin/sh > # > export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs' > cvs login > # FULL CHECKOUT > cvs -z3 checkout linux-2.4-xfs > > ------------------------------ XFS INFO -------------------------------- > > Here's the xfs info from the /usr partition in run dbench on. > > [root@dl01 xfs]# xfs_info /usr > meta-data=/usr isize=256 agcount=14, agsize=262144 blks > data = bsize=4096 blocks=3584280, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=1200 > realtime =none extsz=65536 blocks=0, rtextents=0 > > ------------------------------ MOUNT INFO -------------------------------- > > I've tried to mount /usr with both default logbufs and logbsize values, > and also the parameters listed for /usr below (logbufs=8,logbsize=32768). > There are dbench lockups in both cases. > > [root@dl01 xfs]# mount > /dev/cciss/c0d0p6 on / type xfs (rw) > none on /proc type proc (rw) > /dev/cciss/c0d0p1 on /boot type ext2 (rw) > none on /dev/pts type devpts (rw,gid=5,mode=620) > /dev/cciss/c0d0p7 on /home type xfs (rw,logbufs=8,logbsize=32768) > none on /dev/shm type tmpfs (rw) > /dev/cciss/c0d0p2 on /usr type xfs (rw,logbufs=8,logbsize=32768) > /dev/cciss/c0d0p3 on /var type xfs (rw,logbufs=8,logbsize=32768) > > ------------------------------------------------------------------------ > Name: messages.gz > messages.gz Type: application/x-gzip > Encoding: base64 > > Name: kernel_config_file.gz > kernel_config_file.gz Type: application/x-gzip > Encoding: base64 From owner-linux-xfs@oss.sgi.com Mon Mar 4 04:34:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24CYjC11897 for linux-xfs-outgoing; Mon, 4 Mar 2002 04:34:45 -0800 Received: from office.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24CYd911875 for ; Mon, 4 Mar 2002 04:34:40 -0800 Received: from localhost.mandrakesoft.com (dhcp108.mandrakesoft.com [192.168.100.108]) by office.mandrakesoft.com (8.9.3/8.9.3) with ESMTP id MAA32046; Mon, 4 Mar 2002 12:34:31 +0100 Received: by localhost.mandrakesoft.com (Postfix, from userid 501) id DD79516F62; Mon, 4 Mar 2002 12:24:05 +0100 (CET) To: Ingo Juergensmann Cc: linux-xfs@oss.sgi.com Subject: Re: kernel panic booting from raid5 with external log References: <20020302051731.GC14671@muaddib.localnet> <20020302154304.GD14671@muaddib.localnet> <3C828CB7.7050505@sgi.com> <20020303221923.GE14671@muaddib.localnet> X-Url: http://www.lfcia.org/~quintela From: Juan Quintela In-Reply-To: <20020303221923.GE14671@muaddib.localnet> Date: 04 Mar 2002 12:24:05 +0100 Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "ingo" == Ingo Juergensmann writes: ingo> On Sun, Mar 03, 2002 at 02:51:03PM -0600, Stephen Lord wrote: >> Try passing mount options into the rootfs using the rootflags= boot option. ingo> Ok, tried at lilo prompt: linux rootflags=logdev=/dev/sde2 ingo> Sadly this results in a kernel panic as well. ingo> After the NET4 unix domain sockets message something like this appears: ingo> EXT2-fs: Unrecognized mount option logdev ingo> Unable to handle kernel NULL pointer dereference at virtual address 00000000 ingo> . ingo> . ingo> <0> Kernel panic: Attempted to kill init Let me guess, you are using initrd, if that is true, you need to make tricks in the initrd to get that options passed to the _real_ rootfs. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy From owner-linux-xfs@oss.sgi.com Mon Mar 4 04:50:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24Co4512214 for linux-xfs-outgoing; Mon, 4 Mar 2002 04:50:04 -0800 Received: from pooh.lsc.hu (IDENT:postfix@pooh.lsc.hu [195.56.172.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24Cno912190 for ; Mon, 4 Mar 2002 04:49:50 -0800 Received: by pooh.lsc.hu (Postfix, from userid 547) id F1A4CE0005; Mon, 4 Mar 2002 12:54:05 +0100 (CET) Date: Mon, 4 Mar 2002 12:54:05 +0100 From: GCS To: linux-xfs@oss.sgi.com Subject: XFS integrated Message-ID: <20020304125405.E7175@lsc.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I have included XFS in my project (http://lkpc.sourceforge.net/), which is a collection of patches. They apply cleanly to a vanilla kernel together, the users do not have to choose one vs an other. I hope we can have a cooperation - I can ask questions, and I will report bugs if I or the users find one. Cheers, GCS -- BorsodChem Joint-Stock Company Linux Support Center University of Miskolc Software engineer Programmer System administrator +36-48-511211/27-90 +36-20-4441745 From owner-linux-xfs@oss.sgi.com Mon Mar 4 06:20:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24EKip13925 for linux-xfs-outgoing; Mon, 4 Mar 2002 06:20:44 -0800 Received: from cellus.no (www.smssiden.com [193.91.191.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24EKB913895 for ; Mon, 4 Mar 2002 06:20:12 -0800 Received: from christian ([193.69.127.56]) by cellus.no (8.9.3/8.9.3) with SMTP id OAA01971 for ; Mon, 4 Mar 2002 14:20:07 +0100 From: =?iso-8859-1?Q?Christian_R=F8snes?= To: Subject: RE: Linux 2.4.18 freeze running dbench 1.3 Date: Mon, 4 Mar 2002 14:20:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MIME-Autoconverted: from 8bit to quoted-printable by cellus.no id OAA01971 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g24EKC913896 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As per Mr Owens' description, I've now captured the kdb debugging trace - during the dbench crash. Is this related to XFS, or could it be something some other part of the kernel ? (Happens on both my DL380 G2s) Any other pointers to where I should look is greatly appreciated. Thank you. Christian -------------------- KDB DEBUG OUTPUT ----------------------- [root@dl02 dbench]# ./dbench 10 10 clients started ......invalid operand: 0000 CPU: 1 EIP: 0010:[] Not tainted EFLAGS: 00010086 eax: 0000004a ebx: f7537800 ecx: c03bbe24 edx: 00002f46 esi: 00000297 edi: f75378f0 ebp: 00000000 esp: f6d59ab8 ds: 0018 es: 0018 ss: 0018 Process dbench (pid: 1253, stackpage=f6d59000) Stack: c02ee260 0000005a 00000010 00000005 f7537800 f6d59cb0 c01b5974 f7537800 0000001e ffffffeb 00000000 00000000 f6d59bac f6d59bb0 f6d59bd8 f6d59bb8 00000000 c01b568b f6bd0610 00000090 00000000 00000000 00000000 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [ [] [] [] [] [] [ [] [] [] [] Code: 0f 0b 5f 58 c6 83 f0 00 00 00 01 56 9d 89 e8 5b 5e 5f 5d c3 Entering kdb (current=0xf6d58000, pid 1253) on processor 1 Oops: invalid operand due to oops @ 0xc01e8437 eax = 0x0000004a ebx = 0xf7537800 ecx = 0xc03bbe24 edx = 0x00002f46 esi = 0x00000297 edi = 0xf75378f0 esp = 0xf6d59ab8 eip = 0xc01e8437 ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086 xds = 0xc02e0018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf6d59a84 [1]kdb> cpu Currently on cpu 1 Available cpus: 0, 1 [1]kdb> bt EBP EIP Function(args) 0xc01e8437 xfs_mod_incore_sb+0x97 (0xf7537800, 0x1e, 0xffffffeb, 0x0) kernel .text 0xc0100000 0xc01e83a0 0xc01e8450 0xf6d59cb0 0xc01b5974 xfs_bmapi+0x634 (0xf6bd0628, 0x90000, 0x0, 0x10000, 0x2) kernel .text 0xc0100000 0xc01b5340 0xc01b6550 0xc02024ce linvfs_pb_bmap+0x6e (0xf6bd0628, 0xf6d59f4c, 0x2, 0x0, 0x) kernel .text 0xc0100000 0xc0202460 0xc02025b0 0xc01ff419 linvfs_write+0x2b9 (0xf6d364f4, 0x804bde0, 0xffc3, 0xf6d3) kernel .text 0xc0100000 0xc01ff160 0xc01ff470 0xc0145a26 sys_write+0x96 (0x7, 0x804bde0, 0xffc3, 0x18, 0x105b) kernel .text 0xc0100000 0xc0145990 0xc0145b50 0xc01078ab system_call+0x33 kernel .text 0xc0100000 0xc0107878 0xc01078b0 [1]kdb> cpu 0 Entering kdb (current=0xf6c48000, pid 1256) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xc01e8c3a _text_lock_xfs_mount+0x16 (0xf6ba2bf4, 0x30000, 0x0, 0x10) kernel .text 0xc0100000 0xc01e8c24 0xc01e8ca0 0xc02024ce linvfs_pb_bmap+0x6e (0xf6ba2bf4, 0xf6c49f4c, 0x2, 0x0, 0x) kernel .text 0xc0100000 0xc0202460 0xc02025b0 0xc01ff419 linvfs_write+0x2b9 (0xf6d369c4, 0x804bde0, 0xf803, 0xf6d3) kernel .text 0xc0100000 0xc01ff160 0xc01ff470 0xc0145a26 sys_write+0x96 (0x7, 0x804bde0, 0xf803, 0x18, 0x1062) kernel .text 0xc0100000 0xc0145990 0xc0145b50 0xc01078ab system_call+0x33 kernel .text 0xc0100000 0xc0107878 0xc01078b0 [0]kdb> -------------------- KSYMOOPS OUTPUT ----------------------- And here's the ksymoops output. ksymoops 2.4.1 on i686 2.4.9-13SGI_XFS_1.0.2smp. Options used -v /usr/src/xfs/linux-2.4-xfs/linux/vmlinux (specified) -k /var/log/ksyms.crash (specified) -L (specified) -o /lib/modules/2.4.18-xfs/ (specified) -m /usr/src/xfs/linux-2.4-xfs/linux/System.map (specified) No modules in ksyms, skipping objects Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c026ed40, vmlinux says c0173fc0. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol pci_hp_change_slot_info_R__ver_pci_hp_change_slot_info not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol pci_hp_deregister_R__ver_pci_hp_deregister not found in vmlinux. Ignoring ksy ms_base entry Warning (compare_maps): ksyms_base symbol pci_hp_register_R__ver_pci_hp_register not found in vmlinux. Ignoring ksyms_b ase entry CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: 0000004a ebx: f7537800 ecx: c03bbe24 edx: 00002f46 esi: 00000297 edi: f75378f0 ebp: 00000000 esp: f6d59ab8 ds: 0018 es: 0018 ss: 0018 Process dbench (pid: 1253, stackpage=f6d59000) Stack: c02ee260 0000005a 00000010 00000005 f7537800 f6d59cb0 c01b5974 f7537800 0000001e ffffffeb 00000000 00000000 f6d59bac f6d59bb0 f6d59bd8 f6d59bb8 00000000 c01b568b f6bd0610 00000090 00000000 00000000 00000000 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5f 58 c6 83 f0 00 00 00 01 56 9d 89 e8 5b 5e 5f 5d c3 >>EIP; c01e8437 <===== Trace; c01b5974 Trace; c01b568b Trace; c0204c66 Trace; c01f989a <_pagebuf_free_object+15a/1c0> Trace; c0202f1a Trace; c01fa58b Trace; c020461d Trace; c0203960 Trace; c02024ce Trace; c01fdb88 <_pagebuf_file_write+f8/210> Trace; c01f6802 Trace; c0202460 Trace; c01fde3b Trace; c0202460 Trace; c0203630 Trace; c0202460 Trace; c01ff419 Trace; c0145a26 Trace; c01453b0 Trace; c014561e Trace; c01078ab Code; c01e8437 00000000 <_EIP>: Code; c01e8437 <===== 0: 0f 0b ud2a <===== Code; c01e8439 2: 5f pop %edi Code; c01e843a 3: 58 pop %eax Code; c01e843b 4: c6 83 f0 00 00 00 01 movb $0x1,0xf0(%ebx) Code; c01e8442 b: 56 push %esi Code; c01e8443 c: 9d popf Code; c01e8444 d: 89 e8 mov %ebp,%eax Code; c01e8446 f: 5b pop %ebx Code; c01e8447 10: 5e pop %esi Code; c01e8448 11: 5f pop %edi Code; c01e8449 12: 5d pop %ebp Code; c01e844a 13: c3 ret Entering kdb (current=0xf6d58000, pid 1253) on processor 1 Oops: invalid operand eax = 0x0000004a ebx = 0xf7537800 ecx = 0xc03bbe24 edx = 0x00002f46 esi = 0x00000297 edi = 0xf75378f0 esp = 0xf6d59ab8 eip = 0xc01e8437 ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086 4 warnings issued. Results may not be reliable. -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On Behalf Of Christian Rřsnes Sent: 2. mars 2002 15:49 To: linux-xfs@oss.sgi.com Subject: Linux 2.4.18 freeze running dbench 1.3 Hello Everytime I run dbench 1.3 on a linux kernel 2.4.18 from the XFS cvs checkout, I'm experiencing complete lockups on Compaq Proliant DL380 G2 servers. * Dual cpu 1266 Mhz, * SmartArray Raid controller * 2 x 36 GB HD in Raid 1 * 1256 MB RAM * eepro100 NIC (I've installed RedHat 7.2 with the SGI 1.0.2a installer.) Dbench works fine when running it with the 2.4.9-13SGI_XFS_1.0.2smp kernel from the SGI installer. The freeze happens evertime when I start dbench 1.3 with the 2.4.18 kernel: (I'm running it on my /usr partition which is xfs formatted and mounted) Eg: ./dbench 10 Starting 10 clients The system then becomes unresponsive, and reseting the machine is the only way to get it back on its feet. I've tested this on two different DL380 G2s, and it locks up on both. Is anyone else seeing this ? Is there any way I can debug this ? When the system freezes, there are no more entries in /var/log/messages. There are no Oopses. I've included my kernel config file (gzipped) and the message output found in /var/log/messages (also gzipped). Any help appreciated. Thank you. (I do not have physical access to the machines at the moment, but will on Monday) Christian -------------------------- CHECKOUT INFO ------------------------------- I've tried checkouts Thursday,Friday and today - all freeze up when running 2.4.18 and dbench 1.3: #!/bin/sh # export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs' cvs login # FULL CHECKOUT cvs -z3 checkout linux-2.4-xfs ------------------------------ XFS INFO -------------------------------- Here's the xfs info from the /usr partition in run dbench on. [root@dl01 xfs]# xfs_info /usr meta-data=/usr isize=256 agcount=14, agsize=262144 blks data = bsize=4096 blocks=3584280, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 ------------------------------ MOUNT INFO -------------------------------- I've tried to mount /usr with both default logbufs and logbsize values, and also the parameters listed for /usr below (logbufs=8,logbsize=32768). There are dbench lockups in both cases. [root@dl01 xfs]# mount /dev/cciss/c0d0p6 on / type xfs (rw) none on /proc type proc (rw) /dev/cciss/c0d0p1 on /boot type ext2 (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/cciss/c0d0p7 on /home type xfs (rw,logbufs=8,logbsize=32768) none on /dev/shm type tmpfs (rw) /dev/cciss/c0d0p2 on /usr type xfs (rw,logbufs=8,logbsize=32768) /dev/cciss/c0d0p3 on /var type xfs (rw,logbufs=8,logbsize=32768) From owner-linux-xfs@oss.sgi.com Mon Mar 4 07:39:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24FdG116449 for linux-xfs-outgoing; Mon, 4 Mar 2002 07:39:16 -0800 Received: from uyema.net (dsl092-188-244.sfo2.dsl.speakeasy.net [66.92.188.244]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24Fbx916388 for ; Mon, 4 Mar 2002 07:37:59 -0800 Received: from localhost (myles@localhost) by uyema.net (8.11.6/8.11.6) with ESMTP id g24EbrL04112 for ; Mon, 4 Mar 2002 06:37:53 -0800 Date: Mon, 4 Mar 2002 06:37:53 -0800 (PST) From: Myles Uyema To: linux-xfs@oss.sgi.com Subject: CVS 2.4.18-xfs LVM-xfs-raid oops during boot Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168484060-701792593-1015252673=:3674" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --168484060-701792593-1015252673=:3674 Content-Type: TEXT/PLAIN; charset=US-ASCII I currently run 2.4.17-xfs and tried booting up 2.4.18-xfs this past weekend, but get an oops during boot...kernel was built with kgcc on Redhat 7.2. This is a staging server, and I'm trying to test it out...alas, I can't get that far. System Configuration: RedHat 7.2 SMP Abit BP6 dual celeron (mendocino) LVM 1.0.2 utilities Filesystem 1k-blocks Used Available Use% Mounted on /dev/md0 149696 139728 9968 94% / none 127236 0 127236 0% /dev/shm /dev/vol0/usr 3804480 726572 3077908 20% /usr /dev/vol0/tmp 1043776 748 1043028 1% /tmp /dev/vol0/var 2092352 473024 1619328 23% /var /dev/vol0/home 3140928 1035388 2105540 33% /home /dev/vol0/src 2092352 1395288 697064 67% /usr/src /dev/vol0/archive 13774144 584 13773560 1% /archive Personalities : [raid1] read_ahead 1024 sectors md0 : active raid1 sdb1[1] sda1[0] 154496 blocks [2/2] [UU] lvscan -- ACTIVE "/dev/vol0/tmp" [1.00 GB] striped[2] lvscan -- ACTIVE "/dev/vol0/src" [2.00 GB] striped[2] lvscan -- ACTIVE "/dev/vol0/var" [2.00 GB] lvscan -- ACTIVE "/dev/vol0/home" [3.00 GB] lvscan -- ACTIVE "/dev/vol0/archive" [13.14 GB] striped[2] lvscan -- ACTIVE "/dev/vol0/usr" [3.63 GB] lvscan -- 6 logical volumes with 24.77 GB total in 1 volume group lvscan -- 6 active logical volumes pvscan -- reading all physical volumes (this may take a while...) pvscan -- ACTIVE PV "/dev/sda4" of VG "vol0" [8.07 GB / 4.00 MB free] pvscan -- ACTIVE PV "/dev/sdb4" of VG "vol0" [16.71 GB / 4.00 MB free] pvscan -- total: 2 [24.79 GB] / in use: 2 [24.79 GB] / in no VG: 0 [0] --168484060-701792593-1015252673=:3674 Content-Type: TEXT/plain; name="2.4.18.oops.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: oops / ksymoops output Content-Disposition: attachment; filename="2.4.18.oops.txt" bWQ6IHN3YXBwZXIocGlkIDEpIHVzZWQgb2Jzb2xldGUgTUQgaW9jdGwsIHVw Z3JhZGUgeW91ciBzb2Z0d2FyZSB0byB1c2UgbmV3IGljdGxzLg0KWEZTIG1v dW50aW5nIGZpbGVzeXN0ZW0gbWQoOSwwKQ0KVkZTOiBNb3VudGVkIHJvb3Qg KHhmcyBmaWxlc3lzdGVtKSByZWFkb25seS4NCkZyZWVpbmcgdW51c2VkIGtl cm5lbCBtZW1vcnk6IDI2MGsgZnJlZWQNCmludmFsaWQgb3BlcmFuZDogMDAw MA0KQ1BVOiAgICAxDQpFSVA6ICAgIDAwMTA6WzxjMDFmMjJiZT5dICAgIE5v dCB0YWludGVkDQpFRkxBR1M6IDAwMDEwMDg2DQplYXg6IDAwMDAwMDRhICAg ZWJ4OiAwMDAwMDAwMSAgIGVjeDogZmZmZmM5NzEgICBlZHg6IDAwMDAzNjhm DQplc2k6IDAwMDAwMDg2ICAgZWRpOiBjMTQ4MDgxNCAgIGVicDogY2Y2ZGMz ZDAgICBlc3A6IGNmZjNkZWFjDQpkczogMDAxOCAgIGVzOiAwMDE4ICAgc3M6 IDAwMTgNClByb2Nlc3Mga3VwZGF0ZWQgKHBpZDogNywgc3RhY2twYWdlPWNm ZjNkMDAwKQ0KU3RhY2s6IGMwMzk2MjgwIDAwMDAwMDZmIGNmNmRjM2QwIGNm NmJjMGUwIGMxNGU5NzYwIGMxNGU5NzVjIDAwMDAwMDAwIDAwMDAwMDAwDQog ICAgICAgY2Y2YmMwZTAgYzE0ODA4MDAgYzAxZjFjYTMgY2Y2YmMwZTAgY2Yw ZmEwYTAgY2Y2YjdlMDQgMDAwMDAwMDAgY2ZmMjJhYzANCiAgICAgICBjZjZi YjFmNCAwMDAwMDI0NiAwMDAwMDAwMSAwMDAwMDAwMCBjMTQ4MDgwMCBjZjZi ZGUwMCBjZjBmYTBhMCBjMDIwODU1Ng0KQ2FsbCBUcmFjZTogWzxjMDFmMWNh Mz5dIFs8YzAyMDg1NTY+XSBbPGMwMjA3ZGUzPl0gWzxjMDIxZWMzNj5dIFs8 YzAxNGI1NjI+XQ0KICAgWzxjMDE0OWVhYz5dIFs8YzAxNGE0Zjg+XSBbPGMw MTA1OTAzPl0NCg0KQ29kZTogMGYgMGIgODMgYzQgMDggOGIgNDQgMjQgMWMg ODYgNTggMTQgNTYgOWQgNTUgNjggMzggMmYgMWYgYzANCg0Kd2FpdF9vbl9p cnEsIENQVSAxOg0KaXJxOiAgMCBbIDAgMCBdDQpiaDogICAxIFsgMSAwIF0N ClN0YWNrIGR1bXBzOg0KQ1BVIDA6IDx1bmtub3duPg0KQ1BVIDE6YzE0NzVm MzQgYzAzNmZmZGQgMDAwMDAwMDEgMDAwMDAwMDAgMDAwMDAwMjAgMDAwMDAw MDEgYzAxMDhjYmQgYzAzNmZmZjINCiAgICAgICBjMDQ5Y2FhNCBjZjRiMjAw MCAwMDAwMDAwMSBjZjRiMjU2YyBjMDI0ODhhOSBjMDQ5Y2FhNCBjMTQ3NWY5 MCAwMDAwMDI4Ng0KICAgICAgIGMxNDc1ZmUwIGNmNGIyMTZjIGMwMTIxNGU4 IGNmNGIyMDAwIDAwMDAwMDAxIGMxNDc1ZmNjIGMxNDc0NjU4IGNmNGIyMTMw DQpDYWxsIFRyYWNlOiBbPGMwMTA4Y2JkPl0gWzxjMDI0ODhhOT5dIFs8YzAx MjE0ZTg+XSBbPGMwMTJiMDVjPl0gWzxjMDEwNzgwMD5dDQogICBbPGMwMTA1 OTAzPl0NCg0KaW52YWxpZCBvcGVyYW5kOiAwMDAwDQpDUFU6ICAgIDENCkVJ UDogICAgMDAxMDpbPGMwMWYyMmJlPl0gICAgTm90IHRhaW50ZWQNClVzaW5n IGRlZmF1bHRzIGZyb20ga3N5bW9vcHMgLXQgZWxmMzItaTM4NiAtYSBpMzg2 DQpFRkxBR1M6IDAwMDEwMDg2DQplYXg6IDAwMDAwMDRhICAgZWJ4OiAwMDAw MDAwMSAgIGVjeDogZmZmZmM5NzEgICBlZHg6IDAwMDAzNjhmDQplc2k6IDAw MDAwMDg2ICAgZWRpOiBjMTQ4MDgxNCAgIGVicDogY2Y2ZGMzZDAgICBlc3A6 IGNmZjNkZWFjDQpkczogMDAxOCAgIGVzOiAwMDE4ICAgc3M6IDAwMTgNClBy b2Nlc3Mga3VwZGF0ZWQgKHBpZDogNywgc3RhY2twYWdlPWNmZjNkMDAwKQ0K U3RhY2s6IGMwMzk2MjgwIDAwMDAwMDZmIGNmNmRjM2QwIGNmNmJjMGUwIGMx NGU5NzYwIGMxNGU5NzVjIDAwMDAwMDAwIDAwMDAwMDAwDQogICAgICAgY2Y2 YmMwZTAgYzE0ODA4MDAgYzAxZjFjYTMgY2Y2YmMwZTAgY2YwZmEwYTAgY2Y2 YjdlMDQgMDAwMDAwMDAgY2ZmMjJhYzANCiAgICAgICBjZjZiYjFmNCAwMDAw MDI0NiAwMDAwMDAwMSAwMDAwMDAwMCBjMTQ4MDgwMCBjZjZiZGUwMCBjZjBm YTBhMCBjMDIwODU1Ng0KQ2FsbCBUcmFjZTogWzxjMDFmMWNhMz5dIFs8YzAy MDg1NTY+XSBbPGMwMjA3ZGUzPl0gWzxjMDIxZWMzNj5dIFs8YzAxNGI1NjI+ XQ0KICAgWzxjMDE0OWVhYz5dIFs8YzAxNGE0Zjg+XSBbPGMwMTA1OTAzPl0N CkNvZGU6IDBmIDBiIDgzIGM0IDA4IDhiIDQ0IDI0IDFjIDg2IDU4IDE0IDU2 IDlkIDU1IDY4IDM4IDJmIDFmIGMwDQoNCj4+RUlQOyBjMDFmMjJiZSA8eGZz X2lmbHVzaF9pbnQrMzQyLzM4ND4gICA8PT09PT0NClRyYWNlOyBjMDFmMWNh MyA8eGZzX2lmbHVzaCsyM2IvNTE0Pg0KVHJhY2U7IGMwMjA4NTU2IDx4ZnNf c3luY3N1Yis3NmUvYzAwPg0KVHJhY2U7IGMwMjA3ZGUzIDx4ZnNfc3luYysx My8xOD4NClRyYWNlOyBjMDIxZWMzNiA8bGludmZzX3dyaXRlX3N1cGVyKzJh LzMwPg0KVHJhY2U7IGMwMTRiNTYyIDxzeW5jX3N1cGVycysxNTYvMWQwPg0K VHJhY2U7IGMwMTQ5ZWFjIDxzeW5jX29sZF9idWZmZXJzKzY0LzE5ND4NClRy YWNlOyBjMDE0YTRmOCA8a3VwZGF0ZSsyOWMvMmE0Pg0KVHJhY2U7IGMwMTA1 OTAzIDxrZXJuZWxfdGhyZWFkKzIzLzMwPg0KQ29kZTsgIGMwMWYyMmJlIDx4 ZnNfaWZsdXNoX2ludCszNDIvMzg0Pg0KMDAwMDAwMDAgPF9FSVA+Og0KQ29k ZTsgIGMwMWYyMmJlIDx4ZnNfaWZsdXNoX2ludCszNDIvMzg0PiAgIDw9PT09 PQ0KICAgMDogICAwZiAwYiAgICAgICAgICAgICAgICAgICAgIHVkMmEgICAg ICA8PT09PT0NCkNvZGU7ICBjMDFmMjJjMCA8eGZzX2lmbHVzaF9pbnQrMzQ0 LzM4ND4NCiAgIDI6ICAgODMgYzQgMDggICAgICAgICAgICAgICAgICBhZGQg ICAgJDB4OCwlZXNwDQpDb2RlOyAgYzAxZjIyYzMgPHhmc19pZmx1c2hfaW50 KzM0Ny8zODQ+DQogICA1OiAgIDhiIDQ0IDI0IDFjICAgICAgICAgICAgICAg bW92ICAgIDB4MWMoJWVzcCwxKSwlZWF4DQpDb2RlOyAgYzAxZjIyYzcgPHhm c19pZmx1c2hfaW50KzM0Yi8zODQ+DQogICA5OiAgIDg2IDU4IDE0ICAgICAg ICAgICAgICAgICAgeGNoZyAgICVibCwweDE0KCVlYXgpDQpDb2RlOyAgYzAx ZjIyY2EgPHhmc19pZmx1c2hfaW50KzM0ZS8zODQ+DQogICBjOiAgIDU2ICAg ICAgICAgICAgICAgICAgICAgICAgcHVzaCAgICVlc2kNCkNvZGU7ICBjMDFm MjJjYiA8eGZzX2lmbHVzaF9pbnQrMzRmLzM4ND4NCiAgIGQ6ICAgOWQgICAg ICAgICAgICAgICAgICAgICAgICBwb3BmDQpDb2RlOyAgYzAxZjIyY2MgPHhm c19pZmx1c2hfaW50KzM1MC8zODQ+DQogICBlOiAgIDU1ICAgICAgICAgICAg ICAgICAgICAgICAgcHVzaCAgICVlYnANCkNvZGU7ICBjMDFmMjJjZCA8eGZz X2lmbHVzaF9pbnQrMzUxLzM4ND4NCiAgIGY6ICAgNjggMzggMmYgMWYgYzAg ICAgICAgICAgICBwdXNoICAgJDB4YzAxZjJmMzgNCg0Kd2FpdF9vbl9pcnEs IENQVSAxOg0KaXJxOiAgMCBbIDAgMCBdDQpiaDogICAxIFsgMSAwIF0NClN0 YWNrIGR1bXBzOg0KQ1BVIDA6IDx1bmtub3duPg0KQ1BVIDE6YzE0NzVmMzQg YzAzNmZmZGQgMDAwMDAwMDEgMDAwMDAwMDAgMDAwMDAwMjAgMDAwMDAwMDEg YzAxMDhjYmQgYzAzNmZmZjINCiAgICAgICBjMDQ5Y2FhNCBjZjRiMjAwMCAw MDAwMDAwMSBjZjRiMjU2YyBjMDI0ODhhOSBjMDQ5Y2FhNCBjMTQ3NWY5MCAw MDAwMDI4Ng0KICAgICAgIGMxNDc1ZmUwIGNmNGIyMTZjIGMwMTIxNGU4IGNm NGIyMDAwIDAwMDAwMDAxIGMxNDc1ZmNjIGMxNDc0NjU4IGNmNGIyMTMwDQpD YWxsIFRyYWNlOiBbPGMwMTA4Y2JkPl0gWzxjMDI0ODhhOT5dIFs8YzAxMjE0 ZTg+XSBbPGMwMTJiMDVjPl0gWzxjMDEwNzgwMD5dDQogICBbPGMwMTA1OTAz Pl0NCldhcm5pbmcgKE9vcHNfcmVhZCk6IENvZGUgbGluZSBub3Qgc2Vlbiwg ZHVtcGluZyB3aGF0IGRhdGEgaXMgYXZhaWxhYmxlDQoNClRyYWNlOyBjMDEw OGNiZCA8X19nbG9iYWxfY2xpKzhkLzEyYz4NClRyYWNlOyBjMDI0ODhhOSA8 Zmx1c2hfdG9fbGRpc2MrMTQ1LzE4Yz4NClRyYWNlOyBjMDEyMTRlOCA8X19y dW5fdGFza19xdWV1ZStlMC9mMD4NClRyYWNlOyBjMDEyYjA1YyA8Y29udGV4 dF90aHJlYWQrMWU0LzMxYz4NClRyYWNlOyBjMDEwNzgwMCA8dHJhY2VzeXNf ZXhpdCs1L2E+DQpUcmFjZTsgYzAxMDU5MDMgPGtlcm5lbF90aHJlYWQrMjMv MzA+DQoNCg0KMTM2NyB3YXJuaW5ncyBhbmQgNCBlcnJvcnMgaXNzdWVkLiAg UmVzdWx0cyBtYXkgbm90IGJlIHJlbGlhYmxlLg0KDQo= --168484060-701792593-1015252673=:3674 Content-Type: TEXT/plain; name="2.4.18.config.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: .config Content-Disposition: attachment; filename="2.4.18.config.txt" Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBtYWtlIGNvbmZpZzogZG9u J3QgZWRpdA0KIw0KQ09ORklHX1g4Nj15DQpDT05GSUdfSVNBPXkNCiMgQ09O RklHX1NCVVMgaXMgbm90IHNldA0KQ09ORklHX1VJRDE2PXkNCg0KIw0KIyBD b2RlIG1hdHVyaXR5IGxldmVsIG9wdGlvbnMNCiMNCkNPTkZJR19FWFBFUklN RU5UQUw9eQ0KDQojDQojIExvYWRhYmxlIG1vZHVsZSBzdXBwb3J0DQojDQpD T05GSUdfTU9EVUxFUz15DQpDT05GSUdfTU9EVkVSU0lPTlM9eQ0KQ09ORklH X0tNT0Q9eQ0KDQojDQojIFByb2Nlc3NvciB0eXBlIGFuZCBmZWF0dXJlcw0K Iw0KIyBDT05GSUdfTTM4NiBpcyBub3Qgc2V0DQojIENPTkZJR19NNDg2IGlz IG5vdCBzZXQNCiMgQ09ORklHX001ODYgaXMgbm90IHNldA0KIyBDT05GSUdf TTU4NlRTQyBpcyBub3Qgc2V0DQojIENPTkZJR19NNTg2TU1YIGlzIG5vdCBz ZXQNCkNPTkZJR19NNjg2PXkNCiMgQ09ORklHX01QRU5USVVNSUlJIGlzIG5v dCBzZXQNCiMgQ09ORklHX01QRU5USVVNNCBpcyBub3Qgc2V0DQojIENPTkZJ R19NSzYgaXMgbm90IHNldA0KIyBDT05GSUdfTUs3IGlzIG5vdCBzZXQNCiMg Q09ORklHX01FTEFOIGlzIG5vdCBzZXQNCiMgQ09ORklHX01DUlVTT0UgaXMg bm90IHNldA0KIyBDT05GSUdfTVdJTkNISVBDNiBpcyBub3Qgc2V0DQojIENP TkZJR19NV0lOQ0hJUDIgaXMgbm90IHNldA0KIyBDT05GSUdfTVdJTkNISVAz RCBpcyBub3Qgc2V0DQojIENPTkZJR19NQ1lSSVhJSUkgaXMgbm90IHNldA0K Q09ORklHX1g4Nl9XUF9XT1JLU19PSz15DQpDT05GSUdfWDg2X0lOVkxQRz15 DQpDT05GSUdfWDg2X0NNUFhDSEc9eQ0KQ09ORklHX1g4Nl9YQUREPXkNCkNP TkZJR19YODZfQlNXQVA9eQ0KQ09ORklHX1g4Nl9QT1BBRF9PSz15DQojIENP TkZJR19SV1NFTV9HRU5FUklDX1NQSU5MT0NLIGlzIG5vdCBzZXQNCkNPTkZJ R19SV1NFTV9YQ0hHQUREX0FMR09SSVRITT15DQpDT05GSUdfWDg2X0wxX0NB Q0hFX1NISUZUPTUNCkNPTkZJR19YODZfVFNDPXkNCkNPTkZJR19YODZfR09P RF9BUElDPXkNCkNPTkZJR19YODZfUEdFPXkNCkNPTkZJR19YODZfVVNFX1BQ Uk9fQ0hFQ0tTVU09eQ0KQ09ORklHX1g4Nl9QUFJPX0ZFTkNFPXkNCiMgQ09O RklHX1RPU0hJQkEgaXMgbm90IHNldA0KIyBDT05GSUdfSThLIGlzIG5vdCBz ZXQNCiMgQ09ORklHX01JQ1JPQ09ERSBpcyBub3Qgc2V0DQojIENPTkZJR19Y ODZfTVNSIGlzIG5vdCBzZXQNCiMgQ09ORklHX1g4Nl9DUFVJRCBpcyBub3Qg c2V0DQpDT05GSUdfTk9ISUdITUVNPXkNCiMgQ09ORklHX0hJR0hNRU00RyBp cyBub3Qgc2V0DQojIENPTkZJR19ISUdITUVNNjRHIGlzIG5vdCBzZXQNCiMg Q09ORklHX01BVEhfRU1VTEFUSU9OIGlzIG5vdCBzZXQNCkNPTkZJR19NVFJS PXkNCkNPTkZJR19TTVA9eQ0KIyBDT05GSUdfTVVMVElRVUFEIGlzIG5vdCBz ZXQNCkNPTkZJR19IQVZFX0RFQ19MT0NLPXkNCg0KIw0KIyBHZW5lcmFsIHNl dHVwDQojDQpDT05GSUdfTkVUPXkNCkNPTkZJR19YODZfSU9fQVBJQz15DQpD T05GSUdfWDg2X0xPQ0FMX0FQSUM9eQ0KQ09ORklHX1BDST15DQojIENPTkZJ R19QQ0lfR09CSU9TIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BDSV9HT0RJUkVD VCBpcyBub3Qgc2V0DQpDT05GSUdfUENJX0dPQU5ZPXkNCkNPTkZJR19QQ0lf QklPUz15DQpDT05GSUdfUENJX0RJUkVDVD15DQpDT05GSUdfUENJX05BTUVT PXkNCiMgQ09ORklHX0VJU0EgaXMgbm90IHNldA0KIyBDT05GSUdfTUNBIGlz IG5vdCBzZXQNCiMgQ09ORklHX0hPVFBMVUcgaXMgbm90IHNldA0KIyBDT05G SUdfUENNQ0lBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hPVFBMVUdfUENJIGlz IG5vdCBzZXQNCkNPTkZJR19TWVNWSVBDPXkNCkNPTkZJR19CU0RfUFJPQ0VT U19BQ0NUPXkNCkNPTkZJR19TWVNDVEw9eQ0KQ09ORklHX0tDT1JFX0VMRj15 DQojIENPTkZJR19LQ09SRV9BT1VUIGlzIG5vdCBzZXQNCkNPTkZJR19CSU5G TVRfQU9VVD15DQpDT05GSUdfQklORk1UX0VMRj15DQpDT05GSUdfQklORk1U X01JU0M9eQ0KQ09ORklHX1BNPXkNCkNPTkZJR19BQ1BJPXkNCiMgQ09ORklH X0FDUElfREVCVUcgaXMgbm90IHNldA0KQ09ORklHX0FDUElfQlVTTUdSPXkN CkNPTkZJR19BQ1BJX1NZUz15DQpDT05GSUdfQUNQSV9DUFU9eQ0KQ09ORklH X0FDUElfQlVUVE9OPXkNCkNPTkZJR19BQ1BJX0FDPXkNCkNPTkZJR19BQ1BJ X0VDPXkNCkNPTkZJR19BQ1BJX0NNQkFUVD15DQpDT05GSUdfQUNQSV9USEVS TUFMPXkNCkNPTkZJR19BUE09eQ0KIyBDT05GSUdfQVBNX0lHTk9SRV9VU0VS X1NVU1BFTkQgaXMgbm90IHNldA0KIyBDT05GSUdfQVBNX0RPX0VOQUJMRSBp cyBub3Qgc2V0DQojIENPTkZJR19BUE1fQ1BVX0lETEUgaXMgbm90IHNldA0K IyBDT05GSUdfQVBNX0RJU1BMQVlfQkxBTksgaXMgbm90IHNldA0KIyBDT05G SUdfQVBNX1JUQ19JU19HTVQgaXMgbm90IHNldA0KIyBDT05GSUdfQVBNX0FM TE9XX0lOVFMgaXMgbm90IHNldA0KIyBDT05GSUdfQVBNX1JFQUxfTU9ERV9Q T1dFUl9PRkYgaXMgbm90IHNldA0KDQojDQojIE1lbW9yeSBUZWNobm9sb2d5 IERldmljZXMgKE1URCkNCiMNCiMgQ09ORklHX01URCBpcyBub3Qgc2V0DQoN CiMNCiMgUGFyYWxsZWwgcG9ydCBzdXBwb3J0DQojDQpDT05GSUdfUEFSUE9S VD1tDQpDT05GSUdfUEFSUE9SVF9QQz1tDQpDT05GSUdfUEFSUE9SVF9QQ19D TUwxPW0NCkNPTkZJR19QQVJQT1JUX1NFUklBTD1tDQpDT05GSUdfUEFSUE9S VF9QQ19GSUZPPXkNCkNPTkZJR19QQVJQT1JUX1BDX1NVUEVSSU89eQ0KIyBD T05GSUdfUEFSUE9SVF9BTUlHQSBpcyBub3Qgc2V0DQojIENPTkZJR19QQVJQ T1JUX01GQzMgaXMgbm90IHNldA0KIyBDT05GSUdfUEFSUE9SVF9BVEFSSSBp cyBub3Qgc2V0DQojIENPTkZJR19QQVJQT1JUX0dTQyBpcyBub3Qgc2V0DQoj IENPTkZJR19QQVJQT1JUX1NVTkJQUCBpcyBub3Qgc2V0DQojIENPTkZJR19Q QVJQT1JUX09USEVSIGlzIG5vdCBzZXQNCkNPTkZJR19QQVJQT1JUXzEyODQ9 eQ0KDQojDQojIFBsdWcgYW5kIFBsYXkgY29uZmlndXJhdGlvbg0KIw0KQ09O RklHX1BOUD15DQojIENPTkZJR19JU0FQTlAgaXMgbm90IHNldA0KDQojDQoj IEJsb2NrIGRldmljZXMNCiMNCkNPTkZJR19CTEtfREVWX0ZEPXkNCiMgQ09O RklHX0JMS19ERVZfWEQgaXMgbm90IHNldA0KIyBDT05GSUdfUEFSSURFIGlz IG5vdCBzZXQNCiMgQ09ORklHX0JMS19DUFFfREEgaXMgbm90IHNldA0KIyBD T05GSUdfQkxLX0NQUV9DSVNTX0RBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JM S19ERVZfREFDOTYwIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0xPT1A9 eQ0KQ09ORklHX0JMS19ERVZfTkJEPXkNCkNPTkZJR19CTEtfREVWX1JBTT15 DQpDT05GSUdfQkxLX0RFVl9SQU1fU0laRT00MDk2DQpDT05GSUdfQkxLX0RF Vl9JTklUUkQ9eQ0KDQojDQojIE11bHRpLWRldmljZSBzdXBwb3J0IChSQUlE IGFuZCBMVk0pDQojDQpDT05GSUdfTUQ9eQ0KQ09ORklHX0JMS19ERVZfTUQ9 eQ0KQ09ORklHX01EX0xJTkVBUj15DQpDT05GSUdfTURfUkFJRDA9eQ0KQ09O RklHX01EX1JBSUQxPXkNCkNPTkZJR19NRF9SQUlENT15DQpDT05GSUdfTURf TVVMVElQQVRIPXkNCkNPTkZJR19CTEtfREVWX0xWTT15DQoNCiMNCiMgTmV0 d29ya2luZyBvcHRpb25zDQojDQpDT05GSUdfUEFDS0VUPXkNCkNPTkZJR19Q QUNLRVRfTU1BUD15DQojIENPTkZJR19ORVRMSU5LX0RFViBpcyBub3Qgc2V0 DQpDT05GSUdfTkVURklMVEVSPXkNCiMgQ09ORklHX05FVEZJTFRFUl9ERUJV RyBpcyBub3Qgc2V0DQpDT05GSUdfRklMVEVSPXkNCkNPTkZJR19VTklYPXkN CkNPTkZJR19JTkVUPXkNCkNPTkZJR19JUF9NVUxUSUNBU1Q9eQ0KIyBDT05G SUdfSVBfQURWQU5DRURfUk9VVEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQ X1BOUCBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX0lQSVA9bQ0KQ09ORklHX05F VF9JUEdSRT1tDQpDT05GSUdfTkVUX0lQR1JFX0JST0FEQ0FTVD15DQpDT05G SUdfSVBfTVJPVVRFPXkNCkNPTkZJR19JUF9QSU1TTV9WMT15DQpDT05GSUdf SVBfUElNU01fVjI9eQ0KIyBDT05GSUdfQVJQRCBpcyBub3Qgc2V0DQpDT05G SUdfSU5FVF9FQ049eQ0KQ09ORklHX1NZTl9DT09LSUVTPXkNCg0KIw0KIyAg IElQOiBOZXRmaWx0ZXIgQ29uZmlndXJhdGlvbg0KIw0KQ09ORklHX0lQX05G X0NPTk5UUkFDSz15DQpDT05GSUdfSVBfTkZfRlRQPW0NCkNPTkZJR19JUF9O Rl9JUkM9bQ0KQ09ORklHX0lQX05GX1FVRVVFPW0NCkNPTkZJR19JUF9ORl9J UFRBQkxFUz15DQpDT05GSUdfSVBfTkZfTUFUQ0hfTElNSVQ9eQ0KQ09ORklH X0lQX05GX01BVENIX01BQz15DQpDT05GSUdfSVBfTkZfTUFUQ0hfTUFSSz15 DQpDT05GSUdfSVBfTkZfTUFUQ0hfTVVMVElQT1JUPXkNCkNPTkZJR19JUF9O Rl9NQVRDSF9UT1M9eQ0KQ09ORklHX0lQX05GX01BVENIX0FIX0VTUD15DQpD T05GSUdfSVBfTkZfTUFUQ0hfTEVOR1RIPXkNCkNPTkZJR19JUF9ORl9NQVRD SF9UVEw9eQ0KQ09ORklHX0lQX05GX01BVENIX1RDUE1TUz15DQpDT05GSUdf SVBfTkZfTUFUQ0hfU1RBVEU9eQ0KQ09ORklHX0lQX05GX01BVENIX1VOQ0xF QU49eQ0KQ09ORklHX0lQX05GX01BVENIX09XTkVSPXkNCkNPTkZJR19JUF9O Rl9GSUxURVI9eQ0KQ09ORklHX0lQX05GX1RBUkdFVF9SRUpFQ1Q9eQ0KQ09O RklHX0lQX05GX1RBUkdFVF9NSVJST1I9bQ0KQ09ORklHX0lQX05GX05BVD15 DQpDT05GSUdfSVBfTkZfTkFUX05FRURFRD15DQpDT05GSUdfSVBfTkZfVEFS R0VUX01BU1FVRVJBREU9bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9SRURJUkVD VD1tDQpDT05GSUdfSVBfTkZfTkFUX1NOTVBfQkFTSUM9bQ0KQ09ORklHX0lQ X05GX05BVF9JUkM9bQ0KQ09ORklHX0lQX05GX05BVF9GVFA9bQ0KQ09ORklH X0lQX05GX01BTkdMRT15DQpDT05GSUdfSVBfTkZfVEFSR0VUX1RPUz15DQpD T05GSUdfSVBfTkZfVEFSR0VUX01BUks9eQ0KQ09ORklHX0lQX05GX1RBUkdF VF9MT0c9eQ0KIyBDT05GSUdfSVBfTkZfVEFSR0VUX1VMT0cgaXMgbm90IHNl dA0KQ09ORklHX0lQX05GX1RBUkdFVF9UQ1BNU1M9eQ0KQ09ORklHX0lQVjY9 eQ0KDQojDQojICAgSVB2NjogTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24NCiMN CiMgQ09ORklHX0lQNl9ORl9RVUVVRSBpcyBub3Qgc2V0DQpDT05GSUdfSVA2 X05GX0lQVEFCTEVTPXkNCkNPTkZJR19JUDZfTkZfTUFUQ0hfTElNSVQ9bQ0K Q09ORklHX0lQNl9ORl9NQVRDSF9NQUM9bQ0KQ09ORklHX0lQNl9ORl9NQVRD SF9NVUxUSVBPUlQ9bQ0KQ09ORklHX0lQNl9ORl9NQVRDSF9PV05FUj1tDQpD T05GSUdfSVA2X05GX01BVENIX01BUks9bQ0KQ09ORklHX0lQNl9ORl9GSUxU RVI9bQ0KQ09ORklHX0lQNl9ORl9UQVJHRVRfTE9HPW0NCkNPTkZJR19JUDZf TkZfTUFOR0xFPW0NCkNPTkZJR19JUDZfTkZfVEFSR0VUX01BUks9bQ0KIyBD T05GSUdfS0hUVFBEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FUTSBpcyBub3Qg c2V0DQpDT05GSUdfVkxBTl84MDIxUT1tDQoNCiMNCiMgIA0KIw0KIyBDT05G SUdfSVBYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FUQUxLIGlzIG5vdCBzZXQN CiMgQ09ORklHX0RFQ05FVCBpcyBub3Qgc2V0DQpDT05GSUdfQlJJREdFPW0N CiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0DQojIENPTkZJR19MQVBCIGlzIG5v dCBzZXQNCiMgQ09ORklHX0xMQyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRf RElWRVJUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VDT05FVCBpcyBub3Qgc2V0 DQojIENPTkZJR19XQU5fUk9VVEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX05F VF9GQVNUUk9VVEUgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX0hXX0ZMT1dD T05UUk9MIGlzIG5vdCBzZXQNCg0KIw0KIyBRb1MgYW5kL29yIGZhaXIgcXVl dWVpbmcNCiMNCkNPTkZJR19ORVRfU0NIRUQ9eQ0KQ09ORklHX05FVF9TQ0hf Q0JRPXkNCkNPTkZJR19ORVRfU0NIX0NTWj15DQpDT05GSUdfTkVUX1NDSF9Q UklPPXkNCkNPTkZJR19ORVRfU0NIX1JFRD15DQpDT05GSUdfTkVUX1NDSF9T RlE9eQ0KQ09ORklHX05FVF9TQ0hfVEVRTD15DQpDT05GSUdfTkVUX1NDSF9U QkY9eQ0KQ09ORklHX05FVF9TQ0hfR1JFRD15DQpDT05GSUdfTkVUX1NDSF9E U01BUks9eQ0KQ09ORklHX05FVF9TQ0hfSU5HUkVTUz15DQpDT05GSUdfTkVU X1FPUz15DQpDT05GSUdfTkVUX0VTVElNQVRPUj15DQpDT05GSUdfTkVUX0NM Uz15DQpDT05GSUdfTkVUX0NMU19UQ0lOREVYPXkNCkNPTkZJR19ORVRfQ0xT X1JPVVRFND15DQpDT05GSUdfTkVUX0NMU19ST1VURT15DQpDT05GSUdfTkVU X0NMU19GVz15DQpDT05GSUdfTkVUX0NMU19VMzI9eQ0KQ09ORklHX05FVF9D TFNfUlNWUD15DQpDT05GSUdfTkVUX0NMU19SU1ZQNj15DQpDT05GSUdfTkVU X0NMU19QT0xJQ0U9eQ0KDQojDQojIFRlbGVwaG9ueSBTdXBwb3J0DQojDQoj IENPTkZJR19QSE9ORSBpcyBub3Qgc2V0DQojIENPTkZJR19QSE9ORV9JWEog aXMgbm90IHNldA0KIyBDT05GSUdfUEhPTkVfSVhKX1BDTUNJQSBpcyBub3Qg c2V0DQoNCiMNCiMgQVRBL0lERS9NRk0vUkxMIHN1cHBvcnQNCiMNCkNPTkZJ R19JREU9eQ0KDQojDQojIElERSwgQVRBIGFuZCBBVEFQSSBCbG9jayBkZXZp Y2VzDQojDQpDT05GSUdfQkxLX0RFVl9JREU9eQ0KDQojDQojIFBsZWFzZSBz ZWUgRG9jdW1lbnRhdGlvbi9pZGUudHh0IGZvciBoZWxwL2luZm8gb24gSURF IGRyaXZlcw0KIw0KIyBDT05GSUdfQkxLX0RFVl9IRF9JREUgaXMgbm90IHNl dA0KIyBDT05GSUdfQkxLX0RFVl9IRCBpcyBub3Qgc2V0DQpDT05GSUdfQkxL X0RFVl9JREVESVNLPXkNCkNPTkZJR19JREVESVNLX01VTFRJX01PREU9eQ0K IyBDT05GSUdfQkxLX0RFVl9JREVESVNLX1ZFTkRPUiBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfREVWX0lERURJU0tfRlVKSVRTVSBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfREVWX0lERURJU0tfSUJNIGlzIG5vdCBzZXQNCiMgQ09O RklHX0JMS19ERVZfSURFRElTS19NQVhUT1IgaXMgbm90IHNldA0KIyBDT05G SUdfQkxLX0RFVl9JREVESVNLX1FVQU5UVU0gaXMgbm90IHNldA0KIyBDT05G SUdfQkxLX0RFVl9JREVESVNLX1NFQUdBVEUgaXMgbm90IHNldA0KIyBDT05G SUdfQkxLX0RFVl9JREVESVNLX1dEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JM S19ERVZfQ09NTUVSSUFMIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZf VElWTyBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0lERUNTIGlzIG5v dCBzZXQNCkNPTkZJR19CTEtfREVWX0lERUNEPXkNCkNPTkZJR19CTEtfREVW X0lERVRBUEU9bQ0KQ09ORklHX0JMS19ERVZfSURFRkxPUFBZPXkNCkNPTkZJ R19CTEtfREVWX0lERVNDU0k9bQ0KDQojDQojIElERSBjaGlwc2V0IHN1cHBv cnQvYnVnZml4ZXMNCiMNCkNPTkZJR19CTEtfREVWX0NNRDY0MD15DQojIENP TkZJR19CTEtfREVWX0NNRDY0MF9FTkhBTkNFRCBpcyBub3Qgc2V0DQojIENP TkZJR19CTEtfREVWX0lTQVBOUCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RF Vl9SWjEwMDA9eQ0KQ09ORklHX0JMS19ERVZfSURFUENJPXkNCkNPTkZJR19J REVQQ0lfU0hBUkVfSVJRPXkNCkNPTkZJR19CTEtfREVWX0lERURNQV9QQ0k9 eQ0KQ09ORklHX0JMS19ERVZfQURNQT15DQojIENPTkZJR19CTEtfREVWX09G RkJPQVJEIGlzIG5vdCBzZXQNCkNPTkZJR19JREVETUFfUENJX0FVVE89eQ0K Q09ORklHX0JMS19ERVZfSURFRE1BPXkNCiMgQ09ORklHX0lERURNQV9QQ0lf V0lQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lERURNQV9ORVdfRFJJVkVfTElT VElOR1MgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9BRUM2MlhYIGlz IG5vdCBzZXQNCiMgQ09ORklHX0FFQzYyWFhfVFVOSU5HIGlzIG5vdCBzZXQN CiMgQ09ORklHX0JMS19ERVZfQUxJMTVYMyBpcyBub3Qgc2V0DQojIENPTkZJ R19XRENfQUxJMTVYMyBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0FN RDc0WFggaXMgbm90IHNldA0KIyBDT05GSUdfQU1ENzRYWF9PVkVSUklERSBp cyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0NNRDY0WCBpcyBub3Qgc2V0 DQojIENPTkZJR19CTEtfREVWX0NZODJDNjkzIGlzIG5vdCBzZXQNCiMgQ09O RklHX0JMS19ERVZfQ1M1NTMwIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVW X0hQVDM0WD15DQojIENPTkZJR19IUFQzNFhfQVVUT0RNQSBpcyBub3Qgc2V0 DQpDT05GSUdfQkxLX0RFVl9IUFQzNjY9eQ0KQ09ORklHX0JMS19ERVZfUElJ WD15DQpDT05GSUdfUElJWF9UVU5JTkc9eQ0KIyBDT05GSUdfQkxLX0RFVl9O Uzg3NDE1IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfT1BUSTYyMSBp cyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX1BEQzIwMlhYIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1BEQzIwMlhYX0JVUlNUIGlzIG5vdCBzZXQNCiMgQ09O RklHX1BEQzIwMlhYX0ZPUkNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19E RVZfU1ZXS1MgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9TSVM1NTEz IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfU0xDOTBFNjYgaXMgbm90 IHNldA0KIyBDT05GSUdfQkxLX0RFVl9UUk0yOTAgaXMgbm90IHNldA0KQ09O RklHX0JMS19ERVZfVklBODJDWFhYPXkNCiMgQ09ORklHX0lERV9DSElQU0VU UyBpcyBub3Qgc2V0DQpDT05GSUdfSURFRE1BX0FVVE89eQ0KIyBDT05GSUdf SURFRE1BX0lWQiBpcyBub3Qgc2V0DQojIENPTkZJR19ETUFfTk9OUENJIGlz IG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lERV9NT0RFUz15DQpDT05GSUdf QkxLX0RFVl9BVEFSQUlEPW0NCkNPTkZJR19CTEtfREVWX0FUQVJBSURfUERD PW0NCkNPTkZJR19CTEtfREVWX0FUQVJBSURfSFBUPW0NCg0KIw0KIyBTQ1NJ IHN1cHBvcnQNCiMNCkNPTkZJR19TQ1NJPXkNCg0KIw0KIyBTQ1NJIHN1cHBv cnQgdHlwZSAoZGlzaywgdGFwZSwgQ0QtUk9NKQ0KIw0KQ09ORklHX0JMS19E RVZfU0Q9eQ0KQ09ORklHX1NEX0VYVFJBX0RFVlM9NDANCkNPTkZJR19DSFJf REVWX1NUPW0NCkNPTkZJR19DSFJfREVWX09TU1Q9bQ0KQ09ORklHX0JMS19E RVZfU1I9bQ0KIyBDT05GSUdfQkxLX0RFVl9TUl9WRU5ET1IgaXMgbm90IHNl dA0KQ09ORklHX1NSX0VYVFJBX0RFVlM9Mg0KQ09ORklHX0NIUl9ERVZfU0c9 bQ0KDQojDQojIFNvbWUgU0NTSSBkZXZpY2VzIChlLmcuIENEIGp1a2Vib3gp IHN1cHBvcnQgbXVsdGlwbGUgTFVOcw0KIw0KQ09ORklHX1NDU0lfREVCVUdf UVVFVUVTPXkNCkNPTkZJR19TQ1NJX01VTFRJX0xVTj15DQpDT05GSUdfU0NT SV9DT05TVEFOVFM9eQ0KIyBDT05GSUdfU0NTSV9MT0dHSU5HIGlzIG5vdCBz ZXQNCg0KIw0KIyBTQ1NJIGxvdy1sZXZlbCBkcml2ZXJzDQojDQpDT05GSUdf QkxLX0RFVl8zV19YWFhYX1JBSUQ9bQ0KIyBDT05GSUdfU0NTSV83MDAwRkFT U1QgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9BQ0FSRCBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX0FIQTE1MlggaXMgbm90IHNldA0KIyBDT05GSUdf U0NTSV9BSEExNTQyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfQUhBMTc0 MCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FBQ1JBSUQgaXMgbm90IHNl dA0KIyBDT05GSUdfU0NTSV9BSUM3WFhYIGlzIG5vdCBzZXQNCiMgQ09ORklH X1NDU0lfQUlDN1hYWF9PTEQgaXMgbm90IHNldA0KQ09ORklHX1NDU0lfRFBU X0kyTz1tDQojIENPTkZJR19TQ1NJX0FEVkFOU1lTIGlzIG5vdCBzZXQNCiMg Q09ORklHX1NDU0lfSU4yMDAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lf QU01M0M5NzQgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9NRUdBUkFJRCBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0JVU0xPR0lDIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NDU0lfQ1BRRkNUUyBpcyBub3Qgc2V0DQojIENPTkZJR19T Q1NJX0RNWDMxOTFEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfRFRDMzI4 MCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0VBVEEgaXMgbm90IHNldA0K IyBDT05GSUdfU0NTSV9FQVRBX0RNQSBpcyBub3Qgc2V0DQojIENPTkZJR19T Q1NJX0VBVEFfUElPIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfRlVUVVJF X0RPTUFJTiBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0dEVEggaXMgbm90 IHNldA0KIyBDT05GSUdfU0NTSV9HRU5FUklDX05DUjUzODAgaXMgbm90IHNl dA0KIyBDT05GSUdfU0NTSV9JUFMgaXMgbm90IHNldA0KIyBDT05GSUdfU0NT SV9JTklUSU8gaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9JTklBMTAwIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUFBBIGlzIG5vdCBzZXQNCiMgQ09O RklHX1NDU0lfSU1NIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfTkNSNTND NDA2QSBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX05DUjUzQzd4eCBpcyBu b3Qgc2V0DQpDT05GSUdfU0NTSV9TWU01M0M4WFhfMj15DQpDT05GSUdfU0NT SV9TWU01M0M4WFhfRE1BX0FERFJFU1NJTkdfTU9ERT0xDQpDT05GSUdfU0NT SV9TWU01M0M4WFhfREVGQVVMVF9UQUdTPTE2DQpDT05GSUdfU0NTSV9TWU01 M0M4WFhfTUFYX1RBR1M9NjQNCiMgQ09ORklHX1NDU0lfU1lNNTNDOFhYX0lP TUFQUEVEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUEFTMTYgaXMgbm90 IHNldA0KIyBDT05GSUdfU0NTSV9QQ0kyMDAwIGlzIG5vdCBzZXQNCiMgQ09O RklHX1NDU0lfUENJMjIyMEkgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9Q U0kyNDBJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUUxPR0lDX0ZBUyBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1FMT0dJQ19JU1AgaXMgbm90IHNl dA0KIyBDT05GSUdfU0NTSV9RTE9HSUNfRkMgaXMgbm90IHNldA0KIyBDT05G SUdfU0NTSV9RTE9HSUNfMTI4MCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJ X1NFQUdBVEUgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9TSU03MTAgaXMg bm90IHNldA0KIyBDT05GSUdfU0NTSV9TWU01M0M0MTYgaXMgbm90IHNldA0K IyBDT05GSUdfU0NTSV9EQzM5MFQgaXMgbm90IHNldA0KIyBDT05GSUdfU0NT SV9UMTI4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfVTE0XzM0RiBpcyBu b3Qgc2V0DQojIENPTkZJR19TQ1NJX1VMVFJBU1RPUiBpcyBub3Qgc2V0DQoj IENPTkZJR19TQ1NJX0RFQlVHIGlzIG5vdCBzZXQNCg0KIw0KIyBGdXNpb24g TVBUIGRldmljZSBzdXBwb3J0DQojDQojIENPTkZJR19GVVNJT04gaXMgbm90 IHNldA0KIyBDT05GSUdfRlVTSU9OX0JPT1QgaXMgbm90IHNldA0KIyBDT05G SUdfRlVTSU9OX0lTRU5TRSBpcyBub3Qgc2V0DQojIENPTkZJR19GVVNJT05f Q1RMIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZVU0lPTl9MQU4gaXMgbm90IHNl dA0KDQojDQojIElFRUUgMTM5NCAoRmlyZVdpcmUpIHN1cHBvcnQgKEVYUEVS SU1FTlRBTCkNCiMNCiMgQ09ORklHX0lFRUUxMzk0IGlzIG5vdCBzZXQNCg0K Iw0KIyBJMk8gZGV2aWNlIHN1cHBvcnQNCiMNCkNPTkZJR19JMk89bQ0KQ09O RklHX0kyT19QQ0k9bQ0KQ09ORklHX0kyT19CTE9DSz1tDQpDT05GSUdfSTJP X0xBTj1tDQpDT05GSUdfSTJPX1NDU0k9bQ0KQ09ORklHX0kyT19QUk9DPW0N Cg0KIw0KIyBOZXR3b3JrIGRldmljZSBzdXBwb3J0DQojDQpDT05GSUdfTkVU REVWSUNFUz15DQoNCiMNCiMgQVJDbmV0IGRldmljZXMNCiMNCiMgQ09ORklH X0FSQ05FVCBpcyBub3Qgc2V0DQpDT05GSUdfRFVNTVk9bQ0KQ09ORklHX0JP TkRJTkc9bQ0KIyBDT05GSUdfRVFVQUxJWkVSIGlzIG5vdCBzZXQNCkNPTkZJ R19UVU49bQ0KQ09ORklHX0VUSEVSVEFQPW0NCg0KIw0KIyBFdGhlcm5ldCAo MTAgb3IgMTAwTWJpdCkNCiMNCkNPTkZJR19ORVRfRVRIRVJORVQ9eQ0KIyBD T05GSUdfU1VOTEFOQ0UgaXMgbm90IHNldA0KIyBDT05GSUdfSEFQUFlNRUFM IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NVTkJNQUMgaXMgbm90IHNldA0KIyBD T05GSUdfU1VOUUUgaXMgbm90IHNldA0KIyBDT05GSUdfU1VOR0VNIGlzIG5v dCBzZXQNCiMgQ09ORklHX05FVF9WRU5ET1JfM0NPTSBpcyBub3Qgc2V0DQoj IENPTkZJR19MQU5DRSBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfVkVORE9S X1NNQyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfVkVORE9SX1JBQ0FMIGlz IG5vdCBzZXQNCiMgQ09ORklHX0FUMTcwMCBpcyBub3Qgc2V0DQojIENPTkZJ R19ERVBDQSBpcyBub3Qgc2V0DQojIENPTkZJR19IUDEwMCBpcyBub3Qgc2V0 DQojIENPTkZJR19ORVRfSVNBIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfUENJ PXkNCiMgQ09ORklHX1BDTkVUMzIgaXMgbm90IHNldA0KIyBDT05GSUdfQURB UFRFQ19TVEFSRklSRSBpcyBub3Qgc2V0DQojIENPTkZJR19BQzMyMDAgaXMg bm90IHNldA0KIyBDT05GSUdfQVBSSUNPVCBpcyBub3Qgc2V0DQojIENPTkZJ R19DUzg5eDAgaXMgbm90IHNldA0KQ09ORklHX1RVTElQPXkNCiMgQ09ORklH X1RVTElQX01XSSBpcyBub3Qgc2V0DQojIENPTkZJR19UVUxJUF9NTUlPIGlz IG5vdCBzZXQNCiMgQ09ORklHX0RFNFg1IGlzIG5vdCBzZXQNCiMgQ09ORklH X0RHUlMgaXMgbm90IHNldA0KIyBDT05GSUdfRE05MTAyIGlzIG5vdCBzZXQN CkNPTkZJR19FRVBSTzEwMD15DQojIENPTkZJR19MTkUzOTAgaXMgbm90IHNl dA0KIyBDT05GSUdfRkVBTE5YIGlzIG5vdCBzZXQNCiMgQ09ORklHX05BVFNF TUkgaXMgbm90IHNldA0KIyBDT05GSUdfTkUyS19QQ0kgaXMgbm90IHNldA0K IyBDT05GSUdfTkUzMjEwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VTMzIxMCBp cyBub3Qgc2V0DQojIENPTkZJR184MTM5Q1AgaXMgbm90IHNldA0KQ09ORklH XzgxMzlUT089eQ0KIyBDT05GSUdfODEzOVRPT19QSU8gaXMgbm90IHNldA0K IyBDT05GSUdfODEzOVRPT19UVU5FX1RXSVNURVIgaXMgbm90IHNldA0KIyBD T05GSUdfODEzOVRPT184MTI5IGlzIG5vdCBzZXQNCiMgQ09ORklHXzgxMzlf TkVXX1JYX1JFU0VUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NJUzkwMCBpcyBu b3Qgc2V0DQojIENPTkZJR19FUElDMTAwIGlzIG5vdCBzZXQNCiMgQ09ORklH X1NVTkRBTkNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RMQU4gaXMgbm90IHNl dA0KIyBDT05GSUdfVklBX1JISU5FIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ZJ QV9SSElORV9NTUlPIGlzIG5vdCBzZXQNCiMgQ09ORklHX1dJTkJPTkRfODQw IGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9QT0NLRVQgaXMgbm90IHNldA0K DQojDQojIEV0aGVybmV0ICgxMDAwIE1iaXQpDQojDQojIENPTkZJR19BQ0VO SUMgaXMgbm90IHNldA0KIyBDT05GSUdfREwySyBpcyBub3Qgc2V0DQojIENP TkZJR19NWVJJX1NCVVMgaXMgbm90IHNldA0KIyBDT05GSUdfTlM4MzgyMCBp cyBub3Qgc2V0DQojIENPTkZJR19IQU1BQ0hJIGlzIG5vdCBzZXQNCiMgQ09O RklHX1lFTExPV0ZJTiBpcyBub3Qgc2V0DQojIENPTkZJR19TSzk4TElOIGlz IG5vdCBzZXQNCiMgQ09ORklHX0ZEREkgaXMgbm90IHNldA0KIyBDT05GSUdf SElQUEkgaXMgbm90IHNldA0KIyBDT05GSUdfUExJUCBpcyBub3Qgc2V0DQpD T05GSUdfUFBQPW0NCkNPTkZJR19QUFBfTVVMVElMSU5LPXkNCkNPTkZJR19Q UFBfRklMVEVSPXkNCkNPTkZJR19QUFBfQVNZTkM9bQ0KQ09ORklHX1BQUF9T WU5DX1RUWT1tDQpDT05GSUdfUFBQX0RFRkxBVEU9bQ0KQ09ORklHX1BQUF9C U0RDT01QPW0NCkNPTkZJR19QUFBPRT1tDQojIENPTkZJR19TTElQIGlzIG5v dCBzZXQNCg0KIw0KIyBXaXJlbGVzcyBMQU4gKG5vbi1oYW1yYWRpbykNCiMN CiMgQ09ORklHX05FVF9SQURJTyBpcyBub3Qgc2V0DQoNCiMNCiMgVG9rZW4g UmluZyBkZXZpY2VzDQojDQojIENPTkZJR19UUiBpcyBub3Qgc2V0DQojIENP TkZJR19ORVRfRkMgaXMgbm90IHNldA0KIyBDT05GSUdfUkNQQ0kgaXMgbm90 IHNldA0KIyBDT05GSUdfU0hBUEVSIGlzIG5vdCBzZXQNCg0KIw0KIyBXYW4g aW50ZXJmYWNlcw0KIw0KIyBDT05GSUdfV0FOIGlzIG5vdCBzZXQNCg0KIw0K IyBBbWF0ZXVyIFJhZGlvIHN1cHBvcnQNCiMNCiMgQ09ORklHX0hBTVJBRElP IGlzIG5vdCBzZXQNCg0KIw0KIyBJckRBIChpbmZyYXJlZCkgc3VwcG9ydA0K Iw0KIyBDT05GSUdfSVJEQSBpcyBub3Qgc2V0DQoNCiMNCiMgSVNETiBzdWJz eXN0ZW0NCiMNCiMgQ09ORklHX0lTRE4gaXMgbm90IHNldA0KDQojDQojIE9s ZCBDRC1ST00gZHJpdmVycyAobm90IFNDU0ksIG5vdCBJREUpDQojDQojIENP TkZJR19DRF9OT19JREVTQ1NJIGlzIG5vdCBzZXQNCg0KIw0KIyBJbnB1dCBj b3JlIHN1cHBvcnQNCiMNCkNPTkZJR19JTlBVVD1tDQpDT05GSUdfSU5QVVRf S0VZQkRFVj1tDQpDT05GSUdfSU5QVVRfTU9VU0VERVY9bQ0KQ09ORklHX0lO UFVUX01PVVNFREVWX1NDUkVFTl9YPTEwMjQNCkNPTkZJR19JTlBVVF9NT1VT RURFVl9TQ1JFRU5fWT03NjgNCkNPTkZJR19JTlBVVF9KT1lERVY9bQ0KQ09O RklHX0lOUFVUX0VWREVWPW0NCg0KIw0KIyBDaGFyYWN0ZXIgZGV2aWNlcw0K Iw0KQ09ORklHX1ZUPXkNCkNPTkZJR19WVF9DT05TT0xFPXkNCkNPTkZJR19T RVJJQUw9eQ0KQ09ORklHX1NFUklBTF9DT05TT0xFPXkNCiMgQ09ORklHX1NF UklBTF9BQ1BJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFUklBTF9FWFRFTkRF RCBpcyBub3Qgc2V0DQojIENPTkZJR19TRVJJQUxfTk9OU1RBTkRBUkQgaXMg bm90IHNldA0KQ09ORklHX1VOSVg5OF9QVFlTPXkNCkNPTkZJR19VTklYOThf UFRZX0NPVU5UPTIwNDgNCiMgQ09ORklHX1BSSU5URVIgaXMgbm90IHNldA0K IyBDT05GSUdfUFBERVYgaXMgbm90IHNldA0KDQojDQojIEkyQyBzdXBwb3J0 DQojDQpDT05GSUdfSTJDPW0NCkNPTkZJR19JMkNfQUxHT0JJVD1tDQpDT05G SUdfSTJDX1BISUxJUFNQQVI9bQ0KQ09ORklHX0kyQ19FTFY9bQ0KQ09ORklH X0kyQ19WRUxMRU1BTj1tDQpDT05GSUdfSTJDX0FMR09QQ0Y9bQ0KQ09ORklH X0kyQ19FTEVLVE9SPW0NCkNPTkZJR19JMkNfQ0hBUkRFVj1tDQpDT05GSUdf STJDX1BST0M9bQ0KDQojDQojIE1pY2UNCiMNCiMgQ09ORklHX0JVU01PVVNF IGlzIG5vdCBzZXQNCkNPTkZJR19NT1VTRT15DQpDT05GSUdfUFNNT1VTRT15 DQojIENPTkZJR184MkM3MTBfTU9VU0UgaXMgbm90IHNldA0KIyBDT05GSUdf UEMxMTBfUEFEIGlzIG5vdCBzZXQNCg0KIw0KIyBKb3lzdGlja3MNCiMNCiMg Q09ORklHX0lOUFVUX0dBTUVQT1JUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lO UFVUX05TNTU4IGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX0xJR0hUTklO RyBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9QQ0lHQU1FIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0lOUFVUX0NTNDYxWCBpcyBub3Qgc2V0DQojIENPTkZJ R19JTlBVVF9FTVUxMEsxIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX1NF UklPIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX1NFUlBPUlQgaXMgbm90 IHNldA0KDQojDQojIEpveXN0aWNrcw0KIw0KIyBDT05GSUdfSU5QVVRfQU5B TE9HIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX0EzRCBpcyBub3Qgc2V0 DQojIENPTkZJR19JTlBVVF9BREkgaXMgbm90IHNldA0KIyBDT05GSUdfSU5Q VVRfQ09CUkEgaXMgbm90IHNldA0KIyBDT05GSUdfSU5QVVRfR0YySyBpcyBu b3Qgc2V0DQojIENPTkZJR19JTlBVVF9HUklQIGlzIG5vdCBzZXQNCiMgQ09O RklHX0lOUFVUX0lOVEVSQUNUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVU X1RNREMgaXMgbm90IHNldA0KIyBDT05GSUdfSU5QVVRfU0lERVdJTkRFUiBp cyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9JRk9SQ0VfVVNCIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0lOUFVUX0lGT1JDRV8yMzIgaXMgbm90IHNldA0KIyBD T05GSUdfSU5QVVRfV0FSUklPUiBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBV VF9NQUdFTExBTiBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9TUEFDRU9S QiBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9TUEFDRUJBTEwgaXMgbm90 IHNldA0KIyBDT05GSUdfSU5QVVRfU1RJTkdFUiBpcyBub3Qgc2V0DQojIENP TkZJR19JTlBVVF9EQjkgaXMgbm90IHNldA0KIyBDT05GSUdfSU5QVVRfR0FN RUNPTiBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9UVVJCT0dSQUZYIGlz IG5vdCBzZXQNCiMgQ09ORklHX1FJQzAyX1RBUEUgaXMgbm90IHNldA0KDQoj DQojIFdhdGNoZG9nIENhcmRzDQojDQpDT05GSUdfV0FUQ0hET0c9eQ0KIyBD T05GSUdfV0FUQ0hET0dfTk9XQVlPVVQgaXMgbm90IHNldA0KQ09ORklHX1NP RlRfV0FUQ0hET0c9bQ0KIyBDT05GSUdfV0RUIGlzIG5vdCBzZXQNCiMgQ09O RklHX1dEVFBDSSBpcyBub3Qgc2V0DQojIENPTkZJR19QQ1dBVENIRE9HIGlz IG5vdCBzZXQNCiMgQ09ORklHX0FDUVVJUkVfV0RUIGlzIG5vdCBzZXQNCiMg Q09ORklHX0FEVkFOVEVDSF9XRFQgaXMgbm90IHNldA0KIyBDT05GSUdfRVVS T1RFQ0hfV0RUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lCNzAwX1dEVCBpcyBu b3Qgc2V0DQojIENPTkZJR19JODEwX1RDTyBpcyBub3Qgc2V0DQojIENPTkZJ R19NSVhDT01XRCBpcyBub3Qgc2V0DQojIENPTkZJR182MFhYX1dEVCBpcyBu b3Qgc2V0DQojIENPTkZJR19XODM4NzdGX1dEVCBpcyBub3Qgc2V0DQojIENP TkZJR19NQUNIWl9XRFQgaXMgbm90IHNldA0KQ09ORklHX0lOVEVMX1JORz1t DQojIENPTkZJR19OVlJBTSBpcyBub3Qgc2V0DQpDT05GSUdfUlRDPXkNCiMg Q09ORklHX0RUTEsgaXMgbm90IHNldA0KIyBDT05GSUdfUjM5NjQgaXMgbm90 IHNldA0KIyBDT05GSUdfQVBQTElDT00gaXMgbm90IHNldA0KIyBDT05GSUdf U09OWVBJIGlzIG5vdCBzZXQNCg0KIw0KIyBGdGFwZSwgdGhlIGZsb3BweSB0 YXBlIGRldmljZSBkcml2ZXINCiMNCiMgQ09ORklHX0ZUQVBFIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0FHUCBpcyBub3Qgc2V0DQojIENPTkZJR19EUk0gaXMg bm90IHNldA0KIyBDT05GSUdfTVdBVkUgaXMgbm90IHNldA0KDQojDQojIE11 bHRpbWVkaWEgZGV2aWNlcw0KIw0KIyBDT05GSUdfVklERU9fREVWIGlzIG5v dCBzZXQNCg0KIw0KIyBGaWxlIHN5c3RlbXMNCiMNCkNPTkZJR19RVU9UQT15 DQpDT05GSUdfRlNfUE9TSVhfQUNMPXkNCiMgQ09ORklHX0FVVE9GU19GUyBp cyBub3Qgc2V0DQpDT05GSUdfQVVUT0ZTNF9GUz15DQpDT05GSUdfUkVJU0VS RlNfRlM9bQ0KIyBDT05GSUdfUkVJU0VSRlNfQ0hFQ0sgaXMgbm90IHNldA0K Q09ORklHX1JFSVNFUkZTX1BST0NfSU5GTz15DQojIENPTkZJR19BREZTX0ZT IGlzIG5vdCBzZXQNCiMgQ09ORklHX0FERlNfRlNfUlcgaXMgbm90IHNldA0K IyBDT05GSUdfQUZGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19IRlNfRlMg aXMgbm90IHNldA0KIyBDT05GSUdfQkZTX0ZTIGlzIG5vdCBzZXQNCkNPTkZJ R19FWFQzX0ZTPW0NCkNPTkZJR19KQkQ9bQ0KIyBDT05GSUdfSkJEX0RFQlVH IGlzIG5vdCBzZXQNCkNPTkZJR19GQVRfRlM9bQ0KQ09ORklHX01TRE9TX0ZT PW0NCiMgQ09ORklHX1VNU0RPU19GUyBpcyBub3Qgc2V0DQpDT05GSUdfVkZB VF9GUz1tDQojIENPTkZJR19FRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdf SkZGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19KRkZTMl9GUyBpcyBub3Qg c2V0DQojIENPTkZJR19DUkFNRlMgaXMgbm90IHNldA0KQ09ORklHX1RNUEZT PXkNCiMgQ09ORklHX1JBTUZTIGlzIG5vdCBzZXQNCkNPTkZJR19JU085NjYw X0ZTPXkNCkNPTkZJR19KT0xJRVQ9eQ0KQ09ORklHX1pJU09GUz15DQpDT05G SUdfTUlOSVhfRlM9bQ0KQ09ORklHX1ZYRlNfRlM9bQ0KQ09ORklHX05URlNf RlM9bQ0KQ09ORklHX05URlNfUlc9eQ0KQ09ORklHX0hQRlNfRlM9bQ0KQ09O RklHX1BST0NfRlM9eQ0KIyBDT05GSUdfREVWRlNfRlMgaXMgbm90IHNldA0K IyBDT05GSUdfREVWRlNfTU9VTlQgaXMgbm90IHNldA0KIyBDT05GSUdfREVW RlNfREVCVUcgaXMgbm90IHNldA0KQ09ORklHX0RFVlBUU19GUz15DQojIENP TkZJR19RTlg0RlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfUU5YNEZTX1JX IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JPTUZTX0ZTIGlzIG5vdCBzZXQNCkNP TkZJR19FWFQyX0ZTPW0NCiMgQ09ORklHX1NZU1ZfRlMgaXMgbm90IHNldA0K IyBDT05GSUdfVURGX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VERl9SVyBp cyBub3Qgc2V0DQojIENPTkZJR19VRlNfRlMgaXMgbm90IHNldA0KIyBDT05G SUdfVUZTX0ZTX1dSSVRFIGlzIG5vdCBzZXQNCkNPTkZJR19YRlNfRlM9eQ0K Q09ORklHX1hGU19SVD15DQpDT05GSUdfWEZTX1FVT1RBPXkNCiMgQ09ORklH X1hGU19ETUFQSSBpcyBub3Qgc2V0DQoNCiMNCiMgTmV0d29yayBGaWxlIFN5 c3RlbXMNCiMNCkNPTkZJR19DT0RBX0ZTPW0NCkNPTkZJR19JTlRFUk1FWlpP X0ZTPW0NCkNPTkZJR19ORlNfRlM9eQ0KQ09ORklHX05GU19WMz15DQojIENP TkZJR19ST09UX05GUyBpcyBub3Qgc2V0DQpDT05GSUdfTkZTRD15DQpDT05G SUdfTkZTRF9WMz15DQpDT05GSUdfU1VOUlBDPXkNCkNPTkZJR19MT0NLRD15 DQpDT05GSUdfTE9DS0RfVjQ9eQ0KQ09ORklHX1NNQl9GUz1tDQpDT05GSUdf U01CX05MU19ERUZBVUxUPXkNCkNPTkZJR19TTUJfTkxTX1JFTU9URT0iY3A0 MzciDQojIENPTkZJR19OQ1BfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfTkNQ RlNfUEFDS0VUX1NJR05JTkcgaXMgbm90IHNldA0KIyBDT05GSUdfTkNQRlNf SU9DVExfTE9DS0lORyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BGU19TVFJP TkcgaXMgbm90IHNldA0KIyBDT05GSUdfTkNQRlNfTkZTX05TIGlzIG5vdCBz ZXQNCiMgQ09ORklHX05DUEZTX09TMl9OUyBpcyBub3Qgc2V0DQojIENPTkZJ R19OQ1BGU19TTUFMTERPUyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BGU19O TFMgaXMgbm90IHNldA0KIyBDT05GSUdfTkNQRlNfRVhUUkFTIGlzIG5vdCBz ZXQNCkNPTkZJR19aSVNPRlNfRlM9eQ0KQ09ORklHX1pMSUJfRlNfSU5GTEFU RT15DQoNCiMNCiMgUGFydGl0aW9uIFR5cGVzDQojDQpDT05GSUdfUEFSVElU SU9OX0FEVkFOQ0VEPXkNCiMgQ09ORklHX0FDT1JOX1BBUlRJVElPTiBpcyBu b3Qgc2V0DQojIENPTkZJR19PU0ZfUEFSVElUSU9OIGlzIG5vdCBzZXQNCiMg Q09ORklHX0FNSUdBX1BBUlRJVElPTiBpcyBub3Qgc2V0DQojIENPTkZJR19B VEFSSV9QQVJUSVRJT04gaXMgbm90IHNldA0KIyBDT05GSUdfTUFDX1BBUlRJ VElPTiBpcyBub3Qgc2V0DQpDT05GSUdfTVNET1NfUEFSVElUSU9OPXkNCkNP TkZJR19CU0RfRElTS0xBQkVMPXkNCiMgQ09ORklHX01JTklYX1NVQlBBUlRJ VElPTiBpcyBub3Qgc2V0DQpDT05GSUdfU09MQVJJU19YODZfUEFSVElUSU9O PXkNCiMgQ09ORklHX1VOSVhXQVJFX0RJU0tMQUJFTCBpcyBub3Qgc2V0DQpD T05GSUdfTERNX1BBUlRJVElPTj15DQpDT05GSUdfTERNX0RFQlVHPXkNCiMg Q09ORklHX1NHSV9QQVJUSVRJT04gaXMgbm90IHNldA0KIyBDT05GSUdfVUxU UklYX1BBUlRJVElPTiBpcyBub3Qgc2V0DQpDT05GSUdfU1VOX1BBUlRJVElP Tj15DQpDT05GSUdfU01CX05MUz15DQpDT05GSUdfTkxTPXkNCg0KIw0KIyBO YXRpdmUgTGFuZ3VhZ2UgU3VwcG9ydA0KIw0KQ09ORklHX05MU19ERUZBVUxU PSJpc284ODU5LTEiDQpDT05GSUdfTkxTX0NPREVQQUdFXzQzNz15DQpDT05G SUdfTkxTX0NPREVQQUdFXzczNz1tDQpDT05GSUdfTkxTX0NPREVQQUdFXzc3 NT1tDQpDT05GSUdfTkxTX0NPREVQQUdFXzg1MD1tDQpDT05GSUdfTkxTX0NP REVQQUdFXzg1Mj1tDQpDT05GSUdfTkxTX0NPREVQQUdFXzg1NT1tDQpDT05G SUdfTkxTX0NPREVQQUdFXzg1Nz1tDQpDT05GSUdfTkxTX0NPREVQQUdFXzg2 MD1tDQpDT05GSUdfTkxTX0NPREVQQUdFXzg2MT1tDQpDT05GSUdfTkxTX0NP REVQQUdFXzg2Mj1tDQpDT05GSUdfTkxTX0NPREVQQUdFXzg2Mz1tDQpDT05G SUdfTkxTX0NPREVQQUdFXzg2ND1tDQpDT05GSUdfTkxTX0NPREVQQUdFXzg2 NT1tDQpDT05GSUdfTkxTX0NPREVQQUdFXzg2Nj1tDQpDT05GSUdfTkxTX0NP REVQQUdFXzg2OT1tDQpDT05GSUdfTkxTX0NPREVQQUdFXzkzNj1tDQpDT05G SUdfTkxTX0NPREVQQUdFXzk1MD1tDQpDT05GSUdfTkxTX0NPREVQQUdFXzkz Mj1tDQpDT05GSUdfTkxTX0NPREVQQUdFXzk0OT1tDQpDT05GSUdfTkxTX0NP REVQQUdFXzg3ND1tDQpDT05GSUdfTkxTX0lTTzg4NTlfOD1tDQojIENPTkZJ R19OTFNfQ09ERVBBR0VfMTI1MCBpcyBub3Qgc2V0DQpDT05GSUdfTkxTX0NP REVQQUdFXzEyNTE9bQ0KQ09ORklHX05MU19JU084ODU5XzE9eQ0KQ09ORklH X05MU19JU084ODU5XzI9bQ0KQ09ORklHX05MU19JU084ODU5XzM9bQ0KQ09O RklHX05MU19JU084ODU5XzQ9bQ0KQ09ORklHX05MU19JU084ODU5XzU9bQ0K Q09ORklHX05MU19JU084ODU5XzY9bQ0KQ09ORklHX05MU19JU084ODU5Xzc9 bQ0KQ09ORklHX05MU19JU084ODU5Xzk9bQ0KQ09ORklHX05MU19JU084ODU5 XzEzPW0NCkNPTkZJR19OTFNfSVNPODg1OV8xND1tDQpDT05GSUdfTkxTX0lT Tzg4NTlfMTU9bQ0KQ09ORklHX05MU19LT0k4X1I9bQ0KQ09ORklHX05MU19L T0k4X1U9bQ0KQ09ORklHX05MU19VVEY4PXkNCg0KIw0KIyBDb25zb2xlIGRy aXZlcnMNCiMNCkNPTkZJR19WR0FfQ09OU09MRT15DQojIENPTkZJR19WSURF T19TRUxFQ1QgaXMgbm90IHNldA0KIyBDT05GSUdfTURBX0NPTlNPTEUgaXMg bm90IHNldA0KDQojDQojIEZyYW1lLWJ1ZmZlciBzdXBwb3J0DQojDQojIENP TkZJR19GQiBpcyBub3Qgc2V0DQoNCiMNCiMgU291bmQNCiMNCiMgQ09ORklH X1NPVU5EIGlzIG5vdCBzZXQNCg0KIw0KIyBVU0Igc3VwcG9ydA0KIw0KIyBD T05GSUdfVVNCIGlzIG5vdCBzZXQNCg0KIw0KIyBVU0IgQ29udHJvbGxlcnMN CiMNCiMgQ09ORklHX1VTQl9VSENJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT Ql9VSENJX0FMVCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfT0hDSSBpcyBu b3Qgc2V0DQoNCiMNCiMgVVNCIERldmljZSBDbGFzcyBkcml2ZXJzDQojDQoj IENPTkZJR19VU0JfQVVESU8gaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0JM VUVUT09USCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFHRSBpcyBu b3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFHRV9ERUJVRyBpcyBub3Qgc2V0 DQojIENPTkZJR19VU0JfU1RPUkFHRV9EQVRBRkFCIGlzIG5vdCBzZXQNCiMg Q09ORklHX1VTQl9TVE9SQUdFX0ZSRUVDT00gaXMgbm90IHNldA0KIyBDT05G SUdfVVNCX1NUT1JBR0VfSVNEMjAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT Ql9TVE9SQUdFX0RQQ00gaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NUT1JB R0VfSFA4MjAwZSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFHRV9T RERSMDkgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NUT1JBR0VfSlVNUFNI T1QgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0FDTSBpcyBub3Qgc2V0DQoj IENPTkZJR19VU0JfUFJJTlRFUiBpcyBub3Qgc2V0DQoNCiMNCiMgVVNCIEh1 bWFuIEludGVyZmFjZSBEZXZpY2VzIChISUQpDQojDQojIENPTkZJR19VU0Jf SElEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9ISURERVYgaXMgbm90IHNl dA0KIyBDT05GSUdfVVNCX0tCRCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0Jf TU9VU0UgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1dBQ09NIGlzIG5vdCBz ZXQNCg0KIw0KIyBVU0IgSW1hZ2luZyBkZXZpY2VzDQojDQojIENPTkZJR19V U0JfREMyWFggaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX01EQzgwMCBpcyBu b3Qgc2V0DQojIENPTkZJR19VU0JfU0NBTk5FUiBpcyBub3Qgc2V0DQojIENP TkZJR19VU0JfTUlDUk9URUsgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX0hQ VVNCU0NTSSBpcyBub3Qgc2V0DQoNCiMNCiMgVVNCIE11bHRpbWVkaWEgZGV2 aWNlcw0KIw0KDQojDQojICAgVmlkZW80TGludXggc3VwcG9ydCBpcyBuZWVk ZWQgZm9yIFVTQiBNdWx0aW1lZGlhIGRldmljZSBzdXBwb3J0DQojDQoNCiMN CiMgVVNCIE5ldHdvcmsgYWRhcHRvcnMNCiMNCiMgQ09ORklHX1VTQl9QRUdB U1VTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9LQVdFVEggaXMgbm90IHNl dA0KIyBDT05GSUdfVVNCX0NBVEMgaXMgbm90IHNldA0KIyBDT05GSUdfVVNC X0NEQ0VUSEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9VU0JORVQgaXMg bm90IHNldA0KDQojDQojIFVTQiBwb3J0IGRyaXZlcnMNCiMNCiMgQ09ORklH X1VTQl9VU1M3MjAgaXMgbm90IHNldA0KDQojDQojIFVTQiBTZXJpYWwgQ29u dmVydGVyIHN1cHBvcnQNCiMNCiMgQ09ORklHX1VTQl9TRVJJQUwgaXMgbm90 IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9HRU5FUklDIGlzIG5vdCBzZXQN CiMgQ09ORklHX1VTQl9TRVJJQUxfQkVMS0lOIGlzIG5vdCBzZXQNCiMgQ09O RklHX1VTQl9TRVJJQUxfV0hJVEVIRUFUIGlzIG5vdCBzZXQNCiMgQ09ORklH X1VTQl9TRVJJQUxfRElHSV9BQ0NFTEVQT1JUIGlzIG5vdCBzZXQNCiMgQ09O RklHX1VTQl9TRVJJQUxfRU1QRUcgaXMgbm90IHNldA0KIyBDT05GSUdfVVNC X1NFUklBTF9GVERJX1NJTyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VS SUFMX1ZJU09SIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfSVBB USBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0lSIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfRURHRVBPUlQgaXMgbm90IHNldA0K IyBDT05GSUdfVVNCX1NFUklBTF9LRVlTUEFOX1BEQSBpcyBub3Qgc2V0DQoj IENPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU4gaXMgbm90IHNldA0KIyBDT05G SUdfVVNCX1NFUklBTF9LRVlTUEFOX1VTQTI4IGlzIG5vdCBzZXQNCiMgQ09O RklHX1VTQl9TRVJJQUxfS0VZU1BBTl9VU0EyOFggaXMgbm90IHNldA0KIyBD T05GSUdfVVNCX1NFUklBTF9LRVlTUEFOX1VTQTI4WEEgaXMgbm90IHNldA0K IyBDT05GSUdfVVNCX1NFUklBTF9LRVlTUEFOX1VTQTI4WEIgaXMgbm90IHNl dA0KIyBDT05GSUdfVVNCX1NFUklBTF9LRVlTUEFOX1VTQTE5IGlzIG5vdCBz ZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfS0VZU1BBTl9VU0ExOFggaXMgbm90 IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9LRVlTUEFOX1VTQTE5VyBpcyBu b3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU5fVVNBNDlXIGlz IG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfTUNUX1UyMzIgaXMgbm90 IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9LTFNJIGlzIG5vdCBzZXQNCiMg Q09ORklHX1VTQl9TRVJJQUxfUEwyMzAzIGlzIG5vdCBzZXQNCiMgQ09ORklH X1VTQl9TRVJJQUxfQ1lCRVJKQUNLIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT Ql9TRVJJQUxfWElSQ09NIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJ QUxfT01OSU5FVCBpcyBub3Qgc2V0DQoNCiMNCiMgVVNCIE1pc2NlbGxhbmVv dXMgZHJpdmVycw0KIw0KIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qgc2V0 DQoNCiMNCiMgQmx1ZXRvb3RoIHN1cHBvcnQNCiMNCiMgQ09ORklHX0JMVUVa IGlzIG5vdCBzZXQNCg0KIw0KIyBLZXJuZWwgaGFja2luZw0KIw0KQ09ORklH X0RFQlVHX0tFUk5FTD15DQojIENPTkZJR19ERUJVR19ISUdITUVNIGlzIG5v dCBzZXQNCiMgQ09ORklHX0RFQlVHX1NMQUIgaXMgbm90IHNldA0KIyBDT05G SUdfREVCVUdfSU9WSVJUIGlzIG5vdCBzZXQNCkNPTkZJR19NQUdJQ19TWVNS UT15DQpDT05GSUdfREVCVUdfU1BJTkxPQ0s9eQ0KQ09ORklHX0RFQlVHX0JV R1ZFUkJPU0U9eQ0KIyBDT05GSUdfS0RCIGlzIG5vdCBzZXQNCiMgQ09ORklH X0tEQl9NT0RVTEVTIGlzIG5vdCBzZXQNCkNPTkZJR19LQUxMU1lNUz15DQoj IENPTkZJR19GUkFNRV9QT0lOVEVSIGlzIG5vdCBzZXQNCg== --168484060-701792593-1015252673=:3674-- From owner-linux-xfs@oss.sgi.com Mon Mar 4 08:06:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24G6Pf17152 for linux-xfs-outgoing; Mon, 4 Mar 2002 08:06:25 -0800 Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24G6D917124 for ; Mon, 4 Mar 2002 08:06:13 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 5C007C001C2; Mon, 4 Mar 2002 23:06:09 +0800 (PHT) Received: from cache.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id D85C7C001C1; Mon, 4 Mar 2002 23:06:01 +0800 (PHT) Date: Mon, 4 Mar 2002 23:06:01 +0800 (PHT) From: Federico Sevilla III To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= Cc: Linux XFS Mailing List , Samba Mailing List Subject: Re: samba oplocks problem In-Reply-To: <20020304145027.GA15933@venus.local.navi.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id g24G6E917126 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Olaf, (cc XFS and Samba lists) On Mon, 4 Mar 2002 at 15:50, Olaf Frączyk wrote: > I have similar problems, (with doc and xls) but I don't have file > corruption (I hope :) We hope. I've turned off oplocks with my Samba completely just to be sure. Things haven't slowed down that drastically, but perhaps it's because the load isn't as high as with some other much larger installations. > But I suspect Win2k with SP2. Could you check in log, if the problem > first takes place on win2k machine, and after on other? We only have Microsoft Windows 95/98/ME clients here. No Windows2000. > BTW, I also posted several times, but got no reply. :( > I also have XFS, today changed from 2.4.17-cvs to 2.4.18-cvs. But the > problem persist. (I had to upgrade because cyrus-imap was dying under > 2.4.17 - ugly). May be it is problem with XFS? (I had strange problems > with vmware+XFS). But I'm not sure if it is related to xfs, as somebody > had similar problem with suse with kernel 2.4.10. Or may be SUSE has XFS > compiled in? I doubt it's a problem with XFS. Samba is an almost purely userland tool (except for smbfs), and if it were running into problems with the filesystem, I'd expect we'd see more logs especially in the kernel side from XFS, not to mention more "universal/global" data corruption. As things are here the data corruption is quite sparse. An oplock_break failure doesn't guarantee data corruption. It seems to require that oplock_breaks happen consecutively at a particular rate on the same file. Or something like that. :( Anyway, no data corruption so far since oplocks have been turned off. I've been told whatever problem it is I'm running into has been solved in Samba's CVS. Perhaps the next release (post 2.2.3a) will bring the possibility of turning oplocks back on. --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: http://jijo.leathercollection.ph/jijo.gpg From owner-linux-xfs@oss.sgi.com Mon Mar 4 08:24:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24GOtt17618 for linux-xfs-outgoing; Mon, 4 Mar 2002 08:24:55 -0800 Received: from cellus.no (www.smssiden.com [193.91.191.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24GOS917588 for ; Mon, 4 Mar 2002 08:24:28 -0800 Received: from christian ([193.69.127.56]) by cellus.no (8.9.3/8.9.3) with SMTP id QAA08951 for ; Mon, 4 Mar 2002 16:24:24 +0100 From: =?iso-8859-1?Q?Christian_R=F8snes?= To: Subject: RE: Linux 2.4.18 freeze running dbench 1.3 Date: Mon, 4 Mar 2002 16:24:28 +0100 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk To follow up: I tested dbench on an ext2 partition (/home) on the same server, and it worked. dbench on the XFS /usr partition still crashes the server. This kernel was made with gcc 2.96. (I also tested dbench with a kgcc - gcc 2.91.66 compiled kernel. SEE BELOW) --------------------------- EXT2 PARTITION /home ------------------------- with gcc version 2.96 root@dl02 root]# cd /home/dbench [root@dl02 dbench]# ./dbench 10 10 clients started ............................................................................ ...* Throughput 173.955 MB/sec (NB=217.443 MB/sec 1739.55 MBit/sec) 10 procs [root@dl02 dbench]# ./dbench 10 ..........10 clients started ............................................................................ ...* Throughput 207.96 MB/sec (NB=259.949 MB/sec 2079.6 MBit/sec) 10 procs [root@dl02 dbench]# ./dbench 10 ..........10 clients started ............................................................................ ...* Throughput 207.656 MB/sec (NB=259.57 MB/sec 2076.56 MBit/sec) 10 procs [root@dl02 dbench]# ./dbench 10 ........10 clients started ............................................................................ ...* Throughput 206.644 MB/sec (NB=258.305 MB/sec 2066.44 MBit/sec) 10 procs [root@dl02 dbench]# ./dbench 10 ........10 clients started ............................................................................ ...* Throughput 207.308 MB/sec (NB=259.135 MB/sec 2073.08 MBit/sec) 10 procs [root@dl02 dbench]# ./dbench 10 ..........10 clients started ............................................................................ ...* Throughput 205.681 MB/sec (NB=257.101 MB/sec 2056.81 MBit/sec) 10 procs --------------------------- XFS PARTITION /usr ------------------------- with gcc version 2.96 [root@dl02 dbench]# cd /usr/src/dbench [root@dl02 dbench]# ./dbench 10 bash: ./dbench: cannot execute binary file [root@dl02 dbench]# ./dbench 10 10 clients started ....invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010086 eax: 0000004a ebx: f7574800 ecx: c03bbe24 edx: 00002f1d esi: 00000297 edi: f75748f0 ebp: 00000000 esp: f621fab8 ds: 0018 es: 0018 ss: 0018 Process dbench (pid: 1240, stackpage=f621f000) Stack: c02ee260 0000005a 00000010 00000005 f7574800 f621fcb0 c01b5974 f7574800 0000001e ffffffeb 00000000 00000000 f621fbac f621fbb0 f621fbd8 f621fbb8 00000000 c01b568b f5c0fa18 00000070 00000000 00000000 00000000 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [ [] [] [] [] [] [ [] [] [] [] Code: 0f 0b 5f 58 c6 83 f0 00 00 00 01 56 9d 89 e8 5b 5e 5f 5d c3 Entering kdb (current=0xf621e000, pid 1240) on processor 0 Oops: invalid operand due to oops @ 0xc01e8437 eax = 0x0000004a ebx = 0xf7574800 ecx = 0xc03bbe24 edx = 0x00002f1d esi = 0x00000297 edi = 0xf75748f0 esp = 0xf621fab8 eip = 0xc01e8437 ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086 xds = 0xc02e0018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf621fa84 [0]kdb> bt EBP EIP Function(args) 0xc01e8437 xfs_mod_incore_sb+0x97 (0xf7574800, 0x1e, 0xffffffeb, 0x0) kernel .text 0xc0100000 0xc01e83a0 0xc01e8450 0xf621fcb0 0xc01b5974 xfs_bmapi+0x634 (0xf5c0fa30, 0x70000, 0x0, 0x10000, 0x2) kernel .text 0xc0100000 0xc01b5340 0xc01b6550 0xc02024ce linvfs_pb_bmap+0x6e (0xf5c0fa30, 0xf621ff4c, 0x2, 0x0, 0x) kernel .text 0xc0100000 0xc0202460 0xc02025b0 0xc01ff419 linvfs_write+0x2b9 (0xf6db0174, 0x804bde0, 0xffc3, 0xf6db) kernel .text 0xc0100000 0xc01ff160 0xc01ff470 0xc0145a26 sys_write+0x96 (0x6, 0x804bde0, 0xffc3, 0x10, 0x105e) kernel .text 0xc0100000 0xc0145990 0xc0145b50 0xc01078ab system_call+0x33 kernel .text 0xc0100000 0xc0107878 0xc01078b0 [0]kdb> cpu 1 Entering kdb (current=0xf5c6c000, pid 1243) on processor 1 due to cpu switch [1]kdb> bt EBP EIP Function(args) 0xc01e8c31 _text_lock_xfs_mount+0xd (0xf5c07e18, 0x20000, 0x0, 0x100) kernel .text 0xc0100000 0xc01e8c24 0xc01e8ca0 0xc02024ce linvfs_pb_bmap+0x6e (0xf5c07e18, 0xf5c6df4c, 0x2, 0x0, 0x) kernel .text 0xc0100000 0xc0202460 0xc02025b0 0xc01ff419 linvfs_write+0x2b9 (0xf6db0414, 0x804bde0, 0xffc3, 0xf6db) kernel .text 0xc0100000 0xc01ff160 0xc01ff470 0xc0145a26 sys_write+0x96 (0x6, 0x804bde0, 0xffc3, 0x10, 0x105c) kernel .text 0xc0100000 0xc0145990 0xc0145b50 0xc01078ab system_call+0x33 kernel .text 0xc0100000 0xc0107878 0xc01078b0 ------------ Kernel compiled with kgcc - gcc version 2.91.66 ------------ I recompiled it with kgcc (version 2.91.66) - and dbench on the XFS partition /usr still crashes the server ******************* /usr XFS partition: ******************* [root@dl02 dbench]# ./dbench 10 ..10 clients started ...invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010086 eax: 0000004a ebx: f757b4f0 ecx: c03edb44 edx: 00002f09 esi: 00000297 edi: f757b400 ebp: 00000000 esp: f5e93a5c ds: 0018 es: 0018 ss: 0018 Process dbench (pid: 1247, stackpage=f5e93000) Stack: c0315a80 0000005a 00000000 00000005 00000010 f5e93cc0 c01bb04d f757b400 0000001e ffffffeb 00000000 00000010 00000000 c01ba988 f5e93cc0 00000001 00000000 00000000 f76a2c68 00000000 f5e93b60 00000000 fffe0005 00000010 Call Trace: [] [] [] [] [] [] [] [] [] [] [ [] [] [] [] [] [ [] [] [] [] [] [ Code: 0f 0b 83 c4 08 8d 74 26 00 c6 87 f0 00 00 00 01 56 9d 89 e8 Entering kdb (current=0xf5e92000, pid 1247) on processor 0 Oops: invalid operand due to oops @ 0xc01f1c47 eax = 0x0000004a ebx = 0xf757b4f0 ecx = 0xc03edb44 edx = 0x00002f09 esi = 0x00000297 edi = 0xf757b400 esp = 0xf5e93a5c eip = 0xc01f1c47 ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086 xds = 0xc0310018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf5e93a28 [0]kdb> bt EBP EIP Function(args) 0xc01f1c47 xfs_mod_incore_sb+0x93 (0xf757b400, 0x1e, 0xffffffeb, 0x0) kernel .text 0xc0100000 0xc01f1bb4 0xc01f1c60 0xf5e93cc0 0xc01bb04d xfs_bmapi+0x6c5 (0x0, 0xf6dc2670, 0x80, 0x0, 0x10) kernel .text 0xc0100000 0xc01ba988 0xc01bbca4 0xc020fc49 xfs_iomap_write_delay+0x64d (0xf6dc2670, 0xc4, 0xf6dc27a8) kernel .text 0xc0100000 0xc020f5fc 0xc020fe8c 0xc020d8b8 xfs_zero_last_block+0x680 (0xf63dfdcc, 0x80000, 0x0, 0x10) kernel .text 0xc0100000 0xc020d238 0xc020d8e0 0xc0208259 _pagebuf_file_write+0xf1 (0xf628b9c4, 0x804bde8, 0xffbb, ) kernel .text 0xc0100000 0xc0208168 0xc0208390 0xc0208453 pagebuf_generic_file_write+0xc3 (0xf628b9c4, 0x804bde8, 0) kernel .text 0xc0100000 0xc0208390 0xc02086fc 0xc020e0bf xfs_write+0x2bb (0xf6dc2688, 0xf5e93f7c, 0x2, 0x0, 0x0) kernel .text 0xc0100000 0xc020de04 0xc020e320 0xc0209a6e linvfs_write+0x2fe (0xf628b9c4, 0x804bde0, 0xffc3, 0xf628) kernel .text 0xc0100000 0xc0209770 0xc0209abc 0xc0145717 sys_write+0x8f (0x6, 0x804bde0, 0xffc3, 0x10, 0x105d) kernel .text 0xc0100000 0xc0145688 0xc0145858 0xc01077bb system_call+0x33 kernel .text 0xc0100000 0xc0107788 0xc01077c0 [0]kdb> cpu 1 Entering kdb (current=0xf6d6a000, pid 1244) on processor 1 due to cpu switch [1]kdb> bt EBP EIP Function(args) 0xc01f242a _text_lock_xfs_mount+0xc (0x0, 0xf5e68228, 0xc0, 0x0, 0x1) kernel .text 0xc0100000 0xc01f241e 0xc01f2480 0xc020fc49 xfs_iomap_write_delay+0x64d (0xf5e68228, 0xc4, 0xf5e68360) kernel .text 0xc0100000 0xc020f5fc 0xc020fe8c 0xc020d8b8 xfs_zero_last_block+0x680 (0xf662c45c, 0xc0000, 0x0, 0x10) kernel .text 0xc0100000 0xc020d238 0xc020d8e0 0xc0208259 _pagebuf_file_write+0xf1 (0xf63b0bb4, 0x804bdec, 0xffb7, ) kernel .text 0xc0100000 0xc0208168 0xc0208390 0xc0208453 pagebuf_generic_file_write+0xc3 (0xf63b0bb4, 0x804bdec, 0) kernel .text 0xc0100000 0xc0208390 0xc02086fc 0xc020e0bf xfs_write+0x2bb (0xf5e68240, 0xf6d6bf7c, 0x2, 0x0, 0x0) kernel .text 0xc0100000 0xc020de04 0xc020e320 0xc0209a6e linvfs_write+0x2fe (0xf63b0bb4, 0x804bde0, 0xffc3, 0xf63b) kernel .text 0xc0100000 0xc0209770 0xc0209abc 0xc0145717 sys_write+0x8f (0x6, 0x804bde0, 0xffc3, 0x10, 0x105e) kernel .text 0xc0100000 0xc0145688 0xc0145858 0xc01077bb system_call+0x33 kernel .text 0xc0100000 0xc0107788 0xc01077c0 [1]kdb> From owner-linux-xfs@oss.sgi.com Mon Mar 4 08:56:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24GuwW18326 for linux-xfs-outgoing; Mon, 4 Mar 2002 08:56:58 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24Gup918303 for ; Mon, 4 Mar 2002 08:56:51 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA11046 for ; Mon, 4 Mar 2002 07:52:22 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA00513; Mon, 4 Mar 2002 09:55:34 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA51121; Mon, 4 Mar 2002 09:55:34 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g24Fsje23562; Mon, 4 Mar 2002 09:54:45 -0600 Subject: RE: Linux 2.4.18 freeze running dbench 1.3 From: Steve Lord To: Christian =?ISO-8859-1?Q?R=F8snes?= Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.2 Date: 04 Mar 2002 09:54:45 -0600 Message-Id: <1015257285.21528.55.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g24Gup918304 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-04 at 09:24, Christian Rřsnes wrote: > > To follow up: > > I tested dbench on an ext2 partition (/home) on the same server, > and it worked. dbench on the XFS /usr partition still crashes the server. > This kernel was made with gcc 2.96. Let me confirm something here - you originally reported a complete hang when running with xfs. Keith asked you to run with the nmi oopser enabled - is this oops coming out after your turned on the oopser enabled (nmi_watchdog=1 on the kernel boot line)? If this is the case I think I can deduce the lock xfs has got hung up on - and safely say I have never seen this before. I may try and come up with some tracing code for this one, it looks like a spinlock leak on the superblock counters. Could you possibly try this: Edit fs/xfs/Makefile and fs/xfs/linux/Makefile, look for the line like this: EXTRA_CFLAGS += -I. -funsigned-char (It is a little different in the xfs/linux/Makefile) Remove the -funsigned-char Also remove all the .o files in the xfs directories after doing this. Now in the config tool, turn on spinlock debugging in the kernel and try running xfs again. You have to remove the -funsigned-char to make xfs function with spinlock debugging. We know it mostly works this way, but it has not had much exposure. Hopefully this will report some misuse of the lock somewhere. Thanks Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Mar 4 10:26:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24IQtm21246 for linux-xfs-outgoing; Mon, 4 Mar 2002 10:26:55 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24IQq921224 for ; Mon, 4 Mar 2002 10:26:52 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g24IQlBA020366 for ; Mon, 4 Mar 2002 10:26:47 -0800 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA03957 for ; Mon, 4 Mar 2002 11:25:31 -0600 (CST) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA92443 for ; Mon, 4 Mar 2002 11:25:31 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id LAA33732 for linux-xfs@oss.sgi.com; Mon, 4 Mar 2002 11:25:31 -0600 (CST) Date: Mon, 4 Mar 2002 11:25:31 -0600 (CST) From: Dean Roehrich Message-Id: <200203041725.LAA33732@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - update dmapi's prohibited_mr_events for 2.5, fix build error Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 4 09:25:01 PST 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:113205a linux/fs/xfs/xfs_dmapi.c - 1.49 - Update prohibited_mr_events() for 2.5, to use the list macros for i_mmap_shared. From owner-linux-xfs@oss.sgi.com Mon Mar 4 12:17:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24KHKX24710 for linux-xfs-outgoing; Mon, 4 Mar 2002 12:17:20 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24KHE924688 for ; Mon, 4 Mar 2002 12:17:14 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA07007 for ; Mon, 4 Mar 2002 11:17:13 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA05327 for ; Mon, 4 Mar 2002 13:15:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA91366 for ; Mon, 4 Mar 2002 13:15:57 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g24JF8I17937; Mon, 4 Mar 2002 13:15:08 -0600 Message-Id: <200203041915.g24JF8I17937@jen.americas.sgi.com> Date: Mon, 4 Mar 2002 13:15:08 -0600 Subject: TAKE - Make xfs metadata accesses refresh pages To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This makes xfs metadata accesses to pages move the pages in the lru lists in a similar manner to the buffer cache metadata filesystems. This tends to make them stick in cache longer and reduce metadata reads. Date: Mon Mar 4 11:12:38 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113212a linux/mm/filemap.c - 1.106 - export mark_page_accessed to modules linux/fs/xfs/pagebuf/page_buf.c - 1.10 - make xfs metadata references bring pages forward in the cache, fix an assert, and count the number of metadata reads we do. linux/fs/xfs/pagebuf/page_buf.h - 1.6 - Add read counter to pagebuf stats From owner-linux-xfs@oss.sgi.com Mon Mar 4 12:52:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24Kq7v25408 for linux-xfs-outgoing; Mon, 4 Mar 2002 12:52:07 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24Kq1925385 for ; Mon, 4 Mar 2002 12:52:01 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA00649 for ; Mon, 4 Mar 2002 11:52:02 -0800 (PST) mail_from (ak@suse.de) Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 67B4F1E5D7; Mon, 4 Mar 2002 20:46:56 +0100 (MET) Date: Mon, 4 Mar 2002 20:46:56 +0100 From: Andi Kleen To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - reduce synchronous transaction use in xfs Message-ID: <20020304204656.A29810@wotan.suse.de> References: <200202152055.g1FKt4x10539@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202152055.g1FKt4x10539@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Feb 15, 2002 at 02:55:04PM -0600, Steve Lord wrote: > This was long thought to be the sole cause of slower delete speed in > XFS, this turns out not to be the case, it does help delete speed, but > if you go and delete 30000 files in one go it will not make a large > difference for you. That issue is the next thing being tackled. > [just noticing some big slow rm -rfs on a xfs disk] Could you expand a bit on that issue? I would like to understand it. Thanks, -Andi From owner-linux-xfs@oss.sgi.com Mon Mar 4 13:13:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24LDJq27557 for linux-xfs-outgoing; Mon, 4 Mar 2002 13:13:19 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24LDC927529 for ; Mon, 4 Mar 2002 13:13:12 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA08758 for ; Mon, 4 Mar 2002 12:13:13 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA04581; Mon, 4 Mar 2002 14:11:56 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA83389; Mon, 4 Mar 2002 14:11:56 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g24KB5J18848; Mon, 4 Mar 2002 14:11:05 -0600 Subject: Re: TAKE - reduce synchronous transaction use in xfs From: Steve Lord To: Andi Kleen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020304204656.A29810@wotan.suse.de> References: <200202152055.g1FKt4x10539@jen.americas.sgi.com> <20020304204656.A29810@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 04 Mar 2002 14:11:05 -0600 Message-Id: <1015272665.21528.72.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-04 at 13:46, Andi Kleen wrote: > On Fri, Feb 15, 2002 at 02:55:04PM -0600, Steve Lord wrote: > > This was long thought to be the sole cause of slower delete speed in > > XFS, this turns out not to be the case, it does help delete speed, but > > if you go and delete 30000 files in one go it will not make a large > > difference for you. That issue is the next thing being tackled. > > > > [just noticing some big slow rm -rfs on a xfs disk] > > Could you expand a bit on that issue? I would like to understand it. Well, the synchronous transaction removal means we get to fill the internal log buffers before we write them. So we manage to do larger writes to the log, but we still max out at 32K per write. We used to manage a lot less than this. Use the xfsstats script from cmds/xfsmisc/xfsstats.pl and look at xs_log_writes vs xs_log_blocks xs_log_blocks is in 512 byte chunks. If you run bonnie++ in the normal configuration it creates 30000 files in one directory. Once a directory gets that big XFS is, on average, writing 7K to the log for each file create and remove. So we do one log write for each 4 or 5 files created or removed. The next chunk of code is to support larger log writes - and to support better alignment of those writes. Delete performance then basically increases linearly with the size of the log buffers used. The alignment thing should help software raid5 with an internal log, as in that case the non-aligned log writes caused continuous tossing of the cache in the raid5 code. There is no date for when we can get this code into linux XFS yet. The other thing which seems to help a lot is the change I just put in pagebuf today. XFS metadata was getting pushed out of cache too easily and we ended up rereading a lot. This change on my box can make the removal of a kernel tree drop from 10 seconds to 5 seconds, but will not make a difference if you are removing stuff which has not been accessed recently. Steve > > Thanks, > -Andi -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Mar 4 13:25:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24LPRe27971 for linux-xfs-outgoing; Mon, 4 Mar 2002 13:25:27 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24LPO927949 for ; Mon, 4 Mar 2002 13:25:24 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07909 for ; Mon, 4 Mar 2002 12:25:24 -0800 (PST) mail_from (ak@suse.de) Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 29F201E5FA; Mon, 4 Mar 2002 21:19:34 +0100 (MET) Date: Mon, 4 Mar 2002 21:19:34 +0100 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: TAKE - reduce synchronous transaction use in xfs Message-ID: <20020304211934.B2952@wotan.suse.de> References: <200202152055.g1FKt4x10539@jen.americas.sgi.com> <20020304204656.A29810@wotan.suse.de> <1015272665.21528.72.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1015272665.21528.72.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [...] Thanks for the explanation. It feels better now that I know why it is slow :-) > > The other thing which seems to help a lot is the change I just put in > pagebuf today. XFS metadata was getting pushed out of cache too easily > and we ended up rereading a lot. This change on my box can make the > removal of a kernel tree drop from 10 seconds to 5 seconds, but will > not make a difference if you are removing stuff which has not been > accessed recently. Hmm, I may consider pulling that into my kernel then if it is a low risk change. -Andi From owner-linux-xfs@oss.sgi.com Mon Mar 4 13:59:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24Lx1x31472 for linux-xfs-outgoing; Mon, 4 Mar 2002 13:59:01 -0800 Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24Lwv931450 for ; Mon, 4 Mar 2002 13:58:57 -0800 Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8]) by ex1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g24KwuV27229 for ; Mon, 4 Mar 2002 14:58:56 -0600 (CST) Received: from niri.ncsa.uiuc.edu (niri.ncsa.uiuc.edu [141.142.64.68]) by mx1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g24KwuB20902 for ; Mon, 4 Mar 2002 14:58:56 -0600 (CST) From: Stuart Levy Received: (from slevy@localhost) by niri.ncsa.uiuc.edu (8.8.5/8.8.5) id OAA03586 for linux-xfs@oss.sgi.com; Mon, 4 Mar 2002 14:58:56 -0600 (CST) Date: Mon, 4 Mar 2002 14:58:56 -0600 (CST) Message-Id: <200203042058.OAA03586@niri.ncsa.uiuc.edu> To: linux-xfs@oss.sgi.com Subject: Fixed? xfs_alloc_lookup kernel oopses... Stupidity wins again! Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'd been getting frequent (every hour or two under heavy load) NULL-pointer kernel Oopses in xfs_alloc_lookup, using Jan 23 2.4.17 snapshot patch, and also with the full CVS 2.4.18-xfs, compiled either with gcc 2.95.3 or 2.91.66. Realized over the weekend that the machine has 1GB of RAM, but I hadn't built the kernel with CONFIG_HIGHMEM! Booted the existing kernel with mem=800M -- seemed to help -- and rebuilt 2.4.18-xfs with CONFIG_HIGHMEM (i.e. "4GB"). It hasn't crashed since then either. Workload hasn't been terribly heavy, but I think it would have died by now if the old symptom hadn't been fixed. Sorry to have bothered you all with this Stuart Levy, slevy@ncsa.uiuc.edu From owner-linux-xfs@oss.sgi.com Mon Mar 4 14:05:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24M50031746 for linux-xfs-outgoing; Mon, 4 Mar 2002 14:05:00 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24M4s931724 for ; Mon, 4 Mar 2002 14:04:54 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1452954 for ; Mon, 4 Mar 2002 22:08:36 +0100 (CET) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA05874; Mon, 4 Mar 2002 15:03:36 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA25164; Mon, 4 Mar 2002 15:03:35 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g24L2jP23127; Mon, 4 Mar 2002 15:02:45 -0600 Subject: Re: Fixed? xfs_alloc_lookup kernel oopses... Stupidity wins again! From: Steve Lord To: Stuart Levy Cc: linux-xfs@oss.sgi.com In-Reply-To: <200203042058.OAA03586@niri.ncsa.uiuc.edu> References: <200203042058.OAA03586@niri.ncsa.uiuc.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 04 Mar 2002 15:02:44 -0600 Message-Id: <1015275764.21528.78.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-04 at 14:58, Stuart Levy wrote: > I'd been getting frequent (every hour or two under heavy load) > NULL-pointer kernel Oopses in xfs_alloc_lookup, > using Jan 23 2.4.17 snapshot patch, and also with the full > CVS 2.4.18-xfs, compiled either with gcc 2.95.3 or 2.91.66. > > Realized over the weekend that the machine has 1GB of RAM, > but I hadn't built the kernel with CONFIG_HIGHMEM! > Booted the existing kernel with mem=800M -- seemed to help -- > and rebuilt 2.4.18-xfs with CONFIG_HIGHMEM (i.e. "4GB"). > It hasn't crashed since then either. Workload hasn't been > terribly heavy, but I think it would have died by now > if the old symptom hadn't been fixed. > > Sorry to have bothered you all with this > > Stuart Levy, slevy@ncsa.uiuc.edu Well, seems a little odd that running a non-highmem kernel on a highmem box would cause this. It should ignore the memory it cannot get to. Keep us posted if things fall over again. Good to get something knocked off the list though. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Mar 4 14:46:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24MkL701167 for linux-xfs-outgoing; Mon, 4 Mar 2002 14:46:21 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24MkF901145 for ; Mon, 4 Mar 2002 14:46:15 -0800 Received: (qmail 20887 invoked from network); 4 Mar 2002 21:46:11 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 4 Mar 2002 21:46:11 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id D68913000B8; Tue, 5 Mar 2002 07:46:08 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id B1F8ABA; Tue, 5 Mar 2002 08:46:08 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: =?iso-8859-1?Q?Christian_R=F8snes?= Cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.18 freeze running dbench 1.3 In-reply-to: Your message of "Mon, 04 Mar 2002 14:20:10 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Mar 2002 08:46:03 +1100 Message-ID: <23655.1015278363@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 4 Mar 2002 14:20:10 +0100, =?iso-8859-1?Q?Christian_R=F8snes?= wrote: >ksymoops 2.4.1 on i686 2.4.9-13SGI_XFS_1.0.2smp. Options used >ksyms_base entry >Warning (compare_maps): ksyms_base symbol >pci_hp_change_slot_info_R__ver_pci_hp_change_slot_info not found in vmlinux. >Ignoring ksyms_base entry >Warning (compare_maps): ksyms_base symbol >pci_hp_deregister_R__ver_pci_hp_deregister not found in vmlinux. Ignoring ksyms_base entry >Warning (compare_maps): ksyms_base symbol >pci_hp_register_R__ver_pci_hp_register not found in vmlinux. Ignoring >ksyms_base entry This may or may not have anything to do with the XFS oops but the *_R__ver_* warnings say that your kernel has not been correctly built. See http://www.tux.org/lkml/#s8-8. Does the problem still occur after a clean kernel build? From owner-linux-xfs@oss.sgi.com Mon Mar 4 15:15:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24NFHl02007 for linux-xfs-outgoing; Mon, 4 Mar 2002 15:15:17 -0800 Received: from web21107.mail.yahoo.com (web21107.mail.yahoo.com [216.136.227.109]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24NFD901985 for ; Mon, 4 Mar 2002 15:15:13 -0800 Message-ID: <20020304221513.34714.qmail@web21107.mail.yahoo.com> Received: from [12.234.153.47] by web21107.mail.yahoo.com via HTTP; Mon, 04 Mar 2002 14:15:13 PST Date: Mon, 4 Mar 2002 14:15:13 -0800 (PST) From: Glow Nair Subject: Recovering from an XFS crash To: 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 HELP.. I would appreciate any help/hints etc. that I can get from SGI.. I've generally been very happy with SGI XFS 1.02 I made emergency boot disks.. however when my disk crashed, it wont boot using the rescue disk Can you help ? Thanks Glow Nair 408-343-1112 glow@zanchu.com __________________________________________________ Do You Yahoo!? Yahoo! Sports - sign up for Fantasy Baseball http://sports.yahoo.com From owner-linux-xfs@oss.sgi.com Mon Mar 4 15:28:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24NSfl02331 for linux-xfs-outgoing; Mon, 4 Mar 2002 15:28:41 -0800 Received: from mail.gmx.net (sproxy.gmx.de [213.165.64.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24NST902301 for ; Mon, 4 Mar 2002 15:28:29 -0800 Received: (qmail 23497 invoked by uid 0); 4 Mar 2002 22:28:22 -0000 Received: from pec-88-143.tnt6.b2.uunet.de (HELO 127.0.0.1) (149.225.88.143) by mail.gmx.net (mp013-rz3) with SMTP; 4 Mar 2002 22:28:22 -0000 Date: Mon, 4 Mar 2002 23:26:20 +0100 From: Andreas Piesk X-Mailer: The Bat! (v1.53d) Personal Reply-To: Andreas Piesk Organization: private X-Priority: 3 (Normal) Message-ID: <15912112847.20020304232620@gmx.net> To: xfs ML Subject: Re[2]: REPOST: PATCH proposal: attr In-Reply-To: <20020212094708.A138465@wobbly.melbourne.sgi.com> References: <6053616045.20020211133106@gmx.net> <20020212094708.A138465@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------66710C2AD2A5A5" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ------------66710C2AD2A5A5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Monday, February 11, 2002, 11:47:08 PM, Nathan Scott wrote: > On Mon, Feb 11, 2002 at 01:31:06PM +0100, Andreas Piesk wrote: >> hiho, >> >> this is a patch for attr. >> >> detail: >> - provides the ability to hande more than one file like chacl >> - changes the error messages to look like the ones from chacl >> >> i introduced a new command line parameter "-c". if set, attr >> continues with the next file if an error occured. it's disabled >> by default. >> > There is a new command on its way which should do these things. > Please wait a bit, then lets reevaluate whether this change is > still useful once you've had a look at the new tools. > ETA for new EA tools is with the 2.4.18 merge, once that is out. nathan, are the version 2.x tools the new tools you spoke about? i just checked attr-2.0.1 and there's no multifile handling. so i brought my little patch up-to-date with attr-2.0.1. i'm not sure about the '-c' flag. see above for description. acl continues on errors per default. i think, the tools should behave similar. so either acl gets the '-c' flag or attr continues on errors and the '-c' flag should be removed. comments? ciao -ap -- Andreas Piesk a.piesk@gmx.net PGP-Fingerprint: 23CB A7E2 2E53 373C DBCD 8EFC 7777 61C1 ------------66710C2AD2A5A5 Content-Type: application/x-gzip; name="attr-2.0.1-multifile.patch.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attr-2.0.1-multifile.patch.gz" H4sICO7ygzwCA2F0dHItMi4wLjEtbXVsdGlmaWxlLnBhdGNoAOVYbXObRhD+ jH7FRpk4yIAtOY6Tonpqt3X6RY4yru12JvFkMDoQExnkA8ltU/337t4LIKFI kDRtZ6oPGI693Wd3n91b7DgOeFnGnYO97l5vn27FZc83LmcMXrFbODiC7qHb e+kePoODbvegZVlWac/eXTJa2neexHDucYBDOHjm9o7c5z257+QEnOfP7G/A EteTkxbMUi9k5jyJRp0WfGyBEUx5FGeBmWYjxrndctpXJOLCkxTeOoOL+xtw UmE99u4YLl2Lh7k3mbEbmHrZWKzDY0hZBmL5XdxGNSB/JTVhoabYt/J7DOE2 NbyWGs7ukjkToqTIWnXL/zy/rFVA/uc5tlbPZ3kGShN6w5k3Qp+kFQh4cgeY 1igGLx4RygceZawQyBJ6ncwyVGMjFYwpT0IyakP1rtNHCfZblJk9vCVmHR3Z L8ASV2IWkckfIw13tRO2vBXG8D6IJoyWSRFSTjiAK2E27rccsZJMg4kX2uCP bUAyJtyGIJlMkgcb5ozfJimq4UmSkVS/ZTXeoyT8JM4QBMLQzsEx3HqpQGd6 PJy/7d6Qv8LNF4dUQOJKbhqwC28i/wPMpiKs6F008jKM5hhzwsPZHYuzdE8I 7uNVgUALPXJTYsMniRtvNDi87ZJTGyVy/FIajJwwxwV98f711WBA5h7GGHQw TX+Mi0jAZJqRg75NUOc2tFP32g1d7t4PLtqdDjw6hrPhqw4m02q011/ejFxK H6IMd+JuteBjgOFp+tSlByMKULPyEPd1O7CzA6WFn88uh286tJVy0DvA/vUS LPrb66pEKI33SmMRaBEYw7jFcviAEdWVI8V9FLfKBVUOaa+//E6pQG0jFniz SSZNrfRMaF/FnPlIpegPNsK8ZVESY6fxqa4oAh7vYBgkKtmAO0sQ8XaBlwWV QUBRyCJkFkaBwu30RDoITunlsXypYlsBdAq62qjKkynjRFE8JyLqEveziLMR opMwSpAIQr5TmJi/lRZvkE74cn8XL1gC3xNywN4BaDhRPjvplPlREPnUNXyW plEc7gn5fbxqRsgkE3JHplDk2sUn4X2JxpLHUtIwyvy+87BIfPP08vLi/fnp r++vTwdXZ4Oz152+EN2ox5iKlJttqaSt9hTNjZ4WuUnZouBYCgXUY81SW+vZ UEFhy7YrVS2ATdDJjxWFKET3hTIlTxeBUNX0ezyATJ0UG4ruWqCQ2AykSGGg tGg+Uk3lO4n1x+Hry1fDwWD4C7hUen+WRPNmo2QvhsNLISXRUWQFOB1NHUyN VIezQskfktlkBHGSiQP1XftJ+q6NrZrjCSjOHwmh8E57rPSVs7PQSFTN51ik yfYpKoluZ8h4ZYYsIks9eDKC299xXRKjLXapWm9LLG4ORq0vx1vFdhVdII7W FV6U5eVBq6Q1TlmB2iHVDBxdFj/lZVGf+RuJv573lcAucbRip1+hZ9iAnjv/ Lj/DWvwM/3F+jr1RhZyrdDTqEFFYbkTGDTA30/Pi7Hx4faYYukQIOaCu40SR x2ZZ/+LES0g1cq+G6y9Pfylc+ezgGNXPLdyLfIAJ81IcZmM8pAMc5W0c121A 6/hNUDmyndKRXbJEM4ScExC2CX1Qo8K3YlLQj/gpmc8TNG1+6rC3pAgd+PKm 2aFvybThwS93Vw9/KVEeACyZ60/2MEuRoWY7lIY39ESJYG1jtGDNb39XDouU ER9LLPK9CdhIG6DxMYpRO/lrKLU5JTTuRQ5paa7IYTScLZShfL4oh2fTjGGt oGk6a+R4V+eN3PN6PV3j3d7XFdClEtfGKrWMPRM2zBquLujCfPGxWy1vCjeX 9MBrnHTWkSMKzNJnRGc9ezRHCmKWCCJWFuUKKPVkjbT5eGMVY0xlxLGKXNUa c3Ta658uOkXL54myu9AK9WeaelEefZRE3Xqv2T62VLuxrsyrVb4th9umqHXF FzYsvp3/evWF/4fq2za8WUapMW8usZXSaFxqW6DXL8BiuFNCdQe8JRY2J+JX 5OK6ye7voKPxNbm4kpt8krTWupyHoulEqXDkU+UKMzQmOTaAwVk247HZpX8Z LVp/AVID1tnSGAAA ------------66710C2AD2A5A5-- From owner-linux-xfs@oss.sgi.com Mon Mar 4 15:36:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24NaZt02835 for linux-xfs-outgoing; Mon, 4 Mar 2002 15:36:35 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24NaV902813 for ; Mon, 4 Mar 2002 15:36:31 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g24MaObX001443 for ; Mon, 4 Mar 2002 14:36:25 -0800 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 JAA24878 for ; Tue, 5 Mar 2002 09:35:08 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA17722 for linux-xfs@oss.sgi.com; Tue, 5 Mar 2002 09:35:07 +1100 (AEDT) Date: Tue, 5 Mar 2002 09:35:07 +1100 From: Nathan Scott To: Andreas Piesk Subject: Re: Re[2]: REPOST: PATCH proposal: attr Message-ID: <20020305093507.R13725@wobbly.melbourne.sgi.com> References: <6053616045.20020211133106@gmx.net> <20020212094708.A138465@wobbly.melbourne.sgi.com> <15912112847.20020304232620@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15912112847.20020304232620@gmx.net>; from a.piesk@gmx.net on Mon, Mar 04, 2002 at 11:26:20PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Mar 04, 2002 at 11:26:20PM +0100, Andreas Piesk wrote: > nathan, are the version 2.x tools the new tools you spoke about? yup. > i just checked attr-2.0.1 and there's no multifile handling. > so i brought my little patch up-to-date with attr-2.0.1. getfattr(1) and setfattr(1) do multiple files. > i'm not sure about the '-c' flag. see above for description. > acl continues on errors per default. i think, the tools should > behave similar. so either acl gets the '-c' flag or attr continues > on errors and the '-c' flag should be removed. > > comments? attr(1) is not really the tool of choice anymore, and we only maintain it for compatibility with existing XFS installations and with IRIX. adding new options should be done to getfattr and setfattr, if necessary (in this case, it seems to me that no change is needed?). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 4 15:41:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24NfUa03005 for linux-xfs-outgoing; Mon, 4 Mar 2002 15:41:30 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24NfQ902982 for ; Mon, 4 Mar 2002 15:41:26 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA1442058 for ; Mon, 4 Mar 2002 23:45:09 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA08338; Mon, 4 Mar 2002 16:40:07 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA85364; Mon, 4 Mar 2002 16:40:07 -0600 (CST) Subject: Re: Recovering from an XFS crash From: Eric Sandeen To: Glow Nair Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020304221513.34714.qmail@web21107.mail.yahoo.com> References: <20020304221513.34714.qmail@web21107.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 04 Mar 2002 16:40:07 -0600 Message-Id: <1015281607.22675.12.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-04 at 16:15, Glow Nair wrote: > HELP.. > I would appreciate any help/hints etc. that I can > get from SGI.. I've generally been very happy with > SGI XFS 1.02 > > I made emergency boot disks.. however when my > disk crashed, it wont boot using the rescue > disk > > Can you help ? The installer should warn you, but it doesn't... the XFS kernel is often too big to fit on a boot floppy. :( Try booting from the 1.0.2 CD with "linux rescue" at the boot prompt. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Mar 4 15:51:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24NptE03348 for linux-xfs-outgoing; Mon, 4 Mar 2002 15:51:55 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24Npo903326 for ; Mon, 4 Mar 2002 15:51:50 -0800 Received: (qmail 23599 invoked by uid 500); 4 Mar 2002 22:51:14 -0000 Subject: Re: Linux 2.4.18 freeze running dbench 1.3 From: Austin Gonyou To: Keith Owens Cc: Christian =?ISO-8859-1?Q?R=F8snes?= , linux-xfs@oss.sgi.com In-Reply-To: <23655.1015278363@ocs3.intra.ocs.com.au> References: <23655.1015278363@ocs3.intra.ocs.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 04 Mar 2002 16:51:14 -0600 Message-Id: <1015282274.23562.0.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As a side note, make mrproper or use refined kernel sources. On Mon, 2002-03-04 at 15:46, Keith Owens wrote: > On Mon, 4 Mar 2002 14:20:10 +0100, > =?iso-8859-1?Q?Christian_R=F8snes?= wrote: > >ksymoops 2.4.1 on i686 2.4.9-13SGI_XFS_1.0.2smp. Options used > >ksyms_base entry > >Warning (compare_maps): ksyms_base symbol > >pci_hp_change_slot_info_R__ver_pci_hp_change_slot_info not found in > vmlinux. > >Ignoring ksyms_base entry > >Warning (compare_maps): ksyms_base symbol > >pci_hp_deregister_R__ver_pci_hp_deregister not found in vmlinux. > Ignoring > ksyms_base entry > >Warning (compare_maps): ksyms_base symbol > >pci_hp_register_R__ver_pci_hp_register not found in vmlinux. Ignoring > >ksyms_base entry > > This may or may not have anything to do with the XFS oops but the > *_R__ver_* warnings say that your kernel has not been correctly built. > See http://www.tux.org/lkml/#s8-8. Does the problem still occur after > a clean kernel build? -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Mar 4 15:56:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24NurV03633 for linux-xfs-outgoing; Mon, 4 Mar 2002 15:56:53 -0800 Received: from cellus.no (mail.cellus.no [193.91.191.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24Nua903611 for ; Mon, 4 Mar 2002 15:56:36 -0800 Received: from christian ([193.69.127.56]) by cellus.no (8.9.3/8.9.3) with SMTP id XAA30424; Mon, 4 Mar 2002 23:56:32 +0100 From: =?us-ascii?Q?Christian_Rosnes?= To: "Keith Owens" Cc: Subject: RE: Linux 2.4.18 freeze running dbench 1.3 Date: Mon, 4 Mar 2002 23:56:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: <23655.1015278363@ocs3.intra.ocs.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > -----Original Message----- > From: Keith Owens [mailto:kaos@sgi.com] > > On Mon, 4 Mar 2002 14:20:10 +0100, > =?iso-8859-1?Q?Christian_R=F8snes?= wrote: > >ksymoops 2.4.1 on i686 2.4.9-13SGI_XFS_1.0.2smp. Options used > >ksyms_base entry > >Warning (compare_maps): ksyms_base symbol > >pci_hp_change_slot_info_R__ver_pci_hp_change_slot_info not found > in vmlinux. > >Ignoring ksyms_base entry > >Warning (compare_maps): ksyms_base symbol > >pci_hp_deregister_R__ver_pci_hp_deregister not found in vmlinux. > Ignoring > ksyms_base entry > >Warning (compare_maps): ksyms_base symbol > >pci_hp_register_R__ver_pci_hp_register not found in vmlinux. Ignoring > >ksyms_base entry > > This may or may not have anything to do with the XFS oops but the > *_R__ver_* warnings say that your kernel has not been correctly built. > See http://www.tux.org/lkml/#s8-8. Does the problem still occur after > a clean kernel build? > When I ran the oops through ksymoops I had rebooted with the 2.4.9-13SGI_XFS_1.0.2smp kernel. So, I tried to refer to 2.4.18 kernel and the related data/objects of that kernel. I believe I found the kernel, ksym table, system map, module path for that version of 2.4.18. I read the info from the link you provided, and did: mv .config .. make mrproper mv ../.config . make oldconfig make dep clean bzImage modules # install, boot Still oopsing: [root@dl02 dbench]# ./dbench 10 ..invalid operand: 0000 CPU: 1 EIP: 0010:[] Not tainted EFLAGS: 00010086 eax: 0000004a ebx: f7573cf0 ecx: c03ed424 edx: 00002ed2 esi: 00000297 edi: f7573c00 ebp: 00000000 esp: f6c8ba5c ds: 0018 es: 0018 ss: 0018 Process dbench (pid: 1155, stackpage=f6c8b000) Stack: c0315760 0000005a 00000000 00000005 00000010 f6c8bcc0 c01bb04d f7573c00 0000001e ffffffeb 00000000 00000010 00000000 c01ba988 f6c8bcc0 00000001 00000000 00000000 f7c73530 00000000 f6c8bb60 00000000 fffe0005 00000010 Call Trace: [] [] [] [] [] [] [] [] [] [] [ [] [] [] [] [] [ [] [] [] [] [] [ Code: 0f 0b 83 c4 08 8d 74 26 00 c6 87 f0 00 00 00 01 56 9d 89 e8 Entering kdb (current=0xf6c8a000, pid 1155) on processor 1 Oops: invalid operand due to oops @ 0xc01f1c47 eax = 0x0000004a ebx = 0xf7573cf0 ecx = 0xc03ed424 edx = 0x00002ed2 esi = 0x00000297 edi = 0xf7573c00 esp = 0xf6c8ba5c eip = 0xc01f1c47 ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086 xds = 0xc0310018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf6c8ba28 [1]kdb> bt EBP EIP Function(args) 0xc01f1c47 xfs_mod_incore_sb+0x93 (0xf7573c00, 0x1e, 0xffffffeb, 0x0) kernel .text 0xc0100000 0xc01f1bb4 0xc01f1c60 0xf6c8bcc0 0xc01bb04d xfs_bmapi+0x6c5 (0x0, 0xf6db2dc0, 0x80, 0x0, 0x10) kernel .text 0xc0100000 0xc01ba988 0xc01bbca4 0xc020fc49 xfs_iomap_write_delay+0x64d (0xf6db2dc0, 0xc4, 0xf6db2ef8) kernel .text 0xc0100000 0xc020f5fc 0xc020fe8c 0xc020d8b8 xfs_zero_last_block+0x680 (0xf6c7f044, 0x80000, 0x0, 0x10) kernel .text 0xc0100000 0xc020d238 0xc020d8e0 0xc0208259 _pagebuf_file_write+0xf1 (0xf72d14b4, 0x804bde8, 0xffbb, ) kernel .text 0xc0100000 0xc0208168 0xc0208390 0xc0208453 pagebuf_generic_file_write+0xc3 (0xf72d14b4, 0x804bde8, 0) kernel .text 0xc0100000 0xc0208390 0xc02086fc 0xc020e0bf xfs_write+0x2bb (0xf6db2dd8, 0xf6c8bf7c, 0x2, 0x0, 0x0) kernel .text 0xc0100000 0xc020de04 0xc020e320 0xc0209a6e linvfs_write+0x2fe (0xf72d14b4, 0x804bde0, 0xffc3, 0xf72d) kernel .text 0xc0100000 0xc0209770 0xc0209abc 0xc0145717 sys_write+0x8f (0x6, 0x804bde0, 0xffc3, 0x10, 0x105d) kernel .text 0xc0100000 0xc0145688 0xc0145858 0xc01077bb system_call+0x33 kernel .text 0xc0100000 0xc0107788 0xc01077c0 [1]kdb> cpu 0 Entering kdb (current=0xf6c7c000, pid 1156) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xf6c7dcc0 0xc01f242d _text_lock_xfs_mount+0xf (0x0, 0xf6c4d9d8, 0x90, 0x0, 0x1) kernel .text 0xc0100000 0xc01f241e 0xc01f2480 0xc020fc49 xfs_iomap_write_delay+0x64d (0xf6c4d9d8, 0xc4, 0xf6c4db10) kernel .text 0xc0100000 0xc020f5fc 0xc020fe8c 0xc020d8b8 xfs_zero_last_block+0x680 (0xf6c35c4c, 0x90000, 0x0, 0x10) kernel .text 0xc0100000 0xc020d238 0xc020d8e0 0xc0208259 _pagebuf_file_write+0xf1 (0xf737d644, 0x804bde9, 0xffba, ) kernel .text 0xc0100000 0xc0208168 0xc0208390 0xc0208453 pagebuf_generic_file_write+0xc3 (0xf737d644, 0x804bde9, 0) kernel .text 0xc0100000 0xc0208390 0xc02086fc 0xc020e0bf xfs_write+0x2bb (0xf6c4d9f0, 0xf6c7df7c, 0x2, 0x0, 0x0) kernel .text 0xc0100000 0xc020de04 0xc020e320 0xc0209a6e linvfs_write+0x2fe (0xf737d644, 0x804bde0, 0xffc3, 0xf737) kernel .text 0xc0100000 0xc0209770 0xc0209abc 0xc0145717 sys_write+0x8f (0x6, 0x804bde0, 0xffc3, 0x10, 0x105d) kernel .text 0xc0100000 0xc0145688 0xc0145858 0xc01077bb system_call+0x33 kernel .text 0xc0100000 0xc0107788 0xc01077c0 [0]kdb> From owner-linux-xfs@oss.sgi.com Mon Mar 4 15:57:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g24Nv3E03659 for linux-xfs-outgoing; Mon, 4 Mar 2002 15:57:03 -0800 Received: from cellus.no (ns.cellus.no [193.91.191.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g24NuI903587 for ; Mon, 4 Mar 2002 15:56:18 -0800 Received: from christian ([193.69.127.56]) by cellus.no (8.9.3/8.9.3) with SMTP id XAA30401; Mon, 4 Mar 2002 23:56:11 +0100 From: =?iso-8859-1?Q?Christian_R=F8snes?= To: "Steve Lord" Cc: Subject: RE: Linux 2.4.18 freeze running dbench 1.3 Date: Mon, 4 Mar 2002 23:56:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1015257285.21528.55.camel@jen.americas.sgi.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MIME-Autoconverted: from 8bit to quoted-printable by cellus.no id XAA30401 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g24NuJ903588 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > From: Steve Lord [mailto:lord@sgi.com] Sent: 4. mars 2002 16:55 > > On Mon, 2002-03-04 at 09:24, Christian Rřsnes wrote: > > > > To follow up: > > > > I tested dbench on an ext2 partition (/home) on the same server, > > and it worked. dbench on the XFS /usr partition still crashes > the server. > > This kernel was made with gcc 2.96. > > > Let me confirm something here - you originally reported a complete > hang when running with xfs. Keith asked you to run with the nmi > oopser enabled - is this oops coming out after your turned on the > oopser enabled (nmi_watchdog=1 on the kernel boot line)? I've ran some tests to be sure: Running dbench on an XFS partition. All kernel compilation done with kgcc - gcc version 2.91.66 1) Without kdb turned on in the kernel, it did a complete hang: No Oops on console or in /var/log/messages (Running dbench on an ext2 partition works fine). 2) With kdb turned on, but without the nmi_watchdog=1 parameter it oopsed and entered the debugger: [root@dl02 dbench]# ./dbench 10 ..invalid operand: 0000 CPU: 1 EIP: 0010:[] Not tainted EFLAGS: 00010086 eax: 0000004a ebx: f75748f0 ecx: c03ed424 edx: 00002e72 esi: 00000297 edi: f7574800 ebp: 00000000 esp: f5f8da5c ds: 0018 es: 0018 ss: 0018 Process dbench (pid: 1050, stackpage=f5f8d000) Stack: c0315760 0000005a 00000000 00000005 00000010 f5f8dcc0 c01bb04d f7574800 0000001e ffffffeb 00000000 00000010 00000000 c01ba988 f5f8dcc0 00000001 00000000 00000000 f7c73218 00000000 f5f8db60 00000000 fffe0005 00000010 Call Trace: [] [] [] [] [] [] [] [] [] [] [ [] [] [] [] [] [ [] [] [] [] [] [ Code: 0f 0b 83 c4 08 8d 74 26 00 c6 87 f0 00 00 00 01 56 9d 89 e8 Entering kdb (current=0xf5f8c000, pid 1050) on processor 1 Oops: invalid operand due to oops @ 0xc01f1c47 eax = 0x0000004a ebx = 0xf75748f0 ecx = 0xc03ed424 edx = 0x00002e72 esi = 0x00000297 edi = 0xf7574800 esp = 0xf5f8da5c eip = 0xc01f1c47 ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086 xds = 0xc0310018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf5f8da28 [1]kdb> bt EBP EIP Function(args) 0xc01f1c47 xfs_mod_incore_sb+0x93 (0xf7574800, 0x1e, 0xffffffeb, 0x0) kernel .text 0xc0100000 0xc01f1bb4 0xc01f1c60 0xf5f8dcc0 0xc01bb04d xfs_bmapi+0x6c5 (0x0, 0xf5fb7bdc, 0x80, 0x0, 0x10) kernel .text 0xc0100000 0xc01ba988 0xc01bbca4 0xc020fc49 xfs_iomap_write_delay+0x64d (0xf5fb7bdc, 0xc4, 0xf5fb7d14) kernel .text 0xc0100000 0xc020f5fc 0xc020fe8c 0xc020d8b8 xfs_zero_last_block+0x680 (0xf657cccc, 0x80000, 0x0, 0x10) kernel .text 0xc0100000 0xc020d238 0xc020d8e0 0xc0208259 _pagebuf_file_write+0xf1 (0xf6da1334, 0x804bde8, 0xffbb, ) kernel .text 0xc0100000 0xc0208168 0xc0208390 0xc0208453 pagebuf_generic_file_write+0xc3 (0xf6da1334, 0x804bde8, 0) kernel .text 0xc0100000 0xc0208390 0xc02086fc 0xc020e0bf xfs_write+0x2bb (0xf5fb7bf4, 0xf5f8df7c, 0x2, 0x0, 0x0) kernel .text 0xc0100000 0xc020de04 0xc020e320 0xc0209a6e linvfs_write+0x2fe (0xf6da1334, 0x804bde0, 0xffc3, 0xf6da) kernel .text 0xc0100000 0xc0209770 0xc0209abc 0xc0145717 sys_write+0x8f (0x6, 0x804bde0, 0xffc3, 0x10, 0x105e) kernel .text 0xc0100000 0xc0145688 0xc0145858 0xc01077bb system_call+0x33 kernel .text 0xc0100000 0xc0107788 0xc01077c0 [1]kdb> cpu 0 Entering kdb (current=0xf5f8a000, pid 1049) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xf5f8bcc0 0xc01f242d _text_lock_xfs_mount+0xf (0x0, 0xf5faf5f0, 0x90, 0x0, 0x1) kernel .text 0xc0100000 0xc01f241e 0xc01f2480 0xc020fc49 xfs_iomap_write_delay+0x64d (0xf5faf5f0, 0xc4, 0xf5faf728) kernel .text 0xc0100000 0xc020f5fc 0xc020fe8c 0xc020d8b8 xfs_zero_last_block+0x680 (0xf6c6a758, 0x90000, 0x0, 0x10) kernel .text 0xc0100000 0xc020d238 0xc020d8e0 0xc0208259 _pagebuf_file_write+0xf1 (0xf72b59f4, 0x804bde9, 0xffba, ) kernel .text 0xc0100000 0xc0208168 0xc0208390 0xc0208453 pagebuf_generic_file_write+0xc3 (0xf72b59f4, 0x804bde9, 0) kernel .text 0xc0100000 0xc0208390 0xc02086fc 0xc020e0bf xfs_write+0x2bb (0xf5faf608, 0xf5f8bf7c, 0x2, 0x0, 0x0) kernel .text 0xc0100000 0xc020de04 0xc020e320 0xc0209a6e linvfs_write+0x2fe (0xf72b59f4, 0x804bde0, 0xffc3, 0xf72b) kernel .text 0xc0100000 0xc0209770 0xc0209abc 0xc0145717 sys_write+0x8f (0x6, 0x804bde0, 0xffc3, 0x10, 0x105e) kernel .text 0xc0100000 0xc0145688 0xc0145858 0xc01077bb system_call+0x33 kernel .text 0xc0100000 0xc0107788 0xc01077c0 [0]kdb> > From: Steve Lord [mailto:lord@sgi.com] Sent: 4. mars 2002 16:55 > > If this is the case I think I can deduce the lock xfs has got hung > up on - and safely say I have never seen this before. I may try and > come up with some tracing code for this one, it looks like a spinlock > leak on the superblock counters. > > Could you possibly try this: > > Edit fs/xfs/Makefile and fs/xfs/linux/Makefile, look for the line like > this: > > EXTRA_CFLAGS += -I. -funsigned-char > > (It is a little different in the xfs/linux/Makefile) Remove the > -funsigned-char > > Also remove all the .o files in the xfs directories after doing this. > Now in the config tool, turn on spinlock debugging in the kernel and > try running xfs again. > > You have to remove the -funsigned-char to make xfs function with > spinlock debugging. We know it mostly works this way, but it has not > had much exposure. > > Hopefully this will report some misuse of the lock somewhere. > 3) Ok, here goes: Spinlock debugging turned on (it was also turned on in case 2 above) Removed '-funsigned-char' from fs/xfs/Makefile and fs/xfs/linux/Makefile make clean make dep make bzImage make modules make modules_install reboot (no nmi_watchdog=1 when booting kernel) Test dbench: [root@dl02 dbench]# ./dbench 10 10 clients started .......... Result: A complete hang this time. No oops. 4) Tried the same kernel, but with nmi_watchdog=1. Result: Complete hang. No oops. 5) Same as 3) above, but put '-funsigned-char' back in the two Makefiles. with nmi_watchdog=1 This time it crashed when i tried to 'rm' the /usr/src/dbench directory, to untar and rebuild the dbench test. [root@dl02 root]# cd /usr/src [root@dl02 src]# rm -rf dbench invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010082 eax: 0000004a ebx: f7c74014 ecx: c03ed424 edx: 00002eef esi: 0000026e edi: 000000d8 ebp: f7c74000 esp: f6de9d2c ds: 0018 es: 0018 ss: 0018 Process rm (pid: 1108, stackpage=f6de9000) Stack: c03160e0 0000005a 00000008 f7c73694 f7c73694 f7c73694 00000286 c01e7e23 f7c74000 00000008 f7c73694 f7c73694 f7550000 f6de9d70 c01e9721 f7c73694 00000000 00000296 f7c61930 c01ea74e f7c74000 00000000 00000008 f7c73694 Call Trace: [] [] [] [] [] [] [] [] [] [] [ [] [] Code: 0f 0b 83 c4 08 c6 45 14 01 ff 74 24 10 9d 89 f0 89 fa 5b 5e Entering kdb (current=0xf6de8000, pid 1108) on processor 0 Oops: invalid operand due to oops @ 0xc01f6993 eax = 0x0000004a ebx = 0xf7c74014 ecx = 0xc03ed424 edx = 0x00002eef esi = 0x0000026e edi = 0x000000d8 esp = 0xf6de9d2c eip = 0xc01f6993 ebp = 0xf7c74000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010082 xds = 0xc0310018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf6de9cf8 [0]kdb> bt EBP EIP Function(args) 0xf7c74000 0xc01f6993 xfs_trans_tail_ail+0xa3 (0xf7c74000) kernel .text 0xc0100000 0xc01f68f0 0xc01f69ac 0xc01e7e23 xlog_assign_tail_lsn+0x17 (0xf7c74000, 0x0) kernel .text 0xc0100000 0xc01e7e0c 0xc01e7f5c 0xc01ea74e xlog_state_release_iclog+0x22 (0xf7c73694, 0xf7550000) kernel .text 0xc0100000 0xc01ea72c 0xc01ea88c 0xc01e8ecc xlog_write+0x3ec (0xf7c74000, 0xf6de9e54, 0x8, 0xf7c61930) kernel .text 0xc0100000 0xc01e8ae0 0xc01e8ed8 0xc01e7ad4 xfs_log_write+0x38 (0xf7c74000, 0xf6de9e54, 0x8, 0xf7c619) kernel .text 0xc0100000 0xc01e7a9c 0xc01e7af8 0xc01f6219 xfs_trans_commit+0x19d (0xf7582e68, 0x4, 0x0) kernel .text 0xc0100000 0xc01f607c 0xc01f6318 0xc01ffc23 xfs_rmdir+0x523 (0xf6d7605c, 0xf7657948, 0x0, 0x0) kernel .text 0xc0100000 0xc01ff700 0xc01ffd1c 0xc020c7dd linvfs_rmdir+0x25 (0xf6decb50, 0xf76578ec) kernel .text 0xc0100000 0xc020c7b8 0xc020c834 0xc0155cf4 vfs_rmdir+0x2c8 (0xf6decb50, 0xf76578ec) kernel .text 0xc0100000 0xc0155a2c 0xc0155de4 0xc0155ea0 sys_rmdir+0xbc (0xbfffeeb0, 0x0, 0x1, 0x0, 0xbfffeeb0) kernel .text 0xc0100000 0xc0155de4 0xc0155ee4 0xc01077bb system_call+0x33 [0]more> kernel .text 0xc0100000 0xc0107788 0xc01077c0 [0]kdb> cpu 1 Entering kdb (current=0xc2554000, pid 0) on processor 1 due to cpu switch [1]kdb> bt EBP EIP Function(args) 0x000000d8 0xc01f68e0 _text_lock_xfs_trans (0xf764bc10, 0x0) kernel .text 0xc0100000 0xc01f68e0 0xc01f68f0 0xc01e944a xlog_state_do_callback+0x3aa (0xf7c73694, 0x0, 0xf7540000) kernel .text 0xc0100000 0xc01e90a0 0xc01e9600 0xc01e9702 xlog_state_done_syncing+0x102 (0xf7540000, 0x0) kernel .text 0xc0100000 0xc01e9600 0xc01e970c 0xc01e801b xlog_iodone+0x73 (0xf7765a34) kernel .text 0xc0100000 0xc01e7fa8 0xc01e803c 0xc0204fe8 pagebuf_iodone+0x38 (0xf7765a34) kernel .text 0xc0100000 0xc0204fb0 0xc0205030 0xc0205232 _end_pagebuf_page_io+0x15e (0xf71ccae4, 0x1) kernel .text 0xc0100000 0xc02050d4 0xc020523c 0xc024bc11 do_cciss_intr+0x241 (0x3, 0xf7c6a000, 0xc2555f7c, 0xc0444) kernel .text 0xc0100000 0xc024b9d0 0xc024bce4 0xc0108f88 handle_IRQ_event+0x50 (0x3, 0xc2555f7c, 0xc255f9ec, 0xc01) kernel .text 0xc0100000 0xc0108f38 0xc0108fb4 0xc2555f74 0xc010929d do_IRQ+0x105 (0xc01054e0, 0x1, 0xc2554000, 0xc2554000, 0x) kernel .text 0xc0100000 0xc0109198 0xc0109358 0xc02eeaac call_do_IRQ+0x5 kernel .rodata 0xc02ec940 0xc02eeaa7 0xc02eeab4 0xc0105572 cpu_idle+0x3e [1]more> kernel .text 0xc0100000 0xc0105534 0xc0105588 0xc040bc86 start_secondary+0x26 kernel .text.init 0xc0406000 0xc040bc60 0xc040bc8 [1]kdb> 6) I then rebooted and did: with nmi_watchdog=1 mv .config .. make mrproper mv ../.config . make oldconfig make dep clean bzImage modules # install, boot [root@dl02 dbench]# ./dbench 10 ..invalid operand: 0000 CPU: 1 EIP: 0010:[] Not tainted EFLAGS: 00010086 eax: 0000004a ebx: f7573cf0 ecx: c03ed424 edx: 00002ed2 esi: 00000297 edi: f7573c00 ebp: 00000000 esp: f6c8ba5c ds: 0018 es: 0018 ss: 0018 Process dbench (pid: 1155, stackpage=f6c8b000) Stack: c0315760 0000005a 00000000 00000005 00000010 f6c8bcc0 c01bb04d f7573c00 0000001e ffffffeb 00000000 00000010 00000000 c01ba988 f6c8bcc0 00000001 00000000 00000000 f7c73530 00000000 f6c8bb60 00000000 fffe0005 00000010 Call Trace: [] [] [] [] [] [] [] [] [] [] [ [] [] [] [] [] [ [] [] [] [] [] [ Code: 0f 0b 83 c4 08 8d 74 26 00 c6 87 f0 00 00 00 01 56 9d 89 e8 Entering kdb (current=0xf6c8a000, pid 1155) on processor 1 Oops: invalid operand due to oops @ 0xc01f1c47 eax = 0x0000004a ebx = 0xf7573cf0 ecx = 0xc03ed424 edx = 0x00002ed2 esi = 0x00000297 edi = 0xf7573c00 esp = 0xf6c8ba5c eip = 0xc01f1c47 ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086 xds = 0xc0310018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf6c8ba28 [1]kdb> bt EBP EIP Function(args) 0xc01f1c47 xfs_mod_incore_sb+0x93 (0xf7573c00, 0x1e, 0xffffffeb, 0x0) kernel .text 0xc0100000 0xc01f1bb4 0xc01f1c60 0xf6c8bcc0 0xc01bb04d xfs_bmapi+0x6c5 (0x0, 0xf6db2dc0, 0x80, 0x0, 0x10) kernel .text 0xc0100000 0xc01ba988 0xc01bbca4 0xc020fc49 xfs_iomap_write_delay+0x64d (0xf6db2dc0, 0xc4, 0xf6db2ef8) kernel .text 0xc0100000 0xc020f5fc 0xc020fe8c 0xc020d8b8 xfs_zero_last_block+0x680 (0xf6c7f044, 0x80000, 0x0, 0x10) kernel .text 0xc0100000 0xc020d238 0xc020d8e0 0xc0208259 _pagebuf_file_write+0xf1 (0xf72d14b4, 0x804bde8, 0xffbb, ) kernel .text 0xc0100000 0xc0208168 0xc0208390 0xc0208453 pagebuf_generic_file_write+0xc3 (0xf72d14b4, 0x804bde8, 0) kernel .text 0xc0100000 0xc0208390 0xc02086fc 0xc020e0bf xfs_write+0x2bb (0xf6db2dd8, 0xf6c8bf7c, 0x2, 0x0, 0x0) kernel .text 0xc0100000 0xc020de04 0xc020e320 0xc0209a6e linvfs_write+0x2fe (0xf72d14b4, 0x804bde0, 0xffc3, 0xf72d) kernel .text 0xc0100000 0xc0209770 0xc0209abc 0xc0145717 sys_write+0x8f (0x6, 0x804bde0, 0xffc3, 0x10, 0x105d) kernel .text 0xc0100000 0xc0145688 0xc0145858 0xc01077bb system_call+0x33 kernel .text 0xc0100000 0xc0107788 0xc01077c0 [1]kdb> cpu 0 Entering kdb (current=0xf6c7c000, pid 1156) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xf6c7dcc0 0xc01f242d _text_lock_xfs_mount+0xf (0x0, 0xf6c4d9d8, 0x90, 0x0, 0x1) kernel .text 0xc0100000 0xc01f241e 0xc01f2480 0xc020fc49 xfs_iomap_write_delay+0x64d (0xf6c4d9d8, 0xc4, 0xf6c4db10) kernel .text 0xc0100000 0xc020f5fc 0xc020fe8c 0xc020d8b8 xfs_zero_last_block+0x680 (0xf6c35c4c, 0x90000, 0x0, 0x10) kernel .text 0xc0100000 0xc020d238 0xc020d8e0 0xc0208259 _pagebuf_file_write+0xf1 (0xf737d644, 0x804bde9, 0xffba, ) kernel .text 0xc0100000 0xc0208168 0xc0208390 0xc0208453 pagebuf_generic_file_write+0xc3 (0xf737d644, 0x804bde9, 0) kernel .text 0xc0100000 0xc0208390 0xc02086fc 0xc020e0bf xfs_write+0x2bb (0xf6c4d9f0, 0xf6c7df7c, 0x2, 0x0, 0x0) kernel .text 0xc0100000 0xc020de04 0xc020e320 0xc0209a6e linvfs_write+0x2fe (0xf737d644, 0x804bde0, 0xffc3, 0xf737) kernel .text 0xc0100000 0xc0209770 0xc0209abc 0xc0145717 sys_write+0x8f (0x6, 0x804bde0, 0xffc3, 0x10, 0x105d) kernel .text 0xc0100000 0xc0145688 0xc0145858 0xc01077bb system_call+0x33 kernel .text 0xc0100000 0xc0107788 0xc01077c0 [0]kdb> Also: When the system has rebooted, and I try to run dbench on the XFS partition again, it will not run. Eg: root@dl02 dbench]# ./dbench 10 bash: ./dbench: cannot execute binary file [root@dl02 dbench]# file dbench dbench: ASCII text, with no line terminators Thank you for your assistance. Christian From owner-linux-xfs@oss.sgi.com Mon Mar 4 16:06:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2506cE04195 for linux-xfs-outgoing; Mon, 4 Mar 2002 16:06:38 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2505m904105 for ; Mon, 4 Mar 2002 16:05:48 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA23327 for ; Mon, 4 Mar 2002 15:01:20 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA08365 for ; Mon, 4 Mar 2002 17:04:32 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA99814 for ; Mon, 4 Mar 2002 17:04:32 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g24N3fA27485; Mon, 4 Mar 2002 17:03:41 -0600 Message-Id: <200203042303.g24N3fA27485@jen.americas.sgi.com> Date: Mon, 4 Mar 2002 17:03:41 -0600 Subject: TAKE - merge up to 2.5.6-pre2 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 4 15:01:13 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:113254a linux/fs/jfs/jfs_metapage.h - 1.1 linux/drivers/hotplug/ibmphp_res.c - 1.1 linux/Documentation/arm/Interrupts - 1.1 linux/include/asm-arm/arch-sa1100/badge4.h - 1.1 linux/drivers/hotplug/ibmphp_pci.c - 1.1 linux/Documentation/filesystems/jfs.txt - 1.1 linux/fs/jfs/jfs_logmgr.h - 1.1 linux/fs/jfs/jfs_lock.h - 1.1 linux/drivers/hotplug/ibmphp_hpc.c - 1.1 linux/drivers/hotplug/ibmphp_ebda.c - 1.1 linux/fs/jfs/jfs_inode.h - 1.1 linux/drivers/hotplug/ibmphp_core.c - 1.1 linux/drivers/hotplug/ibmphp.h - 1.1 linux/fs/jfs/Makefile - 1.1 linux/arch/arm/boot/compressed/head-epxa10db.S - 1.1 linux/fs/jfs/endian24.h - 1.1 linux/fs/jfs/file.c - 1.1 linux/arch/arm/def-configs/badge4 - 1.1 linux/arch/arm/mm/copypage-v5te.S - 1.1 linux/arch/arm/def-configs/fortunet - 1.1 linux/arch/arm/mm/copypage-v4mc.S - 1.1 linux/arch/arm/def-configs/stork - 1.1 linux/fs/jfs/inode.c - 1.1 linux/arch/arm/mm/copypage-v4.S - 1.1 linux/fs/jfs/jfs_btree.h - 1.1 linux/fs/jfs/jfs_debug.c - 1.1 linux/fs/jfs/jfs_debug.h - 1.1 linux/fs/jfs/jfs_defragfs.h - 1.1 linux/arch/arm/mm/copypage-v3.S - 1.1 linux/fs/jfs/jfs_dinode.h - 1.1 linux/fs/jfs/jfs_dmap.c - 1.1 linux/fs/jfs/jfs_dmap.h - 1.1 linux/fs/jfs/jfs_dtree.c - 1.1 linux/fs/jfs/jfs_dtree.h - 1.1 linux/fs/jfs/jfs_extendfs.h - 1.1 linux/fs/jfs/jfs_inode.c - 1.1 linux/fs/jfs/jfs_extent.c - 1.1 linux/fs/jfs/jfs_incore.h - 1.1 linux/fs/jfs/jfs_imap.h - 1.1 linux/fs/jfs/jfs_imap.c - 1.1 linux/arch/arm/mm/abort-lv4t.S - 1.1 linux/arch/arm/mm/abort-ev5ej.S - 1.1 linux/fs/jfs/jfs_extent.h - 1.1 linux/arch/arm/mm/abort-ev4t.S - 1.1 linux/arch/arm/mm/abort-ev4.S - 1.1 linux/arch/arm/mach-clps711x/fortunet.c - 1.1 linux/fs/jfs/jfs_filsys.h - 1.1 linux/fs/jfs/namei.c - 1.1 linux/fs/jfs/jfs_xtree.h - 1.1 linux/arch/arm/mach-sa1100/stork.c - 1.1 linux/fs/jfs/jfs_xtree.c - 1.1 linux/arch/arm/mach-footbridge/isa-irq.c - 1.1 linux/fs/jfs/jfs_logmgr.c - 1.1 linux/fs/jfs/super.c - 1.1 linux/include/asm-arm/glue.h - 1.1 linux/fs/jfs/symlink.c - 1.1 linux/include/asm-arm/arch-sa1100/stork.h - 1.1 linux/fs/jfs/jfs_uniupr.c - 1.1 linux/arch/arm/mm/tlb-v4wb.S - 1.1 linux/fs/jfs/jfs_mount.c - 1.1 linux/fs/jfs/jfs_superblock.h - 1.1 linux/fs/jfs/jfs_txnmgr.c - 1.1 linux/fs/jfs/jfs_txnmgr.h - 1.1 linux/fs/jfs/jfs_types.h - 1.1 linux/arch/arm/mach-sa1100/badge4.c - 1.1 linux/fs/jfs/jfs_umount.c - 1.1 linux/arch/arm/mm/proc-macros.S - 1.1 linux/arch/arm/mm/tlb-v4.S - 1.1 linux/arch/arm/mm/tlb-v3.S - 1.1 linux/fs/jfs/jfs_unicode.c - 1.1 linux/fs/jfs/jfs_unicode.h - 1.1 linux/fs/jfs/jfs_metapage.c - 1.1 linux/net/sunrpc/xprt.c - 1.23 linux/net/sunrpc/svcsock.c - 1.17 linux/net/sunrpc/svc.c - 1.12 linux/net/sunrpc/stats.c - 1.8 linux/net/sunrpc/sched.c - 1.28 linux/net/sunrpc/clnt.c - 1.16 linux/mm/vmscan.c - 1.95 linux/kernel/ksyms.c - 1.137 linux/kernel/info.c - 1.7 linux/init/main.c - 1.75 linux/include/linux/sunrpc/types.h - 1.4 linux/include/linux/sunrpc/svcsock.h - 1.4 linux/include/linux/sunrpc/svc.h - 1.6 linux/include/linux/sunrpc/sched.h - 1.10 linux/include/linux/parport.h - 1.23 linux/include/linux/nfsd/export.h - 1.11 linux/include/linux/fs.h - 1.156 linux/include/linux/blk.h - 1.30 linux/include/asm-arm/system.h - 1.17 linux/include/asm-arm/procinfo.h - 1.8 linux/include/asm-arm/page.h - 1.15 linux/include/asm-arm/mmu_context.h - 1.10 linux/include/asm-arm/irq.h - 1.3 linux/include/asm-arm/io.h - 1.19 linux/include/asm-arm/bitops.h - 1.11 linux/include/asm-arm/arch-rpc/time.h - 1.8 linux/include/asm-arm/arch-rpc/irq.h - 1.8 linux/include/asm-arm/arch-nexuspci/time.h - 1.9 linux/include/asm-arm/arch-nexuspci/irq.h - 1.6 linux/include/asm-arm/arch-ebsa285/time.h - 1.13 linux/include/asm-arm/arch-ebsa285/irq.h - 1.15 linux/include/asm-arm/arch-ebsa110/time.h - 1.10 linux/include/asm-arm/arch-ebsa110/irq.h - 1.5 linux/include/asm-arm/arch-arc/time.h - 1.8 linux/include/asm-arm/arch-arc/irq.h - 1.8 linux/fs/super.c - 1.78 linux/fs/nls/Config.in - 1.10 linux/fs/nfsd/vfs.c - 1.48 linux/fs/nfsd/nfssvc.c - 1.20 linux/fs/nfsd/nfsproc.c - 1.22 linux/fs/nfsd/nfsfh.c - 1.37 linux/fs/nfsd/nfsctl.c - 1.27 linux/fs/nfsd/nfscache.c - 1.10 linux/fs/nfsd/nfs3proc.c - 1.13 linux/fs/nfsd/lockd.c - 1.8 linux/fs/nfsd/export.c - 1.29 linux/fs/lockd/svcproc.c - 1.10 linux/fs/inode.c - 1.68 linux/fs/buffer.c - 1.113 linux/fs/block_dev.c - 1.42 linux/fs/Makefile - 1.49 linux/fs/Config.in - 1.79 linux/drivers/usb/usb.c - 1.71 linux/drivers/usb/uhci.h - 1.28 linux/drivers/usb/uhci.c - 1.61 linux/drivers/usb/audio.c - 1.41 linux/drivers/scsi/qlogicfas.c - 1.13 linux/drivers/scsi/ide-scsi.c - 1.27 linux/drivers/pci/quirks.c - 1.27 linux/drivers/macintosh/via-pmu.c - 1.18 linux/drivers/char/sysrq.c - 1.22 linux/drivers/char/lp.c - 1.31 linux/drivers/block/ll_rw_blk.c - 1.94 linux/drivers/block/amiflop.c - 1.21 linux/arch/sparc64/kernel/sys_sparc32.c - 1.45 linux/arch/i386/kernel/time.c - 1.20 linux/arch/i386/defconfig - 1.100 linux/arch/arm/mm/proc-sa110.S - 1.24 linux/arch/arm/mm/proc-arm6,7.S - 1.20 linux/arch/arm/mm/proc-arm2,3.S - 1.11 linux/arch/arm/mm/fault-common.c - 1.19 linux/arch/arm/mm/fault-armv.c - 1.21 linux/arch/arm/mm/Makefile - 1.15 linux/arch/arm/lib/io-acorn.S - 1.8 linux/arch/arm/lib/Makefile - 1.21 linux/arch/arm/kernel/traps.c - 1.25 linux/arch/arm/kernel/time.c - 1.14 linux/arch/arm/kernel/signal.c - 1.21 linux/arch/arm/kernel/setup.c - 1.26 linux/arch/arm/kernel/ptrace.c - 1.16 linux/arch/arm/kernel/irq.c - 1.16 linux/arch/arm/kernel/entry-common.S - 1.20 linux/arch/arm/kernel/entry-armv.S - 1.25 linux/arch/arm/kernel/entry-armo.S - 1.13 linux/arch/arm/kernel/ecard.c - 1.18 linux/arch/arm/kernel/armksyms.c - 1.23 linux/arch/arm/config.in - 1.35 linux/arch/arm/boot/compressed/misc.c - 1.5 linux/arch/arm/boot/compressed/Makefile - 1.21 linux/arch/arm/boot/Makefile - 1.11 linux/arch/arm/Makefile - 1.26 linux/Makefile - 1.188 linux/MAINTAINERS - 1.98 linux/Documentation/filesystems/00-INDEX - 1.10 linux/Documentation/Changes - 1.47 linux/CREDITS - 1.75 linux/include/linux/ide.h - 1.40 linux/arch/arm/nwfpe/softfloat.h - 1.2 linux/arch/arm/nwfpe/softfloat.c - 1.3 linux/arch/arm/nwfpe/softfloat-specialize - 1.2 linux/arch/arm/nwfpe/single_cpdo.c - 1.6 linux/arch/arm/nwfpe/fpopcode.c - 1.5 linux/arch/arm/nwfpe/fpmodule.c - 1.10 linux/arch/arm/nwfpe/fpa11_cprt.c - 1.7 linux/arch/arm/nwfpe/fpa11_cpdt.c - 1.7 linux/arch/arm/nwfpe/fpa11.h - 1.5 linux/arch/arm/nwfpe/fpa11.c - 1.8 linux/arch/arm/nwfpe/extended_cpdo.c - 1.7 linux/arch/arm/nwfpe/entry26.S - 1.6 linux/arch/arm/nwfpe/entry.S - 1.6 linux/arch/arm/nwfpe/double_cpdo.c - 1.7 linux/arch/arm/nwfpe/ChangeLog - 1.3 linux/drivers/char/ppdev.c - 1.30 linux/drivers/parport/parport_pc.c - 1.46 linux/include/asm-arm/cpu-single.h - 1.9 linux/include/asm-arm/cpu-multi32.h - 1.9 linux/include/asm-arm/proc-armv/cache.h - 1.12 linux/include/asm-arm/pci.h - 1.18 linux/include/asm-arm/arch-sa1100/irqs.h - 1.7 linux/include/asm-arm/arch-sa1100/irq.h - 1.8 linux/include/asm-arm/arch-sa1100/hardware.h - 1.13 linux/include/asm-arm/arch-cl7500/time.h - 1.8 linux/Documentation/usb/usb-serial.txt - 1.19 linux/drivers/usb/devices.c - 1.16 linux/include/asm-arm/arch-sa1100/ide.h - 1.7 linux/drivers/usb/usb-uhci.c - 1.41 linux/drivers/usb/usb-ohci.c - 1.38 linux/drivers/macintosh/via-pmu68k.c - 1.5 linux/fs/lockd/svc4proc.c - 1.6 linux/include/linux/usb.h - 1.32 linux/drivers/parport/ChangeLog - 1.28 linux/drivers/ide/via82cxxx.c - 1.22 linux/drivers/ide/trm290.c - 1.4 linux/drivers/ide/sl82c105.c - 1.7 linux/drivers/ide/sis5513.c - 1.14 linux/drivers/ide/piix.c - 1.16 linux/drivers/ide/pdc4030.c - 1.10 linux/drivers/ide/pdc202xx.c - 1.15 linux/drivers/ide/opti621.c - 1.6 linux/drivers/ide/ns87415.c - 1.5 linux/drivers/ide/ide_modes.h - 1.5 linux/drivers/ide/ide.c - 1.45 linux/drivers/ide/ide-tape.c - 1.20 linux/drivers/ide/ide-proc.c - 1.13 linux/drivers/ide/ide-probe.c - 1.25 linux/drivers/ide/ide-pnp.c - 1.6 linux/drivers/ide/ide-pci.c - 1.21 linux/drivers/ide/ide-geometry.c - 1.10 linux/drivers/ide/ide-floppy.c - 1.17 linux/drivers/ide/ide-features.c - 1.10 linux/drivers/ide/ide-dma.c - 1.20 linux/drivers/ide/ide-disk.c - 1.26 linux/drivers/ide/ide-cd.c - 1.27 linux/drivers/ide/ht6560b.c - 1.4 linux/drivers/ide/hpt366.c - 1.13 linux/drivers/ide/hpt34x.c - 1.7 linux/drivers/ide/cy82c693.c - 1.7 linux/drivers/ide/cs5530.c - 1.6 linux/drivers/ide/cmd64x.c - 1.9 linux/drivers/ide/cmd640.c - 1.5 linux/drivers/ide/alim15x3.c - 1.12 linux/drivers/ide/ali14xx.c - 1.5 linux/fs/nfs/flushd.c - 1.12 linux/include/asm-arm/arch-shark/time.h - 1.8 linux/include/asm-arm/arch-shark/param.h - 1.4 linux/include/asm-arm/arch-shark/keyboard.h - 1.7 linux/include/asm-arm/arch-shark/irq.h - 1.5 linux/drivers/usb/serial/keyspan_pda.c - 1.22 linux/drivers/usb/serial/ftdi_sio.c - 1.32 linux/drivers/usb/serial/usbserial.c - 1.31 linux/drivers/usb/serial/whiteheat.c - 1.22 linux/drivers/usb/serial/visor.h - 1.9 linux/drivers/usb/serial/visor.c - 1.31 linux/include/asm-arm/arch-shark/hardware.h - 1.6 linux/drivers/ide/aec62xx.c - 1.5 linux/drivers/usb/serial/omninet.c - 1.21 linux/include/asm-arm/arch-sa1100/time.h - 1.5 linux/include/asm-arm/arch-l7200/time.h - 1.6 linux/include/asm-arm/arch-l7200/irq.h - 1.4 linux/drivers/usb/serial/keyspan.c - 1.23 linux/fs/jffs/intrep.c - 1.12 linux/arch/arm/mm/proc-arm720.S - 1.10 linux/include/asm-arm/arch-sa1100/assabet.h - 1.9 linux/drivers/mtd/mtdblock.c - 1.13 linux/drivers/mtd/mtdchar.c - 1.9 linux/include/linux/nfsd/interface.h - 1.3 linux/include/linux/irq_cpustat.h - 1.5 linux/fs/nfs/unlink.c - 1.5 linux/arch/arm/tools/mach-types - 1.13 linux/arch/arm/mach-footbridge/netwinder-hw.c - 1.3 linux/arch/arm/mach-footbridge/Makefile - 1.6 linux/drivers/md/lvm.c - 1.29 linux/arch/arm/def-configs/shark - 1.4 linux/arch/arm/kernel/via82c505.c - 1.5 linux/arch/arm/mach-shark/pci.c - 1.2 linux/arch/arm/mm/proc-arm920.S - 1.7 linux/arch/arm/mm/proc-syms.c - 1.2 linux/drivers/md/md.c - 1.40 linux/include/asm-arm/arch-tbox/irq.h - 1.3 linux/include/asm-arm/arch-tbox/time.h - 1.5 linux/drivers/ide/slc90e66.c - 1.7 linux/drivers/usb/serial/belkin_sa.c - 1.17 linux/drivers/video/sis/sis_main.c - 1.10 linux/drivers/usb/serial/mct_u232.c - 1.16 linux/drivers/usb/serial/empeg.c - 1.20 linux/arch/arm/lib/ecard.S - 1.2 linux/drivers/usb/serial/Config.in - 1.12 linux/include/asm-arm/mmu.h - 1.2 linux/fs/reiserfs/super.c - 1.19 linux/fs/reiserfs/bitmap.c - 1.14 linux/drivers/s390/block/xpram.c - 1.12 linux/include/asm-arm/mach/irq.h - 1.3 linux/include/asm-arm/arch-integrator/time.h - 1.4 linux/include/asm-arm/arch-integrator/irq.h - 1.2 linux/arch/arm/mach-integrator/irq.c - 1.2 linux/arch/arm/mach-integrator/pci.c - 1.4 linux/arch/arm/mach-integrator/pci_v3.c - 1.6 linux/arch/arm/mach-footbridge/irq.c - 1.2 linux/drivers/mtd/nftlcore.c - 1.11 linux/drivers/mtd/mtdblock_ro.c - 1.6 linux/drivers/usb/serial/cyberjack.c - 1.10 linux/drivers/usb/serial/pl2303.c - 1.11 linux/drivers/parport/parport_serial.c - 1.7 linux/drivers/ide/serverworks.c - 1.5 linux/drivers/ide/it8172.c - 1.3 linux/drivers/ide/amd74xx.c - 1.4 linux/arch/arm/mach-sa1100/simpad.c - 1.5 linux/arch/arm/mach-sa1100/sa1111.c - 1.4 linux/include/asm-arm/arch-anakin/irq.h - 1.2 linux/include/asm-arm/arch-anakin/time.h - 1.3 linux/arch/arm/mach-sa1100/neponset.c - 1.5 linux/arch/arm/mach-sa1100/jornada720.c - 1.4 linux/arch/arm/mach-sa1100/irq.c - 1.4 linux/arch/arm/mach-sa1100/graphicsclient.c - 1.6 linux/arch/arm/mach-sa1100/assabet.c - 1.5 linux/arch/arm/mach-sa1100/cerf.c - 1.5 linux/drivers/ide/qd65xx.c - 1.3 linux/drivers/usb/hid-core.c - 1.9 linux/fs/jffs2/dir.c - 1.8 linux/fs/jffs2/erase.c - 1.5 linux/fs/jffs2/file.c - 1.5 linux/fs/jffs2/gc.c - 1.6 linux/fs/jffs2/malloc.c - 1.3 linux/fs/jffs2/nodelist.c - 1.4 linux/fs/jffs2/nodelist.h - 1.3 linux/fs/jffs2/nodemgmt.c - 1.4 linux/fs/jffs2/read.c - 1.3 linux/fs/jffs2/readinode.c - 1.4 linux/fs/jffs2/scan.c - 1.4 linux/fs/jffs2/super.c - 1.7 linux/fs/jffs2/symlink.c - 1.2 linux/include/linux/jffs2_fs_sb.h - 1.3 linux/include/linux/jffs2.h - 1.2 linux/drivers/mtd/devices/blkmtd.c - 1.7 linux/drivers/usb/serial/ir-usb.c - 1.10 linux/arch/arm/mach-sa1100/h3600.c - 1.5 linux/arch/arm/mach-sa1100/graphicsmaster.c - 1.5 linux/drivers/message/i2o/i2o_block.c - 1.12 linux/drivers/net/8139cp.c - 1.8 linux/arch/arm/def-configs/epxa10db - 1.2 linux/arch/arm/mach-epxa10db/irq.c - 1.2 linux/include/asm-arm/arch-epxa10db/irq.h - 1.2 linux/arch/arm/mach-sa1100/pm.c - 1.3 linux/include/asm-arm/arch-epxa10db/time.h - 1.4 linux/include/asm-arm/arch-epxa10db/uncompress.h - 1.2 linux/arch/arm/mm/proc-arm1020.S - 1.3 linux/arch/arm/mm/proc-arm926.S - 1.3 linux/fs/intermezzo/inode.c - 1.3 linux/drivers/hotplug/pci_hotplug_core.c - 1.6 linux/drivers/hotplug/cpqphp_proc.c - 1.2 linux/drivers/hotplug/Makefile - 1.2 linux/fs/intermezzo/presto.c - 1.6 linux/fs/intermezzo/super.c - 1.4 linux/fs/intermezzo/vfs.c - 1.4 linux/include/linux/intermezzo_fs.h - 1.3 linux/drivers/hotplug/Config.in - 1.2 linux/fs/intermezzo/cache.c - 1.4 linux/Documentation/driver-model.txt - 1.2 linux/drivers/usb/hcd/ehci-mem.c - 1.3 linux/drivers/usb/hcd.c - 1.9 linux/drivers/usb/hcd.h - 1.2 linux/drivers/usb/hcd/ehci-hcd.c - 1.6 linux/drivers/usb/hcd/ehci-hub.c - 1.4 linux/drivers/usb/hcd/ehci-q.c - 1.6 linux/drivers/usb/hcd/ehci-sched.c - 1.5 linux/drivers/usb/serial/ipaq.c - 1.3 linux/drivers/usb/serial/ipaq.h - 1.2 linux/drivers/usb/serial/kl5kusb105.c - 1.4 linux/arch/arm/mm/proc-xscale.S - 1.2 linux/arch/arm/mm/proc-arm922.S - 1.2 linux/arch/arm/mm/minicache.c - 1.2 linux/arch/arm/mm/armv5ej-early-abort.S - 1.2 linux/arch/arm/mm/armv4t-late-abort.S - 1.2 linux/arch/arm/mm/armv4t-early-abort.S - 1.2 linux/arch/arm/mm/armv4-early-abort.S - 1.2 linux/arch/arm/mach-shark/irq.c - 1.2 linux/include/asm-arm/arch-adifcc/irq.h - 1.2 linux/include/asm-arm/arch-adifcc/irqs.h - 1.2 linux/arch/arm/lib/copy_page-armv3.S - 1.2 linux/arch/arm/lib/copy_page-armv4.S - 1.2 linux/arch/arm/lib/copy_page-armv4mc.S - 1.2 linux/arch/arm/lib/copy_page-armv5te.S - 1.2 linux/arch/arm/mach-arc/dma.c - 1.2 linux/arch/arm/mach-clps711x/Makefile - 1.2 linux/arch/arm/mach-clps711x/irq.c - 1.2 linux/include/asm-arm/arch-iop310/irq.h - 1.2 linux/arch/arm/mach-ebsa110/core.c - 1.2 linux/arch/arm/mach-iop310/iop310-irq.c - 1.3 linux/arch/arm/mach-iop310/iop310-pci.c - 1.2 linux/arch/arm/mach-iop310/iq80310-irq.c - 1.3 linux/arch/arm/mach-iop310/iq80310-time.c - 1.2 linux/arch/arm/mach-iop310/xs80200-irq.c - 1.3 linux/arch/arm/mach-rpc/irq.c - 1.2 linux/include/asm-arm/arch-clps711x/time.h - 1.2 linux/include/asm-arm/arch-clps711x/irq.h - 1.2 linux/drivers/usb/auerswald.c - 1.7 linux/Documentation/usb/auerswald.txt - 1.2 linux/arch/arm/kernel/debug.S - 1.2 linux/arch/arm/kernel/head.S - 1.3 linux/arch/arm/mach-rpc/dma.c - 1.2 linux/fs/xfs/pagebuf/page_buf_io.c - 1.14 linux/drivers/ide/ide-taskfile.c - 1.5 linux/drivers/ide/pdcadma.c - 1.2 linux/drivers/usb/hcd/ohci-q.c - 1.4 linux/arch/arm/Config.help - 1.5 linux/fs/Config.help - 1.3 linux/drivers/video/Config.help - 1.3 linux/drivers/usb/serial/Config.help - 1.2 linux/drivers/char/Config.help - 1.3 linux/drivers/hotplug/Config.help - 1.2 linux/drivers/input/joystick/grip.c - 1.2 linux/drivers/input/joystick/gf2k.c - 1.2 linux/drivers/input/joystick/gamecon.c - 1.2 linux/drivers/input/joystick/db9.c - 1.2 linux/drivers/input/joystick/cobra.c - 1.2 linux/drivers/input/joystick/analog.c - 1.2 linux/drivers/input/joystick/amijoy.c - 1.2 linux/drivers/input/joystick/adi.c - 1.2 linux/drivers/input/joystick/a3d.c - 1.2 linux/drivers/input/joystick/interact.c - 1.2 linux/drivers/input/gameport/ns558.c - 1.2 linux/drivers/input/gameport/lightning.c - 1.2 linux/drivers/input/gameport/gameport.c - 1.2 linux/drivers/input/gameport/emu10k1-gp.c - 1.3 linux/drivers/input/gameport/cs461x.c - 1.3 linux/drivers/input/joystick/magellan.c - 1.2 linux/drivers/input/joystick/sidewinder.c - 1.2 linux/drivers/input/joystick/spaceball.c - 1.2 linux/drivers/input/joystick/spaceorb.c - 1.2 linux/drivers/input/joystick/stinger.c - 1.2 linux/drivers/input/joystick/tmdc.c - 1.2 linux/drivers/input/joystick/turbografx.c - 1.2 linux/drivers/input/joystick/warrior.c - 1.2 linux/drivers/input/serio/serio.c - 1.2 linux/drivers/input/serio/serport.c - 1.2 linux/arch/x86_64/config.in - 1.3 linux/arch/x86_64/defconfig - 1.2 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.2 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.2 linux/arch/x86_64/ia32/ia32_signal.c - 1.2 linux/arch/x86_64/kernel/process.c - 1.2 linux/arch/x86_64/kernel/ptrace.c - 1.2 linux/arch/x86_64/kernel/signal.c - 1.2 linux/arch/x86_64/kernel/time.c - 1.2 linux/arch/x86_64/kernel/vsyscall.c - 1.2 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.2 linux/arch/x86_64/mm/fault.c - 1.2 linux/arch/x86_64/mm/init.c - 1.2 linux/arch/x86_64/mm/ioremap.c - 1.2 linux/arch/x86_64/tools/offset.c - 1.2 linux/include/asm-x86_64/pgtable.h - 1.3 linux/include/asm-x86_64/pgalloc.h - 1.2 linux/include/asm-x86_64/pda.h - 1.2 linux/include/asm-x86_64/page.h - 1.2 linux/include/asm-x86_64/mmu_context.h - 1.2 linux/include/asm-x86_64/bitops.h - 1.2 linux/include/asm-x86_64/system.h - 1.2 linux/arch/ppc64/kernel/sys_ppc32.c - 1.2 linux/drivers/net/e1000/e1000_main.c - 1.2 linux/drivers/net/e1000/e1000.h - 1.2 From owner-linux-xfs@oss.sgi.com Mon Mar 4 16:29:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g250TBu04707 for linux-xfs-outgoing; Mon, 4 Mar 2002 16:29:11 -0800 Received: from cellus.no (ns.smssiden.com [193.91.191.71] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g250Su904684 for ; Mon, 4 Mar 2002 16:28:56 -0800 Received: from christian ([193.69.127.56]) by cellus.no (8.9.3/8.9.3) with SMTP id AAA31370; Tue, 5 Mar 2002 00:28:44 +0100 From: =?iso-8859-1?Q?Christian_R=F8snes?= To: "Austin Gonyou" , "Keith Owens" Cc: Subject: RE: Linux 2.4.18 freeze running dbench 1.3 Date: Tue, 5 Mar 2002 00:28:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1015282274.23562.0.camel@UberGeek> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MIME-Autoconverted: from 8bit to quoted-printable by cellus.no id AAA31370 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g250Sv904685 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I did a complete new checkout just now to an ext2 partition. Rebuild and got: root@dl02 dbench]# ./dbench 10 10 clients started .......invalid operand: 0000 CPU: 1 EIP: 0010:[] Not tainted EFLAGS: 00010086 eax: 00000047 ebx: f75734f0 ecx: c03e9e44 edx: 00002eec esi: 00000206 edi: f7573400 ebp: 00000000 esp: f6dd9954 ds: 0018 es: 0018 ss: 0018 Process dbench (pid: 1164, stackpage=f6dd9000) Stack: c0313b00 0000005a 00000005 f6152c20 00000040 00000000 c01b4a59 f7573400 0000001e 00000005 00000000 00000000 00000001 f6152bbc f6dd9cc0 f6152c20 00000005 00000000 00000084 f63cdd80 0000000a 00000000 00000005 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [ [] [] [] [] [] [ [] [] [] [] [] [ [] [] [] Code: 0f 0b 83 c4 08 8d 74 26 00 c6 87 f0 00 00 00 01 56 9d 89 e8 Entering kdb (current=0xf6dd8000, pid 1164) on processor 1 Oops: invalid operand due to oops @ 0xc01f1d37 eax = 0x00000047 ebx = 0xf75734f0 ecx = 0xc03e9e44 edx = 0x00002eec esi = 0x00000206 edi = 0xf7573400 esp = 0xf6dd9954 eip = 0xc01f1d37 ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086 xds = 0xc0310018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf6dd9920 [1]kdb> bt EBP EIP Function(args) 0xc01f1d37 xfs_mod_incore_sb+0x93 (0xf7573400, 0x1e, 0x5, 0x0) kernel .text 0xc0100000 0xc01f1ca4 0xc01f1d50 0xc01b4a59 xfs_bmap_add_extent_hole_delay+0x4d9 (0xf6152bbc, 0x1, 0x) kernel .text 0xc0100000 0xc01b4580 0xc01b4a74 0xc01b15a3 xfs_bmap_add_extent+0x157 (0xf6152bbc, 0x1, 0xf6dd9b30, 0) kernel .text 0xc0100000 0xc01b144c 0xc01b18b8 0xc01bb487 xfs_bmapi+0xaff (0x0, 0xf6152bbc, 0x30, 0x0, 0x10) kernel .text 0xc0100000 0xc01ba988 0xc01bbca4 0xc020fd69 xfs_iomap_write_delay+0x64d (0xf6152bbc, 0xc4, 0xf6152cf4) kernel .text 0xc0100000 0xc020f71c 0xc020ffac 0xc020d9d8 xfs_zero_last_block+0x680 (0xf63cdc4c, 0x30000, 0x0, 0x10) kernel .text 0xc0100000 0xc020d358 0xc020da00 0xc0208379 _pagebuf_file_write+0xf1 (0xf6aed654, 0x804bde3, 0xffc0, ) kernel .text 0xc0100000 0xc0208288 0xc02084b0 0xc0208573 pagebuf_generic_file_write+0xc3 (0xf6aed654, 0x804bde3, 0) kernel .text 0xc0100000 0xc02084b0 0xc020881c 0xc020e1df xfs_write+0x2bb (0xf6152bd4, 0xf6dd9f7c, 0x2, 0x0, 0x0) kernel .text 0xc0100000 0xc020df24 0xc020e440 0xc0209b8e linvfs_write+0x2fe (0xf6aed654, 0x804bde0, 0xffc3, 0xf6ae) kernel .text 0xc0100000 0xc0209890 0xc0209bdc 0xc0145717 sys_write+0x8f (0x6, 0x804bde0, 0xffc3, 0x10, 0x105e) [1]more> kernel .text 0xc0100000 0xc0145688 0xc0145858 0xc01077bb system_call+0x33 kernel .text 0xc0100000 0xc0107788 0xc01077c0 [1]kdb> cpu 0 Entering kdb (current=0xf6234000, pid 1166) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xf6235cc0 0xc01f251d _text_lock_xfs_mount+0xf (0x0, 0xf61535f0, 0x20, 0x0, 0x1) kernel .text 0xc0100000 0xc01f250e 0xc01f2570 0xc020fd69 xfs_iomap_write_delay+0x64d (0xf61535f0, 0xc4, 0xf6153728) kernel .text 0xc0100000 0xc020f71c 0xc020ffac 0xc020d9d8 xfs_zero_last_block+0x680 (0xf6407d6c, 0x20000, 0x0, 0x10) kernel .text 0xc0100000 0xc020d358 0xc020da00 0xc0208379 _pagebuf_file_write+0xf1 (0xf65b43d4, 0x804bde2, 0xffc1, ) kernel .text 0xc0100000 0xc0208288 0xc02084b0 0xc0208573 pagebuf_generic_file_write+0xc3 (0xf65b43d4, 0x804bde2, 0) kernel .text 0xc0100000 0xc02084b0 0xc020881c 0xc020e1df xfs_write+0x2bb (0xf6153608, 0xf6235f7c, 0x2, 0x0, 0x0) kernel .text 0xc0100000 0xc020df24 0xc020e440 0xc0209b8e linvfs_write+0x2fe (0xf65b43d4, 0x804bde0, 0xffc3, 0xf65b) kernel .text 0xc0100000 0xc0209890 0xc0209bdc 0xc0145717 sys_write+0x8f (0x6, 0x804bde0, 0xffc3, 0x10, 0x105e) kernel .text 0xc0100000 0xc0145688 0xc0145858 0xc01077bb system_call+0x33 kernel .text 0xc0100000 0xc0107788 0xc01077c0 [0]kdb> > -----Original Message----- > From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On > Behalf Of Austin Gonyou > Sent: 4. mars 2002 23:51 > To: Keith Owens > Cc: Christian Rřsnes; linux-xfs@oss.sgi.com > Subject: Re: Linux 2.4.18 freeze running dbench 1.3 > > > As a side note, > > make mrproper or use refined kernel sources. > From owner-linux-xfs@oss.sgi.com Mon Mar 4 17:17:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g251H7f05828 for linux-xfs-outgoing; Mon, 4 Mar 2002 17:17:07 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g251Gx905806 for ; Mon, 4 Mar 2002 17:16:59 -0800 Received: (qmail 24701 invoked by uid 500); 5 Mar 2002 00:16:26 -0000 Subject: RE: Linux 2.4.18 freeze running dbench 1.3 From: Austin Gonyou To: Christian =?ISO-8859-1?Q?R=F8snes?= Cc: Keith Owens , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.2 Date: 04 Mar 2002 18:16:26 -0600 Message-Id: <1015287386.24622.3.camel@UberGeek> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g251H0905807 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Did you run that test on EXT2 or did you just build your kernel on EXT2, or did you run dbench FROM EXT2? Also, are you running XFS as a kernel module or built-in? Is dmapi turned on? On Mon, 2002-03-04 at 17:28, Christian Rřsnes wrote: ... > kernel .text 0xc0100000 0xc0145688 > 0xc0145858 > 0xc01077bb system_call+0x33 > kernel .text 0xc0100000 0xc0107788 > 0xc01077c0 > [0]kdb> > > > -----Original Message----- > > From: owner-linux-xfs@oss.sgi.com > [mailto:owner-linux-xfs@oss.sgi.com]On > > Behalf Of Austin Gonyou > > Sent: 4. mars 2002 23:51 > > To: Keith Owens > > Cc: Christian Rřsnes; linux-xfs@oss.sgi.com > > Subject: Re: Linux 2.4.18 freeze running dbench 1.3 > > > > > > As a side note, > > > > make mrproper or use refined kernel sources. > > > -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Mar 4 18:10:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g252Ad306778 for linux-xfs-outgoing; Mon, 4 Mar 2002 18:10:39 -0800 Received: from web21103.mail.yahoo.com (web21103.mail.yahoo.com [216.136.227.105]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g252AX906756 for ; Mon, 4 Mar 2002 18:10:33 -0800 Message-ID: <20020305011032.25259.qmail@web21103.mail.yahoo.com> Received: from [12.234.153.47] by web21103.mail.yahoo.com via HTTP; Mon, 04 Mar 2002 17:10:32 PST Date: Mon, 4 Mar 2002 17:10:32 -0800 (PST) From: Glow Nair Subject: any help in restoring my filesystems To: 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 Hi :) I have SGI XFS installed on my computers here; and for some reason, I've had two of my machines just stop booting (a bit of a coincidence). Both of them are on UPS, so i'd suspect that I did something wrong or that the machines got badly hacked into. I'd appreciate *any* help that I could get. Is there some kind of link that tells me the various steps to go through for restoring my filesystems? (Eric.. thanks for helping me out) This of course assumes that my computer didnt get hacked into.. :) and no one deleted all my files, partitions and everything..:) Here are the error messages I get. (i just typed these in) ================ Partition check: sda: sda1 sda2 < sda4 sda6 sda7 sda8> (scsi0:0:8:0) Synchronous at 80.0 Mbyte/sec, offset 30. SCSI device sdb: 1796240 512-byte hdwr sectors (9173 MB) sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 sdb9> Start mounting fileseystem: sd(8,17) XDS: WARNING: recovery required on readonly filesystem XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17) Ending XFS recovery on filesystem: sd(8,17) (dev: 8/17) VFS: Mounted root (xfs filesystem) readonly Trying to unmount old root... okay Freeing unused kernel memory: 240K freed Warning: unable to open an intial console Kernel panic: No init found. Try passing init= option to kernel ================ Thanks for your help.. Good old yahoo still works Glow 408-343-1112 __________________________________________________ Do You Yahoo!? Yahoo! Sports - sign up for Fantasy Baseball http://sports.yahoo.com From owner-linux-xfs@oss.sgi.com Mon Mar 4 20:09:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2549kR09133 for linux-xfs-outgoing; Mon, 4 Mar 2002 20:09:46 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2549d909110 for ; Mon, 4 Mar 2002 20:09:39 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id EAA1274083 for ; Tue, 5 Mar 2002 04:13:23 +0100 (CET) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA27205; Tue, 5 Mar 2002 14:08:17 +1100 (EST) Date: Tue, 5 Mar 2002 14:08:17 +1100 (EST) From: Nathan Scott Message-Id: <200203050308.OAA27205@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: TAKE - attr/acl updates Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 4 19:06:25 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:113283a acl/VERSION - 1.20 acl/doc/CHANGES - 1.23 acl/debian/changelog - 1.14 attr/VERSION - 1.15 attr/doc/CHANGES - 1.17 attr/debian/changelog - 1.16 attr/test/run - 1.2 acl/setfacl/setfacl.c - 1.3 acl/setfacl/sequence.c - 1.2 acl/setfacl/parse.h - 1.2 acl/setfacl/parse.c - 1.2 acl/setfacl/do_set.c - 1.3 acl/test/getfacl-noacl.test - 1.2 acl/test/run - 1.2 - merge changes from Andreas - test scripts updates, setfacl bug fix. acl/include/config.h - 1.3 - remove from tree, this is a generated file. From owner-linux-xfs@oss.sgi.com Mon Mar 4 20:34:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g254Y7o09523 for linux-xfs-outgoing; Mon, 4 Mar 2002 20:34:07 -0800 Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.25.148.40]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g254Y3909501 for ; Mon, 4 Mar 2002 20:34:03 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g253Y1Xt024467; Tue, 5 Mar 2002 14:34:01 +1100 (EST) Received: from jdc.local (ppp201.dyn141.pacific.net.au [210.23.141.201]) by wisma.pacific.net.au with ESMTP id OAA04013; Tue, 5 Mar 2002 14:33:59 +1100 (EST) Received: from jdc.local (LOCALHOST [127.0.0.1]) by jdc.local (8.12.1/8.12.1/Debian -5) with ESMTP id g253XwTc002978; Tue, 5 Mar 2002 14:33:58 +1100 Received: (from jason@localhost) by jdc.local (8.12.1/8.12.1/Debian -5) id g253XsVT002958; Tue, 5 Mar 2002 14:33:54 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15492.15522.26083.272350@jdc.local> Date: Tue, 5 Mar 2002 14:33:54 +1100 To: Glow Nair CC: linux-xfs@oss.sgi.com Subject: Re: any help in restoring my filesystems In-Reply-To: <20020305011032.25259.qmail@web21103.mail.yahoo.com> References: <20020305011032.25259.qmail@web21103.mail.yahoo.com> X-Mailer: VM 7.01 under Emacs 20.7.2 Reply-To: jasonw@ariel.ucs.unimelb.edu.au Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I would suggest visiting http://lbt.linuxcare.com/ and downloading (or otherwise obtaining) an LBT CD. With this you should be able to boot the system from CD, then mount the XFS filesystems manually, running xfs_repair if necessary. Actually it would probably be best to run xfs_check first on each of the filesystems, followed by xfs_repair if errors are reported. >From the log messages you posted, however, it appears that init (and possibly other critical system files) may have been lost, or perhaps deleted if crackers have been at work. From owner-linux-xfs@oss.sgi.com Mon Mar 4 20:58:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g254wtQ09981 for linux-xfs-outgoing; Mon, 4 Mar 2002 20:58:55 -0800 Received: from mta5.srv.hcvlny.cv.net (mta5.srv.hcvlny.cv.net [167.206.5.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g254wn909958 for ; Mon, 4 Mar 2002 20:58:49 -0800 Received: from nic.com (ool-4350f032.dyn.optonline.net [67.80.240.50]) by mta2.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GSH000C5F1Y9K@mta2.srv.hcvlny.cv.net> for linux-xfs@oss.sgi.com; Mon, 04 Mar 2002 22:58:46 -0500 (EST) Date: Mon, 04 Mar 2002 22:37:53 -0500 From: John W Subject: Million files or so on RAID 5 Partition To: linux-xfs@oss.sgi.com Reply-to: jwest@nic.com Message-id: <3C843D91.703130C6@nic.com> Organization: Long Pond Industries MIME-version: 1.0 X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP22) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello all, I have a 8 disk RAID 5 partition (8 X 9 GB) on a split bus Compaq array that currently has around 1 million files on it. Some tiny, some 5 MB. Controllers are Sym53C875 (non bootable compaq flavor). Doing any kind of removal or listing seems to take waaaay too long, an ls in a dir with 200 files will take 5 seconds to return. :^/ Any thoughts on Kernel tuning/adjustment to speed this up? Its a custom kernel with the Sym53C875 parts in the kernel. IIRC, I was getting around 200 Interrupts per second when doing some 'rm -rf' operations. Xsysinfo showed the IRQs for Network card and scsi controllers were pegged during NFS/Rsync load. Machine Asus P2B-DS 2X 400 MHz, 256 MB RAM. Thanks! John W. BTW- Had a power outage that put the array into a bit of a spin. When it booted, it stalled on mounting the RAID 5 partition, and one disk was marked as bad... I rebooted, and the array came back up, but one disk light was out... marked as bad. I did the addhotspare and it came back online (Phew!). # Inspire Growth # From owner-linux-xfs@oss.sgi.com Mon Mar 4 21:10:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g255AY610308 for linux-xfs-outgoing; Mon, 4 Mar 2002 21:10:34 -0800 Received: from mta10.srv.hcvlny.cv.net (mta10.srv.hcvlny.cv.net [167.206.5.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g255AP910286 for ; Mon, 4 Mar 2002 21:10:26 -0800 Received: from nic.com (ool-4350f032.dyn.optonline.net [67.80.240.50]) by mta10.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GSH00GJBFLC20@mta10.srv.hcvlny.cv.net> for linux-xfs@oss.sgi.com; Mon, 04 Mar 2002 23:10:25 -0500 (EST) Date: Mon, 04 Mar 2002 22:49:35 -0500 From: John W Subject: RedHat or XFS/NFS? To: linux-xfs@oss.sgi.com Reply-to: jwest@nic.com Message-id: <3C84404F.BAB3EE8F@nic.com> Organization: Long Pond Industries MIME-version: 1.0 X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP22) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello All, Have an Indy on home network, running 6.5.9 and a linux NFS client running RHL 7.2 and Kernel 2.4.17-xfs. When I cd into a NFS mounted dir from Linux client, I seem to have issues with File operations. (linux-XFS box mounts SGI volume as NFSV2 via fstab entry). radial 3% ls -la .log* ls: No match. radial 4% ls -al .login -rwxrwxrwx 1 joker99 users 1467 Apr 16 2000 .login radial 5% So it looks like an NFS related issue? Snoop trace from SGI Indy powerhouse server :^) (ls -la .log* - above yields following:) radial -> crank NFS C LOOKUP2 FH=AC18 -C crank -> radial NFS R LOOKUP2 No such file or directory radial -> crank NFS C LOOKUP2 FH=AC18 -al crank -> radial NFS R LOOKUP2 No such file or directory radial -> crank NFS C GETATTR2 FH=AC18 crank -> radial NFS R GETATTR2 OK radial -> crank NFS C READDIR2 FH=AC18 Cookie=0 crank -> radial NFS R READDIR2 OK 0+ entries (incomplete) crank -> radial UDP continuation ID=20820 crank -> radial UDP continuation ID=20820 radial -> crank NFS C READDIR2 FH=AC18 Cookie=913810309 crank -> radial NFS R READDIR2 OK 0+ entries (incomplete) crank -> radial UDP continuation ID=20821 crank -> radial UDP continuation ID=20821 radial -> crank NFS C READDIR2 FH=AC18 Cookie=2040705243 crank -> radial NFS R READDIR2 OK 0+ entries (incomplete) crank -> radial UDP continuation ID=20822 crank -> radial UDP continuation ID=20822 radial -> crank NFS C READDIR2 FH=AC18 Cookie=3514359216 crank -> radial NFS R READDIR2 OK 0+ entries (incomplete) crank -> radial UDP continuation ID=20823 crank -> radial TELNET C port=1212 radial -> crank TELNET R port=1212 ls: No match.\r\nradia crank -> radial TELNET C port=1212 ( ls -al .login from above yields:) radial -> crank NFS C GETATTR2 FH=5745 crank -> radial NFS R GETATTR2 OK crank -> radial TELNET C port=1212 ls -al .login\n radial -> crank TELNET R port=1212 l crank -> radial TELNET C port=1212 radial -> crank TELNET R port=1212 s -al .login\r\0\r\n-rwx crank -> radial TELNET C port=1212 Thanks All! John W. # Inspire Growth # From owner-linux-xfs@oss.sgi.com Mon Mar 4 22:22:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g256MU411583 for linux-xfs-outgoing; Mon, 4 Mar 2002 22:22:30 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g256ML911561 for ; Mon, 4 Mar 2002 22:22:21 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA04828 for ; Mon, 4 Mar 2002 21:22:24 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA92891; Tue, 5 Mar 2002 16:21:03 +1100 (EST) Date: Tue, 5 Mar 2002 16:21:03 +1100 (EST) From: Nathan Scott Message-Id: <200203050521.QAA92891@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, jack@ucw.cz Subject: TAKE - Even newer VFS quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is Jan's latest set of VFS quota patches. These patches (which were posted to LKML on the weekend) allow the two VFS quota formats and quotactl interfaces to coexist. All seems stable on my machine. If you're one of the people merging XFS with Alan Cox's patches, you should first reverse-apply Jan's old patches (which removes the old 32 bit UID/GID quota from Alan's patches, and then apply the new code from the XFS CVS tree (which "re-applies" the 32 bit UID/GID quota patches, but now using Jan's new mechanisms). Please let us know of any quota oddities you see in the CVS tree. cheers. [ ps: 2.5 port is next. ] Date: Mon Mar 4 21:05:36 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:113294a cmd/xfsmisc/README - 1.9 - Update with Jan's latest round of patches. Now allows co-existance of the old and new VFS quota formats/quotactl operations. Modid: 2.4.x-xfs:slinx:113294b linux/include/linux/quotacompat.h - 1.1 linux/include/linux/quotaio_v2.h - 1.1 linux/fs/quota_v2.c - 1.1 linux/include/linux/dqblk_v1.h - 1.1 linux/include/linux/dqblk_v2.h - 1.1 linux/fs/quota_v1.c - 1.1 linux/include/linux/quotaio_v1.h - 1.1 linux/include/linux/quotaops.h - 1.13 linux/include/linux/quota.h - 1.9 linux/include/linux/fs.h - 1.144 linux/include/asm-sparc64/ioctls.h - 1.4 linux/include/asm-sparc/ioctls.h - 1.4 linux/include/asm-m68k/ioctls.h - 1.4 linux/include/asm-i386/ioctls.h - 1.4 linux/include/asm-alpha/ioctls.h - 1.6 linux/fs/super.c - 1.74 linux/fs/ioctl.c - 1.13 linux/fs/inode.c - 1.62 linux/fs/dquot.c - 1.46 linux/fs/Config.in - 1.76 linux/arch/sparc64/kernel/sys_sparc32.c - 1.42 linux/Documentation/Configure.help - 1.126 linux/include/asm-sh/ioctls.h - 1.5 linux/arch/ia64/ia32/sys_ia32.c - 1.20 linux/include/asm-ia64/ioctls.h - 1.3 linux/include/asm-parisc/ioctls.h - 1.3 linux/include/asm-cris/ioctls.h - 1.3 linux/fs/quota.c - 1.6 - Update with Jan's latest round of patches. Now allows co-existance of the old and new VFS quota formats/quotactl operations. linux/fs/xfs/linux/xfs_super.c - 1.161 - Update to match minor field renaming from Jan's new patches. linux/fs/xfs/xfs_qm_syscalls.c - 1.56 linux/fs/xfs/xfs_qm.h - 1.21 - Type of parameter "type" change to int for a couple of operations. From owner-linux-xfs@oss.sgi.com Mon Mar 4 22:57:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g256vqI13277 for linux-xfs-outgoing; Mon, 4 Mar 2002 22:57:52 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g256vf913255 for ; Mon, 4 Mar 2002 22:57:41 -0800 Received: (qmail 11792 invoked from network); 5 Mar 2002 05:59:05 -0000 Received: from cpedeadbeef0000.cpe.net.cable.rogers.com (HELO sh0n.net) (sh0n@24.100.234.67) by cpedeadbeef0000.cpe.net.cable.rogers.com with SMTP; 5 Mar 2002 05:59:05 -0000 Date: Tue, 5 Mar 2002 00:59:04 -0500 (EST) From: Shawn Starr To: Nathan Scott cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - Even newer VFS quota In-Reply-To: <200203050521.QAA92891@snort.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I will be doing this today for -shawn10. Thank you. Shawn. On Tue, 5 Mar 2002, Nathan Scott wrote: > This is Jan's latest set of VFS quota patches. These patches (which > were posted to LKML on the weekend) allow the two VFS quota formats > and quotactl interfaces to coexist. All seems stable on my machine. > > If you're one of the people merging XFS with Alan Cox's patches, you > should first reverse-apply Jan's old patches (which removes the old > 32 bit UID/GID quota from Alan's patches, and then apply the new code > from the XFS CVS tree (which "re-applies" the 32 bit UID/GID quota > patches, but now using Jan's new mechanisms). > > Please let us know of any quota oddities you see in the CVS tree. > > cheers. > > [ ps: 2.5 port is next. ] > > > Date: Mon Mar 4 21:05:36 PST 2002 > Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: xfs-cmds:slinx:113294a > cmd/xfsmisc/README - 1.9 > - Update with Jan's latest round of patches. Now allows co-existance > of the old and new VFS quota formats/quotactl operations. > > > Modid: 2.4.x-xfs:slinx:113294b > linux/include/linux/quotacompat.h - 1.1 > linux/include/linux/quotaio_v2.h - 1.1 > linux/fs/quota_v2.c - 1.1 > linux/include/linux/dqblk_v1.h - 1.1 > linux/include/linux/dqblk_v2.h - 1.1 > linux/fs/quota_v1.c - 1.1 > linux/include/linux/quotaio_v1.h - 1.1 > linux/include/linux/quotaops.h - 1.13 > linux/include/linux/quota.h - 1.9 > linux/include/linux/fs.h - 1.144 > linux/include/asm-sparc64/ioctls.h - 1.4 > linux/include/asm-sparc/ioctls.h - 1.4 > linux/include/asm-m68k/ioctls.h - 1.4 > linux/include/asm-i386/ioctls.h - 1.4 > linux/include/asm-alpha/ioctls.h - 1.6 > linux/fs/super.c - 1.74 > linux/fs/ioctl.c - 1.13 > linux/fs/inode.c - 1.62 > linux/fs/dquot.c - 1.46 > linux/fs/Config.in - 1.76 > linux/arch/sparc64/kernel/sys_sparc32.c - 1.42 > linux/Documentation/Configure.help - 1.126 > linux/include/asm-sh/ioctls.h - 1.5 > linux/arch/ia64/ia32/sys_ia32.c - 1.20 > linux/include/asm-ia64/ioctls.h - 1.3 > linux/include/asm-parisc/ioctls.h - 1.3 > linux/include/asm-cris/ioctls.h - 1.3 > linux/fs/quota.c - 1.6 > - Update with Jan's latest round of patches. Now allows co-existance > of the old and new VFS quota formats/quotactl operations. > > linux/fs/xfs/linux/xfs_super.c - 1.161 > - Update to match minor field renaming from Jan's new patches. > > linux/fs/xfs/xfs_qm_syscalls.c - 1.56 > linux/fs/xfs/xfs_qm.h - 1.21 > - Type of parameter "type" change to int for a couple of operations. > > > From owner-linux-xfs@oss.sgi.com Mon Mar 4 23:09:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2579lQ13752 for linux-xfs-outgoing; Mon, 4 Mar 2002 23:09:47 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2579g913730 for ; Mon, 4 Mar 2002 23:09:43 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id HAA1478212 for ; Tue, 5 Mar 2002 07:13:30 +0100 (CET) mail_from (eric@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id AAA12919 for ; Tue, 5 Mar 2002 00:08:24 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id AAA27141 for ; Tue, 5 Mar 2002 00:08:24 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g2568OS17732; Tue, 5 Mar 2002 00:08:24 -0600 Message-Id: <200203050608.g2568OS17732@stout.americas.sgi.com> Date: Tue, 5 Mar 2002 00:08:24 -0600 From: Eric Sandeen Subject: TAKE - fix xfs build when procfs is not enabled Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk xfs_utils was looking for struct xfsstats when procfs was not enabled; it's only defined w/ procfs support turned on. Date: Mon Mar 4 22:07:09 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113295a linux/fs/xfs/xfs_utils.c - 1.40 - Fix build w/o procfs From owner-linux-xfs@oss.sgi.com Mon Mar 4 23:22:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g257MUN14157 for linux-xfs-outgoing; Mon, 4 Mar 2002 23:22:30 -0800 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g257MS914135 for ; Mon, 4 Mar 2002 23:22:28 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA01042 for ; Mon, 4 Mar 2002 22:22:26 -0800 (PST) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA38093 for linux-xfs@oss.sgi.com; Tue, 5 Mar 2002 17:21:04 +1100 (EST) Date: Tue, 5 Mar 2002 17:21:04 +1100 (EST) From: Nathan Scott Message-Id: <200203050621.RAA38093@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fs/Makefile Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 4 22:20:37 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113297a linux/fs/Makefile - 1.49 - I missed the changes in this file in that last merge with the new quota code. From owner-linux-xfs@oss.sgi.com Tue Mar 5 00:34:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g258YKv15561 for linux-xfs-outgoing; Tue, 5 Mar 2002 00:34:20 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g258YE915539 for ; Tue, 5 Mar 2002 00:34:14 -0800 Received: from lizard.webland.de (unknown [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx11)) with ESMTP id C2861C22F; Tue, 5 Mar 2002 08:34:07 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA26786; Tue, 5 Mar 2002 08:34:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id C4D1557306; Tue, 5 Mar 2002 08:33:58 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 22C7C25835; Tue, 5 Mar 2002 08:33:58 +0100 (CET) Message-ID: <3C8474E6.74143253@ch.sauter-bc.com> Date: Tue, 05 Mar 2002 08:33:58 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: Glow Nair , linux-xfs@oss.sgi.com Subject: Re: Recovering from an XFS crash References: <20020304221513.34714.qmail@web21107.mail.yahoo.com> <1015281607.22675.12.camel@stout.americas.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen schrieb: > > On Mon, 2002-03-04 at 16:15, Glow Nair wrote: > > HELP.. > > I would appreciate any help/hints etc. that I can > > get from SGI.. I've generally been very happy with > > SGI XFS 1.02 > > > > I made emergency boot disks.. however when my > > disk crashed, it wont boot using the rescue > > disk > > > > Can you help ? > > The installer should warn you, but it doesn't... the XFS kernel is often > too big to fit on a boot floppy. :( The kernel is too big to fit on a standard 1.44M floppy, but on most machines you can overformat the disks so the kernel will fit without any problem. I have built fixed mkbootdisk RPM's for RH-7.1 but I didn't for 7.2 until now. If I find some free time I will rebuild packages for 7.2 and kindly ask Eric to put it on oss/contrib toghether with my newest RH XFS kernel 2.4.9-31SGI_XFS_1.0.2. -Simon > > Try booting from the 1.0.2 CD with "linux rescue" at the boot prompt. > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Mar 5 00:44:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g258ihC15852 for linux-xfs-outgoing; Tue, 5 Mar 2002 00:44:43 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g258iY915827 for ; Tue, 5 Mar 2002 00:44:34 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g257iRbX019914 for ; Mon, 4 Mar 2002 23:44:28 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA66631; Tue, 5 Mar 2002 18:43:10 +1100 (EST) Date: Tue, 5 Mar 2002 18:43:10 +1100 (EST) From: Nathan Scott Message-Id: <200203050743.SAA66631@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, jack@ucw.cz Subject: TAKE - [2.5] Even newer VFS quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk New quota patches, forward ported to the 2.5 code base. cheers. Date: Mon Mar 4 23:40:55 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs Merged by: nathans Merged mods: 2.4.x-xfs:slinx:113294b,2.4.x-xfs:slinx:113297a,2.4.x-xfs:slinx:113298a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:113299a linux/include/linux/quotaio_v1.h - 1.1 linux/include/linux/dqblk_v1.h - 1.1 linux/include/linux/dqblk_v2.h - 1.1 linux/include/linux/quotacompat.h - 1.1 linux/fs/quota_v2.c - 1.1 linux/fs/quota_v1.c - 1.1 linux/include/linux/quotaio_v2.h - 1.1 linux/include/linux/quotaops.h - 1.15 linux/include/linux/quota.h - 1.10 linux/include/linux/fs.h - 1.157 linux/include/asm-sparc64/ioctls.h - 1.4 linux/include/asm-sparc/ioctls.h - 1.4 linux/include/asm-m68k/ioctls.h - 1.4 linux/include/asm-i386/ioctls.h - 1.4 linux/include/asm-alpha/ioctls.h - 1.6 linux/fs/super.c - 1.79 linux/fs/ioctl.c - 1.14 linux/fs/inode.c - 1.69 linux/fs/dquot.c - 1.52 - Merge of 2.4.x-xfs:slinx:113294b originally by nathans on 03/04/02 Update with Jan's latest round of patches. Now allows co-existance of the old and new VFS quota formats/quotactl operations. linux/fs/buffer.c - 1.114 - Merge of 2.4.x-xfs:slinx:113298a originally by nathans on 03/04/02 Missed this file during last merge with Jan's new code. linux/fs/Makefile - 1.50 - Merge of 2.4.x-xfs:slinx:113297a originally by nathans on 03/04/02 I missed the changes in this file in that last merge with Jan's new quota code. linux/fs/Config.in - 1.80 linux/arch/sparc64/kernel/sys_sparc32.c - 1.46 linux/include/asm-sh/ioctls.h - 1.5 linux/arch/ia64/ia32/sys_ia32.c - 1.21 linux/include/asm-ia64/ioctls.h - 1.3 - Merge of 2.4.x-xfs:slinx:113294b originally by nathans on 03/04/02 Update with Jan's latest round of patches. Now allows co-existance of the old and new VFS quota formats/quotactl operations. linux/fs/xfs/xfs_qm_syscalls.c - 1.57 linux/fs/xfs/xfs_qm.h - 1.21 - Merge of 2.4.x-xfs:slinx:113294b originally by nathans on 03/04/02 Type of parameter "type" change to int for a couple of operations. linux/fs/xfs/linux/xfs_super.c - 1.167 - Merge of 2.4.x-xfs:slinx:113294b originally by nathans on 03/04/02 Update to match minor field renaming from Jans new patches. linux/include/asm-parisc/ioctls.h - 1.3 linux/include/asm-cris/ioctls.h - 1.3 linux/fs/quota.c - 1.6 - Merge of 2.4.x-xfs:slinx:113294b originally by nathans on 03/04/02 Update with Jan's latest round of patches. Now allows co-existance of the old and new VFS quota formats/quotactl operations. From owner-linux-xfs@oss.sgi.com Tue Mar 5 00:48:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g258mMf16060 for linux-xfs-outgoing; Tue, 5 Mar 2002 00:48:22 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g258mE916033 for ; Tue, 5 Mar 2002 00:48:14 -0800 Received: from lizard.webland.de (unknown [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx07)) with ESMTP id 7BF226128; Tue, 5 Mar 2002 08:48:08 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA27968; Tue, 5 Mar 2002 08:48:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 3BF7357306; Tue, 5 Mar 2002 08:48:02 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 1C6CB25835; Tue, 5 Mar 2002 08:48:02 +0100 (CET) Message-ID: <3C847832.38F8C1C@ch.sauter-bc.com> Date: Tue, 05 Mar 2002 08:48:02 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: jwest@nic.com Cc: linux-xfs@oss.sgi.com Subject: Re: Million files or so on RAID 5 Partition References: <3C843D91.703130C6@nic.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk John W schrieb: > > Hello all, > > I have a 8 disk RAID 5 partition (8 X 9 GB) on a split bus Compaq array > that > currently has around 1 million files on it. Some tiny, some 5 MB. > Controllers > are Sym53C875 (non bootable compaq flavor). > > Doing any kind of removal or listing seems to take waaaay too long, an > ls in a dir > with 200 files will take 5 seconds to return. :^/ > > Any thoughts on Kernel tuning/adjustment to speed this up? Its a custom > kernel with > the Sym53C875 parts in the kernel. IIRC, I was getting around 200 > Interrupts per second > when doing some 'rm -rf' operations. Xsysinfo showed the IRQs for > Network card and > scsi controllers were pegged during NFS/Rsync load. > > Machine Asus P2B-DS 2X 400 MHz, 256 MB RAM. > > Thanks! Hi, Two things come to mind 1) IIRC there are two different drivers available for the NCR/Symbios chipset you're using. 2) The really important thing is how you set up the raid5 array. Did you make an external log? That makes the BIG difference. I suggest this layout: Every disk has: Part1: 200M Part2: 8.8G create raid1 on disk 1-2 / part 1 create swap on disk 3-8 / part1 create raid5 on disk 1-8 / part 2 create XFS FS on raid5 with external log on raid1 -Simon > > John W. > > BTW- Had a power outage that put the array into a bit of a spin. When it > booted, it > stalled on mounting the RAID 5 partition, and one disk was marked as > bad... > > I rebooted, and the array came back up, but one disk light was out... > marked as bad. > > I did the addhotspare and it came back online (Phew!). > > # Inspire Growth # From owner-linux-xfs@oss.sgi.com Tue Mar 5 00:51:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g258pf716220 for linux-xfs-outgoing; Tue, 5 Mar 2002 00:51:41 -0800 Received: from cellus.no (www.smsiden.com [193.91.191.71] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g258pZ916197 for ; Tue, 5 Mar 2002 00:51:35 -0800 Received: from christian ([193.69.127.56]) by cellus.no (8.9.3/8.9.3) with SMTP id IAA07693; Tue, 5 Mar 2002 08:51:23 +0100 From: =?iso-8859-1?Q?Christian_R=F8snes?= To: "Austin Gonyou" Cc: "Keith Owens" , Subject: RE: Linux 2.4.18 freeze running dbench 1.3 Date: Tue, 5 Mar 2002 08:51:27 +0100 Message-ID: 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: <1015287386.24622.3.camel@UberGeek> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was unclear in my previous post. I meant to say that I did a full new cvs to checkout to an ext2 partition on my system, to get a pristine copy. (My previous checkout was to a xfs partition.) I then compiled the kernel and modules on the ext2 partition, installed them and rebooted. The dbench was run on a xfs partition, where it crashed. I've compiled xfs into the kernel, and DMAPI is turned off. CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y # CONFIG_XFS_DMAPI is not set Christian > -----Original Message----- > From: Austin Gonyou [mailto:austin@coremetrics.com] Sent: 5. mars 2002 01:16 > > Did you run that test on EXT2 or did you just build your kernel on EXT2, > or did you run dbench FROM EXT2? > > Also, are you running XFS as a kernel module or built-in? Is dmapi > turned on? From owner-linux-xfs@oss.sgi.com Tue Mar 5 01:15:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g259FTS16986 for linux-xfs-outgoing; Tue, 5 Mar 2002 01:15:29 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g259FN916964 for ; Tue, 5 Mar 2002 01:15:23 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id C06BB40187A; Tue, 5 Mar 2002 03:15:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 927A4C00EEF; Tue, 5 Mar 2002 03:15:42 -0500 (EST) Date: Tue, 5 Mar 2002 03:15:42 -0500 (EST) From: Mike Burger To: Simon Matter Cc: Eric Sandeen , Glow Nair , Subject: Re: Recovering from an XFS crash In-Reply-To: <3C8474E6.74143253@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk What's wrong with just using the BOOT kernel, which fits just fine on a floppy? On Tue, 5 Mar 2002, Simon Matter wrote: > Eric Sandeen schrieb: > > > > On Mon, 2002-03-04 at 16:15, Glow Nair wrote: > > > HELP.. > > > I would appreciate any help/hints etc. that I can > > > get from SGI.. I've generally been very happy with > > > SGI XFS 1.02 > > > > > > I made emergency boot disks.. however when my > > > disk crashed, it wont boot using the rescue > > > disk > > > > > > Can you help ? > > > > The installer should warn you, but it doesn't... the XFS kernel is often > > too big to fit on a boot floppy. :( > > The kernel is too big to fit on a standard 1.44M floppy, but on most > machines you can overformat the disks so the kernel will fit without any > problem. I have built fixed mkbootdisk RPM's for RH-7.1 but I didn't for > 7.2 until now. If I find some free time I will rebuild packages for 7.2 > and kindly ask Eric to put it on oss/contrib toghether with my newest RH > XFS kernel 2.4.9-31SGI_XFS_1.0.2. > > -Simon > > > > > Try booting from the 1.0.2 CD with "linux rescue" at the boot prompt. > > > > -Eric > > > > -- > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > sandeen@sgi.com SGI, Inc. > > From owner-linux-xfs@oss.sgi.com Tue Mar 5 01:25:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g259PUR17278 for linux-xfs-outgoing; Tue, 5 Mar 2002 01:25:30 -0800 Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g259PM917252 for ; Tue, 5 Mar 2002 01:25:22 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 7F59740187A; Tue, 5 Mar 2002 03:25:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 1410DC00EEF; Tue, 5 Mar 2002 03:25:42 -0500 (EST) Date: Tue, 5 Mar 2002 03:25:42 -0500 (EST) From: Mike Burger To: Simon Matter Cc: Eric Sandeen , Glow Nair , Subject: Re: Recovering from an XFS crash In-Reply-To: <3C847F4F.C4C42DED@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm going to have to disagree, there. I just made a floppy with the BOOT kernel, and I have an Adaptec 2940U2W card active in my system, running my scanner and CD-RW drive. I'm also running the IDE-SCSI module for my tape and CD-ROM drives. I made the floppy just fine, using whichever mkbootdisk that is currently installed on my 7.1XFS system, and your 2.4.9-31.i686 kernel. On Tue, 5 Mar 2002, Simon Matter wrote: > Mike Burger schrieb: > > > > What's wrong with just using the BOOT kernel, which fits just fine on a > > floppy? > > It doesn't fit on a floppy if you have an SCSI system. The initrd gets > too big. > > -Simon > > > > > On Tue, 5 Mar 2002, Simon Matter wrote: > > > > > Eric Sandeen schrieb: > > > > > > > > On Mon, 2002-03-04 at 16:15, Glow Nair wrote: > > > > > HELP.. > > > > > I would appreciate any help/hints etc. that I can > > > > > get from SGI.. I've generally been very happy with > > > > > SGI XFS 1.02 > > > > > > > > > > I made emergency boot disks.. however when my > > > > > disk crashed, it wont boot using the rescue > > > > > disk > > > > > > > > > > Can you help ? > > > > > > > > The installer should warn you, but it doesn't... the XFS kernel is often > > > > too big to fit on a boot floppy. :( > > > > > > The kernel is too big to fit on a standard 1.44M floppy, but on most > > > machines you can overformat the disks so the kernel will fit without any > > > problem. I have built fixed mkbootdisk RPM's for RH-7.1 but I didn't for > > > 7.2 until now. If I find some free time I will rebuild packages for 7.2 > > > and kindly ask Eric to put it on oss/contrib toghether with my newest RH > > > XFS kernel 2.4.9-31SGI_XFS_1.0.2. > > > > > > -Simon > > > > > > > > > > > Try booting from the 1.0.2 CD with "linux rescue" at the boot prompt. > > > > > > > > -Eric > > > > > > > > -- > > > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > > > sandeen@sgi.com SGI, Inc. > > > > > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 5 01:38:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g259cOL17773 for linux-xfs-outgoing; Tue, 5 Mar 2002 01:38:24 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g259cE917746 for ; Tue, 5 Mar 2002 01:38:14 -0800 Received: from lizard.webland.de (unknown [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx13)) with ESMTP id 96206C209; Tue, 5 Mar 2002 09:38:08 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA02081; Tue, 5 Mar 2002 09:38:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 397EF57306; Tue, 5 Mar 2002 09:37:26 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id E1BB125835; Tue, 5 Mar 2002 09:37:25 +0100 (CET) Message-ID: <3C8483C5.EC969869@ch.sauter-bc.com> Date: Tue, 05 Mar 2002 09:37:25 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Mike Burger Cc: Eric Sandeen , Glow Nair , linux-xfs@oss.sgi.com Subject: Re: Recovering from an XFS crash References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Burger schrieb: > > I'm going to have to disagree, there. I just made a floppy with the BOOT > kernel, and I have an Adaptec 2940U2W card active in my system, running my > scanner and CD-RW drive. I'm also running the IDE-SCSI module for my tape > and CD-ROM drives. > > I made the floppy just fine, using whichever mkbootdisk that is currently > installed on my 7.1XFS system, and your 2.4.9-31.i686 kernel. Oops, I mean if you run a software raid1/5 system on SCSI, it does not fit. It even does not fit with software raid1/5 on IDE. -Simon > > On Tue, 5 Mar 2002, Simon Matter wrote: > > > Mike Burger schrieb: > > > > > > What's wrong with just using the BOOT kernel, which fits just fine on a > > > floppy? > > > > It doesn't fit on a floppy if you have an SCSI system. The initrd gets > > too big. > > > > -Simon > > > > > > > > On Tue, 5 Mar 2002, Simon Matter wrote: > > > > > > > Eric Sandeen schrieb: > > > > > > > > > > On Mon, 2002-03-04 at 16:15, Glow Nair wrote: > > > > > > HELP.. > > > > > > I would appreciate any help/hints etc. that I can > > > > > > get from SGI.. I've generally been very happy with > > > > > > SGI XFS 1.02 > > > > > > > > > > > > I made emergency boot disks.. however when my > > > > > > disk crashed, it wont boot using the rescue > > > > > > disk > > > > > > > > > > > > Can you help ? > > > > > > > > > > The installer should warn you, but it doesn't... the XFS kernel is often > > > > > too big to fit on a boot floppy. :( > > > > > > > > The kernel is too big to fit on a standard 1.44M floppy, but on most > > > > machines you can overformat the disks so the kernel will fit without any > > > > problem. I have built fixed mkbootdisk RPM's for RH-7.1 but I didn't for > > > > 7.2 until now. If I find some free time I will rebuild packages for 7.2 > > > > and kindly ask Eric to put it on oss/contrib toghether with my newest RH > > > > XFS kernel 2.4.9-31SGI_XFS_1.0.2. > > > > > > > > -Simon > > > > > > > > > > > > > > Try booting from the 1.0.2 CD with "linux rescue" at the boot prompt. > > > > > > > > > > -Eric > > > > > > > > > > -- > > > > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > > > > sandeen@sgi.com SGI, Inc. > > > > > > > > > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 5 01:51:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g259poR18296 for linux-xfs-outgoing; Tue, 5 Mar 2002 01:51:50 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g259pX918269 for ; Tue, 5 Mar 2002 01:51:33 -0800 Received: from lizard.webland.de (unknown [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx11)) with ESMTP id EE84CC25E; Tue, 5 Mar 2002 09:19:07 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA00475; Tue, 5 Mar 2002 09:19:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 6A3FA57306; Tue, 5 Mar 2002 09:18:23 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 1A84E25835; Tue, 5 Mar 2002 09:18:23 +0100 (CET) Message-ID: <3C847F4F.C4C42DED@ch.sauter-bc.com> Date: Tue, 05 Mar 2002 09:18:23 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Mike Burger Cc: Eric Sandeen , Glow Nair , linux-xfs@oss.sgi.com Subject: Re: Recovering from an XFS crash References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Burger schrieb: > > What's wrong with just using the BOOT kernel, which fits just fine on a > floppy? It doesn't fit on a floppy if you have an SCSI system. The initrd gets too big. -Simon > > On Tue, 5 Mar 2002, Simon Matter wrote: > > > Eric Sandeen schrieb: > > > > > > On Mon, 2002-03-04 at 16:15, Glow Nair wrote: > > > > HELP.. > > > > I would appreciate any help/hints etc. that I can > > > > get from SGI.. I've generally been very happy with > > > > SGI XFS 1.02 > > > > > > > > I made emergency boot disks.. however when my > > > > disk crashed, it wont boot using the rescue > > > > disk > > > > > > > > Can you help ? > > > > > > The installer should warn you, but it doesn't... the XFS kernel is often > > > too big to fit on a boot floppy. :( > > > > The kernel is too big to fit on a standard 1.44M floppy, but on most > > machines you can overformat the disks so the kernel will fit without any > > problem. I have built fixed mkbootdisk RPM's for RH-7.1 but I didn't for > > 7.2 until now. If I find some free time I will rebuild packages for 7.2 > > and kindly ask Eric to put it on oss/contrib toghether with my newest RH > > XFS kernel 2.4.9-31SGI_XFS_1.0.2. > > > > -Simon > > > > > > > > Try booting from the 1.0.2 CD with "linux rescue" at the boot prompt. > > > > > > -Eric > > > > > > -- > > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > > sandeen@sgi.com SGI, Inc. > > > > From owner-linux-xfs@oss.sgi.com Tue Mar 5 05:28:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25DSoa24732 for linux-xfs-outgoing; Tue, 5 Mar 2002 05:28:50 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25DSY924699 for ; Tue, 5 Mar 2002 05:28:34 -0800 Received: from lizard.webland.de (unknown [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx12)) with ESMTP id 60FBDC203; Tue, 5 Mar 2002 13:07:08 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id NAA19627; Tue, 5 Mar 2002 13:07:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id E54CB57306; Tue, 5 Mar 2002 13:06:19 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 6081225835; Tue, 5 Mar 2002 13:06:19 +0100 (CET) Message-ID: <3C84B4BB.C8700F84@ch.sauter-bc.com> Date: Tue, 05 Mar 2002 13:06:19 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: Glow Nair , linux-xfs@oss.sgi.com Subject: Re: Recovering from an XFS crash References: <20020304221513.34714.qmail@web21107.mail.yahoo.com> <1015281607.22675.12.camel@stout.americas.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen schrieb: > > On Mon, 2002-03-04 at 16:15, Glow Nair wrote: > > HELP.. > > I would appreciate any help/hints etc. that I can > > get from SGI.. I've generally been very happy with > > SGI XFS 1.02 > > > > I made emergency boot disks.. however when my > > disk crashed, it wont boot using the rescue > > disk > > > > Can you help ? Updated mkbootdisk RPMs are here: http://home.datacomm.ch/simix/XFS/rh-7.2/ Create bootdisk as usual, but use a different device: mkbootdisk --device /dev/fd0u1722 2.4.9-31SGI_XFS_1.0.2 -Simon > > The installer should warn you, but it doesn't... the XFS kernel is often > too big to fit on a boot floppy. :( > > Try booting from the 1.0.2 CD with "linux rescue" at the boot prompt. > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Mar 5 07:05:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25F5Pm27625 for linux-xfs-outgoing; Tue, 5 Mar 2002 07:05:25 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25F5G927586 for ; Tue, 5 Mar 2002 07:05:16 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g25E5AbX032532 for ; Tue, 5 Mar 2002 06:05:11 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA15483; Tue, 5 Mar 2002 08:03:55 -0600 (CST) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.191.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA98721; Tue, 5 Mar 2002 08:03:54 -0600 (CST) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id IAA49645; Tue, 5 Mar 2002 08:03:54 -0600 (CST) Message-Id: <200203051403.IAA49645@fsgi158.americas.sgi.com> Subject: Re: RedHat or XFS/NFS? To: jwest@nic.com Date: Tue, 5 Mar 2002 08:03:53 -0600 (CST) Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C84404F.BAB3EE8F@nic.com> from "John W" at Mar 04, 2002 10:49:35 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 Might want to apply Trond's client patches found at http://www.fys.uio.no/~trondmy/src/2.4.17/ especially the one described here: linux-2.4.17-seekdir.dif An experimental patch for fixing a problem that is due to NFSv(2|3) readdir returning (32|64) bit unsigned offsets. If you are seeing problems involving files that mysteriously disappear from your directory listings, then please consider applying this patch. NOTE: You might still have to set the '32bitclients' export option on some IRIX servers due to a remaining bug in glibc-2.2. Tad > > Have an Indy on home network, running 6.5.9 and a linux NFS client > running RHL 7.2 and Kernel 2.4.17-xfs. When I cd into a NFS mounted dir > from Linux client, I seem to have issues with > File operations. (linux-XFS box mounts SGI volume as NFSV2 via fstab > entry). > > radial 3% ls -la .log* > ls: No match. > radial 4% ls -al .login > -rwxrwxrwx 1 joker99 users 1467 Apr 16 2000 .login > radial 5% > > So it looks like an NFS related issue? > > Snoop trace from SGI Indy powerhouse server :^) > > (ls -la .log* - above yields following:) > > radial -> crank NFS C LOOKUP2 FH=AC18 -C > crank -> radial NFS R LOOKUP2 No such file or directory > radial -> crank NFS C LOOKUP2 FH=AC18 -al > crank -> radial NFS R LOOKUP2 No such file or directory > radial -> crank NFS C GETATTR2 FH=AC18 > crank -> radial NFS R GETATTR2 OK > radial -> crank NFS C READDIR2 FH=AC18 Cookie=0 > crank -> radial NFS R READDIR2 OK 0+ entries (incomplete) > crank -> radial UDP continuation ID=20820 > crank -> radial UDP continuation ID=20820 > radial -> crank NFS C READDIR2 FH=AC18 Cookie=913810309 > crank -> radial NFS R READDIR2 OK 0+ entries (incomplete) > crank -> radial UDP continuation ID=20821 > crank -> radial UDP continuation ID=20821 > radial -> crank NFS C READDIR2 FH=AC18 Cookie=2040705243 > crank -> radial NFS R READDIR2 OK 0+ entries (incomplete) > crank -> radial UDP continuation ID=20822 > crank -> radial UDP continuation ID=20822 > radial -> crank NFS C READDIR2 FH=AC18 Cookie=3514359216 > crank -> radial NFS R READDIR2 OK 0+ entries (incomplete) > crank -> radial UDP continuation ID=20823 > crank -> radial TELNET C port=1212 > radial -> crank TELNET R port=1212 ls: No match.\r\nradia > crank -> radial TELNET C port=1212 > > ( ls -al .login from above yields:) > > radial -> crank NFS C GETATTR2 FH=5745 > crank -> radial NFS R GETATTR2 OK > crank -> radial TELNET C port=1212 ls -al .login\n > radial -> crank TELNET R port=1212 l > crank -> radial TELNET C port=1212 > radial -> crank TELNET R port=1212 s -al .login\r\0\r\n-rwx > crank -> radial TELNET C port=1212 > > Thanks All! > > John W. > > > # Inspire Growth # > From owner-linux-xfs@oss.sgi.com Tue Mar 5 08:11:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25GBME07060 for linux-xfs-outgoing; Tue, 5 Mar 2002 08:11:22 -0800 Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25GBG907038 for ; Tue, 5 Mar 2002 08:11:16 -0800 Received: from offline.mpc.local ([172.16.20.7] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.16 #1) id 16iGaC-0007EG-00; Tue, 05 Mar 2002 15:10:28 +0000 Message-ID: <3C84DFE4.27289538@moving-picture.com> Date: Tue, 05 Mar 2002 15:10:28 +0000 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: jwest@nic.com CC: linux-xfs@oss.sgi.com Subject: Re: RedHat or XFS/NFS? References: <3C84404F.BAB3EE8F@nic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk John W wrote: > > Hello All, > > Have an Indy on home network, running 6.5.9 and a linux NFS client > running RHL 7.2 and Kernel 2.4.17-xfs. When I cd into a NFS mounted dir > from Linux client, I seem to have issues with > File operations. (linux-XFS box mounts SGI volume as NFSV2 via fstab > entry). > > radial 3% ls -la .log* > ls: No match. > radial 4% ls -al .login > -rwxrwxrwx 1 joker99 users 1467 Apr 16 2000 .login > radial 5% > > So it looks like an NFS related issue? Apply (at least) the 'seekdir' patch from http://www.fys.uio.no/~trondmy (BTW: RedHat based kernels already have this patch, including the 'SGI XFS release' variants) You will either have to: export your IRIX (XFS) file system using the -32bitclients option or: remake the IRIX XFS file system with naming version=2 (using 'mkfs -n version=2 device'). You can find out what 'version' your current file system is using by running 'xfs_growfs -n /mountpoint'. Of course, this involves backing up/restoring data ... James Pearson From owner-linux-xfs@oss.sgi.com Tue Mar 5 08:33:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25GXnS07505 for linux-xfs-outgoing; Tue, 5 Mar 2002 08:33:49 -0800 Received: from web21105.mail.yahoo.com (web21105.mail.yahoo.com [216.136.227.107]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25GXc907483 for ; Tue, 5 Mar 2002 08:33:38 -0800 Message-ID: <20020305153335.86626.qmail@web21105.mail.yahoo.com> Received: from [12.234.153.47] by web21105.mail.yahoo.com via HTTP; Tue, 05 Mar 2002 07:33:35 PST Date: Tue, 5 Mar 2002 07:33:35 -0800 (PST) From: Glow Nair Subject: Re: Recovering from an XFS crash To: Simon Matter , Eric Sandeen Cc: Glow Nair , linux-xfs@oss.sgi.com, jasonw@ariel.ucs.unimelb.edu.au In-Reply-To: <3C84B4BB.C8700F84@ch.sauter-bc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks Guys.. I did manage to boot to shell using the Linux Rescue option on the SGI XFS CD .. I wonder if there is any organized methodology to recover your partitions etc. Something like this would be fit the bill: ==== 1) Use the SGI XFS CD and type linux rescue 2) The system will attempt to find your old linux partitions (mine did not) 3) Check each of the filesystems using xfs_check xfs_check /dev/sda1 and so on 4) If there are any errors, repair them using xfs_repair xfs_repair /dev/sda1 and so on. 5) Manually mount each of the filesystems using mount -t xfs /dev/sda1 /dir1 6) Examine and verify your data 7) Next step... ==== I am writing this story as I travel through this process..If there is anything written out like this I'd DIE to get my hands on it.. In my case, I did not back up my /etc/fstab (yeah pretty dumb).. so I guessed at most of it.. I could mount /dev/sda1, /dev/sda2 etc but all the data seems to have vanished. Could this be because the filesystem type of "xfs" is wrong ? I can only see the directories but not the files themselves... it all seems to have been "wiped out" Any known vulnerabilities and patches would also be appreciated.. both in Redhat and SGI XFS.. Glow Nair --- Simon Matter wrote: > Eric Sandeen schrieb: > > > > On Mon, 2002-03-04 at 16:15, Glow Nair wrote: > > > HELP.. > > > I would appreciate any help/hints etc. that I > can > > > get from SGI.. I've generally been very happy > with > > > SGI XFS 1.02 > > > > > > I made emergency boot disks.. however when my > > > disk crashed, it wont boot using the rescue > > > disk > > > > > > Can you help ? > > Updated mkbootdisk RPMs are here: > > http://home.datacomm.ch/simix/XFS/rh-7.2/ > > Create bootdisk as usual, but use a different > device: > > mkbootdisk --device /dev/fd0u1722 > 2.4.9-31SGI_XFS_1.0.2 > > -Simon > > > > > The installer should warn you, but it doesn't... > the XFS kernel is often > > too big to fit on a boot floppy. :( > > > > Try booting from the 1.0.2 CD with "linux rescue" > at the boot prompt. > > > > -Eric > > > > -- > > Eric Sandeen XFS for Linux > http://oss.sgi.com/projects/xfs > > sandeen@sgi.com SGI, Inc. > > __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ From owner-linux-xfs@oss.sgi.com Tue Mar 5 09:08:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25H8lg12526 for linux-xfs-outgoing; Tue, 5 Mar 2002 09:08:47 -0800 Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25H8g912497 for ; Tue, 5 Mar 2002 09:08:42 -0800 Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8]) by ex1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g25G8cV01211; Tue, 5 Mar 2002 10:08:38 -0600 (CST) Received: from niri.ncsa.uiuc.edu (niri.ncsa.uiuc.edu [141.142.64.68]) by mx1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g25G8cB16392; Tue, 5 Mar 2002 10:08:38 -0600 (CST) From: Stuart Levy Received: (from slevy@localhost) by niri.ncsa.uiuc.edu (8.8.5/8.8.5) id KAA09623; Tue, 5 Mar 2002 10:08:37 -0600 (CST) Date: Tue, 5 Mar 2002 10:08:37 -0600 (CST) Message-Id: <200203051608.KAA09623@niri.ncsa.uiuc.edu> To: Simon Matter Subject: external log config [was: Million files or so on RAID 5 Partition] Cc: linux-xfs@oss.sgi.com References: <3C843D91.703130C6@nic.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter suggested, re improving setup of a RAID-5: [...] > 2) The really important thing is how you set up the raid5 array. Did you > make an external log? That makes the BIG difference. I suggest this > layout: > > Every disk has: > Part1: 200M Part2: 8.8G > create raid1 on disk 1-2 / part 1 > create swap on disk 3-8 / part1 > create raid5 on disk 1-8 / part 2 > > create XFS FS on raid5 with external log on raid1 Just wondering about the importance of a redundant external log. I have a RAID-5 setup for the main filesystem data, but keep the log on a nonredundant partition of another drive, on the theory that if the log were lost, I shouldn't lose more than the last few seconds' activity. And it appears that xfs_repair -l /dev/newpartition -L /dev/maindevice can be used to initialize a new external log -- I won't need to re-create the entire filesystem or anything. (I tested the above create-new-log scenario, though only on a cleanly-unmounted filesystem.) Also, for performance, I imagine that it'd help a lot to have an external log on a *different spindle* than the main filesystem, to avoid lots of extra seeks. Since N disks fit in my system, I used N-1 for the RAID-5 main xfs filesystem and the other 1 for the external log (and system disk). But if the ext log needed to be *both* redundant and to share no spindles with the main fs, I'd be limited to N-2 disks for XFS data, a big loss. Does this sound right? Stuart Levy, slevy@ncsa.uiuc.edu From owner-linux-xfs@oss.sgi.com Tue Mar 5 10:19:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25IJWT13541 for linux-xfs-outgoing; Tue, 5 Mar 2002 10:19:32 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25IJO913513 for ; Tue, 5 Mar 2002 10:19:24 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g25IJJBA017839 for ; Tue, 5 Mar 2002 10:19:19 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA14830; Tue, 5 Mar 2002 11:18:03 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA95746; Tue, 5 Mar 2002 11:18:03 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g25HH4Q30405; Tue, 5 Mar 2002 11:17:04 -0600 Subject: Re: external log config [was: Million files or so on RAID 5 Partition] From: Steve Lord To: Stuart Levy Cc: Simon Matter , linux-xfs@oss.sgi.com In-Reply-To: <200203051608.KAA09623@niri.ncsa.uiuc.edu> References: <3C843D91.703130C6@nic.com> <200203051608.KAA09623@niri.ncsa.uiuc.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 05 Mar 2002 11:17:04 -0600 Message-Id: <1015348624.25411.42.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-05 at 10:08, Stuart Levy wrote: > Simon Matter suggested, re improving setup of a RAID-5: > [...] > > 2) The really important thing is how you set up the raid5 array. Did you > > make an external log? That makes the BIG difference. I suggest this > > layout: > > > > Every disk has: > > Part1: 200M Part2: 8.8G > > create raid1 on disk 1-2 / part 1 > > create swap on disk 3-8 / part1 > > create raid5 on disk 1-8 / part 2 > > > > create XFS FS on raid5 with external log on raid1 > > Just wondering about the importance of a redundant > external log. I have a RAID-5 setup for the main filesystem > data, but keep the log on a nonredundant partition of > another drive, on the theory that if the log were lost, > I shouldn't lose more than the last few seconds' activity. > > And it appears that xfs_repair -l /dev/newpartition -L /dev/maindevice > can be used to initialize a new external log -- I won't need > to re-create the entire filesystem or anything. No, this will not do anything to the filesystem - might be an interesting way to switch the log to external though. I think the argument parsing needs some work here - I suspect you can specify an external log on the mount line when you do not have one in the filesystem..... There is no way of moving the log without dump/mkfs/restore. Steve p.s. there is code coming which may fix the raid5 internal log performance problem, but we have not had time to port it to linux yet. > > (I tested the above create-new-log scenario, though only on a > cleanly-unmounted filesystem.) > > Also, for performance, I imagine that it'd help a lot to have > an external log on a *different spindle* than the > main filesystem, to avoid lots of extra seeks. > Since N disks fit in my system, I used N-1 for the RAID-5 > main xfs filesystem and the other 1 for the external log > (and system disk). But if the ext log needed to be *both* > redundant and to share no spindles with the main fs, > I'd be limited to N-2 disks for XFS data, a big loss. > > Does this sound right? > > Stuart Levy, slevy@ncsa.uiuc.edu -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 5 10:40:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25IedL13998 for linux-xfs-outgoing; Tue, 5 Mar 2002 10:40:39 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25IeW913976 for ; Tue, 5 Mar 2002 10:40:32 -0800 Received: (qmail 29150 invoked by uid 500); 5 Mar 2002 17:39:57 -0000 Subject: RE: Linux 2.4.18 freeze running dbench 1.3 From: Austin Gonyou To: Christian =?ISO-8859-1?Q?R=F8snes?= Cc: Keith Owens , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.2 Date: 05 Mar 2002 11:39:57 -0600 Message-Id: <1015349997.29100.2.camel@UberGeek> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g25IeW913977 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk With that kernel used...can you dbench your ext2 filesystem and see any difference?(i.e. does it crash too, or act funky?) On Tue, 2002-03-05 at 01:51, Christian Rřsnes wrote: > I was unclear in my previous post. > > I meant to say that I did a full new cvs to checkout to an ext2 > partition > on my system, to get a pristine copy. > (My previous checkout was to a xfs partition.) > > I then compiled the kernel and modules on the ext2 partition, > installed them and rebooted. > > The dbench was run on a xfs partition, where it crashed. > > I've compiled xfs into the kernel, and DMAPI is turned off. > > CONFIG_XFS_FS=y > # CONFIG_XFS_RT is not set > CONFIG_XFS_QUOTA=y > # CONFIG_XFS_DMAPI is not set > > > Christian > > > -----Original Message----- > > From: Austin Gonyou [mailto:austin@coremetrics.com] Sent: 5. mars 2002 > 01:16 > > > > Did you run that test on EXT2 or did you just build your kernel on > EXT2, > > or did you run dbench FROM EXT2? > > > > Also, are you running XFS as a kernel module or built-in? Is dmapi > > turned on? > -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Tue Mar 5 10:45:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25Ijgq14247 for linux-xfs-outgoing; Tue, 5 Mar 2002 10:45:42 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25Ijd914225 for ; Tue, 5 Mar 2002 10:45:39 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g25HjXbX012932 for ; Tue, 5 Mar 2002 09:45:33 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA19622; Tue, 5 Mar 2002 11:44:17 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA44587; Tue, 5 Mar 2002 11:44:17 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g25HhIt31604; Tue, 5 Mar 2002 11:43:18 -0600 Subject: RE: Linux 2.4.18 freeze running dbench 1.3 From: Steve Lord To: Austin Gonyou Cc: Christian =?ISO-8859-1?Q?R=F8snes?= , Keith Owens , linux-xfs@oss.sgi.com In-Reply-To: <1015349997.29100.2.camel@UberGeek> References: <1015349997.29100.2.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 05 Mar 2002 11:43:18 -0600 Message-Id: <1015350198.25452.62.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-05 at 11:39, Austin Gonyou wrote: > With that kernel used...can you dbench your ext2 filesystem and see any > difference?(i.e. does it crash too, or act funky?) > > I have been communicating off list with Christian, ext2 is working just find, xfs is having problems with a spinlock appearing to be unlocked. I have asked him to try a few more things which may narrow it down. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 5 11:10:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25JAdp14868 for linux-xfs-outgoing; Tue, 5 Mar 2002 11:10:39 -0800 Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25JAW914844 for ; Tue, 5 Mar 2002 11:10:33 -0800 Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8]) by ex1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g25I9kV11246; Tue, 5 Mar 2002 12:09:46 -0600 (CST) Received: from niri.ncsa.uiuc.edu (niri.ncsa.uiuc.edu [141.142.64.68]) by mx1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g25I9jB24588; Tue, 5 Mar 2002 12:09:45 -0600 (CST) From: Stuart Levy Received: (from slevy@localhost) by niri.ncsa.uiuc.edu (8.8.5/8.8.5) id MAA10106; Tue, 5 Mar 2002 12:09:45 -0600 (CST) Date: Tue, 5 Mar 2002 12:09:45 -0600 (CST) Message-Id: <200203051809.MAA10106@niri.ncsa.uiuc.edu> To: Steve Lord Subject: Re: external log config [was: Million files or so on RAID 5 Partition] Cc: linux-xfs@oss.sgi.com References: <3C843D91.703130C6@nic.com> <200203051608.KAA09623@niri.ncsa.uiuc.edu> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>[...] xfs_repair -l /dev/newpartition -L /dev/maindevice > No, this will not do anything to the filesystem - might be an > interesting way to switch the log to external though. Oh... I was intending to use it to move an already-external log to a *different* device, assuming the original logdev had been trashed somehow. If the filesystem is unmounted cleanly, and I use the above to initialize the new log partition, will anything have been lost? I.e. is the log empty after a clean umount? I tried a few things, like: create two xfs filesystems (sda1, sda2) each with its own external log (hda5, hda6) Tried mounting one fs with the other's log: mount -o logdev=/dev/hda6 /dev/sda1 This failed as expected. Tried xfs_repair as: xfs_repair -l /dev/hda6 /dev/sda1 This complained too, reporting that the logdev and fs UUIDs didn't match, or something. That's good. Then told xfs_repair to erase the log: xfs_repair -l /dev/hda6 -L /dev/sda1 This succeeded. And I could then mount -o logdev=/dev/hda6 /dev/sda1 without apparent error, and the filesystem *appeared* to be intact. > I think the argument parsing needs some work here - I suspect you can > specify an external log on the mount line when you do not have > one in the filesystem..... Would the logdev= just be ignored in that case? > There is no way of moving the log without dump/mkfs/restore. Doesn't the above recipe amount to moving the log? Do I lose anything? > Steve From owner-linux-xfs@oss.sgi.com Tue Mar 5 11:35:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25JZ2G16198 for linux-xfs-outgoing; Tue, 5 Mar 2002 11:35:02 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25JYv916176 for ; Tue, 5 Mar 2002 11:34:57 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g25Jg9kw010007 for ; Tue, 5 Mar 2002 13:42:09 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA20818; Tue, 5 Mar 2002 12:33:35 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA84068; Tue, 5 Mar 2002 12:33:35 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g25IWaF31630; Tue, 5 Mar 2002 12:32:36 -0600 Subject: Re: external log config [was: Million files or so on RAID 5 Partition] From: Steve Lord To: Stuart Levy Cc: linux-xfs@oss.sgi.com In-Reply-To: <200203051809.MAA10106@niri.ncsa.uiuc.edu> References: <3C843D91.703130C6@nic.com> <200203051608.KAA09623@niri.ncsa.uiuc.edu> <200203051809.MAA10106@niri.ncsa.uiuc.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 05 Mar 2002 12:32:36 -0600 Message-Id: <1015353156.25452.120.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-05 at 12:09, Stuart Levy wrote: > >>[...] xfs_repair -l /dev/newpartition -L /dev/maindevice > > > No, this will not do anything to the filesystem - might be an > > interesting way to switch the log to external though. > > Oh... I was intending to use it to move an already-external log > to a *different* device, assuming the original logdev had been > trashed somehow. > > If the filesystem is unmounted cleanly, and I use the above > to initialize the new log partition, will anything have been lost? > I.e. is the log empty after a clean umount? > Ah, I was thinking you were going from internal to external log. For external to external it should work I think. If you do a clean unmount you will lose no data. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 5 15:23:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g25NNK621195 for linux-xfs-outgoing; Tue, 5 Mar 2002 15:23:20 -0800 Received: from downtown.oche.de (root@downtown.oche.de [194.94.253.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g25NNB921101 for ; Tue, 5 Mar 2002 15:23:12 -0800 Received: (from uucp@localhost) by downtown.oche.de (8.9.3/8.9.3/Debian 8.9.3-21) with UUCP id XAA28829 for linux-xfs@oss.sgi.com; Tue, 5 Mar 2002 23:23:09 +0100 Received: from sirius.quickstep.oche.de (sirius.quickstep.oche.de [192.168.48.4]) by foehn.quickstep.oche.de (8.9.3/8.6.12) with ESMTP id XAA17931 for ; Tue, 5 Mar 2002 23:07:01 +0100 (MET) Received: (from martin@localhost) by sirius.quickstep.oche.de (SGI-8.9.3/8.9.3) id XAA03349; Tue, 5 Mar 2002 23:07:01 +0100 (CET) Date: Tue, 5 Mar 2002 23:07:01 +0100 (CET) Message-Id: <200203052207.XAA03349@sirius.quickstep.oche.de> From: Martin Spott To: linux-xfs@oss.sgi.com Subject: Re: Million files or so on RAID 5 Partition X-Newsgroups: list.linux-xfs In-Reply-To: User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (IRIX64/6.5 (IP30)) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I have a 8 disk RAID 5 partition (8 X 9 GB) on a split bus Compaq array > [...] Just to be curious (as always ....): Do you use the old 'md' driver for this or LVM ? Should I stay away from one of these (despite the issues with internal log on RAID5) ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Mar 5 16:51:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g260pvr27966 for linux-xfs-outgoing; Tue, 5 Mar 2002 16:51:57 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g260pr927944 for ; Tue, 5 Mar 2002 16:51:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g260plBA007228 for ; Tue, 5 Mar 2002 16:51:47 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA55704 for linux-xfs@oss.sgi.com; Wed, 6 Mar 2002 10:50:30 +1100 (EST) Date: Wed, 6 Mar 2002 10:50:30 +1100 (EST) From: Nathan Scott Message-Id: <200203052350.KAA55704@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota update Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Mar 5 15:49:18 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113366a linux/include/linux/quota.h - 1.10 linux/Documentation/Configure.help - 1.127 linux/fs/quota.c - 1.7 - Sync up with Jan's latest quota patches (very minor). From owner-linux-xfs@oss.sgi.com Tue Mar 5 17:16:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g261GcG28514 for linux-xfs-outgoing; Tue, 5 Mar 2002 17:16:38 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g261GZ928492 for ; Tue, 5 Mar 2002 17:16:35 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g261GTBA008293 for ; Tue, 5 Mar 2002 17:16:29 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA16132 for linux-xfs@oss.sgi.com; Wed, 6 Mar 2002 11:15:11 +1100 (EST) Date: Wed, 6 Mar 2002 11:15:11 +1100 (EST) From: Nathan Scott Message-Id: <200203060015.LAA16132@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - [2.5] quota updates Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Mar 5 16:14:27 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs Author: nathans Merged by: nathans Merged mods: 2.4.x-xfs:slinx:113366a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:113366a linux/include/linux/quota.h - 1.11 linux/fs/quota.c - 1.7 - Merge of 2.4.x-xfs:slinx:113366a by nathans. Sync up with Jan's latest quota patches. linux/fs/Config.help - 1.4 - Add missing help text entries for new VFS quota options. From owner-linux-xfs@oss.sgi.com Tue Mar 5 22:01:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2661Bx05896 for linux-xfs-outgoing; Tue, 5 Mar 2002 22:01:11 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26618905868 for ; Tue, 5 Mar 2002 22:01:08 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g26511bX011270 for ; Tue, 5 Mar 2002 21:01:02 -0800 Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA60085 for linux-xfs@oss.sgi.com; Wed, 6 Mar 2002 15:59:44 +1100 (EST) Date: Wed, 6 Mar 2002 15:59:44 +1100 (EST) From: Timothy Shimmin Message-Id: <200203060459.PAA60085@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfstests/065 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Mar 5 20:57:59 PST 2002 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:113382a cmd/xfstests/065 - 1.4 cmd/xfstests/065.out - 1.2 - Update filtering so this test can be identical on IRIX. From owner-linux-xfs@oss.sgi.com Tue Mar 5 23:11:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g267Bfm07199 for linux-xfs-outgoing; Tue, 5 Mar 2002 23:11:41 -0800 Received: from mta10.srv.hcvlny.cv.net (mta10.srv.hcvlny.cv.net [167.206.5.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g267BZ907175 for ; Tue, 5 Mar 2002 23:11:36 -0800 Received: from nic.com (ool-4350f032.dyn.optonline.net [67.80.240.50]) by mta10.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GSJ007CDFVAIF@mta10.srv.hcvlny.cv.net> for linux-xfs@oss.sgi.com; Wed, 06 Mar 2002 01:11:34 -0500 (EST) Date: Wed, 06 Mar 2002 00:50:39 -0500 From: John W Subject: Million files and NFS/XFS To: linux-xfs@oss.sgi.com Reply-to: jwest@nic.com Message-id: <3C85AE2F.54EE1BF3@nic.com> Organization: Long Pond Industries MIME-version: 1.0 X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP22) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Guysm Thanks a bunch! 2.4.18 kernel with Tronds patches compiling now ! Will test tomorrow. This should help the dissappearing files. TCsh (esc) (esc) may work again ! WRT to the XFS/NFS issue, that sounds pretty broken. The Indy is already exported as 32bitclients (plural?). no help. Sounds like this is pretty new! Kernel / Glibc assumption. RE: Raid5 w/ millions of files. As I have no logging enabled at all, can I put it on sep. internal disks on the system controller. ( do have a few 80 MBPS disks inside :^) Would probably put them on the spare parts of the partitions. Can I add entries as Steve Lord indicates to /etc/fstab to start logging on these new partitions. Thanks! John W. -- # Inspire Growth # From owner-linux-xfs@oss.sgi.com Wed Mar 6 00:12:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g268CNH08205 for linux-xfs-outgoing; Wed, 6 Mar 2002 00:12:23 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g268CE908183 for ; Wed, 6 Mar 2002 00:12:14 -0800 Received: from lizard.webland.de (unknown [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx14)) with ESMTP id 8763BC246; Wed, 6 Mar 2002 08:12:08 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA04077; Wed, 6 Mar 2002 08:12:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id A4D9457306; Wed, 6 Mar 2002 08:11:55 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 5FC8225835; Wed, 6 Mar 2002 08:11:55 +0100 (CET) Message-ID: <3C85C13B.84619B48@ch.sauter-bc.com> Date: Wed, 06 Mar 2002 08:11:55 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Stuart Levy Cc: linux-xfs@oss.sgi.com Subject: Re: external log config [was: Million files or so on RAID 5 Partition] References: <3C843D91.703130C6@nic.com> <200203051608.KAA09623@niri.ncsa.uiuc.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stuart Levy schrieb: > > Simon Matter suggested, re improving setup of a RAID-5: > [...] > > 2) The really important thing is how you set up the raid5 array. Did you > > make an external log? That makes the BIG difference. I suggest this > > layout: > > > > Every disk has: > > Part1: 200M Part2: 8.8G > > create raid1 on disk 1-2 / part 1 > > create swap on disk 3-8 / part1 > > create raid5 on disk 1-8 / part 2 > > > > create XFS FS on raid5 with external log on raid1 > > Just wondering about the importance of a redundant > external log. I have a RAID-5 setup for the main filesystem > data, but keep the log on a nonredundant partition of I have made several performance tests some time ago. I learnt that, while it's imporant to have external log, it's not so important to keep the log on different spindles. I like to have everything redundant, rootfs, datafs, logs and even swap. Swap was dangerous on software raid long time ago but it seems safe today. Putting the log on raid1 will improve security and read performance while write performance is almost identical to a single drive. That's why I always do it this way. > another drive, on the theory that if the log were lost, > I shouldn't lose more than the last few seconds' activity. > > And it appears that xfs_repair -l /dev/newpartition -L /dev/maindevice > can be used to initialize a new external log -- I won't need > to re-create the entire filesystem or anything. > > (I tested the above create-new-log scenario, though only on a > cleanly-unmounted filesystem.) > > Also, for performance, I imagine that it'd help a lot to have > an external log on a *different spindle* than the > main filesystem, to avoid lots of extra seeks. > Since N disks fit in my system, I used N-1 for the RAID-5 > main xfs filesystem and the other 1 for the external log > (and system disk). But if the ext log needed to be *both* > redundant and to share no spindles with the main fs, > I'd be limited to N-2 disks for XFS data, a big loss. > > Does this sound right? > > Stuart Levy, slevy@ncsa.uiuc.edu From owner-linux-xfs@oss.sgi.com Wed Mar 6 00:21:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g268Lj808507 for linux-xfs-outgoing; Wed, 6 Mar 2002 00:21:45 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g268LV908482 for ; Wed, 6 Mar 2002 00:21:31 -0800 Received: from lizard.webland.de (unknown [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx02)) with ESMTP id 28125615C; Wed, 6 Mar 2002 08:02:15 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA03456; Wed, 6 Mar 2002 08:02:14 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 4A23C57306; Wed, 6 Mar 2002 08:01:16 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 248BF25835; Wed, 6 Mar 2002 08:01:16 +0100 (CET) Message-ID: <3C85BEBC.37645CE6@ch.sauter-bc.com> Date: Wed, 06 Mar 2002 08:01:16 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Martin Spott Cc: linux-xfs@oss.sgi.com Subject: Re: Million files or so on RAID 5 Partition References: <200203052207.XAA03349@sirius.quickstep.oche.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Martin Spott schrieb: > > > I have a 8 disk RAID 5 partition (8 X 9 GB) on a split bus Compaq array > > [...] > > Just to be curious (as always ....): Do you use the old 'md' driver for this > or LVM ? Should I stay away from one of these (despite the issues with > internal log on RAID5) ? IIRC you can not use LVM to create RAID5 devices, just RAID0,1. Anyway it seems to be not so sure that we always have a working LVM for every kernel (Isn't it broken at this time for 2.5?). MD should be more safe here. -Simon > > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Mar 6 00:23:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g268NKT08638 for linux-xfs-outgoing; Wed, 6 Mar 2002 00:23:20 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g268ND908616 for ; Wed, 6 Mar 2002 00:23:13 -0800 Received: from lizard.webland.de (unknown [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx14)) with ESMTP id 3622CC246; Wed, 6 Mar 2002 08:23:07 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA05004; Wed, 6 Mar 2002 08:23:06 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 03BAD57306; Wed, 6 Mar 2002 08:22:08 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id ABE4125835; Wed, 6 Mar 2002 08:22:07 +0100 (CET) Message-ID: <3C85C39F.E368C5A4@ch.sauter-bc.com> Date: Wed, 06 Mar 2002 08:22:07 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: jwest@nic.com Cc: linux-xfs@oss.sgi.com Subject: Re: Million files and NFS/XFS References: <3C85AE2F.54EE1BF3@nic.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk John W schrieb: > > Guysm > > Thanks a bunch! > > 2.4.18 kernel with Tronds patches compiling now ! Will test tomorrow. > > This should help the dissappearing files. TCsh (esc) (esc) may work > again > ! > WRT to the XFS/NFS issue, that sounds pretty broken. The Indy is already > exported as 32bitclients (plural?). no help. Sounds like this is > pretty new! > Kernel / Glibc assumption. > > RE: Raid5 w/ millions of files. The question is whether you have software raid5 or anything else. Software raid0,1 and any hardware raid should be okay. > > As I have no logging enabled at all, can I put it on sep. internal disks > on the You HAVE logging enabled if you run XFS. If you don't specify logoptions XFS creates internal log with default values. > system controller. ( do have a few 80 MBPS disks inside :^) > > Would probably put them on the spare parts of the partitions. > > Can I add entries as Steve Lord indicates to /etc/fstab to start logging > on these new partitions. To move internal log to external I guess you have to recreate the fs. -Simon > > Thanks! > > John W. > > -- > # Inspire Growth # From owner-linux-xfs@oss.sgi.com Wed Mar 6 01:03:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2693G209874 for linux-xfs-outgoing; Wed, 6 Mar 2002 01:03:16 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2693B909851 for ; Wed, 6 Mar 2002 01:03:11 -0800 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16iWJe-0006l3-00; Wed, 06 Mar 2002 08:58:26 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Simon Matter" Date: Wed, 06 Mar 2002 08:58:26 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2472) For Windows 2000 (5.0.2195;2) In-Reply-To: <3C85C13B.84619B48@ch.sauter-bc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: external log config [was: Million files or so on RAID 5 Partition] Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 06 Mar 2002 08:11:55 +0100, Simon Matter wrote: >I have made several performance tests some time ago. I learnt that, >while it's imporant to have external log Is it ALWAYS advisable to have an external log (I mean even on hardware RAIDs,) or does this only apply to software RAIDs (LVM)? Thanks, Ralf -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Wed Mar 6 01:44:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g269iED10718 for linux-xfs-outgoing; Wed, 6 Mar 2002 01:44:14 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g269hx910692 for ; Wed, 6 Mar 2002 01:43:59 -0800 Received: from lizard.webland.de (unknown [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx01)) with ESMTP id E2099615D; Wed, 6 Mar 2002 09:12:11 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA08854; Wed, 6 Mar 2002 09:12:11 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 3A65757306; Wed, 6 Mar 2002 09:11:30 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 7FB4A25835; Wed, 6 Mar 2002 09:11:29 +0100 (CET) Message-ID: <3C85CF31.495FB605@ch.sauter-bc.com> Date: Wed, 06 Mar 2002 09:11:29 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: "Ralf G. R. Bergs" Cc: "linux-xfs@oss.sgi.com" Subject: Re: external log config [was: Million files or so on RAID 5 Partition] References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Ralf G. R. Bergs" schrieb: > > On Wed, 06 Mar 2002 08:11:55 +0100, Simon Matter wrote: > > >I have made several performance tests some time ago. I learnt that, > >while it's imporant to have external log > > Is it ALWAYS advisable to have an external log (I mean even on hardware RAIDs,) > or does this only apply to software RAIDs (LVM)? I think the only reason to have external log is performance. Having all the logs external makes it complitated on servers with alot of partitions. So until performance is mission critical or you use software raid5 (only 5), you should be okay with internal log. I, for example, do it only on software raid5 volumes because it makes a very big performance difference there. -Simon > > Thanks, > > Ralf > > -- > Sign the EU petition against SPAM: L I N U X .~. > http://www.politik-digital.de/spam/ The Choice /V\ > of a GNU /( )\ > Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Wed Mar 6 02:06:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26A6dC12116 for linux-xfs-outgoing; Wed, 6 Mar 2002 02:06:39 -0800 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26A6Y912080 for ; Wed, 6 Mar 2002 02:06:34 -0800 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g2696w506702; Wed, 6 Mar 2002 10:06:58 +0100 Date: Wed, 6 Mar 2002 10:06:57 +0100 (CET) From: Matteo Centonza To: Simon Matter cc: Martin Spott , Subject: Re: Million files or so on RAID 5 Partition In-Reply-To: <3C85BEBC.37645CE6@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Simon, > > Just to be curious (as always ....): Do you use the old 'md' driver for this > > or LVM ? Should I stay away from one of these (despite the issues with > > internal log on RAID5) ? > > IIRC you can not use LVM to create RAID5 devices, just RAID0,1. Anyway > it seems to be not so sure that we always have a working LVM for every > kernel (Isn't it broken at this time for 2.5?). MD should be more safe > here. Not that sure AFAICT. The same problem happened for RAID 5 recently (in 2.5). BTW LVM has been fixed and it's working fine. In my case, i have LVM stacked on RAID5 with internal log. Is it possible that this configuration doesn't suffer the performance penalty? Just curious. Ciao, -m From owner-linux-xfs@oss.sgi.com Wed Mar 6 05:43:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26DhPA17747 for linux-xfs-outgoing; Wed, 6 Mar 2002 05:43:25 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26DhL917725 for ; Wed, 6 Mar 2002 05:43:21 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g26DoZkw016587 for ; Wed, 6 Mar 2002 07:50:35 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA31254 for ; Wed, 6 Mar 2002 06:42:00 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA59252 for ; Wed, 6 Mar 2002 06:41:59 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g26Cerq14735; Wed, 6 Mar 2002 06:40:53 -0600 Message-Id: <200203061240.g26Cerq14735@jen.americas.sgi.com> Date: Wed, 6 Mar 2002 06:40:53 -0600 Subject: TAKE - fix super block reference leak To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Was not harmful in normal operation, but caused a memory leak at unmount and oopses if you unload and reload xfs as a module Date: Wed Mar 6 04:40:51 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113384a linux/fs/xfs/xfs_buf.h - 1.82 - No longer treat the super block specially in the delayed write queue linux/fs/xfs/xfs_mount.c - 1.273 - Fix a reference leak on the super block buffer - causes a small memory leak under pressure, and can cause oopses if loading and unloading an xfs module. linux/fs/xfs/pagebuf/page_buf.c - 1.12 - No longer treat the super block specially in the delayed write queue From owner-linux-xfs@oss.sgi.com Wed Mar 6 05:49:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26DnL917961 for linux-xfs-outgoing; Wed, 6 Mar 2002 05:49:21 -0800 Received: from ksimachine.com (IDENT:root@ksimachine.com [64.81.128.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26DnH917939 for ; Wed, 6 Mar 2002 05:49:17 -0800 Received: from ksimachine.com (sta16.local.ksimachine.com [192.168.250.16]) by ksimachine.com (8.11.6/8.11.6) with ESMTP id g26CnGV09862 for ; Wed, 6 Mar 2002 07:49:16 -0500 Message-ID: <3C861060.7070106@ksimachine.com> Date: Wed, 06 Mar 2002 07:49:36 -0500 From: "Joe St.Clair" Reply-To: ksimach@ksimachine.com Organization: KSI Machine & Engineering User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: kernel upgrade question. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have 2 boxes running the SGI-XFS install of Redhat 7.1 with all of the updates including kenel 2.4.9-21SGI_XFS_1.0.2. I have kept both boxes up to date according to Redhat and have used the patched kernel RPM's from the SGI ftp site. I am currently using 2.4.9-21SGI_XFS_1.0.2 and used the RPM's found at "ftp://oss.sgi.com/projects/xfs/download/Release-1.0.2/kernel_rpms/i386/contributed-RH-updates/2.4.9-21-RH7.1/". My question is with regards to 2.4.9-31 kernel upgrade. Will a simular set of RPM's be available to keep in line with Redhat? If not, should I go to 2.4.14? If I should go to 2.4.14, do I have to do anything to use them on a original 1.0.1 install? Thanks. -- Joseph St.Clair - KSI Machine & Engineering From owner-linux-xfs@oss.sgi.com Wed Mar 6 05:56:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26DuJ718219 for linux-xfs-outgoing; Wed, 6 Mar 2002 05:56:19 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26DuE918197 for ; Wed, 6 Mar 2002 05:56:14 -0800 Received: from lizard.webland.de (unknown [194.122.76.106]) by mx.de.kpnqwest.net (Postfix (mx11)) with ESMTP id 0BB6CC211; Wed, 6 Mar 2002 13:56:08 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id NAA04716; Wed, 6 Mar 2002 13:56:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 0B50157306; Wed, 6 Mar 2002 13:55:31 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id F3B5325836; Wed, 6 Mar 2002 13:55:30 +0100 (CET) Message-ID: <3C8611C2.6948E33E@ch.sauter-bc.com> Date: Wed, 06 Mar 2002 13:55:30 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: ksimach@ksimachine.com Cc: linux-xfs@oss.sgi.com Subject: Re: kernel upgrade question. References: <3C861060.7070106@ksimachine.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Joe St.Clair" schrieb: > > I have 2 boxes running the SGI-XFS install of Redhat 7.1 with all of the > updates including kenel 2.4.9-21SGI_XFS_1.0.2. I have kept both boxes > up to date according to Redhat and have used the patched kernel RPM's > from the SGI ftp site. I am currently using 2.4.9-21SGI_XFS_1.0.2 and > used the RPM's found at > "ftp://oss.sgi.com/projects/xfs/download/Release-1.0.2/kernel_rpms/i386/contributed-RH-updates/2.4.9-21-RH7.1/". > > My question is with regards to 2.4.9-31 kernel upgrade. Will a simular > set of RPM's be available to keep in line with Redhat? If not, should I > go to 2.4.14? If I should go to 2.4.14, do I have to do anything to use > them on a original 1.0.1 install? I have made 2.4.9-31 kernels and I'm asking Eric or someone else at SGI to check them and put them on oss/contrib. -Simon > > Thanks. > > -- > Joseph St.Clair - KSI Machine & Engineering From owner-linux-xfs@oss.sgi.com Wed Mar 6 06:38:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26EcuK19005 for linux-xfs-outgoing; Wed, 6 Mar 2002 06:38:56 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26Ecm918983 for ; Wed, 6 Mar 2002 06:38:49 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16ibd0-0003lE-00; Wed, 06 Mar 2002 08:38:46 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g26Dciq21181; Wed, 6 Mar 2002 08:38:44 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: "Ralf G. R. Bergs" Cc: "linux-xfs@oss.sgi.com" , "Simon Matter" Subject: Re: external log config [was: Million files or so on RAID 5 Partition] From: "Martin K. Petersen" Organization: mkp.net References: Date: 06 Mar 2002 08:38:44 -0500 In-Reply-To: Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Ralf" == Ralf G R Bergs writes: Ralf> On Wed, 06 Mar 2002 08:11:55 +0100, Simon Matter wrote: >> I have made several performance tests some time ago. I learnt that, >> while it's imporant to have external log Ralf> Is it ALWAYS advisable to have an external log (I mean even on Ralf> hardware RAIDs,) or does this only apply to software RAIDs Ralf> (LVM)? It only applies to Linux software RAID5. It is due to the way the latter implements stripe caching. See http://oss.sgi.com/projects/xfs/mail_archive/0202/msg00329.html -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Wed Mar 6 06:46:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26EkLY19262 for linux-xfs-outgoing; Wed, 6 Mar 2002 06:46:21 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26EkF919239 for ; Wed, 6 Mar 2002 06:46:15 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16ibkA-0003oF-00; Wed, 06 Mar 2002 08:46:10 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g26Dk8521212; Wed, 6 Mar 2002 08:46:08 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: Simon Matter Cc: Martin Spott , linux-xfs@oss.sgi.com Subject: Re: Million files or so on RAID 5 Partition From: "Martin K. Petersen" Organization: Linuxcare, Inc. References: <200203052207.XAA03349@sirius.quickstep.oche.de> <3C85BEBC.37645CE6@ch.sauter-bc.com> Date: 06 Mar 2002 08:46:08 -0500 In-Reply-To: <3C85BEBC.37645CE6@ch.sauter-bc.com> Message-ID: Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Simon" == Simon Matter writes: Simon> Martin Spott schrieb: >> >> > I have a 8 disk RAID 5 partition (8 X 9 GB) on a split bus Compaq >> > array [...] >> >> Just to be curious (as always ....): Do you use the old 'md' driver >> for this or LVM ? Should I stay away from one of these (despite the >> issues with internal log on RAID5) ? Simon> IIRC you can not use LVM to create RAID5 devices, just Simon> RAID0,1. Correct. MD and LVM are orthogonal. Think of MD as a way to improve redundancy and/or performance. And LVM as a dynamic partitioning scheme. Forget about the striping features of LVM. MD RAID0 is a lot faster. Simon> Anyway it seems to be not so sure that we always have a working Simon> LVM for every kernel (Isn't it broken at this time for Simon> 2.5?). MD should be more safe here. And yet neither LVM nor MD are big I/O safe in 2.5 yet. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Wed Mar 6 06:47:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26El5m19342 for linux-xfs-outgoing; Wed, 6 Mar 2002 06:47:05 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26El2919320 for ; Wed, 6 Mar 2002 06:47:02 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16ibkv-0003oZ-00; Wed, 06 Mar 2002 08:46:57 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g26Dktn21216; Wed, 6 Mar 2002 08:46:55 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: Matteo Centonza Cc: Simon Matter , Martin Spott , Subject: Re: Million files or so on RAID 5 Partition From: "Martin K. Petersen" Organization: Linuxcare, Inc. References: Date: 06 Mar 2002 08:46:55 -0500 In-Reply-To: Message-ID: Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Matteo" == Matteo Centonza writes: Matteo> In my case, i have LVM stacked on RAID5 with internal log. Is Matteo> it possible that this configuration doesn't suffer the Matteo> performance penalty? Nope. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Wed Mar 6 07:26:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26FQw020563 for linux-xfs-outgoing; Wed, 6 Mar 2002 07:26:58 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26FQt920540 for ; Wed, 6 Mar 2002 07:26:55 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g26FYAkw017388 for ; Wed, 6 Mar 2002 09:34:10 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA32751; Wed, 6 Mar 2002 08:25:34 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:sandeen@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA00170; Wed, 6 Mar 2002 08:25:30 -0600 (CST) Date: Wed, 6 Mar 2002 08:25:29 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Simon Matter cc: , Subject: Re: kernel upgrade question. In-Reply-To: <3C8611C2.6948E33E@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 6 Mar 2002, Simon Matter wrote: > I have made 2.4.9-31 kernels and I'm asking Eric or someone else at SGI > to check them and put them on oss/contrib. > > -Simon And I'll do that very soon. I promise. :) -Eric From owner-linux-xfs@oss.sgi.com Wed Mar 6 09:53:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26HrSF25786 for linux-xfs-outgoing; Wed, 6 Mar 2002 09:53:28 -0800 Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26HrP925764 for ; Wed, 6 Mar 2002 09:53:25 -0800 Received: from [216.36.120.213] (HELO there) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 21455115; Wed, 06 Mar 2002 08:49:41 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects.com To: linux-xfs@oss.sgi.com, linux-lvm@sistina.com, mysql@lists.mysql.com Subject: System Suggestions Date: Wed, 6 Mar 2002 11:52:30 -0500 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Could someone, please, provide me with a link and/or facilitate some suggestons for configuration of the following components for a new DB server hosting MySQL 4.01MAX? I'm only looking to get a start and don't expect "THE" answer since all things are relative and I will have to further test the various scenarios. SuSE 7.3-2.4.18 512MB RAM 4x40GB Maxtor IDE (7200RPM) drives 3Ware 7800 RAID Controller LVM XFS Thank You, Anthony From owner-linux-xfs@oss.sgi.com Wed Mar 6 09:53:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26Hr9r25723 for linux-xfs-outgoing; Wed, 6 Mar 2002 09:53:09 -0800 Received: from muaddib.localnet (wh6012.stw.uni-rostock.de [139.30.106.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26Hr5925699 for ; Wed, 6 Mar 2002 09:53:06 -0800 Received: from ij by muaddib.localnet with local (Exim 3.34 #1 (Debian)) id 16ieR5-0005La-00; Wed, 06 Mar 2002 17:38:39 +0100 Date: Wed, 6 Mar 2002 17:38:39 +0100 To: Juan Quintela Cc: linux-xfs@oss.sgi.com Subject: Re: kernel panic booting from raid5 with external log Message-ID: <20020306163839.GA14671@muaddib.localnet> References: <20020302051731.GC14671@muaddib.localnet> <20020302154304.GD14671@muaddib.localnet> <3C828CB7.7050505@sgi.com> <20020303221923.GE14671@muaddib.localnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i From: Ingo Juergensmann Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Mar 04, 2002 at 12:24:05PM +0100, Juan Quintela wrote: > ingo> <0> Kernel panic: Attempted to kill init > Let me guess, you are using initrd, if that is true, you need to make > tricks in the initrd to get that options passed to the _real_ rootfs. At that moment no initrd was used, but now I'm using initrd and it kernel panics with similar error as before, but now at virtual address 00000040. What tricks do you mean exactly? Right now, I'm using a linuxrc with mount -n -t xfs -o logdev=/dev/sde2 / /initrd (statically linked mount). -- Ciao... // PowerAnimator & Maya Operator Ingo \X/ To boldly design where noone designed before! From owner-linux-xfs@oss.sgi.com Wed Mar 6 11:50:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26JoNB28151 for linux-xfs-outgoing; Wed, 6 Mar 2002 11:50:23 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26JoJ928127 for ; Wed, 6 Mar 2002 11:50:19 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g26JvZkw020962 for ; Wed, 6 Mar 2002 13:57:35 -0600 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA37020 for ; Wed, 6 Mar 2002 12:48:58 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id MAA25289 for ; Wed, 6 Mar 2002 12:48:58 -0600 (CST) Subject: [Announce] Updated 2.4.9-31 XFS kernels for Red Hat systems From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 06 Mar 2002 12:48:58 -0600 Message-Id: <1015440538.2043.16.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks to Simon Matter, updated XFS 1.0.2 RPMs for Red Hat kernels 2.4.9-31 are available at: ftp://oss.sgi.com/projects/xfs/download/Release-1.0.2/kernel_rpms/i386/contributed-RH-updates/2.4.9-31-RH7.1-RH7.2/ Since these are contributed, they have not been through rigorous testing at SGI. I've sanity-checked them, but that's it. These kernels contain the exact same XFS bits as the original 1.0.2 XFS release, with a newer underlying kernel from Red Hat. Again, many thanks to Simon for putting forth the effort to make these RPMS available! -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Mar 6 12:15:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26KFNP29136 for linux-xfs-outgoing; Wed, 6 Mar 2002 12:15:23 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26KEp929090 for ; Wed, 6 Mar 2002 12:14:51 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g26JEkbX011675 for ; Wed, 6 Mar 2002 11:14:46 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA36650; Wed, 6 Mar 2002 13:13:30 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA58684; Wed, 6 Mar 2002 13:13:29 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g26JCJe07416; Wed, 6 Mar 2002 13:12:19 -0600 Subject: Re: XFS NFS server Oops From: Steve Lord To: "Ian D. Hardy" Cc: linux-xfs@oss.sgi.com, idh@soton.ac.uk In-Reply-To: <3C5E8CFA.CACF28C3@soton.ac.uk> References: <3C5E8CFA.CACF28C3@soton.ac.uk> Content-Type: multipart/mixed; boundary="=-pDcE8Rn8SQGmWJVTuLS7" X-Mailer: Evolution/1.0.2 Date: 06 Mar 2002 13:12:19 -0600 Message-Id: <1015441939.18604.11.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-pDcE8Rn8SQGmWJVTuLS7 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2002-02-04 at 07:30, Ian D. Hardy wrote: > Hi, > > Anyone any ideas on the following Oops (processed with ksymoops 2.4.3). It is > from a NFS server (Dual 1Ghz Supermicro LE, 1Gbyte RAM, 40Gbyte Maxtor IDE > system disk, Zero-D/GForce RI Fibrechannel to IDE hardware RAID-5 500Gbyte > disk unit). It is running the Linux 2.4.17-xfs kernel taken as a CVS image > on 27th January. The main area of disk it is serving is on the HW RAID unit, > which is the only XFS filesystem on the system. The system had been up > for just over 3 days when it crashed. > > I reported a very similar failure a few weeks ago, at that time running a > 2.4.9 based kernel, Steve Lord suggested that we tried the latest CVS image > as this had fixed some memory alloacation problems. > > The machine is essentially an NFS fileserver to a computational cluster. Though > of possible interest is the 'save' process that was running on one of the > processes, this is the Legato Networker backup client process (which was > performing a full backup of the XFS filesystem at the time). I don't think > this is significant as I was seeing these crashes (at ~4 to 12 day intervals) > with the 2.4.9 kernel not dependant upon a 'save' session running. > > Ian, can you try the attached patch against a current cvs kernel and see if it helps at all. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com --=-pDcE8Rn8SQGmWJVTuLS7 Content-Disposition: attachment; filename=vnode.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Index: linux/fs/xfs/linux/xfs_super.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/tmp/TmpDir.7400-0/linux/fs/xfs/linux/xfs_super.c_1.161 Wed Mar 6 = 13:11:35 2002 +++ linux/fs/xfs/linux/xfs_super.c Tue Mar 5 04:54:59 2002 @@ -606,6 +606,7 @@ vnode_t *vp =3D LINVFS_GET_VP(inode); =20 if (vp) { + vn_rele(vp); vn_trace_entry(vp, "linvfs_delete_inode", (inst_t *)__return_address); /* @@ -626,6 +627,7 @@ vnode_t *vp =3D LINVFS_GET_VP(inode); =20 if (vp) { + vn_rele(vp); vn_trace_entry(vp, "linvfs_clear_inode", (inst_t *)__return_address); /* @@ -638,11 +640,13 @@ =20 void=20 linvfs_put_inode( - struct inode *inode) + struct inode *ip) { - vnode_t *vp =3D LINVFS_GET_VP(inode); + vnode_t *vp =3D LINVFS_GET_VP(ip); + int error; =20 - if (vp) vn_put(vp); + if (vp && (atomic_read(&ip->i_count) =3D=3D 1)) + VOP_RELEASE(vp, error); } =20 void =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Index: linux/fs/xfs/linux/xfs_vnode.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/tmp/TmpDir.7400-0/linux/fs/xfs/linux/xfs_vnode.c_1.69 Wed Mar 6 1= 3:11:35 2002 +++ linux/fs/xfs/linux/xfs_vnode.c Tue Mar 5 04:42:15 2002 @@ -224,29 +224,6 @@ } =20 /* - * Free an isolated vnode. - * The vnode must not have any other references. - */ -void -vn_free(struct vnode *vp) -{ - struct inode *inode; - - XFS_STATS_INC(xfsstats.vn_free); - - vn_trace_entry(vp, "vn_free", (inst_t *)__return_address); - - ASSERT(vn_count(vp) =3D=3D 1); - - ASSERT((vp->v_flag & VPURGE) =3D=3D 0); - vp->v_fbhv =3D NULL; - inode =3D LINVFS_GET_IP(vp); - inode->i_sb =3D NULL; - iput(inode); -} - - -/* * Get a reference on a vnode. */ vnode_t * @@ -276,25 +253,6 @@ return vp; } =20 - -/* - * "Temporary" routine to return the linux inode - * hold count, after everybody else can directly - * reference the inode (header magic!), this - * routine is dead meat.. - */ -int -vn_count(struct vnode *vp) -{ - struct inode *inode; - - inode =3D LINVFS_GET_IP(vp); - - ASSERT(inode); - - return atomic_read(&inode->i_count); -} - /* * "revalidate" the linux inode. */ @@ -439,19 +397,10 @@ } =20 /* - * Release a vnode.=20 - */ -void -vn_rele(struct vnode *vp) -{ - iput(LINVFS_GET_IP(vp)); -} - -/* * Call VOP_INACTIVE on last reference. */ void -vn_put(struct vnode *vp) +vn_rele(struct vnode *vp) { int s; int vcnt; @@ -473,7 +422,7 @@ * that i_count won't be decremented after we * return.=20 */ - if (vcnt =3D=3D 1) { + if (vcnt =3D=3D 0) { /* * It is absolutely, positively the case that * the lock manager will not be releasing vnodes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Index: linux/fs/xfs/linux/xfs_vnode.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/tmp/TmpDir.7400-0/linux/fs/xfs/linux/xfs_vnode.h_1.26 Wed Mar 6 1= 3:11:35 2002 +++ linux/fs/xfs/linux/xfs_vnode.h Sun Mar 3 18:04:15 2002 @@ -719,7 +719,6 @@ * incremented to define a new vnode epoch. */ extern void vn_init(void); -extern void vn_free(struct vnode *); extern int vn_wait(struct vnode *); extern vnode_t *vn_address(struct inode *); extern vnode_t *vn_initialize(struct vfs *, struct inode *, int); @@ -750,12 +749,18 @@ #define VMAP(vp, ip, vmap) {(vmap).v_vfsp =3D (vp)->v_vfsp, \ (vmap).v_number =3D (vp)->v_number, \ (vmap).v_ino =3D (ip)->i_ino; } -extern int vn_count(struct vnode *); extern void vn_purge(struct vnode *, vmap_t *); extern vnode_t *vn_get(struct vnode *, vmap_t *, uint); extern int vn_revalidate(struct vnode *, int); extern void vn_remove(struct vnode *); =20 +static inline int vn_count(struct vnode *vp) +{ + struct inode *ip =3D LINVFS_GET_IP(vp); + + return atomic_read(&ip->i_count); +} + /* * Flags for vn_get(). */ @@ -766,7 +771,6 @@ */ extern vnode_t *vn_hold(struct vnode *); extern void vn_rele(struct vnode *); -extern void vn_put(struct vnode *); =20 #if defined(CONFIG_XFS_VNODE_TRACING) =20 @@ -775,12 +779,12 @@ vn_trace_hold(vp, __FILE__, __LINE__, (inst_t *)__return_address)) #define VN_RELE(vp) \ (vn_trace_rele(vp, __FILE__, __LINE__, (inst_t *)__return_address), \ - vn_rele(vp)) + iput(LINVFS_GET_IP(vp))) =20 #else /* ! (defined(CONFIG_XFS_VNODE_TRACING)) */ =20 #define VN_HOLD(vp) ((void)vn_hold(vp)) -#define VN_RELE(vp) (vn_rele(vp)) +#define VN_RELE(vp) (iput(LINVFS_GET_IP(vp))) =20 #endif /* ! (defined(CONFIG_XFS_VNODE_TRACING) */ =20 --=-pDcE8Rn8SQGmWJVTuLS7-- From owner-linux-xfs@oss.sgi.com Wed Mar 6 12:33:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26KXLl29680 for linux-xfs-outgoing; Wed, 6 Mar 2002 12:33:21 -0800 Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26KXD929655 for ; Wed, 6 Mar 2002 12:33:13 -0800 Received: from poplar.sucs.soton.ac.uk (poplar.sucs.soton.ac.uk [152.78.128.30]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g26JX8H16189; Wed, 6 Mar 2002 19:33:08 GMT Received: from soton.ac.uk (pluto.sucs.soton.ac.uk [152.78.128.80]) (authenticated as idh) by poplar.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g26JWwg12392; Wed, 6 Mar 2002 19:32:58 GMT Message-ID: <3C866EEA.6CA3DC1A@soton.ac.uk> Date: Wed, 06 Mar 2002 19:32:58 +0000 From: "Ian D. Hardy" Organization: University of Southampton X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: XFS NFS server Oops References: <3C5E8CFA.CACF28C3@soton.ac.uk> <1015441939.18604.11.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, Thanks, I'll try to get the latest XFS CVS kernel and this patch compiled up and tested (on our development server) tonight/tomorrow and get it on our production server in the next couple of days. Fortunately (though in testing new versions/patches frustrating) it can be anytime between 2 hours and 2 weeks between crashes on our production server so it will be some time before I can say with any certainty if this is the fix. Will keep you informed. Thanks Ian Steve Lord wrote: > > On Mon, 2002-02-04 at 07:30, Ian D. Hardy wrote: > > Hi, > > > > Anyone any ideas on the following Oops (processed with ksymoops 2.4.3). It is > > from a NFS server (Dual 1Ghz Supermicro LE, 1Gbyte RAM, 40Gbyte Maxtor IDE > > system disk, Zero-D/GForce RI Fibrechannel to IDE hardware RAID-5 500Gbyte > > disk unit). It is running the Linux 2.4.17-xfs kernel taken as a CVS image > > on 27th January. The main area of disk it is serving is on the HW RAID unit, > > which is the only XFS filesystem on the system. The system had been up > > for just over 3 days when it crashed. > > > > I reported a very similar failure a few weeks ago, at that time running a > > 2.4.9 based kernel, Steve Lord suggested that we tried the latest CVS image > > as this had fixed some memory alloacation problems. > > > > The machine is essentially an NFS fileserver to a computational cluster. Though > > of possible interest is the 'save' process that was running on one of the > > processes, this is the Legato Networker backup client process (which was > > performing a full backup of the XFS filesystem at the time). I don't think > > this is significant as I was seeing these crashes (at ~4 to 12 day intervals) > > with the 2.4.9 kernel not dependant upon a 'save' session running. > > > > > > Ian, can you try the attached patch against a current cvs kernel and see > if it helps at all. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > > -------------------------------------------------------------------------------- > Name: vnode.patch > vnode.patch Type: Plain Text (text/plain) > Encoding: quoted-printable -- /////////////Technical Coordination, Research Services//////////////////// Ian Hardy Tel: 023 80 593577 Computing Services Southampton University email: idh@soton.ac.uk Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ From owner-linux-xfs@oss.sgi.com Wed Mar 6 12:40:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26KeaK29987 for linux-xfs-outgoing; Wed, 6 Mar 2002 12:40:36 -0800 Received: from whitestar.auctionwatch.com (ns0.auctionwatch.com [66.7.130.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26KeT929965 for ; Wed, 6 Mar 2002 12:40:31 -0800 Received: from cz75.corp.auctionwatch.com (mail@cz75.corp.auctionwatch.com [10.128.1.244]) by whitestar.auctionwatch.com (8.9.3/8.9.3) with ESMTP id LAA03148; Wed, 6 Mar 2002 11:43:45 -0800 Received: from petro by cz75.corp.auctionwatch.com with local (Exim 3.35 #1 (Debian)) id 16ihGx-0001jJ-00; Wed, 06 Mar 2002 11:40:23 -0800 Date: Wed, 6 Mar 2002 11:40:23 -0800 From: Petro To: linux-lvm@sistina.com Cc: linux-xfs@oss.sgi.com, mysql@lists.mysql.com Subject: Re: [linux-lvm] System Suggestions Message-ID: <20020306194023.GB32504@auctionwatch.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 06, 2002 at 11:52:30AM -0500, Anthony W. Marino wrote: > Could someone, please, provide me with a link and/or facilitate some > suggestons for configuration of the following components for a new DB server > hosting MySQL 4.01MAX? I'm only looking to get a start and don't expect > "THE" answer since all things are relative and I will have to further test > the various scenarios. > SuSE 7.3-2.4.18 > 512MB RAM > 4x40GB Maxtor IDE (7200RPM) drives > 3Ware 7800 RAID Controller > LVM > XFS You really don't provide us with enough information here. How big is your database, both in total size and in number of tables. How are those tables utilized, when they get used do you primarily open one table, manipulate it, then close it, or do you go across a bunch of tables? All of these, and more will have a dramatic impact on how you set this stuff up. -- Share and Enjoy. From owner-linux-xfs@oss.sgi.com Wed Mar 6 12:46:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26KkvR30529 for linux-xfs-outgoing; Wed, 6 Mar 2002 12:46:57 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26Kks930505 for ; Wed, 6 Mar 2002 12:46:54 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g26KsAkw021698 for ; Wed, 6 Mar 2002 14:54:10 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA38004 for ; Wed, 6 Mar 2002 13:45:33 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA31160 for ; Wed, 6 Mar 2002 13:45:33 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g26JiNm09808; Wed, 6 Mar 2002 13:44:23 -0600 Message-Id: <200203061944.g26JiNm09808@jen.americas.sgi.com> Date: Wed, 6 Mar 2002 13:44:23 -0600 Subject: TAKE - remove some dead code Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Small chunk of pagebuf code which was not used. Date: Wed Mar 6 11:44:58 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113413a linux/fs/xfs/xfs_buf.h - 1.83 - remove xfs_bwait_unpin, no one uses it. linux/fs/xfs/pagebuf/page_buf.c - 1.13 linux/fs/xfs/pagebuf/page_buf.h - 1.7 - remove pagebuf_wait_unpin no one uses it From owner-linux-xfs@oss.sgi.com Wed Mar 6 13:01:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26L17W31094 for linux-xfs-outgoing; Wed, 6 Mar 2002 13:01:07 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26L13931070 for ; Wed, 6 Mar 2002 13:01:03 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g26K0vbX016480 for ; Wed, 6 Mar 2002 12:00:58 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA38295 for ; Wed, 6 Mar 2002 13:59:42 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA45320 for ; Wed, 6 Mar 2002 13:59:42 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g26JwXT14095; Wed, 6 Mar 2002 13:58:33 -0600 Message-Id: <200203061958.g26JwXT14095@jen.americas.sgi.com> Date: Wed, 6 Mar 2002 13:58:33 -0600 Subject: TAKE - remove remains of internal readahead state from xfs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Readahead is handled at the vfs layer, this is dead code. Date: Wed Mar 6 11:58:25 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113419a linux/fs/xfs/xfs_macros.c - 1.39 - remove readahead reset macro - dead code linux/fs/xfs/xfs_vnodeops.c - 1.517 - remove readahead reset macro calls, and iocore_reset calls - the latter did nothing and we were obtaining a lock to do it. linux/fs/xfs/xfs_iocore.c - 1.27 - remove xfs_iocore_reset - it was dead code linux/fs/xfs/xfs_inode.h - 1.156 - remove internal readahead reset macro, not used linux/fs/xfs/linux/xfs_lrw.c - 1.126 - remove internal readahead reset - not used From owner-linux-xfs@oss.sgi.com Wed Mar 6 13:14:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26LEaq31666 for linux-xfs-outgoing; Wed, 6 Mar 2002 13:14:36 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26LEX931642 for ; Wed, 6 Mar 2002 13:14:33 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g26LESBA022474 for ; Wed, 6 Mar 2002 13:14:28 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA36200 for ; Wed, 6 Mar 2002 14:13:12 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA84667 for ; Wed, 6 Mar 2002 14:13:12 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g26KC2h15646; Wed, 6 Mar 2002 14:12:02 -0600 Message-Id: <200203062012.g26KC2h15646@jen.americas.sgi.com> Date: Wed, 6 Mar 2002 14:12:02 -0600 Subject: TAKE - another contribution to the dead code society Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Mar 6 12:12:43 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113423a linux/fs/xfs/xfs_trans_priv.h - 1.19 linux/fs/xfs/xfs_trans_ail.c - 1.60 linux/fs/xfs/xfs_mount.h - 1.136 - remove ancient INTERRUPT_LATENCY_TESTING code From owner-linux-xfs@oss.sgi.com Wed Mar 6 13:22:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26LMgJ32035 for linux-xfs-outgoing; Wed, 6 Mar 2002 13:22:42 -0800 Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26LMb932000 for ; Wed, 6 Mar 2002 13:22:37 -0800 Received: from [216.36.120.213] (HELO there) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 20218640; Wed, 06 Mar 2002 12:19:11 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects.com To: Petro , linux-lvm@sistina.com Subject: Re: [linux-lvm] System Suggestions Date: Wed, 6 Mar 2002 15:21:44 -0500 X-Mailer: KMail [version 1.3.2] Cc: linux-xfs@oss.sgi.com, mysql@lists.mysql.com References: <20020306194023.GB32504@auctionwatch.com> In-Reply-To: <20020306194023.GB32504@auctionwatch.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 06 March 2002 02:40 pm, Petro wrote: > On Wed, Mar 06, 2002 at 11:52:30AM -0500, Anthony W. Marino wrote: > > Could someone, please, provide me with a link and/or facilitate some > > suggestons for configuration of the following components for a new DB > > server hosting MySQL 4.01MAX? I'm only looking to get a start and don't > > expect "THE" answer since all things are relative and I will have to > > further test the various scenarios. > > SuSE 7.3-2.4.18 > > 512MB RAM > > 4x40GB Maxtor IDE (7200RPM) drives > > 3Ware 7800 RAID Controller > > LVM > > XFS > > You really don't provide us with enough information here. > > How big is your database, both in total size and in number of > tables. How are those tables utilized, when they get used do you > primarily open one table, manipulate it, then close it, or do you go > across a bunch of tables? > > All of these, and more will have a dramatic impact on how you set > this stuff up. Thanks. I'm more concerned about any specifics as it applies to MySQL Max and XFS, RAID and LVM as a whole. Are there any nuances as it applies to the whole? Anthony From owner-linux-xfs@oss.sgi.com Wed Mar 6 14:04:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26M4rI01242 for linux-xfs-outgoing; Wed, 6 Mar 2002 14:04:53 -0800 Received: from imf11bis.bellsouth.net (mail311.mail.bellsouth.net [205.152.58.171]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26M4i901216 for ; Wed, 6 Mar 2002 14:04:44 -0800 Received: from taz ([66.156.33.180]) by imf11bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz>; Wed, 6 Mar 2002 16:06:00 -0500 Date: Wed, 6 Mar 2002 15:59:50 -0500 From: Greg Freemyer Subject: re[2]: [linux-lvm] System Suggestions To: "Anthony W. Marino" , Petro , cc: , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g26M4j901217 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Anthony, I'd be careful with the IDE Raid controller. We just built a lab machine with a Promise IDE Raid controller and the assumption that we could get it and XFS to co-exist. I'm not doing the work, but the engineer that is tells me that the Promise Patch Kit only works with a very limited number of stock Redhat Kernels, and that we are NOT free to add the XFS patch. Even worse, promise does not supply their patch in source, so we are not free to tweak it ourselves. I'm not sure I really believe that, but that is what I'm told. If you do get the 3Ware IDE RAID controller to work with XFS, please let me know. Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com >> On Wednesday 06 March 2002 02:40 pm, Petro wrote: >> > On Wed, Mar 06, 2002 at 11:52:30AM -0500, Anthony W. Marino wrote: >> > > Could someone, please, provide me with a link and/or facilitate some >> > > suggestons for configuration of the following components for a new DB >> > > server hosting MySQL 4.01MAX? I'm only looking to get a start and >> don't >> > > expect "THE" answer since all things are relative and I will have to >> > > further test the various scenarios. >> > > SuSE 7.3-2.4.18 >> > > 512MB RAM >> > > 4x40GB Maxtor IDE (7200RPM) drives >> > > 3Ware 7800 RAID Controller >> > > LVM >> > > XFS >> > >> > You really don't provide us with enough information here. >> > >> > How big is your database, both in total size and in number of >> > tables. How are those tables utilized, when they get used do you >> > primarily open one table, manipulate it, then close it, or do you go >> > across a bunch of tables? >> > >> > All of these, and more will have a dramatic impact on how you set >> > this stuff up. >> Thanks. I'm more concerned about any specifics as it applies to MySQL Max >> >> and XFS, RAID and LVM as a whole. Are there any nuances as it applies to >> the >> whole? >> Anthony From owner-linux-xfs@oss.sgi.com Wed Mar 6 14:11:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26MBdt01508 for linux-xfs-outgoing; Wed, 6 Mar 2002 14:11:39 -0800 Received: from eclectic.kluge.net (IDENT:GYbYxK88EQQvOcLa1o15fgQMzzzRqvgo@dsl092-071-242.bos1.dsl.speakeasy.net [66.92.71.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26MBZ901485 for ; Wed, 6 Mar 2002 14:11:35 -0800 Received: (from felicity@localhost) by eclectic.kluge.net (8.11.6/8.11.6) id g26LBUr03293; Wed, 6 Mar 2002 16:11:30 -0500 Date: Wed, 6 Mar 2002 16:11:30 -0500 From: Theo Van Dinter To: linux-lvm@sistina.com Cc: "Anthony W. Marino" , Petro , linux-xfs@oss.sgi.com, mysql@lists.mysql.com Subject: Re: [linux-lvm] System Suggestions Message-ID: <20020306161130.D855@kluge.net> References: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz>; from freemyer@NorcrossGroup.com on Wed, Mar 06, 2002 at 03:59:50PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 06, 2002 at 03:59:50PM -0500, Greg Freemyer wrote: > If you do get the 3Ware IDE RAID controller to work with XFS, please let me know. Works beautifully. Have RH7.2, XFS, LVM, and a 3Ware 7410 running the box that I'm sending this from. :) The Promise RAID cards are cute but crappy from what I've heard. The 3ware cards seem to be excellent quality so far, and the driver (as far as I can tell) was GPLed and is standard in the 2.4 kernel series (well, it's in 2.4.9 anyway...) -- Randomly Generated Tagline: I'm a white male, aged 18 to 49. Everyone listens to me! No matter how dumb my suggestions are. -- Homer Simpson Lisa vs. Malibu Stacy From owner-linux-xfs@oss.sgi.com Wed Mar 6 14:24:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26MO7H01910 for linux-xfs-outgoing; Wed, 6 Mar 2002 14:24:07 -0800 Received: from mxzilla1.xs4all.nl (mxzilla1.xs4all.nl [194.109.6.54]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26MO1901888 for ; Wed, 6 Mar 2002 14:24:01 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g26LNm9i065110; Wed, 6 Mar 2002 22:23:49 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA20128; Wed, 6 Mar 2002 22:23:48 +0100 (CET) Date: Wed, 6 Mar 2002 22:23:48 +0100 (CET) From: Seth Mos To: Greg Freemyer cc: "Anthony W. Marino" , Petro , linux-lvm@sistina.com, linux-xfs@oss.sgi.com, mysql@lists.mysql.com Subject: Re: re[2]: [linux-lvm] System Suggestions In-Reply-To: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 6 Mar 2002, Greg Freemyer wrote: > Anthony, > > I'd be careful with the IDE Raid controller. > > We just built a lab machine with a Promise IDE Raid controller and the assumption that we could get it and XFS to co-exist. > > I'm not doing the work, but the engineer that is tells me that the Promise Patch Kit only works with a very limited number of stock Redhat Kernels, and that we are NOT free to add the XFS patch. Even worse, promise does not supply their patch in source, so we are not free to tweak it ourselves. > > I'm not sure I really believe that, but that is what I'm told. > > If you do get the 3Ware IDE RAID controller to work with XFS, please let me know. 3Ware IDE controllers and XFS are just fine. The driver is available in source form and can be added to any kernel. The promise raid controllers are not really nice. They have never ever been open about the hardware specs of the cards. For some reason they seem to think that their IDE controllers are something special. Which they are not. If you are looking into using the 3Ware controllers watch the following: The 64xx controllers are underpowered and should better not be used in raid 5 mode. The 74xx controllers seem to be good and should be fine with raid5 but note that raid5 will always have slow write speeds. Software raid can be used if you need a lot of speed _and_ redundancy. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Mar 6 14:28:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26MSDt02127 for linux-xfs-outgoing; Wed, 6 Mar 2002 14:28:13 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26MS9902105 for ; Wed, 6 Mar 2002 14:28:09 -0800 Received: from smtp.digikom.net (smtp.digikom.net [194.52.56.65]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA02194 for ; Wed, 6 Mar 2002 13:28:12 -0800 (PST) mail_from (andewid@tnonline.net) Received: from s20.dknet.se ([10.0.0.55]) by smtp.digikom.net with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 22:22:19 +0100 Received: from kadzuki [217.208.168.40] by s20.dknet.se with ESMTP (SMTPD32-6.06) id A94C65101A0; Wed, 06 Mar 2002 22:25:32 +0100 Date: Wed, 6 Mar 2002 22:25:39 +0100 From: Anders Widman X-Mailer: The Bat! (v1.54 Beta/43) UNREG / CD5BF9353B3B7091 Reply-To: Anders Widman Organization: TNOnline.NET X-Priority: 3 (Normal) Message-ID: <11679047703.20020306222539@tnonline.net> To: linux-lvm-admin@sistina.com, Theo Van Dinter CC: linux-lvm@sistina.com, "Anthony W. Marino" , Petro , , Subject: Re: [linux-lvm] System Suggestions In-Reply-To: <20020306161130.D855@kluge.net> References: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> <20020306161130.D855@kluge.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2002 21:22:19.0359 (UTC) FILETIME=[FF42FEF0:01C1C554] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, Mar 06, 2002 at 03:59:50PM -0500, Greg Freemyer wrote: >> If you do get the 3Ware IDE RAID controller to work with XFS, please let me know. > Works beautifully. Have RH7.2, XFS, LVM, and a 3Ware 7410 running the > box that I'm sending this from. :) > The Promise RAID cards are cute but crappy from what I've heard. > The 3ware cards seem to be excellent quality so far, and the driver (as > far as I can tell) was GPLed and is standard in the 2.4 kernel series > (well, it's in 2.4.9 anyway...) I have a Promise FastTrak 100 card and it is very fast and stable. I think that Toms Hardware had a review of it a while ago (placed the Promise card as winner). Anyway. Linux Kernel now days has support for FastTrack cards too. //Anders From owner-linux-xfs@oss.sgi.com Wed Mar 6 14:39:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26MdsU02488 for linux-xfs-outgoing; Wed, 6 Mar 2002 14:39:54 -0800 Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26Mdo902465 for ; Wed, 6 Mar 2002 14:39:51 -0800 Received: from [216.36.120.213] (HELO there) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 20233424; Wed, 06 Mar 2002 13:36:24 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects.com To: Seth Mos , Greg Freemyer Subject: Re: re[2]: [linux-lvm] System Suggestions Date: Wed, 6 Mar 2002 16:38:57 -0500 X-Mailer: KMail [version 1.3.2] Cc: Petro , linux-lvm@sistina.com, linux-xfs@oss.sgi.com, mysql@lists.mysql.com References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > If you are looking into using the 3Ware controllers watch the following: > The 64xx controllers are underpowered and should better not be used in > raid 5 mode. > The 74xx controllers seem to be good and should be fine with raid5 but > note that raid5 will always have slow write speeds. > Is there a way to minimize the write penalty using both XFS and LVM with RAID 5? Thanks, Anthony > Software raid can be used if you need a lot of speed _and_ redundancy. > > Cheers > Seth From owner-linux-xfs@oss.sgi.com Wed Mar 6 14:43:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26MhtP02700 for linux-xfs-outgoing; Wed, 6 Mar 2002 14:43:55 -0800 Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26Mhp902674 for ; Wed, 6 Mar 2002 14:43:51 -0800 Received: from [216.36.120.213] (HELO there) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 21502935; Wed, 06 Mar 2002 13:40:05 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects.com To: Greg Freemyer , Petro , Subject: Re: re[2]: [linux-lvm] System Suggestions Date: Wed, 6 Mar 2002 16:42:58 -0500 X-Mailer: KMail [version 1.3.2] Cc: , References: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> In-Reply-To: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > If you do get the 3Ware IDE RAID controller to work with XFS, please let me > know. > I'm going to get moving on this within the next day or two after I've had time to do some research on what partitioning and levels of RAID to put where ... Thank You, Anthony From owner-linux-xfs@oss.sgi.com Wed Mar 6 14:46:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26MkIY02876 for linux-xfs-outgoing; Wed, 6 Mar 2002 14:46:18 -0800 Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26MkE902853 for ; Wed, 6 Mar 2002 14:46:14 -0800 Received: from [216.36.120.213] (HELO there) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 20234823; Wed, 06 Mar 2002 13:42:48 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects.com To: linux-lvm@sistina.com, Theo Van Dinter Subject: Re: [linux-lvm] System Suggestions Date: Wed, 6 Mar 2002 16:45:21 -0500 X-Mailer: KMail [version 1.3.2] Cc: Petro , linux-xfs@oss.sgi.com, mysql@lists.mysql.com References: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> <20020306161130.D855@kluge.net> In-Reply-To: <20020306161130.D855@kluge.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 06 March 2002 04:11 pm, Theo Van Dinter wrote: > On Wed, Mar 06, 2002 at 03:59:50PM -0500, Greg Freemyer wrote: > > If you do get the 3Ware IDE RAID controller to work with XFS, please let > > me know. > > Works beautifully. Have RH7.2, XFS, LVM, and a 3Ware 7410 running the > box that I'm sending this from. :) > > The Promise RAID cards are cute but crappy from what I've heard. > The 3ware cards seem to be excellent quality so far, and the driver (as > far as I can tell) was GPLed and is standard in the 2.4 kernel series > (well, it's in 2.4.9 anyway...) I should then hope to find all I need in my 2.4.18 kernel to pull this off (3Ware/XFS/LVM)? What RAID/LVM config do you recommend to minimize write issues with RAID 5? Anthony From owner-linux-xfs@oss.sgi.com Wed Mar 6 14:51:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26MpmF03138 for linux-xfs-outgoing; Wed, 6 Mar 2002 14:51:48 -0800 Received: from imf12bis.bellsouth.net (mail012.mail.bellsouth.net [205.152.58.32]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26Mpj903113 for ; Wed, 6 Mar 2002 14:51:45 -0800 Received: from taz ([66.156.33.180]) by imf12bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020306215256.PCSF8136.imf12bis.bellsouth.net@taz>; Wed, 6 Mar 2002 16:52:56 -0500 Date: Wed, 6 Mar 2002 16:46:54 -0500 From: Greg Freemyer Subject: re[4]: [linux-lvm] System Suggestions To: "Anthony W. Marino" , Seth Mos cc: Petro , , , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020306215256.PCSF8136.imf12bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g26Mpk903116 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> > >> Is there a way to minimize the write penalty using both XFS and LVM with >> RAID >> 5? >> Thanks, >> Anthony You have been following the thread about using a external log partition setup as a small Raid 1 partition. Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Mar 6 14:51:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26Mpvg03247 for linux-xfs-outgoing; Wed, 6 Mar 2002 14:51:57 -0800 Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26Mps903203 for ; Wed, 6 Mar 2002 14:51:54 -0800 Received: from [216.36.120.213] (HELO there) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 21504179; Wed, 06 Mar 2002 13:48:09 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects.com To: linux-lvm@sistina.com, Anders Widman , linux-lvm-admin@sistina.com, Theo Van Dinter Subject: Re: [linux-lvm] System Suggestions Date: Wed, 6 Mar 2002 16:51:01 -0500 X-Mailer: KMail [version 1.3.2] Cc: linux-lvm@sistina.com, Petro , , References: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> <20020306161130.D855@kluge.net> <11679047703.20020306222539@tnonline.net> In-Reply-To: <11679047703.20020306222539@tnonline.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I have a Promise FastTrak 100 card and it is very fast and stable. I > think that Toms Hardware had a review of it a while ago (placed the > Promise card as winner). > > Anyway. Linux Kernel now days has support for FastTrack cards too. > > //Anders Besides my 3Ware 7800, I also have several promise TX2 100 controllers which I have had for around 9 months since at that time their drivers didn't work with Linux. I'll most likely use them later after I get this DB server up and running. Anthony From owner-linux-xfs@oss.sgi.com Wed Mar 6 14:55:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26MtOX03549 for linux-xfs-outgoing; Wed, 6 Mar 2002 14:55:24 -0800 Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26MtL903510 for ; Wed, 6 Mar 2002 14:55:21 -0800 Received: from [216.36.120.213] (HELO there) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 20236447; Wed, 06 Mar 2002 13:51:55 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects.com To: Greg Freemyer , Seth Mos Subject: Re: re[4]: [linux-lvm] System Suggestions Date: Wed, 6 Mar 2002 16:54:28 -0500 X-Mailer: KMail [version 1.3.2] Cc: Petro , , , References: <20020306215256.PCSF8136.imf12bis.bellsouth.net@taz> In-Reply-To: <20020306215256.PCSF8136.imf12bis.bellsouth.net@taz> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 06 March 2002 04:46 pm, Greg Freemyer wrote: > >> Is there a way to minimize the write penalty using both XFS and LVM > >> with RAID > >> 5? > >> > >> Thanks, > >> Anthony > > You have been following the thread about using a external log partition > setup as a small Raid 1 partition. > I saw that this morning and needed some more specifics on it. RAID1 hardware or software? I guess that I should just locate the thread. Thanks, Anthony > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > The Norcross Group > www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Mar 6 14:57:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26MvG203788 for linux-xfs-outgoing; Wed, 6 Mar 2002 14:57:16 -0800 Received: from eclectic.kluge.net (IDENT:jq2u1BFdd/76HmIOh2pxV1El5EDec0vL@dsl092-071-242.bos1.dsl.speakeasy.net [66.92.71.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26MvC903764 for ; Wed, 6 Mar 2002 14:57:12 -0800 Received: (from felicity@localhost) by eclectic.kluge.net (8.11.6/8.11.6) id g26Lv8e03634; Wed, 6 Mar 2002 16:57:08 -0500 Date: Wed, 6 Mar 2002 16:57:08 -0500 From: Theo Van Dinter To: "Anthony W. Marino" Cc: linux-lvm@sistina.com, Petro , linux-xfs@oss.sgi.com Subject: Re: [linux-lvm] System Suggestions Message-ID: <20020306165708.E855@kluge.net> References: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> <20020306161130.D855@kluge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from anthony@AWMObjects.com on Wed, Mar 06, 2002 at 04:45:21PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 06, 2002 at 04:45:21PM -0500, Anthony W. Marino wrote: > I should then hope to find all I need in my 2.4.18 kernel to pull this off > (3Ware/XFS/LVM)? What RAID/LVM config do you recommend to minimize write > issues with RAID 5? If you have a vanilla 2.4.18 kernel, you definately won't have XFS built in, and I don't think you'll have the latest LVM code built-in (although I'm sure someone will correct me on this if I'm wrong ...) The kernel and a lot of patches later, and you should be all set. :) -- Randomly Generated Tagline: "Probability ratio 1:1. We have achieved normality. Whatever you can't deal with is now therefore your own problem." - HitchHiker's Guide to the Galaxy From owner-linux-xfs@oss.sgi.com Wed Mar 6 15:02:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g26N2Sp04179 for linux-xfs-outgoing; Wed, 6 Mar 2002 15:02:28 -0800 Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g26N2L904157 for ; Wed, 6 Mar 2002 15:02:22 -0800 Received: from [216.36.120.213] (HELO there) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 20237405; Wed, 06 Mar 2002 13:58:55 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects.com To: Theo Van Dinter Subject: Re: [linux-lvm] System Suggestions Date: Wed, 6 Mar 2002 17:01:29 -0500 X-Mailer: KMail [version 1.3.2] Cc: linux-lvm@sistina.com, Petro , linux-xfs@oss.sgi.com References: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> <20020306165708.E855@kluge.net> In-Reply-To: <20020306165708.E855@kluge.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 06 March 2002 04:57 pm, Theo Van Dinter wrote: > On Wed, Mar 06, 2002 at 04:45:21PM -0500, Anthony W. Marino wrote: > > I should then hope to find all I need in my 2.4.18 kernel to pull this > > off (3Ware/XFS/LVM)? What RAID/LVM config do you recommend to minimize > > write issues with RAID 5? > > If you have a vanilla 2.4.18 kernel, you definately won't have XFS built > in, and I don't think you'll have the latest LVM code built-in (although > I'm sure someone will correct me on this if I'm wrong ...) > > The kernel and a lot of patches later, and you should be all set. :) My kernel does have XFS and I believe LVM. I need to find out about versions. This kernel is built by a Kernel person from SuSE and is not a fully supported release, however, it was just released the other day. Maybe I'm lucky and have latest and greatest LVM/XFS? I've never patched a kernel before, however, I have built several. Anthony From owner-linux-xfs@oss.sgi.com Wed Mar 6 16:48:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g270mJO06595 for linux-xfs-outgoing; Wed, 6 Mar 2002 16:48:19 -0800 Received: from minnie.omroep.nl (minnie.omroep.nl [145.58.30.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g270mF906572 for ; Wed, 6 Mar 2002 16:48:15 -0800 Received: (from smap@localhost) by minnie.omroep.nl (SGI-8.9.3/8.9.3) id AAA96587; Thu, 7 Mar 2002 00:48:08 +0100 (CET) Received: from kwek.omroep.nl (145.58.31.3 "EHLO kwek.omroep.nl") by minnie.omroep.nl with ESMTP (smap v3.0 nederlandse publieke omroep) id xma9019666; Thu, 7 Mar 02 00:48:07 +0100 Received: from localhost (matthijs@localhost) by kwek.omroep.nl (SGI-8.9.3/8.9.3) with ESMTP id AAA62843; Thu, 7 Mar 2002 00:48:05 +0100 (CET) X-Authentication-Warning: kwek.omroep.nl: matthijs owned process doing -bs Date: Thu, 7 Mar 2002 00:48:05 +0100 From: Matthijs van der Klip X-X-Sender: matthijs@kwek.omroep.nl To: Linux XFS Mailing List Subject: status of the 'null' issue Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Could someone tell me what the status of the 'null' issue is?: http://oss.sgi.com/projects/xfs/faq.html#nulls Has any solution or workaround been developed yet? Can we expect a solution in the next official release? Best regards, -- Matthijs van der Klip - Unix Administrator NOS - Dutch Public Broadcasting Organisation http://www.omroep.nl From owner-linux-xfs@oss.sgi.com Wed Mar 6 16:56:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g270uIw06875 for linux-xfs-outgoing; Wed, 6 Mar 2002 16:56:18 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g270uD906852 for ; Wed, 6 Mar 2002 16:56:13 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g26Nu8bX028372 for ; Wed, 6 Mar 2002 15:56:08 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA41757; Wed, 6 Mar 2002 17:54:52 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA84561; Wed, 6 Mar 2002 17:54:52 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g26NspL01523; Wed, 6 Mar 2002 17:54:51 -0600 Subject: Re: status of the 'null' issue From: Steve Lord To: Matthijs van der Klip Cc: Linux XFS Mailing List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 06 Mar 2002 17:54:51 -0600 Message-Id: <1015458891.1496.9.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-06 at 17:48, Matthijs van der Klip wrote: > Hi, > > Could someone tell me what the status of the 'null' issue is?: > > http://oss.sgi.com/projects/xfs/faq.html#nulls > > > Has any solution or workaround been developed yet? Can we expect a > solution in the next official release? > The 2.4.18 kernel in cvs and the patches has some code which removes the synchronous transactions from xfs. For the most part these tended to be the culprit in that an inode size update was forced out into the log long before the data was. So, while it is still possible, it is less likely than it was. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Mar 6 17:08:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2718lx07402 for linux-xfs-outgoing; Wed, 6 Mar 2002 17:08:47 -0800 Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2718g907375 for ; Wed, 6 Mar 2002 17:08:42 -0800 Received: from idcomm.com (IDENT:u7JqJuSw0Jv89WwF2wY6GsjDXK39S++y@k56-pip73.idcomm.com [209.60.72.200] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g270IHV23557 for ; Wed, 6 Mar 2002 17:18:17 -0700 Message-ID: <3C86AFC6.FECE2FC8@idcomm.com> Date: Wed, 06 Mar 2002 17:09:42 -0700 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 CC: Linux XFS Mailing List Subject: Re: status of the 'null' issue References: <1015458891.1496.9.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > On Wed, 2002-03-06 at 17:48, Matthijs van der Klip wrote: > > Hi, > > > > Could someone tell me what the status of the 'null' issue is?: > > > > http://oss.sgi.com/projects/xfs/faq.html#nulls > > > > > > Has any solution or workaround been developed yet? Can we expect a > > solution in the next official release? > > > > The 2.4.18 kernel in cvs and the patches has some code which removes > the synchronous transactions from xfs. For the most part these tended > to be the culprit in that an inode size update was forced out into > the log long before the data was. > > So, while it is still possible, it is less likely than it was. I would assume that a file subject to NULLs would still be at risk of being emptied out, rather than acting as nice as full journalling would. So is this 2.4.18 code intended to simply avoid filling with nulls, or does it completely protect the file (the former seems more likely)? It does not seem possible to have the advantages of full journalling within a meta journalling system. D. Stimits, stimits@idcomm.com > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Mar 6 17:10:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g271AWo07570 for linux-xfs-outgoing; Wed, 6 Mar 2002 17:10:32 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g271AR907547 for ; Wed, 6 Mar 2002 17:10:27 -0800 Received: (qmail 5232 invoked by uid 500); 7 Mar 2002 00:09:51 -0000 Subject: Re: status of the 'null' issue From: Austin Gonyou To: Steve Lord Cc: Matthijs van der Klip , Linux XFS Mailing List In-Reply-To: <1015458891.1496.9.camel@jen.americas.sgi.com> References: <1015458891.1496.9.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 06 Mar 2002 18:09:51 -0600 Message-Id: <1015459791.5063.4.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just beautiful. Thanks! On Wed, 2002-03-06 at 17:54, Steve Lord wrote: > On Wed, 2002-03-06 at 17:48, Matthijs van der Klip wrote: > > Hi, > > > > Could someone tell me what the status of the 'null' issue is?: > > > > http://oss.sgi.com/projects/xfs/faq.html#nulls > > > > > > Has any solution or workaround been developed yet? Can we expect a > > solution in the next official release? > > > > The 2.4.18 kernel in cvs and the patches has some code which removes > the synchronous transactions from xfs. For the most part these tended > to be the culprit in that an inode size update was forced out into > the log long before the data was. > > So, while it is still possible, it is less likely than it was. > > Steve > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Wed Mar 6 17:37:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g271bRG08226 for linux-xfs-outgoing; Wed, 6 Mar 2002 17:37:27 -0800 Received: from mailnet.consensys.com ([209.47.40.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g271bM908195 for ; Wed, 6 Mar 2002 17:37:22 -0800 Received: from Francis ([209.47.40.10]) by mailnet.consensys.com (8.11.6/8.11.2) with SMTP id g26JY1W32124 for ; Wed, 6 Mar 2002 19:34:01 GMT Message-ID: <001f01c1c570$3d88a960$8d02a8c0@consensys.com> From: "Francis Qu" To: Subject: catch mount event Date: Wed, 6 Mar 2002 19:37:19 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, In my DMAPI application, I'd like to catch the mount event of xfs file system. After init service and create session, I set DM_EVENT_MOUNT and dm_set_disp, then I dm_get_events. Now the program is waiting for mount event to come. When I mount -o dmapi -t xfs /dev/xxx /mnt and it mounts, but the program doesn't catch the mount event. Thanks. Francis [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Mar 6 18:36:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g272aLs09748 for linux-xfs-outgoing; Wed, 6 Mar 2002 18:36:21 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g272aG909726 for ; Wed, 6 Mar 2002 18:36:16 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g272hXkw024956 for ; Wed, 6 Mar 2002 20:43:33 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA43323; Wed, 6 Mar 2002 19:34:56 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:sandeen@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id TAA56403; Wed, 6 Mar 2002 19:34:55 -0600 (CST) Date: Wed, 6 Mar 2002 19:34:55 -0600 (CST) From: Eric Sandeen X-X-Sender: To: "D. Stimits" cc: Linux XFS Mailing List Subject: Re: status of the 'null' issue In-Reply-To: <3C86AFC6.FECE2FC8@idcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'll preface this by saying "when you lose power you lose data" but in the new scenario, you're more likely to "get your old file back." In the new async transaction scenario, if you quickly edit->write->quit->save->lose power then _nothing_ makes it out to disk - not data, not metadata, nothing. So, essentially, your old file is still there when you reboot. In the synchronous transaction case, the write would force the metadata (including a truncate) out to disk, but the new data never made it. So you had a file with a size, but no data - hence nulls. -Eric On Wed, 6 Mar 2002, D. Stimits wrote: > I would assume that a file subject to NULLs would still be at risk of > being emptied out, rather than acting as nice as full journalling would. > So is this 2.4.18 code intended to simply avoid filling with nulls, or > does it completely protect the file (the former seems more likely)? It > does not seem possible to have the advantages of full journalling within > a meta journalling system. From owner-linux-xfs@oss.sgi.com Wed Mar 6 20:27:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g274RI911880 for linux-xfs-outgoing; Wed, 6 Mar 2002 20:27:18 -0800 Received: from web13003.mail.yahoo.com (web13003.mail.yahoo.com [216.136.174.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g274RC911858 for ; Wed, 6 Mar 2002 20:27:12 -0800 Message-ID: <20020307032711.20158.qmail@web13003.mail.yahoo.com> Received: from [207.218.233.153] by web13003.mail.yahoo.com via HTTP; Wed, 06 Mar 2002 19:27:11 PST Date: Wed, 6 Mar 2002 19:27:11 -0800 (PST) From: Darius Stout Subject: How to build external logs? To: 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 Hello Fellow XFS'ers, I need you help. I have read and have experienced how writes are slow to a software RAID5 array. I found in the FAQ that to regain lost performance, I could either setup a RAID1 array across a RAID5 array OR set up a logging filesystem on a (preferably) existing RAID1 array. I prefer the latter but I am running into problems with the best way to build this. I am running two arrays of 11 100GB SCSI drives in RAID5 on a Gigabyte motherboard (8idxh) w/a 1.8GHz P4 and 1.5GB of memory. I have a RAID1 consisting of two Maxtor 60Gb EIDE 100 drives with space available for extra filesystems. The O/S is Redhat 7.2. It has been loaded with the SGI Installer version 1.02. I need to know 1) What kind of partition to create on the RAID1 drives. 2) What size should I make the logginf FS considering the size of the data area? 3) How do I determine the block size necessary for the data XFS portion if a external log may be involved? 4) Is it ok to use a single RAID1 array to be the target of two XFS external logs? 5) Since the size of each array is 1 TB. Is there any other performance criteria I should take notice of? Thank you very much. I really appreciate any input. Darius Stout __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ From owner-linux-xfs@oss.sgi.com Wed Mar 6 20:40:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g274eL312284 for linux-xfs-outgoing; Wed, 6 Mar 2002 20:40:21 -0800 Received: from whitestar.auctionwatch.com (ns0.auctionwatch.com [66.7.130.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g274eH912260 for ; Wed, 6 Mar 2002 20:40:17 -0800 Received: from cz75.corp.auctionwatch.com (mail@cz75.corp.auctionwatch.com [10.128.1.244]) by whitestar.auctionwatch.com (8.9.3/8.9.3) with ESMTP id TAA14987; Wed, 6 Mar 2002 19:43:33 -0800 Received: from petro by cz75.corp.auctionwatch.com with local (Exim 3.35 #1 (Debian)) id 16iolF-0002p2-00; Wed, 06 Mar 2002 19:40:09 -0800 Date: Wed, 6 Mar 2002 19:40:09 -0800 From: Petro To: Theo Van Dinter Cc: linux-lvm@sistina.com, "Anthony W. Marino" , linux-xfs@oss.sgi.com, mysql@lists.mysql.com Subject: Re: [linux-lvm] System Suggestions Message-ID: <20020307034009.GJ32504@auctionwatch.com> References: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> <20020306161130.D855@kluge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020306161130.D855@kluge.net> User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 06, 2002 at 04:11:30PM -0500, Theo Van Dinter wrote: > On Wed, Mar 06, 2002 at 03:59:50PM -0500, Greg Freemyer wrote: > > If you do get the 3Ware IDE RAID controller to work with XFS, please let me know. > Works beautifully. Have RH7.2, XFS, LVM, and a 3Ware 7410 running the > box that I'm sending this from. :) > The Promise RAID cards are cute but crappy from what I've heard. > The 3ware cards seem to be excellent quality so far, and the driver (as > far as I can tell) was GPLed and is standard in the 2.4 kernel series > (well, it's in 2.4.9 anyway...) We have 10 of the 3ware cards, and while the drive is GPLd and in the kernel, we have not been satisfied with the stability of the system We haven't had a chance yet to qual the latest firmware, etc., but we went with dumb IDE expansion cards (we're only using 4 ide drives per system) and we're getting better speed (RAID0 or 1+0 depending) than we were off the 3ware card. We are not using XFS, so no comments there. We're also having some problems with Mysql that people keep pointing fingers at LVM for, but at this time we're point right back and saying "No!" in a firm voice... -- Share and Enjoy. From owner-linux-xfs@oss.sgi.com Wed Mar 6 21:15:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g275Fc013156 for linux-xfs-outgoing; Wed, 6 Mar 2002 21:15:38 -0800 Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g275FY913131 for ; Wed, 6 Mar 2002 21:15:34 -0800 Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8]) by ex1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g274FXV27548; Wed, 6 Mar 2002 22:15:33 -0600 (CST) Received: from niri.ncsa.uiuc.edu (niri.ncsa.uiuc.edu [141.142.64.68]) by mx1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g274FXB17524; Wed, 6 Mar 2002 22:15:33 -0600 (CST) From: Stuart Levy Received: (from slevy@localhost) by niri.ncsa.uiuc.edu (8.8.5/8.8.5) id WAA16951; Wed, 6 Mar 2002 22:15:32 -0600 (CST) Date: Wed, 6 Mar 2002 22:15:32 -0600 (CST) Message-Id: <200203070415.WAA16951@niri.ncsa.uiuc.edu> To: Petro Subject: Re: [linux-lvm] System Suggestions Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> <20020306161130.D855@kluge.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk wrote: > We have 10 of the 3ware cards, and while the drive is GPLd and in > the kernel, we have not been satisfied with the stability of the > system A 3ware 7850 here (8 drive hw RAID5) performed erratically until I got their latest .016 driver, which seems to be in the 2.4.18 kernel too. The earlier .010 driver in 2.4.<=17 would sometimes get into a low-performance (~15MB/sec) mode, but the .016 driver has been doing very well. 3ware tech support have been very responsive too. Based on a few weeks' experience, I'd recommend them. Stuart Levy, slevy@ncsa.uiuc.edu From owner-linux-xfs@oss.sgi.com Wed Mar 6 21:49:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g275ncR13827 for linux-xfs-outgoing; Wed, 6 Mar 2002 21:49:38 -0800 Received: from mta2.srv.hcvlny.cv.net (mta2.srv.hcvlny.cv.net [167.206.5.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g275nW913800 for ; Wed, 6 Mar 2002 21:49:32 -0800 Received: from nic.com (ool-4350f032.dyn.optonline.net [67.80.240.50]) by mta2.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GSL009LP6QHFR@mta2.srv.hcvlny.cv.net> for linux-xfs@oss.sgi.com; Wed, 06 Mar 2002 23:49:29 -0500 (EST) Date: Wed, 06 Mar 2002 23:44:12 -0500 From: John W Subject: Nillion files NFS/XFS To: linux-xfs@oss.sgi.com Reply-to: jwest@nic.com Message-id: <3C86F01C.C01BB399@nic.com> Organization: Long Pond Industries MIME-version: 1.0 X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-xfs i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Folks, NFS wackiness: Thanks for the NFS fix pointer to Tronds' site. Recompiled 2.4.18-xfs-trond, and all is well again! Machine is a L440GX Dual 600 PIII machine. Nice and stable. Million Files Machine: Will need to hold off on the adding Log file problem to the Million File array. Any predictions on how much performance would go up? There were several choices for 53C875 support. Do these all suffer the same performance issues for a million NCR53C7,8XX SCSI Support files on XFS partition? SYM53C8XXX Version 2 Scsi support NCR53C8XXX SCSI Support SYM53C8XXX SCSI Support Some have queing and depth settings. Do these values affect the performance of the I/O ? Did see thru sar (IIRC) that there were 250 Or so interrupts per second. Is this OK? Can I tune this in the compiled kernel via Tagged command queue depth, or other tunable kernel parameters. Is there any analogue to Kernel param DNLC or similar to help out the Directory names speed issue that seems to be lurking in the shadows and perhaps mucking things up? Thanks, always! John Westerdale. -- # Inspire Growth # From owner-linux-xfs@oss.sgi.com Wed Mar 6 23:32:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g277Whc15838 for linux-xfs-outgoing; Wed, 6 Mar 2002 23:32:43 -0800 Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g277Wc915815 for ; Wed, 6 Mar 2002 23:32:38 -0800 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g276WTHC086020; Thu, 7 Mar 2002 07:32:29 +0100 (CET) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA16878; Thu, 7 Mar 2002 07:32:29 +0100 (CET) Date: Thu, 7 Mar 2002 07:32:29 +0100 (CET) From: Seth Mos To: "Anthony W. Marino" cc: Greg Freemyer , Petro , linux-lvm@sistina.com, linux-xfs@oss.sgi.com, mysql@lists.mysql.com Subject: Re: re[2]: [linux-lvm] System Suggestions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 6 Mar 2002, Anthony W. Marino wrote: > > > > If you are looking into using the 3Ware controllers watch the following: > > The 64xx controllers are underpowered and should better not be used in > > raid 5 mode. > > The 74xx controllers seem to be good and should be fine with raid5 but > > note that raid5 will always have slow write speeds. > > > Is there a way to minimize the write penalty using both XFS and LVM with RAID > 5? Don't use raid5. I always use a combination of raid 1 and 10 for a database server. If you have a database that frequently updates records you don't want the extra write overhead. Software raid 1 or 10 will do fine in that case. If you have 4 disks you make 2 raid 1 arrays and then stripe those in a raid 0. You then have optimum speed at the lowest possible overhead. Generally that is what you want for a database server. Cheers Seth From owner-linux-xfs@oss.sgi.com Thu Mar 7 02:53:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27ArE520868 for linux-xfs-outgoing; Thu, 7 Mar 2002 02:53:14 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Ar8920845 for ; Thu, 7 Mar 2002 02:53:09 -0800 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16iuZs-0003O9-00; Thu, 07 Mar 2002 10:52:48 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "jwest@nic.com" Date: Thu, 07 Mar 2002 10:52:48 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2472) For Windows 2000 (5.0.2195;2) In-Reply-To: <3C86F01C.C01BB399@nic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Nillion files NFS/XFS Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 06 Mar 2002 23:44:12 -0500, John W wrote: >There were several choices for 53C875 support. Do these all suffer the >same performance issues for a million >NCR53C7,8XX SCSI Support This is the "original" Linux NCR/Symbios/LSI Logic driver. I would NOT use this, but favor the BSD-ported ones (the following two drivers) or even the new "Version 2" driver: >NCR53C8XXX SCSI Support >SYM53C8XXX SCSI Support The SYM driver is the successor of the NCR driver. Unless your SCSI host is "old" (which I don't assume because you have a 53C875) you should use the latter of the above two. >SYM53C8XXX Version 2 Scsi support This driver is brand-new and supposed to be the successor to the SYM53C8xx driver, so I guess this is the best choice of all the above drivers. Can't comment on performance, tho. -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Thu Mar 7 03:05:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27B5LK21362 for linux-xfs-outgoing; Thu, 7 Mar 2002 03:05:21 -0800 Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27B5H921339 for ; Thu, 7 Mar 2002 03:05:17 -0800 Received: from [216.36.120.213] (HELO there) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 20280462; Thu, 07 Mar 2002 02:01:48 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects.com To: Petro , Theo Van Dinter Subject: Re: [linux-lvm] System Suggestions Date: Thu, 7 Mar 2002 05:04:21 -0500 X-Mailer: KMail [version 1.3.2] Cc: linux-lvm@sistina.com, linux-xfs@oss.sgi.com, mysql@lists.mysql.com References: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> <20020306161130.D855@kluge.net> <20020307034009.GJ32504@auctionwatch.com> In-Reply-To: <20020307034009.GJ32504@auctionwatch.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > We have 10 of the 3ware cards, and while the drive is GPLd and in > the kernel, we have not been satisfied with the stability of the > system Is there anything that I can avoid while still using the card (ie; specific RAID config)? > > We haven't had a chance yet to qual the latest firmware, etc., but > we went with dumb IDE expansion cards (we're only using 4 ide drives > per system) and we're getting better speed (RAID0 or 1+0 depending) > than we were off the 3ware card. > > We are not using XFS, so no comments there. > > We're also having some problems with Mysql that people keep pointing > fingers at LVM for, but at this time we're point right back and > saying "No!" in a firm voice... What kind of problems with MySQL, if you don't mind to summarize? Thank You, Anthony From owner-linux-xfs@oss.sgi.com Thu Mar 7 03:08:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27B8E821547 for linux-xfs-outgoing; Thu, 7 Mar 2002 03:08:14 -0800 Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27B8A921522 for ; Thu, 7 Mar 2002 03:08:10 -0800 Received: from [216.36.120.213] (HELO there) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 21554843; Thu, 07 Mar 2002 02:04:22 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects.com To: Seth Mos Subject: Re: re[2]: [linux-lvm] System Suggestions Date: Thu, 7 Mar 2002 05:07:16 -0500 X-Mailer: KMail [version 1.3.2] Cc: Greg Freemyer , Petro , linux-lvm@sistina.com, linux-xfs@oss.sgi.com, mysql@lists.mysql.com References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thursday 07 March 2002 01:32 am, Seth Mos wrote: > On Wed, 6 Mar 2002, Anthony W. Marino wrote: > > > If you are looking into using the 3Ware controllers watch the > > > following: The 64xx controllers are underpowered and should better not > > > be used in raid 5 mode. > > > The 74xx controllers seem to be good and should be fine with raid5 but > > > note that raid5 will always have slow write speeds. > > > > Is there a way to minimize the write penalty using both XFS and LVM with > > RAID 5? > > Don't use raid5. I always use a combination of raid 1 and 10 for a > database server. If you have a database that frequently updates records > you don't want the extra write overhead. > > Software raid 1 or 10 will do fine in that case. > If you have 4 disks you make 2 raid 1 arrays and then stripe those in a > raid 0. You then have optimum speed at the lowest possible overhead. > > Generally that is what you want for a database server. > > Cheers > Seth I caught a few emails on linux-lvm list where an external log is being used as well to better write performance. Thanks Alot, Anthony From owner-linux-xfs@oss.sgi.com Thu Mar 7 03:23:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27BNcB22069 for linux-xfs-outgoing; Thu, 7 Mar 2002 03:23:38 -0800 Received: from viruswall.behr.de ([194.99.122.195]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27BNS922046 for ; Thu, 7 Mar 2002 03:23:28 -0800 Received: from 172.27.16.1 by viruswall.behr.de (InterScan E-Mail VirusWall NT); Thu, 07 Mar 2002 11:28:19 +0100 Received: from stdoad02.st.behr.de (stdoad02.st.behr.de [172.27.15.12]) by mh1.st.behr.de (8.9.3/8.9.3) with ESMTP id JAA22685; Thu, 7 Mar 2002 09:57:08 +0100 Subject: Antwort: Re: Nillion files NFS/XFS To: "Ralf G. R. Bergs" Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: From: "Andreas Reschke" Date: Thu, 7 Mar 2002 11:16:25 +0100 X-MIMETrack: Serialize by Router on stdoad02/Server/Behr/Behrgroup(Release 5.0.8 |June 18, 2001) at 03/07/2002 11:21:06 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hallo everybody, I'm using the new driver >SYM53C8XXX Version 2 Scsi support< on two different system (server with Redhat 7.2 with xfs) and on my PC (standard Redhat 7.2). It works very good. Best regards Andreas -- BEHR GmbH & Co Andreas Reschke Abteilung G-IMC7 IT-Services Unix/Linux-Administration Siemensstrasse 164 D-70469 Stuttgart Tel. 0711-896-4598 Fax: 0711-8902-4598 Mobil: 0172-6307978 andreas.reschke@behrgroup.com "Ralf G. R. Bergs" An: "linux-xfs@oss.sgi.com" .DE> Thema: Re: Nillion files NFS/XFS Gesendet von: owner-linux-xfs@o ss.sgi.com 07.03.02 10:52 Bitte antworten an "Ralf G. R. Bergs" On Wed, 06 Mar 2002 23:44:12 -0500, John W wrote: >There were several choices for 53C875 support. Do these all suffer the >same performance issues for a million >NCR53C7,8XX SCSI Support This is the "original" Linux NCR/Symbios/LSI Logic driver. I would NOT use this, but favor the BSD-ported ones (the following two drivers) or even the new "Version 2" driver: >NCR53C8XXX SCSI Support >SYM53C8XXX SCSI Support The SYM driver is the successor of the NCR driver. Unless your SCSI host is "old" (which I don't assume because you have a 53C875) you should use the latter of the above two. >SYM53C8XXX Version 2 Scsi support This driver is brand-new and supposed to be the successor to the SYM53C8xx driver, so I guess this is the best choice of all the above drivers. Can't comment on performance, tho. -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Thu Mar 7 03:25:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27BPDt22219 for linux-xfs-outgoing; Thu, 7 Mar 2002 03:25:13 -0800 Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27BPA922197 for ; Thu, 7 Mar 2002 03:25:10 -0800 Received: from [216.36.120.213] (HELO there) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 20281605; Thu, 07 Mar 2002 02:21:42 -0800 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects.com To: Stuart Levy , Petro Subject: Re: [linux-lvm] System Suggestions Date: Thu, 7 Mar 2002 05:24:16 -0500 X-Mailer: KMail [version 1.3.2] Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> <20020306161130.D855@kluge.net> <200203070415.WAA16951@niri.ncsa.uiuc.edu> In-Reply-To: <200203070415.WAA16951@niri.ncsa.uiuc.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 06 March 2002 11:15 pm, Stuart Levy wrote: > wrote: > > We have 10 of the 3ware cards, and while the drive is GPLd and in > > the kernel, we have not been satisfied with the stability of the > > system > > A 3ware 7850 here (8 drive hw RAID5) performed erratically > until I got their latest .016 driver, which seems to be in > the 2.4.18 kernel too. The earlier .010 driver in 2.4.<=17 > would sometimes get into a low-performance (~15MB/sec) mode, > but the .016 driver has been doing very well. 3ware tech support > have been very responsive too. Based on a few weeks' experience, > I'd recommend them. > > Stuart Levy, slevy@ncsa.uiuc.edu Are you, too, using XFS and LVM with your 3Ware/RAID5 config? Thank You! Anthony From owner-linux-xfs@oss.sgi.com Thu Mar 7 04:27:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27CRoU24166 for linux-xfs-outgoing; Thu, 7 Mar 2002 04:27:50 -0800 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27CRe924140 for ; Thu, 7 Mar 2002 04:27:41 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 124B11E59F; Thu, 7 Mar 2002 12:27:34 +0100 (MET) Date: Thu, 7 Mar 2002 12:27:33 +0100 From: Andi Kleen To: Steve Lord Cc: Matthijs van der Klip , Linux XFS Mailing List Subject: Re: status of the 'null' issue Message-ID: <20020307122733.A11548@wotan.suse.de> References: <1015458891.1496.9.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1015458891.1496.9.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 06, 2002 at 05:54:51PM -0600, Steve Lord wrote: > On Wed, 2002-03-06 at 17:48, Matthijs van der Klip wrote: > > Hi, > > > > Could someone tell me what the status of the 'null' issue is?: > > > > http://oss.sgi.com/projects/xfs/faq.html#nulls > > > > > > Has any solution or workaround been developed yet? Can we expect a > > solution in the next official release? > > > > The 2.4.18 kernel in cvs and the patches has some code which removes > the synchronous transactions from xfs. For the most part these tended > to be the culprit in that an inode size update was forced out into > the log long before the data was. > > So, while it is still possible, it is less likely than it was. I guess one can make it even less likely by changing the bdflush buffer timeout to 5 seconds, at the cost of some performance. % cat /proc/sys/vm/bdflush 30 500 0 0 500 3000 60 20 0 % echo 30 500 0 0 500 500 60 20 0 > /proc/sys/vm/bdflush [3000 -> 500] -Andi From owner-linux-xfs@oss.sgi.com Thu Mar 7 06:49:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27EnOL29828 for linux-xfs-outgoing; Thu, 7 Mar 2002 06:49:24 -0800 Received: from mail.fisek.com.tr (fisek2.ada.net.tr [195.112.153.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27EnB929803 for ; Thu, 7 Mar 2002 06:49:13 -0800 Received: (qmail 14987 invoked from network); 7 Mar 2002 13:46:05 -0000 Received: from isdn01047.ada.net.tr (HELO fisek.com.tr) (195.112.138.47) by 195.112.152.33 with SMTP; 7 Mar 2002 13:46:05 -0000 Date: Thu, 7 Mar 2002 15:35:48 +0200 From: Doruk Fisek To: linux-xfs@oss.sgi.com Subject: annoying slowdowns Message-Id: <20020307153548.6a6a0e87.dfisek@fisek.com.tr> Organization: Fisek Enstitusu X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i686-pc-linux-gnu) X-GPG-Key: http://linux.fisek.com.tr/dfisek/dfisek.gpg Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm experiencing real slowdowns in my xfs partition on my laptop. I know there were issues of problems in some laptop harddisks with xfs but couldn't find any details about it, just some talk on mailing lists. My hard disk is a 6 gig ide ibm. The partition is not near full, actually 28% of it is unused. There are a lot of files on the disk, I'm using an e-mail client (Sylpheed) which stores each mail seperately as a file on the disk (mh) and have a not so small message base. Could it be that there are a lot of files and there is some tweaking I can do to increase performance? It's not a fast disk alright but wasn't this slow. I'm using Linux 2.4.17-xfs. Had the same problem with 2.4.14-xfs too. Thanks for all help. Doruk -- FISEK INSTITUTE - http://www.fisek.org From owner-linux-xfs@oss.sgi.com Thu Mar 7 07:39:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27FdvY31119 for linux-xfs-outgoing; Thu, 7 Mar 2002 07:39:57 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Fdo931097 for ; Thu, 7 Mar 2002 07:39:50 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g27Fl9kw027361 for ; Thu, 7 Mar 2002 09:47:09 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA62067 for ; Thu, 7 Mar 2002 08:38:29 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA30744 for ; Thu, 7 Mar 2002 08:38:29 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id IAA55872; Thu, 7 Mar 2002 08:38:29 -0600 (CST) Message-Id: <200203071438.IAA55872@slobber.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: Re: catch mount event Date: Thu, 07 Mar 2002 08:38:28 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "Francis Qu" >Hi there, > >In my DMAPI application, I'd like to catch the mount event of xfs file system. > After init service and create session, I set DM_EVENT_MOUNT and dm_set_disp, >then I dm_get_events. Now the program is waiting for mount event to come. > >When I > >mount -o dmapi -t xfs /dev/xxx /mnt > >and it mounts, but the program doesn't catch the mount event. Are you setting that mount event on the global handle? (DM_GLOBAL_HANP, DM_GLOBAL_HLEN) In cmds/xfstests/dmapi there are dmapi test tools. You can look at src/suite1/cmd/set_disp.c to see how it sets the mount event using the global handle. Using those test tools, I can catch the mount event: # dm_create_session ret=0 newsid=1 # set_disp -s 1 -G DM_EVENT_MOUNT # get_events -f 1 [now do your mount command, and the get_events will return...] rlenp is 128 mount: token=9 sequence=9 fs handle 0998cbba8d08fbb2 mtpt handle mtpt path /mnts/dmi1 media desig ide0(3,12) root handle 0998cbba8d08fbb20e000000000000004000000000000000 mode 0 # respond_event 1 9 1 0 [now the filesystem is mounted] Dean From owner-linux-xfs@oss.sgi.com Thu Mar 7 08:29:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27GTbm01471 for linux-xfs-outgoing; Thu, 7 Mar 2002 08:29:37 -0800 Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27GTW901448 for ; Thu, 7 Mar 2002 08:29:32 -0800 Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8]) by ex1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g27FTVV28884; Thu, 7 Mar 2002 09:29:31 -0600 (CST) Received: from niri.ncsa.uiuc.edu (niri.ncsa.uiuc.edu [141.142.64.68]) by mx1.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id g27FTUB26788; Thu, 7 Mar 2002 09:29:30 -0600 (CST) From: Stuart Levy Received: (from slevy@localhost) by niri.ncsa.uiuc.edu (8.8.5/8.8.5) id JAA18805; Thu, 7 Mar 2002 09:29:30 -0600 (CST) Date: Thu, 7 Mar 2002 09:29:30 -0600 (CST) Message-Id: <200203071529.JAA18805@niri.ncsa.uiuc.edu> To: Petro , "Anthony W. Marino" Subject: Re: [linux-lvm] System Suggestions Cc: linux-lvm@sistina.com, linux-xfs@oss.sgi.com References: <20020306210600.JKKL21197.imf11bis.bellsouth.net@taz> <20020306161130.D855@kluge.net> <200203070415.WAA16951@niri.ncsa.uiuc.edu> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'd written: > A 3ware 7850 here (8 drive hw RAID5) performed erratically > until I got their latest .016 driver, which seems to be in > the 2.4.18 kernel too. The earlier .010 driver in 2.4.<=17 > would sometimes get into a low-performance (~15MB/sec) mode, > but the .016 driver has been doing very well. 3ware tech support > have been very responsive too. Based on a few weeks' experience, > I'd recommend them. > > Stuart Levy, slevy@ncsa.uiuc.edu Anthony Marino asked: > Are you, too, using XFS and LVM with your 3Ware/RAID5 config? XFS yes, LVM no. From owner-linux-xfs@oss.sgi.com Thu Mar 7 09:22:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27HMJn04076 for linux-xfs-outgoing; Thu, 7 Mar 2002 09:22:19 -0800 Received: from web.dragon.cz (root@web.dragon.cz [212.71.160.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27HMA904050 for ; Thu, 7 Mar 2002 09:22:10 -0800 Received: from afd.cz (fw.telekomunikace-mb.cz [212.71.161.89]) by web.dragon.cz with ESMTP id g27GMxxj002192; Thu, 7 Mar 2002 17:22:59 +0100 Message-ID: <3C8793AB.5080309@afd.cz> Date: Thu, 07 Mar 2002 17:22:03 +0100 From: Martin Zabadal Organization: Aufeer Design s.r.o User-Agent: Mozilla/5.0 (X11; U; AIX 0040FD5C4C00; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en, cs MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: PROBLEM: XFS on LVM over NFS (Linux) mounted by AIX X-Priority: 1 (highest) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi experts! I cannot solve the problem with Linux xfs-1.0.2 on LVM on kernel-2.4.14 and higher served per nfs-server to AIX(4.3.3.0) nfs-clients. Compiling with the same .config: 1.) kernel-2.4.2 with xfs-1.0 runs nfs excellent with AIX-clients (except quotas) 2.) kernel-2.4.16 up to 2.4.18 makes use of nfs useless (tranfer rates about 3kB). I get the same bad result with precompiled kernel from SGI: ftp://oss.sgi.com/projects/xfs/download/Release-1.0.2/kernel_rpms/i386/2.4.14/kernel-2.4.14-SGI_XFS_1.0.2.i686.rpm Here my system: SUSE 7.1 /usr/src/linux/scripts # sh ver_linux -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux pc3 2.4.2-XFS #1 Mon Jul 9 19:47:15 CEST 2001 i686 unknown Kernel modules 2.4.2 Gnu C 2.95.2 but kernels compiled with egcs 1.1.2 Gnu Make 3.79.1 Binutils 2.10.0.33 Linux C Library x 1 root root 1382179 Dec 18 16:32 /lib/libc.so.6 Dynamic linker ldd (GNU libc) 2.2 Procps 2.0.7 Mount 2.10q Net-tools 1.57 Kbd 1.02 Sh-utils 2.0 LVM 0.9.4 NFSUTILS 0.2.1-20 Modules Loaded nls_iso8859-1 snd-pcm-oss snd-pcm-plugin snd-mixer-oss ipt_REDIRECT ipt_MASQUERADE iptable_mangle iptable_nat ip_conntrack iptable_filter ip_tables ide-scsi sr_mod sg scsi_mod parport_pc lp parport ipv6 snd-seq-midi snd-seq-midi-event snd-seq snd-card-via686a snd-pcm snd-timer snd-ac97-codec snd-mixer snd-mpu401-uart snd-rawmidi snd-seq-device snd soundcore 3c59x Please help ! -- Martin Zabadal http://www.aufeerdesign.cz From owner-linux-xfs@oss.sgi.com Thu Mar 7 12:42:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27KgB916223 for linux-xfs-outgoing; Thu, 7 Mar 2002 12:42:11 -0800 Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Kg9916201 for ; Thu, 7 Mar 2002 12:42:09 -0800 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Mar 2002 14:42:03 -0500 Message-ID: From: Murthy Kambhampaty To: linux-xfs@oss.sgi.com Subject: Does XFS on hardware RAID5 have perfomance issues? Date: Thu, 7 Mar 2002 14:42:00 -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 I was reviewing the Linux-XFS FAQ to see if I can improve performance with XFS on hardware RAID5 (Mylex Acceleraid352 and five IBM Ultrastar 36LZX drives) by using an external log. The FAQ state the problem as if it is limited to software RAID5. Is hardware RAID5 performance similar whether the log is internal or external? Thanks, Murthy From owner-linux-xfs@oss.sgi.com Thu Mar 7 12:48:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27Kmoi16500 for linux-xfs-outgoing; Thu, 7 Mar 2002 12:48:50 -0800 Received: from eclectic.kluge.net (IDENT:iDjn2i/d76KG0PtSfa7Bn0Reshjkqj3N@dsl092-071-242.bos1.dsl.speakeasy.net [66.92.71.242]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Kmk916478 for ; Thu, 7 Mar 2002 12:48:46 -0800 Received: (from felicity@localhost) by eclectic.kluge.net (8.11.6/8.11.6) id g27Jmiq08632; Thu, 7 Mar 2002 14:48:44 -0500 Date: Thu, 7 Mar 2002 14:48:44 -0500 From: Theo Van Dinter To: Murthy Kambhampaty Cc: linux-xfs@oss.sgi.com Subject: Re: Does XFS on hardware RAID5 have perfomance issues? Message-ID: <20020307144844.B6553@kluge.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Murthy.Kambhampaty@goeci.com on Thu, Mar 07, 2002 at 02:42:00PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 07, 2002 at 02:42:00PM -0500, Murthy Kambhampaty wrote: > I was reviewing the Linux-XFS FAQ to see if I can improve performance with > XFS on hardware RAID5 (Mylex Acceleraid352 and five IBM Ultrastar 36LZX > drives) by using an external log. The FAQ state the problem as if it is > limited to software RAID5. Is hardware RAID5 performance similar whether the > log is internal or external? http://oss.sgi.com/projects/xfs/mail_archive/0202/msg00329.html The issue seems to be related to the way Linux software RAID handles stripe caching. The hardware RAID controller will likely not have the same issue. -- Randomly Generated Tagline: "It's because I was young. When you're young, you're supposed to do stupid things, aren't you?" - David Bishop of Kodak From owner-linux-xfs@oss.sgi.com Thu Mar 7 12:50:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27Kop616670 for linux-xfs-outgoing; Thu, 7 Mar 2002 12:50:51 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Kok916644 for ; Thu, 7 Mar 2002 12:50:46 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g27JofbX006374 for ; Thu, 7 Mar 2002 11:50:41 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA54694; Thu, 7 Mar 2002 13:49:25 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA63709; Thu, 7 Mar 2002 13:49:25 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g27JnGe12913; Thu, 7 Mar 2002 13:49:16 -0600 Subject: Re: Does XFS on hardware RAID5 have perfomance issues? From: Steve Lord To: Murthy Kambhampaty Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Mar 2002 13:49:15 -0600 Message-Id: <1015530555.10642.401.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-03-07 at 13:42, Murthy Kambhampaty wrote: > I was reviewing the Linux-XFS FAQ to see if I can improve performance with > XFS on hardware RAID5 (Mylex Acceleraid352 and five IBM Ultrastar 36LZX > drives) by using an external log. The FAQ state the problem as if it is > limited to software RAID5. Is hardware RAID5 performance similar whether the > log is internal or external? > > Thanks, > Murthy It should be. Simon Matter has done experiments with external logs on software raid 5 and said it does not matter if the external log it on the same spindles or not. The issue with the internal log with software raid5 is that the alignment (or lack thereof) of the logwrites causes invalidation of the internal cache in the raid code which is used for parity generation. So I do not think it should matter. Let me guess, you do not like the performance you are getting right now. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Mar 7 13:20:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27LKfr17736 for linux-xfs-outgoing; Thu, 7 Mar 2002 13:20:41 -0800 Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27LKb917713 for ; Thu, 7 Mar 2002 13:20:37 -0800 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Mar 2002 15:20:32 -0500 Message-ID: From: Murthy Kambhampaty To: "'Steve Lord'" Cc: linux-xfs@oss.sgi.com Subject: RE: Does XFS on hardware RAID5 have perfomance issues? Date: Thu, 7 Mar 2002 15:20:31 -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 > From: Steve Lord [mailto:lord@sgi.com] > Sent: Thursday, March 07, 2002 14:49 ... > Subject: Re: Does XFS on hardware RAID5 have perfomance issues? ... > So I do not think it should matter. Let me guess, you do not like the > performance you are getting right now. We have a SuperMicro S2QR6 motherboard with four PIII Xeon 500 MHz/2Mb cache and 4gb RAM (call it comp1). I get kernel compile times that are thrice as long as on a dual PIII 550 Mhz Katmai processor with 256 MB of RAM (call it comp2); importing a file into MySQL seems to take almost 50% longer on comp1 than on comp2. So, I'm chasing down all the bottlenecks and trying to eliminate them. I thought the 2.4 kernel scaled well to sixteen processors, and there is no indication that the highmem configuration slows the kernel down this much, but I might have to get on the kernel mailing list with this. Thanks for the response to my original question, Murthy From owner-linux-xfs@oss.sgi.com Thu Mar 7 13:23:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27LNJS17930 for linux-xfs-outgoing; Thu, 7 Mar 2002 13:23:19 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27LNE917907 for ; Thu, 7 Mar 2002 13:23:14 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g27KN9bX007808 for ; Thu, 7 Mar 2002 12:23:09 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA41023; Thu, 7 Mar 2002 14:21:54 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA69006; Thu, 7 Mar 2002 14:21:54 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g27KLiO16051; Thu, 7 Mar 2002 14:21:44 -0600 Subject: RE: Does XFS on hardware RAID5 have perfomance issues? From: Steve Lord To: Murthy Kambhampaty Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Mar 2002 14:21:44 -0600 Message-Id: <1015532504.15734.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-03-07 at 14:20, Murthy Kambhampaty wrote: > > From: Steve Lord [mailto:lord@sgi.com] > > Sent: Thursday, March 07, 2002 14:49 > ... > > Subject: Re: Does XFS on hardware RAID5 have perfomance issues? > ... > > So I do not think it should matter. Let me guess, you do not like the > > performance you are getting right now. > > We have a SuperMicro S2QR6 motherboard with four PIII Xeon 500 MHz/2Mb cache > and 4gb RAM (call it comp1). I get kernel compile times that are thrice as > long as on a dual PIII 550 Mhz Katmai processor with 256 MB of RAM (call it > comp2); importing a file into MySQL seems to take almost 50% longer on comp1 > than on comp2. So, I'm chasing down all the bottlenecks and trying to > eliminate them. I thought the 2.4 kernel scaled well to sixteen processors, > and there is no indication that the highmem configuration slows the kernel > down this much, but I might have to get on the kernel mailing list with > this. > > Thanks for the response to my original question, > Murthy Is the disk setup the same in both - raid5 does have a cost. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Mar 7 14:04:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27M45E19373 for linux-xfs-outgoing; Thu, 7 Mar 2002 14:04:05 -0800 Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27M3t919342 for ; Thu, 7 Mar 2002 14:03:55 -0800 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Mar 2002 16:03:49 -0500 Message-ID: From: Murthy Kambhampaty To: "'Steve Lord'" Cc: linux-xfs@oss.sgi.com Subject: RE: Does XFS on hardware RAID5 have perfomance issues? Date: Thu, 7 Mar 2002 16:03:48 -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 > -----Original Message----- > From: > Sent: Thursday, March 07, 2002 15:22 > To: Murthy Kambhampaty > Cc: linux-xfs@oss.sgi.com > Subject: RE: Does XFS on hardware RAID5 have perfomance issues? > > > On Thu, 2002-03-07 at 14:20, Murthy Kambhampaty wrote: > > > From: Steve Lord [mailto:lord@sgi.com] > > > Sent: Thursday, March 07, 2002 14:49 > > ... > > > Subject: Re: Does XFS on hardware RAID5 have perfomance issues? > > ... > > > So I do not think it should matter. Let me guess, you do > not like the > > > performance you are getting right now. > > > > We have a SuperMicro S2QR6 motherboard with four PIII Xeon > 500 MHz/2Mb cache > > and 4gb RAM (call it comp1). I get kernel compile times > that are thrice as > > long as on a dual PIII 550 Mhz Katmai processor with 256 MB > of RAM (call it > > comp2); importing a file into MySQL seems to take almost > 50% longer on comp1 > > than on comp2. So, I'm chasing down all the bottlenecks and > trying to > > eliminate them. I thought the 2.4 kernel scaled well to > sixteen processors, > > and there is no indication that the highmem configuration > slows the kernel > > down this much, but I might have to get on the kernel > mailing list with > > this. > > > > Thanks for the response to my original question, > > Murthy > > Is the disk setup the same in both - raid5 does have a cost. > The better comparison in this regard is to the backup database server, which is a dual PIII Xeon 500 MHz/1MB cache (Dell WS620), with hardware RAID5 on a 3ware 7850 controller, with 2 Gb or RAM. I find that kernel compile time and MySQL import are faster on the dual-proc. mach. than on the quad-proc. mach. Of course, the quad-proc. server has the benefit of being able to support many disks, therefore giving the capacity we need. But it is getting a little uncomfortable that a DP machine with IDE raid is far faster than the quad-processor SCSI raid box. Thanks, Murthy From owner-linux-xfs@oss.sgi.com Thu Mar 7 14:32:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27MWNG20384 for linux-xfs-outgoing; Thu, 7 Mar 2002 14:32:23 -0800 Received: from mail.aem.umn.edu (mail.aem.umn.edu [128.101.142.239]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27MWF920360 for ; Thu, 7 Mar 2002 14:32:16 -0800 Received: from lightning.aem.umn.edu (lightning.aem.umn.edu [128.101.143.49]) by mail.aem.umn.edu (8.11.3/8.11.3) with ESMTP id g27LcuU01556; Thu, 7 Mar 2002 15:38:56 -0600 (CST) (envelope-from muno@aem.umn.edu) Received: (from muno@localhost) by lightning.aem.umn.edu (8.11.6/8.9.1) id g27LY2f08555; Thu, 7 Mar 2002 15:34:02 -0600 Date: Thu, 7 Mar 2002 15:34:02 -0600 From: Ray Muno To: Murthy Kambhampaty Cc: "'Steve Lord'" , linux-xfs@oss.sgi.com Subject: Re: Does XFS on hardware RAID5 have perfomance issues? Message-ID: <20020307153401.B7904@aem.umn.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19-current-20010622i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I did a quick test of a kernel compile. Supermicro 6040 (370DE6) motherboard 2 x 1GHz PIII CPU 1 GB RAM Dual onboard Adaptec aic7899, Quantum Atlas 10K Adaptec 3200 Raid controller, RAID 5, 8 x Seagate 75 MB Cheetah I did a kernel compile on the boot disk, XFS non-RAID and on the RAID volume with an XFS filsystem. Compile times were almost identical, 64min,46sec vs. 6min,48sec. Kernel, 2.4.3-SGI_XFS_1.0.1smp On Thu, Mar 07, 2002 at 03:20:31PM -0500, Murthy Kambhampaty wrote: > > From: Steve Lord [mailto:lord@sgi.com] > > Sent: Thursday, March 07, 2002 14:49 > ... > > Subject: Re: Does XFS on hardware RAID5 have perfomance issues? > ... > > So I do not think it should matter. Let me guess, you do not like the > > performance you are getting right now. > > We have a SuperMicro S2QR6 motherboard with four PIII Xeon 500 MHz/2Mb cache > and 4gb RAM (call it comp1). I get kernel compile times that are thrice as > long as on a dual PIII 550 Mhz Katmai processor with 256 MB of RAM (call it > comp2); importing a file into MySQL seems to take almost 50% longer on comp1 > than on comp2. So, I'm chasing down all the bottlenecks and trying to > eliminate them. I thought the 2.4 kernel scaled well to sixteen processors, > and there is no indication that the highmem configuration slows the kernel > down this much, but I might have to get on the kernel mailing list with > this. > > Thanks for the response to my original question, > Murthy ============================================================================= Ray Muno http://www.aem.umn.edu/people/staff/muno University of Minnesota e-mail: muno@aem.umn.edu Aerospace Engineering and Mechanics Phone: (612) 625-9531 110 Union St. S.E. FAX: (612) 626-1558 Minneapolis, Mn 55455 ============================================================================= From owner-linux-xfs@oss.sgi.com Thu Mar 7 14:35:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27MZqk20582 for linux-xfs-outgoing; Thu, 7 Mar 2002 14:35:52 -0800 Received: from moria.linuxis.net (moria.linuxis.net [64.71.162.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27MZn920560 for ; Thu, 7 Mar 2002 14:35:49 -0800 Received: (qmail 22806 invoked by uid 1000); 7 Mar 2002 21:28:30 -0000 Date: Thu, 7 Mar 2002 13:28:30 -0800 To: linux-xfs@oss.sgi.com Subject: Re: Does XFS on hardware RAID5 have perfomance issues? Message-ID: <20020307212830.GX17914@flounder.net> References: <20020307153401.B7904@aem.umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020307153401.B7904@aem.umn.edu> User-Agent: Mutt/1.3.27i From: "Adam McKenna" Mail-Followup-To: linux-xfs@oss.sgi.com X-Delivery-Agent: TMDA/0.44 (Python 2.1.2; linux2) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 07, 2002 at 03:34:02PM -0600, Ray Muno wrote: > I did a quick test of a kernel compile. How is a kernel compile a test of disk performance? Kernel compiles are generally CPU-bound, not I/O-bound. Why don't you test it with a disk benchmarking tool? As far as your kernel compiles, on a 4-CPU system, make -j4 will most likely speed things up considerably. --Adam From owner-linux-xfs@oss.sgi.com Thu Mar 7 14:36:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27MaVQ20725 for linux-xfs-outgoing; Thu, 7 Mar 2002 14:36:31 -0800 Received: from vortex.xnote.com ([65.105.237.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27MaR920702 for ; Thu, 7 Mar 2002 14:36:27 -0800 Received: from [10.1.17.192] (slccheck01.firsthealth.com [209.180.88.28]) by vortex.xnote.com (8.11.0/8.8.7) with ESMTP id g27LaTF22329; Thu, 7 Mar 2002 14:36:29 -0700 Subject: Re: Does XFS on hardware RAID5 have perfomance issues? From: Vernon McPherron To: linux-xfs@oss.sgi.com Cc: Ray Muno In-Reply-To: <20020307153401.B7904@aem.umn.edu> References: <20020307153401.B7904@aem.umn.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Mar 2002 14:34:13 -0700 Message-Id: <1015536859.1311.8.camel@oreo.typeset.net> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-03-07 at 14:34, Ray Muno wrote: > I did a quick test of a kernel compile. > > Supermicro 6040 (370DE6) motherboard > 2 x 1GHz PIII CPU > 1 GB RAM > Dual onboard Adaptec aic7899, Quantum Atlas 10K > Adaptec 3200 Raid controller, RAID 5, 8 x Seagate 75 MB Cheetah > > I did a kernel compile on the boot disk, XFS non-RAID and on the > RAID volume with an XFS filsystem. Compile times were almost identical, > 64min,46sec vs. 6min,48sec. > almost identical? Just 58 minutes off? :-) I'll guess you meant 6 minutes 46 seconds vs. 6 minutes 48 seconds? -- -=/Vernon McPherron/=- From owner-linux-xfs@oss.sgi.com Thu Mar 7 14:40:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27MeOQ20987 for linux-xfs-outgoing; Thu, 7 Mar 2002 14:40:24 -0800 Received: from mail.aem.umn.edu (mail.aem.umn.edu [128.101.142.239]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27MeE920961 for ; Thu, 7 Mar 2002 14:40:17 -0800 Received: from lightning.aem.umn.edu (lightning.aem.umn.edu [128.101.143.49]) by mail.aem.umn.edu (8.11.3/8.11.3) with ESMTP id g27Ll1U01661; Thu, 7 Mar 2002 15:47:01 -0600 (CST) (envelope-from muno@aem.umn.edu) Received: (from muno@localhost) by lightning.aem.umn.edu (8.11.6/8.9.1) id g27Lg7l08612; Thu, 7 Mar 2002 15:42:07 -0600 Date: Thu, 7 Mar 2002 15:42:07 -0600 From: Ray Muno To: Vernon McPherron Cc: linux-xfs@oss.sgi.com Subject: Re: Does XFS on hardware RAID5 have perfomance issues? Message-ID: <20020307154206.D7904@aem.umn.edu> References: <20020307153401.B7904@aem.umn.edu> <1015536859.1311.8.camel@oreo.typeset.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1015536859.1311.8.camel@oreo.typeset.net> User-Agent: Mutt/1.3.19-current-20010622i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes, stray 4 when I typed it. 6min,46sec vs. 6min,48sec On Thu, Mar 07, 2002 at 02:34:13PM -0700, Vernon McPherron wrote: > On Thu, 2002-03-07 at 14:34, Ray Muno wrote: > > I did a quick test of a kernel compile. > > > > Supermicro 6040 (370DE6) motherboard > > 2 x 1GHz PIII CPU > > 1 GB RAM > > Dual onboard Adaptec aic7899, Quantum Atlas 10K > > Adaptec 3200 Raid controller, RAID 5, 8 x Seagate 75 MB Cheetah > > > > I did a kernel compile on the boot disk, XFS non-RAID and on the > > RAID volume with an XFS filsystem. Compile times were almost identical, > > 64min,46sec vs. 6min,48sec. > > > > almost identical? Just 58 minutes off? :-) > > I'll guess you meant 6 minutes 46 seconds vs. 6 minutes 48 seconds? > -- > > > -=/Vernon McPherron/=- ============================================================================= Ray Muno http://www.aem.umn.edu/people/staff/muno University of Minnesota e-mail: muno@aem.umn.edu Aerospace Engineering and Mechanics Phone: (612) 625-9531 110 Union St. S.E. FAX: (612) 626-1558 Minneapolis, Mn 55455 ============================================================================= From owner-linux-xfs@oss.sgi.com Thu Mar 7 14:48:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g27MmrW21374 for linux-xfs-outgoing; Thu, 7 Mar 2002 14:48:53 -0800 Received: from mail.aem.umn.edu (mail.aem.umn.edu [128.101.142.239]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g27Mmd921348 for ; Thu, 7 Mar 2002 14:48:47 -0800 Received: from lightning.aem.umn.edu (lightning.aem.umn.edu [128.101.143.49]) by mail.aem.umn.edu (8.11.3/8.11.3) with ESMTP id g27LtPU01810; Thu, 7 Mar 2002 15:55:25 -0600 (CST) (envelope-from muno@aem.umn.edu) Received: (from muno@localhost) by lightning.aem.umn.edu (8.11.6/8.9.1) id g27LoVH08738; Thu, 7 Mar 2002 15:50:31 -0600 Date: Thu, 7 Mar 2002 15:50:31 -0600 From: Ray Muno To: Adam McKenna Cc: linux-xfs@oss.sgi.com Subject: Re: Does XFS on hardware RAID5 have perfomance issues? Message-ID: <20020307155030.E7904@aem.umn.edu> References: <20020307153401.B7904@aem.umn.edu> <20020307212830.GX17914@flounder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020307212830.GX17914@flounder.net> User-Agent: Mutt/1.3.19-current-20010622i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am not using it as a benchmark. This is just in followup to the person who posted that they observed kernel compile times that seemed to be extremely long on a machine with RAID and XFS. I offered this as a comparison running on a machine that has both RAID and non-RAID filesystems and it shows no difference at all. On Thu, Mar 07, 2002 at 01:28:30PM -0800, Adam McKenna wrote: > On Thu, Mar 07, 2002 at 03:34:02PM -0600, Ray Muno wrote: > > I did a quick test of a kernel compile. > > How is a kernel compile a test of disk performance? Kernel compiles are > generally CPU-bound, not I/O-bound. > > Why don't you test it with a disk benchmarking tool? > > As far as your kernel compiles, on a 4-CPU system, make -j4 will most likely > speed things up considerably. > > --Adam ============================================================================= Ray Muno http://www.aem.umn.edu/people/staff/muno University of Minnesota e-mail: muno@aem.umn.edu Aerospace Engineering and Mechanics Phone: (612) 625-9531 110 Union St. S.E. FAX: (612) 626-1558 Minneapolis, Mn 55455 ============================================================================= From owner-linux-xfs@oss.sgi.com Thu Mar 7 16:26:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g280QaX27207 for linux-xfs-outgoing; Thu, 7 Mar 2002 16:26:36 -0800 Received: from joines.okstate.edu (joines.bus.okstate.edu [139.78.89.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g280QY927185 for ; Thu, 7 Mar 2002 16:26:34 -0800 Received: from localhost (localhost [[UNIX: localhost]]) by joines.okstate.edu (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id g27NQLa28521 for linux-xfs@oss.sgi.com; Thu, 7 Mar 2002 17:26:21 -0600 Content-Type: text/plain; charset="us-ascii" From: Jason Joines To: linux-xfs@oss.sgi.com Subject: xfs_copy Date: Thu, 7 Mar 2002 17:26:21 -0600 X-Mailer: KMail [version 1.3.9] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200203071726.21801.joines@joines.okstate.edu> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Where do you get xfs_copy? I've installed several different versions of xfsdump, xfsprogs, etc., but none of them have had xfs_copy. Jason Joines ----------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Mar 7 16:29:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g280TMZ27652 for linux-xfs-outgoing; Thu, 7 Mar 2002 16:29:22 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g280TF927628 for ; Thu, 7 Mar 2002 16:29:16 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g27NQPh05874; Thu, 7 Mar 2002 17:26:25 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Serveral weid errors on sys_sparc32.c From: Alvaro Figueroa To: XFS to linux port mailing list Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 07 Mar 2002 17:26:24 -0600 Message-Id: <1015543584.5649.2.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk While compiling the CVS XFS kernel, I get make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/arch/sparc64/kernel' sparc64-linux-gcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs -DKBUILD_BASENAME=sys_sparc32 -c -o sys_sparc32.o sys_sparc32.c sys_sparc32.c: In function `sys32_quotactl': sys_sparc32.c:908: storage size of `d' isn't known sys_sparc32.c:916: `Q_SETUSE' undeclared (first use in this function) sys_sparc32.c:916: (Each undeclared identifier is reported only once sys_sparc32.c:916: for each function it appears in.) sys_sparc32.c:917: `Q_SETQLIM' undeclared (first use in this function) sys_sparc32.c:908: warning: unused variable `d' make[1]: *** [sys_sparc32.o] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/arch/sparc64/kernel' make: *** [_dir_arch/sparc64/kernel] Error 2 I know that this is a platform specific thing, but I've tried to compile stock 2.4.18 and 2.4.19-pre1 (which had a bit of code changed in this file) and it doesn't dives me this error. The XFS CVS kernel, is what? A 2.4.18-rc4 with XFS adds ons right? Does any one recognices any XFS code that could be responsible of this error? Any ideas? -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Thu Mar 7 16:33:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g280XOn27951 for linux-xfs-outgoing; Thu, 7 Mar 2002 16:33:24 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g280XJ927927 for ; Thu, 7 Mar 2002 16:33:20 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g27NXDbX021898 for ; Thu, 7 Mar 2002 15:33:14 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA55309; Thu, 7 Mar 2002 17:31:57 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA20416; Thu, 7 Mar 2002 17:31:57 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g27NVkH05164; Thu, 7 Mar 2002 17:31:46 -0600 Subject: Re: xfs_copy From: Steve Lord To: Jason Joines Cc: linux-xfs@oss.sgi.com In-Reply-To: <200203071726.21801.joines@joines.okstate.edu> References: <200203071726.21801.joines@joines.okstate.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Mar 2002 17:31:46 -0600 Message-Id: <1015543906.1280.9.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-03-07 at 17:26, Jason Joines wrote: > Where do you get xfs_copy? I've installed several different > versions of xfsdump, xfsprogs, etc., but none of them have had > xfs_copy. It has not been ported - care to take a crack at it? It uses thread primitives which are irix specific. Steve > > Jason Joines > ----------------------------------------------------- -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Mar 7 16:33:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g280XZc27996 for linux-xfs-outgoing; Thu, 7 Mar 2002 16:33:35 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g280XV927972 for ; Thu, 7 Mar 2002 16:33:31 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g27NXPbX021904 for ; Thu, 7 Mar 2002 15:33:26 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA58509; Thu, 7 Mar 2002 17:32:10 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA83661; Thu, 7 Mar 2002 17:32:09 -0600 (CST) Subject: Re: xfs_copy From: Eric Sandeen To: Jason Joines Cc: linux-xfs@oss.sgi.com In-Reply-To: <200203071726.21801.joines@joines.okstate.edu> References: <200203071726.21801.joines@joines.okstate.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Mar 2002 17:32:09 -0600 Message-Id: <1015543929.23850.22.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It's not available for Linux - if I understand correctly, it uses Irix threading that has no Linux counterpart. We just ship the man page so you can see what you're missing, apparently. ;-) -Eric On Thu, 2002-03-07 at 17:26, Jason Joines wrote: > Where do you get xfs_copy? I've installed several different > versions of xfsdump, xfsprogs, etc., but none of them have had > xfs_copy. > > Jason Joines > ----------------------------------------------------- -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Mar 7 16:37:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g280bC329438 for linux-xfs-outgoing; Thu, 7 Mar 2002 16:37:12 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g280b5929412 for ; Thu, 7 Mar 2002 16:37:05 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g27NawbX022042 for ; Thu, 7 Mar 2002 15:36:59 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA58574; Thu, 7 Mar 2002 17:35:43 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA51649; Thu, 7 Mar 2002 17:35:43 -0600 (CST) Subject: Re: Serveral weid errors on sys_sparc32.c From: Eric Sandeen To: Alvaro Figueroa Cc: XFS to linux port mailing list In-Reply-To: <1015543584.5649.2.camel@lucy> References: <1015543584.5649.2.camel@lucy> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Mar 2002 17:35:43 -0600 Message-Id: <1015544143.23850.25.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You might need to #include in sys_sparc32.c? Just a guess.... -Eric On Thu, 2002-03-07 at 17:26, Alvaro Figueroa wrote: > While compiling the CVS XFS kernel, I get > > make[1]: Entering directory > `/usr/src/linux-2.4-xfs/linux/arch/sparc64/kernel' > sparc64-linux-gcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include > -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing > -fno-common -fomit-frame-pointer -m64 -pipe -mno-fpu -mcpu=ultrasparc > -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 > -Wno-sign-compare -Wa,--undeclared-regs -DKBUILD_BASENAME=sys_sparc32 > -c -o sys_sparc32.o sys_sparc32.c > sys_sparc32.c: In function `sys32_quotactl': > sys_sparc32.c:908: storage size of `d' isn't known > sys_sparc32.c:916: `Q_SETUSE' undeclared (first use in this function) > sys_sparc32.c:916: (Each undeclared identifier is reported only once > sys_sparc32.c:916: for each function it appears in.) > sys_sparc32.c:917: `Q_SETQLIM' undeclared (first use in this function) > sys_sparc32.c:908: warning: unused variable `d' > make[1]: *** [sys_sparc32.o] Error 1 > make[1]: Leaving directory > `/usr/src/linux-2.4-xfs/linux/arch/sparc64/kernel' > make: *** [_dir_arch/sparc64/kernel] Error 2 > > > I know that this is a platform specific thing, but I've tried to compile > stock 2.4.18 and 2.4.19-pre1 (which had a bit of code changed in this > file) and it doesn't dives me this error. > > The XFS CVS kernel, is what? A 2.4.18-rc4 with XFS adds ons right? Does > any one recognices any XFS code that could be responsible of this error? > > Any ideas? > > -- > Alvaro Figueroa -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Mar 7 16:40:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g280eJO31746 for linux-xfs-outgoing; Thu, 7 Mar 2002 16:40:19 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g280eF931723 for ; Thu, 7 Mar 2002 16:40:15 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g27Ne9bX022150 for ; Thu, 7 Mar 2002 15:40:09 -0800 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 KAA16613; Fri, 8 Mar 2002 10:38:53 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA27848; Fri, 8 Mar 2002 10:38:52 +1100 (AEDT) Date: Fri, 8 Mar 2002 10:38:52 +1100 From: Nathan Scott To: Jason Joines Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_copy Message-ID: <20020308103852.E24252@wobbly.melbourne.sgi.com> References: <200203071726.21801.joines@joines.okstate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200203071726.21801.joines@joines.okstate.edu>; from joines@joines.bus.okstate.edu on Thu, Mar 07, 2002 at 05:26:21PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 07, 2002 at 05:26:21PM -0600, Jason Joines wrote: > Where do you get xfs_copy? I've installed several different > versions of xfsdump, xfsprogs, etc., but none of them have had > xfs_copy. > > Jason Joines > ----------------------------------------------------- > hello, xfs_copy has not been fully ported to Linux - you can find the source code in cmd/xfsdump/copy (in the CVS tree). It still requires some code to be written which basically emulates (or replaces) the IRIX locking code. Same is true for xfsdump and multiple streams (currently only one stream is possible in the Linux version of xfsdump, for the same reason). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 7 16:45:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g280j8W32480 for linux-xfs-outgoing; Thu, 7 Mar 2002 16:45:08 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g280j5932455 for ; Thu, 7 Mar 2002 16:45:05 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g280iwBA024257 for ; Thu, 7 Mar 2002 16:44:59 -0800 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 KAA16638; Fri, 8 Mar 2002 10:43:41 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA27890; Fri, 8 Mar 2002 10:43:40 +1100 (AEDT) Date: Fri, 8 Mar 2002 10:43:40 +1100 From: Nathan Scott To: Eric Sandeen Cc: Jason Joines , linux-xfs@oss.sgi.com Subject: Re: xfs_copy Message-ID: <20020308104340.F24252@wobbly.melbourne.sgi.com> References: <200203071726.21801.joines@joines.okstate.edu> <1015543929.23850.22.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1015543929.23850.22.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Thu, Mar 07, 2002 at 05:32:09PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 07, 2002 at 05:32:09PM -0600, Eric Sandeen wrote: > It's not available for Linux - if I understand correctly, it uses Irix > threading that has no Linux counterpart. There are rumours of a library which provides the IRIX locking primitives (on top of pthreads I believe) having been done by the Performer guys, but I never saw any source & I'm not sure where to find it, if it exists. > We just ship the man page so you can see what you're missing, > apparently. ;-) No, not for a long time (once upon a time we did that) - the man page is in with the source now, and is not installed. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 7 16:45:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g280jVr32597 for linux-xfs-outgoing; Thu, 7 Mar 2002 16:45:31 -0800 Received: from moria.linuxis.net (moria.linuxis.net [64.71.162.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g280jT932574 for ; Thu, 7 Mar 2002 16:45:29 -0800 Received: (qmail 23891 invoked by uid 1000); 7 Mar 2002 23:38:09 -0000 Date: Thu, 7 Mar 2002 15:38:09 -0800 To: linux-xfs@oss.sgi.com Subject: Re: Does XFS on hardware RAID5 have perfomance issues? Message-ID: <20020307233809.GE17914@flounder.net> References: <20020307153401.B7904@aem.umn.edu> <20020307212830.GX17914@flounder.net> <20020307155030.E7904@aem.umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020307155030.E7904@aem.umn.edu> User-Agent: Mutt/1.3.27i From: "Adam McKenna" Mail-Followup-To: linux-xfs@oss.sgi.com X-Delivery-Agent: TMDA/0.44 (Python 2.1.2; linux2) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 07, 2002 at 03:50:31PM -0600, Ray Muno wrote: > I am not using it as a benchmark. This is just in followup to the person > who posted that they observed kernel compile times that seemed to be > extremely long on a machine with RAID and XFS. Yes, I noticed after you sent it that you weren't the original poster. Sorry about that. But still, kernel compile time is a pretty poor gauge for measuring filesystem performance. --Adam From owner-linux-xfs@oss.sgi.com Thu Mar 7 16:58:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g280w2H01584 for linux-xfs-outgoing; Thu, 7 Mar 2002 16:58:02 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g280vs901558 for ; Thu, 7 Mar 2002 16:57:54 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g2815Dkw002251 for ; Thu, 7 Mar 2002 19:05:14 -0600 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 KAA16696; Fri, 8 Mar 2002 10:56:28 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA27904; Fri, 8 Mar 2002 10:56:27 +1100 (AEDT) Date: Fri, 8 Mar 2002 10:56:27 +1100 From: Nathan Scott To: Jan Kara , Alvaro Figueroa Cc: linux-xfs@oss.sgi.com Subject: Re: Serveral weid errors on sys_sparc32.c Message-ID: <20020308105627.G24252@wobbly.melbourne.sgi.com> References: <1015543584.5649.2.camel@lucy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1015543584.5649.2.camel@lucy>; from fede2@fuerzag.ulatina.ac.cr on Thu, Mar 07, 2002 at 05:26:24PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Jan, We got this build problem (on Sparc64) with new VFS quota reported - we no longer seem to define these, I guess the platform-specific quotactl compatibility code needs some work still? Alvaro, On Thu, Mar 07, 2002 at 05:26:24PM -0600, Alvaro Figueroa wrote: > While compiling the CVS XFS kernel, I get > > make[1]: Entering directory > `/usr/src/linux-2.4-xfs/linux/arch/sparc64/kernel' > sparc64-linux-gcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include > -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing > -fno-common -fomit-frame-pointer -m64 -pipe -mno-fpu -mcpu=ultrasparc > -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 > -Wno-sign-compare -Wa,--undeclared-regs -DKBUILD_BASENAME=sys_sparc32 > -c -o sys_sparc32.o sys_sparc32.c > sys_sparc32.c: In function `sys32_quotactl': > sys_sparc32.c:908: storage size of `d' isn't known > sys_sparc32.c:916: `Q_SETUSE' undeclared (first use in this function) > sys_sparc32.c:916: (Each undeclared identifier is reported only once > sys_sparc32.c:916: for each function it appears in.) > sys_sparc32.c:917: `Q_SETQLIM' undeclared (first use in this function) > sys_sparc32.c:908: warning: unused variable `d' > make[1]: *** [sys_sparc32.o] Error 1 > make[1]: Leaving directory > `/usr/src/linux-2.4-xfs/linux/arch/sparc64/kernel' > make: *** [_dir_arch/sparc64/kernel] Error 2 > > > I know that this is a platform specific thing, but I've tried to compile > stock 2.4.18 and 2.4.19-pre1 (which had a bit of code changed in this > file) and it doesn't dives me this error. > > The XFS CVS kernel, is what? A 2.4.18-rc4 with XFS adds ons right? Does No, not quite. We have Jan Kara's latest and greatest VFS quota patches in there too nowadays (among other things, like kdb..), see: ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/ > any one recognices any XFS code that could be responsible of this error? > cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 7 16:58:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g280whO01723 for linux-xfs-outgoing; Thu, 7 Mar 2002 16:58:43 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g280we901698 for ; Thu, 7 Mar 2002 16:58:40 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g27Ntpo05901; Thu, 7 Mar 2002 17:55:51 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Re: Serveral weid errors on sys_sparc32.c From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: <1015544143.23850.25.camel@stout.americas.sgi.com> References: <1015543584.5649.2.camel@lucy> <1015544143.23850.25.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 07 Mar 2002 17:55:51 -0600 Message-Id: <1015545351.5649.4.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > You might need to #include in sys_sparc32.c? It is inclueded. -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Thu Mar 7 17:05:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2815IJ02205 for linux-xfs-outgoing; Thu, 7 Mar 2002 17:05:18 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2815F902182 for ; Thu, 7 Mar 2002 17:05:15 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g2802Q405913; Thu, 7 Mar 2002 18:02:26 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Re: Serveral weid errors on sys_sparc32.c From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: <20020308105627.G24252@wobbly.melbourne.sgi.com> References: <1015543584.5649.2.camel@lucy> <20020308105627.G24252@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 07 Mar 2002 18:02:26 -0600 Message-Id: <1015545746.5649.6.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > We got this build problem (on Sparc64) with new VFS quota reported > - we no longer seem to define these, I guess the platform-specific > quotactl compatibility code needs some work still? So this is a VFS quota bug? -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Thu Mar 7 17:18:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g281ItC02702 for linux-xfs-outgoing; Thu, 7 Mar 2002 17:18:55 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g281Iq902680 for ; Thu, 7 Mar 2002 17:18:52 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g280IjbX023487 for ; Thu, 7 Mar 2002 16:18:46 -0800 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 LAA16829; Fri, 8 Mar 2002 11:17:27 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA27986; Fri, 8 Mar 2002 11:17:26 +1100 (AEDT) Date: Fri, 8 Mar 2002 11:17:26 +1100 From: Nathan Scott To: Alvaro Figueroa Cc: linux-xfs@oss.sgi.com, Jan Kara Subject: Re: Serveral weid errors on sys_sparc32.c Message-ID: <20020308111726.H24252@wobbly.melbourne.sgi.com> References: <1015543584.5649.2.camel@lucy> <20020308105627.G24252@wobbly.melbourne.sgi.com> <1015545746.5649.6.camel@lucy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1015545746.5649.6.camel@lucy>; from fede2@fuerzag.ulatina.ac.cr on Thu, Mar 07, 2002 at 06:02:26PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 07, 2002 at 06:02:26PM -0600, Alvaro Figueroa wrote: > > We got this build problem (on Sparc64) with new VFS quota reported > > - we no longer seem to define these, I guess the platform-specific > > quotactl compatibility code needs some work still? > > So this is a VFS quota bug? It's an area which Jan's latest patches haven't addressed yet. I'm sure he/someone will fix these issues at some point, we'll just have to wait a bit (once they're fixed I'll merge them in with the rest of the quota changes in CVS). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 7 17:35:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g281ZrC03254 for linux-xfs-outgoing; Thu, 7 Mar 2002 17:35:53 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g281Zo903231 for ; Thu, 7 Mar 2002 17:35:50 -0800 Received: from lucy.ulatina.ac.cr (lucy.ulatina.ac.cr [163.178.60.3]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA04739 for ; Thu, 7 Mar 2002 16:35:37 -0800 (PST) mail_from (fede2@fuerzag.ulatina.ac.cr) Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g280WUf05949; Thu, 7 Mar 2002 18:32:30 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Re: Serveral weid errors on sys_sparc32.c From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: <20020308111726.H24252@wobbly.melbourne.sgi.com> References: <1015543584.5649.2.camel@lucy> <20020308105627.G24252@wobbly.melbourne.sgi.com> <1015545746.5649.6.camel@lucy> <20020308111726.H24252@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 07 Mar 2002 18:32:30 -0600 Message-Id: <1015547550.5642.10.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > So this is a VFS quota bug? > > It's an area which Jan's latest patches haven't addressed yet. > I'm sure he/someone will fix these issues at some point, we'll > just have to wait a bit (once they're fixed I'll merge them in > with the rest of the quota changes in CVS). So, is there a quick work arround it? (I don't need any type of quotas, would there be a way to exclude code or something?) Or how could I download a CVS snapshot from _before_ this VFS quota code merge that is affecting me? I will now try with the weekly snapshot. If it compiles properly I'll start using it. Thanks for the help. -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Thu Mar 7 17:43:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g281h9Q03532 for linux-xfs-outgoing; Thu, 7 Mar 2002 17:43:09 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g281h5903510 for ; Thu, 7 Mar 2002 17:43:05 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g281gxBA026262 for ; Thu, 7 Mar 2002 17:43:00 -0800 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 LAA17036; Fri, 8 Mar 2002 11:41:41 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA28043; Fri, 8 Mar 2002 11:41:40 +1100 (AEDT) Date: Fri, 8 Mar 2002 11:41:40 +1100 From: Nathan Scott To: Alvaro Figueroa Cc: linux-xfs@oss.sgi.com Subject: Re: Serveral weid errors on sys_sparc32.c Message-ID: <20020308114140.I24252@wobbly.melbourne.sgi.com> References: <1015543584.5649.2.camel@lucy> <20020308105627.G24252@wobbly.melbourne.sgi.com> <1015545746.5649.6.camel@lucy> <20020308111726.H24252@wobbly.melbourne.sgi.com> <1015547550.5642.10.camel@lucy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1015547550.5642.10.camel@lucy>; from fede2@fuerzag.ulatina.ac.cr on Thu, Mar 07, 2002 at 06:32:30PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 07, 2002 at 06:32:30PM -0600, Alvaro Figueroa wrote: > > > So this is a VFS quota bug? > > > > It's an area which Jan's latest patches haven't addressed yet. > > I'm sure he/someone will fix these issues at some point, we'll > > just have to wait a bit (once they're fixed I'll merge them in > > with the rest of the quota changes in CVS). > > So, is there a quick work arround it? (I don't need any type of quotas, > would there be a way to exclude code or something?) Or how could I > download a CVS snapshot from _before_ this VFS quota code merge that is > affecting me? The 2.4.18 split patches will be fine (uses previous quota patches). A CVS checkout from before 5th March will be OK too (I think you can pass a date/time into cvs(1) when checking out). Or you could just comment out the quota bit of code in the offending file, if you don't need quotas at all. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 7 22:14:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g286E7j09389 for linux-xfs-outgoing; Thu, 7 Mar 2002 22:14:07 -0800 Received: from web21102.mail.yahoo.com (web21102.mail.yahoo.com [216.136.227.104]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g286Dx909365 for ; Thu, 7 Mar 2002 22:14:00 -0800 Message-ID: <20020308051358.40825.qmail@web21102.mail.yahoo.com> Received: from [12.234.153.47] by web21102.mail.yahoo.com via HTTP; Thu, 07 Mar 2002 21:13:58 PST Date: Thu, 7 Mar 2002 21:13:58 -0800 (PST) From: Glow Nair Subject: Trying to implment iptables in SGI XFS 1.02 To: 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 hi.. I am trying to implement iptables in SGI XFS 1.02; but it tells me that the kernel needs to be upgraded.. Any hints ? I have attached the message I get as well. Thanks Glow zanchu_glow@yahoo.com P.S. here are the current kernels that i have [root@yukon modules]# pwd /lib/modules [root@yukon modules]# ls 2.4.9-13SGI_XFS_1.0.2 2.4.9-13SGI_XFS_1.0.2BOOT 2.4.9-13SGI_XFS_1.0.2enterprise 2.4.9-13SGI_XFS_1.0.2smp [root@yukon modules]# --------------------------------- Message i get --------------------------------- [root@yukon modules]# /sbin/iptables -L /lib/modules/2.4.9-13SGI_XFS_1.0.2enterprise/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters /lib/modules/2.4.9-13SGI_XFS_1.0.2enterprise/kernel/net/ipv4/netfilter/ip_tables.o: insmod /lib/modules/2.4.9-13SGI_XFS_1.0.2enterprise/kernel/net/ipv4/netfilter/ip_tables.o failed /lib/modules/2.4.9-13SGI_XFS_1.0.2enterprise/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed iptables v1.2.3: can't initialize iptables table `filter': iptables who? (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. --------------------------------- __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ From owner-linux-xfs@oss.sgi.com Fri Mar 8 00:38:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g288cIb12884 for linux-xfs-outgoing; Fri, 8 Mar 2002 00:38:18 -0800 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g288cE912862 for ; Fri, 8 Mar 2002 00:38:14 -0800 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g287cBgt089223; Fri, 8 Mar 2002 08:38:11 +0100 (CET) Message-Id: <4.3.2.7.2.20020307083651.02e6ed80@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Mar 2002 08:38:31 +0100 To: Glow Nair , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Trying to implment iptables in SGI XFS 1.02 In-Reply-To: <20020308051358.40825.qmail@web21102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 21:13 7-3-2002 -0800, Glow Nair wrote: >hi.. > >I am trying to implement iptables in SGI XFS 1.02; but >it tells me that the kernel needs to be upgraded.. > >Any hints ? I have attached the message I get as well. If you have ipchains loaded, iptables won't load. rmmod ipchains modprobe iptables /sbin/iptables -L iptables is available in the XFS kernels so it should work just fine. Better I am already using it. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Mar 8 00:53:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g288rPa13402 for linux-xfs-outgoing; Fri, 8 Mar 2002 00:53:25 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g288rJ913376 for ; Fri, 8 Mar 2002 00:53:20 -0800 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16jF8a-0008BC-00; Fri, 08 Mar 2002 08:50:00 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Doruk Fisek" Date: Fri, 08 Mar 2002 08:50:00 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2472) For Windows 2000 (5.0.2195;2) In-Reply-To: <20020307153548.6a6a0e87.dfisek@fisek.com.tr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: annoying slowdowns Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 7 Mar 2002 15:35:48 +0200, Doruk Fisek wrote: > I'm experiencing real slowdowns in my xfs partition on my laptop. How much memory do you have? According to my experience a machine running XFS needs much more memory than one running ext2 only. I have a machine with only 40 megs, and it's really slow since I converted it to use XFS. -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Fri Mar 8 03:12:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28BCdF23315 for linux-xfs-outgoing; Fri, 8 Mar 2002 03:12:39 -0800 Received: from pooh.lsc.hu (IDENT:postfix@pooh.lsc.hu [195.56.172.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28BCR923292 for ; Fri, 8 Mar 2002 03:12:27 -0800 Received: by pooh.lsc.hu (Postfix, from userid 547) id 59991DFFEE; Fri, 8 Mar 2002 10:51:48 +0100 (CET) Date: Fri, 8 Mar 2002 10:51:48 +0100 From: GCS To: linux-xfs@oss.sgi.com Subject: Quota patches Message-ID: <20020308105148.A18371@lsc.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! The newest XFS has a new quota related patch for 32 bit uid/gids. Is it available as a separate patch? Thanks, GCS From owner-linux-xfs@oss.sgi.com Fri Mar 8 04:49:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28CnE025650 for linux-xfs-outgoing; Fri, 8 Mar 2002 04:49:14 -0800 Received: from atrey.karlin.mff.cuni.cz (root@atrey.karlin.mff.cuni.cz [195.113.31.123]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28Cn8925628 for ; Fri, 8 Mar 2002 04:49:09 -0800 Received: (from jack@localhost) by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id MAA15081; Fri, 8 Mar 2002 12:48:47 +0100 Date: Fri, 8 Mar 2002 12:48:47 +0100 From: Jan Kara To: Nathan Scott Cc: Alvaro Figueroa , linux-xfs@oss.sgi.com Subject: Re: Serveral weid errors on sys_sparc32.c Message-ID: <20020308114847.GB12160@atrey.karlin.mff.cuni.cz> References: <1015543584.5649.2.camel@lucy> <20020308105627.G24252@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020308105627.G24252@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, > We got this build problem (on Sparc64) with new VFS quota reported > - we no longer seem to define these, I guess the platform-specific > quotactl compatibility code needs some work still? Yes. Thanks. I completely forgot about this part (or better at one point I remembered it needs to be done but that I forgot it again). I'll do it during the weekend. Honza -- Jan Kara SuSE CR Labs From owner-linux-xfs@oss.sgi.com Fri Mar 8 07:24:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28FO6f31407 for linux-xfs-outgoing; Fri, 8 Mar 2002 07:24:06 -0800 Received: from voyager.st-peter.stw.uni-erlangen.de (mail@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28FNg931383 for ; Fri, 8 Mar 2002 07:23:43 -0800 Received: from svetljo.st-peter.stw.uni-erlangen.de ([172.17.17.181] helo=st-peter.stw.uni-erlangen.de) by voyager.st-peter.stw.uni-erlangen.de with esmtp (Exim 3.12 #1 (Debian)) id 16jLHN-0005Pi-00; Fri, 08 Mar 2002 15:23:29 +0100 Message-ID: <3C88C9A1.5070502@st-peter.stw.uni-erlangen.de> Date: Fri, 08 Mar 2002 15:24:33 +0100 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Stephen Lord , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio References: <1015580766.20800.3.camel@svetljo.st-peter.stw.uni-erlangen.de> <3C88B612.1070206@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16jLHN-0005Pi-00*1/AP3BnHHJQ* (Studentenwohnanlage Nuernberg St.-Peter) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stephen Lord wrote: > Svetoslav Slavtchev wrote: > >> that's what i got >> >> Unable to handle kernel NULL pointer dereference at virtual address >> 00000008 >> 801dba4e >> *pde = 00000000 >> Oops: 0000 >> CPU: 0 >> EIP: 0010:[<801dba4e>] Not tainted >> Using defaults from ksymoops -t elf32-i386 -a i386 >> EFLAGS: 00010046 >> eax: 00000120 ebx: 00000000 ecx: 00000282 edx: 00000000 >> esi: 8b745a00 edi: 00000008 ebp: 9aa92000 esp: 9ca31904 >> ds: 0018 es: 0018 ss: 0018 >> Process cpio (pid: 20435, stackpage=9ca31000) >> Stack: 00000282 00000004 8d5f4200 88dc0248 8d65b8c0 801db30d 88dc0248 >> 00000008 >> 00000004 00000001 8d65b980 8d65b8c0 00000004 88dc0248 801db081 >> 88dc0248 >> 8d65b980 8d65b8c0 00000004 8d65ba40 00000000 00000004 00000004 >> 8b745b20 >> Call Trace: [<801db30d>] [<801db081>] [<801db674>] [<8022db0d>] >> [<80209989>] >> [<8023bc4d>] [<8022dd94>] [<801db3a2>] [<8022e747>] [<80222538>] >> [<8020a412>] >> [<8021d4b9>] [<80212496>] [<8020f959>] [<802236ac>] [<802299f5>] >> [<80222f71>] >> [<80234f0e>] [<801d83bd>] [<80220981>] [<8020e103>] [<8022341a>] >> [<8020e103>] >> [<80227c17>] [<80235098>] [<80235348>] [<80145966>] [<80145a52>] >> [<8010722b>] >> Code: 8b 4a 08 85 c9 74 1b 8d 74 26 00 8d bc 27 00 00 00 00 43 83 >> >>>> EIP; 801dba4e <===== >>>> >> Trace; 801db30c >> Trace; 801db080 >> Trace; 801db674 >> Trace; 8022db0c <_pagebuf_get_object+3c/140> >> Trace; 80209988 >> Trace; 8023bc4c >> Trace; 8022dd94 <_pagebuf_free_object+f4/120> >> Trace; 801db3a2 >> Trace; 8022e746 >> Trace; 80222538 >> Trace; 8020a412 >> Trace; 8021d4b8 >> Trace; 80212496 >> Trace; 8020f958 >> Trace; 802236ac >> Trace; 802299f4 >> Trace; 80222f70 >> Trace; 80234f0e >> Trace; 801d83bc >> Trace; 80220980 >> Trace; 8020e102 >> Trace; 8022341a >> Trace; 8020e102 >> Trace; 80227c16 >> Trace; 80235098 >> Trace; 80235348 >> Trace; 80145966 >> Trace; 80145a52 >> Trace; 8010722a >> Code; 801dba4e >> 00000000 <_EIP>: >> Code; 801dba4e <===== >> 0: 8b 4a 08 mov 0x8(%edx),%ecx <===== >> Code; 801dba50 >> 3: 85 c9 test %ecx,%ecx >> Code; 801dba52 >> 5: 74 1b je 22 <_EIP+0x22> 801dba70 >> >> Code; 801dba54 >> 7: 8d 74 26 00 lea 0x0(%esi,1),%esi >> Code; 801dba58 >> b: 8d bc 27 00 00 00 00 lea 0x0(%edi,1),%edi >> Code; 801dba60 >> 12: 43 inc %ebx >> Code; 801dba60 >> 13: 83 00 00 addl $0x0,(%eax) >> > > This is this chunk of code: > > for (bsy = mp->m_perag[agno].pagb_list, n = 0; > c01970e2: 31 db xor %ebx,%ebx > c01970e4: 8b b5 e4 01 00 00 mov 0x1e4(%ebp),%esi > c01970ea: 8b 54 06 20 mov 0x20(%esi,%eax,1),%edx > n < XFS_PAGB_NUM_SLOTS; > bsy++, n++) { > if (bsy->busy_tp == NULL) { > c01970ee: 8b 4a 08 mov 0x8(%edx),%ecx > > It looks like bsy is NULL, which means either a corruption problem > (agno too large), > or a memory allocation problem during mount - did you get any error > messages when > you mounted the filesystem? Had you performed much I/O before this > happened, or > was the cpio the first thing you did. If this structure is missing > then chances are you > would not get far before dying. We have already referenced other > fields in the m_perag[agno] > structure, so I lean towards pagb_list itself being NULL. > > Can you send me the output of mkfs if you still have it, or failing > that, the output > of xfs_growfs -n /xxx where /xxx is the mounted filesystem. > > This chunk of code is new, you may have found a hole in it - although > I have been running > it for a couple of months here without problem. It could also be > something specific to > the aa kernel, I have not looked at this merge of XFS. > > Steve i just created LV, formated it with xfs , extended it , mounted it, extended the fs , and started to transfer my old /opt to the LV with cpio there were no complains from mount or xfs_growfs and i have no the output from mkfs.xfs [root@svetljo log]# xfs_growfs -n /opt meta-data=/opt isize=256 agcount=12, agsize=33024 blks data = bsize=4096 blocks=393216, imaxpct=25 = sunit=4 swidth=12 blks, unwritten=0 = imaxbits=24 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200 realtime =none extsz=49152 blocks=0, rtextents=0 That is from /var/log/messages Mar 8 10:34:44 svetljo kernel: XFS mounting filesystem lvm(58,5) Mar 8 10:35:00 svetljo CROND[20367]: (root) CMD ( /usr/sbin/monitoring.pl) Mar 8 10:36:11 svetljo kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 Mar 8 10:36:11 svetljo kernel: printing eip: Mar 8 10:36:11 svetljo kernel: 801dba4e Mar 8 10:36:11 svetljo kernel: *pde = 00000000 Mar 8 10:36:11 svetljo kernel: Oops: 0000 Mar 8 10:36:11 svetljo kernel: CPU: 0 Mar 8 10:36:11 svetljo kernel: EIP: 0010:[xfs_alloc_mark_busy+62/208] Not tainted Mar 8 10:36:11 svetljo kernel: EIP: 0010:[<801dba4e>] Not tainted Mar 8 10:36:11 svetljo kernel: EFLAGS: 00010046 Mar 8 10:36:11 svetljo kernel: eax: 00000120 ebx: 00000000 ecx: 00000282 edx: 00000000 Mar 8 10:36:11 svetljo kernel: esi: 8b745a00 edi: 00000008 ebp: 9aa92000 esp: 9ca31904 Mar 8 10:36:11 svetljo kernel: ds: 0018 es: 0018 ss: 0018 Mar 8 10:36:11 svetljo kernel: Process cpio (pid: 20435, stackpage=9ca31000) Mar 8 10:36:11 svetljo kernel: Stack: 00000282 00000004 8d5f4200 88dc0248 8d65b8c0 801db30d 88dc0248 00000008 Mar 8 10:36:11 svetljo kernel: 00000004 00000001 8d65b980 8d65b8c0 00000004 88dc0248 801db081 88dc0248 Mar 8 10:36:11 svetljo kernel: 8d65b980 8d65b8c0 00000004 8d65ba40 00000000 00000004 00000004 8b745b20 Mar 8 10:36:11 svetljo kernel: Call Trace: [xfs_alloc_put_freelist+205/224] [xfs_alloc_fix_freelist+1073/1152] [xfs_alloc_vextent+292/960] [_pagebuf_get_object+61/320] [xfs_ialloc_ag_alloc+473/2064] Mar 8 10:36:11 svetljo kernel: Call Trace: [<801db30d>] [<801db081>] [<801db674>] [<8022db0d>] [<80209989>] Mar 8 10:36:11 svetljo kernel: [kmem_zone_zalloc+61/224] [_pagebuf_free_object+244/288] [xfs_alloc_read_agf+130/560] [pagebuf_rele+103/128] [xfs_trans_brelse+216/224] [xfs_dialloc+386/2304] Mar 8 10:36:11 svetljo kernel: [<8023bc4d>] [<8022dd94>] [<801db3a2>] [<8022e747>] [<80222538>] [<8020a412>] Mar 8 10:36:11 svetljo kernel: [xfs_mod_incore_sb_batch+73/160] [xfs_inode_item_unlock+118/128] [xfs_ialloc+89/992] [xfs_dir_ialloc+140/656] [xfs_mkdir+885/1600] [xfs_trans_free_items+49/144] Mar 8 10:36:11 svetljo kernel: [<8021d4b9>] [<80212496>] [<8020f959>] [<802236ac>] [<802299f5>] [<80222f71>] Mar 8 10:36:11 svetljo kernel: [linvfs_common_cr+430/688] [xfs_acl_iaccess+45/144] [xfs_trans_reserve+145/352] [xfs_iunlock+51/96] [xfs_dir_lookup_int+186/704] [xfs_iunlock+51/96] Mar 8 10:36:11 svetljo kernel: [<80234f0e>] [<801d83bd>] [<80220981>] [<8020e103>] [<8022341a>] [<8020e103>] Mar 8 10:36:11 svetljo kernel: [xfs_lookup+167/272] [linvfs_lookup+104/192] [linvfs_mkdir+24/32] [vfs_mkdir+262/352] [sys_mkdir+146/224] [system_call+51/56] Mar 8 10:36:11 svetljo kernel: [<80227c17>] [<80235098>] [<80235348>] [<80145966>] [<80145a52>] [<8010722b>] Mar 8 10:36:11 svetljo kernel: Mar 8 10:36:11 svetljo kernel: Code: 8b 4a 08 85 c9 74 1b 8d 74 26 00 8d bc 27 00 00 00 00 43 83 From owner-linux-xfs@oss.sgi.com Fri Mar 8 07:28:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28FSp031703 for linux-xfs-outgoing; Fri, 8 Mar 2002 07:28:51 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28FSk931681 for ; Fri, 8 Mar 2002 07:28:46 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g28Fa9kw004708 for ; Fri, 8 Mar 2002 09:36:09 -0600 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA64946; Fri, 8 Mar 2002 08:28:40 -0600 (CST) Received: from sgi.com (bzeWCYXzkA998oNWblHEDEJJ2AMtU9LP@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA12638; Fri, 8 Mar 2002 08:28:40 -0600 (CST) Message-ID: <3C88CB1C.90203@sgi.com> Date: Fri, 08 Mar 2002 08:30:52 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: svetljo CC: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio References: <1015580766.20800.3.camel@svetljo.st-peter.stw.uni-erlangen.de> <3C88B612.1070206@sgi.com> <3C88C9A1.5070502@st-peter.stw.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk svetljo wrote: > > i just created LV, formated it with xfs , extended it , mounted it, > extended the fs , and started to transfer my old /opt to the LV with cpio > there were no complains from mount or xfs_growfs > and i have no the output from mkfs.xfs > > [root@svetljo log]# xfs_growfs -n /opt > meta-data=/opt isize=256 agcount=12, agsize=33024 blks > data = bsize=4096 blocks=393216, imaxpct=25 > = sunit=4 swidth=12 blks, > unwritten=0 > = imaxbits=24 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=1200 > realtime =none extsz=49152 blocks=0, rtextents=0 > > Ah, so you ran growfs on the filesystem, thats the key here. It looks like the new code does not handle growfs correctly, the structure which is null is not allocated in the expansion case. I should have a fix shortly. Steve From owner-linux-xfs@oss.sgi.com Fri Mar 8 07:39:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28Fd9w32164 for linux-xfs-outgoing; Fri, 8 Mar 2002 07:39:09 -0800 Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28Fd1932141 for ; Fri, 8 Mar 2002 07:39:01 -0800 Received: from user-2inia51.dialup.mindspring.com ([165.121.40.161] helo=waltsathlon.localhost.net) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16jLWM-0004R1-00 for linux-xfs@oss.sgi.com; Fri, 08 Mar 2002 09:38:58 -0500 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 1D27381BC14; Fri, 8 Mar 2002 06:38:12 -0800 (PST) Message-ID: <3C88CCD3.2060507@mindspring.com> Date: Fri, 08 Mar 2002 06:38:11 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020306 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glow Nair Cc: linux-xfs@oss.sgi.com Subject: Re: Trying to implment iptables in SGI XFS 1.02 References: <20020308051358.40825.qmail@web21102.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk That's usually the userspace tools which need to be updated/recompiled. There are some libraries which need to be linked against your current kernel. -Walt Glow Nair wrote: > hi.. > > I am trying to implement iptables in SGI XFS 1.02; but > it tells me that the kernel needs to be upgraded.. > > Any hints ? I have attached the message I get as well. > > Thanks > > Glow > zanchu_glow@yahoo.com > > P.S. here are the current kernels that i have > > [root@yukon modules]# pwd > /lib/modules > [root@yukon modules]# ls > 2.4.9-13SGI_XFS_1.0.2 > 2.4.9-13SGI_XFS_1.0.2BOOT > 2.4.9-13SGI_XFS_1.0.2enterprise > 2.4.9-13SGI_XFS_1.0.2smp > [root@yukon modules]# > --------------------------------- > Message i get > --------------------------------- > > > > [root@yukon modules]# /sbin/iptables -L > /lib/modules/2.4.9-13SGI_XFS_1.0.2enterprise/kernel/net/ipv4/netfilter/ip_tables.o: > init_module: Device or resource busy > Hint: insmod errors can be caused by incorrect module > parameters, including invalid IO or IRQ parameters > /lib/modules/2.4.9-13SGI_XFS_1.0.2enterprise/kernel/net/ipv4/netfilter/ip_tables.o: > insmod > /lib/modules/2.4.9-13SGI_XFS_1.0.2enterprise/kernel/net/ipv4/netfilter/ip_tables.o > failed > /lib/modules/2.4.9-13SGI_XFS_1.0.2enterprise/kernel/net/ipv4/netfilter/ip_tables.o: > insmod ip_tables failed > iptables v1.2.3: can't initialize iptables table > `filter': iptables who? (do you need to insmod?) > Perhaps iptables or your kernel needs to be upgraded. > > --------------------------------- > > > > > __________________________________________________ > Do You Yahoo!? > Try FREE Yahoo! Mail - the world's greatest free email! > http://mail.yahoo.com/ > From owner-linux-xfs@oss.sgi.com Fri Mar 8 08:20:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28GKjg01031 for linux-xfs-outgoing; Fri, 8 Mar 2002 08:20:45 -0800 Received: from zamok.crans.org (zamok.crans.org [138.231.136.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28GKh901009 for ; Fri, 8 Mar 2002 08:20:43 -0800 Received: from lucas.loria (localhost.crans.org [127.0.0.1]) by zamok.crans.org (Postfix) with ESMTP id CBAEFC00FD6 for ; Fri, 8 Mar 2002 16:20:41 +0100 (CET) Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id F312AA8DD for ; Fri, 8 Mar 2002 16:20:40 +0100 (CET) Received: by neo.loria (Postfix, from userid 500) id 3A97A104D1B; Fri, 8 Mar 2002 16:20:40 +0100 (CET) To: linux-xfs@oss.sgi.com Subject: Intermezzo and XFS X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E From: Vincent Bernat Organization: Kabale Inc Date: Fri, 08 Mar 2002 16:20:40 +0100 Message-ID: Lines: 5 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I remember that Intermezzo was incompatible with XFS. However, since Intermezzo is in the mainstream kernel since 2.4.15, is it now compatible with XFS ? Or will it be soon ? From owner-linux-xfs@oss.sgi.com Fri Mar 8 08:25:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28GPju01276 for linux-xfs-outgoing; Fri, 8 Mar 2002 08:25:45 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28GPg901254 for ; Fri, 8 Mar 2002 08:25:42 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g28FPabX023972 for ; Fri, 8 Mar 2002 07:25:36 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA65287; Fri, 8 Mar 2002 09:25:36 -0600 (CST) Received: from sgi.com (56HJ797rgnIYJv4jztduoHIv89xvix0T@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA63618; Fri, 8 Mar 2002 09:25:36 -0600 (CST) Message-ID: <3C88D874.9060802@sgi.com> Date: Fri, 08 Mar 2002 09:27:48 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Vincent Bernat CC: linux-xfs@oss.sgi.com Subject: Re: Intermezzo and XFS References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Vincent Bernat wrote: >Hello, > >I remember that Intermezzo was incompatible with XFS. However, since >Intermezzo is in the mainstream kernel since 2.4.15, is it now >compatible with XFS ? Or will it be soon ? > You can build them at the same time I think, but you cannot use Intermezzo with XFS, that functionality is currently broken. Steve From owner-linux-xfs@oss.sgi.com Fri Mar 8 08:37:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28Gb1101667 for linux-xfs-outgoing; Fri, 8 Mar 2002 08:37:01 -0800 Received: from zamok.crans.org (zamok.crans.org [138.231.136.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28Gaw901643 for ; Fri, 8 Mar 2002 08:36:58 -0800 Received: from lucas.loria (localhost.crans.org [127.0.0.1]) by zamok.crans.org (Postfix) with ESMTP id 3833BC00FD6; Fri, 8 Mar 2002 16:36:57 +0100 (CET) Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id 80063A8E2; Fri, 8 Mar 2002 16:36:56 +0100 (CET) Received: by neo.loria (Postfix, from userid 500) id A939F104D1B; Fri, 8 Mar 2002 16:36:55 +0100 (CET) To: Stephen Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Intermezzo and XFS References: <3C88D874.9060802@sgi.com> X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E From: Vincent Bernat In-Reply-To: <3C88D874.9060802@sgi.com> (Stephen Lord's message of "Fri, 08 Mar 2002 09:27:48 -0600") Organization: Kabale Inc Date: Fri, 08 Mar 2002 16:36:54 +0100 Message-ID: Lines: 9 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OoO Vers la fin de l'aprčs-midi du vendredi 08 mars 2002, vers 16:27, Stephen Lord disait: > You can build them at the same time I think, but you cannot use > Intermezzo with XFS, > that functionality is currently broken. Is it a limitation from XFS or is it a limitation from Intermezzo ? Just to know where to ask ! :) From owner-linux-xfs@oss.sgi.com Fri Mar 8 08:51:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28Gp3d02109 for linux-xfs-outgoing; Fri, 8 Mar 2002 08:51:03 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28Gp0902087 for ; Fri, 8 Mar 2002 08:51:00 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g28GotBA027108 for ; Fri, 8 Mar 2002 08:50:55 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA65599; Fri, 8 Mar 2002 09:50:54 -0600 (CST) Received: from sgi.com (M2gR8OINct41ql3oFvAaaze8Dt+IoOwm@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA34744; Fri, 8 Mar 2002 09:50:53 -0600 (CST) Message-ID: <3C88DE62.60309@sgi.com> Date: Fri, 08 Mar 2002 09:53:06 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Vincent Bernat CC: linux-xfs@oss.sgi.com Subject: Re: Intermezzo and XFS References: <3C88D874.9060802@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Vincent Bernat wrote: >OoO Vers la fin de l'aprhs-midi du vendredi 08 mars 2002, vers 16:27, >Stephen Lord disait: > >>You can build them at the same time I think, but you cannot use >>Intermezzo with XFS, >>that functionality is currently broken. >> > >Is it a limitation from XFS or is it a limitation from Intermezzo ? >Just to know where to ask ! :) > Well, I was referring to the running the Intermezzo cache in xfs - that requires extensions in the filesystem. Peter Braam started work on these at one point, but they have never been completed - so it is sort of on the Intermezzo end. Steve From owner-linux-xfs@oss.sgi.com Fri Mar 8 08:57:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28Gv9c02384 for linux-xfs-outgoing; Fri, 8 Mar 2002 08:57:09 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28Gux902341 for ; Fri, 8 Mar 2002 08:56:59 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g28GusBA027331 for ; Fri, 8 Mar 2002 08:56:54 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA67190; Fri, 8 Mar 2002 09:56:53 -0600 (CST) Received: from sgi.com (uOgfFfdI1282abL8ji8buHB8KXtcaA9u@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA53020; Fri, 8 Mar 2002 09:56:52 -0600 (CST) Message-ID: <3C88DFC9.8060907@sgi.com> Date: Fri, 08 Mar 2002 09:59:05 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: svetljo CC: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio References: <1015580766.20800.3.camel@svetljo.st-peter.stw.uni-erlangen.de> <3C88B612.1070206@sgi.com> <3C88C9A1.5070502@st-peter.stw.uni-erlangen.de> <3C88CB1C.90203@sgi.com> Content-Type: multipart/mixed; boundary="------------040807060906000606030200" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------040807060906000606030200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stephen Lord wrote: >> > Ah, so you ran growfs on the filesystem, thats the key here. It looks > like the new code > does not handle growfs correctly, the structure which is null is not > allocated in the > expansion case. I should have a fix shortly. > > Steve Hi, Can you try and repeat with this patch, it should apply reasonably cleanly to the aa tree. Steve --------------040807060906000606030200 Content-Type: text/plain; name="growfs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="growfs.patch" =========================================================================== Index: linux/fs/xfs/xfs_alloc.c =========================================================================== 2234a2235,2236 > pag->pagb_list = kmem_zalloc(XFS_PAGB_NUM_SLOTS * > sizeof(xfs_perag_busy_t), KM_SLEEP); =========================================================================== Index: linux/fs/xfs/xfs_mount.c =========================================================================== 151,152c151,153 < kmem_free(mp->m_perag[agno].pagb_list, < sizeof(xfs_perag_busy_t) * XFS_PAGB_NUM_SLOTS); --- > if (mp->m_perag[agno].pagb_list) > kmem_free(mp->m_perag[agno].pagb_list, > sizeof(xfs_perag_busy_t) * XFS_PAGB_NUM_SLOTS); 877,881d877 < for (agno = 0; agno < sbp->sb_agcount; agno++) { < mp->m_perag[agno].pagb_count = 0; < mp->m_perag[agno].pagb_list = kmem_zalloc(XFS_PAGB_NUM_SLOTS * < sizeof(xfs_perag_busy_t), KM_SLEEP); < } 1066,1067c1062,1064 < kmem_free(mp->m_perag[agno].pagb_list, < sizeof(xfs_perag_busy_t) * XFS_PAGB_NUM_SLOTS); --- > if (mp->m_perag[agno].pagb_list) > kmem_free(mp->m_perag[agno].pagb_list, > sizeof(xfs_perag_busy_t) * XFS_PAGB_NUM_SLOTS); --------------040807060906000606030200-- From owner-linux-xfs@oss.sgi.com Fri Mar 8 09:23:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28HNQN03095 for linux-xfs-outgoing; Fri, 8 Mar 2002 09:23:26 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28HNM903073 for ; Fri, 8 Mar 2002 09:23:22 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g28HUjkw006457 for ; Fri, 8 Mar 2002 11:30:45 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA66522 for ; Fri, 8 Mar 2002 10:23:16 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA19881 for ; Fri, 8 Mar 2002 10:23:16 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g28GMwe27224; Fri, 8 Mar 2002 10:22:58 -0600 Message-Id: <200203081622.g28GMwe27224@jen.americas.sgi.com> Date: Fri, 8 Mar 2002 10:22:58 -0600 Subject: TAKE - fix growfs to: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The introduction of the async delete code added some new data structures, these were not initialized correctly in the case where growfs expanded the filesystem. Date: Fri Mar 8 08:21:26 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113568a linux/fs/xfs/xfs_mount.c - 1.274 - only free pagb_list if it is initialized, we do not allocate them all at mount time now. linux/fs/xfs/xfs_alloc.c - 1.146 - Allocate pagb_list when we initialize the agf, moved here from mount From owner-linux-xfs@oss.sgi.com Fri Mar 8 09:46:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28Hkm503574 for linux-xfs-outgoing; Fri, 8 Mar 2002 09:46:48 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28Hkj903551 for ; Fri, 8 Mar 2002 09:46:45 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g28GkcbX027024 for ; Fri, 8 Mar 2002 08:46:39 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA67473 for ; Fri, 8 Mar 2002 10:46:38 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA33648 for ; Fri, 8 Mar 2002 10:46:38 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g28GkKY28040; Fri, 8 Mar 2002 10:46:20 -0600 Message-Id: <200203081646.g28GkKY28040@jen.americas.sgi.com> Date: Fri, 8 Mar 2002 10:46:20 -0600 Subject: TAKE - fix sgid inheritence for root To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Mar 8 08:44:34 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113571a linux/fs/xfs/xfs_inode.c - 1.328 - Fix sgid bit inheritence for root From owner-linux-xfs@oss.sgi.com Fri Mar 8 11:44:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28JifA08640 for linux-xfs-outgoing; Fri, 8 Mar 2002 11:44:41 -0800 Received: from voyager.st-peter.stw.uni-erlangen.de (mail@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28Jia908618 for ; Fri, 8 Mar 2002 11:44:36 -0800 Received: from svetljo.st-peter.stw.uni-erlangen.de ([172.17.17.181]) by voyager.st-peter.stw.uni-erlangen.de with esmtp (Exim 3.12 #1 (Debian)) id 16jPLl-0007CL-00; Fri, 08 Mar 2002 19:44:17 +0100 Received: from svetljo.st-peter.stw.uni-erlangen.de (localhost.localdomain [127.0.0.1]) by svetljo.st-peter.stw.uni-erlangen.de (8.12.1/8.12.1) with ESMTP id g28IjNMb004735; Fri, 8 Mar 2002 19:45:23 +0100 Received: (from root@localhost) by svetljo.st-peter.stw.uni-erlangen.de (8.12.1/8.12.1/Submit) id g28IjNM1004733; Fri, 8 Mar 2002 19:45:23 +0100 Subject: Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio From: Svetoslav Slavtchev To: Stephen Lord Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com In-Reply-To: <3C88CB1C.90203@sgi.com> References: <1015580766.20800.3.camel@svetljo.st-peter.stw.uni-erlangen.de> <3C88B612.1070206@sgi.com> <3C88C9A1.5070502@st-peter.stw.uni-erlangen.de> <3C88CB1C.90203@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2-4mdk Date: 08 Mar 2002 19:45:23 +0100 Message-Id: <1015613123.4301.11.camel@svetljo.st-peter.stw.uni-erlangen.de> Mime-Version: 1.0 X-Scanner: exiscan *16jPLl-0007CL-00*xB8nuNe7t/k* (Studentenwohnanlage Nuernberg St.-Peter) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi seems to work now created a 1 Gib lv, formated it, extended with 2 Gib , extended the fs and transfered about 1,5 Gib over it No troubles thanks for the fix :) svetljo and a stupid question is there a way to limit the I/O request that XFS sends to the lower layer ( soft RAID or lvm ) without need to modify existing fs just a hack until the raid-0 code in 2.5 is fixed i'm talking about this: > raid0_make_request bug: can't convert block across chunks or bigger > than 16k 23610115 64 i posted already twice to lkml and linux-xfs and i got answer that the raid is not ready but it's worked on thanks svetljo From owner-linux-xfs@oss.sgi.com Fri Mar 8 12:14:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28KEoR09758 for linux-xfs-outgoing; Fri, 8 Mar 2002 12:14:50 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28KEj909736 for ; Fri, 8 Mar 2002 12:14:46 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16jPp8-0005f3-00; Fri, 08 Mar 2002 14:14:38 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g28JEaB02038; Fri, 8 Mar 2002 14:14:36 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: Svetoslav Slavtchev Cc: Stephen Lord , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio From: "Martin K. Petersen" Organization: mkp.net References: <1015580766.20800.3.camel@svetljo.st-peter.stw.uni-erlangen.de> <3C88B612.1070206@sgi.com> <3C88C9A1.5070502@st-peter.stw.uni-erlangen.de> <3C88CB1C.90203@sgi.com> <1015613123.4301.11.camel@svetljo.st-peter.stw.uni-erlangen.de> Date: 08 Mar 2002 14:14:36 -0500 In-Reply-To: <1015613123.4301.11.camel@svetljo.st-peter.stw.uni-erlangen.de> Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> "Svetoslav" == Svetoslav Slavtchev writes: Svetoslav> and a stupid question is there a way to limit the I/O Svetoslav> request that XFS sends to the lower layer ( soft RAID or Svetoslav> lvm ) without need to modify existing fs just a hack until Svetoslav> the raid-0 code in 2.5 is fixed Not really. Besides, requests may be merged and that would give the same result. I've been busy with IA-64 stuff the last week - I'll try to get back to the RAID hacking this weekend. I have all of my code merged but still need to deal with multi-zone setups. -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. mkp@linuxcare.com, http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ From owner-linux-xfs@oss.sgi.com Fri Mar 8 13:45:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28LjFb11525 for linux-xfs-outgoing; Fri, 8 Mar 2002 13:45:15 -0800 Received: from primeview.com ([216.237.157.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28LjB911503 for ; Fri, 8 Mar 2002 13:45:11 -0800 Received: from blacky [66.51.210.124] by primeview.com (SMTPD32-7.06) id A2D2EDF008E; Fri, 08 Mar 2002 12:45:06 -0800 From: "RALF" To: Subject: IBM HDDs Date: Fri, 8 Mar 2002 12:44:01 -0800 Message-ID: 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk we can offer ... IBM DDYS 07N3255 9 GB 10K RPM 1" 80 pin price : US$ 69,00 1 year warranty Min. order 100 units NEW Factory sealed in IBM boxes Ralf H Heiss GM A-Tec Subsystems Inc 18261 Enterprise Lane HB CA 92648 USA www.atecsubsystems.com P: 714 848 3599 x29 F: 714 848 9679 C: 714 608 6018 (cell and pager) For IT Alliance customer: use sales@i-t-alliance.com From owner-linux-xfs@oss.sgi.com Fri Mar 8 14:12:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28MCYb12099 for linux-xfs-outgoing; Fri, 8 Mar 2002 14:12:34 -0800 Received: from rj.sgi.com (rj.sgi.com [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28MBQ912065 for ; Fri, 8 Mar 2002 14:11:26 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g28LBKbX011621 for ; Fri, 8 Mar 2002 13:11:21 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA72300 for ; Fri, 8 Mar 2002 15:11:20 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA76520 for ; Fri, 8 Mar 2002 15:11:20 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g28LB0N06517; Fri, 8 Mar 2002 15:11:00 -0600 Message-Id: <200203082111.g28LB0N06517@jen.americas.sgi.com> Date: Fri, 8 Mar 2002 15:11:00 -0600 Subject: TAKE - merge up to 2.5.6 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Mar 8 13:05:27 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:113610a linux/drivers/net/tulip/Config.help - 1.1 linux/sound/pci/Config.help - 1.1 linux/sound/isa/Config.help - 1.1 linux/drivers/net/tulip/Config.in - 1.1 linux/sound/drivers/Config.help - 1.1 linux/Documentation/networking/driver.txt - 1.1 linux/Documentation/networking/generic-hdlc.txt - 1.1 linux/drivers/net/tg3.h - 1.1 linux/sound/core/ioctl32/timer32.c - 1.1 linux/drivers/net/tg3.c - 1.1 linux/sound/core/ioctl32/rawmidi32.c - 1.1 linux/drivers/pcmcia/sa1111_generic.h - 1.1 linux/drivers/pcmcia/sa1111_generic.c - 1.1 linux/drivers/net/tulip/de2104x.c - 1.1 linux/drivers/net/tulip/de4x5.c - 1.1 linux/drivers/pcmcia/sa1100_system3.c - 1.1 linux/drivers/pcmcia/sa1100_shannon.c - 1.1 linux/drivers/net/tulip/de4x5.h - 1.1 linux/drivers/net/tulip/dmfe.c - 1.1 linux/drivers/net/tulip/winbond-840.c - 1.1 linux/drivers/pcmcia/sa1100_generic.h - 1.1 linux/drivers/pcmcia/sa1100_badge4.c - 1.1 linux/include/linux/hdlc/ioctl.h - 1.1 linux/sound/core/ioctl32/pcm32.c - 1.1 linux/sound/core/ioctl32/ioctl32.h - 1.1 linux/drivers/net/tulip/xircom_cb.c - 1.1 linux/sound/core/ioctl32/ioctl32.c - 1.1 linux/sound/core/ioctl32/hwdep32.c - 1.1 linux/drivers/net/wan/hdlc_x25.c - 1.1 linux/Documentation/sound/oss/AD1816 - 1.1 linux/drivers/net/tulip/xircom_tulip_cb.c - 1.1 linux/drivers/net/wan/hdlc_cisco.c - 1.1 linux/sound/core/ioctl32/Makefile - 1.1 linux/sound/core/Config.help - 1.1 linux/sound/Config.help - 1.1 linux/drivers/net/wan/hdlc_fr.c - 1.1 linux/drivers/net/wan/hdlc_generic.c - 1.1 linux/drivers/net/wan/hdlc_ppp.c - 1.1 linux/Documentation/sound/oss/Maestro3 - 1.1 linux/drivers/net/e100/e100_phy.h - 1.1 linux/Documentation/sound/oss/OPL3-SA - 1.1 linux/drivers/net/e100/e100_proc.c - 1.1 linux/drivers/net/e100/Makefile - 1.1 linux/drivers/net/e100/e100.h - 1.1 linux/drivers/net/e100/e100_ucode.h - 1.1 linux/drivers/net/e100/e100_vendor.h - 1.1 linux/Documentation/sound/alsa/CMIPCI.txt - 1.1 linux/Documentation/sound/alsa/SB-Live-mixer.txt - 1.1 linux/Documentation/sound/alsa/seq_oss.html - 1.1 linux/drivers/net/wan/hdlc_raw.c - 1.1 linux/drivers/net/e100/e100_phy.c - 1.1 linux/drivers/net/e100/e100_config.c - 1.1 linux/drivers/net/e100/e100_config.h - 1.1 linux/drivers/net/e100/e100_eeprom.c - 1.1 linux/drivers/net/e100/e100_main.c - 1.1 linux/Documentation/sound/oss/ALS - 1.1 linux/Documentation/sound/oss/AWE32 - 1.1 linux/Documentation/sound/oss/AudioExcelDSP16 - 1.1 linux/Documentation/sound/oss/CMI8330 - 1.1 linux/Documentation/sound/oss/CMI8338 - 1.1 linux/Documentation/sound/oss/CS4232 - 1.1 linux/Documentation/sound/oss/ChangeLog.awe - 1.1 linux/Documentation/sound/oss/ChangeLog.multisound - 1.1 linux/Documentation/sound/oss/ESS - 1.1 linux/Documentation/sound/oss/ESS1868 - 1.1 linux/Documentation/sound/oss/INSTALL.awe - 1.1 linux/Documentation/sound/oss/Introduction - 1.1 linux/Documentation/sound/oss/MAD16 - 1.1 linux/Documentation/sound/oss/Maestro - 1.1 linux/Documentation/sound/oss/ultrasound - 1.1 linux/Documentation/sound/oss/MultiSound - 1.1 linux/Documentation/sound/oss/NEWS - 1.1 linux/Documentation/sound/oss/NM256 - 1.1 linux/Documentation/sound/oss/OPL3 - 1.1 linux/Documentation/sound/oss/vwsnd - 1.1 linux/Documentation/sound/oss/OPL3-SA2 - 1.1 linux/Documentation/sound/oss/Opti - 1.1 linux/Documentation/sound/oss/PAS16 - 1.1 linux/Documentation/sound/oss/PSS - 1.1 linux/Documentation/sound/oss/PSS-updates - 1.1 linux/Documentation/sound/oss/README.OSS - 1.1 linux/Documentation/sound/oss/README.awe - 1.1 linux/Documentation/sound/oss/README.modules - 1.1 linux/Documentation/sound/oss/README.ymfsb - 1.1 linux/Documentation/sound/oss/SoundPro - 1.1 linux/Documentation/sound/oss/Soundblaster - 1.1 linux/Documentation/sound/oss/Tropez+ - 1.1 linux/Documentation/sound/oss/VIA-chipset - 1.1 linux/Documentation/sound/oss/VIBRA16 - 1.1 linux/Documentation/sound/oss/WaveArtist - 1.1 linux/Documentation/sound/oss/Wavefront - 1.1 linux/Documentation/sound/oss/btaudio - 1.1 linux/Documentation/sound/oss/cs46xx - 1.1 linux/Documentation/sound/oss/es1370 - 1.1 linux/Documentation/sound/oss/es1371 - 1.1 linux/Documentation/sound/oss/mwave - 1.1 linux/Documentation/sound/oss/solo1 - 1.1 linux/Documentation/sound/oss/sonicvibes - 1.1 linux/scripts/tkgen.c - 1.8 linux/net/unix/af_unix.c - 1.42 linux/net/irda/irlap_frame.c - 1.15 linux/net/irda/irlap_event.c - 1.20 linux/net/irda/irlap.c - 1.17 linux/net/irda/irda_device.c - 1.24 linux/net/irda/af_irda.c - 1.33 linux/net/core/dev.c - 1.51 linux/mm/swapfile.c - 1.53 linux/mm/slab.c - 1.32 linux/mm/page_alloc.c - 1.74 linux/mm/filemap.c - 1.113 linux/kernel/signal.c - 1.28 linux/kernel/sched.c - 1.62 linux/kernel/ksyms.c - 1.138 linux/kernel/kmod.c - 1.20 linux/init/main.c - 1.76 linux/include/net/irda/irqueue.h - 1.7 linux/include/net/irda/irlap_event.h - 1.7 linux/include/net/irda/irlap.h - 1.13 linux/include/net/irda/irda.h - 1.16 linux/include/linux/swap.h - 1.54 linux/include/linux/sockios.h - 1.10 linux/include/linux/smp.h - 1.11 linux/include/linux/smbno.h - 1.5 linux/include/linux/smb_mount.h - 1.5 linux/include/linux/smb_fs_sb.h - 1.6 linux/include/linux/smb_fs.h - 1.17 linux/include/linux/smb.h - 1.7 linux/include/linux/pci.h - 1.56 linux/include/linux/mm.h - 1.82 linux/include/linux/if_ether.h - 1.10 linux/include/linux/if.h - 1.5 linux/include/linux/hdreg.h - 1.15 linux/include/linux/fs.h - 1.158 linux/include/linux/coda_proc.h - 1.7 linux/include/linux/coda_linux.h - 1.14 linux/include/linux/coda_fs_i.h - 1.8 linux/include/linux/blk.h - 1.31 linux/include/asm-ppc/pgtable.h - 1.32 linux/include/asm-i386/unistd.h - 1.22 linux/include/asm-i386/siginfo.h - 1.8 linux/include/asm-i386/io.h - 1.25 linux/include/asm-arm/proc-armv/pgtable.h - 1.15 linux/include/asm-arm/pgtable.h - 1.24 linux/include/asm-alpha/system.h - 1.20 linux/include/asm-alpha/smp.h - 1.19 linux/include/asm-alpha/pgtable.h - 1.33 linux/include/asm-alpha/keyboard.h - 1.8 linux/include/asm-alpha/jensen.h - 1.7 linux/fs/super.c - 1.80 linux/fs/smbfs/proc.c - 1.17 linux/fs/smbfs/inode.c - 1.30 linux/fs/smbfs/file.c - 1.27 linux/fs/smbfs/dir.c - 1.21 linux/fs/smbfs/cache.c - 1.14 linux/fs/open.c - 1.35 linux/fs/nfsd/nfsctl.c - 1.28 linux/fs/nfsd/export.c - 1.30 linux/fs/namei.c - 1.49 linux/fs/inode.c - 1.70 linux/fs/ext2/fsync.c - 1.13 linux/fs/exec.c - 1.54 linux/fs/coda/upcall.c - 1.17 linux/fs/coda/sysctl.c - 1.16 linux/fs/coda/psdev.c - 1.22 linux/fs/coda/pioctl.c - 1.14 linux/fs/coda/inode.c - 1.21 linux/fs/coda/file.c - 1.19 linux/fs/coda/dir.c - 1.24 linux/fs/coda/coda_linux.c - 1.9 linux/fs/coda/cnode.c - 1.13 linux/fs/coda/cache.c - 1.12 linux/fs/block_dev.c - 1.43 linux/drivers/video/vesafb.c - 1.21 linux/drivers/usb/Config.in - 1.54 linux/drivers/scsi/sr_vendor.c - 1.12 linux/drivers/scsi/sr_ioctl.c - 1.23 linux/drivers/scsi/sr.h - 1.7 linux/drivers/scsi/sr.c - 1.40 linux/drivers/scsi/sd.c - 1.57 linux/drivers/scsi/scsi_syms.c - 1.17 linux/drivers/scsi/scsi_error.c - 1.24 linux/drivers/scsi/scsi.h - 1.27 linux/drivers/scsi/scsi.c - 1.52 linux/drivers/scsi/ide-scsi.c - 1.28 linux/drivers/pci/pci.c - 1.54 linux/drivers/net/wd.c - 1.16 linux/drivers/net/smc-ultra32.c - 1.14 linux/drivers/net/smc-ultra.c - 1.20 linux/drivers/net/ppp_deflate.c - 1.8 linux/drivers/net/pcnet32.c - 1.32 linux/drivers/net/ne3210.c - 1.15 linux/drivers/net/ne2k-pci.c - 1.24 linux/drivers/net/ne.c - 1.21 linux/drivers/net/lne390.c - 1.16 linux/drivers/net/irda/w83977af_ir.c - 1.22 linux/drivers/net/hp.c - 1.15 linux/drivers/net/hp-plus.c - 1.16 linux/drivers/net/hamradio/scc.c - 1.24 linux/drivers/net/hamradio/mkiss.c - 1.14 linux/drivers/net/hamradio/hdlcdrv.c - 1.15 linux/drivers/net/hamradio/bpqether.c - 1.19 linux/drivers/net/hamradio/baycom_epp.c - 1.19 linux/drivers/net/hamradio/6pack.c - 1.13 linux/drivers/net/es3210.c - 1.16 linux/drivers/net/eepro100.c - 1.41 linux/drivers/net/e2100.c - 1.16 linux/drivers/net/de4x5.h - 1.5 linux/drivers/net/de4x5.c - 1.25 linux/drivers/net/ac3200.c - 1.18 linux/drivers/net/Makefile - 1.55 linux/drivers/net/Config.in - 1.59 linux/drivers/net/3c509.c - 1.29 linux/drivers/net/3c505.c - 1.25 linux/drivers/net/3c503.c - 1.21 linux/drivers/isdn/act2000/act2000_isa.c - 1.8 linux/drivers/char/synclink.c - 1.23 linux/drivers/char/acquirewdt.c - 1.15 linux/drivers/cdrom/cdrom.c - 1.40 linux/drivers/block/xd.c - 1.33 linux/drivers/block/rd.c - 1.47 linux/drivers/block/ps2esdi.c - 1.35 linux/drivers/block/paride/pf.c - 1.22 linux/drivers/block/paride/pd.c - 1.27 linux/drivers/block/loop.c - 1.53 linux/drivers/block/floppy.c - 1.36 linux/drivers/block/ataflop.c - 1.20 linux/drivers/block/acsi.c - 1.26 linux/drivers/acorn/scsi/ecoscsi.c - 1.9 linux/drivers/acorn/block/mfmhd.c - 1.20 linux/arch/sparc64/defconfig - 1.61 linux/arch/ppc/vmlinux.lds - 1.15 linux/arch/ppc/mm/init.c - 1.40 linux/arch/ppc/mm/fault.c - 1.19 linux/arch/ppc/lib/locks.c - 1.11 linux/arch/ppc/kernel/smp.c - 1.34 linux/arch/ppc/kernel/ppc_ksyms.c - 1.40 linux/arch/ppc/kernel/misc.S - 1.36 linux/arch/ppc/kernel/idle.c - 1.22 linux/arch/ppc/config.in - 1.46 linux/arch/i386/vmlinux.lds - 1.16 linux/arch/i386/kernel/traps.c - 1.50 linux/arch/i386/kernel/time.c - 1.21 linux/arch/i386/kernel/io_apic.c - 1.34 linux/arch/i386/kernel/entry.S - 1.51 linux/arch/i386/kernel/apm.c - 1.40 linux/arch/i386/kernel/Makefile - 1.25 linux/arch/i386/defconfig - 1.101 linux/arch/arm/mm/mm-armv.c - 1.24 linux/arch/arm/mm/init.c - 1.25 linux/arch/arm/mm/fault-common.c - 1.20 linux/arch/arm/mm/fault-armv.c - 1.22 linux/arch/arm/kernel/process.c - 1.25 linux/arch/arm/kernel/armksyms.c - 1.24 linux/arch/arm/config.in - 1.36 linux/arch/alpha/mm/init.c - 1.21 linux/arch/alpha/kernel/process.c - 1.24 linux/arch/alpha/kernel/entry.S - 1.27 linux/arch/alpha/defconfig - 1.23 linux/arch/alpha/config.in - 1.42 linux/arch/alpha/Makefile - 1.13 linux/Makefile - 1.189 linux/MAINTAINERS - 1.99 linux/Documentation/sound/ultrasound - 1.3 linux/Documentation/sound/sonicvibes - 1.4 linux/Documentation/sound/mwave - 1.3 linux/Documentation/sound/es1371 - 1.4 linux/Documentation/sound/es1370 - 1.4 linux/Documentation/sound/Wavefront - 1.5 linux/Documentation/sound/VIBRA16 - 1.3 linux/Documentation/sound/VIA-chipset - 1.3 linux/Documentation/sound/Tropez+ - 1.3 linux/Documentation/sound/Soundblaster - 1.6 linux/Documentation/sound/README.modules - 1.6 linux/Documentation/sound/README.awe - 1.4 linux/Documentation/sound/README.OSS - 1.7 linux/Documentation/sound/Opti - 1.6 linux/Documentation/sound/OPL3-SA2 - 1.8 linux/Documentation/sound/OPL3-SA - 1.4 linux/Documentation/sound/OPL3 - 1.3 linux/Documentation/sound/MultiSound - 1.4 linux/Documentation/sound/MAD16 - 1.5 linux/Documentation/sound/Introduction - 1.10 linux/Documentation/sound/INSTALL.awe - 1.4 linux/Documentation/sound/ESS1868 - 1.4 linux/Documentation/sound/ESS - 1.5 linux/Documentation/sound/ChangeLog.multisound - 1.3 linux/Documentation/sound/ChangeLog.awe - 1.3 linux/Documentation/sound/CS4232 - 1.3 linux/Documentation/sound/CMI8330 - 1.7 linux/Documentation/sound/AudioExcelDSP16 - 1.4 linux/Documentation/sound/AWE32 - 1.7 linux/Documentation/sound/AD1816 - 1.5 linux/Documentation/pci.txt - 1.18 linux/Documentation/networking/arcnet-hardware.txt - 1.6 linux/COPYING - 1.6 linux/include/linux/ide.h - 1.41 linux/include/linux/blkpg.h - 1.2 linux/fs/hpfs/ea.c - 1.6 linux/drivers/usb/printer.c - 1.43 linux/drivers/net/irda/toshoboe.c - 1.28 linux/drivers/net/irda/smc-ircc.c - 1.23 linux/drivers/block/blkpg.c - 1.18 linux/Documentation/sound/CMI8338 - 1.6 linux/drivers/block/cpqarray.c - 1.43 linux/drivers/net/hamradio/yam.c - 1.17 linux/fs/partitions/msdos.c - 1.19 linux/fs/partitions/check.h - 1.7 linux/fs/partitions/check.c - 1.37 linux/fs/partitions/Config.in - 1.15 linux/Documentation/sound/vwsnd - 1.2 linux/Documentation/sound/solo1 - 1.3 linux/arch/ppc/kernel/entry.S - 1.26 linux/drivers/block/DAC960.c - 1.44 linux/drivers/pcmcia/Makefile - 1.13 linux/drivers/pcmcia/Config.in - 1.11 linux/include/linux/spinlock.h - 1.15 linux/drivers/net/starfire.c - 1.25 linux/drivers/net/pcmcia/Makefile - 1.21 linux/drivers/net/pcmcia/Config.in - 1.27 linux/drivers/net/dmfe.c - 1.24 linux/Documentation/sound/NM256 - 1.4 linux/drivers/net/wan/Makefile - 1.14 linux/drivers/net/wan/Config.in - 1.13 linux/arch/ppc/kernel/qspan_pci.c - 1.6 linux/arch/i386/kernel/smpboot.c - 1.34 linux/arch/i386/kernel/pci-pc.c - 1.33 linux/include/linux/pci_ids.h - 1.60 linux/drivers/net/wan/sdla_x25.c - 1.14 linux/include/asm-arm/arch-sa1100/irqs.h - 1.8 linux/drivers/pci/pci.ids - 1.43 linux/drivers/net/sk98lin/skge.c - 1.19 linux/include/asm-ppc/pgalloc.h - 1.8 linux/include/asm-arm/pgalloc.h - 1.9 linux/include/asm-alpha/pgalloc.h - 1.13 linux/arch/alpha/kernel/core_irongate.c - 1.8 linux/include/linux/cache.h - 1.4 linux/drivers/char/agp/agpgart_be.c - 1.33 linux/drivers/sbus/char/jsflash.c - 1.15 linux/Documentation/sound/Maestro - 1.7 linux/Documentation/filesystems/cramfs.txt - 1.5 linux/scripts/cramfs/mkcramfs.c - 1.7 linux/fs/cramfs/inode.c - 1.25 linux/include/linux/telephony.h - 1.8 linux/drivers/usb/ov511.h - 1.15 linux/drivers/usb/ov511.c - 1.34 linux/drivers/telephony/ixj.c - 1.22 linux/Documentation/usb/ov511.txt - 1.16 linux/drivers/pnp/quirks.c - 1.8 linux/Documentation/sound/PSS - 1.3 linux/Documentation/sound/SoundPro - 1.3 linux/arch/i386/kernel/mpparse.c - 1.15 linux/scripts/cramfs/GNUmakefile - 1.3 linux/include/asm-i386/mpspec.h - 1.8 linux/fs/cramfs/README - 1.3 linux/drivers/scsi/3w-xxxx.h - 1.9 linux/drivers/scsi/3w-xxxx.c - 1.17 linux/drivers/net/irda/nsc-ircc.c - 1.20 linux/drivers/video/matrox/matroxfb_DAC1064.c - 1.11 linux/drivers/net/tulip/tulip_core.c - 1.39 linux/drivers/net/tulip/Makefile - 1.5 linux/arch/mips64/sgi-ip27/ip27-rtc.c - 1.7 linux/drivers/usb/pegasus.c - 1.29 linux/drivers/ide/rz1000.c - 1.5 linux/drivers/ide/piix.c - 1.17 linux/drivers/ide/opti621.c - 1.7 linux/drivers/ide/ide.c - 1.46 linux/drivers/ide/ide-tape.c - 1.21 linux/drivers/ide/ide-proc.c - 1.14 linux/drivers/ide/ide-probe.c - 1.26 linux/drivers/ide/ide-pci.c - 1.22 linux/drivers/ide/ide-geometry.c - 1.11 linux/drivers/ide/ide-floppy.c - 1.18 linux/drivers/ide/ide-dma.c - 1.21 linux/drivers/ide/ide-disk.c - 1.27 linux/drivers/ide/ide-cd.c - 1.28 linux/drivers/ide/ht6560b.c - 1.5 linux/drivers/ide/hpt366.c - 1.14 linux/drivers/ide/hd.c - 1.19 linux/drivers/ide/dtc2278.c - 1.4 linux/drivers/ide/cmd64x.c - 1.10 linux/drivers/ide/cmd640.c - 1.6 linux/drivers/ide/ali14xx.c - 1.6 linux/drivers/ide/Config.in - 1.17 linux/Documentation/sound/ALS - 1.4 linux/drivers/net/tokenring/lanstreamer.h - 1.4 linux/drivers/net/tokenring/lanstreamer.c - 1.11 linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.22 linux/Documentation/sound/PAS16 - 1.3 linux/arch/s390/kernel/entry.S - 1.17 linux/drivers/s390/misc/chandev.c - 1.8 linux/drivers/s390/block/dasd.c - 1.21 linux/Documentation/DocBook/kernel-locking.tmpl - 1.7 linux/fs/xfs/linux/xfs_super.c - 1.168 linux/fs/xfs/linux/xfs_ioctl.c - 1.57 linux/Documentation/sound/README.ymfsb - 1.3 linux/drivers/char/drm/i810_dma.c - 1.11 linux/drivers/usb/storage/transport.c - 1.19 linux/drivers/mtd/ftl.c - 1.13 linux/fs/smbfs/ChangeLog - 1.9 linux/Documentation/sound/NEWS - 1.3 linux/Documentation/sound/PSS-updates - 1.2 linux/drivers/block/cciss.c - 1.32 linux/drivers/md/md.c - 1.41 linux/drivers/net/winbond-840.c - 1.17 linux/include/asm-ppc/highmem.h - 1.7 linux/include/asm-ppc/kmap_types.h - 1.8 linux/drivers/net/tulip/ChangeLog - 1.13 linux/drivers/usb/pegasus.h - 1.10 linux/net/irda/irnet/irnet_irda.c - 1.9 linux/net/irda/irnet/irnet.h - 1.8 linux/arch/ia64/sn/io/pci_bus_cvlink.c - 1.3 linux/include/asm-ia64/sn/pci/pcibr.h - 1.3 linux/fs/reiserfs/super.c - 1.20 linux/fs/reiserfs/journal.c - 1.24 linux/fs/reiserfs/inode.c - 1.28 linux/fs/reiserfs/fix_node.c - 1.18 linux/include/linux/reiserfs_fs_sb.h - 1.10 linux/Documentation/sound/Maestro3 - 1.2 linux/arch/cris/drivers/ide.c - 1.8 linux/arch/s390x/kernel/entry.S - 1.12 linux/drivers/s390/char/tape34xx.c - 1.7 linux/include/asm-arm/arch-sa1100/graphicsclient.h - 1.3 linux/include/asm-cris/ide.h - 1.3 linux/include/linux/hdlc.h - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx.c - 1.7 linux/drivers/net/wan/n2.c - 1.3 linux/drivers/net/wan/hdlc.c - 1.5 linux/drivers/net/wan/hd6457x.c - 1.2 linux/drivers/net/wan/hd64570.h - 1.2 linux/drivers/net/wan/dscc4.c - 1.7 linux/drivers/net/wan/c101.c - 1.3 linux/net/wanrouter/af_wanpipe.c - 1.5 linux/drivers/net/saa9730.c - 1.5 linux/drivers/s390/net/ctctty.c - 1.3 linux/include/asm-arm/proc-armv/pgalloc.h - 1.3 linux/include/linux/compiler.h - 1.4 linux/drivers/net/irda/irda-usb.c - 1.14 linux/Documentation/sound/cs46xx - 1.2 linux/drivers/net/wireless/orinoco.c - 1.7 linux/include/net/irda/irda-usb.h - 1.5 linux/drivers/mtd/nftlcore.c - 1.12 linux/drivers/mtd/nand/spia.c - 1.5 linux/drivers/mtd/devices/pmc551.c - 1.4 linux/drivers/acpi/executer/exresnte.c - 1.4 linux/drivers/acorn/char/mouse_ps2.c - 1.4 linux/Documentation/power/pci.txt - 1.2 linux/arch/ppc/mm/hashtable.S - 1.5 linux/drivers/net/irda/ali-ircc.c - 1.7 linux/drivers/net/lp486e.c - 1.5 linux/include/linux/cramfs_fs.h - 1.2 linux/scripts/cramfs/cramfsck.c - 1.2 linux/drivers/usb/storage/isd200.c - 1.5 linux/Documentation/sound/btaudio - 1.3 linux/drivers/net/irda/vlsi_ir.c - 1.9 linux/drivers/net/wan/farsync.c - 1.6 linux/drivers/net/wan/farsync.h - 1.2 linux/drivers/ide/serverworks.c - 1.6 linux/arch/arm/mach-sa1100/yopy.c - 1.4 linux/arch/arm/mach-sa1100/xp860.c - 1.4 linux/arch/arm/mach-sa1100/victor.c - 1.3 linux/arch/arm/mach-sa1100/simpad.c - 1.6 linux/arch/arm/mach-sa1100/pleb.c - 1.3 linux/arch/arm/mach-sa1100/pfs168.c - 1.5 linux/arch/arm/mach-sa1100/pangolin.c - 1.5 linux/arch/arm/mach-sa1100/omnimeter.c - 1.4 linux/arch/arm/mach-sa1100/neponset.c - 1.6 linux/arch/arm/mach-sa1100/nanoengine.c - 1.3 linux/arch/arm/mach-anakin/mm.c - 1.2 linux/arch/arm/mach-sa1100/lart.c - 1.3 linux/arch/arm/mach-sa1100/jornada720.c - 1.5 linux/arch/arm/mach-sa1100/itsy.c - 1.2 linux/arch/arm/mach-sa1100/huw_webpanel.c - 1.4 linux/arch/arm/mach-sa1100/graphicsclient.c - 1.7 linux/arch/arm/mach-sa1100/assabet.c - 1.6 linux/arch/arm/mach-sa1100/cerf.c - 1.6 linux/arch/arm/mach-sa1100/freebird.c - 1.5 linux/arch/arm/mach-sa1100/empeg.c - 1.3 linux/arch/arm/mach-sa1100/flexanet.c - 1.4 linux/arch/ppc/mm/cachemap.c - 1.4 linux/arch/ppc/mm/mmu_decl.h - 1.4 linux/arch/ppc/mm/pgtable.c - 1.4 linux/arch/ppc/mm/ppc_mmu.c - 1.3 linux/arch/ppc/mm/tlb.c - 1.3 linux/Documentation/sound/WaveArtist - 1.2 linux/drivers/ide/qd65xx.c - 1.4 linux/drivers/usb/hid-core.c - 1.10 linux/fs/jffs2/compr_zlib.c - 1.4 linux/fs/jffs2/nodelist.h - 1.4 linux/fs/jffs2/super.c - 1.8 linux/drivers/net/pcmcia/xircom_cb.c - 1.5 linux/drivers/ide/pdcraid.c - 1.9 linux/drivers/ide/hptraid.c - 1.8 linux/fs/smbfs/proto.h - 1.3 linux/fs/namespace.c - 1.15 linux/drivers/usb/serial/ir-usb.c - 1.11 linux/drivers/pcmcia/sa1100_graphicsclient.c - 1.2 linux/drivers/pcmcia/sa1100_generic.c - 1.3 linux/drivers/pcmcia/sa1100_freebird.c - 1.2 linux/drivers/pcmcia/sa1100_flexanet.c - 1.2 linux/drivers/pcmcia/sa1100_cerf.c - 1.3 linux/drivers/pcmcia/sa1100_assabet.c - 1.3 linux/drivers/pcmcia/sa1100_adsbitsy.c - 1.2 linux/drivers/pcmcia/sa1100.h - 1.2 linux/drivers/pcmcia/sa1100_graphicsmaster.c - 1.2 linux/drivers/pcmcia/sa1100_h3600.c - 1.2 linux/drivers/pcmcia/sa1100_jornada720.c - 1.2 linux/drivers/pcmcia/sa1100_neponset.c - 1.3 linux/drivers/pcmcia/sa1100_pangolin.c - 1.2 linux/drivers/pcmcia/sa1100_pfs168.c - 1.2 linux/drivers/pcmcia/sa1100_simpad.c - 1.3 linux/drivers/pcmcia/sa1100_stork.c - 1.3 linux/drivers/pcmcia/sa1100_xp860.c - 1.2 linux/drivers/pcmcia/sa1100_yopy.c - 1.2 linux/arch/arm/mach-sa1100/h3600.c - 1.6 linux/arch/arm/mach-sa1100/graphicsmaster.c - 1.6 linux/arch/arm/mach-sa1100/adsbitsy.c - 1.4 linux/drivers/message/i2o/i2o_block.c - 1.13 linux/drivers/net/8139cp.c - 1.9 linux/drivers/net/irda/sa1100_ir.c - 1.2 linux/Documentation/networking/bonding.txt - 1.2 linux/fs/intermezzo/kml_reint.c - 1.4 linux/fs/intermezzo/presto.c - 1.7 linux/include/linux/jbd.h - 1.4 linux/fs/intermezzo/vfs.c - 1.5 linux/init/do_mounts.c - 1.9 linux/drivers/net/de2104x.c - 1.5 linux/fs/xfs_dmapi/dmapi_register.c - 1.5 linux/drivers/usb/hcd.c - 1.10 linux/drivers/usb/hcd.h - 1.3 linux/drivers/usb/hcd/ehci-hcd.c - 1.7 linux/drivers/usb/hcd/ehci-hub.c - 1.5 linux/drivers/usb/hcd/ehci-q.c - 1.7 linux/drivers/usb/hcd/ehci-sched.c - 1.6 linux/drivers/usb/hcd/ehci.h - 1.2 linux/arch/arm/mm/proc-xscale.S - 1.3 linux/arch/arm/mm/minicache.c - 1.3 linux/arch/arm/def-configs/shannon - 1.2 linux/arch/arm/mach-sa1100/system3.c - 1.3 linux/include/asm-arm/arch-sa1100/system3.h - 1.2 linux/arch/arm/mach-adifcc/mm.c - 1.2 linux/arch/arm/mach-arc/mm.c - 1.2 linux/arch/arm/mach-clps711x/autcpu12.c - 1.2 linux/arch/arm/mach-clps711x/edb7211-mm.c - 1.2 linux/drivers/ide/ide-taskfile.c - 1.6 linux/fs/ext2/ext2.h - 1.4 linux/drivers/telephony/Config.help - 1.2 linux/drivers/ide/Config.help - 1.4 linux/drivers/net/Config.help - 1.4 linux/drivers/net/wan/Config.help - 1.2 linux/lib/zlib_inflate/inflate.c - 1.2 linux/drivers/pnp/pnpbios_core.c - 1.3 linux/include/linux/pnpbios.h - 1.2 linux/sound/synth/Makefile - 1.2 linux/sound/pci/ymfpci/ymfpci.c - 1.4 linux/arch/ppc/boot/ld.script - 1.2 linux/arch/ppc/boot/simple/misc-embedded.c - 1.2 linux/sound/oss/via82cxxx_audio.c - 1.3 linux/arch/ppc/iSeries/rtc.c - 1.2 linux/arch/ppc/kernel/iSeries_head.S - 1.3 linux/arch/ppc/kernel/iSeries_misc.S - 1.2 linux/arch/ppc/mm/iSeries_hashtable.c - 1.2 linux/arch/ppc/mm/iSeries_mmu.c - 1.2 linux/arch/x86_64/defconfig - 1.3 linux/arch/x86_64/kernel/entry.S - 1.2 linux/sound/isa/wavefront/wavefront_synth.c - 1.3 linux/sound/isa/sgalaxy.c - 1.4 linux/sound/isa/sb/sb_common.c - 1.3 linux/sound/isa/sb/sb8.c - 1.4 linux/sound/isa/sb/sb16_main.c - 1.3 linux/sound/isa/sb/emu8000.c - 1.3 linux/sound/isa/sb/Makefile - 1.2 linux/sound/isa/opl3sa2.c - 1.4 linux/sound/isa/gus/gus_main.c - 1.3 linux/sound/isa/es1688/es1688_lib.c - 1.3 linux/sound/isa/cs423x/cs4231_lib.c - 1.4 linux/sound/isa/azt2320.c - 1.4 linux/sound/isa/ad1848/ad1848_lib.c - 1.3 linux/sound/isa/ad1816a/ad1816a_lib.c - 1.3 linux/sound/i2c/Makefile - 1.2 linux/sound/drivers/serial-u16550.c - 1.4 linux/sound/drivers/opl3/opl3_lib.c - 1.3 linux/sound/drivers/opl3/Makefile - 1.2 linux/sound/drivers/mtpav.c - 1.4 linux/sound/drivers/mpu401/mpu401_uart.c - 1.3 linux/sound/drivers/mpu401/Makefile - 1.2 linux/sound/core/sound_oss.c - 1.3 linux/sound/core/seq/seq_virmidi.c - 1.4 linux/sound/core/seq/seq_midi_event.c - 1.3 linux/sound/core/seq/Makefile - 1.3 linux/sound/core/rtctimer.c - 1.4 linux/sound/core/oss/pcm_oss.c - 1.3 linux/sound/core/info_oss.c - 1.3 linux/sound/core/info.c - 1.4 linux/sound/core/Makefile - 1.3 linux/sound/core/Config.in - 1.4 linux/include/asm-x86_64/rwsem.h - 1.2 linux/include/sound/version.h - 1.4 linux/include/sound/pcm_params.h - 1.3 linux/include/sound/pcm.h - 1.3 linux/include/sound/info.h - 1.2 linux/include/sound/driver.h - 1.2 linux/include/sound/core.h - 1.4 linux/arch/ppc64/kernel/entry.S - 1.2 linux/drivers/net/e1000/e1000_main.c - 1.3 linux/fs/jfs/jfs_dtree.c - 1.2 linux/fs/jfs/jfs_dtree.h - 1.2 linux/arch/arm/mach-sa1100/stork.c - 1.2 From owner-linux-xfs@oss.sgi.com Fri Mar 8 15:44:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28NiZp13520 for linux-xfs-outgoing; Fri, 8 Mar 2002 15:44:35 -0800 Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28NiT913498 for ; Fri, 8 Mar 2002 15:44:29 -0800 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Mar 2002 17:44:19 -0500 Message-ID: From: Murthy Kambhampaty To: "'Stephen Lord'" , Vincent Bernat Cc: linux-xfs@oss.sgi.com Subject: RE: Intermezzo and XFS Date: Fri, 8 Mar 2002 17:44:10 -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 This question probably deserves more analysis than any of us is capable of but if "one-way replication" fulfills my application's needs, and perhaps Vincent's, then is copying an LVM snapshot of an XFS filesystem to an XFS partition on the "secondary" server a sufficient solution. Is it possible to script a cron job which: (a) mounts a snapshot, (b) tar's/untars the snapshot over using NFS/SMBmnt, (c) unmounts the snapshot. I haven't tried it yet becuase (i)I'm having other problems I want to solve first, and (ii) every time I get optimistic about its prospects, I see problems cropping up with LVM snapshots of XFS volumes. Keeping the faith, Murthy > -----Original Message----- > From: Stephen Lord [mailto:lord@sgi.com] > Sent: Friday, March 08, 2002 10:53 > To: Vincent Bernat > Cc: linux-xfs@oss.sgi.com > Subject: Re: Intermezzo and XFS > > > Vincent Bernat wrote: > > >OoO Vers la fin de l'aprhs-midi du vendredi 08 mars 2002, vers 16:27, > >Stephen Lord disait: > > > >>You can build them at the same time I think, but you cannot use > >>Intermezzo with XFS, > >>that functionality is currently broken. > >> > > > >Is it a limitation from XFS or is it a limitation from Intermezzo ? > >Just to know where to ask ! :) > > > Well, I was referring to the running the Intermezzo cache in > xfs - that > requires extensions in the filesystem. Peter Braam started work on > these at one point, but they have never been completed - so it is sort > of on the Intermezzo end. > > Steve > > > From owner-linux-xfs@oss.sgi.com Fri Mar 8 15:54:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g28NsWf13749 for linux-xfs-outgoing; Fri, 8 Mar 2002 15:54:32 -0800 Received: from web11003.mail.yahoo.com (web11003.mail.yahoo.com [216.136.131.53]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g28NsP913727 for ; Fri, 8 Mar 2002 15:54:25 -0800 Message-ID: <20020308225425.99525.qmail@web11003.mail.yahoo.com> Received: from [216.18.124.226] by web11003.mail.yahoo.com via HTTP; Fri, 08 Mar 2002 14:54:25 PST Date: Fri, 8 Mar 2002 14:54:25 -0800 (PST) From: "Mr. Fiddlehead" Subject: kmem_alloc() issues To: 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 file: fs/xfs_support/kmem.c When kmem_alloc() fails to get a kmalloc() within DEF_PRIORITY retries it will alloc the memory from __vmalloc() which will cause an Oops when the memory is kmem_free()'d if the size is <= MAX_SLAB_SIZE. Further, just before the panic, the line should read, if (!rval && (flags & KM_SLEEP)) panic() but would that be more proper as, if (!rval && (flags & (KM_SLEEP | KM_SLEEP_IO)) panic() Note that lowering MAX_SLAB_SIZE to 64K from 128K helps alleviate this problem, as well as putting in a retry instead of the panic(). On linux 2.4.16 I'm seeing this on a system with 512MB of RAM on an SMP system with 1.7TB of attached storage (LSI raid 5 via software raid 0). This helps to alleviate the pressure on the bigger slabs (size-64 and size-128). I tried lowering it to 32K but this bombed on boot when the aic7xxx was initialised. I've also inserted a wake_up_interruptible(&kswapd_wait) here before resetting shrink to 24 (instead of 6) and repeating. I've seen the system retry up to about 48 times, which is bad, but not as bad as a panic. This appears to be a problem with the page cache not releasing pages for use by the slab cache (kmalloc), since I still have about 450MB of inactive page cache available when this happens. This could also happen under VERY severe conditions in kmem_zone_alloc() and kmem_zone_zalloc() but it is very unlikely I suspect. Cheers! Mr F. ===== Mr. Fiddlehead mrfiddlehead@yahoo.co.uk Fuck Off __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ From owner-linux-xfs@oss.sgi.com Fri Mar 8 16:10:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g290A1G14199 for linux-xfs-outgoing; Fri, 8 Mar 2002 16:10:01 -0800 Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2909v914173 for ; Fri, 8 Mar 2002 16:09:57 -0800 Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45]) by mxzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g28N9qYs083434; Sat, 9 Mar 2002 00:09:52 +0100 (CET) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA16207; Sat, 9 Mar 2002 00:09:52 +0100 (CET) Date: Sat, 9 Mar 2002 00:09:52 +0100 (CET) From: Seth Mos To: Murthy Kambhampaty cc: "'Stephen Lord'" , Vincent Bernat , linux-xfs@oss.sgi.com Subject: RE: Intermezzo and XFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 8 Mar 2002, Murthy Kambhampaty wrote: > This question probably deserves more analysis than any of us is capable of > but if "one-way replication" fulfills my application's needs, and perhaps > Vincent's, then is copying an LVM snapshot of an XFS filesystem to an XFS > partition on the "secondary" server a sufficient solution. Is it possible to > script a cron job which: (a) mounts a snapshot, (b) tar's/untars the > snapshot over using NFS/SMBmnt, (c) unmounts the snapshot. I haven't tried > it yet becuase (i)I'm having other problems I want to solve first, and (ii) > every time I get optimistic about its prospects, I see problems cropping up > with LVM snapshots of XFS volumes. Seems like a job for rsync. I think this hould do what you want instead of the tar/untar. Cheers Seth From owner-linux-xfs@oss.sgi.com Sat Mar 9 04:32:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29CWv429682 for linux-xfs-outgoing; Sat, 9 Mar 2002 04:32:57 -0800 Received: from zamok.crans.org (zamok.crans.org [138.231.136.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29CWq929659 for ; Sat, 9 Mar 2002 04:32:53 -0800 Received: from lucas.loria (localhost.crans.org [127.0.0.1]) by zamok.crans.org (Postfix) with ESMTP id DC931C000AA; Sat, 9 Mar 2002 12:32:51 +0100 (CET) Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id DE748A90D; Sat, 9 Mar 2002 12:32:34 +0100 (CET) Received: by neo.loria (Postfix, from userid 500) id 624F9104D1B; Sat, 9 Mar 2002 12:32:34 +0100 (CET) To: Murthy Kambhampaty Cc: "'Stephen Lord'" , linux-xfs@oss.sgi.com Subject: Re: Intermezzo and XFS References: X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E From: Vincent Bernat In-Reply-To: (Murthy Kambhampaty's message of "Fri, 8 Mar 2002 17:44:10 -0500") Organization: Kabale Inc Date: Sat, 09 Mar 2002 12:32:33 +0100 Message-ID: Lines: 13 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OoO La nuit ayant déjŕ recouvert d'encre ce jour du vendredi 08 mars 2002, vers 23:44, Murthy Kambhampaty disait: > This question probably deserves more analysis than any of us is capable of > but if "one-way replication" fulfills my application's needs, and perhaps > Vincent's In my case, I am searching a "two-way replication", since it is to sync a laptop with my workstation. -- Use variable names that mean something. - The Elements of Programming Style (Kernighan & Plaugher) From owner-linux-xfs@oss.sgi.com Sat Mar 9 07:52:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29Fq7200999 for linux-xfs-outgoing; Sat, 9 Mar 2002 07:52:07 -0800 Received: from rediff.co.in (crimson1.rediff.co.in [203.199.37.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29Fq0900972 for ; Sat, 9 Mar 2002 07:52:01 -0800 Received: (qmail 16216 invoked by uid 506); 9 Mar 2002 14:49:50 -0000 Received: from rameshts@rediff.co.in by crimson1.rediff.co.in with qmail-scanner-1.01 (fsecure: 4.11/3190/2002-01-22/2002-01-22. 2002-01-22/. Clean. Processed in 1.018165 secs); 09 Mar 2002 14:49:50 -0000 Received: from unknown (HELO issds) (202.54.124.132) by 0 with SMTP; 9 Mar 2002 14:49:49 -0000 Message-ID: <003e01c1c779$fbb296c0$847c36ca@rediff.com> From: "Ramesh T. S." To: Subject: PARTITON problem Date: Sat, 9 Mar 2002 20:22:07 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: 0 1.6.2 500/0/N Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have a strange problem, recently i moved my disk from one machine to another which r xfs partitions i am not able to mount them, but when i run xfs_ repair i get a secondary superblock and then this error popsup "found candidate secondary superblock... superblock read failed, offset 1073741824, size 2048, ag 4294967295, rval 1 fatal error -- Input/output error" i am not able to retrieve the partition. how do i go about it ? Regards Ramesh [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat Mar 9 14:33:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29MXaM08411 for linux-xfs-outgoing; Sat, 9 Mar 2002 14:33:36 -0800 Received: from sera.symmetry.symmsys.com (usr83@[216.51.91.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29MXU908388 for ; Sat, 9 Mar 2002 14:33:32 -0800 Received: from sera (localhost [127.0.0.1]) by sera.symmetry.symmsys.com (Postfix) with ESMTP id BB257201A8A; Sat, 9 Mar 2002 16:28:32 -0500 (EST) Subject: cloning computers with xfs From: Francis Yom To: linux-xfs@oss.sgi.com Cc: Shawn Starr In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 09 Mar 2002 16:28:32 -0500 Message-Id: <1015709312.1363.15.camel@sera> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi guys, I am trying to find a way to easily clone my laptop to several other computers. It runs 2.4.19-ac1 with xfs and rmap12f. It is using Debian Unstable. I found a utility that says it will do it. It is called Mondo: http://www.microwerks.net/~hugo/ It uses afio to do the backup. Has anyone used this utility or can vouch for afio as being safe to backup xfs partitions. I know I can also use xfsdump and xfsrestore, but my problem here would be how do I create a rescue boot cdrom that uses my root partition as its basis - any thoughts on this too? Many thanks! Francis From owner-linux-xfs@oss.sgi.com Sat Mar 9 15:11:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g29NB0v09448 for linux-xfs-outgoing; Sat, 9 Mar 2002 15:11:00 -0800 Received: from vance.pcsscreston.ca (lankhaar.kootenay.com [206.108.203.230] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g29NAr909424 for ; Sat, 9 Mar 2002 15:10:54 -0800 Received: from localhost (localhost [[UNIX: localhost]]) by vance.pcsscreston.ca (8.11.6/8.11.6) id g2989Zo06671; Sat, 9 Mar 2002 15:09:35 +0700 Message-Id: <200203090809.g2989Zo06671@vance.pcsscreston.ca> Content-Type: text/plain; charset="iso-8859-1" From: Vance Lankhaar To: Francis Yom , linux-xfs@oss.sgi.com Subject: Re: cloning computers with xfs Date: Sat, 9 Mar 2002 15:09:35 +0700 X-Mailer: KMail [version 1.3.1] Cc: Shawn Starr References: <1015709312.1363.15.camel@sera> In-Reply-To: <1015709312.1363.15.camel@sera> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sunday 10 March 2002 04:28, Francis Yom wrote: >It uses afio to do the backup. Has anyone used this utility or can >vouch for afio as being safe to backup xfs partitions. I've talked to Hugo (the developer) about it, and he says that Mondo can handle xfs no problems, so I can't see that it would be a problem. Vance ------------------------------------------------------------ Vance Lankhaar vance@pcsscreston.ca PCSS Yearbook yearbook@pcsscreston.ca PCSS Computers sysadmins@pcsscreston.ca http://www.crestonbc.com/pcss/ http://www.pcsscreston.ca ------------------------------------------------------------ From owner-linux-xfs@oss.sgi.com Sat Mar 9 17:09:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A19Om12004 for linux-xfs-outgoing; Sat, 9 Mar 2002 17:09:24 -0800 Received: from smtp.de.easynet.net (smtp.de.easynet.net [194.24.208.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A19F911982 for ; Sat, 9 Mar 2002 17:09:15 -0800 Received: from h974.ibc.de.easynet.net (h974.ibc.de.easynet.net [212.224.51.206]) by smtp.de.easynet.net (Postfix) with ESMTP id 9DB4411CD0B for ; Sun, 10 Mar 2002 01:09:13 +0100 (CET) Date: Sun, 10 Mar 2002 01:09:16 +0100 From: Sebastian Ude To: linux-xfs@oss.sgi.com Subject: Random filesystem corruption Reply-To: ude@handshake.de X-Mailer: Spruce 0.7.6 for X11 w/smtpio 0.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20020310000913.9DB4411CD0B@smtp.de.easynet.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi list, I have been experiencing corrupted files on multiple XFS filesystems recently. The syndroms are that files or directories do appear in their parent directory, but are not accessible - you get a "File not found" error when trying to open them. The corruption is rather random and hard or impossible to reproduce. Today, it have been another fourty files and two directories that both contained at least ten files. They all resided in the same parent directory, but in different subdirectories. Most of the time not whole directories, but just one or two files get damaged. However, the files were fine yesterday, and I have not done any write operations to the appropiate files and documents today. Sometimes, but not neccesarily, I get a kernel oops when trying to access one of the damaged files, although it does not hang the kernel or parts of it. I am quite sure that this is not a hardware problem. I have had several files getting broken on multiple XFS filesystems that resided on different harddisks during the last months. Any ideas where the corruption might come from ? If this is really not a problem with my system setup (if I remember correctly, someone reported similar problems one month or so ago), but a bug in XFS, then it has to be fixed ASAP. Random data corruption is a really weird thing. In the past, I could fix at least the ghost directory entries using xfs_repair, but the corrupted files were lost. I wonder if there is any way to restore the affected files or directories ? Having noticed the corrupted files, I unmounted the appropiate file system read-only immediately. My setup: - ix86, single processor - Affected XFS-Kernels are perhaps, but not neccesarily 2.2.16, 2.2.17, 2.2.18 from XFS CVS. The problem may have appeared with older kernels (< 2.2.16), though - I'm afraid I can't remember. But I am sure that XFS has been working fine for at least one year with different older kernel versions on the same machine. No third parity patches applied. - All kernels were compiled using egcs 1.1.2 (2.91.66), except the very recent 2.2.18, which was compiled with gcc 3.0.4. Since the problem appeared previously, it can't be the compiler's fault. - The XFS file systems reside on different SCSI harddisks attached to an Adaptec 2940UW controller. The disks run other file systems besides XFS (ext2, reiserfs) with no problems at all. - No special mount options - just the defaults. - No special mkfs.xfs options were used when creating the filesystems - again, simply the defaults. Thanks in advance, Sebastian From owner-linux-xfs@oss.sgi.com Sat Mar 9 17:30:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A1Um612567 for linux-xfs-outgoing; Sat, 9 Mar 2002 17:30:48 -0800 Received: from banix (mail@201dial-132.kotinet.com [212.50.201.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A1UZ912518 for ; Sat, 9 Mar 2002 17:30:36 -0800 Received: from bunnyh by banix with local (Exim 3.34 #1 (Debian)) id 16jrEN-0004Mk-00 for ; Sun, 10 Mar 2002 02:30:31 +0200 Date: Sun, 10 Mar 2002 02:30:31 +0200 To: linux-xfs@oss.sgi.com Subject: Re: Random filesystem corruption Message-ID: <20020310003031.GA16729@bunny.ihme.org> References: <20020310000913.9DB4411CD0B@smtp.de.easynet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020310000913.9DB4411CD0B@smtp.de.easynet.net> User-Agent: Mutt/1.3.27i From: Juha K Kallio Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Mar 10, 2002 at 01:09:16AM +0100, Sebastian Ude wrote: > > Hi list, > > I have been experiencing corrupted files on multiple XFS filesystems > recently. The syndroms are that files or directories do appear in their > parent directory, but are not accessible - you get a "File not found" error > when trying to open them. > > The corruption is rather random and hard or impossible to reproduce. Today, > it have been another fourty files and two directories that both contained > at least ten files. They all resided in the same parent directory, but in > different subdirectories. Most of the time not whole directories, but just > one or two files get damaged. > > However, the files were fine yesterday, and I have not done any write > operations to the appropiate files and documents today. > > Sometimes, but not neccesarily, I get a kernel oops when trying to access > one of the damaged files, although it does not hang the kernel or parts of > it. > > I am quite sure that this is not a hardware problem. I have had several > files getting broken on multiple XFS filesystems that resided on different > harddisks during the last months. > > > Any ideas where the corruption might come from ? If this is really not a > problem with my system setup (if I remember correctly, someone reported > similar problems one month or so ago), but a bug in XFS, then it has to be > fixed ASAP. Random data corruption is a really weird thing. > > In the past, I could fix at least the ghost directory entries using > xfs_repair, but the corrupted files were lost. > > I wonder if there is any way to restore the affected files or directories ? > Having noticed the corrupted files, I unmounted the appropiate file system > read-only immediately. > > > My setup: > > - ix86, single processor > > - Affected XFS-Kernels are perhaps, but not neccesarily 2.2.16, 2.2.17, > 2.2.18 from XFS CVS. The problem may have appeared with older kernels > (< 2.2.16), though - I'm afraid I can't remember. But I am sure that XFS > has been working fine for at least one year with different older kernel > versions on the same machine. > > No third parity patches applied. > > - All kernels were compiled using egcs 1.1.2 (2.91.66), except the very > recent 2.2.18, which was compiled with gcc 3.0.4. Since the problem > appeared previously, it can't be the compiler's fault. > > - The XFS file systems reside on different SCSI harddisks attached to an > Adaptec 2940UW controller. The disks run other file systems besides XFS > (ext2, reiserfs) with no problems at all. > > - No special mount options - just the defaults. > > - No special mkfs.xfs options were used when creating the filesystems - > again, simply the defaults. > > > Thanks in advance, > > Sebastian > I had the same problem when restoring my files when switching from ext2 to XFS. I only had one dir broken, not the subdirectories though, files only. I was using x86 2.4.17-xfs kernel, with the release xfs patch. From owner-linux-xfs@oss.sgi.com Sat Mar 9 21:12:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A5Cf817533 for linux-xfs-outgoing; Sat, 9 Mar 2002 21:12:41 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A5Cb917508 for ; Sat, 9 Mar 2002 21:12:37 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2A5K6kw014495 for ; Sat, 9 Mar 2002 23:20:06 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA85442; Sat, 9 Mar 2002 22:12:31 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:sandeen@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA51276; Sat, 9 Mar 2002 22:12:24 -0600 (CST) Date: Sat, 9 Mar 2002 22:12:24 -0600 (CST) From: Eric Sandeen X-X-Sender: To: "Ramesh T. S." cc: Subject: Re: PARTITON problem In-Reply-To: <003e01c1c779$fbb296c0$847c36ca@rediff.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 9 Mar 2002, Ramesh T. S. wrote: > > Hi, > > I have a strange problem, recently i moved my disk from one machine to another which r xfs partitions i am not able to mount them, but when i run xfs_ repair i get a secondary superblock and then this error popsup What types of machines did you move them between? > > "found candidate secondary superblock... > superblock read failed, offset 1073741824, size 2048, ag 4294967295, rval 1 Hm, that AG number is not right, it's (2^32)-1. -Eric From owner-linux-xfs@oss.sgi.com Sat Mar 9 21:22:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A5MUA17846 for linux-xfs-outgoing; Sat, 9 Mar 2002 21:22:30 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A5MN917824 for ; Sat, 9 Mar 2002 21:22:23 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2A4MHbX009528 for ; Sat, 9 Mar 2002 20:22:18 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA84394; Sat, 9 Mar 2002 22:22:17 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:sandeen@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA02576; Sat, 9 Mar 2002 22:22:17 -0600 (CST) Date: Sat, 9 Mar 2002 22:22:17 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Sebastian Ude cc: Subject: Re: Random filesystem corruption In-Reply-To: <20020310000913.9DB4411CD0B@smtp.de.easynet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Sebastian - On Sun, 10 Mar 2002, Sebastian Ude wrote: > I have been experiencing corrupted files on multiple XFS filesystems > recently. The syndroms are that files or directories do appear in their > parent directory, but are not accessible - you get a "File not found" error > when trying to open them. Can you do an "strace" on a simple program that tries to open one of these files, and send the last bit (the failed open)? Also - are you experiencing this problem on several different machines? I assume this is local, not NFS access? > The corruption is rather random and hard or impossible to reproduce. Today, > it have been another fourty files and two directories that both contained > at least ten files. They all resided in the same parent directory, but in > different subdirectories. Most of the time not whole directories, but just > one or two files get damaged. When you have a file with this problem, though, I assume the behavior is repeatable on that file? Out of curiosity, do either the files or the directories have "international" characters in the names? > However, the files were fine yesterday, and I have not done any write > operations to the appropiate files and documents today. > > Sometimes, but not neccesarily, I get a kernel oops when trying to access > one of the damaged files, although it does not hang the kernel or parts of > it. Decoding the oops through ksymoops would be helpful. If you could enable kdb, that might help us get more information. > xfs_repair, but the corrupted files were lost. What does xfs_repair tell you now? Does it find any problems? If you go back to an older kernel (perhaps the released 1.0.2 kernel) does the problem go away? -Eric From owner-linux-xfs@oss.sgi.com Sun Mar 10 01:14:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A9Ec121917 for linux-xfs-outgoing; Sun, 10 Mar 2002 01:14:38 -0800 Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A9EX921895 for ; Sun, 10 Mar 2002 01:14:34 -0800 Received: from online.no (213-187-164-240.dd.nextgentel.com [213.187.164.240]) by mail.broadpark.no (Postfix) with ESMTP id 7B7717DE2 for ; Sun, 10 Mar 2002 09:14:23 +0100 (MET) Message-ID: <3C8B15B9.4ECAC60B@online.no> Date: Sun, 10 Mar 2002 09:13:45 +0100 From: Knut J Bjuland X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: rmap vm and xfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Are there any plans to make xfs compatible with Riel rmap vm.patch. This'll make it easier to integrate it into Redhat 8.X when it ships, I believe it'll be based on a linux 2.4.17 or later with rmap patch. From owner-linux-xfs@oss.sgi.com Sun Mar 10 01:23:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A9NHw22213 for linux-xfs-outgoing; Sun, 10 Mar 2002 01:23:17 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A9NC922189 for ; Sun, 10 Mar 2002 01:23:13 -0800 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16jyY3-0001yD-00; Sun, 10 Mar 2002 09:19:19 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "ude@handshake.de" Date: Sun, 10 Mar 2002 09:19:18 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2472) For Windows 2000 (5.0.2195;2) In-Reply-To: <20020310000913.9DB4411CD0B@smtp.de.easynet.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Random filesystem corruption Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 10 Mar 2002 01:09:16 +0100, Sebastian Ude wrote: >if I remember correctly, someone reported >similar problems one month or so ago That person could have been me -- but it turned out that our hardware RAID(!) was flawed. The manufacturer replaced and/or repaired it, and now everything it's fine. There have been CVS kernel versions as well that were simply broken WRT "international" characters. This is what Eric was referring to. But I guess that can't be an issue in your case since you mentioned you observed the problem with different kernel versions. -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sun Mar 10 01:30:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2A9UFu22401 for linux-xfs-outgoing; Sun, 10 Mar 2002 01:30:15 -0800 Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2A9LJ922133 for ; Sun, 10 Mar 2002 01:21:19 -0800 Received: from online.no (213-187-164-240.dd.nextgentel.com [213.187.164.240]) by mail.broadpark.no (Postfix) with ESMTP id 044CD7D93 for ; Sun, 10 Mar 2002 09:21:10 +0100 (MET) Message-ID: <3C8B1750.94508898@online.no> Date: Sun, 10 Mar 2002 09:20:32 +0100 From: Knut J Bjuland X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: rmap vm and xfs References: <3C8B15B9.4ECAC60B@online.no> Content-Type: multipart/mixed; boundary="------------96A7B87ECFD990228B1114CB" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------96A7B87ECFD990228B1114CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Knut J Bjuland wrote: > Are there any plans to make xfs compatible with Riel rmap vm.patch. > This'll make it easier to integrate it into Redhat 8.X when it ships, I > believe it'll be based on a linux 2.4.17 or later with rmap patch. send along a log off patching --------------96A7B87ECFD990228B1114CB Content-Type: text/plain; charset=iso-8859-1; name="2.4.19p2-rmap-12g" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="2.4.19p2-rmap-12g" # This is a BitKeeper generated patch for the following project: # Project Name: Long-term Linux VM development # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet linux-2.4.19-pre2 -> 1.207 # include/asm-sparc64/pgtable.h 1.14.1.1 -> 1.16 # fs/inode.c 1.32 -> 1.33 # drivers/block/ll_rw_blk.c 1.27.1.2 -> 1.30 # include/linux/swapctl.h 1.2 -> 1.7 # include/linux/mmzone.h 1.6.1.1 -> 1.15 # fs/proc/proc_misc.c 1.11 -> 1.14 # include/linux/sched.h 1.20.1.4 -> 1.26 # drivers/char/agp/agpgart_be.c 1.20.1.3 -> 1.25 # include/linux/swap.h 1.31 -> 1.41 # include/asm-s390/pgtable.h 1.4.1.1 -> 1.6 # mm/slab.c 1.12 -> 1.13 # mm/vmscan.c 1.53.1.4 -> 1.97 # fs/dquot.c 1.16 -> 1.17 # drivers/char/drm/i810_dma.c 1.5.1.1 -> 1.10 # mm/mmap.c 1.18.1.2 -> 1.21 # include/asm-i386/pgtable.h 1.4.1.1 -> 1.7 # fs/dcache.c 1.15.1.1 -> 1.17 # include/asm-s390x/pgtable.h 1.4.1.1 -> 1.6 # include/asm-sparc/pgtable.h 1.4.1.1 -> 1.6 # include/asm-sh/pgtable.h 1.6.1.1 -> 1.8 # include/asm-arm/pgtable.h 1.5.1.1 -> 1.7 # mm/memory.c 1.41.1.6 -> 1.49 # mm/mremap.c 1.5 -> 1.6 # fs/buffer.c 1.44.1.11 -> 1.55 # include/linux/mm.h 1.29.1.6 -> 1.46 # mm/filemap.c 1.46.1.8 -> 1.54 # mm/bootmem.c 1.6 -> 1.7 # mm/page_alloc.c 1.39.1.2 -> 1.62 # kernel/sysctl.c 1.13.1.3 -> 1.17 # include/asm-i386/pgalloc.h 1.8 -> 1.11 # arch/arm/mm/mm-armv.c 1.4 -> 1.5 # include/asm-mips/pgtable.h 1.3.1.1 -> 1.5 # include/linux/slab.h 1.8 -> 1.9 # mm/swap.c 1.16 -> 1.24 # mm/swap_state.c 1.17 -> 1.20 # include/linux/fs.h 1.49.1.5 -> 1.53 # include/asm-alpha/pgtable.h 1.7.1.1 -> 1.9 # include/linux/pagemap.h 1.15.1.2 -> 1.19 # mm/oom_kill.c 1.9 -> 1.12 # kernel/ksyms.c 1.40.1.7 -> 1.46 # Makefile 1.135.1.16 -> 1.144 # kernel/fork.c 1.18.1.2 -> 1.22 # kernel/sys.c 1.8.1.1 -> 1.10 # mm/Makefile 1.3.1.2 -> 1.7 # include/asm-mips64/pgtable.h 1.3.1.1 -> 1.5 # arch/i386/kernel/setup.c 1.32.1.3 -> 1.35 # mm/swapfile.c 1.20.1.2 -> 1.23 # include/linux/elevator.h 1.4 -> 1.5 # include/linux/sysctl.h 1.10.1.2 -> 1.13 # drivers/block/elevator.c 1.5 -> 1.7 # fs/exec.c 1.17.1.2 -> 1.19 # include/asm-ia64/pgtable.h 1.6.1.1 -> 1.8 # include/asm-cris/pgtable.h 1.4.1.2 -> 1.7 # include/asm-parisc/pgtable.h 1.2.1.1 -> 1.4 # arch/i386/config.in 1.21.1.3 -> 1.24 # include/asm-ppc/pgtable.h 1.7.1.1 -> 1.9 # (new) -> 1.15 include/linux/mm_inline.h # (new) -> 1.1 include/asm-arm/rmap.h # (new) -> 1.1 include/asm-parisc/rmap.h # (new) -> 1.1 include/asm-s390/rmap.h # (new) -> 1.1 include/asm-mips/rmap.h # (new) -> 1.1 include/asm-ia64/rmap.h # (new) -> 1.1 include/asm-s390x/rmap.h # (new) -> 1.14 mm/rmap.c # (new) -> 1.2 include/asm-cris/rmap.h # (new) -> 1.1 include/asm-sparc/rmap.h # (new) -> 1.1 include/asm-arm/proc-armv/rmap.h # (new) -> 1.9 mm/TODO # (new) -> 1.1 include/asm-mips64/rmap.h # (new) -> 1.34 Changelog.rmap # (new) -> 1.1 include/asm-alpha/rmap.h # (new) -> 1.2 include/asm-generic/rmap.h # (new) -> 1.2 include/asm-i386/rmap.h # (new) -> 1.1 include/asm-sparc64/rmap.h # (new) -> 1.2 include/asm-ppc/rmap.h # (new) -> 1.1 include/asm-m68k/rmap.h # (new) -> 1.1 include/asm-sh/rmap.h # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/02/28 marcelo@conectiva.com.br 1.130.1.29 # linux-2.4.19-pre2: # - -ac merge (Alan Cox) # - Huge MIPS/MIPS64 merge (Ralf Baechle) # - IA64 update (David Mosberger) # - PPC update (Tom Rini) # - Shrink struct page (Rik van Riel) # - QNX4 update (now its able to mount QNX 6.1 fses) (Anders Larsen) # - Make max_map_count sysctl configurable (Christoph Hellwig) # - matroxfb update (Petr Vandrovec) # - ymfpci update (Pete Zaitcev) # - LVM update (Heinz J . Mauelshagen) # - btaudio driver update (Gerd Knorr) # - bttv update (Gerd Knorr) # - Out of line code cleanup (Keith Owens) # - Add watchdog API documentation (Christer Weinigel) # - Rivafb update (Ani Joshi) # - Enable PCI buses above quad0 on NUMA-Q (Martin J. Bligh) # - Fix PIIX IDE slave PCI timings (Dave Bogdanoff) # - Make PLIP work again (Tim Waugh) # - Remove unecessary printk from lp.c (Tim Waugh) # - Make parport_daisy_select work for ECP/EPP modes (Max Vorobiev) # - Support O_NONBLOCK on lp/ppdev correctly (Tim Waugh) # - Add PCI card hooks to parport (Tim Waugh) # - Compaq cciss driver fixes (Stephen Cameron) # - VFS cleanups and fixes (Alexander Viro) # - USB update (including USB 2.0 support) (Greg KH) # - More jiffies compare cleanups (Tim Schmielau) # - PCI hotplug update (Greg KH) # - bluesmoke fixes (Dave Jones) # - Fix off-by-one in ide-scsi (John Fremlin) # - Fix warnings in make xconfig (René Scharfe) # - Make x86 MCE a configure option (Paul Gortmaker) # - Small ramdisk fixes (Christoph Hellwig) # - Add missing atime update to pipe code (Christoph Hellwig) # - Serialize microcode access (Tigran Aivazian) # - AMD Elan handling on serial.c (Robert Schwebel) # -------------------------------------------- # 02/02/28 riel@imladris.surriel.com 1.205 # merged # -------------------------------------------- # 02/02/28 riel@imladris.surriel.com 1.206 # remove obsolete code # -------------------------------------------- # 02/02/28 riel@imladris.surriel.com 1.207 # some more merging cleanups # -------------------------------------------- # diff -Nru a/Changelog.rmap b/Changelog.rmap --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/Changelog.rmap Fri Mar 1 18:19:44 2002 @@ -0,0 +1,142 @@ +The seventh maintenance release of the 12th version of the reverse +mapping based VM is now available. +This is an attempt at making a more robust and flexible VM +subsystem, while cleaning up a lot of code at the same time. +The patch is available from: + + http://surriel.com/patches/2.4/2.4.19p1-rmap-12g +and http://linuxvm.bkbits.net/ + + +My big TODO items for a next release are: + - page launder + + - drop pte quicklist in anticipation of pte-highmem (me) + - replace andrea's highmem emulation by ingo's one (me) +rmap 12g: + - port to armv architecture (David Woodhouse) + - NUMA fix to zone_table initialisation (Samuel Ortiz) + - remove init_page_count (David Miller) +rmap 12f: + - for_each_pgdat macro (William Lee Irwin) + - put back EXPORT(__find_get_page) for modular rd (me) + - make bdflush and kswapd actually start queued disk IO (me) +rmap 12e + - RSS limit fix, the limit can be 0 for some reason (me) + - clean up for_each_zone define to not need pgdata_t (William Lee Irwin) + - fix i810_dma bug introduced with page->wait removal (William Lee Irwin) +rmap 12d: + - fix compiler warning in rmap.c (Roger Larsson) + - read latency improvement (read-latency2) (Andrew Morton) +rmap 12c: + - fix small balancing bug in page_launder_zone (Nick Piggin) + - wakeup_kswapd / wakeup_memwaiters code fix (Arjan van de Ven) + - improve RSS limit enforcement (me) +rmap 12b: + - highmem emulation (for debugging purposes) (Andrea Arcangeli) + - ulimit RSS enforcement when memory gets tight (me) + - sparc64 page->virtual quickfix (Greg Procunier) +rmap 12a: + - fix the compile warning in buffer.c (me) + - fix divide-by-zero on highmem initialisation DOH! (me) + - remove the pgd quicklist (suspicious ...) (DaveM, me) +rmap 12: + - keep some extra free memory on large machines (Arjan van de Ven, me) + - higher-order allocation bugfix (Adrian Drzewiecki) + - nr_free_buffer_pages() returns inactive + free mem (me) + - pages from unused objects directly to inactive_clean (me) + - use fast pte quicklists on non-pae machines (Andrea Arcangeli) + - remove sleep_on from wakeup_kswapd (Arjan van de Ven) + - page waitqueue cleanup (Christoph Hellwig) +rmap 11c: + - oom_kill race locking fix (Andres Salomon) + - elevator improvement (Andrew Morton) + - dirty buffer writeout speedup (hopefully ;)) (me) + - small documentation updates (me) + - page_launder() never does synchronous IO, kswapd + and the processes calling it sleep on higher level (me) + - deadlock fix in touch_page() (me) +rmap 11b: + - added low latency reschedule points in vmscan.c (me) + - make i810_dma.c include mm_inline.h too (William Lee Irwin) + - wake up kswapd sleeper tasks on OOM kill so the + killed task can continue on its way out (me) + - tune page allocation sleep point a little (me) +rmap 11a: + - don't let refill_inactive() progress count for OOM (me) + - after an OOM kill, wait 5 seconds for the next kill (me) + - agpgart_be fix for hashed waitqueues (William Lee Irwin) +rmap 11: + - fix stupid logic inversion bug in wakeup_kswapd() (Andrew Morton) + - fix it again in the morning (me) + - add #ifdef BROKEN_PPC_PTE_ALLOC_ONE to rmap.h, it + seems PPC calls pte_alloc() before mem_map[] init (me) + - disable the debugging code in rmap.c ... the code + is working and people are running benchmarks (me) + - let the slab cache shrink functions return a value + to help prevent early OOM killing (Ed Tomlinson) + - also, don't call the OOM code if we have enough + free pages (me) + - move the call to lru_cache_del into __free_pages_ok (Ben LaHaise) + - replace the per-page waitqueue with a hashed + waitqueue, reduces size of struct page from 64 + bytes to 52 bytes (48 bytes on non-highmem machines) (William Lee Irwin) +rmap 10: + - fix the livelock for real (yeah right), turned out + to be a stupid bug in page_launder_zone() (me) + - to make sure the VM subsystem doesn't monopolise + the CPU, let kswapd and some apps sleep a bit under + heavy stress situations (me) + - let __GFP_HIGH allocations dig a little bit deeper + into the free page pool, the SCSI layer seems fragile (me) +rmap 9: + - improve comments all over the place (Michael Cohen) + - don't panic if page_remove_rmap() cannot find the + rmap in question, it's possible that the memory was + PG_reserved and belonging to a driver, but the driver + exited and cleared the PG_reserved bit (me) + - fix the VM livelock by replacing > by >= in a few + critical places in the pageout code (me) + - treat the reclaiming of an inactive_clean page like + allocating a new page, calling try_to_free_pages() + and/or fixup_freespace() if required (me) + - when low on memory, don't make things worse by + doing swapin_readahead (me) +rmap 8: + - add ANY_ZONE to the balancing functions to improve + kswapd's balancing a bit (me) + - regularize some of the maximum loop bounds in + vmscan.c for cosmetic purposes (William Lee Irwin) + - move page_address() to architecture-independent + code, now the removal of page->virtual is portable (William Lee Irwin) + - speed up free_area_init_core() by doing a single + pass over the pages and not using atomic ops (William Lee Irwin) + - documented the buddy allocator in page_alloc.c (William Lee Irwin) +rmap 7: + - clean up and document vmscan.c (me) + - reduce size of page struct, part one (William Lee Irwin) + - add rmap.h for other archs (untested, not for ARM) (me) +rmap 6: + - make the active and inactive_dirty list per zone, + this is finally possible because we can free pages + based on their physical address (William Lee Irwin) + - cleaned up William's code a bit (me) + - turn some defines into inlines and move those to + mm_inline.h (the includes are a mess ...) (me) + - improve the VM balancing a bit (me) + - add back inactive_target to /proc/meminfo (me) +rmap 5: + - fixed recursive buglet, introduced by directly + editing the patch for making rmap 4 ;))) (me) +rmap 4: + - look at the referenced bits in page tables (me) +rmap 3: + - forgot one FASTCALL definition (me) +rmap 2: + - teach try_to_unmap_one() about mremap() (me) + - don't assign swap space to pages with buffers (me) + - make the rmap.c functions FASTCALL / inline (me) +rmap 1: + - fix the swap leak in rmap 0 (Dave McCracken) +rmap 0: + - port of reverse mapping VM to 2.4.16 (me) diff -Nru a/Makefile b/Makefile --- a/Makefile Fri Mar 1 18:19:44 2002 +++ b/Makefile Fri Mar 1 18:19:44 2002 @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 19 -EXTRAVERSION = -pre2 +EXTRAVERSION = -pre2-rmap12g KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) diff -Nru a/arch/arm/mm/mm-armv.c b/arch/arm/mm/mm-armv.c --- a/arch/arm/mm/mm-armv.c Fri Mar 1 18:19:44 2002 +++ b/arch/arm/mm/mm-armv.c Fri Mar 1 18:19:44 2002 @@ -19,6 +19,7 @@ #include #include #include +#include #include @@ -457,6 +458,7 @@ * cache implementation. */ kmem_cache_t *pte_cache; +kmem_cache_t *pte_rmap_cache; /* * The constructor gets called for each object within the cache when the @@ -467,6 +469,22 @@ { unsigned long block = (unsigned long)pte; + if (!(block & 2048)) { + /* First object of two in a page - allocate the + pte_rmap_info to go with them */ + + struct page * page = virt_to_page(pte); + + if (flags & SLAB_CTOR_ATOMIC) + BUG(); + + page->mapping = kmem_cache_alloc(pte_rmap_cache, GFP_KERNEL); + if (!page->mapping) { + printk(KERN_CRIT "pte_rmap_cache alloc failed. Oops. Slab constructors need to be allowed to fail\n"); + /* return -ENOMEM; */ + BUG(); + } + } if (block & 2047) BUG(); @@ -475,11 +493,32 @@ PTRS_PER_PTE * sizeof(pte_t), 0); } +static void pte_cache_dtor(void *pte, kmem_cache_t *cache, unsigned long flags) +{ + unsigned long block = (unsigned long)pte; + + if (!(block & 2048)) { + /* First object of two in a page - free the + pte_rmap_info that was associated with them */ + + struct page * page = virt_to_page(pte); + + kmem_cache_free(pte_rmap_cache, page->mapping); + page->mapping = NULL; + } +} + void __init pgtable_cache_init(void) { + pte_rmap_cache = kmem_cache_create("pte-rmap-cache", + 2 * sizeof(struct arm_rmap_info), 0, 0, + NULL, NULL); + if (!pte_rmap_cache) + BUG(); + pte_cache = kmem_cache_create("pte-cache", 2 * PTRS_PER_PTE * sizeof(pte_t), 0, 0, - pte_cache_ctor, NULL); + pte_cache_ctor, pte_cache_dtor); if (!pte_cache) BUG(); } diff -Nru a/drivers/block/elevator.c b/drivers/block/elevator.c --- a/drivers/block/elevator.c Fri Mar 1 18:19:44 2002 +++ b/drivers/block/elevator.c Fri Mar 1 18:19:44 2002 @@ -80,30 +80,38 @@ struct buffer_head *bh, int rw, int max_sectors) { - struct list_head *entry = &q->queue_head; - unsigned int count = bh->b_size >> 9, ret = ELEVATOR_NO_MERGE; - + struct list_head *entry; + unsigned int count = bh->b_size >> 9; + unsigned int ret = ELEVATOR_NO_MERGE; + int merge_only = 0; + const int max_bomb_segments = q->elevator.max_bomb_segments; + + entry = &q->queue_head; while ((entry = entry->prev) != head) { struct request *__rq = blkdev_entry_to_request(entry); - /* - * simply "aging" of requests in queue - */ - if (__rq->elevator_sequence-- <= 0) - break; - + if (__rq->elevator_sequence-- <= 0) { + /* + * OK, we've exceeded someone's latency limit. + * But we still continue to look for merges, + * because they're so much better than seeks. + */ + merge_only = 1; + } if (__rq->waiting) continue; if (__rq->rq_dev != bh->b_rdev) continue; - if (!*req && bh_rq_in_between(bh, __rq, &q->queue_head)) + if (!*req && !merge_only && + bh_rq_in_between(bh, __rq, &q->queue_head)) { *req = __rq; + } if (__rq->cmd != rw) continue; if (__rq->nr_sectors + count > max_sectors) continue; if (__rq->elevator_sequence < count) - break; + merge_only = 1; if (__rq->sector + __rq->nr_sectors == bh->b_rsector) { ret = ELEVATOR_BACK_MERGE; *req = __rq; @@ -116,6 +124,56 @@ } } + /* + * If we failed to merge a read anywhere in the request + * queue, we really don't want to place it at the end + * of the list, behind lots of writes. So place it near + * the front. + * + * We don't want to place it in front of _all_ writes: that + * would create lots of seeking, and isn't tunable. + * We try to avoid promoting this read in front of existing + * reads. + * + * max_bomb_sectors becomes the maximum number of write + * requests which we allow to remain in place in front of + * a newly introduced read. We weight things a little bit, + * so large writes are more expensive than small ones, but it's + * requests which count, not sectors. + */ + if (max_bomb_segments && rw == READ && ret == ELEVATOR_NO_MERGE) { + int cur_latency = 0; + struct request * const cur_request = *req; + + entry = head->next; + while (entry != &q->queue_head) { + struct request *__rq; + + if (entry == &q->queue_head) + BUG(); + if (entry == q->queue_head.next && + q->head_active && !q->plugged) + BUG(); + __rq = blkdev_entry_to_request(entry); + + if (__rq == cur_request) { + /* + * This is where the old algorithm placed it. + * There's no point pushing it further back, + * so leave it here, in sorted order. + */ + break; + } + if (__rq->cmd == WRITE) { + cur_latency += 1 + __rq->nr_sectors / 64; + if (cur_latency >= max_bomb_segments) { + *req = __rq; + break; + } + } + entry = entry->next; + } + } return ret; } @@ -188,7 +246,7 @@ output.queue_ID = elevator->queue_ID; output.read_latency = elevator->read_latency; output.write_latency = elevator->write_latency; - output.max_bomb_segments = 0; + output.max_bomb_segments = elevator->max_bomb_segments; if (copy_to_user(arg, &output, sizeof(blkelv_ioctl_arg_t))) return -EFAULT; @@ -207,9 +265,12 @@ return -EINVAL; if (input.write_latency < 0) return -EINVAL; + if (input.max_bomb_segments < 0) + return -EINVAL; elevator->read_latency = input.read_latency; elevator->write_latency = input.write_latency; + elevator->max_bomb_segments = input.max_bomb_segments; return 0; } diff -Nru a/drivers/block/ll_rw_blk.c b/drivers/block/ll_rw_blk.c --- a/drivers/block/ll_rw_blk.c Fri Mar 1 18:19:44 2002 +++ b/drivers/block/ll_rw_blk.c Fri Mar 1 18:19:44 2002 @@ -1176,9 +1176,11 @@ * Free request slots per queue. * (Half for reads, half for writes) */ - queue_nr_requests = 64; - if (total_ram > MB(32)) - queue_nr_requests = 128; + queue_nr_requests = (total_ram >> 9) & ~15; /* One per half-megabyte */ + if (queue_nr_requests < 32) + queue_nr_requests = 32; + if (queue_nr_requests > 1024) + queue_nr_requests = 1024; /* * Batch frees according to queue length diff -Nru a/fs/buffer.c b/fs/buffer.c --- a/fs/buffer.c Fri Mar 1 18:19:44 2002 +++ b/fs/buffer.c Fri Mar 1 18:19:44 2002 @@ -47,6 +47,7 @@ #include #include #include +#include #include #include @@ -729,11 +730,9 @@ static void free_more_memory(void) { - zone_t * zone = contig_page_data.node_zonelists[GFP_NOFS & GFP_ZONEMASK].zones[0]; - balance_dirty(); wakeup_bdflush(); - try_to_free_pages(zone, GFP_NOFS, 0); + try_to_free_pages(GFP_NOFS); run_task_queue(&tq_disk); current->policy |= SCHED_YIELD; __set_current_state(TASK_RUNNING); @@ -1046,7 +1045,6 @@ unsigned long dirty, tot, hard_dirty_limit, soft_dirty_limit; dirty = size_buffers_type[BUF_DIRTY] >> PAGE_SHIFT; - dirty += size_buffers_type[BUF_LOCKED] >> PAGE_SHIFT; tot = nr_free_buffer_pages(); dirty *= 100; @@ -1078,18 +1076,17 @@ return; /* If we're getting into imbalance, start write-out */ - spin_lock(&lru_list_lock); - write_some_buffers(NODEV); + wakeup_bdflush(); /* * And if we're _really_ out of balance, wait for - * some of the dirty/locked buffers ourselves and - * start bdflush. + * some of the dirty/locked buffers ourselves. * This will throttle heavy writers. */ if (state > 0) { + spin_lock(&lru_list_lock); + write_some_buffers(NODEV); wait_for_some_buffers(NODEV); - wakeup_bdflush(); } } @@ -2592,10 +2589,9 @@ return 1; } -static int sync_page_buffers(struct buffer_head *head) +static void sync_page_buffers(struct buffer_head *head) { struct buffer_head * bh = head; - int tryagain = 0; do { if (!buffer_dirty(bh) && !buffer_locked(bh)) @@ -2605,15 +2601,11 @@ if (!test_and_set_bit(BH_Wait_IO, &bh->b_state)) continue; - /* Second time through we start actively writing out.. */ - if (test_and_set_bit(BH_Lock, &bh->b_state)) { - if (!test_bit(BH_launder, &bh->b_state)) - continue; - wait_on_buffer(bh); - tryagain = 1; + /* If we cannot lock the buffer just skip it. */ + if (test_and_set_bit(BH_Lock, &bh->b_state)) continue; - } + /* Second time through we start actively writing out.. */ if (!atomic_set_buffer_clean(bh)) { unlock_buffer(bh); continue; @@ -2624,10 +2616,9 @@ set_bit(BH_launder, &bh->b_state); bh->b_end_io = end_buffer_io_sync; submit_bh(WRITE, bh); - tryagain = 0; } while ((bh = bh->b_this_page) != head); - return tryagain; + return; } /* @@ -2651,7 +2642,6 @@ { struct buffer_head * tmp, * bh = page->buffers; -cleaned_buffers_try_again: spin_lock(&lru_list_lock); write_lock(&hash_table_lock); tmp = bh; @@ -2694,15 +2684,9 @@ write_unlock(&hash_table_lock); spin_unlock(&lru_list_lock); gfp_mask = pf_gfp_mask(gfp_mask); - if (gfp_mask & __GFP_IO) { - if ((gfp_mask & __GFP_HIGHIO) || !PageHighMem(page)) { - if (sync_page_buffers(bh)) { - /* no IO or waiting next time */ - gfp_mask = 0; - goto cleaned_buffers_try_again; - } - } - } + if ((gfp_mask & __GFP_IO) && + ((gfp_mask & __GFP_HIGHIO) || !PageHighMem(page))) + sync_page_buffers(bh); if (balance_dirty_state() >= 0) wakeup_bdflush(); return 0; @@ -2951,7 +2935,7 @@ spin_lock(&lru_list_lock); if (!write_some_buffers(NODEV) || balance_dirty_state() < 0) { - wait_for_some_buffers(NODEV); + run_task_queue(&tq_disk); interruptible_sleep_on(&bdflush_wait); } } @@ -2982,7 +2966,6 @@ complete((struct completion *)startup); for (;;) { - wait_for_some_buffers(NODEV); /* update interval */ interval = bdf_prm.b_un.interval; @@ -3011,6 +2994,7 @@ printk(KERN_DEBUG "kupdate() activated...\n"); #endif sync_old_buffers(); + run_task_queue(&tq_disk); } } diff -Nru a/fs/dcache.c b/fs/dcache.c --- a/fs/dcache.c Fri Mar 1 18:19:44 2002 +++ b/fs/dcache.c Fri Mar 1 18:19:44 2002 @@ -568,8 +568,7 @@ count = dentry_stat.nr_unused / priority; prune_dcache(count); - kmem_cache_shrink(dentry_cache); - return 0; + return kmem_cache_shrink_nr(dentry_cache); } #define NAME_ALLOC_LEN(len) ((len+16) & ~15) diff -Nru a/fs/dquot.c b/fs/dquot.c --- a/fs/dquot.c Fri Mar 1 18:19:44 2002 +++ b/fs/dquot.c Fri Mar 1 18:19:44 2002 @@ -413,8 +413,7 @@ lock_kernel(); prune_dqcache(nr_free_dquots / (priority + 1)); unlock_kernel(); - kmem_cache_shrink(dquot_cachep); - return 0; + return kmem_cache_shrink_nr(dquot_cachep); } /* NOTE: If you change this function please check whether dqput_blocks() works right... */ diff -Nru a/fs/exec.c b/fs/exec.c --- a/fs/exec.c Fri Mar 1 18:19:44 2002 +++ b/fs/exec.c Fri Mar 1 18:19:44 2002 @@ -35,6 +35,7 @@ #include #include #include +#include #define __NO_VERSION__ #include @@ -279,6 +280,7 @@ flush_dcache_page(page); flush_page_to_ram(page); set_pte(pte, pte_mkdirty(pte_mkwrite(mk_pte(page, PAGE_COPY)))); + page_add_rmap(page, pte); tsk->mm->rss++; spin_unlock(&tsk->mm->page_table_lock); diff -Nru a/fs/inode.c b/fs/inode.c --- a/fs/inode.c Fri Mar 1 18:19:44 2002 +++ b/fs/inode.c Fri Mar 1 18:19:44 2002 @@ -725,8 +725,7 @@ count = inodes_stat.nr_unused / priority; prune_icache(count); - kmem_cache_shrink(inode_cachep); - return 0; + return kmem_cache_shrink_nr(inode_cachep); } /* diff -Nru a/fs/proc/proc_misc.c b/fs/proc/proc_misc.c --- a/fs/proc/proc_misc.c Fri Mar 1 18:19:44 2002 +++ b/fs/proc/proc_misc.c Fri Mar 1 18:19:44 2002 @@ -36,6 +36,7 @@ #include #include #include +#include #include #include @@ -164,7 +165,9 @@ "Cached: %8lu kB\n" "SwapCached: %8lu kB\n" "Active: %8u kB\n" - "Inactive: %8u kB\n" + "Inact_dirty: %8u kB\n" + "Inact_clean: %8u kB\n" + "Inact_target: %8lu kB\n" "HighTotal: %8lu kB\n" "HighFree: %8lu kB\n" "LowTotal: %8lu kB\n" @@ -178,7 +181,9 @@ K(pg_size - swapper_space.nrpages), K(swapper_space.nrpages), K(nr_active_pages), - K(nr_inactive_pages), + K(nr_inactive_dirty_pages), + K(nr_inactive_clean_pages), + K(inactive_target()), K(i.totalhigh), K(i.freehigh), K(i.totalram-i.totalhigh), diff -Nru a/include/asm-alpha/rmap.h b/include/asm-alpha/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-alpha/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,7 @@ +#ifndef _ALPHA_RMAP_H +#define _ALPHA_RMAP_H + +/* nothing to see, move along */ +#include + +#endif diff -Nru a/include/asm-arm/proc-armv/rmap.h b/include/asm-arm/proc-armv/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-arm/proc-armv/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,72 @@ +#ifndef _ARMV_RMAP_H +#define _ARMV_RMAP_H +/* + * linux/include/asm-arm/proc-armv/rmap.h + * + * Architecture dependant parts of the reverse mapping code, + * + * We use the struct page of the page table page to find a pointer + * to an array of two 'struct arm_rmap_info's, one for each of the + * two page tables in each page. + * + * - rmi->mm points to the process' mm_struct + * - rmi->index has the high bits of the address + * - the lower bits of the address are calculated from the + * offset of the page table entry within the page table page + */ +#include + +struct arm_rmap_info { + struct mm_struct *mm; + unsigned long index; +}; + +static inline void pgtable_add_rmap(pte_t * ptep, struct mm_struct * mm, unsigned long address) +{ + struct page * page = virt_to_page(ptep); + struct arm_rmap_info *rmi = (void *)page->mapping; + + if (((unsigned long)ptep)&2048) + rmi++; + + rmi->mm = mm; + rmi->index = address & ~((PTRS_PER_PTE * PAGE_SIZE) - 1); +} + +static inline void pgtable_remove_rmap(pte_t * ptep) +{ + struct page * page = virt_to_page(ptep); + struct arm_rmap_info *rmi = (void *)page->mapping; + + if (((unsigned long)ptep)&2048) + rmi++; + + rmi->mm = NULL; + rmi->index = 0; +} + +static inline struct mm_struct * ptep_to_mm(pte_t * ptep) +{ + struct page * page = virt_to_page(ptep); + struct arm_rmap_info *rmi = (void *)page->mapping; + + if (((unsigned long)ptep)&2048) + rmi++; + + return rmi->mm; +} + +static inline unsigned long ptep_to_address(pte_t * ptep) +{ + struct page * page = virt_to_page(ptep); + struct arm_rmap_info *rmi = (void *)page->mapping; + unsigned long low_bits; + + if (((unsigned long)ptep)&2048) + rmi++; + + low_bits = ((unsigned long)ptep & ~PAGE_MASK) * PTRS_PER_PTE; + return rmi->index + low_bits; +} + +#endif /* _ARMV_RMAP_H */ diff -Nru a/include/asm-arm/rmap.h b/include/asm-arm/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-arm/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,6 @@ +#ifndef _ARM_RMAP_H +#define _ARM_RMAP_H + +#include + +#endif /* _ARM_RMAP_H */ diff -Nru a/include/asm-cris/rmap.h b/include/asm-cris/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-cris/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,7 @@ +#ifndef _CRIS_RMAP_H +#define _CRIS_RMAP_H + +/* nothing to see, move along :) */ +#include + +#endif diff -Nru a/include/asm-generic/rmap.h b/include/asm-generic/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-generic/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,57 @@ +#ifndef _GENERIC_RMAP_H +#define _GENERIC_RMAP_H +/* + * linux/include/asm-generic/rmap.h + * + * Architecture dependant parts of the reverse mapping code, + * this version should work for most architectures with a + * 'normal' page table layout. + * + * We use the struct page of the page table page to find out + * the process and full address of a page table entry: + * - page->mapping points to the process' mm_struct + * - page->index has the high bits of the address + * - the lower bits of the address are calculated from the + * offset of the page table entry within the page table page + */ +#include + +static inline void pgtable_add_rmap(pte_t * ptep, struct mm_struct * mm, unsigned long address) +{ + struct page * page = virt_to_page(ptep); +#ifdef BROKEN_PPC_PTE_ALLOC_ONE + /* OK, so PPC calls pte_alloc() before mem_map[] is setup ... ;( */ + extern int mem_init_done; + + if (!mem_init_done) + return; +#endif + page->mapping = (void *)mm; + page->index = address & ~((PTRS_PER_PTE * PAGE_SIZE) - 1); +} + +static inline void pgtable_remove_rmap(pte_t * ptep) +{ + struct page * page = virt_to_page(ptep); + + page->mapping = NULL; + page->index = 0; +} + +static inline struct mm_struct * ptep_to_mm(pte_t * ptep) +{ + struct page * page = virt_to_page(ptep); + + return (struct mm_struct *) page->mapping; +} + +static inline unsigned long ptep_to_address(pte_t * ptep) +{ + struct page * page = virt_to_page(ptep); + unsigned long low_bits; + + low_bits = ((unsigned long)ptep & ~PAGE_MASK) * PTRS_PER_PTE; + return page->index + low_bits; +} + +#endif /* _GENERIC_RMAP_H */ diff -Nru a/include/asm-i386/rmap.h b/include/asm-i386/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-i386/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,7 @@ +#ifndef _I386_RMAP_H +#define _I386_RMAP_H + +/* nothing to see, move along */ +#include + +#endif diff -Nru a/include/asm-ia64/rmap.h b/include/asm-ia64/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-ia64/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,7 @@ +#ifndef _IA64_RMAP_H +#define _IA64_RMAP_H + +/* nothing to see, move along */ +#include + +#endif diff -Nru a/include/asm-m68k/rmap.h b/include/asm-m68k/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-m68k/rmap.h Fri Mar 1 18:19:45 2002 @@ -0,0 +1,7 @@ +#ifndef _M86K_RMAP_H +#define _M86K_RMAP_H + +/* nothing to see, move along */ +#include + +#endif diff -Nru a/include/asm-mips/rmap.h b/include/asm-mips/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-mips/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,7 @@ +#ifndef _MIPS_RMAP_H +#define _MIPS_RMAP_H + +/* nothing to see, move along */ +#include + +#endif diff -Nru a/include/asm-mips64/rmap.h b/include/asm-mips64/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-mips64/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,7 @@ +#ifndef _MIPS64_RMAP_H +#define _MIPS64_RMAP_H + +/* nothing to see, move along */ +#include + +#endif diff -Nru a/include/asm-parisc/rmap.h b/include/asm-parisc/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-parisc/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,7 @@ +#ifndef _PARISC_RMAP_H +#define _PARISC_RMAP_H + +/* nothing to see, move along */ +#include + +#endif diff -Nru a/include/asm-ppc/rmap.h b/include/asm-ppc/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-ppc/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,9 @@ +#ifndef _PPC_RMAP_H +#define _PPC_RMAP_H + +/* PPC calls pte_alloc() before mem_map[] is setup ... */ +#define BROKEN_PPC_PTE_ALLOC_ONE + +#include + +#endif diff -Nru a/include/asm-s390/rmap.h b/include/asm-s390/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-s390/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,7 @@ +#ifndef _S390_RMAP_H +#define _S390_RMAP_H + +/* nothing to see, move along */ +#include + +#endif diff -Nru a/include/asm-s390x/rmap.h b/include/asm-s390x/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-s390x/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,7 @@ +#ifndef _S390X_RMAP_H +#define _S390X_RMAP_H + +/* nothing to see, move along */ +#include + +#endif diff -Nru a/include/asm-sh/rmap.h b/include/asm-sh/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-sh/rmap.h Fri Mar 1 18:19:45 2002 @@ -0,0 +1,7 @@ +#ifndef _SH_RMAP_H +#define _SH_RMAP_H + +/* nothing to see, move along */ +#include + +#endif diff -Nru a/include/asm-sparc/rmap.h b/include/asm-sparc/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-sparc/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,7 @@ +#ifndef _SPARC_RMAP_H +#define _SPARC_RMAP_H + +/* nothing to see, move along */ +#include + +#endif diff -Nru a/include/asm-sparc64/rmap.h b/include/asm-sparc64/rmap.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-sparc64/rmap.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,7 @@ +#ifndef _SPARC64_RMAP_H +#define _SPARC64_RMAP_H + +/* nothing to see, move along */ +#include + +#endif diff -Nru a/include/linux/elevator.h b/include/linux/elevator.h --- a/include/linux/elevator.h Fri Mar 1 18:19:44 2002 +++ b/include/linux/elevator.h Fri Mar 1 18:19:44 2002 @@ -1,12 +1,9 @@ #ifndef _LINUX_ELEVATOR_H #define _LINUX_ELEVATOR_H -typedef void (elevator_fn) (struct request *, elevator_t *, - struct list_head *, - struct list_head *, int); - -typedef int (elevator_merge_fn) (request_queue_t *, struct request **, struct list_head *, - struct buffer_head *, int, int); +typedef int (elevator_merge_fn)(request_queue_t *, struct request **, + struct list_head *, struct buffer_head *bh, + int rw, int max_sectors); typedef void (elevator_merge_cleanup_fn) (request_queue_t *, struct request *, int); @@ -16,6 +13,7 @@ { int read_latency; int write_latency; + int max_bomb_segments; elevator_merge_fn *elevator_merge_fn; elevator_merge_cleanup_fn *elevator_merge_cleanup_fn; @@ -24,13 +22,13 @@ unsigned int queue_ID; }; -int elevator_noop_merge(request_queue_t *, struct request **, struct list_head *, struct buffer_head *, int, int); -void elevator_noop_merge_cleanup(request_queue_t *, struct request *, int); -void elevator_noop_merge_req(struct request *, struct request *); - -int elevator_linus_merge(request_queue_t *, struct request **, struct list_head *, struct buffer_head *, int, int); -void elevator_linus_merge_cleanup(request_queue_t *, struct request *, int); -void elevator_linus_merge_req(struct request *, struct request *); +elevator_merge_fn elevator_noop_merge; +elevator_merge_cleanup_fn elevator_noop_merge_cleanup; +elevator_merge_req_fn elevator_noop_merge_req; + +elevator_merge_fn elevator_linus_merge; +elevator_merge_cleanup_fn elevator_linus_merge_cleanup; +elevator_merge_req_fn elevator_linus_merge_req; typedef struct blkelv_ioctl_arg_s { int queue_ID; @@ -54,22 +52,6 @@ #define ELEVATOR_FRONT_MERGE 1 #define ELEVATOR_BACK_MERGE 2 -/* - * This is used in the elevator algorithm. We don't prioritise reads - * over writes any more --- although reads are more time-critical than - * writes, by treating them equally we increase filesystem throughput. - * This turns out to give better overall performance. -- sct - */ -#define IN_ORDER(s1,s2) \ - ((((s1)->rq_dev == (s2)->rq_dev && \ - (s1)->sector < (s2)->sector)) || \ - (s1)->rq_dev < (s2)->rq_dev) - -#define BHRQ_IN_ORDER(bh, rq) \ - ((((bh)->b_rdev == (rq)->rq_dev && \ - (bh)->b_rsector < (rq)->sector)) || \ - (bh)->b_rdev < (rq)->rq_dev) - static inline int elevator_request_latency(elevator_t * elevator, int rw) { int latency; @@ -85,7 +67,7 @@ ((elevator_t) { \ 0, /* read_latency */ \ 0, /* write_latency */ \ - \ + 0, /* max_bomb_segments */ \ elevator_noop_merge, /* elevator_merge_fn */ \ elevator_noop_merge_cleanup, /* elevator_merge_cleanup_fn */ \ elevator_noop_merge_req, /* elevator_merge_req_fn */ \ @@ -95,7 +77,7 @@ ((elevator_t) { \ 8192, /* read passovers */ \ 16384, /* write passovers */ \ - \ + 6, /* max_bomb_segments */ \ elevator_linus_merge, /* elevator_merge_fn */ \ elevator_linus_merge_cleanup, /* elevator_merge_cleanup_fn */ \ elevator_linus_merge_req, /* elevator_merge_req_fn */ \ diff -Nru a/include/linux/fs.h b/include/linux/fs.h --- a/include/linux/fs.h Fri Mar 1 18:19:44 2002 +++ b/include/linux/fs.h Fri Mar 1 18:19:44 2002 @@ -284,7 +284,7 @@ extern void set_bh_page(struct buffer_head *bh, struct page *page, unsigned long offset); -#define touch_buffer(bh) mark_page_accessed(bh->b_page) +#define touch_buffer(bh) touch_page(bh->b_page) #include diff -Nru a/include/linux/mm.h b/include/linux/mm.h --- a/include/linux/mm.h Fri Mar 1 18:19:44 2002 +++ b/include/linux/mm.h Fri Mar 1 18:19:44 2002 @@ -17,9 +17,6 @@ extern unsigned long num_physpages; extern void * high_memory; extern int page_cluster; -/* The inactive_clean lists are per zone. */ -extern struct list_head active_list; -extern struct list_head inactive_list; #include #include @@ -133,6 +130,9 @@ struct page * (*nopage)(struct vm_area_struct * area, unsigned long address, int unused); }; +/* forward declaration; pte_chain is meant to be internal to rmap.c */ +struct pte_chain; + /* * Each physical page in the system has a struct page associated with * it to keep track of whatever it is we are using the page for at the @@ -159,6 +159,8 @@ updated asynchronously */ struct list_head lru; /* Pageout list, eg. active_list; protected by pagemap_lru_lock !! */ + unsigned char age; /* Page aging counter. */ + struct pte_chain * pte_chain; /* Reverse pte mapping pointer. */ struct page **pprev_hash; /* Complement to *next_hash. */ struct buffer_head * buffers; /* Buffer maps us to a disk block. */ @@ -286,9 +288,9 @@ #define PG_referenced 2 #define PG_uptodate 3 #define PG_dirty 4 -#define PG_unused 5 -#define PG_lru 6 -#define PG_active 7 +#define PG_inactive_clean 5 +#define PG_active 6 +#define PG_inactive_dirty 7 #define PG_slab 8 #define PG_skip 10 #define PG_highmem 11 @@ -391,10 +393,19 @@ #define PageActive(page) test_bit(PG_active, &(page)->flags) #define SetPageActive(page) set_bit(PG_active, &(page)->flags) #define ClearPageActive(page) clear_bit(PG_active, &(page)->flags) +#define TestandSetPageActive(page) test_and_set_bit(PG_active, &(page)->flags) +#define TestandClearPageActive(page) test_and_clear_bit(PG_active, &(page)->flags) + +#define PageInactiveDirty(page) test_bit(PG_inactive_dirty, &(page)->flags) +#define SetPageInactiveDirty(page) set_bit(PG_inactive_dirty, &(page)->flags) +#define ClearPageInactiveDirty(page) clear_bit(PG_inactive_dirty, &(page)->flags) + +#define PageInactiveClean(page) test_bit(PG_inactive_clean, &(page)->flags) +#define SetPageInactiveClean(page) set_bit(PG_inactive_clean, &(page)->flags) +#define ClearPageInactiveClean(page) clear_bit(PG_inactive_clean, &(page)->flags) -#define PageLRU(page) test_bit(PG_lru, &(page)->flags) -#define TestSetPageLRU(page) test_and_set_bit(PG_lru, &(page)->flags) -#define TestClearPageLRU(page) test_and_clear_bit(PG_lru, &(page)->flags) +#define PageLRU(pp) \ + (PageActive(pp) | PageInactiveDirty(pp) | PageInactiveClean(pp)) #ifdef CONFIG_HIGHMEM #define PageHighMem(page) test_bit(PG_highmem, &(page)->flags) @@ -459,6 +470,7 @@ #define __free_page(page) __free_pages((page), 0) #define free_page(addr) free_pages((addr),0) +extern void FASTCALL(fixup_freespace(struct zone_struct *, int)); extern void show_free_areas(void); extern void show_free_areas_node(pg_data_t *pgdat); diff -Nru a/include/linux/mm_inline.h b/include/linux/mm_inline.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/linux/mm_inline.h Fri Mar 1 18:19:44 2002 @@ -0,0 +1,294 @@ +#ifndef _LINUX_VM_INLINE_H +#define _LINUX_VM_INLINE_H + +#include + +/* + * These inline functions tend to need bits and pieces of all the + * other VM include files, meaning they cannot be defined inside + * one of the other VM include files. + * + * The include file mess really needs to be cleaned up... + */ + +static inline void add_page_to_active_list(struct page * page) +{ + struct zone_struct * zone = page_zone(page); + DEBUG_LRU_PAGE(page); + SetPageActive(page); + list_add(&page->lru, &zone->active_list); + zone->active_pages++; + nr_active_pages++; +} + +static inline void add_page_to_inactive_dirty_list(struct page * page) +{ + struct zone_struct * zone = page_zone(page); + DEBUG_LRU_PAGE(page); + SetPageInactiveDirty(page); + list_add(&page->lru, &zone->inactive_dirty_list); + zone->inactive_dirty_pages++; + nr_inactive_dirty_pages++; +} + +static inline void add_page_to_inactive_clean_list(struct page * page) +{ + struct zone_struct * zone = page_zone(page); + DEBUG_LRU_PAGE(page); + SetPageInactiveClean(page); + list_add(&page->lru, &zone->inactive_clean_list); + zone->inactive_clean_pages++; + nr_inactive_clean_pages++; +} + +static inline void del_page_from_active_list(struct page * page) +{ + struct zone_struct * zone = page_zone(page); + list_del(&page->lru); + ClearPageActive(page); + nr_active_pages--; + zone->active_pages--; + DEBUG_LRU_PAGE(page); +} + +static inline void del_page_from_inactive_dirty_list(struct page * page) +{ + struct zone_struct * zone = page_zone(page); + list_del(&page->lru); + ClearPageInactiveDirty(page); + nr_inactive_dirty_pages--; + zone->inactive_dirty_pages--; + DEBUG_LRU_PAGE(page); +} + +static inline void del_page_from_inactive_clean_list(struct page * page) +{ + struct zone_struct * zone = page_zone(page); + list_del(&page->lru); + ClearPageInactiveClean(page); + zone->inactive_clean_pages--; + nr_inactive_clean_pages--; + DEBUG_LRU_PAGE(page); +} + +/* + * Inline functions to control some balancing in the VM. + * + * Note that we do both global and per-zone balancing, with + * most of the balancing done globally. + */ +#define PLENTY_FACTOR 2 +#define ALL_ZONES NULL +#define ANY_ZONE (struct zone_struct *)(~0UL) +#define INACTIVE_FACTOR 5 + +#define VM_MIN 0 +#define VM_LOW 1 +#define VM_HIGH 2 +#define VM_PLENTY 3 +static inline int zone_free_limit(struct zone_struct * zone, int limit) +{ + int free, target, delta; + + /* This is really nasty, but GCC should completely optimise it away. */ + if (limit == VM_MIN) + target = zone->pages_min; + else if (limit == VM_LOW) + target = zone->pages_low; + else if (limit == VM_HIGH) + target = zone->pages_high; + else + target = zone->pages_high * PLENTY_FACTOR; + + free = zone->free_pages + zone->inactive_clean_pages; + delta = target - free; + + return delta; +} + +static inline int free_limit(struct zone_struct * zone, int limit) +{ + int shortage = 0, local; + + if (zone == ALL_ZONES) { + for_each_zone(zone) + shortage += zone_free_limit(zone, limit); + } else if (zone == ANY_ZONE) { + for_each_zone(zone) { + local = zone_free_limit(zone, limit); + shortage += max(local, 0); + } + } else { + shortage = zone_free_limit(zone, limit); + } + + return shortage; +} + +/** + * free_min - test for critically low amount of free pages + * @zone: zone to test, ALL_ZONES to test memory globally + * + * Returns a positive value if we have a serious shortage of free and + * clean pages, zero or negative if there is no serious shortage. + */ +static inline int free_min(struct zone_struct * zone) +{ + return free_limit(zone, VM_MIN); +} + +/** + * free_low - test for low amount of free pages + * @zone: zone to test, ALL_ZONES to test memory globally + * + * Returns a positive value if we have a shortage of free and + * clean pages, zero or negative if there is no shortage. + */ +static inline int free_low(struct zone_struct * zone) +{ + return free_limit(zone, VM_LOW); +} + +/** + * free_high - test if amount of free pages is less than ideal + * @zone: zone to test, ALL_ZONES to test memory globally + * + * Returns a positive value if the number of free and clean + * pages is below kswapd's target, zero or negative if we + * have more than enough free and clean pages. + */ +static inline int free_high(struct zone_struct * zone) +{ + return free_limit(zone, VM_HIGH); +} + +/** + * free_plenty - test if enough pages are freed + * @zone: zone to test, ALL_ZONES to test memory globally + * + * Returns a positive value if the number of free + clean pages + * in a zone is not yet excessive and kswapd is still allowed to + * free pages here, a negative value if kswapd should leave the + * zone alone. + */ +static inline int free_plenty(struct zone_struct * zone) +{ + return free_limit(zone, VM_PLENTY); +} + +/* + * The inactive page target is the free target + 20% of (active + inactive) + * pages. + */ +static inline int zone_inactive_limit(struct zone_struct * zone, int limit) +{ + int inactive, target, inactive_base; + + inactive_base = zone->active_pages + zone->inactive_dirty_pages; + inactive_base /= INACTIVE_FACTOR; + + /* GCC should optimise this away completely. */ + if (limit == VM_MIN) + target = zone->pages_high + inactive_base / 2; + else if (limit == VM_LOW) + target = zone->pages_high + inactive_base; + else + target = zone->pages_high + inactive_base * 2; + + inactive = zone->free_pages + zone->inactive_clean_pages; + inactive += zone->inactive_dirty_pages; + + return target - inactive; +} + +static inline int inactive_limit(struct zone_struct * zone, int limit) +{ + int shortage = 0, local; + + if (zone == ALL_ZONES) { + for_each_zone(zone) + shortage += zone_inactive_limit(zone, limit); + } else if (zone == ANY_ZONE) { + for_each_zone(zone) { + local = zone_inactive_limit(zone, limit); + shortage += max(local, 0); + } + } else { + shortage = zone_inactive_limit(zone, limit); + } + + return shortage; +} + +/** + * inactive_min - test for serious shortage of (free + inactive clean) pages + * @zone: zone to test, ALL_ZONES for global testing + * + * Returns the shortage as a positive number, a negative number + * if we have no serious shortage of (free + inactive clean) pages + */ +static inline int inactive_min(struct zone_struct * zone) +{ + return inactive_limit(zone, VM_MIN); +} + +/** + * inactive_low - test for shortage of (free + inactive clean) pages + * @zone: zone to test, ALL_ZONES for global testing + * + * Returns the shortage as a positive number, a negative number + * if we have no shortage of (free + inactive clean) pages + */ +static inline int inactive_low(struct zone_struct * zone) +{ + return inactive_limit(zone, VM_LOW); +} + +/** + * inactive_high - less than ideal amount of (free + inactive) pages + * @zone: zone to test, ALL_ZONES for global testing + * + * Returns the shortage as a positive number, a negative number + * if we have more than enough (free + inactive) pages + */ +static inline int inactive_high(struct zone_struct * zone) +{ + return inactive_limit(zone, VM_HIGH); +} + +/* + * inactive_target - number of inactive pages we ought to have. + */ +static inline int inactive_target(void) +{ + int target; + + target = nr_active_pages + nr_inactive_dirty_pages + + nr_inactive_clean_pages; + + target /= INACTIVE_FACTOR; + + return target; +} + +/* + * Called whenever the VM references a page. We immediately reclaim + * the inactive clean pages because those are counted as freeable. + * We don't modify the inactive dirty ones because we're never sure + * if those are freeable anyway. + */ +static inline void touch_page(struct page * page) +{ + if (PageInactiveClean(page)) { + struct zone_struct * zone = page_zone(page); + int free = zone->free_pages + zone->inactive_clean_pages; + activate_page(page); + if (free < zone->pages_low) + wakeup_kswapd(GFP_NOIO); + if (zone->free_pages < zone->pages_min) + fixup_freespace(zone, 1); + } else + SetPageReferenced(page); +} + +#endif diff -Nru a/include/linux/mmzone.h b/include/linux/mmzone.h --- a/include/linux/mmzone.h Fri Mar 1 18:19:44 2002 +++ b/include/linux/mmzone.h Fri Mar 1 18:19:44 2002 @@ -40,12 +40,18 @@ */ spinlock_t lock; unsigned long free_pages; - unsigned long pages_min, pages_low, pages_high; + unsigned long active_pages; + unsigned long inactive_dirty_pages; + unsigned long inactive_clean_pages; + unsigned long pages_min, pages_low, pages_high, pages_plenty; int need_balance; /* * free areas of different sizes */ + struct list_head active_list; + struct list_head inactive_dirty_list; + struct list_head inactive_clean_list; free_area_t free_area[MAX_ORDER]; /* @@ -143,9 +149,6 @@ extern int numnodes; extern pg_data_t *pgdat_list; -#define memclass(pgzone, classzone) (((pgzone)->zone_pgdat == (classzone)->zone_pgdat) \ - && ((pgzone) <= (classzone))) - /* * The following two are not meant for general usage. They are here as * prototypes for the discontig memory code. @@ -157,6 +160,60 @@ struct page *pmap); extern pg_data_t contig_page_data; + +/** + * for_each_pgdat - helper macro to iterate over all nodes + * @pgdat - pg_data_t * variable + * + * Meant to help with common loops of the form + * pgdat = pgdat_list; + * while(pgdat) { + * ... + * pgdat = pgdat->node_next; + * } + */ +#define for_each_pgdat(pgdat) \ + for (pgdat = pgdat_list; pgdat; pgdat = pgdat->node_next) + + +/* + * next_zone - helper magic for for_each_zone() + * Thanks to William Lee Irwin III for this piece of ingenuity. + */ +static inline zone_t *next_zone(zone_t *zone) +{ + pg_data_t *pgdat = zone->zone_pgdat; + + if (zone - pgdat->node_zones < MAX_NR_ZONES - 1) + zone++; + + else if (pgdat->node_next) { + pgdat = pgdat->node_next; + zone = pgdat->node_zones; + } else + zone = NULL; + + return zone; +} + +/** + * for_each_zone - helper macro to iterate over all memory zones + * @zone - zone_t * variable + * + * The user only needs to declare the zone variable, for_each_zone + * fills it in. This basically means for_each_zone() is an + * easier to read version of this piece of code: + * + * for(pgdat = pgdat_list; pgdat; pgdat = pgdat->node_next) + * for(i = 0; i < MAX_NR_ZONES; ++i) { + * zone_t * z = pgdat->node_zones + i; + * ... + * } + * } + */ +#define for_each_zone(zone) \ + for(zone = pgdat_list->node_zones; zone; zone = next_zone(zone)) + #ifndef CONFIG_DISCONTIGMEM diff -Nru a/include/linux/sched.h b/include/linux/sched.h --- a/include/linux/sched.h Fri Mar 1 18:19:44 2002 +++ b/include/linux/sched.h Fri Mar 1 18:19:44 2002 @@ -225,7 +225,7 @@ unsigned long rss, total_vm, locked_vm; unsigned long def_flags; unsigned long cpu_vm_mask; - unsigned long swap_address; + unsigned long rlimit_rss; unsigned dumpable:1; @@ -244,6 +244,7 @@ mmap_sem: __RWSEM_INITIALIZER(name.mmap_sem), \ page_table_lock: SPIN_LOCK_UNLOCKED, \ mmlist: LIST_HEAD_INIT(name.mmlist), \ + rlimit_rss: RLIM_INFINITY, \ } struct signal_struct { @@ -325,8 +326,6 @@ struct task_struct *next_task, *prev_task; struct mm_struct *active_mm; - struct list_head local_pages; - unsigned int allocation_order, nr_local_pages; /* task state */ struct linux_binfmt *binfmt; diff -Nru a/include/linux/slab.h b/include/linux/slab.h --- a/include/linux/slab.h Fri Mar 1 18:19:44 2002 +++ b/include/linux/slab.h Fri Mar 1 18:19:44 2002 @@ -55,6 +55,7 @@ void (*)(void *, kmem_cache_t *, unsigned long)); extern int kmem_cache_destroy(kmem_cache_t *); extern int kmem_cache_shrink(kmem_cache_t *); +extern int kmem_cache_shrink_nr(kmem_cache_t *); extern void *kmem_cache_alloc(kmem_cache_t *, int); extern void kmem_cache_free(kmem_cache_t *, void *); diff -Nru a/include/linux/swap.h b/include/linux/swap.h --- a/include/linux/swap.h Fri Mar 1 18:19:44 2002 +++ b/include/linux/swap.h Fri Mar 1 18:19:44 2002 @@ -86,8 +86,8 @@ extern unsigned int nr_free_pages(void); extern unsigned int nr_free_buffer_pages(void); extern int nr_active_pages; -extern int nr_inactive_pages; -extern atomic_t nr_async_pages; +extern int nr_inactive_dirty_pages; +extern int nr_inactive_clean_pages; extern atomic_t page_cache_size; extern atomic_t buffermem_pages; extern spinlock_t pagecache_lock; @@ -100,18 +100,39 @@ struct zone_t; +/* linux/mm/rmap.c */ +extern int FASTCALL(page_referenced(struct page *)); +extern void FASTCALL(page_add_rmap(struct page *, pte_t *)); +extern void FASTCALL(page_remove_rmap(struct page *, pte_t *)); +extern int FASTCALL(try_to_unmap(struct page *)); +extern int FASTCALL(page_over_rsslimit(struct page *)); + +/* return values of try_to_unmap */ +#define SWAP_SUCCESS 0 +#define SWAP_AGAIN 1 +#define SWAP_FAIL 2 +#define SWAP_ERROR 3 + /* linux/mm/swap.c */ +extern int total_swap_pages; extern void FASTCALL(lru_cache_add(struct page *)); extern void FASTCALL(__lru_cache_del(struct page *)); extern void FASTCALL(lru_cache_del(struct page *)); extern void FASTCALL(activate_page(struct page *)); +extern void FASTCALL(activate_page_nolock(struct page *)); +extern void FASTCALL(deactivate_page(struct page *)); +extern void FASTCALL(deactivate_page_nolock(struct page *)); +extern void FASTCALL(drop_page(struct page *)); extern void swap_setup(void); /* linux/mm/vmscan.c */ +extern struct page * FASTCALL(reclaim_page(zone_t *)); extern wait_queue_head_t kswapd_wait; -extern int FASTCALL(try_to_free_pages(zone_t *, unsigned int, unsigned int)); +extern int FASTCALL(try_to_free_pages(unsigned int gfp_mask)); +extern void wakeup_kswapd(unsigned int); +extern void rss_free_pages(unsigned int); /* linux/mm/page_io.c */ extern void rw_swap_page(int, struct page *); @@ -125,6 +146,7 @@ extern void show_swap_cache_info(void); #endif extern int add_to_swap_cache(struct page *, swp_entry_t); +extern int add_to_swap(struct page *); extern void __delete_from_swap_cache(struct page *page); extern void delete_from_swap_cache(struct page *page); extern void free_page_and_swap_cache(struct page *page); @@ -158,7 +180,14 @@ extern spinlock_t pagemap_lru_lock; -extern void FASTCALL(mark_page_accessed(struct page *)); +/* + * Page aging defines. These seem to work great in FreeBSD, + * no need to reinvent the wheel. + */ +#define PAGE_AGE_START 5 +#define PAGE_AGE_ADV 3 +#define PAGE_AGE_DECL 1 +#define PAGE_AGE_MAX 64 /* * List add/del helper macros. These must be called @@ -166,38 +195,12 @@ */ #define DEBUG_LRU_PAGE(page) \ do { \ - if (!PageLRU(page)) \ - BUG(); \ if (PageActive(page)) \ BUG(); \ -} while (0) - -#define add_page_to_active_list(page) \ -do { \ - DEBUG_LRU_PAGE(page); \ - SetPageActive(page); \ - list_add(&(page)->lru, &active_list); \ - nr_active_pages++; \ -} while (0) - -#define add_page_to_inactive_list(page) \ -do { \ - DEBUG_LRU_PAGE(page); \ - list_add(&(page)->lru, &inactive_list); \ - nr_inactive_pages++; \ -} while (0) - -#define del_page_from_active_list(page) \ -do { \ - list_del(&(page)->lru); \ - ClearPageActive(page); \ - nr_active_pages--; \ -} while (0) - -#define del_page_from_inactive_list(page) \ -do { \ - list_del(&(page)->lru); \ - nr_inactive_pages--; \ + if (PageInactiveDirty(page)) \ + BUG(); \ + if (PageInactiveClean(page)) \ + BUG(); \ } while (0) extern spinlock_t swaplock; diff -Nru a/include/linux/swapctl.h b/include/linux/swapctl.h --- a/include/linux/swapctl.h Fri Mar 1 18:19:44 2002 +++ b/include/linux/swapctl.h Fri Mar 1 18:19:44 2002 @@ -10,4 +10,13 @@ typedef pager_daemon_v1 pager_daemon_t; extern pager_daemon_t pager_daemon; +typedef struct freepages_v1 +{ + unsigned int min; + unsigned int low; + unsigned int high; +} freepages_v1; +typedef freepages_v1 freepages_t; +extern freepages_t freepages; + #endif /* _LINUX_SWAPCTL_H */ diff -Nru a/kernel/fork.c b/kernel/fork.c --- a/kernel/fork.c Fri Mar 1 18:19:44 2002 +++ b/kernel/fork.c Fri Mar 1 18:19:44 2002 @@ -139,7 +139,6 @@ mm->map_count = 0; mm->rss = 0; mm->cpu_vm_mask = 0; - mm->swap_address = 0; pprev = &mm->mmap; /* @@ -263,9 +262,6 @@ void mmput(struct mm_struct *mm) { if (atomic_dec_and_lock(&mm->mm_users, &mmlist_lock)) { - extern struct mm_struct *swap_mm; - if (swap_mm == mm) - swap_mm = list_entry(mm->mmlist.next, struct mm_struct, mmlist); list_del(&mm->mmlist); mmlist_nr--; spin_unlock(&mmlist_lock); @@ -658,8 +654,6 @@ #endif p->lock_depth = -1; /* -1 = no lock */ p->start_time = jiffies; - - INIT_LIST_HEAD(&p->local_pages); retval = -ENOMEM; /* copy all the process information */ diff -Nru a/kernel/sys.c b/kernel/sys.c --- a/kernel/sys.c Fri Mar 1 18:19:44 2002 +++ b/kernel/sys.c Fri Mar 1 18:19:44 2002 @@ -1128,6 +1128,12 @@ if (resource == RLIMIT_NOFILE) { if (new_rlim.rlim_cur > NR_OPEN || new_rlim.rlim_max > NR_OPEN) return -EPERM; + } else if (resource == RLIMIT_RSS && current->mm) { + /* rlimit is specified in bytes, convert to pages */ + unsigned long pages = RLIM_INFINITY; + if (new_rlim.rlim_cur != RLIM_INFINITY) + pages = new_rlim.rlim_cur >> PAGE_SHIFT; + current->mm->rlimit_rss = pages; } *old_rlim = new_rlim; return 0; diff -Nru a/kernel/sysctl.c b/kernel/sysctl.c --- a/kernel/sysctl.c Fri Mar 1 18:19:44 2002 +++ b/kernel/sysctl.c Fri Mar 1 18:19:44 2002 @@ -260,6 +260,8 @@ }; static ctl_table vm_table[] = { + {VM_FREEPG, "freepages", + &freepages, sizeof(freepages_t), 0644, NULL, &proc_dointvec}, {VM_BDFLUSH, "bdflush", &bdf_prm, 9*sizeof(int), 0644, NULL, &proc_dointvec_minmax, &sysctl_intvec, NULL, &bdflush_min, &bdflush_max}, diff -Nru a/mm/Makefile b/mm/Makefile --- a/mm/Makefile Fri Mar 1 18:19:44 2002 +++ b/mm/Makefile Fri Mar 1 18:19:44 2002 @@ -14,7 +14,7 @@ obj-y := memory.o mmap.o filemap.o mprotect.o mlock.o mremap.o \ vmalloc.o slab.o bootmem.o swap.o vmscan.o page_io.o \ page_alloc.o swap_state.o swapfile.o numa.o oom_kill.o \ - shmem.o + shmem.o rmap.o obj-$(CONFIG_HIGHMEM) += highmem.o diff -Nru a/mm/TODO b/mm/TODO --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/mm/TODO Fri Mar 1 18:19:44 2002 @@ -0,0 +1,35 @@ + VM TODO list + +Forever valid TODO entries: + - keep up with the official kernel + - port over bugfixes + - minimise the diff by keeping code in sync where possible + +Easy short-term features: + - reclaim swap space from refill_inactive() + - simplify SMP locking + - replace foo()/foo_pgd()/foo_pmd()/foo_pte() stuff with + one single function using a for_each_pte() macro + for_each_pte(ptep, mm, start_address, end_address) + - fix page_launder() to not eat horrible amounts of CPU or flush + all pages to disk at once + - better VM balancing, clean vs. dirty ratio + - fix loopback device deadlock + riel: nr_fract=70%, nr_fract_sync=80% + riel: setup a loopback fs ext2-on-ext2 + riel: boot with mem=64m + riel: then write a 500 meg file. + riel: current kernel livelocks. + - stabilise pte_highmem and integrate it with rmap + +Long-term features: + - extensive VM statistics + - IO clustering for page_launder() and sync_old_buffers() + - readahead on per-VMA level (+ drop behind?) + - more graceful degradation when the load gets high + - reducing readahead + - unfair pageout so not all apps fall over + - memory objects, using pagecache and tmpfs for storage so + the memory object itself doesn't introduce any new overhead + - using the memory objects, removing page table copying from fork() + - load control able to deal with really extreme loads, swapping diff -Nru a/mm/bootmem.c b/mm/bootmem.c --- a/mm/bootmem.c Fri Mar 1 18:19:44 2002 +++ b/mm/bootmem.c Fri Mar 1 18:19:44 2002 @@ -326,12 +326,11 @@ pg_data_t *pgdat = pgdat_list; void *ptr; - while (pgdat) { + for_each_pgdat(pgdat) if ((ptr = __alloc_bootmem_core(pgdat->bdata, size, align, goal))) return(ptr); - pgdat = pgdat->node_next; - } + /* * Whoops, we cannot satisfy the allocation request. */ diff -Nru a/mm/filemap.c b/mm/filemap.c --- a/mm/filemap.c Fri Mar 1 18:19:44 2002 +++ b/mm/filemap.c Fri Mar 1 18:19:44 2002 @@ -22,6 +22,7 @@ #include #include #include +#include #include #include @@ -234,7 +235,7 @@ static void truncate_complete_page(struct page *page) { /* Leave it on the LRU if it gets converted into anonymous buffers */ - if (!page->buffers || do_flushpage(page, 0)) + if (!page->pte_chain && (!page->buffers || do_flushpage(page, 0))) lru_cache_del(page); /* @@ -454,6 +455,11 @@ return page; } +static struct page * __find_page(struct address_space * mapping, unsigned long index) +{ + return __find_page_nolock(mapping, index, *page_hash(mapping,index)); +} + static int do_buffer_fdatasync(struct list_head *head, unsigned long start, unsigned long end, int (*fn)(struct page *)) { struct list_head *curr; @@ -1016,7 +1022,53 @@ /* - * Same as grab_cache_page, but do not wait if the page is unavailable. + * We combine this with read-ahead to deactivate pages when we + * think there's sequential IO going on. Note that this is + * harmless since we don't actually evict the pages from memory + * but just move them to the inactive list. + * + * TODO: + * - make the readahead code smarter + * - move readahead to the VMA level so we can do the same + * trick with mmap() + * + * Rik van Riel, 2000 + */ +static void drop_behind(struct file * file, unsigned long index) +{ + struct inode *inode = file->f_dentry->d_inode; + struct address_space *mapping = inode->i_mapping; + struct page *page; + unsigned long start; + + /* Nothing to drop-behind if we're on the first page. */ + if (!index) + return; + + if (index > file->f_rawin) + start = index - file->f_rawin; + else + start = 0; + + /* + * Go backwards from index-1 and drop all pages in the + * readahead window. Since the readahead window may have + * been increased since the last time we were called, we + * stop when the page isn't there. + */ + spin_lock(&pagemap_lru_lock); + while (--index >= start) { + spin_lock(&pagecache_lock); + page = __find_page(mapping, index); + spin_unlock(&pagecache_lock); + if (!page || !PageActive(page)) + break; + drop_page(page); + } + spin_unlock(&pagemap_lru_lock); +} + +/* Same as grab_cache_page, but do not wait if the page is unavailable. * This is intended for speculative data generators, where the data can * be regenerated if the page couldn't be grabbed. This routine should * be safe to call while holding the lock for another page. @@ -1286,6 +1338,12 @@ if (filp->f_ramax > max_readahead) filp->f_ramax = max_readahead; + /* + * Move the pages that have already been passed + * to the inactive list. + */ + drop_behind(filp, index); + #ifdef PROFILE_READAHEAD profile_readahead((reada_ok == 2), filp); #endif @@ -1294,25 +1352,6 @@ return; } -/* - * Mark a page as having seen activity. - * - * If it was already so marked, move it - * to the active queue and drop the referenced - * bit. Otherwise, just mark it for future - * action.. - */ -void mark_page_accessed(struct page *page) -{ - if (!PageActive(page) && PageReferenced(page)) { - activate_page(page); - ClearPageReferenced(page); - return; - } - - /* Mark the page referenced, AFTER checking for previous usage.. */ - SetPageReferenced(page); -} /* * This is a generic file read routine, and uses the @@ -1421,7 +1460,7 @@ * beginning or we just did an lseek. */ if (!offset || !filp->f_reada) - mark_page_accessed(page); + touch_page(page); /* * Ok, we have the page, and it's up-to-date, so @@ -1822,7 +1861,7 @@ nr = max; /* And limit it to a sane percentage of the inactive list.. */ - max = nr_inactive_pages / 2; + max = nr_inactive_clean_pages / 2; if (nr > max) nr = max; @@ -1967,7 +2006,7 @@ * Found the page and have a reference on it, need to check sharing * and possibly copy it over to another page.. */ - mark_page_accessed(page); + touch_page(page); flush_page_to_ram(page); return page; @@ -2840,7 +2879,7 @@ page = __read_cache_page(mapping, index, filler, data); if (IS_ERR(page)) goto out; - mark_page_accessed(page); + touch_page(page); if (Page_Uptodate(page)) goto out; @@ -3037,6 +3076,7 @@ unsigned long index, offset; long page_fault; char *kaddr; + int deactivate = 1; /* * Try to find the page in the cache. If it isn't there, @@ -3045,8 +3085,10 @@ offset = (pos & (PAGE_CACHE_SIZE -1)); /* Within page */ index = pos >> PAGE_CACHE_SHIFT; bytes = PAGE_CACHE_SIZE - offset; - if (bytes > count) + if (bytes > count) { bytes = count; + deactivate = 0; + } /* * Bring in the user page that we will copy from _first_. @@ -3090,8 +3132,11 @@ unlock: kunmap(page); /* Mark it unlocked again and drop the page.. */ - SetPageReferenced(page); UnlockPage(page); + if (deactivate) + deactivate_page(page); + else + touch_page(page); page_cache_release(page); if (status < 0) diff -Nru a/mm/memory.c b/mm/memory.c --- a/mm/memory.c Fri Mar 1 18:19:44 2002 +++ b/mm/memory.c Fri Mar 1 18:19:44 2002 @@ -45,8 +45,10 @@ #include #include #include +#include #include +#include #include #include @@ -102,6 +104,7 @@ } pte = pte_offset(dir, 0); pmd_clear(dir); + pgtable_remove_rmap(pte); pte_free(pte); } @@ -236,9 +239,11 @@ if (pte_none(pte)) goto cont_copy_pte_range_noset; + /* pte contains position in swap, so copy. */ if (!pte_present(pte)) { swap_duplicate(pte_to_swp_entry(pte)); - goto cont_copy_pte_range; + set_pte(dst_pte, pte); + goto cont_copy_pte_range_noset; } ptepage = pte_page(pte); if ((!VALID_PAGE(ptepage)) || @@ -246,7 +251,7 @@ goto cont_copy_pte_range; /* If it's a COW mapping, write protect it both in the parent and the child */ - if (cow && pte_write(pte)) { + if (cow) { ptep_set_wrprotect(src_pte); pte = *src_pte; } @@ -259,6 +264,7 @@ dst->rss++; cont_copy_pte_range: set_pte(dst_pte, pte); + page_add_rmap(ptepage, dst_pte); cont_copy_pte_range_noset: address += PAGE_SIZE; if (address >= end) goto out_unlock; @@ -314,8 +320,10 @@ continue; if (pte_present(pte)) { struct page *page = pte_page(pte); - if (VALID_PAGE(page) && !PageReserved(page)) + if (VALID_PAGE(page) && !PageReserved(page)) { freed ++; + page_remove_rmap(page, ptep); + } /* This will eventually call __free_pte on the pte. */ tlb_remove_page(tlb, ptep, address + offset); } else { @@ -980,7 +988,9 @@ if (pte_same(*page_table, pte)) { if (PageReserved(old_page)) ++mm->rss; + page_remove_rmap(old_page, page_table); break_cow(vma, new_page, address, page_table); + page_add_rmap(new_page, page_table); lru_cache_add(new_page); /* Free the old page.. */ @@ -1093,6 +1103,10 @@ struct page *new_page; unsigned long offset; + /* Low on free memory ? Don't make things worse. */ + if (free_low(ALL_ZONES) < 0) + return; + /* * Get the number of handles we should do readahead io to. */ @@ -1141,7 +1155,7 @@ ret = 2; } - mark_page_accessed(page); + touch_page(page); lock_page(page); @@ -1172,6 +1186,7 @@ flush_page_to_ram(page); flush_icache_page(vma, page); set_pte(page_table, pte); + page_add_rmap(page, page_table); /* No need to invalidate - it was non-present before */ update_mmu_cache(vma, address, pte); @@ -1187,14 +1202,13 @@ static int do_anonymous_page(struct mm_struct * mm, struct vm_area_struct * vma, pte_t *page_table, int write_access, unsigned long addr) { pte_t entry; + struct page * page = ZERO_PAGE(addr); /* Read-only mapping of ZERO_PAGE. */ entry = pte_wrprotect(mk_pte(ZERO_PAGE(addr), vma->vm_page_prot)); /* ..except if it's a write access */ if (write_access) { - struct page *page; - /* Allocate our own private page. */ spin_unlock(&mm->page_table_lock); @@ -1213,10 +1227,10 @@ flush_page_to_ram(page); entry = pte_mkwrite(pte_mkdirty(mk_pte(page, vma->vm_page_prot))); lru_cache_add(page); - mark_page_accessed(page); } set_pte(page_table, entry); + page_add_rmap(page, page_table); /* ignores ZERO_PAGE */ /* No need to invalidate - it was non-present before */ update_mmu_cache(vma, addr, entry); @@ -1271,6 +1285,8 @@ new_page = page; } + touch_page(new_page); + spin_lock(&mm->page_table_lock); /* * This silly early PAGE_DIRTY setting removes a race @@ -1291,6 +1307,7 @@ if (write_access) entry = pte_mkwrite(pte_mkdirty(entry)); set_pte(page_table, entry); + page_add_rmap(new_page, page_table); } else { /* One of our sibling threads was faster, back out. */ page_cache_release(new_page); @@ -1367,6 +1384,14 @@ current->state = TASK_RUNNING; pgd = pgd_offset(mm, address); + /* + * If we are over our RSS limit and the system needs memory, + * we will free memory for the non-hogs and slow down a bit. + */ + if (mm->rlimit_rss && mm->rss > mm->rlimit_rss && + free_high(ALL_ZONES) > 0) + rss_free_pages(GFP_HIGHUSER); + /* * We need the page table lock to synchronize with kswapd * and the SMP-safe atomic PTE updates. @@ -1448,6 +1473,7 @@ goto out; } } + pgtable_add_rmap(new, mm, address); pmd_populate(mm, pmd, new); } out: diff -Nru a/mm/mremap.c b/mm/mremap.c --- a/mm/mremap.c Fri Mar 1 18:19:44 2002 +++ b/mm/mremap.c Fri Mar 1 18:19:44 2002 @@ -61,8 +61,14 @@ { int error = 0; pte_t pte; + struct page * page = NULL; + + if (pte_present(*src)) + page = pte_page(*src); if (!pte_none(*src)) { + if (page) + page_remove_rmap(page, src); pte = ptep_get_and_clear(src); if (!dst) { /* No dest? We must put it back. */ @@ -70,6 +76,8 @@ error++; } set_pte(dst, pte); + if (page) + page_add_rmap(page, dst); } return error; } diff -Nru a/mm/oom_kill.c b/mm/oom_kill.c --- a/mm/oom_kill.c Fri Mar 1 18:19:44 2002 +++ b/mm/oom_kill.c Fri Mar 1 18:19:44 2002 @@ -110,8 +110,7 @@ /* * Simple selection loop. We chose the process with the highest - * number of 'points'. We need the locks to make sure that the - * list of task structs doesn't change while we look the other way. + * number of 'points'. We expect the caller will lock the tasklist. * * (not docbooked, we don't want this one cluttering up the manual) */ @@ -121,7 +120,6 @@ struct task_struct *p = NULL; struct task_struct *chosen = NULL; - read_lock(&tasklist_lock); for_each_task(p) { if (p->pid) { int points = badness(p); @@ -131,7 +129,6 @@ } } } - read_unlock(&tasklist_lock); return chosen; } @@ -170,19 +167,25 @@ */ static void oom_kill(void) { - struct task_struct *p = select_bad_process(), *q; + struct task_struct *p, *q; + extern wait_queue_head_t kswapd_done; + + read_lock(&tasklist_lock); + p = select_bad_process(); /* Found nothing?!?! Either we hang forever, or we panic. */ if (p == NULL) panic("Out of memory and no killable processes...\n"); /* kill all processes that share the ->mm (i.e. all threads) */ - read_lock(&tasklist_lock); for_each_task(q) { if(q->mm == p->mm) oom_kill_task(q); } read_unlock(&tasklist_lock); + /* Chances are by this time our victim is sleeping on kswapd. */ + wake_up(&kswapd_done); + /* * Make kswapd go out of the way, so "p" has a good chance of * killing itself before someone else gets the chance to ask @@ -198,7 +201,7 @@ */ void out_of_memory(void) { - static unsigned long first, last, count; + static unsigned long first, last, count, lastkill; unsigned long now, since; /* @@ -235,8 +238,18 @@ return; /* + * If we just killed a process, wait a while + * to give that task a chance to exit. This + * avoids killing multiple processes needlessly. + */ + since = now - lastkill; + if (since < HZ*5) + return; + + /* * Ok, really out of memory. Kill something. */ + lastkill = now; oom_kill(); reset: diff -Nru a/mm/page_alloc.c b/mm/page_alloc.c --- a/mm/page_alloc.c Fri Mar 1 18:19:44 2002 +++ b/mm/page_alloc.c Fri Mar 1 18:19:44 2002 @@ -22,12 +22,12 @@ #include #include #include +#include int nr_swap_pages; int nr_active_pages; -int nr_inactive_pages; -struct list_head inactive_list; -struct list_head active_list; +int nr_inactive_dirty_pages; +int nr_inactive_clean_pages; pg_data_t *pgdat_list; /* Used to look up the address of the struct zone encoded in page->zone */ @@ -38,6 +38,8 @@ static int zone_balance_ratio[MAX_NR_ZONES] __initdata = { 128, 128, 128, }; static int zone_balance_min[MAX_NR_ZONES] __initdata = { 20 , 20, 20, }; static int zone_balance_max[MAX_NR_ZONES] __initdata = { 255 , 255, 255, }; +static int zone_extrafree_ratio[MAX_NR_ZONES] __initdata = { 128, 512, 0, }; +static int zone_extrafree_max[MAX_NR_ZONES] __initdata = { 1024 , 1024, 0, }; /* * Free_page() adds the page to the free lists. This is optimized for @@ -113,16 +115,17 @@ BUG(); if (PageLocked(page)) BUG(); - if (PageLRU(page)) - BUG(); if (PageActive(page)) BUG(); + if (PageInactiveDirty(page)) + BUG(); + if (PageInactiveClean(page)) + BUG(); + if (page->pte_chain) + BUG(); page->flags &= ~((1<flags & PF_FREE_PAGES) - goto local_freelist; - back_local_freelist: - + page->age = PAGE_AGE_START; + zone = page_zone(page); mask = (~0UL) << order; @@ -169,17 +172,6 @@ memlist_add_head(&(base + page_idx)->list, &area->free_list); spin_unlock_irqrestore(&zone->lock, flags); - return; - - local_freelist: - if (current->nr_local_pages) - goto back_local_freelist; - if (in_interrupt()) - goto back_local_freelist; - - list_add(&page->list, ¤t->local_pages); - page->index = order; - current->nr_local_pages++; } #define MARK_USED(index, order, area) \ @@ -238,10 +230,7 @@ set_page_count(page, 1); if (BAD_RANGE(zone,page)) BUG(); - if (PageLRU(page)) - BUG(); - if (PageActive(page)) - BUG(); + DEBUG_LRU_PAGE(page); return page; } curr_order++; @@ -260,78 +249,83 @@ } #endif -static struct page * FASTCALL(balance_classzone(zone_t *, unsigned int, unsigned int, int *)); -static struct page * balance_classzone(zone_t * classzone, unsigned int gfp_mask, unsigned int order, int * freed) +/* + * If we are able to directly reclaim pages, we move pages from the + * inactive_clean list onto the free list until the zone has enough + * free pages or until the inactive_clean pages are exhausted. + * If we cannot do this work ourselves, call kswapd. + */ +void FASTCALL(fixup_freespace(zone_t * zone, int direct_reclaim)); +void fixup_freespace(zone_t * zone, int direct_reclaim) +{ + if (direct_reclaim) { + struct page * page; + do { + if ((page = reclaim_page(zone))) + __free_pages_ok(page, 0); + } while (page && zone->free_pages <= zone->pages_min); + } else + wakeup_kswapd(GFP_ATOMIC); +} + +#define PAGES_KERNEL 0 +#define PAGES_MIN 1 +#define PAGES_LOW 2 +#define PAGES_HIGH 3 + +/* + * This function does the dirty work for __alloc_pages + * and is separated out to keep the code size smaller. + * (suggested by Davem at 1:30 AM, typed by Rik at 6 AM) + */ +static struct page * __alloc_pages_limit(zonelist_t *zonelist, + unsigned long order, int limit, int direct_reclaim) { - struct page * page = NULL; - int __freed = 0; + zone_t **zone = zonelist->zones; + unsigned long water_mark = 0; - if (!(gfp_mask & __GFP_WAIT)) - goto out; - if (in_interrupt()) - BUG(); - - current->allocation_order = order; - current->flags |= PF_MEMALLOC | PF_FREE_PAGES; - - __freed = try_to_free_pages(classzone, gfp_mask, order); - - current->flags &= ~(PF_MEMALLOC | PF_FREE_PAGES); - - if (current->nr_local_pages) { - struct list_head * entry, * local_pages; - struct page * tmp; - int nr_pages; - - local_pages = ¤t->local_pages; - - if (likely(__freed)) { - /* pick from the last inserted so we're lifo */ - entry = local_pages->next; - do { - tmp = list_entry(entry, struct page, list); - if (tmp->index == order && memclass(page_zone(tmp), classzone)) { - list_del(entry); - current->nr_local_pages--; - set_page_count(tmp, 1); - page = tmp; - - if (page->buffers) - BUG(); - if (page->mapping) - BUG(); - if (!VALID_PAGE(page)) - BUG(); - if (PageSwapCache(page)) - BUG(); - if (PageLocked(page)) - BUG(); - if (PageLRU(page)) - BUG(); - if (PageActive(page)) - BUG(); - if (PageDirty(page)) - BUG(); + for (;;) { + zone_t *z = *(zone++); - break; - } - } while ((entry = entry->next) != local_pages); + if (!z) + break; + if (!z->size) + BUG(); + + /* + * We allocate if the number of (free + inactive_clean) + * pages is above the watermark. + */ + switch (limit) { + case PAGES_KERNEL: + water_mark = z->pages_min / 2; + break; + case PAGES_MIN: + water_mark = z->pages_min; + break; + case PAGES_LOW: + water_mark = z->pages_low; + break; + default: + case PAGES_HIGH: + water_mark = z->pages_high; } - nr_pages = current->nr_local_pages; - /* free in reverse order so that the global order will be lifo */ - while ((entry = local_pages->prev) != local_pages) { - list_del(entry); - tmp = list_entry(entry, struct page, list); - __free_pages_ok(tmp, tmp->index); - if (!nr_pages--) - BUG(); + if (z->free_pages + z->inactive_clean_pages >= water_mark) { + struct page *page = NULL; + /* If possible, reclaim a page directly. */ + if (direct_reclaim) + page = reclaim_page(z); + /* If that fails, fall back to rmqueue. */ + if (!page) + page = rmqueue(z, order); + if (page) + return page; } - current->nr_local_pages = 0; } - out: - *freed = __freed; - return page; + + /* Found nothing. */ + return NULL; } /* @@ -339,100 +333,248 @@ */ struct page * __alloc_pages(unsigned int gfp_mask, unsigned int order, zonelist_t *zonelist) { - unsigned long min; - zone_t **zone, * classzone; + zone_t **zone; + int min, direct_reclaim = 0; struct page * page; - int freed; + /* + * (If anyone calls gfp from interrupts nonatomically then it + * will sooner or later tripped up by a schedule().) + * + * We fall back to lower-level zones if allocation + * in a higher zone fails. + */ + + /* + * Can we take pages directly from the inactive_clean + * list? + */ + if (order == 0 && (gfp_mask & __GFP_WAIT)) + direct_reclaim = 1; + +try_again: + /* + * First, see if we have any zones with lots of free memory. + * + * We allocate free memory first because it doesn't contain + * any data we would want to cache. + */ zone = zonelist->zones; - classzone = *zone; min = 1UL << order; for (;;) { zone_t *z = *(zone++); if (!z) break; + if (!z->size) + BUG(); - min += z->pages_low; + min += z->pages_min; if (z->free_pages > min) { page = rmqueue(z, order); if (page) return page; - } + } else if (z->free_pages < z->pages_min) + fixup_freespace(z, direct_reclaim); + } + + /* + * Next, try to allocate a page from a zone with a HIGH + * amount of (free + inactive_clean) pages. + * + * If there is a lot of activity, inactive_target + * will be high and we'll have a good chance of + * finding a page using the HIGH limit. + */ + page = __alloc_pages_limit(zonelist, order, PAGES_HIGH, direct_reclaim); + if (page) + return page; + + /* + * Then try to allocate a page from a zone with more + * than zone->pages_low of (free + inactive_clean) pages. + * + * When the working set is very large and VM activity + * is low, we're most likely to have our allocation + * succeed here. + */ + page = __alloc_pages_limit(zonelist, order, PAGES_LOW, direct_reclaim); + if (page) + return page; + + /* + * OK, none of the zones on our zonelist has lots + * of pages free. + * + * We wake up kswapd, in the hope that kswapd will + * resolve this situation before memory gets tight. + * + * We'll also help a bit trying to free pages, this + * way statistics will make sure really fast allocators + * are slowed down more than slow allocators and other + * programs in the system shouldn't be impacted as much + * by the hogs. + */ + wakeup_kswapd(gfp_mask); + + /* + * After waking up kswapd, we try to allocate a page + * from any zone which isn't critical yet. + * + * Kswapd should, in most situations, bring the situation + * back to normal in no time. + */ + page = __alloc_pages_limit(zonelist, order, PAGES_MIN, direct_reclaim); + if (page) + return page; + + /* + * Kernel allocations can eat a few emergency pages. + * We should be able to run without this, find out why + * the SCSI layer isn't happy ... + */ + if (gfp_mask & __GFP_HIGH) { + page = __alloc_pages_limit(zonelist, order, PAGES_KERNEL, direct_reclaim); + if (page) + return page; } - classzone->need_balance = 1; - mb(); - if (waitqueue_active(&kswapd_wait)) - wake_up_interruptible(&kswapd_wait); + /* + * Oh well, we didn't succeed. + */ + if (!(current->flags & PF_MEMALLOC)) { + /* + * Are we dealing with a higher order allocation? + * + * If so, try to defragment some memory. + */ + if (order > 0 && (gfp_mask & __GFP_WAIT)) + goto defragment; + + /* + * If we arrive here, we are really tight on memory. + * Since kswapd didn't succeed in freeing pages for us, + * we need to help it. + * + * Single page allocs loop until the allocation succeeds. + * Multi-page allocs can fail due to memory fragmentation; + * in that case we bail out to prevent infinite loops and + * hanging device drivers ... + * + * Another issue are GFP_NOFS allocations; because they + * do not have __GFP_FS set it's possible we cannot make + * any progress freeing pages, in that case it's better + * to give up than to deadlock the kernel looping here. + * + * NFS: we must yield the CPU (to rpciod) to avoid deadlock. + */ + if (gfp_mask & __GFP_WAIT) { + __set_current_state(TASK_RUNNING); + current->policy |= SCHED_YIELD; + schedule(); + if (!order || free_high(ALL_ZONES) >= 0) { + int progress = try_to_free_pages(gfp_mask); + if (progress || (gfp_mask & __GFP_FS)) + goto try_again; + /* + * Fail if no progress was made and the + * allocation may not be able to block on IO. + */ + return NULL; + } + } + } + /* + * Final phase: allocate anything we can! + * + * Higher order allocations, GFP_ATOMIC allocations and + * recursive allocations (PF_MEMALLOC) end up here. + * + * Only recursive allocations can use the very last pages + * in the system, otherwise it would be just too easy to + * deadlock the system... + */ zone = zonelist->zones; min = 1UL << order; for (;;) { - unsigned long local_min; zone_t *z = *(zone++); + struct page * page = NULL; if (!z) break; - local_min = z->pages_min; - if (!(gfp_mask & __GFP_WAIT)) - local_min >>= 2; - min += local_min; - if (z->free_pages > min) { + /* + * SUBTLE: direct_reclaim is only possible if the task + * becomes PF_MEMALLOC while looping above. This will + * happen when the OOM killer selects this task for + * death. + */ + if (direct_reclaim) { + page = reclaim_page(z); + if (page) + return page; + } + + /* XXX: is pages_min/4 a good amount to reserve for this? */ + min += z->pages_min / 4; + if (z->free_pages > min || ((current->flags & PF_MEMALLOC) && !in_interrupt())) { page = rmqueue(z, order); if (page) return page; } } + goto out_failed; - /* here we're in the low on memory slow path */ -rebalance: - if (current->flags & (PF_MEMALLOC | PF_MEMDIE)) { + /* + * Naive "defragmentation" for higher-order allocations. First we + * free the inactive_clean pages to see if we can allocate our + * allocation, then we call page_launder() to clean some dirty + * pages, and last we try once more. + * + * We might want to turn this into something which defragments + * memory based on physical page, simply by looking for unmapped + * pages next to pages on the free list... + */ +defragment: + { + int freed = 0; +defragment_again: zone = zonelist->zones; for (;;) { zone_t *z = *(zone++); if (!z) break; - - page = rmqueue(z, order); - if (page) - return page; + if (!z->size) + continue; + while (z->inactive_clean_pages) { + struct page * page; + /* Move one page to the free list. */ + page = reclaim_page(z); + if (!page) + break; + __free_page(page); + /* Try if the allocation succeeds. */ + page = rmqueue(z, order); + if (page) + return page; + } } - return NULL; - } - - /* Atomic allocations - we can't balance anything */ - if (!(gfp_mask & __GFP_WAIT)) - return NULL; - - page = balance_classzone(classzone, gfp_mask, order, &freed); - if (page) - return page; - - zone = zonelist->zones; - min = 1UL << order; - for (;;) { - zone_t *z = *(zone++); - if (!z) - break; - min += z->pages_min; - if (z->free_pages > min) { - page = rmqueue(z, order); - if (page) - return page; + /* XXX: do real defragmentation instead of calling launder ? */ + if (!freed) { + freed = 1; + current->flags |= PF_MEMALLOC; + try_to_free_pages(gfp_mask); + current->flags &= ~PF_MEMALLOC; + goto defragment_again; } } - /* Don't let big-order allocations loop */ - if (order > 3) - return NULL; - - /* Yield for kswapd, and try again */ - current->policy |= SCHED_YIELD; - __set_current_state(TASK_RUNNING); - schedule(); - goto rebalance; + +out_failed: + /* No luck.. */ +// printk(KERN_ERR "__alloc_pages: %lu-order allocation failed.\n", order); + return NULL; } /* @@ -480,14 +622,11 @@ { unsigned int sum; zone_t *zone; - pg_data_t *pgdat = pgdat_list; sum = 0; - while (pgdat) { - for (zone = pgdat->node_zones; zone < pgdat->node_zones + MAX_NR_ZONES; zone++) - sum += zone->free_pages; - pgdat = pgdat->node_next; - } + for_each_zone(zone) + sum += zone->free_pages; + return sum; } @@ -496,23 +635,21 @@ */ unsigned int nr_free_buffer_pages (void) { - pg_data_t *pgdat = pgdat_list; + pg_data_t *pgdat; unsigned int sum = 0; - do { + for_each_pgdat(pgdat) { zonelist_t *zonelist = pgdat->node_zonelists + (GFP_USER & GFP_ZONEMASK); zone_t **zonep = zonelist->zones; zone_t *zone; for (zone = *zonep++; zone; zone = *zonep++) { - unsigned long size = zone->size; - unsigned long high = zone->pages_high; - if (size > high) - sum += size - high; + sum += zone->free_pages; + sum += zone->inactive_clean_pages; + sum += zone->inactive_dirty_pages; } - pgdat = pgdat->node_next; - } while (pgdat); + } return sum; } @@ -520,13 +657,12 @@ #if CONFIG_HIGHMEM unsigned int nr_free_highpages (void) { - pg_data_t *pgdat = pgdat_list; + pg_data_t *pgdat; unsigned int pages = 0; - while (pgdat) { + for_each_pgdat(pgdat) pages += pgdat->node_zones[ZONE_HIGHMEM].free_pages; - pgdat = pgdat->node_next; - } + return pages; } #endif @@ -563,10 +699,18 @@ tmpdat = tmpdat->node_next; } - printk("( Active: %d, inactive: %d, free: %d )\n", - nr_active_pages, - nr_inactive_pages, - nr_free_pages()); + printk("Free pages: %6dkB (%6dkB HighMem)\n", + nr_free_pages() << (PAGE_SHIFT-10), + nr_free_highpages() << (PAGE_SHIFT-10)); + + printk("( Active: %d, inactive_dirty: %d, inactive_clean: %d, free: %d (%d %d %d) )\n", + nr_active_pages, + nr_inactive_dirty_pages, + nr_inactive_clean_pages, + nr_free_pages(), + freepages.min, + freepages.low, + freepages.high); for (type = 0; type < MAX_NR_ZONES; type++) { struct list_head *head, *curr; @@ -726,9 +870,6 @@ printk("On node %d totalpages: %lu\n", nid, realtotalpages); - INIT_LIST_HEAD(&active_list); - INIT_LIST_HEAD(&inactive_list); - /* * Some architectures (with lots of mem and discontinous memory * maps) have to search for a good mem_map area: @@ -751,7 +892,7 @@ offset = lmem_map - mem_map; for (j = 0; j < MAX_NR_ZONES; j++) { zone_t *zone = pgdat->node_zones + j; - unsigned long mask; + unsigned long mask, extrafree = 0; unsigned long size, realsize; zone_table[nid * MAX_NR_ZONES + j] = zone; @@ -765,7 +906,13 @@ zone->lock = SPIN_LOCK_UNLOCKED; zone->zone_pgdat = pgdat; zone->free_pages = 0; + zone->inactive_clean_pages = 0; + zone->inactive_dirty_pages = 0; zone->need_balance = 0; + INIT_LIST_HEAD(&zone->active_list); + INIT_LIST_HEAD(&zone->inactive_dirty_list); + INIT_LIST_HEAD(&zone->inactive_clean_list); + if (!size) continue; @@ -785,15 +932,36 @@ pgdat->nr_zones = j+1; + /* + * On large memory machines we keep extra memory + * free for kernel allocations. + */ + if (zone_extrafree_ratio[j]) + extrafree = min_t(int, (realtotalpages / zone_extrafree_ratio[j]), zone_extrafree_max[j]); + if (extrafree < zone_balance_max[j]) + extrafree = 0; + mask = (realsize / zone_balance_ratio[j]); if (mask < zone_balance_min[j]) mask = zone_balance_min[j]; - else if (mask > zone_balance_max[j]) - mask = zone_balance_max[j]; - zone->pages_min = mask; - zone->pages_low = mask*2; - zone->pages_high = mask*3; - + zone->pages_min = extrafree + min(mask, (unsigned long)zone_balance_max[j]); + zone->pages_low = extrafree + mask*2; + zone->pages_high = extrafree + mask*3; + zone->pages_plenty = extrafree + mask*6; + /* + * Add these free targets to the global free target; + * we have to be SURE that freepages.high is higher + * than SUM [zone->pages_min] for all zones, otherwise + * we may have bad bad problems. + * + * This means we cannot make the freepages array writable + * in /proc, but have to add a separate extra_free_target + * for people who require it to catch load spikes in eg. + * gigabit ethernet routing... + */ + freepages.min += zone->pages_min; + freepages.low += zone->pages_low; + freepages.high += zone->pages_high; zone->zone_mem_map = mem_map + offset; zone->zone_start_mapnr = offset; zone->zone_start_paddr = zone_start_paddr; diff -Nru a/mm/rmap.c b/mm/rmap.c --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/mm/rmap.c Fri Mar 1 18:19:44 2002 @@ -0,0 +1,384 @@ +/* + * mm/rmap.c - physical to virtual reverse mappings + * + * Copyright 2001, Rik van Riel + * Released under the General Public License (GPL). + * + * + * Simple, low overhead pte-based reverse mapping scheme. + * This is kept modular because we may want to experiment + * with object-based reverse mapping schemes. Please try + * to keep this thing as modular as possible. + */ + +/* + * Locking: + * - the page->pte_chain is protected by the pagemap_lru_lock, + * we probably want to change this to a per-page lock in the + * future + * - because swapout locking is opposite to the locking order + * in the page fault path, the swapout path uses trylocks + * on the mm->page_table_lock + */ +#include +#include +#include + +#include +#include +#include + +/* #define DEBUG_RMAP */ + +/* + * Shared pages have a chain of pte_chain structures, used to locate + * all the mappings to this page. We only need a pointer to the pte + * here, the page struct for the page table page contains the process + * it belongs to and the offset within that process. + * + * A singly linked list should be fine for most, if not all, workloads. + * On fork-after-exec the mapping we'll be removing will still be near + * the start of the list, on mixed application systems the short-lived + * processes will have their mappings near the start of the list and + * in systems with long-lived applications the relative overhead of + * exit() will be lower since the applications are long-lived. + */ +struct pte_chain { + struct pte_chain * next; + pte_t * ptep; +}; + +static struct pte_chain * pte_chain_freelist; +static inline struct pte_chain * pte_chain_alloc(void); +static inline void pte_chain_free(struct pte_chain *, struct pte_chain *, struct page *); +static void alloc_new_pte_chains(void); + +/** + * page_referenced - test if the page was referenced + * @page: the page to test + * + * Quick test_and_clear_referenced for all mappings to a page, + * returns the number of processes which referenced the page. + * Caller needs to hold the pagemap_lru_lock. + */ +int FASTCALL(page_referenced(struct page *)); +int page_referenced(struct page * page) +{ + struct pte_chain * pc; + int referenced = 0; + + if (PageTestandClearReferenced(page)) + referenced++; + + /* Check all the page tables mapping this page. */ + for (pc = page->pte_chain; pc; pc = pc->next) { + if (ptep_test_and_clear_young(pc->ptep)) + referenced++; + } + + return referenced; +} + +/** + * page_add_rmap - add reverse mapping entry to a page + * @page: the page to add the mapping to + * @ptep: the page table entry mapping this page + * + * Add a new pte reverse mapping to a page. + * The caller needs to hold the mm->page_table_lock. + */ +void FASTCALL(page_add_rmap(struct page *, pte_t *)); +void page_add_rmap(struct page * page, pte_t * ptep) +{ + struct pte_chain * pte_chain; + + if (!VALID_PAGE(page) || PageReserved(page)) + return; + + spin_lock(&pagemap_lru_lock); +#ifdef DEBUG_RMAP + if (!page || !ptep) + BUG(); + if (!pte_present(*ptep)) + BUG(); + if (!ptep_to_mm(ptep)); + BUG(); + { + struct pte_chain * pc; + for (pc = page->pte_chain; pc; pc = pc->next) { + if (pc->ptep == ptep) + BUG(); + } + } +#endif + pte_chain = pte_chain_alloc(); + + /* Hook up the pte_chain to the page. */ + pte_chain->ptep = ptep; + pte_chain->next = page->pte_chain; + page->pte_chain = pte_chain; + + spin_unlock(&pagemap_lru_lock); +} + +/** + * page_remove_rmap - take down reverse mapping to a page + * @page: page to remove mapping from + * @ptep: page table entry to remove + * + * Removes the reverse mapping from the pte_chain of the page, + * after that the caller can clear the page table entry and free + * the page. + * Caller needs to hold the mm->page_table_lock. + */ +void FASTCALL(page_remove_rmap(struct page *, pte_t *)); +void page_remove_rmap(struct page * page, pte_t * ptep) +{ + struct pte_chain * pc, * prev_pc = NULL; + + if (!page || !ptep) + BUG(); + if (!VALID_PAGE(page) || PageReserved(page)) + return; + + spin_lock(&pagemap_lru_lock); + for (pc = page->pte_chain; pc; prev_pc = pc, pc = pc->next) { + if (pc->ptep == ptep) { + pte_chain_free(pc, prev_pc, page); + goto out; + } + } +#ifdef DEBUG_RMAP + /* Not found. This should NEVER happen! */ + printk(KERN_ERR "page_remove_rmap: pte_chain %p not present.\n", ptep); + printk(KERN_ERR "page_remove_rmap: only found: "); + for (pc = page->pte_chain; pc; pc = pc->next) + printk("%p ", pc->ptep); + printk("\n"); + printk(KERN_ERR "page_remove_rmap: driver cleared PG_reserved ?\n"); +#endif + +out: + spin_unlock(&pagemap_lru_lock); + return; + +} + +/** + * try_to_unmap_one - worker function for try_to_unmap + * @page: page to unmap + * @ptep: page table entry to unmap from page + * + * Internal helper function for try_to_unmap, called for each page + * table entry mapping a page. Because locking order here is opposite + * to the locking order used by the page fault path, we use trylocks. + * Locking: + * pagemap_lru_lock page_launder() + * page lock page_launder(), trylock + * mm->page_table_lock try_to_unmap_one(), trylock + */ +int FASTCALL(try_to_unmap_one(struct page *, pte_t *)); +int try_to_unmap_one(struct page * page, pte_t * ptep) +{ + unsigned long address = ptep_to_address(ptep); + struct mm_struct * mm = ptep_to_mm(ptep); + struct vm_area_struct * vma; + pte_t pte; + int ret; + + if (!mm) + BUG(); + + /* + * We need the page_table_lock to protect us from page faults, + * munmap, fork, etc... + */ + if (!spin_trylock(&mm->page_table_lock)) + return SWAP_AGAIN; + + /* During mremap, it's possible pages are not in a VMA. */ + vma = find_vma(mm, address); + if (!vma) { + ret = SWAP_FAIL; + goto out_unlock; + } + + /* The page is mlock()d, we cannot swap it out. */ + if (vma->vm_flags & VM_LOCKED) { + ret = SWAP_FAIL; + goto out_unlock; + } + + /* Nuke the page table entry. */ + pte = ptep_get_and_clear(ptep); + flush_tlb_page(vma, address); + flush_cache_page(vma, address); + + /* Store the swap location in the pte. See handle_pte_fault() ... */ + if (PageSwapCache(page)) { + swp_entry_t entry; + entry.val = page->index; + swap_duplicate(entry); + set_pte(ptep, swp_entry_to_pte(entry)); + } + + /* Move the dirty bit to the physical page now the pte is gone. */ + if (pte_dirty(pte)) + set_page_dirty(page); + + mm->rss--; + page_cache_release(page); + ret = SWAP_SUCCESS; + +out_unlock: + spin_unlock(&mm->page_table_lock); + return ret; +} + +/** + * try_to_unmap - try to remove all page table mappings to a page + * @page: the page to get unmapped + * + * Tries to remove all the page table entries which are mapping this + * page, used in the pageout path. Caller must hold pagemap_lru_lock + * and the page lock. Return values are: + * + * SWAP_SUCCESS - we succeeded in removing all mappings + * SWAP_AGAIN - we missed a trylock, try again later + * SWAP_FAIL - the page is unswappable + * SWAP_ERROR - an error occurred + */ +int FASTCALL(try_to_unmap(struct page *)); +int try_to_unmap(struct page * page) +{ + struct pte_chain * pc, * next_pc, * prev_pc = NULL; + int ret = SWAP_SUCCESS; + + /* This page should not be on the pageout lists. */ + if (!VALID_PAGE(page) || PageReserved(page)) + BUG(); + if (!PageLocked(page)) + BUG(); + /* We need backing store to swap out a page. */ + if (!page->mapping) + BUG(); + + for (pc = page->pte_chain; pc; pc = next_pc) { + next_pc = pc->next; + switch (try_to_unmap_one(page, pc->ptep)) { + case SWAP_SUCCESS: + /* Free the pte_chain struct. */ + pte_chain_free(pc, prev_pc, page); + break; + case SWAP_AGAIN: + /* Skip this pte, remembering status. */ + prev_pc = pc; + ret = SWAP_AGAIN; + continue; + case SWAP_FAIL: + return SWAP_FAIL; + case SWAP_ERROR: + return SWAP_ERROR; + } + } + + return ret; +} + +/** + * page_over_rsslimit - test if the page is over its RSS limit + * @page - page to test + * + * This function returns true if the process owning this page + * is over its RSS (resident set size) limit. For shared pages + * we make the optimisation of only checking the first process + * in the pte_chain list, this should catch hogs while not + * evicting pages shared by many processes. + * The caller needs to hold the pagemap_lru_lock. + */ +int FASTCALL(page_over_rsslimit(struct page *)); +int page_over_rsslimit(struct page * page) +{ + struct pte_chain * pte_chain = page->pte_chain; + struct mm_struct * mm; + pte_t * ptep; + + /* No process is using the page. */ + if (!pte_chain) + return 0; + + ptep = pte_chain->ptep; + mm = ptep_to_mm(ptep); + + return mm->rlimit_rss && (mm->rss > mm->rlimit_rss); +} + +/** + * pte_chain_free - free pte_chain structure + * @pte_chain: pte_chain struct to free + * @prev_pte_chain: previous pte_chain on the list (may be NULL) + * @page: page this pte_chain hangs off (may be NULL) + * + * This function unlinks pte_chain from the singly linked list it + * may be on and adds the pte_chain to the free list. May also be + * called for new pte_chain structures which aren't on any list yet. + * Caller needs to hold the pagemap_lru_list. + */ +static inline void pte_chain_free(struct pte_chain * pte_chain, struct pte_chain * prev_pte_chain, struct page * page) +{ + if (prev_pte_chain) + prev_pte_chain->next = pte_chain->next; + else if (page) + page->pte_chain = pte_chain->next; + + pte_chain->ptep = NULL; + pte_chain->next = pte_chain_freelist; + pte_chain_freelist = pte_chain; +} + +/** + * pte_chain_alloc - allocate a pte_chain struct + * + * Returns a pointer to a fresh pte_chain structure. Allocates new + * pte_chain structures as required. + * Caller needs to hold the pagemap_lru_lock. + */ +static inline struct pte_chain * pte_chain_alloc(void) +{ + struct pte_chain * pte_chain; + + /* Allocate new pte_chain structs as needed. */ + if (!pte_chain_freelist) + alloc_new_pte_chains(); + + /* Grab the first pte_chain from the freelist. */ + pte_chain = pte_chain_freelist; + pte_chain_freelist = pte_chain->next; + pte_chain->next = NULL; + + return pte_chain; +} + +/** + * alloc_new_pte_chains - convert a free page to pte_chain structures + * + * Grabs a free page and converts it to pte_chain structures. We really + * should pre-allocate these earlier in the pagefault path or come up + * with some other trick. + * + * Note that we cannot use the slab cache because the pte_chain structure + * is way smaller than the minimum size of a slab cache allocation. + */ +static void alloc_new_pte_chains(void) +{ + struct pte_chain * pte_chain = (void *) get_zeroed_page(GFP_ATOMIC); + int i = PAGE_SIZE / sizeof(struct pte_chain); + + if (pte_chain) { + for (; i-- > 0; pte_chain++) + pte_chain_free(pte_chain, NULL, NULL); + } else { + /* Yeah yeah, I'll fix the pte_chain allocation ... */ + panic("Fix pte_chain allocation, you lazy bastard!\n"); + } +} diff -Nru a/mm/slab.c b/mm/slab.c --- a/mm/slab.c Fri Mar 1 18:19:44 2002 +++ b/mm/slab.c Fri Mar 1 18:19:44 2002 @@ -911,34 +911,45 @@ #define drain_cpu_caches(cachep) do { } while (0) #endif +/** + * Called with the &cachep->spinlock held, returns number of slabs released + */ +static int __kmem_cache_shrink_locked(kmem_cache_t *cachep) +{ + slab_t *slabp; + int ret = 0; + + /* If the cache is growing, stop shrinking. */ + while (!cachep->growing) { + struct list_head *p; + + p = cachep->slabs_free.prev; + if (p == &cachep->slabs_free) + break; + + slabp = list_entry(cachep->slabs_free.prev, slab_t, list); +#if DEBUG + if (slabp->inuse) + BUG(); +#endif + list_del(&slabp->list); + + spin_unlock_irq(&cachep->spinlock); + kmem_slab_destroy(cachep, slabp); + ret++; + spin_lock_irq(&cachep->spinlock); + } + return ret; +} + static int __kmem_cache_shrink(kmem_cache_t *cachep) { - slab_t *slabp; int ret; drain_cpu_caches(cachep); spin_lock_irq(&cachep->spinlock); - - /* If the cache is growing, stop shrinking. */ - while (!cachep->growing) { - struct list_head *p; - - p = cachep->slabs_free.prev; - if (p == &cachep->slabs_free) - break; - - slabp = list_entry(cachep->slabs_free.prev, slab_t, list); -#if DEBUG - if (slabp->inuse) - BUG(); -#endif - list_del(&slabp->list); - - spin_unlock_irq(&cachep->spinlock); - kmem_slab_destroy(cachep, slabp); - spin_lock_irq(&cachep->spinlock); - } + __kmem_cache_shrink_locked(cachep); ret = !list_empty(&cachep->slabs_full) || !list_empty(&cachep->slabs_partial); spin_unlock_irq(&cachep->spinlock); return ret; @@ -957,6 +968,24 @@ BUG(); return __kmem_cache_shrink(cachep); +} + +/** + * kmem_cache_shrink_nr - Shrink a cache returning pages released + */ +int kmem_cache_shrink_nr(kmem_cache_t *cachep) +{ + int ret; + + if (!cachep || in_interrupt() || !is_chained_kmem_cache(cachep)) + BUG(); + + drain_cpu_caches(cachep); + + spin_lock_irq(&cachep->spinlock); + ret = __kmem_cache_shrink_locked(cachep); + spin_unlock_irq(&cachep->spinlock); + return ret<<(cachep->gfporder); } /** diff -Nru a/mm/swap.c b/mm/swap.c --- a/mm/swap.c Fri Mar 1 18:19:44 2002 +++ b/mm/swap.c Fri Mar 1 18:19:44 2002 @@ -15,15 +15,29 @@ #include #include -#include #include #include #include +#include #include #include /* for copy_to/from_user */ #include +/* + * We identify three levels of free memory. We never let free mem + * fall below the freepages.min except for atomic allocations. We + * start background swapping if we fall below freepages.high free + * pages, and we begin intensive swapping below freepages.low. + * + * Actual initialization is done in mm/page_alloc.c + */ +freepages_t freepages = { + 0, /* freepages.min */ + 0, /* freepages.low */ + 0 /* freepages.high */ +}; + /* How many pages do we try to swap or page in/out together? */ int page_cluster; @@ -33,17 +47,102 @@ 8, /* do swap I/O in clusters of this size */ }; +/** + * (de)activate_page - move pages from/to active and inactive lists + * @page: the page we want to move + * @nolock - are we already holding the pagemap_lru_lock? + * + * Deactivate_page will move an active page to the right + * inactive list, while activate_page will move a page back + * from one of the inactive lists to the active list. If + * called on a page which is not on any of the lists, the + * page is left alone. + */ +void FASTCALL(deactivate_page_nolock(struct page *)); +void deactivate_page_nolock(struct page * page) +{ + /* + * Don't touch it if it's not on the active list. + * (some pages aren't on any list at all) + */ + ClearPageReferenced(page); + page->age = 0; + if (PageActive(page)) { + del_page_from_active_list(page); + add_page_to_inactive_dirty_list(page); + } +} + +void FASTCALL(deactivate_page(struct page *)); +void deactivate_page(struct page * page) +{ + spin_lock(&pagemap_lru_lock); + deactivate_page_nolock(page); + spin_unlock(&pagemap_lru_lock); +} + +/** + * drop_page - like deactivate_page, but try inactive_clean list + * @page: the page to drop + * + * Try to move a page to the inactive_clean list, this succeeds if the + * page is clean and not in use by anybody. If the page cannot be placed + * on the inactive_clean list it is placed on the inactive_dirty list + * instead. + * + * Note: this function gets called with the pagemap_lru_lock held. + */ +void FASTCALL(drop_page(struct page *)); +void drop_page(struct page * page) +{ + if (!TryLockPage(page)) { + if (page->mapping && page->buffers) { + page_cache_get(page); + spin_unlock(&pagemap_lru_lock); + try_to_release_page(page, GFP_NOIO); + spin_lock(&pagemap_lru_lock); + page_cache_release(page); + } + UnlockPage(page); + } + + /* Make sure the page really is reclaimable. */ + if (!page->mapping || PageDirty(page) || page->pte_chain || + page->buffers || page_count(page) > 1) + deactivate_page_nolock(page); + + else if (page_count(page) == 1) { + ClearPageReferenced(page); + page->age = 0; + if (PageActive(page)) { + del_page_from_active_list(page); + add_page_to_inactive_clean_list(page); + } else if (PageInactiveDirty(page)) { + del_page_from_inactive_dirty_list(page); + add_page_to_inactive_clean_list(page); + } + } +} + /* * Move an inactive page to the active list. */ -static inline void activate_page_nolock(struct page * page) +void FASTCALL(activate_page_nolock(struct page *)); +void activate_page_nolock(struct page * page) { - if (PageLRU(page) && !PageActive(page)) { - del_page_from_inactive_list(page); + if (PageInactiveDirty(page)) { + del_page_from_inactive_dirty_list(page); + add_page_to_active_list(page); + } else if (PageInactiveClean(page)) { + del_page_from_inactive_clean_list(page); add_page_to_active_list(page); } + + /* Make sure the page gets a fair chance at staying active. */ + page->age = max((int)page->age, PAGE_AGE_START); } +void FASTCALL(activate_page(struct page *)); void activate_page(struct page * page) { spin_lock(&pagemap_lru_lock); @@ -55,11 +154,12 @@ * lru_cache_add: add a page to the page lists * @page: the page to add */ +void FASTCALL(lru_cache_add(struct page *)); void lru_cache_add(struct page * page) { - if (!TestSetPageLRU(page)) { + if (!PageLRU(page)) { spin_lock(&pagemap_lru_lock); - add_page_to_inactive_list(page); + add_page_to_active_list(page); spin_unlock(&pagemap_lru_lock); } } @@ -71,14 +171,15 @@ * This function is for when the caller already holds * the pagemap_lru_lock. */ +void FASTCALL(__lru_cache_del(struct page *)); void __lru_cache_del(struct page * page) { - if (TestClearPageLRU(page)) { - if (PageActive(page)) { - del_page_from_active_list(page); - } else { - del_page_from_inactive_list(page); - } + if (PageActive(page)) { + del_page_from_active_list(page); + } else if (PageInactiveDirty(page)) { + del_page_from_inactive_dirty_list(page); + } else if (PageInactiveClean(page)) { + del_page_from_inactive_clean_list(page); } } @@ -86,6 +187,7 @@ * lru_cache_del: remove a page from the page lists * @page: the page to remove */ +void FASTCALL(lru_cache_del(struct page *)); void lru_cache_del(struct page * page) { spin_lock(&pagemap_lru_lock); diff -Nru a/mm/swap_state.c b/mm/swap_state.c --- a/mm/swap_state.c Fri Mar 1 18:19:44 2002 +++ b/mm/swap_state.c Fri Mar 1 18:19:44 2002 @@ -89,6 +89,40 @@ return 0; } +/** + * add_to_swap - allocate swap space for a page + * @page: page we want to move to swap + * + * Allocate swap space for the page and add the page to the + * swap cache. Caller needs to hold the page lock. + */ +int add_to_swap(struct page * page) +{ + swp_entry_t entry; + + if (!PageLocked(page)) + BUG(); + + for (;;) { + entry = get_swap_page(); + if (!entry.val) + return 0; + /* + * Add it to the swap cache and mark it dirty + * (adding to the page cache will clear the dirty + * and uptodate bits, so we need to do it again) + */ + if (add_to_swap_cache(page, entry) == 0) { + SetPageUptodate(page); + set_page_dirty(page); + swap_free(entry); + return 1; + } + /* Raced with "speculative" read_swap_cache_async */ + swap_free(entry); + } +} + /* * This must be called only on pages that have * been verified to be in the swap cache. diff -Nru a/mm/swapfile.c b/mm/swapfile.c --- a/mm/swapfile.c Fri Mar 1 18:19:44 2002 +++ b/mm/swapfile.c Fri Mar 1 18:19:44 2002 @@ -374,6 +374,7 @@ return; get_page(page); set_pte(dir, pte_mkold(mk_pte(page, vma->vm_page_prot))); + page_add_rmap(page, dir); swap_free(entry); ++vma->vm_mm->rss; } diff -Nru a/mm/vmscan.c b/mm/vmscan.c --- a/mm/vmscan.c Fri Mar 1 18:19:44 2002 +++ b/mm/vmscan.c Fri Mar 1 18:19:44 2002 @@ -1,6 +1,9 @@ /* * linux/mm/vmscan.c * + * The pageout daemon, decides which pages to evict (swap out) and + * does the actual work of freeing them. + * * Copyright (C) 1991, 1992, 1993, 1994 Linus Torvalds * * Swap reorganised 29.12.95, Stephen Tweedie. @@ -21,9 +24,12 @@ #include #include #include +#include #include +static void refill_freelist(void); +static void wakeup_memwaiters(void); /* * The "priority" of VM scanning is how much of the queues we * will scan in one go. A value of 6 for DEF_PRIORITY implies @@ -32,371 +38,275 @@ */ #define DEF_PRIORITY (6) -/* - * The swap-out function returns 1 if it successfully - * scanned all the pages it was asked to (`count'). - * It returns zero if it couldn't do anything, - * - * rss may decrease because pages are shared, but this - * doesn't count as having freed a page. - */ - -/* mm->page_table_lock is held. mmap_sem is not held */ -static inline int try_to_swap_out(struct mm_struct * mm, struct vm_area_struct* vma, unsigned long address, pte_t * page_table, struct page *page, zone_t * classzone) +static inline void age_page_up(struct page *page) { - pte_t pte; - swp_entry_t entry; + page->age = min((int) (page->age + PAGE_AGE_ADV), PAGE_AGE_MAX); +} - /* Don't look at this pte if it's been accessed recently. */ - if ((vma->vm_flags & VM_LOCKED) || ptep_test_and_clear_young(page_table)) { - mark_page_accessed(page); - return 0; - } +static inline void age_page_down(struct page *page) +{ + page->age -= min(PAGE_AGE_DECL, (int)page->age); +} - /* Don't bother unmapping pages that are active */ - if (PageActive(page)) - return 0; +static inline int page_mapping_inuse(struct page * page) +{ + struct address_space * mapping = page->mapping; - /* Don't bother replenishing zones not under pressure.. */ - if (!memclass(page_zone(page), classzone)) - return 0; + /* Page is in somebody's page tables. */ + if (page->pte_chain) + return 1; - if (TryLockPage(page)) + /* XXX: does this happen ? */ + if (!mapping) return 0; - /* From this point on, the odds are that we're going to - * nuke this pte, so read and clear the pte. This hook - * is needed on CPUs which update the accessed and dirty - * bits in hardware. - */ - flush_cache_page(vma, address); - pte = ptep_get_and_clear(page_table); - flush_tlb_page(vma, address); - - if (pte_dirty(pte)) - set_page_dirty(page); + /* File is mmaped by somebody. */ + if (mapping->i_mmap || mapping->i_mmap_shared) + return 1; - /* - * Is the page already in the swap cache? If so, then - * we can just drop our reference to it without doing - * any IO - it's already up-to-date on disk. - */ - if (PageSwapCache(page)) { - entry.val = page->index; - swap_duplicate(entry); -set_swap_pte: - set_pte(page_table, swp_entry_to_pte(entry)); -drop_pte: - mm->rss--; - UnlockPage(page); - { - int freeable = page_count(page) - !!page->buffers <= 2; - page_cache_release(page); - return freeable; - } - } + return 0; +} - /* - * Is it a clean page? Then it must be recoverable - * by just paging it in again, and we can just drop - * it.. or if it's dirty but has backing store, - * just mark the page dirty and drop it. - * - * However, this won't actually free any real - * memory, as the page will just be in the page cache - * somewhere, and as such we should just continue - * our scan. - * - * Basically, this just makes it possible for us to do - * some real work in the future in "refill_inactive()". - */ - if (page->mapping) - goto drop_pte; - if (!PageDirty(page)) - goto drop_pte; +/** + * reclaim_page - reclaims one page from the inactive_clean list + * @zone: reclaim a page from this zone + * + * The pages on the inactive_clean can be instantly reclaimed. + * The tests look impressive, but most of the time we'll grab + * the first page of the list and exit successfully. + */ +struct page * reclaim_page(zone_t * zone) +{ + struct page * page = NULL; + struct list_head * page_lru; + swp_entry_t entry = {0}; + int maxscan; /* - * Anonymous buffercache pages can be left behind by - * concurrent truncate and pagefault. + * We need to hold the pagecache_lock around all tests to make sure + * reclaim_page() cannot race with find_get_page() and friends. */ - if (page->buffers) - goto preserve; + spin_lock(&pagemap_lru_lock); + spin_lock(&pagecache_lock); + maxscan = zone->inactive_clean_pages; + while (maxscan-- && !list_empty(&zone->inactive_clean_list)) { + page_lru = zone->inactive_clean_list.prev; + page = list_entry(page_lru, struct page, lru); - /* - * This is a dirty, swappable page. First of all, - * get a suitable swap entry for it, and make sure - * we have the swap cache set up to associate the - * page with that swap entry. - */ - for (;;) { - entry = get_swap_page(); - if (!entry.val) - break; - /* Add it to the swap cache and mark it dirty - * (adding to the page cache will clear the dirty - * and uptodate bits, so we need to do it again) - */ - if (add_to_swap_cache(page, entry) == 0) { - SetPageUptodate(page); - set_page_dirty(page); - goto set_swap_pte; + /* Wrong page on list?! (list corruption, should not happen) */ + if (unlikely(!PageInactiveClean(page))) { + printk("VM: reclaim_page, wrong page on list.\n"); + list_del(page_lru); + page_zone(page)->inactive_clean_pages--; + continue; } - /* Raced with "speculative" read_swap_cache_async */ - swap_free(entry); - } - - /* No swap space left */ -preserve: - set_pte(page_table, pte); - UnlockPage(page); - return 0; -} -/* mm->page_table_lock is held. mmap_sem is not held */ -static inline int swap_out_pmd(struct mm_struct * mm, struct vm_area_struct * vma, pmd_t *dir, unsigned long address, unsigned long end, int count, zone_t * classzone) -{ - pte_t * pte; - unsigned long pmd_end; - - if (pmd_none(*dir)) - return count; - if (pmd_bad(*dir)) { - pmd_ERROR(*dir); - pmd_clear(dir); - return count; - } - - pte = pte_offset(dir, address); - - pmd_end = (address + PMD_SIZE) & PMD_MASK; - if (end > pmd_end) - end = pmd_end; + /* Page is being freed */ + if (unlikely(page_count(page)) == 0) { + list_del(page_lru); + list_add(page_lru, &zone->inactive_clean_list); + continue; + } - do { - if (pte_present(*pte)) { - struct page *page = pte_page(*pte); + /* Page cannot be reclaimed ? Move to inactive_dirty list. */ + if (unlikely(page->pte_chain || page->buffers || + PageReferenced(page) || PageDirty(page) || + page_count(page) > 1 || TryLockPage(page))) { + del_page_from_inactive_clean_list(page); + add_page_to_inactive_dirty_list(page); + continue; + } - if (VALID_PAGE(page) && !PageReserved(page)) { - count -= try_to_swap_out(mm, vma, address, pte, page, classzone); - if (!count) { - address += PAGE_SIZE; - break; - } - } + /* OK, remove the page from the caches. */ + if (PageSwapCache(page)) { + entry.val = page->index; + __delete_from_swap_cache(page); + goto found_page; } - address += PAGE_SIZE; - pte++; - } while (address && (address < end)); - mm->swap_address = address; - return count; -} -/* mm->page_table_lock is held. mmap_sem is not held */ -static inline int swap_out_pgd(struct mm_struct * mm, struct vm_area_struct * vma, pgd_t *dir, unsigned long address, unsigned long end, int count, zone_t * classzone) -{ - pmd_t * pmd; - unsigned long pgd_end; + if (page->mapping) { + __remove_inode_page(page); + goto found_page; + } - if (pgd_none(*dir)) - return count; - if (pgd_bad(*dir)) { - pgd_ERROR(*dir); - pgd_clear(dir); - return count; + /* We should never ever get here. */ + printk(KERN_ERR "VM: reclaim_page, found unknown page\n"); + list_del(page_lru); + zone->inactive_clean_pages--; + UnlockPage(page); } + spin_unlock(&pagecache_lock); + spin_unlock(&pagemap_lru_lock); + return NULL; - pmd = pmd_offset(dir, address); - - pgd_end = (address + PGDIR_SIZE) & PGDIR_MASK; - if (pgd_end && (end > pgd_end)) - end = pgd_end; - - do { - count = swap_out_pmd(mm, vma, pmd, address, end, count, classzone); - if (!count) - break; - address = (address + PMD_SIZE) & PMD_MASK; - pmd++; - } while (address && (address < end)); - return count; -} - -/* mm->page_table_lock is held. mmap_sem is not held */ -static inline int swap_out_vma(struct mm_struct * mm, struct vm_area_struct * vma, unsigned long address, int count, zone_t * classzone) -{ - pgd_t *pgdir; - unsigned long end; - - /* Don't swap out areas which are reserved */ - if (vma->vm_flags & VM_RESERVED) - return count; - - pgdir = pgd_offset(mm, address); - - end = vma->vm_end; - if (address >= end) - BUG(); - do { - count = swap_out_pgd(mm, vma, pgdir, address, end, count, classzone); - if (!count) - break; - address = (address + PGDIR_SIZE) & PGDIR_MASK; - pgdir++; - } while (address && (address < end)); - return count; +found_page: + del_page_from_inactive_clean_list(page); + spin_unlock(&pagecache_lock); + spin_unlock(&pagemap_lru_lock); + if (entry.val) + swap_free(entry); + UnlockPage(page); + page->age = PAGE_AGE_START; + if (page_count(page) != 1) + printk("VM: reclaim_page, found page with count %d!\n", + page_count(page)); + return page; } -/* Placeholder for swap_out(): may be updated by fork.c:mmput() */ -struct mm_struct *swap_mm = &init_mm; - -/* - * Returns remaining count of pages to be swapped out by followup call. +/** + * page_dirty - do we need to write the data out to disk + * @page: page to test + * + * Returns true if the page contains data which needs to + * be written to disk. Doesn't test the page tables (yet?). */ -static inline int swap_out_mm(struct mm_struct * mm, int count, int * mmcounter, zone_t * classzone) +static inline int page_dirty(struct page *page) { - unsigned long address; - struct vm_area_struct* vma; + struct buffer_head *tmp, *bh; - /* - * Find the proper vm-area after freezing the vma chain - * and ptes. - */ - spin_lock(&mm->page_table_lock); - address = mm->swap_address; - if (address == TASK_SIZE || swap_mm != mm) { - /* We raced: don't count this mm but try again */ - ++*mmcounter; - goto out_unlock; - } - vma = find_vma(mm, address); - if (vma) { - if (address < vma->vm_start) - address = vma->vm_start; - - for (;;) { - count = swap_out_vma(mm, vma, address, count, classzone); - vma = vma->vm_next; - if (!vma) - break; - if (!count) - goto out_unlock; - address = vma->vm_start; - } - } - /* Indicate that we reached the end of address space */ - mm->swap_address = TASK_SIZE; + if (PageDirty(page)) + return 1; -out_unlock: - spin_unlock(&mm->page_table_lock); - return count; -} + if (page->mapping && !page->buffers) + return 0; -static int FASTCALL(swap_out(unsigned int priority, unsigned int gfp_mask, zone_t * classzone)); -static int swap_out(unsigned int priority, unsigned int gfp_mask, zone_t * classzone) -{ - int counter, nr_pages = SWAP_CLUSTER_MAX; - struct mm_struct *mm; + tmp = bh = page->buffers; - counter = mmlist_nr; do { - if (unlikely(current->need_resched)) { - __set_current_state(TASK_RUNNING); - schedule(); - } - - spin_lock(&mmlist_lock); - mm = swap_mm; - while (mm->swap_address == TASK_SIZE || mm == &init_mm) { - mm->swap_address = 0; - mm = list_entry(mm->mmlist.next, struct mm_struct, mmlist); - if (mm == swap_mm) - goto empty; - swap_mm = mm; - } - - /* Make sure the mm doesn't disappear when we drop the lock.. */ - atomic_inc(&mm->mm_users); - spin_unlock(&mmlist_lock); - - nr_pages = swap_out_mm(mm, nr_pages, &counter, classzone); - - mmput(mm); - - if (!nr_pages) + if (tmp->b_state & ((1<= 0); + tmp = tmp->b_this_page; + } while (tmp != bh); return 0; - -empty: - spin_unlock(&mmlist_lock); - return 0; } -static int FASTCALL(shrink_cache(int nr_pages, zone_t * classzone, unsigned int gfp_mask, int priority)); -static int shrink_cache(int nr_pages, zone_t * classzone, unsigned int gfp_mask, int priority) +/** + * page_launder_zone - clean dirty inactive pages, move to inactive_clean list + * @zone: zone to free pages in + * @gfp_mask: what operations we are allowed to do + * + * This function is called when we are low on free / inactive_clean + * pages, its purpose is to refill the free/clean list as efficiently + * as possible. + * + * This means we do writes asynchronously as long as possible and will + * only sleep on IO when we don't have another option. Since writeouts + * cause disk seeks and make read IO slower, we skip writes alltogether + * when the amount of dirty pages is small. + * + * This code is heavily inspired by the FreeBSD source code. Thanks + * go out to Matthew Dillon. + */ +#define CAN_DO_FS ((gfp_mask & __GFP_FS) && should_write) +int page_launder_zone(zone_t * zone, int gfp_mask, int priority) { + int maxscan, cleaned_pages, target; struct list_head * entry; - int max_scan = nr_inactive_pages / priority; - int max_mapped = min((nr_pages << (10 - priority)), max_scan / 10); + target = free_plenty(zone); + cleaned_pages = 0; + + /* The main launder loop. */ spin_lock(&pagemap_lru_lock); - while (--max_scan >= 0 && (entry = inactive_list.prev) != &inactive_list) { + maxscan = zone->inactive_dirty_pages >> priority; + while (maxscan-- && !list_empty(&zone->inactive_dirty_list)) { struct page * page; - - if (unlikely(current->need_resched)) { + + /* Low latency reschedule point */ + if (current->need_resched) { spin_unlock(&pagemap_lru_lock); - __set_current_state(TASK_RUNNING); schedule(); spin_lock(&pagemap_lru_lock); continue; } + entry = zone->inactive_dirty_list.prev; page = list_entry(entry, struct page, lru); - if (unlikely(!PageLRU(page))) - BUG(); - if (unlikely(PageActive(page))) - BUG(); + if (cleaned_pages > target) + break; list_del(entry); - list_add(entry, &inactive_list); + list_add(entry, &zone->inactive_dirty_list); + + /* Wrong page on list?! (list corruption, should not happen) */ + if (!PageInactiveDirty(page)) { + printk("VM: page_launder, wrong page on list.\n"); + list_del(entry); + nr_inactive_dirty_pages--; + page_zone(page)->inactive_dirty_pages--; + continue; + } /* - * Zero page counts can happen because we unlink the pages - * _after_ decrementing the usage count.. + * The page is in active use or really unfreeable. Move to + * the active list and adjust the page age if needed. */ - if (unlikely(!page_count(page))) + if (page_referenced(page) && page_mapping_inuse(page) && + !page_over_rsslimit(page)) { + del_page_from_inactive_dirty_list(page); + add_page_to_active_list(page); + page->age = max((int)page->age, PAGE_AGE_START); continue; + } - if (!memclass(page_zone(page), classzone)) + /* + * Page is being freed, don't worry about it. + */ + if (unlikely(page_count(page)) == 0) continue; - /* Racy check to avoid trylocking when not worthwhile */ - if (!page->buffers && (page_count(page) != 1 || !page->mapping)) - goto page_mapped; - /* * The page is locked. IO in progress? * Move it to the back of the list. */ - if (unlikely(TryLockPage(page))) { - if (PageLaunder(page) && (gfp_mask & __GFP_FS)) { - page_cache_get(page); - spin_unlock(&pagemap_lru_lock); - wait_on_page(page); + if (unlikely(TryLockPage(page))) + continue; + + /* + * Anonymous process memory without backing store. Try to + * allocate it some swap space here. + * + * XXX: implement swap clustering ? + */ + if (page->pte_chain && !page->mapping && !page->buffers) { + page_cache_get(page); + spin_unlock(&pagemap_lru_lock); + if (!add_to_swap(page)) { + activate_page(page); + UnlockPage(page); page_cache_release(page); spin_lock(&pagemap_lru_lock); + continue; + } + page_cache_release(page); + spin_lock(&pagemap_lru_lock); + } + + /* + * The page is mapped into the page tables of one or more + * processes. Try to unmap it here. + */ + if (page->pte_chain) { + switch (try_to_unmap(page)) { + case SWAP_ERROR: + case SWAP_FAIL: + goto page_active; + case SWAP_AGAIN: + UnlockPage(page); + continue; + case SWAP_SUCCESS: + ; /* try to free the page below */ } - continue; } - if (PageDirty(page) && is_page_cache_freeable(page) && page->mapping) { + if (PageDirty(page) && page->mapping) { /* * It is not critical here to write it only if * the page is unmapped beause any direct writer * like O_DIRECT would set the PG_dirty bitflag - * on the phisical page after having successfully + * on the physical page after having successfully * pinned it and after the I/O to the page is finished, * so the direct writes to the page cannot get lost. */ @@ -425,7 +335,7 @@ if (page->buffers) { spin_unlock(&pagemap_lru_lock); - /* avoid to free a locked page */ + /* To avoid freeing our page before we're done. */ page_cache_get(page); if (try_to_release_page(page, gfp_mask)) { @@ -443,14 +353,14 @@ /* effectively free the page here */ page_cache_release(page); - if (--nr_pages) - continue; - break; + cleaned_pages++; + continue; } else { /* - * The page is still in pagecache so undo the stuff - * before the try_to_release_page since we've not - * finished and we can now try the next step. + * We freed the buffers but may have + * slept; undo the stuff we did before + * try_to_release_page and fall through + * to the next step. */ page_cache_release(page); @@ -466,227 +376,268 @@ } } - spin_lock(&pagecache_lock); /* - * this is the non-racy check for busy page. + * If the page is really freeable now, move it to the + * inactive_clean list. + * + * We re-test everything since the page could have been + * used by somebody else while we waited on IO above. + * This test is not safe from races, but only the one + * in reclaim_page() needs to be. */ - if (!page->mapping || !is_page_cache_freeable(page)) { - spin_unlock(&pagecache_lock); + if (page->mapping && !PageDirty(page) && !page->pte_chain && + page_count(page) == 1) { + del_page_from_inactive_dirty_list(page); + add_page_to_inactive_clean_list(page); UnlockPage(page); -page_mapped: - if (--max_mapped >= 0) - continue; - + cleaned_pages++; + } else { /* - * Alert! We've found too many mapped pages on the - * inactive list, so we start swapping out now! + * OK, we don't know what to do with the page. + * It's no use keeping it here, so we move it to + * the active list. */ - spin_unlock(&pagemap_lru_lock); - swap_out(priority, gfp_mask, classzone); - return nr_pages; +page_active: + del_page_from_inactive_dirty_list(page); + add_page_to_active_list(page); + UnlockPage(page); + } + } + spin_unlock(&pagemap_lru_lock); + + /* Return the number of pages moved to the inactive_clean list. */ + return cleaned_pages; +} + +/** + * page_launder - clean dirty inactive pages, move to inactive_clean list + * @gfp_mask: what operations we are allowed to do + * + * This function iterates over all zones and calls page_launder_zone(), + * balancing still needs to be added... + */ +int page_launder(int gfp_mask) +{ + int maxtry = 1 << DEF_PRIORITY; + struct zone_struct * zone; + int freed = 0; + + /* Global balancing while we have a global shortage. */ + while (maxtry-- && free_high(ALL_ZONES) >= 0) { + for_each_zone(zone) + if (free_plenty(zone) >= 0) + freed += page_launder_zone(zone, gfp_mask, 6); + } + + /* Clean up the remaining zones with a serious shortage, if any. */ + for_each_zone(zone) + if (free_min(zone) >= 0) + freed += page_launder_zone(zone, gfp_mask, 0); + + return freed; +} + +/** + * refill_inactive_zone - scan the active list and find pages to deactivate + * @priority: how much are we allowed to scan + * + * This function will scan a portion of the active list of a zone to find + * unused pages, those pages will then be moved to the inactive list. + */ +int refill_inactive_zone(struct zone_struct * zone, int priority) +{ + int maxscan = zone->active_pages >> priority; + int target = inactive_high(zone); + struct list_head * page_lru; + int nr_deactivated = 0; + struct page * page; + + /* Take the lock while messing with the list... */ + spin_lock(&pagemap_lru_lock); + while (maxscan-- && !list_empty(&zone->active_list)) { + page_lru = zone->active_list.prev; + page = list_entry(page_lru, struct page, lru); + + /* Wrong page on list?! (list corruption, should not happen) */ + if (unlikely(!PageActive(page))) { + printk("VM: refill_inactive, wrong page on list.\n"); + list_del(page_lru); + nr_active_pages--; + continue; } /* - * It is critical to check PageDirty _after_ we made sure - * the page is freeable* so not in use by anybody. + * If the object the page is in is not in use we don't + * bother with page aging. If the page is touched again + * while on the inactive_clean list it'll be reactivated. */ - if (PageDirty(page)) { - spin_unlock(&pagecache_lock); - UnlockPage(page); + if (!page_mapping_inuse(page)) { + drop_page(page); continue; } - /* point of no return */ - if (likely(!PageSwapCache(page))) { - __remove_inode_page(page); - spin_unlock(&pagecache_lock); + /* + * Do aging on the pages. + */ + if (page_referenced(page)) { + age_page_up(page); } else { - swp_entry_t swap; - swap.val = page->index; - __delete_from_swap_cache(page); - spin_unlock(&pagecache_lock); - swap_free(swap); + age_page_down(page); } - __lru_cache_del(page); - UnlockPage(page); - - /* effectively free the page here */ - page_cache_release(page); + /* + * If the page age is 'hot' and the process using the + * page doesn't exceed its RSS limit we keep the page. + * Otherwise we move it to the inactive_dirty list. + */ + if (page->age && !page_over_rsslimit(page)) { + list_del(page_lru); + list_add(page_lru, &zone->active_list); + } else { + deactivate_page_nolock(page); + if (++nr_deactivated > target) + break; + } - if (--nr_pages) - continue; - break; + /* Low latency reschedule point */ + if (current->need_resched) { + spin_unlock(&pagemap_lru_lock); + schedule(); + spin_lock(&pagemap_lru_lock); + } } spin_unlock(&pagemap_lru_lock); - return nr_pages; + return nr_deactivated; } -/* - * This moves pages from the active list to - * the inactive list. +/** + * refill_inactive - checks all zones and refills the inactive list as needed * - * We move them the other way when we see the - * reference bit on the page. + * This function tries to balance page eviction from all zones by aging + * the pages from each zone in the same ratio until the global inactive + * shortage is resolved. After that it does one last "clean-up" scan to + * fix up local inactive shortages. */ -static void refill_inactive(int nr_pages) +int refill_inactive(void) { - struct list_head * entry; - - spin_lock(&pagemap_lru_lock); - entry = active_list.prev; - while (nr_pages && entry != &active_list) { - struct page * page; + int maxtry = 1 << DEF_PRIORITY; + zone_t * zone; + int ret = 0; - page = list_entry(entry, struct page, lru); - entry = entry->prev; - if (PageTestandClearReferenced(page)) { - list_del(&page->lru); - list_add(&page->lru, &active_list); - continue; + /* Global balancing while we have a global shortage. */ + while (maxtry-- && inactive_low(ALL_ZONES) >= 0) { + for_each_zone(zone) { + if (inactive_high(zone) >= 0) + ret += refill_inactive_zone(zone, DEF_PRIORITY); } + } - nr_pages--; - - del_page_from_active_list(page); - add_page_to_inactive_list(page); - SetPageReferenced(page); + /* Local balancing for zones which really need it. */ + for_each_zone(zone) { + if (inactive_min(zone) >= 0) + ret += refill_inactive_zone(zone, 0); } - spin_unlock(&pagemap_lru_lock); + + return ret; } -static int FASTCALL(shrink_caches(zone_t * classzone, int priority, unsigned int gfp_mask, int nr_pages)); -static int shrink_caches(zone_t * classzone, int priority, unsigned int gfp_mask, int nr_pages) +/** + * background_aging - slow background aging of zones + * @priority: priority at which to scan + * + * When the VM load is low or nonexistant, this function is + * called once a second to "sort" the pages in the VM. This + * way we know which pages to evict once a load spike happens. + * The effects of this function are very slow, the CPU usage + * should be minimal to nonexistant under most loads. + */ +static inline void background_aging(int priority) { - int chunk_size = nr_pages; - unsigned long ratio; + struct zone_struct * zone; - nr_pages -= kmem_cache_reap(gfp_mask); - if (nr_pages <= 0) - return 0; - - nr_pages = chunk_size; - /* try to keep the active list 2/3 of the size of the cache */ - ratio = (unsigned long) nr_pages * nr_active_pages / ((nr_inactive_pages + 1) * 2); - refill_inactive(ratio); + for_each_zone(zone) + if (inactive_high(zone) > 0) + refill_inactive_zone(zone, priority); +} - nr_pages = shrink_cache(nr_pages, classzone, gfp_mask, priority); - if (nr_pages <= 0) - return 0; +/* + * Worker function for kswapd and try_to_free_pages, we get + * called whenever there is a shortage of free/inactive_clean + * pages. + * + * This function will also move pages to the inactive list, + * if needed. + */ +static int do_try_to_free_pages(unsigned int gfp_mask) +{ + int ret = 0; - shrink_dcache_memory(priority, gfp_mask); - shrink_icache_memory(priority, gfp_mask); + /* + * Eat memory from filesystem page cache, buffer cache, + * dentry, inode and filesystem quota caches. + */ + ret += page_launder(gfp_mask); + ret += shrink_dcache_memory(DEF_PRIORITY, gfp_mask); + ret += shrink_icache_memory(1, gfp_mask); #ifdef CONFIG_QUOTA - shrink_dqcache_memory(DEF_PRIORITY, gfp_mask); + ret += shrink_dqcache_memory(DEF_PRIORITY, gfp_mask); #endif - return nr_pages; -} + /* + * Move pages from the active list to the inactive list. + */ + refill_inactive(); -int try_to_free_pages(zone_t *classzone, unsigned int gfp_mask, unsigned int order) -{ - int priority = DEF_PRIORITY; - int nr_pages = SWAP_CLUSTER_MAX; + /* + * Reclaim unused slab cache memory. + */ + ret += kmem_cache_reap(gfp_mask); - gfp_mask = pf_gfp_mask(gfp_mask); - do { - nr_pages = shrink_caches(classzone, priority, gfp_mask, nr_pages); - if (nr_pages <= 0) - return 1; - } while (--priority); + refill_freelist(); + + /* Start IO when needed. */ + if (free_plenty(ALL_ZONES) > 0 || free_low(ANY_ZONE) > 0) + run_task_queue(&tq_disk); /* * Hmm.. Cache shrink failed - time to kill something? * Mhwahahhaha! This is the part I really like. Giggle. */ - out_of_memory(); - return 0; -} - -DECLARE_WAIT_QUEUE_HEAD(kswapd_wait); - -static int check_classzone_need_balance(zone_t * classzone) -{ - zone_t * first_classzone; + if (!ret && free_low(ANY_ZONE) > 0) + out_of_memory(); - first_classzone = classzone->zone_pgdat->node_zones; - while (classzone >= first_classzone) { - if (classzone->free_pages > classzone->pages_high) - return 0; - classzone--; - } - return 1; + return ret; } -static int kswapd_balance_pgdat(pg_data_t * pgdat) +/** + * refill_freelist - move inactive_clean pages to free list if needed + * + * Move some pages from the inactive_clean lists to the free + * lists so atomic allocations have pages to work from. This + * function really only does something when we don't have a + * userspace load on __alloc_pages(). + * + * We refill the freelist in a bump from pages_min to pages_min * 2 + * in order to give the buddy allocator something to play with. + */ +static void refill_freelist(void) { - int need_more_balance = 0, i; + struct page * page; zone_t * zone; - for (i = pgdat->nr_zones-1; i >= 0; i--) { - zone = pgdat->node_zones + i; - if (unlikely(current->need_resched)) - schedule(); - if (!zone->need_balance) - continue; - if (!try_to_free_pages(zone, GFP_KSWAPD, 0)) { - zone->need_balance = 0; - __set_current_state(TASK_INTERRUPTIBLE); - schedule_timeout(HZ); + for_each_zone(zone) { + if (!zone->size || zone->free_pages >= zone->pages_min) continue; - } - if (check_classzone_need_balance(zone)) - need_more_balance = 1; - else - zone->need_balance = 0; - } - - return need_more_balance; -} - -static void kswapd_balance(void) -{ - int need_more_balance; - pg_data_t * pgdat; - - do { - need_more_balance = 0; - pgdat = pgdat_list; - do - need_more_balance |= kswapd_balance_pgdat(pgdat); - while ((pgdat = pgdat->node_next)); - } while (need_more_balance); -} -static int kswapd_can_sleep_pgdat(pg_data_t * pgdat) -{ - zone_t * zone; - int i; - - for (i = pgdat->nr_zones-1; i >= 0; i--) { - zone = pgdat->node_zones + i; - if (!zone->need_balance) - continue; - return 0; + while (zone->free_pages < zone->pages_min * 2) { + page = reclaim_page(zone); + if (!page) + break; + __free_page(page); + } } - - return 1; -} - -static int kswapd_can_sleep(void) -{ - pg_data_t * pgdat; - - pgdat = pgdat_list; - do { - if (kswapd_can_sleep_pgdat(pgdat)) - continue; - return 0; - } while ((pgdat = pgdat->node_next)); - - return 1; } /* @@ -705,7 +656,6 @@ int kswapd(void *unused) { struct task_struct *tsk = current; - DECLARE_WAITQUEUE(wait, tsk); daemonize(); strcpy(tsk->comm, "kswapd"); @@ -729,24 +679,156 @@ * Kswapd main loop. */ for (;;) { - __set_current_state(TASK_INTERRUPTIBLE); - add_wait_queue(&kswapd_wait, &wait); + static long recalc = 0; - mb(); - if (kswapd_can_sleep()) - schedule(); + /* + * We try to rebalance the VM either when we have a + * global shortage of free pages or when one particular + * zone is very short on free pages. + */ + if (free_high(ALL_ZONES) >= 0 || free_low(ANY_ZONE) > 0) + do_try_to_free_pages(GFP_KSWAPD); + + refill_freelist(); + + /* Once a second ... */ + if (time_after(jiffies, recalc + HZ)) { + recalc = jiffies; + + /* Do background page aging. */ + background_aging(DEF_PRIORITY); + } + + wakeup_memwaiters(); + } +} + +DECLARE_WAIT_QUEUE_HEAD(kswapd_wait); +DECLARE_WAIT_QUEUE_HEAD(kswapd_done); +#define VM_SHOULD_SLEEP (free_low(ALL_ZONES) > (freepages.min / 2)) + +/** + * wakeup_kswapd - wake up the pageout daemon + * gfp_mask: page freeing flags + * + * This function wakes up kswapd and can, under heavy VM pressure, + * put the calling task to sleep temporarily. + */ +void wakeup_kswapd(unsigned int gfp_mask) +{ + DECLARE_WAITQUEUE(wait, current); - __set_current_state(TASK_RUNNING); + /* If we're in the memory freeing business ourself, don't sleep + * but just wake kswapd and go back to businesss. + */ + if (current->flags & PF_MEMALLOC) { + wake_up_interruptible(&kswapd_wait); + return; + } + + /* We need all of kswapd's GFP flags, otherwise we can't sleep on it. + * We still wake kswapd of course. + */ + if ((gfp_mask & GFP_KSWAPD) != GFP_KSWAPD) { + wake_up_interruptible(&kswapd_wait); + return; + } + + add_wait_queue(&kswapd_done, &wait); + set_current_state(TASK_UNINTERRUPTIBLE); + + /* Wake kswapd .... */ + wake_up_interruptible(&kswapd_wait); + + /* ... and check if we need to wait on it */ + if (VM_SHOULD_SLEEP) + schedule(); + set_current_state(TASK_RUNNING); + remove_wait_queue(&kswapd_done, &wait); +} + +static void wakeup_memwaiters(void) +{ + DECLARE_WAITQUEUE(wait, current); + + /* Enough free RAM, we can easily keep up with memory demand. */ + add_wait_queue(&kswapd_wait, &wait); + set_current_state(TASK_INTERRUPTIBLE); + + if (free_high(ALL_ZONES) <= 0) { + wake_up(&kswapd_done); + schedule_timeout(HZ); remove_wait_queue(&kswapd_wait, &wait); + return; + } + remove_wait_queue(&kswapd_wait, &wait); - /* - * If we actually get into a low-memory situation, - * the processes needing more memory will wake us - * up on a more timely basis. - */ - kswapd_balance(); - run_task_queue(&tq_disk); + /* + * kswapd is going to sleep for a long time. Wake up the waiters to + * prevent them to get stuck while waiting for us. + */ + wake_up(&kswapd_done); + + /* OK, the VM is very loaded. Sleep instead of using all CPU. */ + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(HZ / 4); + return; +} + +/** + * try_to_free_pages - run the pageout code ourselves + * gfp_mask: mask of things the pageout code is allowed to do + * + * When the load on the system gets higher, it can happen + * that kswapd no longer manages to keep enough memory + * free. In those cases user programs allocating memory + * will call try_to_free_pages() and help the pageout code. + * This has the effects of freeing memory and slowing down + * the largest memory hogs a bit. + */ +int try_to_free_pages(unsigned int gfp_mask) +{ + int ret = 1; + + gfp_mask = pf_gfp_mask(gfp_mask); + if (gfp_mask & __GFP_WAIT) { + current->flags |= PF_MEMALLOC; + ret = do_try_to_free_pages(gfp_mask); + current->flags &= ~PF_MEMALLOC; } + + return ret; +} + +/** + * rss_free_pages - run part of the pageout code and slow down a bit + * @gfp_mask: mask of things the pageout code is allowed to do + * + * This function is called when a task is over its RSS limit and + * has a page fault. It's goal is to free some memory so non-hogs + * can run faster and slow down itself when needed so it won't eat + * the memory non-hogs can use. + */ +void rss_free_pages(unsigned int gfp_mask) +{ + long pause = 0; + + if (current->flags & PF_MEMALLOC) + return; + + current->flags |= PF_MEMALLOC; + + do { + page_launder(gfp_mask); + + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(pause); + set_current_state(TASK_RUNNING); + pause++; + } while (free_high(ALL_ZONES) >= 0); + + current->flags &= ~PF_MEMALLOC; + return; } static int __init kswapd_init(void) --------------96A7B87ECFD990228B1114CB-- From owner-linux-xfs@oss.sgi.com Sun Mar 10 04:24:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ACOvC27990 for linux-xfs-outgoing; Sun, 10 Mar 2002 04:24:57 -0800 Received: from smtp.de.easynet.net (smtp.de.easynet.net [194.24.208.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ACOk927075 for ; Sun, 10 Mar 2002 04:24:46 -0800 Received: from h528.ibc.de.easynet.net (h528.ibc.de.easynet.net [212.224.50.16]) by smtp.de.easynet.net (Postfix) with ESMTP id 2994E11CD29 for ; Sun, 10 Mar 2002 12:24:41 +0100 (CET) Date: Sun, 10 Mar 2002 12:24:43 +0100 From: Sebastian Ude To: linux-xfs@oss.sgi.com Subject: Re: Random filesystem corruption Reply-To: ude@handshake.de In-Reply-To: References: X-Mailer: Spruce 0.7.6 for X11 w/smtpio 0.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20020310112442.2994E11CD29@smtp.de.easynet.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 9 Mar 2002, sandeen@sgi.com (Eric Sandeen) wrote: > Date: Sat, 9 Mar 2002 22:22:17 -0600 (CST) > To: Sebastian Ude > From: sandeen@sgi.com (Eric Sandeen) > CC: > Subject: Re: Random filesystem corruption [...] > Can you do an "strace" on a simple program that tries to open one of > these files, and send the last bit (the failed open)? Nothing exiting: /* [...] */ open("/home/sebastian/WU RB Gebührenstaffels.txt", O_RDONLY) = -1 ENOENT (No such file or directory) /* [...] */ By the way - I noticed that all files that were damaged *yesterday* contained German Umlauts (the letters u, o, a with two dots above them: ü, ö, ä) in their names. However, I am sure that in the past files without Umlauts in the name got damaged as well. > Also - are you experiencing this problem on several different machines? No, it's all on the same machine. > I assume this is local, not NFS access? Correct, local. > When you have a file with this problem, though, I assume the behavior is > repeatable on that file? You mean that open () says they do not exist, although they are listed in their parent directory ? Yes, it's always the same. > Out of curiosity, do either the files or the directories have > "international" characters in the names? Errr ... yep, see above. But again, in the past also files or directories without "international" characters in the names got corrupted. > Decoding the oops through ksymoops would be helpful. If you could enable > kdb, that might help us get more information. This time there is no oops, unfortuantely. It could be that there was only a oops with some kernel versions, but I am not sure. > > xfs_repair, but the corrupted files were lost. > > What does xfs_repair tell you now? Does it find any problems? I have not run it yet because it could not recover my data the last time (if I remember correctly). > If you go back to an older kernel (perhaps the released 1.0.2 kernel) > does the problem go away? Well, that problem occours perhaps one time a month - and I have no idea how to reproduce it. So if I would try another kernel, I could perhaps tell you in April or May if there was no data corruption ... - Sebastian From owner-linux-xfs@oss.sgi.com Sun Mar 10 04:37:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ACbdU31199 for linux-xfs-outgoing; Sun, 10 Mar 2002 04:37:39 -0800 Received: from smtp.de.easynet.net (smtp.de.easynet.net [194.24.208.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ACbX931175 for ; Sun, 10 Mar 2002 04:37:33 -0800 Received: from h109.ibc.de.easynet.net (h109.ibc.de.easynet.net [212.224.4.109]) by smtp.de.easynet.net (Postfix) with ESMTP id 0066711CD29 for ; Sun, 10 Mar 2002 12:37:28 +0100 (CET) Date: Sun, 10 Mar 2002 12:37:29 +0100 From: Sebastian Ude To: linux-xfs@oss.sgi.com Subject: Re: Random filesystem corruption Reply-To: ude@handshake.de In-Reply-To: References: X-Mailer: Spruce 0.7.6 for X11 w/smtpio 0.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20020310113729.0066711CD29@smtp.de.easynet.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 10 Mar 2002, rabe@RWTH-Aachen.DE (Ralf G. R. Bergs) wrote: > Date: Sun, 10 Mar 2002 09:19:18 +0100 > To: "linux-xfs@oss.sgi.com" > From: rabe@RWTH-Aachen.DE (Ralf G. R. Bergs) > CC: "ude@handshake.de" > Reply-To: rabe@RWTH-Aachen.DE (Ralf G. R. Bergs) > Subject: Re: Random filesystem corruption [...] > >if I remember correctly, someone reported > >similar problems one month or so ago > > That person could have been me -- but it turned out that our hardware > RAID(!) was flawed. The manufacturer replaced and/or repaired it, and now > everything it's fine. Yes, but I do not raid (neither in hardware nor in software), and I doubt that all my disks are damaged anyway, since there is no problem at all with the other filesystems they are running besides XFS. > There have been CVS kernel versions as well that were simply broken WRT > "international" characters. This is what Eric was referring to. But I > guess that can't be an issue in your case since you mentioned you > observed the problem with different kernel versions. Yes. However, it could be that the damaged files were created with one of the broken kernels - but then I am wondering why they got corrupted *now*, and not before. Additionally, as I explained previously, not only files with Umlauts in the name were affected by the problem in the past. - Sebastian From owner-linux-xfs@oss.sgi.com Sun Mar 10 07:22:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2AFMmE01556 for linux-xfs-outgoing; Sun, 10 Mar 2002 07:22:48 -0800 Received: from cellus.no (www.smssiden.com [193.91.191.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2AFMZ901527 for ; Sun, 10 Mar 2002 07:22:36 -0800 Received: from christian ([193.69.127.56]) by cellus.no (8.9.3/8.9.3) with SMTP id PAA12917 for ; Sun, 10 Mar 2002 15:22:31 +0100 From: =?iso-8859-1?Q?Christian_R=F8snes?= To: Subject: KDB debug question - oops when entering kdb Date: Sun, 10 Mar 2002 15:22:29 +0100 Message-ID: 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello Background: The purpose of the debugging is to find out why I get a oops as described in previous mails with subject line: "Linux 2.4.18 freeze running dbench 1.3" (Machine is Compaq Proliant DL380 G2, SmartArray 5i, dual cpu 1266 MHz, 1280 MB RAM) Ok, I'm trying to debug the kernel. My kernel oopses when I run dbench with kernel version 2.4.18 (smp) on a xfs partition. From what little I understand so far, it seems that something seems to alter the xfs mount point (mp) object for the partition I try to run dbench on. (Version 2.4.9smp and dbench works fine on this xfs partion, also 2.4.18 and dbench on an EXT2 partition works fine). I thought that I would try to set a breakpoint for certain memory addresses that refer to items in the mp structure - eg the m_sb_lock - to see if I can catch anyone would shouldn't write to this location. I've compiled kdb into the kernel, and have setup console access from another machine via a serial cable. So, when I login via the serial-console, I thought I would drop into the kdb (CTRL-A CTRL-A from minicom), and set "bhpa
DATAW". The kernel 2.4.18 is booted with "nmi_watchdog=1". However, after I have logged in, and then do CTRL-A CTRL-A, the kernel oopses: Entering kdb (current=0xc2554000, pid 0) on processor 1 due to Keyboard Entry Oops: 0002 CPU: 1 EIP: 0010:[] Not tainted EFLAGS: 00010046 eax: 00000000 ebx: c2554000 ecx: 00000004 edx: c04b48e0 esi: 00000004 edi: 00000003 ebp: c2555e38 esp: c2555d10 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c2555000) Stack: c04b4978 c04b48e0 00000008 c2554000 00000001 00000159 c2555d70 c2555d70 c2554000 00000003 f737b4d0 c2555d54 00000086 00000002 f737b3c0 00000002 00000086 c2555d6c c01ea1c1 00000002 00000046 c2555db4 c0116007 f73de000 Call Trace: [] [] [] [] [] [] [] [] [] [] [ [] [] [] [] [] [ [] [] [] Code: 00 40 55 c2 04 00 00 00 03 00 00 00 08 5d 55 c2 0c 5d 55 c2 kdb: Debugger re-entered on cpu 1, new reason = 5 Not executing a kdb command Cannot recover, allowing event to proceed <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing At this point the machine hangs, and I have to power cycle (reset). Any pointers as to what might cause this when entering the kdb debugger, or have to get by it so I can set breakpoints, is highly welcome. Also, what's the best way to locate the address of the xfs mount point (mp) object for a particular partition, once I get into the kdb debugger ? Thanks Christian Btw - here are the debug options I have set for the kernel: CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_HIGHMEM=y CONFIG_DEBUG_SLAB=y CONFIG_DEBUG_IOVIRT=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_KDB=y CONFIG_KDB_MODULES=y # CONFIG_KDB_OFF is not set CONFIG_KALLSYMS=y CONFIG_FRAME_POINTER=y CONFIG_XFS_DEBUG=y From owner-linux-xfs@oss.sgi.com Sun Mar 10 09:38:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2AHcVr03757 for linux-xfs-outgoing; Sun, 10 Mar 2002 09:38:31 -0800 Received: from cellus.no (mail.cellus.no [193.91.191.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2AHcR903734 for ; Sun, 10 Mar 2002 09:38:27 -0800 Received: from christian ([193.69.127.56]) by cellus.no (8.9.3/8.9.3) with SMTP id RAA18890 for ; Sun, 10 Mar 2002 17:38:24 +0100 From: =?iso-8859-1?Q?Christian_R=F8snes?= To: Subject: RE: KDB debug question - oops when entering kdb Date: Sun, 10 Mar 2002 17:38:24 +0100 Message-ID: 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > However, after I have logged in, and then do CTRL-A CTRL-A, the kernel > oopses: > > Entering kdb (current=0xc2554000, pid 0) on processor 1 due to Keyboard > Entry > Oops: 0002 > ... > Code: 00 40 55 c2 04 00 00 00 03 00 00 00 08 5d 55 c2 0c 5d 55 c2 > kdb: Debugger re-entered on cpu 1, new reason = 5 > Not executing a kdb command > Cannot recover, allowing event to proceed > <0>Kernel panic: Aiee, killing interrupt handler! > In interrupt handler - not syncing I just did a full cvs checkout, menuconfig and build, and I'm now able to enter kdb with CTRL-A CTRL-A. It was probably something with my source tree or - maybe more likely - the config file. Christian From owner-linux-xfs@oss.sgi.com Sun Mar 10 10:36:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2AIaaO04782 for linux-xfs-outgoing; Sun, 10 Mar 2002 10:36:36 -0800 Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2AIaO904758 for ; Sun, 10 Mar 2002 10:36:24 -0800 Received: from user-2inia7c.dialup.mindspring.com ([165.121.40.236] helo=waltsathlon.localhost.net) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16k7F9-0000Co-00 for linux-xfs@oss.sgi.com; Sun, 10 Mar 2002 12:36:23 -0500 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id AE75381775B; Sun, 10 Mar 2002 09:35:36 -0800 (PST) Message-ID: <3C8B9968.2030301@mindspring.com> Date: Sun, 10 Mar 2002 09:35:36 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020306 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Christian_R=F8snes?= Cc: linux-xfs@oss.sgi.com Subject: Re: KDB debug question - oops when entering kdb References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I could be mistaken, but I thought there was a problem with enabling spinlock debugging on an xfs enabled kernel. Is this normally enabled in your .config ? -Walt Christian Rřsnes wrote: > Hello > > Background: The purpose of the debugging is to find out why I get a oops as > described in previous mails with subject line: > "Linux 2.4.18 freeze running dbench 1.3" > (Machine is Compaq Proliant DL380 G2, SmartArray 5i, dual cpu 1266 MHz, > 1280 MB RAM) > > Ok, I'm trying to debug the kernel. My kernel oopses when I run dbench > with kernel version 2.4.18 (smp) on a xfs partition. From what little I > understand so far, it seems that something seems to alter the xfs > mount point (mp) object for the partition I try to run dbench on. > (Version 2.4.9smp and dbench works fine on this xfs partion, > also 2.4.18 and dbench on an EXT2 partition works fine). > > I thought that I would try to set a breakpoint for certain > memory addresses that refer to items in the mp structure - eg > the m_sb_lock - to see if I can catch anyone would shouldn't > write to this location. > > I've compiled kdb into the kernel, and have setup console > access from another machine via a serial cable. > > So, when I login via the serial-console, I thought I would > drop into the kdb (CTRL-A CTRL-A from minicom), and > set "bhpa
DATAW". > > The kernel 2.4.18 is booted with "nmi_watchdog=1". > > However, after I have logged in, and then do CTRL-A CTRL-A, the kernel > oopses: > > Entering kdb (current=0xc2554000, pid 0) on processor 1 due to Keyboard > Entry > Oops: 0002 > CPU: 1 > EIP: 0010:[] Not tainted > EFLAGS: 00010046 > eax: 00000000 ebx: c2554000 ecx: 00000004 edx: c04b48e0 > esi: 00000004 edi: 00000003 ebp: c2555e38 esp: c2555d10 > ds: 0018 es: 0018 ss: 0018 > Process swapper (pid: 0, stackpage=c2555000) > Stack: c04b4978 c04b48e0 00000008 c2554000 00000001 00000159 c2555d70 > c2555d70 > c2554000 00000003 f737b4d0 c2555d54 00000086 00000002 f737b3c0 > 00000002 > 00000086 c2555d6c c01ea1c1 00000002 00000046 c2555db4 c0116007 > f73de000 > Call Trace: [] [] [] [] [] > [] [] [] [] [] > [ > [] [] [] [] [] > [ > [] [] [] > > Code: 00 40 55 c2 04 00 00 00 03 00 00 00 08 5d 55 c2 0c 5d 55 c2 > kdb: Debugger re-entered on cpu 1, new reason = 5 > Not executing a kdb command > Cannot recover, allowing event to proceed > <0>Kernel panic: Aiee, killing interrupt handler! > In interrupt handler - not syncing > > At this point the machine hangs, and I have to power cycle (reset). > > Any pointers as to what might cause this when > entering the kdb debugger, or have to get by it so I can > set breakpoints, is highly welcome. > > Also, what's the best way to locate the address of the > xfs mount point (mp) object for a particular partition, > once I get into the kdb debugger ? > > Thanks > Christian > > Btw - here are the debug options I have set for the kernel: > > CONFIG_DEBUG_KERNEL=y > CONFIG_DEBUG_HIGHMEM=y > CONFIG_DEBUG_SLAB=y > CONFIG_DEBUG_IOVIRT=y > CONFIG_MAGIC_SYSRQ=y > CONFIG_DEBUG_SPINLOCK=y > CONFIG_DEBUG_BUGVERBOSE=y > CONFIG_KDB=y > CONFIG_KDB_MODULES=y > # CONFIG_KDB_OFF is not set > CONFIG_KALLSYMS=y > CONFIG_FRAME_POINTER=y > CONFIG_XFS_DEBUG=y > > > From owner-linux-xfs@oss.sgi.com Sun Mar 10 11:27:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2AJRYx05679 for linux-xfs-outgoing; Sun, 10 Mar 2002 11:27:34 -0800 Received: from cellus.no (ns.cellus.no [193.91.191.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2AJRU905656 for ; Sun, 10 Mar 2002 11:27:30 -0800 Received: from christian ([193.69.127.56]) by cellus.no (8.9.3/8.9.3) with SMTP id TAA24140; Sun, 10 Mar 2002 19:27:25 +0100 From: =?iso-8859-1?Q?Christian_R=F8snes?= To: "Walt H" Cc: Subject: RE: KDB debug question - oops when entering kdb Date: Sun, 10 Mar 2002 19:27:26 +0100 Message-ID: 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: <3C8B9968.2030301@mindspring.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Walt H wrote: > > I could be mistaken, but I thought there was a problem with enabling > spinlock debugging on an xfs enabled kernel. Is this normally enabled in > your .config ? > > -Walt No - I normally have debugging turned off. But since my machine oopses when I run dbench and kernel 2.4.18, I've turned on all debug options. When examing the spinlock variable m_sb_lock in the xfs_mount structure (for the partition where dbench is run) after an oops, it holds the value 0x000000ff. Christian From owner-linux-xfs@oss.sgi.com Sun Mar 10 14:35:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2AMZ4q11413 for linux-xfs-outgoing; Sun, 10 Mar 2002 14:35:04 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2AMZ0911390 for ; Sun, 10 Mar 2002 14:35:01 -0800 Received: (qmail 16066 invoked from network); 10 Mar 2002 21:36:30 -0000 Received: from cpedeadbeef0000.cpe.net.cable.rogers.com (HELO sh0n.net) (sh0n@24.100.234.67) by cpedeadbeef0000.cpe.net.cable.rogers.com with SMTP; 10 Mar 2002 21:36:30 -0000 Date: Sun, 10 Mar 2002 16:36:29 -0500 (EST) From: Shawn Starr To: Knut J Bjuland cc: linux-xfs@oss.sgi.com Subject: Re: rmap vm and xfs In-Reply-To: <3C8B15B9.4ECAC60B@online.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Please try http://xfs.sh0n.net, I make some patches that merge rmap + XFS. current release is -shawn9. Shawn. On Sun, 10 Mar 2002, Knut J Bjuland wrote: > Are there any plans to make xfs compatible with Riel rmap vm.patch. > This'll make it easier to integrate it into Redhat 8.X when it ships, I > believe it'll be based on a linux 2.4.17 or later with rmap patch. > > > From owner-linux-xfs@oss.sgi.com Sun Mar 10 19:17:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2B3H1P16323 for linux-xfs-outgoing; Sun, 10 Mar 2002 19:17:01 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2B3Gv916301 for ; Sun, 10 Mar 2002 19:16:57 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2B2GpbX024969 for ; Sun, 10 Mar 2002 18:16:51 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA96098; Sun, 10 Mar 2002 20:16:51 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:sandeen@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA89368; Sun, 10 Mar 2002 20:16:40 -0600 (CST) Date: Sun, 10 Mar 2002 20:16:40 -0600 (CST) From: Eric Sandeen X-X-Sender: To: =?iso-8859-1?Q?Christian_R=F8snes?= cc: Walt H , Subject: RE: KDB debug question - oops when entering kdb In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by rj.sgi.com id g2B2GpbX024969 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2B3Gv916302 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It's true that spinlock debugging should not be turned on in the XFS kernel until we get the signed/unsigned character differences sorted out. Turning on spinlock debugging w/ xfs will lead to problems all by itself... -Eric On Sun, 10 Mar 2002, Christian Rřsnes wrote: > > Walt H wrote: > > > > I could be mistaken, but I thought there was a problem with enabling > > spinlock debugging on an xfs enabled kernel. Is this normally enabled in > > your .config ? > > > > -Walt > > No - I normally have debugging turned off. But since > my machine oopses when I run dbench and kernel 2.4.18, > I've turned on all debug options. When examing the > spinlock variable m_sb_lock in the xfs_mount structure > (for the partition where dbench is run) after an oops, > it holds the value 0x000000ff. > > Christian > From owner-linux-xfs@oss.sgi.com Mon Mar 11 00:57:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2B8vmI25059 for linux-xfs-outgoing; Mon, 11 Mar 2002 00:57:48 -0800 Received: from ursa.xanoptix.com (host-64-65-199-187.choiceone.net [64.65.199.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2B8vh925037 for ; Mon, 11 Mar 2002 00:57:43 -0800 Received: from kend-linux.xanoptix.com ([10.20.1.45])by ursa.xanoptix.comwith esmtp(Exim 3.20 #1 (Debian))id 16kKge-0007U5-00; Mon, 11 Mar 2002 02:57:40 -0500 Subject: Unable to mount XFS (3Ware). From: "Ken D'Ambrosio" To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Mar 2002 02:53:41 -0500 Message-Id: <1015833221.24549.11.camel@kend-linux> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Howdy, all. I created a 1 TB 3Ware RAID today, and everything works like a charm... until I try to mount it: [root@nebula mnt]# mount -t xfs /dev/sda1 /mnt/raid mount: wrong fs type, bad option, bad superblock on /dev/sda1, or too many mounted file systems In order to isolate the issue, I then did a mkfs.reiser on it, and it mounted just peachily as a ReiserFS volume. XFS is loaded (I've tried both as a module, and monolithically), and that's pretty much all I get. It makes the volume fine with "mkfs.xfs /dev/sda1". Other factoids: - The XFS is from CVS, downloaded earlier today - Ironically, it -had- worked, until I had to re-compile the kernel to add ext-3 support for the boot drive, and tweak one or two other things Should I start from scratch, or am I missing something dumb 'cause I'm up late? Thanks much for any help, -Ken From owner-linux-xfs@oss.sgi.com Mon Mar 11 01:26:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2B9QPg25679 for linux-xfs-outgoing; Mon, 11 Mar 2002 01:26:25 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2B9QI925656 for ; Mon, 11 Mar 2002 01:26:18 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx01)) with ESMTP id 5FCF66139; Mon, 11 Mar 2002 09:26:08 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA16436; Mon, 11 Mar 2002 09:26:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 98AF157306; Mon, 11 Mar 2002 09:25:57 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 9FB1325835; Mon, 11 Mar 2002 09:25:56 +0100 (CET) Message-ID: <3C8C6A14.49DA6213@ch.sauter-bc.com> Date: Mon, 11 Mar 2002 09:25:56 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Vincent Bernat Cc: Murthy Kambhampaty , linux-xfs@oss.sgi.com Subject: Re: Intermezzo and XFS References: Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Vincent Bernat schrieb: > > OoO La nuit ayant déjŕ recouvert d'encre ce jour du vendredi 08 mars > 2002, vers 23:44, Murthy Kambhampaty > disait: > > > This question probably deserves more analysis than any of us is capable of > > but if "one-way replication" fulfills my application's needs, and perhaps > > Vincent's > > In my case, I am searching a "two-way replication", since it is to > sync a laptop with my workstation. > -- > Use variable names that mean something. > - The Elements of Programming Style (Kernighan & Plaugher) Maybe unison is something for you. http://www.cis.upenn.edu/~bcpierce/unison/ Simon From owner-linux-xfs@oss.sgi.com Mon Mar 11 02:34:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BAYXv28545 for linux-xfs-outgoing; Mon, 11 Mar 2002 02:34:33 -0800 Received: from minnie.omroep.nl (minnie.omroep.nl [145.58.30.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BAYO928518 for ; Mon, 11 Mar 2002 02:34:25 -0800 Received: (from smap@localhost) by minnie.omroep.nl (SGI-8.9.3/8.9.3) id KAA45053 for ; Mon, 11 Mar 2002 10:34:17 +0100 (CET) Received: from nos-smtp.nos.nl (145.58.12.125 "HELO nos-smtp.nos.nl") by minnie.omroep.nl with SMTP (smap v3.0 nederlandse publieke omroep) id xma9728923; Mon, 11 Mar 02 10:34:14 +0100 Received: FROM exchange.nos.nl BY nos-smtp.nos.nl ; Mon Mar 11 10:52:30 2002 +0100 Received: by EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Mar 2002 10:34:55 +0100 Message-ID: <35F87783B600D411A1430060943F469A589797@EXCHANGE> From: Matthijs van der Klip To: "'Francis Yom'" , linux-xfs@oss.sgi.com Cc: Shawn Starr Subject: RE: cloning computers with xfs Date: Mon, 11 Mar 2002 10:34:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I found a utility that says it will do it. It is called Mondo: > > http://www.microwerks.net/~hugo/ > > It uses afio to do the backup. Has anyone used this utility or can > vouch for afio as being safe to backup xfs partitions. Hi, I always use Mondo to clone systems. Works like a charm. I still use an old version (1.19 I believe) however, because the newer versions tend to break things rather than fix them. On the other hand that may all be solved now and the newest version may work just fine. Best regards, Matthijs van der Klip Dutch Public Broadcasting Organisation [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Mar 11 05:16:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BDGRF02057 for linux-xfs-outgoing; Mon, 11 Mar 2002 05:16:27 -0800 Received: from yahoo.com ([61.75.8.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BDGK902033 for ; Mon, 11 Mar 2002 05:16:20 -0800 From: autorepeat2002@yahoo.com Message-Id: <200203111316.g2BDGK902033@oss.sgi.com> To: linux-xfs@oss.sgi.com Subject: congratulations! you won! Date: 11 Mar 2002 21:16:48 +0900 Expiry-Date: 31 Mar 2002 17:44:18 +0900 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- (This safeguard is not inserted when using the registered version) -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- (This safeguard is not inserted when using the registered version) -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Mar 11 05:59:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BDxXV02613 for linux-xfs-outgoing; Mon, 11 Mar 2002 05:59:33 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BDxT902590 for ; Mon, 11 Mar 2002 05:59:29 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2BCxNbX010158 for ; Mon, 11 Mar 2002 04:59:23 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA02398; Mon, 11 Mar 2002 06:59:23 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:sandeen@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA74723; Mon, 11 Mar 2002 06:59:23 -0600 (CST) Date: Mon, 11 Mar 2002 06:59:23 -0600 (CST) From: Eric Sandeen X-X-Sender: To: "Ken D'Ambrosio" cc: Subject: Re: Unable to mount XFS (3Ware). In-Reply-To: <1015833221.24549.11.camel@kend-linux> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 11 Mar 2002, Ken D'Ambrosio wrote: > Howdy, all. I created a 1 TB 3Ware RAID today, and everything works > like a charm... until I try to mount it: > > [root@nebula mnt]# mount -t xfs /dev/sda1 /mnt/raid > mount: wrong fs type, bad option, bad superblock on /dev/sda1, > or too many mounted file systems What does your syslog say? That will have the real error information. -Eric From owner-linux-xfs@oss.sgi.com Mon Mar 11 07:17:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BFHmc03990 for linux-xfs-outgoing; Mon, 11 Mar 2002 07:17:48 -0800 Received: from ursa.xanoptix.com (host-64-65-199-187.choiceone.net [64.65.199.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BFHc903967 for ; Mon, 11 Mar 2002 07:17:38 -0800 Received: from kend-linux.xanoptix.com ([10.20.1.45])by ursa.xanoptix.comwith esmtp(Exim 3.20 #1 (Debian))id 16kQc3-0001d0-00; Mon, 11 Mar 2002 09:17:19 -0500 Subject: Re: Unable to mount XFS (3Ware). From: "Ken D'Ambrosio" To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Mar 2002 09:13:21 -0500 Message-Id: <1015856001.26685.22.camel@kend-linux> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-11 at 07:59, Eric Sandeen wrote: > On 11 Mar 2002, Ken D'Ambrosio wrote: > > > Howdy, all. I created a 1 TB 3Ware RAID today, and everything works > > like a charm... until I try to mount it: [...] > What does your syslog say? That will have the real error information. Wow -- hadn't known that! Here's what it shows: Mar 11 09:03:05 nebula kernel: XFS: SB sanity check 2 failed Mar 11 09:03:05 nebula kernel: XFS: SB validate failed I found this link on Google: http://oss.sgi.com/projects/xfs/mail_archive/0107/msg00884.html So, as a pre-emptive strike, here's the output of "xfs_db -c sb -c p /dev/sda1": magicnum = 0x58465342 blocksize = 4096 dblocks = 240123904 rblocks = 0 rextents = 0 uuid = 236ac92d-d4ca-446a-83da-800f2edf0d0a logstart = 120586244 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 1048576 agcount = 230 rbmblocks = 0 logblocks = 29312 versionnum = 0x2084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 20 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 64 ifree = 61 fdblocks = 240093668 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 There's absolutely -no- data on this drive, so I'll gladly do whatever you ask me to. In desperation, prior to my most recent attempt to mkfs it, I did a "dd if=/dev/zero of=/sda bs=1024 count=1024", and it still failed in exactly the same manner, so I don't think it's anything in the partition table or the like... Thanks much, -Ken From owner-linux-xfs@oss.sgi.com Mon Mar 11 07:34:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BFYQQ04346 for linux-xfs-outgoing; Mon, 11 Mar 2002 07:34:26 -0800 Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BFYF904323 for ; Mon, 11 Mar 2002 07:34:15 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx01)) with ESMTP id 3CD6A6200; Mon, 11 Mar 2002 15:34:09 +0100 (MET) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id PAA19718; Mon, 11 Mar 2002 15:34:08 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 0111957306; Mon, 11 Mar 2002 15:34:02 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 6283225835; Mon, 11 Mar 2002 15:34:02 +0100 (CET) Message-ID: <3C8CC05A.74CDE259@ch.sauter-bc.com> Date: Mon, 11 Mar 2002 15:34:02 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.12 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: "Ken D'Ambrosio" Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Unable to mount XFS (3Ware). References: <1015856001.26685.22.camel@kend-linux> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ken D'Ambrosio schrieb: > > On Mon, 2002-03-11 at 07:59, Eric Sandeen wrote: > > On 11 Mar 2002, Ken D'Ambrosio wrote: > > > > > Howdy, all. I created a 1 TB 3Ware RAID today, and everything works > > > like a charm... until I try to mount it: > [...] > > What does your syslog say? That will have the real error information. > > Wow -- hadn't known that! Here's what it shows: > Mar 11 09:03:05 nebula kernel: XFS: SB sanity check 2 failed > Mar 11 09:03:05 nebula kernel: XFS: SB validate failed Can you try to create a filesystem with specified size. IIRC it is mkfs.xfs -d size=800m /dev/sda1 I think XFS determines wrong size. -Simon > > I found this link on Google: > http://oss.sgi.com/projects/xfs/mail_archive/0107/msg00884.html > > So, as a pre-emptive strike, here's the output of > "xfs_db -c sb -c p /dev/sda1": > > magicnum = 0x58465342 > blocksize = 4096 > dblocks = 240123904 > rblocks = 0 > rextents = 0 > uuid = 236ac92d-d4ca-446a-83da-800f2edf0d0a > logstart = 120586244 > rootino = 128 > rbmino = 129 > rsumino = 130 > rextsize = 16 > agblocks = 1048576 > agcount = 230 > rbmblocks = 0 > logblocks = 29312 > versionnum = 0x2084 > sectsize = 512 > inodesize = 256 > inopblock = 16 > fname = "\000\000\000\000\000\000\000\000\000\000\000\000" > blocklog = 12 > sectlog = 9 > inodelog = 8 > inopblog = 4 > agblklog = 20 > rextslog = 0 > inprogress = 0 > imax_pct = 25 > icount = 64 > ifree = 61 > fdblocks = 240093668 > frextents = 0 > uquotino = 0 > gquotino = 0 > qflags = 0 > flags = 0 > shared_vn = 0 > inoalignmt = 2 > unit = 0 > width = 0 > dirblklog = 0 > > There's absolutely -no- data on this drive, so I'll gladly do whatever > you ask me to. In desperation, prior to my most recent attempt to mkfs > it, I did a "dd if=/dev/zero of=/sda bs=1024 count=1024", and it still > failed in exactly the same manner, so I don't think it's anything in the > partition table or the like... > > Thanks much, > > -Ken From owner-linux-xfs@oss.sgi.com Mon Mar 11 07:53:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BFrdx04808 for linux-xfs-outgoing; Mon, 11 Mar 2002 07:53:39 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BFra904786 for ; Mon, 11 Mar 2002 07:53:36 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2BFrVBA014199 for ; Mon, 11 Mar 2002 07:53:32 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA05857; Mon, 11 Mar 2002 08:53:30 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:sandeen@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA49077; Mon, 11 Mar 2002 08:53:30 -0600 (CST) Date: Mon, 11 Mar 2002 08:53:30 -0600 (CST) From: Eric Sandeen X-X-Sender: To: "Ken D'Ambrosio" cc: Subject: Re: Unable to mount XFS (3Ware). In-Reply-To: <1015856001.26685.22.camel@kend-linux> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 11 Mar 2002, Ken D'Ambrosio wrote: > I found this link on Google: > http://oss.sgi.com/projects/xfs/mail_archive/0107/msg00884.html > Ok, and following Steve's suggestion in the followup to that article, what does mkfs.xfs (with no other options) say about how it creates your filesystem? (just send the mkfs output) Thanks, -Eric From owner-linux-xfs@oss.sgi.com Mon Mar 11 07:54:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BFsCF04878 for linux-xfs-outgoing; Mon, 11 Mar 2002 07:54:12 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BFs8904856 for ; Mon, 11 Mar 2002 07:54:08 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2BFs3BA014211 for ; Mon, 11 Mar 2002 07:54:03 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA05574; Mon, 11 Mar 2002 08:54:02 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA86502; Mon, 11 Mar 2002 08:54:02 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2BErFW22733; Mon, 11 Mar 2002 08:53:15 -0600 Subject: Re: Unable to mount XFS (3Ware). From: Steve Lord To: "Ken D'Ambrosio" Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1015856001.26685.22.camel@kend-linux> References: <1015856001.26685.22.camel@kend-linux> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Mar 2002 08:53:15 -0600 Message-Id: <1015858395.22689.6.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-11 at 08:13, Ken D'Ambrosio wrote: > On Mon, 2002-03-11 at 07:59, Eric Sandeen wrote: > > On 11 Mar 2002, Ken D'Ambrosio wrote: > > > > > Howdy, all. I created a 1 TB 3Ware RAID today, and everything works > > > like a charm... until I try to mount it: > [...] > > What does your syslog say? That will have the real error information. > > Wow -- hadn't known that! Here's what it shows: > Mar 11 09:03:05 nebula kernel: XFS: SB sanity check 2 failed > Mar 11 09:03:05 nebula kernel: XFS: SB validate failed > How recent are your XFS commands? It looks like you device size does not play well with this version of mkfs, there was a version which had problems like this, and it is possible the current one still does. Basically mkfs sliced the device up into chunks and hit a boundary condition on the size. Simon's suggestion would work, but you should be able to up the size to say 915m out of the 916 you have. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Mar 11 07:56:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BFu4v05084 for linux-xfs-outgoing; Mon, 11 Mar 2002 07:56:04 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BFu0905062 for ; Mon, 11 Mar 2002 07:56:01 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2BFtuBA014263 for ; Mon, 11 Mar 2002 07:55:56 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA04260; Mon, 11 Mar 2002 08:55:55 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA13660; Mon, 11 Mar 2002 08:55:54 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2BEt8022747; Mon, 11 Mar 2002 08:55:08 -0600 Subject: RE: KDB debug question - oops when entering kdb From: Steve Lord To: Eric Sandeen Cc: Christian =?ISO-8859-1?Q?R=F8snes?= , Walt H , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Mar 2002 08:55:08 -0600 Message-Id: <1015858508.22689.9.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 2002-03-10 at 20:16, Eric Sandeen wrote: > It's true that spinlock debugging should not be turned on in the XFS > kernel until we get the signed/unsigned character differences sorted out. > Turning on spinlock debugging w/ xfs will lead to problems all by > itself... I had been working with Christian, and we had switched xfs to using unsigned characters - which should avoid the oops issue. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Mar 11 08:16:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BGGUn05579 for linux-xfs-outgoing; Mon, 11 Mar 2002 08:16:30 -0800 Received: from ursa.xanoptix.com (host-64-65-199-187.choiceone.net [64.65.199.187]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BGGQ905556 for ; Mon, 11 Mar 2002 08:16:26 -0800 Received: from kend-linux.xanoptix.com ([10.20.1.45])by ursa.xanoptix.comwith esmtp(Exim 3.20 #1 (Debian))id 16kRXD-0002fX-00; Mon, 11 Mar 2002 10:16:23 -0500 Subject: Re: Unable to mount XFS (3Ware). From: "Ken D'Ambrosio" To: Steve Lord Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1015858395.22689.6.camel@jen.americas.sgi.com> References: <1015856001.26685.22.camel@kend-linux> <1015858395.22689.6.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Mar 2002 10:12:25 -0500 Message-Id: <1015859545.24512.47.camel@kend-linux> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-11 at 09:53, Steve Lord wrote: > How recent are your XFS commands? It looks like you device size does not > play well with this version of mkfs, there was a version which had > problems like this, and it is possible the current one still does. > > Basically mkfs sliced the device up into chunks and hit a boundary > condition on the size. Simon's suggestion would work, but you should > be able to up the size to say 915m out of the 916 you have. Thanks so much for the help! (Though you confused me using "m" instead of "g" -- pesky drive sizes are getting insane.) Anyway, 916g worked like a charm; I guess the little extra bit on the end (.01398945g by kcalc) was confusing things. My xfs commands, along with the kernel code etc., were compiled and installed from CVS source downloaded yesterday, so I guess you can't get much newer. ;-) Again, thanks for all the help! -Ken From owner-linux-xfs@oss.sgi.com Mon Mar 11 08:18:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BGI4g05684 for linux-xfs-outgoing; Mon, 11 Mar 2002 08:18:04 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BGHx905662 for ; Mon, 11 Mar 2002 08:18:00 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2BGPXkw021621 for ; Mon, 11 Mar 2002 10:25:33 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA05377; Mon, 11 Mar 2002 09:17:54 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA78647; Mon, 11 Mar 2002 09:17:53 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2BFH7F23481; Mon, 11 Mar 2002 09:17:07 -0600 Subject: Re: Unable to mount XFS (3Ware). From: Steve Lord To: "Ken D'Ambrosio" Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1015859545.24512.47.camel@kend-linux> References: <1015856001.26685.22.camel@kend-linux> <1015858395.22689.6.camel@jen.americas.sgi.com> <1015859545.24512.47.camel@kend-linux> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Mar 2002 09:17:07 -0600 Message-Id: <1015859827.22693.13.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-11 at 09:12, Ken D'Ambrosio wrote: > On Mon, 2002-03-11 at 09:53, Steve Lord wrote: > > > How recent are your XFS commands? It looks like you device size does not > > play well with this version of mkfs, there was a version which had > > problems like this, and it is possible the current one still does. > > > > Basically mkfs sliced the device up into chunks and hit a boundary > > condition on the size. Simon's suggestion would work, but you should > > be able to up the size to say 915m out of the 916 you have. > > Thanks so much for the help! (Though you confused me using "m" instead > of "g" -- pesky drive sizes are getting insane.) Anyway, 916g worked > like a charm; I guess the little extra bit on the end (.01398945g by > kcalc) was confusing things. My xfs commands, along with the kernel > code etc., were compiled and installed from CVS source downloaded > yesterday, so I guess you can't get much newer. ;-) Woops, not enought coffee yet, OK, looks like mkfs is still size sensitive. I will pass the information along. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Mar 11 08:26:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BGQve05945 for linux-xfs-outgoing; Mon, 11 Mar 2002 08:26:57 -0800 Received: from no-maam.dyndns.org (pD903C92C.dip.t-dialin.net [217.3.201.44]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BGQo905923 for ; Mon, 11 Mar 2002 08:26:51 -0800 Received: by no-maam.dyndns.org (Postfix, from userid 1000) id B28B031F96; Mon, 11 Mar 2002 16:26:27 +0100 (CET) Date: Mon, 11 Mar 2002 16:26:27 +0100 To: Shawn Starr Cc: linux-xfs@oss.sgi.com Subject: Re: rmap vm and xfs Message-ID: <20020311152626.GA960@no-maam.dyndns.org> References: <3C8B15B9.4ECAC60B@online.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i From: erik.tews@gmx.net (Erik Tews) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Mar 10, 2002 at 04:36:29PM -0500, Shawn Starr wrote: > > Please try http://xfs.sh0n.net, I make some patches that merge rmap + XFS. > > current release is -shawn9. > On Sun, 10 Mar 2002, Knut J Bjuland wrote: > > > Are there any plans to make xfs compatible with Riel rmap vm.patch. > > This'll make it easier to integrate it into Redhat 8.X when it ships, I > > believe it'll be based on a linux 2.4.17 or later with rmap patch. I am wondering about the size of your patches. The size of the different releases is very different. Is this normal? From owner-linux-xfs@oss.sgi.com Mon Mar 11 11:34:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BJYnU09314 for linux-xfs-outgoing; Mon, 11 Mar 2002 11:34:49 -0800 Received: from smtp2.vol.cz (smtp2.vol.cz [195.250.128.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BJYh909292 for ; Mon, 11 Mar 2002 11:34:44 -0800 Received: from Elf.ucw.cz (prahaf-4.dialup.vol.cz [212.20.103.4]) by smtp2.vol.cz (8.11.6/8.11.3) with ESMTP id g2BIYbi42157; Mon, 11 Mar 2002 19:34:38 +0100 (CET) (envelope-from pavel@Elf.ucw.cz) Received: (from pavel@localhost) by Elf.ucw.cz (8.8.8/8.8.5) id XAA02362; Sun, 10 Mar 2002 23:19:26 +0100 Date: Sun, 10 Mar 2002 23:19:26 +0100 From: Pavel Machek To: Stephen Lord Cc: svetljo , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.18-rc4-aa1 XFS oopses caused by cpio Message-ID: <20020310231926.A2354@elf.ucw.cz> References: <1015580766.20800.3.camel@svetljo.st-peter.stw.uni-erlangen.de> <3C88B612.1070206@sgi.com> <3C88C9A1.5070502@st-peter.stw.uni-erlangen.de> <3C88CB1C.90203@sgi.com> <3C88DFC9.8060907@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C88DFC9.8060907@sgi.com> User-Agent: Mutt/1.3.23i X-Warning: Reading this can be dangerous to your mental health. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! > >Ah, so you ran growfs on the filesystem, thats the key here. It looks > >like the new code > >does not handle growfs correctly, the structure which is null is not > >allocated in the > >expansion case. I should have a fix shortly. > > > >Steve > > Hi, > > Can you try and repeat with this patch, it should apply reasonably > cleanly to the aa tree. Please please, diff -u ... Pavel > > =========================================================================== > Index: linux/fs/xfs/xfs_alloc.c > =========================================================================== > > 2234a2235,2236 > > pag->pagb_list = kmem_zalloc(XFS_PAGB_NUM_SLOTS * > > sizeof(xfs_perag_busy_t), KM_SLEEP); > -- I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org From owner-linux-xfs@oss.sgi.com Mon Mar 11 12:16:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BKGll10445 for linux-xfs-outgoing; Mon, 11 Mar 2002 12:16:47 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BKGf910422 for ; Mon, 11 Mar 2002 12:16:41 -0800 Received: (qmail 9419 invoked from network); 11 Mar 2002 19:16:39 -0000 Received: from cpedeadbeef0000.cpe.net.cable.rogers.com (HELO sh0n.net) (sh0n@24.100.234.67) by cpedeadbeef0000.cpe.net.cable.rogers.com with SMTP; 11 Mar 2002 19:16:39 -0000 Date: Mon, 11 Mar 2002 14:16:38 -0500 (EST) From: Shawn Starr To: linux-xfs@oss.sgi.com Subject: Re: congratulations! you won! In-Reply-To: <200203111316.g2BDGK902033@oss.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I did? ;-) Did I win a new SGI fully souped system? :) Shawn. On 11 Mar 2002 autorepeat2002@yahoo.com wrote: > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > (This safeguard is not inserted when using the registered version) > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > (This safeguard is not inserted when using the registered version) > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > -------------------------------------------------------------------- > > > > [[HTML alternate version deleted]] > > > From owner-linux-xfs@oss.sgi.com Mon Mar 11 12:18:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BKIjT10586 for linux-xfs-outgoing; Mon, 11 Mar 2002 12:18:45 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BKIf910561 for ; Mon, 11 Mar 2002 12:18:41 -0800 Received: (qmail 9582 invoked from network); 11 Mar 2002 19:18:40 -0000 Received: from cpedeadbeef0000.cpe.net.cable.rogers.com (HELO sh0n.net) (sh0n@24.100.234.67) by cpedeadbeef0000.cpe.net.cable.rogers.com with SMTP; 11 Mar 2002 19:18:40 -0000 Date: Mon, 11 Mar 2002 14:18:39 -0500 (EST) From: Shawn Starr To: Erik Tews cc: linux-xfs@oss.sgi.com Subject: Re: rmap vm and xfs In-Reply-To: <20020311152626.GA960@no-maam.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes, the Alan Cox patches are huge :-) On Mon, 11 Mar 2002, Erik Tews wrote: > On Sun, Mar 10, 2002 at 04:36:29PM -0500, Shawn Starr wrote: > > > > Please try http://xfs.sh0n.net, I make some patches that merge rmap + XFS. > > > > current release is -shawn9. > > On Sun, 10 Mar 2002, Knut J Bjuland wrote: > > > > > Are there any plans to make xfs compatible with Riel rmap vm.patch. > > > This'll make it easier to integrate it into Redhat 8.X when it ships, I > > > believe it'll be based on a linux 2.4.17 or later with rmap patch. > > I am wondering about the size of your patches. The size of the different > releases is very different. Is this normal? > > From owner-linux-xfs@oss.sgi.com Mon Mar 11 12:19:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BKJCq10726 for linux-xfs-outgoing; Mon, 11 Mar 2002 12:19:12 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BKJ8910703 for ; Mon, 11 Mar 2002 12:19:08 -0800 Received: (qmail 9612 invoked from network); 11 Mar 2002 19:19:07 -0000 Received: from cpedeadbeef0000.cpe.net.cable.rogers.com (HELO sh0n.net) (sh0n@24.100.234.67) by cpedeadbeef0000.cpe.net.cable.rogers.com with SMTP; 11 Mar 2002 19:19:07 -0000 Date: Mon, 11 Mar 2002 14:19:07 -0500 (EST) From: Shawn Starr To: Erik Tews cc: linux-xfs@oss.sgi.com Subject: Re: rmap vm and xfs In-Reply-To: <20020311152626.GA960@no-maam.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Compare -shawn9 vs shawn10 ac2 to ac4 grows by 100KB. Shawn. On Mon, 11 Mar 2002, Erik Tews wrote: > On Sun, Mar 10, 2002 at 04:36:29PM -0500, Shawn Starr wrote: > > > > Please try http://xfs.sh0n.net, I make some patches that merge rmap + XFS. > > > > current release is -shawn9. > > On Sun, 10 Mar 2002, Knut J Bjuland wrote: > > > > > Are there any plans to make xfs compatible with Riel rmap vm.patch. > > > This'll make it easier to integrate it into Redhat 8.X when it ships, I > > > believe it'll be based on a linux 2.4.17 or later with rmap patch. > > I am wondering about the size of your patches. The size of the different > releases is very different. Is this normal? > > > From owner-linux-xfs@oss.sgi.com Mon Mar 11 12:49:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BKnRg11270 for linux-xfs-outgoing; Mon, 11 Mar 2002 12:49:27 -0800 Received: from mathserv.math.ohio-state.edu (IDENT:root@mathserv.math.ohio-state.edu [128.146.111.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BKnN911247 for ; Mon, 11 Mar 2002 12:49:23 -0800 Received: from math.ohio-state.edu (zaphod.math.ohio-state.edu [128.146.111.36]) by mathserv.math.ohio-state.edu (8.12.2/8.12.2) with ESMTP id g2BJnEXa025932 for ; Mon, 11 Mar 2002 14:49:22 -0500 Received: by math.ohio-state.edu (Postfix, from userid 500) id 92DFE2D82DD; Mon, 11 Mar 2002 14:49:14 -0500 (EST) Date: Mon, 11 Mar 2002 14:49:14 -0500 From: Dave Alden To: linux-xfs@oss.sgi.com Subject: odd problem with XFS & NFS (locking up system) Message-ID: <20020311144914.A6662@math.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-RAVMilter-Version: 8.3.2(snapshot 20020213) (mathserv) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm having an odd problem with the latest CVS (as of 03/11/02 11:00am EST). I've compiled and installed the kernel, but whenever I attempt to copy a file over NFS, the server locks up. Any windows I have open on the server stop responding. I tried to a -A, followed by a bt and I got: Entering kdb (current=0xc045c000, pid 0) due to Keyboard Entry kdb> bt EBP EIP Function(args) 0xc01053b0 0xc01053d3 default_idle+0x23 kernel .text 0xc0100000 0xc01053b0 0xc01053e0 0xc0105452 cpu_idle+0x52 kernel .text 0xc0100000 0xc0105400 0xc0105470 kdb> Help? ...thnx, ...dave alden ps This problem doesn't seem to occur if I copy a file from an EXT3 partition over NFS, only XFS. It also doesn't happen if I reboot to the original XFS kernel (2.4.9-13SGI_XFS_1.0.2). From owner-linux-xfs@oss.sgi.com Mon Mar 11 12:56:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BKuvx11551 for linux-xfs-outgoing; Mon, 11 Mar 2002 12:56:57 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BKuq911529 for ; Mon, 11 Mar 2002 12:56:52 -0800 Received: (qmail 26188 invoked from network); 11 Mar 2002 19:56:49 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 11 Mar 2002 19:56:49 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 7001F3000BA; Tue, 12 Mar 2002 05:56:47 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 4100BBA; Tue, 12 Mar 2002 06:56:47 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Dave Alden Cc: linux-xfs@oss.sgi.com Subject: Re: odd problem with XFS & NFS (locking up system) In-reply-to: Your message of "Mon, 11 Mar 2002 14:49:14 CDT." <20020311144914.A6662@math.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Mar 2002 06:56:42 +1100 Message-ID: <523.1015876602@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 11 Mar 2002 14:49:14 -0500, Dave Alden wrote: >Hi, > I'm having an odd problem with the latest CVS (as of 03/11/02 11:00am EST). >I've compiled and installed the kernel, but whenever I attempt to copy a >file over NFS, the server locks up. Any windows I have open on the server >stop responding. I tried to a -A, followed by a bt and I got: > >Entering kdb (current=0xc045c000, pid 0) due to Keyboard Entry >kdb> bt > EBP EIP Function(args) >0xc01053b0 0xc01053d3 default_idle+0x23 > kernel .text 0xc0100000 0xc01053b0 0xc01053e0 > 0xc0105452 cpu_idle+0x52 > kernel .text 0xc0100000 0xc0105400 0xc0105470 Under kdb, do set LINES 2000 ps bta The fact that you can do control-A and get to kdb means that it is not a complete kernel lockup, rather some code is sitting in interruptible wait. ps and bta will show which tasks are waiting and why. From owner-linux-xfs@oss.sgi.com Mon Mar 11 13:09:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BL9tc12149 for linux-xfs-outgoing; Mon, 11 Mar 2002 13:09:55 -0800 Received: from clubphoto.com (mail-gw.clubphoto.com [64.124.34.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BL9r912124 for ; Mon, 11 Mar 2002 13:09:53 -0800 Received: from [192.168.168.25] (gabe-g4.clubphoto.local [192.168.168.25]) by clubphoto.com (8.9.3/8.9.3) with ESMTP id MAA12123 for ; Mon, 11 Mar 2002 12:09:53 -0800 User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Mon, 11 Mar 2002 12:09:52 -0800 Subject: Adaptec 2005s From: "Gabe E. Nydick" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Can anyone confirm the adaptec 2005s working, and working WELL for them under a 2.4 kernel? Thanks, Gabe From owner-linux-xfs@oss.sgi.com Mon Mar 11 13:26:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BLQoF13012 for linux-xfs-outgoing; Mon, 11 Mar 2002 13:26:50 -0800 Received: from mathserv.math.ohio-state.edu (IDENT:root@mathserv.math.ohio-state.edu [128.146.111.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BLOv912484 for ; Mon, 11 Mar 2002 13:24:57 -0800 Received: from math.ohio-state.edu (zaphod.math.ohio-state.edu [128.146.111.36]) by mathserv.math.ohio-state.edu (8.12.2/8.12.2) with ESMTP id g2BKOuXa029470; Mon, 11 Mar 2002 15:24:56 -0500 Received: by math.ohio-state.edu (Postfix, from userid 500) id EABC02D82DD; Mon, 11 Mar 2002 15:24:55 -0500 (EST) Date: Mon, 11 Mar 2002 15:24:55 -0500 From: Dave Alden To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: odd problem with XFS & NFS (locking up system) Message-ID: <20020311152455.A6907@math.ohio-state.edu> References: <20020311144914.A6662@math.ohio-state.edu> <523.1015876602@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <523.1015876602@ocs3.intra.ocs.com.au>; from kaos@sgi.com on Tue, Mar 12, 2002 at 06:56:42AM +1100 X-RAVMilter-Version: 8.3.2(snapshot 20020213) (mathserv) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Tue, Mar 12, 2002 at 06:56:42AM +1100, Keith Owens wrote: > Under kdb, do > set LINES 2000 > ps > bta > The fact that you can do control-A and get to kdb means that it is not > a complete kernel lockup, rather some code is sitting in interruptible > wait. ps and bta will show which tasks are waiting and why. Ok -- here it is. :-) ...dave --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=typescript Content-Transfer-Encoding: quoted-printable Script started on Mon Mar 11 15:22:39 2002 =1B]0;root@mathcons: /root=07[root@mathcons /root]# kermit -l /dev/ttyN000 = -b 38400 -c=0D Connecting to /dev/ttyN000, speed 38400.=0D=0D The escape character is Ctrl-\ (ASCII 28, FS)=0D=0D Type the escape character followed by C to get back,=0D=0D or followed by ? to see other options.=0D=0D ----------------------------------------------------=0D =0Dkdb> set LINES 2000 =0Dkdb> ps =0DTask Addr Pid Parent [*] cpu State Thread Command =0D0xc2814000 00000001 00000000 1 000 stop 0xc2814270 init =0D0xc2838000 00000002 00000001 1 000 stop 0xc2838270 keventd =0D0xc2834000 00000003 00000000 1 000 stop 0xc2834270 ksoftirqd_CPU0 =0D0xc2832000 00000004 00000000 1 000 stop 0xc2832270 kswapd =0D0xf7bee000 00000005 00000000 1 000 stop 0xf7bee270 bdflush =0D0xf7bec000 00000006 00000000 1 000 stop 0xf7bec270 kupdated =0D0xf7be4000 00000007 00000001 1 000 stop 0xf7be4270 pagebuf_daemon =0D0xf7bcc000 00000008 00000001 1 000 stop 0xf7bcc270 i2oevtd =0D0xf7bc4000 00000009 00000001 1 000 stop 0xf7bc4270 i2oblock =0D0xf7a5a000 00000013 00000001 1 000 stop 0xf7a5a270 scsi_eh_0 =0D0xf7a58000 00000014 00000001 1 000 stop 0xf7a58270 scsi_eh_1 =0D0xf6536000 00000015 00000001 1 000 stop 0xf6536270 kjournald =0D0xf643e000 00000106 00000001 1 000 stop 0xf643e270 kjournald =0D0xf6238000 00000458 00000001 1 000 stop 0xf6238270 dhcpcd =0D0xf622a000 00000522 00000001 1 000 stop 0xf622a270 syslogd =0D0xf6222000 00000527 00000001 1 000 stop 0xf6222270 klogd =0D0xf6158000 00000547 00000001 1 000 stop 0xf6158270 portmap =0D0xf61e0000 00000575 00000001 1 000 stop 0xf61e0270 rpc.statd =0D0xf622c000 00000752 00000001 1 000 stop 0xf622c270 automount =0D0xf616c000 00000754 00000001 1 000 stop 0xf616c270 automount =0D0xf61b8000 00000782 00000001 1 000 stop 0xf61b8270 sshd =0D0xf624a000 00000816 00000001 1 000 stop 0xf624a270 xinetd =0D0xf60f8000 00000844 00000001 1 000 stop 0xf60f8270 rpc.rquotad =0D0xf60ee000 00000849 00000001 1 000 stop 0xf60ee270 rpc.mountd =0D0xf60e2000 00000854 00000001 1 000 stop 0xf60e2270 nfsd =0D0xf60de000 00000855 00000001 1 000 stop 0xf60de270 lockd =0D0xf60dc000 00000856 00000855 1 000 stop 0xf60dc270 rpciod =0D0xf60d6000 00000857 00000001 1 000 stop 0xf60d6270 nfsd =0D0xf60d4000 00000858 00000001 1 000 stop 0xf60d4270 nfsd =0D0xf60cc000 00000859 00000001 1 000 stop 0xf60cc270 nfsd =0D0xf60c2000 00000860 00000001 1 000 stop 0xf60c2270 nfsd =0D0xf60c0000 00000861 00000001 1 000 stop 0xf60c0270 nfsd =0D0xf60b8000 00000862 00000001 1 000 stop 0xf60b8270 nfsd =0D0xf60ae000 00000863 00000001 1 000 stop 0xf60ae270 nfsd =0D0xf609c000 00000948 00000001 1 000 stop 0xf609c270 master =0D0xf5f34000 00000952 00000948 1 000 stop 0xf5f34270 pickup =0D0xf5f2e000 00000953 00000948 1 000 stop 0xf5f2e270 qmgr =0D0xf5f28000 00000954 00000948 1 000 stop 0xf5f28270 tlsmgr =0D0xf5eba000 00000969 00000001 1 000 stop 0xf5eba270 gpm =0D0xf5eb0000 00000987 00000001 1 000 stop 0xf5eb0270 crond =0D0xf5da8000 00001043 00000001 1 000 stop 0xf5da8270 xfs =0D0xf5d90000 00001079 00000001 1 000 stop 0xf5d90270 atd =0D0xf5d84000 00001094 00000001 1 000 stop 0xf5d84270 cupsd =0D0xf64fa000 00001100 00000001 1 000 stop 0xf64fa270 login =0D0xf5d38000 00001129 00001100 1 000 stop 0xf5d38270 bash =0D0xee3da000 00001250 00000001 1 000 stop 0xee3da270 ntpd =0D0xf40b8000 00001369 00001129 1 000 stop 0xf40b8270 bash =0Dkdb> bta =0DStack traceback for pid 1 =0D EBP EIP Function(args) =0D0xc2815efc 0xc01145c2 schedule+0x322 (0xc2815f08, 0xc04a802c, 0xc04cf300= , 0x32da5, 0xc2814000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xc2815f30 0xc011426d schedule_timeout+0x7d (0xc2815f54, 0x400, 0xc28140= 00, 0x1f4, 0xb) =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc014200b do_select+0x1fb (0xb, 0xc2815f90, 0xc2815f8c, 0xf6= 4ed3c0, 0x0) =0D kernel .text 0xc0100000 0xc0141e10 0xc014= 2040 =0D 0xc014239c sys_select+0x32c (0xb, 0xbffff900, 0x0, 0x0, 0xbff= ff838) =0D kernel .text 0xc0100000 0xc0142070 0xc014= 24f0 =0D 0xc0106f4b system_call+0x33 =0D kernel .text 0xc0100000 0xc0106f18 0xc010= 6f50 =0DEnter to end, to continue: =0DStack traceback for pid 2 =0D EBP EIP Function(args) =0D0xc2839f88 0xc01145c2 schedule+0x322 (0xa, 0xc2838560, 0xc2838570, 0xc28= 39fd0, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc012261d context_thread+0xfd =0D kernel .text 0xc0100000 0xc0122520 0xc012= 26d0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 3 =0D EBP EIP Function(args) =0D0xc2835fe0 0xc01145c2 schedule+0x322 =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc011af0f ksoftirqd+0x6f =0D kernel .text 0xc0100000 0xc011aea0 0xc011= af60 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 4 =0D EBP EIP Function(args) =0D0xc2833fbc 0xc01145c2 schedule+0x322 (0x10f00, 0xc012d880, 0x0, 0xc2815f= b8, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc012d908 kswapd+0x88 =0D kernel .text 0xc0100000 0xc012d880 0xc012= d940 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 5 =0D EBP EIP Function(args) =0D0xf7beffbc 0xc01145c2 schedule+0x322 (0x0, 0xf7bee000, 0xc043f8ac, 0xc04= 3f8ac, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf7beffdc 0xc01148ec interruptible_sleep_on+0x3c =0D kernel .text 0xc0100000 0xc01148b0 0xc011= 4910 =0D 0xc013892c bdflush+0x9c =0D kernel .text 0xc0100000 0xc0138890 0xc013= 8930 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 6 =0D EBP EIP Function(args) =0D0xf7bedf9c 0xc01145c2 schedule+0x322 (0xf7bedfa8, 0xc04a8024, 0xf622c0e4= , 0x32c34, 0xf7bec000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf7bedfd0 0xc011426d schedule_timeout+0x7d (0x8e000, 0xf7bec000) =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc01389c3 kupdate+0x93 =0D kernel .text 0xc0100000 0xc0138930 0xc013= 8a30 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 7 =0D EBP EIP Function(args) =0D0xf7be5f78 0xc01145c2 schedule+0x322 (0x0, 0xf7be4000, 0xc04458ec, 0xc04= 458ec, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf7be5f98 0xc01148ec interruptible_sleep_on+0x3c (0xf7be5fc0, 0xf7be5fc= 0, 0xf7be5fc0, 0x0, 0xc2814000) =0D kernel .text 0xc0100000 0xc01148b0 0xc011= 4910 =0D 0xc0225c7f pagebuf_daemon+0xdf =0D kernel .text 0xc0100000 0xc0225ba0 0xc022= 5de0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 8 =0D EBP EIP Function(args) =0D0xf7bcdf6c 0xc01145c2 schedule+0x322 (0x1, 0xf7bcc000, 0xc0455a68, 0xc04= 55a68) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0105d4d __down_interruptible+0x5d =0D kernel .text 0xc0100000 0xc0105cf0 0xc010= 5db0 =0D0xf7bcdfec 0xc0105dfb __down_failed_interruptible+0x7 (0xf7bcc000, 0xc04= e2444, 0xc04e2440, 0xf7bcc000, 0xc2834000) =0D kernel .text 0xc0100000 0xc0105df4 0xc010= 5e00 =0D 0xc02cb7e1 _text_lock_i2o_core+0xff =0D kernel .text 0xc0100000 0xc02cb6e2 0xc02c= b7f0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 9 =0D EBP EIP Function(args) =0D0xf7bc5f90 0xc01145c2 schedule+0x322 (0x1, 0xf7bc4000, 0xc0455cf0, 0xc04= 55cf0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0105d4d __down_interruptible+0x5d =0D kernel .text 0xc0100000 0xc0105cf0 0xc010= 5db0 =0D 0xc0105dfb __down_failed_interruptible+0x7 (0xc02cd350, 0x0, = 0xc2815fa0, 0xc04e7900, 0xc0455d1c) =0D kernel .text 0xc0100000 0xc0105df4 0xc010= 5e00 =0D 0xc02cebb0 _text_lock_i2o_block+0xf =0D kernel .text 0xc0100000 0xc02ceba1 0xc02c= ebc0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 13 =0D EBP EIP Function(args) =0D0xf7a5bf70 0xc01145c2 schedule+0x322 (0x1, 0xf7a5a000, 0xf7a5bfd4, 0xf7a= 5bfd4) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0105d4d __down_interruptible+0x5d =0D kernel .text 0xc0100000 0xc0105cf0 0xc010= 5db0 =0D 0xc0105dfb __down_failed_interruptible+0x7 (0x0, 0x0, 0x0, 0x= f7a5bfd4, 0xf7a5bfd4) =0D kernel .text 0xc0100000 0xc0105df4 0xc010= 5e00 =0D 0xc02986f9 _text_lock_scsi_error+0x55 =0D kernel .text 0xc0100000 0xc02986a4 0xc029= 8710 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 14 =0D EBP EIP Function(args) =0D0xf7a59f70 0xc01145c2 schedule+0x322 (0x1, 0xf7a58000, 0xf7a59fd4, 0xf7a= 59fd4) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0105d4d __down_interruptible+0x5d =0D kernel .text 0xc0100000 0xc0105cf0 0xc010= 5db0 =0D 0xc0105dfb __down_failed_interruptible+0x7 (0x0, 0x0, 0x0, 0x= f7a59fd4, 0xf7a59fd4) =0D kernel .text 0xc0100000 0xc0105df4 0xc010= 5e00 =0D 0xc02986f9 _text_lock_scsi_error+0x55 =0D kernel .text 0xc0100000 0xc02986a4 0xc029= 8710 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 15 =0D EBP EIP Function(args) =0D0xf6537fa0 0xc01145c2 schedule+0x322 (0x0, 0xf6536000, 0xf7a2546c, 0xf7a= 2546c, 0xf6537fc8) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf6537fc0 0xc01148ec interruptible_sleep_on+0x3c (0x0, 0x0, 0x32aa0, 0x= f6536000, 0xc0166020) =0D kernel .text 0xc0100000 0xc01148b0 0xc011= 4910 =0D 0xc016616a kjournald+0x12a =0D kernel .text 0xc0100000 0xc0166040 0xc016= 61e0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 106 =0D EBP EIP Function(args) =0D0xf643ffa0 0xc01145c2 schedule+0x322 (0x0, 0xf643e000, 0xf7a2566c, 0xf7a= 2566c, 0xf643ffc8) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf643ffc0 0xc01148ec interruptible_sleep_on+0x3c (0x0, 0x0, 0x1476, 0xf= 643e000, 0xc0166020) =0D kernel .text 0xc0100000 0xc01148b0 0xc011= 4910 =0D 0xc016616a kjournald+0x12a =0D kernel .text 0xc0100000 0xc0166040 0xc016= 61e0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 458 =0D EBP EIP Function(args) =0D0xf6239f6c 0xc01145c2 schedule+0x322 (0xf6239f78, 0xc04a7b64, 0xf62380e4= , 0x1cd7f65, 0xf6238000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf6239fa0 0xc011426d schedule_timeout+0x7d (0x49d40, 0x0) =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D0xf6239fa8 0xc011e7c2 sys_nanosleep+0x122 (0xbffffac8, 0xbffffac8, 0xbff= ffac8, 0x10000, 0x0) =0D kernel .text 0xc0100000 0xc011e6a0 0xc011= e840 =0D 0xc0106f4b system_call+0x33 =0D kernel .text 0xc0100000 0xc0106f18 0xc010= 6f50 =0DEnter to end, to continue: =0DStack traceback for pid 522 =0D EBP EIP Function(args) =0D0xf622bf00 0xc01145c2 schedule+0x322 (0xffffffff, 0x0, 0xf5e09500, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf622bf30 0xc0114207 schedule_timeout+0x17 =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc02d67bf sock_poll+0x1f =0D kernel .text 0xc0100000 0xc02d67a0 0xc02d= 67d0 =0DEnter to end, to continue: =0DStack traceback for pid 527 =0D EBP EIP Function(args) =0D0xf6223f4c 0xc01145c2 schedule+0x322 (0x0, 0xf6223f48, 0x0, 0xf6222000, = 0xc043dc48) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0116ad1 do_syslog+0xd1 (0x2, 0x804df80, 0xfff, 0xf6377de0,= 0x46) =0D kernel .text 0xc0100000 0xc0116a00 0xc011= 6d00 =0D 0xc01344f5 sys_read+0x95 (0x0, 0x804df80, 0xfff, 0x1, 0x80494= 00) =0D kernel .text 0xc0100000 0xc0134460 0xc013= 4560 =0D 0xc0106f4b system_call+0x33 =0D kernel .text 0xc0100000 0xc0106f18 0xc010= 6f50 =0DEnter to end, to continue: =0DStack traceback for pid 547 =0D EBP EIP Function(args) =0D0xf6159f18 0xc01145c2 schedule+0x322 (0xf6367008, 0x1, 0xc0142549, 0x0, = 0x2) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf6159f48 0xc0114207 schedule_timeout+0x17 =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc0142649 do_pollfd+0x159 =0D kernel .text 0xc0100000 0xc01424f0 0xc014= 2670 =0DEnter to end, to continue: =0DStack traceback for pid 575 =0D EBP EIP Function(args) =0D0xf61e1f00 0xc01145c2 schedule+0x322 (0xf6471ac0, 0x0, 0xf636f2c0, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf61e1f30 0xc0114207 schedule_timeout+0x17 =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc02d67bf sock_poll+0x1f =0D kernel .text 0xc0100000 0xc02d67a0 0xc02d= 67d0 =0DEnter to end, to continue: =0DStack traceback for pid 752 =0D EBP EIP Function(args) =0D0xf622df24 0xc01145c2 schedule+0x322 (0x0, 0xf622c000, 0x0, 0x0, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf622df3c 0xc013c6db pipe_wait+0x7b (0xf61e97c0, 0xfffffff5, 0x0) =0D kernel .text 0xc0100000 0xc013c660 0xc013= c710 =0D 0xc013c7c4 pipe_read+0xb4 (0xf63775c0, 0xbffffaf0, 0x110, 0xf= 63775e0, 0xc011e602) =0D kernel .text 0xc0100000 0xc013c710 0xc013= c930 =0D 0xc01344f5 sys_read+0x95 (0x4, 0xbffffaf0, 0x110, 0xbffffaf0,= 0x4) =0D kernel .text 0xc0100000 0xc0134460 0xc013= 4560 =0D 0xc0106f4b system_call+0x33 =0D kernel .text 0xc0100000 0xc0106f18 0xc010= 6f50 =0DEnter to end, to continue: =0DStack traceback for pid 754 =0D EBP EIP Function(args) =0D0xf616df24 0xc01145c2 schedule+0x322 (0x0, 0xf616c000, 0x0, 0x0, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf616df3c 0xc013c6db pipe_wait+0x7b (0xf61e9bc0, 0xfffffff5, 0x0) =0D kernel .text 0xc0100000 0xc013c660 0xc013= c710 =0D 0xc013c7c4 pipe_read+0xb4 (0xf6533f40, 0xbffffaf0, 0x110, 0xf= 6533f60, 0xc011e602) =0D kernel .text 0xc0100000 0xc013c710 0xc013= c930 =0D 0xc01344f5 sys_read+0x95 (0x4, 0xbffffaf0, 0x110, 0xbffffaf0,= 0x4) =0D kernel .text 0xc0100000 0xc0134460 0xc013= 4560 =0D 0xc0106f4b system_call+0x33 =0D kernel .text 0xc0100000 0xc0106f18 0xc010= 6f50 =0DEnter to end, to continue: =0DStack traceback for pid 782 =0D EBP EIP Function(args) =0D0xf61b9f00 0xc01145c2 schedule+0x322 (0xc012637c, 0x0, 0xf62275c0, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf61b9f30 0xc0114207 schedule_timeout+0x17 =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc02d67bf sock_poll+0x1f =0D kernel .text 0xc0100000 0xc02d67a0 0xc02d= 67d0 =0DEnter to end, to continue: =0DStack traceback for pid 816 =0D EBP EIP Function(args) =0D0xf624bf00 0xc01145c2 schedule+0x322 (0xf652aa40, 0x0, 0xf648d140, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf624bf30 0xc0114207 schedule_timeout+0x17 =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc02d67bf sock_poll+0x1f =0D kernel .text 0xc0100000 0xc02d67a0 0xc02d= 67d0 =0DEnter to end, to continue: =0DStack traceback for pid 844 =0D EBP EIP Function(args) =0D0xf60f9f18 0xc01145c2 schedule+0x322 (0xee5c5008, 0x1, 0xc0142549, 0x0, = 0x2) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf60f9f48 0xc0114207 schedule_timeout+0x17 =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc0142649 do_pollfd+0x159 =0D kernel .text 0xc0100000 0xc01424f0 0xc014= 2670 =0DEnter to end, to continue: =0DStack traceback for pid 849 =0D EBP EIP Function(args) =0D0xf60eff18 0xc01145c2 schedule+0x322 (0xee5b7008, 0x1, 0xc0142549, 0x0, = 0x2) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf60eff48 0xc0114207 schedule_timeout+0x17 =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc0142649 do_pollfd+0x159 =0D kernel .text 0xc0100000 0xc01424f0 0xc014= 2670 =0DEnter to end, to continue: =0DStack traceback for pid 854 =0D EBP EIP Function(args) =0D0xf60e3ddc 0xc01145c2 schedule+0x322 (0x1, 0xf60e2000, 0xf60b9dec, 0xf60= afdec) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0105ca4 __down+0x54 =0D kernel .text 0xc0100000 0xc0105c50 0xc010= 5cf0 =0D 0xc0105df0 __down_failed+0x8 (0xc0228b50, 0xee7c1c44, 0xf60e3= e28, 0x0, 0xffffffff) =0D kernel .text 0xc0100000 0xc0105de8 0xc010= 5df4 =0D 0xc0228e93 _text_lock_xfs_file+0x5 (0xee4eb6c0, 0xf60e3eb8, 0= xf5d33e40, 0xfffffffe, 0x266f9280) =0D kernel .text 0xc0100000 0xc0228e8e 0xc022= 8eb0 =0D 0xc0191043 nfsd_open+0x193 (0xf60e3eb8, 0xf43ec0e8, 0x2000, 0= xf60e3ed8, 0x0) =0D kernel .text 0xc0100000 0xc0190eb0 0xc019= 1090 =0D 0xc0191515 nfsd_write+0x145 (0xf6230800, 0xf6230c04, 0xb30000= , 0x0, 0xf43ec0e8) =0D kernel .text 0xc0100000 0xc01913d0 0xc019= 1690 =0D 0xc0196610 nfsd3_proc_write+0xe0 (0xf6230800, 0xf60e4014, 0x0= , 0x27, 0x7) =0D kernel .text 0xc0100000 0xc0196530 0xc019= 6630 =0D 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf6230800, 0xf60e2= 570, 0xf6101240, 0xc04429c0) =0D kernel .text 0xc0100000 0xc031bf90 0xc031= c470 =0D 0xc018d96b nfsd+0x1bb =0D kernel .text 0xc0100000 0xc018d7b0 0xc018= daa0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 855 =0D EBP EIP Function(args) =0D0xf60dff64 0xc01145c2 schedule+0x322 (0xf60dffa0, 0x0, 0xf60de000, 0xf65= 2a800, 0xf60de000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf60dff94 0xc0114207 schedule_timeout+0x17 (0x0, 0xf60de000, 0x0, 0x0, = 0x0) =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc031d6e6 svc_recv+0x1a6 (0xf6101300, 0xf6230e00, 0x7fffffff= , 0xf6101300) =0D kernel .text 0xc0100000 0xc031d540 0xc031= d920 =0D 0xc019bdbe lockd+0x12e =0D kernel .text 0xc0100000 0xc019bc90 0xc019= bee0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 856 =0D EBP EIP Function(args) =0D0xf60ddfc4 0xc01145c2 schedule+0x322 (0xc045941c, 0x0, 0xf60dc000, 0xc04= 59414, 0xc0459414) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc031a8e2 rpciod+0x172 =0D kernel .text 0xc0100000 0xc031a770 0xc031= a990 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 857 =0D EBP EIP Function(args) =0D0xf60d7d3c 0xc01145c2 schedule+0x322 (0x0, 0xf60d6000, 0x0, 0x0, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc01325c2 kmap_high+0x92 (0x1f, 0x1000, 0xf7c2427c, 0xc2143b= 80, 0xee616534) =0D kernel .text 0xc0100000 0xc0132530 0xc013= 2680 =0D 0xc0127b77 file_read_actor+0x57 (0xee7c13c0, 0xf60d7e64, 0x0,= 0x0, 0x0) =0D kernel .text 0xc0100000 0xc0127b20 0xc012= 7c00 =0D 0xc02287fc linvfs_read+0x7c (0xf60d7eb4, 0xf60d8080, 0x2000, = 0xf60d7ed4, 0x0) =0D kernel .text 0xc0100000 0xc0228780 0xc022= 8830 =0D 0xc019133c nfsd_read+0x1cc (0xf60e0000, 0xf60e0404, 0x2fde000= , 0x0, 0xf60d8080) =0D kernel .text 0xc0100000 0xc0191170 0xc019= 13d0 =0D 0xc01964cc nfsd3_proc_read+0xfc (0xf60e0000, 0xf60d8014, 0x0,= 0x27, 0x6) =0D kernel .text 0xc0100000 0xc01963d0 0xc019= 6530 =0D 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60e0000, 0xf60d6= 570, 0xf6101240, 0xf60d5fd0) =0D kernel .text 0xc0100000 0xc031bf90 0xc031= c470 =0D 0xc018d96b nfsd+0x1bb =0D kernel .text 0xc0100000 0xc018d7b0 0xc018= daa0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 858 =0D EBP EIP Function(args) =0D0xf60d5ddc 0xc01145c2 schedule+0x322 (0x1, 0xf60d4000, 0xf60afdec, 0xf60= c3dec) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0105ca4 __down+0x54 =0D kernel .text 0xc0100000 0xc0105c50 0xc010= 5cf0 =0D 0xc0105df0 __down_failed+0x8 (0xc0228b50, 0xee7c1c44, 0xf60d5= e28, 0x0, 0xffffffff) =0D kernel .text 0xc0100000 0xc0105de8 0xc010= 5df4 =0D 0xc0228e93 _text_lock_xfs_file+0x5 (0xee4eb6c0, 0xf60d5eb8, 0= xf5d33e40, 0xfffffffe, 0x266f9280) =0D kernel .text 0xc0100000 0xc0228e8e 0xc022= 8eb0 =0D 0xc0191043 nfsd_open+0x193 (0xf60d5eb8, 0xf41740e8, 0x2000, 0= xf60d5ed8, 0x0) =0D kernel .text 0xc0100000 0xc0190eb0 0xc019= 1090 =0D 0xc0191515 nfsd_write+0x145 (0xf60e0600, 0xf60e0a04, 0xb20000= , 0x0, 0xf41740e8) =0D kernel .text 0xc0100000 0xc01913d0 0xc019= 1690 =0D 0xc0196610 nfsd3_proc_write+0xe0 (0xf60e0600, 0xf60d0014, 0x0= , 0x27, 0x7) =0D kernel .text 0xc0100000 0xc0196530 0xc019= 6630 =0D 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60e0600, 0xf60d4= 570, 0xf6101240, 0xf60e3fd0) =0D kernel .text 0xc0100000 0xc031bf90 0xc031= c470 =0D 0xc018d96b nfsd+0x1bb =0D kernel .text 0xc0100000 0xc018d7b0 0xc018= daa0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 859 =0D EBP EIP Function(args) =0D0xf60cdbb8 0xc01145c2 schedule+0x322 (0x0, 0xf60cc000, 0x0, 0x0, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc01325c2 kmap_high+0x92 (0xc0136671, 0x0, 0x0, 0xb10, 0x0) =0D kernel .text 0xc0100000 0xc0132530 0xc013= 2680 =0D 0xc022721b __pb_block_prepare_write_async+0x7b (0xee4eb6c0, 0= xc27e3740, 0x0, 0x1000, 0x1) =0D kernel .text 0xc0100000 0xc02271a0 0xc022= 7430 =0D 0xc022657e pagebuf_iozero+0x10e (0xee4eb6c0, 0xee2998c0, 0x0,= 0x1000, 0xb12000) =0D kernel .text 0xc0100000 0xc0226470 0xc022= 66b0 =0D 0xc022c501 xfs_zero_eof+0x391 (0xee4eb7e4, 0xee7c1d3c, 0xb100= 00, 0x0, 0xb0a000) =0D kernel .text 0xc0100000 0xc022c170 0xc022= c590 =0D 0xc022c790 xfs_write+0x200 (0xee7c1c44, 0xf60cde30, 0x8001, 0= x0, 0x0) =0D kernel .text 0xc0100000 0xc022c590 0xc022= ca10 =0D 0xc0228ae6 linvfs_write+0x2b6 (0xf60cdeb8, 0xf42640e8, 0x2000= , 0xf60cded8, 0x0) =0D kernel .text 0xc0100000 0xc0228830 0xc022= 8b30 =0D 0xc0191515 nfsd_write+0x145 (0x0, 0x0, 0xf5d33e40, 0xc281f5c0= , 0xc0445a80) =0D kernel .text 0xc0100000 0xc01913d0 0xc019= 1690 =0D0xf60cded8 0xc02d63bb sock_sendmsg+0x6b (0xf60e0c00, 0xf60c8014, 0x0, 0x= 27, 0x7) =0D kernel .text 0xc0100000 0xc02d6350 0xc02d= 63e0 =0D 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60e0c00, 0xf60cc= 570, 0xf6101240, 0xf60d7fd0) =0D kernel .text 0xc0100000 0xc031bf90 0xc031= c470 =0D 0xc018d96b nfsd+0x1bb =0D kernel .text 0xc0100000 0xc018d7b0 0xc018= daa0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 860 =0D EBP EIP Function(args) =0D0xf60c3ddc 0xc01145c2 schedule+0x322 (0x1, 0xf60c2000, 0xf60d5dec, 0xf60= c1dec) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0105ca4 __down+0x54 =0D kernel .text 0xc0100000 0xc0105c50 0xc010= 5cf0 =0D 0xc0105df0 __down_failed+0x8 (0xc0228b50, 0xee7c1c44, 0xf60c3= e28, 0x0, 0xffffffff) =0D kernel .text 0xc0100000 0xc0105de8 0xc010= 5df4 =0D 0xc0228e93 _text_lock_xfs_file+0x5 (0xee4eb6c0, 0xf60c3eb8, 0= xf5d33e40, 0xfffffffe, 0x266f9280) =0D kernel .text 0xc0100000 0xc0228e8e 0xc022= 8eb0 =0D 0xc0191043 nfsd_open+0x193 (0xf60c3eb8, 0xf40100e8, 0x2000, 0= xf60c3ed8, 0x0) =0D kernel .text 0xc0100000 0xc0190eb0 0xc019= 1090 =0D 0xc0191515 nfsd_write+0x145 (0xf60cf200, 0xf60cf604, 0xb18000= , 0x0, 0xf40100e8) =0D kernel .text 0xc0100000 0xc01913d0 0xc019= 1690 =0D 0xc0196610 nfsd3_proc_write+0xe0 (0xf60cf200, 0xf60c4014, 0x0= , 0x27, 0x7) =0D kernel .text 0xc0100000 0xc0196530 0xc019= 6630 =0D 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60cf200, 0xf60c2= 570, 0xf6101240, 0xf60cdfd0) =0D kernel .text 0xc0100000 0xc031bf90 0xc031= c470 =0D 0xc018d96b nfsd+0x1bb =0D kernel .text 0xc0100000 0xc018d7b0 0xc018= daa0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 861 =0D EBP EIP Function(args) =0D0xf60c1ddc 0xc01145c2 schedule+0x322 (0x1, 0xf60c0000, 0xf60c3dec, 0xee4= eb738) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0105ca4 __down+0x54 =0D kernel .text 0xc0100000 0xc0105c50 0xc010= 5cf0 =0D 0xc0105df0 __down_failed+0x8 (0xc0228b50, 0xee7c1c44, 0xf60c1= e28, 0x0, 0xffffffff) =0D kernel .text 0xc0100000 0xc0105de8 0xc010= 5df4 =0D 0xc0228e93 _text_lock_xfs_file+0x5 (0xee4eb6c0, 0xf60c1eb8, 0= xf5d33e40, 0xb0a000, 0x266f9280) =0D kernel .text 0xc0100000 0xc0228e8e 0xc022= 8eb0 =0D 0xc0191043 nfsd_open+0x193 (0xf60c1eb8, 0xf40880e8, 0x2000, 0= xf60c1ed8, 0x0) =0D kernel .text 0xc0100000 0xc0190eb0 0xc019= 1090 =0D 0xc0191515 nfsd_write+0x145 (0xf60cf800, 0xf60cfc04, 0xb0a000= , 0x0, 0xf40880e8) =0D kernel .text 0xc0100000 0xc01913d0 0xc019= 1690 =0D 0xc0196610 nfsd3_proc_write+0xe0 (0xf60cf800, 0xf60bc014, 0x0= , 0x27, 0x7) =0D kernel .text 0xc0100000 0xc0196530 0xc019= 6630 =0D 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60cf800, 0xf60c0= 570, 0xf6101240, 0xf60c3fd0) =0D kernel .text 0xc0100000 0xc031bf90 0xc031= c470 =0D 0xc018d96b nfsd+0x1bb =0D kernel .text 0xc0100000 0xc018d7b0 0xc018= daa0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 862 =0D EBP EIP Function(args) =0D0xf60b9ddc 0xc01145c2 schedule+0x322 (0x1, 0xf60b8000, 0xee4eb738, 0xf60= e3dec) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0105ca4 __down+0x54 =0D kernel .text 0xc0100000 0xc0105c50 0xc010= 5cf0 =0D 0xc0105df0 __down_failed+0x8 (0xc0228b50, 0xee7c1c44, 0xf60b9= e28, 0x0, 0xffffffff) =0D kernel .text 0xc0100000 0xc0105de8 0xc010= 5df4 =0D 0xc0228e93 _text_lock_xfs_file+0x5 (0xee4eb6c0, 0xf60b9eb8, 0= xf5d33e40, 0xfffffffe, 0x266f9280) =0D kernel .text 0xc0100000 0xc0228e8e 0xc022= 8eb0 =0D 0xc0191043 nfsd_open+0x193 (0xf60b9eb8, 0xf3ce40e8, 0x2000, 0= xf60b9ed8, 0x0) =0D kernel .text 0xc0100000 0xc0190eb0 0xc019= 1090 =0D 0xc0191515 nfsd_write+0x145 (0xf60cfe00, 0xf60bb204, 0xb38000= , 0x0, 0xf3ce40e8) =0D kernel .text 0xc0100000 0xc01913d0 0xc019= 1690 =0D 0xc0196610 nfsd3_proc_write+0xe0 (0xf60cfe00, 0xf60b4014, 0x0= , 0x27, 0x7) =0D kernel .text 0xc0100000 0xc0196530 0xc019= 6630 =0D 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60cfe00, 0xf60b8= 570, 0xf6101240, 0xf60c1fd0) =0D kernel .text 0xc0100000 0xc031bf90 0xc031= c470 =0D 0xc018d96b nfsd+0x1bb =0D kernel .text 0xc0100000 0xc018d7b0 0xc018= daa0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 863 =0D EBP EIP Function(args) =0D0xf60afddc 0xc01145c2 schedule+0x322 (0x1, 0xf60ae000, 0xf60e3dec, 0xf60= d5dec) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0105ca4 __down+0x54 =0D kernel .text 0xc0100000 0xc0105c50 0xc010= 5cf0 =0D 0xc0105df0 __down_failed+0x8 (0xc0228b50, 0xee7c1c44, 0xf60af= e28, 0x0, 0xffffffff) =0D kernel .text 0xc0100000 0xc0105de8 0xc010= 5df4 =0D 0xc0228e93 _text_lock_xfs_file+0x5 (0xee4eb6c0, 0xf60afeb8, 0= xf5d33e40, 0xfffffffe, 0x266f9280) =0D kernel .text 0xc0100000 0xc0228e8e 0xc022= 8eb0 =0D 0xc0191043 nfsd_open+0x193 (0xf60afeb8, 0xf4b340e8, 0x2000, 0= xf60afed8, 0x0) =0D kernel .text 0xc0100000 0xc0190eb0 0xc019= 1090 =0D 0xc0191515 nfsd_write+0x145 (0xf60bb400, 0xf60bb804, 0xb28000= , 0x0, 0xf4b340e8) =0D kernel .text 0xc0100000 0xc01913d0 0xc019= 1690 =0D 0xc0196610 nfsd3_proc_write+0xe0 (0xf60bb400, 0xf60b0014, 0x0= , 0x27, 0x7) =0D kernel .text 0xc0100000 0xc0196530 0xc019= 6630 =0D 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60bb400, 0xf60ae= 570, 0xf6101240, 0xf60b9fd0) =0D kernel .text 0xc0100000 0xc031bf90 0xc031= c470 =0D 0xc018d96b nfsd+0x1bb =0D kernel .text 0xc0100000 0xc018d7b0 0xc018= daa0 =0D 0xc0105746 kernel_thread+0x26 =0D kernel .text 0xc0100000 0xc0105720 0xc010= 5750 =0DEnter to end, to continue: =0DStack traceback for pid 948 =0D EBP EIP Function(args) =0D0xf609defc 0xc01145c2 schedule+0x322 (0xf609df08, 0xc04a8064, 0xc04a8064= , 0x334b7, 0xf609c000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf609df30 0xc011426d schedule_timeout+0x7d =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc02d67bf sock_poll+0x1f =0D kernel .text 0xc0100000 0xc02d67a0 0xc02d= 67d0 =0DEnter to end, to continue: =0DStack traceback for pid 952 =0D EBP EIP Function(args) =0D0xf5f35efc 0xc01145c2 schedule+0x322 (0xf5f35f08, 0xc04a7ee4, 0xc04574a4= , 0x34457, 0xf5f34000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf5f35f30 0xc011426d schedule_timeout+0x7d =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc02d67bf sock_poll+0x1f =0D kernel .text 0xc0100000 0xc02d67a0 0xc02d= 67d0 =0DEnter to end, to continue: =0DStack traceback for pid 953 =0D EBP EIP Function(args) =0D0xf5f2fefc 0xc01145c2 schedule+0x322 (0xf5f2ff08, 0xc04a7d34, 0xc04a7d34= , 0x4abc6, 0xf5f2e000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf5f2ff30 0xc011426d schedule_timeout+0x7d =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc02d67bf sock_poll+0x1f =0D kernel .text 0xc0100000 0xc02d67a0 0xc02d= 67d0 =0DEnter to end, to continue: =0DStack traceback for pid 954 =0D EBP EIP Function(args) =0D0xf5f29efc 0xc01145c2 schedule+0x322 (0xf5f29f08, 0xc04a80b4, 0xc04a80b4= , 0x33ede, 0xf5f28000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf5f29f30 0xc011426d schedule_timeout+0x7d =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc02d67bf sock_poll+0x1f =0D kernel .text 0xc0100000 0xc02d67a0 0xc02d= 67d0 =0DEnter to end, to continue: =0DStack traceback for pid 969 =0D EBP EIP Function(args) =0D0xf5ebbefc 0xc01145c2 schedule+0x322 (0xf5ebbf08, 0xc04a7ac4, 0xc04a7ac4= , 0x83edb7, 0xf5eba000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf5ebbf30 0xc011426d schedule_timeout+0x7d =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc02d67bf sock_poll+0x1f =0D kernel .text 0xc0100000 0xc02d67a0 0xc02d= 67d0 =0DEnter to end, to continue: =0DStack traceback for pid 987 =0D EBP EIP Function(args) =0D0xf5eb1f6c 0xc01145c2 schedule+0x322 (0xf5eb1f78, 0xc04a8084, 0xc04a8084= , 0x338a3, 0xf5eb0000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf5eb1fa0 0xc011426d schedule_timeout+0x7d (0x3c, 0x0) =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D0xf5eb1fa8 0xc011e7c2 sys_nanosleep+0x122 (0xbffffb38, 0xbffffb38, 0x401= 566b4, 0xbffffb38, 0x10000) =0D kernel .text 0xc0100000 0xc011e6a0 0xc011= e840 =0D 0xc0106f4b system_call+0x33 =0D kernel .text 0xc0100000 0xc0106f18 0xc010= 6f50 =0DEnter to end, to continue: =0DStack traceback for pid 1043 =0D EBP EIP Function(args) =0D0xf5da9efc 0xc01145c2 schedule+0x322 (0xf5da9f08, 0xc04a7d1c, 0xc04a7d1c= , 0x3c1a8, 0xf5da8000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf5da9f30 0xc011426d schedule_timeout+0x7d =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc02d67bf sock_poll+0x1f =0D kernel .text 0xc0100000 0xc02d67a0 0xc02d= 67d0 =0DEnter to end, to continue: =0DStack traceback for pid 1079 =0D EBP EIP Function(args) =0D0xf5d91f6c 0xc01145c2 schedule+0x322 (0xf5d91f78, 0xc04a7d54, 0xc04a7d54= , 0x5968b, 0xf5d90000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf5d91fa0 0xc011426d schedule_timeout+0x7d (0xe10, 0x0) =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D0xf5d91fa8 0xc011e7c2 sys_nanosleep+0x122 (0xbffffac8, 0xbffffac8, 0x401= 566b4, 0xbffffac8, 0x10000) =0D kernel .text 0xc0100000 0xc011e6a0 0xc011= e840 =0D 0xc0106f4b system_call+0x33 =0D kernel .text 0xc0100000 0xc0106f18 0xc010= 6f50 =0DEnter to end, to continue: =0DStack traceback for pid 1094 =0D EBP EIP Function(args) =0D0xf5d85efc 0xc01145c2 schedule+0x322 (0xf5d85f08, 0xc04a8134, 0xc04a8134= , 0x32c0a, 0xf5d84000) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xf5d85f30 0xc011426d schedule_timeout+0x7d =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc02d67bf sock_poll+0x1f =0D kernel .text 0xc0100000 0xc02d67a0 0xc02d= 67d0 =0DEnter to end, to continue: =0DStack traceback for pid 1100 =0D EBP EIP Function(args) =0D0xf64fbf88 0xc01145c2 schedule+0x322 (0x0, 0xf64fa000, 0x0, 0x0, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0119de1 sys_wait4+0x371 (0xffffffff, 0x0, 0x0, 0x0, 0x14) =0D kernel .text 0xc0100000 0xc0119a70 0xc011= 9e10 =0D 0xc0106f4b system_call+0x33 =0D kernel .text 0xc0100000 0xc0106f18 0xc010= 6f50 =0DEnter to end, to continue: =0DStack traceback for pid 1129 =0D EBP EIP Function(args) =0D0xf5d39f88 0xc01145c2 schedule+0x322 (0x0, 0xf5d38000, 0x0, 0x0, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc0119de1 sys_wait4+0x371 (0xffffffff, 0xbffffc38, 0x2, 0x0,= 0xffffffff) =0D kernel .text 0xc0100000 0xc0119a70 0xc011= 9e10 =0D 0xc0106f4b system_call+0x33 =0D kernel .text 0xc0100000 0xc0106f18 0xc010= 6f50 =0DEnter to end, to continue: =0DStack traceback for pid 1250 =0D EBP EIP Function(args) =0D0xee3dbf00 0xc01145c2 schedule+0x322 (0xee3da000, 0xee3dbf30, 0xf5e09380= , 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D0xee3dbf30 0xc0114207 schedule_timeout+0x17 =0D kernel .text 0xc0100000 0xc01141f0 0xc011= 4290 =0D 0xc02d67bf sock_poll+0x1f =0D kernel .text 0xc0100000 0xc02d67a0 0xc02d= 67d0 =0DEnter to end, to continue: =0DStack traceback for pid 1369 =0D EBP EIP Function(args) =0D0xf40b9d44 0xc01145c2 schedule+0x322 (0x0, 0xf40b8000, 0x0, 0x0, 0x0) =0D kernel .text 0xc0100000 0xc01142a0 0xc011= 45f0 =0D 0xc01325c2 kmap_high+0x92 (0x1f, 0x80, 0xf7d28bec, 0xc2772480= , 0xf5d26d34) =0D kernel .text 0xc0100000 0xc0132530 0xc013= 2680 =0D 0xc0127b77 file_read_actor+0x57 (0xee7d0d40, 0xf40b9e54, 0x80= , 0xf40b9e20, 0x0) =0D kernel .text 0xc0100000 0xc0127b20 0xc012= 7c00 =0D 0xc013ba4a kernel_read+0x4a (0xee7d0d40, 0x0, 0xf40b9e54, 0x8= 0) =0D kernel .text 0xc0100000 0xc013ba00 0xc013= ba60 =0D 0xc013bf16 prepare_binprm+0x116 (0xf40b9e54, 0x0, 0x0, 0x0, 0= x0) =0D kernel .text 0xc0100000 0xc013be00 0xc013= bf20 =0D 0xc013c40c do_execve+0x10c (0xf3b12000, 0x80f8d8c, 0x80d360c,= 0xf40b9fc4) =0D kernel .text 0xc0100000 0xc013c300 0xc013= c4e0 =0D 0xc0105b8d sys_execve+0x2d (0x80f8e0c, 0x80f8d8c, 0x80d360c, = 0x80f8e0c, 0x80f8e0c) =0D kernel .text 0xc0100000 0xc0105b60 0xc010= 5bc0 =0D 0xc0106f4b system_call+0x33 =0D kernel .text 0xc0100000 0xc0106f18 0xc010= 6f50 =0DEnter to end, to continue: =0Dkdb>=20 =0Dkdb> =0D (Back at mathcons)=0D ----------------------------------------------------=0D C-Kermit 7.0.196, 1 Jan 2000, for Linux=0D =0D Copyright (C) 1985, 2000,=0D Trustees of Columbia University in the City of New York.=0D Type ? or HELP for help.=0D =0D(/root/) C-Kermit>quit=0D Closing /dev/ttyN000...OK=0D =1B]0;root@mathcons: /root=07[root@mathcons /root]# exit Script done on Mon Mar 11 15:23:12 2002 --fdj2RfSjLxBAspz7-- From owner-linux-xfs@oss.sgi.com Mon Mar 11 13:45:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BLjwq13417 for linux-xfs-outgoing; Mon, 11 Mar 2002 13:45:58 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BLjn913395 for ; Mon, 11 Mar 2002 13:45:49 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2BKjhbX002185 for ; Mon, 11 Mar 2002 12:45:43 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA09060; Mon, 11 Mar 2002 14:45:42 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA68705; Mon, 11 Mar 2002 14:45:42 -0600 (CST) Subject: Re: odd problem with XFS & NFS (locking up system) From: Eric Sandeen To: Dave Alden Cc: Keith Owens , linux-xfs@oss.sgi.com In-Reply-To: <20020311152455.A6907@math.ohio-state.edu> References: <20020311144914.A6662@math.ohio-state.edu> <523.1015876602@ocs3.intra.ocs.com.au> <20020311152455.A6907@math.ohio-state.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Mar 2002 14:45:42 -0600 Message-Id: <1015879542.30864.12.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-11 at 14:24, Dave Alden wrote: > Hi, > > On Tue, Mar 12, 2002 at 06:56:42AM +1100, Keith Owens wrote: > > Under kdb, do > > set LINES 2000 > > ps > > bta > > The fact that you can do control-A and get to kdb means that it is not > > a complete kernel lockup, rather some code is sitting in interruptible > > wait. ps and bta will show which tasks are waiting and why. > > Ok -- here it is. :-) Yep, there it is: Stack traceback for pid 859 EBP EIP Function(args) 0xf60cdbb8 0xc01145c2 schedule+0x322 (0x0, 0xf60cc000, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc01142a0 0xc01145f0 0xc01325c2 kmap_high+0x92 (0xc0136671, 0x0, 0x0, 0xb10, 0x0) kernel .text 0xc0100000 0xc0132530 0xc0132680 0xc022721b __pb_block_prepare_write_async+0x7b (0xee4eb6c0, 0xc27e3740, 0x0, 0x1000, 0x1) kernel .text 0xc0100000 0xc02271a0 0xc0227430 0xc022657e pagebuf_iozero+0x10e (0xee4eb6c0, 0xee2998c0, 0x0, 0x1000, 0xb12000) kernel .text 0xc0100000 0xc0226470 0xc02266b0 0xc022c501 xfs_zero_eof+0x391 (0xee4eb7e4, 0xee7c1d3c, 0xb10000, 0x0, 0xb0a000) kernel .text 0xc0100000 0xc022c170 0xc022c590 0xc022c790 xfs_write+0x200 (0xee7c1c44, 0xf60cde30, 0x8001, 0x0, 0x0) kernel .text 0xc0100000 0xc022c590 0xc022ca10 0xc0228ae6 linvfs_write+0x2b6 (0xf60cdeb8, 0xf42640e8, 0x2000, 0xf60cded8, 0x0) kernel .text 0xc0100000 0xc0228830 0xc0228b30 0xc0191515 nfsd_write+0x145 (0x0, 0x0, 0xf5d33e40, 0xc281f5c0, 0xc0445a80) kernel .text 0xc0100000 0xc01913d0 0xc0191690 0xf60cded8 0xc02d63bb sock_sendmsg+0x6b (0xf60e0c00, 0xf60c8014, 0x0, 0x27, 0x7) kernel .text 0xc0100000 0xc02d6350 0xc02d63e0 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60e0c00, 0xf60cc570, 0xf6101240, 0xf60d7fd0) kernel .text 0xc0100000 0xc031bf90 0xc031c470 0xc018d96b nfsd+0x1bb kernel .text 0xc0100000 0xc018d7b0 0xc018daa0 0xc0105746 kernel_thread+0x26 kernel .text 0xc0100000 0xc0105720 0xc0105750 I was in there recently... let me take a look. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Mar 11 14:12:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BMC1613986 for linux-xfs-outgoing; Mon, 11 Mar 2002 14:12:01 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BMBq913964 for ; Mon, 11 Mar 2002 14:11:53 -0800 Received: (qmail 16430 invoked by uid 500); 11 Mar 2002 21:11:15 -0000 Subject: Re: cloning computers with xfs From: Austin Gonyou To: Vance Lankhaar Cc: Francis Yom , linux-xfs@oss.sgi.com, Shawn Starr In-Reply-To: <200203090809.g2989Zo06671@vance.pcsscreston.ca> References: <200203090809.g2989Zo06671@vance.pcsscreston.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 11 Mar 2002 15:11:15 -0600 Message-Id: <1015881075.15563.48.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I also released a set of patches to get XFS support working under System Imager. On Sat, 2002-03-09 at 02:09, Vance Lankhaar wrote: > On Sunday 10 March 2002 04:28, Francis Yom wrote: > >It uses afio to do the backup. Has anyone used this utility or can > >vouch for afio as being safe to backup xfs partitions. > > I've talked to Hugo (the developer) about it, and he says that Mondo can > > handle xfs no problems, so I can't see that it would be a problem. > > Vance > > ------------------------------------------------------------ > Vance Lankhaar vance@pcsscreston.ca > PCSS Yearbook yearbook@pcsscreston.ca > PCSS Computers sysadmins@pcsscreston.ca > http://www.crestonbc.com/pcss/ http://www.pcsscreston.ca > ------------------------------------------------------------ -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Mar 11 14:32:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BMWwo14564 for linux-xfs-outgoing; Mon, 11 Mar 2002 14:32:58 -0800 Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BMWp914542 for ; Mon, 11 Mar 2002 14:32:51 -0800 Received: from umbi.umd.edu (amanda.carb.nist.gov [129.6.113.5]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GSTVVU00.H7G; Mon, 11 Mar 2002 16:33:30 -0500 Message-ID: <3C8D2272.90078233@umbi.umd.edu> Date: Mon, 11 Mar 2002 16:32:34 -0500 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-31SGI_XFS_1.0.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Austin Gonyou CC: Vance Lankhaar , Francis Yom , linux-xfs@oss.sgi.com, Shawn Starr Subject: Re: cloning computers with xfs References: <200203090809.g2989Zo06671@vance.pcsscreston.ca> <1015881075.15563.48.camel@UberGeek> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm using rsync or xfsdump to clone systems with a few different methods. BTW you can sort of emulate xfscopy by piping xfsdump to xfsrestore. You can find info on rsync at rsync.samba.org or poke around on freshmeat.net. 1. rsync over the network I partition the system with 2 root partitions, one that holds the running OS, and I use rsync to copy a root filesystem to the second root partition. Finally, you edit fstab on the cloned system, and add an entry in lilo.conf to boot the new OS. This setup has a couple fringe benefits: a) you can install a beta version of the OS on one partition and revert to the stable version if you have problems; b) between upgrades, you can mirror the root filesystem so eg. if your box gets hacked or the root fs gets trashed, you can boot into the other "clean" copy. 2. rsync from disk to disk This method is done most easily if you have removable hard drive cartridge and bracket. I get ATA-100 cartridge/bracket for $22. You could also use external SCSI or even hot swap SCSI bay. I keep the "master" copy on my workstation which has a removable drive bay, so I just shut down and install the cartridge with the disk that I want to clone to. 3. xfsdump over the network I do an xfsdump of the root that I want to clone to a file and compress with gzip or bzip2 and make this "image" accessible via NFS. I use a set up with 2 root partitions like #1 because you don't want to write over the running OS. Then I just use xfsrestore to extract the root onto the 2nd root partition. 4. xfsdump from disk to disk Similar to #2, but use xfsrestore to extract onto the disk in the removable cartridge. -- "Jonathan F. Dill" (dill@umbi.umd.edu) UMBI CARB IT Coordinator Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Mon Mar 11 14:39:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BMdZY14775 for linux-xfs-outgoing; Mon, 11 Mar 2002 14:39:35 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BMbA914722 for ; Mon, 11 Mar 2002 14:37:10 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2BLb5bX004425 for ; Mon, 11 Mar 2002 13:37:05 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA98459; Mon, 11 Mar 2002 15:37:04 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA55431; Mon, 11 Mar 2002 15:37:04 -0600 (CST) Subject: Re: odd problem with XFS & NFS (locking up system) From: Eric Sandeen To: Dave Alden Cc: Keith Owens , linux-xfs@oss.sgi.com In-Reply-To: <20020311152455.A6907@math.ohio-state.edu> References: <20020311144914.A6662@math.ohio-state.edu> <523.1015876602@ocs3.intra.ocs.com.au> <20020311152455.A6907@math.ohio-state.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Mar 2002 15:37:04 -0600 Message-Id: <1015882624.28288.18.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Does this help? (Thank Steve if it does...) -Eric --- linux/fs/xfs/pagebuf/page_buf_io.c_1.15 Mon Mar 11 15:35:41 2002 +++ linux/fs/xfs/pagebuf/page_buf_io.c Mon Mar 11 15:35:28 2002 @@ -310,7 +310,8 @@ __pb_block_prepare_write_async(ip, page, cpoff, cpoff+csize, at_eof, NULL, pbmapp, PBF_WRITE); - memset((void *) (kmap(page) + cpoff), 0, csize); + /* __pb_block_prepare_write already kmap'd the page */ + memset((void *) (page_address(page) + cpoff), 0, csize); pagebuf_commit_write_core(ip, page, cpoff, cpoff + csize); pos = ((loff_t)page->index << PAGE_CACHE_SHIFT) + cpoff + csize; On Mon, 2002-03-11 at 14:24, Dave Alden wrote: > Hi, > > On Tue, Mar 12, 2002 at 06:56:42AM +1100, Keith Owens wrote: > > Under kdb, do > > set LINES 2000 > > ps > > bta > > The fact that you can do control-A and get to kdb means that it is not > > a complete kernel lockup, rather some code is sitting in interruptible > > wait. ps and bta will show which tasks are waiting and why. > > Ok -- here it is. :-) > > ...dave > ---- > > Script started on Mon Mar 11 15:22:39 2002 > ]0;root@mathcons: /root[root@mathcons /root]# kermit -l /dev/ttyN000 -b 38400 -c > Connecting to /dev/ttyN000, speed 38400. > The escape character is Ctrl-\ (ASCII 28, FS) > Type the escape character followed by C to get back, > or followed by ? to see other options. > ---------------------------------------------------- > > kdb> set LINES 2000 > kdb> ps > Task Addr Pid Parent [*] cpu State Thread Command > 0xc2814000 00000001 00000000 1 000 stop 0xc2814270 init > 0xc2838000 00000002 00000001 1 000 stop 0xc2838270 keventd > 0xc2834000 00000003 00000000 1 000 stop 0xc2834270 ksoftirqd_CPU0 > 0xc2832000 00000004 00000000 1 000 stop 0xc2832270 kswapd > 0xf7bee000 00000005 00000000 1 000 stop 0xf7bee270 bdflush > 0xf7bec000 00000006 00000000 1 000 stop 0xf7bec270 kupdated > 0xf7be4000 00000007 00000001 1 000 stop 0xf7be4270 pagebuf_daemon > 0xf7bcc000 00000008 00000001 1 000 stop 0xf7bcc270 i2oevtd > 0xf7bc4000 00000009 00000001 1 000 stop 0xf7bc4270 i2oblock > 0xf7a5a000 00000013 00000001 1 000 stop 0xf7a5a270 scsi_eh_0 > 0xf7a58000 00000014 00000001 1 000 stop 0xf7a58270 scsi_eh_1 > 0xf6536000 00000015 00000001 1 000 stop 0xf6536270 kjournald > 0xf643e000 00000106 00000001 1 000 stop 0xf643e270 kjournald > 0xf6238000 00000458 00000001 1 000 stop 0xf6238270 dhcpcd > 0xf622a000 00000522 00000001 1 000 stop 0xf622a270 syslogd > 0xf6222000 00000527 00000001 1 000 stop 0xf6222270 klogd > 0xf6158000 00000547 00000001 1 000 stop 0xf6158270 portmap > 0xf61e0000 00000575 00000001 1 000 stop 0xf61e0270 rpc.statd > 0xf622c000 00000752 00000001 1 000 stop 0xf622c270 automount > 0xf616c000 00000754 00000001 1 000 stop 0xf616c270 automount > 0xf61b8000 00000782 00000001 1 000 stop 0xf61b8270 sshd > 0xf624a000 00000816 00000001 1 000 stop 0xf624a270 xinetd > 0xf60f8000 00000844 00000001 1 000 stop 0xf60f8270 rpc.rquotad > 0xf60ee000 00000849 00000001 1 000 stop 0xf60ee270 rpc.mountd > 0xf60e2000 00000854 00000001 1 000 stop 0xf60e2270 nfsd > 0xf60de000 00000855 00000001 1 000 stop 0xf60de270 lockd > 0xf60dc000 00000856 00000855 1 000 stop 0xf60dc270 rpciod > 0xf60d6000 00000857 00000001 1 000 stop 0xf60d6270 nfsd > 0xf60d4000 00000858 00000001 1 000 stop 0xf60d4270 nfsd > 0xf60cc000 00000859 00000001 1 000 stop 0xf60cc270 nfsd > 0xf60c2000 00000860 00000001 1 000 stop 0xf60c2270 nfsd > 0xf60c0000 00000861 00000001 1 000 stop 0xf60c0270 nfsd > 0xf60b8000 00000862 00000001 1 000 stop 0xf60b8270 nfsd > 0xf60ae000 00000863 00000001 1 000 stop 0xf60ae270 nfsd > 0xf609c000 00000948 00000001 1 000 stop 0xf609c270 master > 0xf5f34000 00000952 00000948 1 000 stop 0xf5f34270 pickup > 0xf5f2e000 00000953 00000948 1 000 stop 0xf5f2e270 qmgr > 0xf5f28000 00000954 00000948 1 000 stop 0xf5f28270 tlsmgr > 0xf5eba000 00000969 00000001 1 000 stop 0xf5eba270 gpm > 0xf5eb0000 00000987 00000001 1 000 stop 0xf5eb0270 crond > 0xf5da8000 00001043 00000001 1 000 stop 0xf5da8270 xfs > 0xf5d90000 00001079 00000001 1 000 stop 0xf5d90270 atd > 0xf5d84000 00001094 00000001 1 000 stop 0xf5d84270 cupsd > 0xf64fa000 00001100 00000001 1 000 stop 0xf64fa270 login > 0xf5d38000 00001129 00001100 1 000 stop 0xf5d38270 bash > 0xee3da000 00001250 00000001 1 000 stop 0xee3da270 ntpd > 0xf40b8000 00001369 00001129 1 000 stop 0xf40b8270 bash > kdb> bta > Stack traceback for pid 1 > EBP EIP Function(args) > 0xc2815efc 0xc01145c2 schedule+0x322 (0xc2815f08, 0xc04a802c, 0xc04cf300, 0x32da5, 0xc2814000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc2815f30 0xc011426d schedule_timeout+0x7d (0xc2815f54, 0x400, 0xc2814000, 0x1f4, 0xb) > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc014200b do_select+0x1fb (0xb, 0xc2815f90, 0xc2815f8c, 0xf64ed3c0, 0x0) > kernel .text 0xc0100000 0xc0141e10 0xc0142040 > 0xc014239c sys_select+0x32c (0xb, 0xbffff900, 0x0, 0x0, 0xbffff838) > kernel .text 0xc0100000 0xc0142070 0xc01424f0 > 0xc0106f4b system_call+0x33 > kernel .text 0xc0100000 0xc0106f18 0xc0106f50 > Enter to end, to continue: > Stack traceback for pid 2 > EBP EIP Function(args) > 0xc2839f88 0xc01145c2 schedule+0x322 (0xa, 0xc2838560, 0xc2838570, 0xc2839fd0, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc012261d context_thread+0xfd > kernel .text 0xc0100000 0xc0122520 0xc01226d0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 3 > EBP EIP Function(args) > 0xc2835fe0 0xc01145c2 schedule+0x322 > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc011af0f ksoftirqd+0x6f > kernel .text 0xc0100000 0xc011aea0 0xc011af60 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 4 > EBP EIP Function(args) > 0xc2833fbc 0xc01145c2 schedule+0x322 (0x10f00, 0xc012d880, 0x0, 0xc2815fb8, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc012d908 kswapd+0x88 > kernel .text 0xc0100000 0xc012d880 0xc012d940 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 5 > EBP EIP Function(args) > 0xf7beffbc 0xc01145c2 schedule+0x322 (0x0, 0xf7bee000, 0xc043f8ac, 0xc043f8ac, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf7beffdc 0xc01148ec interruptible_sleep_on+0x3c > kernel .text 0xc0100000 0xc01148b0 0xc0114910 > 0xc013892c bdflush+0x9c > kernel .text 0xc0100000 0xc0138890 0xc0138930 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 6 > EBP EIP Function(args) > 0xf7bedf9c 0xc01145c2 schedule+0x322 (0xf7bedfa8, 0xc04a8024, 0xf622c0e4, 0x32c34, 0xf7bec000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf7bedfd0 0xc011426d schedule_timeout+0x7d (0x8e000, 0xf7bec000) > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc01389c3 kupdate+0x93 > kernel .text 0xc0100000 0xc0138930 0xc0138a30 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 7 > EBP EIP Function(args) > 0xf7be5f78 0xc01145c2 schedule+0x322 (0x0, 0xf7be4000, 0xc04458ec, 0xc04458ec, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf7be5f98 0xc01148ec interruptible_sleep_on+0x3c (0xf7be5fc0, 0xf7be5fc0, 0xf7be5fc0, 0x0, 0xc2814000) > kernel .text 0xc0100000 0xc01148b0 0xc0114910 > 0xc0225c7f pagebuf_daemon+0xdf > kernel .text 0xc0100000 0xc0225ba0 0xc0225de0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 8 > EBP EIP Function(args) > 0xf7bcdf6c 0xc01145c2 schedule+0x322 (0x1, 0xf7bcc000, 0xc0455a68, 0xc0455a68) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0105d4d __down_interruptible+0x5d > kernel .text 0xc0100000 0xc0105cf0 0xc0105db0 > 0xf7bcdfec 0xc0105dfb __down_failed_interruptible+0x7 (0xf7bcc000, 0xc04e2444, 0xc04e2440, 0xf7bcc000, 0xc2834000) > kernel .text 0xc0100000 0xc0105df4 0xc0105e00 > 0xc02cb7e1 _text_lock_i2o_core+0xff > kernel .text 0xc0100000 0xc02cb6e2 0xc02cb7f0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 9 > EBP EIP Function(args) > 0xf7bc5f90 0xc01145c2 schedule+0x322 (0x1, 0xf7bc4000, 0xc0455cf0, 0xc0455cf0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0105d4d __down_interruptible+0x5d > kernel .text 0xc0100000 0xc0105cf0 0xc0105db0 > 0xc0105dfb __down_failed_interruptible+0x7 (0xc02cd350, 0x0, 0xc2815fa0, 0xc04e7900, 0xc0455d1c) > kernel .text 0xc0100000 0xc0105df4 0xc0105e00 > 0xc02cebb0 _text_lock_i2o_block+0xf > kernel .text 0xc0100000 0xc02ceba1 0xc02cebc0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 13 > EBP EIP Function(args) > 0xf7a5bf70 0xc01145c2 schedule+0x322 (0x1, 0xf7a5a000, 0xf7a5bfd4, 0xf7a5bfd4) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0105d4d __down_interruptible+0x5d > kernel .text 0xc0100000 0xc0105cf0 0xc0105db0 > 0xc0105dfb __down_failed_interruptible+0x7 (0x0, 0x0, 0x0, 0xf7a5bfd4, 0xf7a5bfd4) > kernel .text 0xc0100000 0xc0105df4 0xc0105e00 > 0xc02986f9 _text_lock_scsi_error+0x55 > kernel .text 0xc0100000 0xc02986a4 0xc0298710 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 14 > EBP EIP Function(args) > 0xf7a59f70 0xc01145c2 schedule+0x322 (0x1, 0xf7a58000, 0xf7a59fd4, 0xf7a59fd4) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0105d4d __down_interruptible+0x5d > kernel .text 0xc0100000 0xc0105cf0 0xc0105db0 > 0xc0105dfb __down_failed_interruptible+0x7 (0x0, 0x0, 0x0, 0xf7a59fd4, 0xf7a59fd4) > kernel .text 0xc0100000 0xc0105df4 0xc0105e00 > 0xc02986f9 _text_lock_scsi_error+0x55 > kernel .text 0xc0100000 0xc02986a4 0xc0298710 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 15 > EBP EIP Function(args) > 0xf6537fa0 0xc01145c2 schedule+0x322 (0x0, 0xf6536000, 0xf7a2546c, 0xf7a2546c, 0xf6537fc8) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf6537fc0 0xc01148ec interruptible_sleep_on+0x3c (0x0, 0x0, 0x32aa0, 0xf6536000, 0xc0166020) > kernel .text 0xc0100000 0xc01148b0 0xc0114910 > 0xc016616a kjournald+0x12a > kernel .text 0xc0100000 0xc0166040 0xc01661e0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 106 > EBP EIP Function(args) > 0xf643ffa0 0xc01145c2 schedule+0x322 (0x0, 0xf643e000, 0xf7a2566c, 0xf7a2566c, 0xf643ffc8) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf643ffc0 0xc01148ec interruptible_sleep_on+0x3c (0x0, 0x0, 0x1476, 0xf643e000, 0xc0166020) > kernel .text 0xc0100000 0xc01148b0 0xc0114910 > 0xc016616a kjournald+0x12a > kernel .text 0xc0100000 0xc0166040 0xc01661e0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 458 > EBP EIP Function(args) > 0xf6239f6c 0xc01145c2 schedule+0x322 (0xf6239f78, 0xc04a7b64, 0xf62380e4, 0x1cd7f65, 0xf6238000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf6239fa0 0xc011426d schedule_timeout+0x7d (0x49d40, 0x0) > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xf6239fa8 0xc011e7c2 sys_nanosleep+0x122 (0xbffffac8, 0xbffffac8, 0xbffffac8, 0x10000, 0x0) > kernel .text 0xc0100000 0xc011e6a0 0xc011e840 > 0xc0106f4b system_call+0x33 > kernel .text 0xc0100000 0xc0106f18 0xc0106f50 > Enter to end, to continue: > Stack traceback for pid 522 > EBP EIP Function(args) > 0xf622bf00 0xc01145c2 schedule+0x322 (0xffffffff, 0x0, 0xf5e09500, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf622bf30 0xc0114207 schedule_timeout+0x17 > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc02d67bf sock_poll+0x1f > kernel .text 0xc0100000 0xc02d67a0 0xc02d67d0 > Enter to end, to continue: > Stack traceback for pid 527 > EBP EIP Function(args) > 0xf6223f4c 0xc01145c2 schedule+0x322 (0x0, 0xf6223f48, 0x0, 0xf6222000, 0xc043dc48) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0116ad1 do_syslog+0xd1 (0x2, 0x804df80, 0xfff, 0xf6377de0, 0x46) > kernel .text 0xc0100000 0xc0116a00 0xc0116d00 > 0xc01344f5 sys_read+0x95 (0x0, 0x804df80, 0xfff, 0x1, 0x8049400) > kernel .text 0xc0100000 0xc0134460 0xc0134560 > 0xc0106f4b system_call+0x33 > kernel .text 0xc0100000 0xc0106f18 0xc0106f50 > Enter to end, to continue: > Stack traceback for pid 547 > EBP EIP Function(args) > 0xf6159f18 0xc01145c2 schedule+0x322 (0xf6367008, 0x1, 0xc0142549, 0x0, 0x2) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf6159f48 0xc0114207 schedule_timeout+0x17 > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc0142649 do_pollfd+0x159 > kernel .text 0xc0100000 0xc01424f0 0xc0142670 > Enter to end, to continue: > Stack traceback for pid 575 > EBP EIP Function(args) > 0xf61e1f00 0xc01145c2 schedule+0x322 (0xf6471ac0, 0x0, 0xf636f2c0, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf61e1f30 0xc0114207 schedule_timeout+0x17 > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc02d67bf sock_poll+0x1f > kernel .text 0xc0100000 0xc02d67a0 0xc02d67d0 > Enter to end, to continue: > Stack traceback for pid 752 > EBP EIP Function(args) > 0xf622df24 0xc01145c2 schedule+0x322 (0x0, 0xf622c000, 0x0, 0x0, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf622df3c 0xc013c6db pipe_wait+0x7b (0xf61e97c0, 0xfffffff5, 0x0) > kernel .text 0xc0100000 0xc013c660 0xc013c710 > 0xc013c7c4 pipe_read+0xb4 (0xf63775c0, 0xbffffaf0, 0x110, 0xf63775e0, 0xc011e602) > kernel .text 0xc0100000 0xc013c710 0xc013c930 > 0xc01344f5 sys_read+0x95 (0x4, 0xbffffaf0, 0x110, 0xbffffaf0, 0x4) > kernel .text 0xc0100000 0xc0134460 0xc0134560 > 0xc0106f4b system_call+0x33 > kernel .text 0xc0100000 0xc0106f18 0xc0106f50 > Enter to end, to continue: > Stack traceback for pid 754 > EBP EIP Function(args) > 0xf616df24 0xc01145c2 schedule+0x322 (0x0, 0xf616c000, 0x0, 0x0, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf616df3c 0xc013c6db pipe_wait+0x7b (0xf61e9bc0, 0xfffffff5, 0x0) > kernel .text 0xc0100000 0xc013c660 0xc013c710 > 0xc013c7c4 pipe_read+0xb4 (0xf6533f40, 0xbffffaf0, 0x110, 0xf6533f60, 0xc011e602) > kernel .text 0xc0100000 0xc013c710 0xc013c930 > 0xc01344f5 sys_read+0x95 (0x4, 0xbffffaf0, 0x110, 0xbffffaf0, 0x4) > kernel .text 0xc0100000 0xc0134460 0xc0134560 > 0xc0106f4b system_call+0x33 > kernel .text 0xc0100000 0xc0106f18 0xc0106f50 > Enter to end, to continue: > Stack traceback for pid 782 > EBP EIP Function(args) > 0xf61b9f00 0xc01145c2 schedule+0x322 (0xc012637c, 0x0, 0xf62275c0, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf61b9f30 0xc0114207 schedule_timeout+0x17 > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc02d67bf sock_poll+0x1f > kernel .text 0xc0100000 0xc02d67a0 0xc02d67d0 > Enter to end, to continue: > Stack traceback for pid 816 > EBP EIP Function(args) > 0xf624bf00 0xc01145c2 schedule+0x322 (0xf652aa40, 0x0, 0xf648d140, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf624bf30 0xc0114207 schedule_timeout+0x17 > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc02d67bf sock_poll+0x1f > kernel .text 0xc0100000 0xc02d67a0 0xc02d67d0 > Enter to end, to continue: > Stack traceback for pid 844 > EBP EIP Function(args) > 0xf60f9f18 0xc01145c2 schedule+0x322 (0xee5c5008, 0x1, 0xc0142549, 0x0, 0x2) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf60f9f48 0xc0114207 schedule_timeout+0x17 > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc0142649 do_pollfd+0x159 > kernel .text 0xc0100000 0xc01424f0 0xc0142670 > Enter to end, to continue: > Stack traceback for pid 849 > EBP EIP Function(args) > 0xf60eff18 0xc01145c2 schedule+0x322 (0xee5b7008, 0x1, 0xc0142549, 0x0, 0x2) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf60eff48 0xc0114207 schedule_timeout+0x17 > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc0142649 do_pollfd+0x159 > kernel .text 0xc0100000 0xc01424f0 0xc0142670 > Enter to end, to continue: > Stack traceback for pid 854 > EBP EIP Function(args) > 0xf60e3ddc 0xc01145c2 schedule+0x322 (0x1, 0xf60e2000, 0xf60b9dec, 0xf60afdec) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0105ca4 __down+0x54 > kernel .text 0xc0100000 0xc0105c50 0xc0105cf0 > 0xc0105df0 __down_failed+0x8 (0xc0228b50, 0xee7c1c44, 0xf60e3e28, 0x0, 0xffffffff) > kernel .text 0xc0100000 0xc0105de8 0xc0105df4 > 0xc0228e93 _text_lock_xfs_file+0x5 (0xee4eb6c0, 0xf60e3eb8, 0xf5d33e40, 0xfffffffe, 0x266f9280) > kernel .text 0xc0100000 0xc0228e8e 0xc0228eb0 > 0xc0191043 nfsd_open+0x193 (0xf60e3eb8, 0xf43ec0e8, 0x2000, 0xf60e3ed8, 0x0) > kernel .text 0xc0100000 0xc0190eb0 0xc0191090 > 0xc0191515 nfsd_write+0x145 (0xf6230800, 0xf6230c04, 0xb30000, 0x0, 0xf43ec0e8) > kernel .text 0xc0100000 0xc01913d0 0xc0191690 > 0xc0196610 nfsd3_proc_write+0xe0 (0xf6230800, 0xf60e4014, 0x0, 0x27, 0x7) > kernel .text 0xc0100000 0xc0196530 0xc0196630 > 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf6230800, 0xf60e2570, 0xf6101240, 0xc04429c0) > kernel .text 0xc0100000 0xc031bf90 0xc031c470 > 0xc018d96b nfsd+0x1bb > kernel .text 0xc0100000 0xc018d7b0 0xc018daa0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 855 > EBP EIP Function(args) > 0xf60dff64 0xc01145c2 schedule+0x322 (0xf60dffa0, 0x0, 0xf60de000, 0xf652a800, 0xf60de000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf60dff94 0xc0114207 schedule_timeout+0x17 (0x0, 0xf60de000, 0x0, 0x0, 0x0) > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc031d6e6 svc_recv+0x1a6 (0xf6101300, 0xf6230e00, 0x7fffffff, 0xf6101300) > kernel .text 0xc0100000 0xc031d540 0xc031d920 > 0xc019bdbe lockd+0x12e > kernel .text 0xc0100000 0xc019bc90 0xc019bee0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 856 > EBP EIP Function(args) > 0xf60ddfc4 0xc01145c2 schedule+0x322 (0xc045941c, 0x0, 0xf60dc000, 0xc0459414, 0xc0459414) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc031a8e2 rpciod+0x172 > kernel .text 0xc0100000 0xc031a770 0xc031a990 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 857 > EBP EIP Function(args) > 0xf60d7d3c 0xc01145c2 schedule+0x322 (0x0, 0xf60d6000, 0x0, 0x0, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc01325c2 kmap_high+0x92 (0x1f, 0x1000, 0xf7c2427c, 0xc2143b80, 0xee616534) > kernel .text 0xc0100000 0xc0132530 0xc0132680 > 0xc0127b77 file_read_actor+0x57 (0xee7c13c0, 0xf60d7e64, 0x0, 0x0, 0x0) > kernel .text 0xc0100000 0xc0127b20 0xc0127c00 > 0xc02287fc linvfs_read+0x7c (0xf60d7eb4, 0xf60d8080, 0x2000, 0xf60d7ed4, 0x0) > kernel .text 0xc0100000 0xc0228780 0xc0228830 > 0xc019133c nfsd_read+0x1cc (0xf60e0000, 0xf60e0404, 0x2fde000, 0x0, 0xf60d8080) > kernel .text 0xc0100000 0xc0191170 0xc01913d0 > 0xc01964cc nfsd3_proc_read+0xfc (0xf60e0000, 0xf60d8014, 0x0, 0x27, 0x6) > kernel .text 0xc0100000 0xc01963d0 0xc0196530 > 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60e0000, 0xf60d6570, 0xf6101240, 0xf60d5fd0) > kernel .text 0xc0100000 0xc031bf90 0xc031c470 > 0xc018d96b nfsd+0x1bb > kernel .text 0xc0100000 0xc018d7b0 0xc018daa0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 858 > EBP EIP Function(args) > 0xf60d5ddc 0xc01145c2 schedule+0x322 (0x1, 0xf60d4000, 0xf60afdec, 0xf60c3dec) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0105ca4 __down+0x54 > kernel .text 0xc0100000 0xc0105c50 0xc0105cf0 > 0xc0105df0 __down_failed+0x8 (0xc0228b50, 0xee7c1c44, 0xf60d5e28, 0x0, 0xffffffff) > kernel .text 0xc0100000 0xc0105de8 0xc0105df4 > 0xc0228e93 _text_lock_xfs_file+0x5 (0xee4eb6c0, 0xf60d5eb8, 0xf5d33e40, 0xfffffffe, 0x266f9280) > kernel .text 0xc0100000 0xc0228e8e 0xc0228eb0 > 0xc0191043 nfsd_open+0x193 (0xf60d5eb8, 0xf41740e8, 0x2000, 0xf60d5ed8, 0x0) > kernel .text 0xc0100000 0xc0190eb0 0xc0191090 > 0xc0191515 nfsd_write+0x145 (0xf60e0600, 0xf60e0a04, 0xb20000, 0x0, 0xf41740e8) > kernel .text 0xc0100000 0xc01913d0 0xc0191690 > 0xc0196610 nfsd3_proc_write+0xe0 (0xf60e0600, 0xf60d0014, 0x0, 0x27, 0x7) > kernel .text 0xc0100000 0xc0196530 0xc0196630 > 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60e0600, 0xf60d4570, 0xf6101240, 0xf60e3fd0) > kernel .text 0xc0100000 0xc031bf90 0xc031c470 > 0xc018d96b nfsd+0x1bb > kernel .text 0xc0100000 0xc018d7b0 0xc018daa0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 859 > EBP EIP Function(args) > 0xf60cdbb8 0xc01145c2 schedule+0x322 (0x0, 0xf60cc000, 0x0, 0x0, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc01325c2 kmap_high+0x92 (0xc0136671, 0x0, 0x0, 0xb10, 0x0) > kernel .text 0xc0100000 0xc0132530 0xc0132680 > 0xc022721b __pb_block_prepare_write_async+0x7b (0xee4eb6c0, 0xc27e3740, 0x0, 0x1000, 0x1) > kernel .text 0xc0100000 0xc02271a0 0xc0227430 > 0xc022657e pagebuf_iozero+0x10e (0xee4eb6c0, 0xee2998c0, 0x0, 0x1000, 0xb12000) > kernel .text 0xc0100000 0xc0226470 0xc02266b0 > 0xc022c501 xfs_zero_eof+0x391 (0xee4eb7e4, 0xee7c1d3c, 0xb10000, 0x0, 0xb0a000) > kernel .text 0xc0100000 0xc022c170 0xc022c590 > 0xc022c790 xfs_write+0x200 (0xee7c1c44, 0xf60cde30, 0x8001, 0x0, 0x0) > kernel .text 0xc0100000 0xc022c590 0xc022ca10 > 0xc0228ae6 linvfs_write+0x2b6 (0xf60cdeb8, 0xf42640e8, 0x2000, 0xf60cded8, 0x0) > kernel .text 0xc0100000 0xc0228830 0xc0228b30 > 0xc0191515 nfsd_write+0x145 (0x0, 0x0, 0xf5d33e40, 0xc281f5c0, 0xc0445a80) > kernel .text 0xc0100000 0xc01913d0 0xc0191690 > 0xf60cded8 0xc02d63bb sock_sendmsg+0x6b (0xf60e0c00, 0xf60c8014, 0x0, 0x27, 0x7) > kernel .text 0xc0100000 0xc02d6350 0xc02d63e0 > 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60e0c00, 0xf60cc570, 0xf6101240, 0xf60d7fd0) > kernel .text 0xc0100000 0xc031bf90 0xc031c470 > 0xc018d96b nfsd+0x1bb > kernel .text 0xc0100000 0xc018d7b0 0xc018daa0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 860 > EBP EIP Function(args) > 0xf60c3ddc 0xc01145c2 schedule+0x322 (0x1, 0xf60c2000, 0xf60d5dec, 0xf60c1dec) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0105ca4 __down+0x54 > kernel .text 0xc0100000 0xc0105c50 0xc0105cf0 > 0xc0105df0 __down_failed+0x8 (0xc0228b50, 0xee7c1c44, 0xf60c3e28, 0x0, 0xffffffff) > kernel .text 0xc0100000 0xc0105de8 0xc0105df4 > 0xc0228e93 _text_lock_xfs_file+0x5 (0xee4eb6c0, 0xf60c3eb8, 0xf5d33e40, 0xfffffffe, 0x266f9280) > kernel .text 0xc0100000 0xc0228e8e 0xc0228eb0 > 0xc0191043 nfsd_open+0x193 (0xf60c3eb8, 0xf40100e8, 0x2000, 0xf60c3ed8, 0x0) > kernel .text 0xc0100000 0xc0190eb0 0xc0191090 > 0xc0191515 nfsd_write+0x145 (0xf60cf200, 0xf60cf604, 0xb18000, 0x0, 0xf40100e8) > kernel .text 0xc0100000 0xc01913d0 0xc0191690 > 0xc0196610 nfsd3_proc_write+0xe0 (0xf60cf200, 0xf60c4014, 0x0, 0x27, 0x7) > kernel .text 0xc0100000 0xc0196530 0xc0196630 > 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60cf200, 0xf60c2570, 0xf6101240, 0xf60cdfd0) > kernel .text 0xc0100000 0xc031bf90 0xc031c470 > 0xc018d96b nfsd+0x1bb > kernel .text 0xc0100000 0xc018d7b0 0xc018daa0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 861 > EBP EIP Function(args) > 0xf60c1ddc 0xc01145c2 schedule+0x322 (0x1, 0xf60c0000, 0xf60c3dec, 0xee4eb738) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0105ca4 __down+0x54 > kernel .text 0xc0100000 0xc0105c50 0xc0105cf0 > 0xc0105df0 __down_failed+0x8 (0xc0228b50, 0xee7c1c44, 0xf60c1e28, 0x0, 0xffffffff) > kernel .text 0xc0100000 0xc0105de8 0xc0105df4 > 0xc0228e93 _text_lock_xfs_file+0x5 (0xee4eb6c0, 0xf60c1eb8, 0xf5d33e40, 0xb0a000, 0x266f9280) > kernel .text 0xc0100000 0xc0228e8e 0xc0228eb0 > 0xc0191043 nfsd_open+0x193 (0xf60c1eb8, 0xf40880e8, 0x2000, 0xf60c1ed8, 0x0) > kernel .text 0xc0100000 0xc0190eb0 0xc0191090 > 0xc0191515 nfsd_write+0x145 (0xf60cf800, 0xf60cfc04, 0xb0a000, 0x0, 0xf40880e8) > kernel .text 0xc0100000 0xc01913d0 0xc0191690 > 0xc0196610 nfsd3_proc_write+0xe0 (0xf60cf800, 0xf60bc014, 0x0, 0x27, 0x7) > kernel .text 0xc0100000 0xc0196530 0xc0196630 > 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60cf800, 0xf60c0570, 0xf6101240, 0xf60c3fd0) > kernel .text 0xc0100000 0xc031bf90 0xc031c470 > 0xc018d96b nfsd+0x1bb > kernel .text 0xc0100000 0xc018d7b0 0xc018daa0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 862 > EBP EIP Function(args) > 0xf60b9ddc 0xc01145c2 schedule+0x322 (0x1, 0xf60b8000, 0xee4eb738, 0xf60e3dec) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0105ca4 __down+0x54 > kernel .text 0xc0100000 0xc0105c50 0xc0105cf0 > 0xc0105df0 __down_failed+0x8 (0xc0228b50, 0xee7c1c44, 0xf60b9e28, 0x0, 0xffffffff) > kernel .text 0xc0100000 0xc0105de8 0xc0105df4 > 0xc0228e93 _text_lock_xfs_file+0x5 (0xee4eb6c0, 0xf60b9eb8, 0xf5d33e40, 0xfffffffe, 0x266f9280) > kernel .text 0xc0100000 0xc0228e8e 0xc0228eb0 > 0xc0191043 nfsd_open+0x193 (0xf60b9eb8, 0xf3ce40e8, 0x2000, 0xf60b9ed8, 0x0) > kernel .text 0xc0100000 0xc0190eb0 0xc0191090 > 0xc0191515 nfsd_write+0x145 (0xf60cfe00, 0xf60bb204, 0xb38000, 0x0, 0xf3ce40e8) > kernel .text 0xc0100000 0xc01913d0 0xc0191690 > 0xc0196610 nfsd3_proc_write+0xe0 (0xf60cfe00, 0xf60b4014, 0x0, 0x27, 0x7) > kernel .text 0xc0100000 0xc0196530 0xc0196630 > 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60cfe00, 0xf60b8570, 0xf6101240, 0xf60c1fd0) > kernel .text 0xc0100000 0xc031bf90 0xc031c470 > 0xc018d96b nfsd+0x1bb > kernel .text 0xc0100000 0xc018d7b0 0xc018daa0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 863 > EBP EIP Function(args) > 0xf60afddc 0xc01145c2 schedule+0x322 (0x1, 0xf60ae000, 0xf60e3dec, 0xf60d5dec) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0105ca4 __down+0x54 > kernel .text 0xc0100000 0xc0105c50 0xc0105cf0 > 0xc0105df0 __down_failed+0x8 (0xc0228b50, 0xee7c1c44, 0xf60afe28, 0x0, 0xffffffff) > kernel .text 0xc0100000 0xc0105de8 0xc0105df4 > 0xc0228e93 _text_lock_xfs_file+0x5 (0xee4eb6c0, 0xf60afeb8, 0xf5d33e40, 0xfffffffe, 0x266f9280) > kernel .text 0xc0100000 0xc0228e8e 0xc0228eb0 > 0xc0191043 nfsd_open+0x193 (0xf60afeb8, 0xf4b340e8, 0x2000, 0xf60afed8, 0x0) > kernel .text 0xc0100000 0xc0190eb0 0xc0191090 > 0xc0191515 nfsd_write+0x145 (0xf60bb400, 0xf60bb804, 0xb28000, 0x0, 0xf4b340e8) > kernel .text 0xc0100000 0xc01913d0 0xc0191690 > 0xc0196610 nfsd3_proc_write+0xe0 (0xf60bb400, 0xf60b0014, 0x0, 0x27, 0x7) > kernel .text 0xc0100000 0xc0196530 0xc0196630 > 0xc031c2b9 svc_process+0x329 (0xf6101240, 0xf60bb400, 0xf60ae570, 0xf6101240, 0xf60b9fd0) > kernel .text 0xc0100000 0xc031bf90 0xc031c470 > 0xc018d96b nfsd+0x1bb > kernel .text 0xc0100000 0xc018d7b0 0xc018daa0 > 0xc0105746 kernel_thread+0x26 > kernel .text 0xc0100000 0xc0105720 0xc0105750 > Enter to end, to continue: > Stack traceback for pid 948 > EBP EIP Function(args) > 0xf609defc 0xc01145c2 schedule+0x322 (0xf609df08, 0xc04a8064, 0xc04a8064, 0x334b7, 0xf609c000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf609df30 0xc011426d schedule_timeout+0x7d > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc02d67bf sock_poll+0x1f > kernel .text 0xc0100000 0xc02d67a0 0xc02d67d0 > Enter to end, to continue: > Stack traceback for pid 952 > EBP EIP Function(args) > 0xf5f35efc 0xc01145c2 schedule+0x322 (0xf5f35f08, 0xc04a7ee4, 0xc04574a4, 0x34457, 0xf5f34000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf5f35f30 0xc011426d schedule_timeout+0x7d > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc02d67bf sock_poll+0x1f > kernel .text 0xc0100000 0xc02d67a0 0xc02d67d0 > Enter to end, to continue: > Stack traceback for pid 953 > EBP EIP Function(args) > 0xf5f2fefc 0xc01145c2 schedule+0x322 (0xf5f2ff08, 0xc04a7d34, 0xc04a7d34, 0x4abc6, 0xf5f2e000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf5f2ff30 0xc011426d schedule_timeout+0x7d > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc02d67bf sock_poll+0x1f > kernel .text 0xc0100000 0xc02d67a0 0xc02d67d0 > Enter to end, to continue: > Stack traceback for pid 954 > EBP EIP Function(args) > 0xf5f29efc 0xc01145c2 schedule+0x322 (0xf5f29f08, 0xc04a80b4, 0xc04a80b4, 0x33ede, 0xf5f28000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf5f29f30 0xc011426d schedule_timeout+0x7d > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc02d67bf sock_poll+0x1f > kernel .text 0xc0100000 0xc02d67a0 0xc02d67d0 > Enter to end, to continue: > Stack traceback for pid 969 > EBP EIP Function(args) > 0xf5ebbefc 0xc01145c2 schedule+0x322 (0xf5ebbf08, 0xc04a7ac4, 0xc04a7ac4, 0x83edb7, 0xf5eba000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf5ebbf30 0xc011426d schedule_timeout+0x7d > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc02d67bf sock_poll+0x1f > kernel .text 0xc0100000 0xc02d67a0 0xc02d67d0 > Enter to end, to continue: > Stack traceback for pid 987 > EBP EIP Function(args) > 0xf5eb1f6c 0xc01145c2 schedule+0x322 (0xf5eb1f78, 0xc04a8084, 0xc04a8084, 0x338a3, 0xf5eb0000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf5eb1fa0 0xc011426d schedule_timeout+0x7d (0x3c, 0x0) > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xf5eb1fa8 0xc011e7c2 sys_nanosleep+0x122 (0xbffffb38, 0xbffffb38, 0x401566b4, 0xbffffb38, 0x10000) > kernel .text 0xc0100000 0xc011e6a0 0xc011e840 > 0xc0106f4b system_call+0x33 > kernel .text 0xc0100000 0xc0106f18 0xc0106f50 > Enter to end, to continue: > Stack traceback for pid 1043 > EBP EIP Function(args) > 0xf5da9efc 0xc01145c2 schedule+0x322 (0xf5da9f08, 0xc04a7d1c, 0xc04a7d1c, 0x3c1a8, 0xf5da8000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf5da9f30 0xc011426d schedule_timeout+0x7d > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc02d67bf sock_poll+0x1f > kernel .text 0xc0100000 0xc02d67a0 0xc02d67d0 > Enter to end, to continue: > Stack traceback for pid 1079 > EBP EIP Function(args) > 0xf5d91f6c 0xc01145c2 schedule+0x322 (0xf5d91f78, 0xc04a7d54, 0xc04a7d54, 0x5968b, 0xf5d90000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf5d91fa0 0xc011426d schedule_timeout+0x7d (0xe10, 0x0) > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xf5d91fa8 0xc011e7c2 sys_nanosleep+0x122 (0xbffffac8, 0xbffffac8, 0x401566b4, 0xbffffac8, 0x10000) > kernel .text 0xc0100000 0xc011e6a0 0xc011e840 > 0xc0106f4b system_call+0x33 > kernel .text 0xc0100000 0xc0106f18 0xc0106f50 > Enter to end, to continue: > Stack traceback for pid 1094 > EBP EIP Function(args) > 0xf5d85efc 0xc01145c2 schedule+0x322 (0xf5d85f08, 0xc04a8134, 0xc04a8134, 0x32c0a, 0xf5d84000) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xf5d85f30 0xc011426d schedule_timeout+0x7d > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc02d67bf sock_poll+0x1f > kernel .text 0xc0100000 0xc02d67a0 0xc02d67d0 > Enter to end, to continue: > Stack traceback for pid 1100 > EBP EIP Function(args) > 0xf64fbf88 0xc01145c2 schedule+0x322 (0x0, 0xf64fa000, 0x0, 0x0, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0119de1 sys_wait4+0x371 (0xffffffff, 0x0, 0x0, 0x0, 0x14) > kernel .text 0xc0100000 0xc0119a70 0xc0119e10 > 0xc0106f4b system_call+0x33 > kernel .text 0xc0100000 0xc0106f18 0xc0106f50 > Enter to end, to continue: > Stack traceback for pid 1129 > EBP EIP Function(args) > 0xf5d39f88 0xc01145c2 schedule+0x322 (0x0, 0xf5d38000, 0x0, 0x0, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc0119de1 sys_wait4+0x371 (0xffffffff, 0xbffffc38, 0x2, 0x0, 0xffffffff) > kernel .text 0xc0100000 0xc0119a70 0xc0119e10 > 0xc0106f4b system_call+0x33 > kernel .text 0xc0100000 0xc0106f18 0xc0106f50 > Enter to end, to continue: > Stack traceback for pid 1250 > EBP EIP Function(args) > 0xee3dbf00 0xc01145c2 schedule+0x322 (0xee3da000, 0xee3dbf30, 0xf5e09380, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xee3dbf30 0xc0114207 schedule_timeout+0x17 > kernel .text 0xc0100000 0xc01141f0 0xc0114290 > 0xc02d67bf sock_poll+0x1f > kernel .text 0xc0100000 0xc02d67a0 0xc02d67d0 > Enter to end, to continue: > Stack traceback for pid 1369 > EBP EIP Function(args) > 0xf40b9d44 0xc01145c2 schedule+0x322 (0x0, 0xf40b8000, 0x0, 0x0, 0x0) > kernel .text 0xc0100000 0xc01142a0 0xc01145f0 > 0xc01325c2 kmap_high+0x92 (0x1f, 0x80, 0xf7d28bec, 0xc2772480, 0xf5d26d34) > kernel .text 0xc0100000 0xc0132530 0xc0132680 > 0xc0127b77 file_read_actor+0x57 (0xee7d0d40, 0xf40b9e54, 0x80, 0xf40b9e20, 0x0) > kernel .text 0xc0100000 0xc0127b20 0xc0127c00 > 0xc013ba4a kernel_read+0x4a (0xee7d0d40, 0x0, 0xf40b9e54, 0x80) > kernel .text 0xc0100000 0xc013ba00 0xc013ba60 > 0xc013bf16 prepare_binprm+0x116 (0xf40b9e54, 0x0, 0x0, 0x0, 0x0) > kernel .text 0xc0100000 0xc013be00 0xc013bf20 > 0xc013c40c do_execve+0x10c (0xf3b12000, 0x80f8d8c, 0x80d360c, 0xf40b9fc4) > kernel .text 0xc0100000 0xc013c300 0xc013c4e0 > 0xc0105b8d sys_execve+0x2d (0x80f8e0c, 0x80f8d8c, 0x80d360c, 0x80f8e0c, 0x80f8e0c) > kernel .text 0xc0100000 0xc0105b60 0xc0105bc0 > 0xc0106f4b system_call+0x33 > kernel .text 0xc0100000 0xc0106f18 0xc0106f50 > Enter to end, to continue: > kdb> > kdb> > (Back at mathcons) > ---------------------------------------------------- > C-Kermit 7.0.196, 1 Jan 2000, for Linux > Copyright (C) 1985, 2000, > Trustees of Columbia University in the City of New York. > Type ? or HELP for help. > (/root/) C-Kermit>quit > Closing /dev/ttyN000...OK > ]0;root@mathcons: /root[root@mathcons /root]# exit > Script done on Mon Mar 11 15:23:12 2002 -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Mar 11 14:45:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BMjCr14993 for linux-xfs-outgoing; Mon, 11 Mar 2002 14:45:12 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BMj3914971 for ; Mon, 11 Mar 2002 14:45:03 -0800 Received: (qmail 16754 invoked by uid 500); 11 Mar 2002 21:44:23 -0000 Subject: Re: cloning computers with xfs From: Austin Gonyou To: Jonathan Dill Cc: Vance Lankhaar , Francis Yom , linux-xfs@oss.sgi.com, Shawn Starr In-Reply-To: <3C8D2272.90078233@umbi.umd.edu> References: <3C8D2272.90078233@umbi.umd.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 11 Mar 2002 15:44:23 -0600 Message-Id: <1015883063.16520.8.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk FYI. System Imager is Rsync with scripts to aid storage and retreival. On Mon, 2002-03-11 at 15:32, Jonathan Dill wrote: > I'm using rsync or xfsdump to clone systems with a few different > methods. > > BTW you can sort of emulate xfscopy by piping xfsdump to xfsrestore. > > You can find info on rsync at rsync.samba.org or poke around on > freshmeat.net. > > 1. rsync over the network > > I partition the system with 2 root partitions, one that holds the > running OS, and I use rsync to copy a root filesystem to the second root > partition. Finally, you edit fstab on the cloned system, and add an > entry in lilo.conf to boot the new OS. > > This setup has a couple fringe benefits: a) you can install a beta > version of the OS on one partition and revert to the stable version if > you have problems; b) between upgrades, you can mirror the root > filesystem so eg. if your box gets hacked or the root fs gets trashed, > you can boot into the other "clean" copy. > > 2. rsync from disk to disk > > This method is done most easily if you have removable hard drive > cartridge and bracket. I get ATA-100 cartridge/bracket for $22. You > could also use external SCSI or even hot swap SCSI bay. I keep the > "master" copy on my workstation which has a removable drive bay, so I > just shut down and install the cartridge with the disk that I want to > clone to. > > 3. xfsdump over the network > > I do an xfsdump of the root that I want to clone to a file and compress > with gzip or bzip2 and make this "image" accessible via NFS. I use a > set up with 2 root partitions like #1 because you don't want to write > over the running OS. Then I just use xfsrestore to extract the root > onto the 2nd root partition. > > 4. xfsdump from disk to disk > > Similar to #2, but use xfsrestore to extract onto the disk in the > removable cartridge. > > -- > "Jonathan F. Dill" (dill@umbi.umd.edu) > UMBI CARB IT Coordinator > Experimental Support Site http://concept.umbi.umd.edu -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Mar 11 15:06:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BN65M15798 for linux-xfs-outgoing; Mon, 11 Mar 2002 15:06:05 -0800 Received: from virgil.dyndns.dk (foobar@0xc3d7fcc0.boanxx2.adsl.tele.dk [195.215.252.192]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BN5r915776 for ; Mon, 11 Mar 2002 15:05:53 -0800 Received: by virgil.dyndns.dk (Postfix, from userid 1000) id B532B136B78; Mon, 11 Mar 2002 23:05:50 +0100 (CET) To: linux-xfs@oss.sgi.com Subject: A / with XFS on RAID5 with an external log Organization: koldfront - analysis & revolution, Copenhagen, Denmark From: asjo@koldfront.dk (Adam =?iso-8859-1?q?Sj=F8gren?=) Date: Mon, 11 Mar 2002 23:05:50 +0100 Message-ID: <87sn76kbep.fsf@virgil.koldfront.dk> Lines: 67 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Common Lisp, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. This is my first post to the mailinglist, so I hope you'll bear with me. I've spent quite some time spent the last four days searching, reading, experimenting trying to find the solution to the following question: I'm experimenting on a box with three disks with having a root filesystem on XFS on RAID5. I'm having problems booting Linux if I have an external log (as recommended in the faq). I've tried with 2.4.18 with the 2.4.18-patch from the ftp-server and with 2.4.14 with the 1.0.2 patch as distributed by Debian. My setup is three identical disks that look like this: hda1 small /boot hda2 raid1 for the log (md1) hda3 swap/temporary ext2fs-root while experimenting hda4 raid5 for my xfs-/ (md0) Now, I 'mkfs.xfs -l logdev=/dev/md1 /dev/md0', and the fs is created. I can mount it with 'mount -o logdev=/dev/md1 /dev/md0 /mnt' and copy stuff to it. That's all fine. But when I configure lilo to use /dev/md0 as root and reboot, I can't make it work. I have different scenarios depending on what I try: *) Without initrd and no options: Linux boots and gets to the point where it tries to mount / - it then says that xfs needs a logdev-option to mount the partition, and the kernel panics. *) Without initrd and passing LILO linux rootflags=logdev=/dev/md1: Linux boots, EXT2fs complains that it doesn't know what to do with logdev, and I get a kernel oops (when XFS tries to mount?) *) Without initrd and passing LILO linux rootflags="logdev=/dev/md1" (wrong format for option): Linux boots, EXT2fs complains about "log, XFS complains about "log - the root fs isn't mounted, and the kernel panics. *) If I build the kernel with initrd and tell lilo to use it, XFS complains about the lacking logdev-option. I've searched and read and it seems to me that it should be extremely simple to make an initrd that mounts /dev/md0 as / with logdev=/dev/md1, but none of the stuff I've found has been "cookbook" enough to give me a clue about how. I'm using Debians kernel-package' make-kpkg (with/without --initrd) to build a kernel-image-package which I then install. If someone could point me in the right direction, I'd be very happy. I don't want to install a lot of stuff on an xfs-filesystem with an internal log (which I _can_ get Linux to mount when booting, it's not all misery :-)) when/if I can't (easily) change from internal to external later on... Best regards, Adam. -- "Well, I'm a moon around you" Adam Sjřgren asjo@koldfront.dk From owner-linux-xfs@oss.sgi.com Mon Mar 11 15:08:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BN8g515947 for linux-xfs-outgoing; Mon, 11 Mar 2002 15:08:42 -0800 Received: from mta4-rme.xtra.co.nz (210-86-15-132.ipnets.xtra.co.nz [210.86.15.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BN8d915925 for ; Mon, 11 Mar 2002 15:08:39 -0800 Received: from localhost.localdomain ([210.86.52.160]) by mta4-rme.xtra.co.nz with ESMTP id <20020311220831.RRMQ14382.mta4-rme.xtra.co.nz@localhost.localdomain>; Tue, 12 Mar 2002 11:08:31 +1300 Subject: Re: rmap vm and xfs From: mdew To: Shawn Starr Cc: Erik Tews , xfs In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 12 Mar 2002 11:08:10 +1300 Message-Id: <1015884512.811.2.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-12 at 08:19, Shawn Starr wrote: > > Compare -shawn9 vs shawn10 > > ac2 to ac4 grows by 100KB. Whens "shawn10" due? Pre-emptive patch merges in well (one sched.h failure which can be easily fixed)... you could always include that ;) -- ph33r! Linux mdew 2.4.19-pre2-ac2-xfs-rmap-preemptive #2 Mon Mar 11 15:47:59 NZDT 2002 i686 unknown From owner-linux-xfs@oss.sgi.com Mon Mar 11 15:14:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BNEam16147 for linux-xfs-outgoing; Mon, 11 Mar 2002 15:14:36 -0800 Received: from mathserv.math.ohio-state.edu (IDENT:root@mathserv.math.ohio-state.edu [128.146.111.31]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BNES916125 for ; Mon, 11 Mar 2002 15:14:28 -0800 Received: from math.ohio-state.edu (zaphod.math.ohio-state.edu [128.146.111.36]) by mathserv.math.ohio-state.edu (8.12.2/8.12.2) with ESMTP id g2BMERXa008621; Mon, 11 Mar 2002 17:14:27 -0500 Received: by math.ohio-state.edu (Postfix, from userid 500) id D04342D82DD; Mon, 11 Mar 2002 17:14:25 -0500 (EST) Date: Mon, 11 Mar 2002 17:14:25 -0500 From: Dave Alden To: Eric Sandeen Cc: Keith Owens , linux-xfs@oss.sgi.com Subject: Re: odd problem with XFS & NFS (locking up system) Message-ID: <20020311171425.A8938@math.ohio-state.edu> References: <20020311144914.A6662@math.ohio-state.edu> <523.1015876602@ocs3.intra.ocs.com.au> <20020311152455.A6907@math.ohio-state.edu> <1015882624.28288.18.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1015882624.28288.18.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Mon, Mar 11, 2002 at 03:37:04PM -0600 X-RAVMilter-Version: 8.3.2(snapshot 20020213) (mathserv) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, That seems to have fixed it. Thanks. :-) ...dave On Mon, Mar 11, 2002 at 03:37:04PM -0600, Eric Sandeen wrote: > Does this help? > > (Thank Steve if it does...) > > -Eric > > --- linux/fs/xfs/pagebuf/page_buf_io.c_1.15 Mon Mar 11 15:35:41 2002 > +++ linux/fs/xfs/pagebuf/page_buf_io.c Mon Mar 11 15:35:28 2002 > @@ -310,7 +310,8 @@ > __pb_block_prepare_write_async(ip, page, > cpoff, cpoff+csize, at_eof, NULL, > pbmapp, PBF_WRITE); > - memset((void *) (kmap(page) + cpoff), 0, csize); > + /* __pb_block_prepare_write already kmap'd the page */ > + memset((void *) (page_address(page) + cpoff), 0, csize); > pagebuf_commit_write_core(ip, page, cpoff, cpoff + csize); > pos = ((loff_t)page->index << PAGE_CACHE_SHIFT) + > cpoff + csize; > > From owner-linux-xfs@oss.sgi.com Mon Mar 11 15:20:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BNKle16423 for linux-xfs-outgoing; Mon, 11 Mar 2002 15:20:47 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BNKd916401 for ; Mon, 11 Mar 2002 15:20:40 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2BMKXbX006394 for ; Mon, 11 Mar 2002 14:20:34 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA11093 for ; Mon, 11 Mar 2002 16:20:33 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA33536 for ; Mon, 11 Mar 2002 16:20:33 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g2BMKXc20782; Mon, 11 Mar 2002 16:20:33 -0600 Message-Id: <200203112220.g2BMKXc20782@stout.americas.sgi.com> Date: Mon, 11 Mar 2002 16:20:33 -0600 From: Eric Sandeen Subject: TAKE - Fix lockup on highmem system Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The addition of __pb_block_prepare_write to pagebuf_iozero caused us to kmap a page twice... this will break on highmem systems. Change the second kmap() to page_address(). Date: Mon Mar 11 14:17:53 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113806a linux/fs/xfs/pagebuf/page_buf_io.c - 1.16 - Don't try to kmap() a page twice in a row... From owner-linux-xfs@oss.sgi.com Mon Mar 11 15:25:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BNPw016606 for linux-xfs-outgoing; Mon, 11 Mar 2002 15:25:58 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BNPj916582 for ; Mon, 11 Mar 2002 15:25:45 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2BMPdbX006652 for ; Mon, 11 Mar 2002 14:25:39 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA13307; Mon, 11 Mar 2002 16:25:38 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA20236; Mon, 11 Mar 2002 16:25:21 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2BMOVi25963; Mon, 11 Mar 2002 16:24:31 -0600 Subject: Re: A / with XFS on RAID5 with an external log From: Steve Lord To: Adam =?ISO-8859-1?Q?Sj=F8gren?= Cc: linux-xfs@oss.sgi.com In-Reply-To: <87sn76kbep.fsf@virgil.koldfront.dk> References: <87sn76kbep.fsf@virgil.koldfront.dk> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.2 Date: 11 Mar 2002 16:24:31 -0600 Message-Id: <1015885471.22693.62.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2BNPj916583 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-11 at 16:05, Adam Sjřgren wrote: > Hi. > > > This is my first post to the mailinglist, so I hope you'll bear with > me. I've spent quite some time spent the last four days searching, > reading, experimenting trying to find the solution to the following > question: > > > I'm experimenting on a box with three disks with having a root > filesystem on XFS on RAID5. I'm having problems booting Linux if I > have an external log (as recommended in the faq). I've tried with > 2.4.18 with the 2.4.18-patch from the ftp-server and with 2.4.14 with > the 1.0.2 patch as distributed by Debian. > > My setup is three identical disks that look like this: > > hda1 small /boot > hda2 raid1 for the log (md1) > hda3 swap/temporary ext2fs-root while experimenting > hda4 raid5 for my xfs-/ (md0) > > Now, I 'mkfs.xfs -l logdev=/dev/md1 /dev/md0', and the fs is > created. I can mount it with 'mount -o logdev=/dev/md1 /dev/md0 /mnt' > and copy stuff to it. That's all fine. > > But when I configure lilo to use /dev/md0 as root and reboot, I can't > make it work. I have different scenarios depending on what I try: > > *) Without initrd and no options: Linux boots and gets to the > point where it tries to mount / - it then says that xfs needs a > logdev-option to mount the partition, and the kernel panics. > > *) Without initrd and passing LILO linux rootflags=logdev=/dev/md1: > Linux boots, EXT2fs complains that it doesn't know what to do with > logdev, and I get a kernel oops (when XFS tries to mount?) > > *) Without initrd and passing LILO linux rootflags="logdev=/dev/md1" > (wrong format for option): Linux boots, EXT2fs complains about > "log, XFS complains about "log - the root fs isn't mounted, and > the kernel panics. > > *) If I build the kernel with initrd and tell lilo to use it, XFS > complains about the lacking logdev-option. I've searched and read > and it seems to me that it should be extremely simple to make an > initrd that mounts /dev/md0 as / with logdev=/dev/md1, but none of > the stuff I've found has been "cookbook" enough to give me a clue > about how. > > I'm using Debians kernel-package' make-kpkg (with/without --initrd) to > build a kernel-image-package which I then install. > > If someone could point me in the right direction, I'd be very happy. > > I don't want to install a lot of stuff on an xfs-filesystem with an > internal log (which I _can_ get Linux to mount when booting, it's not > all misery :-)) when/if I can't (easily) change from internal to > external later on... > > > Best regards, > > Adam. > Two things to mention. o first of all we are testing code which should help with the internal log performance of raid5 - but it is not ready now. o second maybe you need two boot options here: rootfstype=xfs and rootflags=logdev=/dev/md1 If I read the code correctly, this should make it only try and use xfs. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Mar 11 15:41:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2BNfHA17037 for linux-xfs-outgoing; Mon, 11 Mar 2002 15:41:17 -0800 Received: from virgil.dyndns.dk (foobar@0xc3d7fcc0.boanxx2.adsl.tele.dk [195.215.252.192]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2BNfB917015 for ; Mon, 11 Mar 2002 15:41:11 -0800 Received: by virgil.dyndns.dk (Postfix, from userid 1000) id CFD81136B78; Mon, 11 Mar 2002 23:41:09 +0100 (CET) To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: A / with XFS on RAID5 with an external log References: <87sn76kbep.fsf@virgil.koldfront.dk> <1015885471.22693.62.camel@jen.americas.sgi.com> Organization: koldfront - analysis & revolution, Copenhagen, Denmark From: asjo@koldfront.dk (Adam =?iso-8859-1?q?Sj=F8gren?=) Date: Mon, 11 Mar 2002 23:41:09 +0100 In-Reply-To: <1015885471.22693.62.camel@jen.americas.sgi.com> (Steve Lord's message of "11 Mar 2002 16:24:31 -0600") Message-ID: <874rjmk9ru.fsf@virgil.koldfront.dk> Lines: 42 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Common Lisp, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 11 Mar 2002 16:24:31 -0600, Steve Lord wrote: > o first of all we are testing code which should help with the > internal log performance of raid5 - but it is not ready now. Yeah, I read that. Cool. > o second maybe you need two boot options here: rootfstype=xfs and > rootflags=logdev=/dev/md1 I just tried that. It removed the complaint from EXT2fs, but I still get an oops (I just tried with the initrd-variant, let me know if you think it'll change anything to try with a non-initrd kernel): [...] RAMDISK: Loading 1468 blocks [1 disk] into ram disk... done. Freeing initrd memory: 1468k freed Unable to handle kernel NULL pointer dereference at virtual address 00000008 printing eip: c0139391 *pde = 00000000 Oops: 000 CPU: 0 EIP: 0010:[] Not tainted [...] (I got tired of typing there, if the rest is useful, let me know and I'll post it all). > If I read the code correctly, this should make it only try and use > xfs. Maybe I get the oops when it's actually trying to mount the xfs-system? Thanks! Adam. -- "Well, I'm a moon around you" Adam Sjřgren asjo@koldfront.dk From owner-linux-xfs@oss.sgi.com Mon Mar 11 16:44:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2C0iva18069 for linux-xfs-outgoing; Mon, 11 Mar 2002 16:44:57 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2C0io918047 for ; Mon, 11 Mar 2002 16:44:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2BNiibX009906 for ; Mon, 11 Mar 2002 15:44:45 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA37261; Tue, 12 Mar 2002 10:43:26 +1100 (EST) Date: Tue, 12 Mar 2002 10:43:26 +1100 (EST) From: Nathan Scott Message-Id: <200203112343.KAA37261@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: TAKE - attr/acl updates Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 11 15:42:35 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:113824a acl/VERSION - 1.21 acl/doc/CHANGES - 1.24 acl/man/Makefile - 1.4 acl/man/man1/setfacl.1 - 1.7 acl/man/man1/Makefile - 1.4 acl/man/man5/Makefile - 1.4 acl/man/man5/acl.5 - 1.10 acl/debian/changelog - 1.15 - man page and test script updates from Andreas. attr/VERSION - 1.16 attr/doc/CHANGES - 1.18 attr/man/Makefile - 1.4 attr/man/man1/Makefile - 1.3 attr/man/man2/Makefile - 1.4 attr/man/man3/attr_list.3 - 1.4 attr/man/man3/attr_set.3 - 1.4 attr/man/man3/attr_get.3 - 1.4 attr/man/man3/attr_multi.3 - 1.4 attr/man/man3/Makefile - 1.4 attr/man/man3/attr_remove.3 - 1.4 attr/debian/changelog - 1.17 attr/libattr/syscalls.c - 1.8 attr/test/attr.test - 1.3 attr/man/man5/attr.5 - 1.3 attr/man/man5/Makefile - 1.3 - man page and test script updates from Andreas. fix syscall numbering a/ on sparc (fremovexattr was wrong) and b/ if arch doesn't have numbers defined yet, handle it cleanly (errno.h missing). From owner-linux-xfs@oss.sgi.com Mon Mar 11 16:50:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2C0on218296 for linux-xfs-outgoing; Mon, 11 Mar 2002 16:50:49 -0800 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2C0oc918274 for ; Mon, 11 Mar 2002 16:50:38 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g2C0oVBA009658 for ; Mon, 11 Mar 2002 16:50:32 -0800 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 KAA06390; Tue, 12 Mar 2002 10:49:14 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA47253; Tue, 12 Mar 2002 10:49:09 +1100 (AEDT) Date: Tue, 12 Mar 2002 10:49:09 +1100 From: Nathan Scott To: GCS Cc: linux-xfs@oss.sgi.com Subject: Re: Quota patches Message-ID: <20020312104908.P24252@wobbly.melbourne.sgi.com> References: <20020308105148.A18371@lsc.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020308105148.A18371@lsc.hu>; from gcs@lsc.hu on Fri, Mar 08, 2002 at 10:51:48AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Mar 08, 2002 at 10:51:48AM +0100, GCS wrote: > Hi! > > The newest XFS has a new quota related patch for 32 bit uid/gids. Is it > available as a separate patch? > > Thanks, GCS > hello, You can find these patches on Jan Kara's ftp site, as described in the message Jan sent to LKML below. The patches listed below are not yet in CVS... (small differences)... I'll be merging the latest changes in later today, and then CVS will contain exactly these patches. cheers. -- Nathan On Mon, Mar 11, 2002 at 04:50:08PM +0100, Jan Kara wrote: > Hi, > > So I've created first "publishable" version of quota patches supporting > both quota formats in kernel (so in future the patches can be backported > in 2.4 and included...). Now quota formats are plugins - the idea is similar > to the way how filesystem plugins work. > The changes are split into 13 parts (should I create one empty patch? ;-)): > quota-1-newlocks - this patch changes counting of references on dquot structures > so filesystem can be sure we never call it during DQUOT_ALLOC/DQUOT_FREE/.. > calls. > quota-2-formats - this patch removes most format dependent code from dquot.c > and quota.h and puts calls of callback functions instead > quota-3-register - this patch implements registering/unregistering of quota > formats > quota-4-getstats - this patch removes Q_GETSTATS call and creates /proc/fs/quota > entry instead > quota-5-bytes - implements accounting of used space in bytes on quota side > quota-6-bytes - implements accounting of used space in bytes on VFS side - > - neccessary functions are added to fs.h > quota-7-quotactl - implementation of generic quotactl interface (probably the > biggest patch). Interface is moved from dquot.c to quota.c file. Pointers > to quota operations in superblock are now not filled on quota_on() but > on mount so filesystem can override them (for example ext3 would like to > check on quota_on() that quotafile lies on proper device and turn on > data-journaling on it - at least when we'll have journaled quota :)). > quota-8-format1 - implementation of old quota format (mainly moved stuff from > dquot.c + some interface functions) > quota-9-format2 - implementation of new quota format (mainly just copied from > patches used in -ac kernels) > quota-10-inttype - replace silly usage of 'short' by 'int' > quota-11-sync - implements correct syncing of quota - also quota info stored > in superblock is stored (here 2.4.18 and 2.5.6 patches significantly differ > - in 2.5.6 it's a bit simplier to do it) > quota-12-compat - implements backward compatible quotactl() interface. It's > configurable whether it should be used at all and whether is should behave > as interface in Linus's (the oldest interface) or Alan's (old interface for > new quota format) kernel. > quota-13-ioctl - implements ioctl for getting file size in bytes. I placed > this patch as the last one because I consider it ugly to create ioctl() for > such thing (changing stat() would be cleaner but this change isn't probably > important enough for it to be worth yet another stat() change). So if it > is decided the patch won't be included there won't be problems... > > The patches seem to work reasonably for me so I think it's time for > wider testing... I haven't tested the patches for archs != i386 > so if someone has sparc, ia32 or s390 at hand can you please give patches a try? > The patches for 2.4.18 and 2.5.6 are at: > ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/ > v2.4/alpha/ > v2.5/alpha/ > > There are also quota utilities capable of communicating with new generic > interface (otherwise you can use old utils and compile compatible quotactl() > interface). You can download them at: > > ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/utils/alpha/quota-3.05-pre1.tar.gz > > Any comments & bugreports welcome. > > Honza > > -- > Jan Kara > SuSE CR Labs From owner-linux-xfs@oss.sgi.com Mon Mar 11 17:07:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2C17BK18745 for linux-xfs-outgoing; Mon, 11 Mar 2002 17:07:11 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2C175918723 for ; Mon, 11 Mar 2002 17:07:05 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g2C1Ebkw028790 for ; Mon, 11 Mar 2002 19:14:38 -0600 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 LAA06489; Tue, 12 Mar 2002 11:05:41 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA47315; Tue, 12 Mar 2002 11:05:40 +1100 (AEDT) Date: Tue, 12 Mar 2002 11:05:40 +1100 From: Nathan Scott To: Vincent Bernat Cc: linux-xfs@oss.sgi.com Subject: Re: Intermezzo and XFS Message-ID: <20020312110540.Q24252@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bernat@free.fr on Fri, Mar 08, 2002 at 04:20:40PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Fri, Mar 08, 2002 at 04:20:40PM +0100, Vincent Bernat wrote: > Hello, > > I remember that Intermezzo was incompatible with XFS. However, since > Intermezzo is in the mainstream kernel since 2.4.15, is it now > compatible with XFS ? Or will it be soon ? > Aside from the issues others have discussed, Intermezzo needs updating for the new EA/ACL interfaces in several places ... this code will no longer work for either the ext2/ext3 EA/ACL patches or XFS. I'm sure the Intermezzo folks have this on their ToDo list already though (now that there are "official" interfaces for these things). fs/intermezzo$ egrep -li 'posix_acl|ext_attr' *c dir.c ext_attr.c file.c journal.c methods.c psdev.c vfs.c -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 11 17:28:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2C1SKr19324 for linux-xfs-outgoing; Mon, 11 Mar 2002 17:28:20 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2C1SE919301 for ; Mon, 11 Mar 2002 17:28:15 -0800 Received: (qmail 2221 invoked from network); 12 Mar 2002 00:29:42 -0000 Received: from cpedeadbeef0000.cpe.net.cable.rogers.com (HELO sh0n.net) (sh0n@24.100.234.67) by cpedeadbeef0000.cpe.net.cable.rogers.com with SMTP; 12 Mar 2002 00:29:42 -0000 Date: Mon, 11 Mar 2002 19:29:40 -0500 (EST) From: Shawn Starr To: mdew cc: Erik Tews , xfs Subject: Re: rmap vm and xfs In-Reply-To: <1015884512.811.2.camel@mdew> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk you can get it now :-) On 12 Mar 2002, mdew wrote: > On Tue, 2002-03-12 at 08:19, Shawn Starr wrote: > > > > Compare -shawn9 vs shawn10 > > > > ac2 to ac4 grows by 100KB. > > Whens "shawn10" due? > > Pre-emptive patch merges in well (one sched.h failure which can be > easily fixed)... you could always include that ;) > > > > -- > ph33r! > Linux mdew 2.4.19-pre2-ac2-xfs-rmap-preemptive #2 Mon Mar 11 15:47:59 > NZDT 2002 i686 unknown > > > > From owner-linux-xfs@oss.sgi.com Mon Mar 11 19:38:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2C3cnL22228 for linux-xfs-outgoing; Mon, 11 Mar 2002 19:38:49 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2C3cj922206 for ; Mon, 11 Mar 2002 19:38:45 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2C3kIkw029284 for ; Mon, 11 Mar 2002 21:46:19 -0600 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA51223 for linux-xfs@oss.sgi.com; Tue, 12 Mar 2002 13:37:20 +1100 (EST) Date: Tue, 12 Mar 2002 13:37:20 +1100 (EST) From: Nathan Scott Message-Id: <200203120237.NAA51223@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - sync user/kernel code (minor) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 11 18:35:54 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:113833a cmd/xfsprogs/VERSION - 1.42 cmd/xfsprogs/doc/CHANGES - 1.57 cmd/xfsprogs/include/xfs_ag.h - 1.6 cmd/xfsprogs/include/platform_defs.h.in - 1.7 cmd/xfsprogs/debian/changelog - 1.40 cmd/xfsprogs/libxfs/rdwr.c - 1.5 cmd/xfsprogs/libxfs/xfs.h - 1.14 cmd/xfsprogs/libxfs/xfs_alloc.c - 1.7 - bump minor version to pick up Erics BLKGETSIZE change from awhile ago and sync userspace and kernel code up (minor changes only, doesn't affect user tools at all). From owner-linux-xfs@oss.sgi.com Mon Mar 11 20:30:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2C4U6k25205 for linux-xfs-outgoing; Mon, 11 Mar 2002 20:30:06 -0800 Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2C4Tr925169 for ; Mon, 11 Mar 2002 20:29:58 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 46994C001C6 for ; Tue, 12 Mar 2002 11:29:49 +0800 (PHT) Received: from mail.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id E0362C001C1 for ; Tue, 12 Mar 2002 11:29:41 +0800 (PHT) Date: Tue, 12 Mar 2002 11:29:41 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Debian "Woody" XFS Net Install CD Image Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fellow XFS users, Got this from DebianPlanet: "Eduard Bloch, maintainer of the bf2.4 kernel-image, has done some magic and cooked up XFS install disks and some Net install ISOs.You can get them here." "The disks work wonderfully, XFS is available in the "initalize partition" menu, so no requirement to flip to the second console and fiddle with makefs.xfs." I hope we'll see XFS when Woody is released as the new Debian Stable! :) --> Jijo -- Federico Sevilla III :: jijo@leathercollection.ph Network Administrator :: The Leather Collection, Inc. GnuPG Key: http://jijo.leathercollection.ph/jijo.gpg From owner-linux-xfs@oss.sgi.com Mon Mar 11 21:52:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2C5qTk26472 for linux-xfs-outgoing; Mon, 11 Mar 2002 21:52:29 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2C5qO926450 for ; Mon, 11 Mar 2002 21:52:25 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2C5xwkw029609 for ; Mon, 11 Mar 2002 23:59:59 -0600 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA07882 for linux-xfs@oss.sgi.com; Tue, 12 Mar 2002 15:51:00 +1100 (EST) Date: Tue, 12 Mar 2002 15:51:00 +1100 (EST) From: Nathan Scott Message-Id: <200203120451.PAA07882@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - VFS quota update [2.4] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 11 20:49:56 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:113849a linux/include/linux/quotaops.h - 1.14 linux/include/linux/quota.h - 1.11 linux/include/asm-sparc64/ioctls.h - 1.5 linux/include/asm-sparc/ioctls.h - 1.5 linux/include/asm-m68k/ioctls.h - 1.5 linux/include/asm-i386/ioctls.h - 1.5 linux/include/asm-alpha/ioctls.h - 1.7 linux/fs/ioctl.c - 1.14 linux/fs/dquot.c - 1.47 linux/arch/sparc64/kernel/systbls.S - 1.22 linux/arch/sparc64/kernel/sys_sparc32.c - 1.43 linux/Documentation/Configure.help - 1.128 linux/include/asm-sh/ioctls.h - 1.6 linux/arch/ia64/ia32/sys_ia32.c - 1.21 linux/include/asm-ia64/ioctls.h - 1.4 linux/include/asm-parisc/ioctls.h - 1.4 linux/arch/s390x/kernel/linux32.c - 1.9 linux/include/asm-cris/ioctls.h - 1.4 linux/fs/quota.c - 1.8 - merge in latest quota patches from Jan Kara. minor changes only now. From owner-linux-xfs@oss.sgi.com Mon Mar 11 23:11:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2C7BuI29462 for linux-xfs-outgoing; Mon, 11 Mar 2002 23:11:56 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2C7Bj929432 for ; Mon, 11 Mar 2002 23:11:46 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2C6BabX019518 for ; Mon, 11 Mar 2002 22:11:37 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA27957 for linux-xfs@oss.sgi.com; Tue, 12 Mar 2002 17:10:18 +1100 (EST) Date: Tue, 12 Mar 2002 17:10:18 +1100 (EST) From: Nathan Scott Message-Id: <200203120610.RAA27957@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - VFS quota update [2.5] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 11 22:09:04 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs Author: nathans Merged by: nathans Merged mods: 2.4.x-xfs:slinx:113849a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:113849a linux/include/linux/quotaops.h - 1.16 linux/include/linux/quota.h - 1.12 linux/include/linux/fs.h - 1.159 linux/include/asm-sparc64/ioctls.h - 1.5 linux/include/asm-sparc/ioctls.h - 1.5 linux/include/asm-m68k/ioctls.h - 1.5 linux/include/asm-i386/ioctls.h - 1.5 linux/include/asm-alpha/ioctls.h - 1.7 linux/fs/ioctl.c - 1.15 linux/fs/dquot.c - 1.53 linux/fs/buffer.c - 1.115 linux/arch/sparc64/kernel/systbls.S - 1.24 linux/arch/sparc64/kernel/sys_sparc32.c - 1.47 linux/include/asm-sh/ioctls.h - 1.6 linux/arch/ia64/ia32/sys_ia32.c - 1.22 linux/include/asm-ia64/ioctls.h - 1.4 linux/include/asm-parisc/ioctls.h - 1.4 linux/arch/s390x/kernel/linux32.c - 1.11 linux/include/asm-cris/ioctls.h - 1.4 linux/fs/Config.help - 1.5 linux/fs/quota.c - 1.8 - Merge of 2.4.x-xfs:slinx:113849a by nathans. merge in latest quota patches from Jan Kara. minor changes only now. From owner-linux-xfs@oss.sgi.com Mon Mar 11 23:14:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2C7EYC29604 for linux-xfs-outgoing; Mon, 11 Mar 2002 23:14:34 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2C7ET929581 for ; Mon, 11 Mar 2002 23:14:29 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g2C6EKbX019555 for ; Mon, 11 Mar 2002 22:14:22 -0800 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 RAA08844; Tue, 12 Mar 2002 17:13:02 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA48582; Tue, 12 Mar 2002 17:13:01 +1100 (AEDT) Date: Tue, 12 Mar 2002 17:13:00 +1100 From: Nathan Scott To: Alvaro Figueroa Cc: XFS to linux port mailing list Subject: Re: Serveral weid errors on sys_sparc32.c Message-ID: <20020312171300.Y24252@wobbly.melbourne.sgi.com> References: <1015543584.5649.2.camel@lucy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1015543584.5649.2.camel@lucy>; from fede2@fuerzag.ulatina.ac.cr on Thu, Mar 07, 2002 at 05:26:24PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Alvaro, The latest quota patches are in CVS - could you try these out on your Sparc64 box and let me know if your build problem is fixed? thanks. On Thu, Mar 07, 2002 at 05:26:24PM -0600, Alvaro Figueroa wrote: > While compiling the CVS XFS kernel, I get > ... > -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 12 01:08:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2C98Fm31929 for linux-xfs-outgoing; Tue, 12 Mar 2002 01:08:15 -0800 Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2C98A931906 for ; Tue, 12 Mar 2002 01:08:11 -0800 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16khH2-0003FA-00; Tue, 12 Mar 2002 09:04:44 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Steve Lord" Date: Tue, 12 Mar 2002 09:04:43 +0100 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2472) For Windows 2000 (5.0.2195;2) In-Reply-To: <1015885471.22693.62.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: A / with XFS on RAID5 with an external log Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 11 Mar 2002 16:24:31 -0600, Steve Lord wrote: > o second maybe you need two boot options here: > rootfstype=xfs and rootflags=logdev=/dev/md1 Shouldn't that last token rather be: rootflags="logdev=/dev/md1" ??? -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Mar 12 02:12:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2CACjj05948 for linux-xfs-outgoing; Tue, 12 Mar 2002 02:12:45 -0800 Received: from pc226b.ugn.cas.cz (pc226b.ugn.cas.cz [195.113.112.215]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2CACP905924 for ; Tue, 12 Mar 2002 02:12:27 -0800 Received: by pc226b.ugn.cas.cz (Postfix, from userid 1000) id 7BA1A1CD7A20; Tue, 12 Mar 2002 10:12:19 +0100 (CET) Content-Type: text/plain; charset="iso-8859-2" From: Karel Krecmer Organization: =?iso8859-2?q?V=A9B-TU?= To: linux-xfs@oss.sgi.com Subject: oops from crashed kupdated and kswapd Date: Tue, 12 Mar 2002 10:12:18 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020312091219.7BA1A1CD7A20@pc226b.ugn.cas.cz> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Some daemons (kupdated and others) crashed on my Debian unstable, kernel 2.4.17 with xfs patch. I found in syslog some info (see below) about crash. I would like to this information will be useful. regards Karel -- Karel Krecmer Technical University Ostrava ksymoops 2.4.3 on i686 2.4.18-xfs. Options used -V (default) -K (specified) -L (specified) -o /lib/modules/2.4.17-xfs (specified) -m /boot/System.map-2.4.17-xfs.old (specified) No modules in ksyms, skipping objects Mar 8 01:09:33 pc226b kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000258 Mar 8 01:09:33 pc226b kernel: c01a13f4 Mar 8 01:09:33 pc226b kernel: *pde = 00000000 Mar 8 01:09:33 pc226b kernel: Oops: 0000 Mar 8 01:09:33 pc226b kernel: CPU: 0 Mar 8 01:09:33 pc226b kernel: EIP: 0010:[xfs_iflush+360/1036] Tainted: P Mar 8 01:09:33 pc226b kernel: EFLAGS: 00010006 Mar 8 01:09:33 pc226b kernel: eax: 00000000 ebx: 00000200 ecx: cff36000 edx: c39c8488 Mar 8 01:09:33 pc226b kernel: esi: c2eaf100 edi: 00000001 ebp: 00000000 esp: c142ff10 Mar 8 01:09:33 pc226b kernel: ds: 0018 es: 0018 ss: 0018 Mar 8 01:09:33 pc226b kernel: Process kupdated (pid: 7, stackpage=c142f000) Mar 8 01:09:33 pc226b kernel: Stack: c3b06840 c39c8488 c382b280 c4053760 00000246 00000000 cff36000 c53e9e00 Mar 8 01:09:33 pc226b kernel: c3b06840 c01b437b c39c8488 00000005 cff36118 cff73c00 cff73c44 c142e24b Mar 8 01:09:33 pc226b kernel: 0008e000 00000010 00000000 cff36118 00000001 00000000 00000000 00000000 Mar 8 01:09:33 pc226b kernel: Call Trace: [xfs_syncsub+1871/3044] [xfs_sync+21/28] [linvfs_write_super+43/48] [sync_supers+186/236] [sync_old_buffers+12/64] Mar 8 01:09:33 pc226b kernel: Code: f7 43 58 ff 01 00 00 75 0d 83 be f8 00 00 00 00 0f 84 82 00 Using defaults from ksymoops -t elf32-i386 -a i386 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: f7 43 58 ff 01 00 00 testl $0x1ff,0x58(%ebx) Code; 00000006 Before first symbol 7: 75 0d jne 16 <_EIP+0x16> 00000016 Before first symbol Code; 00000008 Before first symbol 9: 83 be f8 00 00 00 00 cmpl $0x0,0xf8(%esi) Code; 00000010 Before first symbol 10: 0f 84 82 00 00 00 je 98 <_EIP+0x98> 00000098 Before first symbol Mar 8 10:08:40 pc226b kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 0000021c Mar 8 10:08:40 pc226b kernel: c01b0ec6 Mar 8 10:08:40 pc226b kernel: *pde = 00000000 Mar 8 10:08:40 pc226b kernel: Oops: 0000 Mar 8 10:08:40 pc226b kernel: CPU: 0 Mar 8 10:08:40 pc226b kernel: EIP: 0010:[xfs_trans_unlocked_item+10/60] Tainted: P Mar 8 10:08:40 pc226b kernel: EFLAGS: 00010206 Mar 8 10:08:40 pc226b kernel: eax: cff36000 ebx: cff36000 ecx: c2eaf100 edx: 00000000 Mar 8 10:08:40 pc226b kernel: esi: 00000200 edi: 00000001 ebp: 00000000 esp: c1433ea0 Mar 8 10:08:40 pc226b kernel: ds: 0018 es: 0018 ss: 0018 Mar 8 10:08:40 pc226b kernel: Process kswapd (pid: 5, stackpage=c1433000) Mar 8 10:08:40 pc226b kernel: Stack: 00000008 c2eaf100 c019e1ab cff36000 00000200 00000000 0007ffff c01b603a Mar 8 10:08:40 pc226b kernel: c2eaf100 00000008 c2eaf100 cff36000 00000000 c70c2340 c01b6bf6 ffffffff Mar 8 10:08:40 pc226b kernel: ffffffff 00000001 00000001 00000000 fffffffe ffffffff ffffffff 0007ffff Mar 8 10:08:40 pc226b kernel: Call Trace: [xfs_iunlock+95/104] [xfs_inactive_free_eofblocks+202/652] [xfs_inactive+1150/1184] [xfs_inactive+250/1184] [vn_put+52/124] Mar 8 10:08:40 pc226b kernel: Code: f6 46 1c 01 74 26 f6 83 34 02 00 00 10 75 1d 8d 43 18 50 e8 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: f6 46 1c 01 testb $0x1,0x1c(%esi) Code; 00000004 Before first symbol 4: 74 26 je 2c <_EIP+0x2c> 0000002c Before first symbol Code; 00000006 Before first symbol 6: f6 83 34 02 00 00 10 testb $0x10,0x234(%ebx) Code; 0000000c Before first symbol d: 75 1d jne 2c <_EIP+0x2c> 0000002c Before first symbol Code; 0000000e Before first symbol f: 8d 43 18 lea 0x18(%ebx),%eax Code; 00000012 Before first symbol 12: 50 push %eax Code; 00000012 Before first symbol 13: e8 00 00 00 00 call 18 <_EIP+0x18> 00000018 Before first symbol From owner-linux-xfs@oss.sgi.com Tue Mar 12 10:22:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2CIMlX15597 for linux-xfs-outgoing; Tue, 12 Mar 2002 10:22:47 -0800 Received: from lucy.ulatina.ac.cr (root@lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2CIMe915575 for ; Tue, 12 Mar 2002 10:22:43 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g2CHItw11688; Tue, 12 Mar 2002 11:18:55 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Re: Serveral weid errors on sys_sparc32.c From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: <20020312171300.Y24252@wobbly.melbourne.sgi.com> References: <1015543584.5649.2.camel@lucy> <20020312171300.Y24252@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 12 Mar 2002 11:18:55 -0600 Message-Id: <1015953535.11325.8.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > The latest quota patches are in CVS - could you try these out on > your Sparc64 box and let me know if your build problem is fixed? They compiled fine, booted fine and they've let me create and mount xfs filesystems on my box. Thanks for all the help with it. /me goes back to its stress testing of xfs on sparc64 -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Tue Mar 12 13:44:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2CLi2M24846 for linux-xfs-outgoing; Tue, 12 Mar 2002 13:44:02 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2CLhv924820 for ; Tue, 12 Mar 2002 13:43:57 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2CKhqbX024843 for ; Tue, 12 Mar 2002 12:43:52 -0800 Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA16501 for ; Tue, 12 Mar 2002 12:43:21 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 71E0D136590 for ; Tue, 12 Mar 2002 12:43:21 -0800 (PST) Subject: problem with filled-up partition From: Florin Andrei To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 12 Mar 2002 12:43:21 -0800 Message-Id: <1015965801.1610.15.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I used Snort + MySQL to sniff the traffic on a network. Because it was unattended, after a few days the MySQL database took up the entire / partition (i only had a small /boot and a swap partition, everything else was on /). I stopped the mysqld processes, and tried to erase the DB manually. Well, it kind-of worked: some files were deleted ok, but a few ones not (i tried to delete them with an F8 command from midnight commander). I was able to delete all files by entering the directory, selecting them all in mc, and F8 again. But the directory itself (/var/lib/mysql/snort) wasn't deleteable. Strange enough, when i created /var/lib/mysql/snort0 and /var/lib/mysql/snort1 from the mysql client ("CREATE DATABASE ..."), the old undeleteable directory dissapeared! This is odd. No such problems should appear by simply filling up the partition... I'm using vanilla XFS-1.0.2a (from the ISO) on an SGI1100. -- Florin Andrei Jack Valenti, president of the Motion Picture Association of America, has reported that the year 2001 was the "greatest box office year in film history" with movie admissions reaching their highest level since 1959. Isn't this the same industry that is complaining that piracy is putting them out of business? From owner-linux-xfs@oss.sgi.com Tue Mar 12 22:03:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2D63T531961 for linux-xfs-outgoing; Tue, 12 Mar 2002 22:03:29 -0800 Received: from mta6.srv.hcvlny.cv.net (mta6.srv.hcvlny.cv.net [167.206.5.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2D63N931934 for ; Tue, 12 Mar 2002 22:03:23 -0800 Received: from nic.com (ool-4350f032.dyn.optonline.net [67.80.240.50]) by mta6.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GSW000AQBDWP1@mta6.srv.hcvlny.cv.net> for linux-xfs@oss.sgi.com; Wed, 13 Mar 2002 00:03:33 -0500 (EST) Date: Wed, 13 Mar 2002 00:01:52 -0500 From: John W Subject: Millions of Files XFS RAID 5 (S/W) To: linux-xfs@oss.sgi.com Reply-to: jwest@nic.com Message-id: <3C8EDD40.A17450CC@nic.com> Organization: Long Pond Industries MIME-version: 1.0 X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-xfs i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello all, Box is working better, for sure... quick review, onboard Adaptec 80 Mbps scsi... bootable.... RHL 7.2 with 2.4.18-XFS and Tronds Patches. (asus P2B-DS with Dual 400's and 256 MB RAM) Split channel bus with 2 (non bootable NCR53C875 Compaq branded controllers). Compaq Array (F2 perhaps?). anyhoo: During deletes/ moves of say 2,000 files, in 200 directories ( maybe 3 levels deep max) I can watch the lights on the drives go from Disk 1 to Disk 2 Disk 3 Disk 4, and so on.. about 1/4 second per drive.. seems pokey... but it does complete. Was playing with SAR and seeing all sorts of things go by, there are lots of options.. the -d for tranactions per sec, the -q for run queue size... Seems there are 255 transactions per second.. is this bottle neck? Or, is Ypbind sucking 60 MB and Nautilus sucking 100 more of an issue? Its not swapping... just slower than expected for the task it would seem. Would comparison to O200 and single disk file system deletion be of interest? Any idea what to watch in sar, or other system monitor tool? (or is it just software RAID5 that sucks the bus down?) Thanks! John Westerdale # Inspire Growth # From owner-linux-xfs@oss.sgi.com Tue Mar 12 22:39:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2D6dOA32502 for linux-xfs-outgoing; Tue, 12 Mar 2002 22:39:24 -0800 Received: from mta2.srv.hcvlny.cv.net (mta2.srv.hcvlny.cv.net [167.206.5.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2D6dH932475 for ; Tue, 12 Mar 2002 22:39:17 -0800 Received: from nic.com (ool-4350f032.dyn.optonline.net [67.80.240.50]) by mta2.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GSW00L8VD1FPB@mta2.srv.hcvlny.cv.net> for linux-xfs@oss.sgi.com; Wed, 13 Mar 2002 00:39:15 -0500 (EST) Date: Wed, 13 Mar 2002 00:37:46 -0500 From: John W Subject: Re: Does XFS on hardware RAID5 have perfomance issues? To: linux-xfs@oss.sgi.com Reply-to: jwest@nic.com Message-id: <3C8EE5AA.E05BC6C0@nic.com> Organization: Long Pond Industries MIME-version: 1.0 X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-xfs i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > The issue with the internal log with software > raid5 is that the alignment (or lack thereof) of the logwrites causes > invalidation of the internal cache in the raid code which is used for > parity generation. All, If this is the case, then the RAID code get flushed and then sucked back into cache too often? Guess the dinky cache of the Intel Boxen is the weak point. There once was a way, in a distant land, to mark executables as stickier, so they would not get flushed as often as data... thus the code would more probably stay in cache. Do multiple CPU's even compound matters by killing coherency even more? The idea of a software RAID implementation spoils the purity of the whole SCSI thing. More thrashing of the CPU for disk transactions, sounds more like IDE! Hardware RAID all the better... Using separate partitions for log on same disk would make the disk head reposition to a different location, wouldn't that be bad for a big writes? Having a log on a different or even dedicated disk sounds like a great idea... but that is intuition! Is this whats happening? Learning lots on the list! John Westerdale # if you cant xylem, phloegm # From owner-linux-xfs@oss.sgi.com Wed Mar 13 00:31:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2D8VJg02013 for linux-xfs-outgoing; Wed, 13 Mar 2002 00:31:19 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2D8VF901987 for ; Wed, 13 Mar 2002 00:31:16 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2D8crkw007632 for ; Wed, 13 Mar 2002 02:38:54 -0600 Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA50407 for linux-xfs@oss.sgi.com; Wed, 13 Mar 2002 18:29:49 +1100 (EST) Date: Wed, 13 Mar 2002 18:29:49 +1100 (EST) From: Timothy Shimmin Message-Id: <200203130729.SAA50407@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump.html Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Mar 12 23:28:50 PST 2002 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:113980a cmd/xfsdump/doc/xfsdump.html - 1.4 - Add some info about the drive strategies. From owner-linux-xfs@oss.sgi.com Wed Mar 13 09:42:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2DHgZV20957 for linux-xfs-outgoing; Wed, 13 Mar 2002 09:42:35 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2DHgU920931 for ; Wed, 13 Mar 2002 09:42:31 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2DHoBkw011730 for ; Wed, 13 Mar 2002 11:50:12 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA38861 for ; Wed, 13 Mar 2002 10:42:24 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA07439 for ; Wed, 13 Mar 2002 10:42:24 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g2DGgO018926; Wed, 13 Mar 2002 10:42:24 -0600 Message-Id: <200203131642.g2DGgO018926@stout.americas.sgi.com> Date: Wed, 13 Mar 2002 10:42:24 -0600 From: Eric Sandeen Subject: TAKE - undo BLKGETSIZE64 warning mod Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This removes the warning about falling back from BLKGETSIZE64 to BLKGETSIZE - at least for now. We can put this back in after a bit, but I shudder to think of all the emails that will be generated if our 1.1 release issues a warning, or even a cryptic informational statement, whenever anyone uses xfsprogs 2.0+ on one of our released kernels for Red Hat... Date: Wed Mar 13 08:39:34 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-alwaysclean Undoes mod: xfs-cmds:slinx:113024a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:114005a cmd/xfsprogs/libxfs/init.c - 1.15 From owner-linux-xfs@oss.sgi.com Wed Mar 13 10:41:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2DIfSK23989 for linux-xfs-outgoing; Wed, 13 Mar 2002 10:41:28 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2DIeC923961 for ; Wed, 13 Mar 2002 10:40:12 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2DHe46G028392 for ; Wed, 13 Mar 2002 09:40:04 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA40960 for ; Wed, 13 Mar 2002 11:40:04 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA30911 for ; Wed, 13 Mar 2002 11:40:04 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2DHcug13510; Wed, 13 Mar 2002 11:38:56 -0600 Message-Id: <200203131738.g2DHcug13510@jen.americas.sgi.com> Date: Wed, 13 Mar 2002 11:38:56 -0600 Subject: TAKE - merge up to 2.5.7-pre1 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Mar 13 09:36:24 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:114009a linux/arch/ia64/sn/fakeprom/fpmem.c - 1.1 linux/arch/ia64/sn/kernel/sv.c - 1.1 linux/include/asm-ia64/sn/ifconfig_net.h - 1.1 linux/Documentation/ia64/IRQ-redir.txt - 1.1 linux/arch/ia64/sn/kernel/sn_ksyms.c - 1.1 linux/arch/ia64/sn/kernel/sn_asm.S - 1.1 linux/arch/ia64/sn/kernel/sn2/sn2_smp.c - 1.1 linux/include/linux/hash.h - 1.1 linux/include/linux/futex.h - 1.1 linux/include/asm-ia64/sn/hires_clock.h - 1.1 linux/fs/jffs2/writev.c - 1.1 linux/arch/ia64/sn/kernel/sn2/iomv.c - 1.1 linux/arch/ia64/sn/kernel/sn2/cache.c - 1.1 linux/arch/ia64/sn/kernel/sn2/Makefile - 1.1 linux/arch/ia64/sn/kernel/sn1/synergy.c - 1.1 linux/arch/ia64/sn/kernel/sn1/sn1_smp.c - 1.1 linux/arch/ia64/sn/kernel/sn1/iomv.c - 1.1 linux/include/asm-ia64/sn/ate_utils.h - 1.1 linux/arch/ia64/sn/kernel/sn1/error.c - 1.1 linux/arch/ia64/sn/kernel/sn1/cache.c - 1.1 linux/arch/ia64/sn/kernel/llsc4.h - 1.1 linux/arch/ia64/sn/kernel/sn1/Makefile - 1.1 linux/arch/ia64/sn/kernel/irq.c - 1.1 linux/include/asm-ia64/sn/bte.h - 1.1 l