From owner-linux-xfs@oss.sgi.com Thu Jan 1 08:00:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 08:01:25 -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 i01G0sTa025423 for ; Thu, 1 Jan 2004 08:00:55 -0800 Received: from localhost (localhost [127.0.0.1]) by jack.feedbackplusinc.com (Postfix) with ESMTP id EBF588FC71 for ; Thu, 1 Jan 2004 10:00:47 -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 31227-01 for ; Thu, 1 Jan 2004 10:00:45 -0600 (CST) Received: from c-24-0-138-66.client.comcast.net (c-24-0-138-66.client.comcast.net [24.0.138.66]) by jack.feedbackplusinc.com (Postfix) with ESMTP id CE5098FC59 for ; Thu, 1 Jan 2004 10:00:44 -0600 (CST) Subject: XFS external log questions From: Jerry Haltom To: "'linux-xfs list'" Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eq/k8Fz7AIM3GBrMp+rH" Organization: Feedback Plus, Inc. Message-Id: <1072972834.2956.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 01 Jan 2004 10:00:34 -0600 X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at feedbackplusinc.com X-archive-position: 1538 X-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 --=-eq/k8Fz7AIM3GBrMp+rH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Few questions about setting up and using a proper external log: I have a system whose only drive is a raid 5 array. I assume putting hte log on the array itself, on another partition, would be pretty useless, if the data is on the array also. So, I could put in anohter drive, but what are the usual redundency requirements for the external log? I assume if it fails, the entire partition fails also. So, one would need two raid setups to use this effectively? How much data does the log usually use? Thanks --=20 Jerry Haltom Feedback Plus, Inc. --=-eq/k8Fz7AIM3GBrMp+rH 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/9EQhRTZ5+YJ1b+YRAuESAJ9CtFz9dgNBqbpXCo3oItYqBEW3NgCgzcqm ztgMvoSi71T6sZps6FlITp8= =t23U -----END PGP SIGNATURE----- --=-eq/k8Fz7AIM3GBrMp+rH-- From owner-linux-xfs@oss.sgi.com Thu Jan 1 09:34:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 09:34:16 -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 i01HY4Ta029328 for ; Thu, 1 Jan 2004 09:34:04 -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 i01IqRm7002864 for ; Thu, 1 Jan 2004 12:52:27 -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 i01HWvMu26899614; Thu, 1 Jan 2004 11:32: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 i01HWkK210560759; Thu, 1 Jan 2004 11:32:46 -0600 (CST) Date: Thu, 1 Jan 2004 11:32:56 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jerry Haltom cc: "'linux-xfs list'" Subject: Re: XFS external log questions In-Reply-To: <1072972834.2956.2.camel@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1539 X-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 There are a couple of reasons for using an external log. If there is a dedicated block device for the log, then log writes won't cause the head to seek away from the data, which could speed things up. Of course in a raid this is probably less critical, as the notion of "the head" is a little blurry. Also, log writes are done in sector-sized units, while data writes are done in filesystem block-sized units. In software MD raids, this size-switching is very inefficient. Putting the log on an external device alleviates this (as would setting the sector size equal to the block size, but I think that codepath is a bit less tested). I don't think that hardware raid performance suffers from this size-switching, but I suppose some implementations might. I'm not well-versed in hardware raids. The log does not take up much space at all, maximum 65536 filesystem blocks, or 256M on a 4k block filesystem. Defaults are usually much smaller than this. If the log device fails, you don't lose the whole filesystem, but you will lose any metadata in the log. You could recover by replacing the device, and running xfs_repair -L to zero out the log device and repairing the fallout from the missing log. Not ideal, but it should not be catastrophic. -Eric On Thu, 1 Jan 2004, Jerry Haltom wrote: > Few questions about setting up and using a proper external log: > > I have a system whose only drive is a raid 5 array. I assume putting hte > log on the array itself, on another partition, would be pretty useless, > if the data is on the array also. So, I could put in anohter drive, but > what are the usual redundency requirements for the external log? I > assume if it fails, the entire partition fails also. > > So, one would need two raid setups to use this effectively? How much > data does the log usually use? > > Thanks > > -- > Jerry Haltom > Feedback Plus, Inc. > From owner-linux-xfs@oss.sgi.com Thu Jan 1 10:56:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 10:57:18 -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 i01IuoTa030891 for ; Thu, 1 Jan 2004 10:56:50 -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 KAA01858; Thu, 1 Jan 2004 10:56:53 -0800 Message-Id: <200401011856.KAA01858@amber.he.net> From: "Wvoice" To: "'Eric Sandeen'" , "'Jerry Haltom'" Cc: "'linux-xfs list'" Subject: RE: XFS external log questions Date: Thu, 1 Jan 2004 10:56:54 -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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcPQjjM7gapUnVkBQ4aeiO5JuvsscgACC2mw X-archive-position: 1541 X-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: 3377 Lines: 83 Jerry, If you wish to avoid the recovery method, you can still use an external log with your RAID. If you're using hardware RAID, where the array spans the entire drive, create two partitions on the array (sda1 and sda2, where sda2 is used for the log and is less than 256MB). If you're using software raid, then it's just as easy. Just create a couple of partitions on each drive in the array. You'll then create an md1 stripe across one set of partitions for data and another stripe (md2) on another set of partitions for metadata. You can then use the following: mkfs.xfs -l logdev=/dev/sda2,size=32000b /dev/sda1. You can substitute md1 and md2 accordingly. It won't matter that you're creating a metadata device and a data device on the same physical set of drives. You're still creating a new page buffer for the new logical device and this is where you'll speed up performance. The performance hit of physical disk seeks should be negligible. I've actually benchmarked the difference between putting the journal on other RAID stripes, other raids, fast disks, NVRAM, etc. You really shouldn't notice much difference. Plus, placing the log on another stripe is pretty cheap to do. -Mike -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Eric Sandeen Sent: Thursday, January 01, 2004 9:33 AM To: Jerry Haltom Cc: 'linux-xfs list' Subject: Re: XFS external log questions There are a couple of reasons for using an external log. If there is a dedicated block device for the log, then log writes won't cause the head to seek away from the data, which could speed things up. Of course in a raid this is probably less critical, as the notion of "the head" is a little blurry. Also, log writes are done in sector-sized units, while data writes are done in filesystem block-sized units. In software MD raids, this size-switching is very inefficient. Putting the log on an external device alleviates this (as would setting the sector size equal to the block size, but I think that codepath is a bit less tested). I don't think that hardware raid performance suffers from this size-switching, but I suppose some implementations might. I'm not well-versed in hardware raids. The log does not take up much space at all, maximum 65536 filesystem blocks, or 256M on a 4k block filesystem. Defaults are usually much smaller than this. If the log device fails, you don't lose the whole filesystem, but you will lose any metadata in the log. You could recover by replacing the device, and running xfs_repair -L to zero out the log device and repairing the fallout from the missing log. Not ideal, but it should not be catastrophic. -Eric On Thu, 1 Jan 2004, Jerry Haltom wrote: > Few questions about setting up and using a proper external log: > > I have a system whose only drive is a raid 5 array. I assume putting hte > log on the array itself, on another partition, would be pretty useless, > if the data is on the array also. So, I could put in anohter drive, but > what are the usual redundency requirements for the external log? I > assume if it fails, the entire partition fails also. > > So, one would need two raid setups to use this effectively? How much > data does the log usually use? > > Thanks > > -- > Jerry Haltom > Feedback Plus, Inc. > From owner-linux-xfs@oss.sgi.com Thu Jan 1 17:14:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 17:14:49 -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 i021EOTa008961 for ; Thu, 1 Jan 2004 17:14:25 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021EO4Y008957 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 17:14:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i021EKTs008867 for ; Thu, 1 Jan 2004 17:14:22 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0216drt008814; Thu, 1 Jan 2004 17:06:39 -0800 Date: Thu, 1 Jan 2004 17:06:39 -0800 Message-Id: <200401020106.i0216drt008814@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 261] linux kernel 2.5.73 / xfsprogs 2.3.9 fails on striped devices with 2K block size X-Bugzilla-Reason: AssignedTo X-archive-position: 1545 X-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: 599 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=261 ------- Additional Comments From chrisf@filmlight.ltd.uk 2003-09-07 11:49 PDT ------- Created an attachment (id=85) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=85&action=view) Trace of attempting to create xfs filesystem on a striped 2K block size device ------- Additional Comments From hch@xfs.org 2004-01-01 17:06 PDT ------- Does this still happen with a current 2.6 kernel and recent (2.5.x/2.6.x) xfsprofs? ------- 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 Jan 1 17:14:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 17:14:50 -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 i021EPTa008963 for ; Thu, 1 Jan 2004 17:14:25 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021EOn2008960 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 17:14:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i021EKTw008867 for ; Thu, 1 Jan 2004 17:14:23 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i020cmcd008506; Thu, 1 Jan 2004 16:38:48 -0800 Date: Thu, 1 Jan 2004 16:38:48 -0800 Message-Id: <200401020038.i020cmcd008506@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 298] xfsdump doesn't work on sparc64 linux X-Bugzilla-Reason: AssignedTo X-archive-position: 1547 X-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: 882 Lines: 26 http://oss.sgi.com/bugzilla/show_bug.cgi?id=298 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From hch@xfs.org 2004-01-01 16:38 PDT ------- Your description isn't entirely correct. xfsdump should work on a pure sparc64 system. But you are using a system with a sparc64 kernel and sparc32 userland. For those mixed systems translation routines are needed for all ioctls and these don't exist for XFS yet. I don't think there are plans to implement them currently, but we'll of course accept patches. ------- 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 Jan 1 17:14:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 17:14:49 -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 i021EOTa008949 for ; Thu, 1 Jan 2004 17:14:24 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021EOD3008947 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 17:14:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i021EKTi008867 for ; Thu, 1 Jan 2004 17:14:21 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i020Ldqx008336; Thu, 1 Jan 2004 16:21:39 -0800 Date: Thu, 1 Jan 2004 16:21:39 -0800 Message-Id: <200401020021.i020Ldqx008336@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 301] xfsdump won't compile X-Bugzilla-Reason: AssignedTo X-archive-position: 1544 X-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: 334 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=301 ------- Additional Comments From hch@xfs.org 2004-01-01 16:21 PDT ------- I've checked a fix in. NOTE: it can take up to an hour until this is in public CVS. ------- 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 Jan 1 17:14:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 17:14:49 -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 i021EOTa008955 for ; Thu, 1 Jan 2004 17:14:24 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021EOQe008954 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 17:14:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i021EKTo008867 for ; Thu, 1 Jan 2004 17:14:21 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0218KJl008832; Thu, 1 Jan 2004 17:08:20 -0800 Date: Thu, 1 Jan 2004 17:08:20 -0800 Message-Id: <200401020108.i0218KJl008832@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 273] XFS causes kernel OOPS on unclean reboot. X-Bugzilla-Reason: AssignedTo X-archive-position: 1543 X-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: 357 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=273 ------- Additional Comments From hch@xfs.org 2004-01-01 17:08 PDT ------- Is this still reproducible with a recent XFS (1.3.1, the in-tree code from 2.6./2.4.24-pre or current CVS)? ------- 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 Jan 1 17:14:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 17:14:50 -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 i021EOTa008946 for ; Thu, 1 Jan 2004 17:14:24 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021EOZb008944 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 17:14:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i021EKTg008867 for ; Thu, 1 Jan 2004 17:14:20 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0212vs0008751; Thu, 1 Jan 2004 17:02:57 -0800 Date: Thu, 1 Jan 2004 17:02:57 -0800 Message-Id: <200401020102.i0212vs0008751@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 290] XFS Kernel Memory Leak X-Bugzilla-Reason: AssignedTo X-archive-position: 1546 X-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: 332 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=290 ------- Additional Comments From hch@xfs.org 2004-01-01 17:02 PDT ------- Can you retry with 2.6.1-rc1? It has fixes to better reclaim inodes and dentries. ------- 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 Jan 1 17:14:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 17:14:49 -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 i021EOTa008951 for ; Thu, 1 Jan 2004 17:14:24 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021EODk008948 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 17:14:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i021EKTk008867 for ; Thu, 1 Jan 2004 17:14:21 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i020SCFU008435; Thu, 1 Jan 2004 16:28:12 -0800 Date: Thu, 1 Jan 2004 16:28:12 -0800 Message-Id: <200401020028.i020SCFU008435@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: 1542 X-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: 336 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 ------- Additional Comments From hch@xfs.org 2004-01-01 16:28 PDT ------- This looks like some autoconf incompatiblity. What version of autoconf are you using? ------- 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 Jan 1 18:14:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 18:14:58 -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 i022EOTa021690 for ; Thu, 1 Jan 2004 18:14:24 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i022EOrL021679 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 18:14:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i022EKTi021613 for ; Thu, 1 Jan 2004 18:14:21 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021QFKO011485; Thu, 1 Jan 2004 17:26:15 -0800 Date: Thu, 1 Jan 2004 17:26:15 -0800 Message-Id: <200401020126.i021QFKO011485@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 206] XFS filesysem corruption while umounting sw raid 1 X-Bugzilla-Reason: AssignedTo X-archive-position: 1552 X-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: 393 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=206 ------- Additional Comments From hch@xfs.org 2004-01-01 17:26 PDT ------- There have been a bunch of fixes to make sure everything is synched to disk on umount lately. Can you reproduce your problem with current CVS? ------- 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 Jan 1 18:14:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 18:15:03 -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 i022EUTa021819 for ; Thu, 1 Jan 2004 18:14:30 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i022EUe1021818 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 18:14:30 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i022EKUC021613 for ; Thu, 1 Jan 2004 18:14:28 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021Fk4I009556; Thu, 1 Jan 2004 17:15:46 -0800 Date: Thu, 1 Jan 2004 17:15:46 -0800 Message-Id: <200401020115.i021Fk4I009556@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 219] O_DIRECT io no longer works when the available data size is less than the underlying block-device size? X-Bugzilla-Reason: AssignedTo X-archive-position: 1554 X-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: 591 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=219 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From hch@xfs.org 2004-01-01 17:15 PDT ------- Bugzilla maintaince. Marking WONTFIX because it's a common code issue. ------- 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 Jan 1 18:14:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 18:14: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 i022EOTa021691 for ; Thu, 1 Jan 2004 18:14:24 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i022EO40021685 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 18:14:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i022EKTo021613 for ; Thu, 1 Jan 2004 18:14:22 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021Kcbu011381; Thu, 1 Jan 2004 17:20:38 -0800 Date: Thu, 1 Jan 2004 17:20:38 -0800 Message-Id: <200401020120.i021Kcbu011381@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 214] filesystem lockup X-Bugzilla-Reason: AssignedTo X-archive-position: 1551 X-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: 447 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=214 ------- Additional Comments From hch@xfs.org 2004-01-01 17:20 PDT ------- Steve had seen something like this because of a bug in ext3 / buffercache interaction in mixed systems, and submitted a fix for this some time ago. Could you please retry with 2.4.24-pre (or 2.6)? ------- 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 Jan 1 18:14:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 18:14:55 -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 i022EOTa021689 for ; Thu, 1 Jan 2004 18:14:24 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i022EOAg021683 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 18:14:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i022EKTm021613 for ; Thu, 1 Jan 2004 18:14:22 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021LZEj011405; Thu, 1 Jan 2004 17:21:35 -0800 Date: Thu, 1 Jan 2004 17:21:35 -0800 Message-Id: <200401020121.i021LZEj011405@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 222] file truncation after fsync() and following reset. X-Bugzilla-Reason: AssignedTo X-archive-position: 1548 X-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: 398 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=222 ------- Additional Comments From hch@xfs.org 2004-01-01 17:21 PDT ------- Closing this bug as the XFS sync code has been rewritten to deal with issues like this. Please reopen if you still see it with 1.3.1 or current CVS ------- 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 Jan 1 18:14:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 18:14:55 -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 i022ENTa021674 for ; Thu, 1 Jan 2004 18:14:23 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i022EN59021673 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 18:14:23 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i022EKTc021613 for ; Thu, 1 Jan 2004 18:14:20 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021MI4x011445; Thu, 1 Jan 2004 17:22:18 -0800 Date: Thu, 1 Jan 2004 17:22:18 -0800 Message-Id: <200401020122.i021MI4x011445@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 225] thread deadlock on full fs. X-Bugzilla-Reason: AssignedTo X-archive-position: 1550 X-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: 294 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=225 ------- Additional Comments From hch@xfs.org 2004-01-01 17:22 PDT ------- Does this still happen with recent XFS code? ------- 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 Jan 1 18:14:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 18:15:04 -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 i022EVTa021831 for ; Thu, 1 Jan 2004 18:14:31 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i022EUqg021823 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 18:14:30 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i022EKUG021613 for ; Thu, 1 Jan 2004 18:14:29 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021HLux010003; Thu, 1 Jan 2004 17:17:21 -0800 Date: Thu, 1 Jan 2004 17:17:21 -0800 Message-Id: <200401020117.i021HLux010003@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 266] Redhat8: NFS transfers lockup server X-Bugzilla-Reason: AssignedTo X-archive-position: 1555 X-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: 687 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=266 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From hch@xfs.org 2004-01-01 17:17 PDT ------- Bugzilla maintaince: Marking invalid because it appears to not be an XFS issue. Please reopen if it still happens with a recent tg3 driver (and a recent XFS codebase) ------- 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 Jan 1 18:14:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 18:14:55 -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 i022EOTa021686 for ; Thu, 1 Jan 2004 18:14:24 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i022EO3t021681 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 18:14:24 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i022EKTg021613 for ; Thu, 1 Jan 2004 18:14:21 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021TOth011527; Thu, 1 Jan 2004 17:29:24 -0800 Date: Thu, 1 Jan 2004 17:29:24 -0800 Message-Id: <200401020129.i021TOth011527@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 255] 2.5.72: kernel BUG at fs/xfs/pagebuf/page_buf.c:1288 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: 379 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=255 ------- Additional Comments From hch@xfs.org 2004-01-01 17:29 PDT ------- Closing the bug as this his should have been fixed for a while. Please reopen if you can still reproduce it with 2.6.0 or newer. ------- 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 Jan 1 18:14:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 18:14:55 -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 i022ETTa021805 for ; Thu, 1 Jan 2004 18:14:29 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i022ETk9021804 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 18:14:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i022EKUA021613 for ; Thu, 1 Jan 2004 18:14:28 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021ROZA011501; Thu, 1 Jan 2004 17:27:24 -0800 Date: Thu, 1 Jan 2004 17:27:24 -0800 Message-Id: <200401020127.i021ROZA011501@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 205] make install fails to properly symlink and copy the libraries X-Bugzilla-Reason: AssignedTo X-archive-position: 1549 X-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: 626 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=205 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID ------- Additional Comments From hch@xfs.org 2004-01-01 17:27 PDT ------- Closing this bug. The xfs userland uses autoconf in a slightly 'creative' way, but that's a feature (TM). ------- 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 Jan 1 18:14:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 18:14:58 -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 i022ESTa021765 for ; Thu, 1 Jan 2004 18:14:28 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i022ESIT021761 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 18:14:28 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i022EKU4021613 for ; Thu, 1 Jan 2004 18:14:26 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021OWPV011475; Thu, 1 Jan 2004 17:24:32 -0800 Date: Thu, 1 Jan 2004 17:24:32 -0800 Message-Id: <200401020124.i021OWPV011475@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 254] Bootloader X-Bugzilla-Reason: AssignedTo X-archive-position: 1553 X-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: 652 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=254 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From hch@xfs.org 2004-01-01 17:24 PDT ------- This doesn't really look like a XFS problem. Feel free to ask on the linux-xfs for RedHat / XFS / grub interaction problems though. ------- 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 Jan 1 18:14:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 18:14:55 -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 i022ERTa021759 for ; Thu, 1 Jan 2004 18:14:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i022ERdW021756 for linux-xfs@oss.sgi.com; Thu, 1 Jan 2004 18:14:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i022EKU0021613 for ; Thu, 1 Jan 2004 18:14:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i021JLRq010913; Thu, 1 Jan 2004 17:19:21 -0800 Date: Thu, 1 Jan 2004 17:19:21 -0800 Message-Id: <200401020119.i021JLRq010913@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: 1548 X-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: 594 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=209 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From hch@xfs.org 2004-01-01 17:19 PDT ------- Closing this bug as it seems to be fixed in recent Kernel / XFS combinations ------- 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 Jan 1 20:16:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 20:17:11 -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 i024GgTa018711 for ; Thu, 1 Jan 2004 20:16:43 -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 i024GV7x014384 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 1 Jan 2004 23:16:34 -0500 Message-ID: <3FF4F09F.20609@coplanar.net> Date: Thu, 01 Jan 2004 23:16:31 -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: Jerry Haltom CC: "'linux-xfs list'" Subject: Re: XFS external log questions References: <1072972834.2956.2.camel@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1556 X-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: 672 Lines: 22 Jerry Haltom wrote: > Few questions about setting up and using a proper external log: > > I have a system whose only drive is a raid 5 array. I assume putting hte > log on the array itself, on another partition, would be pretty useless, > if the data is on the array also. So, I could put in anohter drive, but > what are the usual redundency requirements for the external log? I > assume if it fails, the entire partition fails also. > > So, one would need two raid setups to use this effectively? How much > data does the log usually use? > > Thanks > I would suggest a small, fast (15k rpm - 9G) raid1 array for redundancy and good performance. Cheers, Jeremy From owner-linux-xfs@oss.sgi.com Thu Jan 1 20:18:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Jan 2004 20:19: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 i024ItTa018993 for ; Thu, 1 Jan 2004 20:18:56 -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 i024Ii7x014399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 1 Jan 2004 23:18:49 -0500 Message-ID: <3FF4F124.1080407@coplanar.net> Date: Thu, 01 Jan 2004 23:18:44 -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: Wvoice CC: "'Jerry Haltom'" , "'linux-xfs list'" Subject: Re: XFS external log questions References: <200401011856.KAA01858@amber.he.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1557 X-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: 1381 Lines: 31 Wvoice wrote: > Jerry, > > If you wish to avoid the recovery method, you can still use an external log > with your RAID. If you're using hardware RAID, where the array spans the > entire drive, create two partitions on the array (sda1 and sda2, where sda2 > is used for the log and is less than 256MB). If you're using software raid, > then it's just as easy. Just create a couple of partitions on each drive in > the array. You'll then create an md1 stripe across one set of partitions > for data and another stripe (md2) on another set of partitions for metadata. > > You can then use the following: mkfs.xfs -l logdev=/dev/sda2,size=32000b > /dev/sda1. You can substitute md1 and md2 accordingly. > > It won't matter that you're creating a metadata device and a data device on > the same physical set of drives. You're still creating a new page buffer > for the new logical device and this is where you'll speed up performance. > The performance hit of physical disk seeks should be negligible. I've > actually benchmarked the difference between putting the journal on other > RAID stripes, other raids, fast disks, NVRAM, etc. You really shouldn't > notice much difference. Plus, placing the log on another stripe is pretty > cheap to do. How did you test this... lots of metadata writes? I can't believe this is a good idea for performance. Regards, Jeremy From owner-linux-xfs@oss.sgi.com Fri Jan 2 06:14:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15: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 i02EEXTa008144 for ; Fri, 2 Jan 2004 06:14:33 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EEW6l008135 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14: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 i02EENU6007980 for ; Fri, 2 Jan 2004 06:14:31 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02DVQe0007427; Fri, 2 Jan 2004 05:31:26 -0800 Date: Fri, 2 Jan 2004 05:31:26 -0800 Message-Id: <200401021331.i02DVQe0007427@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 260] excessive swapping X-Bugzilla-Reason: AssignedTo X-archive-position: 1564 X-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: 585 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=260 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From hch@xfs.org 2004-02-01 05:31 PDT ------- Marking as invalid. XFS isn't doing VM balancing policy changes. ------- 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 Jan 2 06:14:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15:08 -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 i02EERTa008025 for ; Fri, 2 Jan 2004 06:14:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EERLX008023 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02EENTk007980 for ; Fri, 2 Jan 2004 06:14:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02DRc2e007133; Fri, 2 Jan 2004 05:27:38 -0800 Date: Fri, 2 Jan 2004 05:27:38 -0800 Message-Id: <200401021327.i02DRc2e007133@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 277] xfs_force_shutdown after kernel bug X-Bugzilla-Reason: AssignedTo X-archive-position: 1563 X-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: 313 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=277 ------- Additional Comments From hch@xfs.org 2004-02-01 05:27 PDT ------- Looks like there were no follups to this. Is this reproduible? ------- 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 Jan 2 06:14:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15: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 i02EEVTa008121 for ; Fri, 2 Jan 2004 06:14:31 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EEVDG008108 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14: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 i02EENTw007980 for ; Fri, 2 Jan 2004 06:14:29 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02DOjnx006982; Fri, 2 Jan 2004 05:24:45 -0800 Date: Fri, 2 Jan 2004 05:24:45 -0800 Message-Id: <200401021324.i02DOjnx006982@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: 1558 X-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: 420 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=286 ------- Additional Comments From hch@xfs.org 2004-02-01 05:24 PDT ------- This absolutely shouldn't happen an I can't see anything in XFS code leading to this OOPS. What kernel versions is this and do you have some patches applied to the tree? ------- 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 Jan 2 06:14:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15: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 i02EEUTa008080 for ; Fri, 2 Jan 2004 06:14:30 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EEUO9008070 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14:30 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02EENTq007980 for ; Fri, 2 Jan 2004 06:14:28 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02DU91T007409; Fri, 2 Jan 2004 05:30:09 -0800 Date: Fri, 2 Jan 2004 05:30:09 -0800 Message-Id: <200401021330.i02DU91T007409@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 1560 X-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: 366 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 ------- Additional Comments From hch@xfs.org 2004-02-01 05:30 PDT ------- Does this still happen? And if yes can you run xfs_check on the filesystem to check whether there's any corruption? ------- 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 Jan 2 06:14:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15: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 i02EEZTa008210 for ; Fri, 2 Jan 2004 06:14:35 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EEZem008207 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14:35 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02EENUE007980 for ; Fri, 2 Jan 2004 06:14:33 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02E1XEJ007778; Fri, 2 Jan 2004 06:01:33 -0800 Date: Fri, 2 Jan 2004 06:01:33 -0800 Message-Id: <200401021401.i02E1XEJ007778@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 233] Close system call hangs on creating large files on XFS partition X-Bugzilla-Reason: AssignedTo X-archive-position: 1571 X-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: 605 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=233 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From hch@xfs.org 2004-02-01 06:01 PDT ------- Marking as fixed because the testcase is no more reproducible with current XFS sources. ------- 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 Jan 2 06:14:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15:20 -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 i02EEbTa008257 for ; Fri, 2 Jan 2004 06:14:37 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EEbH5008256 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14:37 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02EENUM007980 for ; Fri, 2 Jan 2004 06:14:35 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02E0BSl007767; Fri, 2 Jan 2004 06:00:11 -0800 Date: Fri, 2 Jan 2004 06:00:11 -0800 Message-Id: <200401021400.i02E0BSl007767@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 245] Cannot get type of dirent X-Bugzilla-Reason: AssignedTo X-archive-position: 1568 X-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: 734 Lines: 24 http://oss.sgi.com/bugzilla/show_bug.cgi?id=245 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From hch@xfs.org 2004-02-01 06:00 PDT ------- The directory entry types are an optional feature and only supported by very few filesystems, you application must have a fallback like stating all filenames. There are currently no plans to implement this in XFS. ------- 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 Jan 2 06:14:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15: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 i02EEWTa008124 for ; Fri, 2 Jan 2004 06:14:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EEVhK008120 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14: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 i02EENU2007980 for ; Fri, 2 Jan 2004 06:14:30 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02DvAOo007729; Fri, 2 Jan 2004 05:57:10 -0800 Date: Fri, 2 Jan 2004 05:57:10 -0800 Message-Id: <200401021357.i02DvAOo007729@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 301] xfsdump won't compile X-Bugzilla-Reason: AssignedTo X-archive-position: 1561 X-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: 561 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=301 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From hch@xfs.org 2004-02-01 05:57 PDT ------- Should have closed this yesterday already.. ------- 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 Jan 2 06:14:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15:20 -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 i02EEcTa008264 for ; Fri, 2 Jan 2004 06:14:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EEcOa008260 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14: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 i02EENUO007980 for ; Fri, 2 Jan 2004 06:14:36 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02DNOLD006968; Fri, 2 Jan 2004 05:23:24 -0800 Date: Fri, 2 Jan 2004 05:23:24 -0800 Message-Id: <200401021323.i02DNOLD006968@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 293] mount process crashes while replaying transaction log X-Bugzilla-Reason: AssignedTo X-archive-position: 1569 X-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: 968 Lines: 29 http://oss.sgi.com/bugzilla/show_bug.cgi?id=293 ------- Additional Comments From rlewczuk@pronet.pl 2003-28-11 04:59 PDT ------- Created an attachment (id=91) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=91&action=view) Full kernel configuration. Full kernel configuration on machine I've tested it. Kernel is a bit changed from deault: supports up to 512 groups per user, has Qlogic QLA2300 and Intel E1000 drivers. I can try to compile kernel statically and repeat it if asked, but I suspect it is a reproductible bug (at least always reproduces in my configuration). ------- Additional Comments From hch@xfs.org 2004-02-01 05:23 PDT ------- To debug this we'd really need the decoded symbols. If you still have the System.map for that kernel run ksymoops over it - it's decoding is much better than that in sysklogd anyway. ------- 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 Jan 2 06:14:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15:20 -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 i02EEZTa008213 for ; Fri, 2 Jan 2004 06:14:35 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EEZaT008209 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14:35 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02EENUG007980 for ; Fri, 2 Jan 2004 06:14:34 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02DsLVh007697; Fri, 2 Jan 2004 05:54:21 -0800 Date: Fri, 2 Jan 2004 05:54:21 -0800 Message-Id: <200401021354.i02DsLVh007697@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 246] ooops report 2.4.20-xfs-CVS-2003-02-21_06:00_UTC X-Bugzilla-Reason: AssignedTo X-archive-position: 1567 X-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: 632 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=246 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From hch@xfs.org 2004-02-01 05:54 PDT ------- Marking worksforme because not reproducible here and the submitter hasn't answered for more than half a year. ------- 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 Jan 2 06:14:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15:20 -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 i02EEeTa008292 for ; Fri, 2 Jan 2004 06:14:40 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EEefE008291 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14: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 i02EENUU007980 for ; Fri, 2 Jan 2004 06:14:38 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02DZXts007473; Fri, 2 Jan 2004 05:35:33 -0800 Date: Fri, 2 Jan 2004 05:35:33 -0800 Message-Id: <200401021335.i02DZXts007473@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 302] New: DMAPI conditional build broken in linux-2.6-xfs tree from 20040101 X-Bugzilla-Reason: AssignedTo X-archive-position: 1570 X-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: 1101 Lines: 35 http://oss.sgi.com/bugzilla/show_bug.cgi?id=302 Summary: DMAPI conditional build broken in linux-2.6-xfs tree from 20040101 Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: dmapi AssignedTo: xfs-master@oss.sgi.com ReportedBy: misiek@dione.ids.pl Pasted from #xfs 14:29 < arekm> there is bug in current linux-2.6-xfs tree. DMAPI can be changed via Makefile now but there is still one unconditional in fs/xfs/xfs_vfsops.c 14:29 < arekm> p = vfs_bhv_lookup(vfsp, VFS_POSITION_DM); 14:29 < arekm> mp->m_dm_ops = p ? *(xfs_dmops_t *) vfs_bhv_custom(p) : xfs_dmcore_xfs; 14:29 < arekm> so it won't work when someone disables DMAPI... 14:30 < arekm> ie. for modular built there will be unresolved symbol xfs_dmcore_xfs Fix is to ifdef that code. ------- 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 Jan 2 06:14:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15: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 i02EEVTa008106 for ; Fri, 2 Jan 2004 06:14:31 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EEVhQ008104 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14: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 i02EENTu007980 for ; Fri, 2 Jan 2004 06:14:29 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02E6vuw007851; Fri, 2 Jan 2004 06:06:57 -0800 Date: Fri, 2 Jan 2004 06:06:57 -0800 Message-Id: <200401021406.i02E6vuw007851@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 178] NFSD and 2.4.19+xfs-1.2pre problem X-Bugzilla-Reason: AssignedTo X-archive-position: 1562 X-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: 398 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=178 ------- Additional Comments From hch@xfs.org 2004-02-01 06:06 PDT ------- This looks rather like a nfsd bug to me. anyway, is this reproducible with a current kernel + current XFS (say 2.4.24-pre to make it easy for you)? ------- 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 Jan 2 06:14:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15:08 -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 i02EERTa008022 for ; Fri, 2 Jan 2004 06:14:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EERGe008020 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02EENTe007980 for ; Fri, 2 Jan 2004 06:14:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02DuBMf007711; Fri, 2 Jan 2004 05:56:11 -0800 Date: Fri, 2 Jan 2004 05:56:11 -0800 Message-Id: <200401021356.i02DuBMf007711@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 196] 2.4.18 oops after lvextend X-Bugzilla-Reason: AssignedTo X-archive-position: 1565 X-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: 297 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=196 ------- Additional Comments From hch@xfs.org 2004-02-01 05:56 PDT ------- Is this still happening with a recent XFS tree? ------- 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 Jan 2 06:14:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15: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 i02EERTa008029 for ; Fri, 2 Jan 2004 06:14:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EERYw008026 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02EENTg007980 for ; Fri, 2 Jan 2004 06:14:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02DrUvi007681; Fri, 2 Jan 2004 05:53:30 -0800 Date: Fri, 2 Jan 2004 05:53:30 -0800 Message-Id: <200401021353.i02DrUvi007681@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 259] xfs_freeze gets stuck in "D" state in the function "down" X-Bugzilla-Reason: AssignedTo X-archive-position: 1566 X-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: 267 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=259 ------- Additional Comments From hch@xfs.org 2004-02-01 05:53 PDT ------- Marking as fixed. ------- 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 Jan 2 06:14:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 06:15: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 i02EEYTa008186 for ; Fri, 2 Jan 2004 06:14:34 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EEYia008184 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 06:14: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 i02EENUA007980 for ; Fri, 2 Jan 2004 06:14:32 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02E3a5N007824; Fri, 2 Jan 2004 06:03:36 -0800 Date: Fri, 2 Jan 2004 06:03:36 -0800 Message-Id: <200401021403.i02E3a5N007824@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 194] xfs internal log errors X-Bugzilla-Reason: AssignedTo X-archive-position: 1559 X-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: 606 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=194 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From hch@xfs.org 2004-02-01 06:03 PDT ------- I can't reproeduce this here, please reopen if you still see this with current CVS. ------- 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 Jan 2 07:14:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 07:14:52 -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 i02FERTa014877 for ; Fri, 2 Jan 2004 07:14:28 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02FERrU014874 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 07:14:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02FEOTo014818 for ; Fri, 2 Jan 2004 07:14:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02EFsnm009274; Fri, 2 Jan 2004 06:15:54 -0800 Date: Fri, 2 Jan 2004 06:15:54 -0800 Message-Id: <200401021415.i02EFsnm009274@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: 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: 1053 Lines: 29 http://oss.sgi.com/bugzilla/show_bug.cgi?id=294 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2003-11-12 08:51 PDT ------- Created an attachment (id=93) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=93&action=view) oops-pcitose1-xfsqa13debug I finally managed to get an XFS debug-enabled kernel. See attachment for kernel messages while executing QA013, and a final oops at the end when the test war trying to umount the filesystem. In case you ask, memtest86 didn't find anything and the machine otherwise behaves normally, nothing else is affected but XFS. I have it dedicated for further test and the filesystem image in question is still available (it's on the disk untouched). ------- Additional Comments From hch@xfs.org 2004-02-01 06:15 PDT ------- Does this happen without AFS loaded? AFS does some rather nasty things with kernel interfaces and has caused some problems with XFS in the past.. ------- 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 Jan 2 07:14:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 07:14:52 -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 i02FERTa014875 for ; Fri, 2 Jan 2004 07:14:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02FERrR014870 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 07:14:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02FEOTg014818 for ; Fri, 2 Jan 2004 07:14:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02ERCXq013873; Fri, 2 Jan 2004 06:27:12 -0800 Date: Fri, 2 Jan 2004 06:27:12 -0800 Message-Id: <200401021427.i02ERCXq013873@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 283] kernel-source-2.4.20-20.9.XFS1.3.1.i386.rpm fails to compile X-Bugzilla-Reason: AssignedTo X-archive-position: 1572 X-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: 776 Lines: 25 http://oss.sgi.com/bugzilla/show_bug.cgi?id=283 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From hch@xfs.org 2004-02-01 06:27 PDT ------- This looks like a bad interaction from the kdb kallsysms that's in the XFS patches and the redhat kallsysm for kksymoops. I'll mark this as Wontfix because that kernel is old and has know security holes, please use the newer XFS+RH kernelrpms from atrpms. ------- 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 Jan 2 07:14:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 07:14:52 -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 i02FERTa014876 for ; Fri, 2 Jan 2004 07:14:28 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02FERQT014873 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 07:14:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02FEOTk014818 for ; Fri, 2 Jan 2004 07:14:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02Eoph6014147; Fri, 2 Jan 2004 06:50:51 -0800 Date: Fri, 2 Jan 2004 06:50:51 -0800 Message-Id: <200401021450.i02Eoph6014147@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 302] DMAPI conditional build broken in linux-2.6-xfs tree from 20040101 X-Bugzilla-Reason: AssignedTo X-archive-position: 2 X-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: 840 Lines: 28 http://oss.sgi.com/bugzilla/show_bug.cgi?id=302 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From hch@xfs.org 2004-02-01 06:50 PDT ------- There's two defintions of xfs_dmcore_xfs, one it only built into the kernel if CONFIG_XFS_DMAPI is set and one if not: dmapi/dmapi_xfs.c:xfs_dmops_t xfs_dmcore_xfs = { xfs_dmops.c:xfs_dmops_t xfs_dmcore_xfs = { And surprisingly the build works without dmapi for me. The code in that area is more than ugly, though.. ------- 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 Jan 2 07:14:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 07:14:52 -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 i02FERTa014878 for ; Fri, 2 Jan 2004 07:14:28 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02FERfg014869 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 07:14:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02FEOTc014818 for ; Fri, 2 Jan 2004 07:14:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02F1mhT014502; Fri, 2 Jan 2004 07:01:48 -0800 Date: Fri, 2 Jan 2004 07:01:48 -0800 Message-Id: <200401021501.i02F1mhT014502@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 297] snapshot-2.4.23-2003-12-01_00:33_UTC quota options problem X-Bugzilla-Reason: AssignedTo X-archive-position: 1572 X-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: 715 Lines: 26 http://oss.sgi.com/bugzilla/show_bug.cgi?id=297 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From hch@xfs.org 2004-02-01 07:01 PDT ------- Mounting with -o quota works for me here, (CVS as of today). Note that xfs_parseargs must not support quota options because the code in xfs_qm_bh.c already parsed them. Closing as Worksforme ------- 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 Jan 2 08:14:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 08:14: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 i02GEUTa018974 for ; Fri, 2 Jan 2004 08:14:30 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02GEUns018972 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 08:14:30 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02GENTc018930 for ; Fri, 2 Jan 2004 08:14:23 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02FZhPZ018078; Fri, 2 Jan 2004 07:35:43 -0800 Date: Fri, 2 Jan 2004 07:35:43 -0800 Message-Id: <200401021535.i02FZhPZ018078@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 196] 2.4.18 oops after lvextend X-Bugzilla-Reason: AssignedTo X-archive-position: 1574 X-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: 529 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=196 dm@belkam.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From dm@belkam.com 2004-02-01 07:35 PDT ------- No! :-) ------- 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 Jan 2 08:14:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 08:14: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 i02GEUTa018975 for ; Fri, 2 Jan 2004 08:14:30 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02GEU4O018971 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 08:14:30 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02GENTg018930 for ; Fri, 2 Jan 2004 08:14:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02FWHTp018031; Fri, 2 Jan 2004 07:32:17 -0800 Date: Fri, 2 Jan 2004 07:32:17 -0800 Message-Id: <200401021532.i02FWHTp018031@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 1573 X-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: 1265 Lines: 30 http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 ------- Additional Comments From walt_holman@generalplastics.com 2004-02-01 07:32 PDT ------- Sorry, can't test this server anymore. I've since converted its filesystems to ext3. That seems to be more reliable on this hardware. When this problem last occurred, the system had been running approximately 3 weeks since the last occurrence. In an attempt to catch corruptions earlier, I had been unmounting it's filesystems weekly and running xfs_check on them. No errors were ever reported. This particular problem would surface out of the blue with no irregular behaviour apparent. I've got a dhcp, dns, squid proxy server still using XFS and it's rock solid. It's a P3 based setup, however. Perhaps there's a strange interaction taking place on Athlon based setups? Since converting the filesystems to ext3, the box has been up with no problem to report. When I was experiencing the problems on this box, and xfs_check afterward always showed minimal corruption. Most (>90%) of the time, the xfs_repair process would junk the root inode, but recovery was easy. A bit scary, to be sure. ------- 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 Jan 2 08:14:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 08:14:55 -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 i02GEUTa018973 for ; Fri, 2 Jan 2004 08:14:30 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02GEU8r018970 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 08:14:30 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02GENTk018930 for ; Fri, 2 Jan 2004 08:14:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02FOPiD017908; Fri, 2 Jan 2004 07:24:25 -0800 Date: Fri, 2 Jan 2004 07:24:25 -0800 Message-Id: <200401021524.i02FOPiD017908@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 302] DMAPI conditional build broken in linux-2.6-xfs tree from 20040101 X-Bugzilla-Reason: AssignedTo X-archive-position: 1573 X-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: 1734 Lines: 45 http://oss.sgi.com/bugzilla/show_bug.cgi?id=302 misiek@dione.ids.pl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From misiek@dione.ids.pl 2004-02-01 07:24 PDT ------- I'm talking about linux-2.6-xfs tree at sgi.com [misiek@arm ~/.CVS-OTHER/linux-2.6-xfs/linux/fs/xfs]$ grep -r xfs_dmcore_xfs . ./xfs_mount.h:extern struct xfs_dmops xfs_dmcore_xfs; ./xfs_vfsops.c: mp->m_dm_ops = p ? *(xfs_dmops_t *) vfs_bhv_custom(p) : xfs_dmcore_xfs; ./dmapi/dmapi_xfs.c:xfs_dmops_t xfs_dmcore_xfs = { ./dmapi/dmapi_xfs.c: vfs_bhv_set_custom(&xfs_dmops, &xfs_dmcore_xfs); ./xfs_dmops.c:xfs_dmops_t xfs_dmcore_xfs = { [misiek@arm ~/.CVS-OTHER/linux-2.6-xfs/linux/fs/xfs]$ cat CVS/Root :pserver:cvs@oss.sgi.com:/cvs xfs_vfsopts.c has: /* * Setup xfs_mount function vectors from available behaviors */ p = vfs_bhv_lookup(vfsp, VFS_POSITION_DM); mp->m_dm_ops = p ? *(xfs_dmops_t *) vfs_bhv_custom(p) : xfs_dmcore_xfs; p = vfs_bhv_lookup(vfsp, VFS_POSITION_QM); mp->m_qm_ops = p ? *(xfs_qmops_t *) vfs_bhv_custom(p) : xfs_qmcore_xfs; p = vfs_bhv_lookup(vfsp, VFS_POSITION_IO); mp->m_io_ops = p ? *(xfs_ioops_t *) vfs_bhv_custom(p) : xfs_iocore_xfs; (xfs in vanilla 2.6.1rc1 doesn't have security xattr support so anyone who want's use xfs with SELinux needs SGI CVS version + small security xattr patch). ------- 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 Jan 2 08:26:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 08:27:14 -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 i02GQgTa023042 for ; Fri, 2 Jan 2004 08:26:42 -0800 Received: from localhost (localhost [127.0.0.1]) by jack.feedbackplusinc.com (Postfix) with ESMTP id D377B8FD93; Fri, 2 Jan 2004 10:26:33 -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 11667-02; Fri, 2 Jan 2004 10:26:21 -0600 (CST) Received: from [10.0.0.16] (unknown [10.0.0.16]) by jack.feedbackplusinc.com (Postfix) with ESMTP id 435F08FCD0; Fri, 2 Jan 2004 10:25:51 -0600 (CST) Subject: Re: XFS external log questions From: Jerry Haltom To: Jeremy Jackson Cc: Wvoice , "'linux-xfs list'" In-Reply-To: <3FF4F124.1080407@coplanar.net> References: <200401011856.KAA01858@amber.he.net> <3FF4F124.1080407@coplanar.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+P4DAqidzJRcvjLyT8dI" Organization: Feedback Plus, Inc. Message-Id: <1073060750.8655.4.camel@station-1> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 02 Jan 2004 10:25:51 -0600 X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at feedbackplusinc.com X-archive-position: 1574 X-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: 2274 Lines: 73 --=-+P4DAqidzJRcvjLyT8dI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable And here is exactly why I asked the question! Good discussion. :) I thought about putting it on a seperate partition, like Wvoice has, but couldn't figure out why there would be a performance benefit. :) On Thu, 2004-01-01 at 22:18, Jeremy Jackson wrote: > Wvoice wrote: > > Jerry, > >=20 > > If you wish to avoid the recovery method, you can still use an external= log > > with your RAID. If you're using hardware RAID, where the array spans t= he > > entire drive, create two partitions on the array (sda1 and sda2, where = sda2 > > is used for the log and is less than 256MB). If you're using software = raid, > > then it's just as easy. Just create a couple of partitions on each dri= ve in > > the array. You'll then create an md1 stripe across one set of partitio= ns > > for data and another stripe (md2) on another set of partitions for meta= data. > >=20 > > You can then use the following: mkfs.xfs -l logdev=3D/dev/sda2,size=3D3= 2000b > > /dev/sda1. You can substitute md1 and md2 accordingly. > >=20 > > It won't matter that you're creating a metadata device and a data devic= e on > > the same physical set of drives. You're still creating a new page buff= er > > for the new logical device and this is where you'll speed up performanc= e. > > The performance hit of physical disk seeks should be negligible. I've > > actually benchmarked the difference between putting the journal on other > > RAID stripes, other raids, fast disks, NVRAM, etc. You really shouldn't > > notice much difference. Plus, placing the log on another stripe is pre= tty > > cheap to do. >=20 >=20 > How did you test this... lots of metadata writes? I can't believe this= =20 > is a good idea for performance. >=20 > Regards, >=20 > Jeremy --=20 Jerry Haltom Feedback Plus, Inc. --=-+P4DAqidzJRcvjLyT8dI 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/9ZuKRTZ5+YJ1b+YRAllwAJ9+KVoNfRiK+J3+ooqUIgrudbWRogCgymKp MaZtINMyyuZXNcuJxbRnKBI= =Ep6d -----END PGP SIGNATURE----- --=-+P4DAqidzJRcvjLyT8dI-- From owner-linux-xfs@oss.sgi.com Fri Jan 2 09:04:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 09:04:56 -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 i02H4XTa023868 for ; Fri, 2 Jan 2004 09:04:33 -0800 Received: from mikesx31 (wbar2.sjo1-4-4-027-050.sjo1.dsl-verizon.net [4.4.27.50]) by amber.he.net (8.8.6p2003-03-31/8.8.2) with ESMTP id JAA22502; Fri, 2 Jan 2004 09:04:34 -0800 Message-Id: <200401021704.JAA22502@amber.he.net> From: "Wvoice" To: "'Jerry Haltom'" Cc: "'linux-xfs list'" Subject: RE: XFS external log questions Date: Fri, 2 Jan 2004 09:04:48 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001E_01C3D10F.792CA730" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1073060750.8655.4.camel@station-1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcPRTVG0aMeOxclvS+GMVJ6m4MgSpgAAwIGg X-archive-position: 1575 X-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: 32119 Lines: 574 This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C3D10F.792CA730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jerry, Jeremy is right about placing data on a separate array for increased performance. If you want the best, then I'd place it on an NVRAM device. I did say that the performance is negligible. This doesn't mean that there isn't any benefit. It just means I wouldn't pay the extra price for what little is gained. I've attached a single page excerpt from some of the testing I've done in the past. The server is a dual 2.0GHz Xeon. The client is a single 2.4GHz Xeon. The OS was RedHat 9.0 with a new 2.4.20 kernel and XFS. In this specific case, I used md RAID on 11 10K RPM Seagate FC drives. The lower performance line created a single array and used an internal log. The top line took the same 11 drives and created one 256MB RAID for metadata and the rest of the drives was arrayed for data. Both RAIDs used RAID-5 on the same physical, shared disks. The point of all this was to address the initial question of whether or not to use an external log on another partition. I'm not trying to tell you how to design the fastest possible system. Economics are sometimes a factor. However, you can expect some very definite performance gains over your default config. Your call. -Mike -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Jerry Haltom Sent: Friday, January 02, 2004 8:26 AM To: Jeremy Jackson Cc: Wvoice; 'linux-xfs list' Subject: Re: XFS external log questions And here is exactly why I asked the question! Good discussion. :) I thought about putting it on a seperate partition, like Wvoice has, but couldn't figure out why there would be a performance benefit. :) On Thu, 2004-01-01 at 22:18, Jeremy Jackson wrote: > Wvoice wrote: > > Jerry, > > > > If you wish to avoid the recovery method, you can still use an external log > > with your RAID. If you're using hardware RAID, where the array spans the > > entire drive, create two partitions on the array (sda1 and sda2, where sda2 > > is used for the log and is less than 256MB). If you're using software raid, > > then it's just as easy. Just create a couple of partitions on each drive in > > the array. You'll then create an md1 stripe across one set of partitions > > for data and another stripe (md2) on another set of partitions for metadata. > > > > You can then use the following: mkfs.xfs -l logdev=/dev/sda2,size=32000b > > /dev/sda1. You can substitute md1 and md2 accordingly. > > > > It won't matter that you're creating a metadata device and a data device on > > the same physical set of drives. You're still creating a new page buffer > > for the new logical device and this is where you'll speed up performance. > > The performance hit of physical disk seeks should be negligible. I've > > actually benchmarked the difference between putting the journal on other > > RAID stripes, other raids, fast disks, NVRAM, etc. You really shouldn't > > notice much difference. Plus, placing the log on another stripe is pretty > > cheap to do. > > > How did you test this... lots of metadata writes? I can't believe this > is a good idea for performance. > > Regards, > > Jeremy -- Jerry Haltom Feedback Plus, Inc. ------=_NextPart_000_001E_01C3D10F.792CA730 Content-Type: application/vnd.ms-excel; name="raid_partitions.xls" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="raid_partitions.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB AAAAJAAAAAAAAAAAEAAAJgAAAAEAAAD+////AAAAACUAAAD///////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////8JCBAAAAYFAOwVzQfBwAAABgMAAOEAAgCwBMEA AgAAAOIAAABcAHAACgAATWlrZSBZb3VuZyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAA AMABAAA9AQIAAQCcAAIADgAZAAIAAAASAAIAAAATAAIAAACvAQIAAAC8AQIA AAA9ABIAeAAtAEw7hCE4AAAAAAABAFgCQAACAAAAjQACAAAAIgACAAAADgAC AAEAtwECAAAA2gACAAAAMQAeAMgAAAD/f5ABAAAAAABWBwFWAGUAcgBkAGEA bgBhADEAHgDIAAEA/3+8AgAAAAAAVgcBVgBlAHIAZABhAG4AYQAxAB4AyAAC AP9/kAEAAAAAAFYHAVYAZQByAGQAYQBuAGEAMQAeAMgAAwD/f7wCAAAAAABW BwFWAGUAcgBkAGEAbgBhADEAHgDIAAAA/3+QAQAAAAAAVgcBVgBlAHIAZABh AG4AYQAxAB4AeAAEACQAkAEAAAEAAFYHAVYAZQByAGQAYQBuAGEAMQAeAHgA BAAMAJABAAABAABWBwFWAGUAcgBkAGEAbgBhADEAHgCgAAAA/3+QAQAAAAAA VgcBVgBlAHIAZABhAG4AYQAxAB4AcgEBAP9/vAIAAAAAAFYHAVYAZQByAGQA YQBuAGEAMQAeAPAAAQD/f7wCAAAAAABWBwFWAGUAcgBkAGEAbgBhADEAHgDw AAAA/3+QAQAAAAAAVgcBVgBlAHIAZABhAG4AYQAxAB4A8AAAAP9/kAEAAAAA AFYHAVYAZQByAGQAYQBuAGEAMQAaAMgAAQD/f7wCAAAAAABWBQFBAHIAaQBh AGwAHgQcAAUAFwAAIiQiIywjIzBfKTtcKCIkIiMsIyMwXCkeBCEABgAcAAAi JCIjLCMjMF8pO1tSZWRdXCgiJCIjLCMjMFwpHgQiAAcAHQAAIiQiIywjIzAu MDBfKTtcKCIkIiMsIyMwLjAwXCkeBCcACAAiAAAiJCIjLCMjMC4wMF8pO1tS ZWRdXCgiJCIjLCMjMC4wMFwpHgQ3ACoAMgAAXygiJCIqICMsIyMwXyk7Xygi JCIqIFwoIywjIzBcKTtfKCIkIiogIi0iXyk7XyhAXykeBC4AKQApAABfKCog IywjIzBfKTtfKCogXCgjLCMjMFwpO18oKiAiLSJfKTtfKEBfKR4EPwAsADoA AF8oIiQiKiAjLCMjMC4wMF8pO18oIiQiKiBcKCMsIyMwLjAwXCk7XygiJCIq ICItIj8/Xyk7XyhAXykeBDYAKwAxAABfKCogIywjIzAuMDBfKTtfKCogXCgj LCMjMC4wMFwpO18oKiAiLSI/P18pO18oQF8pHgQ0AKQALwAAXygqICMsIyMw LjBfKTtfKCogXCgjLCMjMC4wXCk7XygqICItIj8/Xyk7XyhAXykeBDAApQAr AABfKCogIywjIzBfKTtfKCogXCgjLCMjMFwpO18oKiAiLSI/P18pO18oQF8p 4AAUAAAAAAD1/yAAAAAAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAA AMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAA AAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQA AAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAA APQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1 /yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAA AAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAU AAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAAAAAABACAAAAAAAAAAAAAAAMAg4AAUAAUAKwD1/yAAAPgAAAAAAAAA AMAg4AAUAAUAKQD1/yAAAPgAAAAAAAAAAMAg4AAUAAUALAD1/yAAAPgAAAAA AAAAAMAg4AAUAAUAKgD1/yAAAPgAAAAAAAAAAMAg4AAUAAYAAAD0/wAAAPQA AAAAAAAAAMAg4AAUAAcAAAD0/wAAAPQAAAAAAAAAAMAg4AAUAAUACQD1/yAA APgAAAAAAAAAAMAg4AAUAAUApQABASAAAAQAAAAAAAAAAMAg4AAUAAAAKwAB ACAAAAQAAAAAAAAAAMAgkwIEABCAA/+TAgQAEYAG/5MCBAASgAT/kwIEABOA B/+TAgQAFIAJ/5MCBAAVgAj/kwIEAACAAP+TAgQAFoAF/2ABAgAAAIUAEwBd CAAAAAALAExWcyBvbiBSQUlEjAAEAAEAAQCuAQQAAQABBBcACAABAAAAAAAA AMEBCADBAQAAIr4BAOsAYgAPAADwWgAAAAAABvAgAAAADwgAAAMAAAARAAAA AgAAAAEAAAACAAAAAgAAAA8AAAAzAAvwEgAAAL8ACAAIAIEBQQAACMABQAAA CEAAHvEQAAAADQAACAwAAAgXAAAI9wAAEPwAPQACAAAAAgAAABYAAExWcyBv biBzZXBhcmF0ZSBSQUlENXMZAABTZXBhcmF0ZSBMVnMgb24gU2FtZSBSQUlE /wAKAAgA/QcAAAwAAABjCBUAYwgAAAAAAAAAAAAAFQAAAAAAAADGCgAAAAkI EAAABhAA7BXNB8HAAAAGAwAACwIYAAAAAAAAAAAAKAAAAB0JAAATDAAAgwwA AA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgABACoA AgAAACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAAAAP8AgQACAMEEFAAA ABUAAACDAAIAAACEAAIAAAChACIAAAD/AAEAAQABAAQAAAAAAAAAAAAAAOA/ AAAAAAAA4D8AAFUAAgAIAH0ADAAAAAIAAAsPAAIABAB9AAwAAwADAMAQDwAG AAQAfQAMAAQAAAEACw8AAgAEAAACDgAAAAAAKAAAAAAADwAAAAgCEAAAAAAA DwD/AAAAAAAAAQ8ACAIQAAEAAAAPAP8AAAAAAAABDwAIAhAAAgAAAA8A/wAA AAAAAAEPAL0AWgAAAAAADwAAAPA/DwAAABBADwAAACBADwAAAChADwAAADBA DwAAADRADwAAADhADwAAADxADwAAAEBADwAAAEJADwAAAERADwAAAEZADwAA AEhADwAAgEpADQADAg4AAQAAAA8AwoanV8rSL0ADAg4AAQABAA8ANs07TtGZ READAg4AAQACAA8AUiegibAZSEADAg4AAQADAA8ANs07TtFBSEADAg4AAQAE AA8AEHo2qz4XSEADAg4AAQAFAA8AHhZqTfOOR0ADAg4AAQAGAA8AcvkP6bef R0ADAg4AAQAHAA8A1XjpJjEgR0ADAg4AAQAIAA8AYcPTK2XBRkADAg4AAQAJ AA8AseHplbL0Q0ADAg4AAQAKAA8AWYY41sXVQkADAg4AAQALAA8AVg4tsp1v QkADAg4AAQAMAA8AiUFg5dAyQkADAg4AAQANAA8AQBNhw9OrQUD9AAoAAQAO AA8AAAAAAAMCDgACAAAADwB5WKg1zSswQAMCDgACAAEADwCTOgFNhB1EQAMC DgACAAIADwD35GGh1kQzQAMCDgACAAMADwC4QILixwgyQAMCDgACAAQADwC5 jQbwFkg2QAMCDgACAAUADwAMk6mCUYk0QAMCDgACAAYADwDA7J48LNQxQAMC DgACAAcADwDcRgN4CxQzQAMCDgACAAgADwCze/KwUPszQAMCDgACAAkADwDL oUW2810yQAMCDgACAAoADwCC4seYu2YxQAMCDgACAAsADwAHX5hMFewsQAMC DgACAAwADwCRfvs6cC4vQAMCDgACAA0ADwCI9NvXgfMxQP0ACgACAA4ADwAB AAAA1wAKAK4CAAAoAF4ACgEIAhAAJwADAAUA/wAAAAAAAAEPAAYAJwAnAAMA FwAAAAAAAACgQAAAJwAE/hEAHgIAHh8ABxUeAAQGFR4ABAYGAB8AJwAEABgA /Knx0k1iIEAAADgsaP0JAEQnAAPAHvoABtcABgBiAAAAAADsAMIADwAC8LoA AAAQAAjwCAAAAAIAAAABBAAADwAD8KIAAAAPAATwKAAAAAEACfAQAAAAAAAA AAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwagAAAJIMCvAIAAAA AQQAAAAKAACDAAvwMAAAAH8ABAEEAb8ACAAIAIEBTgAACIMBTQAACL8BEAAQ AMABTQAACP8BCAAIAD8CAAACAAAAEPASAAAAAAAAAC8ABQAAAA0ADAAkALUA AAAR8AAAAABdABoAFQASAAUAAQARYAAAAAB4BUsBAAAAAAAAAAAJCBAAAAYg AOwVzQfBwAAABgMAABQAAAAVAAAAgwACAAAAhAACAAAAoQAiAAAAEgABAAEA AQAEAAAAeAUAAAAAAADgPwAAAAAAAOA/DwAzAAIAAwBgEAoA8C2YFxgBAAAJ AGAQCgDwLZgXyAABAAoAYBAKAPAtmBfIAAEACwBgEAoA8C2YF8gAAAAMAGAQ CgB4S6Qf3AAAAA0AEgACAAAA7ADEAA8AAvBeBwAAIAAI8AgAAAAPAAAADggA AA8AA/BGBwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArw CAAAAAAIAAAFAAAADwAE8HQAAACiDArwCAAAAAEIAAAACgAAYwAL8CQAAACA ABhuagO/AAoACgCBAQkAAAi/AQAAEADAAUAAAAj/AQAACAATACLxBgAAAL8A AAAgAAAAEPASAAAAAgBKAQAAfwwAAIsBAAAdDQAAAAAR8AAAAABdABoAFQAS AAYAAQARABhuagPwY0sBAAAAAAAAAADsAAgAAAAN8AAAAAC2ARIAFAIAAAAA AAAAAAEAEAAAAAAAPAACAAAxPAAQAAAADQAHABEAAQAAAAAAAADsAHoADwAE 8HoAAACiDArwCAAAAAIIAAAACgAAcwAL8CoAAAB/AAAABACAAHhuagO/AAoA CgCBAQkAAAi/AQAAEADAAUAAAAj/AQAACAATACLxBgAAAL8AAAAgAAAAEPAS AAAAAgBSAgAAfwwAAJMCAAAdDQAAAAAR8AAAAABdABoAFQASAAYAAgARAHhu agOcZEsBAAAAAAAAAADsAAgAAAAN8AAAAAC2ARIAFAIAAAAAAAAAAAEAEAAA AAAAPAACAAA0PAAQAAAADQAHABEAAQAAAAAAAADsAHoADwAE8HoAAACiDArw CAAAAAMIAAAACgAAcwAL8CoAAAB/AAAABACAANhuagO/AAoACgCBAQkAAAi/ AQAAEADAAUAAAAj/AQAACAATACLxBgAAAL8AAAAgAAAAEPASAAAAAgBhAwAA fwwAAKIDAAAlDQAAAAAR8AAAAABdABoAFQASAAYAAwARANhuagNIZUsBAAAA AAAAAADsAAgAAAAN8AAAAAC2ARIAFAIAAAAAAAAAAAEAEAAAAAAAPAACAAA4 PAAQAAAADQAHABEAAQAAAAAAAADsAHoADwAE8HoAAACiDArwCAAAAAQIAAAA CgAAcwAL8CoAAAB/AAAABACAAEBvagO/AAoACgCBAQkAAAi/AQAAEADAAUAA AAj/AQAACAATACLxBgAAAL8AAAAgAAAAEPASAAAAAgBpBAAAfwwAAMUEAAAd DQAAAAAR8AAAAABdABoAFQASAAYABAARAEBvagP0ZUsBAAAAAAAAAADsAAgA AAAN8AAAAAC2ARIAFAIAAAAAAAAAAAIAEAAAAAAAPAADAAAxMjwAEAAAAA0A DgARAAIAAAAAAAAA7AB6AA8ABPB6AAAAogwK8AgAAAAFCAAAAAoAAHMAC/Aq AAAAfwAAAAQAgACob2oDvwAKAAoAgQEJAAAIvwEAABAAwAFAAAAI/wEAAAgA EwAi8QYAAAC/AAAAIAAAABDwEgAAAAIAdQUAAH8MAADRBQAAHQ0AAAAAEfAA AAAAXQAaABUAEgAGAAUAEQCob2oDoGZLAQAAAAAAAAAA7AAIAAAADfAAAAAA tgESABQCAAAAAAAAAAACABAAAAAAADwAAwAAMTY8ABAAAAANAA4AEQACAAAA AAAAAOwAegAPAATwegAAAKIMCvAIAAAABggAAAAKAABzAAvwKgAAAH8AAAAE AIAA4EQ1Ab8ACgAKAIEBCQAACL8BAAAQAMABQAAACP8BAAAIABMAIvEGAAAA vwAAACAAAAAQ8BIAAAACAIEGAAB/DAAA3QYAAB0NAAAAABHwAAAAAF0AGgAV ABIABgAGABEA4EQ1AUxnSwEAAAAAAAAAAOwACAAAAA3wAAAAALYBEgAUAgAA AAAAAAAAAgAQAAAAAAA8AAMAADIwPAAQAAAADQAOABEAAgAAAAAAAADsAHoA DwAE8HoAAACiDArwCAAAAAcIAAAACgAAcwAL8CoAAAB/AAAABACAAEhFNQG/ AAoACgCBAQkAAAi/AQAAEADAAUAAAAj/AQAACAATACLxBgAAAL8AAAAgAAAA EPASAAAAAgCJBwAAfwwAAOUHAAAdDQAAAAAR8AAAAABdABoAFQASAAYABwAR AEhFNQG4bUsBAAAAAAAAAADsAAgAAAAN8AAAAAC2ARIAFAIAAAAAAAAAAAIA EAAAAAAAPAADAAAyNDwAEAAAAA0ADgARAAIAAAAAAAAA7AB6AA8ABPB6AAAA ogwK8AgAAAAICAAAAAoAAHMAC/AqAAAAfwAAAAQAgACwRTUBvwAKAAoAgQEJ AAAIvwEAABAAwAFAAAAI/wEAAAgAEwAi8QYAAAC/AAAAIAAAABDwEgAAAAIA mAgAAH8MAAD0CAAAHQ0AAAAAEfAAAAAAXQAaABUAEgAGAAgAEQCwRTUBvDpL AQAAAAAAAAAA7AAIAAAADfAAAAAAtgESABQCAAAAAAAAAAACABAAAAAAADwA AwAAMjg8ABAAAAANAA4AEQACAAAAAAAAAOwAegAPAATwegAAAKIMCvAIAAAA CQgAAAAKAABzAAvwKgAAAH8AAAAEAIAACDM1Ab8ACgAKAIEBCQAACL8BAAAQ AMABQAAACP8BAAAIABMAIvEGAAAAvwAAACAAAAAQ8BIAAAACAKAJAAB/DAAA /AkAAB0NAAAAABHwAAAAAF0AGgAVABIABgAJABEACDM1AWg7SwEAAAAAAAAA AOwACAAAAA3wAAAAALYBEgAUAgAAAAAAAAAAAgAQAAAAAAA8AAMAADMyPAAQ AAAADQAOABEAAgAAAAAAAADsAHoADwAE8HoAAACiDArwCAAAAAoIAAAACgAA cwAL8CoAAAB/AAAABACAAORaNQG/AAoACgCBAQkAAAi/AQAAEADAAUAAAAj/ AQAACAATACLxBgAAAL8AAAAgAAAAEPASAAAAAgCsCgAAfwwAAAgLAAAdDQAA AAAR8AAAAABdABoAFQASAAYACgARAORaNQEUPEsBAAAAAAAAAADsAAgAAAAN 8AAAAAC2ARIAFAIAAAAAAAAAAAIAEAAAAAAAPAADAAAzNjwAEAAAAA0ADgAR AAIAAAAAAAAA7AB6AA8ABPB6AAAAogwK8AgAAAALCAAAAAoAAHMAC/AqAAAA fwAAAAQAgABYXTUBvwAKAAoAgQEJAAAIvwEAABAAwAFAAAAI/wEAAAgAEwAi 8QYAAAC/AAAAIAAAABDwEgAAAAIAtAsAAH8MAAAQDAAAHQ0AAAAAEfAAAAAA XQAaABUAEgAGAAsAEQBYXTUBjFdLAQAAAAAAAAAA7AAIAAAADfAAAAAAtgES ABQCAAAAAAAAAAACABAAAAAAADwAAwAANDA8ABAAAAANAA4AEQACAAAAAAAA AOwAegAPAATwegAAAKIMCvAIAAAADAgAAAAKAABzAAvwKgAAAH8AAAAEAIAA qFY1Ab8ACgAKAIEBCQAACL8BAAAQAMABQAAACP8BAAAIABMAIvEGAAAAvwAA ACAAAAAQ8BIAAAACAL8MAAB/DAAAGw0AAB0NAAAAABHwAAAAAF0AGgAVABIA BgAMABEAqFY1AThYSwEAAAAAAAAAAOwACAAAAA3wAAAAALYBEgAUAgAAAAAA AAAAAgAQAAAAAAA8AAMAADQ0PAAQAAAADQAOABEAAgAAAAAAAADsAHoADwAE 8HoAAACiDArwCAAAAA0IAAAACgAAcwAL8CoAAAB/AAAABACAAFBZNQG/AAoA CgCBAQkAAAi/AQAAEADAAUAAAAj/AQAACAATACLxBgAAAL8AAAAgAAAAEPAS AAAAAgDHDQAAfwwAACMOAAAdDQAAAAAR8AAAAABdABoAFQASAAYADQARAFBZ NQHkWEsBAAAAAAAAAADsAAgAAAAN8AAAAAC2ARIAFAIAAAAAAAAAAAIAEAAA AAAAPAADAAA0ODwAEAAAAA0ADgARAAIAAAAAAAAA7AB6AA8ABPB6AAAAogwK 8AgAAAAOCAAAAAoAAHMAC/AqAAAAfwAAAAQAgADcVzUBvwAKAAoAgQEJAAAI vwEAABAAwAFAAAAI/wEAAAgAEwAi8QYAAAC/AAAAIAAAABDwEgAAAAIA0w4A AH8MAAAvDwAAHQ0AAAAAEfAAAAAAXQAaABUAEgAGAA4AEQDcVzUBkFlLAQAA AAAAAAAA7AAIAAAADfAAAAAAtgESABQCAAAAAAAAAAACABAAAAAAADwAAwAA NTM8ABAAAAANAA4AEQACAAAAAAAAAAEQAgAAAAIQEAAAAAAAAAAAAAAAewMA AJUBMxAAAKAABAABAAEAZBAIAAAAAQAAAAEAMhAEAAAAAgAzEAAABxAMAAAA AAAAAP//CQBNAAoQEAD///8AAAAAAAEAAQBOAE0ANBAAAAMQDAABAAEADgAO AAEAAAAzEAAAURAIAAABAAAAAAAADRBGAAAAIQFMAG8AZwBpAGMAYQBsACAA VgBvAGwAdQBtAGUAcwAgAG8AbgAgAFMAZQBwAGEAcgBhAHQAZQAgAFIAQQBJ AEQAcwBREBMAAQIAAAAACwA7AAABAAEAAAANAFEQCAACAAAAAAAAAFEQCAAD AQAAAAAAAAYQCAD//wAAAAAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQ DAABAAEADgAOAAEAAAAzEAAAURAIAAABAAAAAAAADRA8AAAAHAFMAG8AZwBp AGMAYQBsACAAVgBvAGwAdQBtAGUAcwAgAG8AbgAgAFMAYQBtAGUAIABSAEEA SQBEAFEQEwABAgAAAAALADsAAAIAAgAAAA0AURAIAAIAAAAAAAAAURAIAAMB AAAAAAAABhAIAP//AQABAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAARBAE AAoAAAAkEAIAAgAlECAAAgIBAAAAAADv////2v///wAAAAAAAAAAsQBNAFCo AAAzEAAATxAUAAIAAgAAAAAAAAAAAAAAAAAAAAAAJhACAAwAURAIAAABAAAA AAAANBAAACQQAgADACUQIAACAgEAAAAAAO/////a////AAAAAAAAAACxAE0A UCgAADMQAABPEBQAAgACAAAAAAAAAAAAAAAAAAAAAAAmEAIACwBREAgAAAEA AAAAAAA0EAAARhACAAEAQRASAAAA+AAAAKACAACGDgAAnQoAADMQAABPEBQA AgACAH4AAAA+AgAAAA8AAGELAAAdEBIAAAAAAAAAAAAAAAAAAAAAAAAAMxAA ACAQCAABAAEAAQABAGIQEgAAAAAAAQAAAAEAAAAAAAAA7wAeEB4AAgAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAIwBNAAAANBAAAB0QEgABAAAAAAAAAAAAAAAA AAAAAAAzEAAAHxAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAfAR4QHgACAAMBAAAAAAAAAAAAAAAAAAAAAAAAAAAjAE0AAAAh EAIAAQAHEAwAAAAAAAAA//8JAE0ANBAAACUQIAACAgEAAAAAALoGAACfDQAA AwMAAMQAAACBAE0AAAAAADMQAABPEBQAAgACAAAAAAAAAAAA4wAAABoAAAAm EAIACgBREAgAAAEAAAAAAAANEDQAAAAYAVMAaQBtAHUAbABhAHQAZQBkACAA TgBCAGUAbgBjAGgAIABDAGwAaQBlAG4AdABzACcQBgADAAAAAAA0EAAAJRAg AAICAQAAAAAAJQAAAPsEAABYAAAA5QUAAIECTQAAAFoAMxAAAE8QFAACAAIA AAAAAAAAAAAaAAAAyAAAACYQAgAKAFEQCAAAAQAAAAAAAA0QKgAAABMBVABo AHIAbwB1AGcAaABwAHUAdAAgACgATQBCAC8AcwBlAGMAKQAnEAYAAgAAAAAA NBAAADUQAAAyEAQAAAADADMQAAAHEAwAgICAAAAAAAAAABcAChAQAMDAwAAA AAAAAQAAABYATwA0EAAAFBAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAMxAAABgQ AgAAACIQCgAAAAAAAAAAAA8AFRAUAAEEAAC+DgAAcAgAAMQAAAAAAQ8AMxAA AE8QFAAFAAIAAQQAAL4OAAAAAAAAAAAAACUQIAACAgEAAAAAAO/////a//// AAAAAAAAAACxAE0AoCoAADMQAABPEBQAAgACAAAAAAAAAAAAAAAAAAAAAABR EAgAAAEAAAAAAAA0EAAANBAAADQQAAA0EAAAJRAgAAICAQAAAAAAywMAAFMA AAANCAAAVAEAAIEATQBQGQAAMxAAAE8QFAACAAIAAAAAAAAAAABfAgAALQAA ACYQAgAJAFEQCAAAAQAAAAAAAA0QVAAAACgBRABlAGQAaQBjAGEAdABlAGQA IABKAG8AdQByAG4AYQBsACAARABlAHYAaQBjAGUAIABvAG4AIABTAGUAcABh AHIAYQB0AGUAIABMAFYAcwAnEAYAAQAAAAAANBAAADQQAAAAAg4AAAAAAA4A AAAAAAIAAABlEAIAAgBlEAIAAQADAg4AAAAAAAAAwoanV8rSL0ADAg4AAAAB AAAAeVioNc0rMEADAg4AAQAAAAAANs07TtGZREADAg4AAQABAAAAkzoBTYQd READAg4AAgAAAAAAUiegibAZSEADAg4AAgABAAAA9+RhodZEM0ADAg4AAwAA AAAANs07TtFBSEADAg4AAwABAAAAuECC4scIMkADAg4ABAAAAAAAEHo2qz4X SEADAg4ABAABAAAAuY0G8BZINkADAg4ABQAAAAAAHhZqTfOOR0ADAg4ABQAB AAAADJOpglGJNEADAg4ABgAAAAAAcvkP6befR0ADAg4ABgABAAAAwOyePCzU MUADAg4ABwAAAAAA1XjpJjEgR0ADAg4ABwABAAAA3EYDeAsUM0ADAg4ACAAA AAAAYcPTK2XBRkADAg4ACAABAAAAs3vysFD7M0ADAg4ACQAAAAAAseHplbL0 Q0ADAg4ACQABAAAAy6FFtvNdMkADAg4ACgAAAAAAWYY41sXVQkADAg4ACgAB AAAAguLHmLtmMUADAg4ACwAAAAAAVg4tsp1vQkADAg4ACwABAAAAB1+YTBXs LEADAg4ADAAAAAAAiUFg5dAyQkADAg4ADAABAAAAkX77OnAuL0ADAg4ADQAA AAAAQBNhw9OrQUADAg4ADQABAAAAiPTb14HzMUBlEAIAAwAKAAAAPgISALYG AAAAAEAAAAAAAAAAAAAAAB0ADwADKAAEAAAAAQAoACgABATvAAYACAA3AAAA CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCr kQgAKyez2TAAAACoAAAABwAAAAEAAABAAAAABAAAAEgAAAAIAAAAXAAAABIA AABwAAAADAAAAIgAAAANAAAAlAAAABMAAACgAAAAAgAAAOQEAAAeAAAADAAA AE1pa2UgWW91bmcAAB4AAAAMAAAATWlrZSBZb3VuZwAAHgAAABAAAABNaWNy b3NvZnQgRXhjZWwAQAAAAAB/SShQ0cMBQAAAAAADIUBQ0cMBAwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQ k5cIACss+a4wAAAAyAAAAAkAAAABAAAAUAAAAA8AAABYAAAAFwAAAGQAAAAL AAAAbAAAABAAAAB0AAAAEwAAAHwAAAAWAAAAhAAAAA0AAACMAAAADAAAAKQA AAACAAAA5AQAAB4AAAAEAAAAAAAAAAMAAABHFgsACwAAAAAAAAALAAAAAAAA AAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAwAAABMVnMgb24gUkFJRAAMEAAA AgAAAB4AAAALAAAAV29ya3NoZWV0cwADAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA AAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAA/v///xMAAAAUAAAA FQAAABYAAAAXAAAAGAAAABkAAAD+////GwAAABwAAAAdAAAAHgAAAB8AAAAg AAAAIQAAAP7////9/////v////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIA eQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABYABQH//////////wIAAAAgCAIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA AAAAAAAAAAD+////AAAAAAAAAABXAG8AcgBrAGIAbwBvAGsAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAf// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAbIwAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA aQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAAMAAAD/ ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAAAAAQ AAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBv AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAAAABAAAAAAAABS AG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AgAAACAIAgAAAAAAwAAA AAAAAEYAAAAAAAAAAAAAAADgozSBUtHDAScAAABAAQAAAAAAAFcAbwByAGsA YgBvAG8AawAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAASAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABsjAAAAAAAABQBTAHUAbQBtAGEAcgB5 AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACgAAgEBAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAASAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUA bQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAAC Af///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAQAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAI AAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAA/v///xMA AAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAD+//////////////////////// //////////////////////////////////7////9/////v////7///////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ////////////////////////////////////////////AQAAAAIAAAADAAAA BAAAAP7///////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// ///////+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgA Kyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuDAEAAMgAAAAJAAAAAQAAAFAAAAAP AAAAWAAAABcAAABkAAAACwAAAGwAAAAQAAAAdAAAABMAAAB8AAAAFgAAAIQA AAANAAAAjAAAAAwAAACkAAAAAgAAAOQEAAAeAAAABAAAAAAAAAADAAAARxYL AAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAMAAAA TFZzIG9uIFJBSUQADBAAAAIAAAAeAAAACwAAAFdvcmtzaGVldHMAAwAAAAEA AAAANAAAAAMAAAAAAAAAIAAAAAEAAAAkAAAAAAAAgCwAAAAAAAAAAgAAALAE AAATAAAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=_NextPart_000_001E_01C3D10F.792CA730-- From owner-linux-xfs@oss.sgi.com Fri Jan 2 09:14:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 09:14: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 i02HEPTa024380 for ; Fri, 2 Jan 2004 09:14:25 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02HEPNj024378 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 09:14:25 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02HENTc024350 for ; Fri, 2 Jan 2004 09:14:23 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02Gih1E023574; Fri, 2 Jan 2004 08:44:43 -0800 Date: Fri, 2 Jan 2004 08:44:43 -0800 Message-Id: <200401021644.i02Gih1E023574@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 1576 X-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: 583 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From hch@xfs.org 2004-02-01 08:44 PDT ------- Okay, marking Worksforme because it's not reproducible here. ------- 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 Jan 2 09:14:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 09:14: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 i02HEPTa024379 for ; Fri, 2 Jan 2004 09:14:25 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02HEPeU024377 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 09:14:25 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02HENTg024350 for ; Fri, 2 Jan 2004 09:14:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02GMQ3e023023; Fri, 2 Jan 2004 08:22:26 -0800 Date: Fri, 2 Jan 2004 08:22:26 -0800 Message-Id: <200401021622.i02GMQ3e023023@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 302] DMAPI conditional build broken in linux-2.6-xfs tree from 20040101 X-Bugzilla-Reason: AssignedTo X-archive-position: 1577 X-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: 670 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=302 misiek@dione.ids.pl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID ------- Additional Comments From misiek@dione.ids.pl 2004-02-01 08:22 PDT ------- You were right of course. I've removed too much from Makefile (including xfs_dmops.o building) and that was the reaseon for problems. ------- 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 Jan 2 10:29:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 10:29:45 -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 i02ITOTa025784 for ; Fri, 2 Jan 2004 10:29:27 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AcU2z-0007IE-Dk; Fri, 02 Jan 2004 18:29:21 +0000 Date: Fri, 2 Jan 2004 18:29:21 +0000 From: Christoph Hellwig To: Claas Langbehn Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS forced shutdown with kernel 2.6.0 Message-ID: <20040102182921.A27237@infradead.org> Mail-Followup-To: Christoph Hellwig , Claas Langbehn , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20040102095051.GA19872@rootdir.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040102095051.GA19872@rootdir.de>; from claas@rootdir.de on Fri, Jan 02, 2004 at 10:50:51AM +0100 X-archive-position: 1578 X-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: 840 Lines: 25 On Fri, Jan 02, 2004 at 10:50:51AM +0100, Claas Langbehn wrote: > Hello! > > > Last night one of my machines running xfs shut down my /homes partition. > > That machine was running Azureus (a bittorrent client) with probably > high memory usage. > > But even if the memory usage of one program is going near to 100% it > should not force the filesystem to shutdown. Instead it should crash > the application. > > I could also think of bad memory, but we did test the SDRAM modules > only a week ago, and they passed memtest86. > > After rebooting everything was working fine, again. > > So, is this a bug of xfs? I've seen the same bug a few times lately, but only if I had previous memory corruption due to code I was hacking on. Can you reproduce it without the nvidia module loaded as that is likely source of such corruption? From owner-linux-xfs@oss.sgi.com Fri Jan 2 12:27:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 12:28:13 -0800 (PST) Received: from turing-police.cc.vt.edu (h80ad254a.async.vt.edu [128.173.37.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i02KRiTa030265 for ; Fri, 2 Jan 2004 12:27:45 -0800 Received: from turing-police.cc.vt.edu (IDENT:valdis@localhost [127.0.0.1]) by turing-police.cc.vt.edu (8.13.0.PreAlpha5/8.13.0.PreAlpha5) with ESMTP id i02KRe7X013502; Fri, 2 Jan 2004 15:27:40 -0500 Message-Id: <200401022027.i02KRe7X013502@turing-police.cc.vt.edu> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4+dev To: Claas Langbehn Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS forced shutdown with kernel 2.6.0 In-Reply-To: Your message of "Fri, 02 Jan 2004 18:29:21 GMT." <20040102182921.A27237@infradead.org> From: Valdis.Kletnieks@vt.edu References: <20040102095051.GA19872@rootdir.de> <20040102182921.A27237@infradead.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1860073584P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 02 Jan 2004 15:27:40 -0500 X-archive-position: 1579 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Valdis.Kletnieks@vt.edu Precedence: bulk X-list: linux-xfs Content-Length: 1812 Lines: 54 --==_Exmh_-1860073584P Content-Type: text/plain; charset=us-ascii On Fri, 02 Jan 2004 18:29:21 GMT, Christoph Hellwig said: > I've seen the same bug a few times lately, but only if I had previous > memory corruption due to code I was hacking on. Can you reproduce it > without the nvidia module loaded as that is likely source of such > corruption? While you're at it, see what *else* you can turn off - RAID, devfs, NFS, etc. It's equally likely that you're tripping over some other kernel module's use-after-free or chase-the-wrong-pointer bug. I've seen a lot more bugfixes for *those* on this list than cases where "I turned off nvidia and it started working". From the 2.6.1-rc1 release notes: Jeff Garzik: o [libata] fix use-after-free Stephen Hemminger: o [ROSE]: Fix use after free in socket destruction Andrew Morton, on broken iee1394: > aargh, sorry. You need to revert > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1-rc1/2.6.1-rc1-mm1/broken-out/sysfs-add-vc-class.patch > > This is the totally weird tty oops which Greg and I have been starting > at bemusedly for a few days. That's *this week* or so. Yes, I understand the political and/or realistic reasons for refusing to look at tainted kernels, but let's face it guys, *our* code is to blame more often than NVidia's. When was the last time there was a *verified* report of "I turned the NVidia graphics module off and things worked" that wasn't directly related to a graphics issue? --==_Exmh_-1860073584P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQE/9dQ8cC3lWbTT17ARArKIAJ9DhuID6a64NS2C4syITqd0pPVr4QCfXlNZ tdIH3vQ1sJnWfWhZCl7/KV0= =Ji3J -----END PGP SIGNATURE----- --==_Exmh_-1860073584P-- From owner-linux-xfs@oss.sgi.com Fri Jan 2 12:35:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 12:36: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 i02KZwTa030699 for ; Fri, 2 Jan 2004 12:35:59 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AcW1T-0000OM-7O; Fri, 02 Jan 2004 20:35:55 +0000 Date: Fri, 2 Jan 2004 20:35:55 +0000 From: Christoph Hellwig To: Valdis.Kletnieks@vt.edu Cc: Claas Langbehn , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS forced shutdown with kernel 2.6.0 Message-ID: <20040102203555.A1420@infradead.org> Mail-Followup-To: Christoph Hellwig , Valdis.Kletnieks@vt.edu, Claas Langbehn , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20040102095051.GA19872@rootdir.de> <20040102182921.A27237@infradead.org> <200401022027.i02KRe7X013502@turing-police.cc.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200401022027.i02KRe7X013502@turing-police.cc.vt.edu>; from Valdis.Kletnieks@vt.edu on Fri, Jan 02, 2004 at 03:27:40PM -0500 X-archive-position: 1580 X-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: 801 Lines: 18 On Fri, Jan 02, 2004 at 03:27:40PM -0500, Valdis.Kletnieks@vt.edu wrote: > On Fri, 02 Jan 2004 18:29:21 GMT, Christoph Hellwig said: > > > I've seen the same bug a few times lately, but only if I had previous > > memory corruption due to code I was hacking on. Can you reproduce it > > without the nvidia module loaded as that is likely source of such > > corruption? > > While you're at it, see what *else* you can turn off - RAID, devfs, NFS, etc. > > It's equally likely that you're tripping over some other kernel module's > use-after-free or chase-the-wrong-pointer bug. I've seen a lot more bugfixes > for *those* on this list than cases where "I turned off nvidia and it started > working". The difference is that I can look at those while I can't look at nvidias driver. Pretty simple. From owner-linux-xfs@oss.sgi.com Fri Jan 2 13:14:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Jan 2004 13:14: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 i02LERTa031451 for ; Fri, 2 Jan 2004 13:14:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02LERT8031450 for linux-xfs@oss.sgi.com; Fri, 2 Jan 2004 13:14:27 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i02LEOTc031436 for ; Fri, 2 Jan 2004 13:14:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i02L7fOl031374; Fri, 2 Jan 2004 13:07:41 -0800 Date: Fri, 2 Jan 2004 13:07:41 -0800 Message-Id: <200401022107.i02L7fOl031374@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 1581 X-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: 797 Lines: 29 http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 overby@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From overby@sgi.com 2004-02-01 13:07 PDT ------- This report is a symptom of another problem. The error came back from inotobp because XFS read an inode off disk that did not look like an inode (bad magic, etc.). See case 2491479, and PVs 906636 and 905898 for the customer reported details we have on this bug. Glen Overby ------- 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 Sat Jan 3 03:14:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Jan 2004 03:15:04 -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 i03BETTa001065 for ; Sat, 3 Jan 2004 03:14:29 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i03BETNM001063 for linux-xfs@oss.sgi.com; Sat, 3 Jan 2004 03:14:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i03BERTc001049 for ; Sat, 3 Jan 2004 03:14:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i03AJM8Y030856; Sat, 3 Jan 2004 02:19:22 -0800 Date: Sat, 3 Jan 2004 02:19:22 -0800 Message-Id: <200401031019.i03AJM8Y030856@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: 1582 X-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: 423 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=286 ------- Additional Comments From john@geeknetau.net 2004-03-01 02:19 PDT ------- Kernel version 2.4.21, Debian Unstable patches, XFS patches. Note thatI have been unable to reproduce this bug, and have recently upgraded to 2.4.23 Prestine + XFS. ------- 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 Sat Jan 3 05:14:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Jan 2004 05:15: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 i03DETTa006871 for ; Sat, 3 Jan 2004 05:14:29 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i03DETLf006870 for linux-xfs@oss.sgi.com; Sat, 3 Jan 2004 05:14:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i03DERTc006856 for ; Sat, 3 Jan 2004 05:14:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i03CMWMR005926; Sat, 3 Jan 2004 04:22:32 -0800 Date: Sat, 3 Jan 2004 04:22:32 -0800 Message-Id: <200401031222.i03CMWMR005926@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 277] xfs_force_shutdown after kernel bug X-Bugzilla-Reason: AssignedTo X-archive-position: 1583 X-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: 340 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=277 ------- Additional Comments From til@belleville.ch 2004-03-01 04:22 PDT ------- No, happened just once in about a year of productive use. No idea what triggered 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 Sat Jan 3 06:50:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Jan 2004 06:50:49 -0800 (PST) Received: from imo-m04.mx.aol.com (imo-m04.mx.aol.com [64.12.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i03EoLTa012331 for ; Sat, 3 Jan 2004 06:50:22 -0800 Received: from AndyLiebman@aol.com by imo-m04.mx.aol.com (mail_out_v36_r4.8.) id 4.14b.28cacee8 (3964) for ; Sat, 3 Jan 2004 09:50:06 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <14b.28cacee8.2d28309e@aol.com> Date: Sat, 3 Jan 2004 09:50:06 EST Subject: XFS under 2.6 kernel To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5006 X-archive-position: 1584 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 266 Lines: 7 Is there any "definitive word" about whether it's safe to use xfs under the released version of the 2.6 kernel? Also, is there anything to watch out for using xfs plus software RAID5? If anybody has this information, it might be nice to post it. Andy Liebman From owner-linux-xfs@oss.sgi.com Sat Jan 3 07:11:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Jan 2004 07:11:24 -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 i03FBCTa015501 for ; Sat, 3 Jan 2004 07:11:12 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id i03FEU17024284; Sat, 3 Jan 2004 10:14:30 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id i03FEUnW024281; Sat, 3 Jan 2004 10:14:30 -0500 Date: Sat, 3 Jan 2004 10:14:30 -0500 (EST) From: Net Llama! To: AndyLiebman@aol.com cc: linux-xfs@oss.sgi.com Subject: Re: XFS under 2.6 kernel In-Reply-To: <14b.28cacee8.2d28309e@aol.com> Message-ID: References: <14b.28cacee8.2d28309e@aol.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: 1585 X-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: 617 Lines: 14 On Sat, 3 Jan 2004 AndyLiebman@aol.com wrote: > Is there any "definitive word" about whether it's safe to use xfs under the > released version of the 2.6 kernel? Also, is there anything to watch out for > using xfs plus software RAID5? If anybody has this information, it might be > nice to post it. My experiences are by no means official, but I'm using 2.6.0 with XFS on three non-production boxes, and haven't had any problems yet. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Sat Jan 3 07:27:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Jan 2004 07:27:43 -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 i03FRKTa018029 for ; Sat, 3 Jan 2004 07:27:20 -0800 Received: from localhost (localhost [127.0.0.1]) by jack.feedbackplusinc.com (Postfix) with ESMTP id 199018FC9A; Sat, 3 Jan 2004 09:27:14 -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 27379-09; Sat, 3 Jan 2004 09:27:11 -0600 (CST) Received: from c-24-0-138-66.client.comcast.net (c-24-0-138-66.client.comcast.net [24.0.138.66]) by jack.feedbackplusinc.com (Postfix) with ESMTP id B8B468FBDD; Sat, 3 Jan 2004 09:27:10 -0600 (CST) Subject: Re: XFS under 2.6 kernel From: Jerry Haltom To: Net Llama! Cc: AndyLiebman@aol.com, linux-xfs@oss.sgi.com In-Reply-To: References: <14b.28cacee8.2d28309e@aol.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DKMzd329J4ananp5knHb" Organization: Feedback Plus, Inc. Message-Id: <1073143622.3475.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 03 Jan 2004 09:27:02 -0600 X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at feedbackplusinc.com X-archive-position: 1586 X-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: 1394 Lines: 44 --=-DKMzd329J4ananp5knHb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I have had problems. I can blame them on the NVidia drivers though. Watch out for that combo. :) What happened is I opened GnomeMeeting, which did SOMETHING to the display, which caused my XFS to become totally trashed (XFS is on a Raid 5 3ware partition, not software). Lost lots of files, spend hours recovering from lost+found. =3D( It was horrible. On Sat, 2004-01-03 at 09:14, Net Llama! wrote: > On Sat, 3 Jan 2004 AndyLiebman@aol.com wrote: > > Is there any "definitive word" about whether it's safe to use xfs under= the > > released version of the 2.6 kernel? Also, is there anything to watch ou= t for > > using xfs plus software RAID5? If anybody has this information, it mig= ht be > > nice to post it. >=20 > My experiences are by no means official, but I'm using 2.6.0 with XFS on > three non-production boxes, and haven't had any problems yet. --=20 Jerry Haltom Feedback Plus, Inc. --=-DKMzd329J4ananp5knHb 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/9t9GRTZ5+YJ1b+YRAop1AJ4xi+02aT4ftViYWfSoHl6urX+/GwCfRCqX SU4FrvoWR4ZYGIp2GbATOA0= =yW2a -----END PGP SIGNATURE----- --=-DKMzd329J4ananp5knHb-- From owner-linux-xfs@oss.sgi.com Sun Jan 4 03:42:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Jan 2004 03:42:54 -0800 (PST) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i04BggTa005130 for ; Sun, 4 Jan 2004 03:42:43 -0800 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.002172AD@mailhub2.arup.com>; 4 Jan 2004 8:32:32 +0000 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Sun, 04 Jan 2004 08:32:31 -0000 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Sun, 04 Jan 2004 19:30:27 +1100 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Sun, 04 Jan 2004 19:28:56 +1100 From: "Scott Fagg" To: Subject: Re: XFS under 2.6 kernel Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i04BghTa005133 X-archive-position: 1587 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 716 Lines: 21 Using 2.6 + XFS on 2 home boxes without any loss of data. Had some odd NFS problems sharing out an XFS disc, toggling NFS options (enabled no_subtree_check) fixed the problem. I don't know where the fault lay as i didn't test it with a non-XFS partition. Plan is to upgrade my production XFS boxes to 2.6.x when convenient. Scott Fagg Arup Brisbane (07) 3023 6000 >>> 04/01/2004 12:50:06 am >>> Is there any "definitive word" about whether it's safe to use xfs under the released version of the 2.6 kernel? Also, is there anything to watch out for using xfs plus software RAID5? If anybody has this information, it might be nice to post it. Andy Liebman From owner-linux-xfs@oss.sgi.com Mon Jan 5 01:16:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 01:17:12 -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 i059GgTa005177 for ; Mon, 5 Jan 2004 01:16:44 -0800 Received: from LINSENEW ([10.0.0.161]) by miami.chance with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CFBZLXKK; Mon, 5 Jan 2004 14:50:05 +0530 Message-ID: <001601c3d36c$8c226960$a100000a@linseNew> From: "Linse A Pallan" To: Subject: ACL Maximum Entries Restriction Date: Mon, 5 Jan 2004 14:46:05 +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: 1588 X-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: 620 Lines: 10 Hi, While working with the XFS File system I found that we can have only maximum of 25 entries per ACL. Is there any way to increase this Maximum limit? I made try by changing the definition "#define XFS_ACL_MAX_ENTRIES 25" in file fs/xfs/xfs_acl.h to "#define XFS_ACL_MAX_ENTRIES 1000". After this change I rebuild the kernel and I am able to having maximum of 1000 entries per ACL. Is there any pitfalls/drawbacks in increasing the ACL maximum entries limit like this? Or is there any other way to increase the ACL Entries Maximum Limit? Thanking you in advance, Linse A Pallan [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Jan 5 04:30:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 04:30:50 -0800 (PST) Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05CUGTa014612 for ; Mon, 5 Jan 2004 04:30:17 -0800 Received: from bliss.uni-koblenz.de (bliss.uni-koblenz.de [141.26.64.65]) by mailhost.uni-koblenz.de (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i057o4MI013885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Jan 2004 08:50:05 +0100 Received: from localhost (localhost [127.0.0.1]) by bliss.uni-koblenz.de (8.12.10/8.12.3) with ESMTP id i057o4XV015779 for ; Mon, 5 Jan 2004 08:50:04 +0100 From: Rainer Krienke Organization: Uni Koblenz To: linux-xfs@oss.sgi.com Subject: Segfault of xfs_repair during repair of a xfs filesystem Date: Mon, 5 Jan 2004 08:49:59 +0100 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_rcR+/9nJ1GiSC26"; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200401050850.03928.krienke@uni-koblenz.de> X-Virus-Scanned: by amavisd-new X-archive-position: 1589 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krienke@uni-koblenz.de Precedence: bulk X-list: linux-xfs Content-Length: 3491 Lines: 100 --Boundary-02=_rcR+/9nJ1GiSC26 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline Hello, a happy new year to everyone on this list ... well for some of my xfs filesystems the year had a bad start. Due to a=20 powerfail on some systems that possibly rebootet and later again crashed du= e=20 to another powerfail some xfs filesystem were damaged. I could not mount=20 theses filesystems and so ran xfs_repair -L. For one filesystem (~150GB) this worked. xfs_repair reported some errors in= =20 the filesystem but finished its work. Next I tired to mount this filesystem= =20 but mount complained that it could not find a valid superblock. So I ran=20 xfs_repair once again. It still found some errors (but less than before).= =20 Next I rebootet the machine and the filesystem was mounted. Another filesystem on a second machien (~40GB) that strange enough had been= =20 mounted on reboot but was not accessible (ls /filesystem: input output erro= r)=20 could not be repaired by xfs_repair: I unmounted it, started xfs_repair and= =20 again I had to use -L since after unmounting I was no longer able to mount= =20 it. xfs_repair reported a lot more errors compared to the first filesystem= =20 from above and then in pass 4 I think when traversing the directory hierarc= hy=20 from / it segfaultet. A second and third run of xfs_repair produced each ti= me=20 more errors but always ended in a segfault. In between I recovered the data= =20 from tape, but I still have the old broken filesystem for further=20 investigation if needed.=20 Now I would like to know if this behaviour is "normal": - Can a filesystem with tansaction logging like xfs become inconsitant beca= use=20 of a power fail? There is no disk failure! - Should xfs_repair find all errors in one run (like a regular fsck does) o= r=20 do I have to run it again and again until it reports no more errors? - Is it a known issue that xfs_repair seg faults sometimes or is it perhaps= a=20 problem of my version (see below) ? - Can I do something else to avoid corrupted xfs filesystems in case of a= =20 crash. The machine is a suse linux 8.2 multiprocessor system with SuSE patched=20 kernel 2.4.21-144 (from a suse 9.0 system). The xfs kernel driver reports= =20 version 1.3.1 but I think the filesystems in question were created with an= =20 earlier kernel I guess with driver version 1.3beta. xfs_repair has version= =20 2.5.6. All filesystems are on logical volumes that are handled by lvm2. The= =20 underlying (lvm) physical volume is a software raid 1, to prevent data loss= =20 due to a disk failure.=20 Thanks for any help=20 Rainer --=20 --------------------------------------------------------------------------- Rainer Krienke, Universitaet Koblenz, Rechenzentrum, Raum A022 Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html --------------------------------------------------------------------------- --Boundary-02=_rcR+/9nJ1GiSC26 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/+Rcraldtjc/KDEoRAgrRAKCEXrzbzQGi3RzvA2L1IelacFq6LwCfa5Bk SFw1ZIhVgOOBYVVOAccb+ic= =/5EW -----END PGP SIGNATURE----- --Boundary-02=_rcR+/9nJ1GiSC26-- From owner-linux-xfs@oss.sgi.com Mon Jan 5 07:13:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 07:13: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 i05FDJTa020271 for ; Mon, 5 Jan 2004 07:13:19 -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 i05GVspx001803 for ; Mon, 5 Jan 2004 10:31:54 -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 i05FD8J727766657; Mon, 5 Jan 2004 09:13: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 i05FD8K212934326; Mon, 5 Jan 2004 09:13:08 -0600 (CST) Date: Mon, 5 Jan 2004 09:13:08 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Rainer Krienke cc: linux-xfs@oss.sgi.com Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem In-Reply-To: <200401050850.03928.krienke@uni-koblenz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1590 X-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: 4075 Lines: 92 On Mon, 5 Jan 2004, Rainer Krienke wrote: > Hello, > > a happy new year to everyone on this list ... > > well for some of my xfs filesystems the year had a bad start. Due to a > powerfail on some systems that possibly rebootet and later again crashed due > to another powerfail some xfs filesystem were damaged. I could not mount > theses filesystems and so ran xfs_repair -L. What was the failure when you first tried to mount? > For one filesystem (~150GB) this worked. xfs_repair reported some errors in > the filesystem but finished its work. Next I tired to mount this filesystem > but mount complained that it could not find a valid superblock. So I ran > xfs_repair once again. It still found some errors (but less than before). > Next I rebootet the machine and the filesystem was mounted. Unable to find a superblock immediately after repair? I have never seen this before, sounds very odd. BTW running repair twice in sucession will keep finding "errors" because the first run creates /lost+found, and the second run unlinks /lost+found then rediscovers everything that was in it as disconnected. This is a "feature" that I'd like to change some day. Moving /lost+found after the first run should make repair run cleanly the next time, unless something is really still wrong with the filesystem. In any case a successful xfs_repair run followed by a bad superblock is a big red flag indicating... something. :) > Another filesystem on a second machien (~40GB) that strange enough had been > mounted on reboot but was not accessible (ls /filesystem: input output error) > could not be repaired by xfs_repair: Sounds like the filesystem shut down due to some error, can you check your logs? In fact checking your logs in general might be useful here, I wonder if there is anything else going on. > again I had to use -L since after unmounting I was no longer able to mount > it. xfs_repair reported a lot more errors compared to the first filesystem > from above and then in pass 4 I think when traversing the directory hierarchy > from / it segfaultet. A second and third run of xfs_repair produced each time > more errors but always ended in a segfault. In between I recovered the data > from tape, but I still have the old broken filesystem for further > investigation if needed. Can you convince it to dump a corefile? We could then have a better idea of what's going wrong. > Now I would like to know if this behaviour is "normal": > > - Can a filesystem with tansaction logging like xfs become inconsitant because > of a power fail? There is no disk failure! It should not be inconsistent (disk+log should always be consistent). You may have data loss though due to cached data which never makes it to disk. > - Should xfs_repair find all errors in one run (like a regular fsck does) or > do I have to run it again and again until it reports no more errors? See above; in general it should find all errors except for the /lost+found "feature." > - Is it a known issue that xfs_repair seg faults sometimes or is it perhaps a > problem of my version (see below) ? I wonder if maybe it's failing a memory allocation for the large filesystem; I thought i remembered a (fixed) problem like this but I don't see it in the changelogs. A little gdb debugging would be a big help. > - Can I do something else to avoid corrupted xfs filesystems in case of a > crash. You shouldn't have to do anything special; let's try to get to the bottom of what happened here. > The machine is a suse linux 8.2 multiprocessor system with SuSE patched > kernel 2.4.21-144 (from a suse 9.0 system). The xfs kernel driver reports > version 1.3.1 but I think the filesystems in question were created with an > earlier kernel I guess with driver version 1.3beta. xfs_repair has version > 2.5.6. All filesystems are on logical volumes that are handled by lvm2. The > underlying (lvm) physical volume is a software raid 1, to prevent data loss > due to a disk failure. Those look like pretty recent versions of everything. -Eric From owner-linux-xfs@oss.sgi.com Mon Jan 5 07:26:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 07:27:19 -0800 (PST) Received: from imf22aec.mail.bellsouth.net (imf22aec.mail.bellsouth.net [205.152.59.70]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FQpTa021454 for ; Mon, 5 Jan 2004 07:26:51 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf22aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040105152645.PPMW1951.imf22aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Mon, 5 Jan 2004 10:26:45 -0500 Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Rainer Krienke Cc: linux-xfs@oss.sgi.com In-Reply-To: <200401050850.03928.krienke@uni-koblenz.de> References: <200401050850.03928.krienke@uni-koblenz.de> Content-Type: text/plain Message-Id: <1073315846.3512.17.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, 05 Jan 2004 10:17:27 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1591 X-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: 412 Lines: 15 On Mon, 2004-01-05 at 02:49, Rainer Krienke wrote: > - Can a filesystem with tansaction logging like xfs become inconsitant because > of a power fail? There is no disk failure! > Do you have write-caching disabled in your drives/raid controller. IIRC, XFS requires that it be disabled to ensure the transaction log works as advertised. This definately impacts speed, but ... Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Mon Jan 5 07:34:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 07:34:20 -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 i05FY8Ta026134 for ; Mon, 5 Jan 2004 07:34:08 -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 i05DguOO019090 for ; Mon, 5 Jan 2004 05:42:56 -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 i05FUnJ727691034; Mon, 5 Jan 2004 09:30: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 i05FO1K212937757; Mon, 5 Jan 2004 09:24:01 -0600 (CST) Date: Mon, 5 Jan 2004 09:24:01 -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 Maximum Entries Restriction In-Reply-To: <001601c3d36c$8c226960$a100000a@linseNew> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1592 X-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: 975 Lines: 22 I'm fairly certain that doing this will require an on-disk format change; there may be other issues as well. John Trostel had a patch at one point to allow this. Please check the archives for previous discussions of this issue, including why you may be better off using groups. -Eric On Mon, 5 Jan 2004, Linse A Pallan wrote: > Hi, > > While working with the XFS File system I found that we can have only maximum of 25 entries per ACL. Is there any way to increase this Maximum limit? I made try by changing the definition "#define XFS_ACL_MAX_ENTRIES 25" in file fs/xfs/xfs_acl.h to "#define XFS_ACL_MAX_ENTRIES 1000". After this change I rebuild the kernel and I am able to having maximum of 1000 entries per ACL. Is there any pitfalls/drawbacks in increasing the ACL maximum entries limit like this? Or is there any other way to increase the ACL Entries Maximum Limit? > > Thanking you in advance, > > Linse A Pallan > > [[HTML alternate version deleted]] > > From owner-linux-xfs@oss.sgi.com Mon Jan 5 07:38:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 07:38:14 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05Fc2Ta026588 for ; Mon, 5 Jan 2004 07:38:03 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i05FZxge004106; Mon, 5 Jan 2004 06:35:59 -0900 Date: Mon, 5 Jan 2004 06:35:59 -0900 (AKST) From: Arthur Corliss X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: Greg Freemyer cc: Rainer Krienke , linux-xfs@oss.sgi.com Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem In-Reply-To: <1073315846.3512.17.camel@david.internal.NorcrossGroup.com> Message-ID: References: <200401050850.03928.krienke@uni-koblenz.de> <1073315846.3512.17.camel@david.internal.NorcrossGroup.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1593 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@digitalmages.com Precedence: bulk X-list: linux-xfs Content-Length: 753 Lines: 21 On Mon, 5 Jan 2004, Greg Freemyer wrote: > On Mon, 2004-01-05 at 02:49, Rainer Krienke wrote: > > > - Can a filesystem with tansaction logging like xfs become inconsitant because > > of a power fail? There is no disk failure! > > > > Do you have write-caching disabled in your drives/raid controller. > > IIRC, XFS requires that it be disabled to ensure the transaction log > works as advertised. This definately impacts speed, but ... Some of the higher-end cards have battery backup for fast-write cache. You shouldn't have to disable it for those units. --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ "Live Free or Die, the Only Way to Live" -- NH State Motto From owner-linux-xfs@oss.sgi.com Mon Jan 5 08:02:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 08:02:27 -0800 (PST) Received: from campbell.mps.ohio-state.edu (campbell.mps.ohio-state.edu [128.146.38.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05G2FTa027549 for ; Mon, 5 Jan 2004 08:02:16 -0800 Received: from mps.ohio-state.edu (babar3.mps.ohio-state.edu [128.146.38.46]) by campbell.mps.ohio-state.edu (8.12.10/8.12.10) with ESMTP id i05G29Qf018423 for ; Mon, 5 Jan 2004 11:02:10 -0500 (EST) Message-ID: <3FF98A81.3060302@mps.ohio-state.edu> Date: Mon, 05 Jan 2004 11:02:09 -0500 From: Dirk Hufnagel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: new 2.4.24 kernel out - w/o XFS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1594 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hufnagel@mps.ohio-state.edu Precedence: bulk X-list: linux-xfs Content-Length: 326 Lines: 11 Looks like the 2.4.24-pre kernels have been removed and a new 2.4.24 kernel has been released, with a *very* short Changelog compared to 2.4.23. Possibly a reaction to the latest kernel security vulnerability (updated Redhat kernels are available too). It seems we will have to wait for 2.4.25 to get XFS included. Dirk From owner-linux-xfs@oss.sgi.com Mon Jan 5 08:36:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 08:37:13 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05GahTa031983 for ; Mon, 5 Jan 2004 08:36:44 -0800 Received: from localhost (localhost [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id DFF84102768 for ; Mon, 5 Jan 2004 17:24:37 +0100 (CET) Received: from nx-01.sapienti-sat.org (pD9E7FF09.dip.t-dialin.net [217.231.255.9]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 8738710254C for ; Mon, 5 Jan 2004 17:24:37 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by nx-01.sapienti-sat.org (Postfix) with SMTP id DC4AF1B05B for ; Mon, 5 Jan 2004 17:24:29 +0100 (CET) Received: from koschikode.com (pktomo.sapienti-sat.org [192.168.200.10]) by nx-01.sapienti-sat.org (Postfix) with ESMTP id A4DE61B058 for ; Mon, 5 Jan 2004 17:24:29 +0100 (CET) Message-ID: <3FF98FBD.4060601@koschikode.com> Date: Mon, 05 Jan 2004 17:24:29 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, de-de, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: new 2.4.24 kernel out - w/o XFS References: <3FF98A81.3060302@mps.ohio-state.edu> In-Reply-To: <3FF98A81.3060302@mps.ohio-state.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1595 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 566 Lines: 16 Dirk Hufnagel wrote: > Looks like the 2.4.24-pre kernels have been removed and a new > 2.4.24 kernel has been released, with a *very* short Changelog > compared to 2.4.23. Possibly a reaction to the latest kernel > security vulnerability (updated Redhat kernels are available too). > > It seems we will have to wait for 2.4.25 to get XFS included. Yep, Marcello said that all changes that are present in the 2.4.24-pre kernels are postponed due to the recent security issues and will re-appear in the 2.4.25-pre patches. I do appreaciate this step. Cheers, Juri From owner-linux-xfs@oss.sgi.com Mon Jan 5 08:44:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 08:45:18 -0800 (PST) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05GipTa032587 for ; Mon, 5 Jan 2004 08:44:54 -0800 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id i05GiWoL017515 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 6 Jan 2004 02:44:39 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.10/8.12.10) with ESMTP id i05Ggrk5004961 for ; Mon, 5 Jan 2004 11:42:53 -0500 Date: Mon, 5 Jan 2004 11:42:53 -0500 (EST) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: linux-xfs@oss.sgi.com Subject: Re: new 2.4.24 kernel out - w/o XFS In-Reply-To: <3FF98A81.3060302@mps.ohio-state.edu> Message-ID: References: <3FF98A81.3060302@mps.ohio-state.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1596 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs Content-Length: 908 Lines: 23 On Mon, 5 Jan 2004, Dirk Hufnagel wrote: > Looks like the 2.4.24-pre kernels have been removed and a new > 2.4.24 kernel has been released, with a *very* short Changelog > compared to 2.4.23. Possibly a reaction to the latest kernel > security vulnerability (updated Redhat kernels are available too). > > It seems we will have to wait for 2.4.25 to get XFS included. This was discussed on some other lists. It looks like Marcelo keeps a seperate tree with just critial updates in order to be able to push out a new kernel quickly in an emergency. I think this is an admirable practice. I'd rather have a secure kernel out more quickly even if it is sans XFS for a few more weeks. Cheers, Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, zzbrock@uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Mon Jan 5 08:48:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 08:48:28 -0800 (PST) Received: from eclectic.kluge.net (eclectic.kluge.net [66.92.69.221]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05GmGTa000642 for ; Mon, 5 Jan 2004 08:48:16 -0800 Received: by eclectic.kluge.net (Postfix, from userid 501) id 7780843E5CD; Mon, 5 Jan 2004 11:48:02 -0500 (EST) Date: Mon, 5 Jan 2004 11:48:02 -0500 From: Theo Van Dinter To: Linux XFS List Subject: 1.3.1 patches against ES/AS kernels? Message-ID: <20040105164802.GG1385@kluge.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S5HS5MvDw4DmbRmb" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-GPG-Keyserver: http://pgp.mit.edu/ X-GPG-Keynumber: 0x9697572A X-GPG-Fingerprint: A849 1D50 DB62 0B54 92F6 E2C8 EED8 0A00 9697 572A X-GPG-URL: http://www.kluge.net/~felicity/pgp.html X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-archive-position: 1597 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: felicity@kluge.net Precedence: bulk X-list: linux-xfs Content-Length: 995 Lines: 35 --S5HS5MvDw4DmbRmb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've recently upgraded my machine from RH 7.3 to ES3. I'm using a custom 2.4.23 kernel w/ CVS+LVM patches, but would like to use the RedHat kernel so I can get the new threading support (and therefore let certain thread-using daemons work ...) I'm trying to merge in 1.3.1 into the kernel-2.4.21-4.0.1.EL RPM, but figured if someone else already has a patch for XFS, it would save me time. :) TIA. :) --=20 Randomly Generated Tagline: "If you think I've answered your question, then I haven't been sufficiently vague." - R. Gary Cutbill --S5HS5MvDw4DmbRmb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/+ZVC7tgKAJaXVyoRAjcjAJ90HrYv4rCPalqstm4Bzr3LvV3TBQCgtspG 3gFsVtt7Qe84vlGo6XYbl8w= =rKGb -----END PGP SIGNATURE----- --S5HS5MvDw4DmbRmb-- From owner-linux-xfs@oss.sgi.com Mon Jan 5 09:02:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 09:02:16 -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 i05H22Ta001416 for ; Mon, 5 Jan 2004 09:02:03 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.8) with ESMTP id i05H1UYu027192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Jan 2004 18:01:31 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i05H1QSX030585; Mon, 5 Jan 2004 18:01:26 +0100 Date: Mon, 5 Jan 2004 18:01:26 +0100 From: Axel Thimm To: Theo Van Dinter Cc: Linux XFS List Subject: Re: 1.3.1 patches against ES/AS kernels? Message-ID: <20040105170126.GE27421@neu.nirvana> References: <20040105164802.GG1385@kluge.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T7mxYSe680VjQnyC" Content-Disposition: inline In-Reply-To: <20040105164802.GG1385@kluge.net> User-Agent: Mutt/1.4.1i X-archive-position: 1598 X-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: 1253 Lines: 38 --T7mxYSe680VjQnyC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 05, 2004 at 11:48:02AM -0500, Theo Van Dinter wrote: > I've recently upgraded my machine from RH 7.3 to ES3. I'm using > a custom 2.4.23 kernel w/ CVS+LVM patches, but would like to use the > RedHat kernel so I can get the new threading support (and therefore let > certain thread-using daemons work ...) >=20 > I'm trying to merge in 1.3.1 into the kernel-2.4.21-4.0.1.EL RPM, but > figured if someone else already has a patch for XFS, it would save me > time. :) Until there is a patch for RHEL3, you could try the FC1 kernel at ATrpms which only lacks the backported 2.6/ipsec, otherwise it has been reported to work well on RHEL3. As there will be a kernel errata for FC1 later today, you should wait until new ATrpms are available, if you want to go that way. --=20 Axel.Thimm@physik.fu-berlin.de --T7mxYSe680VjQnyC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQE/+ZhmQBVS1GOamfERAn2RAJ0crOalO1JqkGZ9qxhB9QkoXrhBOgCdHLN+ MidroWJdbIE2o5QUQReCce4= =GjuN -----END PGP SIGNATURE----- --T7mxYSe680VjQnyC-- From owner-linux-xfs@oss.sgi.com Mon Jan 5 09:10:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 09:10:18 -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 i05HA6Ta002034 for ; Mon, 5 Jan 2004 09:10:07 -0800 Received: (qmail 31215 invoked by uid 777); 5 Jan 2004 17:10:08 -0000 Date: Mon, 5 Jan 2004 18:10:08 +0100 From: Karol Kozimor To: linux-xfs@oss.sgi.com Subject: Re: new 2.4.24 kernel out - w/o XFS Message-ID: <20040105171008.GB9375@hell.org.pl> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3FF98A81.3060302@mps.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 1599 X-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: 353 Lines: 13 Thus wrote Robert Brockway: > new kernel quickly in an emergency. I think this is an admirable > practice. I'd rather have a secure kernel out more quickly even if it is > sans XFS for a few more weeks. Especially that it is doubtful that the 2.4.25 is delayed more than 2.4.24 would be. Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Mon Jan 5 09:13:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 09:13:54 -0800 (PST) Received: from mail.mnsu.edu ([134.29.1.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05HDgTa002485 for ; Mon, 5 Jan 2004 09:13:43 -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 i05HDZJY030034 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 5 Jan 2004 11:13:35 -0600 Message-ID: <3FF99B3F.8060208@mnsu.edu> Date: Mon, 05 Jan 2004 11:13: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: linux-xfs@oss.sgi.com Subject: [Fwd: Re: mremap bug and 2.4?] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1600 X-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: 1201 Lines: 37 FYI: in case you didn't notice it on Linux-kernel. -------- Original Message -------- Subject: Re: mremap bug and 2.4? Date: Mon, 5 Jan 2004 13:26:23 -0200 (BRST) From: Marcelo Tosatti To: Robert L. Harris CC: Linux-Kernel References: <20040105145421.GC2247@rdlg.net> On Mon, 5 Jan 2004, Robert L. Harris wrote: > > > Just read this on full disclosure: > > http://isec.pl/vulnerabilities/isec-0013-mremap.txt > > Is it valid? No working proof of concept code has been posted so I can't > test my systems. The article only lists 2.4 and 2.6. Is this > 2.4.16-current, etc? Anyone have any details about versions that are > safe so I/We can determine if I need to roll a new production kernel out > again? It is possible that the problem is exploitable. There is no known public exploit yet, however. 2.4.24 includes a fix for this (mm/mremap.c diff) - 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 Jan 5 11:11:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 11:11:26 -0800 (PST) Received: from mail-h12-02.cc.ksu.edu (mail-h12-02.cc.ksu.edu [129.130.12.151]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05JB4Ta006905 for ; Mon, 5 Jan 2004 11:11:04 -0800 Received: from unix1.cc.ksu.edu (unix1.cc.ksu.edu [129.130.12.3]) by mail-h12-02.cc.ksu.edu (8.12.9/8.12.9) with ESMTP id i05JB3vL028741; Mon, 5 Jan 2004 13:11:03 -0600 (CST) Received: from localhost (matts@localhost) by unix1.cc.ksu.edu (8.8.8+Sun/8.8.8) with ESMTP id NAA01029; Mon, 5 Jan 2004 13:11:03 -0600 (CST) X-Authentication-Warning: unix1.cc.ksu.edu: matts owned process doing -bs Date: Mon, 5 Jan 2004 13:11:02 -0600 (CST) From: Matt Stegman X-X-Sender: matts@unix1.cc.ksu.edu To: AndyLiebman@aol.com cc: linux-xfs@oss.sgi.com Subject: Re: XFS under 2.6 kernel In-Reply-To: <14b.28cacee8.2d28309e@aol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1601 X-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: 918 Lines: 25 I don't know about anything specific to 2.6, but I know that software RAID5 doesn't work as smoothly with XFS as with ext2/3 or reiserfs. Since XFS uses sector size for log writes and block size for data writes, make sure they're the same size on Linux software RAID5. Otherwise the RAID system will be constantly flushing it's cache, which will slow things down a lot. So if your filesystem will have 4k blocks, make it with: mkfs.xfs -d size=4096 -s size=4096 ... /dev/md0 This was under the 2.4 kernel, but I don't think that part of the RAID system has changed with 2.6. -- Matt Stegman On Sat, 3 Jan 2004 AndyLiebman@aol.com wrote: > Is there any "definitive word" about whether it's safe to use xfs under the > released version of the 2.6 kernel? Also, is there anything to watch out for > using xfs plus software RAID5? If anybody has this information, it might be > nice to post it. > > Andy Liebman From owner-linux-xfs@oss.sgi.com Mon Jan 5 11:21:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 11:21:59 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05JLjTa007937 for ; Mon, 5 Jan 2004 11:21:46 -0800 Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AdaIK-0008JF-00 for linux-xfs@oss.sgi.com; Mon, 05 Jan 2004 20:21:44 +0100 Received: from [80.129.79.148] (helo=krienke.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AdaIK-0006Lz-00 for linux-xfs@oss.sgi.com; Mon, 05 Jan 2004 20:21:44 +0100 Received: from 127.0.0.1 (ident=unknown) by krienke.org with esmtp (masqmail 0.2.18) id 1AdaJI-5Un-00 for ; Mon, 05 Jan 2004 20:22:44 +0100 From: Rainer krienke To: linux-xfs@oss.sgi.com Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem Date: Mon, 5 Jan 2004 20:22:44 +0100 User-Agent: KMail/1.5.4 References: <200401050850.03928.krienke@uni-koblenz.de> <1073315846.3512.17.camel@david.internal.NorcrossGroup.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Emb+/W63lA/yDZT"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401052022.44427.rainer@krienke.org> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:bc73c4e44fefa2230c0ea7a2ec38b3fe X-archive-position: 1602 X-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@krienke.org Precedence: bulk X-list: linux-xfs Content-Length: 1723 Lines: 57 --Boundary-02=_Emb+/W63lA/yDZT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline Am Montag, 5. Januar 2004 16:35 schrieben Sie: > On Mon, 5 Jan 2004, Greg Freemyer wrote: > > On Mon, 2004-01-05 at 02:49, Rainer Krienke wrote: > > > > > > > - Can a filesystem with tansaction logging like xfs become inconsitant > > > because of a power fail? There is no disk failure! > > > > Do you have write-caching disabled in your drives/raid controller. > > > > IIRC, XFS requires that it be disabled to ensure the transaction log > > works as advertised. This definately impacts speed, but ... > > Some of the higher-end cards have battery backup for fast-write cache. Y= ou > shouldn't have to disable it for those units. The basis for storage are IFT 7250 Raids with IDE disks inside (external it= s=20 running fibrechannel). The device is configures as raid level 5. I looked= =20 into the serial vt100 based control interface but there was no option to=20 enable or disable any kind of cache. The specs say it has a cache but I am= =20 unsure if its a read only or a read/write cache. The specs don't say anythi= ng=20 about this nor if there is a battery backup. I think I'll ask the=20 manufacturer or my vendor. Thanks for the hint Rainer --=20 Rainer Krienke, rainer@krienke.org --Boundary-02=_Emb+/W63lA/yDZT Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/+bmEaldtjc/KDEoRAupIAJsE9AuQ5sS5LSIX23SbuuqK1reQdACeKUNc T9CAORmGcYOoJONeXWZ+1pg= =UV5A -----END PGP SIGNATURE----- --Boundary-02=_Emb+/W63lA/yDZT-- From owner-linux-xfs@oss.sgi.com Mon Jan 5 11:47:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 11:47:56 -0800 (PST) Received: from ra.elvis.ru (ra.elvis.ru [194.190.192.34]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05JlQTa008934 for ; Mon, 5 Jan 2004 11:47:32 -0800 Received: from wolf.office.elvis.ru (localhost [127.0.0.1]) by ra.elvis.ru (8.11.6+Sun/8.11.6) with ESMTP id i05HT3D06325 for ; Mon, 5 Jan 2004 20:29:03 +0300 (MSK) Date: Mon, 5 Jan 2004 20:29:04 +0300 From: "Max V. Kosmach" X-Mailer: The Bat! (v2.01) UNREG / CD5BF9353B3B7091 Reply-To: "Max V. Kosmach" Organization: Elvis+ X-Priority: 3 (Normal) Message-ID: <129944663894.20040105202904@elvis.ru> To: linux-xfs@oss.sgi.com Subject: mail list web archive do not work MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1603 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: max@tcen.ru Precedence: bulk X-list: linux-xfs Content-Length: 148 Lines: 8 Hello linux-xfs, please check web-archive - don't work since november 7, 2003 :( Best regards, Max mailto:max@tcen.ru From owner-linux-xfs@oss.sgi.com Mon Jan 5 12:07:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 12:07:30 -0800 (PST) Received: from imo-r01.mx.aol.com (imo-r01.mx.aol.com [152.163.225.97]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05K78Ta009784 for ; Mon, 5 Jan 2004 12:07:08 -0800 Received: from AndyLiebman@aol.com by imo-r01.mx.aol.com (mail_out_v36_r4.8.) id 6.188.23865328 (16781); Mon, 5 Jan 2004 15:06:59 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <188.23865328.2d2b1de1@aol.com> Date: Mon, 5 Jan 2004 15:06:57 EST Subject: Re: XFS under 2.6 kernel To: matts@ksu.edu CC: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5006 X-archive-position: 1604 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 1362 Lines: 37 Matt, Thanks for the reply. I have already made my RAID5 software arrays and they have data on them so I can't remake the filesystem now. But can you tell me if there's a way to check what the sector size is on the current filesystem? I ran mkfs.xfs with the block size = 4096. I didn't specifiy a sector size. Is the default also 4096? Andy Liebman In a message dated 1/5/2004 2:11:09 PM Eastern Standard Time, matts@ksu.edu writes: I don't know about anything specific to 2.6, but I know that software RAID5 doesn't work as smoothly with XFS as with ext2/3 or reiserfs. Since XFS uses sector size for log writes and block size for data writes, make sure they're the same size on Linux software RAID5. Otherwise the RAID system will be constantly flushing it's cache, which will slow things down a lot. So if your filesystem will have 4k blocks, make it with: mkfs.xfs -d size=4096 -s size=4096 ... /dev/md0 This was under the 2.4 kernel, but I don't think that part of the RAID system has changed with 2.6. -- Matt Stegman On Sat, 3 Jan 2004 AndyLiebman@aol.com wrote: > Is there any "definitive word" about whether it's safe to use xfs under the > released version of the 2.6 kernel? Also, is there anything to watch out for > using xfs plus software RAID5? If anybody has this information, it might be > nice to post it. > > Andy Liebman From owner-linux-xfs@oss.sgi.com Mon Jan 5 12:22:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 12:22: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 i05KM6Ta013685 for ; Mon, 5 Jan 2004 12:22:06 -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 i05Lehpx026795 for ; Mon, 5 Jan 2004 15:40:43 -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 i05KKNjP27808490; Mon, 5 Jan 2004 14:20:23 -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 i05KKNoZ2998363; Mon, 5 Jan 2004 14:20:23 -0600 (CST) Subject: Re: mail list web archive do not work From: Russell Cattelan To: "Max V. Kosmach" Cc: linux-xfs@oss.sgi.com In-Reply-To: <129944663894.20040105202904@elvis.ru> References: <129944663894.20040105202904@elvis.ru> Content-Type: text/plain Message-Id: <1073334023.31678.10038.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-2mdk Date: Mon, 05 Jan 2004 14:20:23 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1605 X-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: 274 Lines: 13 Looks fine to me? http://oss.sgi.com/archives/linux-xfs/ On Mon, 2004-01-05 at 11:29, Max V. Kosmach wrote: > Hello linux-xfs, > > please check web-archive - don't work since november 7, 2003 :( > > > Best regards, > Max mailto:max@tcen.ru > From owner-linux-xfs@oss.sgi.com Mon Jan 5 12:26:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 12:26:34 -0800 (PST) Received: from mail-h12-02.cc.ksu.edu (mail-h12-02.cc.ksu.edu [129.130.12.151]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05KQCTa014268 for ; Mon, 5 Jan 2004 12:26:13 -0800 Received: from unix1.cc.ksu.edu (unix1.cc.ksu.edu [129.130.12.3]) by mail-h12-02.cc.ksu.edu (8.12.9/8.12.9) with ESMTP id i05KQBvL019280; Mon, 5 Jan 2004 14:26:12 -0600 (CST) Received: from localhost (matts@localhost) by unix1.cc.ksu.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA03595; Mon, 5 Jan 2004 14:26:11 -0600 (CST) X-Authentication-Warning: unix1.cc.ksu.edu: matts owned process doing -bs Date: Mon, 5 Jan 2004 14:26:11 -0600 (CST) From: Matt Stegman X-X-Sender: matts@unix1.cc.ksu.edu To: AndyLiebman@aol.com cc: linux-xfs@oss.sgi.com Subject: Re: XFS under 2.6 kernel In-Reply-To: <188.23865328.2d2b1de1@aol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1606 X-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: 1135 Lines: 31 xfs_info will report everything mkfs prints out at creation time, including block size and sector size. You run it on the mount point, not the device: xfs_info /mnt/xfs The default sector size would be 512. Also, check your system log or run dmesg. When the RAID5 flushes cache you get a message: Jan 5 13:10:49 elijah kernel: raid5: switching cache buffer size, 512 --> 4096 A symptom of the problem is that when I made XFS filesystems without specifying 4096 byte sectors I was getting dozens of these messages in the system log each second when writing to an XFS volume. If you're not seeing too many of these messages when doing something like "cp -a /usr /mnt/xfs", then you shouldn't have a problem. -- Matt Stegman On Mon, 5 Jan 2004 AndyLiebman@aol.com wrote: > Matt, > > Thanks for the reply. I have already made my RAID5 software arrays and they > have data on them so I can't remake the filesystem now. But can you tell me if > there's a way to check what the sector size is on the current filesystem? I > ran mkfs.xfs with the block size = 4096. I didn't specifiy a sector size. Is > the default also 4096? From owner-linux-xfs@oss.sgi.com Mon Jan 5 12:44:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 12:44:52 -0800 (PST) Received: from rei (82-33-8-63.cable.ubr14.newt.blueyonder.co.uk [82.33.8.63]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05KiUTa015060 for ; Mon, 5 Jan 2004 12:44:31 -0800 Received: from rei ([127.0.0.1] helo=localhost) by rei with esmtp (Exim 3.36 #1 (Debian)) id 1AdbaP-0000Nw-00 for ; Mon, 05 Jan 2004 20:44:29 +0000 Subject: power failure .. broken files.. broken FS :(. From: Daniel Palmer Reply-To: danielpalmer@myrealbox.com To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1073335468.1440.12.camel@rei> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Jan 2004 20:44:29 +0000 Content-Transfer-Encoding: 7bit X-archive-position: 1607 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: danielpalmer@myrealbox.com Precedence: bulk X-list: linux-xfs Content-Length: 4227 Lines: 113 I had a power failure a couple days ago, didn't think anything about it and continued using my system as normal until all but 2 files in a directory didn't want to open in xmms this morning. So I un-mounted the filesystem and ran xfs_repair on it: rei:/# xfs_repair /dev/hdb1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 correcting nblocks for inode 44179985, was 0 - counted 8 correcting nblocks for inode 44180026, was 0 - counted 8 - agno = 3 correcting nblocks for inode 55046098, was 0 - counted 2 - agno = 4 correcting nblocks for inode 72672635, was 0 - counted 8 - agno = 5 - agno = 6 - agno = 7 - agno = 8 correcting nblocks for inode 138982095, was 0 - counted 10 correcting nblocks for inode 138982136, was 0 - counted 8 - agno = 9 - agno = 10 - agno = 11 correcting nblocks for inode 193438914, was 0 - counted 7 - agno = 12 correcting nblocks for inode 205774557, was 0 - counted 22 - agno = 13 - agno = 14 correcting nblocks for inode 241413320, was 0 - counted 9 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 data fork in regular inode 44179985 claims used block 3013232 correcting nblocks for inode 44179985, was 8 - counted 0 data fork in regular inode 44180026 claims used block 6158960 correcting nblocks for inode 44180026, was 8 - counted 0 - agno = 3 data fork in regular inode 55046098 claims used block 4061808 correcting nblocks for inode 55046098, was 2 - counted 0 - agno = 4 data fork in regular inode 72672635 claims used block 5110384 correcting nblocks for inode 72672635, was 8 - counted 0 - agno = 5 - agno = 6 - agno = 7 - agno = 8 data fork in regular inode 138982095 claims used block 9304688 correcting nblocks for inode 138982095, was 10 - counted 0 data fork in regular inode 138982136 claims used block 10353264 correcting nblocks for inode 138982136, was 8 - counted 0 - agno = 9 - agno = 10 - agno = 11 data fork in regular inode 193438914 claims used block 12450416 correcting nblocks for inode 193438914, was 7 - counted 0 - agno = 12 data fork in regular inode 205774557 claims used block 13498992 correcting nblocks for inode 205774557, was 22 - counted 0 - agno = 13 - agno = 14 data fork in regular inode 241413320 claims used block 15596144 correcting nblocks for inode 241413320, was 9 - counted 0 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... corrupt dinode 44179985, extent total = 1, nblocks = 0. Unmount and run xfs_repair. fatal error -- couldn't map inode 44179985, err = 990 The files I couldn't access are now gone (to where no one knows) but they're of little importance. But I get the same output everytime and get no further :(, lost+found is also empty but running find on the fs presented this "find: ./_torrents/chobits_7_1024.jpg: Unknown error 990". I'm running Debian/Unstable on 2.6.0. If anyone can help to get this sorted.. Please help me!! :) Cheers, Daniel Palmer From owner-linux-xfs@oss.sgi.com Mon Jan 5 12:49:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 12:49:53 -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 i05KnYTa015569 for ; Mon, 5 Jan 2004 12:49: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 i05Kqw17032694; Mon, 5 Jan 2004 15:52:58 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id i05Kqwo5032691; Mon, 5 Jan 2004 15:52:58 -0500 Date: Mon, 5 Jan 2004 15:52:58 -0500 (EST) From: Net Llama! To: Daniel Palmer cc: linux-xfs@oss.sgi.com Subject: Re: power failure .. broken files.. broken FS :(. In-Reply-To: <1073335468.1440.12.camel@rei> Message-ID: References: <1073335468.1440.12.camel@rei> 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: 1608 X-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: 1125 Lines: 26 On Mon, 5 Jan 2004, Daniel Palmer wrote: > I had a power failure a couple days ago, didn't think anything about it > and continued using my system as normal until all but 2 files in a > directory didn't want to open in xmms this morning. [SNIP] > Phase 7 - verify and correct link counts... > corrupt dinode 44179985, extent total = 1, nblocks = 0. Unmount and run > xfs_repair. > fatal error -- couldn't map inode 44179985, err = 990 > > The files I couldn't access are now gone (to where no one knows) but > they're of little importance. But I get the same output everytime and > get no further :(, lost+found is also empty but running find on the fs > presented this "find: ./_torrents/chobits_7_1024.jpg: Unknown error > 990". I'm pretty sure that you have to manually delete lost+found (from the partition where you're running xfs_repair) after each run of xfs_repair. Othewise, it just keeps repairing the same stuff over & over again. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Mon Jan 5 12:53:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 12:53:29 -0800 (PST) Received: from rei (82-33-8-63.cable.ubr14.newt.blueyonder.co.uk [82.33.8.63]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05KrFTa016046 for ; Mon, 5 Jan 2004 12:53:17 -0800 Received: from rei ([127.0.0.1] helo=localhost) by rei with esmtp (Exim 3.36 #1 (Debian)) id 1Adbir-0000OZ-00 for ; Mon, 05 Jan 2004 20:53:13 +0000 Subject: Re: power failure .. broken files.. broken FS :(. From: Daniel Palmer Reply-To: danielpalmer@myrealbox.com To: linux-xfs@oss.sgi.com In-Reply-To: References: <1073335468.1440.12.camel@rei> Content-Type: text/plain Message-Id: <1073335989.1440.15.camel@rei> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Jan 2004 20:53:09 +0000 Content-Transfer-Encoding: 7bit X-archive-position: 1609 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: danielpalmer@myrealbox.com Precedence: bulk X-list: linux-xfs Content-Length: 324 Lines: 13 > I'm pretty sure that you have to manually delete lost+found > (from the partition where you're running xfs_repair) after each run of > xfs_repair. Othewise, it just keeps repairing the same stuff over & over > again. I've tried removing lost+found many times .. same output from xfs_repair :(. Cheers, Daniel Palmer From owner-linux-xfs@oss.sgi.com Mon Jan 5 12:57:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 12:57:18 -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 i05Kv6Ta016519 for ; Mon, 5 Jan 2004 12:57:06 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id i05L0U17000803; Mon, 5 Jan 2004 16:00:30 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id i05L0Uxa000800; Mon, 5 Jan 2004 16:00:30 -0500 Date: Mon, 5 Jan 2004 16:00:30 -0500 (EST) From: Net Llama! To: Daniel Palmer cc: linux-xfs@oss.sgi.com Subject: Re: power failure .. broken files.. broken FS :(. In-Reply-To: <1073335989.1440.15.camel@rei> Message-ID: References: <1073335468.1440.12.camel@rei> <1073335989.1440.15.camel@rei> 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: 1610 X-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: 576 Lines: 17 On Mon, 5 Jan 2004, Daniel Palmer wrote: > > > I'm pretty sure that you have to manually delete lost+found > > (from the partition where you're running xfs_repair) after each run of > > xfs_repair. Othewise, it just keeps repairing the same stuff over & over > > again. > > I've tried removing lost+found many times .. same output from xfs_repair > :(. What version of xfs_progs are you using? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Mon Jan 5 13:02:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 13:03:03 -0800 (PST) Received: from rei (82-33-8-63.cable.ubr14.newt.blueyonder.co.uk [82.33.8.63]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05L2oTa017456 for ; Mon, 5 Jan 2004 13:02:51 -0800 Received: from rei ([127.0.0.1] helo=localhost) by rei with esmtp (Exim 3.36 #1 (Debian)) id 1Adbs9-0000QZ-00 for ; Mon, 05 Jan 2004 21:02:49 +0000 Subject: Re: power failure .. broken files.. broken FS :(. From: Daniel Palmer Reply-To: danielpalmer@myrealbox.com To: linux-xfs@oss.sgi.com In-Reply-To: References: <1073335468.1440.12.camel@rei> <1073335989.1440.15.camel@rei> Content-Type: text/plain Message-Id: <1073336568.1440.18.camel@rei> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Jan 2004 21:02:49 +0000 Content-Transfer-Encoding: 7bit X-archive-position: 1611 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: danielpalmer@myrealbox.com Precedence: bulk X-list: linux-xfs Content-Length: 127 Lines: 9 > What version of xfs_progs are you using? 2.6.0(-1) .. I think, that's the version apt says it is. Cheers, Daniel Palmer From owner-linux-xfs@oss.sgi.com Mon Jan 5 14:44:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 14:44:52 -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 i05MieTa021218 for ; Mon, 5 Jan 2004 14:44:41 -0800 Received: from lapprose.ii.uib.no ([129.177.20.37]:32999) by mail.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1AddSU-0004MG-Rj for linux-xfs@oss.sgi.com; Mon, 05 Jan 2004 23:44:26 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.8/8.12.8/Submit) id i05MiPGL024017 for linux-xfs@oss.sgi.com; Mon, 5 Jan 2004 23:44:25 +0100 Date: Mon, 5 Jan 2004 23:44:25 +0100 From: Jan-Frode Myklebust To: linux-xfs@oss.sgi.com Subject: mremap fix / kernel-2.4.20-28.9.XFS1.3.1 Message-ID: <20040105224425.GA19311@ii.uib.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 1612 X-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.no Precedence: bulk X-list: linux-xfs Content-Length: 550 Lines: 20 I've merged the RedHat-9 kernel-2.4.20-28.9 and the SGI kernel-2.4.20-20.9.XFS1.3.1 and am in the process of rebuilding this for i386, i586, i686 and athlon. If anybody want the SRPM it's available at: ftp://ftp.ii.uib.no/pub/janfrode/XFS/rh9/SRPMS/kernel-2.4.20-28.9.XFS1.3.1.src.rpm the binaries should appear soon under: ftp://ftp.ii.uib.no/pub/janfrode/XFS/rh9/ I will build the RedHat-8 kernels tomorrow. Unfortunately I haven't had time to do any testing on these yet, but expect them to be OK. Feedback will be appreciated. -jf From owner-linux-xfs@oss.sgi.com Mon Jan 5 15:27:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 15:27:57 -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 i05NRkTa028348 for ; Mon, 5 Jan 2004 15:27:46 -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 i05LaZOO016254 for ; Mon, 5 Jan 2004 13:36: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 i05NRd2f27789947; Mon, 5 Jan 2004 17:27: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 i05NRdK212951549; Mon, 5 Jan 2004 17:27:39 -0600 (CST) Date: Mon, 5 Jan 2004 17:27:39 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Daniel Palmer cc: linux-xfs@oss.sgi.com Subject: Re: power failure .. broken files.. broken FS :(. In-Reply-To: <1073335468.1440.12.camel@rei> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1613 X-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: 1143 Lines: 36 On Mon, 5 Jan 2004, Daniel Palmer wrote: > So I un-mounted the filesystem and ran xfs_repair on it: > > rei:/# xfs_repair /dev/hdb1 ... > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > - agno = 1 > - agno = 2 > correcting nblocks for inode 44179985, was 0 - counted 8 ... > Phase 4 - check for duplicate blocks... > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 1 > - agno = 2 > data fork in regular inode 44179985 claims used block 3013232 > correcting nblocks for inode 44179985, was 8 - counted 0 ... > Phase 7 - verify and correct link counts... > corrupt dinode 44179985, extent total = 1, nblocks = 0. Unmount and run > xfs_repair. > fatal error -- couldn't map inode 44179985, err = 990 That looks a little odd, repair can't seem to decide how many blocks that inode should have, waffling between 8 and 0. does the -v option give you any more interesting info? how big is this filesystem, btw, and what does xfs_info output look like. -Eric From owner-linux-xfs@oss.sgi.com Mon Jan 5 16:25:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 16:26: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 i060PbTa032740 for ; Mon, 5 Jan 2004 16:25:38 -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 i05MYQOO029529 for ; Mon, 5 Jan 2004 14:34:26 -0800 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id 81F2189E374; Mon, 5 Jan 2004 18:25:12 -0600 (CST) Subject: PARTIAL TAKE 904566 - Add kdb to tree Message-Id: <20040106002512.81F2189E374@naboo.americas.sgi.com> Date: Mon, 5 Jan 2004 18:25:12 -0600 (CST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1614 X-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: 2537 Lines: 90 Date: Mon Jan 5 16:24:28 PST 2004 Workarea: naboo.americas.sgi.com:/go/space/XFS/2.4.x-xfs+kdb The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:164201a kdb/Makefile - 1.1 Documentation/kdb/dump.txt - 1.1 Documentation/kdb/kdb.mm - 1.1 Documentation/kdb/kdb_bp.man - 1.1 Documentation/kdb/kdb_bt.man - 1.1 Documentation/kdb/kdb_env.man - 1.1 Documentation/kdb/kdb_ll.man - 1.1 Documentation/kdb/kdb_md.man - 1.1 Documentation/kdb/kdb_rd.man - 1.1 Documentation/kdb/kdb_sr.man - 1.1 Documentation/kdb/kdb_ss.man - 1.1 Documentation/kdb/slides - 1.1 kdb/ChangeLog - 1.1 kdb/kdb_bp.c - 1.1 kdb/kdb_bt.c - 1.1 arch/i386/kdb/ChangeLog - 1.1 arch/i386/kdb/Makefile - 1.1 arch/i386/kdb/ansidecl.h - 1.1 arch/i386/kdb/bfd.h - 1.1 arch/i386/kdb/i386-dis.c - 1.1 arch/i386/kdb/kdba_bp.c - 1.1 arch/i386/kdb/kdba_bt.c - 1.1 arch/i386/kdb/kdba_id.c - 1.1 arch/i386/kdb/kdba_io.c - 1.1 arch/i386/kdb/kdbasupport.c - 1.1 kdb/kdb_cmds - 1.1 include/linux/kdbprivate.h - 1.1 include/linux/kdb.h - 1.1 include/linux/kallsyms.h - 1.1 include/linux/dis-asm.h - 1.1 kdb/kdb_id.c - 1.1 kdb/kdb_io.c - 1.1 kdb/kdbmain.c - 1.1 include/asm-i386/kdbprivate.h - 1.1 include/asm-i386/kdb.h - 1.1 kdb/kdbsupport.c - 1.1 kdb/modules/Makefile - 1.1 kdb/modules/kdbm_pg.c - 1.1 kdb/modules/kdbm_task.c - 1.1 kdb/modules/kdbm_vm.c - 1.1 kernel/kallsyms.c - 1.1 kdb/modules/kdbm_x86.c - 1.1 Documentation/Configure.help - 1.2 Makefile - 1.2 arch/i386/Makefile - 1.2 arch/i386/config.in - 1.2 arch/i386/kernel/bluesmoke.c - 1.2 arch/i386/kernel/entry.S - 1.2 arch/i386/kernel/i8259.c - 1.2 arch/i386/kernel/io_apic.c - 1.2 arch/i386/kernel/irq.c - 1.2 arch/i386/kernel/nmi.c - 1.2 arch/i386/kernel/process.c - 1.2 arch/i386/kernel/smp.c - 1.2 arch/i386/kernel/smpboot.c - 1.2 arch/i386/kernel/traps.c - 1.2 arch/i386/vmlinux.lds - 1.2 drivers/char/keyboard.c - 1.2 drivers/char/serial.c - 1.2 drivers/char/sn_serial.c - 1.2 drivers/sbus/char/sab82532.c - 1.2 drivers/sbus/char/su.c - 1.2 drivers/sbus/char/sunkbd.c - 1.2 drivers/sbus/char/sunkeymap.c - 1.2 drivers/usb/hid-core.c - 1.2 drivers/usb/host/usb-uhci.c - 1.2 drivers/usb/usbkbd.c - 1.2 include/asm-i386/hw_irq.h - 1.2 include/asm-i386/keyboard.h - 1.2 include/asm-i386/kmap_types.h - 1.2 include/asm-i386/ptrace.h - 1.2 include/linux/module.h - 1.2 include/linux/sysctl.h - 1.2 init/main.c - 1.2 kernel/Makefile - 1.2 kernel/ksyms.c - 1.2 kernel/module.c - 1.2 kernel/printk.c - 1.2 kernel/sched.c - 1.2 kernel/sysctl.c - 1.2 mm/memory.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jan 5 16:29:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 16:30:00 -0800 (PST) Received: from rei (82-33-8-63.cable.ubr14.newt.blueyonder.co.uk [82.33.8.63]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i060TmTa000751 for ; Mon, 5 Jan 2004 16:29:49 -0800 Received: from rei ([127.0.0.1] helo=localhost) by rei with esmtp (Exim 3.36 #1 (Debian)) id 1Adf6Q-0000aV-00 for ; Tue, 06 Jan 2004 00:29:46 +0000 Subject: Re: power failure .. broken files.. broken FS :(. From: Daniel Palmer Reply-To: danielpalmer@myrealbox.com To: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1073348985.1440.35.camel@rei> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 06 Jan 2004 00:29:45 +0000 Content-Transfer-Encoding: 7bit X-archive-position: 1615 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: danielpalmer@myrealbox.com Precedence: bulk X-list: linux-xfs Content-Length: 4815 Lines: 126 > That looks a little odd, repair can't seem to decide how many > blocks that inode should have, waffling between 8 and 0. > > does the -v option give you any more interesting info? rei:/# xfs_repair -v /dev/hdb1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 6687 tail block 6687 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 correcting nblocks for inode 44179985, was 0 - counted 8 correcting nblocks for inode 44180026, was 0 - counted 8 - agno = 3 correcting nblocks for inode 55046098, was 0 - counted 2 - agno = 4 correcting nblocks for inode 72672635, was 0 - counted 8 - agno = 5 - agno = 6 - agno = 7 - agno = 8 correcting nblocks for inode 138982095, was 0 - counted 10 correcting nblocks for inode 138982136, was 0 - counted 8 - agno = 9 - agno = 10 - agno = 11 correcting nblocks for inode 193438914, was 0 - counted 7 - agno = 12 correcting nblocks for inode 205774557, was 0 - counted 22 - agno = 13 - agno = 14 correcting nblocks for inode 241413320, was 0 - counted 9 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 data fork in regular inode 44179985 claims used block 3013232 correcting nblocks for inode 44179985, was 8 - counted 0 data fork in regular inode 44180026 claims used block 6158960 correcting nblocks for inode 44180026, was 8 - counted 0 - agno = 3 data fork in regular inode 55046098 claims used block 4061808 correcting nblocks for inode 55046098, was 2 - counted 0 - agno = 4 data fork in regular inode 72672635 claims used block 5110384 correcting nblocks for inode 72672635, was 8 - counted 0 - agno = 5 - agno = 6 - agno = 7 - agno = 8 data fork in regular inode 138982095 claims used block 9304688 correcting nblocks for inode 138982095, was 10 - counted 0 data fork in regular inode 138982136 claims used block 10353264 correcting nblocks for inode 138982136, was 8 - counted 0 - agno = 9 - agno = 10 - agno = 11 data fork in regular inode 193438914 claims used block 12450416 correcting nblocks for inode 193438914, was 7 - counted 0 - agno = 12 data fork in regular inode 205774557 claims used block 13498992 correcting nblocks for inode 205774557, was 22 - counted 0 - agno = 13 - agno = 14 data fork in regular inode 241413320 claims used block 15596144 correcting nblocks for inode 241413320, was 9 - counted 0 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... corrupt dinode 44179985, extent total = 1, nblocks = 0. Unmount and run xfs_repair. fatal error -- couldn't map inode 44179985, err = 990 > how big is this filesystem, btw, and what does xfs_info output > look like. rei:/# df | grep archive2 /dev/hdb1 58600560 44969692 13630868 77% /archive2 rei:/# xfs_info /archive2 meta-data=/archive2 isize=256 agcount=16, agsize=916081 blks = sectsz=512 data = bsize=4096 blocks=14657296, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=7156, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 That's a whole lot of copy'n'pasting ;) .. Any ideas on how to sort this from the information above? The filesystem is still accessible as I'm burning the stuff on it off now, but I'd rather not keep using it if there's something wrong yet I don't really want to start it from scratch :( Cheers, Daniel Palmer From owner-linux-xfs@oss.sgi.com Mon Jan 5 16:36:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 16:36: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 i060a3Ta001283 for ; Mon, 5 Jan 2004 16:36:06 -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 i061sepx017661 for ; Mon, 5 Jan 2004 19:54:40 -0600 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id 4D93689E374; Mon, 5 Jan 2004 18:35:36 -0600 (CST) Subject: PARTIAL TAKE 904566 - Merge last set of differences Message-Id: <20040106003536.4D93689E374@naboo.americas.sgi.com> Date: Mon, 5 Jan 2004 18:35:36 -0600 (CST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1616 X-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: 501 Lines: 19 Date: Mon Jan 5 16:34:59 PST 2004 Workarea: naboo.americas.sgi.com:/go/space/XFS/2.4.x-xfs+kdb The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:164202a include/linux/posix_acl_xattr.h - 1.1 include/linux/posix_cap_xattr.h - 1.1 Documentation/Configure.help - 1.3 Documentation/filesystems/xfs.txt - 1.2 drivers/md/raid5.c - 1.2 fs/Config.in - 1.2 fs/namei.c - 1.2 include/linux/fs.h - 1.2 include/linux/mm.h - 1.2 mm/mprotect.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jan 5 17:27:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 17:27: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 i061RQTa002858 for ; Mon, 5 Jan 2004 17:27:26 -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 i062k2px003393 for ; Mon, 5 Jan 2004 20:46:04 -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 i061REqH2595816; Tue, 6 Jan 2004 12:27:15 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i061RCsD2610195; Tue, 6 Jan 2004 12:27:12 +1100 (EST) Date: Tue, 6 Jan 2004 12:27:12 +1100 (EST) From: Nathan Scott Message-Id: <200401060127.i061RCsD2610195@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: agruen@suse.de Subject: TAKE - attr/acl fix X-archive-position: 1617 X-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: 578 Lines: 21 Merge acl/attr nftw dir-walk permissions bug fix from Andreas. Date: Mon Jan 5 17:25:47 PST 2004 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:164207a cmd/acl/VERSION - 1.62 cmd/acl/doc/CHANGES - 1.69 cmd/acl/debian/changelog - 1.55 cmd/attr/VERSION - 1.43 cmd/attr/doc/CHANGES - 1.51 cmd/attr/debian/changelog - 1.44 cmd/attr/getfattr/getfattr.c - 1.23 cmd/acl/setfacl/setfacl.c - 1.12 cmd/acl/getfacl/getfacl.c - 1.14 From owner-linux-xfs@oss.sgi.com Mon Jan 5 20:45:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 20:46:20 -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 i064juTa012064 for ; Mon, 5 Jan 2004 20:45:57 -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 i0664Zpx024193 for ; Tue, 6 Jan 2004 00:04:35 -0600 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id 8129189E379; Mon, 5 Jan 2004 22:45:25 -0600 (CST) Subject: TAKE - Upgrade to 2.4.24-pre3... sorta Message-Id: <20040106044525.8129189E379@naboo.americas.sgi.com> Date: Mon, 5 Jan 2004 22:45:25 -0600 (CST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1618 X-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: 3924 Lines: 122 Date: Mon Jan 5 20:41:57 PST 2004 Workarea: naboo.americas.sgi.com:/go/space/XFS/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:164210a Documentation/Configure.help - 1.4 Documentation/SubmittingDrivers - 1.2 Documentation/i2c/summary - 1.2 MAINTAINERS - 1.2 Makefile - 1.3 arch/ppc/boot/Makefile - 1.2 arch/ppc/boot/chrp/Makefile - 1.2 arch/ppc/boot/common/misc-simple.c - 1.2 arch/ppc/boot/pmac/Makefile - 1.2 arch/ppc/boot/simple/Makefile - 1.2 arch/ppc/boot/utils/mkprep.c - 1.2 arch/ppc/config.in - 1.2 arch/ppc/configs/IVMS8_defconfig - 1.2 arch/ppc/configs/SM850_defconfig - 1.2 arch/ppc/configs/SPD823TS_defconfig - 1.2 arch/ppc/configs/TQM823L_defconfig - 1.2 arch/ppc/configs/TQM850L_defconfig - 1.2 arch/ppc/configs/TQM860L_defconfig - 1.2 arch/ppc/configs/apus_defconfig - 1.2 arch/ppc/configs/briq_defconfig - 1.2 arch/ppc/configs/bseip_defconfig - 1.2 arch/ppc/configs/common_defconfig - 1.2 arch/ppc/configs/ebony_defconfig - 1.2 arch/ppc/configs/est8260_defconfig - 1.2 arch/ppc/configs/gemini_defconfig - 1.2 arch/ppc/configs/ibmchrp_defconfig - 1.2 arch/ppc/configs/mbx_defconfig - 1.2 arch/ppc/configs/oak_defconfig - 1.2 arch/ppc/configs/ocotea_defconfig - 1.2 arch/ppc/configs/pal4_defconfig - 1.2 arch/ppc/configs/pmac_defconfig - 1.2 arch/ppc/configs/power3_defconfig - 1.2 arch/ppc/configs/pplus_defconfig - 1.2 arch/ppc/configs/rpxcllf_defconfig - 1.2 arch/ppc/configs/rpxlite_defconfig - 1.2 arch/ppc/configs/spruce_defconfig - 1.2 arch/ppc/configs/walnut_defconfig - 1.2 arch/ppc/defconfig - 1.2 arch/ppc/kernel/Makefile - 1.2 arch/ppc/kernel/m8xx_setup.c - 1.2 arch/ppc/kernel/open_pic.c - 1.2 arch/ppc/kernel/ppc_ksyms.c - 1.2 arch/ppc/kernel/setup.c - 1.2 arch/ppc/platforms/Makefile - 1.2 arch/ppc/platforms/ebony.c - 1.2 arch/ppc/platforms/ebony.h - 1.2 arch/ppc/platforms/gemini_serial.h - 1.2 arch/ppc/platforms/ibm405gp.h - 1.2 arch/ppc/platforms/lopec_serial.h - 1.2 arch/ppc/platforms/lopec_setup.c - 1.2 arch/ppc/platforms/ocotea.c - 1.2 arch/ppc/platforms/ocotea.h - 1.2 arch/ppc/platforms/pal4_serial.h - 1.2 arch/ppc/platforms/spruce.h - 1.2 arch/ppc/platforms/spruce_setup.c - 1.2 arch/sparc64/defconfig - 1.2 arch/sparc64/kernel/pci_sabre.c - 1.2 drivers/block/cciss.c - 1.2 drivers/block/genhd.c - 1.2 drivers/char/Config.in - 1.2 drivers/char/Makefile - 1.2 drivers/i2c/Config.in - 1.2 drivers/i2c/i2c-adap-ite.c - 1.2 drivers/i2c/i2c-algo-bit.c - 1.2 drivers/i2c/i2c-algo-ite.c - 1.2 drivers/i2c/i2c-algo-pcf.c - 1.2 drivers/i2c/i2c-core.c - 1.2 drivers/i2c/i2c-dev.c - 1.2 drivers/i2c/i2c-elektor.c - 1.2 drivers/i2c/i2c-elv.c - 1.2 drivers/i2c/i2c-keywest.c - 1.2 drivers/i2c/i2c-philips-par.c - 1.2 drivers/i2c/i2c-proc.c - 1.2 drivers/i2c/i2c-velleman.c - 1.2 drivers/ide/raid/pdcraid.c - 1.2 drivers/md/lvm-snap.c - 1.2 drivers/md/lvm.c - 1.2 drivers/media/video/Makefile - 1.2 drivers/net/tokenring/Config.in - 1.2 drivers/net/wan/Config.in - 1.2 drivers/net/wan/Makefile - 1.2 drivers/net/wan/c101.c - 1.2 drivers/net/wan/hd64572.h - 1.2 drivers/net/wan/hd6457x.c - 1.2 drivers/net/wan/hdlc_cisco.c - 1.2 drivers/net/wan/hdlc_fr.c - 1.2 drivers/net/wan/hdlc_generic.c - 1.2 drivers/net/wan/hdlc_ppp.c - 1.2 drivers/net/wan/hdlc_raw.c - 1.2 drivers/net/wan/hdlc_raw_eth.c - 1.2 drivers/net/wan/hdlc_x25.c - 1.2 drivers/net/wan/n2.c - 1.2 drivers/video/clgenfb.c - 1.2 drivers/video/hgafb.c - 1.2 fs/readdir.c - 1.2 include/asm-ppc/pc_serial.h - 1.2 include/asm-ppc/serial.h - 1.2 include/linux/hdlc.h - 1.2 include/linux/i2c.h - 1.2 include/linux/lvm.h - 1.2 include/net/pkt_cls.h - 1.2 mm/mmap.c - 1.2 net/core/dev.c - 1.2 net/core/neighbour.c - 1.2 net/sched/cls_api.c - 1.2 net/sched/sch_atm.c - 1.2 net/sched/sch_cbq.c - 1.2 net/sched/sch_csz.c - 1.2 net/sched/sch_dsmark.c - 1.2 net/sched/sch_htb.c - 1.2 net/sched/sch_ingress.c - 1.2 net/sched/sch_prio.c - 1.2 net/sched/sch_tbf.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jan 5 21:36:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Jan 2004 21:37:11 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i065anTa013471 for ; Mon, 5 Jan 2004 21:36:49 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i065aiJt019732 for ; Mon, 5 Jan 2004 21:36:44 -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 i065aidd27648795 for ; Mon, 5 Jan 2004 23:36:44 -0600 (CST) Received: (from overby@localhost) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) id i065ahX43080272; Mon, 5 Jan 2004 23:36:43 -0600 (CST) Date: Mon, 5 Jan 2004 23:36:43 -0600 (CST) Message-Id: <200401060536.i065ahX43080272@daisy-e236.americas.sgi.com> From: Glen Overby To: linux-xfs@oss.sgi.com Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem Reply-To: linux-xfs@oss.sgi.com In-Reply-To: message from Eric Sandeen sent 5 January 2004 References: <200401050850.03928.krienke@uni-koblenz.de> X-archive-position: 1619 X-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: 1404 Lines: 36 On January 5, Eric Sandeen wrote: > On Mon, 5 Jan 2004, Rainer Krienke wrote: > > For one filesystem (~150GB) this worked. xfs_repair reported some errors in > > the filesystem but finished its work. Next I tired to mount this filesystem > > but mount complained that it could not find a valid superblock. So I ran > > xfs_repair once again. It still found some errors (but less than before). > > Next I rebootet the machine and the filesystem was mounted. > > Unable to find a superblock immediately after repair? I have never > seen this before, sounds very odd. BTW running repair twice in If this still happens, It might be useful to see how much was overwritten, and if you recognise the data. You can use xfs_db to read and print the superblock. xfs_db -r /dev/diskxyz sb 0 print - a formatted superblock. type data print - a hex dump of the superblock > > - Is it a known issue that xfs_repair seg faults sometimes or is it perhaps a > > problem of my version (see below) ? > > I wonder if maybe it's failing a memory allocation for the large > filesystem; I thought i remembered a (fixed) problem like this > but I don't see it in the changelogs. A little gdb debugging > would be a big help. xfs_repair can "panic" in which case it calls abort() so you get a coredump to look at. It's a bit unfriendly in that it doesn't exactly say it's going to do that . . . Glen Overby From owner-linux-xfs@oss.sgi.com Tue Jan 6 00:05:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 00:06:25 -0800 (PST) Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0685mTa017327 for ; Tue, 6 Jan 2004 00:05:49 -0800 Received: from bliss.uni-koblenz.de (bliss.uni-koblenz.de [141.26.64.65]) by mailhost.uni-koblenz.de (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i0685jjR031710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jan 2004 09:05:45 +0100 Received: from localhost (localhost [127.0.0.1]) by bliss.uni-koblenz.de (8.12.10/8.12.3) with ESMTP id i0685iXV029037; Tue, 6 Jan 2004 09:05:44 +0100 From: Rainer Krienke Organization: Uni Koblenz To: linux-xfs@oss.sgi.com Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem Date: Tue, 6 Jan 2004 09:05:41 +0100 User-Agent: KMail/1.5.4 Cc: Eric Sandeen References: In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_Xxm+/5LZ67LU3L0" Message-Id: <200401060905.44078.krienke@uni-koblenz.de> X-Virus-Scanned: by amavisd-new X-archive-position: 1620 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krienke@uni-koblenz.de Precedence: bulk X-list: linux-xfs Content-Length: 8017 Lines: 185 --Boundary-00=_Xxm+/5LZ67LU3L0 Content-Type: multipart/signed; charset="iso-8859-1"; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Yxm+/T8zqR91yoR"; name=" " Content-Transfer-Encoding: 7bit --Boundary-02=_Yxm+/T8zqR91yoR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Montag, 5. Januar 2004 16:13, Eric Sandeen wrote: > On Mon, 5 Jan 2004, Rainer Krienke wrote: > > Hello, > > > > a happy new year to everyone on this list ... > > > > well for some of my xfs filesystems the year had a bad start. Due to a > > powerfail on some systems that possibly rebootet and later again crashed > > due to another powerfail some xfs filesystem were damaged. I could not > > mount theses filesystems and so ran xfs_repair -L. > > What was the failure when you first tried to mount? I think originally after I had started the machines (from power off) the=20 filesystem on server1 (that later on could be repaired) was mounted but not= =20 accessible. If I tried to list the directory and ls reported an I/O error. = So=20 I unexported it, unmounted it and the tried to run xfs_repair which reporte= d=20 that there was still a log on the filesystem that should be replayed by=20 mounting the filesystem again or using xfs_restore -L. So I tried to mount = it=20 again and now mount said, that either there are too many mounts, wrong=20 filesystem type or invalid superblock. I tried another mount point and said= =20 that this is a xfs filesystem (-t xfs) but this did not make any difference= .=20 The error message was the same message as for the other (smaller) corrupted= =20 filesystem on server2 which could not be repaired.=20 ... > > Unable to find a superblock immediately after repair? I have never > seen this before, sounds very odd. BTW running repair twice in > sucession will keep finding "errors" because the first run > creates /lost+found, and the second run unlinks /lost+found then > rediscovers everything that was in it as disconnected. This > is a "feature" that I'd like to change some day. Moving /lost+found > after the first run should make repair run cleanly the next time, > unless something is really still wrong with the filesystem. > > In any case a successful xfs_repair run followed by a bad superblock > is a big red flag indicating... something. :) > > > Another filesystem on a second machien (~40GB) that strange enough had > > been mounted on reboot but was not accessible (ls /filesystem: input > > output error) could not be repaired by xfs_repair: > > Sounds like the filesystem shut down due to some error, can you check > your logs? In fact checking your logs in general might be useful > here, I wonder if there is anything else going on. One the first machine (server1) I found a sequence of messages like the log= =20 attached to this mail. But this message was generated upon startup after=20 powerfail not before. Before the power failure there is nothing xfs related= =20 in the logs. > > > again I had to use -L since after unmounting I was no longer able to > > mount it. xfs_repair reported a lot more errors compared to the first > > filesystem from above and then in pass 4 I think when traversing the > > directory hierarchy from / it segfaultet. A second and third run of > > xfs_repair produced each time more errors but always ended in a segfaul= t. > > In between I recovered the data from tape, but I still have the old > > broken filesystem for further investigation if needed. > > Can you convince it to dump a corefile? We could then have a better > idea of what's going wrong. Yes I ran xfs_repair once again (perhaps the 5th time) on the corrupted=20 filesystem on server2 and lifted the ulimit for core dumps. It produced one= .=20 You can download it under http://www.uni-koblenz.de/~krienke/core-xfs_repair.gz It happens during phase 6. Part of the xfs_repair output of this run is (= the=20 complete log is available unter http://www.uni-koblenz.de/~krienke/ xfs_repair.log): --------------------------------------------- ... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 empty data block 7 in directory inode 85967685: junking block free block 16777216 entry 7 for directory ino 85967685 bad rebuilding directory inode 85967685 rebuilding directory inode 132008213 ... rebuilding directory inode 158259325 - traversal finished ... - traversing all unattached subtrees ... segmentation fault ------------------------------------------- > > Now I would like to know if this behaviour is "normal": > > > > - Can a filesystem with tansaction logging like xfs become inconsitant > > because of a power fail? There is no disk failure! > > It should not be inconsistent (disk+log should always be consistent). > You may have data loss though due to cached data which never makes it > to disk. Thanks for these explanations. Perhaps the buffer in the hardware raids tha= t=20 are used as basis for data storage are to blame (IFT 7250 Raid (Level 5),= =20 with 12 160GB IDE disks inside). I'll try to find out if this cache is read= =20 only or read/write. Thanks Rainer --=20 --------------------------------------------------------------------------- Rainer Krienke, Universitaet Koblenz, Rechenzentrum, Raum A022 Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html --------------------------------------------------------------------------- --Boundary-02=_Yxm+/T8zqR91yoR Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/+mxXaldtjc/KDEoRApkiAKCoLgu5cvurLPvg+cdXz6H3dzrEaACfWVgK 3QFs+U7VVwKEeYI4KIT1g3U= =y13X -----END PGP SIGNATURE----- --Boundary-02=_Yxm+/T8zqR91yoR-- --Boundary-00=_Xxm+/5LZ67LU3L0 Content-Type: text/plain; charset="iso-8859-1"; name="syslog.xfserror" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="syslog.xfserror" Jan 1 13:05:35 server1 kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 302 of file xfs_alloc.c. Caller 0xc4f027d0 Jan 1 13:05:35 server1 kernel: c63bf820 c4f01c33 c4f88c75 00000001 00000000 c4f88c69 0000012e c4f027d0 Jan 1 13:05:35 server1 kernel: 00000000 00000000 00000000 00000000 00000010 c63bf9dc c4e77e8c c63bf8cc Jan 1 13:05:35 server1 kernel: c4f027d0 c4e77e8c c4e77d84 0000b36b 00000169 0000b4c4 00000010 00000001 Jan 1 13:05:35 server1 kernel: Call Trace: [mousedev:__insmod_mousedev_O/lib/modules/2.4.21-144-smp4G/kernel/dri+-8913869/96] (04 Jan 1 13:05:35 server1 kernel: Call Trace: [] (04) [] (12) [] (08) Jan 1 13:05:35 server1 kernel: [mousedev:__insmod_mousedev_O/lib/modules/2.4.21-144-smp4G/kernel/dri+-8910896/96] (36) [mousedev:__insm Jan 1 13:05:35 server1 kernel: (128) [] (08) [] (20) Jan 1 13:05:35 server1 kernel: [mousedev:__insmod_mousedev_O/lib/modules/2.4.21-144-smp4G/kernel/dri+-8902169/96] (64) [mousedev:__insm Jan 1 13:05:35 server1 kernel: [] (64) [] (60) [] (48) [] (148) Jan 1 13:05:35 server1 kernel: [mousedev:__insmod_mousedev_O/lib/modules/2.4.21-144-smp4G/kernel/dri+-8823849/96] (48) [mousedev:__insm Jan 1 13:05:35 server1 kernel: [generic_make_request+242/352] (40) [mousedev:__insmod_mousedev_O/lib/modules/2.4.21-144-smp4G/kernel/dr Jan 1 13:05:35 server1 kernel: [] (40) [] (84) [] (52) [] (100) --Boundary-00=_Xxm+/5LZ67LU3L0-- From owner-linux-xfs@oss.sgi.com Tue Jan 6 04:21:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 04:22:16 -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 i06CLrTa000714 for ; Tue, 6 Jan 2004 04:21:54 -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 DDBC532D06; Tue, 6 Jan 2004 13:21:51 +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 3C1A132CB5; Tue, 6 Jan 2004 13:21:51 +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 M2004010613215020727 ; Tue, 06 Jan 2004 13:21: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 2D3124E20C; Tue, 6 Jan 2004 13:21:51 +0100 (CET) Received: from 10.1.200.117 (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Tue, 6 Jan 2004 13:21:51 +0100 (CET) Message-ID: <3487.10.1.200.117.1073391711.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <20040105224425.GA19311@ii.uib.no> References: <20040105224425.GA19311@ii.uib.no> Date: Tue, 6 Jan 2004 13:21:51 +0100 (CET) Subject: Re: mremap fix / kernel-2.4.20-28.9.XFS1.3.1 From: "Simon Matter" To: "Jan-Frode Myklebust" 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 i06CLsTa000715 X-archive-position: 1621 X-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: 615 Lines: 28 Thank you very much! Simon > I've merged the RedHat-9 kernel-2.4.20-28.9 and the SGI > kernel-2.4.20-20.9.XFS1.3.1 and am in the process of rebuilding this > for i386, i586, i686 and athlon. > > If anybody want the SRPM it's available at: > > ftp://ftp.ii.uib.no/pub/janfrode/XFS/rh9/SRPMS/kernel-2.4.20-28.9.XFS1.3.1.src.rpm > > the binaries should appear soon under: > > ftp://ftp.ii.uib.no/pub/janfrode/XFS/rh9/ > > I will build the RedHat-8 kernels tomorrow. > > Unfortunately I haven't had time to do any testing on these yet, but > expect them to be OK. Feedback will be appreciated. > > > -jf > > > From owner-linux-xfs@oss.sgi.com Tue Jan 6 06:41:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 06:41: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 i06Ef7Ta004738 for ; Tue, 6 Jan 2004 06:41: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 i06Fxjpx004675 for ; Tue, 6 Jan 2004 09:59: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 i06Eevbj27509928; Tue, 6 Jan 2004 08:40: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 i06EeuK213020371; Tue, 6 Jan 2004 08:40:57 -0600 (CST) Date: Tue, 6 Jan 2004 08:40:56 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Rainer Krienke cc: linux-xfs@oss.sgi.com Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem In-Reply-To: <200401060905.44078.krienke@uni-koblenz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1622 X-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: 2317 Lines: 55 On Tue, 6 Jan 2004, Rainer Krienke wrote: > I think originally after I had started the machines (from power off) the > filesystem on server1 (that later on could be repaired) was mounted but not > accessible. If I tried to list the directory and ls reported an I/O error. Maybe the filesystem had encountered an error and shut down at this point. Anything in the logs? > So > I unexported it, unmounted it and the tried to run xfs_repair which reported > that there was still a log on the filesystem that should be replayed by > mounting the filesystem again or using xfs_restore -L. So I tried to mount it > again and now mount said, that either there are too many mounts, wrong > filesystem type or invalid superblock. At that point you need to look for the specific failure message from the kernel, either dmesg or /var/log/messages, to know what really happened. > > Sounds like the filesystem shut down due to some error, can you check > > your logs? In fact checking your logs in general might be useful > > here, I wonder if there is anything else going on. > > One the first machine (server1) I found a sequence of messages like the log > attached to this mail. But this message was generated upon startup after > powerfail not before. Before the power failure there is nothing xfs related > in the logs. Ok, I'll take a look... > > Can you convince it to dump a corefile? We could then have a better > > idea of what's going wrong. > > Yes I ran xfs_repair once again (perhaps the 5th time) on the corrupted > filesystem on server2 and lifted the ulimit for core dumps. It produced one. > You can download it under > > http://www.uni-koblenz.de/~krienke/core-xfs_repair.gz Can you put your xfs_repair binary there as well? > Thanks for these explanations. Perhaps the buffer in the hardware raids that > are used as basis for data storage are to blame (IFT 7250 Raid (Level 5), > with 12 160GB IDE disks inside). I'll try to find out if this cache is read > only or read/write. Ah, and if the hardware raid does write caching, and it's not battery backed, then you -could- have inconsistency problems. if the raid claims that something is written when in fact it is only cached, then there is a chance that the fs+log is inconsistent in the case of a power failure. -Eric From owner-linux-xfs@oss.sgi.com Tue Jan 6 06:46:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 06:46: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 i06EkKTa005259 for ; Tue, 6 Jan 2004 06:46:20 -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 i06CtBOO022942 for ; Tue, 6 Jan 2004 04:55:11 -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 i06EkDbj27899842; Tue, 6 Jan 2004 08:46:13 -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 i06EkCK213053635; Tue, 6 Jan 2004 08:46:13 -0600 (CST) Date: Tue, 6 Jan 2004 08:46:12 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Rainer Krienke cc: linux-xfs@oss.sgi.com Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem In-Reply-To: <200401060905.44078.krienke@uni-koblenz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1623 X-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: 700 Lines: 22 On Tue, 6 Jan 2004, Rainer Krienke wrote: > One the first machine (server1) I found a sequence of messages like the log > attached to this mail. But this message was generated upon startup after > powerfail not before. Before the power failure there is nothing xfs related > in the logs. Jan 1 13:05:35 server1 kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 302 of file xfs_alloc.c. Caller 0xc4f027d0 (followed by an indecipherable call trace) I'm guessing that there was a filesystem shutdown after this. If you have the kernel-source tree for your running kernel (2.4.21-144) could you send me a the lines surrounding xfs_alloc.c:302, for a little context? Thanks, -Eric From owner-linux-xfs@oss.sgi.com Tue Jan 6 07:24:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 07:25:03 -0800 (PST) Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06FOcTa007878 for ; Tue, 6 Jan 2004 07:24:38 -0800 Received: from bliss.uni-koblenz.de (bliss.uni-koblenz.de [141.26.64.65]) by mailhost.uni-koblenz.de (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i06FOajR003596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jan 2004 16:24:37 +0100 Received: from localhost (localhost [127.0.0.1]) by bliss.uni-koblenz.de (8.12.10/8.12.3) with ESMTP id i06FOaRK005176; Tue, 6 Jan 2004 16:24:36 +0100 From: Rainer Krienke Organization: Uni Koblenz To: Eric Sandeen Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem Date: Tue, 6 Jan 2004 16:24:31 +0100 User-Agent: KMail/1.5.4 References: In-Reply-To: Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_zMt+/IYBsJzolnW"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401061624.35790.krienke@uni-koblenz.de> X-Virus-Scanned: by amavisd-new X-archive-position: 1624 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krienke@uni-koblenz.de Precedence: bulk X-list: linux-xfs Content-Length: 3633 Lines: 107 --Boundary-02=_zMt+/IYBsJzolnW Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Dienstag, 6. Januar 2004 15:40, you wrote: > > > Sounds like the filesystem shut down due to some error, can you check > > > your logs? In fact checking your logs in general might be useful > > > here, I wonder if there is anything else going on. > > > > One the first machine (server1) I found a sequence of messages like the > > log attached to this mail. But this message was generated upon startup > > after powerfail not before. Before the power failure there is nothing x= fs > > related in the logs. I searched the logs a little deeper. What I overlooked up to now is that cl= ose=20 to the=20 "XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1596 of file xfs_alloc.= c" line. There are on both servers force shutdown messages. On server1: Jan 1 12:55:36 server1 kernel: xfs_force_shutdown(device-mapper(254,0),0x8= )=20 called from line 4051 of file xfs_bmap.c. Return address =3D Jan 1 12:55:36 server1 kernel: Filesystem "device-mapper(254,0)": Corrupti= on=20 of in-memory data detected. Shutting down filesystem: device-mapper(254,0) Jan 1 12:55:36 server1 kernel: Please umount the filesystem, and rectify t= he=20 problem(s) On server2: xfs_force_shutdown(device-mapper(254,3),0x8) called from line 4051 of file= =20 xfs_bmap.c. Return address =3D0xc4f6ff8b Jan 2 00:41:43 server2 kernel: Filesystem "device-mapper(254,3)": Corrupti= on=20 of in-memory data detected. Shutting down filesystem: device-mapper(254,3) Jan 2 00:41:43 server2 kernel: Please umount the filesystem, and rectify t= he=20 problem(s) This was past midnight, so I guess energy went away and then came back agai= n=20 and went away once again. My reboot was on the same day at about 1:00 Uhr p= m. Perhaps many errors I see in the syslog like: Jan 1 13:05:35 server1 kernel: XFS internal error XFS_WANT_CORRUPTED_RETUR= N=20 at line 302 of file xfs_alloc.c. Caller 0xc4f027d0 Jan 1 13:05:35 server1 kernel: c63bf820 c4f01c33 c4f88c75 00000001 0000000= 0=20 c4f88c69 0000012e c4f027d0 Jan 1 13:05:35 server1 kernel: 00000000 00000000 00000000 00000000= =20 00000010 c63bf9dc c4e77e8c c63bf8cc were caused by my attempts to mount the "forced down" filesystem which fail= ed.=20 The time could be right but I cannot remember exactly when I tried to mount= =20 the failed devices before I started xfs_repair. So I am not sure about this. > Can you put your xfs_repair binary there as well? Its there: http://www.uni-koblenz.de/~krienke/xfs/xfs_repair.gz I also put xfs_alloc.c and xfs_bmap.c from "my" kernel-source there: http://www.uni-koblenz.de/~krienke/xfs/xfs_alloc.c.gz http://www.uni-koblenz.de/~krienke/xfs/xfs_bmap.c.gz Thanks a lot=20 Rainer --=20 --------------------------------------------------------------------------- Rainer Krienke, Universitaet Koblenz, Rechenzentrum, Raum A022 Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html --------------------------------------------------------------------------- --Boundary-02=_zMt+/IYBsJzolnW Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/+tMzaldtjc/KDEoRAvoQAKDWWpclrfyg9VipUVbJkBRkxfXnEACfX7v/ JuZXd6a0uWtupXHb9/xVqzg= =P2MI -----END PGP SIGNATURE----- --Boundary-02=_zMt+/IYBsJzolnW-- From owner-linux-xfs@oss.sgi.com Tue Jan 6 09:06:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 09:07:07 -0800 (PST) Received: from ms-smtp-02-eri0.texas.rr.com (ms-smtp-02.texas.rr.com [24.93.47.41]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06H6dTa014615 for ; Tue, 6 Jan 2004 09:06:41 -0800 Received: from chillbear (cs68201181-91.austin.rr.com [68.201.181.91]) by ms-smtp-02-eri0.texas.rr.com (8.12.10/8.12.7) with SMTP id i06H6VvV014276; Tue, 6 Jan 2004 11:06:34 -0600 (CST) Message-ID: <000801c3d477$d7302800$6801a8c0@chillbear> From: "John Groves" To: Cc: Subject: Writing a DMAPI handler Date: Tue, 6 Jan 2004 11:09:23 -0600 MIME-Version: 1.0 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-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1625 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: John@Groves.net Precedence: bulk X-list: linux-xfs Content-Length: 310 Lines: 8 Are there any resources available, such as example code, for people interested in writing a dmapi handler? Are there any resources I should refer to for info as to the completeness or known problems in the dmapi interface for XFS? Thanks, John Groves John@GrovesTech.com [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Jan 6 09:35:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 09:35: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 i06HZGTa015660 for ; Tue, 6 Jan 2004 09:35: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 i06Irspx007845 for ; Tue, 6 Jan 2004 12:53:54 -0600 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id i06HZ77427921895 for ; Tue, 6 Jan 2004 11:35:07 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i06HZ70L27192629 for ; Tue, 6 Jan 2004 11:35:07 -0600 (CST) Received: from clink (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i06HZ6bs6863844 for ; Tue, 6 Jan 2004 11:35:06 -0600 (CST) Message-Id: <200401061735.i06HZ6bs6863844@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: Re: Writing a DMAPI handler Date: Tue, 06 Jan 2004 11:35:06 -0600 From: Dean Roehrich X-archive-position: 1626 X-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@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 544 Lines: 18 >From: "John Groves" >Are there any resources available, such as example code, for people interested > in writing a dmapi handler? Are there any resources I should refer to for in >fo as to the completeness or known problems in the dmapi interface for XFS? > >Thanks, >John Groves >John@GrovesTech.com Grab the xfstests directory from the CVS tree and look through the DMAPI tests. There are a few simple-minded sample HSM tools. The DMAPI spec can be found at http://www.opengroup.org/onlinepubs/9657099/toc.htm Dean From owner-linux-xfs@oss.sgi.com Tue Jan 6 12:43:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 12:43:52 -0800 (PST) Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06KhdTa025436 for ; Tue, 6 Jan 2004 12:43:40 -0800 Received: from bliss.uni-koblenz.de (bliss.uni-koblenz.de [141.26.64.65]) by mailhost.uni-koblenz.de (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i068nrjR018487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jan 2004 09:49:53 +0100 Received: from localhost (localhost [127.0.0.1]) by bliss.uni-koblenz.de (8.12.10/8.12.3) with ESMTP id i068nqXV029547; Tue, 6 Jan 2004 09:49:52 +0100 From: Rainer Krienke Organization: Uni Koblenz To: linux-xfs@oss.sgi.com Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem Date: Tue, 6 Jan 2004 09:49:48 +0100 User-Agent: KMail/1.5.4 References: <200401050850.03928.krienke@uni-koblenz.de> <200401060536.i065ahX43080272@daisy-e236.americas.sgi.com> In-Reply-To: <200401060536.i065ahX43080272@daisy-e236.americas.sgi.com> Cc: Glen Overby MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_wan+/60RmwIroRc"; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200401060949.52412.krienke@uni-koblenz.de> X-Virus-Scanned: by amavisd-new X-archive-position: 1627 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krienke@uni-koblenz.de Precedence: bulk X-list: linux-xfs Content-Length: 4268 Lines: 130 --Boundary-02=_wan+/60RmwIroRc Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Dienstag, 6. Januar 2004 06:36, Glen Overby wrote: > On January 5, Eric Sandeen wrote: > > On Mon, 5 Jan 2004, Rainer Krienke wrote: > > > For one filesystem (~150GB) this worked. xfs_repair reported some > > > errors in the filesystem but finished its work. Next I tired to mount > > > this filesystem but mount complained that it could not find a valid > > > superblock. So I ran xfs_repair once again. It still found some errors > > > (but less than before). Next I rebootet the machine and the filesystem > > > was mounted. > > > > Unable to find a superblock immediately after repair? I have never > > seen this before, sounds very odd. BTW running repair twice in > > If this still happens, It might be useful to see how much was > overwritten, and if you recognise the data. You can use xfs_db to > read and print the superblock. > > xfs_db -r /dev/diskxyz > > sb 0 > print - a formatted superblock. > type data > print - a hex dump of the superblock > Here is the output of the commands you gave me above for the the corrupted= =20 filesystem that causes xfs_repair to segfault. The core dump of xfs_repair = is=20 available by http here:=20 http://www.uni-koblenz.de/~krienke/core-xfs_repair.gz xfs_db> print magicnum =3D 0x58465342 blocksize =3D 4096 dblocks =3D 10485760 rblocks =3D 0 rextents =3D 0 uuid =3D aa892a25-142d-4d69-85a8-64a693561479 logstart =3D 5242884 rootino =3D 128 rbmino =3D 129 rsumino =3D 130 rextsize =3D 16 agblocks =3D 262144 agcount =3D 40 rbmblocks =3D 0 logblocks =3D 1280 versionnum =3D 0x20d4 sectsize =3D 512 inodesize =3D 256 inopblock =3D 16 fname =3D "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog =3D 12 sectlog =3D 9 inodelog =3D 8 inopblog =3D 4 agblklog =3D 18 rextslog =3D 0 inprogress =3D 0 imax_pct =3D 25 icount =3D 1378304 ifree =3D 24887 fdblocks =3D 536064 frextents =3D 0 uquotino =3D 131 gquotino =3D 132 qflags =3D 0x77 flags =3D 0 shared_vn =3D 0 inoalignmt =3D 2 unit =3D 0 width =3D 0 dirblklog =3D 0 logsectlog =3D 0 logsectsize =3D 0 logsunit =3D 0 xfs_db> type data xfs_db> print 000: 58465342 00001000 00000000 00a00000 00000000 00000000 00000000 00000000 020: aa892a25 142d4d69 85a864a6 93561479 00000000 00500004 00000000 00000080 040: 00000000 00000081 00000000 00000082 00000010 00040000 00000028 00000000 060: 00000500 20d40200 01000010 00000000 00000000 00000000 0c090804 12000019 080: 00000000 00150800 00000000 00006137 00000000 00082e00 00000000 00000000 0a0: 00000000 00000083 00000000 00000084 00770000 00000002 00000000 00000000 0c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 100: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 120: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 140: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 160: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 180: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 1a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 1c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 1e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Thanks Rainer --=20 --------------------------------------------------------------------------- Rainer Krienke, Universitaet Koblenz, Rechenzentrum, Raum A022 Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html --------------------------------------------------------------------------- --Boundary-02=_wan+/60RmwIroRc Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/+nawaldtjc/KDEoRAu4tAKCCtZHYoHnTbNkR5qz1YWn2h0lydACfUTsi RIbcXoVYxUrXTyuTgdAXFog= =wgu/ -----END PGP SIGNATURE----- --Boundary-02=_wan+/60RmwIroRc-- From owner-linux-xfs@oss.sgi.com Tue Jan 6 15:14:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 15:15: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 i06NEkTa030582 for ; Tue, 6 Jan 2004 15:14:46 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i06NEkiV030581 for linux-xfs@oss.sgi.com; Tue, 6 Jan 2004 15:14:46 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i06NEiTc030567 for ; Tue, 6 Jan 2004 15:14:44 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i06NDPoO030531; Tue, 6 Jan 2004 15:13:25 -0800 Date: Tue, 6 Jan 2004 15:13:25 -0800 Message-Id: <200401062313.i06NDPoO030531@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 262] cvsup instructions on oss.sgi.com do not get the fs/xfs tree X-Bugzilla-Reason: AssignedTo X-archive-position: 1628 X-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: 604 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=262 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From cattelan@thebarn.com 2004-06-01 15:13 PDT ------- This has been fixed for quite some time. Error in the cvsupd config. ------- 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 Jan 6 15:18:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 15:18: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 i06NIiTa031061 for ; Tue, 6 Jan 2004 15:18:45 -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 i070bPpx028673 for ; Tue, 6 Jan 2004 18:37:25 -0600 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id DE2638C870A; Tue, 6 Jan 2004 17:18:17 -0600 (CST) Subject: TAKE - Upgrade to 2.4.25-pre4 Message-Id: <20040106231817.DE2638C870A@naboo.americas.sgi.com> Date: Tue, 6 Jan 2004 17:18:17 -0600 (CST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1629 X-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: 3753 Lines: 124 Date: Tue Jan 6 15:17:36 PST 2004 Workarea: naboo.americas.sgi.com:/go/space/XFS/2.4.x-xfs-pa The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:164398a include/asm-ppc64/iSeries/vio.h - 1.1 include/asm-s390/ioctl32.h - 1.1 include/asm-s390x/ioctl32.h - 1.1 arch/ppc64/kernel/lparcfg.c - 1.1 CREDITS - 1.2 Documentation/Configure.help - 1.5 Documentation/s390/cds.txt - 1.2 MAINTAINERS - 1.3 Makefile - 1.4 arch/ppc/boot/include/mpc10x.h - 1.2 arch/ppc/boot/prep/misc.c - 1.2 arch/ppc/kernel/open_pic.c - 1.3 arch/ppc64/Makefile - 1.2 arch/ppc64/boot/ppc32-types.h - 1.2 arch/ppc64/config.in - 1.2 arch/ppc64/kernel/Makefile - 1.2 arch/ppc64/kernel/chrp_setup.c - 1.2 arch/ppc64/kernel/cputable.c - 1.2 arch/ppc64/kernel/entry.S - 1.2 arch/ppc64/kernel/head.S - 1.2 arch/ppc64/kernel/misc.S - 1.2 arch/ppc64/kernel/mk_defs.c - 1.2 arch/ppc64/kernel/pSeries_lpar.c - 1.2 arch/ppc64/kernel/ppc_asm.h - 1.2 arch/ppc64/kernel/ppc_ksyms.c - 1.2 arch/ppc64/kernel/process.c - 1.2 arch/ppc64/kernel/prom.c - 1.2 arch/ppc64/kernel/ptrace.c - 1.2 arch/ppc64/kernel/ptrace32.c - 1.2 arch/ppc64/kernel/ras.c - 1.2 arch/ppc64/kernel/rtas-proc.c - 1.2 arch/ppc64/kernel/rtas.c - 1.2 arch/ppc64/kernel/rtc.c - 1.2 arch/ppc64/kernel/setup.c - 1.2 arch/ppc64/kernel/smp.c - 1.2 arch/ppc64/kernel/traps.c - 1.2 arch/ppc64/kernel/udbg.c - 1.2 arch/ppc64/mm/init.c - 1.2 arch/s390/defconfig - 1.2 arch/s390/kernel/process.c - 1.2 arch/s390/kernel/s390_ksyms.c - 1.2 arch/s390/mm/init.c - 1.2 arch/s390x/defconfig - 1.2 arch/s390x/kernel/head.S - 1.2 arch/s390x/kernel/linux32.c - 1.2 arch/s390x/kernel/process.c - 1.2 arch/s390x/kernel/s390_ksyms.c - 1.2 arch/s390x/mm/init.c - 1.2 arch/sh/config.in - 1.2 arch/sh/kernel/entry.S - 1.2 arch/sh64/config.in - 1.2 arch/sh64/kernel/Makefile - 1.2 arch/sh64/kernel/time.c - 1.2 drivers/char/random.c - 1.2 drivers/char/shwdt.c - 1.2 drivers/ide/ide-iops.c - 1.2 drivers/net/tg3.c - 1.2 drivers/s390/block/dasd.c - 1.2 drivers/s390/block/dasd_3990_erp.c - 1.2 drivers/s390/block/dasd_diag.c - 1.2 drivers/s390/block/dasd_eckd.c - 1.2 drivers/s390/block/dasd_fba.c - 1.2 drivers/s390/block/dasd_int.h - 1.2 drivers/s390/block/xpram.c - 1.2 drivers/s390/ccwcache.c - 1.2 drivers/s390/net/ctcmain.c - 1.2 drivers/s390/s390io.c - 1.2 drivers/scsi/megaraid.c - 1.2 drivers/scsi/osst.c - 1.2 drivers/scsi/osst.h - 1.2 drivers/scsi/osst_options.h - 1.2 drivers/scsi/st.c - 1.2 fs/ext2/ialloc.c - 1.2 fs/ext2/inode.c - 1.2 fs/ext2/super.c - 1.2 fs/ext3/inode.c - 1.2 fs/ext3/super.c - 1.2 fs/jbd/commit.c - 1.2 fs/jbd/journal.c - 1.2 fs/jbd/transaction.c - 1.2 include/asm-ppc/floppy.h - 1.2 include/asm-ppc/mpc10x.h - 1.2 include/asm-ppc64/cputable.h - 1.2 include/asm-ppc64/elf.h - 1.2 include/asm-ppc64/mmu_context.h - 1.2 include/asm-ppc64/paca.h - 1.2 include/asm-ppc64/page.h - 1.2 include/asm-ppc64/ppcdebug.h - 1.2 include/asm-ppc64/processor.h - 1.2 include/asm-ppc64/prom.h - 1.2 include/asm-ppc64/ptrace.h - 1.2 include/asm-ppc64/rtas.h - 1.2 include/asm-ppc64/smp.h - 1.2 include/asm-ppc64/system.h - 1.2 include/asm-ppc64/systemcfg.h - 1.2 include/asm-ppc64/time.h - 1.2 include/asm-ppc64/user_exports.h - 1.2 include/asm-s390/ccwcache.h - 1.2 include/asm-s390/dasd.h - 1.2 include/asm-s390/irq.h - 1.2 include/asm-s390/pgalloc.h - 1.2 include/asm-s390/s390io.h - 1.2 include/asm-s390/signal.h - 1.2 include/asm-s390x/ccwcache.h - 1.2 include/asm-s390x/dasd.h - 1.2 include/asm-s390x/irq.h - 1.2 include/asm-s390x/pgalloc.h - 1.2 include/asm-s390x/s390io.h - 1.2 include/asm-s390x/signal.h - 1.2 include/asm-sh/ptrace.h - 1.2 include/linux/ext2_fs.h - 1.2 include/linux/ext2_fs_i.h - 1.2 include/linux/ext3_fs.h - 1.2 kernel/signal.c - 1.2 mm/mremap.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jan 6 15:26:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 15:26:36 -0800 (PST) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06NQOTa031634 for ; Tue, 6 Jan 2004 15:26:25 -0800 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.002270AD@mailhub2.arup.com>; Tue, 6 Jan 2004 23:26:18 +0000 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Tue, 06 Jan 2004 23:26:17 -0000 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Wed, 07 Jan 2004 10:24:12 +1100 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Wed, 07 Jan 2004 10:21:06 +1100 From: "Scott Fagg" To: Subject: state of XFS capable linux installers Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i06NQPTa031638 X-archive-position: 1630 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 285 Lines: 13 I have a couple of RH7.3 XFS boxes i'd like to upgrade, most likely to fedora + 2.6.x. What's the state of the xfs-capable installers ? Is there one for fedora yet ? What we be involved in making such a thing ? Scott Fagg Arup Brisbane (07) 3023 6000 From owner-linux-xfs@oss.sgi.com Tue Jan 6 17:06:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 17:06:52 -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 i0716dTa004683 for ; Tue, 6 Jan 2004 17:06:40 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 92CAEEB4A0E for ; Wed, 7 Jan 2004 09:06:32 +0800 (PHT) Received: from lawin.alabang.leathercollection.ph (lawin.alabang.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id DAD5BEB4A0B for ; Wed, 7 Jan 2004 09:06:17 +0800 (PHT) Received: by lawin.alabang.leathercollection.ph (Postfix, from userid 1000) id 1503B1A403A; Wed, 7 Jan 2004 09:06:16 +0800 (PHT) Date: Wed, 7 Jan 2004 09:06:16 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: new 2.4.24 kernel out - w/o XFS Message-ID: <20040107010616.GI22855@leathercollection.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3FF98A81.3060302@mps.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FF98A81.3060302@mps.ohio-state.edu> 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: 1631 X-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: 1135 Lines: 27 On Mon, Jan 05, 2004 at 11:02:09AM -0500, Dirk Hufnagel wrote: > Looks like the 2.4.24-pre kernels have been removed and a new 2.4.24 > kernel has been released, with a *very* short Changelog compared to > 2.4.23. Possibly a reaction to the latest kernel security > vulnerability (updated Redhat kernels are available too). > > It seems we will have to wait for 2.4.25 to get XFS included. The available split patches for 2.4.23 (2003-12-01 00:33 UTC) apply fairly cleanly to the pristine 2.4.24. The only reject is the Makefile EXTRAVERSION change, which is trivial to repair by hand. I have not tested if this works, though. Has anyone done tests with this combination? If it's not too difficult a task, I'm hoping the XFS team can find some time to release split patches for 2.4.24, though, with whatever XFS fixes came in after 2003-12-01 00:33 UTC. Thank you very much in advance. --> Jijo -- 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 Tue Jan 6 23:41:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Jan 2004 23:41:31 -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 i077fITa013983 for ; Tue, 6 Jan 2004 23:41:19 -0800 Received: from erbenson.alaska.net (216-pm32.nwc.alaska.net [209.112.158.216]) by hob.acsalaska.net (8.12.10/8.12.10) with ESMTP id i077fG1n031557 for ; Tue, 6 Jan 2004 22:41: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 BBBE839E7 for ; Tue, 6 Jan 2004 22:41:14 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id ACD1B40FF35; Tue, 6 Jan 2004 22:41:14 -0900 (AKST) Date: Tue, 6 Jan 2004 22:41:14 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: new 2.4.24 kernel out - w/o XFS Message-ID: <20040107074114.GG14918@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3FF98A81.3060302@mps.ohio-state.edu> <20040107010616.GI22855@leathercollection.ph> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1xGqyAVbSpAWs5A" Content-Disposition: inline In-Reply-To: <20040107010616.GI22855@leathercollection.ph> 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.61; spamdefang 1.76 X-archive-position: 1632 X-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: 1915 Lines: 58 --X1xGqyAVbSpAWs5A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 07, 2004 at 09:06:16AM +0800, Federico Sevilla III wrote: > On Mon, Jan 05, 2004 at 11:02:09AM -0500, Dirk Hufnagel wrote: > > Looks like the 2.4.24-pre kernels have been removed and a new 2.4.24 > > kernel has been released, with a *very* short Changelog compared to > > 2.4.23. Possibly a reaction to the latest kernel security > > vulnerability (updated Redhat kernels are available too). > >=20 > > It seems we will have to wait for 2.4.25 to get XFS included. >=20 > The available split patches for 2.4.23 (2003-12-01 00:33 UTC) apply > fairly cleanly to the pristine 2.4.24. The only reject is the Makefile > EXTRAVERSION change, which is trivial to repair by hand. I have not and only if you apply -misc, which is not even required. > tested if this works, though. Has anyone done tests with this > combination? ive read the entire diff of 2.4.23 -> 2.4.24, see for yourself, its VERY trivial stuff, XFS requires no changes. summary: * one line memset() calls sprinkled into all the rtc drivers * two line code, 4 line comment addition to mremap. * one liner fixes to debug printks in the irda driver. thats all. > If it's not too difficult a task, I'm hoping the XFS team can find some > time to release split patches for 2.4.24, though, with whatever XFS > fixes came in after 2003-12-01 00:33 UTC. you can use 2.4.23 patches safely, don't worry. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --X1xGqyAVbSpAWs5A 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/7uBoACgkQJKx7GixEevy7qwCfagdYYW+V5ij3GnrJuSQtaXfN ddUAn2VP/5n0c1Q2Ta7Xwie12znp5uix =Fu56 -----END PGP SIGNATURE----- --X1xGqyAVbSpAWs5A-- From owner-linux-xfs@oss.sgi.com Wed Jan 7 00:33:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 00:33:37 -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 i078XBTa017866 for ; Wed, 7 Jan 2004 00:33:11 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.8) with ESMTP id i078X7Yu028088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Jan 2004 09:33:09 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i078X1lt032504; Wed, 7 Jan 2004 09:33:01 +0100 Date: Wed, 7 Jan 2004 09:33:01 +0100 From: Axel Thimm To: Scott Fagg Cc: linux-xfs@oss.sgi.com Subject: Re: state of XFS capable linux installers Message-ID: <20040107083301.GE30593@neu.nirvana> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DqhR8hV3EnoxUkKN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 1633 X-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: 1486 Lines: 44 --DqhR8hV3EnoxUkKN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 07, 2004 at 10:21:06AM +1100, Scott Fagg wrote: > I have a couple of RH7.3 XFS boxes i'd like to upgrade, most likely > to fedora + 2.6.x. Maybe wait until FC2 (ETA is April, first test ISOs February) which has offical 2.6 support? > What's the state of the xfs-capable installers ? Is there one for > fedora yet ? What we be involved in making such a thing ? I think the best thing you can do is to ask for it at fedora-devel-list@redhat.com or anaconda-devel-list@redhat.com and offer yourself as a tester. There have been various discussions on enabling XFS in FC2's installer, here is the last one: http://www.redhat.com/archives/fedora-devel-list/2003-December/msg01323.html So in general Red Hat wants to activate XFS support during installation, but hasn't yet decided on the user interaction. A GUI offered XFS would be optimal, a cmdline "linux xfs" boot installer option would be better than nothing. I just hope it doesn't get forgotten in the rather tight release schedule of FC2. :( --=20 Axel.Thimm@physik.fu-berlin.de --DqhR8hV3EnoxUkKN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQE/+8Q9QBVS1GOamfERAgmmAJ9GrgjLm30j+FwdPiFoJ205Sdx02QCfcjx0 w1iwyODfyJQ2Mxhzuh2FlDI= =tsVX -----END PGP SIGNATURE----- --DqhR8hV3EnoxUkKN-- From owner-linux-xfs@oss.sgi.com Wed Jan 7 02:24:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 02:25:03 -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 i07AOcTa021570 for ; Wed, 7 Jan 2004 02:24:40 -0800 Received: from LINSENEW ([10.0.0.161]) by miami.chance with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CFBZLZ9S; Wed, 7 Jan 2004 15:57:59 +0530 Message-ID: <004601c3d508$5bb77430$a100000a@linseNew> From: "Linse A Pallan" To: Cc: , "Eric Sandeen" References: Subject: Re: ACL Maximum Entries Restriction Date: Wed, 7 Jan 2004 15:53:56 +0530 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 1634 X-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: 1580 Lines: 52 Hi, While working around with XFS ACL I noticed that we can't have more than 25 entries per ACL. Through Linux-xfs mailing list I found that you having a patch to increase the maximum ACL entries from default 25 entries to 128 entries. Can you help me to solve this issue with your patch? Thanking you in advance.. Regards, Linse A Pallan ----- Original Message ----- From: "Eric Sandeen" To: "Linse A Pallan" Cc: Sent: Monday, January 05, 2004 8:54 PM Subject: Re: ACL Maximum Entries Restriction > I'm fairly certain that doing this will require an on-disk > format change; there may be other issues as well. John Trostel > had a patch at one point to allow this. Please check > the archives for previous discussions of this issue, including > why you may be better off using groups. > > -Eric > > On Mon, 5 Jan 2004, Linse A Pallan wrote: > > > Hi, > > > > While working with the XFS File system I found that we can have only maximum of 25 entries per ACL. Is there any way to increase this Maximum limit? I made try by changing the definition "#define XFS_ACL_MAX_ENTRIES 25" in file fs/xfs/xfs_acl.h to "#define XFS_ACL_MAX_ENTRIES 1000". After this change I rebuild the kernel and I am able to having maximum of 1000 entries per ACL. Is there any pitfalls/drawbacks in increasing the ACL maximum entries limit like this? Or is there any other way to increase the ACL Entries Maximum Limit? > > > > Thanking you in advance, > > > > Linse A Pallan > > > > [[HTML alternate version deleted]] > > > > From owner-linux-xfs@oss.sgi.com Wed Jan 7 02:35:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 02:35:48 -0800 (PST) Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07AZGTa022116 for ; Wed, 7 Jan 2004 02:35:17 -0800 Received: from bliss.uni-koblenz.de (bliss.uni-koblenz.de [141.26.64.65]) by mailhost.uni-koblenz.de (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i07AZDjR009688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jan 2004 11:35:14 +0100 Received: from localhost (localhost [127.0.0.1]) by bliss.uni-koblenz.de (8.12.10/8.12.3) with ESMTP id i07AZDRK015223; Wed, 7 Jan 2004 11:35:13 +0100 From: Rainer Krienke Organization: Uni Koblenz To: Eric Sandeen Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem Date: Wed, 7 Jan 2004 11:35:12 +0100 User-Agent: KMail/1.5.4 Cc: linux-xfs@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_gD++/62a0P9tQvn"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401071135.12886.krienke@uni-koblenz.de> X-Virus-Scanned: by amavisd-new X-archive-position: 1635 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: krienke@uni-koblenz.de Precedence: bulk X-list: linux-xfs Content-Length: 2122 Lines: 61 --Boundary-02=_gD++/62a0P9tQvn Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Dienstag, 6. Januar 2004 15:40, Eric Sandeen wrote: > > > Thanks for these explanations. Perhaps the buffer in the hardware raids > > that are used as basis for data storage are to blame (IFT 7250 Raid > > (Level 5), with 12 160GB IDE disks inside). I'll try to find out if this > > cache is read only or read/write. > > Ah, and if the hardware raid does write caching, and it's not battery > backed, then you -could- have inconsistency problems. if the raid > claims that something is written when in fact it is only cached, > then there is a chance that the fs+log is inconsistent in the > case of a power failure. > In between I contacted the vendor of the hardware IDE raids. The technician= =20 confirmed that these raids have a read/write cache and that there is *no*= =20 battery backup. So in case of an active filesystem where suddenly there is = a=20 powerfail, it is likely that the hardware cache in the raid is not written = to=20 disk and the filesystem will be become inconsitent. And this very probably= =20 happened in my case.=20 So the remaining question is only why xfs_repair was unable to repair the= =20 damaged filesystem.... Thanks Rainer --=20 --------------------------------------------------------------------------- Rainer Krienke, Universitaet Koblenz, Rechenzentrum, Raum A022 Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html --------------------------------------------------------------------------- --Boundary-02=_gD++/62a0P9tQvn Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/++Dgaldtjc/KDEoRAoK0AKDivZdxmqBIWSB4EQtpcwtnueUkCQCeLmXS U+OBIDr4t//2K2XQ/WV9dRk= =xhN0 -----END PGP SIGNATURE----- --Boundary-02=_gD++/62a0P9tQvn-- From owner-linux-xfs@oss.sgi.com Wed Jan 7 02:36:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 02:36:22 -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 i07Aa7Ta022235 for ; Wed, 7 Jan 2004 02:36:08 -0800 Received: from LINSENEW ([10.0.0.161]) by miami.chance with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CFBZLZ90; Wed, 7 Jan 2004 16:09:31 +0530 Message-ID: <006301c3d509$f82bfc40$a100000a@linseNew> From: "Linse A Pallan" To: Cc: , "Eric Sandeen" References: Subject: Re: ACL Maximum Entries Restriction Date: Wed, 7 Jan 2004 16:05:28 +0530 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 1636 X-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: 1566 Lines: 51 Hi, While working around with XFS ACL I noticed that we can't have more than 25 entries per ACL. Through Linux-xfs mailing list I found that you having a patch to increase the maximum ACL entries from default 25 entries to 128 entries. Can you help me to solve this issue? Thanking you in advance.. Regards, Linse A Pallan ----- Original Message ----- From: "Eric Sandeen" To: "Linse A Pallan" Cc: Sent: Monday, January 05, 2004 8:54 PM Subject: Re: ACL Maximum Entries Restriction > I'm fairly certain that doing this will require an on-disk > format change; there may be other issues as well. John Trostel > had a patch at one point to allow this. Please check > the archives for previous discussions of this issue, including > why you may be better off using groups. > > -Eric > > On Mon, 5 Jan 2004, Linse A Pallan wrote: > > > Hi, > > > > While working with the XFS File system I found that we can have only maximum of 25 entries per ACL. Is there any way to increase this Maximum limit? I made try by changing the definition "#define XFS_ACL_MAX_ENTRIES 25" in file fs/xfs/xfs_acl.h to "#define XFS_ACL_MAX_ENTRIES 1000". After this change I rebuild the kernel and I am able to having maximum of 1000 entries per ACL. Is there any pitfalls/drawbacks in increasing the ACL maximum entries limit like this? Or is there any other way to increase the ACL Entries Maximum Limit? > > > > Thanking you in advance, > > > > Linse A Pallan > > > > [[HTML alternate version deleted]] > > > > From owner-linux-xfs@oss.sgi.com Wed Jan 7 07:08:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 07:08:38 -0800 (PST) Received: from imf22aec.mail.bellsouth.net (imf22aec.mail.bellsouth.net [205.152.59.70]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07F88Ta004975 for ; Wed, 7 Jan 2004 07:08:09 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf22aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040107150801.IKFA1951.imf22aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Wed, 7 Jan 2004 10:08:01 -0500 Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Rainer Krienke Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <200401071135.12886.krienke@uni-koblenz.de> References: <200401071135.12886.krienke@uni-koblenz.de> Content-Type: text/plain Message-Id: <1073487512.19559.8.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Rubber Turnip www.usr-local-bin.org Date: Wed, 07 Jan 2004 09:58:34 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1637 X-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: 816 Lines: 22 On Wed, 2004-01-07 at 05:35, Rainer Krienke wrote: > In between I contacted the vendor of the hardware IDE raids. The technician > confirmed that these raids have a read/write cache and that there is *no* > battery backup. So in case of an active filesystem where suddenly there is a > powerfail, it is likely that the hardware cache in the raid is not written to > disk and the filesystem will be become inconsitent. And this very probably > happened in my case. > XFS gurus: If Rainer's raid system can not have the write cache enabled, is he getting any benefit from the XFS Journaling? I guess if it is an external array which does not have to have its power cycled if/when the server has its power cycled, then at least the journaling is used in the event of a kernel lockup. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Wed Jan 7 07:24:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 07:25:08 -0800 (PST) Received: from imf25aec.mail.bellsouth.net (imf25aec.mail.bellsouth.net [205.152.59.73]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07FOvTa005717 for ; Wed, 7 Jan 2004 07:24:57 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf25aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040107152446.MSH1944.imf25aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Wed, 7 Jan 2004 10:24:46 -0500 Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Rainer Krienke Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1073487512.19559.8.camel@david.internal.NorcrossGroup.com> References: <200401071135.12886.krienke@uni-koblenz.de> <1073487512.19559.8.camel@david.internal.NorcrossGroup.com> Content-Type: text/plain Message-Id: <1073488520.19553.10.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Rubber Turnip www.usr-local-bin.org Date: Wed, 07 Jan 2004 10:15:20 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1638 X-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: 906 Lines: 22 On Wed, 2004-01-07 at 09:58, Greg Freemyer wrote: > On Wed, 2004-01-07 at 05:35, Rainer Krienke wrote: > > > In between I contacted the vendor of the hardware IDE raids. The technician > > confirmed that these raids have a read/write cache and that there is *no* > > battery backup. So in case of an active filesystem where suddenly there is a > > powerfail, it is likely that the hardware cache in the raid is not written to > > disk and the filesystem will be become inconsitent. And this very probably > > happened in my case. > > > XFS gurus: > > If Rainer's raid system can not have the write cache enabled, is he s/enabled/disabled/ > getting any benefit from the XFS Journaling? > > I guess if it is an external array which does not have to have its power > cycled if/when the server has its power cycled, then at least the > journaling is used in the event of a kernel lockup. > > Greg From owner-linux-xfs@oss.sgi.com Wed Jan 7 07:27:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 07:27:25 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07FRBTa006112 for ; Wed, 7 Jan 2004 07:27:14 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i07FPEge025803; Wed, 7 Jan 2004 06:25:14 -0900 Date: Wed, 7 Jan 2004 06:25:14 -0900 (AKST) From: Arthur Corliss X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: Scott Fagg cc: linux-xfs@oss.sgi.com Subject: Re: state of XFS capable linux installers In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1639 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@digitalmages.com Precedence: bulk X-list: linux-xfs Content-Length: 652 Lines: 16 On Wed, 7 Jan 2004, Scott Fagg wrote: > > I have a couple of RH7.3 XFS boxes i'd like to upgrade, most likely to fedora + 2.6.x. > > What's the state of the xfs-capable installers ? Is there one for fedora yet ? What we be involved in making such a thing ? I'm somewhat confused by this question. While I don't use off-the-shelf distros anymore, didn't most support XFS during install for a while now? Slack had it as an option back in 8.x, if I recall correctly. --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ "Live Free or Die, the Only Way to Live" -- NH State Motto From owner-linux-xfs@oss.sgi.com Wed Jan 7 07:39:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 07:39:39 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07FdQTa006698 for ; Wed, 7 Jan 2004 07:39:27 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i07FdLJt009999 for ; Wed, 7 Jan 2004 07:39: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 i07FdKh728108439; Wed, 7 Jan 2004 09:39: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 i07FdJK213158903; Wed, 7 Jan 2004 09:39:19 -0600 (CST) Date: Wed, 7 Jan 2004 09:39:19 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Arthur Corliss cc: Scott Fagg , Subject: Re: state of XFS capable linux installers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1640 X-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: 1021 Lines: 30 The original poster made the common error of equating "Linux" solely with "Red Hat," and Red Hat is indeed pretty much the last distro that has no xfs support. See ftp://oss.sgi.com/projects/xfs/xfs_users.html for a list of distros that have supported xfs for quite some time now. -Eric On Wed, 7 Jan 2004, Arthur Corliss wrote: > On Wed, 7 Jan 2004, Scott Fagg wrote: > > > > > I have a couple of RH7.3 XFS boxes i'd like to upgrade, most likely to fedora + 2.6.x. > > > > What's the state of the xfs-capable installers ? Is there one for fedora yet ? What we be involved in making such a thing ? > > I'm somewhat confused by this question. While I don't use off-the-shelf > distros anymore, didn't most support XFS during install for a while now? > Slack had it as an option back in 8.x, if I recall correctly. > > --Arthur Corliss > Bolverk's Lair -- http://arthur.corlissfamily.org/ > Digital Mages -- http://www.digitalmages.com/ > "Live Free or Die, the Only Way to Live" -- NH State Motto > > From owner-linux-xfs@oss.sgi.com Wed Jan 7 07:44:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 07:44:45 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07FiXTa007185 for ; Wed, 7 Jan 2004 07:44:33 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i07Fgcge026369; Wed, 7 Jan 2004 06:42:38 -0900 Date: Wed, 7 Jan 2004 06:42:38 -0900 (AKST) From: Arthur Corliss X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: Rainer Krienke cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem In-Reply-To: <200401071135.12886.krienke@uni-koblenz.de> Message-ID: References: <200401071135.12886.krienke@uni-koblenz.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1641 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@digitalmages.com Precedence: bulk X-list: linux-xfs Content-Length: 1136 Lines: 25 On Wed, 7 Jan 2004, Rainer Krienke wrote: > In between I contacted the vendor of the hardware IDE raids. The technician > confirmed that these raids have a read/write cache and that there is *no* > battery backup. So in case of an active filesystem where suddenly there is a > powerfail, it is likely that the hardware cache in the raid is not written to > disk and the filesystem will be become inconsitent. And this very probably > happened in my case. > > So the remaining question is only why xfs_repair was unable to repair the > damaged filesystem.... If I had to hazard a guess, I'd think that the transaction log, being hit much more frequently than most other portions of the filesystem, would be much more aggressively cached by the hardware's algorithms, which would leave the log that much more inconsistent than the filesystem. *That* can't help during repairs. . . In any event, it sounds like you need a UPS on that system now, eh? --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ "Live Free or Die, the Only Way to Live" -- NH State Motto From owner-linux-xfs@oss.sgi.com Wed Jan 7 07:52:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 07:52:25 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07FqDTa007652 for ; Wed, 7 Jan 2004 07:52:14 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i07FoFge026574; Wed, 7 Jan 2004 06:50:15 -0900 Date: Wed, 7 Jan 2004 06:50:15 -0900 (AKST) From: Arthur Corliss X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: Eric Sandeen cc: Scott Fagg , linux-xfs@oss.sgi.com Subject: Re: state of XFS capable linux installers In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1642 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@digitalmages.com Precedence: bulk X-list: linux-xfs Content-Length: 687 Lines: 19 On Wed, 7 Jan 2004, Eric Sandeen wrote: > The original poster made the common error of equating "Linux" > solely with "Red Hat," and Red Hat is indeed pretty much the last > distro that has no xfs support. > > See ftp://oss.sgi.com/projects/xfs/xfs_users.html > for a list of distros that have supported xfs for quite some > time now. Had to change the protocol to HTTP, but I found it, thanks. Do you need to add my own homebrew kludge to the list? ;-) Wouldn't want to maintain *that* list. . . --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ "Live Free or Die, the Only Way to Live" -- NH State Motto From owner-linux-xfs@oss.sgi.com Wed Jan 7 07:54:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 07:54:33 -0800 (PST) Received: from imf25aec.mail.bellsouth.net (imf25aec.mail.bellsouth.net [205.152.59.73]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07FsLTa008083 for ; Wed, 7 Jan 2004 07:54:21 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf25aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040107155409.BCSD1944.imf25aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Wed, 7 Jan 2004 10:54:09 -0500 Subject: Re: state of XFS capable linux installers From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Eric Sandeen Cc: Arthur Corliss , Scott Fagg , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1073490282.19560.17.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Rubber Turnip www.usr-local-bin.org Date: Wed, 07 Jan 2004 10:44:42 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1643 X-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: 613 Lines: 21 On Wed, 2004-01-07 at 10:39, Eric Sandeen wrote: > See ftp://oss.sgi.com/projects/xfs/xfs_users.html > for a list of distros that have supported xfs for quite some > time now. > > -Eric That's an interesting list, but I know SUSE considered XFS experimental in the 8.0 release mentioned. I'm curious when the various releases started 'supporting' xfs. (Or whatever the right phrase is.) For instance, I don't know SUSE's current treatment of XFS. ie. Is it still experimental? I know I just upgraded a couple of SUSE 8.2 servers to 9.0 due to issues I believe were caused by xfs. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Wed Jan 7 09:36:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 09:37:06 -0800 (PST) Received: from twin.jikos.cz (IDENT:root@twin.jikos.cz [213.151.79.26]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07HarTa014864 for ; Wed, 7 Jan 2004 09:36:54 -0800 Received: from localhost (jikos@localhost) by twin.jikos.cz (8.11.6/8.11.6) with ESMTP id i07HanH26007; Wed, 7 Jan 2004 18:36:49 +0100 Date: Wed, 7 Jan 2004 18:36:49 +0100 (CET) From: Jirka Kosina To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: XFS over 7.7TB LVM partition through NFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1644 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jikos@jikos.cz Precedence: bulk X-list: linux-xfs Content-Length: 4629 Lines: 69 Hi, I am experiencing problems with LVM2 XFS partition in 2.6.0 being accessed over NFS. After exporting the filesystem clients start writing files to this partition over NFS, and after a short while we get this call trace, repeating indefinitely on the screen and the machine stops responding (keyboard, network): Jan 8 01:40:28 storage2 kernel: Call Trace: Jan 8 01:40:28 storage2 kernel: [xfs_alloc_read_agf+321/582] xfs_alloc_read_agf+0x141/0x246 Jan 8 01:40:28 storage2 kernel: [xfs_alloc_fix_freelist+452/1200] xfs_alloc_fix_freelist+0x1c4/0x4b0 Jan 8 01:40:28 storage2 last message repeated 2 times Jan 8 01:40:28 storage2 kernel: [xfs_alloc_vextent+711/1324] xfs_alloc_vextent+0x2c7/0x52c Jan 8 01:40:28 storage2 kernel: [xfs_bmap_alloc+4129/6483] xfs_bmap_alloc+0x1021/0x1953 Jan 8 01:40:28 storage2 kernel: [handle_IRQ_event+58/100] handle_IRQ_event+0x3a/0x64 Jan 8 01:40:28 storage2 kernel: [ata_output_data+187/207] ata_output_data+0xbb/0xcf Jan 8 01:40:28 storage2 kernel: [xfs_bmbt_get_state+47/59] xfs_bmbt_get_state+0x2f/0x3b Jan 8 01:40:28 storage2 kernel: [xfs_bmapi+1611/5752] xfs_bmapi+0x64b/0x1678 Jan 8 01:40:28 storage2 kernel: [update_process_times+70/82] update_process_times+0x46/0x52 Jan 8 01:40:28 storage2 kernel: [xfs_bmbt_get_state+47/59] xfs_bmbt_get_state+0x2f/0x3b Jan 8 01:40:28 storage2 kernel: [xfs_log_reserve+142/211] xfs_log_reserve+0x8e/0xd3 Jan 8 01:40:28 storage2 kernel: [xfs_iomap_write_allocate+594/1341] xfs_iomap_write_allocate+0x252/0x53d Jan 8 01:40:28 storage2 kernel: [apic_timer_interrupt+26/32] apic_timer_interrupt+0x1a/0x20 Jan 8 01:40:28 storage2 kernel: [xfs_iunlock+74/116] xfs_iunlock+0x4a/0x74 Jan 8 01:40:28 storage2 kernel: [xfs_iomap+1001/1357] xfs_iomap+0x3e9/0x54d Jan 8 01:40:28 storage2 kernel: [map_blocks+120/345] map_blocks+0x78/0x159 Jan 8 01:40:28 storage2 kernel: [page_state_convert+1200/1628] page_state_convert+0x4b0/0x65c Jan 8 01:40:28 storage2 kernel: [pagebuf_iorequest+170/354] pagebuf_iorequest+0xaa/0x162 Jan 8 01:40:28 storage2 kernel: [xfs_xlate_dinode_core+1319/2142] xfs_xlate_dinode_core+0x527/0x85e Jan 8 01:40:28 storage2 kernel: [xfs_bdstrat_cb+58/72] xfs_bdstrat_cb+0x3a/0x48 Jan 8 01:40:28 storage2 kernel: [pagebuf_iostart+72/162] pagebuf_iostart+0x48/0xa2 Jan 8 01:40:28 storage2 kernel: [xfs_iflush+652/1288] xfs_iflush+0x28c/0x508 Jan 8 01:40:28 storage2 kernel: [linvfs_writepage+96/282] linvfs_writepage+0x60/0x11a Jan 8 01:40:28 storage2 kernel: [mpage_writepages+532/794] mpage_writepages+0x214/0x31a Jan 8 01:40:28 storage2 kernel: [linvfs_writepage+0/282] linvfs_writepage+0x0/0x11a Jan 8 01:40:28 storage2 kernel: [do_writepages+54/58] do_writepages+0x36/0x3a Jan 8 01:40:28 storage2 kernel: [__sync_single_inode+211/545] __sync_single_inode+0xd3/0x221 Jan 8 01:40:28 storage2 kernel: [sync_sb_inodes+381/675] sync_sb_inodes+0x17d/0x2a3 Jan 8 01:40:28 storage2 kernel: [writeback_inodes+80/163] writeback_inodes+0x50/0xa3 Jan 8 01:40:28 storage2 kernel: [balance_dirty_pages+72/318] balance_dirty_pages+0x48/0x13e Jan 8 01:40:28 storage2 kernel: [generic_file_aio_write_nolock+1292/3062] generic_file_aio_write_nolock+0x50c/0xbf6 Jan 8 01:40:28 storage2 kernel: [schedule+612/1485] schedule+0x264/0x5cd Jan 8 01:40:28 storage2 kernel: [default_wake_function+0/18] default_wake_function+0x0/0x12 Jan 8 01:40:28 storage2 kernel: [xfs_ichgtime+83/300] xfs_ichgtime+0x53/0x12c Jan 8 01:40:28 storage2 kernel: [xfs_iunlock+74/116] xfs_iunlock+0x4a/0x74 Jan 8 01:40:28 storage2 kernel: [xfs_write+637/2192] xfs_write+0x27d/0x890 Jan 8 01:40:28 storage2 kernel: [xfs_ichgtime+250/300] xfs_ichgtime+0xfa/0x12c Jan 8 01:40:28 storage2 kernel: [linvfs_write+213/333] linvfs_write+0xd5/0x14d Jan 8 01:40:28 storage2 kernel: [do_sync_write+139/205] do_sync_write+0x8b/0xcd Jan 8 01:40:28 storage2 kernel: [update_process_times+70/82] update_process_times+0x46/0x52 Jan 8 01:40:28 storage2 kernel: [update_wall_time+13/54] update_wall_time+0xd/0x36 Jan 8 01:40:28 storage2 kernel: [do_IRQ+277/307] do_IRQ+0x115/0x133 Jan 8 01:40:28 storage2 kernel: [do_sync_write+0/205] do_sync_write+0x0/0xcd Jan 8 01:40:28 storage2 kernel: [vfs_write+211/322] vfs_write+0xd3/0x142 Jan 8 01:40:28 storage2 kernel: [sys_write+66/99] sys_write+0x42/0x63 Jan 8 01:40:28 storage2 kernel: [syscall_call+7/11] syscall_call+0x7/0xb We are using kernel 2.6.0, LVM2.2.00.08 and device-mapper.1.00.07 The partition is approximately 7.7TB large. (please CC: me on reply, as I am only subscribed to LKML and not to linux-xfs). Thanks in advance. -- JiKos. From owner-linux-xfs@oss.sgi.com Wed Jan 7 10:00:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 10:00:34 -0800 (PST) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07I0MTa015503 for ; Wed, 7 Jan 2004 10:00:22 -0800 Received: from matchmail.com (adsl-63-194-239-202.dsl.lsan03.pacbell.net [63.194.239.202]) by mta7.pltn13.pbi.net (8.12.10/8.12.10) with ESMTP id i07I0IHp015820; Wed, 7 Jan 2004 10:00:19 -0800 (PST) Received: from mfedyk by matchmail.com with local (Exim 4.30) id 1AeHyL-0003yb-Ql; Wed, 07 Jan 2004 10:00:01 -0800 Date: Wed, 7 Jan 2004 10:00:01 -0800 From: Mike Fedyk To: Jirka Kosina Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS over 7.7TB LVM partition through NFS Message-ID: <20040107180001.GM1882@matchmail.com> Mail-Followup-To: Jirka Kosina , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: 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: 1645 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mfedyk@matchmail.com Precedence: bulk X-list: linux-xfs Content-Length: 535 Lines: 14 On Wed, Jan 07, 2004 at 06:36:49PM +0100, Jirka Kosina wrote: > Hi, > > I am experiencing problems with LVM2 XFS partition in 2.6.0 being accessed > over NFS. After exporting the filesystem clients start writing files to > this partition over NFS, and after a short while we get this call trace, > repeating indefinitely on the screen and the machine stops responding > (keyboard, network): > > Jan 8 01:40:28 storage2 kernel: Call Trace: You left out the headers with all of the register value information, especially EIP... From owner-linux-xfs@oss.sgi.com Wed Jan 7 10:09:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 10:09:15 -0800 (PST) Received: from twin.jikos.cz (IDENT:root@twin.jikos.cz [213.151.79.26]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07I93Ta015973 for ; Wed, 7 Jan 2004 10:09:03 -0800 Received: from localhost (jikos@localhost) by twin.jikos.cz (8.11.6/8.11.6) with ESMTP id i07I90o16246; Wed, 7 Jan 2004 19:09:00 +0100 Date: Wed, 7 Jan 2004 19:09:00 +0100 (CET) From: Jirka Kosina To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS over 7.7TB LVM partition through NFS In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1646 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jikos@jikos.cz Precedence: bulk X-list: linux-xfs Content-Length: 772 Lines: 21 On Wed, 7 Jan 2004, Jirka Kosina wrote: > I am experiencing problems with LVM2 XFS partition in 2.6.0 being accessed > over NFS. After exporting the filesystem clients start writing files to > this partition over NFS, and after a short while we get this call trace, > repeating indefinitely on the screen and the machine stops responding > (keyboard, network): I am sorry, I have mis-pasted the log, it was not complete - there are two extra lines before the Call Trace ... these two: Jan 8 01:38:35 storage2 kernel: 0x0: 94 38 73 54 cc 8c c9 be 0c 3e 6b 30 4c 9f 54 c5 Jan 8 01:38:35 storage2 kernel: Filesystem "dm-0": XFS internal error xfs_alloc_read_agf at line 2208 of file fs/xfs/xfs_alloc.c. Caller 0xc01fab06 Sorry for the inconvience. -- JiKos. From owner-linux-xfs@oss.sgi.com Wed Jan 7 10:21:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 10:21:18 -0800 (PST) Received: from mtaw4.prodigy.net (mtaw4.prodigy.net [64.164.98.52]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07IL7Ta016429 for ; Wed, 7 Jan 2004 10:21:07 -0800 Received: from matchmail.com (adsl-63-194-239-202.dsl.lsan03.pacbell.net [63.194.239.202]) by mtaw4.prodigy.net (8.12.10/8.12.10) with ESMTP id i07IL2SP004900; Wed, 7 Jan 2004 10:21:02 -0800 (PST) Received: from mfedyk by matchmail.com with local (Exim 4.30) id 1AeIIW-0004mi-9I; Wed, 07 Jan 2004 10:20:52 -0800 Date: Wed, 7 Jan 2004 10:20:52 -0800 From: Mike Fedyk To: Jirka Kosina Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS over 7.7TB LVM partition through NFS Message-ID: <20040107182052.GO1882@matchmail.com> Mail-Followup-To: Jirka Kosina , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: 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: 1647 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mfedyk@matchmail.com Precedence: bulk X-list: linux-xfs Content-Length: 860 Lines: 19 On Wed, Jan 07, 2004 at 07:09:00PM +0100, Jirka Kosina wrote: > On Wed, 7 Jan 2004, Jirka Kosina wrote: > > > I am experiencing problems with LVM2 XFS partition in 2.6.0 being accessed > > over NFS. After exporting the filesystem clients start writing files to > > this partition over NFS, and after a short while we get this call trace, > > repeating indefinitely on the screen and the machine stops responding > > (keyboard, network): > > I am sorry, I have mis-pasted the log, it was not complete - there are two > extra lines before the Call Trace ... these two: > > Jan 8 01:38:35 storage2 kernel: 0x0: 94 38 73 54 cc 8c c9 be 0c 3e 6b 30 > 4c 9f 54 c5 > Jan 8 01:38:35 storage2 kernel: Filesystem "dm-0": XFS internal error > xfs_alloc_read_agf at line 2208 of file fs/xfs/xfs_alloc.c. Caller 0xc01fab06 Try a fsck on your xfs partitions. From owner-linux-xfs@oss.sgi.com Wed Jan 7 10:35:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 10:35:19 -0800 (PST) Received: from mail.myphorum.de (mysnip.de.gw.net-build.de [194.25.82.254] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07IZ7Ta016985 for ; Wed, 7 Jan 2004 10:35:07 -0800 Received: from localhost (myphorum [127.0.0.1]) by mail.myphorum.de (Postfix) with ESMTP id C5B762744B5; Wed, 7 Jan 2004 19:35:05 +0100 (CET) Received: from mail.myphorum.de ([127.0.0.1]) by localhost (myphorum.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19254-04; Wed, 7 Jan 2004 19:35:05 +0100 (CET) Received: from db.myphorum.de (host-184-82-25-194.net-build.de [194.25.82.184]) by mail.myphorum.de (Postfix) with ESMTP id 8155B2744AF; Wed, 7 Jan 2004 19:35:05 +0100 (CET) X-Originating-IP: [unknown] From: "Thomas Seifert" To: "Mike Fedyk" , "Jirka Kosina" Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS over 7.7TB LVM partition through NFS Date: Wed, 07 Jan 2004 18:35:05 +0000 Message-ID: <20040107.8Z4.43021900@db.myphorum.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline X-Mailer: AngleMail for phpGroupWare (http://www.phpgroupware.org) v 0.9.99.008 X-Virus-Scanned: by amavisd-new at mysnip.de Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i07IZ8Ta016986 X-archive-position: 1648 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: thomas-lists@myphorum.com Precedence: bulk X-list: linux-xfs Content-Length: 986 Lines: 32 fsck? shouldn't it read xfs_repair ??? thomas Mike Fedyk (mfedyk@matchmail.com) schrieb: > > On Wed, Jan 07, 2004 at 07:09:00PM +0100, Jirka Kosina wrote: > > On Wed, 7 Jan 2004, Jirka Kosina wrote: > > > > > I am experiencing problems with LVM2 XFS partition in 2.6.0 being accessed > > > over NFS. After exporting the filesystem clients start writing files to > > > this partition over NFS, and after a short while we get this call trace, > > > repeating indefinitely on the screen and the machine stops responding > > > (keyboard, network): > > > > I am sorry, I have mis-pasted the log, it was not complete - there are two > > extra lines before the Call Trace ... these two: > > > > Jan 8 01:38:35 storage2 kernel: 0x0: 94 38 73 54 cc 8c c9 be 0c 3e 6b 30 > > 4c 9f 54 c5 > > Jan 8 01:38:35 storage2 kernel: Filesystem "dm-0": XFS internal error > > xfs_alloc_read_agf at line 2208 of file fs/xfs/xfs_alloc.c. Caller 0xc01fab06 > > Try a fsck on your xfs partitions. > > > From owner-linux-xfs@oss.sgi.com Wed Jan 7 10:35:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 10:35:36 -0800 (PST) Received: from twin.jikos.cz (IDENT:root@twin.jikos.cz [213.151.79.26]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07IZOTa017014 for ; Wed, 7 Jan 2004 10:35:24 -0800 Received: from localhost (jikos@localhost) by twin.jikos.cz (8.11.6/8.11.6) with ESMTP id i07IZGl18252; Wed, 7 Jan 2004 19:35:16 +0100 Date: Wed, 7 Jan 2004 19:35:16 +0100 (CET) From: Jirka Kosina To: Mike Fedyk cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS over 7.7TB LVM partition through NFS In-Reply-To: <20040107182052.GO1882@matchmail.com> Message-ID: References: <20040107182052.GO1882@matchmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1649 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jikos@jikos.cz Precedence: bulk X-list: linux-xfs Content-Length: 981 Lines: 24 On Wed, 7 Jan 2004, Mike Fedyk wrote: > > > I am experiencing problems with LVM2 XFS partition in 2.6.0 being accessed > > > over NFS. After exporting the filesystem clients start writing files to > > > this partition over NFS, and after a short while we get this call trace, > > > repeating indefinitely on the screen and the machine stops responding > > > (keyboard, network): > > Jan 8 01:38:35 storage2 kernel: 0x0: 94 38 73 54 cc 8c c9 be 0c 3e 6b 30 > > 4c 9f 54 c5 > > Jan 8 01:38:35 storage2 kernel: Filesystem "dm-0": XFS internal error > > xfs_alloc_read_agf at line 2208 of file fs/xfs/xfs_alloc.c. Caller 0xc01fab06 > Try a fsck on your xfs partitions. storage2:~# fsck -V /dev/mapper/lvol1-lv1 fsck 1.35-WIP (07-Dec-2003) [/sbin/fsck.xfs (1) -- /dev/mapper/lvol1-lv1] fsck.xfs /dev/mapper/lvol1-lv1 Seems perfectly clean. This is brand new filesystem, bug occurs shortly after mkfs when clients start writing files a little bit intensively. -- JiKos. From owner-linux-xfs@oss.sgi.com Wed Jan 7 10:57:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 10:58:16 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07IvtTa017954 for ; Wed, 7 Jan 2004 10:57:55 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i07IvnJt011743 for ; Wed, 7 Jan 2004 10:57:49 -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 i07IvmMP28135197; Wed, 7 Jan 2004 12:57:48 -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 i07IvmK113188778; Wed, 7 Jan 2004 12:57:48 -0600 (CST) Subject: Re: XFS over 7.7TB LVM partition through NFS From: Eric Sandeen To: Jirka Kosina Cc: LKML , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1073501867.23356.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 07 Jan 2004 12:57:48 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1650 X-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: 1073 Lines: 31 Just to get this out of the way, I assume CONFIG_LBD is turned on? I think so, otherwise it should not mount. Also, is below an oops, or an xfs corruption message, or...? What came before the call trace. fsck won't do anything, fsck.xfs is a no-op. You could run xfs_repair over the fs to see what it finds. Also please include xfs_info output for the filesystem, and whether you expect that any clients are writing files > 4G... And, that stack looks awfully long if it's real, turning on the stack overflow check in the kernel might be interesting. -Eric On Wed, 2004-01-07 at 11:36, Jirka Kosina wrote: > Hi, > > I am experiencing problems with LVM2 XFS partition in 2.6.0 being accessed > over NFS. After exporting the filesystem clients start writing files to > this partition over NFS, and after a short while we get this call trace, > repeating indefinitely on the screen and the machine stops responding > (keyboard, network): -- 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 Jan 7 11:09:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 11:09:34 -0800 (PST) Received: from mail.tamiweb.com (mail.tamiweb.com [194.12.244.146]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07J9HTa018480 for ; Wed, 7 Jan 2004 11:09:20 -0800 Received: (qmail 13932 invoked by uid 89); 7 Jan 2004 19:08:38 -0000 Received: from unknown (HELO tanya.office) (larry@tamiweb.com@195.149.252.6) by 0 with SMTP; 7 Jan 2004 19:08:38 -0000 Subject: cvs again From: Kostadin Karaivanov Reply-To: larry@tamiweb.com To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: tamiweb Message-Id: <1073502528.6513.11.camel@laptop.minfin.bg> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 07 Jan 2004 21:08:48 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 1651 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@tamiweb.com Precedence: bulk X-list: linux-xfs Content-Length: 348 Lines: 12 Happy new year all! Since cvs is the only reliable way to keep my 2.4 kernel in sync I beleave I'm about to become anoing (this is my second or third mail on similar topic) but no [TAKE] after "attr/acl fix" including is accessible through your cvs server. Update passes away without touching anything on my side. ps. Still XFS rox wwell larry From owner-linux-xfs@oss.sgi.com Wed Jan 7 15:16:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 15:17:02 -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 i07NGnTa028094 for ; Wed, 7 Jan 2004 15:16:50 -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 i07NGm73026354 for ; Thu, 8 Jan 2004 10:16:48 +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 i07NGlxs018477 for ; Thu, 8 Jan 2004 10:16:47 +1100 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.10/8.12.10/Debian-6) with ESMTP id i07NGlM0012485 for ; Thu, 8 Jan 2004 10:16:47 +1100 Received: (from jason@localhost) by jdc.local (8.12.10/8.12.10/Debian-6) id i07NGllg012479; Thu, 8 Jan 2004 10:16:47 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16380.37727.379400.337561@jdc.local> Date: Thu, 8 Jan 2004 10:16:47 +1100 To: linux-xfs Subject: Re: TAKE - Upgrade to 2.4.25-pre4 In-Reply-To: <20040106231817.DE2638C870A@naboo.americas.sgi.com> References: <20040106231817.DE2638C870A@naboo.americas.sgi.com> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 1652 X-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: 121 Lines: 3 For some reason these changes haven't made it to the public cvs tree; when I run cvs update it is still at 2.4.24-pre1. From owner-linux-xfs@oss.sgi.com Wed Jan 7 15:42:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 15:43:03 -0800 (PST) Received: from twin.jikos.cz (IDENT:root@twin.jikos.cz [213.151.79.26]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07NgcTa028781 for ; Wed, 7 Jan 2004 15:42:41 -0800 Received: from localhost (jikos@localhost) by twin.jikos.cz (8.11.6/8.11.6) with ESMTP id i07Ng1t09000; Thu, 8 Jan 2004 00:42:01 +0100 Date: Thu, 8 Jan 2004 00:42:01 +0100 (CET) From: Jirka Kosina To: Eric Sandeen cc: LKML , linux-xfs@oss.sgi.com Subject: Re: XFS over 7.7TB LVM partition through NFS In-Reply-To: <1073501867.23356.5.camel@stout.americas.sgi.com> Message-ID: References: <1073501867.23356.5.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1653 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jikos@jikos.cz Precedence: bulk X-list: linux-xfs Content-Length: 10805 Lines: 325 Hi Eric, On Wed, 7 Jan 2004, Eric Sandeen wrote: > Just to get this out of the way, I assume CONFIG_LBD is turned on? > I think so, otherwise it should not mount. CONFIG_LBD is of course turned on - otherwise it won't be even possible to create such large LVM partition. > Also, is below an oops, or an xfs corruption message, or...? What came > before the call trace. This is really all I have in log (and syslog is logging kern.*). Here you can see a few previous lines: (so from my point of view this seems like XFS internal error, but I must admit that I am not familiar with XFS code and design at all) Jan 8 00:39:25 storage2 kernel: eth0: driver changed get_stats after register Jan 8 00:39:25 storage2 kernel: eth0: link now 1000 mbps, full duplex and up. Jan 8 00:39:25 storage2 kernel: XFS mounting filesystem dm-0 Jan 8 00:39:25 storage2 kernel: Ending clean XFS mount for filesystem: dm-0 Jan 8 01:38:35 storage2 kernel: 0x0: 94 38 73 54 cc 8c c9 be 0c 3e 6b 30 4c 9f 54 c5 Jan 8 01:38:35 storage2 kernel: Filesystem "dm-0": XFS internal error xfs_alloc_r ead_agf at line 2208 of file fs/xfs/xfs_alloc.c. Caller 0xc01fab06 Jan 8 01:38:35 storage2 kernel: Call Trace: Jan 8 01:38:35 storage2 kernel: [xfs_alloc_read_agf+321/582] xfs_alloc_read_agf+0x141/0x246 > You could run xfs_repair over the fs to see what it finds. storage2:~# xfs_repair /dev/mapper/lvol1-lv1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad on-disk superblock 6 - bad magic number primary/secondary superblock 6 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x94387354 for agf 6 bad version # -863188546 for agf 6 bad sequence # 205417264 for agf 6 bad length 1285510341 for agf 6, should be 60176384 flfirst -573275643 in agf 6 too large (max = 128) fllast 1287837829 in agf 6 too large (max = 128) bad magic # 0x43758d0d for agi 6 bad version # -985298009 for agi 6 bad sequence # -810919876 for agi 6 bad length # 1866908477 for agi 6, should be 60176384 reset bad sb for ag 6 reset bad agf for ag 6 reset bad agi for ag 6 bad agbno 2423917045 in agfl, agno 6 freeblk count 1 != flcount 1928110601 in ag 6 bad agbno 2083432091 for btbno root, agno 6 bad agbno 2649075945 for btbcnt root, agno 6 bad agbno 2607557273 for inobt root, agno 6 bad on-disk superblock 7 - bad magic number primary/secondary superblock 7 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 7 bad version # 0 for agf 7 bad sequence # 0 for agf 7 bad length 0 for agf 7, should be 60176384 bad magic # 0x0 for agi 7 bad version # 0 for agi 7 bad sequence # 0 for agi 7 bad length # 0 for agi 7, should be 60176384 reset bad sb for ag 7 reset bad agf for ag 7 reset bad agi for ag 7 bad agbno 0 for btbno root, agno 7 bad agbno 0 for btbcnt root, agno 7 bad agbno 0 for inobt root, agno 7 bad on-disk superblock 8 - bad magic number primary/secondary superblock 8 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 8 bad version # 0 for agf 8 bad sequence # 0 for agf 8 bad length 0 for agf 8, should be 60176384 bad magic # 0x0 for agi 8 bad version # 0 for agi 8 bad sequence # 0 for agi 8 bad length # 0 for agi 8, should be 60176384 reset bad sb for ag 8 reset bad agf for ag 8 reset bad agi for ag 8 bad agbno 0 for btbno root, agno 8 bad agbno 0 for btbcnt root, agno 8 bad agbno 0 for inobt root, agno 8 bad on-disk superblock 15 - bad magic number primary/secondary superblock 15 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 15 bad version # 0 for agf 15 bad sequence # 0 for agf 15 bad length 0 for agf 15, should be 60176384 bad magic # 0x0 for agi 15 bad version # 0 for agi 15 bad sequence # 0 for agi 15 bad length # 0 for agi 15, should be 60176384 reset bad sb for ag 15 reset bad agf for ag 15 reset bad agi for ag 15 bad agbno 0 for btbno root, agno 15 bad agbno 0 for btbcnt root, agno 15 bad agbno 0 for inobt root, agno 15 bad on-disk superblock 16 - bad magic number primary/secondary superblock 16 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 16 bad version # 0 for agf 16 bad sequence # 0 for agf 16 bad length 0 for agf 16, should be 60176384 bad magic # 0x0 for agi 16 bad version # 0 for agi 16 bad sequence # 0 for agi 16 bad length # 0 for agi 16, should be 60176384 reset bad sb for ag 16 reset bad agf for ag 16 reset bad agi for ag 16 bad agbno 0 for btbno root, agno 16 bad agbno 0 for btbcnt root, agno 16 bad agbno 0 for inobt root, agno 16 bad on-disk superblock 17 - bad magic number primary/secondary superblock 17 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 17 bad version # 0 for agf 17 bad sequence # 0 for agf 17 bad length 0 for agf 17, should be 60176384 bad magic # 0x0 for agi 17 bad version # 0 for agi 17 bad sequence # 0 for agi 17 bad length # 0 for agi 17, should be 60176384 reset bad sb for ag 17 reset bad agf for ag 17 reset bad agi for ag 17 bad agbno 0 for btbno root, agno 17 bad agbno 0 for btbcnt root, agno 17 bad agbno 0 for inobt root, agno 17 bad on-disk superblock 24 - bad magic number primary/secondary superblock 24 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 24 bad version # 0 for agf 24 bad sequence # 0 for agf 24 bad length 0 for agf 24, should be 60176384 bad magic # 0x0 for agi 24 bad version # 0 for agi 24 bad sequence # 0 for agi 24 bad length # 0 for agi 24, should be 60176384 reset bad sb for ag 24 reset bad agf for ag 24 reset bad agi for ag 24 bad agbno 0 for btbno root, agno 24 bad agbno 0 for btbcnt root, agno 24 bad agbno 0 for inobt root, agno 24 bad on-disk superblock 25 - bad magic number primary/secondary superblock 25 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 25 bad version # 0 for agf 25 bad sequence # 0 for agf 25 bad length 0 for agf 25, should be 60176384 bad magic # 0x0 for agi 25 bad version # 0 for agi 25 bad sequence # 0 for agi 25 bad length # 0 for agi 25, should be 60176384 reset bad sb for ag 25 reset bad agf for ag 25 reset bad agi for ag 25 bad agbno 0 for btbno root, agno 25 bad agbno 0 for btbcnt root, agno 25 bad agbno 0 for inobt root, agno 25 bad on-disk superblock 26 - bad magic number primary/secondary superblock 26 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 26 bad version # 0 for agf 26 bad sequence # 0 for agf 26 bad length 0 for agf 26, should be 60176384 bad magic # 0x0 for agi 26 bad version # 0 for agi 26 bad sequence # 0 for agi 26 bad length # 0 for agi 26, should be 60176384 reset bad sb for ag 26 reset bad agf for ag 26 reset bad agi for ag 26 bad agbno 0 for btbno root, agno 26 bad agbno 0 for btbcnt root, agno 26 bad agbno 0 for inobt root, agno 26 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... error following ag 6 unlinked list error following ag 7 unlinked list error following ag 8 unlinked list error following ag 15 unlinked list error following ag 16 unlinked list error following ag 17 unlinked list error following ag 24 unlinked list error following ag 25 unlinked list error following ag 26 unlinked list - 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 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - 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 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done (this is the same filesystem on which crash happened, I haven't done mkfs in between). > Also please include xfs_info output for the filesystem, and whether you > expect that any clients are writing files > 4G... Having ability for clients to write files larger than > 4G would be nice, but this bug occured even when clients wrote file approximately 700MB large. Here is xfs_info output: storage2:~# mount /raid3 storage2:~# xfs_info /dev/mapper/lvol1-lv1 meta-data=/raid3 isize=256 agcount=32, agsize=60176384 blks = sectsz=512 data = bsize=4096 blocks=1925644288, 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 > And, that stack looks awfully long if it's real, turning on the stack > overflow check in the kernel might be interesting. I will do it as soon as I get physically to the server, and will send you output, if it shows anything interesting (stack overflow). Thanks, kind regards, -- JiKos. From owner-linux-xfs@oss.sgi.com Wed Jan 7 18:50:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 18:51:03 -0800 (PST) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i082oiTa004628 for ; Wed, 7 Jan 2004 18:50:47 -0800 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <0.0022F523@mailhub2.arup.com>; Thu, 8 Jan 2004 2:50:38 +0000 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Thu, 08 Jan 2004 02:50:37 -0000 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Thu, 08 Jan 2004 13:48:22 +1100 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Thu, 08 Jan 2004 13:32:06 +1100 From: "Scott Fagg" To: Subject: Re: state of XFS capable linux installers Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i082olTa004634 X-archive-position: 1654 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 1705 Lines: 45 When i said 'linux' i was referring to linux distros in general, i wasn't trying to equate redhat to linux, it just so happens that i use redhat. Looks like FC2 is the closest answer, for now .. time to contribute. I have the problem that my redhat linux ;) box has XFS filesystems on all partitions, thanks to the SGI supplied RH7.3 installer. Now that i want to upgrade, i'm caught. I was hoping i could do some tricks by installing stuff to the 1GB swap partition, recompiling kernels and so on, but could never come up with a working process. Scott Fagg Arup Brisbane (07) 3023 6000 >>> Eric Sandeen 08/01/2004 1:39:19 AM >>> The original poster made the common error of equating "Linux" solely with "Red Hat," and Red Hat is indeed pretty much the last distro that has no xfs support. See ftp://oss.sgi.com/projects/xfs/xfs_users.html for a list of distros that have supported xfs for quite some time now. -Eric On Wed, 7 Jan 2004, Arthur Corliss wrote: > On Wed, 7 Jan 2004, Scott Fagg wrote: > > > > > I have a couple of RH7.3 XFS boxes i'd like to upgrade, most likely to fedora + 2.6.x. > > > > What's the state of the xfs-capable installers ? Is there one for fedora yet ? What we be involved in making such a thing ? > > I'm somewhat confused by this question. While I don't use off-the-shelf > distros anymore, didn't most support XFS during install for a while now? > Slack had it as an option back in 8.x, if I recall correctly. > > --Arthur Corliss > Bolverk's Lair -- http://arthur.corlissfamily.org/ > Digital Mages -- http://www.digitalmages.com/ > "Live Free or Die, the Only Way to Live" -- NH State Motto > > From owner-linux-xfs@oss.sgi.com Wed Jan 7 18:54:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 18:55:05 -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 i082srTa005060 for ; Wed, 7 Jan 2004 18:54:54 -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 i082slhG007523; Wed, 7 Jan 2004 20:54:48 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: TAKE - Upgrade to 2.4.25-pre4 From: Russell Cattelan To: jasonw@ariel.ucs.unimelb.edu.au Cc: linux-xfs In-Reply-To: <16380.37727.379400.337561@jdc.local> References: <20040106231817.DE2638C870A@naboo.americas.sgi.com> <16380.37727.379400.337561@jdc.local> Content-Type: text/plain Message-Id: <1073530386.81219.9.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 07 Jan 2004 20:53:06 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1655 X-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: 898 Lines: 22 On Wed, 2004-01-07 at 17:16, Jason White wrote: > For some reason these changes haven't made it to the public cvs tree; > when I run cvs update it is still at 2.4.24-pre1. yes sorry about this. We have done at bit of reworking of our internal trees and I haven't hooked up the ptools -> cvs scripts to the new trees. Since you brought it up: This is going to be notice to everybody doing cvs checkouts. The cvs trees are going to be updated soon and it will be best if everybody checks out a fresh copy of the trees. The xfs code will remain the same with the rcs versions in tack, but the surrounding linux trees have been re-imported from scratch. So none of the rcs versions will jive with what is currently in your cvs admin files. I really don't know how cvs would deal with the disconnect. I'll send out a note at to when the tree are updated. -- Russell Cattelan From owner-linux-xfs@oss.sgi.com Wed Jan 7 19:54:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Jan 2004 19:54:14 -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 i083s1Ta006160 for ; Wed, 7 Jan 2004 19:54:02 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.8) with ESMTP id i083rvYu020303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Jan 2004 04:53:58 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i083rnQp021428; Thu, 8 Jan 2004 04:53:49 +0100 Date: Thu, 8 Jan 2004 04:53:48 +0100 From: Axel Thimm To: Scott Fagg Cc: linux-xfs@oss.sgi.com Subject: Re: state of XFS capable linux installers Message-ID: <20040108035348.GW11093@neu.nirvana> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qZTZQd/MRfnLEAAX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 1656 X-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: 1749 Lines: 54 --qZTZQd/MRfnLEAAX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 08, 2004 at 01:32:06PM +1100, Scott Fagg wrote: >=20 > When i said 'linux' i was referring to linux distros in general, i > wasn't trying to equate redhat to linux, it just so happens that i > use redhat. >=20 > Looks like FC2 is the closest answer, for now .. time to contribute. >=20 > I have the problem that my redhat linux ;) box has XFS filesystems > on all partitions, thanks to the SGI supplied RH7.3 installer. Now > that i want to upgrade, i'm caught. I was hoping i could do some > tricks by installing stuff to the 1GB swap partition, recompiling > kernels and so on, but could never come up with a working process. Try installing an XFS capable kernel. If the system boots fine into it, try upgrading glibc. If your system still boots, upgrade rpm itself. If despite all odd even that succeeds, drop in non-X mode and update X. After that try apt-get dist-upgrade. Have a very long walk and come back to check which packages did not upgrade properly (you did add > /tmp/apt-get-dist-upgrade.log 2>&1 to the apt-get dist-upgrade, didn't you?;). Fix the 20-30 packages by manually uninstalling and reinstalling them again. If you have been reading thus far you are a lucky bastard ;) (more seriously: the above could work, but you should backup) --=20 Axel.Thimm@physik.fu-berlin.de --qZTZQd/MRfnLEAAX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQE//NRMQBVS1GOamfERAjP8AJ9J/6KI6cymziv4egCDwzYjBTe+MQCePwgm xWSFiwHStRDx3WKYJicpkPE= =zgZj -----END PGP SIGNATURE----- --qZTZQd/MRfnLEAAX-- From owner-linux-xfs@oss.sgi.com Thu Jan 8 07:20:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Jan 2004 07:20:35 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08FK8Ta004381 for ; Thu, 8 Jan 2004 07:20:08 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i08FICge020638; Thu, 8 Jan 2004 06:18:12 -0900 Date: Thu, 8 Jan 2004 06:18:12 -0900 (AKST) From: Arthur Corliss X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: Scott Fagg cc: linux-xfs@oss.sgi.com Subject: Re: state of XFS capable linux installers In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1657 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@digitalmages.com Precedence: bulk X-list: linux-xfs Content-Length: 1098 Lines: 20 On Thu, 8 Jan 2004, Scott Fagg wrote: > > When i said 'linux' i was referring to linux distros in general, i wasn't trying to equate redhat to linux, it just so happens that i use redhat. > > Looks like FC2 is the closest answer, for now .. time to contribute. > > I have the problem that my redhat linux ;) box has XFS filesystems on all partitions, thanks to the SGI supplied RH7.3 installer. Now that i want to upgrade, i'm caught. I was hoping i could do some tricks by installing stuff to the 1GB swap partition, recompiling kernels and so on, but could never come up with a working process. The last Slack I used (8.1) wasn't clued-in enough to provide a SCSI+XFS kernel, so I would install a mini-root type system with a compiler and kernel source into the swap partition, recompile the kernel, reboot, and migrate back onto the old FS (or create new ones). If you have the RAM that should work nicely. --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ "Live Free or Die, the Only Way to Live" -- NH State Motto From owner-linux-xfs@oss.sgi.com Thu Jan 8 08:14:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Jan 2004 08:15: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 i08GEsTa007156 for ; Thu, 8 Jan 2004 08:14:54 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i08GEsRt007155 for linux-xfs@oss.sgi.com; Thu, 8 Jan 2004 08:14:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i08GEqTc007140 for ; Thu, 8 Jan 2004 08:14:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i08FeYnu005963; Thu, 8 Jan 2004 07:40:34 -0800 Date: Thu, 8 Jan 2004 07:40:34 -0800 Message-Id: <200401081540.i08FeYnu005963@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: 1658 X-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: 478 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=294 ------- Additional Comments From Peter.Kelemen+sgi@cern.ch 2004-08-01 07:40 PDT ------- Unfortunately, it behaves exactly the same wihtout the the AFS module as well. xfs_dilocate() starts spitting debug info (about one each second) the moment QA013 starts; the umount segfaults and the machine oopses. ------- 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 Jan 8 10:29:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Jan 2004 10:29:58 -0800 (PST) Received: from mail.blazebox.homeip.net (postfix@pool-162-83-214-231.ny5030.east.verizon.net [162.83.214.231]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08ITjTa018393 for ; Thu, 8 Jan 2004 10:29:46 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 20500A1FB; Thu, 8 Jan 2004 13:29:44 -0500 (EST) Received: from mail.blazebox.homeip.net ([127.0.0.1]) by localhost (blazebox.homeip.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36063-04-2; Thu, 8 Jan 2004 13:29:42 -0500 (EST) Received: from blaze.homeip.net (blaze [192.168.0.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.blazebox.homeip.net (Postfix) with ESMTP id BEE66A1F7; Thu, 8 Jan 2004 13:29:42 -0500 (EST) Received: (from diffie@localhost) by blaze.homeip.net (8.12.10/8.12.10/Submit) id i08IUAe5001608; Thu, 8 Jan 2004 13:30:10 -0500 X-Authentication-Warning: blaze.homeip.net: diffie set sender to paulb@blazebox.homeip.net using -f Subject: Re: state of XFS capable linux installers From: Paul Blazejowski To: Arthur Corliss Cc: Scott Fagg , XFS List In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ezViZSyesYHL+JdafQmk" Message-Id: <1073586610.1579.3.camel@blaze.homeip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (Slackware Linux) Date: Thu, 08 Jan 2004 13:30:10 -0500 X-Virus-Scanned: by amavisd-new at blazebox.homeip.net X-archive-position: 1659 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: paulb@blazebox.homeip.net Precedence: bulk X-list: linux-xfs Content-Length: 1814 Lines: 59 --=-ezViZSyesYHL+JdafQmk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-01-08 at 10:18, Arthur Corliss wrote: > On Thu, 8 Jan 2004, Scott Fagg wrote: >=20 > > > > When i said 'linux' i was referring to linux distros in general, i wasn= 't trying to equate redhat to linux, it just so happens that i use redhat. > > > > Looks like FC2 is the closest answer, for now .. time to contribute. > > > > I have the problem that my redhat linux ;) box has XFS filesystems on a= ll partitions, thanks to the SGI supplied RH7.3 installer. Now that i want = to upgrade, i'm caught. I was hoping i could do some tricks by installing s= tuff to the 1GB swap partition, recompiling kernels and so on, but could ne= ver come up with a working process. >=20 > The last Slack I used (8.1) wasn't clued-in enough to provide a SCSI+XFS > kernel, so I would install a mini-root type system with a compiler and ke= rnel > source into the swap partition, recompile the kernel, reboot, and migrate= back > onto the old FS (or create new ones). If you have the RAM that should wo= rk > nicely. >=20 > --Arthur Corliss > Bolverk's Lair -- http://arthur.corlissfamily.org/ > Digital Mages -- http://www.digitalmages.com/ > "Live Free or Die, the Only Way to Live" -- NH State Motto >=20 >=20 >=20 FYI, Latest Slackware Linux (9.1) supports booting from SCSI devivces and installing on XFS enabled partitions. Regards, Paul --=-ezViZSyesYHL+JdafQmk 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//aGyv0+bfGBjm98RAoKwAJ4uapMzTPFp6UIqjgqZTpi1E7B7vgCfQVFj 8/JvIs5zesE60u15MZx646E= =4eKT -----END PGP SIGNATURE----- --=-ezViZSyesYHL+JdafQmk-- From owner-linux-xfs@oss.sgi.com Thu Jan 8 11:14:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Jan 2004 11:15:17 -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 i08JEtTa020868 for ; Thu, 8 Jan 2004 11:14:55 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i08JEtLh020867 for linux-xfs@oss.sgi.com; Thu, 8 Jan 2004 11:14:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i08JErTc020851 for ; Thu, 8 Jan 2004 11:14:53 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i08IU9XV018438; Thu, 8 Jan 2004 10:30:09 -0800 Date: Thu, 8 Jan 2004 10:30:09 -0800 Message-Id: <200401081830.i08IU9XV018438@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: 1660 X-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: 389 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=294 ------- Additional Comments From sandeen@sgi.com 2004-08-01 10:30 PDT ------- On a debug kernel the dilocate messages are harmless, fsstress is asking for stuff at random, the kernel is saying that it's not there. ------- 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 Jan 8 12:50:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Jan 2004 12:50:39 -0800 (PST) Received: from ura.dnsalias.org (rdu74-148-233.nc.rr.com [24.74.148.233]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08KoJTa026035 for ; Thu, 8 Jan 2004 12:50:26 -0800 Received: from ken-ohki (bi01p1.nc.us.ibm.com [129.33.49.251]) by ura.dnsalias.org (Postfix) with ESMTP id 178358CB0 for ; Thu, 8 Jan 2004 15:49:51 -0500 (EST) Date: Thu, 8 Jan 2004 15:49:40 -0500 From: Jarrod Johnson To: linux-xfs@oss.sgi.com Subject: Strange df output Message-Id: <20040108154940.7dd28591.jbj-ksylph@ken-ohki> X-Mailer: Sylpheed version 0.9.4 (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: 1661 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jbj-ksylph@ura.dnsalias.org Precedence: bulk X-list: linux-xfs Content-Length: 1228 Lines: 23 I'm running xfs on a software raid5 array, the kernel version is: SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with ACLs, no debug enabled And here is a taste of what I'm seeing: df -k .: Filesystem 1K-blocks Used Available Use% Mounted on /dev/md0 360138240 356276448 3861792 99% /storage dd if=/dev/zero of=tst bs=1000000 count=300 df -k .: Filesystem 1K-blocks Used Available Use% Mounted on /dev/md0 360138240 356327136 3811104 99% /storage rm -f tst: Filesystem 1K-blocks Used Available Use% Mounted on /dev/md0 360138240 355983080 4155160 99% /storage So I had some space free, making a 300,000,000 byte file only consumed about 5,000k, and then deleting it freed up more space than I had to start with? This is consistantly occuring. A week or so back, it inexplicably went from ~2GB free to full instantaneously. I didn't believe the person was keeping good track of it and just filled it up, so I did this a few times and if this is happening, I now believe that what the person said is true. Why is the free space not decreasing on creation of new files, yet increasing on deletion? Please CC me as I'm not subscribed. From owner-linux-xfs@oss.sgi.com Thu Jan 8 13:04:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Jan 2004 13:05: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 i08L4sTa026793 for ; Thu, 8 Jan 2004 13:04:54 -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 i08JDqOO026250 for ; Thu, 8 Jan 2004 11:13: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 i08L4lp928254625; Thu, 8 Jan 2004 15:04: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 i08L4lK113283251; Thu, 8 Jan 2004 15:04:47 -0600 (CST) Subject: Re: Strange df output From: Eric Sandeen To: Jarrod Johnson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040108154940.7dd28591.jbj-ksylph@ken-ohki> References: <20040108154940.7dd28591.jbj-ksylph@ken-ohki> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1073595887.27384.260.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 08 Jan 2004 15:04:47 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1662 X-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: 1673 Lines: 36 Any chance you can give us a reproducible way (from mkfs) to demonstrate the problem? You could be seeing some effects of preallocated space being freed (esp. as the fs fills up), other than that I'm not certain yet. -Eric On Thu, 2004-01-08 at 14:49, Jarrod Johnson wrote: > I'm running xfs on a software raid5 array, the kernel version is: > SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with ACLs, no debug enabled > > And here is a taste of what I'm seeing: > df -k .: > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/md0 360138240 356276448 3861792 99% /storage > dd if=/dev/zero of=tst bs=1000000 count=300 > df -k .: > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/md0 360138240 356327136 3811104 99% /storage > rm -f tst: > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/md0 360138240 355983080 4155160 99% /storage > > So I had some space free, making a 300,000,000 byte file only consumed about 5,000k, and then deleting it freed up more space than I had to start with? > > This is consistantly occuring. A week or so back, it inexplicably went from ~2GB free to full instantaneously. I didn't believe the person was keeping good track of it and just filled it up, so I did this a few times and if this is happening, I now believe that what the person said is true. > > Why is the free space not decreasing on creation of new files, yet increasing on deletion? > > Please CC me as I'm not subscribed. -- 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 Jan 8 13:46:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Jan 2004 13:47:05 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.177.98]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LkrTa029829 for ; Thu, 8 Jan 2004 13:46:53 -0800 Received: from mail.pacrimopen.com (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id 56FC87000D59; Thu, 8 Jan 2004 13:48:02 -0800 (PST) Received: from UNKNOWN(127.0.0.1), claiming to be "mail.pacrimopen.com" via SMTP by sa-relay.pacrimopen.com, id smtpd2Kiho1; Thu Jan 8 13:47:50 2004 Received: from bubbles.imr-net.com (unknown [12.111.175.170]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id A19597000D59; Thu, 8 Jan 2004 13:47:49 -0800 (PST) Subject: Re: Strange df output From: Joshua Schmidlkofer To: Eric Sandeen Cc: Jarrod Johnson , linux-xfs@oss.sgi.com In-Reply-To: <1073595887.27384.260.camel@stout.americas.sgi.com> References: <20040108154940.7dd28591.jbj-ksylph@ken-ohki> <1073595887.27384.260.camel@stout.americas.sgi.com> Content-Type: text/plain Message-Id: <1073598397.18902.7.camel@bubbles.imr-net.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 08 Jan 2004 13:46:37 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 1663 X-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: 490 Lines: 15 [Nvidia + 2.6.1-rc1-mm2 + XFS] I saw a similar case recently. [But no proveable metrics] I deleted about 10 gig of files from my NWN Saves directory. When I df'd afterwards, I had gone from 5GB free to 33GB free. I did not think to report it, I just thought that I made a mistake. But after this report, I thought I should mention it. I had tons of hard links, with like 5 directories, from various patch versions, and a lot of links were released. I don't have an explaination. js From owner-linux-xfs@oss.sgi.com Thu Jan 8 14:07:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Jan 2004 14:08:07 -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 i08M7sTa002463 for ; Thu, 8 Jan 2004 14:07:54 -0800 Message-ID: <3FFDD450.6070804@adic.com> Date: Thu, 08 Jan 2004 16:06:08 -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: Joshua Schmidlkofer CC: Eric Sandeen , Jarrod Johnson , linux-xfs@oss.sgi.com Subject: Re: Strange df output References: <20040108154940.7dd28591.jbj-ksylph@adic.com> <1073595887.27384.260.camel@stout.americas.sgi.com> <1073598397.18902.7.camel@bubbles.imr-net.com> In-Reply-To: <1073598397.18902.7.camel@adic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1664 X-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 Content-Length: 1595 Lines: 53 Joshua Schmidlkofer wrote: >[Nvidia + 2.6.1-rc1-mm2 + XFS] > >I saw a similar case recently. [But no proveable metrics] I deleted >about 10 gig of files from my NWN Saves directory. When I df'd >afterwards, I had gone from 5GB free to 33GB free. > >I did not think to report it, I just thought that I made a mistake. But >after this report, I thought I should mention it. >I had tons of hard links, with like 5 directories, from various patch >versions, and a lot of links were released. I don't have an >explaination. > >js > > > > This could all be related to delayed allocation. During write system calls xfs does not actually allocate real disk blocks, it reserves all the potential blocks needed from the superblock counters. This is reflected in the df output. The potential blocks needed is a worst case estimate, all the space needed for the data, plus the worst case estimate of the metadata needed to point at it, which is when xfs ends up using a seperate extent for each block in the file. When the data is actually flushed out to disk, all the prereserved space which was not actually used it put back into the super block counters. When the filesystem is nearly full, a space allocation from write can fail, it attempts reclaim space by flushing out delayed allocate data. So writing a 300M file probably did consume 300M, but the space was reclaimed by flushing other delayed allocate data. No guarantees that this is what is happening, but it should go some way to explaining fluctuations in the free space on a near full filesystem. Steve -- Steve Lord From owner-linux-xfs@oss.sgi.com Thu Jan 8 14:41:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Jan 2004 14:41:56 -0800 (PST) Received: from chipsworld.llamas.net (chipsworld.llamas.net [216.76.43.190]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08MfiTa004428 for ; Thu, 8 Jan 2004 14:41:45 -0800 Received: from localhost (localhost [127.0.0.1]) by chipsworld.llamas.net (Postfix) with ESMTP id C94A444DFF5; Thu, 8 Jan 2004 17:41:36 -0500 (EST) Received: from chipsworld.llamas.net ([127.0.0.1]) by localhost (chipsworld.llamas.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13007-08; Thu, 8 Jan 2004 17:41:35 -0500 (EST) Received: by chipsworld.llamas.net (Postfix, from userid 501) id 7BE6444E58B; Thu, 8 Jan 2004 17:38:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by chipsworld.llamas.net (Postfix) with ESMTP id 6A382C07980; Thu, 8 Jan 2004 17:38:43 -0500 (EST) Date: Thu, 8 Jan 2004 17:38:43 -0500 (EST) From: "Chris 'Chipper' Chiapusio" To: Scott Fagg Cc: linux-xfs@oss.sgi.com Subject: Re: state of XFS capable linux installers In-Reply-To: Message-ID: X-Files: Resist or serve MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at llamas.net X-archive-position: 1665 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: chipper@llamas.net Precedence: bulk X-list: linux-xfs Content-Length: 1651 Lines: 36 On Thu, 8 Jan 2004, Scott Fagg wrote: > >When i said 'linux' i was referring to linux distros in general, i wasn't trying to equate redhat to linux, it just so happens that i use redhat. > >Looks like FC2 is the closest answer, for now .. time to contribute. > >I have the problem that my redhat linux ;) box has XFS filesystems on all partitions, thanks to the SGI supplied RH7.3 installer. Now that i want to upgrade, i'm caught. I was hoping i could do some tricks by installing stuff to the 1GB swap partition, recompiling kernels and so on, but could never come up with a working process. > >Scott Fagg >Arup Brisbane >(07) 3023 6000 > When I recently rebuilt my server, I wanted to install redhat 9, however the installer would hang on my RAID adapter during install. I eventually tried my redhat 8.0 XFS installer disks and got it installed. While waiting on the install, I surfed around a bit and found yum. Since that discovery I have upgraded one RH8-XFS system to RH9-XFS, one from RH8-XFS to FC1, and another from RH9 to Fedora. For desktop systems you may want the intelligence of an installer so that you are offered the new options on your next login, but for servers your don't have to be concerned so much. You can find software, documentation, and yum archives here: http://linux.duke.edu/projects/yum/ Chipper ------ Please encrypt anything important. PGP Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x6CFA486D "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety " - Benjamin Franklin From owner-linux-xfs@oss.sgi.com Thu Jan 8 23:34:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Jan 2004 23:34:53 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.177.98]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i097YTTa024149 for ; Thu, 8 Jan 2004 23:34:29 -0800 Received: from mail.pacrimopen.com (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id A06287000D59; Thu, 8 Jan 2004 23:35:41 -0800 (PST) Received: from UNKNOWN(127.0.0.1), claiming to be "mail.pacrimopen.com" via SMTP by sa-relay.pacrimopen.com, id smtpdBwvSzm; Thu Jan 8 23:35:29 2004 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 AB9037000D59; Thu, 8 Jan 2004 23:35:28 -0800 (PST) Subject: Re: Strange df output From: "Joshua M. Schmidlkofer" To: Steve Lord Cc: Eric Sandeen , Jarrod Johnson , linux-xfs@oss.sgi.com In-Reply-To: <3FFDD450.6070804@adic.com> References: <20040108154940.7dd28591.jbj-ksylph@adic.com> <1073595887.27384.260.camel@stout.americas.sgi.com> <1073598397.18902.7.camel@bubbles.imr-net.com> <3FFDD450.6070804@adic.com> Content-Type: text/plain Message-Id: <1073633655.30586.1.camel@menion.home> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 08 Jan 2004 23:34:15 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 1666 X-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: 1899 Lines: 59 On Thu, 2004-01-08 at 14:06, Steve Lord wrote: > Joshua Schmidlkofer wrote: > > >[Nvidia + 2.6.1-rc1-mm2 + XFS] > > > >I saw a similar case recently. [But no proveable metrics] I deleted > >about 10 gig of files from my NWN Saves directory. When I df'd > >afterwards, I had gone from 5GB free to 33GB free. > > > >I did not think to report it, I just thought that I made a mistake. But > >after this report, I thought I should mention it. > >I had tons of hard links, with like 5 directories, from various patch > >versions, and a lot of links were released. I don't have an > >explaination. > > > >js > > > > > > > > > > This could all be related to delayed allocation. During write system > calls xfs does > not actually allocate real disk blocks, it reserves all the potential > blocks needed from > the superblock counters. This is reflected in the df output. The > potential blocks > needed is a worst case estimate, all the space needed for the data, plus > the worst > case estimate of the metadata needed to point at it, which is when xfs > ends up > using a seperate extent for each block in the file. When the data is > actually flushed > out to disk, all the prereserved space which was not actually used it > put back into > the super block counters. > > When the filesystem is nearly full, a space allocation from write can > fail, it attempts > reclaim space by flushing out delayed allocate data. So writing a 300M > file probably > did consume 300M, but the space was reclaimed by flushing other delayed > allocate > data. > > No guarantees that this is what is happening, but it should go some way > to explaining > fluctuations in the free space on a near full filesystem. Just FYI - these files accumulated over the course of about 10 months, then two days ago, for the first time, I pruned. I will watch for this in the future and see what I get. js From owner-linux-xfs@oss.sgi.com Fri Jan 9 05:22:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Jan 2004 05:22:14 -0800 (PST) Received: from smtp1.clear.net.nz (smtp1.clear.net.nz [203.97.33.27]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09DM1Ta013767 for ; Fri, 9 Jan 2004 05:22:02 -0800 Received: from 218-101-109-185.dialup.clear.net.nz (218-101-109-185.dialup.clear.net.nz [218.101.109.185]) by smtp1.clear.net.nz (CLEAR Net Mail) with ESMTP id <0HR7003K4EUWPQ@smtp1.clear.net.nz> for linux-xfs@oss.sgi.com; Fri, 09 Jan 2004 16:54:36 +1300 (NZDT) Date: Fri, 09 Jan 2004 16:55:09 +1300 From: Nigel Cunningham Subject: Swapfiles broken on XFS. To: XFS list Cc: Karol Kozimor , swsusp-devel Reply-to: ncunningham@users.sourceforge.net Message-id: <1073620506.3790.21.camel@laptop-linux> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.4-8mdk Content-type: multipart/signed; boundary="=-tPhdlAbPHWbh7Mtfs0jx"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-archive-position: 1667 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ncunningham@users.sourceforge.net Precedence: bulk X-list: linux-xfs Content-Length: 1302 Lines: 42 --=-tPhdlAbPHWbh7Mtfs0jx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi. It appears to me that a swapfile on an XFS filesystem will not work, at least some of the time. mm/page_io:722 uses swapf->i_sb->s_blocksize to determine the number of blocks required to store a page. This method is also in Software Suspend's swapfile support. Karol emailed me yesterday saying swapfile support in Suspend seemed to be broken, and I've tracked it down to the fact that (at least on a test 192MB XFS partition with a 98MB swapfile on it), s_blocksize is set to 4096 while the blocksize actually appears to be 512. The means Suspend only gets 12.5% of the way through writing the image before finding it has run out of space. I don't know how the system would cope with the descrepancy. Kernel is 2.4.25-pre4 by the way. Regards, Nigel --=20 My work on Software Suspend is graciously brought to you by LinuxFund.org. --=-tPhdlAbPHWbh7Mtfs0jx 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//iYaVfpQGcyBBWkRAjIXAJ9wjiJ0tcaOGOkVfjI+36l9eCHHyQCdF6rE GAYj4EFpB87riKfoRuTxxNE= =ACkj -----END PGP SIGNATURE----- --=-tPhdlAbPHWbh7Mtfs0jx-- From owner-linux-xfs@oss.sgi.com Fri Jan 9 08:01:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Jan 2004 08:01:57 -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 i09G1PTa023612 for ; Fri, 9 Jan 2004 08:01:26 -0800 Received: (qmail 24777 invoked by uid 777); 9 Jan 2004 16:01:28 -0000 Date: Fri, 9 Jan 2004 17:01:28 +0100 From: Karol Kozimor To: Nigel Cunningham Cc: XFS list , swsusp-devel Subject: Re: Swapfiles broken on XFS. Message-ID: <20040109160128.GA9467@hell.org.pl> Mail-Followup-To: Nigel Cunningham , XFS list , swsusp-devel References: <1073620506.3790.21.camel@laptop-linux> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <1073620506.3790.21.camel@laptop-linux> User-Agent: Mutt/1.4.1i X-archive-position: 1668 X-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: 1057 Lines: 22 Thus wrote Nigel Cunningham: > mm/page_io:722 uses swapf->i_sb->s_blocksize to determine the number of > blocks required to store a page. This method is also in Software > Suspend's swapfile support. Karol emailed me yesterday saying swapfile > support in Suspend seemed to be broken, and I've tracked it down to the > fact that (at least on a test 192MB XFS partition with a 98MB swapfile > on it), s_blocksize is set to 4096 while the blocksize actually appears > to be 512. The means Suspend only gets 12.5% of the way through writing > the image before finding it has run out of space. I don't know how the > system would cope with the descrepancy. I seem to have the answer now: Bad Things^TM. Actually, the test partition I set up for that ended up corrupted beyond mounting (superblock was probably overwritten). Running xfs_repair helped a bit (the whole kernel tree landed in lost+found and the directory structure was shattered, but the files themselves did not show any corruption). Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Fri Jan 9 08:16:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Jan 2004 08:17:19 -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 i09GGvTa024443 for ; Fri, 9 Jan 2004 08:16:58 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AezJe-0006jb-1j; Fri, 09 Jan 2004 16:16:54 +0000 Date: Fri, 9 Jan 2004 16:16:53 +0000 From: Christoph Hellwig To: Nigel Cunningham Cc: XFS list , Karol Kozimor , swsusp-devel Subject: Re: Swapfiles broken on XFS. Message-ID: <20040109161653.A25678@infradead.org> References: <1073620506.3790.21.camel@laptop-linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1073620506.3790.21.camel@laptop-linux>; from ncunningham@users.sourceforge.net on Fri, Jan 09, 2004 at 04:55:09PM +1300 X-archive-position: 1669 X-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: 511 Lines: 12 On Fri, Jan 09, 2004 at 04:55:09PM +1300, Nigel Cunningham wrote: > It appears to me that a swapfile on an XFS filesystem will not work, at > least some of the time. XFS sets s_blocksize to the filesystem blocksize and bdev->bd_block_size / i_blkbits to the XFS sector size. The first would be 4096 in your case and the latter 512. We cannot set a bigger device block size because XFS log writes are in 512b units. I don't think the swap code should do any assumptions about any relation of the above two. From owner-linux-xfs@oss.sgi.com Fri Jan 9 10:14:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Jan 2004 10:14:59 -0800 (PST) Received: from smtp1.clear.net.nz (smtp1.clear.net.nz [203.97.33.27]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09IEiTa030859 for ; Fri, 9 Jan 2004 10:14:46 -0800 Received: from 218-101-109-90.dialup.clear.net.nz (218-101-109-90.dialup.clear.net.nz [218.101.109.90]) by smtp1.clear.net.nz (CLEAR Net Mail) with ESMTP id <0HR8009RGIMTRE@smtp1.clear.net.nz> for linux-xfs@oss.sgi.com; Sat, 10 Jan 2004 07:13:43 +1300 (NZDT) Date: Sat, 10 Jan 2004 07:06:26 +1300 From: Nigel Cunningham Subject: Re: [Swsusp-devel] Re: Swapfiles broken on XFS. In-reply-to: <20040109161653.A25678@infradead.org> To: Christoph Hellwig Cc: XFS list , Karol Kozimor , swsusp-devel Reply-to: ncunningham@users.sourceforge.net Message-id: <1073671586.2069.6.camel@laptop-linux> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.4-8mdk Content-type: multipart/signed; boundary="=-l1g34x12GP7Upc8XkA5G"; protocol="application/pgp-signature"; micalg=pgp-sha1 References: <1073620506.3790.21.camel@laptop-linux> <20040109161653.A25678@infradead.org> X-archive-position: 1670 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ncunningham@users.sourceforge.net Precedence: bulk X-list: linux-xfs Content-Length: 1930 Lines: 57 --=-l1g34x12GP7Upc8XkA5G Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi. Do you know what other filesystems do (haven't had a chance to look for myself yet)? I guess they're using s_blocksize =3D=3D bdev->bd_block_size/i_blkbits, since we haven't seen this issue before. If that's the case, the solution would be to switch what we look at, yes? Regards, Nigel On Sat, 2004-01-10 at 05:16, Christoph Hellwig wrote: > On Fri, Jan 09, 2004 at 04:55:09PM +1300, Nigel Cunningham wrote: > > It appears to me that a swapfile on an XFS filesystem will not work, at > > least some of the time. >=20 > XFS sets s_blocksize to the filesystem blocksize and bdev->bd_block_size / > i_blkbits to the XFS sector size. The first would be 4096 in your > case and the latter 512. We cannot set a bigger device block size because > XFS log writes are in 512b units. >=20 > I don't think the swap code should do any assumptions about any relation > of the above two. >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > swsusp-devel mailing list > swsusp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/swsusp-devel --=20 My work on Software Suspend is graciously brought to you by LinuxFund.org. --=-l1g34x12GP7Upc8XkA5G 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//u2iVfpQGcyBBWkRAs66AJ4tqpa8Nn7Q+7cFoplDnCtXmE8oKgCghPT/ /tvyvicMUmGftvKu/8Mri3A= =HxSx -----END PGP SIGNATURE----- --=-l1g34x12GP7Upc8XkA5G-- From owner-linux-xfs@oss.sgi.com Fri Jan 9 12:23:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Jan 2004 12:23:50 -0800 (PST) Received: from smtp2.clear.net.nz (smtp2.clear.net.nz [203.97.37.27]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09KNZTa004218 for ; Fri, 9 Jan 2004 12:23:36 -0800 Received: from 218-101-109-142.dialup.clear.net.nz (218-101-109-142.dialup.clear.net.nz [218.101.109.142]) by smtp2.clear.net.nz (CLEAR Net Mail) with ESMTP id <0HR800LSZOIHQW@smtp2.clear.net.nz> for linux-xfs@oss.sgi.com; Sat, 10 Jan 2004 09:20:43 +1300 (NZDT) Date: Sat, 10 Jan 2004 09:13:26 +1300 From: Nigel Cunningham Subject: Re: Swapfiles broken on XFS. In-reply-to: <20040109161653.A25678@infradead.org> To: Christoph Hellwig Cc: XFS list , Karol Kozimor , swsusp-devel , Linux Kernel Mailing List Reply-to: ncunningham@users.sourceforge.net Message-id: <1073679200.4566.12.camel@laptop-linux> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.4-8mdk Content-type: multipart/signed; boundary="=-hbcWiGCHEkJ2xqd0E6Qb"; protocol="application/pgp-signature"; micalg=pgp-sha1 References: <1073620506.3790.21.camel@laptop-linux> <20040109161653.A25678@infradead.org> X-archive-position: 1671 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ncunningham@users.sourceforge.net Precedence: bulk X-list: linux-xfs Content-Length: 1668 Lines: 50 --=-hbcWiGCHEkJ2xqd0E6Qb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi again. Perhaps I wasn't clear enough. Both the page_io and Suspend can cope fine with block size < 4096. The issue is where they get the information from as to how many blocks per page they actually need to use when called brw_page. At the moment, they both assume that i_sb->s_blocksize and blocksize_bits is the place to go. What you're saying sounds right to me. They should both be looking at i_blkbits and i_blksize in the struct inode, shouldn't they? I'll make the change, test and submit a patch to LKML. Regards, Nigel On Sat, 2004-01-10 at 05:16, Christoph Hellwig wrote: > On Fri, Jan 09, 2004 at 04:55:09PM +1300, Nigel Cunningham wrote: > > It appears to me that a swapfile on an XFS filesystem will not work, at > > least some of the time. >=20 > XFS sets s_blocksize to the filesystem blocksize and bdev->bd_block_size / > i_blkbits to the XFS sector size. The first would be 4096 in your > case and the latter 512. We cannot set a bigger device block size because > XFS log writes are in 512b units. >=20 > I don't think the swap code should do any assumptions about any relation > of the above two. --=20 My work on Software Suspend is graciously brought to you by LinuxFund.org. --=-hbcWiGCHEkJ2xqd0E6Qb 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//wtgVfpQGcyBBWkRAsK0AJ0ebwIEEwf+QTFAPDaWyGtx2u7vjACfe9Ig RTgyvsbeNrE0YgY8PFnlhuY= =bn0s -----END PGP SIGNATURE----- --=-hbcWiGCHEkJ2xqd0E6Qb-- From owner-linux-xfs@oss.sgi.com Fri Jan 9 14:09:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Jan 2004 14:09:37 -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 i09M9ETa006771 for ; Fri, 9 Jan 2004 14:09:15 -0800 Received: from Unknown [172.20.0.8] by tempgw.ciprico.com - SurfControl E-mail Filter (4.7); Fri, 09 Jan 2004 16:11:20 -0600 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Jan 2004 16:09:06 -0600 Message-ID: From: Gustavo Rincon To: "'linux-xfs@oss.sgi.com'" Cc: Tony Lambert Date: Fri, 9 Jan 2004 16:09:00 -0600 Subject: xfs_check: out of memory error MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 1672 X-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: 403 Lines: 12 Hi guys, I'm trying to use xfs_check on my xfs filesystem (kernel-2.4.24 with LBD support enable and the filesytem size is > 2Terabytes) and the xfs_check (xfsprogs-2.6.0 version ) returns out of memory error during execution. Checking in the man page of xfs_check, it said that xfs_check64 has to be used. My question is how to compile or get the xfs_check64 for linux? Thank you Gustavo Rincon From owner-linux-xfs@oss.sgi.com Fri Jan 9 14:13:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Jan 2004 14:13:30 -0800 (PST) Received: from smtp1.clear.net.nz (smtp1.clear.net.nz [203.97.33.27]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09MDHTa007284 for ; Fri, 9 Jan 2004 14:13:18 -0800 Received: from 218-101-109-10.dialup.clear.net.nz (218-101-109-10.dialup.clear.net.nz [218.101.109.10]) by smtp1.clear.net.nz (CLEAR Net Mail) with ESMTP id <0HR800KD4SLO78@smtp1.clear.net.nz> for linux-xfs@oss.sgi.com; Sat, 10 Jan 2004 10:49:03 +1300 (NZDT) Date: Sat, 10 Jan 2004 10:41:45 +1300 From: Nigel Cunningham Subject: Re: Swapfiles broken on XFS. In-reply-to: <1073679200.4566.12.camel@laptop-linux> To: Christoph Hellwig Cc: XFS list , Karol Kozimor , swsusp-devel , Linux Kernel Mailing List Reply-to: ncunningham@users.sourceforge.net Message-id: <1073684450.4596.55.camel@laptop-linux> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.4-8mdk Content-type: multipart/signed; boundary="=-ePjdu5KETZ8GaqY+6/RR"; protocol="application/pgp-signature"; micalg=pgp-sha1 References: <1073620506.3790.21.camel@laptop-linux> <20040109161653.A25678@infradead.org> <1073679200.4566.12.camel@laptop-linux> X-archive-position: 1673 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ncunningham@users.sourceforge.net Precedence: bulk X-list: linux-xfs Content-Length: 2035 Lines: 65 --=-ePjdu5KETZ8GaqY+6/RR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi. Actually, i_sb->s_blocksize and blocksize_bits both reflect a block size of 4096 too, so that didn't help. What does help is using blksize_size. I'll prepare a patch for Karol and I to try before submitting it to LKML. Regards, Nigel On Sat, 2004-01-10 at 22:13, Nigel Cunningham wrote: > Hi again. >=20 > Perhaps I wasn't clear enough. >=20 > Both the page_io and Suspend can cope fine with block size < 4096. The > issue is where they get the information from as to how many blocks per > page they actually need to use when called brw_page. At the moment, they > both assume that i_sb->s_blocksize and blocksize_bits is the place to > go. What you're saying sounds right to me. They should both be looking > at i_blkbits and i_blksize in the struct inode, shouldn't they? I'll > make the change, test and submit a patch to LKML. >=20 > Regards, >=20 > Nigel >=20 > On Sat, 2004-01-10 at 05:16, Christoph Hellwig wrote: > > On Fri, Jan 09, 2004 at 04:55:09PM +1300, Nigel Cunningham wrote: > > > It appears to me that a swapfile on an XFS filesystem will not work, = at > > > least some of the time. > >=20 > > XFS sets s_blocksize to the filesystem blocksize and bdev->bd_block_siz= e / > > i_blkbits to the XFS sector size. The first would be 4096 in your > > case and the latter 512. We cannot set a bigger device block size beca= use > > XFS log writes are in 512b units. > >=20 > > I don't think the swap code should do any assumptions about any relation > > of the above two. --=20 My work on Software Suspend is graciously brought to you by LinuxFund.org. --=-ePjdu5KETZ8GaqY+6/RR 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//x/iVfpQGcyBBWkRAvsqAJ98kigsmKa9XAYxFrvUzX41X4zZLACbBfYv qWLLsa4UOb7PVuCLqYu03xc= =ePrR -----END PGP SIGNATURE----- --=-ePjdu5KETZ8GaqY+6/RR-- From owner-linux-xfs@oss.sgi.com Fri Jan 9 14:15:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Jan 2004 14:16: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 i09MFuTa007754 for ; Fri, 9 Jan 2004 14:15:56 -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 i09NYnr3000856 for ; Fri, 9 Jan 2004 17:34:49 -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 i09MFnh328527640 for ; Fri, 9 Jan 2004 16:15:50 -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 i09MFnoZ3365735 for ; Fri, 9 Jan 2004 16:15:49 -0600 (CST) Subject: [Annoncement] New CVS trees now on OSS From: Russell Cattelan To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-RBcJ7Sa2rTEkXg9UNmjX" Message-Id: <1073686549.28391.47.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-2mdk Date: Fri, 09 Jan 2004 16:15:50 -0600 X-archive-position: 1674 X-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: 1405 Lines: 47 --=-RBcJ7Sa2rTEkXg9UNmjX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Just a heads up for everybody keeping uptodate with xfs via cvs. The cvs trees have been updated with the latest bits from our new internal trees. We have decided to combine the 2.4 and 2.6 xfs bits into one tree in an effort to reduce the amount of time we spend merging code around, the trees on oss.sgi.com now reflect this merge. http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/ The supporting linux trees have also been re-imported from=20 from the latest 2.4 and 2.6 bits in order to reduce the amount of baggage being carried around in those trees. The old trees will remain online: http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs-OLD/ http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs-OLD/ For anybody needing to do software archeology. Things may check out correctly via cvs update, but if it doesn't please just check out a new tree from scratch before telling us things are broken. -Russell Cattelan Digital Elves Inc --=-RBcJ7Sa2rTEkXg9UNmjX 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//ygVNRmM+OaGhBgRAvMPAJ41XK6Y85r6G2mdnyOz54nfmzFqSgCdHST9 YRj2m61OXs/XvezoXGUQMSs= =W6wr -----END PGP SIGNATURE----- --=-RBcJ7Sa2rTEkXg9UNmjX-- From owner-linux-xfs@oss.sgi.com Sat Jan 10 00:53:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 10 Jan 2004 00:54:27 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0A8rlTa031929 for ; Sat, 10 Jan 2004 00:53:48 -0800 Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AfEr6-00035d-00; Sat, 10 Jan 2004 09:52:28 +0100 Received: from [80.129.69.37] (helo=krienke.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AfEr6-0004UN-00; Sat, 10 Jan 2004 09:52:28 +0100 Received: from 192.168.10.4 (ident=unknown) by krienke.org with esmtp (masqmail 0.2.18) id 1AfEqb-1Ii-00; Sat, 10 Jan 2004 09:51:57 +0100 From: Rainer Krienke To: Arthur Corliss , Rainer Krienke Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem Date: Sat, 10 Jan 2004 09:51:45 +0100 User-Agent: KMail/1.5.4 Cc: Eric Sandeen , linux-xfs@oss.sgi.com References: <200401071135.12886.krienke@uni-koblenz.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_o07//pY5eS4KAHM"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401100951.52922.rainer@krienke.org> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:bc73c4e44fefa2230c0ea7a2ec38b3fe X-archive-position: 1675 X-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@krienke.org Precedence: bulk X-list: linux-xfs Content-Length: 1791 Lines: 50 --Boundary-02=_o07//pY5eS4KAHM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline Am Mittwoch, 7. Januar 2004 16:42 schrieb Arthur Corliss: > On Wed, 7 Jan 2004, Rainer Krienke wrote: > > In between I contacted the vendor of the hardware IDE raids. The > > technician confirmed that these raids have a read/write cache and that > > there is *no* battery backup. So in case of an active filesystem where > > suddenly there is a powerfail, it is likely that the hardware cache in > > the raid is not written to disk and the filesystem will be become > > inconsitent. And this very probably happened in my case. > > > > So the remaining question is only why xfs_repair was unable to repair t= he > > damaged filesystem.... > > If I had to hazard a guess, I'd think that the transaction log, being hit > much more frequently than most other portions of the filesystem, would be > much more aggressively cached by the hardware's algorithms, which would > leave the log that much more inconsistent than the filesystem. *That* > can't help during repairs. . . > > In any event, it sounds like you need a UPS on that system now, eh? In between we found another possibility. Our vendor told us that now there = is=20 a firmware upgrade that allows the write cache to be disabled. So we are=20 probably going to do this, to get rid of this problem.=20 Thanks Rainer --Boundary-02=_o07//pY5eS4KAHM Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA//70oaldtjc/KDEoRAoHOAKCiOMG9NDzH3UVdBIytxgumkvQC9gCZAWSJ CxMqXbA1M2u3Ac4i5zHIk/8= =K6s+ -----END PGP SIGNATURE----- --Boundary-02=_o07//pY5eS4KAHM-- From owner-linux-xfs@oss.sgi.com Sat Jan 10 01:16:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 10 Jan 2004 01:16:52 -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 i0A9GKTa000305 for ; Sat, 10 Jan 2004 01:16:21 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.8) with ESMTP id i0A9GIYu001224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Jan 2004 10:16:19 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i0A9G6RQ009775; Sat, 10 Jan 2004 10:16:06 +0100 Date: Sat, 10 Jan 2004 10:16:06 +0100 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: Re: ATrpms has updated RH + XFS 1.3 RPMs Message-ID: <20040110091606.GB9381@neu.nirvana> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H1spWtNR+x+ondvy" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 1676 X-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: 775 Lines: 30 --H1spWtNR+x+ondvy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, ATrpms' kernels have been synced to Red Hat's base version. All further supporting kernel module rpms (kmdls) have also been rebuilt (like lm_sensors/nvidia/etc.). Note that there have been *two* almost subsequent Red Hat updated to Fedora Core 1 kernel. The one tagged 2140 is the one you want. --=20 Axel.Thimm@physik.fu-berlin.de --H1spWtNR+x+ondvy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQE//8LWQBVS1GOamfERArH+AJsExKnmd7KOrQX+twApNEzQqkT0/QCcDw9c N/bORbUHWv599pHgJ9Hj2lY= =b+TO -----END PGP SIGNATURE----- --H1spWtNR+x+ondvy-- From owner-linux-xfs@oss.sgi.com Sat Jan 10 01:28:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 10 Jan 2004 01:29:32 -0800 (PST) Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0A9SuTa000993 for ; Sat, 10 Jan 2004 01:28:57 -0800 Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id i0A96m928236 for ; Sat, 10 Jan 2004 01:06:48 -0800 (PST) Received: from user-v7kamtm.dialup.mindspring.com ([207.69.91.182] helo=earthlink.net) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AfEx3-0004r3-00 for linux-xfs@oss.sgi.com; Sat, 10 Jan 2004 00:58:37 -0800 Date: Sat, 10 Jan 2004 03:58:39 -0500 To: linux-xfs@oss.sgi.com Subject: Oops xfs_iget_core on 2.6.1 Message-ID: <20040110085839.GA22527@rushmore> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i From: rwhron@earthlink.net X-archive-position: 1677 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rwhron@earthlink.net Precedence: bulk X-list: linux-xfs Content-Length: 2268 Lines: 70 While running the lsat security check tool from http://usat.sourceforge.net/code/lsat-0.9.0.tgz I got this oops: Unable to handle kernel paging request at virtual address 8e8e8e6e printing eip: c018e7dc *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010282 EIP is at xfs_iget_core+0x48/0x40d eax: 8e8e8e32 ebx: d88924dc ecx: 8e8e8e32 edx: 8e8e8e32 esi: f7f9cad0 edi: 06c04522 ebp: 00000000 esp: cbbbfda4 ds: 007b es: 007b ss: 0068 Process find (pid: 4814, threadinfo=cbbbe000 task=c1c08c80) Stack: c014d2b0 00000000 00000000 8e8e8e32 d88924dc d88924c0 06c04522 00000000 c018ec17 d88924c0 f79b0800 00000000 06c04522 00000000 00000000 cbbbfe68 00000000 00000000 d88924dc 00000000 00000000 00000000 ed6cf7f0 cbbbfe68 Call Trace: [] get_new_inode_fast+0x25/0x96 [] xfs_iget+0x76/0x119 [] xfs_dir_lookup_int+0x57/0xa9 [] xfs_lookup+0x3d/0x65 [] linvfs_lookup+0x3a/0x6e [] real_lookup+0x4e/0xb2 [] do_lookup+0x41/0x72 [] link_path_walk+0x4bb/0x670 [] getname+0x5d/0x96 [] __user_walk+0x23/0x3a [] vfs_lstat+0x14/0x3e [] sys_lstat64+0x10/0x27 [] schedule+0x3f2/0x452 [] default_wake_function+0x0/0x12 [] do_page_fault+0x0/0x451 [] error_code+0x2d/0x38 [] syscall_call+0x7/0xb The first time I ran lsat, there was no oops. I did some chmod -R and chown -R commands to fix a few problems the tool found. On re-running lsat, I got the oops. System is uniprocessor Athlon with IDE drives. ver_linux Linux rushmore 2.6.1 #2 Fri Jan 9 05:32:56 EST 2004 i686 AuthenticAMD unknown GNU/Linux Gnu C 3.3.1 Gnu make 3.80 util-linux 2.12 mount 2.12 module-init-tools 0.9.15-pre4 e2fsprogs 1.34 xfsprogs 2.6.0 PPP 2.4.1 Linux C Library 2.3.2 Dynamic linker (ldd) 2.3.2 Linux C++ Library 5.0.5 Procps 3.1.15 Net-tools 1.60 Kbd 1.08 Sh-utils 5.0 Modules Loaded -- Randy Hron http://home.earthlink.net/~rwhron/kernel/bigbox.html From owner-linux-xfs@oss.sgi.com Sat Jan 10 07:15:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 10 Jan 2004 07:15: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 i0AFF3Ta013969 for ; Sat, 10 Jan 2004 07:15:03 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0AFF3Eq013967 for linux-xfs@oss.sgi.com; Sat, 10 Jan 2004 07:15: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 i0AFF1Tc013952 for ; Sat, 10 Jan 2004 07:15:02 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0AEQoqV013042; Sat, 10 Jan 2004 06:26:50 -0800 Date: Sat, 10 Jan 2004 06:26:50 -0800 Message-Id: <200401101426.i0AEQoqV013042@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: 1678 X-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: 614 Lines: 34 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 ------- Additional Comments From karlran@hotmail.com 2004-10-01 06:26 PDT ------- I've tried: $ autoconf --version Autoconf version 2.13 and $ autoconf --version autoconf (GNU Autoconf) 2.57 with out success. BTW, I'm only running the ./configure script && make $ info autoconf says: > The configuration scripts produced by Autoconf are > independent of Autoconf when they are run, so their > users do not need to have Autoconf. ------- 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 Sat Jan 10 14:19:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 10 Jan 2004 14:19:16 -0800 (PST) Received: from mcfeely.r00td0wn.net (dsl093-212-010.clb1.dsl.speakeasy.net [66.93.212.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0AMIw6H032525 for ; Sat, 10 Jan 2004 14:19:03 -0800 Received: from r00td0wn.net ([172.16.1.222]) by mcfeely.r00td0wn.net with Microsoft SMTPSVC(5.0.2195.5329); Sat, 10 Jan 2004 17:18:49 -0500 Message-ID: <40007A49.4060907@r00td0wn.net> Date: Sat, 10 Jan 2004 17:18:49 -0500 From: Diyab 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: Checking FS type Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2004 22:18:49.0842 (UTC) FILETIME=[B8FAE520:01C3D7C7] X-archive-position: 1679 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: diyab@r00td0wn.net Precedence: bulk X-list: linux-xfs Content-Length: 624 Lines: 15 Hello, I'm working with SELinux and adding XFS attribute / security label support into the API. The problem I'm running into is trying to determine what type of filesystem the file I'm operating on is located on. With ext2/3 the EA attribute name is different from what it will be on an XFS file system so I need to detect the file system type from the file stream I have open. I'm not familiar with how to check the file system type since I've not done this before so does anyone have any suggestions to give me? Any help is really appreciated, thanks! Timothy, Also please CC me because I am not on the list. From owner-linux-xfs@oss.sgi.com Sat Jan 10 20:21:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 10 Jan 2004 20:22:01 -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 i0B4Ln6H015765 for ; Sat, 10 Jan 2004 20:21:49 -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 i0AMrWFL030505 for ; Sat, 10 Jan 2004 14:53:32 -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 i0ANpimL28794108; Sat, 10 Jan 2004 17:51:44 -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 i0ANpiK213403948; Sat, 10 Jan 2004 17:51:44 -0600 (CST) Date: Sat, 10 Jan 2004 17:51:44 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Diyab cc: linux-xfs@oss.sgi.com Subject: Re: Checking FS type In-Reply-To: <40007A49.4060907@r00td0wn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1680 X-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: 955 Lines: 29 From userspace you can use stat(1) "stat -f" and it will tell you the filesystem type; older stats don't know about xfs, so you might need to look for the raw magic number, 0x58465342 ("XFSB") To do it from C, see statfs(2), and use the f_type result. -Eric On Sat, 10 Jan 2004, Diyab wrote: > Hello, > > I'm working with SELinux and adding XFS attribute / security label > support into the API. The problem I'm running into is trying to > determine what type of filesystem the file I'm operating on is located > on. With ext2/3 the EA attribute name is different from what it will be > on an XFS file system so I need to detect the file system type from the > file stream I have open. I'm not familiar with how to check the file > system type since I've not done this before so does anyone have any > suggestions to give me? Any help is really appreciated, thanks! > > Timothy, > > Also please CC me because I am not on the list. > > From owner-linux-xfs@oss.sgi.com Sun Jan 11 00:46:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Jan 2004 00:46:23 -0800 (PST) Received: from mail.frequentous.co.uk (213-152-33-154.dsl.eclipse.net.uk [213.152.33.154]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B8jw6H026239 for ; Sun, 11 Jan 2004 00:46:00 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.frequentous.co.uk (Postfix) with ESMTP id 28D9C29C817 for ; Sun, 11 Jan 2004 08:45:52 +0000 (GMT) Received: from mail.frequentous.co.uk ([127.0.0.1]) by localhost (utahia [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27169-03 for ; Sun, 11 Jan 2004 08:45:45 +0000 (GMT) Received: from arequipa.sweeney.demon.co.uk (unknown [10.0.0.180]) by mail.frequentous.co.uk (Postfix) with SMTP id 9506429C472 for ; Sun, 11 Jan 2004 08:45:45 +0000 (GMT) Date: Sun, 11 Jan 2004 08:50:32 +0000 From: Keith Matthews To: linux-xfs@oss.sgi.com Subject: Re: Checking FS type Message-Id: <20040111085032.70e0667c.keith_m@sweeney.demon.co.uk> In-Reply-To: References: <40007A49.4060907@r00td0wn.net> Organization: Frequentous Consultants Ltd X-Mailer: Sylpheed version 0.8.6 (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: 1682 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: keith_m@sweeney.demon.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 495 Lines: 18 On Sat, 10 Jan 2004 17:51:44 -0600 (CST) Eric Sandeen wrote: > From userspace you can use stat(1) "stat -f" and it will tell you > the filesystem type; older stats don't know about xfs, > so you might need to look for the raw magic number, > 0x58465342 ("XFSB") > > To do it from C, see statfs(2), and use the f_type result. > Note - not all distros ship with this as standard. SuSE does, so does RH. Rock and Slackware do not. I've not got any others to hand to try. From owner-linux-xfs@oss.sgi.com Sun Jan 11 01:53:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Jan 2004 01:54:14 -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 i0B9rq6H028607 for ; Sun, 11 Jan 2004 01:53:52 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AfcI2-0005AH-Uj; Sun, 11 Jan 2004 09:53:50 +0000 Date: Sun, 11 Jan 2004 09:53:50 +0000 From: Christoph Hellwig To: Diyab Cc: linux-xfs@oss.sgi.com Subject: Re: Checking FS type Message-ID: <20040111095350.A19788@infradead.org> References: <40007A49.4060907@r00td0wn.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: <40007A49.4060907@r00td0wn.net>; from diyab@r00td0wn.net on Sat, Jan 10, 2004 at 05:18:49PM -0500 X-archive-position: 1683 X-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: 336 Lines: 8 On Sat, Jan 10, 2004 at 05:18:49PM -0500, Diyab wrote: > on. With ext2/3 the EA attribute name is different from what it will be > on an XFS file system This sounds like an incredibly bad idea. We have a common xattr API and common namespaces to avoid exactly that kind of mess. Would you mind to elborate why you are doign this? From owner-linux-xfs@oss.sgi.com Sun Jan 11 03:45:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Jan 2004 03:45:27 -0800 (PST) Received: from averell.firstfloor.org (amaca@pD952645D.dip.t-dialin.net [217.82.100.93]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BBjA6H000689 for ; Sun, 11 Jan 2004 03:45:14 -0800 Received: from averell.firstfloor.org (localhost [127.0.0.1]) by averell.firstfloor.org (8.12.6/8.12.6/SuSE Linux 0.6) with ESMTP id i0BBj4cj004539 for ; Sun, 11 Jan 2004 12:45:04 +0100 Received: (from andi@localhost) by averell.firstfloor.org (8.12.6/8.12.6/Submit) id i0BBj0Vc004538 for linux-xfs@oss.sgi.com; Sun, 11 Jan 2004 12:45:00 +0100 Date: Sun, 11 Jan 2004 12:45:00 +0100 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: XFS_WANT_FUNCS Message-ID: <20040111114500.GA4508@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 1684 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: linux-xfs Content-Length: 203 Lines: 8 I found many of the XFS include files hard to read because of XFS_WANTS_FUNCS. What use is that define? Is it still used for anything? Would patches to remove it have a chance to be accepted? -Andi From owner-linux-xfs@oss.sgi.com Sun Jan 11 08:22:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Jan 2004 08:22: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 i0BGMC6H024827 for ; Sun, 11 Jan 2004 08:22:12 -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 i0BFNtFL024448 for ; Sun, 11 Jan 2004 07:23:55 -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 i0BGM4HB29041451; Sun, 11 Jan 2004 10:22:04 -0600 (CST) Received: (from overby@localhost) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) id i0BGLhA63464298; Sun, 11 Jan 2004 10:21:43 -0600 (CST) Date: Sun, 11 Jan 2004 10:21:43 -0600 (CST) Message-Id: <200401111621.i0BGLhA63464298@daisy-e236.americas.sgi.com> From: Glen Overby To: linux-xfs@oss.sgi.com Cc: ak@muc.de Subject: Re: XFS_WANT_FUNCS In-Reply-To: message from Andi Kleen sent 11 January 2004 References: <20040111114500.GA4508@averell> X-archive-position: 1685 X-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: 731 Lines: 21 On January 11, Andi Kleen wrote: > I found many of the XFS include files hard to read because > of XFS_WANTS_FUNCS. What use is that define? Is it still used > for anything? Would patches to remove it have a chance to be > accepted? When we build XFS kernels with the DEBUG define set, it turns those macros into C functions (see xfs_macros.c). This is so stack traces will show what macro a problem occurs inside of, and so breakpoints can be set inside of macros. While it's not something I've relied heavily on for fixing bugs, I know it's been useful a time or two. I'm never enthusiastic about losing debugging tools. I'm not bothered by ifdefs. #ifdef XFS_WANT_FUNCS Glen Overby #else #error can't grok input #endif From owner-linux-xfs@oss.sgi.com Sun Jan 11 08:44:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Jan 2004 08:45:22 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BGir6H026597 for ; Sun, 11 Jan 2004 08:44:54 -0800 Received: (qmail 47887 invoked by uid 3709); 11 Jan 2004 16:45:49 -0000 Date: 11 Jan 2004 17:45:49 +0100 Date: Sun, 11 Jan 2004 17:45:49 +0100 From: Andi Kleen To: Glen Overby Cc: linux-xfs@oss.sgi.com, ak@muc.de Subject: Re: XFS_WANT_FUNCS Message-ID: <20040111164549.GA45569@colin2.muc.de> References: <20040111114500.GA4508@averell> <200401111621.i0BGLhA63464298@daisy-e236.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401111621.i0BGLhA63464298@daisy-e236.americas.sgi.com> User-Agent: Mutt/1.4.1i X-archive-position: 1686 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@colin2.muc.de Precedence: bulk X-list: linux-xfs Content-Length: 1089 Lines: 25 On Sun, Jan 11, 2004 at 10:21:43AM -0600, Glen Overby wrote: > On January 11, Andi Kleen wrote: > > I found many of the XFS include files hard to read because > > of XFS_WANTS_FUNCS. What use is that define? Is it still used > > for anything? Would patches to remove it have a chance to be > > accepted? > > When we build XFS kernels with the DEBUG define set, it turns those > macros into C functions (see xfs_macros.c). This is so stack traces > will show what macro a problem occurs inside of, and so breakpoints > can be set inside of macros. It sounds like inline functions would serve your goal better. When you have a kernel with debug information you can see exactly the line the fault occurs in then. You could even define the "inline" away to them them into normal static functions, although that would probably not be too useful (except maybe for KDB). They would also be a lot more type safe. You can also still set breakpoints in the, although only per file, not global. I can do a patch to convert them to inlines if there are chances that it will get merged. -Andi From owner-linux-xfs@oss.sgi.com Sun Jan 11 09:28:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Jan 2004 09:29: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 i0BHSg6H028099 for ; Sun, 11 Jan 2004 09:28:42 -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 i0BIlfr3027704 for ; Sun, 11 Jan 2004 12:47:41 -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 i0BHSZbR28891594; Sun, 11 Jan 2004 11:28: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 i0BHS5K213503960; Sun, 11 Jan 2004 11:28:25 -0600 (CST) Date: Sun, 11 Jan 2004 11:28:05 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Andi Kleen cc: linux-xfs@oss.sgi.com Subject: Re: XFS_WANT_FUNCS In-Reply-To: <20040111114500.GA4508@averell> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1687 X-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: 1084 Lines: 32 Andi - I agree that it makes things hard to read. I think the purpose is to turn macros into functions, for use in debugging (setting breakpoints & inspecting args). As for removing them... that's a touchy subject. The upside is that the header files would be a little easier to read, although once you get used to it your eyes can gloss over the mess. The downside would be less flexibility in debugging, and divergence of the Linux code from the Irix code, without adding any new features or fixing any bugs. We try to keep the Linux & Irix code in sync whenever possible, so that the XFS engineering resources we have can work on a common codebase, and hopefully be more efficient at finding bugs and keeping features in sync. I can ask around, but I think the preference would be to keep them in place. -Eric On Sun, 11 Jan 2004, Andi Kleen wrote: > > I found many of the XFS include files hard to read because > of XFS_WANTS_FUNCS. What use is that define? Is it still used > for anything? Would patches to remove it have a chance to be > accepted? > > -Andi > > From owner-linux-xfs@oss.sgi.com Sun Jan 11 10:29:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Jan 2004 10:29:32 -0800 (PST) Received: from mcfeely.r00td0wn.net (dsl093-212-010.clb1.dsl.speakeasy.net [66.93.212.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BITA6H032202 for ; Sun, 11 Jan 2004 10:29:11 -0800 Received: from r00td0wn.net ([172.16.1.222]) by mcfeely.r00td0wn.net with Microsoft SMTPSVC(5.0.2195.5329); Sun, 11 Jan 2004 13:29:04 -0500 Message-ID: <400195F0.1080807@r00td0wn.net> Date: Sun, 11 Jan 2004 13:29:04 -0500 From: Diyab 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: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: Checking FS type References: <40007A49.4060907@r00td0wn.net> <20040111095350.A19788@infradead.org> In-Reply-To: <20040111095350.A19788@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2004 18:29:05.0007 (UTC) FILETIME=[CAFDBFF0:01C3D870] X-archive-position: 1688 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: diyab@r00td0wn.net Precedence: bulk X-list: linux-xfs Content-Length: 1104 Lines: 24 Christoph Hellwig wrote: > On Sat, Jan 10, 2004 at 05:18:49PM -0500, Diyab wrote: > >>on. With ext2/3 the EA attribute name is different from what it will be >>on an XFS file system > > > This sounds like an incredibly bad idea. We have a common xattr API and > common namespaces to avoid exactly that kind of mess. Would you mind to > elborate why you are doign this? Ext2/3 does not seem to have root/non-root namespace like XFS does. I have not been able to find any specific information about the design of Ext2/3 in this manner but the SELinux attribute name on this file system is security.selinux. Operating on security.selinux is fine but when you try to operate on user.security.selinux the operations fail with EOPNOTSUPP. On XFS it is just the opposite, but I can see how stripping the namespace prefix from the attribute can make it fail. Basically what I am doing is putting a check in the SELinux API to look and see what the attribute name it should be using is. If it's on XFS it operates on user.security.selinux, otherwise it operates on security.selinux. Timothy, From owner-linux-xfs@oss.sgi.com Sun Jan 11 14:12:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Jan 2004 14:12: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 i0BMCF6H024429 for ; Sun, 11 Jan 2004 14:12: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 i0BNVCr3016358 for ; Sun, 11 Jan 2004 17:31:12 -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 i0BMC5cJ18525306; Sun, 11 Jan 2004 16:12: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 i0BMBZK213479552; Sun, 11 Jan 2004 16:11:45 -0600 (CST) Date: Sun, 11 Jan 2004 16:11:35 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Diyab cc: Christoph Hellwig , Subject: Re: Checking FS type In-Reply-To: <400195F0.1080807@r00td0wn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1689 X-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: 934 Lines: 19 Others are working on looking at adding a security.* namespace to xfs, you should probably coordinate with them. Hopefully they'll chime in on the list. -Eric On Sun, 11 Jan 2004, Diyab wrote: > Ext2/3 does not seem to have root/non-root namespace like XFS does. I > have not been able to find any specific information about the design of > Ext2/3 in this manner but the SELinux attribute name on this file system > is security.selinux. Operating on security.selinux is fine but when you > try to operate on user.security.selinux the operations fail with > EOPNOTSUPP. On XFS it is just the opposite, but I can see how stripping > the namespace prefix from the attribute can make it fail. Basically what > I am doing is putting a check in the SELinux API to look and see what > the attribute name it should be using is. If it's on XFS it operates on > user.security.selinux, otherwise it operates on security.selinux. From owner-linux-xfs@oss.sgi.com Sun Jan 11 16:18:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Jan 2004 16:18: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 i0C0Ih6H000642 for ; Sun, 11 Jan 2004 16:18:43 -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 i0C1bdr3029418 for ; Sun, 11 Jan 2004 19:37:40 -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 LAA25394; Mon, 12 Jan 2004 11:18:32 +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 i0C0IUUc3204247; Mon, 12 Jan 2004 11:18:31 +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 i0C0Hd0R001104; Mon, 12 Jan 2004 11:17:40 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i0C0Hce5001102; Mon, 12 Jan 2004 11:17:38 +1100 Date: Mon, 12 Jan 2004 11:17:38 +1100 From: Nathan Scott To: Diyab Cc: linux-xfs@oss.sgi.com Subject: Security namespace (was Re: Checking FS type) Message-ID: <20040112001738.GA1012@frodo> References: <40007A49.4060907@r00td0wn.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <40007A49.4060907@r00td0wn.net> User-Agent: Mutt/1.5.3i X-archive-position: 1690 X-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: 12980 Lines: 342 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jan 10, 2004 at 05:18:49PM -0500, Diyab wrote: > Hello, > > I'm working with SELinux and adding XFS attribute / security label > support into the API. The problem I'm running into is trying to > determine what type of filesystem the file I'm operating on is located > on. With ext2/3 the EA attribute name is different from what it will be > on an XFS file system so I need to detect the file system type from the > file stream I have open. I'm not familiar with how to check the file > system type since I've not done this before so does anyone have any > suggestions to give me? Any help is really appreciated, thanks! > > Timothy, > > Also please CC me because I am not on the list. Hi there Timothy, You'll want to read the thread "[patch] security. namespace" recently - see the linux-xfs list archives on oss.sgi.com. The right way to implement this is to support the "security" namespace in XFS. The attached (experimental) patch does just that - there are missing pieces (xfsdump/xfsrestore do not support this yet, etc), but this seems fairly stable so far. The patch is from late last year, it will need a few tweaks to work with the current CVS trees, but should apply relatively cleanly to older trees and Marcelo's bk tree (but not yet Andrew's/Linus' bk tree - thats a few changes behind us just at the moment and will conflict on this one). It needs some more testing, and technical discussion between us SGI folks before this patch will be applied. (so please don't follow up with "when will this be applied" questions ;) Have fun. cheers. -- Nathan --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="secure_attr.patch" =========================================================================== linux/fs/xfs/xfs_attr.c =========================================================================== --- /usr/tmp/TmpDir.24546-0/linux/fs/xfs/xfs_attr.c_1.112 2003-12-12 15:56:46.000000000 +1100 +++ linux/fs/xfs/xfs_attr.c 2003-12-12 15:44:59.696535760 +1100 @@ -2651,6 +2651,16 @@ .attr_capable = attr_trusted_capable, }; +struct attrnames attr_secure = { + .attr_name = "security.", + .attr_namelen = sizeof("security.") - 1, + .attr_flag = ATTR_SECURE, + .attr_capable = (attrcapable_t)fs_noerr, + .attr_get = attr_generic_get, + .attr_set = attr_generic_set, + .attr_remove = attr_generic_remove, +}; + struct attrnames attr_user = { .attr_name = "user.", .attr_namelen = sizeof("user.") - 1, @@ -2661,4 +2671,4 @@ }; struct attrnames *attr_namespaces[] = - { &attr_system, &attr_trusted, &attr_user }; + { &attr_system, &attr_trusted, &attr_secure, &attr_user }; =========================================================================== linux/fs/xfs/xfs_attr.h =========================================================================== --- /usr/tmp/TmpDir.24546-0/linux/fs/xfs/xfs_attr.h_1.28 2003-12-12 15:56:46.000000000 +1100 +++ linux/fs/xfs/xfs_attr.h 2003-12-12 15:45:04.047874256 +1100 @@ -69,8 +69,9 @@ attrcapable_t attr_capable; } attrnames_t; -#define ATTR_NAMECOUNT 3 +#define ATTR_NAMECOUNT 4 extern struct attrnames attr_user; +extern struct attrnames attr_secure; extern struct attrnames attr_system; extern struct attrnames attr_trusted; extern struct attrnames *attr_namespaces[ATTR_NAMECOUNT]; @@ -86,6 +87,7 @@ #define ATTR_DONTFOLLOW 0x0001 /* -- unused, from IRIX -- */ #define ATTR_ROOT 0x0002 /* use attrs in root (trusted) namespace */ #define ATTR_TRUST 0x0004 /* -- unused, from IRIX -- */ +#define ATTR_SECURE 0x0008 /* use attrs in security namespace */ #define ATTR_CREATE 0x0010 /* pure create: fail if attr already exists */ #define ATTR_REPLACE 0x0020 /* pure set: fail if attr does not exist */ #define ATTR_SYSTEM 0x0100 /* use attrs in system (pseudo) namespace */ =========================================================================== linux/fs/xfs/xfs_attr_leaf.c =========================================================================== --- /usr/tmp/TmpDir.24546-0/linux/fs/xfs/xfs_attr_leaf.c_1.75 2003-12-12 15:56:46.000000000 +1100 +++ linux/fs/xfs/xfs_attr_leaf.c 2003-12-12 15:45:07.675322800 +1100 @@ -159,6 +159,9 @@ continue; if (memcmp(args->name, sfe->nameval, args->namelen) != 0) continue; + if (((args->flags & ATTR_SECURE) != 0) != + ((sfe->flags & XFS_ATTR_SECURE) != 0)) + continue; if (((args->flags & ATTR_ROOT) != 0) != ((sfe->flags & XFS_ATTR_ROOT) != 0)) continue; @@ -173,7 +176,8 @@ sfe->namelen = args->namelen; INT_SET(sfe->valuelen, ARCH_CONVERT, args->valuelen); - sfe->flags = (args->flags & ATTR_ROOT) ? XFS_ATTR_ROOT : 0; + sfe->flags = (args->flags & ATTR_SECURE) ? XFS_ATTR_SECURE : + ((args->flags & ATTR_ROOT) ? XFS_ATTR_ROOT : 0); memcpy(sfe->nameval, args->name, args->namelen); memcpy(&sfe->nameval[args->namelen], args->value, args->valuelen); INT_MOD(sf->hdr.count, ARCH_CONVERT, 1); @@ -209,6 +213,9 @@ continue; if (memcmp(sfe->nameval, args->name, args->namelen) != 0) continue; + if (((args->flags & ATTR_SECURE) != 0) != + ((sfe->flags & XFS_ATTR_SECURE) != 0)) + continue; if (((args->flags & ATTR_ROOT) != 0) != ((sfe->flags & XFS_ATTR_ROOT) != 0)) continue; @@ -253,6 +260,9 @@ continue; if (memcmp(args->name, sfe->nameval, args->namelen) != 0) continue; + if (((args->flags & ATTR_SECURE) != 0) != + ((sfe->flags & XFS_ATTR_SECURE) != 0)) + continue; if (((args->flags & ATTR_ROOT) != 0) != ((sfe->flags & XFS_ATTR_ROOT) != 0)) continue; @@ -281,6 +291,9 @@ continue; if (memcmp(args->name, sfe->nameval, args->namelen) != 0) continue; + if (((args->flags & ATTR_SECURE) != 0) != + ((sfe->flags & XFS_ATTR_SECURE) != 0)) + continue; if (((args->flags & ATTR_ROOT) != 0) != ((sfe->flags & XFS_ATTR_ROOT) != 0)) continue; @@ -369,7 +382,8 @@ nargs.valuelen = INT_GET(sfe->valuelen, ARCH_CONVERT); nargs.hashval = xfs_da_hashname((char *)sfe->nameval, sfe->namelen); - nargs.flags = (sfe->flags & XFS_ATTR_ROOT) ? ATTR_ROOT : 0; + nargs.flags = (sfe->flags & XFS_ATTR_SECURE) ? ATTR_SECURE : + ((sfe->flags & XFS_ATTR_ROOT) ? ATTR_ROOT : 0); error = xfs_attr_leaf_lookup_int(bp, &nargs); /* set a->index */ ASSERT(error == ENOATTR); error = xfs_attr_leaf_add(bp, &nargs); @@ -446,14 +460,15 @@ i < INT_GET(sf->hdr.count, ARCH_CONVERT); i++) { attrnames_t *namesp; - namesp = (sfe->flags & XFS_ATTR_ROOT) ? &attr_trusted : - &attr_user; if (((context->flags & ATTR_ROOT) != 0) != ((sfe->flags & XFS_ATTR_ROOT) != 0) && !(context->flags & ATTR_KERNFULLS)) { sfe = XFS_ATTR_SF_NEXTENTRY(sfe); continue; } + namesp = (sfe->flags & XFS_ATTR_ROOT) ? &attr_trusted : + ((sfe->flags & XFS_ATTR_SECURE) ? &attr_secure : + &attr_user); if (context->flags & ATTR_KERNOVAL) { ASSERT(context->flags & ATTR_KERNAMELS); context->count += namesp->attr_namelen + @@ -549,7 +564,8 @@ attrnames_t *namesp; namesp = (sfe->flags & XFS_ATTR_ROOT) ? &attr_trusted : - &attr_user; + ((sfe->flags & XFS_ATTR_SECURE) ? &attr_secure : + &attr_user); if (cursor->hashval != INT_GET(sbp->hash, ARCH_CONVERT)) { cursor->hashval = INT_GET(sbp->hash, ARCH_CONVERT); @@ -668,7 +684,8 @@ nargs.value = (char *)&name_loc->nameval[nargs.namelen]; nargs.valuelen = INT_GET(name_loc->valuelen, ARCH_CONVERT); nargs.hashval = INT_GET(entry->hashval, ARCH_CONVERT); - nargs.flags = (entry->flags & XFS_ATTR_ROOT) ? ATTR_ROOT : 0; + nargs.flags = (entry->flags & XFS_ATTR_SECURE) ? ATTR_SECURE : + ((entry->flags & XFS_ATTR_ROOT) ? ATTR_ROOT : 0); xfs_attr_shortform_add(&nargs); } error = 0; @@ -963,7 +980,8 @@ + INT_GET(map->size, ARCH_CONVERT)); INT_SET(entry->hashval, ARCH_CONVERT, args->hashval); entry->flags = tmp ? XFS_ATTR_LOCAL : 0; - entry->flags |= (args->flags & ATTR_ROOT) ? XFS_ATTR_ROOT : 0; + entry->flags |= (args->flags & ATTR_SECURE) ? XFS_ATTR_SECURE : + ((args->flags & ATTR_ROOT) ? XFS_ATTR_ROOT : 0); if (args->rename) { entry->flags |= XFS_ATTR_INCOMPLETE; if ((args->blkno2 == args->blkno) && @@ -1881,6 +1899,9 @@ if (memcmp(args->name, (char *)name_loc->nameval, args->namelen) != 0) continue; + if (((args->flags & ATTR_SECURE) != 0) != + ((entry->flags & XFS_ATTR_SECURE) != 0)) + continue; if (((args->flags & ATTR_ROOT) != 0) != ((entry->flags & XFS_ATTR_ROOT) != 0)) continue; @@ -1893,6 +1914,9 @@ if (memcmp(args->name, (char *)name_rmt->name, args->namelen) != 0) continue; + if (((args->flags & ATTR_SECURE) != 0) != + ((entry->flags & XFS_ATTR_SECURE) != 0)) + continue; if (((args->flags & ATTR_ROOT) != 0) != ((entry->flags & XFS_ATTR_ROOT) != 0)) continue; @@ -2291,7 +2315,8 @@ continue; /* skip non-matching entries */ namesp = (entry->flags & XFS_ATTR_ROOT) ? &attr_trusted : - &attr_user; + ((entry->flags & XFS_ATTR_SECURE) ? &attr_secure : + &attr_user); if (entry->flags & XFS_ATTR_LOCAL) { name_loc = XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); =========================================================================== linux/fs/xfs/xfs_attr_leaf.h =========================================================================== --- /usr/tmp/TmpDir.24546-0/linux/fs/xfs/xfs_attr_leaf.h_1.33 2003-12-12 15:56:46.000000000 +1100 +++ linux/fs/xfs/xfs_attr_leaf.h 2003-12-12 15:45:11.415754168 +1100 @@ -73,9 +73,9 @@ * to work "forw"ard. If none matches, continue with the "forw"ard leaf * nodes until the hash key changes or the attribute name is found. * - * We store the fact that an attribute is a ROOT versus USER attribute in + * We store the fact that an attribute is a ROOT/USER/SECURE attribute in * the leaf_entry. The namespaces are independent only because we also look - * at the root/user bit when we are looking for a matching attribute name. + * at the namespace bit when we are looking for a matching attribute name. * * We also store a "incomplete" bit in the leaf_entry. It shows that an * attribute is in the middle of being created and should not be shown to @@ -102,7 +102,7 @@ struct xfs_attr_leaf_entry { /* sorted on key, not name */ xfs_dahash_t hashval; /* hash value of name */ __uint16_t nameidx; /* index into buffer of name/value */ - __uint8_t flags; /* LOCAL, ROOT and INCOMPLETE flags */ + __uint8_t flags; /* LOCAL/ROOT/SECURE/INCOMPLETE flag */ __uint8_t pad2; /* unused pad byte */ } entries[1]; /* variable sized array */ struct xfs_attr_leaf_name_local { @@ -130,9 +130,11 @@ */ #define XFS_ATTR_LOCAL_BIT 0 /* attr is stored locally */ #define XFS_ATTR_ROOT_BIT 1 /* limit access to trusted attrs */ +#define XFS_ATTR_SECURE_BIT 2 /* limit access to secure attrs */ #define XFS_ATTR_INCOMPLETE_BIT 7 /* attr in middle of create/delete */ #define XFS_ATTR_LOCAL (1 << XFS_ATTR_LOCAL_BIT) #define XFS_ATTR_ROOT (1 << XFS_ATTR_ROOT_BIT) +#define XFS_ATTR_SECURE (1 << XFS_ATTR_SECURE_BIT) #define XFS_ATTR_INCOMPLETE (1 << XFS_ATTR_INCOMPLETE_BIT) /* =========================================================================== linux/fs/xfs/xfsidbg.c =========================================================================== --- /usr/tmp/TmpDir.24546-0/linux/fs/xfs/xfsidbg.c_1.250 2003-12-12 15:56:46.000000000 +1100 +++ linux/fs/xfs/xfsidbg.c 2003-12-12 15:45:15.532128384 +1100 @@ -3178,7 +3178,7 @@ "DONTFOLLOW", /* 0x0001 */ "ROOT", /* 0x0002 */ "TRUSTED", /* 0x0004 */ - "?", /* 0x0008 */ + "SECURE", /* 0x0008 */ "CREATE", /* 0x0010 */ "REPLACE", /* 0x0020 */ "?", /* 0x0040 */ @@ -4791,9 +4791,12 @@ kdb_printf("LOCAL "); if (e->flags & XFS_ATTR_ROOT) kdb_printf("ROOT "); + if (e->flags & XFS_ATTR_SECURE) + kdb_printf("SECURE "); if (e->flags & XFS_ATTR_INCOMPLETE) kdb_printf("INCOMPLETE "); - k = ~(XFS_ATTR_LOCAL | XFS_ATTR_ROOT | XFS_ATTR_INCOMPLETE); + k = ~(XFS_ATTR_LOCAL | XFS_ATTR_ROOT | + XFS_ATTR_SECURE | XFS_ATTR_INCOMPLETE); if ((e->flags & k) != 0) kdb_printf("0x%x", e->flags & k); kdb_printf(">\n name \""); @@ -5652,13 +5655,16 @@ (uint_t)n->hashval, n->whichfork); if (n->flags & ATTR_ROOT) kdb_printf("ROOT "); + if (n->flags & ATTR_SECURE) + kdb_printf("SECURE "); if (n->flags & ATTR_CREATE) kdb_printf("CREATE "); if (n->flags & ATTR_REPLACE) kdb_printf("REPLACE "); if (n->flags & XFS_ATTR_INCOMPLETE) kdb_printf("INCOMPLETE "); - i = ~(ATTR_ROOT | ATTR_CREATE | ATTR_REPLACE | XFS_ATTR_INCOMPLETE); + i = ~(ATTR_ROOT | ATTR_SECURE | + ATTR_CREATE | ATTR_REPLACE | XFS_ATTR_INCOMPLETE); if ((n->flags & i) != 0) kdb_printf("0x%x", n->flags & i); kdb_printf(">\n"); --wac7ysb48OaltWcw-- From owner-linux-xfs@oss.sgi.com Sun Jan 11 18:16:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Jan 2004 18:16:17 -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 i0C2G56H007352 for ; Sun, 11 Jan 2004 18:16:05 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0C2G504007351 for linux-xfs@oss.sgi.com; Sun, 11 Jan 2004 18:16:05 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i0C2G46J007336 for ; Sun, 11 Jan 2004 18:16:04 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0C1p9J8006655; Sun, 11 Jan 2004 17:51:09 -0800 Date: Sun, 11 Jan 2004 17:51:09 -0800 Message-Id: <200401120151.i0C1p9J8006655@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: 1691 X-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: 1002 Lines: 33 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 ------- Additional Comments From nathans@sgi.com 2004-11-01 17:51 PDT ------- This looks like the first major problem... > > 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? > Can you send the test program that configure generated at this point, your copy of /usr/include/uuid/uuid.h, and the compilation failure message? thanks. I suspect there may be some toolchain problem on your machine, compiler/ linker, something like that. The actual compilation error you're seeing would be because AC_CHECK_SIZEOF seems to be failing too, which I think compiles and runs something to produce its result, so thats consistent with my theory at least. 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 Sun Jan 11 22:29:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Jan 2004 22:30:19 -0800 (PST) Received: from mcfeely.r00td0wn.net (dsl093-212-010.clb1.dsl.speakeasy.net [66.93.212.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0C6Tu6H019550 for ; Sun, 11 Jan 2004 22:29:57 -0800 Received: from r00td0wn.net ([172.16.1.222]) by mcfeely.r00td0wn.net with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Jan 2004 01:29:51 -0500 Message-ID: <40023EDF.50505@r00td0wn.net> Date: Mon, 12 Jan 2004 01:29:51 -0500 From: Diyab 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: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: Security namespace (was Re: Checking FS type) References: <40007A49.4060907@r00td0wn.net> <20040112001738.GA1012@frodo> In-Reply-To: <20040112001738.GA1012@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jan 2004 06:29:51.0577 (UTC) FILETIME=[7BF4A490:01C3D8D5] X-archive-position: 1692 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: diyab@r00td0wn.net Precedence: bulk X-list: linux-xfs Content-Length: 1180 Lines: 31 Nathan Scott wrote: > Hi there Timothy, > > You'll want to read the thread "[patch] security. namespace" > recently - see the linux-xfs list archives on oss.sgi.com. > > The right way to implement this is to support the "security" > namespace in XFS. The attached (experimental) patch does > just that - there are missing pieces (xfsdump/xfsrestore do > not support this yet, etc), but this seems fairly stable so > far. The patch is from late last year, it will need a few > tweaks to work with the current CVS trees, but should apply > relatively cleanly to older trees and Marcelo's bk tree (but > not yet Andrew's/Linus' bk tree - thats a few changes behind > us just at the moment and will conflict on this one). > > It needs some more testing, and technical discussion between > us SGI folks before this patch will be applied. (so please > don't follow up with "when will this be applied" questions ;) > > Have fun. > > cheers. Thanks for the patch and the pointer to the previous discussion. I'm going to try and get this patch applied to the current 2.6.x kernel. If I can get it working it should solve the problem I was originally trying to fix. Timothy, From owner-linux-xfs@oss.sgi.com Mon Jan 12 03:30:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 03:30:33 -0800 (PST) Received: from medoc.inf.ethz.ch (medoc.inf.ethz.ch [129.132.178.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CBUA6H005016 for ; Mon, 12 Jan 2004 03:30:11 -0800 Received: from localhost (localhost [127.0.0.1]) by medoc.inf.ethz.ch (Postfix) with ESMTP id C9476B7E0 for ; Mon, 12 Jan 2004 12:30:07 +0100 (MET) Received: from medoc.inf.ethz.ch ([127.0.0.1]) by localhost (medoc [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25697-01-6 for ; Mon, 12 Jan 2004 12:30:07 +0100 (MET) Received: from inf.ethz.ch (ikarus.inf.ethz.ch [129.132.10.58]) by medoc.inf.ethz.ch (Postfix) with ESMTP id 65CBDB85A for ; Mon, 12 Jan 2004 12:30:07 +0100 (MET) Message-ID: <40028540.1030002@inf.ethz.ch> Date: Mon, 12 Jan 2004 12:30:08 +0100 From: Marc Schmitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS creation and mount parameters on large RAID5 X-Enigmail-Version: 0.76.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at inf.ethz.ch X-archive-position: 1693 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mschmitt@inf.ethz.ch Precedence: bulk X-list: linux-xfs Content-Length: 1472 Lines: 50 Dear list, I've been browsing the XFS archives and the FAQ and found several useful hints on how to create the filesystem on a RAID5 for beter alignment and mount options for better performance. I'd like to find out if the values I found are correct (or maybe too aggressive) for my setup: The storage is a BR1600 FC2IDE (http://www.axus.com.tw/raid_br1600fc.htm), the 16 160GB disks are split in two RAID5 arrays of n=7 disks each and two hot spares. The stripe size is 128KB. According to Axus support, the data block size is 128 (stripe size) * 512bytes = 64KB. The server is a dual Xeon 2.8GHz Dell PE4600 with 4GB RAM running RedHat 7.3 (2.4.20-28_36.rh7.3.atsmp). The purpose of the machine is to serve files over SMB and NFS solely. For the file system creation, this means: Data section options: sunit = 128KB/512bytes = 256 swidth = (n-1)*sunit = 1536 Log section options: size = 64m sunit = 64KB/512bytes = 128 The mkfs.xfs command will be: mkfs.xfs -d sunit=256,swidth=1536 -l size=64m,sunit=128 -L "H1" /dev/... For the mount options: logbufs = 16 logbsize = 65536 I understand that increasing those mount values above the default will improve performance at the cost of more data being lost in case of a server crash. I'm using the sync option for NFS exports which should help this issue, though. Please let me know if you see any problems in my "calculations/settings". Any advice will be appreciated. TIA Regards, Marc From owner-linux-xfs@oss.sgi.com Mon Jan 12 05:35:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 05:35:37 -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 i0CDZ26H029595 for ; Mon, 12 Jan 2004 05:35:05 -0800 Received: (qmail 15830 invoked from network); 12 Jan 2004 13:35:01 -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 ; 12 Jan 2004 13:35:01 -0000 Message-ID: <4002A1C3.8000608@xfs.org> Date: Mon, 12 Jan 2004 07:31: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: Andi Kleen CC: Glen Overby , linux-xfs@oss.sgi.com, ak@muc.de Subject: Re: XFS_WANT_FUNCS References: <20040111114500.GA4508@averell> <200401111621.i0BGLhA63464298@daisy-e236.americas.sgi.com> <20040111164549.GA45569@colin2.muc.de> In-Reply-To: <20040111164549.GA45569@colin2.muc.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1694 X-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: 1670 Lines: 48 Andi Kleen wrote: >On Sun, Jan 11, 2004 at 10:21:43AM -0600, Glen Overby wrote: > > >>When we build XFS kernels with the DEBUG define set, it turns those >>macros into C functions (see xfs_macros.c). This is so stack traces >>will show what macro a problem occurs inside of, and so breakpoints >>can be set inside of macros. >> >> > >It sounds like inline functions would serve your goal better. When >you have a kernel with debug information you can see exactly >the line the fault occurs in then. You could even define the "inline" away >to them them into normal static functions, although that would probably >not be too useful (except maybe for KDB). They would also be a lot more >type safe. You can also still set breakpoints in the, although only >per file, not global. > >I can do a patch to convert them to inlines if there are chances that >it will get merged. > >-Andi > > > The other thing these macros let you do is switch between inline code and out of line code based on how big you want xfs to be in code size. Some of the macros expand to a lot of code and are actually always compiled as functions to avoid too much code bloat. Probably a one off decision on inline code vs function calls should be good enough for modern machines, that mechanism was more concerned with making xfs run on 32M memory Irix boxes. All the definitions in xfs_macros.h control this. But yes it is a pain to read through them - and you should try writing new ones ;-) The scary part about moving things to inlines would be xfs's tendency to push gcc to its limits on ia32. This type of thing is what has caused broken code generation in the past. Steve From owner-linux-xfs@oss.sgi.com Mon Jan 12 07:18:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 07:18:48 -0800 (PST) Received: from imf20aec.mail.bellsouth.net (imf20aec.mail.bellsouth.net [205.152.59.68]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CFIZ6H001282 for ; Mon, 12 Jan 2004 07:18:35 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf20aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040112151827.OVD18522.imf20aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Mon, 12 Jan 2004 10:18:27 -0500 Subject: Re: Segfault of xfs_repair during repair of a xfs filesystem From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Rainer Krienke Cc: Arthur Corliss , Rainer Krienke , Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <200401100951.52922.rainer@krienke.org> References: <200401071135.12886.krienke@uni-koblenz.de> <200401100951.52922.rainer@krienke.org> Content-Type: text/plain Message-Id: <1073920096.30384.12.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, 12 Jan 2004 10:08:17 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1695 X-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: 1738 Lines: 41 On Sat, 2004-01-10 at 03:51, Rainer Krienke wrote: > Am Mittwoch, 7. Januar 2004 16:42 schrieb Arthur Corliss: > > On Wed, 7 Jan 2004, Rainer Krienke wrote: > > > In between I contacted the vendor of the hardware IDE raids. The > > > technician confirmed that these raids have a read/write cache and that > > > there is *no* battery backup. So in case of an active filesystem where > > > suddenly there is a powerfail, it is likely that the hardware cache in > > > the raid is not written to disk and the filesystem will be become > > > inconsitent. And this very probably happened in my case. > > > > > > So the remaining question is only why xfs_repair was unable to repair the > > > damaged filesystem.... > > > > If I had to hazard a guess, I'd think that the transaction log, being hit > > much more frequently than most other portions of the filesystem, would be > > much more aggressively cached by the hardware's algorithms, which would > > leave the log that much more inconsistent than the filesystem. *That* > > can't help during repairs. . . > > > > In any event, it sounds like you need a UPS on that system now, eh? > > In between we found another possibility. Our vendor told us that now there is > a firmware upgrade that allows the write cache to be disabled. So we are > probably going to do this, to get rid of this problem. > > Thanks > Rainer If you care much about performance, you will need to re-do any benchmarking or other performance testing after the change. I was testing our restore procedure recently for xfs filesystems. I found a tremendous speed difference between restoring with write cache enabled/disabled. (iirc, 300% or so) fyi: I was using tar, not xfs_restore. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Mon Jan 12 09:35:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 09:35:48 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CHZH6H010868 for ; Mon, 12 Jan 2004 09:35:24 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0CHZB19491586; Mon, 12 Jan 2004 12:35:11 -0500 Received: from d03nm800.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0CHZAj4070216; Mon, 12 Jan 2004 10:35:10 -0700 Subject: dm_get_bulkall() To: roehrich@sgi.com Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: James A Goodwin Date: Mon, 12 Jan 2004 11:35:07 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/12/2004 10:35:10 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1696 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jagoodwi@us.ibm.com Precedence: bulk X-list: linux-xfs Content-Length: 382 Lines: 22 Dean, I heard that dm_get_bulkall() was implemented sometime recently. Does it work? (i.e., has it been tested?). I checked the Status file in CVS, and it's still listed as unsupported. Regards, -James Goodwin Software Engineer IBM Business Consulting Services jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Jan 12 10:19:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 10:20: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 i0CIJg6H023600 for ; Mon, 12 Jan 2004 10:19:43 -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 i0CJcjr3015565 for ; Mon, 12 Jan 2004 13:38:45 -0600 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id i0CIJSpY29213651; Mon, 12 Jan 2004 12:19:29 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i0CI5E0L27543452; Mon, 12 Jan 2004 12:05:14 -0600 (CST) Received: from clink (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i0CI5Dbs9223058; Mon, 12 Jan 2004 12:05:14 -0600 (CST) Message-Id: <200401121805.i0CI5Dbs9223058@clink.americas.sgi.com> To: James A Goodwin cc: linux-xfs@oss.sgi.com Subject: Re: dm_get_bulkall() Date: Mon, 12 Jan 2004 12:05:13 -0600 From: Dean Roehrich X-archive-position: 1697 X-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@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 445 Lines: 20 >From: James A Goodwin >--0__=09BBE48ADFF3855A8f9e8a93df938690918c09BBE48ADFF3855A >Content-type: text/plain; charset=US-ASCII > > > > > >Dean, > >I heard that dm_get_bulkall() was implemented sometime recently. Does it >work? (i.e., has it been tested?). I checked the Status file in CVS, and >it's still listed as unsupported. Yes, it works, and it screams. And you're right, I forgot about the Status file. Dean From owner-linux-xfs@oss.sgi.com Mon Jan 12 10:35:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 10:35:20 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CIZ86H024380 for ; Mon, 12 Jan 2004 10:35:08 -0800 Received: (qmail 48908 invoked by uid 3709); 12 Jan 2004 18:36:04 -0000 Date: 12 Jan 2004 19:36:04 +0100 Date: Mon, 12 Jan 2004 19:36:04 +0100 From: Andi Kleen To: Steve Lord Cc: Glen Overby , linux-xfs@oss.sgi.com, ak@muc.de Subject: Re: XFS_WANT_FUNCS Message-ID: <20040112183604.GA45023@colin2.muc.de> References: <20040111114500.GA4508@averell> <200401111621.i0BGLhA63464298@daisy-e236.americas.sgi.com> <20040111164549.GA45569@colin2.muc.de> <4002A1C3.8000608@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4002A1C3.8000608@xfs.org> User-Agent: Mutt/1.4.1i X-archive-position: 1698 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@colin2.muc.de Precedence: bulk X-list: linux-xfs Content-Length: 1682 Lines: 40 Hi Steve, On Mon, Jan 12, 2004 at 07:31:47AM -0600, Steve Lord wrote: > The other thing these macros let you do is switch between inline code > and out of > line code based on how big you want xfs to be in code size. Some of the > macros > expand to a lot of code and are actually always compiled as functions to > avoid > too much code bloat. Probably a one off decision on inline code vs function > calls should be good enough for modern machines, that mechanism was more > concerned with making xfs run on 32M memory Irix boxes. All the definitions > in xfs_macros.h control this. Good point. Even on Opteron boxes with incredibly big caches the rule is still approximately to out of line code that generates more than 10-20 instructions and cannot be constant optimized by the compiler. So it would probably make sense to just move the bigger ones out of line unconditionally and drop the macro definitions. > > But yes it is a pain to read through them - and you should try writing > new ones ;-) > The scary part about moving things to inlines would be xfs's tendency to > push > gcc to its limits on ia32. This type of thing is what has caused broken code > generation in the past. It wouldn't be any different to macros in this regard. In modern gcc they are equivalent as seen by the backend. But I agree that moving stuff out of line is often a good idea (Linux went too far on the inlining of things in the past and that is now slowly getting corrected) The question would be only what to do with the small macros, which are most of them. I guess these could be just made inline. Again, if there is a chance of a patch getting merged i can do it. -Andi From owner-linux-xfs@oss.sgi.com Mon Jan 12 15:07:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 15:07:15 -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 i0CN736H008061 for ; Mon, 12 Jan 2004 15:07:03 -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 <20040112230657.VHMB1911.imf24aec.mail.bellsouth.net@david.internal.NorcrossGroup.com> for ; Mon, 12 Jan 2004 18:06:57 -0500 Subject: [OT] Does the ATA 133 spec. include mechanical details? From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1073948203.8061.7.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, 12 Jan 2004 17:56:44 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1699 X-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: 687 Lines: 22 I am specing out a 5-drive RAID system for a large XFS filesystem. I need all the drives to be hotswap. I found what looks like a nice 5-drive chassis that will fit in the space of 3 half-height drives: http://www.rackmountnet.com/diskarray/dc35e/dc35e.htm But it looks like it requires the power and ATA connector to be at specific physical locations on the drive. I know that older IDE drives did not have a consistent location for these connectors, so I'm nervous about buying it. Does anyone know if the ATA 133 spec. requires the connectors be in a specific location, and if so are any of the older drives likely to also use the same physical layout? Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Mon Jan 12 15:31:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 15:32: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 i0CNVm6H009006 for ; Mon, 12 Jan 2004 15:31:48 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id F413A141B13A; Mon, 12 Jan 2004 18:32:20 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id B311C141B136; Mon, 12 Jan 2004 18:32:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id AECAC30001A1; Mon, 12 Jan 2004 18:32:19 -0500 (EST) Date: Mon, 12 Jan 2004 18:32:19 -0500 (EST) From: Mike Burger To: Greg Freemyer Cc: linux-xfs@oss.sgi.com Subject: Re: [OT] Does the ATA 133 spec. include mechanical details? In-Reply-To: <1073948203.8061.7.camel@david.internal.NorcrossGroup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1700 X-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: 1211 Lines: 39 On Mon, 12 Jan 2004, Greg Freemyer wrote: > I am specing out a 5-drive RAID system for a large XFS filesystem. > > I need all the drives to be hotswap. > > I found what looks like a nice 5-drive chassis that will fit in the > space of 3 half-height drives: > > http://www.rackmountnet.com/diskarray/dc35e/dc35e.htm > > But it looks like it requires the power and ATA connector to be at > specific physical locations on the drive. I know that older IDE drives > did not have a consistent location for these connectors, so I'm nervous > about buying it. > > Does anyone know if the ATA 133 spec. requires the connectors be in a > specific location, and if so are any of the older drives likely to also > use the same physical layout? I've never seen an ATA/IDE drive that didn't have the 40-pin connection on one end and the power connection at the other. -- 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 Jan 12 15:36:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 15:36:31 -0800 (PST) Received: from wingerboy.noc.sonic.net (wingerboy.noc.sonic.net [64.142.18.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CNaK6H009555 for ; Mon, 12 Jan 2004 15:36:20 -0800 Received: from wingerboy.noc.sonic.net (localhost [127.0.0.1]) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9) with ESMTP id i0CNaJlR020041 for ; Mon, 12 Jan 2004 15:36:19 -0800 (PST) (envelope-from kgc@wingerboy.noc.sonic.net) Received: (from kgc@localhost) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9/Submit) id i0CNaJ3J020040 for linux-xfs@oss.sgi.com; Mon, 12 Jan 2004 15:36:19 -0800 (PST) Date: Mon, 12 Jan 2004 15:36:19 -0800 From: Kelsey Cummings To: linux-xfs@oss.sgi.com Subject: large file problems with 2.4.25-pre4 Message-ID: <20040112233619.GF98119@sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-PGP-Key: http://sonic.net/~kgc/gpgkey.txt X-archive-position: 1701 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kgc@sonic.net Precedence: bulk X-list: linux-xfs Content-Length: 1791 Lines: 40 I'm new to using xfs, so please forgive me if I'm missing somehting obvious. I've heard good things about xfs' performance, and I have to admit I'm quite impressed with what I've seen so far. However, I've run into some confusing problems. With all of the XFS kernels I've build (2.4.24-pre1, 2.4.25-pre4) I've had trouble creating large files. dd if=/dev/zero of=/mnt/blah bs=1024k count=10000 locks up at app 6gigs with bdflush and kswapd consumming all available CPU. Once this occurs any thing attempting to access the filesystem gets stuck waiting on the kernel. Creating many 1 gig files at once doesn't exhibit the trouble. while this in 1 2 4 5 6 ... 20 do; dd if=/dev/zero of=/mnt/blah/file.${this} & done The volume is not going to be used for such largefiles but it makes me considerably uneasy to have such a clear problem. As a side note, I'm using a new Promise SATA->SCSI raid box (not official released yet) with dual U160 interfaces. With the naive tuing that I've done so far I'm able to get ~120MB through a single channel. It's a 820gb 14 disk raid 10 set, with a 64k stripe. What is a good recomened journal size? There's some suggestion that a bigger one could be better, but how big? Maximum size? Likewise, increasing the logbufs and logbufsize. What settings people having success at? This box going to be a NFS server for small file IO and lots of dbfiles at about 5-10 mb a piece. I expect a pretty high transactional IO load. -- Kelsey Cummings - kgc@sonic.net sonic.net, inc. System Administrator 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax) http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 From owner-linux-xfs@oss.sgi.com Mon Jan 12 15:41:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 15:42:05 -0800 (PST) Received: from wingerboy.noc.sonic.net (wingerboy.noc.sonic.net [64.142.18.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CNfs6H010454 for ; Mon, 12 Jan 2004 15:41:54 -0800 Received: from wingerboy.noc.sonic.net (localhost [127.0.0.1]) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9) with ESMTP id i0CNfqlR020837; Mon, 12 Jan 2004 15:41:52 -0800 (PST) (envelope-from kgc@wingerboy.noc.sonic.net) Received: (from kgc@localhost) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9/Submit) id i0CNfqhL020836; Mon, 12 Jan 2004 15:41:52 -0800 (PST) Date: Mon, 12 Jan 2004 15:41:52 -0800 From: Kelsey Cummings To: Greg Freemyer Cc: linux-xfs@oss.sgi.com Subject: Re: [OT] Does the ATA 133 spec. include mechanical details? Message-ID: <20040112234152.GH98119@sonic.net> References: <1073948203.8061.7.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1073948203.8061.7.camel@david.internal.NorcrossGroup.com> User-Agent: Mutt/1.4.1i X-PGP-Key: http://sonic.net/~kgc/gpgkey.txt X-archive-position: 1702 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kgc@sonic.net Precedence: bulk X-list: linux-xfs Content-Length: 1534 Lines: 39 Greg, I've used some of this vendor's cases elsewhere and I recal having some drives that wouldn't fit it correctly. I'd call them, we've been buying 1U servers from them and they're quite helpful. Otherwise I'd check out cremax's MB810 AKF, which uses short ribon cable stubs off of the carrier. http://www.cremax.com I think supermicro and 3ware also make some nice carrirers, although, I bet they are more expensive. On Mon, Jan 12, 2004 at 05:56:44PM -0500, Greg Freemyer wrote: > I am specing out a 5-drive RAID system for a large XFS filesystem. > > I need all the drives to be hotswap. > > I found what looks like a nice 5-drive chassis that will fit in the > space of 3 half-height drives: > > http://www.rackmountnet.com/diskarray/dc35e/dc35e.htm > > But it looks like it requires the power and ATA connector to be at > specific physical locations on the drive. I know that older IDE drives > did not have a consistent location for these connectors, so I'm nervous > about buying it. > > Does anyone know if the ATA 133 spec. requires the connectors be in a > specific location, and if so are any of the older drives likely to also > use the same physical layout? > > Greg > -- > Greg Freemyer > -- Kelsey Cummings - kgc@sonic.net sonic.net, inc. System Administrator 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax) http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 From owner-linux-xfs@oss.sgi.com Mon Jan 12 15:46:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 15:46:17 -0800 (PST) Received: from imf23aec.mail.bellsouth.net (imf23aec.mail.bellsouth.net [205.152.59.71]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CNk66H010919 for ; Mon, 12 Jan 2004 15:46:06 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf23aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040112234601.FTWF1950.imf23aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Mon, 12 Jan 2004 18:46:01 -0500 Subject: Re: [OT] Does the ATA 133 spec. include mechanical details? From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Mike Burger Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1073950546.8957.5.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, 12 Jan 2004 18:35:47 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1703 X-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: 776 Lines: 26 On Mon, 2004-01-12 at 18:32, Mike Burger wrote: > On Mon, 12 Jan 2004, Greg Freemyer wrote: > > > > > Does anyone know if the ATA 133 spec. requires the connectors be in a > > specific location, and if so are any of the older drives likely to also > > use the same physical layout? > > I've never seen an ATA/IDE drive that didn't have the 40-pin connection on > one end and the power connection at the other. I've got some older 6 GB size drives that have the connector atleast 1/10 inch offset from the drives I now buy. Normally no big deal, but if the drive has to slide onto a fixed connector block like shown at http://www.rackmountnet.com/diskarray/dc35e/dc35e_backplane2.jpg then 1/10 inch is nowhere near consistent enough. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Mon Jan 12 16:08:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 16:08:51 -0800 (PST) Received: from imf16aec.mail.bellsouth.net (imf16aec.mail.bellsouth.net [205.152.59.64]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D08Q6H011893 for ; Mon, 12 Jan 2004 16:08:26 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf16aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040113000813.VFLT1884.imf16aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Mon, 12 Jan 2004 19:08:13 -0500 Subject: Re: [OT] Does the ATA 133 spec. include mechanical details? From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Kelsey Cummings Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040112234152.GH98119@sonic.net> References: <1073948203.8061.7.camel@david.internal.NorcrossGroup.com> <20040112234152.GH98119@sonic.net> Content-Type: text/plain Message-Id: <1073951878.8957.11.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, 12 Jan 2004 18:57:59 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1704 X-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: 882 Lines: 24 On Mon, 2004-01-12 at 18:41, Kelsey Cummings wrote: > Greg, I've used some of this vendor's cases elsewhere and I recal having > some drives that wouldn't fit it correctly. I'd call them, we've been > buying 1U servers from them and they're quite helpful. I'll do that, but I called before I posted, and their seemed to be a language barrier. (Korean?) > Otherwise I'd check > out cremax's MB810 AKF, which uses short ribon cable stubs off of the > carrier. http://www.cremax.com I think supermicro and 3ware also make > some nice carrirers, although, I bet they are more expensive. > I had seen the cremax MB810 AKF before, but it does not look near as professional as the other. I have a 3ware 3-drive chassis on the shelf, but I really need a 5-drive for this, and I don't think 3ware makes them. I had not thought about supermicro, I will see what they have. Greg From owner-linux-xfs@oss.sgi.com Mon Jan 12 16:13:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 16:13:36 -0800 (PST) Received: from wingerboy.noc.sonic.net (wingerboy.noc.sonic.net [64.142.18.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D0DO6H012438 for ; Mon, 12 Jan 2004 16:13:25 -0800 Received: from wingerboy.noc.sonic.net (localhost [127.0.0.1]) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9) with ESMTP id i0D0DNlR025742; Mon, 12 Jan 2004 16:13:23 -0800 (PST) (envelope-from kgc@wingerboy.noc.sonic.net) Received: (from kgc@localhost) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9/Submit) id i0D0DNDr025741; Mon, 12 Jan 2004 16:13:23 -0800 (PST) Date: Mon, 12 Jan 2004 16:13:23 -0800 From: Kelsey Cummings To: Greg Freemyer Cc: linux-xfs@oss.sgi.com Subject: Re: [LNX-XFS] Re: [OT] Does the ATA 133 spec. include mechanical details? Message-ID: <20040113001323.GK98119@sonic.net> References: <1073948203.8061.7.camel@david.internal.NorcrossGroup.com> <20040112234152.GH98119@sonic.net> <1073951878.8957.11.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1073951878.8957.11.camel@david.internal.NorcrossGroup.com> User-Agent: Mutt/1.4.1i X-PGP-Key: http://sonic.net/~kgc/gpgkey.txt X-archive-position: 1705 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kgc@sonic.net Precedence: bulk X-list: linux-xfs Content-Length: 1608 Lines: 40 On Mon, Jan 12, 2004 at 06:57:59PM -0500, Greg Freemyer wrote: > On Mon, 2004-01-12 at 18:41, Kelsey Cummings wrote: > > Greg, I've used some of this vendor's cases elsewhere and I recal > > having > > some drives that wouldn't fit it correctly. I'd call them, we've been > > buying 1U servers from them and they're quite helpful. > > I'll do that, but I called before I posted, and their seemed to be a > language barrier. (Korean?) > > > Otherwise I'd check > > out cremax's MB810 AKF, which uses short ribon cable stubs off of the > > carrier. http://www.cremax.com I think supermicro and 3ware also make > > some nice carrirers, although, I bet they are more expensive. > > > > I had seen the cremax MB810 AKF before, but it does not look near as > professional as the other. I've got lots of the cramax (3 bay units in service) maybe like 15 or 20. I had one go bad and got an advanve replacement out of them. YMMV. > I have a 3ware 3-drive chassis on the shelf, but I really need a 5-drive > for this, and I don't think 3ware makes them. The 3ware bayes are very solid, the RDC-400 is a 4 bay in 3U hot swap chasis. You might see what http://www.scsi4me.com has, despite the cheasy name the've been a good vendor for disks, controllers and tidbits and rock bottom prices. -- Kelsey Cummings - kgc@sonic.net sonic.net, inc. System Administrator 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax) http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 From owner-linux-xfs@oss.sgi.com Mon Jan 12 16:16:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 16:16:21 -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 i0D0GA6H013212 for ; Mon, 12 Jan 2004 16:16:10 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0D0GAd0013211 for linux-xfs@oss.sgi.com; Mon, 12 Jan 2004 16:16: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 i0D0G86J013197 for ; Mon, 12 Jan 2004 16:16:09 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0D0FQm6013185; Mon, 12 Jan 2004 16:15:26 -0800 Date: Mon, 12 Jan 2004 16:15:26 -0800 Message-Id: <200401130015.i0D0FQm6013185@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: 1706 X-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: 1596 Lines: 38 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 ------- Additional Comments From netllama@linux-sxs.org 2004-12-01 16:15 PDT ------- BTW, I just tried rebuilding the newly released xfsprogs-2.6.2, and I'm seeing the same failure. I'm using autoconf-2.57. I'm not sure where to get the test program that you requested. The failure looks like this though: #################### /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.2\" -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.2\" -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/OpenLinux/BUILD/xfsprogs-2.6.2' make: *** [default] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.60974 (%build) ##################### I'll attach my version of uuid.h in a minute. ------- 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 Jan 12 16:31:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 16:31:59 -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 i0D0Vk6H016792 for ; Mon, 12 Jan 2004 16:31:47 -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 i0D1omAY014699 for ; Mon, 12 Jan 2004 19:50:49 -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 LAA11445; Tue, 13 Jan 2004 11:31:36 +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 i0D0VYUc3196273; Tue, 13 Jan 2004 11:31:35 +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 i0D0UebJ001148; Tue, 13 Jan 2004 11:30:41 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i0D0UdNc001146; Tue, 13 Jan 2004 11:30:39 +1100 Date: Tue, 13 Jan 2004 11:30:39 +1100 From: Nathan Scott To: Kelsey Cummings Cc: linux-xfs@oss.sgi.com Subject: Re: large file problems with 2.4.25-pre4 Message-ID: <20040113003039.GB969@frodo> References: <20040112233619.GF98119@sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040112233619.GF98119@sonic.net> User-Agent: Mutt/1.5.3i X-archive-position: 1707 X-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: 1184 Lines: 32 On Mon, Jan 12, 2004 at 03:36:19PM -0800, Kelsey Cummings wrote: > I'm new to using xfs, so please forgive me if I'm missing somehting > obvious. I've heard good things about xfs' performance, and I have to > admit I'm quite impressed with what I've seen so far. However, I've run > into some confusing problems. > > With all of the XFS kernels I've build (2.4.24-pre1, 2.4.25-pre4) I've had > trouble creating large files. > > dd if=/dev/zero of=/mnt/blah bs=1024k count=10000 > > locks up at app 6gigs with bdflush and kswapd consumming all available CPU. > Once this occurs any thing attempting to access the filesystem gets stuck > waiting on the kernel. Hmm... I'm not seeing this behaviour on my test system - using the 10G case you have above it completes for me in a few minutes (and a bit more quickly on 2.6 than 2.4). What is free space like on your /mnt filesystem & how much memory do you have? I tried both a too-small and a plenty- large filesystem, and didn't see lockups on either 2.4 or 2.6 in a couple of attempts. If you consistently see lockups, your best bet is to drop into kdb and start with backtraces on the stuck processes. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jan 12 16:52:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 16:52:34 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D0qM6H018009 for ; Mon, 12 Jan 2004 16:52:22 -0800 Received: from wingerboy.noc.sonic.net (wingerboy.noc.sonic.net [64.142.18.2]) by a.mail.sonic.net (8.12.10/8.12.7) with ESMTP id i0D0qEF4004230 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 12 Jan 2004 16:52:14 -0800 Received: from wingerboy.noc.sonic.net (localhost [127.0.0.1]) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9) with ESMTP id i0D0polR031286; Mon, 12 Jan 2004 16:51:50 -0800 (PST) (envelope-from kgc@wingerboy.noc.sonic.net) Received: (from kgc@localhost) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9/Submit) id i0D0poPx031285; Mon, 12 Jan 2004 16:51:50 -0800 (PST) Date: Mon, 12 Jan 2004 16:51:50 -0800 From: Kelsey Cummings To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: [LNX-XFS] Re: large file problems with 2.4.25-pre4 Message-ID: <20040113005150.GL98119@sonic.net> References: <20040112233619.GF98119@sonic.net> <20040113003039.GB969@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040113003039.GB969@frodo> User-Agent: Mutt/1.4.1i X-PGP-Key: http://sonic.net/~kgc/gpgkey.txt X-archive-position: 1708 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kgc@sonic.net Precedence: bulk X-list: linux-xfs Content-Length: 2038 Lines: 48 On Tue, Jan 13, 2004 at 11:30:39AM +1100, Nathan Scott wrote: > On Mon, Jan 12, 2004 at 03:36:19PM -0800, Kelsey Cummings wrote: > > I'm new to using xfs, so please forgive me if I'm missing somehting > > obvious. I've heard good things about xfs' performance, and I have to > > admit I'm quite impressed with what I've seen so far. However, I've run > > into some confusing problems. > > > > With all of the XFS kernels I've build (2.4.24-pre1, 2.4.25-pre4) I've had > > trouble creating large files. > > > > dd if=/dev/zero of=/mnt/blah bs=1024k count=10000 > > > > locks up at app 6gigs with bdflush and kswapd consumming all available CPU. > > Once this occurs any thing attempting to access the filesystem gets stuck > > waiting on the kernel. > > Hmm... I'm not seeing this behaviour on my test system - > using the 10G case you have above it completes for me in > a few minutes (and a bit more quickly on 2.6 than 2.4). > > What is free space like on your /mnt filesystem & how much > memory do you have? I tried both a too-small and a plenty- > large filesystem, and didn't see lockups on either 2.4 or > 2.6 in a couple of attempts. plenty, it does it on the empty 800gig file system. 2 gigs of ram, dual Xeon, HT enabled. 'defau;t' file system creation args. Just verified again, this time on small filesystems: /dev/sdb1 359652544 4675564 354976980 2% /mnt/vol0 /dev/sdc1 359652544 239820 359412724 1% /mnt/vol1 It's a redhat 7.3 box, if perhaps the system libs could be causing the problems. > If you consistently see lockups, your best bet is to drop > into kdb and start with backtraces on the stuck processes. Aie, I'm afraid I don't have that kind of foo. :) -- Kelsey Cummings - kgc@sonic.net sonic.net, inc. System Administrator 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax) http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 From owner-linux-xfs@oss.sgi.com Mon Jan 12 18:13:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 18:14:16 -0800 (PST) Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D2Du6H021884 for ; Mon, 12 Jan 2004 18:13:56 -0800 Received: (qmail 9172 invoked from network); 13 Jan 2004 02:13:52 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay02.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 13 Jan 2004 02:13:52 -0000 Message-ID: <4003539F.8030207@xfs.org> Date: Mon, 12 Jan 2004 20:10:39 -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: Kelsey Cummings CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: [LNX-XFS] Re: large file problems with 2.4.25-pre4 References: <20040112233619.GF98119@sonic.net> <20040113003039.GB969@frodo> <20040113005150.GL98119@sonic.net> In-Reply-To: <20040113005150.GL98119@sonic.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1709 X-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: 1872 Lines: 57 Kelsey Cummings wrote: > On Tue, Jan 13, 2004 at 11:30:39AM +1100, Nathan Scott wrote: > >>On Mon, Jan 12, 2004 at 03:36:19PM -0800, Kelsey Cummings wrote: >> >>>I'm new to using xfs, so please forgive me if I'm missing somehting >>>obvious. I've heard good things about xfs' performance, and I have to >>>admit I'm quite impressed with what I've seen so far. However, I've run >>>into some confusing problems. >>> >>>With all of the XFS kernels I've build (2.4.24-pre1, 2.4.25-pre4) I've had >>>trouble creating large files. >>> >>>dd if=/dev/zero of=/mnt/blah bs=1024k count=10000 >>> >>>locks up at app 6gigs with bdflush and kswapd consumming all available CPU. >>>Once this occurs any thing attempting to access the filesystem gets stuck >>>waiting on the kernel. >> >>Hmm... I'm not seeing this behaviour on my test system - >>using the 10G case you have above it completes for me in >>a few minutes (and a bit more quickly on 2.6 than 2.4). >> >>What is free space like on your /mnt filesystem & how much >>memory do you have? I tried both a too-small and a plenty- >>large filesystem, and didn't see lockups on either 2.4 or >>2.6 in a couple of attempts. > > > plenty, it does it on the empty 800gig file system. 2 gigs of ram, dual > Xeon, HT enabled. 'defau;t' file system creation args. > > Just verified again, this time on small filesystems: > > /dev/sdb1 359652544 4675564 354976980 2% /mnt/vol0 > /dev/sdc1 359652544 239820 359412724 1% /mnt/vol1 > > It's a redhat 7.3 box, if perhaps the system libs could be causing the > problems. > > >>If you consistently see lockups, your best bet is to drop >>into kdb and start with backtraces on the stuck processes. > > > Aie, I'm afraid I don't have that kind of foo. :) > Nathan, Isn't this the large ag size and extents beyond 4G in size bug again? Steve From owner-linux-xfs@oss.sgi.com Mon Jan 12 18:16:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 18:16:23 -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 i0D2GB6H022348 for ; Mon, 12 Jan 2004 18:16:11 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0D2GBmI022347 for linux-xfs@oss.sgi.com; Mon, 12 Jan 2004 18:16:11 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i0D2G96J022333 for ; Mon, 12 Jan 2004 18:16:10 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0D25xh7021677; Mon, 12 Jan 2004 18:05:59 -0800 Date: Mon, 12 Jan 2004 18:05:59 -0800 Message-Id: <200401130205.i0D25xh7021677@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: 1710 X-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: 922 Lines: 32 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 ------- Additional Comments From netllama@linux-sxs.org 2004-12-01 16:17 PDT ------- Created an attachment (id=95) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=95&action=view) /usr/include/uuid/uuid.h My /usr/include/uuid/uuid.h ------- Additional Comments From nathans@sgi.com 2004-12-01 18:05 PDT ------- > the same failure. I'm using autoconf-2.57. I'm not sure where to get the test > program that you requested. The failed attempt to build the test program that uses uuid/uuid.h will be in the config.log file in the same directory as the configure script. This log file will have an entry like... configure:3461: checking uuid/uuid.h usability then the gcc line used, error messages, copy of the program source, etc. 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 Mon Jan 12 18:28:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 18:28:52 -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 i0D2Sc6H023069 for ; Mon, 12 Jan 2004 18:28:39 -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 i0D1UPMk025709 for ; Mon, 12 Jan 2004 17:30: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 i0D2SUqH3282849 for ; Tue, 13 Jan 2004 13:28:30 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0D2STAb3285276 for linux-xfs@oss.sgi.com; Tue, 13 Jan 2004 13:28:29 +1100 (EST) Date: Tue, 13 Jan 2004 13:28:29 +1100 (EST) From: Nathan Scott Message-Id: <200401130228.i0D2STAb3285276@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Merge up to 2.6.1 X-archive-position: 1711 X-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: 32543 Lines: 996 Date: Mon Jan 12 18:23:07 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:164733a drivers/usb/media/w9968cf.c - 1.1 drivers/usb/media/w9968cf.h - 1.1 drivers/usb/media/w9968cf_decoder.h - 1.1 Documentation/MSI-HOWTO.txt - 1.1 drivers/usb/media/w9968cf_externaldef.h - 1.1 drivers/usb/misc/legousbtower.c - 1.1 Documentation/dvb/bt8xx.txt - 1.1 Documentation/dvb/cards.txt - 1.1 Documentation/dvb/contributors.txt - 1.1 Documentation/dvb/faq.txt - 1.1 Documentation/dvb/firmware.txt - 1.1 Documentation/dvb/readme.txt - 1.1 Documentation/dvb/ttusb-dec.txt - 1.1 include/asm-alpha/cpumask.h - 1.1 include/asm-arm/cpumask.h - 1.1 include/asm-arm26/cpumask.h - 1.1 include/asm-cris/cpumask.h - 1.1 include/asm-generic/cpumask.h - 1.1 Documentation/i2c/porting-clients - 1.1 include/asm-h8300/cpumask.h - 1.1 include/asm-i386/cpumask.h - 1.1 include/asm-ia64/cpumask.h - 1.1 include/asm-m68k/cpumask.h - 1.1 include/asm-m68knommu/cpumask.h - 1.1 include/asm-mips/cpumask.h - 1.1 include/asm-parisc/cpumask.h - 1.1 include/asm-ppc/cpumask.h - 1.1 include/asm-ppc64/cpumask.h - 1.1 include/asm-s390/cpumask.h - 1.1 include/asm-sh/cpumask.h - 1.1 include/asm-sparc/cpumask.h - 1.1 include/asm-sparc/fixmap.h - 1.1 include/asm-sparc/setup.h - 1.1 include/asm-sparc64/cpumask.h - 1.1 include/asm-sparc64/setup.h - 1.1 include/asm-um/cpumask.h - 1.1 include/asm-v850/cpumask.h - 1.1 include/asm-x86_64/cpu.h - 1.1 include/asm-x86_64/cpumask.h - 1.1 Documentation/usb/w9968cf.txt - 1.1 include/asm-x86_64/memblk.h - 1.1 include/asm-x86_64/node.h - 1.1 include/linux/pci_msi.h - 1.1 lib/int_sqrt.c - 1.1 lib/mask.c - 1.1 drivers/pci/msi.c - 1.1 drivers/media/dvb/ttpci/fdump.c - 1.1 drivers/media/dvb/frontends/dst.c - 1.1 drivers/media/dvb/frontends/dst-bt878.h - 1.1 arch/arm/configs/netwinder_defconfig - 1.1 drivers/media/dvb/bt8xx/dvb-bt8xx.h - 1.1 drivers/media/dvb/bt8xx/dvb-bt8xx.c - 1.1 drivers/media/dvb/bt8xx/bt878.h - 1.1 drivers/media/dvb/bt8xx/bt878.c - 1.1 drivers/media/dvb/bt8xx/Makefile - 1.1 drivers/media/dvb/bt8xx/Kconfig - 1.1 drivers/ide/pci/sgiioc4.c - 1.1 drivers/i2c/chips/lm83.c - 1.1 drivers/i2c/chips/lm75.h - 1.1 drivers/char/watchdog/w83627hf_wdt.c - 1.1 arch/x86_64/ia32/ia32_aout.c - 1.1 arch/parisc/kernel/signal32.h - 1.1 arch/parisc/configs/712_defconfig - 1.1 arch/ia64/lib/dec_and_lock.c - 1.1 arch/ia64/configs/sn2_defconfig - 1.1 arch/i386/kernel/efi_stub.S - 1.1 arch/i386/kernel/efi.c - 1.1 CREDITS - 1.2 Documentation/Changes - 1.2 Documentation/DocBook/kernel-locking.tmpl - 1.2 Documentation/SubmittingDrivers - 1.2 Documentation/block/biodoc.txt - 1.2 Documentation/fb/aty128fb.txt - 1.2 Documentation/fb/matroxfb.txt - 1.2 Documentation/filesystems/Locking - 1.2 Documentation/filesystems/xfs.txt - 1.2 Documentation/i2c/i2c-velleman - 1.2 Documentation/i2c/summary - 1.2 Documentation/i2c/sysfs-interface - 1.2 Documentation/i2c/writing-clients - 1.2 Documentation/i386/zero-page.txt - 1.2 Documentation/input/input.txt - 1.2 Documentation/kbuild/kconfig-language.txt - 1.2 Documentation/kbuild/modules.txt - 1.2 Documentation/kernel-parameters.txt - 1.2 Documentation/networking/ip-sysctl.txt - 1.2 Documentation/scsi/BusLogic.txt - 1.2 Documentation/scsi/aic79xx.txt - 1.2 Documentation/scsi/aic7xxx.txt - 1.2 Documentation/scsi/st.txt - 1.2 Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl - 1.2 Documentation/sound/oss/CMI8330 - 1.2 Documentation/sound/oss/INSTALL.awe - 1.2 Documentation/sound/oss/Introduction - 1.2 Documentation/sound/oss/PAS16 - 1.2 Documentation/sound/oss/SoundPro - 1.2 Documentation/sound/oss/Wavefront - 1.2 Documentation/watchdog/watchdog-api.txt - 1.2 MAINTAINERS - 1.2 Makefile - 1.2 README - 1.2 arch/alpha/kernel/irq.c - 1.2 arch/arm/Makefile - 1.2 arch/arm/boot/compressed/Makefile - 1.2 arch/arm/boot/compressed/head.S - 1.2 arch/arm/common/sa1111.c - 1.2 arch/arm/configs/shark_defconfig - 1.2 arch/arm/kernel/armksyms.c - 1.2 arch/arm/kernel/calls.S - 1.2 arch/arm/kernel/dma-isa.c - 1.2 arch/arm/kernel/fiq.c - 1.2 arch/arm/kernel/irq.c - 1.2 arch/arm/kernel/module.c - 1.2 arch/arm/lib/div64.S - 1.2 arch/arm/mach-clps711x/time.c - 1.2 arch/arm/mach-integrator/cpu.c - 1.2 arch/arm/mach-integrator/integrator_ap.c - 1.2 arch/arm/mach-sa1100/Kconfig - 1.2 arch/arm/mm/cache-v3.S - 1.2 arch/arm/mm/cache-v4.S - 1.2 arch/arm/mm/cache-v4wb.S - 1.2 arch/arm/mm/cache-v4wt.S - 1.2 arch/arm/mm/mm-armv.c - 1.2 arch/arm26/kernel/irq.c - 1.2 arch/cris/kernel/irq.c - 1.2 arch/h8300/Kconfig - 1.2 arch/h8300/Makefile - 1.2 arch/h8300/platform/h8300h/ints.c - 1.2 arch/h8300/platform/h8s/ints.c - 1.2 arch/i386/Kconfig - 1.2 arch/i386/kernel/Makefile - 1.2 arch/i386/kernel/acpi/boot.c - 1.2 arch/i386/kernel/cpu/common.c - 1.2 arch/i386/kernel/cpu/cpufreq/acpi.c - 1.2 arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.2 arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.2 arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.2 arch/i386/kernel/cpu/cpufreq/powernow-k8.c - 1.2 arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c - 1.2 arch/i386/kernel/cpu/cpufreq/speedstep-lib.c - 1.2 arch/i386/kernel/cpu/cpufreq/speedstep-lib.h - 1.2 arch/i386/kernel/cpu/cpufreq/speedstep-smi.c - 1.2 arch/i386/kernel/i8259.c - 1.2 arch/i386/kernel/io_apic.c - 1.2 arch/i386/kernel/irq.c - 1.2 arch/i386/kernel/mpparse.c - 1.2 arch/i386/kernel/process.c - 1.2 arch/i386/kernel/reboot.c - 1.2 arch/i386/kernel/setup.c - 1.2 arch/i386/kernel/summit.c - 1.2 arch/i386/kernel/time.c - 1.2 arch/i386/kernel/timers/timer_cyclone.c - 1.2 arch/i386/kernel/timers/timer_hpet.c - 1.2 arch/i386/kernel/timers/timer_none.c - 1.2 arch/i386/kernel/timers/timer_pit.c - 1.2 arch/i386/kernel/timers/timer_tsc.c - 1.2 arch/i386/kernel/vm86.c - 1.2 arch/i386/lib/usercopy.c - 1.2 arch/i386/mm/highmem.c - 1.2 arch/i386/mm/hugetlbpage.c - 1.2 arch/i386/mm/init.c - 1.2 arch/i386/pci/irq.c - 1.2 arch/ia64/Kconfig - 1.2 arch/ia64/Makefile - 1.2 arch/ia64/defconfig - 1.2 arch/ia64/hp/sim/boot/fw-emu.c - 1.2 arch/ia64/ia32/binfmt_elf32.c - 1.2 arch/ia64/ia32/ia32_entry.S - 1.2 arch/ia64/ia32/ia32priv.h - 1.2 arch/ia64/ia32/sys_ia32.c - 1.2 arch/ia64/kernel/Makefile - 1.2 arch/ia64/kernel/acpi.c - 1.2 arch/ia64/kernel/asm-offsets.c - 1.2 arch/ia64/kernel/efi.c - 1.2 arch/ia64/kernel/entry.S - 1.2 arch/ia64/kernel/entry.h - 1.2 arch/ia64/kernel/gate.S - 1.2 arch/ia64/kernel/head.S - 1.2 arch/ia64/kernel/ia64_ksyms.c - 1.2 arch/ia64/kernel/iosapic.c - 1.2 arch/ia64/kernel/irq.c - 1.2 arch/ia64/kernel/ivt.S - 1.2 arch/ia64/kernel/mca.c - 1.2 arch/ia64/kernel/mca_asm.S - 1.2 arch/ia64/kernel/perfmon.c - 1.2 arch/ia64/kernel/perfmon_default_smpl.c - 1.2 arch/ia64/kernel/ptrace.c - 1.2 arch/ia64/kernel/salinfo.c - 1.2 arch/ia64/kernel/setup.c - 1.2 arch/ia64/kernel/signal.c - 1.2 arch/ia64/kernel/smpboot.c - 1.2 arch/ia64/kernel/traps.c - 1.2 arch/ia64/kernel/vmlinux.lds.S - 1.2 arch/ia64/lib/Makefile - 1.2 arch/ia64/mm/discontig.c - 1.2 arch/ia64/mm/hugetlbpage.c - 1.2 arch/ia64/mm/init.c - 1.2 arch/ia64/pci/pci.c - 1.2 arch/m68k/Kconfig - 1.2 arch/m68k/kernel/ints.c - 1.2 arch/m68knommu/platform/5307/ints.c - 1.2 arch/m68knommu/platform/68328/ints.c - 1.2 arch/m68knommu/platform/68360/ints.c - 1.2 arch/mips/Kconfig - 1.2 arch/mips/kernel/irq.c - 1.2 arch/mips/mm/highmem.c - 1.2 arch/parisc/Kconfig - 1.2 arch/parisc/defconfig - 1.2 arch/parisc/kernel/Makefile - 1.2 arch/parisc/kernel/cache.c - 1.2 arch/parisc/kernel/drivers.c - 1.2 arch/parisc/kernel/entry.S - 1.2 arch/parisc/kernel/firmware.c - 1.2 arch/parisc/kernel/hardware.c - 1.2 arch/parisc/kernel/head.S - 1.2 arch/parisc/kernel/head64.S - 1.2 arch/parisc/kernel/inventory.c - 1.2 arch/parisc/kernel/ioctl32.c - 1.2 arch/parisc/kernel/irq.c - 1.2 arch/parisc/kernel/pacache.S - 1.2 arch/parisc/kernel/parisc_ksyms.c - 1.2 arch/parisc/kernel/pdc_chassis.c - 1.2 arch/parisc/kernel/pdc_cons.c - 1.2 arch/parisc/kernel/process.c - 1.2 arch/parisc/kernel/processor.c - 1.2 arch/parisc/kernel/real2.S - 1.2 arch/parisc/kernel/signal.c - 1.2 arch/parisc/kernel/signal32.c - 1.2 arch/parisc/kernel/smp.c - 1.2 arch/parisc/kernel/sys_parisc.c - 1.2 arch/parisc/kernel/sys_parisc32.c - 1.2 arch/parisc/kernel/syscall_table.S - 1.2 arch/parisc/kernel/time.c - 1.2 arch/parisc/kernel/traps.c - 1.2 arch/parisc/kernel/unaligned.c - 1.2 arch/parisc/lib/lusercopy.S - 1.2 arch/ppc/boot/simple/Makefile - 1.2 arch/ppc/boot/utils/mkprep.c - 1.2 arch/ppc/kernel/irq.c - 1.2 arch/ppc/kernel/ppc_ksyms.c - 1.2 arch/ppc64/kernel/irq.c - 1.2 arch/ppc64/kernel/mf_proc.c - 1.2 arch/ppc64/kernel/proc_pmc.c - 1.2 arch/ppc64/kernel/rtas-proc.c - 1.2 arch/ppc64/kernel/scanlog.c - 1.2 arch/ppc64/mm/hugetlbpage.c - 1.2 arch/s390/kernel/compat_wrapper.S - 1.2 arch/s390/kernel/setup.c - 1.2 arch/s390/kernel/syscalls.S - 1.2 arch/sh/Kconfig - 1.2 arch/sh/kernel/irq.c - 1.2 arch/sparc/Kconfig - 1.2 arch/sparc/Makefile - 1.2 arch/sparc/boot/Makefile - 1.2 arch/sparc/kernel/asm-offsets.c - 1.2 arch/sparc/kernel/entry.S - 1.2 arch/sparc/kernel/etrap.S - 1.2 arch/sparc/kernel/irq.c - 1.2 arch/sparc/kernel/process.c - 1.2 arch/sparc/kernel/ptrace.c - 1.2 arch/sparc/kernel/rtrap.S - 1.2 arch/sparc/kernel/setup.c - 1.2 arch/sparc/kernel/signal.c - 1.2 arch/sparc/kernel/sun4d_irq.c - 1.2 arch/sparc/kernel/traps.c - 1.2 arch/sparc/kernel/windows.c - 1.2 arch/sparc/kernel/wof.S - 1.2 arch/sparc/kernel/wuf.S - 1.2 arch/sparc/mm/fault.c - 1.2 arch/sparc/mm/highmem.c - 1.2 arch/sparc/mm/init.c - 1.2 arch/sparc/mm/io-unit.c - 1.2 arch/sparc/mm/iommu.c - 1.2 arch/sparc/mm/srmmu.c - 1.2 arch/sparc/mm/sun4c.c - 1.2 arch/sparc64/Kconfig - 1.2 arch/sparc64/defconfig - 1.2 arch/sparc64/kernel/ebus.c - 1.2 arch/sparc64/kernel/irq.c - 1.2 arch/sparc64/kernel/pci_sabre.c - 1.2 arch/sparc64/kernel/setup.c - 1.2 arch/sparc64/kernel/sparc64_ksyms.c - 1.2 arch/sparc64/kernel/systbls.S - 1.2 arch/sparc64/mm/hugetlbpage.c - 1.2 arch/um/kernel/irq.c - 1.2 arch/v850/kernel/irq.c - 1.2 arch/x86_64/Kconfig - 1.2 arch/x86_64/boot/install.sh - 1.2 arch/x86_64/defconfig - 1.2 arch/x86_64/ia32/Makefile - 1.2 arch/x86_64/ia32/ia32_ioctl.c - 1.2 arch/x86_64/ia32/ia32_signal.c - 1.2 arch/x86_64/ia32/ia32entry.S - 1.2 arch/x86_64/ia32/sys_ia32.c - 1.2 arch/x86_64/ia32/syscall32.c - 1.2 arch/x86_64/kernel/Makefile - 1.2 arch/x86_64/kernel/apic.c - 1.2 arch/x86_64/kernel/bluesmoke.c - 1.2 arch/x86_64/kernel/e820.c - 1.2 arch/x86_64/kernel/head.S - 1.2 arch/x86_64/kernel/i8259.c - 1.2 arch/x86_64/kernel/io_apic.c - 1.2 arch/x86_64/kernel/irq.c - 1.2 arch/x86_64/kernel/mpparse.c - 1.2 arch/x86_64/kernel/pci-gart.c - 1.2 arch/x86_64/kernel/pci-nommu.c - 1.2 arch/x86_64/kernel/process.c - 1.2 arch/x86_64/kernel/setup.c - 1.2 arch/x86_64/kernel/signal.c - 1.2 arch/x86_64/kernel/time.c - 1.2 arch/x86_64/kernel/traps.c - 1.2 arch/x86_64/kernel/vsyscall.c - 1.2 arch/x86_64/lib/memset.S - 1.2 arch/x86_64/mm/fault.c - 1.2 crypto/tcrypt.c - 1.2 crypto/tcrypt.h - 1.2 drivers/acorn/char/i2c.c - 1.2 drivers/acpi/Kconfig - 1.2 drivers/acpi/osl.c - 1.2 drivers/acpi/pci_irq.c - 1.2 drivers/base/firmware_class.c - 1.2 drivers/base/node.c - 1.2 drivers/base/platform.c - 1.2 drivers/base/power/sysfs.c - 1.2 drivers/block/DAC960.c - 1.2 drivers/block/DAC960.h - 1.2 drivers/block/floppy.c - 1.2 drivers/block/floppy98.c - 1.2 drivers/block/genhd.c - 1.2 drivers/block/ll_rw_blk.c - 1.2 drivers/char/agp/alpha-agp.c - 1.2 drivers/char/agp/amd64-agp.c - 1.2 drivers/char/agp/ati-agp.c - 1.2 drivers/char/agp/generic.c - 1.2 drivers/char/agp/intel-agp.c - 1.2 drivers/char/agp/nvidia-agp.c - 1.2 drivers/char/drm/drmP.h - 1.2 drivers/char/drm/drm_vm.h - 1.2 drivers/char/drm/ffb_drv.c - 1.2 drivers/char/keyboard.c - 1.2 drivers/char/ppdev.c - 1.2 drivers/char/sx.c - 1.2 drivers/char/vt_ioctl.c - 1.2 drivers/char/watchdog/Kconfig - 1.2 drivers/char/watchdog/Makefile - 1.2 drivers/char/watchdog/i810-tco.c - 1.2 drivers/char/watchdog/ib700wdt.c - 1.2 drivers/char/watchdog/indydog.c - 1.2 drivers/char/watchdog/machzwd.c - 1.2 drivers/char/watchdog/mixcomwd.c - 1.2 drivers/char/watchdog/pcwd.c - 1.2 drivers/char/watchdog/sa1100_wdt.c - 1.2 drivers/char/watchdog/softdog.c - 1.2 drivers/char/watchdog/wdt.c - 1.2 drivers/cpufreq/Kconfig - 1.2 drivers/fc4/fc.c - 1.2 drivers/i2c/algos/i2c-algo-bit.c - 1.2 drivers/i2c/algos/i2c-algo-ite.c - 1.2 drivers/i2c/busses/Kconfig - 1.2 drivers/i2c/busses/i2c-amd756.c - 1.2 drivers/i2c/busses/i2c-amd8111.c - 1.2 drivers/i2c/busses/i2c-ibm_iic.c - 1.2 drivers/i2c/busses/i2c-piix4.c - 1.2 drivers/i2c/busses/i2c-savage4.c - 1.2 drivers/i2c/busses/i2c-velleman.c - 1.2 drivers/i2c/busses/i2c-viapro.c - 1.2 drivers/i2c/chips/Kconfig - 1.2 drivers/i2c/chips/Makefile - 1.2 drivers/i2c/chips/it87.c - 1.2 drivers/i2c/chips/lm75.c - 1.2 drivers/i2c/chips/lm78.c - 1.2 drivers/i2c/chips/via686a.c - 1.2 drivers/i2c/chips/w83781d.c - 1.2 drivers/i2c/i2c-core.c - 1.2 drivers/i2c/i2c-dev.c - 1.2 drivers/ide/Kconfig - 1.2 drivers/ide/arm/icside.c - 1.2 drivers/ide/ide-cd.c - 1.2 drivers/ide/ide-dma.c - 1.2 drivers/ide/ide-io.c - 1.2 drivers/ide/ide-iops.c - 1.2 drivers/ide/ide-tape.c - 1.2 drivers/ide/ide.c - 1.2 drivers/ide/pci/Makefile - 1.2 drivers/ide/pci/cmd640.c - 1.2 drivers/ide/pci/piix.c - 1.2 drivers/ide/setup-pci.c - 1.2 drivers/ieee1394/Kconfig - 1.2 drivers/ieee1394/dma.c - 1.2 drivers/ieee1394/eth1394.c - 1.2 drivers/ieee1394/highlevel.c - 1.2 drivers/ieee1394/highlevel.h - 1.2 drivers/ieee1394/hosts.c - 1.2 drivers/ieee1394/hosts.h - 1.2 drivers/ieee1394/ieee1394_core.c - 1.2 drivers/ieee1394/ieee1394_core.h - 1.2 drivers/ieee1394/ieee1394_transactions.c - 1.2 drivers/ieee1394/iso.c - 1.2 drivers/ieee1394/iso.h - 1.2 drivers/ieee1394/nodemgr.c - 1.2 drivers/ieee1394/nodemgr.h - 1.2 drivers/ieee1394/ohci1394.c - 1.2 drivers/ieee1394/oui.db - 1.2 drivers/ieee1394/pcilynx.c - 1.2 drivers/ieee1394/raw1394.c - 1.2 drivers/ieee1394/raw1394.h - 1.2 drivers/ieee1394/sbp2.c - 1.2 drivers/ieee1394/video1394.c - 1.2 drivers/input/gameport/Kconfig - 1.2 drivers/input/input.c - 1.2 drivers/input/joydev.c - 1.2 drivers/input/keyboard/atkbd.c - 1.2 drivers/input/mouse/Kconfig - 1.2 drivers/input/mouse/logips2pp.c - 1.2 drivers/input/mouse/logips2pp.h - 1.2 drivers/input/mouse/psmouse-base.c - 1.2 drivers/input/mouse/psmouse.h - 1.2 drivers/input/mouse/synaptics.c - 1.2 drivers/input/mouse/synaptics.h - 1.2 drivers/input/serio/i8042.c - 1.2 drivers/input/serio/serio.c - 1.2 drivers/isdn/eicon/Kconfig - 1.2 drivers/isdn/eicon/eicon_mod.c - 1.2 drivers/isdn/i4l/isdn_ppp_ccp.c - 1.2 drivers/md/Kconfig - 1.2 drivers/md/dm-ioctl-v1.c - 1.2 drivers/md/dm-ioctl-v4.c - 1.2 drivers/md/dm-table.c - 1.2 drivers/md/dm.c - 1.2 drivers/md/dm.h - 1.2 drivers/md/linear.c - 1.2 drivers/md/multipath.c - 1.2 drivers/md/raid0.c - 1.2 drivers/md/raid1.c - 1.2 drivers/md/raid5.c - 1.2 drivers/media/common/saa7146_core.c - 1.2 drivers/media/common/saa7146_fops.c - 1.2 drivers/media/common/saa7146_hlp.c - 1.2 drivers/media/common/saa7146_i2c.c - 1.2 drivers/media/common/saa7146_vbi.c - 1.2 drivers/media/common/saa7146_video.c - 1.2 drivers/media/dvb/Kconfig - 1.2 drivers/media/dvb/Makefile - 1.2 drivers/media/dvb/b2c2/skystar2.c - 1.2 drivers/media/dvb/dvb-core/demux.h - 1.2 drivers/media/dvb/dvb-core/dvb_demux.c - 1.2 drivers/media/dvb/dvb-core/dvb_demux.h - 1.2 drivers/media/dvb/dvb-core/dvb_filter.c - 1.2 drivers/media/dvb/dvb-core/dvb_filter.h - 1.2 drivers/media/dvb/dvb-core/dvb_i2c.c - 1.2 drivers/media/dvb/dvb-core/dvb_ksyms.c - 1.2 drivers/media/dvb/dvb-core/dvb_ringbuffer.c - 1.2 drivers/media/dvb/dvb-core/dvb_ringbuffer.h - 1.2 drivers/media/dvb/frontends/Kconfig - 1.2 drivers/media/dvb/frontends/Makefile - 1.2 drivers/media/dvb/frontends/alps_tdmb7.c - 1.2 drivers/media/dvb/frontends/at76c651.c - 1.2 drivers/media/dvb/frontends/cx24110.c - 1.2 drivers/media/dvb/frontends/mt312.c - 1.2 drivers/media/dvb/frontends/mt312.h - 1.2 drivers/media/dvb/frontends/nxt6000.c - 1.2 drivers/media/dvb/frontends/nxt6000.h - 1.2 drivers/media/dvb/frontends/sp887x.c - 1.2 drivers/media/dvb/frontends/stv0299.c - 1.2 drivers/media/dvb/frontends/tda1004x.c - 1.2 drivers/media/dvb/frontends/ves1820.c - 1.2 drivers/media/dvb/frontends/ves1x93.c - 1.2 drivers/media/dvb/ttpci/Kconfig - 1.2 drivers/media/dvb/ttpci/Makefile - 1.2 drivers/media/dvb/ttpci/av7110.c - 1.2 drivers/media/dvb/ttpci/av7110.h - 1.2 drivers/media/dvb/ttpci/budget-ci.c - 1.2 drivers/media/dvb/ttpci/budget.h - 1.2 drivers/media/dvb/ttpci/ttpci-eeprom.c - 1.2 drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c - 1.2 drivers/media/dvb/ttusb-dec/Kconfig - 1.2 drivers/media/dvb/ttusb-dec/Makefile - 1.2 drivers/media/dvb/ttusb-dec/ttusb_dec.c - 1.2 drivers/media/video/video-buf.c - 1.2 drivers/message/fusion/isense.c - 1.2 drivers/message/fusion/mptbase.c - 1.2 drivers/message/fusion/mptbase.h - 1.2 drivers/message/fusion/mptctl.c - 1.2 drivers/message/fusion/mptctl.h - 1.2 drivers/message/fusion/mptlan.c - 1.2 drivers/message/fusion/mptscsih.c - 1.2 drivers/message/fusion/mptscsih.h - 1.2 drivers/message/fusion/scsi3.h - 1.2 drivers/mtd/chips/jedec_probe.c - 1.2 drivers/mtd/maps/sun_uflash.c - 1.2 drivers/net/8139too.c - 1.2 drivers/net/Space.c - 1.2 drivers/net/bonding/bond_main.c - 1.2 drivers/net/cs89x0.c - 1.2 drivers/net/e100/e100_config.c - 1.2 drivers/net/e100/e100_main.c - 1.2 drivers/net/e100/e100_phy.c - 1.2 drivers/net/hamradio/scc.c - 1.2 drivers/net/irda/ali-ircc.c - 1.2 drivers/net/pcmcia/3c574_cs.c - 1.2 drivers/net/pcmcia/pcnet_cs.c - 1.2 drivers/net/pppoe.c - 1.2 drivers/net/sis900.c - 1.2 drivers/net/tg3.c - 1.2 drivers/net/tokenring/Kconfig - 1.2 drivers/net/typhoon.c - 1.2 drivers/net/wan/Kconfig - 1.2 drivers/net/wan/cycx_drv.c - 1.2 drivers/net/wireless/atmel.c - 1.2 drivers/parisc/Kconfig - 1.2 drivers/parisc/ccio-dma.c - 1.2 drivers/parisc/dino.c - 1.2 drivers/parisc/led.c - 1.2 drivers/parisc/superio.c - 1.2 drivers/parport/parport_sunbpp.c - 1.2 drivers/pci/Makefile - 1.2 drivers/pci/pci.ids - 1.2 drivers/pci/probe.c - 1.2 drivers/pci/proc.c - 1.2 drivers/pci/remove.c - 1.2 drivers/pci/setup-res.c - 1.2 drivers/pcmcia/cistpl.c - 1.2 drivers/pcmcia/cs.c - 1.2 drivers/pcmcia/i82365.c - 1.2 drivers/pcmcia/sa1100_stork.c - 1.2 drivers/pcmcia/yenta_socket.c - 1.2 drivers/pnp/pnpbios/bioscalls.c - 1.2 drivers/sbus/char/bpp.c - 1.2 drivers/sbus/char/vfc_dev.c - 1.2 drivers/scsi/BusLogic.c - 1.2 drivers/scsi/Kconfig - 1.2 drivers/scsi/aacraid/README - 1.2 drivers/scsi/aacraid/aachba.c - 1.2 drivers/scsi/aacraid/aacraid.h - 1.2 drivers/scsi/aacraid/commctrl.c - 1.2 drivers/scsi/aacraid/comminit.c - 1.2 drivers/scsi/aacraid/commsup.c - 1.2 drivers/scsi/aacraid/dpcsup.c - 1.2 drivers/scsi/aacraid/linit.c - 1.2 drivers/scsi/aacraid/rx.c - 1.2 drivers/scsi/aacraid/sa.c - 1.2 drivers/scsi/aha152x.c - 1.2 drivers/scsi/aha1740.c - 1.2 drivers/scsi/aic7xxx/Kconfig.aic7xxx - 1.2 drivers/scsi/aic7xxx/Makefile - 1.2 drivers/scsi/aic7xxx/aic7770.c - 1.2 drivers/scsi/aic7xxx/aic7770_osm.c - 1.2 drivers/scsi/aic7xxx/aic79xx.h - 1.2 drivers/scsi/aic7xxx/aic79xx.reg - 1.2 drivers/scsi/aic7xxx/aic79xx.seq - 1.2 drivers/scsi/aic7xxx/aic79xx_core.c - 1.2 drivers/scsi/aic7xxx/aic79xx_inline.h - 1.2 drivers/scsi/aic7xxx/aic79xx_osm.c - 1.2 drivers/scsi/aic7xxx/aic79xx_osm.h - 1.2 drivers/scsi/aic7xxx/aic79xx_osm_pci.c - 1.2 drivers/scsi/aic7xxx/aic79xx_pci.c - 1.2 drivers/scsi/aic7xxx/aic79xx_proc.c - 1.2 drivers/scsi/aic7xxx/aic79xx_reg.h_shipped - 1.2 drivers/scsi/aic7xxx/aic79xx_reg_print.c_shipped - 1.2 drivers/scsi/aic7xxx/aic79xx_seq.h_shipped - 1.2 drivers/scsi/aic7xxx/aic7xxx.h - 1.2 drivers/scsi/aic7xxx/aic7xxx_core.c - 1.2 drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.2 drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.2 drivers/scsi/aic7xxx/aic7xxx_osm_pci.c - 1.2 drivers/scsi/aic7xxx/aic7xxx_pci.c - 1.2 drivers/scsi/aic7xxx/aic7xxx_proc.c - 1.2 drivers/scsi/aic7xxx/aic7xxx_reg_print.c_shipped - 1.2 drivers/scsi/aic7xxx/aicasm/aicasm_macro_scan.l - 1.2 drivers/scsi/aic7xxx/aicasm/aicasm_scan.l - 1.2 drivers/scsi/ata_piix.c - 1.2 drivers/scsi/cpqfcTSinit.c - 1.2 drivers/scsi/dc390.h - 1.2 drivers/scsi/esp.c - 1.2 drivers/scsi/fcal.c - 1.2 drivers/scsi/hosts.c - 1.2 drivers/scsi/i60uscsi.c - 1.2 drivers/scsi/ini9100u.c - 1.2 drivers/scsi/inia100.c - 1.2 drivers/scsi/inia100.h - 1.2 drivers/scsi/libata-core.c - 1.2 drivers/scsi/libata-scsi.c - 1.2 drivers/scsi/libata.h - 1.2 drivers/scsi/megaraid.c - 1.2 drivers/scsi/megaraid.h - 1.2 drivers/scsi/osst.c - 1.2 drivers/scsi/osst.h - 1.2 drivers/scsi/osst_options.h - 1.2 drivers/scsi/pcmcia/Kconfig - 1.2 drivers/scsi/pluto.c - 1.2 drivers/scsi/qlogicpti.c - 1.2 drivers/scsi/sata_promise.c - 1.2 drivers/scsi/sata_sil.c - 1.2 drivers/scsi/sata_svw.c - 1.2 drivers/scsi/sata_via.c - 1.2 drivers/scsi/scsi.c - 1.2 drivers/scsi/scsi_debug.c - 1.2 drivers/scsi/scsi_error.c - 1.2 drivers/scsi/scsi_logging.h - 1.2 drivers/scsi/scsi_priv.h - 1.2 drivers/scsi/scsiiom.c - 1.2 drivers/scsi/sg.c - 1.2 drivers/scsi/st.c - 1.2 drivers/scsi/st.h - 1.2 drivers/scsi/sym53c8xx_2/sym53c8xx.h - 1.2 drivers/scsi/sym53c8xx_2/sym_fw.c - 1.2 drivers/scsi/sym53c8xx_2/sym_fw.h - 1.2 drivers/scsi/sym53c8xx_2/sym_fw1.h - 1.2 drivers/scsi/sym53c8xx_2/sym_fw2.h - 1.2 drivers/scsi/sym53c8xx_2/sym_glue.c - 1.2 drivers/scsi/sym53c8xx_2/sym_glue.h - 1.2 drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.2 drivers/scsi/sym53c8xx_2/sym_hipd.h - 1.2 drivers/scsi/sym53c8xx_2/sym_malloc.c - 1.2 drivers/scsi/sym53c8xx_2/sym_nvram.c - 1.2 drivers/scsi/tmscsim.c - 1.2 drivers/scsi/tmscsim.h - 1.2 drivers/serial/8250.c - 1.2 drivers/serial/8250_pnp.c - 1.2 drivers/serial/sa1100.c - 1.2 drivers/serial/serial_core.c - 1.2 drivers/serial/sunsu.c - 1.2 drivers/serial/sunzilog.c - 1.2 drivers/usb/Makefile - 1.2 drivers/usb/class/audio.h - 1.2 drivers/usb/class/cdc-acm.c - 1.2 drivers/usb/class/usb-midi.h - 1.2 drivers/usb/class/usblp.c - 1.2 drivers/usb/core/hcd.c - 1.2 drivers/usb/core/hub.c - 1.2 drivers/usb/core/hub.h - 1.2 drivers/usb/core/message.c - 1.2 drivers/usb/core/usb.c - 1.2 drivers/usb/gadget/ether.c - 1.2 drivers/usb/gadget/zero.c - 1.2 drivers/usb/host/ohci-dbg.c - 1.2 drivers/usb/host/ohci-hcd.c - 1.2 drivers/usb/host/ohci-q.c - 1.2 drivers/usb/host/ohci.h - 1.2 drivers/usb/host/uhci-hcd.c - 1.2 drivers/usb/image/scanner.c - 1.2 drivers/usb/image/scanner.h - 1.2 drivers/usb/input/hid-core.c - 1.2 drivers/usb/input/hiddev.c - 1.2 drivers/usb/media/Kconfig - 1.2 drivers/usb/media/Makefile - 1.2 drivers/usb/media/pwc-ctrl.c - 1.2 drivers/usb/media/pwc-if.c - 1.2 drivers/usb/media/pwc-ioctl.h - 1.2 drivers/usb/media/pwc-misc.c - 1.2 drivers/usb/media/pwc.h - 1.2 drivers/usb/misc/Kconfig - 1.2 drivers/usb/misc/Makefile - 1.2 drivers/usb/net/Kconfig - 1.2 drivers/usb/net/pegasus.h - 1.2 drivers/usb/net/usbnet.c - 1.2 drivers/usb/serial/cyberjack.c - 1.2 drivers/usb/serial/ftdi_sio.c - 1.2 drivers/usb/serial/ftdi_sio.h - 1.2 drivers/usb/serial/io_edgeport.c - 1.2 drivers/usb/serial/io_fw_boot.h - 1.2 drivers/usb/serial/io_fw_boot2.h - 1.2 drivers/usb/serial/io_fw_down.h - 1.2 drivers/usb/serial/io_fw_down2.h - 1.2 drivers/usb/serial/mct_u232.c - 1.2 drivers/usb/serial/mct_u232.h - 1.2 drivers/usb/serial/pl2303.c - 1.2 drivers/usb/serial/pl2303.h - 1.2 drivers/usb/serial/visor.c - 1.2 drivers/usb/serial/visor.h - 1.2 drivers/usb/storage/Makefile - 1.2 drivers/usb/storage/datafab.c - 1.2 drivers/usb/storage/debug.c - 1.2 drivers/usb/storage/debug.h - 1.2 drivers/usb/storage/isd200.c - 1.2 drivers/usb/storage/jumpshot.c - 1.2 drivers/usb/storage/protocol.c - 1.2 drivers/usb/storage/protocol.h - 1.2 drivers/usb/storage/scsiglue.c - 1.2 drivers/usb/storage/sddr09.c - 1.2 drivers/usb/storage/sddr55.c - 1.2 drivers/usb/storage/shuttle_usbat.c - 1.2 drivers/usb/storage/transport.c - 1.2 drivers/usb/storage/unusual_devs.h - 1.2 drivers/usb/storage/usb.c - 1.2 drivers/video/cirrusfb.c - 1.2 drivers/video/fbmon.c - 1.2 drivers/video/hgafb.c - 1.2 drivers/video/sis/init301.c - 1.2 fs/Kconfig - 1.2 fs/Kconfig.binfmt - 1.2 fs/binfmt_elf.c - 1.2 fs/binfmt_som.c - 1.2 fs/buffer.c - 1.2 fs/char_dev.c - 1.2 fs/compat.c - 1.2 fs/compat_ioctl.c - 1.2 fs/dcache.c - 1.2 fs/direct-io.c - 1.2 fs/dquot.c - 1.2 fs/exec.c - 1.2 fs/ext3/balloc.c - 1.2 fs/ext3/super.c - 1.2 fs/fat/file.c - 1.2 fs/fat/inode.c - 1.2 fs/fat/misc.c - 1.2 fs/file_table.c - 1.2 fs/isofs/inode.c - 1.2 fs/jbd/commit.c - 1.2 fs/jfs/jfs_imap.c - 1.2 fs/jfs/namei.c - 1.2 fs/locks.c - 1.2 fs/msdos/namei.c - 1.2 fs/ncpfs/Kconfig - 1.2 fs/ncpfs/mmap.c - 1.2 fs/nls/Kconfig - 1.2 fs/nls/nls_base.c - 1.2 fs/pipe.c - 1.2 fs/proc/base.c - 1.2 fs/proc/generic.c - 1.2 fs/proc/proc_misc.c - 1.2 fs/proc/proc_tty.c - 1.2 fs/proc/task_mmu.c - 1.2 fs/reiserfs/journal.c - 1.2 fs/reiserfs/namei.c - 1.2 fs/reiserfs/procfs.c - 1.2 fs/reiserfs/super.c - 1.2 fs/stat.c - 1.2 fs/sysfs/dir.c - 1.2 fs/udf/super.c - 1.2 fs/vfat/namei.c - 1.2 include/asm-arm/arch-ebsa285/time.h - 1.2 include/asm-arm/arch-pxa/time.h - 1.2 include/asm-arm/arch-sa1100/time.h - 1.2 include/asm-arm/arch-shark/time.h - 1.2 include/asm-arm/div64.h - 1.2 include/asm-arm/kmap_types.h - 1.2 include/asm-arm/pgtable.h - 1.2 include/asm-arm/unaligned.h - 1.2 include/asm-arm/unistd.h - 1.2 include/asm-generic/cpumask_arith.h - 1.2 include/asm-generic/cpumask_array.h - 1.2 include/asm-generic/cpumask_const_value.h - 1.2 include/asm-generic/cpumask_up.h - 1.2 include/asm-generic/sections.h - 1.2 include/asm-generic/statfs.h - 1.2 include/asm-h8300/bitops.h - 1.2 include/asm-i386/hw_irq.h - 1.2 include/asm-i386/io_apic.h - 1.2 include/asm-i386/ioctl.h - 1.2 include/asm-i386/irq.h - 1.2 include/asm-i386/mach-default/irq_vectors.h - 1.2 include/asm-i386/mach-default/mach_apic.h - 1.2 include/asm-i386/mach-es7000/mach_apic.h - 1.2 include/asm-i386/mach-pc9800/irq_vectors.h - 1.2 include/asm-i386/mach-summit/mach_mpparse.h - 1.2 include/asm-i386/mach-visws/irq_vectors.h - 1.2 include/asm-i386/mach-voyager/irq_vectors.h - 1.2 include/asm-i386/mpspec.h - 1.2 include/asm-i386/processor.h - 1.2 include/asm-i386/setup.h - 1.2 include/asm-i386/string.h - 1.2 include/asm-i386/timer.h - 1.2 include/asm-ia64/acpi.h - 1.2 include/asm-ia64/ia32.h - 1.2 include/asm-ia64/intrinsics.h - 1.2 include/asm-ia64/mca.h - 1.2 include/asm-ia64/mmu_context.h - 1.2 include/asm-ia64/numa.h - 1.2 include/asm-ia64/numnodes.h - 1.2 include/asm-ia64/page.h - 1.2 include/asm-ia64/pal.h - 1.2 include/asm-ia64/pgtable.h - 1.2 include/asm-ia64/processor.h - 1.2 include/asm-ia64/sal.h - 1.2 include/asm-ia64/spinlock.h - 1.2 include/asm-ia64/statfs.h - 1.2 include/asm-ia64/system.h - 1.2 include/asm-ia64/uaccess.h - 1.2 include/asm-mips/statfs.h - 1.2 include/asm-parisc/dma-mapping.h - 1.2 include/asm-parisc/ioctl.h - 1.2 include/asm-parisc/statfs.h - 1.2 include/asm-parisc/uaccess.h - 1.2 include/asm-parisc/ucontext.h - 1.2 include/asm-parisc/unistd.h - 1.2 include/asm-ppc/highmem.h - 1.2 include/asm-ppc/ioctl.h - 1.2 include/asm-ppc64/ioctl.h - 1.2 include/asm-ppc64/page.h - 1.2 include/asm-ppc64/statfs.h - 1.2 include/asm-s390/ccwdev.h - 1.2 include/asm-s390/statfs.h - 1.2 include/asm-sparc/highmem.h - 1.2 include/asm-sparc/kmap_types.h - 1.2 include/asm-sparc/page.h - 1.2 include/asm-sparc/pgtsrmmu.h - 1.2 include/asm-sparc/processor.h - 1.2 include/asm-sparc/thread_info.h - 1.2 include/asm-sparc/vaddrs.h - 1.2 include/asm-sparc/winmacro.h - 1.2 include/asm-sparc64/pgtable.h - 1.2 include/asm-sparc64/statfs.h - 1.2 include/asm-x86_64/a.out.h - 1.2 include/asm-x86_64/acpi.h - 1.2 include/asm-x86_64/bitops.h - 1.2 include/asm-x86_64/calling.h - 1.2 include/asm-x86_64/hw_irq.h - 1.2 include/asm-x86_64/io.h - 1.2 include/asm-x86_64/io_apic.h - 1.2 include/asm-x86_64/irq.h - 1.2 include/asm-x86_64/pgtable.h - 1.2 include/asm-x86_64/smp.h - 1.2 include/asm-x86_64/stat.h - 1.2 include/asm-x86_64/statfs.h - 1.2 include/asm-x86_64/system.h - 1.2 include/asm-x86_64/unistd.h - 1.2 include/linux/bio.h - 1.2 include/linux/blkdev.h - 1.2 include/linux/compat.h - 1.2 include/linux/compat_ioctl.h - 1.2 include/linux/console.h - 1.2 include/linux/cpufreq.h - 1.2 include/linux/cpumask.h - 1.2 include/linux/device.h - 1.2 include/linux/efi.h - 1.2 include/linux/fs.h - 1.2 include/linux/hugetlb.h - 1.2 include/linux/i2c-dev.h - 1.2 include/linux/i2c-id.h - 1.2 include/linux/ide.h - 1.2 include/linux/input.h - 1.2 include/linux/ip.h - 1.2 include/linux/ipv6.h - 1.2 include/linux/jiffies.h - 1.2 include/linux/kernel.h - 1.2 include/linux/keyboard.h - 1.2 include/linux/kmod.h - 1.2 include/linux/libata.h - 1.2 include/linux/list.h - 1.2 include/linux/mm.h - 1.2 include/linux/mmzone.h - 1.2 include/linux/msdos_fs.h - 1.2 include/linux/msdos_fs_sb.h - 1.2 include/linux/nbd.h - 1.2 include/linux/netdevice.h - 1.2 include/linux/netfilter_bridge.h - 1.2 include/linux/netfilter_ipv4.h - 1.2 include/linux/netfilter_ipv6.h - 1.2 include/linux/page-flags.h - 1.2 include/linux/pagemap.h - 1.2 include/linux/parser.h - 1.2 include/linux/pci.h - 1.2 include/linux/pci_ids.h - 1.2 include/linux/percpu_counter.h - 1.2 include/linux/proc_fs.h - 1.2 include/linux/quota.h - 1.2 include/linux/reiserfs_fs.h - 1.2 include/linux/sched.h - 1.2 include/linux/serio.h - 1.2 include/linux/skbuff.h - 1.2 include/linux/sysctl.h - 1.2 include/linux/tcp.h - 1.2 include/linux/udp.h - 1.2 include/linux/usb.h - 1.2 include/linux/usb_ch9.h - 1.2 include/linux/usb_gadget.h - 1.2 include/linux/videodev.h - 1.2 include/media/saa7146.h - 1.2 include/media/saa7146_vv.h - 1.2 include/net/ax25.h - 1.2 include/net/ipv6.h - 1.2 include/net/irda/ircomm_tty.h - 1.2 include/net/pkt_cls.h - 1.2 include/net/sctp/sctp.h - 1.2 include/net/sock.h - 1.2 include/net/xfrm.h - 1.2 include/scsi/scsi.h - 1.2 init/Kconfig - 1.2 init/do_mounts.c - 1.2 init/main.c - 1.2 ipc/sem.c - 1.2 kernel/compat.c - 1.2 kernel/exit.c - 1.2 kernel/fork.c - 1.2 kernel/futex.c - 1.2 kernel/kmod.c - 1.2 kernel/module.c - 1.2 kernel/power/Kconfig - 1.2 kernel/power/swsusp.c - 1.2 kernel/printk.c - 1.2 kernel/sched.c - 1.2 kernel/sys.c - 1.2 lib/Makefile - 1.2 lib/inflate.c - 1.2 lib/parser.c - 1.2 mm/filemap.c - 1.2 mm/highmem.c - 1.2 mm/memory.c - 1.2 mm/mmap.c - 1.2 mm/mremap.c - 1.2 mm/oom_kill.c - 1.2 mm/page_alloc.c - 1.2 mm/readahead.c - 1.2 mm/shmem.c - 1.2 mm/slab.c - 1.2 mm/swap.c - 1.2 mm/vmscan.c - 1.2 net/appletalk/sysctl_net_atalk.c - 1.2 net/ax25/af_ax25.c - 1.2 net/ax25/ax25_in.c - 1.2 net/bluetooth/af_bluetooth.c - 1.2 net/bluetooth/bnep/core.c - 1.2 net/bridge/br_netfilter.c - 1.2 net/bridge/netfilter/Kconfig - 1.2 net/compat.c - 1.2 net/core/dev.c - 1.2 net/core/neighbour.c - 1.2 net/core/sock.c - 1.2 net/core/sysctl_net_core.c - 1.2 net/decnet/af_decnet.c - 1.2 net/ipv4/ip_output.c - 1.2 net/ipv4/netfilter/ipt_recent.c - 1.2 net/ipv6/addrconf.c - 1.2 net/ipv6/ip6_output.c - 1.2 net/ipv6/ip6_tunnel.c - 1.2 net/ipv6/ndisc.c - 1.2 net/irda/ircomm/ircomm_tty.c - 1.2 net/netrom/af_netrom.c - 1.2 net/netrom/nr_dev.c - 1.2 net/packet/af_packet.c - 1.2 net/rose/af_rose.c - 1.2 net/sched/cls_api.c - 1.2 net/sched/sch_atm.c - 1.2 net/sched/sch_cbq.c - 1.2 net/sched/sch_csz.c - 1.2 net/sched/sch_dsmark.c - 1.2 net/sched/sch_htb.c - 1.2 net/sched/sch_ingress.c - 1.2 net/sched/sch_prio.c - 1.2 net/sched/sch_tbf.c - 1.2 net/sctp/associola.c - 1.2 net/sctp/outqueue.c - 1.2 net/sctp/socket.c - 1.2 net/sctp/transport.c - 1.2 net/xfrm/xfrm_policy.c - 1.2 net/xfrm/xfrm_state.c - 1.2 scripts/kconfig/conf.c - 1.2 scripts/kconfig/gconf.c - 1.2 scripts/kconfig/mconf.c - 1.2 scripts/kconfig/qconf.cc - 1.2 scripts/mkspec - 1.2 scripts/modpost.c - 1.2 security/selinux/hooks.c - 1.2 security/selinux/include/av_perm_to_string.h - 1.2 security/selinux/include/av_permissions.h - 1.2 security/selinux/ss/Makefile - 1.2 security/selinux/ss/avtab.c - 1.2 security/selinux/ss/ebitmap.c - 1.2 security/selinux/ss/hashtab.c - 1.2 security/selinux/ss/mls.c - 1.2 security/selinux/ss/policydb.c - 1.2 security/selinux/ss/services.c - 1.2 security/selinux/ss/sidtab.c - 1.2 security/selinux/ss/symtab.c - 1.2 sound/core/pcm_native.c - 1.2 sound/core/sound.c - 1.2 sound/oss/Kconfig - 1.2 sound/oss/au1000.c - 1.2 sound/oss/cmpci.c - 1.2 sound/oss/cs4281/cs4281m.c - 1.2 sound/oss/cs46xx.c - 1.2 sound/oss/dmasound/Kconfig - 1.2 sound/oss/emu10k1/audio.c - 1.2 sound/oss/es1370.c - 1.2 sound/oss/es1371.c - 1.2 sound/oss/esssolo1.c - 1.2 sound/oss/ite8172.c - 1.2 sound/oss/nec_vrc5477.c - 1.2 sound/oss/rme96xx.c - 1.2 sound/oss/sonicvibes.c - 1.2 sound/oss/via82cxxx_audio.c - 1.2 sound/oss/vidc.c - 1.2 sound/oss/vwsnd.c - 1.2 sound/sound_core.c - 1.2 sound/usb/usbaudio.h - 1.2 usr/gen_init_cpio.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jan 12 18:37:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 18:37: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 i0D2bf6H024379 for ; Mon, 12 Jan 2004 18:37: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 i0D3ujAY027279 for ; Mon, 12 Jan 2004 21:56: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 i0D2agvg29231896; Mon, 12 Jan 2004 20:36:42 -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 i0D2aQK213603026; Mon, 12 Jan 2004 20:36:36 -0600 (CST) Date: Mon, 12 Jan 2004 20:36:26 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Kelsey Cummings cc: linux-xfs@oss.sgi.com Subject: Re: large file problems with 2.4.25-pre4 In-Reply-To: <20040112233619.GF98119@sonic.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1712 X-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: 939 Lines: 24 The problem is probably a current bug with large allocation groups in the filesystem; try re-mkfs'ing with -d agsize=4g and see if the problem goes away. I hope(!) to check in a fix for this in the next day or two (the fix is in kernelspace, and does not affect on-disk xfs format). -Eric On Mon, 12 Jan 2004, Kelsey Cummings wrote: > I'm new to using xfs, so please forgive me if I'm missing somehting > obvious. I've heard good things about xfs' performance, and I have to > admit I'm quite impressed with what I've seen so far. However, I've run > into some confusing problems. > > With all of the XFS kernels I've build (2.4.24-pre1, 2.4.25-pre4) I've had > trouble creating large files. > > dd if=/dev/zero of=/mnt/blah bs=1024k count=10000 > > locks up at app 6gigs with bdflush and kswapd consumming all available CPU. > Once this occurs any thing attempting to access the filesystem gets stuck > waiting on the kernel. From owner-linux-xfs@oss.sgi.com Mon Jan 12 18:40:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 18:40: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 i0D2eH6H024834 for ; Mon, 12 Jan 2004 18:40: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 i0D3xLAY028599 for ; Mon, 12 Jan 2004 21:59:21 -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 i0D2e6vg29217162; Mon, 12 Jan 2004 20:40: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 i0D2dpK213602152; Mon, 12 Jan 2004 20:40:01 -0600 (CST) Date: Mon, 12 Jan 2004 20:39:51 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Kelsey Cummings cc: Nathan Scott , Subject: Re: [LNX-XFS] Re: large file problems with 2.4.25-pre4 In-Reply-To: <20040113005150.GL98119@sonic.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1713 X-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: 519 Lines: 22 On Mon, 12 Jan 2004, Kelsey Cummings wrote: > > > If you consistently see lockups, your best bet is to drop > > into kdb and start with backtraces on the stuck processes. > > Aie, I'm afraid I don't have that kind of foo. :) That's not too hard, if you have kdb in your kernel & config'd on (kdb comes with the cvs code) just hit "pause" on the console, or ctl-A on the serial port. Then: kdb> ps to get a list of processes, look for the stuck dd process, then: kdb> btp for the correct pid nr. -Eric From owner-linux-xfs@oss.sgi.com Mon Jan 12 19:16:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 19:16: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 i0D3GA6H026336 for ; Mon, 12 Jan 2004 19:16:10 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0D3GAgG026335 for linux-xfs@oss.sgi.com; Mon, 12 Jan 2004 19:16: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 i0D3G96J026321 for ; Mon, 12 Jan 2004 19:16:09 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0D31CCV025855; Mon, 12 Jan 2004 19:01:12 -0800 Date: Mon, 12 Jan 2004 19:01:12 -0800 Message-Id: <200401130301.i0D31CCV025855@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: 1714 X-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: 1384 Lines: 47 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 ------- Additional Comments From netllama@linux-sxs.org 2004-12-01 18:59 PDT ------- Created an attachment (id=96) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=96&action=view) config.log ------- Additional Comments From netllama@linux-sxs.org 2004-12-01 19:01 PDT ------- I see the following in config.log, however I honestly still do not know what the failed test program should be: #################### configure:3354: checking uuid.h presence configure:3365: /usr/local/bin/gcc3 -E conftest.c configure:3364:18: uuid.h: No such file or directory configure:3371: $? = 1 configure: failed program was: | #line 3356 "configure" | /* confdefs.h. */ | | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | #include configure:3390: result: no configure:3426: checking for uuid.h configure:3433: result: no configure:3461: checking uuid/uuid.h usability configure:3474: /usr/local/bin/gcc3 -c -O2 -funroll-loops -ffast-math -fomit-frame-pointer -fno-excepti ons conftest.c >&5 ################ Is it confest.c ? If so, then i have no such file. Sorry if i'm a bit dense. ------- 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 Jan 12 20:05:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 20:05:57 -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 i0D45j6H028749 for ; Mon, 12 Jan 2004 20:05:45 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id BEE5A141B138; Mon, 12 Jan 2004 23:06:19 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 34B96141B136; Mon, 12 Jan 2004 23:06:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 32D3B30001A1; Mon, 12 Jan 2004 23:06:18 -0500 (EST) Date: Mon, 12 Jan 2004 23:06:18 -0500 (EST) From: Mike Burger To: Greg Freemyer Cc: linux-xfs@oss.sgi.com Subject: Re: [OT] Does the ATA 133 spec. include mechanical details? In-Reply-To: <1073950546.8957.5.camel@david.internal.NorcrossGroup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1715 X-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: 1247 Lines: 41 On Mon, 12 Jan 2004, Greg Freemyer wrote: > On Mon, 2004-01-12 at 18:32, Mike Burger wrote: > > On Mon, 12 Jan 2004, Greg Freemyer wrote: > > > > > > > > Does anyone know if the ATA 133 spec. requires the connectors be in a > > > specific location, and if so are any of the older drives likely to also > > > use the same physical layout? > > > > I've never seen an ATA/IDE drive that didn't have the 40-pin connection on > > one end and the power connection at the other. > > I've got some older 6 GB size drives that have the connector atleast > 1/10 inch offset from the drives I now buy. > > Normally no big deal, but if the drive has to slide onto a fixed > connector block like shown at > > http://www.rackmountnet.com/diskarray/dc35e/dc35e_backplane2.jpg > > then 1/10 inch is nowhere near consistent enough. Interesting...maybe I've seen them and not known it. Interesting. -- 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 Jan 12 22:16:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Jan 2004 22:16:33 -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 i0D6GB6H003694 for ; Mon, 12 Jan 2004 22:16:11 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0D6GBG9003693 for linux-xfs@oss.sgi.com; Mon, 12 Jan 2004 22:16:11 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i0D6G96J003679 for ; Mon, 12 Jan 2004 22:16:10 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0D6BXwd003551; Mon, 12 Jan 2004 22:11:33 -0800 Date: Mon, 12 Jan 2004 22:11:33 -0800 Message-Id: <200401130611.i0D6BXwd003551@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: 1716 X-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: 793 Lines: 30 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 ------- Additional Comments From nathans@sgi.com 2004-12-01 22:11 PDT ------- Sorry, my last mailw as a bit misleading - where I said there will be a failing test program near: configure:3461: checking uuid/uuid.h usability I meant near: configure:XXXX: checking uuid/uuid.h presence "presence" being the key difference there. Just below that line, there should be the text of a C program and some compiler error messages - like there is for the uuid.h test you've sent there. It'll be in the config.log file, not a separate file. In fact, just sending me your entire config.log file might be simpler. 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 Tue Jan 13 05:43:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 05:44:09 -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 i0DDhn6H023687 for ; Tue, 13 Jan 2004 05:43:50 -0800 Received: (qmail 3742 invoked from network); 13 Jan 2004 13:43:48 -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 ; 13 Jan 2004 13:43:48 -0000 Message-ID: <4003F554.3050609@xfs.org> Date: Tue, 13 Jan 2004 07:40:36 -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: Andi Kleen CC: Glen Overby , linux-xfs@oss.sgi.com, ak@muc.de Subject: Re: XFS_WANT_FUNCS References: <20040111114500.GA4508@averell> <200401111621.i0BGLhA63464298@daisy-e236.americas.sgi.com> <20040111164549.GA45569@colin2.muc.de> <4002A1C3.8000608@xfs.org> <20040112183604.GA45023@colin2.muc.de> In-Reply-To: <20040112183604.GA45023@colin2.muc.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1718 X-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: 2296 Lines: 58 Andi Kleen wrote: > Hi Steve, Hi Andy, > > On Mon, Jan 12, 2004 at 07:31:47AM -0600, Steve Lord wrote: > >>The other thing these macros let you do is switch between inline code >>and out of >>line code based on how big you want xfs to be in code size. Some of the >>macros >>expand to a lot of code and are actually always compiled as functions to >>avoid >>too much code bloat. Probably a one off decision on inline code vs function >>calls should be good enough for modern machines, that mechanism was more >>concerned with making xfs run on 32M memory Irix boxes. All the definitions >>in xfs_macros.h control this. > > > Good point. Even on Opteron boxes with incredibly big caches the rule > is still approximately to out of line code that generates more than 10-20 > instructions and cannot be constant optimized by the compiler. > So it would probably make sense to just move the bigger ones out of line > unconditionally and drop the macro definitions. > > >>But yes it is a pain to read through them - and you should try writing >>new ones ;-) >>The scary part about moving things to inlines would be xfs's tendency to >>push >>gcc to its limits on ia32. This type of thing is what has caused broken code >>generation in the past. > > > It wouldn't be any different to macros in this regard. In modern gcc > they are equivalent as seen by the backend. But I agree that moving stuff > out of line is often a good idea (Linux went too far on the > inlining of things in the past and that is now slowly getting corrected) > > The question would be only what to do with the small macros, which are most > of them. I guess these could be just made inline. > > Again, if there is a chance of a patch getting merged i can do it. I would have to leave that one to the folks still at SGI. Changing from macros to functions would look pretty odd without changing the case, and changing the case makes it a very intrusive mod. There really is an effort to keep Irix and Linux somewhat similar, but so far as I know code from outside the company has never gone back into Irix. Because of that the chances are slim. If you want to push, and can come up with a mechanism which does not look too intrusive, prototype it with a couple of macros and see what people think. Steve From owner-linux-xfs@oss.sgi.com Tue Jan 13 06:16:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 06:16: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 i0DEGD6H024819 for ; Tue, 13 Jan 2004 06:16:13 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0DEGDF8024818 for linux-xfs@oss.sgi.com; Tue, 13 Jan 2004 06:16: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 i0DEGB6J024802 for ; Tue, 13 Jan 2004 06:16:11 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0DDtgjB024367; Tue, 13 Jan 2004 05:55:42 -0800 Date: Tue, 13 Jan 2004 05:55:42 -0800 Message-Id: <200401131355.i0DDtgjB024367@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: 1719 X-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: 350 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 ------- Additional Comments From netllama@linux-sxs.org 2004-13-01 05:55 PDT ------- OK, well, i attached my config.log last night, so I think you should have it now. 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 Tue Jan 13 07:08:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 07:08:45 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DF8O6H027283 for ; Tue, 13 Jan 2004 07:08:24 -0800 Received: from wingerboy.noc.sonic.net (wingerboy.noc.sonic.net [64.142.18.2]) by b.mail.sonic.net (8.12.10/8.12.7) with ESMTP id i0D0vvDg031919 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 12 Jan 2004 16:57:57 -0800 Received: from wingerboy.noc.sonic.net (localhost [127.0.0.1]) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9) with ESMTP id i0D0vSlR031987; Mon, 12 Jan 2004 16:57:28 -0800 (PST) (envelope-from kgc@wingerboy.noc.sonic.net) Received: (from kgc@localhost) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9/Submit) id i0D0vS0o031986; Mon, 12 Jan 2004 16:57:28 -0800 (PST) Date: Mon, 12 Jan 2004 16:57:28 -0800 From: Kelsey Cummings To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: [LNX-XFS] Re: [LNX-XFS] Re: large file problems with 2.4.25-pre4 Message-ID: <20040113005728.GN98119@sonic.net> References: <20040112233619.GF98119@sonic.net> <20040113003039.GB969@frodo> <20040113005150.GL98119@sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040113005150.GL98119@sonic.net> User-Agent: Mutt/1.4.1i X-PGP-Key: http://sonic.net/~kgc/gpgkey.txt X-archive-position: 1720 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kgc@sonic.net Precedence: bulk X-list: linux-xfs Content-Length: 1012 Lines: 24 Acutally, I should clarify the problem. I just realized that the box doens't completely lock up, IO to the XFS formatted filesystems just become very very slow and go into some kind of CPU hog loop: 9 root 20 0 0 0 0 RW 94.9 0.0 5:35 kupdated 8 root 20 0 0 0 0 RW 93.0 0.0 6:05 bdflush 7 root 20 0 0 0 0 RW 53.9 0.0 3:24 kswapd 865 root 15 0 1552 508 464 R 53.0 0.0 3:14 dd 757 root 14 0 1552 508 460 R 52.1 0.0 3:52 dd 803 root 14 0 628 628 516 R 51.1 0.0 1:08 iostat I'll see if I can't the resident kernel hacker to help track this down a bit further. -- Kelsey Cummings - kgc@sonic.net sonic.net, inc. System Administrator 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax) http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 From owner-linux-xfs@oss.sgi.com Tue Jan 13 09:35:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 09:35:26 -0800 (PST) Received: from argo.starforce.com (argo.starforce.com [216.158.58.233]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DHZ06H005132 for ; Tue, 13 Jan 2004 09:35:05 -0800 Received: from argo.starforce.com (localhost [127.0.0.1]) by argo.starforce.com (8.12.9-20030917/8.12.9) with ESMTP id i0DHYxRB008254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jan 2004 12:34:59 -0500 Received: from localhost (dwild@localhost) by argo.starforce.com (8.12.9-20030917/8.12.9/Submit) with ESMTP id i0DHYvAg008251 for ; Tue, 13 Jan 2004 12:34:57 -0500 X-Authentication-Warning: argo.starforce.com: dwild owned process doing -bs Date: Tue, 13 Jan 2004 12:34:57 -0500 (EST) From: dwild+xfs@starforce.com X-X-Sender: dwild@argo.starforce.com To: linux-xfs@oss.sgi.com Subject: xfs errors using lvm or md w/LBD (2.6.1) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1721 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dwild+xfs@starforce.com Precedence: bulk X-list: linux-xfs Content-Length: 2495 Lines: 64 I get the following error running the Cerberus burn-in test on xfs running on top of LVM2 or MD. LBD is enabled, and the disk layout is: 1.0TB /dev/sdb1 1.5TB /dev/sdc1 1.5TB /dev/sdd1 5.0TB /dev/md0 or /dev/vg00/lv00 I havn't had a chance to test 2.6.1 without LBD or individual devices on this machine, because it's going into production shortly so I'm using ext3 instead. Here's the error (same error with md and lvm2): After hardware burning completes with ext3 I should have more time to test if needed. 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Filesystem "dm-0": XFS internal error xfs_alloc_read_agf at line 2208 of file fs/xfs/xfs_alloc.c. Caller 0xc01c4116 Call Trace: [] xfs_alloc_read_agf+0x141/0x254 [] xfs_alloc_fix_freelist+0x1c4/0x4b0 [] xfs_alloc_fix_freelist+0x1c4/0x4b0 [] xfs_alloc_fix_freelist+0x1c4/0x4b0 [] xfs_bmbt_lookup+0x3a8/0x5a2 [] xfs_trans_log_buf+0x6b/0xa4 [] xfs_bmbt_update+0xb3/0x11f [] xfs_alloc_vextent+0x2aa/0x511 [] xfs_bmap_alloc+0x1181/0x1949 [] sd_rw_intr+0x91/0x33d [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmapi+0x65e/0x169e [] xfs_buf_item_relse+0x3f/0x43 [] xfs_buf_item_unlock+0xe3/0xe5 [] xfs_bmbt_get_state+0x2f/0x3b [] xlog_assign_tail_lsn+0x16/0x41 [] smp_apic_timer_interrupt+0x15b/0x16f [] apic_timer_interrupt+0x1a/0x20 [] xfs_iomap_write_allocate+0x271/0x587 [] generic_make_request+0x112/0x1e8 [] as_add_request+0x1c0/0x252 [] xfs_iunlock+0x4a/0x74 [] xfs_iomap+0x3e9/0x54d [] map_blocks+0x7a/0x13a [] page_state_convert+0x4c1/0x678 [] as_next_request+0x33/0x3c [] generic_unplug_device+0x60/0x62 [] blk_run_queues+0x81/0x99 [] pagebuf_iorequest+0xab/0x163 [] linvfs_writepage+0x60/0x11a [] mpage_writepages+0x23b/0x33a [] linvfs_writepage+0x0/0x11a [] do_writepages+0x36/0x3a [] __sync_single_inode+0xb8/0x1fb [] sync_sb_inodes+0x182/0x297 [] writeback_inodes+0x5a/0x8d [] wb_kupdate+0x9c/0x11c [] __pdflush+0xd1/0x1bc [] pdflush+0x0/0x13 [] pdflush+0xf/0x13 [] wb_kupdate+0x0/0x11c [] kernel_thread_helper+0x0/0xb [] kernel_thread_helper+0x5/0xb From owner-linux-xfs@oss.sgi.com Tue Jan 13 10:47:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 10:47:40 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DIlS6H007042 for ; Tue, 13 Jan 2004 10:47:28 -0800 Received: from wingerboy.noc.sonic.net (wingerboy.noc.sonic.net [64.142.18.2]) by b.mail.sonic.net (8.12.10/8.12.7) with ESMTP id i0DIlNDg030000 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 13 Jan 2004 10:47:23 -0800 Received: from wingerboy.noc.sonic.net (localhost [127.0.0.1]) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9) with ESMTP id i0DIl4lR086406; Tue, 13 Jan 2004 10:47:04 -0800 (PST) (envelope-from kgc@wingerboy.noc.sonic.net) Received: (from kgc@localhost) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9/Submit) id i0DIl2le086405; Tue, 13 Jan 2004 10:47:02 -0800 (PST) Date: Tue, 13 Jan 2004 10:47:02 -0800 From: Kelsey Cummings To: Nathan Scott Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: [LNX-XFS] Re: large file problems with 2.4.25-pre4 Message-ID: <20040113184702.GW98119@sonic.net> References: <20040112233619.GF98119@sonic.net> <20040113003039.GB969@frodo> <20040113005150.GL98119@sonic.net> <4003539F.8030207@xfs.org> <20040113024639.GA1205@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040113024639.GA1205@frodo> User-Agent: Mutt/1.4.1i X-PGP-Key: http://sonic.net/~kgc/gpgkey.txt X-archive-position: 1722 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kgc@sonic.net Precedence: bulk X-list: linux-xfs Content-Length: 1262 Lines: 35 On Tue, Jan 13, 2004 at 01:46:39PM +1100, Nathan Scott wrote: > On Mon, Jan 12, 2004 at 08:10:39PM -0600, Steve Lord wrote: > > Kelsey Cummings wrote: > > > > >>If you consistently see lockups, your best bet is to drop > > >>into kdb and start with backtraces on the stuck processes. > > > > > > > > >Aie, I'm afraid I don't have that kind of foo. :) > > > > > > > Nathan, > > > > Isn't this the large ag size and extents beyond 4G in size bug > > again? > > > > Oh, of course - brain switched off today. Kelsey, if its not > too late to do so you can re-mkfs with -dagsize=4g to fix this > or ask Eric for his patch which addresses this one (which I > think is close to ready now?). [root@dhcp-100 root]# ls -las /mnt/vol0/bifile /mnt/vol1/bifile 10240000 -rw-r--r-- 1 root root 10485760000 Jan 13 10:45 /mnt/vol0/bifile 10240000 -rw-r--r-- 1 root root 10485760000 Jan 13 10:44 /mnt/vol1/bifile Working now, thanks! -- Kelsey Cummings - kgc@sonic.net sonic.net, inc. System Administrator 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax) http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 From owner-linux-xfs@oss.sgi.com Tue Jan 13 11:31:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 11:31: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 i0DJV36H019873 for ; Tue, 13 Jan 2004 11:31:04 -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 i0DKoAQI019009 for ; Tue, 13 Jan 2004 14:50: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 i0DJUvjH29356111; Tue, 13 Jan 2004 13:30: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 i0DJUQK113669515; Tue, 13 Jan 2004 13:30:36 -0600 (CST) Subject: Re: [LNX-XFS] Re: large file problems with 2.4.25-pre4 From: Eric Sandeen To: Kelsey Cummings Cc: Nathan Scott , Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <20040113184702.GW98119@sonic.net> References: <20040112233619.GF98119@sonic.net> <20040113003039.GB969@frodo> <20040113005150.GL98119@sonic.net> <4003539F.8030207@xfs.org> <20040113024639.GA1205@frodo> <20040113184702.GW98119@sonic.net> Content-Type: multipart/mixed; boundary="=-PtaMdySARcRsxuplc91w" Organization: Eric Conspiracy Secret Labs Message-Id: <1074022226.20422.23.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 13 Jan 2004 13:30:26 -0600 X-archive-position: 1723 X-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: 8572 Lines: 241 --=-PtaMdySARcRsxuplc91w Content-Type: text/plain Content-Transfer-Encoding: 7bit Here's the patch which I am on the verge of checking in, if you'd like to test it with default mkfs values again, that'd be great. Depending on what your xfs tree looks like, you might need to change "linux-2.4" paths to just "linux" and references to "xfs_buf.[ch]" to "page_buf.[ch]" or so, to make it apply. Pathnames & file names have been swizzled a little bit lately. -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 --=-PtaMdySARcRsxuplc91w Content-Disposition: attachment; filename=large-ag-fix.patch Content-Type: text/plain; name=large-ag-fix.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit =========================================================================== Index: linux-2.4/xfs_aops.c =========================================================================== --- /usr/tmp/TmpDir.10141-0/linux-2.4/xfs_aops.c_1.64 2004-01-12 23:44:25.000000000 -0600 +++ linux-2.4/xfs_aops.c 2004-01-12 21:52:57.000000000 -0600 @@ -374,8 +374,9 @@ offset <<= PAGE_CACHE_SHIFT; offset += p_offset; - pb = pagebuf_lookup(iomapp->iomap_target, - iomapp->iomap_offset, iomapp->iomap_bsize, 0); + /* get an "empty" pagebuf to manage IO completion + * Proper values will be set before returning */ + pb = pagebuf_lookup(iomapp->iomap_target, 0, 0, 0); if (!pb) return -EAGAIN; @@ -438,6 +439,13 @@ nblocks += bs; atomic_add(bs, &pb->pb_io_remaining); convert_page(inode, page, iomapp, pb, startio, all_bh); + /* stop if we've found enough blocks that the + * corresponding byte count won't fit in our ulong + * pagebuf length (max 128 blocks could be returned + * from probe_unwritten_page - 64k page / 512b blocks) + */ + if ((nblocks + 128) > (ULONG_MAX >> block_bits)) + goto enough; } if (tindex == tlast && @@ -448,16 +456,20 @@ nblocks += bs; atomic_add(bs, &pb->pb_io_remaining); convert_page(inode, page, iomapp, pb, startio, all_bh); + if ((nblocks + 128) > (ULONG_MAX >> block_bits)) + goto enough; } } } +enough: size = nblocks; /* NB: using 64bit number here */ size <<= block_bits; /* convert fsb's to byte range */ XFS_BUF_DATAIO(pb); XFS_BUF_ASYNC(pb); XFS_BUF_SET_SIZE(pb, size); + XFS_BUF_SET_COUNT(pb, size); XFS_BUF_SET_OFFSET(pb, offset); XFS_BUF_SET_FSPRIVATE(pb, LINVFS_GET_VP(inode)); XFS_BUF_SET_IODONE_FUNC(pb, linvfs_unwritten_convert); @@ -1127,10 +1139,14 @@ int error = 0; int pb_flags, map_flags, pg_index = 0; size_t length, total; - loff_t offset; - size_t map_size, size; + loff_t offset, map_size; + size_t size; vnode_t *vp = LINVFS_GET_VP(inode); + /* Note - although the iomap could have a 64-bit size, + * kiobuf->length is only an int, so the min(map_size, length) + * test will keep us from overflowing the pagebuf size_t size. + */ total = length = iobuf->length; offset = blocknr; offset <<= inode->i_blkbits; @@ -1147,7 +1163,7 @@ BUG_ON(iomap.iomap_flags & IOMAP_DELAY); map_size = iomap.iomap_bsize - iomap.iomap_delta; - size = min(map_size, length); + size = (size_t)min(map_size, (loff_t)length); if ((iomap.iomap_flags & IOMAP_HOLE) || ((iomap.iomap_flags & IOMAP_UNWRITTEN) && rw == READ)) { =========================================================================== Index: linux-2.6/xfs_aops.c =========================================================================== --- /usr/tmp/TmpDir.10141-0/linux-2.6/xfs_aops.c_1.56 2004-01-12 23:44:25.000000000 -0600 +++ linux-2.6/xfs_aops.c 2004-01-12 23:36:05.000000000 -0600 @@ -407,8 +407,10 @@ offset <<= PAGE_CACHE_SHIFT; offset += p_offset; - pb = pagebuf_lookup(iomapp->iomap_target, - iomapp->iomap_offset, iomapp->iomap_bsize, 0); + /* get an "empty" pagebuf to manage IO completion + * Proper values will be set before returning */ + pb = pagebuf_lookup(iomapp->iomap_target, 0, 0, 0); + if (!pb) return -EAGAIN; @@ -471,6 +473,13 @@ nblocks += bs; atomic_add(bs, &pb->pb_io_remaining); convert_page(inode, page, iomapp, pb, startio, all_bh); + /* stop if we've found enough blocks that the + * corresponding byte count won't fit in the + * pagebuf length (max 128 blocks could be returned + * from probe_unwritten_page: 64k page / 512b blocks) + */ + if ((nblocks + 128) > (ULONG_MAX >> block_bits)) + goto enough; } if (tindex == tlast && @@ -481,16 +490,20 @@ nblocks += bs; atomic_add(bs, &pb->pb_io_remaining); convert_page(inode, page, iomapp, pb, startio, all_bh); + if ((nblocks + 128) > (ULONG_MAX >> block_bits)) + goto enough; } } } +enough: size = nblocks; /* NB: using 64bit number here */ size <<= block_bits; /* convert fsb's to byte range */ XFS_BUF_DATAIO(pb); XFS_BUF_ASYNC(pb); XFS_BUF_SET_SIZE(pb, size); + XFS_BUF_SET_COUNT(pb, size); XFS_BUF_SET_OFFSET(pb, offset); XFS_BUF_SET_FSPRIVATE(pb, LINVFS_GET_VP(inode)); XFS_BUF_SET_IODONE_FUNC(pb, linvfs_unwritten_convert); @@ -925,8 +938,10 @@ } if (blocks) { - size = (iomap.iomap_bsize - iomap.iomap_delta); - bh_result->b_size = min_t(ssize_t, size, blocks << inode->i_blkbits); + loff_t iosize; + iosize = (iomap.iomap_bsize - iomap.iomap_delta); + bh_result->b_size = + (ssize_t)min(iosize, (loff_t)(blocks << inode->i_blkbits)); } return 0; =========================================================================== Index: xfs_iomap.h =========================================================================== --- /usr/tmp/TmpDir.10141-0/xfs_iomap.h_1.1 2004-01-12 23:44:25.000000000 -0600 +++ xfs_iomap.h 2004-01-05 23:05:32.000000000 -0600 @@ -66,27 +66,26 @@ /* * xfs_iomap_t: File system I/O map * - * The iomap_bn, iomap_offset and iomap_length fields are expressed in disk blocks. - * The iomap_length field specifies the size of the underlying backing store - * for the particular mapping. + * The iomap_bn field is expressed in 512-byte blocks, and is where the + * mapping starts on disk. * - * The iomap_bsize, iomap_size and iomap_delta fields are in bytes and indicate - * the size of the mapping, the number of bytes that are valid to access - * (read or write), and the offset into the mapping, given the offset - * supplied to the file I/O map routine. iomap_delta is the offset of the - * desired data from the beginning of the mapping. + * The iomap_offset, iomap_bsize and iomap_delta fields are in bytes. + * iomap_offset is the offset of the mapping in the file itself. + * iomap_bsize is the size of the mapping, iomap_delta is the + * desired data's offset into the mapping, given the offset supplied + * to the file I/O map routine. * * When a request is made to read beyond the logical end of the object, - * iomap_size may be set to 0, but iomap_offset and iomap_length should be set to - * the actual amount of underlying storage that has been allocated, if any. + * iomap_size may be set to 0, but iomap_offset and iomap_length should be set + * to the actual amount of underlying storage that has been allocated, if any. */ typedef struct xfs_iomap { - xfs_daddr_t iomap_bn; + xfs_daddr_t iomap_bn; /* first 512b blk of mapping */ xfs_buftarg_t *iomap_target; - loff_t iomap_offset; - size_t iomap_delta; - size_t iomap_bsize; + loff_t iomap_offset; /* offset of mapping, bytes */ + loff_t iomap_bsize; /* size of mapping, bytes */ + size_t iomap_delta; /* offset into mapping, bytes */ iomap_flags_t iomap_flags; } xfs_iomap_t; =========================================================================== Index: xfsidbg.c =========================================================================== --- /usr/tmp/TmpDir.10141-0/xfsidbg.c_1.250 2004-01-12 23:44:25.000000000 -0600 +++ xfsidbg.c 2004-01-05 23:15:44.000000000 -0600 @@ -2610,9 +2610,9 @@ (diag = kdb_getarea(iomap, addr))) kdb_printf("iomap_t at 0x%lx\n", addr); - kdb_printf(" iomap_bn 0x%llx iomap_offset 0x%Lx iomap_delta 0x%lx iomap_bsize 0x%lx\n", + kdb_printf(" iomap_bn 0x%llx iomap_offset 0x%Lx iomap_delta 0x%lx iomap_bsize 0x%llx\n", (long long) iomap.iomap_bn, iomap.iomap_offset, - (unsigned long) iomap.iomap_delta, (unsigned long) iomap.iomap_bsize); + (unsigned long)iomap.iomap_delta, (long long)iomap.iomap_bsize); kdb_printf(" iomap_flags %s\n", map_flags(iomap.iomap_flags, iomap_flag_vals)); --=-PtaMdySARcRsxuplc91w-- From owner-linux-xfs@oss.sgi.com Tue Jan 13 11:40:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 11:40:59 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJel6H023151 for ; Tue, 13 Jan 2004 11:40:47 -0800 Received: from wingerboy.noc.sonic.net (wingerboy.noc.sonic.net [64.142.18.2]) by b.mail.sonic.net (8.12.10/8.12.7) with ESMTP id i0DJegDg021670 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 13 Jan 2004 11:40:42 -0800 Received: from wingerboy.noc.sonic.net (localhost [127.0.0.1]) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9) with ESMTP id i0DJe2lR094180; Tue, 13 Jan 2004 11:40:02 -0800 (PST) (envelope-from kgc@wingerboy.noc.sonic.net) Received: (from kgc@localhost) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9/Submit) id i0DJe2v0094179; Tue, 13 Jan 2004 11:40:02 -0800 (PST) Date: Tue, 13 Jan 2004 11:40:02 -0800 From: Kelsey Cummings To: Eric Sandeen Cc: Nathan Scott , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: [LNX-XFS] Re: [LNX-XFS] Re: large file problems with 2.4.25-pre4 Message-ID: <20040113194002.GX98119@sonic.net> References: <20040112233619.GF98119@sonic.net> <20040113003039.GB969@frodo> <20040113005150.GL98119@sonic.net> <4003539F.8030207@xfs.org> <20040113024639.GA1205@frodo> <20040113184702.GW98119@sonic.net> <1074022226.20422.23.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1074022226.20422.23.camel@stout.americas.sgi.com> User-Agent: Mutt/1.4.1i X-PGP-Key: http://sonic.net/~kgc/gpgkey.txt X-archive-position: 1724 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kgc@sonic.net Precedence: bulk X-list: linux-xfs Content-Length: 9145 Lines: 241 I'll let you know how it goes. Thanks! On Tue, Jan 13, 2004 at 01:30:26PM -0600, Eric Sandeen wrote: > Here's the patch which I am on the verge of checking in, if you'd like > to test it with default mkfs values again, that'd be great. > > Depending on what your xfs tree looks like, you might need to change > "linux-2.4" paths to just "linux" and references to "xfs_buf.[ch]" to > "page_buf.[ch]" or so, to make it apply. Pathnames & file names have > been swizzled a little bit lately. > > -Eric > > -- > Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 > > =========================================================================== > Index: linux-2.4/xfs_aops.c > =========================================================================== > > --- /usr/tmp/TmpDir.10141-0/linux-2.4/xfs_aops.c_1.64 2004-01-12 23:44:25.000000000 -0600 > +++ linux-2.4/xfs_aops.c 2004-01-12 21:52:57.000000000 -0600 > @@ -374,8 +374,9 @@ > offset <<= PAGE_CACHE_SHIFT; > offset += p_offset; > > - pb = pagebuf_lookup(iomapp->iomap_target, > - iomapp->iomap_offset, iomapp->iomap_bsize, 0); > + /* get an "empty" pagebuf to manage IO completion > + * Proper values will be set before returning */ > + pb = pagebuf_lookup(iomapp->iomap_target, 0, 0, 0); > if (!pb) > return -EAGAIN; > > @@ -438,6 +439,13 @@ > nblocks += bs; > atomic_add(bs, &pb->pb_io_remaining); > convert_page(inode, page, iomapp, pb, startio, all_bh); > + /* stop if we've found enough blocks that the > + * corresponding byte count won't fit in our ulong > + * pagebuf length (max 128 blocks could be returned > + * from probe_unwritten_page - 64k page / 512b blocks) > + */ > + if ((nblocks + 128) > (ULONG_MAX >> block_bits)) > + goto enough; > } > > if (tindex == tlast && > @@ -448,16 +456,20 @@ > nblocks += bs; > atomic_add(bs, &pb->pb_io_remaining); > convert_page(inode, page, iomapp, pb, startio, all_bh); > + if ((nblocks + 128) > (ULONG_MAX >> block_bits)) > + goto enough; > } > } > } > > +enough: > size = nblocks; /* NB: using 64bit number here */ > size <<= block_bits; /* convert fsb's to byte range */ > > XFS_BUF_DATAIO(pb); > XFS_BUF_ASYNC(pb); > XFS_BUF_SET_SIZE(pb, size); > + XFS_BUF_SET_COUNT(pb, size); > XFS_BUF_SET_OFFSET(pb, offset); > XFS_BUF_SET_FSPRIVATE(pb, LINVFS_GET_VP(inode)); > XFS_BUF_SET_IODONE_FUNC(pb, linvfs_unwritten_convert); > @@ -1127,10 +1139,14 @@ > int error = 0; > int pb_flags, map_flags, pg_index = 0; > size_t length, total; > - loff_t offset; > - size_t map_size, size; > + loff_t offset, map_size; > + size_t size; > vnode_t *vp = LINVFS_GET_VP(inode); > > + /* Note - although the iomap could have a 64-bit size, > + * kiobuf->length is only an int, so the min(map_size, length) > + * test will keep us from overflowing the pagebuf size_t size. > + */ > total = length = iobuf->length; > offset = blocknr; > offset <<= inode->i_blkbits; > @@ -1147,7 +1163,7 @@ > BUG_ON(iomap.iomap_flags & IOMAP_DELAY); > > map_size = iomap.iomap_bsize - iomap.iomap_delta; > - size = min(map_size, length); > + size = (size_t)min(map_size, (loff_t)length); > > if ((iomap.iomap_flags & IOMAP_HOLE) || > ((iomap.iomap_flags & IOMAP_UNWRITTEN) && rw == READ)) { > > =========================================================================== > Index: linux-2.6/xfs_aops.c > =========================================================================== > > --- /usr/tmp/TmpDir.10141-0/linux-2.6/xfs_aops.c_1.56 2004-01-12 23:44:25.000000000 -0600 > +++ linux-2.6/xfs_aops.c 2004-01-12 23:36:05.000000000 -0600 > @@ -407,8 +407,10 @@ > offset <<= PAGE_CACHE_SHIFT; > offset += p_offset; > > - pb = pagebuf_lookup(iomapp->iomap_target, > - iomapp->iomap_offset, iomapp->iomap_bsize, 0); > + /* get an "empty" pagebuf to manage IO completion > + * Proper values will be set before returning */ > + pb = pagebuf_lookup(iomapp->iomap_target, 0, 0, 0); > + > if (!pb) > return -EAGAIN; > > @@ -471,6 +473,13 @@ > nblocks += bs; > atomic_add(bs, &pb->pb_io_remaining); > convert_page(inode, page, iomapp, pb, startio, all_bh); > + /* stop if we've found enough blocks that the > + * corresponding byte count won't fit in the > + * pagebuf length (max 128 blocks could be returned > + * from probe_unwritten_page: 64k page / 512b blocks) > + */ > + if ((nblocks + 128) > (ULONG_MAX >> block_bits)) > + goto enough; > } > > if (tindex == tlast && > @@ -481,16 +490,20 @@ > nblocks += bs; > atomic_add(bs, &pb->pb_io_remaining); > convert_page(inode, page, iomapp, pb, startio, all_bh); > + if ((nblocks + 128) > (ULONG_MAX >> block_bits)) > + goto enough; > } > } > } > > +enough: > size = nblocks; /* NB: using 64bit number here */ > size <<= block_bits; /* convert fsb's to byte range */ > > XFS_BUF_DATAIO(pb); > XFS_BUF_ASYNC(pb); > XFS_BUF_SET_SIZE(pb, size); > + XFS_BUF_SET_COUNT(pb, size); > XFS_BUF_SET_OFFSET(pb, offset); > XFS_BUF_SET_FSPRIVATE(pb, LINVFS_GET_VP(inode)); > XFS_BUF_SET_IODONE_FUNC(pb, linvfs_unwritten_convert); > @@ -925,8 +938,10 @@ > } > > if (blocks) { > - size = (iomap.iomap_bsize - iomap.iomap_delta); > - bh_result->b_size = min_t(ssize_t, size, blocks << inode->i_blkbits); > + loff_t iosize; > + iosize = (iomap.iomap_bsize - iomap.iomap_delta); > + bh_result->b_size = > + (ssize_t)min(iosize, (loff_t)(blocks << inode->i_blkbits)); > } > > return 0; > > =========================================================================== > Index: xfs_iomap.h > =========================================================================== > > --- /usr/tmp/TmpDir.10141-0/xfs_iomap.h_1.1 2004-01-12 23:44:25.000000000 -0600 > +++ xfs_iomap.h 2004-01-05 23:05:32.000000000 -0600 > @@ -66,27 +66,26 @@ > /* > * xfs_iomap_t: File system I/O map > * > - * The iomap_bn, iomap_offset and iomap_length fields are expressed in disk blocks. > - * The iomap_length field specifies the size of the underlying backing store > - * for the particular mapping. > + * The iomap_bn field is expressed in 512-byte blocks, and is where the > + * mapping starts on disk. > * > - * The iomap_bsize, iomap_size and iomap_delta fields are in bytes and indicate > - * the size of the mapping, the number of bytes that are valid to access > - * (read or write), and the offset into the mapping, given the offset > - * supplied to the file I/O map routine. iomap_delta is the offset of the > - * desired data from the beginning of the mapping. > + * The iomap_offset, iomap_bsize and iomap_delta fields are in bytes. > + * iomap_offset is the offset of the mapping in the file itself. > + * iomap_bsize is the size of the mapping, iomap_delta is the > + * desired data's offset into the mapping, given the offset supplied > + * to the file I/O map routine. > * > * When a request is made to read beyond the logical end of the object, > - * iomap_size may be set to 0, but iomap_offset and iomap_length should be set to > - * the actual amount of underlying storage that has been allocated, if any. > + * iomap_size may be set to 0, but iomap_offset and iomap_length should be set > + * to the actual amount of underlying storage that has been allocated, if any. > */ > > typedef struct xfs_iomap { > - xfs_daddr_t iomap_bn; > + xfs_daddr_t iomap_bn; /* first 512b blk of mapping */ > xfs_buftarg_t *iomap_target; > - loff_t iomap_offset; > - size_t iomap_delta; > - size_t iomap_bsize; > + loff_t iomap_offset; /* offset of mapping, bytes */ > + loff_t iomap_bsize; /* size of mapping, bytes */ > + size_t iomap_delta; /* offset into mapping, bytes */ > iomap_flags_t iomap_flags; > } xfs_iomap_t; > > > =========================================================================== > Index: xfsidbg.c > =========================================================================== > > --- /usr/tmp/TmpDir.10141-0/xfsidbg.c_1.250 2004-01-12 23:44:25.000000000 -0600 > +++ xfsidbg.c 2004-01-05 23:15:44.000000000 -0600 > @@ -2610,9 +2610,9 @@ > (diag = kdb_getarea(iomap, addr))) > > kdb_printf("iomap_t at 0x%lx\n", addr); > - kdb_printf(" iomap_bn 0x%llx iomap_offset 0x%Lx iomap_delta 0x%lx iomap_bsize 0x%lx\n", > + kdb_printf(" iomap_bn 0x%llx iomap_offset 0x%Lx iomap_delta 0x%lx iomap_bsize 0x%llx\n", > (long long) iomap.iomap_bn, iomap.iomap_offset, > - (unsigned long) iomap.iomap_delta, (unsigned long) iomap.iomap_bsize); > + (unsigned long)iomap.iomap_delta, (long long)iomap.iomap_bsize); > > kdb_printf(" iomap_flags %s\n", map_flags(iomap.iomap_flags, iomap_flag_vals)); > -- Kelsey Cummings - kgc@sonic.net sonic.net, inc. System Administrator 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax) http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 From owner-linux-xfs@oss.sgi.com Tue Jan 13 14:25:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 14:25:44 -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 i0DMPW6H001771 for ; Tue, 13 Jan 2004 14:25:33 -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 i0DLRNxG022283 for ; Tue, 13 Jan 2004 13:27:23 -0800 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id 7EB028C871B; Tue, 13 Jan 2004 16:24:47 -0600 (CST) Subject: PARTIAL TAKE 904566 - Message-Id: <20040113222447.7EB028C871B@naboo.americas.sgi.com> Date: Tue, 13 Jan 2004 16:24:47 -0600 (CST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1725 X-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: 732 Lines: 34 Don't really need this anymore :-) Date: Fri Jan 9 10:37:41 PST 2004 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:164598a pagebuf/Makefile - 1.24 Subject: PARTIAL TAKE 907738 - Merge bits from -dev tree. This change is going in as a separate mod since it it not -dev specfic. Date: Tue Jan 13 14:23:40 PST 2004 Workarea: naboo.americas.sgi.com:/go/space/XFS/xfs-linux-p The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:164812a linux-2.4/xfs_aops.c - 1.65 - Flag handling linux-2.4/kmem.h - 1.23 - Added flag def From owner-linux-xfs@oss.sgi.com Tue Jan 13 14:56:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 14:56:49 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DMuR6H003496 for ; Tue, 13 Jan 2004 14:56:27 -0800 Received: from naboo.americas.sgi.com ([128.162.233.73]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0DNuixx017828 for ; Tue, 13 Jan 2004 15:56:44 -0800 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id BA4218C871B; Tue, 13 Jan 2004 16:38:04 -0600 (CST) Subject: PARTIAL TAKE 907739 - Merge the last xfs devel tree to xfs-linux Message-Id: <20040113223804.BA4218C871B@naboo.americas.sgi.com> Date: Tue, 13 Jan 2004 16:38:04 -0600 (CST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1726 X-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: 929 Lines: 35 Merge the bulk of the bits over from the -dev tree. Some of the code needs some cleanup now but this mod basically is to bring the xfs-linux tree in sync with -dev. Date: Tue Jan 13 14:37:05 PST 2004 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:164814a xfs.h - 1.43 xfs_dmapi.h - 1.43 xfs_acl.c - 1.48 xfs_quota.h - 1.35 quota/xfs_qm_bhv.c - 1.6 quota/Makefile - 1.6 dmapi/Makefile - 1.23 Makefile-linux-2.4 - 1.200 linux-2.4/xfs_lrw.c - 1.211 linux-2.4/xfs_vfs.h - 1.49 linux-2.4/xfs_vfs.c - 1.52 linux-2.4/xfs_globals.c - 1.67 linux-2.4/xfs_linux.h - 1.127 linux-2.4/xfs_file.c - 1.103 linux-2.4/xfs_super.h - 1.57 linux-2.4/xfs_super.c - 1.279 linux-2.4/xfs_aops.c - 1.66 linux-2.4/xfs_sysctl.c - 1.34 linux-2.4/xfs_sysctl.h - 1.25 linux-2.4/xfs_buf.h - 1.86 linux-2.4/xfs_buf.c - 1.152 From owner-linux-xfs@oss.sgi.com Tue Jan 13 16:33:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 16:33:36 -0800 (PST) Received: from imf25aec.mail.bellsouth.net (imf25aec.mail.bellsouth.net [205.152.59.73]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0XN6H014738 for ; Tue, 13 Jan 2004 16:33:23 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf23aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040113235743.XXJP1950.imf23aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Tue, 13 Jan 2004 18:57:43 -0500 Subject: Re: [OT] Does the ATA 133 spec. include mechanical details? From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Danny Cox Cc: XFS Mailing List In-Reply-To: <1074032800.12677.6.camel@pip> References: <1073948203.8061.7.camel@david.internal.NorcrossGroup.com> <1074032800.12677.6.camel@pip> Content-Type: text/plain Message-Id: <1074037639.13017.2.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, 13 Jan 2004 18:47:19 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1728 X-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: 1299 Lines: 34 On Tue, 2004-01-13 at 17:26, Danny Cox wrote: > Greg, > > On Mon, 2004-01-12 at 17:56, Greg Freemyer wrote: > > But it looks like it requires the power and ATA connector to be at > > specific physical locations on the drive. I know that older IDE drives > > did not have a consistent location for these connectors, so I'm nervous > > about buying it. > > > > Does anyone know if the ATA 133 spec. requires the connectors be in a > > specific location, and if so are any of the older drives likely to also > > use the same physical layout? > > Sometimes: in the Snap Appliance (nee Quantum) 12 drive NAS box, we had > drive trays to hold the drives, and provide the slide for the hot-swap > capability (and a common plug at the back for both power and data). We > had at least two kinds: one for IBM DeathStars, and one for Western > Digital. We found later that Seagate would also fit the IBM trays. All > of these AFAIK, were ATA 100, not 133. > > I *don't* know about newer drives, but I strongly suspect that the > "standard" is still what it was: do whatever feels good! > > Good luck! Thanks, I suspected it would be a brand specific thing. The cost is pretty low, so I have decided to buy one and see if it works with the Maxtor drives we normally use. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Tue Jan 13 18:32:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 18:32:41 -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 i0E2WK6H019274 for ; Tue, 13 Jan 2004 18:32:20 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0E3pQQI011470 for ; Tue, 13 Jan 2004 21:51:27 -0600 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i0E2UIdd001486 for ; Wed, 14 Jan 2004 13:30:19 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i0E2UInc001485 for linux-xfs@oss.sgi.com; Wed, 14 Jan 2004 13:30:18 +1100 Date: Wed, 14 Jan 2004 13:30:18 +1100 From: FSG QA Message-Id: <200401140230.i0E2UInc001485@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 1729 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 503 Lines: 21 Test script updates to cater for the revised tree layout. Allows for separate user/kernel workareas now. -- nathans Date: Tue Jan 13 18:29:30 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:164822a xfstests/040 - 1.10 xfstests/README - 1.3 xfstests/tools/README.auto-qa - 1.9 xfstests/tools/auto-qa - 1.45 xfstests/tools/srcdiff - 1.27 From owner-linux-xfs@oss.sgi.com Tue Jan 13 22:16:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 22:16: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 i0E6GG6H027710 for ; Tue, 13 Jan 2004 22:16:16 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0E6GGLW027709 for linux-xfs@oss.sgi.com; Tue, 13 Jan 2004 22:16: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 i0E6GE6J027695 for ; Tue, 13 Jan 2004 22:16:14 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0E5Ms1R026820; Tue, 13 Jan 2004 21:22:54 -0800 Date: Tue, 13 Jan 2004 21:22:54 -0800 Message-Id: <200401140522.i0E5Ms1R026820@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: 1730 X-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: 1097 Lines: 42 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 ------- Additional Comments From nathans@sgi.com 2004-13-01 21:22 PDT ------- OK, I see the problem, and having a look through the current autoconf documentation confirms it. The semantics of the AC_CHECK_SIZEOF macro have changed slightly - it seems for some autoconf versions the second parameter is ignored if the type isn't one of the predefined ones, and a zero size is returned. Previously, if the type wasn't known it would return the second parameter, IIRC - this will probably be some autoconf change to better support cross-compiling. Does your xfsprogs build succeed if you do this? # cd xfsprogs # make distclean # rm -f configure include/platform_defs.h # setenv ac_cv_sizeof_char_p 4 # setenv ac_cv_sizeof_long 4 (or) # export ac_cv_sizeof_char_p=4 # export ac_cv_sizeof_long=4 (depending on your shell, then finally...) # make If so, I have a fix ready to go in that should resolve this. 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 Tue Jan 13 22:16:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Jan 2004 22:17: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 i0E6Gs6H027739 for ; Tue, 13 Jan 2004 22:16:54 -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 i0E5Iju5019149 for ; Tue, 13 Jan 2004 21:18:46 -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 i0E6FrSA022675; Wed, 14 Jan 2004 00:16:07 -0600 Received: (from sandeen@localhost) by stout.americas.sgi.com (8.12.8/8.12.8/Submit) id i0E6FXA4022673; Wed, 14 Jan 2004 00:15:33 -0600 Date: Wed, 14 Jan 2004 00:15:33 -0600 From: Eric Sandeen Message-Id: <200401140615.i0E6FXA4022673@stout.americas.sgi.com> Subject: TAKE 906686 - X-archive-position: 1731 X-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: 774 Lines: 27 Fix for large allocation groups, so that extent sizes will not overflow pagebuf lengths. Date: Tue Jan 13 22:14:39 PST 2004 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:164827a xfsidbg.c - 1.251 - Fix up some printk format strings for the larger iomap size. xfs_iomap.h - 1.2 - Clean up comments on xfs_iomap_t, and make the iomap size a 64-bit number. With AGs > 4G, extents and mappings can be > 32 bits long. linux-2.6/xfs_aops.c - 1.57 linux-2.4/xfs_aops.c - 1.67 - Fix map_unwritten so that we don't map so many blocks that the size won't fit in a pagebuf. Fix up linvfs_direct_IO for large mappings From owner-linux-xfs@oss.sgi.com Wed Jan 14 05:42:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 05:43:05 -0800 (PST) Received: from coredumps.de (coredumps.de [217.160.213.75]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EDgr6H020755 for ; Wed, 14 Jan 2004 05:42:53 -0800 Received: from port-212-202-52-166.reverse.qsc.de ([212.202.52.166] helo=ente.berdmann.de) by coredumps.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1AglIK-0005Cy-En for linux-xfs@oss.sgi.com; Wed, 14 Jan 2004 14:42:52 +0100 Received: from octane.berdmann.de ([192.168.1.14] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1AglIJ-00013z-00 for linux-xfs@oss.sgi.com; Wed, 14 Jan 2004 14:42:52 +0100 Message-ID: <4005475A.2060004@berdmann.de> Date: Wed, 14 Jan 2004 14:42:50 +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: searching forRH-8.0-SGI-XFS-1.2.0-v4.iso Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1733 X-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: 113 Lines: 8 Hi, I'm searching for the file forRH-8.0-SGI-XFS-1.2.0-v4.iso - can I download it somewhere? Regards, Bernie From owner-linux-xfs@oss.sgi.com Wed Jan 14 05:47:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 05:48:05 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EDls6H021297 for ; Wed, 14 Jan 2004 05:47:54 -0800 Received: from [192.168.10.75] (c-24-98-62-33.atl.client2.attbi.com[24.98.62.33]) by comcast.net (sccrmhc13) with SMTP id <2004011322264101600njnjge>; Tue, 13 Jan 2004 22:26:42 +0000 Subject: Re: [OT] Does the ATA 133 spec. include mechanical details? From: Danny Cox To: freemyer-ml@NorcrossGroup.com Cc: XFS Mailing List In-Reply-To: <1073948203.8061.7.camel@david.internal.NorcrossGroup.com> References: <1073948203.8061.7.camel@david.internal.NorcrossGroup.com> Content-Type: text/plain Organization: No Organization at ALL Message-Id: <1074032800.12677.6.camel@pip> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 13 Jan 2004 17:26:40 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1734 X-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: 1130 Lines: 30 Greg, On Mon, 2004-01-12 at 17:56, Greg Freemyer wrote: > But it looks like it requires the power and ATA connector to be at > specific physical locations on the drive. I know that older IDE drives > did not have a consistent location for these connectors, so I'm nervous > about buying it. > > Does anyone know if the ATA 133 spec. requires the connectors be in a > specific location, and if so are any of the older drives likely to also > use the same physical layout? Sometimes: in the Snap Appliance (nee Quantum) 12 drive NAS box, we had drive trays to hold the drives, and provide the slide for the hot-swap capability (and a common plug at the back for both power and data). We had at least two kinds: one for IBM DeathStars, and one for Western Digital. We found later that Seagate would also fit the IBM trays. All of these AFAIK, were ATA 100, not 133. I *don't* know about newer drives, but I strongly suspect that the "standard" is still what it was: do whatever feels good! Good luck! -- 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 Wed Jan 14 09:10:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 09:11:06 -0800 (PST) Received: from shoshana.dnsalias.org (c-67-163-24-167.client.comcast.net [67.163.24.167]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EHAs6H001050 for ; Wed, 14 Jan 2004 09:10:55 -0800 Received: (qmail 8918 invoked by uid 501); 14 Jan 2004 17:10:48 -0000 Date: Wed, 14 Jan 2004 11:10:48 -0600 From: John Palkovic To: linux-xfs@oss.sgi.com Subject: 2.4.25-pre4 build failure Message-ID: <20040114171048.GA8799@gx110> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 1735 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scientist@palkovic.org Precedence: bulk X-list: linux-xfs Content-Length: 1908 Lines: 47 Pentium III, debian unstable, 2.4.25-pre4 kernel tree. Updated my kernel tree with 'cvs update -d', then did a 'fakeroot make-kpkg --revision=jp1.05 kernel-image', build fails thusly: gcc -D__KERNEL__ -I/home/src/linux-2.4-xfs/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -I.. -I. -funsigned-char -nostdinc -iwithprefix include -DKBUILD_BASENAME=xfs_globals -DEXPORT_SYMTAB -c xfs_globals.c xfs_globals.c:374: error: xfs_acl_vtoacl' undeclared here (not in a function) xfs_globals.c:374: error: initializer element is not constant xfs_globals.c:374: error: (near initialization for __ksymtab_xfs_acl_vtoacl.value') xfs_globals.c:375: error: xfs_acl_inherit' undeclared here (not in a function) xfs_globals.c:375: error: initializer element is not constant xfs_globals.c:375: error: (near initialization for __ksymtab_xfs_acl_inherit.value') xfs_globals.c:374: error: __ksymtab_xfs_acl_vtoacl causes a section type conflict xfs_globals.c:375: error: __ksymtab_xfs_acl_inherit causes a section type conflict make[5]: *** [xfs_globals.o] Error 1 make[5]: Leaving directory /home/src/linux-2.4-xfs/fs/xfs/linux-2.4' make[4]: *** [first_rule] Error 2 make[4]: Leaving directory /home/src/linux-2.4-xfs/fs/xfs/linux-2.4' make[3]: *** [_subdir_linux-2.4] Error 2 make[3]: Leaving directory /home/src/linux-2.4-xfs/fs/xfs' make[2]: *** [_subdir_xfs] Error 2 make[2]: Leaving directory /home/src/linux-2.4-xfs/fs' make[1]: *** [_dir_fs] Error 2 make[1]: Leaving directory /home/src/linux-2.4-xfs' make: *** [stamp-build] Error 2 The .config file used can be viewed at http://home.comcast.net/~zl84842g/dot-config regards, -John Palkovic -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell From owner-linux-xfs@oss.sgi.com Wed Jan 14 12:51:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 12:51:57 -0800 (PST) Received: from alienAngel.upjs.sk (gprs152-111.eurotel.cz [160.218.152.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EKpE6H010859 for ; Wed, 14 Jan 2004 12:51:17 -0800 Received: by alienAngel.upjs.sk (Postfix, from userid 500) id 656FC193; Wed, 14 Jan 2004 21:51:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by alienAngel.upjs.sk (Postfix) with ESMTP id 55D0E192; Wed, 14 Jan 2004 21:51:45 +0100 (CET) Date: Wed, 14 Jan 2004 21:51:45 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: John Palkovic Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.25-pre4 build failure In-Reply-To: <20040114171048.GA8799@gx110> Message-ID: References: <20040114171048.GA8799@gx110> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1736 X-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 Content-Length: 5905 Lines: 100 On Wed, 14 Jan 2004, John Palkovic wrote: > Pentium III, debian unstable, 2.4.25-pre4 kernel tree. Updated my kernel > tree with 'cvs update -d', then did a It seems that that 2.6 tree is broken too. I updated my tree from sgi cvs and I noticed that dmapi option is missed. Since sgi cvs kernel is in version 2.6.1, it contains files from 2.6.0 which are removed in vanila 2.6.1 kernel (for example arch/arm/boot/compressed/head-integrator.S). But worser is that compilation ended with errors included below. After this knowledge I used vanila 2.6.1 and replaced content of xfs directory with xfs-linux from cvs. But file xfs/quota/xfs_qm_bhv.c contains bhv_module_init, bhv_module_exit and XFS_QMOPS which are defined only in linux-2.4/xfs_vfs.h. I must have removed quota to compile kernel. So I think that after merge is cvs in bad condition. :( CC fs/xfs/xfs_dmops.o In file included from fs/xfs/xfs.h:56, from fs/xfs/xfs_dmops.c:32: fs/xfs/linux-2.6/xfs_linux.h:87: warning: type defaults to `int' in declaration of `BUFFER_FNS' fs/xfs/linux-2.6/xfs_linux.h:87: warning: parameter names (without types) in function declaration fs/xfs/linux-2.6/xfs_linux.h:87: warning: data definition has no type or storage class fs/xfs/linux-2.6/xfs_linux.h: In function `set_buffer_unwritten_io': fs/xfs/linux-2.6/xfs_linux.h:90: error: dereferencing pointer to incomplete type In file included from fs/xfs/xfs_dmops.c:37: fs/xfs/xfs_log.h: At top level: fs/xfs/xfs_log.h:159: warning: `struct xfs_buftarg' declared inside parameter list fs/xfs/xfs_log.h:159: warning: its scope is only this definition or declaration, which is probably not what you want fs/xfs/xfs_log.h:185: warning: `struct xfs_buf' declared inside parameter list In file included from fs/xfs/xfs_dmops.c:44: fs/xfs/xfs_mount.h:315: error: parse error before "xfs_buftarg_t" fs/xfs/xfs_mount.h:315: warning: no semicolon at end of struct or union fs/xfs/xfs_mount.h:316: warning: type defaults to `int' in declaration of `m_logdev_targp' fs/xfs/xfs_mount.h:316: warning: data definition has no type or storage class fs/xfs/xfs_mount.h:317: error: parse error before '*' token fs/xfs/xfs_mount.h:317: warning: type defaults to `int' in declaration of `m_rtdev_targp' fs/xfs/xfs_mount.h:317: warning: data definition has no type or storage class fs/xfs/xfs_mount.h:387: error: parse error before '}' token fs/xfs/xfs_mount.h:387: warning: type defaults to `int' in declaration of `xfs_mount_t' fs/xfs/xfs_mount.h:387: warning: data definition has no type or storage class fs/xfs/xfs_mount.h:506: error: parse error before '*' token fs/xfs/xfs_mount.h:507: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h: In function `XFS_DADDR_TO_AGNO': fs/xfs/xfs_mount.h:508: error: `d' undeclared (first use in this function) fs/xfs/xfs_mount.h:508: error: (Each undeclared identifier is reported only once fs/xfs/xfs_mount.h:508: error: for each function it appears in.) fs/xfs/xfs_mount.h:508: error: `mp' undeclared (first use in this function) fs/xfs/xfs_mount.h: At top level: fs/xfs/xfs_mount.h:519: error: parse error before '*' token fs/xfs/xfs_mount.h:520: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h: In function `XFS_DADDR_TO_AGBNO': fs/xfs/xfs_mount.h:521: error: `d' undeclared (first use in this function) fs/xfs/xfs_mount.h:521: error: `mp' undeclared (first use in this function) fs/xfs/xfs_mount.h: At top level: fs/xfs/xfs_mount.h:540: error: parse error before '*' token fs/xfs/xfs_mount.h:540: warning: type defaults to `int' in declaration of `xfs_mount_init' fs/xfs/xfs_mount.h:540: warning: data definition has no type or storage class fs/xfs/xfs_mount.h:542: error: parse error before '*' token fs/xfs/xfs_mount.h:542: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:543: error: parse error before "xfs_mount_t" fs/xfs/xfs_mount.h:543: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:545: error: parse error before '*' token fs/xfs/xfs_mount.h:545: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:546: error: parse error before '*' token fs/xfs/xfs_mount.h:546: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:547: error: parse error before '*' token fs/xfs/xfs_mount.h:547: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:548: error: parse error before '*' token fs/xfs/xfs_mount.h:548: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:549: error: parse error before '*' token fs/xfs/xfs_mount.h:549: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:550: error: parse error before '*' token fs/xfs/xfs_mount.h:551: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:552: error: parse error before '*' token fs/xfs/xfs_mount.h:552: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:553: error: parse error before '*' token fs/xfs/xfs_mount.h:553: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:554: error: parse error before '*' token fs/xfs/xfs_mount.h:554: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:556: error: parse error before '*' token fs/xfs/xfs_mount.h:556: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:557: error: parse error before '*' token fs/xfs/xfs_mount.h:557: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:567: error: parse error before '*' token fs/xfs/xfs_mount.h:567: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:568: error: parse error before '*' token fs/xfs/xfs_mount.h:568: warning: function declaration isn't a prototype fs/xfs/xfs_mount.h:569: error: parse error before '*' token fs/xfs/xfs_mount.h:569: warning: function declaration isn't a prototype make[2]: *** [fs/xfs/xfs_dmops.o] Error 1 make[1]: *** [fs/xfs] Error 2 make: *** [fs] Error 2 jan -- From owner-linux-xfs@oss.sgi.com Wed Jan 14 14:16:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 14:17:13 -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 i0EMGn6H013411 for ; Wed, 14 Jan 2004 14:16:52 -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 i0EMGfuq020247 for ; Wed, 14 Jan 2004 16:16:41 -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_force_shutdown from line 1071 of xfs_trans.c Date: Wed, 14 Jan 2004 16:18:48 -0600 X-Mailer: Apple Mail (2.609) X-archive-position: 1737 X-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: 2027 Lines: 54 Hi, I have a ~ 80GB parition (5 disk hardware RAID 0) on a two processor Dell 2650. I have seen two xfs_force_shutdowns on it in the last few days. The filesystem is accessed largely via NFS by between 50 or 100 processes on remote machines. I'm currently running 2.4.20-28_36.rh8.0.atsmp which is XFS 1.3.0. There are no other logs in either syslog or dmesg. Here's the error message: Jan 14 10:27:16 glimpse4 kernel: xfs_force_shutdown(sd(8,5),0x8) called from line 1071 of file xfs_trans.c. Return address = 0xf88d26eb Jan 14 10:27:16 glimpse4 kernel: Filesystem "sd(8,5)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,5) Jan 14 10:27:16 glimpse4 kernel: Please umount the filesystem, and rectify the problem(s) Jan 14 10:27:16 glimpse4 kernel: xfs_force_shutdown(sd(8,5),0x2) called from line 747 of file xfs_log.c. Return address = 0xf88d26eb For various reasons I was running an older kernel 1.2.0 when this first showed up. The message from 1.2.0 appears to be an old bug (see http://oss.sgi.com/bugzilla/show_bug.cgi?id=186). Here's the message from that kernel: Jan 11 13:22:32 glimpse4 kernel: xfs_force_shutdown(sd(8,5),0x8) called from line 1042 of file xfs_trans.c. Return address = 0xc01d3738 Jan 11 13:22:32 glimpse4 kernel: xfs_force_shutdown(sd(8,5),0x2) called from line 721 of file xfs_log.c. Return address = 0xc01c53a1 Here's the output from xfs_info xfs_info /usr/data/glimpse4 meta-data=/usr/data/glimpse4 isize=256 agcount=20, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=20384469, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=2488, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Should I backup, mkfs and restore? ------- Stephan From owner-linux-xfs@oss.sgi.com Wed Jan 14 15:02:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 15:02:52 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EN2C6H016305 for ; Wed, 14 Jan 2004 15:02:12 -0800 Received: from naboo.americas.sgi.com ([128.162.233.73]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0ELpp05002143 for ; Wed, 14 Jan 2004 13:51:51 -0800 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id C22228C871E; Wed, 14 Jan 2004 14:18:16 -0600 (CST) Subject: PARTIAL TAKE 907739 - Add a condtional around some acl exported symbols. Message-Id: <20040114201816.C22228C871E@naboo.americas.sgi.com> Date: Wed, 14 Jan 2004 14:18:16 -0600 (CST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1738 X-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: 257 Lines: 11 Date: Wed Jan 14 12:17:44 PST 2004 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:164873a linux-2.4/xfs_globals.c - 1.68 From owner-linux-xfs@oss.sgi.com Wed Jan 14 15:45:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 15:45:48 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ENjJ6H018437 for ; Wed, 14 Jan 2004 15:45:19 -0800 Received: from naboo.americas.sgi.com ([128.162.233.73]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0F0jhd3015419 for ; Wed, 14 Jan 2004 16:45:43 -0800 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id 4FCD78C871E; Wed, 14 Jan 2004 17:44:53 -0600 (CST) Subject: TAKE 907739 - Fix quota build on linux 2.6 after the -dev merge Message-Id: <20040114234453.4FCD78C871E@naboo.americas.sgi.com> Date: Wed, 14 Jan 2004 17:44:53 -0600 (CST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1739 X-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: 283 Lines: 12 Date: Wed Jan 14 15:44:27 PST 2004 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:164909a linux-2.6/xfs_vfs.h - 1.45 linux-2.6/xfs_super.c - 1.293 From owner-linux-xfs@oss.sgi.com Wed Jan 14 15:52:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 15:53:08 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ENqv6H019682 for ; Wed, 14 Jan 2004 15:52:57 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0F0rJd3019295 for ; Wed, 14 Jan 2004 16:53:20 -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 i0ENqmhI058110 for ; Thu, 15 Jan 2004 10:52:48 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0ENqm4P057962 for linux-xfs@oss.sgi.com; Thu, 15 Jan 2004 10:52:48 +1100 (EST) Date: Thu, 15 Jan 2004 10:52:48 +1100 (EST) From: Nathan Scott Message-Id: <200401142352.i0ENqm4P057962@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - update 2.6 config entries X-archive-position: 1740 X-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: 293 Lines: 12 Add in the DMAPI and debug config options for 2.6 kernels. Date: Wed Jan 14 15:52:12 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:164910a fs/Kconfig - 1.3 From owner-linux-xfs@oss.sgi.com Wed Jan 14 15:54:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 15:54:39 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ENsR6H020415 for ; Wed, 14 Jan 2004 15:54:27 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0F0skd3019532 for ; Wed, 14 Jan 2004 16:54:50 -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 i0ENsAhI059244 for ; Thu, 15 Jan 2004 10:54:10 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0ENs96k059251 for linux-xfs@oss.sgi.com; Thu, 15 Jan 2004 10:54:09 +1100 (EST) Date: Thu, 15 Jan 2004 10:54:09 +1100 (EST) From: Nathan Scott Message-Id: <200401142354.i0ENs96k059251@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - remove empty files X-archive-position: 1741 X-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: 650 Lines: 20 Remove deleted files overlooked in previous merge. Date: Wed Jan 14 15:53:33 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:164911a arch/arm/boot/compressed/head-integrator.S - 1.2 drivers/media/dvb/ttpci/av7110_firm.h - 1.2 drivers/media/dvb/ttusb-dec/dec2000_frontend.c - 1.2 drivers/media/dvb/ttusb-dec/fdump.c - 1.2 drivers/media/dvb/ttusb-dec/ttusb_dec.h - 1.2 drivers/usb/storage/raw_bulk.c - 1.2 drivers/usb/storage/raw_bulk.h - 1.2 include/asm-arm26/keyboard.h.old - 1.2 security/selinux/ss/global.h - 1.2 From owner-linux-xfs@oss.sgi.com Wed Jan 14 16:16:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 16:16: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 i0F0GK6H024984 for ; Wed, 14 Jan 2004 16:16:20 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0F0GKug024983 for linux-xfs@oss.sgi.com; Wed, 14 Jan 2004 16:16:20 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i0F0GI6J024969 for ; Wed, 14 Jan 2004 16:16:18 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0ENtQ3k021361; Wed, 14 Jan 2004 15:55:26 -0800 Date: Wed, 14 Jan 2004 15:55:26 -0800 Message-Id: <200401142355.i0ENtQ3k021361@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: 1742 X-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: 300 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 ------- Additional Comments From netllama@linux-sxs.org 2004-14-01 15:55 PDT ------- Your workaround did the trick. 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 Jan 14 17:29:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 17:29:31 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F1T66H029786 for ; Wed, 14 Jan 2004 17:29:06 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0ELK805028867 for ; Wed, 14 Jan 2004 13:20:08 -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 i0EKJcPW29501145; Wed, 14 Jan 2004 14:19:38 -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 i0EKJHoZ3619730; Wed, 14 Jan 2004 14:19:33 -0600 (CST) Subject: Re: 2.4.25-pre4 build failure From: Russell Cattelan To: John Palkovic Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040114171048.GA8799@gx110> References: <20040114171048.GA8799@gx110> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8YGdK8TPRK1njlUBV2Nd" Message-Id: <1074111557.28397.188.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-2mdk Date: Wed, 14 Jan 2004 14:19:17 -0600 X-archive-position: 1743 X-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: 2443 Lines: 70 --=-8YGdK8TPRK1njlUBV2Nd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Opps missed the case where acl's were not configed on. Fixed. -Russell On Wed, 2004-01-14 at 11:10, John Palkovic wrote: > Pentium III, debian unstable, 2.4.25-pre4 kernel tree. Updated my kernel > tree with 'cvs update -d', then did a=20 > 'fakeroot make-kpkg --revision=3Djp1.05 kernel-image', build fails thusly: >=20 > gcc -D__KERNEL__ -I/home/src/linux-2.4-xfs/include -Wall -Wstrict-prototy= pes > -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer > -pipe -mpreferred-stack-boundary=3D2 -march=3Di686 -I.. -I. -funsigned-c= har > -nostdinc -iwithprefix include -DKBUILD_BASENAME=3Dxfs_globals > -DEXPORT_SYMTAB -c xfs_globals.c > xfs_globals.c:374: error: xfs_acl_vtoacl' undeclared here (not in a funct= ion) > xfs_globals.c:374: error: initializer element is not constant > xfs_globals.c:374: error: (near initialization for > __ksymtab_xfs_acl_vtoacl.value') > xfs_globals.c:375: error: xfs_acl_inherit' undeclared here (not in a func= tion) > xfs_globals.c:375: error: initializer element is not constant > xfs_globals.c:375: error: (near initialization for > __ksymtab_xfs_acl_inherit.value') > xfs_globals.c:374: error: __ksymtab_xfs_acl_vtoacl causes a section type > conflict > xfs_globals.c:375: error: __ksymtab_xfs_acl_inherit causes a section type > conflict > make[5]: *** [xfs_globals.o] Error 1 > make[5]: Leaving directory /home/src/linux-2.4-xfs/fs/xfs/linux-2.4' > make[4]: *** [first_rule] Error 2 > make[4]: Leaving directory /home/src/linux-2.4-xfs/fs/xfs/linux-2.4' > make[3]: *** [_subdir_linux-2.4] Error 2 > make[3]: Leaving directory /home/src/linux-2.4-xfs/fs/xfs' > make[2]: *** [_subdir_xfs] Error 2 > make[2]: Leaving directory /home/src/linux-2.4-xfs/fs' > make[1]: *** [_dir_fs] Error 2 > make[1]: Leaving directory /home/src/linux-2.4-xfs' > make: *** [stamp-build] Error 2 >=20 > The .config file used can be viewed at >=20 > http://home.comcast.net/~zl84842g/dot-config >=20 > regards, >=20 > -John Palkovic >=20 --=-8YGdK8TPRK1njlUBV2Nd 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) iD8DBQBABaRFNRmM+OaGhBgRArNkAJ4vl+Fsv4ggMVba7mA9OUVcpzoY8QCfX8Xd ttrzLxauq+BsRHyn2ZoTBSE= =GxF6 -----END PGP SIGNATURE----- --=-8YGdK8TPRK1njlUBV2Nd-- From owner-linux-xfs@oss.sgi.com Wed Jan 14 20:51:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 20:51:45 -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 i0F4pX6H005659 for ; Wed, 14 Jan 2004 20:51:33 -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 i0F4pViS027978 for ; Wed, 14 Jan 2004 23:51:31 -0500 (EST) Date: Wed, 14 Jan 2004 23:51:31 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: Re: advice: 3ware+raid+xfs In-Reply-To: <1070823336.1358.5.camel@pip> Message-ID: References: <1070823336.1358.5.camel@pip> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1744 X-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: 811 Lines: 25 Hi, Some time ago I asked for advice regarding a 3ware + raid setup on XFS, and I got a LOT of help, such as - what kind of RAID is recommended, - be careful with WD drives, - use LVM2 + XFS, etc. Finally I have all the 4x250Gb WD disks arranged in hardware RAID-5, and I am ready to make xfs under RH9.0, kernel 2.4.23. I remember a discussion on sunit, swidth, logsize, and external/internal log, and frankly, after looking back to the messages, I feel confused. I'd appreciate a little guidance on what exact options should I use with mkfs.xfs, such as: mkfs.xfs -d su=?,sw=? -l size=?,sunit=?? ... What I know is that the hw RAID-5 stripe size is 64K. I have 4 disks => sw=3. I will have typically 8-16Mb files on the disk plus lots small files (i.e. I can't specify well in advance). Thanks, Gaspar From owner-linux-xfs@oss.sgi.com Wed Jan 14 21:40:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 21:40:42 -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 i0F5eU6H006960 for ; Wed, 14 Jan 2004 21:40:30 -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 VAA26110; Wed, 14 Jan 2004 21:40:38 -0800 Message-Id: <200401150540.VAA26110@amber.he.net> From: "Mike Young" To: , Subject: RE: advice: 3ware+raid+xfs Date: Wed, 14 Jan 2004 21:42:41 -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: Thread-Index: AcPbI092170pd0nOT9W3qvLa+I5XlAABo0TQ X-archive-position: 1745 X-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: 1510 Lines: 51 Hi Gaspar, I would certainly be sure to use the external journal. In order to do this with our 3Ware RAID-5, take the resulting RAID (say /dev/sda) and partition it with sda1 being around 256MB. Then create sda2 using the rest of the data. After that, I'd use the following command: "mkfs.xfs -f /dev/sda2 -l logdev=/dev/sda1,size=32000b" To mount this, I'd use "mount -t xfs /dev/sda2 -o logdev=/dev/sda1 /mnt". I'm sure others have other ideas too. -Mike -----Original Message----- From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Gaspar Bakos Sent: Wednesday, January 14, 2004 8:52 PM To: linux-xfs@oss.sgi.com Subject: Re: advice: 3ware+raid+xfs Hi, Some time ago I asked for advice regarding a 3ware + raid setup on XFS, and I got a LOT of help, such as - what kind of RAID is recommended, - be careful with WD drives, - use LVM2 + XFS, etc. Finally I have all the 4x250Gb WD disks arranged in hardware RAID-5, and I am ready to make xfs under RH9.0, kernel 2.4.23. I remember a discussion on sunit, swidth, logsize, and external/internal log, and frankly, after looking back to the messages, I feel confused. I'd appreciate a little guidance on what exact options should I use with mkfs.xfs, such as: mkfs.xfs -d su=?,sw=? -l size=?,sunit=?? ... What I know is that the hw RAID-5 stripe size is 64K. I have 4 disks => sw=3. I will have typically 8-16Mb files on the disk plus lots small files (i.e. I can't specify well in advance). Thanks, Gaspar From owner-linux-xfs@oss.sgi.com Wed Jan 14 23:48:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Jan 2004 23:48:29 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F7m76H009975 for ; Wed, 14 Jan 2004 23:48:08 -0800 Received: from auto-nb1.xs4all.nl (host-2.coltex.demon.nl [212.238.252.66]) (authenticated bits=0) by smtpzilla3.xs4all.nl (8.12.10/8.12.10) with ESMTP id i0F7m1Rb066832; Thu, 15 Jan 2004 08:48:03 +0100 (CET) Message-Id: <4.3.2.7.2.20040115084408.044a32e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Jan 2004 08:48:00 +0100 To: Stephan L Jansen , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfs_force_shutdown from line 1071 of xfs_trans.c In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1746 X-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: 1216 Lines: 36 At 16:18 14-1-2004 -0600, Stephan L Jansen wrote: >Hi, > >I have a ~ 80GB parition (5 disk hardware RAID 0) on a two processor Dell >2650. I >have seen two xfs_force_shutdowns on it in the last few days. The >filesystem is >accessed largely via NFS by between 50 or 100 processes on remote >machines. I'm >currently running 2.4.20-28_36.rh8.0.atsmp which is XFS 1.3.0. There are >no other >logs in either syslog or dmesg. Here's the error message: If it's a Perc3/Di it's a adaptec (aacraid) controller. Basically it is crap piece of hardware that falls apart under load. There is a workaround which you can found on the just launched http://linux.dell.com/ The scsi layer in the Perc3 gets stuck often which results in the controller firmware deadlocking. Upping a certain timeout in the driver to 60 seconds will prevent this from throwing a IO error to the kernel but the box will stall for a seemingly long time. The best workaround for the moment is using either software raid or purchasing a Perc3/DC or better yet a Perc4/DC. Both are also faster and a lot faster respectively with regards to raid 5 throughput. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Thu Jan 15 00:01:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 00:02:08 -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 i0F81t6H010922 for ; Thu, 15 Jan 2004 00:01:56 -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.10/8.12.10) with ESMTP id i0F81lCs024947; Thu, 15 Jan 2004 09:01:48 +0100 (CET) Message-Id: <4.3.2.7.2.20040115084911.03d8b008@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Jan 2004 09:01:46 +0100 To: "Mike Young" , , From: Seth Mos Subject: RE: advice: 3ware+raid+xfs In-Reply-To: <200401150540.VAA26110@amber.he.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1747 X-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: 1120 Lines: 32 At 21:42 14-1-2004 -0800, Mike Young wrote: >Hi Gaspar, > >I would certainly be sure to use the external journal. In order to do this >with our 3Ware RAID-5, take the resulting RAID (say /dev/sda) and partition >it with sda1 being around 256MB. Then create sda2 using the rest of the >data. Using the external journal gives the most benefit on Linux software raid volumes. Put the log on another partition on the same logical disk doesn't make sense to me. My suggestions are using sunit=4096 and swidth=3 (n-1). You could use a larger stripeunit sizes but I don't remember helping it much. Besides that, using a 64k stripe will results in 192k total stripe size. You need to specify this on the mount command since the default mounts upto 64k in stripe size. I tested this some months ago on a 6 disk configuration and the results did not differ much from the defaults. Creating a larger log will help the filesystem if you perform a lot of operations on it. I create my larger filesystems this way. It helps a lot on the IOPS. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Thu Jan 15 00:14:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 00:15:02 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F8EY6H011743 for ; Thu, 15 Jan 2004 00:14:35 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i0ENlsd3030249 for ; Wed, 14 Jan 2004 15:47:56 -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 JAA15079; Thu, 15 Jan 2004 09:47:19 +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 i0EMlFUc3204273; Thu, 15 Jan 2004 09:47:15 +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 i0EMkGrW000886; Thu, 15 Jan 2004 09:46:17 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i0EMkEPh000884; Thu, 15 Jan 2004 09:46:14 +1100 Date: Thu, 15 Jan 2004 09:46:14 +1100 From: Nathan Scott To: Jan Derfinak , John Palkovic Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.25-pre4 build failure Message-ID: <20040114224613.GC654@frodo> References: <20040114171048.GA8799@gx110> 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: 1748 X-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: 1225 Lines: 32 On Wed, Jan 14, 2004 at 09:51:45PM +0100, Jan Derfinak wrote: > On Wed, 14 Jan 2004, John Palkovic wrote: > > > Pentium III, debian unstable, 2.4.25-pre4 kernel tree. Updated my kernel > > tree with 'cvs update -d', then did a > > It seems that that 2.6 tree is broken too. I updated my tree from sgi cvs > and I noticed that dmapi option is missed. Since sgi cvs kernel is in I've got that in a workarea (the debug options are missing too), I'll check that in shortly. > version 2.6.1, it contains files from 2.6.0 which are removed in vanila > 2.6.1 kernel (for example arch/arm/boot/compressed/head-integrator.S). But Oh, I musta botched the merge a bit, thanks - I'll fix that up. > worser is that compilation ended with errors included below. After this > knowledge I used vanila 2.6.1 and replaced content of xfs directory with > xfs-linux from cvs. But file xfs/quota/xfs_qm_bhv.c contains > bhv_module_init, bhv_module_exit and XFS_QMOPS which are defined only in > linux-2.4/xfs_vfs.h. I must have removed quota to compile kernel. So > I think that after merge is cvs in bad condition. :( I think I saw a fix go past from Russell for that one, it should show up in cvs before too long. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jan 15 10:40:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 10:41:08 -0800 (PST) Received: from mail.tivo.com (host25.tivo.com [204.176.49.25]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FIeu6H031822 for ; Thu, 15 Jan 2004 10:40:56 -0800 Received: from CORPEXCH01.Tivo.com (localhost [127.0.0.1]) by mail.tivo.com (8.11.5/8.11.5) with ESMTP id i0FIeon29894 for ; Thu, 15 Jan 2004 10:40:50 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: XFS on Redhat Linux Date: Thu, 15 Jan 2004 10:35:40 -0800 Message-ID: <8428736BC3F90F49A74EE3AF7433AF56451AC1@CORPEXCH01.Tivo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS on Redhat Linux Thread-Index: AcPblmB/n2WbvQeRSTO0ducF5wwXkQ== From: "Anandha Krishnan" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0FIeu6H031844 X-archive-position: 1749 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: anandha@tivo.com Precedence: bulk X-list: linux-xfs Content-Length: 340 Lines: 11 Hi, I would like to get XFS on Redhat Linux 9.0 and I'm new to this field. I would really appreciate if someone could send me instructions on how get the xfs kernel compiled, tuned and create a xfs file system. I have tried to compile a sgi kernel but couldn't create a file system. Any help would be greatly appreciated. Thanks Anandha From owner-linux-xfs@oss.sgi.com Thu Jan 15 11:46:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 11:46:58 -0800 (PST) Received: from coredumps.de (coredumps.de [217.160.213.75]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJkh6H003877 for ; Thu, 15 Jan 2004 11:46:46 -0800 Received: from port-212-202-54-209.reverse.qsc.de ([212.202.54.209] helo=ente.berdmann.de) by coredumps.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1AhDRy-0003eD-Mn; Thu, 15 Jan 2004 20:46:42 +0100 Received: from octane.berdmann.de ([192.168.1.14] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1AhDRy-0005J8-00; Thu, 15 Jan 2004 20:46:42 +0100 Message-ID: <4006EE21.10007@berdmann.de> Date: Thu, 15 Jan 2004 20:46:41 +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: Anandha Krishnan CC: linux-xfs@oss.sgi.com Subject: Re: XFS on Redhat Linux References: <8428736BC3F90F49A74EE3AF7433AF56451AC1@CORPEXCH01.Tivo.com> In-Reply-To: <8428736BC3F90F49A74EE3AF7433AF56451AC1@CORPEXCH01.Tivo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1750 X-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: 429 Lines: 12 Anandha Krishnan wrote: > Hi, > > I would like to get XFS on Redhat Linux 9.0 and I'm new to this field. I > would really appreciate if someone could send me instructions on how get > the xfs kernel compiled, tuned and create a xfs file system. I have > tried to compile a sgi kernel but couldn't create a file system. Any > help would be greatly appreciated. Hi, you need the userspace tools like xfsprogs to have mkfs.xfs. From owner-linux-xfs@oss.sgi.com Thu Jan 15 11:53:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 11:53:56 -0800 (PST) Received: from mail.mnsu.edu (Mail.MNSU.EDU [134.29.1.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJri6H005793 for ; Thu, 15 Jan 2004 11:53:45 -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 i0FJrdHM014419 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 15 Jan 2004 13:53:39 -0600 Message-ID: <4006EFC3.9080800@mnsu.edu> Date: Thu, 15 Jan 2004 13:53:39 -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: linux-xfs@oss.sgi.com Subject: Question about new cvsup tree Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1751 X-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: 341 Lines: 13 Hello, What is the procedure for using the new tree produced by cvsup? All that seems to exist is the changes need for linux-2.4.x AND? linux-2.6.x is this true? How to I apply these changes? ...and it must only apply to certain 2.4 and 2.6 kernels. Which ones? Sorry for all of the stupid questions. Sincerely, Jeffrey Hundstad From owner-linux-xfs@oss.sgi.com Thu Jan 15 12:11:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 12:11:15 -0800 (PST) Received: from mail.tivo.com (host25.tivo.com [204.176.49.25]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FKAx6H007565 for ; Thu, 15 Jan 2004 12:11:04 -0800 Received: from CORPEXCH01.Tivo.com (localhost [127.0.0.1]) by mail.tivo.com (8.11.5/8.11.5) with ESMTP id i0FKApq07217; Thu, 15 Jan 2004 12:10:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: XFS on Redhat Linux Date: Thu, 15 Jan 2004 12:10:06 -0800 Message-ID: <8428736BC3F90F49A74EE3AF7433AF56B2137F@CORPEXCH01.Tivo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS on Redhat Linux Thread-Index: AcPboFHO4wTBuyBTSFGK+uMnPpKjSgAAy6jg From: "Anandha Krishnan" To: "Bernhard Erdmann" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0FKB46H007568 X-archive-position: 1752 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: anandha@tivo.com Precedence: bulk X-list: linux-xfs Content-Length: 703 Lines: 27 Thanks for help. I found out that later and got it working. Anandha -----Original Message----- From: Bernhard Erdmann [mailto:be@berdmann.de] Sent: Thursday, January 15, 2004 11:47 AM To: Anandha Krishnan Cc: linux-xfs@oss.sgi.com Subject: Re: XFS on Redhat Linux Anandha Krishnan wrote: > Hi, > > I would like to get XFS on Redhat Linux 9.0 and I'm new to this field. > I would really appreciate if someone could send me instructions on how > get the xfs kernel compiled, tuned and create a xfs file system. I > have tried to compile a sgi kernel but couldn't create a file system. > Any help would be greatly appreciated. Hi, you need the userspace tools like xfsprogs to have mkfs.xfs. From owner-linux-xfs@oss.sgi.com Thu Jan 15 15:08:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 15:08:19 -0800 (PST) Received: from c-65-34-128-210.se.client2.attbi.com (c-65-34-128-210.se.client2.attbi.com [65.34.128.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FN87NT004846 for ; Thu, 15 Jan 2004 15:08:10 -0800 Received: from (HELO syn) [94.174.147.103] by c-65-34-128-210.se.client2.attbi.com id ZI35ApIq9jrl; Thu, 15 Jan 2004 17:02:04 -0600 Message-ID: From: "Ollie Wu" Reply-To: "Ollie Wu" To: Subject: Re: fantastic Date: Thu, 15 Jan 04 17:02:04 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="88F_941_16.DADE.EB_" X-Priority: 3 X-MSMail-Priority: Normal X-archive-position: 1756 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mo786j@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 4975 Lines: 143 --88F_941_16.DADE.EB_ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
ELIMINATE YOUR CREDIT CARD DEBT WITHOUT BANKRUPTCY!

Tired= of making minimum payments and barely getting by?

This is NOT consolid= ation or negotiation...

This is COMPLETE DEBT ELIMINATION

STOP MAKING PAYMENTS IMMEDIATELY!
Are you drowning in debt?

Here's what we can do= for YOU...
  1. Te= rminate your credit card debt!
  2. Allow you to stop making payments immediately!
  3. Obtain a ZERO BALANCE statement from your creditors!
Unlike bankruptcy, this is COMPLETELY PRIVATE and will
NOT DAMA<= !ng iuv>GE YOUR CREDIT REPORT!
You will N= OT lose your home or any other assets!











Please end future announcements



n ojcipjf a --88F_941_16.DADE.EB_-- From owner-linux-xfs@oss.sgi.com Thu Jan 15 17:14:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 17:14:43 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G1EbNT014893 for ; Thu, 15 Jan 2004 17:14:38 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i0G1Cvge027451 for ; Thu, 15 Jan 2004 16:12:57 -0900 Date: Thu, 15 Jan 2004 16:12:57 -0900 (AKST) From: Arthur Corliss X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: linux-xfs@oss.sgi.com Subject: List configuration Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1767 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@digitalmages.com Precedence: bulk X-list: linux-xfs Content-Length: 603 Lines: 15 Greetings: I don't know who thought it was a good idea to run an open list, but this last week I've been getting pounded with spam because I had the misfortunate of whitelisting sgi's domains until my filters were well trained. Quite frankly, that wouldn't be that much of a problem if your config was saner. Somebody *please* unscrew your list servers before I'm forced to unsubscribe and blacklist these boxes... --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ "Live Free or Die, the Only Way to Live" -- NH State Motto From owner-linux-xfs@oss.sgi.com Thu Jan 15 18:44:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 18:44:54 -0800 (PST) Received: from shksmtp02.so-net.com.hk (pop3.so-net.com.hk [203.99.142.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G2icNT017418 for ; Thu, 15 Jan 2004 18:44:41 -0800 Received: (qmail 11377 invoked from network); 16 Jan 2004 02:44:30 -0000 Received: from so224187.bbo224.so-net.com.hk (HELO linuxmail.org) ([203.176.224.187]) (envelope-sender ) by shksmtp02.so-net.com.hk (qmail-ldap-1.03) with SMTP for ; 16 Jan 2004 02:44:30 -0000 Message-ID: <4007500D.1060806@linuxmail.org> Date: Fri, 16 Jan 2004 10:44:29 +0800 From: Feizhou 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 CC: linux-xfs@oss.sgi.com Subject: Re: List configuration References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1768 X-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: 641 Lines: 20 Arthur Corliss wrote: > Greetings: > > I don't know who thought it was a good idea to run an open list, but this last > week I've been getting pounded with spam because I had the misfortunate of > whitelisting sgi's domains until my filters were well trained. Quite frankly, > that wouldn't be that much of a problem if your config was saner. > Open list? I had to confirm my subscription. You even get spam on the qmail list which requires you send a confirmation for EACH post. Rule No. 2. Spammers are STUPID > Somebody *please* unscrew your list servers before I'm forced to unsubscribe > and blacklist these boxes... Get real. From owner-linux-xfs@oss.sgi.com Thu Jan 15 21:10:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 21:11:05 -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 i0G5AbNT029036 for ; Thu, 15 Jan 2004 21:10:40 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 8329D141B138; Fri, 16 Jan 2004 00:10:44 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id A9F5B141B136; Fri, 16 Jan 2004 00:10:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 9D7ED30001A3; Fri, 16 Jan 2004 00:10:42 -0500 (EST) Date: Fri, 16 Jan 2004 00:10:42 -0500 (EST) From: Mike Burger To: Feizhou Cc: linux-xfs@oss.sgi.com Subject: Re: List configuration In-Reply-To: <4007500D.1060806@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: 1769 X-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: 1024 Lines: 37 On Fri, 16 Jan 2004, Feizhou wrote: > Arthur Corliss wrote: > > Greetings: > > > > I don't know who thought it was a good idea to run an open list, but this last > > week I've been getting pounded with spam because I had the misfortunate of > > whitelisting sgi's domains until my filters were well trained. Quite frankly, > > that wouldn't be that much of a problem if your config was saner. > > > > Open list? I had to confirm my subscription. > > You even get spam on the qmail list which requires you send a > confirmation for EACH post. This list is open in that anyone can send to it...you don't have to be a subscriber to send to it...just to receive from 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 Thu Jan 15 21:27:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 21:27: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 i0G5RRNT030400 for ; Thu, 15 Jan 2004 21:27:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0G5RQ0T030399 for linux-xfs@oss.sgi.com; Thu, 15 Jan 2004 21:27: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 i0G5RNNV030384 for ; Thu, 15 Jan 2004 21:27:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0G4qSRX027590; Thu, 15 Jan 2004 20:52:28 -0800 Date: Thu, 15 Jan 2004 20:52:28 -0800 Message-Id: <200401160452.i0G4qSRX027590@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 303] New: Kernel Panic on umount X-Bugzilla-Reason: AssignedTo X-archive-position: 1770 X-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: 1098 Lines: 40 http://oss.sgi.com/bugzilla/show_bug.cgi?id=303 Summary: Kernel Panic on umount Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: jhaltom@feedbackplusinc.com I think it was umount. Happened during a system shutdown. I believe it was in the init shutdown process, so likely umount. Also I wrote down the call trace, and not all of it. Also my handwriting sucks. Words I can't recognize are symbolized by ????. Part-call trace: xfs_buf_iodone xfs_buf_do_callbacks xfs_buf_iodone_callbacks pagebuf_iodone_work worker_thread pagebuf_iodone_work default_????_function ret_from_fork ... cont ... It was late, didn't get it all, but this might help. Also there was a EIPPnt xfs_log_move_tail+0x1d/0x180 line. That's all I got. :) ------- 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 Jan 15 21:34:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 21:34:47 -0800 (PST) Received: from shksmtp02.so-net.com.hk (pop.so-net.com.hk [203.99.142.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G5YYNT030910 for ; Thu, 15 Jan 2004 21:34:35 -0800 Received: (qmail 3295 invoked from network); 16 Jan 2004 05:34:27 -0000 Received: from so224187.bbo224.so-net.com.hk (HELO linuxmail.org) ([203.176.224.187]) (envelope-sender ) by shksmtp02.so-net.com.hk (qmail-ldap-1.03) with SMTP for ; 16 Jan 2004 05:34:27 -0000 Message-ID: <400777E3.8090503@linuxmail.org> Date: Fri, 16 Jan 2004 13:34:27 +0800 From: Feizhou 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 CC: linux-xfs@oss.sgi.com Subject: Re: List configuration References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1771 X-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: 454 Lines: 19 > > This list is open in that anyone can send to it...you don't have to be a > subscriber to send to it...just to receive from it. > > ??? ^O^ ??? I am shocked. So I can mailbomb linux-xfs@oss.sgi.com from any address to make everyone suffer. Geez. Let me see. Create free webmail account. Run scripts. Tada! No, it is even simpler than that. Fire away at ISP smarthost and bring down linux-xfs@oss.sgi.com. Geez. it is a reason to plonk... From owner-linux-xfs@oss.sgi.com Fri Jan 16 10:52:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 10:52:45 -0800 (PST) Received: from web40602.mail.yahoo.com (web40602.mail.yahoo.com [66.218.78.139]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GIq3mK029112 for ; Fri, 16 Jan 2004 10:52:03 -0800 Message-ID: <20040116185157.94091.qmail@web40602.mail.yahoo.com> Received: from [208.35.40.2] by web40602.mail.yahoo.com via HTTP; Fri, 16 Jan 2004 10:51:57 PST Date: Fri, 16 Jan 2004 10:51:57 -0800 (PST) From: Ravi Wijayaratne Subject: Linux Page cache performance To: linux-xfs@oss.sgi.com, sandeen@sgi.com, lord@xfs.org, linux-kernel@kernel.vger.org.sgi.com Cc: kernelnewbies@nl.linux.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1772 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ravi_wija@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1663 Lines: 35 Hi All. We are running dbench on a machine with Dual Xeon (Hyper threading turned off), 1GB RAM and 4 Drive software RAID5. The kernel is 2.4.29-xfs 1.2. We are using LVM. However similar test done using ext2 on a disk partiotion (no md or LVM) shows The throughput is find till the number of clients are Around 16. At that point the throughput plummets about 40%. We are trying to avoid that and see how we could have a consistent throughput perhaps sacrificing some peak performance. One could argue that at the point the performance drops we are actualy beggining to see I/O requests missing page cache and going to disk. That is our current guess. We try to tune the buffer age and the interval page buffer daemon runs, but had no effect on the curve. So transactional meta data operations seems not be causing the bottle neck. Are there any VM patches that smooths out the Page Cache dirty page swapping process so that we wont see this sudden drop of through put, but could have a smoother transition. I ran a kernel profiler on the test and I dont see any dentry cache flushes or inode cache flushes. Similar test done using ext2 on a disk partiotion (no md or LVM) shows us similar performances. However for ext2 when we tweak the bdflush parameters in /proc (specifically the max age of meta data buffers) we can push the point where the data throughput falls to around 40 clients. But we are more interested in finding out ways to solve the XFS case. Any insights on this ? Thanx Ravi __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From owner-linux-xfs@oss.sgi.com Fri Jan 16 11:39:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 11:40:03 -0800 (PST) Received: from web41503.mail.yahoo.com (web41503.mail.yahoo.com [66.218.93.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GJdZmK031747 for ; Fri, 16 Jan 2004 11:39:35 -0800 Message-ID: <20040116193929.14027.qmail@web41503.mail.yahoo.com> Received: from [65.93.199.195] by web41503.mail.yahoo.com via HTTP; Fri, 16 Jan 2004 14:39:29 EST Date: Fri, 16 Jan 2004 14:39:29 -0500 (EST) From: Rajesh Saxena Subject: XFS and small files To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1773 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rs_404@yahoo.ca Precedence: bulk X-list: linux-xfs Content-Length: 627 Lines: 17 Hi list...... I read all the time that XFS is built to support very large files and large directories efficiently but how well does it handle small files. I want to use in a mail server running cyrus imapd. People on the lvm list pointed out that reiserfs is more suited in that area but I would prefer to have consistent filesystem on all servers. Anyone using XFS on busy mail sites? Do you have any mail usage and server performance figures? http://marc.theaimsgroup.com/?t=107420891200003&r=1&w=2 ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From owner-linux-xfs@oss.sgi.com Fri Jan 16 12:05:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 12:06:06 -0800 (PST) Received: from ms-smtp-03-eri0.texas.rr.com (ms-smtp-03.texas.rr.com [24.93.47.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GK5lmK000531 for ; Fri, 16 Jan 2004 12:05:47 -0800 Received: from johngroves.net (cs68201181-91.austin.rr.com [68.201.181.91]) by ms-smtp-03-eri0.texas.rr.com (8.12.10/8.12.7) with ESMTP id i0GK3spH020724; Fri, 16 Jan 2004 14:03:54 -0600 (CST) Message-ID: <40084436.7080804@johngroves.net> Date: Fri, 16 Jan 2004 14:06:14 -0600 From: John Groves Reply-To: jgl@johngroves.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Not getting CREATE events from dmapi Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1774 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jgl@johngroves.net Precedence: bulk X-list: linux-xfs Content-Length: 840 Lines: 21 I'm doing a dmapi handler, and I'm not receiving any DM_EVENT_CREATE or DM_EVENT_POSTCREATE events. Other events are delivered as expected (including the other async POST-whatever events and the managed region events). Just wondering if there are any known issues around this. I'm running XFS 1.2.0 as included in the 2.4.20 XFS / Redhat distribution. My dmapi library is 2.1.0-1. I don't suppose there's a version alignment requirement there?! (please clarify if so). Otherwise it appears to be working fine. A call to dm_get_eventlist() indicates that the CREATE events are enabled, so it certainly looks like xfs/dmapi thinks the event is enabled. It would appear that the DM_EVENT_ENABLED(...) macro is returning false in xfs_create(), but that's as far as I've followed as yet. Any clues appreciated. Thanks, John From owner-linux-xfs@oss.sgi.com Fri Jan 16 13:49:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 13:50:22 -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 i0GLnumK007703 for ; Fri, 16 Jan 2004 13:49:57 -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 i0GKpuFG019234 for ; Fri, 16 Jan 2004 12:51:56 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id i0GLnnAV29854744; Fri, 16 Jan 2004 15:49:49 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i0GLnm0L28059293; Fri, 16 Jan 2004 15:49:48 -0600 (CST) Received: from clink (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i0GLnRbs11310497; Fri, 16 Jan 2004 15:49:37 -0600 (CST) Message-Id: <200401162149.i0GLnRbs11310497@clink.americas.sgi.com> To: jgl@johngroves.net cc: linux-xfs@oss.sgi.com Subject: Re: Not getting CREATE events from dmapi Date: Fri, 16 Jan 2004 15:49:27 -0600 From: Dean Roehrich X-archive-position: 1775 X-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@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2244 Lines: 64 >From: John Groves >I'm doing a dmapi handler, and I'm not receiving any DM_EVENT_CREATE or >DM_EVENT_POSTCREATE events. Other events are delivered as expected >(including the other async POST-whatever events and the managed region >events). Just wondering if there are any known issues around this. Maybe an example would be useful. Here's how you might use the dmapi test suite, under the userspace CVS tree xfs-cmds/xfstests/dmapi on oss.sgi.com, to test this: First, how to place the CREATE event on the fshandle. This is not persistent across mounts: # dm_create_session ret=0 newsid=2 # path_to_fshandle /mnts/dmi3 819bbace559f0be3 # set_disp -s 2 819bbace559f0be3 DM_EVENT_CREATE DM_EVENT_READ # set_eventlist -F -s 2 819bbace559f0be3 DM_EVENT_CREATE (someone else creates a file now...) # get_events 2 rlenp is 96 create: token=6 sequence=6 parent dir 819bbace559f0be3000e0000000000000000000000000040 name foo mode bits mode 100644: perm rw- r-- r--, type Regular File # respond_event 2 6 1 0 # umount /mnts/dmi3 # mount /mnts/dmi3 # get_eventlist -F -s 2 819bbace559f0be3 Events on object 819bbace559f0be3 (0x0), nelemp 23: Now, to place the CREATE event on the directory. This is persistent across mounts: # path_to_handle /mnts/dmi3 819bbace559f0be3000e0000000000000000000000000040 # set_disp -s 2 819bbace559f0be3000e0000000000000000000000000040 DM_EVENT_CREATE # set_eventlist -s 2 819bbace559f0be3000e0000000000000000000000000040 DM_EVENT_CREATE (someone else creates a file now...) # get_events 2 rlenp is 96 create: token=7 sequence=7 parent dir 819bbace559f0be3000e0000000000000000000000000040 name spam mode bits mode 100644: perm rw- r-- r--, type Regular File # respond_event 2 7 1 0 Anyway, if you could reproduce it with the dmapi test suite, that would be especially useful. You might have to get a current version of the test suite that lets you specify handles rather than pathnames to commands such as set_disp and set_eventlist. (Your handles will look different--my examples are MIPS-order.) Dean From owner-linux-xfs@oss.sgi.com Fri Jan 16 14:34:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 14:34:30 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GMY7mK010540 for ; Fri, 16 Jan 2004 14:34:07 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0GMY13l014474 for ; Fri, 16 Jan 2004 14:34:01 -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 i0GMXxAV29974595; Fri, 16 Jan 2004 16:33:59 -0600 (CST) Received: from zhadum.americas.sgi.com (zhadum.americas.sgi.com [128.162.233.43]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i0GMXioZ3845028; Fri, 16 Jan 2004 16:33:54 -0600 (CST) Received: from zhadum.americas.sgi.com by zhadum.americas.sgi.com (SGI-8.12.5/SGI-client-1.7) via ESMTP id i0GMXi79108296; Fri, 16 Jan 2004 16:33:44 -0600 (CST) Received: (from overby@localhost) by zhadum.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0GMXNbf113772; Fri, 16 Jan 2004 16:33:23 -0600 (CST) Date: Fri, 16 Jan 2004 16:33:23 -0600 (CST) Message-Id: <200401162233.i0GMXNbf113772@zhadum.americas.sgi.com> From: Glen Overby To: rs_404@yahoo.ca Cc: linux-xfs@oss.sgi.com Reply-To: linux-xfs@oss.sgi.com Subject: Re: XFS and small files In-Reply-To: message from Rajesh Saxena sent 16 January 2004 References: <20040116193929.14027.qmail@web41503.mail.yahoo.com> X-archive-position: 1776 X-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: 1056 Lines: 30 On January 16, Rajesh Saxena wrote: > Hi list...... I read all the time that XFS is built to support very > large files and large > directories efficiently but how well does it handle small files. I want > to use in a > mail server running cyrus imapd. People on the lvm list pointed out > that reiserfs > is more suited in that area but I would prefer to have consistent > filesystem on > all servers. Anyone using XFS on busy mail sites? Do you have any mail > usage > and server performance figures? XFS works just fine for mail servers. If you're concerned about wasted space due to the default 4KB filesystem block size, you can make the filesystem block size smaller (the mkfs -b size= option). With dir2, you can have a 1KB filesystem block size and still have a 4KB directory block size. That will keep directory metadata reads at 4KB so they won't be slowed down from what you see today. For example: mkfs_xfs -b size=1024 -n size=4096 /dev/hdz8 will give you a 1KB filesystem block size and a 4KB directory block size. Glen Overby From owner-linux-xfs@oss.sgi.com Fri Jan 16 14:45:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 14:45:32 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GMjKmK011157 for ; Fri, 16 Jan 2004 14:45:21 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i0GMhDge017732; Fri, 16 Jan 2004 13:43:13 -0900 Date: Fri, 16 Jan 2004 13:43:13 -0900 (AKST) From: Arthur Corliss X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: Feizhou cc: linux-xfs@oss.sgi.com Subject: Re: List configuration In-Reply-To: <4007500D.1060806@linuxmail.org> Message-ID: References: <4007500D.1060806@linuxmail.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1777 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@digitalmages.com Precedence: bulk X-list: linux-xfs Content-Length: 1424 Lines: 38 On Fri, 16 Jan 2004, Feizhou wrote: > Open list? I had to confirm my subscription. > > You even get spam on the qmail list which requires you send a > confirmation for EACH post. > > Rule No. 2. Spammers are STUPID > > Somebody *please* unscrew your list servers before I'm forced to unsubscribe > > and blacklist these boxes... > > Get real. Right. If it's not the list, then it's your smtp config. The fact remains that the mail *is* coming through oss.sgi.com, I verified the headers before sending out my bitch: Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i0G0EZNT008197; Thu, 15 Jan 2004 16:14:35 -0800 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Jan 2004 16:14:34 -0800 (PST) Received: from pool-138-89-3-110.mad.east.verizon.net (pool-138-89-3-110.mad.east.verizon.net [138.89.3.110]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G0E0NT008112 for ; Thu, 15 Jan 2004 16:14:16 -0800 Received: from (HELO 3ar9m6l) [3.55.138.235] by pool-138-89-3-110.mad.east.verizon.net; Fri, 16 Jan 2004 03:08:16 +0300 So quit making excuses for something that's obviously broken. --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ "Live Free or Die, the Only Way to Live" -- NH State Motto From owner-linux-xfs@oss.sgi.com Fri Jan 16 14:51:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 14:51:17 -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 i0GMp5mK011640 for ; Fri, 16 Jan 2004 14:51:06 -0800 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id i0GMsgj2006520; Fri, 16 Jan 2004 17:54:42 -0500 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id i0GMsgph006517; Fri, 16 Jan 2004 17:54:42 -0500 Date: Fri, 16 Jan 2004 17:54:42 -0500 (EST) From: Net Llama! To: Arthur Corliss cc: linux-xfs@oss.sgi.com Subject: Re: List configuration In-Reply-To: Message-ID: References: <4007500D.1060806@linuxmail.org> 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: 1778 X-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: 481 Lines: 12 On Fri, 16 Jan 2004, Arthur Corliss wrote: > So quit making excuses for something that's obviously broken. ANd your excuse for spamming the list with something that no list member can fix is what exactly? It apparently hasn't occurred to you that you should contact the list administrative address. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Fri Jan 16 15:00:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 15:00:59 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GN0lmK012327 for ; Fri, 16 Jan 2004 15:00:47 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i0GMwtge019201; Fri, 16 Jan 2004 13:58:55 -0900 Date: Fri, 16 Jan 2004 13:58:55 -0900 (AKST) From: Arthur Corliss X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: Net Llama! cc: linux-xfs@oss.sgi.com Subject: Re: List configuration In-Reply-To: Message-ID: References: <4007500D.1060806@linuxmail.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1779 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@digitalmages.com Precedence: bulk X-list: linux-xfs Content-Length: 958 Lines: 23 On Fri, 16 Jan 2004, Net Llama! wrote: > ANd your excuse for spamming the list with something that no list member > can fix is what exactly? It apparently hasn't occurred to you that you > should contact the list administrative address. I've got a damned good reason for sending this to the list: 1) Any managed list should have the applicable administrator subscribed, or someone who reports to him/her, and 2) Publicising the problem may cause others to confirm that they're seeing the exact same behaviour I am. As a result, the admin might be able to prioritise this based on the severity of the affected. Deal with it. Let's get the damned list fixed or boot me off. Either solution would provide positive results for me at this point. --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ "Live Free or Die, the Only Way to Live" -- NH State Motto From owner-linux-xfs@oss.sgi.com Fri Jan 16 15:04:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 15:04:38 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GN4QmK012770 for ; Fri, 16 Jan 2004 15:04:26 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i0GN2mge020437 for ; Fri, 16 Jan 2004 14:02:48 -0900 Date: Fri, 16 Jan 2004 14:02:48 -0900 (AKST) From: corliss@alaskapm.org X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: linux-xfs@oss.sgi.com Subject: Testing the list config Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1780 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@alaskapm.org Precedence: bulk X-list: linux-xfs Content-Length: 71 Lines: 6 Greetings: This is a test e-mail from an unsubscribed address. Boo! From owner-linux-xfs@oss.sgi.com Fri Jan 16 15:07:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 15:07:26 -0800 (PST) Received: from mail.myphorum.de (mysnip.de.gw.net-build.de [194.25.82.254] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GN7CmK013211 for ; Fri, 16 Jan 2004 15:07:14 -0800 Received: from localhost (myphorum [127.0.0.1]) by mail.myphorum.de (Postfix) with ESMTP id 0E9BD274463 for ; Sat, 17 Jan 2004 00:07:11 +0100 (CET) Received: from mail.myphorum.de ([127.0.0.1]) by localhost (myphorum.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11399-08 for ; Sat, 17 Jan 2004 00:07:10 +0100 (CET) Received: from myphorum.com (pD9E8323C.dip.t-dialin.net [217.232.50.60]) by mail.myphorum.de (Postfix) with ESMTP id 7199627445D for ; Sat, 17 Jan 2004 00:07:10 +0100 (CET) Message-ID: <40086E9F.90602@myphorum.com> Date: Sat, 17 Jan 2004 00:07:11 +0100 From: "Thomas (maillists)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 MultiZilla/1.6.0.0b X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: linux-xfs@oss.sgi.com Subject: Re: List configuration References: <4007500D.1060806@linuxmail.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mysnip.de X-archive-position: 1781 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: thomas-lists@myphorum.com Precedence: bulk X-list: linux-xfs Content-Length: 751 Lines: 31 Arthur Corliss wrote: > I've got a damned good reason for sending this to the list: > > 1) Any managed list should have the applicable administrator > subscribed, or someone who reports to him/her, and > > Why? You could simply contact him directly. > 2) Publicising the problem may cause others to confirm that > they're seeing the exact same behaviour I am. As a result, > the admin might be able to prioritise this based on the > severity of the affected. > > What is severe here? I got my local spamassassin catching the spam just fine. >Deal with it. Let's get the damned list fixed or boot me off. Either >solution would provide positive results for me at this point. > > You are free to unsubscribe. thomas From owner-linux-xfs@oss.sgi.com Fri Jan 16 15:18:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 15:18:34 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GNIMmK013774 for ; Fri, 16 Jan 2004 15:18:22 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i0GNGege021576; Fri, 16 Jan 2004 14:16:40 -0900 Date: Fri, 16 Jan 2004 14:16:40 -0900 (AKST) From: Arthur Corliss X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: "Thomas (maillists)" cc: linux-xfs@oss.sgi.com Subject: Re: List configuration In-Reply-To: <40086E9F.90602@myphorum.com> Message-ID: References: <4007500D.1060806@linuxmail.org> <40086E9F.90602@myphorum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1782 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@digitalmages.com Precedence: bulk X-list: linux-xfs Content-Length: 1042 Lines: 27 On Sat, 17 Jan 2004, Thomas (maillists) wrote: > Why? You could simply contact him directly. Again: one stone, two birds (points 1 & 2). > What is severe here? I got my local spamassassin catching the spam just > fine. And I've got SGI white-listed because, for some reason, my patch updates for IRIX were getting caught by some of SpamAssassin's checks. The irony is that's not really the point. Listen to me carefully, children: treat the cause, not the symptom. This would all be moot if SGI wasn't running an open list. It's that simple. > You are free to unsubscribe. Yes, I am. But until someone from SGI tells me that they refuse to fix the list config, I'm going to stay and hope it gets fixed. I want to get the legitimate e-mails, I just don't want the spam. And I really don't think I'm being unreasonable for expecting that much. --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ "Live Free or Die, the Only Way to Live" -- NH State Motto From owner-linux-xfs@oss.sgi.com Fri Jan 16 15:23:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 15:23:45 -0800 (PST) Received: from mail.myphorum.de (mysnip.de.gw.net-build.de [194.25.82.254] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GNNWmK014311 for ; Fri, 16 Jan 2004 15:23:33 -0800 Received: from localhost (myphorum [127.0.0.1]) by mail.myphorum.de (Postfix) with ESMTP id E7CA3274463 for ; Sat, 17 Jan 2004 00:23:31 +0100 (CET) Received: from mail.myphorum.de ([127.0.0.1]) by localhost (myphorum.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13194-04 for ; Sat, 17 Jan 2004 00:23:31 +0100 (CET) Received: from myphorum.com (pD9E8323C.dip.t-dialin.net [217.232.50.60]) by mail.myphorum.de (Postfix) with ESMTP id 68038274462 for ; Sat, 17 Jan 2004 00:23:31 +0100 (CET) Message-ID: <40087274.7000903@myphorum.com> Date: Sat, 17 Jan 2004 00:23:32 +0100 From: "Thomas (maillists)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 MultiZilla/1.6.0.0b X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: List configuration References: <4007500D.1060806@linuxmail.org> <40086E9F.90602@myphorum.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mysnip.de X-archive-position: 1783 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: thomas-lists@myphorum.com Precedence: bulk X-list: linux-xfs Content-Length: 577 Lines: 22 Arthur Corliss wrote: > >And I've got SGI white-listed because, for some reason, my patch updates for >IRIX were getting caught by some of SpamAssassin's checks. The irony is >that's not really the point. Listen to me carefully, children: > Don't call others children once you know they are ... > treat the >cause, not the symptom. This would all be moot if SGI wasn't running an open >list. It's that simple. > > Yeah, but the CAUSE is the SPAM, not the list. So if you want to treat the cause then you have to go against the spam-senders, not the list. thomas From owner-linux-xfs@oss.sgi.com Fri Jan 16 15:48:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 15:48:26 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GNmBmK015843 for ; Fri, 16 Jan 2004 15:48:14 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i0GNkQge024312; Fri, 16 Jan 2004 14:46:26 -0900 Date: Fri, 16 Jan 2004 14:46:26 -0900 (AKST) From: Arthur Corliss X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: "Thomas (maillists)" cc: linux-xfs@oss.sgi.com Subject: Re: List configuration In-Reply-To: <40087274.7000903@myphorum.com> Message-ID: References: <4007500D.1060806@linuxmail.org> <40086E9F.90602@myphorum.com> <40087274.7000903@myphorum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1784 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@digitalmages.com Precedence: bulk X-list: linux-xfs Content-Length: 1253 Lines: 30 On Sat, 17 Jan 2004, Thomas (maillists) wrote: > Don't call others children once you know they are ... LOL. Okay, I really have no idea how to interpret this, so I'll concede you the point (whatever it is ;-) > Yeah, but the CAUSE is the SPAM, not the list. So if you want to treat > the cause then you have to go against the > spam-senders, not the list. Based on the current protocols, that's pretty damned hard to do, given all the work-arounds. I'm working off of what I had thought the unwritten rule was for all of us admins of public servers: don't exacerbate the problem by (re)transmitting spam ourselves. If I ever catch one of my many users sending spam, I'll terminate the account immediately. In addition to that, I don't run an open relay, nor do I run open lists. Thank god for RBLs, otherwise I'd be paying for a hell of alot more bandwidth (out of the ~200,000 attempts to connect to my server per month 47% are rejected based on RBLs). Now, what happens SGI ends up on an RBL because they refused to closed a hole that spammers are using? --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ "Live Free or Die, the Only Way to Live" -- NH State Motto From owner-linux-xfs@oss.sgi.com Fri Jan 16 16:03:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 16:04:08 -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 i0H03fmK020860 for ; Fri, 16 Jan 2004 16:03:44 -0800 Received: from adsl-67-121-168-101.dsl.sntc01.pacbell.net ([67.121.168.101]:63723 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 1AhdvW-0005nb-D8 by VAauthid with fixed_plain; Fri, 16 Jan 2004 16:02:58 -0800 Message-ID: <40087B7F.1050007@linux-sxs.org> Date: Fri, 16 Jan 2004 16:02:07 -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: Arthur Corliss CC: linux-xfs@oss.sgi.com Subject: Re: List configuration References: <4007500D.1060806@linuxmail.org> <40086E9F.90602@myphorum.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 1AhdvW-0005nb-D8 1163343fe2f9bb05d98af9c9f7f8955f X-Spam-Score: -98.1 (---------------------------------------------------) X-archive-position: 1785 X-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: 662 Lines: 17 On 01/16/04 15:16, Arthur Corliss wrote: > that's not really the point. Listen to me carefully, children: treat the The only child here is you. Throwing a tantrum because you dislike how a list is setup proves you to be the infantile fool. You've wasted significantly more bandwidth in your whining than the spam that you claim to be ruining your life. Get lost troll. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 15:55:01 up 40 days, 20:40, 1 user, load average: 0.05, 0.09, 0.08 From owner-linux-xfs@oss.sgi.com Fri Jan 16 16:07:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 16:07:20 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H078mK021326 for ; Fri, 16 Jan 2004 16:07:08 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i0H05Uge026369; Fri, 16 Jan 2004 15:05:30 -0900 Date: Fri, 16 Jan 2004 15:05:30 -0900 (AKST) From: Arthur Corliss X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: Russell Cattelan cc: linux-xfs@oss.sgi.com Subject: Re: List configuration In-Reply-To: <1074297473.13263.8.camel@naboo.americas.sgi.com> Message-ID: References: <4007500D.1060806@linuxmail.org> <40086E9F.90602@myphorum.com> <40087274.7000903@myphorum.com> <1074297473.13263.8.camel@naboo.americas.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1786 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@digitalmages.com Precedence: bulk X-list: linux-xfs Content-Length: 1589 Lines: 39 On Fri, 16 Jan 2004, Russell Cattelan wrote: > Arthur: > This is a pointless discussion. > > The list does not restrict posting to subscribed uses > on purpose, since we want people with problems to contact > us with having to subscribe to list they may not want to be on. > > No spam filter is 100% and yes a few more got through the other night > due to the fact that spamd died. > > If you send one more message to the list on this, I will > remove you from the list and block your mailer from sending anymore > mail to oss.sgi.com. > > Sorry to sound harsh but I spend way to much of my free time trying > to keep oss.sgi.com as spam free as possible. No need, I've already sent the command to unsubscribe. The irony is that for all of your attempts to keep the list spam-free, one simple change could make it that much more effective. And there's plenty of ways to provide off-list e-mailers from providing feedback. Like the on-line bug management system. Like an off-list bug address. Or even a web-based form. All of which could be moderated before sending out up-teen copies of spam that slips past your filters. From the moment I broached the subject your first reply was a very sarcastic jackass-like response. Rather than explaining what happened (spamd died) or your rationale for an open list, you started a flame war. Right from the annals of bofh. I'm gone, and glad to be so. --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ "Live Free or Die, the Only Way to Live" -- NH State Motto From owner-linux-xfs@oss.sgi.com Fri Jan 16 16:08:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 16:09:18 -0800 (PST) Received: from nevaeh-linux.org (18-165-237-24-mvl.nwc.gci.net [24.237.165.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H08wmK022340 for ; Fri, 16 Jan 2004 16:08:59 -0800 Received: from localhost (localhost [127.0.0.1]) by nevaeh-linux.org (8.12.10/8.12.10) with ESMTP id i0H075ge026403; Fri, 16 Jan 2004 15:07:05 -0900 Date: Fri, 16 Jan 2004 15:07:05 -0900 (AKST) From: Arthur Corliss X-X-Sender: acorliss@bifrost.nevaeh-linux.org To: Net Llama! cc: Arthur Corliss , linux-xfs@oss.sgi.com Subject: Re: List configuration In-Reply-To: <40087B7F.1050007@linux-sxs.org> Message-ID: References: <4007500D.1060806@linuxmail.org> <40086E9F.90602@myphorum.com> <40087B7F.1050007@linux-sxs.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1787 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: corliss@digitalmages.com Precedence: bulk X-list: linux-xfs Content-Length: 800 Lines: 20 On Fri, 16 Jan 2004, Net Llama! wrote: > On 01/16/04 15:16, Arthur Corliss wrote: > > that's not really the point. Listen to me carefully, children: treat the > > The only child here is you. Throwing a tantrum because you dislike how > a list is setup proves you to be the infantile fool. You've wasted > significantly more bandwidth in your whining than the spam that you > claim to be ruining your life. Get lost troll. > Right. You certainly won't be missed, twit. I've at least outline quite clearly my rationale for my actions. You still seem to be without reason altogether. Good riddance. --Arthur Corliss Bolverk's Lair -- http://arthur.corlissfamily.org/ Digital Mages -- http://www.digitalmages.com/ "Live Free or Die, the Only Way to Live" -- NH State Motto From owner-linux-xfs@oss.sgi.com Fri Jan 16 16:26:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 16:26:42 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H0QUmK023124 for ; Fri, 16 Jan 2004 16:26:30 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0H0QO3l004040 for ; Fri, 16 Jan 2004 16:26:25 -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 i0H0QNAV29933785; Fri, 16 Jan 2004 18:26:24 -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 i0H0QNoZ3612820; Fri, 16 Jan 2004 18:26:23 -0600 (CST) Subject: Re: List configuration From: Russell Cattelan To: Arthur Corliss Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <4007500D.1060806@linuxmail.org> <40086E9F.90602@myphorum.com> <40087274.7000903@myphorum.com> <1074297473.13263.8.camel@naboo.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HQBJfekyJ60cG2kBHCAx" Message-Id: <1074299183.13264.15.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-2mdk Date: Fri, 16 Jan 2004 18:26:23 -0600 X-archive-position: 1788 X-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: 661 Lines: 29 --=-HQBJfekyJ60cG2kBHCAx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Arthur: Apparently you're listener is broken. I asked to drop the discussion, so I am now following through on my promise to block you from posting to the list. -Russell Cattelan Digital Elves Inc --=-HQBJfekyJ60cG2kBHCAx 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) iD8DBQBACIEvNRmM+OaGhBgRAmfXAJ9my1jkediGo4Nx7v7IVLT7HzMZKACghBn+ l1HRUnXNmSBdQc2D7A1+CKo= =jpVi -----END PGP SIGNATURE----- --=-HQBJfekyJ60cG2kBHCAx-- From owner-linux-xfs@oss.sgi.com Fri Jan 16 19:04:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 19:04:55 -0800 (PST) Received: from shksmtp02.so-net.com.hk (smtp.so-net.com.hk [203.99.142.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H34UmK031764 for ; Fri, 16 Jan 2004 19:04:31 -0800 Received: (qmail 4672 invoked from network); 17 Jan 2004 03:04:23 -0000 Received: from so224187.bbo224.so-net.com.hk (HELO linuxmail.org) ([203.176.224.187]) (envelope-sender ) by shksmtp02.so-net.com.hk (qmail-ldap-1.03) with SMTP for ; 17 Jan 2004 03:04:23 -0000 Message-ID: <4008A636.600@linuxmail.org> Date: Sat, 17 Jan 2004 11:04:22 +0800 From: Feizhou 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: Arthur Corliss CC: linux-xfs@oss.sgi.com Subject: Re: List configuration References: <4007500D.1060806@linuxmail.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1789 X-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: 740 Lines: 28 Arthur Corliss wrote: > On Fri, 16 Jan 2004, Feizhou wrote: > > >>Open list? I had to confirm my subscription. >> >>You even get spam on the qmail list which requires you send a >>confirmation for EACH post. >> >>Rule No. 2. Spammers are STUPID >> >>>Somebody *please* unscrew your list servers before I'm forced to unsubscribe >>>and blacklist these boxes... >> >>Get real. > > > Right. If it's not the list, then it's your smtp config. The fact remains > that the mail *is* coming through oss.sgi.com, I verified the headers before > sending out my bitch: > Whoa! Sorry for jumping on you but I didn't say anything about your smtp config. I didn't know that the list was open in the sense that anybody could send email to it. From owner-linux-xfs@oss.sgi.com Fri Jan 16 19:07:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Jan 2004 19:07:55 -0800 (PST) Received: from shksmtp02.so-net.com.hk (pop.so-net.com.hk [203.99.142.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H37gmK032206 for ; Fri, 16 Jan 2004 19:07:43 -0800 Received: (qmail 6544 invoked from network); 17 Jan 2004 03:07:36 -0000 Received: from so224187.bbo224.so-net.com.hk (HELO so-net.com.hk) ([203.176.224.187]) (envelope-sender ) by shksmtp02.so-net.com.hk (qmail-ldap-1.03) with SMTP for ; 17 Jan 2004 03:07:36 -0000 Message-ID: <4008A6F7.7010905@so-net.com.hk> Date: Sat, 17 Jan 2004 11:07:35 +0800 From: Christopher Chan 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: linux-xfs@oss.sgi.com Subject: Re: Testing the list config References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1790 X-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@so-net.com.hk Precedence: bulk X-list: linux-xfs Content-Length: 200 Lines: 13 corliss@alaskapm.org wrote: > Greetings: > > This is a test e-mail from an unsubscribed address. > > Boo! > > AH!!! Not funny. Is it really necessary to allow anybody to send mail to the list? From owner-linux-xfs@oss.sgi.com Sat Jan 17 06:16:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 17 Jan 2004 06:16:44 -0800 (PST) Received: from ura.dnsalias.org (rdu74-148-233.nc.rr.com [24.74.148.233]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0HEGNmK026176 for ; Sat, 17 Jan 2004 06:16:32 -0800 Received: from ken-ohki (unknown [10.42.123.118]) by ura.dnsalias.org (Postfix) with ESMTP id BEAB48768; Sat, 17 Jan 2004 09:16:14 -0500 (EST) Date: Sat, 17 Jan 2004 09:16:14 -0500 From: Jarrod Johnson To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Strange df output Message-Id: <20040117091614.7d172889.jbj-ksylph@ken-ohki> In-Reply-To: <1073595887.27384.260.camel@stout.americas.sgi.com> References: <20040108154940.7dd28591.jbj-ksylph@ken-ohki> <1073595887.27384.260.camel@stout.americas.sgi.com> X-Mailer: Sylpheed version 0.9.4 (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: 1791 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jbj-ksylph@ura.dnsalias.org Precedence: bulk X-list: linux-xfs Content-Length: 2775 Lines: 53 Unfortunately, this was first created ~1.5 years ago, so I have no mkfs arguments, I assume the default from whatever it was back then. I've gone since to kernel 2.4.23 with the snapshot for download applied, and it was about then I started noticing this behavior. The system crashed at one point listing about ~4G free, but on reboot the system had 0 free. I tried to run xfs_check on it, but xfs_check is killed partway through, kernel prints: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) VM: killing process xfs_db Is there some serious issues going on here? Amidst 344G of data, it's hard to find if only a portion of data is corrupt. By the same token, I don't have any storage on which to back up 344GB of filesystem for a new mkfs. Anyone have any suggested path to ensure things are ok, or fix things if they aren't? The only other interesting aspect that may be of interest is that the filesystem is on a software RAID-5 volume. On 08 Jan 2004 15:04:47 -0600 Eric Sandeen wrote: > Any chance you can give us a reproducible way (from mkfs) to demonstrate > the problem? > > You could be seeing some effects of preallocated space being freed (esp. > as the fs fills up), other than that I'm not certain yet. > > -Eric > > > On Thu, 2004-01-08 at 14:49, Jarrod Johnson wrote: > > I'm running xfs on a software raid5 array, the kernel version is: > > SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with ACLs, no debug enabled > > > > And here is a taste of what I'm seeing: > > df -k .: > > Filesystem 1K-blocks Used Available Use% Mounted on > > /dev/md0 360138240 356276448 3861792 99% /storage > > dd if=/dev/zero of=tst bs=1000000 count=300 > > df -k .: > > Filesystem 1K-blocks Used Available Use% Mounted on > > /dev/md0 360138240 356327136 3811104 99% /storage > > rm -f tst: > > Filesystem 1K-blocks Used Available Use% Mounted on > > /dev/md0 360138240 355983080 4155160 99% /storage > > > > So I had some space free, making a 300,000,000 byte file only consumed about 5,000k, and then deleting it freed up more space than I had to start with? > > > > This is consistantly occuring. A week or so back, it inexplicably went from ~2GB free to full instantaneously. I didn't believe the person was keeping good track of it and just filled it up, so I did this a few times and if this is happening, I now believe that what the person said is true. > > > > Why is the free space not decreasing on creation of new files, yet increasing on deletion? > > > > Please CC me as I'm not subscribed. > -- > 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 Sat Jan 17 07:05:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 17 Jan 2004 07:05:30 -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 i0HF5ImK027555 for ; Sat, 17 Jan 2004 07:05:18 -0800 Received: from adsl-67-121-168-101.dsl.sntc01.pacbell.net ([67.121.168.101]:62558 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 1Ahs0I-0005Q3-3a by VAauthid with fixed_plain; Sat, 17 Jan 2004 07:04:50 -0800 Message-ID: <40094F09.3000702@linux-sxs.org> Date: Sat, 17 Jan 2004 07:04:41 -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: Jarrod Johnson CC: linux-xfs@oss.sgi.com Subject: Re: Strange df output References: <20040108154940.7dd28591.jbj-ksylph@ken-ohki> <1073595887.27384.260.camel@stout.americas.sgi.com> <20040117091614.7d172889.jbj-ksylph@ken-ohki> In-Reply-To: <20040117091614.7d172889.jbj-ksylph@ken-ohki> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 1Ahs0I-0005Q3-3a 325a12d4b309aaf94f93f7f8119b193f X-Spam-Score: -98.1 (---------------------------------------------------) X-archive-position: 1792 X-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: 1029 Lines: 19 On 01/17/04 06:16, Jarrod Johnson wrote: > Unfortunately, this was first created ~1.5 years ago, so I have no mkfs arguments, I assume the default from whatever it was back then. I've gone since to kernel 2.4.23 with the snapshot for download applied, and it was about then I started noticing this behavior. The system crashed at one point listing about ~4G free, but on reboot the system had 0 free. > > I tried to run xfs_check on it, but xfs_check is killed partway through, kernel prints: > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) > VM: killing process xfs_db I might be wrong, but isn't that what the kernel spits out when the box is running out of memory (and swap)? THat looks exactly like the non-OOM killer message to me. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 07:00:01 up 41 days, 11:45, 1 user, load average: 0.13, 0.08, 0.02 From owner-linux-xfs@oss.sgi.com Sat Jan 17 07:20:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 17 Jan 2004 07:21:06 -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 i0HFKgmK028235 for ; Sat, 17 Jan 2004 07:20:42 -0800 Received: (qmail 32149 invoked from network); 17 Jan 2004 15:20:40 -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 ; 17 Jan 2004 15:20:40 -0000 Message-ID: <4009520A.8030505@xfs.org> Date: Sat, 17 Jan 2004 09:17:30 -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: Jarrod Johnson CC: linux-xfs@oss.sgi.com Subject: Re: Strange df output References: <20040108154940.7dd28591.jbj-ksylph@ken-ohki> <1073595887.27384.260.camel@stout.americas.sgi.com> <20040117091614.7d172889.jbj-ksylph@ken-ohki> <40094F09.3000702@linux-sxs.org> In-Reply-To: <40094F09.3000702@linux-sxs.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1793 X-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: 1503 Lines: 40 Net Llama! wrote: > On 01/17/04 06:16, Jarrod Johnson wrote: > >> Unfortunately, this was first created ~1.5 years ago, so I have no >> mkfs arguments, I assume the default from whatever it was back then. >> I've gone since to kernel 2.4.23 with the snapshot for download >> applied, and it was about then I started noticing this behavior. The >> system crashed at one point listing about ~4G free, but on reboot the >> system had 0 free. >> >> I tried to run xfs_check on it, but xfs_check is killed partway >> through, kernel prints: >> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) >> VM: killing process xfs_db > > > I might be wrong, but isn't that what the kernel spits out when the box > is running out of memory (and swap)? THat looks exactly like the > non-OOM killer message to me. > It is, xfs_check is going to be a memory hog, if your user space tools are as old as the filesystem is, try getting new ones, there were some changes which would reduce the amount of memory consumed by a factor of 2 at least. The other options are to run from single user so there is more memory available, and make sure you have swap configured. xfs_check is just going to report error conditions, xfs_repair is the program to fix them. Same comments apply as above. You can always get the mkfs parameters out of the filesystem by using xfs_info on the mounted fs. If it will not mount then you can dump the super block which contains the info: xfs_db -r /dev/xxx sb 0 p Steve From owner-linux-xfs@oss.sgi.com Sat Jan 17 08:00:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 17 Jan 2004 08:01: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 i0HG0fmK029525 for ; Sat, 17 Jan 2004 08:00:41 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0HG0fPU029523 for linux-xfs@oss.sgi.com; Sat, 17 Jan 2004 08:00: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 i0HG0cmQ029495 for ; Sat, 17 Jan 2004 08:00:39 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0HFjYiq029193; Sat, 17 Jan 2004 07:45:34 -0800 Date: Sat, 17 Jan 2004 07:45:34 -0800 Message-Id: <200401171545.i0HFjYiq029193@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 304] New: memory requirements for xfs_check should be documented in the man page X-Bugzilla-Reason: AssignedTo X-archive-position: 1794 X-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: 791 Lines: 26 http://oss.sgi.com/bugzilla/show_bug.cgi?id=304 Summary: memory requirements for xfs_check should be documented in the man page Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: enhancement Priority: Low Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: karlran@hotmail.com I had to increase the virtual memory with 'ulimit -v 200000' to 200MB to check a 149GB disk (after I moved the disk to a system with enough RAM) A rough guestimate would be good for the man page, IMO. ------- 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 Sat Jan 17 08:00:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 17 Jan 2004 08:01: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 i0HG0fmK029524 for ; Sat, 17 Jan 2004 08:00:41 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0HG0fDK029522 for linux-xfs@oss.sgi.com; Sat, 17 Jan 2004 08:00: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 i0HG0cmM029495 for ; Sat, 17 Jan 2004 08:00:39 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0HFCccK028084; Sat, 17 Jan 2004 07:12:38 -0800 Date: Sat, 17 Jan 2004 07:12:38 -0800 Message-Id: <200401171512.i0HFCccK028084@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: 1794 X-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: 333 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 ------- Additional Comments From karlran@hotmail.com 2004-17-01 07:12 PDT ------- > Your workaround did the trick. Thanks! Yep. Here too. Thanks Nathan! ------- 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 Sat Jan 17 10:43:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 17 Jan 2004 10:43:39 -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 i0HIhFmK006558 for ; Sat, 17 Jan 2004 10:43:15 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 78842141B138; Sat, 17 Jan 2004 13:43:19 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 1695B141B136; Sat, 17 Jan 2004 13:43:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 09930300019E; Sat, 17 Jan 2004 13:43:18 -0500 (EST) Date: Sat, 17 Jan 2004 13:43:17 -0500 (EST) From: Mike Burger To: Christopher Chan Cc: linux-xfs@oss.sgi.com Subject: Re: Testing the list config In-Reply-To: <4008A6F7.7010905@so-net.com.hk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1795 X-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: 707 Lines: 34 On Sat, 17 Jan 2004, Christopher Chan wrote: > corliss@alaskapm.org wrote: > > Greetings: > > > > This is a test e-mail from an unsubscribed address. > > > > Boo! > > > > > > AH!!! > > Not funny. Is it really necessary to allow anybody to send mail to the list? Apparently, due to the sheer number of people on the linux kernel maintainers list, yeah/ -- 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 Sat Jan 17 13:16:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 17 Jan 2004 13:17:12 -0800 (PST) Received: from linux-xfs ([213.13.249.119]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0HLGkmK012833 for ; Sat, 17 Jan 2004 13:16:47 -0800 Message-ID: From: "Apache" Date: Sat, 17 Jan 2004 21:16:20 +0000 To: linux-xfs@oss.sgi.com Subject: Info regarding vigra Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=windows-1251 X-archive-position: 1796 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: infowinding@golfgod.net Precedence: bulk X-list: linux-xfs Content-Length: 535 Lines: 16 how Vigra™ works. So you can better understand, what Vigra can do for you. If you are sensible about your health, reflect on what you can do for your seual health, to keep the chances that you will need Vigra as low as possible. widespread backplanes terms, Mukden. Inrease Seks Drive Bost Seual Performance Fuller & Harder Erecions Inrease Stamna & Endurance Quicker Rechages http://www.raiseyourpower.com/index.php?pid=pharmaboss payroll stewed Whittier, brainstorm. additional winces bronze, uplands. Thanks, Charley From owner-linux-xfs@oss.sgi.com Sun Jan 18 09:05:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 18 Jan 2004 09:05:29 -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 i0IH54mK031376 for ; Sun, 18 Jan 2004 09:05:05 -0800 Received: from linux-xfs (cs2427113-103.houston.rr.com [24.27.113.103]) by lips.borg.umn.edu (8.12.10/8.12.10) with SMTP id i0IH52p3035135 for ; Sun, 18 Jan 2004 11:05:02 -0600 (CST) (envelope-from infopotion@golfgod.net) Message-ID: From: "Tinsley" Date: Sun, 18 Jan 2004 11:06:43 +0000 To: linux-xfs@thebarn.com Subject: Info regarding vigra Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=windows-1251 X-archive-position: 1797 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: infopotion@golfgod.net Precedence: bulk X-list: linux-xfs Content-Length: 519 Lines: 16 how Vigra™ works. So you can better understand, what Vigra can do for you. If you are sensible about your health, reflect on what you can do for your seual health, to keep the chances that you will need Vigra as low as possible. reveals Norristown washings, sense. Inrease Seks Drive Bost Seual Performance Fuller & Harder Erecions Inrease Stamna & Endurance Quicker Rechages http://www.sellherbs.com/index.php?pid=pharmaboss vapors average misfit, guideline. nines mantel breakup, deign. Thanks, salter From owner-linux-xfs@oss.sgi.com Sun Jan 18 20:53:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 18 Jan 2004 20:53:47 -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 i0J4rFmK014645 for ; Sun, 18 Jan 2004 20:53:15 -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 i0J3svI5011782 for ; Sun, 18 Jan 2004 19:54:57 -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 i0J4r7hI463838 for ; Mon, 19 Jan 2004 15:53:07 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0J4r6Rx460419 for linux-xfs@oss.sgi.com; Mon, 19 Jan 2004 15:53:06 +1100 (EST) Date: Mon, 19 Jan 2004 15:53:06 +1100 (EST) From: Nathan Scott Message-Id: <200401190453.i0J4r6Rx460419@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfstests X-archive-position: 1798 X-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: 584 Lines: 24 Update several QA tests, configure magic in xfstests directory. Date: Sun Jan 18 20:51:52 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:165056a xfstests/040 - 1.11 - Fix up location and env vars for srcdiff. xfstests/tools/srcdiff - 1.28 - Update source files checked. xfstests/m4/package_types.m4 - 1.2 xfstests/m4/package_xfslibs.m4 - 1.3 xfstests/aclocal.m4 - 1.3 - Fix configure magic in xfstests directory. From owner-linux-xfs@oss.sgi.com Sun Jan 18 21:01:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 18 Jan 2004 21:01:50 -0800 (PST) Received: from web8206.mail.in.yahoo.com (web8206.mail.in.yahoo.com [203.199.70.75]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0J51amK016173 for ; Sun, 18 Jan 2004 21:01:37 -0800 Message-ID: <20040119050129.79985.qmail@web8206.mail.in.yahoo.com> Received: from [203.197.90.40] by web8206.mail.in.yahoo.com via HTTP; Mon, 19 Jan 2004 05:01:29 GMT Date: Mon, 19 Jan 2004 05:01:29 +0000 (GMT) From: =?iso-8859-1?q?sapna=20todwal?= Subject: XFS-VFS 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: 1799 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sapnatodwal@yahoo.co.in Precedence: bulk X-list: linux-xfs Content-Length: 314 Lines: 10 hi, can anybody tell me does vfs supports xfs. i mean while setting extended attributes what are the corresponding vfs calls that are called? ________________________________________________________________________ Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com From owner-linux-xfs@oss.sgi.com Mon Jan 19 00:43:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 00:43:30 -0800 (PST) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0J8h3mK021918 for ; Mon, 19 Jan 2004 00:43:04 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id 0E4A737ACD for ; Mon, 19 Jan 2004 08:43:01 +0000 (GMT) Received: from smtp1.hk1.outblaze.com (smtp1.hk1.outblaze.com [203.86.166.80]) by corpmail.outblaze.com (Postfix) with SMTP id 9310F16DD85 for ; Mon, 19 Jan 2004 08:43:00 +0000 (GMT) Received: (qmail 1359 invoked from network); 19 Jan 2004 08:42:59 -0000 Received: from unknown (HELO ericy) (ericy@team.outblaze.com@210.177.227.130) by smtp1.hk1.outblaze.com with SMTP; 19 Jan 2004 08:42:59 -0000 Message-ID: <00d801c3de69$be87a980$4702a8c0@outblaze.com> From: "Eric Yu" To: Cc: Subject: xfs_repair "fatal error -- couldn't map inode" Date: Mon, 19 Jan 2004 16:53:43 +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-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.23.0.2; VDF: 6.23.0.34; host: corpmail.outblaze.com) X-archive-position: 1800 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ericy@team.outblaze.com Precedence: bulk X-list: linux-xfs Content-Length: 4992 Lines: 121 Last week one of my fileserver has rebooted due to power failure, and found out there were corrupted files with the following error messages: Jan 13 08:01:17 fs5-11 kernel: Filesystem "sd(8,7)": corrupt dinode 101980910, extent total = 522866323, nblocks = 3608. Unmo unt and run xfs_repair. Jan 13 08:01:17 fs5-11 kernel: 0x0: 49 4e 81 80 01 02 00 01 00 00 03 e9 00 00 03 e9 Jan 13 08:01:17 fs5-11 kernel: Filesystem "sd(8,7)": XFS internal error xfs_iformat(1) at line 472 of file xfs_inode.c. Calle r 0xe099535b Jan 13 08:01:17 fs5-11 kernel: dca71c68 e099423f e09db2b4 00000001 dde26800 e09db292 000001d8 e099535b Jan 13 08:01:17 fs5-11 kernel: e099535b 1f2a3320 1f2a4e93 00000000 00000000 00000000 00000000 dde26800 Jan 13 08:01:17 fs5-11 kernel: c6e03298 e099535b c6e03298 c386ae00 c386ae00 c6e033c4 00000001 00000000 Jan 13 08:01:17 fs5-11 kernel: Call Trace: [] xfs_iformat [xfs] 0x20f (0xdca71c6c)) Jan 13 08:01:17 fs5-11 kernel: [] .LC14 [xfs] 0x3d3 (0xdca71c70)) Jan 13 08:01:17 fs5-11 kernel: [] .LC14 [xfs] 0x3b1 (0xdca71c7c)) Jan 13 08:01:17 fs5-11 kernel: [] xfs_iread [xfs] 0xdb (0xdca71c84)) Jan 13 08:01:17 fs5-11 kernel: [] xfs_iread [xfs] 0xdb (0xdca71c88)) Jan 13 08:01:17 fs5-11 kernel: [] xfs_iread [xfs] 0xdb (0xdca71cac)) Jan 13 08:01:17 fs5-11 kernel: [] xfs_iget_core [xfs] 0x1b6 (0xdca71ce8)) Jan 13 08:01:17 fs5-11 kernel: [] xfs_iget [xfs] 0x7d (0xdca71d38)) Jan 13 08:01:17 fs5-11 kernel: [] xfs_dir_lookup_int [xfs] 0x61 (0xdca71d7c)) Jan 13 08:01:17 fs5-11 kernel: [] xfs_lookup [xfs] 0x3e (0xdca71db8)) Jan 13 08:01:17 fs5-11 kernel: [] linvfs_lookup [xfs] 0x3f (0xdca71dec)) Jan 13 08:01:17 fs5-11 kernel: [] cached_lookup [kernel] 0x10 (0xdca71e10)) Jan 13 08:01:17 fs5-11 kernel: [] lookup_hash [kernel] 0x91 (0xdca71e24)) Jan 13 08:01:17 fs5-11 kernel: [] lookup_one_len [kernel] 0x59 (0xdca71e40)) Jan 13 08:01:17 fs5-11 kernel: [] nfsd_lookup [nfsd] 0x340 (0xdca71e64)) Jan 13 08:01:17 fs5-11 kernel: [] __wake_up [kernel] 0x4f (0xdca71ed0)) Jan 13 08:01:17 fs5-11 kernel: [] svc_sock_enqueue [sunrpc] 0x184 (0xdca71ef8)) Jan 13 08:01:17 fs5-11 kernel: [] svc_udp_recvfrom [sunrpc] 0x2d3 (0xdca71f10)) Jan 13 08:01:17 fs5-11 kernel: [] nfsd3_proc_lookup [nfsd] 0xd8 (0xdca71f38)) Jan 13 08:01:17 fs5-11 kernel: [] nfsd_procedures3 [nfsd] 0x6c (0xdca71f58)) Jan 13 08:01:17 fs5-11 kernel: [] nfsd_dispatch [nfsd] 0xb7 (0xdca71f64)) Jan 13 08:01:17 fs5-11 kernel: [] nfsd_version3 [nfsd] 0x0 (0xdca71f7c)) Jan 13 08:01:17 fs5-11 kernel: [] svc_process_Rsmp_01d929dc [sunrpc] 0x368 (0xdca71f80)) Jan 13 08:01:17 fs5-11 kernel: [] nfsd_procedures3 [nfsd] 0x6c (0xdca71f9c)) Jan 13 08:01:17 fs5-11 kernel: [] nfsd_version3 [nfsd] 0x0 (0xdca71fa0)) Jan 13 08:01:17 fs5-11 kernel: [] nfsd_program [nfsd] 0x0 (0xdca71fa4)) Jan 13 08:01:17 fs5-11 kernel: [] nfsd [nfsd] 0x1ca (0xdca71fc0)) Jan 13 08:01:17 fs5-11 kernel: [] nfsd [nfsd] 0x0 (0xdca71fe0)) Jan 13 08:01:17 fs5-11 kernel: [] kernel_thread_helper [kernel] 0x5 (0xdca71ff0)) Jan 13 08:01:17 fs5-11 kernel: Jan 13 08:01:17 fs5-11 kernel: nfsd: non-standard errno: -990 Tried to run xfs_repair but failed with fatal error: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 59683 tail block 59683 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 corrupt block 0 in directory inode 158139 will junk block no . entry for directory 158139 no .. entry for directory 158139 corrupt block 3 in directory inode 1231523 will junk block . . . Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... corrupt block 8 in directory inode 838926683: junking block rebuilding directory inode 838926683 corrupt block 5 in directory inode 170001259: junking block bad hash table for directory inode 170001259 (no data entry): rebuilding disconnected dir inode 2081119363, moving to lost+found disconnected dir inode 2116550700, moving to lost+found . . . Phase 7 - verify and correct link counts... resetting inode 158139 nlinks from 3 to 2 resetting inode 16967337 nlinks from 3 to 2 resetting inode 335545743 nlinks from 2806 to 2805 fatal error -- couldn't map inode 2133733748, err = 22 I found some other list posting with similar problem, did any fix being release regarding this issue? xfs_info as follow: From owner-linux-xfs@oss.sgi.com Mon Jan 19 00:59:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 01:00:10 -0800 (PST) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0J8xlmK024456 for ; Mon, 19 Jan 2004 00:59:50 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id 0DEE437AC6 for ; Mon, 19 Jan 2004 08:59:47 +0000 (GMT) Received: from smtp1.hk1.outblaze.com (smtp1.hk1.outblaze.com [203.86.166.80]) by corpmail.outblaze.com (Postfix) with SMTP id B40DE16DD85 for ; Mon, 19 Jan 2004 08:59:46 +0000 (GMT) Received: (qmail 1847 invoked from network); 19 Jan 2004 08:59:46 -0000 Received: from unknown (HELO ericy) (ericy@team.outblaze.com@210.177.227.130) by smtp1.hk1.outblaze.com with SMTP; 19 Jan 2004 08:59:46 -0000 Message-ID: <00ee01c3de6c$16289b20$4702a8c0@outblaze.com> From: "Eric Yu" To: Cc: References: <00d801c3de69$be87a980$4702a8c0@outblaze.com> Subject: xfs_repair "fatal error -- couldn't map inode" Date: Mon, 19 Jan 2004 17:10:28 +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-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.23.0.2; VDF: 6.23.0.34; host: corpmail.outblaze.com) X-archive-position: 1801 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ericy@team.outblaze.com Precedence: bulk X-list: linux-xfs Content-Length: 6036 Lines: 149 > Last week one of my fileserver has rebooted due to power failure, and found > out there were corrupted files with the following error messages: > > Jan 13 08:01:17 fs5-11 kernel: Filesystem "sd(8,7)": corrupt dinode > 101980910, extent total = 522866323, nblocks = 3608. Unmo > unt and run xfs_repair. > Jan 13 08:01:17 fs5-11 kernel: 0x0: 49 4e 81 80 01 02 00 01 00 00 03 e9 00 > 00 03 e9 > Jan 13 08:01:17 fs5-11 kernel: Filesystem "sd(8,7)": XFS internal error > xfs_iformat(1) at line 472 of file xfs_inode.c. Calle > r 0xe099535b > Jan 13 08:01:17 fs5-11 kernel: dca71c68 e099423f e09db2b4 00000001 dde26800 > e09db292 000001d8 e099535b > Jan 13 08:01:17 fs5-11 kernel: e099535b 1f2a3320 1f2a4e93 00000000 > 00000000 00000000 00000000 dde26800 > Jan 13 08:01:17 fs5-11 kernel: c6e03298 e099535b c6e03298 c386ae00 > c386ae00 c6e033c4 00000001 00000000 > Jan 13 08:01:17 fs5-11 kernel: Call Trace: [] xfs_iformat [xfs] > 0x20f (0xdca71c6c)) > Jan 13 08:01:17 fs5-11 kernel: [] .LC14 [xfs] 0x3d3 (0xdca71c70)) > Jan 13 08:01:17 fs5-11 kernel: [] .LC14 [xfs] 0x3b1 (0xdca71c7c)) > Jan 13 08:01:17 fs5-11 kernel: [] xfs_iread [xfs] 0xdb > (0xdca71c84)) > Jan 13 08:01:17 fs5-11 kernel: [] xfs_iread [xfs] 0xdb > (0xdca71c88)) > Jan 13 08:01:17 fs5-11 kernel: [] xfs_iread [xfs] 0xdb > (0xdca71cac)) > Jan 13 08:01:17 fs5-11 kernel: [] xfs_iget_core [xfs] 0x1b6 > (0xdca71ce8)) > Jan 13 08:01:17 fs5-11 kernel: [] xfs_iget [xfs] 0x7d > (0xdca71d38)) > Jan 13 08:01:17 fs5-11 kernel: [] xfs_dir_lookup_int [xfs] 0x61 > (0xdca71d7c)) > Jan 13 08:01:17 fs5-11 kernel: [] xfs_lookup [xfs] 0x3e > (0xdca71db8)) > Jan 13 08:01:17 fs5-11 kernel: [] linvfs_lookup [xfs] 0x3f > (0xdca71dec)) > Jan 13 08:01:17 fs5-11 kernel: [] cached_lookup [kernel] 0x10 > (0xdca71e10)) > Jan 13 08:01:17 fs5-11 kernel: [] lookup_hash [kernel] 0x91 > (0xdca71e24)) > Jan 13 08:01:17 fs5-11 kernel: [] lookup_one_len [kernel] 0x59 > (0xdca71e40)) > Jan 13 08:01:17 fs5-11 kernel: [] nfsd_lookup [nfsd] 0x340 > (0xdca71e64)) > Jan 13 08:01:17 fs5-11 kernel: [] __wake_up [kernel] 0x4f > (0xdca71ed0)) > Jan 13 08:01:17 fs5-11 kernel: [] svc_sock_enqueue [sunrpc] 0x184 > (0xdca71ef8)) > Jan 13 08:01:17 fs5-11 kernel: [] svc_udp_recvfrom [sunrpc] 0x2d3 > (0xdca71f10)) > Jan 13 08:01:17 fs5-11 kernel: [] nfsd3_proc_lookup [nfsd] 0xd8 > (0xdca71f38)) > Jan 13 08:01:17 fs5-11 kernel: [] nfsd_procedures3 [nfsd] 0x6c > (0xdca71f58)) > Jan 13 08:01:17 fs5-11 kernel: [] nfsd_dispatch [nfsd] 0xb7 > (0xdca71f64)) > Jan 13 08:01:17 fs5-11 kernel: [] nfsd_version3 [nfsd] 0x0 > (0xdca71f7c)) > Jan 13 08:01:17 fs5-11 kernel: [] svc_process_Rsmp_01d929dc > [sunrpc] 0x368 (0xdca71f80)) > Jan 13 08:01:17 fs5-11 kernel: [] nfsd_procedures3 [nfsd] 0x6c > (0xdca71f9c)) > Jan 13 08:01:17 fs5-11 kernel: [] nfsd_version3 [nfsd] 0x0 > (0xdca71fa0)) > Jan 13 08:01:17 fs5-11 kernel: [] nfsd_program [nfsd] 0x0 > (0xdca71fa4)) > Jan 13 08:01:17 fs5-11 kernel: [] nfsd [nfsd] 0x1ca (0xdca71fc0)) > Jan 13 08:01:17 fs5-11 kernel: [] nfsd [nfsd] 0x0 (0xdca71fe0)) > Jan 13 08:01:17 fs5-11 kernel: [] kernel_thread_helper [kernel] > 0x5 (0xdca71ff0)) > Jan 13 08:01:17 fs5-11 kernel: > Jan 13 08:01:17 fs5-11 kernel: nfsd: non-standard errno: -990 > > Tried to run xfs_repair but failed with fatal error: > > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > zero_log: head block 59683 tail block 59683 > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > corrupt block 0 in directory inode 158139 > will junk block > no . entry for directory 158139 > no .. entry for directory 158139 > corrupt block 3 in directory inode 1231523 > will junk block > . > . > . > Phase 5 - rebuild AG headers and trees... > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - ensuring existence of lost+found directory > - traversing filesystem starting at / ... > corrupt block 8 in directory inode 838926683: junking block > rebuilding directory inode 838926683 > corrupt block 5 in directory inode 170001259: junking block > bad hash table for directory inode 170001259 (no data entry): rebuilding > disconnected dir inode 2081119363, moving to lost+found > disconnected dir inode 2116550700, moving to lost+found > . > . > . > Phase 7 - verify and correct link counts... > resetting inode 158139 nlinks from 3 to 2 > resetting inode 16967337 nlinks from 3 to 2 > resetting inode 335545743 nlinks from 2806 to 2805 > fatal error -- couldn't map inode 2133733748, err = 22 > > I found some other list posting with similar problem, did any fix being > release regarding this issue? > > xfs_info as follow: [root@fs5-11 fs5_11us4_2]# xfs_info /fs5_11us4_2/ meta-data=/fs5_11us4_2 isize=256 agcount=128, agsize=561334 blks = sectsz=512 data = bsize=4096 blocks=71850704, 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 The system is now running but I feel there are something wrong with the file system, moving 150GB+ data will be painful. Please help and see if any fixs I can do to recover a clean file system. Many thanks, Eric Yu Systems Engineer Outblaze Ltd. From owner-linux-xfs@oss.sgi.com Mon Jan 19 03:39:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 03:40:02 -0800 (PST) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JBdbmK011549 for ; Mon, 19 Jan 2004 03:39:38 -0800 Received: from darke.mpc.local ([172.16.11.6] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.24) id 1AiWtu-0006kb-TD for linux-xfs@oss.sgi.com; Mon, 19 Jan 2004 10:44:58 +0000 Message-ID: <400BB52A.58800D79@moving-picture.com> Date: Mon, 19 Jan 2004 10:44:58 +0000 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: xfs_force_shutdown from line 1071 of xfs_trans.c References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 1802 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs Content-Length: 3422 Lines: 90 I've recently had a similar problem on a dual Xeon (NFS) server running a 2.4.21 kernel with XFS 1.3: Jan 18 13:14:57 sierra kernel: xfs_force_shutdown(sd(8,17),0x8) called from line 1071 of file xfs_trans.c. Return address = 0xc01cdc26 Jan 18 13:14:57 sierra kernel: Filesystem "sd(8,17)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,17) Jan 18 13:14:57 sierra kernel: Please umount the filesystem, and rectify the problem(s) The file system is on an external hardware RAID box, attached via SCSI to an onboard aic7902 controller - using v1.3.10 of the aic79xx driver. Details of the file system: meta-data=/disk1 isize=256 agcount=206, agsize=1048576 blks data = bsize=4096 blocks=215060139, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=26252 realtime =none extsz=65536 blocks=0, rtextents=0 The system would have been serving files over NFS at the time. Running xfs_repair on the file system afterwards reported no problems. I've seen this problem a few times on other systems... Any ideas what could be the problem? Thanks James Pearson Stephan L Jansen wrote: > > Hi, > > I have a ~ 80GB parition (5 disk hardware RAID 0) on a two processor > Dell 2650. I > have seen two xfs_force_shutdowns on it in the last few days. The > filesystem is > accessed largely via NFS by between 50 or 100 processes on remote > machines. I'm > currently running 2.4.20-28_36.rh8.0.atsmp which is XFS 1.3.0. There > are no other > logs in either syslog or dmesg. Here's the error message: > > Jan 14 10:27:16 glimpse4 kernel: xfs_force_shutdown(sd(8,5),0x8) called > from line 1071 of file xfs_trans.c. Return address = 0xf88d26eb > Jan 14 10:27:16 glimpse4 kernel: Filesystem "sd(8,5)": Corruption of > in-memory data detected. Shutting down filesystem: sd(8,5) > Jan 14 10:27:16 glimpse4 kernel: Please umount the filesystem, and > rectify the problem(s) > Jan 14 10:27:16 glimpse4 kernel: xfs_force_shutdown(sd(8,5),0x2) called > from line 747 of file xfs_log.c. Return address = 0xf88d26eb > > For various reasons I was running an older kernel 1.2.0 when this first > showed up. The message from > 1.2.0 appears to be an old bug (see > http://oss.sgi.com/bugzilla/show_bug.cgi?id=186). Here's the message > from that kernel: > > Jan 11 13:22:32 glimpse4 kernel: xfs_force_shutdown(sd(8,5),0x8) called > from line 1042 of file xfs_trans.c. Return address = 0xc01d3738 > Jan 11 13:22:32 glimpse4 kernel: xfs_force_shutdown(sd(8,5),0x2) called > from line 721 of file xfs_log.c. Return address = 0xc01c53a1 > > Here's the output from xfs_info > > xfs_info /usr/data/glimpse4 > > meta-data=/usr/data/glimpse4 isize=256 agcount=20, > agsize=1048576 blks > = sectsz=512 > data = bsize=4096 blocks=20384469, > imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=2488, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > Should I backup, mkfs and restore? > > ------- Stephan From owner-linux-xfs@oss.sgi.com Mon Jan 19 09:34:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 09:34:37 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JHYNmK002105 for ; Mon, 19 Jan 2004 09:34:25 -0800 Received: from naboo.americas.sgi.com ([128.162.233.73]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0JHYHNC028020 for ; Mon, 19 Jan 2004 09:34:17 -0800 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id 8CFB18C8711; Mon, 19 Jan 2004 11:33:57 -0600 (CST) Subject: PARTIAL TAKE 907738 - Remove non 2.4 ifdefs from the linux-2.4 dir Message-Id: <20040119173357.8CFB18C8711@naboo.americas.sgi.com> Date: Mon, 19 Jan 2004 11:33:57 -0600 (CST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1803 X-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: 252 Lines: 10 Date: Mon Jan 19 09:33:25 PST 2004 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:165064a linux-2.4/xfs_buf.h - 1.87 From owner-linux-xfs@oss.sgi.com Mon Jan 19 10:47:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 10:47:14 -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 i0JIkxmK007598 for ; Mon, 19 Jan 2004 10:47:02 -0800 Received: from telus.net ([161.184.244.187]) by priv-edtnes57.telusplanet.net (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with ESMTP id <20040119184654.IUXN13868.priv-edtnes57.telusplanet.net@telus.net> for ; Mon, 19 Jan 2004 11:46:54 -0700 Message-ID: <400C261E.6030305@telus.net> Date: Mon, 19 Jan 2004 11:46:54 -0700 From: Aly Dharshi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031115 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [Fwd: Re: Anaconda and XFS FS] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1804 X-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: 1335 Lines: 46 -------- Original Message -------- Subject: Re: Anaconda and XFS FS Date: Sun, 18 Jan 2004 22:17:44 -0500 (EST) From: ne... Reply-To: fedora-list@redhat.com To: fedora-list@redhat.com References: <1074466234.16747.1.camel@localhost.localdomain> On Jan 18, 2004 at 15:50, Aly Dharshi in a soothing rage wrote: >Hi Folks, > > Is there any chance that Anaconda will allow XFS to be installed in the >same fashion as reiserfs/jfs or via the Anaconda gui like we do for EXT3 >et al. You cannot create XFS partitions with anaconda but you should be able to install over previously created XFS partitions using 'linux xfs' at the boot prompt when installing. N.Emile... -- Registered Linux User # 125653 (http://counter.li.org) Switch to: http://www.speakeasy.net/refer/190653 Today is a good day for information-gathering. Read someone else's mail file. 22:15:34 up 46 days, 3:02, 3 users, load average: 0.00, 0.00, 0.00 -- 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 Mon Jan 19 12:04:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 12:04:58 -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 i0JK4jmK011870 for ; Mon, 19 Jan 2004 12:04:46 -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 i0JK4h9J030436; Mon, 19 Jan 2004 21:04:43 +0100 Message-ID: <400C3967.2020607@stesmi.com> Date: Mon, 19 Jan 2004 21:09:11 +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: Aly Dharshi CC: linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: Anaconda and XFS FS] References: <400C261E.6030305@telus.net> In-Reply-To: <400C261E.6030305@telus.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1805 X-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: 921 Lines: 28 Hi. >> Hi Folks, >> >> Is there any chance that Anaconda will allow XFS to be installed >> in the >> same fashion as reiserfs/jfs or via the Anaconda gui like we do for EXT3 >> et al. > > You cannot create XFS partitions with anaconda but you should > be able to install over previously created XFS partitions using > 'linux xfs' at the boot prompt when installing. > > N.Emile... That's a load of crap. The latest anaconda can install on XFS although it only understand the 2.6 kernel. Yes, you use the "linux xfs" trick but you can install on it as long as the kernel supports xfs which the fedora testing ones do. On a sidenote - anyone waiting for FC1 with XFS support I've been working my ass off on it and am currently using the beta anaconda installer (albeit pretty hacked by me to support 2.4 and other things) so something is brewing. No timescales or anything. Only that it's on the way. // Stefan From owner-linux-xfs@oss.sgi.com Mon Jan 19 12:20:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 12:20:59 -0800 (PST) Received: from mail.myphorum.de (mysnip.de.gw.net-build.de [194.25.82.254] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JKKkmK016208 for ; Mon, 19 Jan 2004 12:20:47 -0800 Received: from localhost (myphorum [127.0.0.1]) by mail.myphorum.de (Postfix) with ESMTP id EDE63274348; Mon, 19 Jan 2004 21:20:44 +0100 (CET) Received: from mail.myphorum.de ([127.0.0.1]) by localhost (myphorum.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26085-05; Mon, 19 Jan 2004 21:20:44 +0100 (CET) Received: from myphorum.com (pD9E825AA.dip.t-dialin.net [217.232.37.170]) by mail.myphorum.de (Postfix) with ESMTP id 1B121274347; Mon, 19 Jan 2004 21:20:44 +0100 (CET) Message-ID: <400C3C1B.6030503@myphorum.com> Date: Mon, 19 Jan 2004 21:20:43 +0100 From: "Thomas (maillists)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MultiZilla/1.6.0.0b X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Smietanowski Cc: linux-xfs@oss.sgi.com Subject: Re: [Fwd: Re: Anaconda and XFS FS] References: <400C261E.6030305@telus.net> <400C3967.2020607@stesmi.com> In-Reply-To: <400C3967.2020607@stesmi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mysnip.de X-archive-position: 1806 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: thomas-lists@myphorum.com Precedence: bulk X-list: linux-xfs Content-Length: 811 Lines: 32 Stefan Smietanowski wrote: > Hi. > >>> Hi Folks, >>> >>> Is there any chance that Anaconda will allow XFS to be installed >>> in the >>> same fashion as reiserfs/jfs or via the Anaconda gui like we do for >>> EXT3 >>> et al. >> >> >> You cannot create XFS partitions with anaconda but you should >> be able to install over previously created XFS partitions using >> 'linux xfs' at the boot prompt when installing. >> >> N.Emile... > > > That's a load of crap. The latest anaconda can install on XFS although > it only understand the 2.6 kernel. Yes, you use the "linux xfs" trick > but you can install on it as long as the kernel supports xfs which > the fedora testing ones do. Thats exactly what the above message told. Do you mean that it can also "CREATE" XFS-filesystems with anaconda? thomas From owner-linux-xfs@oss.sgi.com Mon Jan 19 15:06:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 15:06:53 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JN6TmK023918 for ; Mon, 19 Jan 2004 15:06:30 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0JN6Nxq013372 for ; Mon, 19 Jan 2004 15:06:24 -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 i0JN6MhI530157 for ; Tue, 20 Jan 2004 10:06:22 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0JN6Lu9531279 for linux-xfs@oss.sgi.com; Tue, 20 Jan 2004 10:06:21 +1100 (EST) Date: Tue, 20 Jan 2004 10:06:21 +1100 (EST) From: Nathan Scott Message-Id: <200401192306.i0JN6Lu9531279@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix configure issue X-archive-position: 1807 X-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: 525 Lines: 18 Fix up autoconf/configure issues, esp. mishandling the AC_CHECK_SIZEOF macro. Date: Mon Jan 19 15:05:49 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com,netllama@linux-sxs.org The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:165069a dmapi/m4/package_xfslibs.m4 - 1.3 dmapi/aclocal.m4 - 1.4 xfsprogs/aclocal.m4 - 1.6 xfsprogs/m4/package_types.m4 - 1.2 xfsdump/m4/package_xfslibs.m4 - 1.3 xfsdump/aclocal.m4 - 1.6 From owner-linux-xfs@oss.sgi.com Mon Jan 19 16:00:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 16:01: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 i0K00pmK026791 for ; Mon, 19 Jan 2004 16:00:51 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0K00o7B026790 for linux-xfs@oss.sgi.com; Mon, 19 Jan 2004 16:00:50 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i0K00nmM026776 for ; Mon, 19 Jan 2004 16:00:49 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0JNTFe6025012; Mon, 19 Jan 2004 15:29:15 -0800 Date: Mon, 19 Jan 2004 15:29:15 -0800 Message-Id: <200401192329.i0JNTFe6025012@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: 1808 X-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: 595 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=299 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From nathans@sgi.com 2004-19-01 15:29 PDT ------- The fix for this issue has been merged, so marking this bug resolved. ------- 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 Jan 19 16:17:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 16:17:37 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K0HBmK027548 for ; Mon, 19 Jan 2004 16:17:11 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0JMUNP6009554 for ; Mon, 19 Jan 2004 14:30:23 -0800 Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by nodin.corp.sgi.com (8.12.9/8.11.4/nodin-1.0) with ESMTP id i0JMUMfB20462225 for ; Mon, 19 Jan 2004 14:30:22 -0800 (PST) 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 i0JMUKw9006456; Mon, 19 Jan 2004 16:30:21 -0600 Received: (from sandeen@localhost) by stout.americas.sgi.com (8.12.8/8.12.8/Submit) id i0JMUK2l006454; Mon, 19 Jan 2004 16:30:20 -0600 Date: Mon, 19 Jan 2004 16:30:20 -0600 From: Eric Sandeen Message-Id: <200401192230.i0JMUK2l006454@stout.americas.sgi.com> Subject: PARTIAL TAKE 907982 - plug memory leak in libxfs X-archive-position: 1809 X-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: 567 Lines: 23 Fix a memory leak in libxfs, were not freeing allocated inode forks Date: Mon Jan 19 14:29:50 PST 2004 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:165068a cmd/xfsprogs/include/libxfs.h - 1.32 - prototype for new libxfs_idestroy_fork cmd/xfsprogs/libxfs/rdwr.c - 1.22 - call libxfs_idestroy/libxfs_idestroy_fork cmd/xfsprogs/libxfs/xfs.h - 1.40 - #define for libxfs_idestroy_fork From owner-linux-xfs@oss.sgi.com Mon Jan 19 18:23:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 18:23: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 i0K2NImK002182 for ; Mon, 19 Jan 2004 18:23:20 -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 i0JNiJB5013360 for ; Mon, 19 Jan 2004 15:44: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 i0K0gQhI540420 for ; Tue, 20 Jan 2004 11:42:27 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0K0gQqt539475 for linux-xfs@oss.sgi.com; Tue, 20 Jan 2004 11:42:26 +1100 (EST) Date: Tue, 20 Jan 2004 11:42:26 +1100 (EST) From: Nathan Scott Message-Id: <200401200042.i0K0gQqt539475@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfsprogs X-archive-position: 1811 X-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: 60 xfsprogs update - Debian installer support, sync user/kernel stuff. Date: Mon Jan 19 16:41:43 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:165071a xfsprogs/VERSION - 1.96 xfsprogs/doc/CHANGES - 1.133 - xfsprogs update - Debian installer support, sync user/kernel stuff. xfsprogs/mkfs/xfs_mkfs.h - 1.8 xfsprogs/include/xfs_ag.h - 1.15 - Sync up user/kernel code, stop sharing some trivial headers. xfsprogs/include/libxfs.h - 1.33 - Fix whitespace botch, update copyright. xfsprogs/include/Makefile - 1.19 xfsprogs/include/xfs_attr_leaf.h - 1.9 xfsprogs/include/xfs_types.h - 1.22 - Sync up user/kernel code, stop sharing some trivial headers. xfsprogs/debian/control - 1.16 xfsprogs/debian/Makefile - 1.9 xfsprogs/debian/changelog - 1.87 xfsprogs/debian/rules - 1.19 - Debian installer support from Steve Langasek. xfsprogs/repair/attr_repair.h - 1.10 xfsprogs/repair/attr_repair.c - 1.16 - Sync up user/kernel code, stop sharing some trivial headers. xfsprogs/libxfs/xfs.h - 1.41 - Fix whitespace botch, update copyright. xfsprogs/libxfs/xfs_attr_leaf.c - 1.10 - Sync up user/kernel code, stop sharing some trivial headers. xfsprogs/libxfs/xfs_dir2_node.c - 1.16 - Fix some compiler warnings. xfsprogs/include/buildmacros - 1.12 - Debian installer support from Steve Langasek. xfsprogs/include/xfs_cap.h - 1.7 xfsprogs/include/xfs_mac.h - 1.6 xfsprogs/include/xfs_acl.h - 1.9 - Sync up user/kernel code, stop sharing some trivial headers. xfsprogs/io/pread.c - 1.9 xfsprogs/io/pwrite.c - 1.9 - Fix some compiler warnings. From owner-linux-xfs@oss.sgi.com Mon Jan 19 18:23:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 18:23:51 -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 i0K2NbmK002257 for ; Mon, 19 Jan 2004 18:23:39 -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 i0JNYZB5012063 for ; Mon, 19 Jan 2004 15:34:37 -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 i0K0WehI540195; Tue, 20 Jan 2004 11:32:40 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0K0Wd7A540343; Tue, 20 Jan 2004 11:32:39 +1100 (EST) Date: Tue, 20 Jan 2004 11:32:39 +1100 (EST) From: Nathan Scott Message-Id: <200401200032.i0K0Wd7A540343@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 907983 - xfsprogs X-archive-position: 1812 X-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: 363 Lines: 14 Update xfs_db to dump out attrs in the security namespace as well. Date: Mon Jan 19 16:31:03 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:165070a xfsprogs/db/attr.c - 1.9 xfsprogs/db/attrshort.c - 1.7 From owner-linux-xfs@oss.sgi.com Mon Jan 19 18:22:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 18:22:58 -0800 (PST) Received: from bycast.com (bycast.com [207.61.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K2MZmK002099 for ; Mon, 19 Jan 2004 18:22:46 -0800 Received: from bycast.com (24.84.168.245) by bycast.com with ESMTP (Eudora Internet Mail Server 3.0) for ; Mon, 19 Jan 2004 19:28:58 -0700 Message-ID: <400C90E4.8040909@bycast.com> Date: Mon, 19 Jan 2004 18:22:28 -0800 From: Mike Montour 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: dm_write_invis() blocking problem Content-Type: multipart/mixed; boundary="------------070108040300070206020004" X-archive-position: 1810 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mmontour@bycast.com Precedence: bulk X-list: linux-xfs Content-Length: 5965 Lines: 226 This is a multi-part message in MIME format. --------------070108040300070206020004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, I am developing an application using XFS/DMAPI on Linux 2.4. My application registers for DM_EVENT_READ and DM_EVENT_WRITE events on a file, then calls dm_punch_hole() on that file. The event handlers use dm_write_invis() to re-populate the file data on demand (including re-populating all of the original file data before allowing the first write operation to continue). This works fine for READ events. However, whenever I get a WRITE event, the call to dm_write_invis() blocks my program. If I kill (ctrl-C) the application that triggered the WRITE event, then the dm_write_invis() call returns successfully and my program continues. I have attached a test program that illustrates this behaviour. The XFS filesystem is mounted on /mnt and I use a file "/mnt/TESTFILE". Reading from the file works: --- mmontour:/home/mmontour# dd if=/mnt/TESTFILE bs=100 count=1 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB1+0records in 1+0 records out --- and my DMAPI program produces the following output: --- mmontour:/home/mmontour# ./a.out SGI DMAPI (XDSM) API, Release 1.0. Waiting for event... Got DM_EVENT_READ, de_offset 0, de_length 100 Requesting DM_RIGHT_EXCL Calling dm_write_invis() dm_write_invis() returns 100 Sending DM_RESP_CONTINUE Done --- However, when I try to write: --- mmontour:/home/mmontour# dd if=/dev/zero of=/mnt/TESTFILE bs=100 count=1 --- my DMAPI program hangs after: --- mmontour:/home/mmontour# ./a.out SGI DMAPI (XDSM) API, Release 1.0. Waiting for event... Got DM_EVENT_WRITE, de_offset 0, de_length 100 Requesting DM_RIGHT_EXCL Calling dm_write_invis() --- -------------------------------- Kernel is 2.4.24-pre1 plus the xfs-2.4.24-pre1-all-i386.bz2 patch. From dmesg: SGI XFS snapshot 2.4.24-pre1-2003-12-11_23:47_UTC with ACLs, no debug enabled XFS config options are: CONFIG_XFS_FS=y # CONFIG_XFS_QUOTA is not set CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set CONFIG_XFS_DMAPI=y # CONFIG_XFS_TRACE is not set # CONFIG_XFS_DEBUG is not set Additional information is available on request. Am I doing something wrong in my program, is this a known limitation of Linux/XFS/DMAPI, or is this a bug? -Mike Montour -------------------------------- --------------070108040300070206020004 Content-Type: text/x-csrc; name="dmapi_test.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmapi_test.c" #include #include #include #include #include #define MTPT "/mnt" #define TESTFILE "/mnt/TESTFILE" int main(int argc, char *argv[]) { char *str = NULL; int rc = 0; int myfile; char *data = NULL; int nbytes; char buf[256]; size_t bufBytes; dm_sessid_t Session; dm_eventset_t eSet; void *fsHandle; size_t fsHandle_len; void *fileHandle; size_t fileHandle_len; void *eventHandle; size_t eventHandle_len; dm_boolean_t exactflag; dm_region_t rFlags; dm_eventmsg_t *eventMsg; dm_data_event_t *dataEvent; /* Setup */ rc = dm_init_service(&str); assert(rc == 0); printf("%s\n", str); rc = dm_create_session(DM_NO_SESSION, "test", &Session); assert(rc == 0); rc = dm_path_to_fshandle(MTPT, &fsHandle, &fsHandle_len); assert(rc == 0); DMEV_ZERO(eSet); DMEV_SET(DM_EVENT_READ, eSet); DMEV_SET(DM_EVENT_WRITE, eSet); rc = dm_set_disp(Session, fsHandle, fsHandle_len, DM_NO_TOKEN, &eSet, DM_EVENT_MAX); assert(rc == 0); /* Create file (removing old one if present) */ rc = unlink(TESTFILE); assert((rc == 0) || (errno == ENOENT)); myfile = open(TESTFILE, O_WRONLY | O_CREAT, 0644); data = (char *)malloc(100); memset(data,'A',100); nbytes = write(myfile, data, 100); assert (nbytes == 100); close(myfile); free(data); /* Register for notification and punch hole */ rc = dm_path_to_handle(TESTFILE, &fileHandle, &fileHandle_len); assert(rc == 0); rFlags.rg_offset = 0; rFlags.rg_size = 0; rFlags.rg_flags = DM_REGION_READ | DM_REGION_WRITE; rc = dm_set_region(Session, fileHandle, fileHandle_len, DM_NO_TOKEN, 1, &rFlags, &exactflag); assert(rc == 0); rc = dm_punch_hole(Session, fileHandle, fileHandle_len, DM_NO_TOKEN, 0, 0); assert(rc == 0); /* Get event */ printf("Waiting for event...\n"); fflush(stdout); rc = dm_get_events(Session,1,DM_EV_WAIT,256,buf,&bufBytes); assert(rc == 0); eventMsg = (dm_eventmsg_t *)buf; switch(eventMsg->ev_type) { case DM_EVENT_READ: printf("Got DM_EVENT_READ, "); break; case DM_EVENT_WRITE: printf("Got DM_EVENT_WRITE, "); break; default: assert(0); } dataEvent = DM_GET_VALUE(eventMsg, ev_data, dm_data_event_t *); printf("de_offset %lld, de_length %lld\n", dataEvent->de_offset, dataEvent->de_length); fflush(stdout); eventHandle = DM_GET_VALUE(dataEvent, de_handle, void *); eventHandle_len = DM_GET_LEN(dataEvent, de_handle); /* Put data into file */ printf("Requesting DM_RIGHT_EXCL\n"); fflush(stdout); rc = dm_request_right(Session, eventHandle, eventHandle_len, eventMsg->ev_token, DM_RR_WAIT, DM_RIGHT_EXCL); assert(rc == 0); data = (char *)malloc(100); memset(data,'B',100); printf("Calling dm_write_invis()\n"); fflush(stdout); rc = dm_write_invis(Session, eventHandle, eventHandle_len, eventMsg->ev_token, 0, 0, 100, data); printf("dm_write_invis() returns %d\n", rc); fflush(stdout); rc = dm_release_right(Session, eventHandle, eventHandle_len, eventMsg->ev_token); assert(rc == 0); /* Respond to event*/ printf("Sending DM_RESP_CONTINUE\n"); fflush(stdout); rc = dm_respond_event(Session, eventMsg->ev_token, DM_RESP_CONTINUE, 0, 0, NULL); assert(rc == 0); /* Shutdown */ dm_destroy_session(Session); printf("Done\n"); fflush(stdout); return 0; } --------------070108040300070206020004-- From owner-linux-xfs@oss.sgi.com Mon Jan 19 23:37:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Jan 2004 23:37:56 -0800 (PST) Received: from mephisto.ktf.rtu.lv (root@[213.175.91.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K7bfmK017646 for ; Mon, 19 Jan 2004 23:37:43 -0800 Received: from deevee.lv (diablo.integoplus.lv [213.21.215.5]) by mephisto.ktf.rtu.lv (8.12.8/8.11.4) with SMTP id i0K7aewY000785 for ; Tue, 20 Jan 2004 09:36:43 +0200 Date: Tue, 20 Jan 2004 09:38:39 +0200 From: Jancs To: linux-xfs@oss.sgi.com Subject: XFS and Win32 Message-Id: <20040120093839.0000399a@ED333JE.sprk.gov.lv> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.3.0; Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1813 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jancs@dv.lv Precedence: bulk X-list: linux-xfs Content-Length: 265 Lines: 16 Dear sirs! just a small question - is there some software for win32 able to work with xfs partitions? For ext3/reiserfs there is allready... -- Jancs Laps Cileecish Veel 305 meeneshi liidz pensijai... http://openoffice-lv.sourceforge.net http://tehvi.dv.lv From owner-linux-xfs@oss.sgi.com Tue Jan 20 00:34:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Jan 2004 00:34: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 i0K8YKmK023032 for ; Tue, 20 Jan 2004 00:34:21 -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 i0J4DlI5020073 for ; Sun, 18 Jan 2004 20:13:47 -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 QAA15260; Mon, 19 Jan 2004 16:11:57 +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 i0J5BtUc3409523; Mon, 19 Jan 2004 16:11:56 +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 i0J5Bp82001731; Mon, 19 Jan 2004 16:11:51 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i0J5Bosn001729; Mon, 19 Jan 2004 16:11:50 +1100 Date: Mon, 19 Jan 2004 16:11:50 +1100 From: Nathan Scott To: sapna todwal Cc: linux-xfs@oss.sgi.com Subject: Re: XFS-VFS Message-ID: <20040119051150.GG802@frodo> References: <20040119050129.79985.qmail@web8206.mail.in.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040119050129.79985.qmail@web8206.mail.in.yahoo.com> User-Agent: Mutt/1.5.3i X-archive-position: 1814 X-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: 345 Lines: 19 On Mon, Jan 19, 2004 at 05:01:29AM +0000, sapna todwal wrote: > hi, > can anybody tell me does vfs supports xfs. i mean hmm? > while setting extended attributes what are the > corresponding vfs calls that are called? Refer to fs/xattr.c in the kernel source, which calls into fs/xfs/linux/xfs_iops.c for XFS. Have fun. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 20 07:09:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Jan 2004 07:09:42 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0KF9FmK007101 for ; Tue, 20 Jan 2004 07:09:15 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0KF99Uu020630 for ; Tue, 20 Jan 2004 07:09:09 -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 i0KF99mK30553312; Tue, 20 Jan 2004 09:09: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 i0KF98K214209589; Tue, 20 Jan 2004 09:09:08 -0600 (CST) Date: Tue, 20 Jan 2004 09:09:08 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jancs cc: linux-xfs@oss.sgi.com Subject: Re: XFS and Win32 In-Reply-To: <20040120093839.0000399a@ED333JE.sprk.gov.lv> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1816 X-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: 187 Lines: 11 Just a small answer - no. :) -Eric On Tue, 20 Jan 2004, Jancs wrote: > Dear sirs! > > just a small question - is there some software for win32 able to work > with xfs partitions? From owner-linux-xfs@oss.sgi.com Tue Jan 20 16:27:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Jan 2004 16:27:44 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0L0RWmK004821 for ; Tue, 20 Jan 2004 16:27:32 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0L0RKpG017322 for ; Tue, 20 Jan 2004 16:27: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 i0L0RIhI664246 for ; Wed, 21 Jan 2004 11:27:19 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0L0RIr3664931 for linux-xfs@oss.sgi.com; Wed, 21 Jan 2004 11:27:18 +1100 (EST) Date: Wed, 21 Jan 2004 11:27:18 +1100 (EST) From: Nathan Scott Message-Id: <200401210027.i0L0RIr3664931@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - build fix X-archive-position: 1817 X-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: 313 Lines: 12 Fix build fallout from removing more kernel-version ifdef goo. Date: Tue Jan 20 16:25:22 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:165147a linux-2.4/xfs_buf.h - 1.88 From owner-linux-xfs@oss.sgi.com Tue Jan 20 19:58:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Jan 2004 19:59:22 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0L3wumK010199 for ; Tue, 20 Jan 2004 19:58:56 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i0L0kJpG024665 for ; Tue, 20 Jan 2004 16:46:22 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA14830 for ; Wed, 21 Jan 2004 11:46:18 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i0L0kH7a015041 for ; Wed, 21 Jan 2004 11:46:18 +1100 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i0L0kHh2015039 for linux-xfs@oss.sgi.com; Wed, 21 Jan 2004 11:46:17 +1100 Date: Wed, 21 Jan 2004 11:46:17 +1100 From: Tim Shimmin Message-Id: <200401210046.i0L0kHh2015039@sherman.melbourne.sgi.com> Subject: TAKE xfstests/018 Apparently-To: X-archive-position: 1818 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 628 Lines: 22 Fix up failure of log qa test 018 due to running with Electric Fence and somehow me not checking in my 018.noquota.op change in ages ago and left in my workarea. Date: Tue Jan 20 16:43:00 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:165148a xfstests/018.noquota.op - 1.2 - This change was done at the time of a change to common.log but somehow didn't get checked in. xfstests/common.log - 1.2 - Fix up MOUNT_OPTIONS filtering and xfs_logprint filtering. From owner-linux-xfs@oss.sgi.com Wed Jan 21 04:15:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Jan 2004 04:15:51 -0800 (PST) Received: from gw1.takuwa.org (usen-221x115x10x52.ap-US01.usen.ad.jp [221.115.10.52]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LCFFmK031685 for ; Wed, 21 Jan 2004 04:15:16 -0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw1.takuwa.org (Postfix) with ESMTP id 8F27624003AD for ; Wed, 21 Jan 2004 21:15:08 +0900 (JST) Date: Wed, 21 Jan 2004 21:15:08 +0900 From: Susumu Takuwa To: linux-xfs@oss.sgi.com Subject: 2.4.24 and xfs Message-Id: <20040121210648.6F38.SUSUMU-T@po.sakura.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.04 [ja] X-archive-position: 1819 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: susumu-t@po.sakura.ne.jp Precedence: bulk X-list: linux-xfs Content-Length: 257 Lines: 9 Hi, I use linux-2.4.23 and xfs-2.4.23-all-i386.bz2. I'd like to update linux kernel to version 2.4.24, then I searched its patch but I could not find it. So, I'm going to use xfs-2.4.23-all-i386.bz2 for 2.4.24 tree. Is there any problem? Susumu Takuwa From owner-linux-xfs@oss.sgi.com Wed Jan 21 04:26:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Jan 2004 04:26:41 -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 i0LCQGmK002711 for ; Wed, 21 Jan 2004 04:26:17 -0800 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 81093EB4A06 for ; Wed, 21 Jan 2004 20:26:09 +0800 (PHT) Received: from lawin.alabang.leathercollection.ph (lawin.alabang.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id E0731EB4A00 for ; Wed, 21 Jan 2004 20:26:01 +0800 (PHT) Received: by lawin.alabang.leathercollection.ph (Postfix, from userid 1000) id 2FD021A4023; Wed, 21 Jan 2004 20:25:58 +0800 (PHT) Date: Wed, 21 Jan 2004 20:25:58 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: 2.4.24 and xfs Message-ID: <20040121122558.GB12019@leathercollection.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040121210648.6F38.SUSUMU-T@po.sakura.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040121210648.6F38.SUSUMU-T@po.sakura.ne.jp> 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: 1820 X-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: 687 Lines: 16 On Wed, Jan 21, 2004 at 09:15:08PM +0900, Susumu Takuwa wrote: > Hi, I use linux-2.4.23 and xfs-2.4.23-all-i386.bz2. I'd like to update > linux kernel to version 2.4.24, then I searched its patch but I could > not find it. So, I'm going to use xfs-2.4.23-all-i386.bz2 for 2.4.24 > tree. Is there any problem? There is no problem. You can apply the 2.4.23 patch on 2.4.24. You just have to correct the Makefile reject, but it's very trivial. --> Jijo -- 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 Jan 21 05:01:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Jan 2004 05:02:22 -0800 (PST) Received: from gw1.takuwa.org (usen-221x115x10x52.ap-US01.usen.ad.jp [221.115.10.52]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LD1vmK003787 for ; Wed, 21 Jan 2004 05:01:57 -0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw1.takuwa.org (Postfix) with ESMTP id D817E24003AD for ; Wed, 21 Jan 2004 22:01:50 +0900 (JST) Date: Wed, 21 Jan 2004 22:01:51 +0900 From: Susumu Takuwa To: linux-xfs@oss.sgi.com Subject: Re: 2.4.24 and xfs In-Reply-To: <20040121122558.GB12019@leathercollection.ph> References: <20040121210648.6F38.SUSUMU-T@po.sakura.ne.jp> <20040121122558.GB12019@leathercollection.ph> Message-Id: <20040121215348.6F3B.SUSUMU-T@po.sakura.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.04 [ja] X-archive-position: 1821 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: susumu-t@po.sakura.ne.jp Precedence: bulk X-list: linux-xfs Content-Length: 340 Lines: 13 >>>>> On Wed, 21 Jan 2004 20:25:58 +0800 Federico Sevilla III writes: FSI> There is no problem. You can apply the 2.4.23 patch on 2.4.24. You just FSI> have to correct the Makefile reject, but it's very trivial. I have apllied it on 2.4.24 and edited Makefike. Now I can build new kernel without anxiety, thank you :) Susumu Takuwa From owner-linux-xfs@oss.sgi.com Wed Jan 21 05:32:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Jan 2004 05:32:43 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LDWImK004843 for ; Wed, 21 Jan 2004 05:32:18 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0GNSb3l028251 for ; Fri, 16 Jan 2004 15:28:37 -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 i0GNSZAV29976899; Fri, 16 Jan 2004 17:28: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 i0GNSZK113974452; Fri, 16 Jan 2004 17:28:35 -0600 (CST) Subject: Re: List configuration From: Eric Sandeen To: Arthur Corliss Cc: "Thomas (maillists)" , linux-xfs@oss.sgi.com In-Reply-To: References: <4007500D.1060806@linuxmail.org> <40086E9F.90602@myphorum.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1074295715.1535.12.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Jan 2004 17:28:35 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1822 X-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: 948 Lines: 24 On Fri, 2004-01-16 at 17:16, Arthur Corliss wrote: > > You are free to unsubscribe. > > Yes, I am. But until someone from SGI tells me that they refuse to fix the > list config, I'm going to stay and hope it gets fixed. I want to get the > legitimate e-mails, I just don't want the spam. And I really don't think I'm > being unreasonable for expecting that much. We do not plan to change our previous conscious decision to keep the list open. It's not broken, it's intentional. I'm sorry you don't like it. It's not your choice. staying subscribed, or not, is your choice. spamd died for a while, some spam got through, deal with it. If you can't deal with it, please -do- unsubscribe. This thread has had higher volume, and not much more useful content, then the small bit of spam that leaked through. -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 Jan 21 22:27:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Jan 2004 22:27:50 -0800 (PST) Received: from slapper.slappy.org (dsl-321.cascadeaccess.com [64.233.106.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0M6RPmK022929 for ; Wed, 21 Jan 2004 22:27:25 -0800 Received: from bknotts by slapper.slappy.org with local (Exim 3.36 #1 (Debian)) id 1AjYJH-0007Ak-00 for ; Wed, 21 Jan 2004 22:27:23 -0800 From: Brian Knotts To: linux-xfs@oss.sgi.com Subject: Re: power failure .. broken files.. broken FS :(. Date: Wed, 21 Jan 2004 22:27:23 -0800 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401212227.23559.bknotts@cascadeaccess.com> X-archive-position: 1824 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bknotts@cascadeaccess.com Precedence: bulk X-list: linux-xfs Content-Length: 1380 Lines: 42 I am having the same problem with a file on one of my partitions. Interestingly, I am also running debian sid. In addition to the same stuff you are getting back from xfs_repair, I get this in the syslog: Jan 21 19:26:28 slapper kernel: Filesystem "ide2(33,7)": corrupt dinode 17257408 , extent total = 1, nblocks = 0. Unmount and run xfs_repair. Jan 21 19:26:28 slapper kernel: 0x0: 49 4e 81 a4 01 02 00 01 00 00 00 00 00 00 0 0 00 Jan 21 19:26:28 slapper kernel: Filesystem "ide2(33,7)": XFS internal error xfs_ iformat(1) at line 473 of file xfs_inode.c. Caller 0xc0208e32 Jan 21 19:26:28 slapper kernel: c234fd60 c02078c8 c03becaa 00000001 cf960800 c03 bec88 000001d9 c0208e32 Jan 21 19:26:28 slapper kernel: c0208e32 00000000 cf960800 00000000 01000 000 00000000 00000001 00000000 Jan 21 19:26:28 slapper kernel: ca09f3f0 c0208e32 ca09f3f0 c6de3000 00000 001 00000000 c234fdd0 00000000 Jan 21 19:26:28 slapper kernel: Call Trace: [xfs_iformat+280/1536] [xfs_iread+4 50/544] [xfs_iread+450/544] [xfs_iread+450/544] [xfs_iget_core+212/1312] [xf s_iget+311/400] [xfs_dir_lookup_int+172/304] [xfs_lookup+80/144] [linvfs_look up+95/160] [real_lookup+242/320] [link_path_walk+1616/1904] [path_lookup+57/6 4] [__user_walk+73/96] [fput+228/320] [sys_stat64+31/144] [sys_rt_sigprocmas k+306/448] [system_call+51/56] -- Brian Knotts From owner-linux-xfs@oss.sgi.com Wed Jan 21 23:28:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Jan 2004 23:28:44 -0800 (PST) Received: from daisy1.daisytechbg.com (daisy1.daisytechbg.com [212.5.131.209]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0M7SOmK024894 for ; Wed, 21 Jan 2004 23:28:29 -0800 Received: from Daisy-Message_Server by daisy1.daisytechbg.com with Novell_GroupWise; Thu, 22 Jan 2004 09:28:15 +0200 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.7.1 Date: Thu, 22 Jan 2004 09:27:46 +0200 From: "Romeo Ninov" To: Subject: help with ISO Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0M7SWmK024897 X-archive-position: 1825 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: RNinov@daisytechbg.com Precedence: bulk X-list: linux-xfs Content-Length: 238 Lines: 10 Can anyone tell me where I can download a instalation ISO of XFS for RH9? Or scripts to build this CD Thank You in advance <><><><><><><><><><><><><><><><> Regards: Romeo Ninov <><><><><><><><><><><><><><><><> From owner-linux-xfs@oss.sgi.com Thu Jan 22 00:51:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Jan 2004 00:51: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 i0M8pAmK029689 for ; Thu, 22 Jan 2004 00:51:13 -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 i0M8p1sK008591; Thu, 22 Jan 2004 09:51:01 +0100 Message-ID: <400F9005.405@stesmi.com> Date: Thu, 22 Jan 2004 09:55:33 +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: Romeo Ninov , XFS List Subject: Re: help with ISO References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1826 X-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: 506 Lines: 23 Romeo Ninov wrote: > Can anyone tell me where I can download a instalation ISO of XFS for RH9? > Or scripts to build this CD > Thank You in advance > > > <><><><><><><><><><><><><><><><> > Regards: Romeo Ninov > <><><><><><><><><><><><><><><><> > > ftp://oss.sgi.com/projects/xfs/ It might be there if it was respun. You can also download the DVD from ftp://ftp.uninett.no/pub/linux/RH-XFS-DVD The difference is that the DVD contains RH9 and some errata updates. // Stefan From owner-linux-xfs@oss.sgi.com Thu Jan 22 03:00:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Jan 2004 03:02: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 i0MB0GmK002231 for ; Thu, 22 Jan 2004 03:00:16 -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 i0L4xS9o030633 for ; Tue, 20 Jan 2004 20:59:30 -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 i0L5vVhI729158 for ; Wed, 21 Jan 2004 16:57:32 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0L5vVIi730493 for linux-xfs@oss.sgi.com; Wed, 21 Jan 2004 16:57:31 +1100 (EST) Date: Wed, 21 Jan 2004 16:57:31 +1100 (EST) From: Nathan Scott Message-Id: <200401210557.i0L5vVIi730493@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907738 - build cleanup X-archive-position: 1827 X-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: 691 Lines: 26 Revisit symbol exports, move left-over debug/behavior exports outta the way of regular builds. Date: Tue Jan 20 21:55:14 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:165154a linux-2.6/xfs_ksyms.c - 1.1 linux-2.4/xfs_ksyms.c - 1.1 quota/xfs_qm_ksyms.c - 1.1 support/Makefile - 1.19 support/ktrace.c - 1.20 quota/Makefile - 1.7 quota/xfs_qm.c - 1.10 Makefile-linux-2.6 - 1.184 Makefile-linux-2.4 - 1.201 linux-2.6/xfs_globals.c - 1.57 linux-2.4/xfs_globals.c - 1.69 linux-2.4/Makefile - 1.201 linux-2.6/xfs_buf.c - 1.135 linux-2.4/xfs_buf.c - 1.154 From owner-linux-xfs@oss.sgi.com Thu Jan 22 10:32:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Jan 2004 10:32:56 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MIWfmK001936 for ; Thu, 22 Jan 2004 10:32:42 -0800 Received: from naboo.americas.sgi.com ([128.162.233.73]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0MIWXlC013379 for ; Thu, 22 Jan 2004 10:32:33 -0800 Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id 888B48C872C; Thu, 22 Jan 2004 12:32:13 -0600 (CST) Subject: PARTIAL TAKE 907752 - Put back some needed defs Message-Id: <20040122183213.888B48C872C@naboo.americas.sgi.com> Date: Thu, 22 Jan 2004 12:32:13 -0600 (CST) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:; X-archive-position: 1828 X-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: 299 Lines: 12 These are still needed by DEBUG... put them back for now Date: Thu Jan 22 10:31:31 PST 2004 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:165258a xfs_ag.h - 1.52 From owner-linux-xfs@oss.sgi.com Thu Jan 22 13:48:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Jan 2004 13:48: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 i0MLmJmK015986 for ; Thu, 22 Jan 2004 13:48:19 -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 i0MLmPdG029699 for ; Thu, 22 Jan 2004 13:48: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 i0MLmBhI872100 for ; Fri, 23 Jan 2004 08:48:11 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0MLmAfU872998 for linux-xfs@oss.sgi.com; Fri, 23 Jan 2004 08:48:10 +1100 (EST) Date: Fri, 23 Jan 2004 08:48:10 +1100 (EST) From: Nathan Scott Message-Id: <200401222148.i0MLmAfU872998@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix debug builds X-archive-position: 1831 X-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: 369 Lines: 15 Fix builds for various combinations of debug options. Date: Thu Jan 22 13:46:51 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:165272a xfs_macros.c - 1.53 xfs_ag.h - 1.53 linux-2.6/xfs_ksyms.c - 1.3 linux-2.4/xfs_ksyms.c - 1.2 From owner-linux-xfs@oss.sgi.com Fri Jan 23 00:32:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 00:32:08 -0800 (PST) Received: from lsinet.coltex.nl (host-2.coltex.demon.nl [212.238.252.66]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N8W37J011904 for ; Fri, 23 Jan 2004 00:32:04 -0800 Received: from auto-nb1.xs4all.nl (autom-seth.coltex.nl [10.0.2.53] (may be forged)) by lsinet.coltex.nl (8.12.3/8.12.8) with ESMTP id i0N8Vtte028271; Fri, 23 Jan 2004 09:31:56 +0100 Message-Id: <4.3.2.7.2.20040123083205.03df2668@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Jan 2004 09:31:53 +0100 To: alberto , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfs_force_shutdown(md(9,0),0x8) called from line 1070 of file xfs_trans.c. In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.27 (www . roaringpenguin . com / mimedefang) X-archive-position: 1859 X-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: 430 Lines: 19 At 19:38 22-1-2004 +0000, alberto wrote: >Hi all, > >we're having nasty problems an our new raid on a linux box: >When performing hevy i/o (in present case was scp -r), the disks >get disconnected with this kernel message: Can you give us some hardware info? xfs_info output of the mounted /raid Are you using NFS? What kernel version are you using? Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Fri Jan 23 04:15:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 04:15:44 -0800 (PST) Received: from daisy1.daisytechbg.com (daisy1.daisytechbg.com [212.5.131.209]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NCFR7J022928 for ; Fri, 23 Jan 2004 04:15:38 -0800 Received: from Daisy-Message_Server by daisy1.daisytechbg.com with Novell_GroupWise; Fri, 23 Jan 2004 14:15:18 +0200 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.7.1 Date: Fri, 23 Jan 2004 14:15:06 +0200 From: "Romeo Ninov" To: Subject: help build install CD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0NCFe7J022949 X-archive-position: 1863 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: RNinov@daisytechbg.com Precedence: bulk X-list: linux-xfs Content-Length: 204 Lines: 7 Anyone can help me to find scripts (or instructions) to make Install ISO for XFS for RH9? <><><><><><><><><><><><><><><><> Regards: Romeo Ninov <><><><><><><><><><><><><><><><> From owner-linux-xfs@oss.sgi.com Fri Jan 23 08:54:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 08:54: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 i0NGsb7J015138 for ; Fri, 23 Jan 2004 08:54:40 -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 i0NGsZNp012257 for ; Fri, 23 Jan 2004 17:54:35 +0100 Message-ID: <401152DE.6050707@stesmi.com> Date: Fri, 23 Jan 2004 17:59: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: linux-xfs@oss.sgi.com Subject: Does anyone even WANT a Fedora Core 1 that's XFS capable? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1868 X-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: 1286 Lines: 38 Hi people. I've been working alot on making an FC1 XFS installer and the question I have is : Does anyone want it ? I currently have one that seems to work ok-ish. The installer itself is actually a development anaconda installer that's been heavily patched to install FC1. What it doesn't do is : RAID (at least I don't think it does, haven't verified). LVM (Still a few things to take care of before that works). GRUB (same bug as before.. except now grub must be killed manually during installation and then reinstalled manually). Is this of interest to anyone or should I put it up first when I have at least RAID and LVM working or maybe even not at all? It's no use uploading something to my mirror (a process that takes something like 12 hours) if nobody wants it. So come on, please tell me and if so it should be uploaded sometime tomorrow ( my mirror starts grabbing from me 0400 CET / 2200 EST / 0300 BST ). The installer currently uses some things from Axel Thimm (kernel and some userspace) and will use even more from him, so it's not only FC1+XFS there are some other things changed, with apt and synaptics added being some. Alright, enough blabbering - tell me what you want and if I don't hear a peep I'm not making my mirror take it next update. // Stefan From owner-linux-xfs@oss.sgi.com Fri Jan 23 08:58:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 08:58:33 -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 i0NGwL7J015538 for ; Fri, 23 Jan 2004 08:58:21 -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 i0NGwKNp012400; Fri, 23 Jan 2004 17:58:20 +0100 Message-ID: <401153BF.8080409@stesmi.com> Date: Fri, 23 Jan 2004 18:02:55 +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: Stefan Smietanowski CC: linux-xfs@oss.sgi.com Subject: Re: Does anyone even WANT a Fedora Core 1 that's XFS capable? References: <401152DE.6050707@stesmi.com> In-Reply-To: <401152DE.6050707@stesmi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1869 X-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: 1452 Lines: 45 Stefan Smietanowski wrote: > Hi people. > > I've been working alot on making an FC1 XFS installer and > the question I have is : Does anyone want it ? > > I currently have one that seems to work ok-ish. > > The installer itself is actually a development anaconda > installer that's been heavily patched to install FC1. > > What it doesn't do is : > > RAID (at least I don't think it does, haven't verified). > LVM (Still a few things to take care of before that works). > GRUB (same bug as before.. except now grub must be killed > manually during installation and then reinstalled manually). > > Is this of interest to anyone or should I put it up first > when I have at least RAID and LVM working or maybe even > not at all? > > It's no use uploading something to my mirror (a process > that takes something like 12 hours) if nobody wants it. > > So come on, please tell me and if so it should be uploaded > sometime tomorrow ( my mirror starts grabbing from me 0400 CET / > 2200 EST / 0300 BST ). > > The installer currently uses some things from Axel Thimm > (kernel and some userspace) and will use even more from him, > so it's not only FC1+XFS there are some other things changed, > with apt and synaptics added being some. > > Alright, enough blabbering - tell me what you want and if I don't > hear a peep I'm not making my mirror take it next update. > > // Stefan > Btw, it's the _DVD_ I'm talking about, not a CD. // Stefan From owner-linux-xfs@oss.sgi.com Fri Jan 23 09:16:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 09:16:56 -0800 (PST) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NHGf7J016376 for ; Fri, 23 Jan 2004 09:16:44 -0800 Received: from wingnut.mpc.local ([172.16.200.29]) by moving-picture.com with smtp (Exim 4.24) id 1Ak4v5-0005t0-Gf for linux-xfs@oss.sgi.com; Fri, 23 Jan 2004 17:16:35 +0000 Date: Fri, 23 Jan 2004 17:16:35 +0000 From: Huw Lynes Cc: linux-xfs@oss.sgi.com Subject: Re: Does anyone even WANT a Fedora Core 1 that's XFS capable? Message-Id: <20040123171635.632bc8a5.huw-l@moving-picture.com> In-Reply-To: <401153BF.8080409@stesmi.com> References: <401152DE.6050707@stesmi.com> <401153BF.8080409@stesmi.com> Organization: The Moving Picture Company X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 1870 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: huw-l@moving-picture.com Precedence: bulk X-list: linux-xfs Content-Length: 586 Lines: 22 On Fri, 23 Jan 2004 18:02:55 +0100 Stefan Smietanowski wrote: > Stefan Smietanowski wrote: > > > Hi people. > > > > I've been working alot on making an FC1 XFS installer and > > the question I have is : Does anyone want it ? > > > Btw, it's the _DVD_ I'm talking about, not a CD. > Are the SRPMs available anywhere? I'd be interested in taking a look at the bits you've hacked. -- | Huw Lynes | The Moving Picture Company | | System Administrator | 127 Wardour Street | |.........................| London, W1F 0NL | From owner-linux-xfs@oss.sgi.com Fri Jan 23 09:19:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 09:19:54 -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 i0NHJf7J016789 for ; Fri, 23 Jan 2004 09:19:42 -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 i0NHJdNp013377; Fri, 23 Jan 2004 18:19:39 +0100 Message-ID: <401158BF.3080706@stesmi.com> Date: Fri, 23 Jan 2004 18:24:15 +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: Huw Lynes CC: linux-xfs@oss.sgi.com Subject: Re: Does anyone even WANT a Fedora Core 1 that's XFS capable? References: <401152DE.6050707@stesmi.com> <401153BF.8080409@stesmi.com> <20040123171635.632bc8a5.huw-l@moving-picture.com> In-Reply-To: <20040123171635.632bc8a5.huw-l@moving-picture.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1871 X-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: 608 Lines: 30 Huw Lynes wrote: > On Fri, 23 Jan 2004 18:02:55 +0100 > Stefan Smietanowski wrote: > > >>Stefan Smietanowski wrote: >> >> >>>Hi people. >>> >>>I've been working alot on making an FC1 XFS installer and >>>the question I have is : Does anyone want it ? >>> >> >>Btw, it's the _DVD_ I'm talking about, not a CD. >> > > > Are the SRPMs available anywhere? I'd be interested in taking a look at the > bits you've hacked. > No, but I can make them available. Look for them tomorrow on my mirror ftp://ftp.uninett.no/pub/linux/RH-XFS-DVD Well, somewhere around there anyway. // Stefan From owner-linux-xfs@oss.sgi.com Fri Jan 23 09:26:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 09:26:21 -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 i0NHQ17J017277 for ; Fri, 23 Jan 2004 09:26:02 -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 i0NHPxNp013634; Fri, 23 Jan 2004 18:25:59 +0100 Message-ID: <40115A3A.9070504@stesmi.com> Date: Fri, 23 Jan 2004 18:30:34 +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: Murthy Kambhampaty CC: linux-xfs@oss.sgi.com Subject: Re: Does anyone even WANT a Fedora Core 1 that's XFS capable? References: <2D92FEBFD3BE1346A6C397223A8DD3FC092560@THOR.goeci.com> In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC092560@THOR.goeci.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1872 X-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: 791 Lines: 25 Murthy Kambhampaty wrote: > Let's just see whether the FC2 beta installer supports XFS, and take if from > there? > > BTW all of my linux systems have 4 primary partitions on the system disk > with: [hs]da1 for boot, [hs]da2 for root, [hs]da3 for swap, [hs]da4 for > VGsys, with /var, /tmp, /usr and /home on corresponding LVs in VGsys. For > users like me, no LVM means no go. > It should support xfs via "linux xfs". I used an older version of the FC2 installer as a base for my work and it supports it. I seem to have spoken too soon about the RAID support : I currently have a system installing and it's using a mix of RAID0, RAID1 and RAID5 (yes, for testing .. and on one disk only :)). If this indeed works then I'm sitting down and continuing on the LVM support. // Stefan From owner-linux-xfs@oss.sgi.com Fri Jan 23 12:01:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 12:01:55 -0800 (PST) Received: from mail4-red-R.bigfish.com (mail-red.bigfish.com [216.148.222.61]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NK1a7J022295 for ; Fri, 23 Jan 2004 12:01:39 -0800 Received: from mail4-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail4-red-R.bigfish.com (Postfix) with ESMTP id 1705E17B479 for ; Fri, 23 Jan 2004 20:01:29 +0000 (UCT) Received: by mail4-red (MessageSwitch) id 1074888088984995_1435; Fri, 23 Jan 2004 20:01:28 +0000 (UCT) Received: from mx1.spimageworks.com (unknown [160.33.20.27]) by mail4-red.bigfish.com (Postfix) with ESMTP id C870017B1B5 for ; Fri, 23 Jan 2004 20:01:28 +0000 (UCT) Received: from zoot.spimageworks.com (zoot.spimageworks.com [172.18.5.16]) by mx1.spimageworks.com (8.11.6/8.11.6) with ESMTP id i0NK1Sm16748 for ; Fri, 23 Jan 2004 12:01:28 -0800 Subject: XFS internal error / xfs_force_shutdown From: Dan Lake To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-GbYnO8yNucPG3vyLsb4+" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 23 Jan 2004 12:01:28 -0800 Message-Id: <1074888088.16610.1013.camel@zoot.spimageworks.com> Mime-Version: 1.0 X-BigFish: v X-archive-position: 1873 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: danl@imageworks.com Precedence: bulk X-list: linux-xfs Content-Length: 18924 Lines: 339 --=-GbYnO8yNucPG3vyLsb4+ Content-Type: text/plain Content-Transfer-Encoding: 7bit I have been using XFS with some success on Linux NFS fileservers. In the past month, one server has been subjected to an extremely heavy load - lots of IO, many files created/read/deleted, full filesystem. With the increase in load, the system has crashed or hung numerous times. I've included system configuration information and XFS relevant traces from /var/log/messages below. I'd like to stabilize this system. Any suggestions? =Dan Lake Imageworks -- pi equals 3 -- for small values of pi and large values of 3 --=-GbYnO8yNucPG3vyLsb4+ Content-Disposition: attachment; filename=xfs-errors Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name="xfs-errors; charset=ISO-8859-1" Hardware is: 2P Xeon 2.8GHz 2GB memory JBOD with 13 disks 3 md volumes: md0: 7 disks RAID0 md1: 4 disks RAID5 md2: 2 disks RAID0 Adaptec AIC-7899 U160 SCSI controller Broadcom BCM-5701 gigabit network interface XFS setup: $ xfs_info /dev/md0 meta-data=3D/mnt/vol102 isize=3D256 agcount=3D60, agsize=3D10= 48576 blks =3D sectsz=3D512 data =3D bsize=3D4096 blocks=3D62229552, imaxpc= t=3D25 =3D sunit=3D8 swidth=3D56 blks, unwritt= en=3D1 naming =3Dversion 2 bsize=3D4096 log =3Dinternal bsize=3D4096 blocks=3D30392, version= =3D1 =3D sectsz=3D512 sunit=3D0 blks realtime =3Dnone extsz=3D229376 blocks=3D0, rtextents=3D0 $ xfs_info /dev/md1 meta-data=3D/mnt/vol101 isize=3D256 agcount=3D103, agsize=3D1= 048576 blks =3D sectsz=3D512 data =3D bsize=3D4096 blocks=3D107528976, imaxp= ct=3D25 =3D sunit=3D8 swidth=3D24 blks, unwritt= en=3D1 naming =3Dversion 2 bsize=3D4096 log =3Dinternal bsize=3D4096 blocks=3D32768, version= =3D1 =3D sectsz=3D512 sunit=3D0 blks realtime =3Dnone extsz=3D98304 blocks=3D0, rtextents=3D0 $ xfs_info /dev/md2 meta-data=3D/mnt/vol55 isize=3D256 agcount=3D17, agsize=3D10= 48568 blks =3D sectsz=3D512 data =3D bsize=3D4096 blocks=3D17779872, imaxpc= t=3D25 =3D sunit=3D8 swidth=3D16 blks, unwritt= en=3D1 naming =3Dversion 2 bsize=3D4096 log =3Dinternal bsize=3D4096 blocks=3D8688, version=3D1 =3D sectsz=3D512 sunit=3D0 blks realtime =3Dnone extsz=3D65536 blocks=3D0, rtextents=3D0 /var/log/messages snippets: Linux 2.4.22 SMP + xfs-2.4.22 patches=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dec 24 12:44:49 foobar kernel: xfs_inotobp: xfs_imap() returned an error 2= 2 on md(9,1). Returning error. Dec 24 12:44:49 foobar kernel: xfs_iunlink_remove: xfs_inotobp() returned = an error 22 on md(9,1). Returning error. Dec 24 12:44:49 foobar kernel: xfs_inactive:^Ixfs_ifree() returned an error= =3D 22 on md(9,1) Dec 24 12:44:49 foobar kernel: xfs_force_shutdown(md(9,1),0x1) called from = line 1873 of file xfs_vnodeops.c. Return address =3D 0xf89f5ee6 Dec 24 12:44:49 foobar kernel: Filesystem "md(9,1)": I/O Error Detected. S= hutting down filesystem: md(9,1) Dec 24 12:44:49 foobar kernel: Please umount the filesystem, and rectify th= e problem(s) Jan 6 16:00:05 foobar kernel: Filesystem "md(9,0)": xfs_log_write: reserva= tion ran out. Need to up reservation Jan 6 16:00:05 foobar kernel: xfs_force_shutdown(md(9,0),0x8) called from = line 1715 of file xfs_log.c. Return address =3D 0xf89f5ee6 Jan 6 16:00:05 foobar kernel: Filesystem "md(9,0)": Corruption of in-memor= y data detected. Shutting down filesystem: md(9,0) Jan 6 16:00:05 foobar kernel: Please umount the filesystem, and rectify th= e problem(s) Jan 6 16:00:05 foobar kernel: xfs_force_shutdown(md(9,0),0x2) called from = line 1297 of file xfs_log.c. Return address =3D 0xf89f5ee6 Jan 9 09:40:27 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89ca7d1 Jan 9 09:40:27 foobar kernel: d4b55b8c f89c47b9 f8a11f75 00000001 00000000= f8a11f68 00000362 f89ca7d1 Jan 9 09:40:27 foobar kernel: 0803ae90 00000000 00000001 00000000 0= 0001000 00000001 00000018 00000000 Jan 9 09:40:27 foobar kernel: 00000005 000000f0 0000002f 00000008 0= 003ae90 0000a205 00000000 00000000 Jan 9 09:40:27 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] [] Jan 9 09:40:27 foobar kernel: nfsd: non-standard errno: -990 Jan 9 11:57:24 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89ca7d1 Jan 9 11:57:24 foobar kernel: d4af7b8c f89c47b9 f8a11f75 00000001 00000000= f8a11f68 00000362 f89ca7d1 Jan 9 11:57:24 foobar kernel: 0803ae90 00000000 00000001 00000000 d= 1466000 00000000 00000018 c0259824 Jan 9 11:57:24 foobar kernel: f6c11de0 c4d12580 0000002f 00000008 0= 003ae90 00000000 d1466000 00000000 Jan 9 11:57:24 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] [] [] Jan 9 11:57:24 foobar kernel: nfsd: non-standard errno: -990 Jan 9 14:11:25 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN= at line 295 of file xfs_alloc.c. Caller 0xf899559d Jan 9 14:11:25 foobar kernel: c44ada00 f89947bd f8a11a09 00000001 00000000= f8a119fd 00000127 f899559d Jan 9 14:11:25 foobar kernel: 00000000 00000000 00000000 0000000c c= a23789c ca237920 00091e18 f899559d Jan 9 14:11:25 foobar kernel: ca23789c ca237920 00091e18 00000010 0= 0091e1c 0000000c 00000001 0009203c Jan 9 14:11:25 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] [] [] [] [<= f89eddbb>] [] [] [] [] [] []=20 Jan 12 08:08:08 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89ca7d1 Jan 12 08:08:08 foobar kernel: d4b91b8c f89c47b9 f8a11f75 00000001 00000000= f8a11f68 00000362 f89ca7d1 Jan 12 08:08:08 foobar kernel: 21000c16 00000000 00000001 00000000 c= 025e407 43011dac 00000018 00000000 Jan 12 08:08:08 foobar kernel: 00000018 00000006 00000056 00000021 0= 0000c16 d5122c20 00000296 00000000 Jan 12 08:08:08 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] [] [] Jan 12 08:08:08 foobar kernel: nfsd: non-standard errno: -990 Added ikeep mount option. Linux 2.4.24 SMP + xfs-2.4.23 patches =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan 20 08:50:54 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89cb7d1 Jan 20 08:50:54 foobar kernel: f5497b8c f89c57b9 f8a11e55 00000001 00000000= f8a11e48 00000362 f89cb7d1 Jan 20 08:50:54 foobar kernel: 4d164a94 00000000 00000001 00000000 0= 0000000 00000001 00000018 ffffffff Jan 20 08:50:54 foobar kernel: 00000000 00000000 00000047 0000004d 0= 0164a94 c2908400 039d3000 00000000 Jan 20 08:50:54 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [] [] Jan 20 08:50:54 foobar kernel: nfsd: non-standard errno: -990 Jan 20 09:21:26 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89cb7d1 Jan 20 09:21:26 foobar kernel: f549db8c f89c57b9 f8a11e55 00000001 00000000= f8a11e48 00000362 f89cb7d1 Jan 20 09:21:26 foobar kernel: 4b0035b5 00000000 00000001 00000000 0= 0000000 f5a29400 00000018 00000000 Jan 20 09:21:26 foobar kernel: 00000000 00000001 00000056 0000004b 0= 00035b5 000001c4 f89c9ad3 00000000 Jan 20 09:21:26 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] Jan 20 09:21:26 foobar kernel: nfsd: non-standard errno: -990 Jan 20 16:23:34 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 1634 of file xfs_alloc.c. Caller 0xf8997fe2 Jan 20 16:23:34 foobar kernel: e67e5d28 f8997289 f8a11903 00000001 00000000= f8a118dd 00000662 f8997fe2 Jan 20 16:23:34 foobar kernel: f55fb800 e6cf2a6c e6cf285c 00091e88 0= 00000ab 00000001 00091e18 00000010 Jan 20 16:23:34 foobar kernel: 00000000 00000001 f35c2da0 e6cf8c04 e= 6cf8c04 e6cf5f0c f8997fe2 e6cf8c04 Jan 20 16:23:34 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] Jan 20 16:23:34 foobar kernel: xfs_force_shutdown(md(9,0),0x8) called from = line 4046 of file xfs_bmap.c. Return address =3D 0xf89f6fc6 Jan 20 16:23:34 foobar kernel: Filesystem "md(9,0)": Corruption of in-memor= y data detected. Shutting down filesystem: md(9,0) Jan 20 16:23:34 foobar kernel: Please umount the filesystem, and rectify th= e problem(s) Jan 20 21:05:01 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89cb7d1 Jan 20 21:05:01 foobar kernel: f5d93b8c f89c57b9 f8a11e55 00000001 00000000= f8a11e48 00000362 f89cb7d1 Jan 20 21:05:01 foobar kernel: 4b0035b5 00000000 00000001 00000000 c= 0251659 f76af0c0 00000018 c033f450 Jan 20 21:05:01 foobar kernel: 00000020 00000042 0000003f 0000004b 0= 00035b5 f76af0c0 c607b2d4 00000000 Jan 20 21:05:01 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] Jan 20 21:05:01 foobar kernel: nfsd: non-standard errno: -990 Jan 20 21:16:06 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89cb7d1 Jan 20 21:16:06 foobar kernel: f5d3fb8c f89c57b9 f8a11e55 00000001 00000000= f8a11e48 00000362 f89cb7d1 Jan 20 21:16:06 foobar kernel: 48be1c1e 00000000 00000001 00000000 0= 0001000 00000001 00000018 00000000 Jan 20 21:16:06 foobar kernel: 00000005 000000f0 00000047 00000048 0= 0be1c1e 0000a205 00000000 00000000 Jan 20 21:16:06 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] [] Jan 20 21:16:06 foobar kernel: nfsd: non-standard errno: -990 Jan 20 21:42:26 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89cb7d1 Jan 20 21:42:26 foobar kernel: f5d8fb8c f89c57b9 f8a11e55 00000001 00000000= f8a11e48 00000362 f89cb7d1 Jan 20 21:42:26 foobar kernel: 48be1c1e 00000000 00000001 00000000 0= 0000000 f5fab000 00000018 00000000 Jan 20 21:42:26 foobar kernel: 00000000 00000001 00000056 00000048 0= 0be1c1e 000001c4 f89df7f2 00000000 Jan 20 21:42:26 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] Jan 20 21:42:26 foobar kernel: nfsd: non-standard errno: -990 Jan 21 01:04:41 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89cb7d1 Jan 21 01:04:41 foobar kernel: f5d59b8c f89c57b9 f8a11e55 00000001 00000000= f8a11e48 00000362 f89cb7d1 Jan 21 01:04:41 foobar kernel: 4b0035b5 00000000 00000001 00000000 0= 0000000 f5fab000 00000018 00000000 Jan 21 01:04:41 foobar kernel: 00000000 e02b24ec 0000003f 0000004b 0= 00035b5 c02633f4 ca0458a0 00000000 Jan 21 01:04:41 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] [] Jan 21 01:04:41 foobar kernel: nfsd: non-standard errno: -990 Jan 21 01:08:02 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89cb7d1 Jan 21 01:08:02 foobar kernel: f5d55b8c f89c57b9 f8a11e55 00000001 00000000= f8a11e48 00000362 f89cb7d1 Jan 21 01:08:02 foobar kernel: 4cd07e81 00000000 00000001 00000000 0= 0000000 f5fab000 00000018 00000000 Jan 21 01:08:02 foobar kernel: 00000000 00000001 00000047 0000004c 0= 0d07e81 000001c4 f89c9ad3 00000000 Jan 21 01:08:02 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] Jan 21 01:08:02 foobar kernel: nfsd: non-standard errno: -990 Jan 21 01:23:46 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89cb7d1 Jan 21 01:23:46 foobar kernel: f5877b8c f89c57b9 f8a11e55 00000001 00000000= f8a11e48 00000362 f89cb7d1 Jan 21 01:23:46 foobar kernel: 4cd07e81 00000000 00000001 00000000 0= 0001000 00000001 00000018 00000000 Jan 21 01:23:46 foobar kernel: 00000005 000000f0 00000056 0000004c 0= 0d07e81 0000a205 00000000 00000000 Jan 21 01:23:46 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] [] Jan 21 01:23:46 foobar kernel: nfsd: non-standard errno: -990 Jan 21 06:23:18 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89ca7d1 Jan 21 06:23:18 foobar kernel: f603bb8c f89c47b9 f8a11f75 00000001 00000000= f8a11f68 00000362 f89ca7d1 Jan 21 06:23:18 foobar kernel: 4cd07e81 00000000 00000001 00000000 f= 5c938c0 f7fcba40 00000018 f7fcba40 Jan 21 06:23:18 foobar kernel: c0264300 f603bca8 0000003f 0000004c 0= 0d07e81 00000040 f5c938c0 00000000 Jan 21 06:23:18 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] [] Jan 21 06:23:18 foobar kernel: nfsd: non-standard errno: -990 Jan 21 06:33:41 foobar kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO a= t line 866 of file xfs_ialloc.c. Caller 0xf89ca7d1 Jan 21 06:33:41 foobar kernel: f6015b8c f89c47b9 f8a11f75 00000001 00000000= f8a11f68 00000362 f89ca7d1 Jan 21 06:33:41 foobar kernel: 4cd07e81 00000000 00000001 00000000 c= 2dcd800 c2dcd800 00000018 c2dcd800 Jan 21 06:33:41 foobar kernel: c0264300 f6015ca8 00000047 0000004c 0= 0d07e81 c47ab308 e9207acc 00000000 Jan 21 06:33:41 foobar kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [= ] [] [] [] Jan 21 06:33:41 foobar kernel: nfsd: non-standard errno: -990 --=-GbYnO8yNucPG3vyLsb4+-- From owner-linux-xfs@oss.sgi.com Fri Jan 23 13:28:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 13:28:58 -0800 (PST) Received: from wingerboy.noc.sonic.net (wingerboy.noc.sonic.net [64.142.18.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NLSj7J027826 for ; Fri, 23 Jan 2004 13:28:46 -0800 Received: from wingerboy.noc.sonic.net (localhost [127.0.0.1]) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9) with ESMTP id i0NLSjK8058055 for ; Fri, 23 Jan 2004 13:28:45 -0800 (PST) (envelope-from kgc@wingerboy.noc.sonic.net) Received: (from kgc@localhost) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9/Submit) id i0NLSjrc058054 for linux-xfs@oss.sgi.com; Fri, 23 Jan 2004 13:28:45 -0800 (PST) Date: Fri, 23 Jan 2004 13:28:45 -0800 From: Kelsey Cummings To: linux-xfs@oss.sgi.com Subject: log questions Message-ID: <20040123212845.GK32531@sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-PGP-Key: http://sonic.net/~kgc/gpgkey.txt X-archive-position: 1874 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kgc@sonic.net Precedence: bulk X-list: linux-xfs Content-Length: 499 Lines: 13 Is is possible to relocate a log to an external device on a prexisting XFS filesystem? I've poked around in the man pages but haven't found any way to do this that's abundantly clear. -- Kelsey Cummings - kgc@sonic.net sonic.net, inc. System Administrator 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax) http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 From owner-linux-xfs@oss.sgi.com Fri Jan 23 13:40:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 13:41: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 i0NLeq7J028375 for ; Fri, 23 Jan 2004 13:40:52 -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 i0NLPjZX006547 for ; Fri, 23 Jan 2004 13:25:45 -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 i0NLPSNX31367601; Fri, 23 Jan 2004 15:25: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 i0NLPOoZ4028048; Fri, 23 Jan 2004 15:25:27 -0600 (CST) Subject: Re: XFS internal error / xfs_force_shutdown From: Russell Cattelan To: Dan Lake Cc: linux-xfs@oss.sgi.com In-Reply-To: <1074888088.16610.1013.camel@zoot.spimageworks.com> References: <1074888088.16610.1013.camel@zoot.spimageworks.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-wvdOTqkGEhYARX0WNLke" Message-Id: <1074893124.13255.238.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-2mdk Date: Fri, 23 Jan 2004 15:25:24 -0600 X-archive-position: 1875 X-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: 1116 Lines: 38 --=-wvdOTqkGEhYARX0WNLke Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-01-23 at 14:01, Dan Lake wrote: > I have been using XFS with some success on Linux NFS fileservers. In > the past month, one server has been subjected to an > extremely heavy load - lots of IO, many files created/read/deleted, full > filesystem. With the increase in load, the system has crashed or hung > numerous times. I've included system configuration information and XFS > relevant traces from /var/log/messages below. >=20 > I'd like to stabilize this system. Any suggestions? >=20 > =3DDan Lake > Imageworks Can you run xfs_repair -n on the device and send us the output. It appears you have hit the now infamous corruption. --=-wvdOTqkGEhYARX0WNLke 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) iD8DBQBAEZFENRmM+OaGhBgRAir+AJ48GlEkg/Ewi7rrO8ZK7WDfQqknqgCfcFSd 7nsBbvIpi3Hmfc0QMplyzvg= =2qZF -----END PGP SIGNATURE----- --=-wvdOTqkGEhYARX0WNLke-- From owner-linux-xfs@oss.sgi.com Fri Jan 23 13:59:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 14:00:03 -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 i0NLxo7J029701 for ; Fri, 23 Jan 2004 13:59:51 -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 i0NLwr411813; Fri, 23 Jan 2004 16:58:54 -0500 Subject: Re: List configuration From: Darrell Michaud To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1074295715.1535.12.camel@stout.americas.sgi.com> References: <4007500D.1060806@linuxmail.org> <40086E9F.90602@myphorum.com> <1074295715.1535.12.camel@stout.americas.sgi.com> Content-Type: text/plain Organization: Message-Id: <1074895133.9579.28.camel@atherne> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 23 Jan 2004 16:58:53 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1876 X-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 Content-Length: 1269 Lines: 36 It wasn't just yesterday. Not to revive a dead horse but I received over 30 spam mails from the XFS list in the last 24 hours. Something needs to be done if this list is going to remain useful to a wide audience. Before someone flames me to be unsubscribe if I don't like it, I am a step ahead of you. Take care. On Fri, 2004-01-16 at 18:28, Eric Sandeen wrote: > On Fri, 2004-01-16 at 17:16, Arthur Corliss wrote: > > > > You are free to unsubscribe. > > > > Yes, I am. But until someone from SGI tells me that they refuse to fix the > > list config, I'm going to stay and hope it gets fixed. I want to get the > > legitimate e-mails, I just don't want the spam. And I really don't think I'm > > being unreasonable for expecting that much. > > We do not plan to change our previous conscious decision to keep the > list open. It's not broken, it's intentional. I'm sorry you don't like > it. It's not your choice. staying subscribed, or not, is your choice. > > spamd died for a while, some spam got through, deal with it. If you > can't deal with it, please -do- unsubscribe. This thread has had higher > volume, and not much more useful content, then the small bit of spam > that leaked through. > > -Eric -- Darrell Michaud From owner-linux-xfs@oss.sgi.com Fri Jan 23 14:12:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 14:13:02 -0800 (PST) Received: from mail27-red-R.bigfish.com (mail-red.bigfish.com [216.148.222.61]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NMCf7J030736 for ; Fri, 23 Jan 2004 14:12:41 -0800 Received: from mail27-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail27-red-R.bigfish.com (Postfix) with ESMTP id 70A142AA1A7; Fri, 23 Jan 2004 21:39:31 +0000 (UCT) Received: by mail27-red (MessageSwitch) id 1074893971438764_2939; Fri, 23 Jan 2004 21:39:31 +0000 (UCT) Received: from mx1.spimageworks.com (unknown [160.33.20.27]) by mail27-red.bigfish.com (Postfix) with ESMTP id 500882AA1A7; Fri, 23 Jan 2004 21:39:31 +0000 (UCT) Received: from zoot.spimageworks.com (zoot.spimageworks.com [172.18.5.16]) by mx1.spimageworks.com (8.11.6/8.11.6) with ESMTP id i0NLdVm21024; Fri, 23 Jan 2004 13:39:31 -0800 Subject: Re: XFS internal error / xfs_force_shutdown From: Dan Lake To: Russell Cattelan Cc: Dan Lake , linux-xfs@oss.sgi.com In-Reply-To: <1074893124.13255.238.camel@naboo.americas.sgi.com> References: <1074893124.13255.238.camel@naboo.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 23 Jan 2004 13:39:31 -0800 Message-Id: <1074893971.7373.1026.camel@zoot.spimageworks.com> Mime-Version: 1.0 X-BigFish: v X-archive-position: 1877 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: danl@imageworks.com Precedence: bulk X-list: linux-xfs Content-Length: 1131 Lines: 34 On Fri, 2004-01-23 at 13:25, Russell Cattelan wrote: > On Fri, 2004-01-23 at 14:01, Dan Lake wrote: > > I have been using XFS with some success on Linux NFS fileservers. In > > the past month, one server has been subjected to an > > extremely heavy load - lots of IO, many files created/read/deleted, > full > > filesystem. With the increase in load, the system has crashed or hung > > numerous times. I've included system configuration information and > XFS > > relevant traces from /var/log/messages below. > > > > I'd like to stabilize this system. Any suggestions? > > > > =Dan Lake > > Imageworks > Can you run xfs_repair -n on the device and send us the output. After the last crash, I decided to run xfs_repair on all the XFS filesystems. There was indeed corruption - about 20 files ended up in lost+found which I subsequently removed. Do you want me to re-run xfs_repair with -n? > It appears you have hit the now infamous corruption. I'm able to upgrade the kernel easily enough. Are there any fixes available to address this? Thanks, =danl -- pi equals 3 -- for small values of pi and large values of 3 From owner-linux-xfs@oss.sgi.com Fri Jan 23 14:13:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 14:13:34 -0800 (PST) Received: from wingerboy.noc.sonic.net (wingerboy.noc.sonic.net [64.142.18.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NMDN7J030780 for ; Fri, 23 Jan 2004 14:13:23 -0800 Received: from wingerboy.noc.sonic.net (localhost [127.0.0.1]) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9) with ESMTP id i0NMDNK8064009 for ; Fri, 23 Jan 2004 14:13:23 -0800 (PST) (envelope-from kgc@wingerboy.noc.sonic.net) Received: (from kgc@localhost) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9/Submit) id i0NMDNIt064008 for linux-xfs@oss.sgi.com; Fri, 23 Jan 2004 14:13:23 -0800 (PST) Date: Fri, 23 Jan 2004 14:13:23 -0800 From: Kelsey Cummings To: linux-xfs@oss.sgi.com Subject: Re: [LNX-XFS] Re: List configuration Message-ID: <20040123221323.GL32531@sonic.net> References: <4007500D.1060806@linuxmail.org> <40086E9F.90602@myphorum.com> <1074295715.1535.12.camel@stout.americas.sgi.com> <1074895133.9579.28.camel@atherne> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1074895133.9579.28.camel@atherne> User-Agent: Mutt/1.4.1i X-PGP-Key: http://sonic.net/~kgc/gpgkey.txt X-archive-position: 1878 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kgc@sonic.net Precedence: bulk X-list: linux-xfs Content-Length: 836 Lines: 19 On Fri, Jan 23, 2004 at 04:58:53PM -0500, Darrell Michaud wrote: > It wasn't just yesterday. Not to revive a dead horse but I received over > 30 spam mails from the XFS list in the last 24 hours. > > Something needs to be done if this list is going to remain useful to a > wide audience. Well, my SpamAssassin install caught ever one of the spams so it really doesn't bother me - but on that note, it's pretty straight forward to integrate SpamAssassin or other antispam filters into most MTAs and or list software... -- Kelsey Cummings - kgc@sonic.net sonic.net, inc. System Administrator 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax) http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 From owner-linux-xfs@oss.sgi.com Fri Jan 23 14:38:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 14:38:21 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NMc97J032017 for ; Fri, 23 Jan 2004 14:38:09 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0NMc3JL015986 for ; Fri, 23 Jan 2004 14:38:04 -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 i0NMc3NX31456071; Fri, 23 Jan 2004 16:38:03 -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 i0NMc3oZ4256677; Fri, 23 Jan 2004 16:38:03 -0600 (CST) Subject: Re: List configuration From: Russell Cattelan To: Darrell Michaud Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1074895133.9579.28.camel@atherne> References: <4007500D.1060806@linuxmail.org> <40086E9F.90602@myphorum.com> <1074295715.1535.12.camel@stout.americas.sgi.com> <1074895133.9579.28.camel@atherne> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-F7eXokCQHg9s6KwYVlfd" Message-Id: <1074897483.13255.245.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-2mdk Date: Fri, 23 Jan 2004 16:38:03 -0600 X-archive-position: 1879 X-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: 1945 Lines: 61 --=-F7eXokCQHg9s6KwYVlfd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Yes sorry folks. again! sigh. oss got rebooted yesterday and spamd didn't restart when the system came up. On Fri, 2004-01-23 at 15:58, Darrell Michaud wrote: > It wasn't just yesterday. Not to revive a dead horse but I received over > 30 spam mails from the XFS list in the last 24 hours. >=20 > Something needs to be done if this list is going to remain useful to a > wide audience. >=20 > Before someone flames me to be unsubscribe if I don't like it, I am a > step ahead of you. >=20 > Take care. >=20 >=20 >=20 > On Fri, 2004-01-16 at 18:28, Eric Sandeen wrote: > > On Fri, 2004-01-16 at 17:16, Arthur Corliss wrote: > >=20 > > > > You are free to unsubscribe. > > >=20 > > > Yes, I am. But until someone from SGI tells me that they refuse to f= ix the > > > list config, I'm going to stay and hope it gets fixed. I want to get= the > > > legitimate e-mails, I just don't want the spam. And I really don't t= hink I'm > > > being unreasonable for expecting that much. > >=20 > > We do not plan to change our previous conscious decision to keep the > > list open. It's not broken, it's intentional. I'm sorry you don't like > > it. It's not your choice. staying subscribed, or not, is your choice. > >=20 > > spamd died for a while, some spam got through, deal with it. If you > > can't deal with it, please -do- unsubscribe. This thread has had higher > > volume, and not much more useful content, then the small bit of spam > > that leaked through. > >=20 > > -Eric --=-F7eXokCQHg9s6KwYVlfd 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) iD8DBQBAEaJLNRmM+OaGhBgRAkORAJ9sPcreTH2tkjd4H1MgIoAf6GpriACfXNm0 OyZrFkTQ6TAiL2yEPJ+LRP8= =uE1m -----END PGP SIGNATURE----- --=-F7eXokCQHg9s6KwYVlfd-- From owner-linux-xfs@oss.sgi.com Fri Jan 23 16:40:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 16:40:51 -0800 (PST) Received: from wingerboy.noc.sonic.net (wingerboy.noc.sonic.net [64.142.18.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0O0ee7J020610 for ; Fri, 23 Jan 2004 16:40:40 -0800 Received: from wingerboy.noc.sonic.net (localhost [127.0.0.1]) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9) with ESMTP id i0O0eUK8094793 for ; Fri, 23 Jan 2004 16:40:30 -0800 (PST) (envelope-from kgc@wingerboy.noc.sonic.net) Received: (from kgc@localhost) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9/Submit) id i0O0eULS094792 for linux-xfs@oss.sgi.com; Fri, 23 Jan 2004 16:40:30 -0800 (PST) Date: Fri, 23 Jan 2004 16:40:30 -0800 From: Kelsey Cummings To: linux-xfs@oss.sgi.com Subject: Re: [LNX-XFS] log questions Message-ID: <20040124004030.GS32531@sonic.net> References: <20040123212845.GK32531@sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040123212845.GK32531@sonic.net> User-Agent: Mutt/1.4.1i X-PGP-Key: http://sonic.net/~kgc/gpgkey.txt X-archive-position: 1880 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kgc@sonic.net Precedence: bulk X-list: linux-xfs Content-Length: 1028 Lines: 23 On Fri, Jan 23, 2004 at 01:28:45PM -0800, Kelsey Cummings wrote: > Is is possible to relocate a log to an external device on a prexisting XFS > filesystem? > > I've poked around in the man pages but haven't found any way to do this > that's abundantly clear. Another, closely related question: Is is possible to recreate a log on an external device that has been lost? I'm benchmarking the use of a SSD for the logdevice (results are a bit suprising) and one concern that I have is if the SSD fails, can I create a new log easily for it? I can always make a image of the logdevice with dd, and keep it around as a backup, but that seems a bit strange and I'm not sure that the it would work correctly anyway. -- Kelsey Cummings - kgc@sonic.net sonic.net, inc. System Administrator 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax) http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 From owner-linux-xfs@oss.sgi.com Fri Jan 23 16:51:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 16:51:57 -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 i0O0pi7J021448 for ; Fri, 23 Jan 2004 16:51:44 -0800 Received: (qmail 6846 invoked by uid 777); 24 Jan 2004 00:51:44 -0000 Date: Sat, 24 Jan 2004 01:51:44 +0100 From: Karol Kozimor To: linux-kernel@vger.kernel.org Cc: linux-xfs@oss.sgi.com Subject: Re: 2.6.2-rc1-mm2 Message-ID: <20040124005144.GA30881@hell.org.pl> Mail-Followup-To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <1h670-8J-5@gated-at.bofh.it> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <1h670-8J-5@gated-at.bofh.it> User-Agent: Mutt/1.4.1i X-archive-position: 1881 X-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: 1337 Lines: 41 Thus wrote Andrew Morton: > - There is a new debug check in here which drops a stack trace when a piece > of code calls one of the sleep_on() functions without lock_kernel() held. > This is almost certainly a bug. Please try to identify (from the trace) > which subsystem is the culprit and copy its maintainer when reporting such > traces. #v+ Linux version 2.6.2-rc1-mm2 (sziwan@nadir) (gcc version 3.3.2) #11 Fri Jan 23 22:45:18 CET 2004 [...] Badness in interruptible_sleep_on at kernel/sched.c:2230 Call Trace: [] interruptible_sleep_on+0xd1/0xd6 [] default_wake_function+0x0/0x12 [] pagebuf_daemon+0x0/0x230 [] pagebuf_daemon+0x215/0x230 [] pagebuf_daemon_wakeup+0x0/0x2a [] pagebuf_daemon+0x0/0x230 [] kernel_thread_helper+0x5/0xb [...] XFS mounting filesystem hda5 Badness in interruptible_sleep_on at kernel/sched.c:2230 Call Trace: [] interruptible_sleep_on+0xd1/0xd6 [] default_wake_function+0x0/0x12 [] pagebuf_daemon+0x215/0x230 [] pagebuf_daemon_wakeup+0x0/0x2a [] pagebuf_daemon+0x0/0x230 [] kernel_thread_helper+0x5/0xb Ending clean XFS mount for filesystem: hda5 #v- [there was more of that, omitted] Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Fri Jan 23 21:53:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 21:53:48 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0O5rR7J031482 for ; Fri, 23 Jan 2004 21:53:27 -0800 Received: from [10.0.0.7] (sandeen.net [209.173.210.139]) by sandeen.net (Postfix) with ESMTP id 546D02800F1; Fri, 23 Jan 2004 23:53:20 -0600 (CST) Subject: Re: XFS internal error / xfs_force_shutdown From: Eric Sandeen To: Dan Lake Cc: linux-xfs@oss.sgi.com In-Reply-To: <1074888088.16610.1013.camel@zoot.spimageworks.com> References: <1074888088.16610.1013.camel@zoot.spimageworks.com> Content-Type: text/plain Message-Id: <1074923328.5533.1.camel@Liberator2> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 23 Jan 2004 23:48:49 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1882 X-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@sandeen.net Precedence: bulk X-list: linux-xfs Content-Length: 865 Lines: 24 you've hits a few different things... at least this one: Jan 6 16:00:05 foobar kernel: Filesystem "md(9,0)": xfs_log_write: reservation ran out. Need to up reservation can be solved by mounting with the 'ikeep' option, or upgrading to a newer kernel from cvs. It's a problem with deleting unused clusters of on-disk inodes. -Eric On Fri, 2004-01-23 at 14:01, Dan Lake wrote: > I have been using XFS with some success on Linux NFS fileservers. In > the past month, one server has been subjected to an > extremely heavy load - lots of IO, many files created/read/deleted, full > filesystem. With the increase in load, the system has crashed or hung > numerous times. I've included system configuration information and XFS > relevant traces from /var/log/messages below. > > I'd like to stabilize this system. Any suggestions? > > =Dan Lake > Imageworks From owner-linux-xfs@oss.sgi.com Fri Jan 23 22:04:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 22:04:33 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0O64L7J032025 for ; Fri, 23 Jan 2004 22:04:22 -0800 Received: from [10.0.0.7] (sandeen.net [209.173.210.139]) by sandeen.net (Postfix) with ESMTP id 874F92800F1; Sat, 24 Jan 2004 00:04:12 -0600 (CST) Subject: Re: List configuration From: Eric Sandeen To: Darrell Michaud Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1074895133.9579.28.camel@atherne> References: <4007500D.1060806@linuxmail.org> <40086E9F.90602@myphorum.com> <1074295715.1535.12.camel@stout.americas.sgi.com> <1074895133.9579.28.camel@atherne> Content-Type: text/plain Message-Id: <1074923980.5533.6.camel@Liberator2> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 23 Jan 2004 23:59:41 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1883 X-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@sandeen.net Precedence: bulk X-list: linux-xfs Content-Length: 1690 Lines: 43 I sent that email 5 days ago, it sat on a server for 5 days before moving on. Argh. But yes, I see all the spam that got through yesterday. A disaster. I assume spamd died again, but this is getting to be a problem. An open list with a few spams a week is manageable, the flurry yesterday is an embarrassment. We'll discuss it. -Eric On Fri, 2004-01-23 at 15:58, Darrell Michaud wrote: > It wasn't just yesterday. Not to revive a dead horse but I received over > 30 spam mails from the XFS list in the last 24 hours. > > Something needs to be done if this list is going to remain useful to a > wide audience. > > Before someone flames me to be unsubscribe if I don't like it, I am a > step ahead of you. > > Take care. > > > > On Fri, 2004-01-16 at 18:28, Eric Sandeen wrote: > > On Fri, 2004-01-16 at 17:16, Arthur Corliss wrote: > > > > > > You are free to unsubscribe. > > > > > > Yes, I am. But until someone from SGI tells me that they refuse to fix the > > > list config, I'm going to stay and hope it gets fixed. I want to get the > > > legitimate e-mails, I just don't want the spam. And I really don't think I'm > > > being unreasonable for expecting that much. > > > > We do not plan to change our previous conscious decision to keep the > > list open. It's not broken, it's intentional. I'm sorry you don't like > > it. It's not your choice. staying subscribed, or not, is your choice. > > > > spamd died for a while, some spam got through, deal with it. If you > > can't deal with it, please -do- unsubscribe. This thread has had higher > > volume, and not much more useful content, then the small bit of spam > > that leaked through. > > > > -Eric From owner-linux-xfs@oss.sgi.com Fri Jan 23 22:26:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Jan 2004 22:26:44 -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 i0O6QL7J000319 for ; Fri, 23 Jan 2004 22:26:22 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.8) with ESMTP id i0O6QI1r017607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Jan 2004 07:26:19 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i0O6QAUu011965; Sat, 24 Jan 2004 07:26:10 +0100 Date: Sat, 24 Jan 2004 07:26:10 +0100 From: Axel Thimm To: Stefan Smietanowski Cc: linux-xfs@oss.sgi.com Subject: Re: Does anyone even WANT a Fedora Core 1 that's XFS capable? Message-ID: <20040124062610.GD5447@neu.nirvana> References: <401152DE.6050707@stesmi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DiL7RhKs8rK9YGuF" Content-Disposition: inline In-Reply-To: <401152DE.6050707@stesmi.com> User-Agent: Mutt/1.4.1i X-archive-position: 1884 X-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: 1017 Lines: 37 --DiL7RhKs8rK9YGuF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Stefan, On Fri, Jan 23, 2004 at 05:59:10PM +0100, Stefan Smietanowski wrote: > I've been working alot on making an FC1 XFS installer and > the question I have is : Does anyone want it ? I want it! ;) > RAID (at least I don't think it does, haven't verified). > LVM (Still a few things to take care of before that works). > GRUB (same bug as before.. except now grub must be killed > manually during installation and then reinstalled manually). Is this something that could be fixed by patching the rpms? How does RH deal with it in FC2? --=20 Axel.Thimm@physik.fu-berlin.de --DiL7RhKs8rK9YGuF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAEhACQBVS1GOamfERAqmLAJ9I0Z4Nkq2kDejZck+b3Wmk2fL8dQCfR2bz Qdz/qpcQR6PMJZN42F2gXCg= =tf22 -----END PGP SIGNATURE----- --DiL7RhKs8rK9YGuF-- From owner-linux-xfs@oss.sgi.com Sat Jan 24 06:49:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 24 Jan 2004 06:50:16 -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 i0OEnm7J019207 for ; Sat, 24 Jan 2004 06:49:49 -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 i0OEnlNp032182 for ; Sat, 24 Jan 2004 15:49:47 +0100 Message-ID: <40128720.1030902@stesmi.com> Date: Sat, 24 Jan 2004 15:54:24 +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: Fedora Core 1 XFS update Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1886 X-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: 1082 Lines: 29 Hi again people. I sat up for a number of hours yesterday trying to get LVM to work and I finally succeeded but it was too late for the time when my mirror starts downloading from me. The only issue I currently have with it is grub, one needs to do a few things himself (they're very easy). I haven't tried having root on LVM or RAID so I don't know if that works or not. Normal LVM and RAID works though. The installer itself is based on the fedora core development one (a later version is what should be in fc2 test1 but I haven't verified that). The installer however is patched in quite a number of places so that it can install FC1. Since I got some very positive mails during this time I will push it to my mirror and will be available tomorrow sometime. I'll write up something better and release that when I've compiled the version that'll be pushed to mirror so expect another of these (boring) mails. Any questions or bugreports as usual go to me at stesmi@stesmi.com. Any flames go to /dev/null and all positive remarks go to the email address above :) // Stefan From owner-linux-xfs@oss.sgi.com Sat Jan 24 07:45:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 24 Jan 2004 07:45:39 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OFjG7J021098 for ; Sat, 24 Jan 2004 07:45:17 -0800 Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 6A81398386; Sat, 24 Jan 2004 16:45:11 +0100 (CET) Received: by wotan.suse.de (Postfix, from userid 14000) id E187D1072C; Sat, 24 Jan 2004 16:45:10 +0100 (CET) To: mru@kth.se (=?iso-8859-1?q?M=E5ns_Rullg=E5rd?=) Cc: ivi@runbox.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.1 + XFS wierdness References: <8D2C6B0D-21C8-11B2-9DDD-000A958B60EE__36670.0378632688$1074934610@runbox.com.suse.lists.linux.kernel> From: Andi Kleen Date: 24 Jan 2004 16:45:10 +0100 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 1887 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1310 Lines: 33 mru@kth.se (Måns Rullgård) writes: > Igor writes: > > > Ok, as advised I'm reporting what happened to my system: > > I run Kernel 2.6.1 with XFS on a laptop, I forgot to send it to "sleep" > > and battery died, so there was unclean unmount (This is, what I > > believe was the cause), > > at some point after I restarted my system many of the files couldn't > > be executed: > > "binary file can't be executed reported", However the system was > > functional and I could boot it. > > So I hexopened some of the problematic files and found that although > > the size of the file is maintained, there was no data, every byte was > > replaced by 0, I guess it was lucking reference on a hard drive or > > maybe something else. The reason I think the root of the problem is > > filesystem + kernel because the "corrupted" files have nothing in > > common, e.g: > > /usr/bin/file > > /etc/init.d/cron > > /usr/bin/lynx > > and that only happened when I updated kernel to 2.6.1 > > See http://oss.sgi.com/projects/xfs/faq.html#nulls I don't think his description fits the FAQ. The XFS 0 problem should only happen to files that have been written shortly before the crash. Zeroing/destroying random files that haven't been written looks more like a bug (either in XFS or in a driver) -Andi From owner-linux-xfs@oss.sgi.com Sat Jan 24 09:59:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 24 Jan 2004 10:00: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 i0OHxs7J027885 for ; Sat, 24 Jan 2004 09:59:54 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0OHxsFE027884 for linux-xfs@oss.sgi.com; Sat, 24 Jan 2004 09:59:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i0OHxr7L027868 for ; Sat, 24 Jan 2004 09:59:53 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0OHVBnA026988; Sat, 24 Jan 2004 09:31:11 -0800 Date: Sat, 24 Jan 2004 09:31:11 -0800 Message-Id: <200401241731.i0OHVBnA026988@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: 1888 X-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: 1620 Lines: 42 http://oss.sgi.com/bugzilla/show_bug.cgi?id=284 ------- Additional Comments From ja@mail.upjs.sk 2004-24-01 09:31 PDT ------- I retested current xfs version with bonnie. bonnie++-1.02c kernel-2.6.1 SGI-XFS CVS-2004-01-14_06:00_UTC with ACLs, realtime, no debug enabled xfsprogs-2.5.5 meta-data=/mnt/mnt2 isize=256 agcount=8, agsize=16000 blks = sectsz=512 data = bsize=4096 blocks=128000, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 In my previous test (older xfs snapshot, older kernel) bonnie was able to run test with "-u 0:0 -s 0 -n 500" when I used "ikeep" option with mount. Now I created 500M loop device with xfs. I mounted it without additional options (I think "ikeep" is default.) But now bonnie ended with error: # /tmp/bonnie++-1.02c/bonnie++ -d /mnt/mnt2/test -u 0:0 -s 0 -n 500 Using uid:0, gid:0. Create files in sequential order...Can't create file 0511995sgY3t723y2 Cleaning up test directory after error. I repeated test 3 times, the only difference was name of file. There is no log in /var/log/messages nor dmesg. (I have "5" in /proc/sys/fs/xfs/error_level.) When error occured FS was approximately 30% full. ------- 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 Sat Jan 24 12:15:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 24 Jan 2004 12:15:50 -0800 (PST) Received: from mail.mnsu.edu (Mail.MNSU.EDU [134.29.1.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OKFT7J001519 for ; Sat, 24 Jan 2004 12:15:30 -0800 Received: from mnsu.edu (j3gum-5.MavNet.MNSU.EDU [134.29.64.3]) by mail.mnsu.edu (8.12.10/8.12.10) with ESMTP id i0OKFKHM009872 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 24 Jan 2004 14:15:20 -0600 Message-ID: <4012D258.6010201@mnsu.edu> Date: Sat, 24 Jan 2004 14:15:20 -0600 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, "XFS: linux-xfs@oss.sgi.com" , marcelo.tosatti@cyclades.com Subject: 2.4.24 with the 2.4.23-xfs patches from sgi Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1889 X-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: 1054 Lines: 22 Hello, In the last 48-hours we've had two machines hang with no messages on the console and none in the logs, pings return, drive lights are all off and don't ever flash. Both machines we running linux-2.4.24 with the xfs-2.4.23-all-i386 patch as recommended by the XFS group. These machines had been running fine on this kernel image since Jan 13, 2004. One machine was running XFS as a filesystem and the other was running EXT2. These machines have both been in constant production for over 4 years and there has not been any hardware changes, including those to it's environment with is power and temperature controlled. Both machines are Pentium-3 class, 256M of memory, both using SCSI disk with different SCSI controllers. This is the the version string: Linux version 2.4.24-xfs (j3gum@krypton) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 SMP Tue Jan 13 22:05:12 CST 2004 If you need more specific info. I'll prob. keep these and the other dozen on the same kernel image up for a few more days. -- jeffrey hundstad From owner-linux-xfs@oss.sgi.com Sat Jan 24 15:27:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 24 Jan 2004 15:27:45 -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 i0ONRN7J013884 for ; Sat, 24 Jan 2004 15:27:23 -0800 Received: from cm-net-poa-C8B025C6.brdterra.com.br (cm-net-poa-C8B025C6.brdterra.com.br [200.176.37.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by intra.cyclades.com (Postfix) with ESMTP id 000DE2DCA5A; Sat, 24 Jan 2004 15:14:58 -0800 (PST) Date: Sat, 24 Jan 2004 21:14:56 -0200 (BRST) From: Marcelo Tosatti X-X-Sender: marcelo@logos.cnet To: "Jeffrey E. Hundstad" Cc: linux-kernel@vger.kernel.org, "XFS: linux-xfs@oss.sgi.com" , marcelo.tosatti@cyclades.com Subject: Re: 2.4.24 with the 2.4.23-xfs patches from sgi In-Reply-To: <4012D258.6010201@mnsu.edu> Message-ID: References: <4012D258.6010201@mnsu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1890 X-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 Content-Length: 1354 Lines: 34 On Sat, 24 Jan 2004, Jeffrey E. Hundstad wrote: > Hello, > > In the last 48-hours we've had two machines hang with no messages on the > console and none in the logs, pings return, drive lights are all off and > don't ever flash. Both machines we running linux-2.4.24 with the > xfs-2.4.23-all-i386 patch as recommended by the XFS group. These > machines had been running fine on this kernel image since Jan 13, > 2004. One machine was running XFS as a filesystem and the other was > running EXT2. These machines have both been in constant production for > over 4 years and there has not been any hardware changes, including > those to it's environment with is power and temperature controlled. > > Both machines are Pentium-3 class, 256M of memory, both using SCSI disk > with different SCSI controllers. This is the the version string: > Linux version 2.4.24-xfs (j3gum@krypton) (gcc version 2.95.4 20011002 > (Debian prerelease)) #1 SMP Tue Jan 13 22:05:12 CST 2004 > > If you need more specific info. I'll prob. keep these and the other > dozen on the same kernel image up for a few more days. Hi Jeffrey, There is a known VFS _SMP_ deadlock in 2.4.24. I'm not sure if that is what you are hitting, but it is likely. So try 2.4.25-pre7 (which contains an uptodated XFS tree) and check if the problem goes away. Please keep me informed. From owner-linux-xfs@oss.sgi.com Sun Jan 25 01:19:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Jan 2004 01:20:11 -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 i0P9Jl7J005731 for ; Sun, 25 Jan 2004 01:19:48 -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 i0P9JhNp020848 for ; Sun, 25 Jan 2004 10:19:43 +0100 Message-ID: <40138B44.3080309@stesmi.com> Date: Sun, 25 Jan 2004 10:24: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: linux-xfs@oss.sgi.com Subject: Fedora Core 1 XFS DVD released Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1891 X-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: 5468 Lines: 155 Hi Everybody. Ok, I the mirror started fetching the Fedora Core XFS DVD v0.1 image roughly 6 hours ago so it's a few more hours until it's downloadable. The basics: It's Fedora Core 1 with all updates as of tonight. The kernel is the latest atrpms kernel with updated LVM and XFS 1.3.1 and other candy. I had to replace two RPMS from standard Fedora Core 1: pciutils and kudzu. They're the same as in Fedora Core Development as of a few days ago, except that kudzu is recompiled (python2.3 vs python2.2). The installer is the Fedora Core Development anaconda, and NOT the regular Fedora Core 1 installer. It's been patched in many places by me though. Current bugs : If you have XFS on your /boot (or if you have no /boot and have XFS on your / partition) grub locks up right at the end of the install. The readme on the mirror (and on the DVD describes what to do to get it installed. It's not difficult. Other than that everything works as it should. I would like as much feedback (good or bad) so please email me at stesmi@stesmi.com if you downloaded it, even if it's just to say "ok, it worked for me on my computer". Excerpts from the README follows. // Stefan Version 0.1 (2004-01-25) Disclaimer This DVD compilation was made by me, Stefan Smietanowski and I take no responsibility whatsoever that it works or not. If it breaks, you get to keep the pieces. No warranty is neither expressed or implied. Be warned. This release is not endorsed or supported by either RedHat or SGI. If it doesn't work, don't bug them about it. Where to get: There is currently only one place to get it from: ftp://ftp.uninett.no/pub/linux/RH-XFS-DVD/ That dir will always contain the latest version I hope to add at least one ftp site to the list later on. If anyone has a high-bandwidth site that can take 3-4GiB files, email me. Only serious offers please. ADSL is not high bandwidth :) Thanx to Uninett in norway for the chance to mirror it there. It's a 10Gps link. What's on this DVD: * Fedora Core 1 "Yarrow" CDs 1-6, including the SRPMS. * All updates that were released up to and including 2004-01-25 at 00:00 GMT. They are installed automatically when the system is installed. The DVD does not contain the old RPMS. There is one exception. The script that builds the DVD locks up for some reason if I add the "vnc" and "vnc-server" RPMS to it. I have not included those updated RPMS. They can however be installed afterwards. Just download them from the net. * A modified Fedora Core Development Installer. * Kernel RPMS that are made by Axel Thimm that are based on the Fedora Core 1 update RPMS except they also contain XFS and an updated LVM apart from some other things. * The XFS tools that are needed. If you have any questions or ideas, or just want to tell me how great it is that I made this DVD, please mail me at the email address below. Also please drop me a note that you used it at all and if you encountered any bugs that aren't described below. This is NOT an invitation to send unsolicited email ("spam"). Stefan Smietanowski (stesmi@stesmi.com) Thanx must go to: (In no particular order) Axel Thimm Nicolai Langfeldt Russel Cattelan Eric Sandeen Nathan Straz and the rest of the XFS team! This DVD wouldn't have existed without you! * The copyright of any program on this DVD are owned by their respective copyright holder. Known Bugs: - Doesn't work. + Contains a bugfix but needs to be tested by more people. * Fixed ? Unknown if bug still exists. Usually a new bug found in an older version. - GRUB won't install properly at all for some reason. Looking for a fix for this. Workaround exists. See above. If you have a solution or idea to any of these problems, please email me at stesmi@stesmi.com and I'll incorporate them into the next release. Version history: 0.0.X XXXX-XX-XX Internal testing to get stuff building and working. First cut was a simple FC1 DVD, then I slowly added updates and the XFS kernel and finally modified the Fedora Core development installer to install FC1. 0.1 2004-01-25 First release. Was basically a rename of the last 0.0.X version. Frequently Asked Questions: Q - Why release a Fedora Core 1 with XFS support when the Fedora Core 2 Test 1 is (almost) out? A - Why not? FC1 is stable. I run a server from this DVD, but I wouldn't do that off FC2 test 1. Q - Why on earth did you modify the Fedora Core development installer (anaconda) instead of adding XFS support to the FC1 installer? A - I started looking at how they had done their XFS support and saw more and more that I could just as well use that although it proved to be a lot of work to get it to work. The development installer is almost what the Fedora Core 2 Test 1 installer is and it installs a 2.6 kernel so there were lots of changes here and there. In the end I like it better than the old one, but that's me. Q - This sucks. You should NOT have done XXX like that. A - Your opinion is your own. You have all my files and work. Roll your own distro. Q - I think you could make XXX differently and this is why ... A - Describe it properly and I'll look at it. I might agree with you. Q - This installer ate my disk! A - Odd, I thought it wasn't hungry. Read the disclaimer above. From owner-linux-xfs@oss.sgi.com Sun Jan 25 05:59:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Jan 2004 06:00:23 -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 i0PDxx7J028520 for ; Sun, 25 Jan 2004 05:59:59 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0PDxxf7028519 for linux-xfs@oss.sgi.com; Sun, 25 Jan 2004 05:59:59 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i0PDxv7N028503 for ; Sun, 25 Jan 2004 05:59:57 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0PDC32b027621; Sun, 25 Jan 2004 05:12:03 -0800 Date: Sun, 25 Jan 2004 05:12:03 -0800 Message-Id: <200401251312.i0PDC32b027621@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: 1892 X-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: 417 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=284 drzeus_bugzilla@drzeus.cx changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |drzeus_bugzilla@drzeus.cx ------- 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 Sun Jan 25 11:52:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Jan 2004 11:53:04 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PJqq7J011938 for ; Sun, 25 Jan 2004 11:52:52 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0PJqluJ010753 for ; Sun, 25 Jan 2004 13:52:47 -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 i0PJql6B31557757; Sun, 25 Jan 2004 13:52: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 i0PJqf0n115992; Sun, 25 Jan 2004 13:52:46 -0600 (CST) Date: Sun, 25 Jan 2004 13:52:41 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Kelsey Cummings cc: linux-xfs@oss.sgi.com Subject: Re: log questions In-Reply-To: <20040123212845.GK32531@sonic.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1893 X-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: 923 Lines: 28 It is possible, but unsupported. you need to use xfs_db to modify the superblock(s) to change the log device, and have a cleanly unmounted filesystem, and a zeroed-out new log device. http://oss.sgi.com/cgi-bin/namazu.cgi?query=xfs_db+external+log&submit=Search%21&idxname=linux-xfs&max=20&result=normal&sort=score is a place to start. -Eric On Fri, 23 Jan 2004, Kelsey Cummings wrote: > Is is possible to relocate a log to an external device on a prexisting XFS > filesystem? > > I've poked around in the man pages but haven't found any way to do this > that's abundantly clear. > > -- > Kelsey Cummings - kgc@sonic.net sonic.net, inc. > System Administrator 2260 Apollo Way > 707.522.1000 (Voice) Santa Rosa, CA 95407 > 707.547.2199 (Fax) http://www.sonic.net/ > Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 > > From owner-linux-xfs@oss.sgi.com Sun Jan 25 11:56:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Jan 2004 11:56:11 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PJtx7J012172 for ; Sun, 25 Jan 2004 11:56:00 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0PJtouJ012061 for ; Sun, 25 Jan 2004 13:55: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 i0PJtn6B31559190; Sun, 25 Jan 2004 13:55: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 i0PJtn0n115646; Sun, 25 Jan 2004 13:55:49 -0600 (CST) Date: Sun, 25 Jan 2004 13:55:49 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Kelsey Cummings cc: linux-xfs@oss.sgi.com Subject: Re: [LNX-XFS] log questions In-Reply-To: <20040124004030.GS32531@sonic.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1894 X-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: 1018 Lines: 23 On Fri, 23 Jan 2004, Kelsey Cummings wrote: > Another, closely related question: Is is possible to recreate a log on > an external device that has been lost? Sure, just make another device of at least tthe size of the original log, and zero it all out. you'd probably want to run repair, depending on how you lost the log in the first place. > I'm benchmarking the use of a SSD for the logdevice (results are a bit > suprising) and one concern that I have is if the SSD fails, can I create a > new log easily for it? I can always make a image of the logdevice with dd, > and keep it around as a backup, but that seems a bit strange and I'm not > sure that the it would work correctly anyway. The log is constantly changing, as it is circular. backing it up would do you no good; if it dies, you've lost metadata info and your fs is inconsistent. You can recover to some extent by adding a new device, zeroing it out, and running repair, but this is not something you want to do as a matter of course. -Eric From owner-linux-xfs@oss.sgi.com Sun Jan 25 12:35:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Jan 2004 12:35:51 -0800 (PST) Received: from priv-edtnes56.telusplanet.net (defout.telus.net [199.185.220.240]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PKZb7J016610 for ; Sun, 25 Jan 2004 12:35:39 -0800 Received: from telus.net ([142.173.228.94]) by priv-edtnes56.telusplanet.net (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with ESMTP id <20040125203529.VOHA23093.priv-edtnes56.telusplanet.net@telus.net>; Sun, 25 Jan 2004 13:35:29 -0700 Message-ID: <40142890.8040600@telus.net> Date: Sun, 25 Jan 2004 13:35:28 -0700 From: Aly Dharshi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Smietanowski CC: linux-xfs@oss.sgi.com Subject: Re: Fedora Core 1 XFS DVD released References: <40138B44.3080309@stesmi.com> In-Reply-To: <40138B44.3080309@stesmi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1895 X-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: 143 Lines: 9 Hi Stefan, I hope that you are well, this is great ! Are you planning to release a set of regular cd iso's ? Cheers, Aly. From owner-linux-xfs@oss.sgi.com Sun Jan 25 13:34:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Jan 2004 13:35:05 -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 i0PLYp7J018621 for ; Sun, 25 Jan 2004 13:34:52 -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 i0PLYnNp025052; Sun, 25 Jan 2004 22:34:50 +0100 Message-ID: <40143790.4000705@stesmi.com> Date: Sun, 25 Jan 2004 22:39:28 +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: Aly Dharshi CC: linux-xfs@oss.sgi.com Subject: Re: Fedora Core 1 XFS DVD released References: <40138B44.3080309@stesmi.com> <40142890.8040600@telus.net> In-Reply-To: <40142890.8040600@telus.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1896 X-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: 608 Lines: 23 Aly Dharshi wrote: > Hi Stefan, > > I hope that you are well, this is great ! Are you planning to > release a set of regular cd iso's ? > > Cheers, > Aly. Maybe, depending on how many ask me. It would be simple to make new ISOs but it's more work to do it like SGI has done it before. That is, I can cut this DVD into CDs without trouble, but you would have to download all 3-4 CDs (+SRPM CDS if you want them). It's more work to make this into a CD like SGI did it, where you use the regular CDs and just download an installation CD from SGI. But it all depends on interest. // Stefan From owner-linux-xfs@oss.sgi.com Sun Jan 25 13:41:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Jan 2004 13:41:52 -0800 (PST) Received: from mail17-red-R.bigfish.com (mail-red.bigfish.com [216.148.222.61]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PLfd7J019451 for ; Sun, 25 Jan 2004 13:41:39 -0800 Received: from mail17-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail17-red-R.bigfish.com (Postfix) with ESMTP id 45772170F3F; Sun, 25 Jan 2004 21:41:33 +0000 (UCT) Received: by mail17-red (MessageSwitch) id 1075066893208775_4718; Sun, 25 Jan 2004 21:41:33 +0000 (UCT) Received: from mx1.spimageworks.com (unknown [160.33.20.27]) by mail17-red.bigfish.com (Postfix) with ESMTP id 169BE170F26; Sun, 25 Jan 2004 21:41:33 +0000 (UCT) Received: from zoot.spimageworks.com (zoot.spimageworks.com [172.18.5.16]) by mx1.spimageworks.com (8.11.6/8.11.6) with ESMTP id i0PLfXm14718; Sun, 25 Jan 2004 13:41:33 -0800 Subject: Re: XFS internal error / xfs_force_shutdown From: Dan Lake To: Russell Cattelan Cc: linux-xfs@oss.sgi.com In-Reply-To: <1074893124.13255.238.camel@naboo.americas.sgi.com> References: <1074893124.13255.238.camel@naboo.americas.sgi.com> Content-Type: multipart/mixed; boundary="=-S+1sg+VwTfcGVUer+nmy" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 25 Jan 2004 13:41:33 -0800 Message-Id: <1075066893.22406.1045.camel@zoot.spimageworks.com> Mime-Version: 1.0 X-BigFish: v X-archive-position: 1897 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: danl@imageworks.com Precedence: bulk X-list: linux-xfs Content-Length: 7103 Lines: 275 --=-S+1sg+VwTfcGVUer+nmy Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2004-01-23 at 13:25, Russell Cattelan wrote: > On Fri, 2004-01-23 at 14:01, Dan Lake wrote: > > I have been using XFS with some success on Linux NFS fileservers. In > > the past month, one server has been subjected to an > > extremely heavy load - lots of IO, many files created/read/deleted, > full > > filesystem. With the increase in load, the system has crashed or hung > > numerous times. I've included system configuration information and > XFS > > relevant traces from /var/log/messages below. > > > > I'd like to stabilize this system. Any suggestions? > > > > =Dan Lake > > Imageworks > Can you run xfs_repair -n on the device and send us the output. As I mentioned, I had already run xfs_repair on these filesystems. I had an opportunity today to re-run xfs_repair and sure enough, there were inconsistencies needing repair. I've attached the output to this message. On a separate note, I'm thinking of trying a 2.4.25 prepatch but am wondering which would be better for my situation: 2.4.25-pre7 or the SGI CVS kernel which appears to be 2.4.25-pre4? Thanks! =danl -- pi equals 3 -- for small values of pi and large values of 3 --=-S+1sg+VwTfcGVUer+nmy Content-Disposition: attachment; filename="xfs_repair-md1.out" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name="xfs_repair-md1.out; charset=ISO-8859-1" 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 =3D 0 - agno =3D 1 - agno =3D 2 - agno =3D 3 - agno =3D 4 - agno =3D 5 - agno =3D 6 - agno =3D 7 - agno =3D 8 - agno =3D 9 - agno =3D 10 - agno =3D 11 - agno =3D 12 - agno =3D 13 - agno =3D 14 - agno =3D 15 - agno =3D 16 - agno =3D 17 - agno =3D 18 - agno =3D 19 - agno =3D 20 - agno =3D 21 - agno =3D 22 - agno =3D 23 - agno =3D 24 - agno =3D 25 - agno =3D 26 - agno =3D 27 - agno =3D 28 - agno =3D 29 - agno =3D 30 - agno =3D 31 - agno =3D 32 - agno =3D 33 - agno =3D 34 - agno =3D 35 - agno =3D 36 - agno =3D 37 - agno =3D 38 - agno =3D 39 - agno =3D 40 - agno =3D 41 - agno =3D 42 - agno =3D 43 - agno =3D 44 - agno =3D 45 - agno =3D 46 - agno =3D 47 - agno =3D 48 - agno =3D 49 - agno =3D 50 - agno =3D 51 - agno =3D 52 - agno =3D 53 - agno =3D 54 - agno =3D 55 - agno =3D 56 - agno =3D 57 - agno =3D 58 - agno =3D 59 - agno =3D 60 - agno =3D 61 - agno =3D 62 - agno =3D 63 - agno =3D 64 - agno =3D 65 - agno =3D 66 - agno =3D 67 - agno =3D 68 - agno =3D 69 - agno =3D 70 - agno =3D 71 - agno =3D 72 - agno =3D 73 - agno =3D 74 - agno =3D 75 - agno =3D 76 - agno =3D 77 - agno =3D 78 - agno =3D 79 - agno =3D 80 - agno =3D 81 - agno =3D 82 - agno =3D 83 - agno =3D 84 - agno =3D 85 - agno =3D 86 - agno =3D 87 - agno =3D 88 - agno =3D 89 - agno =3D 90 - agno =3D 91 - agno =3D 92 - agno =3D 93 - agno =3D 94 - agno =3D 95 - agno =3D 96 - agno =3D 97 - agno =3D 98 - agno =3D 99 - agno =3D 100 - agno =3D 101 - agno =3D 102 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno =3D 0 - agno =3D 1 - agno =3D 2 - agno =3D 3 - agno =3D 4 - agno =3D 5 - agno =3D 6 - agno =3D 7 - agno =3D 8 - agno =3D 9 - agno =3D 10 - agno =3D 11 - agno =3D 12 - agno =3D 13 - agno =3D 14 - agno =3D 15 - agno =3D 16 - agno =3D 17 - agno =3D 18 - agno =3D 19 - agno =3D 20 - agno =3D 21 - agno =3D 22 - agno =3D 23 - agno =3D 24 - agno =3D 25 - agno =3D 26 - agno =3D 27 - agno =3D 28 - agno =3D 29 - agno =3D 30 - agno =3D 31 - agno =3D 32 - agno =3D 33 - agno =3D 34 - agno =3D 35 - agno =3D 36 - agno =3D 37 - agno =3D 38 - agno =3D 39 - agno =3D 40 - agno =3D 41 - agno =3D 42 - agno =3D 43 - agno =3D 44 - agno =3D 45 - agno =3D 46 - agno =3D 47 - agno =3D 48 - agno =3D 49 - agno =3D 50 - agno =3D 51 - agno =3D 52 - agno =3D 53 - agno =3D 54 - agno =3D 55 - agno =3D 56 - agno =3D 57 - agno =3D 58 - agno =3D 59 - agno =3D 60 - agno =3D 61 - agno =3D 62 - agno =3D 63 - agno =3D 64 - agno =3D 65 - agno =3D 66 - agno =3D 67 - agno =3D 68 - agno =3D 69 - agno =3D 70 - agno =3D 71 - agno =3D 72 - agno =3D 73 - agno =3D 74 - agno =3D 75 - agno =3D 76 - agno =3D 77 - agno =3D 78 - agno =3D 79 - agno =3D 80 - agno =3D 81 - agno =3D 82 - agno =3D 83 - agno =3D 84 - agno =3D 85 - agno =3D 86 - agno =3D 87 - agno =3D 88 - agno =3D 89 - agno =3D 90 - agno =3D 91 - agno =3D 92 - agno =3D 93 - agno =3D 94 - agno =3D 95 - agno =3D 96 - agno =3D 97 - agno =3D 98 - agno =3D 99 - agno =3D 100 - agno =3D 101 - agno =3D 102 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ...=20 - traversal finished ...=20 - traversing all unattached subtrees ...=20 - traversals finished ...=20 - moving disconnected inodes to lost+found ...=20 disconnected inode 1057005473, would move to lost+found Phase 7 - verify link counts... would have reset inode 1057005471 nlinks from 2 to 7 would have reset inode 1057005472 nlinks from 2 to 1 would have reset inode 1090650754 nlinks from 142 to 141 No modify flag set, skipping filesystem flush and exiting. --=-S+1sg+VwTfcGVUer+nmy-- From owner-linux-xfs@oss.sgi.com Sun Jan 25 14:36:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 25 Jan 2004 14:36:17 -0800 (PST) Received: from toronto.yossman.net (root@yossman.net [209.162.234.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PMa37J021454 for ; Sun, 25 Jan 2004 14:36:04 -0800 Received: from toronto.yossman.net (localhost.yossman.net [127.0.0.1]) by toronto.yossman.net (8.12.8p1/8.12.8) with ESMTP id i0PMZbR6005172; Sun, 25 Jan 2004 17:35:37 -0500 (EST) (envelope-from jjackson@toronto.yossman.net) Received: (from jjackson@localhost) by toronto.yossman.net (8.12.8p1/8.12.8/Submit) id i0PMZajK005171; Sun, 25 Jan 2004 17:35:36 -0500 (EST) Date: Sun, 25 Jan 2004 17:35:36 -0500 (EST) From: jjackson Message-Id: <200401252235.i0PMZajK005171@toronto.yossman.net> To: linux-xfs@oss.sgi.com Subject: xfsdump Debian build Cc: jerj@coplanar.net X-archive-position: 1898 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jjackson@toronto.yossman.net Precedence: bulk X-list: linux-xfs Content-Length: 372 Lines: 11 jerj@coplanar.net Hi, I just build all the cmd-tars successfully on debian stable, except xfsdump-2.2.16. I had to make my own changelog entry for the new version (2.2.16) and it is missing a dependency on xfslibs-dev (part of xfsprogs) for the new inode flag defines. If no Debian maintainer is available let me know and I'll send a patch. Regards, Jeremy Jackson From owner-linux-xfs@oss.sgi.com Mon Jan 26 05:28:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Jan 2004 05:28:38 -0800 (PST) Received: from imo-m04.mx.aol.com (imo-m04.mx.aol.com [64.12.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QDSB7J000360 for ; Mon, 26 Jan 2004 05:28:11 -0800 Received: from AndyLiebman@aol.com by imo-m04.mx.aol.com (mail_out_v36_r4.12.) id 4.110.2d63d229 (4238) for ; Mon, 26 Jan 2004 08:27:55 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <110.2d63d229.2d466fda@aol.com> Date: Mon, 26 Jan 2004 08:27:54 EST Subject: Symbolic Links & XFS To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5006 X-archive-position: 1899 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 741 Lines: 17 A question about symbolic links and Linux XFS. Is there any limitation on the number of symbolic links one could make to a file under XFS in Linux? For example, if I had 2000 files in a directory, and each file had 20 symbolic links to it, is there any reason why I might get into trouble because of the links? (And could it make any difference how long the directory and subdirectory and filenames are?) If so, is XFS any different in regard to symbolic links compared to other Linux filesystems? I have no reason to suspect there could be a problem with XFS, but I want to make sure there won't be before I put a big system into production that uses tons of symbolic links. Thanks in advance for your replies. Andy Liebman From owner-linux-xfs@oss.sgi.com Mon Jan 26 08:18:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Jan 2004 08:19:26 -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 i0QGIw7J007595 for ; Mon, 26 Jan 2004 08:18: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 i0QG9w82028605 for ; Mon, 26 Jan 2004 08:09: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 i0QG9VNL31596589; Mon, 26 Jan 2004 10:09:31 -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 i0QG9V0n177762; Mon, 26 Jan 2004 10:09:31 -0600 (CST) Date: Mon, 26 Jan 2004 10:09:31 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: AndyLiebman@aol.com cc: linux-xfs@oss.sgi.com Subject: Re: Symbolic Links & XFS In-Reply-To: <110.2d63d229.2d466fda@aol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1900 X-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: 1213 Lines: 36 From xfs_dinode.h: /* * The 32 bit link count in the inode theoretically maxes out at UINT_MAX. * Since the pathconf interface is signed, we use 2^31 - 1 instead. * The old inode format had a 16 bit link count, so its maximum is USHRT_MAX. */ #define XFS_MAXLINK ((1U << 31) - 1U) For comparison, EXT2_LINK_MAX is 32000 I don't think you'll have any problem. -Eric On Mon, 26 Jan 2004 AndyLiebman@aol.com wrote: > A question about symbolic links and Linux XFS. Is there any limitation on the > number of symbolic links one could make to a file under XFS in Linux? > > For example, if I had 2000 files in a directory, and each file had 20 > symbolic links to it, is there any reason why I might get into trouble because of the > links? (And could it make any difference how long the directory and > subdirectory and filenames are?) If so, is XFS any different in regard to symbolic > links compared to other Linux filesystems? > > I have no reason to suspect there could be a problem with XFS, but I want to > make sure there won't be before I put a big system into production that uses > tons of symbolic links. > > Thanks in advance for your replies. > > Andy Liebman > > From owner-linux-xfs@oss.sgi.com Mon Jan 26 09:19:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Jan 2004 09:19:44 -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 i0QHJL7J012286 for ; Mon, 26 Jan 2004 09:19:21 -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 i0QHIA82014675 for ; Mon, 26 Jan 2004 09:18:10 -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 i0QHHgqp31638387; Mon, 26 Jan 2004 11:17:42 -0600 (CST) Received: from zhadum.americas.sgi.com (zhadum.americas.sgi.com [128.162.233.43]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i0QHHg4X380095; Mon, 26 Jan 2004 11:17:42 -0600 (CST) Received: from zhadum.americas.sgi.com by zhadum.americas.sgi.com (SGI-8.12.5/SGI-client-1.7) via ESMTP id i0QHHgt8003131; Mon, 26 Jan 2004 11:17:42 -0600 (CST) Received: (from overby@localhost) by zhadum.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0QHHfi3003126; Mon, 26 Jan 2004 11:17:41 -0600 (CST) Date: Mon, 26 Jan 2004 11:17:41 -0600 (CST) Message-Id: <200401261717.i0QHHfi3003126@zhadum.americas.sgi.com> From: Glen Overby To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com Reply-To: linux-xfs@oss.sgi.com Subject: Re: Symbolic Links & XFS In-Reply-To: message from AndyLiebman@aol.com sent 26 January 2004 References: <110.2d63d229.2d466fda@aol.com> X-archive-position: 1901 X-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: 884 Lines: 21 On January 26, AndyLiebman@aol.com wrote: > A question about symbolic links and Linux XFS. Is there any limitation on the > number of symbolic links one could make to a file under XFS in Linux? There is no XFS specific limit to the number of symbolic links to a file. Inodes don't contain any information about symlinks pointing to them. > For example, if I had 2000 files in a directory, and each file had 20 > symbolic links to it, is there any reason why I might get into trouble because of the > links? (And could it make any difference how long the directory and > subdirectory and filenames are?) If so, is XFS any different in regard to symbolic > links compared to other Linux filesystems? None of these limits apply to XFS; I'll leave the linux filesystem comparison for someone else. The maximum length of an individual symbolic link is 1024 bytes. Glen Overby From owner-linux-xfs@oss.sgi.com Mon Jan 26 10:06:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Jan 2004 10:06:54 -0800 (PST) Received: from wingerboy.noc.sonic.net (wingerboy.noc.sonic.net [64.142.18.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QI6e7J013747 for ; Mon, 26 Jan 2004 10:06:43 -0800 Received: from wingerboy.noc.sonic.net (localhost [127.0.0.1]) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9) with ESMTP id i0QI6eK8054201; Mon, 26 Jan 2004 10:06:40 -0800 (PST) (envelope-from kgc@wingerboy.noc.sonic.net) Received: (from kgc@localhost) by wingerboy.noc.sonic.net (8.12.9p1/8.12.9/Submit) id i0QI6e2O054200; Mon, 26 Jan 2004 10:06:40 -0800 (PST) Date: Mon, 26 Jan 2004 10:06:40 -0800 From: Kelsey Cummings To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: [LNX-XFS] log questions Message-ID: <20040126180640.GD47649@sonic.net> References: <20040124004030.GS32531@sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-PGP-Key: http://sonic.net/~kgc/gpgkey.txt X-archive-position: 1902 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kgc@sonic.net Precedence: bulk X-list: linux-xfs Content-Length: 1744 Lines: 38 On Sun, Jan 25, 2004 at 01:55:49PM -0600, Eric Sandeen wrote: > On Fri, 23 Jan 2004, Kelsey Cummings wrote: > > > Another, closely related question: Is is possible to recreate a log on > > an external device that has been lost? > > Sure, just make another device of at least tthe size of the original > log, and zero it all out. you'd probably want to run repair, depending > on how you lost the log in the first place. Presumably extended power failure - or possibly other hardware problems. > > I'm benchmarking the use of a SSD for the logdevice (results are a bit > > suprising) and one concern that I have is if the SSD fails, can I create a > > new log easily for it? I can always make a image of the logdevice with dd, > > and keep it around as a backup, but that seems a bit strange and I'm not > > sure that the it would work correctly anyway. > > The log is constantly changing, as it is circular. backing it > up would do you no good; if it dies, you've lost metadata info > and your fs is inconsistent. You can recover to some extent by > adding a new device, zeroing it out, and running repair, but this > is not something you want to do as a matter of course. The intent was not to get use the image as a 'backup of the log' clearly that wouldn't be helpful! I was concerned that the log may have some internal structures or tagging that would require the use of xfs tools and not just dd, etc. Thanks! -- Kelsey Cummings - kgc@sonic.net sonic.net, inc. System Administrator 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax) http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 From owner-linux-xfs@oss.sgi.com Mon Jan 26 13:55:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Jan 2004 13: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 i0QLtJ7J032207 for ; Mon, 26 Jan 2004 13:55:19 -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 i0QLs5wZ008249 for ; Mon, 26 Jan 2004 13:54:06 -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 i0QLrVhI1149661 for ; Tue, 27 Jan 2004 08:53:31 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0QLrUct1146930 for linux-xfs@oss.sgi.com; Tue, 27 Jan 2004 08:53:30 +1100 (EST) Date: Tue, 27 Jan 2004 08:53:30 +1100 (EST) From: Nathan Scott Message-Id: <200401262153.i0QLrUct1146930@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump Debian build update X-archive-position: 1903 X-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: 342 Lines: 14 Update xfsdump Debian build files. Date: Mon Jan 26 13:52:03 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:165438a xfsdump/debian/control - 1.18 xfsdump/debian/changelog - 1.44 From owner-linux-xfs@oss.sgi.com Mon Jan 26 14:18:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Jan 2004 14:18:44 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QMIV7J001212 for ; Mon, 26 Jan 2004 14:18:31 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i0QM8uWd000477 for ; Mon, 26 Jan 2004 14:08:57 -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 JAA04308; Tue, 27 Jan 2004 09:08:48 +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 i0QM8kUc3672521; Tue, 27 Jan 2004 09:08:47 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0QM8gVQ3590721; Tue, 27 Jan 2004 09:08:42 +1100 (EST) Date: Tue, 27 Jan 2004 09:08:42 +1100 From: Nathan Scott To: jjackson Cc: linux-xfs@oss.sgi.com, jerj@coplanar.net Subject: Re: xfsdump Debian build Message-ID: <20040127090841.B3540156@wobbly.melbourne.sgi.com> References: <200401252235.i0PMZajK005171@toronto.yossman.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200401252235.i0PMZajK005171@toronto.yossman.net>; from jjackson@toronto.yossman.net on Sun, Jan 25, 2004 at 05:35:36PM -0500 X-archive-position: 1904 X-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: 375 Lines: 15 On Sun, Jan 25, 2004 at 05:35:36PM -0500, jjackson wrote: > jerj@coplanar.net > Hi, > > I just build all the cmd-tars successfully on debian stable, except > xfsdump-2.2.16. I had to make my own changelog entry for the new > version (2.2.16) and it is missing a dependency on xfslibs-dev (part of > xfsprogs) for the new inode flag defines. > Fixed, thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jan 26 16:00:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Jan 2004 16:00: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 i0R00E7J005751 for ; Mon, 26 Jan 2004 16:00:14 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0R00ERK005750 for linux-xfs@oss.sgi.com; Mon, 26 Jan 2004 16:00:14 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i0R0057N005724 for ; Mon, 26 Jan 2004 16:00:12 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0QN8tM5004479; Mon, 26 Jan 2004 15:08:55 -0800 Date: Mon, 26 Jan 2004 15:08:55 -0800 Message-Id: <200401262308.i0QN8tM5004479@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: 1905 X-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: 1409 Lines: 53 http://oss.sgi.com/bugzilla/show_bug.cgi?id=284 ------- Additional Comments From nathans@sgi.com 2004-26-01 15:08 PDT ------- > Now I created 500M loop device with xfs. I mounted it without additional options > (I think "ikeep" is default.) Thats correct. > But now bonnie ended with error: > # /tmp/bonnie++-1.02c/bonnie++ -d /mnt/mnt2/test -u 0:0 -s 0 -n 500 > Using uid:0, gid:0. Hmmm - I ran this on the weekend on a regular disk, and no errors. Do you only see this on loopback or on other devices too? Unfortunately bonnie++ is not telling us the real error code here: > Create files in sequential order...Can't create file 0511995sgY3t723y2 Could you build bonnie++ with this patch and let me know the extra output? That'll give us a better hint as to where things are going wrong at least. --- bon_file.cpp.orig 2004-01-27 09:51:43.709224000 +1100 +++ bon_file.cpp 2004-01-27 09:52:40.221394000 +1100 @@ -6,6 +6,7 @@ #else #include #include +#include #endif #include #include @@ -167,7 +168,7 @@ #endif if(fd == -1) { - fprintf(stderr, "Can't create file %s\n", filename); + fprintf(stderr, "Can't create file %s: %s\n", filename, strerror(errno)); return -1; } if(m_max) ------- 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 Jan 27 01:33:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Jan 2004 01:33:29 -0800 (PST) Received: from newmail.informatik.fh-gelsenkirchen.de (mail.informatik.fh-gelsenkirchen.de [194.94.127.5] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0R9X47J008279 for ; Tue, 27 Jan 2004 01:33:05 -0800 Received: from localhost (newmail [127.0.0.1]) by newmail.informatik.fh-gelsenkirchen.de (Postfix) with ESMTP id 1FF122BEA7; Tue, 27 Jan 2004 10:27:12 +0100 (CET) Received: from mail.informatik.fh-ge.de (mail.informatik.fh-ge.de [172.16.0.20]) by newmail.informatik.fh-gelsenkirchen.de (Postfix) with ESMTP id BB9552BEA6; Tue, 27 Jan 2004 10:27:10 +0100 (CET) Subject: Re: Fedora Core 1 XFS DVD released From: Thomas Zerulla To: Stefan Smietanowski Cc: linux-xfs@oss.sgi.com In-Reply-To: <40138B44.3080309@stesmi.com> References: <40138B44.3080309@stesmi.com> Content-Type: text/plain Message-Id: <1075195947.19902.63.camel@aquarius.tecmedic-gelsenkirchen.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 27 Jan 2004 10:32:28 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by Amavis - > Sophos X-archive-position: 1906 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Thomas.Zerulla@informatik.fh-ge.de Precedence: bulk X-list: linux-xfs Content-Length: 235 Lines: 10 Thank you for this DVD. but how can I upgrade from RedHat 9 XFS (fresh installation from RH9-XFS-DVD-0.0.3) to FC1-XFS-DVD-0.1 ??? Thank you and have a good day > -- Thomas Zerulla From owner-linux-xfs@oss.sgi.com Tue Jan 27 05:00:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Jan 2004 05:00:33 -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 i0RD0A7J020837 for ; Tue, 27 Jan 2004 05:00:10 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0RD0ASn020836 for linux-xfs@oss.sgi.com; Tue, 27 Jan 2004 05:00: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 i0RD087N020820 for ; Tue, 27 Jan 2004 05:00:08 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i0RCtPut020686; Tue, 27 Jan 2004 04:55:25 -0800 Date: Tue, 27 Jan 2004 04:55:25 -0800 Message-Id: <200401271255.i0RCtPut020686@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: 1907 X-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: 848 Lines: 28 http://oss.sgi.com/bugzilla/show_bug.cgi?id=284 ------- Additional Comments From ja@mail.upjs.sk 2004-27-01 04:55 PDT ------- Hi. I did the test with reiserfs on loop device just to be sure if it isn't loop error. Reiserfs passed the test. With modified bonnie I got this output: /tmp/bonnie++-1.02c/bonnie++ -d /mnt/mnt2/test -u 0:0 -s 0 -n 500 Using uid:0, gid:0. Create files in sequential order...Can't create file 0511995NB9mBb: No space left on device Cleaning up test directory after error. It is unexpecting result for me. I ran command 'df' in loop every 2 second. The FS was filled to 30% where error occured: /dev/loop0 507200 148164 359036 30% /mnt/mnt2 (I can send full log if needed.) ------- 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 Jan 27 06:14:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Jan 2004 06:15:12 -0800 (PST) Received: from avalon.informatik.uni-freiburg.de (avalon.informatik.uni-freiburg.de [132.230.150.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0REEk7J024063 for ; Tue, 27 Jan 2004 06:14:47 -0800 Received: from gmx.net (kitkat.informatik.uni-freiburg.de [132.230.167.207]) by avalon.informatik.uni-freiburg.de (8.9.3p2/8.9.0) with ESMTP id PAA26789 for ; Tue, 27 Jan 2004 15:14:47 +0100 (MET) Message-ID: <4016728C.3010008@gmx.net> Date: Tue, 27 Jan 2004 15:15:40 +0100 From: Michael Veeck User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.6) Gecko/20040114 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [PATCH] XFS: remove warning in xfs_log_recover, 2.6.2-rc2 Content-Type: multipart/mixed; boundary="------------040405010100040101050106" X-archive-position: 1908 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michael.veeck@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 1794 Lines: 58 This is a multi-part message in MIME format. --------------040405010100040101050106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Compiling the 2.6.2-rc2 kernel on my machine with allyesconfig and gcc 3.3.1 triggers the following warning: CC fs/xfs/xfs_log_recover.o fs/xfs/xfs_log_recover.c: In function `xlog_recover_reorder_trans': fs/xfs/xfs_log_recover.c:1534: warning: `flags' might be used uninitialized in this function I've added an "= 0" to the appropiate line which lets it cleanly compile now. Attached patch fixes the warning and is against 2.6.2-rc2. Apply with patch -p1 < patch-XFSwarning. The patch was also send to the LinuxKernelList and to owner-xfs@oss.sgi.com. But the latter (from the MAINTAINER-file) doesnt seem to be valid anymore? Best regards Michael Veeck --------------040405010100040101050106 Content-Type: text/plain; name="patch-XFSwarning" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-XFSwarning" diff -Naur a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c --- old/fs/xfs/xfs_log_recover.c 2004-01-27 14:28:03.000000000 +0100 +++ new/fs/xfs/xfs_log_recover.c 2004-01-27 14:02:25.000000000 +0100 @@ -1531,7 +1531,7 @@ xlog_recover_item_t *first_item, *itemq, *itemq_next; xfs_buf_log_format_t *buf_f; xfs_buf_log_format_v1_t *obuf_f; - ushort flags; + ushort flags = 0; first_item = itemq = trans->r_itemq; trans->r_itemq = NULL; --------------040405010100040101050106 Content-Type: text/plain; name="README" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="README" [PATCH] xfs has uninitialized flags-variable in xfs_log_recover. init it to 0. from michael.veeck@gmx.net --------------040405010100040101050106-- From owner-linux-xfs@oss.sgi.com Tue Jan 27 07:55:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Jan 2004 07:55:34 -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 i0RFtU7J001904 for ; Tue, 27 Jan 2004 07:55:30 -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 i0RFtORl016210; Tue, 27 Jan 2004 16:55:25 +0100 Message-ID: <40168B06.7050007@stesmi.com> Date: Tue, 27 Jan 2004 17:00: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: Mike Burger CC: Thomas Zerulla , linux-xfs@oss.sgi.com Subject: Re: Fedora Core 1 XFS DVD released References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1909 X-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: 651 Lines: 27 Mike Burger wrote: > Put the DVD into your system's drive, boot the system, select "Upgrade" > during the installation process? > > On 27 Jan 2004, Thomas Zerulla wrote: > > >>Thank you for this DVD. >>but how can I upgrade from RedHat 9 XFS (fresh installation from >>RH9-XFS-DVD-0.0.3) to FC1-XFS-DVD-0.1 ??? >>Thank you and have a good day >> >> >> > Except of course the upgrade option doesn't exist. That's why you add "upgradeany" to the command line when you start the installer. It seems to have worked for him and that made me happy. So it is possible to use my DVD to upgrade from RH9 (at least) to FC1, both XFSified. // Stefan From owner-linux-xfs@oss.sgi.com Tue Jan 27 08:21:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Jan 2004 08:21:05 -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 i0RGL17J020861 for ; Tue, 27 Jan 2004 08:21:02 -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 i0RGKuRl017299; Tue, 27 Jan 2004 17:20:57 +0100 Message-ID: <40169102.6010107@stesmi.com> Date: Tue, 27 Jan 2004 17:25: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: Mike Burger CC: Thomas Zerulla , linux-xfs@oss.sgi.com Subject: Re: Fedora Core 1 XFS DVD released References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1910 X-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: 394 Lines: 15 Mike Burger wrote: > Aaahhh...I wasn't aware that the upgrade option didn't exist in your > setup. It did when I upgraded my non-XFS firewall from RHL7.2 to FC1. > > I'll have to keep the "upgradeany" option when I do mine. It's not really such a huge issue having to use "upgradeany" is it? You just enter it on the command line before the kernel boots. "linux upgradeany". // Stefan From owner-linux-xfs@oss.sgi.com Tue Jan 27 08:24:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Jan 2004 08:24:11 -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 i0RGO87J021438 for ; Tue, 27 Jan 2004 08:24:08 -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 i0RGNsRl017430; Tue, 27 Jan 2004 17:23:54 +0100 Message-ID: <401691B3.5@stesmi.com> Date: Tue, 27 Jan 2004 17:28:35 +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: "Net Llama!" CC: linux-xfs@oss.sgi.com Subject: Re: Fedora Core 1 XFS DVD released References: <40168B06.7050007@stesmi.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1911 X-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: 557 Lines: 17 Net Llama! wrote: > Stefan, > If you could createa a CD image that would help me alot. I don't have a > DVD drive attached to the majority of my boxes. If it's ok for you to download 3-4 CDs and not be able to use the regular FC1 CDs then I can do that. Give me a few days as I'm preparing a (major*) update to the DVD and I'll try to push out CDs at the same time. // Stefan * Added a number of packages from atrpms and modified the installer so they can be selected in their own category, the new libata driver in the kernel and other things. From owner-linux-xfs@oss.sgi.com Tue Jan 27 08:44:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Jan 2004 08:44:47 -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 i0RGie7J022429 for ; Tue, 27 Jan 2004 08:44:41 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.8) with ESMTP id i0RGiK1r008103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Jan 2004 17:44:21 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i0RGi4Jw015227; Tue, 27 Jan 2004 17:44:04 +0100 Date: Tue, 27 Jan 2004 17:44:03 +0100 From: Axel Thimm To: Stefan Smietanowski Cc: Net Llama! , linux-xfs@oss.sgi.com Subject: Re: Fedora Core 1 XFS DVD released Message-ID: <20040127164403.GD10641@neu.nirvana> References: <40168B06.7050007@stesmi.com> <401691B3.5@stesmi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GyRA7555PLgSTuth" Content-Disposition: inline In-Reply-To: <401691B3.5@stesmi.com> User-Agent: Mutt/1.4.1i X-archive-position: 1912 X-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: 1217 Lines: 42 --GyRA7555PLgSTuth Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 27, 2004 at 05:28:35PM +0100, Stefan Smietanowski wrote: > Net Llama! wrote: >=20 > >Stefan, > >If you could createa a CD image that would help me alot. I don't have a > >DVD drive attached to the majority of my boxes. >=20 > If it's ok for you to download 3-4 CDs and not be able to use > the regular FC1 CDs then I can do that. Give me a few days as > I'm preparing a (major*) update to the DVD and I'll try to push > out CDs at the same time. >=20 > // Stefan >=20 > * Added a number of packages from atrpms and modified the installer > so they can be selected in their own category, the new libata driver > in the kernel and other things. I'll update the dmapi/xfsprogs/xfsdump rpms also (attr, acl are already uptodate). --=20 Axel.Thimm@physik.fu-berlin.de --GyRA7555PLgSTuth Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAFpVTQBVS1GOamfERAiCKAJ4+URU5AhGq0Y2npWOODaBxyutVzgCfVLB4 XHHp9g3JS/cWnbmprg6u3Sk= =Hyml -----END PGP SIGNATURE----- --GyRA7555PLgSTuth-- From owner-linux-xfs@oss.sgi.com Tue Jan 27 09:08:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Jan 2004 09:08:08 -0800 (PST) Received: from priv-edtnes56.telusplanet.net (defout.telus.net [199.185.220.240]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0RH867J023719 for ; Tue, 27 Jan 2004 09:08:06 -0800 Received: from telus.net ([161.184.244.187]) by priv-edtnes56.telusplanet.net (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with ESMTP id <20040127170800.LARD1017.priv-edtnes56.telusplanet.net@telus.net>; Tue, 27 Jan 2004 10:08:00 -0700 Message-ID: <40169AF0.1010906@telus.net> Date: Tue, 27 Jan 2004 10:08:00 -0700 From: Aly Dharshi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031115 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Smietanowski CC: "Net Llama!" , linux-xfs@oss.sgi.com Subject: Re: Fedora Core 1 XFS DVD released References: <40168B06.7050007@stesmi.com> <401691B3.5@stesmi.com> In-Reply-To: <401691B3.5@stesmi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1913 X-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: 1002 Lines: 40 Hi Stefan, I hope that you are well. I wouldn't mind waiting for the actual regular cd's. I don't mind downloading 3-4 CD's either. Thanxs stacks and Cheers, Aly. Stefan Smietanowski wrote: > Net Llama! wrote: > >> Stefan, >> If you could createa a CD image that would help me alot. I don't have a >> DVD drive attached to the majority of my boxes. > > > If it's ok for you to download 3-4 CDs and not be able to use > the regular FC1 CDs then I can do that. Give me a few days as > I'm preparing a (major*) update to the DVD and I'll try to push > out CDs at the same time. > > // Stefan > > * Added a number of packages from atrpms and modified the installer > so they can be selected in their own category, the new libata driver > in the kernel and other things. > > -- 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 Tue Jan 27 12:23:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Jan 2004 12:23:48 -0800 (PST) Received: from toronto.yossman.net (root@yossman.net [209.162.234.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0RKNW7J000780 for ; Tue, 27 Jan 2004 12:23:33 -0800 Received: from toronto.yossman.net (localhost.yossman.net [127.0.0.1]) by toronto.yossman.net (8.12.8p1/8.12.8) with ESMTP id i0RKNPR6054748; Tue, 27 Jan 2004 15:23:25 -0500 (EST) (envelope-from jjackson@toronto.yossman.net) Received: (from jjackson@localhost) by toronto.yossman.net (8.12.8p1/8.12.8/Submit) id i0RKNPIB054747; Tue, 27 Jan 2004 15:23:25 -0500 (EST) Date: Tue, 27 Jan 2004 15:23:25 -0500 (EST) From: jjackson Message-Id: <200401272023.i0RKNPIB054747@toronto.yossman.net> To: jjackson@toronto.yossman.net, nathans@sgi.com Subject: Re: xfsdump Debian build Cc: jerj@coplanar.net, linux-xfs@oss.sgi.com In-Reply-To: <20040127090841.B3540156@wobbly.melbourne.sgi.com> X-archive-position: 1914 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jjackson@toronto.yossman.net Precedence: bulk X-list: linux-xfs Content-Length: 818 Lines: 31 Hi, I checked the webcvs, and I see the fix there. The tar file has the old date, any chance of updating that as well? Regards, Jeremy > From nathans@wobbly.melbourne.sgi.com Mon Jan 26 17:09:20 2004 > Date: Tue, 27 Jan 2004 09:08:42 +1100 > From: Nathan Scott > To: jjackson > Cc: linux-xfs@oss.sgi.com, jerj@coplanar.net > Subject: Re: xfsdump Debian build > > On Sun, Jan 25, 2004 at 05:35:36PM -0500, jjackson wrote: > > jerj@coplanar.net > > Hi, > > > > I just build all the cmd-tars successfully on debian stable, except > > xfsdump-2.2.16. I had to make my own changelog entry for the new > > version (2.2.16) and it is missing a dependency on xfslibs-dev (part of > > xfsprogs) for the new inode flag defines. > > > > Fixed, thanks. > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Tue Jan 27 13:12:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Jan 2004 13:12:03 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0RLC07J002732 for ; Tue, 27 Jan 2004 13:12:01 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0RLBtFh032392 for ; Tue, 27 Jan 2004 13:11:55 -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 i0RLBrcM31679904; Tue, 27 Jan 2004 15:11: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 i0RLBm0m303419; Tue, 27 Jan 2004 15:11:49 -0600 (CST) Subject: Re: xfsdump Debian build From: Eric Sandeen To: jjackson Cc: nathans@sgi.com, jerj@coplanar.net, linux-xfs@oss.sgi.com In-Reply-To: <200401272023.i0RKNPIB054747@toronto.yossman.net> References: <200401272023.i0RKNPIB054747@toronto.yossman.net> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1075237908.15214.60.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 27 Jan 2004 15:11:48 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1915 X-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: 1081 Lines: 37 Latest bits are pushed out now... On Tue, 2004-01-27 at 14:23, jjackson wrote: > Hi, > > I checked the webcvs, and I see the fix there. The tar file has the old date, any chance of updating that as well? > > Regards, > > Jeremy > > > From nathans@wobbly.melbourne.sgi.com Mon Jan 26 17:09:20 2004 > > Date: Tue, 27 Jan 2004 09:08:42 +1100 > > From: Nathan Scott > > To: jjackson > > Cc: linux-xfs@oss.sgi.com, jerj@coplanar.net > > Subject: Re: xfsdump Debian build > > > > On Sun, Jan 25, 2004 at 05:35:36PM -0500, jjackson wrote: > > > jerj@coplanar.net > > > Hi, > > > > > > I just build all the cmd-tars successfully on debian stable, except > > > xfsdump-2.2.16. I had to make my own changelog entry for the new > > > version (2.2.16) and it is missing a dependency on xfslibs-dev (part of > > > xfsprogs) for the new inode flag defines. > > > > > > > Fixed, thanks. > > > > -- > > Nathan > > -- 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 Jan 28 08:14:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Jan 2004 08:15:29 -0800 (PST) Received: from hotmail.com (bay10-f11.bay10.hotmail.com [64.4.37.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SGEr7J006269 for ; Wed, 28 Jan 2004 08:14:54 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Jan 2004 08:14:48 -0800 Received: from 213.253.102.145 by by10fd.bay10.hotmail.msn.com with HTTP; Wed, 28 Jan 2004 16:14:47 GMT X-Originating-IP: [213.253.102.145] X-Originating-Email: [tomazb@hotmail.com] X-Sender: tomazb@hotmail.com From: "Tomaz Beltram" To: linux-xfs@oss.sgi.com Subject: can't use iget on XFS Date: Wed, 28 Jan 2004 16:14:47 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jan 2004 16:14:48.0236 (UTC) FILETIME=[D9CDCEC0:01C3E5B9] X-archive-position: 1916 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tomazb@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1564 Lines: 43 We have developed a stackable filesystem kernel module for a HSM application. The role of the filter module is to intercept operations between VFS and file system. It then sends events to userspace when these are invoked. We are using ext3 or reiserfs for bottom file system and are evaluating XFS, since it provides all required functionality (extended attributes, journals). In some cases the filter module has to call iget instead of lookup, since it doesn't have the full pathname of the file but just its inode number (ino). On XFS this only works when the inode is found in the cache. If it has to be loaded from disk it oops-es. This is because iget calls read_inode which is not implemented in XFS and just jumps to nowhere. We are considering to call xfs_iget instead of iget, but are not aware of all functional implications this might have. Could someone explain if this is the correct sequence to be called and why not: struct super_block *sb; struct inode *inode; vfs_t *vfsp = LINVFS_GET_VFS(sb); xfs_mount_t *mp = XFS_BHVTOM(vfsp->vfs_fbhv); xfs_inode_t *ip = NULL; int error = xfs_iget(mp, NULL, ino, XFS_ILOCK_SHARED, &ip, 0); vnode_t *vpp = XFS_ITOV(ip); inode = LINVFS_GET_IP(vpp); /* access inode, e.g. read extended attributes */ xfs_iunlock(ip, XFS_ILOCK_SHARED); Any other ideas/suggestion? Thanks in advance for your answer. Tomaz _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-linux-xfs@oss.sgi.com Wed Jan 28 15:39:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Jan 2004 15:39:15 -0800 (PST) Received: from satan.blackhosts (cn202.neoplus.adsl.tpnet.pl [80.54.210.202]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SNcw7J005441 for ; Wed, 28 Jan 2004 15:39:00 -0800 Received: from satan.blackhosts (localhost [127.0.0.1]) by satan.blackhosts (8.12.10/8.12.10) with ESMTP id i0SNhYYN025177 for ; Thu, 29 Jan 2004 00:43:34 +0100 Received: (from qboosh@localhost) by satan.blackhosts (8.12.10/8.12.10/Submit) id i0SNhYbD025174 for linux-xfs@oss.sgi.com; Thu, 29 Jan 2004 00:43:34 +0100 Date: Thu, 29 Jan 2004 00:43:34 +0100 From: Jakub Bogusz To: linux-xfs@oss.sgi.com Subject: Polish translation for attr and acl packages, some i18n notes Message-ID: <20040128234334.GA25005@satan.blackhosts> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 1917 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: qboosh@pld-linux.org Precedence: bulk X-list: linux-xfs Content-Length: 1025 Lines: 29 I've just made Polish translation for these packages (attr 2.4.14 and acl 2.2.22). pl.po files are available on http://cyber.cs.net.pl/~qboosh/pl.po/attr-2.4.14.pl.po http://cyber.cs.net.pl/~qboosh/pl.po/acl-2.2.22.pl.po and can be included in future attr and acl releases (I would be glad to see them there). BTW - when preparing it I found that: - in both packages ENABLE_GETTEXT is not defined automatically even if --enable-gettext is passed (proper AC_DEFINE is missing?) - included attr.pot and acl.pot included in packages were made for some older version and not updated for current (in most packages *.pot files are regenerated when making release, just before packaging to bring them up to date) - in attr/setfattr/setfattr.c:126 there is message containing: "No filename found inline %d of standard input" shouldn't it be "No filename found in line %d of standard input"? (i.e. s/inline/in line/) -- Jakub Bogusz http://cyber.cs.net.pl/~qboosh/ PLD Team http://www.pld-linux.org/ From owner-linux-xfs@oss.sgi.com Wed Jan 28 16:38:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Jan 2004 16:38:26 -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 i0T0cJ7J010899 for ; Wed, 28 Jan 2004 16:38:19 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0T0cinS025135 for ; Wed, 28 Jan 2004 16:38:45 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i0T0aImw024659 for ; Thu, 29 Jan 2004 11:36:18 +1100 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i0T0a2s3024655 for linux-xfs@oss.sgi.com; Thu, 29 Jan 2004 11:36:02 +1100 Date: Thu, 29 Jan 2004 11:36:02 +1100 From: Nathan Scott Message-Id: <200401290036.i0T0a2s3024655@bruce.melbourne.sgi.com> Subject: TAKE 908518 - fix KM_NOFS in 2.6 X-archive-position: 1918 X-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@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 319 Lines: 12 Revert botched merge where KM_NOFS check was unintentionally dropped. Date: Wed Jan 28 16:36:14 PST 2004 Workarea: bruce.melbourne.sgi.com:/source1/ptools/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:165631a linux-2.6/kmem.h - 1.21 From owner-linux-xfs@oss.sgi.com Wed Jan 28 19:57:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Jan 2004 19:57:43 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0T3vc7J017630 for ; Wed, 28 Jan 2004 19:57:38 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0T3vUvk016314 for ; Wed, 28 Jan 2004 21:57:32 -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 i0T3vShI1637335 for ; Thu, 29 Jan 2004 14:57:28 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0T3vRrV1635115 for linux-xfs@oss.sgi.com; Thu, 29 Jan 2004 14:57:27 +1100 (EST) Date: Thu, 29 Jan 2004 14:57:27 +1100 (EST) From: Nathan Scott Message-Id: <200401290357.i0T3vRrV1635115@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - security namespace X-archive-position: 1919 X-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: 476 Lines: 18 Add the security extended attributes namespace. Date: Wed Jan 28 19:56:41 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:165638a fs/xfs/xfsidbg.c - 1.252 fs/xfs/xfs_attr_leaf.h - 1.34 fs/xfs/xfs_attr_leaf.c - 1.76 fs/xfs/xfs_attr.c - 1.114 fs/xfs/xfs_attr.h - 1.29 fs/xfs/linux-2.6/xfs_super.h - 1.52 fs/xfs/linux-2.4/xfs_super.h - 1.58 From owner-linux-xfs@oss.sgi.com Wed Jan 28 20:38:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Jan 2004 20:39:11 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0T4ck7J022229 for ; Wed, 28 Jan 2004 20:38:47 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0T4ccvk015310 for ; Wed, 28 Jan 2004 22:38:39 -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 i0T4cahI1640843 for ; Thu, 29 Jan 2004 15:38:36 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0T4cX2I1624108 for linux-xfs@oss.sgi.com; Thu, 29 Jan 2004 15:38:33 +1100 (EST) Date: Thu, 29 Jan 2004 15:38:33 +1100 (EST) From: Nathan Scott Message-Id: <200401290438.i0T4cX2I1624108@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - merge up to 2.4.25-pre7 X-archive-position: 1920 X-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: 10774 Lines: 338 Date: Wed Jan 28 20:23:20 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:165639a arch/ppc/configs/cpci405_defconfig - 1.1 include/asm-mips/vr41xx/vrc4171.h - 1.1 drivers/net/irda/via-ircc.h - 1.1 drivers/net/irda/via-ircc.c - 1.1 drivers/ide/ppc/cpci405ide.c - 1.1 drivers/char/obmouse.c - 1.1 crypto/cast6.c - 1.1 arch/ppc/platforms/cpci405.h - 1.1 arch/ppc/platforms/cpci405.c - 1.1 arch/mips/vr41xx/common/vrc4171.c - 1.1 arch/mips/defconfig-pb1550 - 1.1 arch/mips/au1000/pb1550/irqmap.c - 1.1 arch/mips/au1000/pb1550/init.c - 1.1 arch/mips/au1000/pb1550/board_setup.c - 1.1 arch/mips/au1000/pb1550/Makefile - 1.1 arch/ia64/mm/hugetlbpage.c - 1.1 CREDITS - 1.3 Documentation/Configure.help - 1.6 Documentation/crypto/api-intro.txt - 1.2 MAINTAINERS - 1.4 Makefile - 1.5 arch/i386/kernel/ldt.c - 1.2 arch/i386/kernel/microcode.c - 1.2 arch/i386/kernel/process.c - 1.3 arch/i386/kernel/smpboot.c - 1.3 arch/i386/math-emu/fpu_system.h - 1.2 arch/ia64/config.in - 1.2 arch/ia64/hp/common/sba_iommu.c - 1.2 arch/ia64/ia32/sys_ia32.c - 1.2 arch/ia64/kernel/acpi.c - 1.2 arch/ia64/kernel/efi.c - 1.2 arch/ia64/kernel/ia64_ksyms.c - 1.2 arch/ia64/kernel/ivt.S - 1.2 arch/ia64/kernel/mca.c - 1.2 arch/ia64/kernel/mca_asm.S - 1.2 arch/ia64/kernel/pci.c - 1.2 arch/ia64/kernel/perfmon.c - 1.2 arch/ia64/kernel/salinfo.c - 1.2 arch/ia64/kernel/setup.c - 1.2 arch/ia64/kernel/sys_ia64.c - 1.2 arch/ia64/mm/Makefile - 1.2 arch/ia64/mm/init.c - 1.2 arch/ia64/tools/print_offsets.c - 1.2 arch/mips/Makefile - 1.2 arch/mips/au1000/common/dma.c - 1.2 arch/mips/au1000/common/irq.c - 1.2 arch/mips/au1000/common/pci_fixup.c - 1.2 arch/mips/au1000/common/pci_ops.c - 1.2 arch/mips/au1000/common/reset.c - 1.2 arch/mips/au1000/common/setup.c - 1.2 arch/mips/au1000/mtx-1/Makefile - 1.2 arch/mips/au1000/mtx-1/board_setup.c - 1.2 arch/mips/au1000/mtx-1/init.c - 1.2 arch/mips/config-shared.in - 1.2 arch/mips/defconfig - 1.2 arch/mips/defconfig-atlas - 1.2 arch/mips/defconfig-bosporus - 1.2 arch/mips/defconfig-capcella - 1.2 arch/mips/defconfig-cobalt - 1.2 arch/mips/defconfig-csb250 - 1.2 arch/mips/defconfig-db1000 - 1.2 arch/mips/defconfig-db1100 - 1.2 arch/mips/defconfig-db1500 - 1.2 arch/mips/defconfig-ddb5476 - 1.2 arch/mips/defconfig-ddb5477 - 1.2 arch/mips/defconfig-decstation - 1.2 arch/mips/defconfig-e55 - 1.2 arch/mips/defconfig-eagle - 1.2 arch/mips/defconfig-ev64120 - 1.2 arch/mips/defconfig-ev96100 - 1.2 arch/mips/defconfig-hp-lj - 1.2 arch/mips/defconfig-hydrogen3 - 1.2 arch/mips/defconfig-ip22 - 1.2 arch/mips/defconfig-it8172 - 1.2 arch/mips/defconfig-ivr - 1.2 arch/mips/defconfig-jmr3927 - 1.2 arch/mips/defconfig-lasat - 1.2 arch/mips/defconfig-malta - 1.2 arch/mips/defconfig-mirage - 1.2 arch/mips/defconfig-mpc30x - 1.2 arch/mips/defconfig-mtx-1 - 1.2 arch/mips/defconfig-nino - 1.2 arch/mips/defconfig-ocelot - 1.2 arch/mips/defconfig-osprey - 1.2 arch/mips/defconfig-pb1000 - 1.2 arch/mips/defconfig-pb1100 - 1.2 arch/mips/defconfig-pb1500 - 1.2 arch/mips/defconfig-rbtx4927 - 1.2 arch/mips/defconfig-rm200 - 1.2 arch/mips/defconfig-sb1250-swarm - 1.2 arch/mips/defconfig-sead - 1.2 arch/mips/defconfig-tb0226 - 1.2 arch/mips/defconfig-tb0229 - 1.2 arch/mips/defconfig-ti1500 - 1.2 arch/mips/defconfig-workpad - 1.2 arch/mips/defconfig-xxs1500 - 1.2 arch/mips/defconfig-yosemite - 1.2 arch/mips/ite-boards/generic/it8172_setup.c - 1.2 arch/mips/kernel/cpu-probe.c - 1.2 arch/mips/kernel/gdb-stub.c - 1.2 arch/mips/kernel/proc.c - 1.2 arch/mips/kernel/smp.c - 1.2 arch/mips/kernel/time.c - 1.2 arch/mips/kernel/traps.c - 1.2 arch/mips/kernel/unaligned.c - 1.2 arch/mips/lib/Makefile - 1.2 arch/mips/lib/rtc-no.c - 1.2 arch/mips/lib/rtc-std.c - 1.2 arch/mips/mm/c-r3k.c - 1.2 arch/mips/mm/c-r4k.c - 1.2 arch/mips/mm/c-sb1.c - 1.2 arch/mips/mm/cex-sb1.S - 1.2 arch/mips/mm/pg-r4k.c - 1.2 arch/mips/mm/tlb-sb1.c - 1.2 arch/mips/pmc-sierra/yosemite/prom.c - 1.2 arch/mips/pmc-sierra/yosemite/smp.c - 1.2 arch/mips/sgi-ip22/ip22-setup.c - 1.2 arch/mips/sgi-ip27/ip27-init.c - 1.2 arch/mips/sgi-ip27/ip27-nmi.c - 1.2 arch/mips/sibyte/cfe/smp.c - 1.2 arch/mips/sibyte/sb1250/smp.c - 1.2 arch/mips/sibyte/sb1250/time.c - 1.2 arch/mips/vr41xx/common/Makefile - 1.2 arch/mips/vr41xx/common/bcu.c - 1.2 arch/mips/vr41xx/common/cmu.c - 1.2 arch/mips/vr41xx/common/giu.c - 1.2 arch/mips/vr41xx/common/icu.c - 1.2 arch/mips/vr41xx/common/rtc.c - 1.2 arch/mips/vr41xx/common/serial.c - 1.2 arch/mips/vr41xx/tanbac-tb0226/init.c - 1.2 arch/mips/vr41xx/tanbac-tb0229/init.c - 1.2 arch/mips/vr41xx/zao-capcella/init.c - 1.2 arch/mips64/Makefile - 1.2 arch/mips64/defconfig - 1.2 arch/mips64/defconfig-atlas - 1.2 arch/mips64/defconfig-decstation - 1.2 arch/mips64/defconfig-ip22 - 1.2 arch/mips64/defconfig-ip27 - 1.2 arch/mips64/defconfig-jaguar - 1.2 arch/mips64/defconfig-malta - 1.2 arch/mips64/defconfig-ocelotc - 1.2 arch/mips64/defconfig-sb1250-swarm - 1.2 arch/mips64/defconfig-sead - 1.2 arch/mips64/kernel/cpu-probe.c - 1.2 arch/mips64/kernel/gdb-stub.c - 1.2 arch/mips64/kernel/head.S - 1.2 arch/mips64/kernel/ioctl32.c - 1.2 arch/mips64/kernel/proc.c - 1.2 arch/mips64/kernel/signal.c - 1.2 arch/mips64/kernel/signal32.c - 1.2 arch/mips64/kernel/smp.c - 1.2 arch/mips64/kernel/syscall.c - 1.2 arch/mips64/kernel/time.c - 1.2 arch/mips64/kernel/unaligned.c - 1.2 arch/mips64/lib/Makefile - 1.2 arch/mips64/lib/rtc-no.c - 1.2 arch/mips64/lib/rtc-std.c - 1.2 arch/mips64/mm/c-r4k.c - 1.2 arch/mips64/mm/c-sb1.c - 1.2 arch/mips64/mm/cex-sb1.S - 1.2 arch/mips64/mm/pg-r4k.c - 1.2 arch/mips64/mm/tlbex-r4k.S - 1.2 arch/ppc/8xx_io/Config.in - 1.2 arch/ppc/boot/simple/embed_config.c - 1.2 arch/ppc/boot/utils/mkbugboot.c - 1.2 arch/ppc/config.in - 1.3 arch/ppc/configs/IVMS8_defconfig - 1.3 arch/ppc/configs/SM850_defconfig - 1.3 arch/ppc/configs/SPD823TS_defconfig - 1.3 arch/ppc/configs/TQM823L_defconfig - 1.3 arch/ppc/configs/TQM850L_defconfig - 1.3 arch/ppc/configs/TQM860L_defconfig - 1.3 arch/ppc/configs/bseip_defconfig - 1.3 arch/ppc/configs/mbx_defconfig - 1.3 arch/ppc/configs/rpxcllf_defconfig - 1.3 arch/ppc/configs/rpxlite_defconfig - 1.3 arch/ppc/platforms/Makefile - 1.3 arch/ppc64/configs/iSeries_devfs_defconfig - 1.2 arch/ppc64/configs/iSeries_nodevfs_ideemul_defconfig - 1.2 arch/ppc64/configs/pSeries_defconfig - 1.2 arch/ppc64/defconfig - 1.2 arch/ppc64/kernel/Makefile - 1.3 arch/ppc64/kernel/chrp_setup.c - 1.3 arch/ppc64/kernel/eeh.c - 1.2 arch/ppc64/kernel/iSeries_setup.c - 1.2 arch/ppc64/kernel/nvram.c - 1.2 arch/ppc64/kernel/perfmon.c - 1.2 arch/ppc64/kernel/prom.c - 1.3 arch/ppc64/kernel/ras.c - 1.3 arch/ppc64/kernel/rtas.c - 1.3 arch/ppc64/kernel/rtas_flash.c - 1.2 arch/ppc64/kernel/rtasd.c - 1.2 arch/ppc64/kernel/setup.c - 1.3 arch/ppc64/kernel/traps.c - 1.3 arch/sparc64/kernel/head.S - 1.2 arch/sparc64/kernel/pci_common.c - 1.2 arch/x86_64/ia32/ptrace32.c - 1.2 crypto/Config.in - 1.2 crypto/Makefile - 1.2 crypto/aes.c - 1.2 crypto/blowfish.c - 1.2 crypto/cast5.c - 1.2 crypto/cipher.c - 1.2 crypto/crypto_null.c - 1.2 crypto/des.c - 1.2 crypto/proc.c - 1.2 crypto/serpent.c - 1.2 crypto/tcrypt.c - 1.2 crypto/tcrypt.h - 1.2 crypto/twofish.c - 1.2 drivers/atm/atmdev_init.c - 1.2 drivers/atm/nicstar.c - 1.2 drivers/char/Config.in - 1.3 drivers/char/Makefile - 1.3 drivers/char/agp/agp.h - 1.2 drivers/char/agp/agpgart_be.c - 1.2 drivers/char/drm/r128_state.c - 1.2 drivers/i2c/Config.in - 1.3 drivers/i2c/i2c-core.c - 1.3 drivers/ide/Config.in - 1.2 drivers/ide/ide-proc.c - 1.2 drivers/ide/ide.c - 1.2 drivers/ide/ppc/Makefile - 1.2 drivers/ieee1394/nodemgr.c - 1.2 drivers/media/video/Makefile - 1.3 drivers/media/video/i2c-old.c - 1.2 drivers/media/video/saa7146.h - 1.2 drivers/net/irda/Config.in - 1.2 drivers/net/irda/Makefile - 1.2 drivers/net/irda/nsc-ircc.c - 1.2 drivers/net/wan/Config.in - 1.3 drivers/parport/Config.in - 1.2 drivers/scsi/changelog.megaraid2 - 1.2 drivers/scsi/cpqfcTSstructs.h - 1.2 drivers/scsi/ips.c - 1.2 drivers/scsi/ips.h - 1.2 drivers/scsi/megaraid2.c - 1.2 drivers/scsi/megaraid2.h - 1.2 drivers/sound/ymfpci.c - 1.2 drivers/tc/lk201.c - 1.2 drivers/tc/zs.c - 1.2 drivers/tc/zs.h - 1.2 drivers/usb/storage/usb.c - 1.2 drivers/usb/vicam.c - 1.2 drivers/usb/w9968cf.c - 1.2 drivers/video/Config.in - 1.2 drivers/video/Makefile - 1.2 drivers/video/fbmem.c - 1.2 drivers/video/maxinefb.c - 1.2 drivers/video/sis/300vtbl.h - 1.2 drivers/video/sis/310vtbl.h - 1.2 drivers/video/sis/init.c - 1.2 drivers/video/sis/init.h - 1.2 drivers/video/sis/init301.c - 1.2 drivers/video/sis/init301.h - 1.2 drivers/video/sis/initdef.h - 1.2 drivers/video/sis/oem300.h - 1.2 drivers/video/sis/oem310.h - 1.2 drivers/video/sis/osdef.h - 1.2 drivers/video/sis/sis_accel.c - 1.2 drivers/video/sis/sis_accel.h - 1.2 drivers/video/sis/sis_main.c - 1.2 drivers/video/sis/sis_main.h - 1.2 drivers/video/sis/vgatypes.h - 1.2 drivers/video/sis/vstruct.h - 1.2 fs/dquot.c - 1.2 fs/ext3/super.c - 1.3 fs/fat/dir.c - 1.2 fs/fat/inode.c - 1.2 fs/fat/misc.c - 1.2 fs/hfs/super.c - 1.2 fs/inode.c - 1.2 fs/jfs/jfs_logmgr.c - 1.2 fs/jfs/xattr.c - 1.2 fs/msdos/namei.c - 1.2 fs/ncpfs/dir.c - 1.2 fs/readdir.c - 1.3 fs/vfat/namei.c - 1.2 include/asm-i386/desc.h - 1.2 include/asm-i386/mmu.h - 1.2 include/asm-i386/mmu_context.h - 1.2 include/asm-i386/processor.h - 1.2 include/asm-ia64/mca.h - 1.2 include/asm-ia64/mmu_context.h - 1.2 include/asm-ia64/page.h - 1.2 include/asm-ia64/pgtable.h - 1.2 include/asm-ia64/processor.h - 1.2 include/asm-ia64/tlb.h - 1.2 include/asm-ia64/xor.h - 1.2 include/asm-mips/asm.h - 1.2 include/asm-mips/au1000.h - 1.2 include/asm-mips/bootinfo.h - 1.2 include/asm-mips/cpu.h - 1.2 include/asm-mips/processor.h - 1.2 include/asm-mips/r4kcache.h - 1.2 include/asm-mips/smp.h - 1.2 include/asm-mips64/asm.h - 1.2 include/asm-mips64/bootinfo.h - 1.2 include/asm-mips64/cpu.h - 1.2 include/asm-mips64/processor.h - 1.2 include/asm-mips64/ptrace.h - 1.2 include/asm-mips64/r4kcache.h - 1.2 include/asm-mips64/smp.h - 1.2 include/asm-mips64/stackframe.h - 1.2 include/asm-ppc/ibm4xx.h - 1.2 include/asm-ppc/todc.h - 1.2 include/asm-ppc64/machdep.h - 1.2 include/asm-ppc64/nvram.h - 1.2 include/asm-ppc64/rtas.h - 1.3 include/linux/crypto.h - 1.2 include/linux/fs.h - 1.3 include/linux/i2c.h - 1.3 include/linux/msdos_fs.h - 1.2 include/linux/msdos_fs_i.h - 1.2 include/linux/quota.h - 1.2 include/linux/sisfb.h - 1.2 include/linux/swap.h - 1.2 include/net/bluetooth/hci_core.h - 1.2 include/net/irda/nsc-ircc.h - 1.2 mm/filemap.c - 1.2 mm/page_alloc.c - 1.2 net/atm/br2684.c - 1.2 net/atm/common.c - 1.2 net/bluetooth/hci_conn.c - 1.2 net/bluetooth/hci_core.c - 1.2 net/ipv4/icmp.c - 1.2 net/ipv4/igmp.c - 1.2 net/ipv4/netfilter/ip_tables.c - 1.2 net/ipv6/mcast.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Jan 28 22:25:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Jan 2004 22:25:13 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0T6P17J025759 for ; Wed, 28 Jan 2004 22:25:01 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0T6Ooo07930; Wed, 28 Jan 2004 22:24:50 -0800 Date: Wed, 28 Jan 2004 22:25:21 -0800 From: Andrew Morton To: "Miquel van Smoorenburg" Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.2-rc2 nfsd+xfs spins in i_size_read() Message-Id: <20040128222521.75a7d74f.akpm@osdl.org> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.4 (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: 1921 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs Content-Length: 2542 Lines: 71 "Miquel van Smoorenburg" wrote: > > I have a Linux 2.6.2-rc2 NFS file server and another similar > box as client. Kernel is compiled for SMP (hyperthreading). > > On the NFS server I'm exporting an XFS filesystem to the client > over Gigabit ethernet. The client mounts using > mount -o nfsvers=3,intr,rsize=32768,wsize=32768 server:/export/hwr /mnt > > On the client I then run a large dd to a file on the server, > like dd if=/dev/zero of=/mnt/file bs=4096 count=800000 > > In a few seconds, the server locks up. It spins in > generic_fillattr(), apparently in the i_size_read() inline function. > Server responds to pings and sysrq, but nothing else. > > 2.6.1 doesn't show this behaviour. I tested several kernels: > > 2.6.1 OK! > 2.6.1-bk4 OK! > 2.6.1-bk5 doesn't boot > 2.6.1-bk6 hangs > 2.6.2-rc1 hangs > 2.6.2-rc2 hangs > 2.6.2-rc2-gcc-2.95 hangs > 2.6.2-rc1-mm3 OK! > 2.6.2-rc2-mm1 OK! > > I can't reproduce it on the local filesystem on the NFS server > directly, and I can't reproduce it on other filesystems than XFS. > But NFSD+XFS locks up every time. > > Unfortunately the diff between 2.6.1-bk4 and bk6 is too large > for me to see what the difference is, likewise 2.6.2-rc2-mm1, > but perhaps someone has an idea what could be causing this ? > > Here's the sysrq output: > > Pid: 531, comm: nfsd > EIP: 0060:[] CPU: 0 > EIP is at generic_fillattr+0x82/0xa0 > EFLAGS: 00000246 Not tainted > EAX: 00000000 EBX: 07ae7200 ECX: f650a0a0 EDX: 000113eb > ESI: 00000000 EDI: f66cfed4 EBP: f66e5804 DS: 007b ES: 007b > CR0: 8005003b CR2: 40019000 CR3: 37245000 CR4: 000006d0 > Call Trace: > [] linvfs_getattr+0x2b/0x34 [xfs] > [] vfs_getattr+0x25/0x84 > [] encode_post_op_attr+0x53/0x238 > [] encode_wcc_data+0x29f/0x2a8 > [] nfs3svc_encode_commitres+0x19/0x5c > [] nfsd_dispatch+0x14d/0x1a3 > [] svc_process+0x3b3/0x640 > [] nfsd+0x1e4/0x358 > [] nfsd+0x0/0x358 > [] kernel_thread_helper+0x5/0xc > Is the EIP _always_ inside generic_fillattr()? If so then yes, your analysis look right. I'd say that the inode has been corrupted and the seqcount counter has assumed an non-even value. That will cause i_size_read() to lock up. Are you using slab debugging? Is so, does the lockup go away if you change mm/slab.c:POISON_FREE to an even value, say 0x6a? That would tend to confirm a use-after-free problem. Or a totally wild pointer. From owner-linux-xfs@oss.sgi.com Wed Jan 28 22:53:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Jan 2004 22:53:17 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0T6rF7J026924 for ; Wed, 28 Jan 2004 22:53:15 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0T6r8UD019143 for ; Thu, 29 Jan 2004 00:53:09 -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 i0T6r5hI1668823; Thu, 29 Jan 2004 17:53:05 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0T6qu131660561; Thu, 29 Jan 2004 17:52:56 +1100 (EST) Date: Thu, 29 Jan 2004 17:52:56 +1100 (EST) From: Nathan Scott Message-Id: <200401290652.i0T6qu131660561@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 908236 - fix compiler warning X-archive-position: 1922 X-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: 312 Lines: 12 Fix a warning from some gcc variants after recent flags botch. Date: Wed Jan 28 22:49:48 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:165646a xfs_log_recover.c - 1.284 From owner-linux-xfs@oss.sgi.com Thu Jan 29 11:31:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Jan 2004 11:32:06 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TJVd7J004632 for ; Thu, 29 Jan 2004 11:31:39 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0TJVWuw004905 for ; Thu, 29 Jan 2004 11:31:33 -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 i0TJVVhI1709046 for ; Fri, 30 Jan 2004 06:31:31 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0TJVUrE1717841 for linux-xfs@oss.sgi.com; Fri, 30 Jan 2004 06:31:30 +1100 (EST) Date: Fri, 30 Jan 2004 06:31:30 +1100 (EST) From: Nathan Scott Message-Id: <200401291931.i0TJVUrE1717841@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.2-rc2 X-archive-position: 1923 X-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: 64561 Lines: 1946 Date: Thu Jan 29 11:23:16 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:165676a drivers/scsi/qla2xxx/Kconfig - 1.1 drivers/scsi/qla2xxx/Makefile - 1.1 Documentation/BK-usage/cpcset - 1.1 Documentation/BK-usage/gcapatch - 1.1 drivers/scsi/qla2xxx/ql2100.c - 1.1 drivers/scsi/qla2xxx/ql2100_fw.c - 1.1 drivers/scsi/qla2xxx/ql2200.c - 1.1 drivers/scsi/qla2xxx/ql2200_fw.c - 1.1 security/selinux/netif.c - 1.1 security/selinux/include/netif.h - 1.1 drivers/scsi/qla2xxx/ql2300.c - 1.1 drivers/scsi/qla2xxx/ql2300_fw.c - 1.1 drivers/scsi/qla2xxx/qla_dbg.c - 1.1 net/bluetooth/cmtp/sock.c - 1.1 Documentation/i386/usb-legacy-support.txt - 1.1 drivers/scsi/qla2xxx/qla_dbg.h - 1.1 drivers/scsi/qla2xxx/qla_def.h - 1.1 drivers/scsi/qla2xxx/qla_devtbl.h - 1.1 drivers/scsi/qla2xxx/qla_gbl.h - 1.1 drivers/scsi/qla2xxx/qla_gs.c - 1.1 drivers/scsi/qla2xxx/qla_init.c - 1.1 Documentation/power/video.txt - 1.1 drivers/scsi/qla2xxx/qla_inline.h - 1.1 Documentation/scsi/qla2xxx.revision.notes - 1.1 Documentation/sh/kgdb.txt - 1.1 drivers/scsi/qla2xxx/qla_iocb.c - 1.1 drivers/scsi/qla2xxx/qla_isr.c - 1.1 drivers/scsi/qla2xxx/qla_listops.h - 1.1 net/bluetooth/cmtp/core.c - 1.1 Documentation/video4linux/CARDLIST.bttv - 1.1 Documentation/video4linux/CARDLIST.saa7134 - 1.1 Documentation/video4linux/CARDLIST.tuner - 1.1 Documentation/video4linux/README.cx88 - 1.1 Documentation/video4linux/README.ir - 1.1 Documentation/video4linux/README.saa7134 - 1.1 drivers/scsi/qla2xxx/qla_mbx.c - 1.1 drivers/scsi/qla2xxx/qla_os.c - 1.1 drivers/scsi/qla2xxx/qla_os.h - 1.1 drivers/scsi/qla2xxx/qla_rscn.c - 1.1 drivers/scsi/qla2xxx/qla_settings.h - 1.1 drivers/scsi/qla2xxx/qla_sup.c - 1.1 drivers/scsi/qla2xxx/qla_version.h - 1.1 drivers/usb/gadget/goku_udc.c - 1.1 drivers/usb/gadget/goku_udc.h - 1.1 drivers/usb/gadget/pxa2xx_udc.c - 1.1 drivers/usb/gadget/pxa2xx_udc.h - 1.1 drivers/usb/gadget/serial.c - 1.1 drivers/usb/misc/emi62.c - 1.1 drivers/usb/misc/emi62_fw_m.h - 1.1 drivers/usb/misc/emi62_fw_s.h - 1.1 drivers/usb/misc/usbled.c - 1.1 drivers/video/kyro/Makefile - 1.1 drivers/video/kyro/STG4000InitDevice.c - 1.1 drivers/video/kyro/STG4000Interface.h - 1.1 drivers/video/kyro/STG4000OverlayDevice.c - 1.1 drivers/video/kyro/STG4000Ramdac.c - 1.1 drivers/video/kyro/STG4000Reg.h - 1.1 drivers/video/kyro/STG4000VTG.c - 1.1 drivers/video/kyro/fbdev.c - 1.1 drivers/zorro/zorro-driver.c - 1.1 drivers/zorro/zorro-sysfs.c - 1.1 drivers/zorro/zorro.h - 1.1 include/asm-arm/arch-pxa/udc.h - 1.1 include/asm-ppc64/iSeries/vio.h - 1.1 include/asm-ppc64/vio.h - 1.1 include/asm-sh/cpu-sh2/addrspace.h - 1.1 include/asm-sh/cpu-sh2/dma.h - 1.1 include/asm-sh/cpu-sh2/shmparam.h - 1.1 include/asm-sh/cpu-sh2/sigcontext.h - 1.1 include/asm-sh/cpu-sh2/ubc.h - 1.1 drivers/s390/char/tty3270.c - 1.1 include/asm-sh/cpu-sh3/sigcontext.h - 1.1 include/asm-sh/cpu-sh4/sigcontext.h - 1.1 include/asm-sh/cpu-sh4/sq.h - 1.1 include/asm-sh/dreamcast/dma.h - 1.1 include/asm-sh/dreamcast/pci.h - 1.1 include/asm-sh/flat.h - 1.1 include/asm-sh/local.h - 1.1 include/asm-sh/sections.h - 1.1 include/asm-sh/segment.h - 1.1 net/bluetooth/cmtp/cmtp.h - 1.1 include/asm-sh/snapgear/io.h - 1.1 include/asm-sh/systemh/7751systemh.h - 1.1 include/asm-sh/systemh/io.h - 1.1 drivers/s390/char/raw3270.h - 1.1 drivers/s390/char/raw3270.c - 1.1 drivers/s390/char/keyboard.h - 1.1 drivers/s390/char/keyboard.c - 1.1 drivers/s390/char/fs3270.c - 1.1 arch/ia64/configs/generic_defconfig - 1.1 net/bluetooth/cmtp/capi.c - 1.1 drivers/s390/char/defkeymap.map - 1.1 drivers/s390/char/defkeymap.c - 1.1 drivers/s390/char/con3270.c - 1.1 include/asm-x86_64/hpet.h - 1.1 include/media/ir-common.h - 1.1 include/video/kyro.h - 1.1 drivers/net/wan/pci200syn.c - 1.1 drivers/net/irda/old_belkin-sir.c - 1.1 drivers/net/irda/mcp2120-sir.c - 1.1 drivers/net/irda/ma600-sir.c - 1.1 drivers/net/irda/litelink-sir.c - 1.1 drivers/net/irda/girbil-sir.c - 1.1 drivers/net/irda/act200l-sir.c - 1.1 drivers/net/forcedeth.c - 1.1 drivers/media/video/saa7134/saa7134-input.c - 1.1 drivers/media/video/ir-kbd-i2c.c - 1.1 drivers/media/video/ir-kbd-gpio.c - 1.1 drivers/media/video/cx88/cx88.h - 1.1 drivers/media/video/cx88/cx88-video.c - 1.1 drivers/media/video/cx88/cx88-tvaudio.c - 1.1 drivers/media/video/cx88/cx88-reg.h - 1.1 drivers/media/video/cx88/cx88-i2c.c - 1.1 drivers/media/video/cx88/cx88-core.c - 1.1 drivers/media/video/cx88/cx88-cards.c - 1.1 arch/ia64/scripts/check-text-align.S - 1.1 arch/ia64/scripts/unwcheck.py - 1.1 drivers/media/video/cx88/Makefile - 1.1 drivers/media/video/bttv-i2c.c - 1.1 drivers/media/video/bttv-gpio.c - 1.1 drivers/media/dvb/ttpci/av7110_v4l.c - 1.1 drivers/media/dvb/ttpci/av7110_hw.h - 1.1 drivers/media/dvb/ttpci/av7110_hw.c - 1.1 drivers/media/dvb/ttpci/av7110_ca.h - 1.1 drivers/media/dvb/ttpci/av7110_ca.c - 1.1 drivers/media/dvb/ttpci/av7110_av.h - 1.1 drivers/media/dvb/ttpci/av7110_av.c - 1.1 drivers/media/common/ir-common.c - 1.1 drivers/md/unroll.pl - 1.1 drivers/md/raid6x86.h - 1.1 drivers/md/raid6test/test.c - 1.1 drivers/md/raid6test/Makefile - 1.1 drivers/md/raid6sse2.c - 1.1 drivers/md/raid6sse1.c - 1.1 drivers/md/raid6recov.c - 1.1 drivers/md/raid6mmx.c - 1.1 drivers/md/raid6main.c - 1.1 drivers/md/raid6int.uc - 1.1 drivers/md/raid6algos.c - 1.1 drivers/md/raid6.h - 1.1 drivers/md/mktables.c - 1.1 drivers/input/keyboard/hpps2atkbd.h - 1.1 lib/bitmap.c - 1.1 drivers/i2c/chips/w83l785ts.c - 1.1 drivers/i2c/chips/lm90.c - 1.1 lib/extable.c - 1.1 drivers/i2c/chips/asb100.c - 1.1 drivers/i2c/busses/i2c-parport.h - 1.1 drivers/i2c/busses/i2c-parport.c - 1.1 drivers/i2c/busses/i2c-parport-light.c - 1.1 net/bluetooth/cmtp/Kconfig - 1.1 drivers/char/viocons.c - 1.1 drivers/bluetooth/bfusb.c - 1.1 drivers/bluetooth/bcm203x.c - 1.1 drivers/base/class_simple.c - 1.1 net/bluetooth/cmtp/Makefile - 1.1 arch/sh/oprofile/op_model_null.c - 1.1 arch/sh/oprofile/Makefile - 1.1 arch/ia64/sn/io/sn2/pcibr/pcibr_reg.c - 1.1 arch/sh/oprofile/Kconfig - 1.1 arch/sh/mm/pg-nommu.c - 1.1 arch/sh/mm/pg-dma.c - 1.1 arch/sh/lib/div64-generic.c - 1.1 arch/sh/kernel/smp.c - 1.1 arch/sh/kernel/cpu/sh4/sq.c - 1.1 arch/sh/kernel/cpu/sh4/ex.S - 1.1 arch/sh/kernel/cpu/sh3/ex.S - 1.1 arch/sh/kernel/cpu/init.c - 1.1 arch/sh/drivers/pci/pci.c - 1.1 arch/ia64/sn/io/snia_if.c - 1.1 arch/sh/drivers/pci/pci-st40.h - 1.1 arch/sh/drivers/pci/pci-st40.c - 1.1 arch/sh/drivers/pci/pci-sh7751.h - 1.1 arch/sh/drivers/pci/pci-sh7751.c - 1.1 arch/sh/drivers/pci/pci-dma.c - 1.1 arch/sh/drivers/pci/pci-auto.c - 1.1 arch/sh/drivers/pci/ops-snapgear.c - 1.1 arch/sh/drivers/pci/ops-dreamcast.c - 1.1 arch/sh/drivers/pci/ops-bigsur.c - 1.1 arch/sh/drivers/pci/fixups-dreamcast.c - 1.1 arch/sh/drivers/pci/dma-dreamcast.c - 1.1 arch/sh/drivers/pci/Makefile - 1.1 arch/sh/drivers/pci/Kconfig - 1.1 arch/sh/drivers/dma/dma-sh.h - 1.1 arch/sh/drivers/dma/dma-sh.c - 1.1 arch/sh/drivers/dma/dma-pvr2.c - 1.1 arch/sh/drivers/dma/dma-isa.c - 1.1 arch/sh/drivers/dma/dma-g2.c - 1.1 arch/sh/drivers/dma/dma-api.c - 1.1 arch/sh/drivers/dma/Makefile - 1.1 arch/sh/drivers/dma/Kconfig - 1.1 arch/sh/drivers/Makefile - 1.1 arch/sh/configs/defconfig-systemh - 1.1 arch/sh/configs/defconfig-snapgear - 1.1 arch/sh/configs/defconfig-se7751 - 1.1 arch/sh/cchips/Kconfig - 1.1 arch/sh/boot/compressed/vmlinux.scr - 1.1 arch/sh/boards/systemh/setup.c - 1.1 arch/sh/boards/systemh/irq.c - 1.1 arch/sh/boards/systemh/io.c - 1.1 arch/sh/boards/systemh/Makefile - 1.1 arch/sh/boards/snapgear/setup.c - 1.1 arch/m68knommu/kernel/module.c - 1.1 arch/sh/boards/snapgear/rtc.c - 1.1 arch/sh/boards/snapgear/io.c - 1.1 arch/sh/boards/snapgear/Makefile - 1.1 arch/ppc64/mm/hash_utils.c - 1.1 arch/ppc64/mm/hash_low.S - 1.1 arch/ppc64/kernel/viopath.c - 1.1 arch/ppc64/kernel/vio.c - 1.1 arch/ppc64/kernel/lparcfg.c - 1.1 arch/ppc64/kernel/iSeries_htab.c - 1.1 CREDITS - 1.3 Documentation/BK-usage/00-INDEX - 1.2 Documentation/DocBook/kernel-locking.tmpl - 1.3 Documentation/SubmittingPatches - 1.2 Documentation/arm/SA1100/CERF - 1.2 Documentation/devices.txt - 1.2 Documentation/fb/modedb.txt - 1.2 Documentation/fb/tridentfb.txt - 1.2 Documentation/filesystems/ntfs.txt - 1.2 Documentation/i386/zero-page.txt - 1.3 Documentation/kernel-parameters.txt - 1.3 Documentation/m68k/00-INDEX - 1.2 Documentation/networking/ip-sysctl.txt - 1.3 Documentation/networking/sk98lin.txt - 1.2 Documentation/power/swsusp.txt - 1.2 Documentation/s390/driver-model.txt - 1.2 Documentation/sh/new-machine.txt - 1.2 Documentation/sysctl/kernel.txt - 1.2 Documentation/sysctl/vm.txt - 1.2 Documentation/video4linux/bttv/CARDLIST - 1.2 Documentation/video4linux/bttv/Insmod-options - 1.2 Documentation/video4linux/bttv/README - 1.2 MAINTAINERS - 1.3 Makefile - 1.3 arch/alpha/Kconfig - 1.2 arch/alpha/kernel/module.c - 1.2 arch/alpha/kernel/signal.c - 1.2 arch/alpha/mm/extable.c - 1.2 arch/arm/configs/cerfpda_defconfig - 1.2 arch/arm/configs/cerfpod_defconfig - 1.2 arch/arm/kernel/setup.c - 1.2 arch/arm/lib/memcpy.S - 1.2 arch/arm/mach-pxa/generic.c - 1.2 arch/arm/mach-pxa/idp.c - 1.2 arch/arm/mach-pxa/lubbock.c - 1.2 arch/arm/mach-sa1100/Kconfig - 1.3 arch/arm/mach-sa1100/leds-cerf.c - 1.2 arch/arm/mm/extable.c - 1.2 arch/arm/mm/proc-arm720.S - 1.2 arch/arm26/mm/extable.c - 1.2 arch/cris/arch-v10/drivers/ds1302.c - 1.2 arch/cris/arch-v10/drivers/pcf8563.c - 1.2 arch/cris/mm/Makefile - 1.2 arch/cris/mm/extable.c - 1.2 arch/h8300/mm/Makefile - 1.2 arch/h8300/mm/extable.c - 1.2 arch/i386/Kconfig - 1.3 arch/i386/defconfig - 1.2 arch/i386/kernel/acpi/wakeup.S - 1.2 arch/i386/kernel/apic.c - 1.2 arch/i386/kernel/apm.c - 1.2 arch/i386/kernel/cpu/cpufreq/Kconfig - 1.2 arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.3 arch/i386/kernel/cpu/cpufreq/speedstep-lib.c - 1.3 arch/i386/kernel/cpu/cpufreq/speedstep-lib.h - 1.3 arch/i386/kernel/cpu/intel.c - 1.2 arch/i386/kernel/cpu/mcheck/k7.c - 1.2 arch/i386/kernel/cpu/mcheck/mce.c - 1.2 arch/i386/kernel/cpu/mcheck/non-fatal.c - 1.2 arch/i386/kernel/cpu/mcheck/p5.c - 1.2 arch/i386/kernel/cpu/mcheck/p6.c - 1.2 arch/i386/kernel/cpu/mcheck/winchip.c - 1.2 arch/i386/kernel/cpu/mtrr/if.c - 1.2 arch/i386/kernel/dmi_scan.c - 1.2 arch/i386/kernel/mca.c - 1.2 arch/i386/kernel/time.c - 1.3 arch/i386/kernel/time_hpet.c - 1.2 arch/i386/mach-voyager/voyager_smp.c - 1.2 arch/i386/mm/extable.c - 1.2 arch/i386/pci/direct.c - 1.2 arch/ia64/Kconfig - 1.3 arch/ia64/Makefile - 1.3 arch/ia64/hp/common/sba_iommu.c - 1.2 arch/ia64/ia32/sys_ia32.c - 1.3 arch/ia64/kernel/acpi.c - 1.3 arch/ia64/kernel/efi.c - 1.3 arch/ia64/kernel/ia64_ksyms.c - 1.3 arch/ia64/kernel/irq.c - 1.3 arch/ia64/kernel/irq_ia64.c - 1.2 arch/ia64/kernel/machvec.c - 1.2 arch/ia64/kernel/perfmon.c - 1.3 arch/ia64/kernel/process.c - 1.2 arch/ia64/kernel/setup.c - 1.3 arch/ia64/kernel/smp.c - 1.2 arch/ia64/kernel/smpboot.c - 1.3 arch/ia64/kernel/time.c - 1.2 arch/ia64/kernel/unwind.c - 1.2 arch/ia64/lib/Makefile - 1.3 arch/ia64/lib/io.c - 1.2 arch/ia64/lib/memcpy_mck.S - 1.2 arch/ia64/lib/memset.S - 1.2 arch/ia64/mm/extable.c - 1.2 arch/ia64/mm/init.c - 1.3 arch/ia64/mm/numa.c - 1.2 arch/ia64/mm/tlb.c - 1.2 arch/ia64/pci/pci.c - 1.3 arch/ia64/scripts/unwcheck.sh - 1.2 arch/ia64/sn/Makefile - 1.2 arch/ia64/sn/fakeprom/README - 1.2 arch/ia64/sn/fakeprom/fprom.lds - 1.2 arch/ia64/sn/io/Makefile - 1.2 arch/ia64/sn/io/cdl.c - 1.2 arch/ia64/sn/io/drivers/Makefile - 1.2 arch/ia64/sn/io/drivers/ioconfig_bus.c - 1.2 arch/ia64/sn/io/hwgfs/Makefile - 1.2 arch/ia64/sn/io/hwgfs/hcl.c - 1.2 arch/ia64/sn/io/hwgfs/hcl_util.c - 1.2 arch/ia64/sn/io/hwgfs/interface.c - 1.2 arch/ia64/sn/io/hwgfs/labelcl.c - 1.2 arch/ia64/sn/io/hwgfs/ramfs.c - 1.2 arch/ia64/sn/io/io.c - 1.2 arch/ia64/sn/io/machvec/Makefile - 1.2 arch/ia64/sn/io/machvec/pci.c - 1.2 arch/ia64/sn/io/machvec/pci_bus_cvlink.c - 1.2 arch/ia64/sn/io/machvec/pci_dma.c - 1.2 arch/ia64/sn/io/platform_init/Makefile - 1.2 arch/ia64/sn/io/platform_init/irix_io_init.c - 1.2 arch/ia64/sn/io/platform_init/sgi_io_init.c - 1.2 arch/ia64/sn/io/sgi_if.c - 1.2 arch/ia64/sn/io/sgi_io_sim.c - 1.2 arch/ia64/sn/io/sn2/Makefile - 1.2 arch/ia64/sn/io/sn2/bte_error.c - 1.2 arch/ia64/sn/io/sn2/geo_op.c - 1.2 arch/ia64/sn/io/sn2/klconflib.c - 1.2 arch/ia64/sn/io/sn2/klgraph.c - 1.2 arch/ia64/sn/io/sn2/l1_command.c - 1.2 arch/ia64/sn/io/sn2/ml_SN_init.c - 1.2 arch/ia64/sn/io/sn2/ml_SN_intr.c - 1.2 arch/ia64/sn/io/sn2/ml_iograph.c - 1.2 arch/ia64/sn/io/sn2/module.c - 1.2 arch/ia64/sn/io/sn2/pcibr/Makefile - 1.2 arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c - 1.2 arch/ia64/sn/io/sn2/pcibr/pcibr_config.c - 1.2 arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.2 arch/ia64/sn/io/sn2/pcibr/pcibr_error.c - 1.2 arch/ia64/sn/io/sn2/pcibr/pcibr_hints.c - 1.2 arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c - 1.2 arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c - 1.2 arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c - 1.2 arch/ia64/sn/io/sn2/pciio.c - 1.2 arch/ia64/sn/io/sn2/pic.c - 1.2 arch/ia64/sn/io/sn2/shub.c - 1.2 arch/ia64/sn/io/sn2/shub_intr.c - 1.2 arch/ia64/sn/io/sn2/shuberror.c - 1.2 arch/ia64/sn/io/sn2/shubio.c - 1.2 arch/ia64/sn/io/sn2/xbow.c - 1.2 arch/ia64/sn/io/sn2/xtalk.c - 1.2 arch/ia64/sn/io/xswitch.c - 1.2 arch/ia64/sn/kernel/Makefile - 1.2 arch/ia64/sn/kernel/bte.c - 1.2 arch/ia64/sn/kernel/irq.c - 1.2 arch/ia64/sn/kernel/machvec.c - 1.2 arch/ia64/sn/kernel/mca.c - 1.2 arch/ia64/sn/kernel/probe.c - 1.2 arch/ia64/sn/kernel/setup.c - 1.2 arch/ia64/sn/kernel/sn2/Makefile - 1.2 arch/ia64/sn/kernel/sn2/cache.c - 1.2 arch/ia64/sn/kernel/sn2/sn2_smp.c - 1.2 arch/ia64/sn/kernel/sn2/sn_proc_fs.c - 1.2 arch/m68k/amiga/amisound.c - 1.2 arch/m68k/amiga/chipram.c - 1.2 arch/m68k/amiga/config.c - 1.2 arch/m68k/atari/hades-pci.c - 1.2 arch/m68k/bvme6000/rtc.c - 1.2 arch/m68k/kernel/head.S - 1.2 arch/m68k/kernel/traps.c - 1.2 arch/m68k/mac/config.c - 1.2 arch/m68k/mac/misc.c - 1.2 arch/m68k/math-emu/fp_arith.c - 1.2 arch/m68k/math-emu/fp_log.c - 1.2 arch/m68k/math-emu/multi_arith.h - 1.2 arch/m68k/mm/Makefile - 1.2 arch/m68k/mm/extable.c - 1.2 arch/m68k/mm/hwtest.c - 1.2 arch/m68k/mm/motorola.c - 1.2 arch/m68k/mvme16x/rtc.c - 1.2 arch/m68k/q40/q40ints.c - 1.2 arch/m68k/sun3/idprom.c - 1.2 arch/m68knommu/kernel/Makefile - 1.2 arch/m68knommu/kernel/time.c - 1.2 arch/m68knommu/lib/checksum.c - 1.2 arch/m68knommu/mm/Makefile - 1.2 arch/m68knommu/mm/extable.c - 1.2 arch/m68knommu/platform/5307/entry.S - 1.2 arch/mips/Kconfig - 1.3 arch/mips/mm/Makefile - 1.2 arch/mips/mm/extable.c - 1.2 arch/parisc/Kconfig - 1.3 arch/parisc/kernel/sys_parisc.c - 1.3 arch/parisc/mm/Makefile - 1.2 arch/parisc/mm/extable.c - 1.2 arch/ppc/Kconfig - 1.2 arch/ppc/boot/prep/Makefile - 1.2 arch/ppc/boot/prep/head.S - 1.2 arch/ppc/boot/prep/misc.c - 1.2 arch/ppc/kernel/Makefile - 1.2 arch/ppc/kernel/misc.S - 1.2 arch/ppc/kernel/module.c - 1.2 arch/ppc/kernel/ppc_ksyms.c - 1.3 arch/ppc/kernel/setup.c - 1.2 arch/ppc/kernel/signal.c - 1.2 arch/ppc/kernel/syscalls.c - 1.2 arch/ppc/mm/Makefile - 1.2 arch/ppc/mm/cachemap.c - 1.2 arch/ppc/mm/extable.c - 1.2 arch/ppc/platforms/mpc82xx.h - 1.2 arch/ppc64/Kconfig - 1.2 arch/ppc64/Makefile - 1.2 arch/ppc64/boot/ppc32-types.h - 1.2 arch/ppc64/kernel/HvCall.c - 1.2 arch/ppc64/kernel/ItLpQueue.c - 1.2 arch/ppc64/kernel/LparData.c - 1.2 arch/ppc64/kernel/Makefile - 1.2 arch/ppc64/kernel/XmPciLpEvent.c - 1.2 arch/ppc64/kernel/asm-offsets.c - 1.2 arch/ppc64/kernel/chrp_setup.c - 1.2 arch/ppc64/kernel/cputable.c - 1.2 arch/ppc64/kernel/eeh.c - 1.2 arch/ppc64/kernel/entry.S - 1.2 arch/ppc64/kernel/head.S - 1.2 arch/ppc64/kernel/htab.c - 1.2 arch/ppc64/kernel/iSeries_IoMmTable.c - 1.2 arch/ppc64/kernel/iSeries_IoMmTable.h - 1.2 arch/ppc64/kernel/iSeries_VpdInfo.c - 1.2 arch/ppc64/kernel/iSeries_irq.c - 1.2 arch/ppc64/kernel/iSeries_pci.c - 1.2 arch/ppc64/kernel/iSeries_pci_reset.c - 1.2 arch/ppc64/kernel/iSeries_proc.c - 1.2 arch/ppc64/kernel/iSeries_setup.c - 1.2 arch/ppc64/kernel/iSeries_setup.h - 1.2 arch/ppc64/kernel/idle.c - 1.2 arch/ppc64/kernel/irq.c - 1.3 arch/ppc64/kernel/mf.c - 1.2 arch/ppc64/kernel/mf_proc.c - 1.3 arch/ppc64/kernel/misc.S - 1.2 arch/ppc64/kernel/module.c - 1.2 arch/ppc64/kernel/nvram.c - 1.2 arch/ppc64/kernel/open_pic.c - 1.2 arch/ppc64/kernel/pSeries_htab.c - 1.2 arch/ppc64/kernel/pSeries_hvCall.S - 1.2 arch/ppc64/kernel/pSeries_lpar.c - 1.2 arch/ppc64/kernel/pSeries_pci.c - 1.2 arch/ppc64/kernel/pci.c - 1.2 arch/ppc64/kernel/pci_dma.c - 1.2 arch/ppc64/kernel/pci_dn.c - 1.2 arch/ppc64/kernel/ppc_ksyms.c - 1.2 arch/ppc64/kernel/proc_pmc.c - 1.3 arch/ppc64/kernel/proc_ppc64.c - 1.2 arch/ppc64/kernel/process.c - 1.2 arch/ppc64/kernel/prom.c - 1.2 arch/ppc64/kernel/ras.c - 1.2 arch/ppc64/kernel/rtas-proc.c - 1.3 arch/ppc64/kernel/rtas.c - 1.2 arch/ppc64/kernel/rtas_flash.c - 1.2 arch/ppc64/kernel/rtasd.c - 1.2 arch/ppc64/kernel/rtc.c - 1.2 arch/ppc64/kernel/scanlog.c - 1.3 arch/ppc64/kernel/setup.c - 1.2 arch/ppc64/kernel/signal.c - 1.2 arch/ppc64/kernel/signal32.c - 1.2 arch/ppc64/kernel/smp.c - 1.2 arch/ppc64/kernel/sys_ppc32.c - 1.2 arch/ppc64/kernel/syscalls.c - 1.2 arch/ppc64/kernel/time.c - 1.2 arch/ppc64/kernel/traps.c - 1.2 arch/ppc64/kernel/udbg.c - 1.2 arch/ppc64/kernel/vmlinux.lds.S - 1.2 arch/ppc64/kernel/xics.c - 1.2 arch/ppc64/mm/Makefile - 1.2 arch/ppc64/mm/extable.c - 1.2 arch/ppc64/mm/hugetlbpage.c - 1.3 arch/ppc64/mm/imalloc.c - 1.2 arch/ppc64/mm/init.c - 1.2 arch/ppc64/mm/numa.c - 1.2 arch/ppc64/xmon/xmon.c - 1.2 arch/s390/Kconfig - 1.2 arch/s390/defconfig - 1.2 arch/s390/kernel/compat_ioctl.c - 1.2 arch/s390/kernel/compat_linux.c - 1.2 arch/s390/kernel/compat_linux.h - 1.2 arch/s390/kernel/compat_signal.c - 1.2 arch/s390/kernel/compat_wrapper.S - 1.3 arch/s390/kernel/entry.S - 1.2 arch/s390/kernel/entry64.S - 1.2 arch/s390/kernel/head.S - 1.2 arch/s390/kernel/head64.S - 1.2 arch/s390/kernel/ptrace.c - 1.2 arch/s390/kernel/semaphore.c - 1.2 arch/s390/kernel/setup.c - 1.3 arch/s390/kernel/signal.c - 1.2 arch/s390/kernel/sys_s390.c - 1.2 arch/s390/kernel/syscalls.S - 1.3 arch/s390/kernel/traps.c - 1.2 arch/s390/kernel/vmlinux.lds.S - 1.2 arch/s390/lib/uaccess.S - 1.2 arch/s390/lib/uaccess64.S - 1.2 arch/s390/mm/Makefile - 1.2 arch/s390/mm/extable.c - 1.2 arch/s390/mm/fault.c - 1.2 arch/sh/Kconfig - 1.3 arch/sh/Makefile - 1.2 arch/sh/boards/adx/Makefile - 1.2 arch/sh/boards/adx/io.c - 1.2 arch/sh/boards/adx/mach.c - 1.2 arch/sh/boards/adx/setup.c - 1.2 arch/sh/boards/bigsur/Makefile - 1.2 arch/sh/boards/bigsur/io.c - 1.2 arch/sh/boards/bigsur/mach.c - 1.2 arch/sh/boards/bigsur/pci.c - 1.2 arch/sh/boards/bigsur/setup.c - 1.2 arch/sh/boards/cat68701/Makefile - 1.2 arch/sh/boards/cat68701/io.c - 1.2 arch/sh/boards/cat68701/mach.c - 1.2 arch/sh/boards/cat68701/setup.c - 1.2 arch/sh/boards/cqreek/Makefile - 1.2 arch/sh/boards/cqreek/io.c - 1.2 arch/sh/boards/cqreek/mach.c - 1.2 arch/sh/boards/cqreek/setup.c - 1.2 arch/sh/boards/dmida/mach.c - 1.2 arch/sh/boards/dreamcast/Makefile - 1.2 arch/sh/boards/dreamcast/io.c - 1.2 arch/sh/boards/dreamcast/mach.c - 1.2 arch/sh/boards/dreamcast/pci.c - 1.2 arch/sh/boards/dreamcast/setup.c - 1.2 arch/sh/boards/ec3104/Makefile - 1.2 arch/sh/boards/ec3104/mach.c - 1.2 arch/sh/boards/ec3104/setup.c - 1.2 arch/sh/boards/harp/mach.c - 1.2 arch/sh/boards/hp6xx/hp620/mach.c - 1.2 arch/sh/boards/hp6xx/hp680/mach.c - 1.2 arch/sh/boards/hp6xx/hp690/mach.c - 1.2 arch/sh/boards/mpc1211/Makefile - 1.2 arch/sh/boards/mpc1211/io.c - 1.2 arch/sh/boards/mpc1211/mach.c - 1.2 arch/sh/boards/mpc1211/pci.c - 1.2 arch/sh/boards/mpc1211/rtc.c - 1.2 arch/sh/boards/mpc1211/setup.c - 1.2 arch/sh/boards/overdrive/mach.c - 1.2 arch/sh/boards/saturn/Makefile - 1.2 arch/sh/boards/saturn/irq.c - 1.2 arch/sh/boards/saturn/mach.c - 1.2 arch/sh/boards/saturn/setup.c - 1.2 arch/sh/boards/saturn/smp.c - 1.2 arch/sh/boards/se/770x/io.c - 1.2 arch/sh/boards/se/770x/mach.c - 1.2 arch/sh/boards/se/7751/io.c - 1.2 arch/sh/boards/se/7751/mach.c - 1.2 arch/sh/boards/se/7751/pci.c - 1.2 arch/sh/boards/sh2000/Makefile - 1.2 arch/sh/boards/sh2000/io.c - 1.2 arch/sh/boards/sh2000/mach.c - 1.2 arch/sh/boards/sh2000/setup.c - 1.2 arch/sh/boot/compressed/Makefile - 1.2 arch/sh/boot/compressed/head.S - 1.2 arch/sh/cchips/hd6446x/hd64461/io.c - 1.2 arch/sh/cchips/hd6446x/hd64461/setup.c - 1.2 arch/sh/cchips/hd6446x/hd64465/io.c - 1.2 arch/sh/cchips/hd6446x/hd64465/setup.c - 1.2 arch/sh/configs/defconfig-adx - 1.2 arch/sh/configs/defconfig-cqreek - 1.2 arch/sh/configs/defconfig-dreamcast - 1.2 arch/sh/kernel/Makefile - 1.2 arch/sh/kernel/cpu/Makefile - 1.2 arch/sh/kernel/cpu/dma.c - 1.2 arch/sh/kernel/cpu/sh3/Makefile - 1.2 arch/sh/kernel/cpu/sh4/Makefile - 1.2 arch/sh/kernel/cpu/sh4/fpu.c - 1.2 arch/sh/kernel/cpu/sh4/pci-sh7751.c - 1.2 arch/sh/kernel/cpu/sh4/pci-st40.c - 1.2 arch/sh/kernel/cpu/sh4/pci-st40.h - 1.2 arch/sh/kernel/dma.c - 1.2 arch/sh/kernel/entry.S - 1.2 arch/sh/kernel/fpu.c - 1.2 arch/sh/kernel/head.S - 1.2 arch/sh/kernel/io.c - 1.2 arch/sh/kernel/irq.c - 1.3 arch/sh/kernel/kgdb_stub.c - 1.2 arch/sh/kernel/module.c - 1.2 arch/sh/kernel/pci-dma.c - 1.2 arch/sh/kernel/pci.c - 1.2 arch/sh/kernel/pci_auto.c - 1.2 arch/sh/kernel/pcibios.c - 1.2 arch/sh/kernel/process.c - 1.2 arch/sh/kernel/ptrace.c - 1.2 arch/sh/kernel/rtc.c - 1.2 arch/sh/kernel/setup.c - 1.2 arch/sh/kernel/sh_bios.c - 1.2 arch/sh/kernel/sh_ksyms.c - 1.2 arch/sh/kernel/signal.c - 1.2 arch/sh/kernel/sys_sh.c - 1.2 arch/sh/kernel/time.c - 1.2 arch/sh/kernel/traps.c - 1.2 arch/sh/lib/Makefile - 1.2 arch/sh/lib/div64.S - 1.2 arch/sh/lib/udivdi3.c - 1.2 arch/sh/mm/Makefile - 1.2 arch/sh/mm/__clear_user_page-sh4.S - 1.2 arch/sh/mm/__copy_user_page-sh4.S - 1.2 arch/sh/mm/cache-sh3.c - 1.2 arch/sh/mm/cache-sh4.c - 1.2 arch/sh/mm/clear_page.S - 1.2 arch/sh/mm/copy_page.S - 1.2 arch/sh/mm/extable.c - 1.2 arch/sh/mm/fault.c - 1.2 arch/sh/mm/init.c - 1.2 arch/sh/mm/ioremap.c - 1.2 arch/sh/mm/tlb-sh3.c - 1.2 arch/sh/tools/mach-types - 1.2 arch/sparc/Kconfig - 1.3 arch/sparc/kernel/irq.c - 1.3 arch/sparc/mm/extable.c - 1.2 arch/sparc/mm/fault.c - 1.3 arch/sparc/mm/srmmu.c - 1.3 arch/sparc64/Kconfig - 1.3 arch/sparc64/defconfig - 1.3 arch/sparc64/kernel/head.S - 1.2 arch/sparc64/kernel/pci_common.c - 1.2 arch/sparc64/kernel/smp.c - 1.2 arch/sparc64/kernel/sys_sparc32.c - 1.2 arch/sparc64/kernel/traps.c - 1.2 arch/sparc64/mm/extable.c - 1.2 arch/sparc64/mm/init.c - 1.2 arch/sparc64/prom/bootstr.c - 1.2 arch/um/Kconfig - 1.2 arch/x86_64/Kconfig - 1.3 arch/x86_64/Makefile - 1.2 arch/x86_64/defconfig - 1.3 arch/x86_64/ia32/ia32_binfmt.c - 1.2 arch/x86_64/ia32/ia32_signal.c - 1.3 arch/x86_64/ia32/ia32entry.S - 1.3 arch/x86_64/ia32/ptrace32.c - 1.2 arch/x86_64/ia32/sys_ia32.c - 1.3 arch/x86_64/kernel/acpi/sleep.c - 1.2 arch/x86_64/kernel/acpi/wakeup.S - 1.2 arch/x86_64/kernel/entry.S - 1.2 arch/x86_64/kernel/i387.c - 1.2 arch/x86_64/kernel/ldt.c - 1.2 arch/x86_64/kernel/pci-dma.c - 1.2 arch/x86_64/kernel/pci-gart.c - 1.3 arch/x86_64/kernel/process.c - 1.3 arch/x86_64/kernel/sys_x86_64.c - 1.2 arch/x86_64/kernel/time.c - 1.3 arch/x86_64/kernel/traps.c - 1.3 arch/x86_64/kernel/vmlinux.lds.S - 1.2 arch/x86_64/kernel/x8664_ksyms.c - 1.2 arch/x86_64/lib/thunk.S - 1.2 arch/x86_64/lib/usercopy.c - 1.2 arch/x86_64/mm/extable.c - 1.2 arch/x86_64/mm/fault.c - 1.3 arch/x86_64/mm/k8topology.c - 1.2 drivers/Kconfig - 1.2 drivers/acorn/char/i2c.c - 1.3 drivers/atm/atmdev_init.c - 1.2 drivers/atm/he.c - 1.2 drivers/atm/horizon.c - 1.2 drivers/atm/nicstar.c - 1.2 drivers/base/Makefile - 1.2 drivers/base/class.c - 1.2 drivers/base/core.c - 1.2 drivers/base/firmware_class.c - 1.3 drivers/block/Kconfig - 1.2 drivers/block/as-iosched.c - 1.2 drivers/block/elevator.c - 1.2 drivers/block/floppy.c - 1.3 drivers/block/floppy98.c - 1.3 drivers/block/ll_rw_blk.c - 1.3 drivers/block/loop.c - 1.2 drivers/block/paride/Kconfig - 1.2 drivers/bluetooth/Kconfig - 1.2 drivers/bluetooth/Makefile - 1.2 drivers/bluetooth/bluecard_cs.c - 1.2 drivers/bluetooth/bt3c_cs.c - 1.2 drivers/bluetooth/btuart_cs.c - 1.2 drivers/bluetooth/dtl1_cs.c - 1.2 drivers/bluetooth/hci_usb.c - 1.2 drivers/bluetooth/hci_usb.h - 1.2 drivers/cdrom/cdrom.c - 1.2 drivers/char/Kconfig - 1.2 drivers/char/Makefile - 1.2 drivers/char/drm/Kconfig - 1.2 drivers/char/efirtc.c - 1.2 drivers/char/genrtc.c - 1.2 drivers/char/hp600_keyb.c - 1.2 drivers/char/keyboard.c - 1.3 drivers/char/lp.c - 1.2 drivers/char/mem.c - 1.2 drivers/char/misc.c - 1.2 drivers/char/pcmcia/synclink_cs.c - 1.2 drivers/char/raw.c - 1.2 drivers/char/rtc.c - 1.2 drivers/char/sh-sci.c - 1.2 drivers/char/sh-sci.h - 1.2 drivers/char/sn_serial.c - 1.2 drivers/char/sysrq.c - 1.2 drivers/char/tty_io.c - 1.2 drivers/char/vt.c - 1.2 drivers/char/watchdog/acquirewdt.c - 1.2 drivers/char/watchdog/advantechwdt.c - 1.2 drivers/char/watchdog/alim1535_wdt.c - 1.2 drivers/char/watchdog/alim7101_wdt.c - 1.2 drivers/char/watchdog/amd7xx_tco.c - 1.2 drivers/char/watchdog/cpu5wdt.c - 1.2 drivers/char/watchdog/eurotechwdt.c - 1.2 drivers/char/watchdog/i810-tco.c - 1.3 drivers/char/watchdog/ib700wdt.c - 1.3 drivers/char/watchdog/indydog.c - 1.3 drivers/char/watchdog/machzwd.c - 1.3 drivers/char/watchdog/mixcomwd.c - 1.3 drivers/char/watchdog/pcwd.c - 1.3 drivers/char/watchdog/sa1100_wdt.c - 1.3 drivers/char/watchdog/sbc60xxwdt.c - 1.2 drivers/char/watchdog/sc1200wdt.c - 1.2 drivers/char/watchdog/scx200_wdt.c - 1.2 drivers/char/watchdog/shwdt.c - 1.2 drivers/char/watchdog/softdog.c - 1.3 drivers/char/watchdog/w83877f_wdt.c - 1.2 drivers/char/watchdog/wafer5823wdt.c - 1.2 drivers/char/watchdog/wdt.c - 1.3 drivers/char/watchdog/wdt285.c - 1.2 drivers/char/watchdog/wdt977.c - 1.2 drivers/char/watchdog/wdt_pci.c - 1.2 drivers/i2c/Kconfig - 1.2 drivers/i2c/algos/Kconfig - 1.2 drivers/i2c/algos/i2c-algo-pcf.h - 1.2 drivers/i2c/busses/Kconfig - 1.3 drivers/i2c/busses/Makefile - 1.2 drivers/i2c/busses/i2c-ali1535.c - 1.2 drivers/i2c/busses/i2c-ali15x3.c - 1.2 drivers/i2c/busses/i2c-amd756.c - 1.3 drivers/i2c/busses/i2c-amd8111.c - 1.3 drivers/i2c/busses/i2c-elektor.c - 1.2 drivers/i2c/busses/i2c-elv.c - 1.2 drivers/i2c/busses/i2c-frodo.c - 1.2 drivers/i2c/busses/i2c-i801.c - 1.2 drivers/i2c/busses/i2c-i810.c - 1.2 drivers/i2c/busses/i2c-ibm_iic.c - 1.3 drivers/i2c/busses/i2c-iop3xx.c - 1.2 drivers/i2c/busses/i2c-isa.c - 1.2 drivers/i2c/busses/i2c-ite.c - 1.2 drivers/i2c/busses/i2c-keywest.c - 1.2 drivers/i2c/busses/i2c-nforce2.c - 1.2 drivers/i2c/busses/i2c-philips-par.c - 1.2 drivers/i2c/busses/i2c-piix4.c - 1.3 drivers/i2c/busses/i2c-prosavage.c - 1.2 drivers/i2c/busses/i2c-rpx.c - 1.2 drivers/i2c/busses/i2c-savage4.c - 1.3 drivers/i2c/busses/i2c-sis5595.c - 1.2 drivers/i2c/busses/i2c-sis630.c - 1.2 drivers/i2c/busses/i2c-sis96x.c - 1.2 drivers/i2c/busses/i2c-velleman.c - 1.3 drivers/i2c/busses/i2c-via.c - 1.2 drivers/i2c/busses/i2c-viapro.c - 1.3 drivers/i2c/busses/i2c-voodoo3.c - 1.2 drivers/i2c/busses/scx200_acb.c - 1.2 drivers/i2c/busses/scx200_i2c.c - 1.2 drivers/i2c/chips/Kconfig - 1.3 drivers/i2c/chips/Makefile - 1.3 drivers/i2c/chips/adm1021.c - 1.2 drivers/i2c/chips/eeprom.c - 1.2 drivers/i2c/chips/it87.c - 1.3 drivers/i2c/chips/lm75.c - 1.3 drivers/i2c/chips/lm78.c - 1.3 drivers/i2c/chips/lm85.c - 1.2 drivers/i2c/chips/via686a.c - 1.3 drivers/i2c/chips/w83781d.c - 1.3 drivers/i2c/i2c-core.c - 1.3 drivers/i2c/i2c-dev.c - 1.3 drivers/i2c/i2c-sensor.c - 1.2 drivers/ide/Kconfig - 1.3 drivers/ide/Makefile - 1.2 drivers/ide/ide-cd.c - 1.3 drivers/ide/ide-cd.h - 1.2 drivers/ide/ide-disk.c - 1.2 drivers/ide/ide-taskfile.c - 1.2 drivers/ide/ide.c - 1.3 drivers/ide/legacy/buddha.c - 1.2 drivers/ide/legacy/gayle.c - 1.2 drivers/ide/legacy/ide-cs.c - 1.2 drivers/ide/legacy/pdc4030.c - 1.2 drivers/ide/pci/amd74xx.c - 1.2 drivers/ide/pci/pdc202xx_new.c - 1.2 drivers/ide/pci/pdc202xx_old.c - 1.2 drivers/ide/pci/siimage.c - 1.2 drivers/ieee1394/Kconfig - 1.3 drivers/ieee1394/amdtp.c - 1.2 drivers/ieee1394/cmp.c - 1.2 drivers/ieee1394/csr.c - 1.2 drivers/ieee1394/dv1394.c - 1.2 drivers/ieee1394/eth1394.c - 1.3 drivers/ieee1394/highlevel.c - 1.3 drivers/ieee1394/highlevel.h - 1.3 drivers/ieee1394/hosts.c - 1.3 drivers/ieee1394/hosts.h - 1.3 drivers/ieee1394/ieee1394_core.c - 1.3 drivers/ieee1394/ieee1394_core.h - 1.3 drivers/ieee1394/ohci1394.c - 1.3 drivers/ieee1394/oui.db - 1.3 drivers/ieee1394/raw1394.c - 1.3 drivers/ieee1394/sbp2.c - 1.3 drivers/ieee1394/video1394.c - 1.3 drivers/input/evdev.c - 1.2 drivers/input/input.c - 1.3 drivers/input/joydev.c - 1.3 drivers/input/keyboard/98kbd.c - 1.2 drivers/input/keyboard/amikbd.c - 1.2 drivers/input/keyboard/atkbd.c - 1.3 drivers/input/keyboard/maple_keyb.c - 1.2 drivers/input/keyboard/newtonkbd.c - 1.2 drivers/input/mouse/98busmouse.c - 1.2 drivers/input/mouse/Kconfig - 1.3 drivers/input/mouse/inport.c - 1.2 drivers/input/mouse/logibm.c - 1.2 drivers/input/mouse/logips2pp.c - 1.3 drivers/input/mouse/psmouse-base.c - 1.3 drivers/input/mouse/psmouse.h - 1.3 drivers/input/mouse/synaptics.c - 1.3 drivers/input/mousedev.c - 1.2 drivers/input/serio/i8042.c - 1.3 drivers/input/tsdev.c - 1.2 drivers/isdn/Kconfig - 1.2 drivers/isdn/Makefile - 1.2 drivers/isdn/eicon/Divas_mod.c - 1.2 drivers/isdn/eicon/Kconfig - 1.3 drivers/isdn/eicon/Makefile - 1.2 drivers/isdn/eicon/adapter.h - 1.2 drivers/isdn/eicon/bri.c - 1.2 drivers/isdn/eicon/common.c - 1.2 drivers/isdn/eicon/constant.h - 1.2 drivers/isdn/eicon/divalog.h - 1.2 drivers/isdn/eicon/divas.h - 1.2 drivers/isdn/eicon/dsp_defs.h - 1.2 drivers/isdn/eicon/dspdids.h - 1.2 drivers/isdn/eicon/eicon.h - 1.2 drivers/isdn/eicon/eicon_dsp.h - 1.2 drivers/isdn/eicon/eicon_idi.c - 1.2 drivers/isdn/eicon/eicon_idi.h - 1.2 drivers/isdn/eicon/eicon_io.c - 1.2 drivers/isdn/eicon/eicon_isa.c - 1.2 drivers/isdn/eicon/eicon_isa.h - 1.2 drivers/isdn/eicon/eicon_mod.c - 1.3 drivers/isdn/eicon/eicon_pci.c - 1.2 drivers/isdn/eicon/eicon_pci.h - 1.2 drivers/isdn/eicon/fourbri.c - 1.2 drivers/isdn/eicon/fpga.c - 1.2 drivers/isdn/eicon/idi.c - 1.2 drivers/isdn/eicon/idi.h - 1.2 drivers/isdn/eicon/kprintf.c - 1.2 drivers/isdn/eicon/lincfg.c - 1.2 drivers/isdn/eicon/linchr.c - 1.2 drivers/isdn/eicon/linio.c - 1.2 drivers/isdn/eicon/linsys.c - 1.2 drivers/isdn/eicon/log.c - 1.2 drivers/isdn/eicon/pc.h - 1.2 drivers/isdn/eicon/pc_maint.h - 1.2 drivers/isdn/eicon/pr_pc.h - 1.2 drivers/isdn/eicon/pri.c - 1.2 drivers/isdn/eicon/sys.h - 1.2 drivers/isdn/eicon/uxio.h - 1.2 drivers/isdn/eicon/xlog.c - 1.2 drivers/isdn/hardware/Kconfig - 1.2 drivers/isdn/hardware/avm/avm_cs.c - 1.2 drivers/isdn/hardware/eicon/capifunc.c - 1.2 drivers/isdn/hardware/eicon/divamnt.c - 1.2 drivers/isdn/hardware/eicon/mntfunc.c - 1.2 drivers/isdn/hardware/eicon/platform.h - 1.2 drivers/isdn/hardware/eicon/s_bri.c - 1.2 drivers/isdn/hardware/eicon/um_idi.c - 1.2 drivers/isdn/hardware/eicon/xdi_adapter.h - 1.2 drivers/isdn/hisax/avma1_cs.c - 1.2 drivers/isdn/hisax/elsa_cs.c - 1.2 drivers/isdn/hisax/sedlbauer_cs.c - 1.2 drivers/macintosh/adb-iop.c - 1.2 drivers/macintosh/adbhid.c - 1.2 drivers/macintosh/via-macii.c - 1.2 drivers/md/Kconfig - 1.3 drivers/md/Makefile - 1.2 drivers/md/md.c - 1.2 drivers/md/raid5.c - 1.3 drivers/media/Kconfig - 1.2 drivers/media/common/Makefile - 1.2 drivers/media/common/saa7146_core.c - 1.3 drivers/media/common/saa7146_fops.c - 1.3 drivers/media/common/saa7146_hlp.c - 1.3 drivers/media/common/saa7146_vbi.c - 1.3 drivers/media/common/saa7146_video.c - 1.3 drivers/media/dvb/dvb-core/dvb_demux.c - 1.3 drivers/media/dvb/dvb-core/dvb_frontend.c - 1.2 drivers/media/dvb/frontends/ves1x93.c - 1.3 drivers/media/dvb/ttpci/Makefile - 1.3 drivers/media/dvb/ttpci/av7110.c - 1.3 drivers/media/dvb/ttpci/av7110.h - 1.3 drivers/media/dvb/ttpci/av7110_ipack.c - 1.2 drivers/media/dvb/ttpci/av7110_ipack.h - 1.2 drivers/media/dvb/ttpci/av7110_ir.c - 1.2 drivers/media/dvb/ttpci/budget-patch.c - 1.2 drivers/media/dvb/ttusb-budget/Kconfig - 1.2 drivers/media/dvb/ttusb-dec/ttusb_dec.c - 1.3 drivers/media/video/Kconfig - 1.2 drivers/media/video/Makefile - 1.2 drivers/media/video/bt848.h - 1.2 drivers/media/video/bttv-cards.c - 1.2 drivers/media/video/bttv-driver.c - 1.2 drivers/media/video/bttv-if.c - 1.2 drivers/media/video/bttv-risc.c - 1.2 drivers/media/video/bttv-vbi.c - 1.2 drivers/media/video/bttv.h - 1.2 drivers/media/video/bttvp.h - 1.2 drivers/media/video/msp3400.c - 1.2 drivers/media/video/saa7134/Makefile - 1.2 drivers/media/video/saa7134/saa6752hs.c - 1.2 drivers/media/video/saa7134/saa7134-cards.c - 1.2 drivers/media/video/saa7134/saa7134-core.c - 1.2 drivers/media/video/saa7134/saa7134-oss.c - 1.2 drivers/media/video/saa7134/saa7134-ts.c - 1.2 drivers/media/video/saa7134/saa7134-tvaudio.c - 1.2 drivers/media/video/saa7134/saa7134-vbi.c - 1.2 drivers/media/video/saa7134/saa7134-video.c - 1.2 drivers/media/video/saa7134/saa7134.h - 1.2 drivers/media/video/saa7146.h - 1.2 drivers/media/video/tda7432.c - 1.2 drivers/media/video/tda9875.c - 1.2 drivers/media/video/tda9887.c - 1.2 drivers/media/video/tuner.c - 1.2 drivers/media/video/tvaudio.c - 1.2 drivers/media/video/tvmixer.c - 1.2 drivers/media/video/v4l1-compat.c - 1.2 drivers/media/video/v4l2-common.c - 1.2 drivers/media/video/video-buf.c - 1.3 drivers/media/video/videodev.c - 1.2 drivers/media/video/w9966.c - 1.2 drivers/message/fusion/mptbase.h - 1.3 drivers/message/fusion/mptscsih.c - 1.3 drivers/message/i2o/Kconfig - 1.2 drivers/mtd/maps/pcmciamtd.c - 1.2 drivers/net/3c527.c - 1.2 drivers/net/3c527.h - 1.2 drivers/net/3c59x.c - 1.2 drivers/net/68360enet.c - 1.2 drivers/net/8139cp.c - 1.2 drivers/net/Kconfig - 1.2 drivers/net/Makefile - 1.2 drivers/net/dummy.c - 1.2 drivers/net/hamradio/bpqether.c - 1.2 drivers/net/irda/Kconfig - 1.2 drivers/net/irda/Makefile - 1.2 drivers/net/irda/actisys-sir.c - 1.2 drivers/net/irda/esi-sir.c - 1.2 drivers/net/irda/sir-dev.h - 1.2 drivers/net/irda/sir_core.c - 1.2 drivers/net/irda/sir_dev.c - 1.2 drivers/net/irda/sir_dongle.c - 1.2 drivers/net/irda/sir_kthread.c - 1.2 drivers/net/irda/tekram-sir.c - 1.2 drivers/net/natsemi.c - 1.2 drivers/net/ne2k-pci.c - 1.2 drivers/net/pcmcia/3c574_cs.c - 1.3 drivers/net/pcmcia/3c589_cs.c - 1.2 drivers/net/pcmcia/Kconfig - 1.2 drivers/net/pcmcia/axnet_cs.c - 1.2 drivers/net/pcmcia/com20020_cs.c - 1.2 drivers/net/pcmcia/fmvj18x_cs.c - 1.2 drivers/net/pcmcia/ibmtr_cs.c - 1.2 drivers/net/pcmcia/nmclan_cs.c - 1.2 drivers/net/pcmcia/pcnet_cs.c - 1.3 drivers/net/pcmcia/smc91c92_cs.c - 1.2 drivers/net/pcmcia/xirc2ps_cs.c - 1.2 drivers/net/ppp_async.c - 1.2 drivers/net/pppoe.c - 1.3 drivers/net/sk98lin/Makefile - 1.2 drivers/net/sk98lin/h/skcsum.h - 1.2 drivers/net/sk98lin/h/skdrv1st.h - 1.2 drivers/net/sk98lin/h/skdrv2nd.h - 1.2 drivers/net/sk98lin/h/skgehw.h - 1.2 drivers/net/sk98lin/h/skgehwt.h - 1.2 drivers/net/sk98lin/h/skgei2c.h - 1.2 drivers/net/sk98lin/h/skgeinit.h - 1.2 drivers/net/sk98lin/h/skgepnmi.h - 1.2 drivers/net/sk98lin/h/ski2c.h - 1.2 drivers/net/sk98lin/h/skqueue.h - 1.2 drivers/net/sk98lin/h/sktimer.h - 1.2 drivers/net/sk98lin/h/sktypes.h - 1.2 drivers/net/sk98lin/h/skversion.h - 1.2 drivers/net/sk98lin/h/xmac_ii.h - 1.2 drivers/net/sk98lin/skcsum.c - 1.2 drivers/net/sk98lin/skdim.c - 1.2 drivers/net/sk98lin/skge.c - 1.2 drivers/net/sk98lin/skgehwt.c - 1.2 drivers/net/sk98lin/skgeinit.c - 1.2 drivers/net/sk98lin/skgemib.c - 1.2 drivers/net/sk98lin/skgepnmi.c - 1.2 drivers/net/sk98lin/skgesirq.c - 1.2 drivers/net/sk98lin/ski2c.c - 1.2 drivers/net/sk98lin/sklm80.c - 1.2 drivers/net/sk98lin/skproc.c - 1.2 drivers/net/sk98lin/skqueue.c - 1.2 drivers/net/sk98lin/sktimer.c - 1.2 drivers/net/sk98lin/skxmac2.c - 1.2 drivers/net/starfire.c - 1.2 drivers/net/stnic.c - 1.2 drivers/net/tokenring/olympic.c - 1.2 drivers/net/tokenring/smctr.c - 1.2 drivers/net/tulip/xircom_cb.c - 1.2 drivers/net/wan/Kconfig - 1.3 drivers/net/wan/Makefile - 1.2 drivers/net/wan/farsync.c - 1.2 drivers/net/wan/hd64572.h - 1.2 drivers/net/wan/lapbether.c - 1.2 drivers/net/wan/pc300_drv.c - 1.2 drivers/net/wireless/Kconfig - 1.2 drivers/net/wireless/airo.c - 1.2 drivers/net/wireless/airo_cs.c - 1.2 drivers/net/wireless/atmel.c - 1.3 drivers/net/wireless/atmel_cs.c - 1.2 drivers/net/wireless/netwave_cs.c - 1.2 drivers/net/wireless/orinoco_cs.c - 1.2 drivers/net/wireless/orinoco_pci.c - 1.2 drivers/net/wireless/ray_cs.c - 1.2 drivers/net/wireless/wavelan_cs.c - 1.2 drivers/net/wireless/wl3501_cs.c - 1.2 drivers/oprofile/oprofile_stats.c - 1.2 drivers/parport/parport_cs.c - 1.2 drivers/pci/pci.ids - 1.3 drivers/pci/quirks.c - 1.2 drivers/pcmcia/cs.c - 1.3 drivers/pcmcia/ds.c - 1.2 drivers/pnp/Kconfig - 1.2 drivers/s390/block/dasd.c - 1.2 drivers/s390/block/dasd_3990_erp.c - 1.2 drivers/s390/block/dasd_devmap.c - 1.2 drivers/s390/block/dasd_diag.c - 1.2 drivers/s390/block/dasd_eckd.c - 1.2 drivers/s390/block/dasd_fba.c - 1.2 drivers/s390/block/dasd_genhd.c - 1.2 drivers/s390/block/dasd_int.h - 1.2 drivers/s390/block/dasd_proc.c - 1.2 drivers/s390/char/Makefile - 1.2 drivers/s390/char/con3215.c - 1.2 drivers/s390/char/sclp_con.c - 1.2 drivers/s390/char/sclp_rw.c - 1.2 drivers/s390/char/sclp_rw.h - 1.2 drivers/s390/char/sclp_tty.c - 1.2 drivers/s390/char/tape.h - 1.2 drivers/s390/char/tape_34xx.c - 1.2 drivers/s390/char/tape_block.c - 1.2 drivers/s390/char/tape_char.c - 1.2 drivers/s390/char/tape_core.c - 1.2 drivers/s390/char/tape_proc.c - 1.2 drivers/s390/char/tape_std.c - 1.2 drivers/s390/char/tape_std.h - 1.2 drivers/s390/char/tuball.c - 1.2 drivers/s390/char/tubfs.c - 1.2 drivers/s390/char/tubio.h - 1.2 drivers/s390/char/tubtty.c - 1.2 drivers/s390/char/tubttyaid.c - 1.2 drivers/s390/char/tubttybld.c - 1.2 drivers/s390/char/tubttyrcl.c - 1.2 drivers/s390/char/tubttyscl.c - 1.2 drivers/s390/char/tubttysiz.c - 1.2 drivers/s390/cio/blacklist.c - 1.2 drivers/s390/cio/ccwgroup.c - 1.2 drivers/s390/cio/chsc.c - 1.2 drivers/s390/cio/chsc.h - 1.2 drivers/s390/cio/cio.c - 1.2 drivers/s390/cio/cio.h - 1.2 drivers/s390/cio/css.c - 1.2 drivers/s390/cio/css.h - 1.2 drivers/s390/cio/device.c - 1.2 drivers/s390/cio/device.h - 1.2 drivers/s390/cio/device_fsm.c - 1.2 drivers/s390/cio/device_id.c - 1.2 drivers/s390/cio/device_ops.c - 1.2 drivers/s390/cio/device_pgid.c - 1.2 drivers/s390/cio/device_status.c - 1.2 drivers/s390/cio/qdio.c - 1.2 drivers/s390/cio/qdio.h - 1.2 drivers/s390/net/ctcmain.c - 1.2 drivers/s390/net/ctctty.c - 1.2 drivers/s390/net/cu3088.c - 1.2 drivers/s390/net/fsm.c - 1.2 drivers/s390/net/iucv.c - 1.2 drivers/s390/net/iucv.h - 1.2 drivers/s390/net/lcs.c - 1.2 drivers/s390/net/netiucv.c - 1.2 drivers/s390/net/qeth.c - 1.2 drivers/s390/net/qeth.h - 1.2 drivers/s390/net/qeth_mpc.h - 1.2 drivers/s390/s390mach.c - 1.2 drivers/s390/scsi/zfcp_aux.c - 1.2 drivers/s390/scsi/zfcp_ccw.c - 1.2 drivers/s390/scsi/zfcp_def.h - 1.2 drivers/s390/scsi/zfcp_erp.c - 1.2 drivers/s390/scsi/zfcp_ext.h - 1.2 drivers/s390/scsi/zfcp_fsf.c - 1.2 drivers/s390/scsi/zfcp_fsf.h - 1.2 drivers/s390/scsi/zfcp_qdio.c - 1.2 drivers/s390/scsi/zfcp_scsi.c - 1.2 drivers/s390/scsi/zfcp_sysfs_adapter.c - 1.2 drivers/s390/scsi/zfcp_sysfs_port.c - 1.2 drivers/s390/scsi/zfcp_sysfs_unit.c - 1.2 drivers/sbus/char/rtc.c - 1.2 drivers/scsi/53c7xx.c - 1.2 drivers/scsi/53c7xx.h - 1.2 drivers/scsi/Kconfig - 1.3 drivers/scsi/Makefile - 1.2 drivers/scsi/NCR53C9x.h - 1.2 drivers/scsi/aacraid/aachba.c - 1.3 drivers/scsi/aacraid/aacraid.h - 1.3 drivers/scsi/aacraid/linit.c - 1.3 drivers/scsi/aha152x.c - 1.3 drivers/scsi/aha1542.c - 1.2 drivers/scsi/aic7xxx/Makefile - 1.3 drivers/scsi/aic7xxx/aic79xx_osm.c - 1.3 drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.3 drivers/scsi/aic7xxx/aic7xxx_osm_pci.c - 1.3 drivers/scsi/aic7xxx/aicasm/Makefile - 1.2 drivers/scsi/aic7xxx_old/aic7xxx_proc.c - 1.2 drivers/scsi/amiga7xx.c - 1.2 drivers/scsi/atp870u.c - 1.2 drivers/scsi/atp870u.h - 1.2 drivers/scsi/bvme6000.c - 1.2 drivers/scsi/g_NCR5380.c - 1.2 drivers/scsi/ide-scsi.c - 1.2 drivers/scsi/ini9100u.c - 1.3 drivers/scsi/inia100.c - 1.3 drivers/scsi/ips.c - 1.2 drivers/scsi/ips.h - 1.2 drivers/scsi/mac_esp.c - 1.2 drivers/scsi/mac_scsi.c - 1.2 drivers/scsi/megaraid.c - 1.3 drivers/scsi/mvme16x.c - 1.2 drivers/scsi/nsp32.h - 1.2 drivers/scsi/nsp32_io.h - 1.2 drivers/scsi/pcmcia/aha152x_stub.c - 1.2 drivers/scsi/pcmcia/fdomain_stub.c - 1.2 drivers/scsi/pcmcia/nsp_cs.c - 1.2 drivers/scsi/pcmcia/nsp_cs.h - 1.2 drivers/scsi/pcmcia/qlogic_stub.c - 1.2 drivers/scsi/qla1280.c - 1.2 drivers/scsi/qla1280.h - 1.2 drivers/scsi/qlogicpti.c - 1.3 drivers/scsi/qlogicpti.h - 1.2 drivers/scsi/sata_sil.c - 1.3 drivers/scsi/sata_svw.c - 1.3 drivers/scsi/scsi.c - 1.3 drivers/scsi/scsi_error.c - 1.3 drivers/scsi/scsi_scan.c - 1.2 drivers/scsi/scsi_sysfs.c - 1.2 drivers/scsi/sr.c - 1.2 drivers/scsi/sym53c8xx_2/sym_glue.c - 1.3 drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.3 drivers/scsi/sym53c8xx_2/sym_misc.c - 1.2 drivers/serial/8250_acpi.c - 1.2 drivers/serial/8250_hcdp.c - 1.2 drivers/serial/8250_pnp.c - 1.3 drivers/serial/Kconfig - 1.2 drivers/serial/serial_core.c - 1.3 drivers/serial/serial_cs.c - 1.2 drivers/serial/sunzilog.c - 1.3 drivers/telephony/ixj_pcmcia.c - 1.2 drivers/usb/Makefile - 1.3 drivers/usb/core/buffer.c - 1.2 drivers/usb/core/driverfs.c - 1.2 drivers/usb/core/urb.c - 1.2 drivers/usb/gadget/Kconfig - 1.2 drivers/usb/gadget/Makefile - 1.2 drivers/usb/host/ehci-dbg.c - 1.2 drivers/usb/host/ehci-hcd.c - 1.2 drivers/usb/host/ehci-mem.c - 1.2 drivers/usb/host/ehci-q.c - 1.2 drivers/usb/host/ehci-sched.c - 1.2 drivers/usb/host/ehci.h - 1.2 drivers/usb/host/uhci-hcd.c - 1.3 drivers/usb/input/aiptek.c - 1.2 drivers/usb/input/hid-core.c - 1.3 drivers/usb/input/hid-ff.c - 1.2 drivers/usb/input/hid-input.c - 1.2 drivers/usb/input/hid-lgff.c - 1.2 drivers/usb/input/hid.h - 1.2 drivers/usb/input/hiddev.c - 1.3 drivers/usb/input/kbtab.c - 1.2 drivers/usb/input/powermate.c - 1.2 drivers/usb/input/usbkbd.c - 1.2 drivers/usb/input/usbmouse.c - 1.2 drivers/usb/input/wacom.c - 1.2 drivers/usb/input/xpad.c - 1.2 drivers/usb/media/Kconfig - 1.3 drivers/usb/misc/Kconfig - 1.3 drivers/usb/misc/Makefile - 1.3 drivers/usb/net/usbnet.c - 1.3 drivers/usb/serial/cyberjack.c - 1.3 drivers/usb/serial/ftdi_sio.c - 1.3 drivers/usb/serial/ftdi_sio.h - 1.3 drivers/usb/serial/ir-usb.c - 1.2 drivers/usb/serial/mct_u232.c - 1.3 drivers/usb/serial/mct_u232.h - 1.3 drivers/usb/serial/pl2303.c - 1.3 drivers/usb/serial/pl2303.h - 1.3 drivers/usb/serial/visor.c - 1.3 drivers/usb/serial/visor.h - 1.3 drivers/usb/serial/whiteheat.c - 1.2 drivers/usb/storage/datafab.c - 1.3 drivers/usb/storage/jumpshot.c - 1.3 drivers/usb/storage/scsiglue.c - 1.3 drivers/usb/storage/scsiglue.h - 1.2 drivers/usb/storage/sddr09.c - 1.3 drivers/usb/storage/sddr55.c - 1.3 drivers/usb/storage/shuttle_usbat.c - 1.3 drivers/usb/storage/transport.c - 1.3 drivers/usb/storage/unusual_devs.h - 1.3 drivers/usb/usb-skeleton.c - 1.2 drivers/video/Kconfig - 1.2 drivers/video/Makefile - 1.2 drivers/video/aty/aty128fb.c - 1.2 drivers/video/cirrusfb.c - 1.3 drivers/video/console/Kconfig - 1.2 drivers/video/console/Makefile - 1.2 drivers/video/console/font_acorn_8x8.c - 1.2 drivers/video/fbmem.c - 1.2 drivers/video/logo/Makefile - 1.2 drivers/video/macfb.c - 1.2 drivers/video/pvr2fb.c - 1.2 drivers/video/radeonfb.c - 1.2 drivers/video/sa1100fb.c - 1.2 drivers/video/tridentfb.c - 1.2 drivers/zorro/Makefile - 1.2 drivers/zorro/proc.c - 1.2 drivers/zorro/zorro.c - 1.2 fs/afs/callback.c - 1.2 fs/afs/cell.c - 1.2 fs/afs/cell.h - 1.2 fs/afs/cmservice.c - 1.2 fs/afs/cmservice.h - 1.2 fs/afs/dir.c - 1.2 fs/afs/file.c - 1.2 fs/afs/fsclient.c - 1.2 fs/afs/fsclient.h - 1.2 fs/afs/inode.c - 1.2 fs/afs/internal.h - 1.2 fs/afs/kafsasyncd.c - 1.2 fs/afs/kafsasyncd.h - 1.2 fs/afs/kafstimod.c - 1.2 fs/afs/kafstimod.h - 1.2 fs/afs/main.c - 1.2 fs/afs/mntpt.c - 1.2 fs/afs/proc.c - 1.2 fs/afs/server.c - 1.2 fs/afs/server.h - 1.2 fs/afs/super.c - 1.2 fs/afs/types.h - 1.2 fs/afs/vlclient.c - 1.2 fs/afs/vlclient.h - 1.2 fs/afs/vlocation.c - 1.2 fs/afs/vnode.c - 1.2 fs/afs/vnode.h - 1.2 fs/afs/volume.c - 1.2 fs/binfmt_elf.c - 1.3 fs/bio.c - 1.2 fs/block_dev.c - 1.2 fs/buffer.c - 1.3 fs/coda/file.c - 1.2 fs/compat_ioctl.c - 1.3 fs/cramfs/inode.c - 1.2 fs/devfs/base.c - 1.2 fs/devpts/xattr_security.c - 1.2 fs/dnotify.c - 1.2 fs/dquot.c - 1.3 fs/eventpoll.c - 1.2 fs/exec.c - 1.3 fs/ext2/balloc.c - 1.2 fs/ext2/ialloc.c - 1.2 fs/ext2/inode.c - 1.2 fs/ext2/super.c - 1.2 fs/ext2/xattr_security.c - 1.2 fs/ext3/ialloc.c - 1.2 fs/ext3/inode.c - 1.2 fs/ext3/super.c - 1.3 fs/ext3/xattr_security.c - 1.2 fs/fcntl.c - 1.2 fs/file_table.c - 1.3 fs/freevxfs/vxfs_super.c - 1.2 fs/fs-writeback.c - 1.2 fs/hugetlbfs/inode.c - 1.2 fs/intermezzo/file.c - 1.2 fs/intermezzo/intermezzo_fs.h - 1.2 fs/intermezzo/journal.c - 1.2 fs/intermezzo/presto.c - 1.2 fs/intermezzo/vfs.c - 1.2 fs/ioctl.c - 1.2 fs/jbd/transaction.c - 1.2 fs/jffs/intrep.c - 1.2 fs/jfs/inode.c - 1.2 fs/jfs/super.c - 1.2 fs/jfs/xattr.c - 1.2 fs/libfs.c - 1.2 fs/locks.c - 1.3 fs/nfs/dir.c - 1.2 fs/nfs/file.c - 1.2 fs/nfs/inode.c - 1.2 fs/nfs/write.c - 1.2 fs/nfsd/nfsfh.c - 1.2 fs/nfsd/nfsxdr.c - 1.2 fs/nfsd/vfs.c - 1.2 fs/ntfs/ChangeLog - 1.2 fs/ntfs/Makefile - 1.2 fs/ntfs/inode.c - 1.2 fs/open.c - 1.2 fs/pipe.c - 1.3 fs/proc/base.c - 1.3 fs/proc/proc_devtree.c - 1.2 fs/proc/proc_misc.c - 1.3 fs/proc/task_mmu.c - 1.3 fs/read_write.c - 1.2 fs/reiserfs/file.c - 1.2 fs/reiserfs/inode.c - 1.2 fs/reiserfs/journal.c - 1.3 fs/smbfs/file.c - 1.2 fs/smbfs/proc.c - 1.2 fs/stat.c - 1.3 include/asm-alpha/elf.h - 1.2 include/asm-alpha/floppy.h - 1.2 include/asm-alpha/processor.h - 1.2 include/asm-alpha/smp.h - 1.2 include/asm-alpha/socket.h - 1.2 include/asm-alpha/topology.h - 1.2 include/asm-arm/arch-ebsa285/io.h - 1.2 include/asm-arm/arch-nexuspci/io.h - 1.2 include/asm-arm/arch-sa1100/keyboard.h - 1.2 include/asm-arm/mach/arch.h - 1.2 include/asm-arm/socket.h - 1.2 include/asm-arm26/socket.h - 1.2 include/asm-cris/arch-v10/byteorder.h - 1.2 include/asm-cris/socket.h - 1.2 include/asm-generic/percpu.h - 1.2 include/asm-generic/pgtable.h - 1.2 include/asm-h8300/socket.h - 1.2 include/asm-i386/byteorder.h - 1.2 include/asm-i386/floppy.h - 1.2 include/asm-i386/genapic.h - 1.2 include/asm-i386/hpet.h - 1.2 include/asm-i386/mach-bigsmp/mach_apic.h - 1.2 include/asm-i386/mach-default/mach_apic.h - 1.3 include/asm-i386/mach-es7000/mach_apic.h - 1.3 include/asm-i386/mach-generic/mach_apic.h - 1.2 include/asm-i386/mach-numaq/mach_apic.h - 1.2 include/asm-i386/mach-summit/mach_apic.h - 1.2 include/asm-i386/mach-visws/mach_apic.h - 1.2 include/asm-i386/pgtable.h - 1.2 include/asm-i386/smp.h - 1.2 include/asm-i386/socket.h - 1.2 include/asm-ia64/acpi.h - 1.3 include/asm-ia64/asmmacro.h - 1.2 include/asm-ia64/byteorder.h - 1.2 include/asm-ia64/mmzone.h - 1.2 include/asm-ia64/numa.h - 1.3 include/asm-ia64/page.h - 1.3 include/asm-ia64/pgtable.h - 1.3 include/asm-ia64/smp.h - 1.2 include/asm-ia64/sn/addrs.h - 1.2 include/asm-ia64/sn/alenlist.h - 1.2 include/asm-ia64/sn/arc/hinv.h - 1.2 include/asm-ia64/sn/arc/types.h - 1.2 include/asm-ia64/sn/arch.h - 1.2 include/asm-ia64/sn/bte.h - 1.2 include/asm-ia64/sn/cdl.h - 1.2 include/asm-ia64/sn/clksupport.h - 1.2 include/asm-ia64/sn/dmamap.h - 1.2 include/asm-ia64/sn/driver.h - 1.2 include/asm-ia64/sn/geo.h - 1.2 include/asm-ia64/sn/hcl.h - 1.2 include/asm-ia64/sn/hcl_util.h - 1.2 include/asm-ia64/sn/hwgfs.h - 1.2 include/asm-ia64/sn/intr.h - 1.2 include/asm-ia64/sn/invent.h - 1.2 include/asm-ia64/sn/io.h - 1.2 include/asm-ia64/sn/ioc4.h - 1.2 include/asm-ia64/sn/ioconfig_bus.h - 1.2 include/asm-ia64/sn/ioerror.h - 1.2 include/asm-ia64/sn/ioerror_handling.h - 1.2 include/asm-ia64/sn/iograph.h - 1.2 include/asm-ia64/sn/klconfig.h - 1.2 include/asm-ia64/sn/ksys/elsc.h - 1.2 include/asm-ia64/sn/ksys/l1.h - 1.2 include/asm-ia64/sn/labelcl.h - 1.2 include/asm-ia64/sn/module.h - 1.2 include/asm-ia64/sn/nag.h - 1.2 include/asm-ia64/sn/nodepda.h - 1.2 include/asm-ia64/sn/pci/bridge.h - 1.2 include/asm-ia64/sn/pci/pci_bus_cvlink.h - 1.2 include/asm-ia64/sn/pci/pci_defs.h - 1.2 include/asm-ia64/sn/pci/pcibr.h - 1.2 include/asm-ia64/sn/pci/pcibr_private.h - 1.2 include/asm-ia64/sn/pci/pciio.h - 1.2 include/asm-ia64/sn/pci/pciio_private.h - 1.2 include/asm-ia64/sn/pci/pic.h - 1.2 include/asm-ia64/sn/pda.h - 1.2 include/asm-ia64/sn/pio.h - 1.2 include/asm-ia64/sn/prio.h - 1.2 include/asm-ia64/sn/router.h - 1.2 include/asm-ia64/sn/sgi.h - 1.2 include/asm-ia64/sn/slotnum.h - 1.2 include/asm-ia64/sn/sn2/addrs.h - 1.2 include/asm-ia64/sn/sn2/arch.h - 1.2 include/asm-ia64/sn/sn2/geo.h - 1.2 include/asm-ia64/sn/sn2/intr.h - 1.2 include/asm-ia64/sn/sn2/shub.h - 1.2 include/asm-ia64/sn/sn2/shub_md.h - 1.2 include/asm-ia64/sn/sn2/shubio.h - 1.2 include/asm-ia64/sn/sn2/sn_private.h - 1.2 include/asm-ia64/sn/sn_fru.h - 1.2 include/asm-ia64/sn/sn_private.h - 1.2 include/asm-ia64/sn/sn_sal.h - 1.2 include/asm-ia64/sn/sndrv.h - 1.2 include/asm-ia64/sn/vector.h - 1.2 include/asm-ia64/sn/xtalk/xbow.h - 1.2 include/asm-ia64/sn/xtalk/xbow_info.h - 1.2 include/asm-ia64/sn/xtalk/xswitch.h - 1.2 include/asm-ia64/sn/xtalk/xtalk.h - 1.2 include/asm-ia64/sn/xtalk/xtalk_private.h - 1.2 include/asm-ia64/sn/xtalk/xtalkaddrs.h - 1.2 include/asm-ia64/sn/xtalk/xwidget.h - 1.2 include/asm-ia64/socket.h - 1.2 include/asm-ia64/uaccess.h - 1.3 include/asm-m68k/atariints.h - 1.2 include/asm-m68k/bitops.h - 1.2 include/asm-m68k/byteorder.h - 1.2 include/asm-m68k/cacheflush.h - 1.2 include/asm-m68k/delay.h - 1.2 include/asm-m68k/dvma.h - 1.2 include/asm-m68k/io.h - 1.2 include/asm-m68k/mac_psc.h - 1.2 include/asm-m68k/mac_via.h - 1.2 include/asm-m68k/mmu_context.h - 1.2 include/asm-m68k/motorola_pgtable.h - 1.2 include/asm-m68k/nubus.h - 1.2 include/asm-m68k/page.h - 1.2 include/asm-m68k/pci.h - 1.2 include/asm-m68k/pgtable.h - 1.2 include/asm-m68k/processor.h - 1.2 include/asm-m68k/sbus.h - 1.2 include/asm-m68k/semaphore.h - 1.2 include/asm-m68k/signal.h - 1.2 include/asm-m68k/socket.h - 1.2 include/asm-m68k/string.h - 1.2 include/asm-m68k/sun3_pgtable.h - 1.2 include/asm-m68k/sun3mmu.h - 1.2 include/asm-m68k/system.h - 1.2 include/asm-m68k/thread_info.h - 1.2 include/asm-m68k/tlbflush.h - 1.2 include/asm-m68k/uaccess.h - 1.2 include/asm-m68k/virtconvert.h - 1.2 include/asm-m68k/zorro.h - 1.2 include/asm-m68knommu/types.h - 1.2 include/asm-mips/dma-mapping.h - 1.2 include/asm-mips/pci.h - 1.2 include/asm-mips/smp.h - 1.2 include/asm-mips/socket.h - 1.2 include/asm-parisc/byteorder.h - 1.2 include/asm-parisc/mmu_context.h - 1.2 include/asm-parisc/pgtable.h - 1.2 include/asm-parisc/smp.h - 1.2 include/asm-parisc/socket.h - 1.2 include/asm-parisc/tlbflush.h - 1.2 include/asm-ppc/byteorder.h - 1.2 include/asm-ppc/floppy.h - 1.2 include/asm-ppc/highmem.h - 1.3 include/asm-ppc/ibm4xx.h - 1.2 include/asm-ppc/mpc8260.h - 1.2 include/asm-ppc/pci.h - 1.2 include/asm-ppc/pgtable.h - 1.2 include/asm-ppc/smp.h - 1.2 include/asm-ppc/socket.h - 1.2 include/asm-ppc/uaccess.h - 1.2 include/asm-ppc/unistd.h - 1.2 include/asm-ppc64/byteorder.h - 1.2 include/asm-ppc64/compat.h - 1.2 include/asm-ppc64/cputable.h - 1.2 include/asm-ppc64/elf.h - 1.2 include/asm-ppc64/floppy.h - 1.2 include/asm-ppc64/hvcall.h - 1.2 include/asm-ppc64/hw_irq.h - 1.2 include/asm-ppc64/iSeries/HvCall.h - 1.2 include/asm-ppc64/iSeries/HvCallCfg.h - 1.2 include/asm-ppc64/iSeries/HvCallEvent.h - 1.2 include/asm-ppc64/iSeries/HvCallHpt.h - 1.2 include/asm-ppc64/iSeries/HvCallPci.h - 1.2 include/asm-ppc64/iSeries/HvCallSc.h - 1.2 include/asm-ppc64/iSeries/HvCallSm.h - 1.2 include/asm-ppc64/iSeries/HvCallXm.h - 1.2 include/asm-ppc64/iSeries/HvLpConfig.h - 1.2 include/asm-ppc64/iSeries/HvLpEvent.h - 1.2 include/asm-ppc64/iSeries/HvReleaseData.h - 1.2 include/asm-ppc64/iSeries/HvTypes.h - 1.2 include/asm-ppc64/iSeries/IoHriProcessorVpd.h - 1.2 include/asm-ppc64/iSeries/ItExtVpdPanel.h - 1.2 include/asm-ppc64/iSeries/ItIplParmsReal.h - 1.2 include/asm-ppc64/iSeries/ItLpNaca.h - 1.2 include/asm-ppc64/iSeries/ItLpPaca.h - 1.2 include/asm-ppc64/iSeries/ItLpQueue.h - 1.2 include/asm-ppc64/iSeries/ItLpRegSave.h - 1.2 include/asm-ppc64/iSeries/ItVpdAreas.h - 1.2 include/asm-ppc64/iSeries/LparMap.h - 1.2 include/asm-ppc64/iSeries/iSeries_dma.h - 1.2 include/asm-ppc64/iSeries/iSeries_io.h - 1.2 include/asm-ppc64/iSeries/iSeries_irq.h - 1.2 include/asm-ppc64/iSeries/iSeries_pci.h - 1.2 include/asm-ppc64/iSeries/iSeries_proc.h - 1.2 include/asm-ppc64/iSeries/mf.h - 1.2 include/asm-ppc64/iSeries/mf_proc.h - 1.2 include/asm-ppc64/iSeries/veth-proc.h - 1.2 include/asm-ppc64/io.h - 1.2 include/asm-ppc64/irq.h - 1.2 include/asm-ppc64/machdep.h - 1.2 include/asm-ppc64/memory.h - 1.2 include/asm-ppc64/mmu.h - 1.2 include/asm-ppc64/mmu_context.h - 1.2 include/asm-ppc64/naca.h - 1.2 include/asm-ppc64/nvram.h - 1.2 include/asm-ppc64/paca.h - 1.2 include/asm-ppc64/pci.h - 1.2 include/asm-ppc64/pgalloc.h - 1.2 include/asm-ppc64/pgtable.h - 1.2 include/asm-ppc64/ppc32.h - 1.2 include/asm-ppc64/ppc_asm.h - 1.2 include/asm-ppc64/proc_fs.h - 1.2 include/asm-ppc64/processor.h - 1.2 include/asm-ppc64/prom.h - 1.2 include/asm-ppc64/ptrace.h - 1.2 include/asm-ppc64/rtas.h - 1.2 include/asm-ppc64/sigcontext.h - 1.2 include/asm-ppc64/smp.h - 1.2 include/asm-ppc64/socket.h - 1.2 include/asm-ppc64/system.h - 1.2 include/asm-ppc64/tlb.h - 1.2 include/asm-ppc64/topology.h - 1.2 include/asm-ppc64/uaccess.h - 1.2 include/asm-ppc64/unistd.h - 1.2 include/asm-s390/bitops.h - 1.2 include/asm-s390/bug.h - 1.2 include/asm-s390/byteorder.h - 1.2 include/asm-s390/ccwdev.h - 1.3 include/asm-s390/ccwgroup.h - 1.2 include/asm-s390/checksum.h - 1.2 include/asm-s390/cio.h - 1.2 include/asm-s390/dasd.h - 1.2 include/asm-s390/hardirq.h - 1.2 include/asm-s390/idals.h - 1.2 include/asm-s390/ioctl.h - 1.2 include/asm-s390/mmu_context.h - 1.2 include/asm-s390/pgalloc.h - 1.2 include/asm-s390/pgtable.h - 1.2 include/asm-s390/scatterlist.h - 1.2 include/asm-s390/setup.h - 1.2 include/asm-s390/siginfo.h - 1.2 include/asm-s390/smp.h - 1.2 include/asm-s390/socket.h - 1.2 include/asm-s390/spinlock.h - 1.2 include/asm-s390/tlbflush.h - 1.2 include/asm-s390/uaccess.h - 1.2 include/asm-s390/unistd.h - 1.2 include/asm-sh/bigsur.h - 1.2 include/asm-sh/bigsur/io.h - 1.2 include/asm-sh/byteorder.h - 1.2 include/asm-sh/cache.h - 1.2 include/asm-sh/cat68701/io.h - 1.2 include/asm-sh/cpu-sh2/cache.h - 1.2 include/asm-sh/cpu-sh3/cache.h - 1.2 include/asm-sh/cpu-sh3/dma.h - 1.2 include/asm-sh/cpu-sh3/mmu_context.h - 1.2 include/asm-sh/cpu-sh4/cache.h - 1.2 include/asm-sh/cpu-sh4/dma.h - 1.2 include/asm-sh/dc_sysasic.h - 1.2 include/asm-sh/dma.h - 1.2 include/asm-sh/dreamcast/sysasic.h - 1.2 include/asm-sh/ec3104.h - 1.2 include/asm-sh/ec3104/io.h - 1.2 include/asm-sh/floppy.h - 1.2 include/asm-sh/hardirq.h - 1.2 include/asm-sh/hd64461.h - 1.2 include/asm-sh/hd64461/io.h - 1.2 include/asm-sh/hd64465.h - 1.2 include/asm-sh/hd64465/io.h - 1.2 include/asm-sh/hd64465_gpio.h - 1.2 include/asm-sh/hitachi_7751se.h - 1.2 include/asm-sh/hitachi_se.h - 1.2 include/asm-sh/io.h - 1.2 include/asm-sh/io_7751se.h - 1.2 include/asm-sh/io_adx.h - 1.2 include/asm-sh/io_bigsur.h - 1.2 include/asm-sh/io_cat68701.h - 1.2 include/asm-sh/io_dc.h - 1.2 include/asm-sh/io_ec3104.h - 1.2 include/asm-sh/io_generic.h - 1.2 include/asm-sh/io_hd64461.h - 1.2 include/asm-sh/io_hd64465.h - 1.2 include/asm-sh/io_se.h - 1.2 include/asm-sh/io_sh2000.h - 1.2 include/asm-sh/io_unknown.h - 1.2 include/asm-sh/ipc.h - 1.2 include/asm-sh/irq.h - 1.2 include/asm-sh/keyboard-ec3104.h - 1.2 include/asm-sh/kgdb.h - 1.2 include/asm-sh/machvec.h - 1.2 include/asm-sh/mc146818rtc.h - 1.2 include/asm-sh/module.h - 1.2 include/asm-sh/mpc1211/io.h - 1.2 include/asm-sh/overdrive/io.h - 1.2 include/asm-sh/page.h - 1.2 include/asm-sh/pci-sh7751.h - 1.2 include/asm-sh/pci.h - 1.2 include/asm-sh/pgalloc.h - 1.2 include/asm-sh/pgtable.h - 1.2 include/asm-sh/processor.h - 1.2 include/asm-sh/ptrace.h - 1.2 include/asm-sh/rtc.h - 1.2 include/asm-sh/saturn/io.h - 1.2 include/asm-sh/se/io.h - 1.2 include/asm-sh/se7751/io.h - 1.2 include/asm-sh/serial-bigsur.h - 1.2 include/asm-sh/serial-ec3104.h - 1.2 include/asm-sh/sigcontext.h - 1.2 include/asm-sh/smc37c93x.h - 1.2 include/asm-sh/smp.h - 1.2 include/asm-sh/socket.h - 1.2 include/asm-sh/spinlock.h - 1.2 include/asm-sh/system.h - 1.2 include/asm-sh/timex.h - 1.2 include/asm-sh/uaccess.h - 1.2 include/asm-sh/unistd.h - 1.2 include/asm-sparc/elf.h - 1.2 include/asm-sparc/socket.h - 1.2 include/asm-sparc64/floppy.h - 1.2 include/asm-sparc64/smp.h - 1.2 include/asm-sparc64/socket.h - 1.2 include/asm-sparc64/tlbflush.h - 1.2 include/asm-um/smp.h - 1.2 include/asm-v850/byteorder.h - 1.2 include/asm-v850/socket.h - 1.2 include/asm-x86_64/byteorder.h - 1.2 include/asm-x86_64/calling.h - 1.3 include/asm-x86_64/desc.h - 1.2 include/asm-x86_64/dwarf2.h - 1.2 include/asm-x86_64/floppy.h - 1.2 include/asm-x86_64/hw_irq.h - 1.3 include/asm-x86_64/ia32.h - 1.2 include/asm-x86_64/kdebug.h - 1.2 include/asm-x86_64/mc146818rtc.h - 1.2 include/asm-x86_64/pgalloc.h - 1.2 include/asm-x86_64/pgtable.h - 1.3 include/asm-x86_64/processor.h - 1.2 include/asm-x86_64/proto.h - 1.2 include/asm-x86_64/ptrace.h - 1.2 include/asm-x86_64/scatterlist.h - 1.2 include/asm-x86_64/smp.h - 1.3 include/asm-x86_64/socket.h - 1.2 include/asm-x86_64/spinlock.h - 1.2 include/asm-x86_64/system.h - 1.3 include/asm-x86_64/thread_info.h - 1.2 include/asm-x86_64/timex.h - 1.2 include/asm-x86_64/unistd.h - 1.3 include/asm-x86_64/vsyscall32.h - 1.2 include/linux/apm_bios.h - 1.2 include/linux/bio.h - 1.3 include/linux/bitmap.h - 1.2 include/linux/blkdev.h - 1.3 include/linux/buffer_head.h - 1.2 include/linux/byteorder/swab.h - 1.2 include/linux/cdrom.h - 1.2 include/linux/compat.h - 1.3 include/linux/compat_ioctl.h - 1.3 include/linux/compiler-gcc+.h - 1.2 include/linux/compiler-gcc2.h - 1.2 include/linux/compiler-gcc3.h - 1.2 include/linux/compiler.h - 1.2 include/linux/cpu.h - 1.2 include/linux/cpumask.h - 1.3 include/linux/dcache.h - 1.2 include/linux/device.h - 1.3 include/linux/efi.h - 1.3 include/linux/eventpoll.h - 1.2 include/linux/ext2_fs_sb.h - 1.2 include/linux/ext3_fs_sb.h - 1.2 include/linux/ext3_jbd.h - 1.2 include/linux/fs.h - 1.3 include/linux/genhd.h - 1.2 include/linux/highmem.h - 1.2 include/linux/i2c-id.h - 1.3 include/linux/ide.h - 1.3 include/linux/input.h - 1.3 include/linux/ipv6.h - 1.3 include/linux/kernel.h - 1.3 include/linux/kobject.h - 1.2 include/linux/miscdevice.h - 1.2 include/linux/mm.h - 1.3 include/linux/mmzone.h - 1.3 include/linux/module.h - 1.2 include/linux/moduleparam.h - 1.2 include/linux/net.h - 1.2 include/linux/netdevice.h - 1.3 include/linux/nfs_fs.h - 1.2 include/linux/nfsd/nfsfh.h - 1.2 include/linux/pci_ids.h - 1.3 include/linux/proc_fs.h - 1.3 include/linux/quotaops.h - 1.2 include/linux/raid/md_k.h - 1.2 include/linux/raid/raid5.h - 1.2 include/linux/rcupdate.h - 1.2 include/linux/rtnetlink.h - 1.2 include/linux/sched.h - 1.3 include/linux/sctp.h - 1.2 include/linux/security.h - 1.2 include/linux/signal.h - 1.2 include/linux/skbuff.h - 1.3 include/linux/smp.h - 1.2 include/linux/smp_lock.h - 1.2 include/linux/sunrpc/cache.h - 1.2 include/linux/sunrpc/sched.h - 1.2 include/linux/swap.h - 1.2 include/linux/sysctl.h - 1.3 include/linux/videodev.h - 1.3 include/linux/videodev2.h - 1.2 include/linux/xattr.h - 1.2 include/linux/zorro.h - 1.2 include/media/id.h - 1.2 include/media/saa7146.h - 1.3 include/media/saa7146_vv.h - 1.3 include/media/tuner.h - 1.2 include/net/addrconf.h - 1.2 include/net/ah.h - 1.2 include/net/bluetooth/bluetooth.h - 1.2 include/net/bluetooth/hci.h - 1.2 include/net/bluetooth/hci_core.h - 1.2 include/net/bluetooth/rfcomm.h - 1.2 include/net/flow.h - 1.2 include/net/if_inet6.h - 1.2 include/net/inet_common.h - 1.2 include/net/ipv6.h - 1.3 include/net/irda/ircomm_tty.h - 1.3 include/net/irda/timer.h - 1.2 include/net/ndisc.h - 1.2 include/net/neighbour.h - 1.2 include/net/sctp/constants.h - 1.2 include/net/sctp/sctp.h - 1.3 include/net/sctp/sm.h - 1.2 include/net/sctp/structs.h - 1.2 include/net/sock.h - 1.3 include/net/tcp.h - 1.2 include/net/udp.h - 1.2 include/pcmcia/cs.h - 1.2 include/rxrpc/call.h - 1.2 include/rxrpc/connection.h - 1.2 include/rxrpc/message.h - 1.2 include/rxrpc/peer.h - 1.2 include/rxrpc/transport.h - 1.2 include/scsi/scsi.h - 1.3 include/sound/core.h - 1.2 init/main.c - 1.3 kernel/cpu.c - 1.2 kernel/dma.c - 1.2 kernel/exit.c - 1.3 kernel/extable.c - 1.2 kernel/fork.c - 1.3 kernel/futex.c - 1.3 kernel/module.c - 1.3 kernel/posix-timers.c - 1.2 kernel/printk.c - 1.3 kernel/sched.c - 1.3 kernel/sys.c - 1.3 kernel/sysctl.c - 1.2 kernel/timer.c - 1.2 kernel/workqueue.c - 1.2 lib/Makefile - 1.3 lib/kobject.c - 1.2 mm/fadvise.c - 1.2 mm/filemap.c - 1.3 mm/fremap.c - 1.2 mm/madvise.c - 1.2 mm/memory.c - 1.3 mm/mincore.c - 1.2 mm/mmap.c - 1.3 mm/mremap.c - 1.3 mm/msync.c - 1.2 mm/nommu.c - 1.2 mm/page-writeback.c - 1.2 mm/page_alloc.c - 1.3 mm/readahead.c - 1.3 mm/rmap.c - 1.2 mm/shmem.c - 1.3 mm/swapfile.c - 1.2 mm/vmscan.c - 1.3 net/appletalk/ddp.c - 1.2 net/atm/br2684.c - 1.2 net/atm/clip.c - 1.2 net/atm/common.c - 1.2 net/atm/common.h - 1.2 net/ax25/af_ax25.c - 1.3 net/bluetooth/Kconfig - 1.2 net/bluetooth/Makefile - 1.2 net/bluetooth/af_bluetooth.c - 1.3 net/bluetooth/bnep/core.c - 1.3 net/bluetooth/hci_conn.c - 1.2 net/bluetooth/hci_core.c - 1.2 net/bluetooth/hci_event.c - 1.2 net/bluetooth/hci_sock.c - 1.2 net/bluetooth/l2cap.c - 1.2 net/bluetooth/rfcomm/core.c - 1.2 net/bluetooth/rfcomm/sock.c - 1.2 net/bluetooth/sco.c - 1.2 net/bridge/br_if.c - 1.2 net/bridge/br_netfilter.c - 1.3 net/core/dev.c - 1.3 net/core/dev_mcast.c - 1.2 net/core/dst.c - 1.2 net/core/flow.c - 1.2 net/core/neighbour.c - 1.3 net/core/pktgen.c - 1.2 net/core/sock.c - 1.3 net/decnet/af_decnet.c - 1.3 net/econet/af_econet.c - 1.2 net/ipv4/Kconfig - 1.2 net/ipv4/af_inet.c - 1.2 net/ipv4/ah4.c - 1.2 net/ipv4/arp.c - 1.2 net/ipv4/devinet.c - 1.2 net/ipv4/igmp.c - 1.2 net/ipv4/ipcomp.c - 1.2 net/ipv4/ipmr.c - 1.2 net/ipv4/netfilter/Kconfig - 1.2 net/ipv4/netfilter/ip_tables.c - 1.2 net/ipv4/raw.c - 1.2 net/ipv4/route.c - 1.2 net/ipv4/tcp.c - 1.2 net/ipv4/udp.c - 1.2 net/ipv6/addrconf.c - 1.3 net/ipv6/af_inet6.c - 1.2 net/ipv6/ah6.c - 1.2 net/ipv6/anycast.c - 1.2 net/ipv6/datagram.c - 1.2 net/ipv6/exthdrs.c - 1.2 net/ipv6/icmp.c - 1.2 net/ipv6/ip6_fib.c - 1.2 net/ipv6/ip6_output.c - 1.3 net/ipv6/ip6_tunnel.c - 1.3 net/ipv6/ipv6_sockglue.c - 1.2 net/ipv6/mcast.c - 1.2 net/ipv6/ndisc.c - 1.3 net/ipv6/raw.c - 1.2 net/ipv6/reassembly.c - 1.2 net/ipv6/route.c - 1.2 net/ipv6/sit.c - 1.2 net/ipv6/udp.c - 1.2 net/ipx/af_ipx.c - 1.2 net/ipx/ipx_route.c - 1.2 net/irda/af_irda.c - 1.2 net/irda/ircomm/ircomm_tty.c - 1.3 net/irda/ircomm/ircomm_tty_ioctl.c - 1.2 net/irda/irlap_event.c - 1.2 net/irda/irlap_frame.c - 1.2 net/key/af_key.c - 1.2 net/llc/af_llc.c - 1.2 net/netlink/af_netlink.c - 1.2 net/netrom/af_netrom.c - 1.3 net/packet/af_packet.c - 1.3 net/rose/af_rose.c - 1.3 net/rxrpc/call.c - 1.2 net/rxrpc/krxiod.c - 1.2 net/rxrpc/krxsecd.c - 1.2 net/rxrpc/krxtimod.c - 1.2 net/rxrpc/transport.c - 1.2 net/sched/sch_teql.c - 1.2 net/sctp/associola.c - 1.3 net/sctp/input.c - 1.2 net/sctp/ipv6.c - 1.2 net/sctp/output.c - 1.2 net/sctp/outqueue.c - 1.3 net/sctp/protocol.c - 1.2 net/sctp/sm_make_chunk.c - 1.2 net/sctp/sm_sideeffect.c - 1.2 net/sctp/sm_statefuns.c - 1.2 net/sctp/sm_statetable.c - 1.2 net/sctp/socket.c - 1.3 net/sctp/sysctl.c - 1.2 net/socket.c - 1.2 net/sunrpc/cache.c - 1.2 net/sunrpc/sysctl.c - 1.2 net/unix/af_unix.c - 1.2 net/x25/af_x25.c - 1.2 net/xfrm/xfrm_algo.c - 1.2 net/xfrm/xfrm_policy.c - 1.3 net/xfrm/xfrm_user.c - 1.2 scripts/kconfig/mconf.c - 1.3 scripts/modpost.c - 1.3 security/Makefile - 1.2 security/capability.c - 1.2 security/commoncap.c - 1.2 security/dummy.c - 1.2 security/selinux/Makefile - 1.2 security/selinux/avc.c - 1.2 security/selinux/hooks.c - 1.3 security/selinux/include/av_perm_to_string.h - 1.3 security/selinux/include/av_permissions.h - 1.3 security/selinux/include/avc.h - 1.2 security/selinux/include/objsec.h - 1.2 security/selinux/ss/Makefile - 1.3 sound/core/sound.c - 1.3 sound/oss/dmabuf.c - 1.2 sound/oss/soundcard.c - 1.2 sound/oss/trident.c - 1.2 sound/oss/trident.h - 1.2 sound/pci/intel8x0.c - 1.2 sound/pcmcia/vx/vx_entry.c - 1.2 sound/sound_core.c - 1.3 drivers/usb/media/w9968cf.c - 1.2 drivers/usb/media/w9968cf.h - 1.2 drivers/usb/media/w9968cf_decoder.h - 1.2 drivers/usb/media/w9968cf_externaldef.h - 1.2 Documentation/dvb/contributors.txt - 1.2 Documentation/dvb/ttusb-dec.txt - 1.2 Documentation/i2c/porting-clients - 1.2 Documentation/usb/w9968cf.txt - 1.2 drivers/ide/pci/sgiioc4.c - 1.2 drivers/i2c/chips/lm83.c - 1.2 drivers/char/watchdog/w83627hf_wdt.c - 1.2 arch/x86_64/ia32/ia32_aout.c - 1.2 arch/ia64/configs/sn2_defconfig - 1.2 arch/i386/kernel/efi.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Jan 29 15:21:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Jan 2004 15:21:56 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TNLi7J018991 for ; Thu, 29 Jan 2004 15:21:45 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0TNLcmb015178 for ; Thu, 29 Jan 2004 17:21:39 -0600 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i0TNI6pR002299 for ; Fri, 30 Jan 2004 10:18:07 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i0TNI6h0002298 for linux-xfs@oss.sgi.com; Fri, 30 Jan 2004 10:18:06 +1100 Date: Fri, 30 Jan 2004 10:18:06 +1100 From: FSG QA Message-Id: <200401292318.i0TNI6h0002298@bruce.melbourne.sgi.com> Subject: TAKE 907752 - xfstests X-archive-position: 1924 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 681 Lines: 28 Update to allow this test to be easily extended for exercising the security namespace. Date: Mon Jan 19 22:39:32 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:165074a xfstests/062 - 1.20 Fix xfs_db filter for attrs so test 021 output is as before. Date: Thu Jan 29 15:20:35 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:165698a xfstests/021 - 1.18 From owner-linux-xfs@oss.sgi.com Thu Jan 29 15:21:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Jan 2004 15:21:56 -0800 (PST) Received: from smtp.cistron-office.nl (mail@10fwd.cistron-office.nl [62.216.29.197]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TNLc7J018985 for ; Thu, 29 Jan 2004 15:21:38 -0800 Received: from subspace.cistron-office.nl ([62.216.29.200]) by smtp.cistron-office.nl with esmtp (Exim 3.35 #1 (Debian)) id 1AmLSc-0003pL-00; Fri, 30 Jan 2004 00:20:34 +0100 Received: from miquels by subspace.cistron-office.nl with local (Exim 3.35 #1 (Debian)) id 1AmLSc-0002t4-00; Fri, 30 Jan 2004 00:20:34 +0100 Date: Fri, 30 Jan 2004 00:20:33 +0100 From: Miquel van Smoorenburg To: Andrew Morton , Nathan Scott Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.2-rc2 nfsd+xfs spins in i_size_read() Message-ID: <20040129232033.GA10541@cistron.nl> References: <20040129063009.GD2474@frodo> <20040128222521.75a7d74f.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040129063009.GD2474@frodo> <20040128222521.75a7d74f.akpm@osdl.org> X-NCC-RegID: nl.cistron User-Agent: Mutt/1.5.4i X-archive-position: 1924 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: miquels@cistron.nl Precedence: bulk X-list: linux-xfs Content-Length: 3758 Lines: 89 According to Andrew Morton: > "Miquel van Smoorenburg" wrote: > > > > On the NFS server I'm exporting an XFS filesystem to the client > > over Gigabit ethernet. The client mounts using > > mount -o nfsvers=3,intr,rsize=32768,wsize=32768 server:/export/hwr /mnt > > > > On the client I then run a large dd to a file on the server, > > like dd if=/dev/zero of=/mnt/file bs=4096 count=800000 > > > > In a few seconds, the server locks up. It spins in > > generic_fillattr(), apparently in the i_size_read() inline function. > > Server responds to pings and sysrq, but nothing else. > > > > 2.6.1 doesn't show this behaviour. I tested several kernels: Okay so I did some more tests today. As it turns out, all stock 2.6 kernels lock up - it's just that 2.6.2-rc* locks up faster than earlier versions. I tested 2.6.1-rc1-mm3 and 2.6.2-rc2-mm1, these do not lock up (test on -mm has been running for 8 hours straight now, 2.6.* vanilla locks up in a few minutes). > > Here's the sysrq output: > > > > Pid: 531, comm: nfsd > > EIP: 0060:[] CPU: 0 > > EIP is at generic_fillattr+0x82/0xa0 > > EFLAGS: 00000246 Not tainted > > EAX: 00000000 EBX: 07ae7200 ECX: f650a0a0 EDX: 000113eb > > ESI: 00000000 EDI: f66cfed4 EBP: f66e5804 DS: 007b ES: 007b > > CR0: 8005003b CR2: 40019000 CR3: 37245000 CR4: 000006d0 > > Call Trace: > > [] linvfs_getattr+0x2b/0x34 [xfs] > > [] vfs_getattr+0x25/0x84 > > [] encode_post_op_attr+0x53/0x238 > > [] encode_wcc_data+0x29f/0x2a8 > > [] nfs3svc_encode_commitres+0x19/0x5c > > [] nfsd_dispatch+0x14d/0x1a3 > > [] svc_process+0x3b3/0x640 > > [] nfsd+0x1e4/0x358 > > [] nfsd+0x0/0x358 > > [] kernel_thread_helper+0x5/0xc > > > > Is the EIP _always_ inside generic_fillattr()? Yes, if a keep on doing BREAK-p the output is alway the same. EIP varies a few bytes, ofcourse, not much. > If so then yes, your analysis look right. I'd say that the inode has been > corrupted and the seqcount counter has assumed an non-even value. That > will cause i_size_read() to lock up. > > Are you using slab debugging? Is so, does the lockup go away if you change > mm/slab.c:POISON_FREE to an even value, say 0x6a? That would tend to > confirm a use-after-free problem. Or a totally wild pointer. I turned on slab debugging but it didn't help, and it didn't make any difference. Well actually it made it take longer to show the effect - at first I thought that the problem dissapeared when I turned on slab debugging, but when I removed the "count=bignumber" from the dd command, it locked up eventually (in a few minutes). I also changed the debug constanst from odd to even and the other way around, but that had no effect - no messages logged, and the kernel still locked up. Note that at this heavy load, there are up to 8 nfsd's running on the server concurrently. There must be some lock or race ... According to Nathan Scott: > Hmmmm... I don't think Andrew has any XFS fixes in his tree that > might help there; and I can't think of any XFS change in -rc1 that > might have caused this (does the fs/xfs subdir from 2.6.1 plonked > down in place of the 2.6.2-rc1/2 version still have the problem?) Yes, sorry for the confusion - all 2.6 (non-mm) shows this behaviour. I tried -mm1 XFS in 2.6.1-rc2, but that did't help, it still locks up (the diff is just a one-liner, so that was to be expected). So it doesn't look like an XFS problem, perse. > i_size_read seems to have a fair bit of config dependency - are you > CONFIG_SMP / CONFIG_PREEMPT / neither? and is your BITS_PER_LONG > 32 or 64? thanks. CONFIG_SMP (for P IV hyperthreading), 32 bits. Mike. From owner-linux-xfs@oss.sgi.com Thu Jan 29 16:32:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Jan 2004 16:32:46 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0U0WW7J025063 for ; Thu, 29 Jan 2004 16:32:33 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0U0WHha015896 for ; Thu, 29 Jan 2004 16:32:17 -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.10/SGI_generic_relay-1.2) with ESMTP id i0U0WFcn32251012; Thu, 29 Jan 2004 18:32:16 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AmMZz-0006cB-00; Thu, 29 Jan 2004 18:32:15 -0600 Subject: TAKE 908145 - Plug a pagebuf race that got bigger with the recent cleanup Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Thu, 29 Jan 2004 18:32:15 -0600 X-archive-position: 1925 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 823 Lines: 27 Date: Thu Jan 29 16:31:35 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:165722a fs/xfs/linux-2.6/xfs_buf.h - 1.84 - kill PBF_FREED and _PBF_PRIVATE_BH fs/xfs/linux-2.6/xfs_buf.c - 1.139 - - drop out of pagebuf_free if the buffer hold count was incremented before taking the lock - ignore buffers with a zero hold-count in _pagebuf_find - kill PBF_FREED flag, as it was racy fs/xfs/linux-2.4/xfs_buf.h - 1.89 - kill PBF_FREED fs/xfs/linux-2.4/xfs_buf.c - 1.158 - - drop out of pagebuf_free if the buffer hold count was incremented before taking the lock - ignore buffers with a zero hold-count in _pagebuf_find - kill PBF_FREED flag, as it was racy From owner-linux-xfs@oss.sgi.com Thu Jan 29 17:07:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Jan 2004 17:07:37 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0U17J7J026862 for ; Thu, 29 Jan 2004 17:07:20 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0U17Dha026266 for ; Thu, 29 Jan 2004 17:07:14 -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 i0U17BhI1756471 for ; Fri, 30 Jan 2004 12:07:12 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i0U17BME1750221 for linux-xfs@oss.sgi.com; Fri, 30 Jan 2004 12:07:11 +1100 (EST) Date: Fri, 30 Jan 2004 12:07:11 +1100 (EST) From: Nathan Scott Message-Id: <200401300107.i0U17BME1750221@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.4.25-pre8 X-archive-position: 1926 X-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: 14604 Lines: 429 Date: Thu Jan 29 16:27:42 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:165721a drivers/message/fusion/lsi/mpi_tool.h - 1.1 drivers/usb/gadget/file_storage.c - 1.1 drivers/usb/gadget/goku_udc.c - 1.1 drivers/usb/gadget/goku_udc.h - 1.1 drivers/video/it8181fb.c - 1.1 arch/ppc/configs/sandpoint_defconfig - 1.1 arch/ppc/configs/prpmc750_defconfig - 1.1 fs/smbfs/symlink.c - 1.1 include/linux/moduleparam.h - 1.1 Documentation/Configure.help - 1.7 Makefile - 1.6 arch/alpha/config.in - 1.2 arch/alpha/defconfig - 1.2 arch/arm/config.in - 1.2 arch/arm/def-configs/a5k - 1.2 arch/arm/def-configs/accelent_sa - 1.2 arch/arm/def-configs/adsagc - 1.2 arch/arm/def-configs/adsbitsy - 1.2 arch/arm/def-configs/adsbitsyplus - 1.2 arch/arm/def-configs/anakin - 1.2 arch/arm/def-configs/assabet - 1.2 arch/arm/def-configs/at91rm9200dk - 1.2 arch/arm/def-configs/badge4 - 1.2 arch/arm/def-configs/brutus - 1.2 arch/arm/def-configs/cep - 1.2 arch/arm/def-configs/cerfcube - 1.2 arch/arm/def-configs/cerfpda - 1.2 arch/arm/def-configs/cerfpod - 1.2 arch/arm/def-configs/clps7500 - 1.2 arch/arm/def-configs/ebsa110 - 1.2 arch/arm/def-configs/edb7211 - 1.2 arch/arm/def-configs/epxa10db - 1.2 arch/arm/def-configs/epxa1db - 1.2 arch/arm/def-configs/flexanet - 1.2 arch/arm/def-configs/footbridge - 1.2 arch/arm/def-configs/fortunet - 1.2 arch/arm/def-configs/freebird - 1.2 arch/arm/def-configs/freebird_new - 1.2 arch/arm/def-configs/frodo - 1.2 arch/arm/def-configs/graphicsclient - 1.2 arch/arm/def-configs/graphicsmaster - 1.2 arch/arm/def-configs/h3600 - 1.2 arch/arm/def-configs/huw_webpanel - 1.2 arch/arm/def-configs/integrator - 1.2 arch/arm/def-configs/jornada720 - 1.2 arch/arm/def-configs/lart - 1.2 arch/arm/def-configs/lusl7200 - 1.2 arch/arm/def-configs/nanoengine - 1.2 arch/arm/def-configs/neponset - 1.2 arch/arm/def-configs/omaha - 1.2 arch/arm/def-configs/omnimeter - 1.2 arch/arm/def-configs/pangolin - 1.2 arch/arm/def-configs/pfs168_mqtft - 1.2 arch/arm/def-configs/pfs168_mqvga - 1.2 arch/arm/def-configs/pfs168_sastn - 1.2 arch/arm/def-configs/pfs168_satft - 1.2 arch/arm/def-configs/pleb - 1.2 arch/arm/def-configs/riscstation - 1.2 arch/arm/def-configs/rpc - 1.2 arch/arm/def-configs/shannon - 1.2 arch/arm/def-configs/shark - 1.2 arch/arm/def-configs/system3 - 1.2 arch/arm/defconfig - 1.2 arch/cris/config.in - 1.2 arch/cris/defconfig - 1.2 arch/i386/config.in - 1.3 arch/i386/defconfig - 1.2 arch/i386/kernel/setup.c - 1.2 arch/i386/kernel/time.c - 1.2 arch/ia64/config.in - 1.3 arch/ia64/configs/dig - 1.2 arch/ia64/configs/generic - 1.2 arch/ia64/configs/numa - 1.2 arch/ia64/configs/zx1 - 1.2 arch/ia64/defconfig - 1.2 arch/m68k/config.in - 1.2 arch/m68k/defconfig - 1.2 arch/mips/config-shared.in - 1.3 arch/mips/defconfig - 1.3 arch/mips/defconfig-atlas - 1.3 arch/mips/defconfig-bosporus - 1.3 arch/mips/defconfig-capcella - 1.3 arch/mips/defconfig-cobalt - 1.3 arch/mips/defconfig-csb250 - 1.3 arch/mips/defconfig-db1000 - 1.3 arch/mips/defconfig-db1100 - 1.3 arch/mips/defconfig-db1500 - 1.3 arch/mips/defconfig-ddb5476 - 1.3 arch/mips/defconfig-ddb5477 - 1.3 arch/mips/defconfig-decstation - 1.3 arch/mips/defconfig-e55 - 1.3 arch/mips/defconfig-eagle - 1.3 arch/mips/defconfig-ev64120 - 1.3 arch/mips/defconfig-ev96100 - 1.3 arch/mips/defconfig-hp-lj - 1.3 arch/mips/defconfig-hydrogen3 - 1.3 arch/mips/defconfig-ip22 - 1.3 arch/mips/defconfig-it8172 - 1.3 arch/mips/defconfig-ivr - 1.3 arch/mips/defconfig-jmr3927 - 1.3 arch/mips/defconfig-lasat - 1.3 arch/mips/defconfig-malta - 1.3 arch/mips/defconfig-mirage - 1.3 arch/mips/defconfig-mpc30x - 1.3 arch/mips/defconfig-mtx-1 - 1.3 arch/mips/defconfig-nino - 1.3 arch/mips/defconfig-ocelot - 1.3 arch/mips/defconfig-osprey - 1.3 arch/mips/defconfig-pb1000 - 1.3 arch/mips/defconfig-pb1100 - 1.3 arch/mips/defconfig-pb1500 - 1.3 arch/mips/defconfig-rbtx4927 - 1.3 arch/mips/defconfig-rm200 - 1.3 arch/mips/defconfig-sb1250-swarm - 1.3 arch/mips/defconfig-sead - 1.3 arch/mips/defconfig-tb0226 - 1.3 arch/mips/defconfig-tb0229 - 1.3 arch/mips/defconfig-ti1500 - 1.3 arch/mips/defconfig-workpad - 1.3 arch/mips/defconfig-xxs1500 - 1.3 arch/mips/defconfig-yosemite - 1.3 arch/mips64/defconfig - 1.3 arch/mips64/defconfig-atlas - 1.3 arch/mips64/defconfig-decstation - 1.3 arch/mips64/defconfig-ip22 - 1.3 arch/mips64/defconfig-ip27 - 1.3 arch/mips64/defconfig-jaguar - 1.3 arch/mips64/defconfig-malta - 1.3 arch/mips64/defconfig-ocelotc - 1.3 arch/mips64/defconfig-sb1250-swarm - 1.3 arch/mips64/defconfig-sead - 1.3 arch/parisc/config.in - 1.2 arch/parisc/defconfig - 1.2 arch/ppc/config.in - 1.4 arch/ppc/configs/IVMS8_defconfig - 1.4 arch/ppc/configs/SM850_defconfig - 1.4 arch/ppc/configs/SPD823TS_defconfig - 1.4 arch/ppc/configs/TQM823L_defconfig - 1.4 arch/ppc/configs/TQM850L_defconfig - 1.4 arch/ppc/configs/TQM860L_defconfig - 1.4 arch/ppc/configs/apus_defconfig - 1.3 arch/ppc/configs/briq_defconfig - 1.3 arch/ppc/configs/bseip_defconfig - 1.4 arch/ppc/configs/common_defconfig - 1.3 arch/ppc/configs/ebony_defconfig - 1.3 arch/ppc/configs/est8260_defconfig - 1.3 arch/ppc/configs/gemini_defconfig - 1.3 arch/ppc/configs/ibmchrp_defconfig - 1.3 arch/ppc/configs/mbx_defconfig - 1.4 arch/ppc/configs/oak_defconfig - 1.3 arch/ppc/configs/ocotea_defconfig - 1.3 arch/ppc/configs/pal4_defconfig - 1.3 arch/ppc/configs/pmac_defconfig - 1.3 arch/ppc/configs/power3_defconfig - 1.3 arch/ppc/configs/pplus_defconfig - 1.3 arch/ppc/configs/rpxcllf_defconfig - 1.4 arch/ppc/configs/rpxlite_defconfig - 1.4 arch/ppc/configs/spruce_defconfig - 1.3 arch/ppc/configs/walnut_defconfig - 1.3 arch/ppc/defconfig - 1.3 arch/ppc64/config.in - 1.3 arch/ppc64/configs/iSeries_devfs_defconfig - 1.3 arch/ppc64/configs/iSeries_nodevfs_ideemul_defconfig - 1.3 arch/ppc64/configs/pSeries_defconfig - 1.3 arch/ppc64/defconfig - 1.3 arch/sh/config.in - 1.3 arch/sh/defconfig - 1.2 arch/sh64/config.in - 1.3 arch/sh64/defconfig - 1.2 arch/sparc/config.in - 1.2 arch/sparc/defconfig - 1.2 arch/sparc64/config.in - 1.2 arch/sparc64/defconfig - 1.3 arch/sparc64/kernel/head.S - 1.3 arch/sparc64/mm/init.c - 1.2 arch/x86_64/config.in - 1.2 arch/x86_64/defconfig - 1.2 arch/x86_64/ia32/ia32_ioctl.c - 1.2 arch/x86_64/ia32/ia32entry.S - 1.2 arch/x86_64/ia32/ptrace32.c - 1.3 arch/x86_64/ia32/sys_ia32.c - 1.2 arch/x86_64/kernel/bluesmoke.c - 1.2 arch/x86_64/kernel/e820.c - 1.2 arch/x86_64/kernel/mtrr.c - 1.2 arch/x86_64/kernel/pci-gart.c - 1.2 arch/x86_64/kernel/process.c - 1.2 arch/x86_64/mm/k8topology.c - 1.2 drivers/acpi/ac.c - 1.2 drivers/acpi/asus_acpi.c - 1.2 drivers/acpi/battery.c - 1.2 drivers/acpi/button.c - 1.2 drivers/acpi/dispatcher/dsfield.c - 1.2 drivers/acpi/dispatcher/dsinit.c - 1.2 drivers/acpi/dispatcher/dsmethod.c - 1.2 drivers/acpi/dispatcher/dsmthdat.c - 1.2 drivers/acpi/dispatcher/dsobject.c - 1.2 drivers/acpi/dispatcher/dsopcode.c - 1.2 drivers/acpi/dispatcher/dsutils.c - 1.2 drivers/acpi/dispatcher/dswexec.c - 1.2 drivers/acpi/dispatcher/dswload.c - 1.2 drivers/acpi/dispatcher/dswscope.c - 1.2 drivers/acpi/dispatcher/dswstate.c - 1.2 drivers/acpi/ec.c - 1.2 drivers/acpi/events/evevent.c - 1.2 drivers/acpi/events/evgpe.c - 1.2 drivers/acpi/events/evgpeblk.c - 1.2 drivers/acpi/events/evmisc.c - 1.2 drivers/acpi/events/evregion.c - 1.2 drivers/acpi/events/evrgnini.c - 1.2 drivers/acpi/events/evsci.c - 1.2 drivers/acpi/events/evxface.c - 1.2 drivers/acpi/events/evxfevnt.c - 1.2 drivers/acpi/events/evxfregn.c - 1.2 drivers/acpi/executer/exconfig.c - 1.2 drivers/acpi/executer/exconvrt.c - 1.2 drivers/acpi/executer/excreate.c - 1.2 drivers/acpi/executer/exdump.c - 1.2 drivers/acpi/executer/exfield.c - 1.2 drivers/acpi/executer/exfldio.c - 1.2 drivers/acpi/executer/exmisc.c - 1.2 drivers/acpi/executer/exmutex.c - 1.2 drivers/acpi/executer/exnames.c - 1.2 drivers/acpi/executer/exoparg1.c - 1.2 drivers/acpi/executer/exoparg2.c - 1.2 drivers/acpi/executer/exoparg3.c - 1.2 drivers/acpi/executer/exoparg6.c - 1.2 drivers/acpi/executer/exprep.c - 1.2 drivers/acpi/executer/exregion.c - 1.2 drivers/acpi/executer/exresnte.c - 1.2 drivers/acpi/executer/exresolv.c - 1.2 drivers/acpi/executer/exresop.c - 1.2 drivers/acpi/executer/exstore.c - 1.2 drivers/acpi/executer/exstoren.c - 1.2 drivers/acpi/executer/exstorob.c - 1.2 drivers/acpi/executer/exsystem.c - 1.2 drivers/acpi/executer/exutils.c - 1.2 drivers/acpi/fan.c - 1.2 drivers/acpi/hardware/hwacpi.c - 1.2 drivers/acpi/hardware/hwgpe.c - 1.2 drivers/acpi/hardware/hwregs.c - 1.2 drivers/acpi/hardware/hwsleep.c - 1.2 drivers/acpi/hardware/hwtimer.c - 1.2 drivers/acpi/namespace/nsaccess.c - 1.2 drivers/acpi/namespace/nsalloc.c - 1.2 drivers/acpi/namespace/nsdump.c - 1.2 drivers/acpi/namespace/nsdumpdv.c - 1.2 drivers/acpi/namespace/nseval.c - 1.2 drivers/acpi/namespace/nsinit.c - 1.2 drivers/acpi/namespace/nsload.c - 1.2 drivers/acpi/namespace/nsnames.c - 1.2 drivers/acpi/namespace/nsobject.c - 1.2 drivers/acpi/namespace/nsparse.c - 1.2 drivers/acpi/namespace/nssearch.c - 1.2 drivers/acpi/namespace/nsutils.c - 1.2 drivers/acpi/namespace/nswalk.c - 1.2 drivers/acpi/namespace/nsxfeval.c - 1.2 drivers/acpi/namespace/nsxfname.c - 1.2 drivers/acpi/namespace/nsxfobj.c - 1.2 drivers/acpi/osl.c - 1.2 drivers/acpi/parser/psargs.c - 1.2 drivers/acpi/parser/psopcode.c - 1.2 drivers/acpi/parser/psparse.c - 1.2 drivers/acpi/parser/psscope.c - 1.2 drivers/acpi/parser/pstree.c - 1.2 drivers/acpi/parser/psutils.c - 1.2 drivers/acpi/parser/pswalk.c - 1.2 drivers/acpi/parser/psxface.c - 1.2 drivers/acpi/power.c - 1.2 drivers/acpi/processor.c - 1.2 drivers/acpi/resources/rsaddr.c - 1.2 drivers/acpi/resources/rscalc.c - 1.2 drivers/acpi/resources/rscreate.c - 1.2 drivers/acpi/resources/rsdump.c - 1.2 drivers/acpi/resources/rsio.c - 1.2 drivers/acpi/resources/rsirq.c - 1.2 drivers/acpi/resources/rslist.c - 1.2 drivers/acpi/resources/rsmemory.c - 1.2 drivers/acpi/resources/rsmisc.c - 1.2 drivers/acpi/resources/rsutils.c - 1.2 drivers/acpi/resources/rsxface.c - 1.2 drivers/acpi/tables.c - 1.2 drivers/acpi/tables/tbconvrt.c - 1.2 drivers/acpi/tables/tbget.c - 1.2 drivers/acpi/tables/tbgetall.c - 1.2 drivers/acpi/tables/tbinstal.c - 1.2 drivers/acpi/tables/tbrsdt.c - 1.2 drivers/acpi/tables/tbutils.c - 1.2 drivers/acpi/tables/tbxface.c - 1.2 drivers/acpi/tables/tbxfroot.c - 1.2 drivers/acpi/thermal.c - 1.2 drivers/acpi/toshiba_acpi.c - 1.2 drivers/acpi/utilities/utalloc.c - 1.2 drivers/acpi/utilities/utcopy.c - 1.2 drivers/acpi/utilities/utdebug.c - 1.2 drivers/acpi/utilities/utdelete.c - 1.2 drivers/acpi/utilities/uteval.c - 1.2 drivers/acpi/utilities/utglobal.c - 1.2 drivers/acpi/utilities/utinit.c - 1.2 drivers/acpi/utilities/utmath.c - 1.2 drivers/acpi/utilities/utmisc.c - 1.2 drivers/acpi/utilities/utobject.c - 1.2 drivers/acpi/utilities/utxface.c - 1.2 drivers/atm/horizon.c - 1.2 drivers/block/cpqarray.c - 1.2 drivers/char/alim7101_wdt.c - 1.2 drivers/i2c/i2c-philips-par.c - 1.3 drivers/ide/Config.in - 1.3 drivers/ide/raid/hptraid.c - 1.2 drivers/message/fusion/isense.c - 1.2 drivers/message/fusion/linux_compat.h - 1.2 drivers/message/fusion/lsi/mpi.h - 1.2 drivers/message/fusion/lsi/mpi_cnfg.h - 1.2 drivers/message/fusion/lsi/mpi_init.h - 1.2 drivers/message/fusion/lsi/mpi_ioc.h - 1.2 drivers/message/fusion/lsi/mpi_raid.h - 1.2 drivers/message/fusion/lsi/mpi_targ.h - 1.2 drivers/message/fusion/mptbase.c - 1.2 drivers/message/fusion/mptbase.h - 1.2 drivers/message/fusion/mptctl.c - 1.2 drivers/message/fusion/mptctl.h - 1.2 drivers/message/fusion/mptscsih.c - 1.2 drivers/message/fusion/mptscsih.h - 1.2 drivers/message/fusion/scsi3.h - 1.2 drivers/net/8139cp.c - 1.2 drivers/net/ns83820.c - 1.2 drivers/net/pcmcia/xircom_cb.c - 1.2 drivers/net/tokenring/olympic.c - 1.2 drivers/net/wan/pc300_drv.c - 1.2 drivers/pci/pci.ids - 1.2 drivers/sbus/char/flash.c - 1.2 drivers/scsi/aha152x.c - 1.2 drivers/scsi/fdomain.c - 1.2 drivers/scsi/qlogicfas.c - 1.2 drivers/usb/Config.in - 1.2 drivers/usb/Makefile - 1.2 drivers/usb/auermain.c - 1.2 drivers/usb/ax8817x.c - 1.2 drivers/usb/gadget/Config.in - 1.2 drivers/usb/gadget/Makefile - 1.2 drivers/usb/gadget/ether.c - 1.2 drivers/usb/gadget/net2280.c - 1.2 drivers/usb/gadget/net2280.h - 1.2 drivers/usb/gadget/zero.c - 1.2 drivers/usb/hid-core.c - 1.3 drivers/usb/host/ehci-dbg.c - 1.2 drivers/usb/host/ehci-hcd.c - 1.2 drivers/usb/host/ehci-mem.c - 1.2 drivers/usb/host/ehci-q.c - 1.2 drivers/usb/host/ehci-sched.c - 1.2 drivers/usb/host/ehci.h - 1.2 drivers/usb/host/sl811.c - 1.2 drivers/usb/host/usb-ohci.c - 1.2 drivers/usb/host/usb-ohci.h - 1.2 drivers/usb/host/usb-uhci.c - 1.3 drivers/usb/inode.c - 1.2 drivers/usb/serial/ir-usb.c - 1.2 drivers/usb/serial/visor.c - 1.2 drivers/usb/serial/visor.h - 1.2 drivers/usb/storage/transport.c - 1.2 drivers/usb/storage/unusual_devs.h - 1.2 drivers/usb/storage/usb.c - 1.3 drivers/usb/usb.c - 1.2 fs/Config.in - 1.3 fs/smbfs/ChangeLog - 1.2 fs/smbfs/Makefile - 1.2 fs/smbfs/dir.c - 1.2 fs/smbfs/file.c - 1.2 fs/smbfs/inode.c - 1.2 fs/smbfs/proc.c - 1.2 fs/smbfs/proto.h - 1.2 include/acpi/acconfig.h - 1.2 include/acpi/acdebug.h - 1.2 include/acpi/acdisasm.h - 1.2 include/acpi/acdispat.h - 1.2 include/acpi/acevents.h - 1.2 include/acpi/acexcep.h - 1.2 include/acpi/acglobal.h - 1.2 include/acpi/achware.h - 1.2 include/acpi/acinterp.h - 1.2 include/acpi/aclocal.h - 1.2 include/acpi/acmacros.h - 1.2 include/acpi/acnamesp.h - 1.2 include/acpi/acobject.h - 1.2 include/acpi/acoutput.h - 1.2 include/acpi/acparser.h - 1.2 include/acpi/acpi.h - 1.2 include/acpi/acpiosxf.h - 1.2 include/acpi/acpixf.h - 1.2 include/acpi/acresrc.h - 1.2 include/acpi/acstruct.h - 1.2 include/acpi/actables.h - 1.2 include/acpi/actbl.h - 1.2 include/acpi/actbl1.h - 1.2 include/acpi/actbl2.h - 1.2 include/acpi/actypes.h - 1.2 include/acpi/acutils.h - 1.2 include/acpi/amlcode.h - 1.2 include/acpi/amlresrc.h - 1.2 include/acpi/platform/acenv.h - 1.2 include/acpi/platform/acgcc.h - 1.2 include/acpi/platform/aclinux.h - 1.2 include/asm-alpha/elf.h - 1.2 include/asm-alpha/system.h - 1.2 include/asm-i386/timex.h - 1.2 include/asm-x86_64/desc.h - 1.2 include/asm-x86_64/uaccess.h - 1.2 include/asm-x86_64/unistd.h - 1.2 include/linux/console.h - 1.2 include/linux/pci_ids.h - 1.2 include/linux/smb.h - 1.2 include/linux/smb_fs.h - 1.2 include/linux/smb_fs_sb.h - 1.2 include/linux/smb_mount.h - 1.2 include/linux/smbno.h - 1.2 include/linux/usb_gadget.h - 1.2 net/ipv4/igmp.c - 1.3 net/ipv6/mcast.c - 1.3 arch/ppc/configs/cpci405_defconfig - 1.2 drivers/net/irda/via-ircc.c - 1.2 arch/mips/defconfig-pb1550 - 1.2 From owner-linux-xfs@oss.sgi.com Thu Jan 29 17:13:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Jan 2004 17:13:08 -0800 (PST) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0U1D57J027408 for ; Thu, 29 Jan 2004 17:13:05 -0800 Received: from hpti7.fsl.noaa.gov ([137.75.132.227]) by hptimail01.HPTI.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jan 2004 20:13:03 -0500 Subject: Data corruption with xfs+nfs+lvm From: Craig Tierney To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1075423747.3859.280.camel@hpti7.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 29 Jan 2004 17:49:07 -0700 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2004 01:13:03.0499 (UTC) FILETIME=[35B19DB0:01C3E6CE] X-archive-position: 1927 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctierney@HPTI.com Precedence: bulk X-list: linux-xfs Content-Length: 1760 Lines: 43 I have just discovered that I am having problems with data corruption on my NFS servers and XFS. It happens in several different cases, but all under load. Here are the cases that I have gotten data corruption for reads and writes. Corruption happens on different servers and on different filesystems (some configured with LVM striping, some not). linux-2.4.20, xfs 1.2, lvm 1.0.5, qlogic 6.01.0, - Trond's nfs patches available at the time applied to kernel linux-2.4.21, xfs 1.3.1, lvm 1.0.8, qlogic 6.06.10 - stock NFS (no patches applied) NFS is configured as vers=3,udp,async,rsize=wsize=8192,nolock,hard We tested a dual P3 and a dual Xeon with the linux-2.4.20 kernel setup. We were able to generate corruption on both servers. We tested the new linux-2.4.21 kernel on the dual P3. All servers are using the tg3 driver (broadcom gigE). All clients are using the e100 driver (Intel's eepro driver). The file writes are from single processes. Some codes are MPI, but all the IO, reads and writes, go through the rank 0 node. We can reproduce the corruption relatively easy when 16 processes are active. We do not see the corruption on nfs+xfs when running just 1 case at a time. Running linux-2.4.20, lvm 1.0.5, and ext2/3 does not show the problem, but it is just a bunch slower. We ran the suite of test cases several times and could not trigger a problem. The structure of the corruption can vary. One case I saw difference in the binary files for a span of 49k out of 102MB. Another case had differences spread over a much larger region. The differences in data are different, but non-zero values. If anyone has suggestions on what to try or test to determine what is wrong, I would love to hear it. Thanks, Craig From owner-linux-xfs@oss.sgi.com Thu Jan 29 18:44:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Jan 2004 18:44:33 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0U2iI7J031681 for ; Thu, 29 Jan 2004 18:44:18 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i0U2iBmb023683 for ; Thu, 29 Jan 2004 20:44:12 -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 NAA00977; Fri, 30 Jan 2004 13:44:10 +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 i0U2i5Uc2895319; Fri, 30 Jan 2004 13:44:06 +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 i0U2hl7P001587; Fri, 30 Jan 2004 13:43:47 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i0U2hhtV001585; Fri, 30 Jan 2004 13:43:43 +1100 Date: Fri, 30 Jan 2004 13:43:43 +1100 From: Nathan Scott To: Craig Tierney , cattelan@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: Data corruption with xfs+nfs+lvm Message-ID: <20040130024343.GC1062@frodo> References: <1075423747.3859.280.camel@hpti7.fsl.noaa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1075423747.3859.280.camel@hpti7.fsl.noaa.gov> User-Agent: Mutt/1.5.3i X-archive-position: 1928 X-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: 1277 Lines: 33 On Thu, Jan 29, 2004 at 05:49:07PM -0700, Craig Tierney wrote: > I have just discovered that I am having problems with data corruption > on my NFS servers and XFS. It happens in several different cases, but > all under load. Here are the cases that I have gotten data corruption > for reads and writes. Corruption happens on different servers and > on different filesystems (some configured with LVM striping, some not). Can you descibe your test case in more detail? In particular, do you have a program/programs that demonstrates the problem? That is always a huge help. Or a list of things to run - what sort of IO is being done, and what does "under load" mean in your context. > We tested the new linux-2.4.21 kernel on the dual P3. "new" and "2.4.21" don't really go together. :) > The file writes are from single processes. Some codes are MPI, but > all the IO, reads and writes, go through the rank 0 node. We can > reproduce the corruption relatively easy when 16 processes are active. Can you give me a recipe so that I can reproduce it locally? Does NFS have to be in the picture for this to fail? And is it reproducible without LVM too? Russell, does this sound like that NFS corruption that you were looking into awhile back? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jan 29 20:33:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Jan 2004 20:33:20 -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 i0U4XI7J005694 for ; Thu, 29 Jan 2004 20:33:19 -0800 Received: from [10.0.0.22] (c-24-118-170-148.mn.client2.attbi.com [24.118.170.148]) by lips.borg.umn.edu (8.12.11/8.12.11) with ESMTP id i0U4XAhl062796; Thu, 29 Jan 2004 22:33:14 -0600 (CST) (envelope-from cattelan@thebarn.com) In-Reply-To: <20040130024343.GC1062@frodo> References: <1075423747.3859.280.camel@hpti7.fsl.noaa.gov> <20040130024343.GC1062@frodo> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6F51E0CE-52DD-11D8-B9F1-0003935AF3D2@thebarn.com> Content-Transfer-Encoding: 7bit Cc: cattelan@sgi.com, linux-xfs@oss.sgi.com, Craig Tierney From: Russell Cattelan Subject: Re: Data corruption with xfs+nfs+lvm Date: Thu, 29 Jan 2004 22:33:21 -0600 To: Nathan Scott X-Mailer: Apple Mail (2.609) X-archive-position: 1929 X-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: 1684 Lines: 48 On Jan 29, 2004, at 8:43 PM, Nathan Scott wrote: > On Thu, Jan 29, 2004 at 05:49:07PM -0700, Craig Tierney wrote: >> I have just discovered that I am having problems with data corruption >> on my NFS servers and XFS. It happens in several different cases, but >> all under load. Here are the cases that I have gotten data corruption >> for reads and writes. Corruption happens on different servers and >> on different filesystems (some configured with LVM striping, some >> not). > > Can you descibe your test case in more detail? In particular, > do you have a program/programs that demonstrates the problem? > That is always a huge help. Or a list of things to run - what > sort of IO is being done, and what does "under load" mean in > your context. > >> We tested the new linux-2.4.21 kernel on the dual P3. > > "new" and "2.4.21" don't really go together. :) > >> The file writes are from single processes. Some codes are MPI, but >> all the IO, reads and writes, go through the rank 0 node. We can >> reproduce the corruption relatively easy when 16 processes are active. > > Can you give me a recipe so that I can reproduce it locally? > Does NFS have to be in the picture for this to fail? And is > it reproducible without LVM too? > > Russell, does this sound like that NFS corruption that you > were looking into awhile back? Yes it does. I still don't have any idea as to what is going wrong, I think somehow there is a race someplace when a close happens and the pages beyond eof that get flushed. http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 comment out the xfs_refcache_purge_some and see if the corruption goes away. > > cheers. > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Fri Jan 30 04:51:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 04:52:13 -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 i0UCpu7J029458 for ; Fri, 30 Jan 2004 04:51:57 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AmY7n-0005QF-MJ; Fri, 30 Jan 2004 12:51:55 +0000 Date: Fri, 30 Jan 2004 12:51:55 +0000 From: Christoph Hellwig To: Tomaz Beltram Cc: linux-xfs@oss.sgi.com Subject: Re: can't use iget on XFS Message-ID: <20040130125155.A20815@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from tomazb@hotmail.com on Wed, Jan 28, 2004 at 04:14:47PM +0000 X-archive-position: 1930 X-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: 1309 Lines: 36 On Wed, Jan 28, 2004 at 04:14:47PM +0000, Tomaz Beltram wrote: > In some cases the filter module has to call iget instead of lookup, since it > doesn't have the full pathname of the file but just its inode number (ino). > On XFS this only works when the inode is found in the cache. If it has to be > loaded from disk it oops-es. This is because iget calls read_inode which is > not implemented in XFS and just jumps to nowhere. Simple answer: Don't do that. iget something only the filesystem may call. > We are considering to call xfs_iget instead of iget, but are not aware of > all functional implications this might have. Could someone explain if this > is the correct sequence to be called and why not: > > > struct super_block *sb; > struct inode *inode; > > vfs_t *vfsp = LINVFS_GET_VFS(sb); > xfs_mount_t *mp = XFS_BHVTOM(vfsp->vfs_fbhv); > > xfs_inode_t *ip = NULL; > > int error = xfs_iget(mp, NULL, ino, XFS_ILOCK_SHARED, &ip, 0); > > vnode_t *vpp = XFS_ITOV(ip); > inode = LINVFS_GET_IP(vpp); > > /* access inode, e.g. read extended attributes */ > > xfs_iunlock(ip, XFS_ILOCK_SHARED); This is bollocks. You are absolutely not supposed to mess with filesystem interanls. Use the exposed interface instead (s_ops->fh_to_dentry in 2.4, the export_operations in 2.6) From owner-linux-xfs@oss.sgi.com Fri Jan 30 07:37:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 07:37: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 i0UFbF7J004199 for ; Fri, 30 Jan 2004 07:37:15 -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 i0UFaPUX031930 for ; Fri, 30 Jan 2004 07:36:26 -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.10/SGI_generic_relay-1.2) with ESMTP id i0UFZji232356521; Fri, 30 Jan 2004 09:35:46 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AmagL-0002uc-00; Fri, 30 Jan 2004 09:35:45 -0600 Subject: TAKE 908648 - Fix gcc 3.5 compilations Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Fri, 30 Jan 2004 09:35:45 -0600 X-archive-position: 1931 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 325 Lines: 13 Date: Fri Jan 30 07:34:58 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:165754a fs/xfs/xfs_buf_item.c - 1.147 - use XFS_BUF_SET_FSPRIVATE properly to set bufer private data From owner-linux-xfs@oss.sgi.com Fri Jan 30 08:16:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 08:16:46 -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 i0UGGd7J005908 for ; Fri, 30 Jan 2004 08:16:40 -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 <0HSB0030197ML0@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Fri, 30 Jan 2004 10:16:39 -0600 (CST) Received: from maxwell.fnal.gov (maxwell.fnal.gov [131.225.54.225]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTPS id <0HSB000UG97QGZ@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Fri, 30 Jan 2004 10:16:39 -0600 (CST) Date: Fri, 30 Jan 2004 10:16:38 -0600 (CST) From: Chris Green Subject: Re: XFS patched RHELv3 kernels now available - please test In-reply-to: <40197777.1010103@fnal.gov> To: Dan Yocum Cc: "linux-users@fnal.gov" , linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_oM4E2YmeG556bJworDDhYg)" X-archive-position: 1932 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greenc@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 35773 Lines: 926 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. --Boundary_(ID_oM4E2YmeG556bJworDDhYg) Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Hi, I downloaded kernel-2.4.21-4.0.1.EL.sgi1.src.rpm and accompanying xfs-modules src.rpm and built them on a Fermi Linux LTS3.0 system (based on RHEL3.0 update1), and then downloaded, built and ran the xfstests suite. Being ambitious, I had started to try to forward-port the kernel to the latest RHEL kernel, 2.4.21-9.EL, but reverted to the packaged 2.4.21-4.0.1.EL when I encountered xfstest failures. The good news is that the failures are the same betwen the "official" 2.4.21-4.0.1.EL and my attempt to port to 2.4.21-9.EL. The bad news is that there were failures. I tested this on a Polywell server (single-CPU, Hyperthreading) with SATA RAID (2x160GB on a 3Ware 8006-2, 11x160GB on each of two 8506-12s) with the test partitions, initially ~70GB each and one final test with 640MB each, both on the RAID1 system disk. The test results are attached above. Apart from the failure of test 005 which was expected, and the failure of any test that used xfsdump or xfsrestore since I don't have access to a tape device, I believe the worrying failures are 073, 079 and 080. The failures are identical (within expected differences like $$-expansion) between the three attached log files. At the request of Dan Yocum, our local informal contact with the SGI team, I'm posting these experiences on the linux-xfs list. If I have mis-run the tests in any way (./check -g auto) or misinterpreted the results, I would be happy to hear about it. Comments appreciated, Chris. On Thu, 29 Jan 2004, Dan Yocum wrote: > I've tested the kernel on a RH7.3 machine and it completes the xfstests > successfully (except for one minor symbolic links test - which is expected > on a RH7.3 machine). > > The SGI folks would appreciate any feedback you might have on your > experiences using this kernel, good or bad. Please post them to the > linux-xfs@oss.sgi.com mailing list. > > Thanks, > Dan > > > Dan Yocum wrote: > > The SGI folks have released the latest RHELv3 kernels patched with the > > latest version of XFS. The RPMS are available here: > > > > ftp://oss.sgi.com/projects/xfs/testing/RHEL/RPMS/ > > > > They have passed the xfstests (available via cvs from the XFS site) on > > their > > hardware, but they'd also appreciate real world testing. > > > > The distribution is slightly different than what we're used to - there is a > > "generic" kernel RPM along with an additional xfs-modules RPM. > > > > Cheers, > > Dan > > > > -- > > Dan Yocum > > Sloan Digital Sky Survey, Fermilab 630.840.6509 > > yocum@fnal.gov, http://www.sdss.org > > SDSS. Mapping the Universe. There is no spoon. > > > > -- > Dan Yocum > Sloan Digital Sky Survey, Fermilab 630.840.6509 > yocum@fnal.gov, http://www.sdss.org > SDSS. Mapping the Universe. There is no spoon. > -- Chris Green, MiniBooNE / LANL. Email greenc@fnal.gov Tel: (630) 840-2167. Fax: (630) 840-3867 --Boundary_(ID_oM4E2YmeG556bJworDDhYg) Content-id: Content-type: TEXT/PLAIN; charset=US-ASCII; name=xfstest_2.4.21_9.EL.sgi1smp.out Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=xfstest_2.4.21_9.EL.sgi1smp.out Content-description: make: Nothing to be done for `default'. MKFS_OPTIONS -- -bsize=4096 /dev/sda7 MOUNT_OPTIONS -- -ologbufs=2 /dev/sda7 /scratch2 001 25s ... 002 1s ... 003 10s ... 004 28s ... 005 - output mismatch (see 005.out.bad) 4,6d3 < touch: symlink_05: Too many levels of symbolic links < touch: symlink_06: Too many levels of symbolic links < touch: symlink_07: Too many levels of symbolic links 006 184s ... 007 327s ... 008 20s ... 009 21s ... 010 011 286s ... 012 17s ... 013 014 015 016 017 018 019 020 021 022 [not run] No dump tape specified 023 [not run] No dump tape specified 024 [not run] No dump tape specified 025 [not run] No dump tape specified 026 - output mismatch (see 026.out.bad) 37a38,39 > xfsrestore: WARNING: open_by_handle of dumpdir/sub failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 027 - output mismatch (see 027.out.bad) 24a25,26 > xfsrestore: WARNING: open_by_handle of dumpdir/sub failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 028 029 030 031 032 033 034 035 [not run] No dump tape specified 036 [not run] No dump tape specified 037 [not run] No dump tape specified 038 [not run] No dump tape specified 039 [not run] No dump tape specified 040 [not run] Can't run srcdiff without KWORKAREA set 041 042 043 [not run] No dump tape specified 044 [not run] This test requires a valid $SCRATCH_LOGDEV 045 046 - output mismatch (see 046.out.bad) 37a38,39 > xfsrestore: WARNING: open_by_handle of dumpdir/sub failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 047 048 049 050 [not run] No quota support at mount time 051 052 [not run] No quota support at mount time 053 054 055 [not run] mt -f @ failed 056 - output mismatch (see 056.out.bad) 37a38,43 > xfsrestore: WARNING: open_by_handle of dumpdir/dir_mix2 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_mix1 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_sticky failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_guid failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_suid failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 057 [not run] IRIX acl_get semantics no longer required 058 [not run] acl_test.c requires the IRIX ACL API 061 - output mismatch (see 061.out.bad) 24a25,30 > xfsrestore: WARNING: open_by_handle of dumpdir/dir_suid failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_mix2 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_mix1 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_guid failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_sticky failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 062 063 - output mismatch (see 063.out.bad) 12a13,28 > .Attribute "XFS_XFLAG_REALTIME" set to a 10 byte value for xflag_realtime: > some_text5 > .Attribute "XFS_XFLAG_PREALLOC" set to a 10 byte value for xflag_prealloc: > some_text6 > .Attribute "XFS_XFLAG_IMMUTABLE" set to a 10 byte value for xflag_immutable: > some_text7 > .Attribute "XFS_XFLAG_APPEND" set to a 10 byte value for xflag_append: > some_text8 > .Attribute "XFS_XFLAG_SYNC" set to a 10 byte value for xflag_sync: > some_text9 > .Attribute "XFS_XFLAG_NOATIME" set to a 11 byte value for xflag_noatime: > some_text10 > .Attribute "XFS_XFLAG_NODUMP" set to a 11 byte value for xflag_nodump: > some_text11 > .Attribute "XFS_XFLAG_HASATTR" set to a 11 byte value for xflag_hasattr: > some_text12 45c61 < xfsrestore: 4 directories and 21 entries processed --- > xfsrestore: 4 directories and 29 entries processed 47a64,66 > xfsrestore: WARNING: open_by_handle of dumpdir/dir failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/sub failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 64a84,99 > Attribute "XFS_XFLAG_APPEND" had a 10 byte value for DUMP_DIR/xflag_append: > some_text8 > Attribute "XFS_XFLAG_HASATTR" had a 11 byte value for DUMP_DIR/xflag_hasattr: > some_text12 > Attribute "XFS_XFLAG_IMMUTABLE" had a 10 byte value for DUMP_DIR/xflag_immutable: > some_text7 > Attribute "XFS_XFLAG_NOATIME" had a 11 byte value for DUMP_DIR/xflag_noatime: > some_text10 > Attribute "XFS_XFLAG_NODUMP" had a 11 byte value for DUMP_DIR/xflag_nodump: > some_text11 > Attribute "XFS_XFLAG_PREALLOC" had a 10 byte value for DUMP_DIR/xflag_prealloc: > some_text6 > Attribute "XFS_XFLAG_REALTIME" had a 10 byte value for DUMP_DIR/xflag_realtime: > some_text5 > Attribute "XFS_XFLAG_SYNC" had a 10 byte value for DUMP_DIR/xflag_sync: > some_text9 77a113,128 > Attribute "XFS_XFLAG_APPEND" had a 10 byte value for DUMP_DIR/xflag_append: > some_text8 > Attribute "XFS_XFLAG_HASATTR" had a 11 byte value for DUMP_DIR/xflag_hasattr: > some_text12 > Attribute "XFS_XFLAG_IMMUTABLE" had a 10 byte value for DUMP_DIR/xflag_immutable: > some_text7 > Attribute "XFS_XFLAG_NOATIME" had a 11 byte value for DUMP_DIR/xflag_noatime: > some_text10 > Attribute "XFS_XFLAG_NODUMP" had a 11 byte value for DUMP_DIR/xflag_nodump: > some_text11 > Attribute "XFS_XFLAG_PREALLOC" had a 10 byte value for DUMP_DIR/xflag_prealloc: > some_text6 > Attribute "XFS_XFLAG_REALTIME" had a 10 byte value for DUMP_DIR/xflag_realtime: > some_text5 > Attribute "XFS_XFLAG_SYNC" had a 10 byte value for DUMP_DIR/xflag_sync: > some_text9 065 - output mismatch (see 065.out.bad) 578a579,583 > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir4 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir3 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir2 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir1 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 619a625 > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 654a661,663 > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir6 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir2 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 689a699,700 > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir6 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 728a740,741 > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir6 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 763a777 > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 794a809 > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 066 - output mismatch (see 066.out.bad) 40a41 > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 067 069 070 071 072 073 [failed, exit status 1] - output mismatch (see 073.out.bad) 50,73c50,54 < mounting new image on loopback < comparing new image files to old < comparing new image directories to old < comparing new image geometry to old < unmounting and removing new image < < === copying scratch device to multiple targets < Creating file < Creating file < 0% ... 10% ... 20% ... 30% ... 40% ... 50% ... 60% ... 70% ... 80% ... 90% ... 100% < < All copies completed. < checking new image < mounting new image on loopback < comparing new image files to old < comparing new image directories to old < comparing new image geometry to old < unmounting and removing new image < checking new image < mounting new image on loopback < comparing new image files to old < comparing new image directories to old < comparing new image geometry to old < unmounting and removing new image --- > _check_fs: filesystem on /tmp/11459.image has dirty log (see 073.full) > _check_fs: filesystem on /tmp/11459.image is inconsistent (c) (see 073.full) > _check_fs: filesystem on /tmp/11459.image is inconsistent (r) (see 073.full) > rmdir: `/tmp/11459.source_dir': Device or resource busy > rm: cannot remove `/tmp/11459.source_dir': Is a directory 074 075 077 [not run] No linux directory to source files from 078 079 [failed, exit status 1] - output mismatch (see 079.out.bad) 3,6c3,10 < testing immutable...PASS. < testing append-only...PASS. < testing immutable as non-root...PASS. < testing append-only as non-root...PASS. --- > utime(/scratch2/079/immutable.f, ) did not fail > utime(/scratch2/079/immutable.f, NULL) did not fail > utime(/scratch2/079/immutable.d, ) did not fail > utime(/scratch2/079/immutable.d, NULL) did not fail > utime(/scratch2/079/append-only.f, ) did not fail > utime(/scratch2/079/append-only.d, ) did not fail > testing immutable...FAILED! (4 tests failed) > testing append-only...FAILED! (2 tests failed) 080 [failed, exit status 2] - output mismatch (see 080.out.bad) 3c3,29 < Completed rwtest pass 1 successfully. --- > > doio (14118) 18:49:35 > --------------------- > mmap() failed - 0xffffffff 12 > > doio (14118) 18:49:35 > --------------------- > mmap-write() request failed: Cannot allocate memory (12) > Request number 18 > fd 11 is file /scratch/rwtest.file - open flags are 040002 O_RDWR,O_DIRECT, > write done at file offset 937984 - pattern is G (0107) > number of requests is 1, strides per request is 1 > i/o byte count = 106496 > memory alignment is aligned > DIRECT I/O: offset % 4096 = 0 length % 106496 = 0 > mem alignment 0x1000 xfer size: small: 4096 large: 524288 > > syscall: mmap-write(NULL, 512000000, PROT_WRITE, MAP_SHARED, 11, 0) > file is mmaped to: 0x0 > file-mem=0xe5000, length=106496, buffer=0x8072000 > > > doio (14118) 18:49:35 > --------------------- > doio(): operation 121 returned != 0 > /root/xfstests/ltp/rwtest.sh: line 414: 14117 Broken pipe $IOgen ${iOpts} ${Files} > rwtest.sh : iogen reported errors (r=141) 083 Not run: 022 023 024 025 035 036 037 038 039 040 043 044 050 052 055 057 058 077 Failures: 005 026 027 046 056 061 063 065 066 073 079 080 Failed 12 of 58 tests --Boundary_(ID_oM4E2YmeG556bJworDDhYg) Content-id: Content-type: TEXT/PLAIN; charset=US-ASCII; name=xfstest_2.4.21_4.0.1.EL.sgi1smp_640M.out Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=xfstest_2.4.21_4.0.1.EL.sgi1smp_640M.out Content-description: make: Nothing to be done for `default'. MKFS_OPTIONS -- -bsize=4096 /dev/sda7 MOUNT_OPTIONS -- -ologbufs=2 /dev/sda7 /scratch2 001 002 003 004 005 - output mismatch (see 005.out.bad) 4,6d3 < touch: symlink_05: Too many levels of symbolic links < touch: symlink_06: Too many levels of symbolic links < touch: symlink_07: Too many levels of symbolic links 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 [not run] No dump tape specified 023 [not run] No dump tape specified 024 [not run] No dump tape specified 025 [not run] No dump tape specified 026 - output mismatch (see 026.out.bad) 37a38,39 > xfsrestore: WARNING: open_by_handle of dumpdir/sub failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 027 - output mismatch (see 027.out.bad) 24a25,26 > xfsrestore: WARNING: open_by_handle of dumpdir/sub failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 028 029 030 031 032 033 034 035 [not run] No dump tape specified 036 [not run] No dump tape specified 037 [not run] No dump tape specified 038 [not run] No dump tape specified 039 [not run] No dump tape specified 040 [not run] Can't run srcdiff without KWORKAREA set 041 042 043 [not run] No dump tape specified 044 [not run] This test requires a valid $SCRATCH_LOGDEV 045 046 - output mismatch (see 046.out.bad) 37a38,39 > xfsrestore: WARNING: open_by_handle of dumpdir/sub failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 047 048 049 050 [not run] No quota support at mount time 051 052 [not run] No quota support at mount time 053 054 055 [not run] mt -f @ failed 056 - output mismatch (see 056.out.bad) 37a38,43 > xfsrestore: WARNING: open_by_handle of dumpdir/dir_mix2 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_mix1 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_sticky failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_guid failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_suid failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 057 [not run] IRIX acl_get semantics no longer required 058 [not run] acl_test.c requires the IRIX ACL API 061 - output mismatch (see 061.out.bad) 24a25,30 > xfsrestore: WARNING: open_by_handle of dumpdir/dir_suid failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_mix2 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_mix1 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_guid failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_sticky failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 062 063 - output mismatch (see 063.out.bad) 12a13,28 > .Attribute "XFS_XFLAG_REALTIME" set to a 10 byte value for xflag_realtime: > some_text5 > .Attribute "XFS_XFLAG_PREALLOC" set to a 10 byte value for xflag_prealloc: > some_text6 > .Attribute "XFS_XFLAG_IMMUTABLE" set to a 10 byte value for xflag_immutable: > some_text7 > .Attribute "XFS_XFLAG_APPEND" set to a 10 byte value for xflag_append: > some_text8 > .Attribute "XFS_XFLAG_SYNC" set to a 10 byte value for xflag_sync: > some_text9 > .Attribute "XFS_XFLAG_NOATIME" set to a 11 byte value for xflag_noatime: > some_text10 > .Attribute "XFS_XFLAG_NODUMP" set to a 11 byte value for xflag_nodump: > some_text11 > .Attribute "XFS_XFLAG_HASATTR" set to a 11 byte value for xflag_hasattr: > some_text12 45c61 < xfsrestore: 4 directories and 21 entries processed --- > xfsrestore: 4 directories and 29 entries processed 47a64,66 > xfsrestore: WARNING: open_by_handle of dumpdir/dir failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/sub failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 64a84,99 > Attribute "XFS_XFLAG_APPEND" had a 10 byte value for DUMP_DIR/xflag_append: > some_text8 > Attribute "XFS_XFLAG_HASATTR" had a 11 byte value for DUMP_DIR/xflag_hasattr: > some_text12 > Attribute "XFS_XFLAG_IMMUTABLE" had a 10 byte value for DUMP_DIR/xflag_immutable: > some_text7 > Attribute "XFS_XFLAG_NOATIME" had a 11 byte value for DUMP_DIR/xflag_noatime: > some_text10 > Attribute "XFS_XFLAG_NODUMP" had a 11 byte value for DUMP_DIR/xflag_nodump: > some_text11 > Attribute "XFS_XFLAG_PREALLOC" had a 10 byte value for DUMP_DIR/xflag_prealloc: > some_text6 > Attribute "XFS_XFLAG_REALTIME" had a 10 byte value for DUMP_DIR/xflag_realtime: > some_text5 > Attribute "XFS_XFLAG_SYNC" had a 10 byte value for DUMP_DIR/xflag_sync: > some_text9 77a113,128 > Attribute "XFS_XFLAG_APPEND" had a 10 byte value for DUMP_DIR/xflag_append: > some_text8 > Attribute "XFS_XFLAG_HASATTR" had a 11 byte value for DUMP_DIR/xflag_hasattr: > some_text12 > Attribute "XFS_XFLAG_IMMUTABLE" had a 10 byte value for DUMP_DIR/xflag_immutable: > some_text7 > Attribute "XFS_XFLAG_NOATIME" had a 11 byte value for DUMP_DIR/xflag_noatime: > some_text10 > Attribute "XFS_XFLAG_NODUMP" had a 11 byte value for DUMP_DIR/xflag_nodump: > some_text11 > Attribute "XFS_XFLAG_PREALLOC" had a 10 byte value for DUMP_DIR/xflag_prealloc: > some_text6 > Attribute "XFS_XFLAG_REALTIME" had a 10 byte value for DUMP_DIR/xflag_realtime: > some_text5 > Attribute "XFS_XFLAG_SYNC" had a 10 byte value for DUMP_DIR/xflag_sync: > some_text9 065 - output mismatch (see 065.out.bad) 578a579,583 > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir4 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir3 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir2 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir1 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 619a625 > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 654a661,663 > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir6 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir2 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 689a699,700 > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir6 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 728a740,741 > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir6 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 763a777 > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 794a809 > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 066 - output mismatch (see 066.out.bad) 40a41 > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 067 069 070 071 072 073 [failed, exit status 1] - output mismatch (see 073.out.bad) 50,73c50,54 < mounting new image on loopback < comparing new image files to old < comparing new image directories to old < comparing new image geometry to old < unmounting and removing new image < < === copying scratch device to multiple targets < Creating file < Creating file < 0% ... 10% ... 20% ... 30% ... 40% ... 50% ... 60% ... 70% ... 80% ... 90% ... 100% < < All copies completed. < checking new image < mounting new image on loopback < comparing new image files to old < comparing new image directories to old < comparing new image geometry to old < unmounting and removing new image < checking new image < mounting new image on loopback < comparing new image files to old < comparing new image directories to old < comparing new image geometry to old < unmounting and removing new image --- > _check_fs: filesystem on /tmp/25277.image has dirty log (see 073.full) > _check_fs: filesystem on /tmp/25277.image is inconsistent (c) (see 073.full) > _check_fs: filesystem on /tmp/25277.image is inconsistent (r) (see 073.full) > rmdir: `/tmp/25277.source_dir': Device or resource busy > rm: cannot remove `/tmp/25277.source_dir': Is a directory 074 075 077 [not run] No linux directory to source files from 078 079 [failed, exit status 1] - output mismatch (see 079.out.bad) 3,6c3,10 < testing immutable...PASS. < testing append-only...PASS. < testing immutable as non-root...PASS. < testing append-only as non-root...PASS. --- > utime(/scratch2/079/immutable.f, ) did not fail > utime(/scratch2/079/immutable.f, NULL) did not fail > utime(/scratch2/079/immutable.d, ) did not fail > utime(/scratch2/079/immutable.d, NULL) did not fail > utime(/scratch2/079/append-only.f, ) did not fail > utime(/scratch2/079/append-only.d, ) did not fail > testing immutable...FAILED! (4 tests failed) > testing append-only...FAILED! (2 tests failed) 080 [failed, exit status 2] - output mismatch (see 080.out.bad) 3c3,27 < Completed rwtest pass 1 successfully. --- > > doio (27924) 09:17:37 > --------------------- > mmap() failed - 0xffffffff 12 > > doio (27924) 09:17:37 > --------------------- > mmap-write() request failed: Cannot allocate memory (12) > Request number 24 > fd 11 is file /scratch/rwtest.file - open flags are 010002 O_RDWR,O_SYNC, > write done at file offset 1122446 - pattern is D (0104) > number of requests is 1, strides per request is 1 > i/o byte count = 53299 > memory alignment is unaligned > > syscall: mmap-write(NULL, 512000000, PROT_WRITE, MAP_SHARED, 11, 0) > file is mmaped to: 0x0 > file-mem=0x11208e, length=53299, buffer=0x8071e85 > > > doio (27924) 09:17:37 > --------------------- > doio(): operation 121 returned != 0 > /root/xfstests/ltp/rwtest.sh: line 414: 27923 Broken pipe $IOgen ${iOpts} ${Files} > rwtest.sh : iogen reported errors (r=141) 083 Not run: 022 023 024 025 035 036 037 038 039 040 043 044 050 052 055 057 058 077 Failures: 005 026 027 046 056 061 063 065 066 073 079 080 Failed 12 of 58 tests --Boundary_(ID_oM4E2YmeG556bJworDDhYg) Content-id: Content-type: TEXT/PLAIN; charset=US-ASCII; name=xfstest_2.4.21_4.0.1.EL.sgi1smp.out Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=xfstest_2.4.21_4.0.1.EL.sgi1smp.out Content-description: make: Nothing to be done for `default'. MKFS_OPTIONS -- -bsize=4096 /dev/sda7 MOUNT_OPTIONS -- -ologbufs=2 /dev/sda7 /scratch2 001 25s ... 002 0s ... 003 0s ... 004 30s ... 005 - output mismatch (see 005.out.bad) 4,6d3 < touch: symlink_05: Too many levels of symbolic links < touch: symlink_06: Too many levels of symbolic links < touch: symlink_07: Too many levels of symbolic links 006 203s ... 007 314s ... 008 12s ... 009 20s ... 010 4s ... 011 299s ... 012 15s ... 013 1778s ... 014 1s ... 015 2s ... 016 10s ... 017 39s ... 018 54s ... 019 12s ... 020 6s ... 021 3s ... 022 [not run] No dump tape specified 023 [not run] No dump tape specified 024 [not run] No dump tape specified 025 [not run] No dump tape specified 026 - output mismatch (see 026.out.bad) 37a38,39 > xfsrestore: WARNING: open_by_handle of dumpdir/sub failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 027 - output mismatch (see 027.out.bad) 24a25,26 > xfsrestore: WARNING: open_by_handle of dumpdir/sub failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 028 26s ... 029 11s ... 030 15s ... 031 143s ... 032 108s ... 033 44s ... 034 8s ... 035 [not run] No dump tape specified 036 [not run] No dump tape specified 037 [not run] No dump tape specified 038 [not run] No dump tape specified 039 [not run] No dump tape specified 040 [not run] Can't run srcdiff without KWORKAREA set 041 40s ... 042 77s ... 043 [not run] No dump tape specified 044 [not run] This test requires a valid $SCRATCH_LOGDEV 045 4s ... 046 - output mismatch (see 046.out.bad) 37a38,39 > xfsrestore: WARNING: open_by_handle of dumpdir/sub failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 047 26s ... 048 0s ... 049 57s ... 050 [not run] No quota support at mount time 051 2s ... 052 [not run] No quota support at mount time 053 7s ... 054 11s ... 055 [not run] mt -f @ failed 056 - output mismatch (see 056.out.bad) 37a38,43 > xfsrestore: WARNING: open_by_handle of dumpdir/dir_mix2 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_mix1 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_sticky failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_guid failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_suid failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 057 [not run] IRIX acl_get semantics no longer required 058 [not run] acl_test.c requires the IRIX ACL API 061 - output mismatch (see 061.out.bad) 24a25,30 > xfsrestore: WARNING: open_by_handle of dumpdir/dir_suid failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_mix2 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_mix1 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_guid failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/dir_sticky failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 062 4s ... 063 - output mismatch (see 063.out.bad) 12a13,28 > .Attribute "XFS_XFLAG_REALTIME" set to a 10 byte value for xflag_realtime: > some_text5 > .Attribute "XFS_XFLAG_PREALLOC" set to a 10 byte value for xflag_prealloc: > some_text6 > .Attribute "XFS_XFLAG_IMMUTABLE" set to a 10 byte value for xflag_immutable: > some_text7 > .Attribute "XFS_XFLAG_APPEND" set to a 10 byte value for xflag_append: > some_text8 > .Attribute "XFS_XFLAG_SYNC" set to a 10 byte value for xflag_sync: > some_text9 > .Attribute "XFS_XFLAG_NOATIME" set to a 11 byte value for xflag_noatime: > some_text10 > .Attribute "XFS_XFLAG_NODUMP" set to a 11 byte value for xflag_nodump: > some_text11 > .Attribute "XFS_XFLAG_HASATTR" set to a 11 byte value for xflag_hasattr: > some_text12 45c61 < xfsrestore: 4 directories and 21 entries processed --- > xfsrestore: 4 directories and 29 entries processed 47a64,66 > xfsrestore: WARNING: open_by_handle of dumpdir/dir failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/sub failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 64a84,99 > Attribute "XFS_XFLAG_APPEND" had a 10 byte value for DUMP_DIR/xflag_append: > some_text8 > Attribute "XFS_XFLAG_HASATTR" had a 11 byte value for DUMP_DIR/xflag_hasattr: > some_text12 > Attribute "XFS_XFLAG_IMMUTABLE" had a 10 byte value for DUMP_DIR/xflag_immutable: > some_text7 > Attribute "XFS_XFLAG_NOATIME" had a 11 byte value for DUMP_DIR/xflag_noatime: > some_text10 > Attribute "XFS_XFLAG_NODUMP" had a 11 byte value for DUMP_DIR/xflag_nodump: > some_text11 > Attribute "XFS_XFLAG_PREALLOC" had a 10 byte value for DUMP_DIR/xflag_prealloc: > some_text6 > Attribute "XFS_XFLAG_REALTIME" had a 10 byte value for DUMP_DIR/xflag_realtime: > some_text5 > Attribute "XFS_XFLAG_SYNC" had a 10 byte value for DUMP_DIR/xflag_sync: > some_text9 77a113,128 > Attribute "XFS_XFLAG_APPEND" had a 10 byte value for DUMP_DIR/xflag_append: > some_text8 > Attribute "XFS_XFLAG_HASATTR" had a 11 byte value for DUMP_DIR/xflag_hasattr: > some_text12 > Attribute "XFS_XFLAG_IMMUTABLE" had a 10 byte value for DUMP_DIR/xflag_immutable: > some_text7 > Attribute "XFS_XFLAG_NOATIME" had a 11 byte value for DUMP_DIR/xflag_noatime: > some_text10 > Attribute "XFS_XFLAG_NODUMP" had a 11 byte value for DUMP_DIR/xflag_nodump: > some_text11 > Attribute "XFS_XFLAG_PREALLOC" had a 10 byte value for DUMP_DIR/xflag_prealloc: > some_text6 > Attribute "XFS_XFLAG_REALTIME" had a 10 byte value for DUMP_DIR/xflag_realtime: > some_text5 > Attribute "XFS_XFLAG_SYNC" had a 10 byte value for DUMP_DIR/xflag_sync: > some_text9 065 - output mismatch (see 065.out.bad) 578a579,583 > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir4 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir3 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir2 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir1 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 619a625 > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 654a661,663 > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir6 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir2 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 689a699,700 > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir6 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 728a740,741 > xfsrestore: WARNING: open_by_handle of dumpdir/addeddir6 failed:Bad file descriptor > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 763a777 > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 794a809 > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 066 - output mismatch (see 066.out.bad) 40a41 > xfsrestore: WARNING: open_by_handle of dumpdir failed:Bad file descriptor 067 5s ... 069 20s ... 070 14s ... 071 3s ... 072 2s ... 073 [failed, exit status 1] - output mismatch (see 073.out.bad) 50,73c50,54 < mounting new image on loopback < comparing new image files to old < comparing new image directories to old < comparing new image geometry to old < unmounting and removing new image < < === copying scratch device to multiple targets < Creating file < Creating file < 0% ... 10% ... 20% ... 30% ... 40% ... 50% ... 60% ... 70% ... 80% ... 90% ... 100% < < All copies completed. < checking new image < mounting new image on loopback < comparing new image files to old < comparing new image directories to old < comparing new image geometry to old < unmounting and removing new image < checking new image < mounting new image on loopback < comparing new image files to old < comparing new image directories to old < comparing new image geometry to old < unmounting and removing new image --- > _check_fs: filesystem on /tmp/26838.image has dirty log (see 073.full) > _check_fs: filesystem on /tmp/26838.image is inconsistent (c) (see 073.full) > _check_fs: filesystem on /tmp/26838.image is inconsistent (r) (see 073.full) > rmdir: `/tmp/26838.source_dir': Device or resource busy > rm: cannot remove `/tmp/26838.source_dir': Is a directory 074 147s ... 075 41s ... 077 [not run] No linux directory to source files from 078 1s ... 079 [failed, exit status 1] - output mismatch (see 079.out.bad) 3,6c3,10 < testing immutable...PASS. < testing append-only...PASS. < testing immutable as non-root...PASS. < testing append-only as non-root...PASS. --- > utime(/scratch2/079/immutable.f, ) did not fail > utime(/scratch2/079/immutable.f, NULL) did not fail > utime(/scratch2/079/immutable.d, ) did not fail > utime(/scratch2/079/immutable.d, NULL) did not fail > utime(/scratch2/079/append-only.f, ) did not fail > utime(/scratch2/079/append-only.d, ) did not fail > testing immutable...FAILED! (4 tests failed) > testing append-only...FAILED! (2 tests failed) 080 [failed, exit status 2] - output mismatch (see 080.out.bad) 3c3,27 < Completed rwtest pass 1 successfully. --- > > doio (29478) 08:03:06 > --------------------- > mmap() failed - 0xffffffff 12 > > doio (29478) 08:03:06 > --------------------- > mmap-write() request failed: Cannot allocate memory (12) > Request number 49 > fd 11 is file /scratch/rwtest.file - open flags are 02 O_RDWR, > write done at file offset 2924987 - pattern is H (0110) > number of requests is 1, strides per request is 1 > i/o byte count = 37992 > memory alignment is unaligned > > syscall: mmap-write(NULL, 512000000, PROT_WRITE, MAP_SHARED, 11, 0) > file is mmaped to: 0x0 > file-mem=0x2ca1bb, length=37992, buffer=0x5bbaa00d > > > doio (29478) 08:03:06 > --------------------- > doio(): operation 121 returned != 0 > /root/xfstests/ltp/rwtest.sh: line 414: 29477 Broken pipe $IOgen ${iOpts} ${Files} > rwtest.sh : iogen reported errors (r=141) 083 61s ... Not run: 022 023 024 025 035 036 037 038 039 040 043 044 050 052 055 057 058 077 Failures: 005 026 027 046 056 061 063 065 066 073 079 080 Failed 12 of 58 tests --Boundary_(ID_oM4E2YmeG556bJworDDhYg) Content-id: Content-type: TEXT/PLAIN; charset=US-ASCII; name=local.config Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=local.config Content-description: TEST_DEV=/dev/sda6 TEST_DIR=/scratch SCRATCH_DEV=/dev/sda7 SCRATCH_MNT=/scratch2 --Boundary_(ID_oM4E2YmeG556bJworDDhYg)-- From owner-linux-xfs@oss.sgi.com Fri Jan 30 08:50:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 08:50:22 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0UGoI7J010097 for ; Fri, 30 Jan 2004 08:50:19 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0UGoD3J012216 for ; Fri, 30 Jan 2004 10:50: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.10/SGI_generic_relay-1.2) with ESMTP id i0UGoCi232241212; Fri, 30 Jan 2004 10:50: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 i0UGoC0m584758; Fri, 30 Jan 2004 10:50:12 -0600 (CST) Subject: Re: XFS patched RHELv3 kernels now available - please test From: Eric Sandeen To: Chris Green Cc: Dan Yocum , "linux-users@fnal.gov" , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1075481411.30025.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 30 Jan 2004 10:50:12 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1933 X-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: 2350 Lines: 55 I've got it forward-ported to the latest errata kernel as well, I'll update that on the ftp site soon (BTW: ftp://oss.sgi.com/projects/xfs/testing/RHEL for those just joining us...) I'll have to sort out which of the xfsqa failures are unique to RHEL, and which are having trouble in general. Also a note, please read the README in the above dir for details on what's different in this kernel - of note, devfs is turned on, and this version of xfs is a bit different from what's currently in cvs, that may change in the future but this is the result of an internal build, tossed out onto ftp for the impatient... :) Thanks, -Eric On Fri, 2004-01-30 at 10:16, Chris Green wrote: > Hi, > > I downloaded kernel-2.4.21-4.0.1.EL.sgi1.src.rpm and accompanying > xfs-modules src.rpm and built them on a Fermi Linux LTS3.0 system (based > on RHEL3.0 update1), and then downloaded, built and ran the xfstests > suite. Being ambitious, I had started to try to forward-port the kernel to > the latest RHEL kernel, 2.4.21-9.EL, but reverted to the packaged > 2.4.21-4.0.1.EL when I encountered xfstest failures. > > The good news is that the failures are the same betwen the "official" > 2.4.21-4.0.1.EL and my attempt to port to 2.4.21-9.EL. The bad news is > that there were failures. I tested this on a Polywell server (single-CPU, > Hyperthreading) with SATA RAID (2x160GB on a 3Ware 8006-2, 11x160GB on > each of two 8506-12s) with the test partitions, initially ~70GB each and > one final test with 640MB each, both on the RAID1 system disk. > > The test results are attached above. Apart from the failure of test 005 > which was expected, and the failure of any test that used xfsdump or > xfsrestore since I don't have access to a tape device, I believe the > worrying failures are 073, 079 and 080. The failures are identical (within > expected differences like $$-expansion) between the three attached log > files. > > At the request of Dan Yocum, our local informal contact with the SGI team, > I'm posting these experiences on the linux-xfs list. If I have mis-run the > tests in any way (./check -g auto) or misinterpreted the results, I would > be happy to hear about it. > > Comments appreciated, > Chris. > -- 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 Fri Jan 30 09:04:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 09:04:43 -0800 (PST) Received: from imo-r08.mx.aol.com (imo-r08.mx.aol.com [152.163.225.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0UH4a7J010700 for ; Fri, 30 Jan 2004 09:04:37 -0800 Received: from AndyLiebman@aol.com by imo-r08.mx.aol.com (mail_out_v36_r4.12.) id 4.a3.513b6725 (30960) for ; Fri, 30 Jan 2004 12:04:27 -0500 (EST) From: AndyLiebman@aol.com Message-ID: Date: Fri, 30 Jan 2004 12:04:26 EST Subject: noatime To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5006 X-archive-position: 1934 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 372 Lines: 10 Can anybody tell me if the "noatime" flag can be used when mounting xfs partitions under Linux? Is "noatime" the default? Do you have to specify it? Is it irrelevant? Or will it get me into trouble? From what I remember from the xfs documentation, "noatime" wasn't mentioned. But maybe I'm not remembering correctly. Thanks in advance for the answer. Andy Liebman From owner-linux-xfs@oss.sgi.com Fri Jan 30 09:12:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 09:12:36 -0800 (PST) Received: from ip67-95-18-218.z18-95-67.customer.algx.net (djedwhite.swc.com [207.208.158.41] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0UHCT7J011240 for ; Fri, 30 Jan 2004 09:12:30 -0800 Received: from [207.208.158.41] by ip67-95-18-218.z18-95-67.customer.algx.net via smtpd (for oss.SGI.COM [192.48.159.27]) with ESMTP; Fri, 30 Jan 2004 11:12:30 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by ed.swc.com (8.12.8/8.12.5) with ESMTP id i0UHCGvN008381; Fri, 30 Jan 2004 11:12:16 -0600 Date: Fri, 30 Jan 2004 11:12:16 -0600 (CST) From: Edmund White X-X-Sender: ewwhite@ed.swc.com To: AndyLiebman@aol.com cc: linux-xfs@oss.sgi.com Subject: Re: noatime In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1935 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ewwhite@mac.com Precedence: bulk X-list: linux-xfs Content-Length: 858 Lines: 30 On Fri, 30 Jan 2004 AndyLiebman@aol.com wrote: > Can anybody tell me if the "noatime" flag can be used when mounting xfs > partitions under Linux? Is "noatime" the default? Do you have to specify it? Is it > irrelevant? Or will it get me into trouble? From what I remember from the xfs > documentation, "noatime" wasn't mentioned. But maybe I'm not remembering > correctly. > > Thanks in advance for the answer. > > Andy Liebman > > I'm not sure if noatime is the default. I do mount my filesystems as "noatime" and "nodiratime". I use the tuning methods described at: Common threads: Advanced filesystem implementor's guide http://www-106.ibm.com/developerworks/linux/library/l-fs10.html My /etc/fstab entries look like this: LABEL=/usr /usr xfs noatime,nodiratime 1 2 -- Edmund William White http://www.djedwhite.com ewwhite@mac.com From owner-linux-xfs@oss.sgi.com Fri Jan 30 09:13:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 09:13:22 -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 i0UHDG7J011489 for ; Fri, 30 Jan 2004 09:13:17 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AmcCg-00060e-EA; Fri, 30 Jan 2004 17:13:14 +0000 Date: Fri, 30 Jan 2004 17:13:14 +0000 From: Christoph Hellwig To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com Subject: Re: noatime Message-ID: <20040130171314.A23071@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from AndyLiebman@aol.com on Fri, Jan 30, 2004 at 12:04:26PM -0500 X-archive-position: 1936 X-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: 569 Lines: 12 On Fri, Jan 30, 2004 at 12:04:26PM -0500, AndyLiebman@aol.com wrote: > Can anybody tell me if the "noatime" flag can be used when mounting xfs > partitions under Linux? Is "noatime" the default? Do you have to specify it? Is it > irrelevant? Or will it get me into trouble? From what I remember from the xfs > documentation, "noatime" wasn't mentioned. But maybe I'm not remembering > correctly. noatime isn't a per-filesystem but VFS-level mount option, so the XFS documentation is the wrong place, check the mount manpage for it. It does work fine under XFS. From owner-linux-xfs@oss.sgi.com Fri Jan 30 09:24:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 09:24:48 -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 i0UHOU7J012287 for ; Fri, 30 Jan 2004 09:24:33 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AmcNO-00062a-Js; Fri, 30 Jan 2004 17:24:18 +0000 Date: Fri, 30 Jan 2004 17:24:18 +0000 From: Christoph Hellwig To: Edmund White Cc: AndyLiebman@aol.com, linux-xfs@oss.sgi.com Subject: Re: noatime Message-ID: <20040130172418.A23219@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ewwhite@mac.com on Fri, Jan 30, 2004 at 11:12:16AM -0600 X-archive-position: 1937 X-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: 397 Lines: 9 On Fri, Jan 30, 2004 at 11:12:16AM -0600, Edmund White wrote: > I'm not sure if noatime is the default. I do mount my filesystems as > "noatime" and "nodiratime". I use the tuning methods described at: nodiratime doesn't work with XFS currently because it does the atime updates itself instead of using the generic update_atime helper. I wanted to fix this for a while now but never got time. From owner-linux-xfs@oss.sgi.com Fri Jan 30 09:34:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 09:34:46 -0800 (PST) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0UHYe7J012915 for ; Fri, 30 Jan 2004 09:34:42 -0800 Received: from hpti7.fsl.noaa.gov ([137.75.132.227]) by hptimail01.HPTI.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jan 2004 12:34:39 -0500 Subject: Re: Data corruption with xfs+nfs+lvm From: Craig Tierney To: Nathan Scott Cc: cattelan@sgi.com, linux-xfs@oss.sgi.com In-Reply-To: <20040130024343.GC1062@frodo> References: <1075423747.3859.280.camel@hpti7.fsl.noaa.gov> <20040130024343.GC1062@frodo> Content-Type: text/plain Organization: Message-Id: <1075482631.3866.9.camel@hpti7.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 30 Jan 2004 10:10:31 -0700 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2004 17:34:40.0027 (UTC) FILETIME=[56C296B0:01C3E757] X-archive-position: 1938 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctierney@HPTI.com Precedence: bulk X-list: linux-xfs Content-Length: 2270 Lines: 56 On Thu, 2004-01-29 at 19:43, Nathan Scott wrote: > On Thu, Jan 29, 2004 at 05:49:07PM -0700, Craig Tierney wrote: > > I have just discovered that I am having problems with data corruption > > on my NFS servers and XFS. It happens in several different cases, but > > all under load. Here are the cases that I have gotten data corruption > > for reads and writes. Corruption happens on different servers and > > on different filesystems (some configured with LVM striping, some not). > > Can you descibe your test case in more detail? In particular, > do you have a program/programs that demonstrates the problem? > That is always a huge help. Or a list of things to run - what > sort of IO is being done, and what does "under load" mean in > your context. I will gather more information and get back. The job is serveral different codes that massage the data. One piece regrids the data for the model, then the model reads some data and writes more out, and the last post-processes the data into new grids. We have seen failures at every step. Not that every step fails, but we can trigger issues at every step. We have some cases were we think we have read corruption because re-running the same case works the 2nd (or 3rd) time. > > > We tested the new linux-2.4.21 kernel on the dual P3. > > "new" and "2.4.21" don't really go together. :) True. The last patch I found for xfs was 1.3.1 and applied to 2.4.21, so that is why I used it. If 2.4.24 (or .25) is released with full xfs support I will try that. If there is a pre-release I should try then I will do that as well. > > > The file writes are from single processes. Some codes are MPI, but > > all the IO, reads and writes, go through the rank 0 node. We can > > reproduce the corruption relatively easy when 16 processes are active. > > Can you give me a recipe so that I can reproduce it locally? > Does NFS have to be in the picture for this to fail? And is > it reproducible without LVM too? I hadn't thought of testing without NFS due to the setup. However, I do know of a way to test it. I will get one portion going directly on the filesystem. > > Russell, does this sound like that NFS corruption that you > were looking into awhile back? > > cheers. Thanks, Craig From owner-linux-xfs@oss.sgi.com Fri Jan 30 09:55:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 09:55:51 -0800 (PST) Received: from imo-r07.mx.aol.com (imo-r07.mx.aol.com [152.163.225.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0UHtb7J014617 for ; Fri, 30 Jan 2004 09:55:40 -0800 Received: from AndyLiebman@aol.com by imo-r07.mx.aol.com (mail_out_v36_r4.12.) id g.115.2e2700bf (30960); Fri, 30 Jan 2004 12:54:58 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <115.2e2700bf.2d4bf471@aol.com> Date: Fri, 30 Jan 2004 12:54:57 EST Subject: Re: noatime To: hch@infradead.org, ewwhite@mac.com CC: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5006 X-archive-position: 1939 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 285 Lines: 10 Just a follow up. Is there any danger/disadvantage in using "noatime" on a big RAID array with critical data on it? Does it somehow prejudice the recovery from an unexpected shut down or crash? Or is "atime" just pretty much useless information for most people? Andy Liebman From owner-linux-xfs@oss.sgi.com Fri Jan 30 09:58:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 09:58:18 -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 i0UHw07J015052 for ; Fri, 30 Jan 2004 09:58:02 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1Amctw-00069S-PF; Fri, 30 Jan 2004 17:57:56 +0000 Date: Fri, 30 Jan 2004 17:57:56 +0000 From: Christoph Hellwig To: AndyLiebman@aol.com Cc: ewwhite@mac.com, linux-xfs@oss.sgi.com Subject: Re: noatime Message-ID: <20040130175756.A23646@infradead.org> References: <115.2e2700bf.2d4bf471@aol.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: <115.2e2700bf.2d4bf471@aol.com>; from AndyLiebman@aol.com on Fri, Jan 30, 2004 at 12:54:57PM -0500 X-archive-position: 1940 X-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: 444 Lines: 9 On Fri, Jan 30, 2004 at 12:54:57PM -0500, AndyLiebman@aol.com wrote: > Just a follow up. Is there any danger/disadvantage in using "noatime" on a > big RAID array with critical data on it? Does it somehow prejudice the recovery > from an unexpected shut down or crash? Or is "atime" just pretty much useless > information for most people? There's no data-integrity issues, but there's certain applications that rely on atime information. From owner-linux-xfs@oss.sgi.com Fri Jan 30 10:10:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 10:10:12 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0UIA97J016470 for ; Fri, 30 Jan 2004 10:10:10 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i0UIA43J020972 for ; Fri, 30 Jan 2004 12:10:04 -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.10/SGI_generic_relay-1.2) with ESMTP id i0UIA3GQ32398989; Fri, 30 Jan 2004 12:10:03 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Amd5e-0000OY-00; Fri, 30 Jan 2004 12:10:02 -0600 Subject: TAKE 908648 - Fix gcc 3.5 compilation for real Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com, sgi.bugs.communitylinux@fido.engr.sgi.com Date: Fri, 30 Jan 2004 12:10:02 -0600 X-archive-position: 1941 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 373 Lines: 15 Sorry, the last commit actually had zero code changes. Date: Fri Jan 30 10:09:13 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:165783a fs/xfs/xfs_buf_item.c - 1.148 - use XFS_BUF_SET_FSPRIVATE to set buffer private data From owner-linux-xfs@oss.sgi.com Fri Jan 30 10:45:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 10:45:48 -0800 (PST) Received: from imo-r06.mx.aol.com (imo-r06.mx.aol.com [152.163.225.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0UIjS7J017920 for ; Fri, 30 Jan 2004 10:45:28 -0800 Received: from AndyLiebman@aol.com by imo-r06.mx.aol.com (mail_out_v36_r4.12.) id g.70.3788aa08 (1320); Fri, 30 Jan 2004 13:44:41 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <70.3788aa08.2d4c0018@aol.com> Date: Fri, 30 Jan 2004 13:44:40 EST Subject: Re: noatime To: hch@infradead.org CC: ewwhite@mac.com, linux-xfs@oss.sgi.com MIME-Version: 1.0 X-Mailer: 9.0 for Windows sub 5006 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1942 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 354 Lines: 11 Thanks for clarifying. The aps that are accessing those drives don't need the atime information. So, it's goodbye with it. In a message dated 1/30/2004 12:58:13 PM Eastern Standard Time, hch@infradead.org writes: There's no data-integrity issues, but there's certain applications that rely on atime information. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Jan 30 11:43:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Jan 2004 11:43:24 -0800 (PST) Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0UJh37J019853 for ; Fri, 30 Jan 2004 11:43:10 -0800 Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) id <0HSB00L01HZEZX@nammta01.sugar-land.nam.slb.com> for linux-xfs@oss.sgi.com; Fri, 30 Jan 2004 19:39:49 +0000 (GMT) Received: from wgmail1.houston.nam.slb.com (wgmail1.houston.nam.slb.com [137.144.106.50]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPS id <0HSB0085CIEB5J@nammta01.sugar-land.nam.slb.com> for linux-xfs@oss.sgi.com; Fri, 30 Jan 2004 19:35:00 +0000 (GMT) Received: from JOSEMORALES-WADE1WG.houston.westerngeco.slb.com (localhost [127.0.0.1]) by wgmail1.houston.nam.slb.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id i0UJUGi29024 for ; Fri, 30 Jan 2004 13:30:16 -0600 (CST) Date: Fri, 30 Jan 2004 13:34:57 -0600 From: Jose Morales-Wade Subject: KERNEL_PANIC null memory on KM_SLEEP request X-Sender: josemorales-wade@wgmail1.houston.nam.slb.com To: linux-xfs@oss.sgi.com Message-id: <5.1.1.1.2.20040130132813.02f85868@wgmail1.houston.nam.slb.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-archive-position: 1943 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: josemorales-wade@houston.westerngeco.slb.com Precedence: bulk X-list: linux-xfs Content-Length: 391 Lines: 14 I have a Dell 2650 with 4 Drawers of disks connected using two Perc 4DC raid cards. I'm running 2.4.20-19.9.XFS1.3.0smp. The server has two cpu's and 2GB of memory. Yesterday the server kernel panic with a : KERNEL_PANIC null memory on KM_SLEEP request The memory usage for the machine looks "normal" around the time the system crashed. There was hardly any swap going on. Any ideas? From owner-linux-xfs@oss.sgi.com Sat Jan 31 00:42:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 31 Jan 2004 00:43:08 -0800 (PST) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0V8go7J022037 for ; Sat, 31 Jan 2004 00:42:53 -0800 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id i0V8cFfI030919 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 31 Jan 2004 18:38:43 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.11/8.12.11) with ESMTP id i0V8b1Mu002085; Sat, 31 Jan 2004 03:37:01 -0500 Date: Sat, 31 Jan 2004 03:37:01 -0500 (EST) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: Christoph Hellwig cc: AndyLiebman@aol.com, ewwhite@mac.com, linux-xfs@oss.sgi.com Subject: Re: noatime In-Reply-To: <20040130175756.A23646@infradead.org> Message-ID: References: <115.2e2700bf.2d4bf471@aol.com> <20040130175756.A23646@infradead.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1944 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs Content-Length: 957 Lines: 28 On Fri, 30 Jan 2004, Christoph Hellwig wrote: > There's no data-integrity issues, but there's certain applications that rely > on atime information. The question is which apps. I usually mount filesystems noatime but the caveat has always been, "watchout some apps require it". I think this has reached the point of being unix folk-lore. I've asked many Sysadmins to name a single app that misbehaves if filesystems are mounted noatime and (as far as I recall) no one has yet presented a credible example. This isn't criticism of the claim, just a genuine request. Can anyone name an application which misbehaves or breaks if filesystems it relies on are mounted noatime? This is somewhat OT I know, but while we're talking about it... Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, zzbrock@uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Sat Jan 31 02:26:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 31 Jan 2004 02:26:23 -0800 (PST) Received: from tri-e2k.ethz.ch (tri-e2k.ethz.ch [129.132.112.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VAQB7J025065 for ; Sat, 31 Jan 2004 02:26:12 -0800 Received: from xfe1.d.ethz.ch ([192.168.36.10]) by tri-e2k.ethz.ch with Microsoft SMTPSVC(5.0.2195.6713); Sat, 31 Jan 2004 11:26:10 +0100 Received: from inf.ethz.ch ([192.33.109.200]) by xfe1.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Sat, 31 Jan 2004 11:26:09 +0100 Message-ID: <401B82CF.8090106@inf.ethz.ch> Date: Sat, 31 Jan 2004 11:26:23 +0100 From: Marc Schmitt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: noatime References: <115.2e2700bf.2d4bf471@aol.com> <20040130175756.A23646@infradead.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2004 10:26:09.0925 (UTC) FILETIME=[A4C21B50:01C3E7E4] X-archive-position: 1945 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mschmitt@inf.ethz.ch Precedence: bulk X-list: linux-xfs Content-Length: 158 Lines: 9 Robert Brockway wrote: >Can anyone name an application which misbehaves or breaks if filesystems >it relies on are mounted noatime? > tmpwatch :) Marc From owner-linux-xfs@oss.sgi.com Sat Jan 31 04:53:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 31 Jan 2004 04:53: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 i0VCrV7J001853 for ; Sat, 31 Jan 2004 04:53:31 -0800 Received: from erbenson.alaska.net (229-pm20.nwc.alaska.net [209.112.142.229]) by iris.acsalaska.net (8.12.10/8.12.10) with ESMTP id i0V8qrgR036564 for ; Fri, 30 Jan 2004 23:52:53 -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 A2D9339E5 for ; Fri, 30 Jan 2004 23:52:51 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id E4FB340FF35; Fri, 30 Jan 2004 23:52:51 -0900 (AKST) Date: Fri, 30 Jan 2004 23:52:51 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: noatime Message-ID: <20040131085251.GP5676@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <115.2e2700bf.2d4bf471@aol.com> <20040130175756.A23646@infradead.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gJNQRAHI5jiYqw2y" 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: 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.61; spamdefang 1.93 X-archive-position: 1946 X-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: 1794 Lines: 55 --gJNQRAHI5jiYqw2y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 31, 2004 at 03:37:01AM -0500, Robert Brockway wrote: > On Fri, 30 Jan 2004, Christoph Hellwig wrote: >=20 > > There's no data-integrity issues, but there's certain applications that= rely > > on atime information. >=20 > The question is which apps. >=20 > I usually mount filesystems noatime but the caveat has always been, > "watchout some apps require it". I think this has reached the point of > being unix folk-lore. >=20 > I've asked many Sysadmins to name a single app that misbehaves if > filesystems are mounted noatime and (as far as I recall) no one has yet > presented a credible example. This isn't criticism of the claim, just a > genuine request. im not certain, but i think mutt uses it to determine which mailboxes listed in the "mailboxes" directive in .muttrc contain new mail. debian also has a package called `popularity contest' which runs from cron, looks at installed packages binary files and checks the atime to see how often they are actually used, then reports back to the popularity contest server with the results. > Can anyone name an application which misbehaves or breaks if filesystems > it relies on are mounted noatime? see above, atime is used by some apps, and is sometimes useful in certain cases. it all depends on your particular usage. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --gJNQRAHI5jiYqw2y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkAbbOMACgkQJKx7GixEevzYwgCeIwyuy7GdFwqMuxAXrwCLuWEo eggAn3Ibod3XE57CcGQtIpOda6nRXwu/ =w98n -----END PGP SIGNATURE----- --gJNQRAHI5jiYqw2y-- From owner-linux-xfs@oss.sgi.com Sat Jan 31 05:07:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 31 Jan 2004 05:08:03 -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 i0VD7k7J002538 for ; Sat, 31 Jan 2004 05:07:47 -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 i0VD7jRl013336; Sat, 31 Jan 2004 14:07:45 +0100 Message-ID: <401BA9C0.7000807@stesmi.com> Date: Sat, 31 Jan 2004 14:12:32 +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: Marc Schmitt CC: linux-xfs@oss.sgi.com Subject: Re: noatime References: <115.2e2700bf.2d4bf471@aol.com> <20040130175756.A23646@infradead.org> <401B82CF.8090106@inf.ethz.ch> In-Reply-To: <401B82CF.8090106@inf.ethz.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1947 X-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: 169 Lines: 11 Yo Marc. >> Can anyone name an application which misbehaves or breaks if filesystems >> it relies on are mounted noatime? >> > tmpwatch :) sendmail afaik. // Stefan From owner-linux-xfs@oss.sgi.com Sat Jan 31 11:12:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 31 Jan 2004 11:12: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 i0VJCe7J017875 for ; Sat, 31 Jan 2004 11:12:40 -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 i0VJCU2I032027 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 31 Jan 2004 14:12:32 -0500 Message-ID: <401BFE1E.2030508@coplanar.net> Date: Sat, 31 Jan 2004 14:12:30 -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: Jose Morales-Wade CC: linux-xfs@oss.sgi.com Subject: Re: KERNEL_PANIC null memory on KM_SLEEP request References: <5.1.1.1.2.20040130132813.02f85868@wgmail1.houston.nam.slb.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (hoby.coplanar.net: domain of jerj@coplanar.net designates 24.112.162.124 as SASL permitted sender) X-archive-position: 1948 X-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: 803 Lines: 28 Those Dell Perc4 controllers can be touchy. use an newer kernel, make sure you have current firmware, and possibly patch your new kernel with the latest perc driver, it probably has fixes not in the main kernel. You should be subscribed to dell's perc mailing list, and check the list archives, they probably have more detailed info. Cheers, Jeremy Jose Morales-Wade wrote: > I have a Dell 2650 with 4 Drawers of disks connected using two Perc 4DC > raid cards. > I'm running 2.4.20-19.9.XFS1.3.0smp. The server has two cpu's and 2GB of > memory. > Yesterday the server kernel panic with a : > > KERNEL_PANIC null memory on KM_SLEEP request > > The memory usage for the machine looks "normal" around the time the > system crashed. > There was hardly any swap going on. > > Any ideas? > From owner-linux-xfs@oss.sgi.com Sat Jan 31 11:16:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 31 Jan 2004 11:16:10 -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 i0VJG87J018301 for ; Sat, 31 Jan 2004 11:16:08 -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 i0VJFs2I032062 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 31 Jan 2004 14:15:56 -0500 Message-ID: <401BFEEA.2030409@coplanar.net> Date: Sat, 31 Jan 2004 14:15:54 -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: Tomaz Beltram CC: linux-xfs@oss.sgi.com Subject: Re: can't use iget on XFS References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (hoby.coplanar.net: domain of jerj@coplanar.net designates 24.112.162.124 as SASL permitted sender) X-archive-position: 1949 X-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: 583 Lines: 15 Why not use DMAPI? Maybe you could implement it for other FS like ext3, and move it to the VFS layer. That would benefit the most people. Cheers, Jeremy Jackson Tomaz Beltram wrote: > We have developed a stackable filesystem kernel module for a HSM > application. The role of the filter module is to intercept operations > between VFS and file system. It then sends events to userspace when > these are invoked. We are using ext3 or reiserfs for bottom file system > and are evaluating XFS, since it provides all required functionality > (extended attributes, journals). From owner-linux-xfs@oss.sgi.com Sat Jan 31 14:00:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 31 Jan 2004 14:00:49 -0800 (PST) Received: from ms-smtp-03-eri0.texas.rr.com (ms-smtp-03.texas.rr.com [24.93.47.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VM0T7J028505 for ; Sat, 31 Jan 2004 14:00:29 -0800 Received: from Groves.net (cs68201181-91.austin.rr.com [68.201.181.91]) by ms-smtp-03-eri0.texas.rr.com (8.12.10/8.12.7) with ESMTP id i0VM03ZV008207; Sat, 31 Jan 2004 16:00:23 -0600 (CST) Message-ID: <401C2687.5010902@Groves.net> Date: Sat, 31 Jan 2004 16:04:55 -0600 From: John Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Dmapi questions Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1950 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: John@Groves.net Precedence: bulk X-list: linux-xfs Content-Length: 652 Lines: 18 I'm trying to track changes to a filesystem via dmapi. There are a few things that I haven't figured out yet, and I'm hoping somebody can set me straight. My filesystems can be huge, so want to avoid full scans to the extent possible. I can get CREATE events, but in some cases I need the filename & path to pass to a separate program. * If I have a file handle, can I get the relevant the relevant directory handle somehow? If so I could presumably use dm_handle_to_path() to generate the path... * Given a handle, how can I tell whether it is for a file or directory? Thanks, John [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat Jan 31 20:58:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 31 Jan 2004 20:58:58 -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 i114wk7J013991 for ; Sat, 31 Jan 2004 20:58:46 -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 i114wj1i014079 for ; Sat, 31 Jan 2004 23:58:45 -0500 (EST) Date: Sat, 31 Jan 2004 23:58:44 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: system hangs after mounting XFS root fs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1951 X-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: 1155 Lines: 35 Hi, I encountered a strange thing. My RH7.3 linux with 2.4.18 kernel, which has been running fine in the past 3 months, after a reboot (issued by me) stopped at the following lines: XFS mounting filesystem md(9,3) XFS: WARNING: recovery required on readonly filesysten Starting XFS recovery on filesystem: ... Ending XFS recovery on filesystem: ... VFS: mounted root (xfs filesystem) readonly < hang , nothing happens, cursor blinks. At CTRL+ALT+DEL, the system reboots, and the raid arrays are stopped/flushed. IT is not a complete 'freeze' of the system. I booted in a recovery CD, and checked the xfs root filesystem; it reported a few lines of inconsitencies. Then I repaired it, mounted it from the recovery CD with no problem (2.4.22 kernel, other XFS version). Now I thought the problem is solved ... But it isn't, because after reboot (now not from the CD, but again from the disk with 2.4.18), the system stops at the same place: XFS mounting filesystem md(9,3) VFS: mounted root (xfs filesystem) readonly Now no warnings are reported, just nothing happens... Let me know if you have any suggestion how to recover. Cheers Gaspar