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 linux/arch/ia64/sn/kernel/bte.c - 1.1 linux/fs/jffs2/wbuf.c - 1.1 linux/arch/ia64/sn/io/efi-rtc.c - 1.1 linux/arch/ia64/sn/io/ifconfig_net.c - 1.1 linux/fs/jffs2/os-linux.h - 1.1 linux/kernel/futex.c - 1.1 linux/arch/ia64/sn/kernel/setup.c - 1.1 linux/arch/ia64/sn/kernel/probe.c - 1.1 linux/arch/ia64/sn/kernel/misctest.c - 1.1 linux/arch/ia64/sn/io/ate_utils.c - 1.1 linux/arch/ia64/sn/kernel/mca.c - 1.1 linux/arch/ia64/sn/kernel/machvec.c - 1.1 linux/include/asm-ia64/thread_info.h - 1.1 linux/include/asm-ia64/sn/uart16550.h - 1.1 linux/fs/jffs2/fs.c - 1.1 linux/mm/mincore.c - 1.1 linux/include/asm-ia64/sn/sndrv.h - 1.1 linux/mm/msync.c - 1.1 linux/include/asm-ia64/sn/snconfig.h - 1.1 linux/include/asm-ia64/sn/sn_pio_sync.h - 1.1 linux/include/asm-ia64/sn/sn2/sn_private.h - 1.1 linux/include/asm-ia64/sn/sn2/slotnum.h - 1.1 linux/include/asm-ia64/sn/sn2/shubio.h - 1.1 linux/include/asm-ia64/sn/sn2/shub_mmr_t.h - 1.1 linux/include/asm-ia64/sn/sn2/shub_mmr.h - 1.1 linux/include/asm-ia64/sn/sn2/shub_md.h - 1.1 linux/include/asm-ia64/sn/sn2/shub.h - 1.1 linux/include/asm-ia64/sn/sn2/mmzone_sn2.h - 1.1 linux/include/asm-ia64/sn/sn2/intr.h - 1.1 linux/include/asm-ia64/sn/sn2/arch.h - 1.1 linux/include/asm-ia64/sn/sn2/addrs.h - 1.1 linux/include/asm-ia64/sn/sn1/synergy.h - 1.1 linux/include/asm-ia64/sn/sn1/sn_private.h - 1.1 linux/include/asm-ia64/sn/sn1/mmzone_sn1.h - 1.1 linux/include/asm-ia64/sn/sn1/mem_refcnt.h - 1.1 linux/include/asm-ia64/sn/sn1/intr_public.h - 1.1 linux/include/asm-ia64/sn/sn1/intr.h - 1.1 linux/include/asm-ia64/sn/sn1/hwcntrs.h - 1.1 linux/include/asm-ia64/sn/sn1/hubstat.h - 1.1 linux/include/asm-ia64/sn/sn1/hubspc.h - 1.1 linux/include/asm-ia64/sn/simulator.h - 1.1 linux/include/asm-ia64/sn/pio_flush.h - 1.1 linux/include/asm-ia64/sn/pda.h - 1.1 linux/include/asm-ia64/sn/nag.h - 1.1 linux/include/asm-ia64/sn/mmtimer_private.h - 1.1 linux/include/asm-ia64/sn/mca.h - 1.1 linux/include/asm-ia64/sn/leds.h - 1.1 linux/include/asm-ia64/sn/klclock.h - 1.1 linux/include/asm-ia64/machvec_sn2.h - 1.1 linux/include/asm-ia64/sn/idle.h - 1.1 linux/arch/ia64/sn/configs/sn1/defconfig-generic-sp - 1.1 linux/include/asm-ia64/sn/fetchop.h - 1.1 linux/include/asm-ia64/sn/bte_copy.h - 1.1 linux/arch/ia64/sn/configs/sn1/defconfig-hp-sp - 1.1 linux/arch/ia64/sn/io/sn1/hub_intr.c - 1.1 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp - 1.1 linux/arch/ia64/kernel/salinfo.c - 1.1 linux/arch/ia64/sn/io/sn1/hubcounters.c - 1.1 linux/arch/ia64/sn/kernel/llsc4.c - 1.1 linux/arch/ia64/sn/io/sn1/huberror.c - 1.1 linux/fs/jffs2/README.Locking - 1.1 linux/arch/ia64/sn/kernel/Makefile - 1.1 linux/arch/ia64/sn/io/sn2/shuberror.c - 1.1 linux/arch/ia64/sn/io/sn2/shub_intr.c - 1.1 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c - 1.1 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c - 1.1 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c - 1.1 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_idbg.c - 1.1 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_hints.c - 1.1 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_error.c - 1.1 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.1 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_config.c - 1.1 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c - 1.1 linux/arch/ia64/sn/io/sn2/ml_SN_intr.c - 1.1 linux/arch/ia64/sn/configs/sn1/defconfig-bigsur-mp - 1.1 linux/arch/ia64/sn/configs/sn1/defconfig-bigsur-sp - 1.1 linux/arch/ia64/sn/configs/sn1/defconfig-dig-mp - 1.1 linux/arch/ia64/sn/configs/sn1/defconfig-dig-sp - 1.1 linux/arch/ia64/sn/configs/sn1/defconfig-generic-mp - 1.1 linux/arch/ia64/sn/io/sn1/ip37.c - 1.1 linux/arch/ia64/sn/io/sn1/mem_refcnt.c - 1.1 linux/arch/ia64/sn/configs/sn1/defconfig-prom-medusa - 1.1 linux/arch/ia64/sn/io/sn1/ml_SN_intr.c - 1.1 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp-modules - 1.1 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp-syn1-0 - 1.1 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-sp - 1.1 linux/arch/ia64/sn/configs/sn2/defconfig-dig-numa - 1.1 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-dig-mp - 1.1 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-dig-sp - 1.1 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-mp - 1.1 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-mp-modules - 1.1 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-prom-medusa - 1.1 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-sp - 1.1 linux/arch/ia64/sn/fakeprom/Makefile - 1.1 linux/arch/ia64/sn/fakeprom/README - 1.1 linux/arch/ia64/sn/io/sn2/bte_error.c - 1.1 linux/arch/ia64/sn/fakeprom/fpmem.h - 1.1 linux/arch/ia64/sn/fakeprom/fprom.lds - 1.1 linux/arch/ia64/sn/fakeprom/fpromasm.S - 1.1 linux/arch/ia64/sn/fakeprom/fw-emu.c - 1.1 linux/arch/ia64/sn/fakeprom/klgraph_init.c - 1.1 linux/arch/ia64/sn/fakeprom/main.c - 1.1 linux/arch/ia64/sn/fakeprom/runsim - 1.1 linux/arch/ia64/sn/io/sn1/pcibr.c - 1.1 linux/net/unix/af_unix.c - 1.43 linux/net/sunrpc/xprt.c - 1.24 linux/net/sunrpc/svcsock.c - 1.18 linux/net/sunrpc/sunrpc_syms.c - 1.11 linux/net/socket.c - 1.33 linux/net/packet/af_packet.c - 1.31 linux/net/netsyms.c - 1.43 linux/net/irda/af_irda.c - 1.34 linux/net/ipv6/udp.c - 1.25 linux/net/ipv6/tcp_ipv6.c - 1.34 linux/net/ipv6/raw.c - 1.23 linux/net/ipv6/ndisc.c - 1.20 linux/net/ipv6/ipv6_sockglue.c - 1.15 linux/net/ipv6/af_inet6.c - 1.21 linux/net/ipv4/udp.c - 1.30 linux/net/ipv4/tcp_timer.c - 1.24 linux/net/ipv4/tcp_output.c - 1.29 linux/net/ipv4/tcp_ipv4.c - 1.43 linux/net/ipv4/tcp_input.c - 1.36 linux/net/ipv4/tcp.c - 1.38 linux/net/ipv4/raw.c - 1.22 linux/net/ipv4/ip_sockglue.c - 1.19 linux/net/ipv4/ip_output.c - 1.31 linux/net/ipv4/ip_input.c - 1.15 linux/net/ipv4/af_inet.c - 1.33 linux/net/Config.in - 1.21 linux/mm/page_alloc.c - 1.75 linux/mm/mprotect.c - 1.24 linux/mm/memory.c - 1.78 linux/mm/filemap.c - 1.114 linux/mm/Makefile - 1.13 linux/kernel/sched.c - 1.63 linux/kernel/printk.c - 1.18 linux/kernel/ksyms.c - 1.139 linux/kernel/acct.c - 1.16 linux/kernel/Makefile - 1.28 linux/include/net/udp.h - 1.8 linux/include/net/tcp.h - 1.29 linux/include/net/sock.h - 1.30 linux/include/net/ip.h - 1.17 linux/include/linux/wireless.h - 1.9 linux/include/linux/videodev.h - 1.21 linux/include/linux/rtnetlink.h - 1.12 linux/include/linux/nfsd/export.h - 1.12 linux/include/linux/netdevice.h - 1.32 linux/include/linux/mm.h - 1.83 linux/include/linux/minix_fs.h - 1.12 linux/include/linux/ip.h - 1.5 linux/include/linux/if_ec.h - 1.6 linux/include/linux/hdreg.h - 1.16 linux/include/linux/fs.h - 1.160 linux/include/asm-sparc64/unistd.h - 1.18 linux/include/asm-sparc64/system.h - 1.17 linux/include/asm-sparc64/siginfo.h - 1.8 linux/include/asm-sparc64/pgtable.h - 1.33 linux/include/asm-sparc64/mmu_context.h - 1.17 linux/include/asm-sparc64/head.h - 1.3 linux/include/asm-sparc64/fhc.h - 1.4 linux/include/asm-sparc64/bitops.h - 1.13 linux/include/asm-sparc/unistd.h - 1.16 linux/include/asm-sparc/siginfo.h - 1.10 linux/include/asm-ppc/unistd.h - 1.19 linux/include/asm-ppc/mman.h - 1.7 linux/include/asm-i386/unistd.h - 1.23 linux/include/asm-i386/mman.h - 1.4 linux/include/asm-arm/procinfo.h - 1.9 linux/include/asm-arm/proc-fns.h - 1.12 linux/include/asm-arm/proc-armv/pgtable.h - 1.16 linux/include/asm-arm/proc-armv/page.h - 1.5 linux/include/asm-arm/proc-armo/pgtable.h - 1.10 linux/include/asm-arm/proc-armo/page.h - 1.5 linux/include/asm-arm/pgtable.h - 1.25 linux/include/asm-arm/page.h - 1.16 linux/include/asm-arm/arch-ebsa110/system.h - 1.11 linux/fs/vfat/vfatfs_syms.c - 1.8 linux/fs/ufs/super.c - 1.27 linux/fs/super.c - 1.81 linux/fs/smbfs/inode.c - 1.31 linux/fs/romfs/inode.c - 1.32 linux/fs/qnx4/inode.c - 1.32 linux/fs/proc/root.c - 1.28 linux/fs/pipe.c - 1.28 linux/fs/ntfs/fs.c - 1.41 linux/fs/nfsd/nfsfh.c - 1.38 linux/fs/nfsd/export.c - 1.31 linux/fs/nfs/inode.c - 1.39 linux/fs/ncpfs/inode.c - 1.28 linux/fs/namei.c - 1.50 linux/fs/msdos/msdosfs_syms.c - 1.9 linux/fs/minix/namei.c - 1.18 linux/fs/minix/inode.c - 1.31 linux/fs/minix/dir.c - 1.10 linux/fs/minix/bitmap.c - 1.15 linux/fs/lockd/svcproc.c - 1.11 linux/fs/isofs/inode.c - 1.34 linux/fs/inode.c - 1.71 linux/fs/hfs/super.c - 1.15 linux/fs/ext2/super.c - 1.27 linux/fs/exec.c - 1.55 linux/fs/devpts/inode.c - 1.14 linux/fs/coda/inode.c - 1.22 linux/fs/block_dev.c - 1.44 linux/fs/binfmt_misc.c - 1.20 linux/fs/autofs/init.c - 1.9 linux/fs/affs/super.c - 1.21 linux/fs/adfs/super.c - 1.19 linux/fs/Config.in - 1.81 linux/drivers/scsi/ide-scsi.c - 1.29 linux/drivers/pci/pci.c - 1.55 linux/drivers/net/sunhme.h - 1.12 linux/drivers/net/sunhme.c - 1.35 linux/drivers/acorn/scsi/fas216.c - 1.12 linux/drivers/acorn/scsi/acornscsi.c - 1.13 linux/drivers/acorn/net/etherh.c - 1.13 linux/drivers/acorn/net/ether3.c - 1.14 linux/drivers/acorn/char/serial-dualsp.c - 1.5 linux/drivers/acorn/char/serial-card.c - 1.7 linux/drivers/acorn/char/serial-atomwide.c - 1.5 linux/arch/sparc64/vmlinux.lds - 1.12 linux/arch/sparc64/solaris/ioctl.c - 1.13 linux/arch/sparc64/mm/ultra.S - 1.26 linux/arch/sparc64/mm/init.c - 1.40 linux/arch/sparc64/mm/generic.c - 1.10 linux/arch/sparc64/mm/fault.c - 1.21 linux/arch/sparc64/kernel/ttable.S - 1.14 linux/arch/sparc64/kernel/time.c - 1.18 linux/arch/sparc64/kernel/systbls.S - 1.25 linux/arch/sparc64/kernel/sys_sparc32.c - 1.48 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.40 linux/arch/sparc64/kernel/smp.c - 1.39 linux/arch/sparc64/kernel/signal32.c - 1.22 linux/arch/sparc64/kernel/signal.c - 1.20 linux/arch/sparc64/kernel/setup.c - 1.27 linux/arch/sparc64/kernel/rtrap.S - 1.15 linux/arch/sparc64/kernel/ptrace.c - 1.16 linux/arch/sparc64/kernel/process.c - 1.32 linux/arch/sparc64/kernel/ioctl32.c - 1.51 linux/arch/sparc64/kernel/entry.S - 1.21 linux/arch/sparc64/kernel/central.c - 1.6 linux/arch/sparc64/defconfig - 1.62 linux/arch/sparc/vmlinux.lds - 1.11 linux/arch/sparc/kernel/systbls.S - 1.21 linux/arch/ppc/kernel/misc.S - 1.37 linux/arch/ppc/defconfig - 1.38 linux/arch/i386/kernel/entry.S - 1.52 linux/arch/i386/kernel/apm.c - 1.41 linux/arch/i386/defconfig - 1.102 linux/arch/arm/mm/proc-sa110.S - 1.25 linux/arch/arm/mm/proc-arm6,7.S - 1.21 linux/arch/arm/mm/proc-arm2,3.S - 1.12 linux/arch/arm/mm/mm-armv.c - 1.25 linux/arch/arm/mm/init.c - 1.26 linux/arch/arm/mm/fault-armv.c - 1.23 linux/arch/arm/kernel/setup.c - 1.27 linux/arch/arm/kernel/entry-armv.S - 1.26 linux/arch/arm/kernel/dma.c - 1.10 linux/arch/alpha/defconfig - 1.24 linux/Makefile - 1.190 linux/MAINTAINERS - 1.100 linux/Documentation/video4linux/API.html - 1.5 linux/include/linux/ide.h - 1.42 linux/fs/hpfs/super.c - 1.15 linux/fs/efs/super.c - 1.13 linux/Documentation/kernel-parameters.txt - 1.15 linux/arch/sparc64/kernel/pci_sabre.c - 1.29 linux/arch/sparc64/kernel/pci_psycho.c - 1.27 linux/arch/sparc64/kernel/pci_common.c - 1.17 linux/arch/sparc64/kernel/pci.c - 1.24 linux/include/asm-arm/cpu-single.h - 1.10 linux/include/asm-arm/cpu-multi32.h - 1.10 linux/fs/udf/super.c - 1.26 linux/arch/i386/kernel/pci-pc.c - 1.34 linux/arch/i386/kernel/pci-i386.h - 1.8 linux/include/linux/pci_ids.h - 1.61 linux/include/asm-arm/proc-armv/cache.h - 1.13 linux/fs/bfs/inode.c - 1.21 linux/include/asm-i386/pgalloc.h - 1.17 linux/arch/ppc/configs/pmac_defconfig - 1.5 linux/arch/ppc/configs/common_defconfig - 1.25 linux/include/linux/mmzone.h - 1.19 linux/arch/sparc64/kernel/sbus.c - 1.16 linux/include/asm-sparc64/pgalloc.h - 1.18 linux/fs/openpromfs/inode.c - 1.19 linux/fs/cramfs/inode.c - 1.26 linux/net/sched/sch_gred.c - 1.9 linux/drivers/usb/inode.c - 1.24 linux/Documentation/DMA-mapping.txt - 1.13 linux/fs/autofs4/init.c - 1.6 linux/drivers/char/efirtc.c - 1.8 linux/arch/ia64/kernel/head.S - 1.10 linux/arch/ia64/kernel/gate.S - 1.9 linux/arch/ia64/kernel/entry.S - 1.22 linux/arch/ia64/kernel/acpi.c - 1.11 linux/arch/ia64/ia32/sys_ia32.c - 1.23 linux/arch/ia64/ia32/ia32_support.c - 1.7 linux/arch/ia64/ia32/ia32_signal.c - 1.9 linux/arch/ia64/ia32/ia32_entry.S - 1.15 linux/arch/ia64/ia32/binfmt_elf32.c - 1.13 linux/drivers/acorn/char/i2c.c - 1.4 linux/arch/ia64/hp/hpsim_console.c - 1.4 linux/arch/ia64/dig/setup.c - 1.7 linux/arch/ia64/vmlinux.lds.S - 1.9 linux/arch/ia64/tools/print_offsets.c - 1.10 linux/arch/ia64/defconfig - 1.12 linux/arch/ia64/config.in - 1.24 linux/arch/ia64/Makefile - 1.11 linux/arch/ia64/tools/print_offsets.awk - 1.4 linux/arch/ia64/kernel/init_task.c - 1.4 linux/arch/ia64/kernel/irq.c - 1.16 linux/arch/ia64/tools/Makefile - 1.7 linux/arch/ia64/sn/Makefile - 1.5 linux/arch/ia64/sn/sn1/Makefile - 1.5 linux/arch/ia64/kernel/setup.c - 1.12 linux/arch/ia64/kernel/signal.c - 1.13 linux/arch/ia64/kernel/smp.c - 1.12 linux/arch/ia64/kernel/sys_ia64.c - 1.11 linux/arch/ia64/kernel/traps.c - 1.12 linux/arch/ia64/kernel/unaligned.c - 1.10 linux/arch/ia64/kernel/unwind.c - 1.10 linux/arch/ia64/kernel/ivt.S - 1.14 linux/arch/ia64/lib/clear_page.S - 1.6 linux/arch/ia64/lib/copy_page.S - 1.7 linux/arch/ia64/sn/sn1/setup.c - 1.6 linux/arch/ia64/sn/sn1/machvec.c - 1.4 linux/arch/ia64/sn/sn1/irq.c - 1.5 linux/arch/ia64/kernel/sal.c - 1.7 linux/arch/ia64/kernel/ptrace.c - 1.15 linux/arch/ia64/kernel/process.c - 1.14 linux/arch/ia64/kernel/perfmon.c - 1.11 linux/arch/ia64/kernel/mca.c - 1.9 linux/arch/ia64/mm/init.c - 1.13 linux/arch/ia64/mm/fault.c - 1.8 linux/arch/ia64/mm/extable.c - 1.4 linux/arch/ia64/kernel/mca_asm.S - 1.9 linux/include/asm-ia64/sigcontext.h - 1.5 linux/include/asm-ia64/irq.h - 1.3 linux/include/asm-ia64/io.h - 1.9 linux/include/asm-ia64/ia32.h - 1.11 linux/include/asm-ia64/hardirq.h - 1.11 linux/include/asm-ia64/elf.h - 1.4 linux/include/asm-ia64/current.h - 1.3 linux/include/asm-ia64/checksum.h - 1.2 linux/include/asm-ia64/bitops.h - 1.7 linux/include/asm-ia64/acpi-ext.h - 1.7 linux/include/asm-ia64/a.out.h - 1.5 linux/include/asm-ia64/siginfo.h - 1.10 linux/include/asm-ia64/mman.h - 1.4 linux/include/asm-ia64/mca_asm.h - 1.6 linux/include/asm-ia64/smp.h - 1.10 linux/include/asm-ia64/scatterlist.h - 1.7 linux/include/asm-ia64/sal.h - 1.9 linux/include/asm-ia64/processor.h - 1.16 linux/include/asm-ia64/smplock.h - 1.5 linux/include/asm-ia64/pgtable.h - 1.15 linux/include/asm-ia64/pgalloc.h - 1.10 linux/include/asm-ia64/machvec.h - 1.7 linux/include/asm-ia64/pci.h - 1.12 linux/include/asm-ia64/pal.h - 1.9 linux/include/asm-ia64/page.h - 1.12 linux/include/asm-ia64/softirq.h - 1.7 linux/include/asm-ia64/offsets.h - 1.12 linux/include/asm-ia64/ptrace.h - 1.9 linux/include/asm-ia64/machvec_sn1.h - 1.5 linux/include/asm-ia64/mca.h - 1.6 linux/include/asm-ia64/spinlock.h - 1.9 linux/include/asm-ia64/unistd.h - 1.17 linux/include/asm-ia64/signal.h - 1.4 linux/include/asm-ia64/uaccess.h - 1.7 linux/include/asm-ia64/system.h - 1.11 linux/fs/devfs/base.c - 1.35 linux/fs/lockd/svc4proc.c - 1.7 linux/net/econet/af_econet.c - 1.10 linux/drivers/ide/via82cxxx.c - 1.23 linux/drivers/ide/sis5513.c - 1.15 linux/drivers/ide/ide.c - 1.47 linux/drivers/ide/ide-probe.c - 1.27 linux/drivers/ide/ide-pci.c - 1.23 linux/drivers/ide/ide-dma.c - 1.22 linux/drivers/ide/ide-disk.c - 1.28 linux/drivers/ide/ide-cs.c - 1.9 linux/drivers/ide/ide-cd.c - 1.29 linux/drivers/ide/Makefile - 1.16 linux/drivers/ide/Config.in - 1.18 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.13 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.15 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.12 linux/net/ipv4/netfilter/Makefile - 1.11 linux/net/ipv4/netfilter/Config.in - 1.8 linux/include/linux/netfilter_ipv4/ip_conntrack.h - 1.10 linux/drivers/isdn/avmb1/capifs.c - 1.16 linux/arch/i386/kernel/pci-irq.c - 1.19 linux/fs/ramfs/inode.c - 1.19 linux/arch/ia64/kernel/smpboot.c - 1.7 linux/arch/ia64/kernel/minstate.h - 1.7 linux/arch/ia64/ia32/ia32_traps.c - 1.5 linux/include/linux/if_pppox.h - 1.6 linux/drivers/net/pppoe.c - 1.19 linux/arch/mips64/kernel/ioctl32.c - 1.10 linux/fs/xfs/linux/xfs_super.c - 1.169 linux/Documentation/filesystems/Locking - 1.8 linux/include/asm-ia64/asmmacro.h - 1.4 linux/fs/jffs/inode-v23.c - 1.22 linux/arch/arm/mm/proc-arm720.S - 1.11 linux/arch/ia64/ia32/ia32_ioctl.c - 1.4 linux/arch/ia64/kernel/brl_emu.c - 1.3 linux/arch/ia64/kernel/ia64_ksyms.c - 1.8 linux/arch/ia64/kernel/palinfo.c - 1.7 linux/arch/ia64/kernel/unwind_i.h - 1.4 linux/net/ipv4/tcp_minisocks.c - 1.12 linux/include/asm-arm/mach/pci.h - 1.6 linux/drivers/media/video/videodev.c - 1.12 linux/arch/arm/mach-sa1100/Makefile - 1.8 linux/arch/arm/mm/proc-arm920.S - 1.8 linux/fs/dnotify.c - 1.3 linux/fs/minix/itree_v1.c - 1.4 linux/fs/minix/itree_v2.c - 1.4 linux/include/linux/dnotify.h - 1.5 linux/arch/i386/kernel/dmi_scan.c - 1.15 linux/mm/shmem.c - 1.32 linux/arch/ia64/sn/io/stubs.c - 1.3 linux/include/asm-ia64/sn/addrs.h - 1.3 linux/include/asm-ia64/sn/agent.h - 1.3 linux/include/asm-ia64/sn/alenlist.h - 1.2 linux/include/asm-ia64/sn/arc/hinv.h - 1.3 linux/include/asm-ia64/sn/arc/types.h - 1.2 linux/include/asm-ia64/sn/arch.h - 1.3 linux/include/asm-ia64/sn/cdl.h - 1.3 linux/include/asm-ia64/sn/clksupport.h - 1.2 linux/include/asm-ia64/sn/dmamap.h - 1.3 linux/include/asm-ia64/sn/driver.h - 1.2 linux/include/asm-ia64/sn/eeprom.h - 1.3 linux/include/asm-ia64/sn/gda.h - 1.3 linux/include/asm-ia64/sn/hack.h - 1.3 linux/include/asm-ia64/sn/hcl.h - 1.3 linux/include/asm-ia64/sn/hcl_util.h - 1.2 linux/include/asm-ia64/sn/hubspc.h - 1.2 linux/include/asm-ia64/sn/hwcntrs.h - 1.3 linux/include/asm-ia64/sn/intr.h - 1.3 linux/include/asm-ia64/sn/intr_public.h - 1.3 linux/include/asm-ia64/sn/invent.h - 1.3 linux/include/asm-ia64/sn/io.h - 1.3 linux/include/asm-ia64/sn/iobus.h - 1.2 linux/include/asm-ia64/sn/ioc3.h - 1.2 linux/include/asm-ia64/sn/ioerror.h - 1.3 linux/include/asm-ia64/sn/ioerror_handling.h - 1.3 linux/include/asm-ia64/sn/iograph.h - 1.3 linux/include/asm-ia64/sn/klconfig.h - 1.3 linux/include/asm-ia64/sn/kldir.h - 1.3 linux/include/asm-ia64/sn/ksys/elsc.h - 1.3 linux/include/asm-ia64/sn/ksys/i2c.h - 1.2 linux/include/asm-ia64/sn/ksys/l1.h - 1.3 linux/include/asm-ia64/sn/labelcl.h - 1.2 linux/arch/ia64/kernel/iosapic.c - 1.5 linux/include/asm-ia64/sn/mem_refcnt.h - 1.2 linux/include/asm-ia64/sn/mmzone.h - 1.3 linux/include/asm-ia64/sn/mmzone_default.h - 1.2 linux/include/asm-ia64/sn/mmzone_sn1.h - 1.3 linux/include/asm-ia64/sn/module.h - 1.3 linux/include/asm-ia64/sn/nic.h - 1.2 linux/include/asm-ia64/sn/nodemask.h - 1.3 linux/include/asm-ia64/sn/xtalk/xwidget.h - 1.2 linux/include/asm-ia64/sn/xtalk/xtalkaddrs.h - 1.3 linux/include/asm-ia64/sn/xtalk/xtalk_private.h - 1.3 linux/include/asm-ia64/sn/xtalk/xtalk.h - 1.3 linux/include/asm-ia64/sn/xtalk/xswitch.h - 1.2 linux/include/asm-ia64/sn/xtalk/xbow_info.h - 1.2 linux/include/asm-ia64/sn/xtalk/xbow.h - 1.3 linux/include/asm-ia64/sn/vector.h - 1.2 linux/include/asm-ia64/sn/types.h - 1.3 linux/include/asm-ia64/sn/systeminfo.h - 1.2 linux/include/asm-ia64/sn/synergy.h - 1.3 linux/include/asm-ia64/sn/sn_private.h - 1.3 linux/include/asm-ia64/sn/sn_fru.h - 1.3 linux/include/asm-ia64/sn/sn_cpuid.h - 1.3 linux/include/asm-ia64/sn/sn1/uart16550.h - 1.3 linux/include/asm-ia64/sn/sn1/sn1.h - 1.2 linux/include/asm-ia64/sn/sn1/slotnum.h - 1.3 linux/arch/ia64/lib/swiotlb.c - 1.6 linux/include/asm-ia64/sn/sn1/router.h - 1.3 linux/include/asm-ia64/sn/sn1/promlog.h - 1.2 linux/include/asm-ia64/sn/sn1/leds.h - 1.3 linux/include/asm-ia64/sn/sn1/kldir.h - 1.2 linux/include/asm-ia64/sn/sn1/ip27config.h - 1.3 linux/arch/ia64/sn/fprom/Makefile - 1.4 linux/arch/ia64/sn/fprom/README - 1.2 linux/arch/ia64/sn/fprom/fpmem.c - 1.2 linux/arch/ia64/sn/fprom/fpmem.h - 1.2 linux/arch/ia64/sn/fprom/fprom.lds - 1.3 linux/arch/ia64/sn/fprom/fpromasm.S - 1.2 linux/arch/ia64/sn/fprom/fw-emu.c - 1.4 linux/arch/ia64/sn/fprom/main.c - 1.2 linux/arch/ia64/sn/fprom/runsim - 1.2 linux/arch/ia64/sn/io/Makefile - 1.3 linux/arch/ia64/sn/io/alenlist.c - 1.3 linux/arch/ia64/sn/io/cdl.c - 1.3 linux/arch/ia64/sn/io/devsupport.c - 1.3 linux/arch/ia64/sn/io/eeprom.c - 1.3 linux/arch/ia64/sn/io/hcl.c - 1.4 linux/arch/ia64/sn/io/hcl_util.c - 1.3 linux/arch/ia64/sn/io/hubdev.c - 1.3 linux/arch/ia64/sn/io/hubspc.c - 1.4 linux/arch/ia64/sn/io/invent.c - 1.3 linux/arch/ia64/sn/io/io.c - 1.3 linux/arch/ia64/sn/io/ip37.c - 1.3 linux/arch/ia64/sn/io/klconflib.c - 1.4 linux/arch/ia64/sn/io/klgraph.c - 1.3 linux/arch/ia64/sn/io/klgraph_hack.c - 1.4 linux/arch/ia64/sn/io/l1.c - 1.5 linux/arch/ia64/sn/io/l1_command.c - 1.3 linux/arch/ia64/sn/io/labelcl.c - 1.3 linux/arch/ia64/sn/io/mem_refcnt.c - 1.3 linux/arch/ia64/sn/io/ml_SN_init.c - 1.3 linux/arch/ia64/sn/io/ml_SN_intr.c - 1.4 linux/arch/ia64/sn/io/ml_iograph.c - 1.3 linux/arch/ia64/sn/io/module.c - 1.3 linux/arch/ia64/sn/io/pci.c - 1.3 linux/arch/ia64/sn/io/pci_bus_cvlink.c - 1.4 linux/arch/ia64/sn/io/pci_dma.c - 1.4 linux/arch/ia64/sn/io/pcibr.c - 1.5 linux/arch/ia64/sn/io/pciio.c - 1.3 linux/arch/ia64/sn/io/sgi_if.c - 1.3 linux/arch/ia64/sn/io/sgi_io_init.c - 1.3 linux/arch/ia64/sn/io/sgi_io_sim.c - 1.3 linux/include/asm-ia64/sn/nodepda.h - 1.3 linux/arch/ia64/sn/io/xbow.c - 1.4 linux/arch/ia64/sn/io/xswitch.c - 1.3 linux/arch/ia64/sn/io/xtalk.c - 1.4 linux/include/asm-ia64/sn/sn1/hubxb_next.h - 1.3 linux/arch/ia64/sn/sn1/discontig.c - 1.3 linux/arch/ia64/sn/sn1/iomv.c - 1.3 linux/include/asm-ia64/sn/sn1/hubxb.h - 1.2 linux/arch/ia64/sn/sn1/llsc4.c - 1.4 linux/arch/ia64/sn/sn1/llsc4.h - 1.2 linux/arch/ia64/sn/sn1/mm.c - 1.3 linux/include/asm-ia64/sn/sn1/hubpi_next.h - 1.3 linux/arch/ia64/sn/sn1/smp.c - 1.3 linux/arch/ia64/sn/sn1/sn1_asm.S - 1.3 linux/arch/ia64/sn/sn1/synergy.c - 1.3 linux/arch/ia64/sn/tools/make_textsym - 1.2 linux/include/asm-ia64/sn/sn1/hubpi.h - 1.2 linux/include/asm-ia64/sn/sn1/hubni_next.h - 1.2 linux/include/asm-ia64/sn/sn1/hubni.h - 1.2 linux/include/asm-ia64/sn/sn1/hubmd_next.h - 1.3 linux/include/asm-ia64/sn/sn1/hubmd.h - 1.3 linux/include/asm-ia64/sn/sn1/hublb_next.h - 1.2 linux/include/asm-ia64/sn/sn1/hublb.h - 1.2 linux/include/asm-ia64/sn/sn1/hubio_next.h - 1.3 linux/include/asm-ia64/sn/sn1/hubio.h - 1.2 linux/include/asm-ia64/sn/sn1/hubdev.h - 1.2 linux/include/asm-ia64/sn/sn1/bedrock.h - 1.3 linux/include/asm-ia64/sn/sn1/arch.h - 1.2 linux/include/asm-ia64/sn/sn1/addrs.h - 1.3 linux/include/asm-ia64/sn/slotnum.h - 1.3 linux/include/asm-ia64/sn/sgi.h - 1.3 linux/include/asm-ia64/sn/router.h - 1.3 linux/include/asm-ia64/sn/prio.h - 1.2 linux/include/asm-ia64/sn/pio.h - 1.3 linux/include/asm-ia64/sn/pci/pciio_private.h - 1.3 linux/include/asm-ia64/sn/pci/pciio.h - 1.3 linux/include/asm-ia64/sn/pci/pcibr_private.h - 1.4 linux/include/asm-ia64/sn/pci/pcibr.h - 1.4 linux/include/asm-ia64/sn/pci/pci_defs.h - 1.2 linux/include/asm-ia64/sn/pci/pci_bus_cvlink.h - 1.3 linux/include/asm-ia64/sn/pci/bridge.h - 1.3 linux/fs/reiserfs/super.c - 1.21 linux/arch/sparc64/kernel/pci_schizo.c - 1.14 linux/arch/arm/mach-integrator/pci.c - 1.5 linux/arch/arm/mach-integrator/pci_v3.c - 1.7 linux/include/asm-arm/proc-armo/pgalloc.h - 1.2 linux/include/asm-arm/proc-armv/pgalloc.h - 1.4 linux/include/asm-ia64/perfmon.h - 1.3 linux/include/asm-ia64/sn/pci/pciba.h - 1.2 linux/include/asm-ia64/sn/sn_sal.h - 1.2 linux/include/asm-ia64/sn/sv.h - 1.2 linux/arch/mips/defconfig-it8172 - 1.3 linux/arch/mips/defconfig-ddb5476 - 1.3 linux/arch/ia64/kernel/efivars.c - 1.5 linux/arch/ia64/sn/sn1/sv.c - 1.2 linux/arch/ia64/sn/sn1/sn1_ksyms.c - 1.2 linux/arch/ia64/sn/sn1/probe.c - 1.2 linux/arch/ia64/sn/sn1/error.c - 1.2 linux/arch/ia64/sn/io/pciba.c - 1.2 linux/arch/ia64/sn/io/huberror.c - 1.2 linux/fs/freevxfs/vxfs_super.c - 1.8 linux/drivers/media/radio/miropcm20-rds-core.c - 1.3 linux/drivers/media/radio/miropcm20-radio.c - 1.3 linux/fs/sysv/super.c - 1.10 linux/include/linux/cramfs_fs_sb.h - 1.2 linux/arch/ia64/kernel/sigframe.h - 1.3 linux/drivers/ide/ide-adma.c - 1.2 linux/drivers/ide/amd74xx.c - 1.5 linux/arch/arm/def-configs/jornada720 - 1.2 linux/arch/arm/mach-sa1100/cpu-sa1110.c - 1.4 linux/drivers/parport/parport_cs.c - 1.3 linux/fs/jffs2/Makefile - 1.5 linux/fs/jffs2/TODO - 1.2 linux/fs/jffs2/background.c - 1.8 linux/fs/jffs2/build.c - 1.2 linux/fs/jffs2/compr.c - 1.3 linux/fs/jffs2/compr_rtime.c - 1.2 linux/fs/jffs2/compr_rubin.c - 1.3 linux/fs/jffs2/compr_rubin.h - 1.2 linux/fs/jffs2/compr_zlib.c - 1.5 linux/fs/jffs2/comprtest.c - 1.2 linux/fs/jffs2/dir.c - 1.9 linux/fs/jffs2/erase.c - 1.6 linux/fs/jffs2/file.c - 1.6 linux/fs/jffs2/gc.c - 1.7 linux/fs/jffs2/malloc.c - 1.4 linux/fs/jffs2/nodelist.c - 1.5 linux/fs/jffs2/nodelist.h - 1.5 linux/fs/jffs2/nodemgmt.c - 1.5 linux/fs/jffs2/pushpull.c - 1.3 linux/fs/jffs2/pushpull.h - 1.3 linux/fs/jffs2/read.c - 1.4 linux/fs/jffs2/readinode.c - 1.5 linux/fs/jffs2/scan.c - 1.5 linux/fs/jffs2/super.c - 1.9 linux/fs/jffs2/symlink.c - 1.3 linux/fs/jffs2/write.c - 1.6 linux/include/linux/jffs2_fs_sb.h - 1.4 linux/include/linux/jffs2_fs_i.h - 1.3 linux/include/linux/jffs2.h - 1.3 linux/fs/namespace.c - 1.16 linux/drivers/pcmcia/sa1100_generic.c - 1.4 linux/arch/arm/mach-sa1100/pm.c - 1.4 linux/net/8021q/vlanproc.c - 1.6 linux/net/8021q/vlan_dev.c - 1.3 linux/net/8021q/vlan.h - 1.2 linux/net/8021q/vlan.c - 1.3 linux/include/linux/if_vlan.h - 1.2 linux/arch/arm/mm/proc-arm1020.S - 1.4 linux/arch/arm/mm/proc-arm926.S - 1.4 linux/fs/ext3/super.c - 1.12 linux/drivers/hotplug/pci_hotplug_core.c - 1.7 linux/fs/driverfs/inode.c - 1.10 linux/arch/arm/mm/proc-xscale.S - 1.4 linux/arch/arm/mm/proc-arm922.S - 1.3 linux/arch/arm/def-configs/iq80310 - 1.2 linux/arch/arm/mach-sa1100/system3.c - 1.4 linux/arch/arm/mach-iop310/iq80310-time.c - 1.3 linux/net/ipv4/tcp_diag.c - 1.3 linux/net/core/wireless.c - 1.2 linux/include/net/iw_handler.h - 1.2 linux/include/asm-sparc64/pil.h - 1.2 linux/fs/Config.help - 1.6 linux/drivers/ide/Config.help - 1.5 linux/include/asm-sparc64/thread_info.h - 1.2 linux/Documentation/filesystems/porting - 1.4 linux/arch/ppc/configs/k2_defconfig - 1.2 linux/arch/ppc/configs/menf1_defconfig - 1.2 linux/arch/ppc/configs/pplus_defconfig - 1.2 linux/arch/ppc/configs/sandpoint_defconfig - 1.2 linux/sound/oss/es1370.c - 1.2 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.3 linux/arch/ppc64/kernel/ioctl32.c - 1.2 linux/arch/arm/def-configs/badge4 - 1.2 linux/arch/arm/mm/copypage-v5te.S - 1.2 linux/arch/arm/mm/copypage-v4mc.S - 1.2 linux/arch/arm/mm/copypage-v4.S - 1.2 linux/arch/arm/mm/copypage-v3.S - 1.2 linux/arch/arm/mm/abort-lv4t.S - 1.2 linux/arch/arm/mm/abort-ev5ej.S - 1.2 linux/arch/arm/mm/abort-ev4t.S - 1.2 linux/arch/arm/mm/abort-ev4.S - 1.2 linux/fs/jfs/super.c - 1.2 linux/include/asm-arm/glue.h - 1.2 linux/drivers/pcmcia/sa1100_generic.h - 1.2 From owner-linux-xfs@oss.sgi.com Wed Mar 13 14:38:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2DMc1w05279 for linux-xfs-outgoing; Wed, 13 Mar 2002 14:38:01 -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 g2DMbs905247 for ; Wed, 13 Mar 2002 14:37:54 -0800 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Mar 2002 16:37:47 -0500 Message-ID: From: Murthy Kambhampaty To: "'Eric Sandeen'" Cc: linux-xfs@oss.sgi.com Subject: RE: xfs_copy Date: Wed, 13 Mar 2002 16:37:47 -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 NGPT, which is in 2.4.19pre3, aims to provide IRIX threading for Linux, so it may not be true for much longer that "Irix threading that has no Linux counterpart". From the NGPT page (http://oss.software.ibm.com/pthreads/): "Goals The goal of this project is to attempt to solve the problems associated with the use of the pthreads library on Linux. It will add M:N threading capability and improve significantly on the POSIX compliance of pthreads on Linux. This will allow significant performance improvements for all applications that make use of the pthreads library, particularly on SMP machines. It will also enable Linux to provide threading services that are more in line with the capabilities of the commerical Unix operating system such as IBM AIX and SGI IRIX." Murthy > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sgi.com] > Sent: Thursday, March 07, 2002 18:32 > To: Jason Joines > Cc: linux-xfs@oss.sgi.com > Subject: Re: xfs_copy > > > 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 Wed Mar 13 16:46:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2E0kbe19678 for linux-xfs-outgoing; Wed, 13 Mar 2002 16:46:37 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2E0kR919652 for ; Wed, 13 Mar 2002 16:46:27 -0800 Received: (qmail 29149 invoked by uid 500); 13 Mar 2002 23:45:54 -0000 Subject: RE: xfs_copy From: Austin Gonyou To: Murthy Kambhampaty Cc: "'Eric Sandeen'" , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 13 Mar 2002 17:45:54 -0600 Message-Id: <1016063154.28876.6.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Looking at the changelog, I don't see any NGPT. On Wed, 2002-03-13 at 15:37, Murthy Kambhampaty wrote: > NGPT, which is in 2.4.19pre3, aims to provide IRIX threading for Linux, > so > it may not be true for much longer that "Irix threading that has no > Linux > counterpart". From the NGPT page > (http://oss.software.ibm.com/pthreads/): > > "Goals > The goal of this project is to attempt to solve the problems associated > with > the use of the pthreads library on Linux. It will add M:N threading > capability and improve significantly on the POSIX compliance of pthreads > on > Linux. This will allow significant performance improvements for all > applications that make use of the pthreads library, particularly on SMP > machines. It will also enable Linux to provide threading services that > are > more in line with the capabilities of the commerical Unix operating > system > such as IBM AIX and SGI IRIX." > > Murthy > > > > > > -----Original Message----- > > From: Eric Sandeen [mailto:sandeen@sgi.com] > > Sent: Thursday, March 07, 2002 18:32 > > To: Jason Joines > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: xfs_copy > > > > > > 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. > > -- 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 13 21:50:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2E5oRx25888 for linux-xfs-outgoing; Wed, 13 Mar 2002 21:50:27 -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 g2E5oO925859 for ; Wed, 13 Mar 2002 21:50:24 -0800 Received: from bunnyh by banix with local (Exim 3.34 #1 (Debian)) id 16lO9Q-0001GF-00 for ; Thu, 14 Mar 2002 07:51:45 +0200 Date: Thu, 14 Mar 2002 07:51:44 +0200 To: linux-xfs@oss.sgi.com Subject: Kernel oops Message-ID: <20020314055144.GA4312@bunny.ihme.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i From: Juha K Kallio Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I got a kernel oops on the display this morning when i woke up. It had something about kupdated being killed, but i can't get the whole error, since it could't log anymore. Right after i tried to read my mail, it crashed. Strangely i could still exec binaries.. Any idea what might have caused this? From owner-linux-xfs@oss.sgi.com Wed Mar 13 21:58:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2E5w8S26155 for linux-xfs-outgoing; Wed, 13 Mar 2002 21:58:08 -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 g2E5w5926128 for ; Wed, 13 Mar 2002 21:58:05 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2E5xT6G032555 for ; Wed, 13 Mar 2002 21:59:29 -0800 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 g2E5wQA32493527; Wed, 13 Mar 2002 21:58:27 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 1329E3000BA; Thu, 14 Mar 2002 16:58:24 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id CA635BA; Thu, 14 Mar 2002 16:58:24 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Juha K Kallio Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel oops In-reply-to: Your message of "Thu, 14 Mar 2002 07:51:44 +0200." <20020314055144.GA4312@bunny.ihme.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Mar 2002 16:58:19 +1100 Message-ID: <29292.1016085499@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Mar 2002 07:51:44 +0200, Juha K Kallio wrote: >I got a kernel oops on the display this morning when i woke up. It had >something about kupdated being killed, but i can't get the whole error, >since it could't log anymore. >Right after i tried to read my mail, it crashed. Strangely i could still >exec binaries.. Any idea what might have caused this? To do any debugging we need the first oops (all of it) run through ksymoops. Without that plus your kernel version, XFS version, gcc etc., there is no hope of debugging this. From owner-linux-xfs@oss.sgi.com Wed Mar 13 23:50:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2E7ouL28118 for linux-xfs-outgoing; Wed, 13 Mar 2002 23:50:56 -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 g2E7op928090 for ; Wed, 13 Mar 2002 23:50:51 -0800 Received: from bunnyh by banix with local (Exim 3.34 #1 (Debian)) id 16lQ27-0000qX-00 for ; Thu, 14 Mar 2002 09:52:19 +0200 Date: Thu, 14 Mar 2002 09:52:18 +0200 To: linux-xfs@oss.sgi.com Subject: Re: Kernel oops Message-ID: <20020314075218.GA2662@bunny.ihme.org> References: <20020314055144.GA4312@bunny.ihme.org> <29292.1016085499@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29292.1016085499@kao2.melbourne.sgi.com> User-Agent: Mutt/1.3.27i From: Juha K Kallio Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 14, 2002 at 04:58:19PM +1100, Keith Owens wrote: > On Thu, 14 Mar 2002 07:51:44 +0200, > Juha K Kallio wrote: > >I got a kernel oops on the display this morning when i woke up. It had > >something about kupdated being killed, but i can't get the whole error, > >since it could't log anymore. > >Right after i tried to read my mail, it crashed. Strangely i could still > >exec binaries.. Any idea what might have caused this? > > To do any debugging we need the first oops (all of it) run through > ksymoops. Without that plus your kernel version, XFS version, gcc > etc., there is no hope of debugging this. > I've never had a kernel oops before, so I'm really not experienced in debugging. But I have /var/log/ksymoops and some files in there, do I have to do something with those? Strangely, some of them are dated three days back, I hadn't any problems before this morning. From owner-linux-xfs@oss.sgi.com Thu Mar 14 03:56:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EBuIp01846 for linux-xfs-outgoing; Thu, 14 Mar 2002 03:56:18 -0800 Received: from gateway.max-t.com (229.124.18.216.gt-est.net [216.18.124.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2EBuB901817 for ; Thu, 14 Mar 2002 03:56:11 -0800 Received: from smccauley by gateway.max-t.com with local (Exim 3.32 #3) id 16lTsp-0003t8-00; Thu, 14 Mar 2002 06:58:59 -0500 Date: Thu, 14 Mar 2002 06:58:59 -0500 From: Steeve McCauley To: Juha K Kallio Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel oops Message-ID: <20020314065859.A14883@max-t.com> References: <20020314055144.GA4312@bunny.ihme.org> <29292.1016085499@kao2.melbourne.sgi.com> <20020314075218.GA2662@bunny.ihme.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020314075218.GA2662@bunny.ihme.org>; from bunnyh@banix.ihme.org on Thu, Mar 14, 2002 at 09:52:18AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 14, 2002 at 09:52:18AM +0200, Juha K Kallio wrote: > On Thu, Mar 14, 2002 at 04:58:19PM +1100, Keith Owens wrote: > > On Thu, 14 Mar 2002 07:51:44 +0200, > > Juha K Kallio wrote: > > >I got a kernel oops on the display this morning when i woke up. It had > > >something about kupdated being killed, but i can't get the whole error, > > >since it could't log anymore. > > >Right after i tried to read my mail, it crashed. Strangely i could still > > >exec binaries.. Any idea what might have caused this? > > > > To do any debugging we need the first oops (all of it) run through > > ksymoops. Without that plus your kernel version, XFS version, gcc > > etc., there is no hope of debugging this. > > > > > I've never had a kernel oops before, so I'm really not experienced in > debugging. But I have /var/log/ksymoops and some files in there, do I > have to do something with those? Strangely, some of them are dated three > days back, I hadn't any problems before this morning. Check in /var/log/messages for the Oops. If it's there copy it to another file and run it through ksymoops. Make sure that System.map is symlinked to the correct System.map-xxx file in /boot, normally this will be true while running the same kernel that caused the oops. See ksymoops manpage for details. It's possible that the oops was not written to the syslog though and if that's the case and you do not have a photograhpic memory, you'll have to wait until it happens again (type in the oops or write it down, painful but the fs programmers will find it invaluable in tracing the cause of the oops.) -- Steeve McCauley Maximum Throughput Programmer & Team Leader smccauley@max-t.com :wq From owner-linux-xfs@oss.sgi.com Thu Mar 14 07:32:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EFWr406847 for linux-xfs-outgoing; Thu, 14 Mar 2002 07:32:53 -0800 Received: from hermes.math.u-bordeaux.fr (math2.math.duke.edu [152.3.25.212]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2EFWi906818 for ; Thu, 14 Mar 2002 07:32:44 -0800 Received: from math.u-bordeaux.fr (localhost.localdomain [127.0.0.1]) by hermes.math.u-bordeaux.fr (8.11.2/8.11.2) with ESMTP id g2E9Xfr05018; Thu, 14 Mar 2002 10:33:41 +0100 X-Mozilla-Status: 0801 Message-ID: <3C8FB49C.5040306@math.u-bordeaux.fr> Date: Wed, 13 Mar 2002 21:20:44 +0100 From: Qing Liu Organization: CNRS, =?ISO-8859-1?Q?Universit=E9?= Bordeaux 1 User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.18 i686; en-US; 0.7) Gecko/20010316 X-Accept-Language: French, fr, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Odd behavior of xfs with SCSI/Adaptec AIC7899 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I did a very simple test sometimes ago on deleting files and found that it is much slower on SCSI than on IDE drive ! Box 1: Bi-Pentium III 1Ghz, 256 MB Ram, hard drive SCSI FUJITSU UW2, 18 GB, Adaptec AIC 7899, hdparm -t /dev/sda: 52.89 MB/sec Test partition is /dev/sda3, 5.9 GB. Software: RedHat 7.2, with vanilla kernel 2.4.16 + patches xfs-2.4.16-all-i386 and jfs-1.0.14, compiled with egcs 1.1.2. Test partition is /dev/sda3, 5.9 GB. Box 2: Duron 700 Mhz, 128 Mo, hard drive IDE Western Digital Udma66, 20 GB hdparm -t 20.98 MB/sec. Test partition is /dev/hda10, 3.6 GB. Software: Slackware 8.0, vanilla kernel 2.4.16 + patches xfs-2.4.16-all-i386 and jfs-1.0.14, compiled with gcc-2.95.3. The test consist in formatting the test partition, copying the source of the kernel into the test partition, umounting the partition, and then deleting the copied source tree. Results of time rm -rf /testfs/LINUX; time sync Box 1: --------------------------------------------------------------------------------- ext2 ext3 reiserfs xfs jfs --------------------------------------------------------------------------------- real 6.972s 7.245s 3.086s 1m17.333s 48.510s user 0.020s 0.010s 0.050s 0.070s 0.030s sys 0.180s 0.540s 1.210s 2.640s 0.800s sync real 0.616s 0.569s 0.165s 0.014s 0.039s --------------------------------------------------------------------------------- Box 2: --------------------------------------------------------------------------------- ext2 ext3 reiserfs xfs jfs --------------------------------------------------------------------------------- real 4.907s 7.416 4.242s 15.415s 15.005s user 0.050s 0.020 0.060s 0.120s 0.110s sys 0.230s 0.820 1.480s 3.610s 0.960s ---------------------------------------------------------------------------------- The test had been running several times with comparable output. I known xfs is rather slow when deleting large number of files (above 11,000 here). But it is rather surprising that it performs *much worse* on a much better machine. The problem is same with a mono processor kernel on Box 1. Is there a known issue here ? Liu From owner-linux-xfs@oss.sgi.com Thu Mar 14 07:40:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EFeFP07117 for linux-xfs-outgoing; Thu, 14 Mar 2002 07:40:15 -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 g2EFeC907089 for ; Thu, 14 Mar 2002 07: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 g2EFfZ6G015045 for ; Thu, 14 Mar 2002 07:41:36 -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 JAA54713; Thu, 14 Mar 2002 09:41:35 -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 JAA36115; Thu, 14 Mar 2002 09:41:35 -0600 (CST) Date: Thu, 14 Mar 2002 09:41:35 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Qing Liu cc: Subject: Re: Odd behavior of xfs with SCSI/Adaptec AIC7899 In-Reply-To: <3C8FB49C.5040306@math.u-bordeaux.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Mar 2002, Qing Liu wrote: > Hello, > > I did a very simple test sometimes ago on deleting files and found that it > is much slower on SCSI than on IDE drive ! From owner-linux-xfs@oss.sgi.com Thu Mar 14 07:40:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EFeUK07248 for linux-xfs-outgoing; Thu, 14 Mar 2002 07:40: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 g2EFeL907169 for ; Thu, 14 Mar 2002 07:40:21 -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 g2EFfi6G015051 for ; Thu, 14 Mar 2002 07:41:45 -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 JAA53599; Thu, 14 Mar 2002 09:41:44 -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 JAA60175; Thu, 14 Mar 2002 09:41:44 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2EFeRG05679; Thu, 14 Mar 2002 09:40:27 -0600 Subject: Re: Odd behavior of xfs with SCSI/Adaptec AIC7899 From: Steve Lord To: Qing Liu Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C8FB49C.5040306@math.u-bordeaux.fr> References: <3C8FB49C.5040306@math.u-bordeaux.fr> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 14 Mar 2002 09:40:27 -0600 Message-Id: <1016120427.5053.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, first of all, turn off write caching on the ide device and try again, it will get a lot slower: hdparm -W 0 /dev/hda Second, get a recent xfs kernel, delete speed has been improved. Steve On Wed, 2002-03-13 at 14:20, Qing Liu wrote: > Hello, > > I did a very simple test sometimes ago on deleting files and found that it > is much slower on SCSI than on IDE drive ! > > Box 1: Bi-Pentium III 1Ghz, 256 MB Ram, hard drive SCSI FUJITSU UW2, 18 GB, > Adaptec AIC 7899, hdparm -t /dev/sda: 52.89 MB/sec > Test partition is /dev/sda3, 5.9 GB. > Software: RedHat 7.2, with vanilla kernel 2.4.16 + patches xfs-2.4.16-all-i386 > and jfs-1.0.14, compiled with egcs 1.1.2. Test partition is /dev/sda3, 5.9 GB. > > Box 2: Duron 700 Mhz, 128 Mo, hard drive IDE Western Digital Udma66, 20 GB > hdparm -t 20.98 MB/sec. Test partition is /dev/hda10, 3.6 GB. > Software: Slackware 8.0, vanilla kernel 2.4.16 + patches xfs-2.4.16-all-i386 > and jfs-1.0.14, compiled with gcc-2.95.3. > > > The test consist in formatting the test partition, copying the source of the > kernel into the test partition, umounting the partition, and then > deleting the copied source tree. > > Results of time rm -rf /testfs/LINUX; time sync > > Box 1: > > --------------------------------------------------------------------------------- > ext2 ext3 reiserfs xfs jfs > --------------------------------------------------------------------------------- > real 6.972s 7.245s 3.086s 1m17.333s 48.510s > user 0.020s 0.010s 0.050s 0.070s 0.030s > sys 0.180s 0.540s 1.210s 2.640s 0.800s > sync real 0.616s 0.569s 0.165s 0.014s 0.039s > --------------------------------------------------------------------------------- > > Box 2: > > --------------------------------------------------------------------------------- > ext2 ext3 reiserfs xfs jfs > --------------------------------------------------------------------------------- > real 4.907s 7.416 4.242s 15.415s 15.005s > user 0.050s 0.020 0.060s 0.120s 0.110s > sys 0.230s 0.820 1.480s 3.610s 0.960s > ---------------------------------------------------------------------------------- > > The test had been running several times with comparable output. > > I known xfs is rather slow when deleting large number of files (above 11,000 > here). But it is rather surprising that it performs *much worse* on a much > better machine. The problem is same with a mono processor kernel on Box 1. > > Is there a known issue here ? > > Liu > > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Mar 14 07:42:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EFgGq07414 for linux-xfs-outgoing; Thu, 14 Mar 2002 07:42:16 -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 g2EFgD907388 for ; Thu, 14 Mar 2002 07:42: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 g2EFhb6G015124 for ; Thu, 14 Mar 2002 07:43:37 -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 JAA54746; Thu, 14 Mar 2002 09:43:36 -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 JAA24823; Thu, 14 Mar 2002 09:43:36 -0600 (CST) Date: Thu, 14 Mar 2002 09:43:36 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Qing Liu cc: Subject: Re: Odd behavior of xfs with SCSI/Adaptec AIC7899 In-Reply-To: <3C8FB49C.5040306@math.u-bordeaux.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Mar 2002, Qing Liu wrote: > Hello, > > I did a very simple test sometimes ago on deleting files and found that it > is much slower on SCSI than on IDE drive ! (whoops sorry for the previous non-answer!) Do you have IDE write caching enabled? -Eric From owner-linux-xfs@oss.sgi.com Thu Mar 14 07:48:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EFmZB07656 for linux-xfs-outgoing; Thu, 14 Mar 2002 07:48:35 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2EFmV907615 for ; Thu, 14 Mar 2002 07:48:31 -0800 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2EFnvXv076744; Thu, 14 Mar 2002 16:49:57 +0100 (CET) Message-Id: <4.3.2.7.2.20020314164757.054b89f8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Mar 2002 16:50:02 +0100 To: Qing Liu , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Odd behavior of xfs with SCSI/Adaptec AIC7899 In-Reply-To: <3C8FB49C.5040306@math.u-bordeaux.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 21:20 13-3-2002 +0100, Qing Liu wrote: >Hello, > >I known xfs is rather slow when deleting large number of files (above >11,000 here). But it is rather surprising that it performs *much worse* on >a much >better machine. The problem is same with a mono processor kernel on Box 1. > >Is there a known issue here ? Try using 2.4.18 XFS CVS. This tree has the asynchronous delete path and that alone might give your delete speed a nice boost. I won't say this will fix your problem but it will make a difference. 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 Thu Mar 14 07:58:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EFwMf08016 for linux-xfs-outgoing; Thu, 14 Mar 2002 07:58:22 -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 g2EFw8907985 for ; Thu, 14 Mar 2002 07:58:09 -0800 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Mar 2002 10:59:32 -0500 Message-ID: From: Murthy Kambhampaty To: "'linux-xfs@oss.sgi.com'" Cc: "'dmc@austin.ibm.com'" Subject: RE: xfs_copy Date: Thu, 14 Mar 2002 10:59: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 The patches my Dave McCracken are the kernel code needed to support NGTP (M:N threading). The userspace tools are available at the website my earlier msg. pointed to. I suppose it is more accurate to say NGPT is >supported< in 2.4.19pre3 than to say that it is "in"; at any rate IRIX-like threading facilities are coming to linux soon. (Now I'm begginning to sound like I'm marketing NGPT, sorry.) If there is an interest in porting XFS code that relies on NGPT, I'd be happy to be a tester (wish I could offer more, but my programming sills are limited to high level languages for numerical/statistical analysis I'm afraid). Murthy > -----Original Message----- > From: Austin Gonyou [mailto:austin@coremetrics.com] > Sent: Wednesday, March 13, 2002 18:46 > To: Murthy Kambhampaty > Cc: 'Eric Sandeen'; linux-xfs@oss.sgi.com > Subject: RE: xfs_copy > > > Looking at the changelog, I don't see any NGPT. > > On Wed, 2002-03-13 at 15:37, Murthy wrote: > > NGPT, which is in 2.4.19pre3, aims to provide IRIX > threading for Linux, > > so > > it may not be true for much longer that "Irix threading that has no > > Linux > > counterpart". From the NGPT page > > (http://oss.software.ibm.com/pthreads/): > > > > "Goals > > The goal of this project is to attempt to solve the > problems associated > > with > > the use of the pthreads library on Linux. It will add M:N > threading > > capability and improve significantly on the POSIX > compliance of pthreads > > on > > Linux. This will allow significant performance > improvements for all > > applications that make use of the pthreads library, > particularly on SMP > > machines. It will also enable Linux to provide threading > services that > > are > > more in line with the capabilities of the commerical Unix operating > > system > > such as IBM AIX and SGI IRIX." > > > > Murthy > > > > > > > > > > > -----Original Message----- > > > From: Eric Sandeen [mailto:sandeen@sgi.com] > > > Sent: Thursday, March 07, 2002 18:32 > > > To: Jason Joines > > > Cc: linux-xfs@oss.sgi.com > > > Subject: Re: xfs_copy > > > > > > > > > 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. > > > > -- > 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 Thu Mar 14 08:03:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EG3aN08310 for linux-xfs-outgoing; Thu, 14 Mar 2002 08:03:36 -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 g2EG3N908282 for ; Thu, 14 Mar 2002 08:03:24 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 239A9C001CA; Fri, 15 Mar 2002 00:04:50 +0800 (PHT) Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id BEBFAC001C7; Fri, 15 Mar 2002 00:04:44 +0800 (PHT) Received: from 192.168.0.1 ( [192.168.0.1]) as user jijo@127.0.0.1 by horde.leathercollection.ph with HTTP; Fri, 15 Mar 2002 00:04:44 +0800 Message-ID: <1016121884.3c90ca1ca95a8@horde.leathercollection.ph> Date: Fri, 15 Mar 2002 00:04:44 +0800 From: Federico Sevilla III To: wolfgang.glas@ev-i.at Cc: linux-xfs@oss.sgi.com, samba@lists.samba.org Subject: Re: Oplocks problems with samba. References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 192.168.0.1 X-Organization: The Leather Collection, Inc. X-Virus-Scanned: by AMaViS perl-11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Wolfgang, (cc Linux XFS list) (cc Samba list) Quoting wolfgang.glas@ev-i.at: > I just found you message in the samba mailing list archives and foiund > out, that we have a very similar problem. We are using samba-2.2.1a on a > kerenl-2.4.16 and we use reiserfs. > We also experience data corruption with messages like: > > [2002/03/14 15:15:26, 0] > smbd/oplock_linux.c:linux_release_kernel_oplock(211) > release_kernel_oplock: Error when removing kernel oplock on file > Allplot/PRJ/n0000329.prj/tb000264.000, dev = 3a06, inode = 65854. Error > was Bad file descriptor Do you get this error only when simultaneously working on files via NFS? Or also when NFS is inactive and it is only Samba at work? We are currently using Samba 2.2.3a with Linux kernel 2.4.18-xfs. By disabling oplocks completely we have gotten rid of the oplock_break problems that I reported, and so far have not had a single issue of data corruption. The speed penalty has gone relatively unnoticed, but perhaps this is because our server is very well-equipped relative to the workstation demands and usage patterns. > We also found, that transferring large files over samba over NFS to server > completely locks the network for seconds, as if a kernel thread has been > locked. Finally, I compared reiserfs/jfs/ and ext3 and found out, that > only ext3 is fully interoperable with NFS and samba. So you should also > check at your site, if the third party FS (in your case XFS) causes the > problem. I am sending the XFS list a copy of this reply. It's interesting to note the interoprability problems with NFS and Samba with ReiserFS, JFS, and perhaps XFS. I cannot be sure about XFS because the NFS installation in our system does not "cover" the data files of Samba, where the corruption occurs. We have NFS that is used to export /home. Otherwise the only way to get to the data through the network is via Samba. > If it does, I think we should join our forces to report the problem to the > kernel/reiserfs/jfs/xfs mailing lists, because I get the impression, that there > are some severe problems with 3rd party filesystems in the 2.4.x Kernels > related to NFS/samba/oplocks. (Unfortunately, I'm not a kernel hacker, but > hopefully we reach an informed person on any of these channels). I have quoted your message in full, in the hopes that people on both the Samba and XFS lists will get hints and maybe people with similar problems can chime in. --> Jijo > Regards, > > Wolfgang > > -- > Dr. Wolfgang Glas EV-i Informationstechnologie > GmbH. > Geschäftsführer Sebastian-Kneipp-Weg 17 > Wolfgang.Glas@ev-i.at A-6020 Innsbruck/Austria > phone: ++43-512-284883-2 fax: ++43-512-281624-31 -- 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 Thu Mar 14 08:10:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EGAgd08527 for linux-xfs-outgoing; Thu, 14 Mar 2002 08:10:42 -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 g2EGAV908501 for ; Thu, 14 Mar 2002 08:10:32 -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 g2EGBwH19447; Thu, 14 Mar 2002 16:11:58 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 g2EGBSg12725; Thu, 14 Mar 2002 16:11:28 GMT Message-ID: <3C90CBB0.26A52000@soton.ac.uk> Date: Thu, 14 Mar 2002 16:11:28 +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, idh@soton.ac.uk 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 for the patch (vnode.patch) and sorry for the delay, we've had a week or so of stability on this server so haven't had chance to install the patched kernel. However, managed to fit it into a regular maintenance period yesterday, though I soon ran into (what I believe was) the bug reported by Dave Alden and fixed by you/Eric Sandeen (thanks!) of NFS hangs (page_buf_io.c) (though it was not quite as reproducible as it seemed to be for Dave) - anyway updated to the latest CVS tree (as of ~ 12:00GMT 13th March) + the patch you sent me last week and so far so good! As I indicated before I have seen upto 14 days between crashes so its a bit early to tell if its fixed my problem but at least its run for >24hrs now without any noticeable bad effects. Regards and thanks. Ian Hardy On 06 Mar 2002 13:12:19 -0600 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 Mobile: 0709 2127503 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 Thu Mar 14 08:57:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EGvDa14668 for linux-xfs-outgoing; Thu, 14 Mar 2002 08:57:13 -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 g2EGv4914641 for ; Thu, 14 Mar 2002 08:57:04 -0800 Received: from securities.com (IDENT:root@localhost [127.0.0.1]) by dns.securities.com (8.11.6/8.11.6) with ESMTP id g2EGwVx23367 for ; Thu, 14 Mar 2002 11:58:31 -0500 Message-ID: <3C90D5F2.9030607@securities.com> Date: Thu, 14 Mar 2002 11:55:14 -0500 From: Benito Venegas User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_repair problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi boys and girls: I have a problem in one my servers in India. Local sysadmin lost access to /dev/sdb1 partition after blackout :/ Device Boot Start End Blocks Id System /dev/sdb1 1 13215 106149456 83 Linux The problem came to us, when local sysadmin in India had an old kernel version. (2.4.2) He traid to run xfs_reapir but after 10 minutes running, it gave this error xfs_repair:buf calloc failed cannot allocate memrory After that, I upgreaded kernel version and tools. We ran xfs_repair in single mode and now we got this message: xfs_repair running in single mode. waiting for any message..... error message: fatal error -- can't read block 0 for directory 210516126 We don't want to run xfs_repair with -L switch option, to avoid loose important information (we do backups but runs once a day, and this happend before backup process :/ ) Doctors, any idea about if I can save this patient? :/ Thanks DELL PE4300 2 CPU Perc Card (megaraid.o module) OS: RH 7.1 Current kernel version: 2.4.9-13SGI_XFS_1.0.2smp Previous kernel version: 2.4.2-SGI_XFS_1.0smp -- Benito 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 Thu Mar 14 12:00:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EK06m06808 for linux-xfs-outgoing; Thu, 14 Mar 2002 12:00:06 -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 g2EK03906782 for ; Thu, 14 Mar 2002 12:00: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 g2EK1Q6G026130 for ; Thu, 14 Mar 2002 12:01:27 -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 OAA58522 for ; Thu, 14 Mar 2002 14:01: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 OAA67663 for ; Thu, 14 Mar 2002 14:01:26 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2EK08O27767; Thu, 14 Mar 2002 14:00:08 -0600 Message-Id: <200203142000.g2EK08O27767@jen.americas.sgi.com> Date: Thu, 14 Mar 2002 14:00:08 -0600 Subject: TAKE - gcc 3.1 compiler fix To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Mar 14 12:01:00 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-newpagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:114162a linux/fs/xfs/linux/xfs_super.c - 1.162 - Compiler fix for gcc 3.1, remove call to fss From owner-linux-xfs@oss.sgi.com Thu Mar 14 11:58:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EJwQu06663 for linux-xfs-outgoing; Thu, 14 Mar 2002 11:58:26 -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 g2EJwM906637 for ; Thu, 14 Mar 2002 11:58:22 -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 g2EJxk6G026081 for ; Thu, 14 Mar 2002 11:59:46 -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 NAA58268 for ; Thu, 14 Mar 2002 13:59:45 -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 NAA40437 for ; Thu, 14 Mar 2002 13:59:45 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2EJwRM27690; Thu, 14 Mar 2002 13:58:27 -0600 Message-Id: <200203141958.g2EJwRM27690@jen.americas.sgi.com> Date: Thu, 14 Mar 2002 13:58:27 -0600 Subject: TAKE - do not factor stripe size in to st_blocksize To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk An md volume was confusing user space applications with a large blocksize being reported, just report the filesystem iosize instead, defaults to blocksize. Date: Thu Mar 14 11:58:22 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-newpagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:114161a linux/fs/xfs/xfs_vnodeops.c - 1.518 - Do not report stripesize back in st_blocksize - it confuses applications on linux. From owner-linux-xfs@oss.sgi.com Thu Mar 14 12:03:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EK30E07042 for linux-xfs-outgoing; Thu, 14 Mar 2002 12:03:00 -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 g2EK2v907016 for ; Thu, 14 Mar 2002 12:02: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 g2EK4K6G026238 for ; Thu, 14 Mar 2002 12:04:20 -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 OAA58918 for ; Thu, 14 Mar 2002 14:04: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 OAA61675 for ; Thu, 14 Mar 2002 14:04:20 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2EK31D27848; Thu, 14 Mar 2002 14:03:01 -0600 Message-Id: <200203142003.g2EK31D27848@jen.americas.sgi.com> Date: Thu, 14 Mar 2002 14:03:01 -0600 Subject: TAKE - make open return EFBIG in some cases To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This gets xfs behavior closer to other linux filesystems. Date: Thu Mar 14 12:03:21 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-newpagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:114164a linux/fs/xfs/linux/xfs_file.c - 1.59 - Make open on an xfs filesystem report EFBIG if an inode is too large for a non O_LARGEFILE open. From owner-linux-xfs@oss.sgi.com Thu Mar 14 14:18:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EMIQZ09616 for linux-xfs-outgoing; Thu, 14 Mar 2002 14:18:26 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2EMIK909589 for ; Thu, 14 Mar 2002 14:18:20 -0800 Received: (qmail 1728 invoked by uid 500); 14 Mar 2002 22:19:14 -0000 Subject: Re: Odd behavior of xfs with SCSI/Adaptec AIC7899 From: Austin Gonyou To: Seth Mos Cc: Qing Liu , linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20020314164757.054b89f8@pop.xs4all.nl> References: <4.3.2.7.2.20020314164757.054b89f8@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 14 Mar 2002 16:19:14 -0600 Message-Id: <1016144354.1700.0.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It's very odd that you have this problem. I've not seen it be that bad ever. I deal with files between 2 and 8gb in size. On Thu, 2002-03-14 at 09:50, Seth Mos wrote: > At 21:20 13-3-2002 +0100, Qing Liu wrote: > >Hello, > > > >I known xfs is rather slow when deleting large number of files (above > >11,000 here). But it is rather surprising that it performs *much worse* > on > >a much > >better machine. The problem is same with a mono processor kernel on Box > 1. > > > >Is there a known issue here ? > > Try using 2.4.18 XFS CVS. This tree has the asynchronous delete path and > > that alone might give your delete speed a nice boost. I won't say this > will > fix your problem but it will make a difference. > > 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. -- 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 Thu Mar 14 14:58:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2EMwwZ10649 for linux-xfs-outgoing; Thu, 14 Mar 2002 14:58: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 g2EMwk910620 for ; Thu, 14 Mar 2002 14:58:47 -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 g2F080kw027548 for ; Thu, 14 Mar 2002 18:08:01 -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 JAA29563; Fri, 15 Mar 2002 09:58:51 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA55867; Fri, 15 Mar 2002 09:58:49 +1100 (AEDT) Date: Fri, 15 Mar 2002 09:58:49 +1100 From: Nathan Scott To: Benito Venegas Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair problem Message-ID: <20020315095849.O24252@wobbly.melbourne.sgi.com> References: <3C90D5F2.9030607@securities.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C90D5F2.9030607@securities.com>; from venevene@securities.com on Thu, Mar 14, 2002 at 11:55:14AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 14, 2002 at 11:55:14AM -0500, Benito Venegas wrote: > Hi boys and girls: > hi there Benito, > I have a problem in one my servers in India. > Local sysadmin lost access to /dev/sdb1 partition > after blackout :/ Does that mean it failed to mount after the blackout? Was there a syslog message, if so? > Device Boot Start End Blocks Id System > /dev/sdb1 1 13215 106149456 83 Linux > > The problem came to us, when local sysadmin in India had an old kernel > version. (2.4.2) > > He traid to run xfs_reapir but after 10 minutes running, it gave this error > > xfs_repair:buf calloc failed cannot allocate memrory > > After that, I upgreaded kernel version and tools. > We ran xfs_repair in single mode and now we got this message: > > xfs_repair running in single mode. waiting for any message..... > error message: > fatal error -- can't read block 0 for directory 210516126 [is "single mode" the same as "single-user mode"?] Both of these error messages suggest that xfs_repair is running out of memory. > We don't want to run xfs_repair with -L switch option, to avoid loose > important information (we do backups but runs once a day, and this > happend before backup process :/ ) >From your description above, it sounds like -L will not be useful to you (xfs_repair will tell you when the -L option could be useful). > Doctors, any idea about if I can save this patient? > :/ > Can you send the full xfs_repair output, and see whether there's anything else chewing up memory while xfs_repair is running, or whether xfs_repair itself is the cause (run "top" while xfs_repair is running, and keep an eye on memory use). If you can cut and paste all the output/save to a file and then send it to us, that will be a help. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 14 15:57:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ENvx011898 for linux-xfs-outgoing; Thu, 14 Mar 2002 15:57:59 -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 g2ENvm911872 for ; Thu, 14 Mar 2002 15:57:49 -0800 Received: from idcomm.com (IDENT:vlP/daGMnrzjzbGwumCMR1qSY5BigN9J@k56-pip73.idcomm.com [209.60.72.200] (may be forged)) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g2F09Ux05547 for ; Thu, 14 Mar 2002 17:09:30 -0700 Message-ID: <3C913961.2E084BFA@idcomm.com> Date: Thu, 14 Mar 2002 16:59:29 -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 To: "XFS: linux-xfs@oss.sgi.com" Subject: CVS 2.4.x update Q. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've done a recent cvs checkout for linux-2.4-xfs, and saw some TAKE messages in the email during the checkout (it was a slow checkout...on a 56k modem), so I also ran cvs update after: cvs -q -z 7 update -P -C -d -R I had some access errors, which I suspect do not matter. I'm sending a copy of those just to confirm this. FYI, I am on the email list, no need to reply-all. D. Stimits, stimits@idcomm.com cvs server: cannot open directory /cvs/linux-2.4-xfs/cmd/acl/man/man2: No such file or directory cvs server: skipping directory cmd/acl/man/man2 cvs server: cannot open directory /cvs/linux-2.4-xfs/cmd/acl/man/man3: No such file or directory cvs server: skipping directory cmd/acl/man/man3 cvs server: cannot open directory /cvs/linux-2.4-xfs/linux/arch/s390/tools: No such file or directory cvs server: skipping directory linux/arch/s390/tools cvs server: cannot open directory /cvs/linux-2.4-xfs/linux/arch/s390x/tools: No such file or directory cvs server: skipping directory linux/arch/s390x/tools cvs server: cannot open directory /cvs/linux-2.4-xfs/linux/drivers/acpi/common: No such file or directory cvs server: skipping directory linux/drivers/acpi/common cvs server: cannot open directory /cvs/linux-2.4-xfs/linux/drivers/acpi/interpreter: No such file or directory cvs server: skipping directory linux/drivers/acpi/interpreter cvs server: cannot open directory /cvs/linux-2.4-xfs/linux/drivers/i2o: No such file or directory cvs server: skipping directory linux/drivers/i2o cvs server: cannot open directory /cvs/linux-2.4-xfs/linux/fs/cramfs/inflate: No such file or directory cvs server: skipping directory linux/fs/cramfs/inflate cvs server: cannot open directory /cvs/linux-2.4-xfs/linux/fs/pagebuf: No such file or directory cvs server: skipping directory linux/fs/pagebuf cvs server: cannot open directory /cvs/linux-2.4-xfs/linux/fs/xfs/dmapi: No such file or directory cvs server: skipping directory linux/fs/xfs/dmapi cvs server: cannot open directory /cvs/linux-2.4-xfs/linux/net/irda/compressors: No such file or directory cvs server: skipping directory linux/net/irda/compressors From owner-linux-xfs@oss.sgi.com Thu Mar 14 16:05:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2F05BO12180 for linux-xfs-outgoing; Thu, 14 Mar 2002 16:05:11 -0800 Received: from mta1-rme.xtra.co.nz (mta1-rme.xtra.co.nz [210.86.15.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2F057912153 for ; Thu, 14 Mar 2002 16:05:07 -0800 Received: from localhost.localdomain ([210.86.52.159]) by mta1-rme.xtra.co.nz with ESMTP id <20020315000628.OHAH8792.mta1-rme.xtra.co.nz@localhost.localdomain> for ; Fri, 15 Mar 2002 13:06:28 +1300 Subject: RE: xfs_copy From: mdew To: xfs In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Mar 2002 13:06:23 +1300 Message-Id: <1016150788.3118.35.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-03-15 at 04:59, Murthy Kambhampaty wrote: > If there is an interest in porting XFS code that relies on NGPT, I'd be > happy to be a tester (wish I could offer more, but my programming sills are > limited to high level languages for numerical/statistical analysis I'm > afraid). and your spelling skills... ;) -- 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 Thu Mar 14 16:34:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2F0YlX12895 for linux-xfs-outgoing; Thu, 14 Mar 2002 16:34: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 g2F0YW912868 for ; Thu, 14 Mar 2002 16:34:32 -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 g2F0Zr6G004613 for ; Thu, 14 Mar 2002 16:35:55 -0800 Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA00304; Fri, 15 Mar 2002 11:34:26 +1100 Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA03550; Fri, 15 Mar 2002 11:34:24 +1100 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Fri, 15 Mar 2002 11:34:24 +1100 From: Ivan Rayner X-X-Sender: ivanr@omen.melbourne.sgi.com To: Murthy Kambhampaty cc: "'linux-xfs@oss.sgi.com'" Subject: RE: xfs_copy 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 Thu, 14 Mar 2002, Murthy Kambhampaty wrote: > The patches my Dave McCracken are the kernel code needed to support NGTP > (M:N threading). The userspace tools are available at the website my earlier > msg. pointed to. > > I suppose it is more accurate to say NGPT is >supported< in 2.4.19pre3 than > to say that it is "in"; at any rate IRIX-like threading facilities are > coming to linux soon. (Now I'm begginning to sound like I'm marketing NGPT, > sorry.) The IRIX threading problem we have is not so much with kernel support, but the userspace libraries. xfsdump uses the IRIX sproc/arena model rather than pthreads. Ivan > If there is an interest in porting XFS code that relies on NGPT, I'd be > happy to be a tester (wish I could offer more, but my programming sills are > limited to high level languages for numerical/statistical analysis I'm > afraid). > > Murthy > > > -----Original Message----- > > From: Austin Gonyou [mailto:austin@coremetrics.com] > > Sent: Wednesday, March 13, 2002 18:46 > > To: Murthy Kambhampaty > > Cc: 'Eric Sandeen'; linux-xfs@oss.sgi.com > > Subject: RE: xfs_copy > > > > > > Looking at the changelog, I don't see any NGPT. > > > > On Wed, 2002-03-13 at 15:37, Murthy wrote: > > > NGPT, which is in 2.4.19pre3, aims to provide IRIX > > threading for Linux, > > > so > > > it may not be true for much longer that "Irix threading that has no > > > Linux > > > counterpart". From the NGPT page > > > (http://oss.software.ibm.com/pthreads/): > > > > > > "Goals > > > The goal of this project is to attempt to solve the > > problems associated > > > with > > > the use of the pthreads library on Linux. It will add M:N > > threading > > > capability and improve significantly on the POSIX > > compliance of pthreads > > > on > > > Linux. This will allow significant performance > > improvements for all > > > applications that make use of the pthreads library, > > particularly on SMP > > > machines. It will also enable Linux to provide threading > > services that > > > are > > > more in line with the capabilities of the commerical Unix operating > > > system > > > such as IBM AIX and SGI IRIX." > > > > > > Murthy > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Eric Sandeen [mailto:sandeen@sgi.com] > > > > Sent: Thursday, March 07, 2002 18:32 > > > > To: Jason Joines > > > > Cc: linux-xfs@oss.sgi.com > > > > Subject: Re: xfs_copy > > > > > > > > > > > > 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. > > > > > > -- > > 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 > > > -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Thu Mar 14 22:01:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2F61ft18374 for linux-xfs-outgoing; Thu, 14 Mar 2002 22:01:41 -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 g2F61X918348 for ; Thu, 14 Mar 2002 22:01:33 -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 g2F72uBA012651 for ; Thu, 14 Mar 2002 23:02:57 -0800 Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA89781 for linux-xfs@oss.sgi.com; Fri, 15 Mar 2002 17:01:39 +1100 (EST) Date: Fri, 15 Mar 2002 17:01:39 +1100 (EST) From: Timothy Shimmin Message-Id: <200203150601.RAA89781@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 Mar 14 22:01:08 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:114212a cmd/xfsdump/doc/inventory.gif - 1.1 - Block diagram of inventory data layout. cmd/xfsdump/doc/inventory.obj - 1.1 - Block diagram of inventory data layout. cmd/xfsdump/doc/xfsdump.html - 1.7 - Minor corrections and rearrangement - move partial registry info to the xfsrestore section. Add reference to inventory diagram. From owner-linux-xfs@oss.sgi.com Thu Mar 14 23:36:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2F7ahU19891 for linux-xfs-outgoing; Thu, 14 Mar 2002 23:36:43 -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 g2F7ad919859 for ; Thu, 14 Mar 2002 23:36:39 -0800 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16lmDx-0000iL-00 for linux-xfs@oss.sgi.com; Fri, 15 Mar 2002 08:34:01 +0100 From: "Ralf G. R. Bergs" To: "XFS: linux-xfs@oss.sgi.com" Date: Fri, 15 Mar 2002 08:33:59 +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: <3C913961.2E084BFA@idcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: CVS 2.4.x update Q. Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 14 Mar 2002 16:59:29 -0700, D. Stimits wrote: >I had some access errors, which I suspect do not matter. You're right, they don't matter. They just mean that you still have a local copy of what has already been removed on the CVS server. -- 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 15 01:49:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2F9nhJ22163 for linux-xfs-outgoing; Fri, 15 Mar 2002 01:49:43 -0800 Received: from gk.ka.epigenomics.net (qmailr@gk.ka.epigenomics.net [62.159.77.106]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2F9nb922133 for ; Fri, 15 Mar 2002 01:49:37 -0800 Received: (qmail 23536 invoked from network); 15 Mar 2002 09:51:03 -0000 Received: from einstein.epigenomics.epi (qmailr@192.168.1.4) by weinberg.epigenomics.epi with SMTP; 15 Mar 2002 09:51:03 -0000 Received: (qmail 26462 invoked from network); 15 Mar 2002 09:51:02 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by einstein.epigenomics.epi with SMTP; 15 Mar 2002 09:51:02 -0000 Received: (qmail 29374 invoked by uid 9); 15 Mar 2002 09:51:02 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: force_shutdown experienced Date: Fri, 15 Mar 2002 09:51:02 +0000 (UTC) Organization: Epigenomics AG Lines: 31 Message-ID: X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.3 (Linux) To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! This morning I saw this in the logfile: Mar 15 09:30:39 raman kernel: xfs_force_shutdown(sd(8,18),0x8) called from line 4079 of file xfs_bmap.c. Return address = 0xf89692a2 Mar 15 09:30:39 raman kernel: Corruption of in-memory data detected. Shutting down filesystem: sd(8,18) Mar 15 09:30:39 raman kernel: Please umount the filesystem, and rectify the problem(s) After reading the FAQ and the mailing list archive it seems that a simple umount and mount could slove the problem. But: Mar 15 10:21:40 raman kernel: XFS: bad magic number Mar 15 10:21:40 raman kernel: XFS: SB validate failed The primary superblock was corrupted. Running xfs_repair produced some files in lost+found and the message that sunit and swidth are being resetted and should be specified in the mount options. I haven't used these options for mkfs.xfs so I did not specify them when mounting the repaired filesystem. The mount worked and the filesystem looks godd at a first glance (execpt for the file in lost+found...). Are we still able to use that filesystem? Kernel is 2.4.17 from CVS compiled on Jan 4th, filesystem is on an external HW-RAID which does not report errors. Greetings -- Robert Sander Department Head Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Fri Mar 15 03:41:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FBfj824613 for linux-xfs-outgoing; Fri, 15 Mar 2002 03:41:45 -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 g2FBff924587 for ; Fri, 15 Mar 2002 03:41:41 -0800 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16lq5s-0001Pd-00; Fri, 15 Mar 2002 12:41:56 +0100 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Robert Sander" Date: Fri, 15 Mar 2002 12:41:55 +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: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: force_shutdown experienced Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Mar 2002 09:51:02 +0000 (UTC), Robert Sander wrote: >The primary superblock was corrupted. I guess this is due to a bug that "once" was present in the kernel (but seems to have been corrected, if I remember correctly.) Better get yourself a current kernel! -- 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 15 05:00:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FD0iW27715 for linux-xfs-outgoing; Fri, 15 Mar 2002 05:00:44 -0800 Received: from mail016.syd.optusnet.com.au (mail016.syd.optusnet.com.au [203.2.75.176]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FD0d927688 for ; Fri, 15 Mar 2002 05:00:40 -0800 Received: from localhost.localdomain (c17835.eburwd2.vic.optusnet.com.au [210.49.188.189]) by mail016.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id g2FD22608877 for ; Sat, 16 Mar 2002 00:02:02 +1100 Subject: 2.4.18-benh kernels From: Menaka Lashitha Bandara To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 16 Mar 2002 00:02:02 +1100 Message-Id: <1016197322.1661.41.camel@rasta> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Folks, Just wondering if anyone out there has managed to patch a 2.4.18-benh powerpc kernel with XFS. I'm currently running my iBook 600 with XFS (from root up, Debian 3.0), and I want to use the optimisations that have been done to the kernel by benh (mainly regarding accerlerated graphics). I'm not willing to move away from XFS... I want the best of both worlds. Thanx. \LaShI From owner-linux-xfs@oss.sgi.com Fri Mar 15 05:32:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FDWlx28381 for linux-xfs-outgoing; Fri, 15 Mar 2002 05:32:47 -0800 Received: from pasiphae03.frii.com (root@pasiphae03.frii.com [216.17.128.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FDWg928353 for ; Fri, 15 Mar 2002 05:32:42 -0800 Received: from deimos.frii.net (deimos.frii.com [216.17.128.2]) by pasiphae03.frii.com (8.12.2/8.12.2) with ESMTP id g2FDYAV7016713 for ; Fri, 15 Mar 2002 06:34:10 -0700 (MST) Received: from jeffw (pico205.dsl.frii.net [216.17.224.205]) by deimos.frii.net (8.12.2/8.12.2) with ESMTP id g2FDY8aO055368 for ; Fri, 15 Mar 2002 06:34:09 -0700 (MST) From: "Jeffrey D. Means" To: "XFS" Subject: What am i dooing wrong?? (setfacl problem) Date: Fri, 15 Mar 2002 06:42:27 -0700 Message-ID: <000001c1cc27$40d75810$0264a8c0@jeffw> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2FDWg928354 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [root@trouble www]# setfacl --version setfacl 2.0.4 [root@trouble www]# mount /dev/sda1 on / type xfs (rw) none on /proc type proc (rw) /dev/hda1 on /boot type xfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/hda2 on /home type xfs (rw) none on /dev/shm type tmpfs (rw) /dev/hdb1 on /samba type xfs (rw) /dev/sdb2 on /tmp type xfs (rw) [root@trouble www]# setfacl -m u:meaje:rwx,mask:rwx html setfacl: html: Operation not supported [root@trouble www]# Why is this operation not supported? I am in a directory under /home which is an XFS filesystem. I really want to apply the default permissions to this directory but will be happy if this user can write to it. I installed and formatted these drives with the 1.0.2 install iso cdrom image file off your website, the rest of the install is basic RedHat except I have recompiled a kernel and xfs commands using the cvs tree on 3/14/02. ------------- Jeffrey D. Means CIO for PicoTech Ft. Collins, Colorado From owner-linux-xfs@oss.sgi.com Fri Mar 15 05:39:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FDdF628546 for linux-xfs-outgoing; Fri, 15 Mar 2002 05:39:15 -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 g2FDd8928520 for ; Fri, 15 Mar 2002 05:39: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 g2FEeWBA023261 for ; Fri, 15 Mar 2002 06:40:32 -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 HAA68763; Fri, 15 Mar 2002 07:39:16 -0600 (CST) Received: from sgi.com (Lz9my5pYRafgJ/nZ+h0jDBpKvrzcFzd5@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 HAA48678; Fri, 15 Mar 2002 07:39:15 -0600 (CST) Message-ID: <3C91F99A.5000704@sgi.com> Date: Fri, 15 Mar 2002 07:39:38 -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: Robert Sander CC: linux-xfs@oss.sgi.com Subject: Re: force_shutdown experienced References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Robert Sander wrote: >Hi! > >This morning I saw this in the logfile: > >Mar 15 09:30:39 raman kernel: xfs_force_shutdown(sd(8,18),0x8) called from line 4079 of file xfs_bmap.c. Return address = 0xf89692a2 >Mar 15 09:30:39 raman kernel: Corruption of in-memory data detected. Shutting down filesystem: sd(8,18) >Mar 15 09:30:39 raman kernel: Please umount the filesystem, and rectify the problem(s) > >After reading the FAQ and the mailing list archive it seems that a >simple umount and mount could slove the problem. But: > >Mar 15 10:21:40 raman kernel: XFS: bad magic number >Mar 15 10:21:40 raman kernel: XFS: SB validate failed > >The primary superblock was corrupted. Running xfs_repair produced some >files in lost+found and the message that sunit and swidth are being >resetted and should be specified in the mount options. >I haven't used these options for mkfs.xfs so I did not specify them when >mounting the repaired filesystem. The mount worked and the filesystem >looks godd at a first glance (execpt for the file in lost+found...). > >Are we still able to use that filesystem? >Kernel is 2.4.17 from CVS compiled on Jan 4th, filesystem is on an >external HW-RAID which does not report errors. > >Greetings > Well, two things happened to you - the forced shutdown, and the bug which Ralf Bergs mentioned. That bug was fixed on Jan 17th - a current cvs kernel should get you around that one. The bug caused the superblock to get overwritten after forced shutdown. Note if you get the new kernel and you use ACLs you need new user space utilities to go with the kernel. I would unmount the filesystem and run xfs_check on it to verify it is clean, but repair should have handled everything. I do not think we will be able to determine the cause of the memory corruption from the information we have here. Steve From owner-linux-xfs@oss.sgi.com Fri Mar 15 05:43:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FDhsl28712 for linux-xfs-outgoing; Fri, 15 Mar 2002 05:43:54 -0800 Received: from svrmail.vecteurplus.com (IDENT:root@srvmail.vecteurplus.com [195.101.229.42] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FDhl928686 for ; Fri, 15 Mar 2002 05:43:47 -0800 Received: from info103 (info-103.info.lan.vecteurplus.com [192.168.120.103]) by svrmail.vecteurplus.com (8.11.4/8.11.4) with SMTP id g2FDkAF12667 for ; Fri, 15 Mar 2002 14:46:10 +0100 Message-ID: <001b01c1cc28$24fd9040$6778a8c0@info103> From: "Pascal Schelcher" To: References: <000001c1cc27$40d75810$0264a8c0@jeffw> Subject: Re: What am i dooing wrong?? (setfacl problem) Date: Fri, 15 Mar 2002 14:48:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Have you compiled your kernel with ACL support ? Can you do (in any directory) : # getfacl * Pascal Schelcher. ----- Original Message ----- From: "Jeffrey D. Means" To: "XFS" Sent: Friday, March 15, 2002 2:42 PM Subject: What am i dooing wrong?? (setfacl problem) > [root@trouble www]# setfacl --version > setfacl 2.0.4 > [root@trouble www]# mount > /dev/sda1 on / type xfs (rw) > none on /proc type proc (rw) > /dev/hda1 on /boot type xfs (rw) > none on /dev/pts type devpts (rw,gid=5,mode=620) > /dev/hda2 on /home type xfs (rw) > none on /dev/shm type tmpfs (rw) > /dev/hdb1 on /samba type xfs (rw) > /dev/sdb2 on /tmp type xfs (rw) > [root@trouble www]# setfacl -m u:meaje:rwx,mask:rwx html > setfacl: html: Operation not supported > [root@trouble www]# > > Why is this operation not supported? I am in a directory under /home > which is an XFS filesystem. I really want to apply the default > permissions to this directory but will be happy if this user can write > to it. I installed and formatted these drives with the 1.0.2 install > iso cdrom image file off your website, the rest of the install is basic > RedHat except I have recompiled a kernel and xfs commands using the cvs > tree on 3/14/02. > > ------------- > Jeffrey D. Means > CIO for PicoTech > Ft. Collins, Colorado > > > > From owner-linux-xfs@oss.sgi.com Fri Mar 15 05:45:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FDjq928845 for linux-xfs-outgoing; Fri, 15 Mar 2002 05:45:52 -0800 Received: from gk.hm.epigenomics.net (qmailr@gk.hm.epigenomics.net [212.121.137.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FDjk928819 for ; Fri, 15 Mar 2002 05:45:46 -0800 Received: (qmail 20555 invoked from network); 15 Mar 2002 13:47:13 -0000 Received: from raman.epigenomics.epi (qmailr@192.168.2.2) by salam.epigenomics.epi with SMTP; 15 Mar 2002 13:47:13 -0000 Received: (qmail 3422 invoked from network); 15 Mar 2002 13:47:12 -0000 Received: from eigen.epigenomics.epi (qmailr@192.168.2.36) by raman.epigenomics.epi with SMTP; 15 Mar 2002 13:47:12 -0000 Received: (qmail 5144 invoked by uid 515); 15 Mar 2002 13:47:12 -0000 Date: Fri, 15 Mar 2002 14:47:12 +0100 From: Robert Sander To: linux-xfs@oss.sgi.com Subject: Re: force_shutdown experienced Message-ID: <20020315134712.GA5095@epigenomics.de> References: <3C91F99A.5000704@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <3C91F99A.5000704@sgi.com> User-Agent: Mutt/1.3.27i X-Operating-System: Linux eigen 2.4.17-xfs-20020131-client-piii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Mar 15, 2002 at 07:39:38AM -0600, Stephen Lord wrote: > Well, two things happened to you - the forced shutdown, and the bug > which Ralf Bergs > mentioned. That bug was fixed on Jan 17th - a current cvs kernel should > get you around > that one. The bug caused the superblock to get overwritten after forced > shutdown. I have heard (or better read) of the bug, but did not correlate the two. > Note if you get the new kernel and you use ACLs you need new user space > utilities to go with the kernel. Or I compile the compatability layer into the kernel. How is that working? > I would unmount the filesystem and run xfs_check on it to verify it is > clean, but repair should have handled everything. Yes, filesystem looks good. > I do not think we will be able to determine the cause of the memory > corruption from the information we have here. I wish I could. The machine is a Dell PowerEdge 2550 with an onboard Perc 3/Di (the famous aacraid) and an external HW-RAID box connected via normal Adaptec SCSI controller. Greetings -- Robert Sander Department Head Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Fri Mar 15 05:52:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FDqOh29062 for linux-xfs-outgoing; Fri, 15 Mar 2002 05:52:24 -0800 Received: from MailUser (80-25-195-149.uc.nombres.ttd.es [80.25.195.149]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FDqK929036 for ; Fri, 15 Mar 2002 05:52:20 -0800 Message-Id: <200203151352.g2FDqK929036@oss.sgi.com> Reply-To: info@ifactoria.com From: "Grupo iFactoria" To: "" Organization: Grupo iFactoria X-Priority: 3 X-MSMail-Priority: Normal Subject: Invitacion y Presentacion publicaciones profesionales gratuitas Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 15 Mar 2002 14:52:01 +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Le invitamos a visitar el portal iKiosco.com en http://www.ikiosco.com donde le informamos de las publicaciones profesionales dirigidas a los sectores de educacion y formacion, informatica, internet, negocios y nuevas tecnologias. Gracias por su atencion y disculpe las molestias ocasionadas, Grupo iFactoria From owner-linux-xfs@oss.sgi.com Fri Mar 15 08:07:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FG7in31809 for linux-xfs-outgoing; Fri, 15 Mar 2002 08:07:44 -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 g2FG7c931783 for ; Fri, 15 Mar 2002 08:07:38 -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 g2FH92BA027892 for ; Fri, 15 Mar 2002 09:09:03 -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 KAA72045; Fri, 15 Mar 2002 10:07:46 -0600 (CST) Received: from sgi.com (fm8nwq9eXBPBwJN0QxWl4LdzJug8fvnb@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 KAA61863; Fri, 15 Mar 2002 10:07:46 -0600 (CST) Message-ID: <3C921C68.6000308@sgi.com> Date: Fri, 15 Mar 2002 10:08:08 -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: Robert Sander CC: linux-xfs@oss.sgi.com Subject: Re: force_shutdown experienced References: <3C91F99A.5000704@sgi.com> <20020315134712.GA5095@epigenomics.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Robert Sander wrote: >On Fri, Mar 15, 2002 at 07:39:38AM -0600, Stephen Lord wrote: > >>Well, two things happened to you - the forced shutdown, and the bug >>which Ralf Bergs >>mentioned. That bug was fixed on Jan 17th - a current cvs kernel should >>get you around >>that one. The bug caused the superblock to get overwritten after forced >>shutdown. >> > >I have heard (or better read) of the bug, but did not correlate the two. > >>Note if you get the new kernel and you use ACLs you need new user space >>utilities to go with the kernel. >> > >Or I compile the compatability layer into the kernel. How is that >working? > There is no compatibility layer, at 2.4.18 the system calls change. Maintaining both in the kernel was going to be a nightmare. I am not sure what the current status is with third party apps like samba - I think some people have it working. Steve From owner-linux-xfs@oss.sgi.com Fri Mar 15 09:13:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FHDMT01050 for linux-xfs-outgoing; Fri, 15 Mar 2002 09:13:22 -0800 Received: from rain.CC.Lehigh.EDU (rain.CC.Lehigh.EDU [128.180.39.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FHDB901020 for ; Fri, 15 Mar 2002 09:13:12 -0800 Received: from Lehigh.EDU (hooch.CC.Lehigh.EDU [128.180.3.11]) by rain.CC.Lehigh.EDU (8.12.2/8.12.2) with ESMTP id g2FHEUEW002133 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 15 Mar 2002 12:14:31 -0500 Message-ID: <3C922BF6.8050405@Lehigh.EDU> Date: Fri, 15 Mar 2002 12:14:30 -0500 From: Jim Eshleman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nfs@lists.sourceforge.net, linux-xfs@oss.sgi.com Subject: 2.4.18 rpciod oops [xdr_encode_netobj] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk FYI. There was no apparent effect on the running system, an 8-way 8.5G (64G HIGHMEM) P3 Xeon, running 2.4.18 + XFS, NIS, NFS, sendmail, etc. Let me know if more info is needed. Jim ksymoops 2.4.0 on i686 2.4.18-xfs. Options used -v /usr/src/linux-2.4.18-xfs/vmlinux (specified) -K (specified) -L (specified) -O (specified) -m /usr/src/linux-2.4.18-xfs/System.map (specified) kernel: Unable to handle kernel paging request at virtual address 40020045 kernel: c02e3d51 kernel: *pde = 1a3f3001 kernel: Oops: 0000 kernel: CPU: 7 kernel: EIP: 0010:[xdr_encode_netobj+49/80] Not tainted kernel: EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 kernel: EFLAGS: 00010212 kernel: eax: eb46b468 ebx: cc6c20b0 ecx: 00020df4 edx: 000837d1 kernel: esi: 40020045 edi: cc6c20b0 ebp: eb46b41c esp: f71ebef4 kernel: ds: 0018 es: 0018 ss: 0018 kernel: Process rpciod (pid: 728, stackpage=f71eb000) kernel: Stack: eb46b470 f56fa05c c0197590 c0196c63 cc6c20ac eb46b468 c0196e2a cc6c20ac kernel: eb46b468 eb46b41c f56fa05c c0197590 cd88dae0 eb46b41c f56fa05c c0197590 kernel: cd88dae0 c01975d1 cc6c2078 eb46b41c f56fa05c f1ea7de0 c02da78c f56fa05c kernel: Call Trace: [nlm4clt_encode_testargs+0/96] [nlm4_encode_oh+15/20] [nlm4_encode_lock+66/360] [nlm4clt_encode_testargs+0/96] [nlm4clt_encode_testargs+0/96] kernel: Call Trace: [] [] [] [] [] kernel: [] [] [] [] [] [] kernel: Code: f3 a5 f6 c2 02 74 02 66 a5 f6 c2 01 74 01 a4 8b 00 83 c0 03 >>EIP; c02e3d51 <===== Trace; c0197590 Trace; c0196c63 Trace; c0196e2a Trace; c0197590 Trace; c0197590 Trace; c01975d1 Trace; c02da78c Trace; c02de45c <__rpc_execute+ac/310> Trace; c02de8bd <__rpc_schedule+18d/1dc> Trace; c02df20d Trace; c01057db Code; c02e3d51 00000000 <_EIP>: Code; c02e3d51 <===== 0: f3 a5 repz movsl %ds:(%esi),%es:(%edi) <===== Code; c02e3d53 2: f6 c2 02 test $0x2,%dl Code; c02e3d56 5: 74 02 je 9 <_EIP+0x9> c02e3d5a Code; c02e3d58 7: 66 a5 movsw %ds:(%esi),%es:(%edi) Code; c02e3d5a 9: f6 c2 01 test $0x1,%dl Code; c02e3d5d c: 74 01 je f <_EIP+0xf> c02e3d60 Code; c02e3d5f e: a4 movsb %ds:(%esi),%es:(%edi) Code; c02e3d60 f: 8b 00 mov (%eax),%eax Code; c02e3d62 11: 83 c0 03 add $0x3,%eax From owner-linux-xfs@oss.sgi.com Fri Mar 15 09:24:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FHOGo01521 for linux-xfs-outgoing; Fri, 15 Mar 2002 09:24:16 -0800 Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FHOB901495 for ; Fri, 15 Mar 2002 09:24:11 -0800 Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45]) by mxzilla4.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2FHPcAh045846; Fri, 15 Mar 2002 18:25:38 +0100 (CET) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id SAA28908; Fri, 15 Mar 2002 18:25:38 +0100 (CET) Date: Fri, 15 Mar 2002 18:25:37 +0100 (CET) From: Seth Mos To: Robert Sander cc: linux-xfs@oss.sgi.com Subject: Re: force_shutdown experienced In-Reply-To: <20020315134712.GA5095@epigenomics.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Mar 2002, Robert Sander wrote: > > I do not think we will be able to determine the cause of the memory > > corruption from the information we have here. > > I wish I could. The machine is a Dell PowerEdge 2550 with an onboard > Perc 3/Di (the famous aacraid) and an external HW-RAID box connected via > normal Adaptec SCSI controller. The newer 2.4.18 has the newer aacraid driver which is much better then the older adaptec only drivers. It is a good suspect for corruption but it does not have to be this problem perse. cheers Seth From owner-linux-xfs@oss.sgi.com Fri Mar 15 09:30:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FHUel02123 for linux-xfs-outgoing; Fri, 15 Mar 2002 09:30:40 -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 g2FHUa902096 for ; Fri, 15 Mar 2002 09:30:36 -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 g2FHVw6G031005 for ; Fri, 15 Mar 2002 09:31:59 -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 LAA72072 for ; Fri, 15 Mar 2002 11:30:43 -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 LAA85327 for ; Fri, 15 Mar 2002 11:30:43 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g2FHUhn09740; Fri, 15 Mar 2002 11:30:43 -0600 Message-Id: <200203151730.g2FHUhn09740@stout.americas.sgi.com> Date: Fri, 15 Mar 2002 11:30:43 -0600 From: Eric Sandeen Subject: TAKE - Fix error reporting in write path Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We always have to be careful about how we return errors out of xfs - Irix (and hence the guts of xfs) deal with positive error values, but Linux expect to deal with negative errors. linvfs_write was returning the wrong error signs in the majority of error cases, including EFBIG. The LSB test suite caught this; this mod alone fixes about 18 of the LSB streamio test cases. Date: Fri Mar 15 09:27:23 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:114230a linux/fs/xfs/linux/xfs_file.c - 1.60 - Fix the sign of the majority of error returns in linvfs_write From owner-linux-xfs@oss.sgi.com Fri Mar 15 12:35:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FKZHe13522 for linux-xfs-outgoing; Fri, 15 Mar 2002 12:35:17 -0800 Received: from comm.hcsd.de (comm-ext0.hcsd.de [62.225.175.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FKZA913495 for ; Fri, 15 Mar 2002 12:35:11 -0800 Received: from babbage.hcsd.de (babbage.hcsd.de [192.168.100.5]) by comm.hcsd.de (8.12.2/8.12.2) with ESMTP id g2FKaZWf009259 for ; Fri, 15 Mar 2002 21:36:35 +0100 Received: (from au@localhost) by babbage.hcsd.de (8.11.3/8.11.3) id g2FKaYO27388 for linux-xfs@oss.sgi.com; Fri, 15 Mar 2002 21:36:35 +0100 Date: Fri, 15 Mar 2002 21:36:34 +0100 From: =?iso-8859-1?Q?Stephan_Austerm=FChle?= To: linux-xfs@oss.sgi.com Subject: compiling xfsdump: `SYS_getdents64' undeclared Message-ID: <20020315213634.A879@babbage.hcsd.de> 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, while trying to compile xfsdump 2.0.0 on my system (Kernel 2.4.18-xfs, glibc 2.1.3) the compiler aborts with an error: === dump === gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="2.0.0"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c -o getdents.o getdents.c getdents.c: In function `getdents_wrap': getdents.c:152: `SYS_getdents64' undeclared (first use in this function) getdents.c:152: (Each undeclared identifier is reported only once getdents.c:152: for each function it appears in.) make[1]: *** [getdents.o] Error 1 make: *** [default] Error 2 Maybe someone can help me fixing this problem. Please let me know if any information is missing. Thanks in advance, Stephan From owner-linux-xfs@oss.sgi.com Fri Mar 15 12:57:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FKvJc14234 for linux-xfs-outgoing; Fri, 15 Mar 2002 12:57:19 -0800 Received: from webcube2.volstate.net (webcube2.volstate.net [66.129.16.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FKvD914208 for ; Fri, 15 Mar 2002 12:57:14 -0800 Received: from there ([207.65.81.171]) by webcube2.volstate.net (8.9.3/8.9.3) with SMTP id PAA10148 for ; Fri, 15 Mar 2002 15:58:41 -0500 Message-Id: <200203152058.PAA10148@webcube2.volstate.net> Content-Type: text/plain; charset="us-ascii" From: Joe Bacom Reply-To: joebacom@volstate.net To: linux-xfs@oss.sgi.com Subject: xfs_check 112 Segmentation fault Date: Fri, 15 Mar 2002 14:51:02 -0600 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Anybody have any clues about the following error from xfs_check. /usr/sbin/xfs_check: line 62: 112 Segmentation fault xfs_db$ISFILE -i -p xfs_check -c "check$OPTS" $1 This drive has been acting up and the new one is one the way but I was trying to salvage some data off ot it. I am running on the SGI installer cd in rescue mode, kernel version: 2.4.7-10SGI_XFS_PR1BOOT Thanks; Joe From owner-linux-xfs@oss.sgi.com Fri Mar 15 13:14:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FLE8S14765 for linux-xfs-outgoing; Fri, 15 Mar 2002 13:14:08 -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 g2FLE1914732 for ; Fri, 15 Mar 2002 13:14:01 -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 g2FMNJkw003055 for ; Fri, 15 Mar 2002 16:23:19 -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 PAA76124; Fri, 15 Mar 2002 15:14:09 -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 PAA88678; Fri, 15 Mar 2002 15:14:09 -0600 (CST) Subject: Re: compiling xfsdump: `SYS_getdents64' undeclared From: Eric Sandeen To: Stephan =?ISO-8859-1?Q?Austerm=FChle?= Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020315213634.A879@babbage.hcsd.de> References: <20020315213634.A879@babbage.hcsd.de> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Evolution/1.0.2 Date: 15 Mar 2002 15:14:08 -0600 Message-Id: <1016226849.9370.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2FLE1914734 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Stephan - This should be defined in bits/syscall.h. From sys/syscall.h: /* The Linux kernel header file defines macros `__NR_', but some programs expect the traditional form `SYS_'. So in building libc we scan the kernel's list and produce with macros for all the `SYS_' names. */ So it's probably your older glibc that's causing the problem. You could either add #define SYS_getdents64 __NR_getdents64 to /usr/include/bits/syscall.h or replace SYS_getdents64 with __NR_getdents64 in xfsdump. ...I think. ;-) -Eric On Fri, 2002-03-15 at 14:36, Stephan Austermühle wrote: > Hi, > > while trying to compile xfsdump 2.0.0 on my system (Kernel 2.4.18-xfs, > glibc 2.1.3) the compiler aborts with an error: > > === dump === > gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="2.0.0"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs -I/usr/include/attr -c -o getdents.o getdents.c > getdents.c: In function `getdents_wrap': > getdents.c:152: `SYS_getdents64' undeclared (first use in this function) > getdents.c:152: (Each undeclared identifier is reported only once > getdents.c:152: for each function it appears in.) > make[1]: *** [getdents.o] Error 1 > make: *** [default] Error 2 > > Maybe someone can help me fixing this problem. Please let me know if > any information is missing. > > Thanks in advance, > > Stephan -- 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 15 13:47:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FLlcn15453 for linux-xfs-outgoing; Fri, 15 Mar 2002 13:47:38 -0800 Received: from comm.hcsd.de (comm-ext0.hcsd.de [62.225.175.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2FLlX915427 for ; Fri, 15 Mar 2002 13:47:33 -0800 Received: from babbage.hcsd.de (babbage.hcsd.de [192.168.100.5]) by comm.hcsd.de (8.12.2/8.12.2) with ESMTP id g2FLn0Wf009400; Fri, 15 Mar 2002 22:49:00 +0100 Received: (from au@localhost) by babbage.hcsd.de (8.11.3/8.11.3) id g2FLn0429595; Fri, 15 Mar 2002 22:49:00 +0100 Date: Fri, 15 Mar 2002 22:49:00 +0100 From: =?iso-8859-1?Q?Stephan_Austerm=FChle?= To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: compiling xfsdump: `SYS_getdents64' undeclared Message-ID: <20020315224900.B879@babbage.hcsd.de> References: <20020315213634.A879@babbage.hcsd.de> <1016226849.9370.2.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: <1016226849.9370.2.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Fri, Mar 15, 2002 at 03:14:08PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric! On Fri, Mar 15, 2002 at 03:14:08PM -0600, Eric Sandeen wrote: > You could either add > > #define SYS_getdents64 __NR_getdents64 > > to /usr/include/bits/syscall.h > > or replace SYS_getdents64 with __NR_getdents64 in xfsdump. Okay -- adding the definition for SYS_getdents64 to syscall.h worked. Thanks a lot for your quick response! Stephan From owner-linux-xfs@oss.sgi.com Fri Mar 15 15:37:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2FNbns17068 for linux-xfs-outgoing; Fri, 15 Mar 2002 15:37: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 g2FNbi917041 for ; Fri, 15 Mar 2002 15:37:44 -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 g2G0l3kw004234 for ; Fri, 15 Mar 2002 18:47:03 -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 RAA78060 for ; Fri, 15 Mar 2002 17:37:53 -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 RAA60386 for ; Fri, 15 Mar 2002 17:37:53 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g2FNbqo04338; Fri, 15 Mar 2002 17:37:52 -0600 Message-Id: <200203152337.g2FNbqo04338@stout.americas.sgi.com> Date: Fri, 15 Mar 2002 17:37:52 -0600 From: Eric Sandeen Subject: TAKE - Return ENAMETOOLONG on too-long pathname components. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This just adds if (dentry->d_name.len >= MAXNAMELEN) return ERR_PTR(-ENAMETOOLONG); to the top of linvfs_lookup, to make sure we don't go down the lookup path with something we can't handle. This is the same as ext2_lookup, etc. Gets us past another LSB test. :) Date: Fri Mar 15 15:35:17 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:114287a linux/fs/xfs/linux/xfs_iops.c - 1.126 - Return ENAMETOOLONG if that's the case in linvfs_lookup From owner-linux-xfs@oss.sgi.com Fri Mar 15 16:47:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2G0lFI19641 for linux-xfs-outgoing; Fri, 15 Mar 2002 16:47:15 -0800 Received: from hotmail.com (f82.law9.hotmail.com [64.4.9.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2G0lB919594 for ; Fri, 15 Mar 2002 16:47:11 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 15 Mar 2002 16:48:35 -0800 Received: from 211.50.36.24 by lw9fd.law9.hotmail.msn.com with HTTP; Sat, 16 Mar 2002 00:48:34 GMT X-Originating-IP: [211.50.36.24] From: "=?ks_c_5601-1987?B?wdYgsOa29A==?=" To: linux-xfs@oss.sgi.com Subject: redhat7.2 + sgi-xfs 1.0.2a .. problem... Date: Sat, 16 Mar 2002 09:48:34 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=ks_c_5601-1987; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2002 00:48:35.0165 (UTC) FILETIME=[4D88E0D0:01C1CC84] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk redhat7.2 + sgi-xfs 1.0.2a installed (intel platform machine - p4 single processor) full install bash shell create file-size > 2GB but cshell is not create file-size > 2GB why is it problem...?? please wise a reply.... Thank you! _________________________________________________________________ http://photos.msn.co.kr żĄź­ MSN Ć÷Ĺ丌 ťçżëÇĎ¸é żÂśóŔÎ ťóżĄź­ ťçÁřŔť ŔÎźâÇĎ °í ´Ů¸Ľ ťçś÷ľé°ú °řŔŻÇŇ źöľľ ŔÖ˝Ŕ´Ď´Ů. From owner-linux-xfs@oss.sgi.com Fri Mar 15 16:58:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2G0wUU20428 for linux-xfs-outgoing; Fri, 15 Mar 2002 16:58:30 -0800 Received: from mout0.freenet.de (exim@mout0.freenet.de [194.97.50.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2G0wN920402 for ; Fri, 15 Mar 2002 16:58:23 -0800 Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with esmtp (Exim 3.33 #4) id 16m2Y2-0005S0-00 for linux-xfs@oss.sgi.com; Sat, 16 Mar 2002 01:59:50 +0100 Received: from bbef0.pppool.de ([213.7.190.240]) by mx3.freenet.de with esmtp (Exim 3.33 #4) id 16m2Y2-0001Bm-00 for linux-xfs@oss.sgi.com; Sat, 16 Mar 2002 01:59:50 +0100 Date: Sat, 16 Mar 2002 01:59:54 +0100 From: Sebastian Ude To: linux-xfs@oss.sgi.com Subject: Re: Random filesystem corruption Reply-To: ude@handshake.de In-Reply-To: <20020310112442.2994E11CD29@smtp.de.easynet.net> References: <20020310112442.2994E11CD29@smtp.de.easynet.net> 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: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 10 Mar 2002, ude@handshake.de (Sebastian Ude) wrote: > Date: Sun, 10 Mar 2002 12:24:43 +0100 > To: linux-xfs@oss.sgi.com > From: ude@handshake.de (Sebastian Ude) > Reply-To: ude@handshake.de > Subject: Re: Random filesystem corruption > > > > 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. Come on gentlemen - no ideas about the FS corruption and on how to restore my data (besides xfs_repair which was not able to restore my data the last time if I remember correctly) ? - Sebastian From owner-linux-xfs@oss.sgi.com Fri Mar 15 17:18:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2G1ILB20823 for linux-xfs-outgoing; Fri, 15 Mar 2002 17:18: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 g2G1IH920796 for ; Fri, 15 Mar 2002 17:18:17 -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 g2G2Rakw004507 for ; Fri, 15 Mar 2002 20:27:36 -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 TAA78699; Fri, 15 Mar 2002 19:18:26 -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 TAA73924; Fri, 15 Mar 2002 19:18:25 -0600 (CST) Date: Fri, 15 Mar 2002 19:18:25 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Sebastian Ude cc: Subject: Re: Random filesystem corruption 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 You can try xfs_repair by dd'ing off the parition, if it's not too big, and running xfs_repair on that file. Also, are you _certain_ that you have seen this same problem on files without international characters? -Eric On Sat, 16 Mar 2002, Sebastian Ude wrote: > Come on gentlemen - no ideas about the FS corruption and on how to restore > my data (besides xfs_repair which was not able to restore my data the last > time if I remember correctly) ? > > > - Sebastian > From owner-linux-xfs@oss.sgi.com Fri Mar 15 17:22:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2G1Ma021020 for linux-xfs-outgoing; Fri, 15 Mar 2002 17:22:36 -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 g2G1MV920990 for ; Fri, 15 Mar 2002 17:22: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 g2G1Nt6G015730 for ; Fri, 15 Mar 2002 17:23:55 -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 TAA78125; Fri, 15 Mar 2002 19:21:25 -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 TAA50798; Fri, 15 Mar 2002 19:21:25 -0600 (CST) Date: Fri, 15 Mar 2002 19:21:25 -0600 (CST) From: Eric Sandeen X-X-Sender: To: =?ks_c_5601-1987?B?wdYgsOa29A==?= cc: Subject: Re: redhat7.2 + sgi-xfs 1.0.2a .. problem... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to base64 by rj.sgi.com id g2G1Nt6G015730 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g2G1MV920991 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Please see http://oss.sgi.com/projects/xfs/faq.html#largefilesupport (tcsh is known to have problems w/ largefile support) -Eric On Sat, 16 Mar 2002, [ks_c_5601-1987] ÁÖ °ćśô wrote: > > > redhat7.2 + sgi-xfs 1.0.2a installed (intel platform machine - p4 single > processor) > > full install > bash shell create file-size > 2GB but cshell is not create file-size > 2GB > > why is it problem...?? > > please wise a reply.... > > Thank you! > > > _________________________________________________________________ > http://photos.msn.co.kr żĄź­ MSN Ć÷Ĺ丌 ťçżëÇĎ¸é żÂśóŔÎ ťóżĄź­ ťçÁřŔť ŔÎźâÇĎ > °í ´Ů¸Ľ ťçś÷ľé°ú °řŔŻÇŇ źöľľ ŔÖ˝Ŕ´Ď´Ů. > From owner-linux-xfs@oss.sgi.com Fri Mar 15 17:49:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2G1nJc21429 for linux-xfs-outgoing; Fri, 15 Mar 2002 17:49: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 g2G1nF921403 for ; Fri, 15 Mar 2002 17:49:15 -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 g2G1oc6G016160 for ; Fri, 15 Mar 2002 17:50:39 -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 TAA79836; Fri, 15 Mar 2002 19:49: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 TAA06645; Fri, 15 Mar 2002 19:49:23 -0600 (CST) Date: Fri, 15 Mar 2002 19:49:23 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Sebastian Ude cc: Subject: Re: Random filesystem corruption 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 Also, please send the output of "xfs_repair -n" - this will not actually do anything to your filesystem, but it might give hints about what's gone wrong. -Eric On Sat, 16 Mar 2002, Sebastian Ude wrote: > Come on gentlemen - no ideas about the FS corruption and on how to restore > my data (besides xfs_repair which was not able to restore my data the last > time if I remember correctly) ? > > > - Sebastian > From owner-linux-xfs@oss.sgi.com Sat Mar 16 04:17:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GCHsw29989 for linux-xfs-outgoing; Sat, 16 Mar 2002 04:17:54 -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 g2GCHk929960 for ; Sat, 16 Mar 2002 04:17:47 -0800 Received: from h573.ibc.de.easynet.net (h573.ibc.de.easynet.net [212.224.50.61]) by smtp.de.easynet.net (Postfix) with ESMTP id 040D511CD22 for ; Sat, 16 Mar 2002 13:19:09 +0100 (CET) Date: Sat, 16 Mar 2002 13:19:12 +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: <20020316121910.040D511CD22@smtp.de.easynet.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Mar 2002, sandeen@sgi.com (Eric Sandeen) wrote: > Date: Fri, 15 Mar 2002 19:18:25 -0600 (CST) > To: Sebastian Ude > From: sandeen@sgi.com (Eric Sandeen) > CC: > Subject: Re: Random filesystem corruption [...] > Also, are you _certain_ that you have seen this same problem on files > without international characters? Yes. I remember that for example, one subdirectory of a local copy of the bttv driver tree got corrupted. I do not remember which one it was, but the directory name must have been one of: ~/kernel/bttv-0.7.90$ find -type d . /driver /driver/old /pending /ralphs-doc /tools As you see, no international characters here. - Sebastian From owner-linux-xfs@oss.sgi.com Sat Mar 16 04:22:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GCM5h30156 for linux-xfs-outgoing; Sat, 16 Mar 2002 04:22:05 -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 g2GCLx930128 for ; Sat, 16 Mar 2002 04:21:59 -0800 Received: from h587.ibc.de.easynet.net (h587.ibc.de.easynet.net [212.224.50.75]) by smtp.de.easynet.net (Postfix) with ESMTP id 5081711CD22 for ; Sat, 16 Mar 2002 13:23:23 +0100 (CET) Date: Sat, 16 Mar 2002 13:23:24 +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: <20020316122323.5081711CD22@smtp.de.easynet.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Mar 2002, sandeen@sgi.com (Eric Sandeen) wrote: > Date: Fri, 15 Mar 2002 19:49:23 -0600 (CST) > To: Sebastian Ude > From: sandeen@sgi.com (Eric Sandeen) > CC: > Subject: Re: Random filesystem corruption > > Also, please send the output of "xfs_repair -n" - this will not actually > do anything to your filesystem, but it might give hints about what's gone > wrong. Okay - here comes the intresting part: Phase 6 - check inode connectivity... - traversing filesystem starting at / ... bad hash table for directory inode 1314885 (hash value mismatch): would rebuild bad hash table for directory inode 30843915 (hash value mismatch): would rebuildbad hash table for directory inode 26167342 (hash value mismatch): would rebuildbad hash table for directory inode 22646639 (hash value mismatch): would rebuildbad hash table for directory inode 22646607 (hash value mismatch): would rebuildbad hash table for directory inode 4813419 (hash value mismatch): would rebuild bad hash table for directory inode 30021493 (hash value mismatch): would rebuildbad hash table for directory inode 21552797 (hash value mismatch): would rebuildbad hash table for directory inode 16796591 (hash value mismatch): would rebuildbad hash table for directory inode 1314933 (hash value mismatch): would rebuild bad hash table for directory inode 16796583 (hash value mismatch): would rebuildbad hash table for directory inode 16796575 (hash value mismatch): would rebuildbad hash table for directory inode 13233180 (hash value mismatch): would rebuildbad hash table for directory inode 8388768 (hash value mismatch): would rebuild bad hash table for directory inode 4813382 (hash value mismatch): would rebuild bad hash table for directory inode 1314889 (hash value mismatch): would rebuild bad hash table for directory inode 29360317 (hash value mismatch): would rebuildbad hash table for directory inode 12583099 (hash value mismatch): would rebuild - traversal finished ... - Sebastian From owner-linux-xfs@oss.sgi.com Sat Mar 16 04:24:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GCO0G30298 for linux-xfs-outgoing; Sat, 16 Mar 2002 04:24:00 -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 g2GCNu930270 for ; Sat, 16 Mar 2002 04:23:57 -0800 Received: from h651.ibc.de.easynet.net (h651.ibc.de.easynet.net [212.224.50.139]) by smtp.de.easynet.net (Postfix) with ESMTP id 9C1BC11CD22 for ; Sat, 16 Mar 2002 13:25:22 +0100 (CET) Date: Sat, 16 Mar 2002 13:25:25 +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: <20020316122522.9C1BC11CD22@smtp.de.easynet.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Mar 2002, sandeen@sgi.com (Eric Sandeen) wrote: > Date: Fri, 15 Mar 2002 19:18:25 -0600 (CST) > To: Sebastian Ude > From: sandeen@sgi.com (Eric Sandeen) > CC: > Subject: Re: Random filesystem corruption > > You can try xfs_repair by dd'ing off the parition, if it's not too big, > and running xfs_repair on that file. It *is* too big ... - Sebastian From owner-linux-xfs@oss.sgi.com Sat Mar 16 06:16:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GEGTo32424 for linux-xfs-outgoing; Sat, 16 Mar 2002 06:16:29 -0800 Received: from mail.exaband.net ([203.112.145.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2GEGL932396 for ; Sat, 16 Mar 2002 06:16:23 -0800 Received: from exaband.net (sanat.uulogic.com [192.168.1.72]) by mail.exaband.net (8.11.0/8.11.0) with ESMTP id g2GECD530183 for ; Sat, 16 Mar 2002 19:42:13 +0530 Message-ID: <3C9351DF.1571C100@exaband.net> Date: Sat, 16 Mar 2002 19:38:31 +0530 From: Sanat Mohanty X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: help Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm trying to install XFS for RH-7.1 on my systems. I downloaded the ISO images from the SGI's repository. I'm able to install it using manual installation method, when I tried with kiskstart it failed giving error "No RedHat directory found on CD." I don't know what is going wrong. From some news group I came to know there is a bug in RH-7.1 anaconda, that's why it failed with kickstart, I don't know whether it is true or false. Please help me out. Thanks in advance Sanat From owner-linux-xfs@oss.sgi.com Sat Mar 16 06:26:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GEQQK32683 for linux-xfs-outgoing; Sat, 16 Mar 2002 06:26: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 g2GEQL932656 for ; Sat, 16 Mar 2002 06:26: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 g2GFZfkw006024 for ; Sat, 16 Mar 2002 09:35:42 -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 IAA87009; Sat, 16 Mar 2002 08:26:29 -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 IAA22988; Sat, 16 Mar 2002 08:26:29 -0600 (CST) Date: Sat, 16 Mar 2002 08:26:29 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Sanat Mohanty cc: Subject: Re: help In-Reply-To: <3C9351DF.1571C100@exaband.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have had luck with kickstart + a network install source, but have not tried it with a local CDROM. Is there a reason you don't want to use the 7.2/1.0.2 installer? It has a much newer release of XFS, and kickstart might work better for you too. -Eric On Sat, 16 Mar 2002, Sanat Mohanty wrote: > Hi, > I'm trying to install XFS for RH-7.1 on my systems. I downloaded the > ISO images from the SGI's repository. > I'm able to install it using manual installation method, when I tried > with kiskstart it failed giving error "No RedHat directory found on > CD." I don't know what is going wrong. From some news group I came to > know there is a bug in RH-7.1 anaconda, that's why > it failed with kickstart, I don't know whether it is true or false. > Please help me out. > > Thanks in advance > Sanat > > From owner-linux-xfs@oss.sgi.com Sat Mar 16 09:07:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GH70m08569 for linux-xfs-outgoing; Sat, 16 Mar 2002 09:07:00 -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 g2GH6p908543 for ; Sat, 16 Mar 2002 09:06:51 -0800 Received: from h721.ibc.de.easynet.net (h721.ibc.de.easynet.net [212.224.50.209]) by smtp.de.easynet.net (Postfix) with ESMTP id 2D7C411CD43 for ; Sat, 16 Mar 2002 18:08:17 +0100 (CET) Date: Sat, 16 Mar 2002 18:08:19 +0100 From: Sebastian Ude To: linux-xfs@oss.sgi.com Subject: Re: Random filesystem corruption Reply-To: ude@handshake.de In-Reply-To: <3C929D14.6040502@sgi.com> References: <3C929D14.6040502@sgi.com> 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: <20020316170817.2D7C411CD43@smtp.de.easynet.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 15 Mar 2002, lord@sgi.com (Stephen Lord) wrote: > Date: Fri, 15 Mar 2002 19:17:08 -0600 > To: ude@handshake.de > From: lord@sgi.com (Stephen Lord) > CC: linux-xfs@oss.sgi.com > Subject: Re: Random filesystem corruption [...] > We then want to look at the block in the file (if it was less than 4K > this would be in the > inode output): > > xfs_db: dblock 0 > xfs_db: p > bhdr.magic = 0x58443242 > bhdr.bestfree[0].offset = 0xb18 > bhdr.bestfree[0].length = 0x1a8 > bhdr.bestfree[1].offset = 0x540 > bhdr.bestfree[1].length = 0x1a0 > bhdr.bestfree[2].offset = 0x7c0 > bhdr.bestfree[2].length = 0x1a0 > bu[0].inumber = 131 > bu[0].namelen = 1 > bu[0].name = "." > bu[0].tag = 0x10 > bu[1].inumber = 128 > bu[1].namelen = 2 > bu[1].name = ".." > bu[1].tag = 0x20 [...] > bleaf[0].hashval = 0x2e > bleaf[0].address = 0x2 > bleaf[1].hashval = 0x172e > bleaf[1].address = 0x4 [...] > Now find the offending name and run the hash command on it: > > xfs_db: hash xfs-baseline > 0xf050e942 Steve, for some reason xfs_db does print the first listing of the form: xx[i].inumber = xx[i].namelen = xx[i].name = xx[i].tag = but not the second one where it comes to the important hash values ... - Sebastian From owner-linux-xfs@oss.sgi.com Sat Mar 16 09:44:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GHiwV09042 for linux-xfs-outgoing; Sat, 16 Mar 2002 09:44: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 g2GHio909015 for ; Sat, 16 Mar 2002 09:44:50 -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 g2GHiL6G026283 for ; Sat, 16 Mar 2002 09:44:21 -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 LAA84787; Sat, 16 Mar 2002 11:43:06 -0600 (CST) Received: from sgi.com (06VtViUNQ3Dh3fO74FTIjpU+CD0oqio4@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 LAA60206; Sat, 16 Mar 2002 11:43:05 -0600 (CST) Message-ID: <3C93843D.4020505@sgi.com> Date: Sat, 16 Mar 2002 11:43:25 -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: ude@handshake.de CC: linux-xfs@oss.sgi.com Subject: Re: Random filesystem corruption References: <20020316122323.5081711CD22@smtp.de.easynet.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sebastian Ude wrote: > >On Fri, 15 Mar 2002, sandeen@sgi.com (Eric Sandeen) wrote: > >>Date: Fri, 15 Mar 2002 19:49:23 -0600 (CST) >>To: Sebastian Ude >>From: sandeen@sgi.com (Eric Sandeen) >>CC: >>Subject: Re: Random filesystem corruption >> >>Also, please send the output of "xfs_repair -n" - this will not actually >>do anything to your filesystem, but it might give hints about what's gone >>wrong. >> > >Okay - here comes the intresting part: > >Phase 6 - check inode connectivity... > - traversing filesystem starting at / ... >bad hash table for directory inode 1314885 (hash value mismatch): would rebuild >bad hash table for directory inode 30843915 (hash value mismatch): would rebuildbad hash table for directory inode 26167342 (hash value mismatch): would rebuildbad hash table for directory inode 22646639 (hash value mismatch): would rebuildbad hash >table for directory inode 22646607 (hash value mismatch): would rebuildbad hash table for directory inode 4813419 (hash value mismatch): would rebuild >bad hash table for directory inode 30021493 (hash value mismatch): would rebuildbad hash table for directory inode 21552797 (hash value mismatch): would rebuildbad hash table for directory inode 16796591 (hash value mismatch): would rebuildbad hash >table for directory inode 1314933 (hash value mismatch): would rebuild >bad hash table for directory inode 16796583 (hash value mismatch): would rebuildbad hash table for directory inode 16796575 (hash value mismatch): would rebuildbad hash table for directory inode 13233180 (hash value mismatch): would rebuildbad hash >table for directory inode 8388768 (hash value mismatch): would rebuild >bad hash table for directory inode 4813382 (hash value mismatch): would rebuild >bad hash table for directory inode 1314889 (hash value mismatch): would rebuild >bad hash table for directory inode 29360317 (hash value mismatch): would rebuildbad hash table for directory inode 12583099 (hash value mismatch): would rebuild > - traversal finished ... > > >- Sebastian > Well, from this it looks like repair might actually fix it. Steve From owner-linux-xfs@oss.sgi.com Sat Mar 16 09:58:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GHw2t09387 for linux-xfs-outgoing; Sat, 16 Mar 2002 09:58:02 -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 g2GHvv909361 for ; Sat, 16 Mar 2002 09:57:58 -0800 Received: from h652.ibc.de.easynet.net (h652.ibc.de.easynet.net [212.224.50.140]) by smtp.de.easynet.net (Postfix) with ESMTP id EE31311CD43 for ; Sat, 16 Mar 2002 18:57:30 +0100 (CET) Date: Sat, 16 Mar 2002 18:57:33 +0100 From: Sebastian Ude To: linux-xfs@oss.sgi.com Subject: Re: Random filesystem corruption Reply-To: ude@handshake.de In-Reply-To: <3C93843D.4020505@sgi.com> References: <3C93843D.4020505@sgi.com> 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: <20020316175731.EE31311CD43@smtp.de.easynet.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 16 Mar 2002, lord@sgi.com (Stephen Lord) wrote: > Date: Sat, 16 Mar 2002 11:43:25 -0600 > To: ude@handshake.de > From: lord@sgi.com (Stephen Lord) > CC: linux-xfs@oss.sgi.com > Subject: Re: Random filesystem corruption [...] > Well, from this it looks like repair might actually fix it. > > Steve I just ran xfs_repair and it did indeed fix the files / directories. Many thanks ! - Sebastian From owner-linux-xfs@oss.sgi.com Sat Mar 16 12:40:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GKelx12198 for linux-xfs-outgoing; Sat, 16 Mar 2002 12:40:47 -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 g2GKdm912159 for ; Sat, 16 Mar 2002 12:39:48 -0800 Received: from localhost (myles@localhost) by uyema.net (8.11.6/8.11.6) with ESMTP id g2GKfBM01167 for ; Sat, 16 Mar 2002 12:41:11 -0800 Date: Sat, 16 Mar 2002 12:41:11 -0800 (PST) From: Myles Uyema To: linux-xfs@oss.sgi.com Subject: oops, 2.4.18-xfs cvs 2002/03/16 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168484060-90843961-1016311271=:1142" 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-90843961-1016311271=:1142 Content-Type: TEXT/PLAIN; charset=US-ASCII This crash is happening on bootup with an SMP kernel. Uniprocessor kernels do not crash on me. I'm using an Abit BP6 dual celeron 500. 2.4.9-sgi-xfs-1.0.2SMP works fine as well. 2.4.17-xfs SMP also worked fine. Custom kernels were built using Redhat 7.2 kgcc (egcs-1.1.2) ksymoops 2.4.1 on i686 2.4.18-xfs. Options used -v /usr/src/myles/linux-2.4.18-xfs/vmlinux (specified) -K (specified) -L (specified) -o /lib/modules/2.4.18-xfs-mp (specified) -m /boot/System.map-2.4.18-xfs-mp (specified) No modules in ksyms, skipping objects Reading Oops report from the terminal invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: 0000004a ebx: cf9bd990 ecx: ffffe0b1 edx: 00002f4e esi: c14d44a0 edi: c14d454c ebp: cf1e3ddc esp: cf1e3dac ds: 0018 es: 0018 ss: 0018 Process identd (pid: 642, stackpage=cf1e3000) Stack: c02d6700 0000006f cf9bd990 c14d44a0 cfc5e800 cf960c90 01c5e800 00000282 00000000 00000000 00000001 00000000 00000000 00000000 00001e2f 00000021 c01c70cf cfc5e800 0001b5b8 cf960c5c cf960c5c cf1e2000 00000000 c01d55ce Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 8a 5c 24 13 86 9e ac 00 00 00 ff 74 24 14 9d >>EIP; c01c81ab <===== Trace; c01c70cf Trace; c01d55ce Trace; c01c19f0 Trace; c01dc245 Trace; c01dc918 Trace; c01e93b4 Trace; c01444e9 Trace; c01427b2 Trace; c014283f Trace; c01075fb Code; c01c81ab 00000000 <_EIP>: Code; c01c81ab <===== 0: 0f 0b ud2a <===== Code; c01c81ad 2: 83 c4 08 add $0x8,%esp Code; c01c81b0 5: 8a 5c 24 13 mov 0x13(%esp,1),%bl Code; c01c81b4 9: 86 9e ac 00 00 00 xchg %bl,0xac(%esi) Code; c01c81ba f: ff 74 24 14 pushl 0x14(%esp,1) Code; c01c81be 13: 9d popf --168484060-90843961-1016311271=:1142 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=".config" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: linux kernel configuration Content-Disposition: attachment; filename=".config" Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBieSBtYWtlIG1lbnVjb25m aWc6IGRvbid0IGVkaXQNCiMNCkNPTkZJR19YODY9eQ0KQ09ORklHX0lTQT15 DQojIENPTkZJR19TQlVTIGlzIG5vdCBzZXQNCkNPTkZJR19VSUQxNj15DQoN CiMNCiMgQ29kZSBtYXR1cml0eSBsZXZlbCBvcHRpb25zDQojDQpDT05GSUdf RVhQRVJJTUVOVEFMPXkNCg0KIw0KIyBMb2FkYWJsZSBtb2R1bGUgc3VwcG9y dA0KIw0KQ09ORklHX01PRFVMRVM9eQ0KQ09ORklHX01PRFZFUlNJT05TPXkN CkNPTkZJR19LTU9EPXkNCg0KIw0KIyBQcm9jZXNzb3IgdHlwZSBhbmQgZmVh dHVyZXMNCiMNCiMgQ09ORklHX00zODYgaXMgbm90IHNldA0KIyBDT05GSUdf TTQ4NiBpcyBub3Qgc2V0DQojIENPTkZJR19NNTg2IGlzIG5vdCBzZXQNCiMg Q09ORklHX001ODZUU0MgaXMgbm90IHNldA0KIyBDT05GSUdfTTU4Nk1NWCBp cyBub3Qgc2V0DQpDT05GSUdfTTY4Nj15DQojIENPTkZJR19NUEVOVElVTUlJ SSBpcyBub3Qgc2V0DQojIENPTkZJR19NUEVOVElVTTQgaXMgbm90IHNldA0K IyBDT05GSUdfTUs2IGlzIG5vdCBzZXQNCiMgQ09ORklHX01LNyBpcyBub3Qg c2V0DQojIENPTkZJR19NRUxBTiBpcyBub3Qgc2V0DQojIENPTkZJR19NQ1JV U09FIGlzIG5vdCBzZXQNCiMgQ09ORklHX01XSU5DSElQQzYgaXMgbm90IHNl dA0KIyBDT05GSUdfTVdJTkNISVAyIGlzIG5vdCBzZXQNCiMgQ09ORklHX01X SU5DSElQM0QgaXMgbm90IHNldA0KIyBDT05GSUdfTUNZUklYSUlJIGlzIG5v dCBzZXQNCkNPTkZJR19YODZfV1BfV09SS1NfT0s9eQ0KQ09ORklHX1g4Nl9J TlZMUEc9eQ0KQ09ORklHX1g4Nl9DTVBYQ0hHPXkNCkNPTkZJR19YODZfWEFE RD15DQpDT05GSUdfWDg2X0JTV0FQPXkNCkNPTkZJR19YODZfUE9QQURfT0s9 eQ0KIyBDT05GSUdfUldTRU1fR0VORVJJQ19TUElOTE9DSyBpcyBub3Qgc2V0 DQpDT05GSUdfUldTRU1fWENIR0FERF9BTEdPUklUSE09eQ0KQ09ORklHX1g4 Nl9MMV9DQUNIRV9TSElGVD01DQpDT05GSUdfWDg2X1RTQz15DQpDT05GSUdf WDg2X0dPT0RfQVBJQz15DQpDT05GSUdfWDg2X1BHRT15DQpDT05GSUdfWDg2 X1VTRV9QUFJPX0NIRUNLU1VNPXkNCkNPTkZJR19YODZfUFBST19GRU5DRT15 DQojIENPTkZJR19UT1NISUJBIGlzIG5vdCBzZXQNCiMgQ09ORklHX0k4SyBp cyBub3Qgc2V0DQpDT05GSUdfTUlDUk9DT0RFPXkNCkNPTkZJR19YODZfTVNS PXkNCkNPTkZJR19YODZfQ1BVSUQ9eQ0KQ09ORklHX05PSElHSE1FTT15DQoj IENPTkZJR19ISUdITUVNNEcgaXMgbm90IHNldA0KIyBDT05GSUdfSElHSE1F TTY0RyBpcyBub3Qgc2V0DQojIENPTkZJR19NQVRIX0VNVUxBVElPTiBpcyBu b3Qgc2V0DQpDT05GSUdfTVRSUj15DQpDT05GSUdfU01QPXkNCiMgQ09ORklH X01VTFRJUVVBRCBpcyBub3Qgc2V0DQpDT05GSUdfSEFWRV9ERUNfTE9DSz15 DQoNCiMNCiMgR2VuZXJhbCBzZXR1cA0KIw0KQ09ORklHX05FVD15DQpDT05G SUdfWDg2X0lPX0FQSUM9eQ0KQ09ORklHX1g4Nl9MT0NBTF9BUElDPXkNCkNP TkZJR19QQ0k9eQ0KIyBDT05GSUdfUENJX0dPQklPUyBpcyBub3Qgc2V0DQoj IENPTkZJR19QQ0lfR09ESVJFQ1QgaXMgbm90IHNldA0KQ09ORklHX1BDSV9H T0FOWT15DQpDT05GSUdfUENJX0JJT1M9eQ0KQ09ORklHX1BDSV9ESVJFQ1Q9 eQ0KQ09ORklHX1BDSV9OQU1FUz15DQojIENPTkZJR19FSVNBIGlzIG5vdCBz ZXQNCiMgQ09ORklHX01DQSBpcyBub3Qgc2V0DQojIENPTkZJR19IT1RQTFVH IGlzIG5vdCBzZXQNCiMgQ09ORklHX1BDTUNJQSBpcyBub3Qgc2V0DQojIENP TkZJR19IT1RQTFVHX1BDSSBpcyBub3Qgc2V0DQpDT05GSUdfU1lTVklQQz15 DQpDT05GSUdfQlNEX1BST0NFU1NfQUNDVD15DQpDT05GSUdfU1lTQ1RMPXkN CkNPTkZJR19LQ09SRV9FTEY9eQ0KIyBDT05GSUdfS0NPUkVfQU9VVCBpcyBu b3Qgc2V0DQojIENPTkZJR19CSU5GTVRfQU9VVCBpcyBub3Qgc2V0DQpDT05G SUdfQklORk1UX0VMRj15DQpDT05GSUdfQklORk1UX01JU0M9eQ0KIyBDT05G SUdfUE0gaXMgbm90IHNldA0KIyBDT05GSUdfQUNQSSBpcyBub3Qgc2V0DQoj IENPTkZJR19BUE0gaXMgbm90IHNldA0KDQojDQojIE1lbW9yeSBUZWNobm9s b2d5IERldmljZXMgKE1URCkNCiMNCiMgQ09ORklHX01URCBpcyBub3Qgc2V0 DQoNCiMNCiMgUGFyYWxsZWwgcG9ydCBzdXBwb3J0DQojDQojIENPTkZJR19Q QVJQT1JUIGlzIG5vdCBzZXQNCg0KIw0KIyBQbHVnIGFuZCBQbGF5IGNvbmZp Z3VyYXRpb24NCiMNCkNPTkZJR19QTlA9eQ0KIyBDT05GSUdfSVNBUE5QIGlz IG5vdCBzZXQNCg0KIw0KIyBCbG9jayBkZXZpY2VzDQojDQpDT05GSUdfQkxL X0RFVl9GRD15DQojIENPTkZJR19CTEtfREVWX1hEIGlzIG5vdCBzZXQNCiMg Q09ORklHX1BBUklERSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfQ1BRX0RB IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19DUFFfQ0lTU19EQSBpcyBub3Qg c2V0DQojIENPTkZJR19CTEtfREVWX0RBQzk2MCBpcyBub3Qgc2V0DQpDT05G SUdfQkxLX0RFVl9MT09QPW0NCkNPTkZJR19CTEtfREVWX05CRD1tDQpDT05G SUdfQkxLX0RFVl9SQU09bQ0KQ09ORklHX0JMS19ERVZfUkFNX1NJWkU9NDA5 Ng0KIyBDT05GSUdfQkxLX0RFVl9JTklUUkQgaXMgbm90IHNldA0KDQojDQoj IE11bHRpLWRldmljZSBzdXBwb3J0IChSQUlEIGFuZCBMVk0pDQojDQpDT05G SUdfTUQ9eQ0KQ09ORklHX0JMS19ERVZfTUQ9eQ0KQ09ORklHX01EX0xJTkVB Uj1tDQpDT05GSUdfTURfUkFJRDA9bQ0KQ09ORklHX01EX1JBSUQxPXkNCkNP TkZJR19NRF9SQUlENT1tDQpDT05GSUdfTURfTVVMVElQQVRIPW0NCkNPTkZJ R19CTEtfREVWX0xWTT15DQoNCiMNCiMgTmV0d29ya2luZyBvcHRpb25zDQoj DQpDT05GSUdfUEFDS0VUPXkNCkNPTkZJR19QQUNLRVRfTU1BUD15DQpDT05G SUdfTkVUTElOS19ERVY9bQ0KQ09ORklHX05FVEZJTFRFUj15DQojIENPTkZJ R19ORVRGSUxURVJfREVCVUcgaXMgbm90IHNldA0KQ09ORklHX0ZJTFRFUj15 DQpDT05GSUdfVU5JWD15DQpDT05GSUdfSU5FVD15DQpDT05GSUdfSVBfTVVM VElDQVNUPXkNCiMgQ09ORklHX0lQX0FEVkFOQ0VEX1JPVVRFUiBpcyBub3Qg c2V0DQojIENPTkZJR19JUF9QTlAgaXMgbm90IHNldA0KQ09ORklHX05FVF9J UElQPW0NCkNPTkZJR19ORVRfSVBHUkU9bQ0KQ09ORklHX05FVF9JUEdSRV9C Uk9BRENBU1Q9eQ0KQ09ORklHX0lQX01ST1VURT15DQpDT05GSUdfSVBfUElN U01fVjE9eQ0KQ09ORklHX0lQX1BJTVNNX1YyPXkNCiMgQ09ORklHX0FSUEQg aXMgbm90IHNldA0KQ09ORklHX0lORVRfRUNOPXkNCkNPTkZJR19TWU5fQ09P S0lFUz15DQoNCiMNCiMgICBJUDogTmV0ZmlsdGVyIENvbmZpZ3VyYXRpb24N CiMNCkNPTkZJR19JUF9ORl9DT05OVFJBQ0s9bQ0KQ09ORklHX0lQX05GX0ZU UD1tDQpDT05GSUdfSVBfTkZfSVJDPW0NCkNPTkZJR19JUF9ORl9RVUVVRT1t DQpDT05GSUdfSVBfTkZfSVBUQUJMRVM9bQ0KQ09ORklHX0lQX05GX01BVENI X0xJTUlUPW0NCkNPTkZJR19JUF9ORl9NQVRDSF9NQUM9bQ0KQ09ORklHX0lQ X05GX01BVENIX01BUks9bQ0KQ09ORklHX0lQX05GX01BVENIX01VTFRJUE9S VD1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfVE9TPW0NCkNPTkZJR19JUF9ORl9N QVRDSF9BSF9FU1A9bQ0KQ09ORklHX0lQX05GX01BVENIX0xFTkdUSD1tDQpD T05GSUdfSVBfTkZfTUFUQ0hfVFRMPW0NCkNPTkZJR19JUF9ORl9NQVRDSF9U Q1BNU1M9bQ0KQ09ORklHX0lQX05GX01BVENIX1NUQVRFPW0NCkNPTkZJR19J UF9ORl9NQVRDSF9VTkNMRUFOPW0NCkNPTkZJR19JUF9ORl9NQVRDSF9PV05F Uj1tDQpDT05GSUdfSVBfTkZfRklMVEVSPW0NCkNPTkZJR19JUF9ORl9UQVJH RVRfUkVKRUNUPW0NCkNPTkZJR19JUF9ORl9UQVJHRVRfTUlSUk9SPW0NCkNP TkZJR19JUF9ORl9OQVQ9bQ0KQ09ORklHX0lQX05GX05BVF9ORUVERUQ9eQ0K Q09ORklHX0lQX05GX1RBUkdFVF9NQVNRVUVSQURFPW0NCkNPTkZJR19JUF9O Rl9UQVJHRVRfUkVESVJFQ1Q9bQ0KQ09ORklHX0lQX05GX05BVF9TTk1QX0JB U0lDPW0NCkNPTkZJR19JUF9ORl9OQVRfSVJDPW0NCkNPTkZJR19JUF9ORl9O QVRfRlRQPW0NCkNPTkZJR19JUF9ORl9NQU5HTEU9bQ0KQ09ORklHX0lQX05G X1RBUkdFVF9UT1M9bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9NQVJLPW0NCkNP TkZJR19JUF9ORl9UQVJHRVRfTE9HPW0NCkNPTkZJR19JUF9ORl9UQVJHRVRf VENQTVNTPW0NCiMgQ09ORklHX0lQX05GX0NPTVBBVF9JUENIQUlOUyBpcyBu b3Qgc2V0DQojIENPTkZJR19JUF9ORl9DT01QQVRfSVBGV0FETSBpcyBub3Qg c2V0DQpDT05GSUdfSVBWNj1tDQoNCiMNCiMgICBJUHY2OiBOZXRmaWx0ZXIg Q29uZmlndXJhdGlvbg0KIw0KQ09ORklHX0lQNl9ORl9RVUVVRT1tDQpDT05G SUdfSVA2X05GX0lQVEFCTEVTPW0NCkNPTkZJR19JUDZfTkZfTUFUQ0hfTElN SVQ9bQ0KQ09ORklHX0lQNl9ORl9NQVRDSF9NQUM9bQ0KQ09ORklHX0lQNl9O Rl9NQVRDSF9NVUxUSVBPUlQ9bQ0KQ09ORklHX0lQNl9ORl9NQVRDSF9PV05F Uj1tDQpDT05GSUdfSVA2X05GX01BVENIX01BUks9bQ0KQ09ORklHX0lQNl9O Rl9GSUxURVI9bQ0KQ09ORklHX0lQNl9ORl9UQVJHRVRfTE9HPW0NCkNPTkZJ R19JUDZfTkZfTUFOR0xFPW0NCkNPTkZJR19JUDZfTkZfVEFSR0VUX01BUks9 bQ0KIyBDT05GSUdfS0hUVFBEIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FUTSBp cyBub3Qgc2V0DQpDT05GSUdfVkxBTl84MDIxUT1tDQojIENPTkZJR19JUFgg aXMgbm90IHNldA0KIyBDT05GSUdfQVRBTEsgaXMgbm90IHNldA0KIyBDT05G SUdfREVDTkVUIGlzIG5vdCBzZXQNCkNPTkZJR19CUklER0U9bQ0KIyBDT05G SUdfWDI1IGlzIG5vdCBzZXQNCiMgQ09ORklHX0xBUEIgaXMgbm90IHNldA0K IyBDT05GSUdfTExDIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9ESVZFUlQg aXMgbm90IHNldA0KIyBDT05GSUdfRUNPTkVUIGlzIG5vdCBzZXQNCiMgQ09O RklHX1dBTl9ST1VURVIgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX0ZBU1RS T1VURSBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfSFdfRkxPV0NPTlRST0wg aXMgbm90IHNldA0KDQojDQojIFFvUyBhbmQvb3IgZmFpciBxdWV1ZWluZw0K Iw0KIyBDT05GSUdfTkVUX1NDSEVEIGlzIG5vdCBzZXQNCg0KIw0KIyBUZWxl cGhvbnkgU3VwcG9ydA0KIw0KIyBDT05GSUdfUEhPTkUgaXMgbm90IHNldA0K IyBDT05GSUdfUEhPTkVfSVhKIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BIT05F X0lYSl9QQ01DSUEgaXMgbm90IHNldA0KDQojDQojIEFUQS9JREUvTUZNL1JM TCBzdXBwb3J0DQojDQpDT05GSUdfSURFPXkNCg0KIw0KIyBJREUsIEFUQSBh bmQgQVRBUEkgQmxvY2sgZGV2aWNlcw0KIw0KQ09ORklHX0JMS19ERVZfSURF PW0NCiMgQ09ORklHX0JMS19ERVZfSERfSURFIGlzIG5vdCBzZXQNCiMgQ09O RklHX0JMS19ERVZfSEQgaXMgbm90IHNldA0KQ09ORklHX0JMS19ERVZfSURF RElTSz1tDQpDT05GSUdfSURFRElTS19NVUxUSV9NT0RFPXkNCiMgQ09ORklH X0JMS19ERVZfSURFRElTS19WRU5ET1IgaXMgbm90IHNldA0KIyBDT05GSUdf QkxLX0RFVl9JREVESVNLX0ZVSklUU1UgaXMgbm90IHNldA0KIyBDT05GSUdf QkxLX0RFVl9JREVESVNLX0lCTSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf REVWX0lERURJU0tfTUFYVE9SIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19E RVZfSURFRElTS19RVUFOVFVNIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19E RVZfSURFRElTS19TRUFHQVRFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19E RVZfSURFRElTS19XRCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0NP TU1FUklBTCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX1RJVk8gaXMg bm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9JREVDUyBpcyBub3Qgc2V0DQpD T05GSUdfQkxLX0RFVl9JREVDRD1tDQpDT05GSUdfQkxLX0RFVl9JREVUQVBF PW0NCkNPTkZJR19CTEtfREVWX0lERUZMT1BQWT1tDQpDT05GSUdfQkxLX0RF Vl9JREVTQ1NJPW0NCkNPTkZJR19CTEtfREVWX0NNRDY0MD15DQojIENPTkZJ R19CTEtfREVWX0NNRDY0MF9FTkhBTkNFRCBpcyBub3Qgc2V0DQojIENPTkZJ R19CTEtfREVWX0lTQVBOUCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9S WjEwMDA9eQ0KQ09ORklHX0JMS19ERVZfSURFUENJPXkNCkNPTkZJR19JREVQ Q0lfU0hBUkVfSVJRPXkNCkNPTkZJR19CTEtfREVWX0lERURNQV9QQ0k9eQ0K Q09ORklHX0JMS19ERVZfQURNQT15DQojIENPTkZJR19CTEtfREVWX09GRkJP QVJEIGlzIG5vdCBzZXQNCkNPTkZJR19JREVETUFfUENJX0FVVE89eQ0KQ09O RklHX0JMS19ERVZfSURFRE1BPXkNCiMgQ09ORklHX0lERURNQV9QQ0lfV0lQ IGlzIG5vdCBzZXQNCiMgQ09ORklHX0lERURNQV9ORVdfRFJJVkVfTElTVElO R1MgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9BRUM2MlhYIGlzIG5v dCBzZXQNCiMgQ09ORklHX0FFQzYyWFhfVFVOSU5HIGlzIG5vdCBzZXQNCiMg Q09ORklHX0JMS19ERVZfQUxJMTVYMyBpcyBub3Qgc2V0DQojIENPTkZJR19X RENfQUxJMTVYMyBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0FNRDc0 WFggaXMgbm90IHNldA0KIyBDT05GSUdfQU1ENzRYWF9PVkVSUklERSBpcyBu b3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0NNRDY0WCBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfREVWX0NZODJDNjkzIGlzIG5vdCBzZXQNCiMgQ09ORklH X0JMS19ERVZfQ1M1NTMwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZf SFBUMzRYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hQVDM0WF9BVVRPRE1BIGlz IG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSFBUMzY2IGlzIG5vdCBzZXQN CkNPTkZJR19CTEtfREVWX1BJSVg9eQ0KQ09ORklHX1BJSVhfVFVOSU5HPXkN CiMgQ09ORklHX0JMS19ERVZfTlM4NzQxNSBpcyBub3Qgc2V0DQojIENPTkZJ R19CTEtfREVWX09QVEk2MjEgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RF Vl9QREMyMDJYWCBpcyBub3Qgc2V0DQojIENPTkZJR19QREMyMDJYWF9CVVJT VCBpcyBub3Qgc2V0DQojIENPTkZJR19QREMyMDJYWF9GT1JDRSBpcyBub3Qg c2V0DQojIENPTkZJR19CTEtfREVWX1NWV0tTIGlzIG5vdCBzZXQNCiMgQ09O RklHX0JMS19ERVZfU0lTNTUxMyBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf REVWX1NMQzkwRTY2IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfVFJN MjkwIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX1ZJQTgyQ1hYWD15DQoj IENPTkZJR19JREVfQ0hJUFNFVFMgaXMgbm90IHNldA0KQ09ORklHX0lERURN QV9BVVRPPXkNCiMgQ09ORklHX0lERURNQV9JVkIgaXMgbm90IHNldA0KIyBD T05GSUdfRE1BX05PTlBDSSBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9J REVfTU9ERVM9eQ0KIyBDT05GSUdfQkxLX0RFVl9BVEFSQUlEIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0JMS19ERVZfQVRBUkFJRF9QREMgaXMgbm90IHNldA0K IyBDT05GSUdfQkxLX0RFVl9BVEFSQUlEX0hQVCBpcyBub3Qgc2V0DQoNCiMN CiMgU0NTSSBzdXBwb3J0DQojDQpDT05GSUdfU0NTST15DQpDT05GSUdfQkxL X0RFVl9TRD15DQpDT05GSUdfU0RfRVhUUkFfREVWUz00MA0KQ09ORklHX0NI Ul9ERVZfU1Q9bQ0KQ09ORklHX0NIUl9ERVZfT1NTVD1tDQpDT05GSUdfQkxL X0RFVl9TUj1tDQojIENPTkZJR19CTEtfREVWX1NSX1ZFTkRPUiBpcyBub3Qg c2V0DQpDT05GSUdfU1JfRVhUUkFfREVWUz0yDQpDT05GSUdfQ0hSX0RFVl9T Rz1tDQpDT05GSUdfU0NTSV9ERUJVR19RVUVVRVM9eQ0KQ09ORklHX1NDU0lf TVVMVElfTFVOPXkNCkNPTkZJR19TQ1NJX0NPTlNUQU5UUz15DQojIENPTkZJ R19TQ1NJX0xPR0dJTkcgaXMgbm90IHNldA0KDQojDQojIFNDU0kgbG93LWxl dmVsIGRyaXZlcnMNCiMNCiMgQ09ORklHX0JMS19ERVZfM1dfWFhYWF9SQUlE IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfNzAwMEZBU1NUIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1NDU0lfQUNBUkQgaXMgbm90IHNldA0KIyBDT05GSUdf U0NTSV9BSEExNTJYIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfQUhBMTU0 MiBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FIQTE3NDAgaXMgbm90IHNl dA0KIyBDT05GSUdfU0NTSV9BQUNSQUlEIGlzIG5vdCBzZXQNCiMgQ09ORklH X1NDU0lfQUlDN1hYWCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0FJQzdY WFhfT0xEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfRFBUX0kyTyBpcyBu b3Qgc2V0DQojIENPTkZJR19TQ1NJX0FEVkFOU1lTIGlzIG5vdCBzZXQNCiMg Q09ORklHX1NDU0lfSU4yMDAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lf QU01M0M5NzQgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9NRUdBUkFJRCBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0JVU0xPR0lDIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NDU0lfQ1BRRkNUUyBpcyBub3Qgc2V0DQojIENPTkZJR19T Q1NJX0RNWDMxOTFEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfRFRDMzI4 MCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0VBVEEgaXMgbm90IHNldA0K IyBDT05GSUdfU0NTSV9FQVRBX0RNQSBpcyBub3Qgc2V0DQojIENPTkZJR19T Q1NJX0VBVEFfUElPIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfRlVUVVJF X0RPTUFJTiBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0dEVEggaXMgbm90 IHNldA0KIyBDT05GSUdfU0NTSV9HRU5FUklDX05DUjUzODAgaXMgbm90IHNl dA0KIyBDT05GSUdfU0NTSV9JUFMgaXMgbm90IHNldA0KIyBDT05GSUdfU0NT SV9JTklUSU8gaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9JTklBMTAwIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfTkNSNTNDNDA2QSBpcyBub3Qgc2V0 DQojIENPTkZJR19TQ1NJX05DUjUzQzd4eCBpcyBub3Qgc2V0DQpDT05GSUdf U0NTSV9TWU01M0M4WFhfMj15DQpDT05GSUdfU0NTSV9TWU01M0M4WFhfRE1B X0FERFJFU1NJTkdfTU9ERT0xDQpDT05GSUdfU0NTSV9TWU01M0M4WFhfREVG QVVMVF9UQUdTPTE2DQpDT05GSUdfU0NTSV9TWU01M0M4WFhfTUFYX1RBR1M9 NjQNCiMgQ09ORklHX1NDU0lfU1lNNTNDOFhYX0lPTUFQUEVEIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1NDU0lfUEFTMTYgaXMgbm90IHNldA0KIyBDT05GSUdf U0NTSV9QQ0kyMDAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUENJMjIy MEkgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9QU0kyNDBJIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1NDU0lfUUxPR0lDX0ZBUyBpcyBub3Qgc2V0DQojIENP TkZJR19TQ1NJX1FMT0dJQ19JU1AgaXMgbm90IHNldA0KIyBDT05GSUdfU0NT SV9RTE9HSUNfRkMgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9RTE9HSUNf MTI4MCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1NFQUdBVEUgaXMgbm90 IHNldA0KIyBDT05GSUdfU0NTSV9TSU03MTAgaXMgbm90IHNldA0KIyBDT05G SUdfU0NTSV9TWU01M0M0MTYgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9E QzM5MFQgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9UMTI4IGlzIG5vdCBz ZXQNCiMgQ09ORklHX1NDU0lfVTE0XzM0RiBpcyBub3Qgc2V0DQojIENPTkZJ R19TQ1NJX1VMVFJBU1RPUiBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0RF QlVHIGlzIG5vdCBzZXQNCg0KIw0KIyBGdXNpb24gTVBUIGRldmljZSBzdXBw b3J0DQojDQojIENPTkZJR19GVVNJT04gaXMgbm90IHNldA0KIyBDT05GSUdf RlVTSU9OX0JPT1QgaXMgbm90IHNldA0KIyBDT05GSUdfRlVTSU9OX0lTRU5T RSBpcyBub3Qgc2V0DQojIENPTkZJR19GVVNJT05fQ1RMIGlzIG5vdCBzZXQN CiMgQ09ORklHX0ZVU0lPTl9MQU4gaXMgbm90IHNldA0KDQojDQojIElFRUUg MTM5NCAoRmlyZVdpcmUpIHN1cHBvcnQgKEVYUEVSSU1FTlRBTCkNCiMNCiMg Q09ORklHX0lFRUUxMzk0IGlzIG5vdCBzZXQNCg0KIw0KIyBJMk8gZGV2aWNl IHN1cHBvcnQNCiMNCiMgQ09ORklHX0kyTyBpcyBub3Qgc2V0DQojIENPTkZJ R19JMk9fUENJIGlzIG5vdCBzZXQNCiMgQ09ORklHX0kyT19CTE9DSyBpcyBu b3Qgc2V0DQojIENPTkZJR19JMk9fTEFOIGlzIG5vdCBzZXQNCiMgQ09ORklH X0kyT19TQ1NJIGlzIG5vdCBzZXQNCiMgQ09ORklHX0kyT19QUk9DIGlzIG5v dCBzZXQNCg0KIw0KIyBOZXR3b3JrIGRldmljZSBzdXBwb3J0DQojDQpDT05G SUdfTkVUREVWSUNFUz15DQoNCiMNCiMgQVJDbmV0IGRldmljZXMNCiMNCiMg Q09ORklHX0FSQ05FVCBpcyBub3Qgc2V0DQpDT05GSUdfRFVNTVk9bQ0KQ09O RklHX0JPTkRJTkc9bQ0KQ09ORklHX0VRVUFMSVpFUj1tDQpDT05GSUdfVFVO PW0NCkNPTkZJR19FVEhFUlRBUD1tDQoNCiMNCiMgRXRoZXJuZXQgKDEwIG9y IDEwME1iaXQpDQojDQpDT05GSUdfTkVUX0VUSEVSTkVUPXkNCiMgQ09ORklH X1NVTkxBTkNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hBUFBZTUVBTCBpcyBu b3Qgc2V0DQojIENPTkZJR19TVU5CTUFDIGlzIG5vdCBzZXQNCiMgQ09ORklH X1NVTlFFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NVTkdFTSBpcyBub3Qgc2V0 DQojIENPTkZJR19ORVRfVkVORE9SXzNDT00gaXMgbm90IHNldA0KIyBDT05G SUdfTEFOQ0UgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX1ZFTkRPUl9TTUMg aXMgbm90IHNldA0KIyBDT05GSUdfTkVUX1ZFTkRPUl9SQUNBTCBpcyBub3Qg c2V0DQojIENPTkZJR19BVDE3MDAgaXMgbm90IHNldA0KIyBDT05GSUdfREVQ Q0EgaXMgbm90IHNldA0KIyBDT05GSUdfSFAxMDAgaXMgbm90IHNldA0KIyBD T05GSUdfTkVUX0lTQSBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX1BDST15DQoj IENPTkZJR19QQ05FVDMyIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FEQVBURUNf U1RBUkZJUkUgaXMgbm90IHNldA0KIyBDT05GSUdfQUMzMjAwIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0FQUklDT1QgaXMgbm90IHNldA0KIyBDT05GSUdfQ1M4 OXgwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RVTElQIGlzIG5vdCBzZXQNCiMg Q09ORklHX0RFNFg1IGlzIG5vdCBzZXQNCiMgQ09ORklHX0RHUlMgaXMgbm90 IHNldA0KIyBDT05GSUdfRE05MTAyIGlzIG5vdCBzZXQNCkNPTkZJR19FRVBS TzEwMD15DQojIENPTkZJR19MTkUzOTAgaXMgbm90IHNldA0KIyBDT05GSUdf RkVBTE5YIGlzIG5vdCBzZXQNCiMgQ09ORklHX05BVFNFTUkgaXMgbm90IHNl dA0KIyBDT05GSUdfTkUyS19QQ0kgaXMgbm90IHNldA0KIyBDT05GSUdfTkUz MjEwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VTMzIxMCBpcyBub3Qgc2V0DQoj IENPTkZJR184MTM5Q1AgaXMgbm90IHNldA0KIyBDT05GSUdfODEzOVRPTyBp cyBub3Qgc2V0DQojIENPTkZJR184MTM5VE9PX1BJTyBpcyBub3Qgc2V0DQoj IENPTkZJR184MTM5VE9PX1RVTkVfVFdJU1RFUiBpcyBub3Qgc2V0DQojIENP TkZJR184MTM5VE9PXzgxMjkgaXMgbm90IHNldA0KIyBDT05GSUdfODEzOV9O RVdfUlhfUkVTRVQgaXMgbm90IHNldA0KIyBDT05GSUdfU0lTOTAwIGlzIG5v dCBzZXQNCiMgQ09ORklHX0VQSUMxMDAgaXMgbm90IHNldA0KIyBDT05GSUdf U1VOREFOQ0UgaXMgbm90IHNldA0KIyBDT05GSUdfVExBTiBpcyBub3Qgc2V0 DQojIENPTkZJR19WSUFfUkhJTkUgaXMgbm90IHNldA0KIyBDT05GSUdfVklB X1JISU5FX01NSU8gaXMgbm90IHNldA0KIyBDT05GSUdfV0lOQk9ORF84NDAg aXMgbm90IHNldA0KIyBDT05GSUdfTkVUX1BPQ0tFVCBpcyBub3Qgc2V0DQoN CiMNCiMgRXRoZXJuZXQgKDEwMDAgTWJpdCkNCiMNCiMgQ09ORklHX0FDRU5J QyBpcyBub3Qgc2V0DQojIENPTkZJR19ETDJLIGlzIG5vdCBzZXQNCiMgQ09O RklHX01ZUklfU0JVUyBpcyBub3Qgc2V0DQojIENPTkZJR19OUzgzODIwIGlz IG5vdCBzZXQNCiMgQ09ORklHX0hBTUFDSEkgaXMgbm90IHNldA0KIyBDT05G SUdfWUVMTE9XRklOIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NLOThMSU4gaXMg bm90IHNldA0KIyBDT05GSUdfRkRESSBpcyBub3Qgc2V0DQojIENPTkZJR19I SVBQSSBpcyBub3Qgc2V0DQojIENPTkZJR19QTElQIGlzIG5vdCBzZXQNCkNP TkZJR19QUFA9bQ0KQ09ORklHX1BQUF9NVUxUSUxJTks9eQ0KQ09ORklHX1BQ UF9GSUxURVI9eQ0KQ09ORklHX1BQUF9BU1lOQz1tDQpDT05GSUdfUFBQX1NZ TkNfVFRZPW0NCkNPTkZJR19QUFBfREVGTEFURT1tDQpDT05GSUdfUFBQX0JT RENPTVA9bQ0KQ09ORklHX1BQUE9FPW0NCiMgQ09ORklHX1NMSVAgaXMgbm90 IHNldA0KDQojDQojIFdpcmVsZXNzIExBTiAobm9uLWhhbXJhZGlvKQ0KIw0K IyBDT05GSUdfTkVUX1JBRElPIGlzIG5vdCBzZXQNCg0KIw0KIyBUb2tlbiBS aW5nIGRldmljZXMNCiMNCiMgQ09ORklHX1RSIGlzIG5vdCBzZXQNCiMgQ09O RklHX05FVF9GQyBpcyBub3Qgc2V0DQpDT05GSUdfUkNQQ0k9bQ0KQ09ORklH X1NIQVBFUj1tDQoNCiMNCiMgV2FuIGludGVyZmFjZXMNCiMNCiMgQ09ORklH X1dBTiBpcyBub3Qgc2V0DQoNCiMNCiMgQW1hdGV1ciBSYWRpbyBzdXBwb3J0 DQojDQojIENPTkZJR19IQU1SQURJTyBpcyBub3Qgc2V0DQoNCiMNCiMgSXJE QSAoaW5mcmFyZWQpIHN1cHBvcnQNCiMNCiMgQ09ORklHX0lSREEgaXMgbm90 IHNldA0KDQojDQojIElTRE4gc3Vic3lzdGVtDQojDQojIENPTkZJR19JU0RO IGlzIG5vdCBzZXQNCg0KIw0KIyBPbGQgQ0QtUk9NIGRyaXZlcnMgKG5vdCBT Q1NJLCBub3QgSURFKQ0KIw0KIyBDT05GSUdfQ0RfTk9fSURFU0NTSSBpcyBu b3Qgc2V0DQoNCiMNCiMgSW5wdXQgY29yZSBzdXBwb3J0DQojDQojIENPTkZJ R19JTlBVVCBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9LRVlCREVWIGlz IG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX01PVVNFREVWIGlzIG5vdCBzZXQN CiMgQ09ORklHX0lOUFVUX0pPWURFViBpcyBub3Qgc2V0DQojIENPTkZJR19J TlBVVF9FVkRFViBpcyBub3Qgc2V0DQoNCiMNCiMgQ2hhcmFjdGVyIGRldmlj ZXMNCiMNCkNPTkZJR19WVD15DQpDT05GSUdfVlRfQ09OU09MRT15DQpDT05G SUdfU0VSSUFMPXkNCkNPTkZJR19TRVJJQUxfQ09OU09MRT15DQojIENPTkZJ R19TRVJJQUxfRVhURU5ERUQgaXMgbm90IHNldA0KIyBDT05GSUdfU0VSSUFM X05PTlNUQU5EQVJEIGlzIG5vdCBzZXQNCkNPTkZJR19VTklYOThfUFRZUz15 DQpDT05GSUdfVU5JWDk4X1BUWV9DT1VOVD0yNTYNCg0KIw0KIyBJMkMgc3Vw cG9ydA0KIw0KIyBDT05GSUdfSTJDIGlzIG5vdCBzZXQNCg0KIw0KIyBNaWNl DQojDQojIENPTkZJR19CVVNNT1VTRSBpcyBub3Qgc2V0DQpDT05GSUdfTU9V U0U9eQ0KQ09ORklHX1BTTU9VU0U9eQ0KIyBDT05GSUdfODJDNzEwX01PVVNF IGlzIG5vdCBzZXQNCiMgQ09ORklHX1BDMTEwX1BBRCBpcyBub3Qgc2V0DQoN CiMNCiMgSm95c3RpY2tzDQojDQojIENPTkZJR19JTlBVVF9HQU1FUE9SVCBp cyBub3Qgc2V0DQojIENPTkZJR19RSUMwMl9UQVBFIGlzIG5vdCBzZXQNCg0K Iw0KIyBXYXRjaGRvZyBDYXJkcw0KIw0KIyBDT05GSUdfV0FUQ0hET0cgaXMg bm90IHNldA0KIyBDT05GSUdfSU5URUxfUk5HIGlzIG5vdCBzZXQNCkNPTkZJ R19OVlJBTT15DQpDT05GSUdfUlRDPXkNCiMgQ09ORklHX0RUTEsgaXMgbm90 IHNldA0KIyBDT05GSUdfUjM5NjQgaXMgbm90IHNldA0KIyBDT05GSUdfQVBQ TElDT00gaXMgbm90IHNldA0KIyBDT05GSUdfU09OWVBJIGlzIG5vdCBzZXQN Cg0KIw0KIyBGdGFwZSwgdGhlIGZsb3BweSB0YXBlIGRldmljZSBkcml2ZXIN CiMNCiMgQ09ORklHX0ZUQVBFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FHUCBp cyBub3Qgc2V0DQojIENPTkZJR19EUk0gaXMgbm90IHNldA0KIyBDT05GSUdf TVdBVkUgaXMgbm90IHNldA0KDQojDQojIE11bHRpbWVkaWEgZGV2aWNlcw0K Iw0KIyBDT05GSUdfVklERU9fREVWIGlzIG5vdCBzZXQNCg0KIw0KIyBGaWxl IHN5c3RlbXMNCiMNCkNPTkZJR19GU19QT1NJWF9BQ0w9eQ0KQ09ORklHX1FV T1RBPXkNCiMgQ09ORklHX1FGTVRfVjEgaXMgbm90IHNldA0KQ09ORklHX1FG TVRfVjI9eQ0KIyBDT05GSUdfUUlGQUNFX0NPTVBBVCBpcyBub3Qgc2V0DQoj IENPTkZJR19BVVRPRlNfRlMgaXMgbm90IHNldA0KQ09ORklHX0FVVE9GUzRf RlM9eQ0KQ09ORklHX1JFSVNFUkZTX0ZTPW0NCiMgQ09ORklHX1JFSVNFUkZT X0NIRUNLIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFSVNFUkZTX1BST0NfSU5G TyBpcyBub3Qgc2V0DQojIENPTkZJR19BREZTX0ZTIGlzIG5vdCBzZXQNCiMg Q09ORklHX0FERlNfRlNfUlcgaXMgbm90IHNldA0KIyBDT05GSUdfQUZGU19G UyBpcyBub3Qgc2V0DQojIENPTkZJR19IRlNfRlMgaXMgbm90IHNldA0KIyBD T05GSUdfQkZTX0ZTIGlzIG5vdCBzZXQNCkNPTkZJR19FWFQzX0ZTPW0NCkNP TkZJR19KQkQ9bQ0KIyBDT05GSUdfSkJEX0RFQlVHIGlzIG5vdCBzZXQNCiMg Q09ORklHX0ZBVF9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19NU0RPU19GUyBp cyBub3Qgc2V0DQojIENPTkZJR19VTVNET1NfRlMgaXMgbm90IHNldA0KIyBD T05GSUdfVkZBVF9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19FRlNfRlMgaXMg bm90IHNldA0KIyBDT05GSUdfSkZGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJ R19KRkZTMl9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19DUkFNRlMgaXMgbm90 IHNldA0KQ09ORklHX1RNUEZTPXkNCiMgQ09ORklHX1JBTUZTIGlzIG5vdCBz ZXQNCkNPTkZJR19JU085NjYwX0ZTPXkNCiMgQ09ORklHX0pPTElFVCBpcyBu b3Qgc2V0DQojIENPTkZJR19aSVNPRlMgaXMgbm90IHNldA0KIyBDT05GSUdf TUlOSVhfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfVlhGU19GUyBpcyBub3Qg c2V0DQpDT05GSUdfTlRGU19GUz1tDQojIENPTkZJR19OVEZTX1JXIGlzIG5v dCBzZXQNCiMgQ09ORklHX0hQRlNfRlMgaXMgbm90IHNldA0KQ09ORklHX1BS T0NfRlM9eQ0KIyBDT05GSUdfREVWRlNfRlMgaXMgbm90IHNldA0KIyBDT05G SUdfREVWRlNfTU9VTlQgaXMgbm90IHNldA0KIyBDT05GSUdfREVWRlNfREVC VUcgaXMgbm90IHNldA0KQ09ORklHX0RFVlBUU19GUz15DQojIENPTkZJR19R Tlg0RlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfUU5YNEZTX1JXIGlzIG5v dCBzZXQNCiMgQ09ORklHX1JPTUZTX0ZTIGlzIG5vdCBzZXQNCkNPTkZJR19F WFQyX0ZTPW0NCiMgQ09ORklHX1NZU1ZfRlMgaXMgbm90IHNldA0KQ09ORklH X1VERl9GUz1tDQpDT05GSUdfVURGX1JXPXkNCkNPTkZJR19VRlNfRlM9bQ0K Q09ORklHX1VGU19GU19XUklURT15DQpDT05GSUdfWEZTX0ZTPXkNCiMgQ09O RklHX1hGU19SVCBpcyBub3Qgc2V0DQpDT05GSUdfWEZTX1FVT1RBPXkNCiMg Q09ORklHX1hGU19ETUFQSSBpcyBub3Qgc2V0DQoNCiMNCiMgTmV0d29yayBG aWxlIFN5c3RlbXMNCiMNCiMgQ09ORklHX0NPREFfRlMgaXMgbm90IHNldA0K IyBDT05GSUdfSU5URVJNRVpaT19GUyBpcyBub3Qgc2V0DQpDT05GSUdfTkZT X0ZTPW0NCkNPTkZJR19ORlNfVjM9eQ0KIyBDT05GSUdfUk9PVF9ORlMgaXMg bm90IHNldA0KQ09ORklHX05GU0Q9bQ0KQ09ORklHX05GU0RfVjM9eQ0KQ09O RklHX1NVTlJQQz1tDQpDT05GSUdfTE9DS0Q9bQ0KQ09ORklHX0xPQ0tEX1Y0 PXkNCkNPTkZJR19TTUJfRlM9bQ0KQ09ORklHX1NNQl9OTFNfREVGQVVMVD15 DQpDT05GSUdfU01CX05MU19SRU1PVEU9ImNwNDM3Ig0KIyBDT05GSUdfTkNQ X0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX05DUEZTX1BBQ0tFVF9TSUdOSU5H IGlzIG5vdCBzZXQNCiMgQ09ORklHX05DUEZTX0lPQ1RMX0xPQ0tJTkcgaXMg bm90IHNldA0KIyBDT05GSUdfTkNQRlNfU1RST05HIGlzIG5vdCBzZXQNCiMg Q09ORklHX05DUEZTX05GU19OUyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BG U19PUzJfTlMgaXMgbm90IHNldA0KIyBDT05GSUdfTkNQRlNfU01BTExET1Mg aXMgbm90IHNldA0KIyBDT05GSUdfTkNQRlNfTkxTIGlzIG5vdCBzZXQNCiMg Q09ORklHX05DUEZTX0VYVFJBUyBpcyBub3Qgc2V0DQojIENPTkZJR19aSVNP RlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfWkxJQl9GU19JTkZMQVRFIGlz IG5vdCBzZXQNCg0KIw0KIyBQYXJ0aXRpb24gVHlwZXMNCiMNCiMgQ09ORklH X1BBUlRJVElPTl9BRFZBTkNFRCBpcyBub3Qgc2V0DQpDT05GSUdfTVNET1Nf UEFSVElUSU9OPXkNCkNPTkZJR19TTUJfTkxTPXkNCkNPTkZJR19OTFM9eQ0K DQojDQojIE5hdGl2ZSBMYW5ndWFnZSBTdXBwb3J0DQojDQpDT05GSUdfTkxT X0RFRkFVTFQ9Imlzbzg4NTktMSINCkNPTkZJR19OTFNfQ09ERVBBR0VfNDM3 PXkNCkNPTkZJR19OTFNfQ09ERVBBR0VfNzM3PW0NCkNPTkZJR19OTFNfQ09E RVBBR0VfNzc1PW0NCkNPTkZJR19OTFNfQ09ERVBBR0VfODUwPW0NCkNPTkZJ R19OTFNfQ09ERVBBR0VfODUyPW0NCkNPTkZJR19OTFNfQ09ERVBBR0VfODU1 PW0NCkNPTkZJR19OTFNfQ09ERVBBR0VfODU3PW0NCkNPTkZJR19OTFNfQ09E RVBBR0VfODYwPW0NCkNPTkZJR19OTFNfQ09ERVBBR0VfODYxPW0NCkNPTkZJ R19OTFNfQ09ERVBBR0VfODYyPW0NCkNPTkZJR19OTFNfQ09ERVBBR0VfODYz PW0NCkNPTkZJR19OTFNfQ09ERVBBR0VfODY0PW0NCkNPTkZJR19OTFNfQ09E RVBBR0VfODY1PW0NCkNPTkZJR19OTFNfQ09ERVBBR0VfODY2PW0NCkNPTkZJ R19OTFNfQ09ERVBBR0VfODY5PW0NCkNPTkZJR19OTFNfQ09ERVBBR0VfOTM2 PW0NCkNPTkZJR19OTFNfQ09ERVBBR0VfOTUwPW0NCkNPTkZJR19OTFNfQ09E RVBBR0VfOTMyPW0NCkNPTkZJR19OTFNfQ09ERVBBR0VfOTQ5PW0NCkNPTkZJ R19OTFNfQ09ERVBBR0VfODc0PW0NCkNPTkZJR19OTFNfSVNPODg1OV84PW0N CkNPTkZJR19OTFNfQ09ERVBBR0VfMTI1MD1tDQpDT05GSUdfTkxTX0NPREVQ QUdFXzEyNTE9bQ0KQ09ORklHX05MU19JU084ODU5XzE9eQ0KQ09ORklHX05M U19JU084ODU5XzI9bQ0KQ09ORklHX05MU19JU084ODU5XzM9bQ0KQ09ORklH X05MU19JU084ODU5XzQ9bQ0KQ09ORklHX05MU19JU084ODU5XzU9bQ0KQ09O RklHX05MU19JU084ODU5XzY9bQ0KQ09ORklHX05MU19JU084ODU5Xzc9bQ0K Q09ORklHX05MU19JU084ODU5Xzk9bQ0KQ09ORklHX05MU19JU084ODU5XzEz PW0NCkNPTkZJR19OTFNfSVNPODg1OV8xND1tDQpDT05GSUdfTkxTX0lTTzg4 NTlfMTU9bQ0KQ09ORklHX05MU19LT0k4X1I9bQ0KQ09ORklHX05MU19LT0k4 X1U9bQ0KQ09ORklHX05MU19VVEY4PXkNCg0KIw0KIyBDb25zb2xlIGRyaXZl cnMNCiMNCkNPTkZJR19WR0FfQ09OU09MRT15DQojIENPTkZJR19WSURFT19T RUxFQ1QgaXMgbm90IHNldA0KIyBDT05GSUdfTURBX0NPTlNPTEUgaXMgbm90 IHNldA0KDQojDQojIEZyYW1lLWJ1ZmZlciBzdXBwb3J0DQojDQojIENPTkZJ R19GQiBpcyBub3Qgc2V0DQoNCiMNCiMgU291bmQNCiMNCiMgQ09ORklHX1NP VU5EIGlzIG5vdCBzZXQNCg0KIw0KIyBVU0Igc3VwcG9ydA0KIw0KIyBDT05G SUdfVVNCIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9VSENJIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1VTQl9VSENJX0FMVCBpcyBub3Qgc2V0DQojIENPTkZJ R19VU0JfT0hDSSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfQVVESU8gaXMg bm90IHNldA0KIyBDT05GSUdfVVNCX0JMVUVUT09USCBpcyBub3Qgc2V0DQoj IENPTkZJR19VU0JfU1RPUkFHRSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0Jf U1RPUkFHRV9ERUJVRyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFH RV9EQVRBRkFCIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TVE9SQUdFX0ZS RUVDT00gaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NUT1JBR0VfSVNEMjAw IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TVE9SQUdFX0RQQ00gaXMgbm90 IHNldA0KIyBDT05GSUdfVVNCX1NUT1JBR0VfSFA4MjAwZSBpcyBub3Qgc2V0 DQojIENPTkZJR19VU0JfU1RPUkFHRV9TRERSMDkgaXMgbm90IHNldA0KIyBD T05GSUdfVVNCX1NUT1JBR0VfSlVNUFNIT1QgaXMgbm90IHNldA0KIyBDT05G SUdfVVNCX0FDTSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfUFJJTlRFUiBp cyBub3Qgc2V0DQojIENPTkZJR19VU0JfREMyWFggaXMgbm90IHNldA0KIyBD T05GSUdfVVNCX01EQzgwMCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0NB Tk5FUiBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfTUlDUk9URUsgaXMgbm90 IHNldA0KIyBDT05GSUdfVVNCX0hQVVNCU0NTSSBpcyBub3Qgc2V0DQojIENP TkZJR19VU0JfUEVHQVNVUyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfS0FX RVRIIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9DQVRDIGlzIG5vdCBzZXQN CiMgQ09ORklHX1VTQl9DRENFVEhFUiBpcyBub3Qgc2V0DQojIENPTkZJR19V U0JfVVNCTkVUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9VU1M3MjAgaXMg bm90IHNldA0KDQojDQojIFVTQiBTZXJpYWwgQ29udmVydGVyIHN1cHBvcnQN CiMNCiMgQ09ORklHX1VTQl9TRVJJQUwgaXMgbm90IHNldA0KIyBDT05GSUdf VVNCX1NFUklBTF9HRU5FUklDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9T RVJJQUxfQkVMS0lOIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxf V0hJVEVIRUFUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfRElH SV9BQ0NFTEVQT1JUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxf RU1QRUcgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9GVERJX1NJ TyBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX1ZJU09SIGlzIG5v dCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfSVBBUSBpcyBub3Qgc2V0DQoj IENPTkZJR19VU0JfU0VSSUFMX0lSIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT Ql9TRVJJQUxfRURHRVBPUlQgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NF UklBTF9LRVlTUEFOX1BEQSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VS SUFMX0tFWVNQQU4gaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9L RVlTUEFOX1VTQTI4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxf S0VZU1BBTl9VU0EyOFggaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklB TF9LRVlTUEFOX1VTQTI4WEEgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NF UklBTF9LRVlTUEFOX1VTQTI4WEIgaXMgbm90IHNldA0KIyBDT05GSUdfVVNC X1NFUklBTF9LRVlTUEFOX1VTQTE5IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT Ql9TRVJJQUxfS0VZU1BBTl9VU0ExOFggaXMgbm90IHNldA0KIyBDT05GSUdf VVNCX1NFUklBTF9LRVlTUEFOX1VTQTE5VyBpcyBub3Qgc2V0DQojIENPTkZJ R19VU0JfU0VSSUFMX0tFWVNQQU5fVVNBNDlXIGlzIG5vdCBzZXQNCiMgQ09O RklHX1VTQl9TRVJJQUxfTUNUX1UyMzIgaXMgbm90IHNldA0KIyBDT05GSUdf VVNCX1NFUklBTF9LTFNJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJ QUxfUEwyMzAzIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfQ1lC RVJKQUNLIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfWElSQ09N IGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfT01OSU5FVCBpcyBu b3Qgc2V0DQojIENPTkZJR19VU0JfUklPNTAwIGlzIG5vdCBzZXQNCg0KIw0K IyBCbHVldG9vdGggc3VwcG9ydA0KIw0KIyBDT05GSUdfQkxVRVogaXMgbm90 IHNldA0KDQojDQojIEtlcm5lbCBoYWNraW5nDQojDQpDT05GSUdfREVCVUdf S0VSTkVMPXkNCiMgQ09ORklHX0RFQlVHX0hJR0hNRU0gaXMgbm90IHNldA0K IyBDT05GSUdfREVCVUdfU0xBQiBpcyBub3Qgc2V0DQojIENPTkZJR19ERUJV R19JT1ZJUlQgaXMgbm90IHNldA0KQ09ORklHX01BR0lDX1NZU1JRPXkNCkNP TkZJR19ERUJVR19TUElOTE9DSz15DQpDT05GSUdfREVCVUdfQlVHVkVSQk9T RT15DQpDT05GSUdfS0RCPXkNCkNPTkZJR19LREJfTU9EVUxFUz15DQojIENP TkZJR19LREJfT0ZGIGlzIG5vdCBzZXQNCkNPTkZJR19LQUxMU1lNUz15DQoj IENPTkZJR19GUkFNRV9QT0lOVEVSIGlzIG5vdCBzZXQNCg== --168484060-90843961-1016311271=:1142-- From owner-linux-xfs@oss.sgi.com Sat Mar 16 13:15:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GLFo912892 for linux-xfs-outgoing; Sat, 16 Mar 2002 13:15:50 -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 g2GLFl912866 for ; Sat, 16 Mar 2002 13:15:47 -0800 Received: from online.no (213-187-164-240.dd.nextgentel.com [213.187.164.240]) by mail.broadpark.no (Postfix) with ESMTP id 020857D3D for ; Sat, 16 Mar 2002 22:17:09 +0100 (MET) Message-ID: <3C93B625.4BF9917@online.no> Date: Sat, 16 Mar 2002 22:16:21 +0100 From: Knut J Bjuland X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre2-ac2-xfs-shawn9 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs in linux or redhat kernel Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk How far is XFS from beige include in either Linux 2.5 or in Redhat Linux X.X above 7.2? Would it be possible from SGI side to make XFS more compatible with other kernel patch like ac and rmap. This'll make it easier to patch Redhat's Linux kernel. From owner-linux-xfs@oss.sgi.com Sat Mar 16 14:27:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2GMRdP14062 for linux-xfs-outgoing; Sat, 16 Mar 2002 14:27:39 -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 g2GMRa914033 for ; Sat, 16 Mar 2002 14:27:36 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 9C1B440187F; Sat, 16 Mar 2002 17:29:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 8B7FBC00EF1; Sat, 16 Mar 2002 17:29:06 -0500 (EST) Date: Sat, 16 Mar 2002 17:29:06 -0500 (EST) From: Mike Burger To: Knut J Bjuland Cc: linux-xfs@oss.sgi.com Subject: Re: xfs in linux or redhat kernel In-Reply-To: <3C93B625.4BF9917@online.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The answer, as always, is that it's as far away as Linus Torvalds wishes it to be. On Sat, 16 Mar 2002, Knut J Bjuland wrote: > How far is XFS from beige include in either Linux 2.5 or in Redhat Linux > X.X above 7.2? Would it be possible from SGI side to make XFS more > compatible with other kernel patch like ac and rmap. This'll make it > easier to patch Redhat's Linux kernel. > From owner-linux-xfs@oss.sgi.com Sun Mar 17 05:02:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2HD2DH00899 for linux-xfs-outgoing; Sun, 17 Mar 2002 05:02:13 -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 g2HD26900873 for ; Sun, 17 Mar 2002 05:02:07 -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 g2HEBSkw010759 for ; Sun, 17 Mar 2002 08:11:29 -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 HAA00034; Sun, 17 Mar 2002 07:02:12 -0600 (CST) Received: from sgi.com (rXAoJwxRC4WFSLKJnbny7hhFxwXFRIvv@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 HAA49506; Sun, 17 Mar 2002 07:02:12 -0600 (CST) Message-ID: <3C9493E8.4000500@sgi.com> Date: Sun, 17 Mar 2002 07:02:32 -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: Myles Uyema CC: linux-xfs@oss.sgi.com Subject: Re: oops, 2.4.18-xfs cvs 2002/03/16 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Myles Uyema wrote: >This crash is happening on bootup with an SMP kernel. Uniprocessor >kernels do not crash on me. I'm using an Abit BP6 dual celeron 500. > > ># ># Kernel hacking ># >CONFIG_DEBUG_KERNEL=y ># CONFIG_DEBUG_HIGHMEM is not set ># CONFIG_DEBUG_SLAB is not set ># CONFIG_DEBUG_IOVIRT is not set >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 is not set > Turn off spinlock debugging and it should go away, xfs is not compatible with spinlock debugging. I will get to fixing this eventually! Steve From owner-linux-xfs@oss.sgi.com Sun Mar 17 06:54:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2HEs1602299 for linux-xfs-outgoing; Sun, 17 Mar 2002 06:54: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 g2HEqr902264 for ; Sun, 17 Mar 2002 06:52:53 -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 g2HEsG6G007502 for ; Sun, 17 Mar 2002 06:54:17 -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 IAA01020 for ; Sun, 17 Mar 2002 08:53:01 -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 IAA74680 for ; Sun, 17 Mar 2002 08:53:01 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2HEpFf12439; Sun, 17 Mar 2002 08:51:15 -0600 Message-Id: <200203171451.g2HEpFf12439@jen.americas.sgi.com> Date: Sun, 17 Mar 2002 08:51:15 -0600 Subject: TAKE - merge up to 2.5.7-pre2 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Mar 17 06:49:41 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:114320a linux/fs/nfsctl.c - 1.1 linux/Documentation/BK-usage/bk-kernel-howto.txt - 1.1 linux/Documentation/BK-usage/bk-make-sum - 1.1 linux/Documentation/BK-usage/cset-to-linus - 1.1 linux/Documentation/BK-usage/csets-to-patches - 1.1 linux/Documentation/filesystems/tmpfs.txt - 1.1 linux/Documentation/networking/NAPI_HOWTO.txt - 1.1 linux/include/linux/netfilter_arp/arp_tables.h - 1.1 linux/Documentation/networking/slicecom.hun - 1.1 linux/Documentation/networking/slicecom.txt - 1.1 linux/include/linux/netfilter_arp.h - 1.1 linux/drivers/media/video/video-buf.h - 1.1 linux/include/asm-i386/acpi.h - 1.1 linux/Documentation/video4linux/bttv/README.freeze - 1.1 linux/arch/ia64/hp/simscsi.h - 1.1 linux/arch/sparc64/lib/mcount.S - 1.1 linux/arch/ia64/hp/simserial.c - 1.1 linux/net/ipv4/netfilter/arptable_filter.c - 1.1 linux/net/ipv4/netfilter/arp_tables.c - 1.1 linux/drivers/acpi/acpi_ac.c - 1.1 linux/drivers/acpi/acpi_battery.c - 1.1 linux/drivers/media/video/video-buf.c - 1.1 linux/drivers/acpi/acpi_bus.c - 1.1 linux/drivers/acpi/acpi_bus.h - 1.1 linux/drivers/acpi/acpi_button.c - 1.1 linux/fs/udf/osta_udf.h - 1.1 linux/arch/i386/kernel/acpi_wakeup.S - 1.1 linux/drivers/acpi/acpi_pci_root.c - 1.1 linux/fs/udf/ecma_167.h - 1.1 linux/drivers/acpi/acpi_drivers.h - 1.1 linux/drivers/acpi/acpi_ec.c - 1.1 linux/drivers/acpi/acpi_fan.c - 1.1 linux/drivers/acpi/acpi_osl.c - 1.1 linux/drivers/ide/ata-timing.c - 1.1 linux/drivers/ide/ata-timing.h - 1.1 linux/drivers/media/video/bttv-risc.c - 1.1 linux/drivers/media/video/bttv-vbi.c - 1.1 linux/arch/ia64/hp/simscsi.c - 1.1 linux/drivers/acpi/acpi_processor.c - 1.1 linux/drivers/acpi/acpi_pci_link.c - 1.1 linux/drivers/acpi/acpi_system.c - 1.1 linux/drivers/net/wan/comx-hw-munich.c - 1.1 linux/arch/ia64/hp/simeth.c - 1.1 linux/drivers/acpi/acpi_tables.c - 1.1 linux/drivers/net/wan/falc-lh.h - 1.1 linux/drivers/net/wan/munich32x.h - 1.1 linux/drivers/acpi/acpi_power.c - 1.1 linux/drivers/acpi/acpi_thermal.c - 1.1 linux/drivers/acpi/acpi_utils.c - 1.1 linux/fs/libfs.c - 1.1 linux/drivers/usb/emi26_fw.h - 1.1 linux/drivers/usb/emi26.c - 1.1 linux/net/socket.c - 1.34 linux/net/netsyms.c - 1.44 linux/net/ipx/af_spx.c - 1.17 linux/net/ipv4/ipmr.c - 1.21 linux/net/ipv4/arp.c - 1.21 linux/net/core/sysctl_net_core.c - 1.5 linux/net/core/dev.c - 1.52 linux/kernel/sys.c - 1.29 linux/kernel/signal.c - 1.29 linux/kernel/sched.c - 1.64 linux/kernel/ksyms.c - 1.140 linux/kernel/fork.c - 1.52 linux/kernel/exit.c - 1.42 linux/kernel/acct.c - 1.17 linux/include/linux/sysctl.h - 1.46 linux/include/linux/sunrpc/svcsock.h - 1.5 linux/include/linux/smb_fs_sb.h - 1.7 linux/include/linux/smb_fs.h - 1.18 linux/include/linux/sched.h - 1.64 linux/include/linux/romfs_fs_i.h - 1.3 linux/include/linux/qnx4_fs_sb.h - 1.5 linux/include/linux/qnx4_fs.h - 1.12 linux/include/linux/pci.h - 1.57 linux/include/linux/nfsd/syscall.h - 1.7 linux/include/linux/nfs_fs_sb.h - 1.7 linux/include/linux/nfs_fs.h - 1.20 linux/include/linux/netdevice.h - 1.33 linux/include/linux/ncp_fs_sb.h - 1.7 linux/include/linux/ncp_fs.h - 1.14 linux/include/linux/msdos_fs.h - 1.17 linux/include/linux/hdreg.h - 1.17 linux/include/linux/fs.h - 1.161 linux/include/linux/ext2_fs.h - 1.20 linux/include/asm-sparc64/unistd.h - 1.19 linux/include/asm-sparc64/system.h - 1.18 linux/include/asm-sparc64/page.h - 1.16 linux/include/asm-sparc64/mman.h - 1.4 linux/include/asm-sparc64/current.h - 1.4 linux/include/asm-sparc/unistd.h - 1.17 linux/include/asm-sparc/mman.h - 1.4 linux/include/asm-i386/irq.h - 1.5 linux/include/asm-i386/fixmap.h - 1.10 linux/fs/vfat/namei.c - 1.28 linux/fs/smbfs/proc.c - 1.18 linux/fs/smbfs/inode.c - 1.32 linux/fs/romfs/inode.c - 1.33 linux/fs/readdir.c - 1.15 linux/fs/read_write.c - 1.19 linux/fs/qnx4/inode.c - 1.33 linux/fs/qnx4/bitmap.c - 1.12 linux/fs/proc/inode.c - 1.20 linux/fs/proc/base.c - 1.36 linux/fs/proc/array.c - 1.40 linux/fs/pipe.c - 1.29 linux/fs/nfsd/nfsctl.c - 1.29 linux/fs/nfsd/export.c - 1.32 linux/fs/nfs/write.c - 1.38 linux/fs/nfs/read.c - 1.31 linux/fs/nfs/inode.c - 1.40 linux/fs/nfs/dir.c - 1.37 linux/fs/ncpfs/inode.c - 1.29 linux/fs/msdos/namei.c - 1.28 linux/fs/minix/inode.c - 1.32 linux/fs/filesystems.c - 1.21 linux/fs/fat/inode.c - 1.40 linux/fs/fat/fatfs_syms.c - 1.13 linux/fs/ext2/super.c - 1.28 linux/fs/ext2/inode.c - 1.44 linux/fs/ext2/ialloc.c - 1.24 linux/fs/ext2/dir.c - 1.20 linux/fs/ext2/balloc.c - 1.19 linux/fs/devpts/inode.c - 1.15 linux/fs/dcache.c - 1.34 linux/fs/binfmt_misc.c - 1.21 linux/fs/binfmt_elf.c - 1.40 linux/fs/autofs/inode.c - 1.12 linux/fs/autofs/dir.c - 1.10 linux/fs/autofs/autofs_i.h - 1.11 linux/fs/autofs/Makefile - 1.4 linux/fs/Makefile - 1.52 linux/drivers/video/clgenfb.c - 1.26 linux/drivers/usb/usb.c - 1.72 linux/drivers/usb/Makefile - 1.49 linux/drivers/usb/Config.in - 1.55 linux/drivers/scsi/ide-scsi.c - 1.30 linux/drivers/pnp/Makefile - 1.12 linux/drivers/pci/pci.c - 1.56 linux/drivers/net/pcnet32.c - 1.33 linux/drivers/net/lance.c - 1.23 linux/drivers/net/hp100.c - 1.20 linux/drivers/net/eepro100.c - 1.42 linux/drivers/net/bmac.c - 1.20 linux/drivers/net/at1700.c - 1.17 linux/drivers/net/acenic.h - 1.19 linux/drivers/net/acenic.c - 1.38 linux/drivers/isdn/sc/Makefile - 1.5 linux/drivers/isdn/pcbit/Makefile - 1.5 linux/drivers/isdn/hisax/Makefile - 1.18 linux/drivers/isdn/avmb1/Makefile - 1.12 linux/drivers/isdn/act2000/Makefile - 1.6 linux/drivers/isdn/Makefile - 1.11 linux/drivers/char/sysrq.c - 1.23 linux/drivers/char/stallion.c - 1.19 linux/drivers/char/rocket.c - 1.15 linux/arch/sparc64/solaris/entry64.S - 1.5 linux/arch/sparc64/prom/Makefile - 1.8 linux/arch/sparc64/mm/ultra.S - 1.27 linux/arch/sparc64/mm/fault.c - 1.22 linux/arch/sparc64/lib/checksum.S - 1.6 linux/arch/sparc64/lib/blockops.S - 1.17 linux/arch/sparc64/lib/VIScsumcopy.S - 1.5 linux/arch/sparc64/lib/Makefile - 1.10 linux/arch/sparc64/kernel/winfixup.S - 1.6 linux/arch/sparc64/kernel/trampoline.S - 1.11 linux/arch/sparc64/kernel/systbls.S - 1.26 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.41 linux/arch/sparc64/kernel/smp.c - 1.40 linux/arch/sparc64/kernel/process.c - 1.33 linux/arch/sparc64/kernel/ioctl32.c - 1.52 linux/arch/sparc64/kernel/head.S - 1.16 linux/arch/sparc64/kernel/etrap.S - 1.8 linux/arch/sparc64/kernel/ebus.c - 1.15 linux/arch/sparc64/defconfig - 1.63 linux/arch/sparc64/config.in - 1.53 linux/arch/sparc64/Makefile - 1.17 linux/arch/sparc/kernel/systbls.S - 1.22 linux/arch/sparc/kernel/sun4m_smp.c - 1.19 linux/arch/sparc/kernel/sun4d_smp.c - 1.19 linux/arch/ppc/kernel/smp.c - 1.35 linux/arch/i386/mm/fault.c - 1.23 linux/arch/i386/kernel/traps.c - 1.51 linux/arch/i386/kernel/signal.c - 1.24 linux/arch/i386/kernel/setup.c - 1.71 linux/arch/i386/kernel/head.S - 1.22 linux/arch/i386/kernel/Makefile - 1.26 linux/arch/i386/defconfig - 1.103 linux/arch/i386/config.in - 1.75 linux/arch/alpha/kernel/smp.c - 1.32 linux/arch/alpha/defconfig - 1.25 linux/Rules.make - 1.16 linux/Makefile - 1.191 linux/MAINTAINERS - 1.101 linux/CREDITS - 1.76 linux/include/linux/ide.h - 1.43 linux/include/linux/efs_fs.h - 1.9 linux/fs/efs/super.c - 1.14 linux/drivers/isdn/eicon/Makefile - 1.6 linux/kernel/ptrace.c - 1.20 linux/drivers/isdn/divert/Makefile - 1.4 linux/arch/sparc64/kernel/pci.c - 1.25 linux/include/asm-i386/pci.h - 1.15 linux/fs/udf/udftime.c - 1.6 linux/include/linux/udf_udf.h - 1.5 linux/fs/udf/fsync.c - 1.7 linux/fs/udf/ialloc.c - 1.14 linux/include/linux/udf_fs_sb.h - 1.7 linux/fs/udf/file.c - 1.26 linux/fs/udf/directory.c - 1.8 linux/fs/udf/dir.c - 1.18 linux/fs/udf/crc.c - 1.3 linux/fs/udf/inode.c - 1.30 linux/include/linux/udf_fs_i.h - 1.7 linux/fs/udf/lowlevel.c - 1.10 linux/fs/udf/balloc.c - 1.12 linux/include/linux/udf_fs.h - 1.13 linux/include/linux/udf_167.h - 1.6 linux/fs/udf/misc.c - 1.10 linux/fs/udf/namei.c - 1.22 linux/fs/udf/partition.c - 1.8 linux/fs/udf/super.c - 1.27 linux/fs/udf/truncate.c - 1.10 linux/fs/udf/symlink.c - 1.15 linux/fs/udf/unicode.c - 1.6 linux/fs/udf/udf_i.h - 1.7 linux/fs/udf/udfend.h - 1.6 linux/fs/udf/udf_sb.h - 1.7 linux/fs/udf/udfdecl.h - 1.18 linux/include/asm-sparc64/pci.h - 1.12 linux/include/linux/acpi.h - 1.23 linux/drivers/net/wan/Makefile - 1.15 linux/drivers/net/wan/Config.in - 1.14 linux/arch/i386/kernel/smpboot.c - 1.35 linux/arch/i386/kernel/pci-pc.c - 1.35 linux/arch/i386/kernel/pci-i386.h - 1.9 linux/fs/proc/kcore.c - 1.12 linux/kernel/timer.c - 1.19 linux/Documentation/video4linux/bttv/Sound-FAQ - 1.9 linux/Documentation/video4linux/bttv/CARDLIST - 1.13 linux/Documentation/video4linux/bttv/Insmod-options - 1.12 linux/arch/i386/kernel/acpi.c - 1.23 linux/fs/openpromfs/inode.c - 1.20 linux/fs/cramfs/inode.c - 1.27 linux/drivers/usb/ov511.c - 1.35 linux/drivers/usb/inode.c - 1.25 linux/arch/i386/kernel/mpparse.c - 1.16 linux/arch/sparc64/lib/VIScsumcopyusr.S - 1.3 linux/fs/autofs4/autofs_i.h - 1.9 linux/fs/autofs4/root.c - 1.15 linux/fs/autofs4/inode.c - 1.12 linux/arch/ia64/kernel/entry.S - 1.23 linux/arch/ia64/ia32/ia32_entry.S - 1.16 linux/arch/ia64/hp/Makefile - 1.4 linux/arch/ia64/vmlinux.lds.S - 1.10 linux/arch/ia64/tools/print_offsets.c - 1.11 linux/arch/ia64/defconfig - 1.13 linux/arch/ia64/config.in - 1.25 linux/arch/ia64/tools/print_offsets.awk - 1.5 linux/arch/ia64/kernel/setup.c - 1.13 linux/arch/ia64/kernel/smp.c - 1.13 linux/arch/ia64/kernel/unaligned.c - 1.11 linux/arch/ia64/kernel/ivt.S - 1.15 linux/arch/ia64/lib/clear_page.S - 1.7 linux/arch/ia64/kernel/process.c - 1.15 linux/arch/ia64/kernel/perfmon.c - 1.12 linux/arch/ia64/mm/init.c - 1.14 linux/arch/ia64/mm/fault.c - 1.9 linux/include/asm-ia64/hardirq.h - 1.12 linux/include/asm-ia64/cache.h - 1.5 linux/include/asm-ia64/bitops.h - 1.8 linux/include/asm-ia64/siginfo.h - 1.11 linux/include/asm-ia64/mman.h - 1.5 linux/include/asm-ia64/processor.h - 1.17 linux/include/asm-ia64/smplock.h - 1.6 linux/include/asm-ia64/offsets.h - 1.13 linux/include/asm-ia64/uaccess.h - 1.8 linux/include/asm-ia64/system.h - 1.12 linux/drivers/isdn/hysdn/Makefile - 1.5 linux/fs/devfs/base.c - 1.36 linux/arch/mips64/sgi-ip27/ip27-init.c - 1.10 linux/drivers/usb/pegasus.c - 1.30 linux/drivers/ide/via82cxxx.c - 1.24 linux/drivers/ide/umc8672.c - 1.4 linux/drivers/ide/sl82c105.c - 1.8 linux/drivers/ide/sis5513.c - 1.16 linux/drivers/ide/piix.c - 1.18 linux/drivers/ide/pdc4030.c - 1.11 linux/drivers/ide/pdc202xx.c - 1.16 linux/drivers/ide/opti621.c - 1.8 linux/drivers/ide/ide_modes.h - 1.6 linux/drivers/ide/ide.c - 1.48 linux/drivers/ide/ide-tape.c - 1.22 linux/drivers/ide/ide-pmac.c - 1.9 linux/drivers/ide/ide-floppy.c - 1.19 linux/drivers/ide/ide-dma.c - 1.23 linux/drivers/ide/ide-disk.c - 1.29 linux/drivers/ide/ide-cd.c - 1.30 linux/drivers/ide/icside.c - 1.12 linux/drivers/ide/ht6560b.c - 1.6 linux/drivers/ide/hpt366.c - 1.15 linux/drivers/ide/hpt34x.c - 1.8 linux/drivers/ide/dtc2278.c - 1.5 linux/drivers/ide/cy82c693.c - 1.8 linux/drivers/ide/cs5530.c - 1.7 linux/drivers/ide/cmd64x.c - 1.11 linux/drivers/ide/cmd640.c - 1.7 linux/drivers/ide/alim15x3.c - 1.13 linux/drivers/ide/ali14xx.c - 1.7 linux/drivers/ide/Makefile - 1.17 linux/drivers/ide/Config.in - 1.19 linux/Documentation/networking/comx.txt - 1.4 linux/drivers/usb/dsbr100.c - 1.14 linux/drivers/net/wan/comx.c - 1.17 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.16 linux/net/ipv4/netfilter/ip_nat_rule.c - 1.6 linux/net/ipv4/netfilter/ip_nat_core.c - 1.10 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.12 linux/net/ipv4/netfilter/Makefile - 1.12 linux/net/ipv4/netfilter/Config.in - 1.9 linux/include/linux/netfilter_ipv4/ip_nat.h - 1.3 linux/arch/i386/kernel/pci-irq.c - 1.20 linux/fs/ramfs/inode.c - 1.20 linux/fs/nfs/nfs3proc.c - 1.9 linux/drivers/ide/aec62xx.c - 1.6 linux/arch/ia64/kernel/smpboot.c - 1.8 linux/arch/ia64/ia32/ia32_traps.c - 1.6 linux/include/linux/nfs_page.h - 1.8 linux/arch/s390/kernel/smp.c - 1.11 linux/arch/mips64/kernel/ioctl32.c - 1.11 linux/kdb/kdbmain.c - 1.28 linux/drivers/acpi/tables/tbxface.c - 1.8 linux/drivers/acpi/tables/tbutils.c - 1.8 linux/drivers/acpi/tables/tbinstal.c - 1.8 linux/drivers/acpi/tables/tbget.c - 1.8 linux/drivers/acpi/resources/rsxface.c - 1.8 linux/drivers/acpi/resources/rsutils.c - 1.8 linux/drivers/acpi/resources/rsmisc.c - 1.7 linux/drivers/acpi/resources/rsmemory.c - 1.7 linux/drivers/acpi/resources/rslist.c - 1.8 linux/drivers/acpi/resources/rsirq.c - 1.7 linux/drivers/acpi/resources/rsio.c - 1.7 linux/drivers/acpi/resources/rsdump.c - 1.8 linux/drivers/acpi/resources/rscreate.c - 1.8 linux/drivers/acpi/resources/rscalc.c - 1.8 linux/drivers/acpi/resources/rsaddr.c - 1.7 linux/drivers/acpi/parser/psxface.c - 1.8 linux/drivers/acpi/parser/pswalk.c - 1.8 linux/drivers/acpi/parser/psutils.c - 1.8 linux/drivers/acpi/parser/pstree.c - 1.8 linux/drivers/acpi/parser/psscope.c - 1.8 linux/drivers/acpi/parser/psparse.c - 1.9 linux/drivers/acpi/parser/psopcode.c - 1.8 linux/drivers/acpi/parser/psargs.c - 1.9 linux/drivers/acpi/os.c - 1.11 linux/drivers/acpi/namespace/nsxfobj.c - 1.11 linux/drivers/acpi/namespace/nsxfname.c - 1.8 linux/drivers/acpi/namespace/nswalk.c - 1.7 linux/drivers/acpi/namespace/nsutils.c - 1.8 linux/drivers/acpi/namespace/nssearch.c - 1.9 linux/drivers/acpi/namespace/nsobject.c - 1.8 linux/drivers/acpi/namespace/nsnames.c - 1.9 linux/drivers/acpi/namespace/nsload.c - 1.8 linux/drivers/acpi/namespace/nseval.c - 1.9 linux/drivers/acpi/namespace/nsalloc.c - 1.8 linux/drivers/acpi/namespace/nsaccess.c - 1.9 linux/drivers/acpi/include/amlcode.h - 1.8 linux/drivers/acpi/include/actypes.h - 1.10 linux/drivers/acpi/include/actables.h - 1.8 linux/drivers/acpi/include/acpixf.h - 1.9 linux/drivers/acpi/include/acpiosxf.h - 1.8 linux/drivers/acpi/include/acpi.h - 1.5 linux/drivers/acpi/include/acobject.h - 1.8 linux/drivers/acpi/include/acexcep.h - 1.7 linux/drivers/acpi/hardware/hwregs.c - 1.9 linux/drivers/acpi/hardware/hwgpe.c - 1.8 linux/drivers/acpi/hardware/hwacpi.c - 1.9 linux/drivers/acpi/events/evxfregn.c - 1.9 linux/drivers/acpi/events/evxfevnt.c - 1.8 linux/drivers/acpi/events/evxface.c - 1.8 linux/drivers/acpi/events/evsci.c - 1.8 linux/drivers/acpi/events/evrgnini.c - 1.8 linux/drivers/acpi/events/evregion.c - 1.10 linux/drivers/acpi/events/evmisc.c - 1.8 linux/drivers/acpi/events/evevent.c - 1.10 linux/drivers/acpi/driver.c - 1.13 linux/drivers/acpi/dispatcher/dswstate.c - 1.9 linux/drivers/acpi/dispatcher/dswscope.c - 1.8 linux/drivers/acpi/dispatcher/dswload.c - 1.8 linux/drivers/acpi/dispatcher/dswexec.c - 1.8 linux/drivers/acpi/dispatcher/dsutils.c - 1.8 linux/drivers/acpi/dispatcher/dsopcode.c - 1.9 linux/drivers/acpi/dispatcher/dsobject.c - 1.9 linux/drivers/acpi/dispatcher/dsmthdat.c - 1.7 linux/drivers/acpi/dispatcher/dsmethod.c - 1.8 linux/drivers/acpi/dispatcher/dsfield.c - 1.7 linux/arch/ia64/kernel/ia64_ksyms.c - 1.9 linux/drivers/acpi/Makefile - 1.11 linux/include/linux/nfsd/interface.h - 1.4 linux/fs/nfs/unlink.c - 1.6 linux/drivers/media/video/tvmixer.c - 1.8 linux/drivers/media/video/tuner.h - 1.7 linux/drivers/media/video/tuner.c - 1.9 linux/drivers/media/video/tda9875.c - 1.8 linux/drivers/media/video/tda7432.c - 1.9 linux/drivers/media/video/saa5249.c - 1.8 linux/drivers/media/video/pms.c - 1.7 linux/drivers/media/video/msp3400.c - 1.10 linux/drivers/media/video/cpia.c - 1.13 linux/drivers/media/video/c-qcam.c - 1.9 linux/drivers/media/video/bw-qcam.c - 1.9 linux/drivers/media/video/bttv.h - 1.11 linux/drivers/media/video/bttv-driver.c - 1.19 linux/drivers/media/video/bttv-cards.c - 1.11 linux/drivers/media/video/Makefile - 1.7 linux/drivers/media/radio/radio-typhoon.c - 1.8 linux/drivers/media/radio/radio-trust.c - 1.8 linux/drivers/media/radio/radio-terratec.c - 1.8 linux/drivers/media/radio/radio-sf16fmi.c - 1.10 linux/drivers/media/radio/radio-rtrack2.c - 1.8 linux/drivers/media/radio/radio-gemtek.c - 1.8 linux/drivers/media/radio/radio-cadet.c - 1.7 linux/drivers/media/radio/radio-aztech.c - 1.8 linux/drivers/media/radio/radio-aimslab.c - 1.8 linux/drivers/acpi/dispatcher/Makefile - 1.4 linux/drivers/acpi/events/Makefile - 1.4 linux/drivers/acpi/hardware/Makefile - 1.4 linux/drivers/acpi/include/acconfig.h - 1.9 linux/drivers/acpi/include/acdebug.h - 1.8 linux/drivers/acpi/include/acdispat.h - 1.7 linux/drivers/acpi/include/acevents.h - 1.8 linux/drivers/acpi/include/acglobal.h - 1.7 linux/drivers/acpi/include/achware.h - 1.7 linux/drivers/acpi/include/acinterp.h - 1.8 linux/drivers/acpi/include/aclocal.h - 1.9 linux/drivers/acpi/include/acmacros.h - 1.8 linux/drivers/acpi/include/acnamesp.h - 1.9 linux/drivers/acpi/include/acoutput.h - 1.7 linux/drivers/acpi/include/acparser.h - 1.6 linux/drivers/acpi/include/acresrc.h - 1.5 linux/drivers/acpi/include/actbl.h - 1.7 linux/drivers/acpi/namespace/Makefile - 1.4 linux/drivers/acpi/namespace/nsdump.c - 1.5 linux/drivers/acpi/parser/Makefile - 1.4 linux/drivers/acpi/resources/Makefile - 1.4 linux/drivers/acpi/tables/Makefile - 1.4 linux/drivers/media/radio/radio-maestro.c - 1.6 linux/drivers/ide/slc90e66.c - 1.8 linux/drivers/usb/pegasus.h - 1.11 linux/drivers/media/video/tvaudio.h - 1.3 linux/drivers/media/video/tvaudio.c - 1.9 linux/drivers/media/video/id.h - 1.3 linux/drivers/media/video/bttvp.h - 1.7 linux/include/linux/ethtool.h - 1.9 linux/drivers/acpi/tables/tbconvrt.c - 1.7 linux/drivers/acpi/tables/tbxfroot.c - 1.6 linux/drivers/acpi/namespace/nsinit.c - 1.8 linux/drivers/acpi/include/actbl71.h - 1.6 linux/drivers/acpi/include/actbl2.h - 1.6 linux/drivers/acpi/include/actbl1.h - 1.5 linux/mm/shmem.c - 1.33 linux/drivers/acpi/acpi_ksyms.c - 1.6 linux/drivers/acpi/hardware/hwsleep.c - 1.6 linux/drivers/acpi/hardware/hwtimer.c - 1.6 linux/drivers/ide/ide-timing.h - 1.3 linux/arch/s390x/kernel/smp.c - 1.8 linux/arch/cris/drivers/ide.c - 1.9 linux/drivers/usb/serial/io_edgeport.c - 1.22 linux/drivers/media/radio/radio-maxiradio.c - 1.5 linux/drivers/media/video/w9966.c - 1.3 linux/drivers/usb/pwc-if.c - 1.14 linux/drivers/usb/pwc-ctrl.c - 1.8 linux/drivers/media/radio/miropcm20-radio.c - 1.4 linux/drivers/acpi/ospm/ec/ecgpe.c - 1.3 linux/drivers/acpi/executer/exstore.c - 1.4 linux/drivers/acpi/ospm/ec/ec_osl.c - 1.6 linux/drivers/acpi/ospm/ec/Makefile - 1.2 linux/drivers/acpi/ospm/include/pr.h - 1.4 linux/drivers/acpi/ospm/button/bn_osl.c - 1.6 linux/drivers/acpi/utilities/utxface.c - 1.4 linux/drivers/acpi/utilities/utobject.c - 1.4 linux/drivers/acpi/utilities/utmisc.c - 1.4 linux/drivers/acpi/utilities/utinit.c - 1.4 linux/drivers/acpi/utilities/utglobal.c - 1.4 linux/drivers/acpi/utilities/uteval.c - 1.4 linux/drivers/acpi/utilities/utdelete.c - 1.4 linux/drivers/acpi/utilities/utdebug.c - 1.4 linux/drivers/acpi/utilities/utcopy.c - 1.4 linux/drivers/acpi/utilities/utalloc.c - 1.4 linux/drivers/acpi/utilities/Makefile - 1.2 linux/drivers/acpi/ospm/button/bn.c - 1.4 linux/drivers/acpi/ospm/button/Makefile - 1.2 linux/drivers/acpi/ospm/busmgr/bmutils.c - 1.4 linux/drivers/acpi/ospm/busmgr/bmsearch.c - 1.3 linux/drivers/acpi/ospm/thermal/tz.c - 1.4 linux/drivers/acpi/ospm/busmgr/bmrequest.c - 1.3 linux/drivers/acpi/ospm/busmgr/bmpower.c - 1.4 linux/drivers/acpi/ospm/busmgr/bmpm.c - 1.3 linux/drivers/acpi/ospm/busmgr/bmnotify.c - 1.3 linux/drivers/acpi/ospm/busmgr/bmdriver.c - 1.3 linux/drivers/acpi/ospm/busmgr/bm_osl.c - 1.6 linux/drivers/acpi/ospm/busmgr/bm.c - 1.4 linux/drivers/acpi/ospm/busmgr/Makefile - 1.3 linux/drivers/acpi/ospm/thermal/Makefile - 1.2 linux/drivers/acpi/ospm/battery/bt_osl.c - 1.6 linux/drivers/acpi/ospm/battery/bt.c - 1.4 linux/drivers/acpi/Config.in - 1.2 linux/drivers/acpi/include/acstruct.h - 1.4 linux/drivers/acpi/ospm/system/sm_osl.c - 1.6 linux/drivers/acpi/ospm/thermal/tz_osl.c - 1.7 linux/drivers/acpi/ospm/thermal/tzpolicy.c - 1.5 linux/drivers/acpi/ospm/system/sm.c - 1.4 linux/drivers/acpi/ospm/include/bt.h - 1.4 linux/drivers/acpi/ospm/include/bn.h - 1.4 linux/drivers/acpi/include/acutils.h - 1.4 linux/drivers/acpi/include/platform/acenv.h - 1.4 linux/drivers/acpi/ospm/include/bmpower.h - 1.3 linux/drivers/acpi/include/platform/acgcc.h - 1.6 linux/drivers/acpi/include/platform/aclinux.h - 1.3 linux/drivers/acpi/debugger/dbcmds.c - 1.4 linux/drivers/acpi/debugger/dbdisasm.c - 1.4 linux/drivers/acpi/debugger/dbdisply.c - 1.4 linux/drivers/acpi/debugger/dbexec.c - 1.3 linux/drivers/acpi/debugger/dbfileio.c - 1.4 linux/drivers/acpi/debugger/dbhistry.c - 1.3 linux/drivers/acpi/debugger/dbinput.c - 1.4 linux/drivers/acpi/debugger/dbstats.c - 1.4 linux/drivers/acpi/debugger/dbutils.c - 1.4 linux/drivers/acpi/debugger/dbxface.c - 1.4 linux/drivers/acpi/ospm/system/Makefile - 1.2 linux/drivers/acpi/ospm/include/ec.h - 1.3 linux/drivers/acpi/ospm/processor/prpower.c - 1.4 linux/drivers/acpi/ospm/processor/prperf.c - 1.4 linux/drivers/acpi/ospm/battery/Makefile - 1.2 linux/drivers/acpi/ospm/processor/pr_osl.c - 1.7 linux/drivers/acpi/ospm/ac_adapter/ac_osl.c - 1.6 linux/drivers/acpi/ospm/processor/pr.c - 1.4 linux/drivers/acpi/ospm/processor/Makefile - 1.2 linux/drivers/acpi/ospm/ac_adapter/ac.c - 1.4 linux/drivers/acpi/executer/exutils.c - 1.4 linux/drivers/acpi/executer/exsystem.c - 1.3 linux/drivers/acpi/ospm/ac_adapter/Makefile - 1.2 linux/drivers/acpi/executer/exstorob.c - 1.3 linux/drivers/acpi/ospm/Makefile - 1.2 linux/drivers/acpi/executer/exstoren.c - 1.3 linux/drivers/acpi/ospm/include/bm.h - 1.3 linux/drivers/acpi/ospm/ec/ecmain.c - 1.4 linux/drivers/acpi/ospm/include/sm.h - 1.3 linux/drivers/acpi/ospm/include/tz.h - 1.4 linux/drivers/acpi/ospm/ec/ecspace.c - 1.4 linux/drivers/acpi/ospm/ec/ectransx.c - 1.3 linux/drivers/acpi/ospm/include/ac.h - 1.3 linux/drivers/acpi/executer/Makefile - 1.2 linux/drivers/acpi/executer/exconfig.c - 1.4 linux/drivers/acpi/executer/exconvrt.c - 1.4 linux/drivers/acpi/executer/excreate.c - 1.4 linux/drivers/acpi/executer/exdump.c - 1.4 linux/drivers/acpi/executer/exfield.c - 1.3 linux/drivers/acpi/executer/exfldio.c - 1.4 linux/drivers/acpi/executer/exmisc.c - 1.4 linux/drivers/acpi/executer/exmutex.c - 1.3 linux/drivers/acpi/executer/exnames.c - 1.3 linux/drivers/acpi/executer/exprep.c - 1.4 linux/drivers/acpi/executer/exregion.c - 1.4 linux/drivers/acpi/executer/exresnte.c - 1.5 linux/drivers/acpi/executer/exresolv.c - 1.4 linux/drivers/acpi/executer/exresop.c - 1.4 linux/drivers/usb/se401.c - 1.11 linux/arch/mips/kernel/smp.c - 1.5 linux/drivers/media/video/meye.h - 1.4 linux/drivers/media/video/meye.c - 1.8 linux/drivers/media/radio/radio-gemtek-pci.c - 1.4 linux/drivers/ide/serverworks.c - 1.7 linux/drivers/ide/it8172.c - 1.4 linux/drivers/ide/amd74xx.c - 1.6 linux/drivers/usb/usbvideo.h - 1.8 linux/drivers/usb/usbvideo.c - 1.10 linux/drivers/ide/qd65xx.c - 1.5 linux/drivers/net/ns83820.c - 1.10 linux/drivers/acpi/debugger/Makefile - 1.2 linux/drivers/ide/ide-m8xx.c - 1.2 linux/Documentation/video4linux/bttv/Cards - 1.2 linux/drivers/net/8139cp.c - 1.10 linux/drivers/acpi/executer/exoparg6.c - 1.2 linux/drivers/acpi/utilities/utmath.c - 1.2 linux/drivers/pcmcia/i82092.c - 1.3 linux/drivers/acpi/executer/exoparg3.c - 1.2 linux/drivers/acpi/executer/exoparg2.c - 1.2 linux/drivers/acpi/executer/exoparg1.c - 1.2 linux/arch/i386/kernel/acpitable.c - 1.3 linux/drivers/hotplug/pci_hotplug_core.c - 1.8 linux/fs/intermezzo/journal_ext2.c - 1.4 linux/fs/nfs/pagelist.c - 1.4 linux/arch/i386/kernel/acpitable.h - 1.2 linux/fs/driverfs/inode.c - 1.11 linux/drivers/usb/serial/ipaq.c - 1.4 linux/drivers/usb/stv680.c - 1.7 linux/drivers/usb/vicam.c - 1.8 linux/include/linux/init_task.h - 1.7 linux/drivers/ide/pdcadma.c - 1.3 linux/arch/i386/Config.help - 1.5 linux/fs/Config.help - 1.7 linux/drivers/usb/Config.help - 1.4 linux/drivers/acpi/Config.help - 1.2 linux/drivers/ide/Config.help - 1.6 linux/drivers/base/core.c - 1.5 linux/sound/oss/via82cxxx_audio.c - 1.4 linux/sound/oss/btaudio.c - 1.3 linux/arch/x86_64/kernel/smpboot.c - 1.2 linux/sound/core/rtctimer.c - 1.5 linux/arch/ppc64/kernel/smp.c - 1.2 linux/drivers/net/e1000/e1000_main.c - 1.4 linux/drivers/net/tg3.h - 1.2 linux/drivers/net/tg3.c - 1.2 linux/drivers/net/e100/e100_phy.h - 1.2 linux/drivers/net/e100/e100_proc.c - 1.2 linux/drivers/net/e100/e100.h - 1.2 linux/drivers/net/e100/e100_ucode.h - 1.2 linux/drivers/net/e100/e100_vendor.h - 1.2 linux/drivers/net/e100/e100_phy.c - 1.2 linux/drivers/net/e100/e100_config.c - 1.2 linux/drivers/net/e100/e100_config.h - 1.2 linux/drivers/net/e100/e100_eeprom.c - 1.2 linux/drivers/net/e100/e100_main.c - 1.2 From owner-linux-xfs@oss.sgi.com Sun Mar 17 10:41:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2HIfis05251 for linux-xfs-outgoing; Sun, 17 Mar 2002 10:41:44 -0800 Received: from mons.uio.no (IDENT:7411@mons.uio.no [129.240.130.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2HIfe905225 for ; Sun, 17 Mar 2002 10:41:41 -0800 Received: from charged.uio.no ([129.240.86.49]) by mons.uio.no with esmtp (Exim 2.12 #7) id 16mfcJ-0003no-00; Sun, 17 Mar 2002 19:42:51 +0100 Received: from trondmy by charged.uio.no with local (Exim 2.12 #1) id 16mfcI-0000U0-00; Sun, 17 Mar 2002 19:42:50 +0100 To: Jim Eshleman Cc: nfs@lists.sourceforge.net, linux-xfs@oss.sgi.com Subject: Re: [NFS] 2.4.18 rpciod oops [xdr_encode_netobj] References: <3C922BF6.8050405@Lehigh.EDU> From: Trond Myklebust Date: 17 Mar 2002 19:42:50 +0100 In-Reply-To: <3C922BF6.8050405@Lehigh.EDU> Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >>>>> " " == Jim Eshleman writes: > FYI. There was no apparent effect on the running system, an > 8-way 8.5G (64G HIGHMEM) P3 Xeon, running 2.4.18 + XFS, NIS, > NFS, sendmail, etc. Let me know if more info is needed. Is it repeatable on a non-XFS patched kernel? Cheers, Trond From owner-linux-xfs@oss.sgi.com Sun Mar 17 11:40:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2HJe7s06244 for linux-xfs-outgoing; Sun, 17 Mar 2002 11:40:07 -0800 Received: from kendy.up.ac.za (kendy.up.AC.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2HJdn906216 for ; Sun, 17 Mar 2002 11:39:50 -0800 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 16mgWd-0001cJ-00 for linux-xfs@oss.sgi.com; Sun, 17 Mar 2002 21:41:03 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=it.up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.15 #1) id 16mgWd-0003bC-00 for linux-xfs@oss.sgi.com; Sun, 17 Mar 2002 21:41:03 +0200 Message-ID: <3C94F14E.7DE5A62D@it.up.ac.za> Date: Sun, 17 Mar 2002 21:41:02 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.19-pre2-ac2-xfs-shawn9 i686) X-Accept-Language: en MIME-Version: 1.0 To: XFS mailing list Subject: XFS slows down on used partions with bonnie++ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16mgWd-0003bC-00*5w95OblSzDM* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have being playing around with bonnie++ from http://www.coker.com.au/bonnie++/ I found an interesting thing. When I run bonnie++ on a newly created XFS filesystem I get the following results: mkfs.xfs -f -l size=8192b /dev/sda7 meta-data=/dev/sda7 isize=256 agcount=19, agsize=262144 blks data = bsize=4096 blocks=4843589, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=8192 realtime =none extsz=65536 blocks=0, rtextents=0 mount -o logbufs=8 /dev/sda7 /mnt cd /mnt /mnt#time bonnie++ -u root -s0 -b -n 10:100000:1000:1000 Version 1.02b ------Sequential Create------ --------Random Create-------- kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 10:100000:1000/1000 206 8 154 3 1463 20 192 7 49 1 1081 18 kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,206,8,154,3,1463,20,192,7,49,1, 1081,18 0.300u 15.540s 6:35.00 4.0% 0+0k 0+0io 215pf+0w /mnt#time bonnie++ -u root -s0 -b -n 10:100000:1000:1000 Version 1.02b ------Sequential Create------ --------Random Create-------- kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 10:100000:1000/1000 196 7 83 1 1215 23 191 8 49 1 1023 20 kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,196,7,83,1,1215,23,191,8,49,1,1 023,20 0.370u 16.520s 7:31.92 3.7% 0+0k 0+0io 219pf+0w I created the file system. Run bonnie++ with the parameters as above. I run bonnie++ immediately for a second time. If you look at the sequential read field, you will see that it is nearly half the amount of the first run. According to this test XFS seems to lose sequential read speed as the filesystem gets used. You can umount and even reboot the machine and run bonnie++ again and still get the slowdown phenomenon, provided you mount the same filesystem again without mkfs'ing it. I repeated this test on several other machines with the same result. I also did it with other filesystems. Here is the result with ext2: Version 1.02b ------Sequential Create------ --------Random Create-------- kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 10:100000:1000/1000 142 2 142 2 585 3 150 3 46 0 430 2 kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,142,2,142,2,585,3,150,3,46,0,43 0,2 0.240u 8.950s 7:56.63 1.9% 0+0k 0+0io 218pf+0w /mnt#time bonnie++ -u root -s0 -b -n 10:100000:1000:1000 Version 1.02b ------Sequential Create------ --------Random Create-------- kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 10:100000:1000/1000 154 3 143 3 540 2 152 2 47 0 449 2 kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,154,3,143,3,540,2,152,2,47,0,44 9,2 0.300u 9.080s 7:42.20 2.0% 0+0k 0+0io 220pf+0w No slow down. I can include results for reiserfs and JFS, but will add size to this message without adding additional info regarding this issue. The machine is a Dell PE2550 1G RAM (I used mem=256M kernel param, otherwise everything runs from cache) 4x18G 15k RPM seagate cheethas in RAID 10 2x1.133GHz P4 CPUs Regards Paul Schutte From owner-linux-xfs@oss.sgi.com Sun Mar 17 21:12:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2I5CvJ15540 for linux-xfs-outgoing; Sun, 17 Mar 2002 21:12: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 g2I5Cp915513 for ; Sun, 17 Mar 2002 21:12:52 -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 g2I6MFkw012125 for ; Mon, 18 Mar 2002 00:22:17 -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 QAA18785; Mon, 18 Mar 2002 16:12:55 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA17071; Mon, 18 Mar 2002 16:12:54 +1100 (AEDT) Date: Mon, 18 Mar 2002 16:12:54 +1100 From: Nathan Scott To: Joe Bacom Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_check 112 Segmentation fault Message-ID: <20020318161254.J1601@wobbly.melbourne.sgi.com> References: <200203152058.PAA10148@webcube2.volstate.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200203152058.PAA10148@webcube2.volstate.net>; from joebacom@volstate.net on Fri, Mar 15, 2002 at 02:51:02PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Joe, On Fri, Mar 15, 2002 at 02:51:02PM -0600, Joe Bacom wrote: > Anybody have any clues about the following error from xfs_check. > > /usr/sbin/xfs_check: line 62: 112 Segmentation fault xfs_db$ISFILE -i -p > xfs_check -c "check$OPTS" $1 Was a "core" file generated? If so, could you send it to me, along with the xfs_db binary from your system, and I'll see if I can figure out the problem. > This drive has been acting up and the new one is one the way but I was trying > to salvage some data off ot it. I am running on the SGI installer cd in > rescue mode, kernel version: > 2.4.7-10SGI_XFS_PR1BOOT Does xfs_repair work? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Mar 17 21:27:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2I5R7A16016 for linux-xfs-outgoing; Sun, 17 Mar 2002 21:27: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 g2I5R2915987 for ; Sun, 17 Mar 2002 21:27:02 -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 g2I5SN6G019517 for ; Sun, 17 Mar 2002 21:28:24 -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 QAA18854; Mon, 18 Mar 2002 16:27:07 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA17138; Mon, 18 Mar 2002 16:27:05 +1100 (AEDT) Date: Mon, 18 Mar 2002 16:27:04 +1100 From: Nathan Scott To: Stephen Lord , Robert Sander Cc: linux-xfs@oss.sgi.com Subject: Re: force_shutdown experienced Message-ID: <20020318162704.L1601@wobbly.melbourne.sgi.com> References: <3C91F99A.5000704@sgi.com> <20020315134712.GA5095@epigenomics.de> <3C921C68.6000308@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: <3C921C68.6000308@sgi.com>; from lord@sgi.com on Fri, Mar 15, 2002 at 10:08:08AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Mar 15, 2002 at 10:08:08AM -0600, Stephen Lord wrote: > Robert Sander wrote: > > > >>Note if you get the new kernel and you use ACLs you need new user space > >>utilities to go with the kernel. > > > >Or I compile the compatability layer into the kernel. How is that > >working? > > > There is no compatibility layer, at 2.4.18 the system calls change. > Maintaining both > in the kernel was going to be a nightmare. I am not sure what the > current status is > with third party apps like samba - I think some people have it working. > Samba uses the libacl.so interface (POSIX), not the syscalls directly; so, provided one has the correct version of libacl installed (matching the syscall interface in the running kernel), and Samba is linked with that version of libacl, Samba's ACL support will continue to work with no changes to the Samba source. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Mar 17 21:43:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2I5hua16512 for linux-xfs-outgoing; Sun, 17 Mar 2002 21:43:56 -0800 Received: from emergence.com (IDENT:root@mail.emergence.com [209.5.172.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2I5hn916485 for ; Sun, 17 Mar 2002 21:43:49 -0800 Received: from emergence.com (h24-86-77-34.ed.shawcable.net [24.86.77.34]) by emergence.com (8.9.3/8.9.3) with ESMTP id WAA25732 for ; Sun, 17 Mar 2002 22:44:31 -0700 Message-ID: <3C957EC7.9E788759@emergence.com> Date: Sun, 17 Mar 2002 22:44:39 -0700 From: Michael Best X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en, pdf MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: fatal error -- xfs_repair: duplicate inode range Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was called Sunday morning for a machine that had failed. You could ping it from the network but nothing else. I rebooted it, and got a XFS Page alloc kernel panic I believe. (unsure it's been hours since then). I rebooted it in single user mode, read some logfiles and then rebooted it into multi user mode. A short while later the machine appeared to fail again, when rebooted it could no longer load the initrd in order to mount the root (/) filesystem to boot. I used a Mandrake 8.2rc1 disc to boot the system, after finding the mount command on the 1.0.2 installer disc was hopeless. I ran XFS repair, which suggested something good had happened. And then it suggested mounting it. No luck. It suggested I could use xfs_repair -L to try and mount it after that. I tried that, no luck. All further attempts produce output like this: fatal error -- xfs_repair: duplicate inode range Here are the logs from xfs_check and xfs_repair for this filesystem. http://www.emergence.com/xfs_trouble/xfs_check_sda5.txt http://www.emergence.com/xfs_trouble/xfs_repair_sda5.txt The machine was originally running a single Quantum Atlas V on Ultra 160 Scsi chain. I have moved this machine to two Maxtor 20G drives with Raid 1 mirroring. The Scsi chain is still in the machine with the broken filesystem drive and I can make it available/prepare a filesystem dump (perhaps someone can explain how to do that). Hopefully I have enough space on my drive for that. I saw other people with this error in the mailing list archives but didn't see if there was a solution to this problem. I should be available by 10am Pacific 12pm Eastern on Monday March 18th, 2002. -- Michael Best Emergence By Design +1 780 413-6397 From owner-linux-xfs@oss.sgi.com Sun Mar 17 21:49:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2I5nf916764 for linux-xfs-outgoing; Sun, 17 Mar 2002 21:49:41 -0800 Received: from emergence.com (IDENT:root@mail.emergence.com [209.5.172.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2I5nb916737 for ; Sun, 17 Mar 2002 21:49:38 -0800 Received: from emergence.com (h24-86-77-34.ed.shawcable.net [24.86.77.34]) by emergence.com (8.9.3/8.9.3) with ESMTP id WAA25822 for ; Sun, 17 Mar 2002 22:50:20 -0700 Message-ID: <3C958025.10D4903A@emergence.com> Date: Sun, 17 Mar 2002 22:50:29 -0700 From: Michael Best X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en, pdf MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: fatal error -- xfs_repair: duplicate inode range Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk One additional piece of information: On the failed system and on this new system I am running the SGI 1.0.2 + Redhat 7.2 installer. -- Michael Best Emergence By Design +1 780 413-6397 From owner-linux-xfs@oss.sgi.com Mon Mar 18 04:58:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ICwXC26706 for linux-xfs-outgoing; Mon, 18 Mar 2002 04:58:33 -0800 Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ICwG926658 for ; Mon, 18 Mar 2002 04:58:26 -0800 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id g2ICxZW18966 for linux-xfs@oss.sgi.com.KAV; Mon, 18 Mar 2002 13:59:35 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g2ICxYI18955 for ; Mon, 18 Mar 2002 13:59:35 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id g2ICuil08528 for ; Mon, 18 Mar 2002 13:56:44 +0100 Date: Mon, 18 Mar 2002 13:56:43 +0100 From: Olaf Frączyk To: linux-xfs@oss.sgi.com Subject: Encryption and XFS Message-ID: <20020318125643.GA8412@venus.local.navi.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Disposition: inline X-Mailer: Balsa 1.3.3 Lines: 9 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I found, that in middle of last year was a short discussion about it, but it ended without conclusions. Is anyone using encryption with XFS? Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Mon Mar 18 07:49:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IFna131934 for linux-xfs-outgoing; Mon, 18 Mar 2002 07:49:36 -0800 Received: from webcube2.volstate.net (webcube2.volstate.net [66.129.16.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IFnU931908 for ; Mon, 18 Mar 2002 07:49:30 -0800 Received: from volstate.net (webcube2.volstate.net [66.129.16.201]) by webcube2.volstate.net (8.9.3/8.9.3) with SMTP id KAA17245; Mon, 18 Mar 2002 10:50:41 -0500 From: joebacom@volstate.net Message-Id: <200203181550.KAA17245@webcube2.volstate.net> Date: Mon, 18 Mar 2002 10:50:41 -0500 (EST) To: nathans@sgi.com Cc: nathans@sgi.com, linux-xfs@oss.sgi.com Subject: Re: xfs_check 112 Segmentation fault X-Mailer: AtDot 2.0.1 X-URL: http://www.volstate.net/webmail.html Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Nathan; Sorry the partition is gone and the drive is dead (new one is on the way from WD) it seems that the logic board went out so I don't think this was and XFS issue at all. Thanks for the offer to help. Joe You wrote: > From: Nathan Scott > To: Joe Bacom > Cc: linux-xfs@oss.sgi.com > Date: Mon, 18 Mar 2002 16:12:54 +1100 > Subject: Re: xfs_check 112 Segmentation fault > > > hi Joe, > > On Fri, Mar 15, 2002 at 02:51:02PM -0600, Joe Bacom wrote: > > Anybody have any clues about the following error from xfs_check. > > > > /usr/sbin/xfs_check: line 62: 112 Segmentation fault xfs_db$ISFILE -i -p > > xfs_check -c "check$OPTS" $1 > > Was a "core" file generated? If so, could you send it to me, > along with the xfs_db binary from your system, and I'll see if > I can figure out the problem. > > > This drive has been acting up and the new one is one the way but I was trying > > to salvage some data off ot it. I am running on the SGI installer cd in > > rescue mode, kernel version: > > 2.4.7-10SGI_XFS_PR1BOOT > > Does xfs_repair work? > > cheers. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 18 08:04:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IG4t701658 for linux-xfs-outgoing; Mon, 18 Mar 2002 08:04:55 -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 g2IG4i901632 for ; Mon, 18 Mar 2002 08:04:44 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx02)) with ESMTP id 41B8862E9 for ; Mon, 18 Mar 2002 17:06:06 +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 RAA00702 for linux-xfs@oss.sgi.com; Mon, 18 Mar 2002 17:06:05 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 2492257306 for ; Mon, 18 Mar 2002 17:05:42 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id C215525835 for ; Mon, 18 Mar 2002 17:05:41 +0100 (CET) Message-ID: <3C961055.FF5DF9C6@ch.sauter-bc.com> Date: Mon, 18 Mar 2002 17:05:41 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: files in /etc/xinetd.d become 0 byte size Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I'm setting up a new server, basically it's RedHat 7.2 XFS with all updates from RedHat applied. Kernel is 2.4.9-31SGI_XFS_1.0.2. I have two IDE disks with software RAID1 partitions for /, /boot, /home. Nothing special. The problem I have is that after some installation and configuration work, some xinetd config files in /etc/xinetd.d became 0 byte size. IIRC I saw the same thing some time ago with another machine but I really don't understand what's going on. BTW, I didn't have a crash or unclean shutdown. [root@gw-linux-dev xinetd.d]# ll /etc/xinetd.d total 44 -rw-r--r-- 1 root root 295 Mar 18 15:53 chargen -rw-r--r-- 1 root root 315 Mar 18 15:53 chargen-udp -rw-r--r-- 1 root root 295 Mar 18 15:53 daytime -rw-r--r-- 1 root root 315 Mar 18 15:53 daytime-udp -rw-r--r-- 1 root root 287 Mar 18 15:53 echo -rw-r--r-- 1 root root 306 Mar 18 15:53 echo-udp -rw-r--r-- 1 root root 317 Mar 18 15:53 finger -rw-r--r-- 1 root root 491 Mar 18 15:53 jftpgw-inet -rw-r--r-- 1 root root 257 Mar 18 15:53 ntalk -rw-r--r-- 1 root root 0 Mar 18 15:53 rexec -rw-r--r-- 1 root root 0 Mar 18 15:53 rlogin -rw-r--r-- 1 root root 0 Mar 18 15:53 rsh -rw-r--r-- 1 root root 0 Mar 18 15:53 rsync -rw-r--r-- 1 root root 0 Mar 18 15:53 talk -rw-r--r-- 1 root root 0 Mar 18 15:53 telnet -rw-r--r-- 1 root root 0 Mar 18 15:53 time -rw-r--r-- 1 root root 0 Mar 18 15:53 time-udp -rw-r--r-- 1 root root 0 Mar 18 15:53 wu-ftpd I have then restored the empty files from another installation. Everything seemed okay. I have then rebooted and now it's getting more interesting. [root@gw-linux-dev xinetd.d]# ll total 36 -rw-r--r-- 1 root root 295 Mar 18 15:59 chargen -rw-r--r-- 1 root root 315 Mar 18 15:59 chargen-udp -rw-r--r-- 1 root root 295 Mar 18 15:59 daytime -rw-r--r-- 1 root root 315 Mar 18 15:59 daytime-udp -rw-r--r-- 1 root root 287 Mar 18 15:59 echo -rw-r--r-- 1 root root 306 Mar 18 15:59 echo-udp -rw-r--r-- 1 root root 317 Mar 18 15:59 finger -rw-r--r-- 1 root root 491 Mar 18 15:59 jftpgw-inet -rw-r--r-- 1 root root 257 Mar 18 15:59 ntalk -rw-r--r-- 1 root root 359 Mar 18 15:59 rexec -rw-r--r-- 1 root root 376 Mar 18 15:59 rlogin -rw-r--r-- 1 root root 428 Mar 18 15:59 rsh -rw-r--r-- 1 root root 317 Mar 18 15:59 rsync -rw-r--r-- 1 root root 245 Mar 18 15:59 talk -rw-r--r-- 1 root root 303 Mar 18 15:59 telnet -rw-r--r-- 1 root root 319 Mar 18 15:59 time -rw-r--r-- 1 root root 315 Mar 18 15:59 time-udp -rw-r--r-- 1 root root 361 Mar 18 15:59 wu-ftpd It looks okay, but then I tried this: [root@gw-linux-dev xinetd.d]# cat rsh [root@gw-linux-dev xinetd.d]# Further investigation shows that the same files that were missing before are now filled with zero. After restarting xinetd, I guess they will be 0 bytes in size. I have searched RedHat bugzilla but didn't find anything useful. What comes to mind is the problem with zero filled bytes after a crash but I didnt' have any crash or unclean shutdowns. It seems to be something similar anyway. Is it possible that xinetd performs an operation on the files which leaves them not cleanly flushed to disk when shutting down? Thanks for any help! -Simon From owner-linux-xfs@oss.sgi.com Mon Mar 18 08:27:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IGR9A02044 for linux-xfs-outgoing; Mon, 18 Mar 2002 08:27:09 -0800 Received: from rain.CC.Lehigh.EDU (rain.CC.Lehigh.EDU [128.180.39.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IGR5902018 for ; Mon, 18 Mar 2002 08:27:05 -0800 Received: from Lehigh.EDU (hooch.CC.Lehigh.EDU [128.180.3.11]) by rain.CC.Lehigh.EDU (8.12.2/8.12.2) with ESMTP id g2IGSMEW022581 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 18 Mar 2002 11:28:22 -0500 Message-ID: <3C9615A5.6080807@Lehigh.EDU> Date: Mon, 18 Mar 2002 11:28:21 -0500 From: Jim Eshleman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Trond Myklebust CC: nfs@lists.sourceforge.net, linux-xfs@oss.sgi.com Subject: Re: [NFS] 2.4.18 rpciod oops [xdr_encode_netobj] References: <3C922BF6.8050405@Lehigh.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Trond Myklebust wrote: >>>>>>" " == Jim Eshleman writes: >>>>> > > > FYI. There was no apparent effect on the running system, an > > 8-way 8.5G (64G HIGHMEM) P3 Xeon, running 2.4.18 + XFS, NIS, > > NFS, sendmail, etc. Let me know if more info is needed. > > Is it repeatable on a non-XFS patched kernel? > > Cheers, > Trond Unfortunately I'm not able to try a non-XFS kernel on this machine. Jim From owner-linux-xfs@oss.sgi.com Mon Mar 18 08:29:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IGTwC02254 for linux-xfs-outgoing; Mon, 18 Mar 2002 08:29:58 -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 g2IGTk902227 for ; Mon, 18 Mar 2002 08:29:46 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx03)) with ESMTP id C1833622E for ; Mon, 18 Mar 2002 17:31: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 RAA02701 for linux-xfs@oss.sgi.com; Mon, 18 Mar 2002 17:31:08 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 8E0BB57306 for ; Mon, 18 Mar 2002 17:30:35 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 7C8C525836 for ; Mon, 18 Mar 2002 17:30:35 +0100 (CET) Message-ID: <3C96162B.FEBA6ABA@ch.sauter-bc.com> Date: Mon, 18 Mar 2002 17:30:35 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C961055.FF5DF9C6@ch.sauter-bc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter schrieb: > > Hi all, > > I'm setting up a new server, basically it's RedHat 7.2 XFS with all > updates from RedHat applied. Kernel is 2.4.9-31SGI_XFS_1.0.2. I have two > IDE disks with software RAID1 partitions for /, /boot, /home. Nothing > special. > > The problem I have is that after some installation and configuration > work, some xinetd config files in /etc/xinetd.d became 0 byte size. IIRC > I saw the same thing some time ago with another machine but I really > don't understand what's going on. BTW, I didn't have a crash or unclean > shutdown. > > [root@gw-linux-dev xinetd.d]# ll /etc/xinetd.d > total 44 > -rw-r--r-- 1 root root 295 Mar 18 15:53 chargen > -rw-r--r-- 1 root root 315 Mar 18 15:53 chargen-udp > -rw-r--r-- 1 root root 295 Mar 18 15:53 daytime > -rw-r--r-- 1 root root 315 Mar 18 15:53 daytime-udp > -rw-r--r-- 1 root root 287 Mar 18 15:53 echo > -rw-r--r-- 1 root root 306 Mar 18 15:53 echo-udp > -rw-r--r-- 1 root root 317 Mar 18 15:53 finger > -rw-r--r-- 1 root root 491 Mar 18 15:53 jftpgw-inet > -rw-r--r-- 1 root root 257 Mar 18 15:53 ntalk > -rw-r--r-- 1 root root 0 Mar 18 15:53 rexec > -rw-r--r-- 1 root root 0 Mar 18 15:53 rlogin > -rw-r--r-- 1 root root 0 Mar 18 15:53 rsh > -rw-r--r-- 1 root root 0 Mar 18 15:53 rsync > -rw-r--r-- 1 root root 0 Mar 18 15:53 talk > -rw-r--r-- 1 root root 0 Mar 18 15:53 telnet > -rw-r--r-- 1 root root 0 Mar 18 15:53 time > -rw-r--r-- 1 root root 0 Mar 18 15:53 time-udp > -rw-r--r-- 1 root root 0 Mar 18 15:53 wu-ftpd > > I have then restored the empty files from another installation. > Everything seemed okay. I have then rebooted and now it's getting more > interesting. > > [root@gw-linux-dev xinetd.d]# ll > total 36 > -rw-r--r-- 1 root root 295 Mar 18 15:59 chargen > -rw-r--r-- 1 root root 315 Mar 18 15:59 chargen-udp > -rw-r--r-- 1 root root 295 Mar 18 15:59 daytime > -rw-r--r-- 1 root root 315 Mar 18 15:59 daytime-udp > -rw-r--r-- 1 root root 287 Mar 18 15:59 echo > -rw-r--r-- 1 root root 306 Mar 18 15:59 echo-udp > -rw-r--r-- 1 root root 317 Mar 18 15:59 finger > -rw-r--r-- 1 root root 491 Mar 18 15:59 jftpgw-inet > -rw-r--r-- 1 root root 257 Mar 18 15:59 ntalk > -rw-r--r-- 1 root root 359 Mar 18 15:59 rexec > -rw-r--r-- 1 root root 376 Mar 18 15:59 rlogin > -rw-r--r-- 1 root root 428 Mar 18 15:59 rsh > -rw-r--r-- 1 root root 317 Mar 18 15:59 rsync > -rw-r--r-- 1 root root 245 Mar 18 15:59 talk > -rw-r--r-- 1 root root 303 Mar 18 15:59 telnet > -rw-r--r-- 1 root root 319 Mar 18 15:59 time > -rw-r--r-- 1 root root 315 Mar 18 15:59 time-udp > -rw-r--r-- 1 root root 361 Mar 18 15:59 wu-ftpd > > It looks okay, but then I tried this: > [root@gw-linux-dev xinetd.d]# cat rsh > [root@gw-linux-dev xinetd.d]# > > Further investigation shows that the same files that were missing before > are now filled with zero. After restarting xinetd, I guess they will be > 0 bytes in size. > > I have searched RedHat bugzilla but didn't find anything useful. > What comes to mind is the problem with zero filled bytes after a crash > but I didnt' have any crash or unclean shutdowns. It seems to be > something similar anyway. > > Is it possible that xinetd performs an operation on the files which > leaves them not cleanly flushed to disk when shutting down? > > Thanks for any help! > > -Simon I reproduced it now: Using ntsysv to manage services -> reboot: Files in /etc/xinetd.d have normal size but filled with zero. Using ntsysv again truncates them to zero size. Maybe write cache on the disks is enabled for some reason. That could explain why changes are not commited to disk. I don't understand it anyway because on reboot, the cache should be flushed to disk, doesn't it? The hole thing lets me feel quite bad because I'm wondering what else has been lost. Can anybody confirm similar problems? -Simon From owner-linux-xfs@oss.sgi.com Mon Mar 18 08:34:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IGYHU02539 for linux-xfs-outgoing; Mon, 18 Mar 2002 08:34:17 -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 g2IGYA902513 for ; Mon, 18 Mar 2002 08:34:10 -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 g2IHhckw015919 for ; Mon, 18 Mar 2002 11:43:38 -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 KAA16867 for ; Mon, 18 Mar 2002 10:34:18 -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 KAA89273 for ; Mon, 18 Mar 2002 10:34:18 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g2IGYI406679; Mon, 18 Mar 2002 10:34:18 -0600 Message-Id: <200203181634.g2IGYI406679@stout.americas.sgi.com> Date: Mon, 18 Mar 2002 10:34:18 -0600 From: Eric Sandeen Subject: TAKE - correct utime permissions checking Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This fixes another LSB test suite failure. EPERM in errno and a return value of -1 on a call to utime() when the times argument is not NULL and the calling process's effective user ID has write access to the file but does not match the owner of the file and the calling process does not have appropriate privileges. The file times shall not be affected. RETURN VALUES: expected: -1, observed: 0 ERRNO VALUES: expected: 1 (EPERM), observed: 0 (NO ERROR) xfs_setattr had the correct code to check it, but it needed proper flags passed in from linvfs_setattr. Date: Mon Mar 18 08:32:21 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:114345a linux/fs/xfs/linux/xfs_iops.c - 1.127 - pass flag to xfs_setattr for correct utime permissions checking From owner-linux-xfs@oss.sgi.com Mon Mar 18 09:13:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IHDAQ03575 for linux-xfs-outgoing; Mon, 18 Mar 2002 09:13:10 -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 g2IHD3903548 for ; Mon, 18 Mar 2002 09:13: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 g2IHEP6G006846 for ; Mon, 18 Mar 2002 09:14:25 -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 LAA17528; Mon, 18 Mar 2002 11:13: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 LAA08615; Mon, 18 Mar 2002 11:13:09 -0600 (CST) Subject: Re: files in /etc/xinetd.d become 0 byte size From: Eric Sandeen To: Simon Matter Cc: linux-xfs In-Reply-To: <3C96162B.FEBA6ABA@ch.sauter-bc.com> References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <3C96162B.FEBA6ABA@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Mar 2002 11:13:09 -0600 Message-Id: <1016471589.5554.35.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-18 at 10:30, Simon Matter wrote: > I reproduced it now: > Using ntsysv to manage services -> reboot: Files in /etc/xinetd.d have > normal size but filled with zero. Trying it now... no problems. I tested it with the 2.4.9-13SGI_XFS_1.0.2 kernel and ntsysv-1.2.24-1. (this test box is mostly ext3, but I mounted an xfs filesystem on /etc/xinetd.d for this test). > Using ntsysv again truncates them to > zero size. That part's not too surprising, if it encountered config files with bad data. -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 18 09:31:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IHVLK03903 for linux-xfs-outgoing; Mon, 18 Mar 2002 09:31:21 -0800 Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IHVE903877 for ; Mon, 18 Mar 2002 09:31:15 -0800 Received: from hamburg.fcb.com ([170.200.66.15]) by hammail1.truenorth.com (Netscape Messaging Server 4.15) with ESMTP id GT6JEB00.QV3; Mon, 18 Mar 2002 18:32:35 +0100 Message-ID: <3C9624B4.7E3318F6@hamburg.fcb.com> Date: Mon, 18 Mar 2002 18:32:36 +0100 From: Harald Wagener Organization: FCB Wilkens X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.13-pre1-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Simon Matter , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <3C96162B.FEBA6ABA@ch.sauter-bc.com> <1016471589.5554.35.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > On Mon, 2002-03-18 at 10:30, Simon Matter wrote: > > > I reproduced it now: > > Using ntsysv to manage services -> reboot: Files in /etc/xinetd.d have > > normal size but filled with zero. > > Trying it now... no problems. I tested it with the > 2.4.9-13SGI_XFS_1.0.2 kernel and ntsysv-1.2.24-1. (this test box is > mostly ext3, but I mounted an xfs filesystem on /etc/xinetd.d for this > test). > > > Using ntsysv again truncates them to > > zero size. > > That part's not too surprising, if it encountered config files with bad > data. > A fix is to remount the xfs partition read-only before really unmounting and then shutting down completely so the kernel buffers will get written out to disk. RedHat already does this for ext2, so You should find the appropriate spot in Your scripts. Regards, Harald -- Harald Wagener * An der Alster 42 * 20099 Hamburg * http://www.fcb-wilkens.com "Ada is PL/I trying to be Smalltalk. -- Codoso diBlini From owner-linux-xfs@oss.sgi.com Mon Mar 18 09:35:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IHZA204072 for linux-xfs-outgoing; Mon, 18 Mar 2002 09:35:10 -0800 Received: from emergence.com (IDENT:root@mail.emergence.com [209.5.172.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IHZ1904046 for ; Mon, 18 Mar 2002 09:35:02 -0800 Received: from emergence.com (relative.emergence.com [209.5.172.43]) by emergence.com (8.9.3/8.9.3) with ESMTP id KAA03293; Mon, 18 Mar 2002 10:35:44 -0700 Message-ID: <3C96259D.270CEB2E@emergence.com> Date: Mon, 18 Mar 2002 10:36:29 -0700 From: Michael Best X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-4mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: fatal error -- xfs_repair: duplicate inode range Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It appears that either the mailing list manager threw away my earlier posting to the mailing list or that there is no hope for recovery of my filesystem. Any pointers would be appreciated. ssh access to this machine is available. Trying to get a dump of the filesystem right now with dd. ----- On the failed system and on this new system I am running the SGI_XFS 1.0.2 + Redhat 7.2 installer. ----- I was called Sunday morning for a machine that had failed. You could ping it from the network but nothing else. I rebooted it, and got a XFS Page alloc kernel panic I believe. (unsure it's been hours since then). I rebooted it in single user mode, read some logfiles and then rebooted it into multi user mode. A short while later the machine appeared to fail again, when rebooted it could no longer load the initrd in order to mount the root (/) filesystem to boot. I used a Mandrake 8.2rc1 disc to boot the system, after finding the mount command on the 1.0.2 installer disc was hopeless. I ran XFS repair, which suggested something good had happened. And then it suggested mounting it. No luck. It suggested I could use xfs_repair -L to try and mount it after that. I tried that, no luck. All further attempts produce output like this: fatal error -- xfs_repair: duplicate inode range Here are the logs from xfs_check and xfs_repair for this filesystem. http://www.emergence.com/xfs_trouble/xfs_check_sda5.txt http://www.emergence.com/xfs_trouble/xfs_repair_sda5.txt The machine was originally running a single Quantum Atlas V on Ultra 160 Scsi chain. I have moved this machine to two Maxtor 20G drives with Raid 1 mirroring. The Scsi chain is still in the machine with the broken filesystem drive and I can make it available/prepare a filesystem dump (perhaps someone can explain how to do that). Hopefully I have enough space on my drive for that. I saw other people with this error in the mailing list archives but didn't see if there was a solution to this problem. -- Michael Best Systems Administrator ph 780-413-6397 x230 Emergence By Design fax 780-433-7548 #200, 11209 Jasper Avenue toll 866-860-2666 Edmonton, Alberta, T5K 0L5 From owner-linux-xfs@oss.sgi.com Mon Mar 18 09:42:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IHgpF04477 for linux-xfs-outgoing; Mon, 18 Mar 2002 09:42: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 g2IHge904439 for ; Mon, 18 Mar 2002 09:42:40 -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 g2IIq9kw017025 for ; Mon, 18 Mar 2002 12:52:09 -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 LAA17052; Mon, 18 Mar 2002 11:42:48 -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 LAA80859; Mon, 18 Mar 2002 11:42:48 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2IHeo919719; Mon, 18 Mar 2002 11:40:50 -0600 Subject: Re: fatal error -- xfs_repair: duplicate inode range From: Steve Lord To: Michael Best Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C96259D.270CEB2E@emergence.com> References: <3C96259D.270CEB2E@emergence.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Mar 2002 11:40:50 -0600 Message-Id: <1016473250.14540.102.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-18 at 11:36, Michael Best wrote: > It appears that either the mailing list manager threw away my earlier > posting to the mailing list or that there is no hope for recovery of my > filesystem. Or people took the weekend off. You need a newer xfs_repair, and I suspect a newer kernel. You have corruption in your filesystems, and older kernels can write over block zero if they shutdown. Steve > > Any pointers would be appreciated. ssh access to this machine is > available. > > Trying to get a dump of the filesystem right now with dd. > > ----- > > On the failed system and on this new system I am running the SGI_XFS > 1.0.2 + > Redhat 7.2 installer. > > ----- > > I was called Sunday morning for a machine that had failed. > > You could ping it from the network but nothing else. > > I rebooted it, and got a XFS Page alloc kernel panic I believe. (unsure > it's been hours since then). > > I rebooted it in single user mode, read some logfiles and then rebooted > it into multi user mode. > > A short while later the machine appeared to fail again, when rebooted it > could no longer load the initrd in order to mount the root (/) > filesystem to boot. > > I used a Mandrake 8.2rc1 disc to boot the system, after finding the > mount command on the 1.0.2 installer disc was hopeless. > > I ran XFS repair, which suggested something good had happened. And then > it suggested mounting it. No luck. It suggested I could use xfs_repair > -L to try and mount it after that. > > I tried that, no luck. All further attempts produce output like this: > > fatal error -- xfs_repair: duplicate inode range > > Here are the logs from xfs_check and xfs_repair for this filesystem. > > http://www.emergence.com/xfs_trouble/xfs_check_sda5.txt > http://www.emergence.com/xfs_trouble/xfs_repair_sda5.txt > > The machine was originally running a single Quantum Atlas V on Ultra 160 > Scsi chain. I have moved this machine to two Maxtor 20G drives with > Raid 1 mirroring. The Scsi chain is still in the machine with the > broken filesystem drive and I can make it available/prepare a filesystem > dump (perhaps someone can explain how to do that). Hopefully I have > enough space on my drive for that. > > I saw other people with this error in the mailing list archives but > didn't see if there was a solution to this problem. > > -- > Michael Best > Systems Administrator ph 780-413-6397 x230 > Emergence By Design fax 780-433-7548 > #200, 11209 Jasper Avenue toll 866-860-2666 > Edmonton, Alberta, T5K 0L5 -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Mar 18 09:49:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IHnVm04691 for linux-xfs-outgoing; Mon, 18 Mar 2002 09:49:31 -0800 Received: from emergence.com (IDENT:root@mail.emergence.com [209.5.172.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IHnQ904658 for ; Mon, 18 Mar 2002 09:49:26 -0800 Received: from emergence.com (relative.emergence.com [209.5.172.43]) by emergence.com (8.9.3/8.9.3) with ESMTP id KAA03805; Mon, 18 Mar 2002 10:50:06 -0700 Message-ID: <3C9628FB.8E3F8B0A@emergence.com> Date: Mon, 18 Mar 2002 10:50:51 -0700 From: Michael Best X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-4mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: fatal error -- xfs_repair: duplicate inode range References: <3C96259D.270CEB2E@emergence.com> <1016473250.14540.102.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 Okay, no problem. How new a kernel should I use? I have a few choices that I am aware of: 2.4.9-13-RH7.2 (what I am running right now) 2.4.14 - latest Release RPM 2.4.19 - patches directory 2.4 CVS 2.5 CVS -Mike Steve Lord wrote: > > On Mon, 2002-03-18 at 11:36, Michael Best wrote: > > It appears that either the mailing list manager threw away my earlier > > posting to the mailing list or that there is no hope for recovery of my > > filesystem. > > Or people took the weekend off. > > You need a newer xfs_repair, and I suspect a newer kernel. You have > corruption in your filesystems, and older kernels can write over > block zero if they shutdown. > > Steve From owner-linux-xfs@oss.sgi.com Mon Mar 18 09:52:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IHqbi04861 for linux-xfs-outgoing; Mon, 18 Mar 2002 09:52:37 -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 g2IHqX904830 for ; Mon, 18 Mar 2002 09:52: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 g2IHrv6G008606 for ; Mon, 18 Mar 2002 09:53:57 -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 LAA18211; Mon, 18 Mar 2002 11:52:41 -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 LAA83843; Mon, 18 Mar 2002 11:52:41 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2IHoiI19736; Mon, 18 Mar 2002 11:50:44 -0600 Subject: Re: fatal error -- xfs_repair: duplicate inode range From: Steve Lord To: Michael Best Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C9628FB.8E3F8B0A@emergence.com> References: <3C96259D.270CEB2E@emergence.com> <1016473250.14540.102.camel@jen.americas.sgi.com> <3C9628FB.8E3F8B0A@emergence.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Mar 2002 11:50:44 -0600 Message-Id: <1016473844.14540.105.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-18 at 11:50, Michael Best wrote: > Okay, no problem. > > How new a kernel should I use? I have a few choices that I am aware of: > > 2.4.9-13-RH7.2 (what I am running right now) > > 2.4.14 - latest Release RPM > 2.4.19 - patches directory > 2.4 CVS > 2.5 CVS 2.4 CVS - and there are new command rpms on the ftp site too. I think the 2.4.18 split patches should be immune to this too, but there are other problems fixed since then - there are no 2.4.19 patches yet. 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 18 10:07:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2II7vY05280 for linux-xfs-outgoing; Mon, 18 Mar 2002 10:07:57 -0800 Received: from emergence.com (IDENT:root@mail.emergence.com [209.5.172.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2II7r905249 for ; Mon, 18 Mar 2002 10:07:53 -0800 Received: from emergence.com (relative.emergence.com [209.5.172.43]) by emergence.com (8.9.3/8.9.3) with ESMTP id LAA04520; Mon, 18 Mar 2002 11:08:35 -0700 Message-ID: <3C962D50.2E955C9C@emergence.com> Date: Mon, 18 Mar 2002 11:09:20 -0700 From: Michael Best X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-4mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: fatal error -- xfs_repair: duplicate inode range References: <3C96259D.270CEB2E@emergence.com> <1016473250.14540.102.camel@jen.americas.sgi.com> <3C9628FB.8E3F8B0A@emergence.com> <1016473844.14540.105.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: > 2.4 CVS - and there are new command rpms on the ftp site too. I think > the 2.4.18 split patches should be immune to this too, but there are > other problems fixed since then - there are no 2.4.19 patches yet. > > Steve I will just use the xfs_repair out of the CVS tree unless the command rpms are a better choice. -Mike From owner-linux-xfs@oss.sgi.com Mon Mar 18 11:08:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IJ81w06111 for linux-xfs-outgoing; Mon, 18 Mar 2002 11:08:01 -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 g2IJ7r906085 for ; Mon, 18 Mar 2002 11:07:53 -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 g2IKHMkw017985 for ; Mon, 18 Mar 2002 14:17:22 -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 NAA15633; Mon, 18 Mar 2002 13:08:01 -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 NAA76553; Mon, 18 Mar 2002 13:08:00 -0600 (CST) Subject: Re: files in /etc/xinetd.d become 0 byte size From: Eric Sandeen To: Eric Sandeen Cc: Simon Matter , linux-xfs In-Reply-To: <1016471589.5554.35.camel@stout.americas.sgi.com> References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <3C96162B.FEBA6ABA@ch.sauter-bc.com> <1016471589.5554.35.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Mar 2002 13:08:00 -0600 Message-Id: <1016478480.5555.49.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-18 at 11:13, Eric Sandeen wrote: > On Mon, 2002-03-18 at 10:30, Simon Matter wrote: > > > I reproduced it now: > > Using ntsysv to manage services -> reboot: Files in /etc/xinetd.d have > > normal size but filled with zero. > > Trying it now... no problems. I tested it with the > 2.4.9-13SGI_XFS_1.0.2 kernel and ntsysv-1.2.24-1. (this test box is > mostly ext3, but I mounted an xfs filesystem on /etc/xinetd.d for this > test). Sorry, wasn't thinking, that wasn't a good test... I need this to be on the root fs. Let me try again... also, re: remounting readonly - I think the RH 7.2 scripts are no longer ext2-specific - they should be mounting xfs ro in the halt script. -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 18 12:41:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IKfgN07706 for linux-xfs-outgoing; Mon, 18 Mar 2002 12:41:42 -0800 Received: from kendy.up.ac.za (kendy.up.AC.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IKf9907680 for ; Mon, 18 Mar 2002 12:41:10 -0800 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 16n3xZ-0008Hr-00 for linux-xfs@oss.sgi.com; Mon, 18 Mar 2002 22:42:25 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=it.up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.15 #1) id 16n3xZ-0005yl-00 for linux-xfs@oss.sgi.com; Mon, 18 Mar 2002 22:42:25 +0200 Message-ID: <3C965130.2CAB0A19@it.up.ac.za> Date: Mon, 18 Mar 2002 22:42:24 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.19-pre2-ac2-xfs-shawn9 i686) X-Accept-Language: en MIME-Version: 1.0 To: XFS mailing list Subject: Kernel oops on new mailserver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16n3xZ-0005yl-00*rcBmDOY.LGA* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have set up a new mailserver, consisting of the following: Dell PE2550 1G RAM 2 x 1.133GHz CPUs 4x18Gb Seagate cheeta's in RAID 10 kernel 2.4.18 from cvs checked out on March 14 2002. gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) ksymoops 2.4.3 Debian 3.0 (woody) JFS 1.0.15 were also patched into the kernel, but no jfs partitions were mounted at the time. I also compiled a kernel without any other filesystem in it. Not even ext2, but also got the problem. I did'nt had a terminal connected at that time, so I don't have an oops where XFS was the only filesystem. The kernel oopsed several times lately. I caught an oops, but couldn't do stack traces. I caught another one, this time with traces on both CPUs. The e100 ethernet module from intel was loaded in the first oops. I reverted back to the stock eepro100 module in the hope that it might solve the problem. The second oops was with the eepro100 module loaded No other modules were loaded. First oops: kernel BUG at ll_rw_blk.c:978! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 0000001f ebx: 00000805 ecx: c0436068 edx: 00002e5a esi: 00000000 edi: c87e5d10 ebp: c87e5ce8 esp: c87e5cb4 ds: 0018 es: 0018 ss: 0018 Process modprobe (pid: 3891, stackpage=c87e5000) Stack: c0362282 000003d2 cac4f6a0 cace26e0 c87e5d34 cace26e0 00000040 07eb9067 c87e5cec c012420b 00001000 00000200 00000200 c87e5ef8 c0136efc 00000001 00000001 c87e5d10 cac4f680 00000001 c043d920 c87e5d34 00000000 cace26e0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 8d 76 00 83 c7 04 46 3b 75 0c 7c bb 8b 4d 08 >>EIP; c026eec0 <===== Trace; c012420a Trace; c0136efc Trace; c01e7d60 Trace; c01e7d60 Trace; c0231594 Trace; c013734a <__refile_buffer+56/60> Trace; c013736c Trace; c023fe80 Trace; c0240212 <__pb_block_commit_write_async+2e/4c> Trace; c023f000 Trace; c02408e8 Trace; c024091a Trace; c0231582 Trace; c0231582 Trace; c021d214 Trace; c023a31c Trace; c0245a64 Trace; c023f084 Trace; c0241d58 Trace; c02361e2 Trace; c0241926 Trace; c01366b8 Trace; c010720e Code; c026eec0 00000000 <_EIP>: Code; c026eec0 <===== 0: 0f 0b ud2a <===== Code; c026eec2 2: 83 c4 08 add $0x8,%esp Code; c026eec4 5: 8d 76 00 lea 0x0(%esi),%esi Code; c026eec8 8: 83 c7 04 add $0x4,%edi Code; c026eeca b: 46 inc %esi Code; c026eecc c: 3b 75 0c cmp 0xc(%ebp),%esi Code; c026eece f: 7c bb jl ffffffcc <_EIP+0xffffffcc> c026ee8c Code; c026eed0 11: 8b 4d 08 mov 0x8(%ebp),%ecx Entering kdb (current=0xc87e4000, pid 3891) on processor 0 Oops: invalid operand Second oops: kernel BUG at ll_rw_blk.c:978! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 0000001f ebx: 00000805 ecx: c0436068 edx: 00003217 esi: 00000000 edi: c87c7d10 ebp: c87c7ce8 esp: c87c7cb4 ds: 0018 es: 0018 ss: 0018 Process modprobe (pid: 4414, stackpage=c87c7000) Stack: c0362282 000003d2 c3f4e4c0 c26f47a0 c87c7d34 c26f47a0 00000040 0343a067 c87c7cec c012420b 00001000 00000200 00000200 c87c7ef8 c0136efc 00000001 00000001 c87c7d10 c3f4e4a0 00000001 c043d920 c87c7d34 00000000 c26f47a0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 8d 76 00 83 c7 04 46 3b 75 0c 7c bb 8b 4d 08 >>EIP; c026eec0 <===== Trace; c012420a Trace; c0136efc Trace; c01e7d60 Trace; c01e7d60 Trace; c0231594 Trace; c023fe72 Trace; c0240212 <__pb_block_commit_write_async+2e/4c> Trace; c023f000 Trace; c02408e8 Trace; c024091a Trace; c0231582 Trace; c021d214 Trace; c023f084 Trace; c0241d58 Trace; c02361e2 Trace; c0241926 Trace; c01366b8 Trace; c010720e Code; c026eec0 00000000 <_EIP>: Code; c026eec0 <===== 0: 0f 0b ud2a <===== Code; c026eec2 2: 83 c4 08 add $0x8,%esp Code; c026eec4 5: 8d 76 00 lea 0x0(%esi),%esi Code; c026eec8 8: 83 c7 04 add $0x4,%edi Code; c026eeca b: 46 inc %esi Code; c026eecc c: 3b 75 0c cmp 0xc(%ebp),%esi Code; c026eece f: 7c bb jl ffffffcc <_EIP+0xffffffcc> c026ee8c Code; c026eed0 11: 8b 4d 08 mov 0x8(%ebp),%ecx Entering kdb (current=0xc87c6000, pid 4414) on processor 0 Oops: invalid operand due to oops @ 0xc026eec0 eax = 0x0000001f ebx = 0x00000805 ecx = 0xc0436068 edx = 0x00003217 esi = 0x00000000 edi = 0xc87c7d10 esp = 0xc87c7cb4 eip = 0xc026eec0 ebp = 0xc87c7ce8 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010202 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc87c7c80 [0]kdb> bt EBP EIP Function(args) 0xc87c7ce8 0xc026eec0 ll_rw_block+0x8c (0x1, 0x1, 0xc87c7d10, 0xc3f4e4a0, 0x1) kernel .text 0xc0100000 0xc026ee34 0xc026f028 0xc87c7ef8 0xc0136efc fsync_inode_data_buffers+0xbc (0xc3f4e4a0, 0xc3f4e554, 0x0) kernel .text 0xc0100000 0xc0136e40 0xc0136fe0 0xc87c7f0c 0xc023f085 pagebuf_flush+0x19 (0xc3f4e4a0, 0x0, 0x0, 0x0, 0xc3f4e5c4) kernel .text 0xc0100000 0xc023f06c 0xc023f098 0xc87c7f28 0xc0241d59 fs_flush_pages+0x29 (0xce7a7748, 0x0, 0x0, 0xffffffff, 0xffffffff) kernel .text 0xc0100000 0xc0241d30 0xc0241d64 0xc87c7f64 0xc02361e2 xfs_fsync+0xea (0xce7a7748, 0x5, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc02360f8 0xc0236380 0xc87c7f90 0xc0241926 linvfs_fsync+0x42 (0xcc608240, 0xcddd2ec0, 0x1, 0xc3f4e554, 0xc87c6000) kernel .text 0xc0100000 0xc02418e4 0xc0241934 0xc87c7fbc 0xc01366b8 sys_fdatasync+0x68 (0x0, 0x8063258, 0xbfffeca0, 0x8063258, 0x4013b6e0) kernel .text 0xc0100000 0xc0136650 0xc0136704 0xc010720f system_call+0x2f kernel .text 0xc0100000 0xc01071e0 0xc0107214 [0]kdb> cpu Currently on cpu 0 Available cpus: 0, 1 [0]kdb> cpu 1 Entering kdb (current=0xcf6f6000, pid 160) on processor 1 due to cpu switch [1]kdb> bt EBP EIP Function(args) 0xcf6f7e38 0xc0124522 pte_alloc+0xe (0xcf986660, 0xcfe90dc0, 0xcf6f6000) kernel .text 0xc0100000 0xc0124514 0xc01245f4 0xcf6f7e4c 0xc012445b handle_mm_fault+0x3b (0xcfe90dc0, 0xcf986660, 0x804dca0, 0x1, 0xcf6f6000) kernel .text 0xc0100000 0xc0124420 0xc01244e0 0xcf6f7f10 0xc0111ad7 do_page_fault+0x1af (0xc14e3080, 0xc1414000, 0xf6f8000, 0xcd29cf40, 0xc04c2900) kernel .text 0xc0100000 0xc0111928 0xc0111df3 0xcf6f7f04 0xc030ae0a unix_dgram_sendmsg+0x3c6 (0xcf6f7f20, 0x2, 0x0, 0x804dca0, 0x31f6) kernel .text 0xc0100000 0xc030aa44 0xc030ae74 0xc01072f8 error_code+0x34 kernel .text 0xc0100000 0xc01072c4 0xc0107300 Interrupt registers: eax = 0x00000000 ebx = 0xcf6f7f20 ecx = 0x00000002 edx = 0x00000000 esi = 0x0804dca0 edi = 0x000031f6 esp = 0x00000010 eip = 0x00000018 ebp = 0xc04e6ca0 xss = 0x00010246 xcs = 0xffffffff eflags = 0xc01157f7 xds = 0xcf6f7f7c xes = 0x0000313c origeax = 0x00000018 ®s = 0xcf6f7f18 Interrupt from user space, end of kernel trace [1]kdb> lsmod Module Size modstruct Used by eepro100 20152 0xd087f000 1 Pleases let me know if there is anything else that I must check. Paul Schutte From owner-linux-xfs@oss.sgi.com Mon Mar 18 12:56:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IKula07980 for linux-xfs-outgoing; Mon, 18 Mar 2002 12:56:47 -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 g2IKuV907952 for ; Mon, 18 Mar 2002 12:56:34 -0800 Received: from piaskowy.internal.prz.rzeszow.pl (promien.prz.rzeszow.pl [212.160.98.116]) 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 MAA09180 for ; Mon, 18 Mar 2002 12:57:54 -0800 (PST) mail_from (mzieba@prz-rzeszow.pl) From: mzieba@prz-rzeszow.pl Received: from piaskowy.internal.prz.rzeszow.pl (localhost [127.0.0.1]) by piaskowy.internal.prz.rzeszow.pl (8.12.1/8.12.1/Debian -5) with ESMTP id g2IKvWlG001650 for ; Mon, 18 Mar 2002 21:57:32 +0100 Received: (from mzieba@localhost) by piaskowy.internal.prz.rzeszow.pl (8.12.1/8.12.1/Debian -5) id g2IKvRZN001649 for linux-xfs@oss.sgi.com; Mon, 18 Mar 2002 21:57:27 +0100 Date: Mon, 18 Mar 2002 21:57:27 +0100 To: linux-xfs@oss.sgi.com Subject: Oops on 2.4.17, some fs corruption. Message-ID: <20020318205727.GA1462@prz-rzeszow.pl> Reply-To: mzieba@prz-rzeszow.pl Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I've got Oops on 2.4.17 cvs-ed ~21 Feb, after my problem with disapearing partitions in the past. It hits when I put some load on disk, trying to install newer mozilla (with dpkg). After xfs_repair I ended with whole /usr in pieces (at least it was most visible, some other files i.e. from /etc were gone too) in lost+found. Can you tell me, if it can be xfs-related? I'm asking, because I'm using tainted modules, like NVDriver, VMWare modules... Maybe it's theirs fault? ;) The kernel was compiled using gcc version 2.95.4 20011002 (Debian prerelease) Oh, btw, there was no filesystem shutdown after/before an Oops, I do not have CONFIG_DEBUG_BUGVERBOSE, should I? Friend of mine told me, that setting that will "mask" EIP.. Is it anything, I can do, to help you? ;) Regards, (please CC, I'm not a subscriber) -- Marcin Zieba mzieba@prz-rzeszow.pl --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="decoded.13Mar" ksymoops 2.4.3 on i586 2.4.17-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.17-xfs/ (default) -m /boot/System.map-2.4.17-xfs (default) Warning: You did not tell me where to find symbol information. I will [...] Mar 13 22:06:31 piaskowy kernel: c019eff2 Mar 13 22:06:31 piaskowy kernel: *pde = 00000000 Mar 13 22:06:31 piaskowy kernel: Oops: 0000 Mar 13 22:06:31 piaskowy kernel: CPU: 0 Mar 13 22:06:31 piaskowy kernel: EIP: 0010:[] Tainted: PF Using defaults from ksymoops -t elf32-i386 -a i386 Mar 13 22:06:31 piaskowy kernel: EFLAGS: 00210246 Mar 13 22:06:31 piaskowy kernel: eax: 00000000 ebx: ffffffe8 ecx: c02dbd64 Mar 13 22:06:31 piaskowy kernel: esi: cdfae554 edi: c1663000 ebp: 00000000 Mar 13 22:06:31 piaskowy kernel: ds: 0018 es: 0018 ss: 0018 Mar 13 22:06:31 piaskowy kernel: Process dpkg (pid: 21524, stackpage=c1cab000) Mar 13 22:06:31 piaskowy kernel: Stack: 0000002e cfbf02ac 00000000 00000008 c01b3b7c c1663000 00000000 00804ed0 Mar 13 22:06:31 piaskowy kernel: 00000000 00000000 c1cabe04 00000000 00000000 c1cabdfc c1cabe14 00000000 Mar 13 22:06:31 piaskowy kernel: c1cabed4 00000000 00000011 c019f449 cfbf0338 c01ae732 00000000 cfbf02c4 Mar 13 22:06:31 piaskowy kernel: Call Trace: [] [] [] [] [] Mar 13 22:06:31 piaskowy kernel: [] [] [] [] [] [] Mar 13 22:06:31 piaskowy kernel: [] [] [] Mar 13 22:06:31 piaskowy kernel: Code: 66 83 bb 56 01 00 00 00 75 10 80 a3 48 01 00 00 f7 53 e8 9f >>EIP; c019eff2 <===== Trace; c01b3b7c Trace; c019f448 Trace; c01ae732 Trace; c01aecd8 Trace; d88a25ac <[sound]DMAbuf_outputintr+100/130> Trace; d88b21bc <[sb_lib]sb_intr+b8/f4> Trace; d88b2246 <[sb_lib]sbintr+32/38> Trace; c01b224e Trace; c019f546 Trace; c01c51d4 Trace; c0137c18 Trace; c0137ca8 Trace; c0137e82 Trace; c0106d32 Code; c019eff2 00000000 <_EIP>: Code; c019eff2 <===== 0: 66 83 bb 56 01 00 00 cmpw $0x0,0x156(%ebx) <===== Code; c019eff8 7: 00 Code; c019effa 8: 75 10 jne 1a <_EIP+0x1a> c019f00c Code; c019effc a: 80 a3 48 01 00 00 f7 andb $0xf7,0x148(%ebx) Code; c019f002 11: 53 push %ebx Code; c019f004 12: e8 9f 00 00 00 call b6 <_EIP+0xb6> c019f0a8 1 warning issued. Results may not be reliable. --XsQoSWH+UP9D9v3l-- From owner-linux-xfs@oss.sgi.com Mon Mar 18 13:05:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IL5uF08255 for linux-xfs-outgoing; Mon, 18 Mar 2002 13:05:56 -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 g2IL5n908229 for ; Mon, 18 Mar 2002 13:05:50 -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 g2IM7CBA016121 for ; Mon, 18 Mar 2002 14:07:13 -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 IAA23821; Tue, 19 Mar 2002 08:05:55 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA18609; Tue, 19 Mar 2002 08:05:55 +1100 (AEDT) Date: Tue, 19 Mar 2002 08:05:54 +1100 From: Nathan Scott To: Michael Best Cc: linux-xfs@oss.sgi.com Subject: Re: fatal error -- xfs_repair: duplicate inode range Message-ID: <20020319080554.P1601@wobbly.melbourne.sgi.com> References: <3C96259D.270CEB2E@emergence.com> <1016473250.14540.102.camel@jen.americas.sgi.com> <3C9628FB.8E3F8B0A@emergence.com> <1016473844.14540.105.camel@jen.americas.sgi.com> <3C962D50.2E955C9C@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C962D50.2E955C9C@emergence.com>; from mbest@emergence.com on Mon, Mar 18, 2002 at 11:09:20AM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Mar 18, 2002 at 11:09:20AM -0700, Michael Best wrote: > Steve Lord wrote: > > 2.4 CVS - and there are new command rpms on the ftp site too. I think > > the 2.4.18 split patches should be immune to this too, but there are > > other problems fixed since then - there are no 2.4.19 patches yet. > > > > Steve > > I will just use the xfs_repair out of the CVS tree unless the command > rpms are a better choice. > Any 2.0.0+ user tools are fine for 2.4.18 (both of the above are fine). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 18 13:30:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ILUTC08608 for linux-xfs-outgoing; Mon, 18 Mar 2002 13:30:29 -0800 Received: from emergence.com (IDENT:root@mail.emergence.com [209.5.172.194]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ILUN908582 for ; Mon, 18 Mar 2002 13:30:23 -0800 Received: from emergence.com (relative.emergence.com [209.5.172.43]) by emergence.com (8.9.3/8.9.3) with ESMTP id OAA14798; Mon, 18 Mar 2002 14:31:04 -0700 Message-ID: <3C965CC5.D7DD7A@emergence.com> Date: Mon, 18 Mar 2002 14:31:49 -0700 From: Michael Best X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-4mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: fatal error -- xfs_repair: duplicate inode range References: <3C96259D.270CEB2E@emergence.com> <1016473250.14540.102.camel@jen.americas.sgi.com> <3C9628FB.8E3F8B0A@emergence.com> <1016473844.14540.105.camel@jen.americas.sgi.com> <3C962D50.2E955C9C@emergence.com> <20020319080554.P1601@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for the help Steve and Nathan. The new 2.4.18-xfs (CVS) kernel with the 2.0.1-0 (CVS) tools, appear to have done the job. The filesystem was damaged to the tune of about 13751 files (those moved into lost+found), but otherwise the partition became useable again. If there is any interest in the copy of the unrepaired filesystem (16G) I can make it available, otherwise once I am done rebuilding I will simply toss it. -- Michael Best Systems Administrator ph 780-413-6397 x230 Emergence By Design fax 780-433-7548 #200, 11209 Jasper Avenue toll 866-860-2666 Edmonton, Alberta, T5K 0L5 Nathan Scott wrote: > > On Mon, Mar 18, 2002 at 11:09:20AM -0700, Michael Best wrote: > > Steve Lord wrote: > > > 2.4 CVS - and there are new command rpms on the ftp site too. I think > > > the 2.4.18 split patches should be immune to this too, but there are > > > other problems fixed since then - there are no 2.4.19 patches yet. > > > > > > Steve > > > > I will just use the xfs_repair out of the CVS tree unless the command > > rpms are a better choice. > > > > Any 2.0.0+ user tools are fine for 2.4.18 (both of the above are fine). > > cheers. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 18 13:56:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ILuQ509022 for linux-xfs-outgoing; Mon, 18 Mar 2002 13:56:26 -0800 Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ILuA908995 for ; Mon, 18 Mar 2002 13:56:11 -0800 Received: from user-uivf38j.dsl.mindspring.com ([165.247.141.19] helo=sandbox.wingenbach.org) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16n58H-0005KQ-00; Mon, 18 Mar 2002 16:57:33 -0500 Received: from wingenbach.org (jwinglap.wingenbach.org [10.10.10.25]) by sandbox.wingenbach.org (8.11.4/8.11.4) with ESMTP id g2ILvMp10112; Mon, 18 Mar 2002 16:57:22 -0500 (EST) Message-ID: <3C9662C7.228A1049@wingenbach.org> Date: Mon, 18 Mar 2002 16:57:27 -0500 From: John Wingenbach X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Schutte CC: XFS mailing list Subject: Re: Kernel oops on new mailserver References: <3C965130.2CAB0A19@it.up.ac.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I couldn't bet the farm on it. But every time I see someone using the stock RedHat egcs compiler I cringe. egcs-2.91.66 from Redhat has caused more problems due to an optimizer bug. There are several news groups where it is the root cause of problems in several apps. Upgrade your compiler (and rebuild your kernel) and that very well may eliminate your problems. -- John Wingenbach Paul Schutte wrote: > Hi, > > I have set up a new mailserver, consisting of the following: > > Dell PE2550 > 1G RAM > 2 x 1.133GHz CPUs > 4x18Gb Seagate cheeta's in RAID 10 > > kernel 2.4.18 from cvs checked out on March 14 2002. > gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) > ksymoops 2.4.3 > Debian 3.0 (woody) > JFS 1.0.15 were also patched into the kernel, but no jfs partitions were > mounted at the time. > I also compiled a kernel without any other filesystem in it. Not even > ext2, but also got the problem. > I did'nt had a terminal connected at that time, so I don't have an oops > where XFS was the only > filesystem. > > The kernel oopsed several times lately. > I caught an oops, but couldn't do stack traces. > I caught another one, this time with traces on both CPUs. > The e100 ethernet module from intel was loaded in the first oops. > I reverted back to the stock eepro100 module in the hope that it might > solve the problem. > The second oops was with the eepro100 module loaded > No other modules were loaded. > > Kernel trace removed... > > > Pleases let me know if there is anything else that I must check. > > Paul Schutte From owner-linux-xfs@oss.sgi.com Mon Mar 18 14:33:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IMXxd12005 for linux-xfs-outgoing; Mon, 18 Mar 2002 14:33:59 -0800 Received: from mailnet.consensys.com ([209.47.40.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IMXp911977 for ; Mon, 18 Mar 2002 14:33:51 -0800 Received: from Francis ([209.47.40.10]) by mailnet.consensys.com (8.11.6/8.11.2) with SMTP id g2IHUWW21707 for ; Mon, 18 Mar 2002 17:30:32 GMT Message-ID: <00c401c1cecd$2e8aa420$8d02a8c0@consensys.com> From: "Francis Qu" To: Subject: write event Date: Mon, 18 Mar 2002 17:35:18 -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, I am testing sample_hsm/migin. After it catches a write event, it tries to clear managed regions by calling dm_set_region with DM_REGION_NOEVENT. It never returns from this call while the user write operation is suspended. It has the DM_RIGHT_EXCL before making the call, so there could be no access right problem. What's wrong? Thanks a lot. Francis [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Mar 18 14:40:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IMe2Y12191 for linux-xfs-outgoing; Mon, 18 Mar 2002 14:40:02 -0800 Received: from www.fortuitous.com (cs6625128-203.austin.rr.com [66.25.128.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IMdw912163 for ; Mon, 18 Mar 2002 14:39:58 -0800 Received: by www.fortuitous.com (Postfix, from userid 500) id 7197E15D; Mon, 18 Mar 2002 16:37:49 -0600 (CST) Date: Mon, 18 Mar 2002 16:37:49 -0600 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Distributed File Systems. Which is best? Message-ID: <20020318223749.GB17642@bistro.marx> Reply-To: pac@fortuitous.com References: <85063BBE668FD411944400D0B744267A88872A@AUSMAIL> <20011107212340.A25294@bistro.marx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011107212340.A25294@bistro.marx> User-Agent: Mutt/1.3.25i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Anyone use or care about: a. Coda b. Intermezzo Does Coda have its own filesystem, or does it use an underlying FS? Intermezzo tries to use the underlying FS. What are the advantages/disadvantages to each from your perspective? Thanks, -Phil Carinhas -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-467-2154 | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Mon Mar 18 14:55:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IMt7P12579 for linux-xfs-outgoing; Mon, 18 Mar 2002 14:55: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 g2IMt3912523 for ; Mon, 18 Mar 2002 14:55:03 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g2IMuTXt009885 for ; Tue, 19 Mar 2002 09:56:29 +1100 (EST) Received: from jdc.local (ppp204.dyn141.pacific.net.au [210.23.141.204]) by wisma.pacific.net.au with ESMTP id JAA08390 for ; Tue, 19 Mar 2002 09:56:28 +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 g2IMuQ7X002609 for ; Tue, 19 Mar 2002 09:56:26 +1100 Received: (from jason@localhost) by jdc.local (8.12.1/8.12.1/Debian -5) id g2IMuOSS002601; Tue, 19 Mar 2002 09:56:24 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15510.28824.127449.355731@jdc.local> Date: Tue, 19 Mar 2002 09:56:24 +1100 To: linux-xfs@oss.sgi.com Subject: Re: Distributed File Systems. Which is best? In-Reply-To: <20020318223749.GB17642@bistro.marx> References: <85063BBE668FD411944400D0B744267A88872A@AUSMAIL> <20011107212340.A25294@bistro.marx> <20020318223749.GB17642@bistro.marx> 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 pac@fortuitous.com writes: > > Anyone use or care about: > > a. Coda > b. Intermezzo Why not consider c. OpenAFS (http://www.openafs.org/) which I have never used, but apparently it works (or at least used to work/has been rumored to work) with XFS as the underlying file system on the AFS partitions. From owner-linux-xfs@oss.sgi.com Mon Mar 18 14:57:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2IMv5I12737 for linux-xfs-outgoing; Mon, 18 Mar 2002 14:57:05 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2IMux912700 for ; Mon, 18 Mar 2002 14:56:59 -0800 Received: (qmail 8773 invoked by uid 500); 18 Mar 2002 22:57:52 -0000 Subject: Re: Distributed File Systems. Which is best? From: Austin Gonyou To: pac@fortuitous.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020318223749.GB17642@bistro.marx> References: <20020318223749.GB17642@bistro.marx> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 18 Mar 2002 16:57:52 -0600 Message-Id: <1016492272.8135.40.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So..those are not true distributed FS in the way that GFS,PolyServe, etc are. I'd say that because GFS and PolyServe have block level locking. In terms of a network filesystem though, that they are. On Mon, 2002-03-18 at 16:37, pac@fortuitous.com wrote: > > Anyone use or care about: > > a. Coda > b. Intermezzo > > Does Coda have its own filesystem, or does it use an underlying FS? > Intermezzo tries to use the underlying FS. > > What are the advantages/disadvantages to each from your perspective? > > Thanks, > > -Phil Carinhas > -- > .--------------------------------------------------------. > | Dr. Philip A. Carinhas | pac@fortuitous.com | > | Fortuitous Technologies Inc. | http://fortuitous.com | > | Linux Consulting & Training | Tel : 1-512-467-2154 | > `--------------------------------------------------------' -- 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 18 15:11:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2INB8m13047 for linux-xfs-outgoing; Mon, 18 Mar 2002 15:11:08 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2INB3913017 for ; Mon, 18 Mar 2002 15:11:03 -0800 Received: (qmail 8899 invoked by uid 500); 18 Mar 2002 23:11:58 -0000 Subject: Re: Distributed File Systems. Which is best? From: Austin Gonyou To: jasonw@ariel.ucs.unimelb.edu.au Cc: linux-xfs@oss.sgi.com In-Reply-To: <15510.28824.127449.355731@jdc.local> References: <15510.28824.127449.355731@jdc.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 18 Mar 2002 17:11:58 -0600 Message-Id: <1016493118.7723.59.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ahh..yes...openAFS. I should've thought about that one. Then you could user kerberos too! :) On Mon, 2002-03-18 at 16:56, Jason White wrote: > pac@fortuitous.com writes: > > > > Anyone use or care about: > > > > a. Coda > > b. Intermezzo > > Why not consider > c. OpenAFS (http://www.openafs.org/) which I have never used, but > apparently it works (or at least used to work/has been rumored to > work) with XFS as the underlying file system on the AFS partitions. -- 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 18 15:43:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2INhYl13420 for linux-xfs-outgoing; Mon, 18 Mar 2002 15:43:34 -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 g2INhS913383 for ; Mon, 18 Mar 2002 15:43:28 -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 g2J0qvkw021327 for ; Mon, 18 Mar 2002 18:52:57 -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 RAA23867; Mon, 18 Mar 2002 17:43:35 -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 RAA18651; Mon, 18 Mar 2002 17:43:35 -0600 (CST) Subject: Re: Oops on 2.4.17, some fs corruption. From: Eric Sandeen To: mzieba@prz-rzeszow.pl Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020318205727.GA1462@prz-rzeszow.pl> References: <20020318205727.GA1462@prz-rzeszow.pl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Mar 2002 17:43:35 -0600 Message-Id: <1016495015.2713.24.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This backtace looks very similar to one reported Jan 05 2001, so it's probably XFS - although I wish I could blame your modules. :) Is this repeatable? -Eric On Mon, 2002-03-18 at 14:57, mzieba@prz-rzeszow.pl wrote: > Hi, > I've got Oops on 2.4.17 cvs-ed ~21 Feb, after my problem with > disapearing partitions in the past. It hits when I put some load on disk, trying to > install newer mozilla (with dpkg). After xfs_repair I ended with whole > /usr in pieces (at least it was most visible, some other files i.e. from > /etc were gone too) in lost+found. > Can you tell me, if it can be xfs-related? I'm asking, because I'm using > tainted modules, like NVDriver, VMWare modules... Maybe it's theirs > fault? ;) > The kernel was compiled using gcc version 2.95.4 20011002 (Debian > prerelease) > Oh, btw, there was no filesystem shutdown after/before an Oops, I do > not have CONFIG_DEBUG_BUGVERBOSE, should I? Friend of mine told me, that > setting that will "mask" EIP.. > Is it anything, I can do, to help you? ;) > > Regards, > (please CC, I'm not a subscriber) > -- > Marcin Zieba > mzieba@prz-rzeszow.pl > ---- > -- 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 18 18:06:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J26Xv15728 for linux-xfs-outgoing; Mon, 18 Mar 2002 18:06:33 -0800 Received: from www.fortuitous.com (cs6625128-203.austin.rr.com [66.25.128.203]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2J26S915701 for ; Mon, 18 Mar 2002 18:06:28 -0800 Received: by www.fortuitous.com (Postfix, from userid 500) id 3675F15D; Mon, 18 Mar 2002 20:04:19 -0600 (CST) Date: Mon, 18 Mar 2002 20:04:19 -0600 From: pac@fortuitous.com To: linux-xfs@oss.sgi.com Subject: Re: Distributed File Systems. Which is best? Message-ID: <20020319020419.GA19296@bistro.marx> Reply-To: pac@fortuitous.com References: <15510.28824.127449.355731@jdc.local> <1016493118.7723.59.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1016493118.7723.59.camel@UberGeek> User-Agent: Mutt/1.3.25i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Mar 18, 2002 at 05:11:58PM -0600, Austin Gonyou wrote: > Ahh..yes...openAFS. I should've thought about that one. Then you could > user kerberos too! :) > > On Mon, 2002-03-18 at 16:56, Jason White wrote: > > pac@fortuitous.com writes: > > > > > > Anyone use or care about: > > > > > > a. Coda > > > b. Intermezzo > > > > Why not consider > > c. OpenAFS (http://www.openafs.org/) which I have never used, but > > apparently it works (or at least used to work/has been rumored to > > work) with XFS as the underlying file system on the AFS partitions. I'll consider it. But that still leaves us where we started. Has anyone Used any of these, and why are there so many projects working independently of each other, and which is the most reliable? -Phil Carinhas -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac@fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-467-2154 | `--------------------------------------------------------' From owner-linux-xfs@oss.sgi.com Mon Mar 18 19:03:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J332G16525 for linux-xfs-outgoing; Mon, 18 Mar 2002 19:03:02 -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 g2J32s916499 for ; Mon, 18 Mar 2002 19:02:55 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g2J34MXt018528 for ; Tue, 19 Mar 2002 14:04:22 +1100 (EST) Received: from jdc.local (ppp103.dyn134.pacific.net.au [210.23.134.103]) by wisma.pacific.net.au with ESMTP id OAA03638 for ; Tue, 19 Mar 2002 14:04:21 +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 g2J34J3k001573 for ; Tue, 19 Mar 2002 14:04:19 +1100 Received: (from jason@localhost) by jdc.local (8.12.1/8.12.1/Debian -5) id g2J34HID001565; Tue, 19 Mar 2002 14:04:17 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15510.43696.738518.773137@jdc.local> Date: Tue, 19 Mar 2002 14:04:16 +1100 To: linux-xfs@oss.sgi.com Subject: Re: Distributed File Systems. Which is best? In-Reply-To: <20020319020419.GA19296@bistro.marx> References: <15510.28824.127449.355731@jdc.local> <1016493118.7723.59.camel@UberGeek> <20020319020419.GA19296@bistro.marx> 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 pac@fortuitous.com writes: > > > > > > Why not consider > > > c. OpenAFS (http://www.openafs.org/) which I have never used, but > > > apparently it works (or at least used to work/has been rumored to > > > work) with XFS as the underlying file system on the AFS partitions. > > I'll consider it. But that still leaves us where we started. > Has anyone Used any of these, and why are there so many projects > working independently of each other, and which is the most reliable? AFS has a strong reputation for reliability, and it is also the oldest of the systems mentioned, having been used widely in university and corporate settings for years. However I am not acquainted with its reliability or performance under XFS. As to why there are so many projects in this area, I suspect a number of reasons, including different design goals, some projects being newer than others (the desire for a "fresh start" with a different approach to the design), etc. From owner-linux-xfs@oss.sgi.com Mon Mar 18 19:21:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J3LYX16871 for linux-xfs-outgoing; Mon, 18 Mar 2002 19:21: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 g2J3LS916845 for ; Mon, 18 Mar 2002 19:21:28 -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 g2J3Mq6G031008 for ; Mon, 18 Mar 2002 19:22:52 -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 VAA24904; Mon, 18 Mar 2002 21:21:37 -0600 (CST) Received: from sgi.com (cYdsZtjQpdo1e5L8b+P0SkmWgxcv8suG@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 VAA89354; Mon, 18 Mar 2002 21:21:36 -0600 (CST) Message-ID: <3C96AEDC.1030801@sgi.com> Date: Mon, 18 Mar 2002 21:22:04 -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: jasonw@ariel.ucs.unimelb.edu.au CC: linux-xfs@oss.sgi.com Subject: Re: Distributed File Systems. Which is best? References: <15510.28824.127449.355731@jdc.local> <1016493118.7723.59.camel@UberGeek> <20020319020419.GA19296@bistro.marx> <15510.43696.738518.773137@jdc.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jason White wrote: >pac@fortuitous.com writes: > > > > > > > > Why not consider > > > > c. OpenAFS (http://www.openafs.org/) which I have never used, but > > > > apparently it works (or at least used to work/has been rumored to > > > > work) with XFS as the underlying file system on the AFS partitions. > > > > I'll consider it. But that still leaves us where we started. > > Has anyone Used any of these, and why are there so many projects > > working independently of each other, and which is the most reliable? > >AFS has a strong reputation for reliability, and it is >also the oldest of the systems mentioned, having been used widely in >university and corporate settings for years. However I am not >acquainted with its reliability or performance under XFS. > >As to why there are so many projects in this area, I suspect a number >of reasons, including different design goals, some projects being >newer than others (the desire for a "fresh start" with a different >approach to the design), etc. > If you dig back in the xfs list archives, you should find some references to open AFS. Someone, I cannot remember who, got it all working and made patches available. AFS does have XFS support built in, but it is Irix XFS support getting linux XFS going required some work. Steve From owner-linux-xfs@oss.sgi.com Mon Mar 18 20:09:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J49Nb17481 for linux-xfs-outgoing; Mon, 18 Mar 2002 20:09:23 -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 g2J48s917454 for ; Mon, 18 Mar 2002 20:08:54 -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 g2J5AIBA029773 for ; Mon, 18 Mar 2002 21:10:18 -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 WAA25488 for ; Mon, 18 Mar 2002 22:09: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 WAA61583 for ; Mon, 18 Mar 2002 22:09:02 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2J471W01265; Mon, 18 Mar 2002 22:07:01 -0600 Message-Id: <200203190407.g2J471W01265@jen.americas.sgi.com> Date: Mon, 18 Mar 2002 22:07:01 -0600 Subject: TAKE - merge up to 2.5.7 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 18 20:06:41 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:114400a linux/Documentation/sound/alsa/serial-u16550.txt - 1.1 linux/sound/core/ioctl32/seq32.c - 1.1 linux/ipc/shm.c - 1.53 linux/include/linux/msdos_fs_sb.h - 1.9 linux/include/linux/msdos_fs.h - 1.18 linux/include/linux/iso_fs.h - 1.15 linux/include/linux/init.h - 1.17 linux/include/linux/hfs_fs.h - 1.11 linux/include/linux/fs.h - 1.162 linux/include/linux/amigaffs.h - 1.9 linux/include/linux/affs_fs_sb.h - 1.4 linux/include/linux/affs_fs.h - 1.10 linux/include/asm-ppc/siginfo.h - 1.9 linux/fs/vfat/namei.c - 1.29 linux/fs/umsdos/inode.c - 1.24 linux/fs/super.c - 1.82 linux/fs/msdos/namei.c - 1.29 linux/fs/msdos/msdosfs_syms.c - 1.10 linux/fs/isofs/rock.c - 1.20 linux/fs/isofs/namei.c - 1.11 linux/fs/isofs/joliet.c - 1.8 linux/fs/isofs/inode.c - 1.35 linux/fs/isofs/dir.c - 1.15 linux/fs/hfs/super.c - 1.16 linux/fs/filesystems.c - 1.22 linux/fs/affs/symlink.c - 1.13 linux/fs/affs/super.c - 1.22 linux/fs/affs/namei.c - 1.18 linux/fs/affs/inode.c - 1.19 linux/fs/affs/file.c - 1.26 linux/fs/affs/dir.c - 1.13 linux/fs/affs/bitmap.c - 1.9 linux/fs/affs/amigaffs.c - 1.12 linux/drivers/pci/pci.c - 1.57 linux/drivers/Makefile - 1.31 linux/arch/sparc64/defconfig - 1.64 linux/arch/sparc64/config.in - 1.54 linux/arch/sparc/config.in - 1.35 linux/arch/ppc/kernel/align.c - 1.9 linux/arch/ppc/defconfig - 1.39 linux/arch/ppc/config.in - 1.47 linux/arch/mips/config.in - 1.28 linux/arch/m68k/config.in - 1.27 linux/arch/i386/defconfig - 1.104 linux/arch/i386/config.in - 1.76 linux/arch/arm/config.in - 1.37 linux/arch/alpha/defconfig - 1.26 linux/arch/alpha/config.in - 1.43 linux/Makefile - 1.192 linux/include/linux/ide.h - 1.44 linux/drivers/usb/printer.c - 1.44 linux/arch/arm/def-configs/footbridge - 1.11 linux/drivers/pnp/isapnp.c - 1.27 linux/arch/sh/config.in - 1.24 linux/fs/udf/super.c - 1.28 linux/fs/udf/udf_sb.h - 1.8 linux/fs/udf/udfdecl.h - 1.19 linux/include/linux/pci_ids.h - 1.62 linux/drivers/pci/pci.ids - 1.44 linux/arch/ppc/configs/pmac_defconfig - 1.6 linux/arch/ppc/configs/common_defconfig - 1.26 linux/fs/cramfs/uncompress.c - 1.6 linux/drivers/usb/hid.h - 1.18 linux/arch/ia64/defconfig - 1.14 linux/arch/ia64/config.in - 1.26 linux/arch/mips64/config.in - 1.19 linux/drivers/ide/piix.c - 1.19 linux/drivers/ide/pdc4030.c - 1.12 linux/drivers/ide/ide-proc.c - 1.15 linux/drivers/ide/ide-pci.c - 1.24 linux/drivers/ide/ide-disk.c - 1.30 linux/drivers/ide/Makefile - 1.18 linux/drivers/ide/Config.in - 1.20 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.13 linux/drivers/usb/serial/keyspan_pda.c - 1.23 linux/drivers/usb/serial/ftdi_sio.c - 1.33 linux/drivers/usb/serial/usbserial.c - 1.32 linux/drivers/usb/serial/whiteheat.c - 1.23 linux/drivers/usb/serial/visor.c - 1.32 linux/drivers/usb/serial/omninet.c - 1.22 linux/drivers/usb/serial/digi_acceleport.c - 1.24 linux/drivers/usb/serial/keyspan.c - 1.24 linux/drivers/ide/slc90e66.c - 1.9 linux/drivers/usb/serial/mct_u232.c - 1.17 linux/drivers/usb/serial/empeg.c - 1.21 linux/mm/shmem.c - 1.34 linux/arch/cris/config.in - 1.12 linux/drivers/usb/serial/io_edgeport.c - 1.23 linux/net/wanrouter/af_wanpipe.c - 1.6 linux/arch/mips/defconfig-it8172 - 1.4 linux/arch/mips/defconfig-ddb5476 - 1.4 linux/include/linux/if_wanpipe.h - 1.3 linux/drivers/usb/catc.c - 1.10 linux/drivers/usb/serial/cyberjack.c - 1.11 linux/drivers/usb/serial/pl2303.c - 1.12 linux/drivers/ide/amd74xx.c - 1.7 linux/drivers/usb/hid-core.c - 1.11 linux/drivers/usb/hiddev.c - 1.6 linux/include/linux/hiddev.h - 1.2 linux/fs/jffs2/super.c - 1.10 linux/include/linux/jffs2_fs_sb.h - 1.5 linux/drivers/usb/serial/ir-usb.c - 1.12 linux/fs/inflate_fs/Makefile - 1.2 linux/fs/inflate_fs/adler32.c - 1.2 linux/fs/inflate_fs/infblock.c - 1.2 linux/fs/inflate_fs/infblock.h - 1.2 linux/fs/inflate_fs/infcodes.c - 1.2 linux/fs/inflate_fs/infcodes.h - 1.2 linux/fs/inflate_fs/inffast.c - 1.2 linux/fs/inflate_fs/inffast.h - 1.2 linux/fs/inflate_fs/inffixed.h - 1.2 linux/fs/inflate_fs/inflate.c - 1.2 linux/fs/inflate_fs/inflate_syms.c - 1.3 linux/fs/inflate_fs/inftrees.c - 1.2 linux/fs/inflate_fs/inftrees.h - 1.2 linux/fs/inflate_fs/infutil.c - 1.2 linux/fs/inflate_fs/infutil.h - 1.3 linux/fs/inflate_fs/zutil.h - 1.2 linux/fs/isofs/compress.c - 1.6 linux/include/linux/zlib_fs.h - 1.3 linux/drivers/block/block_ioctl.c - 1.7 linux/drivers/usb/serial/ipaq.c - 1.5 linux/drivers/usb/serial/kl5kusb105.c - 1.5 linux/arch/arm/def-configs/iq80310 - 1.3 linux/drivers/ide/ide-taskfile.c - 1.7 linux/arch/alpha/Config.help - 1.4 linux/arch/arm/Config.help - 1.6 linux/arch/cris/Config.help - 1.4 linux/arch/i386/Config.help - 1.6 linux/arch/ia64/Config.help - 1.4 linux/arch/m68k/Config.help - 1.3 linux/arch/mips/Config.help - 1.3 linux/arch/mips64/Config.help - 1.3 linux/arch/parisc/Config.help - 1.2 linux/arch/ppc/Config.help - 1.5 linux/arch/sh/Config.help - 1.3 linux/drivers/usb/Config.help - 1.5 linux/arch/sparc64/Config.help - 1.3 linux/drivers/ide/Config.help - 1.7 linux/drivers/base/core.c - 1.6 linux/sound/ppc/pmac.c - 1.3 linux/sound/pci/ymfpci/ymfpci_main.c - 1.3 linux/sound/pci/ymfpci/ymfpci.c - 1.5 linux/sound/pci/via8233.c - 1.4 linux/sound/pci/via686.c - 1.4 linux/sound/pci/trident/trident_main.c - 1.3 linux/sound/pci/trident/trident.c - 1.4 linux/sound/pci/sonicvibes.c - 1.4 linux/sound/pci/rme9652/rme9652.c - 1.4 linux/sound/pci/rme96.c - 1.4 linux/sound/pci/nm256/nm256.c - 1.4 linux/sound/pci/maestro3.c - 1.4 linux/sound/pci/korg1212/korg1212.c - 1.4 linux/sound/pci/intel8x0.c - 1.4 linux/sound/pci/ice1712.c - 1.4 linux/sound/pci/fm801.c - 1.4 linux/sound/pci/es1968.c - 1.4 linux/sound/pci/es1938.c - 1.4 linux/sound/pci/ens1370.c - 1.4 linux/sound/pci/emu10k1/emuproc.c - 1.4 linux/sound/pci/emu10k1/emupcm.c - 1.4 linux/sound/pci/emu10k1/emu10k1_main.c - 1.4 linux/sound/pci/emu10k1/emu10k1.c - 1.4 linux/sound/pci/emu10k1/Makefile - 1.2 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.3 linux/sound/pci/cs46xx/cs46xx.c - 1.4 linux/sound/pci/cs4281.c - 1.4 linux/sound/pci/cmipci.c - 1.4 linux/sound/pci/als4000.c - 1.4 linux/sound/pci/ali5451/ali5451.c - 1.4 linux/sound/pci/ac97/ac97_codec.c - 1.4 linux/arch/ppc/configs/k2_defconfig - 1.3 linux/arch/ppc/configs/menf1_defconfig - 1.3 linux/arch/ppc/configs/mvme5100_defconfig - 1.2 linux/arch/ppc/configs/pplus_defconfig - 1.3 linux/arch/ppc/configs/sandpoint_defconfig - 1.3 linux/arch/ppc/kernel/prom_init.c - 1.2 linux/arch/ppc/platforms/pmac_feature.c - 1.2 linux/arch/x86_64/config.in - 1.4 linux/sound/oss/Config.help - 1.2 linux/sound/isa/wavefront/wavefront_synth.c - 1.4 linux/sound/isa/wavefront/wavefront_midi.c - 1.3 linux/sound/isa/wavefront/wavefront_fx.c - 1.3 linux/sound/isa/wavefront/wavefront.c - 1.4 linux/sound/isa/wavefront/Makefile - 1.2 linux/sound/isa/sb/sb_common.c - 1.4 linux/sound/isa/sb/sb8.c - 1.5 linux/sound/isa/sb/sb16_main.c - 1.4 linux/sound/isa/sb/sb16.c - 1.4 linux/sound/isa/sb/es968.c - 1.3 linux/sound/isa/sb/emu8000.c - 1.4 linux/sound/isa/opl3sa2.c - 1.5 linux/sound/isa/gus/interwave.c - 1.4 linux/sound/isa/gus/gusmax.c - 1.4 linux/sound/isa/gus/gusextreme.c - 1.4 linux/sound/isa/gus/gusclassic.c - 1.4 linux/sound/isa/es18xx.c - 1.4 linux/sound/isa/es1688/es1688.c - 1.4 linux/sound/isa/dt0197h.c - 1.4 linux/sound/isa/cs423x/cs4236.c - 1.4 linux/sound/isa/cmi8330.c - 1.4 linux/sound/isa/azt2320.c - 1.5 linux/sound/isa/als100.c - 1.4 linux/sound/isa/ad1816a/ad1816a.c - 1.4 linux/sound/drivers/serial-u16550.c - 1.5 linux/sound/core/seq/seq_timer.h - 1.2 linux/sound/core/seq/seq_sync.h - 1.2 linux/sound/core/seq/seq_sync.c - 1.2 linux/sound/core/seq/seq_queue.h - 1.2 linux/sound/core/seq/seq_queue.c - 1.3 linux/sound/core/seq/seq_mtc.c - 1.2 linux/sound/core/seq/seq_midi_clock.c - 1.2 linux/sound/core/seq/seq_dtl.c - 1.2 linux/sound/core/seq/seq_device.c - 1.4 linux/sound/core/seq/oss/seq_oss_synth.c - 1.3 linux/sound/core/seq/oss/seq_oss_midi.c - 1.3 linux/sound/core/seq/oss/seq_oss_init.c - 1.3 linux/sound/core/seq/Makefile - 1.4 linux/sound/core/rtctimer.c - 1.6 linux/sound/core/rawmidi.c - 1.4 linux/sound/core/pcm_native.c - 1.4 linux/sound/core/oss/pcm_oss.c - 1.4 linux/sound/core/misc.c - 1.4 linux/sound/core/Makefile - 1.4 linux/sound/core/Config.in - 1.5 linux/include/sound/version.h - 1.5 linux/include/sound/trident.h - 1.3 linux/include/sound/sndmagic.h - 1.2 linux/include/sound/rawmidi.h - 1.2 linux/include/sound/emu10k1.h - 1.3 linux/include/sound/cs46xx.h - 1.3 linux/include/sound/asoundef.h - 1.2 linux/include/asm-ppc/thread_info.h - 1.3 linux/arch/ppc64/config.in - 1.2 linux/sound/core/ioctl32/timer32.c - 1.2 linux/sound/core/ioctl32/rawmidi32.c - 1.2 linux/sound/core/ioctl32/pcm32.c - 1.2 linux/sound/core/ioctl32/ioctl32.c - 1.2 linux/sound/core/ioctl32/hwdep32.c - 1.2 linux/sound/core/ioctl32/Makefile - 1.2 linux/fs/jffs2/os-linux.h - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-bigsur-mp - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-bigsur-sp - 1.2 linux/drivers/acpi/acpi_bus.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Mar 18 21:02:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J52ES18060 for linux-xfs-outgoing; Mon, 18 Mar 2002 21:02:14 -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 g2J52A918033 for ; Mon, 18 Mar 2002 21:02:10 -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 g2J53W6G000573 for ; Mon, 18 Mar 2002 21:03:33 -0800 Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA65824 for linux-xfs@oss.sgi.com; Tue, 19 Mar 2002 16:02:15 +1100 (EST) Date: Tue, 19 Mar 2002 16:02:15 +1100 (EST) From: Timothy Shimmin Message-Id: <200203190502.QAA65824@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump qa 064 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 18 20:59:21 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:114401a cmd/xfstests/064 - 1.3 - Add more info to 064.full which will allow checking to see that the set of files for incremental dumping have been modified like they are supposed to. Added to help in tracking down some sporadic 064 failures. From owner-linux-xfs@oss.sgi.com Mon Mar 18 21:59:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J5xwu18942 for linux-xfs-outgoing; Mon, 18 Mar 2002 21:59:58 -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 g2J5xs918916 for ; Mon, 18 Mar 2002 21:59:54 -0800 Received: by zeus.city.tvnet.hu (Postfix, from userid 500) id 8B1163C24A7A; Tue, 19 Mar 2002 07:02:44 +0100 (CET) Subject: xfs and delete of small files From: Sipos Ferenc To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 (1.0.2-2) Date: 19 Mar 2002 07:02:44 +0100 Message-Id: <1016517764.1492.2.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! When will the slow delete problem be fixed in xfs? Yesterday, I deleted 16000 emails in evolution, and it took more than 20 minutes. It's not a slow machine, (athlon 500 with 256 megs of ram), so it's clearly the problem of xfs. Thx. Paco From owner-linux-xfs@oss.sgi.com Mon Mar 18 22:02:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J623119089 for linux-xfs-outgoing; Mon, 18 Mar 2002 22:02:03 -0800 Received: from kendy.up.ac.za (kendy.up.AC.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2J61p919053 for ; Mon, 18 Mar 2002 22:01:52 -0800 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 16nChz-0001G2-00; Tue, 19 Mar 2002 08:02:55 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=it.up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.15 #1) id 16nChy-0008JL-00; Tue, 19 Mar 2002 08:02:54 +0200 Message-ID: <3C96D48D.A6AC22F9@it.up.ac.za> Date: Tue, 19 Mar 2002 08:02:53 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.19-pre2-ac2-xfs-shawn9 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Wingenbach CC: XFS mailing list Subject: Re: Kernel oops on new mailserver References: <3C965130.2CAB0A19@it.up.ac.za> <3C9662C7.228A1049@wingenbach.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16nChy-0008JL-00*kqg4MrLIyxI* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I should also have stated that I compiled the kernel with gcc version 2.95.4 (Debian prerelease) as well, the kernel still died on me, but the terminal was'nt hooked up at that time. The egcs is also not the Redhat stock egcs. I build it from source and have 30 or more kernels on other machines build with that very same compiler running for more than 6 months now. Another thing that I omited was that I used CONFIG_HIGHMEM4G=y Paul John Wingenbach wrote: > I couldn't bet the farm on it. But every time I see someone using the stock > RedHat egcs compiler I cringe. egcs-2.91.66 from Redhat has caused more > problems due to an optimizer bug. There are several news groups where it is > the root cause of problems in several apps. Upgrade your compiler (and > rebuild your kernel) and that very well may eliminate your problems. > > -- John Wingenbach > > Paul Schutte wrote: > > > Hi, > > > > I have set up a new mailserver, consisting of the following: > > > > Dell PE2550 > > 1G RAM > > 2 x 1.133GHz CPUs > > 4x18Gb Seagate cheeta's in RAID 10 > > > > kernel 2.4.18 from cvs checked out on March 14 2002. > > gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) > > ksymoops 2.4.3 > > Debian 3.0 (woody) > > JFS 1.0.15 were also patched into the kernel, but no jfs partitions were > > mounted at the time. > > I also compiled a kernel without any other filesystem in it. Not even > > ext2, but also got the problem. > > I did'nt had a terminal connected at that time, so I don't have an oops > > where XFS was the only > > filesystem. > > > > The kernel oopsed several times lately. > > I caught an oops, but couldn't do stack traces. > > I caught another one, this time with traces on both CPUs. > > The e100 ethernet module from intel was loaded in the first oops. > > I reverted back to the stock eepro100 module in the hope that it might > > solve the problem. > > The second oops was with the eepro100 module loaded > > No other modules were loaded. > > > > > > Kernel trace removed... > > > > > > > Pleases let me know if there is anything else that I must check. > > > > Paul Schutte From owner-linux-xfs@oss.sgi.com Mon Mar 18 22:16:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J6Gmr19373 for linux-xfs-outgoing; Mon, 18 Mar 2002 22:16:48 -0800 Received: from pooh.lsc.hu (IDENT:postfix@[195.56.172.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2J6GY919344 for ; Mon, 18 Mar 2002 22:16:35 -0800 Received: by pooh.lsc.hu (Postfix, from userid 547) id 17DE3E02E9; Tue, 19 Mar 2002 07:24:34 +0100 (CET) Date: Tue, 19 Mar 2002 07:24:34 +0100 From: GCS To: linux-xfs@oss.sgi.com Subject: Re: xfs and delete of small files Message-ID: <20020319072433.A11396@lsc.hu> References: <1016517764.1492.2.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1016517764.1492.2.camel@zeus.city.tvnet.hu>; from sferi@dumballah.tvnet.hu on Tue, Mar 19, 2002 at 07:02:44AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Mar 19, 2002 at 07:02:44AM +0100, Sipos Ferenc wrote: > When will the slow delete problem be fixed in xfs? I remember right, Steve said it is not going to be fixed, at least not in the near future. Btw, he would like to get it fixed, and if he would have enough time, he would like to fix it somewhen. Am I right Steve? See ya, 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 18 23:02:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J72KY19889 for linux-xfs-outgoing; Mon, 18 Mar 2002 23:02:20 -0800 Received: from mail.hs.tecmath.com ([62.16.211.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2J72C919863 for ; Mon, 18 Mar 2002 23:02:12 -0800 Received: from [192.168.98.1] (helo=superserver.humanmodeling.tecmath.de) by mail.hs.tecmath.com with esmtp (Exim 3.33 #1) id 16nDeU-0004fd-00; Tue, 19 Mar 2002 08:03:22 +0100 Received: from [192.168.98.14] (helo=tmsgi7.humanmodeling.tecmath.de) by superserver.humanmodeling.tecmath.de with esmtp (Exim 3.22 #1) id 16nDeU-0006aK-00; Tue, 19 Mar 2002 08:03:22 +0100 Date: Tue, 19 Mar 2002 08:03:22 +0100 From: Martin Apel X-X-Sender: apel@tmsgi7.humanmodeling.tecmath.de To: Jeremy Allison cc: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" , , Subject: Re: TDB corruption with Samba 2.2.3a In-Reply-To: <20020313091245.M3093@va.samba.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 13 Mar 2002, Jeremy Allison wrote: > On Wed, Mar 13, 2002 at 05:25:13AM -0500, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > > We are also experiencing the TDB corruptions, as reported in the samba log > > files. At first there didn't seem to be an consequence, but we are now > > beginning to see user's not being able to login to the machine. As a > > workaround we have been just deleting the secrets.tdb file, restarting > > samba, and rejoining the domain. > > > > Our server if very similar to Martin's (Samba 2.2.3a + Linux 2.4.17 + XFS). > > I'll post more details soon. > > Can you try using the tdbbackup utility periodically > to determine when the corruption may be occurring ? I let the tdbbackup run for a few days now. The TDB corruption seems to happen at the time, when Amanda (a great backup tool) starts to run. I have moved the Amanda start time back and forth and the corruption starts within 10 minutes after starting Amanda. I don't think it's Amanda's fault, I assume that Amanda puts a heavy load on the filesystem layer during the first minutes, when it does its estimates. A reminder: all partitions on this system are XFS partititions, including /var, where Samba stores the TDB files. I could try to reformat the /var filesystem with ext2 to see if this has any influence. But this will probably need a server reboot, so I cannot do this before the weekend. Martin From owner-linux-xfs@oss.sgi.com Tue Mar 19 00:25:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J8PHP21142 for linux-xfs-outgoing; Tue, 19 Mar 2002 00:25:17 -0800 Received: from chkbak.localdomain ([213.53.199.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2J8P4921114 for ; Tue, 19 Mar 2002 00:25:04 -0800 Received: (qmail 19334 invoked from network); 19 Mar 2002 08:28:09 -0000 Received: from unknown (HELO aplabwp0368359) (192.168.0.59) by 192.168.0.254 with SMTP; 19 Mar 2002 08:28:09 -0000 Message-ID: <006701c1cf1f$f23a08f0$3b00a8c0@aplabwp0368359> From: "Bas" To: References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <3C96162B.FEBA6ABA@ch.sauter-bc.com> Subject: Re: files in /etc/xinetd.d become 0 byte size Date: Tue, 19 Mar 2002 09:27:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > > > Hi all, > > > > I'm setting up a new server, basically it's RedHat 7.2 XFS with all > > updates from RedHat applied. Kernel is 2.4.9-31SGI_XFS_1.0.2. I have two > > IDE disks with software RAID1 partitions for /, /boot, /home. Nothing > > special. > > > > The problem I have is that after some installation and configuration > > work, some xinetd config files in /etc/xinetd.d became 0 byte size. IIRC > > I saw the same thing some time ago with another machine but I really > > don't understand what's going on. BTW, I didn't have a crash or unclean > > shutdown. > > > > [root@gw-linux-dev xinetd.d]# ll /etc/xinetd.d > > total 44 > > -rw-r--r-- 1 root root 295 Mar 18 15:53 chargen > > -rw-r--r-- 1 root root 315 Mar 18 15:53 chargen-udp > > -rw-r--r-- 1 root root 295 Mar 18 15:53 daytime > > -rw-r--r-- 1 root root 315 Mar 18 15:53 daytime-udp > > -rw-r--r-- 1 root root 287 Mar 18 15:53 echo > > -rw-r--r-- 1 root root 306 Mar 18 15:53 echo-udp > > -rw-r--r-- 1 root root 317 Mar 18 15:53 finger > > -rw-r--r-- 1 root root 491 Mar 18 15:53 jftpgw-inet > > -rw-r--r-- 1 root root 257 Mar 18 15:53 ntalk > > -rw-r--r-- 1 root root 0 Mar 18 15:53 rexec > > -rw-r--r-- 1 root root 0 Mar 18 15:53 rlogin > > -rw-r--r-- 1 root root 0 Mar 18 15:53 rsh > > -rw-r--r-- 1 root root 0 Mar 18 15:53 rsync > > -rw-r--r-- 1 root root 0 Mar 18 15:53 talk > > -rw-r--r-- 1 root root 0 Mar 18 15:53 telnet > > -rw-r--r-- 1 root root 0 Mar 18 15:53 time > > -rw-r--r-- 1 root root 0 Mar 18 15:53 time-udp > > -rw-r--r-- 1 root root 0 Mar 18 15:53 wu-ftpd > > > > I have then restored the empty files from another installation. > > Everything seemed okay. I have then rebooted and now it's getting more > > interesting. > > > > [root@gw-linux-dev xinetd.d]# ll > > total 36 > > -rw-r--r-- 1 root root 295 Mar 18 15:59 chargen > > -rw-r--r-- 1 root root 315 Mar 18 15:59 chargen-udp > > -rw-r--r-- 1 root root 295 Mar 18 15:59 daytime > > -rw-r--r-- 1 root root 315 Mar 18 15:59 daytime-udp > > -rw-r--r-- 1 root root 287 Mar 18 15:59 echo > > -rw-r--r-- 1 root root 306 Mar 18 15:59 echo-udp > > -rw-r--r-- 1 root root 317 Mar 18 15:59 finger > > -rw-r--r-- 1 root root 491 Mar 18 15:59 jftpgw-inet > > -rw-r--r-- 1 root root 257 Mar 18 15:59 ntalk > > -rw-r--r-- 1 root root 359 Mar 18 15:59 rexec > > -rw-r--r-- 1 root root 376 Mar 18 15:59 rlogin > > -rw-r--r-- 1 root root 428 Mar 18 15:59 rsh > > -rw-r--r-- 1 root root 317 Mar 18 15:59 rsync > > -rw-r--r-- 1 root root 245 Mar 18 15:59 talk > > -rw-r--r-- 1 root root 303 Mar 18 15:59 telnet > > -rw-r--r-- 1 root root 319 Mar 18 15:59 time > > -rw-r--r-- 1 root root 315 Mar 18 15:59 time-udp > > -rw-r--r-- 1 root root 361 Mar 18 15:59 wu-ftpd > > > > It looks okay, but then I tried this: > > [root@gw-linux-dev xinetd.d]# cat rsh > > [root@gw-linux-dev xinetd.d]# > > > > Further investigation shows that the same files that were missing before > > are now filled with zero. After restarting xinetd, I guess they will be > > 0 bytes in size. > > > > I have searched RedHat bugzilla but didn't find anything useful. > > What comes to mind is the problem with zero filled bytes after a crash > > but I didnt' have any crash or unclean shutdowns. It seems to be > > something similar anyway. > > > > Is it possible that xinetd performs an operation on the files which > > leaves them not cleanly flushed to disk when shutting down? > > > > Thanks for any help! > > > > -Simon > > I reproduced it now: > Using ntsysv to manage services -> reboot: Files in /etc/xinetd.d have > normal size but filled with zero. Using ntsysv again truncates them to > zero size. Maybe write cache on the disks is enabled for some reason. > That could explain why changes are not commited to disk. I don't > understand it anyway because on reboot, the cache should be flushed to > disk, doesn't it? The hole thing lets me feel quite bad because I'm > wondering what else has been lost. > > Can anybody confirm similar problems? > > -Simon Yep, something similar here. It happened to me in 2.4.17 (and before). If I use vi to edit a file and reboot the machine shortly after (without properly shutting down), the files are filled with nothing but it seems to have it's normal size. Thanks, Bas. From owner-linux-xfs@oss.sgi.com Tue Mar 19 00:29:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J8TO221343 for linux-xfs-outgoing; Tue, 19 Mar 2002 00:29:24 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2J8TJ921316 for ; Tue, 19 Mar 2002 00:29:20 -0800 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2J8UjEV063372; Tue, 19 Mar 2002 09:30:45 +0100 (CET) Message-Id: <4.3.2.7.2.20020319092738.039ad0b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Mar 2002 09:28:09 +0100 To: "Bas" , From: Seth Mos Subject: Re: files in /etc/xinetd.d become 0 byte size In-Reply-To: <006701c1cf1f$f23a08f0$3b00a8c0@aplabwp0368359> References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <3C96162B.FEBA6ABA@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 09:27 19-3-2002 +0100, Bas wrote: >Yep, something similar here. It happened to me in 2.4.17 (and before). >If I use vi to edit a file and reboot the machine shortly after (without >properly shutting down), >the files are filled with nothing but it seems to have it's normal size. This should be fixed in 2.4.18 CVS or the split patches. 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 Tue Mar 19 00:49:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2J8nrn21715 for linux-xfs-outgoing; Tue, 19 Mar 2002 00:49:53 -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 g2J8nc921687 for ; Tue, 19 Mar 2002 00:49:38 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx11)) with ESMTP id 290ADC226; Tue, 19 Mar 2002 09:51:01 +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 JAA03712; Tue, 19 Mar 2002 09:51:00 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id C74E057306; Tue, 19 Mar 2002 09:49:20 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 78D2325835; Tue, 19 Mar 2002 09:49:20 +0100 (CET) Message-ID: <3C96FB90.9E29DC9E@ch.sauter-bc.com> Date: Tue, 19 Mar 2002 09:49:20 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Bas Cc: linux-xfs@oss.sgi.com Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <3C96162B.FEBA6ABA@ch.sauter-bc.com> <006701c1cf1f$f23a08f0$3b00a8c0@aplabwp0368359> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bas schrieb: > > > > > > > Hi all, > > > > > > I'm setting up a new server, basically it's RedHat 7.2 XFS with all > > > updates from RedHat applied. Kernel is 2.4.9-31SGI_XFS_1.0.2. I have two > > > IDE disks with software RAID1 partitions for /, /boot, /home. Nothing > > > special. > > > > > > The problem I have is that after some installation and configuration > > > work, some xinetd config files in /etc/xinetd.d became 0 byte size. IIRC > > > I saw the same thing some time ago with another machine but I really > > > don't understand what's going on. BTW, I didn't have a crash or unclean > > > shutdown. > > > > > > [root@gw-linux-dev xinetd.d]# ll /etc/xinetd.d > > > total 44 > > > -rw-r--r-- 1 root root 295 Mar 18 15:53 chargen > > > -rw-r--r-- 1 root root 315 Mar 18 15:53 chargen-udp > > > -rw-r--r-- 1 root root 295 Mar 18 15:53 daytime > > > -rw-r--r-- 1 root root 315 Mar 18 15:53 daytime-udp > > > -rw-r--r-- 1 root root 287 Mar 18 15:53 echo > > > -rw-r--r-- 1 root root 306 Mar 18 15:53 echo-udp > > > -rw-r--r-- 1 root root 317 Mar 18 15:53 finger > > > -rw-r--r-- 1 root root 491 Mar 18 15:53 jftpgw-inet > > > -rw-r--r-- 1 root root 257 Mar 18 15:53 ntalk > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 rexec > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 rlogin > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 rsh > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 rsync > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 talk > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 telnet > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 time > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 time-udp > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 wu-ftpd > > > > > > I have then restored the empty files from another installation. > > > Everything seemed okay. I have then rebooted and now it's getting more > > > interesting. > > > > > > [root@gw-linux-dev xinetd.d]# ll > > > total 36 > > > -rw-r--r-- 1 root root 295 Mar 18 15:59 chargen > > > -rw-r--r-- 1 root root 315 Mar 18 15:59 chargen-udp > > > -rw-r--r-- 1 root root 295 Mar 18 15:59 daytime > > > -rw-r--r-- 1 root root 315 Mar 18 15:59 daytime-udp > > > -rw-r--r-- 1 root root 287 Mar 18 15:59 echo > > > -rw-r--r-- 1 root root 306 Mar 18 15:59 echo-udp > > > -rw-r--r-- 1 root root 317 Mar 18 15:59 finger > > > -rw-r--r-- 1 root root 491 Mar 18 15:59 jftpgw-inet > > > -rw-r--r-- 1 root root 257 Mar 18 15:59 ntalk > > > -rw-r--r-- 1 root root 359 Mar 18 15:59 rexec > > > -rw-r--r-- 1 root root 376 Mar 18 15:59 rlogin > > > -rw-r--r-- 1 root root 428 Mar 18 15:59 rsh > > > -rw-r--r-- 1 root root 317 Mar 18 15:59 rsync > > > -rw-r--r-- 1 root root 245 Mar 18 15:59 talk > > > -rw-r--r-- 1 root root 303 Mar 18 15:59 telnet > > > -rw-r--r-- 1 root root 319 Mar 18 15:59 time > > > -rw-r--r-- 1 root root 315 Mar 18 15:59 time-udp > > > -rw-r--r-- 1 root root 361 Mar 18 15:59 wu-ftpd > > > > > > It looks okay, but then I tried this: > > > [root@gw-linux-dev xinetd.d]# cat rsh > > > [root@gw-linux-dev xinetd.d]# > > > > > > Further investigation shows that the same files that were missing before > > > are now filled with zero. After restarting xinetd, I guess they will be > > > 0 bytes in size. > > > > > > I have searched RedHat bugzilla but didn't find anything useful. > > > What comes to mind is the problem with zero filled bytes after a crash > > > but I didnt' have any crash or unclean shutdowns. It seems to be > > > something similar anyway. > > > > > > Is it possible that xinetd performs an operation on the files which > > > leaves them not cleanly flushed to disk when shutting down? > > > > > > Thanks for any help! > > > > > > -Simon > > > > I reproduced it now: > > Using ntsysv to manage services -> reboot: Files in /etc/xinetd.d have > > normal size but filled with zero. Using ntsysv again truncates them to > > zero size. Maybe write cache on the disks is enabled for some reason. > > That could explain why changes are not commited to disk. I don't > > understand it anyway because on reboot, the cache should be flushed to > > disk, doesn't it? The hole thing lets me feel quite bad because I'm > > wondering what else has been lost. > > > > Can anybody confirm similar problems? > > > > -Simon > > Yep, something similar here. It happened to me in 2.4.17 (and before). > If I use vi to edit a file and reboot the machine shortly after (without > properly shutting down), > the files are filled with nothing but it seems to have it's normal size. Okay, that's absolutely normal with XFS if you don't properly shutting down. My point is that I do properly shutdown and I get zeroed files anyway! -Simon > > Thanks, > Bas. From owner-linux-xfs@oss.sgi.com Tue Mar 19 02:41:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JAfOv23637 for linux-xfs-outgoing; Tue, 19 Mar 2002 02:41:24 -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 g2JAfI923611 for ; Tue, 19 Mar 2002 02:41:18 -0800 Received: (qmail 22820 invoked from network); 19 Mar 2002 10:42:43 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 19 Mar 2002 10:42:43 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 6A69D3000BA; Tue, 19 Mar 2002 21:42:39 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 0AAAF94; Tue, 19 Mar 2002 21:42:38 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Martin Apel Cc: Jeremy Allison , "ZINKEVICIUS,MATT (HP-Loveland, ex1)" , samba-technical@lists.samba.org, linux-xfs@oss.sgi.com Subject: Re: TDB corruption with Samba 2.2.3a In-reply-to: Your message of "Tue, 19 Mar 2002 08:03:22 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Mar 2002 21:42:33 +1100 Message-ID: <23314.1016534553@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 19 Mar 2002 08:03:22 +0100, Martin Apel wrote: >On Wed, 13 Mar 2002, Jeremy Allison wrote: > >> On Wed, Mar 13, 2002 at 05:25:13AM -0500, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: >> > We are also experiencing the TDB corruptions, as reported in the samba log >> > files. At first there didn't seem to be an consequence, but we are now >> > beginning to see user's not being able to login to the machine. As a >> > workaround we have been just deleting the secrets.tdb file, restarting >> > samba, and rejoining the domain. >> > >> > Our server if very similar to Martin's (Samba 2.2.3a + Linux 2.4.17 + XFS). >> > I'll post more details soon. There was a bug in XFS mmap handling in 2.4.17 with these symptoms. mmapped files would be fine until there was heavy load or the machine shut down, then blocks would be corrupt. http://marc.theaimsgroup.com/?l=linux-xfs&w=2&r=1&s=ftruncate+mmap&q=b Steve Lord fixed it (or at least my test case no longer tripped the problem) on approx January 28, 2002. The patch which fixed my test is http://marc.theaimsgroup.com/?l=linux-xfs&m=101223695324406&w=2 From owner-linux-xfs@oss.sgi.com Tue Mar 19 03:36:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JBa9O26393 for linux-xfs-outgoing; Tue, 19 Mar 2002 03:36: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 g2JBZk926366 for ; Tue, 19 Mar 2002 03:35:46 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx08)) with ESMTP id 2B2BB618C; Tue, 19 Mar 2002 12:37: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 MAA18772; Tue, 19 Mar 2002 12:37:08 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id A17E457306; Tue, 19 Mar 2002 12:36: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 92DF725835; Tue, 19 Mar 2002 12:36:58 +0100 (CET) Message-ID: <3C9722DA.9463DB6C@ch.sauter-bc.com> Date: Tue, 19 Mar 2002 12:36:58 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <3C96162B.FEBA6ABA@ch.sauter-bc.com> <1016479523.1442.1.camel@stout.americas.sgi.com> <3C964F7B.38C3C921@ch.sauter-bc.com> <1016484305.2197.3.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: > > I don't know for sure how IDE write caching works, to tell you the > truth. Try making sure it's off, and we'll go from there. How can I disable write caching on the Quantum AS20.5 disks? I've tried to find a program on www.maxtor.com but couldn't find anything. The only thing I found is that on Apple and Windows systems they have the same problems and it was fixed via driver modification. I tried to find a way to disable write cache via hdparm but didn't find anything. It's not directly a XFS problem but it seems to only happend on XFS. Maybe software raid1 (md) has something to do with but I don't think so. I just can't make this system work as expected... -Simon > > Hm, maybe looking at the ntsysv source would be good too. When I have > time... :) > > -Eric > > On Mon, 2002-03-18 at 14:35, Simon Matter wrote: > > Eric Sandeen schrieb: > > > > > > hi Simon - > > > > > > What happens if you just > > > > > > echo "test" > /etc/testfile > > > > Hi Eric, > > > > I've tried this with no problem at all. I even modified the xinetd > > script > > and included the statement in the stop function because this gets > > executed > > short before system halt/reboot. The result was still okay. > > > > > > > > or something like that, and reboot - just to take ntsysv out of the > > > picture. > > > > Now, how can ntsysv trigger empty files? I don't really understand that. > > > > > > > > I tried ntsysv on an xfs-root system, rebooted, and had no problems. I > > > wonder if my reboot is slow enough that a normal data flush happens > > > after the write. > > > > I have posted to bugzilla.redhat.com but it seems that the problem > > exists only > > with XFS. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=61356 > > > > Believe me, it's not the first time I have this problem but it's the > > first time I really care about it. I don't remember with what kind of > > hardware I already had this. > > > > Now I'm thinking whether the disks could be the culprits. They are two > > Quantum AS20.5 and they have quite big caches. If write cache is > > enabled, could it be that this cache is not flushed to disk on reboot. I > > will check whether cache is enabled but since I'm at home now, I guess I > > have to do it tomorrow when I have physical access. > > However, why are only certain files getting zeroed, I mean not all files > > in /etc/xinetd.d are zeroed? And if it's a cache flushing problem, how > > comes that for example the raid is stopped cleanly and other data still > > in the drive cache is not flushed? Can the OS tell the drive which data > > has to be flushed and which not? > > > > I'll modify the halt script now to ensure drive cache is synced and > > flushed on reboot. I guess using hdparm -f should be the right thing? > > > > -Simon > > > > > > > > -Eric > > > > > > On Mon, 2002-03-18 at 10:30, Simon Matter wrote: > > > > Simon Matter schrieb: > > > > > > > > > > Hi all, > > > > > > > > > > I'm setting up a new server, basically it's RedHat 7.2 XFS with all > > > > > updates from RedHat applied. Kernel is 2.4.9-31SGI_XFS_1.0.2. I have two > > > > > IDE disks with software RAID1 partitions for /, /boot, /home. Nothing > > > > > special. > > > > > > > > > > The problem I have is that after some installation and configuration > > > > > work, some xinetd config files in /etc/xinetd.d became 0 byte size. IIRC > > > > > I saw the same thing some time ago with another machine but I really > > > > > don't understand what's going on. BTW, I didn't have a crash or unclean > > > > > shutdown. > > > > > > > > > > [root@gw-linux-dev xinetd.d]# ll /etc/xinetd.d > > > > > total 44 > > > > > -rw-r--r-- 1 root root 295 Mar 18 15:53 chargen > > > > > -rw-r--r-- 1 root root 315 Mar 18 15:53 chargen-udp > > > > > -rw-r--r-- 1 root root 295 Mar 18 15:53 daytime > > > > > -rw-r--r-- 1 root root 315 Mar 18 15:53 daytime-udp > > > > > -rw-r--r-- 1 root root 287 Mar 18 15:53 echo > > > > > -rw-r--r-- 1 root root 306 Mar 18 15:53 echo-udp > > > > > -rw-r--r-- 1 root root 317 Mar 18 15:53 finger > > > > > -rw-r--r-- 1 root root 491 Mar 18 15:53 jftpgw-inet > > > > > -rw-r--r-- 1 root root 257 Mar 18 15:53 ntalk > > > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 rexec > > > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 rlogin > > > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 rsh > > > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 rsync > > > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 talk > > > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 telnet > > > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 time > > > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 time-udp > > > > > -rw-r--r-- 1 root root 0 Mar 18 15:53 wu-ftpd > > > > > > > > > > I have then restored the empty files from another installation. > > > > > Everything seemed okay. I have then rebooted and now it's getting more > > > > > interesting. > > > > > > > > > > [root@gw-linux-dev xinetd.d]# ll > > > > > total 36 > > > > > -rw-r--r-- 1 root root 295 Mar 18 15:59 chargen > > > > > -rw-r--r-- 1 root root 315 Mar 18 15:59 chargen-udp > > > > > -rw-r--r-- 1 root root 295 Mar 18 15:59 daytime > > > > > -rw-r--r-- 1 root root 315 Mar 18 15:59 daytime-udp > > > > > -rw-r--r-- 1 root root 287 Mar 18 15:59 echo > > > > > -rw-r--r-- 1 root root 306 Mar 18 15:59 echo-udp > > > > > -rw-r--r-- 1 root root 317 Mar 18 15:59 finger > > > > > -rw-r--r-- 1 root root 491 Mar 18 15:59 jftpgw-inet > > > > > -rw-r--r-- 1 root root 257 Mar 18 15:59 ntalk > > > > > -rw-r--r-- 1 root root 359 Mar 18 15:59 rexec > > > > > -rw-r--r-- 1 root root 376 Mar 18 15:59 rlogin > > > > > -rw-r--r-- 1 root root 428 Mar 18 15:59 rsh > > > > > -rw-r--r-- 1 root root 317 Mar 18 15:59 rsync > > > > > -rw-r--r-- 1 root root 245 Mar 18 15:59 talk > > > > > -rw-r--r-- 1 root root 303 Mar 18 15:59 telnet > > > > > -rw-r--r-- 1 root root 319 Mar 18 15:59 time > > > > > -rw-r--r-- 1 root root 315 Mar 18 15:59 time-udp > > > > > -rw-r--r-- 1 root root 361 Mar 18 15:59 wu-ftpd > > > > > > > > > > It looks okay, but then I tried this: > > > > > [root@gw-linux-dev xinetd.d]# cat rsh > > > > > [root@gw-linux-dev xinetd.d]# > > > > > > > > > > Further investigation shows that the same files that were missing before > > > > > are now filled with zero. After restarting xinetd, I guess they will be > > > > > 0 bytes in size. > > > > > > > > > > I have searched RedHat bugzilla but didn't find anything useful. > > > > > What comes to mind is the problem with zero filled bytes after a crash > > > > > but I didnt' have any crash or unclean shutdowns. It seems to be > > > > > something similar anyway. > > > > > > > > > > Is it possible that xinetd performs an operation on the files which > > > > > leaves them not cleanly flushed to disk when shutting down? > > > > > > > > > > Thanks for any help! > > > > > > > > > > -Simon > > > > > > > > I reproduced it now: > > > > Using ntsysv to manage services -> reboot: Files in /etc/xinetd.d have > > > > normal size but filled with zero. Using ntsysv again truncates them to > > > > zero size. Maybe write cache on the disks is enabled for some reason. > > > > That could explain why changes are not commited to disk. I don't > > > > understand it anyway because on reboot, the cache should be flushed to > > > > disk, doesn't it? The hole thing lets me feel quite bad because I'm > > > > wondering what else has been lost. > > > > > > > > Can anybody confirm similar problems? > > > > > > > > -Simon > > > > > > > -- > > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > > sandeen@sgi.com SGI, Inc. > > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] From owner-linux-xfs@oss.sgi.com Tue Mar 19 04:16:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JCGBU27303 for linux-xfs-outgoing; Tue, 19 Mar 2002 04:16:11 -0800 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JCFu927277 for ; Tue, 19 Mar 2002 04:15:56 -0800 Received: from koschikode.com (pktomo.altus.de [192.168.0.62]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 0237AF4D8; Tue, 19 Mar 2002 13:17:19 +0100 (CET) Message-ID: <3C972C4C.8000901@koschikode.com> Date: Tue, 19 Mar 2002 13:17:16 +0100 From: Juri Haberland 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: Simon Matter Cc: Eric Sandeen , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <3C96162B.FEBA6ABA@ch.sauter-bc.com> <1016479523.1442.1.camel@stout.americas.sgi.com> <3C964F7B.38C3C921@ch.sauter-bc.com> <1016484305.2197.3.camel@stout.americas.sgi.com> <3C9722DA.9463DB6C@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > Eric Sandeen schrieb: >> >> I don't know for sure how IDE write caching works, to tell you the >> truth. Try making sure it's off, and we'll go from there. > > How can I disable write caching on the Quantum AS20.5 disks? I've tried > to find a program on www.maxtor.com but couldn't find anything. The only > thing I found is that on Apple and Windows systems they have the same > problems and it was fixed via driver modification. I tried to find a way > to disable write cache via hdparm but didn't find anything. Maybe hdparm -W0 /dev/hdX Cheers, Juri -- If each of us have one object, and we exchange them, then each of us still has one object. If each of us have one idea, and we exchange them, then each of us now has two ideas. From owner-linux-xfs@oss.sgi.com Tue Mar 19 04:30:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JCU2t27632 for linux-xfs-outgoing; Tue, 19 Mar 2002 04:30:02 -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 g2JCTs927603 for ; Tue, 19 Mar 2002 04:29:56 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx08)) with ESMTP id 00071628B; Tue, 19 Mar 2002 13:31: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 NAA23177; Tue, 19 Mar 2002 13:31:08 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 2682A57306; Tue, 19 Mar 2002 13:30:51 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id DF83825835; Tue, 19 Mar 2002 13:30:50 +0100 (CET) Message-ID: <3C972F7A.245FFD37@ch.sauter-bc.com> Date: Tue, 19 Mar 2002 13:30:50 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Juri Haberland Cc: Eric Sandeen , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <3C96162B.FEBA6ABA@ch.sauter-bc.com> <1016479523.1442.1.camel@stout.americas.sgi.com> <3C964F7B.38C3C921@ch.sauter-bc.com> <1016484305.2197.3.camel@stout.americas.sgi.com> <3C9722DA.9463DB6C@ch.sauter-bc.com> <3C972C4C.8000901@koschikode.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juri Haberland schrieb: > > Simon Matter wrote: > > Eric Sandeen schrieb: > >> > >> I don't know for sure how IDE write caching works, to tell you the > >> truth. Try making sure it's off, and we'll go from there. > > > > How can I disable write caching on the Quantum AS20.5 disks? I've tried > > to find a program on www.maxtor.com but couldn't find anything. The only > > thing I found is that on Apple and Windows systems they have the same > > problems and it was fixed via driver modification. I tried to find a way > > to disable write cache via hdparm but didn't find anything. > > Maybe hdparm -W0 /dev/hdX Thanks! I knew it was there but I couldn't find it last night... I found another tool to permanently make feature settings. It's from IBM but it seems to work for other drives too: http://www.storage.ibm.com/hdd/support/download.htm#FeatureTool I'll make some tests now and report what comes out. -Simon > > Cheers, > Juri > > -- > If each of us have one object, and we exchange them, > then each of us still has one object. > If each of us have one idea, and we exchange them, > then each of us now has two ideas. From owner-linux-xfs@oss.sgi.com Tue Mar 19 04:50:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JCoAb27898 for linux-xfs-outgoing; Tue, 19 Mar 2002 04:50:10 -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 g2JCo4927869 for ; Tue, 19 Mar 2002 04:50:04 -0800 Received: from starfleet.attglobal.net (slip-32-100-182-11.wi.us.prserv.net[32.100.182.11]) by prserv.net (out2) with ESMTP id <200203191251302020559ieke>; Tue, 19 Mar 2002 12:51:31 +0000 Received: (from skylar@localhost) by starfleet.attglobal.net (8.11.6/8.11.6) id g2JC68B03225 for linux-xfs@oss.sgi.com; Tue, 19 Mar 2002 06:06:08 -0600 Date: Tue, 19 Mar 2002 06:06:08 -0600 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: Re: xfs and delete of small files Message-ID: <20020319120608.GB3200@starfleet.attglobal.net> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com References: <1016517764.1492.2.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hQiwHBbRI9kgIhsi" Content-Disposition: inline In-Reply-To: <1016517764.1492.2.camel@zeus.city.tvnet.hu> User-Agent: Mutt/1.3.28i 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.28i (2002-03-13) 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 --hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 19, 2002 at 07:02:44AM +0100, Sipos Ferenc wrote: > Hi! >=20 > When will the slow delete problem be fixed in xfs? Yesterday, I deleted > 16000 emails in evolution, and it took more than 20 minutes. It's not a > slow machine, (athlon 500 with 256 megs of ram), so it's clearly the > problem of xfs. Thx. XFS really isn't the best-suited when it comes to lots of small files. ReiserFS is known for extremely high performance in situations like this. XFS, OTOH, excels with huge files. --=20 -- Skylar Thompson (skylar@attglobal.net) --hQiwHBbRI9kgIhsi 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 iD8DBQE8lymwnMU1m27tfjARAhRdAKCR+kWWUtKUWpIAcc18KJmygRCPZQCdGtgJ nEOD2tPkXuAqnQlU6Qgoz9g= =q8hc -----END PGP SIGNATURE----- --hQiwHBbRI9kgIhsi-- From owner-linux-xfs@oss.sgi.com Tue Mar 19 05:02:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JD2wE28198 for linux-xfs-outgoing; Tue, 19 Mar 2002 05:02:58 -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 g2JD2s928172 for ; Tue, 19 Mar 2002 05:02:55 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 2E53D1EB03; Tue, 19 Mar 2002 14:04:18 +0100 (MET) Date: Tue, 19 Mar 2002 14:04:17 +0100 From: Andi Kleen To: Sipos Ferenc Cc: linux-xfs@oss.sgi.com Subject: Re: xfs and delete of small files Message-ID: <20020319140417.A17014@wotan.suse.de> References: <1016517764.1492.2.camel@zeus.city.tvnet.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1016517764.1492.2.camel@zeus.city.tvnet.hu> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Mar 19, 2002 at 07:02:44AM +0100, Sipos Ferenc wrote: > Hi! > > When will the slow delete problem be fixed in xfs? Yesterday, I deleted > 16000 emails in evolution, and it took more than 20 minutes. It's not a > slow machine, (athlon 500 with 256 megs of ram), so it's clearly the > problem of xfs. Thx. Latest 2.4 CVS should delete somewhat faster. -Andi From owner-linux-xfs@oss.sgi.com Tue Mar 19 05:43:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JDhPQ28675 for linux-xfs-outgoing; Tue, 19 Mar 2002 05:43:25 -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 g2JDhH928649 for ; Tue, 19 Mar 2002 05:43:17 -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 g2JEifBA010536 for ; Tue, 19 Mar 2002 06:44:41 -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 HAA31128; Tue, 19 Mar 2002 07:43:25 -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 HAA19637; Tue, 19 Mar 2002 07:43:24 -0600 (CST) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id HAA18639; Tue, 19 Mar 2002 07:43:24 -0600 (CST) Message-Id: <200203191343.HAA18639@fsgi158.americas.sgi.com> Subject: Re: Distributed File Systems. Which is best? To: lord@sgi.com (Stephen Lord) Date: Tue, 19 Mar 2002 07:43:23 -0600 (CST) Cc: jasonw@ariel.ucs.unimelb.edu.au, linux-xfs@oss.sgi.com In-Reply-To: <3C96AEDC.1030801@sgi.com> from "Stephen Lord" at Mar 18, 2002 09:22:04 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 > > Jason White wrote: > > >pac@fortuitous.com writes: > > > > > > > > > > Why not consider > > > > > c. OpenAFS (http://www.openafs.org/) which I have never used, but > > > > > apparently it works (or at least used to work/has been rumored to > > > > > work) with XFS as the underlying file system on the AFS partitions. > > > > > > I'll consider it. But that still leaves us where we started. > > > Has anyone Used any of these, and why are there so many projects > > > working independently of each other, and which is the most reliable? > > > >AFS has a strong reputation for reliability, and it is > >also the oldest of the systems mentioned, having been used widely in > >university and corporate settings for years. However I am not > >acquainted with its reliability or performance under XFS. > > > >As to why there are so many projects in this area, I suspect a number > >of reasons, including different design goals, some projects being > >newer than others (the desire for a "fresh start" with a different > >approach to the design), etc. > > > If you dig back in the xfs list archives, you should find some references to > open AFS. Someone, I cannot remember who, got it all working and made > patches available. AFS does have XFS support built in, but it is Irix XFS > support getting linux XFS going required some work. > >From the archive: Date: Fri, 28 Sep 2001 15:58:12 +0100 (BST) From: "P.Dixon" To: Subject: AFS RPMS for 2.4.5-SGI_XFS_1.0.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: OR Hi, I've put my openafs RPMs here: http://hepwww.ph.qmw.ac.uk/~pd/rpms/ Cheerio, Paul ----------------------------------------------------------------------------- Paul Dixon Email: P.Dixon@qmw.ac.uk Department of Physics Phone: (020) 7882 5054 Queen Mary, University of London Fax : (020) 7882 5054 Mile End Road, London E1 4NS URL : http://hepwww.ph.qmw.ac.uk/~pd ----------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Mar 19 06:34:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JEYkn29785 for linux-xfs-outgoing; Tue, 19 Mar 2002 06:34:46 -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 g2JEYe929759 for ; Tue, 19 Mar 2002 06:34:40 -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 g2JFiBkw024023 for ; Tue, 19 Mar 2002 09:44:11 -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 IAA23416; Tue, 19 Mar 2002 08:34:47 -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 IAA43327; Tue, 19 Mar 2002 08:34:47 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2JEWff01837; Tue, 19 Mar 2002 08:32:41 -0600 Subject: Re: xfs and delete of small files From: Steve Lord To: Sipos Ferenc Cc: linux-xfs@oss.sgi.com In-Reply-To: <1016517764.1492.2.camel@zeus.city.tvnet.hu> References: <1016517764.1492.2.camel@zeus.city.tvnet.hu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Mar 2002 08:32:41 -0600 Message-Id: <1016548361.1770.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 00:02, Sipos Ferenc wrote: > Hi! > > When will the slow delete problem be fixed in xfs? Yesterday, I deleted > 16000 emails in evolution, and it took more than 20 minutes. It's not a > slow machine, (athlon 500 with 256 megs of ram), so it's clearly the > problem of xfs. Thx. > > Paco > You don't say which kernel you are running - things should be better in the current cvs tree. And please do not assume that all the over head of deleting email in evolution is the filesystem underneath it! I realize you do not have the mail anymore, but I think you will find evolution did a lot of its own running around to delete that email. Get a current cvs tree, and mount your filesystem with -o logbufs=4 this will help. 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 19 06:40:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JEeU829972 for linux-xfs-outgoing; Tue, 19 Mar 2002 06:40:30 -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 g2JEeQ929946 for ; Tue, 19 Mar 2002 06:40:26 -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 g2JFnwkw024086 for ; Tue, 19 Mar 2002 09:49:58 -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 IAA30516; Tue, 19 Mar 2002 08:40: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 IAA57989; Tue, 19 Mar 2002 08:40:34 -0600 (CST) Date: Tue, 19 Mar 2002 08:40:34 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Simon Matter cc: linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size In-Reply-To: <3C9722DA.9463DB6C@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 Tue, 19 Mar 2002, Simon Matter wrote: > Eric Sandeen schrieb: > > > > I don't know for sure how IDE write caching works, to tell you the > > truth. Try making sure it's off, and we'll go from there. > > How can I disable write caching on the Quantum AS20.5 disks? I've tried hdparm -W -W Disable/enable the IDE drive's write-caching feature (usually OFF by default). -Eric From owner-linux-xfs@oss.sgi.com Tue Mar 19 07:28:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JFSmN30984 for linux-xfs-outgoing; Tue, 19 Mar 2002 07:28:48 -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 g2JFSb930950 for ; Tue, 19 Mar 2002 07:28:38 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx03)) with ESMTP id A648E619E; Tue, 19 Mar 2002 16:29:59 +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 QAA10008; Tue, 19 Mar 2002 16:29:58 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 5CF9857306; Tue, 19 Mar 2002 16:28:27 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 2817525835; Tue, 19 Mar 2002 16:28:27 +0100 (CET) Message-ID: <3C97591B.FF456D25@ch.sauter-bc.com> Date: Tue, 19 Mar 2002 16:28:27 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen schrieb: > > On Tue, 19 Mar 2002, Simon Matter wrote: > > > Eric Sandeen schrieb: > > > > > > I don't know for sure how IDE write caching works, to tell you the > > > truth. Try making sure it's off, and we'll go from there. > > > > How can I disable write caching on the Quantum AS20.5 disks? I've tried > > hdparm -W > > -W Disable/enable the IDE drive's write-caching feature (usually OFF > by default). I have disabled the write cache directly on the disk with IBM's feature tool. The bad thing is that after a reboot, write cache is enabled again which means that this drive doesn't store caching config permanently! So I have put EXTRA_PARAMS=-W0 into /etc/sysconfig/harddisks and rebooted. syslog confirms that: [root@gw-linux-dev xinetd.d]# grep hdparm /var/log/messages Mar 19 16:14:30 gw-linux-dev hdparm: /dev/hda: Mar 19 16:14:30 gw-linux-dev hdparm: setting drive write-caching to 0 (off) Mar 19 16:14:30 gw-linux-dev hdparm: /dev/hdb: Mar 19 16:14:30 gw-linux-dev hdparm: setting drive write-caching to 0 (off) So I should be safe. Tried a bonnie and the result shows that cache IS off. Tried [root@gw-linux-dev xinetd.d]# ntsysv ; reboot and got zeroed files in /etc/xinetd.d/ again!!! What can I do now? -Simon From owner-linux-xfs@oss.sgi.com Tue Mar 19 07:47:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JFl2E31345 for linux-xfs-outgoing; Tue, 19 Mar 2002 07:47:02 -0800 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JFkj931313 for ; Tue, 19 Mar 2002 07:46:46 -0800 Received: from koschikode.com (pktomo.altus.de [192.168.0.62]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 6BEE7F4D8; Tue, 19 Mar 2002 16:48:09 +0100 (CET) Message-ID: <3C975DB7.4010201@koschikode.com> Date: Tue, 19 Mar 2002 16:48:07 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Matter Cc: Eric Sandeen , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C97591B.FF456D25@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > > So I should be safe. Tried a bonnie and the result shows that cache IS > off. > > Tried > > [root@gw-linux-dev xinetd.d]# ntsysv ; reboot > > and got zeroed files in /etc/xinetd.d/ again!!! > > What can I do now? Did you upgrade from RH7.1 to 7.2? Did you alter the /etc/init.d/halt script? Do you have a part in it that looks like this: # Remount read only anything that's left mounted. #echo $"Remounting remaining filesystems (if any) readonly" mount | awk '/( \/ |^\/dev\/root)/ { print $3 }' | while read line; do mount -n -o ro,remount $line done Juri -- If each of us have one object, and we exchange them, then each of us still has one object. If each of us have one idea, and we exchange them, then each of us now has two ideas. From owner-linux-xfs@oss.sgi.com Tue Mar 19 08:01:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JG14631736 for linux-xfs-outgoing; Tue, 19 Mar 2002 08:01:04 -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 g2JG0p931705 for ; Tue, 19 Mar 2002 08:00:52 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx02)) with ESMTP id B6223622E; Tue, 19 Mar 2002 17:02: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 RAA12888; Tue, 19 Mar 2002 17:02:11 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 0463457306; Tue, 19 Mar 2002 17:01:47 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id EB2AA25835; Tue, 19 Mar 2002 17:01:46 +0100 (CET) Message-ID: <3C9760EA.3874D744@ch.sauter-bc.com> Date: Tue, 19 Mar 2002 17:01:46 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Juri Haberland Cc: Eric Sandeen , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C97591B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juri Haberland schrieb: > > Simon Matter wrote: > > > > > So I should be safe. Tried a bonnie and the result shows that cache IS > > off. > > > > Tried > > > > [root@gw-linux-dev xinetd.d]# ntsysv ; reboot > > > > and got zeroed files in /etc/xinetd.d/ again!!! > > > > What can I do now? > > Did you upgrade from RH7.1 to 7.2? > Did you alter the /etc/init.d/halt script? > Do you have a part in it that looks like this: > > # Remount read only anything that's left mounted. > #echo $"Remounting remaining filesystems (if any) readonly" > mount | awk '/( \/ |^\/dev\/root)/ { print $3 }' | while read line; do > mount -n -o ro,remount $line > done This is a fresh install of 7.2 XFS. I have the mentioned lines in /etc/rc.d/init.d/halt. I think that something in the shutdown process is not okay. I remember the bdflush discussion and the vim story. So I think the remount readonly trick does not make shure data is flushed to disk. I enabled write cache again because it doesn't help and tried this [root@gw-linux-dev xinetd.d]# ntsysv ; sleep 40 ; reboot No zeroed files ! I did 40 second sleep because bdflush should flush metadata after 5 seconds, data after 30 seconds. If it is what I think, how can we force the flushing on shutdown? Calling sync seems not to help. Do I miss something here. It is also to mention that I have the root FS on MD raid1. Thanks for any help! -Simon From owner-linux-xfs@oss.sgi.com Tue Mar 19 08:07:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JG7Xu31919 for linux-xfs-outgoing; Tue, 19 Mar 2002 08:07:33 -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 g2JG7O931886 for ; Tue, 19 Mar 2002 08:07:24 -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 g2JHGukw025540 for ; Tue, 19 Mar 2002 11:16:56 -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 KAA33482; Tue, 19 Mar 2002 10:07:32 -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 KAA65939; Tue, 19 Mar 2002 10:07:31 -0600 (CST) Subject: Re: files in /etc/xinetd.d become 0 byte size From: Eric Sandeen To: Simon Matter Cc: Juri Haberland , linux-xfs In-Reply-To: <3C9760EA.3874D744@ch.sauter-bc.com> References: <3C97591B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> <3C9760EA.3874D744@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Mar 2002 10:07:31 -0600 Message-Id: <1016554052.4383.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 10:01, Simon Matter wrote: > This is a fresh install of 7.2 XFS. I have the mentioned lines in > /etc/rc.d/init.d/halt. > > I think that something in the shutdown process is not okay. I remember > the bdflush discussion and the vim story. So I think the remount > readonly trick does not make shure data is flushed to disk. > I enabled write cache again because it doesn't help and tried this > > [root@gw-linux-dev xinetd.d]# ntsysv ; sleep 40 ; reboot > > No zeroed files ! Odd. You said that echoing something into a file just before shutdown did not exhibit this problem. Was the target file also on the root filesystem? It might also be worth temporarily trying a more recent kernel, just in case we're chasing an old bug. Otherwise, I wonder if remount,ro is not behaving correctly in this case. -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 19 08:44:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JGi1P32399 for linux-xfs-outgoing; Tue, 19 Mar 2002 08:44:01 -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 g2JGhj932373 for ; Tue, 19 Mar 2002 08:43:46 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx13)) with ESMTP id 576C1C275; Tue, 19 Mar 2002 17:45: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 RAA16342; Tue, 19 Mar 2002 17:45:08 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id B599C57306; Tue, 19 Mar 2002 17:44:13 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 5501D25835; Tue, 19 Mar 2002 17:44:13 +0100 (CET) Message-ID: <3C976ADD.FE0E7CDA@ch.sauter-bc.com> Date: Tue, 19 Mar 2002 17:44:13 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: Juri Haberland , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C97591B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> <3C9760EA.3874D744@ch.sauter-bc.com> <1016554052.4383.4.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 Tue, 2002-03-19 at 10:01, Simon Matter wrote: > > > This is a fresh install of 7.2 XFS. I have the mentioned lines in > > /etc/rc.d/init.d/halt. > > > > I think that something in the shutdown process is not okay. I remember > > the bdflush discussion and the vim story. So I think the remount > > readonly trick does not make shure data is flushed to disk. > > I enabled write cache again because it doesn't help and tried this > > > > [root@gw-linux-dev xinetd.d]# ntsysv ; sleep 40 ; reboot > > > > No zeroed files ! > > Odd. > > You said that echoing something into a file just before shutdown did not > exhibit this problem. Was the target file also on the root filesystem? > It was on the same partition. I also used to copy the files from /root/xinetd.d/ to /etc/xinetd.d and just rebooted after and no zeros. But I can reproduce it now very easily. ntsysv (en/disabling rsh) ; reboot : gives zeroed files ntsysv (en/disabling rsh) ; sleep 40 ; reboot : is okay. I'm sure ntsysv does something 'interesting' here but from my understanding it should not be possible to damage the FS in such way. It seems to me that somehow bdflush does not update the changes ntsysv did. Is there a way to ensure bdflush does it's job immediately? sync seems not to do it in this case but what else? My question is how does the proper shutdown process look like? What we have is - kill all processes by SIGTERM - kill all processes by SIGKILL - turn off swap, accounting and quota - unmounting all filesystems - remount anything left readonly Now, my stupid question: ntsysv changes depend on bdflush to get written to disk. Does bdflush survive killall? BTW: I've just found my .bash_history file zeroed. > It might also be worth temporarily trying a more recent kernel, just in > case we're chasing an old bug. Will also try this. > > Otherwise, I wonder if remount,ro is not behaving correctly in this > case. > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] From owner-linux-xfs@oss.sgi.com Tue Mar 19 08:51:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JGpv932645 for linux-xfs-outgoing; Tue, 19 Mar 2002 08:51: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 g2JGpq932604 for ; Tue, 19 Mar 2002 08:51:53 -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 g2JGrF6G020139 for ; Tue, 19 Mar 2002 08:53:16 -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 KAA31646; Tue, 19 Mar 2002 10:51:59 -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 KAA76508; Tue, 19 Mar 2002 10:51:59 -0600 (CST) Subject: Re: files in /etc/xinetd.d become 0 byte size From: Eric Sandeen To: Simon Matter Cc: Juri Haberland , linux-xfs In-Reply-To: <3C976ADD.FE0E7CDA@ch.sauter-bc.com> References: <3C97591B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> <3C9760EA.3874D744@ch.sauter-bc.com> <1016554052.4383.4.camel@stout.americas.sgi.com> <3C976ADD.FE0E7CDA@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Mar 2002 10:51:59 -0600 Message-Id: <1016556719.4476.8.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 10:44, Simon Matter wrote: > BTW: I've just found my .bash_history file zeroed. Root's .bash_history? on the root FS? Then it looks like it's not ntsysv that's doing anything special, and more like a remount,ro problem. Let me know how a newer kernel fares... -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 19 09:15:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JHFuc00767 for linux-xfs-outgoing; Tue, 19 Mar 2002 09:15: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 g2JHFn900728 for ; Tue, 19 Mar 2002 09:15: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 g2JHHB6G021205 for ; Tue, 19 Mar 2002 09:17:12 -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 LAA34067; Tue, 19 Mar 2002 11:15: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 LAA49895; Tue, 19 Mar 2002 11:15:55 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2JHDmS05019; Tue, 19 Mar 2002 11:13:48 -0600 Subject: Re: files in /etc/xinetd.d become 0 byte size From: Steve Lord To: Simon Matter Cc: Eric Sandeen , Juri Haberland , linux-xfs In-Reply-To: <3C976ADD.FE0E7CDA@ch.sauter-bc.com> References: <3C97591B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> <3C9760EA.3874D744@ch.sauter-bc.com> <1016554052.4383.4.camel@stout.americas.sgi.com> <3C976ADD.FE0E7CDA@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Mar 2002 11:13:48 -0600 Message-Id: <1016558028.1770.31.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 10:44, Simon Matter wrote: n > > It was on the same partition. I also used to copy the files from > /root/xinetd.d/ to /etc/xinetd.d and just rebooted after and no zeros. > But I can reproduce it now very easily. > > ntsysv (en/disabling rsh) ; reboot : gives zeroed files > ntsysv (en/disabling rsh) ; sleep 40 ; reboot : is okay. > > I'm sure ntsysv does something 'interesting' here but from my > understanding it should not be possible to damage the FS in such way. It > seems to me that somehow bdflush does not update the changes ntsysv did. > ntsysv does a synchronous transaction in the kernel you have - which in itself is not a problem. What appears to be happening is that the remount readonly is not doing its job, or log recovery is for some reason thinking the filesystem was not cleanly unmounted - which might (just might) have something to do with the raid1 root partition. So, can you see if you are getting a message about running recovery during bootup: XFS mounting filesystem sd(8,1) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: sd(8,1) (dev: 8/1) Ending XFS recovery on filesystem: sd(8,1) (dev: 8/1) This should not happen after a clean shutdown. If this is happening, then is it possible to bring a system up on a different root, or in some other way run xfs_logprint -t on the filesystem before it is mounted again? 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 19 09:23:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JHNot01143 for linux-xfs-outgoing; Tue, 19 Mar 2002 09:23:50 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JHNi901115 for ; Tue, 19 Mar 2002 09:23:44 -0800 Received: (qmail 13516 invoked by uid 500); 19 Mar 2002 17:24:37 -0000 Subject: Re: Distributed File Systems. Which is best? From: Austin Gonyou To: jasonw@ariel.ucs.unimelb.edu.au Cc: linux-xfs@oss.sgi.com In-Reply-To: <15510.43696.738518.773137@jdc.local> References: <15510.43696.738518.773137@jdc.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 19 Mar 2002 11:24:37 -0600 Message-Id: <1016558677.13219.13.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk To answer your question it seems that no one has used these, or very much. I would ask the lists for each FS though. I know GFS works with XFS. I know AFS has been used with XFS systems, and I know that PolyServe has as well. On Mon, 2002-03-18 at 21:04, Jason White wrote: > pac@fortuitous.com writes: > > > > > > > > Why not consider > > > > c. OpenAFS (http://www.openafs.org/) which I have never used, but > > > > apparently it works (or at least used to work/has been rumored to > > > > work) with XFS as the underlying file system on the AFS > partitions. > > > > I'll consider it. But that still leaves us where we started. > > Has anyone Used any of these, and why are there so many projects > > working independently of each other, and which is the most reliable? > > AFS has a strong reputation for reliability, and it is > also the oldest of the systems mentioned, having been used widely in > university and corporate settings for years. However I am not > acquainted with its reliability or performance under XFS. > > As to why there are so many projects in this area, I suspect a number > of reasons, including different design goals, some projects being > newer than others (the desire for a "fresh start" with a different > approach to the design), etc. -- 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 19 09:25:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JHPSq01312 for linux-xfs-outgoing; Tue, 19 Mar 2002 09:25: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 g2JHPP901285 for ; Tue, 19 Mar 2002 09:25:25 -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 g2JHQl6G021676 for ; Tue, 19 Mar 2002 09:26:48 -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 LAA34554 for ; Tue, 19 Mar 2002 11:25: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 LAA04007 for ; Tue, 19 Mar 2002 11:25:12 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2JHN5O05197; Tue, 19 Mar 2002 11:23:05 -0600 Message-Id: <200203191723.g2JHN5O05197@jen.americas.sgi.com> Date: Tue, 19 Mar 2002 11:23:05 -0600 Subject: TAKE - reduce xfs log memory usage To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Some reorganization of the memory allocation for the xfs log buffers. This has two affects, it stops us from using a 64K chunk of memory for the 32K buffer - we now use 32K chunks. The other is to make the log writes start on page boundaries which will help raid5 - and everyone else probably. Date: Tue Mar 19 09:22:53 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-andrea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:114421a linux/fs/xfs/xfs_log.c - 1.244 linux/fs/xfs/xfs_log_priv.h - 1.80 - Break iclog memory into two chunks to make log writes page aligned and to save memory. From owner-linux-xfs@oss.sgi.com Tue Mar 19 09:33:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JHX0v01599 for linux-xfs-outgoing; Tue, 19 Mar 2002 09:33:00 -0800 Received: from tigger.cc-concepts.com (64-40-83-10.mb.dsl.mebtel.net [64.40.83.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JHWt901573 for ; Tue, 19 Mar 2002 09:32:55 -0800 Received: from msbnetworks.net (dhcp-152-3-194-43.egr.duke.edu [152.3.194.43]) (authenticated) by tigger.cc-concepts.com (8.11.6/8.11.6) with ESMTP id g2JHYNw19514 for ; Tue, 19 Mar 2002 12:34:23 -0500 Message-ID: <3C97769F.6050507@msbnetworks.net> Date: Tue, 19 Mar 2002 12:34:23 -0500 From: Mike Baptiste Organization: MSB Networks User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs Subject: Compile problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am bringing a new mail server up with XFS partitions. Not my first - my others run nicely. However, I've hit a problem compiling a newer kernel (its currently running the 2.4.9 kernel from the XFS RedHat installer). I've got RH 7.2 with all the latest RedHat rpm updates installed. I've downloaded both 2.4.17 and 2.4.18 with the xfs-all patches applied. Nothing else. I'm using the stock .config from the 2.4.9-XFS source. During the compile with 2.91.66, I get this error: gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ -I/usr/src/linux-2.4.18-XFS/include -traditional -c trampoline.S -o trampoline.o /tmp/ccE8u6Ji.s: Assembler messages: /tmp/ccE8u6Ji.s:2614: Error: suffix or operands invalid for 'ljmp' make[1]: *** [trampoline.o] Error 1 This happens with 2.4.17 and 2.4.18 The current gcc installed is gcc-2.96-98 though I'm using 2.91.66 mode. I'm going to try mormal 2.96 compile next (though that makes me nervous :) ) and I'm trying to track down a kgcc rpm to try though I wonder if it'll make any difference. Any ideas? I've compiled 2.4.17 on 7.1 (2.91-66) with no problems, though not with the latest gcc rpm form Redhat if memory serves. Mike From owner-linux-xfs@oss.sgi.com Tue Mar 19 09:35:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JHZ0d01739 for linux-xfs-outgoing; Tue, 19 Mar 2002 09:35:00 -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 g2JHYv901712 for ; Tue, 19 Mar 2002 09:34:57 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 8755A1EB3F; Tue, 19 Mar 2002 18:36:20 +0100 (MET) Date: Tue, 19 Mar 2002 18:36:20 +0100 From: Andi Kleen To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - reduce xfs log memory usage Message-ID: <20020319183620.A27373@oldwotan.suse.de> References: <200203191723.g2JHN5O05197@jen.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: <200203191723.g2JHN5O05197@jen.americas.sgi.com>; from lord@sgi.com on Tue, Mar 19, 2002 at 11:23:05AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hallo Steve, On Tue, Mar 19, 2002 at 11:23:05AM -0600, Steve Lord wrote: > Some reorganization of the memory allocation for the xfs log > buffers. This has two affects, it stops us from using a 64K > chunk of memory for the 32K buffer - we now use 32K chunks. > The other is to make the log writes start on page boundaries > which will help raid5 - and everyone else probably. Does that imply that a higher logbufs= value is recommended now, or does XFS need more changes to keep more log in memory ? Thanks, -Andi From owner-linux-xfs@oss.sgi.com Tue Mar 19 09:40:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JHejF01926 for linux-xfs-outgoing; Tue, 19 Mar 2002 09:40: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 g2JHed901900 for ; Tue, 19 Mar 2002 09:40: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 g2JHg26G022576 for ; Tue, 19 Mar 2002 09:42:03 -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 LAA32658; Tue, 19 Mar 2002 11:40:46 -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 LAA43467; Tue, 19 Mar 2002 11:40:45 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2JHccR06623; Tue, 19 Mar 2002 11:38:38 -0600 Subject: Re: TAKE - reduce xfs log memory usage From: Steve Lord To: Andi Kleen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020319183620.A27373@oldwotan.suse.de> References: <200203191723.g2JHN5O05197@jen.americas.sgi.com> <20020319183620.A27373@oldwotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Mar 2002 11:38:38 -0600 Message-Id: <1016559518.1841.36.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 11:36, Andi Kleen wrote: > Hallo Steve, > > On Tue, Mar 19, 2002 at 11:23:05AM -0600, Steve Lord wrote: > > Some reorganization of the memory allocation for the xfs log > > buffers. This has two affects, it stops us from using a 64K > > chunk of memory for the 32K buffer - we now use 32K chunks. > > The other is to make the log writes start on page boundaries > > which will help raid5 - and everyone else probably. > > Does that imply that a higher logbufs= value is recommended now, or > does XFS need more changes to keep more log in memory ? No, this was just a couple of inefficiencies, the in core log buffers consisted of a control structure (512 bytes) and 32K of data, all allocated in one chunk. End result was we chewed up 64K for each, and all log writes started 512 bytes into a page. The latter was one of the causes of raid5 cache thrashing, but there is more to do on that problem. Steve p.s. Andi you should look into the next checkin - it might fix stuff for you. > > Thanks, > -Andi -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 19 09:42:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JHg1A02059 for linux-xfs-outgoing; Tue, 19 Mar 2002 09:42: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 g2JHfs902033 for ; Tue, 19 Mar 2002 09:41:54 -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 g2JHhG6G022660 for ; Tue, 19 Mar 2002 09:43:17 -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 LAA34094 for ; Tue, 19 Mar 2002 11:42:01 -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 LAA39166 for ; Tue, 19 Mar 2002 11:42:01 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2JHdsS06631; Tue, 19 Mar 2002 11:39:54 -0600 Message-Id: <200203191739.g2JHdsS06631@jen.americas.sgi.com> Date: Tue, 19 Mar 2002 11:39:54 -0600 Subject: TAKE - xfs delayed allocate fixups and bug fixes To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In response to comments from Andrea Archangeli and Andrew Morton, and a bug report from Andrew Tridgell (is that enough Andrews in one sentence!), this is a major cleanup of the handling of delayed allocate pages in xfs and its interactions with the mainline kernel. XFS now has a releasepage method - this replaces a bunch of code in fs/buffer.c which it turns out could never really have worked. The code in fs/buffer.c has been simplified, and changed to protect against spinning on the cpu - which some people had reported as bflushd spinning on the cpu. It also fixes a corruption problem which Andrew Tridgell reported under very heavy write pressure, and a deadlock under very heavy mmap write pressure. This appears to be very hard to hit if that is any consolation, I think this bug has been around since early January. Steve Date: Tue Mar 19 09:30:43 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-andrea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:114422a linux/fs/buffer.c - 1.103 - Revamp the delayed allocate handling, there is less of it now and problems with bdflush spinning should go away. linux/drivers/block/ll_rw_blk.c - 1.81 - Move the trap for delayed allocate buffer heads from the ll_rw_block code to submit_bh. This traps all of them rather than just some of them. linux/fs/xfs/linux/xfs_iops.c - 1.128 - Add a releasepage method to xfs. linux/fs/xfs/pagebuf/page_buf_io.c - 1.17 - Add a release_page method, this converts delalloc pages to real so that try_to_free_buffers can function on them. Revamp pagebuf_write_full_page, it now does not unlock the page, that happens in I/O completion. linux/fs/xfs/pagebuf/page_buf.h - 1.8 - definition for pagebuf_release_page From owner-linux-xfs@oss.sgi.com Tue Mar 19 09:42:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JHgsa02192 for linux-xfs-outgoing; Tue, 19 Mar 2002 09:42:54 -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 g2JHgh902165 for ; Tue, 19 Mar 2002 09:42:43 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx13)) with ESMTP id 6918CC2E9; Tue, 19 Mar 2002 18:44:06 +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 SAA20492; Tue, 19 Mar 2002 18:44:05 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 37E0957306; Tue, 19 Mar 2002 18:43:32 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 2E44B25835; Tue, 19 Mar 2002 18:43:32 +0100 (CET) Message-ID: <3C9778C4.42F25505@ch.sauter-bc.com> Date: Tue, 19 Mar 2002 18:43:32 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Steve Lord Cc: Eric Sandeen , Juri Haberland , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C97591B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> <3C9760EA.3874D744@ch.sauter-bc.com> <1016554052.4383.4.camel@stout.americas.sgi.com> <3C976ADD.FE0E7CDA@ch.sauter-bc.com> <1016558028.1770.31.camel@jen.americas.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord schrieb: > > On Tue, 2002-03-19 at 10:44, Simon Matter wrote: > n > > > > It was on the same partition. I also used to copy the files from > > /root/xinetd.d/ to /etc/xinetd.d and just rebooted after and no zeros. > > But I can reproduce it now very easily. > > > > ntsysv (en/disabling rsh) ; reboot : gives zeroed files > > ntsysv (en/disabling rsh) ; sleep 40 ; reboot : is okay. > > > > I'm sure ntsysv does something 'interesting' here but from my > > understanding it should not be possible to damage the FS in such way. It > > seems to me that somehow bdflush does not update the changes ntsysv did. > > > > ntsysv does a synchronous transaction in the kernel you have - which in > itself is not a problem. What appears to be happening is that the > remount readonly is not doing its job, or log recovery is for some > reason thinking the filesystem was not cleanly unmounted - which > might (just might) have something to do with the raid1 root partition. I know it's not only ntsysv because I found /root/.bash_history filled with zeros. > > So, can you see if you are getting a message about running recovery > during bootup: > > XFS mounting filesystem sd(8,1) > XFS: WARNING: recovery required on readonly filesystem. > XFS: write access will be enabled during mount. > Starting XFS recovery on filesystem: sd(8,1) (dev: 8/1) > Ending XFS recovery on filesystem: sd(8,1) (dev: 8/1) There was not a single log recovery as far as messages goes back. So the filesystem was shutdown properly (metadata) but data was not written? I modified /etc/rc.d/init.d/halt in the section before killall like this # Try to sync sync sync sync sync sync and got no zeroed files! My next idea was using xfs_freeze because the man page says Using the -f option, the filesystem is locked out from new modifications, write system calls are halted on entry, other calls which modify the filesystem are halted at the start of a transaction, all ongoing transactions in the filesystem are allowed to complete. I removed the sync's and tried this just before the remount readonly: runcmd $"Freezing root file systems: " xfs_freeze -f / runcmd $"Unfreezing root file systems: " xfs_freeze -u / But this was a bad idea because it has frozen the kernel :-) Now I'm thinking about the sync. I tried with just one sync with no success. I remember that with HP/UX and Solaris we were always used to issue sync several times. IIRC I read somewhere that we don't have to do this on linux but in my case it seems to help. Does it make sense to put something like this into the shutdown script # Syncing Filesystems sync ; sleep 1 ; sync ; sleep 1 ; sync ; sleep 1 ; sync > > This should not happen after a clean shutdown. If this is happening, > then is it possible to bring a system up on a different root, or in > some other way run xfs_logprint -t on the filesystem before it is > mounted again? Do you want me to run xfs_logprint -t even after a clean shutdown? -Simon From owner-linux-xfs@oss.sgi.com Tue Mar 19 09:47:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JHlnS02418 for linux-xfs-outgoing; Tue, 19 Mar 2002 09:47:49 -0800 Received: from tigger.cc-concepts.com (64-40-83-10.mb.dsl.mebtel.net [64.40.83.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JHlg902389 for ; Tue, 19 Mar 2002 09:47:43 -0800 Received: from msbnetworks.net (dhcp-152-3-194-43.egr.duke.edu [152.3.194.43]) (authenticated) by tigger.cc-concepts.com (8.11.6/8.11.6) with ESMTP id g2JHnAw19951 for ; Tue, 19 Mar 2002 12:49:10 -0500 Message-ID: <3C977A17.10808@msbnetworks.net> Date: Tue, 19 Mar 2002 12:49:11 -0500 From: Mike Baptiste Organization: MSB Networks User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs Subject: Re: Compile problem References: <3C97769F.6050507@msbnetworks.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As a followup, compiling in native gcc mode worked fine. Only in 2.91-66 mode does the compile fail. I'm nervous about going with a non 2.91 compiled kernel, but may give it a go and hit the server harder than I had planned before production. ANyone else have experience running a kernel compiled with 2.96-98? Mike Mike Baptiste wrote: > I am bringing a new mail server up with XFS partitions. Not my first - > my others run nicely. However, I've hit a problem compiling a newer > kernel (its currently running the 2.4.9 kernel from the XFS RedHat > installer). > > I've got RH 7.2 with all the latest RedHat rpm updates installed. > > I've downloaded both 2.4.17 and 2.4.18 with the xfs-all patches applied. > Nothing else. I'm using the stock .config from the 2.4.9-XFS source. > > During the compile with 2.91.66, I get this error: > > gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ > -I/usr/src/linux-2.4.18-XFS/include -traditional -c trampoline.S -o > trampoline.o > /tmp/ccE8u6Ji.s: Assembler messages: > /tmp/ccE8u6Ji.s:2614: Error: suffix or operands invalid for 'ljmp' > make[1]: *** [trampoline.o] Error 1 > > This happens with 2.4.17 and 2.4.18 > > The current gcc installed is gcc-2.96-98 though I'm using 2.91.66 mode. > > I'm going to try mormal 2.96 compile next (though that makes me nervous > :) ) and I'm trying to track down a kgcc rpm to try though I wonder if > it'll make any difference. > > Any ideas? I've compiled 2.4.17 on 7.1 (2.91-66) with no problems, > though not with the latest gcc rpm form Redhat if memory serves. > > Mike From owner-linux-xfs@oss.sgi.com Tue Mar 19 10:08:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JI85x02826 for linux-xfs-outgoing; Tue, 19 Mar 2002 10:08:05 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JI7r902799 for ; Tue, 19 Mar 2002 10:07:54 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-104.quicknet.nl [212.58.163.104]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2JI9Bvt065428; Tue, 19 Mar 2002 19:09:16 +0100 (CET) Message-Id: <4.3.2.7.2.20020319190440.0301dd98@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Mar 2002 19:06:33 +0100 To: Mike Baptiste , linux-xfs From: Seth Mos Subject: Re: Compile problem In-Reply-To: <3C977A17.10808@msbnetworks.net> References: <3C97769F.6050507@msbnetworks.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:49 19-3-2002 -0500, Mike Baptiste wrote: >As a followup, compiling in native gcc mode worked fine. Only in 2.91-66 >mode does the compile fail. > >I'm nervous about going with a non 2.91 compiled kernel, but may give it a >go and hit the server harder than I had planned before production. ANyone >else have experience running a kernel compiled with 2.96-98? It might very well be that since the linux-kernel standard is now 2.95.3 it will not compile with egcs 1.1.2 anymore. If you don't like the 2.96 you might also try the gcc-3.x packages from Red Hat Linux 7.2. I think that should work. 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 Tue Mar 19 10:11:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JIBe502993 for linux-xfs-outgoing; Tue, 19 Mar 2002 10:11:40 -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 g2JIBK902964 for ; Tue, 19 Mar 2002 10:11:20 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g2JI5td19476; Tue, 19 Mar 2002 12:05:55 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: opps on xfs on a linear raid on a sparc64 box 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: 19 Mar 2002 12:05:55 -0600 Message-Id: <1016561155.19159.0.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Now that I have xfs compiled and "working", I'm trying to test it on several diferent conditions. Today, I'd tried to use xfs on a linear raid, and it oops'ses. The scene, is a CVS XFS from about a week ago (just after the VFS quota patches got it) on an ultra1 running a linear raid[1] on 7 scsi disks. As usual, I create the raid device and then the filesystem on top of it. After the xfs-raid is mounted, I run an rsync to a local server with about #$"&"&" files and some 30G in order to do a basic test to it (as in, before the xfstests) and I get an oops. (I also tried it with a recursive ftp) After booting up the box, I try to mount the partition again, and I get another oops. The following trace, is from that oops. Do I need to send the other oops also?, If so, please state it. Would it help if I test it on other raid levels? Unable to handle kernel paging request at virtual address 0000000000002000 tsk->{mm,active_mm}->context = 0000000000000476 tsk->{mm,active_mm}->pgd = fffff80001683000 \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ mount(125): Oops TSTATE: 0000009911009603 TPC: 000000000052c848 TNPC: 000000000052c84c Y: 08000000 Not tainted Using defaults from ksymoops -t elf32-sparc -a sparc g0: fffff80001ec7120 g1: fffff8000122d0a0 g2: 0000000000000000 g3: 0000000000000000 g4: fffff80000000000 g5: 000000000000001b g6: fffff80000fa4000 g7: 0000000000000002 o0: 00000000006a5c00 o1: 0000000000000000 o2: fffff80011d92d20 o3: 0000000000000000 o4: 0000000000002000 o5: fffff80011d92040 sp: fffff80000fa5fe1 ret_pc: 000000000052c910 l0: 0000000000696800 l1: 0000000000000001 l2: 000000000253d500 l3: 0000000002600244 l4: 00000000005c13b0 l5: 0000000000677a38 l6: 0000000000673a48 l7: 0000000000000008 i0: 0000000000000000 i1: 0000000000002000 i2: 000000000000000c i3: 0000000000000060 i4: 00000000005afbf8 i5: 0000000000000000 i6: fffff80000fa60a1 i7: 00000000004fcc50 Caller[00000000004fcc50] Caller[00000000004fce0c] Caller[00000000004fd28c] Caller[00000000004fcefc] Caller[0000000000505174] Caller[00000000004e5e24] Caller[00000000004e6138] Caller[00000000004e6a54] Caller[00000000004e6350] Caller[00000000004e6650] Caller[00000000004e9554] Caller[00000000004e2bac] Caller[00000000004eab54] Caller[00000000004f2130] Caller[00000000004f22d4] Caller[00000000004f231c] Caller[00000000005061fc] Caller[0000000000465404] Caller[0000000000465a10] Caller[00000000004790f4] Caller[0000000000479548] Caller[00000000004274a8] Caller[0000000000410974] Caller[0000000000012610] Instruction DUMP: 01000000 9de3bf40 11001a97 90122320 d45e6068 9332e008 932a7003 80a2a000 >>PC; 0052c848 <===== >>O7; 0052c910 >>I7; 004fcc50 <_pagebuf_page_io+230/2e0> Trace; 004fcc50 <_pagebuf_page_io+230/2e0> Trace; 004fce0c <_page_buf_page_apply+10c/120> Trace; 004fd28c Trace; 004fcefc Trace; 00505174 Trace; 004e5e24 Trace; 004e6138 Trace; 004e6a54 Trace; 004e6350 Trace; 004e6650 Trace; 004e9554 Trace; 004e2bac Trace; 004eab54 Trace; 004f2130 Trace; 004f22d4 Trace; 004f231c Trace; 005061fc Trace; 00465404 Trace; 00465a10 Trace; 004790f4 Trace; 00479548 Trace; 004274a8 Trace; 00410974 Trace; 00012610 Before first symbol Code; 0052c83c <__make_request+75c/760> 0000000000000000 <_PC>: Code; 0052c83c <__make_request+75c/760> 0: 01 00 00 00 nop Code; 0052c840 4: 9d e3 bf 40 save %sp, -192, %sp Code; 0052c844 8: 11 00 1a 97 sethi %hi(0x6a5c00), %o0 Code; 0052c848 <===== c: d6 16 60 1c lduh [ %i1 + 0x1c ], %o3 <===== Code; 0052c84c 10: 90 12 23 20 or %o0, 0x320, %o0 Code; 0052c850 14: d4 5e 60 68 unknown Code; 0052c854 18: 93 32 e0 08 srl %o3, 8, %o1 Code; 0052c858 1c: 93 2a 70 03 unknown Code; 0052c85c 20: 80 a2 a0 00 cmp %o2, 0 [1] /etc/raidtab raiddev /dev/md1 raid-level linear nr-raid-disks 7 nr-spare-disks 0 persistent-superblock 1 chunk-size 32 device /dev/scsi/host1/bus0/target3/lun0/part1 raid-disk 0 device /dev/scsi/host1/bus0/target11/lun0/part1 raid-disk 1 device /dev/scsi/host1/bus0/target4/lun0/part1 raid-disk 2 device /dev/scsi/host1/bus0/target12/lun0/part1 raid-disk 3 device /dev/scsi/host1/bus0/target5/lun0/part1 raid-disk 4 device /dev/scsi/host1/bus0/target8/lun0/part1 raid-disk 5 device /dev/scsi/host1/bus0/target14/lun0/part1 raid-disk 6 -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Tue Mar 19 11:01:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JJ1xR03865 for linux-xfs-outgoing; Tue, 19 Mar 2002 11:01:59 -0800 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JJ1g903839 for ; Tue, 19 Mar 2002 11:01:42 -0800 Received: from warp9.koschikode.com (pD951787F.dip.t-dialin.net [217.81.120.127]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 9FE20F4D8; Tue, 19 Mar 2002 20:03:06 +0100 (CET) Received: from koschikode.com (kaplah.koschikode.com [192.168.200.15]) by warp9.koschikode.com (Postfix) with ESMTP id 5EF85A9; Tue, 19 Mar 2002 20:02:55 +0100 (CET) Message-ID: <3C978B5E.3040309@koschikode.com> Date: Tue, 19 Mar 2002 20:02:54 +0100 From: Juri Haberland Organization: totally unorganized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020305 X-Accept-Language: de-DE, en MIME-Version: 1.0 To: Steve Lord Cc: Simon Matter , Eric Sandeen , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C97591B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> <3C9760EA.3874D744@ch.sauter-bc.com> <1016554052.4383.4.camel@stout.americas.sgi.com> <3C976ADD.FE0E7CDA@ch.sauter-bc.com> <1016558028.1770.31.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > On Tue, 2002-03-19 at 10:44, Simon Matter wrote: > n >> >> It was on the same partition. I also used to copy the files from >> /root/xinetd.d/ to /etc/xinetd.d and just rebooted after and no zeros. >> But I can reproduce it now very easily. >> >> ntsysv (en/disabling rsh) ; reboot : gives zeroed files >> ntsysv (en/disabling rsh) ; sleep 40 ; reboot : is okay. >> >> I'm sure ntsysv does something 'interesting' here but from my >> understanding it should not be possible to damage the FS in such way. It >> seems to me that somehow bdflush does not update the changes ntsysv did. >> > > ntsysv does a synchronous transaction in the kernel you have - which in > itself is not a problem. What appears to be happening is that the > remount readonly is not doing its job, or log recovery is for some > reason thinking the filesystem was not cleanly unmounted - which > might (just might) have something to do with the raid1 root partition. Ok, when you mentioned the SW RAID1 root partition I remembered that I have a similar box sitting here. It's also a fresh SGI-RH7.2 installation with all updates and all partitions are on a SW-RAID1, but on SCSI disks, not on IDE disks. I ran three test like yours (ntsysv (en/disabling time ; reboot)) and afterwards I still had all files in /etc/xinetd.d with their proper contents. I also had my .bash_history. This box runs a 2.4.18-xfs-smp kernel from CVS, checked out on 4th of March. Simon what about a recent kernel? 2.4.9-31 is user contributed IIRC. It might not be a good choice... Juri From owner-linux-xfs@oss.sgi.com Tue Mar 19 11:18:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JJIst04293 for linux-xfs-outgoing; Tue, 19 Mar 2002 11:18:54 -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 g2JJIm904267 for ; Tue, 19 Mar 2002 11:18:48 -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 g2JKKCBA026793 for ; Tue, 19 Mar 2002 12:20:12 -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 NAA38098; Tue, 19 Mar 2002 13:18: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 NAA60327; Tue, 19 Mar 2002 13:18:56 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2JJGmQ12374; Tue, 19 Mar 2002 13:16:48 -0600 Subject: Re: files in /etc/xinetd.d become 0 byte size From: Steve Lord To: Juri Haberland Cc: Simon Matter , Eric Sandeen , linux-xfs In-Reply-To: <3C978B5E.3040309@koschikode.com> References: <3C97591 B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> <3C9760EA.3874D744@ch.sauter-bc.com> <1016554052.4383.4.camel@stout.america s.sgi.com> <3C976ADD.FE0E7CDA@ch.sauter-bc.com> <1016558028.1770.31.camel@jen.americas.sgi.com> <3C978B5E.3040309@koschikode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Mar 2002 13:16:48 -0600 Message-Id: <1016565408.1770.93.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 13:02, Juri Haberland wrote: > > Ok, when you mentioned the SW RAID1 root partition I remembered that I > have a similar box sitting here. It's also a fresh SGI-RH7.2 > installation with all updates and all partitions are on a SW-RAID1, but > on SCSI disks, not on IDE disks. > > I ran three test like yours (ntsysv (en/disabling time ; reboot)) and > afterwards I still had all files in /etc/xinetd.d with their proper > contents. I also had my .bash_history. > This box runs a 2.4.18-xfs-smp kernel from CVS, checked out on 4th of March. > > Simon > what about a recent kernel? 2.4.9-31 is user contributed IIRC. It might > not be a good choice... I agree with Juri on the try a recent kernel. And Simon, to answer your other question, if recovery is not reported as being run - then no need to look with xfs_logprint, the problem is the remount readonly code. Steve > > Juri -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 19 11:50:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JJoSb04936 for linux-xfs-outgoing; Tue, 19 Mar 2002 11:50: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 g2JJoK904910 for ; Tue, 19 Mar 2002 11:50: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 g2JJpi6G000549 for ; Tue, 19 Mar 2002 11:51:44 -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 NAA37501; Tue, 19 Mar 2002 13:50:27 -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 NAA46471; Tue, 19 Mar 2002 13:50:27 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2JJmJt22455; Tue, 19 Mar 2002 13:48:19 -0600 Subject: Re: TDB corruption with Samba 2.2.3a From: Steve Lord To: Martin Apel Cc: Jeremy Allison , "ZINKEVICIUS,MATT ""(HP-Loveland,ex1)" , samba-technical@lists.samba.org, linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Mar 2002 13:48:19 -0600 Message-Id: <1016567299.1770.128.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 01:03, Martin Apel wrote: > On Wed, 13 Mar 2002, Jeremy Allison wrote: > > > On Wed, Mar 13, 2002 at 05:25:13AM -0500, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > > > We are also experiencing the TDB corruptions, as reported in the samba log > > > files. At first there didn't seem to be an consequence, but we are now > > > beginning to see user's not being able to login to the machine. As a > > > workaround we have been just deleting the secrets.tdb file, restarting > > > samba, and rejoining the domain. > > > > > > Our server if very similar to Martin's (Samba 2.2.3a + Linux 2.4.17 + XFS). > > > I'll post more details soon. > > > > Can you try using the tdbbackup utility periodically > > to determine when the corruption may be occurring ? > > I let the tdbbackup run for a few days now. The TDB corruption seems to > happen at the time, when Amanda (a great backup tool) starts to run. > I have moved the Amanda start time back and forth and the corruption > starts within 10 minutes after starting Amanda. > I don't think it's Amanda's fault, I assume that Amanda puts a heavy load > on the filesystem layer during the first minutes, when it does its estimates. > A reminder: all partitions on this system are XFS partititions, including > /var, where Samba stores the TDB files. > I could try to reformat the /var filesystem with ext2 to see if this has > any influence. But this will probably need a server reboot, so I cannot > do this before the weekend. > > Martin Can you try a kernel from the 2.4 xfs cvs tree - I just pushed some changes out there which fix a corruption problem under heavy memory pressure. 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 19 11:56:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JJuqh05176 for linux-xfs-outgoing; Tue, 19 Mar 2002 11:56:52 -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 g2JJuj905150 for ; Tue, 19 Mar 2002 11:56:45 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx14)) with ESMTP id 70E3AC2D9; Tue, 19 Mar 2002 20:58: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 UAA01469; Tue, 19 Mar 2002 20:58:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 1074957306; Tue, 19 Mar 2002 20:57:46 +0100 (CET) Received: from ch.sauter-bc.com (ppp02.cad.sba [10.1.249.2]) by mobile.sauter-bc.com (Postfix) with ESMTP id 76E0325835; Tue, 19 Mar 2002 20:57:44 +0100 (CET) Message-ID: <3C979839.5378CCA1@ch.sauter-bc.com> Date: Tue, 19 Mar 2002 20:57:45 +0100 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i586) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord Cc: Juri Haberland , Eric Sandeen , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C97591 B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> <3C9760EA.3874D744@ch.sauter-bc.com> <1016554052.4383.4.camel@stout.america s.sgi.com> <3C976ADD.FE0E7CDA@ch.sauter-bc.com> <1016558028.1770.31.camel@jen.americas.sgi.com> <3C978B5E.3040309@koschikode.com> <1016565408.1770.93.camel@jen.americas.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord schrieb: > > On Tue, 2002-03-19 at 13:02, Juri Haberland wrote: > > > > Ok, when you mentioned the SW RAID1 root partition I remembered that I > > have a similar box sitting here. It's also a fresh SGI-RH7.2 > > installation with all updates and all partitions are on a SW-RAID1, but > > on SCSI disks, not on IDE disks. > > > > I ran three test like yours (ntsysv (en/disabling time ; reboot)) and > > afterwards I still had all files in /etc/xinetd.d with their proper > > contents. I also had my .bash_history. > > This box runs a 2.4.18-xfs-smp kernel from CVS, checked out on 4th of March. > > > > Simon > > what about a recent kernel? 2.4.9-31 is user contributed IIRC. It might > > not be a good choice... You want me to cry, not a good choice, I have contributed them :-) Serious, I'll try a newer kernel as soon as I can. Just to confirm the IDE thing: I've tried the same on my home server now which is SW-RAID1, but on SCSI disks, and it's the same problem. So nothing with IDE and nothing with write cache. What about sync? I'm still wondering whether it's good to have it in halt? With my modified halt script the problem seems to go away. -Simon > > I agree with Juri on the try a recent kernel. And Simon, to answer your > other question, if recovery is not reported as being run - then no need > to look with xfs_logprint, the problem is the remount readonly code. > > Steve > > > > > Juri > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 19 12:02:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JK2c705452 for linux-xfs-outgoing; Tue, 19 Mar 2002 12:02:38 -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 g2JK2V905426 for ; Tue, 19 Mar 2002 12:02: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 g2JLC4kw029212 for ; Tue, 19 Mar 2002 15:12:04 -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 OAA12979; Tue, 19 Mar 2002 14:02:40 -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 OAA60842; Tue, 19 Mar 2002 14:02:39 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2JK0V323504; Tue, 19 Mar 2002 14:00:31 -0600 Subject: Re: files in /etc/xinetd.d become 0 byte size From: Steve Lord To: Simon Matter Cc: Juri Haberland , Eric Sandeen , linux-xfs In-Reply-To: <3C979839.5378CCA1@ch.sauter-bc.com> References: <3C97591 B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> <3C9760EA.3874D744@ch.sauter-bc.com> <1016554052.4383.4.camel@stout.america s.sgi.com> <3C976ADD.FE0E7CDA@ch.sauter-bc.com> <1016558028.1770.31.camel@jen.americas.sgi.com> <3C978B5E.3040309@koschikode.com> <1016565408.1770.93.camel@jen.americas.sgi.com> <3C979839.5378CCA1@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Mar 2002 14:00:31 -0600 Message-Id: <1016568031.1841.132.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 13:57, Simon Matter wrote: > Steve Lord schrieb: > > > > On Tue, 2002-03-19 at 13:02, Juri Haberland wrote: > > > > > > Ok, when you mentioned the SW RAID1 root partition I remembered that I > > > have a similar box sitting here. It's also a fresh SGI-RH7.2 > > > installation with all updates and all partitions are on a SW-RAID1, but > > > on SCSI disks, not on IDE disks. > > > > > > I ran three test like yours (ntsysv (en/disabling time ; reboot)) and > > > afterwards I still had all files in /etc/xinetd.d with their proper > > > contents. I also had my .bash_history. > > > This box runs a 2.4.18-xfs-smp kernel from CVS, checked out on 4th of March. > > > > > > Simon > > > what about a recent kernel? 2.4.9-31 is user contributed IIRC. It might > > > not be a good choice... > > You want me to cry, not a good choice, I have contributed them :-) > Serious, I'll try a newer kernel as soon as I can. We are just trying to eliminate variables here - not blaming your merging skills. Juri appears to have a similar setup, except he does not see the problem with a recent kernel. Eric is slaving away over rpm build tools even as I type, attempting to push the latest xfs code into a redhat kernel. > > Just to confirm the IDE thing: I've tried the same on my home server now > which is SW-RAID1, but on SCSI disks, and it's the same problem. So > nothing with IDE and nothing with write cache. > > What about sync? I'm still wondering whether it's good to have it in > halt? With my modified halt script the problem seems to go away. Doing the sync in there is fine, does no harm at all. 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 19 13:13:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JLDTk06647 for linux-xfs-outgoing; Tue, 19 Mar 2002 13:13:29 -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 g2JLDB906621 for ; Tue, 19 Mar 2002 13:13:12 -0800 Received: from plum.sucs.soton.ac.uk (plum.sucs.soton.ac.uk [152.78.128.10]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g2JLEbH07366; Tue, 19 Mar 2002 21:14:37 GMT From: "Ian D. Hardy" Received: (from idh@localhost) by plum.sucs.soton.ac.uk (8.9.3/8.9.3) id VAA3765809; Tue, 19 Mar 2002 21:14:37 GMT Message-Id: <200203192114.VAA3765809@plum.sucs.soton.ac.uk> Subject: Re: XFS NFS server Oops To: lord@sgi.com (Steve Lord) Date: Tue, 19 Mar 2002 21:14:37 +0000 (GMT) Cc: idh@soton.ac.uk, linux-xfs@oss.sgi.com In-Reply-To: <1016122399.5683.3.camel@jen.americas.sgi.com> from "Steve Lord" at Mar 14, 2002 10:13:19 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve +, > > On Thu, 2002-03-14 at 10:11, Ian D. Hardy wrote: > > Steve +, > > > > Thanks for the patch (vnode.patch) and sorry for the delay, we've had a > > week or so of stability on this server so haven't had chance to install > > the patched kernel. > > > > However, managed to fit it into a regular maintenance period yesterday, > > though I soon ran into (what I believe was) the bug reported by Dave > > Alden and fixed by you/Eric Sandeen (thanks!) of NFS hangs > > (page_buf_io.c) (though it was not quite as reproducible as it seemed to > > be for Dave) - anyway updated to the latest CVS tree (as of ~ 12:00GMT > > 13th March) + the patch you sent me last week and so far so good! As > > I indicated before I have seen upto 14 days between crashes so its a > > bit early to tell if its fixed my problem but at least its run for > > >24hrs now without any noticeable bad effects. > > > > Regards and thanks. > > > > Ian Hardy > > > > > > Thanks for the update, and thanks for working past our other bugs! > > Steve > > -- Bad news I'm affraid I've just had what looks like another similar crash. XFS 2.4.18 CVS treee as of 13th March +Steve Lords vnode.patch - server had been up ~6 days 4hours (which is slightly longer than average but we have had ~ 14 days before). The ksymoops output is as follows: invalid operand: 0000 CPU: 1 EIP: 0010:[] Not tainted EFLAGS: 00010202 eax: 00000001 ebx: c16b3d80 ecx: c16b3d80 edx: 00000000 esi: 00000000 edi: 00000000 ebp: 00000000 esp: f6d61cb4 ds: 0018 es: 0018 ss: 0018 Process nfsinvalid operand: 0000 CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 00000001 ebx: c16b3d80 ecx: c16b3d80 edx: 00000000 esi: 00000000 edi: 00000000 ebp: 00000000 esp: f6d61cb4 ds: 0018 es: 0018 ss: 0018 d (pid: 607, stackpage=f6d61000) Stack: c16b3d80 00000000 00000000 e1e618e8 c01286a3 c16b3d80 c0128834 c16b3d80 c16b3d80 c01323e8 c0128a1c 00000000 f6d61d2c 00000000 e1e618e8 c16b3d80 efb57648 f6d60000 00000000 00000001 f6d61d2c 00000000 c0128acd 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 8b 43 18 a8 40 74 02 0f 0b 8b 43 18 a8 80 74 02 0f 0b Process nfsd (pid: 607, stackpage=f6d61000) Stack: c16b3d80 00000000 00000000 e1e618e8 c01286a3 c16b3d80 c0128834 c16b3d80 c16b3d80 c01323e8 c0128a1c 00000000 f6d61d2c 00000000 e1e618e8 c16b3d80 efb57648 f6d60000 00000000 00000001 f6d61d2c 00000000 c0128acd 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 8b 43 18 a8 40 74 02 0f 0b 8b 43 18 a8 80 74 02 0f 0b >>EIP; c0131d00 <__free_pages_ok+50/20c> <===== Trace; c01286a2 Trace; c0128834 Trace; c01323e8 <__free_pages+1c/20> Trace; c0128a1c Trace; c0128acc Trace; c01f1372 Trace; c01f3fec Trace; c01cf79a Trace; c01e6cec Trace; c01e6410 Trace; c026d014 Trace; c0265b06 Trace; c01f6a6e Trace; c01e6410 Trace; c014f4dc Trace; f8d2e972 <[nfsd]nfsd_setattr+3ea/524> Trace; f8d33f7a <[nfsd]nfsd3_proc_setattr+b6/c4> Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8d2b5d2 <[nfsd]nfsd_dispatch+d2/19a> Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8cf6f88 <[sunrpc]svc_process+28c/51c> Trace; f8d3b400 <[nfsd]nfsd_svcstats+0/40> Trace; f8d3aed8 <[nfsd]nfsd_version3+0/10> Trace; f8d2b348 <[nfsd]nfsd+1b8/370> Trace; c01057ea Code; c0131d00 <__free_pages_ok+50/20c> 00000000 <_EIP>: Code; c0131d00 <__free_pages_ok+50/20c> <===== 0: 0f 0b ud2a <===== Code; c0131d02 <__free_pages_ok+52/20c> 2: 8b 43 18 mov 0x18(%ebx),%eax Code; c0131d04 <__free_pages_ok+54/20c> 5: a8 40 test $0x40,%al Code; c0131d06 <__free_pages_ok+56/20c> 7: 74 02 je b <_EIP+0xb> c0131d0a <__free_pages_ok+5a/20c> Code; c0131d08 <__free_pages_ok+58/20c> 9: 0f 0b ud2a Code; c0131d0a <__free_pages_ok+5a/20c> b: 8b 43 18 mov 0x18(%ebx),%eax Code; c0131d0e <__free_pages_ok+5e/20c> e: a8 80 test $0x80,%al Code; c0131d10 <__free_pages_ok+60/20c> 10: 74 02 je 14 <_EIP+0x14> c0131d14 <__free_pages_ok+64/20c> Code; c0131d12 <__free_pages_ok+62/20c> 12: 0f 0b ud2a --- Hope the above provides some useful hints in debugging this. Regards and many thanks for looking at this. Ian Hardy -- //////////////////////////////////////////////////////////////////////////// Ian Hardy Research Services Computing Services email: idh@soton.ac.uk Southampton University i.d.hardy@soton.ac.uk Southampton S017 1BJ, UK. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ From owner-linux-xfs@oss.sgi.com Tue Mar 19 14:03:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JM3R807413 for linux-xfs-outgoing; Tue, 19 Mar 2002 14:03:27 -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 g2JM3K907387 for ; Tue, 19 Mar 2002 14:03: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 g2JM4i6G007672 for ; Tue, 19 Mar 2002 14:04:44 -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 QAA37406; Tue, 19 Mar 2002 16:03: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 QAA87798; Tue, 19 Mar 2002 16:03:26 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2JM1HD10240; Tue, 19 Mar 2002 16:01:17 -0600 Subject: Re: Compile problem From: Steve Lord To: Mike Baptiste Cc: linux-xfs In-Reply-To: <3C97769F.6050507@msbnetworks.net> References: <3C97769F.6050507@msbnetworks.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Mar 2002 16:01:17 -0600 Message-Id: <1016575277.28200.14.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 11:34, Mike Baptiste wrote: > I am bringing a new mail server up with XFS partitions. Not my first - > my others run nicely. However, I've hit a problem compiling a newer > kernel (its currently running the 2.4.9 kernel from the XFS RedHat > installer). > > I've got RH 7.2 with all the latest RedHat rpm updates installed. > > I've downloaded both 2.4.17 and 2.4.18 with the xfs-all patches applied. > Nothing else. I'm using the stock .config from the 2.4.9-XFS source. > > During the compile with 2.91.66, I get this error: > > gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ > -I/usr/src/linux-2.4.18-XFS/include -traditional -c trampoline.S -o > trampoline.o > /tmp/ccE8u6Ji.s: Assembler messages: > /tmp/ccE8u6Ji.s:2614: Error: suffix or operands invalid for 'ljmp' > make[1]: *** [trampoline.o] Error 1 > > This happens with 2.4.17 and 2.4.18 > > The current gcc installed is gcc-2.96-98 though I'm using 2.91.66 mode. > > I'm going to try mormal 2.96 compile next (though that makes me nervous > :) ) and I'm trying to track down a kgcc rpm to try though I wonder if > it'll make any difference. > > Any ideas? I've compiled 2.4.17 on 7.1 (2.91-66) with no problems, > though not with the latest gcc rpm form Redhat if memory serves. There used to be bugs in the redhat compiler which messed up some end cases in xfs. These are fixed in the latest rpms. I use gcc-2.96-101 to build my kernels. Steve > > Mike -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 19 14:07:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JM7Af07557 for linux-xfs-outgoing; Tue, 19 Mar 2002 14:07:10 -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 g2JM75907531 for ; Tue, 19 Mar 2002 14:07:06 -0800 Received: (qmail 30168 invoked from network); 19 Mar 2002 22:08:32 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 19 Mar 2002 22:08:32 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 6BD0F3000B8; Wed, 20 Mar 2002 09:08:25 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 2AE6494; Wed, 20 Mar 2002 09:08:25 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Mike Baptiste Cc: linux-xfs Subject: Re: Compile problem In-reply-to: Your message of "Tue, 19 Mar 2002 12:34:23 CDT." <3C97769F.6050507@msbnetworks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Mar 2002 09:08:17 +1100 Message-ID: <27245.1016575697@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 19 Mar 2002 12:34:23 -0500, Mike Baptiste wrote: >gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__ >-I/usr/src/linux-2.4.18-XFS/include -traditional -c trampoline.S -o >trampoline.o >/tmp/ccE8u6Ji.s: Assembler messages: >/tmp/ccE8u6Ji.s:2614: Error: suffix or operands invalid for 'ljmp' >make[1]: *** [trampoline.o] Error 1 Generic kernel problem, mismatch between gcc and as. Not XFS related. From owner-linux-xfs@oss.sgi.com Tue Mar 19 14:15:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JMFp507786 for linux-xfs-outgoing; Tue, 19 Mar 2002 14:15:51 -0800 Received: from msuex0.Campus.mnsu.edu (msuex0.campus.mnsu.edu [134.29.52.25]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JMFl907760 for ; Tue, 19 Mar 2002 14:15:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: --enable-shared=no gives linking errors Was: New tarball error Date: Tue, 19 Mar 2002 16:17:15 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: --enable-shared=no gives linking errors Was: New tarball error Thread-Index: AcHPkhaIiz8w5npdSUmvt+wLkI3bbQ== From: "Hundstad, Jeffrey E." To: , "Nathan Scott" , "Vincent Bernat" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2JMFl907761 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In http://marc.theaimsgroup.com/?l=linux-xfs&m=99780529714933&w=2 and http://marc.theaimsgroup.com/?l=linux-xfs&m=99784007628575&w=2 in Aug, 2001 there is a reference to a problem with linking when configuring with --enable-shared=no. This problem still exists. If I modify include/builddefs.in in acl, attr and xfsprogs to change all instances of "lai" to "la" the "make install-dev" works to installs the libraries. You still have to manually link all of the binaries. For example: gcc -o chacl chacl.o ../libacl/.libs/libacl.al /usr/lib/libattr.al It looks like the makefiles are a bit munged up... but it also looks like a simple fix. If the ".al" files were ".a" files then the linker would be able to find them with "-l attr" like the makefile now reads. The reason I started down the statically linked road in the first place was because the "autoconf;./configure;make;make install;make install-dev" fails to produce binaries and libraries, and does produce errors. So as far as I can tell you have to munge the build in any case. BTW: I do have a working set of kernel-libraries-binaries now so there isn't any emergency for me.... but for newer members of the XFS community this may be a real sticking point. -- Jeffrey Hundstad P.S. I apologize for the mime-stupidity of this message. From owner-linux-xfs@oss.sgi.com Tue Mar 19 14:19:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JMJt507947 for linux-xfs-outgoing; Tue, 19 Mar 2002 14:19: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 g2JMJf907919 for ; Tue, 19 Mar 2002 14:19:41 -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 g2JML46G008409 for ; Tue, 19 Mar 2002 14:21: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 QAA39006; Tue, 19 Mar 2002 16:19:48 -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 QAA31009; Tue, 19 Mar 2002 16:19:48 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2JMHdq32101; Tue, 19 Mar 2002 16:17:39 -0600 Subject: Re: XFS NFS server Oops From: Steve Lord To: "Ian D. Hardy" Cc: idh@soton.ac.uk, linux-xfs@oss.sgi.com In-Reply-To: <200203192114.VAA3765809@plum.sucs.soton.ac.uk> References: <200203192114.VAA3765809@plum.sucs.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Mar 2002 16:17:39 -0600 Message-Id: <1016576259.28200.22.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 15:14, Ian D. Hardy wrote: > > Bad news I'm affraid I've just had what looks like another similar crash. > XFS 2.4.18 CVS treee as of 13th March +Steve Lords vnode.patch - server had > been up ~6 days 4hours (which is slightly longer than average but we have > had ~ 14 days before). > > The ksymoops output is as follows: > invalid operand: 0000 > CPU: 1 > EIP: 0010:[] Not tainted > EFLAGS: 00010202 > eax: 00000001 ebx: c16b3d80 ecx: c16b3d80 edx: 00000000 > esi: 00000000 edi: 00000000 ebp: 00000000 esp: f6d61cb4 > ds: 0018 es: 0018 ss: 0018 > Process nfsinvalid operand: 0000 > CPU: 1 > EIP: 0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010202 > eax: 00000001 ebx: c16b3d80 ecx: c16b3d80 edx: 00000000 > esi: 00000000 edi: 00000000 ebp: 00000000 esp: f6d61cb4 > ds: 0018 es: 0018 ss: 0018 > d (pid: 607, stackpage=f6d61000) > Stack: c16b3d80 00000000 00000000 e1e618e8 c01286a3 c16b3d80 c0128834 c16b3d80 > c16b3d80 c01323e8 c0128a1c 00000000 f6d61d2c 00000000 e1e618e8 c16b3d80 > efb57648 f6d60000 00000000 00000001 f6d61d2c 00000000 c0128acd 00000000 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] > > Code: 0f 0b 8b 43 18 a8 40 74 02 0f 0b 8b 43 18 a8 80 74 02 0f 0b > Process nfsd (pid: 607, stackpage=f6d61000) > Stack: c16b3d80 00000000 00000000 e1e618e8 c01286a3 c16b3d80 c0128834 c16b3d80 > c16b3d80 c01323e8 c0128a1c 00000000 f6d61d2c 00000000 e1e618e8 c16b3d80 > efb57648 f6d60000 00000000 00000001 f6d61d2c 00000000 c0128acd 00000000 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] > Code: 0f 0b 8b 43 18 a8 40 74 02 0f 0b 8b 43 18 a8 80 74 02 0f 0b > > >>EIP; c0131d00 <__free_pages_ok+50/20c> <===== > Trace; c01286a2 > Trace; c0128834 > Trace; c01323e8 <__free_pages+1c/20> > Trace; c0128a1c > Trace; c0128acc > Trace; c01f1372 > Trace; c01f3fec > Trace; c01cf79a > Trace; c01e6cec > Trace; c01e6410 > Trace; c026d014 > Trace; c0265b06 > Trace; c01f6a6e > Trace; c01e6410 > Trace; c014f4dc > Trace; f8d2e972 <[nfsd]nfsd_setattr+3ea/524> > Trace; f8d33f7a <[nfsd]nfsd3_proc_setattr+b6/c4> > Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> > Trace; f8d2b5d2 <[nfsd]nfsd_dispatch+d2/19a> > Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> > Trace; f8cf6f88 <[sunrpc]svc_process+28c/51c> > Trace; f8d3b400 <[nfsd]nfsd_svcstats+0/40> > Trace; f8d3aed8 <[nfsd]nfsd_version3+0/10> > Trace; f8d2b348 <[nfsd]nfsd+1b8/370> > Trace; c01057ea > Code; c0131d00 <__free_pages_ok+50/20c> > 00000000 <_EIP>: > Code; c0131d00 <__free_pages_ok+50/20c> <===== > 0: 0f 0b ud2a <===== > Code; c0131d02 <__free_pages_ok+52/20c> > 2: 8b 43 18 mov 0x18(%ebx),%eax > Code; c0131d04 <__free_pages_ok+54/20c> > 5: a8 40 test $0x40,%al > Code; c0131d06 <__free_pages_ok+56/20c> > 7: 74 02 je b <_EIP+0xb> c0131d0a <__free_pages_ok+5a/20c> > Code; c0131d08 <__free_pages_ok+58/20c> > 9: 0f 0b ud2a > Code; c0131d0a <__free_pages_ok+5a/20c> > b: 8b 43 18 mov 0x18(%ebx),%eax > Code; c0131d0e <__free_pages_ok+5e/20c> > e: a8 80 test $0x80,%al > Code; c0131d10 <__free_pages_ok+60/20c> > 10: 74 02 je 14 <_EIP+0x14> c0131d14 <__free_pages_ok+64/20c> > Code; c0131d12 <__free_pages_ok+62/20c> > 12: 0f 0b ud2a OK, this is something else, and I just had a brainwave about your old oops though, I think you have a really fragmented file out there. Can you run this on your filesystem: xfs_db -r /dev/xxx (it can be mounted) xfs_db: frag -f and send me the output. Someone reported a problem in the memory allocation code the other day, and maybe, just maybe, you are hitting it. Steve > > --- > > Hope the above provides some useful hints in debugging this. > > Regards and many thanks for looking at this. > > Ian Hardy > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 19 14:22:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JMMPc08105 for linux-xfs-outgoing; Tue, 19 Mar 2002 14:22:25 -0800 Received: from c000.snv.cp.net (c000-h001.c000.snv.cp.net [209.228.32.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2JMMM908079 for ; Tue, 19 Mar 2002 14:22:22 -0800 Received: (cpmta 24113 invoked from network); 19 Mar 2002 14:23:45 -0800 Received: from 207.207.51.226 (HELO filecabinet.amoa.org) by smtp.tooley.com (209.228.32.65) with SMTP; 19 Mar 2002 14:23:45 -0800 X-Sent: 19 Mar 2002 22:23:45 GMT Subject: kernel RPMs From: Chris Tooley To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Mar 2002 22:23:45 +0000 Message-Id: <1016576625.22143.85.camel@filecabinet.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I don't know if anyone is interested, but I found myself in a situation where I had to set up a PPTP server on a linux box (PoPToP) to authenticate Windows clients. This meant that I had get mppe into the kernel ppp that comes built into the RedHat contributed kernel. I ended up getting everything set up right and have RPMs built with it. The only difference between the 2.4.9-31 kernels that are in the contributed-by-redhat directory and is the ppp difference. This doesn't break using ppp normally it just adds the ability to use ppp-mppe. If anyone would like a copy of these kernels they can be made available. Chris Tooley From owner-linux-xfs@oss.sgi.com Tue Mar 19 14:35:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JMZQk08908 for linux-xfs-outgoing; Tue, 19 Mar 2002 14:35:26 -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 g2JMZJ908882 for ; Tue, 19 Mar 2002 14:35:19 -0800 Received: from plum.sucs.soton.ac.uk (plum.sucs.soton.ac.uk [152.78.128.10]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g2JMajH09439; Tue, 19 Mar 2002 22:36:45 GMT From: "Ian D. Hardy" Received: (from idh@localhost) by plum.sucs.soton.ac.uk (8.9.3/8.9.3) id WAA3742294; Tue, 19 Mar 2002 22:36:44 GMT Message-Id: <200203192236.WAA3742294@plum.sucs.soton.ac.uk> Subject: Re: XFS NFS server Oops To: lord@sgi.com (Steve Lord) Date: Tue, 19 Mar 2002 22:36:44 +0000 (GMT) Cc: I.D.Hardy@soton.ac.uk (Ian D. Hardy), linux-xfs@oss.sgi.com In-Reply-To: <1016576259.28200.22.camel@jen.americas.sgi.com> from "Steve Lord" at Mar 19, 2002 04:17:39 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 > > OK, this is something else, and I just had a brainwave about your old > oops though, I think you have a really fragmented file out there. Can > you run this on your filesystem: > > xfs_db -r /dev/xxx (it can be mounted) > xfs_db: frag -f > > and send me the output. > > Someone reported a problem in the memory allocation code the other day, > and maybe, just maybe, you are hitting it. > > Steve > > # xfs_db -r /dev/md0 xfs_db: frag -f actual 994261, ideal 811677, fragmentation factor 18.36% Thanks Ian -- //////////////////////////////////////////////////////////////////////////// Ian Hardy Research Services Computing Services email: idh@soton.ac.uk Southampton University i.d.hardy@soton.ac.uk Southampton S017 1BJ, UK. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ From owner-linux-xfs@oss.sgi.com Tue Mar 19 14:49:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JMnNP09305 for linux-xfs-outgoing; Tue, 19 Mar 2002 14:49: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 g2JMnG909276 for ; Tue, 19 Mar 2002 14:49: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 g2JMod6G009966 for ; Tue, 19 Mar 2002 14:50:40 -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 QAA40566; Tue, 19 Mar 2002 16:49:24 -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 QAA11862; Tue, 19 Mar 2002 16:49:24 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2JMlF803661; Tue, 19 Mar 2002 16:47:15 -0600 Subject: Re: XFS NFS server Oops From: Steve Lord To: "Ian D. Hardy" Cc: linux-xfs@oss.sgi.com In-Reply-To: <200203192236.WAA3742294@plum.sucs.soton.ac.uk> References: <200203192236.WAA3742294@plum.sucs.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Mar 2002 16:47:14 -0600 Message-Id: <1016578034.28166.25.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 16:36, Ian D. Hardy wrote: > > > > OK, this is something else, and I just had a brainwave about your old > > oops though, I think you have a really fragmented file out there. Can > > you run this on your filesystem: > > > > xfs_db -r /dev/xxx (it can be mounted) > > xfs_db: frag -f > > > > and send me the output. > > > > Someone reported a problem in the memory allocation code the other day, > > and maybe, just maybe, you are hitting it. > > > > Steve > > > > > > # xfs_db -r /dev/md0 > xfs_db: frag -f > actual 994261, ideal 811677, fragmentation factor 18.36% So now try this: xfs_fsr -v /dev/md0 it will report the files it defragments, look for something with a really large number of extents in the before column. Steve > > Thanks > > Ian > -- > > //////////////////////////////////////////////////////////////////////////// > Ian Hardy > Research Services > Computing Services email: idh@soton.ac.uk > Southampton University i.d.hardy@soton.ac.uk > Southampton S017 1BJ, UK. > \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Mar 19 15:17:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2JNHU410281 for linux-xfs-outgoing; Tue, 19 Mar 2002 15:17:30 -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 g2JNHK910255 for ; Tue, 19 Mar 2002 15:17:21 -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 g2K0Qnkw031678 for ; Tue, 19 Mar 2002 18:26:51 -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 KAA03391; Wed, 20 Mar 2002 10:17:17 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA21277; Wed, 20 Mar 2002 10:17:15 +1100 (AEDT) Date: Wed, 20 Mar 2002 10:17:13 +1100 From: Nathan Scott To: "Hundstad, Jeffrey E." Cc: linux-xfs@oss.sgi.com, Vincent Bernat Subject: Re: --enable-shared=no gives linking errors Was: New tarball error Message-ID: <20020320101713.W1601@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 jeffrey.hundstad@mnsu.edu on Tue, Mar 19, 2002 at 04:17:15PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello, On Tue, Mar 19, 2002 at 04:17:15PM -0600, Hundstad, Jeffrey E. wrote: > > If I modify include/builddefs.in in acl, attr and xfsprogs to change all instances of "lai" to "la" the "make install-dev" works to installs the libraries. You still have to manually link all of the binaries. For example: > > gcc -o chacl chacl.o ../libacl/.libs/libacl.al /usr/lib/libattr.al > > It looks like the makefiles are a bit munged up... but it also looks like a simple fix. Can you send a patch? Might be easier than explaining it. Its not clear to me that you have latest version of acl (or maybe you overlooked the install-lib target?) > > The reason I started down the statically linked road in the first place was because the "autoconf;./configure;make;make install;make install-dev" fails to produce binaries and libraries, and does produce errors. So as far as I can tell you have to munge the build in any case. What error do you see? You seem to be missing "install-lib", eg. $ autoconf $ ./configure $ make $ make install install-dev install-lib > BTW: I do have a working set of kernel-libraries-binaries now so there isn't any emergency for me.... but for newer members of the XFS community this may be a real sticking point. I expect newer members of the community would just type "make" and expect it to work (which it should and, afaik, does). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 19 16:48:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K0m6013698 for linux-xfs-outgoing; Tue, 19 Mar 2002 16:48:06 -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 g2K0m2913672 for ; Tue, 19 Mar 2002 16:48:02 -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 g2K0nO6G014855 for ; Tue, 19 Mar 2002 16:49:25 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA33704 for linux-xfs@oss.sgi.com; Wed, 20 Mar 2002 11:48:06 +1100 (EST) Date: Wed, 20 Mar 2002 11:48:06 +1100 (EST) From: Nathan Scott Message-Id: <200203200048.LAA33704@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - attr + config workaround Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Mar 19 16:47:15 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:114491a cmd/attr/doc/CHANGES - 1.19 cmd/attr/libattr/syscalls.c - 1.9 - add mips/mips64 syscall entries. Modid: 2.4.x-xfs:slinx:114491b linux/fs/xfs/linux/xfs_super.h - 1.16 - disallow compilation if CONFIG_DEBUG_SPINLOCK is enabled, for now. From owner-linux-xfs@oss.sgi.com Tue Mar 19 16:50:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K0obV13826 for linux-xfs-outgoing; Tue, 19 Mar 2002 16:50:37 -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 g2K0oY913800 for ; Tue, 19 Mar 2002 16:50: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 g2K0pt6G014914 for ; Tue, 19 Mar 2002 16:51:56 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA37496 for linux-xfs@oss.sgi.com; Wed, 20 Mar 2002 11:50:38 +1100 (EST) Date: Wed, 20 Mar 2002 11:50:38 +1100 (EST) From: Nathan Scott Message-Id: <200203200050.LAA37496@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - 2.5 xattr.c locking Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Mar 19 16:50:11 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/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:114492a linux/Documentation/filesystems/Locking - 1.9 linux/fs/xattr.c - 1.3 - switch from BKL to i_sem locking for 2.5 xattr vfs operations. From owner-linux-xfs@oss.sgi.com Tue Mar 19 17:26:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K1Qkl14802 for linux-xfs-outgoing; Tue, 19 Mar 2002 17:26:46 -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 g2K1QU914517 for ; Tue, 19 Mar 2002 17:26:30 -0800 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g2K1LD819866; Tue, 19 Mar 2002 19:21:13 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Re: opps on xfs on a linear raid on a sparc64 box From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: <1016561155.19159.0.camel@lucy> References: <1016561155.19159.0.camel@lucy> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 19 Mar 2002 19:21:12 -0600 Message-Id: <1016587272.19159.2.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Today, I'd tried to use xfs on a linear raid, and it oops'ses. I've just tried it with a raid5, and the same thing happen. (BTW, I did forgot to mention (sorry) that the same raid formated with ext2, even with the same kernel, works perfectly) Here is the oops for the raid5 test. rsync(548): Oops TSTATE: 0000009911009607 TPC: 000000000052c848 TNPC: 000000000052c84c Y: 00300000 Not tainted Using defaults from ksymoops -t elf32-sparc -a sparc g0: ffffffffffffe000 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000000000000 g4: fffff80000000000 g5: 0000000000000001 g6: fffff80011bd4000 g7: 0000000000000001 o0: 00000000006a5c00 o1: 0000000000000001 o2: fffff800117fb9e0 o3: 0000000002000380 o4: fffff800117fbda0 o5: fffff800117fa040 sp: fffff80011bd61a1 ret_pc: 000000000052c910 l0: 0000000000696800 l1: 0000000000000001 l2: 0000000000be1580 l3: 0000000000c0004f l4: 0000000000000002 l5: fffff80013238800 l6: 0000000000000002 l7: 0000000000683808 i0: 0000000000000001 i1: 0000000000c00046 i2: 000000000000000a i3: 0000000000000050 i4: 00000000005afbf8 i5: 0000000000000000 i6: fffff80011bd6261 i7: 00000000004fcc50 Caller[00000000004fcc50] Caller[00000000004fce0c] Caller[00000000004fd28c] Caller[00000000004fcefc] Caller[00000000004e32c4] Caller[00000000004e3ae8] Caller[00000000004e5428] Caller[00000000004e55a0] Caller[00000000004e29f4] Caller[00000000004af6f4] Caller[00000000004acf6c] Caller[00000000004af174] Caller[00000000004d77cc] Caller[00000000004d7f84] Caller[00000000004dd6f8] Caller[00000000004f13b0] Caller[00000000004f7a28] Caller[00000000005024d0] Caller[0000000000502974] Caller[000000000046c220] Caller[000000000046c344] Caller[0000000000410974] Caller[000000000001ae44] Instruction DUMP: 01000000 9de3bf40 11001a97 90122320 d45e6068 9332e008 932a7003 80a2a000 >>PC; 0052c848 <===== >>O7; 0052c910 >>I7; 004fcc50 <_pagebuf_page_io+230/2e0> Trace; 004fcc50 <_pagebuf_page_io+230/2e0> Trace; 004fce0c <_page_buf_page_apply+10c/120> Trace; 004fd28c Trace; 004fcefc Trace; 004e32c4 Trace; 004e3ae8 Trace; 004e5428 Trace; 004e55a0 Trace; 004e29f4 Trace; 004af6f4 Trace; 004acf6c Trace; 004af174 Trace; 004d77cc Trace; 004d7f84 Trace; 004dd6f8 Trace; 004f13b0 Trace; 004f7a28 Trace; 005024d0 Trace; 00502974 Trace; 0046c220 Trace; 0046c344 Trace; 00410974 Trace; 0001ae44 Before first symbol Code; 0052c83c <__make_request+75c/760> 0000000000000000 <_PC>: Code; 0052c83c <__make_request+75c/760> 0: 01 00 00 00 nop Code; 0052c840 4: 9d e3 bf 40 save %sp, -192, %sp Code; 0052c844 8: 11 00 1a 97 sethi %hi(0x6a5c00), %o0 Code; 0052c848 <===== c: d6 16 60 1c lduh [ %i1 + 0x1c ], %o3 <===== Code; 0052c84c 10: 90 12 23 20 or %o0, 0x320, %o0 Code; 0052c850 14: d4 5e 60 68 unknown Code; 0052c854 18: 93 32 e0 08 srl %o3, 8, %o1 Code; 0052c858 1c: 93 2a 70 03 unknown Code; 0052c85c 20: 80 a2 a0 00 cmp %o2, 0 -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Tue Mar 19 17:36:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K1ajO15544 for linux-xfs-outgoing; Tue, 19 Mar 2002 17:36:45 -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 g2K1aa915518 for ; Tue, 19 Mar 2002 17:36:37 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id DDE24C027E0 for ; Wed, 20 Mar 2002 09:37:52 +0800 (PHT) Received: from mail.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 0EECBC001FD for ; Wed, 20 Mar 2002 09:37:44 +0800 (PHT) Date: Wed, 20 Mar 2002 09:37:43 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: Fragmentation (was: XFS NFS server Oops) In-Reply-To: <1016578034.28166.25.camel@jen.americas.sgi.com> 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 On 19 Mar 2002 at 16:47, Steve Lord wrote: > xfs_db -r /dev/xxx (it can be mounted) > xfs_db: frag -f Cool. (Obviously I never really dug into the xfs_db manpage before to find stuff like this out.) That seemed harmless so I checked out all my filesystems. I got fragmentation factors from a high of 50.92% (this is a filesystem where I store huge tar.gz backups and not much else) to a low of 0.43% for my / filesystem. So now I wonder (trivial, really, but this might be FAQ-worthy): a. At what fragmentation factor should we start considering running xfs_fsr? Or should we just go with what the xfs_fsr manpage says and run it in a crontab weekly? b. I remember awhile back that xfs_fsr didn't come very highly recommended. Is this still the case? Or can we use xfs_fsr on production systems (during their more idle times, of course) and still be able to sleep at night? Thanks in advance! :) --> 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 Tue Mar 19 20:18:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K4I8E19575 for linux-xfs-outgoing; Tue, 19 Mar 2002 20:18:08 -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 g2K4I2919549 for ; Tue, 19 Mar 2002 20:18:03 -0800 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g2K4JTXt019385 for ; Wed, 20 Mar 2002 15:19:29 +1100 (EST) Received: from jdc.local (ppp121.dyn141.pacific.net.au [210.23.141.121]) by wisma.pacific.net.au with ESMTP id PAA20623 for ; Wed, 20 Mar 2002 15:19:28 +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 g2K4JLJ4000770 for ; Wed, 20 Mar 2002 15:19:21 +1100 Received: (from jason@localhost) by jdc.local (8.12.1/8.12.1/Debian -5) id g2K3QmwR004482; Wed, 20 Mar 2002 14:26:48 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15512.376.149191.221858@jdc.local> Date: Wed, 20 Mar 2002 14:26:48 +1100 To: linux-xfs@oss.sgi.com Subject: Re: Fragmentation (was: XFS NFS server Oops) In-Reply-To: References: <1016578034.28166.25.camel@jen.americas.sgi.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 While on the subject of xfs_fsr, it would also be of interest to know what risks are involved in running it. For example, what damage can be caused if the system crashes while files are being defragmented, and is there likely to be data loss if the system is cleanly shut down while xfs_fsr is running? Also, xfs_fsr needs to avoid certain files, especially kernel images, the location of which on the disk is significant to the boot process if I understand correctly. From owner-linux-xfs@oss.sgi.com Tue Mar 19 21:18:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K5IJn20194 for linux-xfs-outgoing; Tue, 19 Mar 2002 21:18:19 -0800 Received: from shakti.rupa.com (foobar@adsl-66-125-43-50.dsl.lsan03.pacbell.net [66.125.43.50]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2K5IF920168 for ; Tue, 19 Mar 2002 21:18:15 -0800 Received: from shakti.rupa.com (localhost [127.0.0.1]) by localhost.rupa.com (Postfix) with ESMTP id 40E923EA07; Tue, 19 Mar 2002 21:19:50 -0800 (PST) Mailbox-Line: From rupa-list@rupa.com Tue Mar 19 21:19:50 2002 Received: by shakti.rupa.com (Postfix, from userid 9) id 24B503EA06; Tue, 19 Mar 2002 21:19:50 -0800 (PST) Received: from 192.168.1.20 by 192.168.1.20 with nntp; 19 Mar 2002 21:19:50 PST To: linux-xfs@oss.sgi.com Subject: Re: Fragmentation (was: XFS NFS server Oops) References: <1016578034.28166.25.camel@jen.americas.sgi.com> From: Rupa Schomaker Mail-Copies-To: never Date: Tue, 19 Mar 2002 21:19:49 -0800 Message-ID: User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i386-debian-linux-gnu) Cancel-Lock: sha1:taiaHf/G/3Kl1mzvJZX26gRLcJA= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 192.168.1.20 X-Spam-Status: No, hits=-100.0 required=5.0 tests=USER_IN_WHITELIST version=2.11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Federico Sevilla III writes: > I got fragmentation factors from a high of 50.92% (this is a filesystem > where I store huge tar.gz backups and not much else) to a low of 0.43% for > my / filesystem. I've got a filesystem with 28 .iso images, the frags -f command shows: # xfs_db -r /dev/shaktivg/xxx xfs_db: frag -f actual 355, ideal 29, fragmentation factor 91.83% yikes... -- -rupa From owner-linux-xfs@oss.sgi.com Tue Mar 19 22:36:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K6afx21041 for linux-xfs-outgoing; Tue, 19 Mar 2002 22:36:41 -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 g2K6aZ921015 for ; Tue, 19 Mar 2002 22:36:36 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx03)) with ESMTP id 146E961AE; Wed, 20 Mar 2002 07:35:52 +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 HAA07257; Wed, 20 Mar 2002 07:35:50 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id A597F57306; Wed, 20 Mar 2002 07:35:42 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 5376B25835; Wed, 20 Mar 2002 07:35:42 +0100 (CET) Message-ID: <3C982DBE.65EC9E7@ch.sauter-bc.com> Date: Wed, 20 Mar 2002 07:35:42 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Chris Tooley Cc: linux-xfs@oss.sgi.com Subject: Re: kernel RPMs References: <1016576625.22143.85.camel@filecabinet.amoa.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Chris Tooley schrieb: > > I don't know if anyone is interested, but I found myself in a situation > where I had to set up a PPTP server on a linux box (PoPToP) to > authenticate Windows clients. This meant that I had get mppe into the > kernel ppp that comes built into the RedHat contributed kernel. I ended > up getting everything set up right and have RPMs built with it. The > only difference between the 2.4.9-31 kernels that are in the > contributed-by-redhat directory and is the ppp difference. This doesn't > break using ppp normally it just adds the ability to use ppp-mppe. If > anyone would like a copy of these kernels they can be made available. > > Chris Tooley I might be interested one day but when this day comes, it'll be far too late for the 2.4.9-31 kernel. IIRC the problem with mppe is that for some reason RedHat can not include it in their kernel. It is a licence thing or an export problem, isn't it? I have contributed the 2.4.9-31 RPMs and the goal was to have exactly the same kernel like original RedHat 2.4.9-31 but with only XFS and kdb included. Could you send me the .spec and patches anyway? -Simon From owner-linux-xfs@oss.sgi.com Tue Mar 19 22:49:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K6n0C21361 for linux-xfs-outgoing; Tue, 19 Mar 2002 22:49:00 -0800 Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2K6mt921335 for ; Tue, 19 Mar 2002 22:48:55 -0800 Received: from adsl-64-161-31-224.dsl.sntc01.pacbell.net ([64.161.31.224] helo=zip.com.au) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16nZvR-0008Dc-00; Wed, 20 Mar 2002 06:50:22 +0000 Message-ID: <3C9830A6.EE6025E4@zip.com.au> Date: Tue, 19 Mar 2002 22:48:06 -0800 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rupa Schomaker CC: linux-xfs@oss.sgi.com Subject: Re: Fragmentation (was: XFS NFS server Oops) References: <1016578034.28166.25.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 Rupa Schomaker wrote: > > Federico Sevilla III writes: > > > I got fragmentation factors from a high of 50.92% (this is a filesystem > > where I store huge tar.gz backups and not much else) to a low of 0.43% for > > my / filesystem. > > I've got a filesystem with 28 .iso images, the frags -f command shows: > > # xfs_db -r /dev/shaktivg/xxx > xfs_db: frag -f > actual 355, ideal 29, fragmentation factor 91.83% > I assume that's saying that ideally, those 28 files should take up just 28 contiguous chunks of disk, but in fact they're taking 355. If those ISOs are all 600 megs then your average contiguous chunk size is 47 megs, which is darn good. Quantifying fragmentation is hard. I think the only valid way really of measuring it is to go for the bottom line: grab the stopwatch and time how long it takes to read the files. Then copy them to a newly-initialised and empty filesystem, see how long it takes to read the files under these ideal circumstances. Then compare the two times. From owner-linux-xfs@oss.sgi.com Tue Mar 19 23:26:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K7Qhj22122 for linux-xfs-outgoing; Tue, 19 Mar 2002 23:26:43 -0800 Received: from mail.hs.tecmath.com ([62.16.211.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2K7QY922093 for ; Tue, 19 Mar 2002 23:26:35 -0800 Received: from [192.168.98.1] (helo=superserver.humanmodeling.tecmath.de) by mail.hs.tecmath.com with esmtp (Exim 3.33 #1) id 16naVe-00072H-00; Wed, 20 Mar 2002 08:27:46 +0100 Received: from [192.168.98.14] (helo=tmsgi7.humanmodeling.tecmath.de) by superserver.humanmodeling.tecmath.de with esmtp (Exim 3.22 #1) id 16naVe-0003Nm-00; Wed, 20 Mar 2002 08:27:46 +0100 Date: Wed, 20 Mar 2002 08:27:46 +0100 From: Martin Apel X-X-Sender: apel@tmsgi7.humanmodeling.tecmath.de To: Steve Lord cc: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" , , Subject: Re: TDB corruption with Samba 2.2.3a In-Reply-To: <1016567299.1770.128.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 19 Mar 2002, Steve Lord wrote: > On Tue, 2002-03-19 at 01:03, Martin Apel wrote: > > On Wed, 13 Mar 2002, Jeremy Allison wrote: > > > > > On Wed, Mar 13, 2002 at 05:25:13AM -0500, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > > > > We are also experiencing the TDB corruptions, as reported in the samba log > > > > files. At first there didn't seem to be an consequence, but we are now > > > > beginning to see user's not being able to login to the machine. As a > > > > workaround we have been just deleting the secrets.tdb file, restarting > > > > samba, and rejoining the domain. > > > > > > > > Our server if very similar to Martin's (Samba 2.2.3a + Linux 2.4.17 + XFS). > > > > I'll post more details soon. > > > > > > Can you try using the tdbbackup utility periodically > > > to determine when the corruption may be occurring ? > > > > I let the tdbbackup run for a few days now. The TDB corruption seems to > > happen at the time, when Amanda (a great backup tool) starts to run. > > I have moved the Amanda start time back and forth and the corruption > > starts within 10 minutes after starting Amanda. > > I don't think it's Amanda's fault, I assume that Amanda puts a heavy load > > on the filesystem layer during the first minutes, when it does its estimates. > > A reminder: all partitions on this system are XFS partititions, including > > /var, where Samba stores the TDB files. > > I could try to reformat the /var filesystem with ext2 to see if this has > > any influence. But this will probably need a server reboot, so I cannot > > do this before the weekend. > > > > Martin > > Can you try a kernel from the 2.4 xfs cvs tree - I just pushed some > changes out there which fix a corruption problem under heavy memory > pressure. Hi Steve, since this is our production server with 50 people being dependent on it I would rather not try the current CVS version. Is it possible to isolate your patch relative to XFS 1.0.2? For the record: I put the Samba lock directory onto an ext2 partition yesterday and had no problems since then. Martin ________________________________________________________________________ Martin Apel, Dipl.-Inform. t e c m a t h A G Group Manager Software Development Human Solutions Division phone +49 (0)631 303-5600 Europaallee 10, 67657 Kaiserslautern fax +49 (0)631 303-5700 Germany apel@hs.tecmath.com http://www.tecmath.com ________________________________________________________________________ From owner-linux-xfs@oss.sgi.com Wed Mar 20 00:18:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2K8IfW23177 for linux-xfs-outgoing; Wed, 20 Mar 2002 00:18:41 -0800 Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2K8IZ923145 for ; Wed, 20 Mar 2002 00:18:36 -0800 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2K8Jff7068274; Wed, 20 Mar 2002 09:19:47 +0100 (CET) Message-Id: <4.3.2.7.2.20020320091428.02eea718@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Mar 2002 09:17:02 +0100 To: Martin Apel , Steve Lord From: Seth Mos Subject: Re: TDB corruption with Samba 2.2.3a Cc: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" , , In-Reply-To: References: <1016567299.1770.128.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:27 20-3-2002 +0100, Martin Apel wrote: > > Can you try a kernel from the 2.4 xfs cvs tree - I just pushed some > > changes out there which fix a corruption problem under heavy memory > > pressure. > >Hi Steve, > >since this is our production server with 50 people being dependent on it >I would rather not try the current CVS version. Is it possible to isolate >your patch relative to XFS 1.0.2? >For the record: I put the Samba lock directory onto an ext2 partition >yesterday and had no problems since then. The XFS CVS tree is steady on 2.4.Cheers18 for a while now and a lot of bugs have been fixed since the original 2.4.18 merge and since the 1.0.2 release. But then again, with 2.4 YMMV. 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 Wed Mar 20 03:24:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KBOpG26109 for linux-xfs-outgoing; Wed, 20 Mar 2002 03:24:51 -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 g2KBOh926083 for ; Wed, 20 Mar 2002 03:24:43 -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 g2KBQAH16832 for ; Wed, 20 Mar 2002 11:26:10 GMT Received: from whitebeam.sucs.soton.ac.uk (whitebeam.sucs.soton.ac.uk [152.78.128.4]) by poplar.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g2KBP9g04946; Wed, 20 Mar 2002 11:25:09 GMT Received: (from nobody@localhost) by whitebeam.sucs.soton.ac.uk (8.10.0/8.10.0) id g2KBUX801415; Wed, 20 Mar 2002 11:30:33 GMT To: linux-xfs@oss.sgi.com Subject: WARNING with regards to running xfs_fsr Message-ID: <1016623833.3c9872d96c0a2@webmail.soton.ac.uk> Date: Wed, 20 Mar 2002 11:30:33 +0000 (GMT) From: Ian Hardy Cc: idh@soton.ac.uk MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4 X-Originating-IP: 152.78.128.11 X-MailScanner: Believed to be clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I note that my exchange of emails with Steve Lord yesterday "Re: XFS NFS server Oops" with regards to checking for fragmentation and reducing fragmentation using 'xfs_fsr' has generated a followup thread "Re: Fragmentation (was: XFS NFS server Oops)" and some interest in deframenting XFS file systems. I'd recommend that you DON'T all rush to run 'xfs_fsr', at least until we've got some more feedback/info from the XFS experts at SGI. As advised I ran 'xfs_fsr' last night, it had completed when I got into work in the morning, so I ran 'xfs_db' in order to check fragmentation levels again: # xfs_db -r /dev/md0 xfs_db: frag -f Segmentation fault (core dumped) Whats more it then shutdown the filesystem (from 'messages'): Mar 20 09:30:17 blue00 kernel: xfs_force_shutdown(md(9,0),0x8) called from line 1039 of file xfs_trans.c. Return address = 0xc01e2179 Mar 20 09:30:17 blue00 kernel: Corruption of in-memory data detected. Shutting down filesystem: md(9,0) Mar 20 09:30:17 blue00 kernel: Please umount the filesystem, and rectify the problem(s) I rebooted the server and ran 'xfs_check' on the filesystem that showed a number of errors, which 'xfs_repair' fixed (I'll post some more details shortly). While its (very) possible that the above problem was due to underlying problems with my filesystem, it is also possible that 'xfs_fsr' had some bad effect on the filesystem. Worth getting some feedback from the XFS experts before too many people rush to run 'xfs_fsr' !? By the way I seem to remember a lot of SGI Irix users (including me) had various problems with 'xfs_fsr' when SGI first introduced it (or enabled its default running from cron) under Irix a few years ago. I believe these problems where fixed, however, I still don't routinely run 'xfs_fsr' on my Irix servers. Ian /////////////Technical Coordination, Research Services//////////////////// Ian Hardy 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 20 07:02:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KF2j130373 for linux-xfs-outgoing; Wed, 20 Mar 2002 07:02:45 -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 g2KF2Z930347 for ; Wed, 20 Mar 2002 07:02: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 g2KG3xBA004799 for ; Wed, 20 Mar 2002 08:03:59 -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 JAA47807; Wed, 20 Mar 2002 09:02:43 -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 JAA62501; Wed, 20 Mar 2002 09:02:42 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2KF0QJ07519; Wed, 20 Mar 2002 09:00:26 -0600 Subject: Re: TDB corruption with Samba 2.2.3a From: Steve Lord To: Martin Apel Cc: "ZINKEVICIUS,MATT ""(HP-Loveland,ex1)" , samba-technical@lists.samba.org, linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 09:00:26 -0600 Message-Id: <1016636426.6150.44.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-20 at 01:27, Martin Apel wrote: > On 19 Mar 2002, Steve Lord wrote: > > > On Tue, 2002-03-19 at 01:03, Martin Apel wrote: > > > On Wed, 13 Mar 2002, Jeremy Allison wrote: > > > > > > > On Wed, Mar 13, 2002 at 05:25:13AM -0500, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > > > > > We are also experiencing the TDB corruptions, as reported in the samba log > > > > > files. At first there didn't seem to be an consequence, but we are now > > > > > beginning to see user's not being able to login to the machine. As a > > > > > workaround we have been just deleting the secrets.tdb file, restarting > > > > > samba, and rejoining the domain. > > > > > > > > > > Our server if very similar to Martin's (Samba 2.2.3a + Linux 2.4.17 + XFS). > > > > > I'll post more details soon. > > > > > > > > Can you try using the tdbbackup utility periodically > > > > to determine when the corruption may be occurring ? > > > > > > I let the tdbbackup run for a few days now. The TDB corruption seems to > > > happen at the time, when Amanda (a great backup tool) starts to run. > > > I have moved the Amanda start time back and forth and the corruption > > > starts within 10 minutes after starting Amanda. > > > I don't think it's Amanda's fault, I assume that Amanda puts a heavy load > > > on the filesystem layer during the first minutes, when it does its estimates. > > > A reminder: all partitions on this system are XFS partititions, including > > > /var, where Samba stores the TDB files. > > > I could try to reformat the /var filesystem with ext2 to see if this has > > > any influence. But this will probably need a server reboot, so I cannot > > > do this before the weekend. > > > > > > Martin > > > > Can you try a kernel from the 2.4 xfs cvs tree - I just pushed some > > changes out there which fix a corruption problem under heavy memory > > pressure. > > Hi Steve, > > since this is our production server with 50 people being dependent on it > I would rather not try the current CVS version. Is it possible to isolate > your patch relative to XFS 1.0.2? > For the record: I put the Samba lock directory onto an ext2 partition > yesterday and had no problems since then. > Well, the simple answer is no. Since the code hits fs/buffer.c which has changed a lot. However, we are working on pushing current xfs code back into a 2.4.9 kernel in rpm format. 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 20 07:09:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KF9Ei30621 for linux-xfs-outgoing; Wed, 20 Mar 2002 07:09:14 -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 g2KF94930594 for ; Wed, 20 Mar 2002 07:09:04 -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 g2KFAR6G007444 for ; Wed, 20 Mar 2002 07:10:27 -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 JAA46499; Wed, 20 Mar 2002 09:09:11 -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 JAA28874; Wed, 20 Mar 2002 09:09:11 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2KF6tM07546; Wed, 20 Mar 2002 09:06:55 -0600 Subject: Re: WARNING with regards to running xfs_fsr From: Steve Lord To: Ian Hardy Cc: linux-xfs@oss.sgi.com, idh@soton.ac.uk In-Reply-To: <1016623833.3c9872d96c0a2@webmail.soton.ac.uk> References: <1016623833.3c9872d96c0a2@webmail.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 09:06:55 -0600 Message-Id: <1016636815.28200.52.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-20 at 05:30, Ian Hardy wrote: > I note that my exchange of emails with Steve Lord yesterday > "Re: XFS NFS server Oops" with regards to checking for > fragmentation and reducing fragmentation using 'xfs_fsr' has > generated a followup thread "Re: Fragmentation (was: XFS NFS > server Oops)" and some interest in deframenting XFS file systems. > > I'd recommend that you DON'T all rush to run 'xfs_fsr', at least > until we've got some more feedback/info from the XFS experts > at SGI. As advised I ran 'xfs_fsr' last night, it had completed > when I got into work in the morning, so I ran 'xfs_db' in order > to check fragmentation levels again: > > # xfs_db -r /dev/md0 > xfs_db: frag -f > Segmentation fault (core dumped) > > Whats more it then shutdown the filesystem (from 'messages'): > > Mar 20 09:30:17 blue00 kernel: xfs_force_shutdown(md(9,0),0x8) called from line > 1039 of file xfs_trans.c. Return address = 0xc01e2179 > Mar 20 09:30:17 blue00 kernel: Corruption of in-memory data detected. Shutting > down filesystem: md(9,0) > Mar 20 09:30:17 blue00 kernel: Please umount the filesystem, and rectify the > problem(s) > > I rebooted the server and ran 'xfs_check' on the filesystem that showed > a number of errors, which 'xfs_repair' fixed (I'll post some more details > shortly). > > While its (very) possible that the above problem was due to underlying > problems with my filesystem, it is also possible that 'xfs_fsr' had > some bad effect on the filesystem. Worth getting some feedback from the > XFS experts before too many people rush to run 'xfs_fsr' !? > > By the way I seem to remember a lot of SGI Irix users (including me) had > various problems with 'xfs_fsr' when SGI first introduced it (or enabled > its default running from cron) under Irix a few years ago. I believe > these problems where fixed, however, I still don't routinely run > 'xfs_fsr' on my Irix servers. > > > Ian > Sorry about that Ian, do you have the repair output you can send me? I did run fsr on a few filesystems here before suggesting it. xfs_fsr itself is a purely user level program, all data copying is done via system calls, the only special thing it does is switch the extents of two files, this should be happening atomically, and really should not be able to corrupt a filesystem. It would however look at pretty much all the metadata on a filesystem and find problems if they existed. Once you recovered what did frag -f report - i.e. did fsr do any good? 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 20 07:18:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KFIGm30854 for linux-xfs-outgoing; Wed, 20 Mar 2002 07:18:16 -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 g2KFIC930826 for ; Wed, 20 Mar 2002 07:18:12 -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 16nhsF-0006C2-00 for linux-xfs@oss.sgi.com; Wed, 20 Mar 2002 15:19:35 +0000 Message-ID: <3C98A887.C4E1FFCD@moving-picture.com> Date: Wed, 20 Mar 2002 15:19:35 +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: linux-xfs@oss.sgi.com Subject: NFS and umask Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've just had the problem with mkdir ignoring umask when creating directories on Linux XFS file systems mounted over NFS. I'm using XFS 1.0.2 with kernel 2.4.14-xfs Searching the archives, shows that this is a known issue - but are there any workarounds/fixes? Thanks James Pearson From owner-linux-xfs@oss.sgi.com Wed Mar 20 07:20:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KFKHW31015 for linux-xfs-outgoing; Wed, 20 Mar 2002 07:20:17 -0800 Received: from chkbak.localdomain ([213.53.199.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KFKB930989 for ; Wed, 20 Mar 2002 07:20:12 -0800 Received: (qmail 22954 invoked from network); 20 Mar 2002 15:23:14 -0000 Received: from unknown (HELO aplabwp0368359) (192.168.0.59) by 192.168.0.254 with SMTP; 20 Mar 2002 15:23:14 -0000 Message-ID: <004701c1d023$2623fcd0$3b00a8c0@aplabwp0368359> From: "Bas" To: Subject: Corrupted files on 2.4.18. Date: Wed, 20 Mar 2002 16:23:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, The following has happened: Today I was editing some files on my / filesystem. I had made some changes to one of my startup scripts and the configuration file for samba, which are one the same filesystem. When I tried to look into the logfile directory, which is a separate lv, I could run ls, but when I ran ls -la, it hung. Only option was to reboot, but I waited a little, probably enough time to clear the changes to disk. After a reboot I noticed the files I had changed were indeed changed, the still had the same size, but were filled with ^@ characters -> This was visible through vim. Funny thing is that the backup files vi makes (.rc.samba.swp) were also damaged and not useable anymore. Specs: gcc-2.95.3 glibc-2.2.5 binutils-2.11.2 linux 2.4.18 The first 2.4.18 xfs patch. evms 0.9.2 -> no lvm anymore. lvs: /, /usr, /home, /var. Downloading the entire xfs-2.4 cvs takes a lot of time, but if necessary, I can do that. There used to be some weekly patches, maybe the location has changed, but I can't seem to find them anymore. Groeten, Bas. From owner-linux-xfs@oss.sgi.com Wed Mar 20 07:28:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KFSCl31207 for linux-xfs-outgoing; Wed, 20 Mar 2002 07:28: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 g2KFS7931180 for ; Wed, 20 Mar 2002 07:28:07 -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 g2KGTVBA007190 for ; Wed, 20 Mar 2002 08:29:31 -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 JAA50931; Wed, 20 Mar 2002 09:28:15 -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 JAA38878; Wed, 20 Mar 2002 09:28:15 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2KFPwa07627; Wed, 20 Mar 2002 09:25:58 -0600 Subject: Re: opps on xfs on a linear raid on a sparc64 box From: Steve Lord To: Alvaro Figueroa Cc: XFS to linux port mailing list In-Reply-To: <1016587272.19159.2.camel@lucy> References: <1016561155.19159.0.camel@lucy> <1016587272.19159.2.camel@lucy> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 09:25:58 -0600 Message-Id: <1016637958.6150.78.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 19:21, Alvaro Figueroa wrote: > > Today, I'd tried to use xfs on a linear raid, and it oops'ses. > > I've just tried it with a raid5, and the same thing happen. > > (BTW, I did forgot to mention (sorry) that the same raid formated with > ext2, even with the same kernel, works perfectly) > > Here is the oops for the raid5 test. > > Both these oopses are the same thing, but why sparc64 sees this when other platforms do not I really do not know. Do you have any way of working out where in the function this address is on a sparc64? __make_request+75c/760 i.e. which line of source. It might give us some clues. 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 20 07:30:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KFU8331361 for linux-xfs-outgoing; Wed, 20 Mar 2002 07:30: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 g2KFU2931334 for ; Wed, 20 Mar 2002 07:30:02 -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 g2KGVQBA007392 for ; Wed, 20 Mar 2002 08:31:26 -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 JAA51144; Wed, 20 Mar 2002 09:30:10 -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 JAA65547; Wed, 20 Mar 2002 09:30:10 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2KFRrH07631; Wed, 20 Mar 2002 09:27:53 -0600 Subject: Re: Corrupted files on 2.4.18. From: Steve Lord To: Bas Cc: linux-xfs@oss.sgi.com In-Reply-To: <004701c1d023$2623fcd0$3b00a8c0@aplabwp0368359> References: <004701c1d023$2623fcd0$3b00a8c0@aplabwp0368359> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 09:27:53 -0600 Message-Id: <1016638073.28166.82.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-20 at 09:23, Bas wrote: > Hi, > > The following has happened: > > Today I was editing some files on my / filesystem. I had made some changes > to one of my startup scripts and the configuration file for samba, which are > one the same filesystem. When I tried to look into the logfile directory, > which is a separate lv, I could run ls, but when I ran ls -la, it hung. Only > option was to reboot, but I waited a little, probably enough time to clear > the changes to disk. After a reboot I noticed the files I had changed were > indeed changed, the still had the same size, but were filled with ^@ > characters -> This was visible through vim. Funny thing is that the backup > files vi makes (.rc.samba.swp) were also damaged and not useable anymore. Almost certainly the hung process was holding sufficient locks that it wedged syncing activity on the system and waiting did you no good. I do not think there is anything in a later kernel which would help with this. The hang is the bug here really - and we have no information about what that was. Steve > > Specs: > gcc-2.95.3 > glibc-2.2.5 > binutils-2.11.2 > linux 2.4.18 > The first 2.4.18 xfs patch. > evms 0.9.2 -> no lvm anymore. > > lvs: > /, /usr, /home, /var. > > Downloading the entire xfs-2.4 cvs takes a lot of time, but if necessary, I > can do that. There used to be some weekly patches, maybe the location has > changed, but I can't seem to find them anymore. > > Groeten, > Bas. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Mar 20 07:34:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KFYD831548 for linux-xfs-outgoing; Wed, 20 Mar 2002 07:34:13 -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 g2KFY7931521 for ; Wed, 20 Mar 2002 07:34:07 -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 g2KFZV6G010051 for ; Wed, 20 Mar 2002 07:35:31 -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 JAA51950; Wed, 20 Mar 2002 09:34:16 -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 JAA47119; Wed, 20 Mar 2002 09:34:15 -0600 (CST) Subject: Re: Corrupted files on 2.4.18. From: Eric Sandeen To: Bas Cc: linux-xfs@oss.sgi.com In-Reply-To: <004701c1d023$2623fcd0$3b00a8c0@aplabwp0368359> References: <004701c1d023$2623fcd0$3b00a8c0@aplabwp0368359> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 09:34:15 -0600 Message-Id: <1016638455.24127.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-20 at 09:23, Bas wrote: > Hi, > > The following has happened: > > Today I was editing some files on my / filesystem. I had made some changes > to one of my startup scripts and the configuration file for samba, which are > one the same filesystem. When I tried to look into the logfile directory, > which is a separate lv, I could run ls, but when I ran ls -la, it hung. Only > option was to reboot, but I waited a little, probably enough time to clear > the changes to disk. After a reboot I noticed the files I had changed were > indeed changed, the still had the same size, but were filled with ^@ > characters -> This was visible through vim. Funny thing is that the backup > files vi makes (.rc.samba.swp) were also damaged and not useable anymore. The real culprit here is the fact that your machine locked up - when this happens, there's no telling what data may or may not get down to the disk. The ^@ (null) characters you saw as a result are explained in the FAQ. I have no experience with evms, so I can't say whether that could have been a factor. You might consider compiling kdb into your kernel, so that if it locks up again, you can break into kdb and see what's going on (a simple "bt" command would probably show where things got stuck.) -Eric p.s. the weekly patches were dropped in favor of the "split" patches; it was felt that we had too many patch versions floating around out there. . -- 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 20 07:41:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KFfo131736 for linux-xfs-outgoing; Wed, 20 Mar 2002 07:41:50 -0800 Received: from kendy.up.ac.za (kendy.up.AC.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KFfF931709 for ; Wed, 20 Mar 2002 07:41:15 -0800 Received: from [137.215.109.246] (helo=mx2.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 16niEU-00016U-00 for linux-xfs@oss.sgi.com; Wed, 20 Mar 2002 17:42:34 +0200 Received: from mx1.up.ac.za ([137.215.95.15]) by mx2.up.ac.za with esmtp (Exim 3.12 #1) id 16niET-0004wj-00 for linux-xfs@oss.sgi.com; Wed, 20 Mar 2002 17:42:33 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=it.up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.15 #1) id 16niET-0006iy-00 for linux-xfs@oss.sgi.com; Wed, 20 Mar 2002 17:42:33 +0200 Message-ID: <3C98ADE8.ACDBEF4C@it.up.ac.za> Date: Wed, 20 Mar 2002 17:42:32 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.19-pre2-ac2-xfs-shawn9 i686) X-Accept-Language: en MIME-Version: 1.0 To: XFS mailing list Subject: Re: Kernel oops on new mailserver References: <3C965130.2CAB0A19@it.up.ac.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16niET-0006iy-00*JQrF0kAwkp6* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It struck again. kernel 2.4.18 from cvs checked out on March 14 2002 gcc version 2.95.4 (just to see if it made a difference over egcs-2.91.66) I notice that the process was always 'modprobe' in all of the dumps. I assume that the kernel kicks off the modprobe. There are nothing in the crontabs. The modutils are 2.4.13 that came with debian 3.0 (woody). I had the source for 2.4.11 and compiled and installed it in an attempt to get stability on the server. (I am probably kludging at straws here) I included the output of depmod -v at the end. Maybe it can give someone a clue to what's going wrong. kernel BUG at ll_rw_blk.c:978! invalid operand: 0000 CPU: 1 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 0000001f ebx: cd7d98a0 ecx: c03c1920 edx: 00002ddb esi: 00000000 edi: 00000200 ebp: c7e4dcf0 esp: c7e4dcd4 ds: 0018 es: 0018 ss: 0018 Process modprobe (pid: 19735, stackpage=c7e4d000) Stack: c02f3ea2 000003d2 cd7d98a0 caaec180 cd7d98a0 00001000 00000200 c7e4defc c0136780 00000001 00000001 c7e4dd14 cd7d98a0 00000001 c03c8480 00000000 caaec180 00000000 00000000 c7e4de74 c01907a9 cfd76080 c02e5cd4 c7e4dd44 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 90 8d 74 26 00 46 3b 75 0c 7c ba 8b 55 08 f6 >>EIP; c0213896 <===== Trace; c0136780 Trace; c01907a8 Trace; c01907a8 Trace; c01907a8 Trace; c023f000 Trace; c0136ba6 <__refile_buffer+56/60> Trace; c0136bc8 Trace; c0136af8 <__mark_buffer_dirty+28/30> Trace; c01e4c40 Trace; c01e4f9c <__pb_block_commit_write_async+2c/50> Trace; c01120da Trace; c01d65f2 Trace; c01c318c Trace; c01df3c4 Trace; c01eac9e Trace; c01e3eb0 Trace; c01e6ef2 Trace; c01db540 Trace; c01e6a06 Trace; c0135f66 Trace; c010715a Code; c0213896 00000000 <_EIP>: Code; c0213896 <===== 0: 0f 0b ud2a <===== Code; c0213898 2: 83 c4 08 add $0x8,%esp Code; c021389a 5: 90 nop Code; c021389c 6: 8d 74 26 00 lea 0x0(%esi,1),%esi Code; c02138a0 a: 46 inc %esi Code; c02138a0 b: 3b 75 0c cmp 0xc(%ebp),%esi Code; c02138a4 e: 7c ba jl ffffffca <_EIP+0xffffffca> c0213860 Code; c02138a6 10: 8b 55 08 mov 0x8(%ebp),%edx Code; c02138a8 13: f6 00 00 testb $0x0,(%eax) Entering kdb (current=0xc7e4c000, pid 19735) on processor 1 Oops: invalid operand eax = 0x0000001f ebx = 0xcd7d98a0 ecx = 0xc03c1920 edx = 0x00002ddb [1]kdb> bt EBP EIP Function(args) 0xc7e4dcf0 0xc0213896 ll_rw_block+0x86 (0x1, 0x1, 0xc7e4dd14, 0xcd7d98a0, 0x1) kernel .text 0xc0100000 0xc0213810 0xc0213a00 0xc7e4defc 0xc0136780 fsync_inode_data_buffers+0xb8 (0xcd7d98a0, 0xcd7d9954, 0x0) kernel .text 0xc0100000 0xc01366c8 0xc0136858 0xc7e4df10 0xc01e3eb1 pagebuf_flush+0x19 (0xcd7d98a0, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc01e3e98 0xc01e3ec4 0xc7e4df28 0xc01e6ef3 fs_flush_pages+0x2b (0xcfb78e38, 0x0, 0x0, 0xffffffff, 0xffffffff) kernel .text 0xc0100000 0xc01e6ec8 0xc01e6efc 0xc7e4df64 0xc01db541 xfs_fsync+0xe1 (0xcfb78e38, 0x5, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc01db460 0xc01db760 0xc7e4df90 0xc01e6a06 linvfs_fsync+0x42 (0xcc5b57a0, 0xce38d7a0, 0x1, 0xcd7d9954, 0xc7e4c000) kernel .text 0xc0100000 0xc01e69c4 0xc01e6a14 0xc7e4dfbc 0xc0135f66 sys_fdatasync+0x6a (0x0, 0x8063600, 0xbfffeca0, 0x8063600, 0x4013b6e0) kernel .text 0xc0100000 0xc0135efc 0xc0135fb0 0xc010715b system_call+0x33 kernel .text 0xc0100000 0xc0107128 0xc0107160 [1]kdb> [1]kdb> cpu Currently on cpu 1 Available cpus: 0, 1 [1]kdb> cpu 0 Entering kdb (current=0xcf672000, pid 160) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xcf673d3c 0xc01370db create_empty_buffers+0x5b (0xc117f540, 0x802, 0x1000, 0xc117f540, 0x1aa600) kernel .text 0xc0100000 0xc0137080 0xc01370e8 0xcf673d60 0xc013878b brw_page+0x37 (0x0, 0xc117f540, 0x802, 0xcf673da0, 0x1000) kernel .text 0xc0100000 0xc0138754 0xc0138804 0xcf673dc0 0xc012e21a rw_swap_page_base+0xfa (0x0, 0x1aa600, 0xc117f540, 0xc117f540, 0x0) kernel .text 0xc0100000 0xc012e120 0xc012e22c 0xcf673ddc 0xc012e28f rw_swap_page+0x63 (0x0, 0xc117f540, 0x0, 0x6, 0x8) kernel .text 0xc0100000 0xc012e22c 0xc012e2a8 0xcf673df8 0xc012f258 read_swap_cache_async+0x7c (0x1aa600, 0x1aa300, 0x0, 0xcfec5b40, 0x1aa6) kernel .text 0xc0100000 0xc012f1dc 0xc012f27e 0xcf673e14 0xc0123e9f swapin_readahead+0x3f (0x1aa300, 0xcfec5b40, 0x804dca0, 0x1, 0x1) kernel .text 0xc0100000 0xc0123e60 0xc0123eb0 0xcf673e30 0xc0123edf do_swap_page+0x2f (0xcfec5b40, 0xcf7c7e60, 0x804dca0, 0xcf670134, 0x1aa300) kernel .text 0xc0100000 0xc0123eb0 0xc0123fbc 0xcf673e5c 0xc012431e handle_mm_fault+0x6e (0xcfec5b40, 0xcf7c7e60, 0x804dca0, 0x1, 0xcf672000) kernel .text 0xc0100000 0xc01242b0 0xc0124368 0xcf673f10 0xc01118f9 do_page_fault+0x1a1 (0xcf673f20, 0x2, 0xc0473d00, 0x804dca0, 0xc03c193c) kernel .text 0xc0100000 0xc0111758 0xc0111c3e 0xc010724c error_code+0x34 kernel .text 0xc0100000 0xc0107218 0xc0107254 Interrupt registers: [0]more> eax = 0x00000fff ebx = 0xcf673f20 ecx = 0x00000002 edx = 0xc0473d00 esi = 0x0804dca0 edi = 0xc03c193c esp = 0x00000010 eip = 0x00000018 ebp = 0x00000000 xss = 0x00010246 xcs = 0xffffffff eflags = 0xc011558e xds = 0xcf673f84 xes = 0x00000000 origeax = 0xc03c0018 ®s = 0xcf673f18 Interrupt from user space, end of kernel trace [0]kdb> lsmod Module Size modstruct Used by e100 89752 0xd0850000 1 [0]kdb> Here is the output of depmod -v xftw starting at /lib/modules/boot lstat on /lib/modules/boot failed xftw starting at /lib/modules/2.4.18-xfs-only xftw_readdir /lib/modules/2.4.18-xfs-only pruned build pruned modules.dep pruned modules.generic_string pruned modules.ieee1394map pruned modules.isapnpmap pruned modules.parportmap pruned modules.pcimap pruned modules.pnpbiosmap pruned modules.usbmap type 2 /lib/modules/2.4.18-xfs-only/kernel xftw_readdir /lib/modules/2.4.18-xfs-only/kernel user function /lib/modules/2.4.18-xfs-only/kernel type 2 /lib/modules/2.4.18-xfs-only/kernel/drivers xftw_readdir /lib/modules/2.4.18-xfs-only/kernel/drivers user function /lib/modules/2.4.18-xfs-only/kernel/drivers type 2 /lib/modules/2.4.18-xfs-only/kernel/drivers/net xftw_readdir /lib/modules/2.4.18-xfs-only/kernel/drivers/net user function /lib/modules/2.4.18-xfs-only/kernel/drivers/net user function /lib/modules/2.4.18-xfs-only/kernel/drivers/net/3c59x.o user function /lib/modules/2.4.18-xfs-only/kernel/drivers/net/e100.o user function /lib/modules/2.4.18-xfs-only/kernel/drivers/net/eepro100.o user function /lib/modules/2.4.18-xfs-only/kernel/drivers/net/mii.o user function /lib/modules/2.4.18-xfs-only/kernel/drivers/net/starfire.o type 2 /lib/modules/2.4.18-xfs-only/kernel/fs xftw_readdir /lib/modules/2.4.18-xfs-only/kernel/fs user function /lib/modules/2.4.18-xfs-only/kernel/fs type 2 /lib/modules/2.4.18-xfs-only/kernel/fs/ext2 xftw_readdir /lib/modules/2.4.18-xfs-only/kernel/fs/ext2 user function /lib/modules/2.4.18-xfs-only/kernel/fs/ext2 user function /lib/modules/2.4.18-xfs-only/kernel/fs/ext2/ext2.o type 2 /lib/modules/2.4.18-xfs-only/kernel/fs/ext3 xftw_readdir /lib/modules/2.4.18-xfs-only/kernel/fs/ext3 user function /lib/modules/2.4.18-xfs-only/kernel/fs/ext3 user function /lib/modules/2.4.18-xfs-only/kernel/fs/ext3/ext3.o type 2 /lib/modules/2.4.18-xfs-only/kernel/fs/jbd xftw_readdir /lib/modules/2.4.18-xfs-only/kernel/fs/jbd user function /lib/modules/2.4.18-xfs-only/kernel/fs/jbd user function /lib/modules/2.4.18-xfs-only/kernel/fs/jbd/jbd.o type 2 /lib/modules/2.4.18-xfs-only/kernel/fs/jfs xftw_readdir /lib/modules/2.4.18-xfs-only/kernel/fs/jfs user function /lib/modules/2.4.18-xfs-only/kernel/fs/jfs user function /lib/modules/2.4.18-xfs-only/kernel/fs/jfs/jfs.o type 2 /lib/modules/2.4.18-xfs-only/kernel/fs/reiserfs xftw_readdir /lib/modules/2.4.18-xfs-only/kernel/fs/reiserfs user function /lib/modules/2.4.18-xfs-only/kernel/fs/reiserfs user function /lib/modules/2.4.18-xfs-only/kernel/fs/reiserfs/reiserfs.o type 2 /lib/modules/2.4.18-xfs-only/kernel/fs/xfs xftw_readdir /lib/modules/2.4.18-xfs-only/kernel/fs/xfs user function /lib/modules/2.4.18-xfs-only/kernel/fs/xfs user function /lib/modules/2.4.18-xfs-only/kernel/fs/xfs/xfsidbg.o type 2 /lib/modules/2.4.18-xfs-only/kernel/kdb xftw_readdir /lib/modules/2.4.18-xfs-only/kernel/kdb user function /lib/modules/2.4.18-xfs-only/kernel/kdb type 2 /lib/modules/2.4.18-xfs-only/kernel/kdb/modules xftw_readdir /lib/modules/2.4.18-xfs-only/kernel/kdb/modules user function /lib/modules/2.4.18-xfs-only/kernel/kdb/modules user function /lib/modules/2.4.18-xfs-only/kernel/kdb/modules/kdbm_pg.o user function /lib/modules/2.4.18-xfs-only/kernel/kdb/modules/kdbm_vm.o type 2 /lib/modules/2.4.18-xfs-only/pcmcia xftw_readdir /lib/modules/2.4.18-xfs-only/pcmcia user function /lib/modules/2.4.18-xfs-only/pcmcia xftw starting at /lib/modules/2.4 lstat on /lib/modules/2.4 failed xftw starting at /lib/modules/kernel lstat on /lib/modules/kernel failed xftw starting at /lib/modules/fs lstat on /lib/modules/fs failed xftw starting at /lib/modules/net xftw_readdir /lib/modules/net type 2 /lib/modules/net xftw_readdir /lib/modules/net user function /lib/modules/net xftw starting at /lib/modules/scsi lstat on /lib/modules/scsi failed xftw starting at /lib/modules/block lstat on /lib/modules/block failed xftw starting at /lib/modules/cdrom lstat on /lib/modules/cdrom failed xftw starting at /lib/modules/ipv4 lstat on /lib/modules/ipv4 failed xftw starting at /lib/modules/ipv6 lstat on /lib/modules/ipv6 failed xftw starting at /lib/modules/sound lstat on /lib/modules/sound failed xftw starting at /lib/modules/fc4 lstat on /lib/modules/fc4 failed xftw starting at /lib/modules/video lstat on /lib/modules/video failed xftw starting at /lib/modules/misc lstat on /lib/modules/misc failed xftw starting at /lib/modules/pcmcia lstat on /lib/modules/pcmcia failed xftw starting at /lib/modules/atm lstat on /lib/modules/atm failed xftw starting at /lib/modules/usb lstat on /lib/modules/usb failed xftw starting at /lib/modules/ide lstat on /lib/modules/ide failed xftw starting at /lib/modules/ieee1394 lstat on /lib/modules/ieee1394 failed xftw starting at /lib/modules/mtd lstat on /lib/modules/mtd failed /lib/modules/2.4.18-xfs-only/kernel/drivers/net/3c59x.o /lib/modules/2.4.18-xfs-only/kernel/drivers/net/e100.o /lib/modules/2.4.18-xfs-only/kernel/drivers/net/eepro100.o /lib/modules/2.4.18-xfs-only/kernel/drivers/net/mii.o /lib/modules/2.4.18-xfs-only/kernel/drivers/net/starfire.o /lib/modules/2.4.18-xfs-only/kernel/fs/ext2/ext2.o /lib/modules/2.4.18-xfs-only/kernel/fs/ext3/ext3.o /lib/modules/2.4.18-xfs-only/kernel/fs/jbd/jbd.o /lib/modules/2.4.18-xfs-only/kernel/fs/jfs/jfs.o /lib/modules/2.4.18-xfs-only/kernel/fs/reiserfs/reiserfs.o /lib/modules/2.4.18-xfs-only/kernel/fs/xfs/xfsidbg.o /lib/modules/2.4.18-xfs-only/kernel/kdb/modules/kdbm_pg.o /lib/modules/2.4.18-xfs-only/kernel/kdb/modules/kdbm_vm.o From owner-linux-xfs@oss.sgi.com Wed Mar 20 08:45:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KGj9P00559 for linux-xfs-outgoing; Wed, 20 Mar 2002 08:45:09 -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 g2KGiw900527 for ; Wed, 20 Mar 2002 08:44:58 -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 g2KGkL6G016354 for ; Wed, 20 Mar 2002 08:46:21 -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 KAA50627; Wed, 20 Mar 2002 10:45:01 -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 KAA72061; Wed, 20 Mar 2002 10:45:01 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2KGgi710574; Wed, 20 Mar 2002 10:42:44 -0600 Subject: Re: Kernel oops on new mailserver From: Steve Lord To: Paul Schutte Cc: XFS mailing list In-Reply-To: <3C98ADE8.ACDBEF4C@it.up.ac.za> References: <3C965130.2CAB0A19@it.up.ac.za> <3C98ADE8.ACDBEF4C@it.up.ac.za> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 10:42:43 -0600 Message-Id: <1016642563.28200.113.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-20 at 09:42, Paul Schutte wrote: > It struck again. > > kernel 2.4.18 from cvs checked out on March 14 2002 > gcc version 2.95.4 (just to see if it made a difference over egcs-2.91.66) > > I notice that the process was always 'modprobe' in all of the dumps. > I assume that the kernel kicks off the modprobe. There are nothing in the > crontabs. > The modutils are 2.4.13 that came with debian 3.0 (woody). > > I had the source for 2.4.11 and compiled and installed it in an attempt to > get stability on the server. (I am probably kludging at straws here) > > I included the output of depmod -v at the end. > Maybe it can give someone a clue to what's going wrong. > Well, I just rewrote this code (after the 14th) to clean up a number of problems in this area. Can you possibly try a current cvs tree. If you hit it again it will be in submit_bh this time. Can you run with kdb again, specify y for the KDB modules command. If it should happen again, run the bt command, take the second argument of the submit_bh function and use the bh command on it. Thanks 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 20 08:55:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KGtFe01052 for linux-xfs-outgoing; Wed, 20 Mar 2002 08:55:15 -0800 Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KGt9901024 for ; Wed, 20 Mar 2002 08:55:09 -0800 Received: from taz ([12.92.222.205]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020320165229.NNRL8815.mtiwmhc23.worldnet.att.net@taz>; Wed, 20 Mar 2002 16:52:29 +0000 Date: Wed, 20 Mar 2002 11:46:24 -0500 From: Greg Freemyer Subject: re[2]: TDB corruption with Samba 2.2.3a To: Steve Lord , Martin Apel cc: "ZINKEVICIUS,MATT (HP-Loveland,ex1)" , , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020320165229.NNRL8815.mtiwmhc23.worldnet.att.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2KGtA901025 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, Are you guys back porting to the base 2.4.9 kernel, or to the Redhat patched version? Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com >> However, we are working on pushing current xfs code back >> into a 2.4.9 kernel in rpm format. >> 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 20 08:58:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KGw1B01209 for linux-xfs-outgoing; Wed, 20 Mar 2002 08:58: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 g2KGvt901183 for ; Wed, 20 Mar 2002 08:57:55 -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 g2KGxJ6G016980 for ; Wed, 20 Mar 2002 08:59:19 -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 KAA51166; Wed, 20 Mar 2002 10:57: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 KAA39218; Wed, 20 Mar 2002 10:57:27 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2KGtBh10627; Wed, 20 Mar 2002 10:55:11 -0600 Subject: Re: re[2]: TDB corruption with Samba 2.2.3a From: Steve Lord To: Greg Freemyer Cc: Martin Apel , "ZINKEVICIUS,MATT ""(HP-Loveland,ex1)" , samba-technical@lists.samba.org, linux-xfs@oss.sgi.com In-Reply-To: <20020320165229.NNRL8815.mtiwmhc23.worldnet.att.net@taz> References: <20020320165229.NNRL8815.mtiwmhc23.worldnet.att.net@taz> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 10:55:10 -0600 Message-Id: <1016643310.28200.120.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-20 at 10:46, Greg Freemyer wrote: > Steve, > > Are you guys back porting to the base 2.4.9 kernel, or to the Redhat patched version? > > Latest Redhat 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 20 08:59:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KGx7Y01386 for linux-xfs-outgoing; Wed, 20 Mar 2002 08:59:07 -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 g2KGwj901358 for ; Wed, 20 Mar 2002 08:58:45 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx06)) with ESMTP id A04096109; Wed, 20 Mar 2002 18:00: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 SAA00355; Wed, 20 Mar 2002 18:00:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id DBD3C57306; Wed, 20 Mar 2002 17:59:46 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 42B9025835; Wed, 20 Mar 2002 17:59:46 +0100 (CET) Message-ID: <3C98C002.3F3815F2@ch.sauter-bc.com> Date: Wed, 20 Mar 2002 17:59:46 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Steve Lord Cc: Juri Haberland , Eric Sandeen , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C97591 B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> <3C9760EA.3874D744@ch.sauter-bc.com> <1016554052.4383.4.camel@stout.america s.sgi.com> <3C976ADD.FE0E7CDA@ch.sauter-bc.com> <1016558028.1770.31.camel@jen.americas.sgi.com> <3C978B5E.3040309@koschikode.com> <1016565408.1770.93.camel@jen.americas.sgi.com> <3C979839.5378CCA1@ch.sauter-bc.com> <1016568031.1841.132.camel@jen.americas.sgi.com> Content-Type: multipart/mixed; boundary="------------6A9BC84AA64DDC964AA894C5" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dies ist eine mehrteilige Nachricht im MIME-Format. --------------6A9BC84AA64DDC964AA894C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Lord schrieb: > > On Tue, 2002-03-19 at 13:57, Simon Matter wrote: > > Steve Lord schrieb: > > > > > > On Tue, 2002-03-19 at 13:02, Juri Haberland wrote: > > > > > > > > Ok, when you mentioned the SW RAID1 root partition I remembered that I > > > > have a similar box sitting here. It's also a fresh SGI-RH7.2 > > > > installation with all updates and all partitions are on a SW-RAID1, but > > > > on SCSI disks, not on IDE disks. > > > > > > > > I ran three test like yours (ntsysv (en/disabling time ; reboot)) and > > > > afterwards I still had all files in /etc/xinetd.d with their proper > > > > contents. I also had my .bash_history. > > > > This box runs a 2.4.18-xfs-smp kernel from CVS, checked out on 4th of March. > > > > > > > > Simon > > > > what about a recent kernel? 2.4.9-31 is user contributed IIRC. It might > > > > not be a good choice... > > > > You want me to cry, not a good choice, I have contributed them :-) > > Serious, I'll try a newer kernel as soon as I can. > > We are just trying to eliminate variables here - not blaming your > merging skills. Juri appears to have a similar setup, except he > does not see the problem with a recent kernel. I've just tried to make a joke after a frustrating day... I have checked out 2.4.18-xfs from CVS 8 hours ago. Compiled and tested and I can confirm the problem is gone. Of course I don't know whether the problem comes from the 1001 RedHat patches or the kernel or XFS itself. Now, I can not upgrade all servers to 2.4.18 and even if I could, I didn't have time to test it very well so I have to stick with the RH 2.4.9-31 kernel for now (in production). The solution is to modify the /etc/rc.d/init.d/halt script to call sync several times, BEFORE the umount -a. If I sync just before remounting / ro, it does not help. Would be nice if someone could put this into FAQ since it affects all installaions from the RedHat installer at least on software raid. The patched halt.gz file is attached to this mail. -Simon The patch: ----------------------------------------------------------------------------- --- halt.orig Thu Feb 7 04:03:37 2002 +++ halt Wed Mar 20 17:33:48 2002 @@ -125,6 +125,23 @@ [ -x /sbin/quotaoff ] && runcmd $"Turning off quotas: " /sbin/quotaoff -aug +# Syncing disks, some kernels need this +echo -n $"Syncing disks: " +cnt=10 +while [ $cnt -ne 0 ] +do + cnt=$[ cnt - 1 ] + sync + echo -n "." + sleep 1 +done +if [ "$BOOTUP" = "color" ]; then + echo_success || echo_failure +else + echo -n " done." +fi +echo + # Unmount file systems, killing processes if we have to. # Unmount loopback stuff first remaining=`awk '!/^#/ && $1 ~ /^\/dev\/loop/ && $2 != "/" {print $2}' /proc/mounts` ----------------------------------------------------------------------------- > > Eric is slaving away over rpm build tools even as I type, attempting to > push the latest xfs code into a redhat kernel. > > > > > Just to confirm the IDE thing: I've tried the same on my home server now > > which is SW-RAID1, but on SCSI disks, and it's the same problem. So > > nothing with IDE and nothing with write cache. > > > > What about sync? I'm still wondering whether it's good to have it in > > halt? With my modified halt script the problem seems to go away. > > Doing the sync in there is fine, does no harm at all. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --------------6A9BC84AA64DDC964AA894C5 Content-Type: application/octet-stream; name="halt.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="halt.gz" H4sICBi/mDwAA2hhbHQAtVhrc9NKEv3s+RWN4iI2G0sxFFu1yZpdXwiPIg8q Dvd+uIGLLI9tVSSN0YziZGP2t+/pmZEfeXChti4FiTTqPt3Tfaanm61H0TAt omGsp2JLbFGZhNM4M+T+nE1TTeM0k4Tf8komlZEjGl5TWqSG5lNZEH5PlNRY MYrKqsjkpcwAtPlnl1oM2yZVLoXo79Qq5VAp0w7pnaGLNMs0xVlGs1IlUmup d+4AVUWuqsJ4r/S1NjKHUjEiw97IFL9KYlva2rL4OrR761dmqso9j3SUfq3g xGVc0CBXqpTFsConO/TP3H7Q/x6VaXEhs7DIwryaFNKEqpy8uOPRkRql4xRh GcPe6dsBHaZFdcVBehXnKXw6likCIqA4kIbdpFlspqH40D9724s0wr8X2R+V LlcPvC6EvJqp0tDxyeHJy/7hQa8rQoqkSSJOQDiKxlWRmFQVWgiENclHrTbd CHglk6miTkHNoNmlgFf0NB0bfkjH9DsFzV9OTs4+fgioR0GiMlUG9GnfBlG4 fTWf0OPHFucPXSWcD1os3Ps4TrOqlNZOpuVSgR/GaW1efBOCE/HHRJo/SpnH 8LmYWAcb8fyCth9Frc9bC072IlNqNtaLuDIKv0bycvG5UIVcfD6P8HIelcji gs4jakd0M0NiDDWfftumiLUjRwmPesMbbDWf0X8p+syfmxFvpPmUHvHKuVNp U42yT7dxvrlcSZqqOc0l/paSEhBTjkKRxFoiersBGI+dPrG0Fo0c8YknstcM 3mIB+/TcDMMwEI1E5Tk42gtYGu/7+6zqyb+u/CGTjK8NMxoUmk+Z5k6QQZk9 9wI7kSU0QC0DkP7dPes75ZJiTdv+gG/z6eAXp7hNM2v5ERDkFc501yJJHSfC 8gVUApPWOOLj0PVxoCfwucRm8Oh8YCf4xfvxkXe458rAwu+cbqzSt02jZK2C R8jCe9SEzZIQCibvzS/9wdu/cdX6xgzmB/pk+VrEQ0SMa0l9JGB8IIsRh28D yQbz7OD0iHQ6KeKMI0r23EWsDtnn1Ok+FzqTckbPfwTt/bvDw3W0O3D/4E39 VqZGEsrl3OQzV8iGEtVD1tWNwaPLuLTHhzpzy8f4UlKeXqG6aWlYRO/QlJnJ dSeLkwtSY4qBZAxkZliRoZiUcL3zlYLzlp7FZRJXo1SdLzSsjM7bgec9jliK XbhMN/+FgO5SJ6bOFdnLIa5gt5Pj+OZxtl4lVhGJL9nnTfeC+7Q7Y1e/Qrtc JtQZ+FQProtkjd+UZCq5CEX/9GVvVwxOj/Dz4xk/e0J6IEgnqhink8gqrLsX 3ish+NMWYelSorSqbITjdo0cOH0nytkp5By3Q1YhMKuqefMSlfj90cmrA0u8 4M3R2e3CyV6asvLl8QE9bOu2Hu+01kNIOCpW6dXB614QuOfXh/03g17QXL1Q p8MBU9MkEHVxggf1sbyWesGg9izSgxhVsL8SsAab9SO1KpO03Xd3sAu1GMeo +3+C2UE8uRbm8nvgS6GVCXv+673YQKU+Rpu7ocaDtvvepBe5bRQnoV1L1Aa9 PTDtPnsPmxoA6H4ruszvWFmrIuA7H5ppXI7mcVnzD8TzB8BGzleQ6dx9XbPM Z+asKgsc+zHpeTzbcS2QryEbDVIoBr/1Pwx6X9y9i2vwNb4WcS5xndY3YXd1 ETKc/iJ82be6gauvS/fZNLtfW9+jwP7md6chWP/KbyBOEqOK72BAwJc+RlpX 2sD5WikTs/zDSFZEr1CWKp24mtSVhoVHqb5AEdUKV+OFLAv0Mjj0klvJVItV B7UhD1yRFKbX3RXuckbFxDskJarmJzFSSDgLNH8nu05drKL9AohY9WVByE2Z u1q6UCqk+IG+7LvdmG/FlhaIUWEGhcS2Y9j5x3u4sWMvS97f6i6DK+h7pnzl GBWuKXKfNuS7RpsKER2npTZi2dvV/Io+b7meq0uu5bI9HOsuWzHsLgoebOW+ CGj8/7DdO7Ce0Utoz2p0pLi1e6JRSlNe956JRp3b2+K4FvkdUnieGJvyBnLe aPj01d9wcT9bZq7RaCyp+nF1xy+jyfmoZ5mWRWjvBVS5mK/MA8cm+Sfg+Bjc hwNS4Ac6B8QQ5Y6a6wGnfbJbamQKl3k1s1/pBXHAo6JC2/P0xeMuB+6cpVbO vJImTqYbvrjewiKwLzViZ2SXoG65D4y/gEQA/2to1GiAGf+5h0jDUsYX+Owq z7jS6Ic6F9TJqQmCraWAXiyDCfG6xWx4AjZbLUckNKDtNguAnWgeXbAwn1i2 1mRd2+HdeYsWKHDoczrlFyF+htXMgO9z+rB//Kb3ku6j4sZ0XjMa6a+5iO5t nY6e1T8I+B0gprUL5lPR+OG4/Ek2fy6Zy1zeSqXLpE+kzaNrYi2xhpXG1D+s O3Fn3m9xQ4KrOOwqrszolZOSJ58U80gSG5zmcRZPRJlb4NBN09zxolMAl6CQ 89CyQ7COkUEb22OEoo4lWv4xC59Kt4DtjyCbXVNcXJupG0Bjs60pk2NDVohn 4i0/43k9llvFZqO2gVCAaltkBg6Es7QgezajFs/4G1N/e61DecYdymI5FMM5 3FvSFivusfwuCuooKtVO6XfRZCEXceztGDO9HauW/zsUinpU9nN4sJowxggS y6zuYC97Utj4F/LKkBXgQNOcx9UhiHqRzmaITCD8AGCxVJlIK/ZzYFZv5C5y 8bZ/eNY/5Sa0k6KIrrk6U3NZ2jZH0SO7Yre5tLXSbNaP1Jk5VH/O/f8mcO/h dGltQHGGSjdTVTPN/3JVhDwwOeq4T9xNWF/WF1czGLQ2cem+SQ1Sy4/s2eDg 9NeDU9sUoSf3BYunqcPAVuvjk+MDu2orm/9Qv746+PXdywN/pt1HPsd+3drx 85bEvEd1GGgZJ/E/NtyTVyYVAAA= --------------6A9BC84AA64DDC964AA894C5-- From owner-linux-xfs@oss.sgi.com Wed Mar 20 09:09:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KH9ZC03294 for linux-xfs-outgoing; Wed, 20 Mar 2002 09:09:35 -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 g2KH9V903266 for ; Wed, 20 Mar 2002 09:09:31 -0800 Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7]) 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 JAA08709 for ; Wed, 20 Mar 2002 09:10:53 -0800 (PST) mail_from (rhowe@wiss.co.uk) Received: from os046.sta.man.ac.uk ([130.88.188.46] helo=xiao ident=mail) by curlew.cs.man.ac.uk with esmtp (Exim 2.05 #6) id 16njI4-000PuC-00 for linux-xfs@oss.sgi.com; Wed, 20 Mar 2002 16:50:21 +0000 Received: from rhowe by xiao with local (Exim 3.34 #1 (Debian)) id 16njI2-0000W8-00 for ; Wed, 20 Mar 2002 16:50:18 +0000 Date: Wed, 20 Mar 2002 16:50:18 +0000 To: linux-xfs@oss.sgi.com Subject: Lockups while X is running Message-ID: <20020320165017.GA3454@xiao> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline From: Russell Howe Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I keep getting lockups while X is running (well, I can't remember having any when X wasn't running). My average uptime is under 4-5 days, although that's partially due to CVS updates from the XFS tree. The lockups are happening about 4-6 times per month I guess. Is it possible to use kdb to discover whether the lockups are due to XFS, LVM or something like DRI? Is it possible to get into KDB if I'm in a locked-up X? XFS is performing fine though, thanks for the fs. xfs_fsr is also running fine for me (as far as I know). I run xfs_fsr daily, both on / and my 40G data VG and haven't noticed any fs corruption at all (I'd include the frag -f output if I had the XFS tools installed, but there was a build error last time I tried. They're rebuilding at the moment). The rebuild problem was that debian/rules binary had skipped running configure (or so it seemed - platform_defs.h hadn't been created). Anyway, running configure and debian/rules binary has fixed that. The filesystem gets a reasonable testing here I think. SMP Celeron, serving around 50-100 simultaneous web/FTP connections 24/7, as well as serving as my only PC. Things can get a bit slow sometimes (such that MP3s pause for a while waiting for data off the disk), but that could be anything (old slow IDE drives?). -- Russell Howe rhowe@wiss.co.uk From owner-linux-xfs@oss.sgi.com Wed Mar 20 09:11:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KHBW903434 for linux-xfs-outgoing; Wed, 20 Mar 2002 09:11: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 g2KHBQ903408 for ; Wed, 20 Mar 2002 09:11:26 -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 g2KICoBA015186 for ; Wed, 20 Mar 2002 10:12:50 -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 LAA52167; Wed, 20 Mar 2002 11:11: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 LAA84587; Wed, 20 Mar 2002 11:11:33 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2KH9G410706; Wed, 20 Mar 2002 11:09:16 -0600 Subject: Re: Fragmentation (was: XFS NFS server Oops) From: Steve Lord To: Federico Sevilla III Cc: Linux XFS Mailing List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 11:09:16 -0600 Message-Id: <1016644156.6150.129.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-19 at 19:37, Federico Sevilla III wrote: > On 19 Mar 2002 at 16:47, Steve Lord wrote: > > xfs_db -r /dev/xxx (it can be mounted) > > xfs_db: frag -f > > Cool. (Obviously I never really dug into the xfs_db manpage before to find > stuff like this out.) That seemed harmless so I checked out all my > filesystems. > > I got fragmentation factors from a high of 50.92% (this is a filesystem > where I store huge tar.gz backups and not much else) to a low of 0.43% for > my / filesystem. > > So now I wonder (trivial, really, but this might be FAQ-worthy): > > a. At what fragmentation factor should we start considering running > xfs_fsr? Or should we just go with what the xfs_fsr manpage says and run > it in a crontab weekly? > > b. I remember awhile back that xfs_fsr didn't come very highly > recommended. Is this still the case? Or can we use xfs_fsr on production > systems (during their more idle times, of course) and still be able to > sleep at night? > Probably hold off for now on running fsr. Look at the other numbers on the output. The actual and ideal are more interesting. If you look at these, the difference is the number of extra extents you have above the ideal case. Then ask how much data you have on the disk, dividing by the actual extent number gives you the average length of the extents. It is also possible that most of the fragmentation is restricted to a few files. 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 20 09:14:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KHElE03619 for linux-xfs-outgoing; Wed, 20 Mar 2002 09:14:47 -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 g2KHER903588 for ; Wed, 20 Mar 2002 09:14:27 -0800 Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) 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 JAA05524 for ; Wed, 20 Mar 2002 09:16:01 -0800 (PST) mail_from (i.d.hardy@soton.ac.uk) 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 g2KH7HH00375; Wed, 20 Mar 2002 17:07:17 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 g2KH64g17020; Wed, 20 Mar 2002 17:06:04 GMT Message-ID: <3C98C17C.ED4C4AE4@soton.ac.uk> Date: Wed, 20 Mar 2002 17:06:04 +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, idh@soton.ac.uk Subject: Re: WARNING with regards to running xfs_fsr References: <1016623833.3c9872d96c0a2@webmail.soton.ac.uk> <1016636815.28200.52.camel@jen.americas.sgi.com> <3C98B4CC.52329F55@soton.ac.uk> <1016641429.28166.96.camel@jen.americas.sgi.com> Content-Type: multipart/mixed; boundary="------------4A10D54FA121B8ECAF3A528A" X-MailScanner: Believed to be clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------4A10D54FA121B8ECAF3A528A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit on 20 Mar 2002 10:23:49 -0600: Steve Lord wrote: > > On Wed, 2002-03-20 at 10:11, Ian D. Hardy wrote: > > On Wed, 20 Mar 2002 09:06:55 -0600: Steve Lord wrote: > > > > > > > I suspect that this file grow gradually over a reasonably long computational > > run, hense the OS would tend to deallocate much of the pre-allocated space in > > an extent before it is required hence the high level of fragmentation (if my > > understanding of XFS and the pre-allocation of extents is correct). > > Is this created locally, or via NFS? It is only a 12M file, it should be > a lot less fragmented than that. > All user access to this filesystem is via NFS (this server is the master node to a 170+ node computational cluster). Agreed - 889 extents on a 12M file is a bit excessive! Only myself and a couple of other admins have direct login access to this server/master node. > > OK, once the machine has been up for a while - a few hours use should be > enough, can you send me the output of cat /proc/slabinfo and the free > command. I do have one bugfix which would result in an oops in kfree > which was your original problem. It would take heavy memory pressure to > trigger it - and, I suspect fragmented files. The servers been up for ~5.5hrs now. # free total used free shared buffers cached Mem: 1028664 1018060 10604 0 16612 927256 -/+ buffers/cache: 74192 954472 Swap: 1028120 11396 1016724 (I've attached the slabinfo output - should be easier to read if the mail system doesn't reformat it!). Note, this server is essentially an NFS fileserver (it also runs dhcpd and rsync services to support the booting of the computional nodes in the cluster but this is minimal and is not occuring at the time of the crashes). Therefore the only pressure on memory is from the NFS daemons and the filesystem/buffer caches + std daemons/backup software - Legato Networker). > > Steve (who wishes he had never got out of bed this morning!) ............ know the feeling, won't help you but I'm 6 hours ahead of you so ~ 6hours closer to going back to bed! Thanks Ian -- /////////////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)\ --------------4A10D54FA121B8ECAF3A528A Content-Type: text/plain; charset=us-ascii; name="slabinfo.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="slabinfo.txt" slabinfo - version: 1.1 (statistics) (SMP) kmem_cache 98 98 284 7 7 1 : 98 98 7 0 0 : 124 62 : 28 7 0 0 nfs_write_data 0 0 380 0 0 1 : 10 10 1 1 0 : 124 62 : 1 2 2 0 nfs_read_data 0 0 364 0 0 1 : 100 165 16 16 0 : 124 62 : 125 33 142 0 nfs_page 0 0 96 0 0 1 : 160 432 10 10 0 : 252 126 : 169 21 180 0 xfs_dqtrx 171 171 200 9 9 1 : 285 85521 1202 1193 0 : 252 126 : 159169 4526 162399 92 xfs_dquots 11 22 356 2 2 1 : 22 61 2 0 0 : 124 62 : 7 7 1 0 tcp_tw_bucket 39 40 96 1 1 1 : 120 5060 36 35 0 : 252 126 : 363 168 494 0 tcp_bind_bucket 159 290 24 2 2 1 : 287 16903 2 0 0 : 252 126 : 1261 137 1362 0 tcp_open_request 0 0 64 0 0 1 : 177 2150 35 35 0 : 252 126 : 1358 73 1396 0 inet_peer_cache 53 234 48 3 3 1 : 312 5344 4 1 0 : 252 126 : 281 61 285 0 ip_fib_hash 11 145 24 1 1 1 : 145 145 1 0 0 : 252 126 : 22 3 13 0 ip_dst_cache 400 552 160 23 23 1 : 576 28384 25 2 0 : 252 126 : 2398 277 2373 1 arp_cache 262 288 120 9 9 1 : 288 8252 13 4 0 : 252 126 : 629 107 593 0 blkdev_requests 640 660 88 15 15 1 : 792 792 18 3 0 : 252 126 : 750 36 128 0 xfs_chashlist 1188 1305 24 9 9 1 : 1576 64268 11 2 0 : 252 126 : 3244 530 2699 1 xfs_ili 4066 4077 144 151 151 1 : 4455 124835 291 140 0 : 252 126 : 10940 1848 8522 35 xfs_ifork 0 0 64 0 0 1 : 0 0 0 0 0 : 252 126 : 0 0 0 0 xfs_efi_item 56 56 268 4 4 1 : 140 28659 617 613 0 : 124 62 : 35869 2534 37780 5 xfs_efd_item 56 56 268 4 4 1 : 140 32079 554 550 0 : 124 62 : 35883 2457 37779 6 xfs_buf_item 175 175 156 7 7 1 : 350 193760 355 348 0 : 252 126 : 168345 3082 171059 3 xfs_dabuf 145 145 24 1 1 1 : 145 188712 420 419 0 : 252 126 : 411426 2857 413863 0 xfs_da_state 11 22 348 1 2 1 : 44 14312 810 808 0 : 124 62 : 37951 2083 39224 0 xfs_trans 133 133 584 19 19 1 : 168 105512 2451 2432 0 : 124 62 : 301704 7958 306498 710 xfs_inode 10692 10692 444 1188 1188 1 : 16245 76912 3890 2702 0 : 124 62 : 34678 9029 28750 394 xfs_btree_cur 52 52 148 2 2 1 : 104 62935 1364 1362 0 : 252 126 : 182332 3690 184658 0 xfs_bmap_free_item 145 145 24 1 1 1 : 145 169652 356 355 0 : 252 126 : 36622 2369 38635 0 page_buf_t 210 210 188 10 10 1 : 399 326361 329 319 0 : 252 126 : 962344 4262 966213 29 page_buf_reg_t 1 113 32 1 1 1 : 113 113 1 0 0 : 252 126 : 0 2 0 0 avl_object_t 1 113 32 1 1 1 : 113 113 1 0 0 : 252 126 : 0 2 0 0 avl_entry_t 302 378 28 3 3 1 : 504 432732 6 3 0 : 252 126 : 949692 3511 953132 33 dnotify cache 0 0 28 0 0 1 : 0 0 0 0 0 : 252 126 : 0 0 0 0 file lock cache 156 156 100 4 4 1 : 156 48521 34 30 0 : 252 126 : 64843 528 65323 0 fasync cache 0 0 24 0 0 1 : 0 0 0 0 0 : 252 126 : 0 0 0 0 uid_cache 6 226 32 2 2 1 : 226 982 2 0 0 : 252 126 : 6 10 8 0 skbuff_head_cache 722 792 164 33 33 1 : 888 1486979 51 18 0 : 252 126 : 2186779 12117 2190604 7823 sock 180 180 832 20 20 2 : 198 2488 98 78 0 : 124 62 : 16435 384 16557 0 sigqueue 21 56 140 2 2 1 : 168 15648 115 113 0 : 252 126 : 9159 746 9788 0 cdev_cache 15 234 48 3 3 1 : 1950 2434 25 22 0 : 252 126 : 1831 55 1835 11 bdev_cache 11 118 64 2 2 1 : 118 118 2 0 0 : 252 126 : 18 4 9 0 mnt_cache 33 112 68 2 2 1 : 112 112 2 0 0 : 252 126 : 27 3 0 0 inode_cache 11784 11784 492 1473 1473 1 : 43288 188656 7258 307 0 : 124 62 : 126056 16912 123171 777 dentry_cache 8745 8745 116 265 265 1 : 45705 475422 1720 24 0 : 252 126 : 144528 6893 140749 437 dquot 0 0 128 0 0 1 : 0 0 0 0 0 : 252 126 : 0 0 0 0 filp 746 782 112 23 23 1 : 782 879 23 0 0 : 252 126 : 721 48 0 0 names_cache 2 2 4096 2 2 1 : 12 922 609 607 0 : 60 30 : 1948860 1389 1949640 0 buffer_head 239415 240093 104 6485 6489 1 : 973951 6712159 41536 35047 0 : 252 126 : 8699722 124284 8499867 43524 mm_struct 181 189 144 7 7 1 : 189 31135 34 27 0 : 252 126 : 3910 384 4204 0 vm_area_struct 1300 1300 76 26 26 1 : 1500 72363 57 31 0 : 252 126 : 182876 797 182461 37 fs_cache 181 252 44 3 3 1 : 252 38257 3 0 0 : 252 126 : 3958 357 4258 0 files_cache 99 99 424 11 11 1 : 162 9748 127 116 0 : 124 62 : 3957 482 4258 0 signal_act 117 117 1312 39 39 1 : 159 2241 177 138 0 : 60 30 : 3904 587 4204 2 size-131072(DMA) 0 0 131072 0 0 32 : 0 0 0 0 0 : 0 0 : 0 0 0 0 size-131072 0 0 131072 0 0 32 : 0 0 0 0 0 : 0 0 : 0 0 0 0 size-65536(DMA) 0 0 65536 0 0 16 : 0 0 0 0 0 : 0 0 : 0 0 0 0 size-65536 3 3 65536 3 3 16 : 3 3 3 0 0 : 0 0 : 0 0 0 0 size-32768(DMA) 0 0 32768 0 0 8 : 0 0 0 0 0 : 0 0 : 0 0 0 0 size-32768 0 0 32768 0 0 8 : 0 0 0 0 0 : 0 0 : 0 0 0 0 size-16384(DMA) 0 0 16384 0 0 4 : 0 0 0 0 0 : 0 0 : 0 0 0 0 size-16384 50 51 16384 50 51 4 : 58 1894255 2533 2482 0 : 0 0 : 0 0 0 0 size-8192(DMA) 0 0 8192 0 0 2 : 0 0 0 0 0 : 0 0 : 0 0 0 0 size-8192 17 18 8192 17 18 2 : 45 39499 999 981 0 : 0 0 : 0 0 0 0 size-4096(DMA) 0 0 4096 0 0 1 : 0 0 0 0 0 : 60 30 : 0 0 0 0 size-4096 438 498 4096 438 498 1 : 683 7150152 77280 76782 0 : 60 30 : 12340730 391471 12419436 235115 size-2048(DMA) 2 2 2048 1 1 1 : 2 2 1 0 0 : 60 30 : 1 2 0 0 size-2048 760 760 2048 380 380 1 : 804 772396 7195 6815 0 : 60 30 : 2677371 40959 2685838 24607 size-1024(DMA) 0 0 1024 0 0 1 : 0 0 0 0 0 : 124 62 : 0 0 0 0 size-1024 480 480 1024 120 120 1 : 524 43435 616 496 0 : 124 62 : 54523 2676 56215 0 size-512(DMA) 0 0 512 0 0 1 : 0 0 0 0 0 : 124 62 : 0 0 0 0 size-512 656 656 512 82 82 1 : 680 295376 696 614 0 : 124 62 : 2197760 7471 2203070 960 size-256(DMA) 0 0 264 0 0 1 : 0 0 0 0 0 : 124 62 : 0 0 0 0 size-256 210 210 264 14 14 1 : 345 257909 55 41 0 : 124 62 : 323397 4409 327510 164 size-128(DMA) 4 28 136 1 1 1 : 28 28 1 0 0 : 252 126 : 3 2 0 0 size-128 2078 2100 136 75 75 1 : 2100 711569 75 0 0 : 252 126 : 4024428 5833 4028521 150 size-64(DMA) 0 0 72 0 0 1 : 0 0 0 0 0 : 252 126 : 0 0 0 0 size-64 832 1166 72 22 22 1 : 1643 156683 35 13 0 : 252 126 : 21280 1444 22116 1 size-32(DMA) 0 0 40 0 0 1 : 0 0 0 0 0 : 252 126 : 0 0 0 0 size-32 4934 5612 40 61 61 1 : 7360 554828 127 66 0 : 252 126 : 451465 4627 451193 152 --------------4A10D54FA121B8ECAF3A528A-- From owner-linux-xfs@oss.sgi.com Wed Mar 20 09:19:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KHJl203866 for linux-xfs-outgoing; Wed, 20 Mar 2002 09:19: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 g2KHJg903840 for ; Wed, 20 Mar 2002 09:19: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 g2KHL56G018108 for ; Wed, 20 Mar 2002 09:21:06 -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 LAA52075; Wed, 20 Mar 2002 11:19:50 -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 LAA49421; Wed, 20 Mar 2002 11:19:50 -0600 (CST) Subject: Re: Lockups while X is running From: Eric Sandeen To: Russell Howe Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020320165017.GA3454@xiao> References: <20020320165017.GA3454@xiao> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 11:19:50 -0600 Message-Id: <1016644790.24161.35.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk /On Wed, 2002-03-20 at 10:50, Russell Howe wrote: > I keep getting lockups while X is running (well, I can't remember having > any when X wasn't running). My average uptime is under 4-5 days, > although that's partially due to CVS updates from the XFS tree. The > lockups are happening about 4-6 times per month I guess. > > Is it possible to use kdb to discover whether the lockups are due to > XFS, LVM or something like DRI? Is it possible to get into KDB if I'm in > a locked-up X? If the machine locks up while X is running, you really need kdb on a serial console to use it, unfortunately. A palm pilot will work, if you have one. :) If you can still get to a text console, though, do that and then enter kdb and you should be ok. I would be surprised if a locked up X has anything to do with the xfs filesystem. For a while I had an X installation that was perfectly happy to lock up on it's own. :) -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 20 09:57:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KHvBL04778 for linux-xfs-outgoing; Wed, 20 Mar 2002 09:57:11 -0800 Received: from mail.websolut.net (a213-22-31-179.netcabo.pt [213.22.31.179]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KHv5904752 for ; Wed, 20 Mar 2002 09:57:05 -0800 Received: (from daniel@localhost) by mail.websolut.net (8.11.6/8.11.0) id g2KHxf024882; Wed, 20 Mar 2002 17:59:41 GMT X-Authentication-Warning: dellinux.websolut.net: daniel set sender to daniel@websolut.net using -f Subject: Re: Corrupted files on 2.4.18. From: Daniel Fonseca To: linux-xfs@oss.sgi.com In-Reply-To: <1016638455.24127.3.camel@stout.americas.sgi.com> References: <004701c1d023$2623fcd0$3b00a8c0@aplabwp0368359> <1016638455.24127.3.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 20 Mar 2002 17:59:41 +0000 Message-Id: <1016647181.23989.153.camel@dellinux> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric! Don't you think that this is a major nuisance? I mean, I am very glad with XFS on the server level, but at my home machine I have ext3 and xfs (using, testing and comparison purposes) and everytime there's a hard reset (too many times lately, unfortunately) only the files on the xfs partition get this "screwed". Ext3 truncates (or whatever) them, but loosing the whole files is very bad on the user's point of view - configuration files, for example, drove my client applications mad to the point that I removed xfs completely, to avoid this. Enabling and pressing the Magic SysRq key and flushing out is not a clean solution, IMHO. I seem to remember this being a bug reported some time ago, and thought it was corrected, though. It's never enough to say how great your job has been for all of us! Cheers, Daniel On Wed, 2002-03-20 at 15:34, Eric Sandeen wrote: > The real culprit here is the fact that your machine locked up - when > this happens, there's no telling what data may or may not get down to > the disk. > > The ^@ (null) characters you saw as a result are explained in the FAQ. > From owner-linux-xfs@oss.sgi.com Wed Mar 20 10:23:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KINcJ05424 for linux-xfs-outgoing; Wed, 20 Mar 2002 10:23:38 -0800 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KINK905395 for ; Wed, 20 Mar 2002 10:23:20 -0800 Received: from warp9.koschikode.com (pD9517F82.dip.t-dialin.net [217.81.127.130]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 17048F4D9; Wed, 20 Mar 2002 19:24:43 +0100 (CET) Received: from koschikode.com (kaplah.koschikode.com [192.168.200.15]) by warp9.koschikode.com (Postfix) with ESMTP id 041C8A9; Wed, 20 Mar 2002 19:24:29 +0100 (CET) Message-ID: <3C98D3DC.3070107@koschikode.com> Date: Wed, 20 Mar 2002 19:24:28 +0100 From: Juri Haberland Organization: totally unorganized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020305 X-Accept-Language: de-DE, en MIME-Version: 1.0 To: Simon Matter Cc: Steve Lord , Eric Sandeen , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C97591 B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> <3C9760EA.3874D744@ch.sauter-bc.com> <1016554052.4383.4.camel@stout.america s.sgi.com> <3C976ADD.FE0E7CDA@ch.sauter-bc.com> <1016558028.1770.31.camel@jen.americas.sgi.com> <3C978B5E.3040309@koschikode.com> <1016565408.1770.93.camel@jen.americas.sgi.com> <3C979839.5378CCA1@ch.sauter-bc.com> <1016568031.1841.132.camel@jen.americas.sgi.com> <3C98C002.3F3815F2@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: > Steve Lord schrieb: >> >> On Tue, 2002-03-19 at 13:57, Simon Matter wrote: >> > Steve Lord schrieb: >> > > >> > > On Tue, 2002-03-19 at 13:02, Juri Haberland wrote: >> > > > Simon >> > > > what about a recent kernel? 2.4.9-31 is user contributed IIRC. It might >> > > > not be a good choice... >> > >> > You want me to cry, not a good choice, I have contributed them :-) >> > Serious, I'll try a newer kernel as soon as I can. >> >> We are just trying to eliminate variables here - not blaming your >> merging skills. Juri appears to have a similar setup, except he >> does not see the problem with a recent kernel. > > I've just tried to make a joke after a frustrating day... I thought about checking who contributed this kernel RPMS before sending that mail but was to lazy ;) > I have checked out 2.4.18-xfs from CVS 8 hours ago. Compiled and tested > and I can confirm the problem is gone. Of course I don't know whether > the problem comes from the 1001 RedHat patches or the kernel or XFS > itself. > > Now, I can not upgrade all servers to 2.4.18 and even if I could, I > didn't have time to test it very well so I have to stick with the RH > 2.4.9-31 kernel for now (in production). The solution is to modify the > /etc/rc.d/init.d/halt script to call sync several times, BEFORE the > umount -a. If I sync just before remounting / ro, it does not help. I'm not convinced that 'sync' is the solution. As I can see from your script you do a loop with several 'sync; sleep 1'. Maybe a 'sleep 30' - as you tested successfully in another mail - would be sufficiant... > Would be nice if someone could put this into FAQ since it affects all > installaions from the RedHat installer at least on software raid. Are you sure anbout that? Is it really happening with a stock installation without *any* kernel upgrade? If I find the time during the weekend I will do some tests with the latest official SGI kernel release as well as with all following contributed kernels. Maybe we can narrow it down to a specific release... Juri From owner-linux-xfs@oss.sgi.com Wed Mar 20 10:31:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KIVXR05650 for linux-xfs-outgoing; Wed, 20 Mar 2002 10:31:33 -0800 Received: from roujin.gargoylecc.com (roujin.gargoylecc.com [65.100.85.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KIVO905616 for ; Wed, 20 Mar 2002 10:31:24 -0800 Received: from ringram by roujin.gargoylecc.com with local (Exim 3.34 #1) id 16nkt5-00065h-00 for linux-xfs@oss.sgi.com; Wed, 20 Mar 2002 11:32:39 -0700 Date: Wed, 20 Mar 2002 11:32:39 -0700 To: linux-xfs@oss.sgi.com Subject: Re: WARNING with regards to running xfs_fsr Message-ID: <20020320183239.GA23378@roujin.gargoylecc.com> References: <1016623833.3c9872d96c0a2@webmail.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1016623833.3c9872d96c0a2@webmail.soton.ac.uk> User-Agent: Mutt/1.3.27i From: Russel Ingram X-Scanner: exiscan *16nkt5-00065h-00*8qGTI/1AzeU* http://duncanthrax.net/exiscan/ Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 20, 2002 at 11:30:33AM +0000, Ian Hardy wrote: > I note that my exchange of emails with Steve Lord yesterday > "Re: XFS NFS server Oops" with regards to checking for > fragmentation and reducing fragmentation using 'xfs_fsr' has > generated a followup thread "Re: Fragmentation (was: XFS NFS > server Oops)" and some interest in deframenting XFS file systems. > > I'd recommend that you DON'T all rush to run 'xfs_fsr', at least > until we've got some more feedback/info from the XFS experts > at SGI. As advised I ran 'xfs_fsr' last night, it had completed > when I got into work in the morning, so I ran 'xfs_db' in order > to check fragmentation levels again: > > # xfs_db -r /dev/md0 > xfs_db: frag -f > Segmentation fault (core dumped) > > Whats more it then shutdown the filesystem (from 'messages'): > > Mar 20 09:30:17 blue00 kernel: xfs_force_shutdown(md(9,0),0x8) called from line > 1039 of file xfs_trans.c. Return address = 0xc01e2179 > Mar 20 09:30:17 blue00 kernel: Corruption of in-memory data detected. Shutting > down filesystem: md(9,0) > Mar 20 09:30:17 blue00 kernel: Please umount the filesystem, and rectify the > problem(s) > > I rebooted the server and ran 'xfs_check' on the filesystem that showed > a number of errors, which 'xfs_repair' fixed (I'll post some more details > shortly). > > While its (very) possible that the above problem was due to underlying > problems with my filesystem, it is also possible that 'xfs_fsr' had > some bad effect on the filesystem. Worth getting some feedback from the > XFS experts before too many people rush to run 'xfs_fsr' !? > > By the way I seem to remember a lot of SGI Irix users (including me) had > various problems with 'xfs_fsr' when SGI first introduced it (or enabled > its default running from cron) under Irix a few years ago. I believe > these problems where fixed, however, I still don't routinely run > 'xfs_fsr' on my Irix servers. > > > Ian > > /////////////Technical Coordination, Research Services//////////////////// > Ian Hardy > 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)\ > Just my $0.02 worth on the subject of safety of xfs_fsr: I have been running xfs_fsr from cron (just like on my Irix systems) ever since I discovered it back in November with no problems whatsoever. I have aprox. 10 Linux systems set up this way. Russ -- Russel H. Ingram Gargoyle Computer Consulting (307)742-1361 or (307)760-1317 www.gargoylecc.com From owner-linux-xfs@oss.sgi.com Wed Mar 20 10:31:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KIVgl05734 for linux-xfs-outgoing; Wed, 20 Mar 2002 10:31:42 -0800 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KIVQ905644 for ; Wed, 20 Mar 2002 10:31:27 -0800 Received: from warp9.koschikode.com (pD9517F82.dip.t-dialin.net [217.81.127.130]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 7F615F4D9 for ; Wed, 20 Mar 2002 19:32:52 +0100 (CET) Received: from koschikode.com (kaplah.koschikode.com [192.168.200.15]) by warp9.koschikode.com (Postfix) with ESMTP id 7BACCA9 for ; Wed, 20 Mar 2002 19:32:42 +0100 (CET) Message-ID: <3C98D5CA.6040502@koschikode.com> Date: Wed, 20 Mar 2002 19:32:42 +0100 From: Juri Haberland Organization: totally unorganized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020305 X-Accept-Language: de-DE, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Corrupted files on 2.4.18. References: <004701c1d023$2623fcd0$3b00a8c0@aplabwp0368359> <1016638455.24127.3.camel@stout.americas.sgi.com> <1016647181.23989.153.camel@dellinux> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Daniel Fonseca wrote: > Hi Eric! > > Don't you think that this is a major nuisance? I mean, I am very glad > with XFS on the server level, but at my home machine I have ext3 and xfs > (using, testing and comparison purposes) and everytime there's a hard > reset (too many times lately, unfortunately) only the files on the xfs > partition get this "screwed". Ext3 truncates (or whatever) them, but > loosing the whole files is very bad on the user's point of view - > configuration files, for example, drove my client applications mad to > the point that I removed xfs completely, to avoid this. Enabling and > pressing the Magic SysRq key and flushing out is not a clean solution, > IMHO. > > I seem to remember this being a bug reported some time ago, and thought > it was corrected, though. Hmm, hmm, IMO it's not a bug, but a feature ;) If you want your data reliable on disk mount it -osync. That's what I do on partitions where I won't risk running into this "zero"-issue. Oh well, I think we all are a bit pampered (right word? please correct me) by ext3 :-) > It's never enough to say how great your job has been for all of us! Yes, indeed! Juri From owner-linux-xfs@oss.sgi.com Wed Mar 20 10:33:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KIXv105930 for linux-xfs-outgoing; Wed, 20 Mar 2002 10:33:57 -0800 Received: from c000.snv.cp.net (c000-h002.c000.snv.cp.net [209.228.32.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KIXo905903 for ; Wed, 20 Mar 2002 10:33:50 -0800 Received: (cpmta 11239 invoked from network); 20 Mar 2002 10:35:13 -0800 Received: from 207.207.51.226 (HELO filecabinet.amoa.org) by smtp.tooley.com (209.228.32.66) with SMTP; 20 Mar 2002 10:35:13 -0800 X-Sent: 20 Mar 2002 18:35:13 GMT Subject: Re: kernel RPMs From: Chris Tooley To: Simon Matter Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C982DBE.65EC9E7@ch.sauter-bc.com> References: <1016576625.22143.85.camel@filecabinet.amoa.org> <3C982DBE.65EC9E7@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 18:35:13 +0000 Message-Id: <1016649313.9948.17.camel@filecabinet.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-20 at 06:35, Simon Matter wrote: > Chris Tooley schrieb: > > > > I don't know if anyone is interested, but I found myself in a situation > > where I had to set up a PPTP server on a linux box (PoPToP) to > > authenticate Windows clients. This meant that I had get mppe into the > > kernel ppp that comes built into the RedHat contributed kernel. I ended > > up getting everything set up right and have RPMs built with it. The > > only difference between the 2.4.9-31 kernels that are in the > > contributed-by-redhat directory and is the ppp difference. This doesn't > > break using ppp normally it just adds the ability to use ppp-mppe. If > > anyone would like a copy of these kernels they can be made available. > > > > Chris Tooley > > I might be interested one day but when this day comes, it'll be far too > late for the 2.4.9-31 kernel. IIRC the problem with mppe is that for > some reason RedHat can not include it in their kernel. It is a licence > thing or an export problem, isn't it? mppe uses openssl so there may have been some export restrictions but I thought most of those were lifted. Not sure though. The mppe module (when modprobed) does get a warning about tainting the kernel. Don't know how to go about making that social problem go away. > I have contributed the 2.4.9-31 RPMs and the goal was to have exactly > the same kernel like original RedHat 2.4.9-31 but with only XFS and kdb > included. Could you send me the .spec and patches anyway? > I didn't do a whole lot of work to get it going. I took the kernel-2.4.9-31mppe SRPM from mirrors.binarix.com/ppp-mppe, installed it, took the kernel-2.4.9-31SGI_XFS_1.0.2 SRPM and installed it, (noting that it installes on top of the mppe kernel) and added like five lines to the .spec to include the differences between kernel-2.4.9-31mppe.spec and kernel-2.4.9-31SGI_XFS_1.0.2.spec (which was not much). The patch that is used is: http://mirror.binarix.com/ppp-mppe/linux-2.4.16-openssl-0.9.6b-mppe.patch.gz and the .spec file is: http://www.thetooleys.org/pptp/kernel-2.4.9-31-RH-xfs.spec Let me know if you have concerns over issues that you see with it. The kernel name doesn't reflect the mppe patch at all, as changing the kernel name broke a bunch of my kernel modules. This is something that I would expect most people will have problems with and it seems a very minor change in the long run, but the file names probably ought to reflect a difference. Chris Tooley From owner-linux-xfs@oss.sgi.com Wed Mar 20 10:38:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KIcMT06103 for linux-xfs-outgoing; Wed, 20 Mar 2002 10:38:22 -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 g2KIcC906077 for ; Wed, 20 Mar 2002 10:38: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 g2KIda6G023589 for ; Wed, 20 Mar 2002 10:39:36 -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 MAA53489; Wed, 20 Mar 2002 12:38:20 -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 MAA67478; Wed, 20 Mar 2002 12:38:19 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id MAA10617; Wed, 20 Mar 2002 12:38:19 -0600 (CST) Message-Id: <200203201838.MAA10617@slobber.americas.sgi.com> To: "Hundstad, Jeffrey E." cc: linux-xfs@oss.sgi.com, "Nathan Scott" , "Vincent Bernat" Subject: Re: --enable-shared=no gives linking errors Was: New tarball error Date: Wed, 20 Mar 2002 12:38:18 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "Hundstad, Jeffrey E." >In http://marc.theaimsgroup.com/?l=linux-xfs&m=99780529714933&w=2 and http://m >arc.theaimsgroup.com/?l=linux-xfs&m=99784007628575&w=2 in Aug, 2001 there is a > reference to a problem with linking when configuring with --enable-shared=no. > This problem still exists. > >If I modify include/builddefs.in in acl, attr and xfsprogs to change all insta >nces of "lai" to "la" the "make install-dev" works to installs the libraries. > You still have to manually link all of the binaries. For example: > >gcc -o chacl chacl.o ../libacl/.libs/libacl.al /usr/lib/libattr.al > >It looks like the makefiles are a bit munged up... but it also looks like a si >mple fix. If the ".al" files were ".a" files then the linker would be able to > find them with "-l attr" like the makefile now reads. The makefiles in the acl and attr dirs were changed recently to add the install-lib goal, and this is missing a part (INSTALL_LTLIB is not defined in static-only builds) for static-only builds. However, that's not surprising because . . . We also need to update the steps in the INSTALL_LTLIB_STATIC variable, to find the libtool lib file (the text file). Libtool doesn't give us a .lai file for static builds. Apparently we've never had this working. I'm going to leave the first problem for Nathan, because he accepted the install-lib patch :) and I figure the second can be cleaned up in the same fix....ah, delegation. To recap a libtool build, here's what you see. This is what you have to work with: static-only, you get: libattr/libattr.la - libtool lib file (shell variables) libattr/.libs/libattr.al - ar archive libattr/.libs/libattr.la - symlink to the libtool lib file And dynamic&static you get: libattr/libattr.la - libtool lib file libattr/.libs/libattr.a - ar archive libattr/.libs/libattr.la - symlink to above libtool lib file libattr/.libs/libattr.lai - copy of libtool lib file libattr/.libs/libattr.so* We probably keyed off the .lai suffix in builddefs.in because libtool was doing that. I don't remember, and it's too painful to go back and try it. We've never had a use for a static-only build, so it's not surprising we overlooked this. The shared libs are the reason that we went with the libtool build--we needed those. Then we couldn't use libtool for the install stage because it doesn't have the concept of a runtime install versus a development install (attr-.rpm vs. attr-devel-.rpm). Personally, I think the libtool developers were on drugs. >The reason I started down the statically linked road in the first place was >because the "autoconf;./configure;make;make install;make install-dev" fails to >produce binaries and libraries, and does produce errors. So as far as I can >tell you have to munge the build in any case. Well, you weren't accurate here. It does produce binaries and libraries--you just overlooked the step to install the libraries. This, no doubt, is what you saw, and what you should have included in your mail: $ /usr/bin/attr /usr/bin/attr: error while loading shared libraries: libattr.so.1: cannot load shared object file: No such file or directory Dean From owner-linux-xfs@oss.sgi.com Wed Mar 20 10:41:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KIfrb06261 for linux-xfs-outgoing; Wed, 20 Mar 2002 10:41:53 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KIfl906235 for ; Wed, 20 Mar 2002 10:41:47 -0800 Received: (qmail 18955 invoked by uid 500); 20 Mar 2002 18:42:39 -0000 Subject: Re: Corrupted files on 2.4.18. From: Austin Gonyou To: Juri Haberland Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C98D5CA.6040502@koschikode.com> References: <3C98D5CA.6040502@koschikode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 20 Mar 2002 12:42:39 -0600 Message-Id: <1016649759.18768.8.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk does anyone know how much speed is lost by osync? On Wed, 2002-03-20 at 12:32, Juri Haberland wrote: > Daniel Fonseca wrote: > > Hi Eric! > > > > Don't you think that this is a major nuisance? I mean, I am very glad > > with XFS on the server level, but at my home machine I have ext3 and > xfs > > (using, testing and comparison purposes) and everytime there's a hard > > reset (too many times lately, unfortunately) only the files on the xfs > > partition get this "screwed". Ext3 truncates (or whatever) them, but > > loosing the whole files is very bad on the user's point of view - > > configuration files, for example, drove my client applications mad to > > the point that I removed xfs completely, to avoid this. Enabling and > > pressing the Magic SysRq key and flushing out is not a clean solution, > > IMHO. > > > > I seem to remember this being a bug reported some time ago, and > thought > > it was corrected, though. > > Hmm, hmm, IMO it's not a bug, but a feature ;) If you want your data > reliable on disk mount it -osync. That's what I do on partitions where I > won't risk running into this "zero"-issue. Oh well, I think we all are a > bit pampered (right word? please correct me) by ext3 :-) > > > It's never enough to say how great your job has been for all of us! > > Yes, indeed! > > Juri -- 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 20 10:45:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KIjlc06427 for linux-xfs-outgoing; Wed, 20 Mar 2002 10:45: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 g2KIjg906401 for ; Wed, 20 Mar 2002 10:45: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 g2KIl66G024272 for ; Wed, 20 Mar 2002 10:47:06 -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 MAA51748; Wed, 20 Mar 2002 12:45:51 -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 MAA57016; Wed, 20 Mar 2002 12:45:51 -0600 (CST) Subject: Re: Corrupted files on 2.4.18. From: Eric Sandeen To: Daniel Fonseca Cc: linux-xfs@oss.sgi.com In-Reply-To: <1016647181.23989.153.camel@dellinux> References: <004701c1d023$2623fcd0$3b00a8c0@aplabwp0368359> <1016638455.24127.3.camel@stout.americas.sgi.com> <1016647181.23989.153.camel@dellinux> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 12:45:51 -0600 Message-Id: <1016649951.24344.43.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-20 at 11:59, Daniel Fonseca wrote: > Hi Eric! > > Don't you think that this is a major nuisance? I mean, I am very glad > with XFS on the server level, but at my home machine I have ext3 and xfs > (using, testing and comparison purposes) and everytime there's a hard > reset (too many times lately, unfortunately) only the files on the xfs > partition get this "screwed". Yes, it was a hassle. More recent kernels have done away with a lot of this problem, though - you might give it a shot. However, I keep chanting it like a mantra... flip the power switch, and you're eventually going to lose something, no matter what FS you're using. -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 20 10:56:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KIurL06720 for linux-xfs-outgoing; Wed, 20 Mar 2002 10:56:53 -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 g2KIuf906691 for ; Wed, 20 Mar 2002 10:56:41 -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 g2KJw5BA023209 for ; Wed, 20 Mar 2002 11:58:05 -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 MAA54489; Wed, 20 Mar 2002 12:56:49 -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 MAA74909; Wed, 20 Mar 2002 12:56:49 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2KIsVK10872; Wed, 20 Mar 2002 12:54:31 -0600 Subject: Re: kmem_alloc() issues From: Steve Lord To: "Mr. Fiddlehead" Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020308225425.99525.qmail@web11003.mail.yahoo.com> References: <20020308225425.99525.qmail@web11003.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 12:54:31 -0600 Message-Id: <1016650471.28166.232.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-03-08 at 16:54, Mr. Fiddlehead wrote: > 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. I think this will fix that problem: *** 155,164 **** void kmem_free(void *ptr, size_t size) { ! if (MAX_SLAB_SIZE < size){ ! vfree(ptr); ! } else { kfree(ptr); } } --- 155,165 ---- void kmem_free(void *ptr, size_t size) { ! struct page *p = virt_to_page(ptr); ! if (VALID_PAGE(p) && PageSlab(p)) { kfree(ptr); + } else { + vfree(ptr); } } > > 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() KM_SLEEP_IO is gone in recent kernels. > > 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 will try this here for a while. > > 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. hmm, there might be better things to do than this, possibly calling free_more_memory(). > > 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. Thanks, 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 20 10:57:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KIv9Q06847 for linux-xfs-outgoing; Wed, 20 Mar 2002 10:57:09 -0800 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KIus906738 for ; Wed, 20 Mar 2002 10:56:54 -0800 Received: from warp9.koschikode.com (pD9517F82.dip.t-dialin.net [217.81.127.130]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 6B543F4D9; Wed, 20 Mar 2002 19:58:18 +0100 (CET) Received: from koschikode.com (kaplah.koschikode.com [192.168.200.15]) by warp9.koschikode.com (Postfix) with ESMTP id 3D673A9; Wed, 20 Mar 2002 19:58:06 +0100 (CET) Message-ID: <3C98DBBD.1080300@koschikode.com> Date: Wed, 20 Mar 2002 19:58:05 +0100 From: Juri Haberland Organization: totally unorganized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020305 X-Accept-Language: de-DE, en MIME-Version: 1.0 To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: Corrupted files on 2.4.18. References: <3C98D5CA.6040502@koschikode.com> <1016649759.18768.8.camel@UberGeek> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Austin Gonyou wrote: > does anyone know how much speed is lost by osync? I don't have any numbers but it *feels* not much slower than without -osync. Actually I'm impressed how fast this system still is (it's a workgroups server for ~10 people accessing it mostly via NFS and it runs a small news server). > On Wed, 2002-03-20 at 12:32, Juri Haberland wrote: >> Daniel Fonseca wrote: >> > I seem to remember this being a bug reported some time ago, and >> thought >> > it was corrected, though. >> >> Hmm, hmm, IMO it's not a bug, but a feature ;) If you want your data >> reliable on disk mount it -osync. Cheers, Juri From owner-linux-xfs@oss.sgi.com Wed Mar 20 11:08:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KJ8MY08132 for linux-xfs-outgoing; Wed, 20 Mar 2002 11:08:22 -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 g2KJ8I908106 for ; Wed, 20 Mar 2002 11:08:18 -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 g2KKHtkw006537 for ; Wed, 20 Mar 2002 14:17:55 -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 NAA53486; Wed, 20 Mar 2002 13:08:27 -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 NAA52793; Wed, 20 Mar 2002 13:08:27 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2KJ69q10974; Wed, 20 Mar 2002 13:06:09 -0600 Message-Id: <200203201906.g2KJ69q10974@jen.americas.sgi.com> Date: Wed, 20 Mar 2002 13:06:09 -0600 Subject: TAKE - fix a bug in memory freeing To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Only happens under high memory pressure, Ian, I think this was your original oops. Date: Wed Mar 20 11:06:42 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-baseline The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:114531a linux/fs/xfs_support/kmem.c - 1.22 - Fix the case where we used vmalloc to allocate memory under pressure, we need to free it that way too. From owner-linux-xfs@oss.sgi.com Wed Mar 20 11:08:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KJ8rN08239 for linux-xfs-outgoing; Wed, 20 Mar 2002 11:08:53 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KJ8j908201 for ; Wed, 20 Mar 2002 11:08:46 -0800 Received: (qmail 19457 invoked by uid 500); 20 Mar 2002 19:09:40 -0000 Subject: Re: Corrupted files on 2.4.18. From: Austin Gonyou To: Juri Haberland Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C98DBBD.1080300@koschikode.com> References: <3C98DBBD.1080300@koschikode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 20 Mar 2002 13:09:40 -0600 Message-Id: <1016651380.19217.11.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ah-HAh! You're running a news server on there as well..I'm wondering if your corruption/nfs issues are not in fact caused by the news server? (i.e. fragmentation) On Wed, 2002-03-20 at 12:58, Juri Haberland wrote: > Austin Gonyou wrote: > > does anyone know how much speed is lost by osync? > > I don't have any numbers but it *feels* not much slower than without > -osync. Actually I'm impressed how fast this system still is (it's a > workgroups server for ~10 people accessing it mostly via NFS and it runs > a small news server). > > > On Wed, 2002-03-20 at 12:32, Juri Haberland wrote: > >> Daniel Fonseca wrote: > > >> > I seem to remember this being a bug reported some time ago, and > >> thought > >> > it was corrected, though. > >> > >> Hmm, hmm, IMO it's not a bug, but a feature ;) If you want your data > >> reliable on disk mount it -osync. > > Cheers, > Juri -- 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 20 11:44:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KJi4A08842 for linux-xfs-outgoing; Wed, 20 Mar 2002 11:44:04 -0800 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KJhp908816 for ; Wed, 20 Mar 2002 11:43:51 -0800 Received: from warp9.koschikode.com (pD9517F82.dip.t-dialin.net [217.81.127.130]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id ADCE4F4D9; Wed, 20 Mar 2002 20:45:13 +0100 (CET) Received: from koschikode.com (kaplah.koschikode.com [192.168.200.15]) by warp9.koschikode.com (Postfix) with ESMTP id DD7AFA9; Wed, 20 Mar 2002 20:44:56 +0100 (CET) Message-ID: <3C98E6B8.8080407@koschikode.com> Date: Wed, 20 Mar 2002 20:44:56 +0100 From: Juri Haberland Organization: totally unorganized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020305 X-Accept-Language: de-DE, en MIME-Version: 1.0 To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: Corrupted files on 2.4.18. References: <3C98DBBD.1080300@koschikode.com> <1016651380.19217.11.camel@UberGeek> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Austin Gonyou wrote: > Ah-HAh! You're running a news server on there as well..I'm wondering if > your corruption/nfs issues are not in fact caused by the news server? > (i.e. fragmentation) Sorry, it wasn't me reporting the corruption (thank god!)... I just threw my 0.02 EUR in ;) Juri From owner-linux-xfs@oss.sgi.com Wed Mar 20 12:21:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KKLYt09581 for linux-xfs-outgoing; Wed, 20 Mar 2002 12:21:34 -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 g2KKLQ909555 for ; Wed, 20 Mar 2002 12:21:26 -0800 Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA21465 for ; Wed, 20 Mar 2002 12:18:20 -0800 (PST) mail_from (rhowe@wiss.co.uk) Received: from os046.sta.man.ac.uk ([130.88.188.46] helo=xiao ident=mail) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #6) id 16nmTO-000BNs-00; Wed, 20 Mar 2002 20:14:14 +0000 Received: from rhowe by xiao with local (Exim 3.34 #1 (Debian)) id 16nmTO-0003o2-00; Wed, 20 Mar 2002 20:14:14 +0000 Date: Wed, 20 Mar 2002 20:14:13 +0000 To: Russel Ingram Cc: linux-xfs@oss.sgi.com Subject: Re: WARNING with regards to running xfs_fsr Message-ID: <20020320201413.GB14183@xiao> References: <1016623833.3c9872d96c0a2@webmail.soton.ac.uk> <20020320183239.GA23378@roujin.gargoylecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20020320183239.GA23378@roujin.gargoylecc.com> From: Russell Howe X-MIME-Autoconverted: from 8bit to quoted-printable by deliverator.sgi.com id MAA21465 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2KKLT909556 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 20, 2002 at 11:32:39AM -0700, Russel Ingram wrote: > Just my $0.02 worth on the subject of safety of xfs_fsr: > > I have been running xfs_fsr from cron (just like on my Irix systems) ever since I discovered it back in November with no problems whatsoever. I have aprox. 10 > Linux systems set up this way. Just my Ł0.02... I've had xfs_fsr in cron for a fair while (daily), and it seems to be working: fs_db: frag -f actual 12358, ideal 12038, fragmentation factor 2.59% [root@xiao] ~ # find /usr/local/media -type f|wc -l 12133 Filesystem Size Used Avail Use% Mounted on /dev/data_vg/data_lv 41G 34G 7.5G 82% /usr/local/media So I'm happy. I'd be happier if somehow I could get xfs_fsr to startup 20mins after I fall asleep, since my sleeping patterns are anything but and occasionally I find me and xfs_fsr competing for disk bandwidth, but having it run at 6am helps reduce the problem and it's less work than making something to detect whether or not I'm sleeping! -- Russell Howe rhowe@wiss.co.uk ** NOTE ** new email address From owner-linux-xfs@oss.sgi.com Wed Mar 20 12:50:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KKoCD10024 for linux-xfs-outgoing; Wed, 20 Mar 2002 12:50:12 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KKo7909998 for ; Wed, 20 Mar 2002 12:50:07 -0800 Received: (qmail 25713 invoked by uid 500); 20 Mar 2002 20:51:00 -0000 Subject: Re: TAKE - fix a bug in memory freeing From: Austin Gonyou To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <200203201906.g2KJ69q10974@jen.americas.sgi.com> References: <200203201906.g2KJ69q10974@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 20 Mar 2002 14:51:00 -0600 Message-Id: <1016657460.19220.30.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Does this affect the 8-way memory issues as well? On Wed, 2002-03-20 at 13:06, Steve Lord wrote: > Only happens under high memory pressure, Ian, I think this was > your original oops. > > Date: Wed Mar 20 11:06:42 PST 2002 > Workarea: jen.americas.sgi.com:/src/lord/xfs-baseline > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:114531a > linux/fs/xfs_support/kmem.c - 1.22 > - Fix the case where we used vmalloc to allocate memory under > pressure, > we need to free it that way too. > -- 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 20 13:08:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KL8hO10641 for linux-xfs-outgoing; Wed, 20 Mar 2002 13:08:43 -0800 Received: from gateway.max-t.com (229.124.18.216.gt-est.net [216.18.124.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KL8Z910615 for ; Wed, 20 Mar 2002 13:08:35 -0800 Received: from smccauley by gateway.max-t.com with local (Exim 3.32 #3) id 16nnNb-00062r-00; Wed, 20 Mar 2002 16:12:19 -0500 Date: Wed, 20 Mar 2002 16:12:19 -0500 From: Steeve McCauley To: Steve Lord Cc: Linux XFS Mailing List Subject: Re: Fragmentation (was: XFS NFS server Oops) Message-ID: <20020320161219.B22980@max-t.com> References: <1016644156.6150.129.camel@jen.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: <1016644156.6150.129.camel@jen.americas.sgi.com>; from lord@sgi.com on Wed, Mar 20, 2002 at 11:09:16AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 20, 2002 at 11:09:16AM -0600, Steve Lord wrote: > On Tue, 2002-03-19 at 19:37, Federico Sevilla III wrote: > Probably hold off for now on running fsr. > > Look at the other numbers on the output. The actual and ideal are > more interesting. If you look at these, the difference is the number > of extra extents you have above the ideal case. Then ask how much > data you have on the disk, dividing by the actual extent number > gives you the average length of the extents. It is also possible > that most of the fragmentation is restricted to a few files. We were stressing some systems with 1.6TB drive arrays and ended up with very full, very fragmented filesystems. This led to fs corruption and/or sysstem instability when the system ran out of memory. Note that these systems were running at 99.9% disk full and fragmentation factors of 99.8%. Obviously any sane admin would not run a system in this state for long (insane admins, redundant?). My question is can XFS can be configured to reserve a chunk of disk for root only access? I vaguely remember setting up an HPUX system several years ago and specifying that 5% of the disk should be reserved for administrative purposes. That might be a bit extreme with a 1.7TB drive array, but you get the idea. Is there anything like this in xfs? Thanks, steeve -- :wq From owner-linux-xfs@oss.sgi.com Wed Mar 20 13:22:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KLMET10982 for linux-xfs-outgoing; Wed, 20 Mar 2002 13:22:14 -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 g2KLMA910956 for ; Wed, 20 Mar 2002 13:22:10 -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 g2KMNXBA030050 for ; Wed, 20 Mar 2002 14:23:34 -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 PAA55560 for ; Wed, 20 Mar 2002 15:22:18 -0600 (CST) Received: from localhost.localdomain (eagdhcp-187-28.americas.sgi.com [128.162.187.178]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA85065 for ; Wed, 20 Mar 2002 15:22:18 -0600 (CST) From: Steve Lord Received: by localhost.localdomain (8.11.6/SGI-client-1.7) id g2KLKmA01390; Wed, 20 Mar 2002 15:20:48 -0600 Message-Id: <200203202120.g2KLKmA01390@localhost.localdomain> Date: Wed, 20 Mar 2002 15:20:48 -0600 Subject: TAKE - optimize some endian flipping code To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Mar 20 13:20:51 PST 2002 Workarea: eagdhcp-187-28.americas.sgi.com:/home/lord/src/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:114554a linux/fs/xfs/xfs_da_btree.c - 1.122 - optimize some endian flipping code From owner-linux-xfs@oss.sgi.com Wed Mar 20 13:24:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KLOqh11126 for linux-xfs-outgoing; Wed, 20 Mar 2002 13:24:52 -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 g2KLOi911100 for ; Wed, 20 Mar 2002 13:24:44 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx02)) with ESMTP id E321C6117; Wed, 20 Mar 2002 22:26:06 +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 WAA18024; Wed, 20 Mar 2002 22:26:06 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 0D6D057306; Wed, 20 Mar 2002 22:25:29 +0100 (CET) Received: from ch.sauter-bc.com (ppp02.cad.sba [10.1.249.2]) by mobile.sauter-bc.com (Postfix) with ESMTP id 6F2BF25835; Wed, 20 Mar 2002 22:25:27 +0100 (CET) Message-ID: <3C98FE47.992AC620@ch.sauter-bc.com> Date: Wed, 20 Mar 2002 22:25:27 +0100 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i586) X-Accept-Language: en MIME-Version: 1.0 To: Steeve McCauley Cc: Steve Lord , Linux XFS Mailing List Subject: Re: Fragmentation (was: XFS NFS server Oops) References: <1016644156.6150.129.camel@jen.americas.sgi.com> <20020320161219.B22980@max-t.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steeve McCauley schrieb: > > On Wed, Mar 20, 2002 at 11:09:16AM -0600, Steve Lord wrote: > > On Tue, 2002-03-19 at 19:37, Federico Sevilla III wrote: > > Probably hold off for now on running fsr. > > > > Look at the other numbers on the output. The actual and ideal are > > more interesting. If you look at these, the difference is the number > > of extra extents you have above the ideal case. Then ask how much > > data you have on the disk, dividing by the actual extent number > > gives you the average length of the extents. It is also possible > > that most of the fragmentation is restricted to a few files. > > We were stressing some systems with 1.6TB drive arrays > and ended up with very full, very fragmented filesystems. > This led to fs corruption and/or sysstem instability when > the system ran out of memory. Note that these systems > were running at 99.9% disk full and fragmentation factors > of 99.8%. Obviously any sane admin would not run a system > in this state for long (insane admins, redundant?). > > My question is can XFS can be configured to reserve > a chunk of disk for root only access? I vaguely remember > setting up an HPUX system several years ago and specifying > that 5% of the disk should be reserved for administrative > purposes. That might be a bit extreme with a 1.7TB drive > array, but you get the idea. Is there anything like this > in xfs? I was asking the very same question some month's ago and IIRC the answer was no. You're right with HP/UX about the 5% reserved space but also Linux with ext2 has this 5% limit as a default. Maybe this could go to the feature list. -Simon > > Thanks, > > steeve > > -- > :wq From owner-linux-xfs@oss.sgi.com Wed Mar 20 13:25:52 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KLPqY11270 for linux-xfs-outgoing; Wed, 20 Mar 2002 13:25:52 -0800 Received: from gateway.max-t.com (229.124.18.216.gt-est.net [216.18.124.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KLPf911244 for ; Wed, 20 Mar 2002 13:25:41 -0800 Received: from smccauley by gateway.max-t.com with local (Exim 3.32 #3) id 16nneC-000669-00; Wed, 20 Mar 2002 16:29:28 -0500 Date: Wed, 20 Mar 2002 16:29:28 -0500 From: Steeve McCauley To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: kmem_alloc() issues Message-ID: <20020320162928.C22980@max-t.com> References: <20020308225425.99525.qmail@web11003.mail.yahoo.com> <1016650471.28166.232.camel@jen.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: <1016650471.28166.232.camel@jen.americas.sgi.com>; from lord@sgi.com on Wed, Mar 20, 2002 at 12:54:31PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 20, 2002 at 12:54:31PM -0600, Steve Lord wrote: > On Fri, 2002-03-08 at 16:54, Mr. Fiddlehead wrote: > > 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. > > I think this will fix that problem: > *** 155,164 **** > void > kmem_free(void *ptr, size_t size) > { > ! if (MAX_SLAB_SIZE < size){ > ! vfree(ptr); > ! } else { > kfree(ptr); > } > } > > --- 155,165 ---- > void > kmem_free(void *ptr, size_t size) > { > ! struct page *p = virt_to_page(ptr); > ! if (VALID_PAGE(p) && PageSlab(p)) { > kfree(ptr); > + } else { > + vfree(ptr); > } > } > > > > > 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() > > > KM_SLEEP_IO is gone in recent kernels. Ah yes. It was there in 2.4.16 ... > > 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 will try this here for a while. > > > > > 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. > > hmm, there might be better things to do than this, possibly > calling free_more_memory(). Note that it's a lot better now with the 2.4.17 changes to shrink_cache; the way that max_mapped is calculated. This is a good suggestion though, thanks. On to 2.4.18 :) -- Steeve McCauley Maximum Throughput Programmer & Team Leader smccauley@max-t.com :wq From owner-linux-xfs@oss.sgi.com Wed Mar 20 13:46:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KLkNX11768 for linux-xfs-outgoing; Wed, 20 Mar 2002 13:46: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 g2KLkJ911742 for ; Wed, 20 Mar 2002 13:46:19 -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 g2KLlh6G000719 for ; Wed, 20 Mar 2002 13:47:43 -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 PAA54589 for ; Wed, 20 Mar 2002 15:46:27 -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 PAA16214 for ; Wed, 20 Mar 2002 15:46:27 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id PAA95250 for linux-xfs@oss.sgi.com; Wed, 20 Mar 2002 15:46:27 -0600 (CST) Date: Wed, 20 Mar 2002 15:46:27 -0600 (CST) From: Dean Roehrich Message-Id: <200203202146.PAA95250@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cleanup some invis I/O Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Mar 20 13:46:15 PST 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:114560a linux/fs/xfs/xfs_dmapi.c - 1.48 - cleanups for invis I/O From owner-linux-xfs@oss.sgi.com Wed Mar 20 14:04:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KM4Lr12259 for linux-xfs-outgoing; Wed, 20 Mar 2002 14:04:21 -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 g2KM4H912233 for ; Wed, 20 Mar 2002 14:04:17 -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 g2KM5f6G001417 for ; Wed, 20 Mar 2002 14:05:41 -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 QAA57988 for ; Wed, 20 Mar 2002 16:04:25 -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 QAA20022 for ; Wed, 20 Mar 2002 16:04:25 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id QAA33577 for linux-xfs@oss.sgi.com; Wed, 20 Mar 2002 16:04:25 -0600 (CST) Date: Wed, 20 Mar 2002 16:04:25 -0600 (CST) From: Dean Roehrich Message-Id: <200203202204.QAA33577@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi - allow dm_set_eventlist before responding to a mount event Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Mar 20 14:04:11 PST 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:114562a linux/fs/xfs_dmapi/dmapi_register.c - 1.5 - Rearrange dm_handle_to_vp(). This will allow an HSM to do a dm_set_eventlist between a get_events() which gets a mount event and the respond_event() for that mount. From owner-linux-xfs@oss.sgi.com Wed Mar 20 14:17:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KMHpr12568 for linux-xfs-outgoing; Wed, 20 Mar 2002 14:17:51 -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 g2KMHi912542 for ; Wed, 20 Mar 2002 14:17:44 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx04)) with ESMTP id D4B756123; Wed, 20 Mar 2002 23: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 XAA21178; Wed, 20 Mar 2002 23:19:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 06DB657306; Wed, 20 Mar 2002 23:18:05 +0100 (CET) Received: from ch.sauter-bc.com (ppp02.cad.sba [10.1.249.2]) by mobile.sauter-bc.com (Postfix) with ESMTP id B81EB25835; Wed, 20 Mar 2002 23:18:02 +0100 (CET) Message-ID: <3C990A99.DB38DB39@ch.sauter-bc.com> Date: Wed, 20 Mar 2002 23:18:01 +0100 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i586) X-Accept-Language: en MIME-Version: 1.0 To: Juri Haberland Cc: Steve Lord , Eric Sandeen , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C97591 B.FF456D25@ch.sauter-bc.com> <3C975DB7.4010201@koschikode.com> <3C9760EA.3874D744@ch.sauter-bc.com> <1016554052.4383.4.camel@stout.america s.sgi.com> <3C976ADD.FE0E7CDA@ch.sauter-bc.com> <1016558028.1770.31.camel@jen.americas.sgi.com> <3C978B5E.3040309@koschikode.com> <1016565408.1770.93.camel@jen.americas.sgi.com> <3C979839.5378CCA1@ch.sauter-bc.com> <1016568031.1841.132.camel@jen.americas.sgi.com> <3C98C002.3F3815F2@ch.sauter-bc.com> <3C98D3DC.3070107@koschikode.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juri Haberland schrieb: > > > > I have checked out 2.4.18-xfs from CVS 8 hours ago. Compiled and tested > > and I can confirm the problem is gone. Of course I don't know whether > > the problem comes from the 1001 RedHat patches or the kernel or XFS > > itself. > > > > Now, I can not upgrade all servers to 2.4.18 and even if I could, I > > didn't have time to test it very well so I have to stick with the RH > > 2.4.9-31 kernel for now (in production). The solution is to modify the > > /etc/rc.d/init.d/halt script to call sync several times, BEFORE the > > umount -a. If I sync just before remounting / ro, it does not help. > > I'm not convinced that 'sync' is the solution. As I can see from your > script you do a loop with several 'sync; sleep 1'. Maybe a 'sleep 30' - > as you tested successfully in another mail - would be sufficiant... You're completly right, I have just tested it. The sync call doesn't help anything and a single sleep ?? is enough. > > > Would be nice if someone could put this into FAQ since it affects all > > installaions from the RedHat installer at least on software raid. > > Are you sure anbout that? Is it really happening with a stock > installation without *any* kernel upgrade? I have just tried 2.4.9-13SGI_XFS_1.0.2 from the 7.2 installer CD and it's all the same. So I guess every RH XFS Kernel until 2.4.9-31SGI_XFS_1.0.2 suffers the bug. If it is just a timing issue then maybe your system needs more time to shutdown because you have other services running and that's why you don't have the problem. I can reproduce it on three completely different kind of hardware. The good news: Eric is building updated kernel RPMs and this bug is fixed there. > If I find the time during the weekend I will do some tests with the > latest official SGI kernel release as well as with all following > contributed kernels. Maybe we can narrow it down to a specific release... > > Juri From owner-linux-xfs@oss.sgi.com Wed Mar 20 14:59:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KMxfp13194 for linux-xfs-outgoing; Wed, 20 Mar 2002 14:59:41 -0800 Received: from mailnet.consensys.com ([209.47.40.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2KMxZ913165 for ; Wed, 20 Mar 2002 14:59:36 -0800 Received: from Francis ([209.47.40.10]) by mailnet.consensys.com (8.11.6/8.11.2) with SMTP id g2KHu4W08146 for ; Wed, 20 Mar 2002 17:56:04 GMT Message-ID: <00a601c1d063$1db70d40$8d02a8c0@consensys.com> From: "Francis Qu" To: Subject: DMAPI dm_set_region Date: Wed, 20 Mar 2002 18:01:05 -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 When DMAPI application tries to do dm_set_region on a file which is opened for write, both DMAPI application and the user application doing the write operation are blocked. The DMAPI application won't come back from dm_set_region utill the user cancels the write job. Is it the way DMAPI works? Thanks. Francis [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Mar 20 15:46:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2KNkll13849 for linux-xfs-outgoing; Wed, 20 Mar 2002 15:46: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 g2KNkh913823 for ; Wed, 20 Mar 2002 15:46:43 -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 g2KNm66G004919 for ; Wed, 20 Mar 2002 15:48:06 -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 RAA59007 for ; Wed, 20 Mar 2002 17:46:51 -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 RAA77703 for ; Wed, 20 Mar 2002 17:46:51 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2KNiVB03529; Wed, 20 Mar 2002 17:44:31 -0600 Message-Id: <200203202344.g2KNiVB03529@jen.americas.sgi.com> Date: Wed, 20 Mar 2002 17:44:31 -0600 Subject: TAKE - cleanup xfs vnode layer code Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a cleanup of the layer between linux inodes and xfs, it does clean up a few potential windows in there, and hopefully makes it less confusing. Date: Wed Mar 20 15:45:23 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-newpagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:114579a linux/fs/xfs/linux/xfs_vnode.c - 1.70 linux/fs/xfs/linux/xfs_super.c - 1.163 linux/fs/xfs/linux/xfs_vnode.h - 1.27 - rationalize xfs vnode layer code From owner-linux-xfs@oss.sgi.com Wed Mar 20 18:26:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L2QcR15774 for linux-xfs-outgoing; Wed, 20 Mar 2002 18:26:38 -0800 Received: from server-12.tower-16.messagelabs.com (mail16.messagelabs.com [64.124.170.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2L2QX915748 for ; Wed, 20 Mar 2002 18:26:34 -0800 X-VirusChecked: Checked Received: (qmail 27756 invoked from network); 21 Mar 2002 02:27:52 -0000 Received: from mail.tapeware.com (HELO yt-internet.tapeware.com) (4.21.59.10) by server-12.tower-16.messagelabs.com with SMTP; 21 Mar 2002 02:27:52 -0000 Received: from BRONCO (192.168.0.117 [192.168.0.117]) by yt-internet.tapeware.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDHGSVGD; Wed, 20 Mar 2002 18:26:22 -0800 From: "Quang Nguyen \(Ngo\)" To: Subject: mkfs.xfs Fails Date: Wed, 20 Mar 2002 18:27:54 -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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm using mkfs.xfs version 1.3.13 on Mandrake 8.1. In some occasions, mkfs.xfs fails to format my partition, even when I give it the -f flag. The actually command used is: mkfs.xfs -f /dev/hda2 It thinks the partition is busy, but in fact it's not. I just fdisked. How could it be busy or in used? /proc/mounts and /etc/mtab don't show /dev/hda2. Any suggestions or ideas? Maybe I'm doing wrong? Thanks, Quang ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From owner-linux-xfs@oss.sgi.com Wed Mar 20 18:34:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L2Ywq15971 for linux-xfs-outgoing; Wed, 20 Mar 2002 18:34: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 g2L2Yr915945 for ; Wed, 20 Mar 2002 18:34:53 -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 g2L3iUkw011688 for ; Wed, 20 Mar 2002 21:44:30 -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 UAA58516; Wed, 20 Mar 2002 20:35:01 -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 UAA38463; Wed, 20 Mar 2002 20:35:01 -0600 (CST) Date: Wed, 20 Mar 2002 20:35:01 -0600 (CST) From: Eric Sandeen X-X-Sender: To: "Quang Nguyen (Ngo)" cc: Subject: Re: mkfs.xfs Fails 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 If you have any partition on /dev/hda mounted, when you run fdisk, you'll need to unmount them and re-fdisk, or reboot. (Watch carefully after the fdisk - does it tell you to reboot?) Have you tried rebooting after the fdisk? -Eric On Wed, 20 Mar 2002, Quang Nguyen (Ngo) wrote: > I'm using mkfs.xfs version 1.3.13 on Mandrake 8.1. In some occasions, > mkfs.xfs fails to format my partition, even when I give it the -f flag. The > actually command used is: mkfs.xfs -f /dev/hda2 > > It thinks the partition is busy, but in fact it's not. I just fdisked. How > could it be busy or in used? /proc/mounts and /etc/mtab don't show > /dev/hda2. > > Any suggestions or ideas? Maybe I'm doing wrong? > > Thanks, > Quang > > > ________________________________________________________________________ > This email has been scanned for all viruses by the MessageLabs SkyScan > service. For more information on a proactive anti-virus service working > around the clock, around the globe, visit http://www.messagelabs.com > ________________________________________________________________________ > From owner-linux-xfs@oss.sgi.com Wed Mar 20 21:32:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L5WFs18210 for linux-xfs-outgoing; Wed, 20 Mar 2002 21:32:15 -0800 Received: from hanford.psnw.com (hanford.psnw.com [209.107.130.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2L5W8918184 for ; Wed, 20 Mar 2002 21:32:09 -0800 Received: from there (ct2-48.fresno-dial.psnw.com [209.107.139.48]) by hanford.psnw.com (Postfix) with SMTP id CAA3062CF; Wed, 20 Mar 2002 21:41:56 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" From: Quang Nguyen (Ngo) Organization: Yosemite Technologies, Inc. To: Eric Sandeen Subject: Re: mkfs.xfs Fails Date: Wed, 20 Mar 2002 21:33:34 -0800 X-Mailer: KMail [version 1.3.1] Cc: References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020321054156.CAA3062CF@hanford.psnw.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 20 March 2002 06:35 pm, Eric Sandeen wrote: > If you have any partition on /dev/hda mounted, when you run fdisk, you'll > need to unmount them and re-fdisk, or reboot. (Watch carefully after the > fdisk - does it tell you to reboot?) > > Have you tried rebooting after the fdisk? Hi Eric, There aren't any partition on that drive mounted when I fdisked it. Actually it's the second IDE drive, which is /dev/hdb. I know in my original email mentioned /dev/hda2. It should be /dev/hdb2. Anyway, I ran mkfs.ext2 and mkfs.reiserfs and they both formatted it fine. Just that mkfs.xfs -f /dev/hdb2 thinks it's busy or in use. Could you tell me where in the src code of mkfs.xfs I can modify to force it to format? Thanks, Quang From owner-linux-xfs@oss.sgi.com Wed Mar 20 21:41:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L5fnC18402 for linux-xfs-outgoing; Wed, 20 Mar 2002 21:41: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 g2L5fj918368 for ; Wed, 20 Mar 2002 21:41:45 -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 g2L6h8BA014520 for ; Wed, 20 Mar 2002 22:43:09 -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 XAA58953; Wed, 20 Mar 2002 23:41:53 -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 XAA52070; Wed, 20 Mar 2002 23:41:52 -0600 (CST) Date: Wed, 20 Mar 2002 23:41:52 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Quang Nguyen cc: Subject: Re: mkfs.xfs Fails In-Reply-To: <20020321054156.CAA3062CF@hanford.psnw.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Quang - I don't see offhand where the problem might be. Can you send the exact error message, and maybe run mkfs.xfs through strace (strace mkfs.xfs /dev/hdb2) and send the output? (if it's long just send it direct to me.) Thanks, -Eric On Wed, 20 Mar 2002, Quang Nguyen wrote: > Anyway, I ran mkfs.ext2 and mkfs.reiserfs and they both formatted it fine. > Just that mkfs.xfs -f /dev/hdb2 thinks it's busy or in use. > > Could you tell me where in the src code of mkfs.xfs I can modify to force it > to format? > > Thanks, > Quang > From owner-linux-xfs@oss.sgi.com Wed Mar 20 21:43:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L5hLW18544 for linux-xfs-outgoing; Wed, 20 Mar 2002 21:43: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 g2L5hG918518 for ; Wed, 20 Mar 2002 21:43:16 -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 g2L6qqkw012056 for ; Thu, 21 Mar 2002 00:52:53 -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 QAA15597; Thu, 21 Mar 2002 16:43:22 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA24956; Thu, 21 Mar 2002 16:43:21 +1100 (AEDT) Date: Thu, 21 Mar 2002 16:43:21 +1100 From: Nathan Scott To: Quang Nguyen Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs Fails Message-ID: <20020321164320.F23600@wobbly.melbourne.sgi.com> References: <20020321054156.CAA3062CF@hanford.psnw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020321054156.CAA3062CF@hanford.psnw.com>; from quang@tapeware.com on Wed, Mar 20, 2002 at 09:33:34PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 20, 2002 at 09:33:34PM -0800, Quang Nguyen wrote: > On Wednesday 20 March 2002 06:35 pm, Eric Sandeen wrote: > > If you have any partition on /dev/hda mounted, when you run fdisk, you'll > > need to unmount them and re-fdisk, or reboot. (Watch carefully after the > > fdisk - does it tell you to reboot?) > > > > Have you tried rebooting after the fdisk? > > Hi Eric, > > There aren't any partition on that drive mounted when I fdisked it. Actually > it's the second IDE drive, which is /dev/hdb. I know in my original email > mentioned /dev/hda2. It should be /dev/hdb2. > > Anyway, I ran mkfs.ext2 and mkfs.reiserfs and they both formatted it fine. > Just that mkfs.xfs -f /dev/hdb2 thinks it's busy or in use. That's very odd -- can you run "strace mkfs.xfs -f /dev/hdb2" and send the output? That will tell us where to start looking in mkfs. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 20 22:42:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L6gol19344 for linux-xfs-outgoing; Wed, 20 Mar 2002 22:42:50 -0800 Received: from kendy.up.ac.za (kendy.up.AC.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2L6gW919317 for ; Wed, 20 Mar 2002 22:42:33 -0800 Received: from [137.215.109.246] (helo=mx2.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 16nwIS-0004jA-00; Thu, 21 Mar 2002 08:43:36 +0200 Received: from mx1.up.ac.za ([137.215.95.15]) by mx2.up.ac.za with esmtp (Exim 3.12 #1) id 16nwIS-0002Vk-00; Thu, 21 Mar 2002 08:43:36 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=it.up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.15 #1) id 16nwIS-0002Tk-00; Thu, 21 Mar 2002 08:43:36 +0200 Message-ID: <3C998117.A0FE0323@it.up.ac.za> Date: Thu, 21 Mar 2002 08:43:35 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.19-pre2-ac2-xfs-shawn9 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: XFS mailing list Subject: Re: Kernel oops on new mailserver References: <3C965130.2CAB0A19@it.up.ac.za> <3C98ADE8.ACDBEF4C@it.up.ac.za> <1016642563.28200.113.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16nwIS-0002Tk-00*UTbUc7o5A.w* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk kernel 2.4.18 (checked out on 21 March 2002 - after vnode mods) gcc version 2.95.4 (Debian prerelease) modutils 2.4.13 I did the bh xxxx as you requested. kernel BUG at ll_rw_blk.c:902! invalid operand: 0000 CPU: 1 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 0000001f ebx: cb6ceae0 ecx: c03cc4c0 edx: 00002ddc esi: 00000008 edi: 00000001 ebp: ce113cbc esp: ce113ca8 ds: 0018 es: 0018 ss: 0018 Process modprobe (pid: 2328, stackpage=ce113000) Stack: c02ff562 00000386 cb6ceae0 00000000 00000001 ce113ce4 c021c047 00000001 cb6ceae0 c35888e0 cb6ceae0 c35888e0 00001000 cb6ceae0 00000200 ce113cfc c013582e 00000001 00000001 ce113d04 c35888e0 ce113efc c013677d cb6ceae0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 b8 03 00 00 00 f0 0f ab 43 18 0f b7 43 0c 66 >>EIP; c021bebc <===== Trace; c021c046 Trace; c013582e Trace; c013677c Trace; c0190744 Trace; c0190744 Trace; c0190744 Trace; c0111758 Trace; c0190744 Trace; c01d6600 Trace; c0136b96 <__refile_buffer+56/60> Trace; c0136bb8 Trace; c0136ae8 <__mark_buffer_dirty+28/30> Trace; c01e4cac Trace; c01e4fcc <__pb_block_commit_write_async+2c/50> Trace; c01e3f28 Trace; c01e5662 Trace; c01e5692 Trace; c01d6642 Trace; c01d6642 Trace; c01c312c Trace; c01df4b4 Trace; c01eadae Trace; c01e3fb0 Trace; c01e6f36 Trace; c01db5e0 Trace; c01e6a42 Trace; c0135fa6 Trace; c010715a Code; c021bebc 00000000 <_EIP>: Code; c021bebc <===== 0: 0f 0b ud2a <===== Code; c021bebe 2: 83 c4 08 add $0x8,%esp Code; c021bec0 5: b8 03 00 00 00 mov $0x3,%eax Code; c021bec6 a: f0 0f ab 43 18 lock bts %eax,0x18(%ebx) Code; c021beca f: 0f b7 43 0c movzwl 0xc(%ebx),%eax Code; c021bece 13: 66 data16 Entering kdb (current=0xce112000, pid 2328) on processor 1 Oops: invalid operand eax = 0x0000001f ebx = 0xcb6ceae0 ecx = 0xc03cc4c0 edx = 0x00002ddc esi = 0x00000008 edi = 0x00000001 esp = 0xce113ca8 eip = 0xc021bebc ebp = 0xce113cbc xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010202 [1]kdb> bh 0xcb6ceae0 buffer_head at 0xcb6ceae0 next 0x00000000 bno 0 rsec 11371432 size 4096 dev 0x805 rdev 0x807 count 2 state 0x5 [Uptodate Lock] ftime 0x18df77 b_list 1 b_reqnext 0x00000000 b_data 0xc59e6000 b_page 0xc1167980 b_this_page 0xcb6ceae0 b_private 0x00000000 [1]kdb> cpu Currently on cpu 1 Available cpus: 0, 1 [1]kdb> cpu 0 Entering kdb (current=0xcf6ea000, pid 162) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xcf6ebf84 0xc011559d do_syslog+0x15d (0x2, 0x804dd21, 0xfff) kernel .text 0xc0100000 0xc0115440 0xc0115804 0xcf6ebf98 0xc01562ea kmsg_read+0x12 (0xc151d620, 0x804dca0, 0xfff, 0xc151d640, 0xcf6ea000) kernel .text 0xc0100000 0xc01562d8 0xc01562f0 0xcf6ebfbc 0xc013461d sys_read+0x91 (0x0, 0x804dca0, 0xfff, 0x0, 0x804eca0) kernel .text 0xc0100000 0xc013458c 0xc01346a0 0xc010715b system_call+0x33 kernel .text 0xc0100000 0xc0107128 0xc0107160 Steve Lord wrote: > > Well, I just rewrote this code (after the 14th) to clean up a number > of problems in this area. > > Can you possibly try a current cvs tree. If you hit it again it will > be in submit_bh this time. Can you run with kdb again, specify y > for the KDB modules command. If it should happen again, run the > bt command, take the second argument of the submit_bh function > and use the bh command on it. > > Thanks > > 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 20 22:58:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L6wA319707 for linux-xfs-outgoing; Wed, 20 Mar 2002 22:58:10 -0800 Received: from ilanz.monex.li (ilanz.monex.li [164.128.93.104]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2L6vx919678 for ; Wed, 20 Mar 2002 22:57:59 -0800 Received: from spalegna.monex.li (spalegna [164.128.93.99]) by ilanz.monex.li (8.11.6/8.11.6) with ESMTP id g2L6xLG18272 for ; Thu, 21 Mar 2002 07:59:21 +0100 Received: from relay.monex.li (8.9.3/8.9.3) id JAA27764 for ; Thu, 21 Mar 2002 09:24:07 +0100 Received: from mailpumpe.monex.li by relay.monex.li via smtp; Received: from vorab.monex.li by mailpumpe.monex.li (8.11.6/8.11.6) with ESMTP id g2L6x3D06315 for ; Thu, 21 Mar 2002 07:59:04 +0100 Subject: mkfs.xfs on EVMS Volume From: Oliver Jehle To: XFS mailing list Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 21 Mar 2002 08:00:53 +0100 Message-Id: <1016694053.999.5.camel@vorab> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there i've problems makeing a new Filesystem with mkfs.xfs and EVMS (IBM LVM). with all other fs (reiserfs,ext2/3) its working... it looks, that there is a problem getting the device-size of the volume... Thanks Oliver here's the strace of the mkfs execve("/sbin/mkfs.xfs", ["mkfs.xfs", "-f", "/dev/evms/test1"], [/* 47 vars */]) = 0 uname({sys="Linux", node="arena1", ...}) = 0 brk(0) = 0x8083ef0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=86570, ...}) = 0 old_mmap(NULL, 86570, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\330"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1384040, ...}) = 0 old_mmap(NULL, 1201860, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002c000 mprotect(0x40147000, 42692, PROT_NONE) = 0 old_mmap(0x40147000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x11a000) = 0x40147000 old_mmap(0x4014e000, 14020, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4014e000 close(3) = 0 munmap(0x40016000, 86570) = 0 stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, 255), ...}) = 0 brk(0) = 0x8083ef0 brk(0x8084070) = 0x8084070 brk(0x8085000) = 0x8085000 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000 read(3, "Character devices:\n 1 mem\n 2 p"..., 4096) = 187 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40016000, 4096) = 0 getcwd("/", 4095) = 2 stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, 255), ...}) = 0 stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, 255), ...}) = 0 ustat(0x3fff, 0xbfffe178) = -1 EINVAL (Invalid argument) open("/dev/evms/test1", O_RDONLY|O_LARGEFILE) = 3 stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, 255), ...}) = 0 stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, 255), ...}) = 0 ustat(0x3fff, 0xbfffe178) = -1 EINVAL (Invalid argument) open("/dev/evms/test1", O_RDWR|O_LARGEFILE) = 4 stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, 255), ...}) = 0 ioctl(4, 0x40041271, 0xbfffe128) = -1 EINVAL (Invalid argument) write(2, "mkfs.xfs: warning - cannot set b"..., 98mkfs.xfs: warning - cannot set blocksize on block device /dev/evms/test1: Invalid argument ) = 98 stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, 255), ...}) = 0 open("/dev/evms/test1", O_RDONLY|O_LARGEFILE) = 5 ioctl(5, 0x80041272, 0xbfffe124) = -1 EINVAL (Invalid argument) write(2, "mkfs.xfs: can\'t determine device"..., 38mkfs.xfs: can't determine device size ) = 38 _exit(1) = ? From owner-linux-xfs@oss.sgi.com Wed Mar 20 23:11:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L7BE320069 for linux-xfs-outgoing; Wed, 20 Mar 2002 23:11: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 g2L7B5920037 for ; Wed, 20 Mar 2002 23:11:05 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx10)) with ESMTP id DF7F4622E; Thu, 21 Mar 2002 08:12:26 +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 IAA22770; Thu, 21 Mar 2002 08:12:26 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 22CCE57306; Thu, 21 Mar 2002 08:12:10 +0100 (CET) Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 5AC8E25835; Thu, 21 Mar 2002 08:12:10 +0100 (CET) Message-ID: <3C9987CA.83691F8F@ch.sauter-bc.com> Date: Thu, 21 Mar 2002 08:12:10 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.15 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Chris Tooley Cc: linux-xfs@oss.sgi.com Subject: Re: kernel RPMs References: <1016576625.22143.85.camel@filecabinet.amoa.org> <3C982DBE.65EC9E7@ch.sauter-bc.com> <1016649313.9948.17.camel@filecabinet.amoa.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Chris Tooley schrieb: > > On Wed, 2002-03-20 at 06:35, Simon Matter wrote: > > Chris Tooley schrieb: > > > > > > I don't know if anyone is interested, but I found myself in a situation > > > where I had to set up a PPTP server on a linux box (PoPToP) to > > > authenticate Windows clients. This meant that I had get mppe into the > > > kernel ppp that comes built into the RedHat contributed kernel. I ended > > > up getting everything set up right and have RPMs built with it. The > > > only difference between the 2.4.9-31 kernels that are in the > > > contributed-by-redhat directory and is the ppp difference. This doesn't > > > break using ppp normally it just adds the ability to use ppp-mppe. If > > > anyone would like a copy of these kernels they can be made available. > > > > > > Chris Tooley > > > > I might be interested one day but when this day comes, it'll be far too > > late for the 2.4.9-31 kernel. IIRC the problem with mppe is that for > > some reason RedHat can not include it in their kernel. It is a licence > > thing or an export problem, isn't it? > > mppe uses openssl so there may have been some export restrictions but I > thought most of those were lifted. Not sure though. The mppe module > (when modprobed) does get a warning about tainting the kernel. Don't > know how to go about making that social problem go away. > > > I have contributed the 2.4.9-31 RPMs and the goal was to have exactly > > the same kernel like original RedHat 2.4.9-31 but with only XFS and kdb > > included. Could you send me the .spec and patches anyway? > > > I didn't do a whole lot of work to get it going. I took the > kernel-2.4.9-31mppe SRPM from mirrors.binarix.com/ppp-mppe, installed > it, took the kernel-2.4.9-31SGI_XFS_1.0.2 SRPM and installed it, (noting > that it installes on top of the mppe kernel) and added like five lines > to the .spec to include the differences between kernel-2.4.9-31mppe.spec > and kernel-2.4.9-31SGI_XFS_1.0.2.spec (which was not much). > > The patch that is used is: > http://mirror.binarix.com/ppp-mppe/linux-2.4.16-openssl-0.9.6b-mppe.patch.gz and the .spec file is: > http://www.thetooleys.org/pptp/kernel-2.4.9-31-RH-xfs.spec > Let me know if you have concerns over issues that you see with it. The > kernel name doesn't reflect the mppe patch at all, as changing the > kernel name broke a bunch of my kernel modules. This is something that > I would expect most people will have problems with and it seems a very > minor change in the long run, but the file names probably ought to > reflect a difference. > > Chris Tooley My question is, why is mppe not in RedHat's kernel? Is there a license problem? Eric is building new kernel RPMs and I whish he could incorporate mppe. Unfortunately I think he won't because the goal of the RH XFS kernels is to be 100% inline with RH and just add the XFS bits. He refused to incorporate other changes in the past and I understand why. So the best thing will be to keep the mppe patch available and a template .spec file so it will be easy to rebuild the upcoming RPMs with mppe support. -Simon From owner-linux-xfs@oss.sgi.com Wed Mar 20 23:41:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L7fAW20804 for linux-xfs-outgoing; Wed, 20 Mar 2002 23:41:10 -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 g2L7f7920777 for ; Wed, 20 Mar 2002 23:41:07 -0800 Received: from online.no (213-187-164-240.dd.nextgentel.com [213.187.164.240]) by mail.broadpark.no (Postfix) with ESMTP id A875A7D43 for ; Thu, 21 Mar 2002 08:42:26 +0100 (MET) Message-ID: <3C998EB0.C0D5E431@online.no> Date: Thu, 21 Mar 2002 08:41:36 +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: xfs in linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Acording to openloggin xfs are going to be part of linux 2.5 From owner-linux-xfs@oss.sgi.com Thu Mar 21 00:51:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L8pjT26391 for linux-xfs-outgoing; Thu, 21 Mar 2002 00:51:45 -0800 Received: from ilanz.monex.li (ilanz.monex.li [164.128.93.104]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2L8pU926358 for ; Thu, 21 Mar 2002 00:51:30 -0800 Received: from spalegna.monex.li (spalegna [164.128.93.99]) by ilanz.monex.li (8.11.6/8.11.6) with ESMTP id g2L8qrD18651 for ; Thu, 21 Mar 2002 09:52:53 +0100 Received: from relay.monex.li (8.9.3/8.9.3) id LAA28070 for ; Thu, 21 Mar 2002 11:17:40 +0100 Received: from mailpumpe.monex.li by relay.monex.li via smtp; Received: from vorab.monex.li by mailpumpe.monex.li (8.11.6/8.11.6) with ESMTP id g2L8qPD06755 for ; Thu, 21 Mar 2002 09:52:25 +0100 Subject: mkfs.xfs on EVMS Volume forgot the releases used From: Oliver Jehle To: linux-xfs@oss.sgi.com In-Reply-To: <1016694053.999.5.camel@vorab> References: <1016694053.999.5.camel@vorab> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 21 Mar 2002 09:54:15 +0100 Message-Id: <1016700855.999.39.camel@vorab> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk used releases vanilla smp 2.4.18 kernel evms-0.9.2 xfs-packages from the download area patches/2.4.18/xfs-2.4.18-all-i386.bz2. cmd_tars/*2.0.* .tar.gz On Thu, 2002-03-21 at 08:00, Oliver Jehle wrote: > Hi there > > > i've problems makeing a new Filesystem with mkfs.xfs and EVMS (IBM LVM). > with all other fs (reiserfs,ext2/3) its working... > > it looks, that there is a problem getting the device-size of the > volume... > > Thanks > Oliver > > > > > here's the strace of the mkfs > > execve("/sbin/mkfs.xfs", ["mkfs.xfs", "-f", "/dev/evms/test1"], [/* 47 > vars */]) = 0 > uname({sys="Linux", node="arena1", ...}) = 0 > brk(0) = 0x8083ef0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, > -1, 0) = 0x40015000 > open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or > directory) > open("/etc/ld.so.cache", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=86570, ...}) = 0 > old_mmap(NULL, 86570, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000 > close(3) = 0 > open("/lib/libc.so.6", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\330"..., > 1024) = 1024 > fstat64(3, {st_mode=S_IFREG|0755, st_size=1384040, ...}) = 0 > old_mmap(NULL, 1201860, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x4002c000 > mprotect(0x40147000, 42692, PROT_NONE) = 0 > old_mmap(0x40147000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, > 3, 0x11a000) = 0x40147000 > old_mmap(0x4014e000, 14020, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4014e000 > close(3) = 0 > munmap(0x40016000, 86570) = 0 > stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, > 255), ...}) = 0 > brk(0) = 0x8083ef0 > brk(0x8084070) = 0x8084070 > brk(0x8085000) = 0x8085000 > open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 > fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, > -1, 0) = 0x40016000 > read(3, "Character devices:\n 1 mem\n 2 p"..., 4096) = 187 > read(3, "", 4096) = 0 > close(3) = 0 > munmap(0x40016000, 4096) = 0 > getcwd("/", 4095) = 2 > stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, > 255), ...}) = 0 > stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, > 255), ...}) = 0 > ustat(0x3fff, 0xbfffe178) = -1 EINVAL (Invalid argument) > open("/dev/evms/test1", O_RDONLY|O_LARGEFILE) = 3 > stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, > 255), ...}) = 0 > stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, > 255), ...}) = 0 > ustat(0x3fff, 0xbfffe178) = -1 EINVAL (Invalid argument) > open("/dev/evms/test1", O_RDWR|O_LARGEFILE) = 4 > stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, > 255), ...}) = 0 > ioctl(4, 0x40041271, 0xbfffe128) = -1 EINVAL (Invalid argument) > write(2, "mkfs.xfs: warning - cannot set b"..., 98mkfs.xfs: warning - > cannot set blocksize on block device /dev/evms/test1: Invalid argument > ) = 98 > stat64("/dev/evms/test1", {st_mode=S_IFBLK|0644, st_rdev=makedev(63, > 255), ...}) = 0 > open("/dev/evms/test1", O_RDONLY|O_LARGEFILE) = 5 > ioctl(5, 0x80041272, 0xbfffe124) = -1 EINVAL (Invalid argument) > write(2, "mkfs.xfs: can\'t determine device"..., 38mkfs.xfs: can't > determine device size > ) = 38 > _exit(1) = ? > > > > From owner-linux-xfs@oss.sgi.com Thu Mar 21 01:22:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2L9MBg27243 for linux-xfs-outgoing; Thu, 21 Mar 2002 01:22:11 -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 g2L9M8927216 for ; Thu, 21 Mar 2002 01:22:08 -0800 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 758EA401A46; Thu, 21 Mar 2002 04:24:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 42C21C00EF6; Thu, 21 Mar 2002 04:24:11 -0500 (EST) Date: Thu, 21 Mar 2002 04:24:10 -0500 (EST) From: Mike Burger To: Knut J Bjuland Cc: linux-xfs@oss.sgi.com Subject: Re: xfs in linux In-Reply-To: <3C998EB0.C0D5E431@online.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Care to give us a URL to visit? On Thu, 21 Mar 2002, Knut J Bjuland wrote: > Acording to openloggin xfs are going to be part of linux 2.5 > From owner-linux-xfs@oss.sgi.com Thu Mar 21 03:20:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LBK8A01195 for linux-xfs-outgoing; Thu, 21 Mar 2002 03:20:08 -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 g2LBK3901169 for ; Thu, 21 Mar 2002 03:20:04 -0800 Received: from online.no (213-187-164-240.dd.nextgentel.com [213.187.164.240]) by mail.broadpark.no (Postfix) with ESMTP id D29EF7D27; Thu, 21 Mar 2002 12:21:26 +0100 (MET) Message-ID: <3C99C208.EFFCA9D8@online.no> Date: Thu, 21 Mar 2002 12:20:40 +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: Mike Burger Cc: linux-xfs@oss.sgi.com Subject: Re: xfs in linux References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Burger wrote: > Care to give us a URL to visit? > > On Thu, 21 Mar 2002, Knut J Bjuland wrote: > > > Acording to openloggin xfs are going to be part of linux 2.5 > > http://www.bitmover.com:8888//tmp/v2_logging/athlon.transmeta.com/torvalds-20020205173056-16047-c1d11a41ed024864 From owner-linux-xfs@oss.sgi.com Thu Mar 21 03:21:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LBLKt01334 for linux-xfs-outgoing; Thu, 21 Mar 2002 03:21:20 -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 g2LBL6901298 for ; Thu, 21 Mar 2002 03:21:06 -0800 Received: by pooh.lsc.hu (Postfix, from userid 547) id 7B59CE0573; Thu, 21 Mar 2002 12:29:40 +0100 (CET) Date: Thu, 21 Mar 2002 12:29:40 +0100 From: GCS To: linux-xfs@oss.sgi.com Subject: XFS and kernel 2.5.x Message-ID: <20020321122940.A26364@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! Is XFS part of the kernel as version 2.5.x? If not, why, and when it will be included? 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 Thu Mar 21 03:25:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LBPoQ01485 for linux-xfs-outgoing; Thu, 21 Mar 2002 03:25: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 g2LBPj901459 for ; Thu, 21 Mar 2002 03:25:45 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id A7B921E43D; Thu, 21 Mar 2002 12:27:08 +0100 (MET) Date: Thu, 21 Mar 2002 12:27:06 +0100 From: Andi Kleen To: Knut J Bjuland Cc: Mike Burger , linux-xfs@oss.sgi.com Subject: Re: xfs in linux Message-ID: <20020321122706.A27485@wotan.suse.de> References: <3C99C208.EFFCA9D8@online.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C99C208.EFFCA9D8@online.no> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 21, 2002 at 12:20:40PM +0100, Knut J Bjuland` wrote: > Mike Burger wrote: > > > Care to give us a URL to visit? > > > > On Thu, 21 Mar 2002, Knut J Bjuland wrote: > > > > > Acording to openloggin xfs are going to be part of linux 2.5 > > > > > http://www.bitmover.com:8888//tmp/v2_logging/athlon.transmeta.com/torvalds-20020205173056-16047-c1d11a41ed024864 This is not the Linus tree, but Chris Mason's (private) tree. Remember the bitkeeper license forces everybody to log all his private changes to openlogging.org and in addition bitkeeper relates trees and mixes their changelog. It it is not surprising that the end result is rather confusing. You always have to be very careful that the change you're seeing is for the right tree. -Andi From owner-linux-xfs@oss.sgi.com Thu Mar 21 03:35:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LBZcw01657 for linux-xfs-outgoing; Thu, 21 Mar 2002 03:35:38 -0800 Received: from indonesia.kscanners.no (indonesia.kscanners.no [193.214.130.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LBZU901631 for ; Thu, 21 Mar 2002 03:35:31 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=indonesia) by indonesia.kscanners.no with esmtp (Exim 3.33 #1) id 16o0sE-0006cR-00 for linux-xfs@oss.sgi.com; Thu, 21 Mar 2002 12:36:50 +0100 Date: Thu, 21 Mar 2002 12:36:46 +0100 From: Toralf Lund To: linux-xfs@oss.sgi.com Subject: Forced XFS shutdown Message-ID: <20020321113646.GA3651@indonesia.kscanners.no> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.3.3 Lines: 39 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk One of our customers recently had a problem with an XFS file system on a Linux server installation - the file system was simply missing all of a sudden. Inspection of the system log revealed the following messages: Mar 19 09:41:01 zagreb kernel: xfs_force_shutdown(sd(8,16),0x8) called from line 4079 of file xfs_bmap.c. Return address = 0xc0190be2 Mar 19 09:41:01 zagreb kernel: Corruption of in-memory data detected. Shutting down filesystem: sd(8,16) Mar 19 09:41:01 zagreb kernel: Please umount the file system, and rectify the problem(s) When someone tried to reboot the machine in an attempt to re-mount the file system, the following message occurred: Mar 19 10:00:58 zagreb kernel: XFS mounting filesystem sd(8,16) Mar 19 10:00:58 zagreb kernel: Starting XFS recovery on filesystem: sd(8,16) (dev: 8/16) Mar 19 10:00:58 zagreb kernel: XFS: xlog_recover_process_data: bad clientid Mar 19 10:00:58 zagreb kernel: XFS: log mount/recovery failed Mar 19 10:00:58 zagreb kernel: XFS: log mount failed xfs_repair didn't work on the first attempt, either, but fortunately "xfs_repair -L" seemed to put everything right; the volume was mounted successfully after that. Any idea what happened here? Is there any reason to suspect that the file system has become unstable so that the problem could reappear, and if so, is there any way of rectifying it? Note that the device is a RAID-5 unit, and that the error occurred some time after one of the disks was replaced due to a hardware failure. The machine is a Dual-AMD Athlon system with Red Hat Linux 7.2 and kernel-2.4.9-13SGI_XFS_1.0.2smp installed via prebuilt RPM. -- Toralf Lund +47 66 85 51 22 Kongsberg Scanners AS +47 66 85 51 00 (switchboard) http://www.kscanners.no/~toralf +47 66 85 51 01 (fax) From owner-linux-xfs@oss.sgi.com Thu Mar 21 09:19:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHJRb01499 for linux-xfs-outgoing; Thu, 21 Mar 2002 09:19:27 -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 g2LHJJq01467 for ; Thu, 21 Mar 2002 09:19:19 -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 g2LEUn6G026762 for ; Thu, 21 Mar 2002 06:30:49 -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 IAA66969; Thu, 21 Mar 2002 08:29: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 IAA86521; Thu, 21 Mar 2002 08:29:33 -0600 (CST) Date: Thu, 21 Mar 2002 08:29:33 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Oliver Jehle cc: Subject: Re: mkfs.xfs on EVMS Volume forgot the releases used In-Reply-To: <1016700855.999.39.camel@vorab> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 21 Mar 2002, Oliver Jehle wrote: > > ioctl(5, 0x80041272, 0xbfffe124) = -1 EINVAL (Invalid argument) > > write(2, "mkfs.xfs: can\'t determine device"..., 38mkfs.xfs: can't > > determine device size > > ) = 38 > > _exit(1) = ? Ok, it looks like the BLKGETSIZE64 ioctl is failing. The very latest mkfs.xfs will fall back to BLKGETSIZE if this happens; I guess we need to update what's on oss. You should suggest to the evms folks that they implement BLKGETSIZE64, but in the meantime this patch will fix things for you: --- /usr/tmp/TmpDir.30077-0/cmd/xfsprogs/libxfs/init.c_1.12 Thu Mar 21 08:28:40 2002 +++ /usr/tmp/TmpDir.30077-0/cmd/xfsprogs/libxfs/init.c_1.13 Thu Mar 21 08:28:40 2002 @@ -156,11 +156,19 @@ exit(1); } error = ioctl(fd, BLKGETSIZE64, &size); - /* BLKGETSIZE64 returns size in bytes */ - size = size >> 9; - if (error < 0) { - fprintf(stderr, "%s: can't determine device size\n", progname); - exit(1); + if (error >= 0) { + /* BLKGETSIZE64 returns size in bytes not 512-byte blocks */ + size = size >> 9; + } else { + /* If BLKGETSIZE64 fails, try BLKGETSIZE */ + unsigned long tmpsize; + error = ioctl(fd, BLKGETSIZE, &tmpsize); + if (error < 0) { + fprintf(stderr, "%s: can't determine device size\n", + progname); + exit(1); + } + size = (__uint64_t)tmpsize; } close(fd); -Eric From owner-linux-xfs@oss.sgi.com Thu Mar 21 09:19:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHJK801468 for linux-xfs-outgoing; Thu, 21 Mar 2002 09:19:20 -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 g2LHJEq01440 for ; Thu, 21 Mar 2002 09:19: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 g2LEZn6G026916 for ; Thu, 21 Mar 2002 06:35:49 -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 IAA67942; Thu, 21 Mar 2002 08:34: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 IAA24550; Thu, 21 Mar 2002 08:34:33 -0600 (CST) Date: Thu, 21 Mar 2002 08:34:33 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Toralf Lund cc: Subject: Re: Forced XFS shutdown In-Reply-To: <20020321113646.GA3651@indonesia.kscanners.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 21 Mar 2002, Toralf Lund wrote: > One of our customers recently had a problem with an XFS file system on a > Linux server installation - the file system was simply missing all of a > sudden. Inspection of the system log revealed the following messages: > > Mar 19 09:41:01 zagreb kernel: xfs_force_shutdown(sd(8,16),0x8) called > from line 4079 of file xfs_bmap.c. Return address = 0xc0190be2 This means some sort of i/o error has occured. Bad cable, bad disk, in-memory corruption problems, it's hard to tell. :( > When someone tried to reboot the machine in an attempt to re-mount the > file system, the following message occurred: > > Mar 19 10:00:58 zagreb kernel: XFS mounting filesystem sd(8,16) > Mar 19 10:00:58 zagreb kernel: Starting XFS recovery on filesystem: > sd(8,16) (dev: 8/16) > Mar 19 10:00:58 zagreb kernel: XFS: xlog_recover_process_data: bad clientid > Mar 19 10:00:58 zagreb kernel: XFS: log mount/recovery failed > Mar 19 10:00:58 zagreb kernel: XFS: log mount failed > > Any idea what happened here? Is there any reason to suspect that the file > system has become unstable so that the problem could reappear, and if so, > is there any way of rectifying it? There was a bug in some xfs versions that would overwrite the first part of the disk after a forced shutdown, which is why it would not mount afterwards. This bug is fixed in recent CVS kernels and will also be fixed in some upcoming prerelease kernels, due out soon... So the real problem is the forced shutdown; the subsequent mount problem is due to a bug that's been fixed. So the shutdown could happen again, but we can avoid the mount problem now. -Eric From owner-linux-xfs@oss.sgi.com Thu Mar 21 09:28:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHSVu01948 for linux-xfs-outgoing; Thu, 21 Mar 2002 09:28:31 -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 g2LHSNq01913 for ; Thu, 21 Mar 2002 09:28:23 -0800 Received: from atlantel.fr (geo.atlantel.fr [194.206.120.243]) 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 HAA03366 for ; Thu, 21 Mar 2002 07:30:31 -0800 (PST) mail_from (secure@ieak.net) Received: from geo (unverified [194.206.120.243]) by atlantel.org (Rockliffe SMTPRA 5.2.3) with SMTP id for ; Thu, 21 Mar 2002 16:29:58 +0100 Received: FROM marguerite.atlantel.fr BY geo ; Thu Mar 21 16:29:55 2002 +0100 Received: from ADMIEAK (adm-ieak.atl.net [10.1.2.193]) by marguerite.atlantel.fr (Postfix) with SMTP id 48316B6ED5 for ; Thu, 21 Mar 2002 16:29:55 +0100 (CET) Message-ID: <00b401c1d0ed$40cda4d0$c102010a@atl.net> From: "Hugo Lafargue" To: References: <3C99C208.EFFCA9D8@online.no> <20020321122706.A27485@wotan.suse.de> Subject: xfs and acl > inherit permissions (acl) Date: Thu, 21 Mar 2002 16:29:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have a linux with a 2.4.14 xfs patched kernel. ACL are working as it should do I guess... but i have an issue with files created by root logged in a console (this is an example...) here is the acl of the directory /home/hugo $ getfacl /home/hugo #file: /home/hugo #owner: hugo #group: admins user::rwx user:paul:r-x user:hugo:rwx group::r-x group:admins:rwx mask::rwx other::--- if i understand correctly how acl works, - the user 'hugo' as Read-Write-Execute rights, - the user 'paul' as Read-Execute rights, - members of the 'admins' group have Read-Write-Execute rights, - access to this directory is forbidden for other users Am I right or wrong ? tell me... well, if I create a test file with 'touch /home/hugo/test' : $ getfacl /home/hugo/test # file: test # owner: root # group: root user::rw- group::r-- other::r-- Argh ! I would like the file to inherit its default permissions, and the acl from the parent directory ! is it possible ?? if yes, could you explain me how to do such a thing ? Thanks. Hugo. From owner-linux-xfs@oss.sgi.com Thu Mar 21 09:32:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHW2M02184 for linux-xfs-outgoing; Thu, 21 Mar 2002 09:32:02 -0800 Received: from the-penguin.otak.com (mail@the-penguin.otak.com [216.122.56.136]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LHVsq02158 for ; Thu, 21 Mar 2002 09:31:54 -0800 Received: from lawrence by the-penguin.otak.com with local (Exim 3.35 #1 (Debian)) id 16o5Lp-0005TU-00; Thu, 21 Mar 2002 08:23:41 -0800 Date: Thu, 21 Mar 2002 08:23:41 -0800 From: Lawrence Walton To: Hugo Lafargue Cc: linux-xfs@oss.sgi.com Subject: Re: xfs and acl > inherit permissions (acl) Message-ID: <20020321162341.GA26026@the-penguin.otak.com> References: <3C99C208.EFFCA9D8@online.no> <20020321122706.A27485@wotan.suse.de> <00b401c1d0ed$40cda4d0$c102010a@atl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b401c1d0ed$40cda4d0$c102010a@atl.net> User-Agent: Mutt/1.3.27i X-Operating-System: Linux 2.5.6-pre2 on an i686 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hugo Lafargue [secure@ieak.net] wrote: > Hi, > > I have a linux with a 2.4.14 xfs patched kernel. > ACL are working as it should do I guess... > > but i have an issue with files created by root logged in a console (this is > an example...) > > here is the acl of the directory /home/hugo > > $ getfacl /home/hugo > #file: /home/hugo > #owner: hugo > #group: admins > user::rwx > user:paul:r-x > user:hugo:rwx > group::r-x > group:admins:rwx > mask::rwx > other::--- > > if i understand correctly how acl works, > - the user 'hugo' as Read-Write-Execute rights, > - the user 'paul' as Read-Execute rights, > - members of the 'admins' group have Read-Write-Execute rights, > - access to this directory is forbidden for other users > Am I right or wrong ? tell me... > > well, if I create a test file with 'touch /home/hugo/test' : > $ getfacl /home/hugo/test > # file: test > # owner: root > # group: root > user::rw- > group::r-- > other::r-- > > Argh ! I would like the file to inherit its default permissions, and the acl > from the parent directory ! > is it possible ?? if yes, could you explain me how to do such a thing ? > > Thanks. > > Hugo. > man setfacl look for "default" -- *--* Mail: lawrence@otak.com *--* Voice: 425.739.4247 *--* Fax: 425.827.9577 *--* HTTP://www.otak-k.com/~lawrence/ -------------------------------------- - - - - - - O t a k i n c . - - - - - From owner-linux-xfs@oss.sgi.com Thu Mar 21 09:45:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHj5602727 for linux-xfs-outgoing; Thu, 21 Mar 2002 09:45:05 -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 g2LHiuq02691 for ; Thu, 21 Mar 2002 09:44: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 g2LHr5kw015725 for ; Thu, 21 Mar 2002 11:53:05 -0600 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 KAA69805 for ; Thu, 21 Mar 2002 10:43:34 -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 KAA79027 for ; Thu, 21 Mar 2002 10:43:34 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id KAA89164 for linux-xfs@oss.sgi.com; Thu, 21 Mar 2002 10:43:34 -0600 (CST) Date: Thu, 21 Mar 2002 10:43:34 -0600 (CST) From: Dean Roehrich Message-Id: <200203211643.KAA89164@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi - use vfsmount ptr in dmapi_mount_event callout Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk To fix dm_handle_to_path() I need to be able to open a file by its handle, when I don't know which filesystem the handle belongs to--meaning, I don't have an open filedescriptor that I could use in, say, ioctl(XFS_IOC_OPEN_BY_HANDLE), which means I don't have access to a vfsmount ptr, which means I can't fully populate a new "struct file", which means I'm giving the user a new filedescriptor that isn't safe to use. This mod allows DMAPI to keep a vfsmount pointer that was used during the mount event, and in a followup mod I will use that pointer for an open_by_handle operation. Date: Thu Mar 21 08:42:58 PST 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:114620a linux/include/linux/fs.h - 1.145 - Change dmapi_mount_event in struct super_operations, to have vfsmount ptr param instead of super_block param. linux/fs/xfs/xfs_dmapi.h - 1.21 - Change xfs_dm_mount() prototype for vfsmount ptr. linux/fs/xfs/xfs_dmapi.c - 1.49 - Change xfs_dm_mount() to accept vfsmount ptr, and to call dm_hookup_vfsmount. linux/fs/xfs/linux/xfs_dmistubs.c - 1.14 - fixup xfs_dm_mount() stub, for new vfsmount param. linux/fs/xfs/linux/xfs_super.c - 1.164 - Change linvfs_dmapi_mount to take vfsmount ptr rather than super_block. linux/include/linux/dmapi_kern.h - 1.8 - add prototype for dm_hookup_vfsmount. linux/fs/xfs/linux/xfs_vfs.h - 1.10 - Change vfs_dmapi_mount prototype and VFSOPS_DMAPI_MOUNT macro to send vfsmount ptr. linux/fs/namespace.c - 1.9 - Put the vfsmount ptr into the dmapi_mount_event callout, rather than the superblock. We can get the superblock later from the vfsmount. linux/fs/xfs_dmapi/dmapi_register.c - 1.6 - Add new function dm_hookup_vfsmount() to attach the vfsmount ptr to the dm_fsreg_t. linux/fs/xfs_dmapi/dmapi_private.h - 1.4 - Add vfsmount ptr to dm_fsreg_t. From owner-linux-xfs@oss.sgi.com Thu Mar 21 09:48:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHmxG02913 for linux-xfs-outgoing; Thu, 21 Mar 2002 09:48:59 -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 g2LHmsq02887 for ; Thu, 21 Mar 2002 09:48: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 g2LFnqkw013694 for ; Thu, 21 Mar 2002 09:49:52 -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 IAA67589 for ; Thu, 21 Mar 2002 08:40:22 -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 IAA37542 for ; Thu, 21 Mar 2002 08:40:21 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2LEbub14432; Thu, 21 Mar 2002 08:37:56 -0600 Message-Id: <200203211437.g2LEbub14432@jen.americas.sgi.com> Date: Thu, 21 Mar 2002 08:37:56 -0600 Subject: TAKE - fix debug kernel Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk New vnode code left in an assert which is no longer valid Date: Thu Mar 21 06:39:40 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-newpagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:114612a linux/fs/xfs/linux/xfs_vnode.c - 1.71 - remove bad assert From owner-linux-xfs@oss.sgi.com Thu Mar 21 09:49:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHn2Q02942 for linux-xfs-outgoing; Thu, 21 Mar 2002 09:49:02 -0800 Received: from nasexs1.meridian-data.com (cdserv.meridian-data.com [206.79.177.152]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LHmkq02860 for ; Thu, 21 Mar 2002 09:48:47 -0800 Received: by cdserv.meridian-data.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 08:51:57 -0800 Message-ID: <2D0AFEFEE711D611923E009027D39F2B052F92@cdserv.meridian-data.com> From: "Kaplan, Marc" To: "'Hugo Lafargue'" , linux-xfs@oss.sgi.com Subject: RE: xfs and acl > inherit permissions (acl) Date: Thu, 21 Mar 2002 08:51:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You need to set the default or inheritance ACLs on the /home/hugo directory. This can be probably be done using setfacl, but I am more familiar with chacl. You can use chacl -B to set both the object ACL and the default (inheritance) ACL. To accomplish what you want, you have to do something like this: chacl -B u::rwx,g::r-x,o:---,u:paul:r-x,u:hugo:rwx,g:admins:rwx u::rwx,g::r-x,o:---,u:paul:r-x,u:hugo:rwx,g:admins:rwx So the first entry (before the space) applies to the object itself, and the second (after the space) applies to inheritance. If in doubt, look at the man pages for chacl and setfacl. Cheers, -Marc -----Original Message----- From: Hugo Lafargue [mailto:secure@ieak.net] Sent: Thursday, March 21, 2002 7:30 AM To: linux-xfs@oss.sgi.com Subject: xfs and acl > inherit permissions (acl) Hi, I have a linux with a 2.4.14 xfs patched kernel. ACL are working as it should do I guess... but i have an issue with files created by root logged in a console (this is an example...) here is the acl of the directory /home/hugo $ getfacl /home/hugo #file: /home/hugo #owner: hugo #group: admins user::rwx user:paul:r-x user:hugo:rwx group::r-x group:admins:rwx mask::rwx other::--- if i understand correctly how acl works, - the user 'hugo' as Read-Write-Execute rights, - the user 'paul' as Read-Execute rights, - members of the 'admins' group have Read-Write-Execute rights, - access to this directory is forbidden for other users Am I right or wrong ? tell me... well, if I create a test file with 'touch /home/hugo/test' : $ getfacl /home/hugo/test # file: test # owner: root # group: root user::rw- group::r-- other::r-- Argh ! I would like the file to inherit its default permissions, and the acl from the parent directory ! is it possible ?? if yes, could you explain me how to do such a thing ? Thanks. Hugo. From owner-linux-xfs@oss.sgi.com Thu Mar 21 09:56:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LHud203313 for linux-xfs-outgoing; Thu, 21 Mar 2002 09:56: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 g2LHuZq03286 for ; Thu, 21 Mar 2002 09:56:35 -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 g2LHuSBA000777 for ; Thu, 21 Mar 2002 09:56:29 -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 KAA70316 for ; Thu, 21 Mar 2002 10:55:13 -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 KAA63782 for ; Thu, 21 Mar 2002 10:55:13 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g2LGtDH30395; Thu, 21 Mar 2002 10:55:13 -0600 Message-Id: <200203211655.g2LGtDH30395@stout.americas.sgi.com> Date: Thu, 21 Mar 2002 10:55:13 -0600 From: Eric Sandeen Subject: TAKE - fix ia64 warning / incorrect cast Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk the nfs refcache flush timer code was casting the value assigned to the timer.data field incorrectly, this caused a warning on the ia64 compile. Date: Thu Mar 21 08:53:58 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:114625a linux/fs/xfs/xfs_rw.c - 1.352 - Fix an ia64 warning generated by an incorrect cast From owner-linux-xfs@oss.sgi.com Thu Mar 21 10:06:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LI6sa03588 for linux-xfs-outgoing; Thu, 21 Mar 2002 10:06:54 -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 g2LI6nq03562 for ; Thu, 21 Mar 2002 10:06:49 -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 g2LIEwkw015988 for ; Thu, 21 Mar 2002 12:14:58 -0600 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 LAA69043 for ; Thu, 21 Mar 2002 11:05:27 -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 LAA04211 for ; Thu, 21 Mar 2002 11:05:27 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id LAA54953 for linux-xfs@oss.sgi.com; Thu, 21 Mar 2002 11:05:27 -0600 (CST) Date: Thu, 21 Mar 2002 11:05:27 -0600 (CST) From: Dean Roehrich Message-Id: <200203211705.LAA54953@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi - add a dm_open_by_handle() to be used by dm_handle_to_path() Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Mar 21 09:05:14 PST 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:114627a linux/include/linux/dmapi.h - 1.8 - Add dm_open_by_handle() prototype. linux/include/linux/dmapi_kern.h - 1.9 - Define DM_OPEN_BY_HANDLE. linux/fs/xfs_dmapi/dmapi_right.c - 1.3 - Make dm_copyin_handle() non-static, so dm_open_by_handle_rvp() can use it. linux/fs/xfs_dmapi/dmapi_register.c - 1.7 - Add dm_open_by_handle_rvp(). linux/fs/xfs_dmapi/dmapi_private.h - 1.5 - Add prototypes for dm_open_by_handle_rvp() and dm_copyin_handle(). linux/fs/xfs_dmapi/dmapi_sysent.c - 1.3 - Add DM_OPEN_BY_HANDLE case. From owner-linux-xfs@oss.sgi.com Thu Mar 21 10:13:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LIDtE05292 for linux-xfs-outgoing; Thu, 21 Mar 2002 10:13:55 -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 g2LIDkq05266 for ; Thu, 21 Mar 2002 10:13:46 -0800 Received: from mta3-rme.xtra.co.nz (210-86-15-131.ipnets.xtra.co.nz [210.86.15.131]) 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 FAA08692 for ; Thu, 21 Mar 2002 05:02:48 -0800 (PST) mail_from (mdew@orcon.net.nz) Received: from localhost.localdomain ([210.86.52.154]) by mta3-rme.xtra.co.nz with ESMTP id <20020321125737.HCEH20246.mta3-rme.xtra.co.nz@localhost.localdomain>; Fri, 22 Mar 2002 00:57:37 +1200 Subject: Re: XFS and kernel 2.5.x From: mdew To: GCS Cc: xfs In-Reply-To: <20020321122940.A26364@lsc.hu> References: <20020321122940.A26364@lsc.hu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 22 Mar 2002 00:57:47 +1200 Message-Id: <1016715468.9401.10.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk the only person who can answer that is Linus. > Hi! > > Is XFS part of the kernel as version 2.5.x? If not, why, and when it will be > included? > > 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 -- ph33r! Linux mdew 2.4.18-xfs-preemptive #9 Tue Feb 26 11:45:49 NZDT 2002 i686 unknown From owner-linux-xfs@oss.sgi.com Thu Mar 21 10:36:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LIaHu06067 for linux-xfs-outgoing; Thu, 21 Mar 2002 10:36:17 -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 g2LIa9q06041 for ; Thu, 21 Mar 2002 10:36:09 -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 g2LIa2BA002478 for ; Thu, 21 Mar 2002 10:36:02 -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 LAA69525 for ; Thu, 21 Mar 2002 11:34:47 -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 LAA21660 for ; Thu, 21 Mar 2002 11:34:47 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id LAA89587 for linux-xfs@oss.sgi.com; Thu, 21 Mar 2002 11:34:47 -0600 (CST) Date: Thu, 21 Mar 2002 11:34:47 -0600 (CST) From: Dean Roehrich Message-Id: <200203211734.LAA89587@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix dm_handle_to_path() Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk dm_handle_to_path() will now work in most cases, and in the other cases there's just a little more grunt work that has to be done in the library. If the directory that contains some component of the path has never had a lookup performed on it, then the kernel won't have that dir in its dcache. In that case it'll create an anonymous dentry for the filesystem's root dir, and the library detects that this happened. If the library detects that an anonymous dentry was created, then it returns an error indicating that it didn't find the path. Before I take this another step, I'd like to know if this scenario happens in actual practice. I'm betting the directory of interest has almost always been loaded into the dcache by a user process before the HSM uses dm_handle_to_path(). We'll see. It seems that ioctl(XFS_IOC_OPEN_BY_HANDLE) would have the same restriction, though it looks like it's never used in a case where the path hasn't already been accessed. This mod also removes libdm's dependence on libhandle. Date: Thu Mar 21 09:33:31 PST 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:114629a cmd/dmapi/configure.in - 1.13 - Remove check for libhandle. cmd/dmapi/VERSION - 1.10 - update revision cmd/dmapi/man/man3/dmapi.3 - 1.3 - Update, libhandle no longer required. cmd/dmapi/include/dmapi_kern.h - 1.3 - sync with kernel side cmd/dmapi/include/dmapi.h - 1.4 - sync with kernel side cmd/dmapi/debian/changelog - 1.9 - update cmd/dmapi/libdm/dm_handle2path.c - 1.7 - Use new DM_OPEN_BY_HANDLE call. Verify its results. cmd/dmapi/libdm/dm_handle.c - 1.4 - cleanup junk cmd/dmapi/libdm/dmapi_lib.c - 1.7 - Add DM_OPEN_BY_HANDLE case. cmd/dmapi/libdm/Makefile - 1.7 - Do not look for libhandle. From owner-linux-xfs@oss.sgi.com Thu Mar 21 10:44:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LIigH06284 for linux-xfs-outgoing; Thu, 21 Mar 2002 10:44:42 -0800 Received: from com.esnaola.org (postfix@aboukir-101-1-5-ldarnis.adsl.nerim.net [80.65.225.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LIicq06258 for ; Thu, 21 Mar 2002 10:44:38 -0800 Received: from localhost.localdomain (unknown [192.168.33.18]) by com.esnaola.org (Microsoft Exchange) with ESMTP id 76074474D5 for ; Thu, 21 Mar 2002 18:42:42 +0100 (CET) Subject: kernel 2.2.20 From: Lionel DARNIS To: linux-xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 21 Mar 2002 18:42:56 +0100 Message-Id: <1016732577.7611.1.camel@neotrantor> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi ! Can I use the Kernel 2.2.20 with XFS ? If yes how ? which patch ? Thanx for your help. Lionel From owner-linux-xfs@oss.sgi.com Thu Mar 21 10:53:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LIrR806497 for linux-xfs-outgoing; Thu, 21 Mar 2002 10:53:27 -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 g2LIrOq06471 for ; Thu, 21 Mar 2002 10:53:24 -0800 Received: from user-uivf38j.dsl.mindspring.com ([165.247.141.19] helo=sandbox.wingenbach.org) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16o6kV-0001TR-00 for linux-xfs@oss.sgi.com; Thu, 21 Mar 2002 12:53:15 -0500 Received: from wingenbach.org (jwinglap.wingenbach.org [10.10.10.25]) by sandbox.wingenbach.org (8.11.4/8.11.4) with ESMTP id g2LHqwp15056 for ; Thu, 21 Mar 2002 12:52:58 -0500 (EST) Message-ID: <3C9A1E06.729AC72C@wingenbach.org> Date: Thu, 21 Mar 2002 12:53:10 -0500 From: John Wingenbach X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: XFS mailing list Subject: xfsprogs Makepkgs fails to make rpm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have been working on a RH 7.2 based system and found that the normal Makepkgs fails to build the rpm. From what I can tell/understand, it is due to the new rpm. Instead of using rpm to build packages, rpmbuild is used. I temporarily changed my rpm to be a link to rpmbuild and the rpm packages built successfully. -- John Wingenbach From owner-linux-xfs@oss.sgi.com Thu Mar 21 10:53:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LIru307213 for linux-xfs-outgoing; Thu, 21 Mar 2002 10:53:56 -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 g2LIrrq07153 for ; Thu, 21 Mar 2002 10:53:53 -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 g2LIrkBA003295 for ; Thu, 21 Mar 2002 10:53:46 -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 LAA69880 for ; Thu, 21 Mar 2002 11:52: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 LAA84393 for ; Thu, 21 Mar 2002 11:52:30 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id LAA88385 for linux-xfs@oss.sgi.com; Thu, 21 Mar 2002 11:52:30 -0600 (CST) Date: Thu, 21 Mar 2002 11:52:30 -0600 (CST) From: Dean Roehrich Message-Id: <200203211752.LAA88385@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix dmapi test handle_to_path to accept handles Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Mar 21 09:51:53 PST 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:114634a cmd/xfstests/dmapi/src/suite1/cmd/handle_to_path.c - 1.6 - Allow user to specify handles, rather than paths which the tool will then turn into handles. This allows the test to work without cheating :) That is, it can be used without causing the kernel's dnlc/dcache to be preloaded. From owner-linux-xfs@oss.sgi.com Thu Mar 21 10:55:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LItBf07487 for linux-xfs-outgoing; Thu, 21 Mar 2002 10:55:11 -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 g2LIt4q07461 for ; Thu, 21 Mar 2002 10:55:04 -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 g2LIswBA003354 for ; Thu, 21 Mar 2002 10:54:58 -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 LAA16833 for ; Thu, 21 Mar 2002 11:53:42 -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 LAA52874 for ; Thu, 21 Mar 2002 11:53:42 -0600 (CST) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id LAA77213 for linux-xfs@oss.sgi.com; Thu, 21 Mar 2002 11:53:42 -0600 (CST) Date: Thu, 21 Mar 2002 11:53:42 -0600 (CST) From: Dean Roehrich Message-Id: <200203211753.LAA77213@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi test suite no longer relies on libhandle Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Mar 21 09:53:32 PST 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:114635a cmd/xfstests/dmapi/Makefile.in - 1.4 - No Message Supplied cmd/xfstests/dmapi/configure.in - 1.3 - No Message Supplied cmd/xfstests/dmapi/aclocal.m4 - 1.3 - No Message Supplied cmd/xfstests/dmapi/src/Makefile.in - 1.4 - No Message Supplied cmd/xfstests/dmapi/src/suite2/Makefile.in - 1.4 - No Message Supplied cmd/xfstests/dmapi/src/suite2/src/Makefile.am - 1.2 - No Message Supplied cmd/xfstests/dmapi/src/suite2/src/Makefile.in - 1.4 - No Message Supplied cmd/xfstests/dmapi/src/suite1/Makefile.in - 1.4 - No Message Supplied cmd/xfstests/dmapi/src/suite1/cmd/Makefile.in - 1.4 - No Message Supplied cmd/xfstests/dmapi/src/simple/Makefile.in - 1.4 - No Message Supplied cmd/xfstests/dmapi/src/sample_hsm/Makefile.in - 1.5 - No Message Supplied cmd/xfstests/dmapi/src/common/Makefile.in - 1.4 - No Message Supplied cmd/xfstests/dmapi/src/common/cmd/Makefile.in - 1.4 - No Message Supplied cmd/xfstests/dmapi/src/common/lib/Makefile.in - 1.4 - No Message Supplied From owner-linux-xfs@oss.sgi.com Thu Mar 21 11:13:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJD4j08459 for linux-xfs-outgoing; Thu, 21 Mar 2002 11:13: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 g2LJCwq08433 for ; Thu, 21 Mar 2002 11:12:58 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2LJCqBA004554 for ; Thu, 21 Mar 2002 11:12:52 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA79869; Thu, 21 Mar 2002 12:11:35 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.35 #1 (Debian)) id 16o72E-0000We-00; Thu, 21 Mar 2002 12:11:34 -0600 Date: Thu, 21 Mar 2002 12:11:34 -0600 From: Nathan Straz To: Lionel DARNIS Cc: linux-xfs Subject: Re: kernel 2.2.20 Message-ID: <20020321181134.GL32176@sgi.com> Mail-Followup-To: Lionel DARNIS , linux-xfs References: <1016732577.7611.1.camel@neotrantor> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1016732577.7611.1.camel@neotrantor> User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 21, 2002 at 06:42:56PM +0100, Lionel DARNIS wrote: > Can I use the Kernel 2.2.20 with XFS ? XFS is not available for 2.2.x series Linux kernels. All development is being done for 2.4.x and later kernels. There are no plans to work on XFS for 2.2.x series kernels. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Thu Mar 21 11:34:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJYgY09056 for linux-xfs-outgoing; Thu, 21 Mar 2002 11:34:42 -0800 Received: from server-18.tower-16.messagelabs.com (mail16.messagelabs.com [64.124.170.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LJYaq09030 for ; Thu, 21 Mar 2002 11:34:36 -0800 X-VirusChecked: Checked Received: (qmail 11107 invoked from network); 21 Mar 2002 18:34:22 -0000 Received: from mail.tapeware.com (HELO yt-internet.tapeware.com) (4.21.59.10) by server-18.tower-16.messagelabs.com with SMTP; 21 Mar 2002 18:34:22 -0000 Received: from BRONCO (192.168.0.117 [192.168.0.117]) by yt-internet.tapeware.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDHGSWKY; Thu, 21 Mar 2002 10:32:50 -0800 From: "Quang Nguyen \(Ngo\)" To: "Nathan Scott" Cc: "Eric Sandeen" , Subject: RE: mkfs.xfs Fails Date: Thu, 21 Mar 2002 10:34:22 -0800 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020321164320.F23600@wobbly.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk From: Nathan Scott [mailto:nathans@sgi.com] +--------------------------------------------------------------------------- | > Anyway, I ran mkfs.ext2 and mkfs.reiserfs and they both formatted it fine. | > Just that mkfs.xfs -f /dev/hdb2 thinks it's busy or in use. | | That's very odd -- can you run "strace mkfs.xfs -f /dev/hdb2" and | send the output? That will tell us where to start looking in mkfs. +--------------------------------------------------------------------------- In one occasion, my program puts back the original /etc/mtab and that happens to have /dev/hdb2 mounted. mkfs.xfs is nice enough to verify that I shouldn't be formatting a mounted partition. I gdb'ed it and it was obvious. Duhh! Thanks guys, Quang ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________ From owner-linux-xfs@oss.sgi.com Thu Mar 21 11:14:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJEHm10535 for linux-xfs-outgoing; Thu, 21 Mar 2002 11:14:17 -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 g2LJECq10509 for ; Thu, 21 Mar 2002 11:14: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 g2LJGU6G009860 for ; Thu, 21 Mar 2002 11:16:30 -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 NAA71449 for ; Thu, 21 Mar 2002 13:15:15 -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 NAA13729 for ; Thu, 21 Mar 2002 13:15:14 -0600 (CST) Subject: [Announce] XFS 1.1 Prerelease 2 available for testing From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 21 Mar 2002 13:15:14 -0600 Message-Id: <1016738115.30196.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At long last, a prerelease of the upcoming XFS 1.1 release is available at ftp://oss.sgi.com/projects/xfs/download/testing/xfs-1.1 These packages are a pre-release of the upcoming 1.1 release of XFS for Linux. They have been sanity-checked, but not heavily tested at SGI, and as such are intended for testing purposes. They may in fact be bulletproof, but that's for you to decide before you use them in a critical environment! The XFS code in this release is very close to what is currently in CVS, with some of the most recent, least tested changes omitted. Kernels are available for x86 and ia64, based both on the vanilla Linux 2.4.18 kernel, and on the Red Hat 2.4.9-31 kernel release. Please test 'em, benchmark 'em, break 'em, and let us know what you find. Thanks, -Eric -- 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 21 11:39:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJdgt11127 for linux-xfs-outgoing; Thu, 21 Mar 2002 11:39:42 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LJdOq11097 for ; Thu, 21 Mar 2002 11:39:25 -0800 Received: (qmail 22451 invoked by uid 1000); 21 Mar 2002 19:48:38 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Mar 2002 19:48:38 -0000 Date: Thu, 21 Mar 2002 21:48:38 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Eric Sandeen cc: Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing In-Reply-To: <1016738115.30196.4.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric Cool! First of all what is the recommended compiler for the sources ? 2.95.3 as per Documentation/Changes ? :) On 21 Mar 2002, Eric Sandeen wrote: > At long last, a prerelease of the upcoming XFS 1.1 release is available > at > > ftp://oss.sgi.com/projects/xfs/download/testing/xfs-1.1 > > > These packages are a pre-release of the upcoming 1.1 release of XFS > for Linux. They have been sanity-checked, but not heavily tested > at SGI, and as such are intended for testing purposes. > > They may in fact be bulletproof, but that's for you to decide > before you use them in a critical environment! > > The XFS code in this release is very close to what is currently in CVS, > with some of the most recent, least tested changes omitted. > > Kernels are available for x86 and ia64, based both on the vanilla Linux > 2.4.18 kernel, and on the Red Hat 2.4.9-31 kernel release. > > Please test 'em, benchmark 'em, break 'em, and let us know what you > find. > > Thanks, > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > > ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Thu Mar 21 11:44:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJip011321 for linux-xfs-outgoing; Thu, 21 Mar 2002 11:44: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 g2LJilq11294 for ; Thu, 21 Mar 2002 11:44:47 -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 g2LJl66G012485 for ; Thu, 21 Mar 2002 11:47:06 -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 NAA72304; Thu, 21 Mar 2002 13:45:50 -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 NAA84991; Thu, 21 Mar 2002 13:45:50 -0600 (CST) Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Eric Sandeen To: Mihai RUSU 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: 21 Mar 2002 13:45:50 -0600 Message-Id: <1016739950.30176.8.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The RPMs are still compiled with "kgcc" for x86... Steve has been using gcc-2.96-101 with good success. I think that 2.95.x is not so good. If anyone has had problems with one compiler, that were solved by changing to kgcc or a newer compiler, please chime in... I _really_ hope that some day this question can go away. :) -Eric On Thu, 2002-03-21 at 13:48, Mihai RUSU wrote: > Hi Eric > > Cool! > First of all what is the recommended compiler for the sources ? 2.95.3 as > per Documentation/Changes ? :) -- 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 21 11:47:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJlp811510 for linux-xfs-outgoing; Thu, 21 Mar 2002 11:47:51 -0800 Received: from k1.hq.pnp-group.com ([65.163.202.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LJllq11484 for ; Thu, 21 Mar 2002 11:47:48 -0800 Received: from navizpro ([192.168.1.200]) by k1.hq.pnp-group.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Mar 2002 14:50:03 -0500 Message-ID: <021301c1d111$a212b9f0$c801a8c0@hq.pnpgroup.com> From: To: "Eric Sandeen" Cc: References: <1016739950.30176.8.camel@stout.americas.sgi.com> Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Date: Thu, 21 Mar 2002 14:50:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 21 Mar 2002 19:50:03.0211 (UTC) FILETIME=[97A819B0:01C1D111] Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk | gcc-2.96-101 with good success. I think that 2.95.x is not so good. 2.95.x not so good? That's a little scary to me... could you explain why you feel that way? | I _really_ hope that some day this question can go away. :) I'll second that... z. From owner-linux-xfs@oss.sgi.com Thu Mar 21 11:50:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LJo5n11667 for linux-xfs-outgoing; Thu, 21 Mar 2002 11:50:05 -0800 Received: from mailnet.consensys.com ([209.47.40.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LJo2q11640 for ; Thu, 21 Mar 2002 11:50:02 -0800 Received: from Francis ([209.47.40.10]) by mailnet.consensys.com (8.11.6/8.11.2) with SMTP id g2LElLW01313 for ; Thu, 21 Mar 2002 14:47:21 GMT Message-ID: <007701c1d111$ee53c0c0$8d02a8c0@consensys.com> From: "Francis Qu" To: "Linux XFS" Subject: DMAPI Attribute Event and Append Date: Thu, 21 Mar 2002 14:52:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Dean, When appending data to the end of a file, the file modification time and change time are updated. But this operation cannot be caught as an attribute event. Do you have any idea about it? Thanks a lot. Francis From owner-linux-xfs@oss.sgi.com Thu Mar 21 12:02:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LK2C920365 for linux-xfs-outgoing; Thu, 21 Mar 2002 12:02: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 g2LK25q20339 for ; Thu, 21 Mar 2002 12:02: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 g2LK4N6G013935 for ; Thu, 21 Mar 2002 12:04:23 -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 OAA71432; Thu, 21 Mar 2002 14:03:08 -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 OAA20383; Thu, 21 Mar 2002 14:03:07 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id OAA12756; Thu, 21 Mar 2002 14:03:07 -0600 (CST) Message-Id: <200203212003.OAA12756@slobber.americas.sgi.com> To: "Francis Qu" cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI dm_set_region Date: Thu, 21 Mar 2002 14:03:07 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "Francis Qu" >When DMAPI application tries to do dm_set_region on a file which is opened for > write, both DMAPI application and the user application doing the write operat >ion are blocked. The DMAPI application won't come back from dm_set_region util >l the user cancels the write job. What are you using to hold the file open? It is just an open(O_RDWR), or are you also currently in a write(2) or do you currently have it mmaped? If mmapped, is it private or shared? Can you give me a small C test program to hold the file open in a way which allows this behavior to be seen? > Is it the way DMAPI works? Doesn't sound like desirable behavior :) Dean From owner-linux-xfs@oss.sgi.com Thu Mar 21 12:03:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LK3a020504 for linux-xfs-outgoing; Thu, 21 Mar 2002 12:03:36 -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 g2LK3Wq20478 for ; Thu, 21 Mar 2002 12:03:32 -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 g2LK5p6G014087 for ; Thu, 21 Mar 2002 12:05:51 -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 OAA71918; Thu, 21 Mar 2002 14:04:36 -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 OAA02728; Thu, 21 Mar 2002 14:04:35 -0600 (CST) Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Eric Sandeen To: z@pnp-group.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <021301c1d111$a212b9f0$c801a8c0@hq.pnpgroup.com> References: <1016739950.30176.8.camel@stout.americas.sgi.com> <021301c1d111$a212b9f0$c801a8c0@hq.pnpgroup.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 21 Mar 2002 14:04:35 -0600 Message-Id: <1016741075.30176.19.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-03-21 at 13:50, z@pnp-group.com wrote: > | gcc-2.96-101 with good success. I think that 2.95.x is not so good. > > 2.95.x not so good? That's a little scary to me... > could you explain why you feel that way? > > | I _really_ hope that some day this question can go away. :) > > I'll second that... xfs exposed some bugs in the 2.95 series, there were reports of 2.95.2 miscompiling, 2.95.3 may be better... -Eric -- 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 21 12:15:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LKFlC20908 for linux-xfs-outgoing; Thu, 21 Mar 2002 12:15:47 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LKFbq20880 for ; Thu, 21 Mar 2002 12:15:38 -0800 Received: (qmail 27119 invoked by uid 1000); 21 Mar 2002 20:24:48 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Mar 2002 20:24:48 -0000 Date: Thu, 21 Mar 2002 22:24:48 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing In-Reply-To: <1016741075.30176.19.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 21 Mar 2002, Eric Sandeen wrote: > xfs exposed some bugs in the 2.95 series, there were reports of 2.95.2 > miscompiling, 2.95.3 may be better... > Uff ! This just mixes the things more :( Now, acording to RedHat (http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56603) the recommended compiler for the latest of their kernels is 2.95.3 at least. I dont have a RedHat distro arround so I am not sure but isnt kgcc in fact egcs-2.91.66 ? By using kgcc (egcs-2.91.66) to compile that kernel it should be wrong ... :) ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Thu Mar 21 12:32:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LKWHI21279 for linux-xfs-outgoing; Thu, 21 Mar 2002 12:32:17 -0800 Received: from mailnet.consensys.com ([209.47.40.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LKW8q21249 for ; Thu, 21 Mar 2002 12:32:08 -0800 Received: from Francis ([209.47.40.10]) by mailnet.consensys.com (8.11.6/8.11.2) with SMTP id g2LFSkW15750; Thu, 21 Mar 2002 15:28:47 GMT Message-ID: <00a501c1d117$b8337e80$8d02a8c0@consensys.com> From: "Francis Qu" To: "Dean Roehrich" Cc: "Linux XFS" References: <200203212003.OAA12756@slobber.americas.sgi.com> Subject: Re: DMAPI dm_set_region Date: Thu, 21 Mar 2002 15:33:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Dean, 1. A piece of test code is as below: ... int i, n; int fd; fd = open(argv[1], O_WRONLY); if (fd == -1) { perror("open file failed"); return 0; } for (i = 0; i < 100; ++i) { n = write(fd, &i, sizeof(i)); if (n == -1) { perror("write error"); break; } printf("write %d bytes: %d\n", n, i); } close(fd); ... 2. It doesn't work in such case as: $ cat >> filename Thanks, Francis ----- Original Message ----- From: "Dean Roehrich" To: "Francis Qu" Cc: Sent: Thursday, March 21, 2002 3:03 PM Subject: Re: DMAPI dm_set_region > > >From: "Francis Qu" > >When DMAPI application tries to do dm_set_region on a file which is opened for > > write, both DMAPI application and the user application doing the write operat > >ion are blocked. The DMAPI application won't come back from dm_set_region util > >l the user cancels the write job. > > What are you using to hold the file open? It is just an open(O_RDWR), or are > you also currently in a write(2) or do you currently have it mmaped? If > mmapped, is it private or shared? > > Can you give me a small C test program to hold the file open in a way which > allows this behavior to be seen? > > > Is it the way DMAPI works? > > Doesn't sound like desirable behavior :) > > Dean From owner-linux-xfs@oss.sgi.com Thu Mar 21 12:36:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LKa1q21464 for linux-xfs-outgoing; Thu, 21 Mar 2002 12:36:01 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LKZtq21437 for ; Thu, 21 Mar 2002 12:35:55 -0800 Received: (qmail 14291 invoked by uid 500); 21 Mar 2002 20:37:44 -0000 Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Austin Gonyou To: Eric Sandeen Cc: z@pnp-group.com, linux-xfs@oss.sgi.com In-Reply-To: <1016741075.30176.19.camel@stout.americas.sgi.com> References: <1016741075.30176.19.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 21 Mar 2002 14:37:44 -0600 Message-Id: <1016743064.13665.12.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Personally I use gcc 3.0.3 or 3.0.4, I've yet to have things happen which cannot be explained. On Thu, 2002-03-21 at 14:04, Eric Sandeen wrote: > On Thu, 2002-03-21 at 13:50, z@pnp-group.com wrote: > > | gcc-2.96-101 with good success. I think that 2.95.x is not so good. > > > > 2.95.x not so good? That's a little scary to me... > > could you explain why you feel that way? > > > > | I _really_ hope that some day this question can go away. :) > > > > I'll second that... > > xfs exposed some bugs in the 2.95 series, there were reports of 2.95.2 > miscompiling, 2.95.3 may be better... > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- 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 Thu Mar 21 12:44:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LKi3x21717 for linux-xfs-outgoing; Thu, 21 Mar 2002 12:44:03 -0800 Received: from piaskowy (promien.prz.rzeszow.pl [212.160.98.116]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LKhoq21691 for ; Thu, 21 Mar 2002 12:43:51 -0800 Received: from piaskowy.internal.prz.rzeszow.pl (localhost [127.0.0.1]) by piaskowy (8.12.2/8.12.2/Debian -4) with ESMTP id g2LKjwsx013098; Thu, 21 Mar 2002 21:45:58 +0100 Received: (from mzieba@localhost) by piaskowy.internal.prz.rzeszow.pl (8.12.2/8.12.2/Debian -4) id g2LKjgDa013096; Thu, 21 Mar 2002 21:45:42 +0100 Date: Thu, 21 Mar 2002 21:45:41 +0100 From: Marcin Zieba To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Oops on 2.4.17, some fs corruption. Message-ID: <20020321204541.GA12990@prz-rzeszow.pl> References: <20020318205727.GA1462@prz-rzeszow.pl> <1016495015.2713.24.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1016495015.2713.24.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric, I applied patch, which you provided to me, and for some time, it is stable. I was trying to put load on fs, it pass all things, and everything is working ok. :) Once again, thanks. -- Marcin Zieba mzieba@prz-rzeszow.pl From owner-linux-xfs@oss.sgi.com Thu Mar 21 12:55:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LKtxK22069 for linux-xfs-outgoing; Thu, 21 Mar 2002 12:55:59 -0800 Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LKtsq22042 for ; Thu, 21 Mar 2002 12:55:55 -0800 Received: from slc-unislc.slc.unisys.com ([192.60.174.32]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id UAA21565; Thu, 21 Mar 2002 20:56:43 GMT Received: from localhost.localdomain (slc-knysna.slc.unisys.com [192.60.130.30]) by slc-unislc.slc.unisys.com (8.9.3/UW7.1.1) with ESMTP id NAA20793; Thu, 21 Mar 2002 13:57:37 -0700 (MST) Received: from there (slc-knysna [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with SMTP id g2LKvaR30093; Thu, 21 Mar 2002 13:57:36 -0700 Message-Id: <200203212057.g2LKvaR30093@localhost.localdomain> Content-Type: text/plain; charset="iso-8859-1" From: Warren Stockton Reply-To: wns@slc.unisys.com To: Eric Sandeen , Mihai RUSU Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Date: Thu, 21 Mar 2002 13:57:36 -0700 X-Mailer: KMail [version 1.3.2] Cc: linux-xfs@oss.sgi.com References: <1016739950.30176.8.camel@stout.americas.sgi.com> In-Reply-To: <1016739950.30176.8.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk What compiler would you recommend for ia64? Warren. On Thursday 21 March 2002 12:45, Eric Sandeen wrote: > The RPMs are still compiled with "kgcc" for x86... Steve has been using > gcc-2.96-101 with good success. I think that 2.95.x is not so good. If > anyone has had problems with one compiler, that were solved by changing > to kgcc or a newer compiler, please chime in... > > I _really_ hope that some day this question can go away. :) > > -Eric > > On Thu, 2002-03-21 at 13:48, Mihai RUSU wrote: > > Hi Eric > > > > Cool! > > First of all what is the recommended compiler for the sources ? 2.95.3 as > > per Documentation/Changes ? :) From owner-linux-xfs@oss.sgi.com Thu Mar 21 13:31:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LLV3d22782 for linux-xfs-outgoing; Thu, 21 Mar 2002 13:31:03 -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 g2LLV0q22756 for ; Thu, 21 Mar 2002 13:31:00 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2LMfZkw019685 for ; Thu, 21 Mar 2002 16:41:35 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA77907 for ; Thu, 21 Mar 2002 15:32:02 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.35 #1 (Debian)) id 16oAAD-0003mh-00 for ; Thu, 21 Mar 2002 15:32:01 -0600 Date: Thu, 21 Mar 2002 15:32:01 -0600 From: Nathan Straz To: linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Message-ID: <20020321213201.GO32176@sgi.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1016739950.30176.8.camel@stout.americas.sgi.com> <200203212057.g2LKvaR30093@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203212057.g2LKvaR30093@localhost.localdomain> User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 21, 2002 at 01:57:36PM -0700, Warren Stockton wrote: > What compiler would you recommend for ia64? We are still building ia64 kernels with 2.96 (-85 or -101) and we haven't found any compiler related issues yet. David Mosberger is compiling ia64 kernels with gcc 3.0, but I doubt he's compiling XFS in his kernels. The general concensus on the linux-ia64 list is that gcc 3.1 doesn't compile bootable ia64 kernels. So all I can recommand now is staying with 2.96. I would like to hear any success stories with 3.0 or later compilers. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Thu Mar 21 14:20:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LMKQh25074 for linux-xfs-outgoing; Thu, 21 Mar 2002 14:20:26 -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 g2LMKKq25048 for ; Thu, 21 Mar 2002 14:20:20 -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 g2LNMcBA024466 for ; Thu, 21 Mar 2002 15:22:39 -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 JAA21472; Fri, 22 Mar 2002 09:21:22 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA26627; Fri, 22 Mar 2002 09:21:20 +1100 (AEDT) Date: Fri, 22 Mar 2002 09:21:20 +1100 From: Nathan Scott To: John Wingenbach Cc: XFS mailing list Subject: Re: xfsprogs Makepkgs fails to make rpm Message-ID: <20020322092120.L23600@wobbly.melbourne.sgi.com> References: <3C9A1E06.729AC72C@wingenbach.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C9A1E06.729AC72C@wingenbach.org>; from xfs@wingenbach.org on Thu, Mar 21, 2002 at 12:53:10PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 21, 2002 at 12:53:10PM -0500, John Wingenbach wrote: > I have been working on a RH 7.2 based system and found that the normal > Makepkgs fails to build the rpm. From what I can tell/understand, it is > due to the new rpm. Instead of using rpm to build packages, rpmbuild is > used. I temporarily changed my rpm to be a link to rpmbuild and the rpm > packages built successfully. > hi John, I've built using the normal Makepkgs several times on RH7.2 with no problems. Can you provide some more details on the nature of the problem you see? (how does it fail? Logs/* messages, etc) thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 21 14:39:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LMdio25462 for linux-xfs-outgoing; Thu, 21 Mar 2002 14:39:44 -0800 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LMdbq25436 for ; Thu, 21 Mar 2002 14:39:37 -0800 Received: from user-uivf38j.dsl.mindspring.com ([165.247.141.19] helo=sandbox.wingenbach.org) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 16oBFq-0002T8-00; Thu, 21 Mar 2002 17:41:54 -0500 Received: from wingenbach.org (jwinglap.wingenbach.org [10.10.10.25]) by sandbox.wingenbach.org (8.11.4/8.11.4) with ESMTP id g2LMfap17636; Thu, 21 Mar 2002 17:41:36 -0500 (EST) Message-ID: <3C9A61AC.E9FAE3EB@wingenbach.org> Date: Thu, 21 Mar 2002 17:41:48 -0500 From: John Wingenbach X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott CC: John Wingenbach , XFS mailing list Subject: Re: xfsprogs Makepkgs fails to make rpm References: <3C9A1E06.729AC72C@wingenbach.org> <20020322092120.L23600@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Nathan, The problem I am seeing is the same thing I saw when building another rpm myself. When I try to run: rpm -bANYTHING specfile I always get: No such file or directory >From searching the net, all I could find was a recommendation to use rpmbuild instead of rpm. When I did that, it worked perfectly. The Makepkgs run also is trying to perform a "rpm" build. Simply fooling Makepkgs into using rpmbuild instead of rpm built the rpms. The rpm versions I have installed are: rpm-4.0.3-1.03 rpmbuild-4.0.3-1.03 rpm-python-4.0.3-1.03 Nathan Scott wrote: > On Thu, Mar 21, 2002 at 12:53:10PM -0500, John Wingenbach wrote: > > I have been working on a RH 7.2 based system and found that the normal > > Makepkgs fails to build the rpm. From what I can tell/understand, it is > > due to the new rpm. Instead of using rpm to build packages, rpmbuild is > > used. I temporarily changed my rpm to be a link to rpmbuild and the rpm > > packages built successfully. > > > > hi John, > > I've built using the normal Makepkgs several times on RH7.2 with > no problems. Can you provide some more details on the nature of > the problem you see? (how does it fail? Logs/* messages, etc) > > thanks. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 21 14:53:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LMr0s25828 for linux-xfs-outgoing; Thu, 21 Mar 2002 14:53:00 -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 g2LMqrq25801 for ; Thu, 21 Mar 2002 14:52:53 -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 g2M03Okw020690 for ; Thu, 21 Mar 2002 18:03:25 -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 JAA21697; Fri, 22 Mar 2002 09:53:51 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA26711; Fri, 22 Mar 2002 09:53:50 +1100 (AEDT) Date: Fri, 22 Mar 2002 09:53:49 +1100 From: Nathan Scott To: John Wingenbach Cc: XFS mailing list Subject: Re: xfsprogs Makepkgs fails to make rpm Message-ID: <20020322095349.M23600@wobbly.melbourne.sgi.com> References: <3C9A1E06.729AC72C@wingenbach.org> <20020322092120.L23600@wobbly.melbourne.sgi.com> <3C9A61AC.E9FAE3EB@wingenbach.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C9A61AC.E9FAE3EB@wingenbach.org>; from xfs@wingenbach.org on Thu, Mar 21, 2002 at 05:41:48PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 21, 2002 at 05:41:48PM -0500, John Wingenbach wrote: > Hi Nathan, > > The problem I am seeing is the same thing I saw when building another rpm > myself. When I try to run: > > rpm -bANYTHING specfile > > I always get: > No such file or directory That sounds like your rpm installation is borken - I'm not sure exactly how it got in that state though. Just as a second workaround, you could set RPM=/bin/rpmbuild in the environment before the build and it will use that in preference (with no Makefile changes, etc). What does "strace rpm -bANYTHING specfile" list as the file that is not found? > >From searching the net, all I could find was a recommendation to use rpmbuild > instead of rpm. When I did that, it worked perfectly. The Makepkgs run also > is trying to perform a "rpm" build. Simply fooling Makepkgs into using > rpmbuild instead of rpm built the rpms. > > The rpm versions I have installed are: > rpm-4.0.3-1.03 > rpmbuild-4.0.3-1.03 > rpm-python-4.0.3-1.03 > The only difference between your Redhat machine and mine is that # rpm -q rpm rpmbuild rpm-python rpm-4.0.3-1.03 package rpmbuild is not installed rpm-python-4.0.3-1.03 Oh, wait I have: # rpm -q -f `which rpmbuild` rpm-build-4.0.3-1.03 Was that a typo above in your list? Anyway, maybe you should try a fresh install of rpm - sounds like something is fishy on your machine (maybe try compare your machine to another with similar config to see whats different?) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 21 15:00:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LN0sI26136 for linux-xfs-outgoing; Thu, 21 Mar 2002 15:00:54 -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 g2LN0lq26109 for ; Thu, 21 Mar 2002 15:00:49 -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 g2LN346G025198 for ; Thu, 21 Mar 2002 15:03:05 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA45150; Fri, 22 Mar 2002 10:01:48 +1100 (EST) Date: Fri, 22 Mar 2002 10:01:48 +1100 (EST) From: Nathan Scott Message-Id: <200203212301.KAA45150@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: ag@muriel.parsec.at Subject: TAKE - acl_to_text Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Mar 21 15:01:12 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:114666a acl/doc/CHANGES - 1.25 acl/libacl/acl_to_text.c - 1.3 - Fix up acl_to_text compliance with POSIX draft (from Andreas). From owner-linux-xfs@oss.sgi.com Thu Mar 21 16:50:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M0oaD28045 for linux-xfs-outgoing; Thu, 21 Mar 2002 16:50:36 -0800 Received: from saiya-jin.flinthills.com (saiya-jin.flinthills.com [64.39.192.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M0oMq28017 for ; Thu, 21 Mar 2002 16:50:23 -0800 Received: from saiya-jin.flinthills.com (localhost.flinthills.com [127.0.0.1]) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -3) with ESMTP id g2M0mitt005898 for ; Thu, 21 Mar 2002 18:48:44 -0600 Received: (from cappicard@localhost) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -3) id g2M0mhvM005896; Thu, 21 Mar 2002 18:48:43 -0600 X-Authentication-Warning: saiya-jin.flinthills.com: cappicard set sender to djw@flinthills.com using -f Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Derek James Witt To: Linux XFS In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4wmIIDL2x6fo7NurpvVb" X-Mailer: Evolution/1.0.2 Date: 21 Mar 2002 18:48:43 -0600 Message-Id: <1016758123.5851.3.camel@saiya-jin.flinthills.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-4wmIIDL2x6fo7NurpvVb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi Mihai. I'm using 2.95.4 to compile the kernel and the XFS utilities from CVS. It's working fine for me here. On Thu, 2002-03-21 at 13:48, Mihai RUSU wrote: > Hi Eric >=20 > Cool! > First of all what is the recommended compiler for the sources ? 2.95.3 as > per Documentation/Changes ? :) >=20 >=20 > On 21 Mar 2002, Eric Sandeen wrote: >=20 > > At long last, a prerelease of the upcoming XFS 1.1 release is available > > at > > > > ftp://oss.sgi.com/projects/xfs/download/testing/xfs-1.1 > > > > > > These packages are a pre-release of the upcoming 1.1 release of XFS > > for Linux. They have been sanity-checked, but not heavily tested > > at SGI, and as such are intended for testing purposes. > > > > They may in fact be bulletproof, but that's for you to decide > > before you use them in a critical environment! > > > > The XFS code in this release is very close to what is currently in CVS, > > with some of the most recent, least tested changes omitted. > > > > Kernels are available for x86 and ia64, based both on the vanilla Linux > > 2.4.18 kernel, and on the Red Hat 2.4.9-31 kernel release. > > > > Please test 'em, benchmark 'em, break 'em, and let us know what you > > find. > > > > Thanks, > > > > -Eric > > > > -- > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > sandeen@sgi.com SGI, Inc. > > > > >=20 > ---------------------------- > Mihai RUSU >=20 > Disclaimer: Any views or opinions presented within this e-mail are solely > those of the author and do not necessarily represent those of any company, > unless otherwise specifically stated. --=20 ** Derek J Witt ** * Email: mailto:djw@flinthills.com * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** --=-4wmIIDL2x6fo7NurpvVb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8mn9qgnGXTpcv6TgRAgIeAKDFYzV78kozIR1TaP/Guf2V5RpKCwCfQ8iK 8NNLNTBEmkh+xssgGlA/7qM= =Lsjx -----END PGP SIGNATURE----- --=-4wmIIDL2x6fo7NurpvVb-- From owner-linux-xfs@oss.sgi.com Thu Mar 21 17:44:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M1i2O29118 for linux-xfs-outgoing; Thu, 21 Mar 2002 17:44:02 -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 g2M1huq29092 for ; Thu, 21 Mar 2002 17:43:56 -0800 Received: from localhost.localdomain ([210.86.52.154]) by mta4-rme.xtra.co.nz with ESMTP id <20020322014613.NTHE14382.mta4-rme.xtra.co.nz@localhost.localdomain>; Fri, 22 Mar 2002 13:46:13 +1200 Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: mdew To: Eric Sandeen Cc: z@pnp-group.com, xfs In-Reply-To: <1016741075.30176.19.camel@stout.americas.sgi.com> References: <1016739950.30176.8.camel@stout.americas.sgi.com> <021301c1d111$a212b9f0$c801a8c0@hq.pnpgroup.com> <1016741075.30176.19.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 22 Mar 2002 13:46:00 +1200 Message-Id: <1016761583.9819.29.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Whats with the support of a non-standard gcc release "RH's 2.96", wouldnt it be more appropriate to support *atleast* 2.95.x and 3.0x since these are official releases? http://gcc.gnu.org/gcc-2.96.html http://www.mplayerhq.hu/DOCS/gcc-2.96-3.0.html We dont live in a RH-centric world, so SGI should atleast support offical gcc-release versions. On Fri, 2002-03-22 at 08:04, Eric Sandeen wrote: > On Thu, 2002-03-21 at 13:50, z@pnp-group.com wrote: > > | gcc-2.96-101 with good success. I think that 2.95.x is not so good. > > > > 2.95.x not so good? That's a little scary to me... > > could you explain why you feel that way? > > > > | I _really_ hope that some day this question can go away. :) > > > > I'll second that... > > xfs exposed some bugs in the 2.95 series, there were reports of 2.95.2 > miscompiling, 2.95.3 may be better... > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- ph33r! Linux mdew 2.4.18-xfs-preemptive #9 Tue Feb 26 11:45:49 NZDT 2002 i686 unknown From owner-linux-xfs@oss.sgi.com Thu Mar 21 18:07:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M279x03031 for linux-xfs-outgoing; Thu, 21 Mar 2002 18:07:09 -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 g2M271q03005 for ; Thu, 21 Mar 2002 18:07:01 -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 g2M29J6G031798 for ; Thu, 21 Mar 2002 18:09:19 -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 UAA76362; Thu, 21 Mar 2002 20:08:04 -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 UAA92886; Thu, 21 Mar 2002 20:08:03 -0600 (CST) Date: Thu, 21 Mar 2002 20:08:03 -0600 (CST) From: Eric Sandeen X-X-Sender: To: mdew cc: , xfs Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing In-Reply-To: <1016761583.9819.29.camel@mdew> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 22 Mar 2002, mdew wrote: > Whats with the support of a non-standard gcc release "RH's 2.96", > wouldnt it be more appropriate to support *atleast* 2.95.x and 3.0x > since these are official releases? > > http://gcc.gnu.org/gcc-2.96.html > http://www.mplayerhq.hu/DOCS/gcc-2.96-3.0.html > > We dont live in a RH-centric world, so SGI should atleast support > offical gcc-release versions. Who said anything about supporting non-standard compilers? >From the beginning, we have said that gcc-2.91.66/egcs 1.1.2 is the compiler of choice for xfs. This is not RH-centric. http://gcc.gnu.org/egcs-1.1/ I said Steve used 2.96-101 from Red Hat and had good luck. I said 2.95.2 had miscompiled xfs code. Just passing along what has worked, and what has caused problems. It's not that we choose to "support" or "not support" compiler versions, but that we have seen various compiler versions miscompile xfs code. When the problem can be isolated, the bug is submitted, and gcc gets fixed. Regardless of compiler version, regardless of distribution. The whole compiler issue is tricky. Bugs show up in subtle and hard to find ways. We would like to be able to wholeheartedly recommend a recent, official gcc release for compiling xfs, but we need help to do that. People are going to have to use gcc version X, and put it in production or heavy testing, and give detailed reports of the results. For now, when someone asks "what should I use for xfs?" we're still saying gcc-2.91.66/egcs 1.1.2 because that has shown the fewest problems so far. -Eric From owner-linux-xfs@oss.sgi.com Thu Mar 21 18:10:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M2A2t03192 for linux-xfs-outgoing; Thu, 21 Mar 2002 18:10:02 -0800 Received: from mail.sessys.com (dhcp211-25-151-24.nm01-c3.cpe.charter-ne.com [24.151.25.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M29sq03163 for ; Thu, 21 Mar 2002 18:09:54 -0800 Received: from dhcp10 (dhcp-10.intranet.sessys.com [192.168.0.10]) by mail.sessys.com (8.9.3/SES-8.9.3) with SMTP id VAA25212; Thu, 21 Mar 2002 21:13:21 -0500 Reply-To: From: "Sean Elble" To: "Eric Sandeen" Cc: Subject: RE: [Announce] XFS 1.1 Prerelease 2 available for testing Date: Thu, 21 Mar 2002 21:13:20 -0500 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <1016738115.30196.4.camel@stout.americas.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric, Any information on specific changes since the 1.0x releases? I know about the ACL/EA interface changes, and obviously there has been lots of bug fixes, but what about other changes, like performance enhancements, etc? I know the changes will be in the Changelog in the tarball, but I'm on a Windows machine; can't easily grab those. :-( -------------------------------------------- Sean P. Elble Independent Systems/Network Engineer Caldera Accredited Partner UNIX/Linux/Windows NT/2000 SES Computer Systems elbles@sessys.com -------------------------------------------- >-----Original Message----- >From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On >Behalf Of Eric Sandeen >Sent: Thursday, March 21, 2002 2:15 PM >To: linux-xfs@oss.sgi.com >Subject: [Announce] XFS 1.1 Prerelease 2 available for testing > > >At long last, a prerelease of the upcoming XFS 1.1 release is available >at > >ftp://oss.sgi.com/projects/xfs/download/testing/xfs-1.1 > > >These packages are a pre-release of the upcoming 1.1 release of XFS >for Linux. They have been sanity-checked, but not heavily tested >at SGI, and as such are intended for testing purposes. > >They may in fact be bulletproof, but that's for you to decide >before you use them in a critical environment! > >The XFS code in this release is very close to what is currently in CVS, >with some of the most recent, least tested changes omitted. > >Kernels are available for x86 and ia64, based both on the vanilla Linux >2.4.18 kernel, and on the Red Hat 2.4.9-31 kernel release. > >Please test 'em, benchmark 'em, break 'em, and let us know what you >find. > >Thanks, > >-Eric > >-- >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 21 18:33:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M2XBi03836 for linux-xfs-outgoing; Thu, 21 Mar 2002 18:33: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 g2M2Wkq03787 for ; Thu, 21 Mar 2002 18:32: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 g2M3hMkw021997 for ; Thu, 21 Mar 2002 21:43:22 -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 UAA76256; Thu, 21 Mar 2002 20:33:50 -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 UAA65882; Thu, 21 Mar 2002 20:33:50 -0600 (CST) Date: Thu, 21 Mar 2002 20:33:50 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Sean Elble cc: Subject: RE: [Announce] XFS 1.1 Prerelease 2 available for testing 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 Thu, 21 Mar 2002, Sean Elble wrote: > Eric, > > Any information on specific changes since the 1.0x releases? I know about > the ACL/EA interface changes, and obviously there has been lots of bug > fixes, but what about other changes, like performance enhancements, etc? I > know the changes will be in the Changelog in the tarball, but I'm on a > Windows machine; can't easily grab those. :-( Just got this together - probably _too_ detailed at this point. I'll try to do one that's a bit more of an overview. I also plan to do some benchmarking between the 1.0.2 release and this one. -Eric CHANGES since 1.0.2: ==================== Kernel ------ * Remove most synchronous transactions - faster deletes, fewer chances for null files after a crash! * Various error code return fixes * Restrict inodes to 32 bits on large filesystems (override w/ mount option) * Fix concurrent file and mmapped I/O * Fix dbench hangs on low memory systems * Fix recovery of device special inodes * Fix mount argument parsing * Various pagebuf reorganization, simplification, and cleanup * Fix parallel direct and buffered I/O * Code merges from irix * Pagebuf merged into xfs * Fix out-of-line extended attribute data * Fix forced shutdown bug that overwrote superblock :( * Improve memory allocation when not in a transaction * Limit max file size to something Linux can handle * Some realtime device fixes (still not complete) * Clean up xfs_freeze path * Report filesystem name on duplicate UUID mount failure. * Shrink xfs inode size * Fix some direct I/O corner cases * Fix mount with bad log or realtime device options * Make "osyncisdsync" the default on xfs filesystems * Restrict chown to file's owner, or someone w/ the right capability * Upgrade quota to Jan Kara's 32-bit VFS quota * fix memory leak in O_DIRECT read path * Use new reserved ea/acl syscall numbers * Fix some sparc64 compile problems * Make xfs superblock coherent with block layer * Pagebuf use after free fix * Don't allow quota flag changes on read-only device * Make xfs metadata accesses refresh pages, keep them in the cache * Fix sgid inheritence for root * Correct utime permissions checking * Reduce xfs log memory usage * Fix a bug in memory freeing acl --- * Man page updates from Andreas * Test script updates from Andreas * Clean up the --default option handling in setfacl. The old workarounds caused a bug for unusual input. * Changes to the --test output format setfacl generates: ACLs that are not changed are now displayed as `*'. * Fix a bug in setfacl/sequence.c:seq_delete_cmd(). * Minor changes to test scripts * Apply several patches from Andreas, namely: * man page fixes * libacl code reformatting * acl_from_text errno handling * Apply Andreas Gruenbacher's diffs. * Fix up chacl for deletion of access ACL to be in line with Andreas. * Incorporate the Debian packaging again. * Reworked to use the new official system call API. * Sync up with the XFS project, the SGI folk now use this source. * Jumped to version 2 to allow XFS users to upgrade (Rationale: the XFS ACL user tools were at version 1.1.X, and packaging tools like rpm, dpkg, etc. must be presented with a greater version number to allow an upgrade to proceed). * Added the chacl command to ease migration for existing XFS users, and for compatibility with IRIX. * Added a flag to allow acl_print to produce a single-line ACL, in addition to the multi-line format. * Extended attribute documentation has moved into the extended attribute package from SGI ("attr"), this ACL package now deals exclusively with ACLs. * acl_from_text sometimes did not set errno when failing. * Moved files and simplified #includes in libacl attr ---- * Add MIPS/MIPS64 system call numbers * Fix build for architectures which don't have syscalls yet * Fix the syscall number used on Sparc for fremovexattr(2) * Test script updates * Man page updates * A minor change to the test/run script * add in ARM architecture system call numbers * updates to the test output from Andreas * add in S/390 system call numbers from Martin Schwidefsky * revert IA64 syscall numbering after further mail with David Mosberger (apparently sys_tkill will be moved) See: https://external-lists.valinux.com/archives/\ /linux-ia64/2002-February/002990.html * incorporate several documentation changes from Andreas, including a script to convert from the aget format of attribute backup file, to the new getfattr format * fix IA64 syscall numbering * initial introduction of the new system call interface * synced up with the ext2 project, incorporated get/set tools * new man pages for system calls, getfattr(1) and setfattr(1) * made the attributes.h interface align properly with IRIX DMAPI ----- * The kernel-side of dmapi is now a module, and the device has moved. Change dmapi to use the dmapi device in its new location of /proc/fs/xfs_dmapi. xfsprogs --------- * Fall back to BLKGETSIZE if BLKGETSIZE64 fails * Sync user/kernel headers and shared code * Major release to coincide with switch to new extended attributes system call interfaces * bumped version of libhandle, added new symbols to use the reworked extended attributes handle ioctl interface * xfs_repair in no-modify mode opens the filesystem device read-only now (fix from Chris Pascoe) * sync up with recent (minor) changes to shared kernel code * switch to using the BLKGETSIZE64 ioctl in libxfs, instead of the (previously busted) BLKGETSIZE ioctl * fix xfs_repair option parsing for external logs * add xfs_repair option parsing for realtime device * fix xfs_repair version (-V) option - should not require an argument * add -V option to usage string * document verbose (-v) and -r options in manpage * fix mkfs.xfs buglet in overwriting signatures when run on a regular file * mkfs.xfs overwrites pre-existing filesystem, swap, or md driver signatures. * xfs_repair fix to prevent double insertion into the uncertain_inode AVL trees ("avl_insert: duplicate range") * xfs_repair fix if the log is corrupted and we can't find the head, don't exit - just proceed on with zeroing it * use snprintf instead of sprintf throughout * added text dump type to xfs_db (mkp) * removed use of a temporary file in xfs_db when processing commands on the command line - allows xfs_check to be run on read-only root filesystems * reenable the use of the BLKBSZSET ioctl, its baaack * sync recent XFS kernel source changes back into libxfs * fix minor debian package version numbering issue * add documentation for xfs_db(8) label/uuid commands * automatic inode sizing code in mkfs.xfs has been removed (restricting inodes to 32 bits) - Steve's recent kernel changes mean this is no longer an issue * fix bug in mkfs.xfs size cross-check for realtime device xfsdump/restore --------------- * rework all code dealing with extended attributes to use the new system calls (requires attr-2.0.0 or greater) * also, the attrctl-by-handle ioctl is history, replaced by libhandle routines - more like what we have in IRIX (requires xfsprogs-2.0.0 or greater) * effectively no-op change (cleanup) - switch over to using XFS_IOC_FSGEOMETRY instead of XFS_IOC_GETFSUUID ioctl, so we can deprecate that "special" UUID ioctl in the kernel. * add -q description to xfsdump/xfsrestore man pages and usage text. * change failed bulkstat WARNING to a TRACE message to that it doesn't bother people. * avoid a possible assertion failure for cumulative restores with -B option. * fix xfsrestore so that cumulative restores (with -r) will successfully delete removed directories whose files have also been removed. Previously, the files weren't removed until later, which meant that early directory removal failed. SGI bug#844219. * fix xfsdump so that if an inode# is reused in the time between building the inode map and pruning the inode map (in phase 3 when some dirs are marked as not changed), that it no longer aborts with an assertion failure. SGI bug#846374. * add new -B option to xfsrestore to correctly assign ownership and permissions of the dump root directory to the destination directory * port back IRIX changes primarily to xfsrestore for improving performance when one has over a million files * some extra mlogs (messages) for dump estimates, dir tree diagnostics, type of dump format being used * various fixes for restore with multiple threads and extended attributes (note: multiple threads not implemented on Linux yet) * fix xfsdump to endian convert all of the record header fields properly just prior to writing the header out (in particular first_mark_offset). This caused do_next_mark() assertion failures at some sites. * fix xfsrestore so that it doesn't delete hardlinks on alternate cumulative restores * allow xfsdump to exclude files based on whether they have a certain extended attribute set * don't include /var/lib/xfsdump in the dump misc ---- * Updated documentation. From owner-linux-xfs@oss.sgi.com Thu Mar 21 18:39:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M2d6e04046 for linux-xfs-outgoing; Thu, 21 Mar 2002 18:39:06 -0800 Received: from mail.sessys.com (dhcp211-25-151-24.nm01-c3.cpe.charter-ne.com [24.151.25.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M2ccq04010 for ; Thu, 21 Mar 2002 18:38:38 -0800 Received: from dhcp10 (dhcp-10.intranet.sessys.com [192.168.0.10]) by mail.sessys.com (8.9.3/SES-8.9.3) with SMTP id VAA25224; Thu, 21 Mar 2002 21:42:18 -0500 Reply-To: From: "Sean Elble" To: "Eric Sandeen" Cc: Subject: RE: [Announce] XFS 1.1 Prerelease 2 available for testing Date: Thu, 21 Mar 2002 21:42:15 -0500 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric, *Exactly* what I was looking for; thanks a lot! Can't wait to see them benchmarks! ;-) -------------------------------------------- Sean P. Elble Independent Systems/Network Engineer Caldera Accredited Partner UNIX/Linux/Windows NT/2000 SES Computer Systems elbles@sessys.com -------------------------------------------- >-----Original Message----- >From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On >Behalf Of Eric Sandeen >Sent: Thursday, March 21, 2002 9:34 PM >To: Sean Elble >Cc: linux-xfs@oss.sgi.com >Subject: RE: [Announce] XFS 1.1 Prerelease 2 available for testing > > >On Thu, 21 Mar 2002, Sean Elble wrote: > >> Eric, >> >> Any information on specific changes since the 1.0x releases? I know about >> the ACL/EA interface changes, and obviously there has been lots of bug >> fixes, but what about other changes, like performance >enhancements, etc? I >> know the changes will be in the Changelog in the tarball, but I'm on a >> Windows machine; can't easily grab those. :-( > >Just got this together - probably _too_ detailed at this point. I'll try >to do one that's a bit more of an overview. I also plan to do some >benchmarking between the 1.0.2 release and this one. > >-Eric > >CHANGES since 1.0.2: >==================== > >Kernel >------ > >* Remove most synchronous transactions - faster deletes, fewer >chances for null files after a crash! >* Various error code return fixes >* Restrict inodes to 32 bits on large filesystems (override w/ >mount option) >* Fix concurrent file and mmapped I/O >* Fix dbench hangs on low memory systems >* Fix recovery of device special inodes >* Fix mount argument parsing >* Various pagebuf reorganization, simplification, and cleanup >* Fix parallel direct and buffered I/O >* Code merges from irix >* Pagebuf merged into xfs >* Fix out-of-line extended attribute data >* Fix forced shutdown bug that overwrote superblock :( >* Improve memory allocation when not in a transaction >* Limit max file size to something Linux can handle >* Some realtime device fixes (still not complete) >* Clean up xfs_freeze path >* Report filesystem name on duplicate UUID mount failure. >* Shrink xfs inode size >* Fix some direct I/O corner cases >* Fix mount with bad log or realtime device options >* Make "osyncisdsync" the default on xfs filesystems >* Restrict chown to file's owner, or someone w/ the right capability >* Upgrade quota to Jan Kara's 32-bit VFS quota >* fix memory leak in O_DIRECT read path >* Use new reserved ea/acl syscall numbers >* Fix some sparc64 compile problems >* Make xfs superblock coherent with block layer >* Pagebuf use after free fix >* Don't allow quota flag changes on read-only device >* Make xfs metadata accesses refresh pages, keep them in the cache >* Fix sgid inheritence for root >* Correct utime permissions checking >* Reduce xfs log memory usage >* Fix a bug in memory freeing > > >acl >--- > >* Man page updates from Andreas >* Test script updates from Andreas >* Clean up the --default option handling in setfacl. The old > workarounds caused a bug for unusual input. >* Changes to the --test output format setfacl generates: ACLs that > are not changed are now displayed as `*'. >* Fix a bug in setfacl/sequence.c:seq_delete_cmd(). >* Minor changes to test scripts >* Apply several patches from Andreas, namely: >* man page fixes >* libacl code reformatting >* acl_from_text errno handling >* Apply Andreas Gruenbacher's diffs. >* Fix up chacl for deletion of access ACL to be in line with Andreas. >* Incorporate the Debian packaging again. >* Reworked to use the new official system call API. >* Sync up with the XFS project, the SGI folk now use this source. >* Jumped to version 2 to allow XFS users to upgrade > (Rationale: the XFS ACL user tools were at version 1.1.X, and > packaging tools like rpm, dpkg, etc. must be presented with a > greater version number to allow an upgrade to proceed). >* Added the chacl command to ease migration for existing XFS users, > and for compatibility with IRIX. >* Added a flag to allow acl_print to produce a single-line ACL, in > addition to the multi-line format. >* Extended attribute documentation has moved into the extended > attribute package from SGI ("attr"), this ACL package now deals > exclusively with ACLs. >* acl_from_text sometimes did not set errno when failing. >* Moved files and simplified #includes in libacl > >attr >---- >* Add MIPS/MIPS64 system call numbers >* Fix build for architectures which don't have syscalls yet >* Fix the syscall number used on Sparc for fremovexattr(2) >* Test script updates >* Man page updates >* A minor change to the test/run script >* add in ARM architecture system call numbers >* updates to the test output from Andreas >* add in S/390 system call numbers from Martin Schwidefsky >* revert IA64 syscall numbering after further mail with > David Mosberger (apparently sys_tkill will be moved) > See: https://external-lists.valinux.com/archives/\ > /linux-ia64/2002-February/002990.html >* incorporate several documentation changes from Andreas, > including a script to convert from the aget format of > attribute backup file, to the new getfattr format >* fix IA64 syscall numbering >* initial introduction of the new system call interface >* synced up with the ext2 project, incorporated get/set tools >* new man pages for system calls, getfattr(1) and setfattr(1) >* made the attributes.h interface align properly with IRIX > >DMAPI >----- >* The kernel-side of dmapi is now a module, and the device has > moved. Change dmapi to use the dmapi device in its new > location of /proc/fs/xfs_dmapi. > >xfsprogs >--------- >* Fall back to BLKGETSIZE if BLKGETSIZE64 fails >* Sync user/kernel headers and shared code >* Major release to coincide with switch to new extended > attributes system call interfaces >* bumped version of libhandle, added new symbols to use > the reworked extended attributes handle ioctl interface >* xfs_repair in no-modify mode opens the filesystem device > read-only now (fix from Chris Pascoe) >* sync up with recent (minor) changes to shared kernel code >* switch to using the BLKGETSIZE64 ioctl in libxfs, instead > of the (previously busted) BLKGETSIZE ioctl >* fix xfs_repair option parsing for external logs >* add xfs_repair option parsing for realtime device >* fix xfs_repair version (-V) option - should not > require an argument >* add -V option to usage string >* document verbose (-v) and -r options in manpage >* fix mkfs.xfs buglet in overwriting signatures when run > on a regular file >* mkfs.xfs overwrites pre-existing filesystem, swap, or md > driver signatures. >* xfs_repair fix to prevent double insertion into the > uncertain_inode AVL trees ("avl_insert: duplicate range") >* xfs_repair fix if the log is corrupted and we can't find > the head, don't exit - just proceed on with zeroing it >* use snprintf instead of sprintf throughout >* added text dump type to xfs_db (mkp) >* removed use of a temporary file in xfs_db when processing > commands on the command line - allows xfs_check to be run > on read-only root filesystems >* reenable the use of the BLKBSZSET ioctl, its baaack >* sync recent XFS kernel source changes back into libxfs >* fix minor debian package version numbering issue >* add documentation for xfs_db(8) label/uuid commands >* automatic inode sizing code in mkfs.xfs has been removed > (restricting inodes to 32 bits) - Steve's recent kernel > changes mean this is no longer an issue >* fix bug in mkfs.xfs size cross-check for realtime device > >xfsdump/restore >--------------- >* rework all code dealing with extended attributes to use > the new system calls (requires attr-2.0.0 or greater) >* also, the attrctl-by-handle ioctl is history, replaced > by libhandle routines - more like what we have in IRIX > (requires xfsprogs-2.0.0 or greater) >* effectively no-op change (cleanup) - switch over to using > XFS_IOC_FSGEOMETRY instead of XFS_IOC_GETFSUUID ioctl, so > we can deprecate that "special" UUID ioctl in the kernel. >* add -q description to xfsdump/xfsrestore man pages and > usage text. >* change failed bulkstat WARNING to a TRACE message to that > it doesn't bother people. >* avoid a possible assertion failure for cumulative restores > with -B option. >* fix xfsrestore so that cumulative restores (with -r) > will successfully delete removed directories whose > files have also been removed. > Previously, the files weren't removed until later, > which meant that early directory removal failed. > SGI bug#844219. >* fix xfsdump so that if an inode# is reused in the time > between building the inode map and pruning the inode map > (in phase 3 when some dirs are marked as not changed), > that it no longer aborts with an assertion failure. > SGI bug#846374. >* add new -B option to xfsrestore to correctly assign > ownership and permissions of the dump root directory > to the destination directory >* port back IRIX changes primarily to xfsrestore for > improving performance when one has over a million files >* some extra mlogs (messages) for dump estimates, > dir tree diagnostics, type of dump format being used >* various fixes for restore with multiple threads > and extended attributes (note: multiple threads not > implemented on Linux yet) >* fix xfsdump to endian convert all of the record header > fields properly just prior to writing the header out > (in particular first_mark_offset). > This caused do_next_mark() assertion failures at some > sites. >* fix xfsrestore so that it doesn't delete hardlinks > on alternate cumulative restores >* allow xfsdump to exclude files based on whether they have > a certain extended attribute set >* don't include /var/lib/xfsdump in the dump > >misc >---- >* Updated documentation. From owner-linux-xfs@oss.sgi.com Thu Mar 21 18:48:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M2mvI04317 for linux-xfs-outgoing; Thu, 21 Mar 2002 18:48:57 -0800 Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M2mqq04291 for ; Thu, 21 Mar 2002 18:48:52 -0800 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 16oF6f-0001ab-00; Thu, 21 Mar 2002 19:48:41 -0700 Message-ID: <3C9A9C1B.7040409@emergence.com> Date: Thu, 21 Mar 2002 19:51:07 -0700 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I don't know about other package managers, but RPM definiately isn't restricted by this, you can have Version and Release and version respects going from 1.0 to 1.1 So even if this package was 1.1.5 and you wanted to release another 1.1.5 with fixes you could package it again as 1.1.5-2 where the -2 is the Release. Looks like a lot of good changes though. -Mike > acl > --- > * Jumped to version 2 to allow XFS users to upgrade > (Rationale: the XFS ACL user tools were at version 1.1.X, and > packaging tools like rpm, dpkg, etc. must be presented with a > greater version number to allow an upgrade to proceed). From owner-linux-xfs@oss.sgi.com Thu Mar 21 19:01:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M31AE04715 for linux-xfs-outgoing; Thu, 21 Mar 2002 19:01:10 -0800 Received: from groucho.maths.monash.edu.au (groucho.maths.monash.edu.au [130.194.160.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M315q04689 for ; Thu, 21 Mar 2002 19:01:05 -0800 Received: (from rjh@localhost) by groucho.maths.monash.edu.au (8.8.8/8.8.8) id DAA11342 for linux-xfs@oss.sgi.com; Fri, 22 Mar 2002 03:03:27 GMT From: Robin Humble Message-Id: <200203220303.DAA11342@groucho.maths.monash.edu.au> Subject: general 2.5 question To: linux-xfs@oss.sgi.com Date: Fri, 22 Mar 2002 14:03:26 +1100 (EDT) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk So this isn't XFS specific (so feel free to ignore this), but I figure you guys have been compiling and running 2.5 kernels for ages, and so you might have a feel for how usable/stable 2.5 is these days? My data point is that I compiled up a pretty minimal 2.5.7-xfs from XFS cvs on my home machine and tried it out for about an hour today and it seemed to work ok(*). We don't mind occasional crashes if that's the price we have to pay to use the new NAPI + e1000 stuff on our ia64/SMP machines. We prob have to wait for the 2.5.7 ia64 patch first though. cheers, robin (*) VM performance was similar to (no better, maybe a bit worse than) 2.4.18 and some drivers didn't compile. The ALSA audio with OSS wrappers seemed to worked well. XFS had no problems :-) From owner-linux-xfs@oss.sgi.com Thu Mar 21 19:03:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M33cT04878 for linux-xfs-outgoing; Thu, 21 Mar 2002 19:03:38 -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 g2M33Yq04848 for ; Thu, 21 Mar 2002 19:03:34 -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 g2M4EAkw022273 for ; Thu, 21 Mar 2002 22:14:10 -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 VAA76250; Thu, 21 Mar 2002 21:04: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 VAA05316; Thu, 21 Mar 2002 21:04:37 -0600 (CST) Date: Thu, 21 Mar 2002 21:04:37 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Michael Best cc: Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing In-Reply-To: <3C9A9C1B.7040409@emergence.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, this was a big, not backwards-compatible change for the acl package, and it's a lot easier to say "you need version 2.0 or greater" than to say "you need version number 1.1.5-2 or greater." But at the end of the day, they're just version numbers. If we called it vABC-1.0.2-2002-Mar-21-prerelease-1a, it'd still be the same code. :) -Eric On Thu, 21 Mar 2002, Michael Best wrote: > I don't know about other package managers, but RPM definiately isn't > restricted by this, you can have Version and Release and version > respects going from 1.0 to 1.1 > > So even if this package was 1.1.5 and you wanted to release another > 1.1.5 with fixes you could package it again as 1.1.5-2 where the -2 is > the Release. > > Looks like a lot of good changes though. > > -Mike > From owner-linux-xfs@oss.sgi.com Thu Mar 21 19:03:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M33ws05008 for linux-xfs-outgoing; Thu, 21 Mar 2002 19:03:58 -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 g2M33rq04979 for ; Thu, 21 Mar 2002 19:03:53 -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 g2M46BBA001840 for ; Thu, 21 Mar 2002 20:06:12 -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 OAA23692; Fri, 22 Mar 2002 14:04:54 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA27311; Fri, 22 Mar 2002 14:04:54 +1100 (AEDT) Date: Fri, 22 Mar 2002 14:04:53 +1100 From: Nathan Scott To: Michael Best Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Message-ID: <20020322140453.P23600@wobbly.melbourne.sgi.com> References: <3C9A9C1B.7040409@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C9A9C1B.7040409@emergence.com>; from mbest@emergence.com on Thu, Mar 21, 2002 at 07:51:07PM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Mar 21, 2002 at 07:51:07PM -0700, Michael Best wrote: > I don't know about other package managers, but RPM definiately isn't > restricted by this, you can have Version and Release and version > respects going from 1.0 to 1.1 > > So even if this package was 1.1.5 and you wanted to release another > 1.1.5 with fixes you could package it again as 1.1.5-2 where the -2 is > the Release. This is really a note for the ext2/ext3 acl users - Andreas' previous tools were at 0.8.x, we were at 1.1.4, I think. And no package manager is ever going to consider 0.9.0 an upgrade from 1.1.4, for example, so thats what that bullet point is all about. > > Looks like a lot of good changes though. > > -Mike > > > acl > > --- > > * Jumped to version 2 to allow XFS users to upgrade > > (Rationale: the XFS ACL user tools were at version 1.1.X, and > > packaging tools like rpm, dpkg, etc. must be presented with a > > greater version number to allow an upgrade to proceed). > > -- Nathan From owner-linux-xfs@oss.sgi.com Thu Mar 21 21:57:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M5veO07826 for linux-xfs-outgoing; Thu, 21 Mar 2002 21:57:40 -0800 Received: from ilanz.monex.li (ilanz.monex.li [164.128.93.104]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M5vSq07777 for ; Thu, 21 Mar 2002 21:57:29 -0800 Received: from spalegna.monex.li (spalegna [164.128.93.99]) by ilanz.monex.li (8.11.6/8.11.6) with ESMTP id g2M5xiL22087; Fri, 22 Mar 2002 06:59:44 +0100 Received: from relay.monex.li (8.9.3/8.9.3) id IAA30963; Fri, 22 Mar 2002 08:24:35 +0100 Received: from mailpumpe.monex.li by relay.monex.li via smtp; Received: from vorab.monex.li by mailpumpe.monex.li (8.11.6/8.11.6) with ESMTP id g2M5xZD10903; Fri, 22 Mar 2002 06:59:35 +0100 Subject: Re: mkfs.xfs on EVMS Volume forgot the releases used From: Oliver Jehle 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: 22 Mar 2002 07:01:22 +0100 Message-Id: <1016776882.1016.4.camel@vorab> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Got Answer from the evms team... hey fix the BLKGETSIZE64 problem !! http://sourceforge.net/mailarchive/message.php?msg_id=1343124 thanks for helping oliver On Thu, 2002-03-21 at 15:29, Eric Sandeen wrote: > On 21 Mar 2002, Oliver Jehle wrote: > > > > ioctl(5, 0x80041272, 0xbfffe124) = -1 EINVAL (Invalid argument) > > > write(2, "mkfs.xfs: can\'t determine device"..., 38mkfs.xfs: can't > > > determine device size > > > ) = 38 > > > _exit(1) = ? > > Ok, it looks like the BLKGETSIZE64 ioctl is failing. The very latest > mkfs.xfs will fall back to BLKGETSIZE if this happens; I guess we need to > update what's on oss. > > You should suggest to the evms folks that they implement BLKGETSIZE64, but > in the meantime this patch will fix things for you: > > --- /usr/tmp/TmpDir.30077-0/cmd/xfsprogs/libxfs/init.c_1.12 Thu Mar 21 > 08:28:40 2002 > +++ /usr/tmp/TmpDir.30077-0/cmd/xfsprogs/libxfs/init.c_1.13 Thu Mar 21 > 08:28:40 2002 > @@ -156,11 +156,19 @@ > exit(1); > } > error = ioctl(fd, BLKGETSIZE64, &size); > - /* BLKGETSIZE64 returns size in bytes */ > - size = size >> 9; > - if (error < 0) { > - fprintf(stderr, "%s: can't determine device size\n", > progname); > - exit(1); > + if (error >= 0) { > + /* BLKGETSIZE64 returns size in bytes not 512-byte blocks > */ > + size = size >> 9; > + } else { > + /* If BLKGETSIZE64 fails, try BLKGETSIZE */ > + unsigned long tmpsize; > + error = ioctl(fd, BLKGETSIZE, &tmpsize); > + if (error < 0) { > + fprintf(stderr, "%s: can't determine device > size\n", > + progname); > + exit(1); > + } > + size = (__uint64_t)tmpsize; > } > > close(fd); > > > > -Eric > From owner-linux-xfs@oss.sgi.com Thu Mar 21 23:54:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M7sxn09887 for linux-xfs-outgoing; Thu, 21 Mar 2002 23:54:59 -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 g2M7sqq09861 for ; Thu, 21 Mar 2002 23:54:53 -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 g2M7vDgp059827; Fri, 22 Mar 2002 08:57:14 +0100 (CET) Message-Id: <4.3.2.7.2.20020322085138.02fb00f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Mar 2002 08:54:30 +0100 To: Eric Sandeen , Mihai RUSU From: Seth Mos Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Cc: linux-xfs@oss.sgi.com In-Reply-To: <1016739950.30176.8.camel@stout.americas.sgi.com> References: < Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:45 21-3-2002 -0600, Eric Sandeen wrote: >The RPMs are still compiled with "kgcc" for x86... Steve has been using >gcc-2.96-101 with good success. I think that 2.95.x is not so good. If >anyone has had problems with one compiler, that were solved by changing >to kgcc or a newer compiler, please chime in... Anything newer then kgcc fails to compile newer ISDN drivers like the diva driver for Eicon Diva Server cards. This is a add-on patch and I have contacted the author about this. Besides this I have not seen any serious problems, I have used gcc3 instead of kgcc with good success. >I _really_ hope that some day this question can go away. :) I don't think you are the only one. 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 22 00:07:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M87Bq10390 for linux-xfs-outgoing; Fri, 22 Mar 2002 00:07:11 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M876q10364 for ; Fri, 22 Mar 2002 00:07:06 -0800 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2M89O8g058124; Fri, 22 Mar 2002 09:09:24 +0100 (CET) Message-Id: <4.3.2.7.2.20020322090342.02f09d50@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Mar 2002 09:06:41 +0100 To: Eric Sandeen , mdew From: Seth Mos Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Cc: , xfs In-Reply-To: References: <1016761583.9819.29.camel@mdew> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 20:08 21-3-2002 -0600, Eric Sandeen wrote: >I said Steve used 2.96-101 from Red Hat and had good luck. I said 2.95.2 >had miscompiled xfs code. Just passing along what has worked, and what >has caused problems. In the FAQ i mention that kgcc is for pruduction use and people on debian should apt-get at least 2.95.3. 2.95.2 is not good and these problems are fixed in both 2.95.3 and 2.95.4 which people have good success with so far. Besides the occasional compiler bug that bites about every release out there there is not to much to fear. 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 22 00:35:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M8ZeP11507 for linux-xfs-outgoing; Fri, 22 Mar 2002 00:35:40 -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 g2M8Zaq11481 for ; Fri, 22 Mar 2002 00:35:36 -0800 Message-ID: <20020322083759.58127.qmail@web21105.mail.yahoo.com> Received: from [12.234.153.47] by web21105.mail.yahoo.com via HTTP; Fri, 22 Mar 2002 00:37:59 PST Date: Fri, 22 Mar 2002 00:37:59 -0800 (PST) From: Glow Nair Subject: Resetting the root password in SGI XFS 1.02 To: linux-xfs@oss.sgi.com 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 Hi.. Can anyone give me a quick link to a procedure to reset the root password ? I used the following command in Redhat 7.0; but the same doesnt work in SGI XFS 1.02. ----------------- Ctrl-Alt-Del : Reboot the machine Press Tab : When LILO prompt shows up linux single : At the boot : prompt; let the m/c boot passwd : At the bash # prompt Ctrl-Alt-Del : To reboot the machine ----------------- I do have console and the grub passwords. Thanks in advance for any help :) Appreciate it Glow Nair zanchu_glow@yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy AwardsŽ http://movies.yahoo.com/ From owner-linux-xfs@oss.sgi.com Fri Mar 22 00:55:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2M8toC12116 for linux-xfs-outgoing; Fri, 22 Mar 2002 00:55:50 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2M8tjq12089 for ; Fri, 22 Mar 2002 00:55:45 -0800 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2M8w7WR099005; Fri, 22 Mar 2002 09:58:07 +0100 (CET) Message-Id: <4.3.2.7.2.20020322095431.02fb6c50@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Mar 2002 09:55:24 +0100 To: Glow Nair , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Resetting the root password in SGI XFS 1.02 In-Reply-To: <20020322083759.58127.qmail@web21105.mail.yahoo.com> References: <3C84B4BB.C8700F84@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 00:37 22-3-2002 -0800, Glow Nair wrote: >Hi.. > >Can anyone give me a quick link to a procedure >to reset the root password ? > >I used the following command in Redhat 7.0; but >the same doesnt work in SGI XFS 1.02. >----------------- >Ctrl-Alt-Del : Reboot the machine >Press Tab : When LILO prompt shows up >linux single : At the boot : prompt; let the m/c boot >passwd : At the bash # prompt >Ctrl-Alt-Del : To reboot the machine >----------------- > >I do have console and the grub passwords. > >Thanks in advance for any help :) Appreciate it It should work normally, I used the same procedure before. What error do you get? 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 22 02:27:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MARaF15291 for linux-xfs-outgoing; Fri, 22 Mar 2002 02:27:36 -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 g2MARSq15264 for ; Fri, 22 Mar 2002 02:27:28 -0800 Message-ID: <20020322102952.52835.qmail@web21107.mail.yahoo.com> Received: from [12.234.153.47] by web21107.mail.yahoo.com via HTTP; Fri, 22 Mar 2002 02:29:52 PST Date: Fri, 22 Mar 2002 02:29:52 -0800 (PST) From: Glow Nair Subject: Re: Resetting the root password in SGI XFS 1.02 To: Seth Mos , linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20020322095431.02fb6c50@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Seth.. I used to do that with prior versions. My problem is this.. "I cannot get to a text mode.. to even do the "linux single" command..." When SGI XFS boots up.. then.. there are three choices and thats it.. period.. When you enter the grub password, it then offers you some more choices.. but nothing to boot in a single mode. Thanks Glow --- Seth Mos wrote: > At 00:37 22-3-2002 -0800, Glow Nair wrote: > >Hi.. > > > >Can anyone give me a quick link to a procedure > >to reset the root password ? > > > >I used the following command in Redhat 7.0; but > >the same doesnt work in SGI XFS 1.02. > >----------------- > >Ctrl-Alt-Del : Reboot the machine > >Press Tab : When LILO prompt shows up > >linux single : At the boot : prompt; let the m/c > boot > >passwd : At the bash # prompt > >Ctrl-Alt-Del : To reboot the machine > >----------------- > > > >I do have console and the grub passwords. > > > >Thanks in advance for any help :) Appreciate it > > It should work normally, I used the same procedure > before. What error do > you get? > > 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. > __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy AwardsŽ http://movies.yahoo.com/ From owner-linux-xfs@oss.sgi.com Fri Mar 22 03:15:13 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MBFDw16520 for linux-xfs-outgoing; Fri, 22 Mar 2002 03:15: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 g2MBF3q16494 for ; Fri, 22 Mar 2002 03:15:03 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx13)) with ESMTP id CF06EC2C7; Fri, 22 Mar 2002 12:17:20 +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 MAA02720; Fri, 22 Mar 2002 12:17:20 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 9542157306; Fri, 22 Mar 2002 12:16:13 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 2280525835; Fri, 22 Mar 2002 12:16:13 +0100 (CET) Message-ID: <3C9B127D.4C33BB58@ch.sauter-bc.com> Date: Fri, 22 Mar 2002 12:16:13 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Glow Nair Cc: Seth Mos , linux-xfs@oss.sgi.com Subject: Re: Resetting the root password in SGI XFS 1.02 References: <20020322102952.52835.qmail@web21107.mail.yahoo.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Glow Nair schrieb: > > Hi Seth.. > > I used to do that with prior versions. My problem > is this.. > > "I cannot get to a text mode.. to even > do the "linux single" command..." > > When SGI XFS boots up.. then.. there are three choices > and thats it.. period.. When you enter the grub > password, it then offers you some more choices.. > but nothing to boot in a single mode. I have never used grub with password so I don't know about that. But when you come to the menu, IIRC type e to go to edit mode. Then you have to edit the boot line, just add 'single' at the end of the line. Then use b to boot this configuration. It's nothing specific to the SGI Installer, RedHat behaves the same. -Simon > > Thanks > > Glow > > --- Seth Mos wrote: > > At 00:37 22-3-2002 -0800, Glow Nair wrote: > > >Hi.. > > > > > >Can anyone give me a quick link to a procedure > > >to reset the root password ? > > > > > >I used the following command in Redhat 7.0; but > > >the same doesnt work in SGI XFS 1.02. > > >----------------- > > >Ctrl-Alt-Del : Reboot the machine > > >Press Tab : When LILO prompt shows up > > >linux single : At the boot : prompt; let the m/c > > boot > > >passwd : At the bash # prompt > > >Ctrl-Alt-Del : To reboot the machine > > >----------------- > > > > > >I do have console and the grub passwords. > > > > > >Thanks in advance for any help :) Appreciate it > > > > It should work normally, I used the same procedure > > before. What error do > > you get? > > > > 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. > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Movies - coverage of the 74th Academy AwardsŽ > http://movies.yahoo.com/ From owner-linux-xfs@oss.sgi.com Fri Mar 22 03:19:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MBJJh16692 for linux-xfs-outgoing; Fri, 22 Mar 2002 03:19:19 -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 g2MBJEq16665 for ; Fri, 22 Mar 2002 03:19:14 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id EAA13738 for ; Thu, 21 Mar 2002 04:48:14 -0800 (PST) mail_from (knuffie@xs4all.nl) Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2LCpbjm098925; Thu, 21 Mar 2002 13:51:37 +0100 (CET) Message-Id: <4.3.2.7.2.20020321134135.02feb9f8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Mar 2002 13:48:55 +0100 To: Knut J Bjuland , Mike Burger From: Seth Mos Subject: Re: xfs in linux Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C99C208.EFFCA9D8@online.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:20 21-3-2002 +0100, Knut J Bjuland wrote: >Mike Burger wrote: > > > Care to give us a URL to visit? > > > > On Thu, 21 Mar 2002, Knut J Bjuland wrote: > > > > > Acording to openloggin xfs are going to be part of linux 2.5 > > > > >http://www.bitmover.com:8888//tmp/v2_logging/athlon.transmeta.com/torvalds-20020205173056-16047-c1d11a41ed024864 Is seems like someone from SuSE (mason) is commiting those. Since a number of SuSE people are on this list that isn't too surprising. I reckon they also do a lot of testing before 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 22 04:42:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MCgAo20071 for linux-xfs-outgoing; Fri, 22 Mar 2002 04:42:10 -0800 Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MCg6q20045 for ; Fri, 22 Mar 2002 04:42:06 -0800 Received: (qmail 15835 invoked by uid 1000); 22 Mar 2002 12:42:14 -0000 To: Eric Sandeen Cc: mdew , , xfs Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing References: From: Florian Weimer Date: Fri, 22 Mar 2002 13:42:14 +0100 In-Reply-To: (Eric Sandeen's message of "Thu, 21 Mar 2002 20:08:03 -0600 (CST)") Message-ID: <871yec3hax.fsf@CERT.Uni-Stuttgart.DE> Lines: 12 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen writes: > From the beginning, we have said that gcc-2.91.66/egcs 1.1.2 is the > compiler of choice for xfs. This is not RH-centric. This is a bit peculiar because egcs is discouraged for compiling late 2.4.x kernels. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-linux-xfs@oss.sgi.com Fri Mar 22 04:51:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MCphu20303 for linux-xfs-outgoing; Fri, 22 Mar 2002 04:51:43 -0800 Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MCpZq20275 for ; Fri, 22 Mar 2002 04:51:35 -0800 Received: from user-uivf38j.dsl.mindspring.com ([165.247.141.19] helo=sandbox.wingenbach.org) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16oOYQ-0007tw-00; Fri, 22 Mar 2002 07:53:58 -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 g2MCrfp24854; Fri, 22 Mar 2002 07:53:41 -0500 (EST) Message-ID: <3C9B2965.8B164516@wingenbach.org> Date: Fri, 22 Mar 2002 07:53:57 -0500 From: John Wingenbach X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott CC: XFS mailing list Subject: Re: xfsprogs Makepkgs fails to make rpm References: <3C9A1E06.729AC72C@wingenbach.org> <20020322092120.L23600@wobbly.melbourne.sgi.com> <3C9A61AC.E9FAE3EB@wingenbach.org> <20020322095349.M23600@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Very strange. I forcefully reinstalled the "rpm" package and all is well. I will have to track down what happened and what is missing from the install. -- John Nathan Scott wrote: > On Thu, Mar 21, 2002 at 05:41:48PM -0500, John Wingenbach wrote: > > Hi Nathan, > > > > The problem I am seeing is the same thing I saw when building another rpm > > myself. When I try to run: > > > > rpm -bANYTHING specfile > > > > I always get: > > No such file or directory > > That sounds like your rpm installation is borken - I'm not sure > exactly how it got in that state though. Just as a second > workaround, you could set RPM=/bin/rpmbuild in the environment > before the build and it will use that in preference (with no > Makefile changes, etc). > > What does "strace rpm -bANYTHING specfile" list as the file that > is not found? > > > >From searching the net, all I could find was a recommendation to use rpmbuild > > instead of rpm. When I did that, it worked perfectly. The Makepkgs run also > > is trying to perform a "rpm" build. Simply fooling Makepkgs into using > > rpmbuild instead of rpm built the rpms. > > > > The rpm versions I have installed are: > > rpm-4.0.3-1.03 > > rpmbuild-4.0.3-1.03 > > rpm-python-4.0.3-1.03 > > > > The only difference between your Redhat machine and mine is that > # rpm -q rpm rpmbuild rpm-python > rpm-4.0.3-1.03 > package rpmbuild is not installed > rpm-python-4.0.3-1.03 > > Oh, wait I have: > # rpm -q -f `which rpmbuild` > rpm-build-4.0.3-1.03 > > Was that a typo above in your list? > > Anyway, maybe you should try a fresh install of rpm - sounds like > something is fishy on your machine (maybe try compare your machine > to another with similar config to see whats different?) > > cheers. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Fri Mar 22 05:43:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MDhTZ21397 for linux-xfs-outgoing; Fri, 22 Mar 2002 05:43:29 -0800 Received: from guard.polynet.lviv.ua (guard.polynet.lviv.ua [217.9.2.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MDhNq21371 for ; Fri, 22 Mar 2002 05:43:24 -0800 Received: (qmail 93750 invoked from network); 22 Mar 2002 13:45:43 -0000 Received: from postoffice.lp.Lviv.ua (HELO polynet.lviv.ua) (192.168.0.6) by 192.168.0.1 with SMTP; 22 Mar 2002 13:45:43 -0000 Received: (qmail 66915 invoked by uid 0); 22 Mar 2002 13:45:43 -0000 Received: (ofmipd diablo.lp.Lviv.ua); 22 Mar 2002 13:45:21 -0000 Date: 22 Mar 2002 15:43:29 +0200 Message-ID: <00e101c1d1a7$8cc292f0$1c00a8c0@lp.lviv.ua> From: "Andriy Korud" To: linux-xfs@oss.sgi.com Subject: Direct I/O and Oracle MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit 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 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi. I've heard a lot about Direct I/O ability of XFS, but how can I use in "real life". I'm particularly interested in using Direct I/O with Oracle - I don't have too much RAM to put both Oracle's cache and buffer cache in it. And I still cannot find any FS that let not cache file data, anybody know this? Regards, Andriy From owner-linux-xfs@oss.sgi.com Fri Mar 22 06:40:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MEeRZ22464 for linux-xfs-outgoing; Fri, 22 Mar 2002 06:40:27 -0800 Received: from itcampus.de (www.itcampus.de [194.45.97.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MEeJq22436 for ; Fri, 22 Mar 2002 06:40:19 -0800 Received: from [62.16.184.226] (account twinkler HELO janus.lpz.itcampus.de) by itcampus.de (CommuniGate Pro SMTP 3.5.4) with ESMTP-TLS id 324319 for linux-xfs@oss.sgi.com; Fri, 22 Mar 2002 15:42:40 +0100 Subject: default acl on directory problem From: Thomas Winkler To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 22 Mar 2002 15:42:39 +0100 Message-Id: <1016808160.5266.19.camel@janus> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, i am using xfs enabled kernel 2.4.16 and tools. acl seems to work properly, except me having a hard time setting correct default acls on a directory. after setting acls on a directory (chacl and setfacl) it looks like this: # file: . # owner: cvs # group: cvs-misc user::rwx group::rwx other::--- mask::rwx group:cvs-misc:rwx default:user::rwx default:group::rwx default:other::--- default:mask::rwx default:group:cvs-misc:rwx this seems to work for all users in the cvs-misc group. when a create a file as user all other users of cvs-misc have read and write permissions. when i create a directory as another user (not cvs) i get something like the following: # file: . # owner: [otheruser] # group: [otherprimarygroup] user::rwx group::rwx #effective:r-x other::--- mask::r-x group:cvs-misc:rwx #effective:r-x default:user::rwx default:group::rwx default:other::--- default:mask::rwx default:group:cvs-misc:rwx why do i have effective r-x permissions for group access? shouldn't it be rwx, or am i missing something? if someone has an idea. thank you, thomas From owner-linux-xfs@oss.sgi.com Fri Mar 22 07:04:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MF48N23054 for linux-xfs-outgoing; Fri, 22 Mar 2002 07:04:08 -0800 Received: from mars.tronicplanet.de (mars.tronicplanet.de [195.38.137.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MF44q22991 for ; Fri, 22 Mar 2002 07:04:04 -0800 Received: from knollst (igate-tp.tronicplanet.de [217.74.1.58]) by mars.tronicplanet.de (8.9.1a/8.9.1) with SMTP id QAA01695 for ; Fri, 22 Mar 2002 16:06:24 +0100 Date: Fri, 22 Mar 2002 16:06:25 +0100 From: Stefan Knollmüller To: linux-xfs@oss.sgi.com Subject: static xfsprogs Message-Id: <20020322160625.1acc461f.stefan.knollmueller@tronicplanet.de> Organization: Tronic Planet Online Datendienst GmbH X-Mailer: Sylpheed version 0.7.3 (GTK+ 1.2.10; i586-pc-linux-gnu) 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 am really in need of static xfsprogs and as i am trying to get them via configure --enable-shared=no and then make i only get dynamically linked oens. i have already searched the mailing list and found one entry regarding this problem but no right answer and as my skills in programming c are not to big i am looking forward to find someone who knows what to do and so i am asking the xfs-list. has anyone a list of what to do to get static ones? From owner-linux-xfs@oss.sgi.com Fri Mar 22 07:31:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MFVZU23818 for linux-xfs-outgoing; Fri, 22 Mar 2002 07:31:35 -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 g2MFVUq23792 for ; Fri, 22 Mar 2002 07:31:30 -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 g2MGXnBA019400 for ; Fri, 22 Mar 2002 08:33:49 -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 JAA85529; Fri, 22 Mar 2002 09:32:33 -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 JAA75630; Fri, 22 Mar 2002 09:32:33 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id JAA14706; Fri, 22 Mar 2002 09:32:32 -0600 (CST) Message-Id: <200203221532.JAA14706@slobber.americas.sgi.com> To: Stefan Knollm|ller cc: linux-xfs@oss.sgi.com Subject: Re: static xfsprogs Date: Fri, 22 Mar 2002 09:32:32 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: Stefan Knollm|ller >hi, > >i am really in need of static xfsprogs and as i am trying to get them via conf >igure --enable-shared=no and then make i only get dynamically linked oens. >i have already searched the mailing list and found one entry regarding this pr >oblem but no right answer and as my skills in programming c are not to big i a >m looking forward to find someone who knows what to do and so i am asking the >xfs-list. >has anyone a list of what to do to get static ones? The build will not work when enable-shared is "no". We've just been discussing it earlier this week. The default build in xfsprogs will give you both shared libs and static ar archives, and the executables will be linked with the static ar archives. Running ldd(1) on your binaries should confirm this. Dean From owner-linux-xfs@oss.sgi.com Fri Mar 22 08:30:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MGU8625172 for linux-xfs-outgoing; Fri, 22 Mar 2002 08:30:08 -0800 Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MGTxq25140 for ; Fri, 22 Mar 2002 08:30:00 -0800 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 16oRvI-0001q5-00; Fri, 22 Mar 2002 09:29:48 -0700 Message-ID: <3C9B5C91.8010907@emergence.com> Date: Fri, 22 Mar 2002 09:32:17 -0700 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glow Nair CC: linux-xfs Subject: Re: Resetting the root password in SGI XFS 1.02 References: <20020322102952.52835.qmail@web21107.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 From the grub kernel/image selection menu just press 'e' to edit the particular profile. Then 'e' to edit the kernel line and add '1' or 'single' to the end of it and then hit 'enter'. 'b' will boot your edited startup after that. -Mike Glow Nair wrote: > Hi Seth.. > > I used to do that with prior versions. My problem > is this.. > > "I cannot get to a text mode.. to even > do the "linux single" command..." > > When SGI XFS boots up.. then.. there are three choices > and thats it.. period.. When you enter the grub > password, it then offers you some more choices.. > but nothing to boot in a single mode. > > Thanks > > Glow > > --- Seth Mos wrote: > >>At 00:37 22-3-2002 -0800, Glow Nair wrote: >> >>>Hi.. >>> >>>Can anyone give me a quick link to a procedure >>>to reset the root password ? >>> >>>I used the following command in Redhat 7.0; but >>>the same doesnt work in SGI XFS 1.02. >>>----------------- >>>Ctrl-Alt-Del : Reboot the machine >>>Press Tab : When LILO prompt shows up >>>linux single : At the boot : prompt; let the m/c >> >>boot >> >>>passwd : At the bash # prompt >>>Ctrl-Alt-Del : To reboot the machine >>>----------------- >>> >>>I do have console and the grub passwords. >>> >>>Thanks in advance for any help :) Appreciate it >> >>It should work normally, I used the same procedure >>before. What error do >>you get? >> >>Cheers >> >>-- >>Seth From owner-linux-xfs@oss.sgi.com Fri Mar 22 09:13:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MHDCj25940 for linux-xfs-outgoing; Fri, 22 Mar 2002 09:13:12 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MHD7q25911 for ; Fri, 22 Mar 2002 09:13:07 -0800 Received: (qmail 15923 invoked by uid 500); 22 Mar 2002 17:14:58 -0000 Subject: Re: Direct I/O and Oracle From: Austin Gonyou To: Andriy Korud Cc: linux-xfs@oss.sgi.com In-Reply-To: <00e101c1d1a7$8cc292f0$1c00a8c0@lp.lviv.ua> References: <00e101c1d1a7$8cc292f0$1c00a8c0@lp.lviv.ua> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 22 Mar 2002 11:14:58 -0600 Message-Id: <1016817298.15891.1.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk For the most part it should just work, unless you're talking about using raw devices, then you must setup raw devices, aside from that, though, it should just work. On Fri, 2002-03-22 at 07:43, Andriy Korud wrote: > Hi. > I've heard a lot about Direct I/O ability of XFS, but how can I use in > "real > life". I'm particularly interested in using Direct I/O with Oracle - I > don't > have too much RAM to put both Oracle's cache and buffer cache in it. > And I still cannot find any FS that let not cache file data, anybody > know > this? > > Regards, > Andriy -- 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 Fri Mar 22 09:22:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MHMax26152 for linux-xfs-outgoing; Fri, 22 Mar 2002 09:22:36 -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 g2MHMVq26126 for ; Fri, 22 Mar 2002 09:22: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 g2MHOn6G024320 for ; Fri, 22 Mar 2002 09:24:50 -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 LAA84826; Fri, 22 Mar 2002 11:23: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 LAA77717; Fri, 22 Mar 2002 11:23:33 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2MHKuO20229; Fri, 22 Mar 2002 11:20:56 -0600 Subject: Re: Direct I/O and Oracle From: Steve Lord To: Austin Gonyou Cc: Andriy Korud , linux-xfs@oss.sgi.com In-Reply-To: <1016817298.15891.1.camel@UberGeek> References: <00e101c1d1a7$8cc292f0$1c00a8c0@lp.lviv.ua> <1016817298.15891.1.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 22 Mar 2002 11:20:56 -0600 Message-Id: <1016817656.25660.1488.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-03-22 at 11:14, Austin Gonyou wrote: > For the most part it should just work, unless you're talking about using > raw devices, then you must setup raw devices, aside from that, though, > it should just work. Unless Oracle passes the O_DIRECT flag into the kernel is will not use O_DIRECT. There has been a suggestion that a mount option be provided to make the kernel assume O_DIRECT. It is not as simple as this since O_DIRECT has alignment constraints and if the application made non aligned requests they would be failed. So really Oracle is the only one who can help here. 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 22 09:24:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MHO2126317 for linux-xfs-outgoing; Fri, 22 Mar 2002 09:24:02 -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 g2MHNtq26282 for ; Fri, 22 Mar 2002 09:23:55 -0800 Received: from sgiger.munich.sgi.com (sgiger.munich.sgi.com [144.253.192.2]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g2MIQDBA023897 for ; Fri, 22 Mar 2002 10:26:14 -0800 Received: from sgi.com (callisto.munich.sgi.com [144.253.193.156]) by sgiger.munich.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA27827; Fri, 22 Mar 2002 18:24:20 +0100 Message-ID: <3C9B68C4.C5AC7E88@sgi.com> Date: Fri, 22 Mar 2002 18:24:20 +0100 From: Sebastian Brings Reply-To: sebas@sgi.com Organization: sgi X-Mailer: Mozilla 4.78C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Andriy Korud CC: linux-xfs@oss.sgi.com Subject: Re: Direct I/O and Oracle References: <00e101c1d1a7$8cc292f0$1c00a8c0@lp.lviv.ua> <1016817298.15891.1.camel@UberGeek> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Not sure about current Oracle implementations on Linux, but typically you have to specify _any_ type of non-standard FS IO with some init.ora parameters, like USE_DIRECT_IO = true or so. In earlier times there was something like a platform specific documentation where these and other features were mentioned. Sebastian Austin Gonyou wrote: > > For the most part it should just work, unless you're talking about using > raw devices, then you must setup raw devices, aside from that, though, > it should just work. > > On Fri, 2002-03-22 at 07:43, Andriy Korud wrote: > > Hi. > > I've heard a lot about Direct I/O ability of XFS, but how can I use in > > "real > > life". I'm particularly interested in using Direct I/O with Oracle - I > > don't > > have too much RAM to put both Oracle's cache and buffer cache in it. > > And I still cannot find any FS that let not cache file data, anybody > > know > > this? > > > > Regards, > > Andriy > -- > 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 Fri Mar 22 09:32:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MHWBs26596 for linux-xfs-outgoing; Fri, 22 Mar 2002 09:32:11 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MHW3q26570 for ; Fri, 22 Mar 2002 09:32:03 -0800 Received: (qmail 16280 invoked by uid 500); 22 Mar 2002 17:33:52 -0000 Subject: Re: Direct I/O and Oracle From: Austin Gonyou To: sebas@sgi.com Cc: Andriy Korud , linux-xfs@oss.sgi.com In-Reply-To: <3C9B68C4.C5AC7E88@sgi.com> References: <3C9B68C4.C5AC7E88@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 22 Mar 2002 11:33:52 -0600 Message-Id: <1016818432.16234.0.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When I said it should just work, I meant that Oracle handles that bit, as Steve mentioned. As in below, we do have a setting for this in our init.ora. On Fri, 2002-03-22 at 11:24, Sebastian Brings wrote: > Not sure about current Oracle implementations on Linux, but typically > you have to specify _any_ type of non-standard FS IO with some init.ora > parameters, like USE_DIRECT_IO = true or so. In earlier times there was > something like a platform specific documentation where these and other > features were mentioned. > > Sebastian > > Austin Gonyou wrote: > > > > For the most part it should just work, unless you're talking about > using > > raw devices, then you must setup raw devices, aside from that, though, > > it should just work. > > > > On Fri, 2002-03-22 at 07:43, Andriy Korud wrote: > > > Hi. > > > I've heard a lot about Direct I/O ability of XFS, but how can I use > in > > > "real > > > life". I'm particularly interested in using Direct I/O with Oracle - > I > > > don't > > > have too much RAM to put both Oracle's cache and buffer cache in it. > > > And I still cannot find any FS that let not cache file data, anybody > > > know > > > this? > > > > > > Regards, > > > Andriy > > -- > > 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 -- 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 Fri Mar 22 10:54:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MIsTa27919 for linux-xfs-outgoing; Fri, 22 Mar 2002 10:54:29 -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 g2MIsPq27878 for ; Fri, 22 Mar 2002 10:54:25 -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 g2MJuhBA027667 for ; Fri, 22 Mar 2002 11:56:43 -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 MAA88552; Fri, 22 Mar 2002 12:55:27 -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 MAA65553; Fri, 22 Mar 2002 12:55:27 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id MAA14972; Fri, 22 Mar 2002 12:55:26 -0600 (CST) Message-Id: <200203221855.MAA14972@slobber.americas.sgi.com> To: "Francis Qu" cc: "Linux XFS" Subject: Re: DMAPI Attribute Event and Append Date: Fri, 22 Mar 2002 12:55:26 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "Francis Qu" >Hi Dean, > >When appending data to the end of a file, the file modification time and >change time are updated. But this operation cannot be caught as an attribute >event. Do you have any idea about it? My guess is that we're getting out early in xfs_setattr(), before the DM_EVENT_ATTRIBUTE is generated. At the end of xfs_setattr() you'll find a dm_send_namesp_event() and its corresponding if-wrapper. Put a copy of that if-block earlier in xfs_setattr(), inside the "if (mask & AT_UPDTIMES)" conditional. Let me know if that has anything to do with what you're seeing. Dean From owner-linux-xfs@oss.sgi.com Fri Mar 22 10:58:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MIwti28176 for linux-xfs-outgoing; Fri, 22 Mar 2002 10:58: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 g2MIweq28148 for ; Fri, 22 Mar 2002 10:58:40 -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 g2MK0xBA027849 for ; Fri, 22 Mar 2002 12:00: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 MAA88198 for ; Fri, 22 Mar 2002 12:59: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 MAA02838 for ; Fri, 22 Mar 2002 12:59:43 -0600 (CST) Subject: LVM patch for XFS 1.1-PR2 release From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-mxa6L/kxZVtKE9e3Cat7" X-Mailer: Evolution/1.0.2 Date: 22 Mar 2002 12:59:43 -0600 Message-Id: <1016823583.6022.18.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-mxa6L/kxZVtKE9e3Cat7 Content-Type: text/plain Content-Transfer-Encoding: 7bit Whoops, I patched the 2.4.9-31 kernels for LVM 1.0.3, but then forgot to enable LVM in the configs. And it turns out that as it is, it won't compile. Well... that's why we issue test releases I guess. Thanks for finding it, Seth! :) If anyone wants to use LVM with this release, here's a patch to get it building again; we'll get it turned on in the next spin. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. --=-mxa6L/kxZVtKE9e3Cat7 Content-Disposition: attachment; filename=lvm_fix_2.4.9.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/x-patch; charset=ISO-8859-1 diff -urp linux-2.4.9-31-RH-xfs-1.1-newdelalloc/drivers/md/lvm-snap.c linux= -2.4.9-31-RH-xfs-1.1/drivers/md/lvm-snap.c --- linux-2.4.9-31-RH-xfs-1.1-newdelalloc/drivers/md/lvm-snap.c Tue Mar 19 = 11:59:48 2002 +++ linux-2.4.9-31-RH-xfs-1.1/drivers/md/lvm-snap.c Fri Mar 22 10:15:22 2002 @@ -540,9 +540,10 @@ out: int lvm_snapshot_alloc(lv_t * lv_snap) { int ret, max_sectors; + int nbhs =3D KIO_MAX_SECTORS; =20 /* allocate kiovec to do chunk io */ - ret =3D alloc_kiovec(1, &lv_snap->lv_iobuf); + ret =3D alloc_kiovec_sz(1, &lv_snap->lv_iobuf, &nbhs); if (ret) goto out; =20 max_sectors =3D KIO_MAX_SECTORS << (PAGE_SHIFT-9); @@ -551,7 +552,7 @@ int lvm_snapshot_alloc(lv_t * lv_snap) if (ret) goto out_free_kiovec; =20 /* allocate kiovec to do exception table io */ - ret =3D alloc_kiovec(1, &lv_snap->lv_COW_table_iobuf); + ret =3D alloc_kiovec_sz(1, &lv_snap->lv_COW_table_iobuf, &nbhs); if (ret) goto out_free_kiovec; =20 ret =3D lvm_snapshot_alloc_iobuf_pages(lv_snap->lv_COW_table_iobuf, @@ -566,12 +567,12 @@ out: =20 out_free_both_kiovecs: unmap_kiobuf(lv_snap->lv_COW_table_iobuf); - free_kiovec(1, &lv_snap->lv_COW_table_iobuf); + free_kiovec_sz(1, &lv_snap->lv_COW_table_iobuf, &nbhs); lv_snap->lv_COW_table_iobuf =3D NULL; =20 out_free_kiovec: unmap_kiobuf(lv_snap->lv_iobuf); - free_kiovec(1, &lv_snap->lv_iobuf); + free_kiovec_sz(1, &lv_snap->lv_iobuf, &nbhs); lv_snap->lv_iobuf =3D NULL; vfree(lv_snap->lv_snapshot_hash_table); lv_snap->lv_snapshot_hash_table =3D NULL; @@ -580,6 +581,8 @@ out_free_kiovec: =20 void lvm_snapshot_release(lv_t * lv) { + int nbhs =3D KIO_MAX_SECTORS; + if (lv->lv_block_exception) { vfree(lv->lv_block_exception); @@ -595,14 +598,14 @@ void lvm_snapshot_release(lv_t * lv) { kiobuf_wait_for_io(lv->lv_iobuf); unmap_kiobuf(lv->lv_iobuf); - free_kiovec(1, &lv->lv_iobuf); + free_kiovec_sz(1, &lv->lv_iobuf, &nbhs); lv->lv_iobuf =3D NULL; } if (lv->lv_COW_table_iobuf) { kiobuf_wait_for_io(lv->lv_COW_table_iobuf); unmap_kiobuf(lv->lv_COW_table_iobuf); - free_kiovec(1, &lv->lv_COW_table_iobuf); + free_kiovec_sz(1, &lv->lv_COW_table_iobuf, &nbhs); lv->lv_COW_table_iobuf =3D NULL; } } diff -urp linux-2.4.9-31-RH-xfs-1.1-newdelalloc/drivers/md/lvm.c linux-2.4.= 9-31-RH-xfs-1.1/drivers/md/lvm.c --- linux-2.4.9-31-RH-xfs-1.1-newdelalloc/drivers/md/lvm.c Tue Mar 19 11:59= :48 2002 +++ linux-2.4.9-31-RH-xfs-1.1/drivers/md/lvm.c Fri Mar 22 10:25:22 2002 @@ -401,7 +400,6 @@ struct file_operations lvm_chr_fops =3D { /* block device operations structure needed for 2.3.38? and above */ struct block_device_operations lvm_blk_dops =3D { - owner: THIS_MODULE, open: lvm_blk_open, release: lvm_blk_close, ioctl: lvm_blk_ioctl, --- linux-2.4.9-31-RH-xfs-1.1-newdelalloc/include/linux/lvm.h Tue Mar 19 13= :47:47 2002 +++ linux-2.4.9-31-RH-xfs-1.1/include/linux/lvm.h Fri Mar 22 10:25:13 2002 @@ -92,6 +92,9 @@ /* if you like emergency reset code in the driver */ #define LVM_TOTAL_RESET =20 +#define min(a, b) ((a) < (b) ? (a) : (b)) +#define max(a, b) ((a) > (b) ? (a) : (b)) + #ifdef __KERNEL__ #undef LVM_HD_NAME /* display nice names in /proc/partitions */ =20 --=-mxa6L/kxZVtKE9e3Cat7-- From owner-linux-xfs@oss.sgi.com Fri Mar 22 12:47:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MKllK29992 for linux-xfs-outgoing; Fri, 22 Mar 2002 12:47:47 -0800 Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MKlYq29965 for ; Fri, 22 Mar 2002 12:47:34 -0800 Received: from slc-unislc.slc.unisys.com ([192.60.174.32]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id UAA26300; Fri, 22 Mar 2002 20:48:55 GMT Received: from localhost.localdomain (slc-knysna.slc.unisys.com [192.60.130.30]) by slc-unislc.slc.unisys.com (8.9.3/UW7.1.1) with ESMTP id NAA03351; Fri, 22 Mar 2002 13:49:48 -0700 (MST) Received: from there (slc-knysna [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with SMTP id g2MKnlR05076; Fri, 22 Mar 2002 13:49:47 -0700 Message-Id: <200203222049.g2MKnlR05076@localhost.localdomain> Content-Type: text/plain; charset="iso-8859-1" From: Warren Stockton Reply-To: wns@slc.unisys.com To: Nathan Straz , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Date: Fri, 22 Mar 2002 13:49:47 -0700 X-Mailer: KMail [version 1.3.2] References: <200203212057.g2LKvaR30093@localhost.localdomain> <20020321213201.GO32176@sgi.com> In-Reply-To: <20020321213201.GO32176@sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well done.... Stability has improved tremendously from the earlier version and it is far more econonical on memory. Now I just get a few of these show up intermittently while running on 70 fibre drives on 5 qla2200 controllers. wait_on_irq, CPU 0: irq: 1 [ 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 ] bh: 1 [ 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] Stack dumps: CPU 0: Call Trace: [] sp=0xe000000048b7fa60 bsp=0xe000000048b79928 decoded to show_stack [kernel] 0x50 [] sp=0xe000000048b7fc20 bsp=0xe000000048b798f8 decoded to show [kernel] 0x310 [] sp=0xe000000048b7fc20 bsp=0xe000000048b798a8 decoded to __global_cli [kernel] 0x3e0 [] sp=0xe000000048b7fc20 bsp=0xe000000048b79868 decoded to rs_timer [kernel] 0xa0 [] sp=0xe000000048b7fc20 bsp=0xe000000048b797f0 decoded to __run_timers [kernel] 0x290 [] sp=0xe000000048b7fc20 bsp=0xe000000048b797c0 decoded to run_all_timers [kernel] 0xc0 [] sp=0xe000000048b7fc20 bsp=0xe000000048b797a0 decoded to bh_action [kernel] 0x110 [] sp=0xe000000048b7fc20 bsp=0xe000000048b79750 decoded to tasklet_hi_action [kernel] 0x250 [] sp=0xe000000048b7fc20 bsp=0xe000000048b796d8 decoded to do_softirq [kernel] 0x140 [] sp=0xe000000048b7fc20 bsp=0xe000000048b796b0 decoded to ia64_handle_irq [kernel] 0x100 [] sp=0xe000000048b7fc20 bsp=0xe000000048b796b0 decoded to ia64_leave_kernel [kernel] 0x0 [] sp=0xe000000048b7fdc0 bsp=0xe000000048b79510 decoded to long_copy_user [kernel] 0xd0 [] sp=0xe000000048b7fdc0 bsp=0xe000000048b79440 decoded to __pagebuf_do_delwri [kernel] 0x220 [] sp=0xe000000048b7fdd0 bsp=0xe000000048b79370 decoded to _pagebuf_file_write [kernel] 0x260 [] sp=0xe000000048b7fe10 bsp=0xe000000048b79280 decoded to pagebuf_generic_file_write [kernel] 0x2c0 [] sp=0xe000000048b7fe20 bsp=0xe000000048b791d0 decoded to xfs_write [kernel] 0x390 [] sp=0xe000000048b7fe20 bsp=0xe000000048b79178 decoded to linvfs_write [kernel] 0x5d0 [] sp=0xe000000048b7fe60 bsp=0xe000000048b79100 decoded to sys_write [kernel] 0x210 [] sp=0xe000000048b7fe60 bsp=0xe000000048b79100 decoded to ia64_ret_from_syscall [kernel] 0x0 Then I just need a patch to eliminate the lru_list_lock... Warren. On Thursday 21 March 2002 14:32, Nathan Straz wrote: > On Thu, Mar 21, 2002 at 01:57:36PM -0700, Warren Stockton wrote: > > What compiler would you recommend for ia64? > > We are still building ia64 kernels with 2.96 (-85 or -101) and we > haven't found any compiler related issues yet. > > David Mosberger is compiling ia64 kernels with gcc 3.0, but I doubt he's > compiling XFS in his kernels. The general concensus on the linux-ia64 > list is that gcc 3.1 doesn't compile bootable ia64 kernels. > > So all I can recommand now is staying with 2.96. I would like to hear > any success stories with 3.0 or later compilers. From owner-linux-xfs@oss.sgi.com Fri Mar 22 12:53:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MKri930309 for linux-xfs-outgoing; Fri, 22 Mar 2002 12:53:44 -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 g2MKrbq30282 for ; Fri, 22 Mar 2002 12:53:37 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-104.quicknet.nl [212.58.163.104]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2MKttiX086604; Fri, 22 Mar 2002 21:55:55 +0100 (CET) Message-Id: <4.3.2.7.2.20020322215033.03919e58@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Mar 2002 21:53:11 +0100 To: wns@slc.unisys.com, Nathan Straz , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing In-Reply-To: <200203222049.g2MKnlR05076@localhost.localdomain> References: <20020321213201.GO32176@sgi.com> <200203212057.g2LKvaR30093@localhost.localdomain> <20020321213201.GO32176@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:49 22-3-2002 -0700, Warren Stockton wrote: >Well done.... > >Stability has improved tremendously from the earlier version and >it is far more econonical on memory. sarcasm ? If so in contrast to what? >Now I just get a few of these show up intermittently while running >on 70 fibre drives on 5 qla2200 controllers. That doesn't seem very healthy. Is this compiled with kgcc, 2.96 or gcc3? Is this on ia64 or ia32? 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 22 13:21:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MLL7p31002 for linux-xfs-outgoing; Fri, 22 Mar 2002 13:21: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 g2MLL5q30975 for ; Fri, 22 Mar 2002 13:21:05 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2MLNN6G001644 for ; Fri, 22 Mar 2002 13:23:23 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA12538 for ; Fri, 22 Mar 2002 15:22:07 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.35 #1 (Debian)) id 16oWUA-0000e4-00 for ; Fri, 22 Mar 2002 15:22:06 -0600 Date: Fri, 22 Mar 2002 15:22:05 -0600 From: Nathan Straz To: linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Message-ID: <20020322212205.GD11391@sgi.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200203212057.g2LKvaR30093@localhost.localdomain> <20020321213201.GO32176@sgi.com> <200203222049.g2MKnlR05076@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203222049.g2MKnlR05076@localhost.localdomain> User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stupid questions first: What kernel are you running? What compiler did you use? Do you know how to reproduce this? Can you compile the kernel with kdb and get more info? -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Fri Mar 22 14:00:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MM0pg31855 for linux-xfs-outgoing; Fri, 22 Mar 2002 14:00:51 -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 g2MM0eq31820 for ; Fri, 22 Mar 2002 14:00:40 -0800 Received: from eamail1-out.unisys.com ([192.61.61.99]) 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 OAA04849 for ; Fri, 22 Mar 2002 14:03:06 -0800 (PST) mail_from (wns@slc.unisys.com) Received: from slc-unislc.slc.unisys.com ([192.60.174.32]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id VAA12644; Fri, 22 Mar 2002 21:53:51 GMT Received: from localhost.localdomain (slc-knysna.slc.unisys.com [192.60.130.30]) by slc-unislc.slc.unisys.com (8.9.3/UW7.1.1) with ESMTP id OAA03923; Fri, 22 Mar 2002 14:54:45 -0700 (MST) Received: from there (slc-knysna [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with SMTP id g2MLsjR05421; Fri, 22 Mar 2002 14:54:45 -0700 Message-Id: <200203222154.g2MLsjR05421@localhost.localdomain> Content-Type: text/plain; charset="iso-8859-1" From: Warren Stockton Reply-To: wns@slc.unisys.com To: Seth Mos , Nathan Straz , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Date: Fri, 22 Mar 2002 14:54:44 -0700 X-Mailer: KMail [version 1.3.2] References: <20020321213201.GO32176@sgi.com> <4.3.2.7.2.20020322215033.03919e58@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20020322215033.03919e58@pop.xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Friday 22 March 2002 13:53, Seth Mos wrote: > At 13:49 22-3-2002 -0700, Warren Stockton wrote: > >Well done.... > > > >Stability has improved tremendously from the earlier version and > >it is far more econonical on memory. > > sarcasm ? > If so in contrast to what? No. I had taken the XFS code from 2.4.9-6SGI-XFS1.0.2 and the XFS CVS updates and merged it with RH 2.4.9.-21 and built with gcc3-3.0.1-3. I was still working some issues when I saw this announcement yesterday. My hacked code would have 98% of memory allocated to cache within 3 minutes of starting the test. (Beyond this point it was hard-hats only and falling machine parts) -31XFS1.1-pre2 running the same test has the cache somewhere between 25% to 75% of physical memory, depending on where the testsuite is in its cycle. So far I tested 70 drives active where total active open files = 50% of physical memory (16G) (Test ran about 7hours with no errors or data corruption before I stopped it.) IO stats showed numbers ext2 can only dream about. Currently testing 70 drives active where total active open files = 3x physical memory. Has been running 5hours with no lock-ups, errors or data corruption and the 32 copies of setiathome are still making good progress and the IO stats are literally 100x better that I ever got with ext2!!! Time to hand over the the benchmark guys!!! > > >Now I just get a few of these show up intermittently while running > >on 70 fibre drives on 5 qla2200 controllers. > > That doesn't seem very healthy. Is this compiled with kgcc, 2.96 or gcc3? gcc-2.96-101 > > Is this on ia64 or ia32? ia64 C1 steppings > > Cheers From owner-linux-xfs@oss.sgi.com Fri Mar 22 14:03:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2MM3F632019 for linux-xfs-outgoing; Fri, 22 Mar 2002 14:03:15 -0800 Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2MM36q31984 for ; Fri, 22 Mar 2002 14:03:06 -0800 Received: from slc-unislc.slc.unisys.com ([192.60.174.32]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id WAA15614; Fri, 22 Mar 2002 22:04:15 GMT Received: from localhost.localdomain (slc-knysna.slc.unisys.com [192.60.130.30]) by slc-unislc.slc.unisys.com (8.9.3/UW7.1.1) with ESMTP id PAA04040; Fri, 22 Mar 2002 15:05:10 -0700 (MST) Received: from there (slc-knysna [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with SMTP id g2MM5AR05485; Fri, 22 Mar 2002 15:05:10 -0700 Message-Id: <200203222205.g2MM5AR05485@localhost.localdomain> Content-Type: text/plain; charset="iso-8859-1" From: Warren Stockton Reply-To: wns@slc.unisys.com To: Nathan Straz , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Date: Fri, 22 Mar 2002 15:05:09 -0700 X-Mailer: KMail [version 1.3.2] References: <200203222049.g2MKnlR05076@localhost.localdomain> <20020322212205.GD11391@sgi.com> In-Reply-To: <20020322212205.GD11391@sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Friday 22 March 2002 14:22, Nathan Straz wrote: > Stupid questions first: > > What kernel are you running? 2.4.9-31SGI-XFS1.1 + some plaform patches we swear by... (or at) > What compiler did you use? gcc-2.96-101 > Do you know how to reproduce this? Generate lots of I/O I don't mean to be flipant but I was expecting the IO subsystem to buckle under the strain > Can you compile the kernel with kdb and get more info? I had expected kdb, but after reading the .spec file saw that the "prep" does not apply the patch, so the next build will include kdb. I am not concerned about these being an XFS bug. It has more to do with the handling of "bottom halves" and the __global_cli() call, as can be seen by the following: wait_on_irq, CPU 0: irq: 1 [ 0 0 0 0 0 0 1 0 1 1 1 0 0 0 0 0 ] bh: 1 [ 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] Stack dumps: CPU 0: Call Trace: [] sp=0xe0000000d8c37b00 bsp=0xe0000000d8c31418 decoded to show_stack [kernel] 0x50 [] sp=0xe0000000d8c37cc0 bsp=0xe0000000d8c313e0 decoded to show [kernel] 0x310 [] sp=0xe0000000d8c37cc0 bsp=0xe0000000d8c31390 decoded to __global_cli [kernel] 0x3e0 [] sp=0xe0000000d8c37cc0 bsp=0xe0000000d8c31350 decoded to rs_timer [kernel] 0xa0 [] sp=0xe0000000d8c37cc0 bsp=0xe0000000d8c312e0 decoded to __run_timers [kernel] 0x290 [] sp=0xe0000000d8c37cc0 bsp=0xe0000000d8c312b0 decoded to run_all_timers [kernel] 0xc0 [] sp=0xe0000000d8c37cc0 bsp=0xe0000000d8c31290 decoded to bh_action [kernel] 0x110 [] sp=0xe0000000d8c37cc0 bsp=0xe0000000d8c31240 decoded to tasklet_hi_action [kernel] 0x250 [] sp=0xe0000000d8c37cc0 bsp=0xe0000000d8c311c0 decoded to do_softirq [kernel] 0x140 [] sp=0xe0000000d8c37cc0 bsp=0xe0000000d8c31198 decoded to ia64_handle_irq [kernel] 0x100 [] sp=0xe0000000d8c37cc0 bsp=0xe0000000d8c31198 decoded to ia64_leave_kernel [kernel] 0x0 [] sp=0xe0000000d8c37e60 bsp=0xe0000000d8c31110 decoded to sys_lseek [kernel] 0x110 [] sp=0xe0000000d8c37e60 bsp=0xe0000000d8c31110 decoded to ia64_ret_from_syscall [kernel] 0x0 From owner-linux-xfs@oss.sgi.com Fri Mar 22 17:57:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2N1vt103539 for linux-xfs-outgoing; Fri, 22 Mar 2002 17:57:55 -0800 Received: from fruit.eu.org (qmailr@38dyn120.com21.casema.net [213.17.111.120]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2N1voq03513 for ; Fri, 22 Mar 2002 17:57:51 -0800 Received: (qmail 93245 invoked by uid 500); 23 Mar 2002 02:00:12 -0000 Date: Sat, 23 Mar 2002 03:00:12 +0100 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: TAKE - reduce xfs log memory usage Message-ID: <20020323030012.X412@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200203191723.g2JHN5O05197@jen.americas.sgi.com> <20020319183620.A27373@oldwotan.suse.de> <1016559518.1841.36.camel@jen.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: <1016559518.1841.36.camel@jen.americas.sgi.com>; from lord@sgi.com on Tue, Mar 19, 2002 at 11:38:38AM -0600 X-oi: oi Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 2002-03-19 11:38:38-0600, Steve Lord wrote: > each, and all log writes started 512 bytes into a page. The > latter was one of the causes of raid5 cache thrashing, but there > is more to do on that problem. By the way, is XFS-on-raid5 just slow or also unstable? I don't mind having a slow file system while XFS and raid5 get to know each other a little better but I would hate to see them throw around my files during a fight :) Regards, -- Wessel Dankers From owner-linux-xfs@oss.sgi.com Fri Mar 22 22:35:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2N6ZJH06008 for linux-xfs-outgoing; Fri, 22 Mar 2002 22:35:19 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2N6ZEq05982 for ; Fri, 22 Mar 2002 22:35:14 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16of9i-0002Ks-00; Sat, 23 Mar 2002 01:37:34 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g2N6bWW02009; Sat, 23 Mar 2002 01:37:32 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: Wessel Dankers Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - reduce xfs log memory usage From: "Martin K. Petersen" Organization: Linuxcare, Inc. References: <200203191723.g2JHN5O05197@jen.americas.sgi.com> <20020319183620.A27373@oldwotan.suse.de> <1016559518.1841.36.camel@jen.americas.sgi.com> <20020323030012.X412@fruit.eu.org> Date: 23 Mar 2002 01:37:32 -0500 In-Reply-To: <20020323030012.X412@fruit.eu.org> Message-ID: Lines: 15 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 >>>>> "Wessel" == Wessel Dankers writes: Wessel> On 2002-03-19 11:38:38-0600, Steve Lord wrote: >> each, and all log writes started 512 bytes into a page. The latter >> was one of the causes of raid5 cache thrashing, but there is more >> to do on that problem. Wessel> By the way, is XFS-on-raid5 just slow or also unstable? Just slow (depending on your workload). -- 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 23 03:19:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2NBJYi08949 for linux-xfs-outgoing; Sat, 23 Mar 2002 03:19:34 -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 g2NBJTq08923 for ; Sat, 23 Mar 2002 03:19:29 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-104.quicknet.nl [212.58.163.104]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2NBLobF074077; Sat, 23 Mar 2002 12:21:50 +0100 (CET) Message-Id: <4.3.2.7.2.20020323121811.02e576b8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 23 Mar 2002 12:19:00 +0100 To: Wessel Dankers , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: TAKE - reduce xfs log memory usage In-Reply-To: <20020323030012.X412@fruit.eu.org> References: <1016559518.1841.36.camel@jen.americas.sgi.com> <200203191723.g2JHN5O05197@jen.americas.sgi.com> <20020319183620.A27373@oldwotan.suse.de> <1016559518.1841.36.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 03:00 23-3-2002 +0100, Wessel Dankers wrote: >On 2002-03-19 11:38:38-0600, Steve Lord wrote: > > each, and all log writes started 512 bytes into a page. The > > latter was one of the causes of raid5 cache thrashing, but there > > is more to do on that problem. > >By the way, is XFS-on-raid5 just slow or also unstable? I don't mind >having a slow file system while XFS and raid5 get to know each other a >little better but I would hate to see them throw around my files during >a fight :) Just slow, it works fine here. With the newer kernel the speed should get a boost. 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 Sat Mar 23 03:59:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2NBxpE09416 for linux-xfs-outgoing; Sat, 23 Mar 2002 03:59:51 -0800 Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2NBxkq09389 for ; Sat, 23 Mar 2002 03:59:46 -0800 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g2NC1wd00413 for ; Sat, 23 Mar 2002 21:01:58 +0900 (JST) Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g2NC1vd10290 for ; Sat, 23 Mar 2002 21:01:57 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id g2NC1ui16516 for ; Sat, 23 Mar 2002 21:01:56 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA126 for ; Sat, 23 Mar 2002 21:01:55 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Sat Mar 23 21:01:54 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g2NC1s675388 for ; Sat, 23 Mar 2002 21:01:55 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id g2NC1sO24229 for ; Sat, 23 Mar 2002 21:01:54 +0900 To: linux-xfs@oss.sgi.com Subject: bomb and force shutdown again X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020323210154F.masano@tnes.nec.co.jp> Date: Sat, 23 Mar 2002 21:01:54 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 14 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, The disk error handling of the recent xfs cvs kernel (20020323, 2.4.18) seems broken. I tested xfs with BOMB patch I previously posted to this list. After force shutdown by the bomb, the system was hanged and I could not enter KDB at my single CPU box. When I tested at 2.4.17 cvs kernel, it passed; the filesystem was just shutting down and I could umount it. -- Masano From owner-linux-xfs@oss.sgi.com Sat Mar 23 09:24:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2NHOtb13439 for linux-xfs-outgoing; Sat, 23 Mar 2002 09:24:55 -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 g2NHOoq13413 for ; Sat, 23 Mar 2002 09:24:51 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx04)) with ESMTP id 9CD9E618D for ; Sat, 23 Mar 2002 18:27: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 SAA05335 for linux-xfs@oss.sgi.com; Sat, 23 Mar 2002 18:27:06 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 5DEBC57306 for ; Sat, 23 Mar 2002 18:26:52 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 93BF825835 for ; Sat, 23 Mar 2002 18:26:51 +0100 (CET) Message-ID: <3C9CBADB.86691E88@ch.sauter-bc.com> Date: Sat, 23 Mar 2002 18:26:51 +0100 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: No kdb in 2.4.9-31SGI_XFS_1.1_PR2 ? Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, My home server is an AMD K6/400 on VIA mobo. It's not fast but works fine. The soft powerdown of this board is a bit special and instead of powering off with linux, it just crashes the kernel. Now, that was good for me because I don't have a monitor on this machine. I powerdown, the kernel crashes and gets into kdb and the keyboard LED's start flashing. When I see the flashing led's, I know it's time to safely turn power off. It seems that kdb is missing in 2.4.9-31SGI_XFS_1.1_PR2. Do we get kdb back in PR3 ? I need the flashing LED's :-) -Simon From owner-linux-xfs@oss.sgi.com Sat Mar 23 11:44:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2NJidX15721 for linux-xfs-outgoing; Sat, 23 Mar 2002 11:44:39 -0800 Received: from mail.blazebox.homeip.net (postfix@pool-141-155-137-69.ny5030.east.verizon.net [141.155.137.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2NJiOq15691 for ; Sat, 23 Mar 2002 11:44:25 -0800 Received: from blaze.homeip.net (blaze.homeip.net [192.168.0.2]) by mail.blazebox.homeip.net (Postfix) with ESMTP id BFA5222998 for ; Sat, 23 Mar 2002 14:45:17 -0500 (EST) Subject: XFS lastest changes, sb corruption? From: Paul Blazejowski To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ACIrwRyz38nUaLH+Uy/0" Organization: X-Mailer: Evolution/1.1.0.99 (Preview Release) Date: 23 Mar 2002 14:46:26 -0500 Message-Id: <1016912787.1751.23.camel@blaze> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-ACIrwRyz38nUaLH+Uy/0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello folks, I've been using XFS filesystem for long time and somewhat track the developement and try to stay up to date with the changes in 2.4 CVS tree. I just built a recent kernel from 03-22-2002 cvs on Slackware Linux 8.0 with gcc 2.95.3 that Slackware ships.I took these steps: update the linux-2.4 tree generate diff against kernel.org 2.4.18 source (diff -Nur --exclude=3DCVS /usr/src/linux-2.4.18 linux > ...) patch JFS 0.1.16 code first (patch -p1 option) patch XFS diff from 03-22-2002 (patch -p1 option) all in linux directory Went to compile kernel as usual and there was no problems, all compiled fine.XFS is build right into kernel and JFS as module but i dont think this should matter. Upon reboot to test new kernel and after my AHA-2940U2W adapter is scanned i get a message that XFS has bad magic number on /dev/sda2 and it's primary superblock has been corrupted and it just halts there...i was able to use SYSRQ to reboot the system. Tried to boot with my previous working kernels (2.4.18 and 2.4.5 both with XFS) and got the same errors that superblock is corrupted and has bad magic... I should note that there was never any oops'es or crashes on my box and hard disk seems to be fine too. I was able to boot to my other Linux LFS system that is on another partition and from there run xfs_repair on the bad partition.All of the xfs utilities are the latest version as of 03-22-2002.Xfs_repair was able to recover the primary superblock from it's secondary copy and repair my partition without any errors. My question is to what could cause such sudden corrruption of superblock and if it has to do anything with recent changes that went into CVS? Is there anything i should do to verify that the filesystem is indeed OK? I would appreciate any help or suggestions on this matter.Thank you for such a great filesystem and your hard work to port it to Linux. Regards, Paul B. --=20 _________________________________ ( http://www.linuxdiscussions.org ) --=-ACIrwRyz38nUaLH+Uy/0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjyc25IACgkQOkMJCMfleaKpKQCg0TDQwByXrD3P+M1+MOeyGiOd fg0An01vd5Ke6zjymhB0kA/ihYOEKVyu =TmNm -----END PGP SIGNATURE----- --=-ACIrwRyz38nUaLH+Uy/0-- From owner-linux-xfs@oss.sgi.com Sat Mar 23 14:12:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2NMC4919460 for linux-xfs-outgoing; Sat, 23 Mar 2002 14:12:04 -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 g2NMBxq19434 for ; Sat, 23 Mar 2002 14:11:59 -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 g2NMEH6G024562 for ; Sat, 23 Mar 2002 14:14:17 -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 QAA07445; Sat, 23 Mar 2002 16:13:02 -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 QAA29934; Sat, 23 Mar 2002 16:13:01 -0600 (CST) Date: Sat, 23 Mar 2002 16:13:01 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Simon Matter cc: Subject: Re: No kdb in 2.4.9-31SGI_XFS_1.1_PR2 ? In-Reply-To: <3C9CBADB.86691E88@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 - the kdb patch is shipped in the SRPM, but it's not applied by default. We decided that xfs should be mature enough that we don't have to ship it with the debugger enabled. Hopefully that's true. :) So if you're at all RPM-savvy, you can enable it in the spec file and rebuild your RPM, and you should be good to go. If you need some help let me know. -Eric On Sat, 23 Mar 2002, Simon Matter wrote: > Hi, > > My home server is an AMD K6/400 on VIA mobo. It's not fast but works > fine. The soft powerdown of this board is a bit special and instead of > powering off with linux, it just crashes the kernel. Now, that was good > for me because I don't have a monitor on this machine. I powerdown, the > kernel crashes and gets into kdb and the keyboard LED's start flashing. > When I see the flashing led's, I know it's time to safely turn power > off. > > It seems that kdb is missing in 2.4.9-31SGI_XFS_1.1_PR2. Do we get kdb > back in PR3 ? I need the flashing LED's :-) > > -Simon > > From owner-linux-xfs@oss.sgi.com Sat Mar 23 14:17:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2NMHKu19645 for linux-xfs-outgoing; Sat, 23 Mar 2002 14:17:20 -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 g2NMHFq19618 for ; Sat, 23 Mar 2002 14:17:15 -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 g2NNRvkw001336 for ; Sat, 23 Mar 2002 17:27:57 -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 QAA94253; Sat, 23 Mar 2002 16:18:18 -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 QAA92635; Sat, 23 Mar 2002 16:18:17 -0600 (CST) Date: Sat, 23 Mar 2002 16:18:17 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Paul Blazejowski cc: Subject: Re: XFS lastest changes, sb corruption? In-Reply-To: <1016912787.1751.23.camel@blaze> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 23 Mar 2002, Paul Blazejowski wrote: > Upon reboot to test new kernel and after my AHA-2940U2W adapter is > scanned i get a message that XFS has bad magic number on /dev/sda2 > and it's primary superblock has been corrupted and it just halts > there...i was able to use SYSRQ to reboot the system. There was a bug a couple months ago that would corrupt the superblock after a forced shutdown - but you're certain that there was never any such event on this system? What kernel version did you upgrade from? If you had a forced shutdown it should be in the logs (hm, unless the forced shutdown happened on your root fs, then I'm not sure the message would make it out). Since you've already repaired the FS, we can't look at the first few kilobytes of the fs to see what might have happened... > Is there anything i should do to verify that the filesystem is indeed > OK? You could run xfs_repair -n to look for problems, but you already ran xfs_repair so it _really_ should not find anything. :) check /lost+found to see if anything got deposited there. -Eric From owner-linux-xfs@oss.sgi.com Sat Mar 23 16:01:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2O010321393 for linux-xfs-outgoing; Sat, 23 Mar 2002 16:01:00 -0800 Received: from mail.blazebox.homeip.net (postfix@pool-141-155-137-69.ny5030.east.verizon.net [141.155.137.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2O00nq21357 for ; Sat, 23 Mar 2002 16:00:50 -0800 Received: from blaze.homeip.net (blaze.homeip.net [192.168.0.2]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 150CC22998; Sat, 23 Mar 2002 19:01:51 -0500 (EST) Subject: Re: XFS lastest changes, sb corruption? From: Paul Blazejowski To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pxocrXuztRagKgiQ+pcP" Organization: X-Mailer: Evolution/1.1.0.99 (Preview Release) Date: 23 Mar 2002 19:03:01 -0500 Message-Id: <1016928182.5040.21.camel@blaze> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-pxocrXuztRagKgiQ+pcP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2002-03-23 at 17:18, Eric Sandeen wrote: > There was a bug a couple months ago that would corrupt the superblock > after a forced shutdown - but you're certain that there was never any such > event on this system? What kernel version did you upgrade from? If you > had a forced shutdown it should be in the logs (hm, unless the forced > shutdown happened on your root fs, then I'm not sure the message would > make it out). Since you've already repaired the FS, we can't look at the > first few kilobytes of the fs to see what might have happened... Thanks for fast replay :-).Yes, i am sure that the system had no forced shutdowns and it never crashed too...for a record i never had anything bad happen to XFS on my Slackware system and i've run XFS since 2.4-test series on my 17gig SCSI partition.Previous to sb corruption i run kernel 2.4.18 + XFS code from CVS from around 02-26-2002.My current kernel version is: Linux blaze 2.4.18-xfs #1 Fri Mar 22 14:01:31 EST 2002 i686 unknown.I wanted to get the system running fast and did not thought about saving any errors/messages/logs...well if it happens again (which i hope will not) i know what to do. > You could run xfs_repair -n to look for problems, but you already ran > xfs_repair so it _really_ should not find anything. :) check /lost+found > to see if anything got deposited there. I did check my /lost+found directory and did not find files or directories there...i assume that all my files are intact :).Thanks again. Regards, Paul --=20 _________________________________ ( http://www.linuxdiscussions.org ) --=-pxocrXuztRagKgiQ+pcP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjydF7UACgkQOkMJCMfleaJZRQCg2sDWWz6ZXqtPcLrcbRj8vmwX WnkAnRrg0TLjZDSqlRrUMidsaTsgmxIt =kmLw -----END PGP SIGNATURE----- --=-pxocrXuztRagKgiQ+pcP-- From owner-linux-xfs@oss.sgi.com Sat Mar 23 23:54:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2O7sWo27797 for linux-xfs-outgoing; Sat, 23 Mar 2002 23:54:32 -0800 Received: from mail.blaze.homeip.net (pool-141-155-137-69.ny5030.east.verizon.net [141.155.137.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2O7sOq27769 for ; Sat, 23 Mar 2002 23:54:25 -0800 Received: by mail.blaze.homeip.net (Postfix, from userid 4444) id 4021C5C268; Sun, 24 Mar 2002 02:56:37 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Paul Blazejowski To: Eric Sandeen Subject: Re: XFS latest changes, sb corruption? Date: Sun, 24 Mar 2002 02:56:36 -0500 X-Mailer: KMail [version 1.3.2] Cc: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020324075637.4021C5C268@mail.blaze.homeip.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Eric, I have a bug i think...i was able to reproduce the sb corruption after compiling new kernel. Updated my xfs tree with todays CVS (no changes) then i generated a diff against clean 2.4.18 kernel patched with xfs and jfs patches,did make dep then make bzImage followed by make modules...all of these steps went fine. I rerun /sbin/lilo to update the loader and made a quick boot disk using: dd if=/dev/sda2 of=/dev/fd0 ibs=1440 count=1 (sda2 is the partition with xfs). Again there was no crashes or forced shutdowns...rebooted the box and when new kernel booted it showed these errors: XFS: bad magic number XFS: SB validate failed VFS: unable to mount block device on (8,2) or something close. Again this is on Slackware Linux 8.0 with kernel 2.4.18 and gcc 2.95.3. This is what xfs_repair shows: xfs_repair -n /dev/sda2 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... .................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................found candidate secondary superblock... verified secondary superblock... would write modified primary superblock primary superblock would have been modified. cannot proceed further in no_modify mode. exiting now. I did not make any changes to the fs yet...how would i pull the first few kb off of the fs you mentioned earlier? Thanks again for your help. Regards, Paul From owner-linux-xfs@oss.sgi.com Sun Mar 24 02:52:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OAqfV30901 for linux-xfs-outgoing; Sun, 24 Mar 2002 02:52:41 -0800 Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2OAqUq30873 for ; Sun, 24 Mar 2002 02:52:30 -0800 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g2OAsmd12045 for ; Sun, 24 Mar 2002 19:54:48 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g2OAslY18851 for ; Sun, 24 Mar 2002 19:54:47 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g2OAslB22027 for ; Sun, 24 Mar 2002 19:54:47 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA433 for ; Sun, 24 Mar 2002 19:54:46 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Sun Mar 24 19:54:45 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g2OAsj635051 for ; Sun, 24 Mar 2002 19:54:45 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id g2OAsjO02693 for ; Sun, 24 Mar 2002 19:54:45 +0900 To: linux-xfs@oss.sgi.com Subject: Re: bomb and force shutdown again In-Reply-To: <20020323210154F.masano@tnes.nec.co.jp> References: <20020323210154F.masano@tnes.nec.co.jp> References: <20020116165541J.masano@tnes.nec.co.jp> X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020324195445T.masano@tnes.nec.co.jp> Date: Sun, 24 Mar 2002 19:54:45 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 73 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, > The disk error handling of the recent xfs cvs kernel (20020323, 2.4.18) > seems broken. Additional information: CVS 2002-02-24 ok CVS 2002-03-13 stalled after fs shutdown CVS 2002-03-23 stalled after fs shutdown > I tested xfs with BOMB patch I previously posted to this list. > After force shutdown by the bomb, the system was hanged and I could > not enter KDB at my single CPU box. On SMP box, I could use KDB. # but I don't have serial console... [0]kdb> ps (snip) 0xc1326000 00000008 00000001 1 001 run 0xc1326370 pagebuf_daemon (snip) 0xc3c0c000 00008958 00000842 1 000 run 0xc3c0c370*bash [0]kdb> bt flush_tlb_others <- loop "while (flush_cpumask) ;" flush_tlb_page do_wp_page handle_mm_fault change_termios error_code Interrupt registers: (snip) Interrupt from user space, end of kernel trace [0]kdb> btp 8 _text_lock_page_buf <- maybe from pagebuf_rele() pagebuf_iodone xfs_bioerror pagebuf_daemon kernel_thread [0]kdb> cpu Currently on cpu 0 Available cpus: 0,1 ** reboot and try again. > ps (snip) 0xc1322000 00000008 00000001 1 000 run 0xc1322370 pagebuf_daemon (snip) 0xc9d40000 00000887 00000886 1 001 run 0xc9d40370*bash > bt flush_tlb_others flush_tlb_mm copy_mm do_fork sys_fork system_call > btp 8 _text_lock_page_buf pagebuf_iodone xfs_bioerror xfs_bdstrat pagebuf_daemon kernel_thread > cpu Currently on cpu 1 Available cpus: 0,1 It looks like page_buf_t issue, but I could not find what led to this. Thanks in advance. -- Masano From owner-linux-xfs@oss.sgi.com Sun Mar 24 03:55:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OBtaQ32094 for linux-xfs-outgoing; Sun, 24 Mar 2002 03:55:36 -0800 Received: from mta3-rme.xtra.co.nz (210-86-15-131.ipnets.xtra.co.nz [210.86.15.131]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2OBtRq32067 for ; Sun, 24 Mar 2002 03:55:27 -0800 Received: from localhost.localdomain ([210.86.53.36]) by mta3-rme.xtra.co.nz with ESMTP id <20020324115745.MELX20246.mta3-rme.xtra.co.nz@localhost.localdomain>; Sun, 24 Mar 2002 23:57:45 +1200 Subject: Re: XFS latest changes, sb corruption? From: mdew To: Paul Blazejowski Cc: Eric Sandeen , xfs In-Reply-To: <20020324075637.4021C5C268@mail.blaze.homeip.net> References: <20020324075637.4021C5C268@mail.blaze.homeip.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 24 Mar 2002 23:57:53 +1200 Message-Id: <1016971074.7957.2.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yeah I've checkout the CVS, and indeed its br0k3n... same Problem. Debian Sid+Preemptive+GCC 3.0.4 Once repairing the drive, its bootable again. On Sun, 2002-03-24 at 19:56, Paul Blazejowski wrote: > Hi Eric, > > I have a bug i think...i was able to reproduce the sb corruption after > compiling new kernel. > > Updated my xfs tree with todays CVS (no changes) then i generated a diff > against clean 2.4.18 kernel patched with xfs and jfs patches,did make dep > then make bzImage followed by make modules...all of these steps went fine. > I rerun /sbin/lilo to update the loader and made a quick boot disk using: > dd if=/dev/sda2 of=/dev/fd0 ibs=1440 count=1 (sda2 is the partition with xfs). > Again there was no crashes or forced shutdowns...rebooted the box and when > new kernel booted it showed these errors: > > XFS: bad magic number > XFS: SB validate failed > VFS: unable to mount block device on (8,2) or something close. > > Again this is on Slackware Linux 8.0 with kernel 2.4.18 and gcc 2.95.3. > > This is what xfs_repair shows: > > xfs_repair -n /dev/sda2 > Phase 1 - find and verify superblock... > bad primary superblock - bad magic number !!! > > attempting to find secondary superblock... > .............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................! > ....................found > candidate secondary superblock... > verified secondary superblock... > would write modified primary superblock > primary superblock would have been modified. > cannot proceed further in no_modify mode. > exiting now. > > I did not make any changes to the fs yet...how would i pull the first few kb > off of the fs you mentioned earlier? Thanks again for your help. > > Regards, > > Paul > -- ph33r! Linux mdew 2.4.18-xfs-preemptive #4 Sun Mar 24 21:44:59 NZST 2002 i686 unknown From owner-linux-xfs@oss.sgi.com Sun Mar 24 05:29:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ODTrU06288 for linux-xfs-outgoing; Sun, 24 Mar 2002 05:29:53 -0800 Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ODTgq06260 for ; Sun, 24 Mar 2002 05:29:42 -0800 Received: from erbenson.alaska.net (206-pm32.nwc.alaska.net [209.112.158.206]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g2ODW4R60559 for ; Sun, 24 Mar 2002 04:32:04 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 1F3E33989 for ; Sun, 24 Mar 2002 04:32:03 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 254B610250; Sun, 24 Mar 2002 04:32:03 -0900 (AKST) Date: Sun, 24 Mar 2002 04:32:03 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: quota permissions Message-ID: <20020324043203.A30975@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I started testing quotas on XFS and found that users cannot find out what thier quota is set to, this is normally found by running the quota command, under 2.2 kernels (this is the first time ive used quota under 2.4) quota details are printed for any filesystems which they have files, with 2.4 and XFS (2.4.18) quota always reports that they have no quotas. strace shows that this appears to be due to the quota syscalls returning EPERM: eb@ash ~$ quota Disk quotas for user eb (uid 1000): none eb@ash ~$ quota -u eb Disk quotas for user eb (uid 1000): none eb@ash ~$ sudo quota -u eb Disk quotas for user eb (uid 1000):=20 Filesystem blocks quota limit grace files quota limit g= race /dev/hda9 0 20480 25600 1 6000 8000=20= =20=20=20=20=20=20=20 eb@ash ~$=20 strace reveals: quotactl(0x5805 /* Q_??? */|USRQUOTA, "/dev/hda9", 0, {16777219, 0, 0, 131,= 0, 7, 5, 0}) =3D 0 stat64(0x10024f88, 0x100274d0) =3D 0 quotactl(0x5805 /* Q_??? */|USRQUOTA, "/dev/hda9", 0, {16777219, 0, 0, 131,= 0, 7, 5, 0}) =3D 0 geteuid() =3D 1000 quotactl(0x5803 /* Q_??? */|USRQUOTA, "/dev/hda9", 1000, {2147481280, 80535= 4732, 805463848, 2147481248, 2147481296, 805354732, 2147481280, 267568876})= =3D -1 EPERM (Operation not permitted) I used the split patches, the following were applied: xfs-2.4.18-split-only.bz2 xfs-2.4.18-split-xattr.bz2 xfs-2.4.18-split-quota32.bz2 xfs-2.4.18-split-kernel.bz2 xfs-2.4.18-split-misc.bz2 xfs-2.4.18-split-acl-dmapi.bz2 as a sidenote, this is probably a quota userland bug, but edquota refused to work initially after activating quotas (i unmounted and remounted the filesystem with the quota mountopt) i had to use edquota -F xfs -u user for the first time, after this it seems to figure out the format without -F. im using quota 3.0.4-1 from debian woody. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --7JfCtLOvnd9MIVvH 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 iEYEARECAAYFAjyd1VIACgkQJKx7GixEevw1SQCgn9gXMsmykXMopn7AyaYDnA1/ 2KIAnROFf2i8lSlRzdWy9GFPjEVaNTpk =mEkH -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-linux-xfs@oss.sgi.com Sun Mar 24 06:54:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OEs6N07627 for linux-xfs-outgoing; Sun, 24 Mar 2002 06:54: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 g2OEs0q07601 for ; Sun, 24 Mar 2002 06:54:01 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id EB848C001D0 for ; Sun, 24 Mar 2002 22:56:21 +0800 (PHT) Received: from mail.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id D891BC001C6 for ; Sun, 24 Mar 2002 22:56:15 +0800 (PHT) Date: Sun, 24 Mar 2002 22:56:15 +0800 (PHT) From: Federico Sevilla III To: Linux XFS Mailing List Subject: 2.4.18-xfs and RML's kernel-preempt (was: XFS latest changes, sb corruption?) In-Reply-To: <1016971074.7957.2.camel@mdew> 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 On 24 Mar 2002 at 23:57, mdew wrote: > Yeah I've checkout the CVS, and indeed its br0k3n... same Problem. > Debian Sid+Preemptive+GCC 3.0.4 Which of RML's kernel-preempt patches are you using against the latest checkout of XFS? Have you tried running things without his patch? I'm curious because when I upgraded to 2.4.18-xfs, I used the 2.4.18 kernel-preempt patch, and it patched properly. Unfortunately the server froze cold after two days uptime. I rebooted. It froze after another two days uptime. Exasperated I went through what I could remove, and thought the preempt patches should go first. I've been running 2.4.18-xfs checked out from CVS 2002-03-12 and built without RML's kernel-preempt for 12d9h now. So far so good. This was compiled using gcc-3.0.4 and runs on Debian/Sid as well. BTW, didn't have any of the corruption errors, though. None related to XFS, anyway. We had some database files gone bonkers thanks to an MS-DOS program running on some client accessing database files (FoxPro I think) via Samba when the freeze occured. --> 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 Sun Mar 24 07:18:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OFIaf08106 for linux-xfs-outgoing; Sun, 24 Mar 2002 07:18:36 -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 g2OFIVq08079 for ; Sun, 24 Mar 2002 07:18: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 g2OGTGkw005199 for ; Sun, 24 Mar 2002 10:29:16 -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 JAA15237; Sun, 24 Mar 2002 09:19: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 JAA91348; Sun, 24 Mar 2002 09:19:34 -0600 (CST) Date: Sun, 24 Mar 2002 09:19:33 -0600 (CST) From: Eric Sandeen X-X-Sender: To: ASANO Masahiro cc: Subject: Re: bomb and force shutdown again In-Reply-To: <20020324195445T.masano@tnes.nec.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Mar 2002, ASANO Masahiro wrote: > Hi, > > > The disk error handling of the recent xfs cvs kernel (20020323, 2.4.18) > > seems broken. > > Additional information: > > CVS 2002-02-24 ok > CVS 2002-03-13 stalled after fs shutdown > CVS 2002-03-23 stalled after fs shutdown Thanks, I'll look at this tomorrow. Narrowing down the dates will help a lot! -Eric From owner-linux-xfs@oss.sgi.com Sun Mar 24 07:35:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OFZTK08476 for linux-xfs-outgoing; Sun, 24 Mar 2002 07:35:29 -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 g2OFZNq08450 for ; Sun, 24 Mar 2002 07:35: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 g2OFbf6G005654 for ; Sun, 24 Mar 2002 07:37:41 -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 JAA19030; Sun, 24 Mar 2002 09:36:26 -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 JAA17341; Sun, 24 Mar 2002 09:36:26 -0600 (CST) Date: Sun, 24 Mar 2002 09:36:26 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Paul Blazejowski cc: Subject: Re: XFS latest changes, sb corruption? In-Reply-To: <20020324075637.4021C5C268@mail.blaze.homeip.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Mar 2002, Paul Blazejowski wrote: > Hi Eric, > > I have a bug i think...i was able to reproduce the sb corruption after > compiling new kernel. > I rerun /sbin/lilo to update the loader and made a quick boot disk using: > dd if=/dev/sda2 of=/dev/fd0 ibs=1440 count=1 (sda2 is the partition with xfs). Oh wait, I probably know what this is. Are you trying to install lilo on your boot partition? (i.e. "boot = /dev/sda2" in lilo.conf) You need to use the mbr (boot = /dev/sda, or whatever disk boots) (or you could install it on your swap partition, or other non-xfs partition). XFS needs block 0 on the disk, but if you try to install lilo there it will overwrite xfs fs structures. http://oss.sgi.com/projects/xfs/faq.html#lilowork -Eric From owner-linux-xfs@oss.sgi.com Sun Mar 24 09:08:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OH8xF09664 for linux-xfs-outgoing; Sun, 24 Mar 2002 09:08:59 -0800 Received: from saiya-jin.flinthills.com (root@saiya-jin.flinthills.com [64.39.192.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2OH8tq09638 for ; Sun, 24 Mar 2002 09:08:55 -0800 Received: from localhost (cappicard@localhost [127.0.0.1]) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -3) with ESMTP id g2OH4paC026507 for ; Sun, 24 Mar 2002 11:04:51 -0600 Date: Sun, 24 Mar 2002 11:04:50 -0600 (CST) From: Derek J Witt To: linux-xfs@oss.sgi.com Subject: Re: 2.4.18-xfs and RML's kernel-preempt (was: XFS latest changes, sb corruption?) 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 Hi! I'm using the 2.4.18-xfs cvs tree. I just used RML's 2.4.18-1 patch and it works like a charm. I applied that patch after applying Shawn Starr's patch10 and i'm having no problems here. One problem I encountered is that if I jump my FSB speed to 75MHz and PCI to 37MHz, I get kernel panics the first time around once the drives get mounted. But, upon shutting the box completely down and powering back up, I'm good to go. I've been running continuously at 564MHz on this celeron for a week and no corruptions. And I have rebooted my box a few times due to OOM. That's a different story. I got a quick question about reading XFS partitions in Windows 2000. Is there such a creature to allow me to do just that? ** Derek J Witt ** * Email: mailto:djw@flinthills.com * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** From owner-linux-xfs@oss.sgi.com Sun Mar 24 09:24:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OHOMn09881 for linux-xfs-outgoing; Sun, 24 Mar 2002 09:24:22 -0800 Received: from mail.blazebox.homeip.net (postfix@pool-141-155-137-69.ny5030.east.verizon.net [141.155.137.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2OHOHq09855 for ; Sun, 24 Mar 2002 09:24:17 -0800 Received: from there (blaze.homeip.net [192.168.0.2]) by mail.blazebox.homeip.net (Postfix) with SMTP id 5F09122998; Sun, 24 Mar 2002 12:25:12 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Paul Blazejowski To: Eric Sandeen Subject: Re: XFS latest changes, sb corruption? Date: Sun, 24 Mar 2002 12:26:26 -0500 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: Cc: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020324172512.5F09122998@mail.blazebox.homeip.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sunday 24 March 2002 10:36 am, you wrote: > Oh wait, I probably know what this is. > > Are you trying to install lilo on your boot partition? > > (i.e. "boot = /dev/sda2" in lilo.conf) > > You need to use the mbr (boot = /dev/sda, or whatever disk boots) > (or you could install it on your swap partition, or other non-xfs > partition). XFS needs block 0 on the disk, but if you try to install lilo > there it will overwrite xfs fs structures. > > http://oss.sgi.com/projects/xfs/faq.html#lilowork Yes, my LILO resides on /dev/sda2 which is the root partition with XFS filesystem.And i've been doing that for past 2 years or so without any problems.My MBR has NTLOADER and to avoid conflicts with it, i choose to use lilo on my / partition. LILO version is 21.7.5 that shipped with Slackware 8.0.It always worked and i knew about the FAQ entry but it never applied in my case until recently.My guess is that there's been either a change in XFS or LILO that don't play together anymore and i get corrupted superblock on my root....Any comments? Paul From owner-linux-xfs@oss.sgi.com Sun Mar 24 10:14:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OIEpK10442 for linux-xfs-outgoing; Sun, 24 Mar 2002 10:14:51 -0800 Received: from s0p7u2 (p509167A5.dip.t-dialin.net [80.145.103.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2OIAFq10392 for ; Sun, 24 Mar 2002 10:10:35 -0800 Message-Id: <200203241810.g2OIAFq10392@oss.sgi.com> From: Fokker-Team-Schorndorf Reply-To: advertise@collectors-edition.com Subject: Aviation CD-Book Release - New series "In Detail" ("Fokker Dr.I - In Detail", "Phylax 1911 - In Detail", "Halberstadt CL.IV - In Detail",...) Date: Sun, 24 Mar 2002 19:12:31 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="38d4dce1-3f31-11d6-8f81-00308441cba8" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format --38d4dce1-3f31-11d6-8f81-00308441cba8 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Deutscher Text am Ende! ******** Dear Aviation Friends, We are happy to announce our new release of a series on aviation books on C= D-Rom. This series is called: "In - Detail" and discusses aspects of early Aviatio= n technology in very close detail. The first two titles are by now released. These are: "Fokker Dr.I - In Detail" http://www.collectors-edition.de/QAU/FokkerDr1indetail.htm "Phylax 1911 - In Detail" http://www.collectors-edition.de/QAU/3-930571-65-X_english.htm Just click on the above links for closer information. Future titles will be for instance: "Halberstadt CL.IV - In Detail" "Munich Fokker D.VII - In Detail" "Bosch Ignition - In Detail" As you can see, we are planning to discuss entire aircraft as well as any d= etail of their equipment, too. We are also looking for authors who want to see their commitment to early a= viation technology published this way. In case of interest, just send a us = a e-mail to: books@fokker-team-schorndorf.de Make sure to place the word "A= UTHOR" in the subject line. The series will be carried on in the future. Make sure to check out our other books at: http://www.collectors-edition.de/f-t-s_buchbestellung_english.htm And to visit our website at: http://www.fokker-team.de Thank you for your time! Achim Engels Fokker-Team-Schorndorf *********** Liebe Luftfahrt-Freunde, Es macht uns stolz Euch =FCber die Ver=F6ffentlichung der ersten beiden B= =FCcher in unserer neuen Reihe von Luftfahrtb=FCchern auf CD-ROM zu inform= ieren. Diese neue Reihe erscheint unter dem Titel "In Detail" und behandelt sehr d= etailiert die Aspekte der Technik in der Luftfahrtgeschichte. Die ersten beiden Titel dieser Reihe sind nun erh=E4ltlich. Diese hei=DFen: "Fokker Dr.I - In Detail" http://www.collectors-edition.de/QAU/FokkerDr1indetaildeutsch.htm "Phylax 1911 - In Detail" http://www.collectors-edition.de/QAU/3-930571-65-X.htm Klicken Sie einfach auf die Links f=FCr weitere Informationen. Derzeit befinden sich in Vorbereitung: "Halberstadt CL.IV - In Detail" "Munich Fokker D.VII - In Detail" Die Serie wird kontinuierlich fortgef=FChrt. Bitte sehen Sie sich auch unsere sonstigen Titel an: http://www.collectors-edition.de/f-t-s_buchbestellung.htm Danke f=FCr Ihre Zeit. Achim Engels Fokker-Team-Schorndorf +++++++++++ Removal instruction: Send blank E-Mail to advertise@collectors-edition.com. make sure to type "R= EMOVE" in subject line. This email is sent to you because your address was linked somewhere on the = net to that topic. If it reached you on error and in case you are upset about this, simply del= ete it --38d4dce1-3f31-11d6-8f81-00308441cba8 Content-Type: application/octet-stream; charset=iso-8859-1; file=3-930571-65-X.JPG Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=3-930571-65-X.JPG /9j/4AAQSkZJRgABAgEASABIAAD/7RKiUGhvdG9zaG9wIDMuMAA4QklNA+0A AAAAABAAR/+0AAIAAgBH/7QAAgACOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklN BAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgA L2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAA AAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////// //////////////////////8D6AAAAAD///////////////////////////// A+gAAAAA/////////////////////////////wPoAAAAAP////////////// //////////////8D6AAAOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJAAAAAADhC SU0ECQAAAAARMgAAAAEAAABWAAAAgAAAAQQAAIIAAAARFgAYAAH/2P/gABBK RklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9z aG9wqCA0LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsR FQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAgABWAwEiAAIRAQMRAf/d AAQABv/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEB AQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZE k1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2 xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYn N0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A8yaxhYJGsKYqqInbxzqU+FjW5eTT iU7fVvcK695DW7nHaxpe72t3OWrn/VXrvTK7bculja8exlOU5tjHih9ga+kZ XplzqmWMsr/TfzP+D3+okhyfTq7t/KmNdfh+JW676m/WFvU2dHNNX7QtqN1e P69ZLqxPva+fS/Nc7+c3qmOgdRf0vK6vX6NmDhO9PItZa07Xbm1sb6f8671H PZ6T9vpvRU53p1+H4penX+7+VafT/q51TqV2NRhCm3IzKnX49HrMa8sYSx+5 r9ux3tf7Hu/wazrGFljmbmv2Et3sO5pjux/57UqUx9Orw/Ep/Tq/d/Eo2Rg5 ePj4+VfU5lOax1mNZ2e1jzTZtj92xv538h6v3fVbrNA6e6yuv0+rODMCxtrX MsJ27fezd6X02/zuz/z4kpyvSr8PxKXp1dx+JU7KjXc+nfW4sJG9jg6sx+5a Pa9qnl4eVhXOx8qs03sO19TvptMB3vb+b7XJUprurYHsAGhmQkmdO9nzSSpT /9Dz/oDHP6109rBuP2mkwPAWMc9x/ktb9JdV/jA65mM6v1fo2BSwUdUsx7Lc hm59mQK66RTVS8H0vQrtb/gmep6vs9T/AAa43Aw7c7LowqdvrZNjaqg8w0ve dlbCYdt3vdtU+o4FvTM6/AyiwX47tlzWHc0OH0mbobu2oqfWrLqh/jMwbzXW aGdPh2bvO1pAuY6ve2z7N9J2zZt3+9cd/i8fbX9YcvpGWyOndRpuo6pXYdga 0Cx1L3O9vp2bnejX/wAeuZ6X0u/qufT0/Daw5F8ioPIaHEAv274LfotR+odA z8DHGVYyu7F9Z+Mb6XCxjb2GLcW3RtlN37nqV/pmfpKfUrSU9H9Q32j6+13Z TfQZjMursDva2mttZx8Wouf+a1grrr3/AM4sPA+qfV8ra22l+J6l7cdgtbtc 4v32W2MY817qcfHrstfb/wAVT/hVSxMMXSWtFxY19jmNAcGsrb6t1jo/Nrr9 9i1ul/V/K6kWDHqZVVZoLHgSRp9Gse9zf+E/mk8QY5ZB2ejya8T6x/VC2qsW DI6BebMFlzG1P+yuH6TAr2XW+tZjUt/479Xx/wBH+kRPq/VUenv+p3V3voZ1 CmzLwbXRGI5zT7N7vofaa3XPyKt9fp+u/Dt/SZlqsYf+LrCqabs8syBW7YXO IIBA3e1tez9Ht/esWti9B+rlVn2emmk2tbvLGsaNGu9NzvYz9/2/TR9I0v8A BHFI608Ji9Fwn9Tb0zKHo3Bxrs2Q4Ata5+5mrWOpft9lv+iV6v6qdK6gKLjn PfdkfZ/WLmy9hv3B3qOssa/fXs/m7P8AA/pf9Gu2d0fogsrxjS2bgdlcSIaN zpkFrEHJ+p3RbYPp11l3tBgMkn83dV6fucnmYO//AEQtECOn/OL5fk/V805+ HQXyzJ9Ug+Hpjckut6r9VDR9ZOhYJe415Yyy0F3Arra87Xbf/RaSZcb2G/b+ qmpV127+L//R4H6uX043XOmZN7xXTRl0W22OMBrK7GW2O/zGrtKPrD0ijqvU cpubQBf1rFyarNHOOLu/XbGFzN1f6F2y36Fv+DXnrANgnwTOceAiq3pOhZ3T cP6/DNN1VHTac2+1lo0rFP6X0vSa0btrt7PTY1i1qet9FwcLKwci2vqFfVes 15eQyprrK68Nl9dzn2FzGtsuyW1bfs1Xv9H+d/0S4ahm+zXgaldL9WelnMym 5Dm7huLMcHjePp3O/wCDpYnRjayU6e66VU63qWcfXxXbsPKx8fLo3v3Mvtbk YjMyy79H6tDN/wBnxK/6PV+gs/wDFruvwcXp4x8d1T7qfQYKwdjtzf0t7dgb 7cr7N+l/7sKk7Ey8bFqx+ntAtsBdTZaN1T3tm19WS9h30vyq2WbLP/VSl0zB vsqFz8W6p7fb6N7ffU1p3NpfZO2+uizf9jyf9CkjXchsX5FOY3LYCA+jMba1 glwfQava9tY/Nvrtto2/6RZ2PZh05lN7LnODKn13B7CHEkUVtawNDt1jfQ33 N/64tj7LfYwwxwDxG9phw3cbXfve9VD0IOcBFweAAz6OhG2vft2bfc1jKkla 9mOLfTkdbtdW7eKqGAETG4l7HRP0+VoW1225eI7T7PQ51tmupeG7cdm393c5 1iy+mYT8brebj1sdsZTSW7uYsNljQz99vsu938hbjKLRrscn5BXD/dj+PqVG /wAXluvY+R/zm+q9W8C/9ft9fXYbCxt3H0/Ta5u3b/okkXrlzH/XT6tVNMvq bnF3lupa5uv9VJRLn//S8yb/ADbfgoHUqUxWPILdH1E+tDmhwxa4cA4frFPB G4f4VFDk4zCWgN+lY6B8T7QvTPq5iVYeGbPaG1NFTCSGiB9P3u9v6Sz2LmOm fUz6xUZdD78esV1O3O/TVO1A9vta/wDeXa0YVrOnMxXtr3ERayxotrM+6xlj Nzd+5yeCBFjlEmWxT4bbbMj1Xeo149gDwarNdW03Bn6tlVM3foMitR6h0Tq9 +U62u1uyCGNNjmlsMa3b7d30rN/9T/hP5tT6Zh1YbmNrHphzmzS17nVMM/8A adlv80137i3rDBKaSvjG7uw4PTOm9Txri64BrNpDWts3BoJa5lDRp/R9r/et W2triC2mwhp1cbG8R9H/ALc2O/62qfVs/IxqJoLWOLoL3a6QS7Y3856yMXLv zLrG5VoeTBazUlrAAz9E57nt3Oc31N+z1v8AhE4AkWg0DWpLtY/TMTHzr8tl d/qXBo3utBH/AAjdu/8Am/oK/SGViIsOp1L50/NVbHyq73Oay1j7GQbGNPub Mxvb+b9FWNU0ykfmJNCtewXiI6POdaYxn1z+rdzZ32DO3+Etpa1JN1w/9lv1 ZPlnf+empJVr9Vlv/9PzB380PgvXxkW+nQ2uNWs3l3AaGN/79tXkJH6EfBeq 4FgsYQRJbVWQPnXx/V2p3X6I6fVtOyXbG+pU/a4hr26T4u9rXtdt/lpU5bX1 gDdLRBDhGgO0cucgEWbHUNgue8uLWuJc6tw+lYHfQdvZY1lf8j99SqxnuLWW vbVaQDc1p3bGj6Tnfuu+inGGmndjjk9RJ00/JuY985FI8bGj8QtrqGXXi1Pu sBLWkAgc6nb3XNUFluduxIFWO5jv0hMuh3udx+dC27c8WzuqYQf5TgmVRZQb F7W89l5L+oXC+6W1gg1VN5A52un9/wDwir5b9z5raapES0wQ35H2rauw+mXk m3CreT3L3qv+xOhTP7Pq76bj3+Sk4x2WcB19V34MOn9Sw8Fpa2i1xcZJaWmd APpT7ludO6jRmtc6trq9kSHxOpP7v9VVa+iYdA/RdPqbEcWu7q3Wy2r2sx2A D/hD/FNJB6fivjEjrp2p53rNdY+tn1dA7/bZGn+jakm6zP8Azp+rp7/rv/nt qSPX6/8AcsPT6f8AdP8A/9TzMCaPkvQOmZgZfSDrvFbI45LP+p+kuArE1gHi NVfd1rLa0D06yAI/O7fNPI0B8Edw91ndSodXfjGyX61yBIJYdJd9DbuVY9SD KzXS7kj3bQyABDfa38//ANWfzi4z9vZf+jr/AOl/5JW+n9Wbfksqy4qqs9os Z2d23793tTQSo8O5ex6Lk++/Wfa38pS6x1y3Ay8fHIDW2VMyXkkHfW9z2Mr3 +70/5qz1P8IgYdNWJvcx73OfAIfEQP3doasbrbDk9ZxqLH7qbm11tbxtrNj/ AFq5/lOda/8A64iRWnVQlYsba29bgOyWdPZlZRYyrJAPTsVgLXemf8Pk2vP8 2/8AwVbK0SvIu3bbdpB1a9kxp9Nrt37qhmZBve5wMe1rQwRAB0ra3T27W+1D yrRXSwmQ+x7nCedrf0e7+q56MtyPxWwugb32H9Vh0PLxsqrI9EvsLMq5+1ry XBj3banPa/3Orf6f6NbLaS0kte7XTUz9yqswfRzbMyltYfawVukEaA+o4mD7 tzlcbvLRuA3RrEx+KcxuN1k/9lH1dPlm/wDnpqSh1hx/5zfV7XUDM1/621JD r9f2J6fT/un/1fNav5tvwUudD3UavoNhTU8aIA8FhQPZtPkmY6JB4KOROh1C C+ss1AlqZPGRqNQoSvR6nonVrsig493ufjgbbP3mn2t3f1YV25uPeWOtYHPq O6t/DmmZ9rlxmNl5GMXejY6sO0dtjWP6wK1cHrrqTOXW3Lq7uOjx/mwmbnek 6AVVvW19Tr2RcHOdEFreD9/0FXyM59zzY+BoA1o4a0fRY1Tprx7N/wCo2MfW S2yq6uxrmuBDYd/afX9FXz0rpJrc5+9rbPZW5uPcQC0/pGt2h36Zn83YnkXr Y1WxmBpUtPJtdUwRl2ttHpODa3V2tsJDi0uruPpFgf8ApmMrf6W5n5/qKng1 3sNGYchjsR8X7zY6RW/bsvfW8bnOyf5p/wDoVbjD2tzGvt3GwZmz0XFpdsOE 6n1AP5t72ek1/wDpE9GL0qrGporuvuray3Drb9ntL3NcBa1lgbVX/wABse36 CNLAfBpdWva76zdB2hxcyzMpc2PcH7GM1b+772P3/wCj96SzuodSJ+sHSbxX te1uQXAEbnbqhV7nf1GpJVruN+/9VV6bHb/un//W876dbiU2Nsy6PtVWxw9K dvuI/Rv5b9ByvZOb0Owu+zdLNLSCB+mJcCWta3XVvss3W79nv+h6ayGWMDQD yB4KQurA5KkiRpqtLsu6l9Xy0el0UVuNhNjjc949Ikn062Od7H1M9nq/4T+c /wCDQTmdHNTWM6c5jxQ9jrHW73G5wb6WTq1jf0T2b9m3/C+l/wAKsz1q/P7k hdX4lSCUf3vxRr2XdU13HtKEWPZ2Md41CKL6vH8E/wBorHBP3JGGI/pCKAZd mwzr/WwCP2hlgGQQ2940cS54+l+e57kXH+sfW8ck0dSyqtxc536R2rnfzjzr 9N/76om3HP0hJ+CiTinxH3pnt1tOP+NSbvcF2GfW36xt1Z1S5pMyd5B9x3O/ znfSULPrT9YXtDX9Xyg0cNba4COPzSsr9V/lFSa/FbwJjxBP5URAnecB/hI0 /dP2MXWtNjHS7SQXapKb7qC+sg6N3bhHiNEkfbF17kd9/wDB4uL/ALhX+D0f /9k4QklNBAYAAAAAAAcAAwEBAAEBAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRv YmUgUGhvdG9zaG9wqCA0LjAA/+4AIUFkb2JlAGQAAAAAAQMAEAMCAwYAAAAA AAAAAAAAAAD/2wCEAAoHBwcIBwoICAoPCggKDxINCgoNEhQQEBIQEBQRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBCwwMFRMVIhgYIhQO Dg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDP/CABEIAWMA8AMBEQACEQEDEQH/xADkAAABBQEBAQAAAAAAAAAA AAAAAQIDBAUGBwgBAQEBAQEBAAAAAAAAAAAAAAABAgMEBRAAAQMDAwQBAwMD AwQDAQAAAQACAxEEBRASBiAhMRMHMDIUQRU2QCIWIyQ0UDUXN2BCJQgRAAIB AgMEBAcKCgYIBAcAAAECAwARIRIEMSITBRBBMkIgUWFxUiMUgZGh0WJygpIz s7HBssJDY3ODJBUwolOTdAZA8OHx0tNENTSEtMTio+NUZJQWEgABAwQBAwQB BQEAAAAAAAAAAREhEDBAMSBQcEJBAiJSEmBhYnLS4v/aAAwDAQECEQMRAAAA 8bkUBQAUAVEBBQAABQABBRAABQajiQQcrkaAoKggqAAAKCgAAEABQBACPUFJ IaLSBCUgCgAAAAoACggAiqQoDgFHwsoFNRKAEVQQAAEUFAUQUBBSJAU2ycxj QWdGSpTiAqF6S1WStQCyVi2aiZi30xVkh+dMuYtAjQHHqVSHoR5VHQ1nQGed lXlEZp9NV8vZrQPf7PEJatfS9ni+blZuLNSydc3xe+MdoQ2A49RrZMIqR2VU TLjzBfpezxaORX6is+Xs0jUt9KSXN8x8/br9T1rvy8K8XqWWanRHpT1nP3jK 9HBljj1Og8tj0M6AzgPLV90s8+jj5r6i1n5gzrs4lxqLnv3L0cfn/wA3Xc6T s9ZizfO+Hbqe3Np01mTNYHLpwfp8+fvDjYAyF1SYYBkxtlcpruZ1a5bblLrO UuxLNNX8yatJMaW5UGbXaZqJZxno4ZusuABQVURVABYs892ue5EbZf59NyOj k2987GpaSe1sNqErLQmseXzPvxydxx6Wc8csChvneWVF81km5dLPLV7eY+e+ tze068tNNLcz5M2tCLK1rY7NaFItRZfn/c5qnr7FZx51YkeSLvp6lWEPxqDN gl9Auc3nei1HRFvK1z2Gbq60b2bz+PZp9fNrOdWqGs3F8R05UevsScaeg048 My3q9TqjC41dMXjv0TpiTLQ65wMq9bS87zWDLrozmeP0ep6+GXXPnbdshPEd zmKevUJRXRRTkTTOkWpy1iS+tQuXZaxQ1I7a0VI6A5sraNubOdUeH1O46/Ol 1hCayS3573OaHqQlIiCCl3l0VOl4dOq1jrZKnTOYXJdImR1YBFq1BA8/1e57 fLVH1JZJXgHScsStIiDUQCfNs43e567bM7GRnTODqTS9FEg4UWlQUON8/wBn t/R8ia4fTqD5/wCk5seojRoIF3nt012XDfWp0nXnX3LJBUkIlpbdOiGGktcZ 5fu9p6fiy6xMguFHhXSYayStZbSAkktzlu/nXaYdhJT6YhXWXL1nCqRK1dLi 9GslVysYnL39P18LLm5ZYtz8vB+s59ZMmajQBJ86mzep4dOvTe1nH1L0uqje kzFiZjt1M3WsbUJZKdl6FHjhub4L0nM0+VliAgWs6lze08++1yg788mt/Gtn pnR75aMGiqyIc2ljV7eZ9xUBRJThrwjrnmaVUsSQAtZt3l07bleyih1wwsRu dGn3wwYMlysaw/N2ztTf1i/2xe1JbFFBTz68J655qnK+zvgAlyt51rZa0N1H U+Lmmt0zGQy1DF4dcTlptu335Xku6l3UWwCVvm14T3zzdridPcaQAGkeLNuA AX620YsMUc3kPL2g9GFzZOemxc6463tznHWOlyfLvxf0YwLXEye01T5al0m3 lvPVnydG+/jEAGlXQpEtDF5XzdqudXvRyg57zcr+s7XTOnqT2T6j0p+Tr4f6 Mc9o4ls9hG8tFi8tQVFw2nu436aBq10iVZeF8vZeepJWEVlbclySlHnU9+Wz 1zW8nTw7vjn9nw+z1mr/AB1XSXz9F3KvPUPt5SakvLVfpna06xKsuYZUtCaq RXmiJdS6l6y/Zo2WSr4uviXp58/s+HWen1tcdVrE8faLcg1nVhvWbXi68n9H jpdM7srRBoggghLYoCgPld5Onivo589tJmrrPo9bXHTtyfydF5bj1lnXN/hv n/Xzd6Mb4AMFHAAF+LIo4ZToreTr4r6eXP2yza3Heamly1q7y2q2blpo8dx9 Jldc3zfAqieXcO1/tmXCPcWsvhu3i3IcLVqLJ4r354GtT56LcdjvFrld7cqU wpCVTA0DdJM3gdS1m7HK974e3MennBuWvRjO47vc7pF4USJK8W788DWp87dZ 0++axqZuVuIAABoHQm34O3jXv42Y9y+Z6OV9XOP0c5pa0Y0lDN9FxZ2lCHR4 v6eeBdT5241d822AAKLGjmzZ1fs0+mamLwu51fDffePph/Q4FWZapewysXos 2ZZbCUjxr088C2bPRRCLXOOwQHLLJ0nDr1GLZ59Kv0PMhwZ2Hj69TFP18ozT zcHboONt4jFlWaURJfG/TzwbZ5slFRIN8moASEkva+Xppdsw9shyxu+Pp0uj fRzbVjnrC656bhqDGq6vksmhE5456eeFdT56ASrDdZr75IgBNFnG+w56d6eY A3lrY8+5vXyfz1hdctrqvPqHNy6jsgrfw3Zrx3vzwtasZ6ATQiys1iDfJEQV ZY0joNAAH89SZQdYWB1vm3r87HqYG86uaStmvMvRzw9WfPRQglc0s1FvlX3x RBXF6NWpZdDNdrK46SZLcw6kh0PHRnTTP1NOSQsS+W+nGNbPnYLNOmhSFWPX Ov04NQFWWHGpx6dPx1pbwuN6PPVneZtR0S7mfm6G8yZr8awuPby/6Hly9ybP RRZpVWaWBQS5r9OEVyIo+V5onRcum7zs+8W9GxVy08bjplXN4zjBxeH75qaS 530o+WmC3VbLQlspDWLcQb5IAF40YuEEsmLp51LLJLYSrTaytZwil0wtsud9 JY6KSrLdKDViHWQzWTNIRb5Q3k2wUHyOVRQFEFCVQK+oqzZ2CyuUUlUQXNW1 ZpRZSo7zi3yh1zRAFUUBQAQWVtjlmz0EWUVZQWUUFlVVlcpNKIqXKXLNYZcs uBFVVdnUue02ej89c30fPi1xklFWVVQUAlUVpZQBVRBXSirKKWA6bIAoiRaP bxw3kAAAAAAAAAAAAAAAAAAAf//aAAgBAgABBQD+nrpX/pNVX+soqaD+roqK nTRU+nVbggR9Q9VekaVReFvCc4LYKB1f6QKqeaAvKjcavbUFAKhKoUCUHuQm TTUdRQ6Cq6k0DnGgeV5G1EUEZUjVVRphQPdg7FijFG9dda6l1EXlbiVUqlEZ CvYvYSg5y3vVSgXBFyDkHFVTfH1HO18Jz1/cUGhbVtW0LaEWBbVtRC2hBhTP t+kU5yqttE91FtJEYai0bnNA0ojpXWi2qiH03LaEWgF6bHQbdwYKmlC/SqOj ih40Og+nX+55og4ky1TGdh4Z5I7vXfSujvIQVVVVQ+iTRVJXhCQlOet5IDlu W6i3IuqgSq6FPPcIKmhQ+i4oJzqk9kAjUdRKBC3BV7u+4aUQGg+gSqJ7qJv9 oAKAVUR10QRPcdI0r1FEody7uWEVJ0ABVAUQqVRK7I0XZVCqA9vjsuyoigj1 FEKQ9vAaqaBNQ0KKAqtqp3LUIO4ZREKipoEeo6E1c89xoTVBtVsKDCFsK2lG MraVtK2lBpW0raVtK2lFp0HjqKd2De6HchEaR+eouARkKa6o6CiU3x1FSHsB 2boTRFR+eh79qJLkBRbXFNbQdBRTfB6tqdHVersIaL1r1r1pradMtE1tUAQa koOQcD0HRvg9ZTXh30XGgJqWiieEHFd01vQUU3weiQlAHSVxAhND0DUvCc6q aRXeE91dGuAQeFvC3hAgoopng9B+5zqCOTvKHJm4oeNRqQqKhVCu67ogoAqh QCjRTvMf2no/+zxUB1HvmJIeWprgQjK0IGqHWaqpQr1HzH9p6D9zvBpSJoJ2 doT/AHTyEIBRigVVVVVVVVVVXSqqqqqKKZ4PQ77iKow0DQSXByaNg7uMcVPp 9lUKoVQqhEhFM8HQaSeUQCgwBBoUsRKZGG9U0lFC+oLgF7GoEHR/koKnQz7T oNJPCBRQ6t4qi0FSPDBUuLIVs2oGok89NEzwdBoRVNbQfQkH94RNE924ws0K j+13lw6meDrXqqvYE6VoTJA7R7A7Sd1AxtSBoVH9siqVVV0OjPB6B00UjaFw 3CAUdrOe8I76PPYCgk81VVXoZ4P0iKqm0tArrOO8Go/uKk87StpW0qh1Z4PS D1ObVR1B1kZURHaUXVQFApPIVDoEdI/tPUD1Ad+h8YchEgANZD3qg4rcQtyJ KAUf2nrBVemqLqIStK3hOlAQnaV7moSAr2BSGpVEUEEUzwfoAodT4qru1bgU 6FpQgNWxGuxyFQS0pxIBKAKdXb/cVCCGn6FUCgeimlE6IFbHBAlA1W1FiMJC 9JXqKLFtoi4Jh7HSioqKi2ratqoqIOQPTVVRW2io4I71ueg56q9DetqDAgjp VVVVVVRKqiVVVVUHKvRRUVFTpr0H61UHoOr9CioqaVQKP9DVF5XsW9bwt4W8 LeF7EZCjIVVM8FUVFtVFtW1bVtW1bSti2LYthWxbFsRjK9ZXrK9ZXrK9ZXqK 9RXqK9RXqKaKD+u//9oACAEDAAEFAP8A5Ef+n7SiKf1QaVsKDaLeVT+kKomi pDQntCa6hCqq0W4I0Ra1GJOFD9elSAKloVaLcEDVPCY5UTwnBU7P8h6k8/VD UGhbQF2XlCNGMraAqNX9iq1EtKFCtoKLQqJ/n6gCGoZ23NRc5VW5bitxW4qq 3KoQcVvCcan6NdGhUVU0IyJ9StxVVVVQ0DSVQjUFAo/TCqVU0ai8lVoieu2Z 2k+7QD6v6NFUaBNTnV1ogiQiURpbD+1/lUqqIj6QCpReU5tE0U1CA1FFRUXZ WoGx3lV1P0QiuzQAiarzpRVVdAFQqiAVsKRnyj0jqAVUwBGriTVfr4+gNLdv +k4d+qnWAndh4B6K9YCYxxt5PuPSEetipUu1K/XSiqqqugdRC/eGvfuOoRQ6 hoR/aBQV0CKqqjSoVQiV2XZHpr9EIGpcijoSj10K2IinUUfoNC/UqqAqqo9L W1QACJQoETXrP0Guog5FyqqqqJ6WImiPdFEIinUUEesgj6LRVAURTSiFVOPU UEdQF20anfQDSmiiIVCqaEIhbStpRGgTkOj9KVTmppCNOsIHXsq6VVVVEp2g TvIR1/Qef0DQiKoimm09fZdkCFUKq7dITvIR1/QeQnHtVO8Nbo7yqKioqKio qKioqKippXR3kI6jwg5eECEe68Bzvrd9Qim6EaDxpuKqmlF1epoTgqKhVNAq qqr0FN0I0H0qaVQBKpRF6rXRvWU3Q6k/Rae2gFA52gTvNSg5HSupTdSOod0R RBhKLSNAaaNCJ1Cd58qgVNa6FN1KI6gahjqGXuNWJ51aigqdJRTdQiqdINEe 6LjTVnh+p7aBAhVCqNKaFN0pqR1NdRPA6GlOFQqU1GgogKKlUe2hTdK60Tm/ TBotyrq0Ki2hFoWzsGoFFN6aIBPYqdQCLCNBGSvWUWFbVtKCqUSqaVQCKboE EOhzKojqbIi0FUIQlIXsFC4KoRpSqaO67JlK0AT/AC3WqBVehzUW9YeVUFEL wqoOW8IyBewLd33INJThQt0DlvW5blvW9ByD6rcEWIinWCq1VWqjVtatgVGr +1VCLyiggqKiAVFtQatqDVt0LQU6JEEfWro36VV5R0oCjCjER9KugBKIom/Q poNAdAgaabQvUCjbowEL1OXrcvS5elyFu4oWqbAAg0BT/eCqrcty3hb1vW8L eF7AvaEJQvaF7QvaF7QvcF7ghO1fkBG4ave1e9q/Kavymr8lq/JavymoXTVM 4Od/Xf/aAAgBAQABBQANLl63L1uQicV6nr1PXpevS9el69Tl6nL1uXrcvW5e py9Tl6nr1PXqevU9ep69T16nr1PXqevU5ep69T16nIggxeVVNOnhEoFEnTwq 9HZVVdaqvQNfKk+9nmqqgaLsQqHSqqiUCq9q9661KqqolVVVVVVVUaVT/ub5 rq0omq3KqP0KqtTSnSFXTsNKp/3N0s+H8ovov/H/ADZXlje2E9hxXkmSiuOG 8stY7TiPJ76O84hyexituFctu4MjxbkOKhx+Mv8AJT3PFORWcv8AgHNSshic hjJKKhVrYXl1FRY3E5LK3DuBczY2PE5GW9u+HcqsoUyCaQGzudsttPEFRP8A ubp8COcM/wDON1c2fKOVYuz5PwT4Qe7/ADP5/c7b8CucM/8APTnfv3w/yt2H z/zbxl17iuJ2jXZDKZG7y2Q4G97+FPc5766fFHFba24fnsNcYPMW1zcWlzxD klnzLjOY+ObnF8k5VnshyTJG1mVvG9jsnkMFJxKZzyQFRP8Aubp8CfyH5cg4 s/knNvltuZxXwl/Nfmj/AB8H4b/xg5v55/kLXOY7gvIoOY8W51Z23HZQFwD+ EH7gFxvExZbMfFXLbm55X808XidNHZRhfHOSvcRyTmHH4uUcf/AfE78JhUGI luH2uCubxwwE88o4/LcNlxMrTcRujmbp8CRv/fvntjxnl8Ise7mfz815Z8Cs ec789MeM7RfA7Hjj3y017efmgXA2Pj4W+GVkmI4nfWHEcZaZHjnEouacsifd w2vKuLOtbpl9nbeXjFt8UcodO35Q42YXtuFwXIXH5XHLyC+x1vl47vlPG7hz sMbGOQcgh9OXbpa8u5RZx3XL+T3kYVlynkePin5jyu5Za8t5PZx3XLeT3kUb 3Rvh5py2GO/5JnslHa3dzZyxcz5q9R8x5fS75Fn7+KTlvI3wwXk0ErOW8vDb XJcwnurrH8vyEeKxebxYkk5AS7jUTpLPF5bHg4jkEcUEmfxQtczkrZsN3Ixc lkEmaau/TXt3X690ChUqK3KY0UBDQS4qwwt5fPtuJxxjHYEMUeHuXpuDsAhj 7QBlrCnWUCONs3J2DtHOkwUzTd4YyNm45aE8rtpLXPtFTRfGXEOMcvi5/isN guQfppw61xWSznPeE8K4fYWPxtx7lmEu7S6s7uGANQoVeYm9tMVjsdc30trx vHW0nHMLbXNxHisVbZDJ2NtaL3wh15yG2gscffi8sw8rJXpt7XA3095ZjaTt CguLW4UuPt5V8jwCDmbfK/8A5/Xyw5rfkPkXx/wbFcZy/CuHZX48XAv5r89/ 9g+A7qUZb5X4+bvnOSw/F+MZzNcLsOO8y+QcVx59vxTitrPi7HAY2THYm2gu bjI/7PIc8urizbcn8fO3MFIeIzezDhxV5cPGYwMboseCFlLsWlhxJjhaRXtz c5j5Pr/nLPPdfAC+XP598m/+q8L/AOiiuAmvNfnv+P8AwNhZo2O5dYZL5d+U r3kuMzkcmdy99zTHi+mxWO/HsMdMJcVw7ISXOQuMkP8AN+X27bq3GM91ncY+ 3eOIwXVtbtIV44HNRH+wFcuuJHw2dsbTHYSzuLK2+Spmzc2Z5WA+Qc1x2LOc ou89eZj5H5BmcTbfJXILXC1WDz0+Eurz5S5Ll4snzPkOStYmyvlxnP8APsxV hDkMpeSZq8kguuR5HE493K8jFjob+6ZccjkuRlH5S4yFvmbV7V7ry8ubbK3k 9qcxdWlvB+QMtDSm5OihkTeyFHD5Khjg5qzyqd0UTo3uYmBrHVJwGIozE483 0zA2NrMhY3c1rcT4q6ssfLaXVvbQ27NoI/S9ddOv7wz2+Tisbizt7m0nuLax mZc5NlNu16aC0NJCDmr5Op/nDPIRRROtuzvXtirF91NBG6eSztmW0NzkLW1n z2AuBLicpZ5+0jYGtB7CtKFU7AKgI9Y2xyD91ZWjUOy7pz2Mb8jzRTczi8lF VQRTRUxgBoBe7FWos7PjtgIYLCcRXE97h8zZ4xn49rPguNtvTlcGxuSzOGgx /wC6Y6WGC+x9w1n4Lopxai29+PNtPe2EagnxtvyC1faut2utQgLIve22DOQy FmP5vu/yaLyQijTWFtX9qYS2Et3ZwC5u2MLG5C9vLOSS2x2ZZasmjg5TPJBi bh1x+Vj22zsjYSF4wbmNvba3kuHfgTub+2s/crjj5vYrHiU7ryLGSW6fjZo7 iCxkijNu+NuTszeW3P2TR8si8k6d9bdvYkrBWrY7XjlvtjeZNjc1dWjrezx0 tzBG+V2QwQv4L3hguJrviM4f/iF1BbYrEXVo2A3MBdNlQ4fu/uhlv2MYcqb4 XN+nSXD0Z7pydcyuaHCnyX/NY/JKJ6IRRsTDJNFCbWDHQiC1zf7uLe35W6N2 Nlx7ocd/yCj4IC/WiM0TZLrI2Vqm5v8AKjs7pt1bagolVXyUa81j8uNU46gV LBQYpm+9tx7b2IANu77J207b7GZQ4/DWuPlxv/IITkSnSALL5j8OM5y4pDkj LnI77JTOsaW8LJHENcVUoFVXevyR/NI/JVrD+Tdn4rgB/wDFkCb8WwAj4zhp j+ARWUtrx+O3uWtDQ1rwQxm7esW6tyU5PrSaqyUDJnync5tx6G2roZBDcxxi G8sHTABUGgVV8j/zOPyVjD/+o6T+72L2L2KScsjjurr2+xexexexYZ9bxycn FXlzHBFkL2SeWCA3EdxAxihu/wAWB2Tnulg7Frp4pHEByFV3Tp52Lnznv5ZF 5KxvbJGTvkb18ETJ5I370XmRZD8pzvTOBvXsXsWBdXIOTj2uchZwjJ5Ka6nN oJYrcxwRTzsJmLnGwFu1uONlbwx3mPoLyxUUsUraFCKKnyCxkfLovJWP/wC4 uf8A3Ni9136jeW8GOtNs1nC64u4A1pdIpH/6m9exccdXJPJCnmoLuWsMRIa5 zUWxlSi3CMTNzDBtc1qcx0hjYQ/DXFZhLUOK+QHbuXReXBWP/cC/vjW77i1f Jb2mMt7otkuWmOCPcXxuZJI//UgtbqcyFwdxV1cq+MlTWsrhcYu7kVxxvIPU nEMm9ScLyaHC7lrIuGS7ouEXrTFxDJNUPG8hGbfEXkahtZmgRvALhX5BFOXQ /c5Wf/OMnfCmrrd7ZMbi5rn92yDi10s07Lx1nIRZ4oz3t3cQ2Nvumup8Oy/t bv8Acb2hv7+n596jkL8O/OvU68uiPy7kpl5dBrLu+cPyshuN7ftJvMhT9wyA QvsmR3XyH/L4fucrT/mGTvgZRuiiItr/ACWRs7WW3fYshueOxK4y0l7OyWLH 2WUu55Z8K/8A3vsXsXsKluooWxzskb7FvXsK3q0u7OK2hvMdMJJrUudJbUbN bEtkg29gvkE15fD5Pi2FLsyd8ROWHa2CzdLvZlLj/aWV9Dbz2V62N17kHQu9 iwsn+93rer7K29kLN0+VsBkrDHQWs8d42USQpszXLeuQQvdjuPwmTjcdvdAu incInShzLkF/lfIH8ug+7woRS5Mgrj5gJMdO6fEG7gCdkbEC3ntYYGX8FtGZ KneFhHj858km2Nkz7aTJuubuC9LVxviT+RXt8/GYOzlD7mSW1fAGTB7eR3b4 sVgJp24kXslWoCqoEHdvkD+XQ/d2UJ/1y9MmLHR8gfFjzJU71vW9b1vWEf8A 77euPZFn4jXECzFxc3NlHb4DDX8lxK9rp3PiaA8tETs5h571Yi8nxl8LaBx7 qop+n6c//lsP3KOjZDk7VHK2YX7tZr92s1+7WaGUtCm5G2cYrG7mYMPkSMdi shZz+xZK/ubG2qvj22Y/MX1057WuutlsX77G3a2e9eBd45sc9tewWt1etyFt VlzDI+oVU11Vz/8AlsP3IdlTs9q/XRjqKpB47lqObM1pluK2+9Oc1zZAGycN aGWF5IAN8bxbe1kGL3RW7pi92D2uspLaKQGzgJigijeDVUXhc9/lkPkHt50c 2oeKdDCo5DE/DZOO6ikeQzevYsjjbmGbidwBa3JimeJIZDb+wrNXjLe29i4+ 6uP5FmrzGQXueyUTjyeJwHIbb02OQivYa9+efyuH7qU0Gj2AhzaahA1bZXkl rJbZJl3bb1vW9R7InRzslaxszRLf21gyW4klk3rjjgcbywSOxV/mLe7mfJaW mdxLvXc8Xfvtqhc7cHcrg+5frTSikYaOBGn6g0QNRg5HtvPYt63r2Jly+NOv 7gt9hJ3reuMOrjAQVNHC5mDuoc6LzH4q+NtNZ2d3Pfz2uX51/KYPuVVXSiAq nxhOaQUECQcZcxQXH7vZqLIW0qbZXT2ftt6hi78huFybh+x5RXWOvLWObDZK CHj8UsWJ406Q4zAyPMvHibfkWQP4uazUcjJcxY/n2vNS48lh8oFBDvoF2T46 pzSCqoEgtcCgXMOOzc9q6xzlnckSAJtw9qxj4768t8I9s78RLcwW1kyC5tON OsFJiTiLU8YsBl5MFJcNubB8eMlycLDyuYT5+H7vIA0BVV3KAX6uYCHxFo0r 3bIa1aVgMa/KZmzxeZt7tuPvfRFYZu3dYtyORtXjmAV07kFhPeRZqzuL615C DFLzV8VxNy64xbLDkNxjXSQsZnJGS5SH7j2FxwrIW0U3BcjC5nGb790xnF8l kxDwbMT21xw66tZp8FfR3l9xXI2OPfx+RmGfCCnMLToDRYrLXOKyFly3MWVr /n/IyZ+aZ6d+P5xm7Btp8j5GFkvyNkbmKTn08kI+S8i0RfI19bvf8o5xrbjn eYngku55HSkmSL7uxT+bX5mvubXt9EOS3z8jByjLQNtuc5a1tb3kF3dvHLb+ O8u+XZK6b/kU37SEWtKfBVFrm61KDyhKFuBX9pQAW1bVSiAav7VvAUh3Pi8/ qhqNPK8aipQKLQU62Y5SWr2ItI0oEFUhB5XsK9rl7XL2PVXFNieS9hY6H7hR FAKmnhBHSioguy8kEBVRa0j8eJydZtTrNy/Fkr+LIELSUr8OVNsnJtkwKO3j CDGgXgAuWODSJWr3NXuavexe9q97F+Q1fkNXvYvyY1+TGvyo6/lRr8uOn5Ma /KiQvIwheRgC9iCN5EvzIqfmRI30K/cGL8+BC/iC/PiTcjbg3UrZZ/67/9oA CAECAgY/AO10D5scXwHH5PVhRaJh7NmlIPE8DRr3G/xIXE+tNWkwdZDVYdR8 xOssg2a4/wCiJ6a92EHy90lRr+zd2CcCLrXWQ3SCMtxiLOq6NGuK1TmijJSL cWU5/wAqK9GyVHIGUfyo646V1R0P35MMSbtJfakkDqSOmW4+PJHBhMd6NYbG ew+M3GaMlpMPebObNIJ0TRlo4yHifkaEfE1T1ps2byYI7P8A/9oACAEDAgY/ AO17dBjIariCY2jZJr3HnTftPsSRhOpHyPqTY2SmCyITzjEejWFXOUVc1Rf7 YEj3FFvut5Rb7XlRU+X/AH/gVE+N577D9Ma7K909m+xUXIw3zXGtzhvdboG+ oSRSeEUZatSMKeWjRq+17eHHQI6TNNC43rTS09Typ5Cqmf8A/9oACAEBAQY/ AMOnqrqrqrqrqrqrqrq6OquququququququququququququququrosdtH/SP L4FqP+vVR8G3hbP9CPhC3+kHp42i5ZNqYsN+EBwLjMM2RjlOU96v+yav+7/2 0dNrdPJpp12xSqUa2y+Vu7hQm5fy6bVRkBs0OV7BuznCnMma3fri6vlU+niv biTBY1v4s0jKtcbQ8sm1MWG/CFkAuMwzZGbK2U96jNruWTaaIX35gEBsMxy5 2GY5R2VqPU6XlOon08ozRyxqGVh5GU1x+Zcvl0kXU0wCXxC7ik5n7S9ivZ9B CdRPhaNCMxubDKGIzt8lajh1nL5NNLIC0aTFYywG1hxGXCv+yav+7/20ItfA 2nlJI4blcwK2zKyqWZDvd/p1M2nhaSLRx8bVMuxIyyxZ2+m69B03LtM+q1Fs 3CjsWIHoqTvfRou/JdUqKLsxSwAG0kk17BHCX1mHqgyEm+XLlbNkbNnXstTa jWcqn08C7ZJQEXZe2Z2GOFXq6ISD4quYzSmRCoYXW/WPJ0np5ogJCHSKSt8C RItjb6TVynU6WV4NRFpC0csbFWU8V9jLUk+ujRZzoRrYZQoYxSCNdT6pm3gj FeG+9vx0wBIV9HLmAOBs0Vs1chS5yMdUxW+BI9mCm3kzNXNEBIQ6RWKjAEiV bEr9KuVoSSg0jEKTgCZGuQPHurQ5VqZMvLeaHJY9ldTa0EnyeJ9g3z489Qc/ 06FpuXer1IB/6eQ9vL+pl9HuSPn7FHm2pVv5dyYDXatxhcoR7Lplk7smr1PD hT94/wCjrUcy1zcTV6pzJK3Vc91R3UQbqVyRnYsx0cV2Juez4zTOxLO5JZji SSblmJ2novU/t0SvLzm51UR7XAZcunhktvJmhk4+X/8AIrWcp1OMukkKZrWD LbNFIP2kTJJUWr0rmLUwOskMg2q6nMrD3aE8igyOjabmWmBIyuRkkFxl3Jo2 4keXuP6darR6gsnINMvtcnMQAQukJ3Qovv6vP/DRxduWb1n2Ve0Sh10cA4Wg 0rsX4MIwRSx+0lbLmmmbfkerZaGYG3krRaTTFRzJJHacBSGAPZzNb86rMxIG zE4e/wBJ6eZ/4MfepXLJOf6zVQoumP8AD6WBZC6cR/07ypwt79RJUnJeS6Nt JoZl4c8stg5jVhlihSM5Y43Rcsmbuero/wCDm/Kirk387GsP/ieB7EYh/wDb 8Ti+0A/IyZK1/wDJhrxP7KOJ7YYSuTiL2PZwGz5q5Z/gz969B0Yq6kFWU2II xDA+Sll1saSTgNpeZQsAUZgLMxXZk1EZWTLl+RTf5S0EhkihmbV66UixeSQf wURvtXS6Jk7O7x9RN9CuSf4OL8mj0afR6h+Fohmm101icmnhUzah939WmRP1 rpXMtLqozFBzf1uljAJSJtOhWKBNmVF0ScPs/wDTR1pP8wQrZpLaXW22Gwza eVvczxf3VbMahTSoZYNWOFq4QQo4ahpDNmfcX2b7bN/Z8SjDA95RbU6GRWOR mAumYXVWWWNsqs32efiU0UoyyRsVkU7QymzKfmmr2opBC0rgFiqAsQqjMzm2 xVpl0unabLbMVGAzHKmZjurnbsenTRRQPJKgYugUllC9suvdyd7NUjQQs4iU ySsoJCoNrue6tG2A6r0yNtFr+9080kCkxrpVUvbAMZFIUtszNlauVyFSIzpW UORgWEjEqG2ZlzL0O6qSqaObOwFwt2itmPVeuRSZTw1OqVnsbAsNOVUtszNl auaSBSY10iqXtuhjIpVS3pHK1crlKkRnSMocjdLCRiVDelvL0cxcqQj6zcYj A2ijvlPXauZllKhxAyEi2YcCJcy+kuZWWscBXJUdSrjRxXVgQez4jTI0bK6k hlIIIINipHdtXOP8ya+L2cywrpOWpMLM/tEiQ6qdUfKy/wAMZEh+fLJ9n225 5py+k1fNdQmm02pW6SLpo1aeV0Y9zVSrGmZe5D28klJIecap8jB8rysVNjmy uL7yNTJGbQcz0weJmHZZgJImII/RyZaPLTA/t6yGA6ZRdzIDlyKvzqXkcoX+ Za2NJ+YzKcVjYnh6CJh2o8ycTUv+lkyJ2I6f/L2oJYwI02jfb6u44kR+Y750 /u6//oNGnq2Kpr0HUx3I9Rt727E+Ve3v1hiD11zHSCVhA+g1MjxA7rMiBVc/ NzVLyELIut1Wohn0s8a5wGTdKyhbOkaLnl4ncrnqaWW+jk0uoLKhBR2ijSLj buDd/ernulEh9m9heThX3cxIUvb5tYWPirURejk+FFPTwtHzTUaaMW3IX4a4 DKMEt3RRi1nNNRqIjcZJn4i4jKbB7909Ah0HMp9LGAFywvkBC9kNktmy371c PU831M8d75JXzrcdeV8wrhaTmmo08QsMkL8MYDKMEtfdFGLWc01GoiNxkmfi DEZTYPfLumlkQ5WQhlPiIxFCODnGqijW+WOOQqoubmyLZaMfMdfNq0IsRM2c 2BzWDNvLvb1cbSyGKWxXMADgdo3ga/75rQv7Zq/71rD55mpYdfzHUamJXWRY 5XLKHXsPlb0a4MnNNQ8VgOEz5ksNgyHd3aEsDFJFvZhicQQdvnpVXm2rVQN0 CRgLDDCm1cGq1b6p1CNOpOcqOyrS9rL9KsvMdY0yMALamQMQL5suO+u9Tez8 2GhVz6wQMczDzqv9WmB/zLqTGwwB4huOu47NMy8yVme5JaNhixxphoOaJFmu Hy3QsDtu1vJU8UTq8M5zTRwyWz/Pylc3zOxTiJZ9IrXDmPC4OGLW7NPHp9XJ Er3MijdzZjds2G982sRh4+qtQ42HJ92nh36dtWrCszVYVhWFWhQuAtyRsHnP ZoHVagBuuOEZmx+Wd2lMGjDZRZZtQczYdahrr9VaHG1Fl60jFhQLKXI2lia3 YEHltercNfeFYxr7wrGJT7lXVcnmNFoZm8qtitfxWkjnX01GU/WSv4WR4H/s 5N5b+LNWqgky504d8nZxjRsPfo9GvXXaSWCXQcECSGdrPxRJfMjq2Vs0Pdbv 1q+Sct0jINLwv4mSZpHbPGk7blljVfW5fodGOHRoeVcx0jTx62dYTNHK0ToG GUZQAyNlbf3lrS6z2DVa72mYw5PbDDl3WkzZuBNm7NPzX/KGtmg1SNkfl+ts yo4AvE00ah1zj1qS+uTufMm0WpjMWq07tFLGdqspysKDNtrzVoeZzrkh5i0o 0qEEMUh4eab9m7S+r+ZQihBaTaFxxHn7K5aV5C2pkwtEuKX8p760RzMLHpAl 4tOh4SF/l8PL2V+VWTTR5oC4UG5JscMHPok1EIrjNmvc32W+OimYFwLlb428 1PrIUMwR+GVvl3hhUWpCheKoYrtsT1VswqRorGYA8Ndtz5hSzai2ckjAWFge i+bCmjhkV8uDKOr3K3kHnFcyiGxeDb3YIjR6Of8A/lP/AHNc0Z1zoDpiy3tc DTwXW49KtFz+U6vTRTGCSWJX47ssqcT2WG6xort2faJOwn93R/zRyDSS8vmh heZVkkZy4hfhTpMHaVf0UnDaLh9HI/8AGRfhrln+MP3Ulc30gI4Mmnjlbx5o 3KJj82d60EegQHXc2hjQg2VTIrNCrs37NVzN+rrlf+W9doDzTUapY/5hrmlk idW1DcGL2OON0iVIm3/XLJnrQaDXmbVck1zqdPw7LIQziL2eeRsq+rZvWvF6 zhf2bvXLtPrtNIsWnjnTRHTusSRYRKqmLvrux5cvoVqNaFvpkDLFp1JRpXSz M2ol/s/kJTaqDTLpdSma5UswbKM36Vnb+tRhlBN1LAg2It/voR6dC6xyxDLf GzFM31c1cv1MTERJKw1CjrRsi/1TWk1IPq9WjQuerMN+M1zvReiw1CDyMA34 VqIHuFl944V46C37KEj3aQMCrEs1rW2sTV6mmJ7Km3nOAp9U17ytu+Yf7alg je2n06gSWtYueoH5Nczvt9Rf/wDXho9HP/8Ayn/ua5v+4/8ATQVyrz6H7k1N /g9b9/P0cj/xkX4a5Z/jD909cy55LuwyBdJB4mynizts7nql7X9pXLtSJgOX aUvodPKcFZ3jmjLjDsS6mXhp/eVotRy1kGk1MWVHbTaeUpNE1z6+eKWVdx0d d5P1ffrk+s/zDqm1MUWoX2I5Y4y7GSLisnCSP1CsiLxG+0/R1y8NiicW6jEk tw8PgqWdnePSgG8MeBcKLY/k1qHVVQesCouwWXx96podQgj1MAcMg2FbrkdP o1rOXSH9Jp5Ib/s4sw/OqPTtskWQX8R3LVpodVIRLpyrLInpL56mmCeuljMb t4xbZUsWojaPfuhYWuNnQw6wopQPFX4ah0cZsZHBbzDs/DUcUK3eNLKNl2t/ xUTqsdTMxklIxsWPZ9yuZyKQReEXHyYIl/FR6JIuT6fR6bjZeO/CZ2coMqF2 kkb0m3V3N+m13MNLpW1rlDLPHG6M4jGVUkCyZGXJuNucTJ36PJ9dFpDoLKI4 0gyGPJ9k0JD+raPsrS8hih0f8qERhOnaC4ZGvxM5z5meRmZ3f+06I9bpNNp5 NZC/EhnnRnZGtl3FzrH8rejoQcy0/L9ZAjZ1jn0qyKGtbMFZu1jXsM2pEHLg uQaDSosGnC7u7wogM65lzesZ6VYr8S4yFTY3vhlI7NJBzBNPrgqZDPKhLSML ZcyhsknDt6yTJvvS805g5Mi5eCAAoUIfV5EXdVE7lCJsoa1uMBveW2O7cUTp YE1UaG7q97qh7ZTKd70stHWaBYtVDJaRkkBuEIs4iCFeyO41Rc55Yscss4CT sy3Yxk3bJiqpvdqtLz2OKNtVCVVt3BrdhnUNvZajaZV2ZgQtiL9VajVzTMoV R7MEYizeatPo5pXiC6biyFDlYt1X96tFp+MyyyytE8oxay+WtanE4smmdUjd sTvHvU3HlMrEKSSALX81CtuFDOitbEXANYbKt1VzKKJQqDg2A8sETH4TR8PL 46FYUdRKpVWF8+ywPdQ/2j/1KDuuXTRWCL1G3dHyaCr1C1T6JJA00YyyoCQb Hxf/AA0OW6sl9JIbaOZsdv6GQmpFht7BLdyhPZc+gPRaskKBEuTYbLmsResK zzaSSeCI+pVezf0zS686eQxzQZLKtyreibVy7UzRNlilaSUWuRm8da7VqG4c syugIIJVaaVL5boMfGBjQFYEEHaCKwW3mrHCsT7tczt+o/8ATw/0GY7OgEKH VCLqdjEnBai0MBui7WGz5TWpI41wUVFDqH4bzYIxBC39Ev3TX815UTHrE32R cM3yl+V+XR0mtQDVJjJEcMQe2lBV7IFh5h0Yg2rHpsRcUfINlPlsF4huLddC +3p89EucqjaTstXMZISGjbg5SNmEEQo+bwrVYjZQUDFsB7tY4OcL/K75+j2K 48g9bJjj4uquISAOHJa7ZbkowVc3ymy1qNHqJFaUCDjaUPmdCqtnVWzKs/CZ l9f8+tPopZlm0scGXiSPaS/tRk4TqrYqukb+pX8zWKI6hWF4xMIw1nltl4k2 nXiyxLH6zP8Au6AneOHUqkbzQsxzIbSCbiJnwVZBEvayd/7PPSNHqozFLKsk SI3EJBjCvlC32S1pZZNXGdHkiWeTinGx3o8nurUbrPFKi8FXCPmG7nD4Bscm ZKiEzoWXBgGawXM5fJj2sY6BTLxgsZwY3JObie9uUrjKJSgNmJALC8bA4/vf mU8qzxhTxzmZzvhk9XvE4rUU8bKdG0YdWBzqk0kOW+OZl4Wqb93UZnl40uVS VJuADmz5ZM2/QFo/sr3zH7X0e1VwUyhiLXOK3XKdvo56OQrnANiD15sP/l04 v2iB79azMuQ5Yd39zFj9Kj5vC2dHFI3Y7HyZjglRadB6pLX8y0oXADC1LImm 42jt60obup8YXvLQ1OmlyalOxPHg6HxMPzWpFncSygWdwLAnx5amlido5CVX OjFWsXXDMtmrXvoAuWHSJHquITjhm9UB4l9KuVxR3aJNIz73jJNya0kJOaKT WSbvVYWrXogsgcYDYDRWMgEbAb4381BgVKkBibkWUhnzHD5D1HpMx9na1nBG f1iA9a5e9RihcLkHDAMgbGRTwwjKije7LU8OplEcOUhQjkyCQQ+1KrXi4TR5 Mmbhy1AHJaJckTEG7kuI97Bcq9vv9yhHmBD3SJ9veaPEjeDZu1RbMpQMVLEF RYNws1iPSpyzLmjIVlHjP+6jECA17gnyVrkny8VRCDl2YQRZf6tHzeFerUHO JIznzndj/Pan1BGLnKvmFNksGIOW+y/VQj5vpzGt7DVRXaI+f0KXmGmtxCLG SM4MPlAYGsi2zWvj5KME9shIO6xBupuOqnmi1DafjKEnRDg6jDHCoJeXagae aCPg3bEFD7m3GtKuklT2nSuZMz3CsW7WwVK87I08zZ3yE2v7oo8NgLkHYDiO yd4dV6OSRAuChcqgZQDbufKalnaSIyrlyyZQLWFuwFy7o7NZWdFIa65FUC47 L9ntUJ20uljCqUWZWBcKwyuqpwF3ZO/mket4rhl2ZRfL2Qdwdm1KWILISVtY WJObqHpUGcgkG4uFPXm9H0qszbQAdnVs6qxwrmX7n7iGvc8NE2liBYUsYGVi cxX4F/q1FEBayi/npG5Vl4ytdwbYr4hmrgc40jQvsZsu6fOrfm1/ABBExzWT Zc7Tavon8XhLEzgSOCUQnEgbbCjx5lQjHLe7fVF6Y6DTvLa+8ykLhUc64Zhv DxMMGHhA1zI/sfuIaPhrhfLc+7UEW0FgD5h0MV0ftGlAG9G4Eg8d0NeyyxkS nHgzIQ2G3bhTSae4DC3DJuB82von8XgbaVYQGmkva+wW66aXUxrPJ/05fAL6 ZULlppYtOGjCh2RiSocDIwV2v9GvtVgh2BExa3zsKEUR3Lk4+M7a2+D5K5l+ 5+4io9EGnLZRNIkZa17Z2C3+GiP5q39wP+dX/dG/uB/zqv8AzRv7gf8ANq38 zb+5H/NoyjXs5Nh9kB1g/wBo1LPxy+W+7kA2/SNWBo53DY4WUiw+s1ZrC42G 2PRb5J/F4GFKXuWsQqDaeuiGsh2W8VqEYAKE3bBbn6Vs1BomRUIwMhx+qKU6 jKiNgHBuATszUIEnQzEXEYIv4Nq5j+5+4io9GjP6+L8taPgM4UuVBOUWBPv0 sc+leDOudWZlYW+ifB+g34vAaSQ2UfDTah2KImIseyvi+lQlW7BsbmkHWb3P isL1d1GUnc6yR8mskYyKe6O17poaw34iMQB5Ru71Y+ABmvuFzcDqPkrXNILO RDcWt+hio+bo0f7eL8taNHhi8uUsnlIwFaeLUtlkkS7m2Vc1sLZt5d6sbDzs o/HXDjZM7YC7A/gNQSRxAZUCsjNvbe7kzeKrkDzA3Pgfu2/F0sXnQW2jMCfg pHRc8Ck5Yjhe/eoJMOsEr1bb2oIAAq7BcUb2YkWCbR79HPcscLeSibhZBgAx GNKjzx5sSTmG0m5rDUR/WFf+Ij+uKzROsg8am/4Oi2QWsRs6vFWvRBlUcGwH 7GKj5ujSfto/y1o+eowcQEv8JqBbEuXdb7dha/5FSCcvmgF2yKBcM2HaPd4i VG+kjk4ag8V2cKw+ZloHSyzyvlXtyWAXu9k1GCzXBUHeJpx8o/h6NtW/Vv8A m9BsKEI05WVXYvNjcgk2FKGtceM2q5lX6wq7zxeTfX46BE8VvI6/HRJ1MbY4 WYbPfrIZoz9IGs0boSpGFxjRYhRm6lxpG4ZYKRgQSDY9damVYeAkhXLGNgsM a2dHMD+y+CGKj5qwrS/to/yhRpT4ojb3S4qGJGIkguBKMSd9k+tlNaouJZoH zqZ2IJugU5MT6SUViXhoLixtmJFxVmuLRRj4DSAjvD8NP84/hpRHGTmBKnYD ajGwKspswOBB8VW/VP8Am1hasLe/RIK+6RRsU901g0Z8zVjk9+iG3WBwINx5 qIAPDGwdf1tlEqEFzfE3oYp79C5X36GYr79C9unmH7n7mKj5ujTH9an5Qo1c Gx4TAHyhj8dAkhWveSxucWufq2oRIJBpJHN47EqC65GZiN3tNUV0Lx2ZWCkj HquVpDpzxF4cYkC4jZgPnVC0ylRmF+o3sTanWVhwlIawOJzY2+TWU2AAwthT lM0rsS3ltRlycP1bKGcXGNvEaG9C3j3SPwmtsRbE4KfH56OEPkwPx0BlitY4 gH8N6AMcZxxJ2/hq3CiHi2/HVzDFhh14/DQJgjzDbtH46JXToR5L/HVvZ1GH lpQYFuT5cfhr7BPh+OiOEoxsMDt9+gMi49djb8NXrmH7n7mKj5ujT/tU/KFG lB8Ui/kH8dLKjBRGSQoAsbk9r8qo9TGykI6tqIwoBy3vhlpZNfwzpZGKoykE hW3lzqfRp5FlytcEgDE2xW2UUvDQqFxgVhjc4GST6PZoEnPqJTmPWxJorIwI FiVBvY+ifNX0G/F4GaVwi9ROFB42DKdhHgsZygKtcl3CYH6QoSxBHiYYOsl1 OJ7waktGLA+lej6seO2Y+fx1laPe7W02Hu0PV9Q73+3o5gf2P3MVHzdEB/WJ +UKNMR3Wv76kfm0sUQJSRGYNhhYZsp+tRV8VYWI8YNTOdpFhbGxOFO8ozpwx awBxv4+7TCRA08t3RUxyr3czURmzaoixO0Rg90frK219BvxdI4pLSMNyJcWP /DXtrRxDTRzZHiLlpRYdt1y2VcaVdRKseZ2AGN9viHd+VWbSOJ16zGc1r+O2 yvWjJ87CrqwPm6JJUawbdkHjUY1po12spv5s5ppJN5ioUqpwsDsHnWvVKUUk kI1+oeQ+lRLswIUWU322x+TURzbjA3JFscKvbCtf+5+5io+boi+ev5Q6HT01 w84NBrEkIVx8a3j+HNRDahFIJHavs+aDRzy8UW7C5hf6TLlp4p4heQ3zRsr4 dSmmXRowdv0shBI+bark3J2no+g34q9W2Vxip6rjGx89HVLG3swOL2wVu9Gf mGptQ5uZGOXyKDurRaORoycCVJH4KZ5HZdHHY6nUHFsf0cebvvQ5byvTRxkW uoANvlyHtSSn5VFpmZ2a5PWcDlO2hqtM5ZRiynrA2igw2MLj3aKgjfJw6+qt DHdQ5S+XaMl+0ccKByrkFsxN+8fJXi6MejX/ALn7mKj5uiP56/h6AwOIqXSR plLMGR73t1vh+T4f0G/F0azl0hymRXKXN8Sp7PRDpYBmmmcRxr42Y2FRaPT2 LRjebreU9t2+l/UpioLuWzM5NgTtxPyaYI6iUIql7YXJuxWjDmuGTZ5VG33a aIbFYgea+FLquNlhJEar3VbrZvn1EjjiadyEaN7YBsFZCdmNAsguNlbcOi9Y ba1/7n7mKj5qvSsdgIPvGr5j7x+Ku2fqn4q7Z+qfirtn6p+Ku2fqn4qwc/VP xVYMb+Y0HjUMp2HMPjoERixNu2vx1x9RGFiylbhlbE7MFPQ2r0q5po+vxA4Z iO9l6H1klraRLpf033R9Vc1XvsG75zTNPYA2CqLe7e9PawxFyfEB1VkQFjlZ mYm9zUwGwMR72FGOVQVD5hfrtY/1ahdoPZ9NBLnea3bYHsLYb2Zu1Vi+UkkD N1220ERwWIuAOsdFujX/ALn7mKj5v6EMPcr2eU7rndPiNAN2SMbUUJviLHxj oKsLqwsQdhBp1GAViLeY1M/ekltfzC1KC2VRiSfJhjQlXfU9n8Fxfs05jGZi SVufLbbU+s1BBKjLcbDl3m+HdpnbaxJPu1mtvZ2F/eoBlBANwtuugSgwvb3d tFkFmOF6xryVhhWv/dfcxUfN/Q40GXq2+/QDG8q229dG3ZLe90ySKpeFmLB1 xsDjvCuGT2ZcR57GkWUXU7AfGDRijsWQdWwXwoaaO9xuhzYY9eFR6CI9QL28 Xl+ed7ov+sb8VBtPAXzWvMcUUk2sw241JwNIrx6eJZJ5HJUHMuYiL5tQjTwt NJLFxylwMqVBKqs76i/DiWxOHavXEjuMSrKdoI6jWFa7919zHR83gXq48LOh t1X8VXJHFW2YDYflL4DSRqFdrFrYXIpWvYnFT4jSqqqMd4jrvTEES6ltg/4v k00sjFnc3Ynx9F/1j/m0VjUsTImAFzbNTcunkOl0aALM5BzSW2ovopUzgrHA NDaDqBGXDLXJhLugxSvc4Yktap5R2Xncr5qvWvI2eq+5jo+bpv0eesPBtWS+ 6UY2PueDYdnxVlDkL4rmr3x6fLxX/No4i1G6KzWwuAcfdqdeYaaJpNM+VBlG A93zUmknVWeMZkRTlZV2buXHLScphjMdo+JGcMpANjaodPKR7JqVIja2IkXH Lf5QrXfuvuo6Pm8LGsPB4khsuUjx4m1ds/VNbj+e4It79K6BWRsQwZSPw12R 9YVcItvnL8dZljUj569Xu19mv11+OjJMFCghSFYMbsbDdWnnljVYowWY512D yXoFxYuxkXHusFy1dzduJJtN+8a5hG7FsmpawJvYEXArmemJ3WJZPcN/zq0G qHYmzaeT3RmT+sK0mviQvJp5AHVRcmN919n1qCI2SdGEkMnosuNawvYvaLMR svwY70fNWHh4bfAwqxq6nGrXOTvDqI81BXYRSYZbkZTTAbOorj7tXUXF95th qOCWThQnGaU2Uqo2nO9k+Tv9+o4dc5gMg1KotyzfwwnbjyXib1TSaV1y/bZK bRzNEZrzxalS75SYGhjkRAsRb/qF3vu6HL9X6oJp+JGytuegiPKVbhLn9W7s n/HXskLhId+TNO1mWzOsolZF4fq3jbst3461HN1bjRaqQGSJCSVa8kPo5cue CTss9GfRsV1kkKTM0kmZQromZGSKHckzSLk3t9KTjPpwVLPlkc3Th3DyEhcm VPnVHr43GQBhMubMcwlbT3jyr9nu9t6ILgt4r3/BWqlF7Nw9vkjQUfN/RbPA xq/XWj5Us3AbWyCFZSucBm7OZMybuaoY4TP7A06aXUaiWHJwZXkSApJBxn+z efT53SXh+vii3JfV1rjMoWbl8yRPGCgzRuJmXUszSfwyZNK8mTULH6vh+nU6 rFJp7RCSUF1jJjLWBOZhmtNHkZO5N6v7Sm1S80neYMsXDCu7F9TxFVA/F3uK sHrdzv8Af36YM2qJV1jbNJhnkyZLnPlyyM0XrPs/st+k1WsE0bEcGOZ3JsL8 ZogyOw3m3/8AV6tDK87xrJM0iF1TIwjz6mOZn4UsWoZsmZHzyZN+OvYI45db pJIkkR1ZgpQhJgmQuwzxvqEXhfacR/V/aUGjWV0dFdbShiyGwjOXi5ztVU+p WjYBjqJs7ExrlnVU4YjLyF2vx01MeVdyWX0KlfXaySLl8EKzoHk4iurMojyQ rJ3mftflvRMkgXz1O6HMhy2PmRRR81XOwVPNLq9LwNPwg82aUJmng9viUloF 4f8ADsn23DR5n4EeeSog+t0ipKCRM7SxoD7MvMVDNLAls+lf7X7GOT1c8kVa TlMskcWu1YsInEuaOTivpeBKqxM/F40b/YrLHw/W8TJXMDpmhH8uzLKGfB3V J5skLIro/qtHqHzsyRbnb36Oqgkgkh9nGqjOZ1LqRqXVESSJGzMmg1MkckmT Typk4c3rEqXTavXaXTauHTe1nTzDURuyhZJXjjz6YLJJGsLZ97g+hK9cv0UW XUT8zhhn0ixZjcai4iRs6plfd9Z3a1OvndOBppxpjZJ9+QhWYIzQLEvDz5W4 0kWf9DxU4eeLnB1UHskwcKPW5uNGVU6P7LJ7Vlfi9vhcH1nFokeDp+Y6XKNV pm4kLOudQwFg2Q+jXscEkfswnGpWNowwDiSLUZAzb3B42l00nD/UpUjF4C8y hNQ5iBMqqs0SJNj6xUTVz5f/AKaVq5JnjeTWoiaiTIAx4bidXRh2JOMiS7vo VIIpQXlmj1LzSDiScWIkxtne/pP9epEywkSMruGjBxQo8fytx4Y2XPXCmZQt wc0YCNsZbZh3WV2zU8DcMaeRXDwKiBCZHSZ3y23X4kUbbtAxsi2tlARcLCJU y39D2aBl/Z0jwJCjxxxQI2QE8OB+NCh+bJvUFiaFSmCsIwThw8h/d+zwZP2V Sab1Ijk08ekYrGFbhRNxIgrX7Syb2ersxv5TeiTt/wBlHzVY1qJ49JpoZtRA dK7pxr8P2dNAqNmmbiqkEa5I5+JGs/8AEfaUIpdHphCqNGEHGNs2mXlgZWed 2XJpU7K+rkl9bKj1oeZalU1Wp5fFFDCZM9zwGMkMsjxukjSqx3nz+s79awo6 ifXRtFNqFXhvkkLmb7DhRyyS8VvXahJpU/RcOm0enigj03A9niis7CO41KtL GWkZs7LzDVbj54V3MkfqkpiUSKIQPpoIVMjLDHI4llEDzyTTDiNnRs8r+qll jrl2sgh08UvLYtPBD6vPmXSlmiLPM0sqMc7cX2eSDiVKFjhhM3DWQoHdWigW FdPp3g1Ek2meOH2WFt+Hi/2ktTcp9k0/s0+V3IEgPHRnb2xFWQRrqCsnC7HA 4HquDVhWIwrdrEf0Nr+BhtrxUTR8EV+Pox8LEULddeMViOnb0bfA211mtlFT tFHzdONCrdOHTh0bKsKw21+OsR0bprA1bo2XrEWFXJwq97ijhjVrfDTgeT8A o3rrrYa2GthrYa2GthrYferYf9fdrYa2N8Hx1sPwVsPwVYAge5Ww/BWxq2H4 K2N7wq9jf3K2N8FbGv7lYqw9wfHQsrYeQfHXe82Hx1sb3h8dbG94fHWxveFD MrONlrAfnU0iDKrWsPFYW/0//9k= --38d4dce1-3f31-11d6-8f81-00308441cba8 Content-Type: application/octet-stream; charset=iso-8859-1; file=Indetail1.jpg Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=Indetail1.jpg /9j/4AAQSkZJRgABAgEASABIAAD/7RXUUGhvdG9zaG9wIDMuMAA4QklNA+0A AAAAABAAR/+0AAIAAgBH/7QAAgACOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklN BAoAAAAAAAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgA L2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAA AAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////// //////////////////////8D6AAAAAD///////////////////////////// A+gAAAAA/////////////////////////////wPoAAAAAP////////////// //////////////8D6AAAOEJJTQQIAAAAAAAQAAAAAQAAAkAAAAJAAAAAADhC SU0ECQAAAAAUYwAAAAEAAABWAAAAgAAAAQQAAIIAAAAURwAYAAH/2P/gABBK RklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9z aG9wqCA0LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsR FQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAgABWAwEiAAIRAQMRAf/d AAQABv/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEB AQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQh EjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZE k1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2 xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYn N0dXZ3eHl6e3x//aAAwDAQACEQMRAD8AxuhfV7oOV0XGycrH35FjSbH73jQO Ld+0O2/yFYd9Wfq+2ZxANZ1e/Ro/tIn1bJ/YWE0QCWnVxgcn3S72t2/vrTu6 X1DG9bHcwB1DDbcDZXvDPzrXVtsdbs2n8z6Fatwjj4I2I2QN2pOeTjlRlQJG jhu+r/QNduIAGuAe4usIE/mVjf8ApLPzFD/m/wBGFZsfisa2SQ0OeTtB/r/n fmLSDHXWNoxgSXgVVVghu6x5DG+93tZu/mq9/wBNCxsfNqv+wuaDm2XGo0+0 H1Af5ltpIq9n7+/0/U/m0724fuhb7s/3pOa/o3Rg/aMNoB+gNz937zrD7/ax v0UQfV/pBAd9ibqIDNzwXO1/le1v760Ps1tV1rHs2WVuNbgYlrmk7myP3H/+ CIlePus1PucANNdB+b+d/wCdo+1D90fYg5cn7x+1oM+rnQ+LMQbo7PfqfgHJ H6t9DLg1uI3Sd0vfEjtO78389addVl+Q3Hx/ddYQ3dIbLj7GV+o7b/YVi7p+ dQ3Y6ktqqd6dtoc1wa+PoWitz9n0vZvS4Mf7sVDJk34pOHX9W+i2P9NmKC7Q ElzhHi/Zu/6CZ/1e6GcxmNXi6GTYQXu2gfm7t/56lntvqzKv2ZZuywNzao3b vpA3S791zVsejmWdLObkMZXU3azIe1zQG26Od6bZ9b1rd7PTr2pe3j6xCvcy dJF5nL6N0ZnWcHFrx4os9T1q5duMMe5jSd38hqSLl3uPXMGwtIh1gEH3H9G8 bi799JRcMb+UfP26cLLxyr5j8l79eL5n/9DL6K//ALH8aqsF9z64Y0anUn3a T/m/nrqvrRbTX1jKrdjurttdj7stu5znUlhqtqrr+jtr3b3bP53/AAi5boLQ zomHYGhz7QGNBiJnaNxdtatP7Pfg3Oxb6yy5oBcx7gXND/c5z9nt32K5AXGG u0f+9aWQ1KYreW/+M7GRh4bOoUurpbW+nquLX08tEepjRj2ZDme79Zqq3ep9 p/wdv+F/waJkdOcer4+ZjD1qj1RwynivbbXYLWvZSX/9wvTb6m//AEn/ABnp 18uMR+Vk110V7r7XFjGAgTt/Na55az2/mf8AC+rYrbenXVMFmTXta1z6w8Rs DmEtspc9hsbXs2/zLv0qIht6uiDPQ1HS3oLOk4z8+q6wepiXZ97cyxzNtjLN 1hqoe7/uI/8ARtrf/wAL/wALX6cacNpzsuqzCFbqcPIPpPDRvex/6vdXVQXe gz03ekx//alYe2thqDay+64ltbfzg0AusdH5rG1+9GZWK4a2N7iJPIn8xrUe E7cSuMfup8VzberYhqprqc++l7qqW7W6OY15a12/az273e5aeVbTgXdduzS2 mvNDqMcPgG60h3pipn0rfT3fT/waxszFsxmvy727acV7qYJbJuDSX1NILt13 pb/TVTfQ9lWUys072manfTbu2/oY/N/4VLhBO+lV/wB1ugSMRtrd/aOHZ2M/ DrYenYrMOg5ubi0H7Rs2W+vq64seIrqa/b+lQLG2n6rdQD6HTV1JreJB2Npr ssDm+11bbd9frN9ixydz3tMENgv00Pf0267dqo22i39I5gM+2to09vhI/Ne7 6aRGgF9bUJCya3HC1sxzf2vgEuG0GwAmNs7H+wfyd/6NJVclxObhmRIc/tp/ Nu9sfuJKLr/h/wDcMtCv+p1/z3//0c/6t/8AI+FoC47WsDjAmZl272sYz6S6 7JycA9V6pc2zGt9S7BdS95qe0t3sqzfSL930MZr/AFtq4zooLuhYrJnewwPC D7nO/k6K/VR+bWzaYgkDUD8539exXYQuET/VH/cyaU51OYq/Uf8Auo/906OG zFZ9Zt9RazFpzJqLXD0vTBc9rmPn09jGe9aW/p9FGbXlOrsqzc9lsMIfFTbW vfkfot+3dX7K/wDDLOYwVgaDXT+MD+SnHt9z43fmMOkSY3/yf5KcY317f81Y JV06n/nel1RZjV52TsFFdrsfKZVdW+t7XhzvUxGO9jKKXMY7062P976/55Dd jUfYYDqHXBuK8bCydXP+1c/pd1jP6Tv/AEf/AAap04eTYGubWYfJZ4GZBf8A 9FUcujqGW2luLVaxtd/DmOZ6rmHZvtefoYf5/wC/am0O6/iJ3G9/851uqOxH YGRU30tlfUvWxq63NJDPR2V3V1s3e11nsq9qw8s2us2Vhohu4unTn85zP/BF YtrzWtFgqe6S33gSf0g/R2P2f4Sxn5v5n82qDm5bS1hou97D+jYwtgufsZqB +e72ep/pvU2IigKu1psm6pFbdtLhEMrMVt4Lj9Hcdv0W7/8APWbfd9JpIBbp poCT9KP5LVeuxs0vcx1Dw+RLQ0kgENslrW+6xjKLGe7/AIRUrcXKkkYlza2D eXmt0BoG7dxt9NrUrUAezQyHH7ViOjXe/Tv9B3/SSTZG37RiwR9N86aTsPt/ 8ySUXX/D/wC5Zun+B/3T/9LO+r1XqdGxABuds0bMAan6f+at2qhrKxuJgauP 7x/OKyfq5bj4n1Xpzrg706mF1rmjcdHemxrW/NFd9bejeF4jj9EY/wCqV6BA hGz+iGlLHKU5mMSfUdnUAlvqOEN592mg1l39VN7bHBwkmQWhvOv0dyzB9auj vaWzeYH51epj3eK1enh3UcL7b0sBzrC2tptO0t3PNXub7v5t+72JGcR1V7Mx +iWOVdY1hx2WuY4jV0wBIP6Osf6Tb+k/4NVn5uf9mrDrHetGymoPO0D8w/m/ RarWd0y7Etrtu2EubFbWuLmkO91n5rfpu/nVWsxchtr63FhtqG60ydpGj9gd 9La1NM40ToSmMJGQBsAkBrOdktY5gNr/AE4dYK98SNWw1v8A4ExiBkWUtyBY 7H6loXbhcSwbIe6llZZsd7ck03W/8JX+rrf6a2zJtuoNteLsYLGWyS0uJ2Br p9P/AKp6l1KjMYdxuZfW6yGsa4vhmm2zd+kf/Y/6ai943XD+LY+6x/zn/Nec JxDtc2vqtri8b2AkOFbZY2lr2+1/rbvzfoIFzbKMZ++nqlYcx7WmwubSBDm0 +tOz9C1np+ozd71v1dSy8R9Nll+PW9pdYTkPDGHYdr27XHd6vu9jG/ziu9W6 jfmdDyach1L2Ws2D7K8vY9rgx/qh7nen7p/wX+kREySPSaJriKJYOEE8V12D 5pfs9XG1hu9/u/62f+ikreS2j9p4bf8ABeq9s9p2ub/1SSPX/D/7ljvT/qf/ AHT/AP/Tb6q2YVX1VxbuosFuExrzcxzBaCNxGtLv5z37FZst/wAW1+hxKa55 Ix7aT/nUFZ/QxS76k1faHFlIreXkCf8ACd/5P7yzKum05eZktZ+jqp+k+ok7 rN0RW1zvYzapztDUj0BigQDkvT1Eu1b0H/F/kNjD6k7Ce4Efzj3N1/ery6tu 3/ri2eidPtxWM+z5tPVhXtDbKHsD9J91jG2P/Sf565F3QrazuqzGOBIG1wkw fGf++ItfS3Q9xrxcyyvaS1puqsaHby17Nm5n+CQ3/SBXGUT1J/l/Wen65nWf aqMW9nphjttb3AtDgfSc6Pbtdtjb9FVn5ld2X1FzSGA1uBbMjcPSZ7ONyB0j G6tk4Fd+M/KZXZuAqfltc0bXuqfW7GzK7q/Zsd/OK8/pvU66rjZjVutsZsrs NlNbR+4600bW+2PzKEqO1JrW7auFlZ4sDsNjTZqG497iyuzQt9/pNss9s7/Z /o9ih1tvWLs8m8fZ6slhbQB7Bul+x7qTsyN9jB+kdaj14nXOkZWLk2Y+M41v L2tGTq72lr/d6H7j1Lqeb1PqV1VxxKaCzt9q9TTT/gK/cm8Outefptecg6X9 knPo+rtufUQcmqm+kNc9z/0o2kPfZb6LdvsZt/Sf2FSxvT/5uWVssDw59oZZ UNDJDdzZ+h6jf0nuV5vS3nqTuo3YzbrXVua6t+SPSeSAyveG0C309n0qPU9H 1P0n/BrKy721F3TaMf7O8OfuDHFwDph9297fc39z+QpY3pES4oj1V+7KXzse ScRE7iwehcjLaP2lgMLQGRZDZMH2u1/z/wA9JFzHkdX6e9zYaW2hvOrdjmb/ AOqkl1/w/wDuWDp/1P8A7t//1KvSse7I/wAX7aaGF9tlbg0MBLj+l/NDfcqW Jh9YxMayr0i+t2janVuY+XFocJsaPUZsr3MrWt9U8ttP1Zw2SGlrHue52ga3 c4yU2bmC24Us/nHGT+8wEDa3+TkW/wDgNatxgJQjf7oassvCZxoH1E6uVi52 bTY3djuf6RLiNpG0AbXRY9236H766NuR00U+o2x5dkbLSyyxtbxIs9ljXvZt 27voLKtY1rG1t2uEzrw5wP0nf8BT/wCCvVPIAIjlxMl06mfp/wDqT/MS9mPd Yctn5QHuuj24zsOoUFv57tjXh2pe9z3bh7fc4/mrRcPVBY4DaWwQuf6J0nLy OhYmZh2h5IsBx7AB9Cy2uaLGe5m7Z9D9IrVfU7MRzas0nHdwBb9A+TbENtN6 7fwbMdYg9wGp1zJf9rZjPM/Zqw2RzLv0jg797b7FRbbZ2O5E6pi5VV9uVYN9 Vzy/1WSWjefaH/uf1v5tNXhvrDbL4az8+Tx/5NyhO7KNklV0yXAtA/O5ErJN Rszcw9nWuhg5Ovue55/6n9xarsgH21jaBwe//mKqudFzmsMS6XOcNIPgn4dz 5MHM/KPNwuoMj6xdKG4Sa7ju7TttSUuosr/5ydKZI2Cq6T2+jaUk6tf8P/uG O9P+p/8Adv8A/9XH6Xc5nQcGsaEtJYQdQ7cf0rm/R/Rf4L/hPerlNRrr3kOa 4ujYNHSdXV7v9M//AAtiodFY09MxXADeawdxOjWt/wAIW/yPzGfnq1c9wa2t oczdIaSdeJe7+v8AnWv/ADFdx/JH+6Gjk+eX94osmwiA2SG9x8Ybp+4z6NP+ eqxc8+7idGjyVotA5BLncA6kCNv9nc0JmVNdwC4u0AAn+t7v3U5Y6PQ/rd1D 6uvZTnY9l3RLjuosDSDX/pX4dpHp31epv9XG3+p6n82hZn1sGJ1zOrxnM6r0 K6wW1UuOrW2sZdb9jueHejtyLLf1W1n2f8z06VVDHuZtc95rEuNYcSwOH5/p T6e93+C/c/n0K7a1rRUxtYLjLiJJn+SozAXbZjzAEQODYAbvZ9JqFmJVn9HN rOn2mHY2TU4NE/TFe7+b5+nRbkYNiB1fBbTsvpDm1Alr6ifayfoPqb+Y130d n0Fzw6X197vR2ZTdPT1dY4AN/wAH7XH6P52z9HWt3G6bRWxtNbc6xxbuFjax YP6vue73796aYXqZJGcj9A/a0je1phzh4cp74YCfzp0BMfyv7KvtxGmLG1ZJ EA+1jXASfe76Xk/83/jFRzsEPqnbnMdte7aaWMa0s959W9727anbXb3u/wAG nQiIEm7vRZlmcgAEarXd53Ntn6w9OeW6NZaANZjY/wB3738tJAzbP8sdOs3H Vlp3EGPov9zfztiSHX/qn/cI/R/6n/3b/9bJ+r1mPT0zFsurFjdg3scYBAmP o/u/TVu7Nos3ZIxK6+W1+5xMkbGDX8yp36V//DLnMDrPT6MSim65wNbGhzWt Jg/n8x7kcdf6Q5o9R7gQfaA0w0caa+7arcJwEY3IaAdWpOEzKVRNWejuNyMe 54LcKhsuFmQ8PsktJk0Bryf55rf+NTHJqZQ2oU11vc0Vgh7nOcfa42/1nMZ+ k/wf6X/RrKP1i6F6Yrbba0DiWTqf5y5/u/SPcmH1k6M20PbY+ANolhB1+lY4 td/0UeOH7w+1Htz/AHT9jsXBlxNLTtb9KxzT+8N2xv8AWQDU61wrpb6TSIr7 uIb9J7N3/flWZ9augepvsssMSB+j8fpO+l9J6LV9b/q9WXP32l5HauNAPbXu 3fRR44fvBHtz/dLr4OEcWk1stcXmNx3uIE+/84/S/ef+erG4gANJaOwBIkk6 O9qxf+ev1d7GzmSPTiSdTPuQH/XDojnE+raQRqPTif8ApfQS9yH7wR7eT90u u68ukhx2N3Ae4+4+Ij8zd7FSqfc+ZefcS6wSSdvbdu+i3/0Ws/8A51dCjYd+ 2NHbeP5Ozd9BQZ9ZeiiSbLGl59zgyTH5o+l+al7kP3gkYp/ulbPfV+3OmHTZ staDGm7bYyY/d9RJU8rrvT7erYWUCTj44sY4RqGua5o/6tJRccb3/Tv6cLLw Sr5f0K+vE//ZADhCSU0EBgAAAAAABwADAQEAAQEA//4AJ0ZpbGUgd3JpdHRl biBieSBBZG9iZSBQaG90b3Nob3CoIDQuMAD/7gAhQWRvYmUAZAAAAAABAwAQ AwIDBgAAAAAAAAAAAAAAAP/bAIQACgcHBwgHCggICg8KCAoPEg0KCg0SFBAQ EhAQFBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAELDAwV ExUiGBgiFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwM/8IAEQgBXgDtAwERAAIRAQMRAf/EANQAAAICAwEA AAAAAAAAAAAAAAMEAgUAAQYHAQADAQEBAQAAAAAAAAAAAAAAAQIDBAUGEAAB AwMDAwMCBgMBAQEBAAABAAIDEQQFEhMGECEyIDEiFCQwQRVFRgcjNRYzQDQl EQACAQIDBQMGCA0DAgUFAAABAgMAESESBDFBUSITMkJSYXFiciMFgqLC0jND gxQQgZGhscHRkrKTs8OEY3MkUxXi8qPTBiDw4TREEgACAgEEAQQBBQEAAAAA AAAAARAxESAwQCECEiJCUmJQMnKCU5L/2gAMAwEBAhEDEQAAAPKQtovSIMwW x4KIYGmYjYRZiNhoJBg9oxrBxFgYGBIIhg9tUtz0WV+reV3gQlRoWCHaTHgt hoINK0bkYmpJxBgHJIMiAmthFosthVRaReZXX75+b+nw22d+l+V3iEBkgUtC TKJQTQwoDSVY5DPJsZ0aDKJo0EwUqVqV9FKTVa3bioejLhfR4rTO/S/J7lNE sDCF09sCKruXBuQKt7lmRBqQHQQY2QQ8JVgQodEfSeq5tNJ19SjvHB+jxWed +i+V3MXOqkALRYAmxOpJm5Wpp6zuYTamxhABRpWbE0hTTIUNTQbPrMS6CoDn ujPlO/ks879F8rus98rvpxpsNaPDQbFh+n93J5nw9N9rDrOd59pSz1OgKFah wfpfp8XI8m9npPH8e/P6F1jRmei+rweQeb1rbRxfo8lpnfovl9rG0dZ1c9Hz bPawunU5123XhynNtHO7fbKux0vejOKVZNWNzS8m9NFelenx8B53X6H6PHzW OrCfN8fRXi9J9Ti8o83rrNo430eSyzvuvM7LPaOi3x4ni6O17MKyaBD7bqxG nzPJve9GMhla5Xl2sNJhnVDjoKl6b6XJyXD0F3zel0PPsbTPlJr1Tv5fIvO6 1N443v5Hs77vzOuwpQaHncxB2msirkJQyBugzJQ4VJU5CTTUqbluthpTdncJ pyqRDFcVDaescx28tjnfofl9ajeIYZoFgUAs04hxGqDiUaZVTaiIYQCVyTLR RpdgWpAhUxYFpXSOa7+azzv0Ly+s28WAqPDWaE22mui6Miy6Tm20xZpypLFj Fcb5hlrNcbGnRSJoHSEjbKy5wAUltJ57u5bHO/QvL7Oj6McoaainxHJ0WVT2 fXzqxYkSYlDvd86jG2GYEwqoqtx0GJKjSItBaUBTRDTBtHPdvLY536P5XXb9 WT6bGsSa8/8AP67u563s5xzQpJ0qzHS13yVl2OiHLp4e5qk59K+hYMaXaghW wQlqI6TQdvLY536H5fWXSRlNoKFXldm1Z6wKaq4q53xrMdLPXMgRYAAza6SU Us0ViAlWAYo0GiAa0ih7eawzv0HyuyvbblkTkD4MNRAINMCIYiCK3yu0sQWc UBizldhUKtLsEmMA2DELWKHt5rLO++8nuEOSUhvA2KDIgyAGotMtEDnrJZm6 DCSBcIgva3LFSEhWgFBER0jnu3mssr7vye7bCocYUZRBBgAMGKxuWtIXpMCD LTGFrTQU6xmBYUqOWzcwAwU01T6Kn6+axyv0PyO7THxkEVggkBHIh4BWspUK Jg2iotMSQB/WIaSBVFo7QGV0tgVWqq6VH281nlfonk9zDGEHYoxhPGl3MgmD FKoFk1BqADpQDbVc0o3gY0w0qnNoDFBg0mm6+awzv07ye55MrBCiBKBpLtRF Y0kk6W1YwxiW2nPW52xt6Q4heaq40alNS768baswZaeNcPVX1PP9vNb536v5 PdjIsxAqUw0LTGSaa0zLDLi0IAbSD1uWY+ochqauarlcRFuIQ7Wav8b4vz96 S45Tv5rbK/XfK7vKvXyq9J0GgkJhqSPW8ee7dWA+XzK0JDiJTpsRXWVi/eaM XzpSrSkU/l6h9fNclcnwbU7XN9/LcZ36/wCT3L+lyh0SCdU3WN01k1PcY5dW 3YspZddJscXNZ03Nu1qOkrLzyNq0yXTxOPL9RHf5/sSON49dTPG+hy9Bnfr3 ld0/S4y6RKW2JscJdIqCpkBW+ZQYWqRUVnVSuuLWex1dKlN5FC/S2XycadKH M8FqWuP7uXos79g8vt8z9PnqtDYpJEY0lZCthWSHUk1SENOwrkOtSbskdlWN XGvJRo5U1j3t9OHhc9uoiqjg0Fc8P38vRZ3635fbxPocdPq0nptMDCDZkdiL FyIGql1jEli1z+tabcS9NrLlstuRnRippo9HsL8ujVqy6nkubnhu/l6HO/Yf M7OU6uPlOm73CHJyJNJ2yDm7rLtbTTsiSCKIbI81MJ89pAmipYBAgw0ulxup KdzA6xxvfzdDnfsPmdvlvpYKVHX8uNXqmJRCn5uFQymG9u6WrIHBcK1lvUee bZbFIWwIEgmjnuPoUwoycdY879Dl6PO/YvL7vIvUyrNFdZYiYVJyI7DnHqqK ZLq8vY45iGC4VOmfL65xFgEA4FEUKHi2jz6sIBtHmnocvR537L5XfxPdkGlt TVMSA47JT0eSr0N2up2t+aKPBEDitsqG4mKQSDQGaOiq4OhjCygntHmHocvR 537N5fcIK6StarWiKgtRaCCdqwtdF25NubWKfmzp+YdOEBaFIDg6IzQE1eDo PhcB12seZ+jydFnfrfl9yok06pzJUUSjBC0CNq+0nr+kop0nrjZViZVx1yBm CbY0B0lAwcuDcOGhJams+WenxX2d+meT3KWkHKaq0lRbUFgLNBZcbx6/1ZrB yqunjXd53V4UratTZNVw1kYEwlwbjw0Yiq7aPMPT4r7O+/8AK7ajWYS3JNAN pGnoQKJSS3n1Hry62TyHR2ylvPSonS21wbI5ehVkwkLYG8/pnzaCHX7Z+aen xXed9l5nai5cVOIVaVaRsGE5ItR2Kb0Z9OiBo81rTrlHfzmpNPVEQ4tuTUQm D/m9Oc+iFKo2y4L0uS6zvqfO6yoYT2AAWECiAbDTLClLqnl7c0SRIXoCi3U1 jDqq4E2DYRN7j2WytGoR2z4D0eS3zvtfM7IsKkvQsEkTQNvBTAdKIFQcEaAC kKI7MOmQQNpiTYBMEKVOAbnhPR5LjO+z83sIgIlKCAWQI9NERG1tEw2C4BYa 52DMvoZZqkqoUudKEUDSFGk06e54X0OW3zvtPN7HBYKtbdkRtETCxxIqYQmF bojQDZK5s2ryXqaYCdJeKxqAk7W0VU0lU+eelyXGd9/5nZa65osDLADrVS3a NBljkLFLsEEmkxxC6ksCtSEHEBAoKTVPSmwyB6z5v6PHb5323mdarIjYRX2m EOoEzQl27KGpUtjVRILVDLZYcU4sgCFKYgiRoKgo6vbLg/Q5bWL6nzevTDyw C0x4Bii3ETs0YS47GWBpoHRxithsEqmDFREAIKWjI2gOkeb+lyWcV0fB1lkB cuJzAoRCSEqDAzLKNhEGmU9JzDQCBWlsQmgMMkqMoTZU658b2c4mERgYGMxG BgYGBgYzEYGBgYGBgYGBgYzEYGBjMRgAZ//aAAgBAgABBQAmi3Wrdat1q3Gr dat1q3Grcatxq3Grcatxq3Grcatxq3Wrdat1q3Wrdatxq3Grcat1q3Wrcat1 qEjT0m8OlVVAqiqgtXeqCJR7Kq1LsFUKnWqr0J6GtKVUHmpvCqA6U6VQVFSi qu5TTROPcI9lRAIk+gA9CFqotZVCofJTeAC9vQD0CNEeh7qiCqvZVQ6URVU0 AoxpzKGiBUI+Sm8EGEoRORjd0KAJTg4ABBpRB6V606AVW25Frh1a0rdRq87b lSii8lN4KDyuCQGSOaSe+kr2Nx4AFW9ddz5Bp6EEKhKonCiCef8AHDIQbiIA d01yKClPwUJ+Sm8FCPlPRT0rbxqJ5L5Yw104q15dGIT/AJJmFz5XuVuyjYgS Lfs6SUMfK/U5P/8AMe83hauqnTBjnu1OAUvgoD8lN4eyh7vufaqtnqJvzmdq dO4tb2lZACJJZSx88eoW7gWmEg2w+VwPmCu6ePhDGS64kBFoFMPnDAHgjS6T wUXZyl8UHkIvd0B77rqVojI4oSOC3XIvJW65Bxq57nJrnBOcSgg4hbjkZHFU JLXuCLi5NcWoEg7jlVRj5KXxCoh1qhULUj1CIp6Aemjsj0r0AVKoBReam8FE 0OMsYaSEEe6ZQmSFrAIA4IptE5pA6RMa5RMDnSMDTr7HqUAqodIvJTeCtvK5 92xMLBE1zA5R+d17WnvNHV5Y1riwNfcEBbVGPibogia5QCj7gfOg6DpTrRBR eSm8Fb+V0fk3/wAof/NRj5XXtatTZA6W4Lmmri66QZpY/wD8rVQ/+lx5kIdA nIILuu6jHyUvimyFqfISt91GzOAqmv0ozuKdI4oL6h9CSS6ZxAmcAJXUbI5q EhBc8uQQCoqegIlReSl8Sen59KfgBNICcetEKBVPSir0HZUUfkpvBE/gAICq 0laSFUAClTVFpWkruEEF3QBVEOsQ+Sm8Oo9bSAS4U1tXxK1MTnBFwq54KLmp zgnOBQe1D2qEHCmpqPcx+Sn8KKir0oielPSDVEII9uhTY6gMATQEGLRRNaEG rQnCii8lN4dadAqdAEECq1X5oBaXLQUGFaSiCg0oApxcUAVQqhHSPyU3h0oq +ivoNAOkI+YaSmsWgIsCMKMJW25FpCZVVTk894j8lN4UQaUWlaCtJWkrSVpK DSi0otK0lBpVCoR891bi3EHBGULfC3VrBRcvyPcyeUPkpvBReHoCqiV+Y6t9 kOgBK0mm0VslbRCpRGbuHVaBVSN+UR+Sm8FG74klaytxbgQcCnCoK9iCKO6D 2CCBog8rV2DyUZXVqSUGkr26SEVi81N4KNtWli0FaStKou4RBVUR2RQHRoRD USjWgCp39l7n2VeknlF5KbwUfjRU61KqqqgWhUIRX5fmOgPclEnpRNeAiiOk nlD5KbwUZq0VRNFqCqqIhfJHUgSqla1UIAIFVVUSESgVVae5cqolSe8I+Sm8 E1p0s9pXVJCqU0lOJTdVQ4qpA3Ct1bq3UWVO2tlbC+nX04X062F9OE9lCAAv dReSl8VG34uNAR3ARCJ7ElNPQHt6AgK/gTeRqqlQj5KbwUXgi1aU5gKMQKLa Fh71KZX0hM/AmaNbnVQUPkpvCiZO0N+qYjcNX1DV9Q1C4aU6VhQkAO4Uw1Ja VT0M9vXcH5IKLyU3gq9O6CJQ7IKvcKNwDg4FEItRHQD8C48qdIfNTeHQr2BK AQVesQ+RYCquamvDulAgfwLjyRKgPzU3hXoB0CoCqHpRBR+6qnMBVXNTXhyo qoeq48q9IPNTeAFE0UR6digKoqnWHyLeje4oiwFAuagQelfTcn5V6Qeam8B3 6EKnQdD1g86JzU3oQqUWkA9AfRc+YVaqHzUviqdQCvZV9EbqEThfUNW+1fUN X1DVvhbwW8EZ2oXDV9S1fUNX1LVM8OcFpUI+am8ED6Ch0KC9lqVOgCKovZe6 DCRtuQbUaHIRkkMJTIyj2UPkpfGvUe3T8h0qgvb0AVQaU4IEhEuC3HIVKBct bqsc6pe6rqqLyUviqFaSjUoAlEFaCVRUIRBHWlFWvRhIQlIW6nPJW6UJitw1 3SjMShKVulOJKhPzUvimv7F9VufIPohKnOqg/uXdnOqqVTQj3TRRdkXnrXqA qdKKoVVCPmpfH3QRKCp2oqVVEAnEBDuiepp0KPoAQCoqdYj8lL4o9gFWiHfp XoFXpq/ApVU9APQqHyUgq0xuW08kxuW05bbltuW05bbltuW05bbltOW05bTk YnLaetp62nrachE5bTltOW25bTltuW25bblGwh3/AN//2gAIAQMAAQUAAqtD ltuWhy0OWhy0FaHLQ5aCtBWgrSVoK0FaHLQ5aHLQ5aHLQ5aCtDloK0FaHLQV ociwjpH5BV6UR6lBE0VUB0CoqemnUDpUdJT8VH5U6noOg7eoqqr6j0BVKqgV VIfio/In0u6g9K+miA6npREdA5VVFIfio/JFwCLwg8KqCJogQiiQEO6CPoqq 0Wtq1A9aoBEgIPaq1Unio/JS+0IBLmAgKo6ReVQpR8YfGo6VCJVUB0b5SMBE T6oo0Q6M8in+KZ5KTxiqoiaTOT2gNjdURmhaA8yj4xuAaxoUrql5FZe4YzU1 jdITfI+0flOEIy5rRQEpnkpPFM8lJ4w+9FM1SH4xigjAJqWOlILWMDmxPoZR RwkBEx7Q+Kqmn5SPAETO85UfjJJpQ7hnkpPFM8kQCtI66AqVWkLSCtAQaAtD VQIMARAKAAVUQtDUGAKqLQUAAnAFEArQF7J/smeSr6SqIdSh0oqKiotXpp6H +yZ5J7iAxxPSnRxoGSFy3aGvUGp6SOIT3EBrqinWvQnrRP8AZM8lL7Q+xe4O 1kOon+0HvP7Ruo0OcW6iWxVRfVzXnVI8tUh+MXij+BJ7JnkpfaD2d/6Seaf7 Qe85RZRkQBHYCFaqub5zp/jF4hH8B/smeSLQU1gC2xUxAmiLQUImhBgHTaaq IRgHbBJjFS0FbYIa0D8J/smeQ/DPUd+lfTVVQR6v9lH5dKr39VUT0qFTpUKo KBCCPSoRPpf7KPy/BKcO1CtJXcLS5AFAGgaVQoAoNK0lH3oVQqhQBT/ZR+Xo qqdD6K9aodS6h11TitS1IuRctSaU/wBlH5H0U6FH8CoVVUIkIEdQAOlQqjo/ 2TPL1nqFTq/21gJz1uuW4UJAhK1a29JFQJgogOz/AGUfl1qqqqBRK1BAhVVQ qhVT/YRLbRbREIRlbKMa0kIBAdwEPZ/so/JH39BCKaFToUEeg6PIVQhIFvNW 6Cg6qZjG6Xx6XVQ7h/so/JOcah61rUqjo9tUAgEfdBHoERVGMUDal0WlBgRF A00U07GtcaqiHs/2Ufkn+6qqqqBWroCvzIQHWvYOeU3sG0LnUoqEgii1kr8k E/xUfknDvRUVFRUWlUVCu61JpRK/MdHAUTQOlVJZv0tHVvtJ4qPyT3GrXEIu otYVQtLUY0WORB6VVAqLuqdCO1Cmo9BeM0AdQn+yj8k8EFqeVVa1rWsoSFbx VQQWNW2FthbY6VRetxbiEi3FuLcTTUU6P9kzyCc3u40C0qiARCDu+tRur6Si afgR+1ej/ZR+VEfchOYFpRARYgCg0qpTK19L/wABnt0f4qPyRZU7aMZrtrQt taFtrQVpIQcPS739cft0f4qPy6lFD06NSdG5qBKD0DX1npRR+w6SeKj8vSfS 72ZM5qpG9SROb01H8GP2QCkHxUfl0r0qq9D1d7IpkrmoBj0+Bzep6AeiP26S eKj8qo9Ket3t7IoCoIomTOajoensLVVU9MQ7U6SeKj8j0Cqj6Qj0ITOhZ01m iCPoi9iipPZM8vwiOtFTo4OK0laCtsrbK2yhGVtlRtIBVVJ4qPyPrqqfhVot QWsIlBwReKawi8Id1J4pnl+BX1kqqBRAKABWhqNAqNWltHNFA0JtFJ4pnkqh VCBCJVQtQVVVV9RFUWArQmtAW2FtBaOxjC2wttaAgKKTxTPJFqDFo7FtVoQb RaOwag2npoqfh0UnimeXQI/igIekn0v9kzy6E/g0R6gIdD6KI+iQ/FM99bVr atQWsLWFrC1hawtYWsLW1a2rW1awg9q1tW41bjUXtWtqL2rWFrC1hawtYWsJ 7gR/9/8A/9oACAEBAAEFAMViLvKzDgefK/4XOajwnMhDhGZKbwfNuX/E5pHh eXDf+Ly2k8QygH/IZQk8Ny4d/wAfk9Z4jkwf+My2kcQyZaeGZZqHDMuUOE5l w/4nMI8JzATeHZVzhw7KOeOH5QuPDcqCeFZgB3EMo0M4dlJE7h2UavppPq+A kjLPeWxh7QAWvfK90qeXAGaOAyRy3D8kdQggJh2mxumu2wttm3DHNmjlLJSY 4oHBjpZp5w50Qa4hj9RdcSnbhjliaGfStFI1bwukme0SPlkjN5bsgtYs2Lc4 3+RcDoMrG+Uy7he4Tx6P8jU+XafBba7i4dI4/bhzbpkpug+UsZFEZXPndFah RxxhjpfqHRmGsksTDA15bMWwtZEQYxsxTyiE296wCxdDNDeteZoMPGJIzFLF nHPYz+RcGAOSmeGq7kbI21oGulIQg1XF011tDFuvs7qYxNx1zSPfD3y0bLEI miQFimLHtZCY4mteVGzVI6aRr4YntlAijDNQYbEzLJSSW8mO5P8ARstb63vL aO4fPBtSmbMSQsi/kXByBkXUarXG3NyLnGZYlmJzZTG7JmkfcIxOndNgcmwt 0SRW9rfZB91a31pLDEdsRFBhZGwNaNuonm0ss7e6vHNwuUiF3j8pGbWAsa9h YMg+zkZ+lTyOwFhcxRz4fKyNvpDbPyDdb/5FwcgZFwmLuN3D/wBd/sS4nhte OZXL2c9010tzeWVxbRQ3Akl5+0P47LbXGzwSI2uf58wHO6Z9ELZnKa1ubcW9 q6Vs7JTJFbzPn0lrcg97uOcZzF1bX3KsFDbxPs7h0l7hMnLf45tu22eXRycq nlh4w3W11/FGIf5FwcVyLRUccla/lHODiBHye4x7rng2KguDgL28n5Zy/GxY nNc2ZPJg7/8AWePY3hUMh5FynEXeU5Flr6+DuJ4tkONw1rcT2fBpJ/1vMZxu K5BmMgy/yDpHTOyBrxmzJdPyQgYP+u5bx8svJLXGZvIXbbq+uZxGOUBp4w6U tOSjdHD/ACLhIrf3F5VvEIAOQ/2ZHI+ydKRbf13kQLbjEd0/nHL763yue5dd 3VniHxWfK8DxC2uYORZrL3eN5HyrDtu7fiU8U+HvuLZCO74VsMy/K46ZyZ7T ENNzFexu/wCeweInubzlnMsbOODx0k5FI2HMcYwEWagz1ndW99ytkjuLBgJy km4P5FxIPNxbRFjre8vrBkGfy9wLOMytl3Q/IZvkF260ubiKU5rMzQw5jLQw xZjM658nkp1+rZ96bd38Cvcxkrw2E93awXl5d3DZm7kdjPdfqEmUzUgvsjlL mzt7WxtoIcplLCG4vL69ksMnkreRlzdWUh5ByHcmnvbmSeRrYf5FwsON9tGK J72XAkMbEbr/AATXJbE5rjE9sbpNl8ot2PlAjjiaGtaiY4hHdCUQRkqZxUUM gV7E6YQw/TQMzNi59xtRwW7HR2rozNMXzFzG7cU9y6WQyaIruZoNwwsZ/IuD 1/Ub1lRxbC2OWveTYbG4MQRmQXAbHHbtLG4SxtLm95NxvD4iBnG4slYTPMAt 4i05S4IjtMLJZWMjmtUgjhGDscbduwWOtMpe8lmtsNkoMVKbx87pLe5eZjcy AMtmuabmRphij3lM51dOltwTq/kXDCRelrwuGMbFmufRh2btcLh5+PvwGIy/ H5IpVgmPfmefNabLgupt3yTEMk5Fe2GMtMs3CwY3kHMJrS3acVHbYG9xVicH xrF2eUbx0CPOc1x5mz0bmzsuQzTJJKCGREzzNZG1kmjVGJJZWbj5KSXAId/I uGOLb2BrmrhUj5uSc40jJ20ol/r/AI0XDhLJCBiRFFlOcaTZ8Ot3BQ5GG65X yZ+Utcm+6vZMjzVmqRuKNngrsTO4fwwaXcbLrjlnK3vfm2TGZ2Rlk0ut5nMu 3R21nZxySMuZS+OQNhjjLXDUKv1PX8i4WCb661mHHZ+6xRv+T32ZFvybMNs7 fkWYsrWK1+4xctxBcTZ/LTq6yd7PG7dneeVZlkMxke+4zeUurePP5GK0OeyF pY2GdvImR5u9t7/K5G9yM087LGK5AuGzUZHcObI4yapN0a5SZQ+pa0F6kdU/ yLhw1XbCXvlYxz9DY2x0hitGB5iiaA17ZE57QiNTy0NaQXOLXSGWQOihALeV X09zJjJZY7Y3EcYMgY2W4ax93cXjopotcF1LHEyRwlfIGOlmh7zticatIk1y H+RcKGq/uTHA0MdRjXF2gzvhga5wYCWmhkaSoo2xNe10jmW8ssn08whNo9gO VnucpcsjsorLFz2EJtLizGRjmhfcMMs2RmEkLrqeWMwSMijt57kRyNjM9wSa pwCnlBX8i4UaX5Ld2OVslxDG6RgZBG2MtILuzvg9jABMC6SINkuLKWK3lfd2 ckORzFtBDYMxjbZ1/imm8voVJmLGe/y+Ux8ykyWH2M1lrGWa6y2IfOeQ4pzY r6xdYHPYVws81iG20WW42Js9eWF1emu7/IuGU+uZEXmTUxW9uIodpxRbpY2o IGlPJ2wmW7GFrS9Su24ZtU6tsiy5lMbo2yXlw+5i244jGysVhHLim8UgivcH Y2Uj5cAyW0HGrS0bhuN2c7ocLFcXs/HIY28hsoLHKyMYw/yLhGn9R1yTC2tQ wRRyuTqNbK+Z00cRCewPe2Zsk2uFz9qWSaRwgiod6Yw3LLS3ZCzITNc23tIY mzyyNlNpeg/TZMu+myIcI7iNNbfRS3l1m8k92Pv5XR4nIl91jcqHSNdbhx1y fyLh2r6y1tXR27Y2tTWhrXexLImOdrVx3ZsRxMZA+Wdr2MExdPLcvde3oZHc KWVrxMxkbLMPDYo2b31RrbZXIMhnzbriO4kjlc27iJiuWOXH4XyW8H6sWX08 t0s3CZs7LGWL+RcBFcux1ZpJbdiN1bFG4tShLa6zdQlzri3cGTWxTWNkbkbx 080ZndauhBZJI5ogjkY24hkljgbkmk3d5ALLATXmMuMJk7HHx4HIy21JmTC3 uzkZJyYMde5CFsWZ5CTcTSkXbWyXWQcGL+RcBr+rQxCMciH/APcICp2omOLX QvIVq2aM4GSN92xgmz8Epkj5GHRDGBwy/IHudb4uFxu5H6Z545JhiMlJj7L9 WmdLcX0INw14kfcRR3eWytux0/N5pJY+U4zIC8u4CLq4tmyvrIz+Rf19/uaV EvDOMXzpv6x4qRcf1ViyLn+qr0K4/rnlEBuMbk7F2CyMlpe4++gMuID4riG9 hhh5SDLNiJI35rksRbBgp9y9nIF0ZZIm4S/uLzI3FvirBvIM3YwX92SyK1lF zJLA8iWe0htcPqdlcg7VJe/UT393HtQVP6l/X3+5DXtaeV8dgceU8QlDc7hX uiyFnIgzcabfcivuGYC5dHx+XHzWst7HcZN95b4i9uZpZsQbzXmrqeOfj72/ V3txFHLFdzyvfi8jdw2uCzmOwOctLppt4Y7yHH4q+il41x2XJQW3AMXkLTH2 EMOae6HRdlz7i+J0fuP9e/7pxoc454zDrohwnDkJGply5iiyd/EYOYcjgVn/ AGPm4VD/AGHjZnDL8VyrMnxkXz/0q+soshZyTZnCyXMNtdR/eQUWHZ9Tk7fh 2DbNyDTE22ZM24lH0kON5vf44cm5RjJMFjLqe2yF/JE1pY0Ov4hFZ/uP9e/7 p2pzstZMgyF5ZWTzb2humPxkrGOgmYmXU4Ud8KW8+Ge76bjUzpMPbPlHE72I 2Y5lbtdkc8+bFW9u9XsjHXkUzIW4e5bDlbeeAOzxtpba3NvGbiCW+jueM5+2 nZjMXh7CDF420nupi97HPde5SRu1+4/17/uW/E5DJW02TyrxNd8dtn29tA6V zvo8cTd2NuhYWBbZWPHLm/u8NYxjj9pJd5m34hLDIzhGQQ4PkwX8cz0MLP66 trqc/wBYWxVxxOyiuXcXtXOHHLZqZx22D5OPW8jXcbgc6fj1tM3JQNs7+afc dbRlsc9u2SD9x/r7/csYQ7P30kfIMbEy8ubYPjilvJgYLgONrE+W5vLfHwxY i1g/W/q7FY+1YeTMoox2a1GIut4SbW+vZ9GPMxCbOFukoPqg9BwTT3z8uq8t 8dEJDDDO7KUbY/uP9d/7wuquREHOfOI2WTk0HIUbbZC7gFrmZ2utLeC8tLDF QW9z9PRY427LxoFY3ALeUetzLuNoWfv7q3x5IJ/MSPCbOKsnaUwtJFQs/dPZ Nj7J7SWua3LtczFfuP8AXX+80d8lxbPyX8HH+TWzp8FdCxuOOZWJn6XklFgc m9ce+uschLl8b9TvYLViLvDwXsOTtpUGtKaoWp8bXjllzu5AOQegVoaQY2lW 9u9obcFpyUbP1CF5IbC2NuZLHYr9x/rr/eEhSyBXL9T7ljZpJrl07LS2c8XZ dcSzBkMb43Fr3lpwzxBdQ3MFwILt8at8rI0Wt3DKXyhrLi5knlaexITSQoWv kMVu1o0VDpYwpdO6wRsZdH/Hl2NixX7j/Xhpm7m60Fz5FPMbiXI3jrm5jt3P N3I5rZWttWNjdEny7MUhe2TiEVvJyHLcRY4Ptr62VteAGKWKVSOuX215Z3Nm e1A41FqYorXc3JZo4BJO6UjujQJzjrtLYMizjBHiv3HgbnsyjXOKvL6S6N/l BqhaY3l4tYd027N1rXTXOkyyManVpwhwPLGlXeMtrtXWMgniuLS+t1achET2 SQXMWR41VtgyBklA1s98wOAJIBBaSE9rnsiY6Jb0gZnZXHH/ALjwVodk7+R8 hu7gxJgEJirbp7Z44ajTuOe90po6QvTpahl9c4xcO5xY8gjaubXmT4nzDC8t wecWSwkUjjY5HFLG561uzf461vmZWDI2TgDRshpqqg6qY12tsT6aJNvOua2z /ceFOc2/mc6xax7mCziJicASHvkV0/dc9+txkMijYaGlcgwMsoppoX8J/stm v+5GxOuQO/Hef32NZY3GPytre4WxvDENqO7i+ptY43xsLe1SmE1i1mK4LRDK Jq5Zwlh/ceGSCK9mnkuJLMAuge2SW8eJZbh8NJvk4xmYmPu4u07ZYMRJYW17 mcTwqdjcVdOT7XIysGIuwYsTKXccu/6/48b3l/GLkHmGGTc7byG/Y+7uZbO4 aZrG4AgxlyXCuq9e9PmZMsvpMH7jxJrXXH0bQpdMpkoxk7mRujb/AJWxuY+T Q1mhlGs+UkUhcAJHstnXL2s3DEyEy3s8QeXSXEheNTnOIw+Hnu3W2Eu/p5cR ldTcfOYf0y7EkdheSXRtMi9kmHy88rrG5sXZKNzrb9x4g0vupSQixtnblk0a uNMMhqxBjLZjpKv07b2uaGtM1w4waZpmGeWR5oXvc+eFlbOxuL5DG3RVvibi M4zex4v8jlrK4gyuYY2GW9lDJ8xJIb3ItWPyOYbdTZ/Kuucq3IxyX75XWn7j xKv1FmA50drcukura5hNtZTuuGQERi1vTI2C6gYba5fM+1eyKfVCJrR6LIo4 Ly8D3wxyQwuhBFtlnYg4zk+Rt4LbK3ENvdZC6vI25C4DhyK/jmflHuuZc5dR ST57IOhueW5L6uPO5AwZOV2RmyULo8f+48Qa1100xkwZ2NlvPyNtzJb5aaXI w5+7t3x8mdbx3uVmyd3dchMGXnycb4slkpbqRr2PZfSsEUNk2NXl3DpBuHxx Y6jsdjhE2YPDYoIoxK8vADYmF0bFLctkNw/aj3Tuz77i6NkMOdfSy/ceIf8A 6TKxrLi4NLeL6h95O1tuJHqSQvfGLa3YCN1twyFltNPdSm4jbaQNDi9zg2K1 fLJEXOlt7VsbnT0m0te951OrGxOLhJey7h1xQC4cHiN0bXwapnyPEKuyZrH9 x4qQJjdOeaOkcXthL4ZJpXbsTooGWUEhuCogZVdMobWKZsD2bxlifM91pqin aHq1tWQECqitGsa5kgL9EAc9gc64MhEOwW2znxvgcW3AmLo4zbsIMkuVdG3G fuPGext72wbGMljra2gv7JqflrLRb5PGRtOVxc811lsbLIMlhbeN11jJXtzF jJK7K4hjYsviI0c3htpmXwrnMzuD1/8ASYcznkOHTuR4cSOz2Ge+4zGIll/W 8QwfreL1f9HYOE+axUgZlsfuHL40yDKYhseQyUN0v3GLfr9+vv19+vv19+vv 19+vv19+vv19+vv19+vv19+vv19+vv19+vv19+vv19+vv19+vv19+vv13r// 2gAIAQICBj8ALLLLLLLLLLLLLLLLLLLLLLLLLLLOnD19cVQ+YofMUOOkUVoq Ojta+ijtTmOijsUOELAsv27Xen+ph/tPUijGI6HChwhZFj6mXox9hCS+p6fq er5DXkNFGY/qIY0NYG4cKHCFGI6MqOxfU9SMHf7PuPR/U/E9KGMy2YHChx0y 5uLMJlnbLMnbOmduOiztxhOOouFD2MLbzsqHGGYWjDPkZ8Xoy/lLyzBgxsqH o9RlQv5CGdfMXiYfuFlHq/cepHe4ocrQhD8jJlC9QjL934Q9xQ46OzHxMKOj sucmDBg6M/Iy9x8bvUoe/ln4zjZUPfoRk/6KFg6jGjoUPh5hmYwNaXwKKKK1 Vpe+t1Q5ooooorWiitFamKHC2XwGKHCL4WDvSxQ4Wq9rrTnQxQ4W1WqtONDF DhLlKHGYxrzrsssssssxKhwpxGTriKHCjGvvezKhwlylD3OuAoe59T776hz3 ufbx3VDjOytXfu8TraUPbXBUPbzvZUqHuda+jMZjE9ih8bCOjIlHYoerEY3s 6MGRQ4qMnU5wVw1D5ih6OjvjqGUUUUUUUUUUUUUUUUUUUUUUUUUUUV+gf//a AAgBAwIGPwAoooooooooooooooooooooooooooqFzHC5jhc5TZers619l6uy 4cLQ8cDJh63CnoeTGjM5MCfiZjGhCF2Y1LTmcOfyMMyfkLVliFGdKmtNFFRR g6KOprT3qXMcKM68NaMT0ZM7ThaMGHDGI/ieoyowYZ1vLWxmIwx4GYULeUdn RkzsZMmTuOtxc5c5cB7y4eIWyucuD0Wd+ko+RejOhcC9N6O9K5GfLy8jr3eO lcPo7KOhGW/b5eJ1pUPge4xn0+0Tz6tF+rUuP6tah41db/5mdShuOtdFbdaX Ch8pwtGNOeKtvPBcLbwd8Bwtz7eJ/n5b7hb2Ef5+W64XA+x17PM72nC4WNpw uY4XIzqXGzGJ6lcbGpwtGNGOMuY4XPssssssssssssssssssssssssssv9B/ /9oACAEBAQY/AGg0pQSKAeckXucoC2Dc1YLHh5X+ZRX2WYbRd/mVYmEfCb5l YGI/Cb5lHKYjbbZm+ZW2H95vmVmLwheOZrfwVmzw5eOZrfwUGMsFmwBzNj8S rCWC/DM3zKyl4cx2DM1/4KMfVg6g2rma/wDBRBlgBG3mb5lFs8OUbTmb5lZh LBl45mt/BQLPCL7Ls3zKNnhNtvM3zKuGhI9ZvmV2of3m+ZWLQi23mb5lZVkg LcAzfMrpiSAv4QzX/gooJICw2jM1x8SgDJACdgzN8yrloQPWb5lEtLAANpLN 8yjkkga22zN/7dDPLp0BIALOwFybDalfdMOt1Ol5M2bJTEYG0dj9otXGLbvK aclryHBmrM3MguB5xupIxdWbhhhSQhstzid5oxs4MjYKpxpYyxGljONtrGlj Q5dPHbPY7fJXWfsn6Jb7BWdjkRDy27x8tGaNs0pwB24mmlFjqHxdm2KKIjN7 NgN7GnBPKMGPE11pTaFcQONcEA5eNqWNUszbP2tQVrC2wDjVkNmG0+Ssi432 DeTTEWMr8OPk9GuOrk7R4UQBzMe1vJrqO1mXsjcKZSxzAcwvu8lGEPYIcBt/ LQC8+YXLDdeiyDnMkO3/AHUr/N/u099lo7/zFp5HwgXBV304GEQuWrqKbXNo U40DLYSEX8vq0WlOaVvo+Avuol7PN2mPhXhQTTnLnFlPh9I0IJGLQJzO3iYb aVIl27F3Ko40sQAu1/xChC3M4F1HD0moaaElAWuTvPnrpQgLlwZ/01cj2Ue0 8fLQhVsFxC7h61WjWwXAneTxomQHZfymjIRmmf6NTuFFO1Kx5rceFX7wGzh5 BTSPjITZRwom+bUOMBu89ZnOKG2c7z5KBRgzHE+ejDDdSRiw40XlLKFN3kJ7 VexNhsAO+khDXvLEz/zEr/N/u1IDstHf+YlLjgbBF300a8sIxllH8K196nWx 7OnTgBsoyuLsRs/VSSMc07C6RDYoPeamyYy7XYUcjW6naY7RQW112DykUfZ5 QcXlO8+GjkFkOOY7TWA9pJtPEUSQeoSBmH6KESbXNz5vLRSO+BsB4jXSiPas Zpfk0AMIwbk8aaeUdnsjdamkBOa1kUbr1bFpGOY33eeizNd9oPlqSSQ5yxwF ZpDbMbsRw8FWC8i3stKohBueY3tX3lcBa7jbbyUWmQLEb5BtNqaRSQuwKNw4 1kXmkd4QzbbDqJy1/m/3alJ2AR3/AJiUWJu8mBfgvhWnaGB5oL2CqtwLeag3 /b52AHskEZNrb2rM/u/UXOIGQ/npnOEx+mY7h4RQCDLApx4sTupdJpEMsmIC Ri5JtiB4qGo1+mm0+nU5RJIhUXOwfCpYgB00Nwvk8TVm0Wmk1UcJAIiBOW+9 6/5URj1TjMsbrlITZe1ZjsJvfy0XJOZjitNmW8jcN3o10nwuMUobMoFvxUVW zPa+OwCh0Imd7XUL+nLRb7lOzk3bkJJ8ldTUaaWHMCczowVR56BfmvsrKCMx 3VNEovPwvQ6ILX2kbAaXTaeF522sAL+TNlpgNFOq77Ib0umyEaodtW7Si3eo OcAssWVb4k9RK/zf7tSk7LR/1ErYCp2HcvlrRLG5WPMVYg2z8p+LWhMUzwgy vm6blL2XAHLWmm1eqdtDqDfpyNm5MxjMnP2eapLEdEO1yN+NLLNFLDpxzCRo 2C2PpWy5qiXTAxsjqxcXBHMDgw71Op2GWL+KljhjcmTa6oxuOOa1aeFSUDxy h0xBYqt+ZfRqFhfqfd1AAx78lFTFJZOZrowt+ai/fbCNN9A6mJombsZ1K38v NWYKzsTbMFJGG64pYUja5wCIpLE+r2qYGNkiQ5XDgqxI3ZTTFuWJMUK4Et+K pXuc50wJa+Nyo31HpJXaXSTEI8bHMAWwVxm9LtV9/wBGgRAQJo1GAzHldB63 apJyrkXueUkW8lhUk0ETSSsSRDGpLBfSUCugIskmwg7b76DJcCIgmRTY3HZy 2rWzRsVkES2YGxxZR+usTmmlN2c7fVWmJHtFlix4e1TCv83+7Uo9GP8AqJTo xJAN3YbD6IrQqpACuRlG4ZWrQH3okzxCViogIHd5s+bu5a0P3HKdEdIhhKdk Jme1Te8ZYwyxN0oAQCMwszyetjWognkeXTz9ZZIJGLJlBunI3L6NR6fRqEh1 WWSNBgFu1nX1aaPTxmWZ5Y1RFGYkluFJ7tEskb6y0s2qDcqgDm0ul/6Tf9R6 g1EjZ2KS3JJJxXy1p4dLdD0FLT2OWMBn5mP8K0Pd0ksiQ6UdERs13kYdqadh 28/cXwU/vBlD6mYMYSQOULdRlJ8TVrtN77delPYwmSRHIJUhmRs75a1enRj9 zhR0IBujSI6r1FHyqI0+nEruqNrGPayZcscUPh/6j0+q6fRUqAQcSMo2tajM Gy6dQQo8R8VSEb9KMfgioEUlLSx5m3nmFa0k2tHe/luK94rPIzQDptBGxvlv nzN8KtZp4dLnUMW1MwtnaQgHKvoR9mptSkYjbUkswHdGzb4q5sBfl/a1avN2 ekl/3ko5ReQiwLDsjjUYGIMsWY8T1Er/ADf7tTC9uWPH7RKMEAwU2L760bZS 85Yk2xCqFN3NaEpmCiVw7gXAuu+oYkv0YFKqdpN2L2/eapvd81kkZzNCp3gg K6/By1OoUrFpTqG1DkEXJORahfROs0cGWAOvMGbPmbJl7XNy0dVpXMckUsTE jwhsVb0GqN25HPMpG2OZcP3fkUsU6FJIllV0sRbC1ad3c/8AbGgAlj3El2vI vpR8tf8ActImfUqoz5e9FtzeslDQsR1IAyOu8o5LBvjU8Ew6fu1Tml1uGXpD w/6rdnJ46l0+nVgkUDbdwLLlz+k1TSWOYpHY/BtToxPRGLv+qlBOWIiwVBjb dapI1U5hpgMlscF4VDOylNNCwklkcWFl5rY1/wBq0Mq6gMQZ5YzmTA/RBl5W 9OtbJtLLGC27DPy1rSBaTqE28h7xqbUTSNCkbZECAXYkZsxzVP7uVjN05umX UYvjyqqitYiIXfpJyAEnBkJw8lZ2b2S4m++kERvGjwliNn0iYV/m/wB2tSEN nKJY/apRVeZgLsx3mjJFqnhhxLBDa7GpGk185ja4RC1xb0gRQcqAovkv+mlQ EpY8rpykW8JFHQffpejb25BAPTAtld1Gd/3qVtHIdNHAbrKmDDdgatqdfL9z YZSC1844Glj0+rligQWjRGsoXdTlveEwcDnJbG24XtUY1OqkdVIaNWN8Rsai U181j2Rm/PSvHKw1RJLzA449om1JBPPJN4QxAW/iyrRTTaiSPM2Zyptc0vWm acrszm9r+GsrkLCO2eJ4V1YZm00EQyrkwLUSmtmW2Nw9Muo1cs6m4ZSxsR6o pbRlZZMVUbbmlih1TpHeyJewudtF9XI06qMqMxxPHHw0zaLUvpobZXyHBiPI fD4qbVwahkmk7Tg8zEm+JNNL/wBz1GQd3Pv8lSSaiQtI12dj+TG1JFGCIzLE TfEk9RK/zf7tTBe0Vjt/NSmsLMMXagtz01wVeJoBL9JBeTLx8NRjJ02HMVG4 U0hBZ2+j40IIQerNzTPwXymlgja0K/St4jQZntpY9i+as/1Zt0x5ONXClnJ3 7z5aXrWaUm2G4HcKsDla2J4CnyNZFNh4iaJYXY9ojcKyDlv+SjmxU7f/AMV0 UsqAbzb8dBcpcDa1sSaOnzjqDAjZTSILkg5QONB5SGmLYE7r90UykkHa7Hyd 1aaJTy7F83Ba5yVjTZbea6UXPfadyiipF3JsD+ulhiBC947z56jzGxMsVh5O otf5v92pbbbR2/mpWVjZRibd48KOk1XWildGdXiZcoCkWXIyHLy+lSRRNLKx QOpdlte+VRkVObZTSTXDHEqaErYkdhPPTu5JZhzWOz0aih1yPbUSJFF02AyB za/MrZq0kjtqJonkyFFdEAwzZj7Js1fevc+rLFDZ9PKAGFu5nTveHlo9UFZF wKHtZh3a+8y4SsMF3AV0ouZ2xw/XWm1cyW+8Ziitg1h3/Va/LQjXtuMbVne7 DYKmOt1BgKoCgzBdt7tzeHw1931PUF8xjZSBcLvZWVu1Unu9MzLkVg7Y2zDy Cm18ptpwS9yLXPhFdR1Cm3LHwFRCxUXFrU0Ubc204Y0DKvtSML7FWm4WIFtw 40LezjHaO8/+aiQuIFlHhHFqDHEnYTvqIHaZYr+T2i1/m/3anI2hY/6iUvel bsqdw40ijF2ics3lwrSsTfLAMq7r53xND3nqM8DIrM7hiwujZc2Q+K3Zp9fo o5IJ4lcoZGuSY74SDsc3o0I4zlQYux/RWgIGCzxnzDMK0bMLlZiVU7zlNaoX IEkasy7rhrX+NUSwqDLrApA3K1yryfFzVpvdLxGSOYKs2pZyHDPcJ01Xk+LS 6bVxHVadmXo5jlBVzlXqWHNk8NaUS6cymziPK+QLYDu5WzUvviZRO8hDOpYq qRMcvc5nfN6VQ+9tJGYSVVmhZiy2Y5O/zdqp/vcbB4ipVlYi4a/d+DQTAfSh eNhepZziirHdTssFpVZLRLiqnZTd1e6aTIbG+UeWpCozunaN8L+ejiCOI3mj 1MqwgXHlNHpjM18L7h46YAkrfmbezUM/bOy2xRUZOF5YrDj7Rca/zf7tTsou Qsdh9qlFpD7R/wAwpWB9ikUioeJ5b1C7AWWAXJ9Z6ndNhSW1/JIa1JGLBNSf x2aohM1zbEDid1aDPh1NREBbbmzCwrSAjEymx4cprUa5uWDKI0Y4A2OZ29Va i1TH2FjBp7+Y83w2pNTEQukKDI+RWIkW+1ypZa0D66XPIzxZAQAwVn5Qygd7 tVoQAWb2llAvsANHV6vNqEsHg0JY9FS5GWSRVOO3NSddcspSPMoGUDnHdHZr WKe0BHf49dYEiOLrqF3Em4vU8Y7CrGWXjy00arZY926so2E4mgFYtqGwUcAd pFdDFUT6RhtdvDTGc2uASm5V3ClVRYE5Ygd58VFS5zntPvJpnbBYht8tFzsJ uONI52dWK38xa/zf7tTAbSsdv5qUYy2JtzDafRro6URRyotnnMYZgpxyZjWX VLGyKMscnTAf4Ljs0Pd8fQGntlMPRXJl3i3pUNHA8QgUZTF0lIAO3P4majqJ soXEqgFlF+Ao6vJHnUgwdRA5S3eTwtQSYxTIDfniVgPNmpYpZPYbFhQBEHwU pQjsqo184wNx4aWFZEc2sJWQF/m/Fr7xM5kmY3zttzeKlgmkUxjlZgtnYb8z /NoaaOUZAMquV5wPDejBJIOkb8zC7gE3tnasnu6REVzdnKBmb1mNO+iiiWQ4 zTLGtrntZF7ufvVz5DOwAMqKFbKPFbtZasMdmZt5qORgUDMAFG23E17MgsCA H4CsztmMRwUceNOzE5VFz+yuvK1kQezWuootmPKprLfkXFvKaLvgo2eWosLD qxWH2i1/m/3a1A4on9VKVkaxQFQvn300LMbA3dhvPCgMoMpGC8BTEDmOJJom /Jtx2seNFpOwMQLVy7KyqLtvrIhOW/Of1UBbL5KIJAZtgHCmQcuQ3Mh2YUBf 93aaEjHs7AaGn02YonaCY3PlqHSwXOsI9qNuRd+askeLNtYcfLTANzueduAp ncBoIwMeJ3CupbI0lgF8K1FGjHKbNLJswoRRHNJf8fnpYVwRbZr7Sd96yHmA Owfwisz8sbb18ndpQvKijZvJo3NlG6ony2VZYgB9otf5v92pl4rGP/VSisQ2 beNB5UAv9HGNpJ7xrJb2jYu3AVkDf8ePBj4jWci0SjBasBYWwPDzUYx2zs/b WVTgO0RWZhu21mZjm7ooxw3kmHM1sbAVlkjKhWAkJ4kZlB9auq6FYwAQTgLN 2D8KpdHEvswLA8OJojSIJNbIbAHHE95r0srqx1WtJuR3mvayfCoRyxt1HJBu LWbC6D0uahE8Lx5mYNmUi5j+lX7P6yhHJGYtPCQcjYFmAvjSs3KB2LHCo9PC CxUFmUC5IUZmb1VXmp9ZkJhuEM1uUOwzKl/VovEjSWIDFATYnsr67eGpHkXK 4uiqcCLbc3pVe4t4b4UWY4cKUGwY7huFQxx9gSxXPE9Ra/zf7tTHgsf9RKD7 YwcD4jTNa5A28PVpoV5cx53G21KsaARrhbiaJsVQbfLQy7DwoYnqNt81WAx2 teupKfYpgq8TWdyVkt7NDsAouy3BR1Nhe5YZRenDxMzkxG68l8idNrdrL6lQ lomdF+7oEsGJEbOZl295WrrCOGDUsiLI0i5SziNg5bJn5ObN69JIdMercnsL c3WNQNvZzJI3w60ojDM0E0r5SAOSSXqoq49xOWppHUlmDrEAoAVmbMkrLfnn 7jVqGCtE0w1SSS5VLDrsjRAc3dytnqVjpbIwcRHKLnMsawtt5Oi6St6eetFL poAq6aSR5YSiqsitL1IUKg92H2dBotJ0dOI541QKCzZ1dNKTj2kz+1rVQTQO 8eqEZSIxoVQppn0wPa7s7LJmrR6KRGy6HUnUSOv1oYIG5gVZJI+n7N60yrog MjO2pLIJHcky5G6jtzZupH1E/wBOtMNZpVfUqzNqWWFLPeaKRcuK/wD86Sx/ DrTyHRs6RzrJIpiQeyDS5oQobn5ZIu34KEuhi6SGKJZOUJeRUCytlU99+aos frYsPhrX+b/dqa+Ayx3/AJiUZCtgMI13W40IoFBmfhuHFqCLge+x2k0Mtgoo EtfeB5aZlxc7R+yg8lg/CicBfZbaaGYXO4U0jG7HtH5IrLawtRW/N3RvNB5Z DFDAxaTjhuos4sbWjU7h8+jIzXvjc7hwq0R5LEX8m9qBWOzN2SdoHiNBpBY7 FTaB6VT+8TIVWANliIHMQUXKmOZvpM3ZqKabUNPH1AH07KqsyjUjSvsb6HJ7 R2r3wdTGrDTLm011z5T1umoHizpy/wDqVHqCx0k2qYtJAq50hUTRadkvm6n1 /UVfQr7qQZZzNplbqKVKLJLNG62UrnSVI0kp1mcSQ6jSuyyWs8M6yRR2VGK/ R9Tl7kiV7z07SZG0EiQxSGwU5pxpnmkHgjT2nLXvFtPPJOdBGJCojy5+Zo5V XN2unyy8v1VPo4Mx06xxOshIOfPGkjOpXu52aocu+WLD7Ra/zf7tS5uzljv/ ADEpmTAbF4AUG2ki7Grlth4bq/OfLSCPCPa7AfmFF3wJ2Cg7d2mUHMke1hsF Kqty7b0CcI17I4+emkfYuNNrdQ3tX7CXsqJ4qvltCDmQnvnxUZWQAk3F6KAk ljbLx8gq7HNI9rqpuPUpY3BJY4BQbmnlfTTSSKLIio5sDvwFNqH0c7tsijEb 2X0iAKMksE+ZthZHGH4xRcq6vsXBlvUUkSS9ZGDq2ViAwOYGk+9daQxAhbqw yhjna3wqypFMUUXfKrk2/FWY6PUcEXpvs9LCgo02oVe8SkgX8tqMbDKVNiGv f89RPbATRAfvrX+b/dqfKLtkSw8vVSlU9onn8tBb7uY8KOXZ+qsOyNlK74Kc ABvNWGxdtEA24t5KyBT0Ti1tp89dS3T064qnlq5OG0sa6j80C7F3E100XLpo /p38ZHc9Wle2WCPsjZe1ZBfL3fSNPJNzSPyoBuFEIBGt7qBxO3M1JO7WCXyK u1jsuaJCqCdrY5j60l89OIJXSOFc7WlawA4dTqUiyyyEoLBiFbDy5enSnqB1 U3sQRSgMGZRYhTjhswogSWPAmpZFlyXOQMADffla/ZpZI54ZQwBCuroR5MyM 9LoZHjjlc4BXLK2GAzWrXtlYxrOwGbaSMKTMuUmaKy/aLX+b/dph/t/1Frpq L4YncKyGWMMDzAuoP48aI68YHrr+2rCaOw2nOv7aznURm3ZBdcPz1frR5PCH X9tH2seOwZlw/PRCzRlt5DKSfIuNZTv3Cm0cKukcXb5Wu3orhQjXTOhtZgQc PzV0xGYowea4sb8MayKOY4ADG35KE81wASEUjLe2/GndvpXHIo2KL1laNCbX BDEfpFXbShrkXKuN+/Gl176hNOrkjpspZrg5eXJ2matTNIoYzRExxjB8sZzu 8mbs8ncqTUuyxxxoJMmJYoTbMAKSLpsS9yCLbBxFO0eYSLErLC2CsCSr/wDm rqE5NxBGKkdpTamQah0LWdVVmGDcaj0qN1RI6IgawJOcHF1yt62ZqbU60CGQ 8kax2yg+jWodjzM7NdjcmkSwLNLFjtt7Ra/zf7tNbbaP+otA5iCcTWvv/wBZ v/oBp9+B/RSalUbIrgCQDluCDtoFyOWzAk2G2hqEYtFkvmXYceNajNiokIH4 rVgcJnzFTxtbCkvYEMzY+QHCtOTvdyLbAMKhAS+Vc2O+1ODhaRlt+O1dNRYn AflqNU0zanU5rWJyqq7yrvyLSyTaJZFGYOrzIRY+jly5VrOmlj6vTaEZtSMg RuCqnaoMJtPFGFPKJOYn18tRz9WKyRurkSDYxVl3VC8cBkDlTKuYFHQHluy9 6op093aVDErRZWUvmRrYP+7y17vaOEaXVxSFZdPCpZSzHkeP1lpUdpDHHhkc WcvbEZW7NaiVb9R2OVDsUcKzjYJYif5iV/m/3aP2f9RauBiNgo6ifSO+qm55 nErKMx2tloFDKhO4Sn5Qr2Orni9bK4r/AI2vjk4CRCv51q408cy7mjkGP72W mXV6WWEm+LKbfvDlpUveCU5ZU2g32NbxVYTdNjgL3U/npjDNHOsaWtfZfG3L ReVOirub7x581aYxZWTeQQb44VmAuMrkYX2LtrSMpHNmNlOF+NjQzdlUxP5K 1F8LyMcfPWeEAsMQW2Co9DMqsNQjCJlOKuvNfL3+XuURr5xHp5AFnUyC4P1e a3fdqMGihd4g2RmdrC4NiRlPNy1Os5CyxSXFjjka2TlqNMpJMTRu5xufFagd QS4RVEWU4BVNsuFP1bifMOmRiMuOe4rRJAVj9sjtJckPkPV3ejyctGQnnZy2 G69TKOwr5SaCq2GeK4+0Ws1zm6977756P2f9RaNtrHltupdNqZ2SaDklHSY8 w9Je1QA94ZT6SuPk0Oh720+XgXt/FXJqdPNfwyp+2ro4twDA/wAJrpSQCRNm IvRZtJHFNcMHAMbAj0koSx3dAb482FTkQxoJFwN8t7d3AdqllnCBV5mN72B/ FUEi5URow69O+XhdlatRqYcnIpUljbNmPZSoYtSmWVEuirZhZjfGpJmbIiDM QOF6m1ABdQ7k+W5qyu12wyhcMMbejTHREDXRIWjykI4X6wLJ4svdrUxa3TSr q9Rq425csknTVG9suYsv0lQ6ZgzSxKWaaR0N81mygxhV5GzVqB93fUTyXdJY 0Y2wHK7Hl5GpWECKVJOZmAwIItyZ/wCGmSZxkjkaGVkHOc3NZs2X1q1TaiaT T6gM6KEiJAjUkQutz2Jcna8daXThmfTiMuc25ipOXCgtr2wXH8lSdIcuc2I3 +WlVRcCSPPJx51wFfbfLr+X/AFFq4/JWsygn2rVlYFWG0GuP5K2fmq6uyeYk fooNHq5kI3iRh+ugE94yMvhkIcfHFW1EUGoXyqUP5Y/m1/zfdzJ6UTB/isEp 4fv4hjlw6EwMdt+08tdXSe8+sQFUIHEq2S2XlvnqdJ4usvSyRPYk5mYZmC91 qOpcjK5nfNchssYWNb37vgqWdZGDkolzYtzyKmXm8S1qbmwaRyo4C9AKMTjf 9tRaIsY0mJVphfNszWsDSSyrJLMpuWeRsoI2cl+Z6hMOREIdAAoCkgnabeGn eVy6lyLK90Ita2VTlqSR3KxRqWzHgBepGXSRmCXKz2LdUZezJjyZsvdpdD7u 1LP7y6SxCTTggdJwDOszjtfPrTLGSwLhWjOOYNyt8LJRvcXNhYYiuV75yTbg N1KO05kiueAzrhX23y6/l/1FoIDv21qdRq+oI5JTlKEgAcS1mqabq5DGgc51 Ysb7A1u9QMcfO3YUXN6Dm632qQRY+G/ZrmB476ALZgNzCgJYEZeK4Gl6waJb jNcHZvxWj0NRYX5RnIw+GKSPStJLnOUZRnHxaDLJJE3HpuLfCSidJqHnjjNm WRS4x2csq08Ou90QahwLSIqmNsp3cp+TVv8AseqhAYEhCsiqwIYZReN+1Uwi bKBIwbNgQL2s1+9Vha+5QcSa0upLi6yA5QbcpuuUGlkkmjzbI4g62QH4Xa8T 1IqahFMLggFly2ZmDZGB7fwaKwES3diXblF79xPlPR0smB1B6Ze4NgcL4mm0 h0TySklYnQqY3tgHEubIq+tUeiEcS6uPTrHPKpUmSVxeZy3eVOxR1GmjjSXH Kw3X8ONE3UjYpJ3U+fCMNYkbKVdoaSPIL49teZq+2+XX8v8AqLXl3VLoJrvK GIWM9kjaFzVNCsmWK4k1gXsAxjKiDxNTzOAks47OXspbMpJo50V0vhGQCCTj ms3ay0xjjVHt21ZlVr17N1Aa1jJGGHwWQI1ANBEQoDGVCSjKRctzZWTLUGn6 A53C25hmG1rY9mpJBnEZJ6RRg1+Fw/8ADUXu8zyaUvntKm0WBPZvRI986rMA VykEjmGW9up+7WH/AMh1ijzY/wBSrr/8l1l+OUf+5QdP/kmr6lg2UgBdu5s1 FpPeskkjc/U6akNfab5+1WHvOQXw+iX59SRrrZJUQlQ2RRe3wqH/AC5ABuyj 51X+8Pfdyj51Z21MhIxHKNv71c2qkzE3ZsoufJ2qXNq5TGuyMKAP4qVPvDiJ dqZRj8LNX3eK8hVAy3FgARswore6jtW3nhRd8EHaHCjqLkKkkeQHf7RcTX23 y6P2f9Rau2NauRLrLDKyowJw4W8NRwmUqzsZJmNuZ9sa/Pap4pJGYrixLZow LZizN8io9RIiHTHMUkNxcg2sEU5o/Uam6jBHB5IgCxxxyuF70n1T5q+7TyOg RAVlQDC55g38HJUU0qsWKhChxD4koWqCYy9R1kug8KWJG2njV3bKb4RILE+s O9Xu2dVkFg6SB1C2VkZoyMvL4qvt3cKx/ACvbUnKT5DXTBKpqLyQjuiUfSxj /dXnVfHU+pVrBI2ax81quDt3VjtrbXl/BifwNp41IkZU6j+jbBRQk7VhitrZ aVbkRrtTxGnRVyoHisdl/aJX23y6H2f9Raw/EK15YbJmw4mlkRiHBuCNoNS6 2UiSfLcBwQJCvK0fL22ZWzUskWnAmvdJCTmBHccHMrpTyLIR1DmMeF8/HNbs eGrvFcEgtY434gmkmWTrJILhGsSL9pW9SoOmuUKwKkG2NjgKAZHznEhWb9tR qQS7hwpJJAbaQMxryHbVjtFWXE0cxsMxwG3bQYWAzAgsM1mXEWFLo5FCDVHM wBucqm/wc1Yfg4isaGONW/AVjQFiFzHfj2ctZpWYuVuRuHo1dSC3EbqOezOz xXP2iV9t8uh54/6i1fcK1M2mfTdCad541kJLc69M5uTwd2s4fQrfKGcrmICg INqeGjppZ4Y2Ll0CrZWJJONh6VFzJBYC5szfNpVV4zfs2v8ANpneaNY12kMc fNy0JVcyaRLq65yo5u1bCoWLTsI3JfAHarJhZl8VFM87KLbQ1hb7SohpFkMi liFZbbRzc5dqCg5GO5sB+9QdjusSDga5RhTcQxrK2w0kJ7WnjCPbiTmrCrH8 HlrhTNcqW2GgsuDbA2411bFnCqF4A2oRlea3M/lNXY47bcakdWF2eK43/SJX 23y6Hnj/AKi/gsNvHhVmByLj5zXW1Ayoo5R5qaIHLplxc7zwWrlsoUcx3BfA PSoafTgADDDu+f0qGl07EsCOo47zcBRRTdx234ejRjT8f7aVyjOQGJtixwoN A/ONqHBh51rLmaMneDhfzVaZOoPEmB/d7NSFG2tfKcG2cKZgL5QT+QXqSaUl nkYszcbn8FvwWUec7qBPM3GsMANpOAohVD+k2z8S1lRLta78APJQse3sB3mj Yh5dmUbqaM4uXiJP2iYV9t8urjb7P+otBEGaU7r7BxNDaEB5mPeNZlNoIziR vNDTQ4oBa/6SajhDdjE8APGaj0+mGJPL89qMcT3le5kk89KT9Kw5TtsD8qjF sa97bz61Ze+20+StLppOcSZ82O2yGjLAC9vCLSD8naoqfbxjABu0KsMCMDE+ B+DWHa3qcCKkgSXCRSgLY5bjumssyEJukGK/lq4NWtcnYK60ysbkBYlF2JOw Hw1llITOvJCowAG8t/1PGlWY3bcg2/jq5NlGxBsH4Cx5VAux4nctNMD7Qiy8 FHojxUyg3djfMe1c1Io5jniu/wBqlfbfLp2j7YEeW/HqLTAtYHF5+J4LS6fT H2anLJIOApNL7vGZI8C3Fq5btqGOI4nh6tMG5nfttxbwLRaQjryi/mHAUjy2 JY+zTifEfRoy7T3PKfJQduaVsXPCmkJxb9FaG27Ph8A/gzMMku6RdvwvFRmU rqNOGKfeIjcBlNmV/A6+F6zQ+2jGw3swFZNYpUDDPbEeesyMssLjG2IIppvd xyvtMDdk+oe7RiZSmsT6SOTBh6vo+rRZzZRtJwpl0otftSWxPq1c7TtJq1Y/ iq24YgeWuoWLOcEU7B5aUKo2klqYEGxePDd9IlfbfLqRTgCIxh/uLS6KJgBb G24ChodLyhfpZBvrJGuWRrADhf5TUzZc0xFl8lLNqLEn6JeF99feJ75N/l9E V1pMFXsrwG4CjLJcnYnAV5P/ALxoL+KhrdFIU1cRDLMLG3kxpNNKRB72RLyw bFe3fg+Z+CXVe6ZjDB7xRdTJpzzRO3Yl6kXZbMy1HA5Hu33q+Bic207t/oyn 6Nm8D0Y9RH05lvY/r9KutpD1Ihi8a/NoROelqBtjbC/moCZbSL9HMuDqfI1I usfq6cm0Uy7L/wCoPFV6sfwoyg2W+fgcMKdmN+B3AUqJgpN7k7jvoomCZ4hc 7z1E2V9t8upmXtBUt5+olOS5OskJGGwA0ZLZ3247PWal1D4HNdVO0+lTO4sN rHeaLuw6a7L0EX6NMTwrE8i76ygcu4Udyjaf1Udx3GmA2kAkfjpZYnaORDdH UkMDxVhS+7/fzlc1li1pN1vstP4f9yvdM6ENnilUMpBBUMrYH8f4Bo/eSH3l 7u2Kjt7WL/Zlb+m1HWe6dQNTCPpIzyzRnwyxfKWlaVLMhuGQ5ThuutLGCSqi wvialhsDnUgBhcXrK+1SUYHaCO7Qt+C9LlttN71mA5R2gO8eFFpXyRtYlRut 3aMliFEkeQE/6i19t8up5DsRUP8A6iU8xA27ONOZvoBi3pHwj0a6hwUbOHmo RKbqNpG+lhzAE7bY10ITdRi7D9FGNFywp2mrNgF2A1lXCPdff5aLkXJwQcfL UTe9YuvpCG68eXOSCLLy38VNP7um1WhkOKxugkhv+N+ov71EgrlGNySLiooH kLpHcQxsxIXMbtkB7OaiGKC20k4fopWmkWKAnmkNycu9lTv0mrij1mp1o7Op kQZhu5I0cIq0ZYRqI5m7pjAB8/Py0fpdtsEGPxqT7urktiAwt+umliRVuBnI wuw2k+KkGYAk3Fsb+evprE2HLYmgWlLCPaDh+WlhBsoHM36qEQssaG5bdTpm ui4su80MAMrRZR9otfbfLrUq/ZKJf+alWJ5GGPEClggwRRYeqO8aSGCxY4W/ XXTucw7bD9FGS1yewtXQ3lfaNwrprcDvekaXP3di7yeFXkFzuA2UHI5h+QCi rGyAXZ/1VfswL2Q36ay7IYziR3qEj2DHBRsso40rHEXsQNh8lZn7KjlQYACu W5AwrKtyThh+ipGjjDvFGZcjG11XtZB3m71GZEIyKrsmxmD9nJ6NBYYM5bKV ZNlmCtbHvc600y5SI2CMpPNmPk7q93M1EiJjlNm32xy0dEidKQIZbPe7KBfl y5s1GTSxmaJnKRyR2IbKcrbfSpYjGUkmLqjSH2YKKZOZkzd1aVdWhSU8xQ7T eg+XASRlid3tFwFfbfLrUKu0ogH81K+7Rtcntt4jw9WlAAeV8GI2k8B6NLGn /wCzLjmPdFLHi4U3kO9jWb6x8FUbQKzSNixx4+as7jnfCJOA41nkINtooyuL Le4/ZVzdQ2CrSwjFBi4/bRiQ5Y48ZCNlvDSlUyIvZt3vPRBNmfbbcKznmAwR Tx408OkCl44zLKWYLZF7ds3hqfSaWLPNAjSzvcdhCEfpH63KzfV1EjQlhKqu rDG4a+UYd6lEJ6UhOMhXA3FsmZx2KESuoJjQvlCuxjAzQ5svdyNyUJS55VBj AQXA5QCcP9NKmjhbKSjtqbgKQjW6l79lW5alXTyMXVeo5a2W0VkLL/1Mvo0Z VdnmERiDhO5vtYdmtPpohcs56MBUIGZjm7TDlXPSyAOuVndYlS6qWHTkZcMv rVDqfere1kjUQRkrmMYHss6r2eTx0VYWUSRHz+0Wvtvl1qbHKcic3D2iUXK3 VRZX/TSztA5V8YSFNst8oYfCqwgkfUS4IuU5jcZgqfB5qjdlLyvjHEBctfwi ptR0md1F3yqSFUbzbs008sD5UXOq5SRlPZf1aeWWBzObk3HYHlr7u0TpqGIs jKQ1j2eX0qjaSJigOUuRyBuBPipYyhE0gBUkWw3V0w/M+Mso/QKEKC0SnM8m 9qBF8imyKN/mpp5hi+7gKMspwI5VG21SvCivPqYX09rkFEftMuQ/SVp42hil 6cR06gqcUaykvlPayLl+P26hMenjQRKUhUF8yqwKsuYt/FUedwrLGI3AxuAS 2Zs3f5qkmCKnUhjgYLe9oh7NwSf3vHS9OCLMUEZbmyhAc2PNS6k2LDKAMR2A o7QOfmy82ahL00L9Mwra6jKWz4Ipyqy+KniypaSJouS4ID2xUg92tM3Rh6ul XKi8xuOTtc3+ktNC6RqrRNGSMymzqI+Xm7WVabUyFROsccAVSSAsa5FOJbnb vUQbYPDjv+kSvtvl1qFbBSiX83VSljjIEKi5AqNGgzRwwnTmMsMsgLNLcrl5 crN3aim6LRnR5TE6vzBo4ugrLy/D589Re+ZolEmnUAqnKrvzZpCtmX2mf2iV qxBGka6hGjyC+QZ7jPlbNzqjskfNTH7sMIVgRs3McqtEpkIXnZYpMi00sqsJ XjEWd2DOFJuc7KqdR8vs8+XsVD7wj0waRESKzMS9lj+78klsubLz/R1JBBpV WaaXryqXLRDAqiCMBMvTzN9Z4604ZnK6dbF5GDuRhyB8qN0vArdiszYKB2aF xtNkQbSaWSSzTts4KKxW7LgoO80y5cdrtw81B5QWmfsLvA8TV1JUx7qnf5ay qQGI28Ky4tvvvY0ArWwxtVrkk4laJbAbTwFZ15lvlG3HzU1r3Axbh5KEirmk GwNw4mldm9pLgANir5KWOEXv22O29ZbjKXhx3k50r7b5dan1E/qpRA7PHiay obMcGPAcBQhuRGuLEb6yw2Ea4W4njQAN3Y7KWCMZpb3JOxaBy55WNlvx40xz CTUbQDsWnJQBd7b2NM5T2dwW4ADuinYrYA4Dy8KM+ovfaB4f/FQLYEi4Xgvp UZ5BZdiDgONdJFvHm2cTxpnK5nJtmP6KAW7Mtt2Hmpi4PNtG6gkfatieAqxG OweU1ZtjDbvoaSMXlJ5reHy0sYN5VwCjYDRibHJzseJ4UZplJHdHE8fVrqns nBfJRUDmthfjUkj4sJYrX/3E2V9t8utUW7IjS9v91KBC8qiyLwoJGMzt2hwF LDEbi3tG4+SsAQi7BWWNbyHlB4U5YZtRJi77/NQdlKm1ohvUb2NNFFyj62Uj Gljj5iBYKePjpVjsqWxPHxUosBElzbhbeaRV5YlN2PE0FUhVPbc7bUsKXWMY Ft9XHMxG07qNxicBbdRsSzE3uay35jtNAubs2GHGnlkOVE2cT5FoECzMMLY5 eFMRdtQ3M78BQLEX7WbePPRYtybhvYiulEl5XGC7lG+kgQ5nOLE7AaKxm4J5 mPk4Uy5crGSMDy+0TGvtvl1rm3LErMeAEiG9NI2pjDbFS+NERalDNJ2yDiKX /lIGJuSThRVdYgc4A7gOPrUs7aqIyjBUvs9JqUyauJUXHbtNEJrIxfDPemSL Vxtccxve5oINYi3xkkLbvCtLAupSKCPAMTtFZE1kZzdo5t1KF1kRF97bBT/8 6LZgualkbXQ8o7ObfQc66HHALm2eeumNbEEP1gbAVlTXwhV35sTQy62HKBzN mvei766LKMVUHGlc62LKvZS9XTVxA8M1XGrjNxjc76OaRMqmwF+1/wCGiRqo xYAWB2erV49TGoG9jjRA1UYUDmx2nyUSNXFsuVBx9VaU9YPJJJGI4UNwoDrt r7b5dHo581scl72+DX13xq+u+NX13xq+u+NX13xq+u+NX13xq+u+NX13xq+u +NX13xq+u+NX13xq+u+NX13xq+u+NX13xq+u+NX13xq+u+NX13xq+u+NX13x q+u+NX13xq+u+NX13xq+u+PXl/Pev//Z --38d4dce1-3f31-11d6-8f81-00308441cba8-- From owner-linux-xfs@oss.sgi.com Sun Mar 24 11:01:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OJ1cZ10921 for linux-xfs-outgoing; Sun, 24 Mar 2002 11:01: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 g2OJ1Xq10894 for ; Sun, 24 Mar 2002 11:01: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 g2OK3qBA008526 for ; Sun, 24 Mar 2002 12:03:52 -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 NAA20237; Sun, 24 Mar 2002 13:02:36 -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 NAA76568; Sun, 24 Mar 2002 13:02:36 -0600 (CST) Date: Sun, 24 Mar 2002 13:02:36 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Paul Blazejowski cc: Subject: Re: XFS latest changes, sb corruption? In-Reply-To: <20020324172512.5F09122998@mail.blazebox.homeip.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 24 Mar 2002, Paul Blazejowski wrote: > Yes, my LILO resides on /dev/sda2 which is the root partition with XFS > filesystem.And i've been doing that for past 2 years or so without any > problems.My MBR has NTLOADER and to avoid conflicts with it, i choose to use > lilo on my / partition. > > LILO version is 21.7.5 that shipped with Slackware 8.0.It always worked and i > knew about the FAQ entry but it never applied in my case until recently.My > guess is that there's been either a change in XFS or LILO that don't play > together anymore and i get corrupted superblock on my root....Any comments? My only comment is that I don't know how this ever worked... if it did, I think you were just lucky. :) The XFS superblock signature / magic number should be "XFSB" in the first 4 bytes on the partition, and they're not there in your image - lilo has overwritten it. I'm afraid that you'll have to find another way to boot, XFS and lilo want to put data in the same place. -Eric From owner-linux-xfs@oss.sgi.com Sun Mar 24 11:12:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OJCSO11133 for linux-xfs-outgoing; Sun, 24 Mar 2002 11:12:28 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2OJCNq11107 for ; Sun, 24 Mar 2002 11:12:23 -0800 Received: from auto-nb1.xs4all.nl (qn-212-58-163-104.quicknet.nl [212.58.163.104]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2OJEg0c098283; Sun, 24 Mar 2002 20:14:42 +0100 (CET) Message-Id: <4.3.2.7.2.20020324201112.02d80360@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 24 Mar 2002 20:11:51 +0100 To: Eric Sandeen , Paul Blazejowski From: Seth Mos Subject: Re: XFS latest changes, sb corruption? Cc: In-Reply-To: References: <20020324172512.5F09122998@mail.blazebox.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 13:02 24-3-2002 -0600, Eric Sandeen wrote: >On Sun, 24 Mar 2002, Paul Blazejowski wrote: > > > Yes, my LILO resides on /dev/sda2 which is the root partition with XFS > > filesystem.And i've been doing that for past 2 years or so without any > > problems.My MBR has NTLOADER and to avoid conflicts with it, i choose > to use > > lilo on my / partition. > > > > LILO version is 21.7.5 that shipped with Slackware 8.0.It always worked > and i > > knew about the FAQ entry but it never applied in my case until recently.My > > guess is that there's been either a change in XFS or LILO that don't play > > together anymore and i get corrupted superblock on my root....Any comments? > >My only comment is that I don't know how this ever worked... if it did, I >think you were just lucky. :) The XFS superblock signature / magic >number should be "XFSB" in the first 4 bytes on the partition, and they're >not there in your image - lilo has overwritten it. I'm afraid that >you'll have to find another way to boot, XFS and lilo want to put data in >the same place. He could try putting it onto the swap partition. 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 Sun Mar 24 12:39:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2OKdPh11962 for linux-xfs-outgoing; Sun, 24 Mar 2002 12:39:25 -0800 Received: from absinthe.carnagecopia.com (qmailr@absinthe.carnagecopia.com [216.187.87.246]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2OKdKq11936 for ; Sun, 24 Mar 2002 12:39:20 -0800 Received: (qmail 56227 invoked by uid 85); 24 Mar 2002 20:41:39 -0000 Received: from random@carnagecopia.com by absinthe.carnagecopia.com with qmail-scanner-1.03 (uvscan: v4.0.50/v4193. . Clean. Processed in 0.253645 secs); 24 Mar 2002 20:41:39 -0000 Received: from h24-80-25-225.vc.shawcable.net (HELO carnagecopia.com) (24.80.25.225) by absinthe.carnagecopia.com with SMTP; 24 Mar 2002 20:41:38 -0000 Message-ID: <3C9E3A3B.9000908@carnagecopia.com> Date: Sun, 24 Mar 2002 12:42:35 -0800 From: Vincent Janelle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Blazejowski CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: XFS latest changes, sb corruption? References: <20020324172512.5F09122998@mail.blazebox.homeip.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Actually, you can install lilo/grub/etc onto your MBR, and tell it to boot /dev/sda1 (assuming that is where windows is installed). I've been doing this for the last 4 years =) NTLDR isn't actually installed on the MBR of the drive. Paul Blazejowski wrote: > On Sunday 24 March 2002 10:36 am, you wrote: > >>Oh wait, I probably know what this is. >> >>Are you trying to install lilo on your boot partition? >> >>(i.e. "boot = /dev/sda2" in lilo.conf) >> >>You need to use the mbr (boot = /dev/sda, or whatever disk boots) >>(or you could install it on your swap partition, or other non-xfs >>partition). XFS needs block 0 on the disk, but if you try to install lilo >>there it will overwrite xfs fs structures. >> >>http://oss.sgi.com/projects/xfs/faq.html#lilowork > > Yes, my LILO resides on /dev/sda2 which is the root partition with XFS > filesystem.And i've been doing that for past 2 years or so without any > problems.My MBR has NTLOADER and to avoid conflicts with it, i choose to use > lilo on my / partition. From owner-linux-xfs@oss.sgi.com Sun Mar 24 15:21:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ONL7V13851 for linux-xfs-outgoing; Sun, 24 Mar 2002 15:21:07 -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 g2ONKvq13825 for ; Sun, 24 Mar 2002 15:20:57 -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 g2P0Vekw005746 for ; Sun, 24 Mar 2002 18:31:41 -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 KAA10721; Mon, 25 Mar 2002 10:21:56 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA42481; Mon, 25 Mar 2002 10:21:54 +1100 (AEDT) Date: Mon, 25 Mar 2002 10:21:53 +1100 From: Nathan Scott To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: quota permissions Message-ID: <20020325102153.C42289@wobbly.melbourne.sgi.com> References: <20020324043203.A30975@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020324043203.A30975@plato.local.lan>; from erbenson@alaska.net on Sun, Mar 24, 2002 at 04:32:03AM -0900 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Ethan, This EPERM sounds like a botch in the spilt patches. CVS works fine for me after a quick test, but CVS has different quota code. Could you mail me your fs/quota.c please? (will save me having to download and apply the split patches). The tools problem is known and has been fixed in current devel tools, not yet released (the workaround you used should always work). thanks. On Sun, Mar 24, 2002 at 04:32:03AM -0900, Ethan Benson wrote: > > I started testing quotas on XFS and found that users cannot find out > what thier quota is set to, this is normally found by running the > quota command, under 2.2 kernels (this is the first time ive used > quota under 2.4) quota details are printed for any filesystems which > they have files, with 2.4 and XFS (2.4.18) quota always reports that > they have no quotas. > > strace shows that this appears to be due to the quota syscalls > returning EPERM: > > eb@ash ~$ quota > Disk quotas for user eb (uid 1000): none > eb@ash ~$ quota -u eb > Disk quotas for user eb (uid 1000): none > eb@ash ~$ sudo quota -u eb > Disk quotas for user eb (uid 1000): > Filesystem blocks quota limit grace files quota limit grace > /dev/hda9 0 20480 25600 1 6000 8000 > eb@ash ~$ > > strace reveals: > > quotactl(0x5805 /* Q_??? */|USRQUOTA, "/dev/hda9", 0, {16777219, 0, 0, 131, 0, 7, 5, 0}) = 0 > stat64(0x10024f88, 0x100274d0) = 0 > quotactl(0x5805 /* Q_??? */|USRQUOTA, "/dev/hda9", 0, {16777219, 0, 0, 131, 0, 7, 5, 0}) = 0 > geteuid() = 1000 > quotactl(0x5803 /* Q_??? */|USRQUOTA, "/dev/hda9", 1000, {2147481280, 805354732, 805463848, 2147481248, 2147481296, 805354732, 2147481280, 267568876}) = -1 EPERM (Operation not permitted) > > I used the split patches, the following were applied: > xfs-2.4.18-split-only.bz2 > xfs-2.4.18-split-xattr.bz2 > xfs-2.4.18-split-quota32.bz2 > xfs-2.4.18-split-kernel.bz2 > xfs-2.4.18-split-misc.bz2 > xfs-2.4.18-split-acl-dmapi.bz2 > > as a sidenote, this is probably a quota userland bug, but edquota > refused to work initially after activating quotas (i unmounted and > remounted the filesystem with the quota mountopt) i had to use edquota > -F xfs -u user for the first time, after this it seems to figure out > the format without -F. im using quota 3.0.4-1 from debian woody. > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ -- Nathan From owner-linux-xfs@oss.sgi.com Sun Mar 24 15:57:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2ONvgs14345 for linux-xfs-outgoing; Sun, 24 Mar 2002 15:57:42 -0800 Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2ONvVq14286 for ; Sun, 24 Mar 2002 15:57:31 -0800 Received: from erbenson.alaska.net (85-pm30.nwc.alaska.net [209.112.158.85]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g2ONxpR57408 for ; Sun, 24 Mar 2002 14:59:51 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 72A3D3939 for ; Sun, 24 Mar 2002 14:58:48 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 9A5F71027C; Sun, 24 Mar 2002 14:58:48 -0900 (AKST) Date: Sun, 24 Mar 2002 14:58:48 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: XFS latest changes, sb corruption? Message-ID: <20020324145848.K26309@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020324172512.5F09122998@mail.blazebox.homeip.net> <4.3.2.7.2.20020324201112.02d80360@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GeDkoc8jIzHasOdk" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20020324201112.02d80360@pop.xs4all.nl>; from knuffie@xs4all.nl on Sun, Mar 24, 2002 at 08:11:51PM +0100 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --GeDkoc8jIzHasOdk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 24, 2002 at 08:11:51PM +0100, Seth Mos wrote: > At 13:02 24-3-2002 -0600, Eric Sandeen wrote: > >On Sun, 24 Mar 2002, Paul Blazejowski wrote: > > > > > Yes, my LILO resides on /dev/sda2 which is the root partition with XFS > > > filesystem.And i've been doing that for past 2 years or so without any > > > problems.My MBR has NTLOADER and to avoid conflicts with it, i choos= e=20 > > to use > > > lilo on my / partition. > > > > > > LILO version is 21.7.5 that shipped with Slackware 8.0.It always work= ed=20 > > and i > > > knew about the FAQ entry but it never applied in my case until recent= ly.My > > > guess is that there's been either a change in XFS or LILO that don't = play > > > together anymore and i get corrupted superblock on my root....Any com= ments? > > > >My only comment is that I don't know how this ever worked... if it did, I > >think you were just lucky. :) The XFS superblock signature / magic > >number should be "XFSB" in the first 4 bytes on the partition, and they'= re > >not there in your image - lilo has overwritten it. I'm afraid that > >you'll have to find another way to boot, XFS and lilo want to put data in > >the same place. >=20 > He could try putting it onto the swap partition. bad plan, the bootloader will be overwritten as soon as swap is activated, and you will probably end up crashing your system when you scribble part of the active swap with lilo. his only options are put lilo in the MBR, or create a small ext2 partition to hold lilo (such as /boot). i recommend MBR it will not cause problems with dual booting, just read the lilo.conf man page. lilo should really have a check added to see if the partition its going to install on has an XFS superblock, as far as linux filesystems go XFS is unique in that it doesn't have 1K of space left alone at the start of the partition for bootblocks. should be a trivial 2 or 3 line change to lilo which would save a few people a lousy day i imagine. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --GeDkoc8jIzHasOdk 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 iEYEARECAAYFAjyeaDgACgkQJKx7GixEevy1tACgoet2NTK2tyo0Tr9H/w3ssR8i lNAAn3y1Jbyxcvfto6eYrFb1OpN1U8/C =v1vD -----END PGP SIGNATURE----- --GeDkoc8jIzHasOdk-- From owner-linux-xfs@oss.sgi.com Sun Mar 24 17:25:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P1PEG15351 for linux-xfs-outgoing; Sun, 24 Mar 2002 17:25:14 -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 g2P1P9q15325 for ; Sun, 24 Mar 2002 17:25:10 -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 g2P1RP6G014827 for ; Sun, 24 Mar 2002 17:27:27 -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 MAA11737; Mon, 25 Mar 2002 12:26:07 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA42707; Mon, 25 Mar 2002 12:26:05 +1100 (AEDT) Date: Mon, 25 Mar 2002 12:26:05 +1100 From: Nathan Scott To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: quota permissions Message-ID: <20020325122605.D42289@wobbly.melbourne.sgi.com> References: <20020324043203.A30975@plato.local.lan> <"from <20020325102153.C42289@wobbly.melbourne.sgi.com> <20020324143537.J26309@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020324143537.J26309@plato.local.lan>; from erbenson@alaska.net on Sun, Mar 24, 2002 at 02:35:37PM -0900 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Mar 24, 2002 at 02:35:37PM -0900, Ethan Benson wrote: > ... > i attached fs/quota.c Thanks, here is the problem: $ diff -Naur quota.c.orig quota.c --- quota.c.orig Mon Mar 25 12:19:57 2002 +++ quota.c Mon Mar 25 12:20:55 2002 @@ -47,6 +47,7 @@ (type == GRPQUOTA && !in_egroup_p(id))) && !capable(CAP_SYS_ADMIN)) goto error; + break; default: if (!capable(CAP_SYS_ADMIN)) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Mar 24 17:30:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P1UIp15586 for linux-xfs-outgoing; Sun, 24 Mar 2002 17:30:18 -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 g2P1UEq15560 for ; Sun, 24 Mar 2002 17:30:14 -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 g2P2evkw006386 for ; Sun, 24 Mar 2002 20:40:58 -0600 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA37506 for linux-xfs@oss.sgi.com; Mon, 25 Mar 2002 12:31:11 +1100 (EST) Date: Mon, 25 Mar 2002 12:31:11 +1100 (EST) From: Nathan Scott Message-Id: <200203250131.MAA37506@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota permissions Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Mar 24 17:29:46 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:114776a xfsmisc/2.4.18-pre3-ac2-quotactl.patch - 1.2 - Fix a bug where we were only allowing root to use Q_GETQUOTA/Q_XGETQUOTA. From owner-linux-xfs@oss.sgi.com Sun Mar 24 19:36:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P3aME16822 for linux-xfs-outgoing; Sun, 24 Mar 2002 19:36:22 -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 g2P3aFq16796 for ; Sun, 24 Mar 2002 19:36:15 -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 g2P4kxkw006530 for ; Sun, 24 Mar 2002 22:47:00 -0600 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA55079 for linux-xfs@oss.sgi.com; Mon, 25 Mar 2002 14:37:13 +1100 (EST) Date: Mon, 25 Mar 2002 14:37:13 +1100 (EST) From: Nathan Scott Message-Id: <200203250337.OAA55079@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf massaging Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk No-op change, effectively, but should help Steve and I to keep our workareas in sync a bit better. Date: Sun Mar 24 19:32:38 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:114782a linux/fs/xfs/xfsidbg.c - 1.175 linux/fs/xfs/xfs_buf.h - 1.84 linux/fs/xfs/pagebuf/page_buf_trace.h - 1.2 - Get external trace points working again, PB_TRACE macro busted for this case. linux/fs/xfs/xfs_vnodeops.c - 1.519 linux/fs/xfs/linux/xfs_lrw.h - 1.19 linux/fs/xfs/linux/xfs_lrw.c - 1.127 linux/fs/xfs/linux/xfs_iops.c - 1.129 linux/fs/xfs/linux/xfs_vnode.h - 1.28 linux/fs/xfs/pagebuf/page_buf_io.c - 1.18 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.6 linux/fs/xfs/pagebuf/page_buf.c - 1.14 linux/fs/xfs/pagebuf/page_buf.h - 1.9 - Prepare pagebuf APIs for multiple blocksize support. In particular, the IO path needs to get access to blocksize information which currently is only held in the xfs_mount structure -- this change reorganises a few things so that the necessary information is available to the code that needs it. We also no longer need the pbm_dev field (in pb_bmap_t) as this is now available from the pb_target_t always. linux/fs/xfs/Makefile - 1.136 linux/fs/xfs/Makefile.in - 1.14 linux/fs/xfs/pagebuf/Makefile.in - 1.4 linux/fs/xfs/pagebuf/Makefile - 1.4 - Propogate the PAGEBUF_TRACE flag if need be. From owner-linux-xfs@oss.sgi.com Sun Mar 24 20:09:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P49Ri17288 for linux-xfs-outgoing; Sun, 24 Mar 2002 20:09:27 -0800 Received: from mail.blazebox.homeip.net (postfix@pool-141-155-137-69.ny5030.east.verizon.net [141.155.137.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2P49Hq17260 for ; Sun, 24 Mar 2002 20:09:18 -0800 Received: from blaze.homeip.net (blaze.homeip.net [192.168.0.2]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 9FF9922998; Sun, 24 Mar 2002 23:10:09 -0500 (EST) Subject: Re: XFS latest changes, sb corruption? From: Paul Blazejowski To: Ethan Benson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020324145848.K26309@plato.local.lan> References: <20020324172512.5F09122998@mail.blazebox.homeip.net> <4.3.2.7.2.20020324201112.02d80360@pop.xs4all.nl> <20020324145848.K26309@plato.local.lan> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-sZkLaQiF57K6SzEHoMH5" Organization: X-Mailer: Evolution/1.1.0.99 (Preview Release) Date: 24 Mar 2002 23:11:15 -0500 Message-Id: <1017029475.791.13.camel@blaze> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-sZkLaQiF57K6SzEHoMH5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2002-03-24 at 18:58, Ethan Benson wrote: > bad plan, the bootloader will be overwritten as soon as swap is > activated, and you will probably end up crashing your system when you > scribble part of the active swap with lilo. >=20 > his only options are put lilo in the MBR, or create a small ext2 > partition to hold lilo (such as /boot). i recommend MBR it will not > cause problems with dual booting, just read the lilo.conf man page. >=20 > lilo should really have a check added to see if the partition its > going to install on has an XFS superblock, as far as linux filesystems > go XFS is unique in that it doesn't have 1K of space left alone at the > start of the partition for bootblocks. should be a trivial 2 or 3 > line change to lilo which would save a few people a lousy day i imagine. That's what i thought about using swap...that the loader would get wiped, not that my swap is used a lot these days (1gig of ram helps). I grabbed latest LILO and put it on MBR (they way i intended to do it long time ago).It works all fine now for both XFS on / and win2k. But teh thing is that it all worked till now,LILO was happy and so was XFS...unless i had done it all wrong.Now i wonder wheater to report this to LILO maintainer and hope it will get fixed/changed? Paul --=20 _________________________________ ( http://www.linuxdiscussions.org ) --=-sZkLaQiF57K6SzEHoMH5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjyeo2MACgkQOkMJCMfleaK7VgCgjsCsnzi0/rsaJaTYBr0BnppX zCwAoOzfOknTDB6C6X6GD035D1mQytMc =opfI -----END PGP SIGNATURE----- --=-sZkLaQiF57K6SzEHoMH5-- From owner-linux-xfs@oss.sgi.com Sun Mar 24 21:07:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P57Mq17827 for linux-xfs-outgoing; Sun, 24 Mar 2002 21:07:22 -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 g2P57Dq17801 for ; Sun, 24 Mar 2002 21:07:13 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2P6Hukw006653 for ; Mon, 25 Mar 2002 00:17:58 -0600 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA20318; Mon, 25 Mar 2002 16:08:08 +1100 (AEDT) Date: Mon, 25 Mar 2002 16:08:08 +1100 From: Timothy Shimmin To: Thomas Winkler Cc: linux-xfs@oss.sgi.com Subject: Re: default acl on directory problem Message-ID: <20020325160807.B5356@boing.melbourne.sgi.com> References: <1016808160.5266.19.camel@janus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <1016808160.5266.19.camel@janus>; from t.winkler@itcampus.de on Fri, Mar 22, 2002 at 03:42:39PM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Thomas, On Fri, Mar 22, 2002 at 03:42:39PM +0100, Thomas Winkler wrote: > i am using xfs enabled kernel 2.4.16 and tools. acl seems to work > properly, except me having a hard time setting correct default acls on a > directory. after setting acls on a directory (chacl and setfacl) it looks > like this: > # file: . > # owner: cvs > # group: cvs-misc > user::rwx > group::rwx > other::--- > mask::rwx > group:cvs-misc:rwx > default:user::rwx > default:group::rwx > default:other::--- > default:mask::rwx > default:group:cvs-misc:rwx > this seems to work for all users in the cvs-misc group. when a create a > file as user all other users of cvs-misc have read and write > permissions. when i create a directory as another user (not cvs) i get > something like the following: > # file: . > # owner: [otheruser] > # group: [otherprimarygroup] > user::rwx > group::rwx #effective:r-x > other::--- > mask::r-x > group:cvs-misc:rwx #effective:r-x > default:user::rwx > default:group::rwx > default:other::--- > default:mask::rwx > default:group:cvs-misc:rwx > why do i have effective r-x permissions for group access? shouldn't it > be rwx, or am i missing something? > Looking at getfacl(1), the "#effective" comment refers to the effect the mask ACE has on all groups and named user ACEs whose permissions are reduced. In your case, your mask ACE is "r-x" so this will potentially reduce permissions for group and named-user ACEs. I guess the comment is there as a reminder of what the mask ACE is doing. So did you have a different command to set the acl for "otheruser" which had a different mask ACE ??? BTW, general userland ACL questions are best sent to acl-devel@bestbits.at (check out: http://acl.bestbits.at/) now that we're using common userspace code for ext2, ext3 and XFS. Cheers, --Tim From owner-linux-xfs@oss.sgi.com Sun Mar 24 21:19:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P5Jsb18069 for linux-xfs-outgoing; Sun, 24 Mar 2002 21:19:54 -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 g2P5Jnq18043 for ; Sun, 24 Mar 2002 21:19:49 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2P6M5BA019338 for ; Sun, 24 Mar 2002 22:22:06 -0800 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA20404; Mon, 25 Mar 2002 16:20:44 +1100 (AEDT) Date: Mon, 25 Mar 2002 16:20:44 +1100 From: Timothy Shimmin To: James Pearson Cc: linux-xfs@oss.sgi.com Subject: Re: NFS and umask Message-ID: <20020325162044.C5356@boing.melbourne.sgi.com> References: <3C98A887.C4E1FFCD@moving-picture.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3C98A887.C4E1FFCD@moving-picture.com>; from james-p@moving-picture.com on Wed, Mar 20, 2002 at 03:19:35PM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi James, On Wed, Mar 20, 2002 at 03:19:35PM +0000, James Pearson wrote: > I've just had the problem with mkdir ignoring umask when creating > directories on Linux XFS file systems mounted over NFS. > > I'm using XFS 1.0.2 with kernel 2.4.14-xfs > > Searching the archives, shows that this is a known issue - but are there > any workarounds/fixes? > This is probably related to a bug with the handling of the umask in the XFS/ACL code. (if a default ACL doesn't exist then xfs incorrectly applies the umask in the nfsd case) With ACLs disabled, this bug was fixed in the xfs-kernel on January 10 2002. With ACLs enabled, this bug still exists and possible solutions are currently being discussed. --Tim From owner-linux-xfs@oss.sgi.com Sun Mar 24 21:27:26 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P5RQH18223 for linux-xfs-outgoing; Sun, 24 Mar 2002 21:27: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 g2P5RLq18197 for ; Sun, 24 Mar 2002 21:27:21 -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 g2P6c6kw006683 for ; Mon, 25 Mar 2002 00:38:07 -0600 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA67154; Mon, 25 Mar 2002 16:28:21 +1100 (EST) Date: Mon, 25 Mar 2002 16:28:21 +1100 (EST) From: Nathan Scott Message-Id: <200203250528.QAA67154@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@muriel.parsec.at Subject: TAKE - libacl Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Small cleanup from AG... Date: Sun Mar 24 21:26:46 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:114787a cmd/acl/include/libacl.h - 1.7 cmd/acl/libacl/Makefile - 1.9 cmd/acl/libacl/acl_to_any_text.c - 1.3 cmd/acl/libacl/acl_entry_to_any_str.c - 1.4 - Make acl_entry_to_any_str() a static function and move it to libacl/acl_to_any_text.c From owner-linux-xfs@oss.sgi.com Sun Mar 24 22:10:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P6ABV18878 for linux-xfs-outgoing; Sun, 24 Mar 2002 22:10:11 -0800 Received: from mail.tahsda.org.tw (c252.h203149202.is.net.tw [203.149.202.252]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2P6A4q18852 for ; Sun, 24 Mar 2002 22:10:05 -0800 Received: from localhost ([127.0.0.1] helo=mail.teatime.com.tw) by mail.tahsda.org.tw with smtp (Exim 3.33 #1) id 16pNhX-0000Ez-00; Mon, 25 Mar 2002 14:11:27 +0800 Received: from p66.n120.tah ([139.168.120.66]) by mail (TeaTime Mail Server 0.6.5) with SMTP id spool/sma.914..BaqYb for ; Mon, 25 Mar 02 14:11:18 +0800 Date: Mon, 25 Mar 2002 14:11:16 +0800 From: Tommy Wu To: Eric Sandeen Subject: Re: bomb and force shutdown again Cc: ASANO Masahiro , Reply-To: tommy@teatime.com.tw Organization: TeaTime Development In-Reply-To: References: <20020324195445T.masano@tnes.nec.co.jp> Message-Id: <20020325140745.B920.NEWSLETTER@teatime.com.tw> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.10 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > > The disk error handling of the recent xfs cvs kernel (20020323, 2.4.18) > > CVS 2002-02-24 ok > > CVS 2002-03-13 stalled after fs shutdown > > CVS 2002-03-23 stalled after fs shutdown I also got the xfs_force_shutdown message in 3/15. Use the 2.4.18 patch in ftp site. -- Tommy Wu mailto:tommy@teatime.com.tw http://www.teatime.com.tw/~tommy ICQ: 22766091 Mobile Phone: +886 936 909490 TeaTime BBS +886 2 31515964 24Hrs V.Everything From owner-linux-xfs@oss.sgi.com Sun Mar 24 23:30:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P7Uc119733 for linux-xfs-outgoing; Sun, 24 Mar 2002 23:30:38 -0800 Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2P7UUq19705 for ; Sun, 24 Mar 2002 23:30:30 -0800 Received: from erbenson.alaska.net (96-pm14.nwc.alaska.net [209.112.141.96]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g2P7WqD10724 for ; Sun, 24 Mar 2002 22:32:52 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 808283939 for ; Sun, 24 Mar 2002 22:32:51 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 74DE21027C; Sun, 24 Mar 2002 22:32:51 -0900 (AKST) Date: Sun, 24 Mar 2002 22:32:51 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: XFS latest changes, sb corruption? Message-ID: <20020324223251.L26309@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020324172512.5F09122998@mail.blazebox.homeip.net> <4.3.2.7.2.20020324201112.02d80360@pop.xs4all.nl> <20020324145848.K26309@plato.local.lan> <1017029475.791.13.camel@blaze> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1rguoi8KZGYj2k4L" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1017029475.791.13.camel@blaze>; from paulb@blazebox.homeip.net on Sun, Mar 24, 2002 at 11:11:15PM -0500 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --1rguoi8KZGYj2k4L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 24, 2002 at 11:11:15PM -0500, Paul Blazejowski wrote: > That's what i thought about using swap...that the loader would get > wiped, not that my swap is used a lot these days (1gig of ram helps). i don't think it would matter whether your swap was actually used or not, from looking a the first 1k on my swap partition there appears to be some consistent pattern of data, i expect (but havn't tested) that it would be wiped the moment you ran swapon. either way why anyone would want to have thier system randomly not boot is beyond me ;-) > I grabbed latest LILO and put it on MBR (they way i intended to do it > long time ago).It works all fine now for both XFS on / and win2k. >=20 > But teh thing is that it all worked till now,LILO was happy and so was that is not possible, XFS has not left room at block zero of the partition for as long as its existed, lilo when told you install on a partition always puts it within the first 512 bytes, there is zero chance that installing lilo will not result in the destruction of the XFS superblock. you must be mistaken about how you had lilo configured. > XFS...unless i had done it all wrong.Now i wonder wheater to report this > to LILO maintainer and hope it will get fixed/changed? it cannot be fixed, all that can be done is for lilo to check for XFS magic before scribbling on partitions, and abort if it finds one. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --1rguoi8KZGYj2k4L 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 iEYEARECAAYFAjye0qMACgkQJKx7GixEevzqNACePWOTkxzmK/wRFhuSdvCoUUOO 93IAn1HroB0e+pmt5rxKpEmyE/lRzmtt =MFnq -----END PGP SIGNATURE----- --1rguoi8KZGYj2k4L-- From owner-linux-xfs@oss.sgi.com Sun Mar 24 23:41:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P7fwa20133 for linux-xfs-outgoing; Sun, 24 Mar 2002 23:41:58 -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 g2P7fpq20106 for ; Sun, 24 Mar 2002 23:41:52 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx08)) with ESMTP id C91B8613E; Mon, 25 Mar 2002 08:44: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 IAA19487; Mon, 25 Mar 2002 08:44:07 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 2A32B57306; Mon, 25 Mar 2002 08:43:31 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id C6EEA25835; Mon, 25 Mar 2002 08:43:30 +0100 (CET) Message-ID: <3C9ED522.B872AFD3@ch.sauter-bc.com> Date: Mon, 25 Mar 2002 08:43:30 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: XFS latest changes, sb corruption? References: <20020324172512.5F09122998@mail.blazebox.homeip.net> <4.3.2.7.2.20020324201112.02d80360@pop.xs4all.nl> <20020324145848.K26309@plato.local.lan> <1017029475.791.13.camel@blaze> <20020324223251.L26309@plato.local.lan> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ethan Benson schrieb: > > On Sun, Mar 24, 2002 at 11:11:15PM -0500, Paul Blazejowski wrote: > > > That's what i thought about using swap...that the loader would get > > wiped, not that my swap is used a lot these days (1gig of ram helps). > > i don't think it would matter whether your swap was actually used or > not, from looking a the first 1k on my swap partition there appears to > be some consistent pattern of data, i expect (but havn't tested) that > it would be wiped the moment you ran swapon. either way why anyone > would want to have thier system randomly not boot is beyond me ;-) I agree. The better way would be to create just a small primary partition and use this to place LILO. Since Linux doesn't insist on sitting on a primary partition, it should always be possible to keep one only for LILO. > > > I grabbed latest LILO and put it on MBR (they way i intended to do it > > long time ago).It works all fine now for both XFS on / and win2k. > > > > But teh thing is that it all worked till now,LILO was happy and so was > > that is not possible, XFS has not left room at block zero of the > partition for as long as its existed, lilo when told you install on a > partition always puts it within the first 512 bytes, there is zero > chance that installing lilo will not result in the destruction of the > XFS superblock. you must be mistaken about how you had lilo configured. > > > XFS...unless i had done it all wrong.Now i wonder wheater to report this > > to LILO maintainer and hope it will get fixed/changed? > > it cannot be fixed, all that can be done is for lilo to check for XFS > magic before scribbling on partitions, and abort if it finds one. > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ > > ------------------------------------------------------------------------ > Part 1.2Type: application/pgp-signature From owner-linux-xfs@oss.sgi.com Mon Mar 25 00:03:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P83Te25298 for linux-xfs-outgoing; Mon, 25 Mar 2002 00:03:29 -0800 Received: from mail.blazebox.homeip.net (postfix@pool-141-155-137-69.ny5030.east.verizon.net [141.155.137.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2P83Iq25270 for ; Mon, 25 Mar 2002 00:03:19 -0800 Received: from blaze.homeip.net (blaze.homeip.net [192.168.0.2]) by mail.blazebox.homeip.net (Postfix) with ESMTP id A3C3822998; Mon, 25 Mar 2002 03:04:02 -0500 (EST) Subject: Re: XFS latest changes, sb corruption? From: Paul Blazejowski To: Ethan Benson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020324223251.L26309@plato.local.lan> References: <20020324172512.5F09122998@mail.blazebox.homeip.net> <4.3.2.7.2.20020324201112.02d80360@pop.xs4all.nl> <20020324145848.K26309@plato.local.lan> <1017029475.791.13.camel@blaze> <20020324223251.L26309@plato.local.lan> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-YWoWtKKqeTMDOQMtVJ8R" Organization: X-Mailer: Evolution/1.1.0.99 (Preview Release) Date: 25 Mar 2002 03:05:08 -0500 Message-Id: <1017043512.2732.17.camel@blaze> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-YWoWtKKqeTMDOQMtVJ8R Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-03-25 at 02:32, Ethan Benson wrote: > that is not possible, XFS has not left room at block zero of the > partition for as long as its existed, lilo when told you install on a > partition always puts it within the first 512 bytes, there is zero > chance that installing lilo will not result in the destruction of the > XFS superblock. you must be mistaken about how you had lilo configured. Previously i had this in /etc/lilo.conf (lilo-21.5-7) boot =3D /dev/sda2 prompt timeout =3D 300 default =3D Linux change-rules reset vga=3D792 # XFS image =3D /vmlinuz root =3D /dev/sda2=20=20 label =3D Linux read-only # LFS_3.1 image =3D /vmlinuz-lfs root =3D /dev/hde3 label =3D "LFS 3.1" read-only # Windows 2000 other =3D /dev/sda1 label =3D "Windows 2000" table =3D /dev/sda I bet if went back to XFS code from around Feb 20th i can still use this config without lilo overwriting the superblock on sda2...but i've put lilo on MBR and i'm happy with the way it works now :-). =20 > it cannot be fixed, all that can be done is for lilo to check for XFS > magic before scribbling on partitions, and abort if it finds one. I would like to see this change in lilo -:) for one and it would save some boot suprises about VFS not being able to mout partitions... Regards, Paul --=20 _________________________________ ( http://www.linuxdiscussions.org ) --=-YWoWtKKqeTMDOQMtVJ8R Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjye2jQACgkQOkMJCMfleaIjNwCdFOYeK4+WejgqV8Pbl2AbwbQp Dq0AoL2z7cM74chgb20fX35XwBUmOA64 =buzu -----END PGP SIGNATURE----- --=-YWoWtKKqeTMDOQMtVJ8R-- From owner-linux-xfs@oss.sgi.com Mon Mar 25 00:32:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2P8WR427459 for linux-xfs-outgoing; Mon, 25 Mar 2002 00:32:27 -0800 Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2P8WHq27069 for ; Mon, 25 Mar 2002 00:32:17 -0800 Received: from erbenson.alaska.net (96-pm14.nwc.alaska.net [209.112.141.96]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g2P8YdD40360 for ; Sun, 24 Mar 2002 23:34:39 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 237AA3939 for ; Sun, 24 Mar 2002 23:34:38 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id D934E1027C; Sun, 24 Mar 2002 23:34:37 -0900 (AKST) Date: Sun, 24 Mar 2002 23:34:37 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: XFS latest changes, sb corruption? Message-ID: <20020324233437.M26309@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020324172512.5F09122998@mail.blazebox.homeip.net> <4.3.2.7.2.20020324201112.02d80360@pop.xs4all.nl> <20020324145848.K26309@plato.local.lan> <1017029475.791.13.camel@blaze> <20020324223251.L26309@plato.local.lan> <1017043512.2732.17.camel@blaze> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tpyx7gKuSYt+mjHM" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1017043512.2732.17.camel@blaze>; from paulb@blazebox.homeip.net on Mon, Mar 25, 2002 at 03:05:08AM -0500 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --tpyx7gKuSYt+mjHM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 25, 2002 at 03:05:08AM -0500, Paul Blazejowski wrote: > On Mon, 2002-03-25 at 02:32, Ethan Benson wrote: >=20 > > that is not possible, XFS has not left room at block zero of the > > partition for as long as its existed, lilo when told you install on a > > partition always puts it within the first 512 bytes, there is zero > > chance that installing lilo will not result in the destruction of the > > XFS superblock. you must be mistaken about how you had lilo configured. >=20 > Previously i had this in /etc/lilo.conf (lilo-21.5-7) >=20 > boot =3D /dev/sda2 this will destroy the XFS superblock. >=20 > I bet if went back to XFS code from around Feb 20th i can still use this > config without lilo overwriting the superblock on sda2...but i've put > lilo on MBR and i'm happy with the way it works now :-). you are wrong. XFS has never left space for lilo (or any bootblock), its been that way long before it ever was ported to Linux. but feel free to try, just be ready for another ruined superblock. the only explanation is your configuration was not what you thought it was. > I would like to see this change in lilo -:) for one and it would save > some boot suprises about VFS not being able to mout partitions... i don't use lilo anymore so im not that interested in doing the work, but like i said its really only a matter of 2 or 3 lines of code. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --tpyx7gKuSYt+mjHM 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 iEYEARECAAYFAjye4R0ACgkQJKx7GixEevyLegCePD6YUb/9E5mdIR0y0Iu0QP7g PiYAn0+2rpV0S+1s+ku7hFZbBdCS/0xO =hJSL -----END PGP SIGNATURE----- --tpyx7gKuSYt+mjHM-- From owner-linux-xfs@oss.sgi.com Mon Mar 25 03:25:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PBPSh11177 for linux-xfs-outgoing; Mon, 25 Mar 2002 03:25:28 -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 g2PBPLq11151 for ; Mon, 25 Mar 2002 03:25:21 -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 16pSdT-0001n9-00; Mon, 25 Mar 2002 11:27:35 +0000 Message-ID: <3C9F09A7.326376DF@moving-picture.com> Date: Mon, 25 Mar 2002 11:27:35 +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: Timothy Shimmin CC: linux-xfs@oss.sgi.com, seth.mos@xs4all.nl Subject: Re: NFS and umask References: <3C98A887.C4E1FFCD@moving-picture.com> <20020325162044.C5356@boing.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for the info - given that the XFS 1.0.2 v2.4.14-xfs kernel was available before January 10 2002, then, I assume, disabling ACLs will make no difference with this kernel? As our users have a default umask of 2, setting the default ACL equivalent to a directory with '0775' seems to be a suitable work round for the time being ... does this sound like a sensible thing to do? I notice there is nothing in the XFS FAQ about this problem - in fact the FAQ states: 'So far there are no more known problems with XFS and NFS since then (mid-march 2001)' James Pearson Timothy Shimmin wrote: > > Hi James, > > On Wed, Mar 20, 2002 at 03:19:35PM +0000, James Pearson wrote: > > I've just had the problem with mkdir ignoring umask when creating > > directories on Linux XFS file systems mounted over NFS. > > > > I'm using XFS 1.0.2 with kernel 2.4.14-xfs > > > > Searching the archives, shows that this is a known issue - but are there > > any workarounds/fixes? > > > This is probably related to a bug with the handling of > the umask in the XFS/ACL code. > (if a default ACL doesn't exist then xfs incorrectly applies > the umask in the nfsd case) > > With ACLs disabled, this bug was fixed in the xfs-kernel > on January 10 2002. > > With ACLs enabled, this bug still exists and > possible solutions are currently being discussed. > > --Tim From owner-linux-xfs@oss.sgi.com Mon Mar 25 04:06:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PC6gr12042 for linux-xfs-outgoing; Mon, 25 Mar 2002 04:06:42 -0800 Received: from magic.vamo.orbitel.bg (dns.vamo.orbitel.bg [195.24.63.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PC6Tq12015 for ; Mon, 25 Mar 2002 04:06:32 -0800 Received: from localhost (ivandi@localhost) by magic.vamo.orbitel.bg (8.11.6/8.11.4) with ESMTP id g2PCAEg08395 for ; Mon, 25 Mar 2002 14:10:14 +0200 X-Authentication-Warning: magic.vamo.orbitel.bg: ivandi owned process doing -bs Date: Mon, 25 Mar 2002 14:10:13 +0200 (EET) From: Ivan Ivanov To: linux-xfs@oss.sgi.com Subject: file coruption on power fail Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Are there any chances for solving this problem. I have read all the faq and the XFS white paper. I have tried allmost all XFS patches from oss.sgi.com for various kernels and know that XFS logs only metadata updates. It is fast, has EA and ACL but when the system crashes for any reason most of the open files ( including opened ro ) are lost - for example XF86Config. Regards Ivan From owner-linux-xfs@oss.sgi.com Mon Mar 25 04:27:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PCR3512363 for linux-xfs-outgoing; Mon, 25 Mar 2002 04:27:03 -0800 Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PCQvq12335 for ; Mon, 25 Mar 2002 04:26:57 -0800 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2PCTJ5d067329; Mon, 25 Mar 2002 13:29:19 +0100 (CET) Message-Id: <4.3.2.7.2.20020325132339.038b6bb8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Mar 2002 13:26:27 +0100 To: Ivan Ivanov , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: file coruption on power fail In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:10 25-3-2002 +0200, Ivan Ivanov wrote: >Are there any chances for solving this problem. > >I have read all the faq and the XFS white paper. >I have tried allmost all XFS patches from oss.sgi.com for various kernels >and know that XFS logs only metadata updates. >It is fast, has EA and ACL but when the system crashes for any reason most >of the open files ( including opened ro ) are lost - for example >XF86Config. Bizarre, normally only files that have been written within 30 seconds before the crash could be affected, can you give some more details about the problem. What kernel are you on? What compiler did you use? Can you describe your hardware? Is it the machine that crashes or the power that fails? If you see a panic or a oops can you parse it through ksymoops and send it to the list? 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 Mon Mar 25 05:10:57 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PDAva13435 for linux-xfs-outgoing; Mon, 25 Mar 2002 05:10:57 -0800 Received: from dns.vamo.orbitel.bg (mail@dns.vamo.orbitel.bg [195.24.63.30]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PDAhq13407 for ; Mon, 25 Mar 2002 05:10:47 -0800 Received: from amavis by dns.vamo.orbitel.bg with scanned-ok (Exim 3.33 #1) id 16pUHW-0001Z8-00 for linux-xfs@oss.sgi.com; Mon, 25 Mar 2002 15:13:02 +0200 Received: from ivandi (helo=localhost) by dns.vamo.orbitel.bg with local-esmtp (Exim 3.33 #1) id 16pUHG-0001Uh-00; Mon, 25 Mar 2002 15:12:46 +0200 Date: Mon, 25 Mar 2002 15:12:46 +0200 (EET) From: Ivan Ivanov To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: file coruption on power fail In-Reply-To: <4.3.2.7.2.20020325132339.038b6bb8@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Mar 2002, Seth Mos wrote: > At 14:10 25-3-2002 +0200, Ivan Ivanov wrote: > >Are there any chances for solving this problem. > > > >I have read all the faq and the XFS white paper. > >I have tried allmost all XFS patches from oss.sgi.com for various kernels > >and know that XFS logs only metadata updates. > >It is fast, has EA and ACL but when the system crashes for any reason most > >of the open files ( including opened ro ) are lost - for example > >XF86Config. > > Bizarre, normally only files that have been written within 30 seconds > before the crash could be affected, can you give some more details about > the problem. > > What kernel are you on? > What compiler did you use? > Can you describe your hardware? > Is it the machine that crashes or the power that fails? > If you see a panic or a oops can you parse it through ksymoops and send it > to the list? > > 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. > > > I started testing XFS from kernel 2.4.6, the last was 2.4.18. Compiler is gcc-2.95-3 / Slackware-8.0 Old machine - AMD K6, VIA TX Pro, WD Caviar UDMA HDD, 160 MB SDRAM. I have no any hardware problems. Machine doesn't crashes - I am unpluging power for testing. No kernel oops or somthing else. The main problem is not that data writen in last 30 sec. is lost - it is normal. The BIG PROBLEM is that entire file is lost. In the case with XF86Config I unpluged power during X startup. XF86Config must be opened ro but after rebooting it was garbage. Most of config files of X apps are broken ( in my case DFM configs ) if power crashes in a X session. Any file opened for editing with mcedit or any editor that rewrites file on save is filled with NULL. Mounting filesystem with -o sync has no efect. This never hapens with ext3 in ordered data mode. So, is it a bug or a feature of XFS jornaling filesystem. From owner-linux-xfs@oss.sgi.com Mon Mar 25 05:30:20 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PDUKi13804 for linux-xfs-outgoing; Mon, 25 Mar 2002 05:30:20 -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 g2PDUDq13776 for ; Mon, 25 Mar 2002 05:30:13 -0800 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2PDWYKF007104; Mon, 25 Mar 2002 14:32:35 +0100 (CET) Message-Id: <4.3.2.7.2.20020325142634.03da58f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Mar 2002 14:29:44 +0100 To: Ivan Ivanov From: Seth Mos Subject: Re: file coruption on power fail Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <4.3.2.7.2.20020325132339.038b6bb8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:12 25-3-2002 +0200, Ivan Ivanov wrote: >I started testing XFS from kernel 2.4.6, the last was 2.4.18. >Compiler is gcc-2.95-3 / Slackware-8.0 >Old machine - AMD K6, VIA TX Pro, WD Caviar UDMA HDD, 160 MB SDRAM. >I have no any hardware problems. Machine doesn't crashes - I am unpluging >power for testing. No kernel oops or somthing else. > >The main problem is not that data writen in last 30 sec. is lost - it is >normal. The BIG PROBLEM is that entire file is lost. In the case with >XF86Config I unpluged power during X startup. XF86Config must be opened ro >but after rebooting it was garbage. Most of config files of X apps are >broken ( in my case DFM configs ) if power crashes in a X session. Any >file opened for editing with mcedit or any editor that rewrites file on >save is >filled with NULL. >Mounting filesystem with -o sync has no efect. Mounting the filesytem sync should make this go away, also the latest CVS has a update which may fix this. Can try checking out the latest tree and see if this helps? >This never hapens with ext3 in ordered data mode. > >So, is it a bug or a feature of XFS jornaling filesystem. It is a feature present in all XFS enabled kernels before a recent 2.4.18-xfs from CVS or recent split patches. The new 1.1 release which is coming also has this fix. 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 Mon Mar 25 06:55:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PEtNu16633 for linux-xfs-outgoing; Mon, 25 Mar 2002 06:55:23 -0800 Received: from mail.blazebox.homeip.net (postfix@pool-141-155-137-69.ny5030.east.verizon.net [141.155.137.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PEtEq16605 for ; Mon, 25 Mar 2002 06:55:14 -0800 Received: from blaze.homeip.net (blaze.homeip.net [192.168.0.2]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 1454A22998; Mon, 25 Mar 2002 09:56:06 -0500 (EST) Subject: Re: XFS latest changes, sb corruption? From: Paul Blazejowski To: Ethan Benson Cc: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-/V5zPJLMQZc5I31Dh6ck" Organization: X-Mailer: Evolution/1.1.0.99 (Preview Release) Date: 25 Mar 2002 09:57:16 -0500 Message-Id: <1017068236.864.7.camel@blaze> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-/V5zPJLMQZc5I31Dh6ck Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-03-25 at 03:34, Ethan Benson wrote:=20 =20 > you are wrong. XFS has never left space for lilo (or any bootblock), > its been that way long before it ever was ported to Linux. but feel > free to try, just be ready for another ruined superblock. I'm wrong on many things and i must agree because Eric pointed this out too...i knew about it from reading FAQ before. > the only explanation is your configuration was not what you thought it > was. That's what i think it was and it worked as i was booting using floppy disk that would load part of teh loader and /dev/sda2 would load the kernel image...=20 > i don't use lilo anymore so im not that interested in doing the work, > but like i said its really only a matter of 2 or 3 lines of code. I'll try write the author and ask, if he could modify lilo... Thanks, Paul --=20 _________________________________ ( http://www.linuxdiscussions.org ) --=-/V5zPJLMQZc5I31Dh6ck Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjyfOswACgkQOkMJCMfleaLwcQCfSdT3glG3rrWMK4QmWFnqSUg6 hNwAoKZRk4dxfzVAWFLXrJyd6YwJEO7Z =AMnA -----END PGP SIGNATURE----- --=-/V5zPJLMQZc5I31Dh6ck-- From owner-linux-xfs@oss.sgi.com Mon Mar 25 08:59:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PGxa021053 for linux-xfs-outgoing; Mon, 25 Mar 2002 08:59:36 -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 g2PGxVq21027 for ; Mon, 25 Mar 2002 08:59: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 g2PIAKkw010788 for ; Mon, 25 Mar 2002 12:10:20 -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 LAA30910; Mon, 25 Mar 2002 11:00:33 -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 LAA58878; Mon, 25 Mar 2002 11:00:33 -0600 (CST) Subject: Re: 2.4.18-xfs and RML's kernel-preempt (was: XFS latest changes, sb corruption?) From: Eric Sandeen To: Derek J Witt 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: 25 Mar 2002 11:00:34 -0600 Message-Id: <1017075634.1738.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 2002-03-24 at 11:04, Derek J Witt wrote: > Hi! I'm using the 2.4.18-xfs cvs tree. I just used RML's 2.4.18-1 patch > and it works like a charm. I applied that patch after applying Shawn > Starr's patch10 and i'm having no problems here. I've heard reports that although the preempt patches apply and build and run, you're not actually getting any benefit w/ xfs kernels - but I have not looked into this. > One problem I encountered is that if I jump my FSB speed to 75MHz and PCI > to 37MHz, I get kernel panics the first time around once the drives get > mounted. try alt.overclocking.breaks.stuff :) > I got a quick question about reading XFS partitions in Windows 2000. Is > there such a creature to allow me to do just that? No, no such option. -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 25 09:06:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PH6hx21593 for linux-xfs-outgoing; Mon, 25 Mar 2002 09:06:43 -0800 Received: from filecabinet.amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PH6cq21561 for ; Mon, 25 Mar 2002 09:06:38 -0800 Received: (from ctooley@localhost) by filecabinet.amoa.org (8.11.6/8.11.6) id g2PH8v510082; Mon, 25 Mar 2002 17:08:57 GMT X-Authentication-Warning: filecabinet.amoa.org: ctooley set sender to ctooley@amoa.org using -f Subject: Re: 2.4.18-xfs and RML's kernel-preempt (was: XFS latest changes, sb corruption?) From: Chris Tooley To: Derek J Witt , linux-xfs@oss.sgi.com In-Reply-To: <1017075634.1738.4.camel@stout.americas.sgi.com> References: <1017075634.1738.4.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 25 Mar 2002 17:08:57 +0000 Message-Id: <1017076137.8381.14.camel@filecabinet.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Samba across a network. Not on the local machine. On Mon, 2002-03-25 at 17:00, Eric Sandeen wrote: > On Sun, 2002-03-24 at 11:04, Derek J Witt wrote: > > Hi! I'm using the 2.4.18-xfs cvs tree. I just used RML's 2.4.18-1 patch > > and it works like a charm. I applied that patch after applying Shawn > > Starr's patch10 and i'm having no problems here. > > I've heard reports that although the preempt patches apply and build and > run, you're not actually getting any benefit w/ xfs kernels - but I have > not looked into this. > > > One problem I encountered is that if I jump my FSB speed to 75MHz and PCI > > to 37MHz, I get kernel panics the first time around once the drives get > > mounted. > > try alt.overclocking.breaks.stuff :) > > > I got a quick question about reading XFS partitions in Windows 2000. Is > > there such a creature to allow me to do just that? > > No, no such option. > > -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 25 10:30:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PIUJT24102 for linux-xfs-outgoing; Mon, 25 Mar 2002 10:30:19 -0800 Received: from saiya-jin.flinthills.com (root@saiya-jin.flinthills.com [64.39.192.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PITxq24066 for ; Mon, 25 Mar 2002 10:29:59 -0800 Received: from saiya-jin.flinthills.com (cappicard@localhost [127.0.0.1]) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) with ESMTP id g2PIPjQf014907 for ; Mon, 25 Mar 2002 12:25:45 -0600 Received: (from cappicard@localhost) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) id g2PIPjM1014905; Mon, 25 Mar 2002 12:25:45 -0600 X-Authentication-Warning: saiya-jin.flinthills.com: cappicard set sender to djw@flinthills.com using -f Subject: Re: XFS latest changes, sb corruption? From: Derek James Witt To: Linux XFS In-Reply-To: <1016971074.7957.2.camel@mdew> References: <20020324075637.4021C5C268@mail.blaze.homeip.net> <1016971074.7957.2.camel@mdew> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qs6QSEOKtn+N9n/SVtaZ" X-Mailer: Evolution/1.0.2 Date: 25 Mar 2002 12:25:44 -0600 Message-Id: <1017080744.2172.6.camel@saiya-jin.flinthills.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-qs6QSEOKtn+N9n/SVtaZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, there. I got the same behavior. I found LILO does overwrite the XFS superblock. Evidently, XFS's superblock even includes the boot sector. So, could lilo be modified not to run on a XFS root partition? I can try to modify lilo to include a XFS-detection routine and abort if XFS is detected on root. I could also put in a parameter to override this (if anyone would be bold enough to overwrite the SB). On Sun, 2002-03-24 at 05:57, mdew wrote: > Yeah I've checkout the CVS, and indeed its br0k3n... same Problem. >=20 > Debian Sid+Preemptive+GCC 3.0.4 >=20 > Once repairing the drive, its bootable again. >=20 >=20 > On Sun, 2002-03-24 at 19:56, Paul Blazejowski wrote: > > Hi Eric, > >=20 > > I have a bug i think...i was able to reproduce the sb corruption after > > compiling new kernel. > >=20 > > Updated my xfs tree with todays CVS (no changes) then i generated a dif= f=20 > > against clean 2.4.18 kernel patched with xfs and jfs patches,did make d= ep=20 > > then make bzImage followed by make modules...all of these steps went fi= ne. > > I rerun /sbin/lilo to update the loader and made a quick boot disk usin= g: > > dd if=3D/dev/sda2 of=3D/dev/fd0 ibs=3D1440 count=3D1 (sda2 is the parti= tion with xfs). > > Again there was no crashes or forced shutdowns...rebooted the box and w= hen=20 > > new kernel booted it showed these errors:=20 > >=20 > > XFS: bad magic number > > XFS: SB validate failed > > VFS: unable to mount block device on (8,2) or something close. > >=20 > > Again this is on Slackware Linux 8.0 with kernel 2.4.18 and gcc 2.95.3. > >=20 > > This is what xfs_repair shows: > >=20 > > xfs_repair -n /dev/sda2 > > Phase 1 - find and verify superblock... > > bad primary superblock - bad magic number !!! > >=20 > > attempting to find secondary superblock... > > .......................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ................! > ..! > > ....................found=20 > > candidate secondary superblock... > > verified secondary superblock... > > would write modified primary superblock > > primary superblock would have been modified. > > cannot proceed further in no_modify mode. > > exiting now. > >=20 > > I did not make any changes to the fs yet...how would i pull the first f= ew kb=20 > > off of the fs you mentioned earlier? Thanks again for your help. > >=20 > > Regards, > >=20 > > Paul > >=20=20 > --=20 > ph33r! > Linux mdew 2.4.18-xfs-preemptive #4 Sun Mar 24 21:44:59 NZST 2002 i686 > unknown >=20 --=20 ** Derek J Witt ** * Email: mailto:djw@flinthills.com * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** --=-qs6QSEOKtn+N9n/SVtaZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8n2uognGXTpcv6TgRAtlxAJ0QGt3E74qfR0t89mGsL8oNlU1Q2ACeMCrU 6uVXeepkO4K+9h5sS01zyvo= =Ibfv -----END PGP SIGNATURE----- --=-qs6QSEOKtn+N9n/SVtaZ-- From owner-linux-xfs@oss.sgi.com Mon Mar 25 12:47:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PKlGA28238 for linux-xfs-outgoing; Mon, 25 Mar 2002 12:47:16 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PKlAq28212 for ; Mon, 25 Mar 2002 12:47:11 -0800 Received: (qmail 5830 invoked by uid 500); 25 Mar 2002 20:48:55 -0000 Subject: Re: 2.4.18-xfs and RML's kernel-preempt (was: XFS latest changes, sb corruption?) From: Austin Gonyou To: Eric Sandeen Cc: Derek J Witt , linux-xfs@oss.sgi.com In-Reply-To: <1017075634.1738.4.camel@stout.americas.sgi.com> References: <1017075634.1738.4.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 25 Mar 2002 14:48:55 -0600 Message-Id: <1017089335.5458.16.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-25 at 11:00, Eric Sandeen wrote: > > I got a quick question about reading XFS partitions in Windows 2000. > Is > > there such a creature to allow me to do just that? > > No, no such option. > > -Eric Amen! -- 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 25 13:43:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PLhE729400 for linux-xfs-outgoing; Mon, 25 Mar 2002 13:43:14 -0800 Received: from saiya-jin.flinthills.com (root@saiya-jin.flinthills.com [64.39.192.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PLgaq29348 for ; Mon, 25 Mar 2002 13:42:36 -0800 Received: from saiya-jin.flinthills.com (cappicard@localhost [127.0.0.1]) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) with ESMTP id g2PLcLQf023613 for ; Mon, 25 Mar 2002 15:38:21 -0600 Received: (from cappicard@localhost) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) id g2PLcL7u023568; Mon, 25 Mar 2002 15:38:21 -0600 X-Authentication-Warning: saiya-jin.flinthills.com: cappicard set sender to djw@flinthills.com using -f Subject: [Fwd: lilo-xfs patch] From: Derek James Witt To: Linux XFS Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XnbtsFxaq9eHlAP+s5qg" X-Mailer: Evolution/1.0.2 Date: 25 Mar 2002 15:38:20 -0600 Message-Id: <1017092300.2173.13.camel@saiya-jin.flinthills.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-XnbtsFxaq9eHlAP+s5qg Content-Type: multipart/mixed; boundary="=-tKhJm7WifBIMvuaYW8kW" --=-tKhJm7WifBIMvuaYW8kW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable --=20 ** Derek J Witt ** * Email: mailto:djw@flinthills.com * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** --=-tKhJm7WifBIMvuaYW8kW Content-Disposition: inline Content-Description: Forwarded message - lilo-xfs patch Content-Type: message/rfc822 Return-Path: Received: from localhost (fetchmail@localhost [127.0.0.1]) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) with ESMTP id g2PLV3Qf008491 for ; Mon, 25 Mar 2002 15:31:03 -0600 Received: from konza.flinthills.com [64.39.200.1] by localhost with IMAP (fetchmail-5.9.10) for cappicard@localhost (single-drop); Mon, 25 Mar 2002 15:31:03 -0600 (CST) Received: from saiya-jin.flinthills.com (root@saiya-jin.flinthills.com [64.39.192.211]) by konza.flinthills.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2PLXAXQ008701 for ; Mon, 25 Mar 2002 15:33:10 -0600 (CST) Received: from saiya-jin.flinthills.com (cappicard@localhost [127.0.0.1]) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) with ESMTP id g2PLQWQf008468 for ; Mon, 25 Mar 2002 15:26:32 -0600 Received: (from cappicard@localhost) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) id g2PLQWTe008466; Mon, 25 Mar 2002 15:26:32 -0600 X-Authentication-Warning: saiya-jin.flinthills.com: cappicard set sender to djw@flinthills.com using -f Subject: lilo-xfs patch From: Derek James Witt To: Derek James Witt In-Reply-To: <1017080744.2172.6.camel@saiya-jin.flinthills.com> References: <20020324075637.4021C5C268@mail.blaze.homeip.net> <1016971074.7957.2.camel@mdew> <1017080744.2172.6.camel@saiya-jin.flinthills.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-jEbHx6gMtKp+AnIJ8x36" X-Mailer: Evolution/1.0.2 Date: 25 Mar 2002 15:26:32 -0600 Message-Id: <1017091592.2172.11.camel@saiya-jin.flinthills.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.8 required=5.0 tests=IN_REP_TO,FROM_AND_TO_SAME version=2.11 --=-jEbHx6gMtKp+AnIJ8x36 Content-Type: multipart/mixed; boundary="=-NrUu626SnNJjEkai4TRS" --=-NrUu626SnNJjEkai4TRS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey, everyone. I just hacked up a quick patch for lilo to behave correctly with XFS. This just checks the file system type of the current root partition. If XFS is detected, lilo aborts with an error. I also included a -F parameter to force XFS to install on XFS partitions. Let me know how this looks. On Mon, 2002-03-25 at 12:25, Derek James Witt wrote: > Hi, there. I got the same behavior. I found LILO does overwrite the XFS > superblock. Evidently, XFS's superblock even includes the boot sector. > So, could lilo be modified not to run on a XFS root partition? I can > try to modify lilo to include a XFS-detection routine and abort if XFS > is detected on root. I could also put in a parameter to override this > (if anyone would be bold enough to overwrite the SB). > On Sun, 2002-03-24 at 05:57, mdew wrote: > > Yeah I've checkout the CVS, and indeed its br0k3n... same Problem. > >=20 > > Debian Sid+Preemptive+GCC 3.0.4 > >=20 > > Once repairing the drive, its bootable again. > >=20 > >=20 > > On Sun, 2002-03-24 at 19:56, Paul Blazejowski wrote: > > > Hi Eric, > > >=20 > > > I have a bug i think...i was able to reproduce the sb corruption after > > > compiling new kernel. > > >=20 > > > Updated my xfs tree with todays CVS (no changes) then i generated a d= iff=20 > > > against clean 2.4.18 kernel patched with xfs and jfs patches,did make= dep=20 > > > then make bzImage followed by make modules...all of these steps went = fine. > > > I rerun /sbin/lilo to update the loader and made a quick boot disk us= ing: > > > dd if=3D/dev/sda2 of=3D/dev/fd0 ibs=3D1440 count=3D1 (sda2 is the par= tition with xfs). > > > Again there was no crashes or forced shutdowns...rebooted the box and= when=20 > > > new kernel booted it showed these errors:=20 > > >=20 > > > XFS: bad magic number > > > XFS: SB validate failed > > > VFS: unable to mount block device on (8,2) or something close. > > >=20 > > > Again this is on Slackware Linux 8.0 with kernel 2.4.18 and gcc 2.95.= 3. > > >=20 > > > This is what xfs_repair shows: > > >=20 > > > xfs_repair -n /dev/sda2 > > > Phase 1 - find and verify superblock... > > > bad primary superblock - bad magic number !!! > > >=20 > > > attempting to find secondary superblock... > > > .....................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ...........................................................................= ..................! > > ..! > > > ....................found=20 > > > candidate secondary superblock... > > > verified secondary superblock... > > > would write modified primary superblock > > > primary superblock would have been modified. > > > cannot proceed further in no_modify mode. > > > exiting now. > > >=20 > > > I did not make any changes to the fs yet...how would i pull the first= few kb=20 > > > off of the fs you mentioned earlier? Thanks again for your help. > > >=20 > > > Regards, > > >=20 > > > Paul > > >=20=20 > > --=20 > > ph33r! > > Linux mdew 2.4.18-xfs-preemptive #4 Sun Mar 24 21:44:59 NZST 2002 i686 > > unknown > >=20 > --=20 > ** Derek J Witt ** > * Email: mailto:djw@flinthills.com * > * Home Page: http://www.flinthills.com/~djw/ * > *** "...and on the eighth day, God met Bill Gates." - Unknown ** --=20 ** Derek J Witt ** * Email: mailto:djw@flinthills.com * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** --=-NrUu626SnNJjEkai4TRS Content-Disposition: attachment; filename=lilo-xfs.diff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --- lilo-22.2/lilo.c Sun Dec 30 16:10:26 2001 +++ lilo-xfs.c Mon Mar 25 15:17:53 2002 @@ -755,16 +755,49 @@ fprintf(errstd,"%7s%s -A /dev/XXX [ N ]\t\tactivate a partition\n","",= name); fprintf(errstd,"%7s%s -M /dev/XXX [ mbr_file ]\tinstall master boot re= cord\n","",name); fprintf(errstd,"%7s%s -T help \t\t\tlist additional options\n", "", na= me); + fprintf(errstd,"%7s%s -F \t\t\t\tforce install on XFS partition\n\t\t\= t\t\tWARNING: This will corrupt\n\t\t\t\t\tthe superblock on XFS partitions= .\n\n", "", name); fprintf(errstd,"%7s%s -V [ -v ]\t\t\tversion information\n\n","",name); exit(1); } =20 =20 +int is_xfs(char* device)=20 +{ + FILE* mounts;=20=20=20=20 + + if ((mounts =3D fopen("/etc/mtab", "r")) =3D=3D NULL)=20 + { /* Just some insurance. If this does not exists, there's something + seriously wrong here. How are you even in Linux in the first place? + */ + fprintf(errstd, "ERROR: I cannot find /etc/mtab! Nothing done.\n"); + exit(-1); + } + else + { + while (! feof(mounts)) + { + char mount_line[255],*fs_type,*mount_device,*mount_point; + fgets(mount_line, 255, mounts); + if (strlen(mount_line) =3D=3D 0) break; + mount_device =3D strtok(mount_line, " "); + mount_point =3D strtok(NULL, " "); + fs_type =3D strtok(NULL, " "); + if (fs_type =3D=3D NULL) break; + if ((strcmp(fs_type, "xfs") =3D=3D 0) && (strcmp(mount_device,device) = =3D=3D 0)) + return 1; + } + fclose(mounts); + } + return 0; +} + int main(int argc,char **argv) { char *name,*reboot_arg,*identify,*ident_opt,*new_root; char *tell_param, *uninst_dev, *param, *act1, *act2, ch; int query,more,version,uninstall,validate,activate,instmbr,geom; + int force_xfs; + char *boot_device =3D NULL; struct stat st; int fd; long raid_offset; @@ -775,6 +808,7 @@ reboot_arg =3D identify =3D ident_opt =3D new_root =3D uninst_dev =3D= NULL; lowest =3D do_md_install =3D zflag =3D query =3D version =3D uninstall =3D validate =3D activate =3D instmbr= =3D 0; + force_xfs =3D 0; verbose =3D -1; name =3D *argv; argc--; @@ -806,6 +840,9 @@ break; case 'b': cfg_set(cf_options,"boot",param,NULL); + boot_device =3D (char*)malloc((sizeof (char)) * 255); + strcpy(boot_device,param); + // if (is_xfs(boot_device) =3D=3D 1) die("root (%s) is XFS. Aborted.",b= oot_device); break; case 'c': cfg_set(cf_options,"compact",NULL,NULL); @@ -823,6 +860,11 @@ case 'f': cfg_set(cf_options,"disktab",param,NULL); break; + case 'F': + if (!nowarn) + fprintf(errstd,"WARNING: Forcing install on XFS partitions...\nBe pr= epared to run xfs_repair\non any XFS root partitions\nthat LILO selects as = boot.\n"); + force_xfs =3D 1; + break; case 'g': geometric |=3D 1; break; @@ -1104,6 +1146,13 @@ if (verbose >=3D2 && do_md_install) printf("raid flags: at bsect_open 0x%02X\n", raid_flags); =20 + if (boot_device =3D=3D NULL) + { + boot_device =3D (char*)malloc((sizeof (char)) * 255); + strcpy(boot_device,cfg_get_strg(cf_options,"boot")); + } + if ((is_xfs(boot_device) =3D=3D 1) && (force_xfs =3D=3D 0)) die("root (%s= ) is XFS. Aborted.",boot_device); +=09 bsect_open(cfg_get_strg(cf_options,"boot"),cfg_get_strg(cf_options,"map")= ? cfg_get_strg(cf_options,"map") : MAP_FILE,cfg_get_strg(cf_options, "install"),cfg_get_strg(cf_options,"delay") ? to_number(cfg_get_strg( --=-NrUu626SnNJjEkai4TRS-- --=-jEbHx6gMtKp+AnIJ8x36 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8n5YIgnGXTpcv6TgRAptsAJ9WfapYFGs2DsrftLYBXOgINPPAQgCfci4W CFdWRjd6XlIxY4rqcmKZsUs=3D =3DVYvz -----END PGP SIGNATURE----- --=-jEbHx6gMtKp+AnIJ8x36-- --=-tKhJm7WifBIMvuaYW8kW-- --=-XnbtsFxaq9eHlAP+s5qg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8n5jMgnGXTpcv6TgRAmdJAKCYWl3KDlk2iTVCH17VhkS2iI1FNACfb4dS aluNNg3+6kv86bjTfH+IAAs= =cTEp -----END PGP SIGNATURE----- --=-XnbtsFxaq9eHlAP+s5qg-- From owner-linux-xfs@oss.sgi.com Mon Mar 25 13:52:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PLq6k29641 for linux-xfs-outgoing; Mon, 25 Mar 2002 13:52:06 -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 g2PLq1q29609 for ; Mon, 25 Mar 2002 13:52:01 -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 g2PLsK6G023387 for ; Mon, 25 Mar 2002 13:54:20 -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 PAA38673; Mon, 25 Mar 2002 15:53: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 PAA38890; Mon, 25 Mar 2002 15:53:04 -0600 (CST) Subject: Re: [Fwd: lilo-xfs patch] From: Eric Sandeen To: Derek James Witt Cc: Linux XFS In-Reply-To: <1017092300.2173.13.camel@saiya-jin.flinthills.com> References: <1017092300.2173.13.camel@saiya-jin.flinthills.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 25 Mar 2002 15:53:04 -0600 Message-Id: <1017093184.1748.32.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Derek - Rather than parsing /etc/mtab, it would probably be better to look for "XFSB" in the first 4 bytes of the target partition - that way you _know_ the target has (or has had....) an xfs filesystem on it. -Eric On Mon, 2002-03-25 at 15:38, Derek James Witt wrote: > From: Derek James Witt > To: Derek James Witt > Subject: lilo-xfs patch > Date: 25 Mar 2002 15:26:32 -0600 > > Hey, everyone. I just hacked up a quick patch for lilo to behave > correctly with XFS. This just checks the file system type of the > current root partition. If XFS is detected, lilo aborts with an error. > I also included a -F parameter to force XFS to install on XFS > partitions. Let me know how this looks. > -- 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 25 14:55:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PMtVr00703 for linux-xfs-outgoing; Mon, 25 Mar 2002 14:55:31 -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 g2PMtRq00676 for ; Mon, 25 Mar 2002 14:55:27 -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 g2PNvjBA026389 for ; Mon, 25 Mar 2002 15:57:45 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA34824 for linux-xfs@oss.sgi.com; Tue, 26 Mar 2002 09:56:27 +1100 (EST) Date: Tue, 26 Mar 2002 09:56:27 +1100 (EST) From: Nathan Scott Message-Id: <200203252256.JAA34824@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 25 14:55:08 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:114846a linux/fs/quota.c - 1.9 - some updates from Jan in the new quota compatibility interface code. From owner-linux-xfs@oss.sgi.com Mon Mar 25 14:57:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PMv4l00871 for linux-xfs-outgoing; Mon, 25 Mar 2002 14:57:04 -0800 Received: from saiya-jin.flinthills.com (root@saiya-jin.flinthills.com [64.39.192.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PMuhq00841 for ; Mon, 25 Mar 2002 14:56:43 -0800 Received: from saiya-jin.flinthills.com (cappicard@localhost [127.0.0.1]) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) with ESMTP id g2PMqPQf030458 for ; Mon, 25 Mar 2002 16:52:25 -0600 Received: (from cappicard@localhost) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) id g2PMqPSe030456; Mon, 25 Mar 2002 16:52:25 -0600 X-Authentication-Warning: saiya-jin.flinthills.com: cappicard set sender to djw@flinthills.com using -f Subject: Re: [Fwd: lilo-xfs patch] From: Derek James Witt To: Linux XFS In-Reply-To: <1017093184.1748.32.camel@stout.americas.sgi.com> References: <1017092300.2173.13.camel@saiya-jin.flinthills.com> <1017093184.1748.32.camel@stout.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cOzvY6JJkswPwgvV9tWz" X-Mailer: Evolution/1.0.2 Date: 25 Mar 2002 16:52:25 -0600 Message-Id: <1017096745.2172.18.camel@saiya-jin.flinthills.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-cOzvY6JJkswPwgvV9tWz Content-Type: multipart/mixed; boundary="=-E3OV9iMAwk6Ln+NS+iY5" --=-E3OV9iMAwk6Ln+NS+iY5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Eric. Thanks for the suggestion. That made it cleaner. Here's the new patch. On Mon, 2002-03-25 at 15:53, Eric Sandeen wrote: > hi Derek -=20 >=20 > Rather than parsing /etc/mtab, it would probably be better to look for > "XFSB" in the first 4 bytes of the target partition - that way you > _know_ the target has (or has had....) an xfs filesystem on it. >=20 > -Eric >=20 > --=20 > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. --=20 ** Derek J Witt ** * Email: mailto:djw@flinthills.com * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** --=-E3OV9iMAwk6Ln+NS+iY5 Content-Disposition: attachment; filename=lilo-xfs.diff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --- lilo.c Sun Dec 30 16:10:26 2001 +++ ../lilo-xfs.c Mon Mar 25 16:43:40 2002 @@ -755,16 +755,40 @@ fprintf(errstd,"%7s%s -A /dev/XXX [ N ]\t\tactivate a partition\n","",= name); fprintf(errstd,"%7s%s -M /dev/XXX [ mbr_file ]\tinstall master boot re= cord\n","",name); fprintf(errstd,"%7s%s -T help \t\t\tlist additional options\n", "", na= me); + fprintf(errstd,"%7s%s -F \t\t\t\tforce install on XFS partition\n\t\t\= t\t\tWARNING: This will corrupt\n\t\t\t\t\tthe superblock on XFS partitions= .\n\n", "", name); fprintf(errstd,"%7s%s -V [ -v ]\t\t\tversion information\n\n","",name); exit(1); } =20 =20 +int is_xfs(char* device)=20 +{ + FILE* mounts; + unsigned char xfs_sig[] =3D {'X','F','S','B'}; + int got_xfs =3D 1, i; + + if ((mounts =3D fopen(device, "rb")) =3D=3D NULL)=20 + { /* Just some insurance. If this does not exists, there's something + seriously wrong here. How are you even in Linux in the first place? + */ + die("ERROR: I cannot find %s! Nothing done.\n",device); + } + + for (i =3D 0; (i < 4) && (got_xfs =3D=3D 1); i++)=20 + if (xfs_sig[i] =3D=3D fgetc(mounts)) got_xfs =3D 1; else got_xfs =3D= 0; + + fclose(mounts); + + return got_xfs; +} + int main(int argc,char **argv) { char *name,*reboot_arg,*identify,*ident_opt,*new_root; char *tell_param, *uninst_dev, *param, *act1, *act2, ch; int query,more,version,uninstall,validate,activate,instmbr,geom; + int force_xfs; + char *boot_device =3D NULL; struct stat st; int fd; long raid_offset; @@ -775,6 +799,7 @@ reboot_arg =3D identify =3D ident_opt =3D new_root =3D uninst_dev =3D= NULL; lowest =3D do_md_install =3D zflag =3D query =3D version =3D uninstall =3D validate =3D activate =3D instmbr= =3D 0; + force_xfs =3D 0; verbose =3D -1; name =3D *argv; argc--; @@ -806,6 +831,8 @@ break; case 'b': cfg_set(cf_options,"boot",param,NULL); + boot_device =3D (char*)malloc((sizeof (char)) * 255); + strcpy(boot_device,param); break; case 'c': cfg_set(cf_options,"compact",NULL,NULL); @@ -823,6 +850,11 @@ case 'f': cfg_set(cf_options,"disktab",param,NULL); break; + case 'F': + if (!nowarn) + fprintf(errstd,"WARNING: Forcing install on XFS partitions...\nBe pr= epared to run xfs_repair\non any XFS root partitions\nthat LILO selects as = boot.\n"); + force_xfs =3D 1; + break; case 'g': geometric |=3D 1; break; @@ -1104,6 +1136,13 @@ if (verbose >=3D2 && do_md_install) printf("raid flags: at bsect_open 0x%02X\n", raid_flags); =20 + if (boot_device =3D=3D NULL) + { + boot_device =3D (char*)malloc((sizeof (char)) * 255); + strcpy(boot_device,cfg_get_strg(cf_options,"boot")); + } + if ((is_xfs(boot_device) =3D=3D 1) && (force_xfs =3D=3D 0)) die("root (%s= ) is XFS. Aborted.",boot_device); +=09 bsect_open(cfg_get_strg(cf_options,"boot"),cfg_get_strg(cf_options,"map")= ? cfg_get_strg(cf_options,"map") : MAP_FILE,cfg_get_strg(cf_options, "install"),cfg_get_strg(cf_options,"delay") ? to_number(cfg_get_strg( --=-E3OV9iMAwk6Ln+NS+iY5-- --=-cOzvY6JJkswPwgvV9tWz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8n6opgnGXTpcv6TgRAukEAJ4oy7P8iyTeDF973fS4M8YOyjKtowCggtxG wOvBz2bzZzIhPPrI1rSmlZE= =nuxL -----END PGP SIGNATURE----- --=-cOzvY6JJkswPwgvV9tWz-- From owner-linux-xfs@oss.sgi.com Mon Mar 25 15:04:41 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PN4fd01150 for linux-xfs-outgoing; Mon, 25 Mar 2002 15:04:41 -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 g2PN4dq01124 for ; Mon, 25 Mar 2002 15:04:39 -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 PAA22392 for ; Mon, 25 Mar 2002 15:07:03 -0800 User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Mon, 25 Mar 2002 15:07:04 -0800 Subject: Pgcc 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 I haven't seen anyone on this list talk about compiling with pgcc instead of gcc. Has there been any work done on compiling with pgcc? Thanks, Gabe From owner-linux-xfs@oss.sgi.com Mon Mar 25 15:37:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PNbWX01929 for linux-xfs-outgoing; Mon, 25 Mar 2002 15:37:32 -0800 Received: from apollo.digitalpictures.com.au (mail.digitalpictures.com.au [203.29.89.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2PNbJq01899 for ; Mon, 25 Mar 2002 15:37:19 -0800 Received: by apollo.digitalpictures.com.au with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 10:36:05 +1100 Received: from digitalpictures.com.au (owl.digitalpictures.com.au [172.30.24.41]) by apollo.digitalpictures.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F5AVWMYN; Tue, 26 Mar 2002 10:35:53 +1100 From: "Monton, Nick" To: linux-xfs@oss.sgi.com Message-ID: <3C9F6F17.515978F@digitalpictures.com.au> Date: Mon, 25 Mar 2002 10:40:23 -0800 Organization: dps/aav X-Mailer: Mozilla 4.77C-SGI [en] (X11; I; IRIX64 6.5 IP28) X-Accept-Language: en MIME-Version: 1.0 Subject: incorrect file listings References: <200203211655.g2LGtDH30395@stout.americas.sgi.com> Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk has anybody else experienced this / discovered a work around ? SERVER: platform: Linux i386 kernel: 2.4.17 xfspatch: 1.0.1 (for 2.4.17) samba: 2.2.3a-6 nfs-server: 2.2beta47-4 I create a list of files (500 total) in a directory on the xfs file system. samba is exporting this directory, nfs is also exporting this directory. via win2k (samba/smb) a total of around 8 files are missing. via nfs3(irix 6.5.11) around 20 files are missing. according to the local file system (xfs1.0.1) all these files are present. I can correct the nfs3 problem by dropping the mount point down to nfs2. the only reason I assume that this may be an xfs problem is that an export from the same system which originates on an ext2 partition, mounted via samba or nfs(3) does not fail to display files. the command I used to create the xfs file system was: mkfs -t xfs -l internal,size=8000b -d name=/dev/sda1 this is being created on a 250gb hardware raid. originally the drive was partitioned on an SGI Octane (irix 6.5.11) the file system was however created on the above linux server. regards, nick monton. here is some extra machine information which may help: ---uname -a Linux aardvark 2.4.17-xfs #10 SMP Sun Mar 24 22:37:50 EST 2002 i686 unknown ---fdisk -ul /dev/sda Disk /dev/sda (SGI disk label): 128 heads, 128 sectors, 8 cylinders Units = sectors of 1 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 8: /dev/sda1 4096 468959231 468955136 a SGI xfs 9: /dev/sda2 0 4095 4096 0 SGI volhdr 11: /dev/sda3 0 468959231 468959232 6 SGI volume ----- Bootinfo ----- Bootfile: /unix ----- Directory Entries ----- df -k /DPS_RAID (local mount) Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda1 234445568 61440380 173005188 26% /DPS_RAID --df -k /projects (nfs3 mount) (irix 6.5.11) Filesystem Type kbytes use avail %use Mounted on aardvark:/DPS_RAID nfs 234445568 61440380 173005188 27 /projects [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Mar 25 15:53:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2PNrOu02227 for linux-xfs-outgoing; Mon, 25 Mar 2002 15:53: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 g2PNrKq02185 for ; Mon, 25 Mar 2002 15:53: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 g2PNtc6G029381 for ; Mon, 25 Mar 2002 15:55:38 -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 RAA38417; Mon, 25 Mar 2002 17:54:23 -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 RAA41481; Mon, 25 Mar 2002 17:54:22 -0600 (CST) Subject: Re: incorrect file listings From: Eric Sandeen To: "Monton, Nick" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3C9F6F17.515978F@digitalpictures.com.au> References: <200203211655.g2LGtDH30395@stout.americas.sgi.com> <3C9F6F17.515978F@digitalpictures.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 25 Mar 2002 17:54:22 -0600 Message-Id: <1017100463.9366.40.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-25 at 12:40, Monton, Nick wrote: > via win2k (samba/smb) a total of around 8 files are missing. > via nfs3(irix 6.5.11) around 20 files are missing. > according to the local file system (xfs1.0.1) all these files are > present. > > > I can correct the nfs3 problem by dropping the mount point down to nfs2. > The nfs thing is not xfs related, it's a known bug in irix nfs. Can you reproduce the samba problem with smbclient? -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 25 17:23:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2Q1Ng703620 for linux-xfs-outgoing; Mon, 25 Mar 2002 17:23:42 -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 g2Q1Naq03594 for ; Mon, 25 Mar 2002 17:23:36 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2Q2PsBA000511 for ; Mon, 25 Mar 2002 18:25:55 -0800 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA44378; Tue, 26 Mar 2002 12:24:35 +1100 (AEDT) Date: Tue, 26 Mar 2002 12:24:34 +1100 From: Timothy Shimmin To: James Pearson Cc: linux-xfs@oss.sgi.com, seth.mos@xs4all.nl Subject: Re: NFS and umask Message-ID: <20020326122434.F5356@boing.melbourne.sgi.com> References: <3C98A887.C4E1FFCD@moving-picture.com> <20020325162044.C5356@boing.melbourne.sgi.com> <3C9F09A7.326376DF@moving-picture.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3C9F09A7.326376DF@moving-picture.com>; from james-p@moving-picture.com on Mon, Mar 25, 2002 at 11:27:35AM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk James, On Mon, Mar 25, 2002 at 11:27:35AM +0000, James Pearson wrote: > Thanks for the info - given that the XFS 1.0.2 v2.4.14-xfs kernel was > available before January 10 2002, then, I assume, disabling ACLs will > make no difference with this kernel? I believe so. > > As our users have a default umask of 2, setting the default ACL > equivalent to a directory with '0775' seems to be a suitable work round > for the time being ... does this sound like a sensible thing to do? Sounds reasonable to me. (If you have a default ACL then the permissions get intersected with the permissions parameters of the syscall for creation) > I notice there is nothing in the XFS FAQ about this problem - in fact > the FAQ states: > 'So far there are no more known problems with XFS and NFS since then > (mid-march 2001)' Good point. --Tim > Timothy Shimmin wrote: > > On Wed, Mar 20, 2002 at 03:19:35PM +0000, James Pearson wrote: > > > I've just had the problem with mkdir ignoring umask when creating > > > directories on Linux XFS file systems mounted over NFS. > > > I'm using XFS 1.0.2 with kernel 2.4.14-xfs > > > Searching the archives, shows that this is a known issue - but are there > > > any workarounds/fixes? > > This is probably related to a bug with the handling of > > the umask in the XFS/ACL code. > > (if a default ACL doesn't exist then xfs incorrectly applies > > the umask in the nfsd case) > > With ACLs disabled, this bug was fixed in the xfs-kernel > > on January 10 2002. > > With ACLs enabled, this bug still exists and > > possible solutions are currently being discussed. From owner-linux-xfs@oss.sgi.com Mon Mar 25 17:37:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2Q1bBk03886 for linux-xfs-outgoing; Mon, 25 Mar 2002 17:37:11 -0800 Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2Q1axq03859 for ; Mon, 25 Mar 2002 17:36:59 -0800 Received: from slc-unislc.slc.unisys.com ([192.60.174.32]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id BAA03466 for ; Tue, 26 Mar 2002 01:38:23 GMT Received: from localhost.localdomain (slc-knysna.slc.unisys.com [192.60.130.30]) by slc-unislc.slc.unisys.com (8.9.3/UW7.1.1) with ESMTP id SAA19589 for ; Mon, 25 Mar 2002 18:39:21 -0700 (MST) Received: from there (slc-knysna [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with SMTP id g2Q1dKR03578 for ; Mon, 25 Mar 2002 18:39:20 -0700 Message-Id: <200203260139.g2Q1dKR03578@localhost.localdomain> Content-Type: text/plain; charset="iso-8859-1" From: Warren Stockton Reply-To: wns@slc.unisys.com To: linux-xfs@oss.sgi.com Subject: xfsprogs-2.0.1-0.ia64.rpm - mkfs.xfs fails to create a filesystem Date: Mon, 25 Mar 2002 18:39:20 -0700 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Is the following a known problem? I am running a kernel built from kernel-2.4.9-31SGI_XFS_1.1_PR2.src.rpm on ia64. When I installed the new kernel I also removed the previous acl-1.1.3-0 , dmapi-0.2.2-0 and xfsprogs-1.3.13.-0 rpms and installed the new rpms. Everything was going pretty well until I tried to add some new drives. The error messages are below: I found that if remove the xfsprogs-2.0.1 and install the older xfsprogs-1.3.13 I can again make filesystems. The controller in question is running the qla2200 driver: qla2x00: Found VID=1077 DID=2200 SSVID=1077 SSDID=2 scsi3: Found a QLA2200 @ bus 10, device 0x1, irq 53, iobase 0x1300 scsi(3): Configure NVRAM parameters... scsi(3): Verifying loaded RISC code... scsi(3): Verifying chip... Firmware version: 2.01.35, Driver version 5.31.RH1 The drive in question is as follows: blk: queue e0000000ed7afbf0, no I/O memory limit Vendor: SEAGATE Model: ST318304 CLAR18 Rev: 3B85 Type: Direct-Access ANSI SCSI revision: 03 I have tried different qla2200 controllers and different drives (including RAID volumes) and all give the same error. Ouput of mkfs.xfs 2.0.1 ================= # mkfs.xfs -V mkfs.xfs version 2.0.1 # mkfs.xfs -f /dev/sd/c3b0t0u0p5 can't get size of data subvolume Usage: mkfs.xfs /* blocksize */ [-b log=n|size=num] /* data subvol */ [-d agcount=n,agsize=n,file,name=xxx,size=num, sunit=value,swidth=value,unwritten=0|1, su=value,sw=value] /* inode size */ [-i log=n|perblock=n|size=num,maxpct=n] /* log subvol */ [-l agnum=n,internal,size=num,logdev=xxx] /* naming */ [-n log=n|size=num|version=n] /* label */ [-L label (maximum 12 characters)] /* prototype file */ [-p fname] /* quiet */ [-q] /* version */ [-V] /* realtime subvol */ [-r extsize=num,size=num,rtdev=xxx] devicename is required unless -d name=xxx is given. Internal log by default, size is scaled from 1,000 blocks to 32,768 blocks based on the filesystem size. Default log reaches its largest size at 1TB. This can be overridden with the -l options or using a volume manager with a log subvolume. is xxx (bytes), or xxxb (blocks), or xxxk (xxx KB), or xxxm (xxx MB) is xxx (512 blocks). Output of mkfs.xfs 1.3.13 ================== # mkfs.xfs -V mkfs.xfs version 1.3.13 no device name given in argument list Usage: mkfs.xfs /* blocksize */ [-b log=n|size=num] /* data subvol */ [-d agcount=n,agsize=n,file,name=xxx,size=num, sunit=value,swidth=value,unwritten=0|1, su=value,sw=value] /* inode size */ [-i log=n|perblock=n|size=num,maxpct=n] /* log subvol */ [-l agnum=n,internal,size=num,logdev=xxx] /* naming */ [-n log=n|size=num|version=n] /* label */ [-L label (maximum 12 characters)] /* prototype file */ [-p fname] /* quiet */ [-q] /* version */ [-V] /* realtime subvol */ [-r extsize=num,size=num,rtdev=xxx] devicename is required unless -d name=xxx is given. Internal log by default, size is scaled from 1,000 blocks to 32,768 blocks based on the filesystem size. Default log reaches its largest size at 1TB. This can be overridden with the -l options or using a volume manager with a log subvolume. is xxx (bytes), or xxxb (blocks), or xxxk (xxx KB), or xxxm (xxx MB) is xxx (512 blocks). # mkfs.xfs -f /dev/sd/c3b0t0u0p5 meta-data=/dev/sd/c3b0t0u0p5 isize=256 agcount=17, agsize=65536 blks data = bsize=16384 blocks=1088399, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 = imaxbits=27 naming =version 2 bsize=16384 log =internal log bsize=16384 blocks=1000 realtime =none extsz=65536 blocks=0, rtextents=0 From owner-linux-xfs@oss.sgi.com Mon Mar 25 19:21:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2Q3LcY05595 for linux-xfs-outgoing; Mon, 25 Mar 2002 19:21: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 g2Q3LXq05569 for ; Mon, 25 Mar 2002 19:21: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 g2Q4NoBA004926 for ; Mon, 25 Mar 2002 20:23:50 -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 VAA41033; Mon, 25 Mar 2002 21:22: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 VAA89399; Mon, 25 Mar 2002 21:22:34 -0600 (CST) Date: Mon, 25 Mar 2002 21:22:34 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Warren Stockton cc: Subject: Re: xfsprogs-2.0.1-0.ia64.rpm - mkfs.xfs fails to create a filesystem In-Reply-To: <200203260139.g2Q1dKR03578@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 25 Mar 2002, Warren Stockton wrote: > Everything was going pretty well until I tried to add some new drives. The > error messages are below: I found that if remove the xfsprogs-2.0.1 and > install the older xfsprogs-1.3.13 I can again make filesystems. mkfs 2.0+ tries to use BLKGETSIZE64 and falls back to BLKGETSIZE if that fails, I thought this was working... Can you run mkfs.xfs through strace to see if it's encountering any errors? strace -omkfs.strace.output mkfs.xfs and the output goes to mkfs.strace.output -Eric From owner-linux-xfs@oss.sgi.com Mon Mar 25 19:55:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2Q3t2406019 for linux-xfs-outgoing; Mon, 25 Mar 2002 19:55:02 -0800 Received: from saiya-jin.flinthills.com (root@saiya-jin.flinthills.com [64.39.192.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2Q3sdq05984 for ; Mon, 25 Mar 2002 19:54:40 -0800 Received: from saiya-jin.flinthills.com (cappicard@localhost [127.0.0.1]) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) with ESMTP id g2Q3oFQf003076 for ; Mon, 25 Mar 2002 21:50:15 -0600 Received: (from cappicard@localhost) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) id g2Q3oEtS003074; Mon, 25 Mar 2002 21:50:14 -0600 X-Authentication-Warning: saiya-jin.flinthills.com: cappicard set sender to djw@flinthills.com using -f Subject: superblocks and lilo From: Derek James Witt To: Linux XFS In-Reply-To: <1017096745.2172.18.camel@saiya-jin.flinthills.com> References: <1017092300.2173.13.camel@saiya-jin.flinthills.com> <1017093184.1748.32.camel@stout.americas.sgi.com> <1017096745.2172.18.camel@saiya-jin.flinthills.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-p+H/R6XmJVuUkSvKPx9N" X-Mailer: Evolution/1.0.2 Date: 25 Mar 2002 21:50:14 -0600 Message-Id: <1017114614.1754.6.camel@saiya-jin.flinthills.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-p+H/R6XmJVuUkSvKPx9N Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hey all. I'm going through the kernel source for XFS and I'm trying to find out how many superblocks a partition usually has and the maximum it's allowed to have. So far in xfs_mount.h, I'm seeing that we are allowed two superblocks. I am proposing that we have two consecutive primary superblocks (duplicates) in use. In other words, mirrored blocks.=20 So, if lilo or any other boot loader comes along and overwrites a part of the first superblock, the mounting code can still get at the 2nd sb. But, the problem is that the size of the superblock I've seen varies from 512 bytes to 65535 bytes. In lilo's sources, we got blocks of size 1024 and sector sizes of 512. Any ideas on what to do on this? On Mon, 2002-03-25 at 16:52, Derek James Witt wrote: > Hi, Eric. Thanks for the suggestion. That made it cleaner. Here's the > new patch. >=20 > On Mon, 2002-03-25 at 15:53, Eric Sandeen wrote: > > hi Derek -=20 > >=20 > > Rather than parsing /etc/mtab, it would probably be better to look for > > "XFSB" in the first 4 bytes of the target partition - that way you > > _know_ the target has (or has had....) an xfs filesystem on it. > >=20 > > -Eric > >=20 > > --=20 > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > sandeen@sgi.com SGI, Inc. > --=20 > ** Derek J Witt ** > * Email: mailto:djw@flinthills.com * > * Home Page: http://www.flinthills.com/~djw/ * > *** "...and on the eighth day, God met Bill Gates." - Unknown ** > ---- >=20 > --- lilo.c Sun Dec 30 16:10:26 2001 > +++ ../lilo-xfs.c Mon Mar 25 16:43:40 2002 > @@ -755,16 +755,40 @@ > fprintf(errstd,"%7s%s -A /dev/XXX [ N ]\t\tactivate a partition\n","= ",name); > fprintf(errstd,"%7s%s -M /dev/XXX [ mbr_file ]\tinstall master boot = record\n","",name); > fprintf(errstd,"%7s%s -T help \t\t\tlist additional options\n", "", = name); > + fprintf(errstd,"%7s%s -F \t\t\t\tforce install on XFS partition\n\t\= t\t\t\tWARNING: This will corrupt\n\t\t\t\t\tthe superblock on XFS partitio= ns.\n\n", "", name); > fprintf(errstd,"%7s%s -V [ -v ]\t\t\tversion information\n\n","",nam= e); > exit(1); > } >=20=20 >=20=20 > +int is_xfs(char* device)=20 > +{ > + FILE* mounts; > + unsigned char xfs_sig[] =3D {'X','F','S','B'}; > + int got_xfs =3D 1, i; > + > + if ((mounts =3D fopen(device, "rb")) =3D=3D NULL)=20 > + { /* Just some insurance. If this does not exists, there's somethi= ng > + seriously wrong here. How are you even in Linux in the first place? > + */ > + die("ERROR: I cannot find %s! Nothing done.\n",device); > + } > + > + for (i =3D 0; (i < 4) && (got_xfs =3D=3D 1); i++)=20 > + if (xfs_sig[i] =3D=3D fgetc(mounts)) got_xfs =3D 1; else got_xfs = =3D 0; > + > + fclose(mounts); > + > + return got_xfs; > +} > + > int main(int argc,char **argv) > { > char *name,*reboot_arg,*identify,*ident_opt,*new_root; > char *tell_param, *uninst_dev, *param, *act1, *act2, ch; > int query,more,version,uninstall,validate,activate,instmbr,geom; > + int force_xfs; > + char *boot_device =3D NULL; > struct stat st; > int fd; > long raid_offset; > @@ -775,6 +799,7 @@ > reboot_arg =3D identify =3D ident_opt =3D new_root =3D uninst_dev = =3D NULL; > lowest =3D do_md_install =3D zflag =3D > query =3D version =3D uninstall =3D validate =3D activate =3D instm= br =3D 0; > + force_xfs =3D 0; > verbose =3D -1; > name =3D *argv; > argc--; > @@ -806,6 +831,8 @@ > break; > case 'b': > cfg_set(cf_options,"boot",param,NULL); > + boot_device =3D (char*)malloc((sizeof (char)) * 255); > + strcpy(boot_device,param); > break; > case 'c': > cfg_set(cf_options,"compact",NULL,NULL); > @@ -823,6 +850,11 @@ > case 'f': > cfg_set(cf_options,"disktab",param,NULL); > break; > + case 'F': > + if (!nowarn) > + fprintf(errstd,"WARNING: Forcing install on XFS partitions...\nBe = prepared to run xfs_repair\non any XFS root partitions\nthat LILO selects a= s boot.\n"); > + force_xfs =3D 1; > + break; > case 'g': > geometric |=3D 1; > break; > @@ -1104,6 +1136,13 @@ > if (verbose >=3D2 && do_md_install) > printf("raid flags: at bsect_open 0x%02X\n", raid_flags); >=20=20 > + if (boot_device =3D=3D NULL) > + { > + boot_device =3D (char*)malloc((sizeof (char)) * 255); > + strcpy(boot_device,cfg_get_strg(cf_options,"boot")); > + } > + if ((is_xfs(boot_device) =3D=3D 1) && (force_xfs =3D=3D 0)) die("root (= %s) is XFS. Aborted.",boot_device); > +=09 > bsect_open(cfg_get_strg(cf_options,"boot"),cfg_get_strg(cf_options,"map= ") ? > cfg_get_strg(cf_options,"map") : MAP_FILE,cfg_get_strg(cf_options, > "install"),cfg_get_strg(cf_options,"delay") ? to_number(cfg_get_strg( --=20 ** Derek J Witt ** * Email: mailto:djw@flinthills.com * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** --=-p+H/R6XmJVuUkSvKPx9N Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8n+/2gnGXTpcv6TgRAhBwAJwOrKfC5Zz2Y/n66zRJHALw/9RwxgCgtuB3 uzhDIhOvpjIuHAgHgYjfK68= =/mML -----END PGP SIGNATURE----- --=-p+H/R6XmJVuUkSvKPx9N-- From owner-linux-xfs@oss.sgi.com Mon Mar 25 20:31:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2Q4Ve206523 for linux-xfs-outgoing; Mon, 25 Mar 2002 20:31:40 -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 g2Q4VZq06497 for ; Mon, 25 Mar 2002 20:31:35 -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 g2Q5gNkw016502 for ; Mon, 25 Mar 2002 23:42:25 -0600 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA84437 for linux-xfs@oss.sgi.com; Tue, 26 Mar 2002 15:32:33 +1100 (EST) Date: Tue, 26 Mar 2002 15:32:33 +1100 (EST) From: Nathan Scott Message-Id: <200203260432.PAA84437@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - attr man page updates Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 25 20:30:40 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:114877a cmd/attr/doc/CHANGES - 1.20 cmd/attr/debian/changelog - 1.18 - bump release number for man page and MIPS syscall updates. cmd/attr/man/man1/Makefile - 1.4 cmd/attr/man/man2/Makefile - 1.5 cmd/attr/man/man3/Makefile - 1.5 cmd/attr/man/man5/Makefile - 1.4 - minor updates, keeping in sync with acl and other packages. cmd/attr/man/man3/attr_list.3 - 1.5 cmd/attr/man/man3/attr_set.3 - 1.5 cmd/attr/man/man3/attr_get.3 - 1.5 cmd/attr/man/man3/attr_multi.3 - 1.5 cmd/attr/man/man3/attr_remove.3 - 1.5 - formatting consistency changes. From owner-linux-xfs@oss.sgi.com Mon Mar 25 20:55:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2Q4twh06958 for linux-xfs-outgoing; Mon, 25 Mar 2002 20:55: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 g2Q4toq06929 for ; Mon, 25 Mar 2002 20:55:50 -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 g2Q4w76G007840 for ; Mon, 25 Mar 2002 20:58:08 -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 PAA23297; Tue, 26 Mar 2002 15:56:51 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA45982; Tue, 26 Mar 2002 15:56:50 +1100 (AEDT) Date: Tue, 26 Mar 2002 15:56:49 +1100 From: Nathan Scott To: Derek James Witt Cc: Linux XFS Subject: Re: superblocks and lilo Message-ID: <20020326155649.C45001@wobbly.melbourne.sgi.com> References: <1017092300.2173.13.camel@saiya-jin.flinthills.com> <1017093184.1748.32.camel@stout.americas.sgi.com> <1017096745.2172.18.camel@saiya-jin.flinthills.com> <1017114614.1754.6.camel@saiya-jin.flinthills.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1017114614.1754.6.camel@saiya-jin.flinthills.com>; from djw@flinthills.com on Mon, Mar 25, 2002 at 09:50:14PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Mar 25, 2002 at 09:50:14PM -0600, Derek James Witt wrote: > Hey all. > > I'm going through the kernel source for XFS and I'm trying to find out > how many superblocks a partition usually has and the maximum it's > allowed to have. There is one superblock at the head of every allocation group. xfs_info/xfs_db/... will show you how many allocation groups a filesystem has. There is one primary superblock, in the first AG (at offset zero); and any number of secondary superblocks - the number of AGs is a mkfs time option. The primary superblock is the one the kernel uses at all times. The secondary superblocks are usually only written at mkfs time, and are read by xfs_repair when reconstructing the primary SB. > So far in xfs_mount.h, I'm seeing that we are allowed > two superblocks. I am proposing that we have two consecutive primary > superblocks (duplicates) in use. In other words, mirrored blocks. I'll leave it for others to judge the relative merits of this, my first thought is that it seems overly complex when the answer should be "don't overwrite the SB in the first place". > So, if lilo or any other boot loader comes along and overwrites a part > of the first superblock, the mounting code can still get at the 2nd sb. I think the operational model here should remain "run xfs_repair" once you've blown your foot off... but, just my 2c. > But, the problem is that the size of the superblock I've seen varies > from 512 bytes to 65535 bytes. In lilo's sources, we got blocks of size > 1024 and sector sizes of 512. Any ideas on what to do on this? The XFS superblock fits within 512 bytes. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Mar 25 22:35:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2Q6Ze208073 for linux-xfs-outgoing; Mon, 25 Mar 2002 22:35:40 -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 g2Q6Zaq08047 for ; Mon, 25 Mar 2002 22:35:36 -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 g2Q7bsBA009997 for ; Mon, 25 Mar 2002 23:37:54 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA94856 for linux-xfs@oss.sgi.com; Tue, 26 Mar 2002 17:36:37 +1100 (EST) Date: Tue, 26 Mar 2002 17:36:37 +1100 (EST) From: Nathan Scott Message-Id: <200203260636.RAA94856@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - compiler warnings Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Mar 25 22:35:12 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:114879a linux/fs/xfs/xfsidbg.c - 1.176 linux/fs/xfs/xfs_mount.c - 1.275 linux/fs/xfs/linux/xfs_lrw.c - 1.128 linux/fs/xfs/linux/xfs_xattr.c - 1.8 - fix some compiler warnings on 64 bit platforms. From owner-linux-xfs@oss.sgi.com Tue Mar 26 02:15:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QAFms13064 for linux-xfs-outgoing; Tue, 26 Mar 2002 02:15:48 -0800 Received: from itcampus.de (www.itcampus.de [194.45.97.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QAFfq13038 for ; Tue, 26 Mar 2002 02:15:41 -0800 Received: from [62.16.184.226] (account twinkler HELO janus.lpz.itcampus.de) by itcampus.de (CommuniGate Pro SMTP 3.5.4) with ESMTP-TLS id 325297 for linux-xfs@oss.sgi.com; Tue, 26 Mar 2002 11:18:02 +0100 Subject: Re: default acl on directory problem From: Thomas Winkler To: linux-xfs@oss.sgi.com In-Reply-To: <20020325160807.B5356@boing.melbourne.sgi.com> References: <1016808160.5266.19.camel@janus> <20020325160807.B5356@boing.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Mar 2002 11:18:00 +0100 Message-Id: <1017137882.1405.13.camel@janus> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Am Mon, 2002-03-25 um 06.08 schrieb Timothy Shimmin: > Looking at getfacl(1), the "#effective" comment refers > to the effect the mask ACE has on all groups and named user > ACEs whose permissions are reduced. > In your case, your mask ACE is "r-x" so this will > potentially reduce permissions for group and named-user ACEs. > I guess the comment is there as a reminder of what the mask ACE is doing. > > So did you have a different command to set the acl for "otheruser" > which had a different mask ACE ??? since we are running many systems on xfs for quite a while now i had some more machines i was able to test. it seems as if this problem only occurs on 1 out of 3 systems i tried with. all are running the same kernel. first i thought i did forget to update all xfs related progs (acl, attr, xfsprogs...) but nothing changed after an update to the versions from the 2.4.16 kernel. now i am kind of lost. it seems to work the way i want it to, but unfortunatelay not on the system it has to. i also checked kernel settings and umask entries for the users. what could cause this behaviour? now i am using (all devels installed): xfsprogs-1.3.19-0 attr-2.0.0-0 acl-1.1.4-0 dmapi-0.3.0-0 are there any known issues? could find any on my list archives... > BTW, general userland ACL questions are best sent to > acl-devel@bestbits.at (check out: http://acl.bestbits.at/) > now that we're using common userspace code for ext2, ext3 and XFS. yes, but i searched lots of places and could only find solaris questions, concerning the same behaviour. in this cases it where bugs, thats why i asked here. i am sorry... > Cheers, > --Tim > thank you thomas From owner-linux-xfs@oss.sgi.com Tue Mar 26 02:36:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QAauH13532 for linux-xfs-outgoing; Tue, 26 Mar 2002 02:36:56 -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 g2QAapq13506 for ; Tue, 26 Mar 2002 02:36:52 -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 16poLt-0000r0-00; Tue, 26 Mar 2002 10:38:53 +0000 Message-ID: <3CA04FBD.F206F8DB@moving-picture.com> Date: Tue, 26 Mar 2002 10:38:53 +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: Eric Sandeen CC: "Monton, Nick" , linux-xfs@oss.sgi.com Subject: Re: incorrect file listings References: <200203211655.g2LGtDH30395@stout.americas.sgi.com> <3C9F6F17.515978F@digitalpictures.com.au> <1017100463.9366.40.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > On Mon, 2002-03-25 at 12:40, Monton, Nick wrote: > > > via win2k (samba/smb) a total of around 8 files are missing. > > via nfs3(irix 6.5.11) around 20 files are missing. > > according to the local file system (xfs1.0.1) all these files are > > present. > > > > > > I can correct the nfs3 problem by dropping the mount point down to nfs2. > > > > The nfs thing is not xfs related, it's a known bug in irix nfs. I've seen this problem with IRIX servers and Linux clients, but not the other way round ... which known IRIX bug is this? James Pearson From owner-linux-xfs@oss.sgi.com Tue Mar 26 03:24:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QBOWV14730 for linux-xfs-outgoing; Tue, 26 Mar 2002 03:24:32 -0800 Received: from kendy.up.ac.za (kendy.up.AC.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QBNgq14693 for ; Tue, 26 Mar 2002 03:23:45 -0800 Received: from [137.215.109.246] (helo=mx2.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 16pp4B-0006Hz-00; Tue, 26 Mar 2002 13:24:39 +0200 Received: from mx1.up.ac.za ([137.215.95.15]) by mx2.up.ac.za with esmtp (Exim 3.12 #1) id 16pp4A-0000Ae-00; Tue, 26 Mar 2002 13:24:39 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=it.up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.15 #1) id 16pp4A-0005O3-00; Tue, 26 Mar 2002 13:24:38 +0200 Message-ID: <3CA05A75.9193A874@it.up.ac.za> Date: Tue, 26 Mar 2002 13:24:37 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-xfs-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: XFS mailing list Subject: Re: Kernel oops on new mailserver References: <3C965130.2CAB0A19@it.up.ac.za> <3C98ADE8.ACDBEF4C@it.up.ac.za> <1016642563.28200.113.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16pp4A-0005O3-00*pFGrKS7wE9.* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, It happened again. Dell PE2550 1G RAM 2 x 1.133GHz CPUs 4x18Gb Seagate cheeta's in RAID 10 on Perc hardware RAID kernel 2.4.18 (checked out on 21 March 2002 ) after the following take: > New vnode code left in an assert which is no longer valid > > Date: Thu Mar 21 06:39:40 PST 2002 > Workarea: jen.americas.sgi.com:/src/lord/xfs-newpagebuf > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:114612a > linux/fs/xfs/linux/xfs_vnode.c - 1.71 > - remove bad assert > > > gcc version 2.95.4 (Debian prerelease) modutils 2.4.13 CONFIG_HIGHMEM4G=y I see that Nathan Scott has checked changes in for page_buf. I am checking out the latest release to see if it helps. Paul kernel BUG at ll_rw_blk.c:902! invalid operand: 0000 CPU: 1 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 0000001f ebx: ca3a77a0 ecx: c03cc4c0 edx: 00002dbd esi: 00000008 edi: 00000001 ebp: c8fa3cbc esp: c8fa3ca8 ds: 0018 es: 0018 ss: 0018 Process modprobe (pid: 471, stackpage=c8fa3000) Stack: c02ff562 00000386 ca3a77a0 00000000 00000001 c8fa3ce4 c021c047 00000001 ca3a77a0 c67171a0 ca3a77a0 c67171a0 00001000 ca3a77a0 00000200 c8fa3cfc c013582e 00000001 00000001 c8fa3d04 c67171a0 c8fa3efc c013677d ca3a77a0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 b8 03 00 00 00 f0 0f ab 43 18 0f b7 43 0c 66 >>EIP; c021bebc <===== Trace; c021c046 Trace; c013582e Trace; c013677c Trace; c0190734 Trace; c0190734 Trace; c0190734 Trace; c0111758 Trace; c0190734 Trace; c01d6600 Trace; c0136b96 <__refile_buffer+56/60> Trace; c0136bb8 Trace; c0136ae8 <__mark_buffer_dirty+28/30> Trace; c01e4c9c Trace; c01e4fbc <__pb_block_commit_write_async+2c/50> Trace; c01e3f18 Trace; c01e5652 Trace; c01e5682 Trace; c01d6632 Trace; c01c311c Trace; c01e3fa0 Trace; c01e6f26 Trace; c01db5d0 Trace; c01e6a32 Trace; c0135fa6 Trace; c010715a Code; c021bebc 00000000 <_EIP>: Code; c021bebc <===== 0: 0f 0b ud2a <===== Code; c021bebe 2: 83 c4 08 add $0x8,%esp Code; c021bec0 5: b8 03 00 00 00 mov $0x3,%eax Code; c021bec6 a: f0 0f ab 43 18 lock bts %eax,0x18(%ebx) Code; c021beca f: 0f b7 43 0c movzwl 0xc(%ebx),%eax Code; c021bece 13: 66 data16 Entering kdb (current=0xc8fa2000, pid 471) on processor 1 Oops: invalid operand eax = 0x0000001f ebx = 0xca3a77a0 ecx = 0xc03cc4c0 edx = 0x00002dbd esi = 0x00000008 edi = 0x00000001 esp = 0xc8fa3ca8 eip = 0xc021bebc ebp = 0xc8fa3cbc xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010202 [1]kdb> bt EBP EIP Function(args) 0xc8fa3cbc 0xc021bebc submit_bh+0x54 (0x1, 0xca3a77a0, 0xc67171a0, 0xca3a77a0, 0xc67171a0) kernel .text 0xc0100000 0xc021be68 0xc021bf00 0xc8fa3ce4 0xc021c047 ll_rw_block+0x147 (0x1, 0x1, 0xc8fa3d04, 0xc67171a0) kernel .text 0xc0100000 0xc021bf00 0xc021c0b4 0xc8fa3cfc 0xc013582e write_buffer+0x1a (0xca3a77a0, 0xc67171a0, 0x1, 0xc03d3020, 0x0) kernel .text 0xc0100000 0xc0135814 0xc013586c 0xc8fa3efc 0xc013677d fsync_inode_data_buffers+0x9d (0xc67171a0, 0xc6717254, 0x0) kernel .text 0xc0100000 0xc01366e0 0xc0136844 0xc8fa3f10 0xc01e3fa1 pagebuf_flush+0x19 (0xc67171a0, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc01e3f88 0xc01e3fb4 0xc8fa3f28 0xc01e6f27 fs_flush_pages+0x2b (0xca9a8c64, 0x0, 0x0, 0xffffffff, 0xffffffff) kernel .text 0xc0100000 0xc01e6efc 0xc01e6f30 0xc8fa3f64 0xc01db5d1 xfs_fsync+0xe1 (0xca9a8c64, 0x5, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc01db4f0 0xc01db7f0 0xc8fa3f90 0xc01e6a32 linvfs_fsync+0x42 (0xcc5227a0, 0xc6dac760, 0x1, 0xc6717254, 0xc8fa2000) kernel .text 0xc0100000 0xc01e69f0 0xc01e6a40 0xc8fa3fbc 0xc0135fa6 sys_fdatasync+0x6a (0x0, 0x8063530, 0xbfffeca0, 0x8063530, 0x4013b6e0) kernel .text 0xc0100000 0xc0135f3c 0xc0135ff0 0xc010715b system_call+0x33 kernel .text 0xc0100000 0xc0107128 0xc0107160 [1]kdb> bh 0xca3a77a0 buffer_head at 0xca3a77a0 next 0x00000000 bno 0 rsec 1054688 size 4096 dev 0x805 rdev 0x805 count 2 state 0x5 [Uptodate Lock] ftime 0x899f47 b_list 1 b_reqnext 0x00000000 b_data 0xc41c2000 b_page 0xc1107080 b_this_page 0xca3a77a0 b_private 0xcd388da0 [1]kdb> cpu Currently on cpu 1 Available cpus: 0, 1 [1]kdb> cpu 0 Entering kdb (current=0xcf42e000, pid 171) on processor 0 due to cpu switch [0]kdb> bt EBP EIP Function(args) 0xcf42ff84 0xc011558b do_syslog+0x14b (0x2, 0x804dcbf, 0xfff) kernel .text 0xc0100000 0xc0115440 0xc0115804 0xcf42ff98 0xc01562da kmsg_read+0x12 (0xcffd7720, 0x804dca0, 0xfff, 0xcffd7740, 0xcf42e000) kernel .text 0xc0100000 0xc01562c8 0xc01562e0 0xcf42ffbc 0xc013461d sys_read+0x91 (0x0, 0x804dca0, 0xfff, 0x0, 0x804eca0) kernel .text 0xc0100000 0xc013458c 0xc01346a0 0xc010715b system_call+0x33 kernel .text 0xc0100000 0xc0107128 0xc0107160 [0]kdb> lsmod Module Size modstruct Used by e100 89752 0xd0850000 1 [0]kdb> Steve Lord wrote: > > Well, I just rewrote this code (after the 14th) to clean up a number > of problems in this area. > > Can you possibly try a current cvs tree. If you hit it again it will > be in submit_bh this time. Can you run with kdb again, specify y > for the KDB modules command. If it should happen again, run the > bt command, take the second argument of the submit_bh function > and use the bh command on it. > > Thanks > > 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 26 03:33:50 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QBXos15037 for linux-xfs-outgoing; Tue, 26 Mar 2002 03:33:50 -0800 Received: from xekmail.aeiou.pt (ramses.caleida.pt [194.65.155.52]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QBXjq15010 for ; Tue, 26 Mar 2002 03:33:45 -0800 Received: (from www@localhost) by xekmail.aeiou.pt (8.9.3/8.9.3) id LAA26827; Tue, 26 Mar 2002 11:38:35 GMT Date: Tue, 26 Mar 2002 11:38:35 GMT From: gamito@aeiou.pt Message-Id: <200203261138.LAA26827@xekmail.aeiou.pt> To: linux-xfs@oss.sgi.com Reply-To: gamito@aeiou.pt MIME-Version: 1.0 Content-Type: text/plain User-Agent: XekMail Imap webMail Program II Subject: Samba, xfs, permissions and chacl X-MIME-Autoconverted: from 8bit to quoted-printable by xekmail.aeiou.pt id LAA26827 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2QBXkq15011 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, I wonder if someone can help me out on this one. I'm running Samba 2.2.3a with-acl support included on XFS shares. Well, i got this weird problem: when i try to change NT file permissions through the NT security file tab it works perfectly well. When i try to do the same with some directory it simple doesm't work (!) I check some permission box, then apply and the box gets automagically unchecked and thereby the permission is not altered. Let's see: 1. i've got a directory name "test", a user "gamito" and a group "test" 2. chacl u::rwx,g::rwx,o::rw-,m::rwx,g:test:rw- test/ 3. Running chacl -l i get everytihng fine. Why does this works on files but not on directories ? Any help would be appreciated. Thanks in advance, Mário Gamito __________________________________________________________ Vida.pt: Arte, Cultura, Espectáculos, Lazer http://vida.aeiou.pt From owner-linux-xfs@oss.sgi.com Tue Mar 26 05:19:42 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QDJgL20756 for linux-xfs-outgoing; Tue, 26 Mar 2002 05:19:42 -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 g2QDJaq20730 for ; Tue, 26 Mar 2002 05:19:36 -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 g2QEUSkw017731 for ; Tue, 26 Mar 2002 08:30:28 -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 HAA47230; Tue, 26 Mar 2002 07:20:36 -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 HAA37411; Tue, 26 Mar 2002 07:20:35 -0600 (CST) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id HAA45207; Tue, 26 Mar 2002 07:20:35 -0600 (CST) Message-Id: <200203261320.HAA45207@fsgi158.americas.sgi.com> Subject: Re: incorrect file listings To: james-p@moving-picture.com (James Pearson) Date: Tue, 26 Mar 2002 07:20:34 -0600 (CST) Cc: sandeen@sgi.com (Eric Sandeen), nikk@digitalpictures.com.au (Monton Nick), linux-xfs@oss.sgi.com In-Reply-To: <3CA04FBD.F206F8DB@moving-picture.com> from "James Pearson" at Mar 26, 2002 10:38:53 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Eric Sandeen wrote: > > > > On Mon, 2002-03-25 at 12:40, Monton, Nick wrote: > > > > > via win2k (samba/smb) a total of around 8 files are missing. > > > via nfs3(irix 6.5.11) around 20 files are missing. > > > according to the local file system (xfs1.0.1) all these files are > > > present. > > > > > > > > > I can correct the nfs3 problem by dropping the mount point down to nfs2. > > > > > > > The nfs thing is not xfs related, it's a known bug in irix nfs. > > I've seen this problem with IRIX servers and Linux clients, but not the > other way round ... which known IRIX bug is this? > James, Probably referring to PV 815265, the 32 vs 64 bit file handle bug, which you're already aware of. I agree that this bug usually manifests itself by not returning the full pathname for a "pwd". I don't know if that bug can explain the behavior described here. I just tried with a 2.4.18-SGI_XFS_1.1 server and 6.5.16 IRIX client. I created 500 files and saw all of them from the 6.5.16 IRIX client. Unfortunately I don't have a 6.5.11 client to try it with. Tad From owner-linux-xfs@oss.sgi.com Tue Mar 26 05:29:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QDTBP21091 for linux-xfs-outgoing; Tue, 26 Mar 2002 05:29:11 -0800 Received: from saiya-jin.flinthills.com (root@saiya-jin.flinthills.com [64.39.192.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QDSxq21060 for ; Tue, 26 Mar 2002 05:28:59 -0800 Received: from saiya-jin.flinthills.com (cappicard@localhost [127.0.0.1]) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) with ESMTP id g2QDOXQf008492 for ; Tue, 26 Mar 2002 07:24:33 -0600 Received: (from cappicard@localhost) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) id g2QDOXQw008490; Tue, 26 Mar 2002 07:24:33 -0600 X-Authentication-Warning: saiya-jin.flinthills.com: cappicard set sender to djw@flinthills.com using -f Subject: Re: superblocks and lilo From: Derek James Witt To: Linux XFS In-Reply-To: <20020326155649.C45001@wobbly.melbourne.sgi.com> References: <1017092300.2173.13.camel@saiya-jin.flinthills.com> <1017093184.1748.32.camel@stout.americas.sgi.com> <1017096745.2172.18.camel@saiya-jin.flinthills.com> <1017114614.1754.6.camel@saiya-jin.flinthills.com> <20020326155649.C45001@wobbly.melbourne.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-nc7mN5wFWCl+asbmDXeJ" X-Mailer: Evolution/1.0.2 Date: 26 Mar 2002 07:24:33 -0600 Message-Id: <1017149073.5820.26.camel@saiya-jin.flinthills.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-nc7mN5wFWCl+asbmDXeJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Nathan, yeah. I agree. I have submitted a lilo patch to do just that (not allowing itself to install onto a XFS partition). But, it seems there are going to be folks not subscribed to the list that may unknowingly install lilo in that manner.=20=20 On Mon, 2002-03-25 at 22:56, Nathan Scott wrote: > hi, >=20 > On Mon, Mar 25, 2002 at 09:50:14PM -0600, Derek James Witt wrote: > > Hey all. > >=20 > > I'm going through the kernel source for XFS and I'm trying to find out > > how many superblocks a partition usually has and the maximum it's > > allowed to have. >=20 > There is one superblock at the head of every allocation group. > xfs_info/xfs_db/... will show you how many allocation groups a > filesystem has. There is one primary superblock, in the first > AG (at offset zero); and any number of secondary superblocks - > the number of AGs is a mkfs time option. >=20 > The primary superblock is the one the kernel uses at all times. > The secondary superblocks are usually only written at mkfs time, > and are read by xfs_repair when reconstructing the primary SB. >=20 > > So far in xfs_mount.h, I'm seeing that we are allowed > > two superblocks. I am proposing that we have two consecutive primary > > superblocks (duplicates) in use. In other words, mirrored blocks.=20 >=20 > I'll leave it for others to judge the relative merits of this, > my first thought is that it seems overly complex when the answer > should be "don't overwrite the SB in the first place". >=20 > > So, if lilo or any other boot loader comes along and overwrites a part > > of the first superblock, the mounting code can still get at the 2nd sb. >=20 > I think the operational model here should remain "run xfs_repair" > once you've blown your foot off... but, just my 2c. >=20 > > But, the problem is that the size of the superblock I've seen varies > > from 512 bytes to 65535 bytes. In lilo's sources, we got blocks of size > > 1024 and sector sizes of 512. Any ideas on what to do on this? >=20 > The XFS superblock fits within 512 bytes. >=20 > cheers. >=20 > --=20 > Nathan >=20 --=20 ** Derek J Witt ** * Email: mailto:djw@flinthills.com * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** --=-nc7mN5wFWCl+asbmDXeJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8oHaRgnGXTpcv6TgRAlkUAJ4uqhzzYOWAAxRUV+N7md6++Cp8HgCgyuVj lrBiYO8P9hBIjgJY2CKapr8= =kT71 -----END PGP SIGNATURE----- --=-nc7mN5wFWCl+asbmDXeJ-- From owner-linux-xfs@oss.sgi.com Tue Mar 26 05:46:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QDkVX22818 for linux-xfs-outgoing; Tue, 26 Mar 2002 05:46:31 -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 g2QDkPq22792 for ; Tue, 26 Mar 2002 05:46:25 -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 g2QDmh6G022868 for ; Tue, 26 Mar 2002 05:48:43 -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 HAA48436; Tue, 26 Mar 2002 07:47:27 -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 HAA64447; Tue, 26 Mar 2002 07:47:27 -0600 (CST) Date: Tue, 26 Mar 2002 07:47:27 -0600 (CST) From: Eric Sandeen X-X-Sender: To: James Pearson cc: "Monton, Nick" , Subject: Re: incorrect file listings In-Reply-To: <3CA04FBD.F206F8DB@moving-picture.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 26 Mar 2002, James Pearson wrote: > I've seen this problem with IRIX servers and Linux clients, but not the > other way round ... which known IRIX bug is this? I had read things wrong, you're right that the known issue is w/ IRIX servers. It turns out that Nick's problem was that he had made the filesystem on IRIX, with version 1 directories and unwritten extents, neither of which is supported on Linux - this is probably what caused his problems. -Eric From owner-linux-xfs@oss.sgi.com Tue Mar 26 06:36:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QEaZO24993 for linux-xfs-outgoing; Tue, 26 Mar 2002 06:36: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 g2QEaTq24966 for ; Tue, 26 Mar 2002 06:36:29 -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 g2QFlLkw018562 for ; Tue, 26 Mar 2002 09:47:21 -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 IAA49170; Tue, 26 Mar 2002 08:37: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 IAA11188; Tue, 26 Mar 2002 08:37:26 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2QEYAb17216; Tue, 26 Mar 2002 08:34:10 -0600 Subject: Re: superblocks and lilo From: Steve Lord To: Derek James Witt Cc: Linux XFS In-Reply-To: <1017114614.1754.6.camel@saiya-jin.flinthills.com> References: <1017092300.2173.13.camel@saiya-jin.flinthills.com> <1017093184.1748.32.camel@stout.americas.sgi.com> <1017096745.2172.18.camel@saiya-jin.flinthills.com> <1017114614.1754.6.camel@saiya-jin.flinthills.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Mar 2002 08:34:10 -0600 Message-Id: <1017153250.19650.31.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-25 at 21:50, Derek James Witt wrote: > Hey all. > > I'm going through the kernel source for XFS and I'm trying to find out > how many superblocks a partition usually has and the maximum it's > allowed to have. So far in xfs_mount.h, I'm seeing that we are allowed > two superblocks. I am proposing that we have two consecutive primary > superblocks (duplicates) in use. In other words, mirrored blocks. > > So, if lilo or any other boot loader comes along and overwrites a part > of the first superblock, the mounting code can still get at the 2nd sb. > But, the problem is that the size of the superblock I've seen varies > from 512 bytes to 65535 bytes. In lilo's sources, we got blocks of size > 1024 and sector sizes of 512. Any ideas on what to do on this? > Nathan answered some structural details here, but the idea of placing a second super block after the first will not work, the second 512 bytes of the filesystem contain another data structure. In fact there are data structures in the first 2K of disk, then a 2K gap, then regular metadata can start at 4K. The only fields in the primary superblock which change are the totals of free space and inodes used. These can all be reconstructed with xfs repair. Thanks for the lilo patch though. 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 26 06:46:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QEkWt25463 for linux-xfs-outgoing; Tue, 26 Mar 2002 06:46: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 g2QEk2q25354 for ; Tue, 26 Mar 2002 06:46:02 -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 g2QFmKBA024922 for ; Tue, 26 Mar 2002 07:48:21 -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 IAA47699; Tue, 26 Mar 2002 08:46: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 IAA48738; Tue, 26 Mar 2002 08:46:56 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2QEhfW17222; Tue, 26 Mar 2002 08:43:41 -0600 Subject: Re: Kernel oops on new mailserver From: Steve Lord To: Paul Schutte Cc: XFS mailing list In-Reply-To: <3CA05A75.9193A874@it.up.ac.za> References: <3C965130.2CAB0A19@it.up.ac.za> <3C98ADE8.ACDBEF4C@it.up.ac.za> <1016642563.28200.113.camel@jen.americas.sgi.com> <3CA05A75.9193A874@it.up.ac.za> Content-Type: multipart/mixed; boundary="=-hPtGgnkiawOUdPYRDc8z" X-Mailer: Evolution/1.0.2 Date: 26 Mar 2002 08:43:41 -0600 Message-Id: <1017153821.17221.42.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-hPtGgnkiawOUdPYRDc8z Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2002-03-26 at 05:24, Paul Schutte wrote: > Hi, > > It happened again. > > Dell PE2550 > 1G RAM > 2 x 1.133GHz CPUs > 4x18Gb Seagate cheeta's in RAID 10 on Perc hardware RAID > > kernel 2.4.18 (checked out on 21 March 2002 ) after the following take: > Don't worry, I have not forgotten you! Nathan's change is mostly all formatting, no real structural changes in there. Can you try this code? Thanks, Steve Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com --=-hPtGgnkiawOUdPYRDc8z Content-Disposition: attachment; filename=buffer.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/pagebuf/page_buf_io.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.17165-0/linux/fs/xfs/pagebuf/page_buf_io.c_1.18 Tue Mar= 26 08:31:11 2002 +++ linux/fs/xfs/pagebuf/page_buf_io.c Mon Mar 25 12:50:15 2002 @@ -638,12 +638,12 @@ =20=09=09 error =3D bmap(inode, ((loff_t)page->index << PAGE_CACHE_SHIFT), PAGE_CACHE_SIZE, &map, 1, &nmaps, PBF_READ); + + hook_buffers_to_page(target, inode, page, &map, nmaps); + bh =3D head =3D page->buffers; if (error) BUG(); - if (map.pbm_bn >=3D 0) { - hook_buffers_to_page(target, inode, page, &map, nmaps); - bh =3D head =3D page->buffers; - } else if (map.pbm_flags & (PBMF_HOLE|PBMF_DELAY)) { + if (map.pbm_flags & (PBMF_HOLE|PBMF_DELAY)) { memset(kmap(page), 0, PAGE_CACHE_SIZE); flush_dcache_page(page); kunmap(page); @@ -754,11 +754,10 @@ { struct buffer_head *bh; =20 - if (page->buffers) - BUG(); - create_empty_buffers(page, target->pbr_device, PAGE_CACHE_SIZE); + if (!page->buffers) + create_empty_buffers(page, target->pbr_device, PAGE_CACHE_SIZE); bh =3D page->buffers; - bh->b_state =3D (1 << BH_Delay) | (1 << BH_Mapped); + bh->b_state =3D (1 << BH_Delay) | (1 << BH_Mapped) | (1 << BH_Uptodate); __mark_buffer_dirty(bh); buffer_insert_inode_data_queue(bh, inode); balance_dirty(); @@ -785,19 +784,22 @@ * delta =3D offset of _this_ page in extent. * pbm_offset =3D offset in file corresponding to pbm_bn. */ - delta =3D page->index; /* do computations in 64 bit ... */ - delta <<=3D PAGE_CACHE_SHIFT; /* delta now offset from 0 of page */ - delta -=3D mp->pbm_offset; /* delta now offset in extent of page */ - - bn =3D mp->pbm_bn >> - (PAGE_CACHE_SHIFT - inode->i_sb->s_blocksize_bits); - bn +=3D (delta >> PAGE_CACHE_SHIFT); - lock_buffer(bh); - bh->b_blocknr =3D bn; - bh->b_dev =3D target->pbr_device; - set_bit(BH_Mapped, &bh->b_state); - clear_bit(BH_Delay, &bh->b_state); - unlock_buffer(bh); + + if (mp->pbm_bn >=3D 0) { + delta =3D page->index; /* do computations in 64 bit */ + delta <<=3D PAGE_CACHE_SHIFT; /* delta is offset from 0 of page */ + delta -=3D mp->pbm_offset; /* delta is offset in extent */ + bn =3D mp->pbm_bn >> + (PAGE_CACHE_SHIFT - inode->i_sb->s_blocksize_bits); + bn +=3D (delta >> PAGE_CACHE_SHIFT); + bh =3D page->buffers; + lock_buffer(bh); + bh->b_blocknr =3D bn;=20 + bh->b_dev =3D target->pbr_device; + set_bit(BH_Mapped, &bh->b_state); + clear_bit(BH_Delay, &bh->b_state); + unlock_buffer(bh); + } } =20 STATIC void @@ -809,13 +811,9 @@ int need_balance_dirty =3D 0; =20 #ifdef PAGEBUF_DEBUG - /* negative blocknr is always bad; if it's zero, and the - * inode & bh are on different devices, it could be an - * xfs realtime file, which would be OK. Either that - * or something is seriously wrong! + /* negative blocknr is always bad;=20 */ - if ((bh->b_blocknr < 0) ||=20 - ((bh->b_blocknr =3D=3D 0) && (inode->i_dev =3D=3D bh->b_dev))) { + if (bh->b_blocknr < 0) { printk("Warning: buffer 0x%p with weird blockno (%ld)\n", bh, bh->b_blocknr); } @@ -860,8 +858,10 @@ * go get some space. */ bh =3D page->buffers; +/*** if ((!bh || buffer_delay(bh)) && (!dp || (flags & PBF_FILE_ALLOCATE))) - { +***/ + if (!bh || !buffer_mapped(bh)) { if (!mp) { mp =3D map; err =3D bmap(inode, ((loff_t)page->index << PAGE_CACHE_SHIFT), @@ -870,10 +870,8 @@ goto out; } } - if (mp->pbm_bn >=3D 0) { - hook_buffers_to_page(target, inode, page, mp, nmaps); - bh =3D page->buffers; - } + hook_buffers_to_page(target, inode, page, mp, nmaps); + bh =3D page->buffers; } =20 /* Is the write over the entire page? */ @@ -961,9 +959,9 @@ * parts of page not covered by from/to. Page is now fully valid. */ SetPageUptodate(page); - if ((bh =3D page->buffers) && !buffer_delay(bh)) { + if ((bh =3D page->buffers) && buffer_mapped(bh)) { set_buffer_dirty_uptodate(inode, page->buffers, partial); - } else if (!DelallocPage(page)) { + } else { hook_buffers_to_page_delay(target, inode, page); } } @@ -1363,7 +1361,7 @@ /* Three possible conditions - page with delayed buffers, * page with real buffers, or page with no buffers (mmap) */ - if (!bh || DelallocPage(page)) { + if (!bh || DelallocPage(page) || !buffer_mapped(bh)) { hook_buffers_to_page(target, inode, page, mp, nmaps); } =20 @@ -1424,7 +1422,8 @@ loff_t rounded_offset; =20 /* Fast path for mapped page */ - if (page->buffers && !buffer_delay(page->buffers)) { + if (page->buffers && !buffer_delay(page->buffers) && + buffer_mapped(page->buffers)) { if (async_write) { submit_page_io(page); } --=-hPtGgnkiawOUdPYRDc8z-- From owner-linux-xfs@oss.sgi.com Tue Mar 26 07:23:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QFNeD26975 for linux-xfs-outgoing; Tue, 26 Mar 2002 07:23:40 -0800 Received: from kendy.up.ac.za (kendy.up.AC.za [137.215.101.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QFNUq26946 for ; Tue, 26 Mar 2002 07:23:31 -0800 Received: from [137.215.109.246] (helo=mx2.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 16pspP-00054g-00; Tue, 26 Mar 2002 17:25:39 +0200 Received: from mx1.up.ac.za ([137.215.95.15]) by mx2.up.ac.za with esmtp (Exim 3.12 #1) id 16pspP-0001u3-00; Tue, 26 Mar 2002 17:25:39 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=it.up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.15 #1) id 16pspO-00071L-00; Tue, 26 Mar 2002 17:25:38 +0200 Message-ID: <3CA092F2.B5DB6F19@it.up.ac.za> Date: Tue, 26 Mar 2002 17:25:38 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-xfs-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: XFS mailing list Subject: Re: Kernel oops on new mailserver References: <3C965130.2CAB0A19@it.up.ac.za> <3C98ADE8.ACDBEF4C@it.up.ac.za> <1016642563.28200.113.camel@jen.americas.sgi.com> <3CA05A75.9193A874@it.up.ac.za> <1017153821.17221.42.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16pspO-00071L-00*Km7U/rP0epU* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I have patched the cvs source that I checked out today. The server is up and running with this kernel. I will keep you informed. Thank's a lot for your effort. Paul > > Can you try this code? > > Thanks, > > Steve > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > > ------------------------------------------------------------------------ > Name: buffer.patch > buffer.patch Type: Plain Text (text/plain) > Encoding: quoted-printable From owner-linux-xfs@oss.sgi.com Tue Mar 26 08:00:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QG06w27984 for linux-xfs-outgoing; Tue, 26 Mar 2002 08:00:06 -0800 Received: from saiya-jin.flinthills.com (root@saiya-jin.flinthills.com [64.39.192.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QFxuq27946 for ; Tue, 26 Mar 2002 07:59:56 -0800 Received: from saiya-jin.flinthills.com (cappicard@localhost [127.0.0.1]) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) with ESMTP id g2QFtUQf014556 for ; Tue, 26 Mar 2002 09:55:30 -0600 Received: (from cappicard@localhost) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) id g2QFtUpg014554; Tue, 26 Mar 2002 09:55:30 -0600 X-Authentication-Warning: saiya-jin.flinthills.com: cappicard set sender to djw@flinthills.com using -f Subject: Re: superblocks and lilo From: Derek James Witt To: Linux XFS In-Reply-To: <1017153250.19650.31.camel@jen.americas.sgi.com> References: <1017092300.2173.13.camel@saiya-jin.flinthills.com> <1017093184.1748.32.camel@stout.americas.sgi.com> <1017096745.2172.18.camel@saiya-jin.flinthills.com> <1017114614.1754.6.camel@saiya-jin.flinthills.com> <1017153250.19650.31.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-r5kcQDAFTwVt1It9SkSs" X-Mailer: Evolution/1.0.2 Date: 26 Mar 2002 09:55:30 -0600 Message-Id: <1017158130.5820.39.camel@saiya-jin.flinthills.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-r5kcQDAFTwVt1It9SkSs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-03-26 at 08:34, Steve Lord wrote: > On Mon, 2002-03-25 at 21:50, Derek James Witt wrote: > > Hey all. > >=20 > > I'm going through the kernel source for XFS and I'm trying to find out > > how many superblocks a partition usually has and the maximum it's > > allowed to have. So far in xfs_mount.h, I'm seeing that we are allowed > > two superblocks. I am proposing that we have two consecutive primary > > superblocks (duplicates) in use. In other words, mirrored blocks.=20 > >=20 > > So, if lilo or any other boot loader comes along and overwrites a part > > of the first superblock, the mounting code can still get at the 2nd sb. > > But, the problem is that the size of the superblock I've seen varies > > from 512 bytes to 65535 bytes. In lilo's sources, we got blocks of size > > 1024 and sector sizes of 512. Any ideas on what to do on this? > >=20 >=20 > Nathan answered some structural details here, but the idea of placing > a second super block after the first will not work, the second 512 bytes > of the filesystem contain another data structure. In fact there are > data structures in the first 2K of disk, then a 2K gap, then regular > metadata can start at 4K. >=20 > The only fields in the primary superblock which change are the totals > of free space and inodes used. These can all be reconstructed with xfs > repair. >=20 > Thanks for the lilo patch though. >=20 > Steve >=20 >=20 > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com >=20 --=20 ** Derek J Witt ** * Email: mailto:djw@flinthills.com * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** --=-r5kcQDAFTwVt1It9SkSs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8oJnygnGXTpcv6TgRAsg9AKC1019RtI+yoGip/N0yE+opYxhnoACfZwot 3asOPVLRwzZH3pv6BN41XtA= =gxzA -----END PGP SIGNATURE----- --=-r5kcQDAFTwVt1It9SkSs-- From owner-linux-xfs@oss.sgi.com Tue Mar 26 08:20:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QGKCG28604 for linux-xfs-outgoing; Tue, 26 Mar 2002 08:20:12 -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 g2QGK2q28578 for ; Tue, 26 Mar 2002 08:20:02 -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 g2QHUskw020172 for ; Tue, 26 Mar 2002 11:30:54 -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 KAA50677 for ; Tue, 26 Mar 2002 10:21:05 -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 KAA80861 for ; Tue, 26 Mar 2002 10:21:04 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2QGHm619038; Tue, 26 Mar 2002 10:17:48 -0600 Message-Id: <200203261617.g2QGHm619038@jen.americas.sgi.com> Date: Tue, 26 Mar 2002 10:17:48 -0600 Subject: TAKE - shrink xfs inode To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This gets the xfs inode down to 400 bytes, and as a consequence we can fit 10 into a page now. So we reduce the slabcache memory consumption of xfs. Date: Tue Mar 26 08:19:25 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-ishrink The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:114887a linux/fs/xfs/xfsidbg.c - 1.177 - cleanup inode debug functions to remove fields linux/fs/xfs/xfs_rw.h - 1.62 - prototype change for xfs_inval_cached_pages linux/fs/xfs/xfs_rw.c - 1.353 - make xfs_inval_cached_pages take a parameter indicating the lock state of the iolock. linux/fs/xfs/xfs_vnodeops.c - 1.520 - remove usage of i_dev linux/fs/xfs/xfs_itable.c - 1.102 - remove i_dev linux/fs/xfs/xfs_dmapi.c - 1.50 - i_dev replaced with i_mount->m_dev linux/fs/xfs/xfs_inode_item.c - 1.97 - access i_pincount via function now, it is an atomic_t linux/fs/xfs/xfs_iocore.c - 1.28 - make io_lock and io_iolock debug only linux/fs/xfs/xfs_vfsops.c - 1.339 - access i_pincount via function now, it is an atomic_t linux/fs/xfs/xfs_dfrag.c - 1.28 - Add parameter to xfs_inval_cached_pages indicating ilock state linux/fs/xfs/xfs_iget.c - 1.152 - replace the sv and spinlock for inode pinning with a waitqueue and an atomic_t linux/fs/xfs/xfs_mount.c - 1.276 - remove i_dev usage linux/fs/xfs/xfs_inode.c - 1.329 - i_dev replaced with i_mount->m_dev, remove assert references to io_queued_bufs and use lighter weight implementation for inode pinning. linux/fs/xfs/xfs_inode.h - 1.157 - Remove unused fields in the xfs_inode and xfs_iocore structures linux/fs/xfs/linux/xfs_lrw.c - 1.129 - Add parameter to xfs_inval_cached_pages indicating ilock state linux/include/linux/xfs_support/mrlock.h - 1.3 - shrink mrlock 4 more bytes From owner-linux-xfs@oss.sgi.com Tue Mar 26 08:37:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QGbRc30243 for linux-xfs-outgoing; Tue, 26 Mar 2002 08:37:27 -0800 Received: from saiya-jin.flinthills.com (root@saiya-jin.flinthills.com [64.39.192.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QGbGq30214 for ; Tue, 26 Mar 2002 08:37:16 -0800 Received: from saiya-jin.flinthills.com (cappicard@localhost [127.0.0.1]) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) with ESMTP id g2QGWoQf014812 for ; Tue, 26 Mar 2002 10:32:50 -0600 Received: (from cappicard@localhost) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) id g2QGWov2014810; Tue, 26 Mar 2002 10:32:50 -0600 X-Authentication-Warning: saiya-jin.flinthills.com: cappicard set sender to djw@flinthills.com using -f Subject: Re: superblocks and lilo From: Derek James Witt To: Linux XFS In-Reply-To: <1017158130.5820.39.camel@saiya-jin.flinthills.com> References: <1017092300.2173.13.camel@saiya-jin.flinthills.com> <1017093184.1748.32.camel@stout.americas.sgi.com> <1017096745.2172.18.camel@saiya-jin.flinthills.com> <1017114614.1754.6.camel@saiya-jin.flinthills.com> <1017153250.19650.31.camel@jen.americas.sgi.com> <1017158130.5820.39.camel@saiya-jin.flinthills.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-YOhKptasnAB0THbiZjad" X-Mailer: Evolution/1.0.2 Date: 26 Mar 2002 10:32:49 -0600 Message-Id: <1017160369.5820.42.camel@saiya-jin.flinthills.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-YOhKptasnAB0THbiZjad Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Nathan. ok. That makes perfect sense now. Looks like the mirroring superblocks is out of the question then. Oh well. :-) Thanks for the heads up. On Tue, 2002-03-26 at 09:55, Derek James Witt wrote: > On Tue, 2002-03-26 at 08:34, Steve Lord wrote: > > On Mon, 2002-03-25 at 21:50, Derek James Witt wrote: > > > Hey all. > > >=20 > > > I'm going through the kernel source for XFS and I'm trying to find out > > > how many superblocks a partition usually has and the maximum it's > > > allowed to have. So far in xfs_mount.h, I'm seeing that we are allow= ed > > > two superblocks. I am proposing that we have two consecutive primary > > > superblocks (duplicates) in use. In other words, mirrored blocks.=20 > > >=20 > > > So, if lilo or any other boot loader comes along and overwrites a part > > > of the first superblock, the mounting code can still get at the 2nd s= b. > > > But, the problem is that the size of the superblock I've seen varies > > > from 512 bytes to 65535 bytes. In lilo's sources, we got blocks of s= ize > > > 1024 and sector sizes of 512. Any ideas on what to do on this? > > >=20 > >=20 > > Nathan answered some structural details here, but the idea of placing > > a second super block after the first will not work, the second 512 bytes > > of the filesystem contain another data structure. In fact there are > > data structures in the first 2K of disk, then a 2K gap, then regular > > metadata can start at 4K. > >=20 > > The only fields in the primary superblock which change are the totals > > of free space and inodes used. These can all be reconstructed with xfs > > repair. > >=20 > > Thanks for the lilo patch though. > >=20 > > Steve > >=20 > >=20 > > --=20 > >=20 > > Steve Lord voice: +1-651-683-3511 > > Principal Engineer, Filesystem Software email: lord@sgi.com > >=20 > --=20 > ** Derek J Witt ** > * Email: mailto:djw@flinthills.com * > * Home Page: http://www.flinthills.com/~djw/ * > *** "...and on the eighth day, God met Bill Gates." - Unknown ** --=20 ** Derek J Witt ** * Email: mailto:djw@flinthills.com * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** --=-YOhKptasnAB0THbiZjad Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8oKKxgnGXTpcv6TgRAjnDAJ4mspYmbxBjQs489Bh5cU6G5lQqogCdF4ju nfwubn4eiBsYoEojJ8jOWf4= =Iskg -----END PGP SIGNATURE----- --=-YOhKptasnAB0THbiZjad-- From owner-linux-xfs@oss.sgi.com Tue Mar 26 09:09:59 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QH9xM00355 for linux-xfs-outgoing; Tue, 26 Mar 2002 09:09:59 -0800 Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QH6xq00301 for ; Tue, 26 Mar 2002 09:06:59 -0800 Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel9.hp.com (Postfix) with ESMTP id DEC81804E03 for ; Tue, 26 Mar 2002 12:09:16 -0500 (EST) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id B2F0E12D for ; Tue, 26 Mar 2002 12:09:16 -0500 (EST) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 12:09:16 -0500 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" Subject: XFS livelock during NFS SPEC testing Date: Tue, 26 Mar 2002 12:09:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm seeing XFS livelock during SPEC SFS testing. Kernel: 2.4.17 XFS: CVS from Feb 7, 2002 (right before update to 2.4.18) 4 Intel PIII Xeon processors 4 GB RAM Here's the translated output from AltSysRq-T. Most processes are stuck in xlog_grant_log_space, and a few are stuck in lock_wait via mrupdatef + mraccessf. Any ideas on how I can help debug this? Thanks, Erik Habbinga task: kupdated (pid: 9) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy c01cb9ea: c01cb788 T xfs_trans_commit c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c01cc126: c01cc104 T xfs_trans_unlocked_item c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d49: c0134ce0 t write_buffer_delay c0134f3f: c0134ed0 t write_some_buffers c010b06d: c010b068 t call_apic_timer_interrupt c01ceecd: c01ceeb8 t xfs_sync c01e4943: c01e4918 T linvfs_write_super c013872d: c013863c T sync_supers c0137f2b: c0137ed4 t sync_old_buffers c0138205: c01380ec T kupdate c0105594: c010556c T kernel_thread task: syslogd (pid: 142) c011a6f0: c011a690 T __run_task_queue c0134e4f: c0134de0 T __wait_on_buffer c0135b0e: c0135a24 T fsync_inode_buffers c025a912: c025a800 t megaIssueCmd c0259a63: c0259a40 t mega_runpendq c025bfb5: c025be6c T megaraid_queue c0135fbc: c0135f68 t __refile_buffer c0135fdb: c0135fc4 T refile_buffer c01dac70: c01dac4c t set_buffer_dirty_uptodate c01daf80: c01daf54 t __pb_block_commit_write_async c01d9f90: c01d9f50 T pagebuf_commit_write c01db655: c01db3d0 T pagebuf_generic_file_write c01bd573: c01bd55c t xfs_setsize_fn c01b8cc5: c01b8c60 T xfs_ilock_ra c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01b8e2b: c01b8dcc T xfs_iunlock c01d5154: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01dc524: c01dc524 t linvfs_write c01d9ff3: c01d9fdc T pagebuf_flush c01dceab: c01dce80 T fs_flush_pages c01d103e: c01d0f5c t xfs_fsync c01dc8c5: c01dc884 t linvfs_fsync c013542c: c01353cc T sys_fsync c0106d6f: c0106d3c T system_call task: nfsd (pid: 4630) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca097: c02c65b8 T stext_lock c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4631) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d13f6: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c0239f7a: c0239e18 T scsi_io_completion c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4632) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy c01e23e9: c01e23c0 t _xfs_imap_to_bmap c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c01dab77: c01dab38 t hook_buffers_to_page_delay c01daf9b: c01daf54 t __pb_block_commit_write_async c01d9f90: c01d9f50 T pagebuf_commit_write c01d9fc1: c01d9f50 T pagebuf_commit_write c01db155: c01dafa0 T __pagebuf_do_delwri c01db17b: c01dafa0 T __pagebuf_do_delwri c01db317: c01db1dc T _pagebuf_file_write f88cf2f2: c042b620 B ___strtok c01d5154: c01d5124 T xfs_rwunlock c0147ed5: c0147e88 T iget4 c01e58b1: c01e5890 T vn_put c0148084: c014803c T iput c016139a: c01612a8 t nfsd_iget c016141d: c01613b4 t nfsd_get_dentry c01d9ff3: c01d9fdc T pagebuf_flush c01dceab: c01dce80 T fs_flush_pages c01d103e: c01d0f5c t xfs_fsync c01dc8c5: c01dc884 t linvfs_fsync c01632cc: c0163264 T nfsd_sync c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4633) c01e648d: c01e63e0 T lock_wait c01e657d: c01e6554 T mrupdatef c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01b8c94: c01b8c60 T xfs_ilock_ra c01b8d03: c01b8cf0 T xfs_ilock c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4634) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy c01cbf16: c01cbef8 T xfs_trans_tail_ail c01c7d19: c01c7ccc T xfs_mod_incore_sb_batch c01cb77c: c01cb620 T xfs_trans_unreserve_and_mod_sb c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c01df6d3: c01df6a8 t validate_fields c021bd89: c021bc40 t __make_request c021bdc6: c021bc40 t __make_request c021bde5: c021bc40 t __make_request c021c37c: c021c264 T generic_make_request c01d9193: c01d8f48 t _pagebuf_page_io f88b83aa: c042b620 B ___strtok f88b426f: c042b620 B ___strtok c01d023e: c01cfff4 t xfs_setattr c01b8cc5: c01b8c60 T xfs_ilock_ra c01cc126: c01cc104 T xfs_trans_unlocked_item c01b8e2b: c01b8dcc T xfs_iunlock c0147ed5: c0147e88 T iget4 c01e58b1: c01e5890 T vn_put c0148084: c014803c T iput c016139a: c01612a8 t nfsd_iget c016141d: c01613b4 t nfsd_get_dentry c01d9ff3: c01d9fdc T pagebuf_flush c01dceab: c01dce80 T fs_flush_pages c01d103e: c01d0f5c t xfs_fsync c01dc8c5: c01dc884 t linvfs_fsync c01632cc: c0163264 T nfsd_sync c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4635) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c01d9fc1: c01d9f50 T pagebuf_commit_write c01df819: c01df6f8 T linvfs_common_cr f88cf2f2: c042b620 B ___strtok c01d5154: c01d5124 T xfs_rwunlock c027e038: c027dea4 T csum_partial_copy_fromiovecend c0285ae3: c0285ad0 T qdisc_restart c027f9bd: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag c028f26c: c028efd8 T ip_build_xmit c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4636) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c01df819: c01df6f8 T linvfs_common_cr f88cf2f2: c042b620 B ___strtok c01b8e2b: c01b8dcc T xfs_iunlock c027e038: c027dea4 T csum_partial_copy_fromiovecend c0285ae3: c0285ad0 T qdisc_restart c027f9bd: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag c028f26c: c028efd8 T ip_build_xmit c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4637) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca097: c02c65b8 T stext_lock c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4638) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca097: c02c65b8 T stext_lock c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4639) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca069: c02c65b8 T stext_lock c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4640) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d13f6: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4641) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c01df819: c01df6f8 T linvfs_common_cr f88cf2f2: c042b620 B ___strtok c01d5154: c01d5124 T xfs_rwunlock c027e038: c027dea4 T csum_partial_copy_fromiovecend c0285ae3: c0285ad0 T qdisc_restart c027f9bd: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag c028f26c: c028efd8 T ip_build_xmit c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4642) c01617e9: c01617a8 t find_fh_dentry c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02caed4: c02c65b8 T stext_lock c0160018: c015fd68 T sys_nfsservctl c02c92fb: c02c65b8 T stext_lock c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4643) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c01d9fc1: c01d9f50 T pagebuf_commit_write c01df819: c01df6f8 T linvfs_common_cr f88cf2f2: c042b620 B ___strtok c01d5154: c01d5124 T xfs_rwunlock c027e038: c027dea4 T csum_partial_copy_fromiovecend c0285ae3: c0285ad0 T qdisc_restart c027f9bd: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag c028f26c: c028efd8 T ip_build_xmit c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4644) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c01d9fc1: c01d9f50 T pagebuf_commit_write c01df819: c01df6f8 T linvfs_common_cr f88cf2f2: c042b620 B ___strtok c01a5f62: c01a5eac t xfs_dir2_lookup c01d5154: c01d5124 T xfs_rwunlock c027e038: c027dea4 T csum_partial_copy_fromiovecend c0285ae3: c0285ad0 T qdisc_restart c027f9bd: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag c028f26c: c028efd8 T ip_build_xmit c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4645) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca097: c02c65b8 T stext_lock c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4646) c01617e9: c01617a8 t find_fh_dentry c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02caed4: c02c65b8 T stext_lock c0163199: c0162ff0 T nfsd_open c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4647) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy c0112caa: c0112c48 t reschedule_idle c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c028c08c: c028bfb4 T ip_local_deliver c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c01dab77: c01dab38 t hook_buffers_to_page_delay c01daf9b: c01daf54 t __pb_block_commit_write_async c01d9f90: c01d9f50 T pagebuf_commit_write c01d9fc1: c01d9f50 T pagebuf_commit_write c01db155: c01dafa0 T __pagebuf_do_delwri c01db17b: c01dafa0 T __pagebuf_do_delwri c01db317: c01db1dc T _pagebuf_file_write f88cf2f2: c042b620 B ___strtok c01d5154: c01d5124 T xfs_rwunlock c0147ed5: c0147e88 T iget4 c01e58b1: c01e5890 T vn_put c0148084: c014803c T iput c016139a: c01612a8 t nfsd_iget c016141d: c01613b4 t nfsd_get_dentry c01d9ff3: c01d9fdc T pagebuf_flush c01dceab: c01dce80 T fs_flush_pages c01d103e: c01d0f5c t xfs_fsync c01dc8c5: c01dc884 t linvfs_fsync c01632cc: c0163264 T nfsd_sync c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4648) c01e648d: c01e63e0 T lock_wait c01e653c: c01e64ec T mraccessf c01d0c96: c01d0c7c t xfs_access c01b8ce6: c01b8c60 T xfs_ilock_ra c01b8d03: c01b8cf0 T xfs_ilock c01d0c96: c01d0c7c t xfs_access c01d0c96: c01d0c7c t xfs_access c01e0171: c01e0154 T linvfs_permission c013d222: c013d1bc T permission c01651cf: c016511c T nfsd_permission c0161f46: c0161b70 T fh_verify c016a00a: c0169f88 T nfs3svc_decode_createargs c0168818: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4649) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d13f6: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4650) c01e648d: c01e63e0 T lock_wait c01e657d: c01e6554 T mrupdatef c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01b8c94: c01b8c60 T xfs_ilock_ra c01b8d03: c01b8cf0 T xfs_ilock c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4651) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca069: c02c65b8 T stext_lock c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4652) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d13f6: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4653) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d13f6: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4654) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c01cca3b: c01cc98c T xfs_trans_brelse c01df819: c01df6f8 T linvfs_common_cr c01a77df: c01a77c4 T xfs_dir2_block_lookup f88cf2f2: c042b620 B ___strtok c01a5f8a: c01a5eac t xfs_dir2_lookup c027e038: c027dea4 T csum_partial_copy_fromiovecend c0285ae3: c0285ad0 T qdisc_restart c027f9bd: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag c028f26c: c028efd8 T ip_build_xmit c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4655) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c011349a: c0113038 T schedule c01df819: c01df6f8 T linvfs_common_cr c01b8e2b: c01b8dcc T xfs_iunlock c01d12ea: c01d1220 t xfs_inactive_free_eofblocks c01cc126: c01cc104 T xfs_trans_unlocked_item c0112ea7: c0112c48 t reschedule_idle f88cf2f2: c042b620 B ___strtok c027e038: c027dea4 T csum_partial_copy_fromiovecend c0285ae3: c0285ad0 T qdisc_restart c027f9bd: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag f88b4787: c042b620 B ___strtok f88b4768: c042b620 B ___strtok c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4656) c01617e9: c01617a8 t find_fh_dentry c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02caed4: c02c65b8 T stext_lock c0163199: c0162ff0 T nfsd_open c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4657) c01617e9: c01617a8 t find_fh_dentry c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02caed4: c02c65b8 T stext_lock c0163199: c0162ff0 T nfsd_open c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4659) c01617e9: c01617a8 t find_fh_dentry c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02caed4: c02c65b8 T stext_lock c0163199: c0162ff0 T nfsd_open c01636f0: c01635c8 T nfsd_write c0108414: c01083c4 T handle_IRQ_event c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4660) c01617e9: c01617a8 t find_fh_dentry c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02caed4: c02c65b8 T stext_lock c0163199: c0162ff0 T nfsd_open c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4661) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy c01d8900: c01d887c T pagebuf_get_no_daddr c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c0136247: c01361ec t create_buffers c0135fbc: c0135f68 t __refile_buffer c0135e6d: c0135e54 t balance_dirty_state c0135eb2: c0135eac T balance_dirty c01dab77: c01dab38 t hook_buffers_to_page_delay c01daf9b: c01daf54 t __pb_block_commit_write_async c01d9f90: c01d9f50 T pagebuf_commit_write c01d9fc1: c01d9f50 T pagebuf_commit_write c01db155: c01dafa0 T __pagebuf_do_delwri c01db17b: c01dafa0 T __pagebuf_do_delwri c01db317: c01db1dc T _pagebuf_file_write c01db493: c01db3d0 T pagebuf_generic_file_write c01bd573: c01bd55c t xfs_setsize_fn c01b8cc5: c01b8c60 T xfs_ilock_ra c01cc126: c01cc104 T xfs_trans_unlocked_item c01b8e2b: c01b8dcc T xfs_iunlock c01bd5c4: c01bd55c t xfs_setsize_fn c01e1802: c01e1320 T xfs_write c01e181c: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4662) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d13f6: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4663) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca097: c02c65b8 T stext_lock c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4664) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c01d9fc1: c01d9f50 T pagebuf_commit_write c01df819: c01df6f8 T linvfs_common_cr f88cf2f2: c042b620 B ___strtok c01d5154: c01d5124 T xfs_rwunlock c027e038: c027dea4 T csum_partial_copy_fromiovecend c0285ae3: c0285ad0 T qdisc_restart c027f9bd: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag c028f26c: c028efd8 T ip_build_xmit c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4665) c01e648d: c01e63e0 T lock_wait c01e657d: c01e6554 T mrupdatef c01e1479: c01e1320 T xfs_write c01b8c94: c01b8c60 T xfs_ilock_ra c01b8d03: c01b8cf0 T xfs_ilock c01e1479: c01e1320 T xfs_write c01e1479: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4666) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca069: c02c65b8 T stext_lock c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4667) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy f88b83aa: c042b620 B ___strtok c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c011349a: c0113038 T schedule c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c01dab77: c01dab38 t hook_buffers_to_page_delay c01daf9b: c01daf54 t __pb_block_commit_write_async c01d9f90: c01d9f50 T pagebuf_commit_write c01db155: c01dafa0 T __pagebuf_do_delwri c01db17b: c01dafa0 T __pagebuf_do_delwri c01db317: c01db1dc T _pagebuf_file_write f88cf2f2: c042b620 B ___strtok c0147ed5: c0147e88 T iget4 c01e58b1: c01e5890 T vn_put c0148084: c014803c T iput c016139a: c01612a8 t nfsd_iget c016141d: c01613b4 t nfsd_get_dentry c01d9ff3: c01d9fdc T pagebuf_flush c01dceab: c01dce80 T fs_flush_pages c01d103e: c01d0f5c t xfs_fsync c01dc8c5: c01dc884 t linvfs_fsync c01632cc: c0163264 T nfsd_sync c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4668) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca097: c02c65b8 T stext_lock c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4670) c01e648d: c01e63e0 T lock_wait c01e657d: c01e6554 T mrupdatef c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01b8c94: c01b8c60 T xfs_ilock_ra c01b8d03: c01b8cf0 T xfs_ilock c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4671) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca069: c02c65b8 T stext_lock c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4672) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca097: c02c65b8 T stext_lock c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4673) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d13f6: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4674) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c01d9fc1: c01d9f50 T pagebuf_commit_write c01df819: c01df6f8 T linvfs_common_cr f88cf2f2: c042b620 B ___strtok c01d5154: c01d5124 T xfs_rwunlock c027e038: c027dea4 T csum_partial_copy_fromiovecend c0285ae3: c0285ad0 T qdisc_restart c027f9bd: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag c028f26c: c028efd8 T ip_build_xmit c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4675) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy c01cb77c: c01cb620 T xfs_trans_unreserve_and_mod_sb c01e23e9: c01e23c0 t _xfs_imap_to_bmap c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c01dab77: c01dab38 t hook_buffers_to_page_delay c01daf9b: c01daf54 t __pb_block_commit_write_async c01d9f90: c01d9f50 T pagebuf_commit_write c01db155: c01dafa0 T __pagebuf_do_delwri c01db17b: c01dafa0 T __pagebuf_do_delwri c01db317: c01db1dc T _pagebuf_file_write f88cf2f2: c042b620 B ___strtok c01d5154: c01d5124 T xfs_rwunlock c0147ed5: c0147e88 T iget4 c01e58b1: c01e5890 T vn_put c0148084: c014803c T iput c016139a: c01612a8 t nfsd_iget c016141d: c01613b4 t nfsd_get_dentry c01d9ff3: c01d9fdc T pagebuf_flush c01dceab: c01dce80 T fs_flush_pages c01d103e: c01d0f5c t xfs_fsync c01dc8c5: c01dc884 t linvfs_fsync c01632cc: c0163264 T nfsd_sync c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4676) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c028c41a: c028c108 T ip_rcv c0136247: c01361ec t create_buffers c0135fbc: c0135f68 t __refile_buffer c0135e6d: c0135e54 t balance_dirty_state c0135eb2: c0135eac T balance_dirty c01dab77: c01dab38 t hook_buffers_to_page_delay c01daf9b: c01daf54 t __pb_block_commit_write_async c01d9f90: c01d9f50 T pagebuf_commit_write c01d9fc1: c01d9f50 T pagebuf_commit_write c01db155: c01dafa0 T __pagebuf_do_delwri c01db17b: c01dafa0 T __pagebuf_do_delwri c01db317: c01db1dc T _pagebuf_file_write c02b3a04: c02b38a8 t unix_stream_sendmsg c01db493: c01db3d0 T pagebuf_generic_file_write c01bd573: c01bd55c t xfs_setsize_fn c01b8cc5: c01b8c60 T xfs_ilock_ra c01cc126: c01cc104 T xfs_trans_unlocked_item c01b8e2b: c01b8dcc T xfs_iunlock c01bd5c4: c01bd55c t xfs_setsize_fn c01e1802: c01e1320 T xfs_write c01e181c: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4677) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca069: c02c65b8 T stext_lock c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4678) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca069: c02c65b8 T stext_lock c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4679) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca069: c02c65b8 T stext_lock c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4680) c01617e9: c01617a8 t find_fh_dentry c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02caed4: c02c65b8 T stext_lock c0163199: c0162ff0 T nfsd_open c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4681) c01e648d: c01e63e0 T lock_wait c01e657d: c01e6554 T mrupdatef c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01b8c94: c01b8c60 T xfs_ilock_ra c01b8d03: c01b8cf0 T xfs_ilock c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4682) c01e648d: c01e63e0 T lock_wait c01e653c: c01e64ec T mraccessf c01d0c96: c01d0c7c t xfs_access c01b8ce6: c01b8c60 T xfs_ilock_ra c01b8d03: c01b8cf0 T xfs_ilock c01d0c96: c01d0c7c t xfs_access c01d0c96: c01d0c7c t xfs_access c01e0171: c01e0154 T linvfs_permission c013d222: c013d1bc T permission c01651cf: c016511c T nfsd_permission c0161f46: c0161b70 T fh_verify c016a00a: c0169f88 T nfs3svc_decode_createargs c0168818: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4684) c01617e9: c01617a8 t find_fh_dentry c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02caed4: c02c65b8 T stext_lock c0160018: c015fd68 T sys_nfsservctl c02c92f2: c02c65b8 T stext_lock c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4685) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy f88b424d: c042b620 B ___strtok f88c3180: c042b620 B ___strtok c0233dbf: c0233d04 T scsi_dispatch_cmd c0233e2c: c0233d04 T scsi_dispatch_cmd c019e987: c019e954 T xfs_bmbt_get_state c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c01981db: c0197f00 T xfs_bmapi c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c01d9f90: c01d9f50 T pagebuf_commit_write c011349a: c0113038 T schedule c01d12d9: c01d1220 t xfs_inactive_free_eofblocks c01cc126: c01cc104 T xfs_trans_unlocked_item c01b8e2b: c01b8dcc T xfs_iunlock c01d12ea: c01d1220 t xfs_inactive_free_eofblocks c01cc126: c01cc104 T xfs_trans_unlocked_item f88cf2f2: c042b620 B ___strtok c01e5889: c01e587c T vn_rele c01d5176: c01d5124 T xfs_rwunlock c0147ed5: c0147e88 T iget4 c01e58b1: c01e5890 T vn_put c0148084: c014803c T iput c016139a: c01612a8 t nfsd_iget c016141d: c01613b4 t nfsd_get_dentry c01d9ff3: c01d9fdc T pagebuf_flush c01dceab: c01dce80 T fs_flush_pages c01d103e: c01d0f5c t xfs_fsync c01dc8c5: c01dc884 t linvfs_fsync c01632cc: c0163264 T nfsd_sync c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4686) c01e648d: c01e63e0 T lock_wait c01e657d: c01e6554 T mrupdatef c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01b8c94: c01b8c60 T xfs_ilock_ra c01b8d03: c01b8cf0 T xfs_ilock c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01d13b8: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4687) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy c01ccafc: c01ccaa0 T xfs_trans_log_buf c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c0136247: c01361ec t create_buffers c0135fbc: c0135f68 t __refile_buffer c0135e6d: c0135e54 t balance_dirty_state c0135eb2: c0135eac T balance_dirty c01dab77: c01dab38 t hook_buffers_to_page_delay c01daf9b: c01daf54 t __pb_block_commit_write_async c01d9f90: c01d9f50 T pagebuf_commit_write c01d9fc1: c01d9f50 T pagebuf_commit_write c01db155: c01dafa0 T __pagebuf_do_delwri c01db17b: c01dafa0 T __pagebuf_do_delwri c01db317: c01db1dc T _pagebuf_file_write c01db493: c01db3d0 T pagebuf_generic_file_write c01bd573: c01bd55c t xfs_setsize_fn c01b8cc5: c01b8c60 T xfs_ilock_ra c01cc126: c01cc104 T xfs_trans_unlocked_item c01b8e2b: c01b8dcc T xfs_iunlock c01bd5c4: c01bd55c t xfs_setsize_fn c01e1802: c01e1320 T xfs_write c01e181c: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4688) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca069: c02c65b8 T stext_lock c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4689) c01e648d: c01e63e0 T lock_wait c01e653c: c01e64ec T mraccessf c01d0c96: c01d0c7c t xfs_access c01b8ce6: c01b8c60 T xfs_ilock_ra c01b8d03: c01b8cf0 T xfs_ilock c01d0c96: c01d0c7c t xfs_access c01d0c96: c01d0c7c t xfs_access c01e0171: c01e0154 T linvfs_permission c013d222: c013d1bc T permission c01651cf: c016511c T nfsd_permission c0161f46: c0161b70 T fh_verify c016a00a: c0169f88 T nfs3svc_decode_createargs c0168818: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4690) c01617e9: c01617a8 t find_fh_dentry c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02caed4: c02c65b8 T stext_lock c0163199: c0162ff0 T nfsd_open c01636f0: c01635c8 T nfsd_write c0239f7a: c0239e18 T scsi_io_completion c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4691) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02cae4a: c02c65b8 T stext_lock c01dbb86: c01dba84 T _pagebuf_find_lockable_buffer c01cc9bd: c01cc98c T xfs_trans_brelse c01e626f: c01e6260 T kmem_zone_free c019fe70: c019fe2c T xfs_btree_del_cursor c01ccafc: c01ccaa0 T xfs_trans_log_buf c01dbcb9: c01dbc84 T _pagebuf_get_lockable_buffer c01d85ef: c01d85b8 T pagebuf_get c01cc5bd: c01cc4c8 T xfs_trans_get_buf c01b4bbf: c01b474c t xfs_ialloc_ag_alloc c0253400: c0253324 t ncr_prepare_nego c01d85ef: c01d85b8 T pagebuf_get c01cc947: c01cc688 T xfs_trans_read_buf c01b611f: c01b60c4 T xfs_ialloc_read_agi c01b529a: c01b518c T xfs_dialloc c01a77df: c01a77c4 T xfs_dir2_block_lookup c01ba637: c01ba5d8 T xfs_ialloc c017fdca: c017fda0 T xfs_trans_mod_dquot c01cdb50: c01cdad8 T xfs_dir_ialloc c01d23dc: c01d1fc4 t xfs_create c01df819: c01df6f8 T linvfs_common_cr f88cf2f2: c042b620 B ___strtok f88cf2f2: c042b620 B ___strtok c01a5f62: c01a5eac t xfs_dir2_lookup c027e038: c027dea4 T csum_partial_copy_fromiovecend c0285ae3: c0285ad0 T qdisc_restart c027f9bd: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag c028f26c: c028efd8 T ip_build_xmit c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4692) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c01d9fc1: c01d9f50 T pagebuf_commit_write c01df819: c01df6f8 T linvfs_common_cr f88cf2f2: c042b620 B ___strtok c01d5154: c01d5124 T xfs_rwunlock c027e038: c027dea4 T csum_partial_copy_fromiovecend c0285ae3: c0285ad0 T qdisc_restart c027f9bd: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag c028f26c: c028efd8 T ip_build_xmit c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4693) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy c028c41a: c028c108 T ip_rcv c010a718: c010a713 t call_do_IRQ f88c3180: c042b620 B ___strtok c0233e3c: c0233d04 T scsi_dispatch_cmd c019e987: c019e954 T xfs_bmbt_get_state c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c01981db: c0197f00 T xfs_bmapi c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c01d9f90: c01d9f50 T pagebuf_commit_write c011349a: c0113038 T schedule c01d12d9: c01d1220 t xfs_inactive_free_eofblocks c01b8e2b: c01b8dcc T xfs_iunlock c01d12ea: c01d1220 t xfs_inactive_free_eofblocks c01d1a0a: c01d1940 t xfs_release f88cf2f2: c042b620 B ___strtok c01e5889: c01e587c T vn_rele c01d5176: c01d5124 T xfs_rwunlock c0147ed5: c0147e88 T iget4 c01e58b1: c01e5890 T vn_put c0148084: c014803c T iput c016139a: c01612a8 t nfsd_iget c016141d: c01613b4 t nfsd_get_dentry c01d9ff3: c01d9fdc T pagebuf_flush c01dceab: c01dce80 T fs_flush_pages c01d103e: c01d0f5c t xfs_fsync c01dc8c5: c01dc884 t linvfs_fsync c01632cc: c0163264 T nfsd_sync c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4694) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca069: c02c65b8 T stext_lock c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4695) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c01d9fc1: c01d9f50 T pagebuf_commit_write c01df819: c01df6f8 T linvfs_common_cr f88cf2f2: c042b620 B ___strtok c01d5154: c01d5124 T xfs_rwunlock c027e038: c027dea4 T csum_partial_copy_fromiovecend c0285ae3: c0285ad0 T qdisc_restart c027f9bd: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag c028f26c: c028efd8 T ip_build_xmit c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4696) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d13f6: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4697) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d13f6: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4698) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca097: c02c65b8 T stext_lock c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4699) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c01d9fc1: c01d9f50 T pagebuf_commit_write c0112caa: c0112c48 t reschedule_idle c01df819: c01df6f8 T linvfs_common_cr c0105a46: c0105a30 T __up c0105c74: c0105c6c T __up_wakeup f88b8c9f: c042b620 B ___strtok f88cf2f2: c042b620 B ___strtok c0108414: c01083c4 T handle_IRQ_event c0108626: c0108560 T do_IRQ c010a718: c010a713 t call_do_IRQ c027fb92: c027f87c T dev_queue_xmit c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag c028f26c: c028efd8 T ip_build_xmit c01cc126: c01cc104 T xfs_trans_unlocked_item c01cc126: c01cc104 T xfs_trans_unlocked_item c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4700) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca097: c02c65b8 T stext_lock c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4703) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02caed4: c02c65b8 T stext_lock c0163199: c0162ff0 T nfsd_open c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4704) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy f88b4768: c042b620 B ___strtok f88b83aa: c042b620 B ___strtok c01e23e9: c01e23c0 t _xfs_imap_to_bmap c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c01dab77: c01dab38 t hook_buffers_to_page_delay c01daf9b: c01daf54 t __pb_block_commit_write_async c01d9f90: c01d9f50 T pagebuf_commit_write c01d9fc1: c01d9f50 T pagebuf_commit_write c01db155: c01dafa0 T __pagebuf_do_delwri c01db17b: c01dafa0 T __pagebuf_do_delwri c01db317: c01db1dc T _pagebuf_file_write f88cf2f2: c042b620 B ___strtok c01d5154: c01d5124 T xfs_rwunlock c0147ed5: c0147e88 T iget4 c01e58b1: c01e5890 T vn_put c0148084: c014803c T iput c016139a: c01612a8 t nfsd_iget c016141d: c01613b4 t nfsd_get_dentry c01d9ff3: c01d9fdc T pagebuf_flush c01dceab: c01dce80 T fs_flush_pages c01d103e: c01d0f5c t xfs_fsync c01dc8c5: c01dc884 t linvfs_fsync c01632cc: c0163264 T nfsd_sync c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4705) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d13f6: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c0108414: c01083c4 T handle_IRQ_event c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4706) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d13f6: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4707) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy c01c00f3: c01c00dc T xlog_assign_tail_lsn c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c0136247: c01361ec t create_buffers c0135fbc: c0135f68 t __refile_buffer c0135e6d: c0135e54 t balance_dirty_state c0135eb2: c0135eac T balance_dirty c01dab77: c01dab38 t hook_buffers_to_page_delay c01daf9b: c01daf54 t __pb_block_commit_write_async c01d9f90: c01d9f50 T pagebuf_commit_write c01d9fc1: c01d9f50 T pagebuf_commit_write c01db155: c01dafa0 T __pagebuf_do_delwri c01db17b: c01dafa0 T __pagebuf_do_delwri c01db317: c01db1dc T _pagebuf_file_write c01db493: c01db3d0 T pagebuf_generic_file_write c01bd573: c01bd55c t xfs_setsize_fn c01b8cc5: c01b8c60 T xfs_ilock_ra c01cc126: c01cc104 T xfs_trans_unlocked_item c01b8e2b: c01b8dcc T xfs_iunlock c01bd5c4: c01bd55c t xfs_setsize_fn c01e1802: c01e1320 T xfs_write c01e181c: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4708) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01e1f31: c01e1b70 T xfs_strategy c0233dbf: c0233d04 T scsi_dispatch_cmd c0233e2c: c0233d04 T scsi_dispatch_cmd c01e23e9: c01e23c0 t _xfs_imap_to_bmap c01e0391: c01e030c T linvfs_pb_bmap c01db90e: c01db8a8 t pagebuf_delalloc_convert c01daaf7: c01daa60 T pagebuf_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c01e053e: c01e04fc t linvfs_write_full_page c01e030c: c01e030c T linvfs_pb_bmap c0134d7b: c0134d50 t write_buffer c0135ab2: c0135a24 T fsync_inode_buffers c01dab77: c01dab38 t hook_buffers_to_page_delay c01daf9b: c01daf54 t __pb_block_commit_write_async c01d9f90: c01d9f50 T pagebuf_commit_write c01d9fc1: c01d9f50 T pagebuf_commit_write c01db155: c01dafa0 T __pagebuf_do_delwri c01db17b: c01dafa0 T __pagebuf_do_delwri c01db317: c01db1dc T _pagebuf_file_write f88cf2f2: c042b620 B ___strtok c01d5154: c01d5124 T xfs_rwunlock c0147ed5: c0147e88 T iget4 c01e58b1: c01e5890 T vn_put c0148084: c014803c T iput c016139a: c01612a8 t nfsd_iget c016141d: c01613b4 t nfsd_get_dentry c01d9ff3: c01d9fdc T pagebuf_flush c01dceab: c01dce80 T fs_flush_pages c01d103e: c01d0f5c t xfs_fsync c01dc8c5: c01dc884 t linvfs_fsync c01632cc: c0163264 T nfsd_sync c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4709) c01617e9: c01617a8 t find_fh_dentry c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02caed4: c02c65b8 T stext_lock c0163199: c0162ff0 T nfsd_open c01636f0: c01635c8 T nfsd_write c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4710) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d13f6: c01d1220 t xfs_inactive_free_eofblocks c01d19c6: c01d1940 t xfs_release c01d516d: c01d5124 T xfs_rwunlock c01e194f: c01e1320 T xfs_write c01dc7e4: c01dc524 t linvfs_write c01636f0: c01635c8 T nfsd_write c0108414: c01083c4 T handle_IRQ_event c016871e: c0168624 t nfsd3_proc_write c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4711) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca097: c02c65b8 T stext_lock c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4712) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca097: c02c65b8 T stext_lock c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4713) c01e68ca: c01e67ec T _sv_wait c01c15bd: c01c1548 t xlog_grant_log_space c01bfc19: c01bfb98 T xfs_log_reserve c01cb04d: c01cafc0 T xfs_trans_reserve c01d221b: c01d1fc4 t xfs_create c01df819: c01df6f8 T linvfs_common_cr c02a89db: c02a896c t udp_queue_rcv_skb c02a8d52: c02a8c1c T udp_rcv c028c08c: c028bfb4 T ip_local_deliver c028c41a: c028c108 T ip_rcv c027c62c: c027c620 T kfree_skbmem c028007e: c027ff14 t net_rx_action c011a28f: c011a220 T do_softirq c02ccd0d: c02c65b8 T stext_lock c028e63e: c028e550 T ip_output c02a7ef8: c02a7ef8 t udp_getfrag f88b4787: c042b620 B ___strtok f88b4768: c042b620 B ___strtok c01df960: c01df948 T linvfs_create c013e340: c013e24c T vfs_create c0163f34: c0163ca0 T nfsd_create_v3 c0168884: c016873c t nfsd3_proc_create c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread task: nfsd (pid: 4714) c0105ab4: c0105a48 T __down c0105c50: c0105c48 T __down_failed c02ca069: c02c65b8 T stext_lock c0163902: c01638b8 T nfsd_commit c0169679: c0169598 t nfsd3_proc_commit c015fc63: c015fb94 t nfsd_dispatch c02bdae5: c02bd858 T svc_process c015fa09: c015f7bc t nfsd c0105594: c010556c T kernel_thread From owner-linux-xfs@oss.sgi.com Tue Mar 26 10:10:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QIA4k02696 for linux-xfs-outgoing; Tue, 26 Mar 2002 10:10:04 -0800 Received: from mailnet.consensys.com ([209.47.40.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QIA0q02670 for ; Tue, 26 Mar 2002 10:10:00 -0800 Received: from Francis ([209.47.40.10]) by mailnet.consensys.com (8.11.6/8.11.2) with SMTP id g2QD6iW14221 for ; Tue, 26 Mar 2002 13:06:44 GMT Message-ID: <007901c1d4f1$c9caea10$8d02a8c0@consensys.com> From: "Francis Qu" To: "Linux XFS" Subject: DMAPI Managed Region Date: Tue, 26 Mar 2002 13:12:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I set DM_REGION_WRITE | DM_REGION_TRUNC on a file. When I use vi to edit the file, the write event is not generated as expected. The program is still waiting and nothing happens. But the managed regions are cleared. Any ideas on what happened in XFS? Kernel: 2.4.18 DMAPI 2.0.0 Thanks, Francis Qu From owner-linux-xfs@oss.sgi.com Tue Mar 26 11:11:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QJB1g04036 for linux-xfs-outgoing; Tue, 26 Mar 2002 11:11: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 g2QJAvq04010 for ; Tue, 26 Mar 2002 11:10: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 g2QKDFBA008111 for ; Tue, 26 Mar 2002 12:13:16 -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 NAA53798; Tue, 26 Mar 2002 13:11:59 -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 NAA24430; Tue, 26 Mar 2002 13:11:59 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id NAA22691; Tue, 26 Mar 2002 13:11:59 -0600 (CST) Message-Id: <200203261911.NAA22691@slobber.americas.sgi.com> To: "Francis Qu" cc: "Linux XFS" Subject: Re: DMAPI Managed Region Date: Tue, 26 Mar 2002 13:11:59 -0600 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "Francis Qu" >I set DM_REGION_WRITE | DM_REGION_TRUNC on a file. When I use vi to edit the >file, the write event is not generated as expected. The program is still >waiting and nothing happens. But the managed regions are cleared. Any ideas >on what happened in XFS? I think vi doesn't work that way. It doesn't write to that same file, it replaces the file. Compare the before-and-after inode numbers, or the before-and-after filehandles. I bet you'll get a destroy event, if you register for it. (still haven't looked at your set_region problem) Dean From owner-linux-xfs@oss.sgi.com Tue Mar 26 12:08:29 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QK8TC05282 for linux-xfs-outgoing; Tue, 26 Mar 2002 12:08:29 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QK8Hq05256 for ; Tue, 26 Mar 2002 12:08:17 -0800 Received: (qmail 11560 invoked by uid 500); 26 Mar 2002 20:10:05 -0000 Subject: Re: TAKE - shrink xfs inode From: Austin Gonyou To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <200203261617.g2QGHm619038@jen.americas.sgi.com> References: <200203261617.g2QGHm619038@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 26 Mar 2002 14:10:05 -0600 Message-Id: <1017173405.11465.9.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is there data around this about any possible changes in performance of either file writes/reads/deletes, or general memory utilization during writes/reads/deletes? Specifically, it takes n long to delete x number of files, or takes n long to create x number of directories, or takes n long to read x number of files or x number of megs into memory, etc? The reason I ask is that news and mail servers seem to be the most common file-corruption witnesses, could this help them? On Tue, 2002-03-26 at 10:17, Steve Lord wrote: > This gets the xfs inode down to 400 bytes, and as a consequence we can > fit 10 into a page now. So we reduce the slabcache memory consumption > of xfs. > > Date: Tue Mar 26 08:19:25 PST 2002 > Workarea: jen.americas.sgi.com:/src/lord/xfs-ishrink > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > Modid: 2.4.x-xfs:slinx:114887a > linux/fs/xfs/xfsidbg.c - 1.177 > - cleanup inode debug functions to remove fields > > linux/fs/xfs/xfs_rw.h - 1.62 > - prototype change for xfs_inval_cached_pages > > linux/fs/xfs/xfs_rw.c - 1.353 > - make xfs_inval_cached_pages take a parameter indicating the > lock state of the iolock. > > linux/fs/xfs/xfs_vnodeops.c - 1.520 > - remove usage of i_dev > > linux/fs/xfs/xfs_itable.c - 1.102 > - remove i_dev > > linux/fs/xfs/xfs_dmapi.c - 1.50 > - i_dev replaced with i_mount->m_dev > > linux/fs/xfs/xfs_inode_item.c - 1.97 > - access i_pincount via function now, it is an atomic_t > > linux/fs/xfs/xfs_iocore.c - 1.28 > - make io_lock and io_iolock debug only > > linux/fs/xfs/xfs_vfsops.c - 1.339 > - access i_pincount via function now, it is an atomic_t > > linux/fs/xfs/xfs_dfrag.c - 1.28 > - Add parameter to xfs_inval_cached_pages indicating ilock state > > linux/fs/xfs/xfs_iget.c - 1.152 > - replace the sv and spinlock for inode pinning with a waitqueue > and an > atomic_t > > linux/fs/xfs/xfs_mount.c - 1.276 > - remove i_dev usage > > linux/fs/xfs/xfs_inode.c - 1.329 > - i_dev replaced with i_mount->m_dev, remove assert references > to > io_queued_bufs and use lighter weight implementation for inode > pinning. > > linux/fs/xfs/xfs_inode.h - 1.157 > - Remove unused fields in the xfs_inode and xfs_iocore > structures > > linux/fs/xfs/linux/xfs_lrw.c - 1.129 > - Add parameter to xfs_inval_cached_pages indicating ilock state > > linux/include/linux/xfs_support/mrlock.h - 1.3 > - shrink mrlock 4 more bytes > -- 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 26 12:12:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QKC2R05447 for linux-xfs-outgoing; Tue, 26 Mar 2002 12:12:02 -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 g2QKBwq05420 for ; Tue, 26 Mar 2002 12:11:58 -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 g2QLEGBA013899 for ; Tue, 26 Mar 2002 13:14:16 -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 OAA54001; Tue, 26 Mar 2002 14:13: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 OAA25878; Tue, 26 Mar 2002 14:13:00 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2QK9gS12208; Tue, 26 Mar 2002 14:09:42 -0600 Subject: Re: TAKE - shrink xfs inode From: Steve Lord To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1017173405.11465.9.camel@UberGeek> References: <200203261617.g2QGHm619038@jen.americas.sgi.com> <1017173405.11465.9.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Mar 2002 14:09:42 -0600 Message-Id: <1017173382.19655.98.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-26 at 14:10, Austin Gonyou wrote: > Is there data around this about any possible changes in performance of > either file writes/reads/deletes, or general memory utilization during > writes/reads/deletes? > > Specifically, it takes n long to delete x number of files, or takes n > long to create x number of directories, or takes n long to read x number > of files or x number of megs into memory, etc? > > The reason I ask is that news and mail servers seem to be the most > common file-corruption witnesses, could this help them? > > The only thing this really does is fit more inodes in a page, and hence make xfs use less memory to operate. Using less memory will help some loads. 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 26 12:18:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QKIHF05682 for linux-xfs-outgoing; Tue, 26 Mar 2002 12:18:17 -0800 Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QKIBq05656 for ; Tue, 26 Mar 2002 12:18:11 -0800 Received: (qmail 11832 invoked by uid 500); 26 Mar 2002 20:20:01 -0000 Subject: Re: TAKE - shrink xfs inode From: Austin Gonyou To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1017173382.19655.98.camel@jen.americas.sgi.com> References: <1017173382.19655.98.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 26 Mar 2002 14:20:01 -0600 Message-Id: <1017174001.11787.3.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk That sounds about right, I was just curious if it was in any way possibly related to some of the corruption issues. And as such, if it were, then that might lead into some performance related issues. Thanks much! On Tue, 2002-03-26 at 14:09, Steve Lord wrote: > On Tue, 2002-03-26 at 14:10, Austin Gonyou wrote: > > Is there data around this about any possible changes in performance of > > either file writes/reads/deletes, or general memory utilization during > > writes/reads/deletes? > > > > Specifically, it takes n long to delete x number of files, or takes n > > long to create x number of directories, or takes n long to read x > number > > of files or x number of megs into memory, etc? > > > > The reason I ask is that news and mail servers seem to be the most > > common file-corruption witnesses, could this help them? > > > > > > The only thing this really does is fit more inodes in a page, and hence > make xfs use less memory to operate. Using less memory will help some > loads. > > 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 Tue Mar 26 13:03:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QL3J107541 for linux-xfs-outgoing; Tue, 26 Mar 2002 13:03:19 -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 g2QL3Bq07511 for ; Tue, 26 Mar 2002 13:03:11 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2QM5UBA018977 for ; Tue, 26 Mar 2002 14:05:30 -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 NAA16454; Tue, 26 Mar 2002 13:04:58 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id C8F58136559; Tue, 26 Mar 2002 13:04:57 -0800 (PST) Subject: Re: files in /etc/xinetd.d become 0 byte size From: Florin Andrei To: Simon Matter Cc: linux-xfs In-Reply-To: <3C961055.FF5DF9C6@ch.sauter-bc.com> References: <3C961055.FF5DF9C6@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 26 Mar 2002 13:04:57 -0800 Message-Id: <1017176697.16815.21.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-03-18 at 08:05, Simon Matter wrote: > > The problem I have is that after some installation and configuration > work, some xinetd config files in /etc/xinetd.d became 0 byte size. It's been a long time since i started to always do "sync; reboot" instead of just "reboot". I've always felt this is safer. But you're right, the OS should do that for me, at the right time. Therefore, i've submitted a bug report to bugzilla.redhat.com: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62025 Please go to the bug report and add your own comments (actually, everyone's invited to do that). I have a feeling that they will dismiss it as "XFS specific" or something like that, which i believe would be wrong. But if quite a few people will agree with the solution proposed in the bug report, maybe RH will fix the init scripts. ;-) -- Florin Andrei "Sorry judge, we would like to publish the file formats, but the data is not stored in files. It is stored in a database that is an indivisible part of the operating system." - a potential future Microsoft excuse From owner-linux-xfs@oss.sgi.com Tue Mar 26 13:31:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QLVIJ08707 for linux-xfs-outgoing; Tue, 26 Mar 2002 13:31:18 -0800 Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2QLV3q08650 for ; Tue, 26 Mar 2002 13:31:03 -0800 Received: from warp9.koschikode.com (pD9EB1A95.dip.t-dialin.net [217.235.26.149]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 23CDBF4E0; Tue, 26 Mar 2002 22:33:04 +0100 (CET) Received: from koschikode.com (kaplah.koschikode.com [192.168.200.15]) by warp9.koschikode.com (Postfix) with ESMTP id 58326B8; Tue, 26 Mar 2002 22:32:53 +0100 (CET) Message-ID: <3CA0E904.1080907@koschikode.com> Date: Tue, 26 Mar 2002 22:32:52 +0100 From: Juri Haberland Organization: totally unorganized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020321 X-Accept-Language: de-DE, en MIME-Version: 1.0 To: Florin Andrei Cc: Simon Matter , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <1017176697.16815.21.camel@stantz.corp.sgi.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Florin Andrei wrote: > It's been a long time since i started to always do "sync; reboot" > instead of just "reboot". I've always felt this is safer. > But you're right, the OS should do that for me, at the right time. > Therefore, i've submitted a bug report to bugzilla.redhat.com: > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62025 > > Please go to the bug report and add your own comments (actually, > everyone's invited to do that). I have a feeling that they will dismiss > it as "XFS specific" or something like that, which i believe would be > wrong. > But if quite a few people will agree with the solution proposed in the > bug report, maybe RH will fix the init scripts. ;-) Ahm, Florin, I think that the conclusion of this thread was that even multiple syncs don't help - instead you could just use 'sleep 30'. The bug must be somewhere in the kernel and it would be nice to know, whether it shows up with ext2/3 also or not. And also 2.4.18 just works with the same init script without the need of just a single 'sync' or 'sleep 30'... Juri From owner-linux-xfs@oss.sgi.com Tue Mar 26 13:31:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QLV4v08651 for linux-xfs-outgoing; Tue, 26 Mar 2002 13:31: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 g2QLUsq08621 for ; Tue, 26 Mar 2002 13:30: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 g2QMfkkw024354 for ; Tue, 26 Mar 2002 16:41:47 -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 IAA29265; Wed, 27 Mar 2002 08:31:54 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA47585; Wed, 27 Mar 2002 08:31:53 +1100 (AEDT) Date: Wed, 27 Mar 2002 08:31:52 +1100 From: Nathan Scott To: Thomas Winkler Cc: linux-xfs@oss.sgi.com Subject: Re: default acl on directory problem Message-ID: <20020327083152.D45001@wobbly.melbourne.sgi.com> References: <1016808160.5266.19.camel@janus> <20020325160807.B5356@boing.melbourne.sgi.com> <1017137882.1405.13.camel@janus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1017137882.1405.13.camel@janus>; from t.winkler@itcampus.de on Tue, Mar 26, 2002 at 11:18:00AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Tue, Mar 26, 2002 at 11:18:00AM +0100, Thomas Winkler wrote: > Am Mon, 2002-03-25 um 06.08 schrieb Timothy Shimmin: > > Looking at getfacl(1), the "#effective" comment refers > > to the effect the mask ACE has on all groups and named user > > ACEs whose permissions are reduced. > > In your case, your mask ACE is "r-x" so this will > > potentially reduce permissions for group and named-user ACEs. > > I guess the comment is there as a reminder of what the mask ACE is doing. > > > > So did you have a different command to set the acl for "otheruser" > > which had a different mask ACE ??? > > since we are running many systems on xfs for quite a while now i had > some more machines i was able to test. it seems as if this problem only > occurs on 1 out of 3 systems i tried with. all are running the same Perhaps these 1 out of 3 are incorrectly set up (but maybe not, just a theory)... > kernel. first i thought i did forget to update all xfs related progs > (acl, attr, xfsprogs...) but nothing changed after an update to the > versions from the 2.4.16 kernel. now i am kind of lost. it seems to work ^^^^^^ 2.4.16 or 2.4.18? either way, you have version problems below... > the way i want it to, but unfortunatelay not on the system it has to. > > i also checked kernel settings and umask entries for the users. > > what could cause this behaviour? > > now i am using (all devels installed): > xfsprogs-1.3.19-0 > attr-2.0.0-0 > acl-1.1.4-0 > dmapi-0.3.0-0 if your kernel version == 2.4.16, your "attr" package is too new. if your kernel version == 2.4.18, everything except for "attr" is too old. ie. using kernel < 2.4.18, all tools must be < 2.0.0; and using kernel >=2.4.18, all tools must be >=2.0.0. Perhaps 1 in 3 of your machines have mismatched kernel/userspace? > are there any known issues? could find any on my list archives... > > > BTW, general userland ACL questions are best sent to > > acl-devel@bestbits.at (check out: http://acl.bestbits.at/) > > now that we're using common userspace code for ext2, ext3 and XFS. > > yes, but i searched lots of places and could only find solaris > questions, concerning the same behaviour. in this cases it where bugs, > thats why i asked here. i am sorry... It's better to ask there because the author of the acl tools hangs out over there, whereas we will have to go dig through his code to try to answer your questions, which is inefficient for everyone. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Mar 26 13:48:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QLmua09136 for linux-xfs-outgoing; Tue, 26 Mar 2002 13:48:56 -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 g2QLmpq09109 for ; Tue, 26 Mar 2002 13:48:51 -0800 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g2QLp8V7080710; Tue, 26 Mar 2002 22:51:09 +0100 (CET) Message-Id: <4.3.2.7.2.20020326224601.039a8638@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Mar 2002 22:48:15 +0100 To: Juri Haberland , Florin Andrei From: Seth Mos Subject: Re: files in /etc/xinetd.d become 0 byte size Cc: Simon Matter , linux-xfs In-Reply-To: <3CA0E904.1080907@koschikode.com> References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <1017176697.16815.21.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 22:32 26-3-2002 +0100, Juri Haberland wrote: >Ahm, Florin, I think that the conclusion of this thread was that even >multiple syncs don't help - instead you could just use 'sleep 30'. > >The bug must be somewhere in the kernel and it would be nice to know, >whether it shows up with ext2/3 also or not. And also 2.4.18 just works >with the same init script without the need of just a single 'sync' or >'sleep 30'... I believe this occured on a software raid 1 root filesystem. And doing a sync before remounting may be called overkill but I have absolutely no objection to it being there. It can only do good there and I can't see how this could be harmfull in any way. 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 Tue Mar 26 13:49:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QLn6e09197 for linux-xfs-outgoing; Tue, 26 Mar 2002 13:49:06 -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 g2QLn0q09159 for ; Tue, 26 Mar 2002 13:49:00 -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 g2QLpJ6G023809 for ; Tue, 26 Mar 2002 13:51:19 -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 NAA03834; Tue, 26 Mar 2002 13:50:48 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 15BB5136559; Tue, 26 Mar 2002 13:50:46 -0800 (PST) Subject: Re: files in /etc/xinetd.d become 0 byte size From: Florin Andrei To: Juri Haberland Cc: Simon Matter , linux-xfs In-Reply-To: <3CA0E904.1080907@koschikode.com> References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <1017176697.16815.21.camel@stantz.corp.sgi.com> <3CA0E904.1080907@koschikode.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 26 Mar 2002 13:50:46 -0800 Message-Id: <1017179446.17163.29.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-26 at 13:32, Juri Haberland wrote: > Florin Andrei wrote: > > > It's been a long time since i started to always do "sync; reboot" > > instead of just "reboot". I've always felt this is safer. > > But you're right, the OS should do that for me, at the right time. > > Therefore, i've submitted a bug report to bugzilla.redhat.com: > > > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62025 > > Ahm, Florin, I think that the conclusion of this thread was that even > multiple syncs don't help - instead you could just use 'sleep 30'. Yes, that's true for this particular bug. But the patch that i included in the bug report does sync AND sleep. That should cover this bug, and also some other unforeseen bugs. Since "sync is cheap" when in runlevel 6, i guess it's a good idea to do it anyway. There are so many things that could go wrong during shutdown. > 'sleep 30'... This should be tunable in /etc/sysconfig/whatever. One is not supposed to edit the init scripts to do parameter tuning. -- Florin Andrei "Sorry judge, we would like to publish the file formats, but the data is not stored in files. It is stored in a database that is an indivisible part of the operating system." - a potential future Microsoft excuse From owner-linux-xfs@oss.sgi.com Tue Mar 26 14:15:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QMFeA09858 for linux-xfs-outgoing; Tue, 26 Mar 2002 14:15:40 -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 g2QMFSq09832 for ; Tue, 26 Mar 2002 14:15:28 -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 g2QNHkBA025012 for ; Tue, 26 Mar 2002 15:17:46 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA35374; Wed, 27 Mar 2002 09:16:29 +1100 (EST) Date: Wed, 27 Mar 2002 09:16:29 +1100 (EST) From: Nathan Scott Message-Id: <200203262216.JAA35374@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: TAKE - acl 2.0.5 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Merges in several changes from Andreas, incl. a complete set of man pages for libacl. Date: Tue Mar 26 14:12:14 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:114947a cmd/acl/man/man3/acl_delete_perm.3 - 1.1 cmd/acl/man/man3/acl_to_text.3 - 1.1 cmd/acl/man/man3/acl_to_any_text.3 - 1.1 cmd/acl/man/man3/acl_set_tag_type.3 - 1.1 cmd/acl/doc/old-acl.5 - 1.1 cmd/acl/man/man3/acl_set_qualifier.3 - 1.1 cmd/acl/man/man3/acl_set_permset.3 - 1.1 cmd/acl/man/man3/acl_set_file.3 - 1.1 cmd/acl/libacl/__acl_to_any_text.c - 1.1 cmd/acl/man/man3/acl_set_fd.3 - 1.1 cmd/acl/man/man3/acl_init.3 - 1.1 cmd/acl/man/man3/acl_get_tag_type.3 - 1.1 cmd/acl/man/man3/acl_get_qualifier.3 - 1.1 cmd/acl/man/man3/acl_get_permset.3 - 1.1 cmd/acl/man/man3/acl_get_perm.3 - 1.1 cmd/acl/man/man3/acl_get_entry.3 - 1.1 cmd/acl/man/man3/acl_from_mode.3 - 1.1 cmd/acl/man/man3/acl_extended_file.3 - 1.1 cmd/acl/man/man3/acl_add_perm.3 - 1.1 cmd/acl/man/man3/acl_calc_mask.3 - 1.1 cmd/acl/man/man3/acl_check.3 - 1.1 cmd/acl/man/man3/acl_clear_perms.3 - 1.1 cmd/acl/man/man3/acl_cmp.3 - 1.1 cmd/acl/man/man3/acl_copy_entry.3 - 1.1 cmd/acl/man/man3/acl_extended_fd.3 - 1.1 cmd/acl/man/man3/acl_copy_int.3 - 1.1 cmd/acl/man/man3/acl_create_entry.3 - 1.1 cmd/acl/man/man3/acl_error.3 - 1.1 cmd/acl/man/man3/acl_delete_entry.3 - 1.1 cmd/acl/man/man3/acl_equiv_mode.3 - 1.1 cmd/acl/man/man3/acl_entries.3 - 1.1 cmd/acl/VERSION - 1.22 cmd/acl/doc/CHANGES - 1.26 cmd/acl/doc/Makefile - 1.8 cmd/acl/man/Makefile - 1.5 cmd/acl/man/man1/Makefile - 1.5 cmd/acl/man/man3/acl_free.3 - 1.6 cmd/acl/man/man3/acl_size.3 - 1.5 cmd/acl/man/man3/acl_copy_ext.3 - 1.5 cmd/acl/man/man3/acl_from_text.3 - 1.6 cmd/acl/man/man3/acl_get_file.3 - 1.6 cmd/acl/man/man3/Makefile - 1.4 cmd/acl/man/man3/acl_delete_def_file.3 - 1.5 cmd/acl/man/man3/acl_get_fd.3 - 1.6 cmd/acl/man/man3/acl_valid.3 - 1.5 cmd/acl/man/man3/acl_dup.3 - 1.5 cmd/acl/man/man5/acl.5 - 1.11 cmd/acl/include/libacl.h - 1.8 cmd/acl/debian/changelog - 1.17 cmd/acl/libacl/Makefile - 1.10 cmd/acl/setfacl/do_set.c - 1.4 cmd/acl/libacl/acl_set_file_mode.c - 1.3 cmd/acl/libacl/acl_set_fd_mode.c - 1.3 cmd/acl/libacl/acl_get_file_mode.c - 1.3 cmd/acl/libacl/acl_get_file.c - 1.3 cmd/acl/libacl/acl_get_fd_mode.c - 1.3 cmd/acl/libacl/acl_get_fd.c - 1.3 cmd/acl/getfacl/getfacl.c - 1.3 - bump version number to 2.0.5 - section 3 added to man pages, some code reorganisation in libacl to be more p1003.1eD17 compliant. From owner-linux-xfs@oss.sgi.com Tue Mar 26 15:01:05 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2QN15e11932 for linux-xfs-outgoing; Tue, 26 Mar 2002 15:01:05 -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 g2QN0vq11886 for ; Tue, 26 Mar 2002 15:00:57 -0800 Received: from idcomm.com (IDENT:TLjqbBGhBJ0Z8J0AyE5QPep9VbcuPjgp@tnt01-ppp-055.idcomm.com [216.98.194.55]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g2QN3pb15057 for ; Tue, 26 Mar 2002 16:03:51 -0700 Message-ID: <3CA0FE5C.E1715ED@idcomm.com> Date: Tue, 26 Mar 2002 16:03:56 -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 Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <1017176697.16815.21.camel@stantz.corp.sgi.com> <3CA0E904.1080907@koschikode.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Juri Haberland wrote: > > Florin Andrei wrote: > > > It's been a long time since i started to always do "sync; reboot" > > instead of just "reboot". I've always felt this is safer. > > But you're right, the OS should do that for me, at the right time. > > Therefore, i've submitted a bug report to bugzilla.redhat.com: > > > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62025 > > > > Please go to the bug report and add your own comments (actually, > > everyone's invited to do that). I have a feeling that they will dismiss > > it as "XFS specific" or something like that, which i believe would be > > wrong. > > But if quite a few people will agree with the solution proposed in the > > bug report, maybe RH will fix the init scripts. ;-) > > Ahm, Florin, I think that the conclusion of this thread was that even > multiple syncs don't help - instead you could just use 'sleep 30'. > > The bug must be somewhere in the kernel and it would be nice to know, > whether it shows up with ext2/3 also or not. And also 2.4.18 just works > with the same init script without the need of just a single 'sync' or > 'sleep 30'... > > Juri A script that uses fuser on files or directories that are known to have problems could be quite useful. If they are not surviving with sync called (still must probably wait a few seconds), and the kernel has a problem, there is a good chance that it is because something is holding those files open. Perhaps a script that does nothing more than write syncronously to a special log file to name users of particular files or directories would give some clues. D. Stimits, stimits@idcomm.com From owner-linux-xfs@oss.sgi.com Tue Mar 26 16:26:34 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R0QYg13709 for linux-xfs-outgoing; Tue, 26 Mar 2002 16:26: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 g2R0QVq13682 for ; Tue, 26 Mar 2002 16:26:31 -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 g2R0Sl6G031291 for ; Tue, 26 Mar 2002 16:28:48 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA44358; Wed, 27 Mar 2002 11:27:29 +1100 (EST) Date: Wed, 27 Mar 2002 11:27:29 +1100 (EST) From: Nathan Scott Message-Id: <200203270027.LAA44358@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: TAKE - acl build fix Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Mar 26 16:27:09 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:114965a acl/man/Makefile - 1.6 acl/man/man5/Makefile - 1.5 acl/chacl/chacl.c - 1.11 acl/include/libacl.h - 1.9 acl/libacl/libacl.h - 1.3 acl/libacl/acl_to_text.c - 1.4 acl/libacl/acl_to_any_text.c - 1.4 - missed part of Andreas last round of patches. From owner-linux-xfs@oss.sgi.com Tue Mar 26 16:57:23 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R0vNB14831 for linux-xfs-outgoing; Tue, 26 Mar 2002 16:57:23 -0800 Received: from apollo.digitalpictures.com.au (mail.digitalpictures.com.au [203.29.89.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2R0vEq14803 for ; Tue, 26 Mar 2002 16:57:14 -0800 Received: by apollo.digitalpictures.com.au with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 11:57:51 +1100 Received: from digitalpictures.com.au (owl.digitalpictures.com.au [172.30.24.41]) by apollo.digitalpictures.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F5AVWN7J; Wed, 27 Mar 2002 11:57:47 +1100 From: "Monton, Nick" To: Eric Sandeen , linux-xfs@oss.sgi.com Message-ID: <3CA0D3C8.6050008@digitalpictures.com.au> Date: Tue, 26 Mar 2002 12:02:16 -0800 User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP28; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 Subject: Re: incorrect file listings References: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk built the file system with the mkfs_xfs that ships with irix 6.5.13. >From irix 6.5.5 "version=2" has been available, however it defaults to "version=1" directory naming unless you manually specify "-n version=2" as of irix 6.5.14 apparently mkfs_xfs defaults now to "version=2" if only i'd update irix first .... anyway, the files are all displaying now, it definately seemed to be a problem relating to the v1/v2 directory naming miss match. kinda surprised it worked... questions are, is linux xfs 1.0.1/1.0.2 compatible with irix xfs version2 ? I'd be interested in the levels of success anybody has had when mounting a linux xfs partition on an sgi machine running irix 6.5.5+ ? thanks for your help Eric ... cheers, -nick Eric Sandeen wrote: On Tue, 26 Mar 2002, James Pearson wrote: I've seen this problem with IRIX servers and Linux clients, but not the other way round ... which known IRIX bug is this? I had read things wrong, you're right that the known issue is w/ IRIX servers. It turns out that Nick's problem was that he had made the filesystem on IRIX, with version 1 directories and unwritten extents, neither of which is supported on Linux - this is probably what caused his problems. -Eric [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Mar 26 17:36:51 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R1apu15625 for linux-xfs-outgoing; Tue, 26 Mar 2002 17:36: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 g2R1ajq15596 for ; Tue, 26 Mar 2002 17:36:45 -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 g2R2ldkw026330 for ; Tue, 26 Mar 2002 20:47:39 -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 TAA56753; Tue, 26 Mar 2002 19:37:48 -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 TAA50789; Tue, 26 Mar 2002 19:37:48 -0600 (CST) Date: Tue, 26 Mar 2002 19:37:48 -0600 (CST) From: Eric Sandeen X-X-Sender: To: "Monton, Nick" cc: Subject: Re: incorrect file listings In-Reply-To: <3CA0D3C8.6050008@digitalpictures.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFS filesystems created under Linux will be compatible with Irix, just not always the other way around. XFS for Linux supports a subset of the features and formats of XFS on Irix. Specifically, version 2 directories, unwritten extents, and filesystem block size come to mind. (linux does not support unwritten extents, version 1 dirs, or fs block size != page size) -Eric On Tue, 26 Mar 2002, Monton, Nick wrote: > built the file system with the mkfs_xfs that ships with irix 6.5.13. > >From irix 6.5.5 "version=2" has been available, however it defaults to > "version=1" directory > naming unless you manually specify "-n version=2" > as of irix 6.5.14 apparently mkfs_xfs defaults now to "version=2" > if only i'd update irix first .... > questions are, is linux xfs 1.0.1/1.0.2 compatible with irix xfs > version2 ? > I'd be interested in the levels of success anybody has had when mounting > a linux xfs > partition on an sgi machine running irix 6.5.5+ ? From owner-linux-xfs@oss.sgi.com Tue Mar 26 17:42:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R1gjU15983 for linux-xfs-outgoing; Tue, 26 Mar 2002 17:42:45 -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 g2R1gfq15957 for ; Tue, 26 Mar 2002 17:42:41 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2R2rYkw026342 for ; Tue, 26 Mar 2002 20:53:34 -0600 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 RAA66788 for ; Tue, 26 Mar 2002 17:44:28 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id AAE3D13655D for ; Tue, 26 Mar 2002 17:44:27 -0800 (PST) Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Florin Andrei To: linux-xfs@oss.sgi.com In-Reply-To: <1016738115.30196.4.camel@stout.americas.sgi.com> References: <1016738115.30196.4.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 26 Mar 2002 17:44:27 -0800 Message-Id: <1017193467.27762.52.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-03-21 at 11:15, Eric Sandeen wrote: > At long last, a prerelease of the upcoming XFS 1.1 release is available > ftp://oss.sgi.com/projects/xfs/download/testing/xfs-1.1 Is this the version that's gonna be used for the next version of the installer? (based on Red Hat 7.3 or 8.0 or whatever) -- Florin Andrei "Sorry judge, we would like to publish the file formats, but the data is not stored in files. It is stored in a database that is an indivisible part of the operating system." - a potential future Microsoft excuse From owner-linux-xfs@oss.sgi.com Tue Mar 26 20:30:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R4U3O24056 for linux-xfs-outgoing; Tue, 26 Mar 2002 20:30: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 g2R4Twq24028 for ; Tue, 26 Mar 2002 20:29: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 g2R5WHBA007154 for ; Tue, 26 Mar 2002 21:32:17 -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 WAA60138; Tue, 26 Mar 2002 22:31:01 -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 WAA17865; Tue, 26 Mar 2002 22:31:01 -0600 (CST) Date: Tue, 26 Mar 2002 22:31:01 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Florin Andrei cc: Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing In-Reply-To: <1017193467.27762.52.camel@stantz.corp.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 26 Mar 2002, Florin Andrei wrote: > On Thu, 2002-03-21 at 11:15, Eric Sandeen wrote: > > At long last, a prerelease of the upcoming XFS 1.1 release is available > > ftp://oss.sgi.com/projects/xfs/download/testing/xfs-1.1 > > Is this the version that's gonna be used for the next version of the > installer? (based on Red Hat 7.3 or 8.0 or whatever) The next version of Red Hat seems to be based on a 2.4.18 kernel + the usual assortment of patches. As far as I know, nobody at SGI has yet produced RPMs with XFS bits based on that Red Hat kernel, and it's not really on the radar at this point. Some of the xfs installer code is in the latest Red Hat installer, which makes some of the work easier, but putting out a new installer is still quite time consuming. If anyone would like to contribute such a beast (kernel and/or installer), I'd be glad to put it up on oss. :) -Eric From owner-linux-xfs@oss.sgi.com Tue Mar 26 21:07:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R57kU24787 for linux-xfs-outgoing; Tue, 26 Mar 2002 21:07:46 -0800 Received: from mail.blazebox.homeip.net (postfix@pool-141-155-137-69.ny5030.east.verizon.net [141.155.137.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2R57dq24759 for ; Tue, 26 Mar 2002 21:07:39 -0800 Received: from mail.blaze.homeip.net (blaze.homeip.net [192.168.0.2]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 3103D22998; Wed, 27 Mar 2002 00:08:25 -0500 (EST) Received: (from paul@localhost) by mail.blaze.homeip.net (8.11.6/8.11.4) id g2R59hx00779; Wed, 27 Mar 2002 00:09:43 -0500 X-Authentication-Warning: blaze.homeip.net: paul set sender to paulb@blazebox.homeip.net using -f Subject: Re: superblocks and lilo From: Paul Blazejowski To: Derek James Witt Cc: linux-xfs@oss.sgi.com In-Reply-To: <1017149073.5820.26.camel@saiya-jin.flinthills.com> References: <1017092300.2173.13.camel@saiya-jin.flinthills.com> <1017093184.1748.32.camel@stout.americas.sgi.com> <1017096745.2172.18.camel@saiya-jin.flinthills.com> <1017114614.1754.6.camel@saiya-jin.flinthills.com> <20020326155649.C45001@wobbly.melbourne.sgi.com> <1017149073.5820.26.camel@saiya-jin.flinthills.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Bui5UTdV3BcPJ+gTmFLo" X-Mailer: Evolution/1.0.2 Date: 27 Mar 2002 00:09:43 -0500 Message-Id: <1017205783.712.9.camel@blaze> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-Bui5UTdV3BcPJ+gTmFLo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-03-26 at 08:24, Derek James Witt wrote: > Nathan, yeah. I agree. I have submitted a lilo patch to do just that > (not allowing itself to install onto a XFS partition). But, it seems > there are going to be folks not subscribed to the list that may > unknowingly install lilo in that manner.=20=20 Maybe this patch could be added into the FAQ on oss.sgi.com/projects/xfs site? or perhaps it would be better to submit the patch to author of LILO? Just a suggestion here... Paul --=-Bui5UTdV3BcPJ+gTmFLo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjyhVBYACgkQOkMJCMfleaIJLgCeKRQcSoR3pcNcFWT7wR0EITnQ UTYAoMgyK5wsy8ii8QmiwAyeTJfsQ7XA =GEJd -----END PGP SIGNATURE----- --=-Bui5UTdV3BcPJ+gTmFLo-- From owner-linux-xfs@oss.sgi.com Tue Mar 26 23:39:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R7dwG29679 for linux-xfs-outgoing; Tue, 26 Mar 2002 23:39:58 -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 g2R7doq29652 for ; Tue, 26 Mar 2002 23:39:50 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx11)) with ESMTP id EDE60C46E; Wed, 27 Mar 2002 08:42:06 +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 IAA26752; Wed, 27 Mar 2002 08:42:05 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 8234257306; Wed, 27 Mar 2002 08:41:22 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id EE1F225835; Wed, 27 Mar 2002 08:41:21 +0100 (CET) Message-ID: <3CA177A1.DA2AD64F@ch.sauter-bc.com> Date: Wed, 27 Mar 2002 08:41:21 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Florin Andrei Cc: Juri Haberland , linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <1017176697.16815.21.camel@stantz.corp.sgi.com> <3CA0E904.1080907@koschikode.com> <1017179446.17163.29.camel@stantz.corp.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Florin Andrei schrieb: > > On Tue, 2002-03-26 at 13:32, Juri Haberland wrote: > > Florin Andrei wrote: > > > > > It's been a long time since i started to always do "sync; reboot" > > > instead of just "reboot". I've always felt this is safer. > > > But you're right, the OS should do that for me, at the right time. > > > Therefore, i've submitted a bug report to bugzilla.redhat.com: > > > > > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62025 > > > > Ahm, Florin, I think that the conclusion of this thread was that even > > multiple syncs don't help - instead you could just use 'sleep 30'. > > Yes, that's true for this particular bug. > > But the patch that i included in the bug report does sync AND sleep. > That should cover this bug, and also some other unforeseen bugs. > Since "sync is cheap" when in runlevel 6, i guess it's a good idea to do > it anyway. There are so many things that could go wrong during shutdown. > > > 'sleep 30'... > > This should be tunable in /etc/sysconfig/whatever. One is not supposed > to edit the init scripts to do parameter tuning. > > -- > Florin Andrei > > "Sorry judge, we would like to publish the file formats, but the data is > not stored in files. It is stored in a database that is an indivisible > part of the operating system." - a potential future Microsoft excuse Hi Florin, When I discovered the bug, I first tried it with sync in the halt script. Unfortunately it doesn't help. The only thing that helped was to sleep long enough and magically everything was written where it should. I don't understand interna of the kernel but it sems that sync does not ensure data to be written to disk. Using a script with fuser to determine open files does not help too because there were no open files. They have been closed immediately before shutdown but did not get written to disk, only metadata was written, not data. The culprit was the remount readonly feature of XFS enabled kernels which was buggy. It does not apply to ext2/3 filesystems. The bug is fixed in current CVS as well as in the upcoming 2.4.9-31 based XFS 1.1 release. -Simon From owner-linux-xfs@oss.sgi.com Tue Mar 26 23:48:54 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R7msE30037 for linux-xfs-outgoing; Tue, 26 Mar 2002 23:48:54 -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 g2R7mnq30010 for ; Tue, 26 Mar 2002 23:48:49 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx09)) with ESMTP id 759026271; Wed, 27 Mar 2002 08:51: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 IAA27772; Wed, 27 Mar 2002 08:51:06 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 197C957306; Wed, 27 Mar 2002 08:51:03 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 10FA725835; Wed, 27 Mar 2002 08:51:03 +0100 (CET) Message-ID: <3CA179E7.7413F25@ch.sauter-bc.com> Date: Wed, 27 Mar 2002 08:51:03 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Eric Sandeen Cc: Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen schrieb: > > On 26 Mar 2002, Florin Andrei wrote: > > > On Thu, 2002-03-21 at 11:15, Eric Sandeen wrote: > > > At long last, a prerelease of the upcoming XFS 1.1 release is available > > > ftp://oss.sgi.com/projects/xfs/download/testing/xfs-1.1 > > > > Is this the version that's gonna be used for the next version of the > > installer? (based on Red Hat 7.3 or 8.0 or whatever) > > The next version of Red Hat seems to be based on a 2.4.18 kernel + the > usual assortment of patches. As far as I know, nobody at SGI has yet > produced RPMs with XFS bits based on that Red Hat kernel, and it's not > really on the radar at this point. Some of the xfs installer code is in > the latest Red Hat installer, which makes some of the work easier, but > putting out a new installer is still quite time consuming. > > If anyone would like to contribute such a beast (kernel and/or installer), > I'd be glad to put it up on oss. :) > > -Eric How can we convince RedHat to XFS enable their distribution? There must be a way, suggestions. -Simon From owner-linux-xfs@oss.sgi.com Tue Mar 26 23:52:17 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R7qHT30227 for linux-xfs-outgoing; Tue, 26 Mar 2002 23:52:17 -0800 Received: from ente.berdmann.de (frnk-d514e1e7.dsl.mediaWays.net [213.20.225.231]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2R7qFq30201 for ; Tue, 26 Mar 2002 23:52:15 -0800 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16q8GO-0008RH-00; Wed, 27 Mar 2002 08:54:32 +0100 Message-ID: <3CA17AB8.28E38B0D@berdmann.de> Date: Wed, 27 Mar 2002 08:54:32 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13SGI_XFS_1.0.2 i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Simon Matter CC: Eric Sandeen , Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing References: <3CA179E7.7413F25@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > How can we convince RedHat to XFS enable their distribution? > There must be a way, suggestions. Buy RedHat From owner-linux-xfs@oss.sgi.com Wed Mar 27 00:13:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R8DR430788 for linux-xfs-outgoing; Wed, 27 Mar 2002 00:13:27 -0800 Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2R8D8q30759 for ; Wed, 27 Mar 2002 00:13:09 -0800 Received: from erbenson.alaska.net (113-pm18.nwc.alaska.net [209.112.142.113]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g2R8FIw12817 for ; Tue, 26 Mar 2002 23:15:21 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 015D739D5 for ; Tue, 26 Mar 2002 23:15:06 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 865B11027C; Tue, 26 Mar 2002 23:15:06 -0900 (AKST) Date: Tue, 26 Mar 2002 23:15:06 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: superblocks and lilo Message-ID: <20020326231506.O26309@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1017092300.2173.13.camel@saiya-jin.flinthills.com> <1017093184.1748.32.camel@stout.americas.sgi.com> <1017096745.2172.18.camel@saiya-jin.flinthills.com> <1017114614.1754.6.camel@saiya-jin.flinthills.com> <20020326155649.C45001@wobbly.melbourne.sgi.com> <1017149073.5820.26.camel@saiya-jin.flinthills.com> <1017205783.712.9.camel@blaze> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zn4k3Q+N5puqXur4" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1017205783.712.9.camel@blaze>; from paulb@blazebox.homeip.net on Wed, Mar 27, 2002 at 12:09:43AM -0500 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --zn4k3Q+N5puqXur4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 27, 2002 at 12:09:43AM -0500, Paul Blazejowski wrote: > On Tue, 2002-03-26 at 08:24, Derek James Witt wrote: >=20 > > Nathan, yeah. I agree. I have submitted a lilo patch to do just that > > (not allowing itself to install onto a XFS partition). But, it seems > > there are going to be folks not subscribed to the list that may > > unknowingly install lilo in that manner.=20=20 >=20 > Maybe this patch could be added into the FAQ on oss.sgi.com/projects/xfs if people bothered to read the FAQ they would know better then to scribble thier superblocks with lilo. > site? or perhaps it would be better to submit the patch to author of > LILO? Just a suggestion here... the only way the lilo patch is effective is for it to be merged with mainline lilo, if you know about the patch and what its for you will presumably have enough clue to not screw up your lilo config. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --zn4k3Q+N5puqXur4 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 iEYEARECAAYFAjyhf4oACgkQJKx7GixEevxufwCghP/LpbivsEinYUcQsS+Odjhr UIoAoIGC1bgq2V2Mr9Lt7ymCE5CxJAQY =iXRg -----END PGP SIGNATURE----- --zn4k3Q+N5puqXur4-- From owner-linux-xfs@oss.sgi.com Wed Mar 27 00:16:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R8G8D30993 for linux-xfs-outgoing; Wed, 27 Mar 2002 00:16:08 -0800 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2R8Fwq30966 for ; Wed, 27 Mar 2002 00:15:59 -0800 Received: from kauri.csee.uq.edu.au (kauri.csee.uq.edu.au [130.102.66.24]) by gum.csee.uq.edu.au (8.11.6/8.11.6) with ESMTP id g2R8IKb26765 for ; Wed, 27 Mar 2002 18:18:20 +1000 (EST) Received: from SPIKE (spike.csee.uq.edu.au [130.102.66.71]) by kauri.csee.uq.edu.au (8.11.6/8.11.6) with SMTP id g2R8IAV29046 for ; Wed, 27 Mar 2002 18:18:10 +1000 (EST) Message-ID: <04dd01c1d567$f40e7320$47426682@csee.uq.edu.au> From: "Chris Pascoe" To: Subject: 1.1PR2 LVM warning, sunit/swidth query Date: Wed, 27 Mar 2002 18:18:19 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, On a new machine, I have rebuilt the XFS 1.1 PR2 kernels, adding the LVM patch posted by Eric late last week and enabling LVM support in the build. I have installed the XFS 1.1 PR2 cmd_rpms also. I have a single LVM volume on hardware RAID 5 (9 disks, 64kB chunk size), and am trying the mkfs command: # mkfs.xfs -f -d sw=9,su=64k /dev/vg/lv Firstly, is this the right sw/su combination for this RAID configuration? I've seen this asked before, but can't find any obvious answer in the mailing list archives nor anything in the FAQ - sorry for repeating it. Secondly, upon running the mkfs I see the warning message shown below before the filesystem is created: mkfs.xfs: warning - cannot set blocksize on block device /dev/vg/lv: Invalid argument meta-data=/dev/vg/lv isize=256 agcount=125, agsize=1048576 blks data = bsize=4096 blocks=131072000, imaxpct=25 = sunit=16 swidth=144 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=16000 realtime =none extsz=65536 blocks=0, rtextents=0 Is this anything to worry about? I know it says "warning", but I thought I read somewhere that all the warnings that weren't evil were going to be hidden by default before the 1.1 release. Has this been overlooked, or is it something to worry about? Thirdly this machine will be used primarily as a NFS server; is there any advantage in increasing the log sizes here? Thanks in advance, Chris From owner-linux-xfs@oss.sgi.com Wed Mar 27 00:24:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R8Oc931252 for linux-xfs-outgoing; Wed, 27 Mar 2002 00:24:38 -0800 Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2R8OXq31216 for ; Wed, 27 Mar 2002 00:24:33 -0800 Received: from kauri.csee.uq.edu.au (kauri.csee.uq.edu.au [130.102.66.24]) by gum.csee.uq.edu.au (8.11.6/8.11.6) with ESMTP id g2R8Qsb27175; Wed, 27 Mar 2002 18:26:54 +1000 (EST) Received: from SPIKE (spike.csee.uq.edu.au [130.102.66.71]) by kauri.csee.uq.edu.au (8.11.6/8.11.6) with SMTP id g2R8QiV29167; Wed, 27 Mar 2002 18:26:44 +1000 (EST) Message-ID: <056301c1d569$26ee0520$47426682@csee.uq.edu.au> From: "Chris Pascoe" To: "Eric Sandeen" Cc: "linux-xfs" References: <3C961055.FF5DF9C6@ch.sauter-bc.com> <1017176697.16815.21.camel@stantz.corp.sgi.com> <3CA0E904.1080907@koschikode.com> <1017179446.17163.29.camel@stantz.corp.sgi.com> <3CA177A1.DA2AD64F@ch.sauter-bc.com> Subject: Re: files in /etc/xinetd.d become 0 byte size Date: Wed, 27 Mar 2002 18:26:54 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter writes: > The culprit was the remount readonly feature of XFS enabled kernels > which was buggy. It does not apply to ext2/3 filesystems. > > The bug is fixed in current CVS as well as in the upcoming 2.4.9-31 > based XFS 1.1 release. Hi Eric, I was wondering if this the same thing that was causing inconsistent snapshots (remember the directories that wouldn't show in ls - back after the change to speedup xfs_freeze), and thus if it is now solved? Thanks, Chris From owner-linux-xfs@oss.sgi.com Wed Mar 27 00:42:21 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2R8gL731549 for linux-xfs-outgoing; Wed, 27 Mar 2002 00:42:21 -0800 Received: from chkbak.localdomain ([213.53.199.26]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2R8gDq31520 for ; Wed, 27 Mar 2002 00:42:13 -0800 Received: (qmail 5892 invoked from network); 27 Mar 2002 08:45:57 -0000 Received: from unknown (HELO aplabwp0368359) (192.168.0.59) by 192.168.0.254 with SMTP; 27 Mar 2002 08:45:57 -0000 Message-ID: <004a01c1d56b$cae7cb50$3b00a8c0@aplabwp0368359> From: "Bas" To: Subject: Can't build CVS kernels of 20020321 & 20020327 Date: Wed, 27 Mar 2002 09:45:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, It's not possible for me to build the kernel mentioned above. I saw the new qouta options and suspect it has something to do with it, but I'm not sure. Building everything goes fine, but at the end of the run it's not able to produce a kernel because of DQUOT_SYNC. I don't have the exact error here. My config: - gcc 2.95.3; - libc 2.2.5; - linux 2.4.18 w/xfs support; - evms 0.9.2 base patch; - evms CVS patch 20020326; - devfs 199-9; - devfs raw patch. I noticed the new options and tried both old quota interface and the new quota interface and I've got the new quota tools, but it will not build at all. Thanks, Bas. From owner-linux-xfs@oss.sgi.com Wed Mar 27 02:04:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RA4Io01420 for linux-xfs-outgoing; Wed, 27 Mar 2002 02:04:18 -0800 Received: from porsta.cs.Helsinki.FI (root@porsta.cs.Helsinki.FI [128.214.48.124]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RA4Cq01394 for ; Wed, 27 Mar 2002 02:04:13 -0800 Received: from melkki.cs.Helsinki.FI (sslwrap@localhost [127.0.0.1]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g2RA6Tr29985 for ; Wed, 27 Mar 2002 12:06:33 +0200 Received: (from hhaataja@localhost) by melkki.cs.Helsinki.FI (8.11.6/8.11.2) id g2RA6Nd09893 for linux-xfs@oss.sgi.com; Wed, 27 Mar 2002 12:06:23 +0200 Date: Wed, 27 Mar 2002 12:06:23 +0200 From: Harri Haataja Cc: linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Message-ID: <20020327120623.B5357@cs.helsinki.fi> References: <3CA179E7.7413F25@ch.sauter-bc.com> <3CA17AB8.28E38B0D@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CA17AB8.28E38B0D@berdmann.de>; from be@berdmann.de on Wed, Mar 27, 2002 at 08:54:32AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 27, 2002 at 08:54:32AM +0100, Bernhard R. Erdmann wrote: > > How can we convince RedHat to XFS enable their distribution? > > There must be a way, suggestions. > > Buy RedHat Indeed. They have their mind pretty much set on backwards-compatible ext3. You might get it to a similiar spot like reiserfs - just put in. But I don't know if they'll allow putting it to root without doing it by hand. From owner-linux-xfs@oss.sgi.com Wed Mar 27 02:40:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RAe3M01987 for linux-xfs-outgoing; Wed, 27 Mar 2002 02:40:03 -0800 Received: from mail.securities.co.in ([203.197.18.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RAdoq01956 for ; Wed, 27 Mar 2002 02:39:51 -0800 Received: from volstan (volstan.securities.co.in [192.168.1.10]) by mail.securities.co.in (8.11.6/8.11.6) with SMTP id g2RAfkS17213 for ; Wed, 27 Mar 2002 16:11:46 +0530 Message-ID: <00f201c1d57c$77304e40$0a01a8c0@securities.co.in> From: "Volstan Stephen" To: Subject: problem running xfs_repair Date: Wed, 27 Mar 2002 16:15:02 +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 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all, I have loaded XFS filesytem on the / partition. When I boot the linux box everything works fine for some time and then I see some messages like this on the console screen. Mar 27 06:05:34 leopard kernel: Unable to handle kernel NULL pointer dereference at virtual addres s 00000004 Mar 27 06:05:34 leopard kernel: printing eip: Mar 27 06:05:34 leopard kernel: c0133ab0 Mar 27 06:05:34 leopard kernel: *pde = 00000000 Mar 27 06:05:34 leopard kernel: Oops: 0002 Mar 27 06:05:34 leopard kernel: CPU: 0 Mar 27 06:05:34 leopard kernel: EIP: 0010:[get_empty_filp+32/296] Not tainted Mar 27 06:05:34 leopard kernel: EIP: 0010:[] Not tainted Mar 27 06:05:34 leopard kernel: EFLAGS: 00010212 Mar 27 06:05:34 leopard kernel: eax: 00000000 ebx: 00000000 ecx: c426e000 edx: c0365854 Mar 27 06:05:34 leopard kernel: esi: c4790800 edi: ffffffe9 ebp: c13792a0 esp: c426ff4c Mar 27 06:05:34 leopard kernel: ds: 0018 es: 0018 ss: 0018 Mar 27 06:05:34 leopard kernel: Process touch (pid: 1045, stackpage=c426f000) Mar 27 06:05:34 leopard kernel: Stack: 00000000 00000000 ffffffe9 c5ee4000 c013296e 00000000 00000 003 0000002c Mar 27 06:05:34 leopard kernel: c5ee4000 c013294f c5d73f60 c13792a0 00000000 c426e000 c5d73 f60 c13792a0 Mar 27 06:05:34 leopard kernel: 0000002c c5ee4000 00000003 00000001 00000001 c0132c3c c5ee4 000 00000000 Mar 27 06:05:34 leopard kernel: Call Trace: [dentry_open+22/328] dentry_open [kernel] 0x16 Mar 27 06:05:34 leopard kernel: Call Trace: [] dentry_open [kernel] 0x16 Mar 27 06:05:34 leopard kernel: [filp_open+71/80] filp_open [kernel] 0x47 Mar 27 06:05:34 leopard kernel: [] filp_open [kernel] 0x47 Mar 27 06:05:34 leopard kernel: [sys_open+56/180] sys_open [kernel] 0x38 Mar 27 06:05:34 leopard kernel: [] sys_open [kernel] 0x38 Mar 27 06:05:34 leopard kernel: [system_call+51/64] system_call [kernel] 0x33 Mar 27 06:05:34 leopard kernel: [] system_call [kernel] 0x33 Mar 27 06:05:34 leopard kernel: Mar 27 06:05:34 leopard kernel: Mar 27 06:05:34 leopard kernel: Code: 89 50 04 89 02 c7 46 04 00 00 00 00 c7 06 00 00 00 00 ba 00 and also the corrup inode message at this address. Mar 25 03:16:04 leopard kernel: cmn_err level 4 Filesystem "ide0(3,2)": corrupt inode 12919647 (ba d size 2305843009213693958 for local inode). Unmount and run xfs_repair. Mar 25 03:50:01 leopard kernel: Unable to handle kernel paging request at virtual address 6c616375 I booted the system using a bootable disk and ran xfs_repair on this partition and eachtime it come out with segmentation fault. The linux version is RH7.2 with 2.4.9-13SGI_XFS_1.0.2 . Any thoughts on how I can get this going. Thanks and regards, Volstan. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Mar 27 05:10:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RDAe004423 for linux-xfs-outgoing; Wed, 27 Mar 2002 05:10:40 -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 g2RDAaq04395 for ; Wed, 27 Mar 2002 05:10:36 -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 g2RDCs6G021374 for ; Wed, 27 Mar 2002 05:12:54 -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 HAA64271 for ; Wed, 27 Mar 2002 07:12: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 HAA61628 for ; Wed, 27 Mar 2002 07:12:54 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2RD9To26016; Wed, 27 Mar 2002 07:09:29 -0600 Message-Id: <200203271309.g2RD9To26016@jen.americas.sgi.com> Date: Wed, 27 Mar 2002 07:09:29 -0600 Subject: TAKE - fixup inode shrink code To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Remove an assert and fix module build of kdb Date: Wed Mar 27 05:11:14 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:114994a linux/fs/xfs/xfs_vnodeops.c - 1.521 - remove bogus asserts linux/fs/xfs/xfs_inode.c - 1.330 - move xfs_ipincount into header file as a #define linux/fs/xfs/xfs_inode.h - 1.158 - redfine xfs_ipincount as a #define From owner-linux-xfs@oss.sgi.com Wed Mar 27 05:30:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RDUV304883 for linux-xfs-outgoing; Wed, 27 Mar 2002 05:30:31 -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 g2RDURq04857 for ; Wed, 27 Mar 2002 05:30:27 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2REWkBA022131 for ; Wed, 27 Mar 2002 06:32:46 -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 FAA54264; Wed, 27 Mar 2002 05:32:14 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 40E7113650D; Wed, 27 Mar 2002 05:32:14 -0800 (PST) Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Florin Andrei To: Simon Matter Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <3CA179E7.7413F25@ch.sauter-bc.com> References: <3CA179E7.7413F25@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 27 Mar 2002 05:32:14 -0800 Message-Id: <1017235934.29730.6.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-03-26 at 23:51, Simon Matter wrote: > > How can we convince RedHat to XFS enable their distribution? > There must be a way, suggestions. Naah. The right question is: "how can we convince Linus to include XFS in the mainstream kernel?" And the answer is quite simple: you guys are all using XFS, right? I guess most of you know that it works just perfect on busy servers, under high system load. Well, go to lkml (Linux Kernel Mailing List), send a nice message explaining how stable is XFS in production, and asking for inclusion. If a reasonable amount of people will do that on the list, it's bound to get included. It's not just Red Hat, it's Linux. ;-) -- Florin Andrei "Sorry judge, we would like to publish the file formats, but the data is not stored in files. It is stored in a database that is an indivisible part of the operating system." - a potential future Microsoft excuse From owner-linux-xfs@oss.sgi.com Wed Mar 27 05:38:28 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RDcSo05145 for linux-xfs-outgoing; Wed, 27 Mar 2002 05:38:28 -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 g2RDcPq05119 for ; Wed, 27 Mar 2002 05:38:25 -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 g2REeiBA022379 for ; Wed, 27 Mar 2002 06:40:44 -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 HAA58884; Wed, 27 Mar 2002 07:40:43 -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 HAA26628; Wed, 27 Mar 2002 07:40:43 -0600 (CST) Date: Wed, 27 Mar 2002 07:40:43 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Chris Pascoe cc: Subject: Re: 1.1PR2 LVM warning, sunit/swidth query In-Reply-To: <04dd01c1d567$f40e7320$47426682@csee.uq.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Chris - I don't know the answer to your RAID question, but the warning below is indeed harmless, at this point. It might be worth asking the LVM guys to impliment the BLKBSZSET and BLKLGSZGET ioctls, though - I don't know if there's a reason that this hasn't been done. -Eric On Wed, 27 Mar 2002, Chris Pascoe wrote: > Secondly, upon running the mkfs I see the warning message shown below before > the filesystem is created: > > mkfs.xfs: warning - cannot set blocksize on block device /dev/vg/lv: Invalid > argument From owner-linux-xfs@oss.sgi.com Wed Mar 27 05:39:56 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RDdut05285 for linux-xfs-outgoing; Wed, 27 Mar 2002 05:39:56 -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 g2RDdqq05259 for ; Wed, 27 Mar 2002 05:39: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 g2REgBBA022451 for ; Wed, 27 Mar 2002 06:42:11 -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 HAA66719; Wed, 27 Mar 2002 07:42:10 -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 HAA96617; Wed, 27 Mar 2002 07:42:10 -0600 (CST) Date: Wed, 27 Mar 2002 07:42:10 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Chris Pascoe cc: linux-xfs Subject: Re: files in /etc/xinetd.d become 0 byte size In-Reply-To: <056301c1d569$26ee0520$47426682@csee.uq.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 27 Mar 2002, Chris Pascoe wrote: > I was wondering if this the same thing that was causing inconsistent > snapshots (remember the directories that wouldn't show in ls - back after > the change to speedup xfs_freeze), and thus if it is now solved? Hi Chris - Not sure, to tell you the truth. I have not yet gotten back to xfs_freeze, although I think I did a little testing a while ago and did not see the problem. Can you verify that the problem still exists? Thanks, -Eric From owner-linux-xfs@oss.sgi.com Wed Mar 27 06:08:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RE8a905768 for linux-xfs-outgoing; Wed, 27 Mar 2002 06:08: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 g2RE8Vq05742 for ; Wed, 27 Mar 2002 06:08:32 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2RFAoBA023431 for ; Wed, 27 Mar 2002 07:10:50 -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 GAA89030 for ; Wed, 27 Mar 2002 06:10:19 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 607A713650D for ; Wed, 27 Mar 2002 06:10:19 -0800 (PST) Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Florin Andrei To: linux-xfs@oss.sgi.com In-Reply-To: <1017235934.29730.6.camel@stantz.corp.sgi.com> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 27 Mar 2002 06:10:19 -0800 Message-Id: <1017238219.30422.14.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 05:32, Florin Andrei wrote: > > Naah. The right question is: "how can we convince Linus to include XFS > in the mainstream kernel?" Obviously, XFS is missing someone as good as Hans Reiser at doing advertising. ;-) If you divide ${popularity} / ${technical merits}, XFS gets an abnormally low result. -- Florin Andrei "Sorry judge, we would like to publish the file formats, but the data is not stored in files. It is stored in a database that is an indivisible part of the operating system." - a potential future Microsoft excuse From owner-linux-xfs@oss.sgi.com Wed Mar 27 06:10:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2REAZK05929 for linux-xfs-outgoing; Wed, 27 Mar 2002 06:10:35 -0800 Received: from s1.uklinux.net (mail.uklinux.net [80.84.72.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2REASq05903 for ; Wed, 27 Mar 2002 06:10:29 -0800 Received: from pyewacket.nic.uklinux.net (host213-122-28-74.in-addr.btopenworld.com [213.122.28.74]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g2RECVi26275; Wed, 27 Mar 2002 14:12:31 GMT Envelope-To: linux-xfs@oss.sgi.com Received: from nic by pyewacket.nic.uklinux.net with local (Exim 3.34 #1) id 16qE9B-0001le-00; Wed, 27 Mar 2002 14:11:29 +0000 Subject: XFS pressure group From: Nic Doye To: Florin Andrei Cc: linux-xfs@oss.sgi.com In-Reply-To: <1017235934.29730.6.camel@stantz.corp.sgi.com> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 (1.0.1-2) Date: 27 Mar 2002 14:11:29 +0000 Message-Id: <1017238289.6621.5.camel@pyewacket> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 13:32, Florin Andrei wrote: > Naah. The right question is: "how can we convince Linus to include XFS > in the mainstream kernel?" > > And the answer is quite simple: you guys are all using XFS, right? I > guess most of you know that it works just perfect on busy servers, under > high system load. > Well, go to lkml (Linux Kernel Mailing List), send a nice message > explaining how stable is XFS in production, and asking for inclusion. > If a reasonable amount of people will do that on the list, it's bound to > get included. I don't think it's been done before and possibly not a good precendent to set, but perhaps SGI could set up a form (or volunteer someone to collect e-mail messages, or use an on-line petition service) to get a letter to Linus saying "We the undersigned all think XFS rocks and is way stable enough to get included in the 2.5 tree today and in the 2.4 tree some months ago". Or if it would look like undue commercial pressure if SGI did it, I could whack up a form to do it... Opinions, comments, flames anyone? nic From owner-linux-xfs@oss.sgi.com Wed Mar 27 06:19:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2REJrC06158 for linux-xfs-outgoing; Wed, 27 Mar 2002 06:19:53 -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 g2REJnq06132 for ; Wed, 27 Mar 2002 06:19:49 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 450FF1E9F7; Wed, 27 Mar 2002 15:22:07 +0100 (MET) Date: Wed, 27 Mar 2002 15:22:06 +0100 From: Andi Kleen To: Nic Doye Cc: Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: XFS pressure group Message-ID: <20020327152206.A5364@wotan.suse.de> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017238289.6621.5.camel@pyewacket> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1017238289.6621.5.camel@pyewacket> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 27, 2002 at 02:11:29PM +0000, Nic Doye wrote: > I don't think it's been done before and possibly not a good precendent I has been done before (for LVM for example). I think it is a waste of your time. What's needed is someone to submit XFS to Linus and other VFS codekeepers and spend the time to fix any reasonable complaints they have about the code (and explain to them why the unreasonable ones cannot be changed). That can be a time consuming task. This will eventually happen I guess, but it's a purely technical thing, not a "political" one. Cleaning up XFS before as far as possible will be helpful, there are certainly some ugly parts in the code right now. I guess the main work in that will not be in merging XFS itself, but the pagebuf layer. What also helps is lots of people using and testing XFS so that that I can be said with reasonable certainity that it is stable. -Andi From owner-linux-xfs@oss.sgi.com Wed Mar 27 06:42:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2REgA606598 for linux-xfs-outgoing; Wed, 27 Mar 2002 06:42:10 -0800 Received: from relay.dera.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2REg5q06569 for ; Wed, 27 Mar 2002 06:42:05 -0800 Received: (qmail 17860 invoked from network); 27 Mar 2002 14:44:27 +0000 Received: from syntax.dera.gov.uk (HELO syntax.dstl.gov.uk) (146.80.9.50) by relay.dera.gov.uk with SMTP; 27 Mar 2002 14:44:27 +0000 Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Tony Gale To: Florin Andrei Cc: Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1017235934.29730.6.camel@stantz.corp.sgi.com> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 27 Mar 2002 14:44:26 +0000 Message-Id: <1017240266.16216.8.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 13:32, Florin Andrei wrote: > > And the answer is quite simple: you guys are all using XFS, right? I > guess most of you know that it works just perfect on busy servers, under > high system load. > Well, go to lkml (Linux Kernel Mailing List), send a nice message > explaining how stable is XFS in production, and asking for inclusion. > If a reasonable amount of people will do that on the list, it's bound to > get included. > > It's not just Red Hat, it's Linux. ;-) Another thing to do is get XFS moved from 'Beta' to 'Ready' status on: http://kernelnewbies.org/status/ I guess all that would take is an email from someone at SGI. <- Hint Thanks -tony From owner-linux-xfs@oss.sgi.com Wed Mar 27 06:54:00 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2REs0M06899 for linux-xfs-outgoing; Wed, 27 Mar 2002 06:54:00 -0800 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RErtq06873 for ; Wed, 27 Mar 2002 06:53:55 -0800 Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g2REu3V07756; Wed, 27 Mar 2002 15:56:03 +0100 Date: Wed, 27 Mar 2002 15:56:03 +0100 From: Christoph Hellwig To: Tony Gale Cc: Florin Andrei , Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Message-ID: <20020327155602.A7730@caldera.de> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1017240266.16216.8.camel@syntax.dstl.gov.uk>; from gale@syntax.dstl.gov.uk on Wed, Mar 27, 2002 at 02:44:26PM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 27, 2002 at 02:44:26PM +0000, Tony Gale wrote: > Another thing to do is get XFS moved from 'Beta' to 'Ready' status on: > > http://kernelnewbies.org/status/ > > I guess all that would take is an email from someone at SGI. <- Hint That document is just informal - there are a number of items of which I bet they won't make it into 2.6. From owner-linux-xfs@oss.sgi.com Wed Mar 27 06:58:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2REwde07206 for linux-xfs-outgoing; Wed, 27 Mar 2002 06:58:39 -0800 Received: from relay.dera.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2REwZq07180 for ; Wed, 27 Mar 2002 06:58:35 -0800 Received: (qmail 22588 invoked from network); 27 Mar 2002 15:00:58 +0000 Received: from syntax.dera.gov.uk (HELO syntax.dstl.gov.uk) (146.80.9.50) by relay.dera.gov.uk with SMTP; 27 Mar 2002 15:00:58 +0000 Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Tony Gale To: Christoph Hellwig Cc: Florin Andrei , Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <20020327155602.A7730@caldera.de> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 27 Mar 2002 15:00:57 +0000 Message-Id: <1017241257.14218.15.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 14:56, Christoph Hellwig wrote: > > That document is just informal - there are a number of items > of which I bet they won't make it into 2.6. > I know it's informal. But many people look at it and take note of it's contents. Easy way to increase the userbase. I mean, how the hell did IBM get the jump on SGI with kernel integration? Someone missed a trick there. -tony From owner-linux-xfs@oss.sgi.com Wed Mar 27 07:00:19 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RF0JF07378 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:00:19 -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 g2RF0Eq07352 for ; Wed, 27 Mar 2002 07:00:14 -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 g2RG2XBA025737 for ; Wed, 27 Mar 2002 08:02:33 -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 JAA79244; Wed, 27 Mar 2002 09:02: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 JAA52838; Wed, 27 Mar 2002 09:02:28 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2REx2a28817; Wed, 27 Mar 2002 08:59:02 -0600 Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Steve Lord To: Tony Gale Cc: Christoph Hellwig , Florin Andrei , Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1017241257.14218.15.camel@syntax.dstl.gov.uk> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Mar 2002 08:59:02 -0600 Message-Id: <1017241142.27964.3.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 09:00, Tony Gale wrote: > > On Wed, 2002-03-27 at 14:56, Christoph Hellwig wrote: > > > > That document is just informal - there are a number of items > > of which I bet they won't make it into 2.6. > > > > I know it's informal. But many people look at it and take note of it's > contents. Easy way to increase the userbase. > > I mean, how the hell did IBM get the jump on SGI with kernel > integration? Someone missed a trick there. I think Christoph had a lot to do with it. 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 27 07:03:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RF3h207549 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:03:43 -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 g2RF3bq07523 for ; Wed, 27 Mar 2002 07:03:38 -0800 Received: from ursa.xanoptix.com ([10.20.1.31] helo=xanoptix.com)by ursa.xanoptix.comwith smtp(Exim 3.20 #1 (Debian))id 16qEzl-000544-00; Wed, 27 Mar 2002 10:05:49 -0500 Received: from 10.20.1.46 (SquirrelMail authenticated user kend) by webmail.xanoptix.com with HTTP; Wed, 27 Mar 2002 10:05:49 -0500 (EST) Message-ID: <32832.10.20.1.46.1017241549.squirrel@webmail.xanoptix.com> Date: Wed, 27 Mar 2002 10:05:49 -0500 (EST) Subject: =?iso-8859-1?Q?Re:_XFS_pressure_group?= From: To: In-Reply-To: <1017238289.6621.5.camel@pyewacket> References: <1017238289.6621.5.camel@pyewacket> Cc: , X-Mailer: SquirrelMail (version 1.2.0 [rc1]) 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 Wed, 2002-03-27 at 13:32, Florin Andrei wrote: > I don't think it's been done before and possibly not a good precendent > to set, but perhaps SGI could set up a form (or volunteer someone to > collect e-mail messages, or use an on-line petition service) to get a > letter to Linus saying "We the undersigned all think XFS rocks and is > way stable enough to get included in the 2.5 tree today and in the 2.4 > tree some months ago". > > Or if it would look like undue commercial pressure if SGI did it, I > could whack up a form to do it... > > Opinions, comments, flames anyone? Well, since you asked... ;-) Seriously, though -- first and foremost, I'm an XFS "user", and most certainly am not competent to comment in-depth on kernel issues, but I'd always been somewhat under the impression that ACLs brought up security issues that had yet to be dealt with, and that that was a large portion of the reason for Linus' reluctance to include it. Is this true? If so, how has it been addressed? Or am I merely misguided? $.02, -Ken From owner-linux-xfs@oss.sgi.com Wed Mar 27 07:12:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RFC6Y07854 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:12:06 -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 g2RFC2q07827 for ; Wed, 27 Mar 2002 07:12:02 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2RGMvkw029263 for ; Wed, 27 Mar 2002 10:22:58 -0600 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 HAA61953 for ; Wed, 27 Mar 2002 07:13:49 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 8557513650D for ; Wed, 27 Mar 2002 07:13:49 -0800 (PST) Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Florin Andrei To: linux-xfs@oss.sgi.com In-Reply-To: <1017241257.14218.15.camel@syntax.dstl.gov.uk> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 27 Mar 2002 07:13:49 -0800 Message-Id: <1017242029.30422.26.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 07:00, Tony Gale wrote: > > I mean, how the hell did IBM get the jump on SGI with kernel > integration? Someone missed a trick there. s/a trick/advertising/ It takes someone who knows how to deal with Freshmeat, and lkml, and Slashdot and [insert your favourite here], and do the right things, and send the right information when the time comes, etc. Like i said, this is an art (besides being a full-time job), and some people are very good at it. Another example is msyslog. How many of you have heard of it? And it's a far better syslog replacement than many other (including syslog-ng). But it's like their authors try to hide it or something. After trying to make them submit the releases to Freshmeat, and trying to increase awareness about this product on several popular groups, i just gave up. Hey, i'm just a user, not its author... :-/ -- Florin Andrei "Sorry judge, we would like to publish the file formats, but the data is not stored in files. It is stored in a database that is an indivisible part of the operating system." - a potential future Microsoft excuse From owner-linux-xfs@oss.sgi.com Wed Mar 27 07:15:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RFFmK08061 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:15:48 -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 g2RFFiq08035 for ; Wed, 27 Mar 2002 07:15:44 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2RGQekw029336 for ; Wed, 27 Mar 2002 10:26:40 -0600 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 HAA82830 for ; Wed, 27 Mar 2002 07:17:32 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id CC94B13650D for ; Wed, 27 Mar 2002 07:17:31 -0800 (PST) Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Florin Andrei To: linux-xfs@oss.sgi.com In-Reply-To: <1017242029.30422.26.camel@stantz.corp.sgi.com> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <1017242029.30422.26.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 27 Mar 2002 07:17:31 -0800 Message-Id: <1017242251.30422.29.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 07:13, Florin Andrei wrote: > > It takes someone who knows how to deal with Freshmeat, and lkml, and > Slashdot and [insert your favourite here], and do the right things, and > send the right information when the time comes, etc. > Like i said, this is an art (besides being a full-time job), and some > people are very good at it. Just because you're open source it doesn't mean it's the end of advertising. Just that the ways are different. (sorry for reply-to-myself) -- Florin Andrei "Sorry judge, we would like to publish the file formats, but the data is not stored in files. It is stored in a database that is an indivisible part of the operating system." - a potential future Microsoft excuse From owner-linux-xfs@oss.sgi.com Wed Mar 27 07:17:55 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RFHt008206 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:17:55 -0800 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RFHmq08180 for ; Wed, 27 Mar 2002 07:17:49 -0800 Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g2RFK3U08959; Wed, 27 Mar 2002 16:20:03 +0100 Date: Wed, 27 Mar 2002 16:20:03 +0100 From: Christoph Hellwig To: Tony Gale Cc: Florin Andrei , Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Message-ID: <20020327162003.A8199@caldera.de> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1017241257.14218.15.camel@syntax.dstl.gov.uk>; from gale@syntax.dstl.gov.uk on Wed, Mar 27, 2002 at 03:00:57PM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 27, 2002 at 03:00:57PM +0000, Tony Gale wrote: > I mean, how the hell did IBM get the jump on SGI with kernel > integration? Someone missed a trick there. If you look at JFS compared to XFS you will see two things: a) outside fs/jfs only configuration/documentation is touched, there are _no_ core kernel changes. b) JFS uses the generic kernel filesystem code wherever possible But this does not only have advantages: - in 2.4 JFS requires two memory allocations for each new inode, bot just one like ext2/ext3/xfs/etc - JFS can't support features implemented in the disk format but not in the main kernel. Examples are EAs/ACLs. - sometimes the core kernel really should be changed. An example is the missing export of block_flushpage in pre-2.4.18 kernels (or 2.5) - JFS works around this in a way I absoloutly don't like. I think XFS could try hard to archive the first item, even if it loses some functionaly that needs to be pulled in through extra patches, but given the current SGI policy/development model I don't think b) is / will be a goal. It's up to Al and Linus to decide whether b) is important or not, but I strongly doubt they will take an XFS patch with all the mainline invasion the current version has. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Wed Mar 27 07:20:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RFK1808356 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:20:01 -0800 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RFJvq08328 for ; Wed, 27 Mar 2002 07:19:57 -0800 Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g2RFMDN09121; Wed, 27 Mar 2002 16:22:13 +0100 Date: Wed, 27 Mar 2002 16:22:13 +0100 From: Christoph Hellwig To: Florin Andrei Cc: linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Message-ID: <20020327162213.B8199@caldera.de> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <1017242029.30422.26.camel@stantz.corp.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: <1017242029.30422.26.camel@stantz.corp.sgi.com>; from florin@sgi.com on Wed, Mar 27, 2002 at 07:13:49AM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 27, 2002 at 07:13:49AM -0800, Florin Andrei wrote: > On Wed, 2002-03-27 at 07:00, Tony Gale wrote: > > > > I mean, how the hell did IBM get the jump on SGI with kernel > > integration? Someone missed a trick there. > > s/a trick/advertising/ This is utterly untrue. > It takes someone who knows how to deal with Freshmeat, and lkml, and > Slashdot and [insert your favourite here], and do the right things, and > send the right information when the time comes, etc. Have you ever seen Linus merging something because it appeared on /. ? Christoph -- Whip me. Beat me. Make me maintain AIX. From owner-linux-xfs@oss.sgi.com Wed Mar 27 07:28:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RFSbU08606 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:28:37 -0800 Received: from filecabinet.amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RFSUq08580 for ; Wed, 27 Mar 2002 07:28:30 -0800 Received: (from ctooley@localhost) by filecabinet.amoa.org (8.11.6/8.11.6) id g2RFUb620648; Wed, 27 Mar 2002 15:30:37 GMT X-Authentication-Warning: filecabinet.amoa.org: ctooley set sender to ctooley@amoa.org using -f Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Chris Tooley To: Florin Andrei Cc: linux-xfs@oss.sgi.com In-Reply-To: <1017242251.30422.29.camel@stantz.corp.sgi.com> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sg i.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <1017242029.30422.26.camel@stantz.corp.sgi.com> <1017242251.30422.29.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Mar 2002 15:30:37 +0000 Message-Id: <1017243037.19718.15.camel@filecabinet.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 15:17, Florin Andrei wrote: > On Wed, 2002-03-27 at 07:13, Florin Andrei wrote: > > > > It takes someone who knows how to deal with Freshmeat, and lkml, and > > Slashdot and [insert your favourite here], and do the right things, and > > send the right information when the time comes, etc. > > Like i said, this is an art (besides being a full-time job), and some > > people are very good at it. > > Just because you're open source it doesn't mean it's the end of > advertising. Just that the ways are different. > > (sorry for reply-to-myself) It's also a matter of picking your path into the kernel. Linus says he only trusts a small number of people, 10-15 or something like that. If you want something in the Linus kernel, you typically have to go through one of those people unless Linus trusts you. Or so the theory goes. That is one of the good things about going through a distribution kernel first. There is usually someone there that give it a once over and get it pushed up to Linus for another look over. Since SGI already creates RedHat Installers and RPMs for RedHat, it seems like a convenient target distro. And, Christoph, I thought ACL/EA went into the kernel at 2.5.3 which was before JFS at 2.5.6 ... http://www.geocrawler.com/mail/msg.php3?msg_id=7686796&list=35 http://kernelnewbies.org/status/latest.html Chris Tooley I am not a kernel developer and am just interested in seeing this project go through as I've an XFS user and really like the filesystem. From owner-linux-xfs@oss.sgi.com Wed Mar 27 07:31:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RFV8Z08769 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:31:08 -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 g2RFV0q08743 for ; Wed, 27 Mar 2002 07:31:00 -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 g2RFXJ6G026899 for ; Wed, 27 Mar 2002 07:33:19 -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 JAA65822; Wed, 27 Mar 2002 09:33:18 -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 JAA89597; Wed, 27 Mar 2002 09:33:18 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2RFTqh29993; Wed, 27 Mar 2002 09:29:52 -0600 Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Steve Lord To: Christoph Hellwig Cc: Tony Gale , Florin Andrei , Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <20020327162003.A8199@caldera.de> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <20020327162003.A8199@caldera.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Mar 2002 09:29:52 -0600 Message-Id: <1017242992.27964.13.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 09:20, Christoph Hellwig wrote: > On Wed, Mar 27, 2002 at 03:00:57PM +0000, Tony Gale wrote: > > I mean, how the hell did IBM get the jump on SGI with kernel > > integration? Someone missed a trick there. > > If you look at JFS compared to XFS you will see two things: > > a) outside fs/jfs only configuration/documentation is touched, > there are _no_ core kernel changes. > b) JFS uses the generic kernel filesystem code wherever possible > > But this does not only have advantages: > > - in 2.4 JFS requires two memory allocations for each new inode, > bot just one like ext2/ext3/xfs/etc xfs does two by the way. > - JFS can't support features implemented in the disk format but not in > the main kernel. Examples are EAs/ACLs. > - sometimes the core kernel really should be changed. An example > is the missing export of block_flushpage in pre-2.4.18 kernels > (or 2.5) - JFS works around this in a way I absoloutly don't like. > > I think XFS could try hard to archive the first item, even if it > loses some functionaly that needs to be pulled in through extra patches, > but given the current SGI policy/development model I don't think b) > is / will be a goal. It's up to Al and Linus to decide whether b) is > important or not, but I strongly doubt they will take an XFS patch with > all the mainline invasion the current version has. So, it is OK for people to rip the guts out of the VM every other week and for Al Viro to apply so many patches the filesystem API that your head spins, but a filesystem which does anything outside the VFS box is regarded as an invasion. Gutting XFS to remove all the code which would not work without kernel changes removes a lot of the reasons people use XFS in the first place. 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 27 07:35:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RFZGV08938 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:35:16 -0800 Received: from s1.uklinux.net (mail.uklinux.net [80.84.72.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RFZBq08912 for ; Wed, 27 Mar 2002 07:35:12 -0800 Received: from pyewacket.nic.uklinux.net (host213-122-28-74.in-addr.btopenworld.com [213.122.28.74]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g2RFbRH06552 for ; Wed, 27 Mar 2002 15:37:27 GMT Envelope-To: Received: from nic by pyewacket.nic.uklinux.net with local (Exim 3.34 #1) id 16qFTN-0001mS-00 for linux-xfs@oss.sgi.com; Wed, 27 Mar 2002 15:36:25 +0000 Subject: Re: XFS pressure group From: Nic Doye To: linux-xfs@oss.sgi.com In-Reply-To: <20020327152206.A5364@wotan.suse.de> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017238289.6621.5.camel@pyewacket> <20020327152206.A5364@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 (1.0.1-2) Date: 27 Mar 2002 15:36:25 +0000 Message-Id: <1017243385.6620.12.camel@pyewacket> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 14:22, Andi Kleen wrote: > On Wed, Mar 27, 2002 at 02:11:29PM +0000, Nic Doye wrote: > > I don't think it's been done before and possibly not a good precendent > > I has been done before []. I think it is a waste of > your time. [Sensible argument deleted]. Yeah - point taken. If it's purely a technical thing then so be it. Sorry for the bandwidth wastage, nic From owner-linux-xfs@oss.sgi.com Wed Mar 27 07:38:15 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RFcFc09114 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:38:15 -0800 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RFc9q09088 for ; Wed, 27 Mar 2002 07:38:09 -0800 Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g2RFeNG10111; Wed, 27 Mar 2002 16:40:23 +0100 Date: Wed, 27 Mar 2002 16:40:23 +0100 From: Christoph Hellwig To: Steve Lord Cc: Tony Gale , Florin Andrei , Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Message-ID: <20020327164023.A9888@caldera.de> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <20020327162003.A8199@caldera.de> <1017242992.27964.13.camel@jen.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: <1017242992.27964.13.camel@jen.americas.sgi.com>; from lord@sgi.com on Wed, Mar 27, 2002 at 09:29:52AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 27, 2002 at 09:29:52AM -0600, Steve Lord wrote: > > - in 2.4 JFS requires two memory allocations for each new inode, > > bot just one like ext2/ext3/xfs/etc > > xfs does two by the way. I would have to do three with using ->u.generic_ip then ;) Okay, saw the vnode apropeach. > > but given the current SGI policy/development model I don't think b) > > is / will be a goal. It's up to Al and Linus to decide whether b) is > > important or not, but I strongly doubt they will take an XFS patch with > > all the mainline invasion the current version has. > > So, it is OK for people to rip the guts out of the VM every other week It absoloutly is not and I'm on -ac all the time because I have huge problems with the new VM. > and for Al Viro to apply so many patches the filesystem API that your > head spins, but a filesystem which does anything outside the VFS box > is regarded as an invasion. Al's VFS changes aren't for fun but to fix problems. > Gutting XFS to remove all the code which would not work without kernel > changes removes a lot of the reasons people use XFS in the first place. This opinion is not shared my many core kernel developers. There sometimes are core changes that make fully sense, but then you have to axplain why they make sense and submit them separate. That's how Linux development works. And when looking at Nathan's xattr work it looks like SGI also is sucessfull when working this way. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Wed Mar 27 07:40:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RFeRU09309 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:40: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 g2RFeMq09282 for ; Wed, 27 Mar 2002 07:40:22 -0800 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2RGgfBA027599 for ; Wed, 27 Mar 2002 08:42:41 -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 HAA34553 for ; Wed, 27 Mar 2002 07:42:10 -0800 (PST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 4F5C313650D for ; Wed, 27 Mar 2002 07:42:10 -0800 (PST) Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Florin Andrei To: linux-xfs@oss.sgi.com In-Reply-To: <20020327162213.B8199@caldera.de> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <1017242029.30422.26.camel@stantz.corp.sgi.com> <20020327162213.B8199@caldera.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 27 Mar 2002 07:42:10 -0800 Message-Id: <1017243730.30422.42.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 07:22, Christoph Hellwig wrote: > > Have you ever seen Linus merging something because it appeared on /. ? Not because "it appeared on /.", but yes, i've seen him influenced by popular beliefs, and making decisions based on popularity, and buzzword-related reasons, not technical reasons. ReiserFS is one example. It's been included when it was kind-of far from being production-ready, just because media was starting to jump on Linux and pound on it because "it didn't had a journalised filesystem". But hey, i really appreciate ReiserFS and all that stuff. This is not a flamewar. In fact, ReiserFS evolved a lot in terms of stability. I'm merely pointing out that Linus is just human, not the "never-erring god of The Book Of Technical Merits". I repeat, this is not a FS flamewar. =) I'm not even sure Linus' decision was wrong; it's likely it wasn't. Media is a big thing, dammit... :-( -- Florin Andrei "Sorry judge, we would like to publish the file formats, but the data is not stored in files. It is stored in a database that is an indivisible part of the operating system." - a potential future Microsoft excuse From owner-linux-xfs@oss.sgi.com Wed Mar 27 07:41:09 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RFf9409444 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:41:09 -0800 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RFf4q09418 for ; Wed, 27 Mar 2002 07:41:04 -0800 Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g2RFhIq10365; Wed, 27 Mar 2002 16:43:18 +0100 Date: Wed, 27 Mar 2002 16:43:18 +0100 From: Christoph Hellwig To: Chris Tooley Cc: Florin Andrei , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Message-ID: <20020327164318.A10118@caldera.de> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sg <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <1017242029.30422.26.camel@stantz.corp.sgi.com> <1017242251.30422.29.camel@stantz.corp.sgi.com> <1017243037.19718.15.camel@filecabinet.amoa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1017243037.19718.15.camel@filecabinet.amoa.org>; from ctooley@amoa.org on Wed, Mar 27, 2002 at 03:30:37PM +0000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 27, 2002 at 03:30:37PM +0000, Chris Tooley wrote: > That is one of the good things about going through a distribution kernel > first. There is usually someone there that give it a once over and get > it pushed up to Linus for another look over. Since SGI already creates > RedHat Installers and RPMs for RedHat, it seems like a convenient target > distro. There are some distributions that take random features into their kernels, others consider they maintainability of these extra features, and for a complex filesystem that manages ondisk structures the risc involved with providing support to customers years later is very high. > And, Christoph, I thought ACL/EA went into the kernel at 2.5.3 which was > before JFS at 2.5.6 ... I know - I'm working hard on getting EA support working.. Christoph -- Of course it doesn't work. We've performed a software upgrade. From owner-linux-xfs@oss.sgi.com Wed Mar 27 07:49:43 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RFnhT09678 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:49:43 -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 g2RFnZq09652 for ; Wed, 27 Mar 2002 07:49:36 -0800 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id A58EA1E9FB; Wed, 27 Mar 2002 16:51:53 +0100 (MET) Date: Wed, 27 Mar 2002 16:51:53 +0100 From: Andi Kleen To: Christoph Hellwig Cc: Tony Gale , Florin Andrei , Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Message-ID: <20020327165153.A29381@wotan.suse.de> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <20020327162003.A8199@caldera.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020327162003.A8199@caldera.de> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I think XFS could try hard to archive the first item, even if it > loses some functionaly that needs to be pulled in through extra patches, > but given the current SGI policy/development model I don't think b) > is / will be a goal. It's up to Al and Linus to decide whether b) is > important or not, but I strongly doubt they will take an XFS patch with > all the mainline invasion the current version has. I think outside XFS changes should be definitely done if it makes XFS cleaner and is a improvement of the rest of the kernel too. I also don't think it'll be a big problem to integrate such changes (even independent of XFS) when they are submitted separately and explained to the relevant maintainers. To give one example the current hack used in XFS to manage NFS readahead windows is rather ugly. It would be much cleaner to change nfsd instead to cache file descriptors and remove the ugly/bad/broken racache there. Such a change would help XFS and clean up the kernel and be an obvious improvement for everybody and I think it would be rather easy to integrate it. Trying hard in XFS to not change code outside fs/xfs is imho a waste of time. Just for outside changes it is probably best and most painless to submit them as soon as possible when they are done, not defer them to the great "xfs merging". This way XFS will eventually just fit naturally in. -Andi From owner-linux-xfs@oss.sgi.com Wed Mar 27 07:53:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RFrA909856 for linux-xfs-outgoing; Wed, 27 Mar 2002 07:53:10 -0800 Received: from relay.dera.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RFr4q09828 for ; Wed, 27 Mar 2002 07:53:05 -0800 Received: (qmail 5034 invoked from network); 27 Mar 2002 15:55:27 +0000 Received: from syntax.dera.gov.uk (HELO syntax.dstl.gov.uk) (146.80.9.50) by relay.dera.gov.uk with SMTP; 27 Mar 2002 15:55:27 +0000 Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Tony Gale To: Steve Lord Cc: Christoph Hellwig , Florin Andrei , Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1017242992.27964.13.camel@jen.americas.sgi.com> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <20020327162003.A8199@caldera.de> <1017242992.27964.13.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 27 Mar 2002 15:55:26 +0000 Message-Id: <1017244527.16216.26.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 15:29, Steve Lord wrote: > > So, it is OK for people to rip the guts out of the VM every other week > and for Al Viro to apply so many patches the filesystem API that your > head spins, but a filesystem which does anything outside the VFS box > is regarded as an invasion. > > Gutting XFS to remove all the code which would not work without kernel > changes removes a lot of the reasons people use XFS in the first place. > Yes, I don't believe that's a goer. But, now you've bitten Steve, why aren't you/SGI pushing XFS split-patches at Linus/Al/lkml regularly? Is it because you don't think they are ready? I don't agree that advertising is the way to get things into the kernel - pure bloody mindedness seems more effective. You are at least likely to get some feedback on why they aren't currently being included. -tony From owner-linux-xfs@oss.sgi.com Wed Mar 27 08:04:37 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RG4bT12616 for linux-xfs-outgoing; Wed, 27 Mar 2002 08:04:37 -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 g2RG4Tq12589 for ; Wed, 27 Mar 2002 08:04: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 g2RG6l6G028618 for ; Wed, 27 Mar 2002 08:06:47 -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 KAA67758; Wed, 27 Mar 2002 10:06:47 -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 KAA27183; Wed, 27 Mar 2002 10:06:47 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2RG3Lc30082; Wed, 27 Mar 2002 10:03:21 -0600 Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Steve Lord To: Tony Gale Cc: Christoph Hellwig , Florin Andrei , Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1017244527.16216.26.camel@syntax.dstl.gov.uk> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <20020327162003.A8199@caldera.de> <1017242992.27964.13.camel@jen.americas.sgi.com> <1017244527.16216.26.camel@syntax.dstl.gov.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Mar 2002 10:03:21 -0600 Message-Id: <1017245001.27964.83.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 09:55, Tony Gale wrote: > On Wed, 2002-03-27 at 15:29, Steve Lord wrote: > > > > So, it is OK for people to rip the guts out of the VM every other week > > and for Al Viro to apply so many patches the filesystem API that your > > head spins, but a filesystem which does anything outside the VFS box > > is regarded as an invasion. > > > > Gutting XFS to remove all the code which would not work without kernel > > changes removes a lot of the reasons people use XFS in the first place. > > > > Yes, I don't believe that's a goer. > > But, now you've bitten Steve, why aren't you/SGI pushing XFS > split-patches at Linus/Al/lkml regularly? Because I have a lot of other work I do for SGI apart from Linux XFS, work which generates revenue. I do not yet feel I have the time to dedicate to going through the process of getting XFS into the kernel. Once I start, I expect the floodgates to open, and basically I would get totally buried, then something would come up on the Irix side and I would have to drop the process for a couple of weeks. Having said that, I am working towards this, I know the clock is ticking on 2.5. > > Is it because you don't think they are ready? I don't agree that > advertising is the way to get things into the kernel - pure bloody > mindedness seems more effective. Well, I am not Hans Reiser when it comes to being bloody minded! > > You are at least likely to get some feedback on why they aren't > currently being included. because we have not asked to be included! > > -tony > 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 27 08:06:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RG6al12796 for linux-xfs-outgoing; Wed, 27 Mar 2002 08:06:36 -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 g2RG6Xq12770 for ; Wed, 27 Mar 2002 08:06: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 g2RG8p6G028729 for ; Wed, 27 Mar 2002 08:08:51 -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 KAA68232; Wed, 27 Mar 2002 10:08:50 -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 KAA22607; Wed, 27 Mar 2002 10:08:50 -0600 (CST) Subject: Re: Can't build CVS kernels of 20020321 & 20020327 From: Eric Sandeen To: Bas Cc: linux-xfs@oss.sgi.com In-Reply-To: <004a01c1d56b$cae7cb50$3b00a8c0@aplabwp0368359> References: <004a01c1d56b$cae7cb50$3b00a8c0@aplabwp0368359> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 27 Mar 2002 10:08:50 -0600 Message-Id: <1017245330.16305.16.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 02:45, Bas wrote: > Hi, > > It's not possible for me to build the kernel mentioned above. I saw the new > qouta options and suspect it has something to do with it, but I'm not sure. > > Building everything goes fine, but at the end of the run it's not able to > produce a kernel because of DQUOT_SYNC. I don't have the exact error here. Does stock XFS+linux build for your configuration, without those extra patches? The exact error would help. XFS quota is now keeping up with Jan's quota code, so if your other patches expect stock quota, something might break (although I don't see "DQUOT" anywhere in evms-0.9.2) -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 27 08:12:10 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RGCAE13002 for linux-xfs-outgoing; Wed, 27 Mar 2002 08:12:10 -0800 Received: from relay.dera.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RGC5q12976 for ; Wed, 27 Mar 2002 08:12:05 -0800 Received: (qmail 10943 invoked from network); 27 Mar 2002 16:14:27 +0000 Received: from syntax.dera.gov.uk (HELO syntax.dstl.gov.uk) (146.80.9.50) by relay.dera.gov.uk with SMTP; 27 Mar 2002 16:14:27 +0000 Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing From: Tony Gale To: Steve Lord Cc: Christoph Hellwig , Florin Andrei , Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1017245001.27964.83.camel@jen.americas.sgi.com> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <20020327162003.A8199@caldera.de> <1017242992.27964.13.camel@jen.americas.sgi.com> <1017244527.16216.26.camel@syntax.dstl.gov.uk> <1017245001.27964.83.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 27 Mar 2002 16:14:27 +0000 Message-Id: <1017245667.14218.33.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-03-27 at 16:03, Steve Lord wrote: > > Because I have a lot of other work I do for SGI apart from Linux XFS, > work which generates revenue. I do not yet feel I have the time to > dedicate to going through the process of getting XFS into the kernel. > Once I start, I expect the floodgates to open, and basically I would > get totally buried, then something would come up on the Irix side and I > would have to drop the process for a couple of weeks. > > Having said that, I am working towards this, I know the clock is > ticking on 2.5. Ok, thats understandable. Perhaps we should be petitioning SGI to free up your time instead of to bother Linus/Al :-) > > > > > Is it because you don't think they are ready? I don't agree that > > advertising is the way to get things into the kernel - pure bloody > > mindedness seems more effective. > > Well, I am not Hans Reiser when it comes to being bloody minded! Few people are :-) -tony From owner-linux-xfs@oss.sgi.com Wed Mar 27 10:46:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RIknD15927 for linux-xfs-outgoing; Wed, 27 Mar 2002 10:46:49 -0800 Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RIkiq15900 for ; Wed, 27 Mar 2002 10:46:44 -0800 Received: from zip.com.au (root@zipperii.zip.com.au [61.8.0.87]) by vasquez.zip.com.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id FAA17965; Thu, 28 Mar 2002 05:48:52 +1100 X-Authentication-Warning: vasquez.zip.com.au: Host root@zipperii.zip.com.au [61.8.0.87] claimed to be zip.com.au Message-ID: <3CA213B3.30A06FE1@zip.com.au> Date: Wed, 27 Mar 2002 10:47:15 -0800 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig CC: Tony Gale , Florin Andrei , Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <20020327162003.A8199@caldera.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christoph Hellwig wrote: > > ... > - sometimes the core kernel really should be changed. An example > is the missing export of block_flushpage in pre-2.4.18 kernels > (or 2.5) - JFS works around this in a way I absoloutly don't like. That's dumb. They should just export the damn thing and argue the case. The block_flushpage and block_truncate_page functions need to become address_space operations, in fact. ext3 probably changed more stuff in the core kernel than XFS does. But those changes made sense and were, ahem, skilfully explained to Linus :) - From owner-linux-xfs@oss.sgi.com Wed Mar 27 11:46:03 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RJk3016661 for linux-xfs-outgoing; Wed, 27 Mar 2002 11:46:03 -0800 Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RJjwq16633 for ; Wed, 27 Mar 2002 11:45:59 -0800 Received: (from hch@localhost) by ns.caldera.de (8.11.6/8.11.6) id g2RJldB22149; Wed, 27 Mar 2002 20:47:39 +0100 Date: Wed, 27 Mar 2002 20:47:39 +0100 From: Christoph Hellwig To: Andrew Morton Cc: Tony Gale , Florin Andrei , Simon Matter , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing Message-ID: <20020327204739.A22019@caldera.de> References: <3CA179E7.7413F25@ch.sauter-bc.com> <1017235934.29730.6.camel@stantz.corp.sgi.com> <1017240266.16216.8.camel@syntax.dstl.gov.uk> <20020327155602.A7730@caldera.de> <1017241257.14218.15.camel@syntax.dstl.gov.uk> <20020327162003.A8199@caldera.de> <3CA213B3.30A06FE1@zip.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CA213B3.30A06FE1@zip.com.au>; from akpm@zip.com.au on Wed, Mar 27, 2002 at 10:47:15AM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 27, 2002 at 10:47:15AM -0800, Andrew Morton wrote: > That's dumb. They should just export the damn thing and argue > the case. The block_flushpage and block_truncate_page functions > need to become address_space operations, in fact. I've been arguing the block_flushpage case for about half an year now. 2.4.18 finally exported block_flushpage, but so far I haven't managed to convience Linus.. From owner-linux-xfs@oss.sgi.com Wed Mar 27 12:26:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RKQMs17108 for linux-xfs-outgoing; Wed, 27 Mar 2002 12:26:22 -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 g2RKQIq17079 for ; Wed, 27 Mar 2002 12:26:18 -0800 Received: from sam.engr.sgi.com (sam.engr.sgi.com [163.154.6.37]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g2RLbEkw001213 for ; Wed, 27 Mar 2002 15:37:14 -0600 Received: from turbo-linux.engr.sgi.com (turbo-linux.engr.sgi.com [163.154.6.103]) by sam.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id MAA36619; Wed, 27 Mar 2002 12:27:21 -0800 (PST) Date: Wed, 27 Mar 2002 12:28:04 -0800 (PST) From: Paul Jackson To: Florin Andrei cc: Subject: Re: [Announce] XFS 1.1 Prerelease 2 available for testing In-Reply-To: <1017238219.30422.14.camel@stantz.corp.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 27 Mar 2002, Florin Andrei wrote: > > If you divide ${popularity} / ${technical merits}, XFS gets an > abnormally low result. Must be the SGI Curse. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373 From owner-linux-xfs@oss.sgi.com Wed Mar 27 12:40:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RKel317393 for linux-xfs-outgoing; Wed, 27 Mar 2002 12:40:47 -0800 Received: from saiya-jin.flinthills.com (root@saiya-jin.flinthills.com [64.39.192.211]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RKefq17361 for ; Wed, 27 Mar 2002 12:40:41 -0800 Received: from localhost (cappicard@localhost [127.0.0.1]) by saiya-jin.flinthills.com (8.12.2/8.12.2/Debian -5) with ESMTP id g2RKgq89001047; Wed, 27 Mar 2002 14:42:57 -0600 Date: Wed, 27 Mar 2002 14:42:51 -0600 (CST) From: Derek J Witt To: Paul Blazejowski cc: Derek James Witt , Subject: Re: superblocks and lilo In-Reply-To: <1017205783.712.9.camel@blaze> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Paul. I have already submitted my patch to the maintainer of LILO. :-) This would be a good idea to put it up onto the faq. ** Derek J Witt ** * Email: mailto:djw@flinthills.com * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** On 27 Mar 2002, Paul Blazejowski wrote: > Date: 27 Mar 2002 00:09:43 -0500 > From: Paul Blazejowski > To: Derek James Witt > Cc: linux-xfs@oss.sgi.com > Subject: Re: superblocks and lilo > > On Tue, 2002-03-26 at 08:24, Derek James Witt wrote: > > > Nathan, yeah. I agree. I have submitted a lilo patch to do just that > > (not allowing itself to install onto a XFS partition). But, it seems > > there are going to be folks not subscribed to the list that may > > unknowingly install lilo in that manner. > > Maybe this patch could be added into the FAQ on oss.sgi.com/projects/xfs > site? or perhaps it would be better to submit the patch to author of > LILO? Just a suggestion here... > > Paul > > From owner-linux-xfs@oss.sgi.com Wed Mar 27 12:49:25 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RKnPa17604 for linux-xfs-outgoing; Wed, 27 Mar 2002 12:49: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 g2RKnMq17578 for ; Wed, 27 Mar 2002 12:49:22 -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 g2RKpe6G018833 for ; Wed, 27 Mar 2002 12:51:41 -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 OAA70035 for ; Wed, 27 Mar 2002 14:51:40 -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 OAA67704 for ; Wed, 27 Mar 2002 14:51:40 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2RKmCF09989; Wed, 27 Mar 2002 14:48:12 -0600 Message-Id: <200203272048.g2RKmCF09989@jen.americas.sgi.com> Date: Wed, 27 Mar 2002 14:48:12 -0600 Subject: TAKE - remove some duplicate prototypes To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Noticed by Christoph Hellwig Date: Wed Mar 27 12:49:59 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:115027a linux/include/linux/pagemap.h - 1.40 linux/include/linux/fs.h - 1.146 - remove duplicate prototypes From owner-linux-xfs@oss.sgi.com Wed Mar 27 13:29:24 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RLTO118396 for linux-xfs-outgoing; Wed, 27 Mar 2002 13:29:24 -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 g2RLTHq18370 for ; Wed, 27 Mar 2002 13:29:17 -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 g2RMeDkw002142 for ; Wed, 27 Mar 2002 16:40: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 IAA08980; Thu, 28 Mar 2002 08:30:17 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA50544; Thu, 28 Mar 2002 08:30:16 +1100 (AEDT) Date: Thu, 28 Mar 2002 08:30:15 +1100 From: Nathan Scott To: Bas Cc: linux-xfs@oss.sgi.com Subject: Re: Can't build CVS kernels of 20020321 & 20020327 Message-ID: <20020328083015.G47866@wobbly.melbourne.sgi.com> References: <004a01c1d56b$cae7cb50$3b00a8c0@aplabwp0368359> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <004a01c1d56b$cae7cb50$3b00a8c0@aplabwp0368359>; from weblists@gmx.net on Wed, Mar 27, 2002 at 09:45:48AM +0100 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, On Wed, Mar 27, 2002 at 09:45:48AM +0100, Bas wrote: > Hi, > > It's not possible for me to build the kernel mentioned above. I saw the new > qouta options and suspect it has something to do with it, but I'm not sure. > > Building everything goes fine, but at the end of the run it's not able to > produce a kernel because of DQUOT_SYNC. I don't have the exact error here. Hmm... 20020327 - that's yesterday. DQUOT_SYNC doesn't appear in the source at all anymore (for awhile now), so I suspect the problem must be at your end. Try getting a fresh CVS copy and/or "make clean". [ The other patches you mentioned should not have anything to do with this problem. ] $ find . -type f | xargs fgrep DQUOT_SYNC ./fs/buffer.c: DQUOT_SYNC_SB(sb); ./fs/buffer.c: DQUOT_SYNC_DEV(dev); ./include/linux/quotaops.h:#define DQUOT_SYNC_DEV(dev) sync_dquots_dev(dev, -1) ./include/linux/quotaops.h:#define DQUOT_SYNC_SB(sb) sync_dquots_sb(sb, -1) ./include/linux/quotaops.h:#define DQUOT_SYNC_DEV(dev) do { } while(0) ./include/linux/quotaops.h:#define DQUOT_SYNC_SB(sb) do { } while(0) $ FWIW, DQUOT_SYNC used to come from include/linux/quotaops.h too, and its definition was also dependent on CONFIG_QUOTA. The reason you'd be getting an unresolved symbol would be a file referencing DQUOT_SYNC wasn't #include'ing quotaops.h; but thats all by-the-by - the real problem is related to the source you're using I suspect - it certainly doesn't match CVS of yesterday. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 27 13:31:44 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RLViF18543 for linux-xfs-outgoing; Wed, 27 Mar 2002 13:31:44 -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 g2RLVeq18517 for ; Wed, 27 Mar 2002 13:31:40 -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 g2RLXv6G022667 for ; Wed, 27 Mar 2002 13:33:58 -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 IAA09005; Thu, 28 Mar 2002 08:32:41 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA42241; Thu, 28 Mar 2002 08:32:39 +1100 (AEDT) Date: Thu, 28 Mar 2002 08:32:39 +1100 From: Nathan Scott To: kend@xanoptix.com Cc: nic@uklinux.net, florin@sgi.com, linux-xfs@oss.sgi.com Subject: ACLs (was Re: XFS pressure group) Message-ID: <20020328083239.H47866@wobbly.melbourne.sgi.com> References: <1017238289.6621.5.camel@pyewacket> <32832.10.20.1.46.1017241549.squirrel@webmail.xanoptix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <32832.10.20.1.46.1017241549.squirrel@webmail.xanoptix.com>; from kend@xanoptix.com on Wed, Mar 27, 2002 at 10:05:49AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Mar 27, 2002 at 10:05:49AM -0500, kend@xanoptix.com wrote: > ... > Seriously, though -- first and foremost, I'm an XFS "user", and most > certainly am not competent to comment in-depth on kernel issues, but I'd > always been somewhat under the impression that ACLs brought up security > issues that had yet to be dealt with, and that that was a large portion of > the reason for Linus' reluctance to include it. Is this true? No. > If so, how has it been addressed? Or am I merely misguided? The latter. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 27 13:36:47 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RLal618697 for linux-xfs-outgoing; Wed, 27 Mar 2002 13:36:47 -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 g2RLaiq18671 for ; Wed, 27 Mar 2002 13:36:44 -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 g2RMd1BA022597 for ; Wed, 27 Mar 2002 14:39:02 -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 IAA09046; Thu, 28 Mar 2002 08:37:44 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA50631; Thu, 28 Mar 2002 08:37:42 +1100 (AEDT) Date: Thu, 28 Mar 2002 08:37:41 +1100 From: Nathan Scott To: Volstan Stephen Cc: linux-xfs@oss.sgi.com Subject: Re: problem running xfs_repair Message-ID: <20020328083741.I47866@wobbly.melbourne.sgi.com> References: <00f201c1d57c$77304e40$0a01a8c0@securities.co.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00f201c1d57c$77304e40$0a01a8c0@securities.co.in>; from volstan@securities.com on Wed, Mar 27, 2002 at 04:15:02PM +0530 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, On Wed, Mar 27, 2002 at 04:15:02PM +0530, Volstan Stephen wrote: > ... > I booted the system using a bootable disk and ran xfs_repair on this partition and eachtime it come out with segmentation fault. > The linux version is RH7.2 with 2.4.9-13SGI_XFS_1.0.2 . > > Any thoughts on how I can get this going. Could you send me the `core' file from xfs_repair (if it didn't generate one, try "limit coredumpsize unlimited" then re-run xfs_repair and it should create one) and your xfs_repair binary? I'll see if I can figure out where its going off the rails. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Mar 27 14:57:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RMvIO20373 for linux-xfs-outgoing; Wed, 27 Mar 2002 14:57:18 -0800 Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2RMvDq20335 for ; Wed, 27 Mar 2002 14:57:14 -0800 Received: (qmail 10576 invoked by uid 1000); 27 Mar 2002 22:56:44 -0000 To: linux-xfs@oss.sgi.com Subject: Verifying XFS dumps From: Florian Weimer Date: Wed, 27 Mar 2002 23:56:44 +0100 Message-ID: <87663hmxg3.fsf@CERT.Uni-Stuttgart.DE> Lines: 11 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is it possible to verify dumps created with xfsdump by comparing it to the actual disk contents? Generating MD5/SHA-1 hashes for files in the dump is sufficient, and you may assume that there aren't any files with holes. ;-) Thanks, -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-linux-xfs@oss.sgi.com Wed Mar 27 15:51:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2RNpwj21409 for linux-xfs-outgoing; Wed, 27 Mar 2002 15:51:58 -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 g2RNptq21383 for ; Wed, 27 Mar 2002 15:51:55 -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 g2S0sDBA028792 for ; Wed, 27 Mar 2002 16:54:13 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA24659 for linux-xfs@oss.sgi.com; Thu, 28 Mar 2002 10:52:55 +1100 (EST) Date: Thu, 28 Mar 2002 10:52:55 +1100 (EST) From: Nathan Scott Message-Id: <200203272352.KAA24659@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf merging Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Mar 27 15:50:16 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:115060a linux/fs/xfs/linux/xfs_lrw.c - 1.130 linux/fs/xfs/pagebuf/page_buf_io.c - 1.19 - merge in a couple more multiple block size support changes, no difference for blocksize == pagesize case. From owner-linux-xfs@oss.sgi.com Wed Mar 27 19:17:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2S3Hjb28794 for linux-xfs-outgoing; Wed, 27 Mar 2002 19:17:45 -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 g2S3Hdq28768 for ; Wed, 27 Mar 2002 19:17:39 -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 g2S4JwBA003000 for ; Wed, 27 Mar 2002 20:19:58 -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 VAA76865 for ; Wed, 27 Mar 2002 21:19: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 VAA18519 for ; Wed, 27 Mar 2002 21:19:57 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2S3GRG28310; Wed, 27 Mar 2002 21:16:27 -0600 Message-Id: <200203280316.g2S3GRG28310@jen.americas.sgi.com> Date: Wed, 27 Mar 2002 21:16:27 -0600 Subject: TAKE - ensure unsigned long used to store irq state To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This should have no effect on platforms where int and long are the same size, but for other platforms it will raise the chances of xfs functioning correctly. Date: Wed Mar 27 19:18:22 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:115078a linux/fs/xfs/xfs_log.c - 1.245 linux/fs/xfs/xfs_trans_priv.h - 1.20 linux/fs/xfs/xfs_da_btree.c - 1.123 linux/fs/xfs/xfs_trans_ail.c - 1.61 linux/fs/xfs/xfs_log_recover.c - 1.220 linux/fs/xfs/xfs_dquot_item.c - 1.25 linux/fs/xfs/xfs_mount.h - 1.137 linux/fs/xfs/xfs_mount.c - 1.277 linux/fs/xfs/xfs_alloc.c - 1.147 linux/fs/xfs/linux/xfs_vnode.c - 1.72 linux/fs/xfs_support/sv.c - 1.5 linux/fs/xfs_dmapi/xfsjunk.c - 1.4 linux/fs/xfs_dmapi/dmapi_session.c - 1.5 linux/fs/xfs_dmapi/dmapi_right.c - 1.4 linux/fs/xfs_dmapi/dmapi_register.c - 1.8 linux/fs/xfs_dmapi/dmapi_private.h - 1.6 linux/include/linux/xfs_support/mutex.h - 1.2 linux/include/linux/xfs_support/sv.h - 1.2 From owner-linux-xfs@oss.sgi.com Thu Mar 28 01:42:46 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2S9gkA03551 for linux-xfs-outgoing; Thu, 28 Mar 2002 01:42:46 -0800 Received: from nt3.au.de (gateway.advanced-unibyte.de [213.69.4.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2S9ggq03525 for ; Thu, 28 Mar 2002 01:42:42 -0800 Received: from mail pickup service by nt3.au.de with Microsoft SMTPSVC; Thu, 28 Mar 2002 10:45:06 +0100 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain Subject: XFS and MD multipath Date: Thu, 28 Mar 2002 10:45:03 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS and MD multipath thread-index: AcHWPTwXKz3V3xu8Q22tWID1atNfKA== From: "Michael Dr|ing" To: X-OriginalArrivalTime: 28 Mar 2002 09:45:06.0458 (UTC) FILETIME=[3DFF5FA0:01C1D63D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g2S9ghq03526 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, We noticed some problems with XFS on a multipath raid device: As soon as one path is removed the system does not switch to the second path. But as soon as the failed path is reconnected, Linux shuts down the (reenabled) path... With ext2, everything works as expected. Is multipath not supported on XFS? Or are we doing something wrong here? Please cc any responses to me as I'm not subscribed to the list. Thanks, --Michael Drüing Advanced UniByte GmbH From owner-linux-xfs@oss.sgi.com Thu Mar 28 07:07:07 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2SF77U11056 for linux-xfs-outgoing; Thu, 28 Mar 2002 07:07:07 -0800 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-225.qld.bigpond.net.au [203.45.214.225]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2SF72q11027 for ; Thu, 28 Mar 2002 07:07:02 -0800 Received: by monkeyiq.dnsalias.org id g2SFC9Y03492 ; Fri, 29 Mar 2002 01:12:09 +1000 Date: Fri, 29 Mar 2002 01:12:09 +1000 Message-Id: <200203281512.g2SFC9Y03492@monkeyiq.dnsalias.org> Subject: attr_list(3) on XFS, headers and such From: Ben Martin To: acl list , xfs list Content-Type: text/plain Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I noticed that in the recent rpms for attr-devel there is a man page for attr_list again, though there doesn't seem to be a declaration in the headers for this function and nothing in the sources defining it. Should this function exist in a 2.4.18+ environment? -- ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Thu Mar 28 07:06:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2SF66810945 for linux-xfs-outgoing; Thu, 28 Mar 2002 07:06:06 -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 g2SF62q10919 for ; Thu, 28 Mar 2002 07:06:02 -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 g2SG8KBA026189 for ; Thu, 28 Mar 2002 08:08:20 -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 JAA82298 for ; Thu, 28 Mar 2002 09:08:19 -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 JAA18111 for ; Thu, 28 Mar 2002 09:08:19 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g2SF8J026088; Thu, 28 Mar 2002 09:08:19 -0600 Message-Id: <200203281508.g2SF8J026088@stout.americas.sgi.com> Date: Thu, 28 Mar 2002 09:08:19 -0600 From: Eric Sandeen Subject: TAKE - Merge irix6.5f:irix:114941b Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk No functional change for Linux XFS, just keeping code in sync with Irix. Date: Thu Mar 28 07:06:54 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:115090a linux/fs/xfs/xfs_vnodeops.c - 1.522 - Merge irix6.5f:irix:114941b Bug 852300. In xfs_create_new(), for an existing file, if there are no changes made, then VOP_VNODE_CHANGE(x, VCHANGE_FLAGS_TRUNCATED, 3) must be called to release the IO token, clear the DVN_RECREATE flag, and unlock the dsv_dirlock. From owner-linux-xfs@oss.sgi.com Thu Mar 28 07:09:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2SF9nG11257 for linux-xfs-outgoing; Thu, 28 Mar 2002 07:09:49 -0800 Received: from rover (rover.mkp.net [209.217.122.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2SF9jq11231 for ; Thu, 28 Mar 2002 07:09:45 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=austin.mkp.net) by rover with esmtp (Exim 3.33 #1) id 16qbZP-0005mN-00; Thu, 28 Mar 2002 10:12:07 -0500 Received: (from mkp@localhost) by austin.mkp.net (8.11.6/8.11.6) id g2SFC4o12872; Thu, 28 Mar 2002 10:12:04 -0500 X-Authentication-Warning: austin.mkp.net: mkp set sender to mkp@mkp.net using -f To: "Michael Dr|ing" Cc: Subject: Re: XFS and MD multipath From: "Martin K. Petersen" Organization: mkp.net References: Date: 28 Mar 2002 10:12:04 -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 >>>>> "Michael" == Michael Dr|ing writes: Michael> We noticed some problems with XFS on a multipath raid device: Michael> As soon as one path is removed the system does not switch to Michael> the second path. But as soon as the failed path is Michael> reconnected, Linux shuts down the (reenabled) path... With Michael> ext2, everything works as expected. Is multipath not Michael> supported on XFS? Or are we doing something wrong here? That's odd. The multipath personality shouldn't expose any of this to the filesystem. And didn't last I looked at it. I'll add another path to my setup at work and give it a whirl later today. -- 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 Thu Mar 28 08:46:32 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2SGkWe12813 for linux-xfs-outgoing; Thu, 28 Mar 2002 08:46:32 -0800 Received: from muriel.parsec.at (muriel.parsec.at [212.236.50.199]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2SGkRq12786 for ; Thu, 28 Mar 2002 08:46:27 -0800 Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g2SGmh728479; Thu, 28 Mar 2002 17:48:43 +0100 Date: Thu, 28 Mar 2002 17:48:43 +0100 (CET) From: Andreas Gruenbacher X-X-Sender: To: Ben Martin cc: acl list , xfs list Subject: Re: [Acl-Devel] attr_list(3) on XFS, headers and such In-Reply-To: <200203281512.g2SFC9Y03492@monkeyiq.dnsalias.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 29 Mar 2002, Ben Martin wrote: > I noticed that in the recent rpms for attr-devel there is a man > page for attr_list again, though there doesn't seem to be a declaration > in the headers for this function and nothing in the sources defining it. > > Should this function exist in a 2.4.18+ environment? Looking at the version history, it seems attr_list has again been added to the CVS repository after having been deleted: . I am sure the XFS developers will respond in a few hours, when their working day starts. Anyway, this function was there for backwards compatibility with Irix; I don't know the details about why it was removed. On Linux you should use the listxattr system call (see ). Cheers, Andreas. From owner-linux-xfs@oss.sgi.com Thu Mar 28 11:49:18 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2SJnIu18931 for linux-xfs-outgoing; Thu, 28 Mar 2002 11:49:18 -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 g2SJn7q18905 for ; Thu, 28 Mar 2002 11:49:07 -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 g2SKpPBA010711 for ; Thu, 28 Mar 2002 12:51:25 -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 NAA20190 for ; Thu, 28 Mar 2002 13:51: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 NAA43125 for ; Thu, 28 Mar 2002 13:51:24 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2SJllj12964; Thu, 28 Mar 2002 13:47:47 -0600 Message-Id: <200203281947.g2SJllj12964@jen.americas.sgi.com> Date: Thu, 28 Mar 2002 13:47:47 -0600 Subject: TAKE - revamp pagebuf locking To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Pagebuf used to use an avl tree to organize cached buffers, one avl tree per filesystem, and a spinlock across the whole tree. There was also too much other use of spinlocks and complex interactions between them. This changes us to use a hash table for lookup of buffers, with one spinlock per hash chain. The spinlock within each pagebuf is now gone and code to lookup and free pagebufs is simplified. Handling of the list of delayed write pagebufs is cleaned up, and extensive use made of list macros. Finally in the I/O path, remove the case where we had pages without buffer heads (mmap write). This was causing excessive memory pressure on the flush path. This should also help out on the forced shutdown path although we are seeing cases where unmount fails after forced shutdown and a leak of an internal data structure. This code has had extensive testing, but it is a fairly radical change. Please let me know if things happen after you start using it. Steve Date: Thu Mar 28 11:45:15 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-newpagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:115116a linux/fs/xfs/pagebuf/page_buf_internal.h - 1.1 - pagebuf internal definitions moved here from page_buf.h linux/fs/xfs/xfsidbg.c - 1.178 - account for changes in pagebuf structure linux/fs/xfs/xfs_buf.h - 1.85 - couple of tweaks for reworked pagebuf. linux/fs/xfs/xfs_buf_item.c - 1.116 - a forced shutdown cleanup linux/fs/xfs/xfs_log_recover.c - 1.221 - correct locking on iclog buffers linux/fs/xfs/linux/xfs_linux.h - 1.63 - remove avl.h include, file deleted linux/fs/xfs/pagebuf/page_buf_io.c - 1.20 - always put buffer heads on pages, really only affects reading holes and page faults. Reduces memory pressure when flushing mmapped data. linux/fs/xfs/pagebuf/Makefile - 1.5 - remove avl.c, file deleted linux/fs/xfs/pagebuf/avl.c - 1.3 - file deleted linux/fs/xfs/pagebuf/page_buf_locking.c - 1.7 - rewrite pagebuf locking. The avl tree is gone and is replaced by hash buckets. Code is simpler, smaller and faster. linux/fs/xfs/pagebuf/page_buf.c - 1.15 - simplify locking of pagebufs linux/fs/xfs/pagebuf/page_buf.h - 1.10 - move pagebuf internal definitions to a new file linux/fs/xfs/pagebuf/avl.h - 1.2 - file deleted From owner-linux-xfs@oss.sgi.com Thu Mar 28 13:27:35 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2SLRZq21201 for linux-xfs-outgoing; Thu, 28 Mar 2002 13:27: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 g2SLRUq21175 for ; Thu, 28 Mar 2002 13:27:30 -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 g2SMcVkw012437 for ; Thu, 28 Mar 2002 16:38:31 -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 PAA91377 for ; Thu, 28 Mar 2002 15:29:48 -0600 (CST) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA16749 for ; Thu, 28 Mar 2002 15:29:48 -0600 (CST) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id PAA06557; Thu, 28 Mar 2002 15:29:47 -0600 (CST) Message-ID: <3CA38B4A.B42C9074@sgi.com> Date: Thu, 28 Mar 2002 15:29:47 -0600 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Verifying XFS dumps References: <20020328164907.K5356@boing.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The answer to this question is no. The only existing way of verifying the data within the dump is to restore it and compare the restored data to the actual disk contents. Kihonge JN > To: linux-xfs@oss.sgi.com > Subject: Verifying XFS dumps > From: Florian Weimer > Date: Wed, 27 Mar 2002 23:56:44 +0100 > > Is it possible to verify dumps created with xfsdump by comparing it to > the actual disk contents? > Generating MD5/SHA-1 hashes for files in the dump is sufficient, and > you may assume that there aren't any files with holes. ;-) > > Thanks, > -- > Florian Weimer Weimer@CERT.Uni-Stuttgart.DE > University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ > RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-linux-xfs@oss.sgi.com Thu Mar 28 15:37:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2SNbm425262 for linux-xfs-outgoing; Thu, 28 Mar 2002 15:37:48 -0800 Received: from tigger.cc-concepts.com (64-40-83-10.mb.dsl.mebtel.net [64.40.83.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2SNbdq25234 for ; Thu, 28 Mar 2002 15:37:39 -0800 Received: from thebaptistes.net (gwy3.cc-concepts.com [64.40.83.12]) (authenticated) by tigger.cc-concepts.com (8.11.6/8.11.6) with ESMTP id g2SNdqw21633; Thu, 28 Mar 2002 18:39:53 -0500 Message-ID: <3CA3A9C8.9060705@thebaptistes.net> Date: Thu, 28 Mar 2002 18:39:52 -0500 From: Mike Baptiste User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan Ivanov CC: linux-xfs@oss.sgi.com Subject: Re: file coruption on power fail References: X-Enigmail-Version: 0.39.2.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk FWIW - I had the exact same problem. I'm running 2.4.18-xfs, compiled with gcc3.0.4 on RH 7.2 I was running red-carpet to update gnome and it updated a LOT of core gnome packages. Well, X froze solid (except for the mouse) ctrl-alt-backspace did nothing (2nd system this happened to me). Finally after waiting a good long while, I powered down. When I restarted, I got a bunch of error msgs due to missing libraries (X and kerberos) X refused to start. I did an xfs_repair - no help. Since I was on XFree 4.1.0, I grabbed the 4.2.0 rpms and installed those from the command line along with the kerberos RPMs using the --force option. After that, everything worked fine. Nothing else got corrupted - only the X libraries (well that I've found so far - but I use this system heavily and everything seems to be happy) Wish I had more info - but this was at work so I just got it working again with the rpm install. Mike Ivan Ivanov wrote: | Are there any chances for solving this problem. | | I have read all the faq and the XFS white paper. | I have tried allmost all XFS patches from oss.sgi.com for various kernels | and know that XFS logs only metadata updates. | It is fast, has EA and ACL but when the system crashes for any reason most | of the open files ( including opened ro ) are lost - for example | XF86Config. | | Regards | Ivan | From owner-linux-xfs@oss.sgi.com Thu Mar 28 16:01:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2T01cf26316 for linux-xfs-outgoing; Thu, 28 Mar 2002 16:01: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 g2T01Xq26290 for ; Thu, 28 Mar 2002 16:01:33 -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 g2T13pBA021638 for ; Thu, 28 Mar 2002 17:03:52 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA31348 for linux-xfs@oss.sgi.com; Fri, 29 Mar 2002 11:02:34 +1100 (EST) Date: Fri, 29 Mar 2002 11:02:34 +1100 (EST) From: Nathan Scott Message-Id: <200203290002.LAA31348@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - ACL tidyup Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Mar 28 16:00:32 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:115139a cmd/xfsprogs/include/xfs_mount.h - 1.12 cmd/xfsprogs/libxfs/xfs_da_btree.c - 1.8 - sync with kernel, no-op change for userspace. Date: Thu Mar 28 16:01:39 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:115140a linux/include/linux/fs.h - 1.147 linux/fs/Config.in - 1.77 linux/fs/intermezzo/vfs.c - 1.5 linux/include/linux/posix_acl.h - 1.2 - a few minor changes to the ACL code which Andreas has asked for. From owner-linux-xfs@oss.sgi.com Thu Mar 28 16:06:58 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2T06ww26521 for linux-xfs-outgoing; Thu, 28 Mar 2002 16:06:58 -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 g2T06oq26490 for ; Thu, 28 Mar 2002 16:06:50 -0800 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx09)) with ESMTP id EE3FB61E0; Fri, 29 Mar 2002 01:09:06 +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 BAA06725; Fri, 29 Mar 2002 01:09:06 +0100 (MET) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 8686E57306; Fri, 29 Mar 2002 01:08:46 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 0081125836; Fri, 29 Mar 2002 01:08:41 +0100 (CET) Message-ID: <3CA3B089.EEA70773@ch.sauter-bc.com> Date: Fri, 29 Mar 2002 01:08:42 +0100 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i586) X-Accept-Language: en MIME-Version: 1.0 To: Mike Baptiste Cc: Ivan Ivanov , linux-xfs@oss.sgi.com Subject: Re: file coruption on power fail References: <3CA3A9C8.9060705@thebaptistes.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Baptiste schrieb: > > FWIW - I had the exact same problem. I'm running 2.4.18-xfs, compiled > with gcc3.0.4 on RH 7.2 I was running red-carpet to update gnome and it > updated a LOT of core gnome packages. Well, X froze solid (except for > the mouse) ctrl-alt-backspace did nothing (2nd system this happened to > me). Finally after waiting a good long while, I powered down. Are you sure it was not the gnome update which corrupted your libraries? That could explain why xfs_repair found nothing wrong. I'm quite sure this time it was not XFS. Too bad you didn't check the failed libs and look whether they contain "the zero's". Anyway, zero filled files after unclean shutdown is one of the weak points of XFS. As Steve mentioned, it was adressed with recent changes and I expect it has and will improve much. If you have a stable kernel and a good power supply with UPS, the risk of loosing anything on a XFS filesystem is _very_ low. On unstable kernels and power supplies, there is always a chance to loose some bit's. -Simon > > When I restarted, I got a bunch of error msgs due to missing libraries > (X and kerberos) X refused to start. > > I did an xfs_repair - no help. Since I was on XFree 4.1.0, I grabbed > the 4.2.0 rpms and installed those from the command line along with the > kerberos RPMs using the --force option. > > After that, everything worked fine. Nothing else got corrupted - only > the X libraries (well that I've found so far - but I use this system > heavily and everything seems to be happy) > > Wish I had more info - but this was at work so I just got it working > again with the rpm install. > > Mike > > Ivan Ivanov wrote: > | Are there any chances for solving this problem. > | > | I have read all the faq and the XFS white paper. > | I have tried allmost all XFS patches from oss.sgi.com for various kernels > | and know that XFS logs only metadata updates. > | It is fast, has EA and ACL but when the system crashes for any reason most > | of the open files ( including opened ro ) are lost - for example > | XF86Config. > | > | Regards > | Ivan > | From owner-linux-xfs@oss.sgi.com Thu Mar 28 16:18:14 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2T0IEf26824 for linux-xfs-outgoing; Thu, 28 Mar 2002 16:18:14 -0800 Received: from tigger.cc-concepts.com (64-40-83-10.mb.dsl.mebtel.net [64.40.83.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2T0I4q26795 for ; Thu, 28 Mar 2002 16:18:04 -0800 Received: from thebaptistes.net (gwy3.cc-concepts.com [64.40.83.12]) (authenticated) by tigger.cc-concepts.com (8.11.6/8.11.6) with ESMTP id g2T0KHw22589; Thu, 28 Mar 2002 19:20:17 -0500 Message-ID: <3CA3B341.9060208@thebaptistes.net> Date: Thu, 28 Mar 2002 19:20:17 -0500 From: Mike Baptiste User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Matter CC: Ivan Ivanov , linux-xfs@oss.sgi.com Subject: Re: file coruption on power fail References: <3CA3A9C8.9060705@thebaptistes.net> <3CA3B089.EEA70773@ch.sauter-bc.com> X-Enigmail-Version: 0.39.2.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well I thought about that - however, the updates were NOT XFree updates - only gnome core. So those files should not have been touched (OK maybe read - but thats it) And the files weren't zero'ed - they were gone. Also, I had the same problem on my desktop at home which runs ext3. Same config as my laptop (RH 7.2, 2.4.18, etc) but ext3 instead of xfs. ~ When gnome froze during the update (not X, it was Gnome - the mouse would still respond) I powered down and when I turned it back on, the file system repaired and X worked just fine. Not conclusive by any stretch, but my desktop and laptop are very similar - just one uses ext3 (the desktop) while the laptop uses xfs. FWIW. Mike Simon Matter wrote: | Mike Baptiste schrieb: | |>FWIW - I had the exact same problem. I'm running 2.4.18-xfs, compiled |>with gcc3.0.4 on RH 7.2 I was running red-carpet to update gnome and it |>updated a LOT of core gnome packages. Well, X froze solid (except for |>the mouse) ctrl-alt-backspace did nothing (2nd system this happened to |>me). Finally after waiting a good long while, I powered down. | | | Are you sure it was not the gnome update which corrupted your libraries? | That could explain why xfs_repair found nothing wrong. I'm quite sure | this time it was not XFS. Too bad you didn't check the failed libs and | look whether they contain "the zero's". | | Anyway, zero filled files after unclean shutdown is one of the weak | points of XFS. As Steve mentioned, it was adressed with recent changes | and I expect it has and will improve much. | | If you have a stable kernel and a good power supply with UPS, the risk | of loosing anything on a XFS filesystem is _very_ low. On unstable | kernels and power supplies, there is always a chance to loose some | bit's. | | -Simon | | |>When I restarted, I got a bunch of error msgs due to missing libraries |>(X and kerberos) X refused to start. |> |>I did an xfs_repair - no help. Since I was on XFree 4.1.0, I grabbed |>the 4.2.0 rpms and installed those from the command line along with the |>kerberos RPMs using the --force option. |> |>After that, everything worked fine. Nothing else got corrupted - only |>the X libraries (well that I've found so far - but I use this system |>heavily and everything seems to be happy) |> |>Wish I had more info - but this was at work so I just got it working |>again with the rpm install. |> |>Mike |> |>Ivan Ivanov wrote: |>| Are there any chances for solving this problem. |>| |>| I have read all the faq and the XFS white paper. |>| I have tried allmost all XFS patches from oss.sgi.com for various kernels |>| and know that XFS logs only metadata updates. |>| It is fast, has EA and ACL but when the system crashes for any reason most |>| of the open files ( including opened ro ) are lost - for example |>| XF86Config. |>| |>| Regards |>| Ivan |>| | | From owner-linux-xfs@oss.sgi.com Thu Mar 28 19:06:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2T361f29517 for linux-xfs-outgoing; Thu, 28 Mar 2002 19:06:01 -0800 Received: from monkeyiq.dnsalias.org (CPE-203-45-214-225.qld.bigpond.net.au [203.45.214.225]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2T35sq29491 for ; Thu, 28 Mar 2002 19:05:55 -0800 Received: by monkeyiq.dnsalias.org id g2T3Aw813602 ; Fri, 29 Mar 2002 13:10:58 +1000 Date: Fri, 29 Mar 2002 13:10:58 +1000 Message-Id: <200203290310.g2T3Aw813602@monkeyiq.dnsalias.org> Subject: Re: [Acl-Devel] attr_list(3) on XFS, headers and such From: Ben Martin To: Andreas Gruenbacher Cc: acl list , xfs list Content-Type: text/plain Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-03-29 at 02:48, Andreas Gruenbacher wrote: > On Fri, 29 Mar 2002, Ben Martin wrote: > > > I noticed that in the recent rpms for attr-devel there is a man > > page for attr_list again, though there doesn't seem to be a declaration > > in the headers for this function and nothing in the sources defining it. > > > > Should this function exist in a 2.4.18+ environment? > > Looking at the version history, it seems attr_list has again been added to > the CVS repository after having been deleted: cvsweb.cgi/linux-2.4-xfs/cmd/attr/man/man3/attr_list.3>. > > I am sure the XFS developers will respond in a few hours, when their > working day starts. > > Anyway, this function was there for backwards compatibility with Irix; I > don't know the details about why it was removed. On Linux you should use > the listxattr system call (see ). ok, I have converted to the xattr(2) functions instead of the attr_list, attr_get(), attr_set(). The only real difference still existing is that previously I had been getting the "user.whatever" EA and presenting them as "whatever" which was very handy for caching stuff like MD5 and width/height of image files (both of which ferris can generate for you if there is no existing EA). But that shouldn't be too hard to add into my code prepending and chopping the user. part. Thanks for the info. > > > Cheers, > Andreas. -- ----------------------------------------------------- http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Fri Mar 29 04:24:45 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TCOjN14887 for linux-xfs-outgoing; Fri, 29 Mar 2002 04:24:45 -0800 Received: from mta05ps.bigpond.com (mta05ps.bigpond.com [144.135.25.137]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TCOTq14861 for ; Fri, 29 Mar 2002 04:24:30 -0800 Message-Id: <200203291224.g2TCOTq14861@oss.sgi.com> Received: from there ([144.135.25.75]) by mta05ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GTQIKL00.5QX; Fri, 29 Mar 2002 22:26:45 +1000 Received: from CPE-144-137-136-216.qld.bigpond.net.au ([144.137.136.216]) by PSMAM03.mailsvc.email.bigpond.com(MailRouter V3.0i 89/4485357); 29 Mar 2002 22:26:45 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Nathan Scott , Bas Subject: DQUOT_SYNC undefined in XFS CVS kernel (was: Can't build CVS kernels of 20020321 & 20020327) Date: Fri, 29 Mar 2002 22:26:41 +1000 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <004a01c1d56b$cae7cb50$3b00a8c0@aplabwp0368359> <20020328083015.G47866@wobbly.melbourne.sgi.com> In-Reply-To: <20020328083015.G47866@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have also run into the XFS CVS kernel compile failing because of an undefined DQUOT_SYNC. Using the information given by Nathan I have tracked down the offending patch that causes the problems. In my case it was the LVM VFS-lock patch from the Sistina LVM project. What they seem to do is use DQUOT_SYNC to force the writing of cached Quota infomation before they lock the VFS during snapshot creation. It would also seem that EVMS does the same thing. I expect that the XFS CVS kernel tree is actually ahead of the standard 2.4.18 kernel tree in this respect so we'll have to wait until 2.4.19 is released with the updated API's before other projects update their kernel patches. Grep'ing through the kernel I have not been able to find any comments or explanations regarding this - so I have assumed that DQUOT_SYNC can be changed to DQUOT_SYNC_DEV without problems. Its times like this that it would be great if there was a one sentence description of what every kernel function does - but alas - for those of us that aren't kernel gods we have to guess - or spend many hours. Sorry - please ignore my rant above. After making that change the kernel compiles cleanly and boots. I'm unsure as yet if I have done the correct thing here. Hopefuly someone will be able to help us out and correct me if I'm incorrect. The offending part of the VF-lock patch follows below: Index: linus.21/fs/buffer.c --- linus.21/fs/buffer.c Mon, 28 Jan 2002 09:51:50 -0500 root (linux/i/45_buffer.c 1.5.2.6 644) +++ linus.21(w)/fs/buffer.c Mon, 28 Jan 2002 11:54:36 -0500 root (linux/i/45_buffer.c 1.5.2.6 644) @@ -361,6 +361,34 @@ fsync_dev(dev); } +int fsync_dev_lockfs(kdev_t dev) +{ + /* you are not allowed to try locking all the filesystems + ** on the system, your chances of getting through without + ** total deadlock are slim to none. + */ + if (!dev) + return fsync_dev(dev) ; + + sync_buffers(dev, 0); + + lock_kernel(); + /* note, the FS might need to start transactions to + ** sync the inodes, or the quota, no locking until + ** after these are done + */ + sync_inodes(dev); + DQUOT_SYNC(dev); ^<==== ****All I did was to change this to DQUOT_SYNC_DEV(dev);**** + /* if inodes or quotas could be dirtied during the + ** sync_supers_lockfs call, the FS is responsible for getting + ** them on disk, without deadlocking against the lock + */ + sync_supers_lockfs(dev) ; + unlock_kernel(); + + return sync_buffers(dev, 1) ; +} + asmlinkage long sys_sync(void) { fsync_dev(0); On Thu, 28 Mar 2002 07:30, Nathan Scott wrote: > Hello, > > On Wed, Mar 27, 2002 at 09:45:48AM +0100, Bas wrote: > > Hi, > > > > It's not possible for me to build the kernel mentioned above. I saw the > > new qouta options and suspect it has something to do with it, but I'm not > > sure. > > > > Building everything goes fine, but at the end of the run it's not able to > > produce a kernel because of DQUOT_SYNC. I don't have the exact error > > here. > > Hmm... 20020327 - that's yesterday. DQUOT_SYNC doesn't appear in > the source at all anymore (for awhile now), so I suspect the problem > must be at your end. Try getting a fresh CVS copy and/or "make clean". > [ The other patches you mentioned should not have anything to do with > this problem. ] > > $ find . -type f | xargs fgrep DQUOT_SYNC > ./fs/buffer.c: DQUOT_SYNC_SB(sb); > ./fs/buffer.c: DQUOT_SYNC_DEV(dev); > ./include/linux/quotaops.h:#define DQUOT_SYNC_DEV(dev) > sync_dquots_dev(dev, -1) ./include/linux/quotaops.h:#define > DQUOT_SYNC_SB(sb) sync_dquots_sb(sb, -1) > ./include/linux/quotaops.h:#define DQUOT_SYNC_DEV(dev) do > { } while(0) ./include/linux/quotaops.h:#define DQUOT_SYNC_SB(sb) > do { } while(0) $ > > FWIW, DQUOT_SYNC used to come from include/linux/quotaops.h > too, and its definition was also dependent on CONFIG_QUOTA. > The reason you'd be getting an unresolved symbol would be a > file referencing DQUOT_SYNC wasn't #include'ing quotaops.h; > but thats all by-the-by - the real problem is related to the > source you're using I suspect - it certainly doesn't match > CVS of yesterday. > > cheers. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Fri Mar 29 07:07:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TF7eX17618 for linux-xfs-outgoing; Fri, 29 Mar 2002 07:07:40 -0800 Received: from gwyn.tux.org (ident-user@gwyn.tux.org [207.96.122.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TF7Yq17582 for ; Fri, 29 Mar 2002 07:07:34 -0800 Received: (from timball@localhost) by gwyn.tux.org (8.9.3/8.9.1) id KAA19044 for linux-xfs@oss.sgi.com; Fri, 29 Mar 2002 10:09:56 -0500 Date: Fri, 29 Mar 2002 10:09:56 -0500 From: Timothy Ball To: XFS Mailing List Subject: xfs + sgi kernel profiler? Message-ID: <20020329150956.GA14089@gwyn.tux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.0i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This isn't directly related but I need an updated copy of the kernel profiler sgi makes that will work w/ xfs. I've tried just blindly patching their 2.4.17 patch to the current cvs to rather mixed results. TIA, --timball -- GPG key available on pgpkeys.mit.edu pub 1024D/511FBD54 2001-07-23 Timothy Lu Hu Ball Key fingerprint = B579 29B0 F6C8 C7AA 3840 E053 FE02 BB97 511F BD54 From owner-linux-xfs@oss.sgi.com Fri Mar 29 08:03:11 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TG3Bh18560 for linux-xfs-outgoing; Fri, 29 Mar 2002 08:03: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 g2TG36q18533 for ; Fri, 29 Mar 2002 08:03:06 -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 g2THE9kw017932 for ; Fri, 29 Mar 2002 11:14:09 -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 KAA01662; Fri, 29 Mar 2002 10:05:23 -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 KAA73977; Fri, 29 Mar 2002 10:05:23 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2TG1bY05409; Fri, 29 Mar 2002 10:01:37 -0600 Subject: Re: xfs + sgi kernel profiler? From: Steve Lord To: Timothy Ball Cc: XFS Mailing List In-Reply-To: <20020329150956.GA14089@gwyn.tux.org> References: <20020329150956.GA14089@gwyn.tux.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 29 Mar 2002 10:01:37 -0600 Message-Id: <1017417697.967.308.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-03-29 at 09:09, Timothy Ball wrote: > This isn't directly related but I need an updated copy of the kernel > profiler sgi makes that will work w/ xfs. I've tried just blindly > patching their 2.4.17 patch to the current cvs to rather mixed results. Its ugly, but doable. First get the kdb patch, and remove it from the xfs kernel. The try the profiling patch. It goes in fairly cleanly but you need to fix a few things up. Steve > > TIA, > --timball > > -- > GPG key available on pgpkeys.mit.edu > pub 1024D/511FBD54 2001-07-23 Timothy Lu Hu Ball > Key fingerprint = B579 29B0 F6C8 C7AA 3840 E053 FE02 BB97 511F BD54 -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Mar 29 08:27:27 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TGRRw19025 for linux-xfs-outgoing; Fri, 29 Mar 2002 08:27:27 -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 g2TGRMq18998 for ; Fri, 29 Mar 2002 08:27:22 -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 g2TGTe6G016255 for ; Fri, 29 Mar 2002 08:29:40 -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 KAA01043 for ; Fri, 29 Mar 2002 10:29:40 -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 KAA86672 for ; Fri, 29 Mar 2002 10:29:40 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2TGPs025314; Fri, 29 Mar 2002 10:25:54 -0600 Message-Id: <200203291625.g2TGPs025314@jen.americas.sgi.com> Date: Fri, 29 Mar 2002 10:25:54 -0600 Subject: TAKE - last part of the spinlock irq change To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Missed one crucial part. This is a noop on i386, it is not on plaforms where sizeof(long) != sizeof(int) and the irq mask uses the extra bits. This may all be a moot point if some development code pans out, xfs will have virtually no code in interrupt context if that works. Steve Date: Fri Mar 29 08:20:57 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:115179a linux/include/linux/xfs_support/mutex.h - 1.3 - switch mutex_spinlock to return an unsigned long From owner-linux-xfs@oss.sgi.com Fri Mar 29 10:45:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TIj6121716 for linux-xfs-outgoing; Fri, 29 Mar 2002 10:45:06 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TIj2q21689 for ; Fri, 29 Mar 2002 10:45:02 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA91858 for ; Fri, 29 Mar 2002 13:44:01 -0500 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2TIlOF125952 for ; Fri, 29 Mar 2002 11:47:25 -0700 Subject: XFS and kernel 2.4.18 To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Fri, 29 Mar 2002 12:47:22 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 03/29/2002 11:47:24 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'd like to create a 2.4.18 kernel with XFS 1.0.2 support, but all the migration paths for 1.0.2 that I've seen end with a 2.4.14 kernel. Is there any way to get this to 2.4.18? Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 From owner-linux-xfs@oss.sgi.com Fri Mar 29 10:51:06 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TIp6K21884 for linux-xfs-outgoing; Fri, 29 Mar 2002 10:51:06 -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 g2TIp2q21856 for ; Fri, 29 Mar 2002 10:51:02 -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 g2TJrLBA021922 for ; Fri, 29 Mar 2002 11:53:21 -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 MAA04243; Fri, 29 Mar 2002 12:53: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 MAA58860; Fri, 29 Mar 2002 12:53:20 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2TInXc02585; Fri, 29 Mar 2002 12:49:33 -0600 Subject: Re: XFS and kernel 2.4.18 From: Steve Lord To: James A Goodwin 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: 29 Mar 2002 12:49:33 -0600 Message-Id: <1017427773.931.352.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-03-29 at 12:47, James A Goodwin wrote: > I'd like to create a 2.4.18 kernel with XFS 1.0.2 support, but all the > migration paths for 1.0.2 that I've seen end with a 2.4.14 kernel. Is > there any way to get this to 2.4.18? Money? ;-) You really want the old code base? 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 29 10:57:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TIvGT22115 for linux-xfs-outgoing; Fri, 29 Mar 2002 10:57:16 -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 g2TIvBq22089 for ; Fri, 29 Mar 2002 10:57:11 -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 g2TIxT6G023121 for ; Fri, 29 Mar 2002 10:59:29 -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 MAA04621; Fri, 29 Mar 2002 12:59:29 -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 MAA44792; Fri, 29 Mar 2002 12:59:28 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g2TItfp03156; Fri, 29 Mar 2002 12:55:41 -0600 Subject: Re: XFS and kernel 2.4.18 From: Steve Lord To: James A Goodwin Cc: linux-xfs@oss.sgi.com In-Reply-To: <1017427773.931.352.camel@jen.americas.sgi.com> References: <1017427773.931.352.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 29 Mar 2002 12:55:41 -0600 Message-Id: <1017428141.931.355.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-03-29 at 12:49, Steve Lord wrote: > On Fri, 2002-03-29 at 12:47, James A Goodwin wrote: > > I'd like to create a 2.4.18 kernel with XFS 1.0.2 support, but all the > > migration paths for 1.0.2 that I've seen end with a 2.4.14 kernel. Is > > there any way to get this to 2.4.18? > > Money? ;-) > > You really want the old code base? Actually I think Eric put out beta 1.1 rpms for 2.4.18 as well as 2.4.9, this is xfs code prior to the last set of gyrations in the cvs tree. 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 29 11:03:12 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2TJ3CZ22376 for linux-xfs-outgoing; Fri, 29 Mar 2002 11:03:12 -0800 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2TJ35q22350 for ; Fri, 29 Mar 2002 11:03:05 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA23070 for ; Fri, 29 Mar 2002 14:02:03 -0500 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2TJ5R0210998 for ; Fri, 29 Mar 2002 12:05:27 -0700 Subject: Re: XFS and kernel 2.4.18 To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Fri, 29 Mar 2002 13:05:25 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 03/29/2002 12:05:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We are going to release a product that will have a certain release of XFS as a prerequisite, so we have to support a fixed version. As far as I can tell, 1.0.2 is the latest release, so we're going with it. If that dictates that we have to stay with kernel 2.4.14, so be it. If not, I'd really like to move on up to 2.4.18. So, I guess my real questions are: a) Is 1.0.2 that latest release of XFS? b) What is the latest kernel that I can use with the latest XFS release? c) If it's not kernel 2.4.14, then how to I upgrade? Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 Steve Lord To: James A Goodwin/Houston/IBM@IBMUS cc: linux-xfs@oss.sgi.com 03/29/2002 12:49 Subject: Re: XFS and kernel 2.4.18 PM On Fri, 2002-03-29 at 12:47, James A Goodwin wrote: > I'd like to create a 2.4.18 kernel with XFS 1.0.2 support, but all the > migration paths for 1.0.2 that I've seen end with a 2.4.14 kernel. Is > there any way to get this to 2.4.18? Money? ;-) You really want the old code base? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Sat Mar 30 21:23:40 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2V5Nec22851 for linux-xfs-outgoing; Sat, 30 Mar 2002 21:23:40 -0800 Received: from webcube2.volstate.net (webcube2.volstate.net [66.129.16.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2V5NZv22825 for ; Sat, 30 Mar 2002 21:23:35 -0800 Received: from there ([207.65.81.109]) by webcube2.volstate.net (8.9.3/8.9.3) with SMTP id AAA00056 for ; Sun, 31 Mar 2002 00:22:56 -0500 Message-Id: <200203310522.AAA00056@webcube2.volstate.net> Content-Type: text/plain; charset="iso-8859-15" From: Joe Bacom Reply-To: joebacom@volstate.net To: linux-xfs@oss.sgi.com Subject: xfsdump parameters not working Date: Sat, 30 Mar 2002 23:22:05 -0600 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Folks; I am using the following xfsdump command to dump system backups to 650m files so they will fit on CD. xfsdump does not seem to be creating individual files but rather a single file. xfsdump -d 650 -f usr.xfsdump.3-30-2002 -l 0 -p 30 -L "Usr Dump 3/30/2002" -T /usr Creates a 2.4G file also I set the SGI_XFSDUMP_SKIP_FILE attribute on each of my dump files so that I could backup the partition that the dump files were on and xfsdump did not ignore them at but gave the error: xfsdump: WARNING: could not open regular file ino 99652 mode 0x000081a4: File too large: not dumped any ideas? Joe From owner-linux-xfs@oss.sgi.com Sun Mar 31 01:32:08 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2V9W8K25886 for linux-xfs-outgoing; Sun, 31 Mar 2002 01:32:08 -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 g2V9W2v25860 for ; Sun, 31 Mar 2002 01:32:02 -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 16rbg9-0000Cd-00; Sun, 31 Mar 2002 11:31:13 +0200 Message-ID: <3CA6D7BD.2090102@st-peter.stw.uni-erlangen.de> Date: Sun, 31 Mar 2002 11:32:45 +0200 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/00200203 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Martin K. Petersen" CC: linux-xfs@oss.sgi.com Subject: Re: REPOST : linux-2.5.5-xfs-dj1+ 2.5.5-dj2 (raid0_make_request bug) References: <3C7FC4A5.7050907@st-peter.stw.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16rbg9-0000Cd-00*F1vj3jpfu6s* (Studentenwohnanlage Nuernberg St.-Peter) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Martin K. Petersen wrote: >>raid0_make_request bug: can't convert block across chunks or bigger >>than 16k 23610115 64 >> > >The RAID0 code does not support request splitting and can't handle the >big I/Os XFS throws at it. > >I am currently porting my kiobuf request splitter code to biobufs to >deal with this. > Hi i hope i don't bother you, but i'd like to ask you wether you had some time to work on the kiobuf code and if you managed to put together some experimental patches kind regards, Svetoslav Slavtchev From owner-linux-xfs@oss.sgi.com Sun Mar 31 11:01:30 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2VJ1Uv05622 for linux-xfs-outgoing; Sun, 31 Mar 2002 11:01:30 -0800 Received: from phoenix.infradead.org (imladris.infradead.org [194.205.184.45]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2VJ1Mv05596 for ; Sun, 31 Mar 2002 11:01:23 -0800 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 16rkZC-0004lT-00; Sun, 31 Mar 2002 20:00:38 +0100 Date: Sun, 31 Mar 2002 20:00:38 +0100 From: Christoph Hellwig To: Andrea Arcangeli Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.19pre5aa1 and splitted vm-33 Message-ID: <20020331200038.B18052@infradead.org> Mail-Followup-To: Christoph Hellwig , Andrea Arcangeli , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20020331164815.A1331@dualathlon.random> <20020331191059.A16769@phoenix.infradead.org> <20020331203830.D1331@dualathlon.random> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020331203830.D1331@dualathlon.random>; from andrea@suse.de on Sun, Mar 31, 2002 at 08:38:30PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Mar 31, 2002 at 08:38:30PM +0200, Andrea Arcangeli wrote: > Hmm that's a problem. BTW, is there any valid reason xfs isn't > implementing O_DIRECT via the direct_IO address space operation like the > other filesystems ext2/reiserfs/nfs? (of course I'm talking long term, I > don't pretend to change that in one day, for the short term we should > still allow xfs to use its own internal methods of doing O_DIRECT) For definitve answers you have to ask Steve or some else from the XFS crow, but if you look at the XFS data I/O path is is completly different from the generic Linux filesystems due to the IRIX history/compatiblity and the 'need' for features not present in the core kernel. Before 2.4.10 one of those was O_DIRECT, btw.. > Fixing that should be a one liner setting a_ops->direct_IO to > ERR_PTR(-1L) within xfs. Comments? Looks good to me. > > > For the open case putting the check into generic_file_open sounds good to me, > > One problem with generic_file_open is that we'd need to rely on all > lowlevel open callbacks to do the check properly if they don't support > O_DIRECT and we'd need to duplicate code, only a few fs uses > generic_file_open. Lefting it in the vfs looked cleaner, it reduces the > check to a few liner patch. > > The lowlevel callback can always drop the kiovec during its own ->open > if they don't need it, even if they uses direct_IO, like nfs. I don't think this is a good design decision, but I can live with it for 2.4 - for 2.5 I'm still hoping for bcrls kvec to replace the current kiobuf stuff and we have to see what that means for O_DIRECT. > > kiobufs even if XFS doesn't need them.. > > Chuck's patch is handling fcntl as well, do you see any problem there? > (modulo the fact the kiovec is pre-allocated even if not necessary, like > in open(2)?) It's this same issue, there is no other problem in my eyes. From owner-linux-xfs@oss.sgi.com Sun Mar 31 16:05:39 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g3105dh19244 for linux-xfs-outgoing; Sun, 31 Mar 2002 16:05:39 -0800 Received: from penguin.e-mind.com (penguin.e-mind.com [195.223.140.120]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g3105Rv19218 for ; Sun, 31 Mar 2002 16:05:27 -0800 Received: from black.random ([195.223.140.107]) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id CAA30195; Mon, 1 Apr 2002 02:22:42 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by black.random (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id g3104at02294; Mon, 1 Apr 2002 02:04:36 +0200 Received: (from andrea@localhost) by dualathlon.random (8.11.6/8.11.6/SuSE Linux 0.5) id g3104Hl25494; Mon, 1 Apr 2002 02:04:17 +0200 Date: Mon, 1 Apr 2002 02:04:17 +0200 From: Andrea Arcangeli To: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.19pre5aa1 and splitted vm-33 Message-ID: <20020401020417.K1331@dualathlon.random> References: <20020331164815.A1331@dualathlon.random> <20020331191059.A16769@phoenix.infradead.org> <20020331203830.D1331@dualathlon.random> <20020331200038.B18052@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020331200038.B18052@infradead.org> User-Agent: Mutt/1.3.22.1i X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Mar 31, 2002 at 08:00:38PM +0100, Christoph Hellwig wrote: > On Sun, Mar 31, 2002 at 08:38:30PM +0200, Andrea Arcangeli wrote: > > Hmm that's a problem. BTW, is there any valid reason xfs isn't > > implementing O_DIRECT via the direct_IO address space operation like the > > other filesystems ext2/reiserfs/nfs? (of course I'm talking long term, I > > don't pretend to change that in one day, for the short term we should > > still allow xfs to use its own internal methods of doing O_DIRECT) > > For definitve answers you have to ask Steve or some else from the XFS crow, > but if you look at the XFS data I/O path is is completly different from > the generic Linux filesystems due to the IRIX history/compatiblity and the > 'need' for features not present in the core kernel. Before 2.4.10 one > of those was O_DIRECT, btw.. Yep I understand that, it was more a request for comments on the API, to learn if they've any design limitation with that generic API, I know it would be tricky to convert xfs, not something I'd expect in a minor release, I was talking a bit longer term, not necessairly for 2.4. XFS doesn't journal data so my point was it should be just fine in theory with the current aops direct_IO API. For 2.5 we also need a generic library function that puts anchors into the pagecache hash too, simulating locked pages, to serialize the I/O on the data too during O_DIRECT to allow cleanly O_DIRECT with _data_ journaling. > > Fixing that should be a one liner setting a_ops->direct_IO to > > ERR_PTR(-1L) within xfs. Comments? > > Looks good to me. Ok. > > > For the open case putting the check into generic_file_open sounds good to me, > > > > One problem with generic_file_open is that we'd need to rely on all > > lowlevel open callbacks to do the check properly if they don't support > > O_DIRECT and we'd need to duplicate code, only a few fs uses > > generic_file_open. Lefting it in the vfs looked cleaner, it reduces the > > check to a few liner patch. > > > > The lowlevel callback can always drop the kiovec during its own ->open > > if they don't need it, even if they uses direct_IO, like nfs. > > I don't think this is a good design decision, but I can live with it for > 2.4 - for 2.5 I'm still hoping for bcrls kvec to replace the current kiobuf > stuff and we have to see what that means for O_DIRECT. Avoiding code duplication and taking the API simpler is the good part, but I see nfs would be penalized (first it allocates and the deallocates). I agree it's not the best design to get the maximal performance with nfs and some other, it was mostly a 2.4 thing infact, as you say with 2.5 if the kiobuf overhead is dropped then we may not need to preallocate the kiobuf in the first place, then this whole discussion about "where to preallocate" will be pointless. Also the kiobuf-slab patch should just make it significantly faster compared to the current prohibitive vmalloc. > > > kiobufs even if XFS doesn't need them.. > > > > Chuck's patch is handling fcntl as well, do you see any problem there? > > (modulo the fact the kiovec is pre-allocated even if not necessary, like > > in open(2)?) > > It's this same issue, there is no other problem in my eyes. Ok. Thanks, Andrea