From owner-linux-xfs@oss.sgi.com Sat May 1 07:44:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 May 2004 07:44:51 -0700 (PDT) Received: from zero.aec.at (Jupiter_Muke@[193.170.194.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i41EigKO008408 for ; Sat, 1 May 2004 07:44:43 -0700 Received: from averell.firstfloor.org.muc.de (Joel_Frad_Bink@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id i41EiJD01191; Sat, 1 May 2004 16:44:20 +0200 To: Bruce Guenter cc: linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS References: <20040426165155.GA19148@em.ca> From: Andi Kleen Date: Sat, 01 May 2004 16:44:18 +0200 In-Reply-To: <20040426165155.GA19148@em.ca> (Bruce Guenter's message of "Mon, 26 Apr 2004 10:51:55 -0600") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2989 X-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 Bruce Guenter writes: > > So far, XFS with an external journal has by far the best delivery rate. > However, as the filesystem fills and delivery concurrency increases, the > time required to list, read and delete the delivered files slows down to > unacceptable levels. Is there anything I can do, settings to modify, > patches to try, to improve this behavior? Did you try it with elevator=deadline ? Maybe you are just seeing elevator starvation. The default anticipatory elevator adds artificial latencies for better throughput. -Andi From owner-linux-xfs@oss.sgi.com Sat May 1 11:25:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 May 2004 11:25:28 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i41IPLKO015101 for ; Sat, 1 May 2004 11:25:22 -0700 Received: from ijet.fsl.noaa.gov ([216.241.42.118]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Sat, 1 May 2004 14:25:20 -0400 Subject: Questions about pagebuf code From: Craig Tierney To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1083435856.2302.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 01 May 2004 12:24:16 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2004 18:25:21.0215 (UTC) FILETIME=[A9740CF0:01C42FA9] X-archive-position: 2990 X-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 1) Are the versions of xfs in 2.4.26 and 2.6.x mostly the same (except for the change in kernel interface)? In particular are there any differences in the pagebuf code? 2) Are all memory allocations controlled through xfs_buf? Not just the actual {v,k}mallocs (I grepped that to verify) but any time a routine chooses to access a page, it is selected through routines in xfs_buf? 3) Does pagebuf_get_pages get called multiple times while the filesystem is active, or only at initialization? 4) Would there be any reason (except performance) not to change MAX_SLAB_SIZE to a smaller values (like 0), to test the behavior when only kmalloc is used to allocation memory? Thanks, Craig From owner-linux-xfs@oss.sgi.com Sat May 1 11:47:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 May 2004 11:47:18 -0700 (PDT) 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 i41IlBKO015913 for ; Sat, 1 May 2004 11:47:14 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BJzW1-0006Bx-PQ; Sat, 01 May 2004 19:47:09 +0100 Date: Sat, 1 May 2004 19:47:09 +0100 From: Christoph Hellwig To: Craig Tierney Cc: linux-xfs@oss.sgi.com Subject: Re: Questions about pagebuf code Message-ID: <20040501194709.A23768@infradead.org> References: <1083435856.2302.3.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1083435856.2302.3.camel@localhost.localdomain>; from ctierney@HPTI.com on Sat, May 01, 2004 at 12:24:16PM -0600 X-archive-position: 2991 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Sat, May 01, 2004 at 12:24:16PM -0600, Craig Tierney wrote: > 1) Are the versions of xfs in 2.4.26 and 2.6.x mostly the same > (except for the change in kernel interface)? In particular > are there any differences in the pagebuf code? there's a bunch of differences, mostly in the handling of the worker threads and the I/O handling code. > 2) Are all memory allocations controlled through xfs_buf? No. > Not just the actual {v,k}mallocs (I grepped that to verify) > but any time a routine chooses to access a page, it is selected > through routines in xfs_buf? Everything dealing with xfs_buf_t (= mostly metadata, + O_DIRECT data I/O in 2.4) is handled by xfs_buf. > 3) Does pagebuf_get_pages get called multiple times while > the filesystem is active, or only at initialization? It's called once for each buffer allocated, which happens all the time. > 4) Would there be any reason (except performance) not to change > MAX_SLAB_SIZE to a smaller values (like 0), to test the behavior > when only kmalloc is used to allocation memory? vmalloc can't be done from inside a spinlock. Now that you mention it I think we should explicitly check for that in the kmem_alloc code instead of relying KM_NOSLEEP requests beeing small enough all the time.. Counterquestion: Why do you care? :) From owner-linux-xfs@oss.sgi.com Sat May 1 14:22:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 May 2004 14:22:34 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i41LMSKO021087 for ; Sat, 1 May 2004 14:22:28 -0700 Received: from ijet.fsl.noaa.gov ([216.241.42.118]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Sat, 1 May 2004 17:22:27 -0400 Subject: Re: Questions about pagebuf code From: Craig Tierney To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040501194709.A23768@infradead.org> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> Content-Type: text/plain Message-Id: <1083446482.2302.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 01 May 2004 15:21:23 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2004 21:22:27.0642 (UTC) FILETIME=[674C21A0:01C42FC2] X-archive-position: 2992 X-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 On Sat, 2004-05-01 at 12:47, Christoph Hellwig wrote: > On Sat, May 01, 2004 at 12:24:16PM -0600, Craig Tierney wrote: > > 1) Are the versions of xfs in 2.4.26 and 2.6.x mostly the same > > (except for the change in kernel interface)? In particular > > are there any differences in the pagebuf code? > > there's a bunch of differences, mostly in the handling of the worker > threads and the I/O handling code. > > > 2) Are all memory allocations controlled through xfs_buf? > > No. > > > Not just the actual {v,k}mallocs (I grepped that to verify) > > but any time a routine chooses to access a page, it is selected > > through routines in xfs_buf? > > Everything dealing with xfs_buf_t (= mostly metadata, + O_DIRECT data > I/O in 2.4) is handled by xfs_buf. > > > 3) Does pagebuf_get_pages get called multiple times while > > the filesystem is active, or only at initialization? > > It's called once for each buffer allocated, which happens all the time. > > > 4) Would there be any reason (except performance) not to change > > MAX_SLAB_SIZE to a smaller values (like 0), to test the behavior > > when only kmalloc is used to allocation memory? > > vmalloc can't be done from inside a spinlock. Now that you mention > it I think we should explicitly check for that in the kmem_alloc code > instead of relying KM_NOSLEEP requests beeing small enough all the time.. > > Counterquestion: Why do you care? :) Thanks for the details. I am trying to debug a problem with file corruption writing to my xfs filesystem (over nfs) when the server is under heavy load (16+ clients writing simultaneously to different directories). It does happen with different versions under the 2.4 kernel. It doesn't happen wen ext2 or jfs is used as the underlying filesystem. It does happen more often on when faster servers are used, and the corruption is always page aligned (starts at ADDR%4096==0, ends at ADDR%4096=4095). Since the corruption is always page aligned, and it happens more often on faster servers, I suspect there is some race condition or missed lock were pages are selected for use. I didn't completely understand the difference between v/kmalloc, but if there is an issue with mvalloc timings, I figured I would remove all vmallocs (because it is easy) to see if it changed anything. Thanks, CRaig From owner-linux-xfs@oss.sgi.com Sun May 2 12:36:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 May 2004 12:36:24 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i42JaKKO005615 for ; Sun, 2 May 2004 12:36:20 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i42JaKWw005614 for linux-xfs@oss.sgi.com; Sun, 2 May 2004 12:36:20 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i42JaJKQ005600 for ; Sun, 2 May 2004 12:36:19 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i42JGocT002296; Sun, 2 May 2004 12:16:50 -0700 Date: Sun, 2 May 2004 12:16:50 -0700 Message-Id: <200405021916.i42JGocT002296@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 326] New: xfs_repair failing to repair corrupted dinode X-Bugzilla-Reason: AssignedTo X-archive-position: 2993 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=326 Summary: xfs_repair failing to repair corrupted dinode Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: e.r.macgregor@warwick.ac.uk Running xfs_repair gives the following error: corrupt dinode 92252, extent total = 3, nblocks = 0. Unmount and run xfs_repair. fatal error -- couldn't map inode 92252, err = 990 Mounting the image causes an XFS internal error dump in the kernel on 2.4 "XFS_WANT_CORRUPTED_GOTO at line 1616 of xfs_alloc.c" (snapshot snapshot-2.4.23-2003-12-01_00:33_UTC [from Knoppix, the machine normally uses 2.4.26] and 2.6.6-rc1 "XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c." Full log at: http://members.uwcs.co.uk/~zx64/hda2_repair.txt.bz2 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 May 2 14:06:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 May 2004 14:06:57 -0700 (PDT) Received: from zak.futurequest.net (zak.futurequest.net [69.5.6.152]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i42L6qKO014687 for ; Sun, 2 May 2004 14:06:52 -0700 Received: (qmail 10860 invoked from network); 2 May 2004 21:06:51 -0000 Received: from localhost ([127.0.0.1]) by zak.futurequest.net ([69.5.6.152]); 02 May 2004 21:06:51 -0000 Received: from bruce-guenter.dyndns.org (unknown [127.0.0.1]) by localhost ([127.0.0.1]) with SMTP via TCP; 02 May 2004 21:06:51 -0000 Received: (qmail 28162 invoked by uid 500); 2 May 2004 21:06:48 -0000 Date: Sun, 2 May 2004 15:06:48 -0600 From: Bruce Guenter To: linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS Message-ID: <20040502210648.GA28154@em.ca> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040426165155.GA19148@em.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-archive-position: 2994 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lists-linux-xfs@bruce-guenter.dyndns.org Precedence: bulk X-list: linux-xfs --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 01, 2004 at 04:44:18PM +0200, Andi Kleen wrote: > Did you try it with elevator=3Ddeadline ? Maybe you are just seeing > elevator starvation. The default anticipatory elevator adds=20 > artificial latencies for better throughput. All the tests were run with elevator=3Ddeadline, for exactly that reason. --=20 Bruce Guenter http://em.ca/~bruceg/ http://untroubled.org/ OpenPGP key: 699980E8 / D0B7 C8DD 365D A395 29DA 2E2A E96F B2DC 6999 80E8 --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAlWLo6W+y3GmZgOgRAqGpAKCNnyN21SdO/NzhwYBbTBB2HHxIcgCePk69 7ffC+V5362KmPI7RZ02emvk= =OCIE -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-linux-xfs@oss.sgi.com Sun May 2 21:38:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 May 2004 21:38:57 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i434cpKO030938 for ; Sun, 2 May 2004 21:38:51 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i434eR05013127 for ; Sun, 2 May 2004 21:40:28 -0700 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 OAA08879; Mon, 3 May 2004 14:38:27 +1000 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 i434cQln125118; Mon, 3 May 2004 14:38:26 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i434cMWJ124397; Mon, 3 May 2004 14:38:22 +1000 (EST) Date: Mon, 3 May 2004 14:38:21 +1000 From: Nathan Scott To: Craig Tierney Cc: Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: Questions about pagebuf code Message-ID: <20040503143821.A124474@wobbly.melbourne.sgi.com> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> <1083446482.2302.22.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1083446482.2302.22.camel@localhost.localdomain>; from ctierney@HPTI.com on Sat, May 01, 2004 at 03:21:23PM -0600 X-archive-position: 2998 X-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: 1092 Lines: 27 On Sat, May 01, 2004 at 03:21:23PM -0600, Craig Tierney wrote: > On Sat, 2004-05-01 at 12:47, Christoph Hellwig wrote: > > > > Everything dealing with xfs_buf_t (= mostly metadata, + O_DIRECT data > > I/O in 2.4) is handled by xfs_buf. > > > I am trying to debug a problem with file corruption writing to my xfs > filesystem (over nfs) when the server is under heavy load (16+ clients > writing simultaneously to different directories). It does happen with > different versions under the 2.4 kernel. It doesn't happen wen ext2 or > jfs is used as the underlying filesystem. It does happen more often on > when faster servers are used, and the corruption is always page aligned > (starts at ADDR%4096==0, ends at ADDR%4096=4095). I'd guess your pagesize and fs blocksize are both 4K? If you read between the lines of Christophs mail, pagebuf isn't the right place to be looking for regular file data corruption, and probably the mem alloc interfaces are unrelated here also. You'll want to focus on the get_block and writepage operations in xfs_aops.c, I suspect. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun May 2 21:46:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 May 2004 21:46:44 -0700 (PDT) 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 i434kdKO031444 for ; Sun, 2 May 2004 21:46:40 -0700 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 i434jYBN009493 for ; Sun, 2 May 2004 23:45:35 -0500 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 OAA09078; Mon, 3 May 2004 14:45:30 +1000 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 i434jTln125144; Mon, 3 May 2004 14:45:29 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i434jOxO125064; Mon, 3 May 2004 14:45:24 +1000 (EST) Date: Mon, 3 May 2004 14:45:24 +1000 From: Nathan Scott To: Johann Lombardi Cc: linux-xfs@oss.sgi.com Subject: Re: Unsupported sector size Message-ID: <20040503144524.B124474@wobbly.melbourne.sgi.com> References: <200404292134.23178.johann.lombardi@free.fr> <20040430111412.A28855@wobbly.melbourne.sgi.com> <20040430111634.B28855@wobbly.melbourne.sgi.com> <200405010040.06340.johann.lombardi@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200405010040.06340.johann.lombardi@free.fr>; from johann.lombardi@free.fr on Sat, May 01, 2004 at 12:40:06AM +0200 X-archive-position: 2999 X-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: 511 Lines: 19 On Sat, May 01, 2004 at 12:40:06AM +0200, Johann Lombardi wrote: > My xfsprogs is to old, this option isn't available. I am going to upgrade this > package as soon as possible. Thanks. > > After this issue, I decided to change the sector size from 4096 to 512. I thought you said this was a 4K sector size device? Using a smaller sector size if the hardware doesn't support it is not going to work. > I encountered no problem with the mkfs. An updated mkfs would warn you, I expect. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun May 2 23:31:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 May 2004 23:31:48 -0700 (PDT) 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 i436VhKO001516 for ; Sun, 2 May 2004 23:31:43 -0700 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 i436OQBN004997 for ; Mon, 3 May 2004 01:24:27 -0500 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 QAA10859; Mon, 3 May 2004 16:24:22 +1000 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 i436OGln126419; Mon, 3 May 2004 16:24:17 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i436OFrs126976; Mon, 3 May 2004 16:24:15 +1000 (EST) Date: Mon, 3 May 2004 16:24:15 +1000 From: Nathan Scott To: Craig Tierney , Christoph Hellwig Cc: linux-xfs@oss.sgi.com Subject: Re: Questions about pagebuf code Message-ID: <20040503162415.F124474@wobbly.melbourne.sgi.com> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040501194709.A23768@infradead.org>; from hch@infradead.org on Sat, May 01, 2004 at 07:47:09PM +0100 X-archive-position: 3000 X-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: 767 Lines: 23 On Sat, May 01, 2004 at 07:47:09PM +0100, Christoph Hellwig wrote: > > > 4) Would there be any reason (except performance) not to change > > MAX_SLAB_SIZE to a smaller values (like 0), to test the behavior Oh, missed this - setting MAX_SLAB_SIZE to 0 will make all allocations go the vmalloc route... under no circumstances is that what you want to do. > > when only kmalloc is used to allocation memory? > > vmalloc can't be done from inside a spinlock. Now that you mention > it I think we should explicitly check for that in the kmem_alloc code > instead of relying KM_NOSLEEP requests beeing small enough all the time.. By adding {BUG/WARN}_ON checks on irqs_disabled() in kmem.h? (is there a 2.4 equivalent interface for that)? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon May 3 00:02:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 00:02:10 -0700 (PDT) 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 i43723KO002358 for ; Mon, 3 May 2004 00:02:03 -0700 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 i4371uBN016800 for ; Mon, 3 May 2004 02:01:57 -0500 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 i4371gAL60718131; Mon, 3 May 2004 17:01:43 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4371dT261357586; Mon, 3 May 2004 17:01:39 +1000 (EST) Date: Mon, 3 May 2004 17:01:39 +1000 (EST) From: Nathan Scott Message-Id: <200405030701.i4371dT261357586@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 913919 - remove some dead code X-archive-position: 3001 X-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: 545 Lines: 19 Remove unused transaction pointer from bulkstat. Thanks cw. Date: Mon May 3 00:00:36 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: sandeen@sgi.com,cattelan@sgi.com,hch@lst.de,cw@f00f.org The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:171081a xfs_itable.c - 1.121 xfs_itable.h - 1.42 quota/xfs_qm_syscalls.c - 1.7 quota/xfs_qm.c - 1.11 dmapi/dmapi_xfs.c - 1.35 linux-2.6/xfs_ioctl.c - 1.108 linux-2.4/xfs_ioctl.c - 1.107 From owner-linux-xfs@oss.sgi.com Mon May 3 00:11:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 00:11:52 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i437BmKO003111 for ; Mon, 3 May 2004 00:11:48 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i437DPCn019036 for ; Mon, 3 May 2004 00:13:25 -0700 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 i437BZAL58982455; Mon, 3 May 2004 17:11:35 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i437BXrR60725335; Mon, 3 May 2004 17:11:33 +1000 (EST) Date: Mon, 3 May 2004 17:11:33 +1000 (EST) From: Nathan Scott Message-Id: <200405030711.i437BXrR60725335@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 912427 - fixup kmalloc/vmalloc cutoff point X-archive-position: 3002 X-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: 382 Lines: 14 Bump the kmalloc/vmalloc cutoff up to 128k. Date: Mon May 3 00:10:54 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: sandeen@sgi.com,hch@lst.de,lord@xfs.org The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:171083a linux-2.6/kmem.h - 1.23 linux-2.4/kmem.c - 1.32 From owner-linux-xfs@oss.sgi.com Mon May 3 00:35:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 00:35:06 -0700 (PDT) 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 i437YfKO006822 for ; Mon, 3 May 2004 00:35:01 -0700 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 i437YXhv028716 for ; Mon, 3 May 2004 00:34:34 -0700 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 i437YJAL61491935; Mon, 3 May 2004 17:34:20 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i437YGsa61289360; Mon, 3 May 2004 17:34:16 +1000 (EST) Date: Mon, 3 May 2004 17:34:16 +1000 (EST) From: Nathan Scott Message-Id: <200405030734.i437YGsa61289360@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 912427 - merge generic cache shrink code X-archive-position: 3003 X-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: 404 Lines: 15 Generic cache shrink infrastructure for 2.4, as used in Redhat/Suse/others. Date: Mon May 3 00:32:10 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs Inspected by: hch@lst.de,cattelan@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:171084a include/linux/cache_def.h - 1.1 mm/Makefile - 1.2 mm/vmscan.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon May 3 00:46:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 00:46:58 -0700 (PDT) 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 i437khKO007415 for ; Mon, 3 May 2004 00:46:43 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i437dJBN028856 for ; Mon, 3 May 2004 02:39:19 -0500 Received: from omx2.sgi.com (omx2.sgi.com [198.149.32.25]) by nodin.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i437dH9f4629568 for ; Mon, 3 May 2004 00:39:17 -0700 (PDT) Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i437f04G026496 for ; Mon, 3 May 2004 00:41:01 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i437dEB15536 for linux-xfs@oss.sgi.com; Mon, 3 May 2004 17:39:14 +1000 Date: Mon, 3 May 2004 17:39:14 +1000 From: Nathan Scott Message-Id: <200405030739.i437dEB15536@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 912427 - split patches X-archive-position: 3004 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 364 Lines: 14 Update split patches for 2.4 generic cache shrink patch. Date: Mon May 3 00:38:37 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:171085a split-patches/cache_defs - 1.1 split-patches/series - 1.3 From owner-linux-xfs@oss.sgi.com Mon May 3 02:41:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 02:41:43 -0700 (PDT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i439fcKO011556 for ; Mon, 3 May 2004 02:41:39 -0700 Received: from lns-th2-4f-81-56-250-144.adsl.proxad.net (lns-th2-4f-81-56-250-144.adsl.proxad.net [81.56.250.144]) by postfix4-2.free.fr (Postfix) with ESMTP id 0202A99A41; Mon, 3 May 2004 11:41:37 +0200 (CEST) From: Johann Lombardi Reply-To: johann.lombardi@free.fr To: Nathan Scott Subject: Re: Unsupported sector size Date: Mon, 3 May 2004 11:47:28 +0200 User-Agent: KMail/1.5.4 Cc: linux-xfs@oss.sgi.com References: <200404292134.23178.johann.lombardi@free.fr> <200405010040.06340.johann.lombardi@free.fr> <20040503144524.B124474@wobbly.melbourne.sgi.com> In-Reply-To: <20040503144524.B124474@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405031147.28211.johann.lombardi@free.fr> X-archive-position: 3005 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: johann.lombardi@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 382 Lines: 10 > I thought you said this was a 4K sector size device? Using > a smaller sector size if the hardware doesn't support it is > not going to work. The storage system I am using allows me to choose the sector size (at LUN creation time). Besides, I have already successfully used ext3 with 512 and 4096 sector sizes. I will send you the output of xfs_db as soon as possible. Johann From owner-linux-xfs@oss.sgi.com Mon May 3 02:47:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 02:48:07 -0700 (PDT) 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 i439lwKO011997 for ; Mon, 3 May 2004 02:47:58 -0700 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 i439iphv029857 for ; Mon, 3 May 2004 02:44:52 -0700 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 TAA14117 for ; Mon, 3 May 2004 19:44:50 +1000 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 i439inln131172 for ; Mon, 3 May 2004 19:44:49 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i439ilCH130650 for linux-xfs@oss.sgi.com; Mon, 3 May 2004 19:44:47 +1000 (EST) Date: Mon, 3 May 2004 19:44:47 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: Indestructible directories? Message-ID: <20040503194447.A126528@wobbly.melbourne.sgi.com> References: <20040430173853.GC1844@hell.org.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040430173853.GC1844@hell.org.pl>; from sziwan@hell.org.pl on Fri, Apr 30, 2004 at 07:38:53PM +0200 X-archive-position: 3006 X-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: 1323 Lines: 41 On Fri, Apr 30, 2004 at 07:38:53PM +0200, Karol Kozimor wrote: > Hi, Hi there, > I suffered from major filesystem corruption while testing third party > patches. The filesystem shut down and was handled with xfs_repair. After > that, several directories were found in /lost+found that could no longer be > removed, e.g.: > # ls -la /lost+found/12616156/ > total 8 > drwxrwxrwx 2 root root 4096 2004-04-29 15:22 ./ > drwxr-xr-x 12 root root 155 2004-04-30 10:53 ../ > # rmdir /lost+found/12616156 > rmdir: `/lost+found/12616156': Directory not empty > # # rm -rf /lost+found/12616156 > rm: cannot remove directory `/lost+found/12616156': Directory not empty > ... > rmdir("/lost+found/12616156") = -1 ENOTEMPTY (Directory not empty) > > Subsequent xfs_repair runs do not fix the problem, the directories are > simply unlinked and relinked in /lost+found. This is a known bug in xfs_repair. > Was it ext2, I would have used debugfs. What can I do to rectify this and The XFS equivalent is xfs_db(8) and you should be able to clear these broken inodes with that tool, then re-run xfs_repair. > / or provide any useful information? Can you open a bug on oss.sgi.com and add in the information you provided above, xfs_info output, and xfs_bmap -vv on one of the inodes in question. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon May 3 03:31:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 03:31:48 -0700 (PDT) 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 i43AVhKO013132 for ; Mon, 3 May 2004 03:31:43 -0700 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 i43AKmBN016292 for ; Mon, 3 May 2004 05:20:49 -0500 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 UAA14753; Mon, 3 May 2004 20:20:40 +1000 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 i43AKaln131344; Mon, 3 May 2004 20:20:37 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i43AKVkr131722; Mon, 3 May 2004 20:20:31 +1000 (EST) Date: Mon, 3 May 2004 20:20:31 +1000 From: Nathan Scott To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] xfsprogs does not support DESTDIR for "make install" Message-ID: <20040503202031.B126528@wobbly.melbourne.sgi.com> References: <409286D4.90804@backtobasicsmgmt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <409286D4.90804@backtobasicsmgmt.com>; from kpfleming@backtobasicsmgmt.com on Fri, Apr 30, 2004 at 10:03:16AM -0700 X-archive-position: 3007 X-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: 491 Lines: 15 On Fri, Apr 30, 2004 at 10:03:16AM -0700, Kevin P. Fleming wrote: > Very simple, just prefixes DESTDIR on all the destination paths so > xfsprogs can be installed somewhere different than --prefix was set for. > > If there's another way to accomplish this with the existing Makefiles > please let me know, I couldn't seem to find it. That would be $DIST_ROOT (see install-sh script; build/tar/Makefile, build/rpm/Makefile, and debian/rules all use this mechanism). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon May 3 05:21:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 05:21:47 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i43CLeKO018767 for ; Mon, 3 May 2004 05:21:41 -0700 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BKa65-0008O6-00 for ; Mon, 03 May 2004 11:50:49 +0200 Received: from pd955bd8d.dip.t-dialin.net ([217.85.189.141]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 May 2004 11:50:49 +0200 Received: from joe by pd955bd8d.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 May 2004 11:50:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: Joe Schulz Subject: dm-crypt + xfs = no quota? Date: Mon, 03 May 2004 11:44:25 +0200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd955bd8d.dip.t-dialin.net User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4 X-Accept-Language: en-us, en X-Enigmail-Version: 0.82.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-archive-position: 3009 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joe@spamfilter.de Precedence: bulk X-list: linux-xfs Content-Length: 642 Lines: 18 Hello all, I have a secure setup here with the root partition mounted on a dm-crypt layer. kernel is 2.6.5. Unfortunately when mounting the fs, I always get this in the logs: XFS: unknown mount option [quota]. I have back-checked twice, the quota option for xfs is enabled in the kernel config. I am suspecting it is something along the lines of this: http://sourceforge.net/tracker/index.php?func=detail&atid=394667&aid=828570&group_id=28891 but I am not quite sure. I already updated my quota tools to 3.11, hoping an up-to-date version would fix the issue. It doesnt. Any ideas what I could do to get quota working? br, Joe From owner-linux-xfs@oss.sgi.com Mon May 3 08:49:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 08:49:13 -0700 (PDT) Received: from office.labsysgrp.com (wsip-68-14-253-125.ph.ph.cox.net [68.14.253.125]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i43Fn6KO030996 for ; Mon, 3 May 2004 08:49:07 -0700 Received: from [127.0.0.1] (helo=localhost) by office.labsysgrp.com with esmtp (Exim 4.24) id 1BKfgh-0004WA-Ec for linux-xfs@oss.sgi.com; Mon, 03 May 2004 08:48:59 -0700 Received: from office.labsysgrp.com ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17148-04 for ; Mon, 3 May 2004 08:48:58 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.labsysgrp.com with esmtp (Exim 4.24) id 1BKfgg-0004W4-St for linux-xfs@oss.sgi.com; Mon, 03 May 2004 08:48:58 -0700 Received: from [192.168.172.107] (helo=backtobasicsmgmt.com) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1BKfgg-0006sF-00 for linux-xfs@oss.sgi.com; Mon, 03 May 2004 08:48:58 -0700 Message-ID: <409669F0.9040501@backtobasicsmgmt.com> Date: Mon, 03 May 2004 08:49:04 -0700 From: "Kevin P. Fleming" Organization: Back To Basics Network Management User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] xfsprogs does not support DESTDIR for "make install" References: <409286D4.90804@backtobasicsmgmt.com> <20040503202031.B126528@wobbly.melbourne.sgi.com> In-Reply-To: <20040503202031.B126528@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 3012 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 174 Lines: 7 Nathan Scott wrote: > That would be $DIST_ROOT (see install-sh script; build/tar/Makefile, > build/rpm/Makefile, and debian/rules all use this mechanism). Got it, thanks. From owner-linux-xfs@oss.sgi.com Mon May 3 10:10:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 10:10:14 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i43HA1KO032622 for ; Mon, 3 May 2004 10:10:02 -0700 Received: from hpti9.fsl.noaa.gov ([137.75.132.229]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 13:09:54 -0400 Subject: Re: Questions about pagebuf code From: Craig Tierney To: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <20040503162415.F124474@wobbly.melbourne.sgi.com> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> <20040503162415.F124474@wobbly.melbourne.sgi.com> Content-Type: text/plain Message-Id: <1083604132.2398.3.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 03 May 2004 11:08:52 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2004 17:09:54.0529 (UTC) FILETIME=[742A1510:01C43131] X-archive-position: 3013 X-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: 1301 Lines: 38 On Mon, 2004-05-03 at 00:24, Nathan Scott wrote: > On Sat, May 01, 2004 at 07:47:09PM +0100, Christoph Hellwig wrote: > > > > > 4) Would there be any reason (except performance) not to change > > > MAX_SLAB_SIZE to a smaller values (like 0), to test the behavior > > Oh, missed this - setting MAX_SLAB_SIZE to 0 will make all > allocations go the vmalloc route... under no circumstances > is that what you want to do. Right. That isn't what I meant. I wanted to set MAX_SLAB_SIZE to something to ensoure only kmalloc is ever used, not vmalloc. > > > > when only kmalloc is used to allocation memory? > > > > vmalloc can't be done from inside a spinlock. Now that you mention > > it I think we should explicitly check for that in the kmem_alloc code > > instead of relying KM_NOSLEEP requests beeing small enough all the time.. > > By adding {BUG/WARN}_ON checks on irqs_disabled() in kmem.h? > (is there a 2.4 equivalent interface for that)? I didn't see and references to irqs_disabled() in either 2.6.5 or 2.4.26. Both 2.4.26 and 2.6.5 seem to have similar references to and irq fuctions (spin_{un}lock_irqsave) in debug.c and ktrace.c. However in xfs_buf.c in 2.4.26, irq functions are called but not in 2.6.5. Not sure if this is significant. Thanks, Craig > > cheers. From owner-linux-xfs@oss.sgi.com Mon May 3 10:22:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 10:22:20 -0700 (PDT) Received: from smtp-out7.xs4all.nl (smtp-out7.xs4all.nl [194.109.24.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i43HMFKO000605 for ; Mon, 3 May 2004 10:22:15 -0700 Received: from auto-nb1.xs4all.nl (a80-126-90-136.adsl.xs4all.nl [80.126.90.136]) by smtp-out7.xs4all.nl (8.12.10/8.12.10) with ESMTP id i43HMDep050064; Mon, 3 May 2004 19:22:14 +0200 (CEST) Message-Id: <4.3.2.7.2.20040503191930.01bfff48@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 May 2004 19:22:09 +0200 To: Steve Lord , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: bugzilla entries for XFS in Fedora Core 2 test 3 In-Reply-To: <4091B7BE.8040701@xfs.org> References: <1083275408.1106.37.camel@stantz.corp.sgi.com> <1083275408.1106.37.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 3014 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: seth.mos@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1227 Lines: 37 At 21:19 29-4-2004 -0500, Steve Lord wrote: >Florin Andrei wrote: >>I did a test install for Fedora Core 2 test 3 using XFS. >>In order to enable XFS in the Fedora installer, when the installer boots >>up, at the very first prompt, enter "linux xfs" (or "linux text xfs" to >>run the installer in text mode). >>I've found a few bugs which i filed to Bugzilla: >>https://bugzilla.redhat.com/ >>The numbers of the bugs are: >>122017 >looks like redhat is getting lazy here > >>122018 >ditto > >>122043 >XFS does labels just fine, something else is going on here, in fact I >have a fedora core setup which is all XFS (except /boot because of >the grub issue). I have about 4 filesystems which all mount fine, >but I am using device mapper for them all which probably changes >the mount sequence. Because XFS labels can not be as long as the ext2/3 variants some of the mountpoints are botched if it is mounted deep in the structure. The label will then not be set on the device and thus the filesystem can not be mounted during install I believe. This is an older issue, because of this XFS mount by label was disabled since the 1.0.2 series IIRC. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Mon May 3 10:26:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 10:26:32 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i43HQPKO001030 for ; Mon, 3 May 2004 10:26:27 -0700 Received: from hpti9.fsl.noaa.gov ([137.75.132.229]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 13:26:15 -0400 Subject: Re: Questions about pagebuf code From: Craig Tierney To: Nathan Scott Cc: Christoph Hellwig , linux-xfs@oss.sgi.com In-Reply-To: <20040503143821.A124474@wobbly.melbourne.sgi.com> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> <1083446482.2302.22.camel@localhost.localdomain> <20040503143821.A124474@wobbly.melbourne.sgi.com> Content-Type: text/plain Message-Id: <1083605113.2398.5.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 03 May 2004 11:25:13 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2004 17:26:16.0264 (UTC) FILETIME=[BD52F480:01C43133] X-archive-position: 3015 X-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: 1308 Lines: 31 On Sun, 2004-05-02 at 22:38, Nathan Scott wrote: > On Sat, May 01, 2004 at 03:21:23PM -0600, Craig Tierney wrote: > > On Sat, 2004-05-01 at 12:47, Christoph Hellwig wrote: > > > > > > Everything dealing with xfs_buf_t (= mostly metadata, + O_DIRECT data > > > I/O in 2.4) is handled by xfs_buf. > > > > > I am trying to debug a problem with file corruption writing to my xfs > > filesystem (over nfs) when the server is under heavy load (16+ clients > > writing simultaneously to different directories). It does happen with > > different versions under the 2.4 kernel. It doesn't happen wen ext2 or > > jfs is used as the underlying filesystem. It does happen more often on > > when faster servers are used, and the corruption is always page aligned > > (starts at ADDR%4096==0, ends at ADDR%4096=4095). > > I'd guess your pagesize and fs blocksize are both 4K? Yes. ia32 page size is 4k, and I didn't change the blocksize (not that XFS would let me). > > If you read between the lines of Christophs mail, pagebuf isn't > the right place to be looking for regular file data corruption, > and probably the mem alloc interfaces are unrelated here also. > You'll want to focus on the get_block and writepage operations > in xfs_aops.c, I suspect. I will look around there. That makes sense. Craig From owner-linux-xfs@oss.sgi.com Mon May 3 11:48:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 11:48:50 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i43ImiKO003292 for ; Mon, 3 May 2004 11:48:45 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i43ImgId002221; Mon, 3 May 2004 20:48:42 +0200 Message-ID: <409693EF.2080609@stesmi.com> Date: Mon, 03 May 2004 20:48:15 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seth Mos CC: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: bugzilla entries for XFS in Fedora Core 2 test 3 References: <1083275408.1106.37.camel@stantz.corp.sgi.com> <1083275408.1106.37.camel@stantz.corp.sgi.com> <4.3.2.7.2.20040503191930.01bfff48@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20040503191930.01bfff48@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3016 X-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: 1454 Lines: 47 Hi Seth. >>> I did a test install for Fedora Core 2 test 3 using XFS. >>> In order to enable XFS in the Fedora installer, when the installer boots >>> up, at the very first prompt, enter "linux xfs" (or "linux text xfs" to >>> run the installer in text mode). >>> I've found a few bugs which i filed to Bugzilla: >>> https://bugzilla.redhat.com/ >>> The numbers of the bugs are: >>> 122017 >> >> looks like redhat is getting lazy here >> >>> 122018 >> >> ditto >> >>> 122043 >> >> XFS does labels just fine, something else is going on here, in fact I >> have a fedora core setup which is all XFS (except /boot because of >> the grub issue). I have about 4 filesystems which all mount fine, >> but I am using device mapper for them all which probably changes >> the mount sequence. > > > Because XFS labels can not be as long as the ext2/3 variants some of the > mountpoints are botched if it is mounted deep in the structure. > > The label will then not be set on the device and thus the filesystem can > not be mounted during install I believe. > > This is an older issue, because of this XFS mount by label was disabled > since the 1.0.2 series IIRC. What's the limit of label length? I believe there's a setting in anaconda one can make and the bug could well be that anaconda doesn't honor that flag, but I believe it's there. So either it's not set / set too high or it's not honored. So what is the max length of the label? // Stefan From owner-linux-xfs@oss.sgi.com Mon May 3 14:58:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 14:58:55 -0700 (PDT) Received: from mail.13thfloor.at (MAIL.13thfloor.at [212.16.62.51]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i43LwjKO010000 for ; Mon, 3 May 2004 14:58:46 -0700 Received: by mail.13thfloor.at (Postfix, from userid 1001) id 2A25B510072; Mon, 3 May 2004 23:58:41 +0200 (CEST) Date: Mon, 3 May 2004 23:58:41 +0200 From: Herbert Poetzl To: linux-xfs@oss.sgi.com Subject: typo in XFS_IOC_GETXFLAGS? Message-ID: <20040503215840.GA26617@MAIL.13thfloor.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 3017 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: herbert@13thfloor.at Precedence: bulk X-list: linux-xfs Content-Length: 407 Lines: 16 Hi Folks! xfs_ioc_xattr() uses in XFS_IOC_GETXFLAGS the XFS_XFLAG_* defines for di_flags comparison, shouldn't that be XFS_DIFLAG_IMMUTABLE and friends instead? if (ip->i_d.di_flags & XFS_XFLAG_IMMUTABLE) flags |= LINUX_XFLAG_IMMUTABLE; if (ip->i_d.di_flags & XFS_XFLAG_APPEND) flags |= LINUX_XFLAG_APPEND; TIA, Herbert From owner-linux-xfs@oss.sgi.com Mon May 3 15:04:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 15:04:48 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i43M4eKO010707 for ; Mon, 3 May 2004 15:04:41 -0700 Received: from hpti9.fsl.noaa.gov ([137.75.132.229]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Mon, 3 May 2004 18:02:23 -0400 Subject: Re: Questions about pagebuf code From: Craig Tierney To: Russell Cattelan Cc: linux-xfs@oss.sgi.com In-Reply-To: <1083614597.24397.16.camel@naboo.americas.sgi.com> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> <1083446482.2302.22.camel@localhost.localdomain> <1083614597.24397.16.camel@naboo.americas.sgi.com> Content-Type: text/plain Message-Id: <1083621685.2398.21.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 03 May 2004 16:01:25 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2004 22:02:24.0032 (UTC) FILETIME=[507BBA00:01C4315A] X-archive-position: 3018 X-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: 3252 Lines: 83 On Mon, 2004-05-03 at 14:03, Russell Cattelan wrote: > Look at this bug and see if matches you're situation. > http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 > I cannot say for certain it is, but I am not sure. My writes don't jump around in the file, it is just a series of reads, then writes, and then another series of reads then again writes. However, I downloaded both test codes and I am trying them out. > I've been taking a bunch of stabs at this bug trying to > figure out the problem. > Everything so far had proved to be an incorrect theory of the problem. > > My latest thought is a race someplace in generic_file_write since xfs > is was calling it with the i_sem held. > I'm testing some code now but either I'm missing something or adding > the lock has not helped the problem. > > I've mostly ruled out the problem being per-page since as the test in > 198 shows the corruption is the size of give write. In the case of > doublewrite 16k. > > What appears to be happening as the file is grown out of order in > relation to the writes that are happening every once in a while a 16k > write is simply forgotten about. > > In other words write 16k at 16k then write 16k at 0k. > So grow to 32k starting at 16k then go back and fill in > the 0-16k block and sometimes the 0-16k block is simply not written > to disk. > > I'm going to keep looking at this i_sem not locked theory a bit longer > before I give up on yet another theory. > > If you have any observations theory let me know it might be helpful. I need to write some code to verify, but it might be that the corrupted data is actual data from another place in the file. Or, it is data from a different file. In one place the corruption looked like a different set of values. It was supposed to be velocities (+/- 5.0) but then ended up looking like temperatures (between 250.0 and 300.0). So the question is, if this is indeed the case, are those values from this file, or another one? I am not sure if this could be caused by 'forgetting' to write a particular chuck as you described above. I will test that as well. On a new filesystem, I should not get so lucky as to have values that look like temperatures (or whatever it was to be). Craig > > > > Thanks for the details. > > > > I am trying to debug a problem with file corruption writing to my xfs > > filesystem (over nfs) when the server is under heavy load (16+ clients > > writing simultaneously to different directories). It does happen with > > different versions under the 2.4 kernel. It doesn't happen wen ext2 or > > jfs is used as the underlying filesystem. It does happen more often on > > when faster servers are used, and the corruption is always page aligned > > (starts at ADDR%4096==0, ends at ADDR%4096=4095). > > > > Since the corruption is always page aligned, and it happens more often > > on faster servers, I suspect there is some race condition or missed lock > > were pages are selected for use. > > > > I didn't completely understand the difference between v/kmalloc, but > > if there is an issue with mvalloc timings, I figured I would remove all > > vmallocs (because it is easy) to see if it changed anything. > > > > Thanks, > > CRaig > > > > > > From owner-linux-xfs@oss.sgi.com Mon May 3 15:16:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 15:16:47 -0700 (PDT) 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 i43MGgKO011253 for ; Mon, 3 May 2004 15:16:42 -0700 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 i43M52BN027517 for ; Mon, 3 May 2004 17:05:02 -0500 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 i43M52Ke37947162; Mon, 3 May 2004 17:05:02 -0500 (CDT) 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 i43M4uHP2199916; Mon, 3 May 2004 17:04:56 -0500 (CDT) Date: Mon, 3 May 2004 17:04:56 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Stefan Smietanowski cc: Seth Mos , Steve Lord , Subject: Re: bugzilla entries for XFS in Fedora Core 2 test 3 In-Reply-To: <409693EF.2080609@stesmi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3019 X-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: 980 Lines: 32 On Mon, 3 May 2004, Stefan Smietanowski wrote: > What's the limit of label length? from the xfs_admin man page... -L label Set the filesystem label. XFS filesystem labels can be at most 12 characters long; if label is longer than 12 characters, xfs_admin will truncate it and print a warning message. The filesystem label can be cleared using the special ``--'' value for label. > I believe there's a setting in anaconda one can make and the bug > could well be that anaconda doesn't honor that flag, but I believe > it's there. i've seen it there once, have not looked at fc2 anaconda. in any case the reason florin was having trouble was not related to this, he had old md superblocks on the devices, mkfs did not wipe them out, and mount didn't scan them because of this. -eric > So either it's not set / set too high or it's not honored. > > So what is the max length of the label? > > // Stefan > > From owner-linux-xfs@oss.sgi.com Mon May 3 15:29:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 15:30:02 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i43MTvKO011744 for ; Mon, 3 May 2004 15:29:58 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i43MTuId011771; Tue, 4 May 2004 00:29:56 +0200 Message-ID: <4096C7C8.9090907@stesmi.com> Date: Tue, 04 May 2004 00:29:28 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Seth Mos , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: bugzilla entries for XFS in Fedora Core 2 test 3 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3020 X-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: 488 Lines: 17 Hi Eric. >>I believe there's a setting in anaconda one can make and the bug >>could well be that anaconda doesn't honor that flag, but I believe >>it's there. > > i've seen it there once, have not looked at fc2 anaconda. I've checked the latest development fc2 installer (don't know if that's one in test3 but this is the latest anyway) and it has max length set to 12 as it should be. But as you said, the bug is unrelated to this but it's still good to have checked it. // Stefan From owner-linux-xfs@oss.sgi.com Mon May 3 15:36:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 15:36:24 -0700 (PDT) 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 i43MaLKO012199 for ; Mon, 3 May 2004 15:36:21 -0700 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 i43MaFhv001051 for ; Mon, 3 May 2004 15:36:16 -0700 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.10/SGI_generic_relay-1.2) with ESMTP id i43MaFKe37951539 for ; Mon, 3 May 2004 17:36:15 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i43MaEXa6175353; Mon, 3 May 2004 17:36:14 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id i43MZ38D003743; Mon, 3 May 2004 17:35:03 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id i43MZ214003741; Mon, 3 May 2004 17:35:03 -0500 Date: Mon, 3 May 2004 17:35:03 -0500 From: Eric Sandeen Message-Id: <200405032235.i43MZ214003741@penguin.americas.sgi.com> Subject: TAKE 913895 - X-archive-position: 3021 X-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@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 583 Lines: 23 zero more at end of device at mkfs time, be sure to get any old md superblock (which throws off mount-by-label) Date: Mon May 3 15:35:41 PDT 2004 Workarea: penguin.americas.sgi.com:/src/eric/xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:171114a xfsprogs/VERSION - 1.107 - bump version xfsprogs/doc/CHANGES - 1.145 - doc change xfsprogs/mkfs/xfs_mkfs.c - 1.57 - zero more at end of device at mkfs time, be sure to get any old md superblock (which throws off mount-by-label) From owner-linux-xfs@oss.sgi.com Mon May 3 15:42:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 15:42:11 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i43Mg6KO012708 for ; Mon, 3 May 2004 15:42:06 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i43Mhoqo026965 for ; Mon, 3 May 2004 15:43:50 -0700 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 i43MfxKe37876255; Mon, 3 May 2004 17:41:59 -0500 (CDT) 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 i43MfxHP2217198; Mon, 3 May 2004 17:41:59 -0500 (CDT) Date: Mon, 3 May 2004 17:41:59 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Stefan Smietanowski cc: Seth Mos , Steve Lord , Subject: Re: bugzilla entries for XFS in Fedora Core 2 test 3 In-Reply-To: <4096C7C8.9090907@stesmi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3022 X-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: 528 Lines: 17 On Tue, 4 May 2004, Stefan Smietanowski wrote: > I've checked the latest development fc2 installer (don't know if that's > one in test3 but this is the latest anyway) and it has max length set > to 12 as it should be. > > But as you said, the bug is unrelated to this but it's still good to > have checked it. yep, thanks stefan. there is also a problem with the bulkstat interface in fc2, this will affect at least xfsdump.... we've got a patch to fix it, hopefully rh^Wfedora will take the patch before they ship. -eric From owner-linux-xfs@oss.sgi.com Mon May 3 15:56:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 15:56:13 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i43Mu9KO013243 for ; Mon, 3 May 2004 15:56:09 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i43Mvq2t030720 for ; Mon, 3 May 2004 15:57:53 -0700 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 IAA29264; Tue, 4 May 2004 08:55:53 +1000 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 i43Mtmln147166; Tue, 4 May 2004 08:55:49 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i43MtkKu147864; Tue, 4 May 2004 08:55:46 +1000 (EST) Date: Tue, 4 May 2004 08:55:46 +1000 From: Nathan Scott To: Herbert Poetzl Cc: linux-xfs@oss.sgi.com Subject: Re: typo in XFS_IOC_GETXFLAGS? Message-ID: <20040504085546.B127559@wobbly.melbourne.sgi.com> References: <20040503215840.GA26617@MAIL.13thfloor.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040503215840.GA26617@MAIL.13thfloor.at>; from herbert@13thfloor.at on Mon, May 03, 2004 at 11:58:41PM +0200 X-archive-position: 3023 X-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: 542 Lines: 23 Hi Herbert, On Mon, May 03, 2004 at 11:58:41PM +0200, Herbert Poetzl wrote: > > Hi Folks! > > xfs_ioc_xattr() uses in XFS_IOC_GETXFLAGS the > XFS_XFLAG_* defines for di_flags comparison, > shouldn't that be XFS_DIFLAG_IMMUTABLE and > friends instead? > > if (ip->i_d.di_flags & XFS_XFLAG_IMMUTABLE) > flags |= LINUX_XFLAG_IMMUTABLE; > if (ip->i_d.di_flags & XFS_XFLAG_APPEND) > flags |= LINUX_XFLAG_APPEND; Yep, good catch - thanks. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon May 3 16:01:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 16:01:44 -0700 (PDT) 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 i43N1eKO013705 for ; Mon, 3 May 2004 16:01:40 -0700 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 i43N0iBN017089 for ; Mon, 3 May 2004 18:00:44 -0500 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 i43N0iKe37877076 for ; Mon, 3 May 2004 18:00:44 -0500 (CDT) 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 i43N0iHP2197080 for ; Mon, 3 May 2004 18:00:44 -0500 (CDT) Date: Mon, 3 May 2004 18:00:44 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: linux-xfs@oss.sgi.com Subject: updated userspace available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3024 X-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: 175 Lines: 10 just a note, newer versions of userspace pkgs are on oss.sgi.com now: acl-2.2.23 (not updated since last push) attr-2.4.16 dmapi-2.2.0 xfsdump-2.2.21 xfsprogs-2.6.13 -Eric From owner-linux-xfs@oss.sgi.com Mon May 3 16:22:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 16:23:04 -0700 (PDT) Received: from mail.13thfloor.at (MAIL.13thfloor.at [212.16.62.51]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i43NMmKO017610 for ; Mon, 3 May 2004 16:22:48 -0700 Received: by mail.13thfloor.at (Postfix, from userid 1001) id 0C10F510072; Tue, 4 May 2004 01:00:42 +0200 (CEST) Date: Tue, 4 May 2004 01:00:42 +0200 From: Herbert Poetzl To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: typo in XFS_IOC_GETXFLAGS? Message-ID: <20040503230042.GA27312@MAIL.13thfloor.at> References: <20040503215840.GA26617@MAIL.13thfloor.at> <20040504085546.B127559@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040504085546.B127559@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.1i X-archive-position: 3025 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: herbert@13thfloor.at Precedence: bulk X-list: linux-xfs Content-Length: 1323 Lines: 47 On Tue, May 04, 2004 at 08:55:46AM +1000, Nathan Scott wrote: > Hi Herbert, > > On Mon, May 03, 2004 at 11:58:41PM +0200, Herbert Poetzl wrote: > > > > Hi Folks! > > > > xfs_ioc_xattr() uses in XFS_IOC_GETXFLAGS the > > XFS_XFLAG_* defines for di_flags comparison, > > shouldn't that be XFS_DIFLAG_IMMUTABLE and > > friends instead? > > > > if (ip->i_d.di_flags & XFS_XFLAG_IMMUTABLE) > > flags |= LINUX_XFLAG_IMMUTABLE; > > if (ip->i_d.di_flags & XFS_XFLAG_APPEND) > > flags |= LINUX_XFLAG_APPEND; > > Yep, good catch - thanks. well, stumbled over another one ... this actually needs a little additional code ... xfs_ioc_xattr() in XFS_IOC_SETXFLAGS calls xfs_merge_ioc_xflags() which is supposed to merge XFS_XFLAG_* values, but it is passed a di_flags, so you gonna need some conversion like ... old_flags = 0; if (ip->i_d.di_flags & XFS_DIFLAG_IMMUTABLE) oldflags |= LINUX_XFLAG_IMMUTABLE; if (ip->i_d.di_flags & XFS_DIFLAG_APPEND) oldflags |= LINUX_XFLAG_APPEND; ... va.va_mask = XFS_AT_XFLAGS; va.va_xflags = xfs_merge_ioc_xflags(flags, old_flags); HTH, Herbert > cheers. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Mon May 3 17:46:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 17:46:46 -0700 (PDT) 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 i440kfKO019408 for ; Mon, 3 May 2004 17:46:42 -0700 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 i440a1BN017229 for ; Mon, 3 May 2004 19:36:04 -0500 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 KAA01515; Tue, 4 May 2004 10:35:43 +1000 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 i440Zfln149818; Tue, 4 May 2004 10:35:41 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i440ZbEV149893; Tue, 4 May 2004 10:35:37 +1000 (EST) Date: Tue, 4 May 2004 10:35:37 +1000 From: Nathan Scott To: Joe Schulz Cc: linux-xfs@oss.sgi.com Subject: Re: dm-crypt + xfs = no quota? Message-ID: <20040504103537.A149002@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from joe@spamfilter.de on Mon, May 03, 2004 at 11:44:25AM +0200 X-archive-position: 3026 X-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: 490 Lines: 19 On Mon, May 03, 2004 at 11:44:25AM +0200, Joe Schulz wrote: > > Hello all, > > I have a secure setup here with the root partition mounted on a dm-crypt > layer. kernel is 2.6.5. Unfortunately when mounting the fs, I always get > this in the logs: XFS: unknown mount option [quota]. > ... > Any ideas what I could do to get quota working? > XFS quota mount option(s) for the root device need to be passed in via "rootflags=..." in the kernel boot parameter list. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon May 3 19:32:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 19:32:57 -0700 (PDT) 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 i442WqKO021321 for ; Mon, 3 May 2004 19:32:52 -0700 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 i442Wjhv005096 for ; Mon, 3 May 2004 19:32:46 -0700 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 MAA04061; Tue, 4 May 2004 12:32:41 +1000 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 i442Wdln152332; Tue, 4 May 2004 12:32:40 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i442WYdD152080; Tue, 4 May 2004 12:32:34 +1000 (EST) Date: Tue, 4 May 2004 12:32:34 +1000 From: Nathan Scott To: Herbert Poetzl Cc: linux-xfs@oss.sgi.com Subject: Re: typo in XFS_IOC_GETXFLAGS? Message-ID: <20040504123233.D149002@wobbly.melbourne.sgi.com> References: <20040503215840.GA26617@MAIL.13thfloor.at> <20040504085546.B127559@wobbly.melbourne.sgi.com> <20040503230042.GA27312@MAIL.13thfloor.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040503230042.GA27312@MAIL.13thfloor.at>; from herbert@13thfloor.at on Tue, May 04, 2004 at 01:00:42AM +0200 X-archive-position: 3027 X-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: 740 Lines: 26 Hi Herbert, On Tue, May 04, 2004 at 01:00:42AM +0200, Herbert Poetzl wrote: > On Tue, May 04, 2004 at 08:55:46AM +1000, Nathan Scott wrote: > > On Mon, May 03, 2004 at 11:58:41PM +0200, Herbert Poetzl wrote: > > > > > > xfs_ioc_xattr() uses in XFS_IOC_GETXFLAGS the > > > XFS_XFLAG_* defines for di_flags comparison, > > > shouldn't that be XFS_DIFLAG_IMMUTABLE and > > > friends instead? > > > > > Yep, good catch - thanks. > > well, stumbled over another one ... this > actually needs a little additional code ... Actually, it turns out that both of these are fine (thought I tested this!) because the XFS_XFLAG and XFS_DIFLAG values are the same. Still, its pretty confusing - I'll clear it up in the code. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon May 3 20:27:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 May 2004 20:27:30 -0700 (PDT) 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 i443RQKO026404 for ; Mon, 3 May 2004 20:27:26 -0700 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 i443Kfhv005888 for ; Mon, 3 May 2004 20:20:44 -0700 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 NAA04900; Tue, 4 May 2004 13:20:33 +1000 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 i443KWln152969; Tue, 4 May 2004 13:20:32 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i443KRcD146660; Tue, 4 May 2004 13:20:27 +1000 (EST) Date: Tue, 4 May 2004 13:20:27 +1000 From: Nathan Scott To: Craig Tierney Cc: linux-xfs@oss.sgi.com Subject: Re: Questions about pagebuf code Message-ID: <20040504132027.F149002@wobbly.melbourne.sgi.com> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> <1083446482.2302.22.camel@localhost.localdomain> <20040503143821.A124474@wobbly.melbourne.sgi.com> <1083605113.2398.5.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1083605113.2398.5.camel@hpti9.fsl.noaa.gov>; from ctierney@HPTI.com on Mon, May 03, 2004 at 11:25:13AM -0600 X-archive-position: 3029 X-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: 287 Lines: 13 On Mon, May 03, 2004 at 11:25:13AM -0600, Craig Tierney wrote: > > Yes. ia32 page size is 4k, and I didn't change the blocksize > (not that XFS would let me). It will -- use the -bsize= option to mkfs, can be any power of 2 between 512 bytes and your page size. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue May 4 02:36:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 02:36:33 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i449aRKO009453 for ; Tue, 4 May 2004 02:36:28 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i449aRLl009452 for linux-xfs@oss.sgi.com; Tue, 4 May 2004 02:36:27 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i449aQKQ009438 for ; Tue, 4 May 2004 02:36:26 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i448gDGE008669; Tue, 4 May 2004 01:42:13 -0700 Date: Tue, 4 May 2004 01:42:13 -0700 Message-Id: <200405040842.i448gDGE008669@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 327] New: Indestructible directories X-Bugzilla-Reason: AssignedTo X-archive-position: 3030 X-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: 2965 Lines: 73 http://oss.sgi.com/bugzilla/show_bug.cgi?id=327 Summary: Indestructible directories Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: sziwan@users.sourceforge.net I suffered from major filesystem corruption while testing third party patches. The filesystem shut down and was handled with xfs_repair. After that, several directories were found in /lost+found that could no longer be removed, e.g.: # ls -la /lost+found/12616156/ total 8 drwxrwxrwx 2 root root 4096 2004-04-29 15:22 ./ drwxr-xr-x 12 root root 155 2004-04-30 10:53 ../ # rmdir /lost+found/12616156 rmdir: `/lost+found/12616156': Directory not empty # # rm -rf /lost+found/12616156 rm: cannot remove directory `/lost+found/12616156': Directory not empty Here's a trace of rm -rf /lost+found/12616156: #v+ unlink("/lost+found/12616156") = -1 EISDIR (Is a directory) open(".", O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 3 lstat64("/lost+found/12616156", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 chdir("/lost+found/12616156") = 0 lstat64(".", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4 fstat64(4, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 brk(0) = 0x8054000 brk(0x8055000) = 0x8055000 getdents64(4, /* 2 entries */, 4096) = 48 getdents64(4, /* 0 entries */, 4096) = 0 close(4) = 0 fchdir(3) = 0 lstat64(".", {st_mode=S_IFDIR|0710, st_size=4096, ...}) = 0 rmdir("/lost+found/12616156") = -1 ENOTEMPTY (Directory not empty) #v- Subsequent xfs_repair runs do not fix the problem, the directories are simply unlinked and relinked in /lost+found. As requested, I provide more info: # xfs_info / meta-data=/ isize=256 agcount=8, agsize=192276 blks = sectsz=512 data = bsize=2048 blocks=1538208, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=2048 blocks=1728, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 # xfs_bmap -vv /lost+found/12616156 /lost+found/12616156: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: 4626592..4626599 6 (11968..11975) 8 ------- 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 May 4 04:17:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 04:18:08 -0700 (PDT) Received: from mail.13thfloor.at (MAIL.13thfloor.at [212.16.62.51]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i44BHmKO013577 for ; Tue, 4 May 2004 04:17:49 -0700 Received: by mail.13thfloor.at (Postfix, from userid 1001) id 25A1C510072; Tue, 4 May 2004 12:56:30 +0200 (CEST) Date: Tue, 4 May 2004 12:56:30 +0200 From: Herbert Poetzl To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: typo in XFS_IOC_GETXFLAGS? Message-ID: <20040504105629.GA1531@MAIL.13thfloor.at> References: <20040503215840.GA26617@MAIL.13thfloor.at> <20040504085546.B127559@wobbly.melbourne.sgi.com> <20040503230042.GA27312@MAIL.13thfloor.at> <20040504123233.D149002@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040504123233.D149002@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.1i X-archive-position: 3031 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: herbert@13thfloor.at Precedence: bulk X-list: linux-xfs Content-Length: 1091 Lines: 40 On Tue, May 04, 2004 at 12:32:34PM +1000, Nathan Scott wrote: > Hi Herbert, > > On Tue, May 04, 2004 at 01:00:42AM +0200, Herbert Poetzl wrote: > > On Tue, May 04, 2004 at 08:55:46AM +1000, Nathan Scott wrote: > > > On Mon, May 03, 2004 at 11:58:41PM +0200, Herbert Poetzl wrote: > > > > > > > > xfs_ioc_xattr() uses in XFS_IOC_GETXFLAGS the > > > > XFS_XFLAG_* defines for di_flags comparison, > > > > shouldn't that be XFS_DIFLAG_IMMUTABLE and > > > > friends instead? > > > > > > > Yep, good catch - thanks. > > > > well, stumbled over another one ... this > > actually needs a little additional code ... > > Actually, it turns out that both of these are fine (thought > I tested this!) because the XFS_XFLAG and XFS_DIFLAG values well, never said that it wouldn't work ;) > are the same. Still, its pretty confusing - I'll clear it > up in the code. okay, thanks ... best, Herbert PS: is there some documentation about the XFS quota code, I'd like to extend the quota system by allowing more than one quota hash for each filesystem (vfsmount) > cheers. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Tue May 4 12:12:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 12:12:30 -0700 (PDT) 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 i44JCQKO016233 for ; Tue, 4 May 2004 12:12:26 -0700 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 i44J04hv026870 for ; Tue, 4 May 2004 12:00:05 -0700 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 i44J02Ke37921401; Tue, 4 May 2004 14:00:02 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1BL597-0002QQ-00; Tue, 04 May 2004 14:00:01 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 913867 - Properly account for clustered pages in the writeout path Message-Id: From: Christoph Hellwig Date: Tue, 04 May 2004 14:00:01 -0500 X-archive-position: 3034 X-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: 365 Lines: 14 Date: Tue May 4 11:59:38 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:171157a fs/xfs/linux-2.6/xfs_aops.c - 1.68 - decrement wbc->nr_to_write to avoid confusion in the VM writeback logic. From owner-linux-xfs@oss.sgi.com Tue May 4 12:28:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 12:28:43 -0700 (PDT) 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 i44JScKO020493 for ; Tue, 4 May 2004 12:28:39 -0700 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 i44JRMhv027491 for ; Tue, 4 May 2004 12:27:22 -0700 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 i44JRLKe37562073; Tue, 4 May 2004 14:27:21 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1BL5ZY-0003jV-00; Tue, 04 May 2004 14:27:20 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 913934 - fix direct user memory dereference in bulkstat Message-Id: From: Christoph Hellwig Date: Tue, 04 May 2004 14:27:20 -0500 X-archive-position: 3035 X-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: 391 Lines: 15 Date: Tue May 4 12:27:00 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans, roehrich, sandeen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:171167a fs/xfs/xfs_itable.c - 1.122 - do copy_to_user in xfs_bulkstat_one, always pass user buffer in xfs_bulkstat_single From owner-linux-xfs@oss.sgi.com Tue May 4 12:30:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 12:31:06 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i44JUxKO020904 for ; Tue, 4 May 2004 12:30:59 -0700 Received: from hpti9.fsl.noaa.gov ([137.75.132.229]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 15:30:56 -0400 Subject: Re: Questions about pagebuf code From: Craig Tierney To: Russell Cattelan Cc: linux-xfs@oss.sgi.com In-Reply-To: <1083614597.24397.16.camel@naboo.americas.sgi.com> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> <1083446482.2302.22.camel@localhost.localdomain> <1083614597.24397.16.camel@naboo.americas.sgi.com> Content-Type: text/plain Message-Id: <1083698993.2376.4.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 04 May 2004 13:29:53 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2004 19:30:57.0333 (UTC) FILETIME=[52CD3E50:01C4320E] X-archive-position: 3036 X-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: 794 Lines: 24 On Mon, 2004-05-03 at 14:03, Russell Cattelan wrote: > Look at this bug and see if matches you're situation. > http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 I ran doublewrite on my server. I bumped up the threads to 20 and was easy able to generate a problem. I wrote a script that submitted 1 doublewrite process to each of 20 nodes, to more mimic what I am doing. I ran these for 6 hours and did not have a problem. It could be that my jobs are putting more of a load on the system, or the problem isn't the same. However, since the doublewrite test passes on a uni-processor kernel, I am rebuilding my kernel and will rerun my test to see if it works or not. The codes might not be the same, but if it is a race condition there still might be something similar there. Craig From owner-linux-xfs@oss.sgi.com Tue May 4 13:37:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 13:37:21 -0700 (PDT) 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 i44KbFKO023015 for ; Tue, 4 May 2004 13:37:15 -0700 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 i44KTAT9006971 for ; Tue, 4 May 2004 15:29:10 -0500 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.10/SGI_generic_relay-1.2) with ESMTP id i44KT9Ke37947790; Tue, 4 May 2004 15:29:09 -0500 (CDT) Received: from [128.162.233.73] (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i44KT9Xa6259986; Tue, 4 May 2004 15:29:09 -0500 (CDT) Subject: Re: Questions about pagebuf code From: Russell Cattelan To: Craig Tierney Cc: linux-xfs@oss.sgi.com In-Reply-To: <1083698993.2376.4.camel@hpti9.fsl.noaa.gov> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> <1083446482.2302.22.camel@localhost.localdomain> <1083614597.24397.16.camel@naboo.americas.sgi.com> <1083698993.2376.4.camel@hpti9.fsl.noaa.gov> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-t1bkwEkQd4TE03nzySoQ" Message-Id: <1083702549.4107.16.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.5.7-2mdk Date: Tue, 04 May 2004 15:29:09 -0500 X-archive-position: 3037 X-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: 1686 Lines: 55 --=-t1bkwEkQd4TE03nzySoQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-05-04 at 13:29 -0600, Craig Tierney wrote: > On Mon, 2004-05-03 at 14:03, Russell Cattelan wrote: > > Look at this bug and see if matches you're situation. > > http://oss.sgi.com/bugzilla/show_bug.cgi?id=3D198 >=20 >=20 > I ran doublewrite on my server. I bumped up the threads > to 20 and was easy able to generate a problem.=20=20 >=20 > I wrote a script that submitted 1 doublewrite process > to each of 20 nodes, to more mimic what I am doing. I ran > these for 6 hours and did not have a problem. It could > be that my jobs are putting more of a load on the system, > or the problem isn't the same. The test was designed to mimic the out of order writes that=20 nfs often generates. So 20 nfs clients banging on the same file on a server would=20 probably end up corrupting it. > However, since the doublewrite test passes on a uni-processor > kernel, I am rebuilding my kernel and will rerun my test > to see if it works or not.=20=20 >=20 > The codes might not be the same, but if it is a race condition > there still might be something similar there. The problem still exists I just don't have a clue at to where the race might be. >=20 > Craig >=20 >=20 --=20 Russell Cattelan --=-t1bkwEkQd4TE03nzySoQ 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) iD8DBQBAl/0VNRmM+OaGhBgRArSYAJ4ipUeEx2z7IjqLpRBLqwV3ZnyGPgCfeVAG OslCPubcJN4sF/XxQylwfQQ= =pzI3 -----END PGP SIGNATURE----- --=-t1bkwEkQd4TE03nzySoQ-- From owner-linux-xfs@oss.sgi.com Tue May 4 17:04:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 17:04:47 -0700 (PDT) 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 i4504dKO029753 for ; Tue, 4 May 2004 17:04:40 -0700 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 i4504WT9008841 for ; Tue, 4 May 2004 19:04:33 -0500 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 KAA28765; Wed, 5 May 2004 10:04:21 +1000 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 i4504Jln177999; Wed, 5 May 2004 10:04:19 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4504HBL178045; Wed, 5 May 2004 10:04:17 +1000 (EST) Date: Wed, 5 May 2004 10:04:17 +1000 From: Nathan Scott To: Herbert Poetzl Cc: linux-xfs@oss.sgi.com Subject: Re: typo in XFS_IOC_GETXFLAGS? Message-ID: <20040505100417.B153962@wobbly.melbourne.sgi.com> References: <20040503215840.GA26617@MAIL.13thfloor.at> <20040504085546.B127559@wobbly.melbourne.sgi.com> <20040503230042.GA27312@MAIL.13thfloor.at> <20040504123233.D149002@wobbly.melbourne.sgi.com> <20040504105629.GA1531@MAIL.13thfloor.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040504105629.GA1531@MAIL.13thfloor.at>; from herbert@13thfloor.at on Tue, May 04, 2004 at 12:56:30PM +0200 X-archive-position: 3038 X-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: 838 Lines: 28 Hi Herbert, On Tue, May 04, 2004 at 12:56:30PM +0200, Herbert Poetzl wrote: > On Tue, May 04, 2004 at 12:32:34PM +1000, Nathan Scott wrote: > > > > Actually, it turns out that both of these are fine (thought > > I tested this!) because the XFS_XFLAG and XFS_DIFLAG values > > well, never said that it wouldn't work ;) Heh. > PS: is there some documentation about the XFS > quota code, I'd like to extend the quota system > by allowing more than one quota hash for each > filesystem (vfsmount) Not really. The code has a fairly liberal sprinkling of comments though, thats probably your best bet. Can you elaborate a bit more on what you mean by one quota hash for each fs? (separate dquot hash tables per-fs?) Is that based on observed performance problems, or to provide some alternate functionality...? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue May 4 17:36:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 17:36:44 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i450aWKO031728 for ; Tue, 4 May 2004 17:36:32 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i450aWKm031725 for linux-xfs@oss.sgi.com; Tue, 4 May 2004 17:36:32 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i450aTKQ031694 for ; Tue, 4 May 2004 17:36:29 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i44NorZ2029344; Tue, 4 May 2004 16:50:53 -0700 Date: Tue, 4 May 2004 16:50:53 -0700 Message-Id: <200405042350.i44NorZ2029344@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 3040 X-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: 2855 Lines: 77 http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 ------- Additional Comments From steven.wilton@team.eftel.com 2004-04-05 16:50 PDT ------- And last night we got the following from a 2.6.6-rc3 kernel after 3 days uptime: xfs_iget_core: ambiguous vns: vp/0xda730220, invp/0xc686a940 ------------[ cut here ]------------ kernel BUG at fs/xfs/support/debug.c:106! invalid operand: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010246 (2.6.6-rc3) EIP is at cmn_err+0x88/0x98 eax: 00000040 ebx: 00000293 ecx: 00000001 edx: c0396224 esi: c034a747 edi: c0456d1e ebp: 00000000 esp: eec86a70 ds: 007b es: 007b ss: 0068 Process lockd (pid: 385, threadinfo=eec86000 task=ee50cb90) Stack: ef91f090 ef439d28 0002013c 00000000 ef42d600 c0201e92 00000000 c0346520 da730220 c686a940 c686a960 c686a940 00000008 ef439c00 cab1f060 c0202204 c686a940 ef439c00 00000000 0002013c 00000000 00000008 eec86b18 00000000 Call Trace: [] xfs_iget_core+0xf6/0x400 [] xfs_iget+0x68/0x118 [] xfs_vget+0x42/0xb8 [] vfs_vget+0x27/0x2c [] linvfs_get_dentry+0x48/0x88 [] find_exported_dentry+0x3d/0x59c [] ip_finish_output2+0x13f/0x18c [] ip_finish_output2+0x0/0x18c [] nf_hook_slow+0xdd/0x120 [] dst_output+0x0/0x24 [] ip_finish_output+0x1d3/0x1dc [] ip_finish_output2+0x0/0x18c [] dst_output+0x0/0x24 [] nf_hook_slow+0xa0/0x120 [] ip_output+0x6e/0x74 [] dst_output+0x11/0x24 [] nf_hook_slow+0xdd/0x120 [] ip_push_pending_frames+0x2e9/0x394 [] dst_output+0x0/0x24 [] udp_push_pending_frames+0x1d0/0x1f0 [] release_sock+0x4c/0x50 [] udp_sendmsg+0x522/0x5c4 [] ip_append_data+0x2d4/0x6b8 [] udp_sendmsg+0x4ea/0x5c4 [] ip_generic_getfrag+0x0/0x90 [] groups_free+0x3b/0x44 [] export_decode_fh+0x66/0x6e [] nfsd_acceptable+0x0/0xcc [] fh_verify+0x398/0x554 [] nfsd_acceptable+0x0/0xcc [] nfsd_open+0x2c/0x150 [] nlm_fopen+0x7b/0x100 [] nlm_lookup_file+0x153/0x1f8 [] nlm4svc_retrieve_args+0x74/0xc0 [] nlm4svc_proc_unlock+0x61/0xbc [] svc_process+0x2fd/0x5f8 [] lockd+0x150/0x1fc [] lockd+0x0/0x1fc [] kernel_thread_helper+0x5/0xc Code: 0f 0b 6a 00 2e a7 34 c0 5b 5e 5f 5d 59 c3 89 f6 83 ec 04 55 <4>pagebuf_get: warning, failed to lookup pages pagebuf_get: warning, failed to lookup pages pagebuf_get: warning, failed to lookup pages pagebuf_get: warning, failed to lookup pages ------- 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 May 4 17:36:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 17:36:38 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i450aWKO031727 for ; Tue, 4 May 2004 17:36:32 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i450aWmM031726 for linux-xfs@oss.sgi.com; Tue, 4 May 2004 17:36:32 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i450aTKW031694 for ; Tue, 4 May 2004 17:36:30 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i44No0v3029308; Tue, 4 May 2004 16:50:00 -0700 Date: Tue, 4 May 2004 16:50:00 -0700 Message-Id: <200405042350.i44No0v3029308@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 3039 X-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: 3077 Lines: 73 http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 ------- Additional Comments From steven.wilton@team.eftel.com 2004-04-05 16:49 PDT ------- OK, with 2.6.5 and 2.6.6-rc3 we get a "kernel BUG" error in the kernel log. On the 1st of May we got the following from a 2.6.5 kernel (after 2 weeks of uptime): xfs_iget_core: ambiguous vns: vp/0xc31b9b20, invp/0xe53feac0 ------------[ cut here ]------------ kernel BUG at fs/xfs/support/debug.c:106! invalid operand: 0000 [#1] CPU: 0 EIP: 0060:[cmn_err+136/152] Not tainted EFLAGS: 00010246 (2.6.5) EIP is at cmn_err+0x88/0x98 eax: 00000040 ebx: 00000293 ecx: 00000001 edx: c039ada4 esi: c034fb27 edi: c0454f3e ebp: 00000000 esp: ed823a70 ds: 007b es: 007b ss: 0068 Process lockd (pid: 488, threadinfo=ed822000 task=ed847250) Stack: ef24f0d8 ef2c4d28 0002008a 00000000 ef2bfc00 c0206432 00000000 c034b900 c31b9b20 e53feac0 e53feae0 e53feac0 00000008 ef2c4c00 e810d790 c02067a4 e53feac0 ef2c4c00 00000000 0002008a 00000000 00000008 ed823b18 00000000 Call Trace: [xfs_iget_core+246/1024] xfs_iget_core+0xf6/0x400 [xfs_iget+104/280] xfs_iget+0x68/0x118 [xfs_vget+66/184] xfs_vget+0x42/0xb8 [vfs_vget+39/44] vfs_vget+0x27/0x2c [linvfs_get_dentry+72/136] linvfs_get_dentry+0x48/0x88 [find_exported_dentry+61/1436] find_exported_dentry+0x3d/0x59c [ip_finish_output2+319/396] ip_finish_output2+0x13f/0x18c [ip_finish_output2+0/396] ip_finish_output2+0x0/0x18c [nf_hook_slow+221/288] nf_hook_slow+0xdd/0x120 [dst_output+0/36] dst_output+0x0/0x24 [ip_finish_output+467/476] ip_finish_output+0x1d3/0x1dc [ip_finish_output2+0/396] ip_finish_output2+0x0/0x18c [dst_output+0/36] dst_output+0x0/0x24 [nf_hook_slow+160/288] nf_hook_slow+0xa0/0x120 [ip_output+110/116] ip_output+0x6e/0x74 [dst_output+17/36] dst_output+0x11/0x24 [nf_hook_slow+221/288] nf_hook_slow+0xdd/0x120 [ip_push_pending_frames+745/916] ip_push_pending_frames+0x2e9/0x394 [dst_output+0/36] dst_output+0x0/0x24 [udp_push_pending_frames+464/496] udp_push_pending_frames+0x1d0/0x1f0 [release_sock+78/96] release_sock+0x4e/0x60 [udp_sendmsg+1411/1584] udp_sendmsg+0x583/0x630 [ip_append_data+724/1720] ip_append_data+0x2d4/0x6b8 [udp_sendmsg+1341/1584] udp_sendmsg+0x53d/0x630 [groups_free+59/68] groups_free+0x3b/0x44 [export_decode_fh+102/110] export_decode_fh+0x66/0x6e [nfsd_acceptable+0/204] nfsd_acceptable+0x0/0xcc [fh_verify+920/1364] fh_verify+0x398/0x554 [nfsd_acceptable+0/204] nfsd_acceptable+0x0/0xcc [nfsd_open+44/336] nfsd_open+0x2c/0x150 [nlm_fopen+123/256] nlm_fopen+0x7b/0x100 [nlm_lookup_file+339/504] nlm_lookup_file+0x153/0x1f8 [nlm4svc_retrieve_args+116/192] nlm4svc_retrieve_args+0x74/0xc0 [nlm4svc_proc_unlock+97/188] nlm4svc_proc_unlock+0x61/0xbc [svc_process+765/1528] svc_process+0x2fd/0x5f8 [lockd+336/508] lockd+0x150/0x1fc [lockd+0/508] lockd+0x0/0x1fc [kernel_thread_helper+5/12] kernel_thread_helper+0x5/0xc Code: 0f 0b 6a 00 0e fb 34 c0 5b 5e 5f 5d 59 c3 89 f6 83 ec 04 55 ------- 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 May 4 17:38:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 17:38:20 -0700 (PDT) Received: from mail.13thfloor.at (MAIL.13thfloor.at [212.16.62.51]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i450cEKO032454 for ; Tue, 4 May 2004 17:38:14 -0700 Received: by mail.13thfloor.at (Postfix, from userid 1001) id DC5AD510072; Wed, 5 May 2004 02:38:11 +0200 (CEST) Date: Wed, 5 May 2004 02:38:11 +0200 From: Herbert Poetzl To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: typo in XFS_IOC_GETXFLAGS? Message-ID: <20040505003811.GA9689@MAIL.13thfloor.at> References: <20040503215840.GA26617@MAIL.13thfloor.at> <20040504085546.B127559@wobbly.melbourne.sgi.com> <20040503230042.GA27312@MAIL.13thfloor.at> <20040504123233.D149002@wobbly.melbourne.sgi.com> <20040504105629.GA1531@MAIL.13thfloor.at> <20040505100417.B153962@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040505100417.B153962@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.1i X-archive-position: 3041 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: herbert@13thfloor.at Precedence: bulk X-list: linux-xfs Content-Length: 1580 Lines: 48 On Wed, May 05, 2004 at 10:04:17AM +1000, Nathan Scott wrote: > Hi Herbert, > > On Tue, May 04, 2004 at 12:56:30PM +0200, Herbert Poetzl wrote: > > On Tue, May 04, 2004 at 12:32:34PM +1000, Nathan Scott wrote: > > > > > > Actually, it turns out that both of these are fine (thought > > > I tested this!) because the XFS_XFLAG and XFS_DIFLAG values > > > > well, never said that it wouldn't work ;) > > Heh. > > > PS: is there some documentation about the XFS > > quota code, I'd like to extend the quota system > > by allowing more than one quota hash for each > > filesystem (vfsmount) > > Not really. The code has a fairly liberal sprinkling of comments > though, thats probably your best bet. Can you elaborate a bit > more on what you mean by one quota hash for each fs? (separate > dquot hash tables per-fs?) Is that based on observed performance > problems, or to provide some alternate functionality...? I did a quota hash implementation for 2.4 and 2.6 to remove the strict sb <-> quota requirements (this is for ext2/ext3) which is called "quota hash abstractions", and this in turn is used by the Linux-VServer per context quota patches, which basically require to have a separate 'quota' store (files for ext2/ext3) for each context, if the contexts share the same filesystem ... this works pretty well, and also allows for vfsmount type quota or directory based quota, but the XFS quota is just weird to me atm, so I didn't implement it for XFS yet ... if you need more information, just let me know ... thanks, Herbert > cheers. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Tue May 4 20:50:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 20:50:36 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i453oWKO006470 for ; Tue, 4 May 2004 20:50:32 -0700 Received: from ijet.fsl.noaa.gov ([216.241.42.118]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 23:50:29 -0400 Subject: Re: Questions about pagebuf code From: Craig Tierney To: Russell Cattelan Cc: linux-xfs@oss.sgi.com In-Reply-To: <1083702549.4107.16.camel@naboo.americas.sgi.com> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> <1083446482.2302.22.camel@localhost.localdomain> <1083614597.24397.16.camel@naboo.americas.sgi.com> <1083698993.2376.4.camel@hpti9.fsl.noaa.gov> <1083702549.4107.16.camel@naboo.americas.sgi.com> Content-Type: text/plain Message-Id: <1083728962.2246.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 04 May 2004 21:49:22 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2004 03:50:31.0077 (UTC) FILETIME=[1C8B9D50:01C43254] X-archive-position: 3043 X-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: 586 Lines: 17 > > > > The codes might not be the same, but if it is a race condition > > there still might be something similar there. > The problem still exists I just don't have a clue at to where > the race might be. The doublewrite README indicated that corruption does not happen when a uni-processor kernel is used. I tried that with my code and I still got corruption. Your test is a bit better (smaller, runs locally). I can help try and track down that problem. It might fix my problem. It might also indicate something else pathological that would be related to my problem. Craig From owner-linux-xfs@oss.sgi.com Tue May 4 22:07:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 22:07:48 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4557hKO008150 for ; Tue, 4 May 2004 22:07:43 -0700 Received: from localhost.localdomain (snap.melbourne.sgi.com [134.14.55.59]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i4559caB028594 for ; Tue, 4 May 2004 22:09:39 -0700 Received: from localhost.localdomain (snap [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i455VIA2000839 for ; Wed, 5 May 2004 15:31:19 +1000 Received: (from fsgqa@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i455VI6P000838 for linux-xfs@oss.sgi.com; Wed, 5 May 2004 15:31:18 +1000 Date: Wed, 5 May 2004 15:31:18 +1000 From: FSG QA Message-Id: <200405050531.i455VI6P000838@localhost.localdomain> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - X-archive-position: 3045 X-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@localhost.localdomain.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 524 Lines: 25 Add testing of 128 and 256 K v2 log recovery after shutdown. --Tim (tes@sgi.com) Date: Tue May 4 22:06:41 PDT 2004 Workarea: snap.melbourne.sgi.com:/home/fsgqa/qa/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:171203a xfstests/086.out - 1.3 - Add output for 128 and 256 cases. xfstests/086 - 1.3 xfstests/087 - 1.3 - Add 128K and 256K v2 log buf tests. xfstests/087.out - 1.3 - Add output for 128 and 256 cases. From owner-linux-xfs@oss.sgi.com Tue May 4 22:07:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 22:07:21 -0700 (PDT) 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 i4557FKO008103 for ; Tue, 4 May 2004 22:07:16 -0700 Received: from localhost.localdomain (snap.melbourne.sgi.com [134.14.55.59]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i454x3T9032290 for ; Tue, 4 May 2004 23:59:05 -0500 Received: from localhost.localdomain (snap [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i455MOA2000766; Wed, 5 May 2004 15:22:25 +1000 Received: (from fsgqa@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i455MMCK000765; Wed, 5 May 2004 15:22:22 +1000 Date: Wed, 5 May 2004 15:22:22 +1000 From: FSG QA Message-Id: <200405050522.i455MMCK000765@localhost.localdomain> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 913531 - recovery of v2 logs of log record size of 256K will fail on Linux X-archive-position: 3044 X-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@localhost.localdomain.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1175 Lines: 42 Remove the 128K limitation on pagebuf_get_no_daddr() and allow the kmem_alloc() to fail. This will get recovery of 256K happening (assuming it has no problems getting 256K for its buffer). pv913534 (todo) addresses the possibility of using smaller buffers in v2 log recovery. --Tim Date: Tue May 4 21:52:50 PDT 2004 Workarea: snap.melbourne.sgi.com:/home/fsgqa/qa/xfs-linux Inspected by: hch@lst.de,nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:171201a xfs_log.c - 1.293 - Print out error code if recovery fails. linux-2.6/xfs_buf.c - 1.166 - Remove the 128K limitiation on pagebuf_get_no_daddr() and allow the kmem_alloc to fail. linux-2.6/kmem.h - 1.24 - Add KM_MAYFAIL and if not KM_MAYFAIL set then set __GFP_NOFAIL. linux-2.4/xfs_buf.c - 1.186 - Remove the 128K limitiation on pagebuf_get_no_daddr() and allow the kmem_alloc to fail. linux-2.4/kmem.h - 1.25 - Add KM_MAYFAIL macro. Rearrange an if for setting of lflags - only clear GFP_FS for GFP_KERNEL. linux-2.4/kmem.c - 1.33 - Don't panic on kmem_alloc with KM_SLEEP if KM_MAYFAIL is also set. From owner-linux-xfs@oss.sgi.com Tue May 4 22:12:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 May 2004 22:13:02 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i455CwKO008938 for ; Tue, 4 May 2004 22:12:58 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i455EpZA029763 for ; Tue, 4 May 2004 22:14:53 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i455CjGh192302 for ; Wed, 5 May 2004 15:12:46 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i455Ci0R192264 for linux-xfs@oss.sgi.com; Wed, 5 May 2004 15:12:44 +1000 (AEST) Date: Wed, 5 May 2004 15:12:43 +1000 From: Tim Shimmin To: linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS Message-ID: <20040505151243.V3275@boing.melbourne.sgi.com> References: <20040426165155.GA19148@em.ca> <200404261726.i3QHQ8Aj298772@zhadum.americas.sgi.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: <200404261726.i3QHQ8Aj298772@zhadum.americas.sgi.com>; from overby@sgi.com on Mon, Apr 26, 2004 at 12:26:08PM -0500 X-archive-position: 3046 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1103 Lines: 28 On Mon, Apr 26, 2004 at 12:26:08PM -0500, Glen Overby wrote: > On April 26, Bruce Guenter wrote: > > So far, XFS with an external journal has by far the best delivery rate. > > However, as the filesystem fills and delivery concurrency increases, the > > time required to list, read and delete the delivered files slows down to > > unacceptable levels. Is there anything I can do, settings to modify, > > patches to try, to improve this behavior? > > Some generic suggestions: > > - more log buffers than fewer (try 8) > > - It looks like you're doing a lot of metadata intense operations, so > you should try a larger log buffer size which are available in > version 2 logs. I wrote version 2 logs, along with some other > changes, to speed up metadata intense benchmarks. I think 128mb > log buffers work on linux. > Up to 256Kb log buffers on Linux should work now. (i.e. 32K, 64K, 128K, 256K). > Stay away from log striping. The last I heard, it still doesn't work. If anyone still has problems with log striping then please let us (me in particular) know. Thanks, Tim. From owner-linux-xfs@oss.sgi.com Wed May 5 10:22:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 May 2004 10:22:48 -0700 (PDT) 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 i45HMDKO032308 for ; Wed, 5 May 2004 10:22:13 -0700 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 i45H8wT9008903 for ; Wed, 5 May 2004 12:08:58 -0500 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 i45H8sKe37965165; Wed, 5 May 2004 12:08:54 -0500 (CDT) 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 i45H8qHP2619952; Wed, 5 May 2004 12:08:52 -0500 (CDT) Date: Wed, 5 May 2004 12:08:52 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Johann Lombardi cc: Nathan Scott , Subject: Re: Unsupported sector size In-Reply-To: <200405051900.14735.johann.lombardi@free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3049 X-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: 900 Lines: 35 On Wed, 5 May 2004, Johann Lombardi wrote: > Here is the output of xfs_db: > > # xfs_db /dev/sdc > xfs_db: sb 0 > xfs_db: p dblocks > dblocks = 6553600 hm, (2^16)*100? > xfs_db: p agcount > agcount = 26 > xfs_db: p agblocks > agblocks = 262144 > > dblocks is not 0, so we must be in the second case. > Is agcount x agblocks supposed to be equal to dblocks? the last ag can be smaller, so no, not quite equal. the test you're failing is whether dblocks > agcount * agblocks. 6553600 is a very.... interesting number for dblocks, strikes me as too round. :) i forget, have you tried repair on this filesystem? you can use the -n switch to do a dry run first. what do the other superblocks have to say - try "sb 25" instead of sb 0, etc. have you run growfs on this filesystem? looks to me like maybe some sb corruption - you might also do just "sb 0" and "p" to print all fields. -eric From owner-linux-xfs@oss.sgi.com Wed May 5 10:29:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 May 2004 10:29:56 -0700 (PDT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i45HTSKO000351 for ; Wed, 5 May 2004 10:29:28 -0700 Received: from lns-th2-4f-81-56-250-144.adsl.proxad.net (lns-th2-4f-81-56-250-144.adsl.proxad.net [81.56.250.144]) by postfix4-1.free.fr (Postfix) with ESMTP id AC7081063E3; Wed, 5 May 2004 18:54:15 +0200 (CEST) From: Johann Lombardi Reply-To: johann.lombardi@free.fr To: Eric Sandeen Subject: Re: Unsupported sector size Date: Wed, 5 May 2004 19:00:14 +0200 User-Agent: KMail/1.5.4 References: In-Reply-To: Cc: Nathan Scott , MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405051900.14735.johann.lombardi@free.fr> X-archive-position: 3050 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: johann.lombardi@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 613 Lines: 33 > you get this message if: > > you have 0 data blocks in your fs > or > your data block count doesn't jive with the allocation groups & ag size > > try: > > xfs_db /dev/whatever > sb 0 > p dblocks > p agcount > p agblocks > > and send the results (and look at that line in xfs_mount.c and sort out > what's wrong if you'd like) Here is the output of xfs_db: # xfs_db /dev/sdc xfs_db: sb 0 xfs_db: p dblocks dblocks = 6553600 xfs_db: p agcount agcount = 26 xfs_db: p agblocks agblocks = 262144 dblocks is not 0, so we must be in the second case. Is agcount x agblocks supposed to be equal to dblocks? Johann From owner-linux-xfs@oss.sgi.com Wed May 5 13:53:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 May 2004 13:53:26 -0700 (PDT) Received: from mailgw1.fnal.gov (mailgw1.fnal.gov [131.225.111.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i45KrIKO014598 for ; Wed, 5 May 2004 13:53:21 -0700 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0HX900F01DMIR2@mailgw1.fnal.gov> (original mail from greenc@fnal.gov) for linux-xfs@oss.sgi.com; Wed, 05 May 2004 15:53:18 -0500 (CDT) Received: from maxwell.fnal.gov (maxwell.fnal.gov [131.225.54.225]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPS id <0HX9004EBE0UU3@mailgw1.fnal.gov>; Wed, 05 May 2004 15:53:18 -0500 (CDT) Date: Wed, 05 May 2004 15:53:18 -0500 (CDT) From: Chris Green Subject: Re: xfs 1.3.3 beta 1 stock kernel source configure problems In-reply-to: To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-archive-position: 3051 X-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: 3574 Lines: 110 Hi, So I just got bitten by an unresolved symbols problem. To reproduce: 1) Install the pre-1 RHEL kernel and source, including the omitted kdb directory. 2) Configure the kernel for i686-smp 3) Download the latest 3-ware drivers for the Escalade 8500 series from http://3ware.com/support/download_7.7.0.asp?SNO=246. Note that this hasn't changed since before the last time I successfully compiled these for a kernel. 4) Compile the SMP module, install it in the right place as 3w-xxxx.o, and run depmod -ae. You should get: depmod: *** Unresolved symbols in /lib/modules/2.4.21-9.0.1.EL.sgi1smp/kernel/drivers/scsi/3w-xxxx.o depmod: __udivdi3 which is from libgcc.a, which I understand cannot be linked into the kernel. Can someone reproduce this, or have I done something crazy? If this can be reproduced, how do I fix it? Thanks, Chris. On Sat, 17 Apr 2004, Chris Green wrote: > > > > (or just rpmbuild -bp it, and copy over kdb/) > > I did this, and it looks like we're cookin'. Thanks for the prompt reply > and quick solution. > > Cheers, > Chris. > > > > > looks like the RH9 kernels are ok in this respect. > > > > thanks for finding that! > > > > -Eric > > > > On Fri, 16 Apr 2004, Chris Green wrote: > > > > > Hi, > > > > > > So, I just downloaded the RPMS from the indicated place for RHEL, and > > > installed: > > > > > > # rpm -Uvh --freshen acl-2.2.23-1.i386.rpm attr-2.4.15-1.i386.rpm dmapi-2.1.0-1.i386.rpm dmapi-devel-2.1.0-1.i386.rpm libacl-2.2.23-1.i386.rpm libacl-devel-2.2.23-1.i386.rpm libattr-2.4.15-1.i386.rpm libattr-devel-2.4.15-1.i386.rpm xfsdump-2.2.17-1.i386.rpm xfsprogs-2.6.4-1.i386.rpm xfsprogs-devel-2.6.4-1.i386.rpm > > > # rpm -ivh kernel-2.4.21-9.0.1.EL.sgi1.i686.rpm kernel-unsupported-2.4.21-9.0.1.EL.sgi1.i686.rpm kernel-smp-2.4.21-9.0.1.EL.sgi1.i686.rpm kernel-smp-unsupported-2.4.21-9.0.1.EL.sgi1.i686.rpm xfs-modules-1.3.3-2.4.21_9.0.1.EL.sgi1_sgi1.i686.rpm xfs-modules-smp-1.3.3-2.4.21_9.0.1.EL.sgi1_sgi1.i686.rpm > > > # rpm -Uvh --freshen kernel-doc-2.4.21-9.0.1.EL.sgi1.i386.rpm kernel-source-2.4.21-9.0.1.EL.sgi1.i386.rpm > > > # rpm -Uvh xfs-modules-BOOT-source-1.3.3-2.4.21_9.0.1.EL.sgi1_sgi1.i386.rpm > > > > > > I attempted to configure the kernel so I could build my favorite > > > modules: > > > > > > # cd /usr/src/linux-2.4 > > > # make mrproper >/dev/null 2>&1 > > > # perl -wap -i.bak -e \ > > > 'BEGIN { $is_smp='"$is_smp"'; $smp=$is_smp?"smp":""; } > > > s|^(EXTRAVERSION\s*=\s*.*)custom$|$1$smp|' Makefile >/dev/null 2>&1 > > > # cp configs/kernel-*-`uname -m`-smp.config ./.config > > > # make oldconfig > > > # make dep > > > > > > Everything went swimmingly, until: > > > > > > > > > make[2]: Leaving directory `/usr/src/linux-2.4.21-9.0.1.EL.sgi1/crypto' > > > make -C kdb fastdep > > > make: Entering an unknown directory > > > make: *** kdb: No such file or directory. Stop. > > > make: Leaving an unknown directory > > > make[1]: *** [_sfdep_kdb] Error 2 > > > make[1]: Leaving directory `/usr/src/linux-2.4.21-9.0.1.EL.sgi1' > > > make: *** [dep-files] Error 2 > > > > > > Oops. > > > > > > Indeed, the kdb directory is not as specified, but is in the arch/i386 > > > directory. A problem with the RPM files list, perhaps? > > > > > > Help! > > > > > > Thanks, > > > Chris. > > > > > > -- > > > Chris Green, MiniBooNE / LANL. Email greenc@fnal.gov > > > Tel: (630) 840-2167. Fax: (630) 840-3867 > > > > > > > > > > > > > > > > > -- Chris Green, MiniBooNE / LANL. Email greenc@fnal.gov Tel: (630) 840-2167. Fax: (630) 840-3867 From owner-linux-xfs@oss.sgi.com Wed May 5 14:23:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 May 2004 14:23:16 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i45LNCKO015384 for ; Wed, 5 May 2004 14:23:12 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i45LPFEd027610 for ; Wed, 5 May 2004 14:25:15 -0700 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 i45LN6Ke38032574; Wed, 5 May 2004 16:23:06 -0500 (CDT) 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 i45LN5HO2517198; Wed, 5 May 2004 16:23:06 -0500 (CDT) Subject: Re: xfs 1.3.3 beta 1 stock kernel source configure problems From: Eric Sandeen To: Chris Green Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1083792185.29671.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 05 May 2004 16:23:05 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 3052 X-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: 1024 Lines: 27 On Wed, 2004-05-05 at 15:53, Chris Green wrote: > 3) Download the latest 3-ware drivers for the Escalade 8500 series from > http://3ware.com/support/download_7.7.0.asp?SNO=246. Note that this hasn't > changed since before the last time I successfully compiled these for a > kernel. > > 4) Compile the SMP module, install it in the right place as 3w-xxxx.o, and > run depmod -ae. You should get: > > depmod: *** Unresolved symbols in /lib/modules/2.4.21-9.0.1.EL.sgi1smp/kernel/drivers/scsi/3w-xxxx.o > depmod: __udivdi3 This is thanks to the LBD patch - some symbols are now 64 bits, and something in that driver is now doing a 64-bit divide; take a look at what the LBD patch does to other scsi drivers, you'll probably find it pretty quickly, something like this: - cylinders = disk->capacity / (heads * sectors); + cylinders = (long)disk->capacity / (heads * sectors); -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 May 5 15:05:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 May 2004 15:05:13 -0700 (PDT) Received: from mailgw2.fnal.gov (mailgw2.fnal.gov [131.225.111.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i45M5AKO018503 for ; Wed, 5 May 2004 15:05:11 -0700 Received: from conversion-daemon.mailgw2.fnal.gov by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0HX900L01H0N18@mailgw2.fnal.gov> (original mail from greenc@fnal.gov) for linux-xfs@oss.sgi.com; Wed, 05 May 2004 17:05:10 -0500 (CDT) Received: from maxwell.fnal.gov (maxwell.fnal.gov [131.225.54.225]) by mailgw2.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPS id <0HX90061THCMKB@mailgw2.fnal.gov>; Wed, 05 May 2004 17:05:10 -0500 (CDT) Date: Wed, 05 May 2004 17:05:10 -0500 (CDT) From: Chris Green Subject: Re: xfs 1.3.3 beta 1 stock kernel source configure problems In-reply-to: <1083792185.29671.14.camel@stout.americas.sgi.com> To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-archive-position: 3053 X-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: 382 Lines: 21 > > - cylinders = disk->capacity / (heads * sectors); > + cylinders = (long)disk->capacity / (heads * sectors); Hi, This was exactly the problem. Thank you very much for a prompt solution to something that wasn't actually your problem. Thanks again, Chris. > > -Eric > > -- Chris Green, MiniBooNE / LANL. Email greenc@fnal.gov Tel: (630) 840-2167. Fax: (630) 840-3867 From owner-linux-xfs@oss.sgi.com Wed May 5 18:22:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 May 2004 18:22:17 -0700 (PDT) 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 i461MAKO032215 for ; Wed, 5 May 2004 18:22:11 -0700 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 i461AbT9002097 for ; Wed, 5 May 2004 20:10:38 -0500 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 i461ARAL57486563; Thu, 6 May 2004 11:10:27 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i461APkk61881618; Thu, 6 May 2004 11:10:25 +1000 (EST) Date: Thu, 6 May 2004 11:10:25 +1000 (EST) From: Nathan Scott Message-Id: <200405060110.i461APkk61881618@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 904788 - logprint X-archive-position: 3054 X-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: 671 Lines: 24 Merge logprint dump and copy operations. Date: Wed May 5 18:09:46 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-cmds Inspected by: sandeen@sgi.com Author: overby Merged by: nathans Merged mods: grove2:irix:161922a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:161922a xfsprogs/logprint/log_copy.c - 1.1 xfsprogs/logprint/log_dump.c - 1.1 xfsprogs/doc/CHANGES - 1.146 xfsprogs/man/man8/xfs_logprint.8 - 1.3 xfsprogs/logprint/Makefile - 1.11 xfsprogs/logprint/logprint.c - 1.13 xfsprogs/logprint/logprint.h - 1.11 xfsprogs/libxlog/util.c - 1.10 xfsprogs/include/libxlog.h - 1.12 From owner-linux-xfs@oss.sgi.com Thu May 6 00:23:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 00:24:26 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i467NdKO013695 for ; Thu, 6 May 2004 00:23:39 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i467Pi5X008861 for ; Thu, 6 May 2004 00:25:45 -0700 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 i467NMAL62214339; Thu, 6 May 2004 17:23:22 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i467NLdO55078813; Thu, 6 May 2004 17:23:21 +1000 (EST) Date: Thu, 6 May 2004 17:23:21 +1000 (EST) From: Nathan Scott Message-Id: <200405060723.i467NLdO55078813@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 914126 - mkfs and MD devices X-archive-position: 3055 X-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: 376 Lines: 14 Remove MD clean superblock bit check, on Neil Browns advice. Date: Thu May 6 00:22:23 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-cmds Inspected by: neilb@cse.unsw.edu.au The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:171294a xfsprogs/doc/CHANGES - 1.147 xfsprogs/libdisk/md.c - 1.14 From owner-linux-xfs@oss.sgi.com Thu May 6 09:26:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 09:26:46 -0700 (PDT) Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i46GQhKO020429 for ; Thu, 6 May 2004 09:26:43 -0700 Received: from noodles (adsl-64-160-55-24.dsl.snfc21.pacbell.net [64.160.55.24]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id i46GPPT1009336 for ; Thu, 6 May 2004 09:25:26 -0700 (PDT) Received: from jwb by noodles with local (Exim 3.36 #1 (Debian)) id 1BLlhm-0000PD-00 for ; Thu, 06 May 2004 09:26:38 -0700 Subject: XFS exploding on 2.4.26 out of nowhere From: "Jeffrey W. Baker" To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1083860798.1121.14.camel@noodles> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 06 May 2004 09:26:38 -0700 X-archive-position: 3056 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jwbaker@acm.org Precedence: bulk X-list: linux-xfs Content-Length: 1108 Lines: 20 We've been having tons of trouble with whatever version of XFS is merged into the 2.4 kernel. At first (some months ago, as reported on this list) we believed the XFS code was having trouble recovering hard I/O errors on our SCSI-attached RAID, which is easy to understand. But yesterday, on a 2.4.26 machine with an SATA-attached 4-way RAID-0 stripe set, we got this error from XFS, without any I/O errors at all: xfs_force_shutdown(md(9,0),0x8) called from line 1070 of file xfs_trans.c. Return address = 0xc0295edc xfs_iunlink_remove: xfs_itobp() returned an error 5 on md(9,0). Returning error. Filesystem "md(9,0)": Corruption of in-memory data detected. Shutting down filesystem: md(9,0) Please umount the filesystem, and rectify the problem(s) XFS just decided out of the blue it was hosed. This has been reported on this list a number of times, normally with NFS involved. But this filesystem was not exported with NFS, it was simply running bonnie, memtest.sh, and dd md0 all at once. That's not even a remarkable I/O load, and it was less than 1 hour of this load before failure. -jwb From owner-linux-xfs@oss.sgi.com Thu May 6 10:17:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 10:17:50 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i46HHSKO022223 for ; Thu, 6 May 2004 10:17:28 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i46HJcX7011450 for ; Thu, 6 May 2004 10:19:38 -0700 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 i46HHMKe37993134; Thu, 6 May 2004 12:17:22 -0500 (CDT) 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 i46HHMHO3210162; Thu, 6 May 2004 12:17:22 -0500 (CDT) Subject: Re: XFS exploding on 2.4.26 out of nowhere From: Eric Sandeen To: "Jeffrey W. Baker" Cc: linux-xfs@oss.sgi.com In-Reply-To: <1083860798.1121.14.camel@noodles> References: <1083860798.1121.14.camel@noodles> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1083863841.436.16.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 06 May 2004 12:17:21 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 3057 X-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: 775 Lines: 18 On Thu, 2004-05-06 at 11:26, Jeffrey W. Baker wrote: > XFS just decided out of the blue it was hosed. This has been reported > on this list a number of times, normally with NFS involved. But this > filesystem was not exported with NFS, it was simply running bonnie, > memtest.sh, and dd md0 all at once. That's not even a remarkable I/O > load, and it was less than 1 hour of this load before failure. are you dd'ing from the same device you're running bonnie on? Accessing the underlying device for a mounted filesystem (yes, even just reading) is known to cause corruptions on the mounted filesystem. Christoph has been looking into this... -- 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 May 6 12:06:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 12:06:49 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i46J6cKO025201 for ; Thu, 6 May 2004 12:06:38 -0700 Received: from hpti9.fsl.noaa.gov ([137.75.132.229]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Thu, 6 May 2004 15:06:37 -0400 Subject: Re: Questions about pagebuf code From: Craig Tierney To: Russell Cattelan , linux-xfs@oss.sgi.com In-Reply-To: <1083614597.24397.16.camel@naboo.americas.sgi.com> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> <1083446482.2302.22.camel@localhost.localdomain> <1083614597.24397.16.camel@naboo.americas.sgi.com> Content-Type: text/plain Message-Id: <1083870335.2376.10.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 06 May 2004 13:05:35 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 May 2004 19:06:37.0577 (UTC) FILETIME=[418BA790:01C4339D] X-archive-position: 3058 X-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: 1502 Lines: 38 > I've mostly ruled out the problem being per-page since as the test in > 198 shows the corruption is the size of give write. In the case of > doublewrite 16k. > > What appears to be happening as the file is grown out of order in > relation to the writes that are happening every once in a while a 16k > write is simply forgotten about. > > In other words write 16k at 16k then write 16k at 0k. > So grow to 32k starting at 16k then go back and fill in > the 0-16k block and sometimes the 0-16k block is simply not written > to disk. > > I'm going to keep looking at this i_sem not locked theory a bit longer > before I give up on yet another theory. > > If you have any observations theory let me know it might be helpful. It appears my corruption pattern is different (but not unrelated). I finally confirmed that when a file is corrupted, it is corrupted with data occurring from another write. For example, Temperature gets overwritten when height, or velocity is overwritten with humidity. Unless there is something really wrong in caching, the corruption must becoming from another client process. In one case, process 3 showed corruption in file 8. The corruption in file 8 matches data from file 14 (files are written in order). Processes are all started at the same time, but they do get out of sync because of IO and other load issues. It seems like buffers are overwritten, or if the IO is async that a buffer is being used before it is actually no longer in use. Craig From owner-linux-xfs@oss.sgi.com Thu May 6 12:36:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 12:36:43 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i46JafKO029155 for ; Thu, 6 May 2004 12:36:41 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i46JafdP029152 for linux-xfs@oss.sgi.com; Thu, 6 May 2004 12:36:41 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i46JabKc029116 for ; Thu, 6 May 2004 12:36:39 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i46IbEha024730; Thu, 6 May 2004 11:37:14 -0700 Date: Thu, 6 May 2004 11:37:14 -0700 Message-Id: <200405061837.i46IbEha024730@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: 3059 X-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: 710 Lines: 27 http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 derry@jungo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |derry@jungo.com ------- Additional Comments From derry@jungo.com 2004-06-05 11:37 PDT ------- This happened also to me. The system is a dual Xeon PC, with a raid1 (/dev/md0) 20GB in size. I needed to do xfs_repair, and only then I could remount the XFS filesystem. There were no errors in the hard drives or the MD device. ------- 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 May 6 12:36:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 12:36:51 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i46JafKO029154 for ; Thu, 6 May 2004 12:36:41 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i46JafFu029153 for linux-xfs@oss.sgi.com; Thu, 6 May 2004 12:36:41 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i46JabKU029116 for ; Thu, 6 May 2004 12:36:38 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i46Icfm6024756; Thu, 6 May 2004 11:38:41 -0700 Date: Thu, 6 May 2004 11:38:41 -0700 Message-Id: <200405061838.i46Icfm6024756@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: 3060 X-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=274 ------- Additional Comments From derry@jungo.com 2004-06-05 11:38 PDT ------- .. Forgot to mention: Kernel is 2.4.22 with XFS patch (1.3) ------- 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 May 6 12:49:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 12:49:08 -0700 (PDT) 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 i46Jn1KO030247 for ; Thu, 6 May 2004 12:49:01 -0700 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 i46Jmthv024584 for ; Thu, 6 May 2004 12:48:56 -0700 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.10/SGI_generic_relay-1.2) with ESMTP id i46JmtKe38019447; Thu, 6 May 2004 14:48:55 -0500 (CDT) Received: from [128.162.233.73] (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i46JmtXa6588847; Thu, 6 May 2004 14:48:55 -0500 (CDT) Subject: Re: Questions about pagebuf code From: Russell Cattelan To: Craig Tierney Cc: linux-xfs@oss.sgi.com In-Reply-To: <1083870335.2376.10.camel@hpti9.fsl.noaa.gov> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> <1083446482.2302.22.camel@localhost.localdomain> <1083614597.24397.16.camel@naboo.americas.sgi.com> <1083870335.2376.10.camel@hpti9.fsl.noaa.gov> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-td1qjxNUc8I924cD075l" Message-Id: <1083872935.28589.27.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.5.7-2mdk Date: Thu, 06 May 2004 14:48:55 -0500 X-archive-position: 3061 X-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: 3241 Lines: 84 --=-td1qjxNUc8I924cD075l Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-05-06 at 13:05 -0600, Craig Tierney wrote: > > I've mostly ruled out the problem being per-page since as the test in > > 198 shows the corruption is the size of give write. In the case of > > doublewrite 16k. > >=20 > > What appears to be happening as the file is grown out of order in > > relation to the writes that are happening every once in a while a 16k > > write is simply forgotten about. > >=20 > > In other words write 16k at 16k then write 16k at 0k. > > So grow to 32k starting at 16k then go back and fill in > > the 0-16k block and sometimes the 0-16k block is simply not written > > to disk. > >=20 > > I'm going to keep looking at this i_sem not locked theory a bit longer= =20 > > before I give up on yet another theory. > >=20 > > If you have any observations theory let me know it might be helpful. >=20 > It appears my corruption pattern is different (but not unrelated). > I finally confirmed that when a file is corrupted, it is corrupted > with data occurring from another write. For example, Temperature gets > overwritten when height, or velocity is overwritten with humidity. The problem is trying to figure out if the data is stale or really from a different process. If the data block was previously used and then freed either by removing the old file or truncating it and then the new file reallocates that free block into its file but never writes to that block, the data is stale. Now if you pattern up a partition with zeros or some known pattern, make a file system run your test with no removes or truncates and you still see data from another client, that is not a stale data problem. That would indicate a page management problem, (usually a locking problem) the size of corruption is usually limited to a page size in those cases.=20 If I remember right you were seeing problems or 1 or more pages in length? I wish I had something for you to try, my latest go around on this bug is not looking promising. I thought it might have something to do with i_sem not being held=20 for writes, but I'm still seeing the problem even with the i_sem. I need to put an assert in generic_file_write just to make sure i_sem is being coming in locked. >=20 > Unless there is something really wrong in caching, the corruption > must becoming from another client process. In one case, process > 3 showed corruption in file 8. The corruption in file 8 matches > data from file 14 (files are written in order). Processes > are all started at the same time, but they do get out of sync > because of IO and other load issues.=20=20 >=20 > It seems like buffers are overwritten, or if the IO is async > that a buffer is being used before it is actually no longer in > use.=20 >=20 > Craig >=20 >=20 --=20 Russell Cattelan --=-td1qjxNUc8I924cD075l 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) iD4DBQBAmpanNRmM+OaGhBgRApH/AJ9nm0d8H6G3AgMKlc7nbzd44LbnSgCY/8Yn Vzmv70TFWj8W2iY9/spxDQ== =uFwA -----END PGP SIGNATURE----- --=-td1qjxNUc8I924cD075l-- From owner-linux-xfs@oss.sgi.com Thu May 6 12:59:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 12:59:10 -0700 (PDT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i46JwwKO030810 for ; Thu, 6 May 2004 12:58:58 -0700 Received: from lns-th2-4f-81-56-250-144.adsl.proxad.net (lns-th2-4f-81-56-250-144.adsl.proxad.net [81.56.250.144]) by postfix4-1.free.fr (Postfix) with ESMTP id DCEC5106B01; Thu, 6 May 2004 21:20:55 +0200 (CEST) From: Johann Lombardi Reply-To: johann.lombardi@free.fr To: Eric Sandeen Subject: Re: Unsupported sector size Date: Thu, 6 May 2004 21:27:02 +0200 User-Agent: KMail/1.5.4 References: In-Reply-To: Cc: Nathan Scott , MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405062127.02535.johann.lombardi@free.fr> X-archive-position: 3062 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: johann.lombardi@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 3163 Lines: 173 > the last ag can be smaller, so no, not quite equal. > the test you're failing is whether dblocks > agcount * agblocks. > > 6553600 is a very.... interesting number for dblocks, strikes me > as too round. :) > > i forget, have you tried repair on this filesystem? > you can use the -n switch to do a dry run first. # xfs_repair /dev/sdc Phase 1 - find and verify superblock... bad primary superblock - inconsistent filesystem geometry information !!! .... attempting to find secondary superblock... ... Then, xfs_repair always prints the same message followed by several dots: found candidate secondary superblock... error reading superblock 26 -- seek to offset 111669149696 failed unable to verify superblock, continuing... > what do the other superblocks have to say - try "sb 25" instead > of sb 0, etc. > > have you run growfs on this filesystem? looks to me like No > maybe some sb corruption - you might also do just > "sb 0" and "p" to print all fields. Here is the results for sb 0, 25 and 26: ******** * sb 0 * ******** magicnum = 0x58465342 blocksize = 16384 dblocks = 6553600 rblocks = 0 rextents = 0 uuid = 1500cda4-08c9-4e61-8d65-33f13f974a77 logstart = 3407876 rootino = 512 rbmino = 513 rsumino = 514 rextsize = 4 agblocks = 262144 agcount = 26 rbmblocks = 0 logblocks = 1000 versionnum = 0x2004 sectsize = 512 inodesize = 256 inopblock = 64 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 14 sectlog = 9 inodelog = 8 inopblog = 6 agblklog = 18 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 64 ifree = 61 fdblocks = 6552495 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 0 unit = 0 width = 0 dirblklog = 0 xfs_db: sb 25 xfs_db: p magicnum = 0x58465342 blocksize = 16384 dblocks = 6553600 rblocks = 0 rextents = 0 uuid = 1500cda4-08c9-4e61-8d65-33f13f974a77 logstart = 3407876 rootino = 512 rbmino = null rsumino = null rextsize = 4 agblocks = 262144 agcount = 26 rbmblocks = 0 logblocks = 1000 versionnum = 0x2004 sectsize = 512 inodesize = 256 inopblock = 64 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 14 sectlog = 9 inodelog = 8 inopblog = 6 agblklog = 18 rextslog = 0 inprogress = 1 imax_pct = 25 icount = 0 ifree = 0 fdblocks = 6552496 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 0 unit = 0 width = 0 dirblklog = 0 ******** * sb 25 * ******** magicnum = 0x58465342 blocksize = 16384 dblocks = 6553600 rblocks = 0 rextents = 0 uuid = cdb99a26-ca18-4434-83e6-aaf4702fec66 logstart = 3407876 rootino = 512 rbmino = null rsumino = null rextsize = 4 agblocks = 262144 agcount = 26 rbmblocks = 0 logblocks = 1000 versionnum = 0x2004 sectsize = 512 inodesize = 256 inopblock = 64 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 14 sectlog = 9 inodelog = 8 inopblog = 6 agblklog = 18 rextslog = 0 inprogress = 1 imax_pct = 25 icount = 0 ifree = 0 fdblocks = 6552496 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 0 unit = 0 width = 0 dirblklog = 0 ******** * sb 26 * ******** bad allocation group number 26 Thanks for your help, Johann From owner-linux-xfs@oss.sgi.com Thu May 6 13:18:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 13:19:02 -0700 (PDT) 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 i46KItKO031577 for ; Thu, 6 May 2004 13:18:55 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i46KInhv027127 for ; Thu, 6 May 2004 13:18:49 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i46KL4E5004807 for ; Thu, 6 May 2004 13:21:05 -0700 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 GAA18180; Fri, 7 May 2004 06:18:40 +1000 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 i46KIaln230355; Fri, 7 May 2004 06:18:36 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i46KIYHo230455; Fri, 7 May 2004 06:18:34 +1000 (EST) Date: Fri, 7 May 2004 06:18:34 +1000 From: Nathan Scott To: "Jeffrey W. Baker" Cc: linux-xfs@oss.sgi.com Subject: Re: XFS exploding on 2.4.26 out of nowhere Message-ID: <20040507061834.B229613@wobbly.melbourne.sgi.com> References: <1083860798.1121.14.camel@noodles> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1083860798.1121.14.camel@noodles>; from jwbaker@acm.org on Thu, May 06, 2004 at 09:26:38AM -0700 X-archive-position: 3063 X-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: 1420 Lines: 31 On Thu, May 06, 2004 at 09:26:38AM -0700, Jeffrey W. Baker wrote: > We've been having tons of trouble with whatever version of XFS is merged > into the 2.4 kernel. At first (some months ago, as reported on this > list) we believed the XFS code was having trouble recovering hard I/O > errors on our SCSI-attached RAID, which is easy to understand. But > yesterday, on a 2.4.26 machine with an SATA-attached 4-way RAID-0 stripe > set, we got this error from XFS, without any I/O errors at all: > > xfs_force_shutdown(md(9,0),0x8) called from line 1070 of file xfs_trans.c. Return address = 0xc0295edc > xfs_iunlink_remove: xfs_itobp() returned an error 5 on md(9,0). Returning error. errno 5 is EIO - this could be coming from either XFS or it could be percolating up from MD. > Filesystem "md(9,0)": Corruption of in-memory data detected. Shutting down filesystem: md(9,0) > Please umount the filesystem, and rectify the problem(s) > > XFS just decided out of the blue it was hosed. This has been reported > on this list a number of times, normally with NFS involved. But this > filesystem was not exported with NFS, it was simply running bonnie, > memtest.sh, and dd md0 all at once. That's not even a remarkable I/O > load, and it was less than 1 hour of this load before failure. yeah, what Eric said - are you reading the raw device while reading/writing to the filesystem? why? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu May 6 13:21:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 13:21:45 -0700 (PDT) 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 i46KLfKO032001 for ; Thu, 6 May 2004 13:21:41 -0700 Received: from noodles (adsl-64-160-55-24.dsl.snfc21.pacbell.net [64.160.55.24]) by mta7.pltn13.pbi.net (8.12.10/8.12.10) with ESMTP id i46KLeVW023916; Thu, 6 May 2004 13:21:40 -0700 (PDT) Received: from jwb by noodles with local (Exim 3.36 #1 (Debian)) id 1BLpNA-0000ge-00; Thu, 06 May 2004 13:21:36 -0700 Subject: Re: XFS exploding on 2.4.26 out of nowhere From: "Jeffrey W. Baker" To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040507061834.B229613@wobbly.melbourne.sgi.com> References: <1083860798.1121.14.camel@noodles> <20040507061834.B229613@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1083874895.2621.0.camel@noodles> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 06 May 2004 13:21:35 -0700 X-archive-position: 3064 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jwbaker@acm.org Precedence: bulk X-list: linux-xfs Content-Length: 1575 Lines: 33 On Thu, 2004-05-06 at 13:18, Nathan Scott wrote: > On Thu, May 06, 2004 at 09:26:38AM -0700, Jeffrey W. Baker wrote: > > We've been having tons of trouble with whatever version of XFS is merged > > into the 2.4 kernel. At first (some months ago, as reported on this > > list) we believed the XFS code was having trouble recovering hard I/O > > errors on our SCSI-attached RAID, which is easy to understand. But > > yesterday, on a 2.4.26 machine with an SATA-attached 4-way RAID-0 stripe > > set, we got this error from XFS, without any I/O errors at all: > > > > xfs_force_shutdown(md(9,0),0x8) called from line 1070 of file xfs_trans.c. Return address = 0xc0295edc > > xfs_iunlink_remove: xfs_itobp() returned an error 5 on md(9,0). Returning error. > > errno 5 is EIO - this could be coming from either XFS or it > could be percolating up from MD. Could be, but md logged nothing. > > Filesystem "md(9,0)": Corruption of in-memory data detected. Shutting down filesystem: md(9,0) > > Please umount the filesystem, and rectify the problem(s) > > > > XFS just decided out of the blue it was hosed. This has been reported > > on this list a number of times, normally with NFS involved. But this > > filesystem was not exported with NFS, it was simply running bonnie, > > memtest.sh, and dd md0 all at once. That's not even a remarkable I/O > > load, and it was less than 1 hour of this load before failure. > > yeah, what Eric said - are you reading the raw device while > reading/writing to the filesystem? why? Yes, and just to exercise the device. -jwb From owner-linux-xfs@oss.sgi.com Thu May 6 13:40:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 13:40:51 -0700 (PDT) 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 i46KejKO003562 for ; Thu, 6 May 2004 13:40:46 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BLpfe-0005nJ-Or; Thu, 06 May 2004 21:40:42 +0100 Date: Thu, 6 May 2004 21:40:42 +0100 From: Christoph Hellwig To: "Jeffrey W. Baker" Cc: linux-xfs@oss.sgi.com Subject: Re: XFS exploding on 2.4.26 out of nowhere Message-ID: <20040506214042.A22254@infradead.org> References: <1083860798.1121.14.camel@noodles> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1083860798.1121.14.camel@noodles>; from jwbaker@acm.org on Thu, May 06, 2004 at 09:26:38AM -0700 X-archive-position: 3065 X-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: 671 Lines: 15 On Thu, May 06, 2004 at 09:26:38AM -0700, Jeffrey W. Baker wrote: > XFS just decided out of the blue it was hosed. This has been reported > on this list a number of times, normally with NFS involved. But this > filesystem was not exported with NFS, it was simply running bonnie, > memtest.sh, and dd md0 all at once. Don't touch the underlying device if XFS is active. This is know to cause data corruption. I have an experimental fix for 2.6 here, I just need to get rid of a occasional deadlock in there that I'm hitting. While it's conceptually backportable to 2.4 I doubt marcelo will take it. Nathan, Eric: any good idea how to prominently warn about this? From owner-linux-xfs@oss.sgi.com Thu May 6 16:41:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 16:41:53 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i46NfbKO009629 for ; Thu, 6 May 2004 16:41:37 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i46Nhm3V001770 for ; Thu, 6 May 2004 16:43:49 -0700 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 JAA21861; Fri, 7 May 2004 09:41:21 +1000 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 i46NfKln205674; Fri, 7 May 2004 09:41:20 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i46NfEWj234750; Fri, 7 May 2004 09:41:14 +1000 (EST) Date: Fri, 7 May 2004 09:41:13 +1000 From: Nathan Scott To: Christoph Hellwig Cc: "Jeffrey W. Baker" , linux-xfs@oss.sgi.com Subject: Re: XFS exploding on 2.4.26 out of nowhere Message-ID: <20040507094113.C207825@wobbly.melbourne.sgi.com> References: <1083860798.1121.14.camel@noodles> <20040506214042.A22254@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040506214042.A22254@infradead.org>; from hch@infradead.org on Thu, May 06, 2004 at 09:40:42PM +0100 X-archive-position: 3066 X-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: 1435 Lines: 34 On Thu, May 06, 2004 at 09:40:42PM +0100, Christoph Hellwig wrote: > On Thu, May 06, 2004 at 09:26:38AM -0700, Jeffrey W. Baker wrote: > > XFS just decided out of the blue it was hosed. This has been reported > > on this list a number of times, normally with NFS involved. But this > > filesystem was not exported with NFS, it was simply running bonnie, > > memtest.sh, and dd md0 all at once. > > Don't touch the underlying device if XFS is active. This is know to > cause data corruption. I have an experimental fix for 2.6 here, I just > need to get rid of a occasional deadlock in there that I'm hitting. > > While it's conceptually backportable to 2.4 I doubt marcelo will take > it. > > Nathan, Eric: any good idea how to prominently warn about this? Not really, its a tough one. It really needs to be in the kernel to be effective ... would it have to be a complete 2.6 backport, or could there be some simplified infrastructure we could use? Maybe just something setting a flag when we claim the device(s) (while holding bd_sem), and preventing blkdev opens on those in the block_dev.c::do_open (and vice-versa, of course, preventing a mount on an already open device). There does seem to be some infrastructure we might use (bd_sem/bd_openers)? Probably we should claim the device excl in 2.6 too until its sorted out too (but if the fix is close at hand, better to focus on that I geuss). thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu May 6 19:37:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 19:37:17 -0700 (PDT) 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 i472bAKO013393 for ; Thu, 6 May 2004 19:37:13 -0700 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 i472SOT9016084 for ; Thu, 6 May 2004 21:28:25 -0500 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 MAA24752; Fri, 7 May 2004 12:28:19 +1000 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 i472SIln238211; Fri, 7 May 2004 12:28:18 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i472SFUR237732; Fri, 7 May 2004 12:28:15 +1000 (EST) Date: Fri, 7 May 2004 12:28:15 +1000 From: Nathan Scott To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com Subject: Re: XFS exploding on 2.4.26 out of nowhere Message-ID: <20040507122815.A237809@wobbly.melbourne.sgi.com> References: <1083860798.1121.14.camel@noodles> <20040506214042.A22254@infradead.org> <20040507094113.C207825@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040507094113.C207825@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Fri, May 07, 2004 at 09:41:13AM +1000 X-archive-position: 3067 X-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: 509 Lines: 17 On Fri, May 07, 2004 at 09:41:13AM +1000, Nathan Scott wrote: > On Thu, May 06, 2004 at 09:40:42PM +0100, Christoph Hellwig wrote: > > > > Nathan, Eric: any good idea how to prominently warn about this? > > Not really, its a tough one. It really needs to be in the kernel > to be effective ... would it have to be a complete 2.6 backport, > or could there be some simplified infrastructure we could use? Ugh, looked, too much change required, there's no good solution here afaict. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu May 6 20:42:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 May 2004 20:42:56 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i473grKO018016 for ; Thu, 6 May 2004 20:42:53 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i473j5XN003860 for ; Thu, 6 May 2004 20:45:07 -0700 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 NAA26090; Fri, 7 May 2004 13:42:37 +1000 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 i473galn238881; Fri, 7 May 2004 13:42:36 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i473gUb6239539; Fri, 7 May 2004 13:42:30 +1000 (EST) Date: Fri, 7 May 2004 13:42:30 +1000 From: Nathan Scott To: Johann Lombardi Cc: linux-xfs@oss.sgi.com Subject: Re: Unsupported sector size Message-ID: <20040507134230.C237809@wobbly.melbourne.sgi.com> References: <200405062127.02535.johann.lombardi@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200405062127.02535.johann.lombardi@free.fr>; from johann.lombardi@free.fr on Thu, May 06, 2004 at 09:27:02PM +0200 X-archive-position: 3068 X-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: 1353 Lines: 49 On Thu, May 06, 2004 at 09:27:02PM +0200, Johann Lombardi wrote: > > the last ag can be smaller, so no, not quite equal. > > the test you're failing is whether dblocks > agcount * agblocks. I think you're actually failing the third check of the three... if (unlikely( sbp->sb_dblocks == 0 || sbp->sb_dblocks > (xfs_drfsbno_t)sbp->sb_agcount * sbp->sb_agblocks || sbp->sb_dblocks < (xfs_drfsbno_t)(sbp->sb_agcount - 1) * sbp->sb_agblocks + XFS_MIN_AG_BLOCKS)) { > > 6553600 is a very.... interesting number for dblocks, strikes me > > as too round. :) > > No, I think this is OK. > * sb 0 * > ******** > magicnum = 0x58465342 > blocksize = 16384 > dblocks = 6553600 16k blocksize? What type of machine have you got there? (i.e. do you know what the kernels pagesize is? - you cannot use a blocksize larger than your pagesize on Linux). > agblocks = 262144 > agcount = 26 OK, this is busted. It looks like quite an old mkfs bug, but my memorys cloudy going back so far - I suspect this is a bug that was fixed early-2002: xfsprogs-2.0.6 (30 May 2002) - ... - Fix the way mkfs.xfs round downs the device when the last AG is smaller than the minimum AG size. - ... What does mkfs.xfs -V say for you? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri May 7 09:55:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 May 2004 09:55:56 -0700 (PDT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i47GtgKO015426 for ; Fri, 7 May 2004 09:55:42 -0700 Received: from lns-th2-4f-81-56-250-144.adsl.proxad.net (lns-th2-4f-81-56-250-144.adsl.proxad.net [81.56.250.144]) by postfix4-2.free.fr (Postfix) with ESMTP id EC0A59F0DF; Fri, 7 May 2004 18:11:34 +0200 (CEST) From: Johann Lombardi Reply-To: johann.lombardi@free.fr To: Nathan Scott Subject: Re: Unsupported sector size Date: Fri, 7 May 2004 18:17:44 +0200 User-Agent: KMail/1.5.4 Cc: linux-xfs@oss.sgi.com References: <200405062127.02535.johann.lombardi@free.fr> <20040507134230.C237809@wobbly.melbourne.sgi.com> In-Reply-To: <20040507134230.C237809@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405071817.44623.johann.lombardi@free.fr> X-archive-position: 3069 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: johann.lombardi@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 813 Lines: 23 > 16k blocksize? What type of machine have you got there? (i.e. > do you know what the kernels pagesize is? - you cannot use a > blocksize larger than your pagesize on Linux). IA64 smp and the pagesize is 16k. > OK, this is busted. It looks like quite an old mkfs bug, but > my memorys cloudy going back so far - I suspect this is a bug > that was fixed early-2002: > > xfsprogs-2.0.6 (30 May 2002) > - ... > - Fix the way mkfs.xfs round downs the device when the last > AG is smaller than the minimum AG size. > - ... > > What does mkfs.xfs -V say for you? OK, you are right. My xfsprog are really old (2.0.3). I have finally decided to upgrade this package (for 2.5.6) and it solves the problem. I didn't know that my xfsprogs was so old. Thanks for your help. Johann From owner-linux-xfs@oss.sgi.com Fri May 7 14:04:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 May 2004 14:04:04 -0700 (PDT) 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 i47L3xKO003604 for ; Fri, 7 May 2004 14:04:00 -0700 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 i47L3shv028896 for ; Fri, 7 May 2004 14:03:54 -0700 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.10/SGI_generic_relay-1.2) with ESMTP id i47L3rKe38055168 for ; Fri, 7 May 2004 16:03:53 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i47L3qXa3265384; Fri, 7 May 2004 16:03:52 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id i47L3E8D023606; Fri, 7 May 2004 16:03:15 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id i47L3EZA023604; Fri, 7 May 2004 16:03:14 -0500 Date: Fri, 7 May 2004 16:03:14 -0500 From: Eric Sandeen Message-Id: <200405072103.i47L3EZA023604@penguin.americas.sgi.com> Subject: TAKE 914236 - X-archive-position: 3070 X-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@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 398 Lines: 15 Fix modular xfs build with tracing enabled - set proper defines so that xfs_ksyms exports symbols xfsidbg needs Date: Fri May 7 14:03:36 PDT 2004 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-iodone Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:171409a linux-2.4/Makefile - 1.203 From owner-linux-xfs@oss.sgi.com Fri May 7 19:43:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 May 2004 19:44:06 -0700 (PDT) Received: from lists.vasoftware.com (mail@internalmx2.vasoftware.com [12.152.184.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i482hxKO016238 for ; Fri, 7 May 2004 19:43:59 -0700 Received: from adsl-64-175-249-150.dsl.sntc01.pacbell.net ([64.175.249.150]:61955 helo=linux-sxs.org) by lists.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.20 #1 (Debian)) id 1BMHoj-0001uR-NH by VAauthid with fixed_plain for ; Fri, 07 May 2004 19:43:57 -0700 Message-ID: <409C4965.3060802@linux-sxs.org> Date: Fri, 07 May 2004 19:43:49 -0700 From: "L. Friedman" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: RHES-3.0 compatible kernels? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: lists.vasoftware.com 1BMHoj-0001uR-NH 232dec81051548165f8819f13535deda X-archive-position: 3071 X-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: 934 Lines: 26 Greetings, I've just acquired a slew of RHES-3.0 boxes that are running a pesky java application that won't run well unless it has NPTL support. So that basically rules out (AFAIK) using a vanilla kernel. I've managed to convert the filesystem over to XFS on them. WHat i'm wondering is are there any recent RHES-3.0 compatible kernels with XFS support out there? I found this: ftp://oss.sgi.com/projects/xfs/testing/release-1.3.3-pre1/ but after reading some old list threads, there were some questions over whether the RPMs were built correctly. Are they safe to use? Is anyone else maintaining kernel RPMs that work well in RHES-3.0? thanks! -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 19:40:01 up 152 days, 23:11, 1 user, load average: 0.23, 0.24, 0.18 From owner-linux-xfs@oss.sgi.com Fri May 7 21:34:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 May 2004 21:34:15 -0700 (PDT) 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 i484YCKO021523 for ; Fri, 7 May 2004 21:34:12 -0700 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 i484Y7hv000513 for ; Fri, 7 May 2004 21:34:07 -0700 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 i484Y6Ke38032317; Fri, 7 May 2004 23:34:06 -0500 (CDT) 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 i484Y6HP3463464; Fri, 7 May 2004 23:34:06 -0500 (CDT) Date: Fri, 7 May 2004 23:34:06 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "L. Friedman" cc: linux-xfs@oss.sgi.com Subject: Re: RHES-3.0 compatible kernels? In-Reply-To: <409C4965.3060802@linux-sxs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3072 X-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: 1345 Lines: 41 they should be fine; the source rpm is missing the kdb/ dir so won't recompile with kdb turned on... i have updated pkgs w/ the latest errata kernel and a minor xfs fix, I'll try to get them out soon. In the meantime though please do grab the -pre1 packages, I'd appreciate any testing you can give them. -Eric On Fri, 7 May 2004, L. Friedman wrote: > Greetings, > I've just acquired a slew of RHES-3.0 boxes that are running a pesky > java application that won't run well unless it has NPTL support. So > that basically rules out (AFAIK) using a vanilla kernel. > > I've managed to convert the filesystem over to XFS on them. WHat i'm > wondering is are there any recent RHES-3.0 compatible kernels with XFS > support out there? > > I found this: > ftp://oss.sgi.com/projects/xfs/testing/release-1.3.3-pre1/ > > but after reading some old list threads, there were some questions over > whether the RPMs were built correctly. Are they safe to use? > > Is anyone else maintaining kernel RPMs that work well in RHES-3.0? > > thanks! > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > L. Friedman netllama@linux-sxs.org > Linux Step-by-step & TyGeMo: http://netllama.ipfox.com > > 19:40:01 up 152 days, 23:11, 1 user, load average: 0.23, 0.24, 0.18 > > From owner-linux-xfs@oss.sgi.com Sat May 8 05:31:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 May 2004 05:32:01 -0700 (PDT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i48CVmKO007833 for ; Sat, 8 May 2004 05:31:49 -0700 Received: from free.fr (lyon-3-62-147-49-94.dial.proxad.net [62.147.49.94]) by postfix3-2.free.fr (Postfix) with ESMTP id 93C7EC161 for ; Sat, 8 May 2004 13:58:56 +0200 (CEST) Message-ID: <409CCB74.8060002@free.fr> Date: Sat, 08 May 2004 13:58:44 +0200 From: Xavier Reply-To: x.poirier@free.fr User-Agent: Mozilla/5.0 (Windows; U; Win95; fr-FR; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS and mount /home quota problem mandrake 9.2 X-Enigmail-Version: 0.82.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3073 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: x.poirier@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 1166 Lines: 36 Hi all, I'm new here on this ML. I have tryed many things before comming and post a message here. Here it is: I have two Mandrake 9.2 servers installed both with a XFS /home partition. The first server (SERVER A) : a DELL Poweredge 2600 with RAID PERC4DI have quota enabled onto /home for a user.At first this quota wath not enabled, I had to pass many command line with quotaon or quotacheck etc..., modify /etc/fstab , doing a reboot.Finally quota works now onto this server, but don't now how I have done to enable this ! cause at first I thought that simply mounting an XFS filesystem with correct options (usrquota,grpquota) was sufficient but quotas was not working at first. The second server (SERVER B) : a DELL 1750 with RAID PERC4DI have quota enable at mount of /home (usrquota,grpquota) But it doesn' t WORK !! The user in witch I put a quota limit can copy a file onto the /home filesystem and filesystem reach 100% , nothing happen ! So, please, mans with good feeling with XFS partitions, Tell me if I am mad or not ? Is there a problem with XFS partitions and Mandrake 9.2 or DELL RAID systems, I m not sure now ? Thanks Xavier From owner-linux-xfs@oss.sgi.com Sat May 8 14:36:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 08 May 2004 14:36:54 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i48LapKO025493 for ; Sat, 8 May 2004 14:36:51 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i48LapSp025492 for linux-xfs@oss.sgi.com; Sat, 8 May 2004 14:36:51 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i48LanKQ025478 for ; Sat, 8 May 2004 14:36:49 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i48Kuk0u024593; Sat, 8 May 2004 13:56:46 -0700 Date: Sat, 8 May 2004 13:56:46 -0700 Message-Id: <200405082056.i48Kuk0u024593@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 328] New: freeze on XFS recovery on sparc64 with linux kernel 2.4.26 X-Bugzilla-Reason: AssignedTo X-archive-position: 3074 X-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: 1204 Lines: 42 http://oss.sgi.com/bugzilla/show_bug.cgi?id=328 Summary: freeze on XFS recovery on sparc64 with linux kernel 2.4.26 Product: Linux XFS Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: major Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: nboullis@debian.org Hi, On sparc64, I tried several versions of the XFS patch for 2.4 kernels, up to the version currently in the 2.4.26 kernel. All of them fail when a recovery is attempted, first by freezing and sometimes by oopsing. It is so badly broken that even the openboot hotkey (STOP-A) does not work. I just rebuilt my kernel and xfs module with DEBUG. And now, at recovery time, I get an assertion failure: XFS assertion failed: item->ri_buf[i].i_len % XFS_BLI_CHUNK == 0, file: xfs_log_recover.c, line: 1955 (I never experienced such a problem on i386.) Is there something I can do to help track this bug? Regards, Nicolas ------- 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 May 9 14:07:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 May 2004 14:07:33 -0700 (PDT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i49L79KO016963 for ; Sun, 9 May 2004 14:07:29 -0700 Received: from taniwha.stupidest.org (adsl-63-205-184-25.dsl.snfc21.pacbell.net [63.205.184.25]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i49L77RG119518; Sun, 9 May 2004 17:07:07 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 4E49014B90; Sun, 9 May 2004 14:07:06 -0700 (PDT) Date: Sun, 9 May 2004 14:07:06 -0700 From: Chris Wedgwood To: Xavier Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and mount /home quota problem mandrake 9.2 Message-ID: <20040509210706.GA15371@taniwha.stupidest.org> References: <409CCB74.8060002@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <409CCB74.8060002@free.fr> X-archive-position: 3075 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 916 Lines: 30 On Sat, May 08, 2004 at 01:58:44PM +0200, Xavier wrote: > At first this quota wath not enabled, I had to pass many command > line with quotaon or quotacheck etc..., modify /etc/fstab , doing a > reboot. mount -t xfs -o quota /dev/foo /mnt/bar sort of thing should be all that's required. Editing /etc/fstab means putting in usrquota and/or grpquota to mount-options column. > The second server (SERVER B) : a DELL 1750 with RAID PERC4DI have > quota enable at mount of /home (usrquota,grpquota) what does /proc/filesystems say? > The user in witch I put a quota limit can copy a file onto the /home > filesystem and filesystem reach 100% , nothing happen ! and 'quota' for that user says? > Is there a problem with XFS partitions and Mandrake 9.2 or DELL RAID > systems, I m not sure now ? The RAID shouldn't matter, I don't know what Mandrake does for their kernels but I assume this will work. --cw From owner-linux-xfs@oss.sgi.com Sun May 9 17:07:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 May 2004 17:07:16 -0700 (PDT) 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 i4A07CKO023305 for ; Sun, 9 May 2004 17:07:12 -0700 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 i49NxOT9020051 for ; Sun, 9 May 2004 18:59:25 -0500 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 JAA26758; Mon, 10 May 2004 09:59:19 +1000 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 i49NxFln328784; Mon, 10 May 2004 09:59:16 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i49NxCxF328307; Mon, 10 May 2004 09:59:12 +1000 (EST) Date: Mon, 10 May 2004 09:59:12 +1000 From: Nathan Scott To: Xavier , Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and mount /home quota problem mandrake 9.2 Message-ID: <20040510095912.A327358@wobbly.melbourne.sgi.com> References: <409CCB74.8060002@free.fr> <20040509210706.GA15371@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040509210706.GA15371@taniwha.stupidest.org>; from cw@f00f.org on Sun, May 09, 2004 at 02:07:06PM -0700 X-archive-position: 3076 X-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: 530 Lines: 18 On Sun, May 09, 2004 at 02:07:06PM -0700, Chris Wedgwood wrote: > On Sat, May 08, 2004 at 01:58:44PM +0200, Xavier wrote: > > > The user in witch I put a quota limit can copy a file onto the /home > > filesystem and filesystem reach 100% , nothing happen ! > > and 'quota' for that user says? In addition, repquota -v on /home will give some insight. Some basic documentation can be read from the README.quota in the xfsprogs docs. quotaon(8) also provides details on enabling quotas on XFS filesystems. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun May 9 23:24:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 May 2004 23:24:19 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4A6OGKO000904 for ; Sun, 9 May 2004 23:24:16 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i4A6QvtQ013296 for ; Sun, 9 May 2004 23:26:57 -0700 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 i4A6O5AL65536381; Mon, 10 May 2004 16:24:05 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4A6O4OC28891151; Mon, 10 May 2004 16:24:04 +1000 (EST) Date: Mon, 10 May 2004 16:24:04 +1000 (EST) From: Nathan Scott Message-Id: <200405100624.i4A6O4OC28891151@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 914274 - fix some warnings X-archive-position: 3077 X-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: 445 Lines: 16 Fix some compiler warnings, mark cmn_err as printflike. Resolves the issue Meelis Roos reported recently on lkml. Date: Sun May 9 23:21:15 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:171451a xfs_buf_item.c - 1.149 xfs_da_btree.c - 1.149 support/debug.h - 1.10 From owner-linux-xfs@oss.sgi.com Sun May 9 23:25:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 May 2004 23:25:31 -0700 (PDT) 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 i4A6PTKO001042 for ; Sun, 9 May 2004 23:25:29 -0700 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 i4A6IXhv026540 for ; Sun, 9 May 2004 23:18:34 -0700 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 i4A6IOAL63722317; Mon, 10 May 2004 16:18:24 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4A6IMxd43527650; Mon, 10 May 2004 16:18:22 +1000 (EST) Date: Mon, 10 May 2004 16:18:22 +1000 (EST) From: Nathan Scott Message-Id: <200405100618.i4A6IMxd43527650@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 913986 - xflags X-archive-position: 3078 X-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: 481 Lines: 18 Make uses of extended inode flags consistent, remove duplicated code. Date: Sun May 9 23:17:46 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: cattelan@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:171450a xfs_vnodeops.c - 1.623 xfs_itable.c - 1.123 xfs_inode.c - 1.396 xfs_inode.h - 1.190 linux-2.6/xfs_ioctl.c - 1.109 linux-2.4/xfs_ioctl.c - 1.108 From owner-linux-xfs@oss.sgi.com Sun May 9 23:57:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 May 2004 23:57:50 -0700 (PDT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4A6vhKO002220 for ; Sun, 9 May 2004 23:57:43 -0700 Received: from imp6-q.free.fr (imp6-q.free.fr [212.27.42.6]) by postfix4-2.free.fr (Postfix) with ESMTP id A1BFC9F1EF; Mon, 10 May 2004 08:57:41 +0200 (CEST) Received: by imp6-q.free.fr (Postfix, from userid 33) id 9709A1B268; Mon, 10 May 2004 08:57:41 +0200 (MEST) Received: from mail.ch-bourg01.fr (mail.ch-bourg01.fr [194.3.110.58]) by imp6-q.free.fr (IMP) with HTTP for ; Mon, 10 May 2004 08:57:41 +0200 Message-ID: <1084172261.409f27e585723@imp6-q.free.fr> Date: Mon, 10 May 2004 08:57:41 +0200 From: Xavier To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and mount /home quota problem mandrake 9.2 References: <409CCB74.8060002@free.fr> <20040509210706.GA15371@taniwha.stupidest.org> In-Reply-To: <20040509210706.GA15371@taniwha.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i4A6viKO002221 X-archive-position: 3079 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: x.poirier@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 1946 Lines: 72 Selon Chris Wedgwood : > On Sat, May 08, 2004 at 01:58:44PM +0200, Xavier wrote: > > > At first this quota was not enabled, I had to pass many command > > line with quotaon or quotacheck etc..., modify /etc/fstab , doing a > > reboot. > > mount -t xfs -o quota /dev/foo /mnt/bar > > sort of thing should be all that's required. Editing /etc/fstab means > putting in usrquota and/or grpquota to mount-options column. So, you say that the mount of the filesystem at boot with /etc/fstab parameters is not sufficient ? I will try again a "mount -t xfs -o quota /dev/foo /mnt/bar" when I can cause I' m on a production environment! > > > The second server (SERVER B) : a DELL 1750 with RAID PERC4DI have > > quota enable at mount of /home (usrquota,grpquota) > > what does /proc/filesystems say? HERE IT IS: more /proc/filesystems nodev rootfs nodev bdev nodev proc nodev sockfs nodev tmpfs nodev shm nodev pipefs ext2 nodev ramfs nodev devfs nodev nfs nodev devpts ext3 nodev usbdevfs nodev usbfs xfs nodev supermount > > > The user in witch I put a quota limit can copy a file onto the /home > > filesystem and filesystem reach 100% , nothing happen ! > > and 'quota' for that user says? HERE IT IS: repquota -sv /home *** Report for user quotas on device /dev/scsi/host2/bus0/target0/lun0/part6 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 819M 0 0 23599 0 0 userx -- 25222M 25293M 27344M 26831 0 0 *** Status for user quotas on device /dev/scsi/host2/bus0/target0/lun0/part6 Accounting: ON; Enforcement: ON Inode: #137 (2 blocks, 2 extents) -- Xavier mailto: x.poirier@free.fr From owner-linux-xfs@oss.sgi.com Mon May 10 00:09:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 May 2004 00:11:39 -0700 (PDT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4A79kKO002921 for ; Mon, 10 May 2004 00:09:47 -0700 Received: from taniwha.stupidest.org (adsl-63-205-184-25.dsl.snfc21.pacbell.net [63.205.184.25]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i4A79Ddg151108; Mon, 10 May 2004 03:09:13 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 01B4714A1D; Mon, 10 May 2004 00:09:13 -0700 (PDT) Date: Mon, 10 May 2004 00:09:12 -0700 From: Chris Wedgwood To: Xavier Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and mount /home quota problem mandrake 9.2 Message-ID: <20040510070912.GA30834@taniwha.stupidest.org> References: <409CCB74.8060002@free.fr> <20040509210706.GA15371@taniwha.stupidest.org> <1084172261.409f27e585723@imp6-q.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1084172261.409f27e585723@imp6-q.free.fr> X-archive-position: 3080 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 372 Lines: 17 On Mon, May 10, 2004 at 08:57:41AM +0200, Xavier wrote: > So, you say that the mount of the filesystem at boot with /etc/fstab > parameters is not sufficient ? yes, that's fine > > what does /proc/filesystems say? crap, i meant /proc/mounts > userx -- 25222M 25293M 27344M 26831 0 0 and this is the user than can exceed it's quota? --cw From owner-linux-xfs@oss.sgi.com Mon May 10 01:27:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 May 2004 01:27:27 -0700 (PDT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4A8ROKO007965 for ; Mon, 10 May 2004 01:27:24 -0700 Received: from imp3-q.free.fr (imp3-q.free.fr [212.27.42.3]) by postfix4-2.free.fr (Postfix) with ESMTP id 82BFC9F106 for ; Mon, 10 May 2004 10:27:23 +0200 (CEST) Received: by imp3-q.free.fr (Postfix, from userid 33) id 774C91ABD8; Mon, 10 May 2004 10:27:23 +0200 (MEST) Received: from mail.ch-bourg01.fr (mail.ch-bourg01.fr [194.3.110.58]) by imp3-q.free.fr (IMP) with HTTP for ; Mon, 10 May 2004 10:27:23 +0200 Message-ID: <1084177643.409f3ceb614b5@imp3-q.free.fr> Date: Mon, 10 May 2004 10:27:23 +0200 From: Xavier To: linux-xfs@oss.sgi.com Subject: Re: XFS and mount /home quota problem mandrake 9.2 References: <409CCB74.8060002@free.fr> <20040509210706.GA15371@taniwha.stupidest.org> <1084172261.409f27e585723@imp6-q.free.fr> <20040510070912.GA30834@taniwha.stupidest.org> In-Reply-To: <20040510070912.GA30834@taniwha.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i4A8RPKO007966 X-archive-position: 3081 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: x.poirier@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 728 Lines: 32 Selon Chris Wedgwood : > > crap, i meant /proc/mounts more /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw 0 0 none /dev devfs rw 0 0 none /proc proc rw 0 0 none /proc/bus/usb usbfs rw 0 0 none /dev/pts devpts rw 0 0 /dev/sda6 /home xfs rw,noatime,usrquota 0 0 none /mnt/cdrom supermount ro,dev=/dev/hdc,fs=udf:iso9660,tray_lock=onwrite,--,iocharset=iso8859-15 0 0 none /mnt/floppy supermount rw,sync,dev=/dev/fd0,fs=ext2:vfat,tray_lock=onwrite,--,codepage=850,iocharset=iso8859-15 0 0 > > > userx -- 25222M 25293M 27344M 26831 0 0 > > and this is the user than can exceed it's quota? Yes : userx can exced quota limits up to 25293M -- Xavier mailto: x.poirier@free.fr From owner-linux-xfs@oss.sgi.com Mon May 10 03:10:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 May 2004 03:10:33 -0700 (PDT) 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 i4AAATKO012816 for ; Mon, 10 May 2004 03:10:29 -0700 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 i4AA8xhv029185 for ; Mon, 10 May 2004 03:08:59 -0700 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 UAA07055; Mon, 10 May 2004 20:08:56 +1000 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 i4AA8mln340536; Mon, 10 May 2004 20:08:48 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4AA8lSd339737; Mon, 10 May 2004 20:08:47 +1000 (EST) Date: Mon, 10 May 2004 20:08:47 +1000 From: Nathan Scott To: Xavier Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and mount /home quota problem mandrake 9.2 Message-ID: <20040510200847.A339754@wobbly.melbourne.sgi.com> References: <409CCB74.8060002@free.fr> <20040509210706.GA15371@taniwha.stupidest.org> <1084172261.409f27e585723@imp6-q.free.fr> <20040510070912.GA30834@taniwha.stupidest.org> <1084177643.409f3ceb614b5@imp3-q.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1084177643.409f3ceb614b5@imp3-q.free.fr>; from x.poirier@free.fr on Mon, May 10, 2004 at 10:27:23AM +0200 X-archive-position: 3082 X-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: 734 Lines: 24 On Mon, May 10, 2004 at 10:27:23AM +0200, Xavier wrote: > Selon Chris Wedgwood : > > > > > userx -- 25222M 25293M 27344M 26831 0 0 > > > > and this is the user than can exceed it's quota? > > Yes : userx can exced quota limits up to 25293M userx should be allowed to exceed 25293M here - that is the "soft" limit. It is the hard limit that one may not exceed, and after a period of time (default 7 days iirc), the soft limit becomes the hard limit - this is how all quota systems function, I believe; certainly XFS and the other filesystems on Linux behave this way. Can you show the repquota output when the user has exceeded the hard limit, or does that not happen? thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon May 10 08:26:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 May 2004 08:26:17 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4AFQ4KO028082 for ; Mon, 10 May 2004 08:26:05 -0700 Received: from hpti9.fsl.noaa.gov ([137.75.132.229]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Mon, 10 May 2004 11:26:03 -0400 Subject: Re: Questions about pagebuf code From: Craig Tierney To: Russell Cattelan Cc: linux-xfs@oss.sgi.com, dritch@HPTI.com In-Reply-To: <1083872935.28589.27.camel@naboo.americas.sgi.com> References: <1083435856.2302.3.camel@localhost.localdomain> <20040501194709.A23768@infradead.org> <1083446482.2302.22.camel@localhost.localdomain> <1083614597.24397.16.camel@naboo.americas.sgi.com> <1083870335.2376.10.camel@hpti9.fsl.noaa.gov> <1083872935.28589.27.camel@naboo.americas.sgi.com> Content-Type: text/plain Message-Id: <1084202701.2386.5.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 May 2004 09:25:01 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2004 15:26:03.0719 (UTC) FILETIME=[1B342D70:01C436A3] X-archive-position: 3083 X-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: 2330 Lines: 56 > > It appears my corruption pattern is different (but not unrelated). > > I finally confirmed that when a file is corrupted, it is corrupted > > with data occurring from another write. For example, Temperature gets > > overwritten when height, or velocity is overwritten with humidity. > The problem is trying to figure out if the data is stale or really from > a different process. > If the data block was previously used and then freed either by removing > the old file or truncating it and then the new file reallocates that > free block into its file but never writes to that block, the data is > stale. I ran several tests over the weekend where wrote a pattern to the disk (val=pos%256). My tests showed that the pages are just not being written. I see the original pattern, and not values that look like data. It seems that my problem is the same as you have described before. That helps. The doublewrite code is easier to run and hopefully debug. Craig > > Now if you pattern up a partition with zeros or some known pattern, make > a file system run your test with no removes or truncates and you still > see data from another client, that is not a stale data problem. > That would indicate a page management problem, (usually a locking > problem) the size of corruption is usually limited to a page size > in those cases. > If I remember right you were seeing problems or 1 or more pages in > length? > > I wish I had something for you to try, my latest go around on this bug > is not looking promising. > I thought it might have something to do with i_sem not being held > for writes, but I'm still seeing the problem even with the i_sem. > I need to put an assert in generic_file_write just to make sure > i_sem is being coming in locked. > > > > > > Unless there is something really wrong in caching, the corruption > > must becoming from another client process. In one case, process > > 3 showed corruption in file 8. The corruption in file 8 matches > > data from file 14 (files are written in order). Processes > > are all started at the same time, but they do get out of sync > > because of IO and other load issues. > > > > It seems like buffers are overwritten, or if the IO is async > > that a buffer is being used before it is actually no longer in > > use. > > > > Craig > > > > From owner-linux-xfs@oss.sgi.com Mon May 10 08:42:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 May 2004 08:42:26 -0700 (PDT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4AFgEKO028941 for ; Mon, 10 May 2004 08:42:15 -0700 Received: from imp6-q.free.fr (imp6-q.free.fr [212.27.42.6]) by postfix4-1.free.fr (Postfix) with ESMTP id E2724106D2E for ; Mon, 10 May 2004 17:42:11 +0200 (CEST) Received: by imp6-q.free.fr (Postfix, from userid 33) id D32E41D3A1; Mon, 10 May 2004 17:42:11 +0200 (MEST) Received: from mail.ch-bourg01.fr (mail.ch-bourg01.fr [194.3.110.58]) by imp6-q.free.fr (IMP) with HTTP for ; Mon, 10 May 2004 17:42:11 +0200 Message-ID: <1084203731.409fa2d382619@imp6-q.free.fr> Date: Mon, 10 May 2004 17:42:11 +0200 From: Xavier To: linux-xfs@oss.sgi.com Subject: Re: XFS and mount /home quota problem mandrake 9.2 References: <409CCB74.8060002@free.fr> <20040509210706.GA15371@taniwha.stupidest.org> <1084172261.409f27e585723@imp6-q.free.fr> <20040510070912.GA30834@taniwha.stupidest.org> <1084177643.409f3ceb614b5@imp3-q.free.fr> <20040510200847.A339754@wobbly.melbourne.sgi.com> In-Reply-To: <20040510200847.A339754@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i4AFgFKO028942 X-archive-position: 3084 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: x.poirier@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 1267 Lines: 47 Selon Nathan Scott : Million thanks Nathan !! What a silly boy I am ! I was persuaded that there was a message indicating a "soft" quota exceed. Doing the tests of copying a file in user "userx" was in fact a wrong test. So, XFS quotas works great with linux Mandrake 9.2 now ! thanks a lot SGI mans. Sorry for disturbing this ML for this stupid question. bye PS: I can go now to see if it works with SAMBA 3.0.x ! Xavier > On Mon, May 10, 2004 at 10:27:23AM +0200, Xavier wrote: > > Selon Chris Wedgwood : > > > > > > > userx -- 25222M 25293M 27344M 26831 0 0 > > > > > > and this is the user than can exceed it's quota? > > > > Yes : userx can exced quota limits up to 25293M > > userx should be allowed to exceed 25293M here - that is the > "soft" limit. It is the hard limit that one may not exceed, > and after a period of time (default 7 days iirc), the soft > limit becomes the hard limit - this is how all quota systems > function, I believe; certainly XFS and the other filesystems > on Linux behave this way. > > Can you show the repquota output when the user has exceeded > the hard limit, or does that not happen? > > thanks. > > -- > Nathan > -- Xavier mailto: x.poirier@free.fr From owner-linux-xfs@oss.sgi.com Mon May 10 15:44:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 May 2004 15:44:29 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4AMiOKO013364 for ; Mon, 10 May 2004 15:44:24 -0700 Received: from hpti9.fsl.noaa.gov ([137.75.132.229]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Mon, 10 May 2004 18:44:23 -0400 Subject: XFS code questions From: Craig Tierney To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1084229000.2990.14.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 10 May 2004 16:43:20 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2004 22:44:23.0676 (UTC) FILETIME=[573323C0:01C436E0] X-archive-position: 3085 X-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: 755 Lines: 22 I have a few questions about the xfs code. Line numbers are relative to the 2.4.26 kernel. 1) In xfs_lrw.c in xfs_iozero at line 179, a page is allocated by grab_cache_page. Does grab_cache_page guarantee that the page is lockable AND that grab_cache_page does the locking? At then end of the function the page is unlocked. Does it matter because you are just zeroing out the page? 2) In xfs_aops.c, the function xfs_count_page_state checks the page for it's state (delayed alloc, unmapped, unwritten). Why does it to a do while to figure it out? Why can't it just check once? Is it check incase there are mulitple buffers in one page? 3) Should the setting of flags with PFLAGS (ex. line 1300 in xfs_aops.c) be done atomically? Thanks, Craig From owner-linux-xfs@oss.sgi.com Mon May 10 16:34:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 May 2004 16:34:15 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4ANY7KO017611 for ; Mon, 10 May 2004 16:34:09 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i4ANaq5a013753 for ; Mon, 10 May 2004 16:36:52 -0700 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 JAA22418; Tue, 11 May 2004 09:33:54 +1000 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 i4ANXpln356886; Tue, 11 May 2004 09:33:51 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4ANXn11350766; Tue, 11 May 2004 09:33:49 +1000 (EST) Date: Tue, 11 May 2004 09:33:49 +1000 From: Nathan Scott To: Craig Tierney Cc: linux-xfs@oss.sgi.com Subject: Re: XFS code questions Message-ID: <20040511093349.B354661@wobbly.melbourne.sgi.com> References: <1084229000.2990.14.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1084229000.2990.14.camel@hpti9.fsl.noaa.gov>; from ctierney@HPTI.com on Mon, May 10, 2004 at 04:43:20PM -0600 X-archive-position: 3086 X-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: 1104 Lines: 37 hi Craig, On Mon, May 10, 2004 at 04:43:20PM -0600, Craig Tierney wrote: > I have a few questions about the xfs code. Line > numbers are relative to the 2.4.26 kernel. > > 1) In xfs_lrw.c in xfs_iozero at line 179, a page is allocated > by grab_cache_page. Does grab_cache_page guarantee > that the page is lockable AND that grab_cache_page > does the locking? grab_cache_page returns a locked page, or NULL. > 2) In xfs_aops.c, the function xfs_count_page_state checks > the page for it's state (delayed alloc, unmapped, unwritten). > Why does it to a do while to figure it out? Why can't it > just check once? Is it check incase there are mulitple > buffers in one page? Yep, this is to support filesystem blocksizes smaller than the page size. > 3) Should the setting of flags with PFLAGS (ex. line > 1300 in xfs_aops.c) be done atomically? Process flags aren't set there, that'll be testing whether or not they are set. Doesn't need to use atomic interfaces, no. Those two process flags are set/cleared in the VM and inside the XFS transaction manager code. HTH. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon May 10 16:37:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 May 2004 16:37:40 -0700 (PDT) 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 i4ANbbKO018038 for ; Mon, 10 May 2004 16:37:37 -0700 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 i4ANbUhv021965 for ; Mon, 10 May 2004 16:37:31 -0700 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 JAA22487; Tue, 11 May 2004 09:37:26 +1000 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 i4ANbPln355970; Tue, 11 May 2004 09:37:25 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4ANbOwc355995; Tue, 11 May 2004 09:37:24 +1000 (EST) Date: Tue, 11 May 2004 09:37:24 +1000 From: Nathan Scott To: Xavier Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and mount /home quota problem mandrake 9.2 Message-ID: <20040511093723.C354661@wobbly.melbourne.sgi.com> References: <409CCB74.8060002@free.fr> <20040509210706.GA15371@taniwha.stupidest.org> <1084172261.409f27e585723@imp6-q.free.fr> <20040510070912.GA30834@taniwha.stupidest.org> <1084177643.409f3ceb614b5@imp3-q.free.fr> <20040510200847.A339754@wobbly.melbourne.sgi.com> <1084203731.409fa2d382619@imp6-q.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1084203731.409fa2d382619@imp6-q.free.fr>; from x.poirier@free.fr on Mon, May 10, 2004 at 05:42:11PM +0200 X-archive-position: 3087 X-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: 645 Lines: 28 On Mon, May 10, 2004 at 05:42:11PM +0200, Xavier wrote: > Selon Nathan Scott : > > Million thanks Nathan !! > > What a silly boy I am ! > I was persuaded that there was a message indicating a "soft" quota exceed. > Doing the tests of copying a file in user "userx" was in fact a wrong test. > > So, XFS quotas works great with linux Mandrake 9.2 now ! Good to hear. > thanks a lot SGI mans. > Sorry for disturbing this ML for this stupid question. No problem. > PS: I can go now to see if it works with SAMBA 3.0.x ! We have some XFS quota code in that Samba release, I believe, so it should work. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue May 11 00:37:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 00:37:56 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4B7b7KO002758 for ; Tue, 11 May 2004 00:37:07 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4B7b7cd002757 for linux-xfs@oss.sgi.com; Tue, 11 May 2004 00:37:07 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4B7b5KQ002741 for ; Tue, 11 May 2004 00:37:06 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4B7Ulg5002542; Tue, 11 May 2004 00:30:47 -0700 Date: Tue, 11 May 2004 00:30:47 -0700 Message-Id: <200405110730.i4B7Ulg5002542@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 3088 X-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: 960 Lines: 30 http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 ------- Additional Comments From steven.wilton@team.eftel.com 2004-11-05 00:30 PDT ------- The 2.6.6 kernel was consistently displaying the original bug very consistently on our backup server until I applied the following patch. --- fs/xfs/linux/xfs_buf.c.orig Tue May 11 13:38:54 2004 +++ fs/xfs/linux/xfs_buf.c Tue May 11 13:40:20 2004 @@ -370,8 +370,8 @@ retry: page = find_or_create_page(mapping, first + i, gfp_mask); if (unlikely(page == NULL)) { - if (flags & PBF_READ_AHEAD) - return -ENOMEM; + //if (flags & PBF_READ_AHEAD) + // return -ENOMEM; /* * This could deadlock. ------- 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 May 11 01:37:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 01:37:24 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4B8b6KO004316 for ; Tue, 11 May 2004 01:37:06 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4B8b6MQ004315 for linux-xfs@oss.sgi.com; Tue, 11 May 2004 01:37:06 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4B8b5KQ004298 for ; Tue, 11 May 2004 01:37:05 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4B7hoBG003241; Tue, 11 May 2004 00:43:50 -0700 Date: Tue, 11 May 2004 00:43:50 -0700 Message-Id: <200405110743.i4B7hoBG003241@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 3089 X-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: 304 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 ------- Additional Comments From hch@xfs.org 2004-11-05 00:43 PDT ------- Okay, I see the problem now. I'll work on a fix ASAP. ------- 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 May 11 02:37:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 02:37:22 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4B9b8KO005779 for ; Tue, 11 May 2004 02:37:08 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4B9b8N0005778 for linux-xfs@oss.sgi.com; Tue, 11 May 2004 02:37:08 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4B9b5KY005754 for ; Tue, 11 May 2004 02:37:06 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4B92HXv005083; Tue, 11 May 2004 02:02:17 -0700 Date: Tue, 11 May 2004 02:02:17 -0700 Message-Id: <200405110902.i4B92HXv005083@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 3090 X-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: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|xfs-master@oss.sgi.com |hch@xfs.org ------- 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 May 11 13:00:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 13:00:50 -0700 (PDT) Received: from diablo.celestial.com (diablo.celestial.com [192.136.111.52]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4BK0kKO026832 for ; Tue, 11 May 2004 13:00:46 -0700 Received: from localhost (localhost [127.0.0.1]) by diablo.celestial.com (Postfix) with ESMTP id 6E8621F926 for ; Tue, 11 May 2004 13:00:45 -0700 (PDT) Received: from linux-sxs.org (d60-54-189.col.wideopenwest.com [65.60.189.54]) by diablo.celestial.com (Postfix) with ESMTP id 2EC231F91D for ; Tue, 11 May 2004 13:00:44 -0700 (PDT) Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.11/8.12.11) with ESMTP id i4BJ3u1X022167 for ; Tue, 11 May 2004 15:03:56 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.11/8.12.10/Submit) with ESMTP id i4BJ3ujG022164 for ; Tue, 11 May 2004 15:03:56 -0400 Date: Tue, 11 May 2004 15:03:56 -0400 (EDT) From: Net Llama! To: linux-xfs@oss.sgi.com Subject: RHES-3.0 with XFS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Virus-Scanned: by amavisd-new at celestial.com X-archive-position: 3091 X-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: 323 Lines: 8 Does anyone know if there are any Redhat Enterprise 3 installer CD images that support XFS (similar to what exists for the older RH releases)? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Tue May 11 15:38:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 15:39:07 -0700 (PDT) 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 i4BMcnKO004305 for ; Tue, 11 May 2004 15:38:54 -0700 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i4BMcKJ01670; Tue, 11 May 2004 15:38:23 -0700 Date: Tue, 11 May 2004 15:40:57 -0700 From: Andrew Morton To: bart@samwel.tk Cc: linux-xfs@oss.sgi.com, Nathan Scott Subject: Re: [patch 1/1] Update laptop mode control script with XFS_HZ=100 Message-Id: <20040511154057.6d6c193b.akpm@osdl.org> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3092 X-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: 526 Lines: 20 bart@samwel.tk wrote: > > The laptop mode control script incorrectly guesses XFS_HZ=1000. aargh. XFS is broken. It shouldn't be exposing jiffy-based tunables into /proc, or `mount -o remount' or whatever. It would be much better to rework XFS so that these user-visible tunables are in units of milliseconds, centiseconds or whatever. Is this possible, please? If so, please make the /proc filename reflect the tunable's units: /proc/sys/fs/xfs/lm_sync_centisecs /proc/sys/fs/xfs/age_buffer_centisecs etc. thanks. From owner-linux-xfs@oss.sgi.com Tue May 11 16:15:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 16:16:00 -0700 (PDT) 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 i4BNFnKO005631 for ; Tue, 11 May 2004 16:15:51 -0700 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i4BNFKJ06909; Tue, 11 May 2004 16:15:20 -0700 Date: Tue, 11 May 2004 16:17:56 -0700 From: Andrew Morton To: Nathan Scott Cc: bart@samwel.tk, linux-xfs@oss.sgi.com Subject: Re: [patch 1/1] Update laptop mode control script with XFS_HZ=100 Message-Id: <20040511161756.189308e6.akpm@osdl.org> In-Reply-To: <20040512090006.B362314@wobbly.melbourne.sgi.com> References: <20040511154057.6d6c193b.akpm@osdl.org> <20040512090006.B362314@wobbly.melbourne.sgi.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3093 X-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: 599 Lines: 19 Nathan Scott wrote: > > What's the right way to convert milli/centiseconds into jiffies for > subsequent use in time_before()/schedule_timeout()? erm, millisecs = (jiffies * 1000) / HZ centisecs = (jiffies * 100) / HZ jiffies = (millisecs * HZ) / 1000 jiffies = (centisecs * HZ) / 100 obviously one needs to watch out for overflows, but I think we can safely assume the user is asking for less than 4 million seconds. In page-writeback.c I didn't bother converting the numbers - just do the math each time we use the number because these are very low-frequency callpaths. From owner-linux-xfs@oss.sgi.com Tue May 11 16:52:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 16:52:16 -0700 (PDT) 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 i4BNqCKO010363 for ; Tue, 11 May 2004 16:52:13 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i4BNfdT9011479 for ; Tue, 11 May 2004 18:41:40 -0500 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i4BNfcR23987 for linux-xfs@oss.sgi.com; Wed, 12 May 2004 09:41:38 +1000 Date: Wed, 12 May 2004 09:41:38 +1000 From: Nathan Scott Message-Id: <200405112341.i4BNfcR23987@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - dmapi docs in 2.6 X-archive-position: 3094 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 393 Lines: 14 Reinstate DMAPI mount option docs, dropped accidentally at some point. Date: Tue May 11 16:41:09 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:171580a Documentation/filesystems/xfs.txt - 1.5 split-patches/dmapi-enable - 1.4 From owner-linux-xfs@oss.sgi.com Tue May 11 18:00:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 18:00:35 -0700 (PDT) Received: from mail2.catalyst.net.nz (godel.catalyst.net.nz [202.49.159.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4C10OKO012193 for ; Tue, 11 May 2004 18:00:25 -0700 Received: from leibniz.catalyst.net.nz ([202.49.159.7] helo=shankara.wgtn.cat-it.co.nz) by mail2.catalyst.net.nz with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.35 #1 (Debian)) id 1BNi6a-0005Wl-02 for ; Wed, 12 May 2004 13:00:16 +1200 From: Steve Wray Reply-To: stevew@catalyst.net.nz To: linux-xfs@oss.sgi.com Subject: XFS for postgres databases? Date: Wed, 12 May 2004 13:00:14 +1200 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200405121300.14866.stevew@catalyst.net.nz> X-System-Filter-Id: mail2.catalyst.net.nz 1BNi6a-0005Wl-02 X-Virus-Scanned-By: Amavis with CLAM Anti Virus on mail2.catalyst.net.nz X-archive-position: 3095 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stevew@catalyst.net.nz Precedence: bulk X-list: linux-xfs Content-Length: 281 Lines: 9 Hi there, I'd just like to know if anyone knows of any issues with running a postgres database on an XFS filesystem in Linux? We did this a few weeks ago and the DB Admin swears that they have been seeing problems. I'm not convinced that the problems are XFS related. Thanks! From owner-linux-xfs@oss.sgi.com Tue May 11 19:06:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 19:06:03 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4C25xKO014114 for ; Tue, 11 May 2004 19:06:00 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i4C28uu3011148 for ; Tue, 11 May 2004 19:08:57 -0700 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 MAA23168 for ; Wed, 12 May 2004 12:05:51 +1000 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 i4C25oln387289 for ; Wed, 12 May 2004 12:05:50 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4C25nGA389005 for linux-xfs@oss.sgi.com; Wed, 12 May 2004 12:05:49 +1000 (EST) Date: Wed, 12 May 2004 12:05:48 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: [resend] Re: Update laptop mode control script with XFS_HZ=100 Message-ID: <20040512120548.G362314@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 3096 X-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: 2162 Lines: 73 ----- Forwarded message from Mail Delivery Subsystem ----- Date: Tue, 11 May 2004 16:09:33 -0700 To: From: Mail Delivery Subsystem Subject: Returned mail: see transcript for details The original message was received at Tue, 11 May 2004 16:03:41 -0700 from fddi-nodin.corp.sgi.com [198.29.75.193] ----- The following addresses had permanent fatal errors ----- (reason: 554 5.4.6 Too many hops) ----- Transcript of session follows ----- 554 5.4.6 Too many hops 18 (17 max): from via localhost, to Reporting-MTA: dns; omx2.sgi.com Arrival-Date: Tue, 11 May 2004 16:03:41 -0700 Final-Recipient: RFC822; linux-xfs@oss.sgi.com Action: failed Status: 5.4.6 Diagnostic-Code: SMTP; 554 5.4.6 Too many hops Last-Attempt-Date: Tue, 11 May 2004 16:09:33 -0700 Date: Wed, 12 May 2004 09:00:06 +1000 To: bart@samwel.tk, Andrew Morton Cc: linux-xfs@oss.sgi.com User-Agent: Mutt/1.2.5i From: Nathan Scott Subject: Re: [patch 1/1] Update laptop mode control script with XFS_HZ=100 Hi guys, On Tue, May 11, 2004 at 03:40:57PM -0700, Andrew Morton wrote: > bart@samwel.tk wrote: > > > > The laptop mode control script incorrectly guesses XFS_HZ=1000. I thought you switched the laptop mode XFS patches to USER_HZ to avoid this issue Bart? > aargh. XFS is broken. It shouldn't be exposing jiffy-based tunables into > /proc, or `mount -o remount' or whatever. > > It would be much better to rework XFS so that these user-visible tunables > are in units of milliseconds, centiseconds or whatever. > > Is this possible, please? Shouldn't be a big deal to switch (and certainly more user friendly). What's the right way to convert milli/centiseconds into jiffies for subsequent use in time_before()/schedule_timeout()? > If so, please make the /proc filename reflect the tunable's units: > > /proc/sys/fs/xfs/lm_sync_centisecs > /proc/sys/fs/xfs/age_buffer_centisecs > etc. cheers. -- Nathan ----- End forwarded message ----- -- Nathan From owner-linux-xfs@oss.sgi.com Tue May 11 20:30:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 20:30:06 -0700 (PDT) Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4C3U3KO019157 for ; Tue, 11 May 2004 20:30:03 -0700 Received: from noodles (adsl-64-169-161-243.dsl.snfc21.pacbell.net [64.169.161.243]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id i4C3SeZq015384; Tue, 11 May 2004 20:28:40 -0700 (PDT) Received: from jwb by noodles with local (Exim 3.36 #1 (Debian)) id 1BNkRc-0002wn-00; Tue, 11 May 2004 20:30:08 -0700 Subject: Re: XFS for postgres databases? From: "Jeffrey W. Baker" To: stevew@catalyst.net.nz Cc: linux-xfs@oss.sgi.com In-Reply-To: <200405121300.14866.stevew@catalyst.net.nz> References: <200405121300.14866.stevew@catalyst.net.nz> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1084332608.11308.3.camel@noodles> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 11 May 2004 20:30:08 -0700 X-archive-position: 3097 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jwbaker@acm.org Precedence: bulk X-list: linux-xfs Content-Length: 841 Lines: 22 On Tue, 2004-05-11 at 18:00, Steve Wray wrote: > Hi there, > I'd just like to know if anyone knows of any issues with running a > postgres database on an XFS filesystem in Linux? > > We did this a few weeks ago and the DB Admin swears that they have been > seeing problems. I'm not convinced that the problems are XFS related. Until a few days ago I had a very large postgresql installation on XFS. We suffered very unusual problems like corrupt tables, missing rows, corrupt indexes, and so forth. We've never seen those problems on ext2, to which we have since switched back. We also had a host of other operational problems like oopsing on log recovery at boot, inability to mount the fs, days-long xfsrepair sessions, ad infinitum. It may be that the heavy sync load of postgresql is not well tested under Linux with xfs. -jwb From owner-linux-xfs@oss.sgi.com Tue May 11 21:52:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 21:52:24 -0700 (PDT) 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 i4C4qDKO021098 for ; Tue, 11 May 2004 21:52:13 -0700 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 i4C4e5T9005537 for ; Tue, 11 May 2004 23:40:06 -0500 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 OAA25780; Wed, 12 May 2004 14:39:52 +1000 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 i4C4djln391979; Wed, 12 May 2004 14:39:46 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4C4dfcw391753; Wed, 12 May 2004 14:39:41 +1000 (EST) Date: Wed, 12 May 2004 14:39:41 +1000 From: Nathan Scott To: stevew@catalyst.net.nz, "Jeffrey W. Baker" Cc: linux-xfs@oss.sgi.com Subject: Re: XFS for postgres databases? Message-ID: <20040512143941.A389759@wobbly.melbourne.sgi.com> References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1084332608.11308.3.camel@noodles>; from jwbaker@acm.org on Tue, May 11, 2004 at 08:30:08PM -0700 X-archive-position: 3098 X-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: 929 Lines: 26 On Tue, May 11, 2004 at 08:30:08PM -0700, Jeffrey W. Baker wrote: > On Tue, 2004-05-11 at 18:00, Steve Wray wrote: > > Hi there, > > I'd just like to know if anyone knows of any issues with running a > > postgres database on an XFS filesystem in Linux? > > > > We did this a few weeks ago and the DB Admin swears that they have been > > seeing problems. I'm not convinced that the problems are XFS related. > > Until a few days ago I had a very large postgresql installation on XFS. > We suffered very unusual problems like corrupt tables, missing rows, > corrupt indexes, and so forth. You were running dd on the block device at the same time as using the mounted filesystem though, weren't you? Did problems persist after you stopped doing that? You didn't get back to us with any further details there.. Do you (either of you) have a test case so we can try to reproduce these problems locally? thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Tue May 11 23:20:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 23:20:51 -0700 (PDT) Received: from mail4.tpgi.com.au (mail.tpgi.com.au [203.12.160.61]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4C6KVKO023711 for ; Tue, 11 May 2004 23:20:32 -0700 Received: from laptop-linux.wpcb.org.au (203-219-189-93-cbr-pow-ts3-2600.tpgi.com.au [203.219.189.93]) by mail4.tpgi.com.au (8.12.10/8.12.10) with ESMTP id i4C6KHHb010124; Wed, 12 May 2004 16:20:18 +1000 From: Nigel Cunningham Reply-To: ncunningham@linuxmail.org To: Nathan Scott , stevew@catalyst.net.nz, "Jeffrey W. Baker" Subject: Re: XFS for postgres databases? Date: Wed, 12 May 2004 16:18:27 +1000 User-Agent: KMail/1.5.3 Cc: linux-xfs@oss.sgi.com References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> <20040512143941.A389759@wobbly.melbourne.sgi.com> In-Reply-To: <20040512143941.A389759@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405121618.27843.ncunningham@linuxmail.org> X-TPG-Antivirus: Passed X-archive-position: 3099 X-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@linuxmail.org Precedence: bulk X-list: linux-xfs Content-Length: 436 Lines: 15 Hi. 'scuse my ignorance, but why in the world is it a bad thing to run dd (dd if=/devhda1 of=/dev/null) on a mounted filesystem with XFS? Regards, Nigel On Wed, 12 May 2004 14:39, Nathan Scott wrote: > You were running dd on the block device at the same time as using > the mounted filesystem though, weren't you? Did problems persist > after you stopped doing that? You didn't get back to us with any > further details there.. From owner-linux-xfs@oss.sgi.com Tue May 11 23:56:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 May 2004 23:56:57 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4C6urKO025183 for ; Tue, 11 May 2004 23:56:53 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i4C6xq5A028074 for ; Tue, 11 May 2004 23:59:52 -0700 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 QAA28225; Wed, 12 May 2004 16:56:36 +1000 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 i4C6uYln394692; Wed, 12 May 2004 16:56:34 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4C6uODi394186; Wed, 12 May 2004 16:56:24 +1000 (EST) Date: Wed, 12 May 2004 16:56:24 +1000 From: Nathan Scott To: Nigel Cunningham Cc: stevew@catalyst.net.nz, "Jeffrey W. Baker" , linux-xfs@oss.sgi.com Subject: Re: XFS for postgres databases? Message-ID: <20040512165624.C389759@wobbly.melbourne.sgi.com> References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> <20040512143941.A389759@wobbly.melbourne.sgi.com> <200405121618.27843.ncunningham@linuxmail.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200405121618.27843.ncunningham@linuxmail.org>; from ncunningham@linuxmail.org on Wed, May 12, 2004 at 04:18:27PM +1000 X-archive-position: 3100 X-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: 1409 Lines: 35 On Wed, May 12, 2004 at 04:18:27PM +1000, Nigel Cunningham wrote: > Hi. > > 'scuse my ignorance, but why in the world is it a bad thing to run dd (dd > if=/devhda1 of=/dev/null) on a mounted filesystem with XFS? > The way XFS manages metadata buffers is not coherent with concurrent direct block device access (the block device filesystem is expecting filesystems to be attaching buffer_heads to pages and observing the locking semantics of operating that way, which pagebuf is not - so, reading from the device populates the page cache with data from the device inode and can inadvertently corrupt XFS's view of the world). Christoph has been working on fixing that up in 2.6, he'll have the gory details if you're curious. (actually, Christoph/Steve - do we have to use bdev->bd_inode->i_mapping as the buftarg mapping? what if we fudged that mapping, then our pages wouldn't overlap with the block device inode pages - wouldn't that work around this? maybe Russells hack^Widea of using multiple metadata mappings to overcome the pagecache size limits would be helped there too...?) > > On Wed, 12 May 2004 14:39, Nathan Scott wrote: > > You were running dd on the block device at the same time as using > > the mounted filesystem though, weren't you? Did problems persist > > after you stopped doing that? You didn't get back to us with any > > further details there.. > cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed May 12 00:13:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 00:14:20 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4C7DlKO026151 for ; Wed, 12 May 2004 00:13:47 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i4C7GkGQ032363 for ; Wed, 12 May 2004 00:16:46 -0700 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 i4C7DUAL65313887; Wed, 12 May 2004 17:13:30 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4C7DSB756464421; Wed, 12 May 2004 17:13:28 +1000 (EST) Date: Wed, 12 May 2004 17:13:28 +1000 (EST) From: Nathan Scott Message-Id: <200405120713.i4C7DSB756464421@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 912975 - laptop mode patch X-archive-position: 3101 X-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: 404 Lines: 15 Merge final laptop mode patch (xfssyncd) from Bart Samwel. Date: Wed May 12 00:13:01 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: hch@lst.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:171591a linux-2.6/xfs_vfs.h - 1.46 linux-2.6/xfs_vfs.c - 1.55 linux-2.6/xfs_super.c - 1.305 From owner-linux-xfs@oss.sgi.com Wed May 12 00:53:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 00:53:59 -0700 (PDT) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4C7rRKO030407 for ; Wed, 12 May 2004 00:53:32 -0700 Received: from localhost ([127.0.0.1] helo=samwel.tk) by samwel.tk with esmtp (Exim 4.33) id 1BNoY9-0002co-4n; Wed, 12 May 2004 09:53:09 +0200 Message-ID: <40A1D7E3.8020700@samwel.tk> Date: Wed, 12 May 2004 09:53:07 +0200 From: Bart Samwel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: nl, en-us, en MIME-Version: 1.0 To: Nathan Scott CC: Andrew Morton , linux-xfs@oss.sgi.com Subject: Re: [patch 1/1] Update laptop mode control script with XFS_HZ=100 References: <20040511154057.6d6c193b.akpm@osdl.org> <20040512090006.B362314@wobbly.melbourne.sgi.com> In-Reply-To: <20040512090006.B362314@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 3102 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 922 Lines: 27 Nathan Scott wrote: > On Tue, May 11, 2004 at 03:40:57PM -0700, Andrew Morton wrote: > >>bart@samwel.tk wrote: >> >>>The laptop mode control script incorrectly guesses XFS_HZ=1000. > > I thought you switched the laptop mode XFS patches to USER_HZ to > avoid this issue Bart? I did. But I forgot to update the Laptop Mode control script to use the common USER_HZ value as well, and that's what this patch is for. (In fact, I didn't see that the USER_HZ patch went in until 2.6.6 came out, so that's why I didn't submit this patch earlier.) >>aargh. XFS is broken. It shouldn't be exposing jiffy-based tunables into >>/proc, or `mount -o remount' or whatever. >> >>It would be much better to rework XFS so that these user-visible tunables >>are in units of milliseconds, centiseconds or whatever. They're in USER_HZ since 2.6.6. Andrew, is that OK or should they really be in some even more fixed unit? --Bart From owner-linux-xfs@oss.sgi.com Wed May 12 00:55:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 00:56:00 -0700 (PDT) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4C7sxKO030572 for ; Wed, 12 May 2004 00:55:00 -0700 Received: from localhost ([127.0.0.1] helo=samwel.tk) by samwel.tk with esmtp (Exim 4.33) id 1BNoZh-0002fV-KU; Wed, 12 May 2004 09:54:45 +0200 Message-ID: <40A1D844.7090302@samwel.tk> Date: Wed, 12 May 2004 09:54:44 +0200 From: Bart Samwel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: nl, en-us, en MIME-Version: 1.0 To: Andrew Morton CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: [patch 1/1] Update laptop mode control script with XFS_HZ=100 References: <20040511154057.6d6c193b.akpm@osdl.org> <20040512090006.B362314@wobbly.melbourne.sgi.com> <20040511161756.189308e6.akpm@osdl.org> In-Reply-To: <20040511161756.189308e6.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 3103 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 595 Lines: 25 Andrew Morton wrote: > Nathan Scott wrote: > >>What's the right way to convert milli/centiseconds into jiffies for >>subsequent use in time_before()/schedule_timeout()? > > > erm, > > millisecs = (jiffies * 1000) / HZ > centisecs = (jiffies * 100) / HZ > jiffies = (millisecs * HZ) / 1000 > jiffies = (centisecs * HZ) / 100 > > obviously one needs to watch out for overflows, but I think we can safely > assume the user is asking for less than 4 million seconds. The XFS tunables are all guarded by max/min values, so this is guaranteed to not overflow. --Bart From owner-linux-xfs@oss.sgi.com Wed May 12 01:06:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 01:07:00 -0700 (PDT) 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 i4C86wKO031389 for ; Wed, 12 May 2004 01:06:58 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i4C85HJ10748; Wed, 12 May 2004 01:05:17 -0700 Date: Wed, 12 May 2004 01:04:53 -0700 From: Andrew Morton To: Bart Samwel Cc: nathans@sgi.com, linux-xfs@oss.sgi.com Subject: Re: [patch 1/1] Update laptop mode control script with XFS_HZ=100 Message-Id: <20040512010453.196fc8c9.akpm@osdl.org> In-Reply-To: <40A1D7E3.8020700@samwel.tk> References: <20040511154057.6d6c193b.akpm@osdl.org> <20040512090006.B362314@wobbly.melbourne.sgi.com> <40A1D7E3.8020700@samwel.tk> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 3104 X-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: 535 Lines: 14 Bart Samwel wrote: > > >>aargh. XFS is broken. It shouldn't be exposing jiffy-based tunables into > >>/proc, or `mount -o remount' or whatever. > >> > >>It would be much better to rework XFS so that these user-visible tunables > >>are in units of milliseconds, centiseconds or whatever. > > They're in USER_HZ since 2.6.6. Andrew, is that OK or should they really > be in some even more fixed unit? All architectures have USER_HZ=100. But it's a bit nicer and future-proof to relabel it as centiseconds. From owner-linux-xfs@oss.sgi.com Wed May 12 01:08:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 01:09:02 -0700 (PDT) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4C88iKO031807 for ; Wed, 12 May 2004 01:08:45 -0700 Received: from localhost ([127.0.0.1] helo=samwel.tk) by samwel.tk with esmtp (Exim 4.33) id 1BNon1-00032c-Ai; Wed, 12 May 2004 10:08:31 +0200 Message-ID: <40A1DB7B.2080600@samwel.tk> Date: Wed, 12 May 2004 10:08:27 +0200 From: Bart Samwel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: nl, en-us, en MIME-Version: 1.0 To: Andrew Morton CC: nathans@sgi.com, linux-xfs@oss.sgi.com Subject: Re: [patch 1/1] Update laptop mode control script with XFS_HZ=100 References: <20040511154057.6d6c193b.akpm@osdl.org> <20040512090006.B362314@wobbly.melbourne.sgi.com> <40A1D7E3.8020700@samwel.tk> <20040512010453.196fc8c9.akpm@osdl.org> In-Reply-To: <20040512010453.196fc8c9.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 3105 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 619 Lines: 20 Andrew Morton wrote: > Bart Samwel wrote: > >> >>aargh. XFS is broken. It shouldn't be exposing jiffy-based tunables into >> >>/proc, or `mount -o remount' or whatever. >> >> >> >>It would be much better to rework XFS so that these user-visible tunables >> >>are in units of milliseconds, centiseconds or whatever. >> >> They're in USER_HZ since 2.6.6. Andrew, is that OK or should they really >> be in some even more fixed unit? > > All architectures have USER_HZ=100. But it's a bit nicer and future-proof > to relabel it as centiseconds. Agreed. Nathan, I'll make a patch for this. --Bart From owner-linux-xfs@oss.sgi.com Wed May 12 01:54:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 01:55:03 -0700 (PDT) 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 i4C8seKO000741 for ; Wed, 12 May 2004 01:54:41 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i4B7V3T9026838 for ; Tue, 11 May 2004 02:31:04 -0500 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i4B7V2W25361 for linux-xfs@oss.sgi.com; Tue, 11 May 2004 17:31:02 +1000 Date: Tue, 11 May 2004 17:31:02 +1000 From: Nathan Scott Message-Id: <200405110731.i4B7V2W25361@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.6 X-archive-position: 3106 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 88435 Lines: 2681 This is without the 2.6.6 freeze changes in XFS at this stage, Christoph is hacking on those a bit more and will merge those pieces later when he's done there. cheers. Date: Mon May 10 22:57:47 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: akpm@osdl.org,torvalds@osdl.org The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:171518a CREDITS - 1.7 Documentation/Changes - 1.5 Documentation/CodingStyle - 1.3 Documentation/DMA-mapping.txt - 1.3 Documentation/DocBook/Makefile - 1.3 Documentation/DocBook/kernel-hacking.tmpl - 1.2 Documentation/DocBook/kernel-locking.tmpl - 1.5 Documentation/DocBook/lsm.tmpl - 1.2 Documentation/DocBook/mousedrivers.tmpl - 1.2 Documentation/DocBook/parportbook.tmpl - 1.3 Documentation/DocBook/sis900.tmpl - 1.2 Documentation/DocBook/via-audio.tmpl - 1.2 Documentation/DocBook/videobook.tmpl - 1.2 Documentation/IPMI.txt - 1.2 Documentation/SubmittingDrivers - 1.4 Documentation/SubmittingPatches - 1.4 Documentation/cciss.txt - 1.3 Documentation/early-userspace/README - 1.2 Documentation/filesystems/ntfs.txt - 1.3 Documentation/filesystems/proc.txt - 1.3 Documentation/firmware_class/README - 1.2 Documentation/firmware_class/hotplug-script - 1.2 Documentation/i2c/sysfs-interface - 1.4 Documentation/ide.txt - 1.4 Documentation/input/ff.txt - 1.2 Documentation/input/input.txt - 1.3 Documentation/input/joystick.txt - 1.3 Documentation/kernel-docs.txt - 1.2 Documentation/kernel-parameters.txt - 1.7 Documentation/mips/pci/pci.README - 1.2 Documentation/mips/time.README - 1.2 Documentation/networking/00-INDEX - 1.2 Documentation/networking/ip-sysctl.txt - 1.6 Documentation/s390/s390dbf.txt - 1.2 Documentation/sound/alsa/ALSA-Configuration.txt - 1.4 MAINTAINERS - 1.7 Makefile - 1.18 arch/alpha/kernel/irq.c - 1.4 arch/alpha/kernel/osf_sys.c - 1.3 arch/alpha/kernel/process.c - 1.2 arch/alpha/kernel/semaphore.c - 1.3 arch/alpha/kernel/systbls.S - 1.3 arch/alpha/kernel/traps.c - 1.3 arch/alpha/kernel/vmlinux.lds.S - 1.2 arch/alpha/lib/ev6-stxncpy.S - 1.2 arch/alpha/lib/stxncpy.S - 1.2 arch/arm/Kconfig - 1.5 arch/arm/Makefile - 1.5 arch/arm/boot/Makefile - 1.3 arch/arm/boot/compressed/Makefile - 1.4 arch/arm/boot/compressed/head.S - 1.4 arch/arm/boot/compressed/misc.c - 1.2 arch/arm/common/Makefile - 1.3 arch/arm/common/sa1111.c - 1.5 arch/arm/configs/assabet_defconfig - 1.3 arch/arm/configs/epxa10db_defconfig - 1.3 arch/arm/configs/lubbock_defconfig - 1.3 arch/arm/configs/neponset_defconfig - 1.3 arch/arm/kernel/armksyms.c - 1.5 arch/arm/kernel/bios32.c - 1.2 arch/arm/kernel/debug.S - 1.3 arch/arm/kernel/ecard.c - 1.2 arch/arm/kernel/entry-armv.S - 1.4 arch/arm/kernel/entry-common.S - 1.2 arch/arm/kernel/fiq.c - 1.3 arch/arm/kernel/process.c - 1.4 arch/arm/kernel/ptrace.c - 1.3 arch/arm/kernel/semaphore.c - 1.2 arch/arm/kernel/setup.c - 1.4 arch/arm/kernel/signal.c - 1.2 arch/arm/kernel/sys_arm.c - 1.4 arch/arm/kernel/traps.c - 1.3 arch/arm/kernel/vmlinux.lds.S - 1.3 arch/arm/lib/findbit.S - 1.2 arch/arm/lib/getuser.S - 1.2 arch/arm/lib/putuser.S - 1.2 arch/arm/mach-footbridge/Kconfig - 1.2 arch/arm/mach-pxa/idp.c - 1.3 arch/arm/mach-pxa/leds-lubbock.c - 1.2 arch/arm/mach-pxa/lubbock.c - 1.4 arch/arm/mach-sa1100/h3600.c - 1.2 arch/arm/mm/Kconfig - 1.5 arch/arm/mm/Makefile - 1.3 arch/arm/mm/alignment.c - 1.2 arch/arm/mm/consistent.c - 1.3 arch/arm/mm/discontig.c - 1.2 arch/arm/mm/fault-armv.c - 1.2 arch/arm/mm/fault.h - 1.2 arch/arm/mm/init.c - 1.2 arch/arm/mm/ioremap.c - 1.2 arch/arm/mm/minicache.c - 1.2 arch/arm/mm/mm-armv.c - 1.4 arch/arm/mm/mmu.c - 1.2 arch/arm/mm/proc-xscale.S - 1.2 arch/arm/mm/tlb-v4wbi.S - 1.2 arch/arm/tools/Makefile - 1.2 arch/arm/tools/mach-types - 1.4 arch/arm26/kernel/process.c - 1.3 arch/arm26/kernel/semaphore.c - 1.2 arch/arm26/kernel/traps.c - 1.2 arch/arm26/kernel/vmlinux-arm26-xip.lds.in - 1.2 arch/arm26/kernel/vmlinux-arm26.lds.in - 1.2 arch/arm26/machine/small_page.c - 1.2 arch/cris/arch-v10/kernel/process.c - 1.2 arch/cris/arch-v10/vmlinux.lds.S - 1.2 arch/cris/kernel/semaphore.c - 1.2 arch/cris/kernel/traps.c - 1.2 arch/h8300/Kconfig - 1.5 arch/h8300/kernel/asm-offsets.c - 1.2 arch/h8300/kernel/process.c - 1.2 arch/h8300/kernel/ptrace.c - 1.2 arch/h8300/kernel/semaphore.c - 1.2 arch/h8300/kernel/setup.c - 1.3 arch/h8300/kernel/traps.c - 1.2 arch/h8300/kernel/vmlinux.lds.S - 1.2 arch/h8300/platform/h8300h/Makefile - 1.4 arch/h8300/platform/h8300h/entry.S - 1.3 arch/h8300/platform/h8s/Makefile - 1.4 arch/h8300/platform/h8s/entry.S - 1.3 arch/i386/Kconfig - 1.10 arch/i386/Makefile - 1.6 arch/i386/kernel/Makefile - 1.5 arch/i386/kernel/acpi/boot.c - 1.9 arch/i386/kernel/apm.c - 1.5 arch/i386/kernel/cpu/common.c - 1.3 arch/i386/kernel/cpu/cpufreq/Kconfig - 1.4 arch/i386/kernel/cpu/cpufreq/acpi.c - 1.5 arch/i386/kernel/cpu/cpufreq/elanfreq.c - 1.3 arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.5 arch/i386/kernel/cpu/cpufreq/longrun.c - 1.3 arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.5 arch/i386/kernel/cpu/cpufreq/powernow-k6.c - 1.3 arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.5 arch/i386/kernel/cpu/cpufreq/powernow-k8.c - 1.5 arch/i386/kernel/cpu/cpufreq/powernow-k8.h - 1.3 arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c - 1.3 arch/i386/kernel/cpu/cpufreq/speedstep-ich.c - 1.3 arch/i386/kernel/cpu/cpufreq/speedstep-lib.c - 1.5 arch/i386/kernel/cpu/cpufreq/speedstep-smi.c - 1.4 arch/i386/kernel/cpu/cyrix.c - 1.2 arch/i386/kernel/cpu/mcheck/non-fatal.c - 1.4 arch/i386/kernel/dmi_scan.c - 1.5 arch/i386/kernel/doublefault.c - 1.2 arch/i386/kernel/entry.S - 1.8 arch/i386/kernel/head.S - 1.4 arch/i386/kernel/i387.c - 1.3 arch/i386/kernel/i8259.c - 1.9 arch/i386/kernel/io_apic.c - 1.11 arch/i386/kernel/irq.c - 1.4 arch/i386/kernel/mpparse.c - 1.8 arch/i386/kernel/nmi.c - 1.8 arch/i386/kernel/process.c - 1.6 arch/i386/kernel/ptrace.c - 1.2 arch/i386/kernel/semaphore.c - 1.3 arch/i386/kernel/setup.c - 1.7 arch/i386/kernel/signal.c - 1.3 arch/i386/kernel/smpboot.c - 1.9 arch/i386/kernel/timers/timer_tsc.c - 1.5 arch/i386/kernel/traps.c - 1.8 arch/i386/kernel/vmlinux.lds.S - 1.6 arch/i386/lib/usercopy.c - 1.3 arch/i386/mach-default/setup.c - 1.2 arch/i386/mach-es7000/setup.c - 1.2 arch/i386/mach-pc9800/Makefile - 1.3 arch/i386/mach-visws/mpparse.c - 1.2 arch/i386/mach-voyager/setup.c - 1.2 arch/i386/mach-voyager/voyager_smp.c - 1.4 arch/i386/mach-voyager/voyager_thread.c - 1.2 arch/i386/mm/hugetlbpage.c - 1.4 arch/i386/mm/init.c - 1.4 arch/i386/mm/pageattr.c - 1.2 arch/i386/mm/pgtable.c - 1.2 arch/i386/oprofile/nmi_int.c - 1.3 arch/i386/pci/acpi.c - 1.3 arch/i386/pci/fixup.c - 1.3 arch/i386/pci/irq.c - 1.5 arch/i386/pci/pcbios.c - 1.2 arch/i386/power/cpu.c - 1.2 arch/i386/power/swsusp.S - 1.2 arch/ia64/Kconfig - 1.7 arch/ia64/defconfig - 1.7 arch/ia64/hp/common/sba_iommu.c - 1.6 arch/ia64/hp/sim/Kconfig - 1.2 arch/ia64/hp/sim/simeth.c - 1.3 arch/ia64/hp/sim/simserial.c - 1.3 arch/ia64/ia32/binfmt_elf32.c - 1.4 arch/ia64/ia32/ia32_entry.S - 1.4 arch/ia64/ia32/ia32_signal.c - 1.3 arch/ia64/ia32/ia32priv.h - 1.3 arch/ia64/ia32/sys_ia32.c - 1.6 arch/ia64/kernel/Makefile - 1.5 arch/ia64/kernel/acpi.c - 1.9 arch/ia64/kernel/efi.c - 1.5 arch/ia64/kernel/entry.S - 1.4 arch/ia64/kernel/fsys.S - 1.2 arch/ia64/kernel/iosapic.c - 1.6 arch/ia64/kernel/irq_ia64.c - 1.5 arch/ia64/kernel/perfmon.c - 1.5 arch/ia64/kernel/perfmon_mckinley.h - 1.2 arch/ia64/kernel/process.c - 1.5 arch/ia64/kernel/semaphore.c - 1.2 arch/ia64/kernel/signal.c - 1.4 arch/ia64/kernel/sys_ia64.c - 1.3 arch/ia64/kernel/traps.c - 1.5 arch/ia64/kernel/unaligned.c - 1.5 arch/ia64/kernel/vmlinux.lds.S - 1.4 arch/ia64/mm/hugetlbpage.c - 1.5 arch/ia64/mm/init.c - 1.6 arch/ia64/pci/pci.c - 1.6 arch/ia64/sn/io/hwgfs/interface.c - 1.3 arch/ia64/sn/io/io.c - 1.5 arch/ia64/sn/io/machvec/pci_bus_cvlink.c - 1.5 arch/ia64/sn/io/machvec/pci_dma.c - 1.6 arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c - 1.5 arch/ia64/sn/kernel/irq.c - 1.6 arch/ia64/sn/kernel/setup.c - 1.7 arch/ia64/sn/kernel/sn2/sn2_smp.c - 1.6 arch/m68k/amiga/amiints.c - 1.3 arch/m68k/amiga/amisound.c - 1.3 arch/m68k/amiga/cia.c - 1.2 arch/m68k/amiga/config.c - 1.3 arch/m68k/apollo/config.c - 1.2 arch/m68k/atari/ataints.c - 1.2 arch/m68k/atari/config.c - 1.3 arch/m68k/atari/debug.c - 1.2 arch/m68k/atari/hades-pci.c - 1.3 arch/m68k/atari/stdma.c - 1.2 arch/m68k/atari/stram.c - 1.2 arch/m68k/bvme6000/rtc.c - 1.3 arch/m68k/hp300/ints.c - 1.2 arch/m68k/kernel/bios32.c - 1.2 arch/m68k/kernel/ints.c - 1.4 arch/m68k/kernel/process.c - 1.2 arch/m68k/kernel/ptrace.c - 1.2 arch/m68k/kernel/semaphore.c - 1.2 arch/m68k/kernel/setup.c - 1.3 arch/m68k/kernel/signal.c - 1.3 arch/m68k/kernel/time.c - 1.3 arch/m68k/kernel/traps.c - 1.4 arch/m68k/kernel/vmlinux-std.lds - 1.2 arch/m68k/kernel/vmlinux-sun3.lds - 1.2 arch/m68k/mac/config.c - 1.3 arch/m68k/mac/debug.c - 1.2 arch/m68k/mac/macboing.c - 1.2 arch/m68k/mac/macints.c - 1.4 arch/m68k/mac/via.c - 1.4 arch/m68k/mm/kmap.c - 1.2 arch/m68k/mm/memory.c - 1.2 arch/m68k/mm/motorola.c - 1.3 arch/m68k/mvme16x/rtc.c - 1.3 arch/m68k/q40/q40ints.c - 1.4 arch/m68k/sun3/leds.c - 1.2 arch/m68k/sun3/mmu_emu.c - 1.2 arch/m68k/sun3/sun3dvma.c - 1.2 arch/m68k/sun3/sun3ints.c - 1.3 arch/m68k/sun3x/prom.c - 1.2 arch/m68knommu/Kconfig - 1.3 arch/m68knommu/Makefile - 1.2 arch/m68knommu/kernel/Makefile - 1.3 arch/m68knommu/kernel/comempci.c - 1.2 arch/m68knommu/kernel/process.c - 1.2 arch/m68knommu/kernel/semaphore.c - 1.2 arch/m68knommu/kernel/setup.c - 1.2 arch/m68knommu/kernel/traps.c - 1.2 arch/m68knommu/kernel/vmlinux.lds.S - 1.2 arch/m68knommu/lib/divsi3.S - 1.2 arch/m68knommu/lib/modsi3.S - 1.2 arch/m68knommu/lib/mulsi3.S - 1.2 arch/m68knommu/lib/udivsi3.S - 1.2 arch/m68knommu/lib/umodsi3.S - 1.2 arch/m68knommu/mm/fault.c - 1.2 arch/m68knommu/mm/init.c - 1.2 arch/m68knommu/platform/5206/config.c - 1.2 arch/m68knommu/platform/5206e/config.c - 1.2 arch/m68knommu/platform/5249/config.c - 1.2 arch/m68knommu/platform/5272/MOTOROLA/crt0_ram.S - 1.2 arch/m68knommu/platform/5272/config.c - 1.2 arch/m68knommu/platform/5282/config.c - 1.2 arch/m68knommu/platform/5307/config.c - 1.2 arch/m68knommu/platform/5307/ints.c - 1.3 arch/m68knommu/platform/5307/timers.c - 1.2 arch/m68knommu/platform/5307/vectors.c - 1.2 arch/m68knommu/platform/5407/CLEOPATRA/crt0_ram.S - 1.2 arch/m68knommu/platform/5407/config.c - 1.2 arch/m68knommu/platform/68328/config.c - 1.2 arch/m68knommu/platform/68328/ints.c - 1.3 arch/m68knommu/platform/68360/commproc.c - 1.2 arch/m68knommu/platform/68360/config.c - 1.2 arch/m68knommu/platform/68360/ints.c - 1.3 arch/m68knommu/platform/68EZ328/config.c - 1.2 arch/m68knommu/platform/68VZ328/de2/config.c - 1.2 arch/m68knommu/platform/68VZ328/de2/crt0_ram.S - 1.2 arch/m68knommu/platform/68VZ328/ucdimm/config.c - 1.2 arch/mips/Kconfig - 1.6 arch/mips/Makefile - 1.3 arch/mips/au1000/common/Makefile - 1.3 arch/mips/au1000/common/dma.c - 1.3 arch/mips/au1000/common/irq.c - 1.3 arch/mips/au1000/common/power.c - 1.3 arch/mips/au1000/common/reset.c - 1.3 arch/mips/au1000/common/usbdev.c - 1.3 arch/mips/au1000/db1x00/Makefile - 1.3 arch/mips/baget/baget.c - 1.2 arch/mips/ddb5xxx/common/irq.c - 1.2 arch/mips/defconfig - 1.3 arch/mips/kernel/Makefile - 1.3 arch/mips/kernel/cpu-probe.c - 1.3 arch/mips/kernel/entry.S - 1.3 arch/mips/kernel/ioctl32.c - 1.3 arch/mips/kernel/irixelf.c - 1.2 arch/mips/kernel/linux32.c - 1.3 arch/mips/kernel/module-elf64.c - 1.3 arch/mips/kernel/proc.c - 1.3 arch/mips/kernel/process.c - 1.3 arch/mips/kernel/r2300_switch.S - 1.3 arch/mips/kernel/r4k_fpu.S - 1.3 arch/mips/kernel/r4k_switch.S - 1.3 arch/mips/kernel/scall64-n32.S - 1.3 arch/mips/kernel/semaphore.c - 1.3 arch/mips/kernel/signal.c - 1.3 arch/mips/kernel/signal32.c - 1.3 arch/mips/kernel/signal_n32.c - 1.3 arch/mips/kernel/syscall.c - 1.3 arch/mips/kernel/sysirix.c - 1.4 arch/mips/kernel/traps.c - 1.3 arch/mips/kernel/vmlinux.lds.S - 1.3 arch/mips/lasat/Makefile - 1.3 arch/mips/lasat/at93c.c - 1.2 arch/mips/lasat/ds1603.c - 1.2 arch/mips/lasat/image/Makefile - 1.2 arch/mips/lasat/interrupt.c - 1.3 arch/mips/lasat/lasatIRQ.S - 1.3 arch/mips/lasat/prom.c - 1.3 arch/mips/lasat/setup.c - 1.3 arch/mips/mm-32/tlbex-r4k.S - 1.3 arch/mips/mm-64/tlb-dbg-r4k.c - 1.2 arch/mips/mm-64/tlbex-r4k.S - 1.3 arch/mips/mm/Makefile - 1.4 arch/mips/mm/c-r3k.c - 1.3 arch/mips/mm/c-r4k.c - 1.3 arch/mips/mm/c-sb1.c - 1.3 arch/mips/mm/c-tx39.c - 1.3 arch/mips/mm/cache.c - 1.3 arch/mips/mm/cex-sb1.S - 1.3 arch/mips/mm/fault.c - 1.3 arch/mips/mm/highmem.c - 1.4 arch/mips/mm/ioremap.c - 1.2 arch/mips/mm/pgtable-64.c - 1.3 arch/mips/mm/sc-ip22.c - 1.2 arch/mips/mm/sc-r5k.c - 1.3 arch/mips/mm/sc-rm7k.c - 1.3 arch/mips/mm/tlb-andes.c - 1.3 arch/mips/mm/tlb-r4k.c - 1.3 arch/mips/momentum/ocelot_c/Makefile - 1.2 arch/mips/momentum/ocelot_c/irq.c - 1.3 arch/mips/momentum/ocelot_c/setup.c - 1.3 arch/mips/momentum/ocelot_g/setup.c - 1.3 arch/mips/pci/Makefile - 1.3 arch/mips/pci/fixup-au1000.c - 1.3 arch/mips/pci/ops-au1000.c - 1.3 arch/mips/pci/pci-ip27.c - 1.3 arch/mips/pci/pci-sb1250.c - 1.3 arch/mips/pci/pci-vr41xx.c - 1.3 arch/mips/sgi-ip27/Makefile - 1.3 arch/mips/sgi-ip27/ip27-init.c - 1.3 arch/mips/sgi-ip27/ip27-irq.c - 1.3 arch/mips/sgi-ip27/ip27-memory.c - 1.3 arch/mips/sgi-ip27/ip27-nmi.c - 1.3 arch/mips/sgi-ip27/ip27-timer.c - 1.3 arch/mips/sgi-ip32/Makefile - 1.3 arch/mips/sgi-ip32/ip32-irq.c - 1.3 arch/mips/sgi-ip32/ip32-setup.c - 1.3 arch/mips/sibyte/sb1250/smp.c - 1.3 arch/mips/sibyte/swarm/setup.c - 1.3 arch/mips/tx4927/common/Makefile - 1.3 arch/mips/vr41xx/casio-e55/Makefile - 1.3 arch/mips/vr41xx/casio-e55/setup.c - 1.3 arch/mips/vr41xx/common/Makefile - 1.3 arch/mips/vr41xx/common/cmu.c - 1.3 arch/mips/vr41xx/common/giu.c - 1.3 arch/mips/vr41xx/common/serial.c - 1.3 arch/mips/vr41xx/ibm-workpad/Makefile - 1.3 arch/mips/vr41xx/ibm-workpad/setup.c - 1.3 arch/mips/vr41xx/nec-eagle/Makefile - 1.3 arch/mips/vr41xx/nec-eagle/irq.c - 1.2 arch/mips/vr41xx/nec-eagle/setup.c - 1.3 arch/mips/vr41xx/tanbac-tb0226/Makefile - 1.2 arch/mips/vr41xx/tanbac-tb0226/setup.c - 1.3 arch/mips/vr41xx/tanbac-tb0229/Makefile - 1.3 arch/mips/vr41xx/tanbac-tb0229/setup.c - 1.3 arch/mips/vr41xx/victor-mpc30x/Makefile - 1.3 arch/mips/vr41xx/victor-mpc30x/setup.c - 1.3 arch/mips/vr41xx/zao-capcella/Makefile - 1.3 arch/mips/vr41xx/zao-capcella/setup.c - 1.3 arch/parisc/defconfig - 1.4 arch/parisc/kernel/cache.c - 1.3 arch/parisc/kernel/semaphore.c - 1.2 arch/parisc/kernel/sys_parisc32.c - 1.5 arch/parisc/kernel/traps.c - 1.3 arch/parisc/kernel/vmlinux.lds.S - 1.4 arch/ppc/4xx_io/serial_sicc.c - 1.2 arch/ppc/8260_io/uart.c - 1.3 arch/ppc/Kconfig - 1.7 arch/ppc/boot/images/Makefile - 1.2 arch/ppc/boot/openfirmware/Makefile - 1.3 arch/ppc/boot/simple/misc-embedded.c - 1.2 arch/ppc/boot/simple/misc.c - 1.4 arch/ppc/configs/adir_defconfig - 1.2 arch/ppc/configs/common_defconfig - 1.4 arch/ppc/configs/k2_defconfig - 1.2 arch/ppc/configs/lopec_defconfig - 1.2 arch/ppc/configs/mcpn765_defconfig - 1.2 arch/ppc/configs/pcore_defconfig - 1.2 arch/ppc/configs/pmac_defconfig - 1.4 arch/ppc/configs/prpmc750_defconfig - 1.2 arch/ppc/configs/prpmc800_defconfig - 1.2 arch/ppc/configs/sandpoint_defconfig - 1.2 arch/ppc/defconfig - 1.4 arch/ppc/kernel/cputable.c - 1.3 arch/ppc/kernel/head.S - 1.6 arch/ppc/kernel/head_44x.S - 1.4 arch/ppc/kernel/misc.S - 1.6 arch/ppc/kernel/process.c - 1.3 arch/ppc/kernel/semaphore.c - 1.2 arch/ppc/kernel/signal.c - 1.4 arch/ppc/kernel/vmlinux.lds.S - 1.2 arch/ppc/mm/hashtable.S - 1.3 arch/ppc/mm/pgtable.c - 1.4 arch/ppc/mm/ppc_mmu.c - 1.3 arch/ppc/platforms/Makefile - 1.5 arch/ppc/platforms/chrp_setup.c - 1.2 arch/ppc/platforms/gemini_setup.c - 1.2 arch/ppc/platforms/lopec_setup.c - 1.2 arch/ppc/platforms/mvme5100_setup.c - 1.2 arch/ppc/platforms/pmac_feature.c - 1.5 arch/ppc/platforms/pmac_nvram.c - 1.3 arch/ppc/platforms/prep_pci.c - 1.3 arch/ppc/platforms/prep_setup.c - 1.4 arch/ppc/platforms/prpmc750.h - 1.2 arch/ppc/platforms/prpmc800.h - 1.2 arch/ppc/platforms/sandpoint.c - 1.3 arch/ppc/syslib/Makefile - 1.4 arch/ppc/syslib/cpc710.h - 1.2 arch/ppc/syslib/harrier.c - 1.2 arch/ppc/syslib/open_pic.c - 1.4 arch/ppc64/Kconfig - 1.7 arch/ppc64/Makefile - 1.5 arch/ppc64/defconfig - 1.5 arch/ppc64/kernel/Makefile - 1.7 arch/ppc64/kernel/chrp_setup.c - 1.6 arch/ppc64/kernel/cputable.c - 1.5 arch/ppc64/kernel/eeh.c - 1.5 arch/ppc64/kernel/entry.S - 1.5 arch/ppc64/kernel/head.S - 1.8 arch/ppc64/kernel/i8259.c - 1.2 arch/ppc64/kernel/iSeries_irq.c - 1.4 arch/ppc64/kernel/iSeries_setup.h - 1.3 arch/ppc64/kernel/idle.c - 1.6 arch/ppc64/kernel/irq.c - 1.6 arch/ppc64/kernel/mf.c - 1.5 arch/ppc64/kernel/misc.S - 1.6 arch/ppc64/kernel/nvram.c - 1.4 arch/ppc64/kernel/open_pic.c - 1.5 arch/ppc64/kernel/open_pic.h - 1.3 arch/ppc64/kernel/pSeries_htab.c - 1.4 arch/ppc64/kernel/pSeries_lpar.c - 1.7 arch/ppc64/kernel/pSeries_pci.c - 1.7 arch/ppc64/kernel/pci_dn.c - 1.5 arch/ppc64/kernel/ppc_ksyms.c - 1.7 arch/ppc64/kernel/process.c - 1.7 arch/ppc64/kernel/prom.c - 1.8 arch/ppc64/kernel/ptrace.c - 1.2 arch/ppc64/kernel/ras.c - 1.5 arch/ppc64/kernel/rtas.c - 1.5 arch/ppc64/kernel/rtasd.c - 1.6 arch/ppc64/kernel/semaphore.c - 1.2 arch/ppc64/kernel/setup.c - 1.8 arch/ppc64/kernel/signal.c - 1.4 arch/ppc64/kernel/signal32.c - 1.5 arch/ppc64/kernel/smp.c - 1.7 arch/ppc64/kernel/stab.c - 1.5 arch/ppc64/kernel/sys_ppc32.c - 1.7 arch/ppc64/kernel/traps.c - 1.6 arch/ppc64/kernel/vmlinux.lds.S - 1.3 arch/ppc64/kernel/xics.c - 1.6 arch/ppc64/mm/fault.c - 1.3 arch/ppc64/mm/hugetlbpage.c - 1.7 arch/ppc64/mm/init.c - 1.6 arch/ppc64/mm/numa.c - 1.6 arch/ppc64/oprofile/Makefile - 1.2 arch/ppc64/xmon/start.c - 1.5 arch/ppc64/xmon/xmon.c - 1.7 arch/s390/Kconfig - 1.5 arch/s390/Makefile - 1.4 arch/s390/defconfig - 1.6 arch/s390/kernel/Makefile - 1.2 arch/s390/kernel/binfmt_elf32.c - 1.4 arch/s390/kernel/compat_exec.c - 1.2 arch/s390/kernel/compat_linux.c - 1.6 arch/s390/kernel/compat_signal.c - 1.4 arch/s390/kernel/compat_wrapper.S - 1.6 arch/s390/kernel/entry.S - 1.4 arch/s390/kernel/entry64.S - 1.4 arch/s390/kernel/process.c - 1.4 arch/s390/kernel/ptrace.c - 1.4 arch/s390/kernel/semaphore.c - 1.4 arch/s390/kernel/setup.c - 1.5 arch/s390/kernel/smp.c - 1.3 arch/s390/kernel/sys_s390.c - 1.5 arch/s390/kernel/syscalls.S - 1.5 arch/s390/kernel/time.c - 1.3 arch/s390/kernel/traps.c - 1.5 arch/s390/kernel/vmlinux.lds.S - 1.3 arch/sh/boards/dreamcast/rtc.c - 1.2 arch/sh/kernel/process.c - 1.5 arch/sh/kernel/semaphore.c - 1.2 arch/sh/kernel/traps.c - 1.4 arch/sh/kernel/vmlinux.lds.S - 1.2 arch/sparc/kernel/entry.S - 1.5 arch/sparc/kernel/process.c - 1.6 arch/sparc/kernel/semaphore.c - 1.3 arch/sparc/kernel/systbls.S - 1.2 arch/sparc/kernel/vmlinux.lds.S - 1.2 arch/sparc/lib/bitext.c - 1.2 arch/sparc/lib/rwsem.S - 1.2 arch/sparc/mm/init.c - 1.4 arch/sparc/mm/srmmu.c - 1.7 arch/sparc/mm/sun4c.c - 1.5 arch/sparc64/Kconfig - 1.7 arch/sparc64/Makefile - 1.2 arch/sparc64/defconfig - 1.7 arch/sparc64/kernel/binfmt_aout32.c - 1.2 arch/sparc64/kernel/binfmt_elf32.c - 1.3 arch/sparc64/kernel/entry.S - 1.3 arch/sparc64/kernel/ioctl32.c - 1.3 arch/sparc64/kernel/power.c - 1.4 arch/sparc64/kernel/process.c - 1.3 arch/sparc64/kernel/semaphore.c - 1.2 arch/sparc64/kernel/signal32.c - 1.3 arch/sparc64/kernel/smp.c - 1.5 arch/sparc64/kernel/sys32.S - 1.2 arch/sparc64/kernel/sys_sparc.c - 1.3 arch/sparc64/kernel/systbls.S - 1.4 arch/sparc64/kernel/traps.c - 1.4 arch/sparc64/kernel/vmlinux.lds.S - 1.2 arch/sparc64/lib/mcount.S - 1.2 arch/sparc64/lib/rwsem.c - 1.2 arch/sparc64/mm/hugetlbpage.c - 1.4 arch/sparc64/mm/init.c - 1.6 arch/sparc64/solaris/misc.c - 1.2 arch/um/Kconfig - 1.3 arch/um/kernel/sysrq.c - 1.2 arch/v850/kernel/process.c - 1.2 arch/v850/kernel/semaphore.c - 1.2 arch/v850/kernel/vmlinux.lds.S - 1.2 arch/x86_64/Kconfig - 1.6 arch/x86_64/Makefile - 1.5 arch/x86_64/boot/setup.S - 1.3 arch/x86_64/defconfig - 1.7 arch/x86_64/ia32/fpu32.c - 1.2 arch/x86_64/ia32/ia32_binfmt.c - 1.5 arch/x86_64/ia32/ia32_ioctl.c - 1.5 arch/x86_64/ia32/ia32_signal.c - 1.5 arch/x86_64/ia32/ia32entry.S - 1.5 arch/x86_64/ia32/ptrace32.c - 1.4 arch/x86_64/ia32/sys_ia32.c - 1.7 arch/x86_64/kernel/Makefile - 1.5 arch/x86_64/kernel/aperture.c - 1.4 arch/x86_64/kernel/entry.S - 1.5 arch/x86_64/kernel/i387.c - 1.3 arch/x86_64/kernel/i8259.c - 1.4 arch/x86_64/kernel/io_apic.c - 1.6 arch/x86_64/kernel/mpparse.c - 1.7 arch/x86_64/kernel/nmi.c - 1.4 arch/x86_64/kernel/pci-gart.c - 1.8 arch/x86_64/kernel/pci-nommu.c - 1.3 arch/x86_64/kernel/process.c - 1.6 arch/x86_64/kernel/ptrace.c - 1.2 arch/x86_64/kernel/semaphore.c - 1.2 arch/x86_64/kernel/setup.c - 1.6 arch/x86_64/kernel/setup64.c - 1.4 arch/x86_64/kernel/smpboot.c - 1.4 arch/x86_64/kernel/suspend.c - 1.2 arch/x86_64/kernel/traps.c - 1.6 arch/x86_64/kernel/vmlinux.lds.S - 1.3 arch/x86_64/kernel/x8664_ksyms.c - 1.5 arch/x86_64/lib/thunk.S - 1.3 arch/x86_64/mm/init.c - 1.5 arch/x86_64/mm/k8topology.c - 1.5 arch/x86_64/mm/numa.c - 1.3 crypto/Kconfig - 1.4 crypto/Makefile - 1.4 crypto/crypto_null.c - 1.2 crypto/des.c - 1.2 crypto/sha512.c - 1.3 crypto/tcrypt.c - 1.5 drivers/acpi/ac.c - 1.4 drivers/acpi/asus_acpi.c - 1.5 drivers/acpi/battery.c - 1.4 drivers/acpi/button.c - 1.4 drivers/acpi/events/evmisc.c - 1.4 drivers/acpi/fan.c - 1.4 drivers/acpi/osl.c - 1.6 drivers/acpi/pci_irq.c - 1.5 drivers/acpi/pci_link.c - 1.6 drivers/acpi/pci_root.c - 1.4 drivers/acpi/processor.c - 1.7 drivers/acpi/scan.c - 1.4 drivers/acpi/thermal.c - 1.4 drivers/acpi/toshiba_acpi.c - 1.5 drivers/atm/Kconfig - 1.2 drivers/atm/ambassador.c - 1.2 drivers/atm/fore200e.c - 1.4 drivers/atm/fore200e.h - 1.3 drivers/atm/lanai.c - 1.2 drivers/atm/nicstar.c - 1.4 drivers/base/Kconfig - 1.3 drivers/base/class.c - 1.6 drivers/base/firmware_class.c - 1.5 drivers/base/platform.c - 1.3 drivers/block/Kconfig.iosched - 1.2 drivers/block/Makefile - 1.4 drivers/block/as-iosched.c - 1.3 drivers/block/cciss.c - 1.5 drivers/block/cciss_scsi.c - 1.3 drivers/block/elevator.c - 1.4 drivers/block/floppy.c - 1.6 drivers/block/floppy98.c - 1.4 drivers/block/ll_rw_blk.c - 1.7 drivers/block/loop.c - 1.5 drivers/block/paride/Kconfig - 1.3 drivers/block/rd.c - 1.3 drivers/block/scsi_ioctl.c - 1.4 drivers/block/umem.c - 1.2 drivers/bluetooth/Kconfig - 1.4 drivers/bluetooth/bluecard_cs.c - 1.4 drivers/bluetooth/bt3c_cs.c - 1.4 drivers/bluetooth/btuart_cs.c - 1.4 drivers/bluetooth/dtl1_cs.c - 1.4 drivers/bluetooth/hci_uart.h - 1.3 drivers/bluetooth/hci_usb.c - 1.5 drivers/cdrom/cdrom.c - 1.6 drivers/cdrom/mcdx.c - 1.2 drivers/char/Kconfig - 1.6 drivers/char/agp/sis-agp.c - 1.3 drivers/char/agp/via-agp.c - 1.3 drivers/char/applicom.c - 1.3 drivers/char/drm/i810_dma.c - 1.2 drivers/char/drm/i830_dma.c - 1.2 drivers/char/drm/i830_drm.h - 1.2 drivers/char/drm/i830_drv.h - 1.2 drivers/char/drm/i830_irq.c - 1.2 drivers/char/dsp56k.c - 1.2 drivers/char/ftape/lowlevel/ftape-bsm.c - 1.2 drivers/char/ftape/lowlevel/ftape-bsm.h - 1.2 drivers/char/ftape/lowlevel/ftape-tracing.h - 1.2 drivers/char/ftape/zftape/zftape-eof.c - 1.2 drivers/char/ftape/zftape/zftape-init.c - 1.2 drivers/char/hw_random.c - 1.3 drivers/char/ipmi/Kconfig - 1.2 drivers/char/ipmi/Makefile - 1.2 drivers/char/ipmi/ipmi_devintf.c - 1.2 drivers/char/ipmi/ipmi_kcs_sm.c - 1.3 drivers/char/ipmi/ipmi_msghandler.c - 1.2 drivers/char/ipmi/ipmi_watchdog.c - 1.2 drivers/char/isicom.c - 1.3 drivers/char/istallion.c - 1.4 drivers/char/mem.c - 1.5 drivers/char/moxa.c - 1.4 drivers/char/mxser.c - 1.4 drivers/char/n_tty.c - 1.3 drivers/char/random.c - 1.3 drivers/char/rocket.c - 1.3 drivers/char/serial_tx3912.h - 1.2 drivers/char/sn_serial.c - 1.13 drivers/char/specialix.c - 1.4 drivers/char/stallion.c - 1.3 drivers/char/sx.c - 1.4 drivers/char/tipar.c - 1.3 drivers/char/tpqic02.c - 1.2 drivers/char/tty_io.c - 1.7 drivers/char/vc_screen.c - 1.2 drivers/char/vt.c - 1.6 drivers/char/vt_ioctl.c - 1.5 drivers/char/watchdog/Kconfig - 1.6 drivers/char/watchdog/Makefile - 1.5 drivers/char/watchdog/cpu5wdt.c - 1.5 drivers/char/watchdog/machzwd.c - 1.6 drivers/cpufreq/Kconfig - 1.4 drivers/cpufreq/cpufreq.c - 1.4 drivers/cpufreq/cpufreq_userspace.c - 1.3 drivers/i2c/busses/Kconfig - 1.6 drivers/i2c/busses/Makefile - 1.5 drivers/i2c/chips/Kconfig - 1.6 drivers/i2c/chips/Makefile - 1.6 drivers/i2c/chips/adm1021.c - 1.4 drivers/i2c/chips/eeprom.c - 1.4 drivers/i2c/chips/it87.c - 1.6 drivers/i2c/chips/lm75.c - 1.6 drivers/i2c/chips/lm78.c - 1.6 drivers/i2c/chips/lm85.c - 1.7 drivers/i2c/chips/via686a.c - 1.5 drivers/i2c/chips/w83781d.c - 1.5 drivers/i2c/i2c-dev.c - 1.5 drivers/ide/ide-cd.c - 1.9 drivers/ide/ide-cd.h - 1.3 drivers/ide/ide-disk.c - 1.6 drivers/ide/ide-io.c - 1.5 drivers/ide/ide-probe.c - 1.5 drivers/ide/ide-proc.c - 1.4 drivers/ide/ide-tape.c - 1.5 drivers/ide/ide.c - 1.11 drivers/ide/legacy/ali14xx.c - 1.2 drivers/ide/legacy/dtc2278.c - 1.2 drivers/ide/legacy/ht6560b.c - 1.2 drivers/ide/legacy/ide-cs.c - 1.3 drivers/ide/legacy/pdc4030.c - 1.4 drivers/ide/legacy/qd65xx.c - 1.2 drivers/ide/legacy/umc8672.c - 1.2 drivers/ide/pci/cmd64x.c - 1.6 drivers/ide/pci/generic.c - 1.5 drivers/ide/pci/generic.h - 1.2 drivers/ide/pci/hpt366.c - 1.6 drivers/ide/pci/serverworks.c - 1.6 drivers/ide/pci/via82cxxx.c - 1.5 drivers/ieee1394/Kconfig - 1.5 drivers/ieee1394/amdtp.c - 1.6 drivers/ieee1394/amdtp.h - 1.2 drivers/ieee1394/cmp.c - 1.3 drivers/ieee1394/csr.c - 1.4 drivers/ieee1394/dma.c - 1.5 drivers/ieee1394/dma.h - 1.4 drivers/ieee1394/dv1394-private.h - 1.2 drivers/ieee1394/dv1394.c - 1.6 drivers/ieee1394/dv1394.h - 1.2 drivers/ieee1394/eth1394.c - 1.6 drivers/ieee1394/highlevel.c - 1.7 drivers/ieee1394/highlevel.h - 1.5 drivers/ieee1394/hosts.c - 1.5 drivers/ieee1394/hosts.h - 1.5 drivers/ieee1394/ieee1394.h - 1.3 drivers/ieee1394/ieee1394_core.c - 1.6 drivers/ieee1394/ieee1394_core.h - 1.5 drivers/ieee1394/ieee1394_transactions.c - 1.4 drivers/ieee1394/ieee1394_types.h - 1.2 drivers/ieee1394/iso.c - 1.4 drivers/ieee1394/nodemgr.c - 1.4 drivers/ieee1394/nodemgr.h - 1.4 drivers/ieee1394/ohci1394.c - 1.6 drivers/ieee1394/ohci1394.h - 1.3 drivers/ieee1394/pcilynx.c - 1.4 drivers/ieee1394/pcilynx.h - 1.3 drivers/ieee1394/raw1394-private.h - 1.3 drivers/ieee1394/raw1394.c - 1.7 drivers/ieee1394/sbp2.c - 1.7 drivers/ieee1394/sbp2.h - 1.4 drivers/ieee1394/video1394.c - 1.7 drivers/ieee1394/video1394.h - 1.2 drivers/input/keyboard/amikbd.c - 1.3 drivers/input/mouse/Kconfig - 1.5 drivers/input/mouse/logips2pp.c - 1.4 drivers/input/mouse/logips2pp.h - 1.3 drivers/input/serio/Kconfig - 1.3 drivers/input/serio/Makefile - 1.3 drivers/input/serio/i8042-io.h - 1.3 drivers/input/serio/i8042.h - 1.2 drivers/input/serio/serio.c - 1.4 drivers/isdn/capi/capi.c - 1.4 drivers/isdn/capi/kcapi.c - 1.4 drivers/isdn/hardware/eicon/capifunc.c - 1.4 drivers/isdn/hardware/eicon/diva.c - 1.3 drivers/isdn/hardware/eicon/divasfunc.c - 1.2 drivers/isdn/hardware/eicon/divasmain.c - 1.5 drivers/isdn/hardware/eicon/idifunc.c - 1.3 drivers/isdn/hisax/st5481_b.c - 1.3 drivers/isdn/hisax/st5481_d.c - 1.3 drivers/isdn/hisax/st5481_init.c - 1.3 drivers/isdn/hisax/st5481_usb.c - 1.3 drivers/isdn/hysdn/hysdn_net.c - 1.2 drivers/isdn/i4l/Kconfig - 1.3 drivers/isdn/i4l/isdn_net.h - 1.3 drivers/isdn/i4l/isdn_ppp.c - 1.3 drivers/isdn/sc/Kconfig - 1.3 drivers/isdn/sc/ioctl.c - 1.3 drivers/macintosh/macserial.c - 1.3 drivers/md/dm-ioctl.c - 1.4 drivers/md/dm-stripe.c - 1.4 drivers/md/dm-table.c - 1.5 drivers/md/dm.c - 1.6 drivers/md/dm.h - 1.5 drivers/md/linear.c - 1.4 drivers/md/md.c - 1.6 drivers/md/multipath.c - 1.4 drivers/md/raid0.c - 1.5 drivers/md/raid1.c - 1.5 drivers/md/raid5.c - 1.7 drivers/media/Kconfig - 1.3 drivers/media/common/saa7146_fops.c - 1.4 drivers/media/common/saa7146_hlp.c - 1.5 drivers/media/common/saa7146_i2c.c - 1.3 drivers/media/common/saa7146_video.c - 1.6 drivers/media/dvb/Kconfig - 1.4 drivers/media/dvb/b2c2/skystar2.c - 1.4 drivers/media/dvb/dvb-core/Makefile - 1.2 drivers/media/dvb/dvb-core/dvb_demux.c - 1.4 drivers/media/dvb/dvb-core/dvb_frontend.c - 1.5 drivers/media/dvb/dvb-core/dvb_frontend.h - 1.2 drivers/media/dvb/dvb-core/dvb_ksyms.c - 1.3 drivers/media/dvb/dvb-core/dvb_net.c - 1.3 drivers/media/dvb/dvb-core/dvb_ringbuffer.c - 1.4 drivers/media/dvb/dvb-core/dvb_ringbuffer.h - 1.3 drivers/media/dvb/dvb-core/dvbdev.c - 1.2 drivers/media/dvb/dvb-core/dvbdev.h - 1.2 drivers/media/dvb/frontends/Kconfig - 1.4 drivers/media/dvb/frontends/alps_tdlb7.c - 1.4 drivers/media/dvb/frontends/alps_tdmb7.c - 1.5 drivers/media/dvb/frontends/at76c651.c - 1.3 drivers/media/dvb/frontends/cx24110.c - 1.3 drivers/media/dvb/frontends/dvb_dummy_fe.c - 1.2 drivers/media/dvb/frontends/grundig_29504-401.c - 1.2 drivers/media/dvb/frontends/grundig_29504-491.c - 1.2 drivers/media/dvb/frontends/mt312.c - 1.3 drivers/media/dvb/frontends/nxt6000.c - 1.5 drivers/media/dvb/frontends/sp887x.c - 1.5 drivers/media/dvb/frontends/stv0299.c - 1.4 drivers/media/dvb/frontends/tda1004x.c - 1.5 drivers/media/dvb/frontends/ves1820.c - 1.5 drivers/media/dvb/frontends/ves1x93.c - 1.4 drivers/media/dvb/ttpci/av7110.c - 1.5 drivers/media/dvb/ttpci/budget-av.c - 1.3 drivers/media/dvb/ttpci/budget-ci.c - 1.3 drivers/media/dvb/ttpci/budget-core.c - 1.2 drivers/media/dvb/ttpci/budget.c - 1.2 drivers/media/dvb/ttpci/budget.h - 1.3 drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c - 1.4 drivers/media/dvb/ttusb-dec/Kconfig - 1.4 drivers/media/dvb/ttusb-dec/ttusb_dec.c - 1.7 drivers/media/radio/Kconfig - 1.3 drivers/media/video/Kconfig - 1.5 drivers/media/video/bttv-cards.c - 1.3 drivers/media/video/bttv-driver.c - 1.3 drivers/media/video/bttvp.h - 1.3 drivers/media/video/dpc7146.c - 1.3 drivers/media/video/hexium_gemini.c - 1.3 drivers/media/video/hexium_orion.c - 1.3 drivers/media/video/msp3400.c - 1.4 drivers/media/video/mxb.c - 1.3 drivers/media/video/saa7134/Makefile - 1.3 drivers/media/video/saa7134/saa7134-cards.c - 1.4 drivers/media/video/saa7134/saa7134-core.c - 1.3 drivers/media/video/saa7134/saa7134-oss.c - 1.3 drivers/media/video/saa7134/saa7134-tvaudio.c - 1.4 drivers/media/video/saa7134/saa7134-video.c - 1.3 drivers/media/video/saa7134/saa7134.h - 1.4 drivers/media/video/tuner.c - 1.6 drivers/media/video/v4l1-compat.c - 1.4 drivers/media/video/videodev.c - 1.3 drivers/media/video/w9966.c - 1.4 drivers/media/video/zoran_procfs.c - 1.2 drivers/message/fusion/Makefile - 1.3 drivers/message/fusion/mptbase.c - 1.6 drivers/message/fusion/mptbase.h - 1.7 drivers/message/fusion/mptctl.c - 1.4 drivers/message/fusion/mptscsih.c - 1.7 drivers/message/fusion/mptscsih.h - 1.5 drivers/misc/Kconfig - 1.3 drivers/mtd/chips/cfi_cmdset_0001.c - 1.3 drivers/mtd/devices/Kconfig - 1.2 drivers/mtd/devices/blkmtd.c - 1.4 drivers/mtd/maps/Kconfig - 1.2 drivers/mtd/maps/lubbock-flash.c - 1.3 drivers/mtd/mtdconcat.c - 1.2 drivers/mtd/nand/Kconfig - 1.2 drivers/net/3c509.c - 1.4 drivers/net/3c515.c - 1.3 drivers/net/8139cp.c - 1.3 drivers/net/8139too.c - 1.5 drivers/net/8390.c - 1.5 drivers/net/8390.h - 1.4 drivers/net/Kconfig - 1.6 drivers/net/Makefile - 1.6 drivers/net/a2065.c - 1.6 drivers/net/amd8111e.c - 1.4 drivers/net/amd8111e.h - 1.2 drivers/net/arcnet/com20020-isa.c - 1.3 drivers/net/ariadne.c - 1.5 drivers/net/arm/etherh.c - 1.5 drivers/net/b44.c - 1.3 drivers/net/b44.h - 1.2 drivers/net/bagetlance.c - 1.4 drivers/net/declance.c - 1.4 drivers/net/dgrs.c - 1.3 drivers/net/dummy.c - 1.4 drivers/net/e1000/e1000.h - 1.4 drivers/net/e1000/e1000_ethtool.c - 1.4 drivers/net/e1000/e1000_hw.c - 1.3 drivers/net/e1000/e1000_hw.h - 1.4 drivers/net/e1000/e1000_main.c - 1.4 drivers/net/e1000/e1000_param.c - 1.3 drivers/net/fc/iph5526.c - 1.5 drivers/net/gt96100eth.c - 1.5 drivers/net/hamradio/baycom_par.c - 1.4 drivers/net/hydra.c - 1.6 drivers/net/ioc3-eth.c - 1.2 drivers/net/irda/ali-ircc.c - 1.6 drivers/net/irda/au1k_ir.c - 1.3 drivers/net/irda/donauboe.c - 1.3 drivers/net/irda/irda-usb.c - 1.3 drivers/net/irda/irport.c - 1.4 drivers/net/irda/nsc-ircc.c - 1.5 drivers/net/irda/sir_dev.c - 1.4 drivers/net/irda/sir_kthread.c - 1.3 drivers/net/irda/smsc-ircc2.c - 1.5 drivers/net/irda/via-ircc.c - 1.5 drivers/net/irda/vlsi_ir.c - 1.4 drivers/net/irda/w83977af_ir.c - 1.5 drivers/net/ixgb/ixgb.h - 1.2 drivers/net/ixgb/ixgb_main.c - 1.3 drivers/net/mace.c - 1.5 drivers/net/meth.c - 1.4 drivers/net/meth.h - 1.2 drivers/net/natsemi.c - 1.4 drivers/net/ne2k-pci.c - 1.5 drivers/net/net_init.c - 1.4 drivers/net/pcmcia/3c574_cs.c - 1.7 drivers/net/pcmcia/3c589_cs.c - 1.6 drivers/net/pcmcia/axnet_cs.c - 1.4 drivers/net/pcmcia/com20020_cs.c - 1.5 drivers/net/pcmcia/fmvj18x_cs.c - 1.6 drivers/net/pcmcia/ibmtr_cs.c - 1.5 drivers/net/pcmcia/nmclan_cs.c - 1.5 drivers/net/pcmcia/smc91c92_cs.c - 1.6 drivers/net/pcmcia/xirc2ps_cs.c - 1.5 drivers/net/pcnet32.c - 1.5 drivers/net/ppp_generic.c - 1.5 drivers/net/r8169.c - 1.3 drivers/net/rcpci45.c - 1.2 drivers/net/saa9730.c - 1.4 drivers/net/sb1250-mac.c - 1.5 drivers/net/sgiseeq.c - 1.4 drivers/net/sk98lin/skge.c - 1.8 drivers/net/sk_mca.c - 1.3 drivers/net/slip.c - 1.2 drivers/net/tc35815.c - 1.3 drivers/net/tg3.c - 1.7 drivers/net/tg3.h - 1.3 drivers/net/tokenring/3c359.c - 1.6 drivers/net/tokenring/abyss.c - 1.5 drivers/net/tokenring/lanstreamer.c - 1.2 drivers/net/tokenring/olympic.c - 1.5 drivers/net/tokenring/tmspci.c - 1.4 drivers/net/tulip/de2104x.c - 1.4 drivers/net/tulip/timer.c - 1.3 drivers/net/tulip/tulip_core.c - 1.4 drivers/net/via-rhine.c - 1.3 drivers/net/wan/cycx_drv.c - 1.3 drivers/net/wan/lapbether.c - 1.5 drivers/net/wan/lmc/lmc_proto.c - 1.2 drivers/net/wan/pc300_drv.c - 1.6 drivers/net/wan/sbni.c - 1.3 drivers/net/wan/sdla.c - 1.3 drivers/net/wireless/airo.c - 1.6 drivers/net/wireless/atmel.c - 1.6 drivers/net/wireless/atmel_cs.c - 1.4 drivers/net/wireless/orinoco.h - 1.2 drivers/net/wireless/orinoco_pci.c - 1.4 drivers/net/wireless/orinoco_plx.c - 1.3 drivers/net/wireless/orinoco_tmd.c - 1.3 drivers/net/wireless/strip.c - 1.4 drivers/net/zorro8390.c - 1.6 drivers/oprofile/oprofile_stats.c - 1.3 drivers/parport/Kconfig - 1.3 drivers/parport/parport_pc.c - 1.5 drivers/parport/procfs.c - 1.3 drivers/pci/Kconfig - 1.2 drivers/pci/Makefile - 1.4 drivers/pci/bus.c - 1.3 drivers/pci/hotplug/acpiphp_glue.c - 1.5 drivers/pci/hotplug/acpiphp_pci.c - 1.4 drivers/pci/hotplug/pci_hotplug.h - 1.4 drivers/pci/hotplug/pcihp_skeleton.c - 1.3 drivers/pci/pci-sysfs.c - 1.4 drivers/pci/pci.c - 1.4 drivers/pci/pci.h - 1.2 drivers/pci/probe.c - 1.9 drivers/pci/proc.c - 1.3 drivers/pci/quirks.c - 1.5 drivers/pcmcia/cistpl.c - 1.4 drivers/pcmcia/cs.c - 1.5 drivers/pcmcia/cs_internal.h - 1.3 drivers/pcmcia/i82365.c - 1.4 drivers/pcmcia/rsrc_mgr.c - 1.2 drivers/pcmcia/sa1100_pfs168.c - 1.2 drivers/pcmcia/sa1100_shannon.c - 1.2 drivers/pcmcia/sa1100_stork.c - 1.3 drivers/pcmcia/sa1100_yopy.c - 1.2 drivers/pcmcia/tcic.c - 1.3 drivers/pcmcia/ti113x.h - 1.2 drivers/pcmcia/yenta_socket.c - 1.4 drivers/pcmcia/yenta_socket.h - 1.2 drivers/pnp/interface.c - 1.2 drivers/pnp/isapnp/core.c - 1.4 drivers/pnp/manager.c - 1.3 drivers/pnp/pnpbios/proc.c - 1.2 drivers/pnp/pnpbios/rsparser.c - 1.3 drivers/s390/Kconfig - 1.3 drivers/s390/Makefile - 1.2 drivers/s390/block/dasd.c - 1.5 drivers/s390/block/dasd_3990_erp.c - 1.5 drivers/s390/block/dasd_eckd.c - 1.5 drivers/s390/block/dasd_fba.c - 1.3 drivers/s390/block/dasd_int.h - 1.5 drivers/s390/char/tape_34xx.c - 1.4 drivers/s390/char/tape_core.c - 1.5 drivers/s390/cio/ccwgroup.c - 1.5 drivers/s390/cio/chsc.c - 1.4 drivers/s390/cio/cio.c - 1.4 drivers/s390/cio/css.c - 1.4 drivers/s390/cio/device.c - 1.6 drivers/s390/cio/device.h - 1.4 drivers/s390/cio/device_fsm.c - 1.5 drivers/s390/cio/device_pgid.c - 1.4 drivers/s390/cio/qdio.c - 1.5 drivers/s390/net/Kconfig - 1.3 drivers/s390/net/Makefile - 1.3 drivers/s390/net/ctcmain.c - 1.5 drivers/s390/net/ctctty.c - 1.5 drivers/s390/net/iucv.c - 1.5 drivers/s390/net/lcs.c - 1.5 drivers/s390/net/netiucv.c - 1.5 drivers/s390/net/qeth.h - 1.4 drivers/s390/net/qeth_mpc.c - 1.2 drivers/s390/net/qeth_mpc.h - 1.3 drivers/s390/scsi/zfcp_aux.c - 1.4 drivers/s390/scsi/zfcp_ccw.c - 1.4 drivers/s390/scsi/zfcp_def.h - 1.4 drivers/s390/scsi/zfcp_erp.c - 1.5 drivers/s390/scsi/zfcp_ext.h - 1.4 drivers/s390/scsi/zfcp_fsf.c - 1.4 drivers/s390/scsi/zfcp_fsf.h - 1.4 drivers/s390/scsi/zfcp_qdio.c - 1.4 drivers/s390/scsi/zfcp_scsi.c - 1.4 drivers/s390/scsi/zfcp_sysfs_adapter.c - 1.4 drivers/s390/scsi/zfcp_sysfs_port.c - 1.4 drivers/s390/scsi/zfcp_sysfs_unit.c - 1.4 drivers/scsi/Kconfig - 1.8 drivers/scsi/Makefile - 1.6 drivers/scsi/aacraid/linit.c - 1.6 drivers/scsi/aic7xxx_old.c - 1.2 drivers/scsi/ata_piix.c - 1.6 drivers/scsi/atari_NCR5380.c - 1.2 drivers/scsi/dpt_i2o.c - 1.3 drivers/scsi/ide-scsi.c - 1.5 drivers/scsi/ips.c - 1.3 drivers/scsi/ips.h - 1.3 drivers/scsi/libata-core.c - 1.7 drivers/scsi/libata-scsi.c - 1.6 drivers/scsi/libata.h - 1.6 drivers/scsi/megaraid.c - 1.5 drivers/scsi/pcmcia/nsp_debug.c - 1.2 drivers/scsi/sata_promise.c - 1.6 drivers/scsi/scsi.c - 1.6 drivers/scsi/scsi_devinfo.c - 1.3 drivers/scsi/scsi_error.c - 1.5 drivers/scsi/scsi_lib.c - 1.5 drivers/scsi/scsi_scan.c - 1.4 drivers/scsi/scsi_sysfs.c - 1.4 drivers/scsi/sd.c - 1.5 drivers/scsi/sg.c - 1.6 drivers/scsi/sr.c - 1.7 drivers/scsi/sr.h - 1.2 drivers/scsi/sym53c8xx_2/sym_glue.c - 1.5 drivers/scsi/sym53c8xx_2/sym_glue.h - 1.4 drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.5 drivers/scsi/tmscsim.c - 1.4 drivers/serial/68328serial.c - 1.2 drivers/serial/8250.c - 1.13 drivers/serial/8250.h - 1.2 drivers/serial/8250_hcdp.c - 1.4 drivers/serial/8250_hcdp.h - 1.2 drivers/serial/8250_pci.c - 1.4 drivers/serial/Kconfig - 1.5 drivers/serial/Makefile - 1.4 drivers/serial/mcfserial.c - 1.3 drivers/serial/mcfserial.h - 1.2 drivers/serial/pmac_zilog.c - 1.6 drivers/serial/sa1100.c - 1.4 drivers/serial/serial_core.c - 1.7 drivers/serial/serial_cs.c - 1.3 drivers/serial/sunzilog.c - 1.4 drivers/serial/uart00.c - 1.2 drivers/tc/lk201.c - 1.2 drivers/tc/zs.c - 1.3 drivers/usb/Makefile - 1.6 drivers/usb/class/cdc-acm.c - 1.5 drivers/usb/core/config.c - 1.3 drivers/usb/core/devices.c - 1.2 drivers/usb/core/devio.c - 1.3 drivers/usb/core/driverfs.c - 1.4 drivers/usb/core/hcd-pci.c - 1.4 drivers/usb/core/hcd.c - 1.6 drivers/usb/core/hcd.h - 1.4 drivers/usb/core/hub.c - 1.7 drivers/usb/core/hub.h - 1.3 drivers/usb/core/inode.c - 1.2 drivers/usb/core/message.c - 1.6 drivers/usb/core/usb.c - 1.7 drivers/usb/core/usb.h - 1.3 drivers/usb/gadget/Kconfig - 1.5 drivers/usb/gadget/Makefile - 1.5 drivers/usb/gadget/ether.c - 1.7 drivers/usb/gadget/net2280.c - 1.6 drivers/usb/gadget/usbstring.c - 1.3 drivers/usb/gadget/zero.c - 1.5 drivers/usb/host/Kconfig - 1.3 drivers/usb/host/ehci-dbg.c - 1.5 drivers/usb/host/ehci-hcd.c - 1.6 drivers/usb/host/ehci-hub.c - 1.4 drivers/usb/host/ehci-q.c - 1.4 drivers/usb/host/ehci.h - 1.5 drivers/usb/host/ohci-hcd.c - 1.6 drivers/usb/host/ohci-q.c - 1.5 drivers/usb/host/uhci-debug.c - 1.3 drivers/usb/host/uhci-hcd.c - 1.7 drivers/usb/host/uhci-hcd.h - 1.5 drivers/usb/input/Kconfig - 1.4 drivers/usb/input/Makefile - 1.3 drivers/usb/input/aiptek.c - 1.4 drivers/usb/input/hiddev.c - 1.5 drivers/usb/input/kbtab.c - 1.4 drivers/usb/input/powermate.c - 1.3 drivers/usb/input/wacom.c - 1.4 drivers/usb/input/xpad.c - 1.3 drivers/usb/media/Kconfig - 1.6 drivers/usb/media/vicam.c - 1.2 drivers/usb/misc/Kconfig - 1.7 drivers/usb/misc/Makefile - 1.5 drivers/usb/misc/speedtch.c - 1.3 drivers/usb/misc/tiglusb.c - 1.3 drivers/usb/misc/usbtest.c - 1.5 drivers/usb/net/Kconfig - 1.5 drivers/usb/net/rtl8150.c - 1.3 drivers/usb/net/usbnet.c - 1.7 drivers/usb/serial/ftdi_sio.c - 1.6 drivers/usb/serial/ftdi_sio.h - 1.6 drivers/usb/serial/io_ti.c - 1.2 drivers/usb/serial/kobil_sct.c - 1.4 drivers/usb/serial/omninet.c - 1.2 drivers/usb/serial/pl2303.c - 1.5 drivers/usb/serial/visor.c - 1.6 drivers/usb/serial/whiteheat.c - 1.4 drivers/usb/storage/datafab.c - 1.4 drivers/usb/storage/dpcm.c - 1.2 drivers/usb/storage/scsiglue.c - 1.6 drivers/usb/storage/transport.c - 1.6 drivers/usb/storage/unusual_devs.h - 1.8 drivers/usb/storage/usb.c - 1.5 drivers/usb/usb-skeleton.c - 1.3 drivers/video/Kconfig - 1.9 drivers/video/acornfb.c - 1.4 drivers/video/aty/aty128fb.c - 1.4 drivers/video/bw2.c - 1.2 drivers/video/cg14.c - 1.2 drivers/video/cg3.c - 1.2 drivers/video/cg6.c - 1.2 drivers/video/console/mdacon.c - 1.2 drivers/video/fbcmap.c - 1.3 drivers/video/fbmem.c - 1.9 drivers/video/ffb.c - 1.3 drivers/video/leo.c - 1.2 drivers/video/pm2fb.c - 1.4 drivers/video/sa1100fb.c - 1.4 drivers/video/tcx.c - 1.2 drivers/video/vga16fb.c - 1.3 drivers/zorro/Makefile - 1.3 fs/Kconfig - 1.12 fs/Kconfig.binfmt - 1.5 fs/Makefile - 1.4 fs/adfs/super.c - 1.4 fs/affs/super.c - 1.3 fs/binfmt_aout.c - 1.2 fs/binfmt_elf.c - 1.7 fs/binfmt_misc.c - 1.3 fs/binfmt_som.c - 1.3 fs/block_dev.c - 1.6 fs/buffer.c - 1.6 fs/cifs/AUTHORS - 1.2 fs/cifs/CHANGES - 1.2 fs/cifs/Makefile - 1.2 fs/cifs/README - 1.2 fs/cifs/TODO - 1.2 fs/cifs/cifs_debug.c - 1.2 fs/cifs/cifs_unicode.c - 1.2 fs/cifs/cifs_unicode.h - 1.2 fs/cifs/cifsencrypt.c - 1.2 fs/cifs/cifsfs.c - 1.3 fs/cifs/cifsfs.h - 1.2 fs/cifs/cifsglob.h - 1.2 fs/cifs/cifspdu.h - 1.2 fs/cifs/cifsproto.h - 1.2 fs/cifs/cifssmb.c - 1.2 fs/cifs/connect.c - 1.3 fs/cifs/dir.c - 1.2 fs/cifs/file.c - 1.3 fs/cifs/inode.c - 1.2 fs/cifs/link.c - 1.2 fs/cifs/md4.c - 1.2 fs/cifs/misc.c - 1.2 fs/cifs/netmisc.c - 1.2 fs/cifs/smbdes.c - 1.2 fs/cifs/smbencrypt.c - 1.2 fs/cifs/transport.c - 1.2 fs/coda/inode.c - 1.4 fs/coda/psdev.c - 1.2 fs/compat.c - 1.5 fs/compat_ioctl.c - 1.8 fs/cramfs/inode.c - 1.5 fs/dcache.c - 1.6 fs/devfs/base.c - 1.5 fs/devfs/util.c - 1.3 fs/direct-io.c - 1.3 fs/dnotify.c - 1.3 fs/dquot.c - 1.4 fs/efs/super.c - 1.3 fs/eventpoll.c - 1.5 fs/exec.c - 1.5 fs/ext2/fsync.c - 1.2 fs/ext2/inode.c - 1.3 fs/ext2/super.c - 1.4 fs/ext3/fsync.c - 1.2 fs/ext3/inode.c - 1.3 fs/ext3/namei.c - 1.3 fs/ext3/super.c - 1.5 fs/fat/file.c - 1.3 fs/fat/inode.c - 1.4 fs/fat/misc.c - 1.3 fs/fcntl.c - 1.5 fs/file_table.c - 1.5 fs/freevxfs/vxfs_super.c - 1.6 fs/fs-writeback.c - 1.6 fs/hfs/inode.c - 1.3 fs/hfs/super.c - 1.4 fs/hugetlbfs/inode.c - 1.5 fs/inode.c - 1.4 fs/intermezzo/vfs.c - 1.4 fs/isofs/inode.c - 1.3 fs/isofs/rock.c - 1.2 fs/jbd/commit.c - 1.3 fs/jbd/journal.c - 1.2 fs/jbd/revoke.c - 1.2 fs/jbd/transaction.c - 1.3 fs/jffs/inode-v23.c - 1.4 fs/jffs2/fs.c - 1.2 fs/jffs2/super.c - 1.3 fs/jfs/inode.c - 1.3 fs/jfs/jfs_dtree.c - 1.4 fs/jfs/jfs_logmgr.c - 1.5 fs/jfs/jfs_txnmgr.c - 1.5 fs/jfs/jfs_unicode.c - 1.3 fs/jfs/namei.c - 1.5 fs/lockd/clntlock.c - 1.3 fs/lockd/clntproc.c - 1.4 fs/locks.c - 1.5 fs/mpage.c - 1.2 fs/msdos/Makefile - 1.2 fs/msdos/namei.c - 1.3 fs/namei.c - 1.6 fs/namespace.c - 1.4 fs/ncpfs/inode.c - 1.4 fs/ncpfs/sock.c - 1.3 fs/nfs/direct.c - 1.3 fs/nfs/file.c - 1.5 fs/nfs/inode.c - 1.5 fs/nfs/nfs2xdr.c - 1.3 fs/nfs/nfs3proc.c - 1.4 fs/nfs/nfs3xdr.c - 1.3 fs/nfs/nfs4proc.c - 1.4 fs/nfs/nfs4state.c - 1.4 fs/nfs/nfs4xdr.c - 1.4 fs/nfs/nfsroot.c - 1.3 fs/nfs/pagelist.c - 1.3 fs/nfs/proc.c - 1.4 fs/nfs/read.c - 1.3 fs/nfs/write.c - 1.4 fs/nfsd/nfs4proc.c - 1.3 fs/nfsd/nfs4state.c - 1.3 fs/nfsd/nfs4xdr.c - 1.3 fs/ntfs/ChangeLog - 1.3 fs/ntfs/Makefile - 1.3 fs/ntfs/aops.c - 1.2 fs/ntfs/attrib.c - 1.2 fs/ntfs/compress.c - 1.2 fs/ntfs/dir.c - 1.2 fs/ntfs/inode.c - 1.3 fs/ntfs/inode.h - 1.2 fs/ntfs/layout.h - 1.2 fs/ntfs/malloc.h - 1.2 fs/ntfs/mft.h - 1.2 fs/ntfs/mst.c - 1.2 fs/ntfs/namei.c - 1.2 fs/ntfs/ntfs.h - 1.3 fs/ntfs/super.c - 1.2 fs/ntfs/types.h - 1.2 fs/ntfs/unistr.c - 1.2 fs/ntfs/volume.h - 1.2 fs/open.c - 1.5 fs/openpromfs/inode.c - 1.3 fs/proc/array.c - 1.3 fs/proc/base.c - 1.6 fs/proc/generic.c - 1.4 fs/proc/inode-alloc.txt - 1.2 fs/proc/inode.c - 1.3 fs/proc/proc_tty.c - 1.3 fs/proc/task_nommu.c - 1.2 fs/qnx4/inode.c - 1.2 fs/quota.c - 1.2 fs/quota_v1.c - 1.2 fs/quota_v2.c - 1.2 fs/read_write.c - 1.4 fs/reiserfs/do_balan.c - 1.2 fs/reiserfs/file.c - 1.4 fs/reiserfs/fix_node.c - 1.3 fs/reiserfs/ibalance.c - 1.2 fs/reiserfs/inode.c - 1.4 fs/reiserfs/ioctl.c - 1.2 fs/reiserfs/journal.c - 1.5 fs/reiserfs/namei.c - 1.3 fs/reiserfs/objectid.c - 1.2 fs/reiserfs/prints.c - 1.3 fs/reiserfs/procfs.c - 1.3 fs/reiserfs/super.c - 1.3 fs/reiserfs/tail_conversion.c - 1.2 fs/romfs/inode.c - 1.3 fs/seq_file.c - 1.2 fs/smbfs/file.c - 1.4 fs/smbfs/inode.c - 1.3 fs/stat.c - 1.6 fs/super.c - 1.5 fs/sysfs/bin.c - 1.2 fs/sysfs/symlink.c - 1.2 fs/sysv/inode.c - 1.2 fs/sysv/super.c - 1.2 fs/sysv/sysv.h - 1.2 fs/udf/super.c - 1.4 fs/ufs/dir.c - 1.3 fs/ufs/inode.c - 1.3 fs/ufs/super.c - 1.4 fs/ufs/truncate.c - 1.2 fs/vfat/Makefile - 1.2 fs/vfat/namei.c - 1.3 fs/xattr_acl.c - 1.2 include/acpi/acpiosxf.h - 1.3 include/asm-alpha/hdreg.h - 1.2 include/asm-alpha/ide.h - 1.2 include/asm-alpha/irq.h - 1.2 include/asm-alpha/pgalloc.h - 1.2 include/asm-alpha/unistd.h - 1.4 include/asm-arm/arch-adifcc/vmalloc.h - 1.2 include/asm-arm/arch-cl7500/ide.h - 1.2 include/asm-arm/arch-cl7500/vmalloc.h - 1.2 include/asm-arm/arch-clps711x/vmalloc.h - 1.2 include/asm-arm/arch-ebsa110/vmalloc.h - 1.2 include/asm-arm/arch-ebsa285/ide.h - 1.2 include/asm-arm/arch-ebsa285/vmalloc.h - 1.2 include/asm-arm/arch-epxa10db/vmalloc.h - 1.2 include/asm-arm/arch-integrator/vmalloc.h - 1.2 include/asm-arm/arch-iop3xx/ide.h - 1.2 include/asm-arm/arch-iop3xx/vmalloc.h - 1.2 include/asm-arm/arch-l7200/ide.h - 1.2 include/asm-arm/arch-l7200/vmalloc.h - 1.2 include/asm-arm/arch-nexuspci/ide.h - 1.2 include/asm-arm/arch-nexuspci/vmalloc.h - 1.2 include/asm-arm/arch-pxa/ide.h - 1.2 include/asm-arm/arch-pxa/lubbock.h - 1.2 include/asm-arm/arch-pxa/memory.h - 1.2 include/asm-arm/arch-pxa/pxa-regs.h - 1.2 include/asm-arm/arch-pxa/vmalloc.h - 1.2 include/asm-arm/arch-rpc/ide.h - 1.2 include/asm-arm/arch-rpc/vmalloc.h - 1.2 include/asm-arm/arch-sa1100/ide.h - 1.2 include/asm-arm/arch-sa1100/vmalloc.h - 1.2 include/asm-arm/arch-shark/ide.h - 1.2 include/asm-arm/arch-shark/vmalloc.h - 1.2 include/asm-arm/arch-tbox/vmalloc.h - 1.2 include/asm-arm/atomic.h - 1.3 include/asm-arm/bitops.h - 1.3 include/asm-arm/cacheflush.h - 1.4 include/asm-arm/div64.h - 1.3 include/asm-arm/dma-mapping.h - 1.4 include/asm-arm/ecard.h - 1.2 include/asm-arm/hardirq.h - 1.3 include/asm-arm/hdreg.h - 1.2 include/asm-arm/ide.h - 1.2 include/asm-arm/irq.h - 1.2 include/asm-arm/memory.h - 1.2 include/asm-arm/numnodes.h - 1.2 include/asm-arm/pgtable.h - 1.3 include/asm-arm/proc-fns.h - 1.3 include/asm-arm/setup.h - 1.3 include/asm-arm/shmparam.h - 1.3 include/asm-arm/system.h - 1.4 include/asm-arm/thread_info.h - 1.4 include/asm-arm/tlb.h - 1.3 include/asm-arm/uaccess.h - 1.2 include/asm-arm26/hdreg.h - 1.2 include/asm-arm26/ide.h - 1.2 include/asm-arm26/irq.h - 1.2 include/asm-cris/bitops.h - 1.2 include/asm-cris/irq.h - 1.2 include/asm-generic/cpumask_arith.h - 1.3 include/asm-generic/cpumask_array.h - 1.3 include/asm-generic/dma-mapping.h - 1.3 include/asm-generic/rmap.h - 1.2 include/asm-generic/siginfo.h - 1.3 include/asm-generic/vmlinux.lds.h - 1.2 include/asm-h8300/hdreg.h - 1.2 include/asm-h8300/ide.h - 1.3 include/asm-h8300/io.h - 1.4 include/asm-h8300/irq.h - 1.3 include/asm-h8300/processor.h - 1.3 include/asm-h8300/ptrace.h - 1.2 include/asm-h8300/regs306x.h - 1.2 include/asm-i386/acpi.h - 1.6 include/asm-i386/apic.h - 1.3 include/asm-i386/bitops.h - 1.2 include/asm-i386/hdreg.h - 1.2 include/asm-i386/hw_irq.h - 1.4 include/asm-i386/i387.h - 1.2 include/asm-i386/ide.h - 1.2 include/asm-i386/irq.h - 1.3 include/asm-i386/mach-bigsmp/mach_apic.h - 1.3 include/asm-i386/mach-default/irq_vectors.h - 1.7 include/asm-i386/mach-generic/mach_mpspec.h - 1.2 include/asm-i386/mach-summit/mach_mpspec.h - 1.2 include/asm-i386/module.h - 1.4 include/asm-i386/mpspec.h - 1.4 include/asm-i386/pgtable.h - 1.4 include/asm-i386/processor.h - 1.4 include/asm-i386/thread_info.h - 1.3 include/asm-i386/uaccess.h - 1.2 include/asm-i386/unistd.h - 1.5 include/asm-ia64/acpi.h - 1.6 include/asm-ia64/bitops.h - 1.2 include/asm-ia64/hdreg.h - 1.2 include/asm-ia64/hw_irq.h - 1.2 include/asm-ia64/ia32.h - 1.3 include/asm-ia64/ide.h - 1.2 include/asm-ia64/irq.h - 1.2 include/asm-ia64/machvec_hpzx1.h - 1.3 include/asm-ia64/perfmon.h - 1.2 include/asm-ia64/pgtable.h - 1.4 include/asm-ia64/processor.h - 1.7 include/asm-ia64/siginfo.h - 1.3 include/asm-ia64/sn/sn_sal.h - 1.4 include/asm-ia64/unistd.h - 1.4 include/asm-m68k/bitops.h - 1.4 include/asm-m68k/hdreg.h - 1.2 include/asm-m68k/ide.h - 1.2 include/asm-m68k/io.h - 1.4 include/asm-m68k/irq.h - 1.4 include/asm-m68k/raw_io.h - 1.2 include/asm-m68k/sun3mmu.h - 1.3 include/asm-m68k/tlbflush.h - 1.3 include/asm-m68k/traps.h - 1.2 include/asm-m68knommu/coldfire.h - 1.2 include/asm-m68knommu/dma-mapping.h - 1.2 include/asm-m68knommu/ide.h - 1.2 include/asm-m68knommu/irq.h - 1.3 include/asm-mips/asm.h - 1.3 include/asm-mips/bitops.h - 1.3 include/asm-mips/bootinfo.h - 1.3 include/asm-mips/cacheflush.h - 1.3 include/asm-mips/dma-mapping.h - 1.5 include/asm-mips/hardirq.h - 1.3 include/asm-mips/hdreg.h - 1.2 include/asm-mips/highmem.h - 1.3 include/asm-mips/ip32/ip32_ints.h - 1.2 include/asm-mips/ip32/mace.h - 1.3 include/asm-mips/irq.h - 1.3 include/asm-mips/lasat/lasat.h - 1.2 include/asm-mips/mipsregs.h - 1.3 include/asm-mips/mmu_context.h - 1.3 include/asm-mips/module.h - 1.2 include/asm-mips/mv64340.h - 1.3 include/asm-mips/page.h - 1.3 include/asm-mips/pgalloc.h - 1.3 include/asm-mips/pgtable-64.h - 1.3 include/asm-mips/processor.h - 1.3 include/asm-mips/serial.h - 1.3 include/asm-mips/sibyte/board.h - 1.3 include/asm-mips/siginfo.h - 1.3 include/asm-mips/smp.h - 1.4 include/asm-mips/sn/agent.h - 1.2 include/asm-mips/sn/arch.h - 1.3 include/asm-mips/sn/io.h - 1.2 include/asm-mips/sn/sn0/arch.h - 1.2 include/asm-mips/sn/sn_private.h - 1.3 include/asm-mips/spinlock.h - 1.3 include/asm-mips/stackframe.h - 1.3 include/asm-mips/topology.h - 1.3 include/asm-mips/uaccess.h - 1.3 include/asm-mips/unistd.h - 1.3 include/asm-mips/vr41xx/e55.h - 1.2 include/asm-mips/vr41xx/vr41xx.h - 1.3 include/asm-mips/vr41xx/workpad.h - 1.3 include/asm-mips/war.h - 1.3 include/asm-parisc/cacheflush.h - 1.2 include/asm-parisc/hdreg.h - 1.2 include/asm-parisc/ide.h - 1.3 include/asm-parisc/irq.h - 1.2 include/asm-ppc/cputable.h - 1.3 include/asm-ppc/dma-mapping.h - 1.3 include/asm-ppc/elf.h - 1.3 include/asm-ppc/harrier.h - 1.2 include/asm-ppc/hdreg.h - 1.2 include/asm-ppc/highmem.h - 1.4 include/asm-ppc/ide.h - 1.2 include/asm-ppc/irq.h - 1.2 include/asm-ppc/open_pic.h - 1.3 include/asm-ppc/page.h - 1.2 include/asm-ppc/pci.h - 1.6 include/asm-ppc/processor.h - 1.2 include/asm-ppc/rwsem.h - 1.2 include/asm-ppc/unistd.h - 1.5 include/asm-ppc64/cacheflush.h - 1.3 include/asm-ppc64/cputable.h - 1.4 include/asm-ppc64/dma-mapping.h - 1.3 include/asm-ppc64/eeh.h - 1.4 include/asm-ppc64/hdreg.h - 1.2 include/asm-ppc64/hw_irq.h - 1.3 include/asm-ppc64/ide.h - 1.2 include/asm-ppc64/irq.h - 1.4 include/asm-ppc64/machdep.h - 1.6 include/asm-ppc64/mmu.h - 1.5 include/asm-ppc64/mmzone.h - 1.5 include/asm-ppc64/naca.h - 1.3 include/asm-ppc64/paca.h - 1.5 include/asm-ppc64/page.h - 1.5 include/asm-ppc64/pci-bridge.h - 1.3 include/asm-ppc64/pci.h - 1.7 include/asm-ppc64/pgalloc.h - 1.3 include/asm-ppc64/pgtable.h - 1.5 include/asm-ppc64/ppc32.h - 1.3 include/asm-ppc64/processor.h - 1.6 include/asm-ppc64/prom.h - 1.6 include/asm-ppc64/rtas.h - 1.4 include/asm-ppc64/smp.h - 1.5 include/asm-ppc64/system.h - 1.5 include/asm-ppc64/thread_info.h - 1.3 include/asm-ppc64/uaccess.h - 1.3 include/asm-ppc64/unistd.h - 1.5 include/asm-s390/cache.h - 1.2 include/asm-s390/elf.h - 1.3 include/asm-s390/irq.h - 1.2 include/asm-s390/pgalloc.h - 1.4 include/asm-s390/processor.h - 1.4 include/asm-s390/spinlock.h - 1.5 include/asm-s390/thread_info.h - 1.2 include/asm-s390/unistd.h - 1.5 include/asm-sh/hdreg.h - 1.2 include/asm-sh/ide.h - 1.2 include/asm-sh/irq.h - 1.4 include/asm-sh/pgalloc.h - 1.3 include/asm-sparc/bitext.h - 1.2 include/asm-sparc/hdreg.h - 1.2 include/asm-sparc/ide.h - 1.3 include/asm-sparc/irq.h - 1.2 include/asm-sparc/pgtable.h - 1.4 include/asm-sparc/pgtsrmmu.h - 1.4 include/asm-sparc/pgtsun4c.h - 1.2 include/asm-sparc/unistd.h - 1.5 include/asm-sparc64/hdreg.h - 1.2 include/asm-sparc64/ide.h - 1.3 include/asm-sparc64/irq.h - 1.2 include/asm-sparc64/mmu_context.h - 1.2 include/asm-sparc64/pgalloc.h - 1.3 include/asm-sparc64/pgtable.h - 1.3 include/asm-sparc64/siginfo.h - 1.3 include/asm-sparc64/system.h - 1.2 include/asm-sparc64/unistd.h - 1.5 include/asm-um/irq.h - 1.2 include/asm-v850/bitops.h - 1.2 include/asm-v850/dma-mapping.h - 1.2 include/asm-v850/irq.h - 1.2 include/asm-v850/rte_me2_cb.h - 1.2 include/asm-x86_64/acpi.h - 1.6 include/asm-x86_64/apic.h - 1.4 include/asm-x86_64/apicdef.h - 1.2 include/asm-x86_64/bitops.h - 1.4 include/asm-x86_64/bootsetup.h - 1.2 include/asm-x86_64/hdreg.h - 1.2 include/asm-x86_64/i387.h - 1.2 include/asm-x86_64/ia32_unistd.h - 1.2 include/asm-x86_64/ide.h - 1.2 include/asm-x86_64/irq.h - 1.3 include/asm-x86_64/mpspec.h - 1.3 include/asm-x86_64/numa.h - 1.2 include/asm-x86_64/pci.h - 1.6 include/asm-x86_64/processor.h - 1.5 include/asm-x86_64/proto.h - 1.5 include/asm-x86_64/smp.h - 1.6 include/asm-x86_64/thread_info.h - 1.4 include/asm-x86_64/topology.h - 1.3 include/asm-x86_64/types.h - 1.3 include/asm-x86_64/unistd.h - 1.5 include/linux/acpi.h - 1.4 include/linux/ata.h - 1.3 include/linux/atmdev.h - 1.3 include/linux/backing-dev.h - 1.2 include/linux/binfmts.h - 1.2 include/linux/bio.h - 1.5 include/linux/bitmap.h - 1.5 include/linux/bitops.h - 1.2 include/linux/blkdev.h - 1.7 include/linux/buffer_head.h - 1.3 include/linux/cciss_ioctl.h - 1.2 include/linux/compat.h - 1.6 include/linux/compat_ioctl.h - 1.7 include/linux/compiler-gcc3.h - 1.4 include/linux/compiler.h - 1.6 include/linux/cpufreq.h - 1.4 include/linux/dcache.h - 1.3 include/linux/devfs_fs.h - 1.2 include/linux/devfs_fs_kernel.h - 1.2 include/linux/device.h - 1.6 include/linux/divert.h - 1.2 include/linux/dm-ioctl.h - 1.4 include/linux/dma-mapping.h - 1.3 include/linux/dvb/frontend.h - 1.2 include/linux/dvb/net.h - 1.2 include/linux/efi.h - 1.5 include/linux/elevator.h - 1.3 include/linux/elf.h - 1.2 include/linux/etherdevice.h - 1.3 include/linux/ext3_fs_sb.h - 1.3 include/linux/ext3_jbd.h - 1.3 include/linux/fd.h - 1.2 include/linux/file.h - 1.2 include/linux/fs.h - 1.7 include/linux/gfp.h - 1.2 include/linux/hugetlb.h - 1.5 include/linux/icmpv6.h - 1.2 include/linux/ide.h - 1.12 include/linux/idr.h - 1.3 include/linux/if.h - 1.2 include/linux/if_bridge.h - 1.2 include/linux/init.h - 1.3 include/linux/init_task.h - 1.4 include/linux/ipmi.h - 1.2 include/linux/ipmi_msgdefs.h - 1.2 include/linux/ipmi_smi.h - 1.2 include/linux/irq.h - 1.2 include/linux/jbd.h - 1.2 include/linux/kernel.h - 1.6 include/linux/kernelcapi.h - 1.2 include/linux/libata.h - 1.6 include/linux/list.h - 1.4 include/linux/mm.h - 1.8 include/linux/mmzone.h - 1.7 include/linux/module.h - 1.4 include/linux/msdos_fs.h - 1.3 include/linux/msg.h - 1.3 include/linux/net.h - 1.3 include/linux/netdevice.h - 1.8 include/linux/netfilter.h - 1.2 include/linux/netfilter_ipv4.h - 1.3 include/linux/netfilter_ipv4/ip_conntrack.h - 1.3 include/linux/netfilter_ipv4/ip_conntrack_helper.h - 1.2 include/linux/netfilter_ipv4/ip_conntrack_tftp.h - 1.2 include/linux/netfilter_ipv4/ipt_ULOG.h - 1.2 include/linux/netfilter_ipv4/ipt_conntrack.h - 1.2 include/linux/netfilter_ipv4/ipt_state.h - 1.2 include/linux/netlink.h - 1.3 include/linux/nfs4.h - 1.4 include/linux/nfs_fs.h - 1.5 include/linux/nfs_fs_sb.h - 1.3 include/linux/nfs_page.h - 1.4 include/linux/nfs_xdr.h - 1.4 include/linux/nfsd/nfsd.h - 1.3 include/linux/nfsd/state.h - 1.3 include/linux/page-flags.h - 1.4 include/linux/pagemap.h - 1.3 include/linux/pagevec.h - 1.2 include/linux/pci.h - 1.7 include/linux/pci_ids.h - 1.9 include/linux/pfkeyv2.h - 1.2 include/linux/posix_types.h - 1.2 include/linux/prefetch.h - 1.2 include/linux/proc_fs.h - 1.6 include/linux/quota.h - 1.3 include/linux/quotaops.h - 1.3 include/linux/radix-tree.h - 1.2 include/linux/raid/md.h - 1.2 include/linux/raid/md_k.h - 1.6 include/linux/reiserfs_fs.h - 1.5 include/linux/reiserfs_fs_i.h - 1.2 include/linux/reiserfs_fs_sb.h - 1.2 include/linux/rtnetlink.h - 1.3 include/linux/sched.h - 1.7 include/linux/sctp.h - 1.4 include/linux/security.h - 1.6 include/linux/sem.h - 1.3 include/linux/seq_file.h - 1.2 include/linux/serial_core.h - 1.4 include/linux/serial_reg.h - 1.3 include/linux/skbuff.h - 1.5 include/linux/slab.h - 1.3 include/linux/string.h - 1.3 include/linux/sunrpc/sched.h - 1.4 include/linux/sunrpc/xdr.h - 1.4 include/linux/sunrpc/xprt.h - 1.4 include/linux/suspend.h - 1.4 include/linux/swap.h - 1.3 include/linux/sysctl.h - 1.14 include/linux/sysfs.h - 1.2 include/linux/tcp.h - 1.5 include/linux/tcp_diag.h - 1.2 include/linux/timer.h - 1.2 include/linux/tty.h - 1.3 include/linux/types.h - 1.2 include/linux/udp.h - 1.3 include/linux/ufs_fs.h - 1.3 include/linux/usb.h - 1.6 include/linux/usb_ch9.h - 1.3 include/linux/usb_gadget.h - 1.4 include/linux/videodev.h - 1.4 include/linux/videodev2.h - 1.3 include/linux/wireless.h - 1.2 include/linux/workqueue.h - 1.3 include/linux/writeback.h - 1.2 include/media/audiochip.h - 1.2 include/media/saa7146.h - 1.4 include/media/saa7146_vv.h - 1.4 include/net/bluetooth/hci_core.h - 1.5 include/net/irda/irlan_common.h - 1.2 include/net/irda/irlan_eth.h - 1.2 include/net/irda/irlan_filter.h - 1.2 include/net/neighbour.h - 1.3 include/net/sctp/command.h - 1.2 include/net/sctp/constants.h - 1.4 include/net/sctp/sctp.h - 1.4 include/net/sctp/sm.h - 1.3 include/net/sctp/structs.h - 1.4 include/net/sctp/tsnmap.h - 1.2 include/net/sctp/ulpevent.h - 1.2 include/net/sctp/ulpqueue.h - 1.2 include/net/sctp/user.h - 1.2 include/net/sock.h - 1.4 include/net/tcp.h - 1.5 include/scsi/scsi_cmnd.h - 1.3 include/scsi/scsi_device.h - 1.3 include/scsi/scsi_devinfo.h - 1.2 include/scsi/scsi_host.h - 1.3 include/sound/es1688.h - 1.2 include/sound/sndmagic.h - 1.4 init/Kconfig - 1.4 init/do_mounts.c - 1.4 init/main.c - 1.14 ipc/Makefile - 1.3 ipc/msg.c - 1.3 ipc/shm.c - 1.4 ipc/util.c - 1.4 ipc/util.h - 1.3 kernel/Makefile - 1.3 kernel/acct.c - 1.4 kernel/configs.c - 1.2 kernel/exit.c - 1.13 kernel/fork.c - 1.6 kernel/kmod.c - 1.5 kernel/module.c - 1.13 kernel/params.c - 1.2 kernel/pid.c - 1.3 kernel/posix-timers.c - 1.5 kernel/power/Kconfig - 1.3 kernel/power/disk.c - 1.3 kernel/power/main.c - 1.2 kernel/power/pmdisk.c - 1.4 kernel/power/process.c - 1.2 kernel/power/swsusp.c - 1.5 kernel/printk.c - 1.12 kernel/rcupdate.c - 1.4 kernel/sched.c - 1.13 kernel/signal.c - 1.9 kernel/softirq.c - 1.4 kernel/sys.c - 1.6 kernel/sysctl.c - 1.13 kernel/time.c - 1.2 kernel/timer.c - 1.5 kernel/workqueue.c - 1.5 lib/Kconfig - 1.2 lib/Makefile - 1.6 lib/crc32.c - 1.4 lib/idr.c - 1.3 lib/kobject.c - 1.5 lib/radix-tree.c - 1.3 lib/rwsem-spinlock.c - 1.3 lib/rwsem.c - 1.3 mm/Makefile - 1.2 mm/fadvise.c - 1.5 mm/filemap.c - 1.9 mm/fremap.c - 1.4 mm/madvise.c - 1.3 mm/memory.c - 1.12 mm/mempool.c - 1.3 mm/mmap.c - 1.8 mm/mprotect.c - 1.4 mm/mremap.c - 1.6 mm/page-writeback.c - 1.3 mm/page_alloc.c - 1.7 mm/page_io.c - 1.2 mm/pdflush.c - 1.4 mm/readahead.c - 1.5 mm/rmap.c - 1.5 mm/shmem.c - 1.5 mm/slab.c - 1.6 mm/swap.c - 1.5 mm/swap_state.c - 1.2 mm/swapfile.c - 1.5 mm/truncate.c - 1.3 mm/vmscan.c - 1.6 net/8021q/vlan.h - 1.2 net/8021q/vlanproc.c - 1.3 net/Kconfig - 1.5 net/appletalk/ddp.c - 1.5 net/atm/ioctl.c - 1.2 net/atm/lec.h - 1.3 net/ax25/Kconfig - 1.2 net/ax25/af_ax25.c - 1.5 net/bluetooth/Kconfig - 1.3 net/bluetooth/bnep/core.c - 1.6 net/bluetooth/hci_sock.c - 1.3 net/bluetooth/rfcomm/core.c - 1.6 net/bluetooth/rfcomm/tty.c - 1.5 net/bridge/br.c - 1.2 net/bridge/br_device.c - 1.2 net/bridge/br_fdb.c - 1.2 net/bridge/br_forward.c - 1.2 net/bridge/br_if.c - 1.4 net/bridge/br_input.c - 1.2 net/bridge/br_ioctl.c - 1.2 net/bridge/br_notify.c - 1.2 net/bridge/br_private.h - 1.2 net/bridge/br_stp.c - 1.2 net/bridge/br_stp_bpdu.c - 1.2 net/bridge/br_stp_if.c - 1.2 net/bridge/br_stp_timer.c - 1.2 net/bridge/netfilter/ebtables.c - 1.2 net/core/dev.c - 1.8 net/core/dv.c - 1.2 net/core/ethtool.c - 1.3 net/core/neighbour.c - 1.5 net/core/netfilter.c - 1.3 net/core/rtnetlink.c - 1.2 net/core/skbuff.c - 1.2 net/core/sock.c - 1.5 net/econet/af_econet.c - 1.5 net/ipv4/af_inet.c - 1.4 net/ipv4/arp.c - 1.5 net/ipv4/devinet.c - 1.6 net/ipv4/esp4.c - 1.3 net/ipv4/icmp.c - 1.3 net/ipv4/igmp.c - 1.7 net/ipv4/ip_sockglue.c - 1.3 net/ipv4/ipcomp.c - 1.3 net/ipv4/ipvs/ip_vs_sync.c - 1.3 net/ipv4/netfilter/Kconfig - 1.4 net/ipv4/netfilter/Makefile - 1.2 net/ipv4/netfilter/ip_conntrack_amanda.c - 1.3 net/ipv4/netfilter/ip_conntrack_core.c - 1.4 net/ipv4/netfilter/ip_conntrack_ftp.c - 1.3 net/ipv4/netfilter/ip_conntrack_irc.c - 1.2 net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.3 net/ipv4/netfilter/ip_conntrack_standalone.c - 1.4 net/ipv4/netfilter/ip_conntrack_tftp.c - 1.3 net/ipv4/netfilter/ip_nat_core.c - 1.3 net/ipv4/netfilter/ip_nat_tftp.c - 1.3 net/ipv4/netfilter/ipt_LOG.c - 1.3 net/ipv4/netfilter/ipt_MASQUERADE.c - 1.4 net/ipv4/netfilter/ipt_ULOG.c - 1.3 net/ipv4/netfilter/ipt_conntrack.c - 1.3 net/ipv4/netfilter/ipt_owner.c - 1.3 net/ipv4/netfilter/ipt_state.c - 1.3 net/ipv4/route.c - 1.4 net/ipv4/sysctl_net_ipv4.c - 1.4 net/ipv4/tcp.c - 1.5 net/ipv4/tcp_diag.c - 1.3 net/ipv4/tcp_input.c - 1.4 net/ipv4/tcp_ipv4.c - 1.4 net/ipv4/tcp_minisocks.c - 1.3 net/ipv4/tcp_output.c - 1.2 net/ipv4/udp.c - 1.4 net/ipv6/addrconf.c - 1.7 net/ipv6/af_inet6.c - 1.5 net/ipv6/ah6.c - 1.3 net/ipv6/datagram.c - 1.4 net/ipv6/esp6.c - 1.3 net/ipv6/exthdrs.c - 1.7 net/ipv6/icmp.c - 1.4 net/ipv6/ip6_input.c - 1.3 net/ipv6/ip6_output.c - 1.7 net/ipv6/mcast.c - 1.6 net/ipv6/ndisc.c - 1.7 net/ipv6/netfilter/Kconfig - 1.3 net/ipv6/netfilter/Makefile - 1.2 net/ipv6/netfilter/ip6t_LOG.c - 1.3 net/ipv6/netfilter/ip6t_owner.c - 1.3 net/ipv6/raw.c - 1.5 net/ipv6/reassembly.c - 1.3 net/ipv6/tcp_ipv6.c - 1.4 net/ipv6/udp.c - 1.5 net/ipx/af_ipx.c - 1.4 net/irda/Kconfig - 1.2 net/irda/af_irda.c - 1.5 net/irda/irda_device.c - 1.3 net/irda/irlan/irlan_client.c - 1.2 net/irda/irlan/irlan_common.c - 1.3 net/irda/irlan/irlan_eth.c - 1.3 net/irda/irlan/irlan_filter.c - 1.3 net/irda/irlan/irlan_provider.c - 1.2 net/irda/irlap_event.c - 1.3 net/key/af_key.c - 1.5 net/netlink/af_netlink.c - 1.4 net/netlink/netlink_dev.c - 1.3 net/netrom/af_netrom.c - 1.5 net/packet/af_packet.c - 1.7 net/rose/af_rose.c - 1.5 net/rxrpc/transport.c - 1.3 net/sched/Kconfig - 1.5 net/sched/sch_dsmark.c - 1.4 net/sctp/associola.c - 1.4 net/sctp/chunk.c - 1.2 net/sctp/crc32c.c - 1.2 net/sctp/debug.c - 1.2 net/sctp/input.c - 1.3 net/sctp/ipv6.c - 1.3 net/sctp/objcnt.c - 1.2 net/sctp/output.c - 1.3 net/sctp/outqueue.c - 1.4 net/sctp/protocol.c - 1.4 net/sctp/sm_make_chunk.c - 1.4 net/sctp/sm_sideeffect.c - 1.3 net/sctp/sm_statefuns.c - 1.4 net/sctp/sm_statetable.c - 1.3 net/sctp/socket.c - 1.6 net/sctp/sysctl.c - 1.3 net/sctp/transport.c - 1.3 net/sctp/tsnmap.c - 1.2 net/sctp/ulpevent.c - 1.3 net/sctp/ulpqueue.c - 1.2 net/socket.c - 1.4 net/sunrpc/auth_gss/auth_gss.c - 1.4 net/sunrpc/auth_gss/gss_krb5_crypto.c - 1.3 net/sunrpc/auth_gss/gss_krb5_mech.c - 1.4 net/sunrpc/clnt.c - 1.4 net/sunrpc/sched.c - 1.5 net/sunrpc/sunrpc_syms.c - 1.5 net/sunrpc/svcauth_unix.c - 1.3 net/sunrpc/svcsock.c - 1.2 net/sunrpc/xdr.c - 1.4 net/sunrpc/xprt.c - 1.5 net/unix/af_unix.c - 1.6 net/wanrouter/af_wanpipe.c - 1.3 net/x25/af_x25.c - 1.4 scripts/Makefile.modinst - 1.3 scripts/Makefile.modpost - 1.4 scripts/genksyms/parse.y - 1.2 scripts/kconfig/gconf.c - 1.3 scripts/kernel-doc - 1.2 scripts/modpost.c - 1.7 scripts/modpost.h - 1.4 scripts/ver_linux - 1.3 security/capability.c - 1.3 security/commoncap.c - 1.5 security/dummy.c - 1.6 security/root_plug.c - 1.2 security/selinux/Kconfig - 1.2 security/selinux/avc.c - 1.4 security/selinux/hooks.c - 1.7 security/selinux/include/avc.h - 1.4 security/selinux/include/objsec.h - 1.4 security/selinux/include/security.h - 1.4 security/selinux/selinuxfs.c - 1.5 security/selinux/ss/policydb.c - 1.5 security/selinux/ss/policydb.h - 1.3 security/selinux/ss/services.c - 1.6 sound/core/Kconfig - 1.3 sound/isa/es1688/es1688.c - 1.4 sound/isa/es1688/es1688_lib.c - 1.4 sound/isa/wavefront/wavefront_synth.c - 1.3 sound/oss/Kconfig - 1.5 sound/oss/au1000.c - 1.3 sound/oss/ite8172.c - 1.3 sound/oss/rme96xx.c - 1.4 sound/oss/sb.h - 1.2 sound/oss/sb_ess.c - 1.2 sound/oss/sb_mixer.c - 1.2 sound/oss/vwsnd.c - 1.3 sound/oss/wavfront.c - 1.3 drivers/usb/media/w9968cf.c - 1.4 Documentation/dvb/cards.txt - 1.3 Documentation/dvb/contributors.txt - 1.3 Documentation/dvb/faq.txt - 1.3 Documentation/i2c/porting-clients - 1.4 drivers/pci/msi.c - 1.4 drivers/media/dvb/frontends/dst.c - 1.4 drivers/media/dvb/bt8xx/dvb-bt8xx.c - 1.2 drivers/i2c/chips/lm83.c - 1.4 arch/x86_64/ia32/ia32_aout.c - 1.3 arch/i386/kernel/efi.c - 1.3 drivers/scsi/qla2xxx/Kconfig - 1.4 drivers/scsi/qla2xxx/ql2100.c - 1.2 drivers/scsi/qla2xxx/ql2100_fw.c - 1.2 drivers/scsi/qla2xxx/ql2200.c - 1.2 drivers/scsi/qla2xxx/ql2200_fw.c - 1.2 drivers/scsi/qla2xxx/ql2300.c - 1.3 drivers/scsi/qla2xxx/ql2300_fw.c - 1.3 drivers/scsi/qla2xxx/qla_dbg.c - 1.4 drivers/scsi/qla2xxx/qla_dbg.h - 1.3 drivers/scsi/qla2xxx/qla_def.h - 1.3 drivers/scsi/qla2xxx/qla_devtbl.h - 1.2 drivers/scsi/qla2xxx/qla_gbl.h - 1.3 drivers/scsi/qla2xxx/qla_gs.c - 1.3 drivers/scsi/qla2xxx/qla_init.c - 1.4 Documentation/power/video.txt - 1.2 drivers/scsi/qla2xxx/qla_inline.h - 1.2 drivers/scsi/qla2xxx/qla_iocb.c - 1.3 drivers/scsi/qla2xxx/qla_isr.c - 1.4 drivers/scsi/qla2xxx/qla_listops.h - 1.2 net/bluetooth/cmtp/core.c - 1.3 Documentation/video4linux/CARDLIST.bttv - 1.2 Documentation/video4linux/CARDLIST.saa7134 - 1.2 Documentation/video4linux/CARDLIST.tuner - 1.2 Documentation/video4linux/README.cx88 - 1.2 drivers/scsi/qla2xxx/qla_mbx.c - 1.4 drivers/scsi/qla2xxx/qla_os.c - 1.5 drivers/scsi/qla2xxx/qla_os.h - 1.3 drivers/scsi/qla2xxx/qla_rscn.c - 1.2 drivers/scsi/qla2xxx/qla_settings.h - 1.3 drivers/scsi/qla2xxx/qla_sup.c - 1.3 drivers/scsi/qla2xxx/qla_version.h - 1.3 drivers/usb/gadget/goku_udc.c - 1.3 drivers/usb/gadget/pxa2xx_udc.c - 1.4 drivers/usb/gadget/serial.c - 1.3 include/asm-ppc64/vio.h - 1.5 drivers/s390/char/raw3270.c - 1.2 drivers/s390/char/keyboard.c - 1.2 arch/ia64/configs/generic_defconfig - 1.4 drivers/media/video/saa7134/saa7134-input.c - 1.3 drivers/media/video/ir-kbd-i2c.c - 1.2 drivers/media/video/cx88/cx88.h - 1.2 drivers/media/video/cx88/cx88-video.c - 1.2 drivers/media/video/cx88/cx88-tvaudio.c - 1.2 drivers/media/video/cx88/cx88-reg.h - 1.2 drivers/media/video/cx88/cx88-i2c.c - 1.2 drivers/media/video/cx88/cx88-core.c - 1.2 drivers/media/video/cx88/cx88-cards.c - 1.2 drivers/media/video/cx88/Makefile - 1.2 drivers/media/video/bttv-i2c.c - 1.2 drivers/media/dvb/ttpci/av7110_v4l.c - 1.3 drivers/media/dvb/ttpci/av7110_hw.h - 1.3 drivers/media/dvb/ttpci/av7110_hw.c - 1.3 drivers/media/dvb/ttpci/av7110_av.c - 1.2 drivers/md/raid6main.c - 1.5 lib/bitmap.c - 1.6 drivers/i2c/chips/w83l785ts.c - 1.4 drivers/i2c/chips/lm90.c - 1.3 drivers/i2c/chips/asb100.c - 1.3 drivers/bluetooth/bfusb.c - 1.4 drivers/bluetooth/bcm203x.c - 1.3 arch/ppc64/mm/hash_low.S - 1.5 arch/ppc64/kernel/vio.c - 1.5 drivers/usb/gadget/file_storage.c - 1.3 drivers/scsi/qla2xxx/ql6312_fw.c - 1.2 drivers/scsi/qla2xxx/ql6312.c - 1.2 drivers/scsi/qla2xxx/ql2322_fw.c - 1.2 drivers/scsi/qla2xxx/ql2322.c - 1.2 drivers/scsi/qla2xxx/ql6322.c - 1.2 drivers/scsi/qla2xxx/ql6322_fw.c - 1.2 arch/ppc/kernel/cpu_setup_power4.S - 1.2 arch/parisc/configs/c3000_defconfig - 1.3 drivers/pci/msi.h - 1.3 drivers/i2c/chips/gl518sm.c - 1.3 drivers/i2c/chips/fscher.c - 1.3 arch/ppc64/kernel/pci_dma_direct.c - 1.3 arch/ppc64/kernel/cpu_setup_power4.S - 1.2 arch/ppc64/kernel/btext.c - 1.2 arch/ppc64/configs/pSeries_defconfig - 1.4 arch/ppc64/configs/g5_defconfig - 1.4 drivers/net/ibmveth.c - 1.3 drivers/net/e100.c - 1.3 drivers/net/irda/stir4200.c - 1.2 drivers/pci/hotplug/pciehp_ctrl.c - 1.2 drivers/pci/hotplug/pciehp_hpc.c - 1.3 drivers/pci/hotplug/pciehp_pci.c - 1.3 net/sunrpc/auth_gss/svcauth_gss.c - 1.3 drivers/pci/hotplug/rpadlpar_core.c - 1.3 drivers/pci/hotplug/rpaphp.h - 1.3 drivers/pci/hotplug/rpaphp_core.c - 1.3 drivers/pci/hotplug/rpaphp_pci.c - 1.3 drivers/pci/hotplug/shpchp_ctrl.c - 1.2 drivers/pci/hotplug/shpchp_hpc.c - 1.2 drivers/pci/hotplug/shpchprm_acpi.c - 1.2 drivers/pci/hotplug/shpchprm_legacy.c - 1.2 drivers/s390/block/dcssblk.c - 1.2 drivers/misc/ibmasm/ibmasm.h - 1.2 drivers/misc/ibmasm/Makefile - 1.2 drivers/s390/char/tape_class.c - 1.3 fs/hfsplus/inode.c - 1.2 include/asm-mips/hazards.h - 1.2 include/asm-mips/mach-atlas/mc146818rtc.h - 1.2 include/asm-mips/mach-au1x00/au1000.h - 1.2 include/asm-mips/mach-au1x00/au1000_dma.h - 1.2 arch/arm/mm/copypage-v6.c - 1.2 include/asm-mips/mach-db1x00/db1x00.h - 1.2 arch/arm/oprofile/Makefile - 1.2 arch/arm/oprofile/init.c - 1.2 include/asm-mips/mach-generic/ide.h - 1.2 arch/h8300/Kconfig.ide - 1.2 include/asm-mips/mach-generic/spaces.h - 1.2 drivers/md/dm-crypt.c - 1.3 include/asm-mips/mach-ip27/mmzone.h - 1.2 include/asm-mips/mach-ip27/spaces.h - 1.2 include/asm-mips/mach-ip32/mc146818rtc.h - 1.2 include/asm-mips/mach-mips/mc146818rtc.h - 1.2 include/asm-mips/mc146818-time.h - 1.2 drivers/isdn/hisax/hfc_usb.c - 1.3 drivers/ieee1394/csr1212.h - 1.2 drivers/ieee1394/csr1212.c - 1.2 include/asm-mips/prefetch.h - 1.2 include/asm-mips/sn/hub.h - 1.2 drivers/char/agp/efficeon-agp.c - 1.2 drivers/cdrom/viocd.c - 1.3 arch/x86_64/kernel/mce.c - 1.3 include/asm-ppc64/iommu.h - 1.3 include/linux/sunrpc/svcauth_gss.h - 1.2 arch/ppc64/kernel/pmac_iommu.c - 1.3 include/linux/syscalls.h - 1.3 arch/ppc64/kernel/pci_iommu.c - 1.3 arch/ppc64/kernel/pSeries_iommu.c - 1.3 arch/ppc64/kernel/iommu.c - 1.3 arch/ppc64/kernel/iSeries_iommu.c - 1.3 kernel/stop_machine.c - 1.3 arch/mips/vr41xx/common/rtc.c - 1.2 arch/mips/sgi-ip27/ip27-smp.c - 1.2 arch/mips/pmc-sierra/yosemite/smp.c - 1.2 arch/mips/pmc-sierra/yosemite/setup.c - 1.2 arch/mips/pmc-sierra/yosemite/prom.c - 1.2 arch/mips/pmc-sierra/yosemite/irq.c - 1.2 arch/mips/pmc-sierra/yosemite/ht.c - 1.2 arch/mips/pmc-sierra/yosemite/Makefile - 1.2 arch/mips/pci/ops-mv64340.c - 1.2 arch/mips/momentum/jaguar_atx/setup.c - 1.2 arch/mips/momentum/jaguar_atx/prom.c - 1.2 arch/mips/momentum/jaguar_atx/jaguar_atx_fpga.h - 1.2 arch/mips/momentum/jaguar_atx/irq.c - 1.2 arch/mips/momentum/jaguar_atx/int-handler.S - 1.2 arch/mips/momentum/jaguar_atx/Makefile - 1.2 arch/mips/mm/pg-r4k.c - 1.2 arch/mips/mm/init.c - 1.2 arch/mips/mm/dma-noncoherent.c - 1.3 arch/mips/mm/dma-ip27.c - 1.3 arch/mips/mm/dma-coherent.c - 1.3 arch/mips/kernel/irq-rm7000.c - 1.2 arch/mips/configs/yosemite_defconfig - 1.2 arch/mips/au1000/common/pci.c - 1.2 arch/mips/configs/xxs1500_defconfig - 1.2 arch/mips/configs/workpad_defconfig - 1.3 arch/mips/configs/tb0229_defconfig - 1.2 arch/mips/configs/tb0226_defconfig - 1.3 arch/mips/configs/sead_defconfig - 1.2 arch/mips/au1000/common/setup.c - 1.2 arch/mips/configs/sb1250-swarm_defconfig - 1.2 arch/mips/configs/rm200_defconfig - 1.3 arch/mips/au1000/csb250/Makefile - 1.2 arch/mips/au1000/csb250/irqmap.c - 1.2 arch/mips/configs/pb1500_defconfig - 1.3 arch/mips/au1000/db1x00/board_setup.c - 1.2 arch/mips/configs/pb1100_defconfig - 1.2 arch/mips/au1000/db1x00/irqmap.c - 1.2 arch/mips/configs/pb1000_defconfig - 1.2 arch/mips/au1000/hydrogen3/Makefile - 1.2 arch/mips/au1000/hydrogen3/board_setup.c - 1.2 arch/mips/au1000/hydrogen3/irqmap.c - 1.2 arch/mips/au1000/mtx-1/irqmap.c - 1.2 arch/mips/configs/osprey_defconfig - 1.2 arch/mips/configs/ocelot_defconfig - 1.2 arch/mips/au1000/pb1000/irqmap.c - 1.2 arch/mips/configs/mtx1_defconfig - 1.2 arch/mips/configs/mpc30x_defconfig - 1.2 arch/mips/configs/mirage_defconfig - 1.2 arch/mips/au1000/pb1100/irqmap.c - 1.2 arch/mips/configs/malta_defconfig - 1.2 arch/mips/configs/lasat200_defconfig - 1.3 arch/mips/configs/jmr3927_defconfig - 1.2 arch/mips/au1000/pb1500/irqmap.c - 1.2 arch/mips/configs/jaguar-atx_defconfig - 1.2 arch/mips/au1000/pb1550/Makefile - 1.2 arch/mips/au1000/pb1550/board_setup.c - 1.2 arch/mips/au1000/pb1550/init.c - 1.2 arch/mips/au1000/pb1550/irqmap.c - 1.2 arch/mips/au1000/xxs1500/irqmap.c - 1.2 arch/mips/configs/ivr_defconfig - 1.3 arch/mips/configs/it8172_defconfig - 1.3 arch/mips/configs/ip32_defconfig - 1.2 arch/mips/configs/ip27_defconfig - 1.2 arch/mips/configs/ip22_defconfig - 1.2 arch/mips/configs/ev96100_defconfig - 1.2 arch/mips/configs/ev64120_defconfig - 1.2 arch/mips/configs/eagle_defconfig - 1.3 arch/mips/configs/atlas_defconfig - 1.2 arch/mips/configs/bosporus_defconfig - 1.2 arch/mips/configs/capcella_defconfig - 1.3 arch/mips/configs/cobalt_defconfig - 1.3 arch/mips/configs/db1000_defconfig - 1.2 arch/mips/configs/db1100_defconfig - 1.2 arch/mips/configs/db1500_defconfig - 1.3 arch/mips/configs/ddb5476_defconfig - 1.3 arch/mips/configs/ddb5477_defconfig - 1.2 arch/mips/configs/decstation_defconfig - 1.2 arch/mips/configs/e55_defconfig - 1.3 drivers/pci/hotplug/rpaphp_slot.c - 1.2 drivers/input/mouse/vsxxxaa.c - 1.2 drivers/input/keyboard/lkkbd.c - 1.2 drivers/scsi/sata_vsc.c - 1.2 drivers/scsi/scsi_transport_fc.c - 1.2 drivers/i2c/chips/w83627hf.c - 1.2 drivers/scsi/scsi_transport_spi.c - 1.2 drivers/i2c/chips/lm80.c - 1.2 drivers/serial/sh-sci.c - 1.2 drivers/serial/sh-sci.h - 1.2 drivers/i2c/chips/ds1621.c - 1.2 drivers/usb/gadget/gadget_chips.h - 1.2 drivers/usb/input/ati_remote.c - 1.2 drivers/firmware/edd.c - 1.2 drivers/firmware/Makefile - 1.2 drivers/firmware/Kconfig - 1.2 include/asm-ppc/hawk.h - 1.2 drivers/char/viotape.c - 1.2 drivers/char/agp/intel-mch-agp.c - 1.2 arch/sh/mm/hugetlbpage.c - 1.2 include/scsi/scsi_transport_fc.h - 1.2 include/scsi/scsi_transport_spi.h - 1.2 net/core/netpoll.c - 1.2 arch/ppc64/kernel/dma.c - 1.2 arch/ppc/platforms/pplus.h - 1.2 arch/ppc/platforms/pplus.c - 1.2 arch/h8300/kernel/ints.c - 1.2 sound/pci/mixart/mixart.h - 1.2 arch/h8300/platform/h8s/ints_h8s.c - 1.2 sound/pcmcia/pdaudiocf/pdaudiocf.c - 1.2 arch/ia64/configs/zx1_defconfig - 1.2 Merge in new kdb for 2.6.6 Date: Mon May 10 23:16:28 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: kaos@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:171519a Makefile - 1.19 arch/i386/Kconfig - 1.11 arch/i386/Makefile - 1.7 arch/i386/kernel/entry.S - 1.9 arch/i386/kernel/i8259.c - 1.10 arch/i386/kernel/io_apic.c - 1.12 arch/i386/kernel/nmi.c - 1.9 arch/i386/kernel/reboot.c - 1.8 arch/i386/kernel/smp.c - 1.7 arch/i386/kernel/smpboot.c - 1.10 arch/i386/kernel/traps.c - 1.9 arch/i386/kernel/vmlinux.lds.S - 1.7 drivers/char/keyboard.c - 1.13 drivers/char/sn_serial.c - 1.14 drivers/serial/8250.c - 1.14 include/asm-i386/kmap_types.h - 1.5 include/asm-i386/mach-default/irq_vectors.h - 1.8 include/asm-i386/ptrace.h - 1.5 include/linux/console.h - 1.10 include/linux/sysctl.h - 1.15 init/main.c - 1.15 kernel/exit.c - 1.14 kernel/kallsyms.c - 1.10 kernel/module.c - 1.14 kernel/printk.c - 1.13 kernel/sched.c - 1.14 kernel/signal.c - 1.10 kernel/sysctl.c - 1.14 mm/memory.c - 1.13 scripts/Makefile - 1.10 scripts/kallsyms.c - 1.9 Documentation/kdb/dump.txt - 1.6 Documentation/kdb/kdb.mm - 1.6 Documentation/kdb/kdb_bp.man - 1.6 Documentation/kdb/kdb_bt.man - 1.6 Documentation/kdb/kdb_env.man - 1.6 Documentation/kdb/kdb_ll.man - 1.6 Documentation/kdb/kdb_md.man - 1.6 Documentation/kdb/kdb_rd.man - 1.6 Documentation/kdb/kdb_sr.man - 1.6 Documentation/kdb/kdb_ss.man - 1.6 Documentation/kdb/slides - 1.6 kdb/Makefile - 1.7 kdb/kdbmain.c - 1.7 kdb/modules/kdbm_vm.c - 1.6 kdb/modules/kdbm_task.c - 1.6 include/linux/dis-asm.h - 1.6 kdb/modules/kdbm_pg.c - 1.7 kdb/modules/Makefile - 1.6 kdb/ChangeLog - 1.9 kdb/kdbsupport.c - 1.7 kdb/kdb_bp.c - 1.6 kdb/kdb_bt.c - 1.6 kdb/kdb_id.c - 1.6 kdb/kdb_io.c - 1.7 kdb/kdb_cmds - 1.6 kdb/modules/kdbm_x86.c - 1.4 include/asm-i386/kdbprivate.h - 1.4 arch/i386/kdb/ChangeLog - 1.6 arch/i386/kdb/Makefile - 1.4 arch/i386/kdb/ansidecl.h - 1.4 arch/i386/kdb/bfd.h - 1.4 arch/i386/kdb/i386-dis.c - 1.4 arch/i386/kdb/kdba_bp.c - 1.4 arch/i386/kdb/kdba_bt.c - 1.4 arch/i386/kdb/kdba_id.c - 1.4 arch/i386/kdb/kdba_io.c - 1.4 arch/i386/kdb/kdbasupport.c - 1.4 arch/i386/kdb/pc_keyb.h - 1.4 include/asm-i386/kdb.h - 1.4 split-patches/kdb-common - 1.2 split-patches/kdb-i386 - 1.2 Refresh split patches for 2.6.6 Date: Mon May 10 23:26:54 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:171520a fs/Kconfig - 1.13 include/linux/mm.h - 1.9 mm/mprotect.c - 1.5 split-patches/dmapi-enable - 1.3 split-patches/doc-update - 1.2 split-patches/kdb-common - 1.3 split-patches/kdb-i386 - 1.3 split-patches/series - 1.2 split-patches/xfs-debug - 1.2 split-patches/xfs-modules - 1.2 Merge up to 2.6.6 - new files. Date: Tue May 11 00:00:08 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: akpm@osdl.org,torvalds@osdl.org The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:171521a Documentation/arm/Sharp-LH/CompactFlash - 1.1 Documentation/arm/Sharp-LH/IOBarrier - 1.1 Documentation/arm/Sharp-LH/KEV7A400 - 1.1 Documentation/arm/Sharp-LH/LPD7A400 - 1.1 Documentation/arm/Sharp-LH/LPD7A40X - 1.1 Documentation/arm/Sharp-LH/VectoredInterruptController - 1.1 Documentation/laptop-mode.txt - 1.1 Documentation/networking/s2io.txt - 1.1 Documentation/s390/crypto/crypto-API.txt - 1.1 Documentation/usb/linux.inf - 1.1 arch/arm/boot/compressed/ice-dcc.S - 1.1 arch/arm/common/dmabounce.c - 1.1 arch/arm/configs/bast_defconfig - 1.1 arch/arm/configs/lpd7a400_defconfig - 1.1 arch/arm/configs/lpd7a404_defconfig - 1.1 arch/arm/configs/s3c2410_defconfig - 1.1 arch/arm/configs/versatile_defconfig - 1.1 arch/arm/mach-lh7a40x/Kconfig - 1.1 arch/arm/mach-lh7a40x/Makefile - 1.1 arch/arm/mach-lh7a40x/arch-kev7a400.c - 1.1 arch/arm/mach-lh7a40x/arch-lpd7a40x.c - 1.1 arch/arm/mach-lh7a40x/fiq.S - 1.1 arch/arm/mach-lh7a40x/ide-lpd7a40x.c - 1.1 arch/arm/mach-lh7a40x/irq-kev7a400.c - 1.1 arch/arm/mach-lh7a40x/irq-lh7a400.c - 1.1 arch/arm/mach-lh7a40x/irq-lh7a404.c - 1.1 arch/arm/mach-lh7a40x/irq-lpd7a40x.c - 1.1 arch/arm/mach-omap/Kconfig - 1.1 arch/arm/mach-omap/Makefile - 1.1 arch/arm/mach-omap/board-generic.c - 1.1 arch/arm/mach-omap/board-innovator.c - 1.1 arch/arm/mach-omap/board-osk.c - 1.1 arch/arm/mach-omap/board-perseus2.c - 1.1 arch/arm/mach-omap/bus.c - 1.1 arch/arm/mach-omap/clocks.c - 1.1 arch/arm/mach-omap/common.c - 1.1 arch/arm/mach-omap/common.h - 1.1 arch/arm/mach-omap/dma.c - 1.1 arch/arm/mach-omap/fpga.c - 1.1 arch/arm/mach-omap/gpio.c - 1.1 arch/arm/mach-omap/innovator1510.c - 1.1 arch/arm/mach-omap/innovator1610.c - 1.1 arch/arm/mach-omap/irq.c - 1.1 arch/arm/mach-omap/irq.h - 1.1 arch/arm/mach-omap/leds-innovator.c - 1.1 arch/arm/mach-omap/leds-perseus2.c - 1.1 arch/arm/mach-omap/leds.c - 1.1 arch/arm/mach-omap/leds.h - 1.1 arch/arm/mach-omap/mux.c - 1.1 arch/arm/mach-omap/ocpi.c - 1.1 arch/arm/mach-omap/omap-generic.c - 1.1 arch/arm/mach-omap/omap-perseus2.c - 1.1 arch/arm/mach-s3c2410/Kconfig - 1.1 arch/arm/mach-s3c2410/Makefile - 1.1 arch/arm/mach-s3c2410/bast-irq.c - 1.1 arch/arm/mach-s3c2410/bast.h - 1.1 arch/arm/mach-s3c2410/irq.c - 1.1 arch/arm/mach-s3c2410/mach-bast.c - 1.1 arch/arm/mach-s3c2410/mach-h1940.c - 1.1 arch/arm/mach-s3c2410/mach-vr1000.c - 1.1 arch/arm/mach-s3c2410/s3c2410.c - 1.1 arch/arm/mach-s3c2410/s3c2410.h - 1.1 arch/arm/mach-versatile/Makefile - 1.1 arch/arm/mach-versatile/core.c - 1.1 arch/arm/mm/fault.c - 1.1 arch/arm/mm/mmap.c - 1.1 arch/arm/oprofile/common.c - 1.1 arch/arm/oprofile/op_arm_model.h - 1.1 arch/arm/oprofile/op_counter.h - 1.1 arch/arm/oprofile/op_model_xscale.c - 1.1 arch/h8300/platform/h8300h/ptrace_h8300h.c - 1.1 arch/h8300/platform/h8s/ptrace_h8s.c - 1.1 arch/i386/kernel/std_resources.c - 1.1 arch/i386/mach-pc9800/std_resources.c - 1.1 arch/m68knommu/kernel/dma.c - 1.1 arch/m68knommu/platform/5272/senTec/crt0_ram.S - 1.1 arch/m68knommu/platform/5282/senTec/crt0_ram.S - 1.1 arch/mips/au1000/common/au1xxx_irqmap.c - 1.1 arch/mips/au1000/common/dbdma.c - 1.1 arch/mips/au1000/db1x00/mirage_ts.c - 1.1 arch/mips/configs/ocelot_c_defconfig - 1.1 arch/mips/configs/pb1550_defconfig - 1.1 arch/mips/kernel/irq-mv6434x.c - 1.1 arch/mips/momentum/jaguar_atx/ja-console.c - 1.1 arch/mips/pci/fixup-lasat.c - 1.1 arch/mips/pci/fixup-mv64340.c - 1.1 drivers/s390/net/qeth_fs.h - 1.1 arch/mips/sgi-ip27/ip27-hubio.c - 1.1 arch/mips/sgi-ip27/ip27-xtalk.c - 1.1 arch/mips/vr41xx/common/init.c - 1.1 arch/ppc/platforms/k2.c - 1.1 arch/ppc/platforms/mcpn765.c - 1.1 arch/ppc/platforms/pcore.c - 1.1 arch/ppc/platforms/prpmc750.c - 1.1 arch/ppc/platforms/prpmc800.c - 1.1 arch/ppc/syslib/hawk_common.c - 1.1 arch/ppc64/kernel/sysfs.c - 1.1 arch/ppc64/oprofile/common.c - 1.1 arch/ppc64/oprofile/op_impl.h - 1.1 arch/ppc64/oprofile/op_model_power4.c - 1.1 arch/ppc64/oprofile/op_model_rs64.c - 1.1 arch/s390/crypto/Makefile - 1.1 arch/s390/crypto/crypt_z990.h - 1.1 arch/s390/crypto/crypt_z990_query.c - 1.1 arch/s390/crypto/crypto_des.h - 1.1 arch/s390/crypto/des_check_key.c - 1.1 arch/s390/crypto/des_z990.c - 1.1 arch/s390/crypto/sha1_z990.c - 1.1 arch/s390/kernel/profile.c - 1.1 arch/s390/oprofile/Kconfig - 1.1 arch/s390/oprofile/Makefile - 1.1 arch/s390/oprofile/init.c - 1.1 crypto/crc32c.c - 1.1 drivers/block/cfq-iosched.c - 1.1 drivers/char/ipmi/ipmi_bt_sm.c - 1.1 drivers/char/ipmi/ipmi_si_intf.c - 1.1 drivers/char/ipmi/ipmi_si_sm.h - 1.1 drivers/char/ipmi/ipmi_smic_sm.c - 1.1 drivers/firmware/efivars.c - 1.1 drivers/i2c/busses/i2c-ali1563.c - 1.1 drivers/i2c/chips/pcf8574.c - 1.1 drivers/i2c/chips/pcf8591.c - 1.1 drivers/input/serio/i8042-ip22io.h - 1.1 drivers/input/serio/i8042-jazzio.h - 1.1 drivers/input/serio/maceps2.c - 1.1 drivers/media/dvb/dvb-core/dvb_ca_en50221.c - 1.1 drivers/media/dvb/dvb-core/dvb_ca_en50221.h - 1.1 drivers/media/video/cx88/cx88-vbi.c - 1.1 drivers/net/irda/ali-ircc.h - 1.1 drivers/net/irda/au1000_ircc.h - 1.1 drivers/net/irda/irda-usb.h - 1.1 drivers/net/irda/irport.h - 1.1 drivers/net/irda/nsc-ircc.h - 1.1 drivers/net/irda/vlsi_ir.h - 1.1 drivers/net/irda/w83977af.h - 1.1 drivers/net/irda/w83977af_ir.h - 1.1 drivers/net/iseries_veth.c - 1.1 drivers/net/iseries_veth.h - 1.1 drivers/net/s2io-regs.h - 1.1 drivers/net/s2io.c - 1.1 drivers/net/s2io.h - 1.1 drivers/s390/crypto/Makefile - 1.1 drivers/s390/crypto/z90common.h - 1.1 drivers/s390/crypto/z90crypt.h - 1.1 drivers/s390/crypto/z90hardware.c - 1.1 drivers/s390/crypto/z90main.c - 1.1 include/asm-arm/arch-omap/bus.h - 1.1 drivers/s390/net/qeth_main.c - 1.1 drivers/s390/net/qeth_proc.c - 1.1 drivers/s390/net/qeth_sys.c - 1.1 drivers/scsi/sata_sis.c - 1.1 drivers/serial/amba-pl010.c - 1.1 drivers/serial/amba-pl011.c - 1.1 drivers/serial/bast_sio.c - 1.1 drivers/serial/s3c2410.c - 1.1 drivers/usb/gadget/dummy_hcd.c - 1.1 drivers/usb/gadget/epautoconf.c - 1.1 drivers/usb/gadget/ndis.h - 1.1 drivers/usb/gadget/rndis.c - 1.1 drivers/usb/gadget/rndis.h - 1.1 drivers/usb/misc/cytherm.c - 1.1 fs/cifs/fcntl.c - 1.1 fs/cifs/rfc1002pdu.h - 1.1 fs/ntfs/logfile.c - 1.1 fs/ntfs/logfile.h - 1.1 fs/ntfs/time.h - 1.1 include/asm-arm/arch-lh7a40x/constants.h - 1.1 include/asm-arm/arch-lh7a40x/dma.h - 1.1 include/asm-arm/arch-lh7a40x/hardware.h - 1.1 include/asm-arm/arch-lh7a40x/ide.h - 1.1 include/asm-arm/arch-lh7a40x/io.h - 1.1 include/asm-arm/arch-lh7a40x/irq.h - 1.1 include/asm-arm/arch-lh7a40x/irqs.h - 1.1 include/asm-arm/arch-lh7a40x/memory.h - 1.1 include/asm-arm/arch-lh7a40x/param.h - 1.1 include/asm-arm/arch-lh7a40x/registers.h - 1.1 include/asm-arm/arch-lh7a40x/serial.h - 1.1 include/asm-arm/arch-lh7a40x/system.h - 1.1 include/asm-arm/arch-lh7a40x/time.h - 1.1 include/asm-arm/arch-lh7a40x/timex.h - 1.1 include/asm-arm/arch-lh7a40x/uncompress.h - 1.1 include/asm-arm/arch-lh7a40x/vmalloc.h - 1.1 include/asm-arm/arch-omap/board-h2.h - 1.1 include/asm-arm/arch-omap/board-h3.h - 1.1 include/asm-arm/arch-omap/board-h4.h - 1.1 include/asm-arm/arch-omap/board-innovator.h - 1.1 include/asm-arm/arch-omap/board-osk.h - 1.1 include/asm-arm/arch-omap/board-perseus2.h - 1.1 include/asm-arm/arch-omap/board.h - 1.1 include/asm-arm/arch-s3c2410/ide.h - 1.1 include/asm-arm/arch-omap/clocks.h - 1.1 include/asm-arm/arch-omap/dma.h - 1.1 include/asm-arm/arch-omap/fpga.h - 1.1 include/asm-arm/arch-omap/gpio.h - 1.1 include/asm-arm/arch-omap/hardware.h - 1.1 include/asm-arm/arch-omap/io.h - 1.1 include/asm-arm/arch-omap/irqs.h - 1.1 include/asm-arm/arch-omap/memory.h - 1.1 include/asm-arm/arch-omap/mux.h - 1.1 include/asm-arm/arch-omap/omap-h2.h - 1.1 include/asm-arm/arch-omap/omap-innovator.h - 1.1 include/asm-arm/arch-omap/omap-perseus2.h - 1.1 include/asm-arm/arch-omap/omap1510.h - 1.1 include/asm-arm/arch-omap/omap1610.h - 1.1 include/asm-arm/arch-omap/omap5912.h - 1.1 include/asm-arm/arch-omap/omap730.h - 1.1 include/asm-arm/arch-omap/param.h - 1.1 include/asm-arm/arch-omap/pm.h - 1.1 include/asm-arm/arch-omap/serial.h - 1.1 include/asm-arm/arch-omap/system.h - 1.1 include/asm-arm/arch-omap/time.h - 1.1 include/asm-arm/arch-omap/timex.h - 1.1 include/asm-arm/arch-omap/uncompress.h - 1.1 include/asm-arm/arch-omap/vmalloc.h - 1.1 include/asm-arm/arch-s3c2410/bast-cpld.h - 1.1 include/asm-arm/arch-s3c2410/bast-irq.h - 1.1 include/asm-arm/arch-s3c2410/bast-map.h - 1.1 include/asm-arm/arch-s3c2410/dma.h - 1.1 include/asm-arm/arch-s3c2410/hardware.h - 1.1 include/asm-arm/arch-s3c2410/vr1000-irq.h - 1.1 include/asm-arm/arch-s3c2410/io.h - 1.1 include/asm-arm/arch-s3c2410/irqs.h - 1.1 include/asm-arm/arch-s3c2410/map.h - 1.1 include/asm-arm/arch-s3c2410/memory.h - 1.1 include/asm-arm/arch-s3c2410/param.h - 1.1 include/asm-arm/arch-s3c2410/regs-clock.h - 1.1 include/asm-arm/arch-s3c2410/regs-gpio.h - 1.1 include/asm-arm/arch-s3c2410/regs-iis.h - 1.1 include/asm-arm/arch-s3c2410/regs-irq.h - 1.1 include/asm-arm/arch-s3c2410/regs-lcd.h - 1.1 include/asm-arm/arch-s3c2410/regs-rtc.h - 1.1 include/asm-arm/arch-s3c2410/regs-serial.h - 1.1 include/asm-arm/arch-s3c2410/regs-timer.h - 1.1 include/asm-arm/arch-s3c2410/regs-watchdog.h - 1.1 include/asm-arm/arch-s3c2410/serial.h - 1.1 include/asm-arm/arch-s3c2410/system.h - 1.1 include/asm-arm/arch-s3c2410/time.h - 1.1 include/asm-arm/arch-s3c2410/timex.h - 1.1 include/asm-arm/arch-s3c2410/uncompress.h - 1.1 include/asm-arm/arch-s3c2410/vmalloc.h - 1.1 include/asm-arm/arch-s3c2410/vr1000-cpld.h - 1.1 include/asm-arm/hardware/amba_serial.h - 1.1 include/asm-arm/arch-s3c2410/vr1000-map.h - 1.1 include/asm-arm/arch-versatile/dma.h - 1.1 include/asm-arm/arch-versatile/hardware.h - 1.1 include/asm-arm/arch-versatile/io.h - 1.1 include/asm-arm/arch-versatile/irqs.h - 1.1 include/asm-arm/arch-versatile/memory.h - 1.1 include/asm-arm/arch-versatile/param.h - 1.1 include/asm-arm/arch-versatile/platform.h - 1.1 include/asm-arm/arch-versatile/serial.h - 1.1 include/asm-arm/arch-versatile/system.h - 1.1 include/asm-arm/arch-versatile/time.h - 1.1 include/asm-arm/arch-versatile/timex.h - 1.1 include/asm-arm/arch-versatile/uncompress.h - 1.1 include/asm-arm/arch-versatile/vmalloc.h - 1.1 include/asm-mips/mach-generic/topology.h - 1.1 include/asm-generic/hdreg.h - 1.1 include/asm-i386/mach-default/irq_vectors_limits.h - 1.1 include/asm-i386/mach-generic/irq_vectors_limits.h - 1.1 include/asm-i386/mach-summit/irq_vectors_limits.h - 1.1 include/asm-i386/msi.h - 1.1 include/asm-i386/std_resources.h - 1.1 include/asm-ia64/msi.h - 1.1 include/asm-mips/mach-au1x00/au1100_mmc.h - 1.1 include/asm-mips/mach-au1x00/au1xxx_dbdma.h - 1.1 include/asm-mips/mach-au1x00/au1xxx_psc.h - 1.1 include/linux/audit.h - 1.1 include/asm-mips/mach-ip27/topology.h - 1.1 include/asm-mips/mach-ja/cpu-feature-overrides.h - 1.1 include/asm-mips/mach-ja/spaces.h - 1.1 include/asm-mips/mach-pb1x00/pb1550.h - 1.1 include/asm-s390/qeth.h - 1.1 include/asm-x86_64/msi.h - 1.1 include/linux/netfilter_logging.h - 1.1 include/linux/crc32c.h - 1.1 include/linux/harrier_defs.h - 1.1 include/linux/mqueue.h - 1.1 include/linux/netfilter_ipv4/ip_logging.h - 1.1 include/linux/netfilter_ipv6/ip6_logging.h - 1.1 ipc/mqueue.c - 1.1 include/linux/rmap.h - 1.1 ipc/compat_mq.c - 1.1 kernel/auditsc.c - 1.1 ipc/msgutil.c - 1.1 kernel/audit.c - 1.1 mm/hugetlb.c - 1.1 lib/libcrc32c.c - 1.1 net/ipv4/netfilter/ipt_NOTRACK.c - 1.1 net/ipv4/netfilter/iptable_raw.c - 1.1 net/ipv6/netfilter/ip6table_raw.c - 1.1 arch/mips/pci/pci-lasat.c - 1.3 From owner-linux-xfs@oss.sgi.com Wed May 12 04:37:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 04:38:40 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4CBbQKO010029 for ; Wed, 12 May 2004 04:37:26 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4CBbQ3w010028 for linux-xfs@oss.sgi.com; Wed, 12 May 2004 04:37:26 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4CBbEKQ010014 for ; Wed, 12 May 2004 04:37:18 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4CAiELu005174; Wed, 12 May 2004 03:44:14 -0700 Date: Wed, 12 May 2004 03:44:14 -0700 Message-Id: <200405121044.i4CAiELu005174@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 329] New: XFS filesystem crashes when heavy load occurs on a corrupted filesystem X-Bugzilla-Reason: AssignedTo X-archive-position: 3107 X-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: 2266 Lines: 52 http://oss.sgi.com/bugzilla/show_bug.cgi?id=329 Summary: XFS filesystem crashes when heavy load occurs on a corrupted filesystem Product: Linux XFS Version: Current Platform: AMD URL: http://hiryuu.systemec.nl/~shadur/xfs_error2.txt OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: shadur@systemec.nl I think this problem started after I was having intermittent power failures with my system (short synopsis: The GeForce FX card I'd installed increased the power drain on the PSU to the point where it couldn't handle the load any more and decided which component not to power on a round-robin basis. This led to fairly interesting results of hardware not being detected until I found out what was wrong after I saw one of the fans not powering up.), resulting in a few very improper shutdowns. The system seemed to come up correctly afterwards, so I took no notice of it until the error mentioned in the URL cropped up several times whenever cpu/disk load were heavy. Note that the load didn't *have* to occur on the corrupted disk; /dev/hda7 was /var but this particular crash happened when tar'ing something large in /usr/local/games As a result, /var became inaccessible (and corrupted, as I found out later) but was not properly umounted. In fact, even a SysRq-U didn't manage to umount *any* filesystem, and since the shutdown command relies on data in /var, it didn't work either. The above log was made of the last attempt at running normally before I thought to run xfs_repair from single user mode; note that the nvidia kernel module did not need to be loaded for the problem to occur. xfs_repair managed to fix the damage (although not the corrupted files, but I managed to replace them without any lasting effects) and the system is again in working condition. Kernels used: 2.6.5-love5 and 2.6.6-love1 CPU: AMD Athlon XP 2600+ 1024 MB Ram Distribution: Debian Sid Version of xfsprogs: 2.6.11-1 ------- 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 May 12 05:01:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 05:01:16 -0700 (PDT) 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 i4CC15KO014203 for ; Wed, 12 May 2004 05:01:05 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BNsPo-0007JO-3S; Wed, 12 May 2004 13:00:48 +0100 Date: Wed, 12 May 2004 13:00:47 +0100 From: Christoph Hellwig To: Nathan Scott Cc: Nigel Cunningham , stevew@catalyst.net.nz, "Jeffrey W. Baker" , linux-xfs@oss.sgi.com Subject: Re: XFS for postgres databases? Message-ID: <20040512130047.A28089@infradead.org> References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> <20040512143941.A389759@wobbly.melbourne.sgi.com> <200405121618.27843.ncunningham@linuxmail.org> <20040512165624.C389759@wobbly.melbourne.sgi.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: <20040512165624.C389759@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, May 12, 2004 at 04:56:24PM +1000 X-archive-position: 3108 X-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: 925 Lines: 16 On Wed, May 12, 2004 at 04:56:24PM +1000, Nathan Scott wrote: > Christoph has been working on fixing that up in 2.6, he'll have the > gory details if you're curious. (actually, Christoph/Steve - do we > have to use bdev->bd_inode->i_mapping as the buftarg mapping? what > if we fudged that mapping, then our pages wouldn't overlap with the > block device inode pages - wouldn't that work around this? maybe > Russells hack^Widea of using multiple metadata mappings to overcome > the pagecache size limits would be helped there too...?) We can use a differnt mapping, in fact that's what XFS did before 2.4.10. It's a little bit of additional code, but not a big deal. The real problem with that is that now the blockdev mapping and XFS mapping are compltely unsynchonized, e.g. reading from the blockdev will give you stale data. For xfs_db this means it'll get access to an totally incoherent image of the filesystem. From owner-linux-xfs@oss.sgi.com Wed May 12 05:33:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 05:34:48 -0700 (PDT) Received: from mail5.tpgi.com.au (mail.tpgi.com.au [203.12.160.53]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4CCXjKO015245 for ; Wed, 12 May 2004 05:33:46 -0700 Received: from 203-213-13-45-cbr-ts2-2600.tpgi.com.au (203-213-13-45-cbr-ts2-2600.tpgi.com.au [203.213.13.45]) by mail5.tpgi.com.au (8.12.10/8.12.10) with ESMTP id i4CCXUra009644; Wed, 12 May 2004 22:33:31 +1000 From: Nigel Cunningham Reply-To: ncunningham@linuxmail.org To: Nathan Scott Subject: Re: XFS for postgres databases? Date: Wed, 12 May 2004 22:31:44 +1000 User-Agent: KMail/1.5.3 Cc: stevew@catalyst.net.nz, "Jeffrey W. Baker" , linux-xfs@oss.sgi.com References: <200405121300.14866.stevew@catalyst.net.nz> <200405121618.27843.ncunningham@linuxmail.org> <20040512165624.C389759@wobbly.melbourne.sgi.com> In-Reply-To: <20040512165624.C389759@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405122231.44208.ncunningham@linuxmail.org> X-TPG-Antivirus: Passed X-archive-position: 3109 X-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@linuxmail.org Precedence: bulk X-list: linux-xfs Content-Length: 201 Lines: 10 Hi. Thanks for the explanation. It all helps as I struggle to learn more and more about how the kernel works. Thanks too for not being condescending (I know some people would be). Regards, Nigel From owner-linux-xfs@oss.sgi.com Wed May 12 08:03:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 08:03:19 -0700 (PDT) Received: from gfdlwebshield.gfdl.noaa.gov (mailbox.GFDL.NOAA.GOV [140.208.1.202]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4CF31KO019082 for ; Wed, 12 May 2004 08:03:11 -0700 Received: from mailbox.GFDL.NOAA.GOV(140.208.1.202) by gfdlwebshield.gfdl.noaa.gov via csmap id 78af4ed6_a425_11d8_8dd9_0002b3a99bb9_26631; Wed, 12 May 2004 11:03:15 -0400 (EDT) Received: from gfdlwebshield.gfdl.noaa.gov (majordomo2.GFDL.NOAA.GOV [140.208.1.206]) by mailbox.gfdl.noaa.gov (Netscape Messaging Server 4.15) with ESMTP id HXLWG200.J7R; Wed, 12 May 2004 11:02:26 -0400 Received: from majordomo2.GFDL.NOAA.GOV(140.208.1.206) by gfdlwebshield.gfdl.noaa.gov via csmap id 6de9cd3c_a425_11d8_8aed_0002b3a99bb9_441; Wed, 12 May 2004 11:02:57 -0400 (EDT) Received: from pimdev.gfdl.noaa.gov (root@pimdev [140.208.1.39]) by majordomo2.gfdl.noaa.gov (8.12.10/8.12.10) with ESMTP id i4CF2GdP016109; Wed, 12 May 2004 11:02:16 -0400 Received: from pimdev.gfdl.noaa.gov (smmsp@localhost [127.0.0.1]) by pimdev.gfdl.noaa.gov (8.12.9/8.11.4) with ESMTP id i4CF1miv020343; Wed, 12 May 2004 11:01:48 -0400 Received: (from root@localhost) by pimdev.gfdl.noaa.gov (8.12.9/8.12.4/Submit) id i4CF1m3M020342; Wed, 12 May 2004 11:01:48 -0400 Date: Wed, 12 May 2004 11:01:42 -0400 Message-Id: <1441-Wed12May2004110142-0400-Philip.Macias@NOAA.gov> X-Mailer: emacs 21.2.1 (via feedmail 8 I) To: oar.gfdl.linux-workstations@noaa.gov, cattelan@xfs.org, linux-xfs@oss.sgi.com In-reply-to: <3174-Wed04Feb2004130248-0500-Philip.Macias@NOAA.gov> Subject: Re: xfsrestore fails to exit properly under 2.6.1 From: Phil Macias References: <4229-Wed04Feb2004062354-0500-Philip.Macias@NOAA.gov> <1075916534.96681.5.camel@lupo.thebarn.com> <3174-Wed04Feb2004130248-0500-Philip.Macias@NOAA.gov> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-NAI-Spam-Score: -4.9 X-NAI-Spam-Rules: 1 Rules triggered BAYES_00=-4.9 X-archive-position: 3110 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Philip.Macias@noaa.gov Precedence: bulk X-list: linux-xfs Content-Length: 8471 Lines: 232 All, Finally back at this and have found the fix. The problem was the "xfsrestorehousekeepingdir" files. root: ls -la /clone/xfsrestorehousekeepingdir total 304k drwx------ 2 root root 4.0k May 12 02:19 ./ drwxr-xr-x 3 root root 4.0k May 12 02:19 ../ -rw------- 1 root root 24k May 12 02:07 .nfs000067c200000002 -rw------- 1 root root 39k May 12 02:07 .nfs000067c300000003 -rw------- 1 root root 190k May 12 02:07 .nfs000067c400000004 -rw------- 1 root root 46M May 12 02:06 .nfs000067c500000005 -rw------- 1 root root 36k May 12 02:07 .nfs000067c600000001 -rw------- 1 root root 0 May 12 02:06 .nfs0000685d00000006 In the 2.4.x systems we have that dir could be on the NFS-mounted destination drives with no problem. Evendently they were creating a problem for 2.6.x as they remained locked by some process even after the hanging xfsrestore process was killed. Adding a rm -rf /tmp/xfsrestorehousekeepingdir/ and "-a /tmp" parameter to the cloning script fixed everything. - Phil ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Phil Macias" , RSIS, Inc. * NOAA/GFDL * Princeton, NJ ___,___ |_|_, 609 987 5059 office | 609 203 5874 cell >__, | Date: 4 Feb 2004 13:02:49 -0500 | Bcc: root@pimdev.gfdl.noaa.gov | Date: Wed, 4 Feb 2004 13:02:48 -0500 | CC: Philip.Macias@noaa.gov, linux-xfs@oss.sgi.com | From: Phil Macias | | Here you go: | | root: ~# gdb --pid=7896 | GNU gdb Red Hat Linux (5.2-2) | Copyright 2002 Free Software Foundation, Inc. | GDB is free software, covered by the GNU General Public License, and you are | welcome to change it and/or distribute copies of it under certain conditions. | Type "show copying" to see the conditions. | There is absolutely no warranty for GDB. Type "show warranty" for details. | This GDB was configured as "i386-redhat-linux". | Attaching to process 7896 | Reading symbols from /usr/sbin/xfsrestore...done. | Reading symbols from /usr/lib/libhandle.so.1...done. | Loaded symbols for /usr/lib/libhandle.so.1 | Reading symbols from /usr/lib/libattr.so.1...done. | Loaded symbols for /usr/lib/libattr.so.1 | Reading symbols from /lib/libc.so.6...done. | Loaded symbols for /lib/libc.so.6 | Reading symbols from /usr/lib/libgcc_s.so.1...done. | Loaded symbols for /usr/lib/libgcc_s.so.1 | Reading symbols from /lib/ld-linux.so.2...done. | Loaded symbols for /lib/ld-linux.so.2 | 0x4010c566 in open64 () from /lib/libc.so.6 | | (gdb) backtrace | #0 0x4010c566 in open64 () from /lib/libc.so.6 | #1 0x400e4dd9 in opendir () from /lib/libc.so.6 | #2 0x08073a0b in wipepersstate () at content.c:3600 | #3 0x08072701 in content_complete () at content.c:2587 | #4 0x08062de7 in main (argc=4, argv=0xbffff514) at main.c:636 | #5 0x4004ed06 in __libc_start_main () from /lib/libc.so.6 | | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | "Phil Macias" , | | RSIS, Inc. * NOAA/GFDL * Princeton, NJ | | ___,___ | |_|_, 609 987 5059 office | | 609 203 5874 cell | >__, | | | | From: Russell Cattelan | | Cc: linux-xfs@oss.sgi.com | | Date: Wed, 04 Feb 2004 11:42:14 -0600 | | | | Are you able to attach gdb to the hung process and | | get a backtrace? | | | | On Wed, 2004-02-04 at 05:23, Phil Macias wrote: | | > Hello, | | > | | > We have been using XFS on RedHat linux for over two years (since I | | > have been here). I have been using a script to clone workstations from | | > one-another for over a year whereby the host-to-be-cloned exports it's | | > XFS partitions over NFS and they are mounted by the donor host and | | > contents copied with: | | > | | > xfsdump -v5 -l 0 - /dev/hda7 | xfsrestore -v5 - /clone-var | | > | | > This process worked reliably for over a year on the 2.4.x kernels and | | > these versions of xfs tools: | | > | | > acl-2.1.1-gfdl-1-1 | | > attr-2.1.1-gfdl-1-1 | | > dmapi-2.0.5-gfdl-1-1 | | > kernel-2.4.18-XFS-NFS-base-gfdl-2-1 | | > xfsdump-2.2.4-gfdl-1-1 | | > xfsprogs-2.3.6-gfdl-1-1 | | > | | > PROBLEM: I am testing the 2.6.1 kernel and the following relevant | | > packages: | | > | | > libelf-0.8.2-2-gfdl-1-1 | | > elfutils-libelf-0.89-2-gfdl-1-1 | | > popt-1.8.1-0.31-gfdl-1-1 | | > gcc-3.3-gfdl-1-1 | | > kernel-2.6.0-complete-gfdl-1-1 | | > glibc-2.3.2-gfdl-1-1 | | > beecrypt-3.0.1-gfdl-1-1 | | > | | > acl-2.2.21-gfdl.tgz | | > attr-2.4.12-gfdl.tgz | | > binutils-2.14-gfdl.tgz | | > dmapi-2.1.0-gfdl.tgz | | > xfsprogs-2.6.0-gfdl.tgz | | > | | > Everything on the system works well except the remote | | > xfsdump/xfsrestore. Running: | | > | | > xfsdump -v5 -l 0 - /dev/hda7 | xfsrestore -v5 - /clone-var | | > | | > on the 2.6.1 system does dump/restore properly, but xfsrestore never | | > exits. I have to issue these commands to release xfsrestore: | | > | | > kill % | | > fuser -k /clone-var/ | | > | | > ...where /clone-var/ is the target partition. Please note that | | > the target host is still running the old (2.4.x) kernel. | | > | | > Here are the last lines to the "-v5" output: | | > | | > ... | | > xfsrestore: read file hdr off 0 flags 0x0 ino 14680333 mode 0x0000a1ff | | > xfsrestore: preemptchk( ) | | > xfsrestore: restoring lib/scrollkeeper/pt_BR (14680333 0) | | > xfsrestore: restoring symbolic link ino 14680333 lib/scrollkeeper/pt_BR | | > xfsrestore: drive_simple read( want 32 ) | | > xfsrestore: drive_simple return_read_buf( returning 32 ) | | > xfsrestore: xlate_extenthdr | | > xfsrestore: read extent hdr size 32 offset 0 type 4 flags 00000000 | | > xfsrestore: drive_simple read( want 32 ) | | > xfsrestore: drive_simple return_read_buf( returning 32 ) | | > xfsrestore: drive_simple get_mark( ) | | > xfsrestore: drive_simple read( want 256 ) | | > xfsrestore: drive_simple return_read_buf( returning 256 ) | | > xfsrestore: xlate_bstat | | > xfsrestore: xlate_bstat: pre-xlate | | > bs_ino 0 | | > bs_mode 0 | | > xfsrestore: xlate_bstat: post-xlate | | > bs_ino 0 | | > bs_mode 0 | | > xfsrestore: xlate_filehdr: pre-xlate | | > fh_offset 0 | | > fh_flags 83886080 | | > fh_checksum 13835040720794157312 | | > xfsrestore: xlate_filehdr: post-xlate | | > fh_offset 0 | | > fh_flags 5 | | > fh_checksum 13835040720794157312 | | > xfsrestore: read file hdr off 0 flags 0x5 ino 0 mode 0x00000000 | | > xfsrestore: preemptchk( ) | | > xfsrestore: Media_end: pos=3D=3D3 | | > xfsrestore: drive_simple end_read( ) | | > xfsrestore: getting next media file for non-dir restore | | > xfsrestore: Media_mfile_next: purp=3D=3D2 pos=3D=3D0 | | > xfsrestore: tree finalize | | > xfsrestore: restore complete: 139 seconds elapsed | | > ------------------------------------------------- | | > | | > Syslog shows no erors or any info about xfsrestore. | | > | | > Any idea why xfsrestore fails to exit properly? | | > | | > Thanx, | | > | | > | | > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | > "Phil Macias" , | | > | | > RSIS, Inc. * NOAA/GFDL * Princeton, NJ | | > | | > ___,___ | | > |_|_, 609 987 5059 office | | > | 609 203 5874 cell | | > >__, | | > | | > | | > | | -- | | Russell Cattelan | | | | --=-P/55uI4EMIJNOPBs/njs | | 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 (FreeBSD) | | | | iD8DBQBAIS72NRmM+OaGhBgRApgsAJ91dL40QRuf489yvuWP0edD5CW3mgCePnHE | | jJKK3969prkDV3Ty8A15YcE= | | =PMku | | -----END PGP SIGNATURE----- | | | | --=-P/55uI4EMIJNOPBs/njs-- | | | | | | From owner-linux-xfs@oss.sgi.com Wed May 12 08:54:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 08:54:23 -0700 (PDT) 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 i4CFsGKO023792 for ; Wed, 12 May 2004 08:54:16 -0700 Received: from noodles (adsl-64-163-212-234.dsl.snfc21.pacbell.net [64.163.212.234]) by mta7.pltn13.pbi.net (8.12.10/8.12.10) with ESMTP id i4CFsFNw019015; Wed, 12 May 2004 08:54:15 -0700 (PDT) Received: from jwb by noodles with local (Exim 3.36 #1 (Debian)) id 1BNw3t-0003XA-00; Wed, 12 May 2004 08:54:25 -0700 Subject: Re: XFS for postgres databases? From: "Jeffrey W. Baker" To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040512143941.A389759@wobbly.melbourne.sgi.com> References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> <20040512143941.A389759@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1084377264.13559.3.camel@noodles> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 12 May 2004 08:54:25 -0700 X-archive-position: 3111 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jwbaker@acm.org Precedence: bulk X-list: linux-xfs Content-Length: 1326 Lines: 30 On Tue, 2004-05-11 at 21:39, Nathan Scott wrote: > On Tue, May 11, 2004 at 08:30:08PM -0700, Jeffrey W. Baker wrote: > > On Tue, 2004-05-11 at 18:00, Steve Wray wrote: > > > Hi there, > > > I'd just like to know if anyone knows of any issues with running a > > > postgres database on an XFS filesystem in Linux? > > > > > > We did this a few weeks ago and the DB Admin swears that they have been > > > seeing problems. I'm not convinced that the problems are XFS related. > > > > Until a few days ago I had a very large postgresql installation on XFS. > > We suffered very unusual problems like corrupt tables, missing rows, > > corrupt indexes, and so forth. > > You were running dd on the block device at the same time as using > the mounted filesystem though, weren't you? Did problems persist > after you stopped doing that? You didn't get back to us with any > further details there.. That was an entirely separate host/filesystem. On the postgresql server we weren't mucking around with the disk by hand, just running postgresql. Although I'd love to try to debug these problems I have limited time to do so. We aren't exactly a huge shop here, I have to get my applications working and then move on to the next task. Reporting my observations might be the limit of my usefulness for the time being. -jwb From owner-linux-xfs@oss.sgi.com Wed May 12 10:09:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 10:09:56 -0700 (PDT) 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 i4CH9lKO026947 for ; Wed, 12 May 2004 10:09:48 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BNxEm-00085P-NB; Wed, 12 May 2004 18:09:44 +0100 Date: Wed, 12 May 2004 18:09:44 +0100 From: Christoph Hellwig To: Gustavo Franco Cc: linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Problems with RAID1 using SATA disks. Message-ID: <20040512180944.A31062@infradead.org> References: <40A255D5.3090602@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40A255D5.3090602@acm.org>; from stratus@acm.org on Wed, May 12, 2004 at 01:50:29PM -0300 X-archive-position: 3112 X-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: 792 Lines: 16 On Wed, May 12, 2004 at 01:50:29PM -0300, Gustavo Franco wrote: > I've already reported[0] my problem on Apr 12, with few details on > lkml.Since then, only Steve Lord (xfs) have replied to me writing that > Christoph was looking into it.I'll explain my problem here again, since > with my new tests i can see clearly that it isn't a xfs problem.I just don't > known if it's a hardware, software raid or libata problem. The thing at [0] certainly is not a raid problem. Most likely it's a XFS problem although there's a small but non-zero chance that either the VFS or nfsd are at fault. I currently have a bunch of more important issue on my plate, but for now the patch at: http://oss.sgi.com/bugzilla/attachment.cgi?id=108&action=view should fix it at the cost of slower deletions. From owner-linux-xfs@oss.sgi.com Wed May 12 10:45:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 10:45:50 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4CHjlKO027906 for ; Wed, 12 May 2004 10:45:47 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4CHjlFN027903 for linux-xfs@oss.sgi.com; Wed, 12 May 2004 10:45:47 -0700 Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4CHjiKO027890; Wed, 12 May 2004 10:45:44 -0700 Received: from taniwha.stupidest.org (adsl-68-120-154-124.dsl.snfc21.pacbell.net [68.120.154.124]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i4CHjgdg225494; Wed, 12 May 2004 13:45:42 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id B2FBB14A6A; Wed, 12 May 2004 10:45:41 -0700 (PDT) Date: Wed, 12 May 2004 10:45:41 -0700 From: Chris Wedgwood To: bugzilla-daemon@oss.sgi.com Cc: xfs-master@oss.sgi.com, shadur@systemec.nl Subject: Re: [Bug 329] New: XFS filesystem crashes when heavy load occurs on a corrupted filesystem Message-ID: <20040512174541.GA4750@taniwha.stupidest.org> References: <200405121044.i4CAiELu005174@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200405121044.i4CAiELu005174@oss.sgi.com> X-archive-position: 3113 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 575 Lines: 19 On Wed, May 12, 2004 at 03:44:14AM -0700, bugzilla-daemon@oss.sgi.com wrote: > I think this problem started after I was having intermittent power > failures with my system If you were running a system with unreliable power, so all bets are off. The oopse you have shows the kernel was tainted so I assume you are using the proprietary NV driver. Please ensure the power supply is reliable and you are not running the nv driver and see if this problem occurs again. > Kernels used: 2.6.5-love5 and 2.6.6-love1 What are -love kernels and do they use 4K stacks? --cw From owner-linux-xfs@oss.sgi.com Wed May 12 13:42:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 13:42:33 -0700 (PDT) Received: from mail2.catalyst.net.nz (godel.catalyst.net.nz [202.49.159.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4CKgTKO005895 for ; Wed, 12 May 2004 13:42:30 -0700 Received: from leibniz.catalyst.net.nz ([202.49.159.7] helo=shankara.wgtn.cat-it.co.nz) by mail2.catalyst.net.nz with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.35 #1 (Debian)) id 1BO0YY-0004pN-02 for ; Thu, 13 May 2004 08:42:22 +1200 From: Steve Wray Reply-To: stevew@catalyst.net.nz To: linux-xfs@oss.sgi.com Subject: Re: XFS for postgres databases? Date: Thu, 13 May 2004 08:42:20 +1200 User-Agent: KMail/1.6.1 References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> <20040512143941.A389759@wobbly.melbourne.sgi.com> In-Reply-To: <20040512143941.A389759@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405130842.20652.stevew@catalyst.net.nz> X-System-Filter-Id: mail2.catalyst.net.nz 1BO0YY-0004pN-02 X-Virus-Scanned-By: Amavis with CLAM Anti Virus on mail2.catalyst.net.nz X-archive-position: 3114 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stevew@catalyst.net.nz Precedence: bulk X-list: linux-xfs Content-Length: 1275 Lines: 28 On Wednesday 12 May 2004 16:39, Nathan Scott wrote: > On Tue, May 11, 2004 at 08:30:08PM -0700, Jeffrey W. Baker wrote: > > On Tue, 2004-05-11 at 18:00, Steve Wray wrote: > > > Hi there, > > > I'd just like to know if anyone knows of any issues with running > > > a postgres database on an XFS filesystem in Linux? > > > > > > We did this a few weeks ago and the DB Admin swears that they > > > have been seeing problems. I'm not convinced that the problems > > > are XFS related. > > > > Until a few days ago I had a very large postgresql installation on > > XFS. We suffered very unusual problems like corrupt tables, missing > > rows, corrupt indexes, and so forth. > > You were running dd on the block device at the same time as using > the mounted filesystem though, weren't you? Did problems persist > after you stopped doing that? You didn't get back to us with any > further details there.. > > Do you (either of you) have a test case so we can try to reproduce > these problems locally? Unfortunately this was on the database of a very sensitive client so we have scrubbed XFS and reverted to ext2. So I can't reproduce the problem at all. I'll have a chat with the database developers and admins and see if we can construct a test case on a development box. From owner-linux-xfs@oss.sgi.com Wed May 12 15:10:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 15:10:50 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4CMAkKO016072 for ; Wed, 12 May 2004 15:10:46 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4CMAkjZ016069 for linux-xfs@oss.sgi.com; Wed, 12 May 2004 15:10:46 -0700 Received: from mirapoint5.brutele.be (mirapoint5.brutele.be [212.68.203.254]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4CMAgKO016056; Wed, 12 May 2004 15:10:43 -0700 Received: from yoko (212.68.250.184.brutele.be [212.68.250.184]) by mirapoint5.brutele.be (MOS 3.4.5-GR) with ESMTP id AKV04523; Wed, 12 May 2004 23:42:51 +0200 (CEST) Subject: Re: [Bug 329] New: XFS filesystem crashes when heavy load occurs on a corrupted filesystem From: Stijn Vander Maelen Reply-To: stijn@sunshine.rave.org To: Chris Wedgwood Cc: bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com, shadur@systemec.nl In-Reply-To: <20040512174541.GA4750@taniwha.stupidest.org> References: <200405121044.i4CAiELu005174@oss.sgi.com> <20040512174541.GA4750@taniwha.stupidest.org> Content-Type: text/plain Organization: Infogroep Message-Id: <1084398207.12640.7.camel@yoko> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 12 May 2004 23:43:27 +0200 Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=0/50, host=mirapoint5.brutele.be X-archive-position: 3115 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stijn@sunshine.rave.org Precedence: bulk X-list: linux-xfs Content-Length: 754 Lines: 30 On Wed, 2004-05-12 at 19:45, Chris Wedgwood wrote: > On Wed, May 12, 2004 at 03:44:14AM -0700, bugzilla-daemon@oss.sgi.com wrote: > > > Kernels used: 2.6.5-love5 and 2.6.6-love1 > > What are -love kernels and do they use 4K stacks? > http://oneofone.limitlessfx.com/love-sources/ and in the release notes one finds: make-4k-stacks-permanent.patch| reversed to fix nvidia crap I remember people not being happy with the -love sources, it was pretty unstable according to some people. "love-sources is not in portage. Basically this is mm-sources plus some even less tested, even more unstable patches." (searched the gentoo forums for lovesources+unstable) regards, stijn > > --cw -- Stijn Vander Maelen Infogroep From owner-linux-xfs@oss.sgi.com Wed May 12 15:18:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 15:18:34 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4CMIUKO016665 for ; Wed, 12 May 2004 15:18:30 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4CMITZo016661 for linux-xfs@oss.sgi.com; Wed, 12 May 2004 15:18:29 -0700 Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4CMIQKO016648; Wed, 12 May 2004 15:18:27 -0700 Received: from taniwha.stupidest.org (adsl-68-120-154-124.dsl.snfc21.pacbell.net [68.120.154.124]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i4CMIFdg092464; Wed, 12 May 2004 18:18:15 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 69CF114A6A; Wed, 12 May 2004 15:18:15 -0700 (PDT) Date: Wed, 12 May 2004 15:18:15 -0700 From: Chris Wedgwood To: Stijn Vander Maelen Cc: bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com, shadur@systemec.nl Subject: Re: [Bug 329] New: XFS filesystem crashes when heavy load occurs on a corrupted filesystem Message-ID: <20040512221815.GA14758@taniwha.stupidest.org> References: <200405121044.i4CAiELu005174@oss.sgi.com> <20040512174541.GA4750@taniwha.stupidest.org> <1084398207.12640.7.camel@yoko> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1084398207.12640.7.camel@yoko> X-archive-position: 3116 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 566 Lines: 17 On Wed, May 12, 2004 at 11:43:27PM +0200, Stijn Vander Maelen wrote: > I remember people not being happy with the -love sources, it was > pretty unstable according to some people. "love-sources is not in > portage. Basically this is mm-sources plus some even less tested, > even more unstable patches." (searched the gentoo forums for > lovesources+unstable) I think the point here then should be: "make sure the bug exists in either a mainline or oss.sgi.com kernel before reporting it" There are too many other variables to consider otherwise. --cw From owner-linux-xfs@oss.sgi.com Wed May 12 15:52:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 15:52:22 -0700 (PDT) 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 i4CMqDKO019448 for ; Wed, 12 May 2004 15:52:14 -0700 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 i4CMjoT9031999 for ; Wed, 12 May 2004 17:45:51 -0500 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 IAA15942; Thu, 13 May 2004 08:45:44 +1000 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 i4CMjgln413459; Thu, 13 May 2004 08:45:42 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4CMjcDJ411979; Thu, 13 May 2004 08:45:38 +1000 (EST) Date: Thu, 13 May 2004 08:45:38 +1000 From: Nathan Scott To: Bart Samwel Cc: Andrew Morton , linux-xfs@oss.sgi.com Subject: Re: [patch 1/1] Update laptop mode control script with XFS_HZ=100 Message-ID: <20040513084538.E389759@wobbly.melbourne.sgi.com> References: <20040511154057.6d6c193b.akpm@osdl.org> <20040512090006.B362314@wobbly.melbourne.sgi.com> <40A1D7E3.8020700@samwel.tk> <20040512010453.196fc8c9.akpm@osdl.org> <40A1DB7B.2080600@samwel.tk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <40A1DB7B.2080600@samwel.tk>; from bart@samwel.tk on Wed, May 12, 2004 at 10:08:27AM +0200 X-archive-position: 3117 X-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: 961 Lines: 29 On Wed, May 12, 2004 at 10:08:27AM +0200, Bart Samwel wrote: > Andrew Morton wrote: > > > Bart Samwel wrote: > > > >> >>aargh. XFS is broken. It shouldn't be exposing jiffy-based tunables into > >> >>/proc, or `mount -o remount' or whatever. > >> >> > >> >>It would be much better to rework XFS so that these user-visible tunables > >> >>are in units of milliseconds, centiseconds or whatever. > >> > >> They're in USER_HZ since 2.6.6. Andrew, is that OK or should they really > >> be in some even more fixed unit? > > > > All architectures have USER_HZ=100. But it's a bit nicer and future-proof > > to relabel it as centiseconds. > > Agreed. Nathan, I'll make a patch for this. I've already done that - I've sent it out to the other XFS guys for review before I merge it in (haven't got to the bottom of my mail box yet, so not sure if it survived that process :) ... I'll merge it later today if it looks OK. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed May 12 17:22:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 May 2004 17:22:19 -0700 (PDT) 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 i4D0MDKO025468 for ; Wed, 12 May 2004 17:22:14 -0700 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 i4D09lT9026951 for ; Wed, 12 May 2004 19:09:48 -0500 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 i4D09fAL36145078 for ; Thu, 13 May 2004 10:09:41 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4D09eXU67030379 for linux-xfs@oss.sgi.com; Thu, 13 May 2004 10:09:40 +1000 (EST) Date: Thu, 13 May 2004 10:09:40 +1000 (EST) From: Nathan Scott Message-Id: <200405130009.i4D09eXU67030379@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfsprogs X-archive-position: 3118 X-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: 507 Lines: 18 Update Debian packaging in xfsprogs; revert a logprint arg handling thinko picked up by the regression tests. Date: Wed May 12 17:08:14 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:171728a xfsprogs/VERSION - 1.108 xfsprogs/doc/CHANGES - 1.148 xfsprogs/logprint/logprint.c - 1.14 xfsprogs/debian/control - 1.17 xfsprogs/debian/changelog - 1.97 From owner-linux-xfs@oss.sgi.com Thu May 13 06:19:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 06:19:56 -0700 (PDT) Received: from shksmtp02.so-net.com.hk (pop.so-net.com.hk [203.99.142.22] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4DDJoKO022064 for ; Thu, 13 May 2004 06:19:51 -0700 Received: (qmail 26067 invoked from network); 12 May 2004 13:53:34 -0000 Received: from so176180.bbo176.so-net.com.hk (HELO [203.176.176.180]) ([203.176.176.180]) (envelope-sender ) by shksmtp02.so-net.com.hk (qmail-ldap-1.03) with SMTP for ; 12 May 2004 13:53:34 -0000 Message-ID: <40A22CA8.5090300@linuxmail.org> Date: Wed, 12 May 2004 21:54:48 +0800 From: Feizhou User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jeffrey W. Baker" CC: stevew@catalyst.net.nz, linux-xfs@oss.sgi.com Subject: Re: XFS for postgres databases? References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> In-Reply-To: <1084332608.11308.3.camel@noodles> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3119 X-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: 756 Lines: 21 Jeffrey W. Baker wrote: > On Tue, 2004-05-11 at 18:00, Steve Wray wrote: > >>Hi there, >>I'd just like to know if anyone knows of any issues with running a >>postgres database on an XFS filesystem in Linux? >> >>We did this a few weeks ago and the DB Admin swears that they have been >>seeing problems. I'm not convinced that the problems are XFS related. > > > Until a few days ago I had a very large postgresql installation on XFS. > We suffered very unusual problems like corrupt tables, missing rows, > corrupt indexes, and so forth. We've never seen those problems on ext2, > to which we have since switched back. > Why would you put a database on a meta data journaling only filesystem? What's wrong with ext3 full journal? (data=journal) From owner-linux-xfs@oss.sgi.com Thu May 13 06:25:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 06:25:21 -0700 (PDT) Received: from diablo.celestial.com (diablo.celestial.com [192.136.111.52]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4DDPAKO022526 for ; Thu, 13 May 2004 06:25:10 -0700 Received: from localhost (localhost [127.0.0.1]) by diablo.celestial.com (Postfix) with ESMTP id 264A42059A; Thu, 13 May 2004 06:25:09 -0700 (PDT) Received: from linux-sxs.org (d60-54-189.col.wideopenwest.com [65.60.189.54]) by diablo.celestial.com (Postfix) with ESMTP id 055022070F; Thu, 13 May 2004 06:24:54 -0700 (PDT) Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.11/8.12.11) with ESMTP id i4DCS8WR032298; Thu, 13 May 2004 08:28:08 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.11/8.12.10/Submit) with ESMTP id i4DCS8OF032295; Thu, 13 May 2004 08:28:08 -0400 Date: Thu, 13 May 2004 08:28:08 -0400 (EDT) From: Net Llama! To: Feizhou Cc: "Jeffrey W. Baker" , stevew@catalyst.net.nz, linux-xfs@oss.sgi.com Subject: Re: XFS for postgres databases? In-Reply-To: <40A22CA8.5090300@linuxmail.org> Message-ID: References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> <40A22CA8.5090300@linuxmail.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Virus-Scanned: by amavisd-new at celestial.com X-archive-position: 3120 X-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: 1016 Lines: 29 On Wed, 12 May 2004, Feizhou wrote: > Jeffrey W. Baker wrote: > > On Tue, 2004-05-11 at 18:00, Steve Wray wrote: > > > >>Hi there, > >>I'd just like to know if anyone knows of any issues with running a > >>postgres database on an XFS filesystem in Linux? > >> > >>We did this a few weeks ago and the DB Admin swears that they have been > >>seeing problems. I'm not convinced that the problems are XFS related. > > > > > > Until a few days ago I had a very large postgresql installation on XFS. > > We suffered very unusual problems like corrupt tables, missing rows, > > corrupt indexes, and so forth. We've never seen those problems on ext2, > > to which we have since switched back. > > > > Why would you put a database on a meta data journaling only filesystem? > > What's wrong with ext3 full journal? (data=journal) Its ext3 :) -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Thu May 13 07:51:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 07:52:10 -0700 (PDT) Received: from zero.aec.at (Aramis_Jukes@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4DEpsKO025065 for ; Thu, 13 May 2004 07:51:55 -0700 Received: from averell.firstfloor.org.muc.de (Golgo_Brone@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id i4DEpnD18317; Thu, 13 May 2004 16:51:50 +0200 To: Feizhou cc: jwbaker@acm.org, linux-xfs@oss.sgi.com Subject: Re: XFS for postgres databases? References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> <40A22CA8.5090300@linuxmail.org> From: Andi Kleen Date: Thu, 13 May 2004 16:51:21 +0200 In-Reply-To: <40A22CA8.5090300@linuxmail.org> (feizhou@linuxmail.org's message of "Wed, 12 May 2004 21:54:48 +0800") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3121 X-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: 640 Lines: 16 Feizhou writes: > > Why would you put a database on a meta data journaling only filesystem? Databases do their own journaling. Doing another journaling layer for the data in the file system is just a waste of IO bandwidth. In addition the data journaling in the file system is quite useless for this because the fs doesn't have any idea about the transaction boundaries the database needs. The database tells the file system about them using fsync() or synchronous writes, and there is not much difference between a data journaling and not data journaling fs for this - both will flush the blocks to disk. -Andi From owner-linux-xfs@oss.sgi.com Thu May 13 08:13:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 08:13:10 -0700 (PDT) Received: from khe-mailhub1.eigner.com (khe-mailhub1.eigner.com [194.120.231.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4DFD2KO025843 for ; Thu, 13 May 2004 08:13:02 -0700 Received: from agile.com (unknown [10.15.120.15]) by khe-mailhub1.eigner.com (Postfix) with ESMTP id 416BE64D; Thu, 13 May 2004 17:09:09 +0200 (CEST) Message-ID: <40A38FB6.9030005@agile.com> Date: Thu, 13 May 2004 17:09:42 +0200 From: Klaus Strebel Organization: Agile Software GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: de, de-de, en, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: bart@samwel.tk Subject: Build XFS as module is broken Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-agile-MailScanner-Information: Please contact the ISP for more information X-agile-MailScanner: Found to be clean X-agile-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-105.7, required 5, AWL 0.00, BAYES_00 -5.20, SIGNATURE_LONG_SPARSE -0.49, USER_AGENT_MOZILLA_UA 0.00, USER_IN_WHITELIST -100.00) X-MailScanner-From: klaus.strebel@agile.com X-archive-position: 3122 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@agile.com Precedence: bulk X-list: linux-xfs Content-Length: 449 Lines: 22 Hi all, tried to build from the current linux-2.6 cvs tree. Fails with unresolved symbol 'laptop_mode' :-(. Works with static nonmod build. EXPORT_SYMBOL(laptop_mode) in mm/page-writeback.c does the trick. Ciao Klaus -- Klaus Strebel UNIX-Engineer Agile Software GmbH How Products Become Profits (TM) Ruschgraben 133 D-76139 Karlsruhe Office: +49 721 6291 0 Fax: +49 721 6291 1204 URL: From owner-linux-xfs@oss.sgi.com Thu May 13 08:41:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 08:41:19 -0700 (PDT) Received: from io.goeci.com (IO.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4DFfGKO029650 for ; Thu, 13 May 2004 08:41:16 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Subject: RE: XFS for postgres databases? Date: Thu, 13 May 2004 11:41:07 -0400 Message-ID: <3554BFA5FAE4B14FB5459D36E4F4E36203D9CF@io.goeci.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS for postgres databases? Thread-Index: AcQ3vLB/rqNWDsQkQtq3fQ8JulEfIABQrm0A From: "Murthy Kambhampaty" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i4DFfGKO029652 X-archive-position: 3123 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs Content-Length: 1354 Lines: 37 We run postgresql on xfs (over LVM) on hardware raid (raid 50) with internal logs, and have done so for years now. Great performance, no data loss. In addition, xfs_freeze is very useful for doing backups: 1.) rsync from $PGDATA to a copy location 2.) xfs_freeze -u $PGDATA 3.) repeat the rsync 4.) xfs_freeze -u $PGDATA Online backups without pain. (we used to do it with snapshots, but LVM snapshots don't appear to be 100% reliable, so we live with the freeze which is at most several seconds long) I will note the server runs nothing but postgresql. Secondly, all changes -- kernel upgrades, version upgrades, etc. -- are first tested and allowed to "soak in" on a test server, before they are applied to the production server. All in all, your skepticism is well justified. HTH, Murthy > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com]On Behalf Of Steve Wray > Sent: Tuesday, May 11, 2004 9:00 PM > To: linux-xfs@oss.sgi.com > Subject: XFS for postgres databases? > > > Hi there, > I'd just like to know if anyone knows of any issues with running a > postgres database on an XFS filesystem in Linux? > > We did this a few weeks ago and the DB Admin swears that they > have been > seeing problems. I'm not convinced that the problems are XFS related. > > Thanks! > > > From owner-linux-xfs@oss.sgi.com Thu May 13 09:03:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 09:03:44 -0700 (PDT) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4DG3fKO030265 for ; Thu, 13 May 2004 09:03:42 -0700 Received: from bsamwel by samwel.tk with local (Exim 4.33) id 1BOIgJ-00016A-1i; Thu, 13 May 2004 18:03:35 +0200 Subject: Re: Build XFS as module is broken From: Bart Samwel Reply-To: bart@samwel.tk To: Klaus Strebel Cc: XFS mailing list In-Reply-To: <40A38FB6.9030005@agile.com> References: <40A38FB6.9030005@agile.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1084464214.31385.13.camel@samwel.tk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 13 May 2004 18:03:34 +0200 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: bsamwel@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 3124 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 447 Lines: 14 On Thu, 2004-05-13 at 17:09, Klaus Strebel wrote: > Hi all, > > tried to build from the current linux-2.6 cvs tree. Fails with > unresolved symbol 'laptop_mode' :-(. Works with static nonmod build. > > EXPORT_SYMBOL(laptop_mode) in mm/page-writeback.c does the trick. Thanks for the report. Apparently a patch was forgotten, because I do remember submitting one that did this. I submitted a patch to Andrew Morton to add this export. --Bart From owner-linux-xfs@oss.sgi.com Thu May 13 09:12:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 09:12:04 -0700 (PDT) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4DGBxKO030859 for ; Thu, 13 May 2004 09:11:59 -0700 Received: from noodles (adsl-64-160-55-212.dsl.snfc21.pacbell.net [64.160.55.212]) by mta4.rcsntx.swbell.net (8.12.10/8.12.10) with ESMTP id i4DGBQGp014966; Thu, 13 May 2004 11:11:27 -0500 (CDT) Received: from jwb by noodles with local (Exim 3.36 #1 (Debian)) id 1BOIo3-0004je-00; Thu, 13 May 2004 09:11:35 -0700 Subject: Re: XFS for postgres databases? From: "Jeffrey W. Baker" To: Net Llama! Cc: Feizhou , stevew@catalyst.net.nz, linux-xfs@oss.sgi.com In-Reply-To: References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> <40A22CA8.5090300@linuxmail.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1084464695.18156.8.camel@noodles> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 13 May 2004 09:11:35 -0700 X-archive-position: 3125 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jwbaker@acm.org Precedence: bulk X-list: linux-xfs Content-Length: 1058 Lines: 28 On Thu, 2004-05-13 at 05:28, Net Llama! wrote: > On Wed, 12 May 2004, Feizhou wrote: > > Jeffrey W. Baker wrote: > > > On Tue, 2004-05-11 at 18:00, Steve Wray wrote: > > > > > >>Hi there, > > >>I'd just like to know if anyone knows of any issues with running a > > >>postgres database on an XFS filesystem in Linux? > > >> > > >>We did this a few weeks ago and the DB Admin swears that they have been > > >>seeing problems. I'm not convinced that the problems are XFS related. > > > > > > > > > Until a few days ago I had a very large postgresql installation on XFS. > > > We suffered very unusual problems like corrupt tables, missing rows, > > > corrupt indexes, and so forth. We've never seen those problems on ext2, > > > to which we have since switched back. > > > > > > > Why would you put a database on a meta data journaling only filesystem? > > > > What's wrong with ext3 full journal? (data=journal) Postgres is a journalling database, so it's safe on any FS. I like to use a journalling FS because it's no fun to fsck several terabytes. -jwb From owner-linux-xfs@oss.sgi.com Thu May 13 09:13:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 09:13:04 -0700 (PDT) Received: from diablo.celestial.com (diablo.celestial.com [192.136.111.52]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4DGCvKO031055 for ; Thu, 13 May 2004 09:12:57 -0700 Received: from localhost (localhost [127.0.0.1]) by diablo.celestial.com (Postfix) with ESMTP id 920D320735; Thu, 13 May 2004 09:12:56 -0700 (PDT) Received: from linux-sxs.org (d60-54-189.col.wideopenwest.com [65.60.189.54]) by diablo.celestial.com (Postfix) with ESMTP id 82E60295C; Thu, 13 May 2004 09:12:54 -0700 (PDT) Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.11/8.12.11) with ESMTP id i4DFG90w013492; Thu, 13 May 2004 11:16:09 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.11/8.12.10/Submit) with ESMTP id i4DFG98e013489; Thu, 13 May 2004 11:16:09 -0400 Date: Thu, 13 May 2004 11:16:09 -0400 (EDT) From: Net Llama! To: "Jeffrey W. Baker" Cc: Feizhou , stevew@catalyst.net.nz, linux-xfs@oss.sgi.com Subject: Re: XFS for postgres databases? In-Reply-To: <1084464695.18156.8.camel@noodles> Message-ID: References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> <40A22CA8.5090300@linuxmail.org> <1084464695.18156.8.camel@noodles> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Virus-Scanned: by amavisd-new at celestial.com X-archive-position: 3126 X-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: 1342 Lines: 34 On Thu, 13 May 2004, Jeffrey W. Baker wrote: > On Thu, 2004-05-13 at 05:28, Net Llama! wrote: > > On Wed, 12 May 2004, Feizhou wrote: > > > Jeffrey W. Baker wrote: > > > > On Tue, 2004-05-11 at 18:00, Steve Wray wrote: > > > > > > > >>Hi there, > > > >>I'd just like to know if anyone knows of any issues with running a > > > >>postgres database on an XFS filesystem in Linux? > > > >> > > > >>We did this a few weeks ago and the DB Admin swears that they have been > > > >>seeing problems. I'm not convinced that the problems are XFS related. > > > > > > > > > > > > Until a few days ago I had a very large postgresql installation on XFS. > > > > We suffered very unusual problems like corrupt tables, missing rows, > > > > corrupt indexes, and so forth. We've never seen those problems on ext2, > > > > to which we have since switched back. > > > > > > > > > > Why would you put a database on a meta data journaling only filesystem? > > > > > > What's wrong with ext3 full journal? (data=journal) > > Postgres is a journalling database, so it's safe on any FS. I like to > use a journalling FS because it's no fun to fsck several terabytes. XFS has no fsck -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Thu May 13 11:04:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 11:04:51 -0700 (PDT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4DI4lKO003501 for ; Thu, 13 May 2004 11:04:48 -0700 Received: from taniwha.stupidest.org (adsl-68-120-154-124.dsl.snfc21.pacbell.net [68.120.154.124]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i4DI4cTT277304; Thu, 13 May 2004 14:04:39 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 927CE14A75; Thu, 13 May 2004 11:04:38 -0700 (PDT) Date: Thu, 13 May 2004 11:04:38 -0700 From: Chris Wedgwood To: Feizhou Cc: "Jeffrey W. Baker" , stevew@catalyst.net.nz, linux-xfs@oss.sgi.com Subject: Re: XFS for postgres databases? Message-ID: <20040513180438.GD22785@taniwha.stupidest.org> References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> <40A22CA8.5090300@linuxmail.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40A22CA8.5090300@linuxmail.org> X-archive-position: 3127 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 216 Lines: 10 On Wed, May 12, 2004 at 09:54:48PM +0800, Feizhou wrote: > Why would you put a database on a meta data journaling only > filesystem? With a sane database journally the data isn't important or desirable. --cw From owner-linux-xfs@oss.sgi.com Thu May 13 14:24:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 14:24:28 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4DLOOKO014987 for ; Thu, 13 May 2004 14:24:25 -0700 Received: from [192.168.10.75] (c-24-98-62-33.atl.client2.attbi.com[24.98.62.33]) by comcast.net (rwcrmhc11) with SMTP id <2004051321080201300mvvcqe>; Thu, 13 May 2004 21:08:03 +0000 Subject: Re: XFS for postgres databases? From: Danny Cox To: Feizhou Cc: "Jeffrey W. Baker" , stevew@catalyst.net.nz, XFS Mailing List In-Reply-To: <40A22CA8.5090300@linuxmail.org> References: <200405121300.14866.stevew@catalyst.net.nz> <1084332608.11308.3.camel@noodles> <40A22CA8.5090300@linuxmail.org> Content-Type: text/plain Organization: No Organization at ALL Message-Id: <1084482475.17854.50.camel@pip> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 13 May 2004 17:07:56 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 3128 X-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: 376 Lines: 12 On Wed, 2004-05-12 at 09:54, Feizhou wrote: > Why would you put a database on a meta data journaling only filesystem? I think that they complement each other. The DB can't assure the filesystem's integrity, and XFS can't assure the file data integrity. -- 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 Thu May 13 18:07:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 18:07:21 -0700 (PDT) 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 i4E17EKO025222 for ; Thu, 13 May 2004 18:07:15 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i4E10oT9005029 for ; Thu, 13 May 2004 20:00:51 -0500 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i4E10nw03839 for linux-xfs@oss.sgi.com; Fri, 14 May 2004 11:00:49 +1000 Date: Fri, 14 May 2004 11:00:49 +1000 From: Nathan Scott Message-Id: <200405140100.i4E10nw03839@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - add laptop mode export X-archive-position: 3129 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 395 Lines: 15 Export laptop_mode for XFS syncd to use. Date: Thu May 13 18:00:13 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: akpm@osdl.org,bart@samwel.tk The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:171817a split-patches/laptop_mode-export - 1.1 mm/page-writeback.c - 1.4 split-patches/series - 1.3 From owner-linux-xfs@oss.sgi.com Thu May 13 18:07:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 18:07:26 -0700 (PDT) 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 i4E17KKO025230 for ; Thu, 13 May 2004 18:07:21 -0700 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 i4E15PT9006586 for ; Thu, 13 May 2004 20:05:26 -0500 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 LAA18236; Fri, 14 May 2004 11:05:22 +1000 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 i4E15Kln445170; Fri, 14 May 2004 11:05:20 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4E15FKN444751; Fri, 14 May 2004 11:05:15 +1000 (EST) Date: Fri, 14 May 2004 11:05:15 +1000 From: Nathan Scott To: Klaus Strebel , Bart Samwel Cc: akpm@osdl.org, XFS mailing list Subject: Re: Build XFS as module is broken Message-ID: <20040514110514.F419914@wobbly.melbourne.sgi.com> References: <40A38FB6.9030005@agile.com> <1084464214.31385.13.camel@samwel.tk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1084464214.31385.13.camel@samwel.tk>; from bart@samwel.tk on Thu, May 13, 2004 at 06:03:34PM +0200 X-archive-position: 3130 X-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: 1204 Lines: 39 On Thu, May 13, 2004 at 06:03:34PM +0200, Bart Samwel wrote: > On Thu, 2004-05-13 at 17:09, Klaus Strebel wrote: > > Hi all, > > > > tried to build from the current linux-2.6 cvs tree. Fails with > > unresolved symbol 'laptop_mode' :-(. Works with static nonmod build. > > > > EXPORT_SYMBOL(laptop_mode) in mm/page-writeback.c does the trick. > > Thanks for the report. Apparently a patch was forgotten, because I do > remember submitting one that did this. I submitted a patch to Andrew > Morton to add this export. > Ah, yes - this one has fallen through the cracks, sorry. I thought Andrew had applied this in 2.6.6 but didn't cross check that before merging Barts final laptop mode patch into our tree. Fixed in the XFS tree now, Andrew could you apply this patch to mainline? thanks. -- Nathan Index: 2.6.x-xfs/mm/page-writeback.c =================================================================== --- 2.6.x-xfs.orig/mm/page-writeback.c Tue May 11 14:54:17 2004 +++ 2.6.x-xfs/mm/page-writeback.c Fri May 14 10:52:56 2004 @@ -91,6 +91,7 @@ * Flag that puts the machine in "laptop mode". */ int laptop_mode; +EXPORT_SYMBOL(laptop_mode); /* End of sysctl-exported parameters */ From owner-linux-xfs@oss.sgi.com Thu May 13 18:37:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 18:37:23 -0700 (PDT) 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 i4E1bGKO026587 for ; Thu, 13 May 2004 18:37:16 -0700 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 i4E1a4T9016891 for ; Thu, 13 May 2004 20:36:06 -0500 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 LAA18908; Fri, 14 May 2004 11:35:49 +1000 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 i4E1Zkln446441; Fri, 14 May 2004 11:35:46 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4E1ZhUC445005; Fri, 14 May 2004 11:35:43 +1000 (EST) Date: Fri, 14 May 2004 11:35:43 +1000 From: Nathan Scott To: David Martinez Moreno - RedIRIS Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, clubinfo.servers@adi.uam.es Subject: Re: Crashes possibly related to XFS fs. Message-ID: <20040514113542.A445608@wobbly.melbourne.sgi.com> References: <200405131116.24487.david.martinez@rediris.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200405131116.24487.david.martinez@rediris.es>; from david.martinez@rediris.es on Thu, May 13, 2004 at 11:16:23AM +0200 X-archive-position: 3131 X-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: 2131 Lines: 53 Hi there, On Thu, May 13, 2004 at 11:16:23AM +0200, David Martinez Moreno - RedIRIS wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello. Since 2.6-preX series we are using XFS filesystem in the Spanish > Debian mirror. The machine is under load most of the time, and I think that > our periodic crashes (most of them occur only after some hours of operation, > some in a couple of days) could be related to the main data filesystem. > > For example, today I rebooted the server. All is working, well, with FTP and > HTTP concurrent access, and then I run the periodic script to sync up with > official Debian mirrors. It is a recursive rsync over the whole tree, over 96 > GB of size. Now it's running 2.6.6 vanilla. The crash is: > ... > May 12 15:21:17 ulises kernel: EIP is at xfs_count_page_state+0x31/0x8a > May 12 15:21:18 ulises kernel: [linvfs_release_page+52/156] linvfs_release_page+0x34/0x9c > May 12 15:21:18 ulises kernel: [try_to_release_page+81/107] try_to_release_page+0x51/0x6b > ... Hmm... that is an odd one. It looks like its crashing at the first point we peek into a buffer_head attached to the page given to xfs_count_page_state... the bh->state access within buffer_uptodate here: bh = head = page_buffers(page); do { if (buffer_uptodate(bh) The page passed to releasepage is guaranteed locked and with buffers attached, so there doesn't seem to me to be anything XFS could have done wrong here - I suspect you may have some memory problems (hardware) or else XFS is being called with a page in an invalid state. I can't see anywhere that that might be happening though - both of the try_to_release_page callers guarantee the page states I described above. Running memtest for awhile seems to be the done thing in this situation, see if that detects any problems. > > Oh, and Nathan (if you are in charge of it), in the MAINTAINERS file there is > an "owner-xfs@oss.sgi.com" address for XFS, that replies with an error, could > you please either fix the address of fix the file? :-) I'll look into that, thanks. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu May 13 20:02:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 20:02:34 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4E32RKO028275 for ; Thu, 13 May 2004 20:02:27 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i4E35gPo008014 for ; Thu, 13 May 2004 20:05:43 -0700 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 NAA20691; Fri, 14 May 2004 13:02:16 +1000 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 i4E32Cln448292; Fri, 14 May 2004 13:02:12 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4E328h1447775; Fri, 14 May 2004 13:02:08 +1000 (EST) Date: Fri, 14 May 2004 13:02:08 +1000 From: Nathan Scott To: Bart Samwel Cc: Andrew Morton , linux-xfs@oss.sgi.com Subject: Re: [patch 1/1] Update laptop mode control script with XFS_HZ=100 Message-ID: <20040514130207.E445608@wobbly.melbourne.sgi.com> References: <20040511154057.6d6c193b.akpm@osdl.org> <20040512090006.B362314@wobbly.melbourne.sgi.com> <40A1D7E3.8020700@samwel.tk> <20040512010453.196fc8c9.akpm@osdl.org> <40A1DB7B.2080600@samwel.tk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <40A1DB7B.2080600@samwel.tk>; from bart@samwel.tk on Wed, May 12, 2004 at 10:08:27AM +0200 X-archive-position: 3132 X-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: 754 Lines: 25 On Wed, May 12, 2004 at 10:08:27AM +0200, Bart Samwel wrote: > >> >>It would be much better to rework XFS so that these user-visible tunables > >> >>are in units of milliseconds, centiseconds or whatever. > >> > >> They're in USER_HZ since 2.6.6. Andrew, is that OK or should they really > >> be in some even more fixed unit? > > > > All architectures have USER_HZ=100. But it's a bit nicer and future-proof > > to relabel it as centiseconds. > > Agreed. Nathan, I'll make a patch for this. Just checking this in now. The updated interfaces will be: /proc/sys/fs/xfs/xfssyncd_centisecs /proc/sys/fs/xfs/xfsbufd_centisecs /proc/sys/fs/xfs/age_buffer_centisecs from sync_interval, flush_interval and age_buffer previously. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu May 13 20:22:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 20:22:19 -0700 (PDT) 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 i4E3MEKO031971 for ; Thu, 13 May 2004 20:22:14 -0700 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 i4E3EXT9017227 for ; Thu, 13 May 2004 22:14:34 -0500 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 i4E3EOAL67230155; Fri, 14 May 2004 13:14:24 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4E3ENTK64494114; Fri, 14 May 2004 13:14:23 +1000 (EST) Date: Fri, 14 May 2004 13:14:23 +1000 (EST) From: Nathan Scott Message-Id: <200405140314.i4E3ENTK64494114@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 914427 - jiffies to centisecs X-archive-position: 3133 X-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: 705 Lines: 25 Export/import tunable time intervals as centisecs not jiffies. Date: Thu May 13 20:13:52 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: sandeen@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:171825a xfsidbg.c - 1.260 linux-2.6/xfs_globals.c - 1.63 linux-2.6/xfs_linux.h - 1.123 linux-2.6/xfs_super.c - 1.306 linux-2.6/xfs_sysctl.c - 1.28 linux-2.6/xfs_sysctl.h - 1.22 linux-2.4/xfs_globals.c - 1.71 linux-2.4/xfs_linux.h - 1.133 linux-2.4/xfs_super.c - 1.289 linux-2.4/xfs_sysctl.c - 1.36 linux-2.4/xfs_sysctl.h - 1.27 linux-2.6/xfs_buf.c - 1.169 linux-2.4/xfs_buf.c - 1.187 From owner-linux-xfs@oss.sgi.com Thu May 13 20:26:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 20:26:26 -0700 (PDT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4E3QNKO032415 for ; Thu, 13 May 2004 20:26:23 -0700 Received: from taniwha.stupidest.org (adsl-68-120-154-124.dsl.snfc21.pacbell.net [68.120.154.124]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i4E3QHpJ263394; Thu, 13 May 2004 23:26:17 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id F0D7F14960; Thu, 13 May 2004 20:26:16 -0700 (PDT) Date: Thu, 13 May 2004 20:26:16 -0700 From: Chris Wedgwood To: Nathan Scott Cc: Bart Samwel , Andrew Morton , linux-xfs@oss.sgi.com Subject: Re: [patch 1/1] Update laptop mode control script with XFS_HZ=100 Message-ID: <20040514032616.GA2456@taniwha.stupidest.org> References: <20040511154057.6d6c193b.akpm@osdl.org> <20040512090006.B362314@wobbly.melbourne.sgi.com> <40A1D7E3.8020700@samwel.tk> <20040512010453.196fc8c9.akpm@osdl.org> <40A1DB7B.2080600@samwel.tk> <20040514130207.E445608@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040514130207.E445608@wobbly.melbourne.sgi.com> X-archive-position: 3134 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 474 Lines: 18 On Fri, May 14, 2004 at 01:02:08PM +1000, Nathan Scott wrote: > Just checking this in now. The updated interfaces will be: > > /proc/sys/fs/xfs/xfssyncd_centisecs > /proc/sys/fs/xfs/xfsbufd_centisecs > /proc/sys/fs/xfs/age_buffer_centisecs > > from sync_interval, flush_interval and age_buffer previously. s/centisecs// please. The time intervals are *defined* to be centiseconds already. Nobody else (other /proc users) has the need to state the obvious. --cw From owner-linux-xfs@oss.sgi.com Thu May 13 20:29:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 20:29:25 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4E3TLKO000347 for ; Thu, 13 May 2004 20:29:21 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i4E3WaUw015841 for ; Thu, 13 May 2004 20:32:37 -0700 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 NAA21267; Fri, 14 May 2004 13:29:13 +1000 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 i4E3TBln447703; Fri, 14 May 2004 13:29:11 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4E3T9HD448892; Fri, 14 May 2004 13:29:09 +1000 (EST) Date: Fri, 14 May 2004 13:29:09 +1000 From: Nathan Scott To: Chris Wedgwood Cc: Bart Samwel , Andrew Morton , linux-xfs@oss.sgi.com Subject: Re: [patch 1/1] Update laptop mode control script with XFS_HZ=100 Message-ID: <20040514132908.F445608@wobbly.melbourne.sgi.com> References: <20040511154057.6d6c193b.akpm@osdl.org> <20040512090006.B362314@wobbly.melbourne.sgi.com> <40A1D7E3.8020700@samwel.tk> <20040512010453.196fc8c9.akpm@osdl.org> <40A1DB7B.2080600@samwel.tk> <20040514130207.E445608@wobbly.melbourne.sgi.com> <20040514032616.GA2456@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040514032616.GA2456@taniwha.stupidest.org>; from cw@f00f.org on Thu, May 13, 2004 at 08:26:16PM -0700 X-archive-position: 3135 X-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: 664 Lines: 25 On Thu, May 13, 2004 at 08:26:16PM -0700, Chris Wedgwood wrote: > On Fri, May 14, 2004 at 01:02:08PM +1000, Nathan Scott wrote: > > > Just checking this in now. The updated interfaces will be: > > > > /proc/sys/fs/xfs/xfssyncd_centisecs > > /proc/sys/fs/xfs/xfsbufd_centisecs > > /proc/sys/fs/xfs/age_buffer_centisecs > > > > from sync_interval, flush_interval and age_buffer previously. > > s/centisecs// please. > > The time intervals are *defined* to be centiseconds already. Nobody > else (other /proc users) has the need to state the obvious. # ls /proc/sys/vm Andrew specifically asked for it to be this way. Seems OK to me. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu May 13 20:38:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 May 2004 20:38:18 -0700 (PDT) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4E3c9KO000898 for ; Thu, 13 May 2004 20:38:10 -0700 Received: from bsamwel by samwel.tk with local (Exim 4.33) id 1BOTWN-0000bD-NS; Fri, 14 May 2004 05:38:03 +0200 Subject: [PATCH] Laptop mode control script support for XFS *_centisecs sysctl values. From: Bart Samwel Reply-To: bart@samwel.tk To: Andrew Morton Cc: XFS mailing list , Nathan Scott In-Reply-To: <20040514130207.E445608@wobbly.melbourne.sgi.com> References: <20040511154057.6d6c193b.akpm@osdl.org> <20040512090006.B362314@wobbly.melbourne.sgi.com> <40A1D7E3.8020700@samwel.tk> <20040512010453.196fc8c9.akpm@osdl.org> <40A1DB7B.2080600@samwel.tk> <20040514130207.E445608@wobbly.melbourne.sgi.com> Content-Type: multipart/mixed; boundary="=-hfmhFf5dfsqAAvX1VvpK" Message-Id: <1084505883.31385.26.camel@samwel.tk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 14 May 2004 05:38:03 +0200 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: bsamwel@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 3136 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 4279 Lines: 85 --=-hfmhFf5dfsqAAvX1VvpK Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2004-05-14 at 05:02, Nathan Scott wrote: > Just checking this in now. The updated interfaces will be: > > /proc/sys/fs/xfs/xfssyncd_centisecs > /proc/sys/fs/xfs/xfsbufd_centisecs > /proc/sys/fs/xfs/age_buffer_centisecs > > from sync_interval, flush_interval and age_buffer previously. Andrew, here's a patch to support these values in the laptop mode control script. --Bart --=-hfmhFf5dfsqAAvX1VvpK Content-Disposition: attachment; filename=laptop-mode-script-xfs-centisecs.patch Content-Type: text/x-patch; name=laptop-mode-script-xfs-centisecs.patch; charset=ISO-8859-1 Content-Transfer-Encoding: base64 DQpGcm9tOiBCYXJ0IFNhbXdlbCA8YmFydEBzYW13ZWwudGs+DQoNCkxhcHRv cCBtb2RlIGNvbnRyb2wgc2NyaXB0IHN1cHBvcnQgZm9yIHhmc3N5bmNkX2Nl bnRpc2VjcyBhbmQgYWdlX2J1ZmZlcl9jZW50aXNlY3MNCmluIGFkZGl0aW9u IHRvIHRoZSBvbGQgc3luY19pbnRlcnZhbCBhbmQgYWdlX2J1ZmZlci4NCg0K DQotLS0NCg0KIGxpbnV4LTIuNi42LWJzYW13ZWwvRG9jdW1lbnRhdGlvbi9s YXB0b3AtbW9kZS50eHQgfCAgIDE1ICsrKysrKysrKysrKysrLQ0KIDEgZmls ZXMgY2hhbmdlZCwgMTQgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0K DQpkaWZmIC1wdU4gRG9jdW1lbnRhdGlvbi9sYXB0b3AtbW9kZS50eHR+bGFw dG9wLW1vZGUtc2NyaXB0LXhmcy1jZW50aXNlY3MgRG9jdW1lbnRhdGlvbi9s YXB0b3AtbW9kZS50eHQNCi0tLSBsaW51eC0yLjYuNi9Eb2N1bWVudGF0aW9u L2xhcHRvcC1tb2RlLnR4dH5sYXB0b3AtbW9kZS1zY3JpcHQteGZzLWNlbnRp c2VjcwkyMDA0LTA1LTE0IDA1OjIyOjM4LjAwMDAwMDAwMCArMDIwMA0KKysr IGxpbnV4LTIuNi42LWJzYW13ZWwvRG9jdW1lbnRhdGlvbi9sYXB0b3AtbW9k ZS50eHQJMjAwNC0wNS0xNCAwNTozMDowNC4wMDAwMDAwMDAgKzAyMDANCkBA IC0zNTQsMTkgKzM1NCwyOCBAQCBjYXNlICIkMSIgaW4NCiAJCWVjaG8gLW4g IlN0YXJ0aW5nIGxhcHRvcF9tb2RlIg0KIA0KIAkJaWYgWyAtZCAvcHJvYy9z eXMvdm0vcGFnZWJ1ZiBdIDsgdGhlbg0KKwkJCSMgKEZvciAyLjQgYW5kIGVh cmx5IDIuNi4pDQogCQkJIyBUaGlzIG9ubHkgbmVlZHMgdG8gYmUgc2V0LCBu b3QgcmVzZXQgLS0gaXQgaXMgb25seSB1c2VkIHdoZW4NCiAJCQkjIGxhcHRv cCBtb2RlIGlzIGVuYWJsZWQuDQogCQkJZWNobyAkWEZTX0FHRSA+IC9wcm9j L3N5cy92bS9wYWdlYnVmL2xtX2ZsdXNoX2FnZQ0KIAkJCWVjaG8gJFhGU19B R0UgPiAvcHJvYy9zeXMvZnMveGZzL2xtX3N5bmNfaW50ZXJ2YWwNCiAJCWVs aWYgWyAtZiAvcHJvYy9zeXMvZnMveGZzL2xtX2FnZV9idWZmZXIgXSA7IHRo ZW4NCisJCQkjIChBIGNvdXBsZSBvZiBlYXJseSAyLjYgbGFwdG9wIG1vZGUg cGF0Y2hlcyBoYWQgdGhlc2UuKQ0KIAkJCSMgVGhlIHNhbWUgZ29lcyBmb3Ig dGhlc2UuDQogCQkJZWNobyAkWEZTX0FHRSA+IC9wcm9jL3N5cy9mcy94ZnMv bG1fYWdlX2J1ZmZlcg0KIAkJCWVjaG8gJFhGU19BR0UgPiAvcHJvYy9zeXMv ZnMveGZzL2xtX3N5bmNfaW50ZXJ2YWwNCiAJCWVsaWYgWyAtZiAvcHJvYy9z eXMvZnMveGZzL2FnZV9idWZmZXIgXSA7IHRoZW4NCisJCQkjICgyLjYuNikN CiAJCQkjIEJ1dCBub3QgZm9yIHRoZXNlIC0tIHRoZXkgYXJlIGFsc28gdXNl ZCBpbiBub3JtYWwNCiAJCQkjIG9wZXJhdGlvbi4NCiAJCQllY2hvICRYRlNf QUdFID4gL3Byb2Mvc3lzL2ZzL3hmcy9hZ2VfYnVmZmVyDQogCQkJZWNobyAk WEZTX0FHRSA+IC9wcm9jL3N5cy9mcy94ZnMvc3luY19pbnRlcnZhbA0KKwkJ ZWxpZiBbIC1mIC9wcm9jL3N5cy9mcy94ZnMvYWdlX2J1ZmZlcl9jZW50aXNl Y3MgXSA7IHRoZW4NCisJCQkjICgyLjYuNyB1cHdhcmRzKQ0KKwkJCSMgQW5k IG5vdCBmb3IgdGhlc2UgZWl0aGVyLiBUaGVzZSBhcmUgaW4gY2VudGlzZWNz LA0KKwkJCSMgbm90IFVTRVJfSFosIHNvIHdlIGhhdmUgdG8gdXNlICRBR0Us IG5vdCAkWEZTX0FHRS4NCisJCQllY2hvICRBR0UgPiAvcHJvYy9zeXMvZnMv eGZzL2FnZV9idWZmZXJfY2VudGlzZWNzDQorCQkJZWNobyAkQUdFID4gL3By b2Mvc3lzL2ZzL3hmcy94ZnNzeW5jZF9jZW50aXNlY3MNCiAJCWZpDQogDQog CQljYXNlICIkS0xFVkVMIiBpbg0KQEAgLTQwNyw5ICs0MTYsMTMgQEAgY2Fz ZSAiJDEiIGluDQogCQllY2hvIC1uICJTdG9wcGluZyBsYXB0b3BfbW9kZSIN CiAJCWVjaG8gIjAiID4gL3Byb2Mvc3lzL3ZtL2xhcHRvcF9tb2RlDQogCQlp ZiBbIC1mIC9wcm9jL3N5cy9mcy94ZnMvYWdlX2J1ZmZlciBdICYmIFsgISAt ZiAvcHJvYy9zeXMvZnMveGZzL2xtX2FnZV9idWZmZXIgXSA7IHRoZW4NCi0J CQkjIFRoZXNlIG5lZWQgdG8gYmUgcmVzdG9yZWQgdGhvdWdoLCBpZiB0aGVy ZSBhcmUgbm8gbG1fKi4NCisJCQkjIFRoZXNlIG5lZWQgdG8gYmUgcmVzdG9y ZWQsIGlmIHRoZXJlIGFyZSBubyBsbV8qLg0KIAkJCWVjaG8gIiQoKCRYRlNf SFoqJERFRl9YRlNfQUdFX0JVRkZFUikpIiAJPiAvcHJvYy9zeXMvZnMveGZz L2FnZV9idWZmZXINCiAJCQllY2hvICIkKCgkWEZTX0haKiRERUZfWEZTX1NZ TkNfSU5URVJWQUwpKSIgCT4gL3Byb2Mvc3lzL2ZzL3hmcy9zeW5jX2ludGVy dmFsDQorCQllbGlmIFsgLWYgL3Byb2Mvc3lzL2ZzL3hmcy9hZ2VfYnVmZmVy X2NlbnRpc2VjcyBdIDsgdGhlbg0KKwkJCSMgVGhlc2UgbmVlZCB0byBiZSBy ZXN0b3JlZCBhcyB3ZWxsLg0KKwkJCWVjaG8gIiQoKDEwMCokREVGX1hGU19B R0VfQlVGRkVSKSkiID4gL3Byb2Mvc3lzL2ZzL3hmcy9hZ2VfYnVmZmVyX2Nl bnRpc2Vjcw0KKwkJCWVjaG8gIiQoKDEwMCokREVGX1hGU19TWU5DX0lOVEVS VkFMKSkiID4gL3Byb2Mvc3lzL2ZzL3hmcy94ZnNzeW5jZF9jZW50aXNlY3MN CiAJCWZpDQogCQljYXNlICIkS0xFVkVMIiBpbg0KIAkJCSIyLjQiKQ0KDQpf DQo= --=-hfmhFf5dfsqAAvX1VvpK-- From owner-linux-xfs@oss.sgi.com Fri May 14 11:05:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 14 May 2004 11:05:23 -0700 (PDT) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4EI5IKO004107 for ; Fri, 14 May 2004 11:05:18 -0700 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.10/8.12.2/SuSE Linux 0.6) with ESMTP id i4EI5CGn014848; Fri, 14 May 2004 11:05:13 -0700 Message-ID: <40A50A58.8030705@tlinx.org> Date: Fri, 14 May 2004 11:05:12 -0700 From: lawalsh User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Tim Shimmin , linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS References: <20040426165155.GA19148@em.ca> <200404261726.i3QHQ8Aj298772@zhadum.americas.sgi.com> <20040505151243.V3275@boing.melbourne.sgi.com> In-Reply-To: <20040505151243.V3275@boing.melbourne.sgi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3138 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 908 Lines: 28 Haven't tried 64 and 128 yet, but 256 made ugly ascii error messages on my screen (generic mount failed message). I'd increased the #buffs to 8 and the bufsize to 262144, and got failures on mounting. #buffs=8 worked though and that alone seemed to improve "rm" speed noticably. It's on my "todo"l list to try 128 and 64. My memory might be too fragmented, dunno -- computer's memory too...:-). This was under 2.6.5 kernel. I wouldn't put too much weight on the problem until I've done some more testing to narrow it down, but thought I'd mention it as a data point. System I tried it on had been up for 15 days... Total mem=1G with 128M in high mem. -l (musing: I wonder if we will need DOS-style disk defragmenters for memory for systems with long uptimes and large memory...) :-) Tim Shimmin wrote: >Up to 256Kb log buffers on Linux should work now. >(i.e. 32K, 64K, 128K, 256K). > > From owner-linux-xfs@oss.sgi.com Sat May 15 05:37:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 May 2004 05:37:48 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4FCbfKO010924 for ; Sat, 15 May 2004 05:37:41 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4FCbfs5010923 for linux-xfs@oss.sgi.com; Sat, 15 May 2004 05:37:41 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4FCbdKQ010909 for ; Sat, 15 May 2004 05:37:39 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4FCaRsN010880; Sat, 15 May 2004 05:36:27 -0700 Date: Sat, 15 May 2004 05:36:27 -0700 Message-Id: <200405151236.i4FCaRsN010880@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 328] freeze on XFS recovery on sparc64 with linux kernel 2.4.26 X-Bugzilla-Reason: AssignedTo X-archive-position: 3139 X-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: 2085 Lines: 53 http://oss.sgi.com/bugzilla/show_bug.cgi?id=328 ------- Additional Comments From nboullis@debian.org 2004-15-05 05:33 PDT ------- Created an attachment (id=120) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=120&action=view) A patch to fix XFS recovery on 64-bit little-endian architectures (like sparc64) As it is currently written, the xfs_contig_bits function in xfs_bit.c, when BITS_PER_LONG != 32, implicitely assumes that the arch is little-endian, as it considers that the LSB of *((uint *)map) is the same as the LSB of *((unsigned long int *)map). This patch implements a rewrite of xfs_contig_bits, that is supposed to work on all arches. Moreover, it adds two ASSERTs that would have been useful to track this bug. ------- Additional Comments From nboullis@debian.org 2004-15-05 05:35 PDT ------- Created an attachment (id=121) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=121&action=view) A patch to fix XFS recovery on 64-bit little-endian architectures (like sparc64) As it is currently written, the xfs_contig_bits function in xfs_bit.c, when BITS_PER_LONG != 32, implicitely assumes that the arch is little-endian, as it considers that the LSB of *((uint *)map) is the same as the LSB of *((unsigned long int *)map). This patch implements a rewrite of xfs_contig_bits, that is supposed to work on all arches. Moreover, it adds two ASSERTs that would have been useful to track this bug. ------- Additional Comments From nboullis@debian.org 2004-15-05 05:36 PDT ------- (From update of attachment 121) As it is currently written, the xfs_contig_bits function in xfs_bit.c, when BITS_PER_LONG != 32, implicitely assumes that the arch is little-endian, as it considers that the LSB of *((uint *)map) is the same as the LSB of *((unsigned long int *)map). This patch implements a rewrite of xfs_contig_bits, that is supposed to work on all arches. Moreover, it adds two ASSERTs that would have been useful to track this bug. ------- 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 May 15 06:37:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 May 2004 06:38:42 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4FDbrKO012851 for ; Sat, 15 May 2004 06:37:53 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4FDbr17012850 for linux-xfs@oss.sgi.com; Sat, 15 May 2004 06:37:53 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4FDbeKQ012828 for ; Sat, 15 May 2004 06:37:40 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4FCcPkf010975; Sat, 15 May 2004 05:38:25 -0700 Date: Sat, 15 May 2004 05:38:25 -0700 Message-Id: <200405151238.i4FCcPkf010975@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 328] freeze on XFS recovery on sparc64 with linux kernel 2.4.26 X-Bugzilla-Reason: AssignedTo X-archive-position: 3140 X-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: 396 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=328 ------- Additional Comments From nboullis@debian.org 2004-15-05 05:38 PDT ------- Sorry for the extra noise, that's roughly the first time I use bugzilla. I hope everything is now fine. If it is not, please ask. Nicolas ------- 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 May 16 05:12:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 May 2004 05:12:54 -0700 (PDT) Received: from smtp5.wanadoo.nl (smtp5.wanadoo.nl [194.134.35.176]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4GCCVKO027911 for ; Sun, 16 May 2004 05:12:32 -0700 Received: from [62.234.194.31] (p5143.vwr.wanadoo.nl [62.234.194.31]) by smtp5.wanadoo.nl (Postfix) with ESMTP id 0C0666BDD for ; Sun, 16 May 2004 13:32:46 +0200 (CEST) Message-ID: <40A750A7.5030507@wanadoo.nl> Date: Sun, 16 May 2004 13:29:43 +0200 From: jack renders User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: crashed partition-table Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3141 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: j-renders@wanadoo.nl Precedence: bulk X-list: linux-xfs Content-Length: 1143 Lines: 28 I just recently partualy crashed the partition table of my HD when running qtparted ( was resising hda1 but entrys of hda5 and hda6 were deleted) and I backed up data from hda1 to hda5 before running qtparted. As is was a lot of important data to me, I want to try to get it back. I read a thread on your mailing list, but I was wondering if you could explain this solution in a beginners way, as I 'm a newbie to repairing filesystems ( no newbie to linux ) Try to find the start and end of every partition, use dd to dump each of > them in separate files and mount them as loop device. I found XFS superblock, dd-ed whole partition and now my all important data is back :-) Thanks for help. If I find the superblocks which commands do I exactly use to " dd " the whole partition and get the data back? Do I need to run the xfsprogs commands from a floppy or can I use knoppix-liveCD? maybe there is a howto on partition recovery for XFS-filesystem for newbies you can point me to? Hope you can give some help as I don't know if this is the right way to go for help on this matter. best regards, jack renders netherlands. From owner-linux-xfs@oss.sgi.com Sun May 16 05:39:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 May 2004 05:39:13 -0700 (PDT) Received: from vanessa.wronline.net (vanessa.wronline.net [80.65.41.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4GCd5KO028569 for ; Sun, 16 May 2004 05:39:06 -0700 Received: (qmail 25817 invoked from network); 16 May 2004 12:38:59 -0000 Received: from delusion.wronline.net (80.65.32.178) by a.corp.mx.wronline.net with DES-CBC3-SHA encrypted SMTP (cert paletta@wronline.de); 16 May 2004 12:38:59 -0000 Received: (qmail 18594 invoked by uid 1000); 16 May 2004 12:39:02 -0000 Received: by delusion.wronline.net (tmda-sendmail, from uid 1000); Sun, 16 May 2004 14:39:02 +0200 (CEST) Date: Sun, 16 May 2004 14:39:00 +0200 To: jack renders Cc: linux-xfs@oss.sgi.com Subject: Re: crashed partition-table Message-ID: <20040516123900.GA3726@delusion.wronline.net> References: <40A750A7.5030507@wanadoo.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <40A750A7.5030507@wanadoo.nl> X-BND-Fodder: Heroin Bombe Echelon missile Plutonium iraq NSA Israel Chaos carnivore defense systems military attack elections policital embassy comint X-PGP-Id: 1024D/9F9F9022 2002-08-07 Stefan Paletta X-PGP-Fingerprint: DDDC B1DB 83BB F0D4 B2DB 8DAA 9404 2CCE 9F9F 9022 User-Agent: Mutt/1.5.6i X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Stefan Paletta Mail-Followup-To: j-renders@wanadoo.nl, linux-xfs@oss.sgi.com Reply-To: Stefan Paletta X-archive-position: 3142 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stefanp@cabal1.com Precedence: bulk X-list: linux-xfs Content-Length: 303 Lines: 10 jack renders wrote/schrieb/scripsit: > If I find the superblocks which commands do I exactly use to " dd " the > whole partition and get the data back? Try gpart: . -Stefan -- junior guru SP666-RIPE JID:stefanp@jabber.de.cw.net SMP@IRC From owner-linux-xfs@oss.sgi.com Sun May 16 11:33:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 May 2004 11:33:52 -0700 (PDT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4GIXoKO003803 for ; Sun, 16 May 2004 11:33:50 -0700 Received: from taniwha.stupidest.org (adsl-68-120-154-124.dsl.snfc21.pacbell.net [68.120.154.124]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i4GIXmN2091322; Sun, 16 May 2004 14:33:49 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id A0B7A14A00; Sun, 16 May 2004 11:33:48 -0700 (PDT) Date: Sun, 16 May 2004 11:33:48 -0700 From: Chris Wedgwood To: lawalsh Cc: Tim Shimmin , linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS Message-ID: <20040516183348.GA9622@taniwha.stupidest.org> References: <20040426165155.GA19148@em.ca> <200404261726.i3QHQ8Aj298772@zhadum.americas.sgi.com> <20040505151243.V3275@boing.melbourne.sgi.com> <40A50A58.8030705@tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40A50A58.8030705@tlinx.org> X-archive-position: 3143 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 256 Lines: 10 On Fri, May 14, 2004 at 11:05:12AM -0700, lawalsh wrote: > Haven't tried 64 and 128 yet, but 256 made ugly ascii error messages > on my screen (generic mount failed message). strace mount please and show the error code it gets from the kernel. --cw From owner-linux-xfs@oss.sgi.com Sun May 16 14:42:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 May 2004 14:42:36 -0700 (PDT) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4GLgOKO009655 for ; Sun, 16 May 2004 14:42:25 -0700 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.10/8.12.2/SuSE Linux 0.6) with ESMTP id i4GLgIGn030107; Sun, 16 May 2004 14:42:18 -0700 Message-ID: <40A7E03A.4020606@tlinx.org> Date: Sun, 16 May 2004 14:42:18 -0700 From: lawalsh User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Chris Wedgwood CC: Tim Shimmin , linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS References: <20040426165155.GA19148@em.ca> <200404261726.i3QHQ8Aj298772@zhadum.americas.sgi.com> <20040505151243.V3275@boing.melbourne.sgi.com> <40A50A58.8030705@tlinx.org> <20040516183348.GA9622@taniwha.stupidest.org> In-Reply-To: <20040516183348.GA9622@taniwha.stupidest.org> Content-Type: multipart/mixed; boundary="------------030700080706000706030403" X-archive-position: 3144 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 7862 Lines: 178 This is a multi-part message in MIME format. --------------030700080706000706030403 Content-Type: multipart/alternative; boundary="------------050500030207060908050507" --------------050500030207060908050507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Attaching traces for 64 (fail), 128(fail), 256(fail). 32 and 16 work as documented on the man page. Maybe it's a new security feature. xfs checks user's man page and enforces language in man page? :-) Also included are the 32 and 16 and no size specified (should be same as 32). tar'ed and feathered.... Chris Wedgwood wrote: >On Fri, May 14, 2004 at 11:05:12AM -0700, lawalsh wrote: > > > >>Haven't tried 64 and 128 yet, but 256 made ugly ascii error messages >>on my screen (generic mount failed message). >> >> > >strace mount please and show the error code it gets from the kernel. > > > --cw > > --------------050500030207060908050507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ishtar.tlinx.org id i4GLgIGn030107 Attaching traces for 64 (fail), 128(fail), 256(fail).=C2=A0 32 and 16 work as
documented on the man page.=C2=A0 Maybe it's a new security feature.=C2=A0 = xfs checks
user's man page and enforces language in man page?=C2=A0 :-)
Also included are the 32 and 16 and no size specified (should be same as
32).=C2=A0 tar'ed and feathered....


Chris Wedgwood wrote:
On Fri, May 14, 2004 at 11:05:12AM -0700, lawalsh wrote:

  
Haven't tried 64 and 128 yet, but 256 made ugly ascii er=
ror messages
on my screen (generic mount failed message).
    

strace mount please and show the error code it gets from the kernel.


  --cw
--------------050500030207060908050507-- --------------030700080706000706030403 Content-Type: application/octet-stream; name="results.tbz2" Content-Disposition: attachment; filename="results.tbz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWdvnGQMAaLF/hdzcSfV7d//y/////v////8AQIgABAhgGT75 KKkUkUlUBAoUSVAVQooSAVQFJJQKBVFEACVJIoAKFFIICUcADQNANDQAADTE NGmgAAADQyAADHAA0DQDQ0AAA0xDRpoAAAA0MgAAxwANA0A0NAAANMQ0aaAA AANDIAAMcADQNANDQAADTENGmgAAADQyAADCapQgmgAQaBJinommEyPTSGJ6 gDRoDRppoNommg0yBSkk0BJqemhT0NQj1HoMTUek0/VNGm0gGhoybQm1NNAM mg0H6vmOOHzjW0M1WSZsVVtMPi+L5+3z/n7t/PLlWM348tsfS22zkz1Sc1ZW JNLUJlWLWCnz/hX0L/R+HMbs+D6i6F3rLRVh0UOqazJ9CbJblazSh0zIasdt x0humQ2Qtpo2YNWVU5Xn0Q+FZIdFi5WrVtx8dkcFiMWFWWK2mStpgK1Yxklj GTFYyaOhoNXQ5kXQYpJ05llVK+YwJaZIi3RTxY1xULan+1Nw7S8UlaL7VX2y OC+tRbyfjX1e/0vR4/OOycSHg1azzOx4HSRK4FUxkxixUYFkpiwsFWWWFhYV YgxYWLBeUtINEmUplEwGKrJWTMMmTGJZZEvrTKeCI2ZCqyZVTJiFtNXApj+O dd09ede4pF4TfT7s1kL8dX+S1HskfkI4X5Fwt7cvZX+94luv8bjPPSvVNqh8 E5Urc3OTfNz35wfam99prJHvzop7vT8H/s+dNZzTbdr6/L1evNfCcZ3zH53N rWvOvsF8xbrquC5r75fzLdYvpL8S+8vkXFfzriXJdF5Fi/ZWl3LF5li86w9k 1mjfP9Z809HDd5PKfnmquE9c5U+o/3nonZPdEyazSHGZKyZMnvaT2tLmn8zJ hMYUxhTGUqsn05kSvMsRpYX96yPrf+YNF0LqXvXNZewl3zRoPiVlDJo0ZZlm WKHdT4Htp+ZuqYTJxIbSWlT1OJU3PiVxQcaI40RuvJVxXQLFkGLRHULdHJfA XdZVkYssv1b6C+iNGVK0na0Evnvem5WjqpunUx6KfA2uSreTFhGKjFi4W6ON 7q6ro+hNaayv0DWZRMKb2K/HNAnNci0VYuAjktrrauaxYIyqt7Yuy7tlytnt RzR8C9C2uxd6OqyMRpYSYsWLBaWFouVsvek6Wli6LqjS5rZfTWLa7lsuq6Lg uq/bjS5rYRiwsjvtI4yGlpfAF1XdHjb2lvGF90tLkVapHrWLFi5LRaQYjiqP kLdbFujBuMmKyms0tZrPFijaZNZk4TfKr50ycSZOTjMRYrkRN84zpnKaTrnZ O2dk7prMpvmDfNJyInKZNRLWVXNN05p/k9c9rg5piuM+jMqZMlV63B4PkeDZ 6WNWroau1+FwfZbNXSrxlV0TSaQ0d7pHXVO13yyX/K/MWqvs+6/VEfgXBaL3 1760vYWL3Ai0EWhDQh8VPrzqnGaT7E+OaTqn06bdvzvHPX9z3p1EOt9aazjM J8DJLancPzz9+aA1Yi7oVkl2Txn2ZijJpT5JtMhXZN43UrGSWLddlirksXJG qjkWgXZeK615jn+G79UtpkxpMmlMZMmSWTIY0iZNGQMpkyYSsmRTJgDJ+WB+ 40nkl9zst8K2mE4SrLkti6L6i/eWxcvUZqNNaLgt16VzqTlbRwI+GyOJfRxS MWFheM0JpMJ0znm09k4TsnNOM3TWcJwnXOqeid03OMycZynGmk1HPOU5T4Ce KOBJ1rAvJqu8u4uQsWFhkyfN9G/JpfNzzhM5Q0mVMoeLztKc8qOxYLS7X6Vw XshbcK79i0FizpldLklNmRq2Lm2La6XFHRHzOcHgULssI6rAW5YJMLBGLFC0 sEdlio2LFiMLCxGLCTFgq2IwCxYgxYVUbFgtLFssW5YqNli9ypOC0jlPQvQu hcF3C7liJkyZMSxX6KppDSYl5Np5XM+ELWlmR7KxdV2WrhkcUdi6Rte2uiWT 7DtuueY7jjIu6VWOExlOVtNhaLS4l9YuAq869Olvr4HvLT0Ny051bLiWxccL NluscC5Yti/o6V4rgvaLBdC+qWLyLddyxKYtL1rxXBcgvgLRci9Ni53PZ7K9 tcC4F8cFjRvm+9bqp5p6XDdvqHCdM6InfNp4rS2JN1yXFbFx4rivQ5LdcbgW RouGxBsue+kp9y4o5LitFwQel0Wi6rguLhpG2tFqXNBtiDgOE176azU/hZjM cJXCZMmU6pwnR5+CK78Xdea2Ys0vEVZYkxcCTSMXWNFssBc+ou9brSrwuGy2 FpiNLw85crXAvB1XtrYt47LSOawLou9i8S0ti8FhaXVdVz5brMTrt03TWpxm Q5pk36nXcN4M18MzSobU6AbNKaRK1mFKyazJrQaBbLYPbSpwuMGF2YtFzLqu NaZHNYlOK6LkWLFuuK0sXBYXkXYtLFwQcAuWY8Vhd5di4DSuZcFZa49hZsYu LvWLfhotYti8xi0uK6rkjsXVB3F1lrt23W63WVts9K8i8iNy4LlclyWyxGLe rFrfvW+i41cHVcS7ltszmcXbxD4rFF4LwXVfWuHIuSdyxKZjcuTlPCb97erS c86NWTWfL16TJ/1Mm04Twq5Fsu5Z043gvMtW0ty9+Uzc497mx3ct+sybU12N 1NtU0TabTam0rvnNMLdGi4oO5ata8GdLtZGPPpS2W6DisLLksWlsuSa99dF6 STmvMuK0vI6l0WYvALqu/FlusWLF33gvBblpGiw5wYdFhstLqsW5ewuCPOvc t71WFpYL5FkfdtLS+Sy+W+VatR8q1CakwsLFiyxJ+GxaX4loRstrS6r8UmKW KWFic9NhsylYwb2OMwJ+Gn4Jk0FG9kS5rFF8tvfXXxF5b7Noi2LKg/lL445r 21sX+d9tUfoWQfaF9uh9wbn983pfGl92aPu1SvyTnCfvTWdE5KT700V01T8d Ox+RXVOiYrZ13Eq/2X7RdFpd9+eTpHBYtiTRcyTdcF1XjEX31hcV3XKDzLyr ZZOSk/O71JunEJumK8ZlMp2Ql2hMS1incOiEvzU5p9KbpycSPMR2Xgu9briF wXO7hbLYWKnRCXXMVs7pvJxnel1hNqfab20U7aG+emnY+q3K6QnjU5mtNKGE 50slemaRTqnbOlxnnnWl2TIpvlVqE51b26Y4jScXfT87lSq405nGh+5T5R9a mz2MZTxdDHhOLqhLVW5XeNIS1pun3p3BOp/jVaWBeiJcVixdr5xbLxQmLVLn dzyCnPOef0qrpCcpzTjOmdE6JpD8CXtmk1mitmETKVqrclpJb2TxEuYGU3TY b0taV2pdVK2mK9+e6emidjJWMJWyXXQ1qlbJdklXQROpLrdU7J0O55N87p52 jgpOU5BMJ6aeE3VSvq8rmpe2vLJ1IT2471zXeovBdgeE4VTcE5T+snapMaPO 0mtUryt1zXZblyXesXahYWheYLyFMJL3MnaynUgvKVXc6ZynKHBwmlU2nrnM keeaK0mMmDykt0JeTsavB8lN05oVuJ1zoak4TWaV5bjGKXpX2kcrhbL0BHGP vXQSc09rlN6XobErkPVcB0qTtm1Nm6leqmnuodc4U0od87yZMVLkl6J1TUqb 3nEX88qsfDA+WZQX8C9xe+tLS2WiwqNlipNlgI9Swq0sR7ywt1i/GvuLRfQW LFguJYWLCxYLBYLFgsLEpzWKuJdxVpfxLBG6xYsQdVi6L8yxaEdyxV6kmLEY VfcWIrZYI6rBV/ksUWliD1rC/uXtLS7LuWirZaXvrZdFixYt1paWy5r1lsSf KWLmt15S7LqvWvFf7rmWiwuC7LRedbL7a2XsrYvyryrvLcvUXRaF0WF+FYX6 C860X9ZfXL2EbKjssL4y+Mv0L4V7l9ksv2wvvLyLwQdl2qTzLjaXrXOl9d9e YrWZPpTams+kkbBMmklorKaqTRJNgnx1T7cJfA4ziuRaXnpHKlvc11R91frr 5i0vWj5CS2m0+/DRI3TFaz8U0hL5DC+de6jlUfIF8oW5H5FoviC7R+Vdyhd1 LdRftL9irmvQjeA6x9ifrz8pT7I4zc3T/KcKm738zMzMzM3JHTOp0UwdXbTm kXfO9F6Fj45unPO6OS+pV767r/YvUL2lOiPSXtLyrzFixVi8F8K8Vi+mu9eZ bBeouVRdjnf+0rSnZNh1iLJXsdlPdN9U2emS8RjUaMQX4qaz9ud0ymk7Kb6b oeQr6VU96VvsFciHSrybJii8I1wq9RHfGlwj5yxdqjEuanvTSZPU6RFj3T3p kOEU307bpd88pqi/REcXS1SOanKemfHOeqHsmzfPdPNb1Zq7CS0dZJcZwdBE 8ztYSu91DfNzSbp1TlOEl6h785TpIbT8s9s658M3fJPRMeimK5p402p4OZzD mmD4R7BXomTJ3U3xT36e9VPbF3U2Gsr355D2Ur6or004KNafkZN9NptPUkex 002lV5p3Csh3TfK9lPlmk/T2t6HrKe2ead82nvTpiPhp3vRK3ytpk9RJaSvZ N43080rrnJ6Zjz08oaiuEU9T0LS3BZV4x7B5szM+auK7qSeC5qT0D80W07BF 2ElzTrnCfrTqnnpxn3VdrsnqpisKnZOmVxnfDKapb6cYdKpfrzRI75tNzonV OE0Y2d7rm6Gw/HTtm4iYUx0zGtMKOi5l+ctriXFG8nnRxWVbFwrgTcMV2OU3 U3U+Uadrrmz+WlaTvnsnrleieeV7JWkU8cGkrnbTgkYMm0XjDfO9vicJumh2 U9baOicaUuS6lhH6S/NciOtSngryEcpp5s/Ln6c/Vmmaeh5iYwqfRntnlPWr gRN7qe6bpX1JXqm+e2c5oDJ5PXVTmWy2Le0u6MovaUL1Lcj3lut6vfXui4Ea Xrr/yvYXGOqDuRpfPXsEeq+qXzV8KOK8V7i+wtLXJe2uJesvFe1Ud1SnuUk+ Yti9K0I9LCxiMYjGJMYXeL1I+aC9hf8SHgkamPMrnnXFOxtPGVgrlTjNHWfU MPCS5y3pGaTzPZPdO+dk1gbSqyiZTz0yZK0PdMqG0lunNOLZtOam0PO91Uxw mvKbOLqaUri5qmTxNp2NqVtP1T0U0nrn1JynpntHlOdrTwHmkuh66qfqNadk 1nKnTTKYE+nNBynjO+dM3zdwnhODqrF6S+IkPWWSc1wXxLS9FdboR4ltGR3q VykT5Vl7oL+KMXyL8B9+Ylo/Axq1mk1JuZQ/iVpNFbkPZpV5b+kLF+ojsg+g XwpP/xdyRThQkNvnGQM= --------------030700080706000706030403-- From owner-linux-xfs@oss.sgi.com Sun May 16 22:37:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 16 May 2004 22:37:54 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4H5bqKO023381 for ; Sun, 16 May 2004 22:37:52 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4H5bqUF023380 for linux-xfs@oss.sgi.com; Sun, 16 May 2004 22:37:52 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4H5bnKS023364 for ; Sun, 16 May 2004 22:37:49 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4H4xfuM022711; Sun, 16 May 2004 21:59:41 -0700 Date: Sun, 16 May 2004 21:59:41 -0700 Message-Id: <200405170459.i4H4xfuM022711@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 328] freeze on XFS recovery on sparc64 with linux kernel 2.4.26 X-Bugzilla-Reason: AssignedTo X-archive-position: 3145 X-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: 2111 Lines: 54 http://oss.sgi.com/bugzilla/show_bug.cgi?id=328 tes@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|xfs-master@oss.sgi.com |tes@sgi.com ------- Additional Comments From tes@sgi.com 2004-16-05 21:59 PDT ------- Hi Nicolas, Thanks very much for the patch. I see the problem that you point out. For xfs_buf_item's we store a blf_data_map which is an array of 32bit ints and we use xfs_buf_item_log() to add to the map. When we call xfs_contig_bits on a 64 bit word system we have to be careful. On little endian systems the LSB of a 32 bit word and a 64 bit word for the same data is the same but on a big endian system they differ. So one can't just call the linux find_next_zero_bit() function when we have 64 bit words on big endian boxes (as you mentioned). I noticed that for xfs_next_bit() we are doing the right thing and doing our own 32 bit int code. The xfs_contig_bits() is fairly similar to xfs_next_bit() and is largely just a xfs_next_zero_bit() except that we want a count of all the 1s so far even if we never find a zero (which would return -1 in the xfs_next* case). So I compared your xfs_contig_bits() code with our existing xfs_next_bit() code and I realised that we have a few simplifications to make which you've already done in your code. The thing is, unlike in the kernel functions, the size parameter in xfs code is in 32 bit ints and NOT in bits. We only do ops on size which keep it a multiple of 32 bits and therefore some size related tests in xfs_next_bit() can be simplified/removed. I'll make some changes for xfs_next_bit() in a separate incident :-) So the only thing I noticed in your code is that while (size >= NBWORD) { could probably be simplified to while (size) { and the assert removed, since size must be a multiple of NBWORD. Did you write this code based on xfs_next_bit() or from somewhere else? --Tim ------- 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 May 17 16:45:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 May 2004 16:45:06 -0700 (PDT) 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 i4HNj0KO000811 for ; Mon, 17 May 2004 16:45:02 -0700 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 i4HNirhv016598 for ; Mon, 17 May 2004 16:44:54 -0700 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 JAA26253 for ; Tue, 18 May 2004 09:44:52 +1000 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 i4HNipln567716 for ; Tue, 18 May 2004 09:44:51 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4HNio6p569175 for linux-xfs@oss.sgi.com; Tue, 18 May 2004 09:44:50 +1000 (EST) Date: Tue, 18 May 2004 09:44:49 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Bug#249429: xfslibs-dev: xfs/swab.h not ISO-C(++) compliant (fwd) Message-ID: <20040518094449.H543681@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 3147 X-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: 3370 Lines: 121 Could some compiler guru advise me here? (CW? you seem to know which is the pointy end of a compiler) Is this the right fix? swab.h isn't real pretty to start with, but this seems like a simple fixup... (hmm, is it going to work on all gcc versions I wonder?) thanks. ----- Forwarded message from Stephan A Suerken ----- Date: Mon, 17 May 2004 14:00:51 +0200 To: Debian Bug Tracking System Reply-To: Stephan A Suerken , 249429@bugs.debian.org From: Stephan A Suerken Subject: Bug#249429: xfslibs-dev: xfs/swab.h not ISO-C(++) compliant Package: xfslibs-dev Version: 2.6.11-1 Severity: normal Tags: patch, upstream Hi, when including XFS support from any C++ (maybe C as well) program and compiling it with "-pedantic" will lead to: --- In file included from /usr/include/xfs/platform_defs.h:60, from /usr/include/xfs/libxfs.h:38, from /usr/include/xfs/xqm.h:36, from QuotaInfo.cpp:17: /usr/include/xfs/swab.h: In function `const __u16 __fswab16(short unsigned int) ': /usr/include/xfs/swab.h:113: error: ISO C++ forbids braced-groups within expressions --- Afaik, includes intended for user space should have this fixed (for gcc, at least) via "__extension__", as in the patch. --- swab.h.orig 2004-05-17 13:54:00.000000000 +0200 +++ swab.h 2004-05-17 13:44:40.000000000 +0200 @@ -110,28 +110,28 @@ static __inline__ __const__ __u16 __fswab16(__u16 x) { - return __arch__swab16(x); + return (__extension__ __arch__swab16(x)); } static __inline__ __u16 __swab16p(__u16 *x) { - return __arch__swab16p(x); + return (__extension__ __arch__swab16p(x)); } static __inline__ void __swab16s(__u16 *addr) { - __arch__swab16s(addr); + (__extension__ ({__arch__swab16s(addr);})); } static __inline__ __const__ __u32 __fswab32(__u32 x) { - return __arch__swab32(x); + return (__extension__ __arch__swab32(x)); } static __inline__ __u32 __swab32p(__u32 *x) { - return __arch__swab32p(x); + return (__extension__ __arch__swab32p(x)); } static __inline__ void __swab32s(__u32 *addr) { - __arch__swab32s(addr); + (__extension__ ({__arch__swab32s(addr);})); } static __inline__ __const__ __u64 __fswab64(__u64 x) @@ -141,16 +141,16 @@ __u32 l = x & ((1ULL<<32)-1); return (((__u64)__swab32(l)) << 32) | ((__u64)(__swab32(h))); # else - return __arch__swab64(x); + return (__extension__ __arch__swab64(x)); # endif } static __inline__ __u64 __swab64p(__u64 *x) { - return __arch__swab64p(x); + return (__extension__ __arch__swab64p(x)); } static __inline__ void __swab64s(__u64 *addr) { - __arch__swab64s(addr); + (__extension__ ({__arch__swab64s(addr);})); } #endif /* SWAB_H */ ---UDIFFEND--- -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (1002, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.4.22-custom-adkm-manwe Locale: LANG=C, LC_CTYPE=de_DE@euro Versions of packages xfslibs-dev depends on: ii libc6-dev 2.3.2.ds1-12 GNU C Library: Development Librari ii uuid-dev 1.2-1.35-6 Universally unique id library - he ii xfsprogs 2.6.11-1 Utilities for managing the XFS fil -- no debconf information ----- End forwarded message ----- -- Nathan From owner-linux-xfs@oss.sgi.com Tue May 18 21:11:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 May 2004 21:11:27 -0700 (PDT) Received: from c000.snv.cp.net (h007.c000.snv.cp.net [209.228.32.71]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4J4BOKO031482 for ; Tue, 18 May 2004 21:11:25 -0700 Received: (cpmta 18424 invoked from network); 18 May 2004 21:11:24 -0700 Received: from 209.228.32.75 (HELO mail.mcadams.com.criticalpath.net) by smtp.mcadams.com (209.228.32.71) with SMTP; 18 May 2004 21:11:24 -0700 X-Sent: 19 May 2004 04:11:24 GMT Received: from [129.33.49.251] by mail.mcadams.com with HTTP; Tue, 18 May 2004 21:11:23 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 To: linux-xfs@oss.sgi.com From: tyler@mcadams.com Subject: Installation failure - incorrect disk X-Sent-From: tyler@mcadams.com Date: Tue, 18 May 2004 21:11:23 -0700 (PDT) X-Mailer: Web Mail 5.6.3-1 Message-Id: <20040518211124.9226.h011.c000.wm@mail.mcadams.com.criticalpath.net> X-archive-position: 3149 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tyler@mcadams.com Precedence: bulk X-list: linux-xfs Content-Length: 349 Lines: 14 I've tried every single release and I can not get *ome* of them to install... I use the SGI XFS disc one to start the process and then when the install asks for the regular disk it always returns with an error saying it's not the correct disk... What am I doing wrong here? Is there a place where I can actually buy the full sgi set? thx Tyler From owner-linux-xfs@oss.sgi.com Tue May 18 23:40:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 May 2004 23:40:35 -0700 (PDT) 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 i4J6eWKO002558 for ; Tue, 18 May 2004 23:40:32 -0700 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 i4J6eOhv013311 for ; Tue, 18 May 2004 23:40:25 -0700 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 i4J6eCAL70289078; Wed, 19 May 2004 16:40:12 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4J6eA1J69567925; Wed, 19 May 2004 16:40:10 +1000 (EST) Date: Wed, 19 May 2004 16:40:10 +1000 (EST) From: Nathan Scott Message-Id: <200405190640.i4J6eA1J69567925@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 914703 - forced shutdown fix X-archive-position: 3150 X-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: 398 Lines: 14 Fix a use-after-free during transaction commit when the log is in error state. Date: Tue May 18 23:38:41 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: sandeen@sgi.com,felixb@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:172041a xfs_log.c - 1.295 xfs_trans.c - 1.156 From owner-linux-xfs@oss.sgi.com Tue May 18 23:51:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 May 2004 23:51:33 -0700 (PDT) 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 i4J6pUKO003159 for ; Tue, 18 May 2004 23:51:30 -0700 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 i4J6ktiv026032 for ; Wed, 19 May 2004 01:46:56 -0500 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 i4J6kpAL68328980; Wed, 19 May 2004 16:46:51 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4J6koa768024557; Wed, 19 May 2004 16:46:50 +1000 (EST) Date: Wed, 19 May 2004 16:46:50 +1000 (EST) From: Nathan Scott Message-Id: <200405190646.i4J6koa768024557@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 914706 - use set_current_state X-archive-position: 3151 X-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: 483 Lines: 17 Use set_current_state instead of direct current->state assignment, it has added memory barrier goodness. Date: Tue May 18 23:45:45 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: hch@lst.de,kaos@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:172042a linux-2.6/xfs_buf.c - 1.170 linux-2.4/xfs_buf.c - 1.188 linux-2.6/time.h - 1.15 linux-2.4/time.h - 1.17 From owner-linux-xfs@oss.sgi.com Wed May 19 07:55:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 May 2004 07:55:24 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4JEtJKO004122 for ; Wed, 19 May 2004 07:55:20 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i4JExPqY016321 for ; Wed, 19 May 2004 07:59:25 -0700 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 i4JEtDKe38817027; Wed, 19 May 2004 09:55:13 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1BQSTR-0006Y6-00; Wed, 19 May 2004 09:55:13 -0500 Date: Wed, 19 May 2004 09:55:13 -0500 From: Nathan Straz To: tyler@mcadams.com Cc: linux-xfs@oss.sgi.com Subject: Re: Installation failure - incorrect disk Message-ID: <20040519145513.GD23231@sgi.com> Mail-Followup-To: tyler@mcadams.com, linux-xfs@oss.sgi.com References: <20040518211124.9226.h011.c000.wm@mail.mcadams.com.criticalpath.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040518211124.9226.h011.c000.wm@mail.mcadams.com.criticalpath.net> User-Agent: Mutt/1.5.3i X-archive-position: 3152 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1118 Lines: 24 On Tue, May 18, 2004 at 09:11:23PM -0700, tyler@mcadams.com wrote: > I've tried every single release and I can not get *ome* > of them to install... I use the SGI XFS disc one to > start the process and then when the install asks for > the regular disk it always returns with an error saying > it's not the correct disk... What am I doing wrong > here? I'll guess that you're trying to install an older version of Redhat with an SGI XFS installer. I remember at one point Redhat updated the CDs without changing the version and I think we respun the installer to accept the new discs. Regardless, you're probably trying to install an old version of XFS. I would recommend a more recent distro that supports XFS natively. I know the SuSE, Mandrake and Debian all support XFS. I have used the Debian sarge beta installers[1] with good success. [1] http://www.debian.org/devel/debian-installer/ -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Wed May 19 16:48:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 May 2004 16:48:52 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [207.218.156.196]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4JNmlKO013123 for ; Wed, 19 May 2004 16:48:48 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-3) with ESMTP id i4JNmTNT010232; Wed, 19 May 2004 18:48:29 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-3) with ESMTP id i4JNm9eA010229; Wed, 19 May 2004 18:48:09 -0500 Date: Wed, 19 May 2004 18:48:08 -0500 (EST) From: Net Llama! To: Nathan Straz cc: tyler@mcadams.com, linux-xfs@oss.sgi.com Subject: Re: Installation failure - incorrect disk In-Reply-To: <20040519145513.GD23231@sgi.com> Message-ID: References: <20040518211124.9226.h011.c000.wm@mail.mcadams.com.criticalpath.net> <20040519145513.GD23231@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3153 X-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@mail.linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1173 Lines: 26 On Wed, 19 May 2004, Nathan Straz wrote: > On Tue, May 18, 2004 at 09:11:23PM -0700, tyler@mcadams.com wrote: > > I've tried every single release and I can not get *ome* > > of them to install... I use the SGI XFS disc one to > > start the process and then when the install asks for > > the regular disk it always returns with an error saying > > it's not the correct disk... What am I doing wrong > > here? > > I'll guess that you're trying to install an older version of Redhat with > an SGI XFS installer. I remember at one point Redhat updated the CDs > without changing the version and I think we respun the installer to > accept the new discs. > > Regardless, you're probably trying to install an old version of XFS. I > would recommend a more recent distro that supports XFS natively. I know > the SuSE, Mandrake and Debian all support XFS. I have used the Debian > sarge beta installers[1] with good success. Fedora Core 2 also support XFS. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Wed May 19 17:43:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 May 2004 17:43:20 -0700 (PDT) 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 i4K0hGKO014388 for ; Wed, 19 May 2004 17:43:16 -0700 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 i4K0hAhv020201 for ; Wed, 19 May 2004 17:43:10 -0700 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 i4K0h6AL70451679; Thu, 20 May 2004 10:43:06 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4K0h5QG70315409; Thu, 20 May 2004 10:43:05 +1000 (EST) Date: Thu, 20 May 2004 10:43:05 +1000 (EST) From: Nathan Scott Message-Id: <200405200043.i4K0h5QG70315409@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 910888 - fix sendfile return code X-archive-position: 3154 X-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: 385 Lines: 13 Fix sendfile return code to be ssize_t in all places. Date: Wed May 19 17:42:35 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: hch@lst.de,jakub@redhat.com,kas@informatics.muni.cz The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:172110a linux-2.6/xfs_file.c - 1.102 From owner-linux-xfs@oss.sgi.com Wed May 19 17:59:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 May 2004 17:59:37 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.17.187.61]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4K0xWKO015119 for ; Wed, 19 May 2004 17:59:33 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <1.01C15C13@mailhub2.arup.com>; Wed, 19 May 2004 5:36:02 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Wed, 19 May 2004 05:36:01 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Wed, 19 May 2004 14:36:38 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Wed, 19 May 2004 14:25:25 +1000 From: "Scott Fagg" To: , Subject: Re: Installation failure - incorrect disk 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 i4K0xYKO015120 X-archive-position: 3155 X-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: 593 Lines: 26 Sounds like the standard discs you are trying to use ( e.g. the RH7.3 originals ) are not correctly written or formatted. Scott Fagg Arup Brisbane (07) 3023 6000 >>> 19/05/2004 2:11:23 PM >>> I've tried every single release and I can not get *ome* of them to install... I use the SGI XFS disc one to start the process and then when the install asks for the regular disk it always returns with an error saying it's not the correct disk... What am I doing wrong here? Is there a place where I can actually buy the full sgi set? thx Tyler From owner-linux-xfs@oss.sgi.com Wed May 19 18:51:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 May 2004 18:51:29 -0700 (PDT) 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 i4K1pOKO016272 for ; Wed, 19 May 2004 18:51:26 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i4K1fqiv018965 for ; Wed, 19 May 2004 20:41:54 -0500 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i4K1fhb05960; Thu, 20 May 2004 11:41:43 +1000 Date: Thu, 20 May 2004 11:41:43 +1000 From: Nathan Scott Message-Id: <200405200141.i4K1fhb05960@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: PARTIAL TAKE 914873 - lowmem handling in 2.4 X-archive-position: 3156 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 675 Lines: 22 Tweak and export free_more_memory routine so XFS can use it. Allows us to interact much better with the VM in low memory situations, especially in combination with the cache_defs patch. We'll attempt to get these accepted after a bit more testing, and some similar 2.6 work. Date: Wed May 19 18:38:55 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:172113a split-patches/free_more_memory - 1.1 fs/buffer.c - 1.3 include/linux/fs.h - 1.4 mm/vmscan.c - 1.4 split-patches/series - 1.5 split-patches/cache_defs - 1.3 From owner-linux-xfs@oss.sgi.com Wed May 19 18:56:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 May 2004 18:56:18 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4K1uFKO016677 for ; Wed, 19 May 2004 18:56:15 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i4K20ONh006099 for ; Wed, 19 May 2004 19:00:24 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i4K1u0527357; Thu, 20 May 2004 11:56:00 +1000 Date: Thu, 20 May 2004 11:56:00 +1000 From: Nathan Scott Message-Id: <200405200156.i4K1u0527357@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: PARTIAL TAKE 914873 - lowmem handling in 2.6 X-archive-position: 3157 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 493 Lines: 18 Tweak and export free_more_memory routine so XFS can use it. Allows us to interact much better with the VM in low memory situations. Date: Wed May 19 18:54:30 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:172114a split-patches/free_more_memory - 1.1 fs/buffer.c - 1.7 include/linux/buffer_head.h - 1.4 split-patches/series - 1.5 From owner-linux-xfs@oss.sgi.com Wed May 19 20:36:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 May 2004 20:36:29 -0700 (PDT) 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 i4K3aOKO021596 for ; Wed, 19 May 2004 20:36:25 -0700 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 i4K3XQiv004846 for ; Wed, 19 May 2004 22:33:28 -0500 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 i4K3XBAL70288074; Thu, 20 May 2004 13:33:11 +1000 (EST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4K3X9tI70671879; Thu, 20 May 2004 13:33:09 +1000 (EST) Date: Thu, 20 May 2004 13:33:09 +1000 (EST) From: Timothy Shimmin Message-Id: <200405200333.i4K3X9tI70671879@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 914643 - freeze on XFS recovery on sparc64 X-archive-position: 3158 X-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@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 932 Lines: 28 This change should get log recovery working on 64 bit big endian arches such as sparc64 for which Nicolas Boullis created his patch (bugzilla#328). Change xfs_contig_bits to work on 32/64 and both endian styles. This change was contributed by nboullis@debian.org based on xfs_next_bit which exists in the xfs code. Date: Wed May 19 20:27:56 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/tes/isms/xfs-linux Inspected by: nboullis@debian.org,nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:172115a xfs_bit.c - 1.26 - Change xfs_contig_bits to work on 32/64 and both endian styles. This change was contributed by nboullis@debian.org based on xfs_next_bit which exists in the xfs code. I've also simplified xfs_next_bit after looking at this code. xfs_log_recover.c - 1.287 - Add asserts to ensure that the bit routine worked. From owner-linux-xfs@oss.sgi.com Thu May 20 01:14:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 01:15:00 -0700 (PDT) Received: from localhost.localdomain (CPE-144-136-105-90.nsw.bigpond.net.au [144.136.105.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4K8E3KO005295 for ; Thu, 20 May 2004 01:14:04 -0700 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id i4K8DnUM001533 for ; Thu, 20 May 2004 18:13:54 +1000 Message-ID: <40AC68BD.2080704@netscape.net> Date: Thu, 20 May 2004 18:13:49 +1000 From: How Wong User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: FC2 XFS install from harddisk Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3159 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: grandsonata@netscape.net Precedence: bulk X-list: linux-xfs Content-Length: 356 Lines: 9 HI I have been trying to upgrade FC1 to FC2 for a whole day. Disappointing to see that the installer doesn't support XFS. I browsed around and found that you can boot with "linux xfs". that does not work with expert mode! which I need to select hard drive install. Is there a way around at all? what a load of rubbish! XFS heaps better that ext3. From owner-linux-xfs@oss.sgi.com Thu May 20 02:26:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 02:26:44 -0700 (PDT) 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 i4K9QVKO006875 for ; Thu, 20 May 2004 02:26:32 -0700 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 i4K9PFhv000429 for ; Thu, 20 May 2004 02:25:15 -0700 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 i4K9PDKe38813916; Thu, 20 May 2004 04:25:13 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1BQjnc-0005eq-00; Thu, 20 May 2004 04:25:12 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 914880 - Use macros instead of inlines for spinlock wrappers to aid debugging Message-Id: From: Christoph Hellwig Date: Thu, 20 May 2004 04:25:12 -0500 X-archive-position: 3160 X-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: 398 Lines: 16 Date: Thu May 20 02:24:59 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: roehrich,felixb,nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:172120a fs/xfs/linux-2.6/spin.h - 1.17 - use macros instead of inlines fs/xfs/linux-2.4/spin.h - 1.19 - use macros instead of inlines From owner-linux-xfs@oss.sgi.com Thu May 20 02:38:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 02:38:17 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4K9cEKO007563 for ; Thu, 20 May 2004 02:38:14 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4K9cDWb007562 for linux-xfs@oss.sgi.com; Thu, 20 May 2004 02:38:13 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4K9cBKU007529 for ; Thu, 20 May 2004 02:38:12 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4K9Yoaf007428; Thu, 20 May 2004 02:34:50 -0700 Date: Thu, 20 May 2004 02:34:50 -0700 Message-Id: <200405200934.i4K9Yoaf007428@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 324] oops with xfs_fsr on 2.6.5-1.326 X-Bugzilla-Reason: AssignedTo X-archive-position: 3161 X-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: 673 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=324 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From hch@xfs.org 2004-20-05 02:34 PDT ------- This should be fixed in CVS (and the final FC2 kernel) XFS had been directly referencing userspace pointers which doesn't fly with the 4g/4g patch in FC2. ------- 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 May 20 02:38:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 02:38:25 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4K9cEKO007564 for ; Thu, 20 May 2004 02:38:14 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4K9cD6U007561 for linux-xfs@oss.sgi.com; Thu, 20 May 2004 02:38:13 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4K9cBKQ007529 for ; Thu, 20 May 2004 02:38:12 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4K9a8Is007480; Thu, 20 May 2004 02:36:08 -0700 Date: Thu, 20 May 2004 02:36:08 -0700 Message-Id: <200405200936.i4K9a8Is007480@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 320] xfsinvutil -i crash with segfault X-Bugzilla-Reason: AssignedTo X-archive-position: 3162 X-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: 575 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=320 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From hch@xfs.org 2004-20-05 02:36 PDT ------- The patch that fixed the bug has been in CVS for a while. ------- 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 May 20 03:38:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 03:39:10 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4KAcJKO011530 for ; Thu, 20 May 2004 03:38:19 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4KAcJJ1011528 for linux-xfs@oss.sgi.com; Thu, 20 May 2004 03:38:19 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4KAcDKQ011500 for ; Thu, 20 May 2004 03:38:13 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4K9cdtK007733; Thu, 20 May 2004 02:38:39 -0700 Date: Thu, 20 May 2004 02:38:39 -0700 Message-Id: <200405200938.i4K9cdtK007733@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 201] The procedure described in the document "Making a Linux XFS Root filesystem" yield an unbootable system. X-Bugzilla-Reason: AssignedTo X-archive-position: 3164 X-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: 367 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=201 ------- Additional Comments From hch@xfs.org 2004-20-05 02:38 PDT ------- I can't find such documentation on oss.sgi.com anymore. If you can still find it and it's still bogus please reopen. ------- 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 May 20 03:38:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 03:39:07 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4KAcJKO011529 for ; Thu, 20 May 2004 03:38:19 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4KAcJhF011527 for linux-xfs@oss.sgi.com; Thu, 20 May 2004 03:38:19 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4KAcDKU011500 for ; Thu, 20 May 2004 03:38:14 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4K9csJ7007819; Thu, 20 May 2004 02:38:54 -0700 Date: Thu, 20 May 2004 02:38:54 -0700 Message-Id: <200405200938.i4K9csJ7007819@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 201] The procedure described in the document "Making a Linux XFS Root filesystem" yield an unbootable system. X-Bugzilla-Reason: AssignedTo X-archive-position: 3163 X-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: 635 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=201 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From hch@xfs.org 2004-20-05 02:38 PDT ------- I can't find such documentation on oss.sgi.com anymore. If you can still find it and it's still bogus please reopen. ------- 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 May 20 08:42:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 08:42:35 -0700 (PDT) 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 i4KFgRKO027473 for ; Thu, 20 May 2004 08:42:27 -0700 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 i4KFcQhv011018 for ; Thu, 20 May 2004 08:38:26 -0700 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 i4KFcQKe38850330; Thu, 20 May 2004 10:38:26 -0500 (CDT) 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 i4KFcP3a391607; Thu, 20 May 2004 10:38:26 -0500 (CDT) Subject: Re: FC2 XFS install from harddisk From: Eric Sandeen To: How Wong Cc: linux-xfs@oss.sgi.com In-Reply-To: <40AC68BD.2080704@netscape.net> References: <40AC68BD.2080704@netscape.net> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1085067505.4181.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 20 May 2004 10:38:25 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 3165 X-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: 834 Lines: 23 Not certain, have not tried it yet. However.... If xfs users want things like FC to work with XFS, then TEST THE BETAS. It's a little late to complain now... the things we found, the Fedora^wRedHat guys were very willing to fix. But if they don't know what's wrong, they can't fix it. -Eric On Thu, 2004-05-20 at 03:13, How Wong wrote: > HI > > I have been trying to upgrade FC1 to FC2 for a whole day. Disappointing > to see that the installer doesn't support XFS. I browsed around and > found that you can boot with "linux xfs". that does not work with expert > mode! which I need to select hard drive install. Is there a way around > at all? what a load of rubbish! XFS heaps better that ext3. -- 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 May 20 08:48:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 08:48:25 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [207.218.156.196]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4KFmDKO027930 for ; Thu, 20 May 2004 08:48:13 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-3) with ESMTP id i4KFm018005360; Thu, 20 May 2004 10:48:00 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-3) with ESMTP id i4KFm0tf005357; Thu, 20 May 2004 10:48:00 -0500 Date: Thu, 20 May 2004 10:48:00 -0500 (EST) From: Net Llama! To: Eric Sandeen cc: How Wong , linux-xfs@oss.sgi.com Subject: Re: FC2 XFS install from harddisk In-Reply-To: <1085067505.4181.1.camel@stout.americas.sgi.com> Message-ID: References: <40AC68BD.2080704@netscape.net> <1085067505.4181.1.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3166 X-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@mail.linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1193 Lines: 32 What is it in the 'expert' install that you needed? Admittedly, my testing was the basic 'linux xfs' install of FC2-test1. I submitted a bug that i found related to XFS, and they fixed it. On Thu, 20 May 2004, Eric Sandeen wrote: > Not certain, have not tried it yet. > > However.... > > If xfs users want things like FC to work with XFS, then TEST THE BETAS. > It's a little late to complain now... the things we found, the > Fedora^wRedHat guys were very willing to fix. But if they don't know > what's wrong, they can't fix it. > > -Eric > > On Thu, 2004-05-20 at 03:13, How Wong wrote: > > HI > > > > I have been trying to upgrade FC1 to FC2 for a whole day. Disappointing > > to see that the installer doesn't support XFS. I browsed around and > > found that you can boot with "linux xfs". that does not work with expert > > mode! which I need to select hard drive install. Is there a way around > > at all? what a load of rubbish! XFS heaps better that ext3. > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Thu May 20 08:59:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 08:59:43 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4KFxdKO028881 for ; Thu, 20 May 2004 08:59:40 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i4KFxIId005306; Thu, 20 May 2004 17:59:18 +0200 Message-ID: <40ACD5AB.2070405@stesmi.com> Date: Thu, 20 May 2004 17:58:35 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Net Llama!" CC: Eric Sandeen , How Wong , linux-xfs@oss.sgi.com Subject: Re: FC2 XFS install from harddisk References: <40AC68BD.2080704@netscape.net> <1085067505.4181.1.camel@stout.americas.sgi.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3167 X-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: 250 Lines: 10 Net Llama! wrote: > What is it in the 'expert' install that you needed? Admittedly, my > testing was the basic 'linux xfs' install of FC2-test1. I submitted a bug > that i found related to XFS, and they fixed it. Which bug was that ? // Stefan From owner-linux-xfs@oss.sgi.com Thu May 20 09:02:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 09:02:20 -0700 (PDT) Received: from mail.linux-sxs.org (mail.linux-sxs.org [207.218.156.196]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4KG2FKO029315 for ; Thu, 20 May 2004 09:02:16 -0700 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-3) with ESMTP id i4KG29bG005469; Thu, 20 May 2004 11:02:09 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.12.11/8.12.11/Debian-3) with ESMTP id i4KG29ID005466; Thu, 20 May 2004 11:02:09 -0500 Date: Thu, 20 May 2004 11:02:09 -0500 (EST) From: Net Llama! To: Stefan Smietanowski cc: Eric Sandeen , How Wong , linux-xfs@oss.sgi.com Subject: Re: FC2 XFS install from harddisk In-Reply-To: <40ACD5AB.2070405@stesmi.com> Message-ID: References: <40AC68BD.2080704@netscape.net> <1085067505.4181.1.camel@stout.americas.sgi.com> <40ACD5AB.2070405@stesmi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3168 X-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@mail.linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 662 Lines: 17 On Thu, 20 May 2004, Stefan Smietanowski wrote: > Net Llama! wrote: > > > What is it in the 'expert' install that you needed? Admittedly, my > > testing was the basic 'linux xfs' install of FC2-test1. I submitted a bug > > that i found related to XFS, and they fixed it. > > Which bug was that ? I don't remember, but it was marked fixed prior to the release of FC2. I think it was the same bug that you were referencing a few weeks back. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Thu May 20 09:04:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 09:04:23 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4KG4JKO029682 for ; Thu, 20 May 2004 09:04:20 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i4KG4EId005515; Thu, 20 May 2004 18:04:14 +0200 Message-ID: <40ACD6D3.4060906@stesmi.com> Date: Thu, 20 May 2004 18:03:31 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Net Llama!" CC: Eric Sandeen , How Wong , linux-xfs@oss.sgi.com Subject: Re: FC2 XFS install from harddisk References: <40AC68BD.2080704@netscape.net> <1085067505.4181.1.camel@stout.americas.sgi.com> <40ACD5AB.2070405@stesmi.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3169 X-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: 593 Lines: 23 Net Llama! wrote: > On Thu, 20 May 2004, Stefan Smietanowski wrote: > >>Net Llama! wrote: >> >> >>>What is it in the 'expert' install that you needed? Admittedly, my >>>testing was the basic 'linux xfs' install of FC2-test1. I submitted a bug >>>that i found related to XFS, and they fixed it. >> >>Which bug was that ? > > > I don't remember, but it was marked fixed prior to the release of FC2. I > think it was the same bug that you were referencing a few weeks back. > Ok, good, just checking because I couldn't remember any other bugs posted for FC2t1 regarding XFS. // Stefan From owner-linux-xfs@oss.sgi.com Thu May 20 10:05:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 10:05:32 -0700 (PDT) Received: from zen.timetraveller.org (rbrockway.tor.istop.com [66.11.182.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4KH5AKO032079 for ; Thu, 20 May 2004 10:05:11 -0700 Received: by zen.timetraveller.org (Postfix, from userid 1000) id 59D9410001EF; Thu, 20 May 2004 13:06:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zen.timetraveller.org (Postfix) with ESMTP id 593D91C0F542 for ; Thu, 20 May 2004 13:06:28 -0400 (EDT) Date: Thu, 20 May 2004 13:06:28 -0400 (EDT) From: Robert Brockway To: linux-xfs@oss.sgi.com Subject: Re: Installation failure - incorrect disk In-Reply-To: <20040519145513.GD23231@sgi.com> Message-ID: References: <20040518211124.9226.h011.c000.wm@mail.mcadams.com.criticalpath.net> <20040519145513.GD23231@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3170 X-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: 991 Lines: 24 On Wed, 19 May 2004, Nathan Straz wrote: > Regardless, you're probably trying to install an old version of XFS. I > would recommend a more recent distro that supports XFS natively. I know > the SuSE, Mandrake and Debian all support XFS. I have used the Debian > sarge beta installers[1] with good success. I've built at least a couple of dozen Debian boxes with xfs using this net install image. This is a nice and up to date boot CD. http://people.debian.org/~blade/XFS-Install/download/ Don't use this unless you have decent bandwidth at the site as it is designed to pickup almost all packages off the web. If you need to build lots of boxes using this then make sure you have some sort of caching that will hold .debs (apt-proxy, squid configured properly, etc). Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, rbrockway@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 Thu May 20 13:15:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 13:16:01 -0700 (PDT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4KKFkKO023356 for ; Thu, 20 May 2004 13:15:47 -0700 Received: from taniwha.stupidest.org (adsl-68-120-154-124.dsl.snfc21.pacbell.net [68.120.154.124]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i4KKFjWB222534; Thu, 20 May 2004 16:15:45 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 285E414A84; Thu, 20 May 2004 13:15:45 -0700 (PDT) Date: Thu, 20 May 2004 13:15:45 -0700 From: Chris Wedgwood To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: Bug#249429: xfslibs-dev: xfs/swab.h not ISO-C(++) compliant (fwd) Message-ID: <20040520201545.GA8472@taniwha.stupidest.org> References: <20040518094449.H543681@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040518094449.H543681@wobbly.melbourne.sgi.com> X-archive-position: 3171 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 504 Lines: 18 On Tue, May 18, 2004 at 09:44:49AM +1000, Nathan Scott wrote: > /usr/include/xfs/swab.h: In function `const __u16 __fswab16(short unsigned int)': > /usr/include/xfs/swab.h:113: error: ISO C++ forbids braced-groups within expressions ick > Afaik, includes intended for user space should have this fixed (for > gcc, at least) via "__extension__", as in the patch. that sounds horrible and i very much doubt it will work with icc (did any check?) are inlines really out of the question here? --cw From owner-linux-xfs@oss.sgi.com Thu May 20 17:11:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 17:11:16 -0700 (PDT) Received: from office.labsysgrp.com (wsip-68-14-253-125.ph.ph.cox.net [68.14.253.125]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4L0BDKO030829 for ; Thu, 20 May 2004 17:11:14 -0700 Received: from [127.0.0.1] (helo=localhost) by office.labsysgrp.com with esmtp (Exim 4.34) id 1BQxcy-0008G2-Dx for linux-xfs@oss.sgi.com; Thu, 20 May 2004 17:11:08 -0700 Received: from office.labsysgrp.com ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31520-05 for ; Thu, 20 May 2004 17:11:07 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.labsysgrp.com with esmtp (Exim 4.34) id 1BQxcx-0008Fw-Kw for linux-xfs@oss.sgi.com; Thu, 20 May 2004 17:11:07 -0700 Received: from [192.168.172.107] (helo=[192.168.172.107]) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1BQxcw-0004TD-00 for linux-xfs@oss.sgi.com; Thu, 20 May 2004 17:11:06 -0700 Message-ID: <40AD491A.7020805@backtobasicsmgmt.com> Date: Thu, 20 May 2004 17:11:06 -0700 From: "Kevin P. Fleming" Organization: Back To Basics Network Management User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS backtrace with kernel 2.6.6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 3172 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 1067 Lines: 26 I've got a server that generated about a dozen of these today: 0x0: 00 00 01 7a 03 38 0b f0 02 10 00 b8 01 08 00 18 Filesystem "dm-0": XFS internal error xfs_da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xc01d0347 Call Trace: [] xfs_da_do_buf+0x47f/0xa70 [] xfs_da_read_buf+0x57/0x60 [] xfs_da_read_buf+0x57/0x60 [] xfs_da_read_buf+0x57/0x60 [] xfs_dir2_block_getdents+0xad/0x360 [] xfs_dir2_block_getdents+0xad/0x360 [] xfs_bmap_last_offset+0xc5/0x130 [] xfs_dir2_put_dirent64_direct+0x0/0xa0 [] xfs_dir2_isblock+0x32/0x80 [] xfs_dir2_put_dirent64_direct+0x0/0xa0 [] xfs_dir2_getdents+0xc9/0x190 [] xfs_dir2_put_dirent64_direct+0x0/0xa0 [] xfs_readdir+0x60/0xc0 [] linvfs_readdir+0x115/0x260 [] vfs_readdir+0x89/0xa0 [] filldir64+0x0/0x100 [] sys_getdents64+0x6f/0xab [] filldir64+0x0/0x100 [] syscall_call+0x7/0xb From owner-linux-xfs@oss.sgi.com Thu May 20 17:55:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 17:55:32 -0700 (PDT) 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 i4L0tTKO031936 for ; Thu, 20 May 2004 17:55:29 -0700 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 i4L0pchv028395 for ; Thu, 20 May 2004 17:51:39 -0700 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 KAA20138; Fri, 21 May 2004 10:51:29 +1000 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 i4L0pQln653890; Fri, 21 May 2004 10:51:27 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4L0pOVP655189; Fri, 21 May 2004 10:51:24 +1000 (EST) Date: Fri, 21 May 2004 10:51:24 +1000 From: Nathan Scott To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com Subject: Re: XFS backtrace with kernel 2.6.6 Message-ID: <20040521105124.B653735@wobbly.melbourne.sgi.com> References: <40AD491A.7020805@backtobasicsmgmt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <40AD491A.7020805@backtobasicsmgmt.com>; from kpfleming@backtobasicsmgmt.com on Thu, May 20, 2004 at 05:11:06PM -0700 X-archive-position: 3173 X-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: 467 Lines: 16 On Thu, May 20, 2004 at 05:11:06PM -0700, Kevin P. Fleming wrote: > I've got a server that generated about a dozen of these today: > > 0x0: 00 00 01 7a 03 38 0b f0 02 10 00 b8 01 08 00 18 > Filesystem "dm-0": XFS internal error xfs_da_do_buf(2) at line 2273 of > file fs/xfs/xfs_da_btree.c. Caller 0xc01d0347 A corrupt directory block from the look of it - did xfs_repair find anything? Any kind of disk or block layer errors in your logs? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu May 20 18:17:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 18:17:33 -0700 (PDT) Received: from office.labsysgrp.com (wsip-68-14-253-125.ph.ph.cox.net [68.14.253.125]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4L1HRKO032605 for ; Thu, 20 May 2004 18:17:27 -0700 Received: from [127.0.0.1] (helo=localhost) by office.labsysgrp.com with esmtp (Exim 4.34) id 1BQyf4-0008JC-7c; Thu, 20 May 2004 18:17:22 -0700 Received: from office.labsysgrp.com ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31891-02; Thu, 20 May 2004 18:17:21 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.labsysgrp.com with esmtp (Exim 4.34) id 1BQyf3-0008J6-FJ; Thu, 20 May 2004 18:17:21 -0700 Received: from [192.168.172.107] (helo=[192.168.172.107]) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1BQyf2-0004dW-00; Thu, 20 May 2004 18:17:20 -0700 Message-ID: <40AD58A0.3000201@backtobasicsmgmt.com> Date: Thu, 20 May 2004 18:17:20 -0700 From: "Kevin P. Fleming" Organization: Back To Basics Network Management User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: XFS backtrace with kernel 2.6.6 References: <40AD491A.7020805@backtobasicsmgmt.com> <20040521105124.B653735@wobbly.melbourne.sgi.com> In-Reply-To: <20040521105124.B653735@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 3174 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 390 Lines: 11 Nathan Scott wrote: > A corrupt directory block from the look of it - did xfs_repair > find anything? Any kind of disk or block layer errors in your > logs? I was not able to take the system down to try xfs_repair, but I can do that tomorrow. No other errors in the logs at all, just about 10 of these in order (captured via a serial console, so I'm pretty sure nothing got missed). From owner-linux-xfs@oss.sgi.com Thu May 20 18:24:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 18:24:38 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4L1OOKO000585 for ; Thu, 20 May 2004 18:24:24 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i4L1SdAT021961 for ; Thu, 20 May 2004 18:28:41 -0700 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 LAA20766; Fri, 21 May 2004 11:24:09 +1000 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 i4L1O6ln656936; Fri, 21 May 2004 11:24:07 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4L1O3LG656009; Fri, 21 May 2004 11:24:03 +1000 (EST) Date: Fri, 21 May 2004 11:24:03 +1000 From: Nathan Scott To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: Bug#249429: xfslibs-dev: xfs/swab.h not ISO-C(++) compliant (fwd) Message-ID: <20040521112403.C653735@wobbly.melbourne.sgi.com> References: <20040518094449.H543681@wobbly.melbourne.sgi.com> <20040520201545.GA8472@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040520201545.GA8472@taniwha.stupidest.org>; from cw@f00f.org on Thu, May 20, 2004 at 01:15:45PM -0700 X-archive-position: 3175 X-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: 291 Lines: 16 On Thu, May 20, 2004 at 01:15:45PM -0700, Chris Wedgwood wrote: > ... > that sounds horrible and i very much doubt it will work with icc (did > any check?) I've only tried it with gcc. > are inlines really out of the question here? Hmm, dunno - will look into that. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu May 20 23:45:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 20 May 2004 23:46:03 -0700 (PDT) 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 i4L6juKO009905 for ; Thu, 20 May 2004 23:45:56 -0700 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 i4L6jnhv000913 for ; Thu, 20 May 2004 23:45:50 -0700 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 i4L6jbAL55530645; Fri, 21 May 2004 16:45:38 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4L6jZg868802600; Fri, 21 May 2004 16:45:35 +1000 (EST) Date: Fri, 21 May 2004 16:45:35 +1000 (EST) From: Nathan Scott Message-Id: <200405210645.i4L6jZg868802600@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 913919 - remove some dead code X-archive-position: 3176 X-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: 1257 Lines: 51 Most of these noticed by Chris Wedgwood, few more of these little cleanups to come over time. Remove xfs_swappable code, its not useful on Linux. Date: Thu May 20 20:30:22 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: hch@lst.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:172224a xfs_inode.c - 1.397 xfs_bmap.h - 1.84 xfs_bmap.c - 1.316 Remove no-longer-used variable in log write code, and a dated comment. Date: Thu May 20 20:42:47 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: hch@lst.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:172225a xfs_log.c - 1.296 xfs_trans_buf.c - 1.117 Remove unused xfs_trans_bhold_until_committed and related macros. Date: Thu May 20 23:35:11 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: hch@lst.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:172230a xfs_trans_item.c - 1.39 xfs_trans.c - 1.157 xfs_trans.h - 1.125 xfs_trans_buf.c - 1.118 From owner-linux-xfs@oss.sgi.com Fri May 21 00:01:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 May 2004 00:01:41 -0700 (PDT) Received: from localhost.localdomain (CPE-144-136-105-90.nsw.bigpond.net.au [144.136.105.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4L71QKO011078 for ; Fri, 21 May 2004 00:01:28 -0700 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i4L71Knq001303 for ; Fri, 21 May 2004 17:01:21 +1000 Message-ID: <40ADA940.6010900@netscape.net> Date: Fri, 21 May 2004 17:01:20 +1000 From: How Wong User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: FC2 XFS install from harddisk Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3177 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: grandsonata@netscape.net Precedence: bulk X-list: linux-xfs Content-Length: 74 Lines: 4 I found a way of upgrading to FC2 using yum. Everything is fine. thanks From owner-linux-xfs@oss.sgi.com Fri May 21 04:07:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 May 2004 04:07:44 -0700 (PDT) Received: from mail.slb.com (eurmta01.london.eur.slb.com [134.32.26.55]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4LB6vKO020878 for ; Fri, 21 May 2004 04:07:01 -0700 Received: from conversion-daemon.eurmta01.london.eur.slb.com by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) id <0HY200D0193VQS@eurmta01.london.eur.slb.com> for linux-xfs@oss.sgi.com; Fri, 21 May 2004 11:05:36 +0000 (GMT) Received: from stavanger.westerngeco.slb.com (wgmail9.stavanger.eur.slb.com [134.32.72.36]) by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPS id <0HY200ED89H8T8@eurmta01.london.eur.slb.com> for linux-xfs@oss.sgi.com; Fri, 21 May 2004 11:05:33 +0000 (GMT) Received: from GSTJ2W (localhost [127.0.0.1]) by stavanger.westerngeco.slb.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id i4LAxfD18395 for ; Fri, 21 May 2004 12:59:42 +0200 (MEST) Date: Fri, 21 May 2004 13:05:29 +0200 From: marat Subject: Re: XFS for postgres databases? In-reply-to: <20040512130047.A28089@infradead.org> To: linux-xfs@oss.sgi.com Message-id: <200405211305.29899.marat@stavanger.westerngeco.slb.com> Organization: westerngeco MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_mk6efV1JbQV/JSLZURDmqQ)" User-Agent: KMail/1.4.1 References: <200405121300.14866.stevew@catalyst.net.nz> <20040512165624.C389759@wobbly.melbourne.sgi.com> <20040512130047.A28089@infradead.org> X-archive-position: 3178 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marat@stavanger.westerngeco.slb.com Precedence: bulk X-list: linux-xfs Content-Length: 9639 Lines: 206 --Boundary_(ID_mk6efV1JbQV/JSLZURDmqQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi experts, I have got some strange problem on Linux RH9 system, kernel 2.4.25 The XFS filesystem crashed with message : Filesystem "sd(8,33)": XFS internal error xfs_btree_check_lblock at line 222 of file xfs_btree.c. Caller 0xf89b695f f65ada4c f89b7ffa f8a14e7a 00000001 f6e78400 f8a14e6e 000000de f89b695f ea6a6dcc e68ffe40 db68dd84 db68dd84 f89b8da5 d3a0d7a8 e3a8d1a0 5f0fbac6 0a05bb82 d87da000 db68dd84 00000000 00000000 f89b695f db68dd84 d87da000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] xfs_force_shutdown(sd(8,33),0x8) called from line 1070 of file xfs_trans.c. Return address = 0xf8a05a5b Filesystem "sd(8,33)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,33) Please umount the filesystem, and rectify the problem(s) I had to reboot system and run xfs_repair. it looks like xfs_repair does not fix all problems, I have tried to run it several times and every time had the same output. I attached output from xfs_repair command ( I had to edit file to make it readable ). I have tried xfsprogs-2.6.3-1 and xfsprogs-2.6.13-1 - no difference. I had to mounted file system, backup data, recreate file system and restore data back. Any ideas, comments ? Regards, -- Marat Mukhitov --Boundary_(ID_mk6efV1JbQV/JSLZURDmqQ) Content-type: text/plain; charset=iso-8859-1; name=xfs_repair.log1 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=xfs_repair.log1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad magic # 0xbcb1f67d in btcnt block 16/1685472 expected level 0 got 48234 in btcnt block 16/1685472 bad magic # 0 in btbno block 17/1251598 bad magic # 0xb915e51a in btcnt block 17/1477488 expected level 0 got 47808 in btcnt block 17/1477488 bad magic # 0xb02ee3b9 in btbno block 18/1254103 expected level 0 got 47231 in btbno block 18/1254103 block (18,1) multiply claimed by bno space tree, state - 1 block (18,2) multiply claimed by bno space tree, state - 1 ............ block (18,3) multiply claimed by bno space tree, state - 1 block (18,14691) multiply claimed by bno space tree, state - 1 block (18,327) multiply claimed by bno space tree, state - 1 bad magic # 0xe03b5984 in btcnt block 18/1419678 expected level 0 got 49211 in btcnt block 18/1419678 block (18,1046073) already used, state 2 block (18,1046074) already used, state 2 ............ block (18,1098880) already used, state 2 block (18,1098881) already used, state 2 bad magic # 0x1695f03a in btcnt block 21/1480040 expected level 0 got 46427 in btcnt block 21/1480040 bad magic # 0xfcb93b9c in btcnt block 23/1282456 expected level 0 got 8380 in btcnt block 23/1282456 bad magic # 0x826de0bd in btcnt block 24/1504404 expected level 0 got 11698 in btcnt block 24/1504404 bad magic # 0xa3896c40 in btbno block 26/281812 expected level 0 got 53014 in btbno block 26/281812 block (26,234675) multiply claimed by bno space tree, state - 1 block (26,234676) multiply claimed by bno space tree, state - 1 block (26,234677) multiply claimed by bno space tree, state - 1 ......... block (26,517477) multiply claimed by bno space tree, state - 1 block (26,517478) multiply claimed by bno space tree, state - 1 block (26,517479) multiply claimed by bno space tree, state - 1 block (26,517480) multiply claimed by bno space tree, state - 1 bno freespace btree block claimed (state 1), agno 26, bno 282741, suspect 0 bno freespace btree block claimed (state 1), agno 26, bno 283654, suspect 0 bno freespace btree block claimed (state 1), agno 26, bno 408215, suspect 0 bno freespace btree block claimed (state 1), agno 26, bno 409127, suspect 0 bno freespace btree block claimed (state 1), agno 26, bno 410040, suspect 0 bno freespace btree block claimed (state 1), agno 26, bno 410953, suspect 0 bno freespace btree block claimed (state 1), agno 26, bno 411882, suspect 0 bno freespace btree block claimed (state 1), agno 26, bno 412795, suspect 0 bno freespace btree block claimed (state 1), agno 26, bno 413708, suspect 0 bno freespace btree block claimed (state 1), agno 26, bno 414621, suspect 0 bno freespace btree block claimed (state 1), agno 26, bno 415534, suspect 0 bad magic # 0x21f74e3c in btcnt block 26/1481762 expected level 0 got 14626 in btcnt block 26/1481762 block (26,6) already used, state 2 block (26,2715) already used, state 2 block (26,2716) already used, state 2 block (26,2717) already used, state 2 block (26,2718) already used, state 2 block (26,2719) already used, state 2 ....... block (26,2) already used, state 2 block (26,3) already used, state 2 block (26,4) already used, state 2 block (26,5) already used, state 2 block (26,6) already used, state 2 block (26,7) already used, state 2 bad magic # 0x531fc0bc in btcnt block 26/1538132 expected level 0 got 15301 in btcnt block 26/1538132 bad magic # 0x1ca93c0a in btcnt block 27/1517551 expected level 0 got 31228 in btcnt block 27/1517551 bad magic # 0xc482bb08 in btbno block 30/871339 expected level 0 got 49761 in btbno block 30/871339 block (30,1199029) multiply claimed by bno space tree, state - 1 block (30,1199030) multiply claimed by bno space tree, state - 1 block (30,1199031) multiply claimed by bno space tree, state - 1 block (30,1199032) multiply claimed by bno space tree, state - 1 block (30,1199033) multiply claimed by bno space tree, state - 1 block (30,1199034) multiply claimed by bno space tree, state - 1 .............. block (31,1243661) multiply claimed by bno space tree, state - 1 block (31,1243662) multiply claimed by bno space tree, state - 1 block (31,1243663) multiply claimed by bno space tree, state - 1 block (31,1243664) multiply claimed by bno space tree, state - 1 bno freespace btree block claimed (state 1), agno 31, bno 932934, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 935685, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 937544, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 939403, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 941248, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 943109, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 945405, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 947267, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 949113, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 1017267, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 1020516, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 1021928, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 1023292, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 1025164, suspect 0 bno freespace btree block claimed (state 1), agno 31, bno 1026560, suspect 0 bcnt freespace btree block claimed (state 1), agno 31, bno 1028859, suspect 0 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 data fork in ino 134 claims free block 301989896 data fork in ino 134 claims free block 301989897 data fork in ino 134 claims free block 301989898 data fork in ino 134 claims free block 301989899 data fork in ino 134 claims free block 301989900 data fork in ino 134 claims free block 301989901 data fork in ino 134 claims free block 301989902 data fork in ino 134 claims free block 301989903 ............. data fork in ino 835 claims free block 530070339 data fork in ino 835 claims free block 530070340 data fork in ino 835 claims free block 530070341 data fork in ino 835 claims free block 530070342 data fork in ino 835 claims free block 530070343 data fork in ino 835 claims free block 530070344 - agno = 1 - agno = 2 - agno = 3 - agno = 4 .......... - 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) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 ............ - 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 --Boundary_(ID_mk6efV1JbQV/JSLZURDmqQ)-- From owner-linux-xfs@oss.sgi.com Fri May 21 07:59:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 May 2004 07:59:44 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4LExZKO027571 for ; Fri, 21 May 2004 07:59:36 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i4LF3xkG027660 for ; Fri, 21 May 2004 08:03:59 -0700 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 i4LExNKe38907104; Fri, 21 May 2004 09:59:23 -0500 (CDT) 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 i4LExN3b496775; Fri, 21 May 2004 09:59:23 -0500 (CDT) Date: Fri, 21 May 2004 09:59:23 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: marat cc: linux-xfs@oss.sgi.com Subject: Re: XFS for postgres databases? In-Reply-To: <200405211305.29899.marat@stavanger.westerngeco.slb.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3179 X-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: 1590 Lines: 34 On Fri, 21 May 2004, marat wrote: > I have got some strange problem on Linux RH9 system, kernel 2.4.25 a kernel.org kernel? > The XFS filesystem crashed with message : > > Filesystem "sd(8,33)": XFS internal error xfs_btree_check_lblock at line 222 of file xfs_btree.c. Caller 0xf89b695f > f65ada4c f89b7ffa f8a14e7a 00000001 f6e78400 f8a14e6e 000000de f89b695f > ea6a6dcc e68ffe40 db68dd84 db68dd84 f89b8da5 d3a0d7a8 e3a8d1a0 5f0fbac6 > 0a05bb82 d87da000 db68dd84 00000000 00000000 f89b695f db68dd84 d87da000 > Call Trace: [] [] [] [] [] please run this through ksyumoops to get full backtrace information. > xfs_force_shutdown(sd(8,33),0x8) called from line 1070 of file xfs_trans.c. Return address = 0xf8a05a5b > Filesystem "sd(8,33)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,33) > Please umount the filesystem, and rectify the problem(s) > > > I had to reboot system and run xfs_repair. it looks like xfs_repair does not fix all problems, I have tried to run it several times and every time had the same output. this may be normal, the first thing repair does is unlink lost+found, and then rediscovers everything in it. rename lost+found and try again, things should be fine. if you still see unrepaired errors please post the complete output of repair (or send directly to me if it's overly long) > I attached output from xfs_repair command ( I had to edit file to make it readable ). hm, what was unreadable? -Eric From owner-linux-xfs@oss.sgi.com Fri May 21 08:38:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 May 2004 08:38:30 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4LFcRKO031841 for ; Fri, 21 May 2004 08:38:27 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4LFcR0m031840 for linux-xfs@oss.sgi.com; Fri, 21 May 2004 08:38:27 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4LFcKKS031823 for ; Fri, 21 May 2004 08:38:20 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4LFERd3028303; Fri, 21 May 2004 08:14:27 -0700 Date: Fri, 21 May 2004 08:14:27 -0700 Message-Id: <200405211514.i4LFERd3028303@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 200] xfs_check should set the exit code to non-zero if the filesystem does not check out X-Bugzilla-Reason: AssignedTo X-archive-position: 3180 X-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: 576 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=200 sandeen@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|xfs-master@oss.sgi.com |sandeen@sgi.com Status|ASSIGNED |NEW ------- Additional Comments From sandeen@sgi.com 2004-21-05 08:14 PDT ------- i'll take a look at this when i get a chance. ------- 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 May 23 15:50:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 May 2004 15:50:20 -0700 (PDT) Received: from web90002.mail.scd.yahoo.com (web90002.mail.scd.yahoo.com [66.218.94.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4NMoJKO019202 for ; Sun, 23 May 2004 15:50:19 -0700 Message-ID: <20040523225013.51141.qmail@web90002.mail.scd.yahoo.com> Received: from [158.140.2.102] by web90002.mail.scd.yahoo.com via HTTP; Sun, 23 May 2004 15:50:13 PDT Date: Sun, 23 May 2004 15:50:13 -0700 (PDT) From: Phy Prabab Subject: limitation of inode count on x86 (32b) To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3181 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: phyprabab@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 429 Lines: 19 Sirs, Do I understand correctly that XFS on x86 is limited to 2^32 inodes? I am looking at making a fairly large XFS file server where there will probably be millions up millions of sym-links. Want to make sure I properly size the server. Thank you for your time. Phy __________________________________ Do you Yahoo!? Yahoo! Domains – Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer From owner-linux-xfs@oss.sgi.com Sun May 23 16:51:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 May 2004 16:51:34 -0700 (PDT) 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 i4NNpQKO023237 for ; Sun, 23 May 2004 16:51:29 -0700 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 i4NNpHiv008301 for ; Sun, 23 May 2004 18:51:18 -0500 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 i4NNp8AL72674844; Mon, 24 May 2004 09:51:08 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4NNp6CL67743436; Mon, 24 May 2004 09:51:06 +1000 (EST) Date: Mon, 24 May 2004 09:51:06 +1000 (EST) From: Nathan Scott Message-Id: <200405232351.i4NNp6CL67743436@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE 907752 - fix acl(5) typo X-archive-position: 3182 X-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: 326 Lines: 13 Fix typo on acl(5) man page. From Andreas Gruenbacher. Date: Sun May 23 16:50:42 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:172301a acl/man/man5/acl.5 - 1.20 From owner-linux-xfs@oss.sgi.com Sun May 23 18:27:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 May 2004 18:27:59 -0700 (PDT) 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 i4O1RsKO025279 for ; Sun, 23 May 2004 18:27:54 -0700 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 i4O1Hihv029036 for ; Sun, 23 May 2004 18:17:45 -0700 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 LAA04356; Mon, 24 May 2004 11:17:41 +1000 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 i4O1Hdln752670; Mon, 24 May 2004 11:17:40 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4O1HciD751259; Mon, 24 May 2004 11:17:38 +1000 (EST) Date: Mon, 24 May 2004 11:17:38 +1000 From: Nathan Scott To: Phy Prabab Cc: linux-xfs@oss.sgi.com Subject: Re: limitation of inode count on x86 (32b) Message-ID: <20040524111738.C751892@wobbly.melbourne.sgi.com> References: <20040523225013.51141.qmail@web90002.mail.scd.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040523225013.51141.qmail@web90002.mail.scd.yahoo.com>; from phyprabab@yahoo.com on Sun, May 23, 2004 at 03:50:13PM -0700 X-archive-position: 3183 X-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: 618 Lines: 21 On Sun, May 23, 2004 at 03:50:13PM -0700, Phy Prabab wrote: > Sirs, > > Do I understand correctly that XFS on x86 is limited > to 2^32 inodes? I am looking at making a fairly large > XFS file server where there will probably be millions > up millions of sym-links. Want to make sure I > properly size the server. > > Thank you for your time. All Linux filesystems are "limited" that way. The size of the inode number in the VFS is 32 bits on i386. See __kernel_ino_t, ino_t, and all the places where "unsigned long" is used directly, eg. the "struct inode" i_ino definition in linux/fs.h. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun May 23 18:39:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 May 2004 18:39:41 -0700 (PDT) Received: from web90002.mail.scd.yahoo.com (web90002.mail.scd.yahoo.com [66.218.94.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4O1ddKO025801 for ; Sun, 23 May 2004 18:39:39 -0700 Message-ID: <20040524013934.30686.qmail@web90002.mail.scd.yahoo.com> Received: from [158.140.2.102] by web90002.mail.scd.yahoo.com via HTTP; Sun, 23 May 2004 18:39:34 PDT Date: Sun, 23 May 2004 18:39:34 -0700 (PDT) From: Phy Prabab Subject: Re: limitation of inode count on x86 (32b) To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040524111738.C751892@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3184 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: phyprabab@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 898 Lines: 43 Thanks Nathan! Phy --- Nathan Scott wrote: > On Sun, May 23, 2004 at 03:50:13PM -0700, Phy Prabab > wrote: > > Sirs, > > > > Do I understand correctly that XFS on x86 is > limited > > to 2^32 inodes? I am looking at making a fairly > large > > XFS file server where there will probably be > millions > > up millions of sym-links. Want to make sure I > > properly size the server. > > > > Thank you for your time. > > All Linux filesystems are "limited" that way. The > size of the > inode number in the VFS is 32 bits on i386. See > __kernel_ino_t, > ino_t, and all the places where "unsigned long" is > used directly, > eg. the "struct inode" i_ino definition in > linux/fs.h. > > cheers. > > -- > Nathan > > __________________________________ Do you Yahoo!? Yahoo! Domains – Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer From owner-linux-xfs@oss.sgi.com Sun May 23 21:46:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 May 2004 21:47:01 -0700 (PDT) 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 i4O4kuKO000343 for ; Sun, 23 May 2004 21:46:56 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id AB2C337B4D for ; Mon, 24 May 2004 04:46:54 +0000 (GMT) Received: from yusufg.portal2.com (210-177-227-130.outblaze.com [210.177.227.130]) by corpmail.outblaze.com (Postfix) with SMTP id 5ABB316DD98 for ; Mon, 24 May 2004 04:46:54 +0000 (GMT) Received: (qmail 21580 invoked by uid 500); 24 May 2004 04:46:53 -0000 Date: Mon, 24 May 2004 12:46:53 +0800 From: Yusuf Goolamabbas To: linux-xfs@oss.sgi.com Subject: Any specific options for creating XFS fs over software raid ? Message-ID: <20040524044653.GA21546@outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-AntiVirus: checked by Vexira MailArmor (version: 2.0.2-5; VAE: 6.25.0.3; VDF: 6.25.0.74; host: corpmail.outblaze.com) X-archive-position: 3185 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yusufg@outblaze.com Precedence: bulk X-list: linux-xfs Content-Length: 365 Lines: 10 Hi, Was reading Christophs and Nathan's email on lkml about using v2 XFS log format when using software raid5 and then Nathan's message about creating the filesystem with -ssize=4096 Are the above statements only true for software raid5 or true for all software raid levels. Are there any other values appropiate for software raid/hardware raid ? Regards, Yusuf From owner-linux-xfs@oss.sgi.com Sun May 23 22:03:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 May 2004 22:03:51 -0700 (PDT) Received: from mail.rsise.anu.edu.au (mail.rsise.anu.edu.au [150.203.208.4]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4O53hKO000902 for ; Sun, 23 May 2004 22:03:44 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.rsise.anu.edu.au (Postfix) with ESMTP id EA4E296CC for ; Mon, 24 May 2004 15:03:41 +1000 (EST) Received: from pulp.anu.edu.au (pulp.anu.edu.au [150.203.126.25]) by mail.rsise.anu.edu.au (Postfix) with ESMTP id 4686096C6 for ; Mon, 24 May 2004 15:03:41 +1000 (EST) Received: by pulp.anu.edu.au (Postfix, from userid 1560) id 777C825B7A3; Mon, 24 May 2004 15:03:36 +1000 (EST) Date: Mon, 24 May 2004 15:03:36 +1000 From: Pietro Abate To: linux-xfs@oss.sgi.com Subject: Re: Any specific options for creating XFS fs over software raid ? Message-ID: <20040524050336.GA5430@pulp.anu.edu.au> References: <20040524044653.GA21546@outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040524044653.GA21546@outblaze.com> X-Operating-System: GNU/Linux X-Organization: Research School of Information Science and Engineering (Australian National University) User-Agent: Mutt/1.5.6i X-Scanned-By: AMaViS-ng/Claimv at mail.rsise.anu.edu.au X-archive-position: 3186 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Pietro.Abate@anu.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 1215 Lines: 31 Hi, On Mon, May 24, 2004 at 12:46:53PM +0800, Yusuf Goolamabbas wrote: > Are the above statements only true for software raid5 or true for all > software raid levels. Are there any other values appropiate for software > raid/hardware raid ? in my understanding the big problem with raid5 is that most controller have a fix block size, but xfs uses two different bs for logs and data. Having external logs can alleviate the problem. On the other side you don't have the same problem with raid1 (please correct me if I'm wrong). Googling around it seems that a fixed bs fs ala ext3 can have better performance that a default xfs on raid5. However it's still not clear to me how to tweak performance of xfs both on raid1/5 and avoid these pitfalls. Moreover the xfs website says that xfs performance on raid are poor and the problem is going to be solved in the next major release. does anybody have any pointer to a xfs on raid performance how-to and the latest news about xfs performance in the development branch ? p -- ++ "All great truths begin as blasphemies." -George Bernard Shaw ++ Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html From owner-linux-xfs@oss.sgi.com Sun May 23 22:26:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 May 2004 22:27:07 -0700 (PDT) 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 i4O5QmKO002162 for ; Sun, 23 May 2004 22:26:49 -0700 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 i4O5M0hv032056 for ; Sun, 23 May 2004 22:22:01 -0700 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 PAA09005; Mon, 24 May 2004 15:21:56 +1000 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 i4O5Lsln756792; Mon, 24 May 2004 15:21:55 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4O5Lr2W755968; Mon, 24 May 2004 15:21:53 +1000 (EST) Date: Mon, 24 May 2004 15:21:53 +1000 From: Nathan Scott To: Yusuf Goolamabbas Cc: linux-xfs@oss.sgi.com Subject: Re: Any specific options for creating XFS fs over software raid ? Message-ID: <20040524152153.G751892@wobbly.melbourne.sgi.com> References: <20040524044653.GA21546@outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040524044653.GA21546@outblaze.com>; from yusufg@outblaze.com on Mon, May 24, 2004 at 12:46:53PM +0800 X-archive-position: 3187 X-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: 474 Lines: 17 On Mon, May 24, 2004 at 12:46:53PM +0800, Yusuf Goolamabbas wrote: > Hi, Was reading Christophs and Nathan's email on lkml about using v2 XFS > log format when using software raid5 and then Nathan's message about > creating the filesystem with -ssize=4096 > > Are the above statements only true for software raid5 or true for all Software raid5 only. > software raid levels. Are there any other values appropiate for software > raid/hardware raid ? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun May 23 22:36:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 May 2004 22:36:31 -0700 (PDT) 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 i4O5aQKO002873 for ; Sun, 23 May 2004 22:36:27 -0700 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 i4O5VDiv029726 for ; Mon, 24 May 2004 00:31:14 -0500 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 PAA09238; Mon, 24 May 2004 15:31:04 +1000 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 i4O5V3ln758104; Mon, 24 May 2004 15:31:03 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4O5V1PG758156; Mon, 24 May 2004 15:31:01 +1000 (EST) Date: Mon, 24 May 2004 15:31:01 +1000 From: Nathan Scott To: Pietro Abate Cc: linux-xfs@oss.sgi.com Subject: Re: Any specific options for creating XFS fs over software raid ? Message-ID: <20040524153101.H751892@wobbly.melbourne.sgi.com> References: <20040524044653.GA21546@outblaze.com> <20040524050336.GA5430@pulp.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040524050336.GA5430@pulp.anu.edu.au>; from Pietro.Abate@anu.edu.au on Mon, May 24, 2004 at 03:03:36PM +1000 X-archive-position: 3188 X-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: 1265 Lines: 35 On Mon, May 24, 2004 at 03:03:36PM +1000, Pietro Abate wrote: > Hi, > > On Mon, May 24, 2004 at 12:46:53PM +0800, Yusuf Goolamabbas wrote: > > Are the above statements only true for software raid5 or true for all > > software raid levels. Are there any other values appropiate for software > > raid/hardware raid ? > > in my understanding the big problem with raid5 is that most controller > have a fix block size, but xfs uses two different bs for logs and data. Theres a bit more to it than that, but thats close to the mark, yes. > Having external logs can alleviate the problem. External logs help, but don't completely alleviate the problem. Using a sector size that matches the filesystem blocksize is the key, as it ensures _all_ IOs coming out of XFS are aligned with that size boundary. > However it's still not clear to me how to tweak performance of xfs both > on raid1/5 and avoid these pitfalls. Moreover the xfs website says that > xfs performance on raid are poor and the problem is going to be solved > in the next major release. The website is quite out of date & needs lots of updating, so I wouldn't put too much faith in what it says at the moment. Unfortunately we're always too busy hacking the code to update it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon May 24 16:32:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 May 2004 16:32:47 -0700 (PDT) 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 i4ONWhKO030395 for ; Mon, 24 May 2004 16:32:43 -0700 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 i4ONWYhv014086 for ; Mon, 24 May 2004 16:32:37 -0700 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 i4ONWWAL71128908 for ; Tue, 25 May 2004 09:32:32 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4ONWVRl64564732 for linux-xfs@oss.sgi.com; Tue, 25 May 2004 09:32:31 +1000 (EST) Date: Tue, 25 May 2004 09:32:31 +1000 (EST) From: Nathan Scott Message-Id: <200405242332.i4ONWVRl64564732@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - add missing line from 2.6.6 merge X-archive-position: 3189 X-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: 360 Lines: 13 Merge back an overlooked writeback change from akpm on 2.6.6 merge. Date: Mon May 24 16:31:11 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: akpm@osdl.org The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:172377a linux-2.6/xfs_aops.c - 1.71 From owner-linux-xfs@oss.sgi.com Tue May 25 11:30:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 May 2004 11:30:12 -0700 (PDT) Received: from smtp1.ActiveState.com (gw.activestate.com [209.17.183.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4PIU9gi003103 for ; Tue, 25 May 2004 11:30:10 -0700 Received: from smtp3.ActiveState.com (latte.activestate.com [192.168.4.252]) by smtp1.ActiveState.com (8.12.10/8.12.10) with ESMTP id i4PIU4Ys008268 for ; Tue, 25 May 2004 11:30:04 -0700 (envelope-from daves@ActiveState.com) Received: from ActiveState.com (rock.ActiveState.com [192.168.3.223]) by smtp3.ActiveState.com (8.12.9/8.12.9) with ESMTP id i4PIU31M011641 for ; Tue, 25 May 2004 11:30:04 -0700 Message-ID: <40B390AB.3080204@ActiveState.com> Date: Tue, 25 May 2004 11:30:03 -0700 From: David Sparks Reply-To: daves@ActiveState.com Organization: ActiveState User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Any specific options for creating XFS fs over software raid ? References: <20040524044653.GA21546@outblaze.com> In-Reply-To: <20040524044653.GA21546@outblaze.com> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3191 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daves@ActiveState.com Precedence: bulk X-list: linux-xfs Content-Length: 1454 Lines: 32 Yusuf Goolamabbas wrote: > Hi, Was reading Christophs and Nathan's email on lkml about using v2 XFS > log format when using software raid5 and then Nathan's message about > creating the filesystem with -ssize=4096 I've got a software MD RAID5 that was not created with that option. I could've sworn that I read that mkfs.xfs would query the block size if it was being created on a MD device and adjust accordingly. In any case the logs fill up with this seems to confirm a block mismatch (512 vs 4096). May 25 11:17:13 [kernel] raid5: switching cache buffer size, 512 --> 4096 May 25 11:17:13 [kernel] raid5: switching cache buffer size, 4096 --> 512 May 25 11:17:14 [kernel] raid5: switching cache buffer size, 512 --> 4096 May 25 11:17:14 [kernel] raid5: switching cache buffer size, 4096 --> 512 May 25 11:17:14 [kernel] raid5: switching cache buffer size, 512 --> 4096 May 25 11:17:14 [kernel] raid5: switching cache buffer size, 4096 --> 512 May 25 11:17:14 [kernel] raid5: switching cache buffer size, 512 --> 4096 May 25 11:17:15 [kernel] raid5: switching cache buffer size, 4096 --> 512 May 25 11:17:15 [kernel] raid5: switching cache buffer size, 512 --> 4096 May 25 11:17:15 [kernel] raid5: switching cache buffer size, 4096 --> 512 ----->%----- What is the best course of action to fix this problem? Backup data, reformat partition and restore data? Should I adjust the MD device to match XFS or adjust XFS to match MD? TIA! ds From owner-linux-xfs@oss.sgi.com Tue May 25 21:44:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 May 2004 21:44:46 -0700 (PDT) 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 i4Q4ihgi030407 for ; Tue, 25 May 2004 21:44:43 -0700 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 i4Q4iWhv013967 for ; Tue, 25 May 2004 21:44:35 -0700 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 OAA07491; Wed, 26 May 2004 14:44:14 +1000 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 i4Q4i2ln813670; Wed, 26 May 2004 14:44:05 +1000 (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 i4Q5ftnb005395; Wed, 26 May 2004 15:41:56 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i4Q5faW8005393; Wed, 26 May 2004 15:41:36 +1000 Date: Wed, 26 May 2004 15:41:36 +1000 From: Nathan Scott To: David Sparks Cc: linux-xfs@oss.sgi.com Subject: Re: Any specific options for creating XFS fs over software raid ? Message-ID: <20040526054136.GC4645@frodo> References: <20040524044653.GA21546@outblaze.com> <40B390AB.3080204@ActiveState.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40B390AB.3080204@ActiveState.com> User-Agent: Mutt/1.5.3i X-archive-position: 3193 X-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: 1091 Lines: 33 Hi there, On Tue, May 25, 2004 at 11:30:03AM -0700, David Sparks wrote: > Yusuf Goolamabbas wrote: > >Hi, Was reading Christophs and Nathan's email on lkml about using v2 XFS > >log format when using software raid5 and then Nathan's message about > >creating the filesystem with -ssize=4096 > > I've got a software MD RAID5 that was not created with that option. I > could've sworn that I read that mkfs.xfs would query the block size if > it was being created on a MD device and adjust accordingly. mkfs.xfs queries alot of things, and at one point in the code it does actually know if its writing to a MD RAID5 device. There isn't any heuristic in there for switching to a sector size that matches the block size though, we'll need to add that. Its on my list now... ;) > What is the best course of action to fix this problem? Backup data, > reformat partition and restore data? Yep. > Should I adjust the MD device to > match XFS or adjust XFS to match MD? You cannot do the former (while contining to use RAID5), so the latter will be your best bet. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed May 26 10:23:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 May 2004 10:23:47 -0700 (PDT) Received: from c000.snv.cp.net (h001.c000.snv.cp.net [209.228.32.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4QHNjgi004772 for ; Wed, 26 May 2004 10:23:45 -0700 Received: (cpmta 20383 invoked from network); 26 May 2004 10:23:43 -0700 Received: from 209.228.32.75 (HELO mail.bakke.com.criticalpath.net) by smtp.bakke.com (209.228.32.65) with SMTP; 26 May 2004 10:23:42 -0700 X-Sent: 26 May 2004 17:23:43 GMT Received: from [80.202.108.94] by mail.bakke.com with HTTP; Wed, 26 May 2004 10:23:42 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 To: linux-xfs@oss.sgi.com From: dag@bakke.com Subject: xfsdump hangs - 2.6.6 && 2.6.7-rc1-bk3 X-Sent-From: dag@bakke.com Date: Wed, 26 May 2004 10:23:42 -0700 (PDT) X-Mailer: Web Mail 5.6.3-1 Message-Id: <20040526102342.19709.h011.c000.wm@mail.bakke.com.criticalpath.net> X-archive-position: 3195 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dag@bakke.com Precedence: bulk X-list: linux-xfs Content-Length: 3072 Lines: 79 Sent this on the l-k list. Think it may belong here as well. I experience hangs with xfsdump, when dumping my rootfs to a USB 2.0 connected drive. The hangs are reproducible within 0.2-2 GB of dump, and always come together with one or two instances of : pagebuf_get: failed to lookup pages Note: xfsdump hangs, not the kernel. I do not know if this is a problem with xfs, ide, scsi, usb, VM or some other area of the kernel. But it is reproducible with 2.6.6 + a few select patches, and with plain 2.6.7-rc1-bk3. I have collected sysrq-t, sysrq-p info. A snippet below. If none of this explains the hang, maybe the gurus would like to point a browser at: http://thaifood.homeip.net/xfsdumphang/xfsdump.dmesg.txt http://thaifood.homeip.net/xfsdumphang/config-2.6.7-rc1-bk3 http://thaifood.homeip.net/xfsdumphang/lspci.txt http://thaifood.homeip.net/xfsdumphang/lsusb.txt xfssyncd S C04F25E0 0 331 1 342 317 (L-TLB) cfccbf9c 00000046 c1370610 c04f25e0 cfc31d60 c0238bec cfc31d98 c04fecd8 00000031 00000000 cfccbfb0 00002773 37e96cbf 00000210 c13707b8 000a43c5 cfccbfb0 00000000 00000000 c03d2ec3 cfccbfb0 000a43c5 00000000 c048e508 Call Trace: [] pagebuf_rele+0x2c/0x120 [] schedule_timeout+0x63/0xc0 [] process_timeout+0x0/0x10 [] xfssyncd+0x57/0xc0 [] xfssyncd+0x0/0xc0 [] kernel_thread_helper+0x5/0x18 usb-storage S C04F2A88 0 342 1 343 331 (L-TLB) cfc09f4c 00000046 c13ff0d0 c04f2a88 0000020f 3ccbf196 00000000 c58bfcea c58c004c 0000020f c13ff0d0 0000012d c58c004c 0000020f c1370238 c13b0f04 00000246 cfc08000 c1370090 c03d24c7 cfc08000 c13b0f0c 00000000 00000001 Call Trace: [] __down_interruptible+0xa7/0x140 [] default_wake_function+0x0/0x20 [] wake_up_process+0x1d/0x30 [] __down_failed_interruptible+0x7/0xc [] .text.lock.usb+0x5/0x58 [] schedule_tail+0x17/0x50 [] ret_from_fork+0x6/0x14 [] usb_stor_control_thread+0x0/0x280 [] usb_stor_control_thread+0x0/0x280 [] kernel_thread_helper+0x5/0x18 scsi_eh_0 S C04F25E0 0 343 1 485 342 (L-TLB) cfab7f78 00000046 cfab96b0 c04f25e0 00000000 00000000 00000000 00000000 00000086 cfab7f7c c13ff650 000015c8 2850a2f5 00000184 cfab9858 cfab7fd4 00000246 cfab6000 cfab96b0 c03d24c7 cfab6000 cfab7fdc 00000000 00000001 Call Trace: [] __down_interruptible+0xa7/0x140 [] default_wake_function+0x0/0x20 [] __down_failed_interruptible+0x7/0xc [] .text.lock.scsi_error+0x41/0x49 [] scsi_error_handler+0x0/0x110 [] kernel_thread_helper+0x5/0x18 A few more bits of info, as I have no idea where to start *): - the target filesystem is writeable after xfsdump hangs - the USB2IDE chip is an ISD-300. - the USB 2.0 controller is a NEC chip on a CardBus card. - gcc 3.3, xfsdump 2.2.16 *) Yeah, I can start doing a binary search for a working kernel.... Anyone? Dag B From owner-linux-xfs@oss.sgi.com Wed May 26 13:42:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 May 2004 13:42:59 -0700 (PDT) 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 i4QKgsgi014489 for ; Wed, 26 May 2004 13:42:54 -0700 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 i4QKbrhv027873 for ; Wed, 26 May 2004 13:37:54 -0700 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 GAA28307; Thu, 27 May 2004 06:37:46 +1000 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 i4QKbhln830772; Thu, 27 May 2004 06:37:44 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4QKbf5F833045; Thu, 27 May 2004 06:37:41 +1000 (EST) Date: Thu, 27 May 2004 06:37:40 +1000 From: Nathan Scott To: dag@bakke.com Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfsdump hangs - 2.6.6 && 2.6.7-rc1-bk3 Message-ID: <20040527063740.A832024@wobbly.melbourne.sgi.com> References: <20040526091315.17983.h012.c000.wm@mail.bakke.com.criticalpath.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040526091315.17983.h012.c000.wm@mail.bakke.com.criticalpath.net>; from dag@bakke.com on Wed, May 26, 2004 at 09:13:14AM -0700 X-archive-position: 3196 X-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: 1296 Lines: 38 hi Dag, On Wed, May 26, 2004 at 09:13:14AM -0700, dag@bakke.com wrote: > > I experience hangs with xfsdump, when dumping my rootfs to a USB 2.0 > connected drive. The hangs are reproducible within 0.2-2 GB of dump, and > always come together with one or two instances of : > > pagebuf_get: failed to lookup pages > > xfssyncd S C04F25E0 0 331 1 342 317 (L-TLB) > cfccbf9c 00000046 c1370610 c04f25e0 cfc31d60 c0238bec cfc31d98 c04fecd8 > 00000031 00000000 cfccbfb0 00002773 37e96cbf 00000210 c13707b8 000a43c5 > cfccbfb0 00000000 00000000 c03d2ec3 cfccbfb0 000a43c5 00000000 c048e508 > Call Trace: > [] pagebuf_rele+0x2c/0x120 > [] schedule_timeout+0x63/0xc0 > [] process_timeout+0x0/0x10 > [] xfssyncd+0x57/0xc0 > [] xfssyncd+0x0/0xc0 > [] kernel_thread_helper+0x5/0x18 > > Anyone? > This looks like the result of an earlier error on the code path at that initial warning there (known problem) - in the current code there is a situation where we attempt metadata readahead, cannot initialise a XFS buffer completely due to low memory, but fail to correctly tear down that partially created buffer when passing back the (recoverable) error. We're working on a fix. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed May 26 22:01:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 May 2004 22:01:44 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4R51egi008111 for ; Wed, 26 May 2004 22:01:41 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i4R56o5N004922 for ; Wed, 26 May 2004 22:06:52 -0700 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 PAA08450; Thu, 27 May 2004 15:01:20 +1000 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 i4R51Cln843030; Thu, 27 May 2004 15:01:16 +1000 (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 i4R5x3nb008998; Thu, 27 May 2004 15:59:03 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i4R5wT5t008996; Thu, 27 May 2004 15:58:29 +1000 Date: Thu, 27 May 2004 15:58:29 +1000 From: Nathan Scott To: dag@bakke.com Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfsdump hangs - 2.6.6 && 2.6.7-rc1-bk3 Message-ID: <20040527055829.GA8981@frodo> References: <20040526091315.17983.h012.c000.wm@mail.bakke.com.criticalpath.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040526091315.17983.h012.c000.wm@mail.bakke.com.criticalpath.net> User-Agent: Mutt/1.5.3i X-archive-position: 3197 X-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: 833 Lines: 33 On Wed, May 26, 2004 at 09:13:14AM -0700, dag@bakke.com wrote: > > I experience hangs with xfsdump, when dumping my rootfs to a USB 2.0 > ... > http://thaifood.homeip.net/xfsdumphang/xfsdump.dmesg.txt > ... The xfsdump stack trace in there is the important one. Can you try this patch and let me know how it goes? thanks. -- Nathan --- fs/xfs/linux/xfs_buf.c.orig 2004-05-27 14:06:59.992936144 +1000 +++ fs/xfs/linux/xfs_buf.c 2004-05-27 14:08:21.548537808 +1000 @@ -370,8 +370,12 @@ retry: page = find_or_create_page(mapping, first + i, gfp_mask); if (unlikely(page == NULL)) { - if (flags & PBF_READ_AHEAD) + if (flags & PBF_READ_AHEAD) { + for (--i; i >= 0; i--) + page_cache_release(bp->pb_pages[i]); + _pagebuf_free_pages(bp); return -ENOMEM; + } /* * This could deadlock. From owner-linux-xfs@oss.sgi.com Thu May 27 00:00:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 May 2004 00:00:11 -0700 (PDT) Received: from ns5.sony.co.jp (NS5.Sony.CO.JP [137.153.0.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4R708gi021250 for ; Thu, 27 May 2004 00:00:08 -0700 Received: from mail3.sony.co.jp (mail3.sony.co.jp [43.0.1.203]) Received: from mail3.sony.co.jp (localhost [127.0.0.1]) by mail3.sony.co.jp (R8/Sony) with ESMTP id i4R705827622 for ; Thu, 27 May 2004 16:00:05 +0900 (JST) Received: from cpgsgw.sys1.cpg.sony.co.jp ([43.4.148.1]) by mail3.sony.co.jp (R8/Sony) with ESMTP id i4R704T27609 for ; Thu, 27 May 2004 16:00:05 +0900 (JST) Received: from dse10.sys1.cpg.sony.co.jp (dse10 [43.4.149.10]) by cpgsgw.sys1.cpg.sony.co.jp (8.8.8+Sun/3.6W/980617(siva)) with ESMTP id QAA10604 for ; Thu, 27 May 2004 16:00:04 +0900 (JST) Received: from DSE77 by dse10.sys1.cpg.sony.co.jp (8.8.8/6.4J.6) id QAA20704; Thu, 27 May 2004 16:00:04 +0900 (JST) To: linux-xfs@oss.sgi.com Subject: data corruption on nfs+xfs From: Kazuyuki Goto Message-Id: <200405271558.EJG73779.VJBLYZVL@sys1.cpg.sony.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Thu, 27 May 2004 15:58:48 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3199 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kazuyuki@sys1.cpg.sony.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 934 Lines: 23 We are experiencing the same problem as No.198. http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 http://marc.theaimsgroup.com/?t=108343605300001&r=1&w=2 We have confirmed that even when the refcache is disabled, setting fs.xfs.refcache_size to zero through sysctl, the problem does not disappear. To run linux as single CPU mode, it makes the problem slightly hard to occur, but it still occurs. Two types of corruption we've seen: 1) Width is a multiple of 8kB, starting at 8kB boundary. *Maybe the same trouble as No.198. 2) Width is a 964 bytes, ending up to 4kB boundary. *I'm not sure the cause is same as 1) above. We have tested on 2.4.20-20.9.XFS1.3.1, 2.4.20-30.9.sgi1 XFS1.3.3 and other kernels based on 2.4.20-20 on which we made some changes. Anyone who knows where is the cause. On page cache, disk block handling, or other parts? Or who knows how to avoid this with some setting or another version? From owner-linux-xfs@oss.sgi.com Thu May 27 01:09:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 May 2004 01:10:06 -0700 (PDT) Received: from c000.snv.cp.net (h013.c000.snv.cp.net [209.228.32.77]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4R89lgi011821 for ; Thu, 27 May 2004 01:09:47 -0700 Received: (cpmta 14906 invoked from network); 27 May 2004 01:09:46 -0700 Received: from 209.228.32.82 (HELO mail.bakke.com.criticalpath.net) by smtp.bakke.com (209.228.32.77) with SMTP; 27 May 2004 01:09:46 -0700 X-Sent: 27 May 2004 08:09:46 GMT Received: from [195.204.181.130] by mail.bakke.com with HTTP; Thu, 27 May 2004 01:09:46 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 To: nathans@sgi.com Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com From: dag@bakke.com Subject: Re: xfsdump hangs - 2.6.6 && 2.6.7-rc1-bk3 X-Sent-From: dag@bakke.com Date: Thu, 27 May 2004 01:09:46 -0700 (PDT) X-Mailer: Web Mail 5.6.3-1 Message-Id: <20040527010946.9778.h018.c000.wm@mail.bakke.com.criticalpath.net> X-archive-position: 3200 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dag@bakke.com Precedence: bulk X-list: linux-xfs Content-Length: 4276 Lines: 127 One failure, one success, one question :-) On Thu, 27 May 2004 15:58:29 +1000, Nathan Scott wrote: > > On Wed, May 26, 2004 at 09:13:14AM -0700, dag@bakke.com wrote: > > > > I experience hangs with xfsdump, when dumping my rootfs to a USB 2.0 > > ... > > http://thaifood.homeip.net/xfsdumphang/xfsdump.dmesg.txt > > ... > > The xfsdump stack trace in there is the important one. > Can you try this patch and let me know how it goes? > > --- fs/xfs/linux/xfs_buf.c.orig 2004-05-27 14:06:59.992936144 +1000 > +++ fs/xfs/linux/xfs_buf.c 2004-05-27 14:08:21.548537808 +1000 > @@ -370,8 +370,12 @@ > retry: > page = find_or_create_page(mapping, first + i, gfp_mask); > if (unlikely(page == NULL)) { > - if (flags & PBF_READ_AHEAD) > + if (flags & PBF_READ_AHEAD) { > + for (--i; i >= 0; i--) > + page_cache_release(bp->pb_pages[i]); > + _pagebuf_free_pages(bp); > return -ENOMEM; > + } > > /* > * This could deadlock. xfsdump completes "successfully", but prematurely. And I get an oops. Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: c02381b3 *pde = 00000000 Oops: 0000 [#1] PREEMPT Modules linked in: 3c589_cs CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010206 (2.6.7-rc1-bk3) EIP is at _pagebuf_lookup_pages+0x2b3/0x2e0 eax: ffffffff ebx: 0000ffff ecx: cba8db84 edx: 00000000 esi: cba8dac0 edi: 000389b4 ebp: 00002000 esp: cefa5cc8 ds: 007b es: 007b ss: 0068 Process xfsdump (pid: 5769, threadinfo=cefa4000 task=cf54b6f0) Stack: cffa6afc 000389b4 00001200 00000000 cefa4000 00000000 00000000 000389b4 00000002 00001200 00000000 00001000 00000009 cffa6afc cba8dac0 cba8dac0 00019011 00000002 c023867b cba8dac0 00019011 00000000 00002000 00019011 Call Trace: [] pagebuf_get+0x19b/0x1b0 [] xfs_btree_reada_bufs+0x71/0x90 [] xfs_bulkstat+0xd18/0x1000 [] xfs_ioc_bulkstat+0x10b/0x1f0 [] xfs_bulkstat_one+0x0/0x5f0 [] xfs_ioctl+0x68d/0x840 [] setup_rt_frame+0x1b5/0x2d0 [] xfs_inactive_free_eofblocks+0x107/0x2d0 [] dput+0x31/0x220 [] linvfs_ioctl+0x3d/0x70 [] setup_rt_frame+0x1b5/0x2d0 [] setup_rt_frame+0x1b5/0x2d0 [] sys_ioctl+0x100/0x270 [] setup_rt_frame+0x1b5/0x2d0 [] sys_close+0x61/0xa0 [] sysenter_past_esp+0x52/0x71 [] setup_rt_frame+0x1b5/0x2d0 Code: 8b 02 f6 c4 08 75 f0 8b 42 04 40 74 14 83 42 04 ff 0f 98 c0 xfsrestore: restore complete: 403 seconds elapsed xfsrestore: Restore Status: SUCCESS Filesystem Size Used Avail Use% Mounted on /dev/hda3 3.3G 2.0G 1.3G 62% / /dev/scsi/host0/bus0/target0/lun0/part3 9.4G 562M 8.8G 6% /mnt/target But: his patch from hch Works For Me: --- 1.111/fs/xfs/linux/xfs_buf.c 2004-04-28 06:45:14 +02:00 +++ edited/fs/xfs/linux/xfs_buf.c 2004-05-26 18:58:14 +02:00 @@ -370,8 +370,12 @@ retry: page = find_or_create_page(mapping, first + i, gfp_mask); if (unlikely(page == NULL)) { - if (flags & PBF_READ_AHEAD) + if (flags & PBF_READ_AHEAD) { + bp->pb_page_count = i; + for (i = 0; i < bp->pb_page_count; i++) + unlock_page(bp->pb_pages[i]); return -ENOMEM; + } /* * This could deadlock. Tested two dumps now, and both completes successfully. And for real. I have yet to boot on the new root fs, though. :-) The one remaining question is: why does xfsrestore print xfsrestore: WARNING: open_by_handle of mnt failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of bin failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of dev/rd failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of dev/ida failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of dev failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of sys failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of tftpboot failed:Bad file descriptor etc. etc. for what appears to be every directory in the source fs? This is at the end of the dump, just prior to the xfsrestore: restore complete: 403 seconds elapsed xfsrestore: Restore Status: SUCCESS message? From owner-linux-xfs@oss.sgi.com Thu May 27 01:18:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 May 2004 01:18:59 -0700 (PDT) Received: from pentafluge.infradead.org ([213.146.154.40]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4R8Irgi012488 for ; Thu, 27 May 2004 01:18:56 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.33 #1 (Red Hat Linux)) id 1BTG6D-0003Ej-QT; Thu, 27 May 2004 09:18:49 +0100 Date: Thu, 27 May 2004 09:18:49 +0100 From: Christoph Hellwig To: dag@bakke.com Cc: nathans@sgi.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfsdump hangs - 2.6.6 && 2.6.7-rc1-bk3 Message-ID: <20040527081849.GA12359@infradead.org> Mail-Followup-To: Christoph Hellwig , dag@bakke.com, nathans@sgi.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20040527010946.9778.h018.c000.wm@mail.bakke.com.criticalpath.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040527010946.9778.h018.c000.wm@mail.bakke.com.criticalpath.net> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 3201 X-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: 1092 Lines: 39 My patch still wasn't complete, you're still leaking pages, just not locked ones, this patch should be better and I'll check it in in a few minutes: --- 1.111/fs/xfs/linux/xfs_buf.c 2004-04-28 06:45:14 +02:00 +++ edited/fs/xfs/linux/xfs_buf.c 2004-05-27 08:38:46 +02:00 @@ -359,6 +359,7 @@ error = _pagebuf_get_pages(bp, page_count, flags); if (unlikely(error)) return error; + bp->pb_flags |= _PBF_PAGE_CACHE; offset = bp->pb_offset; first = bp->pb_file_offset >> PAGE_CACHE_SHIFT; @@ -370,8 +371,12 @@ retry: page = find_or_create_page(mapping, first + i, gfp_mask); if (unlikely(page == NULL)) { - if (flags & PBF_READ_AHEAD) + if (flags & PBF_READ_AHEAD) { + bp->pb_page_count = i; + for (i = 0; i < bp->pb_page_count; i++) + unlock_page(bp->pb_pages[i]); return -ENOMEM; + } /* * This could deadlock. @@ -426,8 +431,6 @@ for (i = 0; i < bp->pb_page_count; i++) unlock_page(bp->pb_pages[i]); } - - bp->pb_flags |= _PBF_PAGE_CACHE; if (page_count) { /* if we have any uptodate pages, mark that in the buffer */ From owner-linux-xfs@oss.sgi.com Thu May 27 02:26:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 May 2004 02:26:16 -0700 (PDT) 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 i4R9QAgi028389 for ; Thu, 27 May 2004 02:26:10 -0700 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 i4R9FMhv032549 for ; Thu, 27 May 2004 02:15:22 -0700 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 i4R9FLKe38972680; Thu, 27 May 2004 04:15:21 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1BTGyu-0003OA-00; Thu, 27 May 2004 04:15:20 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 915110 - Don't leak locked pages on readahead failure Message-Id: From: Christoph Hellwig Date: Thu, 27 May 2004 04:15:20 -0500 X-archive-position: 3203 X-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: 421 Lines: 17 Date: Thu May 27 02:15:06 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:172618a fs/xfs/linux-2.6/xfs_buf.c - 1.171 - Don't leak locked pages on readahead failure fs/xfs/linux-2.4/xfs_buf.c - 1.189 - Don't leak locked pages on readahead failure From owner-linux-xfs@oss.sgi.com Thu May 27 03:05:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 May 2004 03:05:28 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4RA5Pgi031583 for ; Thu, 27 May 2004 03:05:25 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i4RAAdbd012856 for ; Thu, 27 May 2004 03:10:40 -0700 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 UAA14357; Thu, 27 May 2004 20:05:11 +1000 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 i4RA59ln847880; Thu, 27 May 2004 20:05:10 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4RA56ub849164; Thu, 27 May 2004 20:05:06 +1000 (EST) Date: Thu, 27 May 2004 20:05:06 +1000 From: Nathan Scott To: dag@bakke.com Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfsdump hangs - 2.6.6 && 2.6.7-rc1-bk3 Message-ID: <20040527200506.A811659@wobbly.melbourne.sgi.com> References: <20040527010946.9778.h018.c000.wm@mail.bakke.com.criticalpath.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040527010946.9778.h018.c000.wm@mail.bakke.com.criticalpath.net>; from dag@bakke.com on Thu, May 27, 2004 at 01:09:46AM -0700 X-archive-position: 3204 X-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: 505 Lines: 20 On Thu, May 27, 2004 at 01:09:46AM -0700, dag@bakke.com wrote: > One failure, one success, one question :-) > ... > But: his patch from hch Works For Me: > Yep, use that final patch from Christoph, thats got all of the bases covered. > The one remaining question is: why does xfsrestore print > xfsrestore: WARNING: open_by_handle of mnt failed:Bad file descriptor Thats familiar - I can't remember the exact cause anymore, but I think a more recent xfsdump solve that for you. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu May 27 04:49:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 May 2004 04:49:39 -0700 (PDT) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4RBnYgi006702 for ; Thu, 27 May 2004 04:49:35 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id A1C52162377 for ; Thu, 27 May 2004 13:49:33 +0200 (CEST) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25258-09 for ; Thu, 27 May 2004 13:49:32 +0200 (CEST) Received: from opticalart.de (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id 82CF4162376 for ; Thu, 27 May 2004 13:49:32 +0200 (CEST) Message-ID: <40B5D5CB.7020702@opticalart.de> Date: Thu, 27 May 2004 13:49:31 +0200 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS List Subject: Shared Devices with XFS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 3205 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Content-Length: 1216 Lines: 28 Hi Guys! Sorry to be a bit Off-Topic, but unfortunatly I can't test this out by myself... I am checking out a way to speed up data-transfers between a server and a couple of clients. A fullblown SAN (CXFS etc) approach is currently not in our budget, but we already have a couple of directly attached fibre-channel diskarrays here. I will buy a FC-switch to get the arrays easily switched over to the clients to speed up things (instead of copying over network). Now, my question: What will happen if I configure the FC-switch to route a single diskarray to all machines, mount that device read-write on the server and read-only on the clients? Will XFS allow me to do that? How propable is non-integrity data on the clients (considering that the server won't write to that device at that time anymore)? What will happen if all clients strom out to get data at the same time? Thanks a lot. Cheers, Frank... -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a Digital Cinema http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 From owner-linux-xfs@oss.sgi.com Thu May 27 05:20:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 May 2004 05:20:24 -0700 (PDT) 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 i4RCKBgi007636 for ; Thu, 27 May 2004 05:20:12 -0700 Received: (qmail 23133 invoked from network); 27 May 2004 12:03:36 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay01.roc.ny.frontiernet.net (FrontierMTA 2.3.23) with SMTP for ; 27 May 2004 12:03:36 -0000 Message-ID: <40B5D903.4050601@xfs.org> Date: Thu, 27 May 2004 07:03:15 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank Hellmann CC: XFS List Subject: Re: Shared Devices with XFS References: <40B5D5CB.7020702@opticalart.de> In-Reply-To: <40B5D5CB.7020702@opticalart.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3206 X-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: 2082 Lines: 46 Frank Hellmann wrote: > Hi Guys! > > Sorry to be a bit Off-Topic, but unfortunatly I can't test this out by > myself... > > I am checking out a way to speed up data-transfers between a server and > a couple of clients. A fullblown SAN (CXFS etc) approach is currently > not in our budget, but we already have a couple of directly attached > fibre-channel diskarrays here. I will buy a FC-switch to get the arrays > easily switched over to the clients to speed up things (instead of > copying over network). > > Now, my question: What will happen if I configure the FC-switch to route > a single diskarray to all machines, mount that device read-write on the > server and read-only on the clients? Will XFS allow me to do that? How > propable is non-integrity data on the clients (considering that the > server won't write to that device at that time anymore)? What will > happen if all clients strom out to get data at the same time? The software will not stop you from doing this, but DON'T! There is a good chance what will happen here is your read-only nodes will crash at some point, or at least decide the fs is corrupted and needs to be shutdown. The read only nodes will have a lot of metadata in cache, and will not know that it is stale and should be refreshed from disk. Once they get a mix of inconsistent metadata all bets are off. You will tend to see stale data as well, and things which the read/write node has put into the filesystem may not show up for a while. Sharing a SAN filesystem between machines involves a lot more than just cabling up the storage ;-). Shared read only on all nodes should be fine, if you want to update content, you have to unmount all but one, make it rw, update content, make it ro again then allow the other nodes to remount. That mode of operation does not fly for many applications. Finally, if two nodes both need to read the same data at the same time, they issue scsi commands to the device, and one gets to wait for the other to complete - but at least the second one gets to use cache on the device. Steve From owner-linux-xfs@oss.sgi.com Thu May 27 05:57:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 May 2004 05:57:03 -0700 (PDT) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4RCuwgi008820 for ; Thu, 27 May 2004 05:57:00 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id 6BD86162377; Thu, 27 May 2004 14:56:58 +0200 (CEST) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27969-02; Thu, 27 May 2004 14:56:57 +0200 (CEST) Received: from opticalart.de (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id 0A4B3162358; Thu, 27 May 2004 14:56:57 +0200 (CEST) Message-ID: <40B5E594.1000605@opticalart.de> Date: Thu, 27 May 2004 14:56:52 +0200 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord Cc: XFS List Subject: Re: Shared Devices with XFS References: <40B5D5CB.7020702@opticalart.de> <40B5D903.4050601@xfs.org> In-Reply-To: <40B5D903.4050601@xfs.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 3207 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Content-Length: 3167 Lines: 90 Hi! see below... Steve Lord wrote: > Frank Hellmann wrote: > >> Hi Guys! >> >> Sorry to be a bit Off-Topic, but unfortunatly I can't test this out by >> myself... >> >> I am checking out a way to speed up data-transfers between a server >> and a couple of clients. A fullblown SAN (CXFS etc) approach is >> currently not in our budget, but we already have a couple of directly >> attached fibre-channel diskarrays here. I will buy a FC-switch to get >> the arrays easily switched over to the clients to speed up things >> (instead of copying over network). >> >> Now, my question: What will happen if I configure the FC-switch to >> route a single diskarray to all machines, mount that device >> read-write on the server and read-only on the clients? Will XFS allow >> me to do that? How propable is non-integrity data on the clients >> (considering that the server won't write to that device at that time >> anymore)? What will happen if all clients strom out to get data at the >> same time? > > > The software will not stop you from doing this, but DON'T! > ;-)))) I knew you would say that... > There is a good chance what will happen here is your read-only nodes > will crash at some point, or at least decide the fs is corrupted and > needs to be shutdown. The read only nodes will have a lot of > metadata in cache, and will not know that it is stale and should be > refreshed from disk. Once they get a mix of inconsistent metadata > all bets are off. You will tend to see stale data as well, and > things which the read/write node has put into the filesystem may > not show up for a while. So, there is no way of striktly working read-only of disk without caching/relying on the meta-data locally. > > Sharing a SAN filesystem between machines involves a lot more than > just cabling up the storage ;-). Right. Most of it has to do with loads of money... ;-) > > Shared read only on all nodes should be fine, if you want to > update content, you have to unmount all but one, make it rw, > update content, make it ro again then allow the other nodes > to remount. That mode of operation does not fly for many applications. > Actually, this is fine for our application. We aquire a lot of hires 50MB sized images that are not changed after that. The clients work on proxy images that they generate locally of these hires images. So during aquisition I can unmount all clients and do the r/w operations and after that mount it on all clients as read-only. That is still better then putting the arrays directly on the single clients... > Finally, if two nodes both need to read the same data at the same time, > they issue scsi commands to the device, and one gets to wait for the > other to complete - but at least the second one gets to use cache on > the device. :-) Thanks a lot Steve. Cheers, Frank... > > Steve > > > > -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a Digital Cinema http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 From owner-linux-xfs@oss.sgi.com Thu May 27 10:41:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 May 2004 10:41:12 -0700 (PDT) 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 i4RHfAgi032476 for ; Thu, 27 May 2004 10:41:10 -0700 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 i4RHUBhv006972 for ; Thu, 27 May 2004 10:30:11 -0700 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.10/SGI_generic_relay-1.2) with ESMTP id i4RHUAKe39301192 for ; Thu, 27 May 2004 12:30:11 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i4RHU9us855837; Thu, 27 May 2004 12:30:09 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id i4RHTqYO021267; Thu, 27 May 2004 12:29:52 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id i4RHTqle021265; Thu, 27 May 2004 12:29:52 -0500 Date: Thu, 27 May 2004 12:29:52 -0500 From: Eric Sandeen Message-Id: <200405271729.i4RHTqle021265@penguin.americas.sgi.com> Subject: TAKE 915269 - Fix overflow at 8 Exabytes X-archive-position: 3208 X-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@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 871 Lines: 27 Found this when running test 071 on 64-bit boxes. Those of you squeezing every last byte out of your 64-bit box can now safely write offsets of 2^63-1 :) Fix overflow in mapping test at offsets of 2^63-1 bytes Date: Thu May 27 10:28:34 PDT 2004 Workarea: penguin.americas.sgi.com:/src/eric/linux-2.4.x Inspected by: nathans,felixb The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:172649a fs/xfs/linux-2.6/xfs_aops.c - 1.72 - When checking whether a mapping matches our offset, test in such a way that it will not overflow 63 bits - calculate last offset in the mapping for comparison fs/xfs/linux-2.4/xfs_aops.c - 1.79 - When checking whether a mapping matches our offset, test in such a way that it will not overflow 63 bits - calculate last offset in the mapping for comparison From owner-linux-xfs@oss.sgi.com Thu May 27 12:11:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 May 2004 12:11:23 -0700 (PDT) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4RJBCgi010036 for ; Thu, 27 May 2004 12:11:17 -0700 Received: from [10.1.2.212] (localhost [127.0.0.1]) by shell.wgops.com (Postfix) with ESMTP id D6D9625752 for ; Thu, 27 May 2004 13:10:41 -0600 (MDT) Date: Thu, 27 May 2004 13:10:41 -0600 From: Michael Loftis To: XFS List Subject: Re: Shared Devices with XFS Message-ID: <0A4C8004C98B7312BADB01FD@[10.1.2.212]> In-Reply-To: <40B5D5CB.7020702@opticalart.de> References: <40B5D5CB.7020702@opticalart.de> X-Mailer: Mulberry/3.1.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-MailScanner-Information: Please contact support@wgops.com X-MailScanner: WGOPS clean X-archive-position: 3209 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 1670 Lines: 46 Unless the filesystem is designed for it (like GFS) 100% chance of crashes, data integrity and other problems. --On Thursday, May 27, 2004 13:49 +0200 Frank Hellmann wrote: > Hi Guys! > > Sorry to be a bit Off-Topic, but unfortunatly I can't test this out by > myself... > > I am checking out a way to speed up data-transfers between a server and a > couple of clients. A fullblown SAN (CXFS etc) approach is currently not > in our budget, but we already have a couple of directly attached > fibre-channel diskarrays here. I will buy a FC-switch to get the arrays > easily switched over to the clients to speed up things (instead of > copying over network). > > Now, my question: What will happen if I configure the FC-switch to route > a single diskarray to all machines, mount that device read-write on the > server and read-only on the clients? Will XFS allow me to do that? How > propable is non-integrity data on the clients (considering that the > server won't write to that device at that time anymore)? What will happen > if all clients strom out to get data at the same time? > > Thanks a lot. Cheers, > > Frank... > -- > -------------------------------------------------------------------------- > Frank Hellmann Optical Art GmbH Waterloohain 7a > Digital Cinema http://www.opticalart.de 22769 Hamburg > frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 > > > -- Undocumented Features quote of the moment... "It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.'" --Murphy's Laws of Combat From owner-linux-xfs@oss.sgi.com Thu May 27 20:51:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 May 2004 20:51:42 -0700 (PDT) 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 i4S3pSgi011549 for ; Thu, 27 May 2004 20:51:29 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i4S3e5iv016715 for ; Thu, 27 May 2004 22:40:06 -0500 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i4S3e3V17199 for linux-xfs@oss.sgi.com; Fri, 28 May 2004 13:40:03 +1000 Date: Fri, 28 May 2004 13:40:03 +1000 From: Nathan Scott Message-Id: <200405280340.i4S3e3V17199@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - split patches X-archive-position: 3210 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 490 Lines: 17 Update patches - revert much of free_more_memory after talking to akpm, and add DMAPI maintainer entry into dmapi-enable patch. Date: Thu May 27 20:38:56 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:172688a fs/buffer.c - 1.4 include/linux/fs.h - 1.5 split-patches/dmapi-enable - 1.2 split-patches/free_more_memory - 1.2 From owner-linux-xfs@oss.sgi.com Thu May 27 21:19:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 May 2004 21:19:56 -0700 (PDT) Received: from staff.shaolinmicro.com ([202.131.75.34]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4S4Jggi012839 for ; Thu, 27 May 2004 21:19:43 -0700 Received: from shaolinmicro.com ([202.131.75.35]) by staff.shaolinmicro.com (8.12.8/8.12.5) with ESMTP id i4S4AaKb014998 for ; Fri, 28 May 2004 12:10:36 +0800 Message-ID: <40B6BE48.2050106@shaolinmicro.com> Date: Fri, 28 May 2004 12:21:28 +0800 From: David Chow Organization: Shaolin Microsystems Ltd. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 X-Accept-Language: zh_TW, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Write to XFS in VFS and page cache Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3211 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: davidchow@shaolinmicro.com Precedence: bulk X-list: linux-xfs Content-Length: 1033 Lines: 17 Dear xfs people, I am new to this list . I am a stackable file system developer which means we write file systems for file systems. When my fs runs with xfs, I notice I got zero data written to the target file. My write path as follows, xfspage=read_cache_page(xfsmapping, index,(filler_t *) xfsmapping->a_ops->readpage); wait_on_page(xfspage); xfs_aops->prepare_write(xfsfile, xfspage, offset, to); kmap(xfspage); memcpy(page_address(xfspage),somedata, somelength); xfs_aops->commit_write(xfsfile, xfspage, offset, to); Both prepare_write and commit_write returns 0 . I did a quick glance on the xfs code and notice that it is using the generic_commit_write() facility . Since my fs works on most of the file systems which also used the generic_commit_write() (e.g. ext2) . I am running Linux kernel 2.4.23 with XFS latest split patches on the SGI web site. If you can point out the pointers on how the XFS write path for dirty pages works, I will be appreciated. Any help and comment are welcome. Thanks. regards, David Chow From owner-linux-xfs@oss.sgi.com Fri May 28 13:08:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 May 2004 13:08:39 -0700 (PDT) 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 i4SK8Ygi002265 for ; Fri, 28 May 2004 13:08:35 -0700 Received: from [10.0.1.41] ([68.213.19.251]) by imf22aec.mail.bellsouth.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with ESMTP id <20040528200829.LXFW12800.imf22aec.mail.bellsouth.net@[10.0.1.41]>; Fri, 28 May 2004 16:08:29 -0400 Subject: Re: Shared Devices with XFS From: Greg Freemyer To: Frank Hellmann Cc: Steve Lord , XFS List In-Reply-To: <40B5E594.1000605@opticalart.de> References: <40B5D5CB.7020702@opticalart.de> <40B5D903.4050601@xfs.org> <40B5E594.1000605@opticalart.de> Content-Type: text/plain Message-Id: <1085774867.518.11.camel@david.internal.norcrossgroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 28 May 2004 16:07:47 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 3212 X-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: 1690 Lines: 48 On Thu, 2004-05-27 at 05:56, Frank Hellmann wrote: > Hi! > > see below... > > Steve Lord wrote: > > Frank Hellmann wrote: > > > > > > Sharing a SAN filesystem between machines involves a lot more than > > just cabling up the storage ;-). > > Right. Most of it has to do with loads of money... ;-) > OT: non-xfs below You could try opengfs, ocfs (Oracle Cluster File Server), or lustre. All are GPL and have production installs. I don't know what sort of performance any of them have in a primarily read-only environment, but it should not be too bad. OpenGFS: OpenGFS currently has a spof (single point of failure) if the lock server dies. OpenGFS is trying to get 0.4 out in the next couple of months. It will be the first opengfs release with no single points of failure, if that is important to you. Intel has a couple of engineers that have been working on the 0.4 release pretty hard. I heard yesterday that they hope to have a 0.4 beta out in the next week or so. ocfs: The biggest problem with ocfs is that it does not have any file-locking, but if you are doing read-only, that should not matter to you. Oracle is supposidely working on ocfs2 which will have more functionality. Lustre: I don't know much about lustre, but I don't think it is designed for a shared SAN. If anybody knows different, please correct me. Also GFS from RH (via the Sistina acquisition) is supposed to be released GPL at some point. I don't know much about GFS, but it has a dedicated engineering team that works on it. Sistina has been selling it commercially for 3 years I think. Hopefully it will be GPL'ed this summer? (Search for old press releases.) Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Fri May 28 15:57:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 May 2004 15:57:22 -0700 (PDT) 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 i4SMvJgi011730 for ; Fri, 28 May 2004 15:57:19 -0700 Received: (qmail 16633 invoked from network); 28 May 2004 20:39:16 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.23) with SMTP for ; 28 May 2004 20:39:16 -0000 Message-ID: <40B7A35F.9010409@xfs.org> Date: Fri, 28 May 2004 15:38:55 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Freemyer CC: Frank Hellmann , XFS List Subject: Re: Shared Devices with XFS References: <40B5D5CB.7020702@opticalart.de> <40B5D903.4050601@xfs.org> <40B5E594.1000605@opticalart.de> <1085774867.518.11.camel@david.internal.norcrossgroup.com> In-Reply-To: <1085774867.518.11.camel@david.internal.norcrossgroup.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3213 X-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: 2442 Lines: 68 Greg Freemyer wrote: > On Thu, 2004-05-27 at 05:56, Frank Hellmann wrote: > >>Hi! >> >>see below... >> >>Steve Lord wrote: >> >>>Frank Hellmann wrote: >>> > > >>>Sharing a SAN filesystem between machines involves a lot more than >>>just cabling up the storage ;-). >> >>Right. Most of it has to do with loads of money... ;-) >> > > > OT: non-xfs below > > You could try opengfs, ocfs (Oracle Cluster File Server), or lustre. > All are GPL and have production installs. I don't know what sort of > performance any of them have in a primarily read-only environment, but > it should not be too bad. > > OpenGFS: OpenGFS currently has a spof (single point of failure) if the > lock server dies. OpenGFS is trying to get 0.4 out in the next couple > of months. It will be the first opengfs release with no single points > of failure, if that is important to you. Intel has a couple of > engineers that have been working on the 0.4 release pretty hard. I heard > yesterday that they hope to have a 0.4 beta out in the next week or so. > > ocfs: The biggest problem with ocfs is that it does not have any > file-locking, but if you are doing read-only, that should not matter to > you. Oracle is supposidely working on ocfs2 which will have more > functionality. > > Lustre: I don't know much about lustre, but I don't think it is designed > for a shared SAN. If anybody knows different, please correct me. Lustre shares data via a high speed network, not fiberchannel. There are storage nodes - one metadata and a bunch of object stores. These are all dedicated linux boxes with their own storage. The Lustre clients run on the nodes the apps are on, these access the storage by talking to the metadata and object store nodes. You can do things like stripe files across the nodes etc. For speed you need a very fast network. > > Also GFS from RH (via the Sistina acquisition) is supposed to be > released GPL at some point. I don't know much about GFS, but it has a > dedicated engineering team that works on it. Sistina has been selling > it commercially for 3 years I think. Hopefully it will be GPL'ed this > summer? (Search for old press releases.) > Yep, this summer I hear - will show up first in a Redhat release. > Greg There are also other commercial offerings available on Linux, which unlike CXFS do not require an SGI metdata server and will run on fairly generic hardware. Still fairly spendy though. Steve From owner-linux-xfs@oss.sgi.com Fri May 28 16:16:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 May 2004 16:16:03 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4SNFxgi013810 for ; Fri, 28 May 2004 16:16:00 -0700 Received: from [192.168.1.105] ([216.241.42.118]) by hptimail01.HPTI.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.0); Fri, 28 May 2004 19:15:59 -0400 Subject: Re: Shared Devices with XFS From: Craig Tierney To: Greg Freemyer , linux-xfs@oss.sgi.com In-Reply-To: <1085774867.518.11.camel@david.internal.norcrossgroup.com> References: <40B5D5CB.7020702@opticalart.de> <40B5D903.4050601@xfs.org> <40B5E594.1000605@opticalart.de> <1085774867.518.11.camel@david.internal.norcrossgroup.com> Content-Type: text/plain Message-Id: <1085786072.4172.632.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 28 May 2004 17:14:32 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 May 2004 23:15:59.0366 (UTC) FILETIME=[BC8DFA60:01C44509] X-archive-position: 3214 X-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: 3123 Lines: 74 On Fri, 2004-05-28 at 14:07, Greg Freemyer wrote: > On Thu, 2004-05-27 at 05:56, Frank Hellmann wrote: > > Hi! > > > > see below... > > > > Steve Lord wrote: > > > Frank Hellmann wrote: > > > > > > > > > > Sharing a SAN filesystem between machines involves a lot more than > > > just cabling up the storage ;-). > > > > Right. Most of it has to do with loads of money... ;-) > > > > OT: non-xfs below (deleting descriptions of openGFS, GFS, ocfs, and Lustre) There are a few other options as well. StorNEXT (ADIC) - A heterogeneous, shared filesystem. It used to be called Centravision Filesystem (CVFS). All clients share the same physical disk(s). Works with Linux and other platforms. Similar to CXFS (at least to a first order). Single metadata server, but supports failover. StorNEXT is powerful because it is more than just a shared filesytem. They have integrated HSM features so multiple clients can access mass store caches directly. If you have really big mass store systems this additional feature is quite handy. Polyserve - Shared filesystem for Linux. Metadata is striped over all servers. Actively supports efficient export over NFS to non-Linux clients or to large systems where you are not going to have all clients directly attached to disks (SAN network or iSCSI) Ibrix - Shared/distributed filesystem for Linux. It is distributed in that you can have multiple, separate servers that are aggregated into one namespace. It also shares the 'Shared' description because if a server shares a disk with the other servers (FC or iSCSI) then the clients can obtain locks from the other server and then directly read and/or write to the disk. I know they support direct reads, but I am not sure if direct writes are supported yet. There is one more interesting thing here. Ibrix provides a client kernel module for access. So all of the nodes in your cluster or infrastructure can use the client for efficient access of the servers, skipping other alternatives like NFS. DataGRID (Terrascale) - This is an interesting project because it is more like a parallel filesystem but used shared filesystem access patterns. It leverages much of the Linux infrastructure. It is based on EXT2, and block devices are exported from each IO server (target). Then the rest of the clients (initiators) uses traditional Linux tools to mount the filesystems. If you want a parallel filesytem, use MD or LVM to stripe each block device. They have their own iSCSI like device that does all of the magic. It supports locking and coordinates disk access because all initiators access the same set of disks from each target. Since the original topic was share devices, PVFS1/2 don't really fit, because they are parallel filesystems. Each uses their own disk, and a filesystem is striped across all servers. This is more similar to Lustre, but Lustre can be a distrbuted filesystem (multiple servers, mulitple disks, single namespace) as well as a parallel filesytem. Metadata services in PVFS2 are striped across all servers. Obvious choices for web server names work in all cases. Craig From owner-linux-xfs@oss.sgi.com Fri May 28 18:01:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 May 2004 18:01:59 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4T11ngi022464 for ; Fri, 28 May 2004 18:01:49 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4T11n9R022463 for linux-xfs@oss.sgi.com; Fri, 28 May 2004 18:01:49 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4T11lgk022449 for ; Fri, 28 May 2004 18:01:47 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4T0DFat020951; Fri, 28 May 2004 17:13:15 -0700 Date: Fri, 28 May 2004 17:13:15 -0700 Message-Id: <200405290013.i4T0DFat020951@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 332] New: XFS internal error shuts down root filesystem. X-Bugzilla-Reason: AssignedTo X-archive-position: 3215 X-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: 1866 Lines: 52 http://oss.sgi.com/bugzilla/show_bug.cgi?id=332 Summary: XFS internal error shuts down root filesystem. Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: daniel-xfs@electricrain.com Using kernel 2.6.6 - disk would operate normally for a period of time between 10 minutes and 2 days, and then start giving I/O errors. This is the root disk. I was able to get this kernel dump from a statically compiled dmesg residing on a different (although also XFS) filesystem. XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller 0xc018f0ad Call Trace: [] xfs_free_ag_extent+0x487/0x790 [] xfs_free_extent+0xcd/0xf0 [] xfs_free_extent+0xcd/0xf0 [] xfs_inobt_rshift+0x14f/0x460 [] xfs_trans_get_efd+0x38/0x50 [] xfs_bmap_finish+0x138/0x1d0 [] xfs_itruncate_finish+0x223/0x450 [] xfs_setattr+0xe9f/0x10f0 [] linvfs_setattr+0x12f/0x1f0 [] notify_change+0x14e/0x190 [] do_truncate+0x6e/0xb0 [] permission+0x2f/0x50 [] may_open+0x171/0x1d0 [] open_namei+0xa2/0x470 [] filp_open+0x3e/0x70 [] sys_open+0x5b/0xb0 [] syscall_call+0x7/0xb xfs_force_shutdown(sda2,0x8) called from line 4049 of file fs/xfs/xfs_bmap.c. Return address = 0xc01fc5ab Filesystem "sda2": Corruption of in-memory data detected. Shutting down filesystem: sda2 Please umount the filesystem, and rectify the problem(s) ------- 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 May 29 07:01:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 May 2004 07:01:54 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4TE1pgi028603 for ; Sat, 29 May 2004 07:01:51 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4TE1pKQ028602 for linux-xfs@oss.sgi.com; Sat, 29 May 2004 07:01:51 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4TE1ogk028588 for ; Sat, 29 May 2004 07:01:50 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4TDEAtA026757; Sat, 29 May 2004 06:14:10 -0700 Date: Sat, 29 May 2004 06:14:10 -0700 Message-Id: <200405291314.i4TDEAtA026757@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 333] New: quotas not letting using get to hard limit. X-Bugzilla-Reason: AssignedTo X-archive-position: 3216 X-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: 1730 Lines: 56 http://oss.sgi.com/bugzilla/show_bug.cgi?id=333 Summary: quotas not letting using get to hard limit. Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: deon@wurley.net Hi There - I'm using FC2 for the first time, and xfs for the first time too. I was playing with quotas, and created a soft limit quota for user "deon" of 200 blocks, and a hard limit of 300 blocks. When I start creating a file - it seems I can only create it up to 256 blocks then I get quota exceed write denied errors. I would be expecting that after I exceed 300 blocks? The file system was mounted like this (its an LVM volume): mount /dev/vgroot/lvxfs /mnt/tmp -ousrquota,grpquota Here is an example: bash-2.05b$ dd if=/dev/zero of=6 bs=4096 count=70 dd: writing `6': Disk quota exceeded 65+0 records in 64+0 records out bash-2.05b$ sync bash-2.05b$ quota Disk quotas for user deon (uid 200): Filesystem blocks quota limit grace files quota limit grace /dev/mapper/vgroot-lvxfs 256* 200 300 7days 1 0 0 Any attempts to create a new file, also give me Disk quota exceed - even if I touch an empty file. This is the only file the this user has on this file system. Is this a bug, or have I got the wrong expections for quota? (BTW, I'm using stock standard Fedora Core 2 - so its kernel 2.6.5-1.358). ...deon ------- 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 May 29 08:58:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 May 2004 08:58:53 -0700 (PDT) Received: from iceberg.elsat.net.pl (iceberg.elsat.net.pl [217.173.160.37]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4TFwkgi003601 for ; Sat, 29 May 2004 08:58:47 -0700 Received: from iceberg.elsat.net.pl (localhost.localdomain [127.0.0.1]) by iceberg.elsat.net.pl (8.12.11/8.12.11) with ESMTP id i4TFwqpL005014 for ; Sat, 29 May 2004 17:58:52 +0200 Received: (from kszysiu@localhost) by iceberg.elsat.net.pl (8.12.11/8.12.11/Submit) id i4TFwqv0005011 for linux-xfs@oss.sgi.com; Sat, 29 May 2004 17:58:52 +0200 Date: Sat, 29 May 2004 17:58:52 +0200 From: Krzysztof Rusocki To: linux-xfs@oss.sgi.com Subject: xfs oops (CVS-2004-05-15_05:00_UTC) Message-ID: <20040529155852.GA30391@iceberg.elsat.net.pl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 3217 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kszysiu@iceberg.elsat.net.pl Precedence: bulk X-list: linux-xfs Content-Length: 39487 Lines: 1699 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I've just got an oops while working in X, I was dropped into kdb, - I blindly typed ,,go'' in order to try to get the system running, oops dump and kernel config - attached. Machine is a low-end AMD Duron on an ECS K7S5A, with merely 128M of memory. System (FC2) is still up so if there's anything I can do before doing cvs update and compiling recent kernel - let me know. I don't know whether this is out of relevance but I also had slab error on 2.6.5 (FC2 Test3) (SGI-XFS CVS-2004-04-20_05:00_UTC), here it is: slab error in cache_free_debugcheck(): cache `linvfs_icache': double free, or memory outside object was overwritten Call Trace: [] __slab_error+0x2f/0x40 [] kmem_cache_free+0x23e/0x310 [] linvfs_destroy_inode+0x1b/0x20 [] linvfs_destroy_inode+0x1b/0x20 [] destroy_inode+0x35/0x50 [] dispose_list+0x47/0xa0 [] prune_icache+0xc2/0x1f0 [] shrink_icache_memory+0x23/0x30 [] shrink_slab+0x120/0x170 [] balance_pgdat+0x1b8/0x200 [] kswapd+0xfc/0x100 [] autoremove_wake_function+0x0/0x50 [] ret_from_fork+0x6/0x14 [] autoremove_wake_function+0x0/0x50 [] kswapd+0x0/0x100 [] kernel_thread_helper+0x5/0x14 c1eeddcc: redzone 1: 0x170fc2e5, redzone 2: 0x170fc2a5. Cheers, Krzysztof --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=oops Unable to handle kernel paging request at virtual address 6b6b6b73 printing eip: c022c490 *pde = 00000000 Oops: 0000 [#1] PREEMPT CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010282 (2.6.6-xfs-cvs) EIP is at pagebuf_daemon+0xe0/0x1c0 eax: 6b6b6b6b ebx: c7e8a680 ecx: 00000000 edx: c11e09f8 esi: c03a1874 edi: c11b0000 ebp: c11b1fd4 esp: c11b1fc8 ds: 007b es: 007b ss: 0068 Process xfsbufd (pid: 12, threadinfo=c11b0000 task=c11b5130) Stack: c7e8a680 00000000 00003a98 c7871ec0 c7e8ae80 00000000 c022c3b0 00000000 00000000 00000000 c0102091 00000000 00000000 00000000 Call Trace: [] pagebuf_daemon+0x0/0x1c0 [] kernel_thread_helper+0x5/0x14 Code: 8b 40 08 85 c0 74 0e 8b 40 44 85 c0 74 07 8b 50 14 85 d2 75 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="oops.processed" ksymoops 2.4.9 on i686 2.6.6-xfs-cvs. Options used -v /boot/vmlinux-2.6.6-xfs-cvs (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.6.6-xfs-cvs/ (default) -m /boot/System.map-2.6.6-xfs-cvs (specified) Error (regular_file): read_ksyms stat /proc/ksyms failed No modules in ksyms, skipping objects No ksyms, skipping lsmod Unable to handle kernel paging request at virtual address 6b6b6b73 c022c490 *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 (2.6.6-xfs-cvs) eax: 6b6b6b6b ebx: c7e8a680 ecx: 00000000 edx: c11e09f8 esi: c03a1874 edi: c11b0000 ebp: c11b1fd4 esp: c11b1fc8 ds: 007b es: 007b ss: 0068 Stack: c7e8a680 00000000 00003a98 c7871ec0 c7e8ae80 00000000 c022c3b0 00000000 00000000 00000000 c0102091 00000000 00000000 00000000 Call Trace: [] pagebuf_daemon+0x0/0x1c0 [] kernel_thread_helper+0x5/0x14 Code: 8b 40 08 85 c0 74 0e 8b 40 44 85 c0 74 07 8b 50 14 85 d2 75 >>EIP; c022c490 <===== >>eax; 6b6b6b6b <__crc_zlib_inflate+a7c75/294b7d> >>ebx; c7e8a680 <__crc_send_sig+55478/91a1f> >>edx; c11e09f8 <__crc_iov_shorten+8965/1e742> >>esi; c03a1874 >>edi; c11b0000 <__crc_generic_read_dir+20d458/2354eb> >>ebp; c11b1fd4 <__crc_generic_read_dir+20f42c/2354eb> >>esp; c11b1fc8 <__crc_generic_read_dir+20f420/2354eb> Trace; c022c3b0 Trace; c0102091 Code; c022c490 00000000 <_EIP>: Code; c022c490 <===== 0: 8b 40 08 mov 0x8(%eax),%eax <===== Code; c022c493 3: 85 c0 test %eax,%eax Code; c022c495 5: 74 0e je 15 <_EIP+0x15> Code; c022c497 7: 8b 40 44 mov 0x44(%eax),%eax Code; c022c49a a: 85 c0 test %eax,%eax Code; c022c49c c: 74 07 je 15 <_EIP+0x15> Code; c022c49e e: 8b 50 14 mov 0x14(%eax),%edx Code; c022c4a1 11: 85 d2 test %edx,%edx Code; c022c4a3 13: 75 00 jne 15 <_EIP+0x15> 1 error issued. Results may not be reliable. --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="config-2.6.6-xfs-cvs" # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y # CONFIG_STANDALONE is not set CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_HOTPLUG is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_EMBEDDED=y CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_DEBUG=y CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_USE_VECTOR=y # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # # CONFIG_PNP is not set # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_CRYPTOLOOP is not set CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_CARMEL is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_LBD is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_IDEDISK_STROKE=y CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_TASKFILE_IO=y # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set CONFIG_BLK_DEV_IDEPCI=y # CONFIG_IDEPCI_SHARE_IRQ is not set # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set CONFIG_BLK_DEV_SIS5513=y # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=m # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_REPORT_LUNS is not set CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # # SCSI Transport Attributes # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=m # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_QLA6322 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y # CONFIG_NETLINK_DEV is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m # CONFIG_IP_NF_MATCH_AH_ESP is not set CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_LOCAL=y # CONFIG_IP_NF_NAT_SNMP_BASIC is not set CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m # CONFIG_IP_NF_ARPTABLES is not set # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set CONFIG_IP_NF_TARGET_NOTRACK=m CONFIG_IP_NF_RAW=m CONFIG_XFRM=y # CONFIG_XFRM_USER is not set # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set CONFIG_LLC=m # CONFIG_LLC2 is not set CONFIG_IPX=m # CONFIG_IPX_INTERN is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set CONFIG_NET_DIVERT=y # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_CSZ=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_DELAY=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETPOLL=y # CONFIG_NETPOLL_RX is not set # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set CONFIG_NETDEVICES=y CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=m # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set CONFIG_NET_VENDOR_3COM=y # CONFIG_EL1 is not set # CONFIG_EL2 is not set # CONFIG_ELPLUS is not set # CONFIG_EL16 is not set # CONFIG_EL3 is not set # CONFIG_3C515 is not set CONFIG_VORTEX=m CONFIG_TYPHOON=m # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # # Tulip family network device support # CONFIG_NET_TULIP=y # CONFIG_DE2104X is not set # CONFIG_TULIP is not set # CONFIG_DE4X5 is not set CONFIG_WINBOND_840=m CONFIG_DM9102=m # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_CS89x0 is not set # CONFIG_DGRS is not set CONFIG_EEPRO100=m # CONFIG_EEPRO100_PIO is not set CONFIG_E100=m # CONFIG_E100_NAPI is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set CONFIG_NE2K_PCI=m CONFIG_8139CP=m CONFIG_8139TOO=y # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set CONFIG_SIS900=m # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set CONFIG_VIA_RHINE=m # CONFIG_VIA_RHINE_MMIO is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=m # CONFIG_PPP_SYNC_TTY is not set CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set CONFIG_SHAPER=m CONFIG_NETCONSOLE=y # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_SERIAL=m # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_ACPI=y CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set # CONFIG_PRINTER is not set CONFIG_PPDEV=m # CONFIG_TIPAR is not set # CONFIG_QIC02_TAPE is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_WAFER_WDT is not set # CONFIG_I8XX_TCO is not set # CONFIG_SC1200_WDT is not set # CONFIG_SCx200_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_W83627HF_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_MACHZ_WDT is not set # # ISA-based Watchdog Cards # # CONFIG_PCWATCHDOG is not set # CONFIG_MIXCOMWD is not set # CONFIG_WDT is not set # # PCI-based Watchdog Cards # # CONFIG_PCIPCWATCHDOG is not set # CONFIG_WDTPCI is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set # CONFIG_HW_RANDOM is not set CONFIG_NVRAM=m CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set # CONFIG_AGP_INTEL_MCH is not set # CONFIG_AGP_NVIDIA is not set CONFIG_AGP_SIS=m # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set CONFIG_HANGCHECK_TIMER=y # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_ELEKTOR is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set CONFIG_I2C_ISA=m # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_SCx200_ACB is not set CONFIG_I2C_SIS5595=m CONFIG_I2C_SIS630=m CONFIG_I2C_SIS96X=m # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # CONFIG_I2C_VOODOO3 is not set # # Hardware Sensors Chip support # CONFIG_I2C_SENSOR=m CONFIG_SENSORS_ADM1021=m # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_GL518SM is not set CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM90=m # CONFIG_SENSORS_VIA686A is not set CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83627HF=m # # Other I2C Chip support # CONFIG_SENSORS_EEPROM=m # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # CONFIG_VIDEO_BT848=m # CONFIG_VIDEO_PMS is not set # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_CQCAM is not set # CONFIG_VIDEO_W9966 is not set # CONFIG_VIDEO_CPIA is not set CONFIG_VIDEO_SAA5246A=m # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set CONFIG_VIDEO_SAA7134=m # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set CONFIG_VIDEO_CX88=m # # Radio Adapters # # CONFIG_RADIO_CADET is not set # CONFIG_RADIO_RTRACK is not set # CONFIG_RADIO_RTRACK2 is not set # CONFIG_RADIO_AZTECH is not set # CONFIG_RADIO_GEMTEK is not set # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # CONFIG_RADIO_SF16FMI is not set # CONFIG_RADIO_SF16FMR2 is not set # CONFIG_RADIO_TERRATEC is not set # CONFIG_RADIO_TRUST is not set # CONFIG_RADIO_TYPHOON is not set # CONFIG_RADIO_ZOLTRIX is not set # # Digital Video Broadcasting Devices # CONFIG_DVB=y CONFIG_DVB_CORE=m # # Supported Frontend Modules # # CONFIG_DVB_STV0299 is not set # CONFIG_DVB_SP887X is not set # CONFIG_DVB_ALPS_TDLB7 is not set # CONFIG_DVB_ALPS_TDMB7 is not set # CONFIG_DVB_ATMEL_AT76C651 is not set # CONFIG_DVB_CX24110 is not set # CONFIG_DVB_GRUNDIG_29504_491 is not set # CONFIG_DVB_GRUNDIG_29504_401 is not set # CONFIG_DVB_MT312 is not set # CONFIG_DVB_VES1820 is not set # CONFIG_DVB_VES1X93 is not set # CONFIG_DVB_TDA1004X is not set # CONFIG_DVB_NXT6000 is not set # # Supported SAA7146 based PCI Adapters # CONFIG_DVB_AV7110=m # CONFIG_DVB_AV7110_FIRMWARE is not set CONFIG_DVB_AV7110_OSD=y CONFIG_DVB_BUDGET=m CONFIG_DVB_BUDGET_CI=m CONFIG_DVB_BUDGET_AV=m CONFIG_DVB_BUDGET_PATCH=m # # Supported USB Adapters # # CONFIG_DVB_TTUSB_BUDGET is not set # CONFIG_DVB_TTUSB_DEC is not set # # Supported FlexCopII (B2C2) Adapters # # CONFIG_DVB_B2C2_SKYSTAR is not set # # Supported BT878 Adapters # # CONFIG_DVB_BT8XX is not set CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_VIDEO_VIDEOBUF=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_BUF=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_IR=m # # Graphics support # # CONFIG_FB is not set CONFIG_VIDEO_SELECT=y # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set CONFIG_SND_MPU401=m # # ISA devices # # CONFIG_SND_AD1848 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_SB8 is not set # CONFIG_SND_SB16 is not set # CONFIG_SND_SBAWE is not set # CONFIG_SND_WAVEFRONT is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_SGALAXY is not set # CONFIG_SND_SSCAPE is not set # # PCI devices # CONFIG_SND_AC97_CODEC=m # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set CONFIG_SND_BT87X=m # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set CONFIG_SND_EMU10K1=m # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set CONFIG_SND_CMIPCI=m # CONFIG_SND_ENS1370 is not set CONFIG_SND_ENS1371=m # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set CONFIG_SND_FM801=m # CONFIG_SND_FM801_TEA575X is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set CONFIG_SND_INTEL8X0=m # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VX222 is not set # # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set # # Open Sound System # CONFIG_SOUND_PRIME=m CONFIG_SOUND_BT878=m CONFIG_SOUND_CMPCI=m # CONFIG_SOUND_CMPCI_FM is not set # CONFIG_SOUND_CMPCI_MIDI is not set # CONFIG_SOUND_CMPCI_JOYSTICK is not set CONFIG_SOUND_CMPCI_CM8738=y # CONFIG_SOUND_CMPCI_SPDIFINVERSE is not set # CONFIG_SOUND_CMPCI_SPDIFLOOP is not set CONFIG_SOUND_CMPCI_SPEAKERS=2 CONFIG_SOUND_EMU10K1=m # CONFIG_MIDI_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set CONFIG_SOUND_ES1371=m # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set CONFIG_SOUND_ICH=m # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_SOUND_OSS is not set CONFIG_SOUND_TVMIXER=m # CONFIG_SOUND_ALI5455 is not set # CONFIG_SOUND_FORTE is not set # CONFIG_SOUND_RME96XX is not set # CONFIG_SOUND_AD1980 is not set # # USB support # CONFIG_USB=m CONFIG_USB_DEBUG=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # # CONFIG_USB_EHCI_HCD is not set CONFIG_USB_OHCI_HCD=m # CONFIG_USB_UHCI_HCD is not set # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set CONFIG_USB_STORAGE=m CONFIG_USB_STORAGE_DEBUG=y CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_HP8200e=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # # USB Human Interface Devices (HID) # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # # USB Imaging devices # CONFIG_USB_MDC800=m # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_STV680 is not set # CONFIG_USB_W9968CF is not set # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m # CONFIG_USB_SERIAL_KEYSPAN_MPR is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y # CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_PL2303=m # CONFIG_USB_SERIAL_SAFE is not set CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_TEST is not set # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y # CONFIG_JFS_FS is not set CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_DMAPI is not set # CONFIG_XFS_SECURITY is not set # CONFIG_XFS_POSIX_ACL is not set # CONFIG_XFS_DEBUG is not set # CONFIG_XFS_TRACE is not set CONFIG_MINIX_FS=m # CONFIG_ROMFS_FS is not set CONFIG_QUOTA=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m # CONFIG_MSDOS_FS is not set CONFIG_VFAT_FS=m CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVPTS_FS_XATTR is not set CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set CONFIG_NFSD_TCP=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=m # CONFIG_RPCSEC_GSS_KRB5 is not set CONFIG_SMB_FS=m CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp1250" CONFIG_CIFS=m # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set # CONFIG_NEC98_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_EFI_PARTITION is not set # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-2" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set CONFIG_NLS_CODEPAGE_1250=m # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_EARLY_PRINTK is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set CONFIG_DEBUG_SLAB=y CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_HIGHMEM is not set # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_FRAME_POINTER is not set # CONFIG_4KSTACKS is not set CONFIG_KDB=y CONFIG_KDB_MODULES=m CONFIG_KDB_OFF=y CONFIG_KDB_CONTINUE_CATASTROPHIC=0 CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_SECURITY is not set # # Cryptographic options # # CONFIG_CRYPTO is not set # # Library routines # CONFIG_CRC32=y CONFIG_LIBCRC32C=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_STD_RESOURCES=y --ZGiS0Q5IWpPtfppv-- From owner-linux-xfs@oss.sgi.com Sat May 29 12:41:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 May 2004 12:41:03 -0700 (PDT) Received: from sweetums.bluetronic.net (sweetums.bluetronic.net [24.199.150.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4TJf0gi014995 for ; Sat, 29 May 2004 12:41:00 -0700 Received: from localhost (jfbeam@localhost) by sweetums.bluetronic.net (8.11.7/8.11.7) with ESMTP id i4TJZYm13065; Sat, 29 May 2004 15:35:34 -0400 (EDT) Date: Sat, 29 May 2004 15:35:34 -0400 (EDT) From: Ricky Beam To: Steve Lord cc: Linux Kernel Mail List , XFS List Subject: Re: xfs partition refuses to mount In-Reply-To: <40B8D24A.4080703@xfs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3218 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jfbeam@bluetronic.net Precedence: bulk X-list: linux-xfs Content-Length: 928 Lines: 21 On Sat, 29 May 2004, Steve Lord wrote: >You have turned on XFS debug, which is really a developer option. It >looks like you have a corrupt journal though. A non debug kernel may >still refuse to mount it and you would need to run xfs_repair from >a rescue disk in that case. Unless xfs_repair has been changed recently, all it will be able to do it delete (zero) the journal. If it detects metadata in the journal, it'll stop and tell you mount the filesystem to replay the journal. Personally, I think that's sorta stupid... if I could mount the fs, I wouldn't be running xfs_repair. (I've had the journal become spooge on a sparc64 box a few times.) There should be a way to instruct the kernel's rootfs mount to not look at the log. I don't know if one can pass any generic mount options at boot. ("ro"/"rw" and rootfs type, but I don't know of any others.) This would be handy for more than just xfs, btw. --Ricky From owner-linux-xfs@oss.sgi.com Sat May 29 12:45:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 May 2004 12:45:59 -0700 (PDT) Received: from smtp.vzavenue.net (smtp.vzavenue.net [66.171.59.140]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4TJjtgi016013 for ; Sat, 29 May 2004 12:45:56 -0700 Received: from vzavenue.net (8.37.171.66.subscriber.vzavenue.net [66.171.37.8]) by smtp.vzavenue.net (MOS 3.4.3-CR) with ESMTP id AQV66111; Sat, 29 May 2004 15:44:25 -0400 (EDT) Message-ID: <40B8E81F.8050405@vzavenue.net> Date: Sat, 29 May 2004 15:44:31 -0400 From: Vincent van de Camp User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040322 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: linux-kernel@vger.kernel.org, XFS List Subject: Re: xfs partition refuses to mount References: <40B89FE7.5090203@vzavenue.net> <40B8D24A.4080703@xfs.org> In-Reply-To: <40B8D24A.4080703@xfs.org> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=0/50, host=smtp.vzavenue.net X-archive-position: 3219 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vncnt@vzavenue.net Precedence: bulk X-list: linux-xfs Content-Length: 2712 Lines: 68 Thanks for the information. The debug option certainly was not intentional. I have tried fsck.xfs, but that didn't do anything but print a version message. I haven't tried xfs_repair. I didn't know of it's existance. That's definately something to try out next time, though. Thanks, Vincent Steve Lord wrote: > Vincent van de Camp wrote: > >> I run a gentoo system, and after updating python 2.3.3-r1, the emerge >> -DU that was running segfaulted. I had to hard reset the computer and >> since then the main (and only) partition refuses to mount. >> >> The motherboard is an A7N8X Deluxe, with a Western Digital 36GB SATA >> Raptor drive. Kernel version was 2.6.5. The message: >> >> XFS mounting filesystem ide2(33,1) >> Starting XFS recovery on filesystem: ide2(33,1) (dev: ide2(33,1)) >> XFS assertion failed: *(uint *)dp == XFS_TRANS_HEADER_MAGIC, file: >> xfs_log_recover.c, line: 1424 >> kernel BUG at debug.c:55! >> invalid operand: 0000 >> ohci1394 ieee1394 3c59x floppy serial isa-pnp usb-storage hid usb-ohci >> ehci-hcd usbcore >> CPU: 0 >> EIP: 0010:[] Not tainted >> EFLAGS: 00010282 >> eax: 00000061 ebx: 00000001 ecx: 00000000 edx: f773c000 >> esi: f6d79780 edi: 00000034 ebp: 00000008 esp: f6de7b68 >> ds: 0018 es: 0018 ss: 0018 >> Process mount (pid: 2689, stackpage=f6de7000) >> Stack: c04180e0 c0414be0 c03ed901 00000590 c029d43e c0414be0 c03ed901 >> 00000590 >> f7340720 f7c36260 f6d79774 00000008 c029f6e5 f7340720 f6d79780 >> 00000034 >> f6d79780 00000020 f6d7a200 00000001 f7341200 f6de7c24 f73d1070 >> 00000011 >> Call Trace: [] [] [] [] >> [] [] [] [] [] >> [] [] [] [] [] >> [] [] [] [] [] >> [] [] [] [] [] >> [] >> Code: 0f 0b 37 00 6f f1 3e c0 83 c4 10 c3 89 f6 8b 0d e0 95 10 c0 >> >> If there's a separate xfs list, I'll be happy to post it there too. >> >> Thanks, >> Vincent > > > Added the XFS mailing list to the cc list.... > > You have turned on XFS debug, which is really a developer option. It > looks like you have a corrupt journal though. A non debug kernel may > still refuse to mount it and you would need to run xfs_repair from > a rescue disk in that case. > > Steve > - > 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 Sat May 29 13:48:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 May 2004 13:48:13 -0700 (PDT) Received: from sweetums.bluetronic.net (sweetums.bluetronic.net [24.199.150.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4TKm8gi020522 for ; Sat, 29 May 2004 13:48:08 -0700 Received: from localhost (jfbeam@localhost) by sweetums.bluetronic.net (8.11.7/8.11.7) with ESMTP id i4TKgsQ13924; Sat, 29 May 2004 16:42:54 -0400 (EDT) Date: Sat, 29 May 2004 16:42:54 -0400 (EDT) From: Ricky Beam To: Steve Lord cc: Linux Kernel Mail List , XFS List Subject: Re: xfs partition refuses to mount In-Reply-To: <40B8EC02.3050506@xfs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3220 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jfbeam@bluetronic.net Precedence: bulk X-list: linux-xfs Content-Length: 1382 Lines: 32 On Sat, 29 May 2004, Steve Lord wrote: >Yes, xfs_repair will not replay a log, and if it finds dirty metadata in >the log it wants you to replay it via mount. Having xfs_repair able to >replay the log would be handy, but if mount cannot replay it, then >repair will not either. Except xfs_repair can be a lot smarter in the process. I would never suggest putting 3MB worth of log recovery code in the kernel when it's likely to very be used. Such "fogiving" log recovery belongs in userland. >The whole reason for -L was customers who automatically ran xfs_repair >after a crash, and hence threw away anything which was in the log. So >it is more of a stop and think what you are doing option. "Don't do that." *grin* >> There should be a way to instruct the kernel's rootfs mount to not look >> at the log. I don't know if one can pass any generic mount options at >> boot. ("ro"/"rw" and rootfs type, but I don't know of any others.) This >> would be handy for more than just xfs, btw. > >You can mount norecovery,ro - but no guarantees that it will stay up >long. See Documentation/filesystems/xfs.txt for a list of xfs mount >options. I know I can tell the userland mount (/sbin/mount) to not replay the log. But I'm looking for a way to tell the kernel, at boot, to not replay the log. (digs through kernel) Ahh... 'rootflags=...' is what I'm looking for. --Ricky From owner-linux-xfs@oss.sgi.com Sat May 29 13:53:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 May 2004 13:53:40 -0700 (PDT) Received: from sweetums.bluetronic.net (sweetums.bluetronic.net [24.199.150.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4TKrZgi021092 for ; Sat, 29 May 2004 13:53:36 -0700 Received: from localhost (jfbeam@localhost) by sweetums.bluetronic.net (8.11.7/8.11.7) with ESMTP id i4TKmMQ13983; Sat, 29 May 2004 16:48:22 -0400 (EDT) Date: Sat, 29 May 2004 16:48:22 -0400 (EDT) From: Ricky Beam To: Vincent van de Camp cc: Linux Kernel Mail List , XFS List Subject: Re: xfs partition refuses to mount In-Reply-To: <40B8E81F.8050405@vzavenue.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3221 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jfbeam@bluetronic.net Precedence: bulk X-list: linux-xfs Content-Length: 688 Lines: 17 On Sat, 29 May 2004, Vincent van de Camp wrote: >Thanks for the information. The debug option certainly was not intentional. >I have tried fsck.xfs, but that didn't do anything but print a version >message. I haven't tried xfs_repair. I didn't know of it's existance. >That's definately something to try out next time, though. fsck.xfs is a nop. It intentionally doesn't do anything... if you've reached a point where the filesystem *needs* to be checked and repaired, you don't want any part of it to be automated. And most distro's these days will needlessly run fsck everytime it's been shutdown "improperly" (where "improperly" is defined as a file didn't get deleted.) --Ricky From owner-linux-xfs@oss.sgi.com Sat May 29 23:00:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 May 2004 23:00:36 -0700 (PDT) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4U60Xgi009009 for ; Sat, 29 May 2004 23:00:33 -0700 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.10/8.12.2/SuSE Linux 0.6) with ESMTP id i4U60BnX005911 for ; Sat, 29 May 2004 23:00:28 -0700 Message-ID: <40B9786B.4050104@tlinx.org> Date: Sat, 29 May 2004 23:00:11 -0700 From: lawalsh User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Linux-Xfs Subject: random file write failure...anyone else seen this? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 2067 Lines: 58 This has happened on _rare_ occasions (rare likely because I am UPS backed-up and usually only run even series kernels on this particular machine). But the problem is thus. I'll write to a file -- pre-existing file or, I think has happened on new files as well. I write them to disk and think nothing more of them.... Then...a _few_ days pass... (file if often recoverable from backups!)...and system crashes (like UPS not charged...minor details...may be getting near EOL)...whatever. Maybe just a mysterious crash no-apparent details -- but what is screwey is that some files will be filled with binary zeros, or sections of files will be filled with binary zeros. Huh? I know in this last case, the file that croked was my fstab (slightly inconvenient) I'd edited a few _days_ prior. Filename was still there but filled with all zeros. Sometimes I'll find other files...log files and such that also are zeroed out. Is there any circumstance where xfs wouldn't actually write something to disk for a few days? Not just for xfs, but I wish there was a user command to sync all buffers to disk on the system. Sync used to do that but with delayed writes and multiple buffering schemes -- even mounting some fs's "async" so a specific program won't slow down, but something other than "umount" since that requires, sometimes, shutting down the machine. But I know it had been 2-3 days since I wrote to that file before the system crashed. It might have been open for read in the middle of a send crash (was testing circuits to do some wiring). Might that be a reason? Though I'm sure I've had it happen on files like ".profile", or something like that that wouldn't have been getting read but that had been changed hours or days earlier. VERY rare, this happens, and it happens randomly -- other files I wrote to after that file were fine. so I dunno what gives... weird -- but just wanted to know if any one else has seen any such weirdness. I saw this under 2.4 patched kernels as well as the more recent 2.6.5 kernel.... -l From owner-linux-xfs@oss.sgi.com Sun May 30 07:35:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 May 2004 07:35:50 -0700 (PDT) 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 i4UEZkgi013854 for ; Sun, 30 May 2004 07:35:47 -0700 Received: (qmail 9562 invoked from network); 29 May 2004 18:11:44 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay02.roc.ny.frontiernet.net (FrontierMTA 2.3.23) with SMTP for ; 29 May 2004 18:11:44 -0000 Message-ID: <40B8D24A.4080703@xfs.org> Date: Sat, 29 May 2004 13:11:22 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vincent van de Camp CC: linux-kernel@vger.kernel.org, XFS List Subject: Re: xfs partition refuses to mount References: <40B89FE7.5090203@vzavenue.net> In-Reply-To: <40B89FE7.5090203@vzavenue.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3223 X-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: 2080 Lines: 51 Vincent van de Camp wrote: > I run a gentoo system, and after updating python 2.3.3-r1, the emerge > -DU that was running segfaulted. I had to hard reset the computer and > since then the main (and only) partition refuses to mount. > > The motherboard is an A7N8X Deluxe, with a Western Digital 36GB SATA > Raptor drive. Kernel version was 2.6.5. The message: > > XFS mounting filesystem ide2(33,1) > Starting XFS recovery on filesystem: ide2(33,1) (dev: ide2(33,1)) > XFS assertion failed: *(uint *)dp == XFS_TRANS_HEADER_MAGIC, file: > xfs_log_recover.c, line: 1424 > kernel BUG at debug.c:55! > invalid operand: 0000 > ohci1394 ieee1394 3c59x floppy serial isa-pnp usb-storage hid usb-ohci > ehci-hcd usbcore > CPU: 0 > EIP: 0010:[] Not tainted > EFLAGS: 00010282 > eax: 00000061 ebx: 00000001 ecx: 00000000 edx: f773c000 > esi: f6d79780 edi: 00000034 ebp: 00000008 esp: f6de7b68 > ds: 0018 es: 0018 ss: 0018 > Process mount (pid: 2689, stackpage=f6de7000) > Stack: c04180e0 c0414be0 c03ed901 00000590 c029d43e c0414be0 c03ed901 > 00000590 > f7340720 f7c36260 f6d79774 00000008 c029f6e5 f7340720 f6d79780 > 00000034 > f6d79780 00000020 f6d7a200 00000001 f7341200 f6de7c24 f73d1070 > 00000011 > Call Trace: [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] > Code: 0f 0b 37 00 6f f1 3e c0 83 c4 10 c3 89 f6 8b 0d e0 95 10 c0 > > If there's a separate xfs list, I'll be happy to post it there too. > > Thanks, > Vincent Added the XFS mailing list to the cc list.... You have turned on XFS debug, which is really a developer option. It looks like you have a corrupt journal though. A non debug kernel may still refuse to mount it and you would need to run xfs_repair from a rescue disk in that case. Steve From owner-linux-xfs@oss.sgi.com Sun May 30 08:01:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 May 2004 08:02:00 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4UF1wgi014743 for ; Sun, 30 May 2004 08:01:58 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4UF1w4T014739 for linux-xfs@oss.sgi.com; Sun, 30 May 2004 08:01:58 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4UF1tgq014696 for ; Sun, 30 May 2004 08:01:56 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4UEvvpw014605; Sun, 30 May 2004 07:57:57 -0700 Date: Sun, 30 May 2004 07:57:57 -0700 Message-Id: <200405301457.i4UEvvpw014605@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: 3224 X-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: 629 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=178 derry@jungo.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From derry@jungo.com 2004-30-05 07:57 PDT ------- this bug is the same (duplicate) as Bug 214 *** This bug has been marked as a duplicate of 214 *** ------- 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 May 30 08:01:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 May 2004 08:02:01 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4UF1wgi014744 for ; Sun, 30 May 2004 08:01:58 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4UF1weu014740 for linux-xfs@oss.sgi.com; Sun, 30 May 2004 08:01:58 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4UF1tgu014696 for ; Sun, 30 May 2004 08:01:57 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4UEuhMS014577; Sun, 30 May 2004 07:56:43 -0700 Date: Sun, 30 May 2004 07:56:43 -0700 Message-Id: <200405301456.i4UEuhMS014577@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: 3225 X-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: 873 Lines: 29 http://oss.sgi.com/bugzilla/show_bug.cgi?id=178 derry@jungo.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From derry@jungo.com 2004-30-05 07:56 PDT ------- I have the same bug on Linux 2.4.24 with XFS 1.3: When I do a lot of activity on an XFS partition (like 'find /mnt/xfs') it gets stuck (D), and additional processes start getting stuck on DiskIO, that are un- related. Once I kill the 'find' - slowly locks are released. I printed out a backtrace, and found the tasks to be stopped at __down_failed. ------- 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 May 30 08:01:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 May 2004 08:02:03 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4UF1wgi014742 for ; Sun, 30 May 2004 08:01:58 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4UF1wuX014741 for linux-xfs@oss.sgi.com; Sun, 30 May 2004 08:01:58 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4UF1tgm014696 for ; Sun, 30 May 2004 08:01:56 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4UEvwhg014609; Sun, 30 May 2004 07:57:58 -0700 Date: Sun, 30 May 2004 07:57:58 -0700 Message-Id: <200405301457.i4UEvwhg014609@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: 3226 X-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: 538 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=214 derry@jungo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tufan@itu.edu.tr ------- Additional Comments From derry@jungo.com 2004-30-05 07:57 PDT ------- *** Bug 178 has been marked as a duplicate of this bug. *** ------- 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 May 30 09:01:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 May 2004 09:01:59 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4UG1ugi020704 for ; Sun, 30 May 2004 09:01:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4UG1ukW020703 for linux-xfs@oss.sgi.com; Sun, 30 May 2004 09:01:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4UG1tgq020672 for ; Sun, 30 May 2004 09:01:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4UFHmeq016501; Sun, 30 May 2004 08:17:48 -0700 Date: Sun, 30 May 2004 08:17:48 -0700 Message-Id: <200405301517.i4UFHmeq016501@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: 3227 X-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: 341 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=225 ------- Additional Comments From derry@jungo.com 2004-30-05 08:17 PDT ------- I encountered the same problem on 2.4.24 with XFS 1.3. This ia the same bug as Bug 214 ------- 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 May 30 09:01:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 May 2004 09:01:59 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4UG1ugi020701 for ; Sun, 30 May 2004 09:01:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4UG1uxd020700 for linux-xfs@oss.sgi.com; Sun, 30 May 2004 09:01:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i4UG1tgm020672 for ; Sun, 30 May 2004 09:01:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i4UFI47t016519; Sun, 30 May 2004 08:18:04 -0700 Date: Sun, 30 May 2004 08:18:04 -0700 Message-Id: <200405301518.i4UFI47t016519@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: 3228 X-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: 285 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=214 ------- Additional Comments From derry@jungo.com 2004-30-05 08:18 PDT ------- This is the same bug as Bug 225 ------- 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 May 30 18:31:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 May 2004 18:32:01 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4V1Vvgi024795 for ; Sun, 30 May 2004 18:31:57 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i4V1bjlu010451 for ; Sun, 30 May 2004 18:37:45 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i4V1VjGh808474; Mon, 31 May 2004 11:31:46 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i4V1VgJa1118071; Mon, 31 May 2004 11:31:42 +1000 (AEST) Date: Mon, 31 May 2004 11:31:41 +1000 From: Tim Shimmin To: Ricky Beam Cc: Steve Lord , Linux Kernel Mail List , XFS List Subject: Re: xfs partition refuses to mount Message-ID: <20040531113141.A1116544@boing.melbourne.sgi.com> References: <40B8D24A.4080703@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jfbeam@bluetronic.net on Sat, May 29, 2004 at 03:35:34PM -0400 X-archive-position: 3230 X-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@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 345 Lines: 11 Hi Ricky, On Sat, May 29, 2004 at 03:35:34PM -0400, Ricky Beam wrote: > (I've had the journal become spooge on a sparc64 box a few times.) > Until May 20 (just over a week ago) recovery on sparc64 (and big endian 64) did not work. A fix went into xfs_bit.c thanks to Nicolas Boullis. (Our XFS qa tests are routinely run on intel cpus) --Tim From owner-linux-xfs@oss.sgi.com Sun May 30 19:32:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 May 2004 19:32:33 -0700 (PDT) Received: from web90002.mail.scd.yahoo.com (web90002.mail.scd.yahoo.com [66.218.94.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4V2WUgi032758 for ; Sun, 30 May 2004 19:32:31 -0700 Message-ID: <20040531023225.93772.qmail@web90002.mail.scd.yahoo.com> Received: from [158.140.2.102] by web90002.mail.scd.yahoo.com via HTTP; Sun, 30 May 2004 19:32:25 PDT Date: Sun, 30 May 2004 19:32:25 -0700 (PDT) From: Phy Prabab Subject: Ooops w/2.6.7-rc2 & XFS To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3231 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: phyprabab@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1561 Lines: 53 Hello, Ran into this problem today. The machine in question is a dual Xeon 2.4GHz w/a 1.5T 3Ware sata volume carved out vi LVM2 and formated with XFS: nfsd: non-standard errno: -990 Filesystem "dm-1": XFS internal error xfs_btree_check_sblock at line 342 of file fs/xfs/xfs_btree.c. Caller 0xc025c414 [] xfs_btree_check_sblock+0x65/0xed [] xfs_inobt_lookup+0x19f/0x3cf [] xfs_inobt_lookup+0x19f/0x3cf [] xfs_dialloc+0x316/0xb74 [] xfs_vget+0xcf/0xe8 [] iput+0x3c/0x76 [] xlog_grant_log_space+0x260/0x408 [] xfs_ialloc+0x7a/0x4bd [] xfs_dir_ialloc+0x9b/0x323 [] xfs_trans_reserve+0x8b/0x1f9 [] xfs_mkdir+0x2d9/0x77d [] xfs_acl_vhasacl_default+0x3b/0x49 [] linvfs_mknod+0x44c/0x451 [] tcp_transmit_skb+0x40b/0x693 [] __wake_up_common+0x3f/0x5e [] linvfs_mkdir+0x2a/0x2e [] vfs_mkdir+0x9f/0x118 [] nfsd_create+0x443/0x48a [] nfsd3_proc_mkdir+0xd3/0x11b [] nfsd_dispatch+0x15e/0x20e [] svc_process+0x406/0x61d [] nfsd+0x1ed/0x39c [] nfsd+0x0/0x39c [] kernel_thread_helper+0x5/0xb I unmounted and repaired which allowed the unit to run for another couple of hours only to get hosed again with the above trace. Any suggestions? Thank you for your time. Phy __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ From owner-linux-xfs@oss.sgi.com Sun May 30 20:38:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 30 May 2004 20:38:28 -0700 (PDT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4V3cOgi019706 for ; Sun, 30 May 2004 20:38:25 -0700 Received: from taniwha.stupidest.org (adsl-68-120-154-124.dsl.snfc21.pacbell.net [68.120.154.124]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i4V3cMMT017142; Sun, 30 May 2004 23:38:23 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 9689E18DA2; Sun, 30 May 2004 20:38:21 -0700 (PDT) Date: Sun, 30 May 2004 20:38:21 -0700 From: Chris Wedgwood To: Phy Prabab Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Ooops w/2.6.7-rc2 & XFS Message-ID: <20040531033821.GA24009@taniwha.stupidest.org> References: <20040531023225.93772.qmail@web90002.mail.scd.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040531023225.93772.qmail@web90002.mail.scd.yahoo.com> X-archive-position: 3232 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 162 Lines: 9 On Sun, May 30, 2004 at 07:32:25PM -0700, Phy Prabab wrote: > nfsd: non-standard errno: -990 XFS has detected corruption. Umount and run xfs_repair. --cw From owner-linux-xfs@oss.sgi.com Mon May 31 02:06:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 May 2004 02:06:11 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [193.151.36.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4V95vgi032478 for ; Mon, 31 May 2004 02:05:58 -0700 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 7A7BC9415E; Mon, 31 May 2004 10:36:10 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id CB81093F35; Mon, 31 May 2004 10:36:08 +0200 (CEST) Received: from [192.168.1.10] (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.12.10/8.12.10) with ESMTP id i4V8dk3P003162; Mon, 31 May 2004 10:39:46 +0200 Subject: Re: Ooops w/2.6.7-rc2 & XFS From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Chris Wedgwood Cc: Phy Prabab , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20040531033821.GA24009@taniwha.stupidest.org> References: <20040531023225.93772.qmail@web90002.mail.scd.yahoo.com> <20040531033821.GA24009@taniwha.stupidest.org> Content-Type: text/plain Message-Id: <1085992786.2714.18.camel@venus.local.navi.pl> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 31 May 2004 10:39:46 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 3233 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 305 Lines: 15 On Mon, 2004-05-31 at 05:38, Chris Wedgwood wrote: > On Sun, May 30, 2004 at 07:32:25PM -0700, Phy Prabab wrote: > > > nfsd: non-standard errno: -990 > > XFS has detected corruption. Umount and run xfs_repair. > Hi, Read his email to the end. He did it, but the error ocurred again. Regards, Olaf From owner-linux-xfs@oss.sgi.com Mon May 31 03:15:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 May 2004 03:15:33 -0700 (PDT) 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 i4VAFUgi004172 for ; Mon, 31 May 2004 03:15:30 -0700 Received: (qmail 26850 invoked from network); 29 May 2004 20:01:27 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.23) with SMTP for ; 29 May 2004 20:01:27 -0000 Message-ID: <40B8EC02.3050506@xfs.org> Date: Sat, 29 May 2004 15:01:06 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ricky Beam CC: Linux Kernel Mail List , XFS List Subject: Re: xfs partition refuses to mount References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3234 X-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: 1859 Lines: 42 Ricky Beam wrote: > On Sat, 29 May 2004, Steve Lord wrote: > >>You have turned on XFS debug, which is really a developer option. It >>looks like you have a corrupt journal though. A non debug kernel may >>still refuse to mount it and you would need to run xfs_repair from >>a rescue disk in that case. > > > Unless xfs_repair has been changed recently, all it will be able to do it > delete (zero) the journal. If it detects metadata in the journal, it'll > stop and tell you mount the filesystem to replay the journal. Personally, > I think that's sorta stupid... if I could mount the fs, I wouldn't be > running xfs_repair. (I've had the journal become spooge on a sparc64 > box a few times.) Yes, xfs_repair will not replay a log, and if it finds dirty metadata in the log it wants you to replay it via mount. Having xfs_repair able to replay the log would be handy, but if mount cannot replay it, then repair will not either. xfs_repair -L bypasses this check and resets the log. Following that it does a complete consistancy check and fixup of metadata - it does a good job in most cases. Note that it deletes lost+found, and if you had files in there, they would be disconnected and get put back in lost+found again. The whole reason for -L was customers who automatically ran xfs_repair after a crash, and hence threw away anything which was in the log. So it is more of a stop and think what you are doing option. > > There should be a way to instruct the kernel's rootfs mount to not look > at the log. I don't know if one can pass any generic mount options at > boot. ("ro"/"rw" and rootfs type, but I don't know of any others.) This > would be handy for more than just xfs, btw. > You can mount norecovery,ro - but no guarantees that it will stay up long. See Documentation/filesystems/xfs.txt for a list of xfs mount options. Steve From owner-linux-xfs@oss.sgi.com Mon May 31 04:49:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 May 2004 04:49:24 -0700 (PDT) Received: from mail.slb.com (eurmta01.london.eur.slb.com [134.32.26.55]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4VBnGgi010434 for ; Mon, 31 May 2004 04:49:19 -0700 Received: from conversion-daemon.eurmta01.london.eur.slb.com by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) id <0HYK00401TOIV3@eurmta01.london.eur.slb.com> for linux-xfs@oss.sgi.com; Mon, 31 May 2004 11:44:31 +0000 (GMT) Received: from stavanger.westerngeco.slb.com (wgmail9.stavanger.eur.slb.com [134.32.72.36]) by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPS id <0HYK0039UTVVAU@eurmta01.london.eur.slb.com>; Mon, 31 May 2004 11:43:08 +0000 (GMT) Received: from GSTJ2W (localhost [127.0.0.1]) by stavanger.westerngeco.slb.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id i4VBbAD28980; Mon, 31 May 2004 13:37:10 +0200 (MEST) Date: Mon, 31 May 2004 13:43:04 +0200 From: marat Subject: Re: XFS for postgres databases? In-reply-to: To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Message-id: <200405311343.04021.marat@stavanger.westerngeco.slb.com> Organization: westerngeco MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT User-Agent: KMail/1.4.1 References: X-archive-position: 3235 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marat@stavanger.westerngeco.slb.com Precedence: bulk X-list: linux-xfs Content-Length: 2600 Lines: 80 Hi Eric , Please, see my answer below : > > I have got some strange problem on Linux RH9 system, kernel 2.4.25 > > a kernel.org kernel? Yes > > > The XFS filesystem crashed with message : > > > > Filesystem "sd(8,33)": XFS internal error xfs_btree_check_lblock at > > line 222 of file xfs_btree.c. Caller 0xf89b695f f65ada4c f89b7ffa > > f8a14e7a 00000001 f6e78400 f8a14e6e 000000de f89b695f > > > ea6a6dcc e68ffe40 db68dd84 db68dd84 f89b8da5 d3a0d7a8 e3a8d1a0 5f0fbac6 > > 0a05bb82 d87da000 db68dd84 00000000 00000000 f89b695f db68dd84 d87da000 > > Call Trace: [] [] [] [] > > [] > > please run this through ksyumoops to get full backtrace information. > Here it is: Warning (Oops_read): Code line not seen, dumping what data is available Trace; f89b82a5 <[xfs]xfs_btree_check_sblock+85/100> Trace; f8a14eab <[xfs].rodata.end+2e0/140b5> Trace; f8a14e6e <[xfs].rodata.end+2a3/140b5> Trace; f899dcfc <[xfs]xfs_alloc_lookup+12c/3c0> Trace; f899dcfc <[xfs]xfs_alloc_lookup+12c/3c0> Trace; f899b114 <[xfs]xfs_free_ag_extent+254/770> Trace; f899c470 <[xfs]xfs_free_extent+f0/100> Trace; f8a09ff8 <[xfs]kmem_zone_zalloc+108/130> Trace; f89f0d58 <[xfs]xfs_trans_get_efd+38/50> Trace; f89ae8c8 <[xfs]xfs_bmap_finish+138/1d0> Trace; f89d7da3 <[xfs]xfs_itruncate_finish+213/440> Trace; f89f6623 <[xfs]xfs_inactive_free_eofblocks+293/2e0> Trace; f89f6d4e <[xfs]xfs_release+9e/f0> Trace; f89fc895 <[xfs]xfs_refcache_purge_some+e5/110> Trace; f89f3c88 <[xfs]xfs_syncsub+258/330> Trace; f89f2fc9 <[xfs]xfs_sync+29/30> Trace; f8a05883 <[xfs]vfs_sync+43/50> Trace; f8a0496a <[xfs]syncd+ca/f0> Trace; c010752e Trace; f8a048a0 <[xfs]syncd+0/f0> 2 warnings issued. Results may not be reliable. > > > > I had to reboot system and run xfs_repair. it looks like xfs_repair does > > not fix all problems, I have tried to run it several times and every time > > had the same output. > > this may be normal, the first thing repair does is unlink lost+found, and > then rediscovers everything in it. rename lost+found and try again, > things should be fine. if you still see unrepaired errors please > post the complete output of repair (or send directly to me if it's > overly long) I had to recreate file system and put it back to production. So, I can't try it. > > > I attached output from xfs_repair command ( I had to edit file to make it > > readable ). > > hm, what was unreadable? I mean, 313Mb of data is not quit easy to read ( > 6 millions line ) > > -Eric Thanks, -- Marat Mukhitov From owner-linux-xfs@oss.sgi.com Mon May 31 10:51:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 May 2004 10:52:01 -0700 (PDT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4VHpwgi025317 for ; Mon, 31 May 2004 10:51:59 -0700 Received: from taniwha.stupidest.org (adsl-68-120-154-124.dsl.snfc21.pacbell.net [68.120.154.124]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i4VHppbj099694; Mon, 31 May 2004 13:51:52 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 818CA14981; Mon, 31 May 2004 10:51:51 -0700 (PDT) Date: Mon, 31 May 2004 10:51:51 -0700 From: Chris Wedgwood To: Phy Prabab Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Ooops w/2.6.7-rc2 & XFS Message-ID: <20040531175151.GA27164@taniwha.stupidest.org> References: <20040531023225.93772.qmail@web90002.mail.scd.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040531023225.93772.qmail@web90002.mail.scd.yahoo.com> X-archive-position: 3237 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 418 Lines: 18 On Sun, May 30, 2004 at 07:32:25PM -0700, Phy Prabab wrote: > I unmounted and repaired which allowed the unit to run > for another couple of hours only to get hosed again > with the above trace. repaired == xfs_repair? what did that say? > Any suggestions? this machine has ECC/whatever and memtest86 passes cleanly right? also, when the error occured again was it exactly the same both times? thanks, --cw From owner-linux-xfs@oss.sgi.com Mon May 31 13:00:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 May 2004 13:00:22 -0700 (PDT) Received: from web90003.mail.scd.yahoo.com (web90003.mail.scd.yahoo.com [66.218.94.61]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i4VK0Fgi032385 for ; Mon, 31 May 2004 13:00:15 -0700 Message-ID: <20040531200008.65043.qmail@web90003.mail.scd.yahoo.com> Received: from [158.140.2.102] by web90003.mail.scd.yahoo.com via HTTP; Mon, 31 May 2004 13:00:08 PDT Date: Mon, 31 May 2004 13:00:08 -0700 (PDT) From: Phy Prabab Subject: Re: Ooops w/2.6.7-rc2 & XFS To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20040531175151.GA27164@taniwha.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3238 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: phyprabab@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 726 Lines: 37 > repaired == xfs_repair? what did that say? ran xfs_repair, no errors reported. > this machine has ECC/whatever and memtest86 passes > cleanly right? ECC 1.5G. I have already swapped out memeory just to be on the safe side. I ran memtest with no errors > also, when the error occured again was it exactly > the same both times? It happened 4 times and every single time, it had the identical trace. I brought on line a new volume with new drives to see if I can reproduce this (same machine and same kernel). Any other suggetions/questions? Thank you for the assistance. Phy __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ From owner-linux-xfs@oss.sgi.com Mon May 31 17:56:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 31 May 2004 17:56:53 -0700 (PDT) Received: from zero.aec.at (Jarn_Leffer@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i510ulgi011219 for ; Mon, 31 May 2004 17:56:48 -0700 Received: from averell.firstfloor.org.muc.de (Dumbo_Omohundro@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id i510ugn18380; Tue, 1 Jun 2004 02:56:44 +0200 To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: Shared Devices with XFS References: <40B5D5CB.7020702@opticalart.de> <40B5D903.4050601@xfs.org> <40B5E594.1000605@opticalart.de> <1085774867.518.11.camel@david.internal.norcrossgroup.com> <40B7A35F.9010409@xfs.org> From: Andi Kleen Date: Tue, 01 Jun 2004 02:56:47 +0200 In-Reply-To: <40B7A35F.9010409@xfs.org> (Steve Lord's message of "Fri, 28 May 2004 15:38:55 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 3239 X-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: 477 Lines: 13 Steve Lord writes: > > There are also other commercial offerings available on Linux, which > unlike CXFS do not require an SGI metdata server and will run on > fairly generic hardware. Still fairly spendy though. There's also GFS/XFS, which is basically NFS with direct access to an XFS block device for data. It's included in the NEC IA64 linux kernel, but not very generic (e.g. bypasses the normal linux block device layers and only works on SCSI) -Andi