From owner-linux-xfs@oss.sgi.com Mon Dec 1 01:41:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 01:41:56 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB19fXTa022945 for ; Mon, 1 Dec 2003 01:41:34 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hB19fOhl016460; Mon, 1 Dec 2003 10:41:24 +0100 Message-ID: <3FCB0D6A.3030503@stesmi.com> Date: Mon, 01 Dec 2003 10:44:10 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jens Axboe CC: Nathan Scott , Marcelo Tosatti , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 References: <20031201062052.GA2022@frodo> <20031201092446.GK6454@suse.de> In-Reply-To: <20031201092446.GK6454@suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1163 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Jens Axboe wrote: > On Mon, Dec 01 2003, Nathan Scott wrote: > >>Hi Marcelo, >> >>Please do a >> >> bk pull http://xfs.org:8090/linux-2.4+coreXFS >> >>This will merge the core 2.4 kernel changes required for supporting >>the XFS filesystem, as listed below. If this all looks acceptable, >>then please also pull the filesystem-specific code (fs/xfs/*) >> >> bk pull http://xfs.org:8090/linux-2.4+justXFS > > > Where can these be found as a unified diff? It's quite bothersome to > have to pull a changeset just to review it (cloning a kernel tree > first), not to mention space intensive. > There was a mail announcing split-patches for 2.4.23 five hours before this mail. The mail was from Keith Owens but here's the link from it: ftp://oss.sgi.com/projects/xfs/patches/2.4.23 for the 2.4.23 patches. // Stefan From owner-linux-xfs@oss.sgi.com Mon Dec 1 08:16:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 08:17:10 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1GGkTa021383 for ; Mon, 1 Dec 2003 08:16:46 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB1GbgHc013649 for ; Mon, 1 Dec 2003 10:37:42 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB1GFbP516011174; Mon, 1 Dec 2003 10:15:37 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB1GFLK18409356; Mon, 1 Dec 2003 10:15:31 -0600 (CST) Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out From: Eric Sandeen To: Soumen Chakrabarti Cc: linux-xfs@oss.sgi.com In-Reply-To: <3FC6E5C4.2080009@cse.iitb.ac.in> References: <3FC6E5C4.2080009@cse.iitb.ac.in> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1070295327.28534.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 01 Dec 2003 10:15:27 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1164 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2003-11-28 at 00:05, Soumen Chakrabarti wrote: > Eric Sandeen wrote: > > On Sun, 26 Oct 2003, Soumen Chakrabarti wrote: > >>Repeatable bug, here's how to create the situation: > >>1. Start with a fresh install of stock RedHat 9. > >>2. Download kernel 2.4.22. > >>3. Patch in XFS 1.3.1 and build new kernel. > > > > Ok, for starters, i don't think we shipped patches specifically > > for xfs 1.3.1 + kernel 2.4.22, and the patches we did ship for 2.4.21 > > do not apply cleanly to 2.4.22. > > I downloaded the patch around 10/15, from this URL: > ftp://oss.sgi.com/projects/xfs/patches/2.4.22 > which seems to indicate that even on that date, there was a patch > available for 2.4.22 (maybe I looked where I should not). Today > (11/28), I can't even find a patch for 2.4.21 (at least not by moving up > to the parent dir ...patches/). Ah, ok. That is a snapshot patch, as indicated by the README - it's not XFS 1.3.1. That's fine, at least now I know what you're running. > Some other people seem to have confirmed in the meantime that the > problem shown by bonnie on 2.4.22 + 1.3.1 is a real one. I think it's also been shown that using the "ikeep" mount option will take care of this? Looks like it has something to do with the unused inode reclamation path. http://oss.sgi.com/bugzilla/show_bug.cgi?id=284 Can you verify that this workaround fixes the problem for you? -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Dec 1 08:28:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 08:29:02 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1GSnTa024681 for ; Mon, 1 Dec 2003 08:28:50 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB1GnjHc018750 for ; Mon, 1 Dec 2003 10:49:45 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB1GQLP516002790; Mon, 1 Dec 2003 10:26:21 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB1GQCK18512885; Mon, 1 Dec 2003 10:26:15 -0600 (CST) Subject: Re: xlog_clear_stale_blocks crashes in line 1242 (suse 9) From: Eric Sandeen To: Klaus Ridder Cc: linux-xfs@oss.sgi.com In-Reply-To: <3FC9C8C0.6060002@kridder.de> References: <3FC9C8C0.6060002@kridder.de> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1070295978.28534.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 01 Dec 2003 10:26:18 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1165 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Sun, 2003-11-30 at 04:38, Klaus Ridder wrote: > I am not on the XFS list (and wil not subscribe), so it would be kind of > you to send me a cc when you figured out the problem or need further > information. Detailed steps on how to reproduce this problem would be most helpful; I'm not certain what steps you took leading up to your problem. Filing this information in a Bugzilla bug would also be very helpful, if possible. http://oss.sgi.com/bugzilla/ Thanks, -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Dec 1 08:34:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 08:34:27 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1GYETa025102 for ; Mon, 1 Dec 2003 08:34:15 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB1GtAHc020986 for ; Mon, 1 Dec 2003 10:55:10 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB1GWZP515666389; Mon, 1 Dec 2003 10:32:36 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB1GWOK18498249; Mon, 1 Dec 2003 10:32:29 -0600 (CST) Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out From: Eric Sandeen To: Jan Derfinak Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: References: <3FC6E5C4.2080009@cse.iitb.ac.in> <20031129085715.A1872948@wobbly.melbourne.sgi.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1070296349.28534.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 01 Dec 2003 10:32:30 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1166 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Sat, 2003-11-29 at 17:41, Jan Derfinak wrote: > With ikeep bonnie worked without error. Interesting is that before test df > showed: > /dev/loop0 519488 144 519344 1% /mnt/mnt2 > > After test: > /dev/loop0 519488 131340 388148 26% /mnt/mnt2 > > And there wasn't any file on the disk. Was the space consumed by inode > table? Yep, inodes are dynamically allocated as needed, so you're seeing them take up space. Without ikeep, there was some new code to remove unused inode clusters. (Nathan has since swizzled the mount options a bit, so now keeping the clusters is default, and "noikeep" will test the removal code). Note that the above situation (disk space used for inodes) is really no different than, say, ext3 - except that with ext3, you allocate all those inodes (and use the space) at mkfs time, not runtime. -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Dec 1 08:55:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 08:55:52 -0800 (PST) Received: from alienAngel.upjs.sk (styx.suse.cz [213.210.157.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1GteTa025752 for ; Mon, 1 Dec 2003 08:55:41 -0800 Received: by alienAngel.upjs.sk (Postfix, from userid 500) id 200603D3; Mon, 1 Dec 2003 17:56:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by alienAngel.upjs.sk (Postfix) with ESMTP id 1BCAE18B; Mon, 1 Dec 2003 17:56:49 +0100 (CET) Date: Mon, 1 Dec 2003 17:56:49 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out In-Reply-To: <1070296349.28534.9.camel@stout.americas.sgi.com> Message-ID: References: <3FC6E5C4.2080009@cse.iitb.ac.in> <20031129085715.A1872948@wobbly.melbourne.sgi.com> <1070296349.28534.9.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1167 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs On Mon, 1 Dec 2003, Eric Sandeen wrote: Hi. > > /dev/loop0 519488 144 519344 1% /mnt/mnt2 > > > > After test: > > /dev/loop0 519488 131340 388148 26% /mnt/mnt2 > > > > And there wasn't any file on the disk. Was the space consumed by inode > > table? > > Yep, inodes are dynamically allocated as needed, so you're seeing them > take up space. Without ikeep, there was some new code to remove unused ... > Note that the above situation (disk space used for inodes) is really no > different than, say, ext3 - except that with ext3, you allocate all > those inodes (and use the space) at mkfs time, not runtime. Yes, I know. I was suprised how big is this percentage. But it seems ok for me now. I haven't realized how small was the FS and how big was the number of files created by bonnie. Thanks. jan -- From owner-linux-xfs@oss.sgi.com Mon Dec 1 10:01:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 10:01:33 -0800 (PST) Received: from chris.pebenito.dhs.org (12-251-184-225.client.attbi.com [12.251.184.225]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1I18Ta027174 for ; Mon, 1 Dec 2003 10:01:09 -0800 Received: by chris.pebenito.dhs.org (Postfix, from userid 1000) id F14699CEC7; Mon, 1 Dec 2003 12:01:02 -0600 (CST) Subject: [patch] security. namespace From: Chris PeBenito To: sandeen@sgi.com, linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-G6eBHJjZi8ll8CclpR+J" Message-Id: <1070301662.7842.11.camel@chris.pebenito.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 01 Dec 2003 12:01:02 -0600 X-archive-position: 1168 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pebenito@gentoo.org Precedence: bulk X-list: linux-xfs --=-G6eBHJjZi8ll8CclpR+J Content-Type: multipart/mixed; boundary="=-PY1EG+CSqMVxaoOqOCPR" --=-PY1EG+CSqMVxaoOqOCPR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Here is a patch against -test10 that adds an option for the security. namespace (controlled by a configure option), which is used by SELinux to store it's security labels. I created this patch based off Tad Glines' (tadglines@comcast.net) 2.4 patch (http://www.glines.com/xfs.patch.bz2). Please critique this, and if its ok, please consider for inclusion. I was warned on #xfs that this may break IRIX compatability, so there is a note in the Kconfig. However Tad says that the security. attributes will show up in the user namespace on a standard XFS linux kernel, but I didn't verify. He also mentioned that xfsdump and xfsrestore would need to be patched to support this. --=20 Chris PeBenito Developer, Hardened Gentoo Linux Embedded Gentoo Linux =20 Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xE6AF9243 Key fingerprint =3D B0E6 877A 883F A57A 8E6A CB00 BC8E E42D E6AF 9243 --=-PY1EG+CSqMVxaoOqOCPR Content-Disposition: attachment; filename=xfs-security-namespace-2.6.0-test10.diff Content-Type: text/x-patch; name=xfs-security-namespace-2.6.0-test10.diff; charset=ISO-8859-1 Content-Transfer-Encoding: base64 VGhpcyBpcyBiYXNlZCBvbiBUYWQgPHRhZGdsaW5lc0Bjb21jYXN0Lm5ldD4g J3Mgc2VjdXJpdHkuIGhhbmRsZXIgZm9yIDIuNA0KDQpkaWZmIC11ck4gbGlu dXgtMi42LjAtdGVzdDEwLm9yaWcvZnMvS2NvbmZpZyBsaW51eC0yLjYuMC10 ZXN0MTAvZnMvS2NvbmZpZw0KLS0tIGxpbnV4LTIuNi4wLXRlc3QxMC5vcmln L2ZzL0tjb25maWcJMjAwMy0xMS0yMyAxOTozMjowNS4wMDAwMDAwMDAgLTA2 MDANCisrKyBsaW51eC0yLjYuMC10ZXN0MTAvZnMvS2NvbmZpZwkyMDAzLTEx LTI2IDA5OjM4OjQ2LjAwMDAwMDAwMCAtMDYwMA0KQEAgLTM1NSw2ICszNTUs MjAgQEANCiANCiAJICBJZiB5b3UgZG9uJ3Qga25vdyB3aGF0IEFjY2VzcyBD b250cm9sIExpc3RzIGFyZSwgc2F5IE4NCiANCitjb25maWcgWEZTX1hBVFRS X1NFQ1VSSVRZDQorCWJvb2wgIlNlY3VyaXR5IExhYmVscyINCisJZGVwZW5k cyBvbiBYRlNfRlMNCisJaGVscA0KKwkgIFNlY3VyaXR5IGxhYmVscyBzdXBw b3J0IGFsdGVybmF0aXZlIGFjY2VzcyBjb250cm9sIG1vZGVscw0KKwkgIGlt cGxlbWVudGVkIGJ5IHNlY3VyaXR5IG1vZHVsZXMgbGlrZSBTRUxpbnV4LiAg VGhpcyBvcHRpb24NCisJICBlbmFibGVzIGFuIGV4dGVuZGVkIGF0dHJpYnV0 ZSBoYW5kbGVyIGZvciBmaWxlIHNlY3VyaXR5DQorCSAgbGFiZWxzIGluIHRo ZSBYRlMgZmlsZXN5c3RlbS4NCisNCisJICBOb3RlOiBFbmFibGluZyB0aGlz IG9wdGlvbiB3aWxsIGJyZWFrIElSSVggY29tcGF0YWJpbGl0eS4NCisNCisJ ICBJZiB5b3UgYXJlIG5vdCB1c2luZyBhIHNlY3VyaXR5IG1vZHVsZSB0aGF0 IHJlcXVpcmVzIHVzaW5nDQorCSAgZXh0ZW5kZWQgYXR0cmlidXRlcyBmb3Ig ZmlsZSBzZWN1cml0eSBsYWJlbHMsIHNheSBOLg0KKw0KIGNvbmZpZyBNSU5J WF9GUw0KIAl0cmlzdGF0ZSAiTWluaXggZnMgc3VwcG9ydCINCiAJaGVscA0K ZGlmZiAtdXJOIGxpbnV4LTIuNi4wLXRlc3QxMC5vcmlnL2ZzL3hmcy9saW51 eC94ZnNfaW9wcy5jIGxpbnV4LTIuNi4wLXRlc3QxMC9mcy94ZnMvbGludXgv eGZzX2lvcHMuYw0KLS0tIGxpbnV4LTIuNi4wLXRlc3QxMC5vcmlnL2ZzL3hm cy9saW51eC94ZnNfaW9wcy5jCTIwMDMtMTEtMjMgMTk6MzE6MzguMDAwMDAw MDAwIC0wNjAwDQorKysgbGludXgtMi42LjAtdGVzdDEwL2ZzL3hmcy9saW51 eC94ZnNfaW9wcy5jCTIwMDMtMTEtMjYgMDA6NDc6MjUuMDAwMDAwMDAwIC0w NjAwDQpAQCAtNTYxLDEwICs1NjEsMTYgQEANCiAjZGVmaW5lIFNZU1RFTV9O QU1FCSJzeXN0ZW0uIgkvKiBWRlMgc2hhcmVkIG5hbWVzL3ZhbHVlcyAqLw0K ICNkZWZpbmUgUk9PVF9OQU1FCSJ0cnVzdGVkLiIJLyogcm9vdCdzIG93biBu YW1lcy92YWx1ZXMgKi8NCiAjZGVmaW5lIFVTRVJfTkFNRQkidXNlci4iCQkv KiB1c2VyJ3Mgb3duIG5hbWVzL3ZhbHVlcyAqLw0KKyNpZmRlZiBDT05GSUdf WEZTX1hBVFRSX1NFQ1VSSVRZDQorI2RlZmluZSBTRUNVUklUWV9OQU1FCSJz ZWN1cml0eS4iCS8qIHNlY3VyaXR5IG5hbWVzcGFjZSAqLw0KKyNlbmRpZg0K IFNUQVRJQyB4YXR0cl9uYW1lc3BhY2VfdCB4ZnNfbmFtZXNwYWNlX2FycmF5 W10gPSB7DQogCXsgLm5hbWU9IFNZU1RFTV9OQU1FLAkubmFtZWxlbj0gc2l6 ZW9mKFNZU1RFTV9OQU1FKS0xLC5leGlzdHM9IE5VTEwgfSwNCiAJeyAubmFt ZT0gUk9PVF9OQU1FLAkubmFtZWxlbj0gc2l6ZW9mKFJPT1RfTkFNRSktMSwJ LmV4aXN0cz0gTlVMTCB9LA0KIAl7IC5uYW1lPSBVU0VSX05BTUUsCS5uYW1l bGVuPSBzaXplb2YoVVNFUl9OQU1FKS0xLAkuZXhpc3RzPSBOVUxMIH0sDQor I2lmZGVmIENPTkZJR19YRlNfWEFUVFJfU0VDVVJJVFkNCisJeyAubmFtZT0g U0VDVVJJVFlfTkFNRSwJLm5hbWVsZW49IHNpemVvZihTRUNVUklUWV9OQU1F KS0xLCAuZXhpc3RzPSBOVUxMIH0sDQorI2VuZGlmDQogCXsgLm5hbWU9IE5V TEwgfQ0KIH07DQogeGF0dHJfbmFtZXNwYWNlX3QgKnhmc19uYW1lc3BhY2Vz ID0gJnhmc19uYW1lc3BhY2VfYXJyYXlbMF07DQpAQCAtNjY3LDYgKzY3Mywx NSBAQA0KIAkJVk9QX0FUVFJfU0VUKHZwLCBwLCAodm9pZCAqKSBkYXRhLCBz aXplLCB4ZmxhZ3MsIE5VTEwsIGVycm9yKTsNCiAJCXJldHVybiAtZXJyb3I7 DQogCX0NCisjaWZkZWYgQ09ORklHX1hGU19YQVRUUl9TRUNVUklUWQ0KKwlp ZiAoc3RybmNtcChuYW1lLCB4ZnNfbmFtZXNwYWNlc1tTRUNVUklUWV9OQU1F U10ubmFtZSwNCisJCQl4ZnNfbmFtZXNwYWNlc1tTRUNVUklUWV9OQU1FU10u bmFtZWxlbikgPT0gMCkgew0KKwkJeGZsYWdzIHw9IEFUVFJfU0VDVVJJVFk7 DQorCQlwICs9IHhmc19uYW1lc3BhY2VzW1NFQ1VSSVRZX05BTUVTXS5uYW1l bGVuOw0KKwkJVk9QX0FUVFJfU0VUKHZwLCBwLCAodm9pZCAqKSBkYXRhLCBz aXplLCB4ZmxhZ3MsIE5VTEwsIGVycm9yKTsNCisJCXJldHVybiAtZXJyb3I7 DQorCX0NCisjZW5kaWYNCiAJcmV0dXJuIC1FT1BOT1RTVVBQOw0KIH0NCiAN CkBAIC03MjMsNiArNzM4LDE3IEBADQogCQkJZXJyb3IgPSAtc2l6ZTsNCiAJ CXJldHVybiAtZXJyb3I7DQogCX0NCisjaWZkZWYgQ09ORklHX1hGU19YQVRU Ul9TRUNVUklUWQ0KKwlpZiAoc3RybmNtcChuYW1lLCB4ZnNfbmFtZXNwYWNl c1tTRUNVUklUWV9OQU1FU10ubmFtZSwNCisJCQl4ZnNfbmFtZXNwYWNlc1tT RUNVUklUWV9OQU1FU10ubmFtZWxlbikgPT0gMCkgew0KKwkJeGZsYWdzIHw9 IEFUVFJfU0VDVVJJVFk7DQorCQlwICs9IHhmc19uYW1lc3BhY2VzW1NFQ1VS SVRZX05BTUVTXS5uYW1lbGVuOw0KKwkJVk9QX0FUVFJfR0VUKHZwLCBwLCBk YXRhLCAoaW50ICopJnNpemUsIHhmbGFncywgTlVMTCwgZXJyb3IpOw0KKwkJ aWYgKCFlcnJvcikNCisJCQllcnJvciA9IC1zaXplOw0KKwkJcmV0dXJuIC1l cnJvcjsNCisJfQ0KKyNlbmRpZg0KIAlyZXR1cm4gLUVPUE5PVFNVUFA7DQog fQ0KIA0KQEAgLTgxMyw2ICs4MzksMTUgQEANCiAJCVZPUF9BVFRSX1JFTU9W RSh2cCwgcCwgeGZsYWdzLCBOVUxMLCBlcnJvcik7DQogCQlyZXR1cm4gLWVy cm9yOw0KIAl9DQorI2lmZGVmIENPTkZJR19YRlNfWEFUVFJfU0VDVVJJVFkN CisJaWYgKHN0cm5jbXAobmFtZSwgeGZzX25hbWVzcGFjZXNbU0VDVVJJVFlf TkFNRVNdLm5hbWUsDQorCQkJeGZzX25hbWVzcGFjZXNbU0VDVVJJVFlfTkFN RVNdLm5hbWVsZW4pID09IDApIHsNCisJCXhmbGFncyB8PSBBVFRSX1NFQ1VS SVRZOw0KKwkJcCArPSB4ZnNfbmFtZXNwYWNlc1tTRUNVUklUWV9OQU1FU10u bmFtZWxlbjsNCisJCVZPUF9BVFRSX1JFTU9WRSh2cCwgcCwgeGZsYWdzLCBO VUxMLCBlcnJvcik7DQorCQlyZXR1cm4gLWVycm9yOw0KKwl9DQorI2VuZGlm DQogCXJldHVybiAtRU9QTk9UU1VQUDsNCiB9DQogDQpkaWZmIC11ck4gbGlu dXgtMi42LjAtdGVzdDEwLm9yaWcvZnMveGZzL2xpbnV4L3hmc19pb3BzLmgg bGludXgtMi42LjAtdGVzdDEwL2ZzL3hmcy9saW51eC94ZnNfaW9wcy5oDQot LS0gbGludXgtMi42LjAtdGVzdDEwLm9yaWcvZnMveGZzL2xpbnV4L3hmc19p b3BzLmgJMjAwMy0xMS0yMyAxOTozMjowMy4wMDAwMDAwMDAgLTA2MDANCisr KyBsaW51eC0yLjYuMC10ZXN0MTAvZnMveGZzL2xpbnV4L3hmc19pb3BzLmgJ MjAwMy0xMS0yNiAwMDo1MToxOS4wMDAwMDAwMDAgLTA2MDANCkBAIC01Myw2 ICs1Myw5IEBADQogI2RlZmluZSBTWVNURU1fTkFNRVMJMA0KICNkZWZpbmUg Uk9PVF9OQU1FUwkxDQogI2RlZmluZSBVU0VSX05BTUVTCTINCisjaWZkZWYg Q09ORklHX1hGU19YQVRUUl9TRUNVUklUWQ0KKyNkZWZpbmUgU0VDVVJJVFlf TkFNRVMJMw0KKyNlbmRpZg0KIGV4dGVybiBzdHJ1Y3QgeGF0dHJfbmFtZXNw YWNlICp4ZnNfbmFtZXNwYWNlczsNCiANCiANCmRpZmYgLXVyTiBsaW51eC0y LjYuMC10ZXN0MTAub3JpZy9mcy94ZnMveGZzX2F0dHIuYyBsaW51eC0yLjYu MC10ZXN0MTAvZnMveGZzL3hmc19hdHRyLmMNCi0tLSBsaW51eC0yLjYuMC10 ZXN0MTAub3JpZy9mcy94ZnMveGZzX2F0dHIuYwkyMDAzLTExLTIzIDE5OjMy OjA3LjAwMDAwMDAwMCAtMDYwMA0KKysrIGxpbnV4LTIuNi4wLXRlc3QxMC9m cy94ZnMveGZzX2F0dHIuYwkyMDAzLTExLTI2IDAwOjU2OjQ0LjAwMDAwMDAw MCAtMDYwMA0KQEAgLTIyMSw3ICsyMjEsMTEgQEANCiAJaW50CQlsb2NhbCwg c2l6ZTsNCiAJdWludAkJbmJsa3M7DQogCXhmc19tb3VudF90CSptcDsNCisj aWZkZWYgQ09ORklHX1hGU19YQVRUUl9TRUNVUklUWQ0KKwlpbnQgICAgICAg ICAgICAgcnN2ZCA9IChmbGFncyAmIChBVFRSX1JPT1R8QVRUUl9TRUNVUklU WSkpICE9IDA7DQorI2Vsc2UNCiAJaW50ICAgICAgICAgICAgIHJzdmQgPSAo ZmxhZ3MgJiBBVFRSX1JPT1QpICE9IDA7DQorI2VuZGlmDQogCWludCAgICAg ICAgICAgICBuYW1lbGVuOw0KIA0KIAlBU1NFUlQoTUFYTkFNRUxFTi0xIDw9 IDB4ZmYpOyAvKiBsZW5ndGggaXMgc3RvcmVkIGluIHVpbnQ4ICovDQpAQCAt NTQ1LDggKzU0OSwxMSBAQA0KIAkgKiBSb290IGZvcmsgYXR0cmlidXRlcyBj YW4gdXNlIHJlc2VydmVkIGRhdGEgYmxvY2tzIGZvciB0aGlzDQogCSAqIG9w ZXJhdGlvbiBpZiBuZWNlc3NhcnkNCiAJICovDQotDQorI2lmZGVmIENPTkZJ R19YRlNfWEFUVFJfU0VDVVJJVFkNCisJaWYgKGZsYWdzICYgKEFUVFJfUk9P VHxBVFRSX1NFQ1VSSVRZKSkNCisjZWxzZQ0KIAlpZiAoZmxhZ3MgJiBBVFRS X1JPT1QpDQorI2VuZGlmDQogCQlhcmdzLnRyYW5zLT50X2ZsYWdzIHw9IFhG U19UUkFOU19SRVNFUlZFOw0KIA0KIAlpZiAoKGVycm9yID0geGZzX3RyYW5z X3Jlc2VydmUoYXJncy50cmFucywNCmRpZmYgLXVyTiBsaW51eC0yLjYuMC10 ZXN0MTAub3JpZy9mcy94ZnMveGZzX2F0dHIuaCBsaW51eC0yLjYuMC10ZXN0 MTAvZnMveGZzL3hmc19hdHRyLmgNCi0tLSBsaW51eC0yLjYuMC10ZXN0MTAu b3JpZy9mcy94ZnMveGZzX2F0dHIuaAkyMDAzLTExLTIzIDE5OjMxOjE2LjAw MDAwMDAwMCAtMDYwMA0KKysrIGxpbnV4LTIuNi4wLXRlc3QxMC9mcy94ZnMv eGZzX2F0dHIuaAkyMDAzLTExLTI2IDAwOjU4OjA1LjAwMDAwMDAwMCAtMDYw MA0KQEAgLTU5LDYgKzU5LDkgQEANCiAgKj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PSovDQogDQogI2RlZmluZSBBVFRSX1JPT1QJMHgwMDAyCS8qIHVz ZSBhdHRycyBpbiByb290IG5hbWVzcGFjZSwgbm90IHVzZXIgKi8NCisjaWZk ZWYgQ09ORklHX1hGU19YQVRUUl9TRUNVUklUWQ0KKyNkZWZpbmUgQVRUUl9T RUNVUklUWQkweDAwMDQJLyogdXNlIGF0dHJzIGluIHNlY3VyaXR5IG5hbWVz cGFjZSwgbm90IHJvb3QvdXNlciAqLw0KKyNlbmRpZg0KICNkZWZpbmUgQVRU Ul9DUkVBVEUJMHgwMDEwCS8qIHB1cmUgY3JlYXRlOiBmYWlsIGlmIGF0dHIg YWxyZWFkeSBleGlzdHMgKi8NCiAjZGVmaW5lIEFUVFJfUkVQTEFDRQkweDAw MjAJLyogcHVyZSBzZXQ6IGZhaWwgaWYgYXR0ciBkb2VzIG5vdCBleGlzdCAq Lw0KICNkZWZpbmUgQVRUUl9LRVJOT1RJTUUJMHgxMDAwCS8qIFtrZXJuZWxd IGRvbid0IHVwZGF0ZSBpbm9kZSB0aW1lc3RhbXBzICovDQpkaWZmIC11ck4g bGludXgtMi42LjAtdGVzdDEwLm9yaWcvZnMveGZzL3hmc19hdHRyX2xlYWYu YyBsaW51eC0yLjYuMC10ZXN0MTAvZnMveGZzL3hmc19hdHRyX2xlYWYuYw0K LS0tIGxpbnV4LTIuNi4wLXRlc3QxMC5vcmlnL2ZzL3hmcy94ZnNfYXR0cl9s ZWFmLmMJMjAwMy0xMS0yMyAxOTozMTo1NC4wMDAwMDAwMDAgLTA2MDANCisr KyBsaW51eC0yLjYuMC10ZXN0MTAvZnMveGZzL3hmc19hdHRyX2xlYWYuYwky MDAzLTExLTI2IDA5OjI2OjM3LjAwMDAwMDAwMCAtMDYwMA0KQEAgLTE1OSw4 ICsxNTksMTUgQEANCiAJCQljb250aW51ZTsNCiAJCWlmIChtZW1jbXAoYXJn cy0+bmFtZSwgc2ZlLT5uYW1ldmFsLCBhcmdzLT5uYW1lbGVuKSAhPSAwKQ0K IAkJCWNvbnRpbnVlOw0KKyNpZmRlZiBDT05GSUdfWEZTX1hBVFRSX1NFQ1VS SVRZDQorCQlpZiAoKChhcmdzLT5mbGFncyAmIEFUVFJfUk9PVCkgIT0gMCkg IT0NCisJCSAgICAoKHNmZS0+ZmxhZ3MgJiBYRlNfQVRUUl9ST09UKSAhPSAw KSB8fA0KKwkJICAgICgoYXJncy0+ZmxhZ3MgJiBBVFRSX1NFQ1VSSVRZKSAh PSAwKSAhPQ0KKwkJICAgICgoc2ZlLT5mbGFncyAmIFhGU19BVFRSX1NFQ1VS SVRZKSAhPSAwKSkNCisjZWxzZQ0KIAkJaWYgKCgoYXJncy0+ZmxhZ3MgJiBB VFRSX1JPT1QpICE9IDApICE9DQogCQkgICAgKChzZmUtPmZsYWdzICYgWEZT X0FUVFJfUk9PVCkgIT0gMCkpDQorI2VuZGlmDQogCQkJY29udGludWU7DQog CQlyZXR1cm4oWEZTX0VSUk9SKEVFWElTVCkpOw0KIAl9DQpAQCAtMTc0LDYg KzE4MSw5IEBADQogCXNmZS0+bmFtZWxlbiA9IGFyZ3MtPm5hbWVsZW47DQog CUlOVF9TRVQoc2ZlLT52YWx1ZWxlbiwgQVJDSF9DT05WRVJULCBhcmdzLT52 YWx1ZWxlbik7DQogCXNmZS0+ZmxhZ3MgPSAoYXJncy0+ZmxhZ3MgJiBBVFRS X1JPT1QpID8gWEZTX0FUVFJfUk9PVCA6IDA7DQorI2lmZGVmIENPTkZJR19Y RlNfWEFUVFJfU0VDVVJJVFkNCisJc2ZlLT5mbGFncyB8PSAoYXJncy0+Zmxh Z3MgJiBBVFRSX1NFQ1VSSVRZKSA/IFhGU19BVFRSX1NFQ1VSSVRZIDogMDsN CisjZW5kaWYNCiAJbWVtY3B5KHNmZS0+bmFtZXZhbCwgYXJncy0+bmFtZSwg YXJncy0+bmFtZWxlbik7DQogCW1lbWNweSgmc2ZlLT5uYW1ldmFsW2FyZ3Mt Pm5hbWVsZW5dLCBhcmdzLT52YWx1ZSwgYXJncy0+dmFsdWVsZW4pOw0KIAlJ TlRfTU9EKHNmLT5oZHIuY291bnQsIEFSQ0hfQ09OVkVSVCwgMSk7DQpAQCAt MjA5LDggKzIxOSwxNSBAQA0KIAkJCWNvbnRpbnVlOw0KIAkJaWYgKG1lbWNt cChzZmUtPm5hbWV2YWwsIGFyZ3MtPm5hbWUsIGFyZ3MtPm5hbWVsZW4pICE9 IDApDQogCQkJY29udGludWU7DQorI2lmZGVmIENPTkZJR19YRlNfWEFUVFJf U0VDVVJJVFkNCisJCWlmICgoKGFyZ3MtPmZsYWdzICYgQVRUUl9ST09UKSAh PSAwKSAhPQ0KKwkJICAgICgoc2ZlLT5mbGFncyAmIFhGU19BVFRSX1JPT1Qp ICE9IDApIHx8DQorCQkgICAgKChhcmdzLT5mbGFncyAmIEFUVFJfU0VDVVJJ VFkpICE9IDApICE9DQorCQkgICAgKChzZmUtPmZsYWdzICYgWEZTX0FUVFJf U0VDVVJJVFkpICE9IDApKQ0KKyNlbHNlDQogCQlpZiAoKChhcmdzLT5mbGFn cyAmIEFUVFJfUk9PVCkgIT0gMCkgIT0NCiAJCSAgICAoKHNmZS0+ZmxhZ3Mg JiBYRlNfQVRUUl9ST09UKSAhPSAwKSkNCisjZW5kaWYNCiAJCQljb250aW51 ZTsNCiAJCWJyZWFrOw0KIAl9DQpAQCAtMjUzLDggKzI3MCwxNSBAQA0KIAkJ CWNvbnRpbnVlOw0KIAkJaWYgKG1lbWNtcChhcmdzLT5uYW1lLCBzZmUtPm5h bWV2YWwsIGFyZ3MtPm5hbWVsZW4pICE9IDApDQogCQkJY29udGludWU7DQor I2lmZGVmIENPTkZJR19YRlNfWEFUVFJfU0VDVVJJVFkNCisJCWlmICgoKGFy Z3MtPmZsYWdzICYgQVRUUl9ST09UKSAhPSAwKSAhPQ0KKwkJICAgICgoc2Zl LT5mbGFncyAmIFhGU19BVFRSX1JPT1QpICE9IDApIHx8DQorCQkgICAgKChh cmdzLT5mbGFncyAmIEFUVFJfU0VDVVJJVFkpICE9IDApICE9DQorCQkgICAg KChzZmUtPmZsYWdzICYgWEZTX0FUVFJfU0VDVVJJVFkpICE9IDApKQ0KKyNl bHNlDQogCQlpZiAoKChhcmdzLT5mbGFncyAmIEFUVFJfUk9PVCkgIT0gMCkg IT0NCiAJCSAgICAoKHNmZS0+ZmxhZ3MgJiBYRlNfQVRUUl9ST09UKSAhPSAw KSkNCisjZW5kaWYNCiAJCQljb250aW51ZTsNCiAJCXJldHVybihYRlNfRVJS T1IoRUVYSVNUKSk7DQogCX0NCkBAIC0yODEsOCArMzA1LDE1IEBADQogCQkJ Y29udGludWU7DQogCQlpZiAobWVtY21wKGFyZ3MtPm5hbWUsIHNmZS0+bmFt ZXZhbCwgYXJncy0+bmFtZWxlbikgIT0gMCkNCiAJCQljb250aW51ZTsNCisj aWZkZWYgQ09ORklHX1hGU19YQVRUUl9TRUNVUklUWQ0KKwkJaWYgKCgoYXJn cy0+ZmxhZ3MgJiBBVFRSX1JPT1QpICE9IDApICE9DQorCQkgICAgKChzZmUt PmZsYWdzICYgWEZTX0FUVFJfUk9PVCkgIT0gMCkgfHwNCisJCSAgICAoKGFy Z3MtPmZsYWdzICYgQVRUUl9TRUNVUklUWSkgIT0gMCkgIT0NCisJCSAgICAo KHNmZS0+ZmxhZ3MgJiBYRlNfQVRUUl9TRUNVUklUWSkgIT0gMCkpDQorI2Vs c2UNCiAJCWlmICgoKGFyZ3MtPmZsYWdzICYgQVRUUl9ST09UKSAhPSAwKSAh PQ0KIAkJICAgICgoc2ZlLT5mbGFncyAmIFhGU19BVFRSX1JPT1QpICE9IDAp KQ0KKyNlbmRpZg0KIAkJCWNvbnRpbnVlOw0KIAkJaWYgKGFyZ3MtPmZsYWdz ICYgQVRUUl9LRVJOT1ZBTCkgew0KIAkJCWFyZ3MtPnZhbHVlbGVuID0gSU5U X0dFVChzZmUtPnZhbHVlbGVuLCBBUkNIX0NPTlZFUlQpOw0KQEAgLTM3MCw2 ICs0MDEsOSBAQA0KIAkJbmFyZ3MuaGFzaHZhbCA9IHhmc19kYV9oYXNobmFt ZSgoY2hhciAqKXNmZS0+bmFtZXZhbCwNCiAJCQkJCQlzZmUtPm5hbWVsZW4p Ow0KIAkJbmFyZ3MuZmxhZ3MgPSAoc2ZlLT5mbGFncyAmIFhGU19BVFRSX1JP T1QpID8gQVRUUl9ST09UIDogMDsNCisjaWZkZWYgQ09ORklHX1hGU19YQVRU Ul9TRUNVUklUWQ0KKwkJbmFyZ3MuZmxhZ3MgfD0gKHNmZS0+ZmxhZ3MgJiBY RlNfQVRUUl9TRUNVUklUWSkgPyBBVFRSX1NFQ1VSSVRZIDogMDsNCisjZW5k aWYNCiAJCWVycm9yID0geGZzX2F0dHJfbGVhZl9sb29rdXBfaW50KGJwLCAm bmFyZ3MpOyAvKiBzZXQgYS0+aW5kZXggKi8NCiAJCUFTU0VSVChlcnJvciA9 PSBFTk9BVFRSKTsNCiAJCWVycm9yID0geGZzX2F0dHJfbGVhZl9hZGQoYnAs ICZuYXJncyk7DQpAQCAtNDQ0LDEwICs0NzgsMjAgQEANCiAJCQkJCQkJPCBj b250ZXh0LT5idWZzaXplKSB7DQogCQlmb3IgKGkgPSAwLCBzZmUgPSAmc2Yt Pmxpc3RbMF07DQogCQkJCWkgPCBJTlRfR0VUKHNmLT5oZHIuY291bnQsIEFS Q0hfQ09OVkVSVCk7IGkrKykgew0KKyNpZmRlZiBDT05GSUdfWEZTX1hBVFRS X1NFQ1VSSVRZDQorCQkJaW50IG5zID0gKHNmZS0+ZmxhZ3MgJiBYRlNfQVRU Ul9ST09UKT8gUk9PVF9OQU1FUzoNCisJCQkJIAkoc2ZlLT5mbGFncyAmIFhG U19BVFRSX1NFQ1VSSVRZKT8NCisJCQkJCQlTRUNVUklUWV9OQU1FUzpVU0VS X05BTUVTOw0KKwkJCWlmICgoKChjb250ZXh0LT5mbGFncyAmIEFUVFJfUk9P VCkgIT0gMCkgIT0NCisJCQkgICAgICgoc2ZlLT5mbGFncyAmIFhGU19BVFRS X1JPT1QpICE9IDApIHx8DQorCQkJICAgICAoKGNvbnRleHQtPmZsYWdzICYg QVRUUl9TRUNVUklUWSkgIT0gMCkgIT0NCisJCQkgICAgICgoc2ZlLT5mbGFn cyAmIFhGU19BVFRSX1NFQ1VSSVRZKSAhPSAwKSkgJiYNCisjZWxzZQ0KIAkJ CWludCBucyA9IChzZmUtPmZsYWdzICYgWEZTX0FUVFJfUk9PVCk/DQogCQkJ CQkJUk9PVF9OQU1FUyA6IFVTRVJfTkFNRVM7DQogCQkJaWYgKCgoY29udGV4 dC0+ZmxhZ3MgJiBBVFRSX1JPT1QpICE9IDApICE9DQogCQkJICAgICgoc2Zl LT5mbGFncyAmIFhGU19BVFRSX1JPT1QpICE9IDApICYmDQorI2VuZGlmDQog CQkJICAgICEoY29udGV4dC0+ZmxhZ3MgJiBBVFRSX0tFUk5GVUxMUykpIHsN CiAJCQkJc2ZlID0gWEZTX0FUVFJfU0ZfTkVYVEVOVFJZKHNmZSk7DQogCQkJ CWNvbnRpbnVlOw0KQEAgLTQ5NCw4ICs1MzgsMTUgQEANCiAJCQlrbWVtX2Zy ZWUoc2J1Ziwgc2JzaXplKTsNCiAJCQlyZXR1cm4gWEZTX0VSUk9SKEVGU0NP UlJVUFRFRCk7DQogCQl9DQorI2lmZGVmIENPTkZJR19YRlNfWEFUVFJfU0VD VVJJVFkNCisJCWlmICgoKChjb250ZXh0LT5mbGFncyAmIEFUVFJfUk9PVCkg IT0gMCkgIT0NCisJCSAgICAgKChzZmUtPmZsYWdzICYgWEZTX0FUVFJfUk9P VCkgIT0gMCkgfHwNCisJCSAgICAgKChjb250ZXh0LT5mbGFncyAmIEFUVFJf U0VDVVJJVFkpICE9IDApICE9DQorCQkgICAgICgoc2ZlLT5mbGFncyAmIFhG U19BVFRSX1NFQ1VSSVRZKSAhPSAwKSkgJiYNCisjZWxzZQ0KIAkJaWYgKCgo Y29udGV4dC0+ZmxhZ3MgJiBBVFRSX1JPT1QpICE9IDApICE9DQogCQkgICAg KChzZmUtPmZsYWdzICYgWEZTX0FUVFJfUk9PVCkgIT0gMCkgJiYNCisjZW5k aWYNCiAJCSAgICAhKGNvbnRleHQtPmZsYWdzICYgQVRUUl9LRVJORlVMTFMp KSB7DQogCQkJc2ZlID0gWEZTX0FUVFJfU0ZfTkVYVEVOVFJZKHNmZSk7DQog CQkJY29udGludWU7DQpAQCAtNTQ0LDcgKzU5NSwxMyBAQA0KIAkgKiBMb29w IHB1dHRpbmcgZW50cmllcyBpbnRvIHRoZSB1c2VyIGJ1ZmZlci4NCiAJICov DQogCWZvciAoIDsgaSA8IG5zYnVmOyBpKyssIHNicCsrKSB7DQorI2lmZGVm IENPTkZJR19YRlNfWEFUVFJfU0VDVVJJVFkNCisJCWludCBucyA9IChzYnAt PmZsYWdzICYgWEZTX0FUVFJfUk9PVCk/IFJPT1RfTkFNRVM6DQorCQkJIChz YnAtPmZsYWdzICYgWEZTX0FUVFJfU0VDVVJJVFkpPw0KKwkJICAJCQlTRUNV UklUWV9OQU1FUzpVU0VSX05BTUVTOw0KKyNlbHNlDQogCQlpbnQgbnMgPSAo c2JwLT5mbGFncyAmIFhGU19BVFRSX1JPT1QpPyBST09UX05BTUVTOlVTRVJf TkFNRVM7DQorI2VuZGlmDQogCQlpZiAoY3Vyc29yLT5oYXNodmFsICE9IElO VF9HRVQoc2JwLT5oYXNoLCBBUkNIX0NPTlZFUlQpKSB7DQogCQkJY3Vyc29y LT5oYXNodmFsID0gSU5UX0dFVChzYnAtPmhhc2gsIEFSQ0hfQ09OVkVSVCk7 DQogCQkJY3Vyc29yLT5vZmZzZXQgPSAwOw0KQEAgLTY2Myw2ICs3MjAsOSBA QA0KIAkJbmFyZ3MudmFsdWVsZW4gPSBJTlRfR0VUKG5hbWVfbG9jLT52YWx1 ZWxlbiwgQVJDSF9DT05WRVJUKTsNCiAJCW5hcmdzLmhhc2h2YWwgPSBJTlRf R0VUKGVudHJ5LT5oYXNodmFsLCBBUkNIX0NPTlZFUlQpOw0KIAkJbmFyZ3Mu ZmxhZ3MgPSAoZW50cnktPmZsYWdzICYgWEZTX0FUVFJfUk9PVCkgPyBBVFRS X1JPT1QgOiAwOw0KKyNpZmRlZiBDT05GSUdfWEZTX1hBVFRSX1NFQ1VSSVRZ DQorCQluYXJncy5mbGFncyB8PSAoZW50cnktPmZsYWdzICYgWEZTX0FUVFJf U0VDVVJJVFkpID8gQVRUUl9TRUNVUklUWSA6IDA7DQorI2VuZGlmDQogCQl4 ZnNfYXR0cl9zaG9ydGZvcm1fYWRkKCZuYXJncyk7DQogCX0NCiAJZXJyb3Ig PSAwOw0KQEAgLTk1OCw2ICsxMDE4LDkgQEANCiAJSU5UX1NFVChlbnRyeS0+ aGFzaHZhbCwgQVJDSF9DT05WRVJULCBhcmdzLT5oYXNodmFsKTsNCiAJZW50 cnktPmZsYWdzID0gdG1wID8gWEZTX0FUVFJfTE9DQUwgOiAwOw0KIAllbnRy eS0+ZmxhZ3MgfD0gKGFyZ3MtPmZsYWdzICYgQVRUUl9ST09UKSA/IFhGU19B VFRSX1JPT1QgOiAwOw0KKyNpZmRlZiBDT05GSUdfWEZTX1hBVFRSX1NFQ1VS SVRZDQorCWVudHJ5LT5mbGFncyB8PSAoYXJncy0+ZmxhZ3MgJiBBVFRSX1NF Q1VSSVRZKSA/IFhGU19BVFRSX1NFQ1VSSVRZIDogMDsNCisjZW5kaWYNCiAJ aWYgKGFyZ3MtPnJlbmFtZSkgew0KIAkJZW50cnktPmZsYWdzIHw9IFhGU19B VFRSX0lOQ09NUExFVEU7DQogCQlpZiAoKGFyZ3MtPmJsa25vMiA9PSBhcmdz LT5ibGtubykgJiYNCkBAIC0xODc1LDggKzE5MzgsMTUgQEANCiAJCQlpZiAo bWVtY21wKGFyZ3MtPm5hbWUsIChjaGFyICopbmFtZV9sb2MtPm5hbWV2YWws DQogCQkJCQkgICAgIGFyZ3MtPm5hbWVsZW4pICE9IDApDQogCQkJCWNvbnRp bnVlOw0KKyNpZmRlZiBDT05GSUdfWEZTX1hBVFRSX1NFQ1VSSVRZDQorCQkJ aWYgKCgoYXJncy0+ZmxhZ3MgJiBBVFRSX1JPT1QpICE9IDApICE9DQorCQkJ ICAgICgoZW50cnktPmZsYWdzICYgWEZTX0FUVFJfUk9PVCkgIT0gMCkgfHwN CisJCQkgICAgKChhcmdzLT5mbGFncyAmIEFUVFJfU0VDVVJJVFkpICE9IDAp ICE9DQorCQkJICAgICgoZW50cnktPmZsYWdzICYgWEZTX0FUVFJfU0VDVVJJ VFkpICE9IDApKQ0KKyNlbHNlDQogCQkJaWYgKCgoYXJncy0+ZmxhZ3MgJiBB VFRSX1JPT1QpICE9IDApICE9DQogCQkJICAgICgoZW50cnktPmZsYWdzICYg WEZTX0FUVFJfUk9PVCkgIT0gMCkpDQorI2VuZGlmDQogCQkJCWNvbnRpbnVl Ow0KIAkJCWFyZ3MtPmluZGV4ID0gcHJvYmU7DQogCQkJcmV0dXJuKFhGU19F UlJPUihFRVhJU1QpKTsNCkBAIC0xODg3LDggKzE5NTcsMTUgQEANCiAJCQlp ZiAobWVtY21wKGFyZ3MtPm5hbWUsIChjaGFyICopbmFtZV9ybXQtPm5hbWUs DQogCQkJCQkgICAgIGFyZ3MtPm5hbWVsZW4pICE9IDApDQogCQkJCWNvbnRp bnVlOw0KKyNpZmRlZiBDT05GSUdfWEZTX1hBVFRSX1NFQ1VSSVRZDQorCQkJ aWYgKCgoYXJncy0+ZmxhZ3MgJiBBVFRSX1JPT1QpICE9IDApICE9DQorCQkJ ICAgICgoZW50cnktPmZsYWdzICYgWEZTX0FUVFJfUk9PVCkgIT0gMCkgfHwN CisJCQkgICAgKChhcmdzLT5mbGFncyAmIEFUVFJfU0VDVVJJVFkpICE9IDAp ICE9DQorCQkJICAgICgoZW50cnktPmZsYWdzICYgWEZTX0FUVFJfU0VDVVJJ VFkpICE9IDApKQ0KKyNlbHNlDQogCQkJaWYgKCgoYXJncy0+ZmxhZ3MgJiBB VFRSX1JPT1QpICE9IDApICE9DQogCQkJICAgICgoZW50cnktPmZsYWdzICYg WEZTX0FUVFJfUk9PVCkgIT0gMCkpDQorI2VuZGlmDQogCQkJCWNvbnRpbnVl Ow0KIAkJCWFyZ3MtPmluZGV4ID0gcHJvYmU7DQogCQkJYXJncy0+cm10Ymxr bm8NCkBAIC0yMjcwLDcgKzIzNDcsMTMgQEANCiAJcmV0dmFsID0gMDsNCiAJ Zm9yICggIDsgKGkgPCBJTlRfR0VUKGxlYWYtPmhkci5jb3VudCwgQVJDSF9D T05WRVJUKSkNCiAJICAgICAmJiAocmV0dmFsID09IDApOyBlbnRyeSsrLCBp KyspIHsNCisjaWZkZWYgQ09ORklHX1hGU19YQVRUUl9TRUNVUklUWQ0KKwkJ aW50IG5zID0gKGVudHJ5LT5mbGFncyAmIFhGU19BVFRSX1JPT1QpPyBST09U X05BTUVTOg0KKwkJCSAoZW50cnktPmZsYWdzICYgWEZTX0FUVFJfU0VDVVJJ VFkpPw0KKwkJCQkJU0VDVVJJVFlfTkFNRVM6VVNFUl9OQU1FUzsNCisjZWxz ZQ0KIAkJaW50IG5zID0gKGVudHJ5LT5mbGFncyAmIFhGU19BVFRSX1JPT1Qp PyBST09UX05BTUVTOlVTRVJfTkFNRVM7DQorI2VuZGlmDQogDQogCQlpZiAo SU5UX0dFVChlbnRyeS0+aGFzaHZhbCwgQVJDSF9DT05WRVJUKSAhPSBjdXJz b3ItPmhhc2h2YWwpIHsNCiAJCQljdXJzb3ItPmhhc2h2YWwgPSBJTlRfR0VU KGVudHJ5LT5oYXNodmFsLCBBUkNIX0NPTlZFUlQpOw0KQEAgLTIyNzksOCAr MjM2MiwxNSBAQA0KIA0KIAkJaWYgKGVudHJ5LT5mbGFncyAmIFhGU19BVFRS X0lOQ09NUExFVEUpDQogCQkJY29udGludWU7CQkvKiBza2lwIGluY29tcGxl dGUgZW50cmllcyAqLw0KKyNpZmRlZiBDT05GSUdfWEZTX1hBVFRSX1NFQ1VS SVRZDQorCQlpZiAoKCgoY29udGV4dC0+ZmxhZ3MgJiBBVFRSX1JPT1QpICE9 IDApICE9DQorCQkgICAgICgoZW50cnktPmZsYWdzICYgWEZTX0FUVFJfUk9P VCkgIT0gMCkgfHwNCisJCSAgICAgKChjb250ZXh0LT5mbGFncyAmIEFUVFJf U0VDVVJJVFkpICE9IDApICE9DQorCQkgICAgICgoZW50cnktPmZsYWdzICYg WEZTX0FUVFJfU0VDVVJJVFkpICE9IDApKSAmJg0KKyNlbHNlDQogCQlpZiAo KChjb250ZXh0LT5mbGFncyAmIEFUVFJfUk9PVCkgIT0gMCkgIT0NCiAJCSAg ICAoKGVudHJ5LT5mbGFncyAmIFhGU19BVFRSX1JPT1QpICE9IDApICYmDQor I2VuZGlmDQogCQkgICAgIShjb250ZXh0LT5mbGFncyAmIEFUVFJfS0VSTkZV TExTKSkNCiAJCQljb250aW51ZTsJCS8qIHNraXAgbm9uLW1hdGNoaW5nIGVu dHJpZXMgKi8NCiANCmRpZmYgLXVyTiBsaW51eC0yLjYuMC10ZXN0MTAub3Jp Zy9mcy94ZnMveGZzX2F0dHJfbGVhZi5oIGxpbnV4LTIuNi4wLXRlc3QxMC9m cy94ZnMveGZzX2F0dHJfbGVhZi5oDQotLS0gbGludXgtMi42LjAtdGVzdDEw Lm9yaWcvZnMveGZzL3hmc19hdHRyX2xlYWYuaAkyMDAzLTExLTIzIDE5OjMw OjU1LjAwMDAwMDAwMCAtMDYwMA0KKysrIGxpbnV4LTIuNi4wLXRlc3QxMC9m cy94ZnMveGZzX2F0dHJfbGVhZi5oCTIwMDMtMTEtMjYgMDk6Mjc6NTAuMDAw MDAwMDAwIC0wNjAwDQpAQCAtMTI5LDkgKzEyOSwxNSBAQA0KICAqLw0KICNk ZWZpbmUJWEZTX0FUVFJfTE9DQUxfQklUCTAJLyogYXR0ciBpcyBzdG9yZWQg bG9jYWxseSAqLw0KICNkZWZpbmUJWEZTX0FUVFJfUk9PVF9CSVQJMQkvKiBs aW1pdCBhY2Nlc3MgdG8gYXR0ciB0byB1c2VyaWQgMCAqLw0KKyNpZmRlZiBD T05GSUdfWEZTX1hBVFRSX1NFQ1VSSVRZDQorI2RlZmluZQlYRlNfQVRUUl9T RUNVUklUWV9CSVQJMgkvKiBhdHRyIGlzIGluIHNlY3VyaXR5LiogbmFtZXNw YWNlICovDQorI2VuZGlmDQogI2RlZmluZQlYRlNfQVRUUl9JTkNPTVBMRVRF X0JJVAk3CS8qIGF0dHIgaW4gbWlkZGxlIG9mIGNyZWF0ZS9kZWxldGUgKi8N CiAjZGVmaW5lIFhGU19BVFRSX0xPQ0FMCQkoMSA8PCBYRlNfQVRUUl9MT0NB TF9CSVQpDQogI2RlZmluZSBYRlNfQVRUUl9ST09UCQkoMSA8PCBYRlNfQVRU Ul9ST09UX0JJVCkNCisjaWZkZWYgQ09ORklHX1hGU19YQVRUUl9TRUNVUklU WQ0KKyNkZWZpbmUgWEZTX0FUVFJfU0VDVVJJVFkgICAgICAJKDEgPDwgWEZT X0FUVFJfU0VDVVJJVFlfQklUKQ0KKyNlbmRpZg0KICNkZWZpbmUgWEZTX0FU VFJfSU5DT01QTEVURQkoMSA8PCBYRlNfQVRUUl9JTkNPTVBMRVRFX0JJVCkN CiANCiAvKg0KZGlmZiAtdXJOIGxpbnV4LTIuNi4wLXRlc3QxMC5vcmlnL2Zz L3hmcy94ZnNpZGJnLmMgbGludXgtMi42LjAtdGVzdDEwL2ZzL3hmcy94ZnNp ZGJnLmMNCi0tLSBsaW51eC0yLjYuMC10ZXN0MTAub3JpZy9mcy94ZnMveGZz aWRiZy5jCTIwMDMtMTEtMjMgMTk6MzI6NDMuMDAwMDAwMDAwIC0wNjAwDQor KysgbGludXgtMi42LjAtdGVzdDEwL2ZzL3hmcy94ZnNpZGJnLmMJMjAwMy0x MS0yNiAwOTozNTowNy4wMDAwMDAwMDAgLTA2MDANCkBAIC0zMzEzLDkgKzMz MTMsMTcgQEANCiAJCQlrZGJfcHJpbnRmKCJMT0NBTCAiKTsNCiAJCWlmIChl LT5mbGFncyAmIFhGU19BVFRSX1JPT1QpDQogCQkJa2RiX3ByaW50ZigiUk9P VCAiKTsNCisjaWZkZWYgQ09ORklHX1hGU19YQVRUUl9TRUNVUklUWQ0KKwkJ aWYgKGUtPmZsYWdzICYgWEZTX0FUVFJfU0VDVVJJVFkpDQorCQkJa2RiX3By aW50ZigiU0VDVVJJVFkgIik7DQorI2VuZGlmDQogCQlpZiAoZS0+ZmxhZ3Mg JiBYRlNfQVRUUl9JTkNPTVBMRVRFKQ0KIAkJCWtkYl9wcmludGYoIklOQ09N UExFVEUgIik7DQorI2lmZGVmIENPTkZJR19YRlNfWEFUVFJfU0VDVVJJVFkN CisJCWsgPSB+KFhGU19BVFRSX0xPQ0FMIHwgWEZTX0FUVFJfUk9PVCB8IFhG U19BVFRSX1NFQ1VSSVRZIHwgWEZTX0FUVFJfSU5DT01QTEVURSk7DQorI2Vs c2UNCiAJCWsgPSB+KFhGU19BVFRSX0xPQ0FMIHwgWEZTX0FUVFJfUk9PVCB8 IFhGU19BVFRSX0lOQ09NUExFVEUpOw0KKyNlbmRpZg0KIAkJaWYgKChlLT5m bGFncyAmIGspICE9IDApDQogCQkJa2RiX3ByaW50ZigiMHgleCIsIGUtPmZs YWdzICYgayk7DQogCQlrZGJfcHJpbnRmKCI+XG4gICAgIG5hbWUgXCIiKTsN CkBAIC0zNzAzLDEzICszNzExLDIxIEBADQogCQkgICh1aW50X3Qpbi0+aGFz aHZhbCwgbi0+d2hpY2hmb3JrKTsNCiAJaWYgKG4tPmZsYWdzICYgQVRUUl9S T09UKQ0KIAkJa2RiX3ByaW50ZigiUk9PVCAiKTsNCisjaWZkZWYgQ09ORklH X1hGU19YQVRUUl9TRUNVUklUWQ0KKwlpZiAobi0+ZmxhZ3MgJiBBVFRSX1NF Q1VSSVRZKQ0KKwkJa2RiX3ByaW50ZigiU0VDVVJJVFkgIik7DQorI2VuZGlm DQogCWlmIChuLT5mbGFncyAmIEFUVFJfQ1JFQVRFKQ0KIAkJa2RiX3ByaW50 ZigiQ1JFQVRFICIpOw0KIAlpZiAobi0+ZmxhZ3MgJiBBVFRSX1JFUExBQ0Up DQogCQlrZGJfcHJpbnRmKCJSRVBMQUNFICIpOw0KIAlpZiAobi0+ZmxhZ3Mg JiBYRlNfQVRUUl9JTkNPTVBMRVRFKQ0KIAkJa2RiX3ByaW50ZigiSU5DT01Q TEVURSAiKTsNCisjaWZkZWYgQ09ORklHX1hGU19YQVRUUl9TRUNVUklUWQ0K KwlpID0gfihBVFRSX1JPT1QgfCBBVFRSX1NFQ1VSSVRZIHwgQVRUUl9DUkVB VEUgfCBBVFRSX1JFUExBQ0UgfCBYRlNfQVRUUl9JTkNPTVBMRVRFKTsNCisj ZWxzZQ0KIAlpID0gfihBVFRSX1JPT1QgfCBBVFRSX0NSRUFURSB8IEFUVFJf UkVQTEFDRSB8IFhGU19BVFRSX0lOQ09NUExFVEUpOw0KKyNlbmRpZg0KIAlp ZiAoKG4tPmZsYWdzICYgaSkgIT0gMCkNCiAJCWtkYl9wcmludGYoIjB4JXgi LCBuLT5mbGFncyAmIGkpOw0KIAlrZGJfcHJpbnRmKCI+XG4iKTsNCg== --=-PY1EG+CSqMVxaoOqOCPR-- --=-G6eBHJjZi8ll8CclpR+J Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/y4HevI7kLeavkkMRAixNAJ4srV5y/f6vCvO8yp2FIEU/CpAKUQCePlLj 3XM//QRvkPmZxNahVRhzIYM= =+Vt4 -----END PGP SIGNATURE----- --=-G6eBHJjZi8ll8CclpR+J-- From owner-linux-xfs@oss.sgi.com Mon Dec 1 11:49:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 11:49:47 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1JnOTa030037 for ; Mon, 1 Dec 2003 11:49:25 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.22) id 1AQu2r-0002F6-N9; Mon, 01 Dec 2003 19:49:21 +0000 Date: Mon, 1 Dec 2003 19:49:21 +0000 From: Christoph Hellwig To: Chris PeBenito Cc: sandeen@sgi.com, linux-xfs@oss.sgi.com Subject: Re: [patch] security. namespace Message-ID: <20031201194921.A8407@infradead.org> References: <1070301662.7842.11.camel@chris.pebenito.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: <1070301662.7842.11.camel@chris.pebenito.net>; from pebenito@gentoo.org on Mon, Dec 01, 2003 at 12:01:02PM -0600 X-archive-position: 1169 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Mon, Dec 01, 2003 at 12:01:02PM -0600, Chris PeBenito wrote: > Here is a patch against -test10 that adds an option for the security. > namespace (controlled by a configure option), which is used by SELinux > to store it's security labels. I created this patch based off Tad > Glines' (tadglines@comcast.net) 2.4 patch > (http://www.glines.com/xfs.patch.bz2). Please critique this, and if its > ok, please consider for inclusion. > > I was warned on #xfs that this may break IRIX compatability, so there is > a note in the Kconfig. However Tad says that the security. attributes > will show up in the user namespace on a standard XFS linux kernel, but I > didn't verify. He also mentioned that xfsdump and xfsrestore would need > to be patched to support this. a) please kill the silly ifdefs b) without xfsdump support the patch is probably rather useless, you should be able to implement xfsdump support easily by looking at handling of the trusted xattrs. Yes, this would be incompatible with IRIX asis, but IMHO it's fine because this incompatiblity only affects people actually using security xattrs which don't make sense on IRIX. From owner-linux-xfs@oss.sgi.com Mon Dec 1 12:43:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 12:43:24 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1Kh1Ta011024 for ; Mon, 1 Dec 2003 12:43:01 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB1L3vHc012775 for ; Mon, 1 Dec 2003 15:03:57 -0600 Received: from sgi.com (syntegra.americas.sgi.com [128.162.232.81]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB1Kf5P516135729; Mon, 1 Dec 2003 14:41:05 -0600 (CST) Message-ID: <3FCBA758.8030805@sgi.com> Date: Mon, 01 Dec 2003 14:40:56 -0600 From: Mandy Kirkconnell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Jeremy Jackson CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump fails to overwrite stream terminator - dumps lost References: <005f01c3aacb$653522d0$6207a8c0@titanic> <3FC398C2.8010407@sgi.com> <3FC3AEE3.2080107@coplanar.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1170 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs Hi Jeremy, I had a chance to look at this over the weekend and was able to reproduce the problem immediately. A mod went into 2.2.13 to fix multiple backups using the TS(SGI) tape driver. There was a call to the MTBSF tape ioctl which got changed to MTBSFM in order to fix multiple backups to TS tape devices. I was under the impression that all tape ioctls followed a standard set of rules and produced the same behaviour regardless of the OS or tape driver (ie. MTBSFM will always position tape to the left side of the FM). This is incorrect. I just found out that TS and ST differ in the following tape ioctls: TS MTBSF - back space file, position after FM MTBSFM - back space file, position before FM ST MTBSF - back space file, position before FM MTBSFM - back space file, position after FM These positioning differences are very significant to xfsdump. When the call to MTBSF got changed to MTBSFM in 2.2.13, it fixed multiple backups for TS devices but actually broke the functionality for ST tape devices!! This is fixed in 2.2.15, available in the next few days. Mandy -- Mandy Kirkconnell SGI, Storage Software Engineer alkirkco@sgi.com Jeremy Jackson wrote: > Hi Mandy, > > I'm a bit confused. The problem occurs on multiple systems when using > xfsdump 2.2.14 on a blank tape. The first fs dumps ok, but the rest > just keep overwriting the second session. > > The *older* versions seem to work, in fact I have switched 7 or so > systems to the 2.2.11 since it's the only way I can do backups. > > Sorry if my post was a bit confusing... I made a second post with some > newer information. It looks to me like 2.2.12 was a regression, not a fix. > > Regards, > > Jeremy Jackson > > Mandy Kirkconnell wrote: > >> Jeremy Jackson wrote: >> >>> I have done dumps of the filesystems of 3 machines to a common tape >>> drive, >>> an Exabyte EXB-8500. One machine contains the tape drive, the other >>> two use >>> rmt. Five tapes were filled (5GB each), with a sixth only partly used. >>> >>> Next I wanted to test overwrite handling, as I was having problems >>> with an >>> earlier version of xfsdump. I started a dump of a 75GB filesystem, >>> without >>> using the -o flag. I began with the partly used sixth tape. The >>> previously >>> used dumps had apparently left a stream terminator at media file 12, and >>> this is where the dump began. >>> >>> After the tape became full, a tape change was requested. I either >>> felt like >>> testing xfsdump, or I wasn't thinking clearly, so I accepted the tape >>> change >>> request without changing the tape. As I watched "xfsdump: preparing >>> drive", >>> the tape was rewound, and media files were examined. I was shocked >>> to see >>> it continue dumping at media file 12 *again*. It found a stream >>> terminator, >>> and that was all it was waiting for! >>> >>> I noticed a bug was fixed in 2.2.13 regarding handling multiple >>> backups to a >>> single tape, but I'm not sure what the exact problem was that was fixed. >>> The earlier dumps on the tapes were with the older version, 2.2.11-1, >>> and >>> the *dump in question* was with 2.2.14-1. >> >> >> >> As you suspected, this is caused by the problem that got fixed in >> 2.2.13. It's a nasty one! Any tape backups written with 2.2.12 or >> earlier are not reliable when multiple dump sessions are involved. >> >> The problem was introduced when xfsdump was ported from IRIX to Linux. >> On IRIX, the TS tape driver sets EOF whether it is to the left OR >> right of a tape mark. On Linux, the ST tape driver ONLY sets EOF when >> positioned to the right of a tape mark. On IRIX, the MTBSF,1 >> (backward space 1 filemark) ioctl moves backward along the tape until >> it finds a filemark, then positions the tape to the RIGHT of (after) >> the filemark. On Linux, the MTBSF,1 ioctl moves back one filemark and >> positions the tape to the LEFT of (before) the filemark. These >> differences are very important!! >> >> These filemark positioning differences were causing the tape to be >> rewound before each dump and the next dump would begin at the exact >> same start position of the last dump. The result of this was that >> each new dump would always overwrite the previous dump, so a tape >> would only ever contain one full (most recent) dump session at a time!! >> >> Please use 2.2.13 or later for any new backups. >> >> Thanks, >> Mandy >> > From owner-linux-xfs@oss.sgi.com Mon Dec 1 13:00:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 13:00:43 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1L0BTa015108 for ; Mon, 1 Dec 2003 13:00:14 -0800 Received: from conversion-daemon.woozle.fnal.gov by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HP800201IC1JS@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Mon, 01 Dec 2003 15:00:11 -0600 (CST) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTPSA id <0HP800HHSIC9YV@woozle.fnal.gov>; Mon, 01 Dec 2003 15:00:10 -0600 (CST) Date: Mon, 01 Dec 2003 15:00:09 -0600 From: Dan Yocum Subject: Re: XFS for 2.4 In-reply-to: <20031201062052.GA2022@frodo> To: Nathan Scott Cc: Marcelo Tosatti , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Message-id: <3FCBABD9.70309@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 References: <20031201062052.GA2022@frodo> X-archive-position: 1171 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Marcelo, We (Fermilab) second this request. We won't be touching 2.6 until it's really stable (read as, Red Hat comes out with an official distro that has it built in), and we already have *a lot* of XFS filesystems here (~>300TB) running on 2.4 kernels. It would be very, very nice to have it in the 2.4 tree without having to pull it from SGI. Thanks, Dan Nathan Scott wrote: > Hi Marcelo, > > Please do a > > bk pull http://xfs.org:8090/linux-2.4+coreXFS > > This will merge the core 2.4 kernel changes required for supporting > the XFS filesystem, as listed below. If this all looks acceptable, > then please also pull the filesystem-specific code (fs/xfs/*) > > bk pull http://xfs.org:8090/linux-2.4+justXFS > > cheers. > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. You are here. From owner-linux-xfs@oss.sgi.com Mon Dec 1 13:21:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 13:21:34 -0800 (PST) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1LL5Ta003244 for ; Mon, 1 Dec 2003 13:21:07 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id hB1LO23o006930; Mon, 1 Dec 2003 16:24:02 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id hB1LO2kw006927; Mon, 1 Dec 2003 16:24:02 -0500 Date: Mon, 1 Dec 2003 16:24:02 -0500 (EST) From: Net Llama! To: Keith Owens cc: linux-xfs@oss.sgi.com Subject: Re: Announce: XFS split patches for 2.4.23 In-Reply-To: <2663.1070240785@kao2.melbourne.sgi.com> Message-ID: References: <2663.1070240785@kao2.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1172 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs On Mon, 1 Dec 2003, Keith Owens wrote: > ftp://oss.sgi.com/projects/xfs/download/patches/2.4.23. Anyone else getting bizarro errors when trying to download anything from this directory? I can run 'ls' on it and see everything, but if I try to perform a GET, i end up with: No such file `xfs-2.4.23-all-i386.bz2' Actually, nevermind, i see the reason (using ncftp): get xfs-2.4.23-all-i386.bz2: server said: The load was 5.82 when you connected. We do not allow downloads ugh. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Mon Dec 1 13:50:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 13:50:38 -0800 (PST) Received: from s383.jpl.nasa.gov (s383.jpl.nasa.gov [137.79.94.127]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1LoFTa012596 for ; Mon, 1 Dec 2003 13:50:15 -0800 Received: from jpl.nasa.gov (mulan [137.78.61.94]) by s383.jpl.nasa.gov (8.12.10/8.12.10) with ESMTP id hB1Lo85t023509; Mon, 1 Dec 2003 13:50:08 -0800 (PST) Message-ID: <3FCBB790.1030503@jpl.nasa.gov> Date: Mon, 01 Dec 2003 13:50:08 -0800 From: Bryan Whitehead Organization: Jet Propulsion Laboratory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630 X-Accept-Language: en-us, en, zh, zh-cn, zh-hk, zh-sg, zh-tw, ja MIME-Version: 1.0 To: Dan Yocum CC: Nathan Scott , Marcelo Tosatti , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 References: <20031201062052.GA2022@frodo> <3FCBABD9.70309@fnal.gov> In-Reply-To: <3FCBABD9.70309@fnal.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1173 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: driver@jpl.nasa.gov Precedence: bulk X-list: linux-xfs I'd like to "third" this request. Have a large amount of data here on XFS with v2.4 kernel. Would be nice to be able to use pre-release 2.4 for testing without having to manually hack in XFS paches from SGI for the odd reject... Dan Yocum wrote: > Marcelo, > > We (Fermilab) second this request. We won't be touching 2.6 until it's > really stable (read as, Red Hat comes out with an official distro that > has it built in), and we already have *a lot* of XFS filesystems here > (~>300TB) running on 2.4 kernels. It would be very, very nice to have > it in the 2.4 tree without having to pull it from SGI. > > Thanks, > Dan > > > Nathan Scott wrote: > >> Hi Marcelo, >> >> Please do a >> >> bk pull http://xfs.org:8090/linux-2.4+coreXFS >> >> This will merge the core 2.4 kernel changes required for supporting >> the XFS filesystem, as listed below. If this all looks acceptable, >> then please also pull the filesystem-specific code (fs/xfs/*) >> >> bk pull http://xfs.org:8090/linux-2.4+justXFS >> >> cheers. >> > -- Bryan Whitehead SysAdmin - JPL - Interferometry and Large Optical Systems Phone: 818 354 2903 driver@jpl.nasa.gov From owner-linux-xfs@oss.sgi.com Mon Dec 1 14:02:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 14:02:43 -0800 (PST) Received: from mail.mnsu.edu ([134.29.1.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1M2BTa016398 for ; Mon, 1 Dec 2003 14:02:12 -0800 Received: from mnsu.edu (j3gum-1.MavNet.MNSU.EDU [134.29.64.64]) by mail.mnsu.edu (8.12.10/8.12.10) with ESMTP id hB1M1ZSh030915 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 1 Dec 2003 16:01:35 -0600 Message-ID: <3FCBBA3F.2090504@mnsu.edu> Date: Mon, 01 Dec 2003 16:01:35 -0600 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bryan Whitehead CC: Dan Yocum , Nathan Scott , Marcelo Tosatti , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 References: <20031201062052.GA2022@frodo> <3FCBABD9.70309@fnal.gov> <3FCBB790.1030503@jpl.nasa.gov> In-Reply-To: <3FCBB790.1030503@jpl.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1174 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: linux-xfs I'd like to add my vote also. I've been using XFS for years. The XFS patches work well. But having them in the standard kernel would be very nice. -- jeffrey hundstad Bryan Whitehead wrote: > I'd like to "third" this request. Have a large amount of data here on > XFS with v2.4 kernel. > > Would be nice to be able to use pre-release 2.4 for testing without > having to manually hack in XFS paches from SGI for the odd reject... > > Dan Yocum wrote: > >> Marcelo, >> >> We (Fermilab) second this request. We won't be touching 2.6 until >> it's really stable (read as, Red Hat comes out with an official >> distro that has it built in), and we already have *a lot* of XFS >> filesystems here (~>300TB) running on 2.4 kernels. It would be very, >> very nice to have it in the 2.4 tree without having to pull it from SGI. >> >> Thanks, >> Dan >> >> >> Nathan Scott wrote: >> >>> Hi Marcelo, >>> >>> Please do a >>> >>> bk pull http://xfs.org:8090/linux-2.4+coreXFS >>> >>> This will merge the core 2.4 kernel changes required for supporting >>> the XFS filesystem, as listed below. If this all looks acceptable, >>> then please also pull the filesystem-specific code (fs/xfs/*) >>> >>> bk pull http://xfs.org:8090/linux-2.4+justXFS >>> >>> cheers. >>> >> > > From owner-linux-xfs@oss.sgi.com Mon Dec 1 14:08:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 14:09:15 -0800 (PST) Received: from zoidberg.canadatux.org (zoidberg@[207.35.33.175]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1M8rTa017224 for ; Mon, 1 Dec 2003 14:08:53 -0800 Received: from localhost (zoidberg.canadatux.org [127.0.0.1]) by zoidberg.canadatux.org (Postfix) with ESMTP id CE0EA807C; Mon, 1 Dec 2003 14:08:52 -0800 (PST) Received: from zoidberg.canadatux.org ([127.0.0.1]) by localhost (zoidberg [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 12331-09; Mon, 1 Dec 2003 14:08:52 -0800 (PST) Received: from kridder.de (ip-190.hilton.RWTH-Aachen.DE [134.130.55.190]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by zoidberg.canadatux.org (Postfix) with ESMTP id 6907E807B; Mon, 1 Dec 2003 14:08:51 -0800 (PST) Message-ID: <3FCBBBF1.3040103@kridder.de> Date: Mon, 01 Dec 2003 23:08:49 +0100 From: Klaus Ridder User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: xlog_clear_stale_blocks crashes in line 1242 (suse 9) References: <3FC9C8C0.6060002@kridder.de> <1070295978.28534.5.camel@stout.americas.sgi.com> In-Reply-To: <1070295978.28534.5.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at canadatux.org X-archive-position: 1175 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mails.2003__contact-me-at__klaus@kridder.de Precedence: bulk X-list: linux-xfs Eric Sandeen wrote: >On Sun, 2003-11-30 at 04:38, Klaus Ridder wrote: > > > >>I am not on the XFS list (and wil not subscribe), so it would be kind of >>you to send me a cc when you figured out the problem or need further >>information. >> >> > >Detailed steps on how to reproduce this problem would be most helpful; >I'm not certain what steps you took leading up to your problem. > >Filing this information in a Bugzilla bug would also be very helpful, if >possible. http://oss.sgi.com/bugzilla/ > >Thanks, >-Eric > > > 1. Installed SUSE 9 2. Created encrypted Raid 5 on 8 IDE disks a 160 GB on 2 IDE Controllers 3. mounted the file system, copied a file on it 4. rebooted the system 5. trying to mount the file system --> error above. I figured out now that - for whatever reason - the blowfish module was not loaded, so I guess that a) XFS got an encrypted stream instead of the decrypted data b) maybe the controllers got mixed up so they got junk data as well. I guess XFS got some sort of totally junk data and didn't handle it proberly somehow. He seems to have scanned for someting for approx. 20 seconds before he mentioned the error. In fact, the first - say - 5 times I tried to mount the drive he didn't give the error; but after that the error was exactly reproducable. I formatted the array with ext3 now so I'm sorry I cannot run any further tests as the array is already used in production. Sorry for the not very detailed problem description. Probably you can simply catch such errors so that XFS doen't throw an error in the mentioned c file with a dump, which looks quite ... well, say ... scary ;) I'm a quit short in time now, so as I don't have a bugzilla account feel free to put my mails in there if you want. It's not urgent for me as I won't use XFS for now. Regards, Klaus From owner-linux-xfs@oss.sgi.com Mon Dec 1 14:11:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 14:12:02 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1MBnTa017692 for ; Mon, 1 Dec 2003 14:11:50 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hB1KIdOO012222 for ; Mon, 1 Dec 2003 12:18:40 -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 JAA13114; Tue, 2 Dec 2003 09:11:37 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB1MBPUc1931779; Tue, 2 Dec 2003 09:11:25 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hB1MBBr3000837; Tue, 2 Dec 2003 09:11:11 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hB1MAweK000835; Tue, 2 Dec 2003 09:10:58 +1100 Date: Tue, 2 Dec 2003 09:10:58 +1100 From: Nathan Scott To: Marcelo Tosatti Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 Message-ID: <20031201221058.GA621@frodo> References: <20031201062052.GA2022@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hB1MBoTa017695 X-archive-position: 1176 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Mon, Dec 01, 2003 at 12:06:14PM -0200, Marcelo Tosatti wrote: > On Mon, 1 Dec 2003, Nathan Scott wrote: > > > Hi Marcelo, > > > > Please do a > > > > bk pull http://xfs.org:8090/linux-2.4+coreXFS > > > > This will merge the core 2.4 kernel changes required for supporting > > the XFS filesystem, as listed below. If this all looks acceptable, > > then please also pull the filesystem-specific code (fs/xfs/*) > > > > bk pull http://xfs.org:8090/linux-2.4+justXFS > > Nathan, > > I think XFS should be a 2.6 only feature. > > 2.6 is already stable enough for people to use it. > Hi Marcelo, Please reconsider -- the "core" kernel changes we need have existed for three+ years outside of the mainline tree, and each is a small and easily understood change that doesn't affect other filesystems. There is also a VFS fix in there from Ethan Benson, as we discussed during 2.4.23-pre, when you asked us to resend XFS for 2.4.24-pre!) Everything there is a backport from 2.6 in some form, there should be no surprises. Not having XFS in 2.4 is extremely disadvantageous for us XFS folks (especially since every other journaled filesystem has been merged now). To our users it means some rescue disks simply don't support XFS, meaning you can't mount filesystems when you _really_ need to, etc, etc. Its also always extra work for distributors to merge XFS themselves, and hence a few just don't (and occasionally tell us that they are waiting for you to merge it) - which means some users don't even get the option of using XFS, despite our best efforts. From discussions with distributors, a stable 2.6 distribution will be many months after 2.6.0 is officially released, so these issues are not going to go away anytime soon. So, please merge XFS this time round - its actively developed, has a large installed user base, and has been maintained outside of 2.4 for a long time. We have waited patiently as each release goes by for you to give us the nod, and have been knocked back on a number of occasions while various other merges are being done. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Dec 1 14:15:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 14:15:44 -0800 (PST) Received: from smtp001.mail.ukl.yahoo.com (smtp001.mail.ukl.yahoo.com [217.12.11.32]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1MFWTa018161 for ; Mon, 1 Dec 2003 14:15:33 -0800 Received: from ol253-88.fibertel.com.ar (HELO djgera) (vmlinuz386@24.232.88.253 with login) by smtp1.mail.vip.ukl.yahoo.com with SMTP; 1 Dec 2003 22:15:26 -0000 Date: Mon, 1 Dec 2003 19:13:03 -0300 From: Gerardo Exequiel Pozzi To: Bryan Whitehead Cc: yocum@fnal.gov, nathans@sgi.com, marcelo.tosatti@cyclades.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 Message-Id: <20031201191303.201b32c6.vmlinuz386@yahoo.com.ar> In-Reply-To: <3FCBB790.1030503@jpl.nasa.gov> References: <20031201062052.GA2022@frodo> <3FCBABD9.70309@fnal.gov> <3FCBB790.1030503@jpl.nasa.gov> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i486-slackware-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1177 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vmlinuz386@yahoo.com.ar Precedence: bulk X-list: linux-xfs On Mon, 01 Dec 2003 13:50:08 -0800, Bryan Whitehead wrote: >I'd like to "third" this request. Have a large amount of data here on >XFS with v2.4 kernel. > >Would be nice to be able to use pre-release 2.4 for testing without >having to manually hack in XFS paches from SGI for the odd reject... > Yes, exactly. Ok the XFS changes some vfs code, but works OK, and is in the -ac and -ck trees. And another point is make the possiblility to add some patchs such as security without hunks failed, and another funny hacks. And the majority of distros include it. Another vote. chau, djgera >Dan Yocum wrote: >> Marcelo, >> >> We (Fermilab) second this request. We won't be touching 2.6 until it's >> really stable (read as, Red Hat comes out with an official distro that >> has it built in), and we already have *a lot* of XFS filesystems here >> (~>300TB) running on 2.4 kernels. It would be very, very nice to have >> it in the 2.4 tree without having to pull it from SGI. >> >> Thanks, >> Dan >> >> >> Nathan Scott wrote: >> >>> Hi Marcelo, >>> >>> Please do a >>> >>> bk pull http://xfs.org:8090/linux-2.4+coreXFS >>> >>> This will merge the core 2.4 kernel changes required for supporting >>> the XFS filesystem, as listed below. If this all looks acceptable, >>> then please also pull the filesystem-specific code (fs/xfs/*) >>> >>> bk pull http://xfs.org:8090/linux-2.4+justXFS >>> >>> cheers. >>> >> > > >-- >Bryan Whitehead >SysAdmin - JPL - Interferometry and Large Optical Systems >Phone: 818 354 2903 >driver@jpl.nasa.gov -- Gerardo Exequiel Pozzi ( djgera ) http://www.vmlinuz.com.ar http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D From owner-linux-xfs@oss.sgi.com Mon Dec 1 14:20:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 14:20:51 -0800 (PST) Received: from work.bitmover.com (ipcop.bitmover.com [192.132.92.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1MKdTa018616 for ; Mon, 1 Dec 2003 14:20:40 -0800 Received: (from lm@localhost) by work.bitmover.com (8.11.6/8.11.6) id hB1MKP507234; Mon, 1 Dec 2003 14:20:25 -0800 Date: Mon, 1 Dec 2003 14:20:25 -0800 From: Larry McVoy To: Nathan Scott Cc: Marcelo Tosatti , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 Message-ID: <20031201222025.GA6152@work.bitmover.com> Mail-Followup-To: Larry McVoy , Nathan Scott , Marcelo Tosatti , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20031201062052.GA2022@frodo> <20031201221058.GA621@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031201221058.GA621@frodo> User-Agent: Mutt/1.4i X-archive-position: 1178 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lm@bitmover.com Precedence: bulk X-list: linux-xfs On Tue, Dec 02, 2003 at 09:10:58AM +1100, Nathan Scott wrote: > > Nathan, > > > > I think XFS should be a 2.6 only feature. > > > > 2.6 is already stable enough for people to use it. > > > > Hi Marcelo, > > Please reconsider I have no idea if XFS should or should not go in, I'm not commenting on that. However, having a bunch of XFS users say "put it in" when the maintainer said no, DaveM said no, and no other file system people seem to be stepping up to the bat with a review and a nod seems wrong. Have you spoken with the people who maintain the generic parts of the VFS layer that you want to change? If those people were in the list of people saying "XFS should go in" then I think you'd get a lot farther. It's great that there are XFS users but the users should not make the add it or not add it decision, the people who maintain those interfaces which are generic should make that decision. Don't you agree? -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From owner-linux-xfs@oss.sgi.com Mon Dec 1 14:39:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 14:40:07 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1MdjTa019538 for ; Mon, 1 Dec 2003 14:39:46 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hB1KkXOO014743 for ; Mon, 1 Dec 2003 12:46:34 -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 JAA13468; Tue, 2 Dec 2003 09:39:27 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB1MdCUc1954460; Tue, 2 Dec 2003 09:39:12 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hB1Mcxr3000924; Tue, 2 Dec 2003 09:38:59 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hB1McafV000922; Tue, 2 Dec 2003 09:38:36 +1100 Date: Tue, 2 Dec 2003 09:38:36 +1100 From: Nathan Scott To: Chris PeBenito Cc: sandeen@sgi.com, linux-xfs@oss.sgi.com, russell@coker.com.au Subject: Re: [patch] security. namespace Message-ID: <20031201223835.GB621@frodo> References: <1070301662.7842.11.camel@chris.pebenito.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1070301662.7842.11.camel@chris.pebenito.net> User-Agent: Mutt/1.5.3i X-archive-position: 1179 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Hi Chris, Good timing! -- I just had lunch with Russell Coker on Saturday, and afterward I started having a look at this too. On Mon, Dec 01, 2003 at 12:01:02PM -0600, Chris PeBenito wrote: > Here is a patch against -test10 that adds an option for the security. > namespace (controlled by a configure option), which is used by SELinux > to store it's security labels. I created this patch based off Tad > Glines' (tadglines@comcast.net) 2.4 patch > (http://www.glines.com/xfs.patch.bz2). Please critique this, and if its > ok, please consider for inclusion. > > I was warned on #xfs that this may break IRIX compatability, so there is > a note in the Kconfig. However Tad says that the security. attributes > will show up in the user namespace on a standard XFS linux kernel, but I Hmm... security names showing up in the user namespace wouldn't be a good thing... depends how the code is written, I'll take a look shortly. > didn't verify. He also mentioned that xfsdump and xfsrestore would need > to be patched to support this. I don't think the "breaking" IRIX compatibility is a big deal - its not so much "breaking" as just being unsupported, hopefully the IRIX XFS code will deal with this gracefully (i.e. anything but a panic ;), I'll cross check that. Same issue exists in an existing Linux kernel of course, so not just IRIX compatibility we must consider here. We also need to do some cleanup in xfs_iops.c first I think - we are repeating too much stuff there, looks like it can be made a fair bit simpler. I'll send you my changes when I have something that compiles and runs so we can compare notes. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Dec 1 15:01:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 15:02:22 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1N1pTa020326 for ; Mon, 1 Dec 2003 15:01:52 -0800 Received: (qmail 5066 invoked from network); 1 Dec 2003 23:01:48 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 1 Dec 2003 23:01:48 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 919DEC00AD; Tue, 2 Dec 2003 10:01:47 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 8ECDF140093; Tue, 2 Dec 2003 10:01:47 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Net Llama! Cc: linux-xfs@oss.sgi.com Subject: Re: Announce: XFS split patches for 2.4.23 In-reply-to: Your message of "Mon, 01 Dec 2003 16:24:02 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Dec 2003 10:01:46 +1100 Message-ID: <6810.1070319706@ocs3.intra.ocs.com.au> X-archive-position: 1180 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 1 Dec 2003 16:24:02 -0500 (EST), Net Llama! wrote: >On Mon, 1 Dec 2003, Keith Owens wrote: >> ftp://oss.sgi.com/projects/xfs/download/patches/2.4.23. > >Anyone else getting bizarro errors when trying to download anything from >this directory? > >I can run 'ls' on it and see everything, but if I try to perform a GET, i >end up with: >No such file `xfs-2.4.23-all-i386.bz2' > >Actually, nevermind, i see the reason (using ncftp): >get xfs-2.4.23-all-i386.bz2: server said: The load was 5.82 when you >connected. We do not allow downloads Try again, the load is < 1 right now. From owner-linux-xfs@oss.sgi.com Mon Dec 1 15:57:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 15:57:43 -0800 (PST) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB1NvMTa023266 for ; Mon, 1 Dec 2003 15:57:22 -0800 Received: from adsl-67-123-174-79.dsl.sntc01.pacbell.net ([67.123.174.79]:61341 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 1AQxuL-0007e3-L3 by VAauthid with fixed_plain; Mon, 01 Dec 2003 15:56:49 -0800 Message-ID: <3FCBD535.7010104@linux-sxs.org> Date: Mon, 01 Dec 2003 15:56:37 -0800 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031125 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com Subject: Re: Announce: XFS split patches for 2.4.23 References: <6810.1070319706@ocs3.intra.ocs.com.au> In-Reply-To: <6810.1070319706@ocs3.intra.ocs.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 1AQxuL-0007e3-L3 de12449f8b8c641b7e440f8a95f78173 X-Spam-Score: -102.1 (---------------------------------------------------) X-archive-position: 1181 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs On 12/01/03 15:01, Keith Owens wrote: > On Mon, 1 Dec 2003 16:24:02 -0500 (EST), > Net Llama! wrote: > >>On Mon, 1 Dec 2003, Keith Owens wrote: >> >>>ftp://oss.sgi.com/projects/xfs/download/patches/2.4.23. >> >>Anyone else getting bizarro errors when trying to download anything from >>this directory? >> >>I can run 'ls' on it and see everything, but if I try to perform a GET, i >>end up with: >>No such file `xfs-2.4.23-all-i386.bz2' >> >>Actually, nevermind, i see the reason (using ncftp): >>get xfs-2.4.23-all-i386.bz2: server said: The load was 5.82 when you >>connected. We do not allow downloads > > > Try again, the load is < 1 right now. > Yup, works fine now. thanks. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 3:55pm up 3 days, 23:32, 1 user, load average: 0.22, 0.13, 0.07 From owner-linux-xfs@oss.sgi.com Mon Dec 1 16:24:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 16:25:04 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB20OqTa028117 for ; Mon, 1 Dec 2003 16:24:52 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hB20jiHc024962 for ; Mon, 1 Dec 2003 18:45: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 LAA15210; Tue, 2 Dec 2003 11:24:38 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB20OGUc1929053; Tue, 2 Dec 2003 11:24:16 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hB20O1r3001241; Tue, 2 Dec 2003 11:24:02 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hB20Nl43001239; Tue, 2 Dec 2003 11:23:47 +1100 Date: Tue, 2 Dec 2003 11:23:47 +1100 From: Nathan Scott To: Larry McVoy , Marcelo Tosatti Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 Message-ID: <20031202002347.GD621@frodo> References: <20031201062052.GA2022@frodo> <20031201221058.GA621@frodo> <20031201222025.GA6152@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031201222025.GA6152@work.bitmover.com> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hB20OrTa028118 X-archive-position: 1182 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Hello Larry, On Mon, Dec 01, 2003 at 02:20:25PM -0800, Larry McVoy wrote: > > I have no idea if XFS should or should not go in, I'm not commenting on that. > > However, having a bunch of XFS users say "put it in" when the maintainer > said no, DaveM said no, and no other file system people seem to be > stepping up to the bat with a review and a nod seems wrong. I must have missed that mail from Dave - or perhaps its still in flight to me. If you're refering to his "super-maintainence mode" comment, I don't believe there was any specific comments relating to XFS there (and XFS on 2.4 is in maintenance mode, has been for a long time). I also have mail from Marcelo saying he would look at merging XFS in 2.4.24-pre (back when we last sent it, in 2.4.23-pre) ... so, obviously I'm a little confused by this turn of events. > Have you spoken with the people who maintain the generic parts of the > VFS layer that you want to change? If those people were in the list of > people saying "XFS should go in" then I think you'd get a lot farther. That level of discussion with other kernel coders, and extensive review _has_ happened, in many cases _years_ ago now - this stuff has all been merged in 2.5 for ages. I wouldn't expect discussion from other filesystem people at this stage - it is all old news to them. > ... the people who maintain those interfaces which > are generic should make that decision. Don't you agree? Of course, and they have agreed that these are the way the changes should be made - if you look at 2.6 you will see these changes all merged there, a long time ago. As I said, there is nothing new or surprising here, and the changes are small and such that the other filesystems are unaffected. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Dec 1 21:39:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 21:39:36 -0800 (PST) Received: from ns.sws.net.au (ns.sws.net.au [61.95.69.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB25dNTa003717 for ; Mon, 1 Dec 2003 21:39:24 -0800 Received: from localhost (localhost [127.0.0.1]) by ns.sws.net.au (Postfix) with ESMTP id 63B5361BF1; Tue, 2 Dec 2003 16:39:21 +1100 (EST) Received: from ns.sws.net.au ([127.0.0.1]) by localhost (ns [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04938-02; Tue, 2 Dec 2003 16:39:20 +1100 (EST) Received: from tsv.sws.net.au (tsv.sws.net.au [61.95.69.2]) by ns.sws.net.au (Postfix) with ESMTP id BCCD861BF0; Tue, 2 Dec 2003 16:39:20 +1100 (EST) Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id 8AD2C9268A; Tue, 2 Dec 2003 16:39:20 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with ESMTP id 8BC757F26F; Tue, 2 Dec 2003 16:39:18 +1100 (EST) From: Russell Coker Reply-To: russell@coker.com.au To: Nathan Scott , Chris PeBenito Subject: Re: [patch] security. namespace Date: Tue, 2 Dec 2003 16:39:18 +1100 User-Agent: KMail/1.5.4 Cc: sandeen@sgi.com, linux-xfs@oss.sgi.com References: <1070301662.7842.11.camel@chris.pebenito.net> <20031201223835.GB621@frodo> In-Reply-To: <20031201223835.GB621@frodo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312021639.18100.russell@coker.com.au> X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at sws.net.au X-archive-position: 1183 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: russell@coker.com.au Precedence: bulk X-list: linux-xfs On Tue, 2 Dec 2003 09:38, Nathan Scott wrote: > > I was warned on #xfs that this may break IRIX compatability, so there is > > a note in the Kconfig. However Tad says that the security. attributes > > will show up in the user namespace on a standard XFS linux kernel, but I > > Hmm... security names showing up in the user namespace wouldn't > be a good thing... depends how the code is written, I'll take a > look shortly. It is a good thing for upgrades. If we can set the security attributes on files before booting the SE Linux kernel then it will make things a bit easier for a first install. As 2.4.22 is bad it would be good to see some ACL patches for 2.4.23 soon. I've done my own port of them and put them on http://www.coker.com.au/selinux/kern/ Russell Coker From owner-linux-xfs@oss.sgi.com Mon Dec 1 22:06:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Dec 2003 22:06:46 -0800 (PST) Received: from smtp1.iitb.ac.in ([203.199.51.149]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB266XTa004420 for ; Mon, 1 Dec 2003 22:06:34 -0800 Received: (qmail 15552 invoked by uid 505); 2 Dec 2003 06:07:58 -0000 Received: from soumen@cse.iitb.ac.in by smtp1.iitb.ac.in by uid 502 with qmail-scanner-1.16 (clamscan: 0.54. spamassassin: 2.54. Clear:. Processed in 0.662164 secs); 02 Dec 2003 06:07:58 -0000 Received: from unknown (HELO jeeves.cse.iitb.ac.in) (10.105.1.1) by smtp1.iitb.ac.in with SMTP; 2 Dec 2003 06:07:57 -0000 Received: from surya.cse.iitb.ac.in (surya.cse.iitb.ac.in [10.105.1.14]) by jeeves.cse.iitb.ac.in (8.11.0/8.11.0) with ESMTP id hB266UT24008; Tue, 2 Dec 2003 11:36:30 +0530 Received: from cse.iitb.ac.in (focus.cse.iitb.ac.in [10.105.5.44]) by surya.cse.iitb.ac.in (8.8.8/8.8.8) with ESMTP id LAA07894; Tue, 2 Dec 2003 11:36:35 +0530 (IST) Message-ID: <3FCC2BE6.30807@cse.iitb.ac.in> Date: Tue, 02 Dec 2003 11:36:30 +0530 From: Soumen Chakrabarti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out References: <3FC6E5C4.2080009@cse.iitb.ac.in> <1070295327.28534.2.camel@stout.americas.sgi.com> In-Reply-To: <1070295327.28534.2.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1184 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: soumen@cse.iitb.ac.in Precedence: bulk X-list: linux-xfs > On Fri, 2003-11-28 at 00:05, Soumen Chakrabarti wrote: >>I downloaded the patch around 10/15, from this URL: >>ftp://oss.sgi.com/projects/xfs/patches/2.4.22 >>which seems to indicate that even on that date, there was a patch >>available for 2.4.22 (maybe I looked where I should not). The above patch version/snapshot has the problem I posted earlier. But with ikeep I have not hit a problem up to 300*1024 files. Could not experiment with my original RAID array because that's in production; I tested with a smaller loop dev. BTW, I rolled back to kernel 2.4.21 and applied these two patches: ftp://oss.sgi.com/projects/xfs/Release-1.3.1/kernel_patches/linux-2.4.21-core-xfs-1.3.1.patch.gz ftp://oss.sgi.com/projects/xfs/Release-1.3.1/kernel_patches/linux-xfs-1.3.1.patch.gz and everything is fine, I have tested with Bonnie++ up to 600,000 files. As you know, sudden power failure can lead to zeroed out blocks in XFS. Is there any tuning option to reduce the cache flush time or force journaling of data as well as metadata? Thanks a lot for your help! From owner-linux-xfs@oss.sgi.com Tue Dec 2 00:05:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 00:05:48 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB285PTa006942 for ; Tue, 2 Dec 2003 00:05:25 -0800 Received: (qmail 18286 invoked by uid 1000); 2 Dec 2003 10:05:25 +0200 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Dec 2003 10:05:25 +0200 Date: Tue, 2 Dec 2003 10:05:22 +0200 (EET) From: Mihai RUSU X-X-Sender: dizzy@ahriman.bucharest.roedu.net To: Soumen Chakrabarti cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out In-Reply-To: <3FCC2BE6.30807@cse.iitb.ac.in> Message-ID: References: <3FC6E5C4.2080009@cse.iitb.ac.in> <1070295327.28534.2.camel@stout.americas.sgi.com> <3FCC2BE6.30807@cse.iitb.ac.in> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1185 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 2 Dec 2003, Soumen Chakrabarti wrote: > BTW, I rolled back to kernel 2.4.21 and applied these two patches: > ftp://oss.sgi.com/projects/xfs/Release-1.3.1/kernel_patches/linux-2.4.21-core-xfs-1.3.1.patch.gz > ftp://oss.sgi.com/projects/xfs/Release-1.3.1/kernel_patches/linux-xfs-1.3.1.patch.gz > and everything is fine, I have tested with Bonnie++ up to 600,000 files. What about the brk() integer overflow bug of which I found out recently ? Seems to be fixed between 2.4.22 and 2.4.23. As the Debian guys say there seems to be an exploit in the wild already. Has anyone a patch against 2.4.21 (/w XFS 1.3.1) for this one ? Otherwise I cannot use 2.4.21 ... :-/ Thanks - -- Mihai RUSU Email: dizzy@roedu.net GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net "Linux is obsolete" -- AST -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/zEfEPZzOzrZY/1QRAv29AKC3kTcJw3kgwg6VJvaH+qPef3p7iwCgxuWT mxAdFfr9wN3q9wSU5b0DgGw= =VWFh -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Dec 2 00:14:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 00:14:43 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB28ELTa007806 for ; Tue, 2 Dec 2003 00:14:21 -0800 Received: (qmail 18370 invoked by uid 1000); 2 Dec 2003 10:14:21 +0200 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Dec 2003 10:14:21 +0200 Date: Tue, 2 Dec 2003 10:14:16 +0200 (EET) From: Mihai RUSU X-X-Sender: dizzy@ahriman.bucharest.roedu.net To: Soumen Chakrabarti cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out In-Reply-To: Message-ID: References: <3FC6E5C4.2080009@cse.iitb.ac.in> <1070295327.28534.2.camel@stout.americas.sgi.com> <3FCC2BE6.30807@cse.iitb.ac.in> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1186 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Whoops, I just found this on another list: http://linux.bkbits.net:8080/linux-2.4/diffs/mm/mmap.c@1.32?nav=cset@1.1148.2.2 Whoud someone with kernel knowledge confirm this is the right fix and also that it shouldnt brake anything XFS related ? Thanks! On Tue, 2 Dec 2003, Mihai RUSU wrote: > What about the brk() integer overflow bug of which I found out recently ? > Seems to be fixed between 2.4.22 and 2.4.23. As the Debian guys say there > seems to be an exploit in the wild already. Has anyone a patch against > 2.4.21 (/w XFS 1.3.1) for this one ? Otherwise I cannot use 2.4.21 ... :-/ - -- Mihai RUSU Email: dizzy@roedu.net GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net "Linux is obsolete" -- AST -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/zEndPZzOzrZY/1QRAhUyAJsG1avwQYBADfMerXnOJRJRGT8pywCeNVKh JD722fNOn4FuM3VfxLjP454= =JmsI -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Dec 2 01:20:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 01:20:41 -0800 (PST) Received: from malik.acsalaska.net (malik.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB29KBTa011977 for ; Tue, 2 Dec 2003 01:20:11 -0800 Received: from erbenson.alaska.net (230-pm16.nwc.alaska.net [209.112.141.230]) by malik.acsalaska.net (8.12.10/8.12.10) with ESMTP id hB29K5eV003101; Tue, 2 Dec 2003 00:20:05 -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 B05AD39E5; Tue, 2 Dec 2003 00:20:03 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 3862240FF35; Tue, 2 Dec 2003 00:20:04 -0900 (AKST) Date: Tue, 2 Dec 2003 00:20:04 -0900 From: Ethan Benson To: Nathan Scott Cc: Marcelo Tosatti , linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 Message-ID: <20031202092004.GA962@plato.local.lan> Mail-Followup-To: Nathan Scott , Marcelo Tosatti , linux-xfs@oss.sgi.com References: <20031201062052.GA2022@frodo> <20031201221058.GA621@frodo> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <20031201221058.GA621@frodo> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: erbenson@alaska.net X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.58 X-archive-position: 1187 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 02, 2003 at 09:10:58AM +1100, Nathan Scott wrote: >=20 > Hi Marcelo, >=20 > Please reconsider -- the "core" kernel changes we need have existed > for three+ years outside of the mainline tree, and each is a small > and easily understood change that doesn't affect other filesystems. > There is also a VFS fix in there from Ethan Benson, as we discussed > during 2.4.23-pre, when you asked us to resend XFS for 2.4.24-pre!) > Everything there is a backport from 2.6 in some form, there should > be no surprises. that VFS fix has also been blessed by Linus, and is in 2.6, so thats a backport now. and its security related. > Not having XFS in 2.4 is extremely disadvantageous for us XFS folks > (especially since every other journaled filesystem has been merged > now). To our users it means some rescue disks simply don't support > XFS, meaning you can't mount filesystems when you _really_ need to, > etc, etc. Its also always extra work for distributors to merge XFS > themselves, and hence a few just don't (and occasionally tell us > that they are waiting for you to merge it) - which means some users > don't even get the option of using XFS, despite our best efforts. >=20 > >From discussions with distributors, a stable 2.6 distribution will > be many months after 2.6.0 is officially released, so these issues > are not going to go away anytime soon. >=20 > So, please merge XFS this time round - its actively developed, has > a large installed user base, and has been maintained outside of 2.4 > for a long time. We have waited patiently as each release goes by > for you to give us the nod, and have been knocked back on a number > of occasions while various other merges are being done. Another point, 2.6 is not yet stable or fully usuable on many non-x86 architectures, such as powerpc. I can tell you there are a significant number of XFS users in the powerpc space, the reason is simply that the users have found it to be the most reliable and solid filesystem available, more reliable then ext3, and reiserfs (ESPECIALLY reiserfs which is notorious for destroying entire volumes with no prior warning, and was compleltly unusable for quite some time do to its complete lack of regard for portability). I myself have used XFS almost exclusivly for quite some time now on both x86 and powerpc, including on a production server (a powerpc at that). Its solid, its reliable, its proven, and it belongs in 2.4. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --5vNYLRcllDrimb99 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 iEYEARECAAYFAj/MWUMACgkQJKx7GixEevzOzwCfVYxsltzOwpGrwIu/U4Rt/Axa l8gAnRXYTeHmpgMjtddPpLZ0KZcETH5R =53ju -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From owner-linux-xfs@oss.sgi.com Tue Dec 2 01:28:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 01:29:10 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB29SlTa012487 for ; Tue, 2 Dec 2003 01:28:47 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.22) id 1AR6pl-0005DZ-6t; Tue, 02 Dec 2003 09:28:41 +0000 Date: Tue, 2 Dec 2003 09:28:41 +0000 From: Christoph Hellwig To: Nathan Scott , Marcelo Tosatti , linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 Message-ID: <20031202092841.A20058@infradead.org> References: <20031201062052.GA2022@frodo> <20031201221058.GA621@frodo> <20031202092004.GA962@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031202092004.GA962@plato.local.lan>; from erbenson@alaska.net on Tue, Dec 02, 2003 at 12:20:04AM -0900 X-archive-position: 1188 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Tue, Dec 02, 2003 at 12:20:04AM -0900, Ethan Benson wrote: > Another point, 2.6 is not yet stable or fully usuable on many non-x86 > architectures, such as powerpc. 2.6 seems to be much better than 2.4 at least for recent pmac hardware.. From owner-linux-xfs@oss.sgi.com Tue Dec 2 03:05:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 03:05:59 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2B5aTa018584 for ; Tue, 2 Dec 2003 03:05:37 -0800 Received: (qmail 8407 invoked from network); 2 Dec 2003 11:05:33 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Dec 2003 11:05:33 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 48D53C00AD; Tue, 2 Dec 2003 22:05:31 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 45F5A140683; Tue, 2 Dec 2003 22:05:31 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Mihai RUSU Cc: Soumen Chakrabarti , linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out In-Reply-To: Your message of "Tue, 02 Dec 2003 10:14:16 +0200." Date: Tue, 02 Dec 2003 22:05:30 +1100 Message-ID: <1985.1070363130@ocs3.intra.ocs.com.au> X-archive-position: 1189 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii On Tue, 2 Dec 2003 10:14:16 +0200 (EET), Mihai RUSU wrote: >Whoops, I just found this on another list: >http://linux.bkbits.net:8080/linux-2.4/diffs/mm/mmap.c@1.32?nav=cset@1.1148.2.2 > >Whoud someone with kernel knowledge confirm this is the right fix and also >that it shouldnt brake anything XFS related ? Thanks! That fix is already in the XFS CVS tree, which is based on 2.4.23. The fix can go into any kernel >= 2.4.21 (did not check any further back). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE/zHH6i4UHNye0ZOoRAuHpAKCkglxUkHB/d3MXMZEli52LF1SDIwCffUm6 g/C0YmWs2b0qQGi8BXao1Uk= =QMj9 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Dec 2 03:34:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 03:34:35 -0800 (PST) Received: from intra.cyclades.com (intra.cyclades.com [64.186.161.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2BY4Ta020162 for ; Tue, 2 Dec 2003 03:34:06 -0800 Received: from intra.cyclades.com (localhost.localdomain [127.0.0.1]) by intra.cyclades.com (Postfix) with SMTP id 522262DC5E4; Tue, 2 Dec 2003 03:33:20 -0800 (PST) Received: from cm-net-poa-C8B02617.brdterra.com.br (cm-net-poa-C8B02617.brdterra.com.br [200.176.38.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by intra.cyclades.com (Postfix) with ESMTP id F15562DC728; Tue, 2 Dec 2003 03:20:41 -0800 (PST) Date: Tue, 2 Dec 2003 09:18:26 -0200 (BRST) From: Marcelo Tosatti X-X-Sender: marcelo@logos.cnet To: Nathan Scott Cc: Marcelo Tosatti , , , Andrew Morton Subject: Re: XFS for 2.4 In-Reply-To: <20031201221058.GA621@frodo> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1191 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marcelo.tosatti@cyclades.com Precedence: bulk X-list: linux-xfs On Tue, 2 Dec 2003, Nathan Scott wrote: > On Mon, Dec 01, 2003 at 12:06:14PM -0200, Marcelo Tosatti wrote: > > On Mon, 1 Dec 2003, Nathan Scott wrote: > > > > > Hi Marcelo, > > > > > > Please do a > > > > > > bk pull http://xfs.org:8090/linux-2.4+coreXFS > > > > > > This will merge the core 2.4 kernel changes required for supporting > > > the XFS filesystem, as listed below. If this all looks acceptable, > > > then please also pull the filesystem-specific code (fs/xfs/*) > > > > > > bk pull http://xfs.org:8090/linux-2.4+justXFS > > > > Nathan, > > > > I think XFS should be a 2.6 only feature. > > > > 2.6 is already stable enough for people to use it. > > > > Hi Marcelo, > > Please reconsider -- the "core" kernel changes we need have existed > for three+ years outside of the mainline tree, and each is a small > and easily understood change that doesn't affect other filesystems. > There is also a VFS fix in there from Ethan Benson, as we discussed > during 2.4.23-pre, when you asked us to resend XFS for 2.4.24-pre!) > Everything there is a backport from 2.6 in some form, there should > be no surprises. Nathan, I remember I have said to you "resend me XFS for 2.4.24-pre". A changed my mind since then... > Not having XFS in 2.4 is extremely disadvantageous for us XFS folks > (especially since every other journaled filesystem has been merged > now). JFS did not touch generic code as I remember. > To our users it means some rescue disks simply don't support > XFS, meaning you can't mount filesystems when you _really_ need to, > etc, etc. Its also always extra work for distributors to merge XFS > themselves, and hence a few just don't (and occasionally tell us > that they are waiting for you to merge it) - which means some users > don't even get the option of using XFS, despite our best efforts. Come one, it is not so hard to maintain a patch in a distros kernel. Distros maintain hundreds of patches (even I did maintain hundreds of patches while maintaining Conectiva's RPM). One more patch is not that hard. > From discussions with distributors, a stable 2.6 distribution will > be many months after 2.6.0 is officially released, so these issues > are not going to go away anytime soon. Fine, so people who want XFS go compile 2.6.0 by hand. I'm using test11 on several boxes and its working very well. And 2.6 is much nicer than 2.4 anyway. > So, please merge XFS this time round - its actively developed, has > a large installed user base, and has been maintained outside of 2.4 > for a long time. We have waited patiently as each release goes by > for you to give us the nod, and have been knocked back on a number > of occasions while various other merges are being done. Also I'm not completly sure if the generic changes are fine and I dont like the XFS code in general. From owner-linux-xfs@oss.sgi.com Tue Dec 2 03:34:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 03:34:35 -0800 (PST) Received: from intra.cyclades.com (intra.cyclades.com [64.186.161.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2BY7Ta020163 for ; Tue, 2 Dec 2003 03:34:07 -0800 Received: from intra.cyclades.com (localhost.localdomain [127.0.0.1]) by intra.cyclades.com (Postfix) with SMTP id 6746E2DC733; Tue, 2 Dec 2003 03:33:29 -0800 (PST) Received: from cm-net-poa-C8B02617.brdterra.com.br (cm-net-poa-C8B02617.brdterra.com.br [200.176.38.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by intra.cyclades.com (Postfix) with ESMTP id 87E6A2DC15E; Tue, 2 Dec 2003 03:25:04 -0800 (PST) Date: Tue, 2 Dec 2003 09:22:48 -0200 (BRST) From: Marcelo Tosatti X-X-Sender: marcelo@logos.cnet To: Nathan Scott Cc: Larry McVoy , Marcelo Tosatti , , Subject: Re: XFS for 2.4 In-Reply-To: <20031202002347.GD621@frodo> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1190 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marcelo.tosatti@cyclades.com Precedence: bulk X-list: linux-xfs On Tue, 2 Dec 2003, Nathan Scott wrote: > Hello Larry, > > On Mon, Dec 01, 2003 at 02:20:25PM -0800, Larry McVoy wrote: > > > > I have no idea if XFS should or should not go in, I'm not commenting on that. > > > > However, having a bunch of XFS users say "put it in" when the maintainer > > said no, DaveM said no, and no other file system people seem to be > > stepping up to the bat with a review and a nod seems wrong. > > I must have missed that mail from Dave - or perhaps its still > in flight to me. If you're refering to his "super-maintainence > mode" comment, I don't believe there was any specific comments > relating to XFS there (and XFS on 2.4 is in maintenance mode, > has been for a long time). > > I also have mail from Marcelo saying he would look at merging XFS > in 2.4.24-pre (back when we last sent it, in 2.4.23-pre) ... so, > obviously I'm a little confused by this turn of events. Nathan, Yes, I indeed told you "resent me for 2.4.24-pre". I have changed my mind. Sorry for the trouble that caused you. > That level of discussion with other kernel coders, and extensive > review _has_ happened, in many cases _years_ ago now - this stuff > has all been merged in 2.5 for ages. I wouldn't expect discussion > from other filesystem people at this stage - it is all old news to > them. > > > ... the people who maintain those interfaces which > > are generic should make that decision. Don't you agree? > > Of course, and they have agreed that these are the way the changes > should be made - if you look at 2.6 you will see these changes all > merged there, a long time ago. As I said, there is nothing new or > surprising here, and the changes are small and such that the other > filesystems are unaffected. A development tree is much different from a stable tree. You cant just simply backport generic VFS changes just because everybody agreed with them on the development tree. My whole point is "2.6 is almost out of the door and its so much better". Its much faster, much cleaner. From owner-linux-xfs@oss.sgi.com Tue Dec 2 03:51:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 03:51:55 -0800 (PST) Received: from intra.cyclades.com (intra.cyclades.com [64.186.161.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2BpbTa021117 for ; Tue, 2 Dec 2003 03:51:37 -0800 Received: from intra.cyclades.com (localhost.localdomain [127.0.0.1]) by intra.cyclades.com (Postfix) with SMTP id 53A872DC1EE; Tue, 2 Dec 2003 03:50:52 -0800 (PST) Received: from cm-net-poa-C8B02617.brdterra.com.br (cm-net-poa-C8B02617.brdterra.com.br [200.176.38.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by intra.cyclades.com (Postfix) with ESMTP id 25D1D2DC2B7; Tue, 2 Dec 2003 03:50:50 -0800 (PST) Date: Tue, 2 Dec 2003 09:48:34 -0200 (BRST) From: Marcelo Tosatti X-X-Sender: marcelo@logos.cnet To: Marcelo Tosatti Cc: Nathan Scott , , , Andrew Morton Subject: Re: XFS for 2.4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1192 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marcelo.tosatti@cyclades.com Precedence: bulk X-list: linux-xfs On Tue, 2 Dec 2003, Marcelo Tosatti wrote: > > > On Tue, 2 Dec 2003, Nathan Scott wrote: > > > On Mon, Dec 01, 2003 at 12:06:14PM -0200, Marcelo Tosatti wrote: > > > On Mon, 1 Dec 2003, Nathan Scott wrote: > > > > > > > Hi Marcelo, > > > > > > > > Please do a > > > > > > > > bk pull http://xfs.org:8090/linux-2.4+coreXFS > > > > > > > > This will merge the core 2.4 kernel changes required for supporting > > > > the XFS filesystem, as listed below. If this all looks acceptable, > > > > then please also pull the filesystem-specific code (fs/xfs/*) > > > > > > > > bk pull http://xfs.org:8090/linux-2.4+justXFS > > > > > > Nathan, > > > > > > I think XFS should be a 2.6 only feature. > > > > > > 2.6 is already stable enough for people to use it. > > > > > > > Hi Marcelo, > > > > Please reconsider -- the "core" kernel changes we need have existed > > for three+ years outside of the mainline tree, and each is a small > > and easily understood change that doesn't affect other filesystems. > > There is also a VFS fix in there from Ethan Benson, as we discussed > > during 2.4.23-pre, when you asked us to resend XFS for 2.4.24-pre!) > > Everything there is a backport from 2.6 in some form, there should > > be no surprises. > > Nathan, > > I remember I have said to you "resend me XFS for 2.4.24-pre". A changed my > mind since then... > > > Not having XFS in 2.4 is extremely disadvantageous for us XFS folks > > (especially since every other journaled filesystem has been merged > > now). > > JFS did not touch generic code as I remember. > > > To our users it means some rescue disks simply don't support > > XFS, meaning you can't mount filesystems when you _really_ need to, > > etc, etc. Its also always extra work for distributors to merge XFS > > themselves, and hence a few just don't (and occasionally tell us > > that they are waiting for you to merge it) - which means some users > > don't even get the option of using XFS, despite our best efforts. > > Come one, it is not so hard to maintain a patch in a distros kernel. s/one/on/ Ugh From owner-linux-xfs@oss.sgi.com Tue Dec 2 04:07:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 04:07:45 -0800 (PST) Received: from malik.acsalaska.net (malik.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2C7GTa022196 for ; Tue, 2 Dec 2003 04:07:18 -0800 Received: from erbenson.alaska.net (230-pm16.nwc.alaska.net [209.112.141.230]) by malik.acsalaska.net (8.12.10/8.12.10) with ESMTP id hB2C74eV005285; Tue, 2 Dec 2003 03:07:08 -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 DA2C83A06; Tue, 2 Dec 2003 03:06:42 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 5D1FA40FF35; Tue, 2 Dec 2003 03:06:42 -0900 (AKST) Date: Tue, 2 Dec 2003 03:06:42 -0900 From: Ethan Benson To: Marcelo Tosatti Cc: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 Message-ID: <20031202120642.GC962@plato.local.lan> Mail-Followup-To: Marcelo Tosatti , Nathan Scott , linux-xfs@oss.sgi.com References: <20031202002347.GD621@frodo> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GPJrCs/72TxItFYR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: erbenson@alaska.net X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.58 X-archive-position: 1193 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --GPJrCs/72TxItFYR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 02, 2003 at 09:22:48AM -0200, Marcelo Tosatti wrote: >=20 > My whole point is "2.6 is almost out of the door and its so much better".= =20=20 > Its much faster, much cleaner.=20 2.6.10 is NOT almost out the door, and the fact is a great many are not going to trust it till then. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --GPJrCs/72TxItFYR 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 iEYEARECAAYFAj/MgFIACgkQJKx7GixEevy1NwCgmiSdU/xGqN2Olt1D/sVysxEg LxYAn0uGxXojko5OKHUpoVfvjPcV6KAv =oOIZ -----END PGP SIGNATURE----- --GPJrCs/72TxItFYR-- From owner-linux-xfs@oss.sgi.com Tue Dec 2 07:39:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 07:39:35 -0800 (PST) Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2FdDTa009691 for ; Tue, 2 Dec 2003 07:39:13 -0800 Received: from [24.118.170.148] (c-24-118-170-148.mn.client2.attbi.com [24.118.170.148]) by lips.borg.umn.edu (8.12.10/8.12.10) with ESMTP id hB2Fd2XI041208; Tue, 2 Dec 2003 09:39:03 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: XFS for 2.4 From: Russell Cattelan To: Marcelo Tosatti Cc: Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton In-Reply-To: References: Content-Type: text/plain Message-Id: <1070379282.82397.29.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 02 Dec 2003 09:34:43 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1194 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs On Tue, 2003-12-02 at 05:18, Marcelo Tosatti wrote: [snip] > Also I'm not completly sure if the generic changes are fine and I dont > like the XFS code in general. Ahh so the real truth comes out. Is there a reason for your sudden dislike of the XFS code? or is this just an arbitrary general dislike for unknown or unstated reasons? -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Tue Dec 2 07:58:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 07:58:51 -0800 (PST) Received: from intra.cyclades.com (intra.cyclades.com [64.186.161.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2FwSTa011367 for ; Tue, 2 Dec 2003 07:58:28 -0800 Received: from intra.cyclades.com (localhost.localdomain [127.0.0.1]) by intra.cyclades.com (Postfix) with SMTP id 2B5292DC490; Tue, 2 Dec 2003 07:57:11 -0800 (PST) Received: from cm-net-poa-C8B02617.brdterra.com.br (cm-net-poa-C8B02617.brdterra.com.br [200.176.38.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by intra.cyclades.com (Postfix) with ESMTP id 1903A2DC7D9; Tue, 2 Dec 2003 07:52:23 -0800 (PST) Date: Tue, 2 Dec 2003 13:50:08 -0200 (BRST) From: Marcelo Tosatti X-X-Sender: marcelo@logos.cnet To: Russell Cattelan Cc: Marcelo Tosatti , Nathan Scott , , , Andrew Morton Subject: Re: XFS for 2.4 In-Reply-To: <1070379282.82397.29.camel@lupo.thebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1195 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marcelo.tosatti@cyclades.com Precedence: bulk X-list: linux-xfs On Tue, 2 Dec 2003, Russell Cattelan wrote: > On Tue, 2003-12-02 at 05:18, Marcelo Tosatti wrote: > [snip] > > Also I'm not completly sure if the generic changes are fine and I dont > > like the XFS code in general. > Ahh so the real truth comes out. > > > Is there a reason for your sudden dislike of the XFS code? I always disliked the XFS code. > or is this just an arbitrary general dislike for unknown or unstated > reasons? I dont like the style of the code. Thats a personal issue, though, and shouldnt matter. The bigger point is that XFS touches generic code and I'm not sure if that can break something. Why it matters so much for you to have XFS in 2.4 ? From owner-linux-xfs@oss.sgi.com Tue Dec 2 08:11:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 08:11:33 -0800 (PST) Received: from nuttfield.wsicorp.com (wsi-204-189.wsi.com [4.36.204.189]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2GBLTa011966 for ; Tue, 2 Dec 2003 08:11:22 -0800 Received: from atherne.wsicorp.com (atherne.wsicorp.com [147.81.84.101]) by nuttfield.wsicorp.com (8.11.6/8.9.3) with ESMTP id hB2GAi406366; Tue, 2 Dec 2003 11:10:44 -0500 Subject: Re: XFS for 2.4 From: Darrell Michaud To: Marcelo Tosatti Cc: Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1070381443.5316.260.camel@atherne> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 02 Dec 2003 11:10:43 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1196 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dmichaud@wsi.com Precedence: bulk X-list: linux-xfs As a user it would be very beneficial for me to have XFS support in the official 2.4 kernel tree. XFS been stable and "2.4 integration-ready" for a long time, and 2.4 is going to be used in certain environments for a long time, if only because it's easier to upgrade a 2.4 kernel to a newer 2.4 kernel than to upgrade to a 2.6 kernel. It seems like an easy case to make. I use other filesystems and some funky drivers as well.. and I'm always very happy to see useful backports show up in the 2.4 tree. Thank you! On Tue, 2003-12-02 at 10:50, Marcelo Tosatti wrote: > On Tue, 2 Dec 2003, Russell Cattelan wrote: > > > On Tue, 2003-12-02 at 05:18, Marcelo Tosatti wrote: > > [snip] > > > Also I'm not completly sure if the generic changes are fine and I dont > > > like the XFS code in general. > > Ahh so the real truth comes out. > > > > > > Is there a reason for your sudden dislike of the XFS code? > > I always disliked the XFS code. > > > or is this just an arbitrary general dislike for unknown or unstated > > reasons? > > I dont like the style of the code. Thats a personal issue, though, and > shouldnt matter. > > The bigger point is that XFS touches generic code and I'm not sure if that > can break something. > > Why it matters so much for you to have XFS in 2.4 ? > -- Darrell Michaud From owner-linux-xfs@oss.sgi.com Tue Dec 2 08:15:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 08:15:50 -0800 (PST) Received: from hoby.coplanar.net (CPE0020afeeb1ac-CM014250013274.cpe.net.cable.rogers.com [24.114.21.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2GFcTa012771 for ; Tue, 2 Dec 2003 08:15:39 -0800 Received: from coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) (authenticated bits=0) by hoby.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hB2GFOCE008125 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 2 Dec 2003 11:15:28 -0500 Message-ID: <3FCCB8F9.1080302@coplanar.net> Date: Tue, 02 Dec 2003 11:08:25 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Ethan Benson CC: Marcelo Tosatti , Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 References: <20031202002347.GD621@frodo> <20031202120642.GC962@plato.local.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1197 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs One example is EVMS (device-mapper) snapshots. Not stable in 2.6, yet related to XFS. It would be nice if the XFS team could maintain patches for newer 2.4 kernels of official releases (ie 1.3.1). This would ease the tension somewhat. Regards, Jeremy Jackson Ethan Benson wrote: > On Tue, Dec 02, 2003 at 09:22:48AM -0200, Marcelo Tosatti wrote: > >>My whole point is "2.6 is almost out of the door and its so much better". >>Its much faster, much cleaner. > > > 2.6.10 is NOT almost out the door, and the fact is a great many are > not going to trust it till then. > From owner-linux-xfs@oss.sgi.com Tue Dec 2 08:20:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 08:21:13 -0800 (PST) Received: from hoby.coplanar.net (CPE0020afeeb1ac-CM014250013274.cpe.net.cable.rogers.com [24.114.21.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2GKsTa015956 for ; Tue, 2 Dec 2003 08:20:54 -0800 Received: from coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) (authenticated bits=0) by hoby.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hB2GKgCE008175 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 2 Dec 2003 11:20:43 -0500 Message-ID: <3FCCBA37.1070209@coplanar.net> Date: Tue, 02 Dec 2003 11:13:43 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Russell Cattelan CC: Marcelo Tosatti , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: Re: XFS for 2.4 References: <1070379282.82397.29.camel@lupo.thebarn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1198 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs I think the dislike is justified. XFS is kind of like an alien parasite attached to Linux. IRIX's IO system is different, it's taken a lot of changes. I still think it is the best filesystem with a lot of unused potential though. I hope it will eventually be well integrated - 2.6/2.8. It's only the generic code changes we need to worry about though, right? Regards, Jeremy Jackson Russell Cattelan wrote: > On Tue, 2003-12-02 at 05:18, Marcelo Tosatti wrote: > [snip] > >>Also I'm not completly sure if the generic changes are fine and I dont >>like the XFS code in general. > > Ahh so the real truth comes out. > > > Is there a reason for your sudden dislike of the XFS code? > or is this just an arbitrary general dislike for unknown or > unstated reasons? > > From owner-linux-xfs@oss.sgi.com Tue Dec 2 08:24:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 08:24:37 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2GOCTa016380 for ; Tue, 2 Dec 2003 08:24:12 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hB2GLw7Y002538; Tue, 2 Dec 2003 10:21:58 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB2GLsKp002536; Tue, 2 Dec 2003 10:21:55 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS for 2.4 From: Austin Gonyou To: Darrell Michaud Cc: Marcelo Tosatti , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, XFS List , Andrew Morton In-Reply-To: <1070381443.5316.260.camel@atherne> References: <1070381443.5316.260.camel@atherne> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1070382114.2392.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 02 Dec 2003 10:21:54 -0600 X-archive-position: 1199 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs I second this as well. I'm sure there are others. XFS is a good option to have for official FS inclusion and I'm *very* happy it's in 2.6. If it were in 2.4, that *may* make adoption of 2.6 for some, slow in coming along. While that may be true, I see that most will eventually want to take advantage of all 2.6 has to offer, but if XFS were in the official tree, then that may be one less piece of guess work needed when upgrading from 2.4 to 2.6 with regards to FS maintenance. (i.e. same version of XFS in both trees == possible same reliability, etc) On Tue, 2003-12-02 at 10:10, Darrell Michaud wrote: > As a user it would be very beneficial for me to have XFS support in > the > official 2.4 kernel tree. XFS been stable and "2.4 integration-ready" > for a long time, and 2.4 is going to be used in certain environments > for > a long time, if only because it's easier to upgrade a 2.4 kernel to a > newer 2.4 kernel than to upgrade to a 2.6 kernel. It seems like an > easy > case to make. > > I use other filesystems and some funky drivers as well.. and I'm > always > very happy to see useful backports show up in the 2.4 tree. Thank you! > > > > On Tue, 2003-12-02 at 10:50, Marcelo Tosatti wrote: > > On Tue, 2 Dec 2003, Russell Cattelan wrote: > > > > > On Tue, 2003-12-02 at 05:18, Marcelo Tosatti wrote: > > > [snip] > > > > Also I'm not completly sure if the generic changes are fine and > I dont > > > > like the XFS code in general. > > > Ahh so the real truth comes out. > > > > > > > > > Is there a reason for your sudden dislike of the XFS code? > > > > I always disliked the XFS code. > > > > > or is this just an arbitrary general dislike for unknown or > unstated > > > reasons? > > > > I dont like the style of the code. Thats a personal issue, though, > and > > shouldnt matter. > > > > The bigger point is that XFS touches generic code and I'm not sure > if that > > can break something. > > > > Why it matters so much for you to have XFS in 2.4 ? > > > -- > Darrell Michaud -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Dec 2 08:58:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 08:58:23 -0800 (PST) Received: from cibs9.sns.it (root@cibs9.sns.it [192.167.206.29]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2GvxTa017319 for ; Tue, 2 Dec 2003 08:58:00 -0800 Received: from cibs9.sns.it (venom@localhost [127.0.0.1]) by cibs9.sns.it (8.12.8/8.12.8) with ESMTP id hB2GvUFc002342; Tue, 2 Dec 2003 17:57:30 +0100 Received: from localhost (venom@localhost) by cibs9.sns.it (8.12.8/8.12.8/Submit) with ESMTP id hB2GvTho002339; Tue, 2 Dec 2003 17:57:30 +0100 X-Authentication-Warning: cibs9.sns.it: venom owned process doing -bs Date: Tue, 2 Dec 2003 17:57:29 +0100 (CET) From: venom@sns.it To: Jeff Garzik cc: Darrell Michaud , Marcelo Tosatti , Russell Cattelan , Nathan Scott , , , Andrew Morton Subject: Re: XFS for 2.4 In-Reply-To: <20031202162808.GC22608@gtf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1200 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venom@sns.it Precedence: bulk X-list: linux-xfs On Tue, 2 Dec 2003, Jeff Garzik wrote: > > This can also be done in patch form, as it is done now :) > of course. 2.4 systems that are already using XFS as a patch probably would have a benefit to see it integrated into 2.4 kernel, but they would is it anyway as a patch. I do not think the merge would be usefull thinking to a from2.4/to2.6 upgrade. In fact, if a system is not using XFS already, it is difficoult that a filesystem is changed if it is an upgrade and not a reinstallation. So, at the end, to have XFS just as a patch for 2.4 is not so bad. Luigi From owner-linux-xfs@oss.sgi.com Tue Dec 2 09:07:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 09:07:27 -0800 (PST) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2H6sTa017935 for ; Tue, 2 Dec 2003 09:06:55 -0800 Received: by havoc.gtf.org (Postfix, from userid 500) id B91CB66E4; Tue, 2 Dec 2003 11:28:08 -0500 (EST) Date: Tue, 2 Dec 2003 11:28:08 -0500 From: Jeff Garzik To: Darrell Michaud Cc: Marcelo Tosatti , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: Re: XFS for 2.4 Message-ID: <20031202162808.GC22608@gtf.org> References: <1070381443.5316.260.camel@atherne> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1070381443.5316.260.camel@atherne> User-Agent: Mutt/1.3.28i X-archive-position: 1201 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: linux-xfs On Tue, Dec 02, 2003 at 11:10:43AM -0500, Darrell Michaud wrote: > As a user it would be very beneficial for me to have XFS support in the > official 2.4 kernel tree. XFS been stable and "2.4 integration-ready" > for a long time, and 2.4 is going to be used in certain environments for > a long time, if only because it's easier to upgrade a 2.4 kernel to a > newer 2.4 kernel than to upgrade to a 2.6 kernel. It seems like an easy > case to make. > > I use other filesystems and some funky drivers as well.. and I'm always > very happy to see useful backports show up in the 2.4 tree. Thank you! This can also be done in patch form, as it is done now :) There are several pieces of backported software that are integration-ready, but that doesn't imply they should go into an increasingly-frozen 2.4.x tree... Jeff From owner-linux-xfs@oss.sgi.com Tue Dec 2 09:39:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 09:39:31 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2Hd0Ta018664 for ; Tue, 2 Dec 2003 09:39:03 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hB2Hcohl005609; Tue, 2 Dec 2003 18:38:50 +0100 Message-ID: <3FCCCED2.1090706@stesmi.com> Date: Tue, 02 Dec 2003 18:41:38 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Darrell Michaud , Marcelo Tosatti , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: Re: XFS for 2.4 References: <1070381443.5316.260.camel@atherne> <20031202162808.GC22608@gtf.org> In-Reply-To: <20031202162808.GC22608@gtf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1202 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Jeff Garzik wrote: > On Tue, Dec 02, 2003 at 11:10:43AM -0500, Darrell Michaud wrote: > >>As a user it would be very beneficial for me to have XFS support in the >>official 2.4 kernel tree. XFS been stable and "2.4 integration-ready" >>for a long time, and 2.4 is going to be used in certain environments for >>a long time, if only because it's easier to upgrade a 2.4 kernel to a >>newer 2.4 kernel than to upgrade to a 2.6 kernel. It seems like an easy >>case to make. >> >>I use other filesystems and some funky drivers as well.. and I'm always >>very happy to see useful backports show up in the 2.4 tree. Thank you! > > > This can also be done in patch form, as it is done now :) > > There are several pieces of backported software that are > integration-ready, but that doesn't imply they should go into an > increasingly-frozen 2.4.x tree... Good point, however the XFS code has been ready for way longer than some other things that were integrated have existed at all. There was a question to merge XFS before 2.4 but the answer was no then. That was eons ago and reiserfs and JFS has made it in since then but not XFS. That strikes me as odd. Everybody have been patient and changing the code according to how it might get accepted and it still hasn't been merged. Many people have run XFS for a long time and while they can use the same way they do now (xfs-patches or precompiled RPM) I don't see a motivation not to include it, especially seeing that other filesystems got in. True XFS touches some generic code but if that really is an issue, why don't people sit down and look at the changes (again) and see what can be changed. If that's the reason. // Stefan From owner-linux-xfs@oss.sgi.com Tue Dec 2 09:45:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 09:46:13 -0800 (PST) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2HjnTa019170 for ; Tue, 2 Dec 2003 09:45:51 -0800 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Dec 2003 12:45:38 -0500 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC0924C8@THOR.goeci.com> From: Murthy Kambhampaty To: "'Marcelo Tosatti'" , Russell Cattelan Cc: Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: RE: XFS for 2.4 Date: Tue, 2 Dec 2003 12:45:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 1203 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs On Tuesday, December 02, 2003 10:50 AM, Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com] wrote: > > > Also I'm not completly sure if the generic changes are > fine and I dont > > > like the XFS code in general. > > Ahh so the real truth comes out. > > > > > > Is there a reason for your sudden dislike of the XFS code? > > I always disliked the XFS code. > > > or is this just an arbitrary general dislike for unknown or unstated > > reasons? > > I dont like the style of the code. Thats a personal issue, > though, and > shouldnt matter. i) Would the linux 2.4 kernel maintainer please stop trolling the XFS mailing list. > > The bigger point is that XFS touches generic code and I'm not > sure if that > can break something. ii) This was the reason why it took so long to get it into the 2.5 series and in the 2.4-ac series, of course, but surely by now it has been shown that the changes to the generic code do not "break something". It isn't clear what standard is being applied here. Surely its not "the patches had better be shown to not break anything else AND Marcelo Tosatti must also like the style of the code". > > Why it matters so much for you to have XFS in 2.4 ? > iii) The 2.4 series kernel is the here and now, regardless of how near we all hope/project the 2.6 kernel to be (has Andrew Morton even taken it over from Linus?). Pushing 2.6 on users, and unjustifiably blocking the adoption of advanced features into the current linux kernel is pretty absurd. XFS has unmatched filesystem features (for example, it uniquely enables filesystem level backup of databases even when the database log is on a different partition than the data tables http://marc.theaimsgroup.com/?l=postgresql-admin&m=106641231828872&w=2). If you can't come up with something more concrete than "I don't like your coding style" and "I'm not sure your patch won't break something", it seems only fair you take the XFS patches. From owner-linux-xfs@oss.sgi.com Tue Dec 2 10:03:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 10:03:31 -0800 (PST) Received: from work.bitmover.com (ipcop.bitmover.com [192.132.92.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2I3JTa020199 for ; Tue, 2 Dec 2003 10:03:19 -0800 Received: (from lm@localhost) by work.bitmover.com (8.11.6/8.11.6) id hB2I2pg09614; Tue, 2 Dec 2003 10:02:51 -0800 Date: Tue, 2 Dec 2003 10:02:51 -0800 From: Larry McVoy To: Murthy Kambhampaty Cc: "'Marcelo Tosatti'" , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: Re: XFS for 2.4 Message-ID: <20031202180251.GB17045@work.bitmover.com> Mail-Followup-To: Larry McVoy , Murthy Kambhampaty , 'Marcelo Tosatti' , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton References: <2D92FEBFD3BE1346A6C397223A8DD3FC0924C8@THOR.goeci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC0924C8@THOR.goeci.com> User-Agent: Mutt/1.4i X-archive-position: 1206 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lm@bitmover.com Precedence: bulk X-list: linux-xfs On Tue, Dec 02, 2003 at 12:45:38PM -0500, Murthy Kambhampaty wrote: > If you can't come up with something more concrete than "I don't like your > coding style" and "I'm not sure your patch won't break something", it seems > only fair you take the XFS patches. Not your call, it's Marcelo's call. And I and he have both suggested that the way to get XFS in is to have someone with some clout in the file system area agree that it is fine. It's a perfectly reasonable request and the longer it goes unanswered the less likely it is that XFS will get integrated. The fact that $XFS_USER wants it in is $XFS_USER's problem. $VFS_MAINTAINER needs to say "hey, this looks good, what's the fuss about?" and I suspect that Marcelo would be more interested. It is not, however, any more my call to make than it is your call to make. We're not doing Marcelo's job. It is also not unreasonable to reject a set of changes right before freezing 2.4. 2.4 is supposed to be dead. Add XFS and what's next? Who's pet feature needs to go in? -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From owner-linux-xfs@oss.sgi.com Tue Dec 2 10:03:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 10:03:30 -0800 (PST) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2I3ITa020187 for ; Tue, 2 Dec 2003 10:03:18 -0800 Received: by havoc.gtf.org (Postfix, from userid 500) id 44ECC6684; Tue, 2 Dec 2003 12:59:57 -0500 (EST) Date: Tue, 2 Dec 2003 12:59:57 -0500 From: Jeff Garzik To: Murthy Kambhampaty Cc: "'Marcelo Tosatti'" , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: Re: XFS for 2.4 Message-ID: <20031202175957.GA1990@gtf.org> References: <2D92FEBFD3BE1346A6C397223A8DD3FC0924C8@THOR.goeci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC0924C8@THOR.goeci.com> User-Agent: Mutt/1.3.28i X-archive-position: 1205 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: linux-xfs On Tue, Dec 02, 2003 at 12:45:38PM -0500, Murthy Kambhampaty wrote: > i) Would the linux 2.4 kernel maintainer please stop trolling the XFS > mailing list. Ok, we'll avoid discussing a major point in XFS's life -- potentially being merged into 2.4 -- on XFS list. Makes sense. > iii) The 2.4 series kernel is the here and now, regardless of how near we > all hope/project the 2.6 kernel to be (has Andrew Morton even taken it over > from Linus?). Pushing 2.6 on users, and unjustifiably blocking the adoption > of advanced features into the current linux kernel is pretty absurd. XFS has This is bogus logic. Nobody is forcing 2.6 on anyone. People who wish to use XFS in 2.4 _can do so today_... without any merging from Marcelo. Merging is nothing more than moving a patch from one place to another. > If you can't come up with something more concrete than "I don't like your > coding style" and "I'm not sure your patch won't break something", it seems > only fair you take the XFS patches. This is bogus logic. It's _very_ wise to hold off on a patch if (a) the code is difficult to read, and therefore difficult to review and fix (read: style) (b) the maintainer is not assured of patch reliability (read: "I'm not sure the patch won't break things") Both (a) and (b) are vaild concerns for long term maintenance costs. Particularly (b). If Marcelo is not assured of patch reliability, then he absolutely --should not-- merge XFS into 2.4. That's just the way the system works. And it's a good system. Jeff From owner-linux-xfs@oss.sgi.com Tue Dec 2 10:02:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 10:02:55 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2I2YTa020127 for ; Tue, 2 Dec 2003 10:02:34 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB2INXHc018151 for ; Tue, 2 Dec 2003 12:23:33 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB2I1SP515792671; Tue, 2 Dec 2003 12:01:28 -0600 (CST) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB2I1LRn341851031; Tue, 2 Dec 2003 12:01:21 -0600 (CST) Subject: Re: XFS for 2.4 From: Russell Cattelan To: Marcelo Tosatti Cc: Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton In-Reply-To: References: Content-Type: text/plain Message-Id: <1070388083.3060.19.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-1mdk Date: Tue, 02 Dec 2003 12:01:23 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1204 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs On Tue, 2003-12-02 at 09:50, Marcelo Tosatti wrote: > On Tue, 2 Dec 2003, Russell Cattelan wrote: > > > On Tue, 2003-12-02 at 05:18, Marcelo Tosatti wrote: > > [snip] > > > Also I'm not completly sure if the generic changes are fine and I dont > > > like the XFS code in general. > > Ahh so the real truth comes out. > > > > > > Is there a reason for your sudden dislike of the XFS code? > > I always disliked the XFS code. > > > or is this just an arbitrary general dislike for unknown or unstated > > reasons? > > I dont like the style of the code. Thats a personal issue, though, and > shouldnt matter. True... so are you basing your decision to not include it on some thing technical or just your personal feeling? which in your words "shouldn't matter" > > The bigger point is that XFS touches generic code and I'm not sure if that > can break something. We have taken great pain to make sure the generic code changes do not logically change any code paths. Everything is either new code paths only used by XFS or very careful conditionals on flags only set by XFS. Some of the changes that were made to generic code was done because it was the right way to it. It would certainly would be possible pull many of the needed changes back into fs/xfs but then there would be duplicated code that could potentially be wrong if somebody changes the generic routines. (core locking differences in different kernels have bitten us in the past, RedHat kernel are good at this) If you really have issues with any of the core changes please make some suggestions it's possible things could be done differently. > > Why it matters so much for you to have XFS in 2.4 ? Well if you follow that logic then why did any of the other filesystems go in? in fact why would any new subsystems go in? Everybody maintaining a large pile of patches should be sufficient to call something linux? Take anybody list of reasons for inclusion into core. Acceptance Larger audience, possible exposure in other projects that won't look at XFS due the extra work of merging their patches with ours Ease the support work needed to integrate with all the different distro More feed back for interfaces From owner-linux-xfs@oss.sgi.com Tue Dec 2 10:07:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 10:07:50 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2I7cTa021449 for ; Tue, 2 Dec 2003 10:07:38 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hB2I5R7Y003431; Tue, 2 Dec 2003 12:05:27 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB2I5QXR003425; Tue, 2 Dec 2003 12:05:26 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS for 2.4 From: Austin Gonyou To: Marcelo Tosatti Cc: Nathan Scott , Larry McVoy , linux-kernel@vger.kernel.org, XFS List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1070388326.2380.16.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 02 Dec 2003 12:05:26 -0600 X-archive-position: 1207 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs On Tue, 2003-12-02 at 05:22, Marcelo Tosatti wrote: > [...] > My whole point is "2.6 is almost out of the door and its so much > better". > Its much faster, much cleaner. I agree with this, even in spite of my earlier arguments. I do like 2.6, but I think there are some valid points listed recently for 2.4 inclusion. I might just be an end-user, but I do appreciate XFS for what it is, and have been using it for a while now. It just seems like natural inclusion at this point almost "just makes sense." -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Dec 2 10:11:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 10:12:03 -0800 (PST) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2IBpTa021906 for ; Tue, 2 Dec 2003 10:11:51 -0800 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Dec 2003 13:11:46 -0500 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC0924C9@THOR.goeci.com> From: Murthy Kambhampaty To: "'CLeon@phs.org'" Cc: pgsql-performance@postgresql.org, pgsql-admin@postgresql.org, "'linux-xfs@oss.sgi.com'" Subject: RE: [linux-lvm] RE: [ADMIN] [PERFORM] backup/restore - another Date: Tue, 2 Dec 2003 13:11:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 1208 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs xfs_freeze is a userspace program included in the xfsprogs rpm. It does run on Redhat 7.3 (the SGI supplied kernels and userspace for RedHat 7.3 are somewhat dated; I'd suggest patching the 2.4.21 kernel with XFS 1.3.1 patches and upgrading the userspace programs from the SRPMS). Post to the linux-xfs mailing list if you need further guidance (lots of people seem to still run XFS on Redhat 7.3). > -----Original Message----- > From: CLeon@phs.org [mailto:CLeon@phs.org] > Sent: Thursday, October 30, 2003 12:28 PM > To: linux-lvm@sistina.com; tgl@sss.pgh.pa.us > Cc: threshar@torgo.978.org; josh@agliodbs.com; markw@osdl.org; > pgsql-performance@postgresql.org; pgsql-admin@postgresql.org > Subject: Re: [linux-lvm] RE: [ADMIN] [PERFORM] backup/restore > - another > > > Does xfs_freeze work on red hat 7.3? > > Cynthia Leon > > -----Original Message----- > From: Murthy Kambhampaty [mailto:murthy.kambhampaty@goeci.com] > Sent: Friday, October 17, 2003 11:34 AM > To: 'Tom Lane'; Murthy Kambhampaty > Cc: 'Jeff'; Josh Berkus; markw@osdl.org; > pgsql-performance@postgresql.org; linux-lvm@sistina.com; > pgsql-admin@postgresql.org > Subject: [linux-lvm] RE: [ADMIN] [PERFORM] backup/restore - another > area. > > > Friday, October 17, 2003 12:05, Tom Lane > [mailto:tgl@sss.pgh.pa.us] wrote: > > >Murthy Kambhampaty writes: > >> ... The script handles situations > >> where (i) the XFS filesystem containing $PGDATA has an > >external log and (ii) > >> the postmaster log ($PGDATA/pg_xlog) is written to a > >filesystem different > >> than the one containing the $PGDATA folder. > > > >It does? How exactly can you ensure snapshot consistency between > >data files and XLOG if they are on different filesystem > > Say, you're setup looks something like this: > > mount -t xfs /dev/VG1/LV_data /home/pgdata > mount -t xfs /dev/VG1/LV_xlog /home/pgdata/pg_xlog > > When you want to take the filesystem backup, you do: > > Step 1: > xfs_freeze -f /dev/VG1/LV_xlog > xfs_freeze -f /dev/VG1/LV_data > This should finish any checkpoints that were in > progress, and not > start any new ones > till you unfreeze. (writes to an xfs_frozen filesystem > wait for the > xfs_freeze -u, > but reads proceed; see text from xfs_freeze manpage in postcript > below.) > > > Step2: > create snapshots of /dev/VG1/LV_xlog and /dev/VG1/LV_xlog > > Step 3: > xfs_freeze -u /dev/VG1/LV_data > xfs_freeze -u /dev/VG1/LV_xlog > Unfreezing in this order should assure that checkpoints > resume where > they left off, then log writes commence. > > > Step4: > mount the snapshots taken in Step2 somewhere; e.g. /mnt/snap_data and > /mnt/snap_xlog. Copy (or rsync or whatever) /mnt/snap_data to > /mnt/pgbackup/ > and /mnt/snap_xlog to /mnt/pgbackup/pg_xlog. Upon completion, > /mnt/pgbackup/ > looks to the postmaster like /home/pgdata would if the server > had crashed at > the moment that Step1 was initiated. As I understand it, > during recovery > (startup) the postmaster will roll the database forward to this point, > "checkpoint-ing" all the transactions that made it into the > log before the > crash. > > Step5: > remove the snapshots created in Step2. > > The key is > (i) xfs_freeze allows you to "quiesce" any filesystem at any > point in time > and, if I'm not mistaken, the order (LIFO) in which you > freeze and unfreeze > the two filesystems: freeze $PGDATA/pg_xlog then $PGDATA; > unfreeze $PGDATA > then $PGDATA/pg_xlog. > (ii) WAL recovery assures consistency after a (file)sytem crash. > > Presently, the test server for my backup scripts is set-up > this way, and the > backup works flawlessly, AFAICT. (Note that the backup script starts a > postmaster on the filesystem copy each time, so you get early > warning of > problems. Moreover the data in the "production" and "backup" > copies are > tested and found to be identical. > > Comments? Any suggestions for additional tests? > > Thanks, > Murthy > > PS: From the xfs_freeze manpage: > "xfs_freeze suspends and resumes access to an XFS filesystem (see > xfs(5)). > > xfs_freeze halts new access to the filesystem and creates a > stable image > on disk. xfs_freeze is intended to be used with volume managers and > hardware RAID devices that support the creation of snapshots. > > The mount-point argument is the pathname of the directory where the > filesystem is mounted. The filesystem must be mounted to be > frozen (see > mount(8)). > > The -f flag requests the specified XFS filesystem to be > frozen from new > modifications. When this is selected, all ongoing transactions in the > filesystem are allowed to complete, new write system calls are halted, > other calls which modify the filesystem are halted, and all > dirty data, > metadata, and log information are written to disk. Any process > attempting to write to the frozen filesystem will block > waiting for the > filesystem to be unfrozen. > > Note that even after freezing, the on-disk filesystem can contain > information on files that are still in the process of unlinking. These > files will not be unlinked until the filesystem is unfrozen or a clean > mount of the snapshot is complete. > > The -u option is used to un-freeze the filesystem and allow operations > to continue. Any filesystem modifications that were blocked by the > freeze are unblocked and allowed to complete." > > _______________________________________________ > linux-lvm mailing list > linux-lvm@sistina.com > http://lists.sistina.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ > > ============================================================== > ================ > --- PRESBYTERIAN HEALTHCARE SERVICES DISCLAIMER --- > > This message originates from Presbyterian Healthcare Services > or one of its > affiliated organizations. It contains information, which may > be confidential > or privileged, and is intended only for the individual or > entity named above. > It is prohibited for anyone else to disclose, copy, > distribute or use the > contents of this message. All personal messages express views > solely of the > sender, which are not to be attributed to Presbyterian > Healthcare Services or > any of its affiliated organizations, and may not be > distributed without this > disclaimer. If you received this message in error, please notify us > immediately at postmaster@phs.org. > ============================================================== > ================ > > > ---------------------------(end of > broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index > scan if your > joining column's datatypes do not match > From owner-linux-xfs@oss.sgi.com Tue Dec 2 10:11:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 10:12:09 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2IBvTa021918 for ; Tue, 2 Dec 2003 10:11:58 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.22) id 1AREzy-0007CV-Js; Tue, 02 Dec 2003 18:11:46 +0000 Date: Tue, 2 Dec 2003 18:11:46 +0000 From: Christoph Hellwig To: Larry McVoy , Murthy Kambhampaty , "'Marcelo Tosatti'" , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: Re: XFS for 2.4 Message-ID: <20031202181146.A27567@infradead.org> Mail-Followup-To: Christoph Hellwig , Larry McVoy , Murthy Kambhampaty , 'Marcelo Tosatti' , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton References: <2D92FEBFD3BE1346A6C397223A8DD3FC0924C8@THOR.goeci.com> <20031202180251.GB17045@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031202180251.GB17045@work.bitmover.com>; from lm@bitmover.com on Tue, Dec 02, 2003 at 10:02:51AM -0800 X-archive-position: 1209 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Tue, Dec 02, 2003 at 10:02:51AM -0800, Larry McVoy wrote: > Not your call, it's Marcelo's call. And I and he have both suggested > that the way to get XFS in is to have someone with some clout in the file > system area agree that it is fine. It's a perfectly reasonable request > and the longer it goes unanswered the less likely it is that XFS will get > integrated. The fact that $XFS_USER wants it in is $XFS_USER's problem. > $VFS_MAINTAINER needs to say "hey, this looks good, what's the fuss about?" > and I suspect that Marcelo would be more interested. I think you're missing the point. The patches have been review many times, they've been posted to lkml many time with the request for comment and they've been merged into 2.5 in almost exactly that form. > It is also not unreasonable to reject a set of changes right before > freezing 2.4. 2.4 is supposed to be dead. That's indeed a point and a very resonable one. But a few of the patches Nathan has in that BK repo have been submited for more than year again and again, and Marcelo's reply (for those 10% of the cases that a reply existed at all) was something along the lines "let's postpone it after the next release". In my opinion that's not the right attitude from a kernel maintainer to someone who wants to contribute major work. From owner-linux-xfs@oss.sgi.com Tue Dec 2 10:20:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 10:20:41 -0800 (PST) Received: from cyber1hq.adic.com (outgoingmail.adic.com [63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2IKJTa022810 for ; Tue, 2 Dec 2003 10:20:19 -0800 Message-ID: <3FCCD7B6.8060503@adic.com> Date: Tue, 02 Dec 2003 12:19:34 -0600 From: Steve Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031121 Thunderbird/0.4a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: Larry McVoy , Murthy Kambhampaty , "'Marcelo Tosatti'" , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: Re: XFS for 2.4 References: <2D92FEBFD3BE1346A6C397223A8DD3FC0924C8@adic.com> <20031202180251.GB17045@work.bitmover.com> <20031202181146.A27567@infradead.org> In-Reply-To: <20031202181146.A27567@adic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1210 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@adic.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: >On Tue, Dec 02, 2003 at 10:02:51AM -0800, Larry McVoy wrote: > > >>Not your call, it's Marcelo's call. And I and he have both suggested >>that the way to get XFS in is to have someone with some clout in the file >>system area agree that it is fine. It's a perfectly reasonable request >>and the longer it goes unanswered the less likely it is that XFS will get >>integrated. The fact that $XFS_USER wants it in is $XFS_USER's problem. >>$VFS_MAINTAINER needs to say "hey, this looks good, what's the fuss about?" >>and I suspect that Marcelo would be more interested. >> >> > >I think you're missing the point. The patches have been review many >times, they've been posted to lkml many time with the request for comment >and they've been merged into 2.5 in almost exactly that form. > > > >>It is also not unreasonable to reject a set of changes right before >>freezing 2.4. 2.4 is supposed to be dead. >> >> > >That's indeed a point and a very resonable one. But a few of the patches >Nathan has in that BK repo have been submited for more than year again >and again, and Marcelo's reply (for those 10% of the cases that a reply >existed at all) was something along the lines "let's postpone it after >the next release". In my opinion that's not the right attitude from >a kernel maintainer to someone who wants to contribute major work. > > > Thank you Christoph, Been sitting here reading this and attempting to control my blood pressure. One thing those folks out there saying this code needs reviewing might want to consider is that XFS spent several months getting 'Christophed' in the last year. Those of you who have seen Christoph in action know what that means ;-). Steve From owner-linux-xfs@oss.sgi.com Tue Dec 2 10:20:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 10:21:16 -0800 (PST) Received: from work.bitmover.com (ipcop.bitmover.com [192.132.92.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2IKvTa022855 for ; Tue, 2 Dec 2003 10:20:57 -0800 Received: (from lm@localhost) by work.bitmover.com (8.11.6/8.11.6) id hB2IKbq10311; Tue, 2 Dec 2003 10:20:37 -0800 Date: Tue, 2 Dec 2003 10:20:37 -0800 From: Larry McVoy To: Christoph Hellwig , Murthy Kambhampaty , "'Marcelo Tosatti'" , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: Re: XFS for 2.4 Message-ID: <20031202182037.GD17045@work.bitmover.com> Mail-Followup-To: Larry McVoy , Christoph Hellwig , Murthy Kambhampaty , 'Marcelo Tosatti' , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton References: <2D92FEBFD3BE1346A6C397223A8DD3FC0924C8@THOR.goeci.com> <20031202180251.GB17045@work.bitmover.com> <20031202181146.A27567@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031202181146.A27567@infradead.org> User-Agent: Mutt/1.4i X-archive-position: 1211 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lm@bitmover.com Precedence: bulk X-list: linux-xfs On Tue, Dec 02, 2003 at 06:11:46PM +0000, Christoph Hellwig wrote: > On Tue, Dec 02, 2003 at 10:02:51AM -0800, Larry McVoy wrote: > > Not your call, it's Marcelo's call. And I and he have both suggested > > that the way to get XFS in is to have someone with some clout in the file > > system area agree that it is fine. It's a perfectly reasonable request > > and the longer it goes unanswered the less likely it is that XFS will get > > integrated. The fact that $XFS_USER wants it in is $XFS_USER's problem. > > $VFS_MAINTAINER needs to say "hey, this looks good, what's the fuss about?" > > and I suspect that Marcelo would be more interested. > > I think you're missing the point. The patches have been review many > times, they've been posted to lkml many time with the request for comment > and they've been merged into 2.5 in almost exactly that form. So what's wrong with asking $VFS_MAINTAINER to refresh Marcelo's memory about that? This is a process. The process is supposed to screen out bad change. Maybe XFS got into 2.5/2.6 inspite of the process rather than because of it. Maybe not. Whatever the answer is, it's perfectly reasonable for the maintainer of the 2.4 tree to want someone he trusts to step forward and say "yeah, it's fine". The fact that other VFS people aren't jumping up and down and saying this should go in is troublesome. If I were Marcelo the more the XFS people push without visible backing from someone with a clear vision of the VFS layer the more I'd push back. Don't get me wrong, I have not looked at or used XFS in years. I have no opinion about it at this point. But I do have an opinion about process and what is going on here, in my opinion, violates the Linux development process. Patches shouldn't go in just because you want them in, they go in because the maintainer chooses to bless them or someone he trusts chooses to bless them. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm From owner-linux-xfs@oss.sgi.com Tue Dec 2 10:23:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 10:24:15 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2INqTa023627 for ; Tue, 2 Dec 2003 10:23:53 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.22) id 1ARFBa-0007GM-Jl; Tue, 02 Dec 2003 18:23:46 +0000 Date: Tue, 2 Dec 2003 18:23:46 +0000 From: Christoph Hellwig To: Larry McVoy , Murthy Kambhampaty , "'Marcelo Tosatti'" , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: Re: XFS for 2.4 Message-ID: <20031202182346.A27914@infradead.org> Mail-Followup-To: Christoph Hellwig , Larry McVoy , Murthy Kambhampaty , 'Marcelo Tosatti' , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton References: <2D92FEBFD3BE1346A6C397223A8DD3FC0924C8@THOR.goeci.com> <20031202180251.GB17045@work.bitmover.com> <20031202181146.A27567@infradead.org> <20031202182037.GD17045@work.bitmover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031202182037.GD17045@work.bitmover.com>; from lm@bitmover.com on Tue, Dec 02, 2003 at 10:20:37AM -0800 X-archive-position: 1212 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Tue, Dec 02, 2003 at 10:20:37AM -0800, Larry McVoy wrote: > So what's wrong with asking $VFS_MAINTAINER to refresh Marcelo's memory > about that? There is no such thing as a VFS maintainer. At least Al doesn't want to be in that position and I guess no one else would qualify (maybe akpm) From owner-linux-xfs@oss.sgi.com Tue Dec 2 10:27:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 10:28:06 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2IRpTa024078 for ; Tue, 2 Dec 2003 10:27:52 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.22) id 1ARFFS-0007H7-CE; Tue, 02 Dec 2003 18:27:46 +0000 Date: Tue, 2 Dec 2003 18:27:46 +0000 From: Christoph Hellwig To: Larry McVoy , Murthy Kambhampaty , "'Marcelo Tosatti'" , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: Re: XFS for 2.4 Message-ID: <20031202182746.A27964@infradead.org> Mail-Followup-To: Christoph Hellwig , Larry McVoy , Murthy Kambhampaty , 'Marcelo Tosatti' , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton References: <2D92FEBFD3BE1346A6C397223A8DD3FC0924C8@THOR.goeci.com> <20031202180251.GB17045@work.bitmover.com> <20031202181146.A27567@infradead.org> <20031202182037.GD17045@work.bitmover.com> <20031202182346.A27914@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031202182346.A27914@infradead.org>; from hch@infradead.org on Tue, Dec 02, 2003 at 06:23:46PM +0000 X-archive-position: 1213 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Tue, Dec 02, 2003 at 06:23:46PM +0000, Christoph Hellwig wrote: > On Tue, Dec 02, 2003 at 10:20:37AM -0800, Larry McVoy wrote: > > So what's wrong with asking $VFS_MAINTAINER to refresh Marcelo's memory > > about that? > > There is no such thing as a VFS maintainer. At least Al doesn't want > to be in that position and I guess no one else would qualify (maybe > akpm) And akpm queued up most of these patches in -mm and revieved them before they went into 2.5, but he is (fortunately for him :)) on vacation so you shouldn't expect any respone from him here. From owner-linux-xfs@oss.sgi.com Tue Dec 2 10:34:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 10:35:13 -0800 (PST) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2IYpTa024563 for ; Tue, 2 Dec 2003 10:34:51 -0800 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Dec 2003 13:34:35 -0500 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC0924CA@THOR.goeci.com> From: Murthy Kambhampaty To: "'Jeff Garzik'" , Murthy Kambhampaty Cc: "'Marcelo Tosatti'" , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: RE: XFS for 2.4 Date: Tue, 2 Dec 2003 13:34:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 1214 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs On Tuesday, December 02, 2003 1:00 PM, Jeff Garzik [mailto:jgarzik@pobox.com] wrote: > On Tue, Dec 02, 2003 at 12:45:38PM -0500, Murthy Kambhampaty wrote: > > i) Would the linux 2.4 kernel maintainer please stop > trolling the XFS > > mailing list. > > Ok, we'll avoid discussing a major point in XFS's life -- potentially > being merged into 2.4 -- on XFS list. Makes sense. I don't see what "discussion" is promoted by Marcelo' comment at this stage in the game that he doesn't like the style of the XFS code, and hasn't for a while, without any constructive examples of what he'd like changed. I'm not sure how you got the impression that my point was that Marcelo shouldn't post his decision not to include XFS in 2.4 to the kernel? Sorry. > > > > iii) The 2.4 series kernel is the here and now, regardless > of how near we > > all hope/project the 2.6 kernel to be (has Andrew Morton > even taken it over > > from Linus?). Pushing 2.6 on users, and unjustifiably > blocking the adoption > > of advanced features into the current linux kernel is > pretty absurd. XFS has > > This is bogus logic. > > Nobody is forcing 2.6 on anyone. People who wish to use XFS in 2.4 > _can do so today_... without any merging from Marcelo. > > Merging is nothing more than moving a patch from one place to another. One of the reasons Marcelo gives for not including XFS in 2.4 is that 2.6 is nearly here and it includes XFS (feel free to review his posts on the subject). My point is that that is bogus logic. Not to put too fine a point on it, but moving a patch from one place to another is the kernel maintainer's job. > > > > If you can't come up with something more concrete than "I > don't like your > > coding style" and "I'm not sure your patch won't break > something", it seems > > only fair you take the XFS patches. > > This is bogus logic. > > It's _very_ wise to hold off on a patch if > (a) the code is difficult to read, and therefore difficult to > review and > fix (read: style) > (b) the maintainer is not assured of patch reliability (read: "I'm not > sure the patch won't break things") > > Both (a) and (b) are vaild concerns for long term maintenance costs. > > Particularly (b). If Marcelo is not assured of patch > reliability, then > he absolutely --should not-- merge XFS into 2.4. That's just the way > the system works. And it's a good system. I agree with the logic you present here, and which Larry McVoy similar comments. My point is that XFS has gone through this mill (and Christoph Hellwig's opinion counts infinitely more than mine on this question). The suggestion that "the maintainer is not assured of patch reliability" with respect to XFS seems cooked-up. In the final analysis, if what it takes is for a filesystem maintainer to jump up and down screaming for XFS's inclusion, then I'm no help ... From owner-linux-xfs@oss.sgi.com Tue Dec 2 11:21:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 11:21:24 -0800 (PST) Received: from intra.cyclades.com (intra.cyclades.com [64.186.161.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2JL4Ta025853 for ; Tue, 2 Dec 2003 11:21:04 -0800 Received: from intra.cyclades.com (localhost.localdomain [127.0.0.1]) by intra.cyclades.com (Postfix) with SMTP id 89A5C2DC8D2; Tue, 2 Dec 2003 11:15:11 -0800 (PST) Received: from cm-net-poa-C8B02617.brdterra.com.br (cm-net-poa-C8B02617.brdterra.com.br [200.176.38.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by intra.cyclades.com (Postfix) with ESMTP id 1036C2DC8F8; Tue, 2 Dec 2003 11:15:08 -0800 (PST) Date: Tue, 2 Dec 2003 17:12:53 -0200 (BRST) From: Marcelo Tosatti X-X-Sender: marcelo@logos.cnet To: Christoph Hellwig Cc: Larry McVoy , Murthy Kambhampaty , "'Marcelo Tosatti'" , Russell Cattelan , Nathan Scott , , , Andrew Morton Subject: Re: XFS for 2.4 In-Reply-To: <20031202182746.A27964@infradead.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1215 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marcelo.tosatti@cyclades.com Precedence: bulk X-list: linux-xfs On Tue, 2 Dec 2003, Christoph Hellwig wrote: > On Tue, Dec 02, 2003 at 06:23:46PM +0000, Christoph Hellwig wrote: > > On Tue, Dec 02, 2003 at 10:20:37AM -0800, Larry McVoy wrote: > > > So what's wrong with asking $VFS_MAINTAINER to refresh Marcelo's memory > > > about that? > > > > There is no such thing as a VFS maintainer. At least Al doesn't want > > to be in that position and I guess no one else would qualify (maybe > > akpm) > > And akpm queued up most of these patches in -mm and revieved them > before they went into 2.5, but he is (fortunately for him :)) on > vacation so you shouldn't expect any respone from him here. Ok, Christoph agreed to review the changes. He has a clue about VFS. If he is OK with them, I'll merge the generic XFS changes. From owner-linux-xfs@oss.sgi.com Tue Dec 2 11:55:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 11:55:38 -0800 (PST) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2Jt4Ta027185 for ; Tue, 2 Dec 2003 11:55:09 -0800 Received: (qmail 10974 invoked by uid 0); 2 Dec 2003 19:55:03 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.28823 secs); 02 Dec 2003 19:55:03 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 2 Dec 2003 19:55:02 -0000 X-Sender-Authentication: net64 Date: Tue, 2 Dec 2003 20:55:02 +0100 From: Stephan von Krawczynski To: Marcelo Tosatti Cc: nathans@sgi.com, lm@work.bitmover.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 Message-Id: <20031202205502.474755f3.skraw@ithnet.com> In-Reply-To: References: <20031202002347.GD621@frodo> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1216 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: linux-xfs On Tue, 2 Dec 2003 09:22:48 -0200 (BRST) Marcelo Tosatti wrote: > [...] > A development tree is much different from a stable tree. You cant just > simply backport generic VFS changes just because everybody agreed with > them on the development tree. > > My whole point is "2.6 is almost out of the door and its so much better". > Its much faster, much cleaner. Even if I am a bit off-topic here, please reconsider your last sentence. Don't make people think that 2.6 is in a widely useable state right now. Just take a look at the history of 2.4. Don't forget 2.4 can be used in boxes beyond 4 GB only right _now_ (2.4.23), all previous versions fall completely apart on i386 platform. 2.4 is right now nice, useable and pretty stable - and 2.6 has not even begun to see the real-and-ugly world yet. There will for sure be a lot of interesting test cases during the next months for 2.6, but there are quite an amount of people that need a real stable environment - and that's why they will have to use 2.4 for at least one year from now on. This is no vote for or against XFS-inclusion, I don't know the thing at all. I only want to state: developer environment is pretty different from the real world, so don't dump 2.4 too early please. Regards, Stephan From owner-linux-xfs@oss.sgi.com Tue Dec 2 12:10:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 12:10:56 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2KAiTa027902 for ; Tue, 2 Dec 2003 12:10:45 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hB2KVgHc025061 for ; Tue, 2 Dec 2003 14:31:43 -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 HAA29926; Wed, 3 Dec 2003 07:10:32 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB2KAAUc2015695; Wed, 3 Dec 2003 07:10:11 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hB2KA6SO2021266; Wed, 3 Dec 2003 07:10:06 +1100 (EST) Date: Wed, 3 Dec 2003 07:10:06 +1100 From: Nathan Scott To: Marcelo Tosatti Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 Message-ID: <20031203071006.B2022202@wobbly.melbourne.sgi.com> References: <20031202182746.A27964@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from marcelo.tosatti@cyclades.com on Tue, Dec 02, 2003 at 05:12:53PM -0200 X-archive-position: 1217 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Dec 02, 2003 at 05:12:53PM -0200, Marcelo Tosatti wrote: > > Ok, Christoph agreed to review the changes. He has a clue about VFS. > > If he is OK with them, I'll merge the generic XFS changes. > Thanks Marcelo. If anything needs clarifying just let me know, or if you have specific requests for XFS changes (provided they don't compromise "super-maintenance mode" of course). Christoph is also very familiar with XFS now, he might be willing to help out reviewing that too. cheers. ps: thanks to everyone who chimed in with a kind word for XFS! (group hug?) -- Nathan From owner-linux-xfs@oss.sgi.com Tue Dec 2 12:11:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 12:11:34 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2KBLTa027985 for ; Tue, 2 Dec 2003 12:11:22 -0800 Received: from viro by www.linux.org.uk with local (Exim 4.22) id 1ARGra-0005ZW-Jt; Tue, 02 Dec 2003 20:11:14 +0000 Date: Tue, 2 Dec 2003 20:11:14 +0000 From: viro@parcelfarce.linux.theplanet.co.uk To: Christoph Hellwig , Larry McVoy , Murthy Kambhampaty , "'Marcelo Tosatti'" , Russell Cattelan , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Andrew Morton Subject: Re: XFS for 2.4 Message-ID: <20031202201114.GA10421@parcelfarce.linux.theplanet.co.uk> References: <2D92FEBFD3BE1346A6C397223A8DD3FC0924C8@THOR.goeci.com> <20031202180251.GB17045@work.bitmover.com> <20031202181146.A27567@infradead.org> <20031202182037.GD17045@work.bitmover.com> <20031202182346.A27914@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031202182346.A27914@infradead.org> User-Agent: Mutt/1.4.1i X-archive-position: 1218 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: viro@parcelfarce.linux.theplanet.co.uk Precedence: bulk X-list: linux-xfs On Tue, Dec 02, 2003 at 06:23:46PM +0000, Christoph Hellwig wrote: > On Tue, Dec 02, 2003 at 10:20:37AM -0800, Larry McVoy wrote: > > So what's wrong with asking $VFS_MAINTAINER to refresh Marcelo's memory > > about that? > > There is no such thing as a VFS maintainer. At least Al doesn't want > to be in that position and I guess no one else would qualify (maybe > akpm) Generally I don't mind doing that kind of work. *However*, in case of XFS I'm very deliberately Not Touching That(tm). Reason: I'm deeply prejudiced against that codebase and (long-standing) situation with its evolution. IOW, I'm not the right guy to ask for comments. XFS codebase is bloated by attempt to imitate VFS interface of inferior operating system (IRIX) and by demand to keep the common codebase between Linux and IRIX versions, IRIX one being the master. And that's not going to change. Moreover, locking in it is such that... well, I would not recommend Larry to look at it - it's a fscking mess that is, AFAICS, long past the point where maintainers had lost any control over it. Basically, all it demonstrates is that with sufficient thrust pigs fly^W^Wanything can be debugged to the point where common codepaths almost never break. I'm not touching that animal. I would trust hch or akpm opinion on it, but that's it - I know that they have enough clue to do it right. Aside of that, count me out whenever XFS is concerned. From owner-linux-xfs@oss.sgi.com Tue Dec 2 14:04:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 14:05:27 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2M4rTa004341 for ; Tue, 2 Dec 2003 14:04:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB2KBlOO018178 for ; Tue, 2 Dec 2003 12:11:47 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB2M4jrA6124490 for ; Wed, 3 Dec 2003 09:04:45 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hB2M4iua6124676 for linux-xfs@oss.sgi.com; Wed, 3 Dec 2003 09:04:44 +1100 (EST) Date: Wed, 3 Dec 2003 09:04:44 +1100 (EST) From: Nathan Scott Message-Id: <200312022204.hB2M4iua6124676@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix comment in xfs_rename.c X-archive-position: 1219 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Noted by Al Viro, passed on by Christoph. Date: Tue Dec 2 13:58:04 PST 2003 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-linux:slinx:162760a linux/fs/xfs/xfs_rename.c - 1.57 From owner-linux-xfs@oss.sgi.com Tue Dec 2 15:28:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 15:28:41 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB2NSPTa006984 for ; Tue, 2 Dec 2003 15:28:25 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB2LYZOO025370 for ; Tue, 2 Dec 2003 13:34:36 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB2NRXrA6342750 for ; Wed, 3 Dec 2003 10:27:33 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hB2NRWAN6341846 for linux-xfs@oss.sgi.com; Wed, 3 Dec 2003 10:27:32 +1100 (EST) Date: Wed, 3 Dec 2003 10:27:32 +1100 (EST) From: Nathan Scott Message-Id: <200312022327.hB2NRWAN6341846@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 905646 - fix debug code X-archive-position: 1220 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Prevent log ktrace code from sleeping in an invalid context. Noticed on 2.6 with preempt enabled. Date: Tue Dec 2 15:25:05 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:162768a linux/fs/xfs/xfs_log.c - 1.287 From owner-linux-xfs@oss.sgi.com Tue Dec 2 21:27:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 21:27:26 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB35R3Ta025664 for ; Tue, 2 Dec 2003 21:27:04 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hB35m0Hc018227 for ; Tue, 2 Dec 2003 23:48: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 QAA07200; Wed, 3 Dec 2003 16:25:35 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB35PVUc1974553; Wed, 3 Dec 2003 16:25:32 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hB35PGJ8002162; Wed, 3 Dec 2003 16:25:17 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hB35PAft002160; Wed, 3 Dec 2003 16:25:10 +1100 Date: Wed, 3 Dec 2003 16:25:10 +1100 From: Nathan Scott To: Chris PeBenito Cc: linux-xfs@oss.sgi.com Subject: Re: [patch] security. namespace Message-ID: <20031203052510.GE1302@frodo> References: <1070301662.7842.11.camel@chris.pebenito.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1070301662.7842.11.camel@chris.pebenito.net> User-Agent: Mutt/1.5.3i X-archive-position: 1221 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Mon, Dec 01, 2003 at 12:01:02PM -0600, Chris PeBenito wrote: > Here is a patch against -test10 that adds an option for the security. > namespace (controlled by a configure option), which is used by SELinux > to store it's security labels. I created this patch based off Tad > Glines' (tadglines@comcast.net) 2.4 patch > (http://www.glines.com/xfs.patch.bz2). Please critique this ... hi Chris, What is the permissions model for the security attribute(s)? It seems from the patch that nothing is enforced, e.g. for setting a new value it seems anyone can do it (which can't be right, can it?)... @@ -667,6 +673,15 @@ VOP_ATTR_SET(vp, p, (void *) data, size, xflags, NULL, error); return -error; } +#ifdef CONFIG_XFS_XATTR_SECURITY + if (strncmp(name, xfs_namespaces[SECURITY_NAMES].name, + xfs_namespaces[SECURITY_NAMES].namelen) == 0) { + xflags |= ATTR_SECURITY; + p += xfs_namespaces[SECURITY_NAMES].namelen; + VOP_ATTR_SET(vp, p, (void *) data, size, xflags, NULL, error); + return -error; + } +#endif If you look at the "trusted" and "user" attrs, they call capable/capable_user_xattr respectively before allowing any operations to proceed (get/set/remove). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Dec 2 22:21:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Dec 2003 22:21:23 -0800 (PST) Received: from chris.pebenito.dhs.org (12-251-184-225.client.attbi.com [12.251.184.225]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB36KxTa027274 for ; Tue, 2 Dec 2003 22:21:00 -0800 Received: by chris.pebenito.dhs.org (Postfix, from userid 1000) id DFBE19CE0A; Wed, 3 Dec 2003 00:20:52 -0600 (CST) Subject: Re: [patch] security. namespace From: Chris PeBenito To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20031203052510.GE1302@frodo> References: <1070301662.7842.11.camel@chris.pebenito.net> <20031203052510.GE1302@frodo> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LCDnS3+lvp34ols3b5iT" Message-Id: <1070432450.19512.30.camel@chris.pebenito.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 03 Dec 2003 00:20:51 -0600 X-archive-position: 1222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pebenito@gentoo.org Precedence: bulk X-list: linux-xfs --=-LCDnS3+lvp34ols3b5iT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-12-02 at 23:25, Nathan Scott wrote: > On Mon, Dec 01, 2003 at 12:01:02PM -0600, Chris PeBenito wrote: > > Here is a patch against -test10 that adds an option for the security. > > namespace (controlled by a configure option), which is used by SELinux > > to store it's security labels. >=20 > What is the permissions model for the security attribute(s)? >=20 > It seems from the patch that nothing is enforced, e.g. for > setting a new value it seems anyone can do it (which can't > be right, can it?)... Actually in terms of SELinux, this is correct, see the very simple ext3 handler (fs/ext3/xattr_security.c), and you'll notice there's not any capability checks. I'm not familiar with lsm hooks/internals, but I would assume that the set is checked pretty early, way before it gets down to the fs. I did turn on SELinux auditing for the set (normally only denials are audited) to make sure it was getting checked, and it was. --=20 Chris PeBenito Developer, Hardened Gentoo Linux Embedded Gentoo Linux =20 Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xE6AF9243 Key fingerprint =3D B0E6 877A 883F A57A 8E6A CB00 BC8E E42D E6AF 9243 --=-LCDnS3+lvp34ols3b5iT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/zYDBvI7kLeavkkMRArszAKCIz0HqDoiEk8nS7prD+nth2omKXQCffoxw 5AvR96zXiExccW7zIU507Dc= =nQd8 -----END PGP SIGNATURE----- --=-LCDnS3+lvp34ols3b5iT-- From owner-linux-xfs@oss.sgi.com Wed Dec 3 05:06:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Dec 2003 05:06:24 -0800 (PST) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB3D60Ta013571 for ; Wed, 3 Dec 2003 05:06:01 -0800 Received: from erbenson.alaska.net (105-pm2.nwc.alaska.net [209.112.138.105]) by iris.acsalaska.net (8.12.10/8.12.10) with ESMTP id hB390wuw054205; Wed, 3 Dec 2003 00:00:59 -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 58C3E39E7; Wed, 3 Dec 2003 00:00:55 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 3DCBC40FF35; Wed, 3 Dec 2003 00:00:57 -0900 (AKST) Date: Wed, 3 Dec 2003 00:00:57 -0900 From: Ethan Benson To: Stefan Smietanowski Cc: Marcelo Tosatti , linux-xfs@oss.sgi.com Subject: Re: XFS for 2.4 Message-ID: <20031203090057.GD962@plato.local.lan> Mail-Followup-To: Stefan Smietanowski , Marcelo Tosatti , linux-xfs@oss.sgi.com References: <1070381443.5316.260.camel@atherne> <20031202162808.GC22608@gtf.org> <3FCCCED2.1090706@stesmi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mSxgbZZZvrAyzONB" Content-Disposition: inline In-Reply-To: <3FCCCED2.1090706@stesmi.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: erbenson@alaska.net X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.69 X-archive-position: 1223 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --mSxgbZZZvrAyzONB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 02, 2003 at 06:41:38PM +0100, Stefan Smietanowski wrote: >=20 > There was a question to merge XFS before 2.4 but the answer was no > then. That was eons ago and reiserfs and JFS has made it in since then > but not XFS. That strikes me as odd.=20 especially since reiserfs was extraordinarily broken when it was merged. (it absolutly did not function on anything except i386, among other things). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --mSxgbZZZvrAyzONB 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 iEYEARECAAYFAj/NpkgACgkQJKx7GixEevyT8ACgi/wJfIarnE/v+WMLJ0sm/cbm iMMAn0c4vFLO2KCW2foVgn6TXxEfBzpC =EZul -----END PGP SIGNATURE----- --mSxgbZZZvrAyzONB-- From owner-linux-xfs@oss.sgi.com Wed Dec 3 10:21:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Dec 2003 10:21:44 -0800 (PST) Received: from elrond.render-it.com (mail.illuvatar.net [205.147.19.123]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB3ILGTa024608 for ; Wed, 3 Dec 2003 10:21:17 -0800 Received: from illuvatar.com (elrond [193.168.254.200]) by elrond.render-it.com (SGI-8.9.3/8.9.3) with ESMTP id KAA76215 for ; Wed, 3 Dec 2003 10:09:49 -0800 (PST) Message-ID: <3FCE26ED.5CFA67B0@illuvatar.com> Date: Wed, 03 Dec 2003 10:09:49 -0800 From: "William C. Shortell" Organization: ILLUVATAR, LLC X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX64 6.5 IP28) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS install questions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bill@illuvatar.com Precedence: bulk X-list: linux-xfs Hello Eric, We talked about a month ago. I had some problems installing to a SCSI based system from the forRH-9.0-SGI-XFS-1.3.0-v1.iso ISO image. The solution was to rebuild the initrd image using mkinitrd --with=xfs. Just last week, I tried to install on an IDE based system. I was unable to install from the forRH-9.0-SGI-XFS-1.3.0-v1.iso ISO image. I was able to upgrade after installing from the RedHat 9.0 CDs. Below are the steps I followed: 1) Failed to install from SGI-XFS CD. Inserted an ISO CD burned from the forRH-9.0-SGI-XFS-1.3.0-v1.iso ISO I downloaded months ago. I ran the CD verification option which passed fine (it stated that it was disk 4). I had also verified that the linux rescue option booted and worked correctly prior to this. When the actual install began, it asked for the first CD. When I inserted the RedHat9.0 install CD1, the install complained that it wasn't an SGI-XFS CD. I was unable to continue with the install. 2) Installed from RedHat 9.0, then rpm'd the kernel from SGI-XFS CD. I did a complete install from the RedHat CDs. Then I installed the rpms from the SGI-XFS CD and converted the file systems. I ran into the same problem as the prior install in that the initrd did not contain the XFS module. I booted into linux rescue mode from the SGI-XFS CD and ran the mkinitrd command (without the --with=xfs option). The machine then booted. My questions are as follows: a) Did I do something wrong on the install from the SGI-XFS CD? Are there more CD iso's than just the forRH-9.0-SGI-XFS-1.3.0-v1.iso? b) Will there be an install iso for XFS-1.3.1? -- William C. Shortell ILLUVATAR,LLC Phone/Fax (714) 965-5918 PO Box 8506 Cell (310) 753-1774 Fountain Valley, CA 92728-8506 E-mail bill@illuvatar.com From owner-linux-xfs@oss.sgi.com Wed Dec 3 10:51:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Dec 2003 10:52:19 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB3IpvTa025354 for ; Wed, 3 Dec 2003 10:51:58 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB3JD1Hc020812 for ; Wed, 3 Dec 2003 13:13:01 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB3IoqP516930978; Wed, 3 Dec 2003 12:50:52 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB3IojK18713264; Wed, 3 Dec 2003 12:50:45 -0600 (CST) Subject: Re: XFS install questions From: Eric Sandeen To: "William C. Shortell" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3FCE26ED.5CFA67B0@illuvatar.com> References: <3FCE26ED.5CFA67B0@illuvatar.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1070477451.8251.13.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 03 Dec 2003 12:50:52 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1225 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2003-12-03 at 12:09, William C. Shortell wrote: > Hello Eric, > > We talked about a month ago. I had some problems installing to a SCSI > based system from the forRH-9.0-SGI-XFS-1.3.0-v1.iso ISO image. The > solution was to rebuild the initrd image using mkinitrd --with=xfs. > > Just last week, I tried to install on an IDE based system. I was > unable to install from the forRH-9.0-SGI-XFS-1.3.0-v1.iso ISO image. I > was able to upgrade after installing from the RedHat 9.0 CDs. Below are > the steps I followed: > > 1) Failed to install from SGI-XFS CD. > > Inserted an ISO CD burned from the forRH-9.0-SGI-XFS-1.3.0-v1.iso ISO > I downloaded months ago. I ran the CD verification option which passed > fine (it stated that it was disk 4). I had also verified that the linux > rescue option booted and worked correctly prior to this. > > When the actual install began, it asked for the first CD. When I > inserted the RedHat9.0 install CD1, the install complained that it > wasn't an SGI-XFS CD. I was unable to continue with the install. Russell changed up the cd request bits a little, I'd try inserting all of your cds and see if it likes any of those better. Also, red hat has been known to have slightly different ISOs out there with different identifiers, perhaps that was the problem. > 2) Installed from RedHat 9.0, then rpm'd the kernel from SGI-XFS CD. > > I did a complete install from the RedHat CDs. Then I installed the > rpms from the SGI-XFS CD and converted the file systems. I ran into the > same problem as the prior install in that the initrd did not contain the > XFS module. I booted into linux rescue mode from the SGI-XFS CD and ran > the mkinitrd command (without the --with=xfs option). The machine then > booted. > > My questions are as follows: > > a) Did I do something wrong on the install from the SGI-XFS CD? Are > there more CD iso's than just the forRH-9.0-SGI-XFS-1.3.0-v1.iso? That's the only one we ship, but you need the original RH cds as well. > b) Will there be an install iso for XFS-1.3.1? It's not very high on the priority list; i.e. probably not, unless there is some community effort to get it done. -Eric > -- > William C. Shortell > ILLUVATAR,LLC Phone/Fax (714) 965-5918 > PO Box 8506 Cell (310) 753-1774 > Fountain Valley, CA 92728-8506 E-mail bill@illuvatar.com -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Dec 3 12:12:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Dec 2003 12:12:22 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB3KC2Ta027697 for ; Wed, 3 Dec 2003 12:12:02 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB3KC26c027696 for linux-xfs@oss.sgi.com; Wed, 3 Dec 2003 12:12:02 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB3KC0Tc027682 for ; Wed, 3 Dec 2003 12:12:01 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB3JF5gZ026290; Wed, 3 Dec 2003 11:15:05 -0800 Date: Wed, 3 Dec 2003 11:15:05 -0800 Message-Id: <200312031915.hB3JF5gZ026290@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 294] New: QA 013 succeeds but leaves filesystem inconsistent X-Bugzilla-Reason: AssignedTo X-archive-position: 1226 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=294 Summary: QA 013 succeeds but leaves filesystem inconsistent Product: Linux XFS Version: 1.3.x Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: xfstests AssignedTo: xfs-master@oss.sgi.com ReportedBy: Peter.Kelemen+sgi@cern.ch QA 013 runs and succeeds, but the filesystem is left inconsistent. _check_fs: filesystem on /dev/hda3 is inconsistent (c) (see after_013.full) _check_fs: filesystem on /dev/hda3 is inconsistent (r) (see after_013.full) The interesting bits of after_013.full are: _check_fs: filesystem on /dev/hda3 is inconsistent *** xfs_check output *** agi unlinked bucket 58 is 4154 in ag 1 (inode=4198458) agi unlinked bucket 21 is 1109 in ag 10 (inode=41944149) allocated inode 4198458 has 0 link count allocated inode 41944149 has 0 link count *** end xfs_check output _check_fs: filesystem on /dev/hda3 is inconsistent *** xfs_repair -n output *** Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 4198458, would move to lost+found disconnected inode 41944149, would move to lost+found Phase 7 - verify link counts... would have reset inode 4198458 nlinks from 0 to 1 would have reset inode 41944149 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting. *** end xfs_repair output *** mount output *** /dev/hda1 on / type ext3 (rw) none on /proc type proc (rw) usbdevfs on /proc/bus/usb type usbdevfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) none on /dev/shm type tmpfs (rw) AFS on /afs type afs (rw) *** end mount output _check_fs: filesystem on /dev/hda3 is inconsistent *** xfs_check output *** agi unlinked bucket 60 is 252 in ag 11 (inode=46137596) allocated inode 46137596 has 0 link count *** end xfs_check output _check_fs: filesystem on /dev/hda3 is inconsistent *** xfs_repair -n output *** Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 46137596, would move to lost+found Phase 7 - verify link counts... would have reset inode 46137596 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting. *** end xfs_repair output *** mount output *** /dev/hda1 on / type ext3 (rw) none on /proc type proc (rw) usbdevfs on /proc/bus/usb type usbdevfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) none on /dev/shm type tmpfs (rw) AFS on /afs type afs (rw) /dev/hda2 on /SCRATCH type xfs (rw,logbufs=2,logbufs=2) *** end mount output _check_fs: filesystem on /dev/hda3 is inconsistent *** xfs_check output *** agi unlinked bucket 63 is 319 in ag 1 (inode=4194623) agi unlinked bucket 15 is 143 in ag 7 (inode=29360271) allocated inode 4194623 has 0 link count allocated inode 29360271 has 0 link count *** end xfs_check output _check_fs: filesystem on /dev/hda3 is inconsistent *** xfs_repair -n output *** Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 4194623, would move to lost+found disconnected inode 29360271, would move to lost+found Phase 7 - verify link counts... would have reset inode 4194623 nlinks from 0 to 1 would have reset inode 29360271 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting. *** end xfs_repair output *** mount output *** /dev/hda1 on / type ext3 (rw) none on /proc type proc (rw) usbdevfs on /proc/bus/usb type usbdevfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) none on /dev/shm type tmpfs (rw) AFS on /afs type afs (rw) *** end mount output ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 3 13:12:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Dec 2003 13:12:24 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB3LC3Ta003116 for ; Wed, 3 Dec 2003 13:12:03 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB3LC3sN003115 for linux-xfs@oss.sgi.com; Wed, 3 Dec 2003 13:12:03 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB3LC1Tc003101 for ; Wed, 3 Dec 2003 13:12:01 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB3KNNDS031403; Wed, 3 Dec 2003 12:23:23 -0800 Date: Wed, 3 Dec 2003 12:23:23 -0800 Message-Id: <200312032023.hB3KNNDS031403@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 294] QA 013 succeeds but leaves filesystem inconsistent X-Bugzilla-Reason: AssignedTo X-archive-position: 1227 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=294 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2003-03-12 12:23 PDT ------- The inconsistency is observed after the second stress command (the multiprocess one) run: xfstests/ltp/fsstress -r -m 8 -n 2000 -d /TEST (two instances). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 3 14:12:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Dec 2003 14:12:14 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB3MC3Ta005691 for ; Wed, 3 Dec 2003 14:12:03 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB3MC220005690 for linux-xfs@oss.sgi.com; Wed, 3 Dec 2003 14:12:02 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB3MC1Tc005676 for ; Wed, 3 Dec 2003 14:12:01 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB3LLkPZ003628; Wed, 3 Dec 2003 13:21:46 -0800 Date: Wed, 3 Dec 2003 13:21:46 -0800 Message-Id: <200312032121.hB3LLkPZ003628@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 295] New: quota block usage not accurate X-Bugzilla-Reason: AssignedTo X-archive-position: 1228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=295 Summary: quota block usage not accurate Product: Linux XFS Version: Current Platform: IA32 URL: http://eelf.ddts.net/~dbharris/quota-shell-log.txt OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: dbharris@eelf.ddts.net Please see referenced log :) I'd attach it if I could, but that doesn't seem to be possible. Basically, the block usage statistics reported by 'quota' aren't accurate until one does a sync. Thanks :) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 3 19:22:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Dec 2003 19:22:21 -0800 (PST) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB43M0Ta016825 for ; Wed, 3 Dec 2003 19:22:00 -0800 Received: from adsl-67-123-174-79.dsl.sntc01.pacbell.net ([67.123.174.79]:62755 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 1ARk3W-0007ip-Pi by VAauthid with fixed_plain for ; Wed, 03 Dec 2003 19:21:30 -0800 Message-ID: <3FCEA837.8040402@linux-sxs.org> Date: Wed, 03 Dec 2003 19:21:27 -0800 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031125 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: failure building xfsprogs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 1ARk3W-0007ip-Pi fc7b75438f8f2214e8c06267650ae14e X-Spam-Score: -100.1 (---------------------------------------------------) X-archive-position: 1229 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Greetings, I'm trying to rebuild xfsprogs-2.6.0-0.src.rpm, and its bombing out: /usr/local/bin/gcc3 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -fno-exceptions -O1 -g -DDEBUG -funsigned-char -Wall -I./include -DVERSION=\"2.6.0\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -O1 -g -DNDEBUG -funsigned-char -Wall -I../include -DVERSION=\"2.6.0\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I. -D_REENTRANT -fno-strict-aliasing -c bit.c -fPIC -DPIC -o .libs/bit.lo In file included from ../include/xfs/libxfs.h:38, from xfs.h:59, from bit.c:37: ../include/xfs/platform_defs.h:454:3: #error Unknown long size ../include/xfs/platform_defs.h:471:4: #error Unknown pointer size ../include/xfs/platform_defs.h:489:4: #error Unknown pointer size make[2]: *** [bit.lo] Error 1 make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/xfsprogs-2.6.0' make: *** [default] Error 2 Bad exit status from /var/tmp/rpm-tmp.84579 (%build) I currently have xfsprogs-2.5.5 (previously built from the SRPM). This box is currently running 2.4.22-xfs. Thanks! -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 7:15pm up 2:26, 1 user, load average: 0.81, 0.39, 0.30 From owner-linux-xfs@oss.sgi.com Wed Dec 3 20:12:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Dec 2003 20:12:15 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB44C4Ta019342 for ; Wed, 3 Dec 2003 20:12:04 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB44C4YR019341 for linux-xfs@oss.sgi.com; Wed, 3 Dec 2003 20:12:04 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB44C2Te019325 for ; Wed, 3 Dec 2003 20:12:03 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB43DC25016758; Wed, 3 Dec 2003 19:13:12 -0800 Date: Wed, 3 Dec 2003 19:13:12 -0800 Message-Id: <200312040313.hB43DC25016758@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 295] quota block usage not accurate X-Bugzilla-Reason: AssignedTo X-archive-position: 1230 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=295 lucaf+sgi@ece.ubc.ca changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucaf+sgi@ece.ubc.ca ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 3 21:31:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Dec 2003 21:31:52 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB45VeTa023204 for ; Wed, 3 Dec 2003 21:31:40 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB45qiHc013943 for ; Wed, 3 Dec 2003 23:52:44 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB45VYP517156953; Wed, 3 Dec 2003 23:31:34 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB45VNK28854353; Wed, 3 Dec 2003 23:31:23 -0600 (CST) Date: Wed, 3 Dec 2003 23:31:30 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Net Llama! cc: linux-xfs@oss.sgi.com Subject: Re: failure building xfsprogs In-Reply-To: <3FCEA837.8040402@linux-sxs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1231 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 3 Dec 2003, Net Llama! wrote: > Greetings, > I'm trying to rebuild xfsprogs-2.6.0-0.src.rpm, and its bombing out: Hm... works for me... platform_defs.h is generated, and the #define it keys on comes from autoconf... so looks like something went wrong there. What distro? -Eric From owner-linux-xfs@oss.sgi.com Wed Dec 3 22:40:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Dec 2003 22:41:11 -0800 (PST) Received: from web8309.mail.in.yahoo.com (web8309.mail.in.yahoo.com [203.199.122.39]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB46ejTa024293 for ; Wed, 3 Dec 2003 22:40:46 -0800 Message-ID: <20031204064039.54088.qmail@web8309.mail.in.yahoo.com> Received: from [61.16.155.180] by web8309.mail.in.yahoo.com via HTTP; Thu, 04 Dec 2003 06:40:39 GMT Date: Thu, 4 Dec 2003 06:40:39 +0000 (GMT) From: =?iso-8859-1?q?rajiv=20gupta?= Subject: acl problem To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 1232 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rajiv_g45@yahoo.co.in Precedence: bulk X-list: linux-xfs hello everybody i am not able to bifurcate the modify and write permission of ntfs filesystem on folders built on xfs filesystem. the modify and write permission remain clubbed as in linux native filesystem. any help regards rajiv ________________________________________________________________________ Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com From owner-linux-xfs@oss.sgi.com Thu Dec 4 05:36:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 05:36:56 -0800 (PST) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4DaXTa021352 for ; Thu, 4 Dec 2003 05:36:34 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id hB4DdU3o030923; Thu, 4 Dec 2003 08:39:30 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id hB4DdUwd030920; Thu, 4 Dec 2003 08:39:30 -0500 Date: Thu, 4 Dec 2003 08:39:30 -0500 (EST) From: Net Llama! To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: failure building xfsprogs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1233 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs On Wed, 3 Dec 2003, Eric Sandeen wrote: > On Wed, 3 Dec 2003, Net Llama! wrote: > > > Greetings, > > I'm trying to rebuild xfsprogs-2.6.0-0.src.rpm, and its bombing out: > > Hm... works for me... platform_defs.h is generated, and the > #define it keys on comes from autoconf... so looks like > something went wrong there. What distro? A mish-mash of what was very long ago OpenLinux-2.4. Now its mostly just me maintaining it from Redhat RPMs, with some other stuff thrown in. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Thu Dec 4 06:37:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 06:37:23 -0800 (PST) Received: from alienAngel.upjs.sk (styx.suse.cz [213.210.157.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4Eb8Ta023081 for ; Thu, 4 Dec 2003 06:37:09 -0800 Received: by alienAngel.upjs.sk (Postfix, from userid 500) id 670DE18D; Thu, 4 Dec 2003 15:38:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by alienAngel.upjs.sk (Postfix) with ESMTP id 616B018C for ; Thu, 4 Dec 2003 15:38:16 +0100 (CET) Date: Thu, 4 Dec 2003 15:38:16 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: linux-xfs@oss.sgi.com Subject: doubled semicolon in xfs_log.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1234 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Hi. I found little typo in xfs_log.c. jan diff -uNr linux/fs/xfs/xfs_log.c 2.6/fs/xfs/xfs_log.c --- linux/fs/xfs/xfs_log.c 2003-12-04 11:13:43.000000000 +0100 +++ 2.6/fs/xfs/xfs_log.c 2003-12-04 15:18:35.000000000 +0100 @@ -1056,7 +1056,7 @@ if (xfs_physmem <= btoc(128*1024*1024)) { log->l_iclog_bufs = XLOG_MIN_ICLOGS; } else if (xfs_physmem <= btoc(400*1024*1024)) { - log->l_iclog_bufs = XLOG_MED_ICLOGS;; + log->l_iclog_bufs = XLOG_MED_ICLOGS; } else { /* 256K with 32K bufs */ log->l_iclog_bufs = XLOG_MAX_ICLOGS; From owner-linux-xfs@oss.sgi.com Thu Dec 4 08:28:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 08:28:24 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4GS1Ta027780 for ; Thu, 4 Dec 2003 08:28:01 -0800 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id hB4GS02I011361 for ; Thu, 4 Dec 2003 11:28:00 -0500 (EST) Date: Thu, 4 Dec 2003 11:28:00 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: Kernel panic, SB validate failed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1235 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Hi, Yesterday my Linux box (RH9.0, 2.4.22, XFS-1.3 or 1.3.1?) crashed (complete freeze while I was working on text editing under X). After some futile attempts to umount or reboot, I had to hard-reset. At boot I got to the following point: FAT: bogus cluster size 51 -"- XFS: bad magic number XFS: SB validate failed Kernel panic: VFS: Unable to mount root fs on 03:05 Any advice would be VERY welcome, how to proceed in such a case. First I would somehow like to distinguish between drive or XFS failure. Cheers Gaspar From owner-linux-xfs@oss.sgi.com Thu Dec 4 09:20:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 09:20:38 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4HK3Ta028991 for ; Thu, 4 Dec 2003 09:20:04 -0800 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id hB4HK2Om014560 for ; Thu, 4 Dec 2003 12:20:03 -0500 (EST) Date: Thu, 4 Dec 2003 12:20:01 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: RE: Kernel panic, SB validate failed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1236 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Hi, Just a couple of debug notes in reference to my previous email. These are the typical messages I get when xfs_checking the partitions on the disk (booted in a previous xfs linux from another disk): -------------------------------------- [root@cfhat root]# xfs_check /dev/hdd5 xfs_check: unexpected XFS SB magic number 0x58665362 bad superblock magic number 58665362, giving up ----------------------------------- [root@cfhat /]# xfs_check /dev/hdd7 bad magic number 0x496e for inode 128 bad magic number 0x496e for inode 129 bad magic number 0x496e for inode 130 bad magic number 0x496e for inode 131 bad magic number 0x496e for inode 132 bad magic number 0x496e for inode 133 bad magic number 0x496e for inode 134 ... bad magic number 0x496e for inode 769216 bad magic number 0x496e for inode 769217 bad magic number 0x496e for inode 769218 ... bad magic number 0x496e for inode 769247 bad magic number 0x496e for inode 1684000 ... bad magic number 0x496e for inode 1684031 root inode 128 is not a directory block 0/12 type unknown not expected block 0/13 type unknown not expected block 0/46 type unknown not expected ... disconnected inode 72210, nlink 1 disconnected inode 72211, nlink 1 disconnected inode 72212, nlink 1 disconnected inode 72213, nlink 1 ... link count mismatch for inode 128 (name ?), nlink 0, counted 17 allocated inode 129 has 0 link count allocated inode 130 has 0 link count link count mismatch for inode 131 (name ?), nlink 0, counted 22 ... link count mismatch for inode 524443 (name ?), nlink 2, counted 1 link count mismatch for inode 633260 (name ?), nlink 4, counted 3 block 2/6028 type unknown not expected block 2/6093 type unknown not expected ... ----------------- [root@cfhat /]# xfs_check /dev/hdd8 xfs_check: unexpected XFS SB magic number 0x58665362 bad superblock magic number 58665362, giving up ------------------- [root@cfhat /]# xfs_check /dev/hdd10 bad magic number 0x496e for inode 25166464 bad magic number 0x496e for inode 25166465 bad magic number 0x496e for inode 25166466 ... agi unlinked bucket 15 is 61967 in ag 6 (inode=25227791) agi unlinked bucket 35 is 209955 in ag 6 (inode=25375779) agi unlinked bucket 50 is 690 in ag 6 (inode=25166514) block 0/238 type unknown not expected link count mismatch for inode 175 (name ?), nlink 2, counted 1 link count mismatch for inode 2591808 (name ?), nlink 3, counted 2 link count mismatch for inode 3381 (name ?), nlink 2, counted 1 ... block 6/57 type unknown not expected block 6/58 type unknown not expected block 6/59 type unknown not expected ... block 6/85154 type unknown not expected block 6/85155 type unknown not expected block 6/85156 type unknown not expected allocated inode 25227791 has 0 link count disconnected inode 25166451, nlink 1 disconnected inode 25166456, nlink 1 ... link count mismatch for inode 29360275 (name ?), nlink 8, counted 7 link count mismatch for inode 29360282 (name ?), nlink 17, counted 15 link count mismatch for inode 29360283 (name ?), nlink 2, counted 1 link count mismatch for inode 30360578 (name ?), nlink 2, counted 1 link count mismatch for inode 29778244 (name ?), nlink 2, counted 1 Gaspar From owner-linux-xfs@oss.sgi.com Thu Dec 4 09:39:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 09:39:41 -0800 (PST) Received: from cyber1hq.adic.com ([63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4HdTTa029581 for ; Thu, 4 Dec 2003 09:39:29 -0800 Message-ID: <3FCF7131.9080703@adic.com> Date: Thu, 04 Dec 2003 11:38:57 -0600 From: Steve Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031121 Thunderbird/0.4a X-Accept-Language: en-us, en MIME-Version: 1.0 To: gbakos@cfa.harvard.edu CC: linux-xfs@oss.sgi.com Subject: Re: Kernel panic, SB validate failed References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1237 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@adic.com Precedence: bulk X-list: linux-xfs Gaspar Bakos wrote: >Hi, > >Just a couple of debug notes in reference to my previous email. These are >the typical messages I get when xfs_checking the partitions on the disk >(booted in a previous xfs linux from another disk): > > Something very wierd has happened to your device, all the magic numbers it is complaining about are almost correct: 0x58665362 is bSfX it is supposed to be BSFX 0x496e is nI, it is supposed to be NI So it almost looks like your device got case flipped on every other byte. However if you look at the correct values vs the wrong ones, what is actually happening is that a bit is getting pulled high in every 16 bit quantity. This caused B to become b, F to become f and N to turn into n. I would blame hardware here - possibly a cable is out of spec, or has come loose, I cannot see software ever causing this type of corruption. Having said that, your disk may still be bad, because you may have had bad data written onto it. Steve >-------------------------------------- >[root@cfhat root]# xfs_check /dev/hdd5 >xfs_check: unexpected XFS SB magic number 0x58665362 >bad superblock magic number 58665362, giving up > >----------------------------------- >[root@cfhat /]# xfs_check /dev/hdd7 >bad magic number 0x496e for inode 128 >bad magic number 0x496e for inode 129 >bad magic number 0x496e for inode 130 >bad magic number 0x496e for inode 131 >bad magic number 0x496e for inode 132 >bad magic number 0x496e for inode 133 >bad magic number 0x496e for inode 134 >... > >bad magic number 0x496e for inode 769216 >bad magic number 0x496e for inode 769217 >bad magic number 0x496e for inode 769218 >... >bad magic number 0x496e for inode 769247 > >bad magic number 0x496e for inode 1684000 >... >bad magic number 0x496e for inode 1684031 >root inode 128 is not a directory >block 0/12 type unknown not expected >block 0/13 type unknown not expected >block 0/46 type unknown not expected >... >disconnected inode 72210, nlink 1 >disconnected inode 72211, nlink 1 >disconnected inode 72212, nlink 1 >disconnected inode 72213, nlink 1 >... >link count mismatch for inode 128 (name ?), nlink 0, counted 17 >allocated inode 129 has 0 link count >allocated inode 130 has 0 link count >link count mismatch for inode 131 (name ?), nlink 0, counted 22 >... >link count mismatch for inode 524443 (name ?), nlink 2, counted 1 >link count mismatch for inode 633260 (name ?), nlink 4, counted 3 >block 2/6028 type unknown not expected >block 2/6093 type unknown not expected >... > >----------------- >[root@cfhat /]# xfs_check /dev/hdd8 >xfs_check: unexpected XFS SB magic number 0x58665362 >bad superblock magic number 58665362, giving up > >------------------- >[root@cfhat /]# xfs_check /dev/hdd10 >bad magic number 0x496e for inode 25166464 >bad magic number 0x496e for inode 25166465 >bad magic number 0x496e for inode 25166466 >... >agi unlinked bucket 15 is 61967 in ag 6 (inode=25227791) >agi unlinked bucket 35 is 209955 in ag 6 (inode=25375779) >agi unlinked bucket 50 is 690 in ag 6 (inode=25166514) >block 0/238 type unknown not expected >link count mismatch for inode 175 (name ?), nlink 2, counted 1 >link count mismatch for inode 2591808 (name ?), nlink 3, counted 2 >link count mismatch for inode 3381 (name ?), nlink 2, counted 1 >... >block 6/57 type unknown not expected >block 6/58 type unknown not expected >block 6/59 type unknown not expected >... >block 6/85154 type unknown not expected >block 6/85155 type unknown not expected >block 6/85156 type unknown not expected >allocated inode 25227791 has 0 link count >disconnected inode 25166451, nlink 1 >disconnected inode 25166456, nlink 1 >... >link count mismatch for inode 29360275 (name ?), nlink 8, counted 7 >link count mismatch for inode 29360282 (name ?), nlink 17, counted 15 >link count mismatch for inode 29360283 (name ?), nlink 2, counted 1 >link count mismatch for inode 30360578 (name ?), nlink 2, counted 1 >link count mismatch for inode 29778244 (name ?), nlink 2, counted 1 > >Gaspar > > > From owner-linux-xfs@oss.sgi.com Thu Dec 4 09:48:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 09:48:33 -0800 (PST) Received: from cyber1hq.adic.com ([63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4Hm3Ta030096 for ; Thu, 4 Dec 2003 09:48:05 -0800 Message-ID: <3FCF732F.5070005@adic.com> Date: Thu, 04 Dec 2003 11:47:27 -0600 From: Steve Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031121 Thunderbird/0.4a X-Accept-Language: en-us, en MIME-Version: 1.0 To: gbakos@cfa.harvard.edu CC: linux-xfs@oss.sgi.com Subject: Re: Kernel panic, SB validate failed References: <3FCF7131.9080703@adic.com> In-Reply-To: <3FCF7131.9080703@adic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1238 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stephen.lord@adic.com Precedence: bulk X-list: linux-xfs Sending this again, from a real email address.... Steve Lord wrote: > Gaspar Bakos wrote: > >> Hi, >> >> Just a couple of debug notes in reference to my previous email. These >> are >> the typical messages I get when xfs_checking the partitions on the disk >> (booted in a previous xfs linux from another disk): >> >> > > Something very wierd has happened to your device, all the magic > numbers it > is complaining about are almost correct: > > 0x58665362 is bSfX it is supposed to be BSFX > > 0x496e is nI, it is supposed to be NI > > So it almost looks like your device got case flipped on every other > byte. However > if you look at the correct values vs the wrong ones, what is actually > happening is > that a bit is getting pulled high in every 16 bit quantity. This > caused B to become > b, F to become f and N to turn into n. > > I would blame hardware here - possibly a cable is out of spec, or has > come > loose, I cannot see software ever causing this type of corruption. > > Having said that, your disk may still be bad, because you may have had > bad data written onto it. > > Steve > From owner-linux-xfs@oss.sgi.com Thu Dec 4 10:12:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 10:12:18 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4IC0Ta031327 for ; Thu, 4 Dec 2003 10:12:03 -0800 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id hB4IBvMg017075; Thu, 4 Dec 2003 13:11:57 -0500 (EST) Date: Thu, 4 Dec 2003 13:11:57 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: Kernel panic, SB validate failed In-Reply-To: <3FCF7131.9080703@adic.com> Message-ID: References: <3FCF7131.9080703@adic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1239 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Hi, Steve, Thanks for the suggestions. I'll check the cable, or swap it, and see what happens. Interestingly, some of the partitions are clean, and only some are affected by the anomaly. Gaspar From owner-linux-xfs@oss.sgi.com Thu Dec 4 10:54:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 10:54:52 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4IsUTa032729 for ; Thu, 4 Dec 2003 10:54:31 -0800 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id hB4IsTS3019309; Thu, 4 Dec 2003 13:54:29 -0500 (EST) Date: Thu, 4 Dec 2003 13:54:28 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: Kernel panic, SB validate failed In-Reply-To: Message-ID: References: <3FCF7131.9080703@adic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1240 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Hi, > I'll check the cable, or swap it, and see what > happens. Swapping the cable did not change things, unfortunately. The main question now is recovery: how to start gently without loosing things - if this is possible at all. I remember that the last time I had to run xfs_repair -L, because the filesystems were not mountable, and simple xfs_repair suggested used of -L. So, I lost a lot of things (not a surprise, but there seemed to be no other way to proceed, at least with my knowledge) Here is the cable situation a bit more detailed: Originally the failed disk was connected as hda with a cable that indeed shows some wear (cable #1). The hdb on the same cable, however, showed no problems (also XFS, what else). After the crash, I replaced the faulty hda to another linux disk to boot in, and the faulty disk went in place of hdd, which has a seemingly new cable, and with which the previous hdd worked fine. All the xfs_check messages I reported were done with this setup, ie. with cable #2. Then I put back fauly to hda, and changed cable #1 to yet another cable (#3), but the same kernel panic happens. Seems like all disks work fine with all the cables I have (as the faulty one also used to). This is off-topic, not directly XFS-related, although would be useful to filter out non-XFS problems: I am thinking if there is a way to investigate if the 'faulty' drive has true hw problems. It is recognized at boot in (as hdd), CHS correct, hdparm -Ii gives correct response. - Is there any meaning of runnig "badblocks" on the device? - Or is there an equivalent for this with xfs (badblocks was mainly used through e2fsck -c)? Cheers, Gaspar From owner-linux-xfs@oss.sgi.com Thu Dec 4 11:29:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 11:29:47 -0800 (PST) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4JTITa002266 for ; Thu, 4 Dec 2003 11:29:19 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id hB4JSh3o018982; Thu, 4 Dec 2003 14:28:43 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id hB4JShW4018979; Thu, 4 Dec 2003 14:28:43 -0500 Date: Thu, 4 Dec 2003 14:28:43 -0500 (EST) From: Net Llama! To: Gaspar Bakos cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Kernel panic, SB validate failed In-Reply-To: Message-ID: References: <3FCF7131.9080703@adic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1241 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs On Thu, 4 Dec 2003, Gaspar Bakos wrote: > Hi, > > > I'll check the cable, or swap it, and see what > > happens. > > Swapping the cable did not change things, unfortunately. > The main question now is recovery: how to start gently without loosing > things - if this is possible at all. > I remember that the last time I had to run xfs_repair -L, because the > filesystems were not mountable, and simple xfs_repair suggested used of > -L. So, I lost a lot of things (not a surprise, but there seemed to be > no other way to proceed, at least with my knowledge) > > Here is the cable situation a bit more detailed: > > Originally the failed disk was connected as hda with a cable that indeed > shows some wear (cable #1). The hdb on the same cable, however, showed no > problems (also XFS, what else). > > After the crash, I replaced the faulty hda to another linux disk to boot > in, and the faulty disk went in place of hdd, which has a seemingly new > cable, and with which the previous hdd worked fine. All the xfs_check > messages I reported were done with this setup, ie. with cable #2. > > Then I put back fauly to hda, and changed cable #1 to yet another cable > (#3), but the same kernel panic happens. Seems like all disks work fine > with all the cables I have (as the faulty one also used to). > > This is off-topic, not directly XFS-related, although would be useful to > filter out non-XFS problems: > > I am thinking if there is a way to investigate if the 'faulty' drive has > true hw problems. It is recognized at boot in (as hdd), CHS correct, > hdparm -Ii gives correct response. > - Is there any meaning of runnig "badblocks" on the device? > - Or is there an equivalent for this with xfs (badblocks was mainly used > through e2fsck -c)? You can start by checking your messages log for any errors. If that comes up clean, and the disk & controller are SMART capable, there is a SMART suite of utilities (google for it) that you can run that will determine if the drive is on the verge of failure. Also, some drive vendors have diagnostic tools that you can run, normally from a bootable floppy disk. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Thu Dec 4 11:59:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 11:59:26 -0800 (PST) Received: from cyber1hq.adic.com ([63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4Jx4Ta003557 for ; Thu, 4 Dec 2003 11:59:04 -0800 Message-ID: <3FCF91E4.7090704@adic.com> Date: Thu, 04 Dec 2003 13:58:28 -0600 From: Steve Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031121 Thunderbird/0.4a X-Accept-Language: en-us, en MIME-Version: 1.0 To: gbakos@cfa.harvard.edu CC: linux-xfs@oss.sgi.com Subject: Re: Kernel panic, SB validate failed References: <3FCF7131.9080703@adic.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1242 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stephen.lord@adic.com Precedence: bulk X-list: linux-xfs Gaspar Bakos wrote: >Hi, > > > >>I'll check the cable, or swap it, and see what >>happens. >> >> > >Swapping the cable did not change things, unfortunately. >The main question now is recovery: how to start gently without loosing >things - if this is possible at all. >I remember that the last time I had to run xfs_repair -L, because the >filesystems were not mountable, and simple xfs_repair suggested used of >-L. So, I lost a lot of things (not a surprise, but there seemed to be >no other way to proceed, at least with my knowledge) > >Here is the cable situation a bit more detailed: > >Originally the failed disk was connected as hda with a cable that indeed >shows some wear (cable #1). The hdb on the same cable, however, showed no >problems (also XFS, what else). > >After the crash, I replaced the faulty hda to another linux disk to boot >in, and the faulty disk went in place of hdd, which has a seemingly new >cable, and with which the previous hdd worked fine. All the xfs_check >messages I reported were done with this setup, ie. with cable #2. > >Then I put back fauly to hda, and changed cable #1 to yet another cable >(#3), but the same kernel panic happens. Seems like all disks work fine >with all the cables I have (as the faulty one also used to). > > So the data probably was corrupted as it was being written to disk. There is not a lot you can do about this after the fact, you do not know if the bit is supposed to be set or not. If you looked at these sectors you will probably find the bad bit set in every other byte. repair will do its best on the fs, you will probably end up with a lot of stuff in lost+found with numbers as file names. The smart utilities are the best way to check the health of the drive itself, it may well be fine. Steve From owner-linux-xfs@oss.sgi.com Thu Dec 4 12:32:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 12:33:00 -0800 (PST) Received: from mail.pdxinc.com (adsl-64-216-7-178.dsl.eulstx.swbell.net [64.216.7.178]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4KWbTa010797 for ; Thu, 4 Dec 2003 12:32:37 -0800 Received: from ncrump (localhost [127.0.0.1]) by mail01.pdxinc.com (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with SMTP id <0HPE002FR127SM@mail01.pdxinc.com> for linux-xfs@oss.sgi.com; Thu, 04 Dec 2003 14:32:31 -0600 (CST) Date: Thu, 04 Dec 2003 14:31:18 -0600 From: Norman Crump Subject: corrupt rpm database To: linux-xfs@oss.sgi.com Reply-to: ncrump@pdxinc.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-archive-position: 1243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ncrump@pdxinc.com Precedence: bulk X-list: linux-xfs I've installed xfs using the rh9 xfs iso along with rh9 distro and cannot install it withour screwing up the rpm database. It renders the rpm stuff usless. is there a patch for this? Thanks From owner-linux-xfs@oss.sgi.com Thu Dec 4 13:33:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 13:34:12 -0800 (PST) Received: from intra.cyclades.com (intra.cyclades.com [64.186.161.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4LXPTa013201 for ; Thu, 4 Dec 2003 13:33:26 -0800 Received: from intra.cyclades.com (localhost.localdomain [127.0.0.1]) by intra.cyclades.com (Postfix) with SMTP id 505C82DCCED; Tue, 2 Dec 2003 12:15:50 -0800 (PST) Received: from cm-net-poa-C8B02617.brdterra.com.br (cm-net-poa-C8B02617.brdterra.com.br [200.176.38.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by intra.cyclades.com (Postfix) with ESMTP id 005292DCFB1; Tue, 2 Dec 2003 12:07:56 -0800 (PST) Date: Tue, 2 Dec 2003 18:05:37 -0200 (BRST) From: Marcelo Tosatti X-X-Sender: marcelo@logos.cnet To: Stephan von Krawczynski Cc: Marcelo Tosatti , , , , Subject: Re: XFS for 2.4 In-Reply-To: <20031202205502.474755f3.skraw@ithnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Cyclades-MailScanner-Information: Please contact the ISP for more information X-Cyclades-MailScanner: Found to be clean X-archive-position: 1244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marcelo.tosatti@cyclades.com Precedence: bulk X-list: linux-xfs On Tue, 2 Dec 2003, Stephan von Krawczynski wrote: > On Tue, 2 Dec 2003 09:22:48 -0200 (BRST) > Marcelo Tosatti wrote: > > > [...] > > A development tree is much different from a stable tree. You cant just > > simply backport generic VFS changes just because everybody agreed with > > them on the development tree. > > > > My whole point is "2.6 is almost out of the door and its so much better". > > Its much faster, much cleaner. > > Even if I am a bit off-topic here, please reconsider your last sentence. Don't > make people think that 2.6 is in a widely useable state right now. Just take a > look at the history of 2.4. Don't forget 2.4 can be used in boxes beyond 4 GB > only right _now_ (2.4.23), all previous versions fall completely apart on i386 > platform. 2.4 is right now nice, useable and pretty stable - and 2.6 has not > even begun to see the real-and-ugly world yet. There will for sure be a lot of > interesting test cases during the next months for 2.6, but there are quite an > amount of people that need a real stable environment - and that's why they will > have to use 2.4 for at least one year from now on. > > This is no vote for or against XFS-inclusion, I don't know the thing at all. I > only want to state: developer environment is pretty different from the real > world, so don't dump 2.4 too early please. I'm not dumping 2.4. It will enter "maintenance-only" mode in 2.4.25. It will be update as long as there are problems in it, but no more features will creep in. As for XFS, Christoph will review the patches and tell me what he thinks. Also other people mailed me saying they reviewed the code. That makes me more comfortable with merging the XFS modifications. From owner-linux-xfs@oss.sgi.com Thu Dec 4 14:04:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 14:05:17 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4M4sTa014168 for ; Thu, 4 Dec 2003 14:04:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB4MQ0Hc000822 for ; Thu, 4 Dec 2003 16:26:01 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB4M4erA8095737; Fri, 5 Dec 2003 09:04:46 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hB4M4ePl8106399; Fri, 5 Dec 2003 09:04:40 +1100 (EST) Date: Fri, 5 Dec 2003 09:04:40 +1100 (EST) From: Nathan Scott Message-Id: <200312042204.hB4M4ePl8106399@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE - acl.5 X-archive-position: 1245 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Update acl.5 man page, from Andreas. Date: Thu Dec 4 14:04:05 PST 2003 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:162939a cmd/acl/man/man5/acl.5 - 1.19 From owner-linux-xfs@oss.sgi.com Thu Dec 4 14:09:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 14:09:57 -0800 (PST) Received: from mail.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4M9VTa014623 for ; Thu, 4 Dec 2003 14:09:32 -0800 Received: from lapprose.ii.uib.no ([129.177.20.37]) by mail.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.12) id 1AS1f1-0002Q9-00 for linux-xfs@oss.sgi.com; Thu, 04 Dec 2003 23:09:23 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.8/8.12.8/Submit) id hB4M9N6S003032 for linux-xfs@oss.sgi.com; Thu, 4 Dec 2003 23:09:23 +0100 Date: Thu, 4 Dec 2003 23:09:23 +0100 From: Jan-Frode Myklebust To: linux-xfs@oss.sgi.com Subject: do_brk() -- kernel 2.4.20-24.9.XFS ? Message-ID: <20031204220923.GB2849@ii.uib.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1AS1f1-0002Q9-00*Xag0ugm3lsE* X-archive-position: 1246 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.uib.no Precedence: bulk X-list: linux-xfs Are there any kernel-2.4.20-24.9.XFS in the pipeline, or will we have to patch up our own version? -jf From owner-linux-xfs@oss.sgi.com Thu Dec 4 14:12:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 14:12:22 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB4MCATa015056 for ; Thu, 4 Dec 2003 14:12:10 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB4MCALj015055 for linux-xfs@oss.sgi.com; Thu, 4 Dec 2003 14:12:10 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB4MC6Te015039 for ; Thu, 4 Dec 2003 14:12:06 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB4LmEdT013940; Thu, 4 Dec 2003 13:48:14 -0800 Date: Thu, 4 Dec 2003 13:48:14 -0800 Message-Id: <200312042148.hB4LmEdT013940@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 295] quota block usage not accurate X-Bugzilla-Reason: AssignedTo X-archive-position: 1247 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=295 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From nathans@sgi.com 2003-04-12 13:48 PDT ------- This is a feature, not a bug (no, really!) - XFS does delayed allocation of space for buffered writes when it can, to get large contiguous extents on disk. Since the space isn't allocated straight away, its not counted by quota straight away - it actually cannot be counted until real space is allocated, because we don't know until the allocation is done exactly how much space will be needed. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Dec 4 14:30:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 14:30:35 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4MUNTa016465 for ; Thu, 4 Dec 2003 14:30:24 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id A8F931437156; Thu, 4 Dec 2003 17:30:37 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 2226D1437131; Thu, 4 Dec 2003 17:30:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 027353020E1B; Thu, 4 Dec 2003 17:30:35 -0500 (EST) Date: Thu, 4 Dec 2003 17:30:35 -0500 (EST) From: Mike Burger To: Norman Crump Cc: linux-xfs@oss.sgi.com Subject: Re: corrupt rpm database In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1248 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs It's probably not actually an XFS issue. There are known problems with the "rpm" program that comes with RH8 and RH9. On Thu, 4 Dec 2003, Norman Crump wrote: > I've installed xfs using the rh9 xfs iso along with rh9 distro and cannot > install it withour screwing up the rpm database. It renders the rpm stuff > usless. is there a patch for this? > Thanks > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Thu Dec 4 15:55:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 15:55:24 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB4Nt8Ta018123 for ; Thu, 4 Dec 2003 15:55:10 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB4M2AOO006027 for ; Thu, 4 Dec 2003 14:02:10 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB4Nt1P517305034; Thu, 4 Dec 2003 17:55:02 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB4NsdK18942110; Thu, 4 Dec 2003 17:54:53 -0600 (CST) Subject: Re: corrupt rpm database From: Eric Sandeen To: Mike Burger Cc: Norman Crump , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1070582086.12073.8.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 04 Dec 2003 17:54:46 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1249 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs TO work around it prefix RPM commands with "LD_ASSUME_KERNEL=2.2.5" or grab latest rpm from rpm.org -Eric On Thu, 2003-12-04 at 16:30, Mike Burger wrote: > It's probably not actually an XFS issue. There are known problems with > the "rpm" program that comes with RH8 and RH9. > > On Thu, 4 Dec 2003, Norman Crump wrote: > > > I've installed xfs using the rh9 xfs iso along with rh9 distro and cannot > > install it withour screwing up the rpm database. It renders the rpm stuff > > usless. is there a patch for this? > > Thanks > > > > -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Dec 4 17:40:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 17:40:53 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB51efTa023241 for ; Thu, 4 Dec 2003 17:40:42 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB521lHc026003 for ; Thu, 4 Dec 2003 20:01:48 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB51eTrA8601399; Fri, 5 Dec 2003 12:40:32 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hB51ePgj8343282; Fri, 5 Dec 2003 12:40:25 +1100 (EST) Date: Fri, 5 Dec 2003 12:40:25 +1100 (EST) From: Nathan Scott Message-Id: <200312050140.hB51ePgj8343282@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE - acl_get_tag_type.3 X-archive-position: 1250 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Merge another ACL man page fix forwarded from Andreas. Date: Thu Dec 4 17:39:51 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs Inspected by: agruen@suse.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:162985a cmd/acl/man/man3/acl_get_tag_type.3 - 1.3 From owner-linux-xfs@oss.sgi.com Thu Dec 4 18:23:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 18:24:00 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB52NcTa024136 for ; Thu, 4 Dec 2003 18:23:38 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB50UeOO020515 for ; Thu, 4 Dec 2003 16:30:40 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB52NRP517356711; Thu, 4 Dec 2003 20:23:27 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB52NKK28952316; Thu, 4 Dec 2003 20:23:20 -0600 (CST) Date: Thu, 4 Dec 2003 20:23:27 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jan-Frode Myklebust cc: linux-xfs@oss.sgi.com Subject: Re: do_brk() -- kernel 2.4.20-24.9.XFS ? In-Reply-To: <20031204220923.GB2849@ii.uib.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1251 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs I'd suggest getting Axel's RPM from atrpms... that's what I just did for my home system. :) It's easy enough for us to spin one, but now that Axel is doing this, I'm happy to point over there... -Eric On Thu, 4 Dec 2003, Jan-Frode Myklebust wrote: > Are there any kernel-2.4.20-24.9.XFS in the pipeline, > or will we have to patch up our own version? > > > -jf > > From owner-linux-xfs@oss.sgi.com Thu Dec 4 20:37:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 20:37:57 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB54bITa028547 for ; Thu, 4 Dec 2003 20:37:19 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hB54wPHc024040 for ; Thu, 4 Dec 2003 22:58: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 PAA12427; Fri, 5 Dec 2003 15:37:06 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB54b5Uc2078943; Fri, 5 Dec 2003 15:37:05 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hB54amJq002076; Fri, 5 Dec 2003 15:36:48 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hB54allA002074; Fri, 5 Dec 2003 15:36:47 +1100 Date: Fri, 5 Dec 2003 15:36:47 +1100 From: Nathan Scott To: Jan Derfinak Cc: linux-xfs@oss.sgi.com Subject: Re: doubled semicolon in xfs_log.c Message-ID: <20031205043647.GC1990@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 1252 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Thu, Dec 04, 2003 at 03:38:16PM +0100, Jan Derfinak wrote: > Hi. > > I found little typo in xfs_log.c. > Thanks Jan, I see theres a couple of others too - I'll get that cleaned up. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Dec 4 21:12:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 21:12:19 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB55C8Ta029291 for ; Thu, 4 Dec 2003 21:12:08 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB55C8pj029290 for linux-xfs@oss.sgi.com; Thu, 4 Dec 2003 21:12:08 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB55C7Tc029276 for ; Thu, 4 Dec 2003 21:12:07 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB54g1dN028966; Thu, 4 Dec 2003 20:42:01 -0800 Date: Thu, 4 Dec 2003 20:42:01 -0800 Message-Id: <200312050442.hB54g1dN028966@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 294] QA 013 succeeds but leaves filesystem inconsistent X-Bugzilla-Reason: AssignedTo X-archive-position: 1253 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=294 ------- Additional Comments From nathans@sgi.com 2003-04-12 20:42 PDT ------- hi Peter, Is this the 1.3.0-release XFS bits? Do you see it in CVS kernels as well? Any info on compiler version? I run that test pretty much all day every day, and have never come across anything like what you describe here before. Which isn't to say its not a real problem of course. Have you tried a debug XFS kernel? cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Dec 4 22:37:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Dec 2003 22:37:29 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB56b8Ta032558 for ; Thu, 4 Dec 2003 22:37:08 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB54i9OO018150 for ; Thu, 4 Dec 2003 20:44:10 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB56b0rA9605114 for ; Fri, 5 Dec 2003 17:37:00 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hB56b06K9614440 for linux-xfs@oss.sgi.com; Fri, 5 Dec 2003 17:37:00 +1100 (EST) Date: Fri, 5 Dec 2003 17:37:00 +1100 (EST) From: Nathan Scott Message-Id: <200312050637.hB56b06K9614440@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs update X-archive-position: 1254 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Sync up with recent kernel changes, noop for userspace Date: Thu Dec 4 22:28:12 PST 2003 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:162989a cmd/dmapi/include/dmapi_kern.h - 1.13 Sync up userspace and kernel code, noop for userspace. Date: Thu Dec 4 22:33:47 PST 2003 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:162991a cmd/xfsprogs/include/xfs_log.h - 1.18 cmd/xfsprogs/include/xfs_ialloc.h - 1.8 cmd/xfsprogs/include/xfs_buf_item.h - 1.9 cmd/xfsprogs/include/xfs_attr_sf.h - 1.9 cmd/xfsprogs/include/xfs_log_priv.h - 1.16 cmd/xfsprogs/include/xfs_da_btree.h - 1.16 cmd/xfsprogs/include/xfs_fs.h - 1.27 cmd/xfsprogs/include/xfs_dir.h - 1.8 cmd/xfsprogs/include/xfs_arch.h - 1.13 cmd/xfsprogs/include/xfs_ialloc_btree.h - 1.8 cmd/xfsprogs/include/xfs_inode_item.h - 1.9 cmd/xfsprogs/include/xfs_bmap_btree.h - 1.12 cmd/xfsprogs/include/xfs_mount.h - 1.42 cmd/xfsprogs/include/xfs_inode.h - 1.37 cmd/xfsprogs/include/xfs_trans.h - 1.15 cmd/xfsprogs/include/xfs_dir_sf.h - 1.9 cmd/xfsprogs/include/xfs_alloc.h - 1.10 cmd/xfsprogs/include/xfs_bmap.h - 1.10 cmd/xfsprogs/libxfs/xfs_da_btree.c - 1.23 cmd/xfsprogs/libxfs/xfs_ialloc_btree.c - 1.9 cmd/xfsprogs/libxfs/xfs_inode.c - 1.27 cmd/xfsprogs/libxfs/xfs_dir2_node.c - 1.15 Small xfs_io tweaks and fixes. Date: Thu Dec 4 22:36:15 PST 2003 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:162992a cmd/xfsprogs/VERSION - 1.94 cmd/xfsprogs/doc/CHANGES - 1.131 cmd/xfsprogs/debian/changelog - 1.85 cmd/xfsprogs/io/command.h - 1.4 cmd/xfsprogs/io/pread.c - 1.8 cmd/xfsprogs/io/input.h - 1.4 cmd/xfsprogs/io/pwrite.c - 1.8 cmd/xfsprogs/io/input.c - 1.6 From owner-linux-xfs@oss.sgi.com Fri Dec 5 00:52:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Dec 2003 00:52:27 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB58puTa005885 for ; Fri, 5 Dec 2003 00:51:59 -0800 Received: from mailhub.ch.sauter-bc.com (mailhub.ch.sauter-bc.com [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 235D632CD1; Fri, 5 Dec 2003 09:51:50 +0100 (CET) Received: from av-01.ch.sauter-bc.com (av-01.ch.sauter-bc.com [10.1.6.28]) by mailhub.ch.sauter-bc.com (Postfix) with SMTP id 479A132CB5; Fri, 5 Dec 2003 09:51:47 +0100 (CET) Received: from mx-05-bsl.ch.sauter-bc.com ([10.1.6.20]) by av-01.ch.sauter-bc.com (SAVSMTP 3.1.2.35) with SMTP id M2003120509514609664 ; Fri, 05 Dec 2003 09:51:46 +0100 Received: from webmail.ch.sauter-bc.com (imap01.ch.sauter-bc.com [10.1.6.25]) by mx-05-bsl.ch.sauter-bc.com (Postfix) with SMTP id 380904E211; Fri, 5 Dec 2003 09:51:47 +0100 (CET) Received: from 10.1.200.117 (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Fri, 5 Dec 2003 09:51:47 +0100 (CET) Message-ID: <3401.10.1.200.117.1070614307.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: References: Date: Fri, 5 Dec 2003 09:51:47 +0100 (CET) Subject: Re: corrupt rpm database From: "Simon Matter" To: ncrump@pdxinc.com Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hB58q0Ta005888 X-archive-position: 1255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs > I've installed xfs using the rh9 xfs iso along with rh9 distro and cannot > install it withour screwing up the rpm database. It renders the rpm stuff > usless. is there a patch for this? Check the archives for different solutions. RedHat has unfortunately broken things here... Simon > Thanks > > > From owner-linux-xfs@oss.sgi.com Fri Dec 5 01:01:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Dec 2003 01:02:09 -0800 (PST) Received: from ngate.noida.hcltech.com ([202.54.110.230]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB591qTa006483 for ; Fri, 5 Dec 2003 01:01:56 -0800 Received: from exch-01.noida.hcltech.com (exch-01 [204.160.254.29]) by ngate.noida.hcltech.com (8.12.8/8.12.8) with ESMTP id hB59dhwa015920 for ; Fri, 5 Dec 2003 15:09:45 +0530 Received: by EXCH-01 with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Dec 2003 14:35:01 +0530 Message-ID: <1B3885BC15C7024C845AAC78314766C55E4F81@EXCH-01> From: "Salil Taneja, Noida" To: "'linux-xfs@oss.sgi.com'" Subject: xfstests Date: Fri, 5 Dec 2003 14:34:24 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 268 X-archive-position: 1256 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: salilt@noida.hcltech.com Precedence: bulk X-list: linux-xfs hi I am unable to downlaod xfstests for xfs release 1.3.1 can you help me out Regards, Salil Taneja HCLT NetCentric Division, A11, Sector 16, Noida, India. * office: +91-120-2510701 Ext 3155 * cell: +91-9810250247 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Dec 5 06:19:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Dec 2003 06:19:47 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB5EJQTa028947 for ; Fri, 5 Dec 2003 06:19:26 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB5EeZHc009576 for ; Fri, 5 Dec 2003 08:40:35 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB5EJJP517473632; Fri, 5 Dec 2003 08:19:20 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB5EJCK29060024; Fri, 5 Dec 2003 08:19:12 -0600 (CST) Date: Fri, 5 Dec 2003 08:19:19 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "Salil Taneja, Noida" cc: "'linux-xfs@oss.sgi.com'" Subject: Re: xfstests In-Reply-To: <1B3885BC15C7024C845AAC78314766C55E4F81@EXCH-01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1257 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs xfstests aren't really packaged up for a release, best bet is to get them out of cvs. On Fri, 5 Dec 2003, Salil Taneja, Noida wrote: > hi > > I am unable to downlaod xfstests for xfs release 1.3.1 > > can you help me out > > Regards, > Salil Taneja From owner-linux-xfs@oss.sgi.com Fri Dec 5 07:12:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Dec 2003 07:12:25 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB5FCDTa030309 for ; Fri, 5 Dec 2003 07:12:13 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB5FCDE2030308 for linux-xfs@oss.sgi.com; Fri, 5 Dec 2003 07:12:13 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB5FCATc030294 for ; Fri, 5 Dec 2003 07:12:10 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB5EHfug028911; Fri, 5 Dec 2003 06:17:41 -0800 Date: Fri, 5 Dec 2003 06:17:41 -0800 Message-Id: <200312051417.hB5EHfug028911@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 294] QA 013 succeeds but leaves filesystem inconsistent X-Bugzilla-Reason: AssignedTo X-archive-position: 1258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=294 ------- Additional Comments From sandeen@sgi.com 2003-05-12 06:17 PDT ------- I have started seeing this as well on the Red Hat kernels and older xfs - around the 1.3.1 timeframe. Newer xfs hits a BUG in __sync_one on those kernels. :/ ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Dec 5 11:07:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Dec 2003 11:07:53 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB5J7HTa007686 for ; Fri, 5 Dec 2003 11:07:18 -0800 Received: from TheDome (CPE0008a10a6eeb-CM014480106915.cpe.net.cable.rogers.com [24.102.42.40]) (authenticated bits=0) by stargate.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hB5J6eBG025969 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 5 Dec 2003 14:06:44 -0500 Message-ID: <007301c3bb62$ecf31a90$282a6618@ddns.coplanar.net> From: "Jeremy Jackson" To: , "Steve Lord" Cc: References: <3FCF7131.9080703@adic.com> Subject: Re: Kernel panic, SB validate failed Date: Fri, 5 Dec 2003 14:06:35 -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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1259 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs The SMART utilities suggestion is a good idea. You can run badblocks on read-only mode: # badblocks -sv -b 512 -c 128 /dev/hda You can try the non-destructive read-write mode, but if there is a hardware problem (not disk media) it will make things way worse, as it reads, corrupts, then rewrites. You could do a destructive read-write test on another disk to check for a hardware problem first, then do the non-destructive read-write on the real drive. I would definitely try the smart utils first. If there is a media defect on the drive, the drive will know (and tell you via SMART) Regards, Jeremy Jackson ----- Original Message ----- From: "Gaspar Bakos" To: "Steve Lord" Cc: Sent: Thursday, December 04, 2003 1:54 PM Subject: Re: Kernel panic, SB validate failed > Hi, > > > I'll check the cable, or swap it, and see what > > happens. > > Swapping the cable did not change things, unfortunately. > The main question now is recovery: how to start gently without loosing > things - if this is possible at all. > I remember that the last time I had to run xfs_repair -L, because the > filesystems were not mountable, and simple xfs_repair suggested used of > -L. So, I lost a lot of things (not a surprise, but there seemed to be > no other way to proceed, at least with my knowledge) > > Here is the cable situation a bit more detailed: > > Originally the failed disk was connected as hda with a cable that indeed > shows some wear (cable #1). The hdb on the same cable, however, showed no > problems (also XFS, what else). > > After the crash, I replaced the faulty hda to another linux disk to boot > in, and the faulty disk went in place of hdd, which has a seemingly new > cable, and with which the previous hdd worked fine. All the xfs_check > messages I reported were done with this setup, ie. with cable #2. > > Then I put back fauly to hda, and changed cable #1 to yet another cable > (#3), but the same kernel panic happens. Seems like all disks work fine > with all the cables I have (as the faulty one also used to). > > This is off-topic, not directly XFS-related, although would be useful to > filter out non-XFS problems: > > I am thinking if there is a way to investigate if the 'faulty' drive has > true hw problems. It is recognized at boot in (as hdd), CHS correct, > hdparm -Ii gives correct response. > - Is there any meaning of runnig "badblocks" on the device? > - Or is there an equivalent for this with xfs (badblocks was mainly used > through e2fsck -c)? > > Cheers, > Gaspar > > From owner-linux-xfs@oss.sgi.com Fri Dec 5 11:08:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Dec 2003 11:08:40 -0800 (PST) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB5J8STa007759 for ; Fri, 5 Dec 2003 11:08:29 -0800 Received: from TheDome (CPE0008a10a6eeb-CM014480106915.cpe.net.cable.rogers.com [24.102.42.40]) (authenticated bits=0) by stargate.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hB5J8QBG025972 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 5 Dec 2003 14:08:27 -0500 Message-ID: <007901c3bb63$2a27e580$282a6618@ddns.coplanar.net> From: "Jeremy Jackson" To: "rajiv gupta" , References: <20031204064039.54088.qmail@web8309.mail.in.yahoo.com> Subject: Re: acl problem Date: Fri, 5 Dec 2003 14:08:20 -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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1260 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Do you mean you are using and XFS filesystem with Samba to store NT acls? Is this a Samba problem or and XFS problem? Regards, Jeremy ----- Original Message ----- From: "rajiv gupta" To: Sent: Thursday, December 04, 2003 1:40 AM Subject: acl problem > hello everybody > > i am not able to bifurcate the modify and write > permission of ntfs filesystem on folders built on xfs > filesystem. > > the modify and write permission remain clubbed as in > linux native filesystem. > > any help > > regards > > rajiv > > > > ________________________________________________________________________ > Yahoo! India Matrimony: Find your partner online. > Go to http://yahoo.shaadi.com > > From owner-linux-xfs@oss.sgi.com Fri Dec 5 14:16:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Dec 2003 14:16:53 -0800 (PST) Received: from mail.modwest.com (marshall.modwest.com [216.129.251.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB5MGMTa024384 for ; Fri, 5 Dec 2003 14:16:22 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.modwest.com (Postfix) with ESMTP id 71AF640F862B for ; Fri, 5 Dec 2003 14:43:58 -0700 (MST) Received: from mail.modwest.com ([127.0.0.1]) by localhost (marshall.modwest.com [127.0.0.1]) (amavisd-new) with ESMTP id 06590-17 for ; Fri, 5 Dec 2003 14:43:57 -0000 (MST) Received: from d216-220-25-60.dynip.modwest.com (d216-220-25-60.dynip.modwest.com [216.220.25.60]) by mail.modwest.com (Postfix) with ESMTP id E459240F870D for ; Fri, 5 Dec 2003 14:43:57 -0700 (MST) Date: Fri, 05 Dec 2003 14:44:36 -0700 From: Michael Loftis To: linux-xfs@oss.sgi.com Subject: Re: do_brk() -- kernel 2.4.20-24.9.XFS ? Message-ID: <94976265.1070635476@d216-220-25-60.dynip.modwest.com> In-Reply-To: <20031204220923.GB2849@ii.uib.no> References: <20031204220923.GB2849@ii.uib.no> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new amavisd-new-20020630 X-archive-position: 1261 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs I'm still looking for a do_brk patch itself...I've got to patch a bunch of 2.4.20 systems but I can't find any useful enough information on the actual patch. --On Thursday, December 04, 2003 23:09 +0100 Jan-Frode Myklebust wrote: > Are there any kernel-2.4.20-24.9.XFS in the pipeline, > or will we have to patch up our own version? > > > -jf > > -- GPG/PGP --> 0xE736BD7E 5144 6A2D 977A 6651 DFBE 1462 E351 88B9 E736 BD7E From owner-linux-xfs@oss.sgi.com Fri Dec 5 14:50:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Dec 2003 14:51:13 -0800 (PST) Received: from elrond.render-it.com (mail.illuvatar.net [205.147.19.123]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB5MopTa027071 for ; Fri, 5 Dec 2003 14:50:51 -0800 Received: from illuvatar.com (bilbo.render-it.com [193.168.254.4]) by elrond.render-it.com (SGI-8.9.3/8.9.3) with ESMTP id OAA84590 for ; Fri, 5 Dec 2003 14:39:13 -0800 (PST) Message-ID: <3FD10911.5702326E@illuvatar.com> Date: Fri, 05 Dec 2003 14:39:13 -0800 From: "William C. Shortell" Organization: ILLUVATAR, LLC X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Thanks Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bill@illuvatar.com Precedence: bulk X-list: linux-xfs Content-Length: 610 Lines: 20 Hello Eric, After downloading the 9.0 ISOs from the redhat site and burning CDs, I was able to do a complete install from the forRH-9.0-SGI-XFS-1.3.0-v1.iso CD. The RedHat 9.0 CDs that I bought from Fry's were an older iso version. Again, thanks very much for all of your help. -- William C. Shortell ILLUVATAR, LLC Cell (310) 753-1774 P. O. Box 8506 Phone/Fax (714) 965-5918 Fountain Valley, CA 92728 E-mail bill@illuvatar.com www.illuvatar.com www.render-it.com [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Dec 5 15:01:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Dec 2003 15:01:43 -0800 (PST) Received: from iceberg.braxis.org (pcp2n94.telpol.net.pl [212.106.145.94]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB5N1GTa028020 for ; Fri, 5 Dec 2003 15:01:20 -0800 Received: (from kszysiu@localhost) by iceberg.braxis.org (8.11.6/8.11.6) id hB5N0lO18180; Sat, 6 Dec 2003 00:00:47 +0100 Date: Sat, 6 Dec 2003 00:00:46 +0100 From: Krzysztof Rusocki To: Michael Loftis Cc: linux-xfs@oss.sgi.com Subject: Re: do_brk() -- kernel 2.4.20-24.9.XFS ? Message-ID: <20031206000046.A18173@iceberg.elsat.net.pl> References: <20031204220923.GB2849@ii.uib.no> <94976265.1070635476@d216-220-25-60.dynip.modwest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <94976265.1070635476@d216-220-25-60.dynip.modwest.com>; from mloftis@wgops.com on Fri, Dec 05, 2003 at 02:44:36PM -0700 X-archive-position: 1263 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kszysiu@iceberg.elsat.net.pl Precedence: bulk X-list: linux-xfs Content-Length: 390 Lines: 11 On Fri, Dec 05, 2003 at 02:44:36PM -0700, Michael Loftis wrote: > I'm still looking for a do_brk patch itself...I've got to patch a bunch of > 2.4.20 systems but I can't find any useful enough information on the actual > patch. There it goes ;) http://linux.bkbits.net:8080/linux-2.4/diffs/mm/mmap.c@1.32?nav=cset@marcelo@dmt.cyclades|ChangeSet|20031002082056|19757 Regards, Krzysztof From owner-linux-xfs@oss.sgi.com Fri Dec 5 15:05:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Dec 2003 15:05:51 -0800 (PST) Received: from mail.modwest.com (marshall.modwest.com [216.129.251.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB5N5dTa028450 for ; Fri, 5 Dec 2003 15:05:39 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.modwest.com (Postfix) with ESMTP id 01A4940F77BB for ; Fri, 5 Dec 2003 16:05:39 -0700 (MST) Received: from mail.modwest.com ([127.0.0.1]) by localhost (marshall.modwest.com [127.0.0.1]) (amavisd-new) with ESMTP id 13138-20 for ; Fri, 5 Dec 2003 16:05:38 -0000 (MST) Received: from d216-220-25-60.dynip.modwest.com (d216-220-25-60.dynip.modwest.com [216.220.25.60]) by mail.modwest.com (Postfix) with ESMTP id C7FE340F5CE6 for ; Fri, 5 Dec 2003 16:05:38 -0700 (MST) Date: Fri, 05 Dec 2003 16:06:17 -0700 From: Michael Loftis Cc: linux-xfs@oss.sgi.com Subject: Re: do_brk() -- kernel 2.4.20-24.9.XFS ? Message-ID: <99877343.1070640377@d216-220-25-60.dynip.modwest.com> In-Reply-To: <20031206000046.A18173@iceberg.elsat.net.pl> References: <20031204220923.GB2849@ii.uib.no> <94976265.1070635476@d216-220-25-60.dynip.modwest.com> <20031206000046.A18173@iceberg.elsat.net.pl> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new amavisd-new-20020630 X-archive-position: 1264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 879 Lines: 26 yah i finally found information that do_brk wasn't bounds checking, and came up with exactly those two lines...then got the bright idea to look at do_brk in .23 vs. .20 that I'm running and saw the same three liner :) Thanks much though, I'm sure this will help someome somewhere! :) --On Saturday, December 06, 2003 00:00 +0100 Krzysztof Rusocki wrote: > On Fri, Dec 05, 2003 at 02:44:36PM -0700, Michael Loftis wrote: >> I'm still looking for a do_brk patch itself...I've got to patch a bunch >> of 2.4.20 systems but I can't find any useful enough information on the >> actual patch. > > There it goes ;) > http://linux.bkbits.net:8080/linux-2.4/diffs/mm/mmap.c@1.32?nav=cset@marc > elo@dmt.cyclades|ChangeSet|20031002082056|19757 > > Regards, > Krzysztof -- GPG/PGP --> 0xE736BD7E 5144 6A2D 977A 6651 DFBE 1462 E351 88B9 E736 BD7E From owner-linux-xfs@oss.sgi.com Fri Dec 5 23:29:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 05 Dec 2003 23:29:29 -0800 (PST) Received: from SAGAN3 (200-162-193-68.sao.ajato.com.br [200.162.193.68] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB67TGTa012462 for ; Fri, 5 Dec 2003 23:29:17 -0800 Received: from mail pickup service by SAGAN3 with Microsoft SMTPSVC; Sat, 6 Dec 2003 05:29:18 -0300 Thread-Topic: [nosso-grupo] AVISO: Migre seu grupo NG-Return-Path: To: "nosso-grupo@nossogrupo.com.br" Content-Class: urn:content-classes:message Reply-To: Received: from fernanda.labone.net ([200.232.50.28]) by sagan.nossogrupo.com.br with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Dec 2003 15:43:39 -0200 Received: from 200-232-50-29.customer.tdatabrasil.net.br (200-232-50-29.customer.tdatabrasil.net.br [200.232.50.29] (may be forged)) by fernanda.labone.net (8.12.5/8.12.5) with SMTP id hB4FxjP0013955 for ; Thu, 4 Dec 2003 13:59:45 -0200 From: "Nosso Grupo" Message-ID: <069001c3bbd1$d2138740$0b03a8c0@SAGAN3> Content-Type: text/plain; charset="iso-8859-1" Subject: [nosso-grupo] AVISO: Migre seu grupo Date: Sat, 6 Dec 2003 05:20:34 -0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: NGDispatcher141 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 04 Dec 2003 17:43:39.0814 (UTC) FILETIME=[26F3CC60:01C3BA8E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hB67TITa012464 X-archive-position: 1265 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mailer@nossogrupo.com.br Precedence: bulk X-list: linux-xfs Content-Length: 2387 Lines: 60 Caro integrante do Nosso Grupo, Como é de seu conhecimento, a partir de 19 de dezembro de 2003 o site Nosso Grupo será descontinuado. Em comunicado enviado nos dias 20 e 21 de novembro, explicamos que o site deixará de ser aberto a todos internautas, passando a ser ferramenta exclusiva das publicaçőes Abril e de suas comunidades. Saiba mais sobre isso lendo os AVISOS IMPORTANTES abaixo. Enviamos esta nova mensagem para lembrá-lo que vocę tem 15 dias para salvar as mensagens e a lista de seu grupo, antes do prazo final. Os administradores dos grupos já foram informados dos procedimentos a serem seguidos para que seja feita a cópia dos endereços de e-mail dos participantes. É muito importante que isso seja feito o mais rápido possível, já que em 15 dias os grupos existentes e as informaçőes neles contidas serăo automaticamente apagados. Caso o seu grupo já tenha feito as devidas alteraçőes, ignore esta mensagem. Lembramos ainda que o Nosso Grupo firmou uma parceria com o Yahoo! Grupos e sugere a transferęncia para o site http://br.groups.yahoo.com . Com isso, vocę poderá manter a sua comunidade ativa, além de contar com o maior serviço de grupos de discussăo do Brasil. Para mais informaçőes sobre o Yahoo! Grupos visite http://br.yahoo.com/info/nossogrupo.html Caso queira criar um novo grupo e/ou incluir novos participantes nos seus grupos atuais, faça isso já no site do Yahoo! Grupos (http://br.yahoo.com/info/nossogrupo.html). ATENÇĂO: Se vocę participa de mais de um grupo poderá receber mais de um comunicado. Pedimos desculpas pelos eventuais transtornos. Agradecemos por sua participaçăo e nos colocamos ŕ inteira disposiçăo para responder a quaisquer dúvidas que possam surgir. Entre em contato pelo e-mail nossogrupo@abril.com.br Atenciosamente, Equipe Nosso Grupo * Termo de responsabilidade do Nosso Grupo http://nossogrupo.abril.com.br/termoresp.htm * Como abrir minha conta no Yahoo! Grupos? http://help.yahoo.com/help/br/groups/groups-48.html * Como faço para transferir minha lista de e-mails para o Yahoo! Grupos? http://help.yahoo.com/help/br/groups/groups-06.html * O que é o Yahoo! Grupos? http://help.yahoo.com/help/br/groups/groups-01.html * Quanto custa para usar o Yahoo! Grupos? http://help.yahoo.com/help/br/groups/groups-02.html * Como faço para iniciar um novo grupo? http://help.yahoo.com/help/br/groups/groups-23.html From owner-linux-xfs@oss.sgi.com Sun Dec 7 08:55:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Dec 2003 08:56:05 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB7GtpTa013044 for ; Sun, 7 Dec 2003 08:55:52 -0800 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id hB7GtP1A021689; Sun, 7 Dec 2003 11:55:25 -0500 (EST) Date: Sun, 7 Dec 2003 11:55:25 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: Jeremy Jackson cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Kernel panic, SB validate failed In-Reply-To: <007301c3bb62$ecf31a90$282a6618@ddns.coplanar.net> Message-ID: References: <3FCF7131.9080703@adic.com> <007301c3bb62$ecf31a90$282a6618@ddns.coplanar.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1266 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 719 Lines: 17 Hi, Thanks for all who helped regarding this problem. I though I would tell the solution so it an be closed. The bottom line is that it wasn't directly an XFS problem, but rather hardware. Steve's detective work - suggesting that the cable might be bad - was very close to the true cause. I ran smartctl, and it reported a bunch of errors for the disk. Then I replaced the cable, but the filesystem was already screwed. After inspection of the harddrive I noticed that one of the small pins that plug in the ATA cable is broken (bent), and also that the cable is suspicious (old and shows some wear). It is still a mystery how the hdd worked with one pin not in contact, and suddenly failed... Best wishes Gaspar From owner-linux-xfs@oss.sgi.com Sun Dec 7 09:14:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Dec 2003 09:15:09 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB7HEwTa013675 for ; Sun, 7 Dec 2003 09:14:58 -0800 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id hB7HEvVd022250 for ; Sun, 7 Dec 2003 12:14:57 -0500 (EST) Date: Sun, 7 Dec 2003 12:14:57 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: advice: 3ware+raid+xfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1267 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 1368 Lines: 32 Dear all, I am about to build a system for data reduction, but before I do so, I thought of posting this in case anyone has useful hints (don't do that!, or be careful with...) It would be a dual xeon mobo + 3ware Escalade card + 4x250Gb (WD) disk, running most probably RH9.0 and kernel 2.4.22-xfs. I haven't decided yet about the arrangement of the 4x250Gb disks, but definitely there will be XFS on them. My possibilities are: (I need total space more than 500Gb) 1. JBOD, each disk one partition (drawback: I have to take care of not filling either of them) 2. RAID-0, one single 1Tb XFS partition 3. RAID-5 Any advice would be welcome. I guess people have done this, and have experience. E.g.issues related to XFS when one disk fails, and has to be replaced. Or mkfs/xfs parameters ideal for mostly relatively big files (8Mb and 16Mb) accompanied with very small files (<1kB). Recovery issues: I saw xfs_check run out of memory on a single 120Gb partition after an unexpected power failure. 3Ware configuration issues that might be related to XFS, speed, efficiency. If the above ide, however, seems viable, just ignore this email. Being an astronomer, I am not that experienced with sw/hw issues... I was always wondering when people write "we have been testing XFS with 60Tb filesystems" (and other magic numbers) - how they do that? Best wishes Gaspar From owner-linux-xfs@oss.sgi.com Sun Dec 7 09:24:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Dec 2003 09:24:13 -0800 (PST) Received: from office.labsysgrp.com (wsip-68-14-236-254.ph.ph.cox.net [68.14.236.254]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB7HO1Ta014165 for ; Sun, 7 Dec 2003 09:24:02 -0800 Received: from [127.0.0.1] (helo=localhost) by office.labsysgrp.com with esmtp (Exim 4.24) id 1AT2dQ-0003XL-1R for linux-xfs@oss.sgi.com; Sun, 07 Dec 2003 10:23:56 -0700 Received: from office.labsysgrp.com ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13143-09 for ; Sun, 7 Dec 2003 10:23:43 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.labsysgrp.com with esmtp (Exim 4.24) id 1AT2dD-0003XF-Ec for linux-xfs@oss.sgi.com; Sun, 07 Dec 2003 10:23:43 -0700 Received: from [192.168.172.107] (helo=backtobasicsmgmt.com) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1AT2ci-00022V-00 for linux-xfs@oss.sgi.com; Sun, 07 Dec 2003 10:23:12 -0700 Message-ID: <3FD36204.9020101@backtobasicsmgmt.com> Date: Sun, 07 Dec 2003 10:23:16 -0700 From: "Kevin P. Fleming" Organization: Back to Basics Network Management User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: advice: 3ware+raid+xfs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 1268 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 994 Lines: 26 Gaspar Bakos wrote: > XFS on them. My possibilities are: (I need total space more than 500Gb) > 1. JBOD, each disk one partition > (drawback: I have to take care of not filling either of them) This will be difficult to manage. > 2. RAID-0, one single 1Tb XFS partition This means if you lose one disk (or even temporarily lose access to one disk) your entire filesystem is unusable. If all this data is easily regeneratable from elsewhere this might be acceptable for you. > 3. RAID-5 The best choice, gives you 750GB usable space and protection against a single disk failure. The most flexible solution will be to add a third component to the mix, that being a volume manager of some type (LVM2 or EVMS). If you make a single RAID-5 of 750GB, then use LVM2 on top of it, you can carve it up into whatever size slices you like and even increase slices at a later time (if you have free space left or add more disks). I use 3ware+LVM2+XFS and am very happy with the combination. From owner-linux-xfs@oss.sgi.com Sun Dec 7 13:21:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Dec 2003 13:21:48 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB7LLITa021721 for ; Sun, 7 Dec 2003 13:21:19 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 4C8611400F4D; Sun, 7 Dec 2003 16:21:32 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id D6B9D1437123; Sun, 7 Dec 2003 16:21:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id C5D013020E1E; Sun, 7 Dec 2003 16:21:30 -0500 (EST) Date: Sun, 7 Dec 2003 16:21:30 -0500 (EST) From: Mike Burger To: Gaspar Bakos Cc: linux-xfs@oss.sgi.com Subject: Re: advice: 3ware+raid+xfs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1270 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 1939 Lines: 56 FWIW, I'm running XFS 1.3.1 on a 3Ware card, with mirrored 80GB WD drives. I've run into absolutely no problems. On Sun, 7 Dec 2003, Gaspar Bakos wrote: > Dear all, > > I am about to build a system for data reduction, but before I do so, I > thought of posting this in case anyone has useful hints (don't do that!, > or be careful with...) > > It would be a dual xeon mobo + 3ware Escalade card + 4x250Gb (WD) disk, > running most probably RH9.0 and kernel 2.4.22-xfs. I haven't decided yet > about the arrangement of the 4x250Gb disks, but definitely there will be > XFS on them. My possibilities are: (I need total space more than 500Gb) > 1. JBOD, each disk one partition > (drawback: I have to take care of not filling either of them) > 2. RAID-0, one single 1Tb XFS partition > 3. RAID-5 > > Any advice would be welcome. I guess people have done this, and > have experience. E.g.issues related to XFS when one disk > fails, and has to be replaced. Or mkfs/xfs parameters ideal for mostly > relatively big files (8Mb and 16Mb) accompanied with very small files > (<1kB). Recovery issues: I saw xfs_check run out of memory on a single > 120Gb partition after an unexpected power failure. 3Ware configuration > issues that might be related to XFS, speed, efficiency. > > If the above ide, however, seems viable, just ignore this email. > > Being an astronomer, I am not that experienced with sw/hw issues... > I was always wondering when people write "we have been testing XFS with > 60Tb filesystems" (and other magic numbers) - how they do that? > > Best wishes > Gaspar > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Sun Dec 7 14:29:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Dec 2003 14:29:27 -0800 (PST) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB7MTGTa022712 for ; Sun, 7 Dec 2003 14:29:16 -0800 Received: from [10.1.2.221] (localhost [127.0.0.1]) by shell.wgops.com (Postfix) with ESMTP id B1A4125539; Sun, 7 Dec 2003 15:29:07 -0700 (MST) Date: Sun, 07 Dec 2003 15:28:08 -0700 From: Michael Loftis To: gbakos@cfa.harvard.edu, linux-xfs@oss.sgi.com Subject: Re: advice: 3ware+raid+xfs Message-ID: <5328562.1070810888@[10.1.2.221]> In-Reply-To: References: X-Mailer: Mulberry/3.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-MailScanner-Information: Please contact support@wgops.com X-MailScanner: WGOPS clean X-archive-position: 1271 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 2608 Lines: 64 Depending on your 3Ware card, try to create a RAID with 128K or 256K stripes....128K is the 'normal' blocking factor the kernel uses when combining reads and writes. Presuming you're doing mostly sequential access a 128K stripe would be optimal. Now RAID0, vs RAID5 depends....Can you suffer losing a disk and thus losing *all* the data? In RAID0 there is no redundancy, but it is *FAST* very fast. in RAID5 you can lose a drive and run ok well enough to replace the drive and rebuild the arry. RAID5 has some performance penalty, you'll have to look up benchmarks or perform your own to find out exactly what the penalty is. For this much data I would recommend a RAID, and presuming oyu can handle the performance drop RAID5, unless the data is replicated elsewhere and totally non-critical then go ahead and go RAID0 for some pretty blazing fast speeds. --On Sunday, December 07, 2003 12:14 PM -0500 Gaspar Bakos wrote: > Dear all, > > I am about to build a system for data reduction, but before I do so, I > thought of posting this in case anyone has useful hints (don't do that!, > or be careful with...) > > It would be a dual xeon mobo + 3ware Escalade card + 4x250Gb (WD) disk, > running most probably RH9.0 and kernel 2.4.22-xfs. I haven't decided yet > about the arrangement of the 4x250Gb disks, but definitely there will be > XFS on them. My possibilities are: (I need total space more than 500Gb) > 1. JBOD, each disk one partition > (drawback: I have to take care of not filling either of them) > 2. RAID-0, one single 1Tb XFS partition > 3. RAID-5 > > Any advice would be welcome. I guess people have done this, and > have experience. E.g.issues related to XFS when one disk > fails, and has to be replaced. Or mkfs/xfs parameters ideal for mostly > relatively big files (8Mb and 16Mb) accompanied with very small files > (<1kB). Recovery issues: I saw xfs_check run out of memory on a single > 120Gb partition after an unexpected power failure. 3Ware configuration > issues that might be related to XFS, speed, efficiency. > > If the above ide, however, seems viable, just ignore this email. > > Being an astronomer, I am not that experienced with sw/hw issues... > I was always wondering when people write "we have been testing XFS with > 60Tb filesystems" (and other magic numbers) - how they do that? > > Best wishes > Gaspar > > -- Undocumented Features quote of the moment... "It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.'" --Murphy's Laws of Combat From owner-linux-xfs@oss.sgi.com Sun Dec 7 16:35:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Dec 2003 16:35:13 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB80Z1Ta028363 for ; Sun, 7 Dec 2003 16:35:01 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB80uGHc022157 for ; Sun, 7 Dec 2003 18:56:18 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB80XYqH055437 for ; Mon, 8 Dec 2003 11:33:35 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hB80XXS0055426 for linux-xfs@oss.sgi.com; Mon, 8 Dec 2003 11:33:33 +1100 (EST) Date: Mon, 8 Dec 2003 11:33:33 +1100 (EST) From: Nathan Scott Message-Id: <200312080033.hB80XXS0055426@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - tweak direct read interface X-archive-position: 1272 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 324 Lines: 13 Make do_generic_direct_read optionally inline. Date: Sun Dec 7 16:32:04 PST 2003 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:163055a linux/mm/filemap.c - 1.124 linux/include/linux/fs.h - 1.170 From owner-linux-xfs@oss.sgi.com Sun Dec 7 20:54:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Dec 2003 20:54:34 -0800 (PST) Received: from 192-246.netfront.net (246-192.netfront.net [202.81.246.192]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB84sATa004149 for ; Sun, 7 Dec 2003 20:54:16 -0800 Received: from linuxmail.org (localhost.netfront.net [127.0.0.1]) by 192-246.netfront.net (Postfix) with ESMTP id CF0BAEAF9C for ; Mon, 8 Dec 2003 12:54:02 +0800 (HKT) Message-ID: <3FD403E9.5050801@linuxmail.org> Date: Mon, 08 Dec 2003 12:54:01 +0800 From: Feizhou User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: linux-xfs@oss.sgi.com Subject: Re: advice: 3ware+raid+xfs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1273 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: feizhou@linuxmail.org Precedence: bulk X-list: linux-xfs Content-Length: 1133 Lines: 27 Gaspar Bakos wrote: > Dear all, > > I am about to build a system for data reduction, but before I do so, I > thought of posting this in case anyone has useful hints (don't do that!, > or be careful with...) > > It would be a dual xeon mobo + 3ware Escalade card + 4x250Gb (WD) disk, you will want to make the firmware/bios of the harddisks and the 3ware are compatible or go for maxtors. The latest should be safe otherwise you are going have funny things happen with your WD drives. > running most probably RH9.0 and kernel 2.4.22-xfs. I haven't decided yet > about the arrangement of the 4x250Gb disks, but definitely there will be > XFS on them. My possibilities are: (I need total space more than 500Gb) > 1. JBOD, each disk one partition > (drawback: I have to take care of not filling either of them) > 2. RAID-0, one single 1Tb XFS partition if you can afford to lose your data and restore and the downtime > 3. RAID-5 if you have a lot of write traffic and cannot afford to have this storage performing absymally for any length of time i suggest you get an eight port card and go for raid 1+0 with 6 or 8 disks. From owner-linux-xfs@oss.sgi.com Sun Dec 7 21:41:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Dec 2003 21:41:53 -0800 (PST) Received: from ngate.noida.hcltech.com ([202.54.110.230]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB85fFTa005131 for ; Sun, 7 Dec 2003 21:41:19 -0800 Received: from exch-01.noida.hcltech.com (exch-01 [204.160.254.29]) by ngate.noida.hcltech.com (8.12.8/8.12.8) with ESMTP id hB86Jbwa022746 for ; Mon, 8 Dec 2003 11:49:37 +0530 Received: by exch-01.noida.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 11:14:25 +0530 Message-ID: <1B3885BC15C7024C845AAC78314766C55E4F94@exch-01.noida.hcltech.com> From: "Salil Taneja, Noida" To: "'linux-xfs@oss.sgi.com.'" Cc: "Salil Taneja, Noida" Subject: xfstests Date: Mon, 8 Dec 2003 11:14:18 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1274 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: salilt@noida.hcltech.com Precedence: bulk X-list: linux-xfs Content-Length: 466 Lines: 26 hi I need to download xfstests . There are no packages corresponding to it . I think the only way to get them is through cvs repository , but cvs on oss.sgi.com is down probably . It stops responding when i enter the password . Can you suggest some solution. Thanks and Regards, Salil Taneja HCLT NetCentric Division, A11, Sector 16, Noida, India. * office: +91-120-2510701 Ext 3155 * cell: +91-9810250247 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Dec 7 22:53:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Dec 2003 22:54:09 -0800 (PST) Received: from ngate.noida.hcltech.com ([202.54.110.230]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB86rlTa006529 for ; Sun, 7 Dec 2003 22:53:50 -0800 Received: from exch-01.noida.hcltech.com (exch-01 [204.160.254.29]) by ngate.noida.hcltech.com (8.12.8/8.12.8) with ESMTP id hB87W9wa026069 for ; Mon, 8 Dec 2003 13:02:10 +0530 Received: by exch-01.noida.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 12:26:57 +0530 Message-ID: <1B3885BC15C7024C845AAC78314766C55E4F97@exch-01.noida.hcltech.com> From: "Salil Taneja, Noida" To: "'linux-xfs@oss.sgi.com'" Subject: xfstests Date: Mon, 8 Dec 2003 12:26:53 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1275 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: salilt@noida.hcltech.com Precedence: bulk X-list: linux-xfs Content-Length: 530 Lines: 27 hi I need to download xfstests . There are no packages corresponding to it . I think the only way to get them is through cvs repository , but cvs on oss.sgi.com is down probably . It stops responding when i enter the password . Can you suggest some solution. PS : I am not a member of the mailing list, so please cc me the solution . Regards, Salil Taneja HCLT NetCentric Division, A11, Sector 16, Noida, India. * office: +91-120-2510701 Ext 3155 * cell: +91-9810250247 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Dec 8 04:16:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 04:16:37 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8CG6Ta020011 for ; Mon, 8 Dec 2003 04:16:07 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hB8CG4hl028915 for ; Mon, 8 Dec 2003 13:16:04 +0100 Message-ID: <3FD46C3A.9010000@stesmi.com> Date: Mon, 08 Dec 2003 13:19:06 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Fwd: XFS merged in 2.4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 825 Lines: 31 Thought everybody would be interested. Not everybody are on lkml. // Stefan -------- Original Message -------- Subject: XFS merged in 2.4 Date: Mon, 8 Dec 2003 09:22:16 -0200 (BRST) From: Marcelo Tosatti To: linux-kernel@vger.kernel.org FYI Christoph reviewed XFS patch which changed generic code, and it was stripped down later to a set of changes which dont modify the code behaviour (except for a few bugfixes which should have been included separately anyway) and are pretty obvious. So its that has been merged, along with fs/xfs/. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-xfs@oss.sgi.com Mon Dec 8 04:21:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 04:22:00 -0800 (PST) Received: from mail.slb.com (eurmta01.london.eur.slb.com [134.32.26.55]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8CLfTa023222 for ; Mon, 8 Dec 2003 04:21:43 -0800 Received: from conversion-daemon.eurmta01.london.eur.slb.com by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) id <0HPK00F01SAVJP@eurmta01.london.eur.slb.com> for linux-xfs@oss.sgi.com; Mon, 08 Dec 2003 12:17:45 +0000 (GMT) Received: from stavanger.westerngeco.slb.com (wgmail9.stavanger.eur.slb.com [134.32.72.36]) by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HPK008PJST9X6@eurmta01.london.eur.slb.com> for linux-xfs@oss.sgi.com; Mon, 08 Dec 2003 12:17:34 +0000 (GMT) Received: from GSTJ2W (localhost [127.0.0.1]) by stavanger.westerngeco.slb.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id hB8CDFF04532 for ; Mon, 08 Dec 2003 13:13:15 +0100 (MET) Date: Mon, 08 Dec 2003 13:17:26 +0100 From: marat Subject: kernel panic:kmem_zone_zalloc: NULL memory on KM_SLEEP request! To: linux-xfs@oss.sgi.com Message-id: <200312081317.26603.nospam-259928-001@slb.com> Organization: westerngeco MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: KMail/1.4.1 X-archive-position: 1277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nospam-259928-001@slb.com Precedence: bulk X-list: linux-xfs Content-Length: 647 Lines: 24 Experts, Recently, I had one of the xfs filesystem failed and the only message was : kernel panic:kmem_zone_zalloc: NULL memory on KM_SLEEP request! I had to reboot machine and run xfs_repair to make files system available again. I am using kernel 2.4.20 SMP and xfs version 1.3.0. Any ideas, suggestions how I can avoid this problem to happen again ? Thanks in advance, Marat -- Marat Mukhitov DP/Computer System Admin Tel. : +47 51 94 68 09 WesternGeco Fax. : +47 51 94 69 51 Stavanger, Norway E-mail: nospam-259928-001@slb.com From owner-linux-xfs@oss.sgi.com Mon Dec 8 04:27:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 04:28:09 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8CRpTa023658 for ; Mon, 8 Dec 2003 04:27:52 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 986311437156; Mon, 8 Dec 2003 07:28:10 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id D548A1437123; Mon, 8 Dec 2003 07:28:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id C4FBA3006537; Mon, 8 Dec 2003 07:28:08 -0500 (EST) Date: Mon, 8 Dec 2003 07:28:08 -0500 (EST) From: Mike Burger To: Feizhou Cc: linux-xfs@oss.sgi.com Subject: Re: advice: 3ware+raid+xfs In-Reply-To: <3FD403E9.5050801@linuxmail.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1278 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 954 Lines: 33 On Mon, 8 Dec 2003, Feizhou wrote: > Gaspar Bakos wrote: > > Dear all, > > > > I am about to build a system for data reduction, but before I do so, I > > thought of posting this in case anyone has useful hints (don't do that!, > > or be careful with...) > > > > It would be a dual xeon mobo + 3ware Escalade card + 4x250Gb (WD) disk, > > you will want to make the firmware/bios of the harddisks and the 3ware > are compatible or go for maxtors. The latest should be safe otherwise > you are going have funny things happen with your WD drives. What kind of "funny things" have you seen with WD drives? -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Mon Dec 8 04:59:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 05:00:13 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8CxpTa024676 for ; Mon, 8 Dec 2003 04:59:51 -0800 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.8/8.12.8) with ESMTP id hB8CwDil028583; Mon, 8 Dec 2003 07:58:13 -0500 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.8/8.12.8/Submit) with ESMTP id hB8CwCQo028579; Mon, 8 Dec 2003 07:58:12 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Mon, 8 Dec 2003 07:58:12 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Mike Burger cc: Feizhou , Subject: Re: advice: 3ware+raid+xfs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1279 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 687 Lines: 21 On Mon, 8 Dec 2003 at 7:28am, Mike Burger wrote > On Mon, 8 Dec 2003, Feizhou wrote: > > > > you will want to make the firmware/bios of the harddisks and the 3ware > > are compatible or go for maxtors. The latest should be safe otherwise > > you are going have funny things happen with your WD drives. > > What kind of "funny things" have you seen with WD drives? Some (and I forget what models are being discussed here) have a tendency to disappear when used in RAID type situations. Discussed here: http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=913&p_created=1047068027 -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Mon Dec 8 05:12:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 05:12:48 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB8DCQTa025322 for ; Mon, 8 Dec 2003 05:12:26 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB8DCQJl025321 for linux-xfs@oss.sgi.com; Mon, 8 Dec 2003 05:12:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB8DCOTc025306 for ; Mon, 8 Dec 2003 05:12:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB8CplOL024433; Mon, 8 Dec 2003 04:51:47 -0800 Date: Mon, 8 Dec 2003 04:51:47 -0800 Message-Id: <200312081251.hB8CplOL024433@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 294] QA 013 succeeds but leaves filesystem inconsistent X-Bugzilla-Reason: AssignedTo X-archive-position: 1280 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 475 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=294 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2003-08-12 04:51 PDT ------- XFS-1.3.1 (ftp://oss.sgi.com/projects/xfs/download/Release-1.3.1/kernel_patches/) gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113) I haven't come around trying a debug kernel yet, but it's in the pipeline. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Dec 8 06:49:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 06:49:42 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8EnSTa006445 for ; Mon, 8 Dec 2003 06:49:30 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB8CugOO003208 for ; Mon, 8 Dec 2003 04:56:42 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB8EnMP518484900; Mon, 8 Dec 2003 08:49:22 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB8EnEK29305684; Mon, 8 Dec 2003 08:49:14 -0600 (CST) Date: Mon, 8 Dec 2003 08:49:22 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jan-Frode Myklebust cc: linux-xfs@oss.sgi.com Subject: Re: do_brk() -- kernel 2.4.20-24.9.XFS ? In-Reply-To: <20031208090604.GA3153@ii.uib.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1281 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1004 Lines: 26 On Mon, 8 Dec 2003, Jan-Frode Myklebust wrote: > I still can't find any updated kernel from Axel's atrpms. > The kernels there seems all to be based on RedHats 2.4.20-20.x > without any mention of extra patches for the do_brk(). Sorry, you're right, Axel hasn't updated yet either. > I'm a bit disappointed that SGI isn't more closely following up on > security patches or redhat errata kernels. If it's "easy enough", > why not just do it, and stop pushing a kernel with a serious security > vulnerability from the project home page? Because time < demands. If I get some time I'll do it, but in the meantime it's really quite simple for anyone in the 'community' to whip this up: Install the xfs 2.4.20-20 src.rpm Install the stock 2.4.20-20 src.rpm Diff the two specfiles to see what xfs changed - adds patches, tweaks release Install the stock 2.4.20-24 src.rpm Apply the above diff to the 2.4.20-24 specfile, fix minor reject on release Rebuild from the patched 2.4.20-24 specfile -Eric From owner-linux-xfs@oss.sgi.com Mon Dec 8 06:51:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 06:51:55 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8EpiTa006869 for ; Mon, 8 Dec 2003 06:51:44 -0800 Received: from conversion-daemon.woozle.fnal.gov by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HPK00D01ZY1UU@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Mon, 08 Dec 2003 08:51:43 -0600 (CST) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTPSA id <0HPK001I7ZY5T2@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Mon, 08 Dec 2003 08:51:43 -0600 (CST) Date: Mon, 08 Dec 2003 08:51:41 -0600 From: Dan Yocum Subject: Re: Fwd: XFS merged in 2.4 In-reply-to: <3FD46C3A.9010000@stesmi.com> To: linux-xfs@oss.sgi.com Message-id: <3FD48FFD.9000404@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 References: <3FD46C3A.9010000@stesmi.com> X-archive-position: 1282 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 1110 Lines: 45 And there was much rejoicing. yaaaaaayyyy. Stefan Smietanowski wrote: > Thought everybody would be interested. Not everybody are on lkml. > > // Stefan > > > > -------- Original Message -------- > Subject: XFS merged in 2.4 > Date: Mon, 8 Dec 2003 09:22:16 -0200 (BRST) > From: Marcelo Tosatti > To: linux-kernel@vger.kernel.org > > > FYI > > Christoph reviewed XFS patch which changed generic code, and it was > stripped down later to a set of changes which dont modify the code > behaviour (except for a few bugfixes which should have been included > separately anyway) and are pretty obvious. > > So its that has been merged, along with fs/xfs/. > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > > > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. You are here. From owner-linux-xfs@oss.sgi.com Mon Dec 8 06:55:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 06:55:28 -0800 (PST) Received: from ngate.noida.hcltech.com ([202.54.110.230]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8Et6Ta007327 for ; Mon, 8 Dec 2003 06:55:10 -0800 Received: from exch-01.noida.hcltech.com (exch-01 [204.160.254.29]) by ngate.noida.hcltech.com (8.12.8/8.12.8) with ESMTP id hB8FXYwa011879 for ; Mon, 8 Dec 2003 21:03:34 +0530 Received: by exch-01.noida.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 20:28:16 +0530 Message-ID: <1B3885BC15C7024C845AAC78314766C501711281@exch-01.noida.hcltech.com> From: "Sanjay Kumar, Noida" To: linux-xfs@oss.sgi.com Subject: difficulty downloading xfs tests Date: Mon, 8 Dec 2003 20:28:12 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sanjayku@noida.hcltech.com Precedence: bulk X-list: linux-xfs Content-Length: 401 Lines: 26 I need to download xfstests . There are no packages corresponding to it . I think the only way to get them is through cvs repository , but cvs on oss.sgi.com is down probably or is very busy . It stops responding when i enter the password . Can you suggest some solution Sanjay Kumar Luck is what happens when preparation meets opportunity [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Dec 8 06:59:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 06:59:21 -0800 (PST) Received: from mail.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8Ex7Ta007791 for ; Mon, 8 Dec 2003 06:59:10 -0800 Received: from lapprose.ii.uib.no ([129.177.20.37]) by mail.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.12) id 1ATHLB-00031u-00; Mon, 08 Dec 2003 10:06:05 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.8/8.12.8/Submit) id hB8964vP003279; Mon, 8 Dec 2003 10:06:04 +0100 Date: Mon, 8 Dec 2003 10:06:04 +0100 From: Jan-Frode Myklebust To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: do_brk() -- kernel 2.4.20-24.9.XFS ? Message-ID: <20031208090604.GA3153@ii.uib.no> References: <20031204220923.GB2849@ii.uib.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Score: 0.0 (/) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1ATHLB-00031u-00*oMGjtVlY3Tk* X-archive-position: 1284 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.uib.no Precedence: bulk X-list: linux-xfs Content-Length: 703 Lines: 18 On Thu, Dec 04, 2003 at 08:23:27PM -0600, Eric Sandeen wrote: > I'd suggest getting Axel's RPM from atrpms... that's what > I just did for my home system. :) It's easy enough > for us to spin one, but now that Axel is doing this, I'm > happy to point over there... I still can't find any updated kernel from Axel's atrpms. The kernels there seems all to be based on RedHats 2.4.20-20.x without any mention of extra patches for the do_brk(). I'm a bit disappointed that SGI isn't more closely following up on security patches or redhat errata kernels. If it's "easy enough", why not just do it, and stop pushing a kernel with a serious security vulnerability from the project home page? -jf From owner-linux-xfs@oss.sgi.com Mon Dec 8 07:26:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 07:27:08 -0800 (PST) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8FQlTa008673 for ; Mon, 8 Dec 2003 07:26:47 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id hB8FTi3o029173; Mon, 8 Dec 2003 10:29:44 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id hB8FTiFm029170; Mon, 8 Dec 2003 10:29:44 -0500 Date: Mon, 8 Dec 2003 10:29:44 -0500 (EST) From: Net Llama! To: Jan-Frode Myklebust cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: do_brk() -- kernel 2.4.20-24.9.XFS ? In-Reply-To: <20031208090604.GA3153@ii.uib.no> Message-ID: References: <20031204220923.GB2849@ii.uib.no> <20031208090604.GA3153@ii.uib.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1044 Lines: 24 On Mon, 8 Dec 2003, Jan-Frode Myklebust wrote: > On Thu, Dec 04, 2003 at 08:23:27PM -0600, Eric Sandeen wrote: > > I'd suggest getting Axel's RPM from atrpms... that's what > > I just did for my home system. :) It's easy enough > > for us to spin one, but now that Axel is doing this, I'm > > happy to point over there... > > I still can't find any updated kernel from Axel's atrpms. > The kernels there seems all to be based on RedHats 2.4.20-20.x > without any mention of extra patches for the do_brk(). > > I'm a bit disappointed that SGI isn't more closely following up on > security patches or redhat errata kernels. If it's "easy enough", > why not just do it, and stop pushing a kernel with a serious security > vulnerability from the project home page? Maybe cause you can very easily build your own 2.4.23-xfs with the patch that SGI already provides? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Mon Dec 8 07:32:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 07:32:33 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8FWLTa009844 for ; Mon, 8 Dec 2003 07:32:22 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB8DdZOO007917 for ; Mon, 8 Dec 2003 05:39:35 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB8FWFP518482571; Mon, 8 Dec 2003 09:32:15 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB8FW7K29526090; Mon, 8 Dec 2003 09:32:07 -0600 (CST) Date: Mon, 8 Dec 2003 09:32:15 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "Sanjay Kumar, Noida" cc: linux-xfs@oss.sgi.com Subject: Re: difficulty downloading xfs tests In-Reply-To: <1B3885BC15C7024C845AAC78314766C501711281@exch-01.noida.hcltech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1286 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 645 Lines: 40 It's working for me now: export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs' cvs login cvs checkout xfs-cmds gets me xfs-cmds/xfstests -Eric On Mon, 8 Dec 2003, Sanjay Kumar, Noida wrote: > > I need to download xfstests . > > There are no packages corresponding to it . > I think the only way to get them is through cvs repository , but cvs on > oss.sgi.com is down probably or is very busy . > It stops responding when i enter the password . > > Can you suggest some solution > > Sanjay Kumar > > Luck is what happens when > > preparation meets opportunity > > > > > > > > > > [[HTML alternate version deleted]] > > From owner-linux-xfs@oss.sgi.com Mon Dec 8 07:36:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 07:36:18 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8Fa6Ta010295 for ; Mon, 8 Dec 2003 07:36:07 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB8FvRHc024965 for ; Mon, 8 Dec 2003 09:57:27 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB8Fa1P518501112; Mon, 8 Dec 2003 09:36:01 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1ATNQW-0000Ui-00; Mon, 08 Dec 2003 09:36:00 -0600 Date: Mon, 8 Dec 2003 09:35:58 -0600 From: Nathan Straz To: "Sanjay Kumar, Noida" Cc: linux-xfs@oss.sgi.com Subject: Re: difficulty downloading xfs tests Message-ID: <20031208153558.GC26385@sgi.com> Mail-Followup-To: "Sanjay Kumar, Noida" , linux-xfs@oss.sgi.com References: <1B3885BC15C7024C845AAC78314766C501711281@exch-01.noida.hcltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1B3885BC15C7024C845AAC78314766C501711281@exch-01.noida.hcltech.com> User-Agent: Mutt/1.5.3i X-archive-position: 1287 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 606 Lines: 15 On Mon, Dec 08, 2003 at 08:28:12PM +0530, Sanjay Kumar, Noida wrote: > I need to download xfstests . > > I think the only way to get them is through cvs repository , but cvs on > oss.sgi.com is down probably or is very busy . > It stops responding when i enter the password . It works for me. Are you following the instructions at http://oss.sgi.com/projects/xfs/cvs_download.html? -- 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 Mon Dec 8 09:33:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 09:33:19 -0800 (PST) Received: from mail.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8HX7Ta016487 for ; Mon, 8 Dec 2003 09:33:07 -0800 Received: from lapprose.ii.uib.no ([129.177.20.37]) by mail.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.12) id 1ATNW5-0000XZ-00; Mon, 08 Dec 2003 16:41:45 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.8/8.12.8/Submit) id hB8Ffint007666; Mon, 8 Dec 2003 16:41:44 +0100 Date: Mon, 8 Dec 2003 16:41:44 +0100 From: Jan-Frode Myklebust To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: do_brk() -- kernel 2.4.20-24.9.XFS ? Message-ID: <20031208154144.GA7338@ii.uib.no> References: <20031208090604.GA3153@ii.uib.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Score: 0.0 (/) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1ATNW5-0000XZ-00*prspB0Pckfk* X-archive-position: 1288 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.uib.no Precedence: bulk X-list: linux-xfs Content-Length: 526 Lines: 18 oh.. Thanks for the procedure. The SPECs are identical. The only changes they've done are two very small changes to linux-2.4.20-o1-sched+threading-backport.patch and linux-2.4.18-smallpatches.patch. So, this should be enough to build it: rpm -ivh kernel-2.4.20-20.9.XFS1.3.1.src.rpm rpm -ivh kernel-2.4.20-24.9.src.rpm cd ~/rpm/SPEC # or 'cd /usr/src/redhat/SPECS' sed 's/20.9.XFS1.3.1/24.9.XFS1.3.1/' kernel-2.4.20.XFS1.3.1.spec > kernel-2.4.24.XFS1.3.1.spec rpmbuild -ba kernel-2.4.24.XFS1.3.1.spec -jf From owner-linux-xfs@oss.sgi.com Mon Dec 8 11:31:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 11:32:03 -0800 (PST) Received: from imf21aec.mail.bellsouth.net (imf21aec.mail.bellsouth.net [205.152.59.69]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8JVpTa018721 for ; Mon, 8 Dec 2003 11:31:51 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf21aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031208193145.MHSX1940.imf21aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Mon, 8 Dec 2003 14:31:45 -0500 Subject: Re: Fwd: XFS merged in 2.4 From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Stefan Smietanowski Cc: linux-xfs@oss.sgi.com In-Reply-To: <3FD46C3A.9010000@stesmi.com> References: <3FD46C3A.9010000@stesmi.com> Content-Type: text/plain Message-Id: <1070909208.4918.0.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Rubber Turnip www.usr-local-bin.org Date: Mon, 08 Dec 2003 14:26:43 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1289 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 1010 Lines: 40 That means XFS should be in 2.4.24? Or in a later version. On Mon, 2003-12-08 at 07:19, Stefan Smietanowski wrote: > Thought everybody would be interested. Not everybody are on lkml. > > // Stefan > > > > -------- Original Message -------- > Subject: XFS merged in 2.4 > Date: Mon, 8 Dec 2003 09:22:16 -0200 (BRST) > From: Marcelo Tosatti > To: linux-kernel@vger.kernel.org > > > FYI > > Christoph reviewed XFS patch which changed generic code, and it was > stripped down later to a set of changes which dont modify the code > behaviour (except for a few bugfixes which should have been included > separately anyway) and are pretty obvious. > > So its that has been merged, along with fs/xfs/. > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > > From owner-linux-xfs@oss.sgi.com Mon Dec 8 11:50:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 11:51:09 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8JovTa019304 for ; Mon, 8 Dec 2003 11:50:58 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hB8Jn5PK003579 for ; Mon, 8 Dec 2003 13:49:05 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB8Jn5Gb003577 for linux-xfs@oss.sgi.com; Mon, 8 Dec 2003 13:49:05 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: Fwd: XFS merged in 2.4 From: Austin Gonyou To: XFS List In-Reply-To: <3FD48FFD.9000404@fnal.gov> References: <3FD48FFD.9000404@fnal.gov> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1070912945.2453.51.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 08 Dec 2003 13:49:05 -0600 X-archive-position: 1290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1360 Lines: 52 I second that. :) Thanks Marcello and the XFS team. On Mon, 2003-12-08 at 08:51, Dan Yocum wrote: > And there was much rejoicing. > > yaaaaaayyyy. > > Stefan Smietanowski wrote: > > Thought everybody would be interested. Not everybody are on lkml. > > > > // Stefan > > > > > > > > -------- Original Message -------- > > Subject: XFS merged in 2.4 > > Date: Mon, 8 Dec 2003 09:22:16 -0200 (BRST) > > From: Marcelo Tosatti > > To: linux-kernel@vger.kernel.org > > > > > > FYI > > > > Christoph reviewed XFS patch which changed generic code, and it was > > stripped down later to a set of changes which dont modify the code > > behaviour (except for a few bugfixes which should have been included > > separately anyway) and are pretty obvious. > > > > So its that has been merged, along with fs/xfs/. > > > > > > > > - > > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > > > > -- > Dan Yocum > Sloan Digital Sky Survey, Fermilab 630.840.6509 > yocum@fnal.gov, http://www.sdss.org > SDSS. Mapping the Universe. You are here. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Mon Dec 8 11:52:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 11:52:50 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8JqcTa019708 for ; Mon, 8 Dec 2003 11:52:38 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hB8JokPK003596 for ; Mon, 8 Dec 2003 13:50:46 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB8JokYt003594 for linux-xfs@oss.sgi.com; Mon, 8 Dec 2003 13:50:46 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: Fwd: XFS merged in 2.4 From: Austin Gonyou To: XFS List In-Reply-To: <1070909208.4918.0.camel@david.internal.NorcrossGroup.com> References: <1070909208.4918.0.camel@david.internal.NorcrossGroup.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1070913046.2449.53.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 08 Dec 2003 13:50:46 -0600 X-archive-position: 1291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1372 Lines: 49 I'm also kind of curious about the replication of updates and backporting of bug fixes, etc from 2.6 and vice versa. i.e. will XFS version for 2.6 and 2.4 remain in-sync? On Mon, 2003-12-08 at 13:26, Greg Freemyer wrote: > That means XFS should be in 2.4.24? > > Or in a later version. > > > On Mon, 2003-12-08 at 07:19, Stefan Smietanowski wrote: > > Thought everybody would be interested. Not everybody are on lkml. > > > > // Stefan > > > > > > > > -------- Original Message -------- > > Subject: XFS merged in 2.4 > > Date: Mon, 8 Dec 2003 09:22:16 -0200 (BRST) > > From: Marcelo Tosatti > > To: linux-kernel@vger.kernel.org > > > > > > FYI > > > > Christoph reviewed XFS patch which changed generic code, and it was > > stripped down later to a set of changes which dont modify the code > > behaviour (except for a few bugfixes which should have been included > > separately anyway) and are pretty obvious. > > > > So its that has been merged, along with fs/xfs/. > > > > > > > > - > > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Mon Dec 8 12:06:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 12:06:33 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8K6LTa020433 for ; Mon, 8 Dec 2003 12:06:21 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB8KRgHc021121 for ; Mon, 8 Dec 2003 14:27:42 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB8K5FP518574016; Mon, 8 Dec 2003 14:05:15 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB8K57K19563920; Mon, 8 Dec 2003 14:05:07 -0600 (CST) Subject: Re: Fwd: XFS merged in 2.4 From: Eric Sandeen To: Austin Gonyou Cc: XFS List In-Reply-To: <1070913046.2449.53.camel@localhost.localdomain> References: <1070909208.4918.0.camel@david.internal.NorcrossGroup.com> <1070913046.2449.53.camel@localhost.localdomain> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1070913915.9510.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 08 Dec 2003 14:05:15 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1292 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 524 Lines: 17 On Mon, 2003-12-08 at 13:50, Austin Gonyou wrote: > I'm also kind of curious about the replication of updates and > backporting of bug fixes, etc from 2.6 and vice versa. > > i.e. will XFS version for 2.6 and 2.4 remain in-sync? In code you get from SGI (cvs, etc) - yes, almost in lock-step. In code you get from Marcelo and Linus, there will be gaps due to different release schedules. -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Dec 8 12:30:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 12:30:37 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8KUKTa024007 for ; Mon, 8 Dec 2003 12:30:23 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hB8KTIhl003643; Mon, 8 Dec 2003 21:29:19 +0100 Message-ID: <3FD4DFD5.2010208@stesmi.com> Date: Mon, 08 Dec 2003 21:32:21 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freemyer-ml@NorcrossGroup.com CC: linux-xfs@oss.sgi.com Subject: Re: Fwd: XFS merged in 2.4 References: <3FD46C3A.9010000@stesmi.com> <1070909208.4918.0.camel@david.internal.NorcrossGroup.com> In-Reply-To: <1070909208.4918.0.camel@david.internal.NorcrossGroup.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1293 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 854 Lines: 37 Greg Freemyer wrote: > That means XFS should be in 2.4.24? > > Or in a later version. > > > On Mon, 2003-12-08 at 07:19, Stefan Smietanowski wrote: > >>Thought everybody would be interested. Not everybody are on lkml. >> >>// Stefan >> >> >> >>-------- Original Message -------- >>Subject: XFS merged in 2.4 >>Date: Mon, 8 Dec 2003 09:22:16 -0200 (BRST) >>From: Marcelo Tosatti >>To: linux-kernel@vger.kernel.org >> >> >>FYI >> >>Christoph reviewed XFS patch which changed generic code, and it was >>stripped down later to a set of changes which dont modify the code >>behaviour (except for a few bugfixes which should have been included >>separately anyway) and are pretty obvious. >> >>So its that has been merged, along with fs/xfs/. >> >> It's in the latest BK that will eventually become 2.4.24 yes. // Stefan From owner-linux-xfs@oss.sgi.com Mon Dec 8 12:31:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 12:31:26 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8KVDTa024201 for ; Mon, 8 Dec 2003 12:31:14 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hB8KV9hl003666; Mon, 8 Dec 2003 21:31:09 +0100 Message-ID: <3FD4E044.3030008@stesmi.com> Date: Mon, 08 Dec 2003 21:34:12 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Austin Gonyou , XFS List Subject: Re: Fwd: XFS merged in 2.4 References: <1070909208.4918.0.camel@david.internal.NorcrossGroup.com> <1070913046.2449.53.camel@localhost.localdomain> <1070913915.9510.11.camel@stout.americas.sgi.com> In-Reply-To: <1070913915.9510.11.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 724 Lines: 27 Eric Sandeen wrote: > On Mon, 2003-12-08 at 13:50, Austin Gonyou wrote: > >>I'm also kind of curious about the replication of updates and >>backporting of bug fixes, etc from 2.6 and vice versa. >> >>i.e. will XFS version for 2.6 and 2.4 remain in-sync? > > > In code you get from SGI (cvs, etc) - yes, almost in lock-step. > > In code you get from Marcelo and Linus, there will be gaps due to > different release schedules. > > -Eric > The important step is that after all this time XFS will finally be in both stable and experimental kernels as a default option. ... unless of course 2.6.0 comes out before 2.4.24 does in which case XFS will be in the latest stable and the previous stable series :) // Stefan From owner-linux-xfs@oss.sgi.com Mon Dec 8 13:44:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 13:44:30 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB8Li9Ta028651 for ; Mon, 8 Dec 2003 13:44:09 -0800 Received: from stout.americas.sgi.com ([128.162.232.50]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB8JpLOO009815 for ; Mon, 8 Dec 2003 11:51:21 -0800 Received: from stout.americas.sgi.com (localhost [127.0.0.1]) by stout.americas.sgi.com (8.12.8/8.12.8) with ESMTP id hB8LhctZ011741; Mon, 8 Dec 2003 15:43:39 -0600 Received: (from sandeen@localhost) by stout.americas.sgi.com (8.12.8/8.12.8/Submit) id hB8Lhc14011739; Mon, 8 Dec 2003 15:43:38 -0600 Date: Mon, 8 Dec 2003 15:43:38 -0600 From: Eric Sandeen Message-Id: <200312082143.hB8Lhc14011739@stout.americas.sgi.com> Subject: PARTIAL TAKE 906019 - X-archive-position: 1295 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@stout.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 399 Lines: 15 Update xfs_showargs to reflect all current mount options Date: Mon Dec 8 13:43:16 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:163102a linux/fs/xfs/xfs_vfsops.c - 1.442 - Update xfs_showargs to reflect all current mount options From owner-linux-xfs@oss.sgi.com Mon Dec 8 18:51:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 18:51:58 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB92pbTa004581 for ; Mon, 8 Dec 2003 18:51:38 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hB90wpOO027082 for ; Mon, 8 Dec 2003 16:58:51 -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 NAA10490; Tue, 9 Dec 2003 13:51:26 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB92pKUc2218107; Tue, 9 Dec 2003 13:51:21 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hB92orku001993; Tue, 9 Dec 2003 13:50:55 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hB92odf3001991; Tue, 9 Dec 2003 13:50:39 +1100 Date: Tue, 9 Dec 2003 13:50:39 +1100 From: Nathan Scott To: marat Cc: linux-xfs@oss.sgi.com Subject: Re: kernel panic:kmem_zone_zalloc: NULL memory on KM_SLEEP request! Message-ID: <20031209025039.GB1798@frodo> References: <200312081317.26603.nospam-259928-001@slb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312081317.26603.nospam-259928-001@slb.com> User-Agent: Mutt/1.5.3i X-archive-position: 1296 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1191 Lines: 33 On Mon, Dec 08, 2003 at 01:17:26PM +0100, marat wrote: > Experts, > > Recently, I had one of the xfs filesystem failed and the only message was : > kernel panic:kmem_zone_zalloc: NULL memory on KM_SLEEP request! > > I had to reboot machine and run xfs_repair to make files system available again. > > I am using kernel 2.4.20 SMP and xfs version 1.3.0. > > Any ideas, suggestions how I can avoid this problem to happen again ? > Well, whats happened here is XFS is allocating memory from a context where it cannot fail, and retries the allocation a number of times (6 IIRC, with delays in-between each) and after freeing up everything that XFS can itself. Afterward if we still cannot get any memory allocated we give up and call BUG(). I guess we could keep retrying indefinitely, but that doesn't seem like a particularly good solution. I suspect we should be getting a bit more help from the VM here (more recent 2.4 kernels might make this case better) ... you may be able to tweak some variables in mm/vmscan.c too - these are likely sysctls somewhere - vm_mapped_ratio, vm_vfs_scan_ratio, etc (ah, have a look through "vm_table" in kernel/sysctl.c). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Dec 8 19:22:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 19:22:39 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB93MSTa005332 for ; Mon, 8 Dec 2003 19:22:28 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB91TeOO005046 for ; Mon, 8 Dec 2003 17:29:42 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB93L2qH417081 for ; Tue, 9 Dec 2003 14:21:02 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hB93L1iH416072 for linux-xfs@oss.sgi.com; Tue, 9 Dec 2003 14:21:01 +1100 (EST) Date: Tue, 9 Dec 2003 14:21:01 +1100 (EST) From: Nathan Scott Message-Id: <200312090321.hB93L1iH416072@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - several small fixes X-archive-position: 1297 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1701 Lines: 67 No need to initialise struct xfs_trans field to null after a zalloc. Date: Mon Dec 8 16:03:48 PST 2003 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-linux:slinx:163115a linux/fs/xfs/xfs_trans.c - 1.154 Remove some spurious double semi-colons. Date: Mon Dec 8 16:06:12 PST 2003 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-linux:slinx:163116a linux/fs/xfs/xfs_log.c - 1.288 linux/fs/xfs/xfs_rename.c - 1.58 linux/fs/xfs/quota/xfs_dquot.c - 1.9 Fix async pagebuf I/O tracing at the bottom of pagebuf_get. Date: Mon Dec 8 16:13:42 PST 2003 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-linux:slinx:163118a linux/fs/xfs/pagebuf/page_buf.c - 1.145 Fix a small pagebuf memory leak and keep track of slab pages ourselves. Date: Mon Dec 8 16:56:37 PST 2003 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-linux:slinx:163124a linux/fs/xfs/pagebuf/page_buf.c - 1.146 linux/fs/xfs/pagebuf/page_buf.h - 1.79 Fix an XFS release_page case where unwritten extents may cause I/O incorrectly. Date: Mon Dec 8 19:18:33 PST 2003 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-linux:slinx:163128a linux/fs/xfs/linux/xfs_aops.c - 1.61 From owner-linux-xfs@oss.sgi.com Mon Dec 8 19:38:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 19:38:14 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB93c2Ta005872 for ; Mon, 8 Dec 2003 19:38:03 -0800 Received: from [192.168.10.75] (c-24-98-62-33.atl.client2.attbi.com[24.98.62.33]) by comcast.net (sccrmhc11) with SMTP id <2003120718553701100qtsoce>; Sun, 7 Dec 2003 18:55:37 +0000 Subject: Re: advice: 3ware+raid+xfs From: Danny Cox To: gbakos@cfa.harvard.edu Cc: XFS Mailing List In-Reply-To: References: Content-Type: text/plain Organization: No Organization at ALL Message-Id: <1070823336.1358.5.camel@pip> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 07 Dec 2003 13:55:36 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1298 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: danscox@mindspring.com Precedence: bulk X-list: linux-xfs Content-Length: 794 Lines: 23 Gaspar, On Sun, 2003-12-07 at 12:14, Gaspar Bakos wrote: > I am about to build a system for data reduction, but before I do so, I > thought of posting this in case anyone has useful hints (don't do that!, > or be careful with...) > > It would be a dual xeon mobo + 3ware Escalade card + 4x250Gb (WD) disk, > running most probably RH9.0 and kernel 2.4.22-xfs. I haven't decided yet You really should consider 2.4.23, or at least apply the patch to do_brk() that 2.4.23 fixed. Of course, if this is a stand-alone machine with no other logins, you may not care. Either I'm getting more paranoid in my old age, or the security guys are beginning to rub off on me.... ;-) -- kernel, n.: A part of an operating system that preserves the medieval traditions of sorcery and black art. Danny From owner-linux-xfs@oss.sgi.com Mon Dec 8 21:05:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Dec 2003 21:05:32 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB955ATa011675 for ; Mon, 8 Dec 2003 21:05:10 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB93CPOO008791 for ; Mon, 8 Dec 2003 19:12:26 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB9552qH456556 for ; Tue, 9 Dec 2003 16:05:03 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hB9552hW451021 for linux-xfs@oss.sgi.com; Tue, 9 Dec 2003 16:05:02 +1100 (EST) Date: Tue, 9 Dec 2003 16:05:02 +1100 (EST) From: Nathan Scott Message-Id: <200312090505.hB9552hW451021@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix comment X-archive-position: 1299 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 372 Lines: 13 Should not insert extra comments right before checkin! - add in a missing comment-closing delimiter. Thanks Chris. Date: Mon Dec 8 21:03:02 PST 2003 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-linux:slinx:163131a linux/fs/xfs/pagebuf/page_buf.h - 1.80 From owner-linux-xfs@oss.sgi.com Tue Dec 9 00:19:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 00:19:48 -0800 (PST) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB98JHTa007919 for ; Tue, 9 Dec 2003 00:19:17 -0800 Received: from erbenson.alaska.net (110-pm2.nwc.alaska.net [209.112.138.110]) by iris.acsalaska.net (8.12.10/8.12.10) with ESMTP id hB98JCDf027093 for ; Mon, 8 Dec 2003 23:19:13 -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 1221939E3 for ; Mon, 8 Dec 2003 23:19:11 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 53F0340FF35; Mon, 8 Dec 2003 23:19:11 -0900 (AKST) Date: Mon, 8 Dec 2003 23:19:11 -0900 From: Ethan Benson To: XFS Mailing List Subject: Re: advice: 3ware+raid+xfs Message-ID: <20031209081910.GD3294@plato.local.lan> Mail-Followup-To: XFS Mailing List References: <1070823336.1358.5.camel@pip> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AbQceqfdZEv+FvjW" Content-Disposition: inline In-Reply-To: <1070823336.1358.5.camel@pip> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.76 X-archive-position: 1300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1340 Lines: 44 --AbQceqfdZEv+FvjW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 07, 2003 at 01:55:36PM -0500, Danny Cox wrote: >=20 > You really should consider 2.4.23, or at least apply the patch to > do_brk() that 2.4.23 fixed. Of course, if this is a stand-alone machine > with no other logins, you may not care. logins don't matter, if its connected to a network and runs any service it needs to be patched. gentoo was not compromised with a local login, someone got uid=3Drsyncd via rsync then used the kernel to get root. bottom line if you don't bother to fix so called local holes, then you may as well just run all services as root, running a service non-root does not buy you any additional securtity if there are local root holes. > Either I'm getting more paranoid in my old age, or the security guys > are beginning to rub off on me.... ;-) good. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --AbQceqfdZEv+FvjW 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 iEYEARECAAYFAj/VhX4ACgkQJKx7GixEevwZKwCfUx8nNL9W+jDyiLAvQcBMvkx5 sVYAn3dAVHBbh/GKJxv+7YwzIhezDOpT =UGfk -----END PGP SIGNATURE----- --AbQceqfdZEv+FvjW-- From owner-linux-xfs@oss.sgi.com Tue Dec 9 01:28:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 01:29:10 -0800 (PST) Received: from mail.slb.com (eurmta01.london.eur.slb.com [134.32.26.55]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB99SbTa009121 for ; Tue, 9 Dec 2003 01:28:38 -0800 Received: from conversion-daemon.eurmta01.london.eur.slb.com by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) id <0HPM00801FCAO6@eurmta01.london.eur.slb.com> for linux-xfs@oss.sgi.com; Tue, 09 Dec 2003 09:24:06 +0000 (GMT) Received: from stavanger.westerngeco.slb.com (wgmail9.stavanger.eur.slb.com [134.32.72.36]) by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HPM00BO6FFH49@eurmta01.london.eur.slb.com>; Tue, 09 Dec 2003 09:23:42 +0000 (GMT) Received: from GSTJ2W (localhost [127.0.0.1]) by stavanger.westerngeco.slb.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id hB99JZF11170; Tue, 09 Dec 2003 10:19:35 +0100 (MET) Date: Tue, 09 Dec 2003 10:23:47 +0100 From: marat Subject: Re: kernel panic:kmem_zone_zalloc: NULL memory on KM_SLEEP request! In-reply-to: <20031209025039.GB1798@frodo> To: Nathan Scott Cc: linux-xfs@oss.sgi.com Message-id: <200312091023.47865.nospam-259928-001@slb.com> Organization: westerngeco MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT User-Agent: KMail/1.4.1 References: <200312081317.26603.nospam-259928-001@slb.com> <20031209025039.GB1798@frodo> X-archive-position: 1301 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nospam-259928-001@slb.com Precedence: bulk X-list: linux-xfs Content-Length: 1615 Lines: 51 Nathan, Thanks a lot for a good explanation. At the moment we are using 4Gb of memory on this machine. Do you think, it will help if I add more memory ? And, you said it tries to allocated memory a number of times. Is it in support/kmem.c file : #define MAX_SHAKE 8 ? May be I can try to increase this value. Regards, Marat On Tuesday 09 December 2003 03:50, you wrote: > On Mon, Dec 08, 2003 at 01:17:26PM +0100, marat wrote: > > Experts, > > > > Recently, I had one of the xfs filesystem failed and the only message > > was : kernel panic:kmem_zone_zalloc: NULL memory on KM_SLEEP request! > > > > I had to reboot machine and run xfs_repair to make files system available > > again. > > > > I am using kernel 2.4.20 SMP and xfs version 1.3.0. > > > > Any ideas, suggestions how I can avoid this problem to happen again ? > > Well, whats happened here is XFS is allocating memory from > a context where it cannot fail, and retries the allocation > a number of times (6 IIRC, with delays in-between each) and > after freeing up everything that XFS can itself. Afterward > if we still cannot get any memory allocated we give up and > call BUG(). > > I guess we could keep retrying indefinitely, but that doesn't > seem like a particularly good solution. I suspect we should > be getting a bit more help from the VM here (more recent 2.4 > kernels might make this case better) ... you may be able to > tweak some variables in mm/vmscan.c too - these are likely > sysctls somewhere - vm_mapped_ratio, vm_vfs_scan_ratio, etc > (ah, have a look through "vm_table" in kernel/sysctl.c). > > cheers. - From owner-linux-xfs@oss.sgi.com Tue Dec 9 02:30:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 02:30:42 -0800 (PST) Received: from relay04.roc.ny.frontiernet.net (relay04.roc.ny.frontiernet.net [66.133.131.37]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9AUKTa010335 for ; Tue, 9 Dec 2003 02:30:20 -0800 Received: (qmail 31765 invoked from network); 9 Dec 2003 10:30:18 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay04.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 9 Dec 2003 10:30:18 -0000 Message-ID: <3FD5A463.9030106@xfs.org> Date: Tue, 09 Dec 2003 04:30:59 -0600 From: Steve Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marat CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: kernel panic:kmem_zone_zalloc: NULL memory on KM_SLEEP request! References: <200312081317.26603.nospam-259928-001@slb.com> <20031209025039.GB1798@frodo> <200312091023.47865.nospam-259928-001@slb.com> In-Reply-To: <200312091023.47865.nospam-259928-001@slb.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1302 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 666 Lines: 22 marat wrote: > Nathan, > > Thanks a lot for a good explanation. > > At the moment we are using 4Gb of memory on this machine. Do you think, it will help if I add more memory ? > > And, you said it tries to allocated memory a number of times. Is it in support/kmem.c file : > #define MAX_SHAKE 8 ? > May be I can try to increase this value. > The fact that you have 4G of memory and you are running out is not a good thing. Unless you have some application which is locking down huge chunks of memory, you should not be able to run something this large out of memory. Taking a look at where the memory is on the system would be a good thing to do. Steve From owner-linux-xfs@oss.sgi.com Tue Dec 9 04:47:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 04:48:12 -0800 (PST) Received: from mail.slb.com (eurmta01.london.eur.slb.com [134.32.26.55]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9ClkTa019573 for ; Tue, 9 Dec 2003 04:47:49 -0800 Received: from conversion-daemon.eurmta01.london.eur.slb.com by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) id <0HPM00L01NMSVJ@eurmta01.london.eur.slb.com> for linux-xfs@oss.sgi.com; Tue, 09 Dec 2003 12:28:00 +0000 (GMT) Received: from stavanger.westerngeco.slb.com (wgmail9.stavanger.eur.slb.com [134.32.72.36]) by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HPM00D0ENXPYD@eurmta01.london.eur.slb.com>; Tue, 09 Dec 2003 12:27:25 +0000 (GMT) Received: from GSTJ2W (localhost [127.0.0.1]) by stavanger.westerngeco.slb.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id hB9CNIF12422; Tue, 09 Dec 2003 13:23:18 +0100 (MET) Date: Tue, 09 Dec 2003 13:27:30 +0100 From: marat Subject: Re: kernel panic:kmem_zone_zalloc: NULL memory on KM_SLEEP request! In-reply-to: <3FD5A463.9030106@xfs.org> To: Steve Lord Cc: linux-xfs@oss.sgi.com Message-id: <200312091327.30528.marat@stavanger.westerngeco.slb.com> Organization: westerngeco MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT User-Agent: KMail/1.4.1 References: <200312081317.26603.nospam-259928-001@slb.com> <200312091023.47865.nospam-259928-001@slb.com> <3FD5A463.9030106@xfs.org> X-archive-position: 1303 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marat@stavanger.westerngeco.slb.com Precedence: bulk X-list: linux-xfs Content-Length: 892 Lines: 31 Steve, We have 3 xfs filesystem on this machine. There are millions of files on those filesystems. And, we have more then 150 NFS clients accessing those filesystems . Most of the memory used for caching. Normally less then 100Mb used as Resident memory, rest is cached. regards, Marat > > The fact that you have 4G of memory and you are running out is not > a good thing. Unless you have some application which is locking > down huge chunks of memory, you should not be able to run something > this large out of memory. > > Taking a look at where the memory is on the system would be a good > thing to do. > > Steve -- Marat Mukhitov DP/Computer System Admin Tel. : +47 51 94 68 09 WesternGeco Fax. : +47 51 94 69 51 Stavanger, Norway E-mail: marat@stavanger.westerngeco.slb.com From owner-linux-xfs@oss.sgi.com Tue Dec 9 04:59:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 05:00:04 -0800 (PST) Received: from mail.tzv.fal.de (dcs.tzv.fal.de [192.108.34.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9CxWTa020091 for ; Tue, 9 Dec 2003 04:59:34 -0800 Received: by mail.tzv.fal.de (Postfix, from userid 1001) id 67B812340EF; Tue, 9 Dec 2003 13:59:31 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tzv.fal.de (Postfix) with ESMTP id BFC3B234129; Tue, 9 Dec 2003 13:59:29 +0100 (CET) Received: from ots-4.tzv.local (ots-4.tzv.local [10.1.0.17]) by mail.tzv.fal.de (Postfix) with ESMTP id F36412340EF; Tue, 9 Dec 2003 13:59:23 +0100 (CET) From: Monika Strack Reply-To: strack@tzv.fal.de To: linux-xfs@oss.sgi.com Subject: XFS , QLA2200 and SMP Date: Tue, 9 Dec 2003 13:59:23 +0100 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Disposition: inline Cc: debian-user@lists.debian.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200312091359.23161.most@tzv.fal.de> X-Virus-Scanned: by AMaViS snapshot-20020222 X-archive-position: 1304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: most@tzv.fal.de Precedence: bulk X-list: linux-xfs Content-Length: 2113 Lines: 53 Hallo, I need some help to make our fileserver working with fibre chanel raid. The hardware of the machine is: 2 Pentium III (Coppermine) 4 GB RAM Ethernet Pro 100 on board Gigabit Ethernet-Controler Syskonnect AT-2970SX RAID-Controler GDT 6113RS/6513RS SCSI-Controler Adaptec AIC-7899P on board Fibre-Channel Adapter QLogic Corp. QLA2200 (rev 5) I have run debian woody with xfs for the external RAID. I down't use LVM. Since 3 years I have run a external RAID with SCSI Adapter to this machine. It work ok with xfs. 2 weeks ago I got a new RAID with Fibre Chanel and Qlogig 2200 HBA. I have make a kernel for it, mount the RAID, make xfs-Filesystem and start to move the userdata from the old to the new RAID. I use command tar to move the data. If a small directory (up to 5 GB) will moved it works ok. If I start with a bigger directory it gives kernel panic after more than 7 GB data. The old RAID is connectet to a other machine and nfs mounted. I have try to make a kernel with kernel-version from 2.4.20 to 2.4.22 (allways from debian-source-package). For 2.4.20 I use xfs-2.4.20-all-i386.gz from SGI , for 2.4.21 linux-xfs-1.3.1 from SGI and for 2.4.22 the debian-package linux-xfs-1.3.1. I also have tried with different driver for the Qlogic HBA, the driver from Qlogic ( ver. 6.04.00 and 6.06.10), the qlogicfc driver from kernel source and the isp driver from feral.com. I have tried it with and with out HighMem IO. Always I get "Unable to handle kernel Null pointer dereference" or "unable to handle kernel paging request" Last night I have run memtest86, memory is ok. Can someone help me to make a working kernel for this configuration? regards Monika -- ________________________________________________________________________________ Monika Strack Institut fuer Tierzucht Bundesforschungsanstalt fuer Landwirschaft 31535 Neustadt e-mail: most@tzv.fal.de Germany Tel: +49 5034 /871 154 Fax: +49 5034 /871 239 _______________________________________________________________________________ From owner-linux-xfs@oss.sgi.com Tue Dec 9 05:41:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 05:41:23 -0800 (PST) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9Df1Ta022976 for ; Tue, 9 Dec 2003 05:41:01 -0800 Received: from auto-nb1.xs4all.nl (host-2.coltex.demon.nl [212.238.252.66]) (authenticated bits=0) by smtpzilla2.xs4all.nl (8.12.9/8.12.9) with ESMTP id hB9DerK7016716; Tue, 9 Dec 2003 14:40:54 +0100 (CET) Message-Id: <4.3.2.7.2.20031209143400.033c2b08@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Dec 2003 14:40:52 +0100 To: gbakos@cfa.harvard.edu, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: advice: 3ware+raid+xfs In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1305 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1966 Lines: 49 At 12:14 7-12-2003 -0500, Gaspar Bakos wrote: >Dear all, > >I am about to build a system for data reduction, but before I do so, I >thought of posting this in case anyone has useful hints (don't do that!, >or be careful with...) > >It would be a dual xeon mobo + 3ware Escalade card + 4x250Gb (WD) disk, Good choice. I assume you mean the 4 port card. >running most probably RH9.0 and kernel 2.4.22-xfs. I haven't decided yet >about the arrangement of the 4x250Gb disks, but definitely there will be >XFS on them. My possibilities are: (I need total space more than 500Gb) >1. JBOD, each disk one partition >(drawback: I have to take care of not filling either of them) >2. RAID-0, one single 1Tb XFS partition >3. RAID-5 I would suggest using Raid 10 ( size = n/2) if you have have a enviroment with heavy writes. If you won't write to the fs too much and it's mostly reads you could use raid 5 (size = n-1). If it's a production server I tend to waste money and opt for the raid 10 option instead since it's so much faster for database workloads and write heavy environments. The raid 10 performance is also a lot more consistent under load. >relatively big files (8Mb and 16Mb) accompanied with very small files >(<1kB). Recovery issues: I saw xfs_check run out of memory on a single >120Gb partition after an unexpected power failure. 3Ware configuration >issues that might be related to XFS, speed, efficiency. I you read/write/modify lot's of small files create the fs with a larger log. mkfs.xfs -l size=32768b /dev/foo >Being an astronomer, I am not that experienced with sw/hw issues... >I was always wondering when people write "we have been testing XFS with >60Tb filesystems" (and other magic numbers) - how they do that? If it's 60TB I don't think it's a single filesytem under linux. The current limit is 2TB per device. AFAIK this is fixed in the upcoming 2.6 Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Tue Dec 9 06:52:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 06:52:49 -0800 (PST) Received: from rolf.uib.no (rolf.uib.no [129.177.30.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9EqPTa025310 for ; Tue, 9 Dec 2003 06:52:26 -0800 Received: from alfred.uib.no (smtp.uib.no) [129.177.30.120] by rolf.uib.no for linux-xfs@oss.sgi.com with esmtp (Exim 4.24) id 1ATjDn-0006OB-Ap; Tue, 09 Dec 2003 15:52:19 +0100 Received: from lapprose.ii.uib.no [129.177.20.37] by smtp.uib.no for linux-xfs@oss.sgi.com with esmtp (Exim 4.12) id 1ATjDm-0006n2-00; Tue, 09 Dec 2003 15:52:18 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.8/8.12.8/Submit) id hB9EqIPq009999 for linux-xfs@oss.sgi.com; Tue, 9 Dec 2003 15:52:18 +0100 Resent-Message-Id: <200312091452.hB9EqIPq009999@lapprose.ii.uib.no> Date: Mon, 8 Dec 2003 17:59:45 +0100 From: Jan-Frode Myklebust To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: do_brk() -- kernel 2.4.20-24.9.XFS ? Message-ID: <20031208165945.GA23902@ii.uib.no> References: <20031208090604.GA3153@ii.uib.no> <20031208154144.GA7338@ii.uib.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031208154144.GA7338@ii.uib.no> Resent-From: Jan-Frode Myklebust Resent-Date: Tue, 9 Dec 2003 15:52:18 +0100 Resent-To: linux-xfs@oss.sgi.com X-checked-clean: by exiscan on rolf X-Scanner: 5572246aa716609b16c5d40289d36cf7 http://tjinfo.uib.no/virus.html X-UiB-SpamFlag: NO UIB: -39.0 hits, 9.0 required X-UiB-SpamReport: spamassassin found; * -30.0 -- From is listed in 'whitelist_from' * -9.0 -- Message received from UIB X-archive-position: 1306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.uib.no Precedence: bulk X-list: linux-xfs Content-Length: 576 Lines: 19 On Mon, Dec 08, 2003 at 04:41:44PM +0100, Jan-Frode Myklebust wrote: > > rpm -ivh kernel-2.4.20-20.9.XFS1.3.1.src.rpm > rpm -ivh kernel-2.4.20-24.9.src.rpm > cd ~/rpm/SPEC # or 'cd /usr/src/redhat/SPECS' > sed 's/20.9.XFS1.3.1/24.9.XFS1.3.1/' kernel-2.4.20.XFS1.3.1.spec > kernel-2.4.24.XFS1.3.1.spec > rpmbuild -ba kernel-2.4.24.XFS1.3.1.spec Needed to keep the SOURCES/*config also, but then it built. Here are the kernel RPMS in case any others are interested: ftp://ftp.ii.uib.no/pub/janfrode/XFS/ I'll put up the i686's as soon as they're finished. -jf From owner-linux-xfs@oss.sgi.com Tue Dec 9 07:38:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 07:38:15 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9Fc4Ta027468 for ; Tue, 9 Dec 2003 07:38:04 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB9DjLOO003555 for ; Tue, 9 Dec 2003 05:45:21 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB9FavP519034024; Tue, 9 Dec 2003 09:36:57 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB9FakK29183609; Tue, 9 Dec 2003 09:36:49 -0600 (CST) Date: Tue, 9 Dec 2003 09:36:53 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: strack@tzv.fal.de cc: linux-xfs@oss.sgi.com, Subject: Re: XFS , QLA2200 and SMP In-Reply-To: <200312091359.23161.most@tzv.fal.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 386 Lines: 15 On Tue, 9 Dec 2003, Monika Strack wrote: > Hallo, > > I need some help to make our fileserver working with fibre chanel raid. > > Always I get "Unable to handle kernel Null pointer dereference" or "unable to > handle kernel paging request" You'll need to start by sending more information, please run the oops through ksymoops so we can have some idea of what went wrong. -Eric From owner-linux-xfs@oss.sgi.com Tue Dec 9 07:43:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 07:43:17 -0800 (PST) Received: from castor.acu.ac.uk (castor.acu.ac.uk [194.81.120.81]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9Fh5Ta027965 for ; Tue, 9 Dec 2003 07:43:06 -0800 Received: from acu.ac.uk (arcturus.acu.ac.uk [194.81.120.110]) by castor.acu.ac.uk (8.12.10/8.12.10) with ESMTP id hB9FgxAZ006060 for ; Tue, 9 Dec 2003 15:43:00 GMT Message-ID: <3FD5ED83.7000500@acu.ac.uk> Date: Tue, 09 Dec 2003 15:42:59 +0000 From: Mike Brodbelt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS filesystem shutdown Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' X-archive-position: 1308 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: m.brodbelt@acu.ac.uk Precedence: bulk X-list: linux-xfs Content-Length: 1919 Lines: 50 I've been using XFS on numerous systems for about 2 years now, and I've recently been bitten by a problem I've seen once or twice before, and was wondering if anyone out there knows what the real cause of this is. Background:- Machine is a fairly heavily used server, hardware RAID-5 on 7 disks, running Debian Woody with a vanilla kernel from kernel.org, patched with the appropriate xfs-all (not the split) patch set. Currently:- SGI XFS snapshot-2.4.22-2003-10-10_04:57_UTC with no debug enabled The most heavily used filesystem is on /var, where there is a Cyrus imap spool, resulting in lots of small files, and a lot of file activity. There is a bug in the version of Cyrus I'm running which periodically causes imapd child processes to sig11 and die. This may be entirely unrelated, but could conceivably have some bearing on the situation. Last week, I get this:- xfs_inotobp: xfs_imap() returned an error 22 on sd (8,8). Returning error. xfs_iunlink_remove: xfs_inotobp() returned an error 22 on sd (8,8). Returning an error. xfs_inactive: 0xfs_ifree() error 22 on sd (8,8) xfs_force_shutdown: (sd(8,8)0x1) called from line 1873 of file xfs_vnodeops.c Return address = 0x01ef8ba File system sd (8,8): I/O error detected. Shutting down file system: sd (8,8) Please umount the fs, & rectify the problem(s) Fixed by taking the machine single user, running xfs_repair over /var, and then remounting the file-system. This has happened to this machine twice in a period of about 14 months, and while it hasn't caused me serious trouble, it's evident from the XFS FAQ that it shouldn't be happening, and I'd like to know why it is, and if there's anything I can do about it. There's a bug report at http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 which looks as though it may be the same thing I'm seeing. I'd be interested to hear from anyone who can shed any more light on the issue... Mike. From owner-linux-xfs@oss.sgi.com Tue Dec 9 08:47:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 08:48:12 -0800 (PST) Received: from odin.sis.hu (odin.sis.hu [212.92.23.29]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9GljTa032091 for ; Tue, 9 Dec 2003 08:47:46 -0800 Received: by odin.sis.hu (Postfix, from userid 1001) id 0A4111004C07; Tue, 9 Dec 2003 17:47:43 +0100 (CET) Date: Tue, 9 Dec 2003 17:47:43 +0100 From: Gabor Burjan To: linux-xfs@oss.sgi.com Subject: Re: Fwd: XFS merged in 2.4 Message-ID: <20031209164743.GA29314@odin.sis.hu> References: <1070909208.4918.0.camel@david.internal.NorcrossGroup.com> <1070913046.2449.53.camel@localhost.localdomain> <1070913915.9510.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1070913915.9510.11.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.28i X-archive-position: 1309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: buga@buvoshetes.hu Precedence: bulk X-list: linux-xfs Content-Length: 323 Lines: 14 On Mon, Dec 08, 2003 at 02:05:15PM -0600, Eric Sandeen wrote: > In code you get from Marcelo and Linus, there will be gaps due to > different release schedules. Which version of XFS is in Marcelo's branch? xfs_version.h from patch-2.4.23-bk7.bz2 contains only this define: #define XFS_VERSION_STRING "SGI XFS" Gabor From owner-linux-xfs@oss.sgi.com Tue Dec 9 08:52:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 08:53:03 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9GqpTa032540 for ; Tue, 9 Dec 2003 08:52:52 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hB9Gp33t002413; Tue, 9 Dec 2003 10:51:03 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB9Gp0hQ002411; Tue, 9 Dec 2003 10:51:00 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS , QLA2200 and SMP From: Austin Gonyou To: Eric Sandeen Cc: strack@tzv.fal.de, XFS List , debian-user@lists.debian.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1070988660.2347.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 09 Dec 2003 10:51:00 -0600 X-archive-position: 1310 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 651 Lines: 24 What qlogic driver, kernel version, XFS version, FC array, size volume, and oops output? All that will help tremendously. On Tue, 2003-12-09 at 09:36, Eric Sandeen wrote: > On Tue, 9 Dec 2003, Monika Strack wrote: > > > Hallo, > > > > I need some help to make our fileserver working with fibre chanel > raid. > > > > Always I get "Unable to handle kernel Null pointer dereference" or > "unable to > > handle kernel paging request" > > You'll need to start by sending more information, please run > the oops through ksymoops so we can have some idea of what went > wrong. > > -Eric -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Dec 9 09:07:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 09:07:38 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9H7GTa000835 for ; Tue, 9 Dec 2003 09:07:17 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hB9H5R3t002586; Tue, 9 Dec 2003 11:05:27 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB9H5Qvt002584; Tue, 9 Dec 2003 11:05:26 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS , QLA2200 and SMP From: Austin Gonyou To: strack@tzv.fal.de Cc: XFS List , debian-user@lists.debian.org In-Reply-To: <200312091359.23161.most@tzv.fal.de> References: <200312091359.23161.most@tzv.fal.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1070989526.2345.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 09 Dec 2003 11:05:26 -0600 X-archive-position: 1311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 2814 Lines: 78 Pardon me for not seeing this earlier. have you created a debug qlogic driver? 6.06.10 prefferably. Also, are you using and ql2xopts in your modules.conf? Just curious. Some older versions may be messed up if you haven't re-written them. Also, tried moving the qlogic card to another slot? We have many systems here with dual 2200s and 2300s in failover, we've had our issues, but overall they continue to work and we do hundreds of GB of IO or more per day. On Tue, 2003-12-09 at 06:59, Monika Strack wrote: > Hallo, > > I need some help to make our fileserver working with fibre chanel > raid. > > The hardware of the machine is: > 2 Pentium III (Coppermine) > 4 GB RAM > Ethernet Pro 100 on board > Gigabit Ethernet-Controler Syskonnect AT-2970SX > RAID-Controler GDT 6113RS/6513RS > SCSI-Controler Adaptec AIC-7899P on board > Fibre-Channel Adapter QLogic Corp. QLA2200 (rev 5) > > I have run debian woody with xfs for the external RAID. I down't use > LVM. > > Since 3 years I have run a external RAID with SCSI Adapter to this > machine. It > work ok with xfs. 2 weeks ago I got a new RAID with Fibre Chanel and > Qlogig > 2200 HBA. > I have make a kernel for it, mount the RAID, make xfs-Filesystem and > start to > move the userdata from the old to the new RAID. I use command tar to > move the > data. If a small directory (up to 5 GB) will moved it works ok. If I > start > with a bigger directory it gives kernel panic after more than 7 GB > data. The > old RAID is connectet to a other machine and nfs mounted. > > I have try to make a kernel with kernel-version from 2.4.20 to > 2.4.22 > (allways from debian-source-package). For 2.4.20 I use > xfs-2.4.20-all-i386.gz from SGI , for 2.4.21 linux-xfs-1.3.1 from > SGI and > for 2.4.22 the debian-package linux-xfs-1.3.1. I also have tried with > different driver for the Qlogic HBA, the driver from Qlogic ( ver. > 6.04.00 > and 6.06.10), the qlogicfc driver from kernel source and the isp > driver from > feral.com. I have tried it with and with out HighMem IO. > > Always I get "Unable to handle kernel Null pointer dereference" or > "unable to > handle kernel paging request" > > Last night I have run memtest86, memory is ok. > > Can someone help me to make a working kernel for this configuration? > > regards > > Monika > -- > ________________________________________________________________________________ > Monika Strack > Institut fuer Tierzucht > Bundesforschungsanstalt fuer Landwirschaft > > 31535 Neustadt e-mail: most@tzv.fal.de > Germany Tel: +49 5034 /871 154 > Fax: +49 5034 /871 239 > _______________________________________________________________________________ -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Dec 9 09:27:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 09:27:53 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9HRfTa001780 for ; Tue, 9 Dec 2003 09:27:42 -0800 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id hB9HRdhm001410; Tue, 9 Dec 2003 12:27:39 -0500 (EST) Date: Tue, 9 Dec 2003 12:27:39 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: advice: 3ware+raid+xfs In-Reply-To: <4.3.2.7.2.20031209143400.033c2b08@pop.xs4all.nl> Message-ID: References: <4.3.2.7.2.20031209143400.033c2b08@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 1107 Lines: 31 Hi, RE: > >It would be a dual xeon mobo + 3ware Escalade card + 4x250Gb (WD) disk, > Good choice. I assume you mean the 4 port card. Yes, it is the 4-port one. Maybe, once upon a time when I get more funded, I will get 8-port card(s). > I would suggest using Raid 10 ( size = n/2) if you have have a enviroment > with heavy writes. If you won't write to the fs too much and it's mostly > reads you could use raid 5 (size = n-1). The read/write is approx equal, maybe 'read' a little bit more. (I wonder, in long-term, how could I 'measure' this). > If it's a production server I tend to waste money and opt for the raid 10 > option instead since it's so much faster for database workloads and write It is a data-cruncher. Reads in 8-16Mb astronomical images, measures 5Bsources, writes out few Mb output, and several small files (logs). Thanks for all the advice on RAID-5 vs. RAID-10! > If it's 60TB I don't think it's a single filesytem under linux. The current > limit is 2TB per device. AFAIK this is fixed in the upcoming 2.6 Great... time will come soon when I hve to migrate. Cheers Gaspar From owner-linux-xfs@oss.sgi.com Tue Dec 9 10:35:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 10:35:45 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9IZOTa003634 for ; Tue, 9 Dec 2003 10:35:24 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hB9GgfOO020885 for ; Tue, 9 Dec 2003 08:42:42 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hB9IZEP519066749; Tue, 9 Dec 2003 12:35:14 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hB9IYFK19651502; Tue, 9 Dec 2003 12:35:06 -0600 (CST) Subject: Re: Fwd: XFS merged in 2.4 From: Eric Sandeen To: Gabor Burjan Cc: linux-xfs@oss.sgi.com In-Reply-To: <20031209164743.GA29314@odin.sis.hu> References: <1070909208.4918.0.camel@david.internal.NorcrossGroup.com> <1070913046.2449.53.camel@localhost.localdomain> <1070913915.9510.11.camel@stout.americas.sgi.com> <20031209164743.GA29314@odin.sis.hu> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1070994862.13823.39.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 09 Dec 2003 12:34:23 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 395 Lines: 16 On Tue, 2003-12-09 at 10:47, Gabor Burjan wrote: > Which version of XFS is in Marcelo's branch? > > xfs_version.h from patch-2.4.23-bk7.bz2 contains only this define: > > #define XFS_VERSION_STRING "SGI XFS" Top of the development tree, minus dmapi and acls. -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Dec 9 14:12:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 14:12:42 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB9MCVTa011912 for ; Tue, 9 Dec 2003 14:12:31 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB9MCVpJ011911 for linux-xfs@oss.sgi.com; Tue, 9 Dec 2003 14:12:31 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB9MCTTc011894 for ; Tue, 9 Dec 2003 14:12:30 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB9LVFbC010298; Tue, 9 Dec 2003 13:31:15 -0800 Date: Tue, 9 Dec 2003 13:31:15 -0800 Message-Id: <200312092131.hB9LVFbC010298@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1314 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1585 Lines: 44 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From tdickson@inostor.com 2003-09-12 13:31 PDT ------- Linux masterd 2.4.20-softpower #1 Tue Dec 2 12:53:05 PST 2003 i686 unknown has a similar problem. Running the creation of 600,000 directories results in the free memory (exluding cache) dropping until the oom killer reaps everything but the kernel. bash-2.05a# cat /proc/slabinfo | grep xfs xfs_dqtrx 27 40 192 2 2 1 xfs_dquots 16 24 324 2 2 1 xfs_acl 0 0 304 0 0 1 xfs_chashlist 146715 146854 16 727 727 1 xfs_ili 575152 575176 140 20542 20542 1 xfs_ifork 0 0 56 0 0 1 xfs_efi_item 0 0 260 0 0 1 xfs_efd_item 0 0 260 0 0 1 xfs_buf_item 97 130 148 5 5 1 xfs_dabuf 0 0 16 0 0 1 xfs_da_state 0 0 336 0 0 1 xfs_trans 27 39 588 3 3 2 xfs_inode 703689 703900 368 70390 70390 1 xfs_btree_cur 0 29 132 0 1 1 xfs_bmap_free_item 0 0 12 0 0 1 bash-2.05a# If I unmount the volume and remove the xfs module, the memory is freed back up. xfs_check also dies when trying to check this filesystem. Filesystem: 800 GBs on a LVM volume. System P4 with 512 mb ram. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Dec 9 14:39:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 14:39:19 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9Md7Ta013631 for ; Tue, 9 Dec 2003 14:39:07 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hB9Nu7m7013725 for ; Tue, 9 Dec 2003 17:56:08 -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 JAA25451; Wed, 10 Dec 2003 09:37:40 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hB9MbdUc2187353; Wed, 10 Dec 2003 09:37:39 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hB9MbGGo001002; Wed, 10 Dec 2003 09:37:16 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hB9MbFHN001000; Wed, 10 Dec 2003 09:37:15 +1100 Date: Wed, 10 Dec 2003 09:37:15 +1100 From: Nathan Scott To: marat Cc: linux-xfs@oss.sgi.com Subject: Re: kernel panic:kmem_zone_zalloc: NULL memory on KM_SLEEP request! Message-ID: <20031209223715.GB783@frodo> References: <200312081317.26603.nospam-259928-001@slb.com> <20031209025039.GB1798@frodo> <200312091023.47865.nospam-259928-001@slb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312091023.47865.nospam-259928-001@slb.com> User-Agent: Mutt/1.5.3i X-archive-position: 1315 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 570 Lines: 20 On Tue, Dec 09, 2003 at 10:23:47AM +0100, marat wrote: > Nathan, > > Thanks a lot for a good explanation. > > At the moment we are using 4Gb of memory on this machine. Do you think, it will help if I add more memory ? > > And, you said it tries to allocated memory a number of times. Is it in support/kmem.c file : > #define MAX_SHAKE 8 ? > May be I can try to increase this value. Thats the right file, but look at DEF_PRIORITY not MAX_SHAKE. I think you'll be better off tweaking those VM sysctls though, or trying a more recent kernel. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Dec 9 15:12:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 15:12:54 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB9NCWTa014776 for ; Tue, 9 Dec 2003 15:12:33 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB9NCWQx014774 for linux-xfs@oss.sgi.com; Tue, 9 Dec 2003 15:12:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB9NCUTe014742 for ; Tue, 9 Dec 2003 15:12:30 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB9MCk8m011951; Tue, 9 Dec 2003 14:12:46 -0800 Date: Tue, 9 Dec 2003 14:12:46 -0800 Message-Id: <200312092212.hB9MCk8m011951@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1316 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 407 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 tdickson@inostor.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tdickson@inostor.com ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Dec 9 15:12:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 15:12:54 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB9NCXTa014775 for ; Tue, 9 Dec 2003 15:12:33 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB9NCWw5014773 for linux-xfs@oss.sgi.com; Tue, 9 Dec 2003 15:12:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hB9NCUTk014742 for ; Tue, 9 Dec 2003 15:12:31 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hB9Mg9Xl014295; Tue, 9 Dec 2003 14:42:09 -0800 Date: Tue, 9 Dec 2003 14:42:09 -0800 Message-Id: <200312092242.hB9Mg9Xl014295@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1316 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1355 Lines: 35 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From tdickson@inostor.com 2003-09-12 14:42 PDT ------- After awhile, (and repeatedly oom killing a number of my processes), the system seemed to recover somewhat. bash-2.05a# more /proc/slabinfo |grep xfs xfs_dqtrx 2 60 192 2 3 1 xfs_dquots 16 24 324 2 2 1 xfs_acl 0 0 304 0 0 1 xfs_chashlist 43298 82820 16 409 410 1 xfs_ili 453700 458360 140 16205 16370 1 xfs_ifork 0 0 56 0 0 1 xfs_efi_item 0 0 260 0 0 1 xfs_efd_item 0 0 260 0 0 1 xfs_buf_item 567 1404 148 30 54 1 xfs_dabuf 0 202 16 0 1 1 xfs_da_state 0 11 336 0 1 1 xfs_trans 2 65 588 2 5 2 xfs_inode 482317 588390 368 58147 58839 1 xfs_btree_cur 0 29 132 0 1 1 xfs_bmap_free_item 0 0 12 0 0 1 is what I see now. Of course, this was after the oom killer killed the tree process that I was running to excercize the inodes. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Dec 9 15:23:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 15:23:55 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.189.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hB9NNXTa015666 for ; Tue, 9 Dec 2003 15:23:34 -0800 Received: from mail.pacrimopen.com (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id 198C970022B9 for ; Tue, 9 Dec 2003 15:29:54 -0800 (PST) Received: from UNKNOWN(127.0.0.1), claiming to be "mail.pacrimopen.com" via SMTP by sa-relay.pacrimopen.com, id smtpd0Jf8oG; Tue Dec 9 15:29:42 2003 Received: from bubbles.imr-net.com (unknown [12.111.175.172]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id 1235F70019D0 for ; Tue, 9 Dec 2003 15:29:42 -0800 (PST) Subject: sunit, swidth question - mkfs.xfs tuning From: Joshua Schmidlkofer To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1071012200.32237.175.camel@bubbles.imr-net.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 09 Dec 2003 15:23:20 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 1317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joshua@imr-net.com Precedence: bulk X-list: linux-xfs Content-Length: 554 Lines: 21 Howdy, WOO HOOO!! On 2.4 inclusion, BTW. (good going!) An old e-mail from Christian Guggenberger recommends swidth be (n-1) disks for RAID5. Is that correct? I have a 66GB volume so I was looking at: Mylex AcceleRAID 170, 6 disks in a RAID 5. (4GB system memory) mkfs.xfs -d su=64k,sw=5 -l size=32m,sunit=64k -L "data" /dev/... Is this correct? Is 32mb a good journal size? This is a mail server, lots of small files, do I need to optimize the inode options? I don't quite understand the full impact of performance here. thanks, Joshua From owner-linux-xfs@oss.sgi.com Tue Dec 9 16:12:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 16:12:54 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBA0CWTa017219 for ; Tue, 9 Dec 2003 16:12:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBA0CV15017218 for linux-xfs@oss.sgi.com; Tue, 9 Dec 2003 16:12:31 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBA0CUTe017202 for ; Tue, 9 Dec 2003 16:12:30 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBA0AYDl017177; Tue, 9 Dec 2003 16:10:34 -0800 Date: Tue, 9 Dec 2003 16:10:34 -0800 Message-Id: <200312100010.hBA0AYDl017177@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1492 Lines: 38 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From tdickson@inostor.com 2003-09-12 16:10 PDT ------- This is wierd. After the oom killer ran out of processes to kill, the slabinfo shows that xfs has dropped all the way to bash-2.05a# cat /proc/slabinfo | grep xfs xfs_dqtrx 7 40 192 2 2 1 xfs_dquots 16 24 324 2 2 1 xfs_acl 0 0 304 0 0 1 xfs_chashlist 242 606 16 3 3 1 xfs_ili 647 672 140 24 24 1 xfs_ifork 0 0 56 0 0 1 xfs_efi_item 0 0 260 0 0 1 xfs_efd_item 0 0 260 0 0 1 xfs_buf_item 50 78 148 3 3 1 xfs_dabuf 0 202 16 0 1 1 xfs_da_state 0 0 336 0 0 1 xfs_trans 10 39 588 2 3 2 xfs_inode 2430 2440 368 243 244 1 xfs_btree_cur 0 29 132 0 1 1 xfs_bmap_free_item 0 0 12 0 0 1 Any hints would be appreciated. I'm currently creating 800000 files and doing a tree of the entire filesystem, and it seems happy. The only problem is that before it recovered, it ate so much memory that the oom killer killed all of the usefull processes. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Dec 9 20:12:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 20:13:07 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBA4CXTa029063 for ; Tue, 9 Dec 2003 20:12:33 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBA4CXXE029062 for linux-xfs@oss.sgi.com; Tue, 9 Dec 2003 20:12:33 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBA4CUTe029046 for ; Tue, 9 Dec 2003 20:12:31 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBA3hpxr028689; Tue, 9 Dec 2003 19:43:51 -0800 Date: Tue, 9 Dec 2003 19:43:51 -0800 Message-Id: <200312100343.hBA3hpxr028689@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 859 Lines: 28 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From sandeen@sgi.com 2003-09-12 19:43 PDT ------- Tom, you're creating 800,000 files and directories -and- constantly running something over them to keep all the inodes in memory? on a machine with 512M? This might well fall into the category of fork-bombs and such. :) Perhaps xfs isn't letting go of inodes as it should, but you are really beating the heck out of the box here, I think. When you said xfs_check failed, how did it fail. Also for completeness, what is this 'tree' application you're running over the dirs, is it the tree command itself? please also try more recent code, xfs's inode size shrank at one point, after 2.4.20 I think. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Dec 9 23:22:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Dec 2003 23:23:24 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBA7MvTa003540 for ; Tue, 9 Dec 2003 23:22:58 -0800 Received: from mailhub.ch.sauter-bc.com (mailhub.ch.sauter-bc.com [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id CEB1332CB7; Wed, 10 Dec 2003 08:22:50 +0100 (CET) Received: from av-01.ch.sauter-bc.com (av-01.ch.sauter-bc.com [10.1.6.28]) by mailhub.ch.sauter-bc.com (Postfix) with SMTP id 4D63332CB5; Wed, 10 Dec 2003 08:22:50 +0100 (CET) Received: from mx-05-bsl.ch.sauter-bc.com ([10.1.6.20]) by av-01.ch.sauter-bc.com (SAVSMTP 3.1.2.35) with SMTP id M2003121008225029433 ; Wed, 10 Dec 2003 08:22:50 +0100 Received: from webmail.ch.sauter-bc.com (imap01.ch.sauter-bc.com [10.1.6.25]) by mx-05-bsl.ch.sauter-bc.com (Postfix) with SMTP id 4518B4E20D; Wed, 10 Dec 2003 08:22:50 +0100 (CET) Received: from 10.1.200.117 (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Wed, 10 Dec 2003 08:22:50 +0100 (CET) Message-ID: <1432.10.1.200.117.1071040970.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <3FD5ED83.7000500@acu.ac.uk> References: <3FD5ED83.7000500@acu.ac.uk> Date: Wed, 10 Dec 2003 08:22:50 +0100 (CET) Subject: Re: XFS filesystem shutdown From: "Simon Matter" To: "Mike Brodbelt" Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hBA7MxTa003543 X-archive-position: 1320 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 2395 Lines: 65 > > I've been using XFS on numerous systems for about 2 years now, and I've > recently been bitten by a problem I've seen once or twice before, and > was wondering if anyone out there knows what the real cause of this is. > > Background:- > > Machine is a fairly heavily used server, hardware RAID-5 on 7 disks, > running Debian Woody with a vanilla kernel from kernel.org, patched with > the appropriate xfs-all (not the split) patch set. Currently:- > > SGI XFS snapshot-2.4.22-2003-10-10_04:57_UTC with no debug enabled > > The most heavily used filesystem is on /var, where there is a Cyrus imap > spool, resulting in lots of small files, and a lot of file activity. > There is a bug in the version of Cyrus I'm running which periodically > causes imapd child processes to sig11 and die. This may be entirely > unrelated, but could conceivably have some bearing on the situation. I've been running cyrus-imapd servers on XFS for years now without any problems related to XFS. I also had the sig11 and die problem but it never affected XFS, and I think it really should not. > > > Last week, I get this:- > > xfs_inotobp: xfs_imap() returned an error 22 on sd (8,8). Returning error. > xfs_iunlink_remove: xfs_inotobp() returned an error 22 on sd (8,8). > Returning an error. > xfs_inactive: 0xfs_ifree() error 22 on sd (8,8) > xfs_force_shutdown: (sd(8,8)0x1) called from line 1873 of file > xfs_vnodeops.c > Return address = 0x01ef8ba > File system sd (8,8): I/O error detected. ^^^^^^^^^ I'm not an expert for those error messages but I guess it unfortunately a hardware error, isn't it? Did you check dmesg output when this happened? Simon > Shutting down file system: sd (8,8) > Please umount the fs, & rectify the problem(s) > > Fixed by taking the machine single user, running xfs_repair over /var, > and then remounting the file-system. > > This has happened to this machine twice in a period of about 14 months, > and while it hasn't caused me serious trouble, it's evident from the XFS > FAQ that it shouldn't be happening, and I'd like to know why it is, and > if there's anything I can do about it. There's a bug report at > http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 which looks as though it > may be the same thing I'm seeing. > > I'd be interested to hear from anyone who can shed any more light on the > issue... > > Mike. > > > > > From owner-linux-xfs@oss.sgi.com Wed Dec 10 00:17:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 00:18:16 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBA8HmTa005567 for ; Wed, 10 Dec 2003 00:17:49 -0800 Received: (qmail 9337 invoked by uid 1000); 10 Dec 2003 10:18:11 +0200 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Dec 2003 10:18:11 +0200 Date: Wed, 10 Dec 2003 10:18:08 +0200 (EET) From: Mihai RUSU X-X-Sender: dizzy@ahriman.bucharest.roedu.net To: linux-xfs@oss.sgi.com cc: linux-kernel@vger.kernel.org Subject: kernel BUG at fs/xfs/support/debug.c:106! Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1435322240-1988664075-1071044288=:8346" X-archive-position: 1321 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 28770 Lines: 554 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. --1435322240-1988664075-1071044288=:8346 Content-Type: TEXT/PLAIN; charset=US-ASCII -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Another problem now, on another system. This one is a 2xP3 1.1 Ghz, 3 GB RAM, MB Intel SCB2, Adaptec 7899 Controller onboard having one 18 GB SCSI disk connected to it (for XFS external journal, swap and / partition which is on ext3), Mylex 170 RAID connected to external storage enclosure with 3 x 70 GB SCSI RAID5. The kernel error message is: ksymoops 2.4.9 on i686 2.6.0-test11. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.6.0-test11/ (default) -m /usr/src/linux/System.map (default) Error (regular_file): read_ksyms stat /proc/ksyms failed No modules in ksyms, skipping objects No ksyms, skipping lsmod Reading Oops report from the terminal kernel BUG at fs/xfs/support/debug.c:106! invalid operand: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: f682e000 ecx: c2e437c8 edx: c038629c esi: c0357380 edi: c043e2de ebp: 00000000 esp: f682f9fc ds: 007b es: 007b ss: 0068 Stack: c035744e c0358c36 c043e2a0 00000293 f682e000 15a2031f 00000000 c77ad810 c021c8bc 00000000 c03625a0 e5a2a640 ef6d1220 000008d0 c0173089 ef6d1240 00100100 f711ddc8 f7130800 ef6d1240 f682e000 f682e000 f71a1524 f682e000 Call Trace: [] xfs_iget_core+0x5ec/0x780 [] alloc_inode+0xd9/0x190 [] vn_initialize+0xc7/0xf0 [] xfs_iget+0x160/0x1a0 [] xfs_vget+0x79/0xf0 [] vfs_vget+0x43/0x50 [] linvfs_get_dentry+0x53/0x90 [] find_exported_dentry+0x3e/0x880 [] iget_locked+0x74/0x100 [] xfs_bmbt_get_state+0x2f/0x40 [] xfs_bmap_do_search_extents+0x27d/0x410 [] udp_queue_rcv_skb+0x228/0x2c0 [] xfs_bmap_search_extents+0x7b/0x90 [] alloc_skb+0x47/0xf0 [] xfs_bmapi+0x2c4/0x1580 [] sock_alloc_send_pskb+0xcb/0x1e0 [] sock_alloc_send_skb+0x2f/0x40 [] ip_append_data+0x6c1/0x790 [] e100_prepare_xmit_buff+0x12f/0x230 [] e100_xmit_frame+0xda/0x120 [] qdisc_restart+0x17/0x260 [] dev_queue_xmit+0x2c2/0x350 [] ip_finish_output+0xee/0x220 [] ipt_do_table+0x2eb/0x400 [] ip_fragment+0x2bd/0x720 [] exp_find_key+0x80/0xa0 [] nf_hook_slow+0x104/0x160 [] export_decode_fh+0x5d/0x79 [] nfsd_acceptable+0x0/0x140 [] fh_verify+0x396/0x5a0 [] nfsd_acceptable+0x0/0x140 [] dst_output+0x0/0x30 [] nfsd_open+0x44/0x160 [] nfsd_read+0x52/0x410 [] __wake_up_common+0x3a/0x60 [] svcauth_unix_accept+0x28a/0x2b0 [] nfsd3_proc_read+0xd1/0x1b0 [] nfsd_dispatch+0xe8/0x1f0 [] svc_process+0x4ec/0x67d [] nfsd+0x23f/0x460 [] nfsd+0x0/0x460 [] kernel_thread_helper+0x5/0xc Code: 0f 0b 6a 00 56 8c 35 c0 83 c4 10 5b 5e 5f 5d c3 e8 63 9c ec >>EIP; c0253058 <===== >>ebx; f682e000 <_end+363e7a5c/3fbb7a5c> >>ecx; c2e437c8 <_end+29fd224/3fbb7a5c> >>edx; c038629c >>esi; c0357380 <__func__.4+bc39/3767b> >>edi; c043e2de >>esp; f682f9fc <_end+363e9458/3fbb7a5c> Trace; c021c8bc Trace; c0173089 Trace; c0252977 Trace; c021cbb0 Trace; c023c639 Trace; c0252153 Trace; c0251ab3 Trace; c01c5fae Trace; c01742e4 Trace; c01fdfdf Trace; c01f520d Trace; c0316f58 Trace; c01f541b Trace; c02d66d7 Trace; c01f6b54 Trace; c02d5c5b Trace; c02d5d9f Trace; c02f4871 Trace; c029d65f Trace; c029beaa Trace; c02e7707 Trace; c02db192 Trace; c02f2fce Trace; c0326dbb Trace; c02f3c8d Trace; c01cf290 Trace; c02e6b44 Trace; c01c6bad Trace; c01c9400 Trace; c01c98d6 Trace; c01c9400 Trace; c02f5670 Trace; c01cafa4 Trace; c01cb332 Trace; c011cd7a <__wake_up_common+3a/60> Trace; c033e82a Trace; c01d3261 Trace; c01c7378 Trace; c033a0ec Trace; c01c706f Trace; c01c6e30 Trace; c01072e9 Code; c0253058 00000000 <_EIP>: Code; c0253058 <===== 0: 0f 0b ud2a <===== Code; c025305a 2: 6a 00 push $0x0 Code; c025305c 4: 56 push %esi Code; c025305d 5: 8c 35 c0 83 c4 10 movl %?,0x10c483c0 Code; c0253063 b: 5b pop %ebx Code; c0253064 c: 5e pop %esi Code; c0253065 d: 5f pop %edi Code; c0253066 e: 5d pop %ebp Code; c0253067 f: c3 ret Code; c0253068 10: e8 63 9c ec 00 call ec9c78 <_EIP+0xec9c78> After this error happened, any process trying to access the XFS filesystem was hanged in D state (even a simple cd /mnt/xfs/dir). I have attached the .config used for this kernel. More infos: $ ./scripts/ver_linux Linux l 2.6.0-test11 #6 SMP Mon Dec 8 18:57:40 EET 2003 i686 Intel(R) Pentium(R) III CPU family 1133MHz GenuineIntel GNU/Linux Gnu C 3.2.3 Gnu make 3.80 util-linux 2.11z mount 2.11z module-init-tools implemented (heh, I'm not using modules anyways) e2fsprogs 1.33 nfs-utils 1.0.6 Linux C Library 2.3.2 Dynamic linker (ldd) 2.3.2 Procps 3.1.12 Net-tools 1.60 Kbd 1.06 Sh-utils 5.0 $ xfs_info /mnt/xfs/ meta-data=/mnt/xfs isize=256 agcount=35, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=35830966, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =external bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Thanks! - -- Mihai RUSU Email: dizzy@roedu.net GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net "Linux is obsolete" -- AST -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/1tbCPZzOzrZY/1QRAgwWAJ94Sy++UuwQdf7MrqmedL+ngYdxOwCbBoot 2f1W+gzRDzm1BlFZY/Uxo1Y= =Q4Cs -----END PGP SIGNATURE----- --1435322240-1988664075-1071044288=:8346 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=config-kernel Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=config-kernel Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBtYWtlIGNvbmZpZzogZG9u J3QgZWRpdA0KIw0KQ09ORklHX1g4Nj15DQpDT05GSUdfTU1VPXkNCkNPTkZJ R19VSUQxNj15DQpDT05GSUdfR0VORVJJQ19JU0FfRE1BPXkNCg0KIw0KIyBD b2RlIG1hdHVyaXR5IGxldmVsIG9wdGlvbnMNCiMNCkNPTkZJR19FWFBFUklN RU5UQUw9eQ0KQ09ORklHX0NMRUFOX0NPTVBJTEU9eQ0KQ09ORklHX1NUQU5E QUxPTkU9eQ0KDQojDQojIEdlbmVyYWwgc2V0dXANCiMNCkNPTkZJR19TV0FQ PXkNCkNPTkZJR19TWVNWSVBDPXkNCiMgQ09ORklHX0JTRF9QUk9DRVNTX0FD Q1QgaXMgbm90IHNldA0KQ09ORklHX1NZU0NUTD15DQpDT05GSUdfTE9HX0JV Rl9TSElGVD0xNQ0KIyBDT05GSUdfSUtDT05GSUcgaXMgbm90IHNldA0KIyBD T05GSUdfRU1CRURERUQgaXMgbm90IHNldA0KQ09ORklHX0tBTExTWU1TPXkN CkNPTkZJR19GVVRFWD15DQpDT05GSUdfRVBPTEw9eQ0KQ09ORklHX0lPU0NI RURfTk9PUD15DQpDT05GSUdfSU9TQ0hFRF9BUz15DQpDT05GSUdfSU9TQ0hF RF9ERUFETElORT15DQoNCiMNCiMgTG9hZGFibGUgbW9kdWxlIHN1cHBvcnQN CiMNCiMgQ09ORklHX01PRFVMRVMgaXMgbm90IHNldA0KDQojDQojIFByb2Nl c3NvciB0eXBlIGFuZCBmZWF0dXJlcw0KIw0KQ09ORklHX1g4Nl9QQz15DQoj IENPTkZJR19YODZfVk9ZQUdFUiBpcyBub3Qgc2V0DQojIENPTkZJR19YODZf TlVNQVEgaXMgbm90IHNldA0KIyBDT05GSUdfWDg2X1NVTU1JVCBpcyBub3Qg c2V0DQojIENPTkZJR19YODZfQklHU01QIGlzIG5vdCBzZXQNCiMgQ09ORklH X1g4Nl9WSVNXUyBpcyBub3Qgc2V0DQojIENPTkZJR19YODZfR0VORVJJQ0FS Q0ggaXMgbm90IHNldA0KIyBDT05GSUdfWDg2X0VTNzAwMCBpcyBub3Qgc2V0 DQojIENPTkZJR19NMzg2IGlzIG5vdCBzZXQNCiMgQ09ORklHX000ODYgaXMg bm90IHNldA0KIyBDT05GSUdfTTU4NiBpcyBub3Qgc2V0DQojIENPTkZJR19N NTg2VFNDIGlzIG5vdCBzZXQNCiMgQ09ORklHX001ODZNTVggaXMgbm90IHNl dA0KIyBDT05GSUdfTTY4NiBpcyBub3Qgc2V0DQojIENPTkZJR19NUEVOVElV TUlJIGlzIG5vdCBzZXQNCkNPTkZJR19NUEVOVElVTUlJST15DQojIENPTkZJ R19NUEVOVElVTTQgaXMgbm90IHNldA0KIyBDT05GSUdfTUs2IGlzIG5vdCBz ZXQNCiMgQ09ORklHX01LNyBpcyBub3Qgc2V0DQojIENPTkZJR19NSzggaXMg bm90IHNldA0KIyBDT05GSUdfTUVMQU4gaXMgbm90IHNldA0KIyBDT05GSUdf TUNSVVNPRSBpcyBub3Qgc2V0DQojIENPTkZJR19NV0lOQ0hJUEM2IGlzIG5v dCBzZXQNCiMgQ09ORklHX01XSU5DSElQMiBpcyBub3Qgc2V0DQojIENPTkZJ R19NV0lOQ0hJUDNEIGlzIG5vdCBzZXQNCiMgQ09ORklHX01DWVJJWElJSSBp cyBub3Qgc2V0DQojIENPTkZJR19NVklBQzNfMiBpcyBub3Qgc2V0DQojIENP TkZJR19YODZfR0VORVJJQyBpcyBub3Qgc2V0DQpDT05GSUdfWDg2X0NNUFhD SEc9eQ0KQ09ORklHX1g4Nl9YQUREPXkNCkNPTkZJR19YODZfTDFfQ0FDSEVf U0hJRlQ9NQ0KQ09ORklHX1JXU0VNX1hDSEdBRERfQUxHT1JJVEhNPXkNCkNP TkZJR19YODZfV1BfV09SS1NfT0s9eQ0KQ09ORklHX1g4Nl9JTlZMUEc9eQ0K Q09ORklHX1g4Nl9CU1dBUD15DQpDT05GSUdfWDg2X1BPUEFEX09LPXkNCkNP TkZJR19YODZfR09PRF9BUElDPXkNCkNPTkZJR19YODZfSU5URUxfVVNFUkNP UFk9eQ0KQ09ORklHX1g4Nl9VU0VfUFBST19DSEVDS1NVTT15DQpDT05GSUdf SFBFVF9USU1FUj15DQpDT05GSUdfSFBFVF9FTVVMQVRFX1JUQz15DQpDT05G SUdfU01QPXkNCkNPTkZJR19OUl9DUFVTPTINCkNPTkZJR19QUkVFTVBUPXkN CkNPTkZJR19YODZfTE9DQUxfQVBJQz15DQpDT05GSUdfWDg2X0lPX0FQSUM9 eQ0KQ09ORklHX1g4Nl9UU0M9eQ0KQ09ORklHX1g4Nl9NQ0U9eQ0KQ09ORklH X1g4Nl9NQ0VfTk9ORkFUQUw9eQ0KQ09ORklHX1g4Nl9NQ0VfUDRUSEVSTUFM PXkNCiMgQ09ORklHX1RPU0hJQkEgaXMgbm90IHNldA0KIyBDT05GSUdfSThL IGlzIG5vdCBzZXQNCiMgQ09ORklHX01JQ1JPQ09ERSBpcyBub3Qgc2V0DQoj IENPTkZJR19YODZfTVNSIGlzIG5vdCBzZXQNCiMgQ09ORklHX1g4Nl9DUFVJ RCBpcyBub3Qgc2V0DQojIENPTkZJR19FREQgaXMgbm90IHNldA0KIyBDT05G SUdfTk9ISUdITUVNIGlzIG5vdCBzZXQNCkNPTkZJR19ISUdITUVNNEc9eQ0K IyBDT05GSUdfSElHSE1FTTY0RyBpcyBub3Qgc2V0DQpDT05GSUdfSElHSE1F TT15DQojIENPTkZJR19ISUdIUFRFIGlzIG5vdCBzZXQNCiMgQ09ORklHX01B VEhfRU1VTEFUSU9OIGlzIG5vdCBzZXQNCkNPTkZJR19NVFJSPXkNCkNPTkZJ R19IQVZFX0RFQ19MT0NLPXkNCg0KIw0KIyBQb3dlciBtYW5hZ2VtZW50IG9w dGlvbnMgKEFDUEksIEFQTSkNCiMNCiMgQ09ORklHX1BNIGlzIG5vdCBzZXQN Cg0KIw0KIyBBQ1BJIChBZHZhbmNlZCBDb25maWd1cmF0aW9uIGFuZCBQb3dl ciBJbnRlcmZhY2UpIFN1cHBvcnQNCiMNCiMgQ09ORklHX0FDUEkgaXMgbm90 IHNldA0KQ09ORklHX0FDUElfQk9PVD15DQoNCiMNCiMgQ1BVIEZyZXF1ZW5j eSBzY2FsaW5nDQojDQojIENPTkZJR19DUFVfRlJFUSBpcyBub3Qgc2V0DQoj IENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9QRVJGT1JNQU5DRSBpcyBu b3Qgc2V0DQojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9VU0VSU1BB Q0UgaXMgbm90IHNldA0KDQojDQojIEJ1cyBvcHRpb25zIChQQ0ksIFBDTUNJ QSwgRUlTQSwgTUNBLCBJU0EpDQojDQpDT05GSUdfUENJPXkNCiMgQ09ORklH X1BDSV9HT0JJT1MgaXMgbm90IHNldA0KIyBDT05GSUdfUENJX0dPRElSRUNU IGlzIG5vdCBzZXQNCkNPTkZJR19QQ0lfR09BTlk9eQ0KQ09ORklHX1BDSV9C SU9TPXkNCkNPTkZJR19QQ0lfRElSRUNUPXkNCkNPTkZJR19QQ0lfTEVHQUNZ X1BST0M9eQ0KQ09ORklHX1BDSV9OQU1FUz15DQojIENPTkZJR19JU0EgaXMg bm90IHNldA0KIyBDT05GSUdfTUNBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1ND eDIwMCBpcyBub3Qgc2V0DQojIENPTkZJR19IT1RQTFVHIGlzIG5vdCBzZXQN Cg0KIw0KIyBFeGVjdXRhYmxlIGZpbGUgZm9ybWF0cw0KIw0KQ09ORklHX0JJ TkZNVF9FTEY9eQ0KQ09ORklHX0JJTkZNVF9BT1VUPXkNCiMgQ09ORklHX0JJ TkZNVF9NSVNDIGlzIG5vdCBzZXQNCg0KIw0KIyBEZXZpY2UgRHJpdmVycw0K Iw0KDQojDQojIEdlbmVyaWMgRHJpdmVyIE9wdGlvbnMNCiMNCg0KIw0KIyBN ZW1vcnkgVGVjaG5vbG9neSBEZXZpY2VzIChNVEQpDQojDQojIENPTkZJR19N VEQgaXMgbm90IHNldA0KDQojDQojIFBhcmFsbGVsIHBvcnQgc3VwcG9ydA0K Iw0KIyBDT05GSUdfUEFSUE9SVCBpcyBub3Qgc2V0DQoNCiMNCiMgUGx1ZyBh bmQgUGxheSBzdXBwb3J0DQojDQojIENPTkZJR19QTlAgaXMgbm90IHNldA0K DQojDQojIEJsb2NrIGRldmljZXMNCiMNCiMgQ09ORklHX0JMS19ERVZfRkQg aXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0NQUV9EQSBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfQ1BRX0NJU1NfREEgaXMgbm90IHNldA0KQ09ORklHX0JM S19ERVZfREFDOTYwPXkNCiMgQ09ORklHX0JMS19ERVZfVU1FTSBpcyBub3Qg c2V0DQojIENPTkZJR19CTEtfREVWX0xPT1AgaXMgbm90IHNldA0KIyBDT05G SUdfQkxLX0RFVl9OQkQgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9S QU0gaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9JTklUUkQgaXMgbm90 IHNldA0KIyBDT05GSUdfTEJEIGlzIG5vdCBzZXQNCg0KIw0KIyBBVEEvQVRB UEkvTUZNL1JMTCBzdXBwb3J0DQojDQojIENPTkZJR19JREUgaXMgbm90IHNl dA0KDQojDQojIFNDU0kgZGV2aWNlIHN1cHBvcnQNCiMNCkNPTkZJR19TQ1NJ PXkNCkNPTkZJR19TQ1NJX1BST0NfRlM9eQ0KDQojDQojIFNDU0kgc3VwcG9y dCB0eXBlIChkaXNrLCB0YXBlLCBDRC1ST00pDQojDQpDT05GSUdfQkxLX0RF Vl9TRD15DQojIENPTkZJR19DSFJfREVWX1NUIGlzIG5vdCBzZXQNCiMgQ09O RklHX0NIUl9ERVZfT1NTVCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW X1NSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0NIUl9ERVZfU0cgaXMgbm90IHNl dA0KDQojDQojIFNvbWUgU0NTSSBkZXZpY2VzIChlLmcuIENEIGp1a2Vib3gp IHN1cHBvcnQgbXVsdGlwbGUgTFVOcw0KIw0KIyBDT05GSUdfU0NTSV9NVUxU SV9MVU4gaXMgbm90IHNldA0KQ09ORklHX1NDU0lfUkVQT1JUX0xVTlM9eQ0K Q09ORklHX1NDU0lfQ09OU1RBTlRTPXkNCiMgQ09ORklHX1NDU0lfTE9HR0lO RyBpcyBub3Qgc2V0DQoNCiMNCiMgU0NTSSBsb3ctbGV2ZWwgZHJpdmVycw0K Iw0KIyBDT05GSUdfQkxLX0RFVl8zV19YWFhYX1JBSUQgaXMgbm90IHNldA0K IyBDT05GSUdfU0NTSV9BQ0FSRCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJ X0FBQ1JBSUQgaXMgbm90IHNldA0KQ09ORklHX1NDU0lfQUlDN1hYWD15DQpD T05GSUdfQUlDN1hYWF9DTURTX1BFUl9ERVZJQ0U9MzINCkNPTkZJR19BSUM3 WFhYX1JFU0VUX0RFTEFZX01TPTIwMDANCiMgQ09ORklHX0FJQzdYWFhfUFJP QkVfRUlTQV9WTCBpcyBub3Qgc2V0DQojIENPTkZJR19BSUM3WFhYX0JVSUxE X0ZJUk1XQVJFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FJQzdYWFhfREVCVUdf RU5BQkxFIGlzIG5vdCBzZXQNCkNPTkZJR19BSUM3WFhYX0RFQlVHX01BU0s9 MA0KIyBDT05GSUdfQUlDN1hYWF9SRUdfUFJFVFRZX1BSSU5UIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1NDU0lfQUlDN1hYWF9PTEQgaXMgbm90IHNldA0KIyBD T05GSUdfU0NTSV9BSUM3OVhYIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lf QURWQU5TWVMgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9NRUdBUkFJRCBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1NBVEEgaXMgbm90IHNldA0KIyBD T05GSUdfU0NTSV9CVVNMT0dJQyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJ X0NQUUZDVFMgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9ETVgzMTkxRCBp cyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX0VBVEEgaXMgbm90IHNldA0KIyBD T05GSUdfU0NTSV9FQVRBX1BJTyBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJ X0ZVVFVSRV9ET01BSU4gaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9HRFRI IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfSVBTIGlzIG5vdCBzZXQNCiMg Q09ORklHX1NDU0lfSU5JQTEwMCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJ X1NZTTUzQzhYWF8yIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NDU0lfUUxPR0lD X0lTUCBpcyBub3Qgc2V0DQojIENPTkZJR19TQ1NJX1FMT0dJQ19GQyBpcyBu b3Qgc2V0DQojIENPTkZJR19TQ1NJX1FMT0dJQ18xMjgwIGlzIG5vdCBzZXQN CiMgQ09ORklHX1NDU0lfREMzOTV4IGlzIG5vdCBzZXQNCiMgQ09ORklHX1ND U0lfTlNQMzIgaXMgbm90IHNldA0KIyBDT05GSUdfU0NTSV9ERUJVRyBpcyBu b3Qgc2V0DQoNCiMNCiMgTXVsdGktZGV2aWNlIHN1cHBvcnQgKFJBSUQgYW5k IExWTSkNCiMNCiMgQ09ORklHX01EIGlzIG5vdCBzZXQNCg0KIw0KIyBGdXNp b24gTVBUIGRldmljZSBzdXBwb3J0DQojDQojIENPTkZJR19GVVNJT04gaXMg bm90IHNldA0KDQojDQojIElFRUUgMTM5NCAoRmlyZVdpcmUpIHN1cHBvcnQg KEVYUEVSSU1FTlRBTCkNCiMNCiMgQ09ORklHX0lFRUUxMzk0IGlzIG5vdCBz ZXQNCg0KIw0KIyBJMk8gZGV2aWNlIHN1cHBvcnQNCiMNCiMgQ09ORklHX0ky TyBpcyBub3Qgc2V0DQoNCiMNCiMgTmV0d29ya2luZyBzdXBwb3J0DQojDQpD T05GSUdfTkVUPXkNCg0KIw0KIyBOZXR3b3JraW5nIG9wdGlvbnMNCiMNCkNP TkZJR19QQUNLRVQ9eQ0KQ09ORklHX1BBQ0tFVF9NTUFQPXkNCiMgQ09ORklH X05FVExJTktfREVWIGlzIG5vdCBzZXQNCkNPTkZJR19VTklYPXkNCiMgQ09O RklHX05FVF9LRVkgaXMgbm90IHNldA0KQ09ORklHX0lORVQ9eQ0KIyBDT05G SUdfSVBfTVVMVElDQVNUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX0FEVkFO Q0VEX1JPVVRFUiBpcyBub3Qgc2V0DQojIENPTkZJR19JUF9QTlAgaXMgbm90 IHNldA0KIyBDT05GSUdfTkVUX0lQSVAgaXMgbm90IHNldA0KIyBDT05GSUdf TkVUX0lQR1JFIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FSUEQgaXMgbm90IHNl dA0KIyBDT05GSUdfSU5FVF9FQ04gaXMgbm90IHNldA0KIyBDT05GSUdfU1lO X0NPT0tJRVMgaXMgbm90IHNldA0KIyBDT05GSUdfSU5FVF9BSCBpcyBub3Qg c2V0DQojIENPTkZJR19JTkVUX0VTUCBpcyBub3Qgc2V0DQojIENPTkZJR19J TkVUX0lQQ09NUCBpcyBub3Qgc2V0DQoNCiMNCiMgSVA6IFZpcnR1YWwgU2Vy dmVyIENvbmZpZ3VyYXRpb24NCiMNCiMgQ09ORklHX0lQX1ZTIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0lQVjYgaXMgbm90IHNldA0KIyBDT05GSUdfREVDTkVU IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JSSURHRSBpcyBub3Qgc2V0DQpDT05G SUdfTkVURklMVEVSPXkNCiMgQ09ORklHX05FVEZJTFRFUl9ERUJVRyBpcyBu b3Qgc2V0DQoNCiMNCiMgSVA6IE5ldGZpbHRlciBDb25maWd1cmF0aW9uDQoj DQojIENPTkZJR19JUF9ORl9DT05OVFJBQ0sgaXMgbm90IHNldA0KIyBDT05G SUdfSVBfTkZfUVVFVUUgaXMgbm90IHNldA0KQ09ORklHX0lQX05GX0lQVEFC TEVTPXkNCiMgQ09ORklHX0lQX05GX01BVENIX0xJTUlUIGlzIG5vdCBzZXQN CiMgQ09ORklHX0lQX05GX01BVENIX0lQUkFOR0UgaXMgbm90IHNldA0KIyBD T05GSUdfSVBfTkZfTUFUQ0hfTUFDIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQ X05GX01BVENIX1BLVFRZUEUgaXMgbm90IHNldA0KIyBDT05GSUdfSVBfTkZf TUFUQ0hfTUFSSyBpcyBub3Qgc2V0DQojIENPTkZJR19JUF9ORl9NQVRDSF9N VUxUSVBPUlQgaXMgbm90IHNldA0KIyBDT05GSUdfSVBfTkZfTUFUQ0hfVE9T IGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX05GX01BVENIX1JFQ0VOVCBpcyBu b3Qgc2V0DQojIENPTkZJR19JUF9ORl9NQVRDSF9FQ04gaXMgbm90IHNldA0K IyBDT05GSUdfSVBfTkZfTUFUQ0hfRFNDUCBpcyBub3Qgc2V0DQojIENPTkZJ R19JUF9ORl9NQVRDSF9BSF9FU1AgaXMgbm90IHNldA0KIyBDT05GSUdfSVBf TkZfTUFUQ0hfTEVOR1RIIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX05GX01B VENIX1RUTCBpcyBub3Qgc2V0DQojIENPTkZJR19JUF9ORl9NQVRDSF9UQ1BN U1MgaXMgbm90IHNldA0KIyBDT05GSUdfSVBfTkZfTUFUQ0hfT1dORVIgaXMg bm90IHNldA0KQ09ORklHX0lQX05GX0ZJTFRFUj15DQpDT05GSUdfSVBfTkZf VEFSR0VUX1JFSkVDVD15DQojIENPTkZJR19JUF9ORl9NQU5HTEUgaXMgbm90 IHNldA0KIyBDT05GSUdfSVBfTkZfVEFSR0VUX0xPRyBpcyBub3Qgc2V0DQoj IENPTkZJR19JUF9ORl9UQVJHRVRfVUxPRyBpcyBub3Qgc2V0DQojIENPTkZJ R19JUF9ORl9UQVJHRVRfVENQTVNTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQ X05GX0FSUFRBQkxFUyBpcyBub3Qgc2V0DQoNCiMNCiMgU0NUUCBDb25maWd1 cmF0aW9uIChFWFBFUklNRU5UQUwpDQojDQpDT05GSUdfSVBWNl9TQ1RQX189 eQ0KIyBDT05GSUdfSVBfU0NUUCBpcyBub3Qgc2V0DQojIENPTkZJR19BVE0g aXMgbm90IHNldA0KIyBDT05GSUdfVkxBTl84MDIxUSBpcyBub3Qgc2V0DQoj IENPTkZJR19MTEMyIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQWCBpcyBub3Qg c2V0DQojIENPTkZJR19BVEFMSyBpcyBub3Qgc2V0DQojIENPTkZJR19YMjUg aXMgbm90IHNldA0KIyBDT05GSUdfTEFQQiBpcyBub3Qgc2V0DQojIENPTkZJ R19ORVRfRElWRVJUIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VDT05FVCBpcyBu b3Qgc2V0DQojIENPTkZJR19XQU5fUk9VVEVSIGlzIG5vdCBzZXQNCiMgQ09O RklHX05FVF9GQVNUUk9VVEUgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX0hX X0ZMT1dDT05UUk9MIGlzIG5vdCBzZXQNCg0KIw0KIyBRb1MgYW5kL29yIGZh aXIgcXVldWVpbmcNCiMNCiMgQ09ORklHX05FVF9TQ0hFRCBpcyBub3Qgc2V0 DQoNCiMNCiMgTmV0d29yayB0ZXN0aW5nDQojDQojIENPTkZJR19ORVRfUEtU R0VOIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRERVZJQ0VTPXkNCg0KIw0KIyBB UkNuZXQgZGV2aWNlcw0KIw0KIyBDT05GSUdfQVJDTkVUIGlzIG5vdCBzZXQN CkNPTkZJR19EVU1NWT15DQojIENPTkZJR19CT05ESU5HIGlzIG5vdCBzZXQN CiMgQ09ORklHX0VRVUFMSVpFUiBpcyBub3Qgc2V0DQojIENPTkZJR19UVU4g aXMgbm90IHNldA0KDQojDQojIEV0aGVybmV0ICgxMCBvciAxMDBNYml0KQ0K Iw0KQ09ORklHX05FVF9FVEhFUk5FVD15DQojIENPTkZJR19NSUkgaXMgbm90 IHNldA0KIyBDT05GSUdfSEFQUFlNRUFMIGlzIG5vdCBzZXQNCiMgQ09ORklH X1NVTkdFTSBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfVkVORE9SXzNDT00g aXMgbm90IHNldA0KDQojDQojIFR1bGlwIGZhbWlseSBuZXR3b3JrIGRldmlj ZSBzdXBwb3J0DQojDQojIENPTkZJR19ORVRfVFVMSVAgaXMgbm90IHNldA0K IyBDT05GSUdfSFAxMDAgaXMgbm90IHNldA0KQ09ORklHX05FVF9QQ0k9eQ0K IyBDT05GSUdfUENORVQzMiBpcyBub3Qgc2V0DQojIENPTkZJR19BTUQ4MTEx X0VUSCBpcyBub3Qgc2V0DQojIENPTkZJR19BREFQVEVDX1NUQVJGSVJFIGlz IG5vdCBzZXQNCiMgQ09ORklHX0I0NCBpcyBub3Qgc2V0DQojIENPTkZJR19E R1JTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VFUFJPMTAwIGlzIG5vdCBzZXQN CkNPTkZJR19FMTAwPXkNCiMgQ09ORklHX0ZFQUxOWCBpcyBub3Qgc2V0DQoj IENPTkZJR19OQVRTRU1JIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FMktfUENJ IGlzIG5vdCBzZXQNCiMgQ09ORklHXzgxMzlDUCBpcyBub3Qgc2V0DQojIENP TkZJR184MTM5VE9PIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NJUzkwMCBpcyBu b3Qgc2V0DQojIENPTkZJR19FUElDMTAwIGlzIG5vdCBzZXQNCiMgQ09ORklH X1NVTkRBTkNFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1RMQU4gaXMgbm90IHNl dA0KIyBDT05GSUdfVklBX1JISU5FIGlzIG5vdCBzZXQNCg0KIw0KIyBFdGhl cm5ldCAoMTAwMCBNYml0KQ0KIw0KIyBDT05GSUdfQUNFTklDIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0RMMksgaXMgbm90IHNldA0KIyBDT05GSUdfRTEwMDAg aXMgbm90IHNldA0KIyBDT05GSUdfTlM4MzgyMCBpcyBub3Qgc2V0DQojIENP TkZJR19IQU1BQ0hJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1lFTExPV0ZJTiBp cyBub3Qgc2V0DQojIENPTkZJR19SODE2OSBpcyBub3Qgc2V0DQojIENPTkZJ R19TSVMxOTAgaXMgbm90IHNldA0KIyBDT05GSUdfU0s5OExJTiBpcyBub3Qg c2V0DQojIENPTkZJR19USUdPTjMgaXMgbm90IHNldA0KDQojDQojIEV0aGVy bmV0ICgxMDAwMCBNYml0KQ0KIw0KIyBDT05GSUdfSVhHQiBpcyBub3Qgc2V0 DQojIENPTkZJR19GRERJIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hJUFBJIGlz IG5vdCBzZXQNCiMgQ09ORklHX1BQUCBpcyBub3Qgc2V0DQojIENPTkZJR19T TElQIGlzIG5vdCBzZXQNCg0KIw0KIyBXaXJlbGVzcyBMQU4gKG5vbi1oYW1y YWRpbykNCiMNCiMgQ09ORklHX05FVF9SQURJTyBpcyBub3Qgc2V0DQoNCiMN CiMgVG9rZW4gUmluZyBkZXZpY2VzDQojDQojIENPTkZJR19UUiBpcyBub3Qg c2V0DQojIENPTkZJR19ORVRfRkMgaXMgbm90IHNldA0KIyBDT05GSUdfUkNQ Q0kgaXMgbm90IHNldA0KIyBDT05GSUdfU0hBUEVSIGlzIG5vdCBzZXQNCg0K Iw0KIyBXYW4gaW50ZXJmYWNlcw0KIw0KIyBDT05GSUdfV0FOIGlzIG5vdCBz ZXQNCg0KIw0KIyBBbWF0ZXVyIFJhZGlvIHN1cHBvcnQNCiMNCiMgQ09ORklH X0hBTVJBRElPIGlzIG5vdCBzZXQNCg0KIw0KIyBJckRBIChpbmZyYXJlZCkg c3VwcG9ydA0KIw0KIyBDT05GSUdfSVJEQSBpcyBub3Qgc2V0DQoNCiMNCiMg Qmx1ZXRvb3RoIHN1cHBvcnQNCiMNCiMgQ09ORklHX0JUIGlzIG5vdCBzZXQN Cg0KIw0KIyBJU0ROIHN1YnN5c3RlbQ0KIw0KIyBDT05GSUdfSVNETl9CT09M IGlzIG5vdCBzZXQNCg0KIw0KIyBUZWxlcGhvbnkgU3VwcG9ydA0KIw0KIyBD T05GSUdfUEhPTkUgaXMgbm90IHNldA0KDQojDQojIElucHV0IGRldmljZSBz dXBwb3J0DQojDQpDT05GSUdfSU5QVVQ9eQ0KDQojDQojIFVzZXJsYW5kIGlu dGVyZmFjZXMNCiMNCkNPTkZJR19JTlBVVF9NT1VTRURFVj15DQpDT05GSUdf SU5QVVRfTU9VU0VERVZfUFNBVVg9eQ0KQ09ORklHX0lOUFVUX01PVVNFREVW X1NDUkVFTl9YPTEwMjQNCkNPTkZJR19JTlBVVF9NT1VTRURFVl9TQ1JFRU5f WT03NjgNCiMgQ09ORklHX0lOUFVUX0pPWURFViBpcyBub3Qgc2V0DQojIENP TkZJR19JTlBVVF9UU0RFViBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9F VkRFViBpcyBub3Qgc2V0DQojIENPTkZJR19JTlBVVF9FVkJVRyBpcyBub3Qg c2V0DQoNCiMNCiMgSW5wdXQgSS9PIGRyaXZlcnMNCiMNCiMgQ09ORklHX0dB TUVQT1JUIGlzIG5vdCBzZXQNCkNPTkZJR19TT1VORF9HQU1FUE9SVD15DQpD T05GSUdfU0VSSU89eQ0KQ09ORklHX1NFUklPX0k4MDQyPXkNCiMgQ09ORklH X1NFUklPX1NFUlBPUlQgaXMgbm90IHNldA0KIyBDT05GSUdfU0VSSU9fQ1Q4 MkM3MTAgaXMgbm90IHNldA0KIyBDT05GSUdfU0VSSU9fUENJUFMyIGlzIG5v dCBzZXQNCg0KIw0KIyBJbnB1dCBEZXZpY2UgRHJpdmVycw0KIw0KQ09ORklH X0lOUFVUX0tFWUJPQVJEPXkNCkNPTkZJR19LRVlCT0FSRF9BVEtCRD15DQoj IENPTkZJR19LRVlCT0FSRF9TVU5LQkQgaXMgbm90IHNldA0KIyBDT05GSUdf S0VZQk9BUkRfWFRLQkQgaXMgbm90IHNldA0KIyBDT05GSUdfS0VZQk9BUkRf TkVXVE9OIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX01PVVNFIGlzIG5v dCBzZXQNCiMgQ09ORklHX0lOUFVUX0pPWVNUSUNLIGlzIG5vdCBzZXQNCiMg Q09ORklHX0lOUFVUX1RPVUNIU0NSRUVOIGlzIG5vdCBzZXQNCiMgQ09ORklH X0lOUFVUX01JU0MgaXMgbm90IHNldA0KDQojDQojIENoYXJhY3RlciBkZXZp Y2VzDQojDQpDT05GSUdfVlQ9eQ0KQ09ORklHX1ZUX0NPTlNPTEU9eQ0KQ09O RklHX0hXX0NPTlNPTEU9eQ0KIyBDT05GSUdfU0VSSUFMX05PTlNUQU5EQVJE IGlzIG5vdCBzZXQNCg0KIw0KIyBTZXJpYWwgZHJpdmVycw0KIw0KQ09ORklH X1NFUklBTF84MjUwPXkNCkNPTkZJR19TRVJJQUxfODI1MF9DT05TT0xFPXkN CkNPTkZJR19TRVJJQUxfODI1MF9OUl9VQVJUUz00DQojIENPTkZJR19TRVJJ QUxfODI1MF9FWFRFTkRFRCBpcyBub3Qgc2V0DQoNCiMNCiMgTm9uLTgyNTAg c2VyaWFsIHBvcnQgc3VwcG9ydA0KIw0KQ09ORklHX1NFUklBTF9DT1JFPXkN CkNPTkZJR19TRVJJQUxfQ09SRV9DT05TT0xFPXkNCkNPTkZJR19VTklYOThf UFRZUz15DQpDT05GSUdfVU5JWDk4X1BUWV9DT1VOVD0yNTYNCg0KIw0KIyBJ MkMgc3VwcG9ydA0KIw0KIyBDT05GSUdfSTJDIGlzIG5vdCBzZXQNCg0KIw0K IyBJMkMgQWxnb3JpdGhtcw0KIw0KDQojDQojIEkyQyBIYXJkd2FyZSBCdXMg c3VwcG9ydA0KIw0KDQojDQojIEkyQyBIYXJkd2FyZSBTZW5zb3JzIENoaXAg c3VwcG9ydA0KIw0KIyBDT05GSUdfSTJDX1NFTlNPUiBpcyBub3Qgc2V0DQoN CiMNCiMgTWljZQ0KIw0KIyBDT05GSUdfQlVTTU9VU0UgaXMgbm90IHNldA0K IyBDT05GSUdfUUlDMDJfVEFQRSBpcyBub3Qgc2V0DQoNCiMNCiMgSVBNSQ0K Iw0KIyBDT05GSUdfSVBNSV9IQU5ETEVSIGlzIG5vdCBzZXQNCg0KIw0KIyBX YXRjaGRvZyBDYXJkcw0KIw0KIyBDT05GSUdfV0FUQ0hET0cgaXMgbm90IHNl dA0KIyBDT05GSUdfSFdfUkFORE9NIGlzIG5vdCBzZXQNCiMgQ09ORklHX05W UkFNIGlzIG5vdCBzZXQNCkNPTkZJR19SVEM9eQ0KIyBDT05GSUdfRFRMSyBp cyBub3Qgc2V0DQojIENPTkZJR19SMzk2NCBpcyBub3Qgc2V0DQojIENPTkZJ R19BUFBMSUNPTSBpcyBub3Qgc2V0DQojIENPTkZJR19TT05ZUEkgaXMgbm90 IHNldA0KDQojDQojIEZ0YXBlLCB0aGUgZmxvcHB5IHRhcGUgZGV2aWNlIGRy aXZlcg0KIw0KIyBDT05GSUdfQUdQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RS TSBpcyBub3Qgc2V0DQojIENPTkZJR19NV0FWRSBpcyBub3Qgc2V0DQojIENP TkZJR19SQVdfRFJJVkVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX0hBTkdDSEVD S19USU1FUiBpcyBub3Qgc2V0DQoNCiMNCiMgTXVsdGltZWRpYSBkZXZpY2Vz DQojDQojIENPTkZJR19WSURFT19ERVYgaXMgbm90IHNldA0KDQojDQojIERp Z2l0YWwgVmlkZW8gQnJvYWRjYXN0aW5nIERldmljZXMNCiMNCiMgQ09ORklH X0RWQiBpcyBub3Qgc2V0DQoNCiMNCiMgR3JhcGhpY3Mgc3VwcG9ydA0KIw0K IyBDT05GSUdfRkIgaXMgbm90IHNldA0KIyBDT05GSUdfVklERU9fU0VMRUNU IGlzIG5vdCBzZXQNCg0KIw0KIyBDb25zb2xlIGRpc3BsYXkgZHJpdmVyIHN1 cHBvcnQNCiMNCkNPTkZJR19WR0FfQ09OU09MRT15DQojIENPTkZJR19NREFf Q09OU09MRSBpcyBub3Qgc2V0DQpDT05GSUdfRFVNTVlfQ09OU09MRT15DQoN CiMNCiMgU291bmQNCiMNCiMgQ09ORklHX1NPVU5EIGlzIG5vdCBzZXQNCg0K Iw0KIyBVU0Igc3VwcG9ydA0KIw0KIyBDT05GSUdfVVNCIGlzIG5vdCBzZXQN CiMgQ09ORklHX1VTQl9HQURHRVQgaXMgbm90IHNldA0KDQojDQojIEZpbGUg c3lzdGVtcw0KIw0KQ09ORklHX0VYVDJfRlM9eQ0KIyBDT05GSUdfRVhUMl9G U19YQVRUUiBpcyBub3Qgc2V0DQpDT05GSUdfRVhUM19GUz15DQojIENPTkZJ R19FWFQzX0ZTX1hBVFRSIGlzIG5vdCBzZXQNCkNPTkZJR19KQkQ9eQ0KIyBD T05GSUdfSkJEX0RFQlVHIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFSVNFUkZT X0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0pGU19GUyBpcyBub3Qgc2V0DQpD T05GSUdfWEZTX0ZTPXkNCiMgQ09ORklHX1hGU19SVCBpcyBub3Qgc2V0DQoj IENPTkZJR19YRlNfUVVPVEEgaXMgbm90IHNldA0KIyBDT05GSUdfWEZTX1BP U0lYX0FDTCBpcyBub3Qgc2V0DQojIENPTkZJR19NSU5JWF9GUyBpcyBub3Qg c2V0DQojIENPTkZJR19ST01GU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19R VU9UQSBpcyBub3Qgc2V0DQojIENPTkZJR19BVVRPRlNfRlMgaXMgbm90IHNl dA0KIyBDT05GSUdfQVVUT0ZTNF9GUyBpcyBub3Qgc2V0DQoNCiMNCiMgQ0Qt Uk9NL0RWRCBGaWxlc3lzdGVtcw0KIw0KIyBDT05GSUdfSVNPOTY2MF9GUyBp cyBub3Qgc2V0DQojIENPTkZJR19VREZfRlMgaXMgbm90IHNldA0KDQojDQoj IERPUy9GQVQvTlQgRmlsZXN5c3RlbXMNCiMNCiMgQ09ORklHX0ZBVF9GUyBp cyBub3Qgc2V0DQojIENPTkZJR19OVEZTX0ZTIGlzIG5vdCBzZXQNCg0KIw0K IyBQc2V1ZG8gZmlsZXN5c3RlbXMNCiMNCkNPTkZJR19QUk9DX0ZTPXkNCkNP TkZJR19QUk9DX0tDT1JFPXkNCkNPTkZJR19ERVZGU19GUz15DQpDT05GSUdf REVWRlNfTU9VTlQ9eQ0KIyBDT05GSUdfREVWRlNfREVCVUcgaXMgbm90IHNl dA0KQ09ORklHX0RFVlBUU19GUz15DQojIENPTkZJR19ERVZQVFNfRlNfWEFU VFIgaXMgbm90IHNldA0KQ09ORklHX1RNUEZTPXkNCiMgQ09ORklHX0hVR0VU TEJGUyBpcyBub3Qgc2V0DQojIENPTkZJR19IVUdFVExCX1BBR0UgaXMgbm90 IHNldA0KQ09ORklHX1JBTUZTPXkNCg0KIw0KIyBNaXNjZWxsYW5lb3VzIGZp bGVzeXN0ZW1zDQojDQojIENPTkZJR19BREZTX0ZTIGlzIG5vdCBzZXQNCiMg Q09ORklHX0FGRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfSEZTX0ZTIGlz IG5vdCBzZXQNCiMgQ09ORklHX0JFRlNfRlMgaXMgbm90IHNldA0KIyBDT05G SUdfQkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VGU19GUyBpcyBub3Qg c2V0DQojIENPTkZJR19DUkFNRlMgaXMgbm90IHNldA0KIyBDT05GSUdfVlhG U19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19IUEZTX0ZTIGlzIG5vdCBzZXQN CiMgQ09ORklHX1FOWDRGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJR19TWVNW X0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VGU19GUyBpcyBub3Qgc2V0DQoN CiMNCiMgTmV0d29yayBGaWxlIFN5c3RlbXMNCiMNCkNPTkZJR19ORlNfRlM9 eQ0KQ09ORklHX05GU19WMz15DQojIENPTkZJR19ORlNfVjQgaXMgbm90IHNl dA0KIyBDT05GSUdfTkZTX0RJUkVDVElPIGlzIG5vdCBzZXQNCkNPTkZJR19O RlNEPXkNCkNPTkZJR19ORlNEX1YzPXkNCiMgQ09ORklHX05GU0RfVjQgaXMg bm90IHNldA0KIyBDT05GSUdfTkZTRF9UQ1AgaXMgbm90IHNldA0KQ09ORklH X0xPQ0tEPXkNCkNPTkZJR19MT0NLRF9WND15DQpDT05GSUdfRVhQT1JURlM9 eQ0KQ09ORklHX1NVTlJQQz15DQojIENPTkZJR19TVU5SUENfR1NTIGlzIG5v dCBzZXQNCiMgQ09ORklHX1NNQl9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19D SUZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0DQoj IENPTkZJR19DT0RBX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOVEVSTUVa Wk9fRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQUZTX0ZTIGlzIG5vdCBzZXQN Cg0KIw0KIyBQYXJ0aXRpb24gVHlwZXMNCiMNCiMgQ09ORklHX1BBUlRJVElP Tl9BRFZBTkNFRCBpcyBub3Qgc2V0DQpDT05GSUdfTVNET1NfUEFSVElUSU9O PXkNCg0KIw0KIyBQcm9maWxpbmcgc3VwcG9ydA0KIw0KIyBDT05GSUdfUFJP RklMSU5HIGlzIG5vdCBzZXQNCg0KIw0KIyBLZXJuZWwgaGFja2luZw0KIw0K IyBDT05GSUdfREVCVUdfS0VSTkVMIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RF QlVHX1NQSU5MT0NLX1NMRUVQIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZSQU1F X1BPSU5URVIgaXMgbm90IHNldA0KQ09ORklHX1g4Nl9FWFRSQV9JUlFTPXkN CkNPTkZJR19YODZfRklORF9TTVBfQ09ORklHPXkNCkNPTkZJR19YODZfTVBQ QVJTRT15DQoNCiMNCiMgU2VjdXJpdHkgb3B0aW9ucw0KIw0KQ09ORklHX1NF Q1VSSVRZPXkNCiMgQ09ORklHX1NFQ1VSSVRZX05FVFdPUksgaXMgbm90IHNl dA0KQ09ORklHX1NFQ1VSSVRZX0NBUEFCSUxJVElFUz15DQojIENPTkZJR19T RUNVUklUWV9TRUxJTlVYIGlzIG5vdCBzZXQNCg0KIw0KIyBDcnlwdG9ncmFw aGljIG9wdGlvbnMNCiMNCiMgQ09ORklHX0NSWVBUTyBpcyBub3Qgc2V0DQoN CiMNCiMgTGlicmFyeSByb3V0aW5lcw0KIw0KIyBDT05GSUdfQ1JDMzIgaXMg bm90IHNldA0KQ09ORklHX1g4Nl9TTVA9eQ0KQ09ORklHX1g4Nl9IVD15DQpD T05GSUdfWDg2X0JJT1NfUkVCT09UPXkNCkNPTkZJR19YODZfVFJBTVBPTElO RT15DQpDT05GSUdfUEM9eQ0K --1435322240-1988664075-1071044288=:8346-- From owner-linux-xfs@oss.sgi.com Wed Dec 10 01:23:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 01:23:40 -0800 (PST) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBA9MwTa011036 for ; Wed, 10 Dec 2003 01:23:01 -0800 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 9271F94A94; Wed, 10 Dec 2003 10:22:56 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id 3B21E9496F; Wed, 10 Dec 2003 10:22:56 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id hBA9Oqpq002059; Wed, 10 Dec 2003 10:24:52 +0100 Subject: Re: Fwd: XFS merged in 2.4 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Eric Sandeen Cc: Gabor Burjan , linux-xfs@oss.sgi.com In-Reply-To: <1070994862.13823.39.camel@stout.americas.sgi.com> References: <1070909208.4918.0.camel@david.internal.NorcrossGroup.com> <1070913046.2449.53.camel@localhost.localdomain> <1070913915.9510.11.camel@stout.americas.sgi.com> <20031209164743.GA29314@odin.sis.hu> <1070994862.13823.39.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 10 Dec 2003 10:24:52 +0100 Message-Id: <1071048293.1823.3.camel@venus> Mime-Version: 1.0 X-archive-position: 1322 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 519 Lines: 21 On Tue, 2003-12-09 at 19:34, Eric Sandeen wrote: > On Tue, 2003-12-09 at 10:47, Gabor Burjan wrote: > > > Which version of XFS is in Marcelo's branch? > > > > xfs_version.h from patch-2.4.23-bk7.bz2 contains only this define: > > > > #define XFS_VERSION_STRING "SGI XFS" > > Top of the development tree, minus dmapi and acls. > Hi, Will ACLs be included in 2.4.24? Or SGI will provide another patch? Or the only way to get ACLs working would be to use SGI's CVS? Will xfsdump work without dmapi? Regards, Olaf From owner-linux-xfs@oss.sgi.com Wed Dec 10 02:11:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 02:12:11 -0800 (PST) Received: from hermod.acsalaska.net (hermod.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAABmTa017888 for ; Wed, 10 Dec 2003 02:11:49 -0800 Received: from erbenson.alaska.net (10-pm21.nwc.alaska.net [209.112.143.10]) by hermod.acsalaska.net (8.12.10/8.12.10) with ESMTP id hBAABiFp004384 for ; Wed, 10 Dec 2003 01:11:45 -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 6A8C739E7 for ; Wed, 10 Dec 2003 01:11:43 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 2717340FF35; Wed, 10 Dec 2003 01:11:43 -0900 (AKST) Date: Wed, 10 Dec 2003 01:11:43 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Fwd: XFS merged in 2.4 Message-ID: <20031210101142.GF3294@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1070909208.4918.0.camel@david.internal.NorcrossGroup.com> <1070913046.2449.53.camel@localhost.localdomain> <1070913915.9510.11.camel@stout.americas.sgi.com> <20031209164743.GA29314@odin.sis.hu> <1070994862.13823.39.camel@stout.americas.sgi.com> <1071048293.1823.3.camel@venus> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z+pzSjdB7cqptWpS" Content-Disposition: inline In-Reply-To: <1071048293.1823.3.camel@venus> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.38; SA 2.60; spamdefang 1.76 X-archive-position: 1323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1711 Lines: 59 --z+pzSjdB7cqptWpS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 10, 2003 at 10:24:52AM +0100, Olaf Fr?czyk wrote: > On Tue, 2003-12-09 at 19:34, Eric Sandeen wrote: > > On Tue, 2003-12-09 at 10:47, Gabor Burjan wrote: > >=20 > > > Which version of XFS is in Marcelo's branch? > > >=20 > > > xfs_version.h from patch-2.4.23-bk7.bz2 contains only this define: > > >=20 > > > #define XFS_VERSION_STRING "SGI XFS" > >=20 > > Top of the development tree, minus dmapi and acls. > >=20 > Hi, > Will ACLs be included in 2.4.24? Or SGI will provide another patch? Or probably not from the sounds of it. > the only way to get ACLs working would be to use SGI's CVS? the acl patch has always been utterly trivial, it hasn't changed in ages so you can apply any split-acl patch to the last several kernels.=20 the acl patch adds three trivial macro checks to fs/namei.c, two new defines to include/linux/fs.h, and one new header file defining the format of the acl xattr. why its not mergable is beyond me (its in 2.6). > Will xfsdump work without dmapi? yes. dmapi has always been configurable and a separate split patch. dmapi is not in 2.6 either i don't think, kernel developers want a more generic interface or something. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --z+pzSjdB7cqptWpS 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 iEYEARECAAYFAj/W8V4ACgkQJKx7GixEevyyQACgkSaGmRLbiPjGUkvtYvOwGX3+ RGkAoJ2XX0AAF0fFyQx2Dc+o5LU/Z+Nb =JiAz -----END PGP SIGNATURE----- --z+pzSjdB7cqptWpS-- From owner-linux-xfs@oss.sgi.com Wed Dec 10 02:12:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 02:12:45 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBAACYTa018135 for ; Wed, 10 Dec 2003 02:12:34 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBAACYee018134 for linux-xfs@oss.sgi.com; Wed, 10 Dec 2003 02:12:34 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBAACWTe018109 for ; Wed, 10 Dec 2003 02:12:32 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBA9tNY1016842; Wed, 10 Dec 2003 01:55:23 -0800 Date: Wed, 10 Dec 2003 01:55:23 -0800 Message-Id: <200312100955.hBA9tNY1016842@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1324 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1156 Lines: 30 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From dizzy@roedu.net 2003-10-12 01:55 PDT ------- I can confirm similar problems which (if my memory holds) started up after 1.2 XFS release (I didnt followed CVS XFS at that time so they possibly started between 1.1 and 1.2 release). I have reported this too as see here http://oss.sgi.com/archives/linux-xfs/2003-01/msg00059.html To me it looks like either XFS or some other common linux code (VM? VFS?) is having a big memory pressure and doesnt want to give up cached memory which triggers the OOM killer. Im not a kernel dev so this explanation may be stupid :) It would be interesting for Chris to try out 2.4.23 or later based xfs kernel. They changed the VM code and disabled(?) the OOM killer. I must say that my systems after upgrading to 2.4.23 based kernel dont have that problem (the memory "leak") anymore and seem to work pretty nice (almost like the 2.4.9-31 XFS 1.1 release which worked best of all XFS releases for me until now). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 10 02:28:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 02:29:02 -0800 (PST) Received: from castor.acu.ac.uk (castor.acu.ac.uk [194.81.120.81]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAASnTa020277 for ; Wed, 10 Dec 2003 02:28:50 -0800 Received: from acu.ac.uk (arcturus.acu.ac.uk [194.81.120.110]) by castor.acu.ac.uk (8.12.10/8.12.10) with ESMTP id hBAASgU4009950; Wed, 10 Dec 2003 10:28:43 GMT Message-ID: <3FD6F55A.2060707@acu.ac.uk> Date: Wed, 10 Dec 2003 10:28:42 +0000 From: Mike Brodbelt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Simon Matter CC: linux-xfs@oss.sgi.com Subject: Re: XFS filesystem shutdown References: <3FD5ED83.7000500@acu.ac.uk> <1432.10.1.200.117.1071040970.squirrel@imap01.ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version devel-20031209', clamav-milter version '0.65i' X-archive-position: 1325 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: m.brodbelt@acu.ac.uk Precedence: bulk X-list: linux-xfs Content-Length: 1530 Lines: 36 Simon Matter wrote: > I've been running cyrus-imapd servers on XFS for years now without any > problems related to XFS. I also had the sig11 and die problem but it never > affected XFS, and I think it really should not. I agree - a non root userland process should definitely not affect the filesystem. I mentioned it only because it may be a reason for a non-expected pattern of fs operations. >>Last week, I get this:- >> >>xfs_inotobp: xfs_imap() returned an error 22 on sd (8,8). Returning error. >>xfs_iunlink_remove: xfs_inotobp() returned an error 22 on sd (8,8). >>Returning an error. >>xfs_inactive: 0xfs_ifree() error 22 on sd (8,8) >>xfs_force_shutdown: (sd(8,8)0x1) called from line 1873 of file >>xfs_vnodeops.c >> Return address = 0x01ef8ba >>File system sd (8,8): I/O error detected. > > ^^^^^^^^^ > I'm not an expert for those error messages but I guess it unfortunately a > hardware error, isn't it? Did you check dmesg output when this happened? That was the dmesg output - not much goes to logs, as they're on /var, which was the affected filesystem. Things I've seen suggest that this error can certainly be caused by a hardware problem, but the disk is a hardware RAID5 array on an ICP controller, which maintains it's own hardware log of disk problems. I've seen no sign of any problems with the array, and the controller doesn't show anything that could have presented an error to the OS layer, so I'm inclined to doubt the "hardware error" theory at the moment. Mike. From owner-linux-xfs@oss.sgi.com Wed Dec 10 02:44:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 02:44:52 -0800 (PST) Received: from castor.acu.ac.uk (castor.acu.ac.uk [194.81.120.81]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAAiVTa022456 for ; Wed, 10 Dec 2003 02:44:31 -0800 Received: from acu.ac.uk (arcturus.acu.ac.uk [194.81.120.110]) by castor.acu.ac.uk (8.12.10/8.12.10) with ESMTP id hBAAiMU4015418; Wed, 10 Dec 2003 10:44:23 GMT Message-ID: <3FD6F906.9070603@acu.ac.uk> Date: Wed, 10 Dec 2003 10:44:22 +0000 From: Mike Brodbelt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Rainer Traut CC: linux-xfs@oss.sgi.com Subject: Re: XFS filesystem shutdown References: <3FD5ED83.7000500@acu.ac.uk> <1432.10.1.200.117.1071040970.squirrel@imap01.ch.sauter-bc.com> <3FD6F55A.2060707@acu.ac.uk> <3FD6F719.7090009@epost.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version devel-20031209', clamav-milter version '0.65i' X-archive-position: 1326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: m.brodbelt@acu.ac.uk Precedence: bulk X-list: linux-xfs Content-Length: 1509 Lines: 38 Rainer Traut wrote: > Hi, > > Mike Brodbelt wrote: > > >>>I'm not an expert for those error messages but I guess it unfortunately a >>>hardware error, isn't it? Did you check dmesg output when this happened? >> >> >>That was the dmesg output - not much goes to logs, as they're on /var, >>which was the affected filesystem. Things I've seen suggest that this >>error can certainly be caused by a hardware problem, but the disk is a >>hardware RAID5 array on an ICP controller, which maintains it's own >>hardware log of disk problems. I've seen no sign of any problems with >>the array, and the controller doesn't show anything that could have >>presented an error to the OS layer, so I'm inclined to doubt the >>"hardware error" theory at the moment. > > > ICP has a nice tool for managing their Controllers from commandline. > icpcon it is called, there are some monitoring options like > View Statistics > View Events > View Hard Disk Info > > These are all empty and nothing unusual to find in there? There are a couple of retries on one of the disks, but nothing that I think should have "show through" to the OS. I suppose I can't discount the possibility entirely, as the error came up about 4 days after we relocated the server in question, due to a leaking roof..... It's conceivable that a SCSI cable could have come loose in the move or something, but if that had been the case, I'd expect to have seen the controller actually log an event, and there is nothing like that available. Mike. From owner-linux-xfs@oss.sgi.com Wed Dec 10 04:12:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 04:12:57 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBACCaTa024599 for ; Wed, 10 Dec 2003 04:12:36 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBACCaSH024598 for linux-xfs@oss.sgi.com; Wed, 10 Dec 2003 04:12:36 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBACCXTc024584 for ; Wed, 10 Dec 2003 04:12:33 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBABgIij023720; Wed, 10 Dec 2003 03:42:18 -0800 Date: Wed, 10 Dec 2003 03:42:18 -0800 Message-Id: <200312101142.hBABgIij023720@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 202] XFS data corruption (very old bug!!!) X-Bugzilla-Reason: AssignedTo X-archive-position: 1327 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 452 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=202 ------- Additional Comments From eumaster@mail.ru 2003-10-12 03:42 PDT ------- Today I got it on 2.4.20-20.9.XFS1.3.1 >And that's not really a bug. I never see this pronlem on ext3 & reiserfs. And I had this problem first time on our main servers (Irix, Challenge L) ;-))) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 10 05:42:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 05:42:36 -0800 (PST) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBADgHTa028925 for ; Wed, 10 Dec 2003 05:42:17 -0800 Received: (qmail 26212 invoked from network); 10 Dec 2003 13:42:16 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay01.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 10 Dec 2003 13:42:16 -0000 Message-ID: <3FD722BC.1000205@xfs.org> Date: Wed, 10 Dec 2003 07:42:20 -0600 From: Steve Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mihai RUSU CC: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: kernel BUG at fs/xfs/support/debug.c:106! References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1328 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1080 Lines: 35 Mihai RUSU wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi > >Another problem now, on another system. This one is a 2xP3 1.1 Ghz, 3 GB >RAM, MB Intel SCB2, Adaptec 7899 Controller onboard having one 18 GB SCSI >disk connected to it (for XFS external journal, swap and / partition which >is on ext3), Mylex 170 RAID connected to external storage enclosure with 3 >x 70 GB SCSI RAID5. The kernel error message is: > > > Mihai, You missed one thing out of your report, the console message xfs output before this. I suspect it would have been this: xfs_iget_core: ambiguous vns: vp/0x ..... but it would be good to confirm it. This was supposed to be a dead code path which there was no longer a route to, it is possible something in the NFS interface in 2.6 has changed to cause this though. Basically a race between two threads looking up the same inode, xfs has it cached already and two threads raced to setup the mapping from the linux inode. The use of iget_locked when looking up new inodes is supposed to protect against just this condition. Steve From owner-linux-xfs@oss.sgi.com Wed Dec 10 05:56:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 05:56:38 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBADuBTa029573 for ; Wed, 10 Dec 2003 05:56:12 -0800 Received: (qmail 17213 invoked by uid 1000); 10 Dec 2003 15:56:34 +0200 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Dec 2003 15:56:34 +0200 Date: Wed, 10 Dec 2003 15:56:32 +0200 (EET) From: Mihai RUSU X-X-Sender: dizzy@ahriman.bucharest.roedu.net To: Steve Lord cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: kernel BUG at fs/xfs/support/debug.c:106! In-Reply-To: <3FD722BC.1000205@xfs.org> Message-ID: References: <3FD722BC.1000205@xfs.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1329 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 814 Lines: 32 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi On Wed, 10 Dec 2003, Steve Lord wrote: > Mihai, > > You missed one thing out of your report, the console message xfs output > before this. Yes you are right, I have saved it and sent it to ksymoops but it seems it ignored it when I fetched ksymoops output. Here its the message before that error xfs_iget_core: ambiguous vns: vp/0xe5a2a640, invp/0xef6d1220 > Steve - -- Mihai RUSU Email: dizzy@roedu.net GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net "Linux is obsolete" -- AST -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/1yYSPZzOzrZY/1QRAoFZAJ9S8opBLWRVOPUbSFdHbyWIntfwDQCgxZk0 0+1DFcnfsGimM2a8LcqHM8E= =p4X7 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Dec 10 06:11:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 06:11:13 -0800 (PST) Received: from mx2.ngi.de (mx2.ngi.de [213.191.74.84]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAEB0Ta030179 for ; Wed, 10 Dec 2003 06:11:01 -0800 Received: (qmail 13067 invoked from network); 10 Dec 2003 13:47:20 -0000 Received: from unknown (HELO ente.berdmann.de) ([212.202.54.141]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 10 Dec 2003 13:47:20 -0000 Received: from octane.berdmann.de ([192.168.1.14] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1AU53H-0001lH-00 for linux-xfs@oss.sgi.com; Wed, 10 Dec 2003 15:10:56 +0100 Message-ID: <3FD7296D.8020008@berdmann.de> Date: Wed, 10 Dec 2003 15:10:53 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP30; en-US; rv:1.4) Gecko/20030711 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: building kernel-source RPM Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1330 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 96 Lines: 5 Hi, how do I rebuild a kernel-source RPM, e.g. kernel-source-2.4.19-SGI_XFS_1.2.0.i386.rpm ? From owner-linux-xfs@oss.sgi.com Wed Dec 10 06:59:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 06:59:24 -0800 (PST) Received: from mail.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAEx1Ta031521 for ; Wed, 10 Dec 2003 06:59:02 -0800 Received: from lapprose.ii.uib.no ([129.177.20.37]) by mail.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.12) id 1AU5ni-00032C-00; Wed, 10 Dec 2003 15:58:54 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.8/8.12.8/Submit) id hBAEwrl0022748; Wed, 10 Dec 2003 15:58:53 +0100 Date: Wed, 10 Dec 2003 15:58:53 +0100 From: Jan-Frode Myklebust To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: building kernel-source RPM Message-ID: <20031210145853.GA22720@ii.uib.no> References: <3FD7296D.8020008@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FD7296D.8020008@berdmann.de> X-Spam-Score: 0.0 (/) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1AU5ni-00032C-00*cu8MW/1ov2M* X-archive-position: 1331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.uib.no Precedence: bulk X-list: linux-xfs Content-Length: 478 Lines: 17 On Wed, Dec 10, 2003 at 03:10:53PM +0100, Bernhard Erdmann wrote: > > how do I rebuild a kernel-source RPM, e.g. > kernel-source-2.4.19-SGI_XFS_1.2.0.i386.rpm ? > That's not the source RPM, but rather the kernel source. A source RPM will be named kernel*.src.rpm and can be built with 'rpmbuild --rebuild kernel*.src.rpm'. BTW: please check out ftp://ftp.ii.uib.no/pub/janfrode/XFS/README if you want to build a kernel RPM with the latest do_brk() security fix. -jf From owner-linux-xfs@oss.sgi.com Wed Dec 10 07:04:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 07:04:20 -0800 (PST) Received: from mail.tzv.fal.de (dcs.tzv.fal.de [192.108.34.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAF47Ta032036 for ; Wed, 10 Dec 2003 07:04:08 -0800 Received: by mail.tzv.fal.de (Postfix, from userid 1001) id 3DB43234184; Wed, 10 Dec 2003 16:04:05 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tzv.fal.de (Postfix) with ESMTP id E201E234141; Wed, 10 Dec 2003 16:04:02 +0100 (CET) Received: from ots-4.tzv.local (ots-4.tzv.local [10.1.0.17]) by mail.tzv.fal.de (Postfix) with ESMTP id 68ED523411B; Wed, 10 Dec 2003 16:03:57 +0100 (CET) From: Monika Strack Reply-To: strack@tzv.fal.de To: debian-user@lists.debian.org Subject: Re: XFS , QLA2200 and SMP Date: Wed, 10 Dec 2003 16:03:57 +0100 User-Agent: KMail/1.5.3 References: <200312101602.26027.most@tzv.fal.de> In-Reply-To: <200312101602.26027.most@tzv.fal.de> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312101603.57046.most@tzv.fal.de> X-Virus-Scanned: by AMaViS snapshot-20020222 X-archive-position: 1332 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: most@tzv.fal.de Precedence: bulk X-list: linux-xfs Content-Length: 6737 Lines: 167 Am Mittwoch, 10. Dezember 2003 16:02 schrieb Monika Strack: > Am Dienstag, 9. Dezember 2003 16:36 schrieben Sie: > > On Tue, 9 Dec 2003, Monika Strack wrote: > > > Hallo, > > > > > > I need some help to make our fileserver working with fibre chanel raid. > > > > > > Always I get "Unable to handle kernel Null pointer dereference" or > > > "unable to handle kernel paging request" > > > > You'll need to start by sending more information, please run > > the oops through ksymoops so we can have some idea of what went > > wrong. > > > > -Eric > > I send output of 2 different kernel only. I made more kernel and any > crashes. > > Monika > > 3.12.03 2.4.20-xfs-xfs-fc-1 > > ksymoops 2.4.5 on i686 2.4.22-ext3-fc-1. Options used > -V (specified) > -k 20031203084512.ksyms (specified) > -l 20031203084512.modules (specified) > -o /lib/modules/2.4.22-ext3-fc-1/ (default) > -m /boot/System.map-2.4.20-xfs-xfs-fc-1 (specified) > > Unable to handle kernel Null pointer dereference > EIP: 0010: [] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010246 > eax: 00000025 ebx: e1b6d45c ecx: c039ce80 edx: 00000025 > esi: 00a43000 edi: 00000000 ebp: c1204f50 esp: f38c5e98 > ds: 0018 es: 0018 ss: 0018 > Stack: c02bc9a0 0000004a c013bf2f 0000004a c1204f50 0806aaf0 cac52000 > 00000000 c012b89a f6e2fb84 c1204f50 00000000 00001000 00000000 00a41200 > 00000000 d31dbcac 00001000 00000000 00001000 00000000 00000e00 00a42000 > 00000000 [] generic_commit_write+0x5d/0x94 [kernel] > [] generic_file_write_nolock+0x4d2/0x748 [kernel] > [] xfs_write_+0x3c3/0x6b8 [kernel] > [] linvfs_write+0xaa/0xe0 [kernel] > [] sys_write+0x8f/0x100 [kernel] > [] system_CALL+0X33/0X38 [kernel] > Code: 0f 0b 8d 00 c6 c9 2b c0 eb fe 8d 74 26 00 8d bc 27 00 00 00 > > >>EIP; c011695b <__out_of_line_bug+f/24> <===== > >> > >>ebx; e1b6d45c <_end+216f69fc/3848e5a0> > >>ecx; c039ce80 > >>esi; 00a43000 Before first symbol > >>ebp; c1204f50 <_end+d8e4f0/3848e5a0> > >>esp; f38c5e98 <_end+3344f438/3848e5a0> > > Code; c011695b <__out_of_line_bug+f/24> > 00000000 <_EIP>: > Code; c011695b <__out_of_line_bug+f/24> <===== > 0: 0f 0b ud2a <===== > Code; c011695d <__out_of_line_bug+11/24> > 2: 8d 00 lea (%eax),%eax > Code; c011695f <__out_of_line_bug+13/24> > 4: c6 c9 2b mov $0x2b,%cl > Code; c0116962 <__out_of_line_bug+16/24> > 7: c0 eb fe shr $0xfe,%bl > Code; c0116965 <__out_of_line_bug+19/24> > a: 8d 74 26 00 lea 0x0(%esi,1),%esi > Code; c0116969 <__out_of_line_bug+1d/24> > e: 8d bc 27 00 00 00 00 lea 0x0(%edi,1),%edi > > Oops: 0002 > > ---- > > 10.12.03 > > ksymoops 2.4.5 on i686 2.4.20-xfs-xfs-fc-4. Options used > -V (default) > -k 20031210132105.ksyms (specified) > -l /proc/modules (default) > -o /lib/modules/2.4.20-xfs-xfs-fc-4/ (default) > -m /boot/System.map-2.4.20-xfs-xfs-fc-4 (default) > > unable to handle kernel NULL pointer derefernce at virtual address 000000e1 > c027d5d0 > Oops: 0000 > CPU: 1 > EIP: 0010 [<0027d5d0>] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010202 > eax: 00000001 ebx: f7acf58c ecx: f72b811c edx: f7acf5fc > esi: f73a5600 edi: da066000 ebp: 00000000 esp: da067b9c > ds: 0018 es: 0018 ss: 0018 > process tar ( pid: 1246, stackpage=da067000) > Stack: f72b811c c0275f92 f72b811c f7acf58c c3f4f8e4 f72b811c da066000 > e2bc817c c0286d25 f72b811c 00000000 e2bc817c f72b811c c0287989 f72b811c > 00000040 00000000 00004040 0232010a f753a3a0 00000000 c02a3286 f753a3a0 > e02a2ee0 [] dev_queue_xmit+0xb2/0x370 [] > [] ip_output+0xd5/0x140 [] > [] ip_buid_xmit+0x1c9/0x390 [] > [] udp_sendmsg+0x286/0x470 [] > [] udp_getfrag+0x0/0x0 [] > [] FillRxRing+0x27/0x40 [sk98lin] > [] inet_sendmsg+0x23/0x40 [] > [] sock_sendmsg+0x67/0x90 [] > [] do_xprt_transmit+0x105/0x500 [sunrpc] > [] skb_release_data+0x72/0x80 [] > [] __kfree_skb+0xdd/0xe0 [] > [] skb_release_data+0x72/0x80 [] > [] kfree_skbmem+0xc/0x70 [] > [] __xprt_lock_write+0x9a/0xb0 [sunrpc] > [] xrpt_transmit+0x115/0x170 [sunrpc] > [] call_transmit+0x3f/0x70 [sunrpc] > [] __rpc_execute+0xa6/0x310 [sunrpc] > [] nfs_read_rpcsetup+0xbc/0x120 [nfs] > [] rpc_execute+0x65/0x70 [sunrpc] > [] nfs_pagein_one+0x11a/0x180 [nfs] > [] nfs_pagein_list+0x86/0xa0 [nfs] > [] nfs_pagein_inode+067/+080 [nfs] > [] nfs_readpage_async+0xea/0x100 [nfs] > [] nfs_readpage+08c/0xa0 [nfs] > [] page_cache_read+0xbc/0xd0 [] > [] generic_file_readhead+0xb1/0x150 [] > [] do_generic_file_read+0xf2/0x110 [] > [] file_read_actor+0x0/100 []f898ce62 > nfs_file_read+0x82/0xb0 [nfs] > [] sys_read+0xf4(0x120 [] > [] system_call+0x33/038 [] > code: 8b 80 e0 00 00 00 39 42 08 77 1a 89 51 08 8b 42 04 ff 42 08 > > >>EIP; 0027d5d0 Before first symbol <===== > >> > >>ebx; f7acf58c <_end+37655b6c/3848b5e0> > >>ecx; f72b811c <_end+36e3e6fc/3848b5e0> > >>edx; f7acf5fc <_end+37655bdc/3848b5e0> > >>esi; f73a5600 <_end+36f2bbe0/3848b5e0> > >>edi; da066000 <_end+19bec5e0/3848b5e0> > >>esp; da067b9c <_end+19bee17c/3848b5e0> > > Code; 0027d5d0 Before first symbol > 00000000 <_EIP>: > Code; 0027d5d0 Before first symbol <===== > 0: 8b 80 e0 00 00 00 mov 0xe0(%eax),%eax <===== > Code; 0027d5d6 Before first symbol > 6: 39 42 08 cmp %eax,0x8(%edx) > Code; 0027d5d9 Before first symbol > 9: 77 1a ja 25 <_EIP+0x25> 0027d5f5 Before > first symbol > Code; 0027d5db Before first symbol > b: 89 51 08 mov %edx,0x8(%ecx) > Code; 0027d5de Before first symbol > e: 8b 42 04 mov 0x4(%edx),%eax > Code; 0027d5e1 Before first symbol > 11: ff 42 08 incl 0x8(%edx) -- ________________________________________________________________________________ Monika Strack Institut fuer Tierzucht Bundesforschungsanstalt fuer Landwirschaft 31535 Neustadt e-mail: most@tzv.fal.de Germany Tel: +49 5034 /871 154 Fax: +49 5034 /871 239 _______________________________________________________________________________ From owner-linux-xfs@oss.sgi.com Wed Dec 10 07:11:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 07:12:13 -0800 (PST) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAFBjTa032571 for ; Wed, 10 Dec 2003 07:11:45 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id hBAFEd3o013613; Wed, 10 Dec 2003 10:14:39 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id hBAFEdGj013610; Wed, 10 Dec 2003 10:14:39 -0500 Date: Wed, 10 Dec 2003 10:14:39 -0500 (EST) From: Net Llama! To: Bernhard Erdmann cc: linux-xfs@oss.sgi.com Subject: Re: building kernel-source RPM In-Reply-To: <3FD7296D.8020008@berdmann.de> Message-ID: References: <3FD7296D.8020008@berdmann.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 897 Lines: 25 On Wed, 10 Dec 2003, Bernhard Erdmann wrote: > Hi, > > how do I rebuild a kernel-source RPM, e.g. > kernel-source-2.4.19-SGI_XFS_1.2.0.i386.rpm ? I think what you want is the SRPM, if you're looking to rebuild. Although i suppose you could build from the source in that RPM. At any rate, assuming that you've installed that RPM, and it contains a SPEC file, you should be able to do: rpm -bb /usr/src/redhat/SPEC/kernel.spec and after a while, you'll end up with RPMs(s) & and SRPM. The faster, easier route would be to get the SRPM, and do: rpmbuild --rebuild kernel-source-2.4.19-SGI_XFS_1.2.0.src.rpm Either way, 2.4.19 is old, buggy, and exploitable, so i'd avoid it and go with something much more recent. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Wed Dec 10 07:30:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 07:30:52 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAFUcTa000755 for ; Wed, 10 Dec 2003 07:30:39 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hBAFUZhl001516; Wed, 10 Dec 2003 16:30:36 +0100 Message-ID: <3FD73CD6.3070002@stesmi.com> Date: Wed, 10 Dec 2003 16:33:42 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jan-Frode Myklebust CC: linux-xfs@oss.sgi.com Subject: Re: building kernel-source RPM References: <3FD7296D.8020008@berdmann.de> <20031210145853.GA22720@ii.uib.no> In-Reply-To: <20031210145853.GA22720@ii.uib.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 879 Lines: 30 Jan-Frode Myklebust wrote: > On Wed, Dec 10, 2003 at 03:10:53PM +0100, Bernhard Erdmann wrote: > >>how do I rebuild a kernel-source RPM, e.g. >>kernel-source-2.4.19-SGI_XFS_1.2.0.i386.rpm ? >> > > > That's not the source RPM, but rather the kernel source. A > source RPM will be named kernel*.src.rpm and can be built > with 'rpmbuild --rebuild kernel*.src.rpm'. > > BTW: please check out ftp://ftp.ii.uib.no/pub/janfrode/XFS/README > if you want to build a kernel RPM with the latest do_brk() > security fix. > > > -jf > add --arch="i386,i586,i686,athlon" to the list also, ie rpmbuild --rebuild --arch="i386,i586,i686,athlon" kernel*.src.rpm Otherwise I believe only the i386 kernel is built and most actually don't use that one. But everybody else are correct - don't use that one, it's old. 1.3.1 is out AND there is exploitable holes in that one. // Stefan From owner-linux-xfs@oss.sgi.com Wed Dec 10 07:40:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 07:40:49 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAFeZTa001264 for ; Wed, 10 Dec 2003 07:40:36 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBAGvem7003380 for ; Wed, 10 Dec 2003 10:57:40 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBAFeTP519113549; Wed, 10 Dec 2003 09:40:29 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBAFeLK29796244; Wed, 10 Dec 2003 09:40:21 -0600 (CST) Date: Wed, 10 Dec 2003 09:40:29 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Bernhard Erdmann cc: linux-xfs@oss.sgi.com Subject: Re: building kernel-source RPM In-Reply-To: <3FD7296D.8020008@berdmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 473 Lines: 21 if you want to just build a kernel, install the kernel-source RPM, cd /usr/src/linux/* and build as you would any kernel. if you want to rebuild a kernel -rpm- (i.e. ahve an rpm package when you're done) get the kernel-2.4.19-*.src.rpm and do: rpmbuild --ba --target=i686 kernel-2.4.19.*.src.rpm and wait. -Eric On Wed, 10 Dec 2003, Bernhard Erdmann wrote: > Hi, > > how do I rebuild a kernel-source RPM, e.g. > kernel-source-2.4.19-SGI_XFS_1.2.0.i386.rpm ? > > From owner-linux-xfs@oss.sgi.com Wed Dec 10 08:18:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 08:18:17 -0800 (PST) Received: from mail.mnsu.edu ([134.29.1.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAGI5Ta002484 for ; Wed, 10 Dec 2003 08:18:06 -0800 Received: from mnsu.edu (j3gum-3.ITS.MNSU.EDU [134.29.32.1]) by mail.mnsu.edu (8.12.10/8.12.10) with ESMTP id hBAGHqJY010545 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 10 Dec 2003 10:17:52 -0600 Message-ID: <3FD74730.9070602@mnsu.edu> Date: Wed, 10 Dec 2003 10:17:52 -0600 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Brodbelt CC: linux-xfs@oss.sgi.com Subject: Re: XFS filesystem shutdown References: <3FD5ED83.7000500@acu.ac.uk> <1432.10.1.200.117.1071040970.squirrel@imap01.ch.sauter-bc.com> <3FD6F55A.2060707@acu.ac.uk> <3FD6F719.7090009@epost.de> <3FD6F906.9070603@acu.ac.uk> In-Reply-To: <3FD6F906.9070603@acu.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1336 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: linux-xfs Content-Length: 2394 Lines: 63 What enclosures are you using for your drives? We had a ICP vortex card with CI-design enclosures we bought that we're supposed to be ultra-160. As it tuns out when we opened the CI-design enclosures they didn't meet any of the ultra-160 design goals. ...We threw out the enclosures and the ICP vortex card works fine. ...We only had problems with the enclosure setup when a drive had a little problems -- soft retries for example, then it threw the whole scsi channel into disarray. Many disks LOOKED as if it had a problem, it of course nuked the raid-5 array. ...If you checked each drive individually each drive succeeded (including the original failed disk.) ...and I could run bonnie++ on it for weeks. ...but several days into a production run it would fail. Mike Brodbelt wrote: >Rainer Traut wrote: > > >>Hi, >> >>Mike Brodbelt wrote: >> >> >> >> >>>>I'm not an expert for those error messages but I guess it unfortunately a >>>>hardware error, isn't it? Did you check dmesg output when this happened? >>>> >>>> >>>That was the dmesg output - not much goes to logs, as they're on /var, >>>which was the affected filesystem. Things I've seen suggest that this >>>error can certainly be caused by a hardware problem, but the disk is a >>>hardware RAID5 array on an ICP controller, which maintains it's own >>>hardware log of disk problems. I've seen no sign of any problems with >>>the array, and the controller doesn't show anything that could have >>>presented an error to the OS layer, so I'm inclined to doubt the >>>"hardware error" theory at the moment. >>> >>> >>ICP has a nice tool for managing their Controllers from commandline. >>icpcon it is called, there are some monitoring options like >>View Statistics >>View Events >>View Hard Disk Info >> >>These are all empty and nothing unusual to find in there? >> >> > >There are a couple of retries on one of the disks, but nothing that I >think should have "show through" to the OS. I suppose I can't discount >the possibility entirely, as the error came up about 4 days after we >relocated the server in question, due to a leaking roof..... It's >conceivable that a SCSI cable could have come loose in the move or >something, but if that had been the case, I'd expect to have seen the >controller actually log an event, and there is nothing like that available. > >Mike. > > > > From owner-linux-xfs@oss.sgi.com Wed Dec 10 08:33:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 08:33:12 -0800 (PST) Received: from mx2.ngi.de (mx2.ngi.de [213.191.74.84]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAGWxTa005882 for ; Wed, 10 Dec 2003 08:33:00 -0800 Received: (qmail 25159 invoked from network); 10 Dec 2003 16:09:20 -0000 Received: from unknown (HELO ente.berdmann.de) ([212.202.54.141]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 10 Dec 2003 16:09:20 -0000 Received: from octane.berdmann.de ([192.168.1.14] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1AU7Gk-00026M-00; Wed, 10 Dec 2003 17:32:58 +0100 Message-ID: <3FD74AB8.6060601@berdmann.de> Date: Wed, 10 Dec 2003 17:32:56 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP30; en-US; rv:1.4) Gecko/20030711 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: building kernel-source RPM References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1337 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 239 Lines: 12 Eric Sandeen wrote: > if you want to just build a kernel, install the kernel-source > RPM, cd /usr/src/linux/* and build as you would any kernel. Hi Eric, how do I recreate kernel-source-2.4.19-SGI_XFS_1.2.0.i386.rpm ? Regards Bernie From owner-linux-xfs@oss.sgi.com Wed Dec 10 08:33:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 08:34:00 -0800 (PST) Received: from castor.acu.ac.uk (castor.acu.ac.uk [194.81.120.81]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAGXlTa005946 for ; Wed, 10 Dec 2003 08:33:48 -0800 Received: from acu.ac.uk (arcturus.acu.ac.uk [194.81.120.110]) by castor.acu.ac.uk (8.12.10/8.12.10) with ESMTP id hBAGXcGD007337; Wed, 10 Dec 2003 16:33:39 GMT Message-ID: <3FD74AE2.2010600@acu.ac.uk> Date: Wed, 10 Dec 2003 16:33:38 +0000 From: Mike Brodbelt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: "Jeffrey E. Hundstad" CC: linux-xfs@oss.sgi.com Subject: Re: XFS filesystem shutdown References: <3FD5ED83.7000500@acu.ac.uk> <1432.10.1.200.117.1071040970.squirrel@imap01.ch.sauter-bc.com> <3FD6F55A.2060707@acu.ac.uk> <3FD6F719.7090009@epost.de> <3FD6F906.9070603@acu.ac.uk> <3FD74730.9070602@mnsu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version devel-20031209', clamav-milter version '0.65i' X-archive-position: 1338 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: m.brodbelt@acu.ac.uk Precedence: bulk X-list: linux-xfs Content-Length: 1672 Lines: 32 Jeffrey E. Hundstad wrote: > What enclosures are you using for your drives? We had a ICP vortex card > with CI-design enclosures we bought that we're supposed to be > ultra-160. I have had enclosure problems on that machine in the past. I have U160 drives, but I've got the sync rate set down to 80, as I was getting an unacceptably high level of retries, and I had disks reported as failed when they were fine. Operating at 80MB, they seem to be OK, though I have seen some retries. I have been operating on the assumption (as there's nothing in the controller's event log) that the host OS would see only good data from the controller even where a disk retry occurs. > As it tuns out when we opened the CI-design enclosures they > didn't meet any of the ultra-160 design goals. ...We threw out the > enclosures and the ICP vortex card works fine. ...We only had problems > with the enclosure setup when a drive had a little problems -- soft > retries for example, then it threw the whole scsi channel into > disarray. Many disks LOOKED as if it had a problem, it of course nuked > the raid-5 array. ...If you checked each drive individually each drive > succeeded (including the original failed disk.) ...and I could run > bonnie++ on it for weeks. ...but several days into a production run it > would fail. I have a second machine, also running an ICP controller and XFS, but with ICY DOCK caddies. These operate perfectly with SCA disks at U160. This machine has never reported any XFS errors, so I suppose it may be worth my while purchasing new caddies and swapping them out. Unreliable SCSI chains are certainly not much fun at all.... Mike. From owner-linux-xfs@oss.sgi.com Wed Dec 10 08:37:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 08:37:39 -0800 (PST) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAGbRTa007097 for ; Wed, 10 Dec 2003 08:37:28 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id hBAGeO3o018762; Wed, 10 Dec 2003 11:40:24 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id hBAGeNpA018759; Wed, 10 Dec 2003 11:40:23 -0500 Date: Wed, 10 Dec 2003 11:40:23 -0500 (EST) From: Net Llama! To: Bernhard Erdmann cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: building kernel-source RPM In-Reply-To: <3FD74AB8.6060601@berdmann.de> Message-ID: References: <3FD74AB8.6060601@berdmann.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1339 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 526 Lines: 18 On Wed, 10 Dec 2003, Bernhard Erdmann wrote: > Eric Sandeen wrote: > > if you want to just build a kernel, install the kernel-source > > RPM, cd /usr/src/linux/* and build as you would any kernel. > > > Hi Eric, > > how do I recreate kernel-source-2.4.19-SGI_XFS_1.2.0.i386.rpm ? 0) download from kernel.org. 1) apply XFS patch from oss.sgi.com -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Wed Dec 10 08:46:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 08:46:13 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAGk1Ta007576 for ; Wed, 10 Dec 2003 08:46:01 -0800 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.8/8.12.8) with ESMTP id hBAGjqil008650; Wed, 10 Dec 2003 11:45:52 -0500 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.8/8.12.8/Submit) with ESMTP id hBAGjqun008646; Wed, 10 Dec 2003 11:45:52 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Wed, 10 Dec 2003 11:45:52 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Bernhard Erdmann cc: Linux xfs mailing list Subject: Re: building kernel-source RPM In-Reply-To: <3FD74AB8.6060601@berdmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1340 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs Content-Length: 409 Lines: 15 On Wed, 10 Dec 2003 at 5:32pm, Bernhard Erdmann wrote > Eric Sandeen wrote: > > if you want to just build a kernel, install the kernel-source > > RPM, cd /usr/src/linux/* and build as you would any kernel. > > how do I recreate kernel-source-2.4.19-SGI_XFS_1.2.0.i386.rpm ? It will get created when you build from the src.rpm. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Wed Dec 10 08:47:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 08:47:18 -0800 (PST) Received: from mx2.ngi.de (mx2.ngi.de [213.191.74.84]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAGl5Ta007754 for ; Wed, 10 Dec 2003 08:47:06 -0800 Received: (qmail 5407 invoked from network); 10 Dec 2003 16:23:24 -0000 Received: from unknown (HELO ente.berdmann.de) ([212.202.54.141]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 10 Dec 2003 16:23:24 -0000 Received: from octane.berdmann.de ([192.168.1.14] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1AU7UM-00028S-00; Wed, 10 Dec 2003 17:47:02 +0100 Message-ID: <3FD74E03.4090203@berdmann.de> Date: Wed, 10 Dec 2003 17:46:59 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP30; en-US; rv:1.4) Gecko/20030711 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: "Net Llama!" CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: building kernel-source RPM References: <3FD74AB8.6060601@berdmann.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1341 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 334 Lines: 18 Net Llama! wrote: [...] >>how do I recreate kernel-source-2.4.19-SGI_XFS_1.2.0.i386.rpm ? > > > 0) download from kernel.org. > 1) apply XFS patch from oss.sgi.com Hi, I'd like to recreate the file kernel-source-2.4.19-SGI_XFS_1.2.0.i386.rpm. What is the way to get it from kernel-2.4.19-SGI_XFS_1.2.0.src.rpm? Regards, Bernie From owner-linux-xfs@oss.sgi.com Wed Dec 10 08:49:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 08:49:40 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAGnSTa008418 for ; Wed, 10 Dec 2003 08:49:29 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hBAGnChl002535; Wed, 10 Dec 2003 17:49:13 +0100 Message-ID: <3FD74F43.5040001@stesmi.com> Date: Wed, 10 Dec 2003 17:52:19 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernhard Erdmann CC: "Net Llama!" , Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: building kernel-source RPM References: <3FD74AB8.6060601@berdmann.de> <3FD74E03.4090203@berdmann.de> In-Reply-To: <3FD74E03.4090203@berdmann.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1342 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 476 Lines: 30 Bernhard Erdmann wrote: > Net Llama! wrote: > [...] > >>> how do I recreate kernel-source-2.4.19-SGI_XFS_1.2.0.i386.rpm ? >> >> >> >> 0) download from kernel.org. >> 1) apply XFS patch from oss.sgi.com > > > > Hi, > > I'd like to recreate the file kernel-source-2.4.19-SGI_XFS_1.2.0.i386.rpm. > > What is the way to get it from kernel-2.4.19-SGI_XFS_1.2.0.src.rpm? > > Regards, > Bernie > rpmbuild -bs kernel-...src.rpm -bs == build source package only // Stefan From owner-linux-xfs@oss.sgi.com Wed Dec 10 09:12:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 09:13:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBAHCdTa009244 for ; Wed, 10 Dec 2003 09:12:39 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBAHCcZw009242 for linux-xfs@oss.sgi.com; Wed, 10 Dec 2003 09:12:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBAHCXTs009204 for ; Wed, 10 Dec 2003 09:12:35 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBAGR3Ln005805; Wed, 10 Dec 2003 08:27:03 -0800 Date: Wed, 10 Dec 2003 08:27:03 -0800 Message-Id: <200312101627.hBAGR3Ln005805@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1343 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1116 Lines: 32 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From tdickson@inostor.com 2003-10-12 08:27 PDT ------- That sounds like it may be usefull. When I say xfs_check dies I mean that it uses memory until there is none left, and then the oom killer kills it; resulting in this error message: Also, I know dir creation at the same time that tree is being run is similar to a fork-bomb, but I'm trying to recreate the scenario on a test machine. On the production machine, a simple "tree" or rsync command (anything that reads all of the inodes (or a large number) causes the memory to be used until the system is EFFECTIVLY crashed (it doesn't actually die, and comes back later, but it kills httpd/samba/atalk/etc in the process). Mihai suggestions look interesting; I'll try with the 2.4.23 kernel and see if removing the oom killer helps. To me, also, it looks as if a cache is too aggressive, given that the machine eventually let go of the xfs_inode memory. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 10 09:12:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 09:13:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBAHCdTa009243 for ; Wed, 10 Dec 2003 09:12:39 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBAHCcai009241 for linux-xfs@oss.sgi.com; Wed, 10 Dec 2003 09:12:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBAHCXTm009204 for ; Wed, 10 Dec 2003 09:12:35 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBAGYorT006601; Wed, 10 Dec 2003 08:34:50 -0800 Date: Wed, 10 Dec 2003 08:34:50 -0800 Message-Id: <200312101634.hBAGYorT006601@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1343 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 611 Lines: 26 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From tdickson@inostor.com 2003-10-12 08:34 PDT ------- Oops forgot to add the xfs_check error: bash-2.05a# xfs_check /dev/H80/v /usr/sbin/xfs_check: line 62: 1484 Terminated xfs_db$ISFILE -i -p xfs_check -c "check$OPTS" $1 dmesg says: Out of Memory: Killed process 1484 (xfs_db). Thank you! Any tests you want run, let me know. (Augh! Bugzilla made me add this to 211 by accident! Sorry) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 10 09:18:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 09:18:57 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAHIZTa010165 for ; Wed, 10 Dec 2003 09:18:36 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hBAHGog0002362; Wed, 10 Dec 2003 11:16:50 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hBAHGlNx002360; Wed, 10 Dec 2003 11:16:47 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS , QLA2200 and SMP From: Austin Gonyou To: strack@tzv.fal.de Cc: debian-user@lists.debian.org, XFS List In-Reply-To: <200312101603.57046.most@tzv.fal.de> References: <200312101603.57046.most@tzv.fal.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1071076607.2341.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 10 Dec 2003 11:16:47 -0600 X-archive-position: 1344 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 226 Lines: 9 Which FS is it that you're writing to? A NFS, or is it local and being shared as NFS? Something seems very odd in that stack trace given the oops that you have. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Dec 10 09:22:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 09:22:54 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAHMhTa010756 for ; Wed, 10 Dec 2003 09:22:43 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hBAHKwg0002398; Wed, 10 Dec 2003 11:20:58 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hBAHKq10002396; Wed, 10 Dec 2003 11:20:52 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: Fwd: XFS merged in 2.4 From: Austin Gonyou To: Ethan Benson Cc: XFS List In-Reply-To: <20031210101142.GF3294@plato.local.lan> References: <20031210101142.GF3294@plato.local.lan> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1071076851.2337.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 10 Dec 2003 11:20:52 -0600 X-archive-position: 1345 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 260 Lines: 8 ACLs are also available for even many virtual FS in 2.6 now, with many backports going to 2.4 for bugfixes, etc. Since ACLs are part of the XFS code-base, I'd imagine they'd come along. Christoph? -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Dec 10 09:39:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 09:39:36 -0800 (PST) Received: from mx2.ngi.de (mx2.ngi.de [213.191.74.84]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAHdLTa011536 for ; Wed, 10 Dec 2003 09:39:24 -0800 Received: (qmail 27267 invoked from network); 10 Dec 2003 17:15:42 -0000 Received: from unknown (HELO ente.berdmann.de) ([212.202.54.141]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 10 Dec 2003 17:15:42 -0000 Received: from octane.berdmann.de ([192.168.1.14] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1AU8Iy-0002EZ-00; Wed, 10 Dec 2003 18:39:20 +0100 Message-ID: <3FD75A45.3080201@berdmann.de> Date: Wed, 10 Dec 2003 18:39:17 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP30; en-US; rv:1.4) Gecko/20030711 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Joshua Baker-LePain CC: Linux xfs mailing list Subject: Re: building kernel-source RPM References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1346 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 149 Lines: 5 > It will get created when you build from the src.rpm. Thanks, "rpmbuild -bb /usr/src/redhat/SPECS/kernel-2.4.19-SGI_XFS_1.2.spec" did the trick. From owner-linux-xfs@oss.sgi.com Wed Dec 10 11:12:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 11:12:56 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBAJCaTa015391 for ; Wed, 10 Dec 2003 11:12:36 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBAJCabQ015390 for linux-xfs@oss.sgi.com; Wed, 10 Dec 2003 11:12:36 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBAJCYTe015374 for ; Wed, 10 Dec 2003 11:12:34 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBAIWVVH013625; Wed, 10 Dec 2003 10:32:31 -0800 Date: Wed, 10 Dec 2003 10:32:31 -0800 Message-Id: <200312101832.hBAIWVVH013625@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1347 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 530 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From tdickson@inostor.com 2003-10-12 10:32 PDT ------- Update: using current xfs patches agains 2.4.23 the same symptoms appear to happen (xfs_check dies with oom, xfs_inode swells until tree command dies with oom, etc). Will try with 2.4.24pre1, if reproducable will try to make the simplest case and submit report to lkml. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 10 12:44:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 12:45:01 -0800 (PST) Received: from hoby.coplanar.net (CPE0020afeeb1ac-CM014250013274.cpe.net.cable.rogers.com [24.114.21.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAKiaTa022253 for ; Wed, 10 Dec 2003 12:44:39 -0800 Received: from coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) (authenticated bits=0) by hoby.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBAKiOVc022996 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 10 Dec 2003 15:44:28 -0500 Message-ID: <3FD7853A.6020505@coplanar.net> Date: Wed, 10 Dec 2003 15:42:34 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Austin Gonyou CC: Ethan Benson , XFS List Subject: Re: Fwd: XFS merged in 2.4 References: <20031210101142.GF3294@plato.local.lan> <1071076851.2337.6.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1348 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 406 Lines: 14 Austin Gonyou wrote: > ACLs are also available for even many virtual FS in 2.6 now, with many > backports going to 2.4 for bugfixes, etc. Since ACLs are part of the XFS > code-base, I'd imagine they'd come along. Christoph? > As for dmapi - they probably want it at the VFS layer so other FS can implement it, rather than just tunneling through VFS with an ioctl to XFS specific API. Cheers, Jeremy From owner-linux-xfs@oss.sgi.com Wed Dec 10 12:52:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 12:53:07 -0800 (PST) Received: from hoby.coplanar.net (CPE0020afeeb1ac-CM014250013274.cpe.net.cable.rogers.com [24.114.21.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAKqqTa023033 for ; Wed, 10 Dec 2003 12:52:54 -0800 Received: from coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) (authenticated bits=0) by hoby.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBAKqnVc023046 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 10 Dec 2003 15:52:51 -0500 Message-ID: <3FD78734.8030401@coplanar.net> Date: Wed, 10 Dec 2003 15:51:00 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: kernel BUG on umount with XFS 1.3.1 Content-Type: multipart/mixed; boundary="------------040204080503060209000900" X-archive-position: 1349 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 3465 Lines: 106 This is a multi-part message in MIME format. --------------040204080503060209000900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I just got a kernel oops. vanilla 2.4.21, device-mapper (EVMS), XFS 1.3.1, packet-writing patch from 2.4.19. I just copied a 71GiB filesystem with: # xfsdump -J - /vol2 | xfsrestore -J - /data2 after completion a few seconds maybe a minute passed then: # umount /vol2 # umount /data2 The second umount segfaulted, and the bug (see ksymoops output in attachment) happened. Just before kernel BUG in syslog/console/dmesg: XFS assertion failed: mp->m_inodes == NULL, file: xfs_mount.c, line: 1091 Do I need to send any other info? Regards, Jeremy Jackson --------------040204080503060209000900 Content-Type: text/plain; name="ksymoops.out" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ksymoops.out" ksymoops 2.4.5 on i686 2.4.21-jerj1-k7-smp. Options used -v /data/build/packages/kernel-image-2.4-i386/build-k7-smp/vmlinux (specified) -k ksyms (specified) -l modules (specified) -o /lib/modules/2.4.21-jerj1-k7-smp/ (specified) -m /boot/System.map-2.4.21-jerj1-k7-smp (specified) -i cpu: 0, clocks: 2666750, slice: 1333375 SGI XFS 1.3.1 with ACLs, debug enabled e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex kernel BUG at debug.c:55! invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 0000004a ebx: ca2a8400 ecx: ffffffff edx: 00000001 esi: cabbe6c0 edi: ca186e00 ebp: 00000000 esp: c58b9ec8 ds: 0018 es: 0018 ss: 0018 Process umount (pid: 1106, stackpage=c58b9000) Stack: c037b7a0 c0377754 c037717f 00000443 c01fbaf3 c0377754 c037717f 00000443 00000000 ca2a8400 00000000 ca2a8400 c02052d9 ca2a8400 00000000 ca2a8400 ca2a8400 c03d85e0 c03d866c 00000001 00000000 cabbe6c0 c021be24 ca2a8400 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 37 00 ce b7 37 c0 83 c4 10 c3 8d 74 26 00 8d bc 27 00 >>EIP; c021cbb9 <===== >>ebx; ca2a8400 <_end+9de6624/10386224> >>ecx; ffffffff >>esi; cabbe6c0 <_end+a6fc8e4/10386224> >>edi; ca186e00 <_end+9cc5024/10386224> >>esp; c58b9ec8 <_end+53f80ec/10386224> Trace; c01fbaf3 Trace; c02052d9 Trace; c021be24 Trace; c021b372 Trace; c0141c36 Trace; c01540ee <__mntput+1e/30> Trace; c0146188 Trace; c015496f Trace; c012bd56 Trace; c015498c Trace; c0108ba3 Code; c021cbb9 00000000 <_EIP>: Code; c021cbb9 <===== 0: 0f 0b ud2a <===== Code; c021cbbb 2: 37 aaa Code; c021cbbc 3: 00 ce add %cl,%dh Code; c021cbbe 5: b7 37 mov $0x37,%bh Code; c021cbc0 7: c0 83 c4 10 c3 8d 74 rolb $0x74,0x8dc310c4(%ebx) Code; c021cbc7 e: 26 00 8d bc 27 00 00 add %cl,%es:0x27bc(%ebp) --------------040204080503060209000900-- From owner-linux-xfs@oss.sgi.com Wed Dec 10 13:13:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 13:14:13 -0800 (PST) Received: from mail.arkon-group.com (mail.arkon-group.com [207.34.136.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBALDgTa024882 for ; Wed, 10 Dec 2003 13:13:43 -0800 Received: from 2d052 (fw1.arkonnetworks.com [207.34.136.29]) by mail.arkon-group.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V5LMLCP6; Wed, 10 Dec 2003 13:10:08 -0800 Message-ID: <002401c3bf62$79d135c0$0716a8c0@hq.arkonnetworks.com> From: "Norman Zhang" To: Subject: Repair XFS Date: Wed, 10 Dec 2003 13:13:36 -0800 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1350 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Content-Length: 895 Lines: 26 Hi, I'm seeing some irregulars halts on one of my XFS volume (/srv). I can only use umount -l to dismount the volume or do a hot reboot. Dec 9 15:47:25 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) called from line 1039 of file xfs_trans.c. Return address = 0xe109f312 Dec 9 15:47:25 smbserver kernel: Corruption of in-memory data detected. Shutting down filesystem: md(9,5) Dec 9 15:47:25 smbserver kernel: Please umount the filesystem, and rectify the problem(s) I'm not sure if the disk has problems, but during boot up there's no error found by fsck. The stall sometime occurs in weeks and sometimes few times per day. So I really doubt if this a disk problem. Is there any way I can trace or perhaps fix this? BTW, if I want to manually force a disk check on the XFS volume. Do I just do $ umount -l srv $ fsck.xfs /srv I don't see any actions on the screen. Regards, Norman From owner-linux-xfs@oss.sgi.com Wed Dec 10 13:17:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 13:17:32 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBALHLTa025699 for ; Wed, 10 Dec 2003 13:17:21 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBAMYQm7009034 for ; Wed, 10 Dec 2003 16:34:26 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBALH9P519147263; Wed, 10 Dec 2003 15:17:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBALEtK19801185; Wed, 10 Dec 2003 15:15:57 -0600 (CST) Subject: Re: XFS filesystem shutdown From: Eric Sandeen To: Simon Matter Cc: Mike Brodbelt , linux-xfs@oss.sgi.com In-Reply-To: <1432.10.1.200.117.1071040970.squirrel@imap01.ch.sauter-bc.com> References: <3FD5ED83.7000500@acu.ac.uk> <1432.10.1.200.117.1071040970.squirrel@imap01.ch.sauter-bc.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1071090903.19271.83.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 10 Dec 2003 15:15:03 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1351 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 756 Lines: 19 On Wed, 2003-12-10 at 01:22, Simon Matter wrote: > > xfs_vnodeops.c > > Return address = 0x01ef8ba > > File system sd (8,8): I/O error detected. > ^^^^^^^^^ > I'm not an expert for those error messages but I guess it unfortunately a > hardware error, isn't it? Did you check dmesg output when this happened? I'm always happy to blame hardware, believe me. :) But error 22 is "EINVAL" on x86, so I suppose it's possible that xfs did something wrong like request a block off the end of the device, and the driver said "no, I can't do that - EINVAL," which xfs interpreted as an I/O error... -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Dec 10 13:19:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 13:19:47 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBALJZTa026479 for ; Wed, 10 Dec 2003 13:19:35 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBALJZeh026478 for linux-xfs@oss.sgi.com; Wed, 10 Dec 2003 13:19:35 -0800 Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBALJWTa026466 for ; Wed, 10 Dec 2003 13:19:33 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBAMacm7009928 for ; Wed, 10 Dec 2003 16:36:38 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBALJRP519194771; Wed, 10 Dec 2003 15:19:27 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBALIsK19836960; Wed, 10 Dec 2003 15:19:19 -0600 (CST) Subject: Re: [Bug 209] Kernel 2.4.20-xfs memory leaks From: Eric Sandeen To: tdickson@inostor.comB.sgi.com Cc: xfs-master@oss.sgi.com In-Reply-To: <200312101832.hBAIWVVH013625@oss.sgi.com> References: <200312101832.hBAIWVVH013625@oss.sgi.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1071091141.19271.85.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 10 Dec 2003 15:19:01 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1352 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 425 Lines: 15 On Wed, 2003-12-10 at 12:32, bugzilla-daemon@oss.sgi.com wrote: > Will try with 2.4.24pre1, if reproducable will try to make the simplest case and > submit report to lkml. Eh, no need to report it to lkml, linux-xfs is fine, I think. :) Have you tried this same test on other filesystems? -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Dec 10 13:36:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 13:37:03 -0800 (PST) Received: from mail.arkon-group.com (mail.arkon-group.com [207.34.136.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBALaXTa027178 for ; Wed, 10 Dec 2003 13:36:33 -0800 Received: from 2d052 (fw1.arkonnetworks.com [207.34.136.29]) by mail.arkon-group.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V5LMLCQG; Wed, 10 Dec 2003 13:32:59 -0800 Message-ID: <003301c3bf65$aaff3540$0716a8c0@hq.arkonnetworks.com> From: "Norman Zhang" To: References: <002401c3bf62$79d135c0$0716a8c0@hq.arkonnetworks.com> <10179.212.58.174.35.1071091562.squirrel@webmail.xs4all.nl> Subject: Re: Repair XFS Date: Wed, 10 Dec 2003 13:36:27 -0800 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1353 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Content-Length: 1154 Lines: 27 >> I'm seeing some irregulars halts on one of my XFS volume (/srv). I >> can only use umount -l to dismount the volume or do a hot reboot. >> >> Dec 9 15:47:25 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) >> called from line 1039 of file xfs_trans.c. Return address = >> 0xe109f312 >> Dec 9 15:47:25 smbserver kernel: Corruption of in-memory data >> detected. Shutting down filesystem: md(9,5) >> Dec 9 15:47:25 smbserver kernel: Please umount the filesystem, and >> rectify the problem(s) >> >> I'm not sure if the disk has problems, but during boot up there's no >> error found by fsck. The stall sometime occurs in weeks and >> sometimes few times per day. So I really doubt if this a disk >> problem. Is there any way I can trace or perhaps fix this? BTW, if I >> want to manually force a disk check > > I think you might have a memory problem. Try memtest86. Some people > don't see the problems with other filesystems. I have seen a number > of cases already where bad memory only showed up with XFS filesystems. I did try memtest86, but found no problem. I even swapped brand new RAM. Is there more info I can provide? Regards, Norman From owner-linux-xfs@oss.sgi.com Wed Dec 10 13:38:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 13:38:53 -0800 (PST) Received: from server418.dnslive.net (server418.dnslive.net [216.74.126.5]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBALccTa027864 for ; Wed, 10 Dec 2003 13:38:38 -0800 Received: from [24.229.125.7] (helo=thinker) by server418.dnslive.net with smtp (Exim 4.24) id 1AUC2V-0003g5-0P; Wed, 10 Dec 2003 16:38:35 -0500 From: "Michael Sinz" To: "linux-xfs@oss.sgi.com" , "Norman Zhang" Date: Wed, 10 Dec 2003 16:37:20 -0500 Reply-To: "Michael Sinz" Priority: Normal X-Mailer: sinz.org In-Reply-To: <002401c3bf62$79d135c0$0716a8c0@hq.arkonnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Repair XFS Message-Id: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server418.dnslive.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sinz.org X-archive-position: 1354 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Linux@sinz.org Precedence: bulk X-list: linux-xfs Content-Length: 1519 Lines: 42 On Wed, 10 Dec 2003 13:13:36 -0800, Norman Zhang wrote: >Hi, > >I'm seeing some irregulars halts on one of my XFS volume (/srv). I can only >use umount -l to dismount the volume or do a hot reboot. > >Dec 9 15:47:25 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) called >from line 1039 of file xfs_trans.c. Return address = 0xe109f312 >Dec 9 15:47:25 smbserver kernel: Corruption of in-memory data detected. >Shutting down filesystem: md(9,5) >Dec 9 15:47:25 smbserver kernel: Please umount the filesystem, and rectify >the problem(s) > >I'm not sure if the disk has problems, but during boot up there's no error >found by fsck. The stall sometime occurs in weeks and sometimes few times >per day. So I really doubt if this a disk problem. Is there any way I can >trace or perhaps fix this? BTW, if I want to manually force a disk check on >the XFS volume. Do I just do > >$ umount -l srv >$ fsck.xfs /srv > >I don't see any actions on the screen. fsck.xfs is a no-op. What you need to do is use xfs_repair on the partition while it is unmounted. Note also that anything in lost+found will be "relost" and then "refound" as xfs_repair just unlinks that directory as part of the repair process. Once the repair is complete, you can then remount the file system. NOTE - you can run an xfs_check on the partition first to see what it may report as any problems. However, if xfs_repair should be safe to run in most (all?) cases. -- Michael Sinz - http://www.sinz.org/Michael.Sinz/Linux - Linux@sinz.org From owner-linux-xfs@oss.sgi.com Wed Dec 10 13:56:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 13:56:29 -0800 (PST) Received: from mail.arkon-group.com (mail.arkon-group.com [207.34.136.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBALuFTa028975 for ; Wed, 10 Dec 2003 13:56:15 -0800 Received: from 2d052 (fw1.arkonnetworks.com [207.34.136.29]) by mail.arkon-group.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V5LMLCQR; Wed, 10 Dec 2003 13:52:41 -0800 Message-ID: <003e01c3bf68$6b8afa40$0716a8c0@hq.arkonnetworks.com> From: "Norman Zhang" To: References: Subject: Re: Repair XFS Date: Wed, 10 Dec 2003 13:56:09 -0800 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1355 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Content-Length: 2465 Lines: 70 >> I'm seeing some irregulars halts on one of my XFS volume (/srv). I >> can only use umount -l to dismount the volume or do a hot reboot. >> >> Dec 9 15:47:25 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) >> called from line 1039 of file xfs_trans.c. Return address = >> 0xe109f312 >> Dec 9 15:47:25 smbserver kernel: Corruption of in-memory data >> detected. Shutting down filesystem: md(9,5) >> Dec 9 15:47:25 smbserver kernel: Please umount the filesystem, and >> rectify the problem(s) >> >> I'm not sure if the disk has problems, but during boot up there's no >> error found by fsck. The stall sometime occurs in weeks and >> sometimes few times per day. So I really doubt if this a disk >> problem. Is there any way I can trace or perhaps fix this? BTW, if I >> want to manually force a disk check on the XFS volume. Do I just do >> >> $ umount -l srv >> $ fsck.xfs /srv >> >> I don't see any actions on the screen. > > fsck.xfs is a no-op. What you need to do is use xfs_repair on the > partition while it is unmounted. > > Note also that anything in lost+found will be "relost" and then > "refound" as xfs_repair just unlinks that directory as part of the > repair process. > > Once the repair is complete, you can then remount the file system. > > NOTE - you can run an xfs_check on the partition first to see what it > may report as any problems. However, if xfs_repair should be safe to > run in most (all?) cases. I ran xfs_check /srv but got "xfs_check: can't determine device size". I'm doing something wrong? I can't seem to umount /srv without -l [root@smbserver root]# umount /srv umount: /srv: device is busy I take it I have to umount /srv before doing xfs_check. So I'm need to reboot then xfs_check? Regards, Norman /dev/md4 / xfs noatime 1 1 /dev/sda1 /boot ext2 noatime 1 2 /dev/sdb5 /bootbak ext2 noatime 1 2 none /dev/pts devpts mode=0620 0 0 /dev/md1 /home xfs noatime,grpquota,usrquota 1 2 none /mnt/cdrom supermount dev=/dev/hdc,fs=auto,ro,--,iocharset=iso8859-1,codepa ge=850,umask=0 0 0 none /mnt/floppy supermount dev=/dev/fd0,fs=auto,--,iocharset=iso8859-1,sync,cod epage=850,umask=0 0 0 none /proc proc defaults 0 0 /dev/md5 /srv xfs noatime,grpquota,usrquota 1 2 /dev/md7 /srv2 xfs grpquota,usrquota 1 2 /dev/md0 /tmp xfs noatime 1 2 /dev/md6 /transfer xfs noatime,grpquota,usrquota 1 2 /dev/md3 /usr xfs noatime 1 2 /dev/md2 /var xfs noatime 1 2 /dev/sda5 swap swap defaults 0 0 /dev/sdb6 swap swap defaults 0 0 From owner-linux-xfs@oss.sgi.com Wed Dec 10 14:23:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 14:24:06 -0800 (PST) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAMNiTa030127 for ; Wed, 10 Dec 2003 14:23:45 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id hBAMQfvj012697; Wed, 10 Dec 2003 17:26:41 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id hBAMQfsa012694; Wed, 10 Dec 2003 17:26:41 -0500 Date: Wed, 10 Dec 2003 17:26:41 -0500 (EST) From: Net Llama! To: Norman Zhang cc: linux-xfs@oss.sgi.com Subject: Re: Repair XFS In-Reply-To: <003301c3bf65$aaff3540$0716a8c0@hq.arkonnetworks.com> Message-ID: References: <002401c3bf62$79d135c0$0716a8c0@hq.arkonnetworks.com> <10179.212.58.174.35.1071091562.squirrel@webmail.xs4all.nl> <003301c3bf65$aaff3540$0716a8c0@hq.arkonnetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1719 Lines: 36 On Wed, 10 Dec 2003, Norman Zhang wrote: > >> I'm seeing some irregulars halts on one of my XFS volume (/srv). I > >> can only use umount -l to dismount the volume or do a hot reboot. > >> > >> Dec 9 15:47:25 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) > >> called from line 1039 of file xfs_trans.c. Return address = > >> 0xe109f312 > >> Dec 9 15:47:25 smbserver kernel: Corruption of in-memory data > >> detected. Shutting down filesystem: md(9,5) > >> Dec 9 15:47:25 smbserver kernel: Please umount the filesystem, and > >> rectify the problem(s) > >> > >> I'm not sure if the disk has problems, but during boot up there's no > >> error found by fsck. The stall sometime occurs in weeks and > >> sometimes few times per day. So I really doubt if this a disk > >> problem. Is there any way I can trace or perhaps fix this? BTW, if I > >> want to manually force a disk check > > > > I think you might have a memory problem. Try memtest86. Some people > > don't see the problems with other filesystems. I have seen a number > > of cases already where bad memory only showed up with XFS filesystems. > > I did try memtest86, but found no problem. I even swapped brand new RAM. Is > there more info I can provide? How long did you let memtest86 run (# of passes, hours)? It could also be a CPU cache problem, or even the motherboard going flaky. I've also seen some cases of power supply problems being exhibited as memory issues (insufficient power delivery, or unstable power delivery, spikes, fluctuations outside spec etc). -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Wed Dec 10 14:29:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 14:29:32 -0800 (PST) Received: from server418.dnslive.net (server418.dnslive.net [216.74.126.5]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAMTLTa030615 for ; Wed, 10 Dec 2003 14:29:21 -0800 Received: from [24.229.125.7] (helo=thinker) by server418.dnslive.net with smtp (Exim 4.24) id 1AUCpd-0006YV-Th; Wed, 10 Dec 2003 17:29:21 -0500 From: "Michael Sinz" To: "linux-xfs@oss.sgi.com" , "Norman Zhang" Date: Wed, 10 Dec 2003 17:29:08 -0500 Reply-To: "Michael Sinz" Priority: Normal X-Mailer: sinz.org In-Reply-To: <003e01c3bf68$6b8afa40$0716a8c0@hq.arkonnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Repair XFS Message-Id: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server418.dnslive.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sinz.org X-archive-position: 1357 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Linux@sinz.org Precedence: bulk X-list: linux-xfs Content-Length: 1458 Lines: 45 On Wed, 10 Dec 2003 13:56:09 -0800, Norman Zhang wrote: >>> I'm seeing some irregulars halts on one of my XFS volume (/srv). I >>> can only use umount -l to dismount the volume or do a hot reboot. >> fsck.xfs is a no-op. What you need to do is use xfs_repair on the >> partition while it is unmounted. >> >> Note also that anything in lost+found will be "relost" and then >> "refound" as xfs_repair just unlinks that directory as part of the >> repair process. >> >> Once the repair is complete, you can then remount the file system. >> >> NOTE - you can run an xfs_check on the partition first to see what it >> may report as any problems. However, if xfs_repair should be safe to >> run in most (all?) cases. > >I ran xfs_check /srv but got "xfs_check: can't determine device size". I'm >doing something wrong? Once you get it unmounted (check that other processes are not using it, you may need to switch to init level 2 or even 1... Anyway, once it is unmounted, you should use: xfs_check /dev/md5 and then try xfs_repair /dev/md5 If you need to reboot to umount the volume, you may need to mount it once and then umount it to make sure that the journal (log) is replayed before doing the xfs_repair. You can see some scripts I have that do this "automatically" for my servers using rebooting into LILO to even handle the "/" mount at http://www.sinz.org/Linux/ -- Michael Sinz - http://www.sinz.org/Michael.Sinz/Linux - Linux@sinz.org From owner-linux-xfs@oss.sgi.com Wed Dec 10 14:47:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 14:47:57 -0800 (PST) Received: from mail.arkon-group.com (mail.arkon-group.com [207.34.136.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAMlaTa031973 for ; Wed, 10 Dec 2003 14:47:36 -0800 Received: from 2d052 (fw1.arkonnetworks.com [207.34.136.29]) by mail.arkon-group.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V5LMLCRR; Wed, 10 Dec 2003 14:44:02 -0800 Message-ID: <005d01c3bf6f$97d99500$0716a8c0@hq.arkonnetworks.com> From: "Norman Zhang" To: References: Subject: Re: Repair XFS Date: Wed, 10 Dec 2003 14:47:30 -0800 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Content-Length: 1070 Lines: 33 >> I ran xfs_check /srv but got "xfs_check: can't determine device >> size". I'm doing something wrong? > > Once you get it unmounted (check that other processes are not using > it, you may need to switch to init level 2 or even 1... > > Anyway, once it is unmounted, you should use: > > xfs_check /dev/md5 > > and then try > > xfs_repair /dev/md5 > > If you need to reboot to umount the volume, you may need to mount it > once and then umount it to make sure that the journal (log) is > replayed before doing the xfs_repair. > > You can see some scripts I have that do this "automatically" for my > servers using rebooting into LILO to even handle the "/" mount at > http://www.sinz.org/Linux/ Thanks. I will try umounting again and follow your steps after hours. This is a production server 8( I'm just wondering, won't Linux (Mandrake 9.2) do fsck automatically? After each reboot, I do see that it complained system not shutdown properly, press Y to force check. I press it. System scans some stuffs then repairs. I still see data corruptions 8( Regards, Norman From owner-linux-xfs@oss.sgi.com Wed Dec 10 14:58:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 14:58:18 -0800 (PST) Received: from mail.arkon-group.com (mail.arkon-group.com [207.34.136.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBAMw6Ta000803 for ; Wed, 10 Dec 2003 14:58:07 -0800 Received: from 2d052 (fw1.arkonnetworks.com [207.34.136.29]) by mail.arkon-group.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V5LMLCRY; Wed, 10 Dec 2003 14:54:32 -0800 Message-ID: <006801c3bf71$0fbdc310$0716a8c0@hq.arkonnetworks.com> From: "Norman Zhang" To: References: <002401c3bf62$79d135c0$0716a8c0@hq.arkonnetworks.com> <10179.212.58.174.35.1071091562.squirrel@webmail.xs4all.nl> <003301c3bf65$aaff3540$0716a8c0@hq.arkonnetworks.com> Subject: Re: Repair XFS Date: Wed, 10 Dec 2003 14:58:01 -0800 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1359 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Content-Length: 1927 Lines: 41 >>>> I'm seeing some irregulars halts on one of my XFS volume (/srv). I >>>> can only use umount -l to dismount the volume or do a hot reboot. >>>> >>>> Dec 9 15:47:25 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) >>>> called from line 1039 of file xfs_trans.c. Return address = >>>> 0xe109f312 >>>> Dec 9 15:47:25 smbserver kernel: Corruption of in-memory data >>>> detected. Shutting down filesystem: md(9,5) >>>> Dec 9 15:47:25 smbserver kernel: Please umount the filesystem, and >>>> rectify the problem(s) >>>> >>>> I'm not sure if the disk has problems, but during boot up there's >>>> no error found by fsck. The stall sometime occurs in weeks and >>>> sometimes few times per day. So I really doubt if this a disk >>>> problem. Is there any way I can trace or perhaps fix this? BTW, if >>>> I want to manually force a disk check >>> >>> I think you might have a memory problem. Try memtest86. Some people >>> don't see the problems with other filesystems. I have seen a number >>> of cases already where bad memory only showed up with XFS >>> filesystems. >> >> I did try memtest86, but found no problem. I even swapped brand new >> RAM. Is there more info I can provide? > > How long did you let memtest86 run (# of passes, hours)? It could > also be a CPU cache problem, or even the motherboard going flaky. > I've also seen some cases of power supply problems being exhibited as > memory issues (insufficient power delivery, or unstable power > delivery, spikes, fluctuations outside spec etc). My last memtest86 ran about a good 1/2 to 1 hour, I think it did 3 cycles. I hope it is not HW, as I have 2 other boxes that run exact config except with HW RAID. I'm running Intel SE7500WV2S motherboard, with dual P4 1.8GHz, 2x256MB PC2100 DDR ECC Reg. I did a top on the halted system, but found not much CPU and swap usage. The system also runs with dual hot-swap 400W power-supply on UPS. Regards, Norman From owner-linux-xfs@oss.sgi.com Wed Dec 10 15:12:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 15:13:00 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBANCcTa002155 for ; Wed, 10 Dec 2003 15:12:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBANCcO8002152 for linux-xfs@oss.sgi.com; Wed, 10 Dec 2003 15:12:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBANCYTk002121 for ; Wed, 10 Dec 2003 15:12:36 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBAMeOka031395; Wed, 10 Dec 2003 14:40:24 -0800 Date: Wed, 10 Dec 2003 14:40:24 -0800 Message-Id: <200312102240.hBAMeOka031395@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1360 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 5066 Lines: 112 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From tdickson@inostor.com 2003-10-12 14:40 PDT ------- OK. I'm going to try on this system: PIII with 256 MB ram (to make it happen faster). 2.4.24pre1 still fails. I'm going to get details soon. I'll record the entire slabinfo page, along with trying this on ext3 and reiserfs. (Below, xfs_inode seems to be double the inode_cache). I'll submit the scripts are reports hopefully today. Here's a teaser for now (from the production system: we upped it to 2 GB of RAM and it seems to be runnning.....): bash-2.05a# more /proc/slabinfo slabinfo - version: 1.1 kmem_cache 76 108 108 3 3 1 xfs_dqtrx 0 0 192 0 0 1 xfs_dquots 98 108 324 9 9 1 xfs_acl 0 0 304 0 0 1 xfs_chashlist 25514 37572 16 186 186 1 xfs_ili 1182 1204 140 43 43 1 xfs_ifork 0 0 56 0 0 1 xfs_efi_item 0 0 260 0 0 1 xfs_efd_item 0 0 260 0 0 1 xfs_buf_item 0 0 148 0 0 1 xfs_dabuf 0 202 16 0 1 1 xfs_da_state 0 0 336 0 0 1 xfs_trans 0 0 588 0 0 2 xfs_inode 147529 313130 368 31313 31313 1 xfs_btree_cur 0 0 132 0 0 1 xfs_bmap_free_item 0 0 12 0 0 1 page_buf_t 42 60 192 3 3 1 linvfs_icache 147529 290224 480 36278 36278 1 tcp_tw_bucket 0 0 96 0 0 1 tcp_bind_bucket 17 113 32 1 1 1 tcp_open_request 0 0 64 0 0 1 inet_peer_cache 8 59 64 1 1 1 ip_fib_hash 14 113 32 1 1 1 ip_dst_cache 82 96 160 4 4 1 arp_cache 21 40 96 1 1 1 blkdev_requests 384 400 96 10 10 1 nfs_write_data 0 0 352 0 0 1 nfs_read_data 0 0 320 0 0 1 nfs_page 0 0 96 0 0 1 dnotify_cache 0 0 20 0 0 1 file_lock_cache 44 84 92 2 2 1 fasync_cache 0 0 16 0 0 1 uid_cache 3 113 32 1 1 1 skbuff_head_cache 291 360 160 15 15 1 sock 122 125 768 25 25 1 sigqueue 0 0 132 0 0 1 kiobuf 2 59 64 1 1 1 cdev_cache 11 118 64 2 2 1 bdev_cache 9 59 64 1 1 1 mnt_cache 20 59 64 1 1 1 inode_cache 776 1160 480 145 145 1 dentry_cache 70294 281970 128 9399 9399 1 dquot 0 0 128 0 0 1 filp 959 960 128 32 32 1 names_cache 0 2 4096 0 2 1 buffer_head 394215 396320 96 9908 9908 1 mm_struct 55 60 128 2 2 1 vm_area_struct 2755 2800 96 69 70 1 fs_cache 54 113 32 1 1 1 files_cache 54 54 416 6 6 1 signal_act 71 72 1312 24 24 1 size-131072(DMA) 0 0 131072 0 0 32 size-131072 0 0 131072 0 0 32 size-65536(DMA) 0 0 65536 0 0 16 size-65536 0 0 65536 0 0 16 size-32768(DMA) 0 0 32768 0 0 8 size-32768 4 4 32768 4 4 8 size-16384(DMA) 1 1 16384 1 1 4 size-16384 8 9 16384 8 9 4 size-8192(DMA) 0 0 8192 0 0 2 size-8192 8 8 8192 8 8 2 size-4096(DMA) 0 0 4096 0 0 1 size-4096 257 271 4096 257 271 1 size-2048(DMA) 0 0 2048 0 0 1 size-2048 24 50 2048 12 25 1 size-1024(DMA) 0 0 1024 0 0 1 size-1024 265 268 1024 67 67 1 size-512(DMA) 0 0 512 0 0 1 size-512 367 368 512 46 46 1 size-256(DMA) 0 0 256 0 0 1 size-256 3882 6825 256 455 455 1 size-128(DMA) 0 0 128 0 0 1 size-128 19565 34950 128 1165 1165 1 size-64(DMA) 0 0 64 0 0 1 size-64 17524 31683 64 537 537 1 size-32(DMA) 0 0 32 0 0 1 size-32 22466 112661 32 997 997 1 Note that right after tree on this system the xfs_inode line was around 750000 with 533 MB of RAM used. I'll have more details soon. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 10 15:12:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 15:13:00 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBANCcTa002154 for ; Wed, 10 Dec 2003 15:12:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBANCcFd002153 for linux-xfs@oss.sgi.com; Wed, 10 Dec 2003 15:12:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBANCYTe002121 for ; Wed, 10 Dec 2003 15:12:35 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBAMVkvX031063; Wed, 10 Dec 2003 14:31:46 -0800 Date: Wed, 10 Dec 2003 14:31:46 -0800 Message-Id: <200312102231.hBAMVkvX031063@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1360 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 407 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From sandeen@sgi.com 2003-10-12 14:31 PDT ------- Steve suggests looking at the slab cache entries for inodes & dentries as well, if those are staying high, xfs can't tear down until they're gone. -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 10 16:03:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 16:03:43 -0800 (PST) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBB03ETa006107 for ; Wed, 10 Dec 2003 16:03:14 -0800 Received: from adsl-67-123-174-79.dsl.sntc01.pacbell.net ([67.123.174.79]:62971 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 1AUEI1-0001WF-58 by VAauthid with fixed_plain; Wed, 10 Dec 2003 16:02:45 -0800 Message-ID: <3FD7B412.9090307@linux-sxs.org> Date: Wed, 10 Dec 2003 16:02:26 -0800 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031125 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Zhang CC: linux-xfs@oss.sgi.com Subject: Re: Repair XFS References: <002401c3bf62$79d135c0$0716a8c0@hq.arkonnetworks.com> <10179.212.58.174.35.1071091562.squirrel@webmail.xs4all.nl> <003301c3bf65$aaff3540$0716a8c0@hq.arkonnetworks.com> <006801c3bf71$0fbdc310$0716a8c0@hq.arkonnetworks.com> In-Reply-To: <006801c3bf71$0fbdc310$0716a8c0@hq.arkonnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 1AUEI1-0001WF-58 8e4a2103e4b0110a83f6ff8373e08405 X-Spam-Score: -102.6 (---------------------------------------------------) X-archive-position: 1361 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 2789 Lines: 62 On 12/10/03 14:58, Norman Zhang wrote: >>>>>I'm seeing some irregulars halts on one of my XFS volume (/srv). I >>>>>can only use umount -l to dismount the volume or do a hot reboot. >>>>> >>>>>Dec 9 15:47:25 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) >>>>>called from line 1039 of file xfs_trans.c. Return address = >>>>>0xe109f312 >>>>>Dec 9 15:47:25 smbserver kernel: Corruption of in-memory data >>>>>detected. Shutting down filesystem: md(9,5) >>>>>Dec 9 15:47:25 smbserver kernel: Please umount the filesystem, and >>>>>rectify the problem(s) >>>>> >>>>>I'm not sure if the disk has problems, but during boot up there's >>>>>no error found by fsck. The stall sometime occurs in weeks and >>>>>sometimes few times per day. So I really doubt if this a disk >>>>>problem. Is there any way I can trace or perhaps fix this? BTW, if >>>>>I want to manually force a disk check >>>> >>>>I think you might have a memory problem. Try memtest86. Some people >>>>don't see the problems with other filesystems. I have seen a number >>>>of cases already where bad memory only showed up with XFS >>>>filesystems. >>> >>>I did try memtest86, but found no problem. I even swapped brand new >>>RAM. Is there more info I can provide? >> >>How long did you let memtest86 run (# of passes, hours)? It could >>also be a CPU cache problem, or even the motherboard going flaky. >>I've also seen some cases of power supply problems being exhibited as >>memory issues (insufficient power delivery, or unstable power >>delivery, spikes, fluctuations outside spec etc). > > > My last memtest86 ran about a good 1/2 to 1 hour, I think it did 3 cycles. I Three tests or three passes? A test is not the same as a pass in memtest86. Unless you have an exceedingly fast box, or very little RAM, i'd be really surprised it you completed three passes in under an hour. Normally it takes roughly 2-3 hours for a single pass on a very fast box with 2GB of RAM. > hope it is not HW, as I have 2 other boxes that run exact config except with > HW RAID. I'm running Intel SE7500WV2S motherboard, with dual P4 1.8GHz, > 2x256MB PC2100 DDR ECC Reg. I did a top on the halted system, but found not > much CPU and swap usage. The system also runs with dual hot-swap 400W > power-supply on UPS. Well, that box is moderately fast, and doesn't have much memory, so perhaps memtest86 finished. Its still possible that you've got bad cache on a CPU, or even the mobo. And a bad power supply could still introduce odd behavior. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 4:00pm up 3 days, 20:49, 1 user, load average: 0.16, 0.20, 0.10 From owner-linux-xfs@oss.sgi.com Wed Dec 10 16:26:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 16:26:33 -0800 (PST) Received: from mail.arkon-group.com (mail.arkon-group.com [207.34.136.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBB0QLTa011198 for ; Wed, 10 Dec 2003 16:26:22 -0800 Received: from 2d052 (fw1.arkonnetworks.com [207.34.136.29]) by mail.arkon-group.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V5LMLCSY; Wed, 10 Dec 2003 16:22:47 -0800 Message-ID: <002c01c3bf7d$63c04cb0$0716a8c0@hq.arkonnetworks.com> From: "Norman Zhang" To: References: <005d01c3bf6f$97d99500$0716a8c0@hq.arkonnetworks.com> Subject: Re: Repair XFS Date: Wed, 10 Dec 2003 16:26:16 -0800 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1362 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Content-Length: 1131 Lines: 33 >> Once you get it unmounted (check that other processes are not using >> it, you may need to switch to init level 2 or even 1... >> >> Anyway, once it is unmounted, you should use: >> >> xfs_check /dev/md5 >> >> and then try >> >> xfs_repair /dev/md5 >> >> If you need to reboot to umount the volume, you may need to mount it >> once and then umount it to make sure that the journal (log) is >> replayed before doing the xfs_repair. >> >> You can see some scripts I have that do this "automatically" for my >> servers using rebooting into LILO to even handle the "/" mount at >> http://www.sinz.org/Linux/ > > Thanks. I will try umounting again and follow your steps after hours. > This is a production server 8( > > I'm just wondering, won't Linux (Mandrake 9.2) do fsck automatically? > After each reboot, I do see that it complained system not shutdown > properly, press Y to force check. I press it. System scans some > stuffs then repairs. I still see data corruptions 8( One funny thing, some folders are still viewable after initial stall. Eventually all folders would be not viewable. Anyone seen this? Regards, Norman From owner-linux-xfs@oss.sgi.com Wed Dec 10 19:49:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 19:49:35 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.189.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBB3nDTa014583 for ; Wed, 10 Dec 2003 19:49:13 -0800 Received: from mail.pacrimopen.com (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id 4AAA47000BD6; Wed, 10 Dec 2003 19:55:37 -0800 (PST) Received: from UNKNOWN(127.0.0.1), claiming to be "mail.pacrimopen.com" via SMTP by sa-relay.pacrimopen.com, id smtpd1BSYKr; Wed Dec 10 19:55:25 2003 Received: from menion.home (unknown [4.4.175.20]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id 884857000BD6; Wed, 10 Dec 2003 19:55:24 -0800 (PST) Subject: Re: Repair XFS From: Joshua Schmidlkofer To: Norman Zhang Cc: linux-xfs@oss.sgi.com In-Reply-To: <002c01c3bf7d$63c04cb0$0716a8c0@hq.arkonnetworks.com> References: <005d01c3bf6f$97d99500$0716a8c0@hq.arkonnetworks.com> <002c01c3bf7d$63c04cb0$0716a8c0@hq.arkonnetworks.com> Content-Type: text/plain Message-Id: <1071114539.10440.29.camel@menion.home> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 10 Dec 2003 19:48:59 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 1363 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: menion@asylumwear.com Precedence: bulk X-list: linux-xfs Content-Length: 507 Lines: 17 > > I'm just wondering, won't Linux (Mandrake 9.2) do fsck automatically? > > After each reboot, I do see that it complained system not shutdown > > properly, press Y to force check. I press it. System scans some > > stuffs then repairs. I still see data corruptions 8( > I don't believe that any distro auto-fsck's on XFS partitions. > One funny thing, some folders are still viewable after initial stall. > Eventually all folders would be not viewable. Anyone seen this? > > Regards, > Norman > > From owner-linux-xfs@oss.sgi.com Wed Dec 10 19:56:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 19:57:04 -0800 (PST) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBB3uoTa015112 for ; Wed, 10 Dec 2003 19:56:52 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 34DCFEB4A05 for ; Thu, 11 Dec 2003 11:56:44 +0800 (PHT) Received: from lawin.alabang.leathercollection.ph (lawin.alabang.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id EB14EEB4A00 for ; Thu, 11 Dec 2003 11:56:34 +0800 (PHT) Received: by lawin.alabang.leathercollection.ph (Postfix, from userid 1000) id 488111A4082; Thu, 11 Dec 2003 11:56:32 +0800 (PHT) Date: Thu, 11 Dec 2003 11:56:32 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: Repair XFS Message-ID: <20031211035632.GE15669@leathercollection.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <005d01c3bf6f$97d99500$0716a8c0@hq.arkonnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005d01c3bf6f$97d99500$0716a8c0@hq.arkonnetworks.com> X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.4i X-archive-position: 1364 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 953 Lines: 23 On Wed, Dec 10, 2003 at 02:47:30PM -0800, Norman Zhang wrote: > I'm just wondering, won't Linux (Mandrake 9.2) do fsck automatically? > After each reboot, I do see that it complained system not shutdown > properly, press Y to force check. I press it. System scans some stuffs > then repairs. I still see data corruptions 8( fsck.xfs is a no-op. As mentioned previously, you need to mount then unmount the problemmatic partition, then run xfs_repair(8) manually. For whatever it's worth, I like Knoppix[1] as a rescue disc because it has support for XFS including an acceptably recent version of the XFS userland tools. Great for when it's your root partition that has problems. --> Jijo [1] http://www.knoppix.org -- Federico Sevilla III : http://jijo.free.net.ph : When we speak of free Network Administrator : The Leather Collection, Inc. : software we refer to GnuPG Key ID : 0x93B746BE : freedom, not price. From owner-linux-xfs@oss.sgi.com Wed Dec 10 20:11:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 20:11:52 -0800 (PST) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBB4BfTa015684 for ; Wed, 10 Dec 2003 20:11:41 -0800 Received: from adsl-67-123-174-79.dsl.sntc01.pacbell.net ([67.123.174.79]:63941 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 1AUIAN-0000dM-0x by VAauthid with fixed_plain; Wed, 10 Dec 2003 20:11:07 -0800 Message-ID: <3FD7EE4A.4050507@linux-sxs.org> Date: Wed, 10 Dec 2003 20:10:50 -0800 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031125 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joshua Schmidlkofer CC: Norman Zhang , linux-xfs@oss.sgi.com Subject: Re: Repair XFS References: <005d01c3bf6f$97d99500$0716a8c0@hq.arkonnetworks.com> <002c01c3bf7d$63c04cb0$0716a8c0@hq.arkonnetworks.com> <1071114539.10440.29.camel@menion.home> In-Reply-To: <1071114539.10440.29.camel@menion.home> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 1AUIAN-0000dM-0x 448d4b9fb14f0a56989673fd40ee54a2 X-Spam-Score: -102.6 (---------------------------------------------------) X-archive-position: 1365 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 712 Lines: 19 On 12/10/03 19:48, Joshua Schmidlkofer wrote: >>>I'm just wondering, won't Linux (Mandrake 9.2) do fsck automatically? >>>After each reboot, I do see that it complained system not shutdown >>>properly, press Y to force check. I press it. System scans some >>>stuffs then repairs. I still see data corruptions 8( >> > > I don't believe that any distro auto-fsck's on XFS partitions. I've seen RH9 attempt to do so on unclean shutdowns. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 8:10pm up 4 days, 59 min, 1 user, load average: 0.02, 0.01, 0.00 From owner-linux-xfs@oss.sgi.com Wed Dec 10 22:01:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 22:01:59 -0800 (PST) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBB61TTa021556 for ; Wed, 10 Dec 2003 22:01:29 -0800 Received: from [10.1.2.77] (localhost [127.0.0.1]) by shell.wgops.com (Postfix) with ESMTP id AAE9C25521; Wed, 10 Dec 2003 23:01:04 -0700 (MST) Date: Wed, 10 Dec 2003 23:01:03 -0700 From: Michael Loftis To: Norman Zhang , linux-xfs@oss.sgi.com Subject: Re: Repair XFS Message-ID: <1090397.1071097263@[10.1.2.77]> In-Reply-To: <005d01c3bf6f$97d99500$0716a8c0@hq.arkonnetworks.com> References: <005d01c3bf6f$97d99500$0716a8c0@hq.arkonnetworks.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-MailScanner-Information: Please contact support@wgops.com X-MailScanner: WGOPS clean X-archive-position: 1366 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 945 Lines: 33 --On Wednesday, December 10, 2003 14:47 -0800 Norman Zhang wrote: > Thanks. I will try umounting again and follow your steps after hours. This > is a production server 8( > > I'm just wondering, won't Linux (Mandrake 9.2) do fsck automatically? > After each reboot, I do see that it complained system not shutdown > properly, press Y to force check. I press it. System scans some stuffs > then repairs. I still see data corruptions 8( xfs_repair is the actual fsck utility...on logging type filesystems (ext3, reiserfs, xfs, jfs, vxvfs/vxfs/vfs) they do not generally need a fsck, and if you do there's something usually more ugly going on than just an unclean shutdown. > > Regards, > Norman > > -- Undocumented Features quote of the moment... "It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.'" --Murphy's Laws of Combat From owner-linux-xfs@oss.sgi.com Wed Dec 10 23:06:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 23:07:09 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBB76bTa029330 for ; Wed, 10 Dec 2003 23:06:38 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AUKu7-0003l9-5h; Thu, 11 Dec 2003 07:06:31 +0000 Date: Thu, 11 Dec 2003 07:06:31 +0000 From: Christoph Hellwig To: Austin Gonyou Cc: Ethan Benson , XFS List Subject: Re: Fwd: XFS merged in 2.4 Message-ID: <20031211070630.A14447@infradead.org> References: <20031210101142.GF3294@plato.local.lan> <1071076851.2337.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1071076851.2337.6.camel@localhost.localdomain>; from austin@coremetrics.com on Wed, Dec 10, 2003 at 11:20:52AM -0600 X-archive-position: 1367 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 335 Lines: 7 On Wed, Dec 10, 2003 at 11:20:52AM -0600, Austin Gonyou wrote: > ACLs are also available for even many virtual FS in 2.6 now, with many > backports going to 2.4 for bugfixes, etc. Since ACLs are part of the XFS > code-base, I'd imagine they'd come along. Christoph? I don't think adding ACL support to 2.4 makes sense at this stage. From owner-linux-xfs@oss.sgi.com Wed Dec 10 23:07:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 23:07:57 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBB77iTa029570 for ; Wed, 10 Dec 2003 23:07:45 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AUKv8-0003lH-NS; Thu, 11 Dec 2003 07:07:34 +0000 Date: Thu, 11 Dec 2003 07:07:34 +0000 From: Christoph Hellwig To: Jeremy Jackson Cc: Austin Gonyou , Ethan Benson , XFS List Subject: Re: Fwd: XFS merged in 2.4 Message-ID: <20031211070734.B14447@infradead.org> References: <20031210101142.GF3294@plato.local.lan> <1071076851.2337.6.camel@localhost.localdomain> <3FD7853A.6020505@coplanar.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: <3FD7853A.6020505@coplanar.net>; from jerj@coplanar.net on Wed, Dec 10, 2003 at 03:42:34PM -0500 X-archive-position: 1368 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 648 Lines: 15 On Wed, Dec 10, 2003 at 03:42:34PM -0500, Jeremy Jackson wrote: > Austin Gonyou wrote: > > ACLs are also available for even many virtual FS in 2.6 now, with many > > backports going to 2.4 for bugfixes, etc. Since ACLs are part of the XFS > > code-base, I'd imagine they'd come along. Christoph? > > > > As for dmapi - they probably want it at the VFS layer so other FS can > implement it, rather than just tunneling through VFS with an ioctl to > XFS specific API. DMAPI is broken by design and can't work reliably with the Linux VFS design unless you take special care (see the mountpoint option for it). It should never go into mainline. From owner-linux-xfs@oss.sgi.com Wed Dec 10 23:06:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Dec 2003 23:07:09 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBB76WTa029320 for ; Wed, 10 Dec 2003 23:06:33 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hBB74mP6003759; Thu, 11 Dec 2003 01:04:49 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hBB74mCs003757; Thu, 11 Dec 2003 01:04:48 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: Repair XFS From: Austin Gonyou To: Joshua Schmidlkofer Cc: Norman Zhang , XFS List In-Reply-To: <1071114539.10440.29.camel@menion.home> References: <1071114539.10440.29.camel@menion.home> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1071126287.3351.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 11 Dec 2003 01:04:47 -0600 X-archive-position: 1367 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1029 Lines: 30 that's also what the journal's for. xfs_repair is a manual intervention bit because the journal should take care of making the FS sane again. thus the reason XFS, VXFS, EXT3, Reiser and many other exist. Only thing is, some of the other FS have come from different background and can require "fsck" type operations, but I think that's more archaic now than anything. On Wed, 2003-12-10 at 21:48, Joshua Schmidlkofer wrote: > > > I'm just wondering, won't Linux (Mandrake 9.2) do fsck > automatically? > > > After each reboot, I do see that it complained system not shutdown > > > properly, press Y to force check. I press it. System scans some > > > stuffs then repairs. I still see data corruptions 8( > > > > I don't believe that any distro auto-fsck's on XFS partitions. > > > > One funny thing, some folders are still viewable after initial > stall. > > Eventually all folders would be not viewable. Anyone seen this? > > > > Regards, > > Norman > > > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Dec 11 00:57:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 00:57:41 -0800 (PST) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBB8vITa004932 for ; Thu, 11 Dec 2003 00:57:19 -0800 Received: from erbenson.alaska.net (104-pm22.nwc.alaska.net [209.112.143.104]) by hob.acsalaska.net (8.12.10/8.12.10) with ESMTP id hBB8vFGo093163 for ; Wed, 10 Dec 2003 23:57:16 -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 0F60439E9 for ; Wed, 10 Dec 2003 23:57:12 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 9CDE040FF35; Wed, 10 Dec 2003 23:57:14 -0900 (AKST) Date: Wed, 10 Dec 2003 23:57:14 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Repair XFS Message-ID: <20031211085714.GG3294@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <002401c3bf62$79d135c0$0716a8c0@hq.arkonnetworks.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TmwHKJoIRFM7Mu/A" Content-Disposition: inline In-Reply-To: <002401c3bf62$79d135c0$0716a8c0@hq.arkonnetworks.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.76 X-archive-position: 1369 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 2276 Lines: 81 --TmwHKJoIRFM7Mu/A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 10, 2003 at 01:13:36PM -0800, Norman Zhang wrote: > Hi, >=20 > I'm seeing some irregulars halts on one of my XFS volume (/srv). I can on= ly > use umount -l to dismount the volume or do a hot reboot. >=20 > Dec 9 15:47:25 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) called > from line 1039 of file xfs_trans.c. Return address =3D 0xe109f312 > Dec 9 15:47:25 smbserver kernel: Corruption of in-memory data detected. > Shutting down filesystem: md(9,5) > Dec 9 15:47:25 smbserver kernel: Please umount the filesystem, and recti= fy > the problem(s) >=20 > I'm not sure if the disk has problems, but during boot up there's no error > found by fsck. The stall sometime occurs in weeks and sometimes few times > per day. So I really doubt if this a disk problem. Is there any way I can > trace or perhaps fix this? BTW, if I want to manually force a disk check = on > the XFS volume. Do I just do >=20 > $ umount -l srv > $ fsck.xfs /srv >=20 > I don't see any actions on the screen. nice example of why my patch to fsck.xfs should go in. as a reminder: --- xfs_fsck.c.orig Sat Oct 18 19:59:18 2003 +++ xfs_fsck.c Sat Oct 18 20:00:01 2003 @@ -35,8 +35,18 @@ /* This used to be a symlink to /bin/true but that gives a wierd */ /* dependency problem in a certain package manager. */ =20 +#include + int main(int argc, char **argv) { - return 0; + int i; + + for (i =3D 1 ; i < argc ; i++) { + if ((argv[i])[0] !=3D '-') { + printf("%s: XFS filesystem, no check required.\n",= argv[i]); + break; + } + } + return 0; } the message itself could perhaps be better, but you get the idea. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --TmwHKJoIRFM7Mu/A 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 iEYEARECAAYFAj/YMWoACgkQJKx7GixEevwSGwCfbf+livOHaPd6Ku2iGuf4bBIq FJgAn3gfIHd0h0GQcxu91CKeh1qKhw+B =BEe5 -----END PGP SIGNATURE----- --TmwHKJoIRFM7Mu/A-- From owner-linux-xfs@oss.sgi.com Thu Dec 11 02:19:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 02:20:32 -0800 (PST) Received: from mail.tzv.fal.de (dcs.tzv.fal.de [192.108.34.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBAJrTa011782 for ; Thu, 11 Dec 2003 02:19:54 -0800 Received: by mail.tzv.fal.de (Postfix, from userid 1001) id 8DF3D234127; Thu, 11 Dec 2003 11:19:52 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.tzv.fal.de (Postfix) with ESMTP id 5711B23413E; Thu, 11 Dec 2003 11:19:51 +0100 (CET) Received: from ots-4.tzv.local (ots-4.tzv.local [10.1.0.17]) by mail.tzv.fal.de (Postfix) with ESMTP id A1F56234127; Thu, 11 Dec 2003 11:19:45 +0100 (CET) From: Monika Strack Reply-To: strack@tzv.fal.de To: Austin Gonyou Subject: Re: XFS , QLA2200 and SMP Date: Thu, 11 Dec 2003 11:19:45 +0100 User-Agent: KMail/1.5.3 Cc: debian-user@lists.debian.org, XFS List References: <200312101603.57046.most@tzv.fal.de> <1071076607.2341.1.camel@localhost.localdomain> In-Reply-To: <1071076607.2341.1.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312111119.45429.most@tzv.fal.de> X-Virus-Scanned: by AMaViS snapshot-20020222 X-archive-position: 1370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: most@tzv.fal.de Precedence: bulk X-list: linux-xfs Content-Length: 1021 Lines: 25 Am Mittwoch, 10. Dezember 2003 18:16 schrieb Austin Gonyou: > Which FS is it that you're writing to? A NFS, or is it local and being > shared as NFS? Something seems very odd in that stack trace given the > oops that you have. I write to a local XFS , it is no shared as nfs. I read the data from a NFS mounted disk. I don't have anythink in my modules.conf for qla2200. As I understand the README I only need it for initrd-kernel. I don't use initrd for this machine. I loadet the driver with modprob by hand with no ql2xopts. The Card is for connetion to the the external RAID with userdata only. Monika -- ________________________________________________________________________________ Monika Strack Institut fuer Tierzucht Bundesforschungsanstalt fuer Landwirschaft 31535 Neustadt e-mail: most@tzv.fal.de Germany Tel: +49 5034 /871 154 Fax: +49 5034 /871 239 _______________________________________________________________________________ From owner-linux-xfs@oss.sgi.com Thu Dec 11 02:40:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 02:41:03 -0800 (PST) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBAekTa014027 for ; Thu, 11 Dec 2003 02:40:48 -0800 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 87E1B95012; Thu, 11 Dec 2003 11:40:46 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id 24CF29500A; Thu, 11 Dec 2003 11:40:46 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id hBBAggPP010259; Thu, 11 Dec 2003 11:42:42 +0100 Subject: Re: Fwd: XFS merged in 2.4 From: Olaf Fraczyk To: Christoph Hellwig Cc: Austin Gonyou , Ethan Benson , XFS List In-Reply-To: <20031211070630.A14447@infradead.org> References: <20031210101142.GF3294@plato.local.lan> <1071076851.2337.6.camel@localhost.localdomain> <20031211070630.A14447@infradead.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 11 Dec 2003 11:42:42 +0100 Message-Id: <1071139363.10090.13.camel@venus> Mime-Version: 1.0 X-archive-position: 1371 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@navi.pl Precedence: bulk X-list: linux-xfs Content-Length: 684 Lines: 19 On Thu, 2003-12-11 at 08:06, Christoph Hellwig wrote: > On Wed, Dec 10, 2003 at 11:20:52AM -0600, Austin Gonyou wrote: > > ACLs are also available for even many virtual FS in 2.6 now, with many > > backports going to 2.4 for bugfixes, etc. Since ACLs are part of the XFS > > code-base, I'd imagine they'd come along. Christoph? > > I don't think adding ACL support to 2.4 makes sense at this stage. Hi, As XFS has ACL support out of the box, I think that most XFS users use them. It means (at least for me) that I need to patch the kernel anyway. Just some additional work for end-user. As the patches are trivial (they say so :) it would be nice to have them in. Regards, Olaf From owner-linux-xfs@oss.sgi.com Thu Dec 11 02:50:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 02:50:34 -0800 (PST) Received: from hermes.acsalaska.net (hermes.acsalaska.net [209.112.155.38]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBAoLTa014545 for ; Thu, 11 Dec 2003 02:50:22 -0800 Received: from erbenson.alaska.net (104-pm22.nwc.alaska.net [209.112.143.104]) by hermes.acsalaska.net (8.12.10/8.12.10) with ESMTP id hBBAoId4022724 for ; Thu, 11 Dec 2003 01:50:19 -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 4DFE439E9 for ; Thu, 11 Dec 2003 01:50:15 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id C65FA40FF35; Thu, 11 Dec 2003 01:50:16 -0900 (AKST) Date: Thu, 11 Dec 2003 01:50:16 -0900 From: Ethan Benson To: XFS List Subject: Re: Fwd: XFS merged in 2.4 Message-ID: <20031211105016.GI3294@plato.local.lan> Mail-Followup-To: XFS List References: <20031210101142.GF3294@plato.local.lan> <1071076851.2337.6.camel@localhost.localdomain> <20031211070630.A14447@infradead.org> <1071139363.10090.13.camel@venus> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/8E7gjuj425jZz9t" Content-Disposition: inline In-Reply-To: <1071139363.10090.13.camel@venus> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.76 X-archive-position: 1372 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 2059 Lines: 57 --/8E7gjuj425jZz9t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 11, 2003 at 11:42:42AM +0100, Olaf Fraczyk wrote: > On Thu, 2003-12-11 at 08:06, Christoph Hellwig wrote: > > On Wed, Dec 10, 2003 at 11:20:52AM -0600, Austin Gonyou wrote: > > > ACLs are also available for even many virtual FS in 2.6 now, with many > > > backports going to 2.4 for bugfixes, etc. Since ACLs are part of the = XFS > > > code-base, I'd imagine they'd come along. Christoph? > >=20 > > I don't think adding ACL support to 2.4 makes sense at this stage. > Hi, >=20 > As XFS has ACL support out of the box, I think that most XFS users use > them. It means (at least for me) that I need to patch the kernel anyway. > Just some additional work for end-user. > As the patches are trivial (they say so :) it would be nice to have them > in. I think Chrostoph's point is XFS is the ONLY filesystem in 2.4 which actually supports ACLs, ext2/3 require patches (perhaps significant i haven't checked if they even support xattr in 2.4). it was hard enough getting the absolute mandatory fixes in to support XFS, much less an optional feature. the acl patch only affects one vfs file, in only 3 small places unlikly to be touched by anyone else, so merging it with just about any kernel tree should be no harder then a single patch -p1 command. I agree it would be nice, but i just don't see it happening unfortunatly, for mostly political reasons. fortunatly this one doesn't matter that much since its so much easier to merge and maintain on the user's side (compared to the entire XFS patchset). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --/8E7gjuj425jZz9t 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 iEYEARECAAYFAj/YS+gACgkQJKx7GixEevyRYQCglt8ZFk8FXDbIpot5mioP0AeD SlcAn0NJcD/sBnnWZUzb3Inwdo+Ny73N =Sy/I -----END PGP SIGNATURE----- --/8E7gjuj425jZz9t-- From owner-linux-xfs@oss.sgi.com Thu Dec 11 03:42:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 03:42:19 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBBg5Ta016886 for ; Thu, 11 Dec 2003 03:42:07 -0800 Received: (qmail 2680 invoked from network); 11 Dec 2003 11:42:03 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 11 Dec 2003 11:42:03 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id BA20FC00AE; Thu, 11 Dec 2003 22:41:57 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 98E01140686 for ; Thu, 11 Dec 2003 22:41:57 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: XFS List Subject: Re: Fwd: XFS merged in 2.4 In-reply-to: Your message of "Thu, 11 Dec 2003 01:50:16 -0900." <20031211105016.GI3294@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Dec 2003 22:41:56 +1100 Message-ID: <2993.1071142916@ocs3.intra.ocs.com.au> X-archive-position: 1373 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 699 Lines: 16 On Thu, 11 Dec 2003 01:50:16 -0900, Ethan Benson wrote: >the acl patch only affects one vfs file, in only 3 small places >unlikly to be touched by anyone else, so merging it with just about >any kernel tree should be no harder then a single patch -p1 command. FYI, summary of the acl patch for 2.4.24-pre1: Documentation/Configure.help | 10 +++++ fs/Config.in | 1 fs/namei.c | 13 ++++--- include/linux/fs.h | 2 + include/linux/posix_acl_xattr.h | 67 ++++++++++++++++++++++++++++++++++++++++ include/linux/posix_cap_xattr.h | 27 ++++++++++++++++ 6 files changed, 115 insertions(+), 5 deletions(-) From owner-linux-xfs@oss.sgi.com Thu Dec 11 04:12:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 04:13:10 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBBCCeTa020150 for ; Thu, 11 Dec 2003 04:12:40 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBBCCe0G020149 for linux-xfs@oss.sgi.com; Thu, 11 Dec 2003 04:12:40 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBBCCbTe020133 for ; Thu, 11 Dec 2003 04:12:37 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBBBbfHF016823; Thu, 11 Dec 2003 03:37:41 -0800 Date: Thu, 11 Dec 2003 03:37:41 -0800 Message-Id: <200312111137.hBBBbfHF016823@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1374 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1449 Lines: 34 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From tdickson@inostor.com 2003-10-12 17:03 PDT ------- Created an attachment (id=92) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=92&action=view) output from /proc/slabinfo during mount xfs and tree command Here is some output from running some tests. I wasn't able to get the oom killer to come into play on this one (I don't think I have enough files). I'm going to try again tomorrow with less RAM and see what happens. As for now, I'm retrying with ext3 to see if the issue is in the vfs layer. xfs_check still gets terminated (out of memory). Hmph. ------- Additional Comments From dizzy@roedu.net 2003-11-12 03:37 PDT ------- For me it happened just as you said , on a production machine if I run any command that whould walk a very large tree (I have some >500k of files/dirs on that partition) then OOM started to kill random processes. I havent seen it since I upgraded to 2.4.23 but maybe its just a coincidence (I havent tried to reproduce it either but I noticed it doesnt happen anymore when the machine runs doing its normal stuff like it happened before). Another thing to note... Is it true that you dont have swap active ? (at least I noticed that enabling swap made the OOM killer cool down on normal server usage). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Dec 11 06:15:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 06:16:08 -0800 (PST) Received: from cpout2.tiscali.be (cpout2.tiscali.be [62.235.13.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBEFiTa026093 for ; Thu, 11 Dec 2003 06:15:45 -0800 Received: from [62.235.14.106] (helo=mail.tiscali.nl) by cpout2.tiscali.be with esmtp (Tiscali) id 1AUOLY-0000ev-00 for ; Thu, 11 Dec 2003 11:47:04 +0100 Received: from [134.146.0.27] by mail.tiscali.nl with HTTP; Thu, 11 Dec 2003 11:47:04 +0100 Date: Thu, 11 Dec 2003 11:47:04 +0100 Message-ID: <3FB2684D00023BBB@ocpmta6.freegates.net> From: jbelshaw@tiscali.nl Subject: 2.4.23 sparc xfs oops on mounting To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-archive-position: 1375 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jbelshaw@tiscali.nl Precedence: bulk X-list: linux-xfs Content-Length: 5701 Lines: 124 I am looking at xfs on sparc and I have a kernel oops with 2.4.23 with the latest xfs patches. xfs-2.4.23-all-i386 perhaps as the name suggests this really is an x86 only patch ! I create a new xfs file system and the kernel oops on attempting to mount it. Machine stays up though ! There are memory errors in this oops but They are corrected, so I don't think they are relevant, but they do occur consistently. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Dec 11 10:27:03 namcxh02 kernel: CPU[0]: Correctable ECC Error AFSR[188300000] AFAR[00000000e355bd50] UDBL[322] UDBH[3f6] Dec 11 10:27:03 namcxh02 kernel: CPU[0]: UDBL Syndrome[48] Memory Module "U0701 U0702 U0703 U0704 " Dec 11 10:27:03 namcxh02 kernel: CPU[0]: UDBH Syndrome[48] Memory Module "U0701 U0702 U0703 U0704 " Dec 11 10:27:03 namcxh02 kernel: Unable to handle kernel NULL pointer dereference Dec 11 10:27:03 namcxh02 kernel: tsk->{mm,active_mm}->context = 00000000000007b3 Dec 11 10:27:03 namcxh02 kernel: tsk->{mm,active_mm}->pgd = fffff800ba1de000 Dec 11 10:27:03 namcxh02 kernel: \|/ ____ \|/ Dec 11 10:27:03 namcxh02 kernel: "@'/ .. \`@" Dec 11 10:27:03 namcxh02 kernel: /_| \__/ |_\ Dec 11 10:27:03 namcxh02 kernel: \__U_/ Dec 11 10:27:03 namcxh02 kernel: mount(1207): Oops Dec 11 10:27:03 namcxh02 kernel: CPU[0]: local_irq_count[0] irqs_running[0] Dec 11 10:27:03 namcxh02 kernel: TSTATE: 0000000011009606 TPC: 00000000004e7ca8 TNPC: 00000000004e7cac Y: 00000000 Not tainted Using defaults from ksymoops -t elf32-sparc -a sparc Dec 11 10:27:03 namcxh02 kernel: g0: 0000000000000000 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000000000000 Dec 11 10:27:03 namcxh02 kernel: g4: fffff80000000000 g5: 0000000000000000 g6: fffff800ba0f0000 g7: 0000000000000066 Dec 11 10:27:03 namcxh02 kernel: o0: ffffffffffffffff o1: 0000500000041800 o2: 0000000000000000 o3: 0000000000000080 Dec 11 10:27:03 namcxh02 kernel: o4: 0000000000000080 o5: 00000000000001f0 sp: fffff800ba0f2661 ret_pc: 0000000000518144 Dec 11 10:27:03 namcxh02 kernel: l0: 0000000000000000 l1: 0000000000000000 l2: 0000000002cfc02b l3: 0000000000000001 Dec 11 10:27:03 namcxh02 kernel: l4: fffff800ba069f74 l5: 0000000000000000 l6: 00000000006a68a8 l7: fffff800bfebd908 Dec 11 10:27:03 namcxh02 kernel: i0: fffff800bba66800 i1: fffff800ba069de0 i2: fffff800ba0b8b80 i3: fffff800ba069f60 Dec 11 10:27:03 namcxh02 kernel: i4: fffff800003c633c i5: 000000000000001c i6: fffff800ba0f2721 i7: 00000000005186f8 Dec 11 10:27:03 namcxh02 kernel: Caller[00000000005186f8] Dec 11 10:27:03 namcxh02 kernel: Caller[0000000000519608] Dec 11 10:27:03 namcxh02 kernel: Caller[00000000005196f0] Dec 11 10:27:03 namcxh02 kernel: Caller[0000000000519820] Dec 11 10:27:03 namcxh02 kernel: Caller[000000000051a43c] Dec 11 10:27:03 namcxh02 kernel: Caller[000000000051a9b0] Dec 11 10:27:03 namcxh02 kernel: Caller[000000000051a9f0] Dec 11 10:27:04 namcxh02 kernel: Caller[000000000051abc4] Dec 11 10:27:04 namcxh02 kernel: Caller[00000000005128d8] Dec 11 10:27:04 namcxh02 kernel: Caller[000000000051c104] Dec 11 10:27:04 namcxh02 kernel: Caller[0000000000522b4c] Dec 11 10:27:04 namcxh02 kernel: Caller[0000000000537df4] Dec 11 10:27:04 namcxh02 kernel: Caller[0000000000537bcc] Dec 11 10:27:04 namcxh02 kernel: Caller[0000000000479b00] Dec 11 10:27:04 namcxh02 kernel: Caller[0000000000479f4c] Dec 11 10:27:04 namcxh02 kernel: Caller[0000000000490e94] Dec 11 10:27:04 namcxh02 kernel: Caller[00000000004911a0] Dec 11 10:27:04 namcxh02 kernel: Caller[0000000000433e94] Dec 11 10:27:04 namcxh02 kernel: Caller[0000000000410d34] Dec 11 10:27:04 namcxh02 kernel: Caller[000000000001277c] Dec 11 10:27:04 namcxh02 kernel: Instruction DUMP: 80a2601f 0840000b 80a26000 92027fe0 80a22000 12400009 8400a004 80a2601f >>PC; 004e7ca8 <===== >>O7; 00518144 >>I7; 005186f8 Trace; 005186f8 Trace; 00519608 Trace; 005196f0 Trace; 00519820 Trace; 0051a43c Trace; 0051a9b0 Trace; 0051a9f0 Trace; 0051abc4 Trace; 005128d8 Trace; 0051c104 Trace; 00522b4c Trace; 00537df4 Trace; 00537bcc Trace; 00479b00 Trace; 00479f4c Trace; 00490e94 Trace; 004911a0 Trace; 00433e94 Trace; 00410d34 Trace; 0001277c Before first symbol Code; 004e7c9c 00000000 <_PC>: Code; 004e7c9c 0: 80 a2 60 1f cmp %o1, 0x1f Code; 004e7ca0 4: 08 40 00 0b unknown Code; 004e7ca4 8: 80 a2 60 00 cmp %o1, 0 Code; 004e7ca8 <===== c: d0 00 80 00 ld [ %g2 ], %o0 <===== Code; 004e7cac 10: 92 02 7f e0 add %o1, -32, %o1 Code; 004e7cb0 14: 80 a2 20 00 cmp %o0, 0 Code; 004e7cb4 18: 12 40 00 09 unknown Code; 004e7cb8 1c: 84 00 a0 04 add %g2, 4, %g2 Code; 004e7cbc 20: 80 a2 60 1f cmp %o1, 0x1f 2 warnings issued. Results may not be reliable. From owner-linux-xfs@oss.sgi.com Thu Dec 11 07:12:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 07:13:09 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBBFCfTa029892 for ; Thu, 11 Dec 2003 07:12:41 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBBFCfcx029891 for linux-xfs@oss.sgi.com; Thu, 11 Dec 2003 07:12:41 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBBFCcTe029875 for ; Thu, 11 Dec 2003 07:12:38 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBBF5EDU029150; Thu, 11 Dec 2003 07:05:14 -0800 Date: Thu, 11 Dec 2003 07:05:14 -0800 Message-Id: <200312111505.hBBF5EDU029150@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1376 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1877 Lines: 48 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From lord@xfs.org 2003-11-12 07:05 PDT ------- A few of comments on this bug: From the attachment tdickson made, the problem here is the linux inode cache (which shows up as linvfs_icache). The kernel's prune_icache and prune_dcache code are responsible for cleaning this up. The linux dcache has a problem in that a directory dcache entry cannot be reclaimed if the directory has an entry. This pins the whole page into the cache, it also pins the inode and xfs inode into memory. On a machine with lots of memory, what I have seen happen is that when page reclaim becomes active, it can often get memory out of the page cache of files, if this succeeds it does not attempt to shrink the dcache and icache at all. If the pages are being claimed from the page cache to create more inodes you end up with a huge imbalance in the memory usage on the system. I think this is the fundamental problem, it creates an imbalance in the system which makes things really bad before you can get out of it. Running without swap is a baad thing, no matter how much memory you have. This is probably doubly true if the oom killer is present. There is a memory overcommit systune /proc/sys/vm/overcommit_memory try playing with that to change behavior. The oom killer has come in and out of the kernel over time, I thought it had recently been removed again because of its tendency to kill important processes. In the most recent kernels the linux inode cache entries are significantly smaller. XFS does not use the union at the end of the inode and does not allocate it at all if the right code is in place. I do not honestly know if this made it into Marcelo or Linus's trees. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Dec 11 08:02:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 08:02:37 -0800 (PST) Received: from server418.dnslive.net (server418.dnslive.net [216.74.126.5]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBG2PTa031061 for ; Thu, 11 Dec 2003 08:02:25 -0800 Received: from [24.229.125.7] (helo=thinker) by server418.dnslive.net with smtp (Exim 4.24) id 1AUTGT-0006S6-Hj; Thu, 11 Dec 2003 11:02:09 -0500 From: "Michael Sinz" To: "linux-xfs@oss.sgi.com" , "Norman Zhang" Date: Thu, 11 Dec 2003 11:00:38 -0500 Reply-To: "Michael Sinz" Priority: Normal X-Mailer: sinz.org In-Reply-To: <005d01c3bf6f$97d99500$0716a8c0@hq.arkonnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Repair XFS Message-Id: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server418.dnslive.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sinz.org X-archive-position: 1377 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Linux@sinz.org Precedence: bulk X-list: linux-xfs Content-Length: 1909 Lines: 49 On Wed, 10 Dec 2003 14:47:30 -0800, Norman Zhang wrote: >>> I ran xfs_check /srv but got "xfs_check: can't determine device >>> size". I'm doing something wrong? >> >> Once you get it unmounted (check that other processes are not using >> it, you may need to switch to init level 2 or even 1... >> >> Anyway, once it is unmounted, you should use: >> >> xfs_check /dev/md5 >> >> and then try >> >> xfs_repair /dev/md5 >> >> If you need to reboot to umount the volume, you may need to mount it >> once and then umount it to make sure that the journal (log) is >> replayed before doing the xfs_repair. >> >> You can see some scripts I have that do this "automatically" for my >> servers using rebooting into LILO to even handle the "/" mount at >> http://www.sinz.org/Linux/ > >Thanks. I will try umounting again and follow your steps after hours. This >is a production server 8( > >I'm just wondering, won't Linux (Mandrake 9.2) do fsck automatically? After >each reboot, I do see that it complained system not shutdown properly, press >Y to force check. I press it. System scans some stuffs then repairs. I still >see data corruptions 8( XFS is a journalled file system that, under most all situations, should not need any fsck. Most all distros/init scripts do run FSCK at boot time but for XFS this is not needed and is a no-op. The xfs_repair is for when something drastically wrong happens, usually due to a bug somewhere or a really unlucky bit of timing with bad hardware (where writes are not really flushed when they say they are). My only cases where an xfs_repair have been needed was during the various bugs and fixes to the XFS code itself and one system where the hard drive just suddenly quit and did not finish flushing its cache to disk. (That was a really strange case of firmware gone bad within the drive) -- Michael Sinz - http://www.sinz.org/Michael.Sinz/Linux - Linux@sinz.org From owner-linux-xfs@oss.sgi.com Thu Dec 11 09:12:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 09:13:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBBHCeTa003022 for ; Thu, 11 Dec 2003 09:12:40 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBBHCeu2003021 for linux-xfs@oss.sgi.com; Thu, 11 Dec 2003 09:12:40 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBBHCcTe003003 for ; Thu, 11 Dec 2003 09:12:38 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBBGaIv4002374; Thu, 11 Dec 2003 08:36:18 -0800 Date: Thu, 11 Dec 2003 08:36:18 -0800 Message-Id: <200312111636.hBBGaIv4002374@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1378 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 568 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From tdickson@inostor.com 2003-11-12 08:36 PDT ------- I've no swap on the system because I'm running a mirrored OS from awhile back, and back then swapping to a md device was considered bad. Is this changed now? Perhaps running with swap is necessary, but I really don't like the idea of swapping to software raid. I'll verify that it occurs with ext3, too. Ugh. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Dec 11 09:28:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 09:29:10 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBHSwTa003836 for ; Thu, 11 Dec 2003 09:28:58 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hBBHRH6k002734; Thu, 11 Dec 2003 11:27:17 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hBBHRGWv002732; Thu, 11 Dec 2003 11:27:16 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: Fwd: XFS merged in 2.4 From: Austin Gonyou To: Ethan Benson Cc: XFS List In-Reply-To: <20031211105016.GI3294@plato.local.lan> References: <20031211105016.GI3294@plato.local.lan> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1071163636.2355.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 11 Dec 2003 11:27:16 -0600 X-archive-position: 1379 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1043 Lines: 26 On Thu, 2003-12-11 at 04:50, Ethan Benson wrote: > [...] > > I think Chrostoph's point is XFS is the ONLY filesystem in 2.4 which > actually supports ACLs, ext2/3 require patches (perhaps significant i > haven't checked if they even support xattr in 2.4). > > it was hard enough getting the absolute mandatory fixes in to support > XFS, much less an optional feature. > > the acl patch only affects one vfs file, in only 3 small places > unlikly to be touched by anyone else, so merging it with just about > any kernel tree should be no harder then a single patch -p1 command. > > I agree it would be nice, but i just don't see it happening > unfortunatly, for mostly political reasons. fortunatly this one > doesn't matter that much since its so much easier to merge and > maintain on the user's side (compared to the entire XFS patchset). Since ACLs are in 2.6 for everything under the sun just about, even pty fs, I'd think that this wouldn't be a huge problem for 2.4. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Dec 11 09:49:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 09:49:55 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBHndTa011037 for ; Thu, 11 Dec 2003 09:49:41 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBBJ6mm7003530 for ; Thu, 11 Dec 2003 13:06:48 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBBHmXSC19490003; Thu, 11 Dec 2003 11:48:33 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.233.34]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBBHmOoZ205681; Thu, 11 Dec 2003 11:48:24 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id LAA20028; Thu, 11 Dec 2003 11:48:24 -0600 (CST) Message-Id: <200312111748.LAA20028@slobber.americas.sgi.com> To: Christoph Hellwig cc: Jeremy Jackson , Austin Gonyou , Ethan Benson , XFS List Subject: Re: Fwd: XFS merged in 2.4 Date: Thu, 11 Dec 2003 11:48:23 -0600 From: Dean Roehrich X-archive-position: 1380 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1377 Lines: 32 >> As for dmapi - they probably want it at the VFS layer so other FS can >> implement it, rather than just tunneling through VFS with an ioctl to >> XFS specific API. Jeremy, you're over-simplifying and picking the low-hanging fruit. Having a working implementation, no matter how objectionable this one may be at the moment, does serve to help other people see the issues involved in making DMAPI work; it does help people see the types of problems that DMAPI has to solve. Everytime someone says it can be done entirely at the Linux VFS level, and that filesystems shouldn't have to be modified to be aware of it, I wonder if they've really studied the issues. >From: Christoph Hellwig >DMAPI is broken by design and can't work reliably with the Linux VFS >design unless you take special care (see the mountpoint option for >it). The fact that the mount event must include the name of the mountpoint is clearly questionable. Unfortunately, Linux is probably the first time anyone who does dmapi has run into an OS that allows a filesystem to be mounted on multiple mountpoints at the same time--it was easy for the people designing the dmapi spec to not anticipate this complication. On the other hand, I will grant that the mount event is one piece that can be done entirely in the Linux VFS layer--originally, that's where I had it. Dean From owner-linux-xfs@oss.sgi.com Thu Dec 11 12:13:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 12:13:22 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBBKD1Ta014656 for ; Thu, 11 Dec 2003 12:13:01 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBBKD1vb014655 for linux-xfs@oss.sgi.com; Thu, 11 Dec 2003 12:13:01 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBBKCdTc014636 for ; Thu, 11 Dec 2003 12:12:59 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBBJpDrd014195; Thu, 11 Dec 2003 11:51:13 -0800 Date: Thu, 11 Dec 2003 11:51:13 -0800 Message-Id: <200312111951.hBBJpDrd014195@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 382 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From juri@koschikode.com 2003-11-12 11:51 PDT ------- Having a SWAP partition on a software RAID is safe since 2.4. I do it on different machines and never had a problem with it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Dec 11 12:52:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 12:52:46 -0800 (PST) Received: from gdr.neokimia.com (dir-rnd.med.usherbrooke.ca [132.210.158.206]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBKqHTa018522 for ; Thu, 11 Dec 2003 12:52:28 -0800 Received: from mercure.neokimia.com (exchange.neokimia.com [192.168.1.3]) by gdr.neokimia.com (8.12.10/8.12.10) with ESMTP id hBBKqFBW020403 for ; Thu, 11 Dec 2003 15:52:15 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: format XFS partition X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 11 Dec 2003 15:52:14 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: format XFS partition Thread-Index: AcO/M6SXSU9sXj1kSsqCspM6pUSnCA== From: "Yanick Quirion" To: X-NK-Spam-Status: Ce message n'est pas du SPAM, (Score: 0, Requis: 5) X-NK-Spam-Version: SpamAssassin version 2.60 X-Scanned-By: MIMEDefang 2.38 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hBBKqSTa018524 X-archive-position: 1382 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yanick.quirion@neokimia.com Precedence: bulk X-list: linux-xfs Content-Length: 605 Lines: 26 Hi all,   I'm using XFS for the first time with kernel 2.4.22 and LVM2. I just want to know what are the best options to use to format an XFS partition. I will have an Oracle Database on this partition and a FTP site, so the size of the file will be big.   Thanks for your help.   Regards,   ----------- Yanick Quirion Administrateur Réseau/Network Manager NEOKIMIA INC. Institut de Pharmacologie de Sherbrooke 3e étage (Édifice Z5) 3001 12e avenue Nord Sherbrooke, Québec CANADA J1H 5N4   Tél.:    +1 819 820-6040 Direct:  +1 819 820-6855 Fax.:    +1 819 820-6841   email: Yanick.Quirion@neokimia.com   From owner-linux-xfs@oss.sgi.com Thu Dec 11 13:19:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 13:19:29 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.189.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBLJ2Ta019463 for ; Thu, 11 Dec 2003 13:19:03 -0800 Received: from mail.pacrimopen.com (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id 5A4387002501; Thu, 11 Dec 2003 13:19:04 -0800 (PST) Received: from UNKNOWN(127.0.0.1), claiming to be "mail.pacrimopen.com" via SMTP by sa-relay.pacrimopen.com, id smtpdLi4oHg; Thu Dec 11 13:18:51 2003 Received: from menion.home (unknown [4.4.175.20]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id 243517002501; Thu, 11 Dec 2003 13:18:51 -0800 (PST) Subject: Re: format XFS partition From: Joshua Schmidlkofer To: Yanick Quirion Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-E5kuWO6TmHyTRgLfPayD" Message-Id: <1071177528.15013.20.camel@menion.home> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 11 Dec 2003 13:18:48 -0800 X-archive-position: 1383 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: menion@asylumwear.com Precedence: bulk X-list: linux-xfs Content-Length: 2061 Lines: 66 --=-E5kuWO6TmHyTRgLfPayD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2003-12-11 at 12:52, Yanick Quirion wrote: > Hi all, >=20=20 > I'm using XFS for the first time with kernel 2.4.22 and LVM2. I just want= to know what are the best options to use to format an XFS partition. I wil= l have an Oracle Database on this partition and a FTP site, so the size of = the file will be big. >=20=20 > Thanks for your help. >=20=20 > Regards, >=20=20 Have you checked out the FAQ?=20=20 http://oss.sgi.com/projects/xfs/faq.html Also, the man page for mkfs.xfs is very usefull.=20 The only things that I have heard are: a. On large volumes keep dcount lower than default. mkfs.xfs -d agcount=3Dx * agcount has to align with sunit and swidth but I don't com b. On RAID arrangements, if your RAID is hardware use: mkfs.xfs -d suinit=3Dk,swidth=3D<(n) disks> * I also saw one post that said on RAID5 use * swith=3D<(n-1) disks> c. Increase the size of the log: mkfs.xfs -l size=3D32m * maybe someone of greater knowledge can comment on=20 * determining what size is reasonable. d. Mount with more logbufs: o logbufs=3D4 or logbufs=3D8, this increases (from 2) the number of in memory log buffers. This means you can have more active transactions at once, and can still perform metadata changes while the log is being synced to disk. The flip side of this is that the amount of metadata changes which may be lost on crash is greater. e. evaluate volume creation options with the '-N' switch. Take note of the output to help decide if what's being done looks optimal. --=-E5kuWO6TmHyTRgLfPayD Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/2N84cweM6t71VHsRAgY6AJ9+zjZuYnfZpIvLytDdk2tTxkg3tgCeMVJH VLWXagiCeF3hF7dodlL/P64= =pQo6 -----END PGP SIGNATURE----- --=-E5kuWO6TmHyTRgLfPayD-- From owner-linux-xfs@oss.sgi.com Thu Dec 11 15:15:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 15:15:31 -0800 (PST) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBNF6Ta021626 for ; Thu, 11 Dec 2003 15:15:09 -0800 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id hBBNF4r1016035 for ; Fri, 12 Dec 2003 00:15:04 +0100 Received: from rss1.rz.uni-regensburg.de ([132.199.1.200]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Fri, 12 Dec 2003 00:15:04 +0100 (CET) Received: (qmail 2732 invoked from network); 12 Dec 2003 00:15:03 +0100 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 12 Dec 2003 00:15:03 +0100 Subject: Re: sunit, swidth question - mkfs.xfs tuning From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Joshua Schmidlkofer Cc: linux-xfs@oss.sgi.com In-Reply-To: <1071012200.32237.175.camel@bubbles.imr-net.com> References: <1071012200.32237.175.camel@bubbles.imr-net.com> Content-Type: text/plain Message-Id: <1071184504.678.19.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 12 Dec 2003 00:15:04 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 1384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 918 Lines: 32 Hi, On Wed, 2003-12-10 at 00:23, Joshua Schmidlkofer wrote: > Howdy, > WOO HOOO!! On 2.4 inclusion, BTW. (good going!) > > An old e-mail from Christian Guggenberger recommends swidth be (n-1) > disks for RAID5. Is that correct? I have a 66GB volume so I was > looking at: > well, the (n-1)*sunit=swidth thing was suggested by Steve some long time (sorry I can't find the original message in the archives) - and that's what I'm using here on several Raid5 setups. > Mylex AcceleRAID 170, 6 disks in a RAID 5. (4GB system memory) > > mkfs.xfs -d su=64k,sw=5 -l size=32m,sunit=64k -L "data" /dev/... > it looks right for the data-section, but sunit=64k is way too large for the logsection. (the syntax is wrong, too - should be sunit=128, (or su=64k) as sunit is given in multplies of 512-byte block units) see http://marc.theaimsgroup.com/?l=linux-xfs&m=104419883023845&w=2 for more info. Christian From owner-linux-xfs@oss.sgi.com Thu Dec 11 15:20:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 15:20:21 -0800 (PST) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBNK9Ta022063 for ; Thu, 11 Dec 2003 15:20:10 -0800 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id hBBNK8r1017899 for ; Fri, 12 Dec 2003 00:20:08 +0100 Received: from rss1.rz.uni-regensburg.de ([132.199.1.200]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Fri, 12 Dec 2003 00:20:08 +0100 (CET) Received: (qmail 2772 invoked from network); 12 Dec 2003 00:20:08 +0100 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 12 Dec 2003 00:20:08 +0100 Subject: Re: format XFS partition From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Joshua Schmidlkofer Cc: Yanick Quirion , linux-xfs@oss.sgi.com In-Reply-To: <1071177528.15013.20.camel@menion.home> References: <1071177528.15013.20.camel@menion.home> Content-Type: text/plain Message-Id: <1071184809.678.25.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 12 Dec 2003 00:20:09 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 1385 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1894 Lines: 53 On Thu, 2003-12-11 at 22:18, Joshua Schmidlkofer wrote: > On Thu, 2003-12-11 at 12:52, Yanick Quirion wrote: > > Hi all, > > > > I'm using XFS for the first time with kernel 2.4.22 and LVM2. I just want to know what are the best options to use to format an XFS partition. I will have an Oracle Database on this partition and a FTP site, so the size of the file will be big. > > > > Thanks for your help. > > > > Regards, > > > > Have you checked out the FAQ? > http://oss.sgi.com/projects/xfs/faq.html > > Also, the man page for mkfs.xfs is very usefull. > > The only things that I have heard are: > > a. On large volumes keep dcount lower than default. > mkfs.xfs -d agcount=x xfsprogs-2.6.0 should do that out of the box. I recently created a 1.6TB fs which has agcount=32, agsize=13340000, while a 1.7 TB volume created a year ago has agcount=431, agsize=1048576. > * agcount has to align with sunit and swidth but I don't com > > b. On RAID arrangements, if your RAID is hardware use: > mkfs.xfs -d suinit=k,swidth=<(n) disks> > * I also saw one post that said on RAID5 use > * swith=<(n-1) disks> > > c. Increase the size of the log: > mkfs.xfs -l size=32m > * maybe someone of greater knowledge can comment on > * determining what size is reasonable. > > d. Mount with more logbufs: > o logbufs=4 or logbufs=8, this increases (from 2) the number of > in memory log buffers. This means you can have more active > transactions at once, and can still perform metadata changes > while the log is being synced to disk. The flip side of this > is that the amount of metadata changes which may be lost on > crash is greater. > > e. evaluate volume creation options with the '-N' switch. Take note of > the output to help decide if what's being done looks optimal. > > > From owner-linux-xfs@oss.sgi.com Thu Dec 11 15:36:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 15:37:05 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBBNarTa030209 for ; Thu, 11 Dec 2003 15:36:54 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hBBLh5OO030262 for ; Thu, 11 Dec 2003 13:43:06 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22697 for ; Fri, 12 Dec 2003 10:35:34 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 7B1D9C00AD; Fri, 12 Dec 2003 10:35:31 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 782C11400B7; Fri, 12 Dec 2003 10:35:31 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: jbelshaw@tiscali.nl Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.23 sparc xfs oops on mounting In-reply-to: Your message of "Thu, 11 Dec 2003 11:47:04 BST." <3FB2684D00023BBB@ocpmta6.freegates.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Dec 2003 10:35:30 +1100 Message-ID: <1726.1071185730@kao2.melbourne.sgi.com> X-archive-position: 1386 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 379 Lines: 11 On Thu, 11 Dec 2003 11:47:04 +0100, jbelshaw@tiscali.nl wrote: >I am looking at xfs on sparc and I have a kernel oops >with 2.4.23 with the latest xfs patches. > >xfs-2.4.23-all-i386 That includes kdb patches for i386, which is probably not a good thing on sparc. Remove that patch, read the README in the patch directory, and apply just the xfs split patches that you need. From owner-linux-xfs@oss.sgi.com Thu Dec 11 16:12:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 16:12:53 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBC0CgTa031464 for ; Thu, 11 Dec 2003 16:12:42 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBC0CgZD031463 for linux-xfs@oss.sgi.com; Thu, 11 Dec 2003 16:12:42 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBC0CdTe031447 for ; Thu, 11 Dec 2003 16:12:40 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBBNxFe6031193; Thu, 11 Dec 2003 15:59:15 -0800 Date: Thu, 11 Dec 2003 15:59:15 -0800 Message-Id: <200312112359.hBBNxFe6031193@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 209] Kernel 2.4.20-xfs memory leaks X-Bugzilla-Reason: AssignedTo X-archive-position: 1387 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1401 Lines: 41 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 ------- Additional Comments From tdickson@inostor.com 2003-11-12 13:29 PDT ------- Created an attachment (id=94) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=94&action=view) Directory creation bomber Thank you! As always, I should blame the VM first, not poor little XFS :) Running 2.4.24pre1 with the script attached is still working after 3000000 directories and counting. Free memory drops to about 60 megs and then will jump back up to 200 megs. So it seems that if you wanna run without swap you have to use 2.4.23 or greater. Good to know. All I need to do is run some further stress tests, then I'll drop this into production. ------- Additional Comments From nathans@sgi.com 2003-11-12 15:59 PDT ------- > ------- Additional Comments From lord@xfs.org 2003-11-12 07:05 PDT ------- > ... > In the most recent kernels the linux inode cache entries are significantly > smaller. XFS does not use the union at the end of the inode and does not > allocate it at all if the right code is in place. I do not honestly > know if this made it into Marcelo or Linus's trees. There was nothing modified during the 2.4 merge in that area, Steve. Fortunately for us, Christoph knows those changes intimately. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Dec 11 16:32:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 16:32:28 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBC0W0Ta002773 for ; Thu, 11 Dec 2003 16:32:00 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hBBMdNOO007486 for ; Thu, 11 Dec 2003 14:39:24 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23480 for ; Fri, 12 Dec 2003 11:31:50 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 39429C00AD; Fri, 12 Dec 2003 11:31:47 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 367C01400B7; Fri, 12 Dec 2003 11:31:47 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: Announce: XFS split patches for 2.4.24-pre1 Date: Fri, 12 Dec 2003 11:31:46 +1100 Message-ID: <2661.1071189106@kao2.melbourne.sgi.com> X-archive-position: 1388 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 938 Lines: 27 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/2.4.24-pre1. 2.4.24-pre1 now contains the bulk of the XFS code. These split patches only contain XFS updates from 2.4.24-pre1, plus add on code such as ACL, DMAPI and KDB. If you do not need those features and you are not seeing any bugs in the base 2.4.24-pre1 XFS code then you do not need to apply any of these patches. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.24/README for the terminally impatient :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE/2Qxyi4UHNye0ZOoRAv2KAKCI6dNO7+Uu6BagjMhRjlDRrWxQYwCgvOvr UyrrqhBfy6dJHnH9vdECVZs= =kMrw -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Thu Dec 11 16:41:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 16:41:24 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBC0fCTa003273 for ; Thu, 11 Dec 2003 16:41:12 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBBMmZOO008720 for ; Thu, 11 Dec 2003 14:48:36 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hBC0f1qH879746 for ; Fri, 12 Dec 2003 11:41:01 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hBC0f0on879929 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 11:41:00 +1100 (EST) Date: Fri, 12 Dec 2003 11:41:00 +1100 (EST) From: Nathan Scott Message-Id: <200312120041.hBC0f0on879929@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - merge cleanups X-archive-position: 1389 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1714 Lines: 68 Cleanup bdevname conditional code in xfs_buf headers. Date: Thu Dec 11 16:03:12 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:163365a linux/fs/xfs/xfs_buf.h - 1.114 linux/fs/xfs/pagebuf/page_buf.h - 1.81 Remove some unnecessary conditional refcache code. Date: Thu Dec 11 16:11:01 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:163367a linux/fs/xfs/linux/xfs_globals.c - 1.64 linux/fs/xfs/linux/xfs_sysctl.c - 1.31 Remove some unnecessary kernel-version conditional code. Date: Thu Dec 11 16:13:00 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:163368a linux/fs/xfs/linux/xfs_linux.h - 1.122 Rework some casts and use of sector_t in some address_space operations. Date: Thu Dec 11 16:27:16 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:163370a linux/fs/xfs/linux/xfs_aops.c - 1.62 Remove some kernel-version macros around old I/O path code. Date: Thu Dec 11 16:35:46 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:163372a linux/fs/xfs/linux/xfs_lrw.c - 1.208 linux/fs/xfs/linux/xfs_file.c - 1.100 From owner-linux-xfs@oss.sgi.com Thu Dec 11 20:13:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Dec 2003 20:13:57 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBC4DjTa007726 for ; Thu, 11 Dec 2003 20:13:46 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBC5Usm7031923 for ; Thu, 11 Dec 2003 23:30:55 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hBC4CLqH863353 for ; Fri, 12 Dec 2003 15:12:21 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hBC4CKWU900480 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 15:12:20 +1100 (EST) Date: Fri, 12 Dec 2003 15:12:20 +1100 (EST) From: Nathan Scott Message-Id: <200312120412.hBC4CKWU900480@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - extended attributes X-archive-position: 1390 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 564 Lines: 20 Rework some extended attributes code to make it more easily extended. Date: Thu Dec 11 20:08:29 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:163383a linux/fs/xfs/xfsidbg.c - 1.250 linux/fs/xfs/xfs_acl.h - 1.26 linux/fs/xfs/xfs_attr_leaf.h - 1.33 linux/fs/xfs/xfs_attr_leaf.c - 1.75 linux/fs/xfs/xfs_attr.c - 1.112 linux/fs/xfs/xfs_attr.h - 1.28 linux/fs/xfs/linux/xfs_iops.c - 1.201 linux/fs/xfs/linux/xfs_iops.h - 1.25 From owner-linux-xfs@oss.sgi.com Fri Dec 12 02:11:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Dec 2003 02:11:53 -0800 (PST) Received: from pophost.wldelft.nl (sunray.wldelft.nl [145.9.132.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBCABMTa024607 for ; Fri, 12 Dec 2003 02:11:23 -0800 Received: (from root@localhost) by pophost.wldelft.nl (8.9.3/8.9.3vc) id LAA04205 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 11:11:22 +0100 (MET) Received: (from root@localhost) by pophost.wldelft.nl (8.9.3/8.9.3vc) id LAA28658 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 11:01:17 +0100 (MET) Received: (from root@localhost) by pophost.wldelft.nl (8.9.3/8.9.3vc) id KAA17442 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 10:51:12 +0100 (MET) Received: (from root@localhost) by pophost.wldelft.nl (8.9.3/8.9.3vc) id KAA11503 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 10:41:05 +0100 (MET) Received: (from root@localhost) by pophost.wldelft.nl (8.9.3/8.9.3vc) id KAA11294 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 10:30:57 +0100 (MET) Received: (from root@localhost) by pophost.wldelft.nl (8.9.3/8.9.3vc) id KAA06977 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 10:21:20 +0100 (MET) Received: (from root@localhost) by pophost.wldelft.nl (8.9.3/8.9.3vc) id KAA16374 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 10:06:34 +0100 (MET) Received: from WLdelft.nl (wl10996 [145.9.222.37]) by pophost.wldelft.nl (8.9.3/8.9.3) with ESMTP id KAA15914 for ; Fri, 12 Dec 2003 10:06:23 +0100 (MET) Message-ID: <3FD9850F.90702@WLdelft.nl> Date: Fri, 12 Dec 2003 10:06:23 +0100 From: Leroy van Logchem Organization: WL delft hydraulics User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Kernel 2.4.22 xfs_force_shutdown Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1391 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Leroy.vanLogchem@wldelft.nl Precedence: bulk X-list: linux-xfs Content-Length: 6093 Lines: 115 Best XFS mailinglist, We have been using XFS on semi-large servers the last 2.5 years [ 2 x 600 GB ] With that in mind we have bought two large servers with general specs: - 24 x 250 GB disks (leaving 4.5 TB netto when using RAID5+2hotspare) - 2 x 3Ware hardware RAID controllers - 6 GB ram - Dual CPU on TYAN mainboard - Debian 3 using 2.4.22 with XFS patches Main purpose is serving NFS v3 and some Samba v3 to >300 users. The total amount of files exceeds 5 milion, most of them are below 1 MB. Loadavg on a normal working day varies between 0.5 <-> 2, which seems quite good & low to me. The servers are running for 2 weeks now but last night one 1.1 TB partition went down -xfs_force_shutdown(sd(8,48),0x8)-. I couldnt umount it so I had to reboot the server. Not a single sign of hardware error messages from the raid drivers. The partitions are mkfs'ed using: mkfs -V -t xfs -f -d su=65536,sw=8 /dev/sdd Logfiles and various info follows: /proc/partitions major minor #blocks name rio rmerge rsect ruse wio wmerge wsect wuse running use aveq 8 0 976790016 sda 3097 15187 146001 155810 6292 94489 804001 265190 0 66830 421000 8 16 1220987520 sdb 33 76 649 180 3 62 513 70 0 250 250 8 32 976790016 sdc 274 76 2521 2450 4 63 529 40 0 2490 2490 8 48 1220987520 sdd 9456 174151 1468331 1372750 4402 42143 367990 505730 0 232020 1878480 /proc/interrupts 26: 357 13379 IO-APIC-level 3ware Storage Controller 27: 132 9000 IO-APIC-level 3ware Storage Controller Elevators optimized for writing are: /dev/sd[a-d] elevator ID 8 read_latency: 32 write_latency: 8192 /proc/version Linux version 2.4.22-xfs (root@kingfish) (gcc version 3.3.2 (Debian)) #12 SMP Thu Nov 27 17:34:34 CET 2003 /var/log/messages Dec 12 01:54:58 kingfish -- MARK -- Dec 12 01:56:22 kingfish kernel: f6bd7c68 f6bd7cc4 c01bbb60 c03259af 00000001 00000000 c03259a3 00000662 Dec 12 01:56:22 kingfish kernel: c01bcbfa 00000000 00000001 f707cc00 f4aaeeac 000a8d43 0000000d 00000001 Dec 12 01:56:22 kingfish kernel: 000a8ce0 00000030 00000000 00000001 00000000 ee73dd10 00000000 f6bd7d3c Dec 12 01:56:22 kingfish kernel: Call Trace: Dec 12 01:56:22 kingfish kernel: [xfs_free_ag_extent+1056/1808] xfs_free_ag_extent+0x420/0x710 [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_free_extent+186/224] xfs_free_extent+0xba/0xe0 [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_free_extent+186/224] xfs_free_extent+0xba/0xe0 [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_efd_init+124/126] xfs_efd_init+0x7c/0x7e [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_trans_get_efd+54/80] xfs_trans_get_efd+0x36/0x50 [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_bmap_finish+306/448] xfs_bmap_finish+0x132/0x1c0 [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_itruncate_finish+513/1008] xfs_itruncate_finish+0x201/0x3f0 [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_inactive+1270/1360] xfs_inactive+0x4f6/0x550 [kernel] Dec 12 01:56:22 kingfish kernel: [vn_rele+167/176] vn_rele+0xa7/0xb0 [kernel] Dec 12 01:56:22 kingfish kernel: [linvfs_clear_inode+25/48] linvfs_clear_inode+0x19/0x30 [kernel] Dec 12 01:56:22 kingfish kernel: [clear_inode+261/320] clear_inode+0x105/0x140 [kernel] Dec 12 01:56:22 kingfish kernel: [iput+214/736] iput+0xd6/0x2e0 [kernel] Dec 12 01:56:22 kingfish kernel: [vfs_unlink+395/640] vfs_unlink+0x18b/0x280 [kernel] Dec 12 01:56:22 kingfish kernel: [nfsd_unlink+285/576] nfsd_unlink+0x11d/0x240 [kernel] Dec 12 01:56:22 kingfish kernel: [nfsd3_proc_remove+132/272] nfsd3_proc_remove+0x84/0x110 [kernel] Dec 12 01:56:22 kingfish kernel: [nfs3svc_decode_diropargs+134/240] nfs3svc_decode_diropargs+0x86/0xf0 [kernel] Dec 12 01:56:22 kingfish kernel: [nfsd_dispatch+204/485] nfsd_dispatch+0xcc/0x1e5 [kernel] Dec 12 01:56:22 kingfish kernel: [nfsd_dispatch+0/485] nfsd_dispatch+0x0/0x1e5 [kernel] Dec 12 01:56:22 kingfish kernel: [svc_process+853/1360] svc_process+0x355/0x600 [kernel] Dec 12 01:56:22 kingfish kernel: [nfsd+495/832] nfsd+0x1ef/0x340 [kernel] Dec 12 01:56:22 kingfish kernel: [arch_kernel_thread+46/64] arch_kernel_thread+0x2e/0x40 [kernel] Dec 12 01:56:22 kingfish kernel: [nfsd+0/832] nfsd+0x0/0x340 [kernel] Dec 12 01:56:22 kingfish kernel: xfs_force_shutdown(sd(8,48),0x8) called from line 4049 of file xfs_bmap.c. Return address = 0xc0223ad8 The recovery upon reboot: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1634 of file xfs_alloc.c. Caller 0xc01bcbfa f6af1bac f6af1c08 c01bbb60 c03259af 00000001 00000000 c03259a3 00000662 c01bcbfa 00000000 00000001 f62b1c00 f689fe8c 000a8d43 0000000d 00000001 000a8ce0 00000030 00000000 00000001 00000000 f68abc50 f68b4e98 f6af1c80 Call Trace: [] xfs_free_ag_extent+0x420/0x710 [kernel] [] xfs_free_extent+0xba/0xe0 [kernel] [] xfs_free_extent+0xba/0xe0 [kernel] [] xfs_efd_init+0x7c/0x7e [kernel] [] xfs_trans_get_efd+0x36/0x50 [kernel] [] xlog_recover_process_efi+0x186/0x1f0 [kernel] [] xlog_recover_process_efis+0x77/0x90 [kernel] [] xfs_iget+0x143/0x1a0 [kernel] [] xlog_recover_finish+0x1d/0x26a [kernel] [] xfs_log_mount_finish+0x2d/0x30 [kernel] [] xfs_mountfs+0x6ac/0xd20 [kernel] [] xfs_ioinit+0x20/0x40 [kernel] [] xfs_mount+0x27d/0x420 [kernel] [] vfs_mount+0x41/0x50 [kernel] [] linvfs_read_super+0x8f/0x270 [kernel] [] alloc_super+0x3d/0x1b0 [kernel] [] get_sb_bdev+0x18e/0x290 [kernel] [] alloc_vfsmnt+0x98/0xe0 [kernel] [] do_kern_mount+0x11f/0x130 [kernel] [] do_add_mount+0x74/0x160 [kernel] [] path_lookup+0x3a/0x40 [kernel] [] do_mount+0x130/0x180 [kernel] [] copy_mount_options+0x5d/0xb0 [kernel] [] sys_mount+0xb6/0x120 [kernel] [] system_call+0x33/0x38 [kernel] Ending XFS recovery on filesystem: sd(8,48) (dev: 8/48) Best regards, Leroy van Logchem The Netherlands WL | delft hydraulics From owner-linux-xfs@oss.sgi.com Fri Dec 12 04:12:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Dec 2003 04:13:10 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBCCCiTa003715 for ; Fri, 12 Dec 2003 04:12:44 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBCCCivW003676 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 04:12:44 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBCCCgTc003510 for ; Fri, 12 Dec 2003 04:12:42 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBCBuq6Y001345; Fri, 12 Dec 2003 03:56:52 -0800 Date: Fri, 12 Dec 2003 03:56:52 -0800 Message-Id: <200312121156.hBCBuq6Y001345@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 296] New: Kernel 2.4.22 xfs_force_shutdown line 4049 of file xfs_bmap.c X-Bugzilla-Reason: AssignedTo X-archive-position: 1392 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 7157 Lines: 171 http://oss.sgi.com/bugzilla/show_bug.cgi?id=296 Summary: Kernel 2.4.22 xfs_force_shutdown line 4049 of file xfs_bmap.c Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: leroy.vanlogchem@wldelft.nl We have been using XFS on semi-large servers the last 2.5 years [ 2 x 600 GB ] With that in mind we have bought two large servers with general specs: - 24 x 250 GB disks (leaving 4.5 TB netto when using RAID5+2hotspare) - 2 x 3Ware hardware RAID controllers - 6 GB ram - Dual CPU on TYAN mainboard - Debian 3 using 2.4.22 with XFS patches Main purpose is serving NFS v3 and some Samba v3 to >300 users. The total amount of files exceeds 5 milion, most of them are below 1 MB. Loadavg on a normal working day varies between 0.5 <-> 2, which seems quite good & low to me. The servers are running for 2 weeks now but last night one 1.1 TB partition went down -xfs_force_shutdown(sd(8,48),0x8)-. I couldnt umount it so I had to reboot the server. Not a single sign of hardware error messages from the raid drivers. The partitions are mkfs'ed using: mkfs -V -t xfs -f -d su=65536,sw=8 /dev/sdd Logfiles and various info follows: /proc/partitions major minor #blocks name rio rmerge rsect ruse wio wmerge wsect wuse running use aveq 8 0 976790016 sda 3097 15187 146001 155810 6292 94489 804001 265190 0 66830 421000 8 16 1220987520 sdb 33 76 649 180 3 62 513 70 0 250 250 8 32 976790016 sdc 274 76 2521 2450 4 63 529 40 0 2490 2490 8 48 1220987520 sdd 9456 174151 1468331 1372750 4402 42143 367990 505730 0 232020 1878480 /proc/interrupts 26: 357 13379 IO-APIC-level 3ware Storage Controller 27: 132 9000 IO-APIC-level 3ware Storage Controller Elevators optimized for writing are: /dev/sd[a-d] elevator ID 8 read_latency: 32 write_latency: 8192 /proc/version Linux version 2.4.22-xfs (root@kingfish) (gcc version 3.3.2 (Debian)) #12 SMP Thu Nov 27 17:34:34 CET 2003 xfs_info /dev/sdd meta-data=/storage/sdd isize=256 agcount=292, agsize=1048560 blks = sectsz=512 data = bsize=4096 blocks=305246880, imaxpct=25 = sunit=16 swidth=128 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 /var/log/messages Dec 12 01:54:58 kingfish -- MARK -- Dec 12 01:56:22 kingfish kernel: f6bd7c68 f6bd7cc4 c01bbb60 c03259af 00000001 00000000 c03259a3 00000662 Dec 12 01:56:22 kingfish kernel: c01bcbfa 00000000 00000001 f707cc00 f4aaeeac 000a8d43 0000000d 00000001 Dec 12 01:56:22 kingfish kernel: 000a8ce0 00000030 00000000 00000001 00000000 ee73dd10 00000000 f6bd7d3c Dec 12 01:56:22 kingfish kernel: Call Trace: Dec 12 01:56:22 kingfish kernel: [xfs_free_ag_extent+1056/1808] xfs_free_ag_extent+0x420/0x710 [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_free_extent+186/224] xfs_free_extent+0xba/0xe0 [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_free_extent+186/224] xfs_free_extent+0xba/0xe0 [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_efd_init+124/126] xfs_efd_init+0x7c/0x7e [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_trans_get_efd+54/80] xfs_trans_get_efd+0x36/0x50 [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_bmap_finish+306/448] xfs_bmap_finish+0x132/0x1c0 [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_itruncate_finish+513/1008] xfs_itruncate_finish+0x201/0x3f0 [kernel] Dec 12 01:56:22 kingfish kernel: [xfs_inactive+1270/1360] xfs_inactive+0x4f6/0x550 [kernel] Dec 12 01:56:22 kingfish kernel: [vn_rele+167/176] vn_rele+0xa7/0xb0 [kernel] Dec 12 01:56:22 kingfish kernel: [linvfs_clear_inode+25/48] linvfs_clear_inode+0x19/0x30 [kernel] Dec 12 01:56:22 kingfish kernel: [clear_inode+261/320] clear_inode+0x105/0x140 [kernel] Dec 12 01:56:22 kingfish kernel: [iput+214/736] iput+0xd6/0x2e0 [kernel] Dec 12 01:56:22 kingfish kernel: [vfs_unlink+395/640] vfs_unlink+0x18b/0x280 [kernel] Dec 12 01:56:22 kingfish kernel: [nfsd_unlink+285/576] nfsd_unlink+0x11d/0x240 [kernel] Dec 12 01:56:22 kingfish kernel: [nfsd3_proc_remove+132/272] nfsd3_proc_remove+0x84/0x110 [kernel] Dec 12 01:56:22 kingfish kernel: [nfs3svc_decode_diropargs+134/240] nfs3svc_decode_diropargs+0x86/0xf0 [kernel] Dec 12 01:56:22 kingfish kernel: [nfsd_dispatch+204/485] nfsd_dispatch+0xcc/0x1e5 [kernel] Dec 12 01:56:22 kingfish kernel: [nfsd_dispatch+0/485] nfsd_dispatch+0x0/0x1e5 [kernel] Dec 12 01:56:22 kingfish kernel: [svc_process+853/1360] svc_process+0x355/0x600 [kernel] Dec 12 01:56:22 kingfish kernel: [nfsd+495/832] nfsd+0x1ef/0x340 [kernel] Dec 12 01:56:22 kingfish kernel: [arch_kernel_thread+46/64] arch_kernel_thread+0x2e/0x40 [kernel] Dec 12 01:56:22 kingfish kernel: [nfsd+0/832] nfsd+0x0/0x340 [kernel] Dec 12 01:56:22 kingfish kernel: xfs_force_shutdown(sd(8,48),0x8) called from line 4049 of file xfs_bmap.c. Return address = 0xc0223ad8 The recovery upon reboot: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1634 of file xfs_alloc.c. Caller 0xc01bcbfa f6af1bac f6af1c08 c01bbb60 c03259af 00000001 00000000 c03259a3 00000662 c01bcbfa 00000000 00000001 f62b1c00 f689fe8c 000a8d43 0000000d 00000001 000a8ce0 00000030 00000000 00000001 00000000 f68abc50 f68b4e98 f6af1c80 Call Trace: [] xfs_free_ag_extent+0x420/0x710 [kernel] [] xfs_free_extent+0xba/0xe0 [kernel] [] xfs_free_extent+0xba/0xe0 [kernel] [] xfs_efd_init+0x7c/0x7e [kernel] [] xfs_trans_get_efd+0x36/0x50 [kernel] [] xlog_recover_process_efi+0x186/0x1f0 [kernel] [] xlog_recover_process_efis+0x77/0x90 [kernel] [] xfs_iget+0x143/0x1a0 [kernel] [] xlog_recover_finish+0x1d/0x26a [kernel] [] xfs_log_mount_finish+0x2d/0x30 [kernel] [] xfs_mountfs+0x6ac/0xd20 [kernel] [] xfs_ioinit+0x20/0x40 [kernel] [] xfs_mount+0x27d/0x420 [kernel] [] vfs_mount+0x41/0x50 [kernel] [] linvfs_read_super+0x8f/0x270 [kernel] [] alloc_super+0x3d/0x1b0 [kernel] [] get_sb_bdev+0x18e/0x290 [kernel] [] alloc_vfsmnt+0x98/0xe0 [kernel] [] do_kern_mount+0x11f/0x130 [kernel] [] do_add_mount+0x74/0x160 [kernel] [] path_lookup+0x3a/0x40 [kernel] [] do_mount+0x130/0x180 [kernel] [] copy_mount_options+0x5d/0xb0 [kernel] [] sys_mount+0xb6/0x120 [kernel] [] system_call+0x33/0x38 [kernel] Ending XFS recovery on filesystem: sd(8,48) (dev: 8/48) Best regards, Leroy van Logchem The Netherlands WL | delft hydraulics ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Dec 12 08:21:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Dec 2003 08:21:33 -0800 (PST) Received: from smtp3.cern.ch (smtp3.cern.ch [137.138.131.164]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBCGLKTa001990 for ; Fri, 12 Dec 2003 08:21:21 -0800 Received: from pcitadc13.cern.ch (pcitadc13.cern.ch [137.138.41.226]) by smtp3.cern.ch (8.12.1-20030924/8.12.1) with ESMTP id hBCGLB2Q005762 for ; Fri, 12 Dec 2003 17:21:11 +0100 (MET) Received: by pcitadc13.cern.ch (Postfix, from userid 32266) id 9CF2A1B91F; Fri, 12 Dec 2003 17:21:11 +0100 (CET) Date: Fri, 12 Dec 2003 17:21:11 +0100 From: KELEMEN Peter To: linux-xfs@oss.sgi.com Subject: XFS internal error xfs_alloc_read_agf at line 2207 of file xfs_alloc.c Message-ID: <20031212162111.GF26765@chihiro.cern.ch> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/EE4C26E8 2000-03-20 X-GPG-Fingerprint: D402 4AF3 7488 165B CC34 4147 7F0C D922 EE4C 26E8 X-PGP-KeyID: 1024/45F83E45 1998/04/04 X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD 6D AA B5 8A D6 03 0F BF X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.4i X-MIME-Autoconverted: from 8bit to quoted-printable by smtp3.cern.ch id hBCGLB2Q005762 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hBCGLMTa001999 X-archive-position: 1393 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: linux-xfs Content-Length: 10477 Lines: 187 Hello, I started seeing the following on production nodes with XFS 1.3.1 (RedHat 7.3 gcc-2.96-113), as I recall there has been reports of the same internal error on 2.6.0-testX sometime in October: 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,32)": XFS internal error xfs_alloc_read_agf at line 2207 of file xfs_alloc.c. Caller 0xf889f850 f7fffa70 f88c98e8 00000001 e6259d80 c1ef6000 f88c99ea f89159db 00000001 c1ef6000 f891599d 0000089f f889f850 00000000 f889fa3f f89159db 00000001 c1ef6000 f77e4200 f891599d 0000089f f889f850 e6259d80 e5b3fc70 f77e0c00 Call Trace: [] xfs_error_report [xfs] 0x58 (0xf7fffa74)) [] xfs_corruption_error [xfs] 0x3a (0xf7fffa84)) [] .rodata.str1.1 [xfs] 0x5b (0xf7fffa88)) [] .rodata.str1.1 [xfs] 0x1d (0xf7fffa94)) [] xfs_alloc_pagf_init [xfs] 0x20 (0xf7fffa9c)) [] xfs_alloc_read_agf [xfs] 0xef (0xf7fffaa4)) [] .rodata.str1.1 [xfs] 0x5b (0xf7fffaa8)) [] .rodata.str1.1 [xfs] 0x1d (0xf7fffab8)) [] xfs_alloc_pagf_init [xfs] 0x20 (0xf7fffac0)) [] xfs_alloc_pagf_init [xfs] 0x20 (0xf7fffad8)) [] xfs_bmap_alloc [xfs] 0xb98 (0xf7fffaf8)) [] xfs_bmbt_get_state [xfs] 0x1c (0xf7fffb54)) [] xfs_bmap_do_search_extents [xfs] 0x344 (0xf7fffb64)) [] xfs_bmap_search_extents [xfs] 0x48 (0xf7fffbac)) [] xfs_bmapi [xfs] 0x34d (0xf7fffbd8)) [] xfs_bmapi [xfs] 0x73d (0xf7fffbf4)) [] xfs_bmap_do_search_extents [xfs] 0x344 (0xf7fffc04)) [] xfs_log_reserve [xfs] 0x86 (0xf7fffca8)) [] xfs_trans_reserve [xfs] 0x60 (0xf7fffce0)) [] xfs_bmap_last_offset [xfs] 0xd0 (0xf7fffce4)) [] xfs_iomap_write_allocate [xfs] 0x287 (0xf7fffcfc)) [] scsi_io_completion_Rsmp_29cadfa3 [scsi_mod] 0x1fa (0xf7fffd88)) [] xfs_iomap [xfs] 0x20a (0xf7fffd9c)) [] xfs_iomap [xfs] 0x31e (0xf7fffdc0)) [] xfs_bmap [xfs] 0x2d (0xf7fffe1c)) [] map_blocks [xfs] 0x7f (0xf7fffe3c)) [] page_state_convert [xfs] 0x23c (0xf7fffe74)) [] generic_make_request [kernel] 0x10a (0xf7fffee4)) [] linvfs_writepage [xfs] 0xc0 (0xf7ffff08)) [] write_some_buffers [kernel] 0xb3 (0xf7ffff38)) [] bdflush [kernel] 0xab (0xf7ffffdc)) [] stext [kernel] 0x0 (0xf7ffffec)) [] arch_kernel_thread [kernel] 0x26 (0xf7fffff0)) [] bdflush [kernel] 0x0 (0xf7fffff8)) 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,32)": XFS internal error xfs_alloc_read_agf at line 2207 of file xfs_alloc.c. Caller 0xf889f850 f7fffa70 f88c98e8 00000001 e6259d80 c1ef6000 f88c99ea f89159db 00000001 c1ef6000 f891599d 0000089f f889f850 00000000 f889fa3f f89159db 00000001 c1ef6000 f77e4200 f891599d 0000089f f889f850 e6259d80 e5b3fc70 f77e0c00 Call Trace: [] xfs_error_report [xfs] 0x58 (0xf7fffa74)) [] xfs_corruption_error [xfs] 0x3a (0xf7fffa84)) [] .rodata.str1.1 [xfs] 0x5b (0xf7fffa88)) [] .rodata.str1.1 [xfs] 0x1d (0xf7fffa94)) [] xfs_alloc_pagf_init [xfs] 0x20 (0xf7fffa9c)) [] xfs_alloc_read_agf [xfs] 0xef (0xf7fffaa4)) [] .rodata.str1.1 [xfs] 0x5b (0xf7fffaa8)) [] .rodata.str1.1 [xfs] 0x1d (0xf7fffab8)) [] xfs_alloc_pagf_init [xfs] 0x20 (0xf7fffac0)) [] xfs_alloc_pagf_init [xfs] 0x20 (0xf7fffad8)) [] xfs_bmap_alloc [xfs] 0xb98 (0xf7fffaf8)) [] xfs_bmbt_get_state [xfs] 0x1c (0xf7fffb54)) [] xfs_bmap_do_search_extents [xfs] 0x344 (0xf7fffb64)) [] xfs_bmap_search_extents [xfs] 0x48 (0xf7fffbac)) [] xfs_bmapi [xfs] 0x34d (0xf7fffbd8)) [] xfs_bmapi [xfs] 0x73d (0xf7fffbf4)) [] xfs_bmap_do_search_extents [xfs] 0x344 (0xf7fffc04)) [] xfs_log_reserve [xfs] 0x86 (0xf7fffca8)) [] xfs_trans_reserve [xfs] 0x60 (0xf7fffce0)) [] xfs_bmap_last_offset [xfs] 0xd0 (0xf7fffce4)) [] xfs_iomap_write_allocate [xfs] 0x287 (0xf7fffcfc)) [] scsi_io_completion_Rsmp_29cadfa3 [scsi_mod] 0x1fa (0xf7fffd88)) [] xfs_iomap [xfs] 0x20a (0xf7fffd9c)) [] xfs_iomap [xfs] 0x31e (0xf7fffdc0)) [] xfs_bmap [xfs] 0x2d (0xf7fffe1c)) [] map_blocks [xfs] 0x7f (0xf7fffe3c)) [] page_state_convert [xfs] 0x23c (0xf7fffe74)) [] generic_make_request [kernel] 0x10a (0xf7fffee4)) [] linvfs_writepage [xfs] 0xc0 (0xf7ffff08)) [] write_some_buffers [kernel] 0xb3 (0xf7ffff38)) [] bdflush [kernel] 0xab (0xf7ffffdc)) [] stext [kernel] 0x0 (0xf7ffffec)) [] arch_kernel_thread [kernel] 0x26 (0xf7fffff0)) [] bdflush [kernel] 0x0 (0xf7fffff8)) 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,32)": XFS internal error xfs_alloc_read_agf at line 2207 of file xfs_alloc.c. Caller 0xf889f850024d>] xfs_bmapi [xfs] 0x73d (0xf7fffbf4)) [] xfs_bmap_do_search_extents [xfs] 0x344 (0xf7fffc04)) [] xfs_log_reserve [xfs] 0x86 (0xf7fffca8)) [] xfs_trans_reserve [xfs] 0x60 (0xf7fffce0)) [] xfs_bmap_last_offset [xfs] 0xd0 (0xf7fffce4)) [] xfs_iomap_write_allocate [xfs] 0x287 (0xf7fffcfc)) [] do_IRQ [kernel] 0x100 (0xf7fffd5c)) [] xfs_iomap [xfs] 0x20a (0xf7fffd9c)) [] xfs_iomap [xfs] 0x31e (0xf7fffdc0)) [] xfs_bmap [xfs] 0x2d (0xf7fffe1c)) [] map_blocks [xfs] 0x7f (0xf7fffe3c)) [] page_state_convert [xfs] 0x23c (0xf7fffe74)) [] generic_make_request [kernel] 0x10a (0xf7fffee4)) [] linvfs_writepage [xfs] 0xc0 (0xf7ffff08)) [] write_some_buffers [kernel] 0xb3 (0xf7ffff38)) [] bdflush [kernel] 0xab (0xf7ffffdc)) [] stext [kernel] 0x0 (0xf7ffffec)) [] arch_kernel_thread [kernel] 0x26 (0xf7fffff0)) [] bdflush [kernel] 0x0 (0xf7fffff8)) 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,32)": XFS internal error xfs_alloc_read_agf at line 2207 of file xfs_alloc.c. Caller 0xf889f850 f7fffa70 f88c98e8 00000001 e6259d80 c1ef6000 f88c99ea f89159db 00000001 c1ef6000 f891599d 0000089f f889f850 00000000 f889fa3f f89159db 00000001 c1ef6000 f77e4200 f891599d 0000089f f889f850 e6259d80 e5b3fc70 f77e0c00 Call Trace: [] xfs_error_report [xfs] 0x58 (0xf7fffa74)) [] xfs_corruption_error [xfs] 0x3a (0xf7fffa84)) [] .rodata.str1.1 [xfs] 0x5b (0xf7fffa88)) [] .rodata.str1.1 [xfs] 0x1d (0xf7fffa94)) [] xfs_alloc_pagf_init [xfs] 0x20 (0xf7fffa9c)) [] xfs_alloc_read_agf [xfs] 0xef (0xf7fffaa4)) [] .rodata.str1.1 [xfs] 0x5b (0xf7fffaa8)) [] .rodata.str1.1 [xfs] 0x1d (0xf7fffab8)) [] xfs_alloc_pagf_init [xfs] 0x20 (0xf7fffac0)) [] xfs_alloc_pagf_init [xfs] 0x20 (0xf7fffad8)) [] xfs_bmap_alloc [xfs] 0xb98 (0xf7fffaf8)) [] xfs_bmbt_get_state [xfs] 0x1c (0xf7fffb54)) [] xfs_bmap_do_search_extents [xfs] 0x344 (0xf7fffb64)) [] xfs_bmap_search_extents [xfs] 0x48 (0xf7fffbac)) [] xfs_bmapi [xfs] 0x34d (0xf7fffbd8)) [] xfs_bmapi [xfs] 0x73d (0xf7fffbf4)) [] xfs_bmap_do_search_extents [xfs] 0x344 (0xf7fffc04)) [] xfs_log_reserve [xfs] 0x86 (0xf7fffca8)) [] xfs_trans_reserve [xfs] 0x60 (0xf7fffce0)) [] xfs_bmap_last_offset [xfs] 0xd0 (0xf7fffce4)) [] xfs_iomap_write_allocate [xfs] 0x287 (0xf7fffcfc)) [] do_IRQ [kernel] 0x100 (0xf7fffd5c)) [] xfs_iomap [xfs] 0x20a (0xf7fffd9c)) [] xfs_iomap [xfs] 0x31e (0xf7fffdc0)) [] xfs_bmap [xfs] 0x2d (0xf7fffe1c)) [] map_blocks [xfs] 0x7f (0xf7fffe3c)) [] page_state_convert [xfs] 0x23c (0xf7fffe74)) [] generic_make_request [kernel] 0x10a (0xf7fffee4)) [] linvfs_writepage [xfs] 0xc0 (0xf7ffff08)) [] write_some_buffers [kernel] 0xb3 (0xf7ffff38)) [] bdflush [kernel] 0xab (0xf7ffffdc)) [] stext [kernel] 0x0 (0xf7ffffec)) [] arch_kernel_thread [kernel] 0x26 (0xf7fffff0)) [] bdflush [kernel] 0x0 (0xf7fffff8)) 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "sd(8,32)": XFS internal error xfs_alloc_read_agf at line 2207 of file xfs_alloc.c. Caller 0xf889f850 f7fffa70 f88c98e8 00000001 e6259d80 c1ef6000 f88c99ea f89159db 00000001 c1ef6000 f891599d 0000089f f889f850 00000000 f889fa3f f89159db 00000001 c1ef6000 f77e4200 f891599d 0000089f f889f850 e6259d80 e5b3fc70 f77e0c00 Call Trace: [] xfs_error_report [xfs] 0x58 (0xf7fffa74)) [] xfs_corruption_error [xfs] 0x3a (0xf7fffa84)) [] .rodata.str1.1 [xfs] 0x5b (0xf7fffa8pagf_init [xfs] 0x20 (0xf7fffad8)) [] xfs_bmap_alloc [xfs] 0xb98 (0xf7fffaf8)) [] xfs_bmbt_get_state [xfs] 0x1c (0xf7fffb54)) [] xfs_bmap_do_search_extents [xfs] 0x344 (0xf7fffb64)) [] xfs_bmap_search_extents [xfs] 0x48 (0xf7fffbac)) [] xfs_bmapi [xfs] 0x34d (0xf7fffbd8)) [] xfs_bmapi [xfs] 0x73d (0xf7fffbf4)) [] xfs_bmap_do_search_extents [xfs] 0x344 (0xf7fffc04)) [] xfs_log_reserve [xfs] 0x86 (0xf7fffca8)) [] xfs_trans_reserve [xfs] 0x60 (0xf7fffce0)) [] xfs_bmap_last_offset [xfs] 0xd0 (0xf7fffce4)) [] xfs_iomap_write_allocate [xfs] 0x287 (0xf7fffcfc)) [] do_IRQ [kernel] 0x100 (0xf7fffd5c)) [] xfs_iomap [xfs] 0x20a (0xf7fffd9c)) [] xfs_iomap [xfs] 0x31e (0xf7fffdc0)) [] xfs_bmap [xfs] 0x2d (0xf7fffe1c)) [] map_blocks [xfs] 0x7f (0xf7fffe3c)) [] page_state_convert [xfs] 0x23c (0xf7fffe74)) [] generic_make_request [kernel] 0x10a (0xf7fffee4)) [] linvfs_writepage [xfs] 0xc0 (0xf7ffff08)) [] write_some_buffers [kernel] 0xb3 (0xf7ffff38)) [] bdflush [kernel] 0xab (0xf7ffffdc)) [] stext [kernel] 0x0 (0xf7ffffec)) [] arch_kernel_thread [kernel] 0x26 (0xf7fffff0)) [] bdflush [kernel] 0x0 (0xf7fffff8)) Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs@oss.sgi.com Fri Dec 12 10:12:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Dec 2003 10:13:05 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBCICjTa009061 for ; Fri, 12 Dec 2003 10:12:45 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBCICjNJ009059 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 10:12:45 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBCIChTc009031 for ; Fri, 12 Dec 2003 10:12:43 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBCHTsYl006674; Fri, 12 Dec 2003 09:29:54 -0800 Date: Fri, 12 Dec 2003 09:29:54 -0800 Message-Id: <200312121729.hBCHTsYl006674@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 296] Kernel 2.4.22 xfs_force_shutdown line 4049 of file xfs_bmap.c X-Bugzilla-Reason: AssignedTo X-archive-position: 1395 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 358 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=296 ------- Additional Comments From sandeen@sgi.com 2003-12-12 09:29 PDT ------- We might need to add some extra diagnostic messages to this error path, too, to get more info next time. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Dec 12 10:12:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Dec 2003 10:13:02 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBCICjTa009060 for ; Fri, 12 Dec 2003 10:12:45 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBCICjCa009058 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 10:12:45 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBCIChTg009031 for ; Fri, 12 Dec 2003 10:12:44 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBCHNhnu006467; Fri, 12 Dec 2003 09:23:43 -0800 Date: Fri, 12 Dec 2003 09:23:43 -0800 Message-Id: <200312121723.hBCHNhnu006467@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 296] Kernel 2.4.22 xfs_force_shutdown line 4049 of file xfs_bmap.c X-Bugzilla-Reason: AssignedTo X-archive-position: 1394 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 947 Lines: 27 http://oss.sgi.com/bugzilla/show_bug.cgi?id=296 ------- Additional Comments From sandeen@sgi.com 2003-12-12 09:23 PDT ------- This is the 2nd time I've seen someone with this problem in the last couple of weeks; however it's a tricky one to diagnose, because it's essentially XFS coming along and noticing something that went wrong previously. Was there anything like the "XFS internal error XFS_WANT_CORRUPTED_GOTO" message on the original shutdown, or did you only see that during log recovery? Is the log still in this state? Getting an image of the log might be helpful. What is happening here is that XFS is trying to free an extent and finds that a portion of that extent is already marked as free. What was the box doing when this happened? It's probably too much to hope for a reproducable test case... :) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Dec 12 12:12:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Dec 2003 12:13:06 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBCKCjTa011379 for ; Fri, 12 Dec 2003 12:12:45 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBCKCj4E011378 for linux-xfs@oss.sgi.com; Fri, 12 Dec 2003 12:12:45 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBCKChTc011364 for ; Fri, 12 Dec 2003 12:12:43 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBCJFPxq010654; Fri, 12 Dec 2003 11:15:25 -0800 Date: Fri, 12 Dec 2003 11:15:25 -0800 Message-Id: <200312121915.hBCJFPxq010654@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 284] Log reservation runs out with bonnie++ X-Bugzilla-Reason: AssignedTo X-archive-position: 1396 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 6761 Lines: 157 http://oss.sgi.com/bugzilla/show_bug.cgi?id=284 ------- Additional Comments From xfs@dgreaves.com 2003-12-12 11:15 PDT ------- I'm using RH7.2 (XFS release) I'm using rsync to backup 1 partition to another (hdg is the target) These are the problems that have occured since upgrading from 2.4.18-4SGI_XFS_1.1 to 2.6.0-test9 I have not applied the patch eric suggested. The drives are not mounted with the ikeep option. Here's additional info asked of others: kernel CONFIG_XFS: CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_POSIX_ACL is not set This is after the xfs_force_shutdown() and before any remount # xfs_info /share/backup/mirror meta-data=/share/backup/mirror isize=256 agcount=19, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=19537040, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=2384, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 # mount -oremount /share/backup/mirror root@willow /usr/src/linux-2.6.0-test11 # ll /share/backup/mirror ?--------- 2053 3367557920 12288 577991275711802121 Jan 1 1970 /share/backup/mirror Eeek root@willow /usr/src/linux-2.6.0-test11 # umount /share/backup/mirror root@willow /usr/src/linux-2.6.0-test11 # mount /share/backup/mirror root@willow /usr/src/linux-2.6.0-test11 # ll /share/backup/mirror/ total 0 drwxr-xr-x 10 root root 148 Dec 11 01:56 ./ drwxr-xr-x 4 root root 33 Nov 6 18:46 ../ drwxr-xr-x 10 root root 140 Nov 7 01:52 yesterday/ drwxr-xr-x 10 root root 140 Nov 7 01:52 yesterday-1/ drwxr-xr-x 10 root root 140 Nov 7 01:52 yesterday-2/ drwxr-xr-x 10 root root 140 Nov 7 01:52 yesterday-3/ drwxr-xr-x 10 root root 140 Nov 7 01:52 yesterday-4/ drwxr-xr-x 10 root root 140 Nov 7 01:52 yesterday-5/ drwxr-xr-x 10 root root 140 Nov 7 01:52 yesterday-6/ drwxr-xr-x 3 root root 19 Dec 12 01:51 yesterday-7/ phew anyway, logs: Dec 2 01:55:12 willow kernel: Filesystem "hdg1": xfs_log_write: reservation ran out. Need to up reservation Dec 2 01:55:12 willow kernel: xfs_force_shutdown(hdg1,0x8) called from line 173 9 of file fs/xfs/xfs_log.c. Return address = 0xc01f023d Dec 2 01:55:12 willow kernel: Filesystem "hdg1": Corruption of in-memory data d etected. Shutting down filesystem: hdg1 Dec 2 01:55:12 willow kernel: Please umount the filesystem, and rectify the pro blem(s) Dec 2 01:55:12 willow kernel: xfs_force_shutdown(hdg1,0x2) called from line 132 1 of file fs/xfs/xfs_log.c. Return address = 0xc01f023d Dec 5 12:30:34 willow kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Dec 5 12:30:34 willow kernel: printing eip: Dec 5 12:30:34 willow kernel: c01c212b Dec 5 12:30:34 willow kernel: *pde = 00000000 Dec 5 12:30:34 willow kernel: Oops: 0002 [#1] Dec 5 12:30:34 willow kernel: CPU: 0 Dec 5 12:30:34 willow kernel: EIP: 0060:[] Not tainted Dec 5 12:30:34 willow kernel: EFLAGS: 00010296 Dec 5 12:30:34 willow kernel: EIP is at xfs_inobt_lookup+0x24b/0x350 Dec 5 12:30:34 willow kernel: eax: ffffffff ebx: 0000000f ecx: 0000000e e dx: 00000000 Dec 5 12:30:34 willow kernel: esi: cd0d1000 edi: 00000000 ebp: 0000000e e sp: c5bb9b5c Dec 5 12:30:34 willow kernel: ds: 007b es: 007b ss: 0068 Dec 5 12:30:34 willow kernel: Process nmbd (pid: 5550, threadinfo=c5bb8000 task =ce2ac6d0) Dec 5 12:30:34 willow kernel: Stack: c13eb6f8 c01aab86 c65cef6c 00000000 000000 06 d0dfc800 00000000 ffffffe4 Dec 5 12:30:34 willow kernel: ffffffff 00000006 00000003 00000001 d05241 60 00000000 0000049c 00000006 Dec 5 12:30:34 willow kernel: d0dfc800 c01bfce7 c65cef30 00000001 c5bb9c 00 00000000 00000000 c5bb9c00 Dec 5 12:30:34 willow kernel: Call Trace: Dec 5 12:30:34 willow kernel: [] xfs_btree_init_cursor+0x36/0x1d0 Dec 5 12:30:34 willow kernel: [] xfs_dialloc+0x2d7/0x990 Dec 5 12:30:34 willow kernel: [] cache_alloc_refill+0x170/0x1c0 Dec 5 12:30:34 willow kernel: [] xfs_ialloc+0x56/0x420 Dec 5 12:30:34 willow kernel: [] xfs_da_buf_make+0x36/0x1f0 Dec 5 12:30:34 willow kernel: [] xfs_dir_ialloc+0x71/0x280 Dec 5 12:30:34 willow kernel: [] xfs_trans_reserve+0xa4/0x180 Dec 5 12:30:34 willow kernel: [] xfs_create+0x30f/0x5b0 Dec 5 12:30:34 willow kernel: [] linvfs_mknod+0x1a8/0x250 Dec 5 12:30:34 willow kernel: [] xfs_dir2_block_lookup+0x1a/0xa0 Dec 5 12:30:34 willow kernel: [] xfs_dir2_lookup+0xc4/0x130 Dec 5 12:30:34 willow kernel: [] __alloc_pages+0xb9/0x320 Dec 5 12:30:34 willow kernel: [] vfs_create+0x71/0xa0 Dec 5 12:30:34 willow kernel: [] __lookup_hash+0x75/0xa0 Dec 5 12:30:34 willow kernel: [] open_namei+0x18c/0x420 Dec 5 12:30:34 willow kernel: [] schedule+0x295/0x4b0 Dec 5 12:30:34 willow kernel: [] filp_open+0x32/0x50 Dec 5 12:30:34 willow kernel: [] sys_open+0x32/0x70 Dec 5 12:30:34 willow kernel: [] syscall_call+0x7/0xb Dec 5 12:30:34 willow kernel: Dec 5 12:30:34 willow kernel: Code: 6c 24 08 04 ff 4c 24 18 0f 89 0e fe ff ff 8 3 7c 24 4c 01 74 Dec 12 01:54:27 willow kernel: Filesystem "hdg1": xfs_log_write: reservation ran out. Need to up reservation Dec 12 01:54:27 willow kernel: xfs_force_shutdown(hdg1,0x8) called from line 173 9 of file fs/xfs/xfs_log.c. Return address = 0xc01f023d Dec 12 01:54:27 willow kernel: Filesystem "hdg1": Corruption of in-memory data d etected. Shutting down filesystem: hdg1 Dec 12 01:54:27 willow kernel: Please umount the filesystem, and rectify the pro blem(s) Dec 12 01:54:27 willow kernel: xfs_force_shutdown(hdg1,0x2) called from line 132 1 of file fs/xfs/xfs_log.c. Return address = 0xc01f023d Since this is occuring reasonably often on a non-critical system I am more than happy to apply changes, report back and try to reproduce crashes *if requested*. For now I'll : a) upgrade to 2.6.0-test11 b) apply the "+ xfs_stack_trace();" patch c) echo 5 > /proc/sys/fs/xfs/error_level d) echo 2 > /proc/sys/fs/xfs/panic_mask But I'm remounting with the ikeep option unless someone mails me to ask me to leave it off :) David ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Dec 12 14:29:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Dec 2003 14:30:01 -0800 (PST) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBCMTmTa025348 for ; Fri, 12 Dec 2003 14:29:49 -0800 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Dec 2003 17:29:43 -0500 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC0924F7@THOR.goeci.com> From: Murthy Kambhampaty To: "'christian.guggenberger@physik.uni-regensburg.de'" , Joshua Schmidlkofer Cc: linux-xfs@oss.sgi.com Subject: RE: sunit, swidth question - mkfs.xfs tuning Date: Fri, 12 Dec 2003 17:29:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 1397 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs Content-Length: 1667 Lines: 55 With RAID-5, each write is, loosely speaking, broken down into five stripes of data, and one stripe for parity, with each stripe going to a separate disk (in RAID-5, parity is rotated among disks, where IIRC RAID-4 uses a dedicated disk for parity). So if want your data to be stripe aligned, you tell mkfs you've that each write is (n -1) stripes wide, where n is the number of disks. HTH > -----Original Message----- > From: Christian Guggenberger > [mailto:christian.guggenberger@physik.uni-regensburg.de] > Sent: Thursday, December 11, 2003 6:15 PM > To: Joshua Schmidlkofer > Cc: linux-xfs@oss.sgi.com > Subject: Re: sunit, swidth question - mkfs.xfs tuning > > > Hi, > > On Wed, 2003-12-10 at 00:23, Joshua Schmidlkofer wrote: > > Howdy, > > WOO HOOO!! On 2.4 inclusion, BTW. (good going!) > > > > An old e-mail from Christian Guggenberger recommends swidth be (n-1) > > disks for RAID5. Is that correct? I have a 66GB volume so I was > > looking at: > > > well, the (n-1)*sunit=swidth thing was suggested by Steve some long > time (sorry I can't find the original message in the archives) - and > that's what I'm using here on several Raid5 setups. > > > Mylex AcceleRAID 170, 6 disks in a RAID 5. (4GB system memory) > > > > mkfs.xfs -d su=64k,sw=5 -l size=32m,sunit=64k -L "data" /dev/... > > > > it looks right for the data-section, but sunit=64k is way too > large for > the logsection. > (the syntax is wrong, too - should be sunit=128, (or su=64k) > as sunit is > given in multplies of 512-byte block units) > > see > http://marc.theaimsgroup.com/?l=linux-xfs&m=104419883023845&w=2 for > more info. > > > Christian > > > > From owner-linux-xfs@oss.sgi.com Fri Dec 12 17:21:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Dec 2003 17:22:13 -0800 (PST) Received: from mail-h12-01.cc.ksu.edu (mail-h12-01.cc.ksu.edu [129.130.12.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBD1LaTa001793 for ; Fri, 12 Dec 2003 17:21:37 -0800 Received: from unix2.cc.ksu.edu (unix2.cc.ksu.edu [129.130.12.4]) by mail-h12-01.cc.ksu.edu (8.12.9/8.12.9) with ESMTP id hBD1LacI012416 for ; Fri, 12 Dec 2003 19:21:36 -0600 (CST) Received: from localhost (matts@localhost) by unix2.cc.ksu.edu (8.11.6+Sun/8.11.6) with ESMTP id hBD1LZ427436 for ; Fri, 12 Dec 2003 19:21:35 -0600 (CST) X-Authentication-Warning: unix2.cc.ksu.edu: matts owned process doing -bs Date: Fri, 12 Dec 2003 19:21:35 -0600 (CST) From: Matt Stegman X-X-Sender: matts@unix2.cc.ksu.edu To: linux-xfs@oss.sgi.com Subject: XFS on Software RAID5 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1398 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matts@ksu.edu Precedence: bulk X-list: linux-xfs Content-Length: 1063 Lines: 26 Hello, I'm testing XFS filesystems on a software RAID5 (SuSE 9.0, kernel 2.4.21-144-athlon). After looking up info about the thousands upon thousands of "raid5: switching cache buffer size, 512 -> 4096" messages I was getting in syslog, I'm trying out what Steve Lord suggested in http://marc.theaimsgroup.com/?l=linux-xfs&m=105613069315201&w=2 ... which is to specify "-s size=4096" with mkfs. Using the sector size of 4096 seems to increase performance on the RAID, especially on sequential reading and writing. and I ran into only one problem, when trying to grow the filesystem while it was under heavy load (four copies of 'cp -a /usr/share /mnt/xfs'). xfs_growfs quit with "XFS_IOC_FSGROWFSDATA xfsctl failed: Input/output error." When growing without load it worked just fine. I've run some bonnie++, tiobench, and custom benchmarks, and seen no other problems. I just thought I'd say that using the 4096 byte sector size seems to help a lot with software RAID5. No more constant flushing of the cache buffer, that's for sure. -- Matt Stegman From owner-linux-xfs@oss.sgi.com Fri Dec 12 20:22:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Dec 2003 20:22:46 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.189.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBD4MWTa025830 for ; Fri, 12 Dec 2003 20:22:33 -0800 Received: from mail.pacrimopen.com (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id 12A917002511; Fri, 12 Dec 2003 20:22:38 -0800 (PST) Received: from UNKNOWN(127.0.0.1), claiming to be "mail.pacrimopen.com" via SMTP by sa-relay.pacrimopen.com, id smtpdhTN9MS; Fri Dec 12 20:22:25 2003 Received: from menion.home (unknown [4.4.175.20]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id DEBA37002511; Fri, 12 Dec 2003 20:22:24 -0800 (PST) Subject: Re: XFS on Software RAID5 From: Joshua Schmidlkofer To: Matt Stegman Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8aDYpVnwqUFtbDT6b2NV" Message-Id: <1071289333.16407.0.camel@menion.home> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 12 Dec 2003 20:22:14 -0800 X-archive-position: 1399 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: menion@asylumwear.com Precedence: bulk X-list: linux-xfs Content-Length: 1643 Lines: 46 --=-8aDYpVnwqUFtbDT6b2NV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2003-12-12 at 17:21, Matt Stegman wrote: > Hello, >=20 > I'm testing XFS filesystems on a software RAID5 (SuSE 9.0, kernel > 2.4.21-144-athlon). After looking up info about the thousands upon > thousands of "raid5: switching cache buffer size, 512 -> 4096" messages I > was getting in syslog, I'm trying out what Steve Lord suggested in > http://marc.theaimsgroup.com/?l=3Dlinux-xfs&m=3D105613069315201&w=3D2 > ... which is to specify "-s size=3D4096" with mkfs. >=20 > Using the sector size of 4096 seems to increase performance on the RAID, > especially on sequential reading and writing. and I ran into only one > problem, when trying to grow the filesystem while it was under heavy load > (four copies of 'cp -a /usr/share /mnt/xfs'). xfs_growfs quit with > "XFS_IOC_FSGROWFSDATA xfsctl failed: Input/output error." When growing > without load it worked just fine. >=20 > I've run some bonnie++, tiobench, and custom benchmarks, and seen no other > problems. I just thought I'd say that using the 4096 byte sector size > seems to help a lot with software RAID5. No more constant flushing of the > cache buffer, that's for sure. So what about hardware RAID5? js --=-8aDYpVnwqUFtbDT6b2NV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/2pP0cweM6t71VHsRAnBoAJ9bGTOSNy2rd7zr/btaCKFpBdjoKQCfX4dm 9Rssabgp0y28cl5AxZJ++8M= =ya5e -----END PGP SIGNATURE----- --=-8aDYpVnwqUFtbDT6b2NV-- From owner-linux-xfs@oss.sgi.com Fri Dec 12 21:22:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Dec 2003 21:23:26 -0800 (PST) Received: from mail-h12-01.cc.ksu.edu (mail-h12-01.cc.ksu.edu [129.130.12.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBD5MvTa027582 for ; Fri, 12 Dec 2003 21:22:58 -0800 Received: from unix2.cc.ksu.edu (unix2.cc.ksu.edu [129.130.12.4]) by mail-h12-01.cc.ksu.edu (8.12.9/8.12.9) with ESMTP id hBD5MucI021866; Fri, 12 Dec 2003 23:22:56 -0600 (CST) Received: from localhost (matts@localhost) by unix2.cc.ksu.edu (8.11.6+Sun/8.11.6) with ESMTP id hBD5Mth05731; Fri, 12 Dec 2003 23:22:55 -0600 (CST) X-Authentication-Warning: unix2.cc.ksu.edu: matts owned process doing -bs Date: Fri, 12 Dec 2003 23:22:55 -0600 (CST) From: Matt Stegman X-X-Sender: matts@unix2.cc.ksu.edu To: Joshua Schmidlkofer cc: linux-xfs@oss.sgi.com Subject: Re: XFS on Software RAID5 In-Reply-To: <1071289333.16407.0.camel@menion.home> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1400 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matts@ksu.edu Precedence: bulk X-list: linux-xfs Content-Length: 522 Lines: 15 On Fri, 12 Dec 2003, Joshua Schmidlkofer wrote: > > So what about hardware RAID5? Well, I imagine it depends on how the controller breaks down I/O. Hardware controllers probably manage to emulate regular hard drives better, and don't have the same problem with caching that Linux software RAID5 does. So I'll bet that this option probably doesn't make much difference for hardware RAID. I can't benchmark that, though - the computers I have with hardware RAID are currently busy doing other things. -- Matt Stegman From owner-linux-xfs@oss.sgi.com Sat Dec 13 10:37:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 13 Dec 2003 10:37:36 -0800 (PST) Received: from ms004msg.fastwebnet.it ([213.140.2.58]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBDIbJTa023536; Sat, 13 Dec 2003 10:37:21 -0800 Received: from [1.24.250.53] (1.24.250.53) by ms004msg.fastwebnet.it (6.7.019) id 3FC203440021F42A; Sat, 13 Dec 2003 19:37:12 +0100 From: Emilio Gargiulo To: linux-kernel@vger.kernel.org Subject: 2.4.24-pre1 hangs with XFS on LVM filesystem full Date: Sat, 13 Dec 2003 19:37:10 +0100 User-Agent: KMail/1.5.4 Cc: owner-xfs@oss.sgi.com, nathans@sgi.com, linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Wx12/e5EqhJPJi+" Message-Id: <200312131937.10987.emiliogargiulo@supereva.it> X-archive-position: 1402 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: emiliogargiulo@supereva.it Precedence: bulk X-list: linux-xfs Content-Length: 45094 Lines: 1661 --Boundary-00=_Wx12/e5EqhJPJi+ Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi There is a severe XFS problem with kernel 2.4.24-pre1. If you try to copy a file in a XFS filesystem on LVM bigger than free spaces, the Linux Box will hang. No messages, no warnings, it just freeze. It happens also if the filesystem was not the root filesystem. The problem is fully reproducible on 2 different computer, an old K6/400MHz and a P4/2,4GHz. If i can do something for address the issue, please tell me. Thanks Emilio Gargiulo --Boundary-00=_Wx12/e5EqhJPJi+ Content-Type: text/plain; charset="iso-8859-15"; name="config-2.4.24-pre1" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="config-2.4.24-pre1" # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set CONFIG_MK6=y # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_HAS_TSC=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_MCE=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_HIGHMEM is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_TSC_DISABLE is not set CONFIG_X86_TSC=y # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_ISA=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set # CONFIG_HOTPLUG_PCI_IBM is not set # CONFIG_HOTPLUG_PCI_ACPI is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # CONFIG_OOM_KILLER is not set CONFIG_PM=y CONFIG_APM=m # CONFIG_APM_IGNORE_USER_SUSPEND is not set CONFIG_APM_DO_ENABLE=y # CONFIG_APM_CPU_IDLE is not set CONFIG_APM_DISPLAY_BLANK=y # CONFIG_APM_RTC_IS_GMT is not set CONFIG_APM_ALLOW_INTS=y # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # ACPI Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_BUS=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SYSTEM=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_ASUS=m CONFIG_ACPI_TOSHIBA=m # CONFIG_ACPI_DEBUG is not set # CONFIG_ACPI_RELAXED_AML is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m CONFIG_PARPORT_SERIAL=m CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_IP22 is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=m CONFIG_ISAPNP=m # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_CISS_MONITOR_THREAD is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # CONFIG_BLK_STATS is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID5=y CONFIG_MD_MULTIPATH=y CONFIG_BLK_DEV_LVM=m # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=m CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_FILTER=y CONFIG_UNIX=m CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_INET_ECN=y CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_UNCLEAN=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_MIRROR=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_NAT_LOCAL=y CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set CONFIG_IPV6=m # # IPv6: Netfilter Configuration # CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_LIMIT=m CONFIG_IP6_NF_MATCH_MAC=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_MULTIPORT=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_MARK=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_AHESP=m CONFIG_IP6_NF_MATCH_LENGTH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_MARK=m CONFIG_KHTTPD=m # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=m CONFIG_IP_SCTP=m # CONFIG_SCTP_ADLER32 is not set CONFIG_SCTP_DBG_MSG=y CONFIG_SCTP_DBG_OBJCNT=y # CONFIG_ATM is not set CONFIG_VLAN_8021Q=m # CONFIG_IPX is not set # CONFIG_ATALK is not set # # Appletalk devices # # CONFIG_DEV_APPLETALK is not set # CONFIG_DECNET is not set CONFIG_BRIDGE=m # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_CSZ=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y # # Network testing # # CONFIG_NET_PKTGEN is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_IDEDISK_STROKE is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_IDEPCI=y # CONFIG_BLK_DEV_GENERIC is not set CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_BLK_DEV_ADMA100 is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_AMD74XX_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_RZ1000 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y CONFIG_BLK_DEV_ATARAID=y # CONFIG_BLK_DEV_ATARAID_PDC is not set # CONFIG_BLK_DEV_ATARAID_HPT is not set CONFIG_BLK_DEV_ATARAID_SII=y # # SCSI support # CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=y # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=y CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_MEGARAID2 is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 # CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SIM710 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m # CONFIG_ETHERTAP is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set CONFIG_NET_VENDOR_3COM=y # CONFIG_EL1 is not set # CONFIG_EL2 is not set # CONFIG_ELPLUS is not set # CONFIG_EL16 is not set # CONFIG_EL3 is not set # CONFIG_3C515 is not set # CONFIG_ELMC is not set # CONFIG_ELMC_II is not set CONFIG_VORTEX=m # CONFIG_TYPHOON is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set CONFIG_HP100=m # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_CS89x0 is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set # CONFIG_EEPRO100 is not set # CONFIG_EEPRO100_PIO is not set CONFIG_E100=y # CONFIG_LNE390 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_SUNDANCE_MMIO is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_RHINE_MMIO is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m # CONFIG_PPPOE is not set CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y CONFIG_SLIP_MODE_SLIP6=y # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y CONFIG_STRIP=m CONFIG_WAVELAN=m CONFIG_ARLAN=m CONFIG_AIRONET4500=m CONFIG_AIRONET4500_NONCS=m # CONFIG_AIRONET4500_PNP is not set CONFIG_AIRONET4500_PCI=y # CONFIG_AIRONET4500_ISA is not set # CONFIG_AIRONET4500_I365 is not set CONFIG_AIRONET4500_PROC=m CONFIG_AIRO=m CONFIG_HERMES=m CONFIG_PLX_HERMES=m CONFIG_TMD_HERMES=m CONFIG_PCI_HERMES=m CONFIG_NET_WIRELESS=y # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # CONFIG_IRDA=m CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m CONFIG_IRDA_ULTRA=y CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y CONFIG_IRDA_DEBUG=y # # Infrared-port device drivers # CONFIG_IRTTY_SIR=m CONFIG_IRPORT_SIR=m CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m CONFIG_GIRBIL_DONGLE=m CONFIG_LITELINK_DONGLE=m # CONFIG_MCP2120_DONGLE is not set CONFIG_OLD_BELKIN_DONGLE=m # CONFIG_ACT200L_DONGLE is not set # CONFIG_MA600_DONGLE is not set CONFIG_USB_IRDA=m CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m # CONFIG_TOSHIBA_OLD is not set CONFIG_TOSHIBA_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_ALI_FIR=m CONFIG_VLSI_FIR=m # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # CONFIG_INPUT=m CONFIG_INPUT_KEYBDEV=m CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_EVDEV=m # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=m # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m CONFIG_LP_CONSOLE=y CONFIG_PPDEV=m # CONFIG_TIPAR is not set # # I2C support # # CONFIG_I2C is not set # # Mice # CONFIG_BUSMOUSE=m CONFIG_ATIXL_BUSMOUSE=m CONFIG_LOGIBUSMOUSE=m CONFIG_MS_BUSMOUSE=m CONFIG_MOUSE=m CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # CONFIG_MK712_MOUSE is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # CONFIG_INPUT_NS558 is not set # CONFIG_INPUT_LIGHTNING is not set # CONFIG_INPUT_PCIGAME is not set # CONFIG_INPUT_CS461X is not set # CONFIG_INPUT_EMU10K1 is not set # CONFIG_INPUT_SERIO is not set # CONFIG_INPUT_SERPORT is not set # CONFIG_INPUT_ANALOG is not set # CONFIG_INPUT_A3D is not set # CONFIG_INPUT_ADI is not set # CONFIG_INPUT_COBRA is not set # CONFIG_INPUT_GF2K is not set # CONFIG_INPUT_GRIP is not set # CONFIG_INPUT_INTERACT is not set # CONFIG_INPUT_TMDC is not set # CONFIG_INPUT_SIDEWINDER is not set # CONFIG_INPUT_IFORCE_USB is not set # CONFIG_INPUT_IFORCE_232 is not set # CONFIG_INPUT_WARRIOR is not set # CONFIG_INPUT_MAGELLAN is not set # CONFIG_INPUT_SPACEORB is not set # CONFIG_INPUT_SPACEBALL is not set # CONFIG_INPUT_STINGER is not set # CONFIG_INPUT_DB9 is not set # CONFIG_INPUT_GAMECON is not set # CONFIG_INPUT_TURBOGRAFX is not set # CONFIG_QIC02_TAPE is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_IPMI_PANIC_EVENT is not set # CONFIG_IPMI_DEVICE_INTERFACE is not set # CONFIG_IPMI_KCS is not set # CONFIG_IPMI_WATCHDOG is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_SCx200_GPIO is not set # CONFIG_AMD_RNG is not set # CONFIG_INTEL_RNG is not set # CONFIG_HW_RANDOM is not set # CONFIG_AMD_PM768 is not set CONFIG_NVRAM=m CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m # CONFIG_AGP_INTEL is not set # CONFIG_AGP_I810 is not set CONFIG_AGP_VIA=y # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD_K8 is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_ALI is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_ATI is not set # # Direct Rendering Manager (XFree86 DRI support) # CONFIG_DRM=y # CONFIG_DRM_OLD is not set CONFIG_DRM_NEW=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_GAMMA is not set CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m # CONFIG_DRM_I810 is not set # CONFIG_DRM_I810_XFREE_41 is not set # CONFIG_DRM_I830 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # CONFIG_QUOTA=y # CONFIG_QFMT_V2 is not set CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BEFS_DEBUG is not set CONFIG_BFS_FS=m CONFIG_EXT3_FS=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_UMSDOS_FS=m CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_JFS_FS=y CONFIG_JFS_DEBUG=y CONFIG_JFS_STATISTICS=y # CONFIG_MINIX_FS is not set CONFIG_VXFS_FS=m CONFIG_NTFS_FS=m # CONFIG_NTFS_RW is not set CONFIG_HPFS_FS=m CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y CONFIG_QNX4FS_FS=m # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set CONFIG_UDF_FS=m # CONFIG_UDF_RW is not set CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set CONFIG_XFS_FS=y CONFIG_XFS_QUOTA=y CONFIG_XFS_RT=y # CONFIG_XFS_TRACE is not set # CONFIG_XFS_DEBUG is not set # # Network File Systems # CONFIG_CODA_FS=m # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_NFS_DIRECTIO is not set # CONFIG_ROOT_NFS is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_TCP=y CONFIG_SUNRPC=m CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set CONFIG_ZISOFS_FS=m # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_EFI_PARTITION is not set CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-15" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=y # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Console drivers # CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y # CONFIG_FB_RIVA is not set # CONFIG_FB_CLGEN is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CYBER2000 is not set CONFIG_FB_VESA=y # CONFIG_FB_VGA16 is not set # CONFIG_FB_HGA is not set CONFIG_VIDEO_SELECT=y # CONFIG_FB_MATROX is not set CONFIG_FB_ATY=m CONFIG_FB_ATY_GX=y CONFIG_FB_ATY_CT=y # CONFIG_FB_ATY_GENERIC_LCD is not set CONFIG_FB_RADEON=m CONFIG_FB_ATY128=m # CONFIG_FB_INTEL is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_VIRTUAL is not set CONFIG_FBCON_ADVANCED=y # CONFIG_FBCON_MFB is not set # CONFIG_FBCON_CFB2 is not set # CONFIG_FBCON_CFB4 is not set CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y # CONFIG_FBCON_AFB is not set # CONFIG_FBCON_ILBM is not set # CONFIG_FBCON_IPLAN2P2 is not set # CONFIG_FBCON_IPLAN2P4 is not set # CONFIG_FBCON_IPLAN2P8 is not set # CONFIG_FBCON_MAC is not set # CONFIG_FBCON_VGA_PLANES is not set # CONFIG_FBCON_VGA is not set # CONFIG_FBCON_HGA is not set # CONFIG_FBCON_FONTWIDTH8_ONLY is not set # CONFIG_FBCON_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Sound # CONFIG_SOUND=m # CONFIG_SOUND_ALI5455 is not set # CONFIG_SOUND_BT878 is not set # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set # CONFIG_MIDI_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set CONFIG_SOUND_ES1371=m # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set # CONFIG_SOUND_FORTE is not set # CONFIG_SOUND_ICH is not set # CONFIG_SOUND_RME96XX is not set # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_MIDI_VIA82CXXX is not set # CONFIG_SOUND_OSS is not set # CONFIG_SOUND_TVMIXER is not set # CONFIG_SOUND_AD1980 is not set # CONFIG_SOUND_WM97XX is not set # # USB support # CONFIG_USB=m CONFIG_USB_DEBUG=y CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set CONFIG_USB_EHCI_HCD=m CONFIG_USB_UHCI=m CONFIG_USB_UHCI_ALT=m CONFIG_USB_OHCI=m CONFIG_USB_SL811HS_ALT=m CONFIG_USB_SL811HS=m CONFIG_USB_AUDIO=m CONFIG_USB_EMI26=m CONFIG_USB_BLUETOOTH=m CONFIG_USB_MIDI=m CONFIG_USB_STORAGE=m CONFIG_USB_STORAGE_DEBUG=y CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_HP8200e=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y CONFIG_USB_HIDDEV=y CONFIG_USB_KBD=m CONFIG_USB_MOUSE=m CONFIG_USB_AIPTEK=m CONFIG_USB_WACOM=m CONFIG_USB_KBTAB=m CONFIG_USB_POWERMATE=m CONFIG_USB_DC2XX=m CONFIG_USB_MDC800=m CONFIG_USB_SCANNER=m CONFIG_USB_MICROTEK=m CONFIG_USB_HPUSBSCSI=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_KAWETH=m CONFIG_USB_CATC=m CONFIG_USB_AX8817X=m CONFIG_USB_CDCETHER=m CONFIG_USB_USBNET=m CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m # CONFIG_USB_SERIAL_DEBUG is not set CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_RIO500=m CONFIG_USB_AUERSWALD=m CONFIG_USB_TIGL=m CONFIG_USB_BRLVGER=m CONFIG_USB_LCD=m # # Support for USB gadgets # # CONFIG_USB_GADGET is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set CONFIG_LOG_BUF_SHIFT=0 # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_TEST=m # # Library routines # CONFIG_CRC32=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_FW_LOADER=m --Boundary-00=_Wx12/e5EqhJPJi+ Content-Type: text/plain; charset="iso-8859-15"; name="dmesg.2.4.24-pre1" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.2.4.24-pre1" le. ACPI: have wakeup address 0xc0001000 On node 0 totalpages: 65536 zone(0): 4096 pages. zone(1): 61440 pages. zone(2): 0 pages. DMI not present. ACPI: Unable to locate RSDP Kernel command line: root=/dev/md1 ro video=vesafb vga=792 mem=262144K No local APIC present or hardware disabled Initializing CPU#0 Detected 400.914 MHz processor. Console: colour dummy device 80x25 Calibrating delay loop... 799.53 BogoMIPS Memory: 255720k/262144k available (2158k kernel code, 6036k reserved, 642k data, 124k init, 0k highmem) Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode cache hash table entries: 16384 (order: 5, 131072 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After generic, caps: 008021bf 808029bf 00000000 00000002 CPU: Common caps: 008021bf 808029bf 00000000 00000002 CPU: AMD-K6(tm) 3D processor stepping 0c Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: AMD K6 ACPI: Subsystem revision 20031002 PCI: PCI BIOS revision 2.10 entry at 0xfb490, last bus=1 PCI: Using configuration type 1 ACPI: System description tables not found ACPI-0084: *** Error: acpi_load_tables: Could not get RSDP, AE_NOT_FOUND ACPI-0134: *** Error: acpi_load_tables: Could not load tables: AE_NOT_FOUND ACPI: Unable to load the System Description Tables PCI: Probing PCI hardware PCI: ACPI tables contain no PCI IRQ routing entries PCI: Probing PCI hardware (bus 00) PCI: Using IRQ router VIA [1106/0596] at 00:07.0 Activating ISA DMA hang workarounds. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd VFS: Disk quotas vdquot_6.5.1 Journalled Block Device driver loaded SGI XFS with realtime, no debug enabled SGI XFS Quota Management subsystem vesafb: framebuffer at 0xe4000000, mapped to 0xd0850000, size 4608k vesafb: mode is 1024x768x24, linelength=3072, pages=13 vesafb: protected mode interface info at c000:49e3 vesafb: scrolling: redraw vesafb: directcolor: size=0:8:8:8, shift=0:16:8:0 Console: switching to colour frame buffer device 128x48 fb0: VESA VGA frame buffer device pty: 256 Unix98 ptys configured Real Time Clock Driver v1.10f RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Intel(R) PRO/100 Network Driver - version 2.3.30-k1 Copyright (c) 2003 Intel Corporation PCI: Found IRQ 5 for device 00:09.0 e100: selftest OK. e100: eth0: Intel(R) PRO/100 Network Connection Hardware receive checksums enabled cpu cycle saver enabled Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 00:07.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c596a (rev 06) IDE UDMA33 controller on pci00:07.1 ide0: BM-DMA at 0xa000-0xa007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xa008-0xa00f, BIOS settings: hdc:DMA, hdd:DMA hda: IC35L120AVVA07-0, ATA DISK drive blk: queue c0409b80, I/O limit 4095Mb (mask 0xffffffff) hdc: IC35L120AVVA07-0, ATA DISK drive blk: queue c0409fd4, I/O limit 4095Mb (mask 0xffffffff) ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: attached ide-disk driver. hda: host protected area => 1 hda: 241254720 sectors (123522 MB) w/1863KiB Cache, CHS=15017/255/63, UDMA(33) hdc: attached ide-disk driver. hdc: host protected area => 1 hdc: 241254720 sectors (123522 MB) w/1863KiB Cache, CHS=239340/16/63, UDMA(33) Partition check: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 hda13 hda14 > hda1: hdc: [PTBL] [15017/255/63] hdc1 hdc2 hdc3 hdc4 < hdc5 hdc6 hdc7 hdc8 hdc9 hdc10 > Guestimating sector 241253695 for superblock Guestimating sector 241253695 for superblock driver for Silicon Image(tm) Medley(tm) hardware version 0.0.1: No raid array found SCSI subsystem driver Revision: 1.00 PCI: Found IRQ 9 for device 00:0c.0 PCI: Sharing IRQ 9 with 00:0a.0 sym.0.12.0: setting PCI_COMMAND_PARITY... sym.0.12.0: setting PCI_COMMAND_INVALIDATE. sym0: <860> rev 0x2 on pci bus 0 device 12 function 0 irq 9 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver sym0: using LOAD/STORE-based firmware. sym0: SCSI BUS has been reset. scsi0 : sym-2.1.17a blk: queue c137b474, I/O limit 4095Mb (mask 0xffffffff) Vendor: ARCHIVE Model: 4326XX 27871-XXX Rev: 0322 Type: Sequential-Access ANSI SCSI revision: 02 blk: queue c137b574, I/O limit 4095Mb (mask 0xffffffff) Vendor: YAMAHA Model: CRW4416S Rev: 1.0j Type: CD-ROM ANSI SCSI revision: 02 blk: queue c137b674, I/O limit 4095Mb (mask 0xffffffff) Vendor: PLEXTOR Model: CD-ROM PX-40TS Rev: 1.05 Type: CD-ROM ANSI SCSI revision: 02 blk: queue c137b774, I/O limit 4095Mb (mask 0xffffffff) st: Version 20030406, bufsize 32768, max init. bufs 4, s/g segs 16 Attached scsi tape st0 at scsi0, channel 0, id 2, lun 0 Attached scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0 Attached scsi CD-ROM sr1 at scsi0, channel 0, id 5, lun 0 sym0:3: FAST-10 SCSI 8.3 MB/s ST (120.0 ns, offset 8) sr0: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.12 sym0:5: FAST-20 SCSI 20.0 MB/s ST (50.0 ns, offset 8) sr1: scsi-1 drive md: linear personality registered as nr 1 md: raid0 personality registered as nr 2 md: raid1 personality registered as nr 3 md: raid5 personality registered as nr 4 raid5: measuring checksumming speed 8regs : 621.600 MB/sec 32regs : 407.600 MB/sec pII_mmx : 887.600 MB/sec p5_mmx : 853.600 MB/sec raid5: using function: pII_mmx (887.600 MB/sec) md: multipath personality registered as nr 7 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. [events: 00002765] [events: 00000bb7] [events: 0000151e] [events: 00002765] [events: 00000bb7] [events: 0000151e] md: autorun ... md: considering hdc9 ... md: adding hdc9 ... md: adding hda9 ... md: created md3 md: bind md: bind md: running: md: hdc9's event counter: 0000151e md: hda9's event counter: 0000151e md: RAID level 1 does not need chunksize! Continuing anyway. md3: max total readahead window set to 124k md3: 1 data-disks, max readahead per data-disk: 124k raid1: device hdc9 operational as mirror 1 raid1: device hda9 operational as mirror 0 raid1: raid set md3 active with 2 out of 2 mirrors md: updating md3 RAID superblock on device md: hdc9 [events: 0000151f]<6>(write) hdc9's sb offset: 4184832 md: hda9 [events: 0000151f]<6>(write) hda9's sb offset: 4184832 md: considering hdc8 ... md: adding hdc8 ... md: adding hda8 ... md: created md2 md: bind md: bind md: running: md: hdc8's event counter: 00000bb7 md: hda8's event counter: 00000bb7 md: RAID level 1 does not need chunksize! Continuing anyway. md2: max total readahead window set to 124k md2: 1 data-disks, max readahead per data-disk: 124k raid1: device hdc8 operational as mirror 1 raid1: device hda8 operational as mirror 0 raid1: raid set md2 active with 2 out of 2 mirrors md: updating md2 RAID superblock on device md: hdc8 [events: 00000bb8]<6>(write) hdc8's sb offset: 4184832 md: hda8 [events: 00000bb8]<6>(write) hda8's sb offset: 4184832 md: considering hdc6 ... md: adding hdc6 ... md: adding hda6 ... md: created md1 md: bind md: bind md: running: md: hdc6's event counter: 00002765 md: hda6's event counter: 00002765 md: RAID level 1 does not need chunksize! Continuing anyway. md1: max total readahead window set to 124k md1: 1 data-disks, max readahead per data-disk: 124k raid1: device hdc6 operational as mirror 0 raid1: device hda6 operational as mirror 1 raid1: raid set md1 active with 2 out of 2 mirrors md: updating md1 RAID superblock on device md: hdc6 [events: 00002766]<6>(write) hdc6's sb offset: 2417664 md: hda6 [events: 00002766]<6>(write) hda6's sb offset: 2417664 md: ... autorun DONE. Initializing Cryptographic API NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 32768) Linux IP multicast router 0.06 plus PIM-SM sh-2021: reiserfs_read_super: can not find reiserfs on md(9,1) Mount JFS Failure: -22 XFS mounting filesystem md(9,1) Ending clean XFS mount for filesystem: md(9,1) VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 124k freed NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Adding Swap: 248968k swap-space (priority -1) Adding Swap: 248968k swap-space (priority -2) LVM version 1.0.7(28/03/2003) module loaded loop: loaded (max 8 devices) kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,5), internal journal EXT3-fs: mounted filesystem with ordered data mode. XFS mounting filesystem md(9,2) Ending clean XFS mount for filesystem: md(9,2) XFS mounting filesystem md(9,3) Ending clean XFS mount for filesystem: md(9,3) reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (device ide1(22,1)) ... for (ide1(22,1)) ide1(22,1):Using r5 hash to sort names NTFS driver v1.1.22 [Flags: R/O MODULE] MSDOS FS: IO charset utf8 XFS mounting filesystem lvm(58,16) Ending clean XFS mount for filesystem: lvm(58,16) XFS mounting filesystem lvm(58,10) Ending clean XFS mount for filesystem: lvm(58,10) reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (device lvm(58,0)) ... for (lvm(58,0)) lvm(58,0):Using r5 hash to sort names XFS mounting filesystem lvm(58,1) Ending clean XFS mount for filesystem: lvm(58,1) XFS mounting filesystem lvm(58,4) Ending clean XFS mount for filesystem: lvm(58,4) XFS mounting filesystem lvm(58,3) Ending clean XFS mount for filesystem: lvm(58,3) XFS mounting filesystem lvm(58,8) Ending clean XFS mount for filesystem: lvm(58,8) XFS mounting filesystem lvm(58,12) Ending clean XFS mount for filesystem: lvm(58,12) XFS mounting filesystem lvm(58,13) Ending clean XFS mount for filesystem: lvm(58,13) XFS mounting filesystem lvm(58,17) Ending clean XFS mount for filesystem: lvm(58,17) XFS mounting filesystem lvm(58,18) Ending clean XFS mount for filesystem: lvm(58,18) XFS mounting filesystem ide1(22,5) Ending clean XFS mount for filesystem: ide1(22,5) reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (device ide0(3,10)) ... for (ide0(3,10)) ide0(3,10):Using r5 hash to sort names reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (device ide0(3,12)) ... for (ide0(3,12)) ide0(3,12):Using r5 hash to sort names reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (device ide0(3,13)) ... for (ide0(3,13)) ide0(3,13):Using r5 hash to sort names XFS mounting filesystem lvm(58,14) Ending clean XFS mount for filesystem: lvm(58,14) apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16) Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 204M agpgart: Detected Via MVP3 chipset agpgart: AGP aperture is 64M @ 0xe0000000 scsi1 : SCSI host adapter emulation for IDE ATAPI devices PCI: Found IRQ 9 for device 00:0a.0 PCI: Sharing IRQ 9 with 00:0c.0 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 00:0a.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xc000. Vers LK1.1.18-ac 00:10:5a:c3:04:06, IRQ 9 product code 5146 rev 00.9 date 11-07-98 Internal config register is 1800000, transceivers 0xa. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 786d. Enabling bus-master transmits and whole-frame receives. 00:0a.0: scatter/gather enabled. h/w checksums enabled usb.c: registered new driver usbdevfs usb.c: registered new driver hub uhci.c: USB Universal Host Controller Interface driver v1.1 uhci.c: USB UHCI at I/O 0xa400, IRQ 10 usb.c: new USB bus registered, assigned bus number 1 uhci.c: detected 2 ports usb.c: kmalloc IF ceed6580, numif 1 usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1 usb.c: USB device number 1 default language ID 0x0 Product: USB UHCI-alt Root Hub SerialNumber: a400 hub.c: USB hub found hub.c: 2 ports detected hub.c: standalone hub hub.c: ganged power switching hub.c: global over-current protection hub.c: Port indicators are not supported hub.c: power on to power good time: 2ms hub.c: hub controller current requirement: 0mA hub.c: port removable status: RR hub.c: local power source is good hub.c: no over-current condition exists hub.c: enabling power on all ports usb.c: hub driver claimed interface ceed6580 usb.c: kusbd: /sbin/hotplug add 1 uhci.c: root-hub INT complete: port1: 48a port2: 58a data: 6 uhci.c: a400: suspend_hc hub.c: port 1, portstatus 100, change 3, 12 Mb/s hub.c: port 1 connection change hub.c: port 1, portstatus 100, change 3, 12 Mb/s hub.c: port 2, portstatus 300, change 3, 1.5 Mb/s hub.c: port 2 connection change hub.c: port 2, portstatus 300, change 3, 1.5 Mb/s uhci.c: root-hub INT complete: port1: 488 port2: 588 data: 6 hub.c: port 1, portstatus 100, change 2, 12 Mb/s hub.c: port 1 enable change, status 100 hub.c: port 2, portstatus 300, change 2, 1.5 Mb/s hub.c: port 2 enable change, status 300 ip_conntrack version 2.1 (2048 buckets, 16384 max) - 292 bytes per conntrack ip_tables: (C) 2000-2002 Netfilter core team sym0:2: FAST-10 SCSI 5.0 MB/s ST (200.0 ns, offset 8) st0: Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1 st0: can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 1, st0: defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 1 st0: sysv: 0 nowait: 0 st0: Default block size set to 0 bytes. st0: Compression default set to 1 st0: Mode 1 options: buffer writes: 1, async writes: 1, read ahead: 1 st0: can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 1, st0: defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 1 st0: sysv: 0 nowait: 0 st0: Default block size set to 1024 bytes. st0: Compression default set to 1 st0: Mode 2 options: buffer writes: 1, async writes: 1, read ahead: 1 st0: can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 1, st0: defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 1 st0: sysv: 0 nowait: 0 st0: Default block size set to 0 bytes. st0: Compression default set to 0 st0: Mode 3 options: buffer writes: 1, async writes: 1, read ahead: 1 st0: can bsr: 1, two FMs: 0, fast mteom: 0, auto lock: 1, st0: defs for wr: 0, no block limits: 0, partitions: 1, s2 log: 1 st0: sysv: 0 nowait: 0 st0: Default block size set to 1024 bytes. st0: Compression default set to 0 [drm] AGP 0.99 Aperture @ 0xe0000000 64MB [drm] Initialized r128 2.2.0 20010917 on minor 0 --Boundary-00=_Wx12/e5EqhJPJi+-- From owner-linux-xfs@oss.sgi.com Sat Dec 13 14:06:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 13 Dec 2003 14:07:10 -0800 (PST) Received: from hotmail.com (law15-f61.law15.hotmail.com [64.4.23.61]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBDM6wTa031063 for ; Sat, 13 Dec 2003 14:06:58 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 13 Dec 2003 14:06:53 -0800 Received: from 211.244.8.224 by lw15fd.law15.hotmail.msn.com with HTTP; Sat, 13 Dec 2003 22:06:52 GMT X-Originating-IP: [211.244.8.224] X-Originating-Email: [yiseungsu@hotmail.com] X-Sender: yiseungsu@hotmail.com From: "Seungsoo Lee" To: linux-xfs@oss.sgi.com Subject: xfs filesystem erased. Date: Sun, 14 Dec 2003 07:06:52 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Dec 2003 22:06:53.0249 (UTC) FILETIME=[6A4A7B10:01C3C1C5] X-archive-position: 1403 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yiseungsu@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 3078 Lines: 94 Hi. Since I have tried to fix the problem for a few day, but I Couldn't . I wrote it briefly below. ------------------------------------------------------------------------------------------------------ 1.detect the problem [root@localhost mntb]# mount -t xfs /dev/hdd1 /home/lss1/lssmnt/mntd mount: wrong fs type, bad option, bad superblock on /dev/hdd1, or too many mounted file systems [root@localhost mntb]# ------------------------------------------------------------------------------------------------------- 2.the trials to rescue this disk ========================================================= Spec: Model: WDC WD1800JB-00DUA0 filesystem type: XFS capacity: 180G My system: RED HAT 9(kernel:SGI 2.4.20-09XFS) ========================================================= I'm useing this disk for backup disk. Abosolutely it contains very important files to me. --------------------------------------------------------------------------------------------------- * In redhat, I check the "hardware browser". Results: /dev/hda hda2 1 255 2000M linux-swap hda1 256 9733 74348M xfs / /dev/hdb hdd1 1 21889 171703M NO filesystem(*) (*) why does the XFS partiions(hdd1) remove? it's originally used in XFS. I didn't format this one. -------------------------------------------------------------------------------------------------- To rescue one. I did it like below. it doesn't work. I don't know exactly why this happens abruptly? ------------------------------------------------------------------------------------------------- [root@localhost sbin]# ./xfs_repair /dev/hdd1 Phase 1 - find and verify superblock... superblock read failed, offset 0, size 524288, ag 4294967295, rval 0 fatal error -- Input/output error [root@localhost sbin]# ./xfs_repair /dev/hdd Phase 1 - find and verify superblock... superblock read failed, offset 0, size 524288, ag 4294967295, rval 0 fatal error -- Input/output error [root@localhost sbin]# ------------------------------------------------------------------------------------------------ * another ways to rescue this disk. 1.partition-rescue-mini-howto. it's not helpful. it's useless to rescue original XFS filesystem. 2.SGI FAQ and Mailing list Archives. There is also no similar case. Around Mar 2003, I have a problem to use XFS. At that time, I report the problem to the XFS team. Through a few communications with xfs team. At that time,I decided there is no bugs in XFS but,the physical harddisk. This case definitely has no problems of this physical hard disk. *is there anyway to repair the corrupted xfs filesystem even if it costs ? *do I have to format this disk? thanks....... from "yiseungsu@hotmail.com" _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Sat Dec 13 21:02:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 13 Dec 2003 21:03:04 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBE52qTa014999 for ; Sat, 13 Dec 2003 21:02:52 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBE6K9m7025846 for ; Sun, 14 Dec 2003 00:20:09 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBE52kSC20289812; Sat, 13 Dec 2003 23:02:46 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBE52cK210231970; Sat, 13 Dec 2003 23:02:38 -0600 (CST) Date: Sat, 13 Dec 2003 23:02:46 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Seungsoo Lee cc: linux-xfs@oss.sgi.com Subject: Re: xfs filesystem erased. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1404 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1211 Lines: 38 On Sun, 14 Dec 2003, Seungsoo Lee wrote: > 1.detect the problem > > [root@localhost mntb]# mount -t xfs /dev/hdd1 /home/lss1/lssmnt/mntd > mount: wrong fs type, bad option, bad superblock on /dev/hdd1, > or too many mounted file systems Unfortunately, this doesn't tell us anything, it is just the generic error from userspace "mount." Looking at "dmesg" output should tell you what really went wrong. > Phase 1 - find and verify superblock... > superblock read failed, offset 0, size 524288, ag 4294967295, rval 0 > > fatal error -- Input/output error > > [root@localhost sbin]# ./xfs_repair /dev/hdd > Phase 1 - find and verify superblock... > superblock read failed, offset 0, size 524288, ag 4294967295, rval 0 > > fatal error -- Input/output error Sounds like a hardware error, if xfs can't even read the disk. Again, look at dmesg output after this happens. > This case definitely has no problems of this physical hard disk. What makes you sure of this? > *is there anyway to repair the corrupted xfs filesystem even if it costs ? > *do I have to format this disk? There are data recovery shops that can try to rescue data from bad disks, if that turns out to be the case. -Eric From owner-linux-xfs@oss.sgi.com Sat Dec 13 21:11:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 13 Dec 2003 21:12:04 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBE5BiTa015512 for ; Sat, 13 Dec 2003 21:11:44 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBE3JGOO028755 for ; Sat, 13 Dec 2003 19:19:16 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBE5BbSC20304405; Sat, 13 Dec 2003 23:11:38 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBE5BTK210300616; Sat, 13 Dec 2003 23:11:29 -0600 (CST) Date: Sat, 13 Dec 2003 23:11:37 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Emilio Gargiulo cc: linux-kernel@vger.kernel.org, Subject: Re: 2.4.24-pre1 hangs with XFS on LVM filesystem full In-Reply-To: <200312131937.10987.emiliogargiulo@supereva.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1108 Lines: 28 So you are seeing a hang when you (over)fill the filesystem, if I understand correctly? If there is any chance that you could test it with XFS to a normal disk (no LVM) or with some other filesystem with LVM, that might help to narrow down the problem. Nightly XFS QA tests do check ENOSPC conditions, but perhaps there is bad interaction with LVM. You could also get a CVS kernel from oss.sgi.com, or apply the KDB patch you your kernel, and enter kdb when the system freezes. Then you could look at backtraces of the relevant processes to get an idea of where things are stuck. -Eric On Sat, 13 Dec 2003, Emilio Gargiulo wrote: > Hi > There is a severe XFS problem with kernel 2.4.24-pre1. If you try to copy a > file in a XFS filesystem on LVM bigger than free spaces, the Linux Box will > hang. No messages, no warnings, it just freeze. It happens also if the > filesystem was not the root filesystem. > The problem is fully reproducible on 2 different computer, an old K6/400MHz > and a P4/2,4GHz. > > If i can do something for address the issue, please tell me. > Thanks > Emilio Gargiulo From owner-linux-xfs@oss.sgi.com Sun Dec 14 02:08:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Dec 2003 02:08:29 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBEA82Ta022727 for ; Sun, 14 Dec 2003 02:08:04 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUAsx-0000rW-00 for ; Wed, 10 Dec 2003 21:24:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUAsw-0000rO-00 for ; Wed, 10 Dec 2003 21:24:38 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AUAsw-0001pC-00 for ; Wed, 10 Dec 2003 21:24:38 +0100 From: "Norman Zhang" Subject: Repairing XFS Date: Wed, 10 Dec 2003 12:24:36 -0800 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1406 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Content-Length: 899 Lines: 27 Hi, I'm seeing some irregulars halts on one of my XFS volume (/srv). I can only use umount -l to dismount the volume or do a hot reboot. Dec 9 15:47:25 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) called from line 1039 of file xfs_trans.c. Return address = 0xe109f312 Dec 9 15:47:25 smbserver kernel: Corruption of in-memory data detected. Shutting down filesystem: md(9,5) Dec 9 15:47:25 smbserver kernel: Please umount the filesystem, and rectify the problem(s) I'm not sure if the disk has problems, but during boot up there's no error found by fsck. The stall sometime occurs in weeks and sometimes few times per day. So I really doubt if this a disk problem. Is there any way I can trace or perhaps fix this? BTW, if I want to manually force a disk check on the XFS volume. Do I just do $ umount -l /srv/ $ fsck.xfs /srv I don't see any actions on the screen. Regards, Norman From owner-linux-xfs@oss.sgi.com Sun Dec 14 08:55:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Dec 2003 08:55:31 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBEGtITa013997 for ; Sun, 14 Dec 2003 08:55:19 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBEF2rOO010830 for ; Sun, 14 Dec 2003 07:02:53 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBEGtCSC20314766; Sun, 14 Dec 2003 10:55:12 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBEGt4K210362714; Sun, 14 Dec 2003 10:55:04 -0600 (CST) Date: Sun, 14 Dec 2003 10:55:12 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Norman Zhang cc: linux-xfs@oss.sgi.com Subject: Re: Repairing XFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1407 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 45 Lines: 4 Use xfs_repair, fsck.xfs is a no-op. -Eric From owner-linux-xfs@oss.sgi.com Sun Dec 14 09:34:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Dec 2003 09:34:34 -0800 (PST) Received: from mail.epost.de (mail.epost.de [193.28.100.187] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBEHY7Ta014758 for ; Sun, 14 Dec 2003 09:34:08 -0800 Received: from epost.de (217.110.232.6) by mail.epost.de (6.7.019) (authenticated as rainer.traut@epost.de) id 3FD5A78700026589; Wed, 10 Dec 2003 11:36:10 +0100 Message-ID: <3FD6F719.7090009@epost.de> Date: Wed, 10 Dec 2003 11:36:09 +0100 From: Rainer Traut User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Brodbelt CC: linux-xfs@oss.sgi.com Subject: Re: XFS filesystem shutdown References: <3FD5ED83.7000500@acu.ac.uk> <1432.10.1.200.117.1071040970.squirrel@imap01.ch.sauter-bc.com> <3FD6F55A.2060707@acu.ac.uk> In-Reply-To: <3FD6F55A.2060707@acu.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1408 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rainer.traut@epost.de Precedence: bulk X-list: linux-xfs Content-Length: 968 Lines: 27 Hi, Mike Brodbelt wrote: >>I'm not an expert for those error messages but I guess it unfortunately a >>hardware error, isn't it? Did you check dmesg output when this happened? > > > That was the dmesg output - not much goes to logs, as they're on /var, > which was the affected filesystem. Things I've seen suggest that this > error can certainly be caused by a hardware problem, but the disk is a > hardware RAID5 array on an ICP controller, which maintains it's own > hardware log of disk problems. I've seen no sign of any problems with > the array, and the controller doesn't show anything that could have > presented an error to the OS layer, so I'm inclined to doubt the > "hardware error" theory at the moment. ICP has a nice tool for managing their Controllers from commandline. icpcon it is called, there are some monitoring options like View Statistics View Events View Hard Disk Info These are all empty and nothing unusual to find in there? Rainer From owner-linux-xfs@oss.sgi.com Sun Dec 14 12:52:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Dec 2003 12:53:25 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBEKqrTa020218 for ; Sun, 14 Dec 2003 12:52:54 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBEMADm7013701 for ; Sun, 14 Dec 2003 16:10:13 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBEKplSC20424080; Sun, 14 Dec 2003 14:51:47 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBEKpdK210387148; Sun, 14 Dec 2003 14:51:39 -0600 (CST) Date: Sun, 14 Dec 2003 14:51:47 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Seungsoo Lee cc: linux-xfs@oss.sgi.com Subject: Re: Linux partitions is good , but XFS couldn't mount.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 7240 Lines: 209 I'm sorry, the only thing I can see that is a problem is: XFS: bad magic number XFS: SB validate failed which means that block 0 of the disk is corrupt. I don't know how this has happened, and there is nothing below to help me figure out what went wrong, perhaps you have filtered too much out of the logs. You can try xfs_repair, it may be able to correct this. -Eric On Sun, 14 Dec 2003, Seungsoo Lee wrote: > Dear, Eric Sandeen > > Hi. I need more help. > > I got messages well. I am surfing the Web to find docs ,Until now I 'm also > testing to restore XFS filesystem. > Before I give up early, this time I have to solve the problem. > > > I used to do to make xfs system. > > let's assume that I attached a hard disk on the secondary slave. > > =================================================== > 1.fdisk /dev/hdd > /dev/hdd1 * 1 21889 171703 Linux (83) > > 2.mkfs -t ext2 /dev/hdd1 > 3.mkfs.xfs -f /dev/hdd1 > ===================================================== > Above ways is used for me. > > (1),(2) is alright. but (3) has problem. It has a problem at mkfs time? > > you asked me why I'm sure that there is no errors in my physical hard disk. > > My disk(hdd) is still alive as "Linux native" but xfs was removed. > > /dev/hdd1 * 1 21889 171703 Linux (83) > > just don't configure the former XFS filesystem. > > If I'm doing mkfs.xfs on this hard disks. Hard disk will survive physically. > But. Data on that will disappear. I'm afraid that. > > > ========================================================================= > [root@localhost sbin]# ./fdisk /dev/hdd > > The number of cylinders for this disk is set to 21889. > There is nothing wrong with that, but this is larger than 1024, > and could in certain setups cause problems with: > 1) software that runs at boot time (e.g., old versions of LILO) > 2) booting and partitioning software from other OSs > (e.g., DOS FDISK, OS/2 FDISK) > > Command (m for help): m > Command action > a toggle a bootable flag > b edit bsd disklabel > c toggle the dos compatibility flag > d delete a partition > l list known partition types > m print this menu > n add a new partition > o create a new empty DOS partition table > p print the partition table > q quit without saving changes > s create a new empty Sun disklabel > t change a partition's system id > u change display/entry units > v verify the partition table > w write table to disk and exit > x extra functionality (experts only) > > Command (m for help): p > > Disk /dev/hdd: 180.0 GB, 180045766656 bytes > 255 heads, 63 sectors/track, 21889 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Boot Start End Blocks Id System > /dev/hdd1 * 1 21889 175823361 83 Linux > ============================================================================ > The real state of my disk.Above > > > > > ======================================================================= > #dmesg: the ones related with XFS. > ------------------------------------ > ............... > > UDF-fs: No VRS found > ISO 9660 Extensions: Microsoft Joliet Level 3 > ISOFS: changing to secondary root > Journalled Block Device driver loaded > kjournald starting. Commit interval 5 seconds > EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,65), internal journal > EXT3-fs: recovery complete. > EXT3-fs: mounted filesystem with ordered data mode. > XFS: bad magic number > XFS: SB validate failed > kjournald starting. Commit interval 5 seconds > EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal > EXT3-fs: mounted filesystem with ordered data mode. > VFS: Can't find ext3 filesystem on dev ide1(22,65). > VFS: Can't find ext2 filesystem on dev ide1(22,65). > XFS: bad magic number > XFS: SB validate failed > XFS: bad magic number > XFS: SB validate failed > kjournald starting. Commit interval 5 seconds > EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal > EXT3-fs: mounted filesystem with ordered data mode. > VFS: Can't find ext3 filesystem on dev sd(8,1). > VFS: Can't find ext3 filesystem on dev sd(8,1). > VFS: Can't find ext3 filesystem on dev sd(8,1). > kjournald starting. Commit interval 5 seconds > EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,0), internal journal > EXT3-fs: mounted filesystem with ordered data mode. > kjournald starting. Commit interval 5 seconds > EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,0), internal journal > EXT3-fs: mounted filesystem with ordered data mode. > VFS: Can't find ext3 filesystem on dev sd(8,1). > XFS mounting filesystem sd(8,1) > Ending clean XFS mount for filesystem: sd(8,1) > kjournald starting. Commit interval 5 seconds > EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,0), internal journal > EXT3-fs: mounted filesystem with ordered data mode. > kjournald starting. Commit interval 5 seconds > EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,0), internal journal > EXT3-fs: mounted filesystem with ordered data mode. > XFS: bad magic number > XFS: SB validate failed > XFS mounting filesystem sd(8,1) > Ending clean XFS mount for filesystem: sd(8,1) > XFS mounting filesystem sd(8,1) > XFS: failed to read root inode > XFS mounting filesystem sd(8,0) > Ending clean XFS mount for filesystem: sd(8,0) > XFS mounting filesystem sd(8,1) > XFS: failed to read root inode > XFS mounting filesystem sd(8,1) > XFS: failed to read root inode > XFS mounting filesystem sd(8,0) > Ending clean XFS mount for filesystem: sd(8,0) > XFS mounting filesystem sd(8,1) > Ending clean XFS mount for filesystem: sd(8,1) > EFSCORRUPTED returned from file xfs_ialloc.c line 1313 > XFS mounting filesystem sd(8,1) > Ending clean XFS mount for filesystem: sd(8,1) > XFS mounting filesystem sd(8,1) > Ending clean XFS mount for filesystem: sd(8,1) > XFS mounting filesystem sd(8,1) > Ending clean XFS mount for filesystem: sd(8,1) > XFS mounting filesystem sd(8,1) > Ending clean XFS mount for filesystem: sd(8,1) > XFS: bad magic number > XFS: SB validate failed > XFS: bad magic number > XFS: SB validate failed > XFS: bad magic number > XFS: SB validate failed > XFS: bad magic number > XFS: SB validate failed > XFS: bad magic number > XFS: SB validate failed > XFS: bad magic number > XFS: SB validate failed > XFS: bad magic number > XFS: SB validate failed > VFS: Can't find ext2 filesystem on dev ide1(22,65). > [lss1@localhost lssbin]$ > =========================================================================== > > notes: I 'm testing another 2G scsi disk for XFS filesystem. Above some kind > of lines will maybe > show the test result. expecially lines included ext3. I only use xfs. > > > > my result: > 1.physical hard disk is alright one hundred percent. > 2.Linux native partitions is exist on hard disk. > 3.the only former XFS is ..... > > help me one more time... > > do I have format this? > Thanks ... > > > from "yiseungsu@hotmail.com" > > _________________________________________________________________ > Help STOP SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail > From owner-linux-xfs@oss.sgi.com Sun Dec 14 20:50:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Dec 2003 20:50:52 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBF4oeTa031102 for ; Sun, 14 Dec 2003 20:50:41 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBF681m7002146 for ; Mon, 15 Dec 2003 00:08:01 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBF4nZSC20600752 for ; Sun, 14 Dec 2003 22:49:35 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBF4nQK210273544 for ; Sun, 14 Dec 2003 22:49:26 -0600 (CST) Date: Sun, 14 Dec 2003 22:49:34 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: linux-xfs@oss.sgi.com Subject: ATrpms has updated RH + XFS 1.3 RPMs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1410 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 174 Lines: 9 For those who were looking for updated RH kernels with XFS 1.3.1, I see that Axel Thimm has updated his kernels now: http://atrpms.physik.fu-berlin.de Thanks Axel! -Eric From owner-linux-xfs@oss.sgi.com Sun Dec 14 21:34:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Dec 2003 21:34:49 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.189.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBF5YaTa032012 for ; Sun, 14 Dec 2003 21:34:36 -0800 Received: from mail.pacrimopen.com (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id ED154700250C; Sun, 14 Dec 2003 21:34:47 -0800 (PST) Received: from UNKNOWN(127.0.0.1), claiming to be "mail.pacrimopen.com" via SMTP by sa-relay.pacrimopen.com, id smtpdtOeSiR; Sun Dec 14 21:34:35 2003 Received: from menion.home (unknown [4.4.175.20]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id A0BDA700250C; Sun, 14 Dec 2003 21:34:34 -0800 (PST) Subject: Re: Repairing XFS From: Joshua Schmidlkofer To: Norman Zhang Cc: XFS Mailing List In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ksCF92ZasHdd5pn2ZZuj" Message-Id: <1071466461.2076.8.camel@menion.home> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 14 Dec 2003 21:34:21 -0800 X-archive-position: 1411 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: menion@asylumwear.com Precedence: bulk X-list: linux-xfs Content-Length: 2523 Lines: 67 --=-ksCF92ZasHdd5pn2ZZuj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-12-10 at 12:24, Norman Zhang wrote: > Hi, >=20 > I'm seeing some irregulars halts on one of my XFS volume (/srv). I can on= ly > use umount -l to dismount the volume or do a hot reboot. >=20 > Dec 9 15:47:25 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) called > from line 1039 of file xfs_trans.c. Return address =3D 0xe109f312 > Dec 9 15:47:25 smbserver kernel: Corruption of in-memory data detected. > Shutting down filesystem: md(9,5) > Dec 9 15:47:25 smbserver kernel: Please umount the filesystem, and recti= fy > the problem(s) >=20 I just got this error on a plain IDE hardrive. XFS, with Kernel 2.6.0-test11. I had a lockup because of an IRQ conflict with my USB2 controller. I had a high load, started to swap, tried to kill evolution, and the Interrupt took my box. The entire UI deadlocked, but the box would still ping. =3D(. No ssh, so I reset, and went to my secondary system. [The hdg2, on a HPT370 controller]. I started to xfs_repair my main fs because I had a LOT going on when I rebooted. I started copying files off of my camera hard drive over USB2 again.=20 Halfway throught Phase 3, I locked up - had to be the new card. Now I dropped back to my rescue partition, and did an xfs_repair on the main fs, [hda7]. When finished, I rebooted to the main system, mount & umount sdg2, then xfs_repair. Repair went fine, dead files, but nothing serious. Then about ten minutes later, while emerging 'kino' [on that fs]: Filesystem "hdg2": xfs_log_write: reservation ran out. Need to up reservati= on xfs_force_shutdown(hdg2,0x8) called from line 1739 of file fs/xfs/xfs_log.c= . Return address =3D 0xc020b8c4 Filesystem "hdg2": Corruption of in-memory data detected. Shutting down fi= lesystem: hdg2 Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(hdg2,0x2) called from line 1321 of file fs/xfs/xfs_log.c= . Return address =3D 0xc020b8c4 I do not know what it means to 'up reservation'. I will google, but I felt this was worth posting. Other details needed? thanks, Joshua --=-ksCF92ZasHdd5pn2ZZuj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/3UfbcweM6t71VHsRArn6AJsELa7owedL7rIisOJOI+M2KyCnWQCgk1X3 Lh6mXI1SFrmD1NAuSHvcKy8= =inb5 -----END PGP SIGNATURE----- --=-ksCF92ZasHdd5pn2ZZuj-- From owner-linux-xfs@oss.sgi.com Sun Dec 14 21:47:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Dec 2003 21:47:38 -0800 (PST) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBF5lHTa032504 for ; Sun, 14 Dec 2003 21:47:17 -0800 Received: from [10.1.2.77] (localhost [127.0.0.1]) by shell.wgops.com (Postfix) with ESMTP id E2C2325510; Sun, 14 Dec 2003 22:47:11 -0700 (MST) Date: Sun, 14 Dec 2003 22:47:10 -0700 From: Michael Loftis To: Joshua Schmidlkofer , Norman Zhang Cc: XFS Mailing List Subject: Re: Repairing XFS Message-ID: <17190909.1071442030@[10.1.2.77]> In-Reply-To: <1071466461.2076.8.camel@menion.home> References: <1071466461.2076.8.camel@menion.home> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-MailScanner-Information: Please contact support@wgops.com X-MailScanner: WGOPS clean X-archive-position: 1412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 758 Lines: 29 --On Sunday, December 14, 2003 21:34 -0800 Joshua Schmidlkofer wrote: > I do not know what it means to 'up reservation'. I will google, but I > felt this was worth posting. Other details needed? It's XFS saying I'm doing something dull here because I ran out of log space. You need to increase the size of your XFS log/journal. Why this code exists? I don't know. It should flush metawrites fromt eh journal to the actual data disk rather than puking under 'high' loads like this. > > thanks, > Joshua > -- Undocumented Features quote of the moment... "It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.'" --Murphy's Laws of Combat From owner-linux-xfs@oss.sgi.com Sun Dec 14 22:09:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Dec 2003 22:09:31 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBF69JTa001073 for ; Sun, 14 Dec 2003 22:09:20 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hBF4GqOO013080 for ; Sun, 14 Dec 2003 20:16:53 -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 RAA07494; Mon, 15 Dec 2003 17:09:09 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hBF697Uc2020131; Mon, 15 Dec 2003 17:09:08 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hBF68b9j002119; Mon, 15 Dec 2003 17:08:37 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hBF68JGl002117; Mon, 15 Dec 2003 17:08:19 +1100 Date: Mon, 15 Dec 2003 17:08:19 +1100 From: Nathan Scott To: Joshua Schmidlkofer Cc: Norman Zhang , XFS Mailing List Subject: Re: Repairing XFS Message-ID: <20031215060819.GG823@frodo> References: <1071466461.2076.8.camel@menion.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1071466461.2076.8.camel@menion.home> User-Agent: Mutt/1.5.3i X-archive-position: 1413 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1006 Lines: 29 On Sun, Dec 14, 2003 at 09:34:21PM -0800, Joshua Schmidlkofer wrote: > On Wed, 2003-12-10 at 12:24, Norman Zhang wrote: > > Hi, > > > > I'm seeing some irregulars halts on one of my XFS volume (/srv). I can only > > use umount -l to dismount the volume or do a hot reboot. > > > > Dec 9 15:47:25 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) called > > from line 1039 of file xfs_trans.c. Return address = 0xe109f312 > > Dec 9 15:47:25 smbserver kernel: Corruption of in-memory data detected. > > Shutting down filesystem: md(9,5) > > Dec 9 15:47:25 smbserver kernel: Please umount the filesystem, and rectify > > the problem(s) > > > > I just got this error on a plain IDE hardrive. XFS, with Kernel > 2.6.0-test11. I had a lockup because of an IRQ conflict with my USB2 This is an XFS bug. Mounting with the "ikeep" mount option will resolve the issue. That option is the default in current CVS kernels (I haven't sent that change on to Linus for 2.6 yet though). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Dec 14 23:12:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Dec 2003 23:13:15 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBF7CjTa002733 for ; Sun, 14 Dec 2003 23:12:45 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBF8U6m7020293 for ; Mon, 15 Dec 2003 02:30:06 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBF7CdSC20565754 for ; Mon, 15 Dec 2003 01:12:39 -0600 (CST) Received: (from overby@localhost) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) id hBF7CVtE565616; Mon, 15 Dec 2003 01:12:31 -0600 (CST) Date: Mon, 15 Dec 2003 01:12:31 -0600 (CST) Message-Id: <200312150712.hBF7CVtE565616@daisy-e236.americas.sgi.com> From: Glen Overby To: linux-xfs@oss.sgi.com Subject: Re: Repairing XFS In-Reply-To: message from Michael Loftis sent 14 December 2003 References: <1071466461.2076.8.camel@menion.home> <17190909.1071442030@[10.1.2.77]> X-archive-position: 1414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: overby@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 582 Lines: 19 On December 14, Michael Loftis wrote: > It's XFS saying I'm doing something dull here because I ran out of log > space. You need to increase the size of your XFS log/journal. No, this error is from running out of space in a transaction's space reservation, not running out of log space. Increasing the log size won't make it go away. Every transaction has a space reservation that says what the maximum ammount of log and disk space it will need. Recent changes in inode removal have resulted in a larger transaction. For now, mount with the "ikeep" option. Glen Overby From owner-linux-xfs@oss.sgi.com Mon Dec 15 07:02:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 07:02:25 -0800 (PST) Received: from provone.provsol.net (provone.provsol.net [66.83.239.66]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFF22Ta005678 for ; Mon, 15 Dec 2003 07:02:02 -0800 Received: from localhost (localhost [127.0.0.1]) by provone.provsol.net (Postfix) with ESMTP id 43223204294 for ; Mon, 15 Dec 2003 09:02:01 -0600 (CST) Received: from provone.provsol.net ([192.168.20.254]) by localhost (provone.provsol.net [192.168.20.254]) (amavisd-new, port 10024) with ESMTP id 07084-01 for ; Mon, 15 Dec 2003 09:02:00 -0600 (CST) Received: from serria.provsol.int (serria.provsol.int [192.168.20.22]) by provone.provsol.net (Postfix) with ESMTP id 5C19C204267 for ; Mon, 15 Dec 2003 09:02:00 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by serria.provsol.int (Postfix) with ESMTP id 519FFA019CA for ; Mon, 15 Dec 2003 09:02:00 -0600 (CST) Received: from cosby.provsol.int (cosby.provsol.int [192.168.20.35]) by serria.provsol.int (Postfix) with ESMTP id 0643AA019C4 for ; Mon, 15 Dec 2003 09:02:00 -0600 (CST) Subject: Re: ATrpms has updated RH + XFS 1.3 RPMs From: "Vernon A. Fort" To: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Provident Solutions, LLC Message-Id: <1071500519.18264.12.camel@cosby> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Dec 2003 09:02:00 -0600 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS snapshot-20020300 X-Virus-Scanned: by amavisd-new at provident-solutions.com X-archive-position: 1415 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vfort@provident-solutions.com Precedence: bulk X-list: linux-xfs Content-Length: 548 Lines: 21 True but it appears only for the Fedora Core 1. BTW - is anyone working on the Fedora XFS Installer? Or could someone point me in the direction to documents or howto's so I could attempt to re-spin one myself. I really have no idea on where to start but would like to give it a shot. Vernon Fort On Sun, 2003-12-14 at 22:49, Eric Sandeen wrote: > For those who were looking for updated RH kernels with XFS > 1.3.1, I see that Axel Thimm has updated his kernels now: > > http://atrpms.physik.fu-berlin.de > > Thanks Axel! > > -Eric > > > From owner-linux-xfs@oss.sgi.com Mon Dec 15 07:05:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 07:05:34 -0800 (PST) Received: from uwast.astro.wisc.edu (uwast.astro.wisc.edu [144.92.179.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFF5MTa006177 for ; Mon, 15 Dec 2003 07:05:22 -0800 Received: from astro.wisc.edu (premo.astro.wisc.edu [144.92.179.236]) (authenticated bits=0) by uwast.astro.wisc.edu (8.12.8/8.12.8) with ESMTP id hBFF5Gq6015553 for ; Mon, 15 Dec 2003 09:05:16 -0600 Message-ID: <3FDDCDAC.8030807@astro.wisc.edu> Date: Mon, 15 Dec 2003 09:05:16 -0600 From: jansen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfsdump problems Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1416 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jansen@astro.wisc.edu Precedence: bulk X-list: linux-xfs Content-Length: 2740 Lines: 71 Hi, I am having problems with xfsdump on a 1.3TB hardware RAID array. First the dumps started running much slower than it used to and now it is frequently hanging in the "D" state. At the moment it seems to only get to the point of "constructing initial dump list" where it hangs. The machine also gets a high load average at this point and becomes slugish. I ran xfs_check on the partition but it didn't find any problems. The RAID array is a promise RM8000 with 8 200 GB disks in RAID5 connected to a 2x3.02 GHz Dell Precision 450 with an Adaptec 39160 SCSI controller. I'm currently using xfs 1.3.1 with this kernel: 2.4.22-1.2129.nptl.xfssmp but it had the same problem with the 2.4.20-20.8.XFS1.3.0smp. There are no error messages in syslog or dmesg associated with the hang of xfsdump and there are no unusual messages when the disk is mounted. I'd appreciate any help debugging this problem. Here's the xfsdump command I'm using: /usr/sbin/xfsdump -l 0 -e -d 2048 -o -T -L premo -f /dev/nst0 /dev/sdb1 Here's the output from the above xfsdump command: /usr/sbin/xfsdump: using scsi tape (drive_scsitape) strategy /usr/sbin/xfsdump: version 2.2.14 (dump format 3.0) - Running single-threaded /usr/sbin/xfsdump: level 0 dump of premo:/usr/data/premo3 /usr/sbin/xfsdump: dump date: Mon Dec 15 07:28:09 2003 /usr/sbin/xfsdump: session id: ebeecaba-8d54-44ed-a645-1b7171b9c00d /usr/sbin/xfsdump: session label: "premo" /usr/sbin/xfsdump: ino map phase 1: skipping (no subtrees specified) /usr/sbin/xfsdump: ino map phase 2: constructing initial dump list Here's the output of xfs_info (yes I know the sunit and swidth are wrong, and I now know that "isize" should be 512): # xfs_info /dev/sdb1 meta-data=/usr/data/premo3 isize=256 agcount=326, agsize=1048575 blks = sectsz=512 data = bsize=4096 blocks=341794915, imaxpct=25 = sunit=1 swidth=4 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Here's the output from xfs_db -c frag /dev/sdb1: actual 4222235, ideal 3973436, fragmentation factor 5.89% I did an "strace" on xfsdump and these ioctl commands are the ones that appear to make the high load average: 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 -- ------- Stephan From owner-linux-xfs@oss.sgi.com Mon Dec 15 08:25:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 08:25:19 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFGOxTa010719 for ; Mon, 15 Dec 2003 08:25:00 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 8B1DB1437156; Mon, 15 Dec 2003 11:25:28 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 52D9B1437146; Mon, 15 Dec 2003 11:25:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 38FEA3006150; Mon, 15 Dec 2003 11:25:26 -0500 (EST) Date: Mon, 15 Dec 2003 11:25:25 -0500 (EST) From: Mike Burger To: "Vernon A. Fort" Cc: linux-xfs@oss.sgi.com Subject: Re: ATrpms has updated RH + XFS 1.3 RPMs In-Reply-To: <1071500519.18264.12.camel@cosby> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1417 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 574 Lines: 24 On 15 Dec 2003, Vernon A. Fort wrote: > True but it appears only for the Fedora Core 1. Not at all...look again...the kernel RPMs are available for versions of RHL back to 7.3, and he also includes a src.rpm in the archive. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Mon Dec 15 08:28:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 08:28:22 -0800 (PST) Received: from hoby.coplanar.net (CPE0020afeeb1ac-CM014250013274.cpe.net.cable.rogers.com [24.114.21.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFGSATa011108 for ; Mon, 15 Dec 2003 08:28:10 -0800 Received: from coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) (authenticated bits=0) by hoby.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBFGS7Vc018476 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 15 Dec 2003 11:28:09 -0500 Message-ID: <3FDDE052.9030904@coplanar.net> Date: Mon, 15 Dec 2003 11:24:50 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 CC: XFS Mailing List Subject: Re: Repairing XFS References: <1071466461.2076.8.camel@menion.home> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1418 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 263 Lines: 8 Joshua Schmidlkofer wrote: > evolution, and the Interrupt took my box. The entire UI deadlocked, but > the box would still ping. =(. No ssh, so I reset, and went to my Question for XFS guys - in general, would kernel Alt-SysRq-U make for a "cleaner" crash? From owner-linux-xfs@oss.sgi.com Mon Dec 15 08:39:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 08:39:43 -0800 (PST) Received: from hoby.coplanar.net (CPE0020afeeb1ac-CM014250013274.cpe.net.cable.rogers.com [24.114.21.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFGdLTa011627 for ; Mon, 15 Dec 2003 08:39:21 -0800 Received: from coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) (authenticated bits=0) by hoby.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBFGdFVc018523 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 15 Dec 2003 11:39:18 -0500 Message-ID: <3FDDE2EF.2000006@coplanar.net> Date: Mon, 15 Dec 2003 11:35:59 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: jansen CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump problems References: <3FDDCDAC.8030807@astro.wisc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1419 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 2127 Lines: 60 jansen wrote: > > Hi, > > I am having problems with xfsdump on a 1.3TB hardware RAID array. First > the dumps started running much slower than it used to and now it is > frequently hanging in the "D" state. At the moment it seems to only get > to the point of "constructing initial dump list" where it hangs. The > machine also gets a high load average at this point and becomes slugish. > I ran xfs_check on the partition but it didn't find any problems. The > RAID array is a promise RM8000 with 8 200 GB disks in RAID5 connected > to a 2x3.02 GHz Dell Precision 450 with an Adaptec 39160 SCSI controller. > I'm currently using xfs 1.3.1 with this kernel: 2.4.22-1.2129.nptl.xfssmp > but it had the same problem with the 2.4.20-20.8.XFS1.3.0smp. There are > no error messages in syslog or dmesg associated with the hang of xfsdump > and there are no unusual messages when the disk is mounted. > > I'd appreciate any help debugging this problem. > > > Here's the xfsdump command I'm using: > > /usr/sbin/xfsdump -l 0 -e -d 2048 -o -T -L premo -f /dev/nst0 /dev/sdb1 > Can you say what tape drive you are using? > Here's the output from the above xfsdump command: > > /usr/sbin/xfsdump: using scsi tape (drive_scsitape) strategy > /usr/sbin/xfsdump: version 2.2.14 (dump format 3.0) - Running > single-threaded You should be aware that this version of xfsdump (2.2.13 and 2.2.14) has problems with multiple sessions on scsi tapes. As a workaround use 2.2.12 until 2.2.15 (includes fix) comes out. I don't think that's the issue here though, since you are using -o. > > I did an "strace" on xfsdump and these ioctl commands are the ones that > appear to make the high load average: > > 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 > 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 > 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 > 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 > 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 > 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 > > It might help to look earlier in the output to see what file #4 points to. Look for open( ... ) = 4 lines. Cheers, Jeremy Jackson From owner-linux-xfs@oss.sgi.com Mon Dec 15 08:41:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 08:41:44 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFGfWTa012031 for ; Mon, 15 Dec 2003 08:41:32 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBFHwtm7009294 for ; Mon, 15 Dec 2003 11:58:55 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBFGeQSC20649087; Mon, 15 Dec 2003 10:40:26 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBFGeHK110495820; Mon, 15 Dec 2003 10:40:18 -0600 (CST) Subject: Re: ATrpms has updated RH + XFS 1.3 RPMs From: Eric Sandeen To: "Vernon A. Fort" Cc: linux-xfs@oss.sgi.com In-Reply-To: <1071500519.18264.12.camel@cosby> References: <1071500519.18264.12.camel@cosby> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1071506425.13290.8.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Dec 2003 10:40:26 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1420 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 737 Lines: 23 On Mon, 2003-12-15 at 09:02, Vernon A. Fort wrote: > True but it appears only for the Fedora Core 1. No, it's available for RH 7/8/9 as well. See for example: http://atrpms.physik.fu-berlin.de/dist/rh9/kernel/ > BTW - is anyone working on the Fedora XFS Installer? Or could someone > point me in the direction to documents or howto's so I could attempt to > re-spin one myself. I really have no idea on where to start but would > like to give it a shot. Look at an older XFS installer for the anaconda src.rpm with anaconda patches; I'll see if we can put minimal build instructions out on the web. -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Dec 15 08:53:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 08:53:38 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFGrOTa012633 for ; Mon, 15 Dec 2003 08:53:25 -0800 Received: by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id hBFGrIGT001477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Dec 2003 17:53:19 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id hBFGr3DQ008945; Mon, 15 Dec 2003 17:53:03 +0100 Date: Mon, 15 Dec 2003 17:53:03 +0100 From: Axel Thimm To: Eric Sandeen , "Vernon A. Fort" , Mike Burger Cc: linux-xfs@oss.sgi.com Subject: Re: ATrpms has updated RH + XFS 1.3 RPMs Message-ID: <20031215165303.GL4974@neu.nirvana> References: <1071500519.18264.12.camel@cosby> <1071500519.18264.12.camel@cosby> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oOpJzULQ70+PGW7h" Content-Disposition: inline In-Reply-To: <1071500519.18264.12.camel@cosby> User-Agent: Mutt/1.4.1i X-archive-position: 1421 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1185 Lines: 42 --oOpJzULQ70+PGW7h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 14, 2003 at 10:49:34PM -0600, Eric Sandeen wrote: > For those who were looking for updated RH kernels with XFS > 1.3.1, I see that Axel Thimm has updated his kernels now: >=20 > http://atrpms.physik.fu-berlin.de >=20 > Thanks Axel! You're welcome! On Mon, Dec 15, 2003 at 09:02:00AM -0600, Vernon A. Fort wrote: > True but it appears only for the Fedora Core 1. On Mon, Dec 15, 2003 at 11:25:25AM -0500, Mike Burger wrote: > Not at all...look again...the kernel RPMs are available for versions of= =20 > RHL back to 7.3, and he also includes a src.rpm in the archive. Well, FC1 is 1.3.1 and the rest is 1.3.0. IIRC the functionality is the same, only some license related changes have been made. --=20 Axel.Thimm@physik.fu-berlin.de --oOpJzULQ70+PGW7h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/3ebvQBVS1GOamfERAv4tAJ9cDQsL8i3YHBo8Xqih48YFCxV0awCeJ+qD ZdDzYy9CXdlorz72s5mV3H4= =bNs0 -----END PGP SIGNATURE----- --oOpJzULQ70+PGW7h-- From owner-linux-xfs@oss.sgi.com Mon Dec 15 09:03:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 09:03:55 -0800 (PST) Received: from uwast.astro.wisc.edu (uwast.astro.wisc.edu [144.92.179.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFH3YTa013391 for ; Mon, 15 Dec 2003 09:03:34 -0800 Received: from astro.wisc.edu (premo.astro.wisc.edu [144.92.179.236]) (authenticated bits=0) by uwast.astro.wisc.edu (8.12.8/8.12.8) with ESMTP id hBFH3Kq6022199; Mon, 15 Dec 2003 11:03:20 -0600 Message-ID: <3FDDE958.2060301@astro.wisc.edu> Date: Mon, 15 Dec 2003 11:03:20 -0600 From: jansen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeremy Jackson CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump problems References: <3FDDCDAC.8030807@astro.wisc.edu> <3FDDE2EF.2000006@coplanar.net> In-Reply-To: <3FDDE2EF.2000006@coplanar.net> Content-Type: multipart/mixed; boundary="------------000407040905000104000805" X-archive-position: 1422 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jansen@astro.wisc.edu Precedence: bulk X-list: linux-xfs Content-Length: 35238 Lines: 654 This is a multi-part message in MIME format. --------------000407040905000104000805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Jeremy Jackson wrote: > jansen wrote: > >> >> Hi, >> >> I am having problems with xfsdump on a 1.3TB hardware RAID array. First >> the dumps started running much slower than it used to and now it is >> frequently hanging in the "D" state. At the moment it seems to only get >> to the point of "constructing initial dump list" where it hangs. The >> machine also gets a high load average at this point and becomes slugish. >> I ran xfs_check on the partition but it didn't find any problems. The >> RAID array is a promise RM8000 with 8 200 GB disks in RAID5 connected >> to a 2x3.02 GHz Dell Precision 450 with an Adaptec 39160 SCSI controller. >> I'm currently using xfs 1.3.1 with this kernel: 2.4.22-1.2129.nptl.xfssmp >> but it had the same problem with the 2.4.20-20.8.XFS1.3.0smp. There are >> no error messages in syslog or dmesg associated with the hang of xfsdump >> and there are no unusual messages when the disk is mounted. >> >> I'd appreciate any help debugging this problem. >> >> >> Here's the xfsdump command I'm using: >> >> /usr/sbin/xfsdump -l 0 -e -d 2048 -o -T -L premo -f /dev/nst0 /dev/sdb1 >> > > Can you say what tape drive you are using? > I'm dumping to an IBM 3581 seven tape LTO SCSI autoloader. >> Here's the output from the above xfsdump command: >> >> /usr/sbin/xfsdump: using scsi tape (drive_scsitape) strategy >> /usr/sbin/xfsdump: version 2.2.14 (dump format 3.0) - Running >> single-threaded > > > You should be aware that this version of xfsdump (2.2.13 and 2.2.14) has > problems with multiple sessions on scsi tapes. As a workaround use > 2.2.12 until 2.2.15 (includes fix) comes out. I don't think that's the > issue here though, since you are using -o. > > >> >> I did an "strace" on xfsdump and these ioctl commands are the ones that >> appear to make the high load average: >> >> 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 >> 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 >> 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 >> 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 >> 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 >> 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 >> >> > > It might help to look earlier in the output to see what file #4 points > to. Look for open( ... ) = 4 lines. > It appears to be opening the mount point, here's the line: 14054 open("/usr/data/premo3", O_RDONLY|O_LARGEFILE) = 4 I've attached the complete output from the strace for those interested. > Cheers, > > Jeremy Jackson > -- ------- Stephan --------------000407040905000104000805 Content-Type: text/plain; name="xfsdump" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xfsdump" 14054 execve("/usr/sbin/xfsdump", ["/usr/sbin/xfsdump", "-l", "0", "-d", "2048", "-o", "-T", "-L", "premo", "-f", "/dev/nst0", "/dev/sdb1"], [/* 22 vars */]) = 0 14054 uname({sys="Linux", node="premo", ...}) = 0 14054 brk(0) = 0x808caa0 14054 open("/etc/ld.so.preload", O_RDONLY) = 3 14054 fstat64(3, {st_mode=S_IFREG|0644, st_size=17, ...}) = 0 14054 old_mmap(NULL, 17, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x40016000 14054 close(3) = 0 14054 open("/etc/libcwait.so", O_RDONLY) = 3 14054 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\5\0\000"..., 512) = 512 14054 fstat64(3, {st_mode=S_IFREG|0755, st_size=4990, ...}) = 0 14054 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 14054 old_mmap(NULL, 6216, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40018000 14054 old_mmap(0x40019000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x40019000 14054 close(3) = 0 14054 munmap(0x40016000, 17) = 0 14054 open("/etc/ld.so.cache", O_RDONLY) = 3 14054 fstat64(3, {st_mode=S_IFREG|0644, st_size=59017, ...}) = 0 14054 old_mmap(NULL, 59017, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001a000 14054 close(3) = 0 14054 open("/lib/libhandle.so.1", O_RDONLY) = 3 14054 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\30\v\0"..., 512) = 512 14054 fstat64(3, {st_mode=S_IFREG|0644, st_size=99806, ...}) = 0 14054 old_mmap(NULL, 9584, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40029000 14054 old_mmap(0x4002b000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x4002b000 14054 close(3) = 0 14054 open("/lib/libattr.so.1", O_RDONLY) = 3 14054 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\274\r\0"..., 512) = 512 14054 fstat64(3, {st_mode=S_IFREG|0644, st_size=49123, ...}) = 0 14054 old_mmap(NULL, 14836, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002c000 14054 old_mmap(0x4002f000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 0x4002f000 14054 close(3) = 0 14054 open("/lib/libdm.so.0", O_RDONLY) = 3 14054 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0X\26\0\000"..., 512) = 512 14054 fstat64(3, {st_mode=S_IFREG|0644, st_size=165761, ...}) = 0 14054 old_mmap(NULL, 24548, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40030000 14054 old_mmap(0x40035000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x4000) = 0x40035000 14054 close(3) = 0 14054 open("/lib/tls/libc.so.6", O_RDONLY) = 3 14054 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000X\1\000"..., 512) = 512 14054 fstat64(3, {st_mode=S_IFREG|0755, st_size=1567528, ...}) = 0 14054 old_mmap(NULL, 1276748, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40036000 14054 old_mmap(0x40168000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x131000) = 0x40168000 14054 old_mmap(0x4016c000, 6988, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4016c000 14054 close(3) = 0 14054 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000 14054 set_thread_area({entry_number:-1 -> 6, base_addr:0x40016460, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 14054 munmap(0x4001a000, 59017) = 0 14054 brk(0) = 0x808caa0 14054 brk(0x80adaa0) = 0x80adaa0 14054 brk(0) = 0x80adaa0 14054 brk(0x80ae000) = 0x80ae000 14054 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 14054 fstat64(3, {st_mode=S_IFREG|0644, st_size=32148976, ...}) = 0 14054 mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4016e000 14054 close(3) = 0 14054 getpid() = 14054 14054 getrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 14054 getrlimit(RLIMIT_STACK, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 14054 setrlimit(RLIMIT_STACK, {rlim_cur=131072*1024, rlim_max=RLIM_INFINITY}) = 0 14054 getrlimit(RLIMIT_STACK, {rlim_cur=131072*1024, rlim_max=RLIM_INFINITY}) = 0 14054 getrlimit(RLIMIT_DATA, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 14054 getrlimit(RLIMIT_FSIZE, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 14054 setrlimit(RLIMIT_FSIZE, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 14054 setrlimit(RLIMIT_FSIZE, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 14054 getrlimit(RLIMIT_FSIZE, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 14054 getrlimit(RLIMIT_CPU, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 14054 setrlimit(RLIMIT_CPU, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 14054 getrlimit(RLIMIT_CPU, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 14054 getcwd("/root", 4096) = 6 14054 stat64("/var/lib/xfsdump", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 14054 stat64("/var/xfsdump", 0xbffff8d0) = -1 ENOENT (No such file or directory) 14054 geteuid32() = 0 14054 getpid() = 14054 14054 stat64("/dev/nst0", {st_mode=S_IFCHR|0660, st_rdev=makedev(9, 128), ...}) = 0 14054 stat64("/dev/nst0", {st_mode=S_IFCHR|0660, st_rdev=makedev(9, 128), ...}) = 0 14054 lstat64("/dev", {st_mode=S_IFDIR|0755, st_size=116736, ...}) = 0 14054 lstat64("/dev/nst0", {st_mode=S_IFCHR|0660, st_rdev=makedev(9, 128), ...}) = 0 14054 stat64("/dev/nst0", {st_mode=S_IFCHR|0660, st_rdev=makedev(9, 128), ...}) = 0 14054 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 3 14054 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 14054 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 14054 read(3, "Character devices:\n 1 mem\n 2 p"..., 4096) = 418 14054 close(3) = 0 14054 munmap(0x4001a000, 4096) = 0 14054 getpid() = 14054 14054 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0 14054 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 14054 write(1, "/usr/sbin/xfsdump: using scsi ta"..., 61) = 61 14054 mmap2(NULL, 2105344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4036e000 14054 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0 14054 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 14054 getpid() = 14054 14054 write(1, "/usr/sbin/xfsdump: version 2.2.1"..., 51) = 51 14054 write(1, " - Running single-threaded\n", 27) = 27 14054 time(NULL) = 1071497192 14054 open("/etc/hostid", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) 14054 open("/etc/hostid", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) 14054 uname({sys="Linux", node="premo", ...}) = 0 14054 gettimeofday({1071497192, 253907}, NULL) = 0 14054 getpid() = 14054 14054 open("/etc/resolv.conf", O_RDONLY) = 3 14054 fstat64(3, {st_mode=S_IFREG|0644, st_size=111, ...}) = 0 14054 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001b000 14054 read(3, "; generated by /sbin/dhclient-sc"..., 4096) = 111 14054 read(3, "", 4096) = 0 14054 close(3) = 0 14054 munmap(0x4001b000, 4096) = 0 14054 socket(PF_UNIX, SOCK_STREAM, 0) = 3 14054 connect(3, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory) 14054 close(3) = 0 14054 open("/etc/nsswitch.conf", O_RDONLY) = 3 14054 fstat64(3, {st_mode=S_IFREG|0644, st_size=1686, ...}) = 0 14054 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001b000 14054 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1686 14054 read(3, "", 4096) = 0 14054 close(3) = 0 14054 munmap(0x4001b000, 4096) = 0 14054 open("/etc/ld.so.cache", O_RDONLY) = 3 14054 fstat64(3, {st_mode=S_IFREG|0644, st_size=59017, ...}) = 0 14054 old_mmap(NULL, 59017, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40570000 14054 close(3) = 0 14054 open("/lib/libnss_files.so.2", O_RDONLY) = 3 14054 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\35\0"..., 512) = 512 14054 fstat64(3, {st_mode=S_IFREG|0755, st_size=51924, ...}) = 0 14054 old_mmap(NULL, 46720, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001b000 14054 old_mmap(0x40026000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xa000) = 0x40026000 14054 close(3) = 0 14054 munmap(0x40570000, 59017) = 0 14054 open("/etc/host.conf", O_RDONLY) = 3 14054 fstat64(3, {st_mode=S_IFREG|0644, st_size=17, ...}) = 0 14054 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40027000 14054 read(3, "order hosts,bind\n", 4096) = 17 14054 read(3, "", 4096) = 0 14054 close(3) = 0 14054 munmap(0x40027000, 4096) = 0 14054 open("/etc/hosts", O_RDONLY) = 3 14054 fcntl64(3, F_GETFD) = 0 14054 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 14054 fstat64(3, {st_mode=S_IFREG|0644, st_size=147, ...}) = 0 14054 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40027000 14054 read(3, "# Do not remove the following li"..., 4096) = 147 14054 read(3, "", 4096) = 0 14054 close(3) = 0 14054 munmap(0x40027000, 4096) = 0 14054 open("/etc/ld.so.cache", O_RDONLY) = 3 14054 fstat64(3, {st_mode=S_IFREG|0644, st_size=59017, ...}) = 0 14054 old_mmap(NULL, 59017, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40570000 14054 close(3) = 0 14054 open("/lib/libnss_dns.so.2", O_RDONLY) = 3 14054 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\16"..., 512) = 512 14054 fstat64(3, {st_mode=S_IFREG|0755, st_size=18384, ...}) = 0 14054 old_mmap(NULL, 16884, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4057f000 14054 old_mmap(0x40583000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3000) = 0x40583000 14054 close(3) = 0 14054 open("/lib/libresolv.so.2", O_RDONLY) = 3 14054 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360(\0"..., 512) = 512 14054 fstat64(3, {st_mode=S_IFREG|0755, st_size=76508, ...}) = 0 14054 old_mmap(NULL, 73604, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40584000 14054 old_mmap(0x40593000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xf000) = 0x40593000 14054 old_mmap(0x40594000, 8068, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40594000 14054 close(3) = 0 14054 munmap(0x40570000, 59017) = 0 14054 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 14054 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("144.92.179.160")}, 28) = 0 14054 send(3, "V\336\1\0\0\1\0\0\0\0\0\0\5premo\5astro\4wisc\3ed"..., 38, 0) = 38 14054 gettimeofday({1071497192, 258028}, NULL) = 0 14054 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 14054 ioctl(3, FIONREAD, [123]) = 0 14054 recvfrom(3, "V\336\205\200\0\1\0\1\0\2\0\2\5premo\5astro\4wisc\3ed"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("144.92.179.160")}, [16]) = 123 14054 close(3) = 0 14054 gettimeofday({1071497192, 261428}, NULL) = 0 14054 open("/dev/urandom", O_RDONLY) = 3 14054 getpid() = 14054 14054 getuid32() = 0 14054 gettimeofday({1071497192, 261611}, NULL) = 0 14054 gettimeofday({1071497192, 261656}, NULL) = 0 14054 read(3, "8==\270a\r\266\2635?\7\4\356Nu\224", 16) = 16 14054 uname({sys="Linux", node="premo", ...}) = 0 14054 open("/etc/mtab", O_RDONLY) = 4 14054 fstat64(4, {st_mode=S_IFREG|0644, st_size=2148, ...}) = 0 14054 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40027000 14054 read(4, "/dev/hda8 / ext3 rw 0 0\nnone /pr"..., 4096) = 2148 14054 read(4, "", 4096) = 0 14054 close(4) = 0 14054 munmap(0x40027000, 4096) = 0 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("/usr/data/premo5", {st_mode=S_IFDIR|0755, st_size=36, ...}) = 0 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("glimpse4:/usr/data/glimpse4", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("/usr/data/premo4", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("coopers:/usr/data/wham2", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("poseidon:/usr/data/poseidon", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("ftp:/usr/data/ftp", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("/usr/data/premo3/oort", {st_mode=S_IFDIR|0755, st_size=131, ...}) = 0 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("sage:/usr/data/sage", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("uwast:/usr/data/uwast9", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("www:/usr/data/www", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("shapley:/usr/data/shapley", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("afarsek:/usr/data/afarsek", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("afarsek:/usr/data/afarsek2", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("uwast:/usr/data/uwast7/uwast5", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("uwast:/usr/local/", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("grays:/usr/data/grays", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("bass:/usr/data/bass2", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("/usr/data/premo2", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("poseidon:/usr/data/poseidon2", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("bass:/usr/data/bass", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("/usr/data/premo3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("/usr/data/premo", {st_mode=S_IFDIR|0755, st_size=41, ...}) = 0 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("automount(pid1035)", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("automount(pid1037)", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("automount(pid1058)", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("uwast:/usr/users", 0xbffff430) = -1 ENOENT (No such file or directory) 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("/dev/hda5", {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 5), ...}) = 0 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("/dev/hda2", {st_mode=S_IFBLK|0660, st_rdev=makedev(3, 2), ...}) = 0 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("/dev/sdd1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 49), ...}) = 0 14054 stat64("/dev/sdb1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 17), ...}) = 0 14054 stat64("/dev/sda1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 1), ...}) = 0 14054 open("/usr/data/premo3", O_RDONLY|O_LARGEFILE) = 4 14054 ioctl(4, 0x806c5864, 0xbffff490) = 0 14054 close(4) = 0 14054 quotactl(Q_XGETQSTAT|USRQUOTA, "/dev/sdb1", 0, 0xbffff5a0) = -1 ENOSYS (Function not implemented) 14054 quotactl(Q_XGETQSTAT|USRQUOTA, "/dev/sdb1", 0, 0xbffff5a0) = -1 ENOSYS (Function not implemented) 14054 mkdir("/var", 0755) = -1 EEXIST (File exists) 14054 mkdir("/var/lib", 0755) = -1 EEXIST (File exists) 14054 mkdir("/var/lib/xfsdump", 0755) = -1 EEXIST (File exists) 14054 stat64("/var/lib/xfsdump/inventory", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 14054 open("/var/lib/xfsdump/inventory/eb89c04e-260e-468c-954e-1427196cd757.InvIndex", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) 14054 close(-2) = -1 EBADF (Bad file descriptor) 14054 getpid() = 14054 14054 write(1, "/usr/sbin/xfsdump: level 0 dump "..., 58) = 58 14054 open("/etc/localtime", O_RDONLY) = 4 14054 fstat64(4, {st_mode=S_IFREG|0644, st_size=1279, ...}) = 0 14054 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40027000 14054 read(4, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0"..., 4096) = 1279 14054 close(4) = 0 14054 munmap(0x40027000, 4096) = 0 14054 open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 4 14054 fstat64(4, {st_mode=S_IFREG|0644, st_size=21436, ...}) = 0 14054 mmap2(NULL, 21436, PROT_READ, MAP_SHARED, 4, 0) = 0x40570000 14054 close(4) = 0 14054 getpid() = 14054 14054 write(1, "/usr/sbin/xfsdump: dump date: Mo"..., 55) = 55 14054 getpid() = 14054 14054 write(1, "/usr/sbin/xfsdump: session id: 3"..., 68) = 68 14054 getpid() = 14054 14054 write(1, "/usr/sbin/xfsdump: session label"..., 42) = 42 14054 open("/usr/data/premo3", O_RDONLY|O_LARGEFILE) = 4 14054 fstat64(4, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 14054 lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 14054 lstat64("/usr/data", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 14054 lstat64("/usr/data/premo3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 14054 open("/usr/data/premo3", O_RDONLY|O_LARGEFILE) = 5 14054 ioctl(5, 0xc01c5868, 0xbfffe510) = 0 14054 statfs("/usr/data/premo3", {f_type=0x58465342, f_bsize=4096, f_blocks=341762147, f_bfree=116330574, f_bavail=116330574, f_files=1367179648, f_ffree=1363037764, f_fsid={2065, 0}, f_namelen=255, f_frsize=0}) = 0 14054 stat64("/usr/data/premo3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 14054 open("/proc/mounts", O_RDONLY) = 6 14054 fstat64(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 14054 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40027000 14054 read(6, "rootfs / rootfs rw 0 0\n/dev/root"..., 4096) = 2587 14054 stat64("/usr/data/premo3", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 14054 close(6) = 0 14054 munmap(0x40027000, 4096) = 0 14054 mmap2(NULL, 450560, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40596000 14054 getpid() = 14054 14054 write(1, "/usr/sbin/xfsdump: ino map phase"..., 69) = 69 14054 getpid() = 14054 14054 write(1, "/usr/sbin/xfsdump: ino map phase"..., 67) = 67 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 brk(0) = 0x80ae000 14054 brk(0x80d1000) = 0x80d1000 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 brk(0) = 0x80d1000 14054 brk(0x80f5000) = 0x80f5000 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 brk(0) = 0x80f5000 14054 brk(0x8119000) = 0x8119000 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 14054 --- SIGINT (Interrupt) @ 0 (0) --- 14054 +++ killed by SIGINT +++ --------------000407040905000104000805-- From owner-linux-xfs@oss.sgi.com Mon Dec 15 09:09:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 09:09:23 -0800 (PST) Received: from provone.provsol.net (provone.provsol.net [66.83.239.66]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFH91Ta013912 for ; Mon, 15 Dec 2003 09:09:01 -0800 Received: from localhost (localhost [127.0.0.1]) by provone.provsol.net (Postfix) with ESMTP id C6FFC204294 for ; Mon, 15 Dec 2003 11:09:00 -0600 (CST) Received: from provone.provsol.net ([192.168.20.254]) by localhost (provone.provsol.net [192.168.20.254]) (amavisd-new, port 10024) with ESMTP id 07649-06 for ; Mon, 15 Dec 2003 11:09:00 -0600 (CST) Received: from serria.provsol.int (serria.provsol.int [192.168.20.22]) by provone.provsol.net (Postfix) with ESMTP id F28BB204267 for ; Mon, 15 Dec 2003 11:08:59 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by serria.provsol.int (Postfix) with ESMTP id D1C97A019CA for ; Mon, 15 Dec 2003 11:08:59 -0600 (CST) Received: from cosby.provsol.int (cosby.provsol.int [192.168.20.35]) by serria.provsol.int (Postfix) with ESMTP id 86DE8A019C4 for ; Mon, 15 Dec 2003 11:08:59 -0600 (CST) Subject: Re: ATrpms has updated RH + XFS 1.3 RPMs From: "Vernon A. Fort" To: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Provident Solutions, LLC Message-Id: <1071508139.18264.20.camel@cosby> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Dec 2003 11:08:59 -0600 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS snapshot-20020300 X-Virus-Scanned: by amavisd-new at provident-solutions.com X-archive-position: 1423 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vfort@provident-solutions.com Precedence: bulk X-list: linux-xfs Content-Length: 522 Lines: 19 Well, I must be looking in the wrong place but each 7.3/8/9 all say (when looking by package name) XFS: merged patches found in 1.3.0 I'm not trying to argue but if I looking in the wrong place, please correct me. Vernon Fort On Mon, 2003-12-15 at 10:25, Mike Burger wrote: > On 15 Dec 2003, Vernon A. Fort wrote: > > > True but it appears only for the Fedora Core 1. > > Not at all...look again...the kernel RPMs are available for versions of > RHL back to 7.3, and he also includes a src.rpm in the archive. From owner-linux-xfs@oss.sgi.com Mon Dec 15 09:15:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 09:15:53 -0800 (PST) Received: from provone.provsol.net (provone.provsol.net [66.83.239.66]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFHFVTa014367 for ; Mon, 15 Dec 2003 09:15:32 -0800 Received: from localhost (localhost [127.0.0.1]) by provone.provsol.net (Postfix) with ESMTP id 82B44204294; Mon, 15 Dec 2003 11:15:31 -0600 (CST) Received: from provone.provsol.net ([192.168.20.254]) by localhost (provone.provsol.net [192.168.20.254]) (amavisd-new, port 10024) with ESMTP id 07698-04; Mon, 15 Dec 2003 11:15:30 -0600 (CST) Received: from serria.provsol.int (serria.provsol.int [192.168.20.22]) by provone.provsol.net (Postfix) with ESMTP id 6EE34204267; Mon, 15 Dec 2003 11:15:30 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by serria.provsol.int (Postfix) with ESMTP id 39264A019CA; Mon, 15 Dec 2003 11:15:30 -0600 (CST) Received: from cosby.provsol.int (cosby.provsol.int [192.168.20.35]) by serria.provsol.int (Postfix) with ESMTP id E2A84A019C4; Mon, 15 Dec 2003 11:15:29 -0600 (CST) Subject: Re: ATrpms has updated RH + XFS 1.3 RPMs From: "Vernon A. Fort" To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1071506425.13290.8.camel@stout.americas.sgi.com> References: <1071500519.18264.12.camel@cosby> <1071506425.13290.8.camel@stout.americas.sgi.com> Content-Type: text/plain Organization: Provident Solutions, LLC Message-Id: <1071508529.18264.27.camel@cosby> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Dec 2003 11:15:29 -0600 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS snapshot-20020300 X-Virus-Scanned: by amavisd-new at provident-solutions.com X-archive-position: 1424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vfort@provident-solutions.com Precedence: bulk X-list: linux-xfs Content-Length: 1299 Lines: 33 Thanks Eric, A quick item list would be sufficient. I might have some time over the holidays to complete a test run on the installer. My main issue is I don't want to continue install 9.0-XFS since this release will no longer be supported via redhat. I need to either move to Redhat Enterprise or Fedora 1. I use(ed) redhat 9.0-XFS heavily for internal and some clients I support. Since using XFS on the install, my support issues/stability greatly reduced/increased respectively. Again, thanks - all I need is a starting point and a lists of items/steps to consider or follow. Vernon Fort On Mon, 2003-12-15 at 10:40, Eric Sandeen wrote: > On Mon, 2003-12-15 at 09:02, Vernon A. Fort wrote: > > True but it appears only for the Fedora Core 1. > > No, it's available for RH 7/8/9 as well. > > See for example: > http://atrpms.physik.fu-berlin.de/dist/rh9/kernel/ > > > BTW - is anyone working on the Fedora XFS Installer? Or could someone > > point me in the direction to documents or howto's so I could attempt to > > re-spin one myself. I really have no idea on where to start but would > > like to give it a shot. > > Look at an older XFS installer for the anaconda src.rpm with anaconda > patches; I'll see if we can put minimal build instructions out on the > web. > > -Eric From owner-linux-xfs@oss.sgi.com Mon Dec 15 09:27:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 09:27:18 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFHR2Ta014948 for ; Mon, 15 Dec 2003 09:27:05 -0800 Received: (qmail 32420 invoked from network); 15 Dec 2003 17:27:00 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 15 Dec 2003 17:27:00 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 53987C00AD; Tue, 16 Dec 2003 04:26:54 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 50B5E14009A; Tue, 16 Dec 2003 04:26:54 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Jeremy Jackson Cc: XFS Mailing List Subject: Re: Repairing XFS In-reply-to: Your message of "Mon, 15 Dec 2003 11:24:50 CDT." <3FDDE052.9030904@coplanar.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Dec 2003 04:26:53 +1100 Message-ID: <5670.1071509213@ocs3.intra.ocs.com.au> X-archive-position: 1425 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 540 Lines: 14 On Mon, 15 Dec 2003 11:24:50 -0500, Jeremy Jackson wrote: >Joshua Schmidlkofer wrote: > >> evolution, and the Interrupt took my box. The entire UI deadlocked, but >> the box would still ping. =(. No ssh, so I reset, and went to my > >Question for XFS guys - in general, would kernel Alt-SysRq-U make for a >"cleaner" crash? Only if the ssytem is still capable of doing disk I/O. Same with sysrq-s. Both issue the request then rely on the kernel being able to do I/O. Some crashes are so bad that nothing works. From owner-linux-xfs@oss.sgi.com Mon Dec 15 10:04:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 10:04:38 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFI4QTa021040 for ; Mon, 15 Dec 2003 10:04:26 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBFJLnm7009839 for ; Mon, 15 Dec 2003 13:21:49 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBFI4KSC20730883; Mon, 15 Dec 2003 12:04:20 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBFI4CK110515115; Mon, 15 Dec 2003 12:04:12 -0600 (CST) Subject: Re: ATrpms has updated RH + XFS 1.3 RPMs From: Eric Sandeen To: "Vernon A. Fort" Cc: linux-xfs@oss.sgi.com In-Reply-To: <1071508139.18264.20.camel@cosby> References: <1071508139.18264.20.camel@cosby> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1071511460.13290.110.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Dec 2003 12:04:20 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1426 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 578 Lines: 20 I'm not certain which version Axel really has there, but there should be no runtime differences between 1.3.0 vs. 1.3.1 - it was just tidying up a few things. -Eric On Mon, 2003-12-15 at 11:08, Vernon A. Fort wrote: > Well, > I must be looking in the wrong place but each > 7.3/8/9 all say (when looking by package name) > > XFS: merged patches found in 1.3.0 > > I'm not trying to argue but if I looking in the wrong place, please > correct me. -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Dec 15 10:25:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 10:25:37 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFIPPTa022096 for ; Mon, 15 Dec 2003 10:25:25 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBFJgmm7022954 for ; Mon, 15 Dec 2003 13:42:48 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBFIPJSC20752439; Mon, 15 Dec 2003 12:25:19 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AVxPD-0002MU-00; Mon, 15 Dec 2003 12:25:19 -0600 Date: Mon, 15 Dec 2003 12:25:19 -0600 From: Nathan Straz To: jansen Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump problems Message-ID: <20031215182519.GE3766@sgi.com> Mail-Followup-To: jansen , linux-xfs@oss.sgi.com References: <3FDDCDAC.8030807@astro.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FDDCDAC.8030807@astro.wisc.edu> User-Agent: Mutt/1.5.3i X-archive-position: 1427 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 996 Lines: 22 On Mon, Dec 15, 2003 at 09:05:16AM -0600, jansen wrote: > I did an "strace" on xfsdump and these ioctl commands are the ones that > appear to make the high load average: > > 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 > 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 > 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 > 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 > 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 > 14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 Looks like it's stuck in a loop doing XFS_IOC_FSBULKSTAT. I think I'm hitting something similar. In my case I'm running on ia64 and the system becomes totally unresponsive. Luckily I have KDB. :) Can you run some of the XFS QA suite from CVS? 013 in particular has been exposing this to me. Run it on a scratch partition. -- 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 Mon Dec 15 10:58:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 10:59:01 -0800 (PST) Received: from mail.arkon-group.com (mail.arkon-group.com [207.34.136.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFIwnTa022956 for ; Mon, 15 Dec 2003 10:58:49 -0800 Received: from 2d052 (207.34.136.14 [207.34.136.14]) by mail.arkon-group.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V5LML1W8; Mon, 15 Dec 2003 10:55:11 -0800 Message-ID: <002f01c3c33d$75cf09f0$0716a8c0@hq.arkonnetworks.com> From: "Norman Zhang" To: Cc: , Subject: Re: Repairing XFS Date: Mon, 15 Dec 2003 10:58:38 -0800 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1428 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Content-Length: 2232 Lines: 53 >>> I'm seeing some irregulars halts on one of my XFS volume (/srv). I can >>> only use umount -l to dismount the volume or do a hot reboot. >>> >>> Dec 9 15:47:25 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) called >>> from line 1039 of file xfs_trans.c. Return address = 0xe109f312 >>> Dec 9 15:47:25 smbserver kernel: Corruption of in-memory data detected. >>> Shutting down filesystem: md(9,5) >>> Dec 9 15:47:25 smbserver kernel: Please umount the filesystem, and >>> rectify the problem(s) >> >> I just got this error on a plain IDE hardrive. XFS, with Kernel >> 2.6.0-test11. I had a lockup because of an IRQ conflict with my USB2 > > This is an XFS bug. Mounting with the "ikeep" mount option will resolve > the issue. > > That option is the default in current CVS kernels (I haven't sent that > change on to Linus for 2.6 yet though). I'm also seeing resource collision, but I don't have any other peripherals or cards connected to my box. I'm running Intel SE7500WV2S motherboard, with dual P4 1.8GHz, 2x256MB PC2100 DDR ECC Registered RAM. And only SCA SCSI U160 HD. kernel: md: md7: raid array is not clean -- starting background reconstruction kernel: md: md6: raid array is not clean -- starting background reconstruction kernel: md: md5: raid array is not clean -- starting background reconstruction kernel: md: md4: raid array is not clean -- starting background reconstruction kernel: md: md3: raid array is not clean -- starting background reconstruction kernel: md: md2: raid array is not clean -- starting background reconstruction kernel: md: md1: raid array is not clean -- starting background reconstruction kernel: md: md0: raid array is not clean -- starting background reconstruction kernel: Unknown bridge resource 2: assuming transparent kernel: PCI: Unable to handle 64-bit address space for kernel: PCI: Unable to handle 64-bit address space for kernel: Unknown bridge resource 2: assuming transparent kernel: PCI: Device 00:1f.1 not available because of resource collisions Does this bug also exists in 2.4? I'm using 2.4.19-35mdksmp (from Mandrake). If the bug also exists in 2.4, I will like to help notify the Mandrake to include the fix. May I ask why is this happening? Regards, Norman From owner-linux-xfs@oss.sgi.com Mon Dec 15 12:47:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 12:47:12 -0800 (PST) Received: from tempgw.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFKkwTa029441 for ; Mon, 15 Dec 2003 12:46:59 -0800 Received: from Unknown [172.20.0.8] by tempgw.ciprico.com - SurfControl E-mail Filter (4.7); Mon, 15 Dec 2003 14:48:25 -0600 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 14:46:51 -0600 Message-ID: From: Gustavo Rincon To: "'linux-xfs@oss.sgi.com'" Cc: Tony Lambert , Ben McMillan Date: Mon, 15 Dec 2003 14:46:50 -0600 Subject: LBD patch and XFS problem! MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 1429 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: grincon@ciprico.com Precedence: bulk X-list: linux-xfs Content-Length: 24426 Lines: 588 Hi, I need some help with XFS and LBD patch. I was doing some testing with the linux-2.4.24-pre1+xfs + LBD patch (gotten from ) and after a couple minutes of accessing the filesystem over the network (using samba-3.0.0 to export the filesystem, and each client is creating a 500G file and read it after the file was created) the whole kernel hangs without any message or going into kdb, using ext3 and reiserfs as a filesystem an running the same test the kernel does not hang and I'm able to perform the test without any problem. I forced the kernel into KBD and the following trace I was able to get: Entering kdb (current=0xc19ec000, pid 6) on processor 0 due to Keyboard Entry [0]kdb> b[0]kdb> bt[0]kdb> bt Stack traceback for pid 6 0xc19ec000 6 1 1 0 R 0xc19ec280 *bdflush ESP EIP Function (args) 0xc19edf34 0xc0145b6a write_some_buffers+0x9a (0x0, 0x0, 0xc0340018, 0x10f00, 0x f7ff3fa4) kernel .text 0xc0100000 0xc0145ad0 0xc0145c00 0xc19edfd8 0xc0149869 bdflush+0xb9 kernel .text 0xc0100000 0xc01497b0 0xc0149890 0xc19edff4 0xc010757e arch_kernel_thread+0x2e kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> p[0]kdb> ps[0]kdb> ps [0]kdb> ps  [0]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xc19ec000 6 1 1 0 R 0xc19ec280 *bdflush 0xc19ea000 7 1 1 1 R 0xc19ea280 kupdated 0xf7ff2000 1 0 0 1 R 0xf7ff2280 init 0xc19b2000 2 1 0 1 R 0xc19b2280 keventd 0xc19b0000 3 1 0 0 S 0xc19b0280 ksoftirqd_CPU0 0xc19fe000 4 1 0 1 S 0xc19fe280 ksoftirqd_CPU1 0xc19ee000 5 1 0 1 S 0xc19ee280 kswapd 0xc19ec000 6 1 1 0 R 0xc19ec280 *bdflush 0xc19ea000 7 1 1 1 R 0xc19ea280 kupdated 0xf7644000 13 1 0 0 S 0xf7644280 scsi_eh_0 0xf7506000 15 1 0 1 S 0xf7506280 mdrecoveryd 0xf72f2000 17 1 0 1 R 0xf72f2280 kreiserfsd 0xf798a000 60 1 0 1 S 0xf798a280 khubd 0xf660a000 533 1 0 0 R 0xf660a280 syslogd 0xf64e4000 537 1 0 1 S 0xf64e4280 klogd 0xf6438000 546 1 0 0 S 0xf6438280 portmap 0xf6374000 565 1 0 0 S 0xf6374280 rpc.statd 0xf5ee8000 646 1 0 1 S 0xf5ee8280 sshd 0xf5e54000 661 1 0 0 S 0xf5e54280 xinetd 0xf69ca000 671 1 0 1 R 0xf69ca280 crond 0xf6f20000 687 1 0 1 S 0xf6f20280 login [0]more> 0xf6324000 688 1 0 0 S 0xf6324280 login 0xf60ec000 689 1 0 1 S 0xf60ec280 mingetty 0xf5df8000 692 1 0 1 S 0xf5df8280 mingetty 0xf5d50000 693 688 0 1 S 0xf5d50280 bash 0xf5b1c000 743 1 0 1 R 0xf5b1c280 pagebufd 0xf5b44000 744 1 0 0 R 0xf5b44280 xfslogd/0 0xf5af6000 745 1 0 1 S 0xf5af6280 xfslogd/1 0xf5a90000 746 1 0 0 S 0xf5a90280 xfsdatad/0 0xf5968000 747 1 0 1 S 0xf5968280 xfsdatad/1 0xf5b24000 748 1 0 1 R 0xf5b24280 xfssyncd 0xf5b30000 756 687 0 1 S 0xf5b30280 bash 0xf595e000 793 1 0 1 R 0xf595e280 nmbd 0xf595a000 795 1 0 0 R 0xf595a280 smbd 0xf5950000 798 795 0 1 R 0xf5950280 smbd 0xf5948000 800 795 0 1 R 0xf5948280 smbd 0xd840e000 802 795 0 0 R 0xd840e280 smbd 0xd74e4000 805 795 0 0 R 0xd74e4280 smbd [0]kdb> btp 743 Stack traceback for pid 743 0xf5b1c000 743 1 0 1 R 0xf5b1c280 pagebufd ESP EIP Function (args) 0xf5b1df3c 0xc011abe6 schedule+0x2e6 (0x0, 0xf5b1c000, 0xf8aff64c, 0xf8aff64c, 0 xf5b1dfb8) kernel .text 0xc0100000 0xc011a900 0xc011ae40 0xf5b1df8c 0xc011b11e interruptible_sleep_on+0x4e (0xf5b1dfc0, 0x84e9, 0xf5b2400 0, 0xf5b1dfb8, 0xf5b1dfb8) kernel .text 0xc0100000 0xc011b0d0 0xc011b150 0xf5b1dfac 0xf8ad8491 [xfs]pagebuf_daemon+0x1b1 xfs .text 0xf8a72060 0xf8ad82e0 0xf8ad8560 0xf5b1dff4 0xc010757e arch_kernel_thread+0x2e kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> p[0]kdb> p [0]kdb> b[0]kdb> bt[0]kdb> btp[0]kdb> btp [0]kdb> btp 7[0]kdb> btp 74[0]kdb> btp 744[0]kdb> btp 744 Stack traceback for pid 744 0xf5b44000 744 1 0 0 R 0xf5b44280 xfslogd/0 ESP EIP Function (args) 0xf5b45f48 0xc011abe6 schedule+0x2e6 (0xf8b00334, 0xf8af0a92, 0xf8af0a98, 0x0, 0 x0) kernel .text 0xc0100000 0xc011a900 0xc011ae40 0xf5b45f98 0xf8ad817a [xfs]pagebuf_iodone_daemon+0x13a xfs .text 0xf8a72060 0xf8ad8040 0xf8ad81d0 0xf5b45fdc 0xf8ad8263 [xfs]pagebuf_logiodone_daemon+0x33 xfs .text 0xf8a72060 0xf8ad8230 0xf8ad8270 0xf5b45ff4 0xc010757e arch_kernel_thread+0x2e kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> [0]kdb> btp 744 [0]kdb> btp 74 [0]kdb> btp 74[0]kdb> btp 745[0]kdb> btp 745 Stack traceback for pid 745 0xf5af6000 745 1 0 1 S 0xf5af6280 xfslogd/1 ESP EIP Function (args) 0xf5af7f48 0xc011abe6 schedule+0x2e6 (0xf5af624a, 0xf8af0a92, 0xf8af0a98, 0x1, 0 x0) kernel .text 0xc0100000 0xc011a900 0xc011ae40 0xf5af7f98 0xf8ad817a [xfs]pagebuf_iodone_daemon+0x13a xfs .text 0xf8a72060 0xf8ad8040 0xf8ad81d0 0xf5af7fdc 0xf8ad8263 [xfs]pagebuf_logiodone_daemon+0x33 xfs .text 0xf8a72060 0xf8ad8230 0xf8ad8270 0xf5af7ff4 0xc010757e arch_kernel_thread+0x2e kernel .text 0xc0100000 0xc0107550 0xc0107590 kdb> btp 746 Stack traceback for pid 746 0xf5a90000 746 1 0 0 S 0xf5a90280 xfsdatad/0 ESP EIP Function (args) 0xf5a91f48 0xc011abe6 schedule+0x2e6 (0xf5a9024a, 0xf8af0a92, 0xf8af0aa0, 0x0, 0 x0) kernel .text 0xc0100000 0xc011a900 0xc011ae40 0xf5a91f98 0xf8ad817a [xfs]pagebuf_iodone_daemon+0x13a xfs .text 0xf8a72060 0xf8ad8040 0xf8ad81d0 0xf5a91fdc 0xf8ad82a3 [xfs]pagebuf_dataiodone_daemon+0x33 xfs .text 0xf8a72060 0xf8ad8270 0xf8ad82b0 0xf5a91ff4 0xc010757e arch_kernel_thread+0x2e kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> [0]kdb> btp 746 [0]kdb> btp 748[0]kdb> btp 748 [0]kdb> btp 747[0]kdb> btp 747 Stack traceback for pid 747 0xf5968000 747 1 0 1 S 0xf5968280 xfsdatad/1 ESP EIP Function (args) 0xf5969f48 0xc011abe6 schedule+0x2e6 (0xf596824a, 0xf8af0a92, 0xf8af0aa0, 0x1, 0 x0) kernel .text 0xc0100000 0xc011a900 0xc011ae40 0xf5969f98 0xf8ad817a [xfs]pagebuf_iodone_daemon+0x13a xfs .text 0xf8a72060 0xf8ad8040 0xf8ad81d0 0xf5969fdc 0xf8ad82a3 [xfs]pagebuf_dataiodone_daemon+0x33 xfs .text 0xf8a72060 0xf8ad8270 0xf8ad82b0 0xf5969ff4 0xc010757e arch_kernel_thread+0x2e kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> [0]kdb> btp 747 [0]kdb> btp 748[0]kdb> btp 748 Stack traceback for pid 748 0xf5b24000 748 1 0 1 R 0xf5b24280 xfssyncd ESP EIP Function (args) 0xf5b25f50 0xc011abe6 schedule+0x2e6 (0xf5b25fac, 0xf5b24000, 0xf7ca4180, 0x0, 0 x0) kernel .text 0xc0100000 0xc011a900 0xc011ae40 0xf5b25fa0 0xc011a888 schedule_timeout+0x58 (0xf7798c00, 0x71, 0x0) kernel .text 0xc0100000 0xc011a830 0xc011a8e0 0xf5b25fdc 0xf8ae2781 [xfs]syncd+0xa1 xfs .text 0xf8a72060 0xf8ae26e0 0xf8ae27d0 0xf5b25ff4 0xc010757e arch_kernel_thread+0x2e kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> I created a filesystem using mkfs.xfs on a 2.7Terabyte md devices (Two 1.5 Terabytes LUN defined in a 3ware 8000 raid controller) and the output was: meta-data=/dev/md0 isize=256 agcount=32, agsize=22888728 blks = sectsz=512 data = bsize=4096 blocks=732439296, imaxpct=25 = sunit=8 swidth=16 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 The bdflush was set to "2 256 512 256 25 100 5 1 0" and the dmesg output was: ]# dmesg INTEL Product ID: S7501HG0 APIC at: 0xFEE00000 I/O APIC #8 Version 32 at 0xFEC00000. I/O APIC #9 Version 32 at 0xFEC81000. I/O APIC #10 Version 32 at 0xFEC81400. Enabling APIC mode: Flat. Using 3 I/O APICs Processors: 2 Kernel command line: ro root=/dev/hda3 console=ttyS0 Initializing CPU#0 Detected 2392.340 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 4771.02 BogoMIPS Memory: 903912k/917504k available (1506k kernel code, 13204k reserved, 1104k dat a, 128k init, 0k highmem) kdb version 4.3 by Keith Owens, Scott Lurndal. Copyright SGI, All Rights Reserve d Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode cache hash table entries: 65536 (order: 7, 524288 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 65536 (order: 6, 262144 bytes) Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 CPU: Common caps: bfebfbff 00000000 00000000 00000000 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 0 Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 CPU: Common caps: bfebfbff 00000000 00000000 00000000 CPU0: Intel(R) Xeon(TM) CPU 2.40GHz stepping 07 per-CPU timeslice cutoff: 1462.89 usecs. enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Booting processor 1/6 eip 2000 Initializing CPU#1 masked ExtINT on CPU#1 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Calibrating delay loop... 4784.12 BogoMIPS CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Physical Processor ID: 3 Intel machine check reporting enabled on CPU#1. CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 CPU: Common caps: bfebfbff 00000000 00000000 00000000 CPU1: Intel(R) Xeon(TM) CPU 2.40GHz stepping 07 Total of 2 processors activated (9555.14 BogoMIPS). WARNING: No sibling found for CPU 0. WARNING: No sibling found for CPU 1. ENABLING IO-APIC IRQs Setting 8 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 8 ... ok. Setting 9 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 9 ... ok. Setting 10 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 10 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 8-0, 8-20, 8-21, 8-22, 9-1, 9-2, 9-3, 9-4, 9-5, 9-6, 9-7, 9-8, 9-9, 9-10, 9-11, 9-12, 9-13, 9-14, 9-15, 9-16, 9-17, 9-18, 9-19, 9-20, 9-21 , 9-22, 9-23, 10-0, 10-1, 10-2, 10-3, 10-4, 10-5, 10-6, 10-7, 10-8, 10-9, 10-12, 10-13, 10-14, 10-15, 10-16, 10-17, 10-18, 10-19, 10-20, 10-21, 10-22, 10-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=0 number of MP IRQ sources: 24. number of IO-APIC #8 registers: 24. number of IO-APIC #9 registers: 24. number of IO-APIC #10 registers: 24. testing the IO APIC....................... IO APIC #8...... .... register #00: 08000000 ....... : physical APIC id: 08 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00178020 ....... : max redirection entries: 0017 ....... : PRQ implemented: 1 ....... : IO APIC version: 0020 .... register #02: 00000000 ....... : arbitration: 00 .... register #03: 00000001 ....... : Boot DT : 1 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 003 03 0 0 0 0 0 1 1 39 02 003 03 0 0 0 0 0 1 1 31 03 003 03 0 0 0 0 0 1 1 41 04 003 03 0 0 0 0 0 1 1 49 05 003 03 0 0 0 0 0 1 1 51 06 003 03 0 0 0 0 0 1 1 59 07 003 03 0 0 0 0 0 1 1 61 08 003 03 0 0 0 0 0 1 1 69 09 003 03 0 0 0 0 0 1 1 71 0a 003 03 0 0 0 0 0 1 1 79 0b 003 03 0 0 0 0 0 1 1 89 0c 003 03 0 0 0 0 0 1 1 91 0d 003 03 0 0 0 0 0 1 1 99 0e 003 03 0 0 0 0 0 1 1 A1 0f 003 03 0 0 0 0 0 1 1 A9 10 003 03 1 1 0 1 0 1 1 B1 11 003 03 1 1 0 1 0 1 1 B9 12 003 03 1 1 0 1 0 1 1 C1 13 003 03 1 1 0 1 0 1 1 C9 14 000 00 1 0 0 0 0 0 0 00 15 07C 0C 1 0 0 0 0 0 2 05 16 000 00 1 0 0 0 0 0 0 00 17 003 03 1 1 0 1 0 1 1 D1 IO APIC #9...... .... register #00: 09000000 ....... : physical APIC id: 09 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00178020 ....... : max redirection entries: 0017 ....... : PRQ implemented: 1 ....... : IO APIC version: 0020 .... register #02: 09000000 ....... : arbitration: 09 .... register #03: 00000001 ....... : Boot DT : 1 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 003 03 1 1 0 1 0 1 1 D9 01 000 00 1 0 0 0 0 0 0 00 02 000 00 1 0 0 0 0 0 0 00 03 000 00 1 0 0 0 0 0 0 00 04 000 00 1 0 0 0 0 0 0 00 05 000 00 1 0 0 0 0 0 0 00 06 000 00 1 0 0 0 0 0 0 00 07 000 00 1 0 0 0 0 0 0 00 08 000 00 1 0 0 0 0 0 0 00 09 000 00 1 0 0 0 0 0 0 00 0a 000 00 1 0 0 0 0 0 0 00 0b 000 00 1 0 0 0 0 0 0 00 0c 000 00 1 0 0 0 0 0 0 00 0d 000 00 1 0 0 0 0 0 0 00 0e 000 00 1 0 0 0 0 0 0 00 0f 000 00 1 0 0 0 0 0 0 00 10 000 00 1 0 0 0 0 0 0 00 11 000 00 1 0 0 0 0 0 0 00 12 000 00 1 0 0 0 0 0 0 00 13 000 00 1 0 0 0 0 0 0 00 14 000 00 1 0 0 0 0 0 0 00 15 000 00 1 0 0 0 0 0 0 00 16 000 00 1 0 0 0 0 0 0 00 17 000 00 1 0 0 0 0 0 0 00 IO APIC #10...... .... register #00: 0A000000 ....... : physical APIC id: 0A ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00178020 ....... : max redirection entries: 0017 ....... : PRQ implemented: 1 ....... : IO APIC version: 0020 .... register #02: 0A000000 ....... : arbitration: 0A .... register #03: 00000001 ....... : Boot DT : 1 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 000 00 1 0 0 0 0 0 0 00 02 000 00 1 0 0 0 0 0 0 00 03 000 00 1 0 0 0 0 0 0 00 04 000 00 1 0 0 0 0 0 0 00 05 000 00 1 0 0 0 0 0 0 00 06 000 00 1 0 0 0 0 0 0 00 07 000 00 1 0 0 0 0 0 0 00 08 000 00 1 0 0 0 0 0 0 00 09 000 00 1 0 0 0 0 0 0 00 0a 003 03 1 1 0 1 0 1 1 E1 0b 003 03 1 1 0 1 0 1 1 E9 0c 000 00 1 0 0 0 0 0 0 00 0d 000 00 1 0 0 0 0 0 0 00 0e 000 00 1 0 0 0 0 0 0 00 0f 000 00 1 0 0 0 0 0 0 00 10 000 00 1 0 0 0 0 0 0 00 11 000 00 1 0 0 0 0 0 0 00 12 000 00 1 0 0 0 0 0 0 00 13 000 00 1 0 0 0 0 0 0 00 14 000 00 1 0 0 0 0 0 0 00 15 000 00 1 0 0 0 0 0 0 00 16 000 00 1 0 0 0 0 0 0 00 17 000 00 1 0 0 0 0 0 0 00 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ5 -> 0:5 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9 IRQ10 -> 0:10 IRQ11 -> 0:11 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 IRQ16 -> 0:16 IRQ17 -> 0:17 IRQ18 -> 0:18 IRQ19 -> 0:19 IRQ23 -> 0:23 IRQ24 -> 1:0 IRQ58 -> 2:10 IRQ59 -> 2:11 .................................... done. Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 2392.2650 MHz. ..... host bus clock speed is 132.9033 MHz. cpu: 0, clocks: 1329033, slice: 443011 CPU0 cpu: 1, clocks: 1329033, slice: 443011 CPU1 checking TSC synchronization across CPUs: passed. Waiting on wait_init_idle (map = 0x2) All processors have done init_idle PCI: PCI BIOS revision 2.10 entry at 0xfdb55, last bus=4 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller 00:1f.1 PCI: Unable to handle 64-bit address space for PCI: Unable to handle 64-bit address space for Transparent bridge - Intel Corp. 82801BA/CA/DB/EB PCI Bridge PCI: Using IRQ router PIIX/ICH [8086/2480] at 00:1f.0 PCI->APIC IRQ transform: (B0,I29,P0) -> 16 PCI->APIC IRQ transform: (B0,I29,P1) -> 19 PCI->APIC IRQ transform: (B0,I29,P2) -> 18 PCI->APIC IRQ transform: (B0,I31,P0) -> 17 PCI->APIC IRQ transform: (B0,I31,P1) -> 17 PCI->APIC IRQ transform: (B4,I5,P0) -> 58 PCI->APIC IRQ transform: (B4,I5,P1) -> 59 PCI->APIC IRQ transform: (B3,I2,P0) -> 24 PCI->APIC IRQ transform: (B1,I12,P0) -> 23 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd VFS: Disk quotas vdquot_6.5.1 i2c-core.o: i2c core module pty: 2048 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI en abled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10f Non-volatile memory driver v1.2 xd: Out of memory. Floppy drive(s): fd0 is 1.44M FDC 0 is a National Semiconductor PC87306 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH3: IDE controller at PCI slot 00:1f.1 PCI: Enabling device 00:1f.1 (0005 -> 0007) ICH3: chipset revision 2 ICH3: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x03a0-0x03a7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x03a8-0x03af, BIOS settings: hdc:DMA, hdd:pio hda: WDC WD400BB-00GFA0, ATA DISK drive blk: queue c04012e0, I/O limit 4095Mb (mask 0xffffffff) hdc: SR244W, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: attached ide-disk driver. hda: host protected area => 1 (40021 MB) w/2048KiB Cache, CHS=4865/255/63, UDMA(100) hdc: attached ide-cdrom driver. hdc: ATAPI 24X CD-ROM drive, 128kB Cache Uniform CD-ROM driver Revision: 3.12 Partition check: hda: hda1 hda2 hda3 Initializing Cryptographic API NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. RAMDISK: Compressed image found at block 0 Freeing initrd memory: 162k freed VFS: Mounted root (ext2 filesystem). SCSI subsystem driver Revision: 1.00 3ware Storage Controller device driver for Linux v1.02.00.037. scsi0 : Found a 3ware Storage Controller at 0x2000, IRQ: 24, P-chip: 1.3 scsi0 : 3ware Storage Controller Vendor: 3ware Model: Logical Disk 0 Rev: 1.0 Type: Direct-Access ANSI SCSI revision: 00 Vendor: 3ware Model: Logical Disk 6 Rev: 1.0 Type: Direct-Access ANSI SCSI revision: 00 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 Attached scsi disk sdb at scsi0, channel 0, id 6, lun 0 SCSI device sda: 2930368512 512-byte hdwr sectors (1500349 MB) sda: sda1 sda2 sda3 SCSI device sdb: 2930368512 512-byte hdwr sectors (1500349 MB) sdb: sdb1 sdb2 sdb3 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: raid0 personality registered as nr 2 reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (device ide0(3,3)) ... for (ide0(3,3)) reiserfs: replayed 27 transactions in 0 seconds ide0(3,3):Using r5 hash to sort names Freeing unused kernel memory: 128k freed usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.275 $ time 20:12:37 Dec 11 2003 usb-uhci.c: High bandwidth mode enabled PCI: Setting latency timer of device 00:1d.0 to 64 usb-uhci.c: USB UHCI at I/O 0x4040, IRQ 16 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected PCI: Setting latency timer of device 00:1d.1 to 64 usb-uhci.c: USB UHCI at I/O 0x4020, IRQ 19 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected PCI: Setting latency timer of device 00:1d.2 to 64 usb-uhci.c: USB UHCI at I/O 0x4000, IRQ 18 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 3 hub.c: USB hub found hub.c: 2 ports detected usb-uhci.c: v1.275:USB Universal Host Controller Interface driver Adding Swap: 2097136k swap-space (priority -1) Intel(R) PRO/1000 Network Driver - version 5.2.20-k1 Copyright (c) 1999-2003 Intel Corporation. eth0: Intel(R) PRO/1000 Network Connection eth1: Intel(R) PRO/1000 Network Connection e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex md: bind md: nonpersistent superblock ... md: bind md: nonpersistent superblock ... md: sdb3's event counter: 00000000 md: sda3's event counter: 00000000 md0: max total readahead window set to 496k md0: 2 data-disks, max readahead per data-disk: 248k raid0: looking at sda3 raid0: comparing sda3(1464879072) with sda3(1464879072) raid0: END raid0: ==> UNIQUE raid0: 1 zones raid0: looking at sdb3 raid0: comparing sdb3(1464879072) with sda3(1464879072) raid0: EQUAL raid0: FINAL 1 zones raid0: zone 0 raid0: checking sda3 ... contained as device 0 (1464879072) is smallest!. raid0: checking sdb3 ... contained as device 1 raid0: zone->nb_dev: 2, size: -1365209152 raid0: current zone offset: 1464879072 raid0: done. raid0 : md_size is 2929758144 blocks. raid0 : conf->smallest->size is -1365209152 blocks. raid0 : nb_zone is 1. raid0 : Allocating 8 bytes for hash. SGI-XFS CVS-2003-11-24_06:00_UTC with ACLs, large block numbers, no debug enable d SGI XFS Quota Management subsystem XFS mounting filesystem md(9,0) Ending clean XFS mount for filesystem: md(9,0) I do not if someone can help me trying to debug or/and fix this problems Thank you Gustavo Rincon From owner-linux-xfs@oss.sgi.com Mon Dec 15 13:50:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 13:50:35 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFLoCTa030542 for ; Mon, 15 Dec 2003 13:50:13 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hBFLmQSL007232; Mon, 15 Dec 2003 15:48:26 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hBFLmMTU007230; Mon, 15 Dec 2003 15:48:22 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: XFS , QLA2200 and SMP From: Austin Gonyou To: strack@tzv.fal.de Cc: debian-user@lists.debian.org, XFS List In-Reply-To: <200312111119.45429.most@tzv.fal.de> References: <200312111119.45429.most@tzv.fal.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1071524902.6376.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 15 Dec 2003 15:48:22 -0600 X-archive-position: 1430 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1935 Lines: 47 Just FYI, sorry for replying to this so late, the modules.conf(<6.06.00) or qla2[2,3]00.conf(6.06.00+) file when used with the SANSurfer software is where it writes module specific config information. I was just curious if these options might've impacted you here at all. but it doesn't sound like you're even using any. I suppose another question is are you direct connected or swtiched? I had an issue where my LIP logins were re-curring while up and after having too many hosts in the same zone, I had to do explicit port zones to prevent IO quashing. After that, no problems, but odd symptoms because any server could cause it and any server could be affected. just another aspect if you're using switches with no, or very broad, zones. On Thu, 2003-12-11 at 04:19, Monika Strack wrote: > Am Mittwoch, 10. Dezember 2003 18:16 schrieb Austin Gonyou: > > Which FS is it that you're writing to? A NFS, or is it local and > being > > shared as NFS? Something seems very odd in that stack trace given > the > > oops that you have. > > I write to a local XFS , it is no shared as nfs. I read the data from > a NFS > mounted disk. > > I don't have anythink in my modules.conf for qla2200. As I understand > the > README I only need it for initrd-kernel. I don't use initrd for this > machine. > I loadet the driver with modprob by hand with no ql2xopts. The Card is > for > connetion to the the external RAID with userdata only. > > Monika > -- > ________________________________________________________________________________ > Monika Strack > Institut fuer Tierzucht > Bundesforschungsanstalt fuer Landwirschaft > > 31535 Neustadt e-mail: most@tzv.fal.de > Germany Tel: +49 5034 /871 154 > Fax: +49 5034 /871 239 > _______________________________________________________________________________ -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Mon Dec 15 14:06:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 14:06:28 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFM6HTa031214 for ; Mon, 15 Dec 2003 14:06:17 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBFNNem7000823 for ; Mon, 15 Dec 2003 17:23:40 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBFM6BSC20806775; Mon, 15 Dec 2003 16:06:11 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBFM62K110523078; Mon, 15 Dec 2003 16:06:02 -0600 (CST) Subject: Re: LBD patch and XFS problem! From: Eric Sandeen To: Gustavo Rincon Cc: "'linux-xfs@oss.sgi.com'" , Tony Lambert , Ben McMillan In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1071525970.13290.375.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Dec 2003 16:06:10 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1431 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1301 Lines: 36 On Mon, 2003-12-15 at 14:46, Gustavo Rincon wrote: > Hi, I need some help with XFS and LBD patch. Whoohoo, we've just been discussing this... :) > I was doing some testing with the linux-2.4.24-pre1+xfs + LBD patch (gotten > from ) Which LBD patch did you use? There is no 2.4.24-pre1 LBD patch. There may already be some problems there, the LBD patch used to make itself known via HAVE_SECTOR_T, but that's not there anymore. So now the conditional code in XFS for LBD doesn't work, and xfs has no way to know that LBD is present. Check your LBD patch for a definition of HAVE_SECTOR_T.... We're probably going to remove all the LBD bits from 2.4 xfs, and push the changes into Peter's patch, since xfs is now in 2.4.24 - I'll try to get an updated patch to him soon. In the meantime, you can probably fix things up by looking for #ifdef HAVE_SECTOR_T conditionals in XFS, and making them always true (either by removing the tests, or defining it yourself in, say, xfs_linux.h) That's just off the top of my head, no promises. Until that's fixed, I'm not inclined to dig through all the stacks posted below. :) -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Dec 15 14:27:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 14:27:17 -0800 (PST) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBFMR5Ta032213 for ; Mon, 15 Dec 2003 14:27:06 -0800 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id hBFMP2hl009559; Mon, 15 Dec 2003 23:25:02 +0100 Message-ID: <3FDE3584.6010208@stesmi.com> Date: Mon, 15 Dec 2003 23:28:20 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Gustavo Rincon , "'linux-xfs@oss.sgi.com'" , Tony Lambert , Ben McMillan Subject: Re: LBD patch and XFS problem! References: <1071525970.13290.375.camel@stout.americas.sgi.com> In-Reply-To: <1071525970.13290.375.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1432 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1331 Lines: 43 Eric Sandeen wrote: > On Mon, 2003-12-15 at 14:46, Gustavo Rincon wrote: > >>Hi, I need some help with XFS and LBD patch. > > > Whoohoo, we've just been discussing this... :) > > >>I was doing some testing with the linux-2.4.24-pre1+xfs + LBD patch (gotten >>from ) > > > Which LBD patch did you use? There is no 2.4.24-pre1 LBD patch. > > There may already be some problems there, the LBD patch used to make > itself known via HAVE_SECTOR_T, but that's not there anymore. So now > the conditional code in XFS for LBD doesn't work, and xfs has no way to > know that LBD is present. Check your LBD patch for a definition of > HAVE_SECTOR_T.... > > We're probably going to remove all the LBD bits from 2.4 xfs, and push > the changes into Peter's patch, since xfs is now in 2.4.24 - I'll try to > get an updated patch to him soon. > > In the meantime, you can probably fix things up by looking for > #ifdef HAVE_SECTOR_T > conditionals in XFS, and making them always true (either by removing the > tests, or defining it yourself in, say, xfs_linux.h) > > That's just off the top of my head, no promises. > > Until that's fixed, I'm not inclined to dig through all the stacks > posted below. :) > > -Eric > Or simply add -DHAVE_SECTOR_T to the Makefile ... // Stefan From owner-linux-xfs@oss.sgi.com Mon Dec 15 17:07:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 17:07:30 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBG178Ta007523 for ; Mon, 15 Dec 2003 17:07:09 -0800 Received: from naboo.americas.sgi.com ([128.162.233.73]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBG2OWm7031658 for ; Mon, 15 Dec 2003 20:24:32 -0600 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id E735E8EBEAA; Mon, 15 Dec 2003 20:06:42 -0500 (EST) Subject: PARTIAL TAKE 904566 - Merge the the 2.4 and 2.6 trees Message-Id: <20031216010642.E735E8EBEAA@naboo.americas.sgi.com> Date: Mon, 15 Dec 2003 20:06:42 -0500 (EST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1433 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@naboo.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 5250 Lines: 153 Delete imported files so they can re-named Date: Mon Dec 15 16:57:46 PST 2003 Workarea: naboo.americas.sgi.com:/go/space/XFS/xfs-linux-new The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:163557a Makefile-linux-2.4 - 1.197 xfs_behavior.c - 1.22 xfs_behavior.h - 1.17 xfs_iomap.c - 1.21 linux-2.4/xfs_lrw.h - 1.40 linux-2.4/xfs_lrw.c - 1.209 linux-2.4/xfs_version.h - 1.170 linux-2.4/xfs_ioctl.c - 1.101 linux-2.4/xfs_vfs.h - 1.47 linux-2.4/xfs_vfs.c - 1.50 linux-2.4/xfs_globals.h - 1.21 linux-2.4/xfs_globals.c - 1.65 linux-2.4/xfs_linux.h - 1.123 linux-2.4/Makefile - 1.197 linux-2.4/page_buf.c - 1.147 linux-2.4/page_buf.h - 1.82 linux-2.4/xfs_file.c - 1.101 linux-2.4/xfs_cred.h - 1.25 linux-2.4/xfs_vnode.c - 1.123 linux-2.4/xfs_vnode.h - 1.89 linux-2.4/xfs_stats.c - 1.17 linux-2.4/xfs_stats.h - 1.11 linux-2.4/xfs_fs_subr.c - 1.41 linux-2.4/xfs_fs_subr.h - 1.14 linux-2.4/xfs_super.h - 1.55 linux-2.4/xfs_super.c - 1.277 linux-2.4/xfs_behavior.c - 1.22 linux-2.4/xfs_behavior.h - 1.17 linux-2.4/xfs_iops.c - 1.202 linux-2.4/xfs_iops.h - 1.26 linux-2.4/xfs_aops.c - 1.63 linux-2.4/xfs_iomap.c - 1.21 linux-2.4/xfs_sysctl.c - 1.32 linux-2.4/xfs_sysctl.h - 1.23 Subject: TAKE 904566 - Move the files around to finalize the 2.4/2.6 merge Date: Mon Dec 15 17:05:04 PST 2003 Workarea: naboo.americas.sgi.com:/go/space/XFS/xfs-linux-new The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:163559a linux/Makefile 1.197 renamed to linux-2.4/Makefile 1.198 - linux/Makefile 1.196 Renamed to linux-2.4/Makefile Makefile 1.57 renamed to Makefile-linux-2.4 1.198 - Makefile 1.56 Renamed to Makefile-linux-2.4 pagebuf/page_buf.c 1.147 renamed to linux-2.4/page_buf.c 1.148 - pagebuf/page_buf.c 1.146 Renamed to linux-2.4/page_buf.c pagebuf/page_buf.h 1.82 renamed to linux-2.4/page_buf.h 1.83 - pagebuf/page_buf.h 1.81 Renamed to linux-2.4/page_buf.h linux/xfs_lrw.h 1.40 renamed to linux-2.4/xfs_lrw.h 1.41 - linux/xfs_lrw.h 1.39 Renamed to linux-2.4/xfs_lrw.h linux/xfs_lrw.c 1.209 renamed to linux-2.4/xfs_lrw.c 1.210 - linux/xfs_lrw.c 1.208 Renamed to linux-2.4/xfs_lrw.c linux/xfs_version.h 1.170 renamed to linux-2.4/xfs_version.h 1.171 - linux/xfs_version.h 1.169 Renamed to linux-2.4/xfs_version.h linux/xfs_ioctl.c 1.101 renamed to linux-2.4/xfs_ioctl.c 1.102 - linux/xfs_ioctl.c 1.100 Renamed to linux-2.4/xfs_ioctl.c linux/xfs_vfs.h 1.47 renamed to linux-2.4/xfs_vfs.h 1.48 - linux/xfs_vfs.h 1.46 Renamed to linux-2.4/xfs_vfs.h linux/xfs_vfs.c 1.50 renamed to linux-2.4/xfs_vfs.c 1.51 - linux/xfs_vfs.c 1.49 Renamed to linux-2.4/xfs_vfs.c linux/xfs_globals.h 1.21 renamed to linux-2.4/xfs_globals.h 1.22 - linux/xfs_globals.h 1.20 Renamed to linux-2.4/xfs_globals.h linux/xfs_globals.c 1.65 renamed to linux-2.4/xfs_globals.c 1.66 - linux/xfs_globals.c 1.64 Renamed to linux-2.4/xfs_globals.c linux/xfs_linux.h 1.123 renamed to linux-2.4/xfs_linux.h 1.124 - linux/xfs_linux.h 1.122 Renamed to linux-2.4/xfs_linux.h linux/xfs_file.c 1.101 renamed to linux-2.4/xfs_file.c 1.102 - linux/xfs_file.c 1.100 Renamed to linux-2.4/xfs_file.c linux/xfs_cred.h 1.25 renamed to linux-2.4/xfs_cred.h 1.26 - linux/xfs_cred.h 1.24 Renamed to linux-2.4/xfs_cred.h linux/xfs_vnode.c 1.123 renamed to linux-2.4/xfs_vnode.c 1.124 - linux/xfs_vnode.c 1.122 Renamed to linux-2.4/xfs_vnode.c linux/xfs_vnode.h 1.89 renamed to linux-2.4/xfs_vnode.h 1.90 - linux/xfs_vnode.h 1.88 Renamed to linux-2.4/xfs_vnode.h linux/xfs_stats.c 1.17 renamed to linux-2.4/xfs_stats.c 1.18 - linux/xfs_stats.c 1.16 Renamed to linux-2.4/xfs_stats.c linux/xfs_stats.h 1.11 renamed to linux-2.4/xfs_stats.h 1.12 - linux/xfs_stats.h 1.10 Renamed to linux-2.4/xfs_stats.h linux/xfs_fs_subr.c 1.41 renamed to linux-2.4/xfs_fs_subr.c 1.42 - linux/xfs_fs_subr.c 1.40 Renamed to linux-2.4/xfs_fs_subr.c linux/xfs_fs_subr.h 1.14 renamed to linux-2.4/xfs_fs_subr.h 1.15 - linux/xfs_fs_subr.h 1.13 Renamed to linux-2.4/xfs_fs_subr.h linux/xfs_super.h 1.55 renamed to linux-2.4/xfs_super.h 1.56 - linux/xfs_super.h 1.54 Renamed to linux-2.4/xfs_super.h linux/xfs_super.c 1.277 renamed to linux-2.4/xfs_super.c 1.278 - linux/xfs_super.c 1.276 Renamed to linux-2.4/xfs_super.c linux/xfs_behavior.c 1.22 renamed to xfs_behavior.c 1.23 - linux/xfs_behavior.c 1.21 Renamed to xfs_behavior.c linux/xfs_behavior.h 1.17 renamed to xfs_behavior.h 1.18 - linux/xfs_behavior.h 1.16 Renamed to xfs_behavior.h linux/xfs_iops.c 1.202 renamed to linux-2.4/xfs_iops.c 1.203 - linux/xfs_iops.c 1.201 Renamed to linux-2.4/xfs_iops.c linux/xfs_iops.h 1.26 renamed to linux-2.4/xfs_iops.h 1.27 - linux/xfs_iops.h 1.25 Renamed to linux-2.4/xfs_iops.h linux/xfs_aops.c 1.63 renamed to linux-2.4/xfs_aops.c 1.64 - linux/xfs_aops.c 1.62 Renamed to linux-2.4/xfs_aops.c linux/xfs_iomap.c 1.21 renamed to xfs_iomap.c 1.22 - linux/xfs_iomap.c 1.20 Renamed to xfs_iomap.c linux/xfs_sysctl.c 1.32 renamed to linux-2.4/xfs_sysctl.c 1.33 - linux/xfs_sysctl.c 1.31 Renamed to linux-2.4/xfs_sysctl.c linux/xfs_sysctl.h 1.23 renamed to linux-2.4/xfs_sysctl.h 1.24 - linux/xfs_sysctl.h 1.22 Renamed to linux-2.4/xfs_sysctl.h From owner-linux-xfs@oss.sgi.com Mon Dec 15 17:22:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 17:22:24 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBG1M0Ta008262 for ; Mon, 15 Dec 2003 17:22:00 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id hBG2dMm7010119 for ; Mon, 15 Dec 2003 20:39:23 -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 MAA21802; Tue, 16 Dec 2003 12:21:51 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hBG1LnUc2221235; Tue, 16 Dec 2003 12:21:49 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id hBG1LGPx001328; Tue, 16 Dec 2003 12:21:17 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id hBG1LEPZ001326; Tue, 16 Dec 2003 12:21:14 +1100 Date: Tue, 16 Dec 2003 12:21:14 +1100 From: Nathan Scott To: Eric Sandeen , Emilio Gargiulo Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.24-pre1 hangs with XFS on LVM filesystem full Message-ID: <20031216012114.GA566@frodo> References: <200312152200.08411.emiliogargiulo@supereva.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312152200.08411.emiliogargiulo@supereva.it> User-Agent: Mutt/1.5.3i X-archive-position: 1434 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 682 Lines: 19 On Mon, Dec 15, 2003 at 10:00:08PM +0100, Emilio Gargiulo wrote: > Yes, a simple overfill of a XFS filesystem on LVM hangs the kernel. > It is easy to reproduce with dd if=/dev/zero of=file_on_dest_xfs_filesystem > bs=1024k. > ... > I compiled the kernel with gcc 3.2.3. (Slackware 9.1) > I am unable to reproduce the problem if I compile the kernel with gcc 3.3.1. Hmm, that would seem to be an important piece of information - could be a gcc-3.2.3 compiler bug. Since noone here is able to trigger this problem with other compilers too (and under a lot more varied conditions around the ENOSPC boundaries), I suppose a gcc bug is a real possibility here. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Dec 15 22:12:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Dec 2003 22:12:43 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBG6CVTa015834 for ; Mon, 15 Dec 2003 22:12:31 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBG7Tum7021031 for ; Tue, 16 Dec 2003 01:29:56 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBG6CPSC20985768 for ; Tue, 16 Dec 2003 00:12:25 -0600 (CST) Received: from sgi.com (chuckle.americas.sgi.com [128.162.241.66]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBG6CFoZ695480; Tue, 16 Dec 2003 00:12:15 -0600 (CST) Received: from chuckle.americas.sgi.com (localhost [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id hBG6CNbc014894; Tue, 16 Dec 2003 00:12:23 -0600 Received: (from cattelan@localhost) by chuckle.americas.sgi.com (8.12.8/8.12.8/Submit) id hBG6CMdr014892; Tue, 16 Dec 2003 00:12:22 -0600 Date: Tue, 16 Dec 2003 00:12:22 -0600 From: Russell Cattelan Message-Id: <200312160612.hBG6CMdr014892@chuckle.americas.sgi.com> Subject: PARTIAL TAKE 904566 - Get the merge tree building for 2.4 X-archive-position: 1435 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@chuckle.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 818 Lines: 35 Fix up Makefiles and include files to deal with merged tree Date: Mon Dec 15 22:10:03 PST 2003 Workarea: chuckle.americas.sgi.com:/go/space/XFS/xfs-linux-new The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:163569a Makefile - 1.58 Subject: PARTIAL TAKE 904566 - Fix up Makefiles and include files to deal with merged tree Date: Mon Dec 15 22:11:00 PST 2003 Workarea: chuckle.americas.sgi.com:/go/space/XFS/xfs-linux-new The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:163570a xfs.h - 1.41 support/Makefile - 1.17 quota/Makefile - 1.5 dmapi/Makefile - 1.22 Makefile-linux-2.6 - 1.182 Makefile-linux-2.4 - 1.199 linux-2.4/xfs_linux.h - 1.125 linux-2.4/Makefile - 1.199 From owner-linux-xfs@oss.sgi.com Tue Dec 16 05:04:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 05:04:32 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGD4ATa017284 for ; Tue, 16 Dec 2003 05:04:11 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 42FB3141B122 for ; Tue, 16 Dec 2003 08:04:10 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 867C1141B120; Tue, 16 Dec 2003 08:04:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 84B7C30002B5 for ; Tue, 16 Dec 2003 08:04:08 -0500 (EST) Date: Tue, 16 Dec 2003 08:04:08 -0500 (EST) From: Mike Burger To: linux-xfs@oss.sgi.com Subject: ATrpms kernel and quota oddity Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1436 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 1335 Lines: 40 I'm wondering if anyone else has run into this with Axel's kernel(s). I ran into it after compiling his 2.4.20-24_30 src.rpm for use with RH7.1. After installing the kernel, I rebooted, and got messages that my /var and /home partitions couldn't be mounted, noting wrong fs type, bad superblock, etc. I could not even issue a simple "mount /home"...got the same error. I could, however, "mount -t xfs /dev/hda3 /home". I finagled for a bit last night, including adding a couple of mount statements to /etc/rc.sysinit, just so that I could mount at boot time. This morning, I monkeyed around a bit more, and removed the "usrquota" from the options I had set in my fstab file. Now, the filesystems mount just fine. While I'm not at any risk of running out of disk space in either filesystem, from users or otherwise, I would still prefer to be able to set and enforce quotas on this system. So, does anyone have any ideas on what might be going on and/or how to fix it? -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Tue Dec 16 05:33:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 05:33:48 -0800 (PST) Received: from tempgw.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGDXZTa020797 for ; Tue, 16 Dec 2003 05:33:36 -0800 Received: from Unknown [172.20.0.8] by tempgw.ciprico.com - SurfControl E-mail Filter (4.7); Tue, 16 Dec 2003 07:34:37 -0600 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Dec 2003 07:33:02 -0600 Message-ID: From: Gustavo Rincon To: "'Eric Sandeen'" , Gustavo Rincon Cc: "'linux-xfs@oss.sgi.com'" , Tony Lambert , Ben McMillan Date: Tue, 16 Dec 2003 07:33:01 -0600 Subject: RE: LBD patch and XFS problem! MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 1437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: grincon@ciprico.com Precedence: bulk X-list: linux-xfs Content-Length: 1957 Lines: 61 Yes I'm using LBD patch for 2.4.23 and I did make the change in include/linux/types.h in order to enable the HAVE_SECTOR_T. The LBD is working, I'm able to create ext3 filesystem on the device and the size of it is 2.7Terabye and by the way I ran the test successfully for 4 days in a row. I'll change xfs_types.h and i' ll force to have the HAVE_SECTOR_T definition and i'll try the test again. Thank you Gustavo Rincon -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Monday, December 15, 2003 5:06 PM To: Gustavo Rincon Cc: 'linux-xfs@oss.sgi.com'; Tony Lambert; Ben McMillan Subject: Re: LBD patch and XFS problem! On Mon, 2003-12-15 at 14:46, Gustavo Rincon wrote: > Hi, I need some help with XFS and LBD patch. Whoohoo, we've just been discussing this... :) > I was doing some testing with the linux-2.4.24-pre1+xfs + LBD patch (gotten > from ) Which LBD patch did you use? There is no 2.4.24-pre1 LBD patch. There may already be some problems there, the LBD patch used to make itself known via HAVE_SECTOR_T, but that's not there anymore. So now the conditional code in XFS for LBD doesn't work, and xfs has no way to know that LBD is present. Check your LBD patch for a definition of HAVE_SECTOR_T.... We're probably going to remove all the LBD bits from 2.4 xfs, and push the changes into Peter's patch, since xfs is now in 2.4.24 - I'll try to get an updated patch to him soon. In the meantime, you can probably fix things up by looking for #ifdef HAVE_SECTOR_T conditionals in XFS, and making them always true (either by removing the tests, or defining it yourself in, say, xfs_linux.h) That's just off the top of my head, no promises. Until that's fixed, I'm not inclined to dig through all the stacks posted below. :) -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Dec 16 06:28:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 06:29:18 -0800 (PST) Received: from tempgw.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGEStTa023369 for ; Tue, 16 Dec 2003 06:28:55 -0800 Received: from Unknown [172.20.0.8] by tempgw.ciprico.com - SurfControl E-mail Filter (4.7); Tue, 16 Dec 2003 08:29:51 -0600 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Dec 2003 08:28:16 -0600 Message-ID: From: Gustavo Rincon To: "'Eric Sandeen'" , Gustavo Rincon Cc: "'linux-xfs@oss.sgi.com'" , Tony Lambert , Ben McMillan , "'Stefan Smietanowski'" Date: Tue, 16 Dec 2003 08:28:15 -0600 Subject: RE: LBD patch and XFS problem! MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=_NextPart_ST_08_29_52_Tuesday_December_16_2003_28085" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 1438 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: grincon@ciprico.com Precedence: bulk X-list: linux-xfs Content-Length: 37069 Lines: 834 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ----=_NextPart_ST_08_29_52_Tuesday_December_16_2003_28085 Content-Type: text/plain; charset="iso-8859-1" Hi, I did the HAVE_SECTOR_T definition in all the xfs Makefiles and the test failed in the same way that before. Here is some information gotten from kdb (Look into the attachment) All the help that you can get me it is highly appreciated. Thank you Gustavo Rincon -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Monday, December 15, 2003 5:06 PM To: Gustavo Rincon Cc: 'linux-xfs@oss.sgi.com'; Tony Lambert; Ben McMillan Subject: Re: LBD patch and XFS problem! On Mon, 2003-12-15 at 14:46, Gustavo Rincon wrote: > Hi, I need some help with XFS and LBD patch. Whoohoo, we've just been discussing this... :) > I was doing some testing with the linux-2.4.24-pre1+xfs + LBD patch (gotten > from ) Which LBD patch did you use? There is no 2.4.24-pre1 LBD patch. There may already be some problems there, the LBD patch used to make itself known via HAVE_SECTOR_T, but that's not there anymore. So now the conditional code in XFS for LBD doesn't work, and xfs has no way to know that LBD is present. Check your LBD patch for a definition of HAVE_SECTOR_T.... We're probably going to remove all the LBD bits from 2.4 xfs, and push the changes into Peter's patch, since xfs is now in 2.4.24 - I'll try to get an updated patch to him soon. In the meantime, you can probably fix things up by looking for #ifdef HAVE_SECTOR_T conditionals in XFS, and making them always true (either by removing the tests, or defining it yourself in, say, xfs_linux.h) That's just off the top of my head, no promises. Until that's fixed, I'm not inclined to dig through all the stacks posted below. :) -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 ----=_NextPart_ST_08_29_52_Tuesday_December_16_2003_28085 Content-Type: application/octet-stream; name="sgi2" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="sgi2" p Only 'q' or 'Q' are processed at more prompt, input ignored 0xf6534000 689 1 0 1 R 0xf6534280 agetty 0xf5f30000 690 1 0 0 S 0xf5f30280 login 0xf5e96000 691 1 0 0 S 0xf5e96280 mingetty 0xf5e58000 692 1 0 1 S 0xf5e58280 mingetty 0xf5dbc000 695 690 0 0 S 0xf5dbc280 bash 0xf57b2000 744 1 0 1 R 0xf57b2280 pagebufd 0xf57b0000 745 1 0 0 S 0xf57b0280 xfslogd/0 0xf57ae000 746 1 0 1 S 0xf57ae280 xfslogd/1 0xf57ac000 747 1 0 0 S 0xf57ac280 xfsdatad/0 0xf57aa000 748 1 0 1 S 0xf57aa280 xfsdatad/1 0xf59b0000 765 1 0 1 S 0xf59b0280 xfssyncd 0xe50e8000 771 1 0 1 R 0xe50e8280 nmbd 0xe4ce6000 773 1 0 1 S 0xe4ce6280 smbd 0xe44e4000 775 773 0 0 R 0xe44e4280 smbd 0xe38e2000 776 773 0 1 R 0xe38e2280 smbd 0xd6d20000 780 773 0 1 R 0xd6d20280 smbd 0xe12a2000 782 773 0 1 R 0xe12a2280 smbd 0xc54fe000 785 695 0 1 R 0xc54fe280 iostat [0]kdb> p[0]kdb> ps[0]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xc19ea000 7 1 1 0 R 0xc19ea280 *kupdated 0xc19ec000 6 1 1 1 R 0xc19ec280 bdflush 0xf7ff2000 1 0 0 1 R 0xf7ff2280 init 0xc19b2000 2 1 0 1 R 0xc19b2280 keventd 0xc19b0000 3 1 0 0 S 0xc19b0280 ksoftirqd_CPU0 0xc19fe000 4 1 0 1 S 0xc19fe280 ksoftirqd_CPU1 0xc19ee000 5 1 0 1 S 0xc19ee280 kswapd 0xc19ec000 6 1 1 1 R 0xc19ec280 bdflush 0xc19ea000 7 1 1 0 R 0xc19ea280 *kupdated 0xf7648000 13 1 0 1 S 0xf7648280 scsi_eh_0 0xf7504000 15 1 0 1 S 0xf7504280 mdrecoveryd 0xf7374000 17 1 0 1 R 0xf7374280 kreiserfsd 0xf798e000 60 1 0 0 S 0xf798e280 khubd 0xf7794000 535 1 0 0 S 0xf7794280 syslogd 0xf6606000 539 1 0 1 S 0xf6606280 klogd 0xf6548000 548 1 0 0 S 0xf6548280 portmap 0xf6454000 567 1 0 0 S 0xf6454280 rpc.statd 0xf5fb0000 648 1 0 0 S 0xf5fb0280 sshd 0xf5eee000 663 1 0 1 S 0xf5eee280 xinetd 0xf5efe000 673 1 0 1 S 0xf5efe280 crond 0xf5e82000 682 1 0 1 S 0xf5e82280 anacron [0]more>=20 0xf6534000 689 1 0 1 R 0xf6534280 agetty 0xf5f30000 690 1 0 0 S 0xf5f30280 login 0xf5e96000 691 1 0 0 S 0xf5e96280 mingetty 0xf5e58000 692 1 0 1 S 0xf5e58280 mingetty 0xf5dbc000 695 690 0 0 S 0xf5dbc280 bash 0xf57b2000 744 1 0 1 R 0xf57b2280 pagebufd 0xf57b0000 745 1 0 0 S 0xf57b0280 xfslogd/0 0xf57ae000 746 1 0 1 S 0xf57ae280 xfslogd/1 0xf57ac000 747 1 0 0 S 0xf57ac280 xfsdatad/0 0xf57aa000 748 1 0 1 S 0xf57aa280 xfsdatad/1 0xf59b0000 765 1 0 1 S 0xf59b0280 xfssyncd 0xe50e8000 771 1 0 1 R 0xe50e8280 nmbd 0xe4ce6000 773 1 0 1 S 0xe4ce6280 smbd 0xe44e4000 775 773 0 0 R 0xe44e4280 smbd 0xe38e2000 776 773 0 1 R 0xe38e2280 smbd 0xd6d20000 780 773 0 1 R 0xd6d20280 smbd 0xe12a2000 782 773 0 1 R 0xe12a2280 smbd 0xc54fe000 785 695 0 1 R 0xc54fe280 iostat [0]kdb> b[0]kdb> bt[0]kdb> bt Stack traceback for pid 7 0xc19ea000 7 1 1 0 R 0xc19ea280 *kupdated ESP EIP Function (args) 0xc19ebc8c 0xf8aefda4 [xfs]xfs_imap_to_bmap+0xb4 (0xf5813b94, 0x4d0c0000, 0= x1, 0 xc19ebd24, 0xc19ebe08) xfs .text 0xf8a84060 0xf8aefcf0 0xf8aeff90 0xc19ebcd4 0xf8af01ef [xfs]xfs_iomap+0x25f xfs .text 0xf8a84060 0xf8aeff90 0xf8af04f0 0xc19ebd58 0xf8af3f85 [xfs]xfs_bmap+0x45 (0xf5813ab0, 0x4d0c0000, 0x1, 0x10= 00, 0 x4) xfs .text 0xf8a84060 0xf8af3f40 0xf8af3f90 0xc19ebd78 0xf8aeb563 [xfs]map_blocks+0x63 (0xf5816b20, 0x4d0c0000, 0x1, 0x= 1000, 0xc19ebe08) xfs .text 0xf8a84060 0xf8aeb500 0xf8aeb5f0 0xc19ebdac 0xf8aec44d [xfs]page_state_convert+0x42d (0xf5816b20, 0xc1951c58= , 0x1 , 0x0, 0x1) xfs .text 0xf8a84060 0xf8aec020 0xf8aec5d0 0xc19ebe5c 0xf8aecb36 [xfs]linvfs_writepage+0x86 (0xc1951c58, 0x0, 0x0, 0x0= , 0xc 03c9980) xfs .text 0xf8a84060 0xf8aecab0 0xf8aecbe0 0xc19ebe8c 0xc0145b9a write_some_buffers+0xca (0x0, 0x0) kernel .text 0xc0100000 0xc0145ad0 0xc0145c00 0xc19ebf30 0xc0149686 sync_old_buffers+0x76 (0xc0359a20, 0x0, 0x0, 0xc19ea5= 74, 0 x0) kernel .text 0xc0100000 0xc0149610 0xc01496c0 0xc19ebf40 0xc0149985 kupdate+0xf5 kernel .text 0xc0100000 0xc0149890 0xc0149a20 0xc19ebff4 0xc010757e arch_kernel_thread+0x2e [0]more>=20 kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> p[0]kdb> pb[0]kdb> pb=08 [0]kdb> p=08 [0]kdb> b[0]kdb> bt[0]kdb> bt= p[0]kdb> btp [0]kdb> btp 7[0]kdb> btp 74[0]kdb> btp 744[0]kdb> btp 744 Stack traceback for pid 744 0xf57b2000 744 1 0 1 R 0xf57b2280 pagebufd ESP EIP Function (args) 0xf57b3f3c 0xc011abe6 schedule+0x2e6 (0x0, 0xf57b2000, 0xf8b1164c, 0xf8b116= 4c, 0 xf57b3fb8) kernel .text 0xc0100000 0xc011a900 0xc011ae40 0xf57b3f8c 0xc011b11e interruptible_sleep_on+0x4e (0xf57b3fc0, 0xaff4, 0xf5= 9c600 0, 0xf57b3fb8, 0xf57b3fb8) kernel .text 0xc0100000 0xc011b0d0 0xc011b150 0xf57b3fac 0xf8aea491 [xfs]pagebuf_daemon+0x1b1 xfs .text 0xf8a84060 0xf8aea2e0 0xf8aea560 0xf57b3ff4 0xc010757e arch_kernel_thread+0x2e kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> [0]kdb> btp 744=08 [0]kdb> btp 745[0]kdb> btp 745 Stack traceback for pid 745 0xf57b0000 745 1 0 0 S 0xf57b0280 xfslogd/0 ESP EIP Function (args) 0xf57b1f48 0xc011abe6 schedule+0x2e6 (0xf8b12334, 0xf8b02a92, 0xf8b02a98, 0= x0, 0 x0) kernel .text 0xc0100000 0xc011a900 0xc011ae40 0xf57b1f98 0xf8aea17a [xfs]pagebuf_iodone_daemon+0x13a xfs .text 0xf8a84060 0xf8aea040 0xf8aea1d0 0xf57b1fdc 0xf8aea263 [xfs]pagebuf_logiodone_daemon+0x33 xfs .text 0xf8a84060 0xf8aea230 0xf8aea270 0xf57b1ff4 0xc010757e arch_kernel_thread+0x2e kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> [0]kdb> btp 745=08 [0]kdb> btp 746[0]kdb> btp 746 Stack traceback for pid 746 0xf57ae000 746 1 0 1 S 0xf57ae280 xfslogd/1 ESP EIP Function (args) 0xf57aff48 0xc011abe6 schedule+0x2e6 (0xf57ae24a, 0xf8b02a92, 0xf8b02a98, 0= x1, 0 x0) kernel .text 0xc0100000 0xc011a900 0xc011ae40 0xf57aff98 0xf8aea17a [xfs]pagebuf_iodone_daemon+0x13a xfs .text 0xf8a84060 0xf8aea040 0xf8aea1d0 0xf57affdc 0xf8aea263 [xfs]pagebuf_logiodone_daemon+0x33 xfs .text 0xf8a84060 0xf8aea230 0xf8aea270 0xf57afff4 0xc010757e arch_kernel_thread+0x2e kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> [0]kdb> btp 746=08 [0]kdb> btp 747[0]kdb> btp 747 Stack traceback for pid 747 0xf57ac000 747 1 0 0 S 0xf57ac280 xfsdatad/0 ESP EIP Function (args) 0xf57adf48 0xc011abe6 schedule+0x2e6 (0xf57ac24a, 0xf8b02a92, 0xf8b02aa0, 0= x0, 0 x0) kernel .text 0xc0100000 0xc011a900 0xc011ae40 0xf57adf98 0xf8aea17a [xfs]pagebuf_iodone_daemon+0x13a xfs .text 0xf8a84060 0xf8aea040 0xf8aea1d0 0xf57adfdc 0xf8aea2a3 [xfs]pagebuf_dataiodone_daemon+0x33 xfs .text 0xf8a84060 0xf8aea270 0xf8aea2b0 0xf57adff4 0xc010757e arch_kernel_thread+0x2e kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> [0]kdb> btp 747=08 [0]kdb> btp 748[0]kdb> btp 748 Stack traceback for pid 748 0xf57aa000 748 1 0 1 S 0xf57aa280 xfsdatad/1 ESP EIP Function (args) 0xf57abf48 0xc011abe6 schedule+0x2e6 (0xf57aa24a, 0xf8b02a92, 0xf8b02aa0, 0= x1, 0 x0) kernel .text 0xc0100000 0xc011a900 0xc011ae40 0xf57abf98 0xf8aea17a [xfs]pagebuf_iodone_daemon+0x13a xfs .text 0xf8a84060 0xf8aea040 0xf8aea1d0 0xf57abfdc 0xf8aea2a3 [xfs]pagebuf_dataiodone_daemon+0x33 xfs .text 0xf8a84060 0xf8aea270 0xf8aea2b0 0xf57abff4 0xc010757e arch_kernel_thread+0x2e kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> [0]kdb> btp 748=08 [0]kdb> btp 749[0]kdb> btp 749 No process with pid =3D=3D 749 found [0]kdb> p[0]kdb> ps[0]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xc19ea000 7 1 1 0 R 0xc19ea280 *kupdated 0xc19ec000 6 1 1 1 R 0xc19ec280 bdflush 0xf7ff2000 1 0 0 1 R 0xf7ff2280 init 0xc19b2000 2 1 0 1 R 0xc19b2280 keventd 0xc19b0000 3 1 0 0 S 0xc19b0280 ksoftirqd_CPU0 0xc19fe000 4 1 0 1 S 0xc19fe280 ksoftirqd_CPU1 0xc19ee000 5 1 0 1 S 0xc19ee280 kswapd 0xc19ec000 6 1 1 1 R 0xc19ec280 bdflush 0xc19ea000 7 1 1 0 R 0xc19ea280 *kupdated 0xf7648000 13 1 0 1 S 0xf7648280 scsi_eh_0 0xf7504000 15 1 0 1 S 0xf7504280 mdrecoveryd 0xf7374000 17 1 0 1 R 0xf7374280 kreiserfsd 0xf798e000 60 1 0 0 S 0xf798e280 khubd 0xf7794000 535 1 0 0 S 0xf7794280 syslogd 0xf6606000 539 1 0 1 S 0xf6606280 klogd 0xf6548000 548 1 0 0 S 0xf6548280 portmap 0xf6454000 567 1 0 0 S 0xf6454280 rpc.statd 0xf5fb0000 648 1 0 0 S 0xf5fb0280 sshd 0xf5eee000 663 1 0 1 S 0xf5eee280 xinetd 0xf5efe000 673 1 0 1 S 0xf5efe280 crond 0xf5e82000 682 1 0 1 S 0xf5e82280 anacron [0]more>=20 0xf6534000 689 1 0 1 R 0xf6534280 agetty 0xf5f30000 690 1 0 0 S 0xf5f30280 login 0xf5e96000 691 1 0 0 S 0xf5e96280 mingetty 0xf5e58000 692 1 0 1 S 0xf5e58280 mingetty 0xf5dbc000 695 690 0 0 S 0xf5dbc280 bash 0xf57b2000 744 1 0 1 R 0xf57b2280 pagebufd 0xf57b0000 745 1 0 0 S 0xf57b0280 xfslogd/0 0xf57ae000 746 1 0 1 S 0xf57ae280 xfslogd/1 0xf57ac000 747 1 0 0 S 0xf57ac280 xfsdatad/0 0xf57aa000 748 1 0 1 S 0xf57aa280 xfsdatad/1 0xf59b0000 765 1 0 1 S 0xf59b0280 xfssyncd 0xe50e8000 771 1 0 1 R 0xe50e8280 nmbd 0xe4ce6000 773 1 0 1 S 0xe4ce6280 smbd 0xe44e4000 775 773 0 0 R 0xe44e4280 smbd 0xe38e2000 776 773 0 1 R 0xe38e2280 smbd 0xd6d20000 780 773 0 1 R 0xd6d20280 smbd 0xe12a2000 782 773 0 1 R 0xe12a2280 smbd 0xc54fe000 785 695 0 1 R 0xc54fe280 iostat [0]kdb> p[0]kdb> p=08 [0]kdb> b[0]kdb> bt[0]kdb> btp[0]kdb> btp7[0]kdb> btp= 76[0]kdb> btp765[0]kdb> btp765 Stack traceback for pid 7 0xc19ea000 7 1 1 0 R 0xc19ea280 *kupdated ESP EIP Function (args) 0xc19ebc8c 0xf8aefda4 [xfs]xfs_imap_to_bmap+0xb4 (0xf5813b94, 0x4d0c0000, 0= x1, 0 xc19ebd24, 0xc19ebe08) xfs .text 0xf8a84060 0xf8aefcf0 0xf8aeff90 0xc19ebcd4 0xf8af01ef [xfs]xfs_iomap+0x25f xfs .text 0xf8a84060 0xf8aeff90 0xf8af04f0 0xc19ebd58 0xf8af3f85 [xfs]xfs_bmap+0x45 (0xf5813ab0, 0x4d0c0000, 0x1, 0x10= 00, 0 x4) xfs .text 0xf8a84060 0xf8af3f40 0xf8af3f90 0xc19ebd78 0xf8aeb563 [xfs]map_blocks+0x63 (0xf5816b20, 0x4d0c0000, 0x1, 0x= 1000, 0xc19ebe08) xfs .text 0xf8a84060 0xf8aeb500 0xf8aeb5f0 0xc19ebdac 0xf8aec44d [xfs]page_state_convert+0x42d (0xf5816b20, 0xc1951c58= , 0x1 , 0x0, 0x1) xfs .text 0xf8a84060 0xf8aec020 0xf8aec5d0 0xc19ebe5c 0xf8aecb36 [xfs]linvfs_writepage+0x86 (0xc1951c58, 0x0, 0x0, 0x0= , 0xc 03c9980) xfs .text 0xf8a84060 0xf8aecab0 0xf8aecbe0 0xc19ebe8c 0xc0145b9a write_some_buffers+0xca (0x0, 0x0) kernel .text 0xc0100000 0xc0145ad0 0xc0145c00 0xc19ebf30 0xc0149686 sync_old_buffers+0x76 (0xc0359a20, 0x0, 0x0, 0xc19ea5= 74, 0 x0) kernel .text 0xc0100000 0xc0149610 0xc01496c0 0xc19ebf40 0xc0149985 kupdate+0xf5 kernel .text 0xc0100000 0xc0149890 0xc0149a20 0xc19ebff4 0xc010757e arch_kernel_thread+0x2e [0]more> d Only 'q' or 'Q' are processed at more prompt, input ignored kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> m[0]kdb> me[0]kdb> me=08 [0]kdb> m=08 [0]kdb> d[0]kdb> d=08 [0]kdb>= [0]kdb> btp765 Stack traceback for pid 7 0xc19ea000 7 1 1 0 R 0xc19ea280 *kupdated ESP EIP Function (args) 0xc19ebc8c 0xf8aefda4 [xfs]xfs_imap_to_bmap+0xb4 (0xf5813b94, 0x4d0c0000, 0= x1, 0 xc19ebd24, 0xc19ebe08) xfs .text 0xf8a84060 0xf8aefcf0 0xf8aeff90 0xc19ebcd4 0xf8af01ef [xfs]xfs_iomap+0x25f xfs .text 0xf8a84060 0xf8aeff90 0xf8af04f0 0xc19ebd58 0xf8af3f85 [xfs]xfs_bmap+0x45 (0xf5813ab0, 0x4d0c0000, 0x1, 0x10= 00, 0 x4) xfs .text 0xf8a84060 0xf8af3f40 0xf8af3f90 0xc19ebd78 0xf8aeb563 [xfs]map_blocks+0x63 (0xf5816b20, 0x4d0c0000, 0x1, 0x= 1000, 0xc19ebe08) xfs .text 0xf8a84060 0xf8aeb500 0xf8aeb5f0 0xc19ebdac 0xf8aec44d [xfs]page_state_convert+0x42d (0xf5816b20, 0xc1951c58= , 0x1 , 0x0, 0x1) xfs .text 0xf8a84060 0xf8aec020 0xf8aec5d0 0xc19ebe5c 0xf8aecb36 [xfs]linvfs_writepage+0x86 (0xc1951c58, 0x0, 0x0, 0x0= , 0xc 03c9980) xfs .text 0xf8a84060 0xf8aecab0 0xf8aecbe0 0xc19ebe8c 0xc0145b9a write_some_buffers+0xca (0x0, 0x0) kernel .text 0xc0100000 0xc0145ad0 0xc0145c00 0xc19ebf30 0xc0149686 sync_old_buffers+0x76 (0xc0359a20, 0x0, 0x0, 0xc19ea5= 74, 0 x0) kernel .text 0xc0100000 0xc0149610 0xc01496c0 0xc19ebf40 0xc0149985 kupdate+0xf5 kernel .text 0xc0100000 0xc0149890 0xc0149a20 0xc19ebff4 0xc010757e arch_kernel_thread+0x2e [0]more>=20 kernel .text 0xc0100000 0xc0107550 0xc0107590 [0]kdb> d[0]kdb> dm[0]kdb> dme[0]kdb> dmes[0]kdb> dmesg[0]kdb> dmesg <4>Linux version 2.4.24-pre1-xfs (root@tracala) (gcc version 3.3.2 20031022= (Red Hat Linux 3.3.2-1)) #2 SMP Tue Dec 16 12:58:37 EST 2003 <6>BIOS-provided physical RAM map: <4> BIOS-e820: 0000000000000000 - 000000000009f000 (usable) <4> BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) <4> BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved) <4> BIOS-e820: 0000000000100000 - 000000003fff0000 (usable) <4> BIOS-e820: 000000003fff0000 - 000000003ffff000 (ACPI data) <4> BIOS-e820: 000000003ffff000 - 0000000040000000 (ACPI NVS) <4> BIOS-e820: 00000000fec00000 - 00000000fed00000 (reserved) <4> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) <4> BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) <4>Warning only 896MB will be used. <4>Use a HIGHMEM enabled kernel. <5>896MB LOWMEM available. <4>found SMP MP-table at 000ff780 <4>hm, page 000ff000 reserved twice. <4>hm, page 00100000 reserved twice. <4>hm, page 000f1000 reserved twice. <4>hm, page 000f2000 reserved twice. <4>On node 0 totalpages: 229376 <4>zone(0): 4096 pages. <4>zone(1): 225280 pages. [0]more>=20 <4>zone(2): 0 pages. <6>ACPI: RSDP (v000 INTEL ) @ 0x000ff9b0 <6>ACPI: RSDT (v001 INTEL S7501HG0 0x00000001 MSFT 0x01000000) @ 0x3fff0000 <6>ACPI: FADT (v001 INTEL S7501HG0 0x00000001 MSFT 0x01000000) @ 0x3fff0030 <6>ACPI: MADT (v001 INTEL S7501HG0 0x00000001 MSFT 0x01000000) @ 0x3fff00b0 <6>ACPI: OEMR (v001 INTEL S7501HG0 0x00000001 MSFT 0x01000000) @ 0x3fff0140 <6>ACPI: DSDT (v001 INTEL S7501HG0 0x00000100 INTL 0x20020918) @ 0x00000000 <6>ACPI: Local APIC address 0xfee00000 <6>ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) <4>Processor #0 Pentium 4(tm) XEON(tm) APIC version 20 <6>ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled) <4>Processor #6 Pentium 4(tm) XEON(tm) APIC version 20 <6>ACPI: LAPIC (acpi_id[0x02] lapic_id[0x00] disabled) <6>ACPI: LAPIC (acpi_id[0x03] lapic_id[0x00] disabled) <6>ACPI: LAPIC_NMI (acpi_id[0x00] polarity[0x1] trigger[0x3] lint[0x1]) <6>ACPI: LAPIC_NMI (acpi_id[0x01] polarity[0x1] trigger[0x3] lint[0x1]) <6>Using ACPI for processor (LAPIC) configuration information <4>Intel MultiProcessor Specification v1.4 <4> Virtual Wire compatibility mode. <4>OEM ID: INTEL Product ID: S7501HG0 APIC at: 0xFEE00000 <4>I/O APIC #8 Version 32 at 0xFEC00000. <4>I/O APIC #9 Version 32 at 0xFEC81000. <4>I/O APIC #10 Version 32 at 0xFEC81400. [0]more>=20 <4>Enabling APIC mode: Flat. Using 3 I/O APICs <4>Processors: 2 <4>Kernel command line: ro root=3D/dev/hda3 console=3DttyS0 <6>Initializing CPU#0 <4>Detected 2392.351 MHz processor. <4>Console: colour VGA+ 80x25 <4>Calibrating delay loop... 4771.02 BogoMIPS <6>Memory: 903912k/917504k available (1506k kernel code, 13204k reserved, 1= 104k=20 data, 128k init, 0k highmem) <4>kdb version 4.3 by Keith Owens, Scott Lurndal. Copyright SGI, All Rights= Rese rved <6>Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) <6>Inode cache hash table entries: 65536 (order: 7, 524288 bytes) <6>Mount cache hash table entries: 512 (order: 0, 4096 bytes) <6>Buffer cache hash table entries: 65536 (order: 6, 262144 bytes) <4>Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) <6>CPU: Trace cache: 12K uops, L1 D cache: 8K <6>CPU: L2 cache: 512K <6>CPU: Physical Processor ID: 0 <6>Intel machine check architecture supported. <6>Intel machine check reporting enabled on CPU#0. <7>CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 <7>CPU: Common caps: bfebfbff 00000000 00000000 00000000 <6>Enabling fast FPU save and restore... done. <6>Enabling unmasked SIMD FPU exception support... done. [0]more>=20 <6>Checking 'hlt' instruction... OK. <4>POSIX conformance testing by UNIFIX <4>mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) <4>mtrr: detected mtrr type: Intel <6>CPU: Trace cache: 12K uops, L1 D cache: 8K <6>CPU: L2 cache: 512K <6>CPU: Physical Processor ID: 0 <6>Intel machine check reporting enabled on CPU#0. <7>CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 <7>CPU: Common caps: bfebfbff 00000000 00000000 00000000 <4>CPU0: Intel(R) Xeon(TM) CPU 2.40GHz stepping 07 <4>per-CPU timeslice cutoff: 1462.89 usecs. <4>enabled ExtINT on CPU#0 <4>ESR value before enabling vector: 00000000 <4>ESR value after enabling vector: 00000000 <4>Booting processor 1/6 eip 2000 <6>Initializing CPU#1 <4>masked ExtINT on CPU#1 <4>ESR value before enabling vector: 00000000 <4>ESR value after enabling vector: 00000000 <4>Calibrating delay loop... 4784.12 BogoMIPS <6>CPU: Trace cache: 12K uops, L1 D cache: 8K <6>CPU: L2 cache: 512K [0]more>=20 <6>CPU: Physical Processor ID: 3 <6>Intel machine check reporting enabled on CPU#1. <7>CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 <7>CPU: Common caps: bfebfbff 00000000 00000000 00000000 <4>CPU1: Intel(R) Xeon(TM) CPU 2.40GHz stepping 07 <6>Total of 2 processors activated (9555.14 BogoMIPS). <4>WARNING: No sibling found for CPU 0. <4>WARNING: No sibling found for CPU 1. <4>ENABLING IO-APIC IRQs <4>Setting 8 in the phys_id_present_map <6>...changing IO-APIC physical APIC ID to 8 ... ok. <4>Setting 9 in the phys_id_present_map <6>...changing IO-APIC physical APIC ID to 9 ... ok. <4>Setting 10 in the phys_id_present_map <6>...changing IO-APIC physical APIC ID to 10 ... ok. <7>init IO_APIC IRQs <7> IO-APIC (apicid-pin) 8-0, 8-20, 8-21, 8-22, 9-1, 9-2, 9-3, 9-4, 9-5, 9-= 6, 9- 7, 9-8, 9-9, 9-10, 9-11, 9-12, 9-13, 9-14, 9-15, 9-16, 9-17, 9-18, 9-19, 9-= 20, 9 -21, 9-22, 9-23, 10-0, 10-1, 10-2, 10-3, 10-4, 10-5, 10-6, 10-7, 10-8, 10-9= , 10- 12, 10-13, 10-14, 10-15, 10-16, 10-17, 10-18, 10-19, 10-20, 10-21, 10-22, 1= 0-23=20 not connected. <6>..TIMER: vector=3D0x31 pin1=3D2 pin2=3D0 <7>number of MP IRQ sources: 24. <7>number of IO-APIC #8 registers: 24. <7>number of IO-APIC #9 registers: 24. <7>number of IO-APIC #10 registers: 24. <6>testing the IO APIC....................... [0]more>=20 <4> <7>IO APIC #8...... <7>.... register #00: 08000000 <7>....... : physical APIC id: 08 <7>....... : Delivery Type: 0 <7>....... : LTS : 0 <7>.... register #01: 00178020 <7>....... : max redirection entries: 0017 <7>....... : PRQ implemented: 1 <7>....... : IO APIC version: 0020 <7>.... register #02: 00000000 <7>....... : arbitration: 00 <7>.... register #03: 00000001 <7>....... : Boot DT : 1 <7>.... IRQ redirection table: <7> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:=20=20=20 <7> 00 000 00 1 0 0 0 0 0 0 00 <7> 01 003 03 0 0 0 0 0 1 1 39 <7> 02 003 03 0 0 0 0 0 1 1 31 <7> 03 003 03 0 0 0 0 0 1 1 41 <7> 04 003 03 0 0 0 0 0 1 1 49 <7> 05 003 03 0 0 0 0 0 1 1 51 <7> 06 003 03 0 0 0 0 0 1 1 59 [0]more>=20 <7> 07 003 03 0 0 0 0 0 1 1 61 <7> 08 003 03 0 0 0 0 0 1 1 69 <7> 09 003 03 0 0 0 0 0 1 1 71 <7> 0a 003 03 0 0 0 0 0 1 1 79 <7> 0b 003 03 0 0 0 0 0 1 1 89 <7> 0c 003 03 0 0 0 0 0 1 1 91 <7> 0d 003 03 0 0 0 0 0 1 1 99 <7> 0e 003 03 0 0 0 0 0 1 1 A1 <7> 0f 003 03 0 0 0 0 0 1 1 A9 <7> 10 003 03 1 1 0 1 0 1 1 B1 <7> 11 003 03 1 1 0 1 0 1 1 B9 <7> 12 003 03 1 1 0 1 0 1 1 C1 <7> 13 003 03 1 1 0 1 0 1 1 C9 <7> 14 000 00 1 0 0 0 0 0 0 00 <7> 15 07C 0C 1 0 0 0 0 0 2 05 <7> 16 000 00 1 0 0 0 0 0 0 00 <7> 17 003 03 1 1 0 1 0 1 1 D1 <4> <7>IO APIC #9...... <7>.... register #00: 09000000 <7>....... : physical APIC id: 09 <7>....... : Delivery Type: 0 <7>....... : LTS : 0 [0]more>=20 <7>.... register #01: 00178020 <7>....... : max redirection entries: 0017 <7>....... : PRQ implemented: 1 <7>....... : IO APIC version: 0020 <7>.... register #02: 09000000 <7>....... : arbitration: 09 <7>.... register #03: 00000001 <7>....... : Boot DT : 1 <7>.... IRQ redirection table: <7> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:=20=20=20 <7> 00 003 03 1 1 0 1 0 1 1 D9 <7> 01 000 00 1 0 0 0 0 0 0 00 <7> 02 000 00 1 0 0 0 0 0 0 00 <7> 03 000 00 1 0 0 0 0 0 0 00 <7> 04 000 00 1 0 0 0 0 0 0 00 <7> 05 000 00 1 0 0 0 0 0 0 00 <7> 06 000 00 1 0 0 0 0 0 0 00 <7> 07 000 00 1 0 0 0 0 0 0 00 <7> 08 000 00 1 0 0 0 0 0 0 00 <7> 09 000 00 1 0 0 0 0 0 0 00 <7> 0a 000 00 1 0 0 0 0 0 0 00 <7> 0b 000 00 1 0 0 0 0 0 0 00 <7> 0c 000 00 1 0 0 0 0 0 0 00 [0]more>=20 <7> 0d 000 00 1 0 0 0 0 0 0 00 <7> 0e 000 00 1 0 0 0 0 0 0 00 <7> 0f 000 00 1 0 0 0 0 0 0 00 <7> 10 000 00 1 0 0 0 0 0 0 00 <7> 11 000 00 1 0 0 0 0 0 0 00 <7> 12 000 00 1 0 0 0 0 0 0 00 <7> 13 000 00 1 0 0 0 0 0 0 00 <7> 14 000 00 1 0 0 0 0 0 0 00 <7> 15 000 00 1 0 0 0 0 0 0 00 <7> 16 000 00 1 0 0 0 0 0 0 00 <7> 17 000 00 1 0 0 0 0 0 0 00 <4> <7>IO APIC #10...... <7>.... register #00: 0A000000 <7>....... : physical APIC id: 0A <7>....... : Delivery Type: 0 <7>....... : LTS : 0 <7>.... register #01: 00178020 <7>....... : max redirection entries: 0017 <7>....... : PRQ implemented: 1 <7>....... : IO APIC version: 0020 <7>.... register #02: 0A000000 <7>....... : arbitration: 0A [0]more>=20 <7>.... register #03: 00000001 <7>....... : Boot DT : 1 <7>.... IRQ redirection table: <7> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:=20=20=20 <7> 00 000 00 1 0 0 0 0 0 0 00 <7> 01 000 00 1 0 0 0 0 0 0 00 <7> 02 000 00 1 0 0 0 0 0 0 00 <7> 03 000 00 1 0 0 0 0 0 0 00 <7> 04 000 00 1 0 0 0 0 0 0 00 <7> 05 000 00 1 0 0 0 0 0 0 00 <7> 06 000 00 1 0 0 0 0 0 0 00 <7> 07 000 00 1 0 0 0 0 0 0 00 <7> 08 000 00 1 0 0 0 0 0 0 00 <7> 09 000 00 1 0 0 0 0 0 0 00 <7> 0a 003 03 1 1 0 1 0 1 1 E1 <7> 0b 003 03 1 1 0 1 0 1 1 E9 <7> 0c 000 00 1 0 0 0 0 0 0 00 <7> 0d 000 00 1 0 0 0 0 0 0 00 <7> 0e 000 00 1 0 0 0 0 0 0 00 <7> 0f 000 00 1 0 0 0 0 0 0 00 <7> 10 000 00 1 0 0 0 0 0 0 00 <7> 11 000 00 1 0 0 0 0 0 0 00 <7> 12 000 00 1 0 0 0 0 0 0 00 [0]more>=20 <7> 13 000 00 1 0 0 0 0 0 0 00 <7> 14 000 00 1 0 0 0 0 0 0 00 <7> 15 000 00 1 0 0 0 0 0 0 00 <7> 16 000 00 1 0 0 0 0 0 0 00 <7> 17 000 00 1 0 0 0 0 0 0 00 <7>IRQ to pin mappings: <7>IRQ0 -> 0:2 <7>IRQ1 -> 0:1 <7>IRQ3 -> 0:3 <7>IRQ4 -> 0:4 <7>IRQ5 -> 0:5 <7>IRQ6 -> 0:6 <7>IRQ7 -> 0:7 <7>IRQ8 -> 0:8 <7>IRQ9 -> 0:9 <7>IRQ10 -> 0:10 <7>IRQ11 -> 0:11 <7>IRQ12 -> 0:12 <7>IRQ13 -> 0:13 <7>IRQ14 -> 0:14 <7>IRQ15 -> 0:15 <7>IRQ16 -> 0:16 <7>IRQ17 -> 0:17 [0]more>=20 <7>IRQ18 -> 0:18 <7>IRQ19 -> 0:19 <7>IRQ23 -> 0:23 <7>IRQ24 -> 1:0 <7>IRQ58 -> 2:10 <7>IRQ59 -> 2:11 <6>.................................... done. <4>Using local APIC timer interrupts. <4>calibrating APIC timer ... <4>..... CPU clock speed is 2392.2607 MHz. <4>..... host bus clock speed is 132.9032 MHz. <4>cpu: 0, clocks: 1329032, slice: 443010 <4>CPU0 <4>cpu: 1, clocks: 1329032, slice: 443010 <4>CPU1 <4>checking TSC synchronization across CPUs: passed. <4>Waiting on wait_init_idle (map =3D 0x2) <4>All processors have done init_idle <6>PCI: PCI BIOS revision 2.10 entry at 0xfdb55, last bus=3D4 <6>PCI: Using configuration type 1 <6>PCI: Probing PCI hardware <4>PCI: Probing PCI hardware (bus 00) <6>PCI: Ignoring BAR0-3 of IDE controller 00:1f.1 [0]more>=20 <3>PCI: Unable to handle 64-bit address space for=20 <3>PCI: Unable to handle 64-bit address space for=20 <4>Transparent bridge - Intel Corp. 82801BA/CA/DB/EB PCI Bridge <6>PCI: Using IRQ router PIIX/ICH [8086/2480] at 00:1f.0 <6>PCI->APIC IRQ transform: (B0,I29,P0) -> 16 <6>PCI->APIC IRQ transform: (B0,I29,P1) -> 19 <6>PCI->APIC IRQ transform: (B0,I29,P2) -> 18 <6>PCI->APIC IRQ transform: (B0,I31,P0) -> 17 <6>PCI->APIC IRQ transform: (B0,I31,P1) -> 17 <6>PCI->APIC IRQ transform: (B4,I5,P0) -> 58 <6>PCI->APIC IRQ transform: (B4,I5,P1) -> 59 <6>PCI->APIC IRQ transform: (B3,I2,P0) -> 24 <6>PCI->APIC IRQ transform: (B1,I12,P0) -> 23 <6>Linux NET4.0 for Linux 2.4 <6>Based upon Swansea University Computer Society NET3.039 <4>Initializing RT netlink socket <4>Starting kswapd <5>VFS: Disk quotas vdquot_6.5.1 <6>i2c-core.o: i2c core module <4>pty: 2048 Unix98 ptys configured <6>Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIA= L_PCI enabled <6>ttyS00 at 0x03f8 (irq =3D 4) is a 16550A <6>ttyS01 at 0x02f8 (irq =3D 3) is a 16550A [0]more>=20 <6>Real Time Clock Driver v1.10f <6>Non-volatile memory driver v1.2 <3>xd: Out of memory. <6>Floppy drive(s): fd0 is 1.44M <6>FDC 0 is a National Semiconductor PC87306 <4>RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize <6>loop: loaded (max 8 devices) <6>Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 <6>ide: Assuming 33MHz system bus speed for PIO modes; override with idebus= =3Dxx <6>ICH3: IDE controller at PCI slot 00:1f.1 <4>PCI: Enabling device 00:1f.1 (0005 -> 0007) <6>ICH3: chipset revision 2 <6>ICH3: not 100% native mode: will probe irqs later <6> ide0: BM-DMA at 0x03a0-0x03a7, BIOS settings: hda:DMA, hdb:pio <6> ide1: BM-DMA at 0x03a8-0x03af, BIOS settings: hdc:DMA, hdd:pio <4>hda: WDC WD400BB-00GFA0, ATA DISK drive <4>blk: queue c04012e0, I/O limit 4095Mb (mask 0xffffffff) <4>hdc: SR244W, ATAPI CD/DVD-ROM drive <4>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 <4>ide1 at 0x170-0x177,0x376 on irq 15 <4>hda: attached ide-disk driver. <4>hda: host protected area =3D> 1 <4> (40021 MB) w/2048KiB Cache, CHS=3D4865/255/63, UDMA(100) [0]more>=20 <4>hdc: attached ide-cdrom driver. <6>hdc: ATAPI 24X CD-ROM drive, 128kB Cache <6>Uniform CD-ROM driver Revision: 3.12 <6>Partition check: <6> hda: hda1 hda2 hda3 <6>Initializing Cryptographic API <6>NET4: Linux TCP/IP 1.0 for NET4.0 <6>IP Protocols: ICMP, UDP, TCP, IGMP <6>IP: routing cache hash table of 8192 buckets, 64Kbytes <6>TCP: Hash tables configured (established 262144 bind 65536) <6>NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. <5>RAMDISK: Compressed image found at block 0 <6>Freeing initrd memory: 161k freed <4>VFS: Mounted root (ext2 filesystem). <6>SCSI subsystem driver Revision: 1.00 <4>3ware Storage Controller device driver for Linux v1.02.00.037. <5>scsi0 : Found a 3ware Storage Controller at 0x2000, IRQ: 24, P-chip: 1.3 <6>scsi0 : 3ware Storage Controller <4> Vendor: 3ware Model: Logical Disk 0 Rev: 1.0=20 <4> Type: Direct-Access ANSI SCSI revision: 00 <4> Vendor: 3ware Model: Logical Disk 6 Rev: 1.0=20 <4> Type: Direct-Access ANSI SCSI revision: 00 <4>Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 [0]more>=20 <4>Attached scsi disk sdb at scsi0, channel 0, id 6, lun 0 <4>SCSI device sda: 2930368512 512-byte hdwr sectors (1500349 MB) <6> sda: sda1 sda2 sda3 <4>SCSI device sdb: 2930368512 512-byte hdwr sectors (1500349 MB) <6> sdb: sdb1 sdb2 sdb3 <6>md: md driver 0.90.0 MAX_MD_DEVS=3D256, MD_SB_DISKS=3D27 <6>md: raid0 personality registered as nr 2 <4>reiserfs: found format "3.6" with standard journal <4>reiserfs: checking transaction log (device ide0(3,3)) ... <4>for (ide0(3,3)) <4>ide0(3,3):Using r5 hash to sort names <6>Freeing unused kernel memory: 128k freed <6>usb.c: registered new driver usbdevfs <6>usb.c: registered new driver hub <6>usb-uhci.c: $Revision: 1.275 $ time 12:54:29 Dec 16 2003 <6>usb-uhci.c: High bandwidth mode enabled <7>PCI: Setting latency timer of device 00:1d.0 to 64 <6>usb-uhci.c: USB UHCI at I/O 0x4040, IRQ 16 <4>usb-uhci.c: Detected 2 ports <6>usb.c: new USB bus registered, assigned bus number 1 <6>hub.c: USB hub found <6>hub.c: 2 ports detected <7>PCI: Setting latency timer of device 00:1d.1 to 64 [0]more>=20 <6>usb-uhci.c: USB UHCI at I/O 0x4020, IRQ 19 <4>usb-uhci.c: Detected 2 ports <6>usb.c: new USB bus registered, assigned bus number 2 <6>hub.c: USB hub found <6>hub.c: 2 ports detected <7>PCI: Setting latency timer of device 00:1d.2 to 64 <6>usb-uhci.c: USB UHCI at I/O 0x4000, IRQ 18 <4>usb-uhci.c: Detected 2 ports <6>usb.c: new USB bus registered, assigned bus number 3 <6>hub.c: USB hub found <6>hub.c: 2 ports detected <6>usb-uhci.c: v1.275:USB Universal Host Controller Interface driver <6>Adding Swap: 2097136k swap-space (priority -1) <6> [events: ffffffff] <3>md: invalid raid superblock magic on sda3 <4>md: sda3 has invalid sb, not importing! <4>md: could not import sda3! <4>md: autostart sda3 failed! <6>md: bind <6>md: nonpersistent superblock ... <6>md: bind <6>md: nonpersistent superblock ... <6>md: sdb3's event counter: 00000000 [0]more>=20 <6>md: sda3's event counter: 00000000 <6>md0: max total readahead window set to 496k <6>md0: 2 data-disks, max readahead per data-disk: 248k <4>raid0: looking at sda3 <4>raid0: comparing sda3(1464879072) with sda3(1464879072) <4>raid0: END <4>raid0: =3D=3D> UNIQUE <4>raid0: 1 zones <4>raid0: looking at sdb3 <4>raid0: comparing sdb3(1464879072) with sda3(1464879072) <4>raid0: EQUAL <4>raid0: FINAL 1 zones <4>raid0: zone 0 <4>raid0: checking sda3 ... contained as device 0 <4> (1464879072) is smallest!. <4>raid0: checking sdb3 ... contained as device 1 <4>raid0: zone->nb_dev: 2, size: -1365209152 <4>raid0: current zone offset: 1464879072 <4>raid0: done. <4>raid0 : md_size is 2929758144 blocks. <4>raid0 : conf->smallest->size is -1365209152 blocks. <4>raid0 : nb_zone is 1. <4>raid0 : Allocating 8 bytes for hash. [0]more>=20 <6>Intel(R) PRO/1000 Network Driver - version 5.2.20-k1 <6>Copyright (c) 1999-2003 Intel Corporation. <6>eth0: Intel(R) PRO/1000 Network Connection <6>eth1: Intel(R) PRO/1000 Network Connection <6>e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex <6>e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex <6>SGI-XFS CVS-2003-11-24_06:00_UTC with ACLs, large block numbers, no debu= g ena bled <6>SGI XFS Quota Management subsystem <5>XFS mounting filesystem md(9,0) <5>Starting XFS recovery on filesystem: md(9,0) (dev: md(9,0)) <5>Ending XFS recovery on filesystem: md(9,0) (dev: md(9,0)) <5>XFS mounting filesystem md(9,0) <7>Ending clean XFS mount for filesystem: md(9,0) <5>XFS mounting filesystem md(9,0) <7>Ending clean XFS mount for filesystem: md(9,0) [0]kdb>=20 ----=_NextPart_ST_08_29_52_Tuesday_December_16_2003_28085-- From owner-linux-xfs@oss.sgi.com Tue Dec 16 06:37:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 06:37:32 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGEb4Ta023789 for ; Tue, 16 Dec 2003 06:37:05 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBGCijOO006088 for ; Tue, 16 Dec 2003 04:44:45 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBGEawSC21102839; Tue, 16 Dec 2003 08:36:58 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBGEanK210555050; Tue, 16 Dec 2003 08:36:49 -0600 (CST) Date: Tue, 16 Dec 2003 08:36:57 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Gustavo Rincon cc: "'linux-xfs@oss.sgi.com'" , Tony Lambert , Ben McMillan Subject: RE: LBD patch and XFS problem! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1439 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 802 Lines: 27 On Tue, 16 Dec 2003, Gustavo Rincon wrote: > Yes I'm using LBD patch for 2.4.23 and I did make the change in > include/linux/types.h in order to > enable the HAVE_SECTOR_T. Oh, you did this before your previous email, and you still had problems? Hm... > The LBD is working, I'm able to create ext3 > filesystem on the device and > the size of it is 2.7Terabye and by the way I ran the test successfully for > 4 days in a row. The problems I mentioned wouldn't affect ext3, since the patch should do everything necessary for ext3. It was trickier for XFS since it was not in the kernel tree, and we needed to be clever about detecting the LBD patch. > I'll change xfs_types.h and i' ll force to have the HAVE_SECTOR_T definition > and i'll try the test > again. Sounds good, thanks. -Eric From owner-linux-xfs@oss.sgi.com Tue Dec 16 06:47:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 06:47:12 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGEkwTa024242 for ; Tue, 16 Dec 2003 06:47:00 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBGCsdOO007440 for ; Tue, 16 Dec 2003 04:54:39 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBGEkpSC21033587; Tue, 16 Dec 2003 08:46:52 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBGEkfK210590380; Tue, 16 Dec 2003 08:46:42 -0600 (CST) Date: Tue, 16 Dec 2003 08:46:49 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Mike Burger cc: linux-xfs@oss.sgi.com Subject: Re: ATrpms kernel and quota oddity In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1440 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 608 Lines: 21 Looks like Axel's RPMs don't have quota turned on - what does "modinfo xfs" say? I guess maybe I'll put my own updates out, so that they keep the same config options as before. Oh well, seemed like a good idea at the time. :) Thanks, -Eric On Tue, 16 Dec 2003, Mike Burger wrote: > I'm wondering if anyone else has run into this with Axel's kernel(s). I > ran into it after compiling his 2.4.20-24_30 src.rpm for use with RH7.1. > > This morning, I monkeyed around a bit more, and removed the "usrquota" > from the options I had set in my fstab file. Now, the filesystems mount > just fine. > From owner-linux-xfs@oss.sgi.com Tue Dec 16 07:03:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 07:03:47 -0800 (PST) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGF3NTa024896 for ; Tue, 16 Dec 2003 07:03:26 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id 90800161EC7 for ; Tue, 16 Dec 2003 16:03:20 +0100 (CET) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15722-10 for ; Tue, 16 Dec 2003 16:03:19 +0100 (CET) Received: from opticalart.de (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id 9517C161EAF for ; Tue, 16 Dec 2003 16:03:19 +0100 (CET) Message-ID: <3FDF1EB7.9080905@opticalart.de> Date: Tue, 16 Dec 2003 16:03:19 +0100 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS List Subject: OT: CXFS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 1441 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Content-Length: 975 Lines: 26 Hi! This is a bit off-topic, but has anybody come in contact with the CXFS client/implementation for Linux? We have a need for our render systems to get faster access to the original film frames to work on (from 12MB up to 50MB size per frame/file). A clustered filesystem might solve our current network bottleneck (Gbit Ethernet) and would make use of the existing fibrechannel infrastructure. I am most interested in actually how good and stable the linux client performs. Is there is any big device support (>2TB)? I would be really gratefull if somebody could point me to more detailed infos about CXFS than the marketing blurb on SGIs site... Thanks a lot, Frank... -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a Digital Cinema http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 From owner-linux-xfs@oss.sgi.com Tue Dec 16 07:27:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 07:28:08 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGFRlTa025594 for ; Tue, 16 Dec 2003 07:27:47 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id C76BD141B121; Tue, 16 Dec 2003 10:27:47 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 35E22141B120; Tue, 16 Dec 2003 10:27:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 298F130002B5; Tue, 16 Dec 2003 10:27:46 -0500 (EST) Date: Tue, 16 Dec 2003 10:27:46 -0500 (EST) From: Mike Burger To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: ATrpms kernel and quota oddity In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1442 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 998 Lines: 36 On Tue, 16 Dec 2003, Eric Sandeen wrote: > Looks like Axel's RPMs don't have quota turned on - what > does "modinfo xfs" say? > > I guess maybe I'll put my own updates out, so that they keep > the same config options as before. Oh well, seemed like a good > idea at the time. :) filename: /lib/modules/2.4.20-24_30.7.1/kernel/fs/xfs/xfs.o description: "SGI XFS 1.3.0 with no debug enabled" author: "Silicon Graphics, Inc." license: "GPL" I did notice that the previous src.rpm that I'd compiled, 2.4.20-19 or -20, had ACLs enabled, and that Axel's don't. I can recompile, if I know what option to pass, or to change in the config. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Tue Dec 16 07:30:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 07:30:30 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGFUHTa026012 for ; Tue, 16 Dec 2003 07:30:18 -0800 Received: by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id hBGFUAGT012713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Dec 2003 16:30:12 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id hBGFTpKG012621; Tue, 16 Dec 2003 16:29:51 +0100 Date: Tue, 16 Dec 2003 16:29:50 +0100 From: Axel Thimm To: Eric Sandeen Cc: Mike Burger , linux-xfs@oss.sgi.com Subject: Re: ATrpms kernel and quota oddity Message-ID: <20031216152950.GA8503@neu.nirvana> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 1443 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 2201 Lines: 86 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 16, 2003 at 08:46:49AM -0600, Eric Sandeen wrote: > Looks like Axel's RPMs don't have quota turned on - what > does "modinfo xfs" say? >=20 > I guess maybe I'll put my own updates out, so that they keep > the same config options as before. Oh well, seemed like a good > idea at the time. :) Ouch, I swapped BOOT vs non-BOOT config, so only BOOT kernels got a config with CONFIG_XFS_QUOTA :( I suggest using kernel-source and build a custom kernel until fixed rpms are available. Just for reference, Eric, are these the currently recommended settings for BOOT vs non-BOOT? Otherwise would you provide a better set I can use for the ATrpms kernels? Thanks. non-BOOT: # XFS-specific options CONFIG_XFS_PRESENT=3Dy CONFIG_XFS_FS=3Dm CONFIG_XFS_POSIX_ACL=3Dy CONFIG_XFS_DMAPI=3Dy CONFIG_XFS_QUOTA=3Dy # CONFIG_XFS_RT is not set # CONFIG_XFS_DEBUG is not set # CONFIG_PAGEBUF_DEBUG is not set CONFIG_KDB=3Dy CONFIG_KDB_MODULES=3Dm # CONFIG_KDB_USB is not set # CONFIG_KDB_OFF is not set BOOT: # XFS-specific options CONFIG_XFS_PRESENT=3Dy CONFIG_XFS_FS=3Dm CONFIG_XFS_POSIX_ACL=3Dn CONFIG_XFS_DMAPI=3Dn CONFIG_XFS_QUOTA=3Dn # CONFIG_XFS_RT is not set # CONFIG_XFS_DEBUG is not set # CONFIG_PAGEBUF_DEBUG is not set CONFIG_KDB=3Dn CONFIG_KDB_MODULES=3Dn # CONFIG_KDB_USB is not set # CONFIG_KDB_OFF is not set > On Tue, 16 Dec 2003, Mike Burger wrote: >=20 > > I'm wondering if anyone else has run into this with Axel's kernel(s). = I=20 > > ran into it after compiling his 2.4.20-24_30 src.rpm for use with RH7.1. > >=20 > > This morning, I monkeyed around a bit more, and removed the "usrquota"= =20 > > from the options I had set in my fstab file. Now, the filesystems moun= t=20 > > just fine. > >=20 >=20 --=20 Axel.Thimm@physik.fu-berlin.de --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/3yTtQBVS1GOamfERAggSAJ0csQ2ehRG9VvI5fX28zE9+5tfKdACgmsmX q7RZ68XkWRpNJY5KC+YP51M= =Y1NW -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-linux-xfs@oss.sgi.com Tue Dec 16 07:31:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 07:31:51 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGFVdTa026407 for ; Tue, 16 Dec 2003 07:31:40 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 6E107141B121; Tue, 16 Dec 2003 10:31:40 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 15E02141B120; Tue, 16 Dec 2003 10:31:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 1401530002B5; Tue, 16 Dec 2003 10:31:39 -0500 (EST) Date: Tue, 16 Dec 2003 10:31:38 -0500 (EST) From: Mike Burger To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: ATrpms kernel and quota oddity In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1444 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 1196 Lines: 43 Oddly enough, I just did a grep for "CONFIG_QUOTA=y" is turned on in all of the Intel architecture config files. On Tue, 16 Dec 2003, Mike Burger wrote: > On Tue, 16 Dec 2003, Eric Sandeen wrote: > > > Looks like Axel's RPMs don't have quota turned on - what > > does "modinfo xfs" say? > > > > I guess maybe I'll put my own updates out, so that they keep > > the same config options as before. Oh well, seemed like a good > > idea at the time. :) > > filename: /lib/modules/2.4.20-24_30.7.1/kernel/fs/xfs/xfs.o > description: "SGI XFS 1.3.0 with no debug enabled" > author: "Silicon Graphics, Inc." > license: "GPL" > > I did notice that the previous src.rpm that I'd compiled, 2.4.20-19 or > -20, had ACLs enabled, and that Axel's don't. > > I can recompile, if I know what option to pass, or to change in the > config. > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Tue Dec 16 07:48:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 07:48:23 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGFm8Ta026934 for ; Tue, 16 Dec 2003 07:48:09 -0800 Received: by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id hBGFm3GT013406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Dec 2003 16:48:05 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id hBGFljxS013070; Tue, 16 Dec 2003 16:47:45 +0100 Date: Tue, 16 Dec 2003 16:47:45 +0100 From: Axel Thimm To: Mike Burger Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: ATrpms kernel and quota oddity Message-ID: <20031216154745.GC8503@neu.nirvana> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E/DnYTRukya0zdZ1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 1445 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1482 Lines: 51 --E/DnYTRukya0zdZ1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 16, 2003 at 10:27:46AM -0500, Mike Burger wrote: > I did notice that the previous src.rpm that I'd compiled, 2.4.20-19 or=20 > -20, had ACLs enabled, and that Axel's don't. >=20 > I can recompile, if I know what option to pass, or to change in the=20 > config. There is a part in the specfile for adding XFS config options. That one does a bad detection of whether a config file belongs to a BOOT kernel or not. Change if echo $file | grep BOOT > /dev/null; then to if echo $file | grep -v BOOT > /dev/null; then to fix the reversed detection :( On Tue, Dec 16, 2003 at 10:31:38AM -0500, Mike Burger wrote: > Oddly enough, I just did a grep for "CONFIG_QUOTA=3Dy" is turned on in al= l=20 > of the Intel architecture config files. It is CONFIG_XFS_QUOTA that is not turned on. I suggest waiting for Eric's and/or Russell's comments on the sets of config options and then use them for rebuilding kernels. That's what I'll do also. Rebuilding all 40+ kernels will take some time though. --=20 Axel.Thimm@physik.fu-berlin.de --E/DnYTRukya0zdZ1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/3ykhQBVS1GOamfERApRRAJ4rVgrwQo2RCW24ezJv3mwAG0dp4QCZAeHg 5ybSn82soOo3gP+jv1J8DE8= =0wUb -----END PGP SIGNATURE----- --E/DnYTRukya0zdZ1-- From owner-linux-xfs@oss.sgi.com Tue Dec 16 07:51:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 07:52:06 -0800 (PST) Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGFprTa027370 for ; Tue, 16 Dec 2003 07:51:53 -0800 Received: from [24.118.170.148] (c-24-118-170-148.mn.client2.attbi.com [24.118.170.148]) by lips.borg.umn.edu (8.12.10/8.12.10) with ESMTP id hBGFphEM017723; Tue, 16 Dec 2003 09:51:43 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: LBD patch and XFS problem! From: Russell Cattelan To: Gustavo Rincon Cc: "'linux-xfs@oss.sgi.com'" , Tony Lambert , Ben McMillan In-Reply-To: References: Content-Type: multipart/mixed; boundary="=-zR1lYn0BaYIRWTPQbCJc" Message-Id: <1071589703.91750.14.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 16 Dec 2003 09:48:24 -0600 X-archive-position: 1446 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 27773 Lines: 662 --=-zR1lYn0BaYIRWTPQbCJc Content-Type: text/plain Content-Transfer-Encoding: 7bit Are you using the latest code? The current code is busted in regards to LBD you will need to ->reverse<- apply this patch to fix it back up. On Mon, 2003-12-15 at 14:46, Gustavo Rincon wrote: > Hi, I need some help with XFS and LBD patch. > > I was doing some testing with the linux-2.4.24-pre1+xfs + LBD patch (gotten > from ) and after a couple > minutes of accessing > the filesystem over the network (using samba-3.0.0 to export the > filesystem, and each > client is creating a 500G file and read it after the file was created) the > whole kernel > hangs without any message or going into kdb, using ext3 and reiserfs as a > filesystem an > running the same test the kernel does not hang and I'm able to perform the > test without > any problem. > > > I forced the kernel into KBD and the following trace I was able to get: > > > Entering kdb (current=0xc19ec000, pid 6) on processor 0 due to Keyboard > Entry > [0]kdb> b[0]kdb> bt[0]kdb> bt > Stack traceback for pid 6 > 0xc19ec000 6 1 1 0 R 0xc19ec280 *bdflush > ESP EIP Function (args) > 0xc19edf34 0xc0145b6a write_some_buffers+0x9a (0x0, 0x0, 0xc0340018, > 0x10f00, 0x > f7ff3fa4) > kernel .text 0xc0100000 0xc0145ad0 0xc0145c00 > 0xc19edfd8 0xc0149869 bdflush+0xb9 > kernel .text 0xc0100000 0xc01497b0 0xc0149890 > 0xc19edff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > [0]kdb> p[0]kdb> ps[0]kdb> ps [0]kdb> ps  [0]kdb> ps > Task Addr Pid Parent [*] cpu State Thread Command > 0xc19ec000 6 1 1 0 R 0xc19ec280 *bdflush > 0xc19ea000 7 1 1 1 R 0xc19ea280 kupdated > 0xf7ff2000 1 0 0 1 R 0xf7ff2280 init > 0xc19b2000 2 1 0 1 R 0xc19b2280 keventd > 0xc19b0000 3 1 0 0 S 0xc19b0280 ksoftirqd_CPU0 > 0xc19fe000 4 1 0 1 S 0xc19fe280 ksoftirqd_CPU1 > 0xc19ee000 5 1 0 1 S 0xc19ee280 kswapd > 0xc19ec000 6 1 1 0 R 0xc19ec280 *bdflush > 0xc19ea000 7 1 1 1 R 0xc19ea280 kupdated > 0xf7644000 13 1 0 0 S 0xf7644280 scsi_eh_0 > 0xf7506000 15 1 0 1 S 0xf7506280 mdrecoveryd > 0xf72f2000 17 1 0 1 R 0xf72f2280 kreiserfsd > 0xf798a000 60 1 0 1 S 0xf798a280 khubd > 0xf660a000 533 1 0 0 R 0xf660a280 syslogd > 0xf64e4000 537 1 0 1 S 0xf64e4280 klogd > 0xf6438000 546 1 0 0 S 0xf6438280 portmap > 0xf6374000 565 1 0 0 S 0xf6374280 rpc.statd > 0xf5ee8000 646 1 0 1 S 0xf5ee8280 sshd > 0xf5e54000 661 1 0 0 S 0xf5e54280 xinetd > 0xf69ca000 671 1 0 1 R 0xf69ca280 crond > 0xf6f20000 687 1 0 1 S 0xf6f20280 login > [0]more> > 0xf6324000 688 1 0 0 S 0xf6324280 login > 0xf60ec000 689 1 0 1 S 0xf60ec280 mingetty > 0xf5df8000 692 1 0 1 S 0xf5df8280 mingetty > 0xf5d50000 693 688 0 1 S 0xf5d50280 bash > 0xf5b1c000 743 1 0 1 R 0xf5b1c280 pagebufd > 0xf5b44000 744 1 0 0 R 0xf5b44280 xfslogd/0 > 0xf5af6000 745 1 0 1 S 0xf5af6280 xfslogd/1 > 0xf5a90000 746 1 0 0 S 0xf5a90280 xfsdatad/0 > 0xf5968000 747 1 0 1 S 0xf5968280 xfsdatad/1 > 0xf5b24000 748 1 0 1 R 0xf5b24280 xfssyncd > 0xf5b30000 756 687 0 1 S 0xf5b30280 bash > 0xf595e000 793 1 0 1 R 0xf595e280 nmbd > 0xf595a000 795 1 0 0 R 0xf595a280 smbd > 0xf5950000 798 795 0 1 R 0xf5950280 smbd > 0xf5948000 800 795 0 1 R 0xf5948280 smbd > 0xd840e000 802 795 0 0 R 0xd840e280 smbd > 0xd74e4000 805 795 0 0 R 0xd74e4280 smbd > [0]kdb> btp 743 > Stack traceback for pid 743 > 0xf5b1c000 743 1 0 1 R 0xf5b1c280 pagebufd > ESP EIP Function (args) > 0xf5b1df3c 0xc011abe6 schedule+0x2e6 (0x0, 0xf5b1c000, 0xf8aff64c, > 0xf8aff64c, 0 > xf5b1dfb8) > kernel .text 0xc0100000 0xc011a900 0xc011ae40 > 0xf5b1df8c 0xc011b11e interruptible_sleep_on+0x4e (0xf5b1dfc0, 0x84e9, > 0xf5b2400 > 0, 0xf5b1dfb8, 0xf5b1dfb8) > kernel .text 0xc0100000 0xc011b0d0 0xc011b150 > 0xf5b1dfac 0xf8ad8491 [xfs]pagebuf_daemon+0x1b1 > xfs .text 0xf8a72060 0xf8ad82e0 0xf8ad8560 > 0xf5b1dff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > [0]kdb> p[0]kdb> p [0]kdb> b[0]kdb> bt[0]kdb> btp[0]kdb> btp [0]kdb> btp > 7[0]kdb> btp 74[0]kdb> btp 744[0]kdb> btp 744 > Stack traceback for pid 744 > 0xf5b44000 744 1 0 0 R 0xf5b44280 xfslogd/0 > ESP EIP Function (args) > 0xf5b45f48 0xc011abe6 schedule+0x2e6 (0xf8b00334, 0xf8af0a92, 0xf8af0a98, > 0x0, 0 > x0) > kernel .text 0xc0100000 0xc011a900 0xc011ae40 > 0xf5b45f98 0xf8ad817a [xfs]pagebuf_iodone_daemon+0x13a > xfs .text 0xf8a72060 0xf8ad8040 0xf8ad81d0 > 0xf5b45fdc 0xf8ad8263 [xfs]pagebuf_logiodone_daemon+0x33 > xfs .text 0xf8a72060 0xf8ad8230 0xf8ad8270 > 0xf5b45ff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > [0]kdb> [0]kdb> btp 744 [0]kdb> btp 74 [0]kdb> btp 74[0]kdb> btp > 745[0]kdb> btp 745 > Stack traceback for pid 745 > 0xf5af6000 745 1 0 1 S 0xf5af6280 xfslogd/1 > ESP EIP Function (args) > 0xf5af7f48 0xc011abe6 schedule+0x2e6 (0xf5af624a, 0xf8af0a92, 0xf8af0a98, > 0x1, 0 > x0) > kernel .text 0xc0100000 0xc011a900 0xc011ae40 > 0xf5af7f98 0xf8ad817a [xfs]pagebuf_iodone_daemon+0x13a > xfs .text 0xf8a72060 0xf8ad8040 0xf8ad81d0 > 0xf5af7fdc 0xf8ad8263 [xfs]pagebuf_logiodone_daemon+0x33 > xfs .text 0xf8a72060 0xf8ad8230 0xf8ad8270 > 0xf5af7ff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > kdb> btp 746 > Stack traceback for pid 746 > 0xf5a90000 746 1 0 0 S 0xf5a90280 xfsdatad/0 > ESP EIP Function (args) > 0xf5a91f48 0xc011abe6 schedule+0x2e6 (0xf5a9024a, 0xf8af0a92, 0xf8af0aa0, > 0x0, 0 > x0) > kernel .text 0xc0100000 0xc011a900 0xc011ae40 > 0xf5a91f98 0xf8ad817a [xfs]pagebuf_iodone_daemon+0x13a > xfs .text 0xf8a72060 0xf8ad8040 0xf8ad81d0 > 0xf5a91fdc 0xf8ad82a3 [xfs]pagebuf_dataiodone_daemon+0x33 > xfs .text 0xf8a72060 0xf8ad8270 0xf8ad82b0 > 0xf5a91ff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > [0]kdb> [0]kdb> btp 746 [0]kdb> btp 748[0]kdb> btp 748 [0]kdb> btp > 747[0]kdb> btp 747 > Stack traceback for pid 747 > 0xf5968000 747 1 0 1 S 0xf5968280 xfsdatad/1 > ESP EIP Function (args) > 0xf5969f48 0xc011abe6 schedule+0x2e6 (0xf596824a, 0xf8af0a92, 0xf8af0aa0, > 0x1, 0 > x0) > kernel .text 0xc0100000 0xc011a900 0xc011ae40 > 0xf5969f98 0xf8ad817a [xfs]pagebuf_iodone_daemon+0x13a > xfs .text 0xf8a72060 0xf8ad8040 0xf8ad81d0 > 0xf5969fdc 0xf8ad82a3 [xfs]pagebuf_dataiodone_daemon+0x33 > xfs .text 0xf8a72060 0xf8ad8270 0xf8ad82b0 > 0xf5969ff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > [0]kdb> [0]kdb> btp 747 [0]kdb> btp 748[0]kdb> btp 748 > Stack traceback for pid 748 > 0xf5b24000 748 1 0 1 R 0xf5b24280 xfssyncd > ESP EIP Function (args) > 0xf5b25f50 0xc011abe6 schedule+0x2e6 (0xf5b25fac, 0xf5b24000, 0xf7ca4180, > 0x0, 0 > x0) > kernel .text 0xc0100000 0xc011a900 0xc011ae40 > 0xf5b25fa0 0xc011a888 schedule_timeout+0x58 (0xf7798c00, 0x71, 0x0) > kernel .text 0xc0100000 0xc011a830 0xc011a8e0 > 0xf5b25fdc 0xf8ae2781 [xfs]syncd+0xa1 > xfs .text 0xf8a72060 0xf8ae26e0 0xf8ae27d0 > 0xf5b25ff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > [0]kdb> > > > I created a filesystem using mkfs.xfs on a 2.7Terabyte md devices (Two 1.5 > Terabytes LUN defined in a 3ware 8000 raid controller) and the output was: > > meta-data=/dev/md0 isize=256 agcount=32, agsize=22888728 > blks > = sectsz=512 > data = bsize=4096 blocks=732439296, imaxpct=25 > = sunit=8 swidth=16 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > > The bdflush was set to "2 256 512 256 25 100 5 > 1 0" > > and the dmesg output was: > ]# dmesg > INTEL Product ID: S7501HG0 APIC at: 0xFEE00000 > I/O APIC #8 Version 32 at 0xFEC00000. > I/O APIC #9 Version 32 at 0xFEC81000. > I/O APIC #10 Version 32 at 0xFEC81400. > Enabling APIC mode: Flat. Using 3 I/O APICs > Processors: 2 > Kernel command line: ro root=/dev/hda3 console=ttyS0 > Initializing CPU#0 > Detected 2392.340 MHz processor. > Console: colour VGA+ 80x25 > Calibrating delay loop... 4771.02 BogoMIPS > Memory: 903912k/917504k available (1506k kernel code, 13204k reserved, 1104k > dat > a, 128k init, 0k highmem) > kdb version 4.3 by Keith Owens, Scott Lurndal. Copyright SGI, All Rights > Reserve > d > Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) > Inode cache hash table entries: 65536 (order: 7, 524288 bytes) > Mount cache hash table entries: 512 (order: 0, 4096 bytes) > Buffer cache hash table entries: 65536 (order: 6, 262144 bytes) > Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) > CPU: Trace cache: 12K uops, L1 D cache: 8K > CPU: L2 cache: 512K > CPU: Physical Processor ID: 0 > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 > CPU: Common caps: bfebfbff 00000000 00000000 00000000 > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Checking 'hlt' instruction... OK. > POSIX conformance testing by UNIFIX > mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) > mtrr: detected mtrr type: Intel > CPU: Trace cache: 12K uops, L1 D cache: 8K > CPU: L2 cache: 512K > CPU: Physical Processor ID: 0 > Intel machine check reporting enabled on CPU#0. > CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 > CPU: Common caps: bfebfbff 00000000 00000000 00000000 > CPU0: Intel(R) Xeon(TM) CPU 2.40GHz stepping 07 > per-CPU timeslice cutoff: 1462.89 usecs. > enabled ExtINT on CPU#0 > ESR value before enabling vector: 00000000 > ESR value after enabling vector: 00000000 > Booting processor 1/6 eip 2000 > Initializing CPU#1 > masked ExtINT on CPU#1 > ESR value before enabling vector: 00000000 > ESR value after enabling vector: 00000000 > Calibrating delay loop... 4784.12 BogoMIPS > CPU: Trace cache: 12K uops, L1 D cache: 8K > CPU: L2 cache: 512K > CPU: Physical Processor ID: 3 > Intel machine check reporting enabled on CPU#1. > CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 > CPU: Common caps: bfebfbff 00000000 00000000 00000000 > CPU1: Intel(R) Xeon(TM) CPU 2.40GHz stepping 07 > Total of 2 processors activated (9555.14 BogoMIPS). > WARNING: No sibling found for CPU 0. > WARNING: No sibling found for CPU 1. > ENABLING IO-APIC IRQs > Setting 8 in the phys_id_present_map > ...changing IO-APIC physical APIC ID to 8 ... ok. > Setting 9 in the phys_id_present_map > ...changing IO-APIC physical APIC ID to 9 ... ok. > Setting 10 in the phys_id_present_map > ...changing IO-APIC physical APIC ID to 10 ... ok. > init IO_APIC IRQs > IO-APIC (apicid-pin) 8-0, 8-20, 8-21, 8-22, 9-1, 9-2, 9-3, 9-4, 9-5, 9-6, > 9-7, > 9-8, 9-9, 9-10, 9-11, 9-12, 9-13, 9-14, 9-15, 9-16, 9-17, 9-18, 9-19, 9-20, > 9-21 > , 9-22, 9-23, 10-0, 10-1, 10-2, 10-3, 10-4, 10-5, 10-6, 10-7, 10-8, 10-9, > 10-12, > 10-13, 10-14, 10-15, 10-16, 10-17, 10-18, 10-19, 10-20, 10-21, 10-22, 10-23 > not > connected. > ..TIMER: vector=0x31 pin1=2 pin2=0 > number of MP IRQ sources: 24. > number of IO-APIC #8 registers: 24. > number of IO-APIC #9 registers: 24. > number of IO-APIC #10 registers: 24. > testing the IO APIC....................... > > IO APIC #8...... > .... register #00: 08000000 > ....... : physical APIC id: 08 > ....... : Delivery Type: 0 > ....... : LTS : 0 > .... register #01: 00178020 > ....... : max redirection entries: 0017 > ....... : PRQ implemented: 1 > ....... : IO APIC version: 0020 > .... register #02: 00000000 > ....... : arbitration: 00 > .... register #03: 00000001 > ....... : Boot DT : 1 > .... IRQ redirection table: > NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: > 00 000 00 1 0 0 0 0 0 0 00 > 01 003 03 0 0 0 0 0 1 1 39 > 02 003 03 0 0 0 0 0 1 1 31 > 03 003 03 0 0 0 0 0 1 1 41 > 04 003 03 0 0 0 0 0 1 1 49 > 05 003 03 0 0 0 0 0 1 1 51 > 06 003 03 0 0 0 0 0 1 1 59 > 07 003 03 0 0 0 0 0 1 1 61 > 08 003 03 0 0 0 0 0 1 1 69 > 09 003 03 0 0 0 0 0 1 1 71 > 0a 003 03 0 0 0 0 0 1 1 79 > 0b 003 03 0 0 0 0 0 1 1 89 > 0c 003 03 0 0 0 0 0 1 1 91 > 0d 003 03 0 0 0 0 0 1 1 99 > 0e 003 03 0 0 0 0 0 1 1 A1 > 0f 003 03 0 0 0 0 0 1 1 A9 > 10 003 03 1 1 0 1 0 1 1 B1 > 11 003 03 1 1 0 1 0 1 1 B9 > 12 003 03 1 1 0 1 0 1 1 C1 > 13 003 03 1 1 0 1 0 1 1 C9 > 14 000 00 1 0 0 0 0 0 0 00 > 15 07C 0C 1 0 0 0 0 0 2 05 > 16 000 00 1 0 0 0 0 0 0 00 > 17 003 03 1 1 0 1 0 1 1 D1 > > IO APIC #9...... > .... register #00: 09000000 > ....... : physical APIC id: 09 > ....... : Delivery Type: 0 > ....... : LTS : 0 > .... register #01: 00178020 > ....... : max redirection entries: 0017 > ....... : PRQ implemented: 1 > ....... : IO APIC version: 0020 > .... register #02: 09000000 > ....... : arbitration: 09 > .... register #03: 00000001 > ....... : Boot DT : 1 > .... IRQ redirection table: > NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: > 00 003 03 1 1 0 1 0 1 1 D9 > 01 000 00 1 0 0 0 0 0 0 00 > 02 000 00 1 0 0 0 0 0 0 00 > 03 000 00 1 0 0 0 0 0 0 00 > 04 000 00 1 0 0 0 0 0 0 00 > 05 000 00 1 0 0 0 0 0 0 00 > 06 000 00 1 0 0 0 0 0 0 00 > 07 000 00 1 0 0 0 0 0 0 00 > 08 000 00 1 0 0 0 0 0 0 00 > 09 000 00 1 0 0 0 0 0 0 00 > 0a 000 00 1 0 0 0 0 0 0 00 > 0b 000 00 1 0 0 0 0 0 0 00 > 0c 000 00 1 0 0 0 0 0 0 00 > 0d 000 00 1 0 0 0 0 0 0 00 > 0e 000 00 1 0 0 0 0 0 0 00 > 0f 000 00 1 0 0 0 0 0 0 00 > 10 000 00 1 0 0 0 0 0 0 00 > 11 000 00 1 0 0 0 0 0 0 00 > 12 000 00 1 0 0 0 0 0 0 00 > 13 000 00 1 0 0 0 0 0 0 00 > 14 000 00 1 0 0 0 0 0 0 00 > 15 000 00 1 0 0 0 0 0 0 00 > 16 000 00 1 0 0 0 0 0 0 00 > 17 000 00 1 0 0 0 0 0 0 00 > > IO APIC #10...... > .... register #00: 0A000000 > ....... : physical APIC id: 0A > ....... : Delivery Type: 0 > ....... : LTS : 0 > .... register #01: 00178020 > ....... : max redirection entries: 0017 > ....... : PRQ implemented: 1 > ....... : IO APIC version: 0020 > .... register #02: 0A000000 > ....... : arbitration: 0A > .... register #03: 00000001 > ....... : Boot DT : 1 > .... IRQ redirection table: > NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: > 00 000 00 1 0 0 0 0 0 0 00 > 01 000 00 1 0 0 0 0 0 0 00 > 02 000 00 1 0 0 0 0 0 0 00 > 03 000 00 1 0 0 0 0 0 0 00 > 04 000 00 1 0 0 0 0 0 0 00 > 05 000 00 1 0 0 0 0 0 0 00 > 06 000 00 1 0 0 0 0 0 0 00 > 07 000 00 1 0 0 0 0 0 0 00 > 08 000 00 1 0 0 0 0 0 0 00 > 09 000 00 1 0 0 0 0 0 0 00 > 0a 003 03 1 1 0 1 0 1 1 E1 > 0b 003 03 1 1 0 1 0 1 1 E9 > 0c 000 00 1 0 0 0 0 0 0 00 > 0d 000 00 1 0 0 0 0 0 0 00 > 0e 000 00 1 0 0 0 0 0 0 00 > 0f 000 00 1 0 0 0 0 0 0 00 > 10 000 00 1 0 0 0 0 0 0 00 > 11 000 00 1 0 0 0 0 0 0 00 > 12 000 00 1 0 0 0 0 0 0 00 > 13 000 00 1 0 0 0 0 0 0 00 > 14 000 00 1 0 0 0 0 0 0 00 > 15 000 00 1 0 0 0 0 0 0 00 > 16 000 00 1 0 0 0 0 0 0 00 > 17 000 00 1 0 0 0 0 0 0 00 > IRQ to pin mappings: > IRQ0 -> 0:2 > IRQ1 -> 0:1 > IRQ3 -> 0:3 > IRQ4 -> 0:4 > IRQ5 -> 0:5 > IRQ6 -> 0:6 > IRQ7 -> 0:7 > IRQ8 -> 0:8 > IRQ9 -> 0:9 > IRQ10 -> 0:10 > IRQ11 -> 0:11 > IRQ12 -> 0:12 > IRQ13 -> 0:13 > IRQ14 -> 0:14 > IRQ15 -> 0:15 > IRQ16 -> 0:16 > IRQ17 -> 0:17 > IRQ18 -> 0:18 > IRQ19 -> 0:19 > IRQ23 -> 0:23 > IRQ24 -> 1:0 > IRQ58 -> 2:10 > IRQ59 -> 2:11 > .................................... done. > Using local APIC timer interrupts. > calibrating APIC timer ... > ..... CPU clock speed is 2392.2650 MHz. > ..... host bus clock speed is 132.9033 MHz. > cpu: 0, clocks: 1329033, slice: 443011 > CPU0 > cpu: 1, clocks: 1329033, slice: 443011 > CPU1 > checking TSC synchronization across CPUs: passed. > Waiting on wait_init_idle (map = 0x2) > All processors have done init_idle > PCI: PCI BIOS revision 2.10 entry at 0xfdb55, last bus=4 > PCI: Using configuration type 1 > PCI: Probing PCI hardware > PCI: Probing PCI hardware (bus 00) > PCI: Ignoring BAR0-3 of IDE controller 00:1f.1 > PCI: Unable to handle 64-bit address space for > PCI: Unable to handle 64-bit address space for > Transparent bridge - Intel Corp. 82801BA/CA/DB/EB PCI Bridge > PCI: Using IRQ router PIIX/ICH [8086/2480] at 00:1f.0 > PCI->APIC IRQ transform: (B0,I29,P0) -> 16 > PCI->APIC IRQ transform: (B0,I29,P1) -> 19 > PCI->APIC IRQ transform: (B0,I29,P2) -> 18 > PCI->APIC IRQ transform: (B0,I31,P0) -> 17 > PCI->APIC IRQ transform: (B0,I31,P1) -> 17 > PCI->APIC IRQ transform: (B4,I5,P0) -> 58 > PCI->APIC IRQ transform: (B4,I5,P1) -> 59 > PCI->APIC IRQ transform: (B3,I2,P0) -> 24 > PCI->APIC IRQ transform: (B1,I12,P0) -> 23 > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Initializing RT netlink socket > Starting kswapd > VFS: Disk quotas vdquot_6.5.1 > i2c-core.o: i2c core module > pty: 2048 Unix98 ptys configured > Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ > SERIAL_PCI en > abled > ttyS00 at 0x03f8 (irq = 4) is a 16550A > ttyS01 at 0x02f8 (irq = 3) is a 16550A > Real Time Clock Driver v1.10f > Non-volatile memory driver v1.2 > xd: Out of memory. > Floppy drive(s): fd0 is 1.44M > FDC 0 is a National Semiconductor PC87306 > RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize > loop: loaded (max 8 devices) > Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > ICH3: IDE controller at PCI slot 00:1f.1 > PCI: Enabling device 00:1f.1 (0005 -> 0007) > ICH3: chipset revision 2 > ICH3: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0x03a0-0x03a7, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0x03a8-0x03af, BIOS settings: hdc:DMA, hdd:pio > hda: WDC WD400BB-00GFA0, ATA DISK drive > blk: queue c04012e0, I/O limit 4095Mb (mask 0xffffffff) > hdc: SR244W, ATAPI CD/DVD-ROM drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: attached ide-disk driver. > hda: host protected area => 1 > (40021 MB) w/2048KiB Cache, CHS=4865/255/63, UDMA(100) > hdc: attached ide-cdrom driver. > hdc: ATAPI 24X CD-ROM drive, 128kB Cache > Uniform CD-ROM driver Revision: 3.12 > Partition check: > hda: hda1 hda2 hda3 > Initializing Cryptographic API > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 8192 buckets, 64Kbytes > TCP: Hash tables configured (established 262144 bind 65536) > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > RAMDISK: Compressed image found at block 0 > Freeing initrd memory: 162k freed > VFS: Mounted root (ext2 filesystem). > SCSI subsystem driver Revision: 1.00 > 3ware Storage Controller device driver for Linux v1.02.00.037. > scsi0 : Found a 3ware Storage Controller at 0x2000, IRQ: 24, P-chip: 1.3 > scsi0 : 3ware Storage Controller > Vendor: 3ware Model: Logical Disk 0 Rev: 1.0 > Type: Direct-Access ANSI SCSI revision: 00 > Vendor: 3ware Model: Logical Disk 6 Rev: 1.0 > Type: Direct-Access ANSI SCSI revision: 00 > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 > Attached scsi disk sdb at scsi0, channel 0, id 6, lun 0 > SCSI device sda: 2930368512 512-byte hdwr sectors (1500349 MB) > sda: sda1 sda2 sda3 > SCSI device sdb: 2930368512 512-byte hdwr sectors (1500349 MB) > sdb: sdb1 sdb2 sdb3 > md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 > md: raid0 personality registered as nr 2 > reiserfs: found format "3.6" with standard journal > reiserfs: checking transaction log (device ide0(3,3)) ... > for (ide0(3,3)) > reiserfs: replayed 27 transactions in 0 seconds > ide0(3,3):Using r5 hash to sort names > Freeing unused kernel memory: 128k freed > usb.c: registered new driver usbdevfs > usb.c: registered new driver hub > usb-uhci.c: $Revision: 1.275 $ time 20:12:37 Dec 11 2003 > usb-uhci.c: High bandwidth mode enabled > PCI: Setting latency timer of device 00:1d.0 to 64 > usb-uhci.c: USB UHCI at I/O 0x4040, IRQ 16 > usb-uhci.c: Detected 2 ports > usb.c: new USB bus registered, assigned bus number 1 > hub.c: USB hub found > hub.c: 2 ports detected > PCI: Setting latency timer of device 00:1d.1 to 64 > usb-uhci.c: USB UHCI at I/O 0x4020, IRQ 19 > usb-uhci.c: Detected 2 ports > usb.c: new USB bus registered, assigned bus number 2 > hub.c: USB hub found > hub.c: 2 ports detected > PCI: Setting latency timer of device 00:1d.2 to 64 > usb-uhci.c: USB UHCI at I/O 0x4000, IRQ 18 > usb-uhci.c: Detected 2 ports > usb.c: new USB bus registered, assigned bus number 3 > hub.c: USB hub found > hub.c: 2 ports detected > usb-uhci.c: v1.275:USB Universal Host Controller Interface driver > Adding Swap: 2097136k swap-space (priority -1) > Intel(R) PRO/1000 Network Driver - version 5.2.20-k1 > Copyright (c) 1999-2003 Intel Corporation. > eth0: Intel(R) PRO/1000 Network Connection > eth1: Intel(R) PRO/1000 Network Connection > e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex > e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex > md: bind > md: nonpersistent superblock ... > md: bind > md: nonpersistent superblock ... > md: sdb3's event counter: 00000000 > md: sda3's event counter: 00000000 > md0: max total readahead window set to 496k > md0: 2 data-disks, max readahead per data-disk: 248k > raid0: looking at sda3 > raid0: comparing sda3(1464879072) with sda3(1464879072) > raid0: END > raid0: ==> UNIQUE > raid0: 1 zones > raid0: looking at sdb3 > raid0: comparing sdb3(1464879072) with sda3(1464879072) > raid0: EQUAL > raid0: FINAL 1 zones > raid0: zone 0 > raid0: checking sda3 ... contained as device 0 > (1464879072) is smallest!. > raid0: checking sdb3 ... contained as device 1 > raid0: zone->nb_dev: 2, size: -1365209152 > raid0: current zone offset: 1464879072 > raid0: done. > raid0 : md_size is 2929758144 blocks. > raid0 : conf->smallest->size is -1365209152 blocks. > raid0 : nb_zone is 1. > raid0 : Allocating 8 bytes for hash. > SGI-XFS CVS-2003-11-24_06:00_UTC with ACLs, large block numbers, no debug > enable > d > SGI XFS Quota Management subsystem > XFS mounting filesystem md(9,0) > Ending clean XFS mount for filesystem: md(9,0) > > > > I do not if someone can help me trying to debug or/and fix this problems > > > Thank you > Gustavo Rincon -- Russell Cattelan --=-zR1lYn0BaYIRWTPQbCJc Content-Disposition: attachment; filename="patch_xfs-linux:slinx:163370a" Content-Type: text/x-patch; name="patch_xfs-linux:slinx:163370a"; charset=iso-8859-1 Content-Transfer-Encoding: 7bit diff -Naur -Xskipfiles slinx.orig/linux/xfs_aops.c slinx/linux/xfs_aops.c --- slinx.orig/linux/xfs_aops.c 2003-12-08 21:18:33.000000000 -0600 +++ slinx/linux/xfs_aops.c 2003-12-11 18:27:16.000000000 -0600 @@ -910,7 +910,7 @@ create, 1, BMAPI_WRITE|BMAPI_DIRECT); } -STATIC sector_t +STATIC int linvfs_bmap( struct address_space *mapping, sector_t block) @@ -1117,7 +1117,7 @@ int rw, struct inode *inode, struct kiobuf *iobuf, - sector_t blocknr, + unsigned long blocknr, int blocksize) { struct page **maplist; @@ -1225,21 +1225,6 @@ } -/* since the address_space_operations are not consitent with the type used - * for block indexes we must cast the functions into what is expected.. - * thus the following 2 lines. - * If running on a kernel with LBD support and hence bmap and direct_IO - * correctly defined with sector_t params. use the second set of typedefs - * or casts from the address space_operations - * RMC - */ - -#ifndef HAVE_SECTOR_T -typedef int (bmap_proc)(struct address_space *, long); -typedef int (direct_IO_proc)(int, struct inode *, struct kiobuf *, - unsigned long, int); -#endif - struct address_space_operations linvfs_aops = { .readpage = linvfs_readpage, .writepage = linvfs_writepage, @@ -1247,11 +1232,6 @@ .releasepage = linvfs_release_page, .prepare_write = linvfs_prepare_write, .commit_write = generic_commit_write, -#ifndef HAVE_SECTOR_T - .bmap = (bmap_proc *)linvfs_bmap, - .direct_IO = (direct_IO_proc *)linvfs_direct_IO, -#else .bmap = linvfs_bmap, .direct_IO = linvfs_direct_IO, -#endif }; --=-zR1lYn0BaYIRWTPQbCJc-- From owner-linux-xfs@oss.sgi.com Tue Dec 16 08:40:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 08:41:18 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGGevTa031562 for ; Tue, 16 Dec 2003 08:40:57 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBGHwNm7024779 for ; Tue, 16 Dec 2003 11:58:23 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBGGdoSC21109728; Tue, 16 Dec 2003 10:39:51 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBGGdgK110608972; Tue, 16 Dec 2003 10:39:42 -0600 (CST) Subject: Re: OT: CXFS From: Eric Sandeen To: Frank Hellmann Cc: XFS List In-Reply-To: <3FDF1EB7.9080905@opticalart.de> References: <3FDF1EB7.9080905@opticalart.de> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1071592789.18446.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Dec 2003 10:39:50 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1447 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1138 Lines: 33 Hi Frank - Yes, SGI does offer an IA32 Linux CXFS client. Someone who can help you should be contacting you shortly. The last two releases did not have >2T support for the Linux client, but that should be on the horizon. -Eric On Tue, 2003-12-16 at 09:03, Frank Hellmann wrote: > Hi! > > This is a bit off-topic, but has anybody come in contact with the CXFS > client/implementation for Linux? > > We have a need for our render systems to get faster access to the > original film frames to work on (from 12MB up to 50MB size per > frame/file). A clustered filesystem might solve our current network > bottleneck (Gbit Ethernet) and would make use of the existing > fibrechannel infrastructure. > > I am most interested in actually how good and stable the linux client > performs. Is there is any big device support (>2TB)? > > I would be really gratefull if somebody could point me to more detailed > infos about CXFS than the marketing blurb on SGIs site... > > Thanks a lot, > > Frank... -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Dec 16 09:07:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 09:07:30 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGH77Ta001493 for ; Tue, 16 Dec 2003 09:07:08 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBGIOYm7005568 for ; Tue, 16 Dec 2003 12:24:34 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBGH71SC21132209; Tue, 16 Dec 2003 11:07:01 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBGH6gK110616318; Tue, 16 Dec 2003 11:06:42 -0600 (CST) Subject: Re: ATrpms kernel and quota oddity From: Eric Sandeen To: Axel Thimm Cc: Mike Burger , linux-xfs@oss.sgi.com In-Reply-To: <20031216152950.GA8503@neu.nirvana> References: <20031216152950.GA8503@neu.nirvana> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1071594410.18446.58.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Dec 2003 11:06:50 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1448 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2051 Lines: 66 Hi Axel - those look pretty sane. I might not include DMAPI support, I doubt that many, if any of your users need that. Also, I see CONFIG_XFS_PRESENT - this is only used when the xfs out of tree patch is applied - which allows xfs to be built outside the kernel tree. If you don't have an xfs-oot.patch in place, you probably don't need CONFIG_XFS_PRESENT> For KDB, you might consider CONFIG_KDB_OFF=y, which will make kdb inactive until the user sets /proc/sys/kernel/kdb to 1 - otherwise any oops will send the box to kdb, which is perhaps not the friendliest thing to do to a casual user. -Eric On Tue, 2003-12-16 at 09:29, Axel Thimm wrote: > Just for reference, Eric, are these the currently recommended settings > for BOOT vs non-BOOT? Otherwise would you provide a better set I can > use for the ATrpms kernels? Thanks. > > non-BOOT: > # XFS-specific options > > CONFIG_XFS_PRESENT=y > CONFIG_XFS_FS=m > CONFIG_XFS_POSIX_ACL=y > CONFIG_XFS_DMAPI=y > CONFIG_XFS_QUOTA=y > # CONFIG_XFS_RT is not set > # CONFIG_XFS_DEBUG is not set > # CONFIG_PAGEBUF_DEBUG is not set > CONFIG_KDB=y > CONFIG_KDB_MODULES=m > # CONFIG_KDB_USB is not set > # CONFIG_KDB_OFF is not set > > BOOT: > # XFS-specific options > > CONFIG_XFS_PRESENT=y > CONFIG_XFS_FS=m > CONFIG_XFS_POSIX_ACL=n > CONFIG_XFS_DMAPI=n > CONFIG_XFS_QUOTA=n > # CONFIG_XFS_RT is not set > # CONFIG_XFS_DEBUG is not set > # CONFIG_PAGEBUF_DEBUG is not set > CONFIG_KDB=n > CONFIG_KDB_MODULES=n > # CONFIG_KDB_USB is not set > # CONFIG_KDB_OFF is not set > > > On Tue, 16 Dec 2003, Mike Burger wrote: > > > > > I'm wondering if anyone else has run into this with Axel's kernel(s). I > > > ran into it after compiling his 2.4.20-24_30 src.rpm for use with RH7.1. > > > > > > This morning, I monkeyed around a bit more, and removed the "usrquota" > > > from the options I had set in my fstab file. Now, the filesystems mount > > > just fine. > > > > > -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Dec 16 12:37:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 12:37:23 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGKaxTa012074 for ; Tue, 16 Dec 2003 12:36:59 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBGIifOO031811 for ; Tue, 16 Dec 2003 10:44:41 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBGKarSC21205710; Tue, 16 Dec 2003 14:36:53 -0600 (CST) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBGKajoZ775725; Tue, 16 Dec 2003 14:36:45 -0600 (CST) Subject: Re: LBD patch and XFS problem! From: Russell Cattelan To: Gustavo Rincon Cc: "'linux-xfs@oss.sgi.com'" , Tony Lambert , Ben McMillan In-Reply-To: References: Content-Type: text/plain Message-Id: <1071607013.7170.118.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-1mdk Date: Tue, 16 Dec 2003 14:36:53 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1449 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 25901 Lines: 597 Ok looking this over more, we need more info. All the daemons are doing nothing, hence them being in schedual. Do bta (backtrace all) and attach it to the bugzilla bug. I think the back traces of the smbd will shed some light on the situation. On Mon, 2003-12-15 at 14:46, Gustavo Rincon wrote: > Hi, I need some help with XFS and LBD patch. > > I was doing some testing with the linux-2.4.24-pre1+xfs + LBD patch (gotten > from ) and after a couple > minutes of accessing > the filesystem over the network (using samba-3.0.0 to export the > filesystem, and each > client is creating a 500G file and read it after the file was created) the > whole kernel > hangs without any message or going into kdb, using ext3 and reiserfs as a > filesystem an > running the same test the kernel does not hang and I'm able to perform the > test without > any problem. > > > I forced the kernel into KBD and the following trace I was able to get: > > > Entering kdb (current=0xc19ec000, pid 6) on processor 0 due to Keyboard > Entry > [0]kdb> b[0]kdb> bt[0]kdb> bt > Stack traceback for pid 6 > 0xc19ec000 6 1 1 0 R 0xc19ec280 *bdflush > ESP EIP Function (args) > 0xc19edf34 0xc0145b6a write_some_buffers+0x9a (0x0, 0x0, 0xc0340018, > 0x10f00, 0x > f7ff3fa4) > kernel .text 0xc0100000 0xc0145ad0 0xc0145c00 > 0xc19edfd8 0xc0149869 bdflush+0xb9 > kernel .text 0xc0100000 0xc01497b0 0xc0149890 > 0xc19edff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > [0]kdb> p[0]kdb> ps[0]kdb> ps [0]kdb> ps  [0]kdb> ps > Task Addr Pid Parent [*] cpu State Thread Command > 0xc19ec000 6 1 1 0 R 0xc19ec280 *bdflush > 0xc19ea000 7 1 1 1 R 0xc19ea280 kupdated > 0xf7ff2000 1 0 0 1 R 0xf7ff2280 init > 0xc19b2000 2 1 0 1 R 0xc19b2280 keventd > 0xc19b0000 3 1 0 0 S 0xc19b0280 ksoftirqd_CPU0 > 0xc19fe000 4 1 0 1 S 0xc19fe280 ksoftirqd_CPU1 > 0xc19ee000 5 1 0 1 S 0xc19ee280 kswapd > 0xc19ec000 6 1 1 0 R 0xc19ec280 *bdflush > 0xc19ea000 7 1 1 1 R 0xc19ea280 kupdated > 0xf7644000 13 1 0 0 S 0xf7644280 scsi_eh_0 > 0xf7506000 15 1 0 1 S 0xf7506280 mdrecoveryd > 0xf72f2000 17 1 0 1 R 0xf72f2280 kreiserfsd > 0xf798a000 60 1 0 1 S 0xf798a280 khubd > 0xf660a000 533 1 0 0 R 0xf660a280 syslogd > 0xf64e4000 537 1 0 1 S 0xf64e4280 klogd > 0xf6438000 546 1 0 0 S 0xf6438280 portmap > 0xf6374000 565 1 0 0 S 0xf6374280 rpc.statd > 0xf5ee8000 646 1 0 1 S 0xf5ee8280 sshd > 0xf5e54000 661 1 0 0 S 0xf5e54280 xinetd > 0xf69ca000 671 1 0 1 R 0xf69ca280 crond > 0xf6f20000 687 1 0 1 S 0xf6f20280 login > [0]more> > 0xf6324000 688 1 0 0 S 0xf6324280 login > 0xf60ec000 689 1 0 1 S 0xf60ec280 mingetty > 0xf5df8000 692 1 0 1 S 0xf5df8280 mingetty > 0xf5d50000 693 688 0 1 S 0xf5d50280 bash > 0xf5b1c000 743 1 0 1 R 0xf5b1c280 pagebufd > 0xf5b44000 744 1 0 0 R 0xf5b44280 xfslogd/0 > 0xf5af6000 745 1 0 1 S 0xf5af6280 xfslogd/1 > 0xf5a90000 746 1 0 0 S 0xf5a90280 xfsdatad/0 > 0xf5968000 747 1 0 1 S 0xf5968280 xfsdatad/1 > 0xf5b24000 748 1 0 1 R 0xf5b24280 xfssyncd > 0xf5b30000 756 687 0 1 S 0xf5b30280 bash > 0xf595e000 793 1 0 1 R 0xf595e280 nmbd > 0xf595a000 795 1 0 0 R 0xf595a280 smbd > 0xf5950000 798 795 0 1 R 0xf5950280 smbd > 0xf5948000 800 795 0 1 R 0xf5948280 smbd > 0xd840e000 802 795 0 0 R 0xd840e280 smbd > 0xd74e4000 805 795 0 0 R 0xd74e4280 smbd > [0]kdb> btp 743 > Stack traceback for pid 743 > 0xf5b1c000 743 1 0 1 R 0xf5b1c280 pagebufd > ESP EIP Function (args) > 0xf5b1df3c 0xc011abe6 schedule+0x2e6 (0x0, 0xf5b1c000, 0xf8aff64c, > 0xf8aff64c, 0 > xf5b1dfb8) > kernel .text 0xc0100000 0xc011a900 0xc011ae40 > 0xf5b1df8c 0xc011b11e interruptible_sleep_on+0x4e (0xf5b1dfc0, 0x84e9, > 0xf5b2400 > 0, 0xf5b1dfb8, 0xf5b1dfb8) > kernel .text 0xc0100000 0xc011b0d0 0xc011b150 > 0xf5b1dfac 0xf8ad8491 [xfs]pagebuf_daemon+0x1b1 > xfs .text 0xf8a72060 0xf8ad82e0 0xf8ad8560 > 0xf5b1dff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > [0]kdb> p[0]kdb> p [0]kdb> b[0]kdb> bt[0]kdb> btp[0]kdb> btp [0]kdb> btp > 7[0]kdb> btp 74[0]kdb> btp 744[0]kdb> btp 744 > Stack traceback for pid 744 > 0xf5b44000 744 1 0 0 R 0xf5b44280 xfslogd/0 > ESP EIP Function (args) > 0xf5b45f48 0xc011abe6 schedule+0x2e6 (0xf8b00334, 0xf8af0a92, 0xf8af0a98, > 0x0, 0 > x0) > kernel .text 0xc0100000 0xc011a900 0xc011ae40 > 0xf5b45f98 0xf8ad817a [xfs]pagebuf_iodone_daemon+0x13a > xfs .text 0xf8a72060 0xf8ad8040 0xf8ad81d0 > 0xf5b45fdc 0xf8ad8263 [xfs]pagebuf_logiodone_daemon+0x33 > xfs .text 0xf8a72060 0xf8ad8230 0xf8ad8270 > 0xf5b45ff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > [0]kdb> [0]kdb> btp 744 [0]kdb> btp 74 [0]kdb> btp 74[0]kdb> btp > 745[0]kdb> btp 745 > Stack traceback for pid 745 > 0xf5af6000 745 1 0 1 S 0xf5af6280 xfslogd/1 > ESP EIP Function (args) > 0xf5af7f48 0xc011abe6 schedule+0x2e6 (0xf5af624a, 0xf8af0a92, 0xf8af0a98, > 0x1, 0 > x0) > kernel .text 0xc0100000 0xc011a900 0xc011ae40 > 0xf5af7f98 0xf8ad817a [xfs]pagebuf_iodone_daemon+0x13a > xfs .text 0xf8a72060 0xf8ad8040 0xf8ad81d0 > 0xf5af7fdc 0xf8ad8263 [xfs]pagebuf_logiodone_daemon+0x33 > xfs .text 0xf8a72060 0xf8ad8230 0xf8ad8270 > 0xf5af7ff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > kdb> btp 746 > Stack traceback for pid 746 > 0xf5a90000 746 1 0 0 S 0xf5a90280 xfsdatad/0 > ESP EIP Function (args) > 0xf5a91f48 0xc011abe6 schedule+0x2e6 (0xf5a9024a, 0xf8af0a92, 0xf8af0aa0, > 0x0, 0 > x0) > kernel .text 0xc0100000 0xc011a900 0xc011ae40 > 0xf5a91f98 0xf8ad817a [xfs]pagebuf_iodone_daemon+0x13a > xfs .text 0xf8a72060 0xf8ad8040 0xf8ad81d0 > 0xf5a91fdc 0xf8ad82a3 [xfs]pagebuf_dataiodone_daemon+0x33 > xfs .text 0xf8a72060 0xf8ad8270 0xf8ad82b0 > 0xf5a91ff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > [0]kdb> [0]kdb> btp 746 [0]kdb> btp 748[0]kdb> btp 748 [0]kdb> btp > 747[0]kdb> btp 747 > Stack traceback for pid 747 > 0xf5968000 747 1 0 1 S 0xf5968280 xfsdatad/1 > ESP EIP Function (args) > 0xf5969f48 0xc011abe6 schedule+0x2e6 (0xf596824a, 0xf8af0a92, 0xf8af0aa0, > 0x1, 0 > x0) > kernel .text 0xc0100000 0xc011a900 0xc011ae40 > 0xf5969f98 0xf8ad817a [xfs]pagebuf_iodone_daemon+0x13a > xfs .text 0xf8a72060 0xf8ad8040 0xf8ad81d0 > 0xf5969fdc 0xf8ad82a3 [xfs]pagebuf_dataiodone_daemon+0x33 > xfs .text 0xf8a72060 0xf8ad8270 0xf8ad82b0 > 0xf5969ff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > [0]kdb> [0]kdb> btp 747 [0]kdb> btp 748[0]kdb> btp 748 > Stack traceback for pid 748 > 0xf5b24000 748 1 0 1 R 0xf5b24280 xfssyncd > ESP EIP Function (args) > 0xf5b25f50 0xc011abe6 schedule+0x2e6 (0xf5b25fac, 0xf5b24000, 0xf7ca4180, > 0x0, 0 > x0) > kernel .text 0xc0100000 0xc011a900 0xc011ae40 > 0xf5b25fa0 0xc011a888 schedule_timeout+0x58 (0xf7798c00, 0x71, 0x0) > kernel .text 0xc0100000 0xc011a830 0xc011a8e0 > 0xf5b25fdc 0xf8ae2781 [xfs]syncd+0xa1 > xfs .text 0xf8a72060 0xf8ae26e0 0xf8ae27d0 > 0xf5b25ff4 0xc010757e arch_kernel_thread+0x2e > kernel .text 0xc0100000 0xc0107550 0xc0107590 > [0]kdb> > > > I created a filesystem using mkfs.xfs on a 2.7Terabyte md devices (Two 1.5 > Terabytes LUN defined in a 3ware 8000 raid controller) and the output was: > > meta-data=/dev/md0 isize=256 agcount=32, agsize=22888728 > blks > = sectsz=512 > data = bsize=4096 blocks=732439296, imaxpct=25 > = sunit=8 swidth=16 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > > The bdflush was set to "2 256 512 256 25 100 5 > 1 0" > > and the dmesg output was: > ]# dmesg > INTEL Product ID: S7501HG0 APIC at: 0xFEE00000 > I/O APIC #8 Version 32 at 0xFEC00000. > I/O APIC #9 Version 32 at 0xFEC81000. > I/O APIC #10 Version 32 at 0xFEC81400. > Enabling APIC mode: Flat. Using 3 I/O APICs > Processors: 2 > Kernel command line: ro root=/dev/hda3 console=ttyS0 > Initializing CPU#0 > Detected 2392.340 MHz processor. > Console: colour VGA+ 80x25 > Calibrating delay loop... 4771.02 BogoMIPS > Memory: 903912k/917504k available (1506k kernel code, 13204k reserved, 1104k > dat > a, 128k init, 0k highmem) > kdb version 4.3 by Keith Owens, Scott Lurndal. Copyright SGI, All Rights > Reserve > d > Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) > Inode cache hash table entries: 65536 (order: 7, 524288 bytes) > Mount cache hash table entries: 512 (order: 0, 4096 bytes) > Buffer cache hash table entries: 65536 (order: 6, 262144 bytes) > Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) > CPU: Trace cache: 12K uops, L1 D cache: 8K > CPU: L2 cache: 512K > CPU: Physical Processor ID: 0 > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 > CPU: Common caps: bfebfbff 00000000 00000000 00000000 > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Checking 'hlt' instruction... OK. > POSIX conformance testing by UNIFIX > mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) > mtrr: detected mtrr type: Intel > CPU: Trace cache: 12K uops, L1 D cache: 8K > CPU: L2 cache: 512K > CPU: Physical Processor ID: 0 > Intel machine check reporting enabled on CPU#0. > CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 > CPU: Common caps: bfebfbff 00000000 00000000 00000000 > CPU0: Intel(R) Xeon(TM) CPU 2.40GHz stepping 07 > per-CPU timeslice cutoff: 1462.89 usecs. > enabled ExtINT on CPU#0 > ESR value before enabling vector: 00000000 > ESR value after enabling vector: 00000000 > Booting processor 1/6 eip 2000 > Initializing CPU#1 > masked ExtINT on CPU#1 > ESR value before enabling vector: 00000000 > ESR value after enabling vector: 00000000 > Calibrating delay loop... 4784.12 BogoMIPS > CPU: Trace cache: 12K uops, L1 D cache: 8K > CPU: L2 cache: 512K > CPU: Physical Processor ID: 3 > Intel machine check reporting enabled on CPU#1. > CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 > CPU: Common caps: bfebfbff 00000000 00000000 00000000 > CPU1: Intel(R) Xeon(TM) CPU 2.40GHz stepping 07 > Total of 2 processors activated (9555.14 BogoMIPS). > WARNING: No sibling found for CPU 0. > WARNING: No sibling found for CPU 1. > ENABLING IO-APIC IRQs > Setting 8 in the phys_id_present_map > ...changing IO-APIC physical APIC ID to 8 ... ok. > Setting 9 in the phys_id_present_map > ...changing IO-APIC physical APIC ID to 9 ... ok. > Setting 10 in the phys_id_present_map > ...changing IO-APIC physical APIC ID to 10 ... ok. > init IO_APIC IRQs > IO-APIC (apicid-pin) 8-0, 8-20, 8-21, 8-22, 9-1, 9-2, 9-3, 9-4, 9-5, 9-6, > 9-7, > 9-8, 9-9, 9-10, 9-11, 9-12, 9-13, 9-14, 9-15, 9-16, 9-17, 9-18, 9-19, 9-20, > 9-21 > , 9-22, 9-23, 10-0, 10-1, 10-2, 10-3, 10-4, 10-5, 10-6, 10-7, 10-8, 10-9, > 10-12, > 10-13, 10-14, 10-15, 10-16, 10-17, 10-18, 10-19, 10-20, 10-21, 10-22, 10-23 > not > connected. > ..TIMER: vector=0x31 pin1=2 pin2=0 > number of MP IRQ sources: 24. > number of IO-APIC #8 registers: 24. > number of IO-APIC #9 registers: 24. > number of IO-APIC #10 registers: 24. > testing the IO APIC....................... > > IO APIC #8...... > .... register #00: 08000000 > ....... : physical APIC id: 08 > ....... : Delivery Type: 0 > ....... : LTS : 0 > .... register #01: 00178020 > ....... : max redirection entries: 0017 > ....... : PRQ implemented: 1 > ....... : IO APIC version: 0020 > .... register #02: 00000000 > ....... : arbitration: 00 > .... register #03: 00000001 > ....... : Boot DT : 1 > .... IRQ redirection table: > NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: > 00 000 00 1 0 0 0 0 0 0 00 > 01 003 03 0 0 0 0 0 1 1 39 > 02 003 03 0 0 0 0 0 1 1 31 > 03 003 03 0 0 0 0 0 1 1 41 > 04 003 03 0 0 0 0 0 1 1 49 > 05 003 03 0 0 0 0 0 1 1 51 > 06 003 03 0 0 0 0 0 1 1 59 > 07 003 03 0 0 0 0 0 1 1 61 > 08 003 03 0 0 0 0 0 1 1 69 > 09 003 03 0 0 0 0 0 1 1 71 > 0a 003 03 0 0 0 0 0 1 1 79 > 0b 003 03 0 0 0 0 0 1 1 89 > 0c 003 03 0 0 0 0 0 1 1 91 > 0d 003 03 0 0 0 0 0 1 1 99 > 0e 003 03 0 0 0 0 0 1 1 A1 > 0f 003 03 0 0 0 0 0 1 1 A9 > 10 003 03 1 1 0 1 0 1 1 B1 > 11 003 03 1 1 0 1 0 1 1 B9 > 12 003 03 1 1 0 1 0 1 1 C1 > 13 003 03 1 1 0 1 0 1 1 C9 > 14 000 00 1 0 0 0 0 0 0 00 > 15 07C 0C 1 0 0 0 0 0 2 05 > 16 000 00 1 0 0 0 0 0 0 00 > 17 003 03 1 1 0 1 0 1 1 D1 > > IO APIC #9...... > .... register #00: 09000000 > ....... : physical APIC id: 09 > ....... : Delivery Type: 0 > ....... : LTS : 0 > .... register #01: 00178020 > ....... : max redirection entries: 0017 > ....... : PRQ implemented: 1 > ....... : IO APIC version: 0020 > .... register #02: 09000000 > ....... : arbitration: 09 > .... register #03: 00000001 > ....... : Boot DT : 1 > .... IRQ redirection table: > NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: > 00 003 03 1 1 0 1 0 1 1 D9 > 01 000 00 1 0 0 0 0 0 0 00 > 02 000 00 1 0 0 0 0 0 0 00 > 03 000 00 1 0 0 0 0 0 0 00 > 04 000 00 1 0 0 0 0 0 0 00 > 05 000 00 1 0 0 0 0 0 0 00 > 06 000 00 1 0 0 0 0 0 0 00 > 07 000 00 1 0 0 0 0 0 0 00 > 08 000 00 1 0 0 0 0 0 0 00 > 09 000 00 1 0 0 0 0 0 0 00 > 0a 000 00 1 0 0 0 0 0 0 00 > 0b 000 00 1 0 0 0 0 0 0 00 > 0c 000 00 1 0 0 0 0 0 0 00 > 0d 000 00 1 0 0 0 0 0 0 00 > 0e 000 00 1 0 0 0 0 0 0 00 > 0f 000 00 1 0 0 0 0 0 0 00 > 10 000 00 1 0 0 0 0 0 0 00 > 11 000 00 1 0 0 0 0 0 0 00 > 12 000 00 1 0 0 0 0 0 0 00 > 13 000 00 1 0 0 0 0 0 0 00 > 14 000 00 1 0 0 0 0 0 0 00 > 15 000 00 1 0 0 0 0 0 0 00 > 16 000 00 1 0 0 0 0 0 0 00 > 17 000 00 1 0 0 0 0 0 0 00 > > IO APIC #10...... > .... register #00: 0A000000 > ....... : physical APIC id: 0A > ....... : Delivery Type: 0 > ....... : LTS : 0 > .... register #01: 00178020 > ....... : max redirection entries: 0017 > ....... : PRQ implemented: 1 > ....... : IO APIC version: 0020 > .... register #02: 0A000000 > ....... : arbitration: 0A > .... register #03: 00000001 > ....... : Boot DT : 1 > .... IRQ redirection table: > NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: > 00 000 00 1 0 0 0 0 0 0 00 > 01 000 00 1 0 0 0 0 0 0 00 > 02 000 00 1 0 0 0 0 0 0 00 > 03 000 00 1 0 0 0 0 0 0 00 > 04 000 00 1 0 0 0 0 0 0 00 > 05 000 00 1 0 0 0 0 0 0 00 > 06 000 00 1 0 0 0 0 0 0 00 > 07 000 00 1 0 0 0 0 0 0 00 > 08 000 00 1 0 0 0 0 0 0 00 > 09 000 00 1 0 0 0 0 0 0 00 > 0a 003 03 1 1 0 1 0 1 1 E1 > 0b 003 03 1 1 0 1 0 1 1 E9 > 0c 000 00 1 0 0 0 0 0 0 00 > 0d 000 00 1 0 0 0 0 0 0 00 > 0e 000 00 1 0 0 0 0 0 0 00 > 0f 000 00 1 0 0 0 0 0 0 00 > 10 000 00 1 0 0 0 0 0 0 00 > 11 000 00 1 0 0 0 0 0 0 00 > 12 000 00 1 0 0 0 0 0 0 00 > 13 000 00 1 0 0 0 0 0 0 00 > 14 000 00 1 0 0 0 0 0 0 00 > 15 000 00 1 0 0 0 0 0 0 00 > 16 000 00 1 0 0 0 0 0 0 00 > 17 000 00 1 0 0 0 0 0 0 00 > IRQ to pin mappings: > IRQ0 -> 0:2 > IRQ1 -> 0:1 > IRQ3 -> 0:3 > IRQ4 -> 0:4 > IRQ5 -> 0:5 > IRQ6 -> 0:6 > IRQ7 -> 0:7 > IRQ8 -> 0:8 > IRQ9 -> 0:9 > IRQ10 -> 0:10 > IRQ11 -> 0:11 > IRQ12 -> 0:12 > IRQ13 -> 0:13 > IRQ14 -> 0:14 > IRQ15 -> 0:15 > IRQ16 -> 0:16 > IRQ17 -> 0:17 > IRQ18 -> 0:18 > IRQ19 -> 0:19 > IRQ23 -> 0:23 > IRQ24 -> 1:0 > IRQ58 -> 2:10 > IRQ59 -> 2:11 > .................................... done. > Using local APIC timer interrupts. > calibrating APIC timer ... > ..... CPU clock speed is 2392.2650 MHz. > ..... host bus clock speed is 132.9033 MHz. > cpu: 0, clocks: 1329033, slice: 443011 > CPU0 > cpu: 1, clocks: 1329033, slice: 443011 > CPU1 > checking TSC synchronization across CPUs: passed. > Waiting on wait_init_idle (map = 0x2) > All processors have done init_idle > PCI: PCI BIOS revision 2.10 entry at 0xfdb55, last bus=4 > PCI: Using configuration type 1 > PCI: Probing PCI hardware > PCI: Probing PCI hardware (bus 00) > PCI: Ignoring BAR0-3 of IDE controller 00:1f.1 > PCI: Unable to handle 64-bit address space for > PCI: Unable to handle 64-bit address space for > Transparent bridge - Intel Corp. 82801BA/CA/DB/EB PCI Bridge > PCI: Using IRQ router PIIX/ICH [8086/2480] at 00:1f.0 > PCI->APIC IRQ transform: (B0,I29,P0) -> 16 > PCI->APIC IRQ transform: (B0,I29,P1) -> 19 > PCI->APIC IRQ transform: (B0,I29,P2) -> 18 > PCI->APIC IRQ transform: (B0,I31,P0) -> 17 > PCI->APIC IRQ transform: (B0,I31,P1) -> 17 > PCI->APIC IRQ transform: (B4,I5,P0) -> 58 > PCI->APIC IRQ transform: (B4,I5,P1) -> 59 > PCI->APIC IRQ transform: (B3,I2,P0) -> 24 > PCI->APIC IRQ transform: (B1,I12,P0) -> 23 > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Initializing RT netlink socket > Starting kswapd > VFS: Disk quotas vdquot_6.5.1 > i2c-core.o: i2c core module > pty: 2048 Unix98 ptys configured > Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ > SERIAL_PCI en > abled > ttyS00 at 0x03f8 (irq = 4) is a 16550A > ttyS01 at 0x02f8 (irq = 3) is a 16550A > Real Time Clock Driver v1.10f > Non-volatile memory driver v1.2 > xd: Out of memory. > Floppy drive(s): fd0 is 1.44M > FDC 0 is a National Semiconductor PC87306 > RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize > loop: loaded (max 8 devices) > Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > ICH3: IDE controller at PCI slot 00:1f.1 > PCI: Enabling device 00:1f.1 (0005 -> 0007) > ICH3: chipset revision 2 > ICH3: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0x03a0-0x03a7, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0x03a8-0x03af, BIOS settings: hdc:DMA, hdd:pio > hda: WDC WD400BB-00GFA0, ATA DISK drive > blk: queue c04012e0, I/O limit 4095Mb (mask 0xffffffff) > hdc: SR244W, ATAPI CD/DVD-ROM drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: attached ide-disk driver. > hda: host protected area => 1 > (40021 MB) w/2048KiB Cache, CHS=4865/255/63, UDMA(100) > hdc: attached ide-cdrom driver. > hdc: ATAPI 24X CD-ROM drive, 128kB Cache > Uniform CD-ROM driver Revision: 3.12 > Partition check: > hda: hda1 hda2 hda3 > Initializing Cryptographic API > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 8192 buckets, 64Kbytes > TCP: Hash tables configured (established 262144 bind 65536) > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > RAMDISK: Compressed image found at block 0 > Freeing initrd memory: 162k freed > VFS: Mounted root (ext2 filesystem). > SCSI subsystem driver Revision: 1.00 > 3ware Storage Controller device driver for Linux v1.02.00.037. > scsi0 : Found a 3ware Storage Controller at 0x2000, IRQ: 24, P-chip: 1.3 > scsi0 : 3ware Storage Controller > Vendor: 3ware Model: Logical Disk 0 Rev: 1.0 > Type: Direct-Access ANSI SCSI revision: 00 > Vendor: 3ware Model: Logical Disk 6 Rev: 1.0 > Type: Direct-Access ANSI SCSI revision: 00 > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 > Attached scsi disk sdb at scsi0, channel 0, id 6, lun 0 > SCSI device sda: 2930368512 512-byte hdwr sectors (1500349 MB) > sda: sda1 sda2 sda3 > SCSI device sdb: 2930368512 512-byte hdwr sectors (1500349 MB) > sdb: sdb1 sdb2 sdb3 > md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 > md: raid0 personality registered as nr 2 > reiserfs: found format "3.6" with standard journal > reiserfs: checking transaction log (device ide0(3,3)) ... > for (ide0(3,3)) > reiserfs: replayed 27 transactions in 0 seconds > ide0(3,3):Using r5 hash to sort names > Freeing unused kernel memory: 128k freed > usb.c: registered new driver usbdevfs > usb.c: registered new driver hub > usb-uhci.c: $Revision: 1.275 $ time 20:12:37 Dec 11 2003 > usb-uhci.c: High bandwidth mode enabled > PCI: Setting latency timer of device 00:1d.0 to 64 > usb-uhci.c: USB UHCI at I/O 0x4040, IRQ 16 > usb-uhci.c: Detected 2 ports > usb.c: new USB bus registered, assigned bus number 1 > hub.c: USB hub found > hub.c: 2 ports detected > PCI: Setting latency timer of device 00:1d.1 to 64 > usb-uhci.c: USB UHCI at I/O 0x4020, IRQ 19 > usb-uhci.c: Detected 2 ports > usb.c: new USB bus registered, assigned bus number 2 > hub.c: USB hub found > hub.c: 2 ports detected > PCI: Setting latency timer of device 00:1d.2 to 64 > usb-uhci.c: USB UHCI at I/O 0x4000, IRQ 18 > usb-uhci.c: Detected 2 ports > usb.c: new USB bus registered, assigned bus number 3 > hub.c: USB hub found > hub.c: 2 ports detected > usb-uhci.c: v1.275:USB Universal Host Controller Interface driver > Adding Swap: 2097136k swap-space (priority -1) > Intel(R) PRO/1000 Network Driver - version 5.2.20-k1 > Copyright (c) 1999-2003 Intel Corporation. > eth0: Intel(R) PRO/1000 Network Connection > eth1: Intel(R) PRO/1000 Network Connection > e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex > e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex > md: bind > md: nonpersistent superblock ... > md: bind > md: nonpersistent superblock ... > md: sdb3's event counter: 00000000 > md: sda3's event counter: 00000000 > md0: max total readahead window set to 496k > md0: 2 data-disks, max readahead per data-disk: 248k > raid0: looking at sda3 > raid0: comparing sda3(1464879072) with sda3(1464879072) > raid0: END > raid0: ==> UNIQUE > raid0: 1 zones > raid0: looking at sdb3 > raid0: comparing sdb3(1464879072) with sda3(1464879072) > raid0: EQUAL > raid0: FINAL 1 zones > raid0: zone 0 > raid0: checking sda3 ... contained as device 0 > (1464879072) is smallest!. > raid0: checking sdb3 ... contained as device 1 > raid0: zone->nb_dev: 2, size: -1365209152 > raid0: current zone offset: 1464879072 > raid0: done. > raid0 : md_size is 2929758144 blocks. > raid0 : conf->smallest->size is -1365209152 blocks. > raid0 : nb_zone is 1. > raid0 : Allocating 8 bytes for hash. > SGI-XFS CVS-2003-11-24_06:00_UTC with ACLs, large block numbers, no debug > enable > d > SGI XFS Quota Management subsystem > XFS mounting filesystem md(9,0) > Ending clean XFS mount for filesystem: md(9,0) > > > > I do not if someone can help me trying to debug or/and fix this problems > > > Thank you > Gustavo Rincon > From owner-linux-xfs@oss.sgi.com Tue Dec 16 12:38:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 12:38:34 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGKcMTa012156 for ; Tue, 16 Dec 2003 12:38:22 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBGIk4OO032033 for ; Tue, 16 Dec 2003 10:46:04 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBGKcGSC21238830; Tue, 16 Dec 2003 14:38:17 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBGKc8K110627549; Tue, 16 Dec 2003 14:38:08 -0600 (CST) Subject: RE: LBD patch and XFS problem! From: Eric Sandeen To: Gustavo Rincon Cc: "'linux-xfs@oss.sgi.com'" , Tony Lambert , Ben McMillan , "'Stefan Smietanowski'" In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1071607096.18446.163.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Dec 2003 14:38:16 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1450 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2578 Lines: 75 Looking at the kdb backtrace attached, it looks like you traced pid 7 (kupdated) several times - I assume that you have let the system run a bit, re-entered kdb, and then re-traced pid 7? If so, it looks like it's stuck in kupdated, at xfs_imap_to_bmap... but if you have not left kdb, then you've just retraced the same frozen pid. Can you let me know which it is? If you did not hop in & out of kdb, perhaps you can try that once the system "freezes," to see if the kupdated thread is moving or not. Also, "bta" output from kdb (backtrace all) might be useful (and verbose! private email is ok on that) Thanks, -Eric On Tue, 2003-12-16 at 08:28, Gustavo Rincon wrote: > Hi, I did the HAVE_SECTOR_T definition in all the xfs Makefiles and the test > failed in the same > way that before. Here is some information gotten from kdb (Look into the > attachment) > > > All the help that you can get me it is highly appreciated. > > Thank you > Gustavo Rincon > > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sgi.com] > Sent: Monday, December 15, 2003 5:06 PM > To: Gustavo Rincon > Cc: 'linux-xfs@oss.sgi.com'; Tony Lambert; Ben McMillan > Subject: Re: LBD patch and XFS problem! > > > On Mon, 2003-12-15 at 14:46, Gustavo Rincon wrote: > > Hi, I need some help with XFS and LBD patch. > > Whoohoo, we've just been discussing this... :) > > > I was doing some testing with the linux-2.4.24-pre1+xfs + LBD patch > (gotten > > from ) > > Which LBD patch did you use? There is no 2.4.24-pre1 LBD patch. > > There may already be some problems there, the LBD patch used to make > itself known via HAVE_SECTOR_T, but that's not there anymore. So now > the conditional code in XFS for LBD doesn't work, and xfs has no way to > know that LBD is present. Check your LBD patch for a definition of > HAVE_SECTOR_T.... > > We're probably going to remove all the LBD bits from 2.4 xfs, and push > the changes into Peter's patch, since xfs is now in 2.4.24 - I'll try to > get an updated patch to him soon. > > In the meantime, you can probably fix things up by looking for > #ifdef HAVE_SECTOR_T > conditionals in XFS, and making them always true (either by removing the > tests, or defining it yourself in, say, xfs_linux.h) > > That's just off the top of my head, no promises. > > Until that's fixed, I'm not inclined to dig through all the stacks > posted below. :) > > -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Dec 16 13:44:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 13:45:01 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBGLicTa013655 for ; Tue, 16 Dec 2003 13:44:39 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBGN26m7001237 for ; Tue, 16 Dec 2003 17:02:06 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBGLhXSC21209890; Tue, 16 Dec 2003 15:43:33 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBGLhOK110634005; Tue, 16 Dec 2003 15:43:25 -0600 (CST) Subject: Re: LBD patch and XFS problem! From: Eric Sandeen To: Gustavo Rincon Cc: "'linux-xfs@oss.sgi.com'" , Tony Lambert , Ben McMillan In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1071611012.18446.177.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Dec 2003 15:43:33 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1451 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1496 Lines: 36 On Mon, 2003-12-15 at 14:46, Gustavo Rincon wrote: > I created a filesystem using mkfs.xfs on a 2.7Terabyte md devices (Two 1.5 > Terabytes LUN defined in a 3ware 8000 raid controller) and the output was: > > meta-data=/dev/md0 isize=256 agcount=32, agsize=22888728 > blks > = sectsz=512 > data = bsize=4096 blocks=732439296, imaxpct=25 > = sunit=8 swidth=16 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 I think you may have run into a problem with large AGs (Allocation Groups). Your AGs above are very large, which is a feature recently added to XFS. Can you try re-making the filesystems with 4G AGs? This should happen automatically with xfsprogs < 2.6.0, or you can use the -d agsize=4g option. Either way, you should see about 700 for the "agcount" value, and your (agsize * bsize) should be less than 4G (in bytes) in the mkfs output. Or put another way, agsize should come out to 1048576 in mkfs output (if I got all my math right). If that makes the problem go away, we probably know where to look. Thanks, -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Dec 16 20:49:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Dec 2003 20:49:29 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBH4nHTa024455 for ; Tue, 16 Dec 2003 20:49:18 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBH66im7009891 for ; Wed, 17 Dec 2003 00:06:45 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hBH4lrqH1312289 for ; Wed, 17 Dec 2003 15:47:53 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hBH4lq121311015 for linux-xfs@oss.sgi.com; Wed, 17 Dec 2003 15:47:52 +1100 (EST) Date: Wed, 17 Dec 2003 15:47:52 +1100 (EST) From: Nathan Scott Message-Id: <200312170447.hBH4lq121311015@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfstests X-archive-position: 1452 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 357 Lines: 14 Fix a test which was sensitive to different error output from the current touch(1) command. Date: Tue Dec 16 20:47:14 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:163654a cmd/xfstests/005 - 1.9 From owner-linux-xfs@oss.sgi.com Wed Dec 17 02:31:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 02:32:00 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBHAVbTa003467 for ; Wed, 17 Dec 2003 02:31:38 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBH8dKOO002951 for ; Wed, 17 Dec 2003 00:39:21 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id hBHAVUqH1345954 for ; Wed, 17 Dec 2003 21:31:30 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id hBHAVTvE1349172 for linux-xfs@oss.sgi.com; Wed, 17 Dec 2003 21:31:29 +1100 (EST) Date: Wed, 17 Dec 2003 21:31:29 +1100 (EST) From: Nathan Scott Message-Id: <200312171031.hBHAVTvE1349172@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-archive-position: 1453 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 740 Lines: 25 Fix dev_t mangling in xfsprogs tools, use xfs_dev_t as its size is what we expect. Patch from Christoph. Date: Wed Dec 17 02:30:22 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:163659a cmd/xfsprogs/VERSION - 1.95 cmd/xfsprogs/doc/CHANGES - 1.132 cmd/xfsprogs/man/man8/xfs_db.8 - 1.7 cmd/xfsprogs/mkfs/proto.c - 1.14 cmd/xfsprogs/include/libxfs.h - 1.31 cmd/xfsprogs/include/platform_defs.h.in - 1.27 cmd/xfsprogs/debian/changelog - 1.86 cmd/xfsprogs/repair/phase6.c - 1.17 cmd/xfsprogs/repair/dinode.c - 1.18 cmd/xfsprogs/libxfs/xfs.h - 1.39 cmd/xfsprogs/libxfs/util.c - 1.13 From owner-linux-xfs@oss.sgi.com Wed Dec 17 03:13:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 03:13:40 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHBDATa006052 for ; Wed, 17 Dec 2003 03:13:10 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHBDAkh006041 for linux-xfs@oss.sgi.com; Wed, 17 Dec 2003 03:13:10 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHBD5To005954 for ; Wed, 17 Dec 2003 03:13:07 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHB10Mp005747; Wed, 17 Dec 2003 03:01:00 -0800 Date: Wed, 17 Dec 2003 03:01:00 -0800 Message-Id: <200312171101.hBHB10Mp005747@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 268] linux 2.6.0-test1-mm1 with RAID 0 XFS internal error during delete X-Bugzilla-Reason: AssignedTo X-archive-position: 1454 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 377 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=268 ------- Additional Comments From hch@xfs.org 2003-17-12 03:01 PDT ------- This should have been fixed in the raid code somewhere in the 2.6.0-test* series. Could you try to reproduce with 2.6.0-test11? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 17 03:13:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 03:13:40 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHBDATa006055 for ; Wed, 17 Dec 2003 03:13:10 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHBDAFH006047 for linux-xfs@oss.sgi.com; Wed, 17 Dec 2003 03:13:10 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHBD5Tw005954 for ; Wed, 17 Dec 2003 03:13:08 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHAxt4L005726; Wed, 17 Dec 2003 02:59:55 -0800 Date: Wed, 17 Dec 2003 02:59:55 -0800 Message-Id: <200312171059.hBHAxt4L005726@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 251] FIOQSIZE not defined for x86-64 X-Bugzilla-Reason: AssignedTo X-archive-position: 1 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 554 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=251 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From hch@xfs.org 2003-17-12 02:59 PDT ------- This is fixed since at least 2.4.23. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 17 03:13:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 03:13:40 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHBDATa006054 for ; Wed, 17 Dec 2003 03:13:10 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHBDAPw006048 for linux-xfs@oss.sgi.com; Wed, 17 Dec 2003 03:13:10 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHBD5Ts005954 for ; Wed, 17 Dec 2003 03:13:08 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHAvhQY005705; Wed, 17 Dec 2003 02:57:43 -0800 Date: Wed, 17 Dec 2003 02:57:43 -0800 Message-Id: <200312171057.hBHAvhQY005705@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 288] XFS NULL pointer dereference at virtual address 0000005c X-Bugzilla-Reason: AssignedTo X-archive-position: 1454 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 445 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=288 ------- Additional Comments From hch@xfs.org 2003-17-12 02:57 PDT ------- XFS currently assumes the buf_get/buf_read may not return NULL because they don't on IRIX. On Linux on the other hand they may return NULL when kmem_cache_alloc fails. I'm working on a fix now. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 17 03:13:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 03:13:40 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHBD9Ta006037 for ; Wed, 17 Dec 2003 03:13:09 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHBD9Wn006036 for linux-xfs@oss.sgi.com; Wed, 17 Dec 2003 03:13:09 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHBD5Tk005954 for ; Wed, 17 Dec 2003 03:13:06 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHAtL92005687; Wed, 17 Dec 2003 02:55:21 -0800 Date: Wed, 17 Dec 2003 02:55:21 -0800 Message-Id: <200312171055.hBHAtL92005687@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 287] xfs kernel error: xfs_da_btree.c 2TB FS under load. X-Bugzilla-Reason: AssignedTo X-archive-position: 1 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 365 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=287 ------- Additional Comments From hch@xfs.org 2003-17-12 02:55 PDT ------- Are you using the large block device patch? Without it 2TB devices can't be used reliably with a linux 2.4 kernel. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 17 03:13:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 03:13:40 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHBD9Ta006031 for ; Wed, 17 Dec 2003 03:13:09 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHBD9lY006030 for linux-xfs@oss.sgi.com; Wed, 17 Dec 2003 03:13:09 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHBD5Tc005954 for ; Wed, 17 Dec 2003 03:13:05 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHAowZp005665; Wed, 17 Dec 2003 02:50:58 -0800 Date: Wed, 17 Dec 2003 02:50:58 -0800 Message-Id: <200312171050.hBHAowZp005665@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 286] Kernel BUG at buffer.c:568 X-Bugzilla-Reason: AssignedTo X-archive-position: 1455 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 365 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=286 ------- Additional Comments From hch@xfs.org 2003-17-12 02:50 PDT ------- This is a typical sign of memory corruption. Did you run memtest86 on your machine to ensure it's not fauly DIMMs? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 17 03:13:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 03:13:40 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHBD9Ta006032 for ; Wed, 17 Dec 2003 03:13:09 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHBD9cJ006029 for linux-xfs@oss.sgi.com; Wed, 17 Dec 2003 03:13:09 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHBD5Ti005954 for ; Wed, 17 Dec 2003 03:13:06 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHBBcpC005911; Wed, 17 Dec 2003 03:11:38 -0800 Date: Wed, 17 Dec 2003 03:11:38 -0800 Message-Id: <200312171111.hBHBBcpC005911@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 275] Consistant oops on dual athlon boards X-Bugzilla-Reason: AssignedTo X-archive-position: 1454 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 377 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=275 ------- Additional Comments From hch@xfs.org 2003-17-12 03:11 PDT ------- Well, this OOPS isn't in XFS code at all. And it looks pretty much like faulty DIMMs. Could you try to run memtest86 over it? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 17 04:13:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 04:13:35 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHCD8Ta009477 for ; Wed, 17 Dec 2003 04:13:08 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHCD8va009476 for linux-xfs@oss.sgi.com; Wed, 17 Dec 2003 04:13:08 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHCD5Tc009462 for ; Wed, 17 Dec 2003 04:13:05 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHBw4Wr008891; Wed, 17 Dec 2003 03:58:04 -0800 Date: Wed, 17 Dec 2003 03:58:04 -0800 Message-Id: <200312171158.hBHBw4Wr008891@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 286] Kernel BUG at buffer.c:568 X-Bugzilla-Reason: AssignedTo X-archive-position: 1455 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 291 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=286 ------- Additional Comments From john@geeknetau.net 2003-17-12 03:58 PDT ------- Yes I did, and the memory is fine. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 17 07:21:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 07:21:29 -0800 (PST) Received: from tempgw.ciprico.com (hqntws.ciprico.com [208.252.143.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBHFL5Ta023421 for ; Wed, 17 Dec 2003 07:21:05 -0800 Received: from Unknown [172.20.0.8] by tempgw.ciprico.com - SurfControl E-mail Filter (4.7); Wed, 17 Dec 2003 09:22:06 -0600 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 09:20:29 -0600 Message-ID: From: Gustavo Rincon To: "'Eric Sandeen'" , Gustavo Rincon Cc: "'linux-xfs@oss.sgi.com'" , Tony Lambert , Ben McMillan Date: Wed, 17 Dec 2003 09:20:28 -0600 Subject: RE: LBD patch and XFS problem! MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 1456 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: grincon@ciprico.com Precedence: bulk X-list: linux-xfs Content-Length: 1964 Lines: 54 Hi Eric, I re-made the filesystem using -d 4g and it ran the whole night without any failure, Today I will do more testing and I'll let you know by the end of the day if everything is OKAY. Thank very much for you help Gustavo Rincon -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Tuesday, December 16, 2003 4:44 PM To: Gustavo Rincon Cc: 'linux-xfs@oss.sgi.com'; Tony Lambert; Ben McMillan Subject: Re: LBD patch and XFS problem! On Mon, 2003-12-15 at 14:46, Gustavo Rincon wrote: > I created a filesystem using mkfs.xfs on a 2.7Terabyte md devices (Two 1.5 > Terabytes LUN defined in a 3ware 8000 raid controller) and the output was: > > meta-data=/dev/md0 isize=256 agcount=32, agsize=22888728 > blks > = sectsz=512 > data = bsize=4096 blocks=732439296, imaxpct=25 > = sunit=8 swidth=16 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 I think you may have run into a problem with large AGs (Allocation Groups). Your AGs above are very large, which is a feature recently added to XFS. Can you try re-making the filesystems with 4G AGs? This should happen automatically with xfsprogs < 2.6.0, or you can use the -d agsize=4g option. Either way, you should see about 700 for the "agcount" value, and your (agsize * bsize) should be less than 4G (in bytes) in the mkfs output. Or put another way, agsize should come out to 1048576 in mkfs output (if I got all my math right). If that makes the problem go away, we probably know where to look. Thanks, -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Dec 17 07:47:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 07:47:46 -0800 (PST) Received: from uwast.astro.wisc.edu (uwast.astro.wisc.edu [144.92.179.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBHFlYTa024068 for ; Wed, 17 Dec 2003 07:47:35 -0800 Received: from astro.wisc.edu (premo.astro.wisc.edu [144.92.179.236]) (authenticated bits=0) by uwast.astro.wisc.edu (8.12.8/8.12.8) with ESMTP id hBHFlSq6029274; Wed, 17 Dec 2003 09:47:28 -0600 Message-ID: <3FE07A90.9030900@astro.wisc.edu> Date: Wed, 17 Dec 2003 09:47:28 -0600 From: jansen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Straz CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump problems References: <3FDDCDAC.8030807@astro.wisc.edu> <20031215182519.GE3766@sgi.com> In-Reply-To: <20031215182519.GE3766@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1457 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jansen@astro.wisc.edu Precedence: bulk X-list: linux-xfs Content-Length: 2004 Lines: 53 Hi, I ran the XFS QA stuff from CVS on kernel-smp-2.4.22-1.2129.nptl.xfs. (which is derived from the kernel-2.4.22-1.2115.nptl.xfs in the testing/FC1 directory on oss.sgi.com). I ran the tests on a different machine from the one I originally had problems on since I don't have any spare partitions to try this on. It passed 013 but failed on 018, 019, 064, 073 and 076. Some of these failures seem to be just minor differences in output. 073 and 076, however, hung. Let me know if you'd like to look at the *.bad files. I tried building a kernel from yesterday's linux-2.4 CVS and the QA tests failed on the 018, 019, 064 and 073 but none hung. One key bit of information I see I have not mentioned is this is on RHEL3 ES using the default gcc 3.2.3. I noticed someone reporting a problem with XFS and LVM when using gcc 3.2.3. THe original problem also happened under RedHat 8.0 with the kernel compiled with the default gcc 3.2 so this may have nothing to do with the orignal problem. I'd appreciate any suggestions on what to try next. Would you suggest running the linux-24-xfs from CVS on a "production" machine with 5.6 TB of disk on it? Nathan Straz wrote: > On Mon, Dec 15, 2003 at 09:05:16AM -0600, jansen wrote: > >>I did an "strace" on xfsdump and these ioctl commands are the ones that >>appear to make the high load average: >> >>14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 >>14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 >>14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 >>14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 >>14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 >>14054 ioctl(4, 0xc0105865, 0xbffff530) = 0 > > > Looks like it's stuck in a loop doing XFS_IOC_FSBULKSTAT. I think I'm > hitting something similar. In my case I'm running on ia64 and the > system becomes totally unresponsive. Luckily I have KDB. :) > > Can you run some of the XFS QA suite from CVS? 013 in particular has > been exposing this to me. Run it on a scratch partition. -- ------- Stephan From owner-linux-xfs@oss.sgi.com Wed Dec 17 08:13:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 08:13:26 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHGD7Ta024734 for ; Wed, 17 Dec 2003 08:13:07 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHGD7gC024733 for linux-xfs@oss.sgi.com; Wed, 17 Dec 2003 08:13:07 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBHGD6Tc024718 for ; Wed, 17 Dec 2003 08:13:06 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBHFVD9C023888; Wed, 17 Dec 2003 07:31:13 -0800 Date: Wed, 17 Dec 2003 07:31:13 -0800 Message-Id: <200312171531.hBHFVD9C023888@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 297] New: snapshot-2.4.23-2003-12-01_00:33_UTC quota options problem X-Bugzilla-Reason: AssignedTo X-archive-position: 1458 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1018 Lines: 31 http://oss.sgi.com/bugzilla/show_bug.cgi?id=297 Summary: snapshot-2.4.23-2003-12-01_00:33_UTC quota options problem Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: ruda@ics.muni.cz 2.4.23 patched with snapshot-2.4.23-2003-12-01_00:33_UTC doesn't support quota mount parameters. xfs_qm_parseargs() from fs/xfs/quota/xfs_qm_bhv.c supports quota/usrquota options, but than it calls PVFS_PARSEARGS -> xfs_parseargs() from fs/xfs/xfs_vfsops.c which doesn't support any quota option! After copying code from xfs_qm_parseargs() to xfs_parseargs() mount with quota options works, but is it safe to use quotas with this snapshot? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 17 08:29:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 08:29:35 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBHGTCTa028082 for ; Wed, 17 Dec 2003 08:29:14 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBHHkgm7005432 for ; Wed, 17 Dec 2003 11:46:42 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBHGT6SC21556384; Wed, 17 Dec 2003 10:29:06 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBHGSwK110649882; Wed, 17 Dec 2003 10:28:58 -0600 (CST) Subject: RE: LBD patch and XFS problem! From: Eric Sandeen To: Gustavo Rincon Cc: "'linux-xfs@oss.sgi.com'" , Tony Lambert , Ben McMillan In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1071678546.22241.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 17 Dec 2003 10:29:06 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1459 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 762 Lines: 25 Sounds great. I'll work on making the large AGs work again soon. One thing - you mentioned that without LBD you did not see failures, but I did not expect that to affect this problem. Just to be certain, when you were testing without LBD, how big was your filesystem, and what version of xfsprogs were you using? Thanks, -Eric On Wed, 2003-12-17 at 09:20, Gustavo Rincon wrote: > Hi Eric, I re-made the filesystem using -d 4g and it ran the whole night > without > any failure, Today I will do more testing and I'll let you know by the end > of > the day if everything is OKAY. > > Thank very much for you help > Gustavo Rincon -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Dec 17 09:14:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 09:14:48 -0800 (PST) Received: from spock.physics.mcgill.ca (spock.physics.mcgill.ca [132.206.92.180]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBHHEQTa029443 for ; Wed, 17 Dec 2003 09:14:27 -0800 Received: from ransom by spock.physics.mcgill.ca with local (Exim 3.36 #1 (Debian)) id 1AWfFi-0000TF-00; Wed, 17 Dec 2003 12:14:26 -0500 From: Scott Ransom Organization: McGill University Physics Dept. To: linux-xfs@oss.sgi.com Subject: mount: Unknown error 990 Date: Wed, 17 Dec 2003 12:14:25 -0500 User-Agent: KMail/1.5.4 Cc: Scott Ransom MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312171214.25982.ransom@physics.mcgill.ca> X-archive-position: 1460 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ransom@physics.mcgill.ca Precedence: bulk X-list: linux-xfs Content-Length: 938 Lines: 28 Hello, I've been happily running XFS (in kernel 2.6.0-test11) using a 32bit kernel on an Opteron system with a 1.7 TB RAID array on a 3ware card. For unrelated issues, I have recently tried moving to a 64bit kernel (same version, self compiled). Everything on the system seems to work fine except that now when I try to mount the XFS filesystem, I get: mount: Unknown error 990 I'm using the most recent mount and Debian unstable (so everything is up-to-date). I was able to run xfs_check and xfs_repair on the file system withour problems. The only issue comes when I try and mount it. Any ideas? Scott PS: I'm using a 32 bit verion of mount. -- Scott M. Ransom Address: McGill Univ. Physics Dept. Phone: (514) 398-6492 3600 University St., Rm 338 email: ransom@physics.mcgill.ca Montreal, QC Canada H3A 2T8 GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 From owner-linux-xfs@oss.sgi.com Wed Dec 17 13:46:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 13:46:34 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBHLkDTa008575 for ; Wed, 17 Dec 2003 13:46:13 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBHJrvOO004036 for ; Wed, 17 Dec 2003 11:53:58 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBHLk6SC21663938; Wed, 17 Dec 2003 15:46:06 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBHLjwK110725676; Wed, 17 Dec 2003 15:45:58 -0600 (CST) Subject: Re: mount: Unknown error 990 From: Eric Sandeen To: Scott Ransom Cc: linux-xfs@oss.sgi.com In-Reply-To: <200312171214.25982.ransom@physics.mcgill.ca> References: <200312171214.25982.ransom@physics.mcgill.ca> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1071697565.22241.40.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 17 Dec 2003 15:46:06 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1461 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 289 Lines: 13 On Wed, 2003-12-17 at 11:14, Scott Ransom wrote: > mount: Unknown error 990 Start by looking at dmesg or system logs, see if the kernel told you any more. -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Dec 17 13:51:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 13:51:21 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBHLp9Ta008984 for ; Wed, 17 Dec 2003 13:51:10 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBHJwsOO004765 for ; Wed, 17 Dec 2003 11:58:54 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBHLopSC21552512; Wed, 17 Dec 2003 15:50:52 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AWjZD-0001Od-00; Wed, 17 Dec 2003 15:50:51 -0600 Date: Wed, 17 Dec 2003 15:50:51 -0600 From: Nathan Straz To: Scott Ransom Cc: linux-xfs@oss.sgi.com Subject: Re: mount: Unknown error 990 Message-ID: <20031217215051.GA5326@sgi.com> Mail-Followup-To: Scott Ransom , linux-xfs@oss.sgi.com References: <200312171214.25982.ransom@physics.mcgill.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312171214.25982.ransom@physics.mcgill.ca> User-Agent: Mutt/1.5.3i X-archive-position: 1462 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 335 Lines: 10 On Wed, Dec 17, 2003 at 12:14:25PM -0500, Scott Ransom wrote: > mount: Unknown error 990 Check dmesg for errors. -- 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 Wed Dec 17 15:14:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 15:14:21 -0800 (PST) Received: from spock.physics.mcgill.ca (spock.physics.mcgill.ca [132.206.92.180]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBHNE0Ta010105 for ; Wed, 17 Dec 2003 15:14:00 -0800 Received: from ransom by spock.physics.mcgill.ca with local (Exim 3.36 #1 (Debian)) id 1AWkrb-0000st-00; Wed, 17 Dec 2003 18:13:55 -0500 From: Scott Ransom Organization: McGill University Physics Dept. To: Nathan Straz , Eric Sandeen Subject: Re: mount: Unknown error 990 Date: Wed, 17 Dec 2003 18:13:55 -0500 User-Agent: KMail/1.5.4 Cc: linux-xfs@oss.sgi.com References: <200312171214.25982.ransom@physics.mcgill.ca> <20031217215051.GA5326@sgi.com> In-Reply-To: <20031217215051.GA5326@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312171813.55480.ransom@physics.mcgill.ca> X-archive-position: 1463 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ransom@physics.mcgill.ca Precedence: bulk X-list: linux-xfs Content-Length: 549 Lines: 19 On 17 December 2003 04:50 pm, Nathan Straz wrote: > On Wed, Dec 17, 2003 at 12:14:25PM -0500, Scott Ransom wrote: > > mount: Unknown error 990 > > Check dmesg for errors. Ah. Forgot to add this. Sorry: XFS mounting filesystem sda1 XFS: failed to read root inode Scott -- Scott M. Ransom Address: McGill Univ. Physics Dept. Phone: (514) 398-6492 3600 University St., Rm 338 email: ransom@physics.mcgill.ca Montreal, QC Canada H3A 2T8 GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 From owner-linux-xfs@oss.sgi.com Wed Dec 17 22:30:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Dec 2003 22:30:16 -0800 (PST) Received: from miami.chance (miami.amiindia.co.in [203.129.222.186]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBI6TsTa023280 for ; Wed, 17 Dec 2003 22:30:00 -0800 Received: from LINSENEW ([10.0.0.161]) by miami.chance with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id YYCZ50JB; Thu, 18 Dec 2003 11:10:37 +0530 Message-ID: <00e001c3c528$f6ef56b0$a100000a@linseNew> From: "Linse A Pallan" To: Subject: ACL group permissions not getting updated properly. Date: Thu, 18 Dec 2003 11:07:02 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1464 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linsea@amiindia.co.in Precedence: bulk X-list: linux-xfs Content-Length: 1053 Lines: 17 Hi, ACL group permissions not getting updated properly. I am working on a Linux machine with XFS support, in which i am using the kernel made out of kernel-2.4.18-18SGI_XFS_1.2.0.src.rpm. There are two groups, group1 and group2, user1 is a member of group1. Initially group1 one having full access to CIFS share share1 and group2 having no access(deny permission) to share1. At a particular time user1 is accessing his share from one of windows client and doing some read-write operations, same time administrator is moving user1 from group1 to group2 which doesn't having any access to share1. But still user1 can access share1 and do the read-write operations. The changes will come into effect only if he's logout and login again. Is there any way to get the effect of the access changes made by administrator , in this case moving user1 from group1 with full permission to share1 to group2 which is having no access to share1, immediately without logout. Thanking you in advance, Regards, Linse A Pallan [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Dec 18 07:29:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Dec 2003 07:29:40 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBIFTSTa015595 for ; Thu, 18 Dec 2003 07:29:28 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBIGl1m7008603 for ; Thu, 18 Dec 2003 10:47:01 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBIFQdSC21954529; Thu, 18 Dec 2003 09:26:39 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBIFQUK210757295; Thu, 18 Dec 2003 09:26:31 -0600 (CST) Date: Thu, 18 Dec 2003 09:26:38 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Linse A Pallan cc: linux-xfs@oss.sgi.com Subject: Re: ACL group permissions not getting updated properly. In-Reply-To: <00e001c3c528$f6ef56b0$a100000a@linseNew> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1465 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1639 Lines: 34 This looks like a somewhat complex situation, and you're also using a pretty old kernel / xfs version. If you can try a recent kernel (at least XFS 1.3.1) then we can be sure we're not chasing an old bug. It would also be instructive to take samba/windows out of the mix, perhaps trying a Linux samba client first, and maybe experimenting with local users, taking samba out of the picture. That way you can narrow down the problem a bit. (Is it old xfs? samba? windows? old kernel?) Thanks, -Eric On Thu, 18 Dec 2003, Linse A Pallan wrote: > Hi, > > ACL group permissions not getting updated properly. > > I am working on a Linux machine with XFS support, in which i am using the kernel made out of kernel-2.4.18-18SGI_XFS_1.2.0.src.rpm. > > There are two groups, group1 and group2, user1 is a member of group1. Initially group1 one having full access to CIFS share share1 and group2 having no access(deny permission) to share1. At a particular time user1 is accessing his share from one of windows client and doing some read-write operations, same time administrator is moving user1 from group1 to group2 which doesn't having any access to share1. But still user1 can access share1 and do the read-write operations. The changes will come into effect only if he's logout and login again. > > Is there any way to get the effect of the access changes made by administrator , in this case moving user1 from group1 with full permission to share1 to group2 which is having no access to share1, immediately without logout. > > Thanking you in advance, > > Regards, > Linse A Pallan > > [[HTML alternate version deleted]] > > From owner-linux-xfs@oss.sgi.com Thu Dec 18 07:41:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Dec 2003 07:41:29 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBIFfHTa016467 for ; Thu, 18 Dec 2003 07:41:18 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBIGwom7016007 for ; Thu, 18 Dec 2003 10:58:50 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBIFbRSC21955344; Thu, 18 Dec 2003 09:37:28 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBIFbCK210716550; Thu, 18 Dec 2003 09:37:12 -0600 (CST) Date: Thu, 18 Dec 2003 09:37:20 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Scott Ransom cc: Nathan Straz , Subject: Re: mount: Unknown error 990 In-Reply-To: <200312171813.55480.ransom@physics.mcgill.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1466 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1406 Lines: 49 Unfortunately that message doesn't give us much to go on... You might try xfs_repair (possibly with -n to not actually -do- anything) to see if it gives any info about problems on the filesystem. Otherwise, find this code in xfs_mount.c: /* * Get and sanity-check the root inode. * Save the pointer to it in the mount structure. */ error = xfs_iget(mp, NULL, sbp->sb_rootino, XFS_ILOCK_EXCL, &rip, 0); if (error) { cmn_err(CE_WARN, "XFS: failed to read root inode"); goto error3; } and change the cmn_err line to say: cmn_err(CE_WARN, "XFS: failed to read root inode (%d)", error); so we can at least see what error was returned from xfs_iget - that might be a hint. -Eric On Wed, 17 Dec 2003, Scott Ransom wrote: > On 17 December 2003 04:50 pm, Nathan Straz wrote: > > On Wed, Dec 17, 2003 at 12:14:25PM -0500, Scott Ransom wrote: > > > mount: Unknown error 990 > > > > Check dmesg for errors. > > Ah. Forgot to add this. Sorry: > > XFS mounting filesystem sda1 > XFS: failed to read root inode > > Scott > > -- > Scott M. Ransom Address: McGill Univ. Physics Dept. > Phone: (514) 398-6492 3600 University St., Rm 338 > email: ransom@physics.mcgill.ca Montreal, QC Canada H3A 2T8 > GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 > > From owner-linux-xfs@oss.sgi.com Thu Dec 18 08:13:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Dec 2003 08:13:37 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBIGDFTa017408 for ; Thu, 18 Dec 2003 08:13:15 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBIGDFVK017407 for linux-xfs@oss.sgi.com; Thu, 18 Dec 2003 08:13:15 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBIGDBTc017392 for ; Thu, 18 Dec 2003 08:13:11 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBIG5cYB017298; Thu, 18 Dec 2003 08:05:39 -0800 Date: Thu, 18 Dec 2003 08:05:39 -0800 Message-Id: <200312181605.hBIG5cYB017298@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 298] New: xfsdump doesn't work on sparc64 linux X-Bugzilla-Reason: AssignedTo X-archive-position: 1467 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1951 Lines: 54 http://oss.sgi.com/bugzilla/show_bug.cgi?id=298 Summary: xfsdump doesn't work on sparc64 linux Product: Linux XFS Version: 1.3.x Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: xfsdump AssignedTo: xfs-master@oss.sgi.com ReportedBy: androsyn@ratbox.org xfsdump currently fails to work on sparc64 linux. I'm using the following: 1.3.1 XFS Linux 2.4.23. xfsdump 2.4.14 xfsprogs 2.6.0 I think the issue may be that the ioctls aren't translated for 32bit binaries running on sparc64. /sbin/xfsdump: using file dump (drive_simple) strategy /sbin/xfsdump: version 2.2.14 (dump format 3.0) - Running single-threaded /sbin/xfsdump: unable to determine uuid of fs mounted at /var/lib/postgres: Invalid argument /sbin/xfsdump: level 0 dump of squeaker.ratbox.org:/var/lib/postgres /sbin/xfsdump: dump date: Thu Dec 18 11:04:41 2003 /sbin/xfsdump: session id: cc5a31b3-e115-451f-9679-85c0a6e792b9 /sbin/xfsdump: session label: "" /sbin/xfsdump: unable to construct a file system handle for /var/lib/postgres: Invalid argument /sbin/xfsdump: Dump Status: ERROR lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var/lib/postgres", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 open("/var/lib/postgres", O_RDONLY|O_LARGEFILE) = 5 ioctl(5, 0xc01c5868, 0xe28be7e0) = -1 EINVAL (Invalid argument) getpid() = 2902 write(2, "/sbin/xfsdump: ", 15/sbin/xfsdump: ) = 15 write(2, "unable to construct a file system handle for /var/lib/postgres: Invalid argument\n", 81unable to construct a file system handle for /var/lib/postgres: Invalid argument ) = 81 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Dec 18 08:30:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Dec 2003 08:30:30 -0800 (PST) Received: from mail41.messagelabs.com (mail41.messagelabs.com [64.125.76.51]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBIGUITa020729 for ; Thu, 18 Dec 2003 08:30:19 -0800 X-VirusChecked: Checked X-Env-Sender: bvenegas@securities.com X-Msg-Ref: server-15.tower-41.messagelabs.com!1071765011!2466513 X-StarScan-Version: 5.1.15; banners=-,-,- Received: (qmail 29155 invoked from network); 18 Dec 2003 16:30:11 -0000 Received: from unknown (HELO mail02.securities.com) (63.87.240.232) by server-15.tower-41.messagelabs.com with SMTP; 18 Dec 2003 16:30:11 -0000 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-DELIVERY) with ESMTP id hBIGUB0H018572 for ; Thu, 18 Dec 2003 11:30:11 -0500 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5) with ESMTP id hBIGUBGK018564 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 18 Dec 2003 11:30:11 -0500 Received: from localhost (venevene@localhost) by mail02.securities.com (8.12.5/8.12.5/Submit) with ESMTP id hBIGUBSl018554 for ; Thu, 18 Dec 2003 11:30:11 -0500 X-Authentication-Warning: mail02.securities.com: venevene owned process doing -bs Date: Thu, 18 Dec 2003 11:30:11 -0500 (EST) From: "Benito A. Venegas" X-X-Sender: venevene@mail02.securities.com To: linux-xfs@oss.sgi.com Subject: xfs_growfs & Raid by HW Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1468 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bvenegas@securities.com Precedence: bulk X-list: linux-xfs Content-Length: 233 Lines: 14 Good morning people: Is it possible to use xfs_growfs with RAID by HW? We'll have new toy soon (EMC Clarion CX600 series) and I don't have the experience with this box and this xfs tool. Any hint will very helpful. Thanks, From owner-linux-xfs@oss.sgi.com Thu Dec 18 09:08:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Dec 2003 09:09:07 -0800 (PST) Received: from priv-edtnes57.telusplanet.net (defout.telus.net [199.185.220.240]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBIH8iTa021821 for ; Thu, 18 Dec 2003 09:08:44 -0800 Received: from [161.184.244.187] by priv-edtnes57.telusplanet.net (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with ESMTP id <20031218170838.GPWN4004.priv-edtnes57.telusplanet.net@[161.184.244.187]> for ; Thu, 18 Dec 2003 10:08:38 -0700 Subject: [Fwd: Re: Kernel 2.6.0 and SGI's XFS] From: Aly Dharshi Reply-To: aly.dharshi@telus.net To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1071767318.1952.17.camel@edtnas67.telus.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 18 Dec 2003 10:08:38 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 1469 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aly.dharshi@telus.net Precedence: bulk X-list: linux-xfs Content-Length: 1117 Lines: 41 Just FYI that Fedora has this in their 2.6 Kernel now ... Aly. -----Forwarded Message----- From: Dave Jones To: fedora-list@redhat.com Subject: Re: Kernel 2.6.0 and SGI's XFS Date: Thu, 18 Dec 2003 16:56:14 +0000 On Thu, 2003-12-18 at 16:34, Aly Dharshi wrote: > Hi Folks, > > I hope that you are well. Just curious if with this of 2.6 whether the > Fedora team is planning to compile in XFS as another alternative FS to > EXT3,JFS and ReiserFS. Already there for a week or so now.. (16:55:44:davej@delerium:Fedora2)$ grep CONFIG_XFS_FS config* config-generic:CONFIG_XFS_FS=m (16:55:46:davej@delerium:Fedora2)$ Dave -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list -- Aly Dharshi Systems Analyst Content Applications Group TELUS Technology & Operations "A good speech is like a good dress that's short enough to be interesting and long enough to cover the subject" From owner-linux-xfs@oss.sgi.com Thu Dec 18 11:13:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Dec 2003 11:13:25 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBIJDDTa024116 for ; Thu, 18 Dec 2003 11:13:13 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBIJDDdq024115 for linux-xfs@oss.sgi.com; Thu, 18 Dec 2003 11:13:13 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBIJDCTc024099 for ; Thu, 18 Dec 2003 11:13:12 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBIIiFFY023735; Thu, 18 Dec 2003 10:44:15 -0800 Date: Thu, 18 Dec 2003 10:44:15 -0800 Message-Id: <200312181844.hBIIiFFY023735@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 296] Kernel 2.4.22 xfs_force_shutdown line 4049 of file xfs_bmap.c X-Bugzilla-Reason: AssignedTo X-archive-position: 1470 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 453 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=296 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |critical Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Dec 18 13:03:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Dec 2003 13:03:31 -0800 (PST) Received: from mail.nucleus.com (mail.nucleus.com [207.34.93.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBIL3JTb028716 for ; Thu, 18 Dec 2003 13:03:20 -0800 Received: from frank (unverified [208.38.4.203]) by mail.nucleus.com (Vircom SMTPRS 3.0.277) with SMTP id for ; Thu, 18 Dec 2003 14:03:08 -0700 From: "Jeremy Jin @ Nucleus" To: Subject: How to install XFS release 1.3.1 Date: Thu, 18 Dec 2003 14:03:28 -0700 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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-archive-position: 1471 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeremyjin@nucleus.com Precedence: bulk X-list: linux-xfs Content-Length: 1172 Lines: 36 Hello, I went through oss.sgi.com, but only found how to download the CVS development tree and build a new kernel, not found a detailed instruction to patch my kernel with XFS Release 1.3.1. I want a stable release, not the development tree. My problem is, After I downloaded the two patches in ftp://oss.sgi.com/projects/xfs/Release-1.3.1/kernel_patches/ and run "patch -p0 < linux-2.4.21-core-xfs-1.3.1.patch" and "patch -p0 < linux-xfs-1.3.1.patch" I got some errors said Reversed (or previously applied) patched found, Assume -R (n)? Applied anyway (n)? After what ever i choose, yes or no, then I do "make mrproper; make menuconfig", I didn't see any configuration option about XFS in the file system category. I believe I did something wrong. But I could find any instructions about how to apply this patches, anyone can give me a hand? I am using RedHat Enterprise Linux ES version 3 which kernel is 2.4.21. Before I did anything with the kernel source, there IS already a xfs.txt file under Documentation directory. in the /boot/config* file, there is a line shown as "CONFIG_XFS_FS is not set". But it doesn't have any XFS source code. Thanks. Jeremy From owner-linux-xfs@oss.sgi.com Thu Dec 18 15:38:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Dec 2003 15:39:18 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBINcrTa031000 for ; Thu, 18 Dec 2003 15:38:54 -0800 Received: by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id hBINckdl000947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Dec 2003 00:38:51 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id hBINcaju003697; Fri, 19 Dec 2003 00:38:36 +0100 Date: Fri, 19 Dec 2003 00:38:35 +0100 From: Axel Thimm To: Aly Dharshi Cc: linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: Kernel 2.6.0 and SGI's XFS] Message-ID: <20031218233835.GC2081@neu.nirvana> References: <1071767318.1952.17.camel@edtnas67.telus.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V88s5gaDVPzZ0KCq" Content-Disposition: inline In-Reply-To: <1071767318.1952.17.camel@edtnas67.telus.net> User-Agent: Mutt/1.4.1i X-archive-position: 1472 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1395 Lines: 53 --V88s5gaDVPzZ0KCq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 18, 2003 at 10:08:38AM -0700, Aly Dharshi wrote: > Just FYI that Fedora has this in their 2.6 Kernel now ... Amen! Let's hope FC's installer get's XFS ready until the first FC2 test releases at the end of January. Current anaconda is said to already have XFS support and only needs enabling. :) > From: Dave Jones > To: fedora-list@redhat.com > Subject: Re: Kernel 2.6.0 and SGI's XFS > Date: Thu, 18 Dec 2003 16:56:14 +0000 >=20 > On Thu, 2003-12-18 at 16:34, Aly Dharshi wrote: > > Hi Folks, > >=20 > > I hope that you are well. Just curious if with this of 2.6 whether the > > Fedora team is planning to compile in XFS as another alternative FS to > > EXT3,JFS and ReiserFS. >=20 > Already there for a week or so now.. >=20 > (16:55:44:davej@delerium:Fedora2)$ grep CONFIG_XFS_FS config* > config-generic:CONFIG_XFS_FS=3Dm > (16:55:46:davej@delerium:Fedora2)$ >=20 > Dave >=20 >=20 --=20 Axel.Thimm@physik.fu-berlin.de --V88s5gaDVPzZ0KCq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/4jp7QBVS1GOamfERAuZtAJ9fJGNe8OYyYArsVGchJ0drldrs2QCbB66g CaL+Rya8dEFpVYJZzHJaRzM= =kndB -----END PGP SIGNATURE----- --V88s5gaDVPzZ0KCq-- From owner-linux-xfs@oss.sgi.com Thu Dec 18 18:28:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Dec 2003 18:28:50 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBJ2SSTa004438 for ; Thu, 18 Dec 2003 18:28:28 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBJ3k3m7020424 for ; Thu, 18 Dec 2003 21:46:03 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBJ2RMSC22211190; Thu, 18 Dec 2003 20:27:22 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBJ2REK210856968; Thu, 18 Dec 2003 20:27:14 -0600 (CST) Date: Thu, 18 Dec 2003 20:27:22 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "Jeremy Jin @ Nucleus" cc: linux-xfs@oss.sgi.com Subject: Re: How to install XFS release 1.3.1 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1473 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1553 Lines: 49 Those patches are only against a "vanilla' 2.4.21 kernel from kernel.org, not the heavily patched Red Hat kernel. If you want to use 1.3.1 you'll need to use the vanilla kernel or the Red Hat Linux 9 kernels we were kind enough to merge it into. -Eric On Thu, 18 Dec 2003, Jeremy Jin @ Nucleus wrote: > Hello, > > I went through oss.sgi.com, but only found how to download the CVS > development tree and build a new kernel, not found a detailed instruction to > patch my kernel with XFS Release 1.3.1. I want a stable release, not the > development tree. > > My problem is, After I downloaded the two patches in > ftp://oss.sgi.com/projects/xfs/Release-1.3.1/kernel_patches/ > > and run "patch -p0 < linux-2.4.21-core-xfs-1.3.1.patch" > and "patch -p0 < linux-xfs-1.3.1.patch" > > I got some errors said > > Reversed (or previously applied) patched found, Assume -R (n)? > Applied anyway (n)? > > After what ever i choose, yes or no, then I do "make mrproper; make > menuconfig", I didn't see any configuration option about XFS in the file > system category. > > I believe I did something wrong. But I could find any instructions about how > to apply this patches, anyone can give me a hand? > > I am using RedHat Enterprise Linux ES version 3 which kernel is 2.4.21. > Before I did anything with the kernel source, there IS already a xfs.txt > file under Documentation directory. in the /boot/config* file, there is a > line shown as "CONFIG_XFS_FS is not set". > But it doesn't have any XFS source code. > > Thanks. > > Jeremy > > > From owner-linux-xfs@oss.sgi.com Fri Dec 19 05:34:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Dec 2003 05:35:26 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBJDYqTa024525 for ; Fri, 19 Dec 2003 05:34:53 -0800 Received: by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id hBJDYodl026847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Dec 2003 14:34:51 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id hBJDYdBJ010761; Fri, 19 Dec 2003 14:34:39 +0100 Date: Fri, 19 Dec 2003 14:34:39 +0100 From: Axel Thimm To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: ATrpms has updated RH + XFS 1.3 RPMs Message-ID: <20031219133439.GD8978@neu.nirvana> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rqzD5py0kzyFAOWN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 1474 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1037 Lines: 37 --rqzD5py0kzyFAOWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 14, 2003 at 10:49:34PM -0600, Eric Sandeen wrote: > For those who were looking for updated RH kernels with XFS > 1.3.1, I see that Axel Thimm has updated his kernels now: >=20 > http://atrpms.physik.fu-berlin.de Mike Burger found a bug which had XFS_QUOTA disabled in the standard kernel builds. Fixed kernel rpms for all currently live RH versions have been uploaded. FC1: contains xfs 1.3.1 RH9, RH8.0, RH 7.3: contain xfs 1.3.0 (no need to update if you were using kernel-source to build your custom kernel, sources are the same) --=20 Axel.Thimm@physik.fu-berlin.de --rqzD5py0kzyFAOWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/4v5vQBVS1GOamfERApFYAJ9ScRemvXkVm6GVxLMnX0b8Tw6NagCfeMIi UGudLneBwP3TiABJO5kUL3E= =A6ug -----END PGP SIGNATURE----- --rqzD5py0kzyFAOWN-- From owner-linux-xfs@oss.sgi.com Fri Dec 19 07:53:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Dec 2003 07:53:29 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBJFrHTa027262 for ; Fri, 19 Dec 2003 07:53:17 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBJHArm7007120 for ; Fri, 19 Dec 2003 11:10:53 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBJFoqSC22435877; Fri, 19 Dec 2003 09:50:53 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBJFohK210848637; Fri, 19 Dec 2003 09:50:44 -0600 (CST) Date: Fri, 19 Dec 2003 09:50:52 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Rainer Traut cc: Axel Thimm , Subject: Re: ATrpms has updated RH + XFS 1.3 RPMs In-Reply-To: <3FE3077C.3040105@epost.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1476 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 354 Lines: 14 On Fri, 19 Dec 2003, Rainer Traut wrote: > How about an Enterprise Kernel with xfs support? > As a Christmas present? :) I'm working on that, because we need it for a project and I'd be happy to have the testing. I keep saying "next week" and next week is always a week away... There is some inode locking bug that I have not sorted out yet. -Eric From owner-linux-xfs@oss.sgi.com Fri Dec 19 07:52:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Dec 2003 07:52:27 -0800 (PST) Received: from priv-edtnes40.telusplanet.net (outbound05.telus.net [199.185.220.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBJFq4Ta027182 for ; Fri, 19 Dec 2003 07:52:05 -0800 Received: from [161.184.244.187] by priv-edtnes40.telusplanet.net (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with ESMTP id <20031219155159.BBEH13160.priv-edtnes40.telusplanet.net@[161.184.244.187]> for ; Fri, 19 Dec 2003 08:51:59 -0700 Subject: [Fwd: XFS in Fedora Core 2] From: Aly Dharshi Reply-To: aly.dharshi@telus.net To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1071849119.4099.3.camel@edtnas67.telus.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 19 Dec 2003 08:51:59 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 1475 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aly.dharshi@telus.net Precedence: bulk X-list: linux-xfs Content-Length: 1302 Lines: 33 -----Forwarded Message----- From: Florin Andrei To: fedora-devel-list@redhat.com, fedora-list@redhat.com Subject: XFS in Fedora Core 2 Date: Thu, 18 Dec 2003 17:35:13 -0800 Now that the schedule for the Fedora Core 2 got published, i don't see any mention of XFS. - will XFS support be included in the kernel? (probably yes, since it's already in the test version, but hopefully it won't have any debug options turned on or other silly things like that to cripple it) - how about userland XFS support? (the XFS utilities required for formatting, dumping/restoring, etc.) - how about support in the installer? (anaconda) And finally, is there any reason to hide so cautiously the other filesystems in the installer? A regular user would never find them, because everything is hidden unless arcane options are passed to the bootloader. Wouldn't be simpler to just list the supported file systems all together in Disk Druid? -- Aly Dharshi Systems Analyst Content Applications Group TELUS Technology & Operations "A good speech is like a good dress that's short enough to be interesting and long enough to cover the subject" From owner-linux-xfs@oss.sgi.com Fri Dec 19 11:55:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Dec 2003 11:56:07 -0800 (PST) Received: from ns1.tippett.com (user-112vvgq.biz.mindspring.com [66.47.254.26]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBJJtcTa001121 for ; Fri, 19 Dec 2003 11:55:42 -0800 Received: from hermes.tippett.com (hermes-e.tippett.com [192.168.3.20]) by ns1.tippett.com (8.12.8/8.12.8) with ESMTP id hBJJkktn010693 for ; Fri, 19 Dec 2003 11:46:46 -0800 Received: from tippett.com (felix.tippett.com [192.168.3.68]) by hermes.tippett.com (980427.SGI.8.8.8/8.7.3) with ESMTP id LAA66793 for ; Fri, 19 Dec 2003 11:54:57 -0800 (PST) Message-ID: <3FE3577F.6080605@tippett.com> Date: Fri, 19 Dec 2003 11:54:39 -0800 From: Christian Rice Organization: Tippett Studio User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP28; en-US; rv:1.1) Gecko/20021001 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: default quotas why not Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.901 () BAYES_00 X-Scanned-By: MIMEDefang 2.38 X-archive-position: 1477 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xian@tippett.com Precedence: bulk X-list: linux-xfs Content-Length: 432 Lines: 11 There was a thread in January where metze got kicked around for his stupid idea of default quotas. I just went back and saw the inanity of that thread, while searching the list for just such a feature announcement. I'd like to say it's one of the smartest things one could ask for in quota-land. By chance has this changed? Do we have default quotas at this time? ps the SGI xfs team rules, you've come a long way, baby! From owner-linux-xfs@oss.sgi.com Fri Dec 19 12:13:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Dec 2003 12:13:29 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBJKDITa001756 for ; Fri, 19 Dec 2003 12:13:18 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBJKDIeS001755 for linux-xfs@oss.sgi.com; Fri, 19 Dec 2003 12:13:18 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBJKDGTc001737 for ; Fri, 19 Dec 2003 12:13:16 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBJJLmrI000800; Fri, 19 Dec 2003 11:21:48 -0800 Date: Fri, 19 Dec 2003 11:21:48 -0800 Message-Id: <200312191921.hBJJLmrI000800@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 299] New: compiling xfsprogs-2.6.0 fails X-Bugzilla-Reason: AssignedTo X-archive-position: 1478 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3893 Lines: 104 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 Summary: compiling xfsprogs-2.6.0 fails Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: karlran@hotmail.com $ ./configure checking for make... /usr/bin/make checking for libtool... /usr/bin/libtool checking for tar... /bin/tar checking for gzip... /usr/bin/gzip checking for makedepend... /usr/X11R6/bin/makedepend checking for awk... /usr/bin/awk checking for sed... /usr/bin/sed checking for echo... /bin/echo checking for sort... /usr/bin/sort checking whether ln -s works... yes checking for msgfmt... /usr/bin/msgfmt checking for msgmerge... /usr/bin/msgmerge checking for rpm... /bin/rpm checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... no checking for sys/types.h... no checking for sys/stat.h... no checking for stdlib.h... no checking for string.h... no checking for memory.h... no checking for strings.h... no checking for inttypes.h... no checking for stdint.h... no checking for unistd.h... no checking uuid.h usability... no checking uuid.h presence... no checking for uuid.h... no checking uuid/uuid.h usability... no checking uuid/uuid.h presence... yes configure: WARNING: uuid/uuid.h: present but cannot be compiled configure: WARNING: uuid/uuid.h: check for missing prerequisite headers? configure: WARNING: uuid/uuid.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for uuid/uuid.h... yes checking for uuid_compare... no checking for uuid_compare in -luuid... yes checking pthread.h usability... no checking pthread.h presence... yes configure: WARNING: pthread.h: present but cannot be compiled configure: WARNING: pthread.h: check for missing prerequisite headers? configure: WARNING: pthread.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for pthread.h... yes checking for pthread_mutex_init in -lpthread... yes checking for __psint_t ... no checking for __psunsigned_t ... no checking for long... no checking size of long... 0 checking for char *... no checking size of char *... 0 configure: creating ./config.status config.status: creating include/builddefs config.status: creating include/platform_defs.h $ make === include === rm -f xfs disk ln -s . xfs ln -s . disk === libxfs === /usr/bin/libtool --mode=compile gcc -O1 -g -DNDEBUG -funsigned-char -Wall -I.. /include -DVERSION=\"2.6.0\" -DLOCALEDIR=\"/usr/local/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I. -D_REENTRANT -fno-strict-aliasing -c bit.c mkdir .libs gcc -O1 -g -DNDEBUG -funsigned-char -Wall -I../include -DVERSION=\"2.6.0\" -DLOCALEDIR=\"/usr/local/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I. -D_REENTRANT -fno-strict-aliasing -c bit.c -fPIC -DPIC -o .libs/bit.lo In file included from ../include/xfs/libxfs.h:38, from xfs.h:59, from bit.c:37: ../include/xfs/platform_defs.h:454:3: #error Unknown long size ../include/xfs/platform_defs.h:471:4: #error Unknown pointer size ../include/xfs/platform_defs.h:489:4: #error Unknown pointer size make[1]: *** [bit.lo] Error 1 make: *** [default] Error 2 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Dec 19 13:13:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Dec 2003 13:13:41 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBJLDJTa006412 for ; Fri, 19 Dec 2003 13:13:19 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBJLDJ3t006411 for linux-xfs@oss.sgi.com; Fri, 19 Dec 2003 13:13:19 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBJLDGTc006397 for ; Fri, 19 Dec 2003 13:13:17 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBJKZq19005250; Fri, 19 Dec 2003 12:35:52 -0800 Date: Fri, 19 Dec 2003 12:35:52 -0800 Message-Id: <200312192035.hBJKZq19005250@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 299] compiling xfsprogs-2.6.0 fails X-Bugzilla-Reason: AssignedTo X-archive-position: 1479 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 315 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 ------- Additional Comments From netllama@linux-sxs.org 2003-19-12 12:35 PDT ------- I've had this problem on some older linux distros too. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Dec 19 19:18:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Dec 2003 19:18:45 -0800 (PST) Received: from spock.physics.mcgill.ca (spock.physics.mcgill.ca [132.206.92.180]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBK3IMTa015752 for ; Fri, 19 Dec 2003 19:18:24 -0800 Received: from ransom by spock.physics.mcgill.ca with local (Exim 3.36 #1 (Debian)) id 1AXXcn-0004gd-00; Fri, 19 Dec 2003 22:17:53 -0500 Date: Fri, 19 Dec 2003 22:17:52 -0500 From: Scott Ransom To: Eric Sandeen Cc: Nathan Straz , linux-xfs@oss.sgi.com Subject: Re: mount: Unknown error 990 Message-ID: <20031220031752.GA18005@spock.physics.mcgill.ca> References: <200312171813.55480.ransom@physics.mcgill.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-archive-position: 1480 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ransom@physics.mcgill.ca Precedence: bulk X-list: linux-xfs Content-Length: 2098 Lines: 68 Well, I don't think this is going to help much. The output is now: XFS mounting filesystem sda1 XFS: failed to read root inode (990) This is using the new kernel 2.6.0. I also tried with a 64bit compiled verion of mount and that doesn't help. Scott On Thu, Dec 18, 2003 at 09:37:20AM -0600, Eric Sandeen wrote: > Unfortunately that message doesn't give us much to go on... > > You might try xfs_repair (possibly with -n to not actually -do- anything) > to see if it gives any info about problems on the filesystem. > > Otherwise, find this code in xfs_mount.c: > > /* > * Get and sanity-check the root inode. > * Save the pointer to it in the mount structure. > */ > error = xfs_iget(mp, NULL, sbp->sb_rootino, XFS_ILOCK_EXCL, &rip, 0); > if (error) { > cmn_err(CE_WARN, "XFS: failed to read root inode"); > goto error3; > } > > and change the cmn_err line to say: > > cmn_err(CE_WARN, "XFS: failed to read root inode (%d)", error); > > so we can at least see what error was returned from xfs_iget - > that might be a hint. > > -Eric > > On Wed, 17 Dec 2003, Scott Ransom wrote: > > > On 17 December 2003 04:50 pm, Nathan Straz wrote: > > > On Wed, Dec 17, 2003 at 12:14:25PM -0500, Scott Ransom wrote: > > > > mount: Unknown error 990 > > > > > > Check dmesg for errors. > > > > Ah. Forgot to add this. Sorry: > > > > XFS mounting filesystem sda1 > > XFS: failed to read root inode > > > > Scott > > > > -- > > Scott M. Ransom Address: McGill Univ. Physics Dept. > > Phone: (514) 398-6492 3600 University St., Rm 338 > > email: ransom@physics.mcgill.ca Montreal, QC Canada H3A 2T8 > > GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 > > > > -- -- Scott M. Ransom Address: McGill Univ. Physics Dept. Phone: (514) 398-6492 3600 University St., Rm 338 email: ransom@physics.mcgill.ca Montreal, QC Canada H3A 2T8 GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 From owner-linux-xfs@oss.sgi.com Fri Dec 19 19:39:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Dec 2003 19:39:15 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBK3d1Ta016207 for ; Fri, 19 Dec 2003 19:39:03 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBK4udm7027677 for ; Fri, 19 Dec 2003 22:56:39 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBK3csSC22525430; Fri, 19 Dec 2003 21:38:54 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBK3cjK210961656; Fri, 19 Dec 2003 21:38:45 -0600 (CST) Date: Fri, 19 Dec 2003 21:38:54 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Scott Ransom cc: Nathan Straz , Subject: Re: mount: Unknown error 990 In-Reply-To: <20031220031752.GA18005@spock.physics.mcgill.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1481 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 455 Lines: 17 Ah, our favorite, EFSCORRUPTED - an xfs special. However, it should have given more info before it passed that up... Hm. I'll take a look. -Eric On Fri, 19 Dec 2003, Scott Ransom wrote: > Well, I don't think this is going to help much. The output is > now: > > XFS mounting filesystem sda1 > XFS: failed to read root inode (990) > > This is using the new kernel 2.6.0. I also tried with a 64bit > compiled verion of mount and that doesn't help. From owner-linux-xfs@oss.sgi.com Fri Dec 19 19:45:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Dec 2003 19:45:45 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBK3jXTa016667 for ; Fri, 19 Dec 2003 19:45:34 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBK53Bm7030379 for ; Fri, 19 Dec 2003 23:03:11 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBK3iQSC22637790; Fri, 19 Dec 2003 21:44:27 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBK3iIK210950368; Fri, 19 Dec 2003 21:44:18 -0600 (CST) Date: Fri, 19 Dec 2003 21:44:26 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Scott Ransom cc: Nathan Straz , Subject: Re: mount: Unknown error 990 In-Reply-To: <20031220031752.GA18005@spock.physics.mcgill.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1482 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 262 Lines: 10 how about running with XFS_DEBUG, that turns on a few more printk's, maybe we'll hit one of those. (Oh, and sorry about the previous printk goosechase, of course it was going to print 990 wasn't it... missed the bit in the original email about 990...) -Eric From owner-linux-xfs@oss.sgi.com Sat Dec 20 08:18:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Dec 2003 08:19:19 -0800 (PST) Received: from gdr.neokimia.com (dir-rnd.med.usherbrooke.ca [132.210.158.206]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBKGIhTa004719 for ; Sat, 20 Dec 2003 08:18:43 -0800 Received: from mercure.neokimia.com (exchange.neokimia.com [192.168.1.3]) by gdr.neokimia.com (8.12.10/8.12.10) with ESMTP id hBKGIfIa025117 for ; Sat, 20 Dec 2003 11:18:41 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: XFS and HP DataProtector X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sat, 20 Dec 2003 11:18:41 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS and HP DataProtector Thread-Index: AcPHFO6GJlaTFHMrQDipw/TVpa5sfA== From: "Yanick Quirion" To: X-NK-Spam-Status: Ce message n'est pas du SPAM, (Score: 0.189, Requis: 5, MIME_BASE64_NO_NAME) X-NK-Spam-Version: SpamAssassin version 2.61 X-Scanned-By: MIMEDefang 2.38 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id hBKGIiTa004720 X-archive-position: 1483 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yanick.quirion@neokimia.com Precedence: bulk X-list: linux-xfs Content-Length: 291 Lines: 9 Hi, I'm using XFS filesystem with linux fedora core 1. When I install my backup software (HP DataProtector 5.1), I can't see mount point tar use XFS filesystem. If I browse from root (/) until the mount point, I will get an error. Is somebody had this problem? Thanks Yanick Quirion From owner-linux-xfs@oss.sgi.com Sat Dec 20 08:26:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Dec 2003 08:26:23 -0800 (PST) Received: from lists.vasoftware.com (mail@lists.vasoftware.com [198.186.202.171]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBKGQ1Ta007945 for ; Sat, 20 Dec 2003 08:26:01 -0800 Received: from adsl-67-121-189-244.dsl.sntc01.pacbell.net ([67.121.189.244]:61165 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 1AXjv1-0002Un-TF by VAauthid with fixed_plain; Sat, 20 Dec 2003 08:25:32 -0800 Message-ID: <3FE477F1.7000509@linux-sxs.org> Date: Sat, 20 Dec 2003 08:25:21 -0800 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031125 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yanick Quirion , linux-xfs@oss.sgi.com Subject: Re: XFS and HP DataProtector References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 1AXjv1-0002Un-TF 6134f053a8019a022308dd4b39da2f3b X-Spam-Score: -98.1 (---------------------------------------------------) X-archive-position: 1484 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 650 Lines: 18 On 12/20/03 08:18, Yanick Quirion wrote: > Hi, > > I'm using XFS filesystem with linux fedora core 1. When I install my backup software (HP DataProtector 5.1), I can't see mount point tar use XFS filesystem. If I browse from root (/) until the mount point, I will get an error. > > Is somebody had this problem? What is the error? What are you trying to do with tar? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 8:20am up 13 days, 13:08, 1 user, load average: 0.26, 0.42, 0.58 From owner-linux-xfs@oss.sgi.com Sat Dec 20 12:10:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Dec 2003 12:11:01 -0800 (PST) Received: from spock.physics.mcgill.ca (spock.physics.mcgill.ca [132.206.92.180]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBKKAnTa010858 for ; Sat, 20 Dec 2003 12:10:50 -0800 Received: from ransom by spock.physics.mcgill.ca with local (Exim 3.36 #1 (Debian)) id 1AXnQa-00060X-00; Sat, 20 Dec 2003 15:10:20 -0500 Date: Sat, 20 Dec 2003 15:10:20 -0500 From: Scott Ransom To: Eric Sandeen Cc: Nathan Straz , linux-xfs@oss.sgi.com Subject: Re: mount: Unknown error 990 Message-ID: <20031220201020.GA23085@spock.physics.mcgill.ca> References: <20031220031752.GA18005@spock.physics.mcgill.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-archive-position: 1485 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ransom@physics.mcgill.ca Precedence: bulk X-list: linux-xfs Content-Length: 792 Lines: 26 OK. Slightly more info this time: XFS mounting filesystem sda1 XFS: device sda1- bad inode magic/vsn daddr 64 #0 (magic=83) XFS: failed to read root inode (990) Scott On Fri, Dec 19, 2003 at 09:44:26PM -0600, Eric Sandeen wrote: > how about running with XFS_DEBUG, that turns on a few > more printk's, maybe we'll hit one of those. > > (Oh, and sorry about the previous printk goosechase, of > course it was going to print 990 wasn't it... missed > the bit in the original email about 990...) > > -Eric > -- -- Scott M. Ransom Address: McGill Univ. Physics Dept. Phone: (514) 398-6492 3600 University St., Rm 338 email: ransom@physics.mcgill.ca Montreal, QC Canada H3A 2T8 GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989 From owner-linux-xfs@oss.sgi.com Sun Dec 21 15:40:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 21 Dec 2003 15:41:19 -0800 (PST) Received: from pc2.dolda2000.com (c06284a.rny.bostream.se [217.215.27.171]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBLNeuTa019634 for ; Sun, 21 Dec 2003 15:40:57 -0800 Received: from pc7.dolda2000.com (pc7.dolda2000.com [192.168.1.254]) by pc2.dolda2000.com (8.12.8/8.11.2) with ESMTP id hBLNes5B027890 for ; Mon, 22 Dec 2003 00:40:54 +0100 From: Fredrik Tolf MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16358.12166.541230.213894@pc7.dolda2000.com> Date: Mon, 22 Dec 2003 00:40:54 +0100 To: linux-xfs@oss.sgi.com Subject: xfs_growfs doesn't detect new blocks X-Mailer: VM 7.17 under Emacs 21.2.1 X-archive-position: 1486 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fredrik@dolda2000.com Precedence: bulk X-list: linux-xfs Content-Length: 384 Lines: 13 Hi! I recently extended a logical volume that I have XFS on, and for some reason, xfs_growfs wouldn't detect the new blocks until I had umounted the filesystem and then remounted it (which, naturally, isn't really desirable). I'm using the Sistina LVM2 and XFS that come with the stock 2.6.0-test10 kernel. Is this a known issue, or did I do something wrong, mayhap? Fredrik Tolf From owner-linux-xfs@oss.sgi.com Sun Dec 21 18:16:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 21 Dec 2003 18:17:14 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBM2GjTa023953 for ; Sun, 21 Dec 2003 18:16:45 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBM3YVm7014394 for ; Sun, 21 Dec 2003 21:34:31 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBM2FdSC23282629; Sun, 21 Dec 2003 20:15:39 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBM2FFK211155173; Sun, 21 Dec 2003 20:15:25 -0600 (CST) Date: Sun, 21 Dec 2003 20:15:23 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Fredrik Tolf cc: linux-xfs@oss.sgi.com Subject: Re: xfs_growfs doesn't detect new blocks In-Reply-To: <16358.12166.541230.213894@pc7.dolda2000.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1487 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 742 Lines: 26 Odd, as far as I know, growfs just uses ioctl(fd, BLKGETSIZE64, &size); to get the size of the underlying device, in xfsprogs/libxfs/linux.c This really shouldn't have anything to do with remounting the filesystem... what exactly was the error that you saw before the remount? -Eric On Mon, 22 Dec 2003, Fredrik Tolf wrote: > Hi! > > I recently extended a logical volume that I have XFS on, and for some > reason, xfs_growfs wouldn't detect the new blocks until I had umounted > the filesystem and then remounted it (which, naturally, isn't really > desirable). > > I'm using the Sistina LVM2 and XFS that come with the stock > 2.6.0-test10 kernel. Is this a known issue, or did I do something > wrong, mayhap? > > Fredrik Tolf > > From owner-linux-xfs@oss.sgi.com Sun Dec 21 18:30:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 21 Dec 2003 18:30:41 -0800 (PST) Received: from pc2.dolda2000.com (c06284a.rny.bostream.se [217.215.27.171]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBM2UGTa024506 for ; Sun, 21 Dec 2003 18:30:29 -0800 Received: from pc7.dolda2000.com (pc7.dolda2000.com [192.168.1.254]) by pc2.dolda2000.com (8.12.8/8.11.2) with ESMTP id hBM2U95B032437; Mon, 22 Dec 2003 03:30:09 +0100 From: Fredrik Tolf MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16358.22320.666836.618205@pc7.dolda2000.com> Date: Mon, 22 Dec 2003 03:30:08 +0100 To: Eric Sandeen Cc: Fredrik Tolf , linux-xfs@oss.sgi.com Subject: Re: xfs_growfs doesn't detect new blocks In-Reply-To: References: <16358.12166.541230.213894@pc7.dolda2000.com> X-Mailer: VM 7.17 under Emacs 21.2.1 X-archive-position: 1488 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fredrik@dolda2000.com Precedence: bulk X-list: linux-xfs Content-Length: 1578 Lines: 44 Eric Sandeen writes: > Odd, as far as I know, growfs just uses ioctl(fd, BLKGETSIZE64, &size); > to get the size of the underlying device, in xfsprogs/libxfs/linux.c That's what I got from an strace as well, so I really didn't understand it. Nonetheless, lvdisplay did return the correct size. Do you think that it might just be an error in LVM2? > This really shouldn't have anything to do with remounting the > filesystem... That's what I really thought, but in a desperate attempt, I tried it, and since it worked, I guess that it flushed some data that made it work. > what exactly was the error that you saw before the remount? With -d, it listed the same info as from xfs_info and then said "data size unchanged, skipping". If I tried to manually specify a new size with -D, it would list the info again and then say "data size xxx too large, maximum is xxx (I dont't remember the exact number, but I guess it's not really important, in any case it was the current data size)". So it seems it really does get the old size reported back to it. Fredrik Tolf > On Mon, 22 Dec 2003, Fredrik Tolf wrote: > > > Hi! > > > > I recently extended a logical volume that I have XFS on, and for some > > reason, xfs_growfs wouldn't detect the new blocks until I had umounted > > the filesystem and then remounted it (which, naturally, isn't really > > desirable). > > > > I'm using the Sistina LVM2 and XFS that come with the stock > > 2.6.0-test10 kernel. Is this a known issue, or did I do something > > wrong, mayhap? > > > > Fredrik Tolf > > > > From owner-linux-xfs@oss.sgi.com Sun Dec 21 19:45:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 21 Dec 2003 19:45:58 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBM3jVTa026221 for ; Sun, 21 Dec 2003 19:45:31 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBM53Gm7011521 for ; Sun, 21 Dec 2003 23:03:16 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBM3jOSC23237012; Sun, 21 Dec 2003 21:45:24 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBM3j0K211136011; Sun, 21 Dec 2003 21:45:10 -0600 (CST) Date: Sun, 21 Dec 2003 21:45:09 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Fredrik Tolf cc: linux-xfs@oss.sgi.com Subject: Re: xfs_growfs doesn't detect new blocks In-Reply-To: <16358.22320.666836.618205@pc7.dolda2000.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1489 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 665 Lines: 17 On Mon, 22 Dec 2003, Fredrik Tolf wrote: > Eric Sandeen writes: > > Odd, as far as I know, growfs just uses ioctl(fd, BLKGETSIZE64, &size); > > to get the size of the underlying device, in xfsprogs/libxfs/linux.c > > That's what I got from an strace as well, so I really didn't > understand it. Nonetheless, lvdisplay did return the correct size. Do > you think that it might just be an error in LVM2? Perhaps... if lvm didn't correctly register the new size with the kernel. I'm not sure why an xfs mount/umount would change that, though. You could experiment with a simple test program that did a BLKGETSIZE64 ioctl on newly expanded lvm2 volumes... -Eric From owner-linux-xfs@oss.sgi.com Sun Dec 21 21:44:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 21 Dec 2003 21:45:05 -0800 (PST) Received: from bastard.smallmerchant.com (postfix@adsl-67-114-19-185.dsl.pltn13.pacbell.net [67.114.19.185]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBM5ibTa030349 for ; Sun, 21 Dec 2003 21:44:37 -0800 Received: from localhost (bastard [127.0.0.1]) by bastard.smallmerchant.com (Postfix) with ESMTP id BB84F8B331F; Sun, 21 Dec 2003 21:44:36 -0800 (PST) Received: from bastard.smallmerchant.com ([127.0.0.1]) by localhost (bastard [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23262-03; Sun, 21 Dec 2003 21:44:35 -0800 (PST) Received: from tupshin.com (fussbudget [172.16.2.50]) by bastard.smallmerchant.com (Postfix) with ESMTP id B43B88B3313; Sun, 21 Dec 2003 21:44:35 -0800 (PST) Message-ID: <3FE684C3.8090506@tupshin.com> Date: Sun, 21 Dec 2003 21:44:35 -0800 From: Tupshin Harper User-Agent: Mozilla Thunderbird 0.5a (20031216) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fredrik Tolf Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_growfs doesn't detect new blocks References: <16358.12166.541230.213894@pc7.dolda2000.com> In-Reply-To: <16358.12166.541230.213894@pc7.dolda2000.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1490 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tupshin@tupshin.com Precedence: bulk X-list: linux-xfs Content-Length: 822 Lines: 27 Fredrik Tolf wrote: >Hi! > >I recently extended a logical volume that I have XFS on, and for some >reason, xfs_growfs wouldn't detect the new blocks until I had umounted >the filesystem and then remounted it (which, naturally, isn't really >desirable). > >I'm using the Sistina LVM2 and XFS that come with the stock >2.6.0-test10 kernel. Is this a known issue, or did I do something >wrong, mayhap? > >Fredrik Tolf > > > > Known problem. I reported it in August. Turned out to be a problem in the dev-mapper layer, so reported to sistina's dm list. I got feedback from Joe Thornber in october (I think) that the problem was fixed in dm, but I just checked that the problem still exists in 2.6.0 final. You might want to check in with the dm-devel list: http://lists.sistina.com/mailman/listinfo/dm-devel -Tupshin From owner-linux-xfs@oss.sgi.com Mon Dec 22 03:34:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Dec 2003 03:34:48 -0800 (PST) Received: from pc2.dolda2000.com (c06284a.rny.bostream.se [217.215.27.171]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBMBYNTa011921 for ; Mon, 22 Dec 2003 03:34:24 -0800 Received: from pc7.dolda2000.com (pc7.dolda2000.com [192.168.1.254]) by pc2.dolda2000.com (8.12.8/8.11.2) with ESMTP id hBMBYE5B014540; Mon, 22 Dec 2003 12:34:15 +0100 From: Fredrik Tolf MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16358.54854.665049.340460@pc7.dolda2000.com> Date: Mon, 22 Dec 2003 12:32:22 +0100 To: Tupshin Harper Cc: Fredrik Tolf , linux-xfs@oss.sgi.com, sandeen@sgi.com Subject: Re: xfs_growfs doesn't detect new blocks In-Reply-To: <3FE684C3.8090506@tupshin.com> References: <16358.12166.541230.213894@pc7.dolda2000.com> <3FE684C3.8090506@tupshin.com> X-Mailer: VM 7.17 under Emacs 21.2.1 X-archive-position: 1491 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fredrik@dolda2000.com Precedence: bulk X-list: linux-xfs Content-Length: 953 Lines: 25 Tupshin Harper writes: > Fredrik Tolf wrote: > > >Hi! > > > >I recently extended a logical volume that I have XFS on, and for some > >reason, xfs_growfs wouldn't detect the new blocks until I had umounted > >the filesystem and then remounted it (which, naturally, isn't really > >desirable). > > > >I'm using the Sistina LVM2 and XFS that come with the stock > >2.6.0-test10 kernel. Is this a known issue, or did I do something > >wrong, mayhap? > > > Known problem. I reported it in August. Turned out to be a problem in > the dev-mapper layer, so reported to sistina's dm list. I got feedback > from Joe Thornber in october (I think) that the problem was fixed in dm, > but I just checked that the problem still exists in 2.6.0 final. You > might want to check in with the dm-devel list: > http://lists.sistina.com/mailman/listinfo/dm-devel Thanks! I guess I'll just have to patch it up to the latest DM, then. Fredrik Tolf From owner-linux-xfs@oss.sgi.com Mon Dec 22 09:30:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Dec 2003 09:31:01 -0800 (PST) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBMHUUTa018046 for ; Mon, 22 Dec 2003 09:30:31 -0800 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Dec 2003 12:30:24 -0500 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC09251C@THOR.goeci.com> From: Murthy Kambhampaty To: "'linux-xfs@oss.sgi.com'" Subject: CVS cmds: problems building xfsdump Date: Mon, 22 Dec 2003 12:30:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 1492 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs Content-Length: 491 Lines: 13 "make cmds" in the xfs-cmds directory give a cryptic "Error 1" when building xfsdump; running make in ~/xfs-cmds/xfsdump/ directory gives: drive_scsitape.o: In function `is_scsi_driver': ~/xfs-cmds/xfsdump/dump/drive_scsitape.c:530: undefined reference to `IRIX_DEV_TO_KDEVT' The kernel source was update from CVS, but the running kernel is older (1.3.1 with DM, LVM2). Will use 1.3.1 cmd rpms, but I was wondering if this was a more general issue (occurs on 2 different machines here). From owner-linux-xfs@oss.sgi.com Mon Dec 22 09:48:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Dec 2003 09:48:21 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBMHlxTa018589 for ; Mon, 22 Dec 2003 09:48:02 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AYU9u-0007zK-Iu; Mon, 22 Dec 2003 17:47:58 +0000 Date: Mon, 22 Dec 2003 17:47:58 +0000 From: Christoph Hellwig To: Murthy Kambhampaty Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: CVS cmds: problems building xfsdump Message-ID: <20031222174758.A30685@infradead.org> References: <2D92FEBFD3BE1346A6C397223A8DD3FC09251C@THOR.goeci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC09251C@THOR.goeci.com>; from murthy.kambhampaty@goeci.com on Mon, Dec 22, 2003 at 12:30:24PM -0500 X-archive-position: 1493 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 147 Lines: 3 Please replace the call with a "XFS_DEV_TO_KDEVT". Not sure how that change got in - it should be gone only from the 2.6 kernel headers so far.. From owner-linux-xfs@oss.sgi.com Mon Dec 22 10:19:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Dec 2003 10:19:55 -0800 (PST) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBMIJhTa019369 for ; Mon, 22 Dec 2003 10:19:43 -0800 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Dec 2003 13:19:38 -0500 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC09251D@THOR.goeci.com> From: Murthy Kambhampaty To: "'Christoph Hellwig'" , Murthy Kambhampaty Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: CVS cmds: problems building xfsdump Date: Mon, 22 Dec 2003 13:19:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 1494 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs Content-Length: 681 Lines: 24 That chokes on: drive_scsitape.o: In function `is_scsi_driver': ~/xfs-cmds/xfsdump/dump/drive_scsitape.c:530: undefined reference to `MKDEV' Apparently XFS_DEV_TO_KDEVT makes an implicit reference to MKDEV (warning appears). PS: The call is also in xfsdump-2.2.13 in Release 1.3.1. > -----Original Message----- > From: Christoph Hellwig [mailto:hch@infradead.org] > Sent: Monday, December 22, 2003 12:48 PM > To: Murthy Kambhampaty > Cc: 'linux-xfs@oss.sgi.com' > Subject: Re: CVS cmds: problems building xfsdump > > > Please replace the call with a "XFS_DEV_TO_KDEVT". Not sure > how that change > got in - it should be gone only from the 2.6 kernel headers so far.. > From owner-linux-xfs@oss.sgi.com Mon Dec 22 13:01:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Dec 2003 13:01:53 -0800 (PST) Received: from uwast.astro.wisc.edu ([144.92.179.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBML1PTa025428 for ; Mon, 22 Dec 2003 13:01:25 -0800 Received: from [144.92.179.204] (sappho.astro.wisc.edu [144.92.179.204]) (authenticated bits=0) by uwast.astro.wisc.edu (8.12.8/8.12.8) with ESMTP id hBML0xq6009571 for ; Mon, 22 Dec 2003 15:01:00 -0600 Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: linux-xfs@oss.sgi.com From: Stephan L Jansen Subject: xfs filesystems greater than 1 TB with inode size = 256? Date: Mon, 22 Dec 2003 15:00:44 -0600 X-Mailer: Apple Mail (2.609) X-archive-position: 1495 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jansen@astro.wisc.edu Precedence: bulk X-list: linux-xfs Content-Length: 354 Lines: 16 Hi, Back in October Steve Lord said in a post to this group to make sure and use "-i size=512" when making a xfs filesystem > 1 TB. I have four filesystems larger than 1 TB that were created without using this switch. Should I be worried? Is this a performance issue or is there a possibility for data corruption? Thanks. ------- Stephan From owner-linux-xfs@oss.sgi.com Mon Dec 22 14:26:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Dec 2003 14:27:08 -0800 (PST) Received: from imf21aec.mail.bellsouth.net (imf21aec.mail.bellsouth.net [205.152.59.69]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBMMQuTa026648 for ; Mon, 22 Dec 2003 14:26:56 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf21aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031222222650.JJGF1948.imf21aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Mon, 22 Dec 2003 17:26:50 -0500 Subject: Re: XFS and HP DataProtector From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Yanick Quirion Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1072131584.16407.42.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Rubber Turnip www.usr-local-bin.org Date: Mon, 22 Dec 2003 17:19:44 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1496 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 733 Lines: 26 On Sat, 2003-12-20 at 11:18, Yanick Quirion wrote: > Hi, > > I'm using XFS filesystem with linux fedora core 1. When I install my backup software (HP DataProtector 5.1), I can't see mount point tar use XFS filesystem. If I browse from root (/) until the mount point, I will get an error. > > Is somebody had this problem? > > Thanks > Yanick Quirion > > Yanick, I'm considering using Data Protector as well. Is the problem you are having unique to XFS, or do other filesystem types have it too? FYI: I looked on the data protector support matrix, and XFS is not shown, but I would not know why it would not work. Also, do you happen to know if/when the Cell Manager is going to run under Linux? Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Tue Dec 23 10:36:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Dec 2003 10:36:57 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBNIaGTa031771 for ; Tue, 23 Dec 2003 10:36:16 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBNJs7m7008345 for ; Tue, 23 Dec 2003 13:54:07 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBNIa9SC23872832; Tue, 23 Dec 2003 12:36:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBNIZjK211459649; Tue, 23 Dec 2003 12:35:55 -0600 (CST) Date: Tue, 23 Dec 2003 12:35:54 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Stephan L Jansen cc: linux-xfs@oss.sgi.com Subject: Re: xfs filesystems greater than 1 TB with inode size = 256? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1497 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 916 Lines: 30 On Mon, 22 Dec 2003, Stephan L Jansen wrote: > > Hi, > > Back in October Steve Lord said in a post to this group to make sure > and use Hm, October of which year? > "-i size=512" when making a xfs filesystem > 1 TB. I have four > filesystems > larger than 1 TB that were created without using this switch. Should > I be > worried? Is this a performance issue or is there a possibility for > data > corruption? Thanks. He was probably referring to problems with inode numbers > 64 bits, which could be alleviated by making the inode size greater, IIRC. The Linux XFS code has been restricting inode numbers by other means for quite some time now, so as long as you don't have ancient code you're probably fine. Dredge up that post again, if it was from this year please post the URL and I'll take a look, maybe Steve was talking about another issue that I'm not remembering at the moment... -Eric From owner-linux-xfs@oss.sgi.com Tue Dec 23 11:10:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Dec 2003 11:11:02 -0800 (PST) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBNJAVTa032498 for ; Tue, 23 Dec 2003 11:10:32 -0800 Received: (qmail 7878 invoked from network); 23 Dec 2003 19:10:30 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay01.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 23 Dec 2003 19:10:30 -0000 Message-ID: <3FE89359.60406@xfs.org> Date: Tue, 23 Dec 2003 13:11:21 -0600 From: Steve Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Stephan L Jansen , linux-xfs@oss.sgi.com Subject: Re: xfs filesystems greater than 1 TB with inode size = 256? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1498 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1355 Lines: 50 Eric Sandeen wrote: > On Mon, 22 Dec 2003, Stephan L Jansen wrote: > > >>Hi, >> >>Back in October Steve Lord said in a post to this group to make sure >>and use > > > Hm, October of which year? > > >>"-i size=512" when making a xfs filesystem > 1 TB. I have four >>filesystems >>larger than 1 TB that were created without using this switch. Should >>I be >>worried? Is this a performance issue or is there a possibility for >>data >>corruption? Thanks. > > > He was probably referring to problems with inode numbers > 64 bits, > which could be alleviated by making the inode size greater, IIRC. > The Linux XFS code has been restricting inode numbers by other means > for quite some time now, so as long as you don't have ancient code > you're probably fine. > > Dredge up that post again, if it was from this year please post > the URL and I'll take a look, maybe Steve was talking about another > issue that I'm not remembering at the moment... > > -Eric > You mean 32 bits ;-) With the default parameters, inodes above the first 1 Tbyte of the fs will take 33 bits to address. There are mount options (default on linux), to keep inodes down in the first 1 Tbyte to avoid this. However, things will behave a little better with the larger inode size. I cannot remember another reason for suggesting this configuration. Steve From owner-linux-xfs@oss.sgi.com Tue Dec 23 13:36:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Dec 2003 13:36:42 -0800 (PST) Received: from saytrin ([62.217.245.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBNLa9Ta012312 for ; Tue, 23 Dec 2003 13:36:16 -0800 Received: by saytrin (Postfix, from userid 4004) id 3637780AAF0; Tue, 23 Dec 2003 23:39:41 +0200 (EET) Date: Tue, 23 Dec 2003 23:39:41 +0200 From: Iustin Pop To: Steve Lord Cc: Eric Sandeen , Stephan L Jansen , linux-xfs@oss.sgi.com Subject: Re: xfs filesystems greater than 1 TB with inode size = 256? Message-ID: <20031223213941.GA4998@saytrin.hq.k1024.org> Mail-Followup-To: Steve Lord , Eric Sandeen , Stephan L Jansen , linux-xfs@oss.sgi.com References: <3FE89359.60406@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FE89359.60406@xfs.org> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.4i X-archive-position: 1499 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lists-xfs@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 707 Lines: 14 On Tue, Dec 23, 2003 at 01:11:21PM -0600, Steve Lord wrote: > However, things will behave a little better with the larger > inode size. Hello, Could you please explain why and maybe also give some explanations about how this affects performance on smaller filesystems (<1TB)? I didn't find anywhere informations related to inode size impact, and I wonder if tuning it makes a difference. Thanks, Iustin Pop From owner-linux-xfs@oss.sgi.com Tue Dec 23 14:05:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Dec 2003 14:06:12 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBNM5rTa012987 for ; Tue, 23 Dec 2003 14:05:53 -0800 Received: (qmail 16048 invoked from network); 23 Dec 2003 22:05:52 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 23 Dec 2003 22:05:52 -0000 Message-ID: <3FE8BC77.2050700@xfs.org> Date: Tue, 23 Dec 2003 16:06:47 -0600 From: Steve Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iustin Pop CC: Eric Sandeen , Stephan L Jansen , linux-xfs@oss.sgi.com Subject: Re: xfs filesystems greater than 1 TB with inode size = 256? References: <3FE89359.60406@xfs.org> <20031223213941.GA4998@saytrin.hq.k1024.org> In-Reply-To: <20031223213941.GA4998@saytrin.hq.k1024.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1500 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1663 Lines: 36 Iustin Pop wrote: > On Tue, Dec 23, 2003 at 01:11:21PM -0600, Steve Lord wrote: > >>However, things will behave a little better with the larger >>inode size. > > > Hello, > > Could you please explain why and maybe also give some explanations about > how this affects performance on smaller filesystems (<1TB)? I didn't > find anywhere informations related to inode size impact, and I wonder if > tuning it makes a difference. > > Thanks, > Iustin Pop Because it (larger inode size) allows inodes to be distributed over the whole filesystem, and hence there is more chance they will be closer to the file data. This all comes from the fact that xfs dynamically allocates inodes when needed instead of creating them at mkfs time, the location of an inode is encoded in the inode number. Making the inode size larged means that you need less bits to index into the block containing the inodes, therefore have more bits to use for the disk address. Larger inodes mean you can put more exents or directory contents into the inode, so a larger percentage of inodes in the system will not have out of line metadata. So larger inodes can make things faster in some cases. They can also make things slower since you have to read/write more blocks to cope with the same number of inodes. So basically it is a balancing act, and it depends on your application. Steve From owner-linux-xfs@oss.sgi.com Tue Dec 23 14:28:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Dec 2003 14:28:32 -0800 (PST) Received: from uwast.astro.wisc.edu (uwast.astro.wisc.edu [144.92.179.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBNMSKTa013521 for ; Tue, 23 Dec 2003 14:28:21 -0800 Received: from [192.168.1.100] (mdsnwi11-vlan423-228.wi.tds.net [66.222.60.228]) (authenticated bits=0) by uwast.astro.wisc.edu (8.12.8/8.12.8) with ESMTP id hBNMSEq6012868; Tue, 23 Dec 2003 16:28:15 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <91390BEF-3597-11D8-871F-003065F970BA@astro.wisc.edu> Content-Transfer-Encoding: 7bit Cc: linux-xfs@oss.sgi.com From: Stephan L Jansen Subject: Re: xfs filesystems greater than 1 TB with inode size = 256? Date: Tue, 23 Dec 2003 16:30:10 -0600 To: Eric Sandeen X-Mailer: Apple Mail (2.609) X-archive-position: 1501 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jansen@astro.wisc.edu Precedence: bulk X-list: linux-xfs Content-Length: 1202 Lines: 44 Hi, Steve Lord's response answered my question but for completeness here's the URL to the message I was referring to: http://oss.sgi.com/archives/linux-xfs/2003-10/msg00152.htm On Dec 23, 2003, at 12:35 PM, Eric Sandeen wrote: > On Mon, 22 Dec 2003, Stephan L Jansen wrote: > >> >> Hi, >> >> Back in October Steve Lord said in a post to this group to make sure >> and use > > Hm, October of which year? > >> "-i size=512" when making a xfs filesystem > 1 TB. I have four >> filesystems >> larger than 1 TB that were created without using this switch. Should >> I be >> worried? Is this a performance issue or is there a possibility for >> data >> corruption? Thanks. > > He was probably referring to problems with inode numbers > 64 bits, > which could be alleviated by making the inode size greater, IIRC. > The Linux XFS code has been restricting inode numbers by other means > for quite some time now, so as long as you don't have ancient code > you're probably fine. > > Dredge up that post again, if it was from this year please post > the URL and I'll take a look, maybe Steve was talking about another > issue that I'm not remembering at the moment... > > -Eric > ------- Stephan From owner-linux-xfs@oss.sgi.com Thu Dec 25 03:20:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Dec 2003 03:20:33 -0800 (PST) Received: from chello080109019036.6.14.vie.surfer.at (chello080109019036.6.14.vie.surfer.at [80.109.19.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBPBKGTa004678; Thu, 25 Dec 2003 03:20:20 -0800 Received: from [80.109.19.36] by 2004hosting.netIP with HTTP; Thu, 25 Dec 2003 02:17:54 +0300 From: "Jacobs Alexis" To: linux-mips@oss.sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: YWBSDDC, the dazzlingly bright Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [2004hosting.netIP] Date: Thu, 25 Dec 2003 05:09:54 +0600 Reply-To: "Alexis" Message-Id: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1503 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: teiivawv@mail.ru Precedence: bulk X-list: linux-xfs Content-Length: 248 Lines: 7 mineralogy aspect casino lenore mccormick receipt ike rushmore always transcription divestiture depressible cross impale menial marionette augean built pail usn barnyard colonel clarendon filipino patrolmen [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Dec 25 23:50:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Dec 2003 23:50:47 -0800 (PST) Received: from jack.feedbackplusinc.com (jack.feedbackplusinc.com [64.25.11.70]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBQ7oZTa004256 for ; Thu, 25 Dec 2003 23:50:36 -0800 Received: from localhost (localhost [127.0.0.1]) by jack.feedbackplusinc.com (Postfix) with ESMTP id F0A3C8FC60; Fri, 26 Dec 2003 01:50:29 -0600 (CST) Received: from jack.feedbackplusinc.com ([127.0.0.1]) by localhost (jack [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16791-07; Fri, 26 Dec 2003 01:50:27 -0600 (CST) Received: from 6-allhosts (c-24-0-139-219.client.comcast.net [24.0.139.219]) by jack.feedbackplusinc.com (Postfix) with ESMTP id 62B2F8FBE8; Fri, 26 Dec 2003 01:50:26 -0600 (CST) Subject: XFS filesystem corruption: 2.6.0. Massive failure. With raid5 From: Jerry Haltom To: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Content-Type: text/plain Message-Id: <1072425031.737.9.camel@osaka> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 26 Dec 2003 01:50:31 -0600 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at feedbackplusinc.com X-archive-position: 1504 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jhaltom@feedbackplusinc.com Precedence: bulk X-list: linux-xfs Content-Length: 1020 Lines: 32 This has happened twice now. Massive XFS file system corruption. The system is running on a 3ware card in Raid5 config. / is XFS. Cannot mount: XFS: log has mismatchd uuid - can't recover XFS: failed to find log head XFS: log mount/recovery/failed ... xfs_repair lets me know a lot of stuff, and: * ERROR: mismathced uuid in log * SB: some long number * log: a slightly different long number It doesn't work. xfs_logprint -t /dev/sda4 produces a lot of illegal type errors and ends up with Segmentation fault (uh oh). I am willing to give an XFS developer access to the machine to poke around (and fix it!!!) It's just my desktop at home, not a big deal. But I have a ton of large files i'd like to recover. :) I could fix it by forcing hte logs clean, that is what I did the first time this happened. However, I lost a lot of files last time, and this shouldn't happen. So here it is for you guys. I am hanging out in #xfs on irc.freenode.net if anybody wants to check it out. Jerry Haltom Feedback Plus, Inc. From owner-linux-xfs@oss.sgi.com Fri Dec 26 11:06:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Dec 2003 11:06:31 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBQJ6ATa025020 for ; Fri, 26 Dec 2003 11:06:10 -0800 Received: from conversion-daemon.woozle.fnal.gov by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HQI00D01NPPWM@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Fri, 26 Dec 2003 13:06:09 -0600 (CST) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTPSA id <0HQI00BC9NQ9JT@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Fri, 26 Dec 2003 13:06:09 -0600 (CST) Date: Fri, 26 Dec 2003 13:06:09 -0600 From: Dan Yocum Subject: kernel oops on RH2.4.20-20.9 w/XFS1.3.1 To: xfs-list Message-id: <3FEC86A1.7070802@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-archive-position: 1505 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 4731 Lines: 110 Eric, Here's the stack trace I mentioned on IRC: Dec 26 11:35:51 sdssdp5 kernel: nfsd: non-standard errno: -990 Dec 26 11:35:51 sdssdp5 kernel: 0x0: 00 0c 58 39 00 00 00 3c 00 0c 59 35 00 00 00 5a Dec 26 11:35:51 sdssdp5 kernel: Filesystem "md(9,5)": XFS internal error xfs_da_do_buf(2) at line 2284 of file xfs_da_btree.c. Caller 0xf8861067 Dec 26 11:35:51 sdssdp5 kernel: f6805bb8 f887138f 00000008 00000000 00000001 f6323000 f88c6980 f88c519b Dec 26 11:35:51 sdssdp5 kernel: 000008ec f88c50a2 f8861067 00000001 00000001 3817dd90 f8871503 f88c519b Dec 26 11:35:51 sdssdp5 kernel: 00000001 f6323000 f88c50a2 000008ec f8861067 c61d6ad0 f8860be9 f88c519b Dec 26 11:35:51 sdssdp5 kernel: Call Trace: [] xfs_error_report [xfs] 0x6f (0xf6805bbc)) Dec 26 11:35:51 sdssdp5 kernel: [] .rodata.str1.32 [xfs] 0x240 (0xf6805bd0)) Dec 26 11:35:51 sdssdp5 kernel: [] .rodata.str1.1 [xfs] 0x3d7 (0xf6805bd4)) Dec 26 11:35:51 sdssdp5 kernel: [] .rodata.str1.1 [xfs] 0x2de (0xf6805bdc)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_da_read_buf [xfs] 0x57 (0xf6805be0)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_corruption_error [xfs] 0x43 (0xf6805bf0)) Dec 26 11:35:51 sdssdp5 kernel: [] .rodata.str1.1 [xfs] 0x3d7 (0xf6805bf4)) Dec 26 11:35:51 sdssdp5 kernel: [] .rodata.str1.1 [xfs] 0x2de (0xf6805c00)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_da_read_buf [xfs] 0x57 (0xf6805c08)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_da_do_buf [xfs] 0x509 (0xf6805c10)) Dec 26 11:35:51 sdssdp5 kernel: [] .rodata.str1.1 [xfs] 0x3d7 (0xf6805c14)) Dec 26 11:35:51 sdssdp5 kernel: [] .rodata.str1.1 [xfs] 0x2de (0xf6805c24)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_da_read_buf [xfs] 0x57 (0xf6805c2c)) Dec 26 11:35:51 sdssdp5 kernel: [] __scsi_end_request [scsi_mod] 0xe1 (0xf6805c78)) Dec 26 11:35:51 sdssdp5 kernel: [] e1000_xmit_frame [e1000] 0x11d (0xf6805ca4)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_da_read_buf [xfs] 0x57 (0xf6805cc0)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_dir2_leaf_lookup_int [xfs] 0x5e (0xf6805ce0)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_dir2_leaf_lookup_int [xfs] 0x5e (0xf6805cec)) Dec 26 11:35:51 sdssdp5 kernel: [] iget4_locked [kernel] 0x61 (0xf6805d0c)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_bmap_last_offset [xfs] 0xcf (0xf6805d30)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_dir2_leaf_lookup [xfs] 0x37 (0xf6805d44)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_dir2_lookup [xfs] 0x11a (0xf6805d74)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_iunlock [xfs] 0x3e (0xf6805d90)) Dec 26 11:35:51 sdssdp5 kernel: [] linvfs_sops [xfs] 0x0 (0xf6805dc4)) Dec 26 11:35:51 sdssdp5 kernel: [] iput [kernel] 0x55 (0xf6805dcc)) Dec 26 11:35:51 sdssdp5 kernel: [] vfs_vget [xfs] 0x43 (0xf6805dd8)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_dir_lookup_int [xfs] 0x4c (0xf6805df8)) Dec 26 11:35:51 sdssdp5 kernel: [] xfs_lookup [xfs] 0x65 (0xf6805e2c)) Dec 26 11:35:51 sdssdp5 kernel: [] linvfs_lookup [xfs] 0x67 (0xf6805e5c)) Dec 26 11:35:51 sdssdp5 kernel: [] lookup_hash [kernel] 0xc2 (0xf6805e84)) Dec 26 11:35:51 sdssdp5 kernel: [] lookup_one_len [kernel] 0x5f (0xf6805ea4)) Dec 26 11:35:51 sdssdp5 kernel: [] nfsd_lookup [nfsd] 0xd0 (0xf6805ec8)) Dec 26 11:35:51 sdssdp5 kernel: [] nfsd3_proc_lookup [nfsd] 0xb0 (0xf6805f18)) Dec 26 11:35:51 sdssdp5 kernel: [] nfs3svc_decode_diropargs [nfsd] 0x85 (0xf6805f34)) Dec 26 11:35:51 sdssdp5 kernel: [] nfsd_procedures3 [nfsd] 0x6c (0xf6805f48)) Dec 26 11:35:51 sdssdp5 kernel: [] nfsd_dispatch [nfsd] 0xce (0xf6805f54)) Dec 26 11:35:51 sdssdp5 kernel: [] nfsd_version3 [nfsd] 0x0 (0xf6805f68)) Dec 26 11:35:51 sdssdp5 kernel: [] nfsd_dispatch [nfsd] 0x0 (0xf6805f6c)) Dec 26 11:35:51 sdssdp5 kernel: [] svc_process_Rsmp_01d929dc [sunrpc] 0x45f (0xf6805f70)) Dec 26 11:35:51 sdssdp5 kernel: [] nfsd_procedures3 [nfsd] 0x6c (0xf6805f90)) Dec 26 11:35:51 sdssdp5 kernel: [] nfsd_program [nfsd] 0x0 (0xf6805f94)) Dec 26 11:35:51 sdssdp5 kernel: [] nfsd [nfsd] 0x1e7 (0xf6805fb0)) Dec 26 11:35:51 sdssdp5 kernel: [] nfsd [nfsd] 0x0 (0xf6805fe0)) Dec 26 11:35:51 sdssdp5 kernel: [] kernel_thread_helper [kernel] 0x5 (0xf6805ff0)) Dec 26 11:35:51 sdssdp5 kernel: Cheers, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. You are here. From owner-linux-xfs@oss.sgi.com Fri Dec 26 20:38:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Dec 2003 20:38:37 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBR4cFTa005880 for ; Fri, 26 Dec 2003 20:38:16 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBR5uGm7018910 for ; Fri, 26 Dec 2003 23:56:16 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBR4bnSC25301057; Fri, 26 Dec 2003 22:37:49 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBR4bEK212052541; Fri, 26 Dec 2003 22:37:29 -0600 (CST) Date: Fri, 26 Dec 2003 22:37:23 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jerry Haltom cc: linux-xfs@oss.sgi.com, Subject: Re: XFS filesystem corruption: 2.6.0. Massive failure. With raid5 In-Reply-To: <1072425031.737.9.camel@osaka> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1506 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1672 Lines: 48 On Fri, 26 Dec 2003, Jerry Haltom wrote: > This has happened twice now. Massive XFS file system corruption. The > system is running on a 3ware card in Raid5 config. / is XFS. Cannot > mount: > > XFS: log has mismatchd uuid - can't recover > XFS: failed to find log head > XFS: log mount/recovery/failed Either a corrupt log, or a misstated external log, it seems. Ah, on irc you said only the first part of the uuid was off, that's a bit odd. Knowing the actual numbers would be very helpful. Perhaps the raid swizzled some bits? > xfs_repair lets me know a lot of stuff, and: > > * ERROR: mismathced uuid in log > * SB: some long number > * log: a slightly different long number Those numbers may be important, without the real output this isn't very helpful. > It doesn't work. > > xfs_logprint -t /dev/sda4 produces a lot of illegal type errors and ends > up with Segmentation fault (uh oh). Hm, so the log was in very bad shape. I don't know how it got there; it may or may not be xfs's fault, but it shouldn't segfault. If you have the core file maybe we can take a look. > I could fix it by forcing hte logs clean, that is what I did the first > time this happened. However, I lost a lot of files last time, and this > shouldn't happen. So here it is for you guys. I am hanging out in #xfs > on irc.freenode.net if anybody wants to check it out. Sounds like you've already repaired it and whacked the log, so no use now. It would also be interesting to know if any I/O or other errors occurred in the system before the problems. You might also run without the nvidia driver* for a while and see if things go better. -Eric *info gleaned from irc From owner-linux-xfs@oss.sgi.com Mon Dec 29 11:36:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Dec 2003 11:36:50 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBTJaSTa023699 for ; Mon, 29 Dec 2003 11:36:29 -0800 Received: from naboo.americas.sgi.com ([128.162.233.73]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBTHirOO023744 for ; Mon, 29 Dec 2003 09:44:54 -0800 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id 87FB28A170D; Mon, 29 Dec 2003 14:35:13 -0500 (EST) Subject: PARTIAL TAKE 904566 - Remove more imported files so they can be p_renamed correctly Message-Id: <20031229193513.87FB28A170D@naboo.americas.sgi.com> Date: Mon, 29 Dec 2003 14:35:13 -0500 (EST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1507 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@naboo.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 479 Lines: 19 Date: Mon Dec 29 11:34:32 PST 2003 Workarea: naboo.americas.sgi.com:/go/space/XFS/xfs-linux-new The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:163969a linux-2.6/page_buf.c - 1.133 linux-2.6/page_buf.h - 1.83 linux-2.6/xfs_behavior.c - 1.20 linux-2.6/xfs_behavior.h - 1.15 linux-2.6/xfs_iomap.c - 1.17 linux-2.4/xfs_buf.h - 1.84 linux-2.4/xfs_buf.c - 1.149 linux-2.4/kmem.h - 1.21 linux-2.4/kmem.c - 1.29 From owner-linux-xfs@oss.sgi.com Mon Dec 29 17:33:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Dec 2003 17:33:38 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBU1XQTa003067 for ; Mon, 29 Dec 2003 17:33:27 -0800 Received: from naboo.americas.sgi.com ([128.162.233.73]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBTNfqOO027244 for ; Mon, 29 Dec 2003 15:41:52 -0800 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id 2B86588E392; Mon, 29 Dec 2003 20:32:41 -0500 (EST) Subject: TAKE 904566 - Tree merge now complete Message-Id: <20031230013241.2B86588E392@naboo.americas.sgi.com> Date: Mon, 29 Dec 2003 20:32:41 -0500 (EST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1509 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@naboo.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1334 Lines: 53 Final bit of code moving to unify the tree rename page_buf.c/h to xfs_buf.c/h and merge in upper level xfs_buf.h Date: Mon Dec 29 17:31:52 PST 2003 Workarea: naboo.americas.sgi.com:/go/space/XFS/xfs-linux-new The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:163989a xfs_buf.h - 1.115 - code merge to linux-2.*/xfs_buf.h xfs.h - 1.42 - include changes support/mrlock.c - 1.17 - Fix to compile on both 2.4/2.6 support/Makefile - 1.18 - kmem.c moved to linux-2.4/Makefile support/kmem.h 1.21 renamed to linux-2.4/kmem.h 1.22 - support/kmem.h 1.20 Renamed to linux-2.4/kmem.hrenamed support/kmem.c 1.29 renamed to linux-2.4/kmem.c 1.30 - support/kmem.c 1.28 Renamed to linux-2.4/kmem.crenamed Makefile-linux-2.6 - 1.183 - page_buf.c -> xfs_buf.c linux-2.6/xfs_linux.h - 1.115 linux-2.4/xfs_linux.h - 1.126 - include xfs_buf.h linux-2.4/Makefile - 1.200 - page_buf.c -> xfs_buf.c linux-2.4/page_buf.c 1.149 renamed to linux-2.4/xfs_buf.c 1.150 - linux-2.4/page_buf.c 1.148 Renamed to linux-2.4/xfs_buf.crename linux-2.4/page_buf.h 1.84 renamed to linux-2.4/xfs_buf.h 1.85 - linux-2.4/page_buf.h 1.83 Renamed to linux-2.4/xfs_buf.hrename linux-2.6/xfs_buf.h - 1.83 - Merge xfs_buf.h macros linux-2.6/xfs_buf.c - 1.133 - include xfs_buf.h From owner-linux-xfs@oss.sgi.com Tue Dec 30 07:16:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Dec 2003 07:16:29 -0800 (PST) Received: from imf21aec.mail.bellsouth.net (imf21aec.mail.bellsouth.net [205.152.59.69]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBUFG2Ta029566 for ; Tue, 30 Dec 2003 07:16:02 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf21aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031230151556.NTIP1948.imf21aec.mail.bellsouth.net@david.internal.NorcrossGroup.com> for ; Tue, 30 Dec 2003 10:15:56 -0500 Subject: Question about XFS 1.2 From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: xfs-list Content-Type: text/plain Message-Id: <1072796861.19522.82.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Rubber Turnip www.usr-local-bin.org Date: Tue, 30 Dec 2003 10:07:41 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1510 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 877 Lines: 30 I have a Samba server using xfs 1.2 from SUSE 8.2 A few days ago it locked up. A few files were lost and filled with nulls. I know that issue is far less likely with xfs 1.3, so I have started the upgrade process. In addition, I have been told that a lot of DB4 database updates from the hours prior to the lockup have been lost. Not the whole file, just the updates. First, could that also be explained by the fact xfs 1.2 does not sync the disk cache out to disk. Second, is xfs 1.3 likely to not to have similar issues. FYI: We just started using this SUSE 8.2 box as a Samba Server for our CRM database (DB4) a couple of months ago. It has not really gone as smooth as I had hoped (ie. it has locked up twice, each time with some data loss). I am upgrading that server to SUSE 9.0 with xfs 1.3. Hopefully that will be more reliable. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Tue Dec 30 07:27:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Dec 2003 07:28:03 -0800 (PST) Received: from linux-sxs.org (d47-69-4-58.col.wideopenwest.com [69.47.58.4]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBUFRiTa030336 for ; Tue, 30 Dec 2003 07:27:45 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id hBUFUw9P017154; Tue, 30 Dec 2003 10:30:58 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id hBUFUvDc017151; Tue, 30 Dec 2003 10:30:57 -0500 Date: Tue, 30 Dec 2003 10:30:57 -0500 (EST) From: Net Llama! To: Greg Freemyer cc: xfs-list Subject: Re: Question about XFS 1.2 In-Reply-To: <1072796861.19522.82.camel@david.internal.NorcrossGroup.com> Message-ID: References: <1072796861.19522.82.camel@david.internal.NorcrossGroup.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.39 X-archive-position: 1511 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1183 Lines: 31 On Tue, 30 Dec 2003, Greg Freemyer wrote: > I have a Samba server using xfs 1.2 from SUSE 8.2 > > A few days ago it locked up. > > A few files were lost and filled with nulls. I know that issue is far > less likely with xfs 1.3, so I have started the upgrade process. > > In addition, I have been told that a lot of DB4 database updates from > the hours prior to the lockup have been lost. Not the whole file, just > the updates. > > First, could that also be explained by the fact xfs 1.2 does not sync > the disk cache out to disk. > > Second, is xfs 1.3 likely to not to have similar issues. > > FYI: We just started using this SUSE 8.2 box as a Samba Server for our > CRM database (DB4) a couple of months ago. It has not really gone as > smooth as I had hoped (ie. it has locked up twice, each time with some > data loss). I am upgrading that server to SUSE 9.0 with xfs 1.3. > Hopefully that will be more reliable. Has it occurred to you that maybe your problem is hardware and not software? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Tue Dec 30 08:01:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Dec 2003 08:01:12 -0800 (PST) Received: from hell.org.pl (qmailr@hell.org.pl [212.244.218.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBUG10Ta031716 for ; Tue, 30 Dec 2003 08:01:01 -0800 Received: (qmail 32245 invoked by uid 777); 30 Dec 2003 16:01:16 -0000 Date: Tue, 30 Dec 2003 17:01:16 +0100 From: Karol Kozimor To: linux-xfs@oss.sgi.com Subject: Zeroed files after unclean shutdown Message-ID: <20031230160116.GA14573@hell.org.pl> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 1512 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sziwan@hell.org.pl Precedence: bulk X-list: linux-xfs Content-Length: 1409 Lines: 30 Hi, I've been using XFS on my laptop for about a year now and overall I'm quite satisfied with its performance. I can't however, say that about stability. I've experienced file zeroing every now and then on various occasions (mostly .bash_history), though I had the impression that this issue has been substantialy improved over the time. However, it seems it has not been the case. I'm currently using 2.4.23 + various patches (including xfs-2.4.23-all-i386 dated 2003-12-01_00:33_UTC, compiled with no debug, no ACLs and any other additional stuff). Anyway, about 15 minutes ago I ran out of battery power, resulting in an unclean fs shutdown. Upon reboot I noticed that this time not only my .bash_history was lost, but also all of the bookmarks. This is doubly strange, since I did issue a sync several seconds before the shutdown happened and, what is more interesting, I did shutdown mozilla at least 30 seconds before that, so there's no way the bookmarks file could have been open at the time of shutdown. Yeah, I know you'll tell me to keep backups at hand, but come on, how come other filesystems are not so picky about open files? Or am I doing something wrong? How to prevent data loss? I'd have accepted the loss if there had been any I/O operations, but there virtually none after the sync() had returned. Do you have any ideas? Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Tue Dec 30 08:17:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Dec 2003 08:17:15 -0800 (PST) Received: from web10009.mail.yahoo.com (web10009.mail.yahoo.com [216.136.128.120]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBUGH3Ta032254 for ; Tue, 30 Dec 2003 08:17:03 -0800 Message-ID: <20031230161703.65462.qmail@web10009.mail.yahoo.com> Received: from [67.80.83.195] by web10009.mail.yahoo.com via HTTP; Tue, 30 Dec 2003 08:17:03 PST X-RocketYMMF: ktulu1115 Date: Tue, 30 Dec 2003 08:17:03 -0800 (PST) From: Anthony DeChiaro Reply-To: axd6491@njit.edu Subject: XFS & 2.6/2.4 on FC1 To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1513 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axd6491@njit.edu Precedence: bulk X-list: linux-xfs Content-Length: 853 Lines: 19 Hello- I'm looking to do a fresh format and install of Fedora Core 1 (previous OS is non-Linux) but would like to use 2.6 kernel (if possible) and XFS on most of my partitions but not quite sure the best way to approach this. I've heard that Fedora Core 2 will have XFS support built-in to the stock kernel, would trying to get that be my best bet or instead use SGI's patch for the FC1 kernel (2.4.22-1.2115.nptl at ftp://oss.sgi.com/projects/xfs/download/testing/FC1/). I'd prefer not to use a CVS build of XFS code considering it *is* a filesystem we're talking about here, unless it is extremely stable. My original plan is to follow TLDP's tutorial on Linux+XFS (http://www.tldp.org/HOWTO/Linux+XFS-HOWTO/index.html) - do a fresh install with ext3, compile new kernel, and migrate filesystems over. Any suggestions/advice? -Anthony DeChiaro From owner-linux-xfs@oss.sgi.com Tue Dec 30 09:13:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Dec 2003 09:13:57 -0800 (PST) Received: from imf24aec.mail.bellsouth.net (imf24aec.mail.bellsouth.net [205.152.59.72]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBUHDjTa004872; Tue, 30 Dec 2003 09:13:45 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf24aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031230171339.DKIL1911.imf24aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Tue, 30 Dec 2003 12:13:39 -0500 Subject: Re: Question about XFS 1.2 From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: linux-xfs-bounce@oss.sgi.com Cc: xfs-list In-Reply-To: References: <1072796861.19522.82.camel@david.internal.NorcrossGroup.com> Content-Type: text/plain Message-Id: <1072803923.19459.196.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Rubber Turnip www.usr-local-bin.org Date: Tue, 30 Dec 2003 12:05:24 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1514 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Content-Length: 1330 Lines: 35 On Tue, 2003-12-30 at 10:30, linux-xfs-bounce@oss.sgi.com wrote: > On Tue, 30 Dec 2003, Greg Freemyer wrote: > > I have a Samba server using xfs 1.2 from SUSE 8.2 > > > > A few days ago it locked up. > > > > A few files were lost and filled with nulls. I know that issue is far > > less likely with xfs 1.3, so I have started the upgrade process. > > > > In addition, I have been told that a lot of DB4 database updates from > > the hours prior to the lockup have been lost. Not the whole file, just > > the updates. > > > > First, could that also be explained by the fact xfs 1.2 does not sync > > the disk cache out to disk. > > > > Second, is xfs 1.3 likely to not to have similar issues. > > > > FYI: We just started using this SUSE 8.2 box as a Samba Server for our > > CRM database (DB4) a couple of months ago. It has not really gone as > > smooth as I had hoped (ie. it has locked up twice, each time with some > > data loss). I am upgrading that server to SUSE 9.0 with xfs 1.3. > > Hopefully that will be more reliable. > > Has it occurred to you that maybe your problem is hardware and not > software? I have not, but my issues seem consistent with problems that I have seen on this list, especially as relates to 1.2. The server does have ECC memory and I don't see any hardware issues in /var/log/warn. Greg From owner-linux-xfs@oss.sgi.com Tue Dec 30 11:36:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Dec 2003 11:37:03 -0800 (PST) Received: from hell.sks3.muni.cz (hell.sks3.muni.cz [147.251.210.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBUJaTTa011467 for ; Tue, 30 Dec 2003 11:36:30 -0800 Received: from xhejtman by hell.sks3.muni.cz with local (Exim 3.36 #1 (Debian)) id 1AbPfA-0000cD-00 for ; Tue, 30 Dec 2003 20:36:20 +0100 Date: Tue, 30 Dec 2003 20:36:20 +0100 From: Lukas Hejtmanek To: linux-xfs@oss.sgi.com Subject: XFS BUG (was Re: 3ware driver broken with 2.4.22/23 ?) Message-ID: <20031230193620.GO916@mail.muni.cz> References: <20031221112113.GE916@mail.muni.cz> <3FE645E3.30602@rackable.com> <1072503925.27022.222.camel@menion.home> <20031229234902.GL916@mail.muni.cz> <1072742359.21939.2.camel@bubbles.imr-net.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1072742359.21939.2.camel@bubbles.imr-net.com> X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb User-Agent: Mutt/1.5.4i X-archive-position: 1515 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xhejtman@hell.sks3.muni.cz Precedence: bulk X-list: linux-xfs Content-Length: 1705 Lines: 48 Hello, that was a discusion about 3ware driver. It has resulted in XFS bug most probably. With kernel 2.4.22 or 2.4.23 (SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with no debug enabled) dd if=/dev/zero of=/file_on_xfs_partition bs=448k count=23405 lockup whole server. xfs partition on SCSI disc. It happen when file becomes about 5GB of size. First I've discovered it with iozone benchmark and 10GB file.. 2.4.20 kernel with IDE disc seems to be OK as well as 2.6.0 kernel on the same configuration as 2.4.23 kernel was. On Mon, Dec 29, 2003 at 03:59:19PM -0800, Joshua Schmidlkofer wrote: > On Mon, 2003-12-29 at 15:49, Lukas Hejtmanek wrote: > > On Fri, Dec 26, 2003 at 09:45:25PM -0800, Joshua Schmidlkofer wrote: > > > > > > > Generally not with such a small rev difference. You could try the > > > > latest driver, and firmware in the 7.7. The driver source is on the Red > > > > Hat drivers disk. You should be able to drop in the .c, and .h in > > > > drivers/scsi, and recompile. > > > > http://3ware.com/support/download.asp?code=5&id=7.7.0&softtype=Driver&releasenotes=&os=Windows > > > > > > > > PS- Personally I'd suspect an XFS bug. Try reiserfs. I've been running > > > > 2.4.23pres, and 2.4.23 on hundreds of 3ware of numerous different types. > > > > With no issue with the prior firmware release. > > > > > > There are a lot of people, running RAID5 3ware's w/ Terrabyte arrays. I > > > don't want to say it is not an XFS bug, but I find that highly suspect. > > > > Well, with ext3 parition iozone program finishes OK. So it looks like some XFS > > bug. > > FWIW have you sent this on to the XFS list? > > thanks, > Joshua > > -- Lukáš Hejtmánek From owner-linux-xfs@oss.sgi.com Tue Dec 30 12:02:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Dec 2003 12:02:21 -0800 (PST) Received: from mail.mnsu.edu ([134.29.1.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBUK29Ta012386 for ; Tue, 30 Dec 2003 12:02:09 -0800 Received: from mnsu.edu (j3gum-3.ITS.MNSU.EDU [134.29.32.1]) by mail.mnsu.edu (8.12.10/8.12.10) with ESMTP id hBUK1tJY009703 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 30 Dec 2003 14:01:55 -0600 Message-ID: <3FF1D9B3.1040507@mnsu.edu> Date: Tue, 30 Dec 2003 14:01:55 -0600 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lukas Hejtmanek , linux-xfs@oss.sgi.com Subject: Re: XFS BUG (was Re: 3ware driver broken with 2.4.22/23 ?) References: <20031221112113.GE916@mail.muni.cz> <3FE645E3.30602@rackable.com> <1072503925.27022.222.camel@menion.home> <20031229234902.GL916@mail.muni.cz> <1072742359.21939.2.camel@bubbles.imr-net.com> <20031230193620.GO916@mail.muni.cz> In-Reply-To: <20031230193620.GO916@mail.muni.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1516 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: linux-xfs Content-Length: 2326 Lines: 84 I've just tried your "dd" command on a couple of boxen. Both succeeded. The systems were 1: Disk: IDE System Ram: 256MB CPU: (1) Pentium III (copermine) 1GHz Kernel: Linux version 2.4.23-rc4-xfs XFS: SGI-XFS CVS-2003-11-24_06:00_UTC with ACLs, realtime, no debug enabled 2: Disk: Hardware raid-5, "Adaptec Raid Controller 1.1-3" System Ram: 2GB CPU: (2) Intel(R) Xeon(TM) CPU 2.80GHz -- acting as 4 processors Kernel: Linux version 2.4.23-rc4-xfs XFS: SGI-XFS CVS-2003-11-24_06:00_UTC with ACLs, realtime, no debug enabled -- jeffrey hundstad Lukas Hejtmanek wrote: >Hello, > >that was a discusion about 3ware driver. It has resulted in XFS bug most >probably. > >With kernel 2.4.22 or 2.4.23 (SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with >no debug enabled) > >dd if=/dev/zero of=/file_on_xfs_partition bs=448k count=23405 > >lockup whole server. xfs partition on SCSI disc. It happen when file becomes >about 5GB of size. > >First I've discovered it with iozone benchmark and 10GB file.. > >2.4.20 kernel with IDE disc seems to be OK as well as 2.6.0 kernel on the same >configuration as 2.4.23 kernel was. > >On Mon, Dec 29, 2003 at 03:59:19PM -0800, Joshua Schmidlkofer wrote: > > >>On Mon, 2003-12-29 at 15:49, Lukas Hejtmanek wrote: >> >> >>>On Fri, Dec 26, 2003 at 09:45:25PM -0800, Joshua Schmidlkofer wrote: >>> >>> >>>>> Generally not with such a small rev difference. You could try the >>>>>latest driver, and firmware in the 7.7. The driver source is on the Red >>>>>Hat drivers disk. You should be able to drop in the .c, and .h in >>>>>drivers/scsi, and recompile. >>>>>http://3ware.com/support/download.asp?code=5&id=7.7.0&softtype=Driver&releasenotes=&os=Windows >>>>> >>>>>PS- Personally I'd suspect an XFS bug. Try reiserfs. I've been running >>>>>2.4.23pres, and 2.4.23 on hundreds of 3ware of numerous different types. >>>>> With no issue with the prior firmware release. >>>>> >>>>> >>>>There are a lot of people, running RAID5 3ware's w/ Terrabyte arrays. I >>>>don't want to say it is not an XFS bug, but I find that highly suspect. >>>> >>>> >>>Well, with ext3 parition iozone program finishes OK. So it looks like some XFS >>>bug. >>> >>> >>FWIW have you sent this on to the XFS list? >> >>thanks, >> Joshua >> >> >> >> > > > From owner-linux-xfs@oss.sgi.com Tue Dec 30 14:07:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Dec 2003 14:07:54 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBUM7QTa018769 for ; Tue, 30 Dec 2003 14:07:26 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBUKFsOO020282 for ; Tue, 30 Dec 2003 12:15:54 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBUM5nMu26398216; Tue, 30 Dec 2003 16:05:49 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBUM5dK212207816; Tue, 30 Dec 2003 16:05:39 -0600 (CST) Date: Tue, 30 Dec 2003 16:05:49 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Lukas Hejtmanek cc: linux-xfs@oss.sgi.com Subject: Re: XFS BUG (was Re: 3ware driver broken with 2.4.22/23 ?) In-Reply-To: <20031230193620.GO916@mail.muni.cz> 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 hBUKFsOO020282 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id hBUM7QTa018770 X-archive-position: 1517 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2154 Lines: 65 can you try the same kernel on an ide disk? What's the result of that? How big is the underlying filesystem? Please add the xfs_info output. Apart from that if you could run strace to see where things stop, or better yet get kdb and backtrace the process. KDB is part of the xfs cvs tree. -Eric On Tue, 30 Dec 2003, Lukas Hejtmanek wrote: > Hello, > > that was a discusion about 3ware driver. It has resulted in XFS bug most > probably. > > With kernel 2.4.22 or 2.4.23 (SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with > no debug enabled) > > dd if=/dev/zero of=/file_on_xfs_partition bs=448k count=23405 > > lockup whole server. xfs partition on SCSI disc. It happen when file becomes > about 5GB of size. > > First I've discovered it with iozone benchmark and 10GB file.. > > 2.4.20 kernel with IDE disc seems to be OK as well as 2.6.0 kernel on the same > configuration as 2.4.23 kernel was. > > On Mon, Dec 29, 2003 at 03:59:19PM -0800, Joshua Schmidlkofer wrote: > > On Mon, 2003-12-29 at 15:49, Lukas Hejtmanek wrote: > > > On Fri, Dec 26, 2003 at 09:45:25PM -0800, Joshua Schmidlkofer wrote: > > > > > > > > > Generally not with such a small rev difference. You could try the > > > > > latest driver, and firmware in the 7.7. The driver source is on the Red > > > > > Hat drivers disk. You should be able to drop in the .c, and .h in > > > > > drivers/scsi, and recompile. > > > > > http://3ware.com/support/download.asp?code=5&id=7.7.0&softtype=Driver&releasenotes=&os=Windows > > > > > > > > > > PS- Personally I'd suspect an XFS bug. Try reiserfs. I've been running > > > > > 2.4.23pres, and 2.4.23 on hundreds of 3ware of numerous different types. > > > > > With no issue with the prior firmware release. > > > > > > > > There are a lot of people, running RAID5 3ware's w/ Terrabyte arrays. I > > > > don't want to say it is not an XFS bug, but I find that highly suspect. > > > > > > Well, with ext3 parition iozone program finishes OK. So it looks like some XFS > > > bug. > > > > FWIW have you sent this on to the XFS list? > > > > thanks, > > Joshua > > > > > > -- > Lukáš Hejtmánek > > From owner-linux-xfs@oss.sgi.com Tue Dec 30 15:45:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Dec 2003 15:45:49 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBUNjbTa020481 for ; Tue, 30 Dec 2003 15:45:37 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBV13rm7017086 for ; Tue, 30 Dec 2003 19:03:53 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBUNfnMu26457362; Tue, 30 Dec 2003 17:41:49 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBUNfdK210263977; Tue, 30 Dec 2003 17:41:39 -0600 (CST) Date: Tue, 30 Dec 2003 17:41:48 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Lukas Hejtmanek cc: linux-xfs@oss.sgi.com Subject: Re: XFS BUG (was Re: 3ware driver broken with 2.4.22/23 ?) In-Reply-To: <20031230222308.GS916@mail.muni.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1518 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1014 Lines: 25 On Tue, 30 Dec 2003, Lukas Hejtmanek wrote: > > How big is the underlying filesystem? Please add > > the xfs_info output. > > (1.75TB) (8x250GB disk in raid 5, stripe 64k) > xfs_info /mnt/export > meta-data=/mnt/export isize=256 agcount=32, agsize=13354352 blks > = sectsz=512 > data = bsize=4096 blocks=427339008, imaxpct=25 > = sunit=16 swidth=112 blks, unwritten=1 > naming =version 2 bsize=4096 > log =external bsize=4096 blocks=20000, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 Ahah, i bet this is the large AG problem again... can you re-mkfs your filesystem, and make the AGs no larger than 4G? xfsprogs < 2.6.0 should do this automatically, btw. if that fixes it, let me know, we'll need to either get that fixed, or turn it off in mkfs for now. -Eric From owner-linux-xfs@oss.sgi.com Tue Dec 30 17:23:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Dec 2003 17:23:40 -0800 (PST) Received: from linux-xfs (adsl-65-66-154-148.dsl.kscymo.swbell.net [65.66.154.148]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBV1NRTa026199 for ; Tue, 30 Dec 2003 17:23:28 -0800 Message-ID: From: "Belitsky" Date: Tue, 30 Dec 2003 19:23:53 +0100 To: linux-xfs@oss.sgi.com Subject: cheeap sooftware avaailable ! mimhgmnz Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-archive-position: 1519 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wareezqxfvl@rock.com Precedence: bulk X-list: linux-xfs Content-Length: 1014 Lines: 32 sybcbbkz ezcskx qruthhzekr ejtbtl fmprf. vyirstso edeqstvo znixal osirlp icshvjrsa. qgbszr sgafcztx twtisutfu. Mlcrosoft Windows XP Professional 2002 - $39.95 Retail: $260.95 Our low: $39.95 More: http://www.softforlive.biz You S.ave: $236 Mlcosoft Office XP Professional 2002 - 59.95 Retail: $569.95 Our low: $59.95 More: http://www.softforlive.biz You S.ave: $530 Mlcrsoft Windows 2000 Professional - 34.95 Retail: $5400.95 Our low: $99.95 More: http://www.softforlive.biz You S.ave: $5501 Ad0be Photosh0p 7.0 - 59.95 Retail price: 509.95 Our low Price: 59.95 You Save: 550 Why you should pay moore for the same proooducts ??!! Read mooore about our new year's special h'ee'r'e: http://www.softforlive.biz qhodhllre vdmzpsjnbv xaomursw oqnpyua stxspwvv olbrs vegnvpj usrwqh uaqkuqhnqz yrjhcwxycmgacv vgpfjpkigm rncea xkbyhmcuj fiaauigrpc. sjdclfqm igwhnhydwl xnpgslvi akfmvygxvf jhjqujtrpxcpk oktkoga vlbdeetwpw ftsxyll meurbohlz lqzoxuex qgghtinipb siuctxiipqjkrn jalzi huacmx zwmocbam risan. From owner-linux-xfs@oss.sgi.com Tue Dec 30 18:19:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Dec 2003 18:19:46 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBV2JITa027510 for ; Tue, 30 Dec 2003 18:19:18 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBV3bZm7019314 for ; Tue, 30 Dec 2003 21:37:35 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id hBV2HCMu24303884; Tue, 30 Dec 2003 20:17:12 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id hBV16ZK212446513; Tue, 30 Dec 2003 19:06:35 -0600 (CST) Date: Tue, 30 Dec 2003 19:06:45 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Lukas Hejtmanek cc: linux-xfs@oss.sgi.com Subject: Re: XFS BUG (was Re: 3ware driver broken with 2.4.22/23 ?) In-Reply-To: <20031231000812.GT916@mail.muni.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1520 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 639 Lines: 25 On Wed, 31 Dec 2003, Lukas Hejtmanek wrote: > # mkfs.xfs -f -l logdev=/dev/hda3,size=20000b -d su=65536,sw=7,agsize=2048m /dev/sda1 2g ags here, fine. > meta-data=/dev/sda1 isize=256 agcount=816, agsize=524288 blks > = sectsz=512 524288 * 4096 is 2G > Hope I have undertood correctly. yep! > (I have xfsprogs 2.6.0, debian package 2.6.0-1) > > And dd created 10GB file without any problem. So it really looks like AG bug. Ok, good - I guess. :) Hopefully I'll have some code for you to test in a bit, need a 64-bit number in a structure, and chase that through the code. -Eric From owner-linux-xfs@oss.sgi.com Tue Dec 30 22:23:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Dec 2003 22:23:20 -0800 (PST) Received: from hell.sks3.muni.cz (hell.sks3.muni.cz [147.251.210.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBV6N7Ta032668 for ; Tue, 30 Dec 2003 22:23:08 -0800 Received: from xhejtman by hell.sks3.muni.cz with local (Exim 3.36 #1 (Debian)) id 1AbSGa-0001xF-00; Tue, 30 Dec 2003 23:23:08 +0100 Date: Tue, 30 Dec 2003 23:23:08 +0100 From: Lukas Hejtmanek To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: XFS BUG (was Re: 3ware driver broken with 2.4.22/23 ?) Message-ID: <20031230222308.GS916@mail.muni.cz> References: <20031230193620.GO916@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb User-Agent: Mutt/1.5.4i X-archive-position: 1521 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xhejtman@hell.sks3.muni.cz Precedence: bulk X-list: linux-xfs Content-Length: 1442 Lines: 35 On Tue, Dec 30, 2003 at 04:05:49PM -0600, Eric Sandeen wrote: > can you try the same kernel on an ide disk? What's > the result of that? On the same system (where I have boot IDE disk) with XFS on IDE disk with 35GB partition it seems to be ok. > How big is the underlying filesystem? Please add > the xfs_info output. (1.75TB) (8x250GB disk in raid 5, stripe 64k) xfs_info /mnt/export meta-data=/mnt/export isize=256 agcount=32, agsize=13354352 blks = sectsz=512 data = bsize=4096 blocks=427339008, imaxpct=25 = sunit=16 swidth=112 blks, unwritten=1 naming =version 2 bsize=4096 log =external bsize=4096 blocks=20000, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 > Apart from that if you could run strace to see where things stop, > or better yet get kdb and backtrace the process. KDB is part > of the xfs cvs tree. strace shows only read and write call, nothing more. I do not know how to run kdb while whole system freezes. No process runs (I run top -d 1 at the beginning on the console and it freezes as well.) Kernel responds to ping request. I remember that bdflush and some other daemon (kswapd I think) does high cpu utilization (99%) just before it freezes. -- Lukáš Hejtmánek From owner-linux-xfs@oss.sgi.com Wed Dec 31 05:06:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 05:06:58 -0800 (PST) Received: from gizmo09bw.bigpond.com (gizmo09bw.bigpond.com [144.140.70.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBVD6dTa014572 for ; Wed, 31 Dec 2003 05:06:40 -0800 Received: (qmail 22782 invoked from network); 30 Dec 2003 12:02:52 -0000 Received: from unknown (HELO bwmam07.bigpond.com) (144.135.24.87) by gizmo09bw.bigpond.com with SMTP; 30 Dec 2003 12:02:52 -0000 Received: from cpe-203-51-31-138.nsw.bigpond.net.au ([203.51.31.138]) by bwmam07.bigpond.com(MAM REL_3_4_2 62/5726492) with SMTP id 5726492; Wed, 31 Dec 2003 23:06:32 +1000 Message-ID: <3FF2C9D8.A96CA7CD@eyal.emu.id.au> Date: Thu, 01 Jan 2004 00:06:32 +1100 From: Eyal Lebedinsky Organization: Eyal at Home X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.23 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs list Subject: blocksize question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1522 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: eyal@eyal.emu.id.au Precedence: bulk X-list: linux-xfs Content-Length: 1093 Lines: 32 We have an 8 disk RAID-5 on 3ware setup at the office. The whole disk (/dev/sda) is xfs. We notice that the performance is not that hot, and one thing we are looking at is the block size. XFS says it is 4096: ======================================= [root@ssa18 ~]# xfs_info /backup meta-data=/backup isize=256 agcount=268, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=280149632, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 ======================================= At the same time we see: ======================================= [root@ssa18 ~]# blockdev --getbsz /dev/sda 512 ======================================= Is this how it is supposed to be? -- Eyal Lebedinsky (eyal@eyal.emu.id.au) From owner-linux-xfs@oss.sgi.com Wed Dec 31 07:58:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 07:58:39 -0800 (PST) Received: from amber.he.net (amber.he.net [216.218.172.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBVFwATa017368 for ; Wed, 31 Dec 2003 07:58:10 -0800 Received: from mikesx31 ([208.35.40.2] (may be forged)) by amber.he.net (8.8.6p2003-03-31/8.8.2) with ESMTP id HAA24969; Wed, 31 Dec 2003 07:58:00 -0800 Message-Id: <200312311558.HAA24969@amber.he.net> From: "Mike Young" To: "'Eyal Lebedinsky'" , "'linux-xfs list'" Subject: RE: blocksize question Date: Wed, 31 Dec 2003 07:57:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <3FF2C9D8.A96CA7CD@eyal.emu.id.au> Thread-Index: AcPPnvw6PjEmBPK/TnytLLTCfaojCgAF7Wkw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 1523 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: myoung@wildernessvoice.com Precedence: bulk X-list: linux-xfs Content-Length: 1517 Lines: 50 Hi Eyal, I'm currently doing some performance testing with 3Ware and some other RAID options on SuSE 9.0 and using XFS. What kind of performance are you seeing? And what tests are you using? -Mike -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Eyal Lebedinsky Sent: Wednesday, December 31, 2003 5:07 AM To: linux-xfs list Subject: blocksize question We have an 8 disk RAID-5 on 3ware setup at the office. The whole disk (/dev/sda) is xfs. We notice that the performance is not that hot, and one thing we are looking at is the block size. XFS says it is 4096: ======================================= [root@ssa18 ~]# xfs_info /backup meta-data=/backup isize=256 agcount=268, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=280149632, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 ======================================= At the same time we see: ======================================= [root@ssa18 ~]# blockdev --getbsz /dev/sda 512 ======================================= Is this how it is supposed to be? -- Eyal Lebedinsky (eyal@eyal.emu.id.au) From owner-linux-xfs@oss.sgi.com Wed Dec 31 12:14:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 12:14:44 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBVKEGTa023961 for ; Wed, 31 Dec 2003 12:14:16 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBVKEGTZ023960 for linux-xfs@oss.sgi.com; Wed, 31 Dec 2003 12:14:16 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBVKEETc023946 for ; Wed, 31 Dec 2003 12:14:14 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBVJiGKq023657; Wed, 31 Dec 2003 11:44:16 -0800 Date: Wed, 31 Dec 2003 11:44:16 -0800 Message-Id: <200312311944.hBVJiGKq023657@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 300] New: Lookup while "mkisofs"ing a DVD-Image X-Bugzilla-Reason: AssignedTo X-archive-position: 1524 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1178 Lines: 33 http://oss.sgi.com/bugzilla/show_bug.cgi?id=300 Summary: Lookup while "mkisofs"ing a DVD-Image Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: ms@citd.de When i try to create a DVD-Image with mkisofs (4.2 GB in size) i get a (most times) reproducable lookup at about 95% to 100% completition (6 out of 8 tries). This happens both with 2.4.24-pre3 (vanilla) and 2.4.23 + XFS-Patch. Nothing appears in the log-files and nothing appears on the screen (The 8 tries where with a freshly booted system on the console (no X11)). Compilers i tried: gcc-3.3.3(Debian Prerelease 20031229) and gcc-2.95.4 System is a Dual-P3-933Mhz, 3GB-RAM. The involved HDDs (both 100GB Western Digital, 7200RPM) are connected to a HighPoint RapidRAID 1540. The system is 3 years old and worked flawlessly with reiserfs for months. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 31 12:49:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 12:50:08 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id hBVKnuTa027372 for ; Wed, 31 Dec 2003 12:49:57 -0800 Received: from stout.americas.sgi.com ([128.162.232.50]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id hBVM8Gm7006500 for ; Wed, 31 Dec 2003 16:08:16 -0600 Received: from stout.americas.sgi.com (localhost [127.0.0.1]) by stout.americas.sgi.com (8.12.8/8.12.8) with ESMTP id hBVKBlBS019617; Wed, 31 Dec 2003 14:11:47 -0600 Received: (from sandeen@localhost) by stout.americas.sgi.com (8.12.8/8.12.8/Submit) id hBVKBleH019615; Wed, 31 Dec 2003 14:11:47 -0600 Date: Wed, 31 Dec 2003 14:11:47 -0600 From: Eric Sandeen Message-Id: <200312312011.hBVKBleH019615@stout.americas.sgi.com> Subject: PARTIAL TAKE 907100 - Make more xfs errors trappable with panic_mask X-archive-position: 1525 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@stout.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 603 Lines: 18 Make more xfs errors trappable with panic_mask Date: Wed Dec 31 12:11:12 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/xfs-linux-new The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:164051a xfs_error.c - 1.49 - Route all errors from xfs_error_report through xfs_cmn error, to make them trappable via the panic_mask setting. Previously calls to xfs_error_report without an xfs_mount_t passed in were not trappable; just deal with the lack of mp later, it was only used for informational messages. From owner-linux-xfs@oss.sgi.com Wed Dec 31 13:14:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 13:14:43 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBVLEJTa028065 for ; Wed, 31 Dec 2003 13:14:19 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBVLEJGP028063 for linux-xfs@oss.sgi.com; Wed, 31 Dec 2003 13:14:19 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBVLEETc028035 for ; Wed, 31 Dec 2003 13:14:15 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBVKwoZw027892; Wed, 31 Dec 2003 12:58:50 -0800 Date: Wed, 31 Dec 2003 12:58:50 -0800 Message-Id: <200312312058.hBVKwoZw027892@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 300] Lookup while "mkisofs"ing a DVD-Image X-Bugzilla-Reason: AssignedTo X-archive-position: 1526 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 386 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=300 ------- Additional Comments From sandeen@sgi.com 2003-31-12 12:58 PDT ------- Actually please include the xfs_info output first, this is simplest and will quickly rule out or confirm a specific problem, thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 31 13:14:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 13:14:43 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBVLEJTa028064 for ; Wed, 31 Dec 2003 13:14:19 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBVLEJCU028062 for linux-xfs@oss.sgi.com; Wed, 31 Dec 2003 13:14:19 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBVLEETg028035 for ; Wed, 31 Dec 2003 13:14:15 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBVKvVfR027873; Wed, 31 Dec 2003 12:57:31 -0800 Date: Wed, 31 Dec 2003 12:57:31 -0800 Message-Id: <200312312057.hBVKvVfR027873@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 300] Lookup while "mkisofs"ing a DVD-Image X-Bugzilla-Reason: AssignedTo X-archive-position: 1526 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 718 Lines: 25 http://oss.sgi.com/bugzilla/show_bug.cgi?id=300 ------- Additional Comments From sandeen@sgi.com 2003-31-12 12:57 PDT ------- Please strace the process to see where it's stopping, and if possible can you test it on a non-xfs filesystem as well? You could also get the kernel tree from oss.sgi.com cvs, this will include kdb and you could get a kernel backtrace to see where things are stuck. As it is, I don't think there's enough info to debug anything. Ah, one further thought... please include xfs_info output for the mount point you're using, this may be the large AG problem again. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 31 14:14:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 14:14:39 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBVMEHTa029765 for ; Wed, 31 Dec 2003 14:14:17 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBVMEHRH029763 for linux-xfs@oss.sgi.com; Wed, 31 Dec 2003 14:14:17 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBVMEFTg029736 for ; Wed, 31 Dec 2003 14:14:16 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBVLVnTq028993; Wed, 31 Dec 2003 13:31:49 -0800 Date: Wed, 31 Dec 2003 13:31:49 -0800 Message-Id: <200312312131.hBVLVnTq028993@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 300] Lookup while "mkisofs"ing a DVD-Image X-Bugzilla-Reason: AssignedTo X-archive-position: 1527 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 862 Lines: 26 http://oss.sgi.com/bugzilla/show_bug.cgi?id=300 ------- Additional Comments From ms@citd.de 2003-31-12 13:31 PDT ------- Here is the xfs_info I formated the partition without further option to mkfs.xfs # xfs_info /dev/hdk1 meta-data=/x4 isize=256 agcount=16, agsize=1526339 blks = sectsz=512 data = bsize=4096 blocks=24421424, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=11924, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 31 14:14:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 14:14:44 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBVMEHTa029766 for ; Wed, 31 Dec 2003 14:14:17 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBVMEHQd029764 for linux-xfs@oss.sgi.com; Wed, 31 Dec 2003 14:14:17 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBVMEFTc029736 for ; Wed, 31 Dec 2003 14:14:15 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBVLZdNo029011; Wed, 31 Dec 2003 13:35:39 -0800 Date: Wed, 31 Dec 2003 13:35:39 -0800 Message-Id: <200312312135.hBVLZdNo029011@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 300] Lookup while "mkisofs"ing a DVD-Image X-Bugzilla-Reason: AssignedTo X-archive-position: 1528 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 705 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=300 ------- Additional Comments From ms@citd.de 2003-31-12 13:35 PDT ------- Testing with non-xfs partition. Before today i used reiserfs for month, worked flawlessly. (The last hardware-change is more than 3 month ago). Kernel 2.4.23 ran since about 1 week after it was released without problems. The first lockup was even with reiserfs as the source-partition after the first lookup i "converted" the source-partition to xfs. (Btw. "cp -av"ing 40GB of data went through without problems). Later i will try the other suggestions. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 31 15:14:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 15:14:38 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBVNEHTa031041 for ; Wed, 31 Dec 2003 15:14:17 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBVNEHKQ031040 for linux-xfs@oss.sgi.com; Wed, 31 Dec 2003 15:14:17 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id hBVNEFTc031026 for ; Wed, 31 Dec 2003 15:14:15 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hBVN21t5030916; Wed, 31 Dec 2003 15:02:01 -0800 Date: Wed, 31 Dec 2003 15:02:01 -0800 Message-Id: <200312312302.hBVN21t5030916@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 300] Lookup while "mkisofs"ing a DVD-Image X-Bugzilla-Reason: AssignedTo X-archive-position: 1529 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 636 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=300 ------- Additional Comments From sandeen@sgi.com 2003-31-12 15:02 PDT ------- Ok, your allocation groups are > 4G (they are 5G or so) which means that file extents can grow past 4G, and this overflows the 32 bits that contain the length in an iomap structure. I'm working on the fix for this; if you want to re-mkfs and test with mkfs options to constrain the AGs to 4G or less, that should fix your problem in the meantime. (the -d agsize=4g option to mkfs) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 31 16:14:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 16:14:30 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i010EHTa032153 for ; Wed, 31 Dec 2003 16:14:17 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i010EHne032152 for linux-xfs@oss.sgi.com; Wed, 31 Dec 2003 16:14:17 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i010EGTg032124 for ; Wed, 31 Dec 2003 16:14:16 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0107lTM032091; Wed, 31 Dec 2003 16:07:47 -0800 Date: Wed, 31 Dec 2003 16:07:47 -0800 Message-Id: <200401010007.i0107lTM032091@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 301] New: xfsdump won't compile X-Bugzilla-Reason: AssignedTo X-archive-position: 1531 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1301 Lines: 36 http://oss.sgi.com/bugzilla/show_bug.cgi?id=301 Summary: xfsdump won't compile Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: xfsdump AssignedTo: xfs-master@oss.sgi.com ReportedBy: corliss@digitalmages.com Using the latest CVS snapshop as of 2003/12/29 xfsdump won't compile. It fails with the message: gcc -o xfsdump arch_xlate.o cldmgr.o content_common.o dlog.o drive.o drive_scsitape.o drive_simple.o drive_minrmt.o fs.o getdents.o global.o lock.o main.o mlog.o openutil.o qlock.o path.o ring.o stream.o util.o sproc.o inv_api.o inv_core.o inv_files.o inv_fstab.o inv_idx.o inv_mgr.o inv_stobj.o content.o hsmapi.o inomap.o var.o /usr/lib/libuuid.a /lib/libhandle.so /lib/libattr.so /lib/libdm.so ../librmt/.libs/librmt.al drive_scsitape.o: In function `is_scsi_driver': /usr/src/nevaeh/build/xfs-cmds/xfs-cmds/xfsdump/dump/drive_scsitape.c:531: undefined reference to `IRIX_DEV_TO_KDEVT' collect2: ld returned 1 exit status make[1]: *** [xfsdump] Error 1 make: *** [default] Error 2 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 31 16:14:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 16:14:29 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i010EHTa032154 for ; Wed, 31 Dec 2003 16:14:17 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i010EHq5032151 for linux-xfs@oss.sgi.com; Wed, 31 Dec 2003 16:14:17 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i010EGTc032124 for ; Wed, 31 Dec 2003 16:14:16 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i010ATgm032110; Wed, 31 Dec 2003 16:10:29 -0800 Date: Wed, 31 Dec 2003 16:10:29 -0800 Message-Id: <200401010010.i010ATgm032110@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 300] Lookup while "mkisofs"ing a DVD-Image X-Bugzilla-Reason: AssignedTo X-archive-position: 1530 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1198 Lines: 33 http://oss.sgi.com/bugzilla/show_bug.cgi?id=300 ------- Additional Comments From ms@citd.de 2003-31-12 16:10 PDT ------- 95GB/16 = 5,9GB. Sure this is more than 4GB. :-( OK. I've recreated the filesystem with doubled agcount. meta-data=/x4 isize=256 agcount=32, agsize=763170 blks = sectsz=512 data = bsize=4096 blocks=24421438, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=11924, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 This also explains why "cp -av"ing the data around ("dump & restore") wasn't a problem because the biggest file copied was only(tm) 3,4 GB in size. Creating the DVD-Image hadn't crashed the machine (3 tries). I hope this was my first and last problem with XFS (knocking on wood). :-) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Dec 31 16:46:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 16:47:08 -0800 (PST) Received: from gizmo11bw.bigpond.com (gizmo11bw.bigpond.com [144.140.70.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i010kmTa003426 for ; Wed, 31 Dec 2003 16:46:48 -0800 Received: (qmail 14122 invoked from network); 31 Dec 2003 23:34:40 -0000 Received: from unknown (HELO bwmam07.bigpond.com) (144.135.24.87) by gizmo11bw.bigpond.com with SMTP; 31 Dec 2003 23:34:40 -0000 Received: from cpe-203-51-31-138.nsw.bigpond.net.au ([203.51.31.138]) by bwmam07.bigpond.com(MAM REL_3_4_2 62/5820740) with SMTP id 5820740; Thu, 01 Jan 2004 10:46:41 +1000 Message-ID: <3FF36DF1.C6973D7@eyal.emu.id.au> Date: Thu, 01 Jan 2004 11:46:41 +1100 From: Eyal Lebedinsky Organization: Eyal at Home X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.23 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mike Young CC: "'linux-xfs list'" Subject: Re: blocksize question References: <200312311558.HAA24969@amber.he.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1532 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: eyal@eyal.emu.id.au Precedence: bulk X-list: linux-xfs Content-Length: 1339 Lines: 40 Mike Young wrote: > > Hi Eyal, > > I'm currently doing some performance testing with 3Ware and some other RAID > options on SuSE 9.0 and using XFS. What kind of performance are you seeing? > And what tests are you using? We have a 7500-12, The raid5 is 8 disks + hot spare (XFS mounted on /backup). We attempted to add a raid0 with two disks but this seems to be too much load. This two disk raid0 was software raid but we kept getting io errors {DriveReady SeekComplere Error} The test is simply reading or writing (dd) a large file. For example: 10GB /dev/zero -> /backup 3m57 (43 MB/s) 10GB /backup -> /dev/null 7m20 (23 MB/s) We do each 'dd' twice and take the second copy as the result. The machine is otherwise idle. This copying is a good measure for us since this machine is an online backup service and it will mostly have large files copied to it and from it. Each disk alone on an IDE cable does about 55MB/s (hdparm, not real performance). Here are the results for the raid0 on the 3ware (/dev/sdb, ext2 on /ssaback): 10GB /dev/zero -> /ssaback 3m52 (44 MB/s) 10GB /ssaback -> /dev/null 2m42 (63 MB/s) BTW, the XFS uses an internal log. I wonder if we should move to an external log? The machine is a dual AMD MP 2100+ with 1GB RAM. -- Eyal Lebedinsky (eyal@eyal.emu.id.au) From owner-linux-xfs@oss.sgi.com Wed Dec 31 16:58:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 16:58:37 -0800 (PST) Received: from snoopy.pacific.net.au (snoopy.pacific.net.au [61.8.0.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i010wPTa003929 for ; Wed, 31 Dec 2003 16:58:25 -0800 Received: from mongrel.pacific.net.au (mongrel.pacific.net.au [61.8.0.107]) by snoopy.pacific.net.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id i010wNno006213 for ; Thu, 1 Jan 2004 11:58:23 +1100 Received: from jdc.local (dyn172.mel2.homedsl.pacific.net.au [203.100.245.172]) by mongrel.pacific.net.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id i010wNxs006261 for ; Thu, 1 Jan 2004 11:58:23 +1100 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.10/8.12.10/Debian-5) with ESMTP id i010wMVG006328 for ; Thu, 1 Jan 2004 11:58:22 +1100 Received: (from jason@localhost) by jdc.local (8.12.10/8.12.10/Debian-5) id i010wM3k006322; Thu, 1 Jan 2004 11:58:22 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16371.28846.677734.571311@jdc.local> Date: Thu, 1 Jan 2004 11:58:22 +1100 To: linux-xfs Subject: Access to 2.6-xfs CVS tree X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 1533 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 250 Lines: 8 It was announced on the list a few months ago that the 2.6-xfs CVS tree had been withdrawn while legal issues (cryptographic export?) were sorted out. What's the current status? I live in Australia and I'm interested in trying the latest 2.6-xfs. From owner-linux-xfs@oss.sgi.com Wed Dec 31 17:39:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 17:39:30 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.177.98]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i011d7Ta004612 for ; Wed, 31 Dec 2003 17:39:07 -0800 Received: from mail.pacrimopen.com (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id E6C7670024C9 for ; Wed, 31 Dec 2003 17:39:53 -0800 (PST) Received: from UNKNOWN(127.0.0.1), claiming to be "mail.pacrimopen.com" via SMTP by sa-relay.pacrimopen.com, id smtpdX8DWoX; Wed Dec 31 17:39:41 2003 Received: from menion.home (unknown [4.4.175.20]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id A973A70024C9 for ; Wed, 31 Dec 2003 17:39:40 -0800 (PST) Subject: Calculating agsize? From: Joshua Schmidlkofer To: XFS Mailing List Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5suPbL6iKCP5Xz8/HumY" Message-Id: <1072921132.27620.0.camel@menion.home> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 31 Dec 2003 17:38:52 -0800 X-archive-position: 1534 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: menion@asylumwear.com Precedence: bulk X-list: linux-xfs Content-Length: 516 Lines: 24 --=-5suPbL6iKCP5Xz8/HumY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable How does one calculate the ag size? thanks, Joshua --=-5suPbL6iKCP5Xz8/HumY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQA/83orcweM6t71VHsRAnjlAJ0baE5Xd+/0tsZ6dcD5LiGByYEHuACgnFvX bYwt9A+aVrbPfW3nxaBgATI= =b1N/ -----END PGP SIGNATURE----- --=-5suPbL6iKCP5Xz8/HumY-- From owner-linux-xfs@oss.sgi.com Wed Dec 31 19:27:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 19:28:03 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i013RbTa005933 for ; Wed, 31 Dec 2003 19:27:37 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i011aAOO021960 for ; Wed, 31 Dec 2003 17:36:10 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id i013RUMu26806770; Wed, 31 Dec 2003 21:27:30 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i013RKK212503916; Wed, 31 Dec 2003 21:27:20 -0600 (CST) Date: Wed, 31 Dec 2003 21:27:29 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Joshua Schmidlkofer cc: XFS Mailing List Subject: Re: Calculating agsize? In-Reply-To: <1072921132.27620.0.camel@menion.home> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1535 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 216 Lines: 14 From mkfs.xfs or xfs_info output, take agsize * bsize, to get the size of an AG in bytes. -Eric On Wed, 31 Dec 2003, Joshua Schmidlkofer wrote: > How does one calculate the ag size? > > thanks, > Joshua > > From owner-linux-xfs@oss.sgi.com Wed Dec 31 20:11:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 20:11:58 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i014BkTa006642 for ; Wed, 31 Dec 2003 20:11:46 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i015U6m7012885 for ; Wed, 31 Dec 2003 23:30:06 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id i014AdMu26687296; Wed, 31 Dec 2003 22:10:39 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i0146ZK212483486; Wed, 31 Dec 2003 22:06:35 -0600 (CST) Date: Wed, 31 Dec 2003 22:06:45 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jason White cc: linux-xfs Subject: Re: Access to 2.6-xfs CVS tree In-Reply-To: <16371.28846.677734.571311@jdc.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1536 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 466 Lines: 16 On Thu, 1 Jan 2004, Jason White wrote: > It was announced on the list a few months ago that the 2.6-xfs CVS > tree had been withdrawn while legal issues (cryptographic export?) > were sorted out. > > What's the current status? > > I live in Australia and I'm interested in trying the latest 2.6-xfs. The 2.6 tree should be available by cvs following the instructions at http://oss.sgi.com/projects/xfs/cvs_download.html; if you have trouble let us know. -Eric From owner-linux-xfs@oss.sgi.com Wed Dec 31 21:28:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 31 Dec 2003 21:28:59 -0800 (PST) Received: from amber.he.net (amber.he.net [216.218.172.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i015SmTa010335 for ; Wed, 31 Dec 2003 21:28:48 -0800 Received: from mikesx31 ([208.35.40.2] (may be forged)) by amber.he.net (8.8.6p2003-03-31/8.8.2) with ESMTP id VAA17301; Wed, 31 Dec 2003 21:28:52 -0800 Message-Id: <200401010528.VAA17301@amber.he.net> From: "Mike Young" To: "'Eyal Lebedinsky'" Cc: "'linux-xfs list'" Subject: RE: blocksize question Date: Wed, 31 Dec 2003 21:28:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3FF36DF1.C6973D7@eyal.emu.id.au> Thread-Index: AcPQAYKHFhPZH88LQ++aDGPmWgXRKwAJGSAg X-archive-position: 1537 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: myoung@wildernessvoice.com Precedence: bulk X-list: linux-xfs Content-Length: 2630 Lines: 76 Eyal, I have not tried the dd test yet. I'll be getting to that tomorrow. On a dual 3.06 Xeon, I received a performance spread of 7MB/sec to 29MB/sec using smbtorture across GbE using a crossover cable. My client was a 1.4GHz P4. The server also had 512MB. The 29MB/sec was at 12 clients. After that, the output was a consistent 21.xxMB/sec up to 53 clients. I did this test using an external log, which I have found to be much faster on such testing than using the internal log. However, I did the same test with an LSI controller and obtained over 40MB/sec at 53 clients. I'm trying to also repeat the test using MD RAID. In the past, I've had MD RAID doing over 50MB/sec on the same test. But I do want to repeat just to be sure. Also, I have some messages over to the 3Ware folks to see if they can help on this. It sounds like the external journal should help you some. Any idea what the block size is on ext2 system? I'm wondering if that may be the issue. The default you're using on your xfs system is probably 4K. -Mike -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Eyal Lebedinsky Sent: Wednesday, December 31, 2003 4:47 PM To: Mike Young Cc: 'linux-xfs list' Subject: Re: blocksize question Mike Young wrote: > > Hi Eyal, > > I'm currently doing some performance testing with 3Ware and some other RAID > options on SuSE 9.0 and using XFS. What kind of performance are you seeing? > And what tests are you using? We have a 7500-12, The raid5 is 8 disks + hot spare (XFS mounted on /backup). We attempted to add a raid0 with two disks but this seems to be too much load. This two disk raid0 was software raid but we kept getting io errors {DriveReady SeekComplere Error} The test is simply reading or writing (dd) a large file. For example: 10GB /dev/zero -> /backup 3m57 (43 MB/s) 10GB /backup -> /dev/null 7m20 (23 MB/s) We do each 'dd' twice and take the second copy as the result. The machine is otherwise idle. This copying is a good measure for us since this machine is an online backup service and it will mostly have large files copied to it and from it. Each disk alone on an IDE cable does about 55MB/s (hdparm, not real performance). Here are the results for the raid0 on the 3ware (/dev/sdb, ext2 on /ssaback): 10GB /dev/zero -> /ssaback 3m52 (44 MB/s) 10GB /ssaback -> /dev/null 2m42 (63 MB/s) BTW, the XFS uses an internal log. I wonder if we should move to an external log? The machine is a dual AMD MP 2100+ with 1GB RAM. -- Eyal Lebedinsky (eyal@eyal.emu.id.au)