From owner-linux-xfs Mon Nov 1 01:06:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Nov 2004 01:06:37 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [81.187.226.98]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA196XH3000733 for ; Mon, 1 Nov 2004 01:06:34 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.42 #1 (Red Hat Linux)) id 1COY8h-0006iU-Kz; Mon, 01 Nov 2004 09:06:11 +0000 Date: Mon, 1 Nov 2004 09:06:11 +0000 From: Christoph Hellwig To: Marek Szyprowski Cc: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: XFS on-disk structures - docs Message-ID: <20041101090611.GA25807@infradead.org> References: <20041101094412.D5462300@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 4366 X-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 Sun, Oct 31, 2004 at 11:54:50PM +0100, Marek Szyprowski wrote: > I know that XFS is complex - that's why I want to write only simple > read-only filesystem driver (that also all I need). Also filesystem driver > in Linux are completely diffrent than in AmigaOS, so it is easier to write > it from scratch, than port. Grub has a simple read-only XFS driver. OTOH the grub filesystem interface is really horrible, so be warned.. From owner-linux-xfs Mon Nov 1 11:36:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Nov 2004 11:36:08 -0800 (PST) Received: from mx1.bluetie.com ([206.65.164.154]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA1Ja5hX005837 for ; Mon, 1 Nov 2004 11:36:05 -0800 Received: from mstore2.app.nyc1.bluetie.com (mstore2.app.nyc1.bluetie.com [10.102.1.17]) by mx1.bluetie.com (Postfix) with ESMTP id 48EBCAC3DA; Mon, 1 Nov 2004 14:35:42 -0500 (EST) Message-ID: <20041101143543.5835@web1.app.nyc1.bluetie.com> X-Mailer: BlueTie Mailer Center Cc: linux-xfs@oss.sgi.com To: nathans@sgi.com From: "Thomas Ledbetter" Subject: Re: xfs out of diskspace issue Content-transfer-encoding: 7bit Content-Type: text/plain Date: Mon, 1 Nov 2004 14:35:42 -0500 (EST) X-archive-position: 4367 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tledbett@bluetie.com Precedence: bulk X-list: linux-xfs Thanks for the reply Nathan - I am really confused here.. I have a 137G production xfs filesystem, of which 79% of the blocks are used, and 11% of the inodes are used. The filesystem used 4K blocks. We seem to be on the verge of some hidden capacity limit as we keep getting 'no space left on device' even though there is 21% (30G) of free space. What could this possibly be? Its a RedHat 9 system with the kernel upgraded to version 2.4.25, so its not cutting edge 2.4.. but its not all that old either.. We are using xfs extended attributes heavily. Removing files and directories allows new ones to be created again but we cant seem to get beyond the 79% mark. We are in a situation where we are continually deleting files to prevent reaching the hidden capacity limit. Up until this point, there have been no problems with this filesystem. Any ideas? ____________________________________ Thomas Ledbetter Systems Administrator / Architect 585-586-2000 x1014 tledbett@bluetie.com -----Original Message----- From: "Nathan Scott" [nathans@sgi.com] Date: 10/29/2004 03:43 On Thu, Oct 21, 2004 at 12:30:37PM -0400, Thomas Ledbetter wrote: > > Is there 'other' portions of the filesystem which could take up 33% of it? No. > In this case there was 2.2G being reported as free by df, yet new files could > not be created. Deleting existing files did allow new ones to be created. > > Does anyone have any ideas why this would occur or where I can turn to for > more information? Unmount and run repair - does that show any disconnected inodes? (if so, they'd be put in lost+found - these may account for your missing space, if any exist..). cheers. -- Nathan This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake then delete this e-mail from your system. From owner-linux-xfs Mon Nov 1 18:12:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Nov 2004 18:12:49 -0800 (PST) Received: from mail42.messagelabs.com (mail42.messagelabs.com [38.118.4.35]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iA22CjBj004089 for ; Mon, 1 Nov 2004 18:12:46 -0800 X-VirusChecked: Checked X-Env-Sender: bvenegas@securities.com X-Msg-Ref: server-6.tower-42.messagelabs.com!1099361543!13214307!1 X-StarScan-Version: 5.4.2; banners=securities.com,-,- X-Originating-IP: [63.87.240.232] Received: (qmail 21241 invoked from network); 2 Nov 2004 02:12:23 -0000 Received: from unknown (HELO mail02.securities.com) (63.87.240.232) by server-6.tower-42.messagelabs.com with SMTP; 2 Nov 2004 02:12:23 -0000 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-DELIVERY) with ESMTP id iA22CC7M021463 for ; Mon, 1 Nov 2004 21:12:22 -0500 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-FRONT-END) with ESMTP id iA22BvUe021415 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 1 Nov 2004 21:12:07 -0500 Received: from localhost (venevene@localhost) by mail02.securities.com (8.12.5/8.12.5/Submit) with ESMTP id iA22BkG9021350; Mon, 1 Nov 2004 21:11:47 -0500 X-Authentication-Warning: mail02.securities.com: venevene owned process doing -bs Date: Mon, 1 Nov 2004 21:11:46 -0500 (EST) From: "Benito A. Venegas" X-X-Sender: venevene@mail02.securities.com To: Net Llama! cc: linux-xfs@oss.sgi.com Subject: Re: XFS/Postgres/Fragmentation In-Reply-To: <4185A8E1.6050009@linux-sxs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4368 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bvenegas@securities.com Precedence: bulk X-list: linux-xfs Thanks!!! What XFS version are you using with your kernels 2.4.X and 2.6.X? Is it possible you send me your xfs_info for the file system is allocating the postgres data? Cheers, -- Vene.- On Sun, 31 Oct 2004, Net Llama! wrote: > On 10/31/2004 06:44 PM, Benito A. Venegas wrote: > > Hi people, > > > > Thanks to everybody for your great effort day by day to maintain this > > great project... > > > > Now..my problem.. :( > > > > I'm experiencing some high fragmentations in one of my boxes, running > > postgresql database. > > > > Last Friday/Saturday I ran some extra maintenance to my postgres DB > > (reindexing, analyze, vacuum full, etc.) due suddenly we started to have > > very slow performance in our queries. This maintenance helped, but later > > I ran xfs_db -r -c "frag -f" and the > > fragmentation was still high (close to 90%) and xfs_fsr reduced it to 7% > > after to complete 10 loops for all my file systems in /etc/mtab. > > > > Today in the evening I took some statistics and fragmentations level was > > 64% !! :( > > > > #xfs_db -r /dev/sdc1 -c "frag -f" > > actual 2531, ideal 906, fragmentation factor 64.20% > > > > > > Basic info: > > > > -kernel 2.4.19 + xfs 1.2 + some extra patches > > -postgres 7.2.3-1PGDG > > Wow, those are some truly ancient versions of both the kernel and > postgresql. > > > > > #xfs_info /proj > > > > meta-data=/proj isize=256 agcount=34, agsize=262144 > > blks > > data = bsize=4096 blocks=8885945, imaxpct=25 > > = sunit=0 swidth=0 blks, unwritten=0 > > naming =version 2 bsize=4096 > > log =internal bsize=4096 blocks=1200 version=1 > > = sunit=0 blks > > realtime =none extsz=65536 blocks=0, rtextents=0 > > > > -HW level > > PE2650 PIII 1400 Mhz Dual CPU, 1Gb ram, > > /proj is in RAID1 using Perc3/Di (Yes, I know this is a bad raid card, > > but IMHO this is not causing the fragmentations) > > Only postgres and a small mysql DB are using this partition. > > > > > > Qs: > > -Can I ran xfs_fsr daily instead weekly? > > > > -DO you think if I update my kernel and recreate my partition, using > > version 2 (or 3) I can mitigate my fragmentation level? (Risky task) > > > > -Is really postgres the frag killer here (if any one of you is running > > postgres and only the data is one paritition..) > > I'm running postgresql 7.3.x and 7.4.x on several boxes with XFS using > 2.4.x and 2.6.x kernels and i'm not seeing fragmentation at anything > even remotely close to what you're reporting. The worst of my boxes is > under 10%, and most are under 5%. > > Internet Securities, Inc. (trading as ISI Emerging Markets) is a Euromoney Institutional Investor company. ________________________________________________________________________ This communication contains information which is confidential. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error please notify us by e-mail or bytelephone (as above) and then delete the e-mail and all attachments and any copies thereof. ________________________________________________________________________ From owner-linux-xfs Mon Nov 1 19:53:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 01 Nov 2004 19:53:47 -0800 (PST) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA23rgE4024153 for ; Mon, 1 Nov 2004 19:53:42 -0800 Received: from erbenson.alaska.net (66-230-89-160-dial-as3.nwc.acsalaska.net [66.230.89.160]) by iris.acsalaska.net (8.13.1/8.13.1) with ESMTP id iA23rN5B053024 for ; Mon, 1 Nov 2004 18:53:24 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 1E36039B0 for ; Mon, 1 Nov 2004 18:53:23 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id B7C4740FF35; Mon, 1 Nov 2004 18:53:22 -0900 (AKST) Date: Mon, 1 Nov 2004 18:53:22 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: XFS on-disk structures - docs Message-ID: <20041102035322.GB26294@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20041101094412.D5462300@wobbly.melbourne.sgi.com> <20041101090611.GA25807@infradead.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i9LlY+UWpKt15+FH" Content-Disposition: inline In-Reply-To: <20041101090611.GA25807@infradead.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.44; SA 2.64; spamdefang 1.110 X-archive-position: 4369 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 01, 2004 at 09:06:11AM +0000, Christoph Hellwig wrote: > On Sun, Oct 31, 2004 at 11:54:50PM +0100, Marek Szyprowski wrote: > > I know that XFS is complex - that's why I want to write only simple > > read-only filesystem driver (that also all I need). Also filesystem dri= ver > > in Linux are completely diffrent than in AmigaOS, so it is easier to wr= ite > > it from scratch, than port. >=20 > Grub has a simple read-only XFS driver. OTOH the grub filesystem interface > is really horrible, so be warned.. and the grub driver has problems with fragmented files. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --i9LlY+UWpKt15+FH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkGHBLIACgkQJKx7GixEevyqCQCeJAVqjayAeHfG90ogAdUFlvVl 78wAn08xrsqMzIiBmnrUnc5q/BAcCg1w =sPaQ -----END PGP SIGNATURE----- --i9LlY+UWpKt15+FH-- From owner-linux-xfs Tue Nov 2 00:37:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Nov 2004 00:37:46 -0800 (PST) Received: from office.cambrium.nl (217-19-18-130.dsl.cambrium.nl [217.19.18.130]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iA28bgOt009842 for ; Tue, 2 Nov 2004 00:37:43 -0800 Received: (qmail 4219 invoked by uid 526); 2 Nov 2004 08:37:25 -0000 Subject: Re: xfs out of diskspace issue From: Johan Mulder To: Thomas Ledbetter Cc: linux-xfs@oss.sgi.com In-Reply-To: <20041101143543.5835@web1.app.nyc1.bluetie.com> References: <20041101143543.5835@web1.app.nyc1.bluetie.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 02 Nov 2004 09:37:25 +0100 Message-Id: <1099384645.19081.21.camel@mother.office.cambrium.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-archive-position: 4370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: johan@office.cambrium.nl Precedence: bulk X-list: linux-xfs On Mon, 2004-11-01 at 14:35 -0500, Thomas Ledbetter wrote: > Thanks for the reply Nathan - I am really confused here.. > > I have a 137G production xfs filesystem, of which 79% of the blocks are used, > and 11% of the inodes are used. The filesystem used 4K blocks. > > We seem to be on the verge of some hidden capacity limit as we keep getting > 'no space left on device' even though there is 21% (30G) of free space. > > What could this possibly be? Its a RedHat 9 system with the kernel upgraded to > version 2.4.25, so its not cutting edge 2.4.. but its not all that old either.. > > We are using xfs extended attributes heavily. > > Removing files and directories allows new ones to be created again but we cant > seem to get beyond the 79% mark. We are in a situation where we are continually > deleting files to prevent reaching the hidden capacity limit. > > Up until this point, there have been no problems with this filesystem. > > Any ideas? If files get deleted, and processes still have them opened, they will not actually get removed until the process has closed the file (or the process dies). Maybe this is the case with your system? (you can check with fuser or lsof. I recommend lsof) From owner-linux-xfs Tue Nov 2 08:19:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Nov 2004 08:19:40 -0800 (PST) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA2GJZtF007735 for ; Tue, 2 Nov 2004 08:19:36 -0800 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.1/8.13.1/Debian-15) with ESMTP id iA2FomIX009146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Nov 2004 10:50:48 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.1/8.13.1/Submit) with ESMTP id iA2Fohpq009143; Tue, 2 Nov 2004 10:50:48 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Tue, 2 Nov 2004 10:50:43 -0500 (EST) From: Net Llama! To: "Benito A. Venegas" cc: linux-xfs@oss.sgi.com Subject: Re: XFS/Postgres/Fragmentation In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.60.818 (localhost [127.0.0.1]); Tue, 02 Nov 2004 10:50:48 -0500 X-archive-position: 4371 X-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 2.6.7 meta-data=/ isize=256 agcount=16, agsize=1086270 blks = sectsz=512 data = bsize=4096 blocks=17380320, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=8486, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 On Mon, 1 Nov 2004, Benito A. Venegas wrote: > Thanks!!! > > What XFS version are you using with your kernels > 2.4.X and 2.6.X? > > Is it possible you send me your xfs_info for the file system > is allocating the postgres data? > > Cheers, > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Tue Nov 2 08:23:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Nov 2004 08:23:40 -0800 (PST) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA2GNbw2008137 for ; Tue, 2 Nov 2004 08:23:38 -0800 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.1/8.13.1/Debian-15) with ESMTP id iA2FsxM1009186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Nov 2004 10:54:59 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.1/8.13.1/Submit) with ESMTP id iA2Fsx4k009183; Tue, 2 Nov 2004 10:54:59 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Tue, 2 Nov 2004 10:54:59 -0500 (EST) From: Net Llama! To: "Benito A. Venegas" cc: linux-xfs@oss.sgi.com Subject: Re: XFS/Postgres/Fragmentation In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.60.818 (localhost [127.0.0.1]); Tue, 02 Nov 2004 10:55:00 -0500 X-archive-position: 4372 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs On Sun, 31 Oct 2004, Benito A. Venegas wrote: > Hi people, > > Thanks to everybody for your great effort day by day to maintain this > great project... > > Now..my problem.. :( > > I'm experiencing some high fragmentations in one of my boxes, running > postgresql database. > > Last Friday/Saturday I ran some extra maintenance to my postgres DB > (reindexing, analyze, vacuum full, etc.) due suddenly we started to have > very slow performance in our queries. This maintenance helped, but later > I ran xfs_db -r -c "frag -f" and the > fragmentation was still high (close to 90%) and xfs_fsr reduced it to 7% > after to complete 10 loops for all my file systems in /etc/mtab. > > Today in the evening I took some statistics and fragmentations level was > 64% !! :( > > #xfs_db -r /dev/sdc1 -c "frag -f" > actual 2531, ideal 906, fragmentation factor 64.20% > > > Basic info: > > -kernel 2.4.19 + xfs 1.2 + some extra patches > -postgres 7.2.3-1PGDG > > #xfs_info /proj > > meta-data=/proj isize=256 agcount=34, agsize=262144 > blks > data = bsize=4096 blocks=8885945, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=1200 version=1 > = sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > -HW level > PE2650 PIII 1400 Mhz Dual CPU, 1Gb ram, > /proj is in RAID1 using Perc3/Di (Yes, I know this is a bad raid card, > but IMHO this is not causing the fragmentations) > Only postgres and a small mysql DB are using this partition. I provided my xfs_info and uname in a separate email. However, here's the xfs_db output: xfs_db -r /dev/sda3 -c "frag -f" actual 249616, ideal 247369, fragmentation factor 0.90% as you can see, i've got virtully no fragmentation at all. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Tue Nov 2 14:29:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Nov 2004 14:29:23 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA2MTJRu031246 for ; Tue, 2 Nov 2004 14:29:20 -0800 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 iA2NiO8x017811 for ; Tue, 2 Nov 2004 15:44:25 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA18808; Wed, 3 Nov 2004 09:27:38 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iA2MRZln4953589; Wed, 3 Nov 2004 09:27:36 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id iA2MRWg65622367; Wed, 3 Nov 2004 09:27:32 +1100 (EST) Date: Wed, 3 Nov 2004 09:27:32 +1100 From: Nathan Scott To: Thomas Ledbetter Cc: linux-xfs@oss.sgi.com Subject: Re: xfs out of diskspace issue Message-ID: <20041103092732.A5524750@wobbly.melbourne.sgi.com> References: <20041101143543.5835@web1.app.nyc1.bluetie.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20041101143543.5835@web1.app.nyc1.bluetie.com>; from tledbett@bluetie.com on Mon, Nov 01, 2004 at 02:35:42PM -0500 X-archive-position: 4375 X-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: 1546 Lines: 47 Hi there, On Mon, Nov 01, 2004 at 02:35:42PM -0500, Thomas Ledbetter wrote: > > Thanks for the reply Nathan - I am really confused here.. > > I have a 137G production xfs filesystem, of which 79% of the blocks are used, > and 11% of the inodes are used. The filesystem used 4K blocks. > > We seem to be on the verge of some hidden capacity limit as we keep getting There aren't any hidden capacity limits - either the space is in use by something (like open, unlinked files as someone suggsted), or some free space accounting has gone awry inside XFS. > 'no space left on device' even though there is 21% (30G) of free space. > > What could this possibly be? Its a RedHat 9 system with the kernel upgraded to > version 2.4.25, so its not cutting edge 2.4.. but its not all that old either.. Did you try the unmount and xfs_repair I suggested earlier? What did xfs_repair have to report? > We are using xfs extended attributes heavily. Out of curiousity, what would the average attribute name and value lengths be? And what does your xfs_info report look like for this filesystem? > From: "Nathan Scott" [nathans@sgi.com] > Date: 10/29/2004 03:43 > > On Thu, Oct 21, 2004 at 12:30:37PM -0400, Thomas Ledbetter wrote: > > > > Does anyone have any ideas why this would occur or where I can turn to for > > more information? > > Unmount and run repair - does that show any disconnected inodes? > (if so, they'd be put in lost+found - these may account for your > missing space, if any exist..). > cheers. -- Nathan From owner-linux-xfs Tue Nov 2 16:18:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 02 Nov 2004 16:18:04 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iA30HxxN002072 for ; Tue, 2 Nov 2004 16:18:00 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA21115; Wed, 3 Nov 2004 11:17:32 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iA30HTln5624926; Wed, 3 Nov 2004 11:17:30 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id iA30HRTc5626641; Wed, 3 Nov 2004 11:17:27 +1100 (EST) Date: Wed, 3 Nov 2004 11:17:26 +1100 From: Nathan Scott To: Martin MOKREJ? Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Filesystem performance on 2.4.28-pre3 on hardware RAID5. Message-ID: <20041103111726.B5524750@wobbly.melbourne.sgi.com> References: <20041029111049.GA554@ribosome.natur.cuni.cz> <20041101102426.G5462300@wobbly.melbourne.sgi.com> <418574FB.2020907@ribosome.natur.cuni.cz> <20041031223214.GB690@frodo> <41878432.5060904@ribosome.natur.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <41878432.5060904@ribosome.natur.cuni.cz>; from mmokrejs@ribosome.natur.cuni.cz on Tue, Nov 02, 2004 at 01:57:22PM +0100 X-archive-position: 4376 X-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: 1426 Lines: 34 On Tue, Nov 02, 2004 at 01:57:22PM +0100, Martin MOKREJ? wrote: > I retested with blocksize 1024, instead of 512 (default) which causes problems: 4K is the default blocksize, not 1024 or 512 bytes. From going through all your notes, the default mkfs parameters are working fine, and changing to a 512 byte blocksize (-blog=9 / -bsize=512) is where the VM starts to see problems. I don't have a device the size of yours handy on my test box, nor do I have as much memory as you -- but I ran similar bonnie++ commands with -bsize=512 filesystems on a machine with very little memory, and a filesystem and file size exponentially larger than available memory, and it ran to completion without problems. I did see vastly more buffer_heads being created than with the default mkfs parameters (as we'd expect with that blocksize) but it didn't cause me any VM problems. > How can I free the buffer_head without rebooting? I'm trying to help myself with AFAICT, there is no way to do this without a reboot. They are meant to be reclaimed (and were reclaimed on my test box) as needed, but they don't seem to be for you. This looks alot like a VM balancing sort of problem to me (that 6G of memory you have is a bit unusual - probably not a widely tested configuration on i386... maybe try booting with mem=1G and see if that changes anything?), so far it doesn't seem like XFS is at fault here at least. cheers. -- Nathan From owner-linux-xfs Wed Nov 3 02:02:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Nov 2004 02:02:55 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA3A2nF9007295 for ; Wed, 3 Nov 2004 02:02:49 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iA3A2nHN007294 for linux-xfs@oss.sgi.com; Wed, 3 Nov 2004 02:02:49 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA3A2lSu007279 for ; Wed, 3 Nov 2004 02:02:47 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iA39Q9Xg006130; Wed, 3 Nov 2004 01:26:09 -0800 Date: Wed, 3 Nov 2004 01:26:09 -0800 Message-Id: <200411030926.iA39Q9Xg006130@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 381] New: Segmentation fault while loading xfs module X-Bugzilla-Reason: AssignedTo X-archive-position: 4378 X-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: 2307 Lines: 59 http://oss.sgi.com/bugzilla/show_bug.cgi?id=381 Summary: Segmentation fault while loading xfs module Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: psacha@blue-cable.net Kernel: Linux 2.6.9, Machine: Compaq DL380 with 2 Intel Pentium Processors While trying to load the xfs module with "modprobe xfs" modprobe produces a segmentation fault and the kernel shows the message: kernel BUG at kernel/module.c:257! invalid operand: 0000 [#1] SMP Modules linked in: dm_mod usbkbd usbcore floppy cpqarray cciss siimage aec62xx a lim15x3 hpt34x hpt366 ide_disk cmd64x piix rz1000 slc90e66 cs5530 pdc202xx_old p dc202xx_new amd74xx sis5513 via82cxxx serverworks ide_core aic7xxx sym53c8xx scs i_transport_spi scsi_mod rtc CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010202 (2.6.9-fai) EIP is at percpu_modalloc+0xe/0xf8 eax: 0000004b ebx: c1635960 ecx: e09b248c edx: 0000000f esi: 00000258 edi: e09b3970 ebp: e09b3a48 esp: de971f04 ds: 007b es: 007b ss: 0068 Process modprobe (pid: 1053, threadinfo=de970000 task=def06c50) Stack: c1635960 00000258 e09b3970 e09b3a48 c012e9de e0947000 c012ea0d 00000160 00000020 b7e22000 080509b8 c03299e4 de970000 00000000 e09b1469 00000044 00000060 df10a4c0 00000000 00000000 e09b2480 0000000f 00000000 00000000 Call Trace: [] load_module+0x3d6/0x914 [] load_module+0x405/0x914 [] sys_init_module+0x65/0x200 [] syscall_call+0x7/0xb Code: d5 29 54 98 04 a1 90 36 3e c0 89 14 98 b8 01 00 00 00 83 c4 0c 5b 5e 5f 5d 59 c3 89 f6 83 ec 08 55 57 56 53 83 7c 24 20 10 76 0a <0f> 0b 01 01 a2 fa 2b c0 89 f6 bd a0 c0 3c c0 31 f6 a1 88 36 3e The same problem with Kernel 2.6.8 was described on the linux kernel mailing list. But i could not find this bug in the bugzilla, so here it is. After the segmenation fault commands like modprobe and lsmod are hanging and they can not be terminated even with a kill -KILL. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Nov 3 14:57:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Nov 2004 14:59:08 -0800 (PST) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA3MvaPS018368 for ; Wed, 3 Nov 2004 14:57:37 -0800 Received: from [10.0.0.150] (thuiscomputer.xs4all.nl [213.84.217.59]) by smtp-vbr11.xs4all.nl (8.12.11/8.12.11) with ESMTP id iA3MvDlq092810 for ; Wed, 3 Nov 2004 23:57:18 +0100 (CET) (envelope-from jwillem@stads.net) Date: Wed, 03 Nov 2004 23:57:18 +0100 From: "mail.stads.net" To: "linux-xfs@oss.sgi.com" Subject: Fedora2 XFS crash when drive full? Message-Id: <20041103234026.AFFE.JWILLEM@stads.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.02 X-Virus-Scanned: by XS4ALL Virus Scanner X-archive-position: 4379 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jwillem@stads.net Precedence: bulk X-list: linux-xfs Content-Length: 798 Lines: 23 Hi there. I have a system with 4TB disk. One LVM "partion", this is formatted with XFS This is our first system where we cross the 2TB limit of an external raidsystem normaly we would have the raidsystem export the disks in 2TB luns. When we fill the disk completely full while copying files (normal cp done as root) my system crashes The stack dump informs of a lot of weird numbers and irq's but also always mentions xfs The disk is in not a system disk Okay, not very nice, running as root. But now as a normal user. I can't completely fill the disk, but get of course into 100% full, and still crash the system! XFS is tested on these situations? Is this a weird local problem on my system or do have to help the developers by giving detailed debug info. Thanks Jan-Willem Michels From owner-linux-xfs Wed Nov 3 16:48:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Nov 2004 16:48:06 -0800 (PST) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA40m22o026510 for ; Wed, 3 Nov 2004 16:48:02 -0800 Received: from taniwha.stupidest.org (adsl-63-202-172-200.dsl.snfc21.pacbell.net [63.202.172.200]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id iA40ldSA097758; Wed, 3 Nov 2004 19:47:40 -0500 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id A9261115C84A; Wed, 3 Nov 2004 16:47:30 -0800 (PST) Date: Wed, 3 Nov 2004 16:47:30 -0800 From: Chris Wedgwood To: "mail.stads.net" Cc: "linux-xfs@oss.sgi.com" Subject: Re: Fedora2 XFS crash when drive full? Message-ID: <20041104004730.GA17583@taniwha.stupidest.org> References: <20041103234026.AFFE.JWILLEM@stads.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041103234026.AFFE.JWILLEM@stads.net> X-archive-position: 4380 X-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: 589 Lines: 17 On Wed, Nov 03, 2004 at 11:57:18PM +0100, mail.stads.net wrote: > When we fill the disk completely full while copying files (normal cp > done as root) my system crashes The stack dump informs of a lot of > weird numbers and irq's but also always mentions xfs The disk is in > not a system disk > XFS is tested on these situations? yes, but fedora kernels are not (well, not with XFS) > Is this a weird local problem on my system or do have to help the > developers by giving detailed debug info. what kernel are you using? older fedora kernels will break under low-space conditions From owner-linux-xfs Wed Nov 3 18:13:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 03 Nov 2004 18:13:22 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:R13fpiVR9VjRudbs+3gQSZ4qJYx+vUrj@burgers.bubbanfriends.org [69.212.163.241]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA42DH4p029866 for ; Wed, 3 Nov 2004 18:13:17 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id DAF501803656; Wed, 3 Nov 2004 21:12:59 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32707-04; Wed, 3 Nov 2004 21:12:59 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 65FB918000AD; Wed, 3 Nov 2004 21:12:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 649641C0A088; Wed, 3 Nov 2004 21:12:59 -0500 (EST) Date: Wed, 3 Nov 2004 21:12:59 -0500 (EST) From: Mike Burger To: "mail.stads.net" Cc: "linux-xfs@oss.sgi.com" Subject: Re: Fedora2 XFS crash when drive full? In-Reply-To: <20041103234026.AFFE.JWILLEM@stads.net> Message-ID: References: <20041103234026.AFFE.JWILLEM@stads.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-archive-position: 4381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 1461 Lines: 44 On Wed, 3 Nov 2004, mail.stads.net wrote: > > Hi there. > > I have a system with 4TB disk. One LVM "partion", this is formatted with XFS > This is our first system where we cross the 2TB limit of an external raidsystem > normaly we would have the raidsystem export the disks in 2TB luns. > > When we fill the disk completely full while copying files (normal cp done as root) my system crashes > The stack dump informs of a lot of weird numbers and irq's but also always mentions xfs > The disk is in not a system disk > > Okay, not very nice, running as root. > But now as a normal user. > I can't completely fill the disk, but get of course into 100% full, and still crash the system! > > XFS is tested on these situations? > Is this a weird local problem on my system or do have to help the developers by giving detailed debug info. > Thanks Is the filesystem in question the root filesystem? All it takes to crash a system, quite often, is to fill up /var, sometimes /tmp...and if either, or both, are actually part of the root filesystem, rather than separate filesystems, it's a recipe for disaster. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs Thu Nov 4 07:28:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Nov 2004 07:28:22 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iA4FSIiJ011573 for ; Thu, 4 Nov 2004 07:28:19 -0800 Received: (qmail 23398 invoked by uid 65534); 4 Nov 2004 15:27:55 -0000 Received: from G060c.g.pppool.de (EHLO [192.168.10.11]) (80.185.6.12) by mail.gmx.net (mp024) with SMTP; 04 Nov 2004 16:27:55 +0100 X-Authenticated: #2986359 Message-ID: <418A4A79.3000708@gmx.net> Date: Thu, 04 Nov 2004 16:27:53 +0100 From: evilninja User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: Re: Fedora2 XFS crash when drive full? References: <20041103234026.AFFE.JWILLEM@stads.net> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-archive-position: 4383 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 973 Lines: 34 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > On Wed, 3 Nov 2004, mail.stads.net wrote: > >>When we fill the disk completely full while copying files (normal cp done as root) >>my system crashes. The stack dump informs of a lot of weird numbers and irq's but >>also always mentions xfs any copies/transcripts of these "weird numbers" and "xfs mentions"? SYSRQ+T or something...even a photograph of the error would probably help here.... >> Is this a weird local problem on my system or do have to help the developers by giving >> detailed debug info. i am not a developer but i hope they agree that no action taken by a user should crash a system. Christian. - -- BOFH excuse #182: endothermal recalibration -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBikp5C/PVm5+NVoYRAnrdAJ9+2Gt2L7XAFCI6pdtWyw7SN933agCguG5T ozqY2u3BwYO/CbOGAC6L+Y8= =9ugF -----END PGP SIGNATURE----- From owner-linux-xfs Thu Nov 4 08:20:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Nov 2004 08:20:28 -0800 (PST) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA4GKNIm019477 for ; Thu, 4 Nov 2004 08:20:24 -0800 Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id iA4GK1Q7003909 for ; Thu, 4 Nov 2004 16:20:01 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id iA4GK1I9003907 for linux-xfs@oss.sgi.com; Thu, 4 Nov 2004 16:20:01 GMT Received: from 81.86.193.1 ( [81.86.193.1]) as user apsy31@dsl.pipex.com by netmail.pipex.net with HTTP; Thu, 4 Nov 2004 16:20:01 +0000 Message-ID: <1099585201.418a56b192c8f@netmail.pipex.net> Date: Thu, 4 Nov 2004 16:20:01 +0000 From: neil sedger To: linux-xfs@oss.sgi.com Subject: Where to find patch for RedHat 2.4.20-8? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 81.86.193.1 X-PIPEX-Username: apsy31%dsl.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use X-archive-position: 4384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: neil@moley.org.uk Precedence: bulk X-list: linux-xfs Content-Length: 1159 Lines: 29 Hi I need to add XFS support to Red Hat 9's 2.4.20-8. (see below for why this version only) The patches on SGI's site don't go back to 2.4.20, I have some old patches that I used on (original, not RedHat) kernel 2.4.20 but these fail to patch on RedHat's source. Searching this list I see this has been covered and solved by: ftp://oss.sgi.com/projects/xfs/download/Release-1.2/installer/forRH-9.0-SGI-XFS-1.2.0-v1.iso and: ftp://ftp.uninett.no/pub/linux/RH-XFS-DVD but neither of these files are available there now. I have found a patched up rpm for 2.4.20-20.9 but this is no good, I need 2.4.20-8. Any pointers to rpms/patches/kernel sources would be most helpful, thanks. Why do I need 2.4.20-8? I have a Highpoint SATA card, they only have closed-source drivers for this card and they only provide modules for a few RH9 (and debian I think) releases, the latest of which is 2.4.20-8. The module fails with unresolved SCSI symbols for every variation of the official kernel 2.4.20 I've tried (even without XFS patched in), and with the 2.4.20-20.9 XFS RPMs I found. If there's a workaround here I would take that option too... Thanks Neil From owner-linux-xfs Thu Nov 4 10:08:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Nov 2004 10:08:07 -0800 (PST) Received: from eik.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA4I858M029779 for ; Thu, 4 Nov 2004 10:08:05 -0800 Received: from lapprose.ii.uib.no ([129.177.20.37]:33530) by eik.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1CPm1M-00041u-NT; Thu, 04 Nov 2004 19:07:40 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.11/8.12.11/Submit) id iA4I7eCv005363; Thu, 4 Nov 2004 19:07:40 +0100 Date: Thu, 4 Nov 2004 19:07:40 +0100 From: Jan-Frode Myklebust To: neil sedger Cc: linux-xfs@oss.sgi.com Subject: Re: Where to find patch for RedHat 2.4.20-8? Message-ID: <20041104180740.GA5062@ii.uib.no> References: <1099585201.418a56b192c8f@netmail.pipex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1099585201.418a56b192c8f@netmail.pipex.net> X-archive-position: 4385 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Jan-Frode.Myklebust@bccs.uib.no Precedence: bulk X-list: linux-xfs Content-Length: 443 Lines: 13 On Thu, Nov 04, 2004 at 04:20:01PM +0000, neil sedger wrote: > > I have found a patched up rpm for 2.4.20-20.9 but this is no good, I > need 2.4.20-8. Do you have this as src.rpm ? Try diffing the spec-file from plain 2.4.20-20.9 and 2.4.20-8. I suspect the difference will just be enabling of nptl in the .9 version, and if that's the case you should just make the same change to the xfs-patched 2.4.20-20.9 src.rpm, and build it. -jf From owner-linux-xfs Sun Nov 7 06:16:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Nov 2004 06:16:56 -0800 (PST) Received: from alicetele.com (smtp.alicetele.com [193.110.20.164]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA7EGnR8007976 for ; Sun, 7 Nov 2004 06:16:52 -0800 Received: from 192.168.7.185 (web.alicetele.com [193.110.20.21]) by alicetele.com (8.12.11/8.12.9) with ESMTP id iA7EGJw0043600 for ; Sun, 7 Nov 2004 16:16:24 +0200 (EET) (envelope-from Zmey@alicetele.com) Date: Sun, 7 Nov 2004 16:16:14 +0200 From: Zmey X-Mailer: The Bat! (v1.62 Christmas Edition) Personal Reply-To: Zmey X-Priority: 3 (Normal) Message-ID: <4331608841.20041107161614@alicetele.com> To: linux-xfs@oss.sgi.com Subject: XFS Update MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/574/Fri Nov 5 02:12:58 2004 clamav-milter version 0.80j on alicetele.com X-Virus-Status: Clean X-archive-position: 4388 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Zmey@alicetele.com Precedence: bulk X-list: linux-xfs Content-Length: 219 Lines: 9 Hello linux-xfs, Please tell me, where I can download XFS_1.3 kernel patch for latest kernel 2.4.27 ? Including corresponding user tools -- Best regards, Zmey mailto:Zmey@alicetele.com From owner-linux-xfs Sun Nov 7 08:12:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 07 Nov 2004 08:12:48 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iA7GCjur011365 for ; Sun, 7 Nov 2004 08:12:46 -0800 Received: (qmail 22991 invoked by uid 65534); 7 Nov 2004 16:12:22 -0000 Received: from G191b.g.pppool.de (EHLO [192.168.10.11]) (80.185.25.27) by mail.gmx.net (mp011) with SMTP; 07 Nov 2004 17:12:22 +0100 X-Authenticated: #2986359 Message-ID: <418E4965.9020605@gmx.net> Date: Sun, 07 Nov 2004 17:12:21 +0100 From: evilninja User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS Update References: <4331608841.20041107161614@alicetele.com> In-Reply-To: <4331608841.20041107161614@alicetele.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-archive-position: 4389 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 696 Lines: 28 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zmey schrieb: > Hello linux-xfs, > > Please tell me, where I can download XFS_1.3 kernel patch > for latest kernel 2.4.27 ? Including corresponding user tools > xfs is included in linux 2.4 (since... ?), userspace should be available from your distribution or here: ftp://oss.sgi.com/projects/xfs/download/download/cmd_tars/ - -- BOFH excuse #50: Change in Earth's rotational speed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBjklkC/PVm5+NVoYRArzFAKCvLOBjZ3FNoxbfIpI8kYNnt/SlyQCghFIy YCEKaHBh94P1yq7Sv5vc+AA= =Y4N4 -----END PGP SIGNATURE----- From owner-linux-xfs Mon Nov 8 15:03:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Nov 2004 15:03:16 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA8N3EZl027155 for ; Mon, 8 Nov 2004 15:03:14 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iA8N3Exn027154 for linux-xfs@oss.sgi.com; Mon, 8 Nov 2004 15:03:14 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA8N3DXY027140 for ; Mon, 8 Nov 2004 15:03:13 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iA8MwBuk026673; Mon, 8 Nov 2004 14:58:11 -0800 Date: Mon, 8 Nov 2004 14:58:11 -0800 Message-Id: <200411082258.iA8MwBuk026673@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 381] Segmentation fault while loading xfs module X-Bugzilla-Reason: AssignedTo X-archive-position: 4392 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 382 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=381 ------- Additional Comments From nathans@sgi.com 2004-08-11 14:58 PDT ------- > kernel BUG at kernel/module.c:257! Did you try Rusty's fix in the same thread? Looks like this is not an XFS issue. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Mon Nov 8 15:55:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 08 Nov 2004 15:55:11 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iA8Nt7Wt000457 for ; Mon, 8 Nov 2004 15:55:09 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08860 for ; Tue, 9 Nov 2004 10:54:44 +1100 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id iA8Nnr5o012566 for ; Tue, 9 Nov 2004 10:49:53 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id iA8NnqR2012565 for linux-xfs@oss.sgi.com; Tue, 9 Nov 2004 10:49:52 +1100 Date: Tue, 9 Nov 2004 10:49:52 +1100 From: FSG QA Message-Id: <200411082349.iA8NnqR2012565@bruce.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfstests X-archive-position: 4393 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1311 Lines: 35 Get things working for unusual filesystem types once again. Date: Tue Oct 12 11:17:14 AEST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/slinx/xfs-cmds-melb Modid: xfs-cmds-melb:slinx:19728a xfstests/common.rc - 1.49 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/common.rc.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h Make test 005 work on SuSE kernels, cleanup its use on other platforms too. Date: Tue Nov 9 10:54:16 AEDT 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/slinx/xfs-cmds-melb Modid: xfs-cmds-melb:slinx:20052a xfstests/005 - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/005.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfstests/005.out - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/005.out.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h xfstests/005.out.irix - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/005.out.irix.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfstests/005.out.linux - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/005.out.linux.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs Tue Nov 9 12:12:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Nov 2004 12:12:30 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.177.98]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA9KCRuW015024 for ; Tue, 9 Nov 2004 12:12:28 -0800 Received: from mail.diaradiology.org (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id B3664675C9A7 for ; Tue, 9 Nov 2004 12:12:09 -0800 (PST) Received: from [10.11.11.174] (mail.imr-net.com [65.182.241.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id 66D33675C990 for ; Tue, 9 Nov 2004 12:12:09 -0800 (PST) Message-ID: <41912498.4000302@pacrimopen.com> Date: Tue, 09 Nov 2004 12:12:08 -0800 From: Joshua Schmidlkofer User-Agent: Mozilla Thunderbird 0.8 (X11/20040915) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS - Changing sunit and swidth X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4397 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kernel@pacrimopen.com Precedence: bulk X-list: linux-xfs Content-Length: 1077 Lines: 35 The mount man page lists the ability to change the sunit and swidth via mount options. Is that the case? Does it work? I will Use The Source(tm) if no one wants to answer. However, everyone keeps reiterating the complexity of XFS, and maybe someon knows. Here are my current mount options. /dev/sda1 /snapshots xfs noatime,nodiratime,logbufs=8,sunit=16,swidth=48 0 0 Here is xfs_info: meta-data=/snapshots isize=256 agcount=32, agsize=4577708 blks = sectsz=512 data = bsize=4096 blocks=146486656, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 ----------- I don't see any change in sunit nor swidth. The previous admin did not know about XFS options for arrays. thanks, Joshua From owner-linux-xfs Tue Nov 9 14:37:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Nov 2004 14:37:21 -0800 (PST) Received: from srvr5.engin.umich.edu (root@srvr5.engin.umich.edu [141.213.75.23]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA9Mb7EM024144 for ; Tue, 9 Nov 2004 14:37:08 -0800 Received: from [141.212.196.116] (techess.engin.umich.edu [141.212.196.116]) by srvr5.engin.umich.edu (8.12.10/8.12.10) with ESMTP id iA9Mam41022619 for ; Tue, 9 Nov 2004 17:36:48 -0500 (EST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 09 Nov 2004 17:36:47 -0500 Subject: Xfs partition info seems to be lost on reboot From: Melissa Terwilliger To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-archive-position: 4398 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: techess@umich.edu Precedence: bulk X-list: linux-xfs Content-Length: 2228 Lines: 66 I have a dual opteron SuSE 9 SLES machine running 2.6.9 kernel. The machine has 2 3ware 9500-12 PCI-X SATA raid cards installed with 12 250 GB drives on each card. I can create the partitions using parted & when I mount the two partitions they show up correctly as 2.6 TB each and they seem to be working perfectly. When I reboot the system I get the error: kernel:XFS:size check 2 failed in the kernel log and the mount command came back bad superblock on /dev/sdb1. I can no longer mount the drives. I tried doing a xfs_repair to fix the drive and I can mount it again, but it only shows up as 513GB after that. Then I have to go into parted again to delete the partition and recreate it. Again it works until I reboot whether or not I have it set to mount in the fstab or to mount by hand later. When I format the drive as ext3 I don't have this problem and it is 100% stable. It only looses the information when I use xfs. I'm sure I'm just missing something but I'm not certain what. Basically this is what I am doing to create the partitions: #parted /dev/sdb #mkpart primary xfs 0.0 2622488.000 #print Disk geometry for /dev/sdc: 0.000-2622488.000 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.031 525333.742 primary xfs type=83 #quit then after the partition was created I did # mkfs.xfs -f /dev/sdc1 meta-data=/dev/sdc1 isize=256 agcount=32, agsize=20979885 blks = sectsz=512 data = bsize=4096 blocks=671356320, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 #mount /dev/sdc1 /scr3 #df -h /dev/sdc1 2.6T 528K 2.6T 1% /scr3 I can mount and unmount this device repeatedly with no problems until I reboot. Thanks, Melissa Terwilliger Space Physics Research Lab AOSS Support techess@umich.edu -- Don't anthropomorphize computers. They hate that. From owner-linux-xfs Tue Nov 9 15:28:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Nov 2004 15:28:44 -0800 (PST) Received: from wildernessvoice.com (wildernessvoice.com [216.218.172.84]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iA9NSe80028509 for ; Tue, 9 Nov 2004 15:28:40 -0800 Received: from 66.14.154.112 ([66.14.154.112]) by wildernessvoice.com for ; Tue, 9 Nov 2004 15:28:27 -0800 From: Mike Young To: Melissa Terwilliger Subject: Re: Xfs partition info seems to be lost on reboot Date: Tue, 9 Nov 2004 15:29:11 -0800 User-Agent: KMail/1.7 Cc: linux-xfs@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411091529.11584.myoung@wildernessvoice.com> X-archive-position: 4399 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: myoung@wildernessvoice.com Precedence: bulk X-list: linux-xfs Content-Length: 3711 Lines: 91 Melissa, I too had problems related to this configuration. In my case I was using a 12-channel 3Ware 9500 series controller along with 12 WD 250GB drives. XFS has been my default FS for some time now. Also, I am running SLES9 SP1 (2.6.5-7.111). My 3Ware-based RAID began to complain about bad data in the scatter gather lists. Soon my system began oopsing after being up for only a few minutes. Soon after, my controller flat out died. I tried hooking up the 12 WD drives to another controller to use with MD RAID. All 12 of the drives have failed to be readable by any of the SATA controllers I have. They all return seek errors when trying to mount the drives. I have another RAID, based on 15 fibre-channel drives and using MD RAID5 with XFS. This combination has also been great. My partitions are configured as RAID partitions. This gets autodetected by SLES when you reboot and the array gets reassembled without a hiccup. I have had this array in operation for more than 6 months. In all fairness, this 15 disk array was created under a different distribution and the migrated over to SLES9. However, I picked up several more Hitachi SATA drives to replace my 3Ware/WD RAID. It too has had no problem on reboot with XFS, though it's only a small amount of time. -Mike On Tuesday 09 November 2004 14:36, Melissa Terwilliger wrote: > I have a dual opteron SuSE 9 SLES machine running 2.6.9 kernel. The > machine has 2 3ware 9500-12 PCI-X SATA raid cards installed with 12 > 250 GB drives on each card. > > I can create the partitions using parted & when I mount the two > partitions they show up correctly as 2.6 TB each and they seem to be > working perfectly. When I reboot the system I get the error: > kernel:XFS:size check 2 failed in the kernel log and the mount command > came back bad superblock on /dev/sdb1. I can no longer mount the > drives. I tried doing a xfs_repair to fix the drive and I can mount > it again, but it only shows up as 513GB after that. Then I have to go > into parted again to delete the partition and recreate it. Again it > works until I reboot whether or not I have it set to mount in the fstab > or to mount by hand later. > > When I format the drive as ext3 I don't have this problem and it is 100% > stable. It only looses the information when I use xfs. I'm sure I'm just > missing something but I'm not certain what. > > Basically this is what I am doing to create the partitions: > > #parted /dev/sdb > #mkpart primary xfs 0.0 2622488.000 > #print > Disk geometry for /dev/sdc: 0.000-2622488.000 megabytes > Disk label type: msdos > Minor Start End Type Filesystem Flags > 1 0.031 525333.742 primary xfs type=83 > #quit > > then after the partition was created I did > > # mkfs.xfs -f /dev/sdc1 > meta-data=/dev/sdc1 isize=256 agcount=32, > agsize=20979885 blks > = sectsz=512 > data = bsize=4096 blocks=671356320, > imaxpct=25 > = sunit=0 swidth=0 blks, > unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=32768, > version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > #mount /dev/sdc1 /scr3 > #df -h > /dev/sdc1 2.6T 528K 2.6T 1% /scr3 > > I can mount and unmount this device repeatedly with no problems until > I reboot. > > Thanks, > > Melissa Terwilliger > Space Physics Research Lab > AOSS Support > techess@umich.edu > > > -- Don't anthropomorphize computers. They hate that. From owner-linux-xfs Tue Nov 9 15:38:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Nov 2004 15:38:12 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iA9Nc8wX029273 for ; Tue, 9 Nov 2004 15:38:09 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA05197; Wed, 10 Nov 2004 10:37:42 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iA9Nbeln5830757; Wed, 10 Nov 2004 10:37:40 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iA9MZj5g000975; Wed, 10 Nov 2004 09:35:45 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iA9MZg8j000973; Wed, 10 Nov 2004 09:35:42 +1100 Date: Wed, 10 Nov 2004 09:35:42 +1100 From: Nathan Scott To: Joshua Schmidlkofer Cc: linux-xfs@oss.sgi.com Subject: Re: XFS - Changing sunit and swidth Message-ID: <20041109223542.GA740@frodo> References: <41912498.4000302@pacrimopen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41912498.4000302@pacrimopen.com> User-Agent: Mutt/1.5.3i X-archive-position: 4400 X-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: 1041 Lines: 29 On Tue, Nov 09, 2004 at 12:12:08PM -0800, Joshua Schmidlkofer wrote: > The mount man page lists the ability to change the sunit and swidth via > mount options. > > Is that the case? Does it work? I will Use The Source(tm) if no one Yes, this is the case, and it should work. Look at the top of xfs_mountfs() in xfs_mount.c, thats where these mouint options are poked into the superblock. > /dev/sda1 /snapshots xfs > noatime,nodiratime,logbufs=8,sunit=16,swidth=48 0 0 > meta-data=/snapshots isize=256 agcount=32, agsize=4577708 > blks > = sectsz=512 > data = bsize=4096 blocks=146486656, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 thats odd, I'd expect the new values to show up here, from a quick look at the code. I'd suggest putting some printks in that code I pointed out above, and see which code path it is using there & why your superblock isn't being updated. cheers. -- Nathan From owner-linux-xfs Tue Nov 9 15:46:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Nov 2004 15:46:54 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iA9NkoxO030084 for ; Tue, 9 Nov 2004 15:46:51 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA05434; Wed, 10 Nov 2004 10:46:25 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iA9NkMln5832211; Wed, 10 Nov 2004 10:46:23 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iA9MiR5g001013; Wed, 10 Nov 2004 09:44:28 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iA9MiPi1001011; Wed, 10 Nov 2004 09:44:26 +1100 Date: Wed, 10 Nov 2004 09:44:25 +1100 From: Nathan Scott To: Melissa Terwilliger Cc: linux-xfs@oss.sgi.com Subject: Re: Xfs partition info seems to be lost on reboot Message-ID: <20041109224425.GB740@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 4401 X-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: 2223 Lines: 56 On Tue, Nov 09, 2004 at 05:36:47PM -0500, Melissa Terwilliger wrote: > > I have a dual opteron SuSE 9 SLES machine running 2.6.9 kernel. The I guess that means you built your own kernel (since SLES9 is a 2.6.5 based kernel). Did you enable CONFIG_LBD? > I can create the partitions using parted & when I mount the two > partitions they show up correctly as 2.6 TB each and they seem to be > working perfectly. When I reboot the system I get the error: > kernel:XFS:size check 2 failed in the kernel log and the mount command > came back bad superblock on /dev/sdb1. I can no longer mount the XFS does a check on mount to make sure that the last sector on the device is actually accessible (ie. does a read of the last 512 bytes). For your kernel, this read is giving an error, so XFS doesn't trust the device and fails the mount. > drives. I tried doing a xfs_repair to fix the drive and I can mount > it again, but it only shows up as 513GB after that. Then I have to go Not sure I can explain that bit. I wouldn't have expected repair to do that even if the device driver is doing funky things. > into parted again to delete the partition and recreate it. Again it > works until I reboot whether or not I have it set to mount in the fstab > or to mount by hand later. > > When I format the drive as ext3 I don't have this problem and it is 100% > stable. It only looses the information when I use xfs. I'm sure I'm just > missing something but I'm not certain what. Hmm. ext3 wont be doing the final sector read check I expect... so, it works fine (and the odds of allocating something at the high end of the device is unlikely, during a simple test like this). > Basically this is what I am doing to create the partitions: > > #parted /dev/sdb > #mkpart primary xfs 0.0 2622488.000 I don't know much about parted, but there was a report on the lbd list the other day - maybe check the archive for that list, I can't remember what the solution was there off the top of my head. > I can mount and unmount this device repeatedly with no problems until > I reboot. Very odd. I suspect its more likely to be a driver/partition table problem rather than an XFS problem though. cheers. -- Nathan From owner-linux-xfs Tue Nov 9 20:01:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 09 Nov 2004 20:01:43 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAA41daD016053 for ; Tue, 9 Nov 2004 20:01:40 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA10930 for ; Wed, 10 Nov 2004 15:01:15 +1100 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id iAA3t2Ia012678 for ; Wed, 10 Nov 2004 14:55:02 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id iAA3t1EC012677 for linux-xfs@oss.sgi.com; Wed, 10 Nov 2004 14:55:01 +1100 Date: Wed, 10 Nov 2004 14:55:01 +1100 From: FSG QA Message-Id: <200411100355.iAA3t1EC012677@bruce.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfstests X-archive-position: 4405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 906 Lines: 29 Fix test 046 - need to include time in symlink filter, as well as dates. Date: Tue Nov 9 11:09:50 AEDT 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/slinx/xfs-cmds-melb Modid: xfs-cmds-melb:slinx:20054a xfstests/common.dump - 1.53 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/common.dump.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h Fix quota tests to correctly run on SuSE. Date: Wed Nov 10 15:00:48 AEDT 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/slinx/xfs-cmds-melb Modid: xfs-cmds-melb:slinx:20073a xfstests/common.quota - 1.20 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/common.quota.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h From owner-linux-xfs Wed Nov 10 08:54:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Nov 2004 08:55:00 -0800 (PST) Received: from wczesny.power.com.pl (host-ip178-211.crowley.pl [62.111.211.178]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAAGswZC027654 for ; Wed, 10 Nov 2004 08:54:58 -0800 Subject: UUIDs / stable identifiers for files and directories? To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: From: wojtek@power.com.pl Date: Wed, 10 Nov 2004 17:52:57 +0100 X-MIMETrack: Serialize by Router on Palacyk/Power(Release 5.0.10 |March 22, 2002) at 11/10/2004 05:53:03 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 4409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wojtek@power.com.pl Precedence: bulk X-list: linux-xfs Content-Length: 443 Lines: 14 Hello, Is it true that every file and directory has its own UUID? And if so: is it accessible to user programs? Can it be made accessible? We want to develop a system that would store part of its data in the filesystem, and part in the database. It would be very convenient to have an unique and stable (surviving backup - restore, dump) filesystem object identifiers, and also uid -> path, or open by uid functionality. Regards, Wojtek From owner-linux-xfs Wed Nov 10 14:48:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Nov 2004 14:48:38 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAAMmXBw021619 for ; Wed, 10 Nov 2004 14:48:34 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA03007; Thu, 11 Nov 2004 09:48:08 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAAMm6ln5854351; Thu, 11 Nov 2004 09:48:07 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iAALkAEh000766; Thu, 11 Nov 2004 08:46:11 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iAALk7ib000764; Thu, 11 Nov 2004 08:46:07 +1100 Date: Thu, 11 Nov 2004 08:46:07 +1100 From: Nathan Scott To: wojtek@power.com.pl Cc: linux-xfs@oss.sgi.com Subject: Re: UUIDs / stable identifiers for files and directories? Message-ID: <20041110214607.GA712@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 4410 X-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: 956 Lines: 25 On Wed, Nov 10, 2004 at 05:52:57PM +0100, wojtek@power.com.pl wrote: > Hello, > > Is it true that every file and directory has its own UUID? And if so: is it > accessible to user programs? Can it be made accessible? Hmm, if you mean UUID's like those described in libuuid(3), then no - each filesystem has a UUID, but not each file. Each file has an inode number of course... and XFS does provide mechanisms to get to files and directories via inode number. > We want to develop a system that would store part of its data in the > filesystem, and part in the database. It would be very convenient to have > an unique and stable (surviving backup - restore, dump) filesystem object > identifiers, and also uid -> path, or open by uid functionality. There's an XFS API to do what you want, I think - open_by_handle(3) and friends; this is used extensively by xfsdump and DMAPI to do the sorts of thing you're talking about there. cheers. -- Nathan From owner-linux-xfs Wed Nov 10 15:14:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Nov 2004 15:14:57 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAANEpQu023184 for ; Wed, 10 Nov 2004 15:14:51 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAB0VB55027447 for ; Wed, 10 Nov 2004 16:31:11 -0800 Received: from chewtoy.americas.sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id iAANEIam1801462; Wed, 10 Nov 2004 17:14:18 -0600 (CST) Received: from chewtoy (localhost [127.0.0.1]) by chewtoy.americas.sgi.com (Postfix) with ESMTP id 0302A4FA2A; Wed, 10 Nov 2004 17:14:17 -0600 (CST) To: Nathan Scott Cc: wojtek@power.com.pl, linux-xfs@oss.sgi.com Subject: Re: UUIDs / stable identifiers for files and directories? Date: Wed, 10 Nov 2004 17:14:17 -0600 From: Dean Roehrich Message-Id: <20041110231417.0302A4FA2A@chewtoy.americas.sgi.com> X-archive-position: 4411 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1291 Lines: 32 [resending...had a bounce] >From: Nathan Scott >On Wed, Nov 10, 2004 at 05:52:57PM +0100, wojtek@power.com.pl wrote: >> Hello, >> >> Is it true that every file and directory has its own UUID? And if so: is it >> accessible to user programs? Can it be made accessible? > >Hmm, if you mean UUID's like those described in libuuid(3), then >no - each filesystem has a UUID, but not each file. Each file has >an inode number of course... and XFS does provide mechanisms to get >to files and directories via inode number. Each file does have a unique identifer, called a handle. The handle is a tuple containing (filesystem id, inode number, inode generation number). So while it's not a uuid, it is, however, unique. >> We want to develop a system that would store part of its data in the >> filesystem, and part in the database. It would be very convenient to have >> an unique and stable (surviving backup - restore, dump) filesystem object >> identifiers, and also uid -> path, or open by uid functionality. The handle won't be persistent across a dump/restore (as you can probably guess, now that you know its contents). You can put a unique identifier in an extended attribute and let xfsdump and xfsrestore carry the extended attributes around for you. Dean From owner-linux-xfs Wed Nov 10 15:42:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Nov 2004 15:42:10 -0800 (PST) Received: from flyingAngel.upjs.sk (gprs185-222.eurotel.cz [160.218.185.222]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAANg3Zv024137 for ; Wed, 10 Nov 2004 15:42:06 -0800 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id F35401004AF; Thu, 11 Nov 2004 01:02:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id EF441181200; Thu, 11 Nov 2004 01:02:38 +0100 (CET) Date: Thu, 11 Nov 2004 01:02:38 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Nathan Scott Cc: Melissa Terwilliger , linux-xfs@oss.sgi.com Subject: Re: Xfs partition info seems to be lost on reboot In-Reply-To: <20041109224425.GB740@frodo> Message-ID: References: <20041109224425.GB740@frodo> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 1090 Lines: 30 On Wed, 10 Nov 2004, Nathan Scott wrote: Hello. > On Tue, Nov 09, 2004 at 05:36:47PM -0500, Melissa Terwilliger wrote: > > > > I have a dual opteron SuSE 9 SLES machine running 2.6.9 kernel. The > > I guess that means you built your own kernel (since SLES9 is a > 2.6.5 based kernel). Did you enable CONFIG_LBD? I'm curious, why there is CONFIG_LBD on 64-bit architecture? Is there because of VFS issue? I'm using Athlon64 kernel with CONFIG_LBD unset and XFS seems to use large block/inode numbers: SGI-XFS CVS-2004-10-22_05:00_UTC with ACLs, large block/inode numbers, no debug enabled > > I can create the partitions using parted & when I mount the two > > partitions they show up correctly as 2.6 TB each and they seem to be > > working perfectly. When I reboot the system I get the error: > > kernel:XFS:size check 2 failed in the kernel log and the mount command > > came back bad superblock on /dev/sdb1. I can no longer mount the Is there possibility that parted changes only kernel idea about partition table but not real disk layout? Did you try fdisk? jan -- From owner-linux-xfs Wed Nov 10 16:22:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Nov 2004 16:22:26 -0800 (PST) Received: from wildernessvoice.com (wildernessvoice.com [216.218.172.84]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAB0MPWf031426 for ; Wed, 10 Nov 2004 16:22:25 -0800 Received: from 66.14.154.112 ([66.14.154.112]) by wildernessvoice.com for ; Wed, 10 Nov 2004 16:22:13 -0800 From: Mike Young To: Jan Derfinak Subject: Re: Xfs partition info seems to be lost on reboot Date: Wed, 10 Nov 2004 16:22:51 -0800 User-Agent: KMail/1.7 Cc: Nathan Scott , Melissa Terwilliger , linux-xfs@oss.sgi.com References: <20041109224425.GB740@frodo> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411101622.51438.myoung@wildernessvoice.com> X-archive-position: 4413 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: myoung@wildernessvoice.com Precedence: bulk X-list: linux-xfs Content-Length: 1377 Lines: 35 Are you sure config_lbd is unset? Everyone of my Opteron and Athlon64 machines have this set. I run SLES9 on everything, including my laptop. This seems to be the default setting. -Mike On Wednesday 10 November 2004 16:02, Jan Derfinak wrote: > On Wed, 10 Nov 2004, Nathan Scott wrote: > > Hello. > > > On Tue, Nov 09, 2004 at 05:36:47PM -0500, Melissa Terwilliger wrote: > > > I have a dual opteron SuSE 9 SLES machine running 2.6.9 kernel. The > > > > I guess that means you built your own kernel (since SLES9 is a > > 2.6.5 based kernel). Did you enable CONFIG_LBD? > > I'm curious, why there is CONFIG_LBD on 64-bit architecture? > Is there because of VFS issue? > I'm using Athlon64 kernel with CONFIG_LBD unset and XFS seems to use large > block/inode numbers: > SGI-XFS CVS-2004-10-22_05:00_UTC with ACLs, large block/inode numbers, no > debug enabled > > > > I can create the partitions using parted & when I mount the two > > > partitions they show up correctly as 2.6 TB each and they seem to be > > > working perfectly. When I reboot the system I get the error: > > > kernel:XFS:size check 2 failed in the kernel log and the mount command > > > came back bad superblock on /dev/sdb1. I can no longer mount the > > Is there possibility that parted changes only kernel idea about partition > table but not real disk layout? Did you try fdisk? > > jan From owner-linux-xfs Wed Nov 10 16:40:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 10 Nov 2004 16:40:59 -0800 (PST) Received: from flyingAngel.upjs.sk (gprs185-222.eurotel.cz [160.218.185.222]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAB0es9H032241 for ; Wed, 10 Nov 2004 16:40:56 -0800 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 976B71004AF; Thu, 11 Nov 2004 02:01:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 948B9181200; Thu, 11 Nov 2004 02:01:30 +0100 (CET) Date: Thu, 11 Nov 2004 02:01:30 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Mike Young Cc: linux-xfs@oss.sgi.com Subject: Re: Xfs partition info seems to be lost on reboot In-Reply-To: <200411101622.51438.myoung@wildernessvoice.com> Message-ID: References: <20041109224425.GB740@frodo> <200411101622.51438.myoung@wildernessvoice.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 597 Lines: 20 On Wed, 10 Nov 2004, Mike Young wrote: > Are you sure config_lbd is unset? Everyone of my Opteron and Athlon64 > machines have this set. I run SLES9 on everything, including my laptop. > This seems to be the default setting. It is default setting on SLES9 but I use self compiled kernel. I don't have disks bigger than 2TB, I had unset it. > uname -m -r -v 2.6.9 #2 Mon Nov 8 02:07:41 CET 2004 x86_64 > zcat /proc/config.gz | grep CONFIG_LBD # CONFIG_LBD is not set > dmesg | grep XFS SGI-XFS CVS-2004-10-22_05:00_UTC with ACLs, large block/inode numbers, no debug enabled jan -- From owner-linux-xfs Thu Nov 11 06:19:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Nov 2004 06:19:58 -0800 (PST) Received: from wanderer.mr.itd.umich.edu (wanderer.mr.itd.umich.edu [141.211.93.146]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iABEJrw1020196 for ; Thu, 11 Nov 2004 06:19:54 -0800 Received: from [141.212.196.116] (techess.engin.umich.edu [141.212.196.116]) by wanderer.mr.itd.umich.edu (smtp) with ESMTP id iABEJWP7007620; Thu, 11 Nov 2004 09:19:33 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 11 Nov 2004 09:19:38 -0500 Subject: Re: Xfs partition info seems to be lost on reboot From: Melissa Terwilliger To: Jan Derfinak , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-archive-position: 4415 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: techess@umich.edu Precedence: bulk X-list: linux-xfs Content-Length: 683 Lines: 24 zcat /proc/config.gz | grep CONFIG_LBD CONFIG_LBD=y So I do have that set. Should I have that unset do you think? >Is there possibility that parted changes only kernel idea about partition >table but not real disk layout? Did you try fdisk? I have not used fdisk because I was told that it would work properly on disks over 2TB, the 3ware company suggested parted instead. We have two identical machines setup. I think I'm going to Try RedHat WS3 and see if I have a similar problem there. It might just be a problem with the 3Ware card or drivers. Melissa Terwilliger Space Physics Research Lab AOSS Support techess@umich.edu -- Features are merely bugs with seniority. From owner-linux-xfs Thu Nov 11 07:13:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Nov 2004 07:13:44 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iABFDfmY022002 for ; Thu, 11 Nov 2004 07:13:41 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iABFDNxT023876 for ; Thu, 11 Nov 2004 09:13:23 -0600 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id iABFDBam1845830; Thu, 11 Nov 2004 09:13:12 -0600 (CST) Message-ID: <41938187.2020503@sgi.com> Date: Thu, 11 Nov 2004 09:13:11 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mail.stads.net" CC: "linux-xfs@oss.sgi.com" Subject: Re: Fedora2 XFS crash when drive full? References: <20041103234026.AFFE.JWILLEM@stads.net> In-Reply-To: <20041103234026.AFFE.JWILLEM@stads.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4416 X-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: 776 Lines: 18 mail.stads.net wrote: > Hi there. > > I have a system with 4TB disk. One LVM "partion", this is formatted with XFS > This is our first system where we cross the 2TB limit of an external raidsystem > normaly we would have the raidsystem export the disks in 2TB luns. > > When we fill the disk completely full while copying files (normal cp done as root) my system crashes > The stack dump informs of a lot of weird numbers and irq's but also always mentions xfs Nothing we can do here without some real information on the crash. Kernel messages, backtraces, etc. It could be an xfs problem but the existence of xfs in the backtrace doesn't necessarily mean that, you have plenty of layers to go through. XFS has been well-tested with > 2T filesystems, FWIW. -Eric From owner-linux-xfs Thu Nov 11 07:39:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Nov 2004 07:39:33 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iABFdVKr023171 for ; Thu, 11 Nov 2004 07:39:31 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iABGtutx030876 for ; Thu, 11 Nov 2004 08:55:56 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id iABFcwp73704270; Thu, 11 Nov 2004 09:38:58 -0600 (CST) Message-ID: <41938792.8090107@sgi.com> Date: Thu, 11 Nov 2004 09:38:58 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jan Derfinak CC: Nathan Scott , Melissa Terwilliger , linux-xfs@oss.sgi.com Subject: Re: Xfs partition info seems to be lost on reboot References: <20041109224425.GB740@frodo> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4417 X-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: 1686 Lines: 57 I'm guessing there's a problem with parted somewhere.... you might use fdisk to print the partition headers and see if it looks ok - if not, I guess either fdisk or parted has a problem. I suppose the only way to know for sure is to dump the partition table from the disk and poke around in it to see if it's writing what you think it's writing. One other test, try looking at /proc/partitions before & after the reboot - how does your device size look? excursion into CONFIG_LBD below... Jan Derfinak wrote: > I'm curious, why there is CONFIG_LBD on 64-bit architecture? > Is there because of VFS issue? I guess CONFIG_LBD is settable on x86_64 because: config LBD bool "Support for Large Block Devices" depends on X86 || MIPS32 || PPC32 || ARCH_S390_31 || SUPERH and x86_64 -does- set CONFIG_X86.... but it should not make any difference I think. The main LBD "switch" is the size of sector_t. It's set in include/linux/types.h unless HAVE_SECTOR_T is set: #ifndef HAVE_SECTOR_T typedef unsigned long sector_t; #endif include/asm-i386/types.h overrides this if CONFIG_LBD is on: #ifdef CONFIG_LBD typedef u64 sector_t; #define HAVE_SECTOR_T #endif but include/asm-x86_64/types.h sets it regardless: typedef u64 sector_t; #define HAVE_SECTOR_T XFS code shouldn't care; when it tests for CONFIG_LBD in xfs_linux.h it also tests for BITS_PER_LONG == 64, and the only other test for CONFIG_LBD is only under BITS_PER_LONG == 32. The only other question I'd have about it is how the do_div macro ultimately winds up getting defined... More than you probably wanted to know about LBD, and probably doesn't answer your question. :) -Eric From owner-linux-xfs Thu Nov 11 10:46:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Nov 2004 10:46:27 -0800 (PST) Received: from flyingAngel.upjs.sk (gprs185-222.eurotel.cz [160.218.185.222]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iABIkI1v032558 for ; Thu, 11 Nov 2004 10:46:21 -0800 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 3740B1004A5; Thu, 11 Nov 2004 20:06:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 2C9B9181207; Thu, 11 Nov 2004 20:06:55 +0100 (CET) Date: Thu, 11 Nov 2004 20:06:55 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Xfs partition info seems to be lost on reboot In-Reply-To: <41938792.8090107@sgi.com> Message-ID: References: <20041109224425.GB740@frodo> <41938792.8090107@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4418 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 743 Lines: 28 On Thu, 11 Nov 2004, Eric Sandeen wrote: > > I'm curious, why there is CONFIG_LBD on 64-bit architecture? > > Is there because of VFS issue? > > I guess CONFIG_LBD is settable on x86_64 because: > > config LBD > bool "Support for Large Block Devices" > depends on X86 || MIPS32 || PPC32 || ARCH_S390_31 || SUPERH > > and x86_64 -does- set CONFIG_X86.... but it should not make any difference I > think. > ... > More than you probably wanted to know about LBD, and probably doesn't answer > your question. :) > Thanks. I asked because I think that CONFIG_LBD isn't necessary on x86_64 platform but I was not sure. Other 64-bit archs work without it. It looks for me like an inaccurancy in kernel config. jan -- From owner-linux-xfs Thu Nov 11 10:46:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Nov 2004 10:46:30 -0800 (PST) Received: from flyingAngel.upjs.sk (gprs185-222.eurotel.cz [160.218.185.222]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iABIkO6C032580 for ; Thu, 11 Nov 2004 10:46:26 -0800 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 1F30C1004B1; Thu, 11 Nov 2004 20:07:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 1DF42181207; Thu, 11 Nov 2004 20:07:01 +0100 (CET) Date: Thu, 11 Nov 2004 20:07:01 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Melissa Terwilliger Cc: linux-xfs@oss.sgi.com Subject: Re: Xfs partition info seems to be lost on reboot In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4419 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 1026 Lines: 30 On Thu, 11 Nov 2004, Melissa Terwilliger wrote: > zcat /proc/config.gz | grep CONFIG_LBD > CONFIG_LBD=y > > So I do have that set. Should I have that unset do you think? I think that there is no difference on 64-bit system. You can leave it on. I propose to use original SLES9 kernel if it is possible. It is well tested and approved by many companies. > > >Is there possibility that parted changes only kernel idea about partition > >table but not real disk layout? Did you try fdisk? > > I have not used fdisk because I was told that it would work properly on > disks over 2TB, the 3ware company suggested parted instead. > > We have two identical machines setup. I think I'm going to Try RedHat WS3 > and see if I have a similar problem there. It might just be a problem with > the 3Ware card or drivers. Simplest thing you can do is to use fdisk and also look to /proc/partitions before/after reboot like Eric mentioned. Please tell me if there is any diffence if you use fdisk or SLES9 kernel. jan -- From owner-linux-xfs Thu Nov 11 19:26:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 11 Nov 2004 19:26:40 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAC3Qbbo009665 for ; Thu, 11 Nov 2004 19:26:38 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAC4h7FN014915 for ; Thu, 11 Nov 2004 20:43:07 -0800 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAC3PIUh1152441 for ; Thu, 11 Nov 2004 19:25:18 -0800 (PST) Message-ID: <41942D1F.5050201@sgi.com> Date: Thu, 11 Nov 2004 21:25:19 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: TAKE - wait for async IOs before tearing down fs at umount time Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4420 X-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: 1636 Lines: 44 Wait for all async buffers to complete before tearing down the filesystem at umount time Date: Thu Nov 11 19:18:17 PST 2004 Workarea: penguin.americas.sgi.com:/src/eric/xfs-trees/xfs-GUT-iodone2 Inspected by: nathans cattelan Author: sandeen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:182694a xfs_mount.h - 1.191 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.191&r2=text&tr2=1.190&f=h - prototype for xfs_unmountfs_wait xfs_mount.c - 1.353 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.353&r2=text&tr2=1.352&f=h - call xfs_wait_buftarg before starting to tear down the filesystem at umount time linux-2.6/xfs_buf.h - 1.101 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.101&r2=text&tr2=1.100&f=h - prototype for xfs_wait_buftarg linux-2.6/xfs_buf.c - 1.180 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.180&r2=text&tr2=1.179&f=h - add xfs_wait_buftarg - returns only when all async bufs for a buftarg are complete linux-2.4/xfs_buf.h - 1.107 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.h.diff?r1=text&tr1=1.107&r2=text&tr2=1.106&f=h - prototype for xfs_wait_buftarg linux-2.4/xfs_buf.c - 1.199 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.c.diff?r1=text&tr1=1.199&r2=text&tr2=1.198&f=h - add xfs_wait_buftarg - returns only when all async bufs for a buftarg are complete From owner-linux-xfs Fri Nov 12 13:03:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 12 Nov 2004 13:03:37 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iACL3WSr021774 for ; Fri, 12 Nov 2004 13:03:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iACL3WWE021773 for linux-xfs@oss.sgi.com; Fri, 12 Nov 2004 13:03:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iACL3Uea021759 for ; Fri, 12 Nov 2004 13:03:31 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iACKigAn021399; Fri, 12 Nov 2004 12:44:42 -0800 Date: Fri, 12 Nov 2004 12:44:42 -0800 Message-Id: <200411122044.iACKigAn021399@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 383] New: Write to an XFS file system generates errno 990 X-Bugzilla-Reason: AssignedTo X-archive-position: 4421 X-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: 9179 Lines: 172 http://oss.sgi.com/bugzilla/show_bug.cgi?id=383 Summary: Write to an XFS file system generates errno 990 Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: Louis.Romero@vexcel.com CC: Louis.Romero@vexcel.com Enclosed is a Call Trace that came out of /var/log/messages. I have 200k lines of simliar messages. uname -a = "Linux dcs4apb 2.6.5-7.108-smp #1 SMP Wed Aug 25 13:34:40 UTC 2004 i686 i686 i386 GNU/Linux" Distro = SuSe 9.1 mount command::/dev/md1 on /data2 type xfs (rw) This is a bound SCSI volume. C++ program was writing to an xfs file system and got to ~1.0 GB b4 spamming /var/log/messages pretty hard with the following: Nov 12 19:44:22 dcs4apb kernel: 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Nov 12 19:44:22 dcs4apb kernel: Filesystem "md1": XFS internal error xfs_alloc_read_agf at line 2195 of file fs/xfs/xfs_alloc.c. Caller 0xf925f90c Nov 12 19:44:22 dcs4apb kernel: Call Trace: Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4222016/5385332] xfs_alloc_read_agf+0x10f/0x230 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_alloc_read_agf+0x10f/0x230 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4222333/5385332] xfs_alloc_pagf_init+0x1c/0x40 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_alloc_pagf_init+0x1c/0x40 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4222333/5385332] xfs_alloc_pagf_init+0x1c/0x40 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_alloc_pagf_init+0x1c/0x40 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4222333/5385332] xfs_alloc_pagf_init+0x1c/0x40 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_alloc_pagf_init+0x1c/0x40 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4320833/5385332] xfs_bmapi+0x3100/0x3360 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_bmapi+0x3100/0x3360 [xfs] Nov 12 19:44:22 dcs4apb kernel: [as_remove_request+0/368] as_remove_request+0x0/0x170 Nov 12 19:44:22 dcs4apb kernel: [] as_remove_request+0x0/0x170 Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4324659/5385332] xfs_bmbt_get_state+0x12/0x30 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_bmbt_get_state+0x12/0x30 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4299114/5385332] xfs_bmap_do_search_extents+0xe9/0x410 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_bmap_do_search_extents+0xe9/0x410 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4300035/5385332] xfs_bmap_search_extents+0x72/0x90 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_bmap_search_extents+0x72/0x90 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4309034/5385332] xfs_bmapi+0x2e9/0x3360 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_bmapi+0x2e9/0x3360 [xfs] Nov 12 19:44:22 dcs4apb kernel: [recalc_task_prio+423/1008] recalc_task_prio+0x1a7/0x3f0 Nov 12 19:44:22 dcs4apb kernel: [] recalc_task_prio+0x1a7/0x3f0 Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4509115/5385332] xlog_grant_push_ail+0x4a/0x1b0 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xlog_grant_push_ail+0x4a/0x1b0 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4537652/5385332] xfs_mod_incore_sb_batch+0x43/0x90 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_mod_incore_sb_batch+0x43/0x90 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4557763/5385332] xfs_trans_unreserve_and_mod_sb+0x172/0x180 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_trans_unreserve_and_mod_sb+0x172/0x180 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4277106/5385332] xfs_bmap_last_offset+0x81/0x140 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_bmap_last_offset+0x81/0x140 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4613826/5385332] xfs_iomap_write_allocate+0x261/0x4a0 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_iomap_write_allocate+0x261/0x4a0 [xfs] Nov 12 19:44:22 dcs4apb kernel: [elv_merged_request+10/32] elv_merged_request+0xa/0x20 Nov 12 19:44:22 dcs4apb kernel: [] elv_merged_request+0xa/0x20 Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4611385/5385332] xfs_iomap+0x6d8/0x7e0 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_iomap+0x6d8/0x7e0 [xfs] Nov 12 19:44:22 dcs4apb kernel: [try_to_free_buffers+104/176] try_to_free_buffers+0x68/0xb0 Nov 12 19:44:22 dcs4apb kernel: [] try_to_free_buffers+0x68/0xb0 Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4617410/5385332] xfs_map_blocks+0x61/0x140 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_map_blocks+0x61/0x140 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_map_blocks+0x61/0x140 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4621933/5385332] xfs_page_state_convert+0x6cc/0x840 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_page_state_convert+0x6cc/0x840 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4622941/5385332] linvfs_writepage+0x6c/0x110 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] linvfs_writepage+0x6c/0x110 [xfs] Nov 12 19:44:22 dcs4apb kernel: [mpage_writepages+707/2784] mpage_writepages+0x2c3/0xae0 Nov 12 19:44:22 dcs4apb kernel: [] mpage_writepages+0x2c3/0xae0 Nov 12 19:44:22 dcs4apb kernel: [smp_apic_timer_interrupt+234/352] smp_apic_timer_interrupt+0xea/0x160 Nov 12 19:44:22 dcs4apb kernel: [] smp_apic_timer_interrupt+0xea/0x160 Nov 12 19:44:22 dcs4apb kernel: [apic_timer_interrupt+26/32] apic_timer_interrupt+0x1a/0x20 Nov 12 19:44:22 dcs4apb kernel: [] apic_timer_interrupt+0x1a/0x20 Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4622833/5385332] linvfs_writepage+0x0/0x110 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] linvfs_writepage+0x0/0x110 [xfs] Nov 12 19:44:22 dcs4apb kernel: [recalc_task_prio+423/1008] recalc_task_prio+0x1a7/0x3f0 Nov 12 19:44:22 dcs4apb kernel: [] recalc_task_prio+0x1a7/0x3f0 Nov 12 19:44:22 dcs4apb kernel: [find_get_page+22/64] find_get_page+0x16/0x40 Nov 12 19:44:22 dcs4apb kernel: [] find_get_page+0x16/0x40 Nov 12 19:44:22 dcs4apb kernel: [__filemap_fdatawrite_range+219/256] __filemap_fdatawrite_range+0xdb/0x100 Nov 12 19:44:22 dcs4apb kernel: [] __filemap_fdatawrite_range+0xdb/0x100 Nov 12 19:44:22 dcs4apb kernel: [filemap_fdatawrite+34/48] filemap_fdatawrite+0x22/0x30 Nov 12 19:44:22 dcs4apb kernel: [] filemap_fdatawrite+0x22/0x30 Nov 12 19:44:22 dcs4apb kernel: [filemap_write_and_wait+23/48] filemap_write_and_wait+0x17/0x30 Nov 12 19:44:22 dcs4apb kernel: [] filemap_write_and_wait+0x17/0x30 Nov 12 19:44:22 dcs4apb kernel: [__generic_file_aio_write_nolock+3131/3216] __generic_file_aio_write_nolock+0xc3b/0xc90 Nov 12 19:44:22 dcs4apb kernel: [] __generic_file_aio_write_nolock+0xc3b/0xc90 Nov 12 19:44:22 dcs4apb kernel: [generic_file_aio_write_nolock+80/208] generic_file_aio_write_nolock+0x50/0xd0 Nov 12 19:44:22 dcs4apb kernel: [] generic_file_aio_write_nolock+0x50/0xd0 Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4641578/5385332] xfs_write+0x2b9/0x790 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] xfs_write+0x2b9/0x790 [xfs] Nov 12 19:44:22 dcs4apb kernel: [__crc_device_suspend+4623944/5385332] linvfs_write+0x97/0xd0 [xfs] Nov 12 19:44:22 dcs4apb kernel: [] linvfs_write+0x97/0xd0 [xfs] Nov 12 19:44:22 dcs4apb kernel: [do_sync_write+172/256] do_sync_write+0xac/0x100 Nov 12 19:44:22 dcs4apb kernel: [] do_sync_write+0xac/0x100 Nov 12 19:44:22 dcs4apb kernel: [get_futex_key+67/448] get_futex_key+0x43/0x1c0 Nov 12 19:44:22 dcs4apb kernel: [] get_futex_key+0x43/0x1c0 Nov 12 19:44:22 dcs4apb kernel: [autoremove_wake_function+0/64] autoremove_wake_function+0x0/0x40 Nov 12 19:44:22 dcs4apb kernel: [] autoremove_wake_function+0x0/0x40 Nov 12 19:44:22 dcs4apb kernel: [do_futex+744/1632] do_futex+0x2e8/0x660 Nov 12 19:44:22 dcs4apb kernel: [] do_futex+0x2e8/0x660 Nov 12 19:44:22 dcs4apb kernel: [__do_softirq+98/208] __do_softirq+0x62/0xd0 Nov 12 19:44:22 dcs4apb kernel: [] __do_softirq+0x62/0xd0 Nov 12 19:44:22 dcs4apb kernel: [vfs_write+194/320] vfs_write+0xc2/0x140 Nov 12 19:44:22 dcs4apb kernel: [] vfs_write+0xc2/0x140 Nov 12 19:44:22 dcs4apb kernel: [sys_write+145/240] sys_write+0x91/0xf0 Nov 12 19:44:22 dcs4apb kernel: [] sys_write+0x91/0xf0 Nov 12 19:44:22 dcs4apb kernel: [do_gettimeofday+32/196] do_gettimeofday+0x20/0xc4 Nov 12 19:44:22 dcs4apb kernel: [] do_gettimeofday+0x20/0xc4 Nov 12 19:44:22 dcs4apb kernel: [sysenter_past_esp+82/121] sysenter_past_esp+0x52/0x79 Nov 12 19:44:22 dcs4apb kernel: [] sysenter_past_esp+0x52/0x79 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sat Nov 13 07:03:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 13 Nov 2004 07:03:43 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iADF3aWL028760 for ; Sat, 13 Nov 2004 07:03:36 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iADF3agD028759 for linux-xfs@oss.sgi.com; Sat, 13 Nov 2004 07:03:36 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iADF3Yf2028745 for ; Sat, 13 Nov 2004 07:03:34 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iADEP2Jf027418; Sat, 13 Nov 2004 06:25:02 -0800 Date: Sat, 13 Nov 2004 06:25:02 -0800 Message-Id: <200411131425.iADEP2Jf027418@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 345] Memory allocation failure X-Bugzilla-Reason: AssignedTo X-archive-position: 4423 X-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: 12165 Lines: 220 http://oss.sgi.com/bugzilla/show_bug.cgi?id=345 ------- Additional Comments From zaphodb@zaphods.net 2004-13-11 06:25 PDT ------- Hi, i am now seeing the same XFS_WANT_CORRUPTED_GOTO internal errors as in Tickets 329 and 332 _but_ after having trouble with current linux 2.6 vm. Read LKML Thread "Kernel 2.6.9 Multiple Page Allocation Failures (Part 2)" about it. Btw. mine is a heavy duty p2p application, too. ;) So essentially after getting loads of these: Nov 13 07:03:07 kernel kernel: peercache: page allocation failure. order:5, mode:0xd0 Nov 13 07:03:08 kernel kernel: [__alloc_pages+417/800] __alloc_pages+0x1a1/0x320 Nov 13 07:03:08 kernel kernel: [__get_free_pages+24/48] __get_free_pages+0x18/0x30 Nov 13 07:03:08 kernel kernel: [kmem_getpages+24/192] kmem_getpages+0x18/0xc0 Nov 13 07:03:08 kernel kernel: [cache_grow+157/304] cache_grow+0x9d/0x130 Nov 13 07:03:08 kernel kernel: [pg0+946041681/1069024256] ip_ct_refresh_acct+0x71/0x80 [ip_conntrack] Nov 13 07:03:08 kernel kernel: [cache_alloc_refill+363/544] cache_alloc_refill+0x16b/0x220 Nov 13 07:03:08 kernel kernel: [__kmalloc+122/144] __kmalloc+0x7a/0x90 Nov 13 07:03:08 kernel kernel: [kmem_alloc+75/192] kmem_alloc+0x4b/0xc0 Nov 13 07:03:08 kernel kernel: [ip_finish_output2+0/416] ip_finish_output2+0x0/0x1a0 Nov 13 07:03:08 kernel kernel: [xfs_iread_extents+71/240] xfs_iread_extents+0x47/0xf0 Nov 13 07:03:08 kernel kernel: [xfs_bmapi+548/5264] xfs_bmapi+0x224/0x1490 Nov 13 07:03:08 kernel kernel: [ip_finish_output2+0/416] ip_finish_output2+0x0/0x1a0 Nov 13 07:03:08 kernel kernel: [dst_output+0/32] dst_output+0x0/0x20 Nov 13 07:03:08 kernel kernel: [dst_output+0/32] dst_output+0x0/0x20 Nov 13 07:03:08 kernel kernel: [dst_output+11/32] dst_output+0xb/0x20 Nov 13 07:03:08 kernel kernel: [nf_hook_slow+178/240] nf_hook_slow+0xb2/0xf0 Nov 13 07:03:08 kernel kernel: [dst_output+0/32] dst_output+0x0/0x20 Nov 13 07:03:08 kernel kernel: [tcp_write_xmit+639/656] tcp_write_xmit+0x27f/0x290 Nov 13 07:03:08 kernel kernel: [tcp_transmit_skb+987/1712] tcp_transmit_skb+0x3db/0x6b0 Nov 13 07:03:08 kernel kernel: [__mod_timer+231/288] __mod_timer+0xe7/0x120 Nov 13 07:03:08 kernel kernel: [sk_reset_timer+12/32] sk_reset_timer+0xc/0x20 Nov 13 07:03:08 kernel kernel: [tcp_write_xmit+415/656] tcp_write_xmit+0x19f/0x290 Nov 13 07:03:08 kernel kernel: [xfs_iomap+388/1168] xfs_iomap+0x184/0x490 Nov 13 07:03:08 kernel kernel: [__tcp_data_snd_check+206/224] __tcp_data_snd_check+0xce/0xe0 Nov 13 07:03:08 kernel kernel: [__kfree_skb+159/320] __kfree_skb+0x9f/0x140 Nov 13 07:03:08 kernel kernel: [linvfs_get_block_core+126/752] linvfs_get_block_core+0x7e/0x2f0 Nov 13 07:03:08 kernel kernel: [tcp_v4_rcv+1547/2224] tcp_v4_rcv+0x60b/0x8b0 Nov 13 07:03:08 kernel kernel: [linvfs_get_block+41/64] linvfs_get_block+0x29/0x40 Nov 13 07:03:08 kernel kernel: [do_mpage_readpage+793/816] do_mpage_readpage+0x319/0x330 Nov 13 07:03:08 kernel kernel: [radix_tree_node_alloc+16/80] radix_tree_node_alloc+0x10/0x50 Nov 13 07:03:08 kernel kernel: [radix_tree_insert+218/256] radix_tree_insert+0xda/0x100 Nov 13 07:03:08 kernel kernel: [add_to_page_cache+180/192] add_to_page_cache+0xb4/0xc0 Nov 13 07:03:08 kernel kernel: [mpage_readpages+145/256] mpage_readpages+0x91/0x100 Nov 13 07:03:08 kernel kernel: [linvfs_get_block+0/64] linvfs_get_block+0x0/0x40 Nov 13 07:03:08 kernel kernel: [ip_rcv_finish+0/624] ip_rcv_finish+0x0/0x270 Nov 13 07:03:08 kernel kernel: [ip_rcv+997/1168] ip_rcv+0x3e5/0x490 Nov 13 07:03:08 kernel kernel: [linvfs_readpages+0/32] linvfs_readpages+0x0/0x20 Nov 13 07:03:08 kernel kernel: [read_pages+224/240] read_pages+0xe0/0xf0 Nov 13 07:03:08 kernel kernel: [linvfs_get_block+0/64] linvfs_get_block+0x0/0x40 Nov 13 07:03:08 kernel kernel: [__alloc_pages+435/800] __alloc_pages+0x1b3/0x320 Nov 13 07:03:08 kernel kernel: [do_page_cache_readahead+266/384] do_page_cache_readahead+0x10a/0x180 Nov 13 07:03:08 kernel kernel: [page_cache_readahead+238/464] page_cache_readahead+0xee/0x1d0 Nov 13 07:03:08 kernel kernel: [do_generic_mapping_read+336/1120] do_generic_mapping_read+0x150/0x460 Nov 13 07:03:08 kernel kernel: [__generic_file_aio_read+474/528] __generic_file_aio_read+0x1da/0x210 Nov 13 07:03:08 kernel kernel: [file_read_actor+0/208] file_read_actor+0x0/0xd0 Nov 13 07:03:08 kernel kernel: [xfs_read+371/688] xfs_read+0x173/0x2b0 Nov 13 07:03:08 kernel kernel: [linvfs_read+120/144] linvfs_read+0x78/0x90 Nov 13 07:03:08 kernel kernel: [do_sync_read+161/224] do_sync_read+0xa1/0xe0 Nov 13 07:03:08 kernel kernel: [linvfs_open+96/112] linvfs_open+0x60/0x70 Nov 13 07:03:08 kernel kernel: [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 Nov 13 07:03:08 kernel kernel: [filp_open+76/80] filp_open+0x4c/0x50 Nov 13 07:03:08 kernel kernel: [vfs_read+205/288] vfs_read+0xcd/0x120 Nov 13 07:03:08 kernel kernel: [copy_to_user+50/80] copy_to_user+0x32/0x50 Nov 13 07:03:08 kernel kernel: [sys_read+71/128] sys_read+0x47/0x80 Nov 13 07:03:08 kernel kernel: [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 Nov 13 07:03:08 kernel kernel: DMA per-cpu: Nov 13 07:03:08 kernel kernel: cpu 0 hot: low 2, high 6, batch 1 Nov 13 07:03:08 kernel kernel: cpu 0 cold: low 0, high 2, batch 1 Nov 13 07:03:08 kernel kernel: cpu 1 hot: low 2, high 6, batch 1 Nov 13 07:03:08 kernel kernel: cpu 1 cold: low 0, high 2, batch 1 Nov 13 07:03:08 kernel kernel: Normal per-cpu: Nov 13 07:03:08 kernel kernel: cpu 0 hot: low 32, high 96, batch 16 Nov 13 07:03:08 kernel kernel: cpu 0 cold: low 0, high 32, batch 16 Nov 13 07:03:08 kernel kernel: cpu 1 hot: low 32, high 96, batch 16 Nov 13 07:03:08 kernel kernel: cpu 1 cold: low 0, high 32, batch 16 Nov 13 07:03:08 kernel kernel: HighMem per-cpu: Nov 13 07:03:08 kernel kernel: cpu 0 hot: low 32, high 96, batch 16 Nov 13 07:03:08 kernel kernel: cpu 0 cold: low 0, high 32, batch 16 Nov 13 07:03:08 kernel kernel: cpu 1 hot: low 32, high 96, batch 16 Nov 13 07:03:08 kernel kernel: cpu 1 cold: low 0, high 32, batch 16 Nov 13 07:03:08 kernel kernel: Nov 13 07:03:08 kernel kernel: Free pages: 66592kB (512kB HighMem) Nov 13 07:03:08 kernel kernel: Active:587182 inactive:357103 dirty:30469 writeback:0 unstable:0 free:16648 slab:48204 mapped:527622 pagetables:1318 Nov 13 07:03:08 kernel kernel: DMA free:1168kB min:1168kB low:1460kB high:1752kB active:3464kB inactive:3720kB present:16384kB pages_scanned:32 all_unreclaimable? no Nov 13 07:03:08 kernel kernel: protections[]: 0 0 0 Nov 13 07:03:08 kernel kernel: Normal free:66064kB min:64360kB low:80448kB high:96540kB active:320864kB inactive:277564kB present:901120kB pages_scanned:0 all_unreclaimable? no Nov 13 07:03:08 kernel kernel: protections[]: 0 0 0 Nov 13 07:03:08 kernel kernel: HighMem free:896kB min:512kB low:640kB high:768kB active:2022656kB inactive:1147140kB present:3178432kB pages_scanned:0 all_unreclaimable? no Nov 13 07:03:08 kernel kernel: protections[]: 0 0 0 Nov 13 07:03:08 kernel kernel: DMA: 3*4kB 0*8kB 1*16kB 12*32kB 4*64kB 2*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1180kB Nov 13 07:03:08 kernel kernel: Normal: 1814*4kB 99*8kB 642*16kB 478*32kB 119*64kB 7*128kB 2*256kB 1*512kB 6*1024kB 1*2048kB 5*4096kB = 71824kB Nov 13 07:03:08 kernel kernel: HighMem: 0*4kB 0*8kB 4*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 512kB Nov 13 07:03:08 kernel kernel: Swap cache: add 183932, delete 102820, find 77182/95633, race 0+0 i got these: Nov 13 07:04:17 kernel kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 359 of file fs/xfs/xfs_alloc.c. Caller 0xc01b17bc Nov 13 07:04:17 kernel kernel: [xfs_alloc_fixup_trees+432/736] xfs_alloc_fixup_trees+0x1b0/0x2e0 Nov 13 07:04:17 kernel kernel: [xfs_alloc_ag_vextent_near+796/2512] xfs_alloc_ag_vextent_near+0x31c/0x9d0 Nov 13 07:04:17 kernel kernel: [xfs_alloc_ag_vextent_near+796/2512] xfs_alloc_ag_vextent_near+0x31c/0x9d0 Nov 13 07:04:17 kernel kernel: [xfs_alloc_ag_vextent+266/272] xfs_alloc_ag_vextent+0x10a/0x110 Nov 13 07:04:17 kernel kernel: [xfs_alloc_vextent+739/912] xfs_alloc_vextent+0x2e3/0x390 Nov 13 07:04:17 kernel kernel: [xfs_bmap_alloc+2072/4800] xfs_bmap_alloc+0x818/0x12c0 Nov 13 07:04:17 kernel kernel: [scsi_request_fn+73/928] scsi_request_fn+0x49/0x3a0 Nov 13 07:04:17 kernel kernel: [elv_next_request+68/240] elv_next_request+0x44/0xf0 Nov 13 07:04:17 kernel kernel: [xfs_bmbt_get_state+18/48] xfs_bmbt_get_state+0x12/0x30 Nov 13 07:04:17 kernel kernel: [xfs_bmap_do_search_extents+230/1040] xfs_bmap_do_search_extents+0xe6/0x410 Nov 13 07:04:17 kernel kernel: [pagebuf_iorequest+147/320] pagebuf_iorequest+0x93/0x140 Nov 13 07:04:17 kernel kernel: [xfs_bmapi+1316/5264] xfs_bmapi+0x524/0x1490 Nov 13 07:04:17 kernel kernel: [_atomic_dec_and_lock+39/80] _atomic_dec_and_lock+0x27/0x50 Nov 13 07:04:17 kernel kernel: [pagebuf_rele+39/208] pagebuf_rele+0x27/0xd0 Nov 13 07:04:17 kernel kernel: [xfs_bmbt_get_state+18/48] xfs_bmbt_get_state+0x12/0x30 Nov 13 07:04:17 kernel kernel: [xfs_bmap_do_search_extents+790/1040] xfs_bmap_do_search_extents+0x316/0x410 Nov 13 07:04:17 kernel kernel: [xfs_bmap_last_offset+180/256] xfs_bmap_last_offset+0xb4/0x100 Nov 13 07:04:17 kernel kernel: [xfs_iomap_write_allocate+609/1264] xfs_iomap_write_allocate+0x261/0x4f0 Nov 13 07:04:17 kernel kernel: [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 Nov 13 07:04:17 kernel kernel: [bio_alloc+200/400] bio_alloc+0xc8/0x190 Nov 13 07:04:17 kernel kernel: [xfs_iomap+871/1168] xfs_iomap+0x367/0x490 Nov 13 07:04:17 kernel kernel: [find_trylock_page+70/96] find_trylock_page+0x46/0x60 Nov 13 07:04:17 kernel kernel: [xfs_map_blocks+69/128] xfs_map_blocks+0x45/0x80 Nov 13 07:04:17 kernel kernel: [xfs_page_state_convert+1241/1584] xfs_page_state_convert+0x4d9/0x630 Nov 13 07:04:17 kernel kernel: [scsi_request_fn+73/928] scsi_request_fn+0x49/0x3a0 Nov 13 07:04:17 kernel kernel: [radix_tree_gang_lookup_tag+73/112] radix_tree_gang_lookup_tag+0x49/0x70 Nov 13 07:04:17 kernel kernel: [linvfs_writepage+91/224] linvfs_writepage+0x5b/0xe0 Nov 13 07:04:17 kernel kernel: [mpage_writepages+571/896] mpage_writepages+0x23b/0x380 Nov 13 07:04:17 kernel kernel: [linvfs_writepage+0/224] linvfs_writepage+0x0/0xe0 Nov 13 07:04:17 kernel kernel: [__sync_single_inode+88/496] __sync_single_inode+0x58/0x1f0 Nov 13 07:04:17 kernel kernel: [__writeback_single_inode+96/320] __writeback_single_inode+0x60/0x140 Nov 13 07:04:17 kernel kernel: [smp_apic_timer_interrupt+95/208] smp_apic_timer_interrupt+0x5f/0xd0 Nov 13 07:04:17 kernel kernel: [apic_timer_interrupt+28/36] apic_timer_interrupt+0x1c/0x24 Nov 13 07:04:17 kernel kernel: [_atomic_dec_and_lock+39/80] _atomic_dec_and_lock+0x27/0x50 Nov 13 07:04:17 kernel kernel: [sync_sb_inodes+404/640] sync_sb_inodes+0x194/0x280 Nov 13 07:04:17 kernel kernel: [pdflush+0/32] pdflush+0x0/0x20 Nov 13 07:04:17 kernel kernel: [writeback_inodes+184/208] writeback_inodes+0xb8/0xd0 Nov 13 07:04:17 kernel kernel: [background_writeout+91/160] background_writeout+0x5b/0xa0 Nov 13 07:04:17 kernel kernel: [__pdflush+189/416] __pdflush+0xbd/0x1a0 Nov 13 07:04:17 kernel kernel: [pdflush+26/32] pdflush+0x1a/0x20 Nov 13 07:04:17 kernel kernel: [background_writeout+0/160] background_writeout+0x0/0xa0 Nov 13 07:04:17 kernel kernel: [pdflush+0/32] pdflush+0x0/0x20 Nov 13 07:04:17 kernel kernel: [kthread+156/176] kthread+0x9c/0xb0 Nov 13 07:04:17 kernel kernel: [kthread+0/176] kthread+0x0/0xb0 Nov 13 07:04:17 kernel kernel: [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18 and then finally these: Nov 13 07:04:17 kernel kernel: xfs_force_shutdown(sdd5,0x8) called from line 1091 of file fs/xfs/xfs_trans.c. Return address = 0xc0212e5c Nov 13 07:04:17 kernel kernel: Filesystem "sdd5": Corruption of in-memory data detected. Shutting down filesystem: sdd5 Nov 13 07:04:17 kernel kernel: Please umount the filesystem, and rectify the problem(s) The VM-issue is yet unresolved afaik but i really think these errors are slowing down the machine significantly. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sat Nov 13 10:12:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 13 Nov 2004 10:12:16 -0800 (PST) Received: from mail.g-house.de ([62.75.136.201]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iADICBYZ004091 for ; Sat, 13 Nov 2004 10:12:11 -0800 Received: from g163c.g.pppool.de ([80.185.22.60] helo=[192.168.10.11]) by mail.g-house.de with asmtp (Exim 4.34) id 1CT2Ja-0005wZ-Rr for linux-xfs@oss.sgi.com; Sat, 13 Nov 2004 19:07:59 +0100 Message-ID: <41964E51.70605@gmx.net> Date: Sat, 13 Nov 2004 19:11:29 +0100 From: Christian User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: sudden xfs errors with 2.6.10-rc1-bk19 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 3222 Lines: 101 hi, a few days ago i had to reboot the machine and i thought i could upgrade to a more recent kernel. i don't know if the following issue is related to this upgrade but as of now i can't mount my xfs fs any more. the hing is, i'm using loop-aes too and so xfs is on the loop device only: $ losetup -F /dev/loop7 Password: $ losetup -a /dev/loop7: [0805]:389 (/dev/sdb1) encryption=twofish128 multi-key $ mount -t xfs /dev/loop7 /data/Storage/ mount: wrong fs type, bad option, bad superblock on /dev/loop7, or too many mounted file systems so i've checked with "xfs_check -v /dev/loop7", because without "-v" the xfs_check returned no output (errorcode 0, so i assume no errors occured). the output of "xfs_check -v" is saved in http://www.nerdbynature.de/bits/sheep/2.6.10-rc1-bk19/xfs_check-loop7.log.bz2 (will be available after the bzip2 finished, it's pretty large...) xfs_repair did (sorry, long) -------------------------- root@sheep:~# xfs_repair -v /dev/loop7 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 2 tail block 2 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done -------------------------- however, i am still not able to mount this thing. this is all on debian/unstable (i386), xfsprogs-2.6.20. do you need more infos about this things? xfsdump or sth. like this? perhaps someone can give me a hint here what to do next. thank you very much, Christian. -- BOFH excuse #293: You must've hit the wrong any key. From owner-linux-xfs Sat Nov 13 10:44:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 13 Nov 2004 10:44:09 -0800 (PST) Received: from mail.g-house.de (ns1.g-housing.de [62.75.136.201]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iADIi5YQ004983 for ; Sat, 13 Nov 2004 10:44:06 -0800 Received: from g1f6a.g.pppool.de ([80.185.31.106] helo=[192.168.10.11]) by mail.g-house.de with asmtp (Exim 4.34) id 1CT2on-00064e-2F for linux-xfs@oss.sgi.com; Sat, 13 Nov 2004 19:40:13 +0100 Message-ID: <419655E0.3070300@gmx.net> Date: Sat, 13 Nov 2004 19:43:44 +0100 From: Christian User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: sudden xfs errors with 2.6.10-rc1-bk19 References: <41964E51.70605@gmx.net> In-Reply-To: <41964E51.70605@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4425 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 740 Lines: 27 i forgot a few things. this showed up once in the syslog too: xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc021427c XFS unmount got error 16 linvfs_put_super: vfsp/0xc324d260 left dangling! VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... and this is shown after an (unseccessful) mount: XFS: Filesystem loop7 has duplicate UUID - can't mount oh, the log from "xfs_check -v" is 11MB even as bzip2, but AFAICT the lines are just repeating. here's is the beginning and the end of the log: http://www.nerdbynature.de/bits/sheep/2.6.10-rc1-bk19/xfs_check-loop7_shortened.log thanks. Christian. -- BOFH excuse #293: You must've hit the wrong any key. From owner-linux-xfs Sat Nov 13 12:15:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 13 Nov 2004 12:15:46 -0800 (PST) Received: from mail.g-house.de (ns1.g-housing.de [62.75.136.201]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iADKFhIW007769 for ; Sat, 13 Nov 2004 12:15:44 -0800 Received: from g1f6a.g.pppool.de ([80.185.31.106] helo=[192.168.10.11]) by mail.g-house.de with asmtp (Exim 4.34) id 1CT4FS-0006XY-4M for linux-xfs@oss.sgi.com; Sat, 13 Nov 2004 21:11:50 +0100 Message-ID: <41966B5C.6090706@gmx.net> Date: Sat, 13 Nov 2004 21:15:24 +0100 From: Christian User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: sudden xfs errors with 2.6.10-rc1-bk19 References: <41964E51.70605@gmx.net> <419655E0.3070300@gmx.net> In-Reply-To: <419655E0.3070300@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4426 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 482 Lines: 17 um, i've forgotten to RTFM first and i've read http://oss.sgi.com/archives/linux-xfs/2004-02/msg00172.html now. yes, mounting with "-o nouuid" works and all files are there. "...sounds like a relatively har[m]less (but annoying) bug." can someone please verify the last sentence? just to get back the warm and fuzzy feeling when using this fs. or better yet: are the any updates on this issue? thanks and sorry for the noise, Christian -- BOFH excuse #95: Pentium FDIV bug From owner-linux-xfs Sat Nov 13 12:36:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 13 Nov 2004 12:36:08 -0800 (PST) Received: from mail.g-house.de (ns1.g-housing.de [62.75.136.201]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iADKa4kH011692 for ; Sat, 13 Nov 2004 12:36:05 -0800 Received: from g1f6a.g.pppool.de ([80.185.31.106] helo=[192.168.10.11]) by mail.g-house.de with asmtp (Exim 4.34) id 1CT4Z8-0006cm-VF for linux-xfs@oss.sgi.com; Sat, 13 Nov 2004 21:32:11 +0100 Message-ID: <41967020.7070201@g-house.de> Date: Sat, 13 Nov 2004 21:35:44 +0100 From: Christian User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: sudden xfs errors with 2.6.10-rc1-bk19 References: <41964E51.70605@gmx.net> <419655E0.3070300@gmx.net> <41966B5C.6090706@gmx.net> In-Reply-To: <41966B5C.6090706@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4427 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evil@g-house.de Precedence: bulk X-list: linux-xfs Content-Length: 746 Lines: 25 Christian wrote: > um, i've forgotten to RTFM first and i've read > http://oss.sgi.com/archives/linux-xfs/2004-02/msg00172.html > now. yes, mounting with "-o nouuid" works and all files are there. > ahem, too soon. after generating a new UUID, unmounting still gives: xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc021427c Filesystem "loop7": I/O Error Detected. Shutting down filesystem: loop7 Please umount the filesystem, and rectify the problem(s) but mount (without -o nouuid) gives: XFS mounting filesystem loop7 Ending clean XFS mount for filesystem: loop7 ...but it mounts successfully and i can access the fs. grrr, Christian. -- BOFH excuse #149: Dew on the telephone lines. From owner-linux-xfs Sat Nov 13 23:03:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 13 Nov 2004 23:03:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAE73cIf003878 for ; Sat, 13 Nov 2004 23:03:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAE73cpe003877 for linux-xfs@oss.sgi.com; Sat, 13 Nov 2004 23:03:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAE73be7003865 for ; Sat, 13 Nov 2004 23:03:37 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAE6YTjb002937; Sat, 13 Nov 2004 22:34:29 -0800 Date: Sat, 13 Nov 2004 22:34:29 -0800 Message-Id: <200411140634.iAE6YTjb002937@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 384] New: Missing compat ioctls X-Bugzilla-Reason: AssignedTo X-archive-position: 4428 X-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: 802 Lines: 29 http://oss.sgi.com/bugzilla/show_bug.cgi?id=384 Summary: Missing compat ioctls Product: Linux XFS Version: Current Platform: PPC OS/Version: Linux Status: NEW Severity: minor Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: jk@blackdown.de 32-bit xfs_fsr doesn't work on PPC64 kernels (2.6.10-rc1-mm5) due to missing 32-bit compat ioctls: $/usr/sbin/xfs_fsr /tmp /tmp start inode=0 unable to get handle: /tmp: Invalid argument $ dmesg | tail -1 ioctl32(xfs_fsr:10817): Unknown cmd fd(3) cmd(c01c5868){00} arg(ffffb440) on /tmp ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Nov 14 07:04:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Nov 2004 07:04:23 -0800 (PST) Received: from short4.org (82-147-17-1.dsl.uk.rapidplay.com [82.147.17.1]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAEF4FVj031152 for ; Sun, 14 Nov 2004 07:04:16 -0800 Received: (qmail 1973 invoked from network); 14 Nov 2004 15:06:45 -0000 Received: from unknown (HELO ?192.168.1.151?) (192.168.1.151) by 192.168.1.253 with SMTP; 14 Nov 2004 15:06:45 -0000 Message-ID: <419781A9.1090706@linux-corner.info> Date: Sun, 14 Nov 2004 16:02:49 +0000 From: Mark Watts User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS corruption on md raid-0 arrays Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4429 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: m.watts@linux-corner.info Precedence: bulk X-list: linux-xfs Content-Length: 15759 Lines: 437 I'm running XFS on Mandrake 10.0 (2.6.3 kernel). System is Athlon XP, 1GM ram, 2 x 40GB Maxtor ATA/66 drives connected to a SiI680 IDE controller. I have several linux software raid partitions, each being a raid-0 array with an XFS filesystem. /boot is on a small ext3 partition. Today, while using the system (which had been running just fine for a week), the XFS driver decided to shutdown /dev/md1 citing 'corruptions in memory data' or somesuch error. dmesg showed a stack trace. Thinking it may be fixable with a reboot, I rebooted, only to have /dev/md0 get shutdown too. When the system comes back up, I get the following on a serial console. Is this an XFS issue or is something wrong with the md arrays? And the big question: is it fixable? Cheers, Mark. Linux version 2.6.3-16mdk-i686-up-4GB (qateam@updates.mandrakesoft.com) (gcc version 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk4 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000d4000 - 00000000000da000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003fff0000 (usable) BIOS-e820: 000000003fff0000 - 000000003fff8000 (ACPI data) BIOS-e820: 000000003fff8000 - 0000000040000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000fb940 hm, page 000fb000 reserved twice. hm, page 000fc000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. On node 0 totalpages: 262128 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:16 HighMem zone: 32752 pages, LIFO batch:7 DMI 2.3 present. ACPI: RSDP (v000 AMI ) @ 0x000fa9d0 ACPI: RSDT (v001 AMIINT VIA_K7 0x00000010 MSFT 0x00000097) @ 0x3fff0000 ACPI: FADT (v001 AMIINT VIA_K7 0x00000011 MSFT 0x00000097) @ 0x3fff0030 ACPI: MADT (v001 AMIINT VIA_K7 0x00000009 MSFT 0x00000097) @ 0x3fff00c0 ACPI: DSDT (v001 VIA VIA_K7 0x00001000 MSFT 0x0100000d) @ 0x00000000 ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 16 ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0]) IOAPIC[0]: Assigned apic_id 2 IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, IRQ 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI BALANCE SET Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Built 1 zonelists Kernel command line: BOOT_IMAGE=263i686up4G-16 ro root=900 devfs=mount splash=silent ide=reverse console=ttyS0 bootsplash: silent mode. ide_setup: ide=reverse : Enabled support for IDE inverse scan order. Initializing CPU#0 PID hash table entries: 4096 (order 12: 32768 bytes) Detected 1760.202 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Memory: 1033256k/1048512k available (1955k kernel code, 14348k reserved, 850k data, 292k init, 131008k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 3481.60 BogoMIPS Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 478k freed CPU: CLK_CTL MSR was 6003d22f. Reprogramming to 2003d22f CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Athlon(tm) XP 2100+ stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: 00000080 ESR value after enabling vector: 00000000 ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=2 pin2=-1 Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 1759.0019 MHz. ..... host bus clock speed is 270.0618 MHz. NET: Registered protocol family 16 EISA bus registered PCI: PCI BIOS revision 2.10 entry at 0xfdaf1, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040211 Looking for DSDT in initrd ... not found! ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: Power Resource [URP1] (off) ACPI: Power Resource [URP2] (off) ACPI: Power Resource [FDDP] (off) ACPI: Power Resource [LPTP] (off) ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 *6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay PnPBIOS: Disabled testing the IO APIC....................... .................................... done. ACPI: No IRQ known for interrupt pin A of device 0000:00:11.1 - using IRQ 255 PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac) apm: overridden by ACPI. ikconfig 0.7 with /proc/config* highmem bounce pool size: 64 pages VFS: Disk quotas dquot_6.5.1 devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x1 Initializing Cryptographic API PCI: Via IRQ fixup for 0000:00:10.2, from 6 to 5 PCI: Via IRQ fixup for 0000:00:10.0, from 11 to 5 isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found pty: 1024 Unix98 ptys configured Serial: 8250/16550 driver $Revision: 1.90 $ 20 ports, IRQ sharing enabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:11.1 ACPI: No IRQ known for interrupt pin A of device 0000:00:11.1 - using IRQ 255 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci0000:00:11.1 ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio hda: MAXTOR 6L020J1, ATA DISK drive Using anticipatory io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: SONY CD-RW CRX300E, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 SiI680: IDE controller at PCI slot 0000:00:07.0 SiI680: chipset revision 1 SiI680: BASE CLOCK == 133 SiI680: 100% native mode on irq 19 ide2: MMIO-DMA , BIOS settings: hde:pio, hdf:pio ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio hde: Maxtor 94098U8, ATA DISK drive ide2 at 0xf8807f80-0xf8807f87,0xf8807f8a on irq 19 hdg: Maxtor 94098U8, ATA DISK drive ide3 at 0xf8807fc0-0xf8807fc7,0xf8807fca on irq 19 hda: max request size: 128KiB hda: 40132503 sectors (20547 MB) w/1819KiB Cache, CHS=39813/16/63, UDMA(133) /dev/ide/host0/bus0/target0/lun0: p1 hde: max request size: 64KiB hde: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(66) /dev/ide/host2/bus0/target0/lun0: p1 p2 < p5 p6 p7 > hdg: max request size: 64KiB hdg: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(66) /dev/ide/host2/bus1/target0/lun0: p1 p2 < p5 p6 p7 > mice: PS/2 mouse device common for all mice serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 input: AT Translated Set 2 keyboard on isa0060/serio0 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 EISA: Probing bus 0 at eisa0 NET: Registered protocol family 2 IP: routing cache hash table of 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) NET: Registered protocol family 1 BIOS EDD facility v0.13 2004-Mar-09, 3 devices found Please report your BIOS at http://linux.dell.com/edd/results.html ACPI: (supports S0 S1 S4 S5) md: Autodetecting RAID arrays. md: autorun ... md: considering hdg7 ... md: adding hdg7 ... md: hdg6 has different UUID to hdg7 md: adding hde7 ... md: hde6 has different UUID to hdg7 md: created mdX md: bind md: bind md: running: md: personality 2 is not loaded! md :do_md_run() returned -22 md: md1 stopped. md: unbind md: export_rdev(hdg7) md: unbind md: export_rdev(hde7) md: considering hdg6 ... md: adding hdg6 ... md: adding hde6 ... md: created md0 md: bind md: bind md: running: md: personality 2 is not loaded! md :do_md_run() returned -22 md: md0 stopped. md: unbind md: export_rdev(hdg6) md: unbind md: export_rdev(hde6) md: ... autorun DONE. RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). Mounted devfs on /dev Red Hat nash verSCSI subsystem initialized sion 3.5.18-mdk starting Loading scsi_mod.ko module Loading aic7xxx.ko module scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs Loading sd_mod.kmd: raid0 personality registered as nr 2 o module LoadinSGI XFS with ACLs, large block numbers, no debug enabled g raid0.ko modulSGI XFS Quota Management subsystem e Loading xfs.kmd: Autodetecting RAID arrays. o module Mountimd: autorun ... md: considering hde6 ... ng /proc filesysmd: adding hde6 ... tem Creating demd: adding hdg6 ... vice files Mounmd: hde7 has different UUID to hde6 md: hdg7 has different UUID to hde6 md: created md0 md: bind md: bind md: running: ting sysfs Actimd0: setting max_sectors to 128, segment boundary to 32767 raid0: looking at hde6 raid0: comparing hde6(5119488) with hde6(5119488) raid0: END raid0: ==> UNIQUE raid0: 1 zones raid0: looking at hdg6 raid0: comparing hdg6(5119488) with hde6(5119488) raid0: EQUAL raid0: FINAL 1 zones raid0: done. raid0 : md_size is 10238976 blocks. raid0 : conf->hash_spacing is 10238976 blocks. raid0 : nb_zone is 1. raid0 : Allocating 4 bytes for hash. vating md devicemd: considering hde7 ... s mknod: failedmd: adding hde7 ... to create /dev/md: adding hdg7 ... md: created md1 md: bind md: bind md: running: md0: 17 mknod: md1: setting max_sectors to 128, segment boundary to 32767 raid0: looking at hde7 raid0: comparing hde7(33979584) with hde7(33979584) raid0: END raid0: ==> UNIQUE raid0: 1 zones raid0: looking at hdg7 raid0: comparing hdg7(33979584) with hde7(33979584) raid0: EQUAL raid0: FINAL 1 zones raid0: done. raid0 : md_size is 67959168 blocks. raid0 : conf->hash_spacing is 67959168 blocks. raid0 : nb_zone is 1. raid0 : Allocating 4 bytes for hash. md: ... autorun DONE. failed to createXFS mounting filesystem md0 /dev/md/0: 17 Creating root device Mounting root filesystem Starting XFS recovery on filesystem: md0 (dev: md0) Filesystem "md0": XFS internal error xlog_valid_rec_header(1) at line 3485 of file fs/xfs/xfs_log_recover.c. Caller 0xf89c Call Trace: [] 0xf89bd40b [] 0xf89bd5ec [] 0xf89bd5ec [] i8042_interrupt+0xad/0x140 [] 0xf89bdf8b [] 0xf89be0b6 [] 0xf89be2d5 [] 0xf89b5064 [] 0xf89bfcad [] 0xf89d571c [] 0xf89db00d [] 0xf89bf080 [] 0xf89b0ebe [] 0xf89c7afd [] 0xf89dbce1 [] 0xf89dba9f [] snprintf+0x26/0x30 [] disk_name+0xa7/0xc0 [] sb_set_blocksize+0x20/0x60 [] get_sb_bdev+0x131/0x160 [] real_lookup+0xd3/0x100 [] 0xf89dbc8f [] 0xf89dba00 [] do_kern_mount+0x89/0x110 [] do_add_mount+0x84/0x190 [] __alloc_pages+0x9b/0x360 [] do_mount+0x182/0x1d0 [] __get_free_pages+0x33/0x40 [] copy_mount_options+0x81/0x100 [] sys_mount+0x8e/0xd0 [] sysenter_past_esp+0x52/0x71 XFS: log mount/recovery failed XFS: log mount failed mount: error 22 XFS mounting filesystem md0 mounting xfs flags defaults well, retrying without the option flags Starting XFS recovery on filesystem: md0 (dev: md0) Filesystem "md0": XFS internal error xlog_valid_rec_header(1) at line 3485 of file fs/xfs/xfs_log_recover.c. Caller 0xf89c Call Trace: [] 0xf89bd40b [] 0xf89bd5ec [] 0xf89bd5ec [] i8042_interrupt+0xad/0x140 [] 0xf89bdf8b [] 0xf89be0b6 [] 0xf89be2d5 [] 0xf89b5064 [] 0xf89bfcad [] 0xf89d571c [] 0xf89db00d [] 0xf89bf080 [] 0xf89b0ebe [] 0xf89c7afd [] 0xf89dbce1 [] 0xf89dba9f [] snprintf+0x26/0x30 [] disk_name+0xa7/0xc0 [] sb_set_blocksize+0x20/0x60 [] get_sb_bdev+0x131/0x160 [] 0xf89dbc8f [] 0xf89dba00 [] do_kern_mount+0x89/0x110 [] do_add_mount+0x84/0x190 [] __alloc_pages+0x9b/0x360 [] do_mount+0x182/0x1d0 [] __get_free_pages+0x33/0x40 [] copy_mount_options+0x81/0x100 [] sys_mount+0x8e/0xd0 [] sysenter_past_esp+0x52/0x71 XFS: log mount/recovery failed XFS: log mount failed mount: error 22 XFS mounting filesystem md0 mounting xfs well, retrying read-only without any flag Starting XFS recovery on filesystem: md0 (dev: md0) Filesystem "md0": XFS internal error xlog_valid_rec_header(1) at line 3485 of file fs/xfs/xfs_log_recover.c. Caller 0xf89c Call Trace: [] 0xf89bd40b [] 0xf89bd5ec [] 0xf89bd5ec [] i8042_interrupt+0xad/0x140 [] 0xf89bdf8b [] 0xf89be0b6 [] 0xf89be2d5 [] 0xf89b5064 [] 0xf89bfcad [] 0xf89d571c [] 0xf89db00d [] 0xf89bf080 [] 0xf89b0ebe [] 0xf89c7afd [] 0xf89dbce1 [] 0xf89dba9f [] snprintf+0x26/0x30 [] disk_name+0xa7/0xc0 [] sb_set_blocksize+0x20/0x60 [] get_sb_bdev+0x131/0x160 [] 0xf89dbc8f [] 0xf89dba00 [] do_kern_mount+0x89/0x110 [] do_add_mount+0x84/0x190 [] __alloc_pages+0x9b/0x360 [] do_mount+0x182/0x1d0 [] __get_free_pages+0x33/0x40 [] copy_mount_options+0x81/0x100 [] sys_mount+0x8e/0xd0 [] sysenter_past_esp+0x52/0x71 XFS: log mount/recovery failed XFS: log mount failed mount: error 22 mounting xfs pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2 Remounting devfs at correct place if necessary Mounted devfs on /dev Freeing unused kernel memory: 292k freed Kernel panic: No init found. Try passing init= option to kernel. From owner-linux-xfs Sun Nov 14 07:10:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Nov 2004 07:10:30 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [81.187.226.98]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAEFAQ4V031857 for ; Sun, 14 Nov 2004 07:10:26 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.42 #1 (Red Hat Linux)) id 1CTM0y-0001up-EF; Sun, 14 Nov 2004 15:10:04 +0000 Date: Sun, 14 Nov 2004 15:10:04 +0000 From: Christoph Hellwig To: Mark Watts Cc: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on md raid-0 arrays Message-ID: <20041114151003.GA7354@infradead.org> References: <419781A9.1090706@linux-corner.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <419781A9.1090706@linux-corner.info> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 4430 X-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: 200 Lines: 6 On Sun, Nov 14, 2004 at 04:02:49PM +0000, Mark Watts wrote: > I'm running XFS on Mandrake 10.0 (2.6.3 kernel). Please repdoruce with a current kernel. MD in early 2.6 kernels has been quite buggy. From owner-linux-xfs Sun Nov 14 08:05:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Nov 2004 08:05:53 -0800 (PST) Received: from exch01smtp11.hdi.tvcabo (smtp1.netcabo.pt [212.113.174.28]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAEG5mPF001320 for ; Sun, 14 Nov 2004 08:05:49 -0800 Received: from login.com.pt ([83.132.17.47]) by exch01smtp11.hdi.tvcabo with Microsoft SMTPSVC(6.0.3790.0); Sun, 14 Nov 2004 16:05:24 +0000 Received: from 192.168.1.106 (unknown [192.168.1.106]) by login.com.pt (Postfix) with ESMTP id 57D84EB3; Sun, 14 Nov 2004 16:16:46 +0000 (WET) From: Gustavo Homem To: linux-xfs@oss.sgi.com Subject: bug 280 / your patch Date: Sun, 14 Nov 2004 16:01:01 +0000 User-Agent: KMail/1.5.3 Cc: s.hetze@linux-ag.de, hch@xfs.org, sandeen@sgi.com, gustavo@login.com.pt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411141601.01782.gustavo@login.com.pt> X-OriginalArrivalTime: 14 Nov 2004 16:05:24.0284 (UTC) FILETIME=[BFDECFC0:01C4CA63] X-archive-position: 4431 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gustavo@login.com.pt Precedence: bulk X-list: linux-xfs Content-Length: 1485 Lines: 56 Hello, A message by Eric Sandeen, http://oss.sgi.com/archives/linux-xfs/2002-04/msg00234.html on Fri, 19 Apr 2002 14:49:53 -0500 suggests that http://oss.sgi.com/bugzilla/show_bug.cgi?id=280 was fixed. However this bug was opened a long time after, on 2003-09-15 08:35 PDT and is still marked as OPEN. I can reproduce this bug with kernel 2.4.22-21mdk. I took a look at the webCVS interface but I can't request version 1.335 of xfs_inode.c I also searched the mailing list archives for the history of this bug, but didn't find more information. Can someone tell me the status of this ? Best regards Gustavo P.S.: This bug causes the following problem: If you try to create per-directory quotas you can: 1- create a directory, say "articles" 2- create a special quota group for that directory, articles_quota 3- turn on that directories SGID bit and change the group ownership to the special quota group (theoreticaly all the created files will now belong to the group articles_quota so the directory will never grow more than desired) 4- control the directory acess rights via ACLs (we don't want to add all users to the quota group of each directory, they must rather belong to their natural groups, ex: writers, photographers, editors, reviewers) Of course if the the directories created inside "articles" do not inherit the SGID bit, the files created inside will not belong to articles_quota and "articles" will be able to grow with no limit.... From owner-linux-xfs Sun Nov 14 08:58:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Nov 2004 08:58:06 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAEGvxVe006365 for ; Sun, 14 Nov 2004 08:58:00 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAEGvexT009981 for ; Sun, 14 Nov 2004 10:57:41 -0600 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAEGvcad1563700; Sun, 14 Nov 2004 08:57:39 -0800 (PST) Message-ID: <41978E82.5030902@sgi.com> Date: Sun, 14 Nov 2004 10:57:38 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gustavo Homem CC: linux-xfs@oss.sgi.com, s.hetze@linux-ag.de, hch@xfs.org Subject: Re: bug 280 / your patch References: <200411141601.01782.gustavo@login.com.pt> In-Reply-To: <200411141601.01782.gustavo@login.com.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4432 X-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: 5819 Lines: 156 Gustavo Homem wrote: > Hello, > > A message by Eric Sandeen, > > http://oss.sgi.com/archives/linux-xfs/2002-04/msg00234.html > > on > > Fri, 19 Apr 2002 14:49:53 -0500 > > suggests that > > http://oss.sgi.com/bugzilla/show_bug.cgi?id=280 > > was fixed. Well, I think that one is slightly different. However this bug was opened a long time after, on > > 2003-09-15 08:35 PDT > > and is still marked as OPEN. I can reproduce this bug with kernel > 2.4.22-21mdk. Just to be sure, if you could check it in the latest cvs kernel, or even the latest kernel.org kernel, that would be useful information. > I took a look at the webCVS interface but I can't request version 1.335 of > xfs_inode.c Here is the patch as it was checked in in 2002. However, I don't think it addresses the aclc problem: =========================================================================== linux/Documentation/filesystems/xfs.txt =========================================================================== --- a/linux/Documentation/filesystems/xfs.txt 2004-11-14 10:49:21.000000000 -0600 +++ b/linux/Documentation/filesystems/xfs.txt 2004-11-14 10:49:21.000000000 -0600 @@ -32,6 +32,12 @@ dmapi/xdsm Enable the DMAPI (Data Management API) event callouts. + irixsgid + Do not inherit the ISGID bit on subdirectories of ISGID + directories, if the process creating the subdirectory + is not a member of the parent directory group ID. + This matches IRIX behavior. + logbufs=value Set the number of in-memory log buffers. Valid numbers range from 2-8 inclusive. =========================================================================== linux/fs/xfs/linux/xfs_super.c =========================================================================== --- a/linux/fs/xfs/linux/xfs_super.c 2004-11-14 10:49:21.000000000 -0600 +++ b/linux/fs/xfs/linux/xfs_super.c 2004-11-14 10:49:21.000000000 -0600 @@ -113,6 +113,7 @@ #define MNTOPT_RO "ro" /* read only */ #define MNTOPT_RW "rw" /* read/write */ #define MNTOPT_NOUUID "nouuid" /* Ignore FS uuid */ +#define MNTOPT_IRIXSGID "irixsgid" /* Irix-style sgid inheritance */ STATIC int xfs_parseargs( @@ -239,6 +240,8 @@ args->flags |= MS_NOSUID; } else if (!strcmp(this_char, MNTOPT_NOUUID)) { args->flags |= XFSMNT_NOUUID; + } else if (!strcmp(this_char, MNTOPT_IRIXSGID)) { + args->flags |= XFSMNT_IRIXSGID; } else { printk("XFS: unknown mount option [%s].\n", this_char); return rval; =========================================================================== linux/fs/xfs/xfs_clnt.h =========================================================================== --- a/linux/fs/xfs/xfs_clnt.h 2004-11-14 10:49:21.000000000 -0600 +++ b/linux/fs/xfs/xfs_clnt.h 2004-11-14 10:49:21.000000000 -0600 @@ -123,6 +123,7 @@ #define XFSMNT_NOUUID 0x01000000 /* Ignore fs uuid */ #define XFSMNT_32BITINODES 0x02000000 /* restrict inodes to 32 * bits of address space */ +#define XFSMNT_IRIXSGID 0x04000000 /* Irix-style sgid inheritance */ /* Did we get any args for CXFS to consume? */ #define XFSARGS_FOR_CXFSARR(ap) \ =========================================================================== linux/fs/xfs/xfs_inode.c =========================================================================== --- a/linux/fs/xfs/xfs_inode.c 2004-11-14 10:49:21.000000000 -0600 +++ b/linux/fs/xfs/xfs_inode.c 2004-11-14 10:49:21.000000000 -0600 @@ -1098,10 +1098,11 @@ /* * If the group ID of the new file does not match the effective group * ID or one of the supplementary group IDs, the ISGID bit is - * cleared. + * cleared if the "irixsgid" mount option is set. */ if (ip->i_d.di_mode & ISGID) { - if (!in_group_p((gid_t)ip->i_d.di_gid) && !capable(CAP_FSETID)){ + if (!in_group_p((gid_t)ip->i_d.di_gid) + && (ip->i_mount->m_flags & XFS_MOUNT_IRIXSGID)) { ip->i_d.di_mode &= ~ISGID; } } =========================================================================== linux/fs/xfs/xfs_mount.h =========================================================================== --- a/linux/fs/xfs/xfs_mount.h 2004-11-14 10:49:21.000000000 -0600 +++ b/linux/fs/xfs/xfs_mount.h 2004-11-14 10:49:21.000000000 -0600 @@ -341,6 +341,7 @@ #define XFS_MOUNT_NOUUID 0x00004000 /* ignore uuid during mount */ #define XFS_MOUNT_32BITINODES 0x00008000 /* do not create inodes above * 32 bits in size */ +#define XFS_MOUNT_IRIXSGID 0x00010000 /* Irix-style sgid inheritance */ /* * Flags for m_cxfstype =========================================================================== linux/fs/xfs/xfs_vfsops.c =========================================================================== --- a/linux/fs/xfs/xfs_vfsops.c 2004-11-14 10:49:21.000000000 -0600 +++ b/linux/fs/xfs/xfs_vfsops.c 2004-11-14 10:49:21.000000000 -0600 @@ -363,6 +363,9 @@ if (ap->flags & XFSMNT_32BITINODES) mp->m_flags |= XFS_MOUNT_32BITINODES; + if (ap->flags & XFSMNT_IRIXSGID) + mp->m_flags |= XFS_MOUNT_IRIXSGID; + if (ap->flags & XFSMNT_IOSIZE) { if (ap->iosizelog > XFS_MAX_IO_LOG || ap->iosizelog < XFS_MIN_IO_LOG) { From owner-linux-xfs Sun Nov 14 10:03:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Nov 2004 10:03:46 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAEI3fnB008243 for ; Sun, 14 Nov 2004 10:03:41 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAEI3ent008242 for linux-xfs@oss.sgi.com; Sun, 14 Nov 2004 10:03:40 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAEI3dAc008230 for ; Sun, 14 Nov 2004 10:03:39 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAEHXRde007417; Sun, 14 Nov 2004 09:33:27 -0800 Date: Sun, 14 Nov 2004 09:33:27 -0800 Message-Id: <200411141733.iAEHXRde007417@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 385] New: xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c X-Bugzilla-Reason: AssignedTo X-archive-position: 4433 X-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: 4767 Lines: 142 http://oss.sgi.com/bugzilla/show_bug.cgi?id=385 Summary: xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c Product: Linux XFS Version: Current Platform: IA32 URL: http://www.nerdbynature.de/bits/sheep/2.6.10-rc1-bk19/ OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: evilninja@gmx.net [ i sent this to the linux-xfs ml, but i decided to file a bug now, because it is still not unresolved - as i thought before ] a few days ago i had to reboot the machine and i thought i could upgrade to a more recent kernel. i don't know if the following issue is related to this upgrade but as of now i can't mount my xfs fs any more. the hing is, i'm using loop-aes too and so xfs is on the loop device only: $ losetup -F /dev/loop7 Password: $ losetup -a /dev/loop7: [0805]:389 (/dev/sdb1) encryption=twofish128 multi-key $ mount -t xfs /dev/loop7 /data/Storage/ mount: wrong fs type, bad option, bad superblock on /dev/loop7, or too many mounted file systems so i've checked with "xfs_check -v /dev/loop7", because without "-v" the xfs_check returned no output (errorcode 0, so i assume no errors occured). the output of "xfs_check -v" is saved in http://www.nerdbynature.de/bits/sheep/2.6.10-rc1-bk19/xfs_check-loop7.log.bz2 (will be available after the bzip2 finished, it's pretty large...) xfs_repair did (sorry, long) -------------------------- root@sheep:~# xfs_repair -v /dev/loop7 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 2 tail block 2 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done -------------------------- this showed up once in the syslog too: xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc021427c XFS unmount got error 16 linvfs_put_super: vfsp/0xc324d260 left dangling! VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... and this is shown after an (unseccessful) mount: XFS: Filesystem loop7 has duplicate UUID - can't mount after some RTFM i've read http://oss.sgi.com/archives/linux-xfs/2004-02/msg00172.html and i could mount the thing with -o nouuid. after generating a new UUID, unmounting still gives: xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc021427c Filesystem "loop7": I/O Error Detected. Shutting down filesystem: loop7 Please umount the filesystem, and rectify the problem(s) but mount (without -o nouuid) gives: XFS mounting filesystem loop7 Ending clean XFS mount for filesystem: loop7 this is all on debian/unstable (i386), xfsprogs-2.6.20. do you need more infos about this things? xfsdump or sth. like this? perhaps someone can give me a hint here what to do next. thanks, Christian. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Nov 14 11:16:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Nov 2004 11:16:59 -0800 (PST) Received: from exch01smtp09.hdi.tvcabo (smtp3.netcabo.pt [212.113.174.30]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAEJGsVp012181 for ; Sun, 14 Nov 2004 11:16:55 -0800 Received: from login.com.pt ([83.132.17.47]) by exch01smtp09.hdi.tvcabo with Microsoft SMTPSVC(6.0.3790.0); Sun, 14 Nov 2004 19:16:30 +0000 Received: from 192.168.1.106 (unknown [192.168.1.106]) by login.com.pt (Postfix) with ESMTP id EEF50EB3; Sun, 14 Nov 2004 19:28:38 +0000 (WET) From: Gustavo Homem To: Eric Sandeen Subject: Re: bug 280 / your patch Date: Sun, 14 Nov 2004 19:12:06 +0000 User-Agent: KMail/1.5.3 Cc: linux-xfs@oss.sgi.com, s.hetze@linux-ag.de, hch@xfs.org, core@login.com.pt References: <200411141601.01782.gustavo@login.com.pt> <41978E82.5030902@sgi.com> In-Reply-To: <41978E82.5030902@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411141912.06172.gustavo@login.com.pt> X-OriginalArrivalTime: 14 Nov 2004 19:16:30.0226 (UTC) FILETIME=[721AB720:01C4CA7E] X-archive-position: 4434 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gustavo@login.com.pt Precedence: bulk X-list: linux-xfs Content-Length: 7601 Lines: 205 Hello, Thanks for your answer. On Sunday 14 November 2004 16:57, Eric Sandeen wrote: > Gustavo Homem wrote: > > Hello, > > > > A message by Eric Sandeen, > > > > http://oss.sgi.com/archives/linux-xfs/2002-04/msg00234.html > > > > on > > > > Fri, 19 Apr 2002 14:49:53 -0500 > > > > suggests that > > > > http://oss.sgi.com/bugzilla/show_bug.cgi?id=280 > > > > was fixed. > > Well, I think that one is slightly different. You are right, endeed. The bug is fixed if the directory doesn't contain any ACLs... I tried changing the values of /proc/sys/fs/xfs/irix_sgid_inherit and it works as expected if there are no ACLs on the main directory. Now that you sent your original patch I found that the related code on xfs_inode.c () is equal both on current CVS (Rev 1.406) and on the linux 2.4.22-mdk source: if (XFS_INHERIT_GID(pip, vp->v_vfsp)) { ip->i_d.di_gid = pip->i_d.di_gid; if ((pip->i_d.di_mode & S_ISGID) && (mode & S_IFMT) == S_IFDIR) { ip->i_d.di_mode |= S_ISGID; } } // what may be wrong here ? Might something be wrong with "mode" (because of // the ACLs) so that (mode & S_IFMT) != S_FDIR ? // it is important to note that if the user creating the file belongs to the // directory group s-inheritance will work regardless of ACLs being present // or not. How is mode affected by this ? // ******** doesn't matter if irix_sgid_inherit equals 0 ******** /* * If the group ID of the new file does not match the effective group * ID or one of the supplementary group IDs, the S_ISGID bit is cleared * (and only if the irix_sgid_inherit compatibility variable is set). */ if ((irix_sgid_inherit) && (ip->i_d.di_mode & S_ISGID) && (!in_group_p((gid_t)ip->i_d.di_gid))) { ip->i_d.di_mode &= ~S_ISGID; } // ******** / doesn't matter if irix_sgid_inherit equals 0 ******** Thank you very much Gustavo > > However this bug was opened a long time after, on > > > 2003-09-15 08:35 PDT > > > > and is still marked as OPEN. I can reproduce this bug with kernel > > 2.4.22-21mdk. > > Just to be sure, if you could check it in the latest cvs kernel, or even > the latest kernel.org kernel, that would be useful information. > > > I took a look at the webCVS interface but I can't request version 1.335 > > of xfs_inode.c > > Here is the patch as it was checked in in 2002. However, I don't think > it addresses the aclc problem: > > =========================================================================== > linux/Documentation/filesystems/xfs.txt > =========================================================================== > > --- a/linux/Documentation/filesystems/xfs.txt 2004-11-14 > 10:49:21.000000000 -0600 > +++ b/linux/Documentation/filesystems/xfs.txt 2004-11-14 > 10:49:21.000000000 -0600 > @@ -32,6 +32,12 @@ > dmapi/xdsm > Enable the DMAPI (Data Management API) event callouts. > > + irixsgid > + Do not inherit the ISGID bit on subdirectories of ISGID > + directories, if the process creating the subdirectory > + is not a member of the parent directory group ID. > + This matches IRIX behavior. > + > logbufs=value > Set the number of in-memory log buffers. Valid numbers range > from 2-8 inclusive. > > =========================================================================== > linux/fs/xfs/linux/xfs_super.c > =========================================================================== > > --- a/linux/fs/xfs/linux/xfs_super.c 2004-11-14 10:49:21.000000000 -0600 > +++ b/linux/fs/xfs/linux/xfs_super.c 2004-11-14 10:49:21.000000000 -0600 > @@ -113,6 +113,7 @@ > #define MNTOPT_RO "ro" /* read only */ > #define MNTOPT_RW "rw" /* read/write */ > #define MNTOPT_NOUUID "nouuid" /* Ignore FS uuid */ > +#define MNTOPT_IRIXSGID "irixsgid" /* Irix-style sgid inheritance */ > > STATIC int > xfs_parseargs( > @@ -239,6 +240,8 @@ > args->flags |= MS_NOSUID; > } else if (!strcmp(this_char, MNTOPT_NOUUID)) { > args->flags |= XFSMNT_NOUUID; > + } else if (!strcmp(this_char, MNTOPT_IRIXSGID)) { > + args->flags |= XFSMNT_IRIXSGID; > } else { > printk("XFS: unknown mount option [%s].\n", > this_char); > return rval; > > =========================================================================== > linux/fs/xfs/xfs_clnt.h > =========================================================================== > > --- a/linux/fs/xfs/xfs_clnt.h 2004-11-14 10:49:21.000000000 -0600 > +++ b/linux/fs/xfs/xfs_clnt.h 2004-11-14 10:49:21.000000000 -0600 > @@ -123,6 +123,7 @@ > #define XFSMNT_NOUUID 0x01000000 /* Ignore fs uuid */ > #define XFSMNT_32BITINODES 0x02000000 /* restrict inodes to 32 > * bits of address space > */ +#define XFSMNT_IRIXSGID 0x04000000 /* Irix-style > sgid inheritance */ > > /* Did we get any args for CXFS to consume? */ > #define XFSARGS_FOR_CXFSARR(ap) \ > > =========================================================================== > linux/fs/xfs/xfs_inode.c > =========================================================================== > > --- a/linux/fs/xfs/xfs_inode.c 2004-11-14 10:49:21.000000000 -0600 > +++ b/linux/fs/xfs/xfs_inode.c 2004-11-14 10:49:21.000000000 -0600 > @@ -1098,10 +1098,11 @@ > /* > * If the group ID of the new file does not match the effective > group > * ID or one of the supplementary group IDs, the ISGID bit is > - * cleared. > + * cleared if the "irixsgid" mount option is set. > */ > if (ip->i_d.di_mode & ISGID) { > - if (!in_group_p((gid_t)ip->i_d.di_gid) && > !capable(CAP_FSETID)){ > + if (!in_group_p((gid_t)ip->i_d.di_gid) > + && (ip->i_mount->m_flags & XFS_MOUNT_IRIXSGID)) { > ip->i_d.di_mode &= ~ISGID; > } > } > > =========================================================================== > linux/fs/xfs/xfs_mount.h > =========================================================================== > > --- a/linux/fs/xfs/xfs_mount.h 2004-11-14 10:49:21.000000000 -0600 > +++ b/linux/fs/xfs/xfs_mount.h 2004-11-14 10:49:21.000000000 -0600 > @@ -341,6 +341,7 @@ > #define XFS_MOUNT_NOUUID 0x00004000 /* ignore uuid during > mount */ > #define XFS_MOUNT_32BITINODES 0x00008000 /* do not create inodes > above > * 32 bits in size */ > +#define XFS_MOUNT_IRIXSGID 0x00010000 /* Irix-style sgid > inheritance */ > > /* > * Flags for m_cxfstype > > =========================================================================== > linux/fs/xfs/xfs_vfsops.c > =========================================================================== > > --- a/linux/fs/xfs/xfs_vfsops.c 2004-11-14 10:49:21.000000000 -0600 > +++ b/linux/fs/xfs/xfs_vfsops.c 2004-11-14 10:49:21.000000000 -0600 > @@ -363,6 +363,9 @@ > if (ap->flags & XFSMNT_32BITINODES) > mp->m_flags |= XFS_MOUNT_32BITINODES; > > + if (ap->flags & XFSMNT_IRIXSGID) > + mp->m_flags |= XFS_MOUNT_IRIXSGID; > + > if (ap->flags & XFSMNT_IOSIZE) { > if (ap->iosizelog > XFS_MAX_IO_LOG || > ap->iosizelog < XFS_MIN_IO_LOG) { From owner-linux-xfs Sun Nov 14 16:49:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Nov 2004 16:50:01 -0800 (PST) Received: from elrond.render-it.com (mail.illuvatar.net [205.147.19.123]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAF0nuZq001690 for ; Sun, 14 Nov 2004 16:49:57 -0800 Received: from illuvatar.com (bilbo.render-it.com [193.168.254.4]) by elrond.render-it.com (SGI-8.9.3/8.9.3) with ESMTP id QAA62531 for ; Sun, 14 Nov 2004 16:49:41 -0800 (PST) Message-ID: <4197FD18.4050507@illuvatar.com> Date: Sun, 14 Nov 2004 16:49:28 -0800 From: "William C. Shortell" Organization: ILLUVATAR, LLC User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP30; en-US; rv:1.4.1) Gecko/20040105 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS for RHEL Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4435 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bill@illuvatar.com Precedence: bulk X-list: linux-xfs Content-Length: 801 Lines: 23 Hello linux-xfs, I have downloaded the release-1.3.3-pre3 version of XFS for RHEL. I need to compile drivers for my network cards and my NVidia card. However, SGI doesn't provide the kernel-source rpm for this kernel. It does provide the kernel-2.4.21-15.0.4.EL.sgi3.src.rpm file. This installs a bunch of patch files in the /usr/src/redhat/SOURCES directory. It also install some spec files in the /usr/src/redhat/SPECS directory. How do I go about creating the /usr/src/linux-2.4.21-15.0.4.EL.sgi3 source tree from the kernel-source-2.4.21-15.0.4.EL rpm? Thanks for your help. -- William C. Shortell ILLUVATAR, LLC Cell (310) 753-1774 P. O. Box 8506 Phone/Fax (714) 965-5918 Fountain Valley, CA 92728 E-mail bill@illuvatar.com www.illuvatar.com www.render-it.com From owner-linux-xfs Sun Nov 14 19:16:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 14 Nov 2004 19:16:17 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAF3GCTH006456 for ; Sun, 14 Nov 2004 19:16:12 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAF4X84r005552 for ; Sun, 14 Nov 2004 20:33:08 -0800 Received: from [127.0.0.1] (sshcf.sgi.com [198.149.20.14]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAF3Eqad1626552; Sun, 14 Nov 2004 19:14:53 -0800 (PST) Message-ID: <41981F2C.8010609@sgi.com> Date: Sun, 14 Nov 2004 21:14:52 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "William C. Shortell" CC: linux-xfs@oss.sgi.com Subject: Re: XFS for RHEL References: <4197FD18.4050507@illuvatar.com> In-Reply-To: <4197FD18.4050507@illuvatar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4436 X-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: 400 Lines: 11 William C. Shortell wrote: > Hello linux-xfs, > > I have downloaded the release-1.3.3-pre3 version of XFS for RHEL. I > need to compile drivers for my network cards and my NVidia card. > However, SGI doesn't provide the kernel-source rpm for this kernel. ftp://oss.sgi.com/projects/xfs/testing/release-1.3.3-pre3/kernels/RHEL/RPMS/i386/kernel-source-2.4.21-15.0.4.EL.sgi3.i386.rpm -Eric From owner-linux-xfs Mon Nov 15 02:31:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 15 Nov 2004 02:31:59 -0800 (PST) Received: from smtp.cistron-office.nl (mail@10fwd.cistron-office.nl [62.216.29.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAFAVsvN025959 for ; Mon, 15 Nov 2004 02:31:54 -0800 Received: from subspace.cistron-office.nl ([62.216.29.200]) by smtp.cistron-office.nl with esmtp (Exim 3.35 #1 (Debian)) id 1CTe90-0006jc-00; Mon, 15 Nov 2004 11:31:34 +0100 Received: from miquels by subspace.cistron-office.nl with local (Exim 3.35 #1 (Debian)) id 1CTe8y-00028Z-00; Mon, 15 Nov 2004 11:31:32 +0100 Date: Mon, 15 Nov 2004 11:31:32 +0100 From: Miquel van Smoorenburg To: linux-xfs@oss.sgi.com Cc: nathans@snort.melbourne.sgi.com Subject: [REPOST] [PATCH] fs/xfs/linux-2.6/kmem.c Message-ID: <20041115103130.GA7971@cistron.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-NCC-RegID: nl.cistron User-Agent: Mutt/1.5.4i X-archive-position: 4437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: miquels@cistron.net Precedence: bulk X-list: linux-xfs Content-Length: 5560 Lines: 179 I've sent this to the list a month ago, but I think it was overlooked. I think this (actually, the second patch) should go as a bugfix into 2.6.10 .. So I'm reposting it, if I'm completely wrong about this tell me and I'll shut up. Thanks! ----- Forwarded message from Miquel van Smoorenburg ----- Date: Thu, 14 Oct 2004 20:26:26 +0200 From: Miquel van Smoorenburg To: linux-xfs@oss.sgi.com Subject: shut up fs/xfs/linux-2.6/kmem.c Message-ID: <20041014182625.GA7535@cistron.nl> Hello, on my machines fs/xfs/linux-2.6/kmem.c is printing a lot of garbage about failed 4th and 5th order allocations. I investigated this, and it appears that the vmalloc/kmalloc wrappers don't set __GFP_REPEAT or __GFP_NOFAIL, instead looping endlessly in the wrapper until the allocation succeeds. Because there is no delay built in (kmalloc at least calls blk_congestion_wait() if it's told to retry) it's printing lots of debug info in a very short time. This only happens for 4th and 5th order allocations, because kmalloc() itself behaves as if __GFP_REPEAT or __GFP_NOFAIL was set for < 4th order allocations if __GFP_WAIT is set. (BTW, note that mm/page_alloc.c::__alloc_pages() has either the comment or the logic wrong...) The first patch just retains the current way of doing things, but cuts down on the debug output - it also adds blk_congestion_wait() in the endless loop. With this patch applied, my system is finally peaceful and quiet again. Which is great, if you have a 9600 bd serial console - otherwise the system just stops. The second patch does the same, but simplifies things a lot by using __GFP_NOFAIL. It's cleaner, deletes code instead of adding to it, but I'm not sure if the printk's were there for some reason. Mike. == First patch, quiet down kmem.c and introduce wait: --- linux-2.6.9-rc4-tw/fs/xfs/linux-2.6/kmem.c.ORIG 2004-08-14 12:55:33.000000000 +0200 +++ linux-2.6.9-rc4-tw/fs/xfs/linux-2.6/kmem.c 2004-10-12 17:47:16.000000000 +0200 @@ -35,6 +35,7 @@ #include #include #include +#include #include "time.h" #include "kmem.h" @@ -47,18 +48,25 @@ kmem_alloc(size_t size, int flags) { int retries = 0, lflags = kmem_flags_convert(flags); + int lflagsq, warn; void *ptr; + lflagsq = lflags | (flags & (KM_MAYFAIL|KM_NOSLEEP)) ? 0 : __GFP_NOWARN; + do { + warn = (++retries % 100) == 0; if (size < MAX_SLAB_SIZE || retries > MAX_VMALLOCS) - ptr = kmalloc(size, lflags); + ptr = kmalloc(size, warn ? lflags : lflagsq); else - ptr = __vmalloc(size, lflags, PAGE_KERNEL); + ptr = __vmalloc(size, warn ? lflags : lflagsq, + PAGE_KERNEL); if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; - if (!(++retries % 100)) - printk(KERN_ERR "possible deadlock in %s (mode:0x%x)\n", + if (warn) + printk(KERN_ERR "xfs: possible memory allocation " + "deadlock in %s (mode:0x%x)\n", __FUNCTION__, lflags); + blk_congestion_wait(WRITE, HZ/50); } while (1); } @@ -103,15 +111,21 @@ kmem_zone_alloc(kmem_zone_t *zone, int flags) { int retries = 0, lflags = kmem_flags_convert(flags); + int lflagsq, warn; void *ptr; + lflagsq = lflags | (flags & (KM_MAYFAIL|KM_NOSLEEP)) ? 0 : __GFP_NOWARN; + do { - ptr = kmem_cache_alloc(zone, lflags); + warn = (++retries % 100) == 0; + ptr = kmem_cache_alloc(zone, warn ? lflags : lflagsq); if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; - if (!(++retries % 100)) - printk(KERN_ERR "possible deadlock in %s (mode:0x%x)\n", + if (warn) + printk(KERN_ERR "xfs: possible memory allocation " + "deadlock in %s (mode:0x%x)\n", __FUNCTION__, lflags); + blk_congestion_wait(WRITE, HZ/50); } while (1); } == alternative patch, simplify and use __GFP_WAIT. --- linux-2.6.9-rc4-tw/fs/xfs/linux-2.6/kmem.c.ORIG 2004-08-14 12:55:33.000000000 +0200 +++ linux-2.6.9-rc4-tw/fs/xfs/linux-2.6/kmem.c 2004-10-14 20:17:31.000000000 +0200 @@ -35,6 +35,7 @@ #include #include #include +#include #include "time.h" #include "kmem.h" @@ -46,20 +47,23 @@ void * kmem_alloc(size_t size, int flags) { - int retries = 0, lflags = kmem_flags_convert(flags); + int retries, lflags = kmem_flags_convert(flags); void *ptr; - do { - if (size < MAX_SLAB_SIZE || retries > MAX_VMALLOCS) + if (flags & (KM_MAYFAIL|KM_NOSLEEP)) + lflags |= __GFP_NOWARN; + + for (retries = 0; retries < MAX_VMALLOCS; retries++) { + if (size < MAX_SLAB_SIZE) ptr = kmalloc(size, lflags); else ptr = __vmalloc(size, lflags, PAGE_KERNEL); if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; - if (!(++retries % 100)) - printk(KERN_ERR "possible deadlock in %s (mode:0x%x)\n", - __FUNCTION__, lflags); - } while (1); + blk_congestion_wait(WRITE, HZ/50); + } + + return kmalloc(size, lflags | __GFP_NOFAIL); } void * @@ -102,17 +106,12 @@ void * kmem_zone_alloc(kmem_zone_t *zone, int flags) { - int retries = 0, lflags = kmem_flags_convert(flags); - void *ptr; + int lflags = kmem_flags_convert(flags); - do { - ptr = kmem_cache_alloc(zone, lflags); - if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) - return ptr; - if (!(++retries % 100)) - printk(KERN_ERR "possible deadlock in %s (mode:0x%x)\n", - __FUNCTION__, lflags); - } while (1); + if (!(flags & (KM_MAYFAIL|KM_NOSLEEP))) + lflags |= __GFP_NOFAIL; + + return kmem_cache_alloc(zone, lflags); } void * ----- End forwarded message ----- From owner-linux-xfs Tue Nov 16 10:00:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Nov 2004 10:00:34 -0800 (PST) Received: from short4.org (82-147-17-1.dsl.uk.rapidplay.com [82.147.17.1]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAGI0TDw005297 for ; Tue, 16 Nov 2004 10:00:30 -0800 Received: (qmail 10107 invoked from network); 16 Nov 2004 18:03:03 -0000 Received: from unknown (HELO ?192.168.1.151?) (192.168.1.151) by 192.168.1.253 with SMTP; 16 Nov 2004 18:03:03 -0000 Message-ID: <419A4DE9.7070007@linux-corner.info> Date: Tue, 16 Nov 2004 18:58:49 +0000 From: Mark Watts User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on md raid-0 arrays References: <419781A9.1090706@linux-corner.info> <20041114151003.GA7354@infradead.org> In-Reply-To: <20041114151003.GA7354@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4439 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: m.watts@linux-corner.info Precedence: bulk X-list: linux-xfs Content-Length: 4146 Lines: 110 Christoph Hellwig wrote: > On Sun, Nov 14, 2004 at 04:02:49PM +0000, Mark Watts wrote: > >>I'm running XFS on Mandrake 10.0 (2.6.3 kernel). > > > Please repdoruce with a current kernel. MD in early 2.6 kernels has > been quite buggy. I took this opportunity to install Mandrake 10.1 which uses a 2.6.8 kernel. I told the installer to reformat /dev/md0 but not to reformat /dev/md1 (/home). NOTE: I did _not_ recreate any partitions or raidsets, and the installer detected the raid partitions just fine. During the following system boot, mounting md1 fails with a bunch of messages in dmesg: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1610 of file fs/xfs/xfs_alloc.c. Caller 0xf8c3450a [] dump_stack+0x1e/0x20 [] xfs_free_ag_extent+0x2ef/0x770 [xfs] [] xfs_free_extent+0xca/0xf0 [xfs] [] xfs_bmap_finish+0x12b/0x1c0 [xfs] [] xfs_itruncate_finish+0x29d/0x3f0 [xfs] [] xfs_setattr+0xde3/0xf50 [xfs] [] linvfs_setattr+0xfd/0x180 [xfs] [] notify_change+0x278/0x2e0 [] do_truncate+0x62/0xa0 [] may_open+0x237/0x2a0 [] open_namei+0x136/0x690 [] filp_open+0x3a/0x60 [] sys_open+0x46/0xa0 [] sysenter_past_esp+0x52/0x71 xfs_force_shutdown(md1,0x8) called from line 4049 of file fs/xfs/xfs_bmap.c. Return address = 0xf8c46e28 Filesystem "md1": Corruption of in-memory data detected. Shutting down filesystem: md1 Please umount the filesystem, and rectify the problem(s) eth0: no IPv6 routers present mtrr: 0xc0000000,0x8000000 overlaps existing 0xc0000000,0x100000 xfs_force_shutdown(md1,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xf8c9232f xfs_force_shutdown(md1,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xf8c9232f xfs_force_shutdown(md1,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xf8c9232f xfs_force_shutdown(md1,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xf8c9232f /home appears to be mounted according to /etc/mtab and 'mount', but I get an I/O error when I try and ls /home. If I unmount /home, then remount it I get the following in dmesg: XFS mounting filesystem md1 Starting XFS recovery on filesystem: md1 (dev: md1) XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1610 of file fs/xfs/xfs_alloc.c. Caller 0xf8c3450a [] dump_stack+0x1e/0x20 [] xfs_free_ag_extent+0x2ef/0x770 [xfs] [] xfs_free_extent+0xca/0xf0 [xfs] [] xlog_recover_process_efi+0x1ce/0x240 [xfs] [] xlog_recover_process_efis+0x3b/0x60 [xfs] [] xlog_recover_finish+0x1c/0xd0 [xfs] [] xfs_log_mount_finish+0x2b/0x30 [xfs] [] xfs_mountfs+0x6c2/0xf00 [xfs] [] xfs_mount+0x24b/0x420 [xfs] [] linvfs_fill_super+0x9f/0x200 [xfs] [] get_sb_bdev+0x11e/0x150 [] linvfs_get_sb+0x2f/0x40 [xfs] [] do_kern_mount+0xca/0x1b0 [] do_new_mount+0x77/0xc0 [] do_mount+0x203/0x210 [] sys_mount+0x92/0xf0 [] sysenter_past_esp+0x52/0x71 Ending XFS recovery on filesystem: md1 (dev: md1) The filesystem appears to be mounted and I can see files/directories in /home as I expect to see. Doing 'find /home' gives the following in dmesg, although it appears to complete the command: Filesystem "md1": XFS internal error xfs_da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xf8c55244 [] dump_stack+0x1e/0x20 [] xfs_da_do_buf+0x7b0/0x840 [xfs] [] xfs_da_read_buf+0x44/0x50 [xfs] [] xfs_dir2_leaf_getdents+0x38e/0xb50 [xfs] [] xfs_dir2_getdents+0x170/0x180 [xfs] [] xfs_readdir+0x5c/0xb0 [xfs] [] linvfs_readdir+0xfc/0x230 [xfs] [] vfs_readdir+0xae/0xd0 [] sys_getdents64+0x74/0xb4 [] sysenter_past_esp+0x52/0x71 What should I be doing now? Is it safe to copy data off of this partition (should I mount read-only to be safe?) Regards, Mark. From owner-linux-xfs Tue Nov 16 10:03:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Nov 2004 10:03:54 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAGI3pwI005888 for ; Tue, 16 Nov 2004 10:03:51 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAGI3oIk005887 for linux-xfs@oss.sgi.com; Tue, 16 Nov 2004 10:03:50 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAGI3mkv005864 for ; Tue, 16 Nov 2004 10:03:49 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAGHLpdd001240; Tue, 16 Nov 2004 09:21:51 -0800 Date: Tue, 16 Nov 2004 09:21:51 -0800 Message-Id: <200411161721.iAGHLpdd001240@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 386] New: xfsdump-2.2.25 fails on compile X-Bugzilla-Reason: AssignedTo X-archive-position: 4440 X-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: 4684 Lines: 104 http://oss.sgi.com/bugzilla/show_bug.cgi?id=386 Summary: xfsdump-2.2.25 fails on compile Product: Linux XFS Version: unspecified Platform: All OS/Version: All Status: NEW Severity: critical Priority: High Component: xfsdump AssignedTo: xfs-master@oss.sgi.com ReportedBy: akingston@gmail.com On: Linux kernel 2.4.27 with XFS support enabled, the following error occurs on xfsdump $sudo /usr/src/xfs/xfsdump-2.2.25/Makepkgs -verbose .... inomap.c: In function `cb_add': inomap.c:739: `XFS_XFLAG_NODUMP' undeclared (first use in this function) inomap.c:739: (Each undeclared identifier is reported only once inomap.c:739: for each function it appears in.) gmake[1]: *** [inomap.o] Error 1 make: *** [default] Error 2 == dist, log is Logs/dist make: Entering directory `/usr/src/xfs/xfsdump-2.2.25/build' /bin/tar: xfsdump-2.2.25/restore/arch_xlate.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/cldmgr.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/dlog.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/drive.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/drive_scsitape.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/drive_simple.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/drive_minrmt.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/fs.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/getdents.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/global.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/lock.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/main.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/mlog.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/openutil.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/path.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/qlock.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/ring.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/sproc.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/stream.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/util.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/inv_api.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/inv_core.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/inv_files.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/inv_fstab.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/inv_idx.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/inv_mgr.c: Cannot stat: No such file or directory /bin/tar: xfsdump-2.2.25/restore/inv_stobj.c: Cannot stat: No such file or directory /bin/tar: Error exit delayed from previous errors Wrote: /usr/src/xfs/xfsdump-2.2.25/build/xfsdump-2.2.25.src.tar.gz === install === gmake[1]: Entering directory `/usr/src/xfs/xfsdump-2.2.25' === include === gmake[2]: Nothing to be done for `default'. === librmt === gmake[2]: Nothing to be done for `default'. === common === gmake[2]: Nothing to be done for `default'. === estimate === gmake[2]: Nothing to be done for `default'. === fsr === gmake[2]: Nothing to be done for `default'. === inventory === gmake[2]: Nothing to be done for `default'. === invutil === gmake[2]: Nothing to be done for `default'. === quota === gmake[2]: Nothing to be done for `default'. === dump === gcc -O1 -g -DDEBUG -funsigned-char -fno-strict-aliasing -Wall -DVERSION=\"2.2.25\" -DLOCALEDIR=\"/usr/s hare/locale\" -DPACKAGE=\"xfsdump\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DDUMP -DRMT -DBA SED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -DDMEXTATTR -c -o inomap.o inomap.c inomap.c: In function `cb_add': inomap.c:739: `XFS_XFLAG_NODUMP' undeclared (first use in this function) inomap.c:739: (Each undeclared identifier is reported only once inomap.c:739: for each function it appears in.) gmake[2]: *** [inomap.o] Error 1 gmake[1]: *** [default] Error 2 gmake[1]: Leaving directory `/usr/src/xfs/xfsdump-2.2.25' make: *** [dist] Error 2 make: Leaving directory `/usr/src/xfs/xfsdump-2.2.25/build' ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Nov 16 14:03:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Nov 2004 14:03:52 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAGM3phU021188 for ; Tue, 16 Nov 2004 14:03:51 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAGM3piT021187 for linux-xfs@oss.sgi.com; Tue, 16 Nov 2004 14:03:51 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAGM3nRN021172 for ; Tue, 16 Nov 2004 14:03:49 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAGLa792020575; Tue, 16 Nov 2004 13:36:07 -0800 Date: Tue, 16 Nov 2004 13:36:07 -0800 Message-Id: <200411162136.iAGLa792020575@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 386] xfsdump-2.2.25 fails on compile X-Bugzilla-Reason: AssignedTo X-archive-position: 4441 X-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: 391 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=386 ------- Additional Comments From nathans@sgi.com 2004-16-11 13:36 PDT ------- You need a newer version of xfsprogs-devel installed (and we need a new configure check in xfsdump to check for this new macro). cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Nov 16 20:02:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Nov 2004 20:02:47 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAH42aIp002806 for ; Tue, 16 Nov 2004 20:02:36 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id iAH427908575; Tue, 16 Nov 2004 20:02:07 -0800 Date: Tue, 16 Nov 2004 20:01:56 -0800 From: Andrew Morton To: Brad Fitzpatrick Cc: linux-kernel@vger.kernel.org, lisa@danga.com, marksmith@danga.com, linux-xfs@oss.sgi.com Subject: Re: 2.6.9: unkillable processes during heavy IO Message-Id: <20041116200156.2b2526e5.akpm@osdl.org> In-Reply-To: References: 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: 4442 X-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: 46379 Lines: 692 Brad Fitzpatrick wrote: > > Here is the information requested regarding the regular lockup we're > seeing (details in original post at bottom) yup, that looks like a locking tangle in the XFS direct-io code. Nathan, this is 2.6.9. > # killall -9 mysqld > # killall -9 mysqld > # killall -9 mysqld > > PID WIDE-WCHAN-COLUMN COMMAND > 1 - init [2] > 2 migration_thread [migration/0] > 3 ksoftirqd [ksoftirqd/0] > 4 migration_thread [migration/1] > 5 ksoftirqd [ksoftirqd/1] > 6 worker_thread [events/0] > 8 worker_thread \_ [khelper] > 9 worker_thread \_ [kacpid] > 39 worker_thread \_ [kblockd/0] > 40 worker_thread \_ [kblockd/1] > 52 pdflush \_ [pdflush] > 53 pdflush \_ [pdflush] > 56 worker_thread \_ [aio/0] > 57 worker_thread \_ [aio/1] > 7 worker_thread [events/1] > 1154 worker_thread \_ [xfslogd/0] > 1155 worker_thread \_ [xfslogd/1] > 1156 worker_thread \_ [xfsdatad/0] > 1157 worker_thread \_ [xfsdatad/1] > 41 hub_thread [khubd] > 54 kswapd [kswapd1] > 55 kswapd [kswapd0] > 639 serio_thread [kseriod] > 726 - [scsi_eh_0] > 733 - [scsi_eh_1] > 1158 - [xfsbufd] > 1159 1109149712136 [xfssyncd] > 1160 1109149728520 [xfssyncd] > 1161 kjournald [kjournald] > 1162 1109157093128 [xfssyncd] > 1163 1109157166856 [xfssyncd] > 1164 1109172895496 [xfssyncd] > 2931 - /sbin/syslogd > 2934 syslog /sbin/klogd > 2942 - /usr/sbin/inetd > 3035 - /usr/lib/postfix/master > 3040 - \_ qmgr -l -t fifo -u -c > 8534 - \_ pickup -l -t fifo -u -c > 3045 - /usr/sbin/snmpd -Lsd -Lf /dev/null -p /var/run/snmpd.pid > 3051 - /usr/sbin/sshd > 6952 - \_ sshd: root@pts/1 > 6954 - | \_ -bash > 8569 - \_ sshd: root@pts/0 > 8571 wait \_ -bash > 8671 - \_ ps afx -o pid,wchan=WIDE-WCHAN-COLUMN,command > 3057 - /usr/sbin/atd > 3060 - /usr/sbin/cron > 3074 - /sbin/getty 38400 tty1 > 3076 - /sbin/getty 38400 tty2 > 3077 - /sbin/getty 38400 tty3 > 3078 - /sbin/getty 38400 tty4 > 3079 - /sbin/getty 38400 tty5 > 3080 - /sbin/getty 38400 tty6 > 5390 - /usr/local/mysql/bin/mysqld --defaults-extra-file=/usr/local/mysql/data/my.cnf --basedir=/usr/local/mysql/ --datadir=/data/mydb --user=root --pid-file=/var/run/mysqld/mysqld.pid --skip-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock > 7663 - /usr/local/mysql/bin/mysqld --defaults-extra-file=/usr/local/mysql/data/my.cnf --basedir=/usr/local/mysql/ --datadir=/data/mydb --user=root --pid-file=/var/run/mysqld/mysqld.pid --skip-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock > 8657 - /usr/local/mysql/bin/mysqld --defaults-extra-file=/usr/local/mysql/data/my.cnf --basedir=/usr/local/mysql/ --datadir=/data/mydb --user=root --pid-file=/var/run/mysqld/mysqld.pid --skip-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock > 8658 exit \_ [mysqld] > > > And sysrq t: > > SysRq : Show State > > sibling > task PC pid father child younger older > init S 0000000000000400 0 1 0 2 (NOTLB) > 00000101450bdd88 0000000000000006 0000000000000256 0000010140000700 > 0000010140021480 0000000000000000 0000000000000007 ffffffff8015ae20 > 0000000000000216 0000000100000246 > Call Trace:{buffered_rmqueue+432} {__mod_timer+303} > {schedule_timeout+173} {process_timeout+0} > {do_select+819} {__pollwait+0} > {sys_select+960} {system_call+126} > > migration/0 S 000001000c004720 0 2 1 3 (L-TLB) > 000001000c03bee8 0000000000000046 0000010143860760 0000000000000012 > 0000007300000002 ffffffff801335c0 0000010211120810 0000000000000073 > 000001000c004740 0000000000000001 > Call Trace:{try_to_wake_up+528} {migration_thread+202} > {migration_thread+0} {kthread+146} > {child_rip+8} {migration_thread+0} > {kthread+0} {child_rip+0} > > ksoftirqd/0 S 0000000000000000 0 3 1 4 2 (L-TLB) > 000001023ff93f08 0000000000000046 0000000000000009 ffffffff804079e0 > 000000000000000a 0000000000000212 0000000000000212 0000000000000000 > 000001000c006940 00000000802f4e80 > Call Trace:{__do_softirq+113} {ksoftirqd+0} > {ksoftirqd+63} {kthread+146} > {child_rip+8} {ksoftirqd+0} > {kthread+0} {child_rip+0} > > migration/1 S 00000101438619a0 0 4 1 5 3 (L-TLB) > 000001023ff95ee8 0000000000000046 000001000c0034e0 0000000000000016 > 0000007300000002 ffffffff801335c0 0000010211120810 0000000000000073 > 00000101438619c0 0000000100000001 > Call Trace:{try_to_wake_up+528} {migration_thread+202} > {migration_thread+0} {kthread+146} > {child_rip+8} {migration_thread+0} > {kthread+0} {child_rip+0} > > ksoftirqd/1 S 0000000000000000 0 5 1 6 4 (L-TLB) > 000001023ffa7f08 0000000000000046 0000000000000212 0000000000000000 > 0000000000000000 ffffffff8024cc49 0000000000000000 0000010143863bc0 > 0000000000000006 000000018025c186 > Call Trace:{dst_destroy+169} {__do_softirq+113} > {ksoftirqd+0} {ksoftirqd+63} > {kthread+146} {child_rip+8} > {ksoftirqd+0} {kthread+0} > {child_rip+0} > events/0 S ffffffff801607e0 0 6 1 8 7 5 (L-TLB) > 000001000c08be58 0000000000000046 000001000c08bd88 0000000000000256 > 0000007380396e68 0000000000000256 0000000000000212 00000100fbf622c0 > 00000100fbf622c0 0000000000000212 > Call Trace:{__wake_up+67} {cache_reap+0} > {worker_thread+270} {default_wake_function+0} > {default_wake_function+0} {worker_thread+0} > {kthread+146} {child_rip+8} > {worker_thread+0} {kthread+0} > {child_rip+0} > events/1 S ffffffff801607e0 0 7 1 1154 41 6 (L-TLB) > 000001023fe4de58 0000000000000046 000001013fffee80 ffffffff8015eda7 > 0000007700000000 0000000000000012 0000000000000012 000001013fffee80 > 0000000000000003 0000000100000212 > Call Trace:{slab_destroy+151} {__wake_up+67} > {cache_reap+0} {worker_thread+270} > {default_wake_function+0} {default_wake_function+0} > {worker_thread+0} {kthread+146} > {child_rip+8} {worker_thread+0} > {kthread+0} {child_rip+0} > > khelper S 000001023fe26828 0 8 6 9 (L-TLB) > 000001000c08fe58 0000000000000046 00000100ad17dd88 0000000000000212 > 0000006a80149390 ffffffff80112446 0000010088e3e810 000000000000006a > 000001000c004740 000000003fe26800 > Call Trace:{kernel_thread+130} {__wake_up+67} > {child_rip+0} {__call_usermodehelper+0} > {worker_thread+270} {default_wake_function+0} > {default_wake_function+0} {keventd_create_kthread+0} > {worker_thread+0} {keventd_create_kthread+0} > {kthread+146} {child_rip+8} > {keventd_create_kthread+0} {worker_thread+0} > {kthread+0} {child_rip+0} > > kacpid S ffffffff8014de80 0 9 6 39 8 (L-TLB) > 000001014515fe58 0000000000000046 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 0000000100000000 > Call Trace:{keventd_create_kthread+0} {worker_thread+270} > {default_wake_function+0} {default_wake_function+0} > {keventd_create_kthread+0} {worker_thread+0} > {keventd_create_kthread+0} {kthread+146} > {child_rip+8} {keventd_create_kthread+0} > {worker_thread+0} {kthread+0} > {child_rip+0} > kblockd/0 S ffffffff80225400 0 39 6 40 9 (L-TLB) > 000001013fe51e58 0000000000000046 000000000000007a ffffffffa00355b2 > 0000000000000212 0000000000000000 000000004520e800 0000010140009400 > 0000000000000000 0000000045281b40 > Call Trace:{:mptscsih:mptscsih_qcmd+770} {__wake_up+67} > {as_work_handler+0} {worker_thread+270} > {default_wake_function+0} {default_wake_function+0} > {keventd_create_kthread+0} {worker_thread+0} > {keventd_create_kthread+0} {kthread+146} > {child_rip+8} {keventd_create_kthread+0} > {worker_thread+0} {kthread+0} > {child_rip+0} > kblockd/1 S ffffffff8021e180 0 40 6 52 39 (L-TLB) > 0000010145193e58 0000000000000046 0000000000000216 0000000000000000 > 000000004520e800 0000010140009400 0000000000000000 0000010145281b40 > 0000010145216000 0000000180224858 > Call Trace:{__wake_up+67} {blk_unplug_work+0} > {worker_thread+270} {default_wake_function+0} > {default_wake_function+0} {keventd_create_kthread+0} > {worker_thread+0} {keventd_create_kthread+0} > {kthread+146} {child_rip+8} > {keventd_create_kthread+0} {worker_thread+0} > {kthread+0} {child_rip+0} > > khubd S 0000000000000000 0 41 1 54 7 (L-TLB) > 00000101451a5ec8 0000000000000046 00000300801c1ad0 0000000000000001 > 000001013ff78400 0000000000000300 000001023fe30600 0000000000000000 > 000001013ff78400 000000018022bad6 > Call Trace:{hub_events+56} {hub_thread+206} > {autoremove_wake_function+0} {finish_task_switch+64} > {autoremove_wake_function+0} {schedule_tail+17} > {child_rip+8} {hub_thread+0} > {child_rip+0} > pdflush S ffffffff8014de80 0 52 6 53 40 (L-TLB) > 000001013fe83eb8 0000000000000046 0000000000000000 000000002faef350 > 0000006c00000000 0000000000ff347f 000001023fe25810 000000000000006c > 000001000c004740 0000000000ff347f > Call Trace:{try_to_wake_up+528} {task_rq_lock+74} > {pdflush+0} {keventd_create_kthread+0} > {__pdflush+170} {pdflush+28} > {pdflush+0} {kthread+146} > {child_rip+8} {keventd_create_kthread+0} > {pdflush+0} {kthread+0} > {child_rip+0} > pdflush S ffffffff8014de80 0 53 6 56 52 (L-TLB) > 000001013fe85eb8 0000000000000046 0000000000000216 ffffffff801417ef > 00000000fffffffc 00000000000011bc 000001013fe85e48 000000010794cb83 > 00000000fffffffc 0000000100000212 > Call Trace:{__mod_timer+303} {pdflush+0} > {keventd_create_kthread+0} {__pdflush+170} > {pdflush+28} {kthread+146} > {child_rip+8} {keventd_create_kthread+0} > {pdflush+0} {kthread+0} > {child_rip+0} > aio/0 S 000001013fe4a028 0 56 6 57 53 (L-TLB) > 000001013fe89e58 0000000000000046 0000000000000000 0000000000000000 > 0000006c00000000 0000000000000000 000001014518d810 000000000000006c > 000001000c004740 0000000000000000 > Call Trace:{keventd_create_kthread+0} {worker_thread+270} > {default_wake_function+0} {default_wake_function+0} > {keventd_create_kthread+0} {worker_thread+0} > {keventd_create_kthread+0} {kthread+146} > {child_rip+8} {keventd_create_kthread+0} > {worker_thread+0} {kthread+0} > {child_rip+0} > kswapd1 S 0000010140001798 0 54 1 55 41 (L-TLB) > 000001013fe87eb8 0000000000000046 ffffffff802f5f48 ffffffff80162255 > 000000790000000c 0000000000000001 00000101cb7ef7d0 0000000000000079 > 00000101438619c0 00000001000f5995 > Call Trace:{shrink_slab+341} {balance_pgdat+2} > {kswapd+261} {autoremove_wake_function+0} > {finish_task_switch+64} {autoremove_wake_function+0} > {schedule_tail+17} {child_rip+8} > {kswapd+0} {child_rip+0} > > kswapd0 S 0000000000000000 0 55 1 639 54 (L-TLB) > 00000101451b9eb8 0000000000000046 ffffffff802f5f48 ffffffff80162255 > 0000008600000004 0000000000000000 000001014000d070 0000000000000086 > 000001000c004740 0000000000000b40 > Call Trace:{shrink_slab+341} {kswapd+261} > {autoremove_wake_function+0} {finish_task_switch+64} > {autoremove_wake_function+0} {schedule_tail+17} > {child_rip+8} {kswapd+0} > {child_rip+0} > aio/1 S ffffffff8014de80 0 57 6 56 (L-TLB) > 000001013fe8be58 0000000000000046 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 0000000100000000 > Call Trace:{keventd_create_kthread+0} {worker_thread+270} > {default_wake_function+0} {default_wake_function+0} > {worker_thread+0} {keventd_create_kthread+0} > {kthread+146} {child_rip+8} > {keventd_create_kthread+0} {worker_thread+0} > {kthread+0} {child_rip+0} > > kseriod S 00000100fbc3df08 0 639 1 726 55 (L-TLB) > 00000100fbc3dec8 0000000000000046 0000003000000008 00000100fbc3ded8 > 00000077fbc3de18 ffffffff8013311c 00000100fbd177d0 0000000000000077 > 000001000c004740 00000000000927c0 > Call Trace:{deactivate_task+44} {serio_thread+246} > {autoremove_wake_function+0} {finish_task_switch+64} > {autoremove_wake_function+0} {schedule_tail+17} > {child_rip+8} {serio_thread+0} > {child_rip+0} > scsi_eh_0 S 000001014527ff18 0 726 1 733 639 (L-TLB) > 000001014527fe48 0000000000000046 0000000000000000 0000000000000000 > 0000007500000000 00000100fbc44baa 000001000565c810 0000000000000075 > 00000101438619c0 0000000100000000 > Call Trace:{__down_interruptible+209} {default_wake_function+0} > {__down_failed_interruptible+53} > {:scsi_mod:.text.lock.scsi_error+45} > {child_rip+8} {:scsi_mod:scsi_error_handler+0} > {child_rip+0} > scsi_eh_1 S 000001013fd47f18 0 733 1 1158 726 (L-TLB) > 000001013fd47e48 0000000000000046 0000000000000000 0000000000000000 > 0000007700000000 000001000565c44a 000001000565c810 0000000000000077 > 000001000c004740 0000000000000000 > Call Trace:{__down_interruptible+209} {default_wake_function+0} > {__down_failed_interruptible+53} > {:scsi_mod:.text.lock.scsi_error+45} > {child_rip+8} {:scsi_mod:scsi_error_handler+0} > {child_rip+0} > xfslogd/0 S ffffffffa013c820 0 1154 7 1155 (L-TLB) > 00000100fbc41e58 0000000000000046 000001023e911740 ffffffffa01232e0 > 000001013dcc1090 000001023ee5a458 000001023e90c800 000001023e547040 > 0000000000000212 00000000801c574e > Call Trace:{:xfs:xfs_log_move_tail+80} {__wake_up+67} > {:xfs:pagebuf_iodone_work+0} {:xfs:pagebuf_iodone_work+0} > {worker_thread+270} {default_wake_function+0} > {default_wake_function+0} {keventd_create_kthread+0} > {worker_thread+0} {keventd_create_kthread+0} > {kthread+146} {child_rip+8} > {keventd_create_kthread+0} {worker_thread+0} > {kthread+0} {child_rip+0} > > xfslogd/1 S ffffffffa013c820 0 1155 7 1156 1154 (L-TLB) > 000001023e915e58 0000000000000046 000001023e911b00 ffffffffa01232e0 > 000001023de55050 000001023ee5a668 000001023e90c880 000001023e547580 > 0000000000000212 00000001801c574e > Call Trace:{:xfs:xfs_log_move_tail+80} {__wake_up+67} > {:xfs:pagebuf_iodone_work+0} {:xfs:pagebuf_iodone_work+0} > {worker_thread+270} {default_wake_function+0} > {default_wake_function+0} {keventd_create_kthread+0} > {worker_thread+0} {keventd_create_kthread+0} > {kthread+146} {child_rip+8} > {keventd_create_kthread+0} {worker_thread+0} > {kthread+0} {child_rip+0} > > xfsdatad/0 S ffffffff8014de80 0 1156 7 1157 1155 (L-TLB) > 000001013ff61e58 0000000000000046 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 > Call Trace:{keventd_create_kthread+0} {worker_thread+270} > {default_wake_function+0} {default_wake_function+0} > {keventd_create_kthread+0} {worker_thread+0} > {keventd_create_kthread+0} {kthread+146} > {child_rip+8} {keventd_create_kthread+0} > {worker_thread+0} {kthread+0} > {child_rip+0} > xfsdatad/1 S 000001023e90c0a8 0 1157 7 1156 (L-TLB) > 000001000c3f1e58 0000000000000046 0000000000000010 0000000000000000 > 0000006d00000008 0000000000000000 000001023f64a7d0 000000000000006d > 00000101438619c0 0000000100002620 > Call Trace:{keventd_create_kthread+0} {worker_thread+270} > {default_wake_function+0} {default_wake_function+0} > {keventd_create_kthread+0} {worker_thread+0} > {keventd_create_kthread+0} {kthread+146} > {child_rip+8} {keventd_create_kthread+0} > {worker_thread+0} {kthread+0} > {child_rip+0} > xfsbufd S 0000000000508ae0 0 1158 1 1159 733 (L-TLB) > 0000010005645e98 0000000000000046 000001013ff8ca80 0000010145216330 > 000001014000ae00 0000000000000000 00000000000000dd ffffffffa00355b2 > 0000000000000212 0000000100000000 > Call Trace:{:mptscsih:mptscsih_qcmd+770} {__mod_timer+303} > {schedule_timeout+173} {process_timeout+0} > {:xfs:pagebuf_daemon+148} {child_rip+8} > {:xfs:pagebuf_daemon+0} {child_rip+0} > > xfssyncd S 0000000000007530 0 1159 1 1160 1158 (L-TLB) > 000001023e797e88 0000000000000046 0000010140009e50 ffffffffffffff00 > 000000748029cc23 0000000000000010 000001023d921070 0000000000000074 > 00000101438619c0 00000001a0125b3e > Call Trace:{__mod_timer+303} {schedule_timeout+173} > {process_timeout+0} {:xfs:xfssyncd+142} > {:xfs:linvfs_fill_super+0} {child_rip+8} > {:xfs:linvfs_fill_super+0} {:xfs:xfssyncd+0} > {child_rip+0} > xfssyncd S 0000000000007530 0 1160 1 1161 1159 (L-TLB) > 000001023e79be88 0000000000000046 000000003ffe3400 000001023ffe3400 > 000001013fcb1200 000001023ffe3450 0000000000000002 00000ad900000af6 > 0000000000000002 00000001a0125b3e > Call Trace:{__mod_timer+303} {schedule_timeout+173} > {process_timeout+0} {:xfs:xfssyncd+142} > {:xfs:linvfs_fill_super+0} {child_rip+8} > {:xfs:linvfs_fill_super+0} {:xfs:xfssyncd+0} > {child_rip+0} > kjournald S 000001023ffe4e98 0 1161 1 1162 1160 (L-TLB) > 000001023f6e9e58 0000000000000046 00000101bab75a28 00000101bab75a80 > 00000101bab75be0 00000101bab75f50 00000101bab758c8 00000101bab75b88 > 00000101bab75d98 00000001bab756b8 > Call Trace:{__wake_up+67} {:jbd:kjournald+532} > {autoremove_wake_function+0} {autoremove_wake_function+0} > {:jbd:commit_timeout+0} {child_rip+8} > {:jbd:kjournald+0} {child_rip+0} > > xfssyncd S 0000000000007530 0 1162 1 1163 1161 (L-TLB) > 000001023eea1e88 0000000000000046 000001023ffe4c50 ffffffffffffff00 > ffffffffa01259ca 0000000000000010 0000000000000246 000001023eea1df8 > 0000000000000018 00000001a0125b3e > Call Trace:{:xfs:xlog_state_sync_all+90} {__mod_timer+303} > {schedule_timeout+173} {process_timeout+0} > {:xfs:xfssyncd+142} {:xfs:linvfs_fill_super+0} > {child_rip+8} {:xfs:linvfs_fill_super+0} > {:xfs:xfssyncd+0} {child_rip+0} > > xfssyncd S 0000000000007530 0 1163 1 1164 1162 (L-TLB) > 000001023eeb3e88 0000000000000046 000000003ffe4a00 000001023ffe4a00 > 000001023e911d40 000001023ffe4a50 0000000000000002 0000000e000041da > 0000000000000002 00000000a0125b3e > Call Trace:{__mod_timer+303} {schedule_timeout+173} > {process_timeout+0} {:xfs:xfssyncd+142} > {:xfs:linvfs_fill_super+0} {child_rip+8} > {:xfs:linvfs_fill_super+0} {:xfs:xfssyncd+0} > {child_rip+0} > xfssyncd S 0000000000007530 0 1164 1 2931 1163 (L-TLB) > 000001023fdb3e88 0000000000000046 000000003ffe4800 000001023ffe4800 > 000001023e911b00 000001023ffe4850 0000000000000002 00000008000068f5 > 0000000000000002 00000001a0125b3e > Call Trace:{__mod_timer+303} {schedule_timeout+173} > {process_timeout+0} {:xfs:xfssyncd+142} > {:xfs:linvfs_fill_super+0} {child_rip+8} > {:xfs:linvfs_fill_super+0} {:xfs:xfssyncd+0} > {child_rip+0} > syslogd S 000001013ff51c80 0 2931 1 2934 1164 (NOTLB) > 000001013fa61d88 0000000000000006 0000000100000000 000001023fd5bb50 > 000000743e7d0468 0000000000000067 000001000c3a7030 0000000000000074 > 000001000c004740 0000000000000246 > Call Trace:{__alloc_pages+831} {schedule_timeout+37} > {add_wait_queue+28} {datagram_poll+21} > {do_select+819} {__pollwait+0} > {sys_select+960} {system_call+126} > > klogd R running task 0 2934 1 2942 2931 (NOTLB) > inetd S 000001023ef77180 0 2942 1 3035 2934 (NOTLB) > 000001023eb73d88 0000000000000002 0000000000000000 00000000000004f4 > 0000007600000007 ffffffff8015ae20 000001023f38c7d0 0000000000000076 > 00000101438619c0 0000000140000700 > Call Trace:{buffered_rmqueue+432} {schedule_timeout+37} > {add_wait_queue+28} {tcp_poll+33} > {do_select+819} {__pollwait+0} > {sys_select+960} {system_call+126} > > master S 0000000000036db6 0 3035 1 3040 3045 2942 (NOTLB) > 000001013fa75d88 0000000000000006 0000000000000256 000001013ff84a18 > 000001013ff84bf0 0000000100000000 0000000000000007 ffffffff8015ae20 > 0000000800000001 0000000000000246 > Call Trace:{buffered_rmqueue+432} {__mod_timer+303} > {schedule_timeout+173} {process_timeout+0} > {do_select+819} {__pollwait+0} > {__wake_up+67} {sys_select+960} > {system_call+126} > qmgr S 0000000000000060 0 3040 3035 8534 (NOTLB) > 000001023e6bbd88 0000000000000002 0000000000000216 ffffffff802425b4 > 000000743e8a95ec 000001023e8a95ec 00000100fbc0f030 0000000000000074 > 000001000c004740 0000000000000246 > Call Trace:{sock_def_readable+68} {__mod_timer+303} > {schedule_timeout+173} {process_timeout+0} > {do_select+819} {__pollwait+0} > {sys_select+960} {system_call+126} > > snmpd S 00000000000001a8 0 3045 1 3051 3035 (NOTLB) > 000001023e3c1d88 0000000000000006 00000000419a0429 000001023e3c1d78 > 000000743e64aa40 000001023e3c1ec8 000001013ff837d0 0000000000000074 > 00000101438619c0 0000000100000246 > Call Trace:{schedule_timeout+37} {add_wait_queue+28} > {fget+91} {do_select+819} > {__pollwait+0} {sys_select+960} > {system_call+126} > sshd S 000001013f805ac0 0 3051 1 6952 3057 3045 (NOTLB) > 000001023df63d88 0000000000000002 0000000000000256 0000010140000700 > 0000007400000007 ffffffff8015ae20 0000010060518070 0000000000000074 > 00000101438619c0 0000000140000700 > Call Trace:{buffered_rmqueue+432} {schedule_timeout+37} > {add_wait_queue+28} {tcp_poll+33} > {do_select+819} {__pollwait+0} > {clear_inode+9} {sys_select+960} > {system_call+126} > atd S 0000000000000000 0 3057 1 3060 3051 (NOTLB) > 000001023e6d7ee8 0000000000000006 0000000000000216 000001023de5d138 > 000001023e6d7ef8 ffffffff8018fb11 000001023e6d7e68 000001023e6d7ef8 > 0000000000000000 0000000180181ce9 > Call Trace:{dput+33} {__mod_timer+303} > {schedule_timeout+173} {process_timeout+0} > {sys_nanosleep+193} {system_call+126} > > cron S 0000000000000000 0 3060 1 3074 3057 (NOTLB) > 000001023deb7ee8 0000000000000002 0000000000000216 00000101e0d4b3f0 > 000001023deb7ef8 ffffffff8018fb97 000001023deb7e68 000001023deb7ef8 > 0000007fbffffc70 0000000180181ce9 > Call Trace:{dput+167} {__mod_timer+303} > {schedule_timeout+173} {process_timeout+0} > {sys_nanosleep+193} {system_call+126} > > getty S 000001013fa2cd28 0 3074 1 3076 3060 (NOTLB) > 000001023e59dd78 0000000000000006 000000000000001c ffffffff801575ea > 0000000000000019 000000000000001b 0000000000000000 0000000000000000 > 000001023da29348 0000000180157610 > Call Trace:{do_generic_mapping_read+1034} {do_con_write+1657} > {schedule_timeout+37} {vgacon_cursor+242} > {add_wait_queue+28} {read_chan+926} > {default_wake_function+0} {default_wake_function+0} > {tty_ldisc_deref+117} {tty_read+256} > {vfs_read+199} {sys_read+83} > {system_call+126} > getty S 000001023e0fcd28 0 3076 1 3077 3074 (NOTLB) > 000001023d835d78 0000000000000002 000000000000001c ffffffff801575ea > 000001023e0fc000 000000000000001b 0000000000000000 0000000000000000 > 000001023da29348 0000000180157610 > Call Trace:{do_generic_mapping_read+1034} {do_con_write+1657} > {schedule_timeout+37} {add_wait_queue+28} > {read_chan+926} {default_wake_function+0} > {default_wake_function+0} {tty_ldisc_deref+117} > {tty_read+256} {vfs_read+199} > {sys_read+83} {system_call+126} > > getty S 00000100fbca2d28 0 3077 1 3078 3076 (NOTLB) > 000001023d859d78 0000000000000002 000000000000001c ffffffff801575ea > 00000074fbca2000 000000000000001b 000001023d8047d0 0000000000000074 > 00000101438619c0 0000000180157610 > Call Trace:{do_generic_mapping_read+1034} {release_console_sem+138} > {do_con_write+1657} {schedule_timeout+37} > {add_wait_queue+28} {read_chan+926} > {default_wake_function+0} {default_wake_function+0} > {tty_ldisc_deref+117} {tty_read+256} > {vfs_read+199} {sys_read+83} > {system_call+126} > getty S 000001023e7c2d28 0 3078 1 3079 3077 (NOTLB) > 000001023d86bd78 0000000000000002 000000000000001c ffffffff801575ea > 000000743e7c2000 000000000000001b 000001023d804030 0000000000000074 > 00000101438619c0 0000000180157610 > Call Trace:{do_generic_mapping_read+1034} {release_console_sem+138} > {do_con_write+1657} {schedule_timeout+37} > {add_wait_queue+28} {read_chan+926} > {default_wake_function+0} {default_wake_function+0} > {tty_ldisc_deref+117} {tty_read+256} > {vfs_read+199} {sys_read+83} > {system_call+126} > getty S 000001023df85d28 0 3079 1 3080 3078 (NOTLB) > 000001023d88dd78 0000000000000006 000000000000001c ffffffff801575ea > 000000743df85000 000000000000001b 000001023d877810 0000000000000074 > 00000101438619c0 0000000180157610 > Call Trace:{do_generic_mapping_read+1034} {release_console_sem+138} > {do_con_write+1657} {schedule_timeout+37} > {add_wait_queue+28} {read_chan+926} > {default_wake_function+0} {default_wake_function+0} > {tty_ldisc_deref+117} {tty_read+256} > {vfs_read+199} {sys_read+83} > {system_call+126} > getty S 000001023e770d28 0 3080 1 5390 3079 (NOTLB) > 000001023d8a1d78 0000000000000002 000000000000001c ffffffff801575ea > 000001023e770000 000000000000001b 0000000000000000 0000000000000000 > 000001023da29348 0000000180157610 > Call Trace:{do_generic_mapping_read+1034} {do_con_write+1657} > {schedule_timeout+37} {add_wait_queue+28} > {read_chan+926} {default_wake_function+0} > {default_wake_function+0} {tty_ldisc_deref+117} > {tty_read+256} {vfs_read+199} > {sys_read+83} {system_call+126} > > mysqld D 000001023e034d80 0 5390 1 7663 3080 (NOTLB) > 0000010211817c88 0000000000000002 0000010211817c98 000000003b98c02b > 0000007400000000 0000000000000000 000001023f7d87d0 0000000000000074 > 00000101438619c0 0000000100000001 > Call Trace:{try_to_wake_up+528} {__down_write+132} > {:xfs:xfs_ilock+44} {:xfs:xfs_write+594} > {__alloc_pages+831} {:xfs:linvfs_write+101} > {do_sync_write+173} {handle_mm_fault+260} > {__up_read+29} {thread_return+41} > {autoremove_wake_function+0} {vfs_write+199} > {sys_pwrite64+104} {system_call+126} > > sshd S 0000000000000198 0 6952 3051 6954 8569 (NOTLB) > 00000101ed1e5d88 0000000000000002 00000101ed1e5ce8 0000010191826278 > 000000000055ba80 00000000659d37d0 0000000000000007 ffffffff8015ae20 > 00000101ed1e5de8 0000000000000246 > Call Trace:{buffered_rmqueue+432} {schedule_timeout+37} > {add_wait_queue+28} {:unix:unix_poll+21} > {do_select+819} {__pollwait+0} > {sys_select+960} {system_call+126} > > bash S 00000100dbcffd28 0 6954 6952 (NOTLB) > 000001007b57dd78 0000000000000002 000000003ff0da00 00000100000129d0 > 000000740000000f 0000010000012700 00000101fd69a070 0000000000000074 > 000001000c004740 000000008015a913 > Call Trace:{free_pages_bulk+663} {schedule_timeout+37} > {add_wait_queue+28} {read_chan+926} > {default_wake_function+0} {default_wake_function+0} > {remove_wait_queue+25} {tty_read+256} > {vfs_read+199} {sys_read+83} > {system_call+126} > mysqld D 000001022b239db8 0 7663 1 8657 5390 (NOTLB) > 000001009c017ae8 0000000000000002 00000102297ae070 0000000000000001 > 000000743ff0d180 00000102297ae070 00000101a76b4030 0000000000000074 > 00000101438619c0 00000001297ae070 > Call Trace:{__down+152} {default_wake_function+0} > {__down_read+130} {__down_failed+53} > {.text.lock.direct_io+15} {__mod_timer+303} > {:xfs:linvfs_direct_IO+186} {:xfs:linvfs_get_blocks_direct+0} > {:xfs:linvfs_unwritten_convert_direct+0} > {cleanup_rbuf+242} {generic_file_direct_IO+100} > {__generic_file_aio_read+214} {__up_read+29} > {:xfs:xfs_read+447} {:xfs:linvfs_read+99} > {setup_rt_frame+143} {do_sync_read+173} > {finish_task_switch+64} {thread_return+41} > {autoremove_wake_function+0} {vfs_read+199} > {sys_pread64+104} {system_call+126} > > pickup S 0000000000000060 0 8534 3035 3040 (NOTLB) > 00000100b49e5d88 0000000000000002 0000000000000216 ffffffff802425b4 > 000001013ff84c2c 000001013ff84c2c 0000000000000007 ffffffff8015ae20 > 0000000800000007 0000000100000246 > Call Trace:{sock_def_readable+68} {buffered_rmqueue+432} > {__mod_timer+303} {schedule_timeout+173} > {process_timeout+0} {do_select+819} > {__pollwait+0} {sys_select+960} > {system_call+126} > sshd S 0000000000000198 0 8569 3051 8571 6952 (NOTLB) > 000001015cffbd88 0000000000000006 000001015cffbce8 0000010005848778 > 0000007300573390 0000000011120810 0000010211120810 0000000000000073 > 00000101438619c0 0000000100000246 > Call Trace:{schedule_timeout+37} {add_wait_queue+28} > {:unix:unix_poll+21} {do_select+819} > {__pollwait+0} {sys_select+960} > {system_call+126} > bash R running task 0 8571 8569 (NOTLB) > mysqld D 0000000000000000 0 8657 1 8658 7663 (NOTLB) > 0000010146e07e80 0000000000000006 0000010146e07e18 0000010146e07e08 > 000001023f6c33c0 0000000000000101 000001022b22ac18 0000010146e07e18 > ffffffff8018fb11 0000000100000000 > Call Trace:{dput+33} {permission+37} > {may_open+95} {__down+152} > {default_wake_function+0} {__down_failed+53} > {.text.lock.read_write+5} {vfs_llseek+50} > {sys_lseek+82} {system_call+126} > > mysqld Z 000001005b0edf58 0 8658 8657 (L-TLB) > 000001005b0edde8 0000000000000046 0000000000000001 0000000000000010 > 0000007a0c3d7070 0000000000000010 000001007f5c4030 000000000000007a > 00000101438619c0 0000000100000001 > Call Trace:{exit_notify+2039} {do_exit+1003} > {do_group_exit+252} {get_signal_to_deliver+1082} > {sysret_signal+28} {do_signal+142} > {poll_freewait+76} {sys_poll+526} > {__pollwait+0} {ptregscall_common+103} > > > > > > > On Sun, 14 Nov 2004, Brad Fitzpatrick wrote: > > > We have two database servers which freeze up during heavy IO load. The > > machines themselves are responsible, but the mysqld processes are forever > > locked, unkillable with even kill -9. I can't restart with MySQL without > > rebooting the machines. > > > > I can reasonable rule out hardware, since this is happening in the > > same way on two identical machines. > > > > I'd like to know how I can debug this, to file a proper bug report. > > > > The hardware/software stack is: > > > > - Dual Opteron 246, SMP kernel, w/ NUMA > > - 9 GB of memory (4GB in one zone, 5GB in the other) > > - MySQL, running mostly InnoDB, but some MyISAM > > - MegaRAID raid-10 > > - device mapper > > - XFS (used as both O_DIRECT from InnoDB and regularly from MyISAM) > > > > At this point I'm going to try changing different variables on > > different machines in order to try and isolate it, but it's a slow > > process. > > > > - on raw partions, instead of device mapper > > - ext3 instead of XFS > > - not using O_DIRECT > > > > "Screenshot": > > > > roast:~# killall -9 mysqld > > roast:~# killall -9 mysqld > > roast:~# ps afx | grep mysqld > > 31495 ? D 0:08 /usr/local/mysql/bin/mysqld --defaults-extra-file=/usr/local/mysql/data/my.cnf --basedir=/usr/local/mysql/ --datadir=/data/mydb --user=root > > --pid-file=/var/run/mysqld/mysqld.pid --skip-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock > > 32391 ? D 0:01 /usr/local/mysql/bin/mysqld --defaults-extra-file=/usr/local/mysql/data/my.cnf --basedir=/usr/local/mysql/ --datadir=/data/mydb --user=root > > --pid-file=/var/run/mysqld/mysqld.pid --skip-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock > > 515 ? D 0:00 /usr/local/mysql/bin/mysqld --defaults-extra-file=/usr/local/mysql/data/my.cnf --basedir=/usr/local/mysql/ --datadir=/data/mydb --user=root > > --pid-file=/var/run/mysqld/mysqld.pid --skip-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock > > 517 ? Z 0:00 \_ [mysqld] > > > > Next time it hangs like this, how can I get a kernel backtrace or other useful information > > for a certain process? > > > > Thanks! > > > > - Brad > > > > - > > 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/ > > > > > - > 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 Tue Nov 16 21:57:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Nov 2004 21:57:54 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAH5vn1b008830 for ; Tue, 16 Nov 2004 21:57:50 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA07445; Wed, 17 Nov 2004 16:57:22 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAH5vIln6041184; Wed, 17 Nov 2004 16:57:19 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iAH4t9I3002017; Wed, 17 Nov 2004 15:55:10 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iAH4t6ri002015; Wed, 17 Nov 2004 15:55:06 +1100 Date: Wed, 17 Nov 2004 15:55:06 +1100 From: Nathan Scott To: Brad Fitzpatrick , Andrew Morton Cc: linux-kernel@vger.kernel.org, lisa@danga.com, marksmith@danga.com, linux-xfs@oss.sgi.com Subject: Re: 2.6.9: unkillable processes during heavy IO Message-ID: <20041117045506.GA1802@frodo> References: <20041116200156.2b2526e5.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041116200156.2b2526e5.akpm@osdl.org> User-Agent: Mutt/1.5.3i X-archive-position: 4443 X-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: 1000 Lines: 34 On Tue, Nov 16, 2004 at 08:01:56PM -0800, Andrew Morton wrote: > Brad Fitzpatrick wrote: > > > > Here is the information requested regarding the regular lockup we're > > seeing (details in original post at bottom) > > yup, that looks like a locking tangle in the XFS direct-io code. > > Nathan, this is 2.6.9. Hmmm, yeah, looks like it - bother. > > On Sun, 14 Nov 2004, Brad Fitzpatrick wrote: > > > > > We have two database servers which freeze up during heavy IO load. The Brad, could you send me details on how you've setup mysqld and how to generate a load similar to yours, so that I can reproduce the hang locally? > > > The hardware/software stack is: > > > > > > - Dual Opteron 246, SMP kernel, w/ NUMA > > > - 9 GB of memory (4GB in one zone, 5GB in the other) > > > - MySQL, running mostly InnoDB, but some MyISAM ( I don't even know what those two things are, so you can probably guess at the level of assistance I'll need here. :) thanks! -- Nathan From owner-linux-xfs Tue Nov 16 23:01:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 16 Nov 2004 23:01:03 -0800 (PST) Received: from danga.com (danga.com [66.150.15.140]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAH710Xj010542 for ; Tue, 16 Nov 2004 23:01:01 -0800 Received: by danga.com (Postfix, from userid 1000) id A64333BC0AD; Tue, 16 Nov 2004 23:00:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by danga.com (Postfix) with ESMTP id 908AA87C121; Tue, 16 Nov 2004 23:00:41 -0800 (PST) Date: Tue, 16 Nov 2004 23:00:41 -0800 (PST) From: Brad Fitzpatrick X-X-Sender: bradfitz@danga.com To: Nathan Scott Cc: Andrew Morton , linux-kernel@vger.kernel.org, Lisa Phillips , Mark Smith , linux-xfs@oss.sgi.com Subject: Re: 2.6.9: unkillable processes during heavy IO In-Reply-To: <20041117045506.GA1802@frodo> Message-ID: References: <20041116200156.2b2526e5.akpm@osdl.org> <20041117045506.GA1802@frodo> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4444 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brad@danga.com Precedence: bulk X-list: linux-xfs Content-Length: 1734 Lines: 63 Nathan, On Wed, 17 Nov 2004, Nathan Scott wrote: > > > On Sun, 14 Nov 2004, Brad Fitzpatrick wrote: > > > > > > > We have two database servers which freeze up during heavy IO load. The > > Brad, could you send me details on how you've setup mysqld > and how to generate a load similar to yours, so that I can > reproduce the hang locally? The MySQL people made a tool to reproduce MySQL-like load for the specific purpose of not putting you through the database setup pain: http://sysbench.sourceforge.net/ To simulate our InnoDB: -- use the tool to do "seqwr" and write out a 50GB file or so -- use the tool to make another file, about 30GB. -- use the tool to do "rndrw" to do random I/O over that 50 GB file, with the O_DIRECT flag on, with a bunch of threads doing 16k reads/writes. -- use the tool to do random IO w/o O_DIRECT on the smaller file at the same time as the O_DIRECT run, also with a number of threads, doing smaller reads/writes. This is happening on a machine with LVM2, as well as directly on /dev/sdb2 (an IBM ServeRAID), so device-mapper shouldn't be an issue one way or another. The filesystem size is 270 GB on one machine (on /dev/sdb2) and 120 GB on LVM2. > > > > The hardware/software stack is: > > > > > > > > - Dual Opteron 246, SMP kernel, w/ NUMA > > > > - 9 GB of memory (4GB in one zone, 5GB in the other) > > > > - MySQL, running mostly InnoDB, but some MyISAM > > ( I don't even know what those two things are, so you can > probably guess at the level of assistance I'll need here. :) Well, sysbench should help you find the problem. Let me know if I can help more. Thanks for looking into this. - Brad > > thanks! > > -- > Nathan > > From owner-linux-xfs Wed Nov 17 09:03:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Nov 2004 09:03:57 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAHH3tRk027134 for ; Wed, 17 Nov 2004 09:03:55 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAHH3tZ6027133 for linux-xfs@oss.sgi.com; Wed, 17 Nov 2004 09:03:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAHH3rVA027121 for ; Wed, 17 Nov 2004 09:03:53 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAHGCscj022978; Wed, 17 Nov 2004 08:12:54 -0800 Date: Wed, 17 Nov 2004 08:12:54 -0800 Message-Id: <200411171612.iAHGCscj022978@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 387] New: Filesystem corruption with large filesystem on FC3 X-Bugzilla-Reason: AssignedTo X-archive-position: 4445 X-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: 1919 Lines: 50 http://oss.sgi.com/bugzilla/show_bug.cgi?id=387 Summary: Filesystem corruption with large filesystem on FC3 Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: davidc@ccmi.salk.edu Hardware: Tyan S2665 motherboard, 4GB RAM, 2x Xeon CPU, IDE drive /dev/hda as system disk. 3Ware 9000 RAID controller running 12 Maxtor 250GB SATA disks (2.8TB). FC2 installed and parted used to create one large volume on /dev/sda1. mkfs.xfs used to create XFS filesystem: mkfs.xfs -i size=512 -f /dev/sda1 Volume mounted and large quantity of test data copied onto it. All seemed OK until the FC3 update, when the FC3 installer complained that /dev/sda1 was not formatted. Removed /dev/sda1 from fstab and installed FC3 as update Tried to mount existing volume /dev/sda1 - mount gives message: mount: /dev/sda1: can't read superblock Ran xfs_check. Received the following messages: XFS: totally zeroed log can't seek in filesystem at bb 2870001664 can't read btree block 17/2092163 extent count for ino 46904 data fork too low (0) for file format bad nblocks 5247 for inode 46904, counted 0 bad nextents 33 for inode 46904, counted 0 /usr/sbin/xfs_check: line 56: 3132 Segmentation fault xfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1 Repeated parted and mkfs.xfs step to recreate partition and filesystem (comes out as 2.4 TB or so). Repeated copy of about 500GB data to filesystem. Unmounted volume. Remounted volume - okay. Rebooted. Volume will not now remount and I get the same messages from xfs_check. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Nov 17 13:03:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Nov 2004 13:03:58 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAHL3tAO006463 for ; Wed, 17 Nov 2004 13:03:55 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAHL3t0C006462 for linux-xfs@oss.sgi.com; Wed, 17 Nov 2004 13:03:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAHL3sRX006447 for ; Wed, 17 Nov 2004 13:03:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAHKdomp006043; Wed, 17 Nov 2004 12:39:50 -0800 Date: Wed, 17 Nov 2004 12:39:50 -0800 Message-Id: <200411172039.iAHKdomp006043@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 387] Filesystem corruption with large filesystem on FC3 X-Bugzilla-Reason: AssignedTo X-archive-position: 4446 X-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: 352 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=387 ------- Additional Comments From sandeen@sgi.com 2004-17-11 12:39 PDT ------- What partition editor did you use, and what does /proc/partitions say before and after the reboot? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Nov 17 14:03:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Nov 2004 14:03:59 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAHM3tlb009424 for ; Wed, 17 Nov 2004 14:03:55 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAHM3tNp009423 for linux-xfs@oss.sgi.com; Wed, 17 Nov 2004 14:03:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAHM3sjb009411 for ; Wed, 17 Nov 2004 14:03:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAHLntcp008999; Wed, 17 Nov 2004 13:49:55 -0800 Date: Wed, 17 Nov 2004 13:49:55 -0800 Message-Id: <200411172149.iAHLntcp008999@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 387] Filesystem corruption with large filesystem on FC3 X-Bugzilla-Reason: AssignedTo X-archive-position: 4447 X-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: 1651 Lines: 53 http://oss.sgi.com/bugzilla/show_bug.cgi?id=387 ------- Additional Comments From davidc@ccmi.salk.edu 2004-17-11 13:49 PDT ------- I used parted to create the partitions - parted-1.6.15-5 - since fdisk would not create anything that would format past 2 GB. Commands to parted were mkpart primary 1 -1 (or similar - used 1 and -1 to get beginning and end of disk) Output from /proc/partitions is as follows: Before the corruption: major minor #blocks name 3 0 120060864 hda 3 1 102280 hda1 3 2 117910800 hda2 3 3 2047752 hda3 8 0 2685427712 sda 8 1 2685425368 sda1 After the reboot (admittedly I did run a mkfs.xfs on this again...) major minor #blocks name 3 0 120060864 hda 3 1 102280 hda1 3 2 117910800 hda2 3 3 2047752 hda3 8 0 2685427712 sda 8 1 537941720 sda1 I just repartitioned the disk and remade the xfs filesystem... mkfs.xfs tells me: [root@bfg2 ~]# mkfs.xfs -i size=512 -f /dev/sda1 meta-data=/dev/sda1 isize=512 agcount=32, agsize=20979885 blks = sectsz=512 data = bsize=4096 blocks=671356320, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Nov 17 15:03:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Nov 2004 15:03:57 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAHN3tl0010882 for ; Wed, 17 Nov 2004 15:03:55 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAHN3tZ5010881 for linux-xfs@oss.sgi.com; Wed, 17 Nov 2004 15:03:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAHN3sIR010867 for ; Wed, 17 Nov 2004 15:03:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAHMb17m010361; Wed, 17 Nov 2004 14:37:01 -0800 Date: Wed, 17 Nov 2004 14:37:01 -0800 Message-Id: <200411172237.iAHMb17m010361@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 387] Filesystem corruption with large filesystem on FC3 X-Bugzilla-Reason: AssignedTo X-archive-position: 4448 X-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: 860 Lines: 30 http://oss.sgi.com/bugzilla/show_bug.cgi?id=387 ------- Additional Comments From sandeen@sgi.com 2004-17-11 14:37 PDT ------- major minor #blocks name 8 0 2685427712 sda 8 1 2685425368 sda1 After the reboot (admittedly I did run a mkfs.xfs on this again...) major minor #blocks name 8 0 2685427712 sda 8 1 537941720 sda1 Houston, we have a problem, but it's not in xfs. Your partition has shrunk after a reboot! XFS will have a hard time coping... What happens if you tell parted to "print" before and after the reboot? Is it consistent with what you asked it to write to disk? Although this isn't an xfs bug I am interested in the problem, because I/we use large devices around here too.... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Nov 17 16:25:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Nov 2004 16:25:36 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAI0PV8E017282 for ; Wed, 17 Nov 2004 16:25:33 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA29375; Thu, 18 Nov 2004 11:25:03 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAI0P0ln6061992; Thu, 18 Nov 2004 11:25:01 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iAHNMote010127; Thu, 18 Nov 2004 10:22:51 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iAHNMlwv010125; Thu, 18 Nov 2004 10:22:47 +1100 Date: Thu, 18 Nov 2004 10:22:47 +1100 From: Nathan Scott To: Miquel van Smoorenburg Cc: linux-xfs@oss.sgi.com Subject: Re: [REPOST] [PATCH] fs/xfs/linux-2.6/kmem.c Message-ID: <20041117232247.GA9834@frodo> References: <20041115103130.GA7971@cistron.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041115103130.GA7971@cistron.nl> User-Agent: Mutt/1.5.3i X-archive-position: 4449 X-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: 1388 Lines: 34 On Mon, Nov 15, 2004 at 11:31:32AM +0100, Miquel van Smoorenburg wrote: > I've sent this to the list a month ago, but I think it was overlooked. Sorry about that. > I think this (actually, the second patch) should go as a bugfix > into 2.6.10 .. So I'm reposting it, if I'm completely wrong about > this tell me and I'll shut up. Thanks! Yep, I agree we can certainly improve things, and your patches are a move in the right direction. A couple of things: - I'd prefer to keep the loop, we've been bitten before by "nofail" allocations, uhm, failing, and ultimately causing corruption. - should also consider printk_ratelimit, but not clear if that'd be better "in addition to" or "in place of" the approaches you've taken so far here. - it'd be better to keep the manipulation of "retries", esp. the modulo part till after the first allocation attempt, since the usual case is for the allocation to succeed, so the fewer instructions we add in beforehand the better. - theres a similar spot in xfs_buf.c where we need to retry page cache allocations when initial attempts don't work out - maybe the block_congestion check would be useful there too? Not clear to me yet though, we may get ourselves in a bind adding that there, but probably not. Could you propose a new patch taking these into account? I think that'd get us close to something we can merge. thanks! -- Nathan From owner-linux-xfs Wed Nov 17 17:03:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Nov 2004 17:03:58 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAI13u5p018468 for ; Wed, 17 Nov 2004 17:03:56 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAI13u8R018467 for linux-xfs@oss.sgi.com; Wed, 17 Nov 2004 17:03:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAI13svq018455 for ; Wed, 17 Nov 2004 17:03:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAI0W8oM017719; Wed, 17 Nov 2004 16:32:08 -0800 Date: Wed, 17 Nov 2004 16:32:08 -0800 Message-Id: <200411180032.iAI0W8oM017719@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 387] Filesystem corruption with large filesystem on FC3 X-Bugzilla-Reason: AssignedTo X-archive-position: 4450 X-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: 1587 Lines: 46 http://oss.sgi.com/bugzilla/show_bug.cgi?id=387 davidc@ccmi.salk.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From davidc@ccmi.salk.edu 2004-17-11 16:32 PDT ------- Well, I'm pleased it's not an XFS bug, anyway! And I can *still* say I have never lost a single byte using XFS! :-) :-) Print from parted gives the wrong value after reboot, **and even after a fresh create!** viz:- (parted) mkpart primary 1 -1 (parted) p Disk geometry for /dev/sda: 0.000-2622488.000 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.031 525333.742 primary xfs Note: (1) parted seems to know the FS is xfs, even though I removed the original partition and made a new label and partition (??). (2) after this create, /proc/partitions displays "8 1 2685425368 sda1" which is what I expected. (3) **I can now mount the filesystem** and see old data there even though I never wrote anything or created a filesystem!!!!!... xfs_check now produces no errors. (4) After a reboot, xfs_check finds lots of errors. (5) Go back into parted, remove partition, recreate it and presto!, all the data is back and xfs_check is happy once more. Hmm, sounds maybe like a parted bug? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Nov 17 22:07:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 17 Nov 2004 22:07:51 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAI67lCV017209 for ; Wed, 17 Nov 2004 22:07:48 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA06327; Thu, 18 Nov 2004 17:07:19 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAI67Hln6069894; Thu, 18 Nov 2004 17:07:17 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iAI556te011002; Thu, 18 Nov 2004 16:05:07 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iAI551bt011000; Thu, 18 Nov 2004 16:05:01 +1100 Date: Thu, 18 Nov 2004 16:05:01 +1100 From: Nathan Scott To: Brad Fitzpatrick Cc: Andrew Morton , linux-kernel@vger.kernel.org, Lisa Phillips , Mark Smith , linux-xfs@oss.sgi.com Subject: Re: 2.6.9: unkillable processes during heavy IO Message-ID: <20041118050501.GD9834@frodo> References: <20041116200156.2b2526e5.akpm@osdl.org> <20041117045506.GA1802@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 4451 X-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: 604 Lines: 22 On Tue, Nov 16, 2004 at 11:00:41PM -0800, Brad Fitzpatrick wrote: > > Brad, could you send me details on how you've setup mysqld > > and how to generate a load similar to yours, so that I can > > reproduce the hang locally? > > The MySQL people made a tool to reproduce MySQL-like load for the specific > purpose of not putting you through the database setup pain: Ah, fantastic. I've reproduced it now with this tool and a simplified version of your recipe - I'll have a fix for you to try before too long. > Well, sysbench should help you find the problem. Yep, it sure did. thanks! -- Nathan From owner-linux-xfs Thu Nov 18 03:17:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 03:17:21 -0800 (PST) Received: from out.smtp.cz (ender.smtp.cz [81.95.97.119]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIBHGNP001648 for ; Thu, 18 Nov 2004 03:17:17 -0800 Received: (qmail 23339 invoked from network); 18 Nov 2004 11:16:51 -0000 Received: from unknown (HELO shade.office.globe.cz) (ondrej@sury.org@81.95.104.4) by ender.smtp.cz with RC4-MD5 encrypted SMTP; 18 Nov 2004 11:16:51 -0000 Subject: nfsd: non-standard errno: -990 From: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= To: linux-xfs@oss.sgi.com Content-Type: text/plain; charset=UTF-8 Date: Thu, 18 Nov 2004 12:16:54 +0100 Message-Id: <1100776614.4833.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 8bit X-archive-position: 4452 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ondrej@sury.org Precedence: bulk X-list: linux-xfs Content-Length: 1736 Lines: 49 Hello, after moving filesystem from one physical location to another, we are experiencing /subj errors. Filesystem is located on LVM2 volume on SCSI RAID10. We did dd old_system new_system and used xfs_growfs to enlarge filesystem to match physical location. Full error is: Filesystem "dm-3": corrupt dinode 204364567, extent total = 6, nblocks = 0. Unmount and run xfs_repair. 0x0: 49 4e 81 80 01 02 00 01 00 00 fa 14 00 00 fa 14 Filesystem "dm-3": XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c. Caller 0xc0234965 [] xfs_iformat+0x2b5/0x5c2 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iread+0x1cf/0x218 [] xfs_iget_core+0xf9/0x5c3 [] xfs_iget+0x162/0x199 [] xfs_dir_lookup_int+0xb4/0x12b [] xfs_lookup+0x50/0x88 [] linvfs_lookup+0x58/0x96 [] __lookup_hash+0xa6/0xd6 [] lookup_hash+0x1f/0x23 [] lookup_one_len+0x67/0x74 [] nfsd_lookup+0xcf/0x4db [] nfsd3_proc_lookup+0xa1/0xe0 [] nfsd_dispatch+0xd9/0x1fa [] svc_process+0x56a/0x784 [] default_wake_function+0x0/0x12 [] nfsd+0x1f3/0x391 [] nfsd+0x0/0x391 [] kernel_thread_helper+0x5/0xb nfsd: non-standard errno: -990 Our current plan is to add another SCSI RAID10 volume to system and use xfs_dump/restore (xfs_copy) to do a logical (not physical) copy of storage. And if there is some quicker way how to fix this error (I haven't found an solution using archive)? It seems that there definetely exists bug when: (0. moving filesystem) 1. using LVM 2. using xfs_growfs Regards, -- OndÅ™ej Surý From owner-linux-xfs Thu Nov 18 06:06:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 06:06:48 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIE6h7Z008631 for ; Thu, 18 Nov 2004 06:06:43 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAIFOARd005286 for ; Thu, 18 Nov 2004 07:24:10 -0800 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAIE6Nad2246408; Thu, 18 Nov 2004 06:06:23 -0800 (PST) Message-ID: <419CAC5E.6070806@sgi.com> Date: Thu, 18 Nov 2004 08:06:22 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ondrej@sury.org CC: linux-xfs@oss.sgi.com Subject: Re: nfsd: non-standard errno: -990 References: <1100776614.4833.22.camel@localhost.localdomain> In-Reply-To: <1100776614.4833.22.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 4453 X-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: 720 Lines: 18 Just to get the obvious things out of the way.... was the source filesystem unmounted when you dd'd it to the new one? -Eric OndÅ™ej Surý wrote: > Hello, > > after moving filesystem from one physical location to another, we are > experiencing /subj errors. Filesystem is located on LVM2 volume on SCSI > RAID10. We did dd old_system new_system and used xfs_growfs to enlarge > filesystem to match physical location. > > Full error is: > Filesystem "dm-3": corrupt dinode 204364567, extent total = 6, nblocks = 0. Unmount and run xfs_repair. > 0x0: 49 4e 81 80 01 02 00 01 00 00 fa 14 00 00 fa 14 > Filesystem "dm-3": XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c. Caller 0xc0234965 From owner-linux-xfs Thu Nov 18 06:13:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 06:13:22 -0800 (PST) Received: from out.smtp.cz (ender.smtp.cz [81.95.97.119]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIEDHAx009017 for ; Thu, 18 Nov 2004 06:13:17 -0800 Received: (qmail 28031 invoked from network); 18 Nov 2004 14:12:53 -0000 Received: from unknown (HELO shade.office.globe.cz) (ondrej@sury.org@81.95.104.4) by ender.smtp.cz with RC4-MD5 encrypted SMTP; 18 Nov 2004 14:12:53 -0000 Subject: Re: nfsd: non-standard errno: -990 From: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= To: linux-xfs@oss.sgi.com In-Reply-To: <419CAC5E.6070806@sgi.com> References: <1100776614.4833.22.camel@localhost.localdomain> <419CAC5E.6070806@sgi.com> Content-Type: text/plain; charset=UTF-8 Date: Thu, 18 Nov 2004 15:12:55 +0100 Message-Id: <1100787175.4833.35.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 8bit X-archive-position: 4454 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ondrej@sury.org Precedence: bulk X-list: linux-xfs Content-Length: 968 Lines: 28 Yep, it was. Sorry, I could mention that, but it seemed so obvious :-). Ondrej. On Thu, 2004-11-18 at 08:06 -0600, Eric Sandeen wrote: > Just to get the obvious things out of the way.... was the source > filesystem unmounted when you dd'd it to the new one? > > -Eric > > OndÅ™ej Surý wrote: > > Hello, > > > > after moving filesystem from one physical location to another, we are > > experiencing /subj errors. Filesystem is located on LVM2 volume on SCSI > > RAID10. We did dd old_system new_system and used xfs_growfs to enlarge > > filesystem to match physical location. > > > > Full error is: > > Filesystem "dm-3": corrupt dinode 204364567, extent total = 6, nblocks = 0. Unmount and run xfs_repair. > > 0x0: 49 4e 81 80 01 02 00 01 00 00 fa 14 00 00 fa 14 > > Filesystem "dm-3": XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c. Caller 0xc0234965 > > !DSPAM:419cac3c304281625398520! > -- OndÅ™ej Surý From owner-linux-xfs Thu Nov 18 08:29:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 08:29:21 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:DvKo9DcozztxcARYji/Q+SPsJjLrDZsU@burgers.bubbanfriends.org [69.212.163.241]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIGTJU2017706 for ; Thu, 18 Nov 2004 08:29:19 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id BE21A1803654 for ; Thu, 18 Nov 2004 11:28:59 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13766-09 for ; Thu, 18 Nov 2004 11:28:59 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 5E49E180009B; Thu, 18 Nov 2004 11:28:59 -0500 (EST) To: linux-xfs@oss.sgi.com Subject: 2GB filesize limit? Message-Id: <20041118162859.5E49E180009B@burgers.bubbanfriends.org> Date: Thu, 18 Nov 2004 11:28:59 -0500 (EST) From: mburger@bubbanfriends.org (Mike Burger) X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-archive-position: 4455 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 392 Lines: 10 I'm (still) running RHL9 with Axel Thimm's 2.4.20-35_39 kernel, and ran into a 2GB filesize limitation while trying to download the FC3 DVD ISO file, which weighs in at about 2.6GB. Quotas are enabled, but I currently have hard and soft limits set to unlimited. I was under the impression that this would not be an issue. Any help in overcoming this issue would be greatly appreciated. From owner-linux-xfs Thu Nov 18 08:41:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 08:41:47 -0800 (PST) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIGfiIR018286 for ; Thu, 18 Nov 2004 08:41:45 -0800 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.1/8.13.1/Debian-16) with ESMTP id iAIGfUI7016598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2004 11:41:31 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.1/8.13.1/Submit) with ESMTP id iAIGfUPq016595; Thu, 18 Nov 2004 11:41:30 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Thu, 18 Nov 2004 11:41:30 -0500 (EST) From: Net Llama! To: Mike Burger cc: linux-xfs@oss.sgi.com Subject: Re: 2GB filesize limit? In-Reply-To: <20041118162859.5E49E180009B@burgers.bubbanfriends.org> Message-ID: References: <20041118162859.5E49E180009B@burgers.bubbanfriends.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Thu, 18 Nov 2004 11:41:32 -0500 X-archive-position: 4456 X-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: 556 Lines: 13 On Thu, 18 Nov 2004, Mike Burger wrote: > I'm (still) running RHL9 with Axel Thimm's 2.4.20-35_39 kernel, and ran into > a 2GB filesize limitation while trying to download the FC3 DVD ISO file, > which weighs in at about 2.6GB. Using what for the download? What was the error? wget didn't support greater than 2GB until very recently. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Thu Nov 18 09:14:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 09:14:06 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:fb1s90LOhExHTSEmNNGnbnyvIe+jy4da@burgers.bubbanfriends.org [69.212.163.241]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIHE2c7020722 for ; Thu, 18 Nov 2004 09:14:03 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 9D46E1803654; Thu, 18 Nov 2004 12:13:43 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15441-02; Thu, 18 Nov 2004 12:13:43 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 444F2180009B; Thu, 18 Nov 2004 12:13:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 439061C0A088; Thu, 18 Nov 2004 12:13:43 -0500 (EST) Date: Thu, 18 Nov 2004 12:13:43 -0500 (EST) From: Mike Burger To: Net Llama! Cc: linux-xfs@oss.sgi.com Subject: Re: 2GB filesize limit? In-Reply-To: Message-ID: References: <20041118162859.5E49E180009B@burgers.bubbanfriends.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-archive-position: 4457 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 806 Lines: 31 wget, it was. Nerts...have to try another way, I guess...thanks. On Thu, 18 Nov 2004, Net Llama! wrote: > On Thu, 18 Nov 2004, Mike Burger wrote: > > I'm (still) running RHL9 with Axel Thimm's 2.4.20-35_39 kernel, and ran into > > a 2GB filesize limitation while trying to download the FC3 DVD ISO file, > > which weighs in at about 2.6GB. > > Using what for the download? What was the error? > wget didn't support greater than 2GB until very recently. > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs Thu Nov 18 09:15:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 09:15:46 -0800 (PST) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIHFhD9021046 for ; Thu, 18 Nov 2004 09:15:44 -0800 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.1/8.13.1/Debian-16) with ESMTP id iAIHFUWQ017117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2004 12:15:31 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.1/8.13.1/Submit) with ESMTP id iAIHFTst017113; Thu, 18 Nov 2004 12:15:29 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Thu, 18 Nov 2004 12:15:29 -0500 (EST) From: Net Llama! To: Mike Burger cc: linux-xfs@oss.sgi.com Subject: Re: 2GB filesize limit? In-Reply-To: Message-ID: References: <20041118162859.5E49E180009B@burgers.bubbanfriends.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Thu, 18 Nov 2004 12:15:31 -0500 X-archive-position: 4458 X-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: 826 Lines: 26 You could always grab the SRPM for wget from the FC3 distro (from updates). On Thu, 18 Nov 2004, Mike Burger wrote: > wget, it was. Nerts...have to try another way, I guess...thanks. > > On Thu, 18 Nov 2004, Net Llama! wrote: > > > On Thu, 18 Nov 2004, Mike Burger wrote: > > > I'm (still) running RHL9 with Axel Thimm's 2.4.20-35_39 kernel, and ran into > > > a 2GB filesize limitation while trying to download the FC3 DVD ISO file, > > > which weighs in at about 2.6GB. > > > > Using what for the download? What was the error? > > wget didn't support greater than 2GB until very recently. > > > > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Thu Nov 18 09:16:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 09:16:22 -0800 (PST) Received: from heretic.physik.fu-berlin.de (heretic.physik.fu-berlin.de [160.45.32.228]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIHGJtV021164 for ; Thu, 18 Nov 2004 09:16:19 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.10) with ESMTP id iAIHFl7Q002706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Nov 2004 18:15:49 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.11/8.12.11/Submit) id iAIHFkQd021250; Thu, 18 Nov 2004 18:15:46 +0100 Date: Thu, 18 Nov 2004 18:15:46 +0100 From: Axel Thimm To: Mike Burger Cc: linux-xfs@oss.sgi.com Subject: Re: 2GB filesize limit? Message-ID: <20041118171546.GH16488@neu.nirvana> References: <20041118162859.5E49E180009B@burgers.bubbanfriends.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+G3HLlWI7eRTl+h" Content-Disposition: inline In-Reply-To: <20041118162859.5E49E180009B@burgers.bubbanfriends.org> User-Agent: Mutt/1.4.2i X-archive-position: 4459 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 1156 Lines: 41 --k+G3HLlWI7eRTl+h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 18, 2004 at 11:28:59AM -0500, Mike Burger wrote: > I'm (still) running RHL9 with Axel Thimm's 2.4.20-35_39 kernel, and ran i= nto > a 2GB filesize limitation while trying to download the FC3 DVD ISO file, > which weighs in at about 2.6GB. >=20 > Quotas are enabled, but I currently have hard and soft limits set to=20 > unlimited. >=20 > I was under the impression that this would not be an issue. Any help in= =20 > overcoming this issue would be greatly appreciated. That might be a server side issue (Some apaches have a 2GB barrier). Try dd if=3D/dev/zero of=3D/path/to/xfs/partition/bigfile bs=3D1M count=3D2600 to verify whether the xfs partition can cope with 2GB+. --=20 Axel.Thimm at ATrpms.net --k+G3HLlWI7eRTl+h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBnNjCQBVS1GOamfERAk+sAJ4u+eOJiYaamuja9rvbp5qwW4XGqQCbBewu vJZZA1uuHcFkRePJZV151JQ= =CW1F -----END PGP SIGNATURE----- --k+G3HLlWI7eRTl+h-- From owner-linux-xfs Thu Nov 18 12:20:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 12:20:32 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:lZVDFFGbJHCJ2FloXzn9Rr/dRn/PGzgD@burgers.bubbanfriends.org [69.212.163.241]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIKKT4u001996 for ; Thu, 18 Nov 2004 12:20:29 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 0F45E180009B; Thu, 18 Nov 2004 15:20:09 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20273-06; Thu, 18 Nov 2004 15:20:08 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 00AF21803654; Thu, 18 Nov 2004 15:20:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id D89FE1C0A088; Thu, 18 Nov 2004 15:20:07 -0500 (EST) Date: Thu, 18 Nov 2004 15:20:07 -0500 (EST) From: Mike Burger To: Axel Thimm Cc: linux-xfs@oss.sgi.com Subject: Re: 2GB filesize limit? In-Reply-To: <20041118171546.GH16488@neu.nirvana> Message-ID: References: <20041118162859.5E49E180009B@burgers.bubbanfriends.org> <20041118171546.GH16488@neu.nirvana> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-archive-position: 4460 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 1370 Lines: 46 On Thu, 18 Nov 2004, Axel Thimm wrote: > On Thu, Nov 18, 2004 at 11:28:59AM -0500, Mike Burger wrote: > > I'm (still) running RHL9 with Axel Thimm's 2.4.20-35_39 kernel, and ran into > > a 2GB filesize limitation while trying to download the FC3 DVD ISO file, > > which weighs in at about 2.6GB. > > > > Quotas are enabled, but I currently have hard and soft limits set to > > unlimited. > > > > I was under the impression that this would not be an issue. Any help in > > overcoming this issue would be greatly appreciated. > > That might be a server side issue (Some apaches have a 2GB > barrier). Try > > dd if=/dev/zero of=/path/to/xfs/partition/bigfile bs=1M count=2600 > > to verify whether the xfs partition can cope with 2GB+. Sure enough...it would appear that it's the web server: [mburger@burgers mburger]$ dd if=/dev/zero of=./bigfile bs=1M count=2600 2600+0 records in 2600+0 records out [mburger@burgers mburger]$ ls -l bigfile -rw-rw-r-- 1 mburger mburger 2726297600 Nov 18 15:18 bigfile -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs Thu Nov 18 12:31:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 12:31:09 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIKV7cK002447 for ; Thu, 18 Nov 2004 12:31:07 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAILmaMD024801 for ; Thu, 18 Nov 2004 13:48:36 -0800 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAIKTlad2310601; Thu, 18 Nov 2004 12:29:48 -0800 (PST) Message-ID: <419D063A.4010809@sgi.com> Date: Thu, 18 Nov 2004 14:29:46 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?T25kw7hlaiBTdXLDvQ==?= CC: linux-xfs@oss.sgi.com Subject: Re: nfsd: non-standard errno: -990 References: <1100776614.4833.22.camel@localhost.localdomain> <419CAC5E.6070806@sgi.com> <1100787175.4833.35.camel@localhost.localdomain> In-Reply-To: <1100787175.4833.35.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 4461 X-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: 418 Lines: 13 OndÅ™ej Surý wrote: > Yep, it was. Sorry, I could mention that, but it seemed so obvious :-). You might also try xfs_repair -n on your source disk before dd-ing, and on the target disk afterwards (-n means don't actually change anything...) Can you also test this without the growfs step? Just to take this one step at a time. FWIW, xfs_copy is another tool that might work well for what you're doing. -Eric From owner-linux-xfs Thu Nov 18 13:04:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 13:04:04 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIL40KE003858 for ; Thu, 18 Nov 2004 13:04:00 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAIL40Cg003857 for linux-xfs@oss.sgi.com; Thu, 18 Nov 2004 13:04:00 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIL3wlH003828 for ; Thu, 18 Nov 2004 13:03:58 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAIKnlSP003066; Thu, 18 Nov 2004 12:49:47 -0800 Date: Thu, 18 Nov 2004 12:49:47 -0800 Message-Id: <200411182049.iAIKnlSP003066@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 388] New: XFS on loop volume on raid device => filesystem corrupt X-Bugzilla-Reason: AssignedTo X-archive-position: 4462 X-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: 1452 Lines: 43 http://oss.sgi.com/bugzilla/show_bug.cgi?id=388 Summary: XFS on loop volume on raid device => filesystem corrupt Product: Linux XFS Version: unspecified Platform: All OS/Version: All Status: NEW Severity: critical Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: abc@digithi.de I am using XFS on an encrypted loop devices (loop-aes.sourceforge.net) and that runs on a software RAID 5 system. Raid 5 doesn't support variable length transfers, normally xfs recognizes it and disables variable length transfers, but here xfs only sees a LOOP device, so variable length transfers are enabled and the filesystem gets completely corrupted in this case. I found a solution on another list: http://mail.nl.linux.org/linux-crypto/2003-12/msg00024.html This disables variable length transfers on all loop devices. Up to know, don't know another solution. --- fs/xfs/linux-2.4/xfs_buf.c.orig Sun Aug 8 01:26:06 2004 +++ fs/xfs/linux-2.4/xfs_buf.c Mon Aug 16 23:51:20 2004 @@ -1492,6 +1492,7 @@ switch (MAJOR(btp->pbr_dev)) { case MD_MAJOR: + case LOOP_MAJOR: case EVMS_MAJOR: btp->pbr_flags = PBR_ALIGNED_ONLY; break; ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Nov 18 14:04:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 14:04:02 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIM405E005954 for ; Thu, 18 Nov 2004 14:04:00 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAIM40Wu005953 for linux-xfs@oss.sgi.com; Thu, 18 Nov 2004 14:04:00 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIM3xGE005938 for ; Thu, 18 Nov 2004 14:03:59 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAIM2b29005912; Thu, 18 Nov 2004 14:02:37 -0800 Date: Thu, 18 Nov 2004 14:02:37 -0800 Message-Id: <200411182202.iAIM2b29005912@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 385] xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c X-Bugzilla-Reason: AssignedTo X-archive-position: 4463 X-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: 378 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=385 ------- Additional Comments From sandeen@sgi.com 2004-18-11 14:02 PDT ------- can you look at bug 388... maybe this is the same thing. what's the backing store for your loopback file? Is it lvm or md? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Nov 18 15:00:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 15:00:18 -0800 (PST) Received: from web42301.mail.yahoo.com (web42301.mail.yahoo.com [66.218.93.210]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAIN0Gm6009833 for ; Thu, 18 Nov 2004 15:00:16 -0800 Received: (qmail 55533 invoked by uid 60001); 18 Nov 2004 22:59:52 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=G25f7LKgO4+WaBwgpzcz69knEs+NYRuK6Zg19tSgLUxKAweYdwXbcme8aaZMPuGm0hNY1ZkapmVESHxX9qB3fqFnORQ6auhTq2r5iuHHBBw/hj3uVaCfX6/NYb/hKL34wLWF+NDn43xVOboNoI0qGU8oCkHlAxPz50RyrTrEmR8= ; Message-ID: <20041118225952.55531.qmail@web42301.mail.yahoo.com> Received: from [67.111.242.194] by web42301.mail.yahoo.com via HTTP; Thu, 18 Nov 2004 14:59:52 PST Date: Thu, 18 Nov 2004 14:59:52 -0800 (PST) From: Joseph Davida Subject: Kernel 2.6.x and XFS To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4464 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jd10008@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 711 Lines: 25 On page http://oss.sgi.com/projects/xfs/ the note says: 2004/10/17 Merged all XFS fixes since 2.6.5 into SLES9 Service Pack 1. Thanks Andreas! 1. What is SLES9 service pack 1? Is that publicly available? 2. Do you have complete installable RPMS containing 2.6.x kernel + xfs + modules + source tree. The kernel needs to be for SMP and hugemem (64GB). I have installed 2.4.20-20.9.XFS1.3.1smp, which was not compiled for hugemem, from an rpm package on your download site. I would like to upgrade to kernel 2.6.x as stated above. Cheers, Joe __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-linux-xfs Thu Nov 18 15:13:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 15:13:05 -0800 (PST) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAIND25q010286 for ; Thu, 18 Nov 2004 15:13:03 -0800 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.1/8.13.1/Debian-16) with ESMTP id iAINCoZa020635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Nov 2004 18:12:52 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.1/8.13.1/Submit) with ESMTP id iAINClQx020632; Thu, 18 Nov 2004 18:12:50 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Thu, 18 Nov 2004 18:12:47 -0500 (EST) From: Net Llama! To: Joseph Davida cc: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.x and XFS In-Reply-To: <20041118225952.55531.qmail@web42301.mail.yahoo.com> Message-ID: References: <20041118225952.55531.qmail@web42301.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Thu, 18 Nov 2004 18:12:52 -0500 X-archive-position: 4465 X-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: 1059 Lines: 36 SLES9 is SuSE Linux Enterprise Server 9. On Thu, 18 Nov 2004, Joseph Davida wrote: > On page http://oss.sgi.com/projects/xfs/ > the note says: > 2004/10/17 Merged all XFS fixes since 2.6.5 into SLES9 Service Pack 1. Thanks > Andreas! > > 1. What is SLES9 service pack 1? Is that > publicly available? > 2. Do you have complete installable RPMS > containing 2.6.x kernel + xfs + modules + source tree. > The kernel needs to be for SMP and hugemem (64GB). > > I have installed 2.4.20-20.9.XFS1.3.1smp, > which was not compiled for hugemem, from an rpm > package on your download site. I would like to > upgrade to kernel 2.6.x as stated above. > > Cheers, > > Joe > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs Thu Nov 18 16:04:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 16:04:04 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAJ040Ul013119 for ; Thu, 18 Nov 2004 16:04:00 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAJ040c3013118 for linux-xfs@oss.sgi.com; Thu, 18 Nov 2004 16:04:00 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAJ03xfs013106 for ; Thu, 18 Nov 2004 16:03:59 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAINodUC012264; Thu, 18 Nov 2004 15:50:39 -0800 Date: Thu, 18 Nov 2004 15:50:39 -0800 Message-Id: <200411182350.iAINodUC012264@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 385] xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c X-Bugzilla-Reason: AssignedTo X-archive-position: 4466 X-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: 1609 Lines: 42 http://oss.sgi.com/bugzilla/show_bug.cgi?id=385 ------- Additional Comments From evilninja@gmx.net 2004-18-11 15:50 PDT ------- hm, do you really mean #388? it's about raid5 and "variable length transfers" and there is no error message of the corruptions at all (but a patch?) but i've looked at the bugs #376, #375, #321, #296, #272, #247 but all these xfs_force_shutdown were called from fs/xfs/xfs_trans.c, xfs_bmap.c and xfs_trans_cancel while this here was called from fs/xfs/xfs_rw.c. i did not find these types of xfs_force_shutdown's on the net either. the backing store for the loopback-device is a scsi-disk partition: $ losetup -a /dev/loop7: [0805]:389 (/dev/sdb1) encryption=twofish128 multi-key the kernel said furthermore: xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xc021427c Filesystem "loop7": I/O Error Detected. Shutting down filesystem: loop7 hm, i thought, "i/o errors", could be hardware related then but it seemed unlikely, because sdb2+sdb3 are both in heavy use too, no errors, but not loop mounted too. badblocks showed no errors. i've reformatted loop7 (sdb1) with xfs then, but the errors were still there. right now i have to admit that the device is now formatted with another fs. (erm, it's reiserfs now. i've tried reiserfs some years ago, with no luck and wanted to give it another shot. but i can continue testing with xfs+loop-aes too, if it helps). thank you for your concern, Christian. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Nov 18 19:04:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 19:04:04 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAJ34241024422 for ; Thu, 18 Nov 2004 19:04:02 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAJ342sP024421 for linux-xfs@oss.sgi.com; Thu, 18 Nov 2004 19:04:02 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAJ340Sc024407 for ; Thu, 18 Nov 2004 19:04:00 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAJ24439022174; Thu, 18 Nov 2004 18:04:04 -0800 Date: Thu, 18 Nov 2004 18:04:04 -0800 Message-Id: <200411190204.iAJ24439022174@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 387] Filesystem corruption with large filesystem on FC3 X-Bugzilla-Reason: AssignedTo X-archive-position: 4467 X-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: 440 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=387 ------- Additional Comments From davidc@ccmi.salk.edu 2004-18-11 18:04 PDT ------- Turns out that one needs to use a disklabel called "gpt" and then everything works perfectly... (tested and appears okay) See http://www.3ware.com/kb/article.aspx?id=11920 - David ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Nov 18 20:18:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 20:18:46 -0800 (PST) Received: from localhost.localdomain (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAJ4IeSw027344 for ; Thu, 18 Nov 2004 20:18:41 -0800 Received: from localhost.localdomain (snap [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id iAJ3uPPE002707; Fri, 19 Nov 2004 14:56:25 +1100 Received: (from fsgqa@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id iAJ3uOZJ002706; Fri, 19 Nov 2004 14:56:24 +1100 Date: Fri, 19 Nov 2004 14:56:24 +1100 From: FSG QA Message-Id: <200411190356.iAJ3uOZJ002706@localhost.localdomain> To: linux-xfs@oss.sgi.com, sgi.bugs.kudzu@engr.sgi.com Subject: PARTIAL TAKE 922265 - xfs reservation issues with xlog_sync roundoff X-archive-position: 4468 X-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 Precedence: bulk X-list: linux-xfs Content-Length: 1840 Lines: 45 xfs reservation issues with xlog_sync roundoff This fix is to address the problem with v2 logs, large stripe sizes, and premature flushing of the iclogs, which can cause the grant heads to fall behind the tail of the log. The grant heads falling behind can mean the calculations of how much available space we have for transaction reservations is incorrect. This fixes the assertion failures with the new versions of xfstests/086,087 which tested large stripe sizes and continual sync's after writing (which was forcing out the iclogs prematurely and thus causing large roundoffs). --Tim Date: Fri Nov 19 15:12:31 AEDT 2004 Workarea: snap.melbourne.sgi.com:/home/fsgqa/qa/xfs-linux Inspected by: overby@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:20222a xfsidbg.c - 1.267 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.267&r2=text&tr2=1.266&f=h - Get rid of l_roundoff and ic_roundoff references. xfs_log.c - 1.301 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.301&r2=text&tr2=1.300&f=h - Get rid of l_roundoff and ic_roundoff. Update the GWH and GRH at sync time with the roundoff value instead of waiting until the iclog buffer is reused. Also remove useless flags param to xlog_sync() and have it match its linux counterpart in this regard. xfs_log_priv.h - 1.103 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.103&r2=text&tr2=1.102&f=h - Get rid of l_roundoff and ic_roundoff. Add extra roundoff param to xlog_pack_data(). xfs_log_recover.c - 1.292 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.292&r2=text&tr2=1.291&f=h - Add extra roundoff param to xlog_pack_data(). From owner-linux-xfs Thu Nov 18 22:02:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 18 Nov 2004 22:02:28 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAJ62OxA001690 for ; Thu, 18 Nov 2004 22:02:25 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04676; Fri, 19 Nov 2004 17:01:55 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAJ61rln6069617; Fri, 19 Nov 2004 17:01:53 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iAJ4xflw002167; Fri, 19 Nov 2004 15:59:41 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iAJ4xbj4002165; Fri, 19 Nov 2004 15:59:37 +1100 Date: Fri, 19 Nov 2004 15:59:37 +1100 From: Nathan Scott To: Brad Fitzpatrick Cc: linux-kernel@vger.kernel.org, Lisa Phillips , Mark Smith , linux-xfs@oss.sgi.com Subject: Re: 2.6.9: unkillable processes during heavy IO Message-ID: <20041119045937.GE1269@frodo> References: <20041116200156.2b2526e5.akpm@osdl.org> <20041117045506.GA1802@frodo> <20041118050501.GD9834@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041118050501.GD9834@frodo> User-Agent: Mutt/1.5.3i X-archive-position: 4469 X-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: 308 Lines: 12 On Thu, Nov 18, 2004 at 04:05:01PM +1100, Nathan Scott wrote: > I've reproduced it now with this tool and a simplified version > of your recipe - I'll have a fix for you to try before too long. Looks like a lock order problem - I have an experimental fix, I'll send it to you shortly. thanks. -- Nathan From owner-linux-xfs Fri Nov 19 00:24:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Nov 2004 00:24:07 -0800 (PST) Received: from out.smtp.cz (ender.smtp.cz [81.95.97.119]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAJ8O0ZM010309 for ; Fri, 19 Nov 2004 00:24:01 -0800 Received: (qmail 12626 invoked from network); 19 Nov 2004 08:23:36 -0000 Received: from unknown (HELO shade.office.globe.cz) (ondrej@sury.org@81.95.104.4) by ender.smtp.cz with RC4-MD5 encrypted SMTP; 19 Nov 2004 08:23:36 -0000 Subject: Re: nfsd: non-standard errno: -990 From: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= To: linux-xfs@oss.sgi.com In-Reply-To: <419D063A.4010809@sgi.com> References: <1100776614.4833.22.camel@localhost.localdomain> <419CAC5E.6070806@sgi.com> <1100787175.4833.35.camel@localhost.localdomain> <419D063A.4010809@sgi.com> Content-Type: text/plain; charset=UTF-8 Date: Fri, 19 Nov 2004 09:23:38 +0100 Message-Id: <1100852618.25135.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 8bit X-archive-position: 4470 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ondrej@sury.org Precedence: bulk X-list: linux-xfs Content-Length: 952 Lines: 26 On Thu, 2004-11-18 at 14:29 -0600, Eric Sandeen wrote: > OndÅ™ej Surý wrote: > > Yep, it was. Sorry, I could mention that, but it seemed so obvious :-). > > You might also try xfs_repair -n on your source disk before dd-ing, and > on the target disk afterwards (-n means don't actually change anything...) > > Can you also test this without the growfs step? Just to take this one > step at a time. > > FWIW, xfs_copy is another tool that might work well for what you're doing. The problem is, that action was already done and I cannot replicate it, because it holds production data. Althought I can prepare some test setup and try to replicate the problem. We tried xfs_repair on unmounted system (already with -990 error) and it also crashed with -990. Question is, if xfs_dump/restore will fix the error or not. Or is there some other way how to fix filesystem and not destroy data it holds. Ondrej -- OndÅ™ej Surý From owner-linux-xfs Fri Nov 19 06:05:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Nov 2004 06:05:12 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAJE59ej024422 for ; Fri, 19 Nov 2004 06:05:09 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAJFMiYc007669 for ; Fri, 19 Nov 2004 07:22:44 -0800 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAJE3mad2416148; Fri, 19 Nov 2004 06:03:49 -0800 (PST) Message-ID: <419DFD44.70601@sgi.com> Date: Fri, 19 Nov 2004 08:03:48 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Davida CC: linux-xfs@oss.sgi.com Subject: Re: Kernel 2.6.x and XFS References: <20041118225952.55531.qmail@web42301.mail.yahoo.com> In-Reply-To: <20041118225952.55531.qmail@web42301.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4471 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1004 Lines: 33 sgi isn't providing any 2.6-based kernel rpms at this point; most linux distributions already do that now. I'd look at the various distros (or beta releases of distros) if you need precompiled 2.6 kernel rpms. -Eric Joseph Davida wrote: > On page http://oss.sgi.com/projects/xfs/ > the note says: > 2004/10/17 Merged all XFS fixes since 2.6.5 into SLES9 Service Pack 1. Thanks > Andreas! > > 1. What is SLES9 service pack 1? Is that > publicly available? > 2. Do you have complete installable RPMS > containing 2.6.x kernel + xfs + modules + source tree. > The kernel needs to be for SMP and hugemem (64GB). > > I have installed 2.4.20-20.9.XFS1.3.1smp, > which was not compiled for hugemem, from an rpm > package on your download site. I would like to > upgrade to kernel 2.6.x as stated above. > > Cheers, > > Joe > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > From owner-linux-xfs Fri Nov 19 06:08:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Nov 2004 06:08:06 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAJE84nr024895 for ; Fri, 19 Nov 2004 06:08:04 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAJFPdSU008475 for ; Fri, 19 Nov 2004 07:25:39 -0800 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAJE7iad2422517; Fri, 19 Nov 2004 06:07:45 -0800 (PST) Message-ID: <419DFE30.5050202@sgi.com> Date: Fri, 19 Nov 2004 08:07:44 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?77+9?= CC: linux-xfs@oss.sgi.com Subject: Re: nfsd: non-standard errno: -990 References: <1100776614.4833.22.camel@localhost.localdomain> <419CAC5E.6070806@sgi.com> <1100787175.4833.35.camel@localhost.localdomain> <419D063A.4010809@sgi.com> <1100852618.25135.18.camel@localhost.localdomain> In-Reply-To: <1100852618.25135.18.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 4472 X-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: 623 Lines: 19 OndÅ™ej Surý wrote: > The problem is, that action was already done and I cannot replicate it, > because it holds production data. Althought I can prepare some test > setup and try to replicate the problem. > > We tried xfs_repair on unmounted system (already with -990 error) and it > also crashed with -990. If repair crashes, then that's a bug in repair, can you be sure you've tried the latest version, and send full info on the crash? > Question is, if xfs_dump/restore will fix the error or not. Or is there > some other way how to fix filesystem and not destroy data it holds. Repair -should- do it. -Eric From owner-linux-xfs Fri Nov 19 06:35:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Nov 2004 06:35:29 -0800 (PST) Received: from out.smtp.cz (ender.smtp.cz [81.95.97.119]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAJEZPkH026284 for ; Fri, 19 Nov 2004 06:35:25 -0800 Received: (qmail 27101 invoked from network); 19 Nov 2004 14:35:00 -0000 Received: from unknown (HELO shade.office.globe.cz) (ondrej@sury.org@81.95.104.4) by ender.smtp.cz with RC4-MD5 encrypted SMTP; 19 Nov 2004 14:35:00 -0000 Subject: Re: nfsd: non-standard errno: -990 From: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= To: linux-xfs@oss.sgi.com In-Reply-To: <419DFE30.5050202@sgi.com> References: <1100776614.4833.22.camel@localhost.localdomain> <419CAC5E.6070806@sgi.com> <1100787175.4833.35.camel@localhost.localdomain> <419D063A.4010809@sgi.com> <1100852618.25135.18.camel@localhost.localdomain> <419DFE30.5050202@sgi.com> Content-Type: text/plain; charset=UTF-8 Date: Fri, 19 Nov 2004 15:35:02 +0100 Message-Id: <1100874902.13322.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 8bit X-archive-position: 4473 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ondrej@sury.org Precedence: bulk X-list: linux-xfs Content-Length: 1241 Lines: 33 On Fri, 2004-11-19 at 08:07 -0600, Eric Sandeen wrote: > OndÅ™ej Surý wrote: > > > The problem is, that action was already done and I cannot replicate it, > > because it holds production data. Althought I can prepare some test > > setup and try to replicate the problem. > > > > We tried xfs_repair on unmounted system (already with -990 error) and it > > also crashed with -990. > > If repair crashes, then that's a bug in repair, can you be sure you've > tried the latest version, and send full info on the crash? We used latest ubuntu version ie. 2.6.18. We will upgrade it to 2.6.25 version and try to repair. Hopefully it will help, you know, customers are bit angry when it comes to losing all their mails :-). > > Question is, if xfs_dump/restore will fix the error or not. Or is there > > some other way how to fix filesystem and not destroy data it holds. > > Repair -should- do it. Ok, we will try to use 2.6.25 version and I will report result afterwards. Is there something you are particulary interested if it crashes again more then full log of activity? I will try to use xfs_repair -n as first step and if it finishes, then use it for real. Any other suggestions? Ondrej -- OndÅ™ej Surý From owner-linux-xfs Fri Nov 19 14:22:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Nov 2004 14:22:35 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAJMMWpH027253 for ; Fri, 19 Nov 2004 14:22:32 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAJNeAts016145 for ; Fri, 19 Nov 2004 15:40:10 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id iAJML1am2427395; Fri, 19 Nov 2004 16:21:02 -0600 (CST) Message-ID: <419E71CC.7010406@sgi.com> Date: Fri, 19 Nov 2004 16:21:00 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?77+9?= CC: linux-xfs@oss.sgi.com Subject: Re: nfsd: non-standard errno: -990 References: <1100776614.4833.22.camel@localhost.localdomain> <419CAC5E.6070806@sgi.com> <1100787175.4833.35.camel@localhost.localdomain> <419D063A.4010809@sgi.com> <1100852618.25135.18.camel@localhost.localdomain> <419DFE30.5050202@sgi.com> <1100874902.13322.7.camel@localhost.localdomain> In-Reply-To: <1100874902.13322.7.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 4474 X-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: 580 Lines: 18 OndÅ™ej Surý wrote: > Ok, we will try to use 2.6.25 version and I will report result > afterwards. Is there something you are particulary interested if it > crashes again more then full log of activity? > > I will try to use xfs_repair -n as first step and if it finishes, then > use it for real. Any other suggestions? That sounds good. Also, have you made sure that there are no other errors in the logs (or dmesg) about general IO problems? 990 errors can come after the filesystem has shut down due to errors, including underlying disk problems... Thanks, -Eric From owner-linux-xfs Fri Nov 19 18:04:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 19 Nov 2004 18:04:09 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAK245vf004294 for ; Fri, 19 Nov 2004 18:04:05 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAK2458t004293 for linux-xfs@oss.sgi.com; Fri, 19 Nov 2004 18:04:05 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAK244is004279 for ; Fri, 19 Nov 2004 18:04:04 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAK1iFlE003516; Fri, 19 Nov 2004 17:44:15 -0800 Date: Fri, 19 Nov 2004 17:44:15 -0800 Message-Id: <200411200144.iAK1iFlE003516@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 385] xfs_force_shutdown(loop7,0x1) called from line 353 of file fs/xfs/xfs_rw.c X-Bugzilla-Reason: AssignedTo X-archive-position: 4475 X-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: 362 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=385 ------- Additional Comments From sandeen@sgi.com 2004-19-11 17:44 PDT ------- Yes, I did mean 388 but if your underlying device is just a simple scsi drive, then it's not related. -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sat Nov 20 02:17:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Nov 2004 02:17:07 -0800 (PST) Received: from smtp10.wanadoo.fr (smtp10.wanadoo.fr [193.252.22.21]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAKAH3US024158 for ; Sat, 20 Nov 2004 02:17:03 -0800 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1001.wanadoo.fr (SMTP Server) with SMTP id 6131918000D8; Sat, 20 Nov 2004 11:16:38 +0100 (CET) Received: from [192.168.3.11] (ASte-Genev-Bois-151-1-8-67.w82-121.abo.wanadoo.fr [82.121.134.67]) by mwinf1001.wanadoo.fr (SMTP Server) with ESMTP id 299F818000D6; Sat, 20 Nov 2004 11:16:38 +0100 (CET) Message-ID: <419F1985.9010603@minet.net> Date: Sat, 20 Nov 2004 11:16:37 +0100 From: Mathieu GOMBAULT User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: qwerty@minet.net Subject: XFS: can't read superblock Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4476 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: qwerty@minet.net Precedence: bulk X-list: linux-xfs Content-Length: 507 Lines: 19 Hello I installed my home directory on an xfs partition under a Debian, kernel 2.6.7. But there has been a kind of 'crash' and, now, when trying to mount it, I get the following message: qwerty@Pegasus:~$;-) sudo mount -t xfs /dev/hdd1 /mnt/ mount: /dev/hdd1: can't read superblock Is it possible to get my partition back (I had about 60 Go of important documents on it...), or to save my documents? If so, how and what can I do? I hope one of you may help me! Thanks in advance Mathieu GOMBAULT From owner-linux-xfs Sat Nov 20 03:13:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Nov 2004 03:13:06 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAKBD3lH027340 for ; Sat, 20 Nov 2004 03:13:04 -0800 Received: (qmail 25029 invoked by uid 65534); 20 Nov 2004 11:12:38 -0000 Received: from G1f9a.g.pppool.de (EHLO [192.168.10.11]) (80.185.31.154) by mail.gmx.net (mp019) with SMTP; 20 Nov 2004 12:12:38 +0100 X-Authenticated: #2986359 Message-ID: <419F1896.6020501@gmx.net> Date: Sat, 20 Nov 2004 11:12:38 +0100 From: evilninja User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Mathieu GOMBAULT Subject: Re: XFS: can't read superblock References: <419F1985.9010603@minet.net> In-Reply-To: <419F1985.9010603@minet.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-archive-position: 4477 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 281 Lines: 14 Mathieu GOMBAULT wrote: > > qwerty@Pegasus:~$;-) sudo mount -t xfs /dev/hdd1 /mnt/ > mount: /dev/hdd1: can't read superblock > what does xfs_check (and then probably xfs_repair) say? the kernel log could also be interesting. -- BOFH excuse #58: high pressure system failure From owner-linux-xfs Sat Nov 20 03:17:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Nov 2004 03:17:39 -0800 (PST) Received: from smtp10.wanadoo.fr (smtp10.wanadoo.fr [193.252.22.21]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAKBHbxS027688 for ; Sat, 20 Nov 2004 03:17:37 -0800 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1006.wanadoo.fr (SMTP Server) with SMTP id 5CE233000085; Sat, 20 Nov 2004 12:17:12 +0100 (CET) Received: from [192.168.3.11] (ASte-Genev-Bois-151-1-8-67.w82-121.abo.wanadoo.fr [82.121.134.67]) by mwinf1006.wanadoo.fr (SMTP Server) with ESMTP id C1ECD3000084; Sat, 20 Nov 2004 12:17:11 +0100 (CET) Message-ID: <419F27B7.10803@minet.net> Date: Sat, 20 Nov 2004 12:17:11 +0100 From: Mathieu GOMBAULT User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: evilninja Cc: linux-xfs@oss.sgi.com Subject: Re: XFS: can't read superblock References: <419F1985.9010603@minet.net> <419F1896.6020501@gmx.net> In-Reply-To: <419F1896.6020501@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 4478 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: qwerty@minet.net Precedence: bulk X-list: linux-xfs Content-Length: 5386 Lines: 210 evilninja wrote: >Mathieu GOMBAULT wrote: > > >>qwerty@Pegasus:~$;-) sudo mount -t xfs /dev/hdd1 /mnt/ >>mount: /dev/hdd1: can't read superblock >> >> >> > >what does xfs_check (and then probably xfs_repair) say? >the kernel log could also be interesting. > > > xfs_repair takes 2 seconds for a disk of 160 GB. I have xfs_repair version 2.6.20 here are all the logs I made: qwerty@Pegasus:~$;-) sudo xfs_repair -v /dev/hdd1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 2 tail block 2 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done qwerty@Pegasus:~$;-) cat /proc/partitions major minor #blocks name 3 0 80043264 hda 3 1 16033 hda1 3 2 498015 hda2 3 3 498015 hda3 3 4 1 hda4 3 5 6000246 hda5 3 6 2000061 hda6 3 7 71023333 hda7 22 64 160086528 hdd 22 65 159993460 hdd1 qwerty@Pegasus:~$;-) sudo fdisk -l /dev/hdd Disk /dev/hdd: 163.9 GB, 163928604672 bytes 255 heads, 63 sectors/track, 19929 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdd1 * 2 19920 159993460 83 Linux I made only one partition with xfs when I created it qwerty@Pegasus:~$;-)sudo strace -omount.trace mount -t xfs /dev/hdd1 /mnt mount: /dev/hdd1: can't read superblock qwerty@Pegasus:~$;-) sudo mount -t xfs /dev/hdd1 /mnt/ mount: /dev/hdd1: can't read superblock qwerty@Pegasus:~$;-) dmesg | tail I/O error in filesystem ("hdd1") meta-data dev hdd1 block 0x1314ff7f ("xfs_read_buf") error 5 buf count 512 XFS: size check 2 failed attempt to access beyond end of device hdd1: rw=0, want=320143232, limit=319986920 I/O error in filesystem ("hdd1") meta-data dev hdd1 block 0x1314ff7f ("xfs_read_buf") error 5 buf count 512 XFS: size check 2 failed attempt to access beyond end of device hdd1: rw=0, want=320143232, limit=319986920 I/O error in filesystem ("hdd1") meta-data dev hdd1 block 0x1314ff7f ("xfs_read_buf") error 5 buf count 512 XFS: size check 2 failed qwerty@Pegasus:~$;-) sudo xfs_db /dev/hdd1 xfs_db> sb 0 xfs_db> p magicnum = 0x58465342 blocksize = 4096 dblocks = 40017904 rblocks = 0 rextents = 0 uuid = 1329d43d-2fcd-4aeb-8956-4a4fff97a6ec logstart = 33554436 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 2501119 agcount = 16 rbmblocks = 0 logblocks = 19539 versionnum = 0x3084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 22 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 7424 ifree = 413 fdblocks = 25901321 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 features2 = 0 qwerty@Pegasus:~$;-) sudo dd if=/dev/hdd1 bs=512 count=1 |hexdump 0000000 4658 4253 0000 0010 0000 0000 6202 f09f 0000010 0000 0000 0000 0000 0000 0000 0000 0000 0000020 2913 3dd4 cd2f eb4a 5689 4f4a 97ff eca6 0000030 0000 0000 0002 0400 0000 0000 0000 8000 0000040 0000 0000 0000 8100 0000 0000 0000 8200 0000050 0000 1000 2600 ff29 0000 1000 0000 0000 0000060 0000 534c 8430 0002 0001 1000 0000 0000 0000070 0000 0000 0000 0000 090c 0408 0016 1900 0000080 0000 0000 0000 001d 0000 0000 0000 9d01 0000090 0000 0000 8b01 0939 0000 0000 0000 0000 00000a0 0000 0000 0000 0000 0000 0000 0000 0000 00000b0 0000 0000 0000 0200 0000 0000 0000 0000 00000c0 0000 0000 0000 0000 0000 0000 0000 0000 * 0000200 1+0 enregistrements lus. 1+0 enregistrements écrits. 512 bytes transferred in 0,018077 seconds (28323 bytes/sec) Thanks in advance Regards Math From owner-linux-xfs Sat Nov 20 05:39:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Nov 2004 05:39:35 -0800 (PST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAKDdVJA001256 for ; Sat, 20 Nov 2004 05:39:32 -0800 Received: (qmail 1281 invoked by uid 65534); 20 Nov 2004 13:39:07 -0000 Received: from G1f9a.g.pppool.de (EHLO [192.168.10.11]) (80.185.31.154) by mail.gmx.net (mp004) with SMTP; 20 Nov 2004 14:39:07 +0100 X-Authenticated: #2986359 Message-ID: <419F3AEC.4050808@gmx.net> Date: Sat, 20 Nov 2004 13:39:08 +0100 From: evilninja User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS: can't read superblock References: <419F1985.9010603@minet.net> <419F1896.6020501@gmx.net> <419F27B7.10803@minet.net> In-Reply-To: <419F27B7.10803@minet.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-archive-position: 4479 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 722 Lines: 29 Mathieu GOMBAULT wrote: [...] wow, that *is* a lot of information. i myself can not help here, as i am not a fs expert. i just wanted you to give the list more details to work with. > qwerty@Pegasus:~$;-) dmesg | tail > I/O error in filesystem ("hdd1") meta-data dev hdd1 block > 0x1314ff7f ("xfs_read_buf") error 5 buf count 512 > XFS: size check 2 failed > attempt to access beyond end of device can you exclude hardware related issues? perhaps dd the disk/partion to /dev/null and see if there are i/o errors too. but it's strange that xfs_repair could not fix it... my 2¢, Christian. -- BOFH excuse #169: broadcast packets on wrong frequency -- BOFH excuse #169: broadcast packets on wrong frequency From owner-linux-xfs Sat Nov 20 07:26:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Nov 2004 07:26:54 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAKFQoZr003540 for ; Sat, 20 Nov 2004 07:26:50 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAKGiYOv023757 for ; Sat, 20 Nov 2004 08:44:34 -0800 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAKFQTad2592570; Sat, 20 Nov 2004 07:26:29 -0800 (PST) Message-ID: <419F6227.8050506@sgi.com> Date: Sat, 20 Nov 2004 09:26:31 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mathieu GOMBAULT CC: evilninja , linux-xfs@oss.sgi.com Subject: Re: XFS: can't read superblock References: <419F1985.9010603@minet.net> <419F1896.6020501@gmx.net> <419F27B7.10803@minet.net> In-Reply-To: <419F27B7.10803@minet.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4480 X-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: 1252 Lines: 40 Mathieu GOMBAULT wrote: > here are all the logs I made: > > qwerty@Pegasus:~$;-) sudo xfs_repair -v /dev/hdd1 Looks like xfs_repair found nothing wrong... > qwerty@Pegasus:~$;-) cat /proc/partitions > major minor #blocks name > 22 64 160086528 hdd > 22 65 159993460 hdd1 A little odd that hdd1 is smaller than hdd? > qwerty@Pegasus:~$;-)sudo strace -omount.trace mount -t xfs /dev/hdd1 /mnt > mount: /dev/hdd1: can't read superblock > > > qwerty@Pegasus:~$;-) sudo mount -t xfs /dev/hdd1 /mnt/ > mount: /dev/hdd1: can't read superblock > qwerty@Pegasus:~$;-) dmesg | tail > I/O error in filesystem ("hdd1") meta-data dev hdd1 block > 0x1314ff7f ("xfs_read_buf") error 5 buf count 512 > XFS: size check 2 failed > attempt to access beyond end of device size check 2 tries to read the last block on the disk. It's saying it cant' read block 0x1314ff74 which is block 320143231 (in 512b blocks, or 160071615 in 1k blocks - which is past the end of hdd1 but still on hdd) I'd either remove the size check 2 and rebuild xfs, then mount read-only and copy the data somewhere safe.... or if you're feeling brave, extend hdd1 to the end of your disk using your favorite partition editor. not sure how this happened... -Eric From owner-linux-xfs Sat Nov 20 14:46:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Nov 2004 14:46:52 -0800 (PST) Received: from flyingAngel.upjs.sk (gprs185-222.eurotel.cz [160.218.185.222]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAKMkff6028382 for ; Sat, 20 Nov 2004 14:46:43 -0800 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id F2D82100700; Sat, 20 Nov 2004 23:46:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id EEE4E18024B for ; Sat, 20 Nov 2004 23:46:10 +0100 (CET) Date: Sat, 20 Nov 2004 23:46:10 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: linux-xfs@oss.sgi.com Subject: Patch for compiling xfs-cmds on amd64. Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168429056-663461925-1100990770=:11405" X-archive-position: 4481 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 7295 Lines: 133 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --168429056-663461925-1100990770=:11405 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello. On the amd64 platform is possible to use 64-bit and 32-bit binaries/libraries. 64-bit libraries are placed in lib64 directories. I prepared a patch for the xfs-cmds cvs which add the ability to detect x86_64 platform and run configure with the correct parameters. jan -- --168429056-663461925-1100990770=:11405 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="xfs-cmds.x86_64.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="xfs-cmds.x86_64.diff" ZGlmZiAtdU5yIHhmcy1jbWRzLm9yaWcvYWNsL01ha2VmaWxlIHhmcy1jbWRz L2FjbC9NYWtlZmlsZQ0KLS0tIHhmcy1jbWRzLm9yaWcvYWNsL01ha2VmaWxl CTIwMDQtMTEtMTQgMTM6NDY6NTMuMDAwMDAwMDAwICswMTAwDQorKysgeGZz LWNtZHMvYWNsL01ha2VmaWxlCTIwMDQtMTEtMTQgMTU6NDQ6NDkuMDAwMDAw MDAwICswMTAwDQpAQCAtMzIsNiArMzIsNyBAQA0KIA0KIFRPUERJUiA9IC4N CiBIQVZFX0JVSUxEREVGUyA9ICQoc2hlbGwgdGVzdCAtZiAkKFRPUERJUikv aW5jbHVkZS9idWlsZGRlZnMgJiYgZWNobyB5ZXMgfHwgZWNobyBubykNCitI V19QTEFUID0gJChzaGVsbCAvYmluL3VuYW1lIC0taGFyZHdhcmUtcGxhdGZv cm0pDQogDQogaWZlcSAoJChIQVZFX0JVSUxEREVGUyksIHllcykNCiBpbmNs dWRlICQoVE9QRElSKS9pbmNsdWRlL2J1aWxkZGVmcw0KQEAgLTYwLDYgKzYx LDEyIEBADQogY2xlYW46CSMgaWYgY29uZmlndXJlIGhhc24ndCBydW4sIG5v dGhpbmcgdG8gY2xlYW4NCiBlbmRpZg0KIA0KK2lmZXEgKCQoSFdfUExBVCks IHg4Nl82NCkNCitIV19MSUIgPSBsaWI2NA0KK2Vsc2UNCitIV19MSUIgPSBs aWINCitlbmRpZg0KKw0KICQoQ09ORklHVVJFKToNCiAJYXV0b2NvbmYNCiAJ Li9jb25maWd1cmUgXA0KQEAgLTY3LDggKzc0LDggQEANCiAJCS0tZXhlYy1w cmVmaXg9LyBcDQogCQktLXNiaW5kaXI9L2JpbiBcDQogCQktLWJpbmRpcj0v dXNyL2JpbiBcDQotCQktLWxpYmRpcj0vbGliIFwNCi0JCS0tbGliZXhlY2Rp cj0vdXNyL2xpYiBcDQorCQktLWxpYmRpcj0vJChIV19MSUIpIFwNCisJCS0t bGliZXhlY2Rpcj0vdXNyLyQoSFdfTElCKSBcDQogCQktLWluY2x1ZGVkaXI9 L3Vzci9pbmNsdWRlIFwNCiAJCS0tbWFuZGlyPS91c3Ivc2hhcmUvbWFuIFwN CiAJCS0tZGF0YWRpcj0vdXNyL3NoYXJlIFwNCmRpZmYgLXVOciB4ZnMtY21k cy5vcmlnL2F0dHIvTWFrZWZpbGUgeGZzLWNtZHMvYXR0ci9NYWtlZmlsZQ0K LS0tIHhmcy1jbWRzLm9yaWcvYXR0ci9NYWtlZmlsZQkyMDA0LTExLTE0IDEz OjQ2OjU2LjAwMDAwMDAwMCArMDEwMA0KKysrIHhmcy1jbWRzL2F0dHIvTWFr ZWZpbGUJMjAwNC0xMS0xNCAxNTo0MzowMy4wMDAwMDAwMDAgKzAxMDANCkBA IC0zMiw2ICszMiw3IEBADQogDQogVE9QRElSID0gLg0KIEhBVkVfQlVJTERE RUZTID0gJChzaGVsbCB0ZXN0IC1mICQoVE9QRElSKS9pbmNsdWRlL2J1aWxk ZGVmcyAmJiBlY2hvIHllcyB8fCBlY2hvIG5vKQ0KK0hXX1BMQVQgPSAkKHNo ZWxsIC9iaW4vdW5hbWUgLS1oYXJkd2FyZS1wbGF0Zm9ybSkNCiANCiBpZmVx ICgkKEhBVkVfQlVJTERERUZTKSwgeWVzKQ0KIGluY2x1ZGUgJChUT1BESVIp L2luY2x1ZGUvYnVpbGRkZWZzDQpAQCAtNjAsNiArNjEsMTIgQEANCiBjbGVh bjoJIyBpZiBjb25maWd1cmUgaGFzbid0IHJ1biwgbm90aGluZyB0byBjbGVh bg0KIGVuZGlmDQogDQoraWZlcSAoJChIV19QTEFUKSwgeDg2XzY0KQ0KK0hX X0xJQiA9IGxpYjY0DQorZWxzZQ0KK0hXX0xJQiA9IGxpYg0KK2VuZGlmDQor DQogJChDT05GSUdVUkUpOg0KIAlhdXRvY29uZg0KIAkuL2NvbmZpZ3VyZSBc DQpAQCAtNjcsOCArNzQsOCBAQA0KIAkJLS1leGVjLXByZWZpeD0vIFwNCiAJ CS0tc2JpbmRpcj0vYmluIFwNCiAJCS0tYmluZGlyPS91c3IvYmluIFwNCi0J CS0tbGliZGlyPS9saWIgXA0KLQkJLS1saWJleGVjZGlyPS91c3IvbGliIFwN CisJCS0tbGliZGlyPS8kKEhXX0xJQikgXA0KKwkJLS1saWJleGVjZGlyPS91 c3IvJChIV19MSUIpIFwNCiAJCS0taW5jbHVkZWRpcj0vdXNyL2luY2x1ZGUg XA0KIAkJLS1tYW5kaXI9L3Vzci9zaGFyZS9tYW4gXA0KIAkJLS1kYXRhZGly PS91c3Ivc2hhcmUgXA0KZGlmZiAtdU5yIHhmcy1jbWRzLm9yaWcvZG1hcGkv TWFrZWZpbGUgeGZzLWNtZHMvZG1hcGkvTWFrZWZpbGUNCi0tLSB4ZnMtY21k cy5vcmlnL2RtYXBpL01ha2VmaWxlCTIwMDQtMTEtMTQgMTM6NDY6NTguMDAw MDAwMDAwICswMTAwDQorKysgeGZzLWNtZHMvZG1hcGkvTWFrZWZpbGUJMjAw NC0xMS0xNCAxNTo0MjoyNC4wMDAwMDAwMDAgKzAxMDANCkBAIC0zMiw2ICsz Miw3IEBADQogDQogVE9QRElSID0gLg0KIEhBVkVfQlVJTERERUZTID0gJChz aGVsbCB0ZXN0IC1mICQoVE9QRElSKS9pbmNsdWRlL2J1aWxkZGVmcyAmJiBl Y2hvIHllcyB8fCBlY2hvIG5vKQ0KK0hXX1BMQVQgPSAkKHNoZWxsIC9iaW4v dW5hbWUgLS1oYXJkd2FyZS1wbGF0Zm9ybSkNCiANCiBpZmVxICgkKEhBVkVf QlVJTERERUZTKSwgeWVzKQ0KIGluY2x1ZGUgJChUT1BESVIpL2luY2x1ZGUv YnVpbGRkZWZzDQpAQCAtNTgsNiArNTksMTIgQEANCiBjbGVhbjoJIyBpZiBj b25maWd1cmUgaGFzbid0IHJ1biwgbm90aGluZyB0byBjbGVhbg0KIGVuZGlm DQogDQoraWZlcSAoJChIV19QTEFUKSwgeDg2XzY0KQ0KK0hXX0xJQiA9IGxp YjY0DQorZWxzZQ0KK0hXX0xJQiA9IGxpYg0KK2VuZGlmDQorDQogJChDT05G SUdVUkUpOg0KIAlhdXRvY29uZg0KIAkuL2NvbmZpZ3VyZSBcDQpAQCAtNjUs OCArNzIsOCBAQA0KIAkJLS1leGVjLXByZWZpeD0vIFwNCiAJCS0tc2JpbmRp cj0vYmluIFwNCiAJCS0tYmluZGlyPS91c3IvYmluIFwNCi0JCS0tbGliZGly PS9saWIgXA0KLQkJLS1saWJleGVjZGlyPS91c3IvbGliIFwNCisJCS0tbGli ZGlyPS8kKEhXX0xJQikgXA0KKwkJLS1saWJleGVjZGlyPS91c3IvJChIV19M SUIpIFwNCiAJCS0taW5jbHVkZWRpcj0vdXNyL2luY2x1ZGUgXA0KIAkJLS1t YW5kaXI9L3Vzci9zaGFyZS9tYW4gXA0KIAkJLS1kYXRhZGlyPS91c3Ivc2hh cmUgXA0KZGlmZiAtdU5yIHhmcy1jbWRzLm9yaWcveGZzZHVtcC9NYWtlZmls ZSB4ZnMtY21kcy94ZnNkdW1wL01ha2VmaWxlDQotLS0geGZzLWNtZHMub3Jp Zy94ZnNkdW1wL01ha2VmaWxlCTIwMDQtMTEtMTQgMTM6NDY6NTguMDAwMDAw MDAwICswMTAwDQorKysgeGZzLWNtZHMveGZzZHVtcC9NYWtlZmlsZQkyMDA0 LTExLTE0IDE1OjU4OjEzLjAwMDAwMDAwMCArMDEwMA0KQEAgLTMyLDYgKzMy LDcgQEANCiANCiBUT1BESVIgPSAuDQogSEFWRV9CVUlMRERFRlMgPSAkKHNo ZWxsIHRlc3QgLWYgJChUT1BESVIpL2luY2x1ZGUvYnVpbGRkZWZzICYmIGVj aG8geWVzIHx8IGVjaG8gbm8pDQorSFdfUExBVCA9ICQoc2hlbGwgL2Jpbi91 bmFtZSAtLWhhcmR3YXJlLXBsYXRmb3JtKQ0KIA0KIGlmZXEgKCQoSEFWRV9C VUlMRERFRlMpLCB5ZXMpDQogaW5jbHVkZSAkKFRPUERJUikvaW5jbHVkZS9i dWlsZGRlZnMNCkBAIC02MCw2ICs2MSwxMiBAQA0KIGNsZWFuOgkjIGlmIGNv bmZpZ3VyZSBoYXNuJ3QgcnVuLCBub3RoaW5nIHRvIGNsZWFuDQogZW5kaWYN CiANCitpZmVxICgkKEhXX1BMQVQpLCB4ODZfNjQpDQorSFdfTElCID0gbGli NjQNCitlbHNlDQorSFdfTElCID0gbGliDQorZW5kaWYNCisNCiAkKENPTkZJ R1VSRSk6DQogCWF1dG9jb25mDQogCS4vY29uZmlndXJlIFwNCkBAIC02Nyw4 ICs3NCw4IEBADQogCQktLWV4ZWMtcHJlZml4PS8gXA0KIAkJLS1zYmluZGly PS9zYmluIFwNCiAJCS0tYmluZGlyPS91c3Ivc2JpbiBcDQotCQktLWxpYmRp cj0vbGliIFwNCi0JCS0tbGliZXhlY2Rpcj0vdXNyL2xpYiBcDQorCQktLWxp YmRpcj0vJChIV19MSUIpIFwNCisJCS0tbGliZXhlY2Rpcj0vdXNyLyQoSFdf TElCKSBcDQogCQktLWluY2x1ZGVkaXI9L3Vzci9pbmNsdWRlIFwNCiAJCS0t bWFuZGlyPS91c3Ivc2hhcmUvbWFuIFwNCiAJCS0tZGF0YWRpcj0vdXNyL3No YXJlIFwNCmRpZmYgLXVOciB4ZnMtY21kcy5vcmlnL3hmc3Byb2dzL01ha2Vm aWxlIHhmcy1jbWRzL3hmc3Byb2dzL01ha2VmaWxlDQotLS0geGZzLWNtZHMu b3JpZy94ZnNwcm9ncy9NYWtlZmlsZQkyMDA0LTExLTE0IDEzOjQ3OjAxLjAw MDAwMDAwMCArMDEwMA0KKysrIHhmcy1jbWRzL3hmc3Byb2dzL01ha2VmaWxl CTIwMDQtMTEtMTQgMTU6NDQ6NDcuMDAwMDAwMDAwICswMTAwDQpAQCAtMzIs NiArMzIsNyBAQA0KIA0KIFRPUERJUiA9IC4NCiBIQVZFX0JVSUxEREVGUyA9 ICQoc2hlbGwgdGVzdCAtZiAkKFRPUERJUikvaW5jbHVkZS9idWlsZGRlZnMg JiYgZWNobyB5ZXMgfHwgZWNobyBubykNCitIV19QTEFUID0gJChzaGVsbCAv YmluL3VuYW1lIC0taGFyZHdhcmUtcGxhdGZvcm0pDQogDQogaWZlcSAoJChI QVZFX0JVSUxEREVGUyksIHllcykNCiBpbmNsdWRlICQoVE9QRElSKS9pbmNs dWRlL2J1aWxkZGVmcw0KQEAgLTYwLDYgKzYxLDEyIEBADQogY2xlYW46CSMg aWYgY29uZmlndXJlIGhhc24ndCBydW4sIG5vdGhpbmcgdG8gY2xlYW4NCiBl bmRpZg0KIA0KK2lmZXEgKCQoSFdfUExBVCksIHg4Nl82NCkNCitIV19MSUIg PSBsaWI2NA0KK2Vsc2UNCitIV19MSUIgPSBsaWINCitlbmRpZg0KKw0KICQo Q09ORklHVVJFKToNCiAJYXV0b2NvbmYNCiAJLi9jb25maWd1cmUgXA0KQEAg LTY3LDggKzc0LDggQEANCiAJCS0tZXhlYy1wcmVmaXg9LyBcDQogCQktLXNi aW5kaXI9L3NiaW4gXA0KIAkJLS1iaW5kaXI9L3Vzci9zYmluIFwNCi0JCS0t bGliZGlyPS9saWIgXA0KLQkJLS1saWJleGVjZGlyPS91c3IvbGliIFwNCisJ CS0tbGliZGlyPS8kKEhXX0xJQikgXA0KKwkJLS1saWJleGVjZGlyPS91c3Iv JChIV19MSUIpIFwNCiAJCS0taW5jbHVkZWRpcj0vdXNyL2luY2x1ZGUgXA0K IAkJLS1tYW5kaXI9L3Vzci9zaGFyZS9tYW4gXA0KIAkJLS1kYXRhZGlyPS91 c3Ivc2hhcmUgXA0K --168429056-663461925-1100990770=:11405-- From owner-linux-xfs Sat Nov 20 14:54:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Nov 2004 14:54:34 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [81.187.226.98]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAKMsWWO001582 for ; Sat, 20 Nov 2004 14:54:33 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.42 #1 (Red Hat Linux)) id 1CVe7P-0005l1-JT; Sat, 20 Nov 2004 22:54:11 +0000 Date: Sat, 20 Nov 2004 22:54:11 +0000 From: Christoph Hellwig To: Jan Derfinak Cc: linux-xfs@oss.sgi.com Subject: Re: Patch for compiling xfs-cmds on amd64. Message-ID: <20041120225411.GA22120@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 4482 X-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: 349 Lines: 14 > +HW_PLAT = $(shell /bin/uname --hardware-platform) hch@dhcppc1:~$ uname --hardware-platform uname: unrecognized option `--hardware-platform' > +ifeq ($(HW_PLAT), x86_64) > +HW_LIB = lib64 > +else > +HW_LIB = lib > +endif Same is true for at least ppc64, sparc64 and s390x. I thought autoconf had some magic macros to handle lib64 these days? From owner-linux-xfs Sat Nov 20 15:33:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Nov 2004 15:33:15 -0800 (PST) Received: from flyingAngel.upjs.sk (gprs185-222.eurotel.cz [160.218.185.222]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAKNX6aX012145 for ; Sat, 20 Nov 2004 15:33:08 -0800 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id B841B100700; Sun, 21 Nov 2004 00:32:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id B4CEB18024B; Sun, 21 Nov 2004 00:32:36 +0100 (CET) Date: Sun, 21 Nov 2004 00:32:36 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com Subject: Re: Patch for compiling xfs-cmds on amd64. In-Reply-To: <20041120225411.GA22120@infradead.org> Message-ID: References: <20041120225411.GA22120@infradead.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168429056-524890765-1100993556=:11405" X-archive-position: 4483 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 7587 Lines: 147 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --168429056-524890765-1100993556=:11405 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 20 Nov 2004, Christoph Hellwig wrote: > > +HW_PLAT = $(shell /bin/uname --hardware-platform) > > hch@dhcppc1:~$ uname --hardware-platform > uname: unrecognized option `--hardware-platform' I'm sorry, I didn't test it on older systems. It is possible to replace "--hardware-platform" with "-m". It works from RH7.2 to SLES9 (FC2 included). I attached new patch. > > > +ifeq ($(HW_PLAT), x86_64) > > +HW_LIB = lib64 > > +else > > +HW_LIB = lib > > +endif > > Same is true for at least ppc64, sparc64 and s390x. I thought autoconf > had some magic macros to handle lib64 these days? I agree. But for some reason is configure in Makefile called with static parameters. jan -- --168429056-524890765-1100993556=:11405 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="xfs-cmds.x86_64.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="xfs-cmds.x86_64.diff" ZGlmZiAtdU5yIHhmcy1jbWRzLm9yaWcvYWNsL01ha2VmaWxlIHhmcy1jbWRz L2FjbC9NYWtlZmlsZQ0KLS0tIHhmcy1jbWRzLm9yaWcvYWNsL01ha2VmaWxl CTIwMDQtMTEtMTQgMTM6NDY6NTMuMDAwMDAwMDAwICswMTAwDQorKysgeGZz LWNtZHMvYWNsL01ha2VmaWxlCTIwMDQtMTEtMTQgMTU6NDQ6NDkuMDAwMDAw MDAwICswMTAwDQpAQCAtMzIsNiArMzIsNyBAQA0KIA0KIFRPUERJUiA9IC4N CiBIQVZFX0JVSUxEREVGUyA9ICQoc2hlbGwgdGVzdCAtZiAkKFRPUERJUikv aW5jbHVkZS9idWlsZGRlZnMgJiYgZWNobyB5ZXMgfHwgZWNobyBubykNCitI V19QTEFUID0gJChzaGVsbCAvYmluL3VuYW1lIC1tKQ0KIA0KIGlmZXEgKCQo SEFWRV9CVUlMRERFRlMpLCB5ZXMpDQogaW5jbHVkZSAkKFRPUERJUikvaW5j bHVkZS9idWlsZGRlZnMNCkBAIC02MCw2ICs2MSwxMiBAQA0KIGNsZWFuOgkj IGlmIGNvbmZpZ3VyZSBoYXNuJ3QgcnVuLCBub3RoaW5nIHRvIGNsZWFuDQog ZW5kaWYNCiANCitpZmVxICgkKEhXX1BMQVQpLCB4ODZfNjQpDQorSFdfTElC ID0gbGliNjQNCitlbHNlDQorSFdfTElCID0gbGliDQorZW5kaWYNCisNCiAk KENPTkZJR1VSRSk6DQogCWF1dG9jb25mDQogCS4vY29uZmlndXJlIFwNCkBA IC02Nyw4ICs3NCw4IEBADQogCQktLWV4ZWMtcHJlZml4PS8gXA0KIAkJLS1z YmluZGlyPS9iaW4gXA0KIAkJLS1iaW5kaXI9L3Vzci9iaW4gXA0KLQkJLS1s aWJkaXI9L2xpYiBcDQotCQktLWxpYmV4ZWNkaXI9L3Vzci9saWIgXA0KKwkJ LS1saWJkaXI9LyQoSFdfTElCKSBcDQorCQktLWxpYmV4ZWNkaXI9L3Vzci8k KEhXX0xJQikgXA0KIAkJLS1pbmNsdWRlZGlyPS91c3IvaW5jbHVkZSBcDQog CQktLW1hbmRpcj0vdXNyL3NoYXJlL21hbiBcDQogCQktLWRhdGFkaXI9L3Vz ci9zaGFyZSBcDQpkaWZmIC11TnIgeGZzLWNtZHMub3JpZy9hdHRyL01ha2Vm aWxlIHhmcy1jbWRzL2F0dHIvTWFrZWZpbGUNCi0tLSB4ZnMtY21kcy5vcmln L2F0dHIvTWFrZWZpbGUJMjAwNC0xMS0xNCAxMzo0Njo1Ni4wMDAwMDAwMDAg KzAxMDANCisrKyB4ZnMtY21kcy9hdHRyL01ha2VmaWxlCTIwMDQtMTEtMTQg MTU6NDM6MDMuMDAwMDAwMDAwICswMTAwDQpAQCAtMzIsNiArMzIsNyBAQA0K IA0KIFRPUERJUiA9IC4NCiBIQVZFX0JVSUxEREVGUyA9ICQoc2hlbGwgdGVz dCAtZiAkKFRPUERJUikvaW5jbHVkZS9idWlsZGRlZnMgJiYgZWNobyB5ZXMg fHwgZWNobyBubykNCitIV19QTEFUID0gJChzaGVsbCAvYmluL3VuYW1lIC1t KQ0KIA0KIGlmZXEgKCQoSEFWRV9CVUlMRERFRlMpLCB5ZXMpDQogaW5jbHVk ZSAkKFRPUERJUikvaW5jbHVkZS9idWlsZGRlZnMNCkBAIC02MCw2ICs2MSwx MiBAQA0KIGNsZWFuOgkjIGlmIGNvbmZpZ3VyZSBoYXNuJ3QgcnVuLCBub3Ro aW5nIHRvIGNsZWFuDQogZW5kaWYNCiANCitpZmVxICgkKEhXX1BMQVQpLCB4 ODZfNjQpDQorSFdfTElCID0gbGliNjQNCitlbHNlDQorSFdfTElCID0gbGli DQorZW5kaWYNCisNCiAkKENPTkZJR1VSRSk6DQogCWF1dG9jb25mDQogCS4v Y29uZmlndXJlIFwNCkBAIC02Nyw4ICs3NCw4IEBADQogCQktLWV4ZWMtcHJl Zml4PS8gXA0KIAkJLS1zYmluZGlyPS9iaW4gXA0KIAkJLS1iaW5kaXI9L3Vz ci9iaW4gXA0KLQkJLS1saWJkaXI9L2xpYiBcDQotCQktLWxpYmV4ZWNkaXI9 L3Vzci9saWIgXA0KKwkJLS1saWJkaXI9LyQoSFdfTElCKSBcDQorCQktLWxp YmV4ZWNkaXI9L3Vzci8kKEhXX0xJQikgXA0KIAkJLS1pbmNsdWRlZGlyPS91 c3IvaW5jbHVkZSBcDQogCQktLW1hbmRpcj0vdXNyL3NoYXJlL21hbiBcDQog CQktLWRhdGFkaXI9L3Vzci9zaGFyZSBcDQpkaWZmIC11TnIgeGZzLWNtZHMu b3JpZy9kbWFwaS9NYWtlZmlsZSB4ZnMtY21kcy9kbWFwaS9NYWtlZmlsZQ0K LS0tIHhmcy1jbWRzLm9yaWcvZG1hcGkvTWFrZWZpbGUJMjAwNC0xMS0xNCAx Mzo0Njo1OC4wMDAwMDAwMDAgKzAxMDANCisrKyB4ZnMtY21kcy9kbWFwaS9N YWtlZmlsZQkyMDA0LTExLTE0IDE1OjQyOjI0LjAwMDAwMDAwMCArMDEwMA0K QEAgLTMyLDYgKzMyLDcgQEANCiANCiBUT1BESVIgPSAuDQogSEFWRV9CVUlM RERFRlMgPSAkKHNoZWxsIHRlc3QgLWYgJChUT1BESVIpL2luY2x1ZGUvYnVp bGRkZWZzICYmIGVjaG8geWVzIHx8IGVjaG8gbm8pDQorSFdfUExBVCA9ICQo c2hlbGwgL2Jpbi91bmFtZSAtbSkNCiANCiBpZmVxICgkKEhBVkVfQlVJTERE RUZTKSwgeWVzKQ0KIGluY2x1ZGUgJChUT1BESVIpL2luY2x1ZGUvYnVpbGRk ZWZzDQpAQCAtNTgsNiArNTksMTIgQEANCiBjbGVhbjoJIyBpZiBjb25maWd1 cmUgaGFzbid0IHJ1biwgbm90aGluZyB0byBjbGVhbg0KIGVuZGlmDQogDQor aWZlcSAoJChIV19QTEFUKSwgeDg2XzY0KQ0KK0hXX0xJQiA9IGxpYjY0DQor ZWxzZQ0KK0hXX0xJQiA9IGxpYg0KK2VuZGlmDQorDQogJChDT05GSUdVUkUp Og0KIAlhdXRvY29uZg0KIAkuL2NvbmZpZ3VyZSBcDQpAQCAtNjUsOCArNzIs OCBAQA0KIAkJLS1leGVjLXByZWZpeD0vIFwNCiAJCS0tc2JpbmRpcj0vYmlu IFwNCiAJCS0tYmluZGlyPS91c3IvYmluIFwNCi0JCS0tbGliZGlyPS9saWIg XA0KLQkJLS1saWJleGVjZGlyPS91c3IvbGliIFwNCisJCS0tbGliZGlyPS8k KEhXX0xJQikgXA0KKwkJLS1saWJleGVjZGlyPS91c3IvJChIV19MSUIpIFwN CiAJCS0taW5jbHVkZWRpcj0vdXNyL2luY2x1ZGUgXA0KIAkJLS1tYW5kaXI9 L3Vzci9zaGFyZS9tYW4gXA0KIAkJLS1kYXRhZGlyPS91c3Ivc2hhcmUgXA0K ZGlmZiAtdU5yIHhmcy1jbWRzLm9yaWcveGZzZHVtcC9NYWtlZmlsZSB4ZnMt Y21kcy94ZnNkdW1wL01ha2VmaWxlDQotLS0geGZzLWNtZHMub3JpZy94ZnNk dW1wL01ha2VmaWxlCTIwMDQtMTEtMTQgMTM6NDY6NTguMDAwMDAwMDAwICsw MTAwDQorKysgeGZzLWNtZHMveGZzZHVtcC9NYWtlZmlsZQkyMDA0LTExLTE0 IDE1OjU4OjEzLjAwMDAwMDAwMCArMDEwMA0KQEAgLTMyLDYgKzMyLDcgQEAN CiANCiBUT1BESVIgPSAuDQogSEFWRV9CVUlMRERFRlMgPSAkKHNoZWxsIHRl c3QgLWYgJChUT1BESVIpL2luY2x1ZGUvYnVpbGRkZWZzICYmIGVjaG8geWVz IHx8IGVjaG8gbm8pDQorSFdfUExBVCA9ICQoc2hlbGwgL2Jpbi91bmFtZSAt bSkNCiANCiBpZmVxICgkKEhBVkVfQlVJTERERUZTKSwgeWVzKQ0KIGluY2x1 ZGUgJChUT1BESVIpL2luY2x1ZGUvYnVpbGRkZWZzDQpAQCAtNjAsNiArNjEs MTIgQEANCiBjbGVhbjoJIyBpZiBjb25maWd1cmUgaGFzbid0IHJ1biwgbm90 aGluZyB0byBjbGVhbg0KIGVuZGlmDQogDQoraWZlcSAoJChIV19QTEFUKSwg eDg2XzY0KQ0KK0hXX0xJQiA9IGxpYjY0DQorZWxzZQ0KK0hXX0xJQiA9IGxp Yg0KK2VuZGlmDQorDQogJChDT05GSUdVUkUpOg0KIAlhdXRvY29uZg0KIAku L2NvbmZpZ3VyZSBcDQpAQCAtNjcsOCArNzQsOCBAQA0KIAkJLS1leGVjLXBy ZWZpeD0vIFwNCiAJCS0tc2JpbmRpcj0vc2JpbiBcDQogCQktLWJpbmRpcj0v dXNyL3NiaW4gXA0KLQkJLS1saWJkaXI9L2xpYiBcDQotCQktLWxpYmV4ZWNk aXI9L3Vzci9saWIgXA0KKwkJLS1saWJkaXI9LyQoSFdfTElCKSBcDQorCQkt LWxpYmV4ZWNkaXI9L3Vzci8kKEhXX0xJQikgXA0KIAkJLS1pbmNsdWRlZGly PS91c3IvaW5jbHVkZSBcDQogCQktLW1hbmRpcj0vdXNyL3NoYXJlL21hbiBc DQogCQktLWRhdGFkaXI9L3Vzci9zaGFyZSBcDQpkaWZmIC11TnIgeGZzLWNt ZHMub3JpZy94ZnNwcm9ncy9NYWtlZmlsZSB4ZnMtY21kcy94ZnNwcm9ncy9N YWtlZmlsZQ0KLS0tIHhmcy1jbWRzLm9yaWcveGZzcHJvZ3MvTWFrZWZpbGUJ MjAwNC0xMS0xNCAxMzo0NzowMS4wMDAwMDAwMDAgKzAxMDANCisrKyB4ZnMt Y21kcy94ZnNwcm9ncy9NYWtlZmlsZQkyMDA0LTExLTE0IDE1OjQ0OjQ3LjAw MDAwMDAwMCArMDEwMA0KQEAgLTMyLDYgKzMyLDcgQEANCiANCiBUT1BESVIg PSAuDQogSEFWRV9CVUlMRERFRlMgPSAkKHNoZWxsIHRlc3QgLWYgJChUT1BE SVIpL2luY2x1ZGUvYnVpbGRkZWZzICYmIGVjaG8geWVzIHx8IGVjaG8gbm8p DQorSFdfUExBVCA9ICQoc2hlbGwgL2Jpbi91bmFtZSAtbSkNCiANCiBpZmVx ICgkKEhBVkVfQlVJTERERUZTKSwgeWVzKQ0KIGluY2x1ZGUgJChUT1BESVIp L2luY2x1ZGUvYnVpbGRkZWZzDQpAQCAtNjAsNiArNjEsMTIgQEANCiBjbGVh bjoJIyBpZiBjb25maWd1cmUgaGFzbid0IHJ1biwgbm90aGluZyB0byBjbGVh bg0KIGVuZGlmDQogDQoraWZlcSAoJChIV19QTEFUKSwgeDg2XzY0KQ0KK0hX X0xJQiA9IGxpYjY0DQorZWxzZQ0KK0hXX0xJQiA9IGxpYg0KK2VuZGlmDQor DQogJChDT05GSUdVUkUpOg0KIAlhdXRvY29uZg0KIAkuL2NvbmZpZ3VyZSBc DQpAQCAtNjcsOCArNzQsOCBAQA0KIAkJLS1leGVjLXByZWZpeD0vIFwNCiAJ CS0tc2JpbmRpcj0vc2JpbiBcDQogCQktLWJpbmRpcj0vdXNyL3NiaW4gXA0K LQkJLS1saWJkaXI9L2xpYiBcDQotCQktLWxpYmV4ZWNkaXI9L3Vzci9saWIg XA0KKwkJLS1saWJkaXI9LyQoSFdfTElCKSBcDQorCQktLWxpYmV4ZWNkaXI9 L3Vzci8kKEhXX0xJQikgXA0KIAkJLS1pbmNsdWRlZGlyPS91c3IvaW5jbHVk ZSBcDQogCQktLW1hbmRpcj0vdXNyL3NoYXJlL21hbiBcDQogCQktLWRhdGFk aXI9L3Vzci9zaGFyZSBcDQo= --168429056-524890765-1100993556=:11405-- From owner-linux-xfs Sat Nov 20 20:02:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Nov 2004 20:02:33 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAL42Vwd020525 for ; Sat, 20 Nov 2004 20:02:31 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAL5KK29026375 for ; Sat, 20 Nov 2004 21:20:20 -0800 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAL42Aad2669547; Sat, 20 Nov 2004 20:02:11 -0800 (PST) Message-ID: <41A01346.9030402@sgi.com> Date: Sat, 20 Nov 2004 22:02:14 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Mathieu GOMBAULT , linux-xfs@oss.sgi.com Subject: Re: XFS: can't read superblock References: <419F1985.9010603@minet.net> <419F1896.6020501@gmx.net> <419F27B7.10803@minet.net> <419F6227.8050506@sgi.com> In-Reply-To: <419F6227.8050506@sgi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4484 X-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: 644 Lines: 27 Eric Sandeen wrote: > Mathieu GOMBAULT wrote: >> major minor #blocks name > > >> 22 64 160086528 hdd >> 22 65 159993460 hdd1 > > > A little odd that hdd1 is smaller than hdd? Hm, to be clearer what strikes me as odd is that hdd1 ends before the end the disk: qwerty@Pegasus:~$;-) sudo fdisk -l /dev/hdd Disk /dev/hdd: 163.9 GB, 163928604672 bytes 255 heads, 63 sectors/track, 19929 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdd1 * 2 19920 159993460 83 Linux so hdd1 does not extend to the end of the disk.... -Eric From owner-linux-xfs Sat Nov 20 20:03:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 20 Nov 2004 20:03:04 -0800 (PST) Received: from snark.thyrsus.com (dsl092-053-140.phl1.dsl.speakeasy.net [66.92.53.140]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAL432cU020554 for ; Sat, 20 Nov 2004 20:03:02 -0800 Received: from snark.thyrsus.com (localhost [127.0.0.1]) by snark.thyrsus.com (8.13.1/8.13.1) with ESMTP id iAL40jcA014232 for ; Sat, 20 Nov 2004 23:00:45 -0500 Date: Sat, 20 Nov 2004 23:00:45 -0500 From: esr@thyrsus.com Message-Id: <200411210400.iAL40jcA014232@snark.thyrsus.com> To: linux-xfs@oss.sgi.com Subject: problems in xfs_bmap.8, xfs_check.8 X-archive-position: 4485 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: esr@thyrsus.com Precedence: bulk X-list: linux-xfs Content-Length: 3088 Lines: 101 This is automatically generated email about problems in a man page for which you appear to be responsible. If you are not the right person or list, tell me and I will attempt to correct my database. See http://catb.org/~esr/doclifter/problems.html for details on how and why these patches were generated. Feel free to email me with any questions. Note: These patches do not change the mod date of any manual page. You may wish to do that by hand. Problems with xfs_bmap.8: My records indicate that you have accepted this patch, so this is just a reminder. Please try to get a release with the patch incorporated to the Fedora folks in time for Fedora Core 4. 1. Unknown or invalid macro. That is, one that does not fit in the macro set that the man page seems to be using. This is a serious error; it often means part of your text is being lost or rendered incorrectly. --- xfs_bmap.8-orig 2004-07-09 06:59:14.210997800 -0400 +++ xfs_bmap.8 2004-07-09 06:59:59.299143360 -0400 @@ -12,10 +12,12 @@ in the file that do not have any corresponding blocks (\f2hole\f1s). Each line of the listings takes the following form: -.Ex -\f2extent\f1\f7: [\f1\f2startoffset\f1\f7..\f1\f2endoffset\f1\f7]: \c -\f1\f2startblock\f1\f7..\f1\f2endblock\f1 -.Ee +.nf +.ft CW + \f2extent\f1\f7: [\f1\f2startoffset\f1\f7..\f1\f2endoffset\f1\f7]: \c + \f1\f2startblock\f1\f7..\f1\f2endblock\f1 +.ft +.fi Holes are marked by replacing the \f2startblock..endblock\f1 with \f2hole\fP. All the file offsets and disk blocks are in units of 512-byte blocks, @@ -29,9 +31,11 @@ .PP If the \f3-l\f1 option is used, then -.Ex -\f1\f2\f1\f7 \f1\f2blocks\f1\f7 -.Ee +.nf +.ft CW + \f1\f2\f1\f7 \f1\f2blocks\f1\f7 +.ft +.fi will be appended to each line. \f1\f2Nblocks\f1\f7 is the length of the extent described on the line in units of 512-byte blocks. ----------------------------- Problems with xfs_check.8: My records indicate that you have accepted this patch, so this is just a reminder. Please try to get a release with the patch incorporated to the Fedora folks in time for Fedora Core 4. 1. Unknown or invalid macro. That is, one that does not fit in the macro set that the man page seems to be using. This is a serious error; it often means part of your text is being lost or rendered incorrectly. --- xfs_check.8-orig 2004-07-09 07:01:51.627066920 -0400 +++ xfs_check.8 2004-07-09 07:03:06.440693520 -0400 @@ -90,17 +90,21 @@ rather than produce useful output. If the filesystem is completely corrupt, a core dump might be produced instead of the message -.Ex -\f2xxx\f1\f7 is not a valid filesystem\f1 -.Ee +.nf +.ft CW + \f2xxx\f1\f7 is not a valid filesystem\f1 +.ft +.fi .PP If the filesystem is very large (has many files) then .I xfs_check might run out of memory. In this case the message -.Ex -out of memory -.Ee +.nf +.ft CW + out of memory +.ft +.fi is printed. .PP The following is a description of the most likely problems and the associated ----------------------------- -- Eric S. Raymond From owner-linux-xfs Sun Nov 21 15:24:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 21 Nov 2004 15:24:14 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iALNO8kh006447 for ; Sun, 21 Nov 2004 15:24:09 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA05320; Mon, 22 Nov 2004 10:23:40 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iALNNbln6181232; Mon, 22 Nov 2004 10:23:38 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iALMLPLb001151; Mon, 22 Nov 2004 09:21:25 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iALMLNc1001148; Mon, 22 Nov 2004 09:21:23 +1100 Date: Mon, 22 Nov 2004 09:21:23 +1100 From: Nathan Scott To: tridge@samba.org Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: performance of filesystem xattrs with Samba4 Message-ID: <20041121222123.GB704@frodo> References: <1098383538.987.359.camel@new.localdomain> <16797.41728.984065.479474@samba.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16797.41728.984065.479474@samba.org> User-Agent: Mutt/1.5.3i X-archive-position: 4486 X-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: 1662 Lines: 43 Hi Andrew, On Fri, Nov 19, 2004 at 06:38:40PM +1100, tridge@samba.org wrote: > ... > The biggest change from the kernels point of view is that Samba4 makes > extensive use of filesystem xattrs. Almost every file with have a > ... > I started some simple benchmarking today using the BENCH-NBENCH > smbtorture benchmark, with 10 simulated clients and loopback > networking on a dual Xeon server with 2G ram and a 50G scsi partition. > I used a 2.6.10-rc2 kernel. This benchmark only involves a > user.DosAttrib xattr of size 44 on every file (that will be the most > common situation in production use). > ... > xfs 62 MB/sec > xfs+xattr 40 MB/sec > xfs+2Kinode 63 MB/sec > xfs+xattr+2Kinode 58 MB/sec > ... > The XFS results with default options are rather disappointing, as XFS > has usually been a good performer for Samba workloads. Increasing the > inode size to 2k brought it back to a more reasonable level. Interesting. There's been on-and-off discussion for some time as to whether the default mkfs parameters should be changed, this will add more fuel to that debate I expect. I'm curious why you went to 2K inodes instead of 512 - I guess because thats the largest inode size with a 4K blocksize? If the defaults were changed, I expect it would be to switch over to 512 byte inodes - do you have numbers for that? > To make it easier to benchmark with xattrs, I'm planning on doing a > new version of dbench with optional xattr support. That will allow > others to play with xattr performance for the above workload without Ah great, thanks, I'll be keen to try that when its available. cheers. -- Nathan From owner-linux-xfs Sun Nov 21 15:44:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 21 Nov 2004 15:44:57 -0800 (PST) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iALNis7G007454 for ; Sun, 21 Nov 2004 15:44:55 -0800 Received: by lists.samba.org (Postfix, from userid 603) id 0D9E8162BD1; Sun, 21 Nov 2004 23:44:35 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16801.10284.732681.619976@samba.org> Date: Mon, 22 Nov 2004 10:43:40 +1100 To: Nathan Scott Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: performance of filesystem xattrs with Samba4 In-Reply-To: <20041121222123.GB704@frodo> References: <1098383538.987.359.camel@new.localdomain> <16797.41728.984065.479474@samba.org> <20041121222123.GB704@frodo> X-Mailer: VM 7.19 under Emacs 21.3.1 Reply-To: tridge@samba.org From: tridge@samba.org X-archive-position: 4487 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tridge@samba.org Precedence: bulk X-list: linux-xfs Content-Length: 1545 Lines: 42 Nathan, > I'm curious why you went to 2K inodes instead of 512 - I guess > because thats the largest inode size with a 4K blocksize? If > the defaults were changed, I expect it would be to switch over > to 512 byte inodes - do you have numbers for that? It was a fairly arbitrary choice. For the test I was running the xattrs were small (44 bytes), so 512 would have been fine, but some other tests I run use larger xattrs (for NT ACLs, streams, DOS EAs etc). > Ah great, thanks, I'll be keen to try that when its available. It's now released. You can grab it at: http://samba.org/ftp/tridge/dbench/dbench-3.0.tar.gz It should produce much more consistent results than previous versions of dbench, plus it has a -x option to enable xattr support. Other changes include: - the runs are now time limited, rather than being a fixed number of operations. This gives much more consisten results, especially for fast machines. - I've changed the mapping of the filesystem operations to be much closer to what Samba4 does, including the directory scans for case insensitivity, the stat() calls in name resolution and things like statfs() calls. The modelling could still be improved, but its much better than it was. - the load file is now compatible with the smbtorture NBENCH test again (the two diverged a while back). - the default load file has been updated to be based on NetBench 7.0.3, running a enterprise disk mix. - the warmup/execute/cleanup phases are now better separated Cheers, Tridge From owner-linux-xfs Sun Nov 21 19:35:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 21 Nov 2004 19:35:27 -0800 (PST) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAM3ZGa2017130 for ; Sun, 21 Nov 2004 19:35:17 -0800 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id iAM3Ypl16222 for linux-xfs@oss.sgi.com; Mon, 22 Nov 2004 14:34:51 +1100 Date: Mon, 22 Nov 2004 14:34:51 +1100 From: Nathan Scott Message-Id: <200411220334.iAM3Ypl16222@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.4.28. X-archive-position: 4488 X-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: 96332 Lines: 1374 Date: Mon Nov 22 12:33:08 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: marcelo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.4.x-xfs-melb Modid: 2.4.x-xfs-melb:linux:20239a crypto/anubis.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/anubis.c drivers/scsi/sata_uli.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_uli.c drivers/ide/pci/delkin_cb.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/pci/delkin_cb.c crypto/wp512.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/wp512.c drivers/acpi/motherboard.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/acpi/motherboard.c Documentation/networking/proc_net_tcp.txt - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Documentation/networking/proc_net_tcp.txt CREDITS - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/CREDITS.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h Documentation/Configure.help - 1.15 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Documentation/Configure.help.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h Documentation/crypto/api-intro.txt - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Documentation/crypto/api-intro.txt.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h Documentation/filesystems/xfs.txt - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Documentation/filesystems/xfs.txt.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h Documentation/ftape.txt - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Documentation/ftape.txt.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Documentation/isdn/CREDITS - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Documentation/isdn/CREDITS.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Documentation/isdn/README.pcbit - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Documentation/isdn/README.pcbit.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h MAINTAINERS - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/MAINTAINERS.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h Makefile - 1.14 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Makefile.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/alpha/config.in - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/alpha/config.in.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/arm/config.in - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/arm/config.in.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/cris/config.in - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/cris/config.in.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/i386/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/i386/boot/compressed/misc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/boot/compressed/misc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/i386/config.in - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/config.in.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/i386/defconfig - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/defconfig.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/i386/kernel/dmi_scan.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/dmi_scan.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/i386/kernel/io_apic.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/io_apic.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/i386/kernel/pci-irq.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/pci-irq.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/i386/kernel/pci-pc.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/pci-pc.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/i386/kernel/process.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/process.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/i386/kernel/signal.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/signal.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/i386/kernel/smp.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/smp.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/i386/kernel/vm86.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/vm86.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ia64/config.in - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ia64/config.in.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ia64/defconfig - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ia64/defconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/m68k/config.in - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/m68k/config.in.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/mips/config-shared.in - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/mips/config-shared.in.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/mips/defconfig - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/mips/defconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/mips64/defconfig - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/mips64/defconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/parisc/config.in - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/parisc/config.in.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ppc/defconfig - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc/defconfig.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ppc/kernel/ppc_htab.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc/kernel/ppc_htab.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ppc64/defconfig - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc64/defconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/s390/config.in - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390/config.in.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/s390/defconfig - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390/defconfig.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/s390/kernel/entry.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390/kernel/entry.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/s390/kernel/s390_ksyms.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390/kernel/s390_ksyms.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/s390/kernel/smp.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390/kernel/smp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/s390/kernel/time.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390/kernel/time.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/s390x/config.in - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390x/config.in.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/s390x/defconfig - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390x/defconfig.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/s390x/kernel/entry.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390x/kernel/entry.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/s390x/kernel/ioctl32.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390x/kernel/ioctl32.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/s390x/kernel/linux32.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390x/kernel/linux32.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/s390x/kernel/s390_ksyms.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390x/kernel/s390_ksyms.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/s390x/kernel/smp.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390x/kernel/smp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/s390x/kernel/time.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390x/kernel/time.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sh/config.in - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sh/config.in.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sh64/config.in - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sh64/config.in.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/sh64/defconfig - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sh64/defconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sparc/config.in - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc/config.in.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc/lib/copy_user.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc/lib/copy_user.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/config.in - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/config.in.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sparc64/defconfig - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/defconfig.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/sparc64/kernel/head.S - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/head.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/sparc64/kernel/ioctl32.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/ioctl32.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sparc64/kernel/itlb_base.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/itlb_base.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/pci_iommu.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/pci_iommu.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/pci_psycho.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/pci_psycho.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/pci_sabre.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/pci_sabre.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sparc64/kernel/pci_schizo.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/pci_schizo.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/process.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/process.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc64/kernel/sbus.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/sbus.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/signal.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/signal.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/signal32.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/signal32.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc64/kernel/sparc64_ksyms.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/sparc64_ksyms.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc64/kernel/time.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/time.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/lib/Makefile - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/lib/U3copy_from_user.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/U3copy_from_user.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/lib/U3copy_in_user.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/U3copy_in_user.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/lib/U3copy_to_user.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/U3copy_to_user.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/lib/U3memcpy.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/U3memcpy.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/lib/VIScopy.S - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/VIScopy.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc64/mm/fault.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/mm/fault.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc64/mm/init.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/mm/init.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/x86_64/boot/compressed/misc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/boot/compressed/misc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/x86_64/config.in - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/config.in.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/x86_64/ia32/ia32_ioctl.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/ia32/ia32_ioctl.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/x86_64/ia32/sys_ia32.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/ia32/sys_ia32.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/x86_64/kernel/x8664_ksyms.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/kernel/x8664_ksyms.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/x86_64/lib/usercopy.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/lib/usercopy.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h crypto/Config.in - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/Config.in.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h crypto/Makefile - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h crypto/aes.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/aes.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h crypto/blowfish.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/blowfish.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h crypto/tcrypt.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/tcrypt.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h crypto/tcrypt.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/tcrypt.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h crypto/twofish.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/twofish.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/atm/eni.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/atm/eni.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/atm/fore200e.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/atm/fore200e.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/atm/suni.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/atm/suni.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/block/cciss.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/block/cciss.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/block/cciss.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/block/cciss.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/block/cpqarray.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/block/cpqarray.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/block/ll_rw_blk.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/block/ll_rw_blk.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/cdrom/aztcd.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/cdrom/aztcd.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/char/agp/agp.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/agp/agp.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/agp/agpgart_be.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/agp/agpgart_be.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/char/applicom.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/applicom.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/drm/drm_dma.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/drm/drm_dma.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/drm/radeon_state.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/drm/radeon_state.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/ftape/lowlevel/ftape-bsm.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/ftape/lowlevel/ftape-bsm.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/ftape/lowlevel/ftape-bsm.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/ftape/lowlevel/ftape-bsm.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/ftape/zftape/zftape-eof.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/ftape/zftape/zftape-eof.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/ib700wdt.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/ib700wdt.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/ip2main.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/ip2main.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/istallion.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/istallion.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/char/mxser.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/mxser.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/nwflash.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/nwflash.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/char/random.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/random.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/char/synclinkmp.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/synclinkmp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/vc_screen.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/vc_screen.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/fc4/fc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/fc4/fc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/cpqphp_ctrl.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/cpqphp_ctrl.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/ibmphp_res.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/ibmphp_res.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ide/Config.in - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/Config.in.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/ide/pci/amd74xx.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/pci/amd74xx.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/ide/pci/amd74xx.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/pci/amd74xx.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/ide/pci/piix.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/pci/piix.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/ide/pci/sc1200.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/pci/sc1200.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ide/pci/siimage.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/pci/siimage.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/ide/pci/triflex.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/pci/triflex.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ide/pci/triflex.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/pci/triflex.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ieee1394/eth1394.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ieee1394/eth1394.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/divert/divert_procfs.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/divert/divert_procfs.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/isdn/hisax/callc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/hisax/callc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/hisax/isar.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/hisax/isar.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/hisax/st5481.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/hisax/st5481.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/hysdn/hysdn_procconf.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/hysdn/hysdn_procconf.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/isdn/pcbit/callbacks.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/pcbit/callbacks.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/pcbit/callbacks.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/pcbit/callbacks.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/pcbit/capi.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/pcbit/capi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/pcbit/capi.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/pcbit/capi.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/pcbit/drv.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/pcbit/drv.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/pcbit/edss1.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/pcbit/edss1.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/pcbit/edss1.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/pcbit/edss1.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/pcbit/layer2.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/pcbit/layer2.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/pcbit/layer2.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/pcbit/layer2.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/pcbit/module.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/pcbit/module.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/pcbit/pcbit.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/pcbit/pcbit.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/md/lvm.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/md/lvm.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/radio/radio-maestro.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/media/radio/radio-maestro.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/video/bttv-driver.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/media/video/bttv-driver.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/video/w9966.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/media/video/w9966.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/message/i2o/i2o_pci.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/message/i2o/i2o_pci.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/mtd/chips/cfi_cmdset_0002.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/mtd/chips/cfi_cmdset_0002.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/mtd/devices/doc1000.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/mtd/devices/doc1000.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/mtd/maps/amd76xrom.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/mtd/maps/amd76xrom.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/8139too.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/8139too.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/dmfe.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/dmfe.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/e100/e100_main.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/e100/e100_main.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/e1000/e1000_main.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/e1000/e1000_main.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/e1000/e1000_param.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/e1000/e1000_param.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/eql.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/eql.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/fc/iph5526.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/fc/iph5526.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/fealnx.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/fealnx.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/hamachi.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/hamachi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/hamradio/dmascc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/hamradio/dmascc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/irda/ma600.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/irda/ma600.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/irda/nsc-ircc.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/irda/nsc-ircc.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/ne2k-pci.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/ne2k-pci.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/ns83820.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/ns83820.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/smc9194.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/smc9194.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/sungem.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/sungem.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/sungem.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/sungem.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/tg3.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/tg3.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/tg3.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/tg3.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/wan/dscc4.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wan/dscc4.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/wan/hd6457x.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wan/hd6457x.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/wan/lmc/lmc_debug.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wan/lmc/lmc_debug.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/wan/lmc/lmc_debug.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wan/lmc/lmc_debug.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/wan/pc300_tty.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wan/pc300_tty.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/wireless/Config.in - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/Config.in.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/wireless/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/parport/ieee1284.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/parport/ieee1284.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/parport/parport_pc.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/parport/parport_pc.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/pci/pci.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/pci/pci.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/pci/quirks.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/pci/quirks.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/pcmcia/bulkmem.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/pcmcia/bulkmem.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/pcmcia/i82365.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/pcmcia/i82365.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/pcmcia/o2micro.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/pcmcia/o2micro.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/pcmcia/ti113x.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/pcmcia/ti113x.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/pcmcia/yenta.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/pcmcia/yenta.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/s390/Config.in - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/Config.in.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/s390/Makefile - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/s390/block/dasd.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/block/dasd.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/s390/block/dasd_3990_erp.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/block/dasd_3990_erp.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/s390/char/ctrlchar.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/char/ctrlchar.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/s390/net/c7000.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/net/c7000.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/s390/net/ctcmain.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/net/ctcmain.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/s390/net/iucv.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/net/iucv.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/s390/net/netiucv.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/net/netiucv.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/s390/net/qeth.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/net/qeth.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/s390/net/qeth.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/net/qeth.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/s390/net/qeth_mpc.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/net/qeth_mpc.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/s390/qdio.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/qdio.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/s390/s390io.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/s390/s390io.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/sbus/char/bpp.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/sbus/char/bpp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/sbus/char/vfc_dev.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/sbus/char/vfc_dev.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/53c7,8xx.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/53c7,8xx.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/AM53C974.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/AM53C974.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/Config.in - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/Config.in.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/README.aic7xxx - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/README.aic7xxx.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/advansys.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/advansys.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/aic7xxx/aic79xx_osm.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/aic7xxx/aic79xx_osm.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/dpt_i2o.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/dpt_i2o.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/esp.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/esp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/fcal.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/fcal.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/ips.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/ips.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/ips.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/ips.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/megaraid.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/megaraid.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/megaraid2.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/megaraid2.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/megaraid2.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/megaraid2.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/nsp32.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/nsp32.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/pluto.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/pluto.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/qla1280.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/qla1280.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/qlogicfc.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/qlogicfc.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/qlogicpti.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/qlogicpti.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/scsi_debug.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/scsi_debug.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/scsi_error.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/scsi_error.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/scsi_merge.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/scsi_merge.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/scsi_scan.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/scsi_scan.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/scsiiom.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/scsiiom.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/seagate.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/seagate.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/sg.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sg.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/sim710.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sim710.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/sound/ac97_codec.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/sound/ac97_codec.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/sound/i810_audio.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/sound/i810_audio.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/usb/devices.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/devices.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/devio.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/devio.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/usb/gadget/net2280.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/gadget/net2280.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/usb/hid-core.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/hid-core.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/host/ehci-hcd.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/host/ehci-hcd.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/usb/host/hc_sl811.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/host/hc_sl811.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/host/usb-uhci.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/host/usb-uhci.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/usb/host/usb-uhci.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/host/usb-uhci.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/kaweth.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/kaweth.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/ov511.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/ov511.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/se401.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/se401.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/storage/scsiglue.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/storage/scsiglue.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/usb/storage/sddr09.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/storage/sddr09.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/storage/shuttle_usbat.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/storage/shuttle_usbat.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/usb/storage/transport.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/storage/transport.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/usb/storage/unusual_devs.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/storage/unusual_devs.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/storage/usb.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/storage/usb.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/usb.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/usb.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/usb/w9968cf.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/w9968cf.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/video/fbcon.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/video/fbcon.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/video/matrox/matroxfb_g450.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/video/matrox/matroxfb_g450.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/video/pm3fb.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/video/pm3fb.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/video/riva/fbdev.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/video/riva/fbdev.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/video/sstfb.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/video/sstfb.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/Config.in - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/Config.in.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h fs/affs/super.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/affs/super.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/befs/btree.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/befs/btree.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/befs/linuxvfs.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/befs/linuxvfs.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/buffer.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/buffer.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h fs/ext3/super.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/ext3/super.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/file_table.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/file_table.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/freevxfs/vxfs_extern.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/freevxfs/vxfs_extern.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/freevxfs/vxfs_subr.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/freevxfs/vxfs_subr.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/hfs/file_hdr.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/hfs/file_hdr.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/intermezzo/cache.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/intermezzo/cache.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/intermezzo/sysctl.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/intermezzo/sysctl.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/jbd/journal.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/jbd/journal.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/jfs/jfs_metapage.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/jfs/jfs_metapage.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/jfs/jfs_mount.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/jfs/jfs_mount.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/namei.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/namei.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/ncpfs/ncplib_kernel.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/ncpfs/ncplib_kernel.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/nfsd/nfs3xdr.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/nfsd/nfs3xdr.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/nfsd/vfs.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/nfsd/vfs.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ntfs/fs.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/ntfs/fs.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/ntfs/util.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/ntfs/util.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/partitions/ibm.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/partitions/ibm.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/partitions/ldm.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/partitions/ldm.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/readdir.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/readdir.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-i386/apic.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-i386/apic.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-i386/rwsem.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-i386/rwsem.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-i386/smp.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-i386/smp.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-i386/smpboot.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-i386/smpboot.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-i386/unistd.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-i386/unistd.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-ppc/unistd.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-ppc/unistd.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390/lowcore.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390/lowcore.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390/pgtable.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390/pgtable.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390/processor.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390/processor.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390/qdio.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390/qdio.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390/sigp.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390/sigp.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390/smp.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390/smp.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390x/lowcore.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390x/lowcore.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390x/pgtable.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390x/pgtable.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390x/processor.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390x/processor.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390x/qdio.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390x/qdio.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390x/siginfo.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390x/siginfo.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390x/sigp.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390x/sigp.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390x/smp.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390x/smp.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-sparc/sigcontext.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc/sigcontext.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-sparc64/asi.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/asi.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-sparc64/page.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/page.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-sparc64/pbm.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/pbm.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-sparc64/pgtable.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/pgtable.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-sparc64/sigcontext.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/sigcontext.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-sparc64/string.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/string.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-sparc64/uaccess.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/uaccess.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-x86_64/apic.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-x86_64/apic.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-x86_64/unistd.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-x86_64/unistd.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/ac97_codec.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/ac97_codec.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/agp_backend.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/agp_backend.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/blkdev.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/blkdev.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/fs.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/fs.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/linux/fsfilter.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/fsfilter.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/ide.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/ide.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/in6.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/in6.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/intermezzo_fs.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/intermezzo_fs.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/ipv6_route.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/ipv6_route.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/irq_cpustat.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/irq_cpustat.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/jbd.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/jbd.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/kernel.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/kernel.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/mm.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/mm.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/netdevice.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/netdevice.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/netfilter_ipv4/ip_conntrack.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/netfilter_ipv4/ip_conntrack.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/linux/netfilter_ipv4/ip_conntrack_ftp.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/netfilter_ipv4/ip_conntrack_ftp.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/netfilter_ipv4/ip_conntrack_irc.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/netfilter_ipv4/ip_conntrack_irc.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/nfsd/const.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/nfsd/const.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/nfsd/xdr3.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/nfsd/xdr3.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/parport_pc.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/parport_pc.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/pci.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/pci.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/linux/pci_ids.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/pci_ids.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/linux/pkt_sched.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/pkt_sched.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/linux/rbtree.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/rbtree.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/reiserfs_fs.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/reiserfs_fs.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/sched.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/sched.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/usb.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/usb.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/net/if_inet6.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/if_inet6.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/net/ip.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/ip.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/net/ip6_fib.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/ip6_fib.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/net/ipv6.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/ipv6.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/net/irda/irlmp_frame.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/irda/irlmp_frame.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/net/irda/timer.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/irda/timer.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/net/neighbour.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/neighbour.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/net/pkt_sched.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/pkt_sched.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/net/sctp/command.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/sctp/command.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/net/sctp/constants.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/sctp/constants.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/net/sctp/sm.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/sctp/sm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/scsi/scsi.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/scsi/scsi.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h kernel/fork.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/kernel/fork.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h kernel/panic.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/kernel/panic.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h kernel/sched.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/kernel/sched.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h kernel/softirq.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/kernel/softirq.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h kernel/sysctl.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/kernel/sysctl.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h lib/brlock.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/lib/brlock.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h lib/crc32.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/lib/crc32.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h lib/rbtree.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/lib/rbtree.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h lib/rwsem.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/lib/rwsem.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h lib/string.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/lib/string.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h mm/filemap.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/mm/filemap.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h mm/highmem.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/mm/highmem.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h mm/memory.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/mm/memory.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h mm/oom_kill.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/mm/oom_kill.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h mm/page_alloc.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/mm/page_alloc.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h mm/slab.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/mm/slab.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h mm/swap.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/mm/swap.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h mm/swapfile.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/mm/swapfile.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h mm/vmscan.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/mm/vmscan.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/appletalk/ddp.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/appletalk/ddp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/atm/lec.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/atm/lec.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/bluetooth/l2cap.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/bluetooth/l2cap.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/bluetooth/rfcomm/core.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/bluetooth/rfcomm/core.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/bluetooth/sco.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/bluetooth/sco.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/core/neighbour.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/core/neighbour.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv4/ip_fragment.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/ip_fragment.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/ip_output.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/ip_output.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/netfilter/arp_tables.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/arp_tables.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv4/netfilter/ip_conntrack_core.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/ip_conntrack_core.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv4/netfilter/ip_conntrack_ftp.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/ip_conntrack_ftp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/netfilter/ip_conntrack_irc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/ip_conntrack_irc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/netfilter/ip_conntrack_standalone.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/ip_conntrack_standalone.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv4/netfilter/ip_nat_ftp.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/ip_nat_ftp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/netfilter/ip_nat_irc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/ip_nat_irc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/ip_nat_snmp_basic.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/tcp_input.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/tcp_input.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv6/addrconf.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/addrconf.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv6/af_inet6.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/af_inet6.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv6/datagram.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/datagram.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv6/exthdrs.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/exthdrs.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv6/icmp.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/icmp.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv6/ip6_fib.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/ip6_fib.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv6/ip6_input.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/ip6_input.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv6/ip6_output.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/ip6_output.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv6/ipv6_sockglue.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/ipv6_sockglue.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv6/mcast.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/mcast.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/ipv6/ndisc.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/ndisc.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv6/netfilter/ip6t_LOG.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/netfilter/ip6t_LOG.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv6/protocol.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/protocol.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv6/raw.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/raw.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv6/reassembly.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/reassembly.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv6/route.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/route.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv6/sit.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/sit.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv6/tcp_ipv6.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/tcp_ipv6.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv6/udp.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/udp.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipx/af_ipx.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipx/af_ipx.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/irda/ircomm/ircomm_param.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/irda/ircomm/ircomm_param.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/irda/irlmp.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/irda/irlmp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/irda/wrapper.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/irda/wrapper.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/netlink/af_netlink.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/netlink/af_netlink.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/netsyms.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/netsyms.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sched/sch_api.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/sch_api.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/sched/sch_atm.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/sch_atm.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sched/sch_cbq.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/sch_cbq.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/sched/sch_dsmark.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/sch_dsmark.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/sched/sch_generic.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/sch_generic.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/sched/sch_htb.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/sch_htb.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/sched/sch_ingress.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/sch_ingress.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sctp/associola.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/associola.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sctp/inqueue.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/inqueue.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/sctp/output.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/output.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sctp/outqueue.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/outqueue.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sctp/protocol.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/protocol.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sctp/sm_sideeffect.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/sm_sideeffect.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sctp/sm_statefuns.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/sm_statefuns.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sctp/socket.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/socket.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sctp/ulpevent.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/ulpevent.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sctp/ulpqueue.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/ulpqueue.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sunrpc/xprt.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sunrpc/xprt.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/sched/sch_hfsc.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/sch_hfsc.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h crypto/scatterwalk.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/scatterwalk.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h crypto/arc4.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/arc4.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/series - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/series.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h split-patches/rwsem-backport - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/rwsem-backport.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/kdb-i386 - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/kdb-i386.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/kdb-common - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/kdb-common.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/dmapi-enable - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/dmapi-enable.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h split-patches/acl-backport - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/acl-backport.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/docs-update2 - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/docs-update2.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/free_more_memory - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/free_more_memory.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/downgrade_write-backport - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/downgrade_write-backport.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/export-sync_buffers - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/export-sync_buffers.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/sata_promise.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_promise.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/sata_sil.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_sil.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/sata_sis.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_sis.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/sata_svw.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_svw.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/sata_sx4.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_sx4.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/libata.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/libata.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/libata-scsi.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/libata-scsi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/libata-core.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/libata-core.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/sata_via.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_via.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/sata_vsc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_vsc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/sched/sch_netem.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/sch_netem.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/gadget/rndis.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/gadget/rndis.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/gadget/rndis.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/gadget/rndis.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/shpchprm_nonacpi.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/shpchprm_nonacpi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/shpchprm_acpi.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/shpchprm_acpi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/shpchp_pci.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/shpchp_pci.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/shpchp_hpc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/shpchp_hpc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/shpchp_ctrl.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/shpchp_ctrl.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/shpchp.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/shpchp.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/pciehprm_nonacpi.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/pciehprm_nonacpi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/pciehprm_acpi.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/pciehprm_acpi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/pciehp_pci.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/pciehp_pci.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/pciehp_hpc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/pciehp_hpc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/pciehp_ctrl.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/pciehp_ctrl.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/hotplug/pciehp.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/pciehp.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/ata.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/ata.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/libata.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/libata.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Subject: TAKE 904196 - Merge up to 2.4.28. Date: Mon Nov 22 13:26:00 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: marcelo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.4.x-xfs-melb Modid: 2.4.x-xfs-melb:linux:20241a drivers/net/wireless/prism54/Makefile - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/Makefile drivers/net/wireless/prism54/isl_38xx.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/isl_38xx.c drivers/net/wireless/prism54/isl_38xx.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/isl_38xx.h drivers/net/wireless/prism54/isl_ioctl.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/isl_ioctl.c drivers/net/wireless/prism54/isl_ioctl.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/isl_ioctl.h drivers/net/wireless/prism54/isl_oid.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/isl_oid.h drivers/net/wireless/prism54/islpci_dev.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/islpci_dev.c drivers/net/wireless/prism54/islpci_dev.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/islpci_dev.h drivers/net/wireless/prism54/islpci_eth.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/islpci_eth.c drivers/net/wireless/prism54/islpci_eth.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/islpci_eth.h drivers/net/wireless/prism54/islpci_hotplug.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/islpci_hotplug.c drivers/net/wireless/prism54/islpci_mgt.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/islpci_mgt.c drivers/net/wireless/prism54/islpci_mgt.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/islpci_mgt.h drivers/net/wireless/prism54/oid_mgt.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/oid_mgt.c drivers/net/wireless/prism54/oid_mgt.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/oid_mgt.h drivers/net/wireless/prism54/prismcompat.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/prismcompat.h drivers/net/wireless/prism54/prismcompat24.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/prism54/prismcompat24.h Subject: TAKE 904196 - Merge up to 2.4.28. Date: Mon Nov 22 13:34:25 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.4.x-xfs-melb Modid: 2.4.x-xfs-melb:linux:20243a fs/buffer.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/buffer.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h split-patches/series - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/series.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h split-patches/export-sync_buffers - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/export-sync_buffers.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Subject: TAKE 904196 - Merge up to 2.4.28. Date: Mon Nov 22 13:50:15 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.4.x-xfs-melb Modid: 2.4.x-xfs-melb:linux:20245a lib/rwsem.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/lib/rwsem.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h split-patches/rwsem-backport - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/rwsem-backport.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h Subject: TAKE 904196 - Merge up to 2.4.28. Date: Mon Nov 22 13:58:59 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.4.x-xfs-melb Modid: 2.4.x-xfs-melb:linux:20246a arch/sparc64/lib/U1copy_from_user.S - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/U1copy_from_user.S arch/sparc64/lib/U1copy_to_user.S - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/U1copy_to_user.S arch/sparc64/lib/U1memcpy.S - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/U1memcpy.S arch/sparc64/lib/U3patch.S - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/U3patch.S arch/sparc64/lib/copy_in_user.S - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/copy_in_user.S arch/sparc64/lib/memmove.S - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/memmove.S arch/sparc64/lib/user_fixup.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/user_fixup.c crypto/khazad.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/khazad.c drivers/scsi/ata_piix.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/ata_piix.c drivers/scsi/sata_nv.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_nv.c include/asm-s390/kmap_types.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390/kmap_types.h include/asm-s390x/kmap_types.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-s390x/kmap_types.h include/asm-sparc64/cmt.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/cmt.h Subject: TAKE 904196 - Merge up to 2.4.28. Date: Mon Nov 22 14:33:50 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: marcelo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.4.x-xfs-melb Modid: 2.4.x-xfs-melb:linux:20247a Documentation/i2c/writing-clients - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Documentation/i2c/writing-clients.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/alpha/boot/bootloader.lds - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/alpha/boot/bootloader.lds.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/alpha/boot/bootp.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/alpha/boot/bootp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/alpha/boot/bootpz.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/alpha/boot/bootpz.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/alpha/boot/head.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/alpha/boot/head.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/i386/kernel/acpi.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/acpi.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/i386/kernel/apic.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/apic.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/i386/kernel/mpparse.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/mpparse.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/m68k/atari/stram.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/m68k/atari/stram.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m68k/kernel/setup.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/m68k/kernel/setup.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/m68k/mm/motorola.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/m68k/mm/motorola.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/mips64/kernel/linux32.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/mips64/kernel/linux32.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/kernel/cputable.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc/kernel/cputable.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ppc/mm/hashtable.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc/mm/hashtable.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/mm/ppc_mmu.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc/mm/ppc_mmu.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/platforms/residual.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc/platforms/residual.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc64/kernel/rtas-proc.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc64/kernel/rtas-proc.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ppc64/kernel/sys_ppc32.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc64/kernel/sys_ppc32.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/sys_sparc32.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/sys_sparc32.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/x86_64/ia32/socket32.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/ia32/socket32.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h crypto/api.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/api.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h crypto/serpent.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/serpent.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/acpi/Makefile - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/acpi/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/acpi/bus.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/acpi/bus.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/acpi/dispatcher/dsopcode.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/acpi/dispatcher/dsopcode.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/acpi/events/evmisc.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/acpi/events/evmisc.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/acpi/hardware/hwsleep.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/acpi/hardware/hwsleep.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/acpi/osl.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/acpi/osl.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/acpi/system.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/acpi/system.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/acpi/utilities/utglobal.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/acpi/utilities/utglobal.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/atm/atmtcp.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/atm/atmtcp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/atm/he.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/atm/he.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/atm/idt77105.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/atm/idt77105.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/atm/iphase.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/atm/iphase.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/atm/uPD98402.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/atm/uPD98402.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/atm/zatm.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/atm/zatm.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/block/genhd.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/block/genhd.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/serial.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/serial.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/char/tty_io.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/tty_io.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/hotplug/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/hotplug/ibmphp_hpc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/hotplug/ibmphp_hpc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ide/pci/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/pci/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/isdn/eicon/eicon_idi.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/eicon/eicon_idi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/hisax/avm_pci.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/hisax/avm_pci.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/hisax/hfc_pci.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/hisax/hfc_pci.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/isdn/hysdn/hysdn_proclog.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/isdn/hysdn/hysdn_proclog.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/md/raid1.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/md/raid1.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/message/i2o/i2o_lan.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/message/i2o/i2o_lan.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/mtd/chips/cfi_cmdset_0001.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/mtd/chips/cfi_cmdset_0001.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/mtd/chips/cfi_cmdset_0020.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/mtd/chips/cfi_cmdset_0020.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/mtd/maps/elan-104nc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/mtd/maps/elan-104nc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/mtd/maps/sbc_gxx.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/mtd/maps/sbc_gxx.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/bonding/bond_main.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/bonding/bond_main.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/defxx.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/defxx.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/e100/e100.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/e100/e100.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/e1000/e1000.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/e1000/e1000.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/e1000/e1000_ethtool.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/e1000/e1000_ethtool.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/e1000/e1000_hw.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/e1000/e1000_hw.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/e1000/e1000_hw.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/e1000/e1000_hw.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/e1000/e1000_osdep.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/e1000/e1000_osdep.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/pcnet32.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/pcnet32.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/skfp/skfddi.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/skfp/skfddi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/tun.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/tun.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/wan/farsync.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wan/farsync.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/53c700.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/53c700.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic7xxx/aic79xx_osm_pci.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/aic7xxx/aic79xx_osm_pci.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/gdth.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/gdth.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/gdth.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/gdth.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/gdth_ioctl.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/gdth_ioctl.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/gdth_proc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/gdth_proc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/gdth_proc.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/gdth_proc.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/nsp32.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/nsp32.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/scsi_lib.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/scsi_lib.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/usb/audio.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/audio.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/usb/hpusbscsi.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/hpusbscsi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/microtek.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/microtek.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/serial/usbserial.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/serial/usbserial.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/usb/uss720.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/uss720.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/video/amifb.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/video/amifb.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/video/matrox/matroxfb_base.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/video/matrox/matroxfb_base.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/video/radeonfb.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/video/radeonfb.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/video/riva/accel.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/video/riva/accel.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/binfmt_elf.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/binfmt_elf.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/dcache.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/dcache.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/nfs/unlink.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/nfs/unlink.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/proc/base.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/proc/base.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/proc/root.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/proc/root.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/smbfs/proc.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/smbfs/proc.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/smbfs/sock.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/smbfs/sock.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/acpi/acglobal.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/acpi/acglobal.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/acpi/acpi_drivers.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/acpi/acpi_drivers.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-i386/mpspec.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-i386/mpspec.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-ppc/cputable.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-ppc/cputable.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/compiler.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/compiler.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/linux/if_fddi.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/if_fddi.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/proc_fs.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/proc_fs.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/sctp.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/sctp.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/linux/seq_file.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/seq_file.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/socket.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/socket.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/string.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/string.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/tcp_diag.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/tcp_diag.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/net/dn_neigh.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/dn_neigh.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/net/ip_vs.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/ip_vs.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/net/sctp/compat.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/sctp/compat.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/net/sctp/structs.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/sctp/structs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/net/sctp/ulpevent.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/sctp/ulpevent.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/net/sock.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/sock.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/net/tcp.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/tcp.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/pcmcia/mem_op.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/pcmcia/mem_op.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h init/main.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/init/main.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h kernel/printk.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/kernel/printk.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h mm/shmem.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/mm/shmem.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/atm/clip.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/atm/clip.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/atm/proc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/atm/proc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/core/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/core/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/decnet/dn_neigh.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/decnet/dn_neigh.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/decnet/dn_route.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/decnet/dn_route.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/arp.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/arp.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv4/ipconfig.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/ipconfig.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/ipvs/ip_vs_sync.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/ipvs/ip_vs_sync.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv4/netfilter/ipt_ULOG.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/ipt_ULOG.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv4/route.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/route.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/tcp_diag.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/tcp_diag.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/tcp_ipv4.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/tcp_ipv4.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv4/tcp_minisocks.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/tcp_minisocks.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv4/tcp_output.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/tcp_output.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/packet/af_packet.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/packet/af_packet.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/sched/cls_fw.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/cls_fw.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/sched/cls_route.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/cls_route.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/sched/cls_rsvp.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/cls_rsvp.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/sched/cls_u32.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/cls_u32.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/sched/estimator.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sched/estimator.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/sctp/ipv6.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/ipv6.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sctp/sm_make_chunk.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/sm_make_chunk.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sctp/transport.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/transport.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/socket.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/socket.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/unix/af_unix.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/unix/af_unix.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h scripts/Menuconfig - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/scripts/Menuconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/gadget/rndis.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/gadget/rndis.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/usb/gadget/rndis.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/gadget/rndis.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h crypto/tea.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/crypto/tea.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs Sun Nov 21 22:29:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 21 Nov 2004 22:29:22 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAM6TCm5024027 for ; Sun, 21 Nov 2004 22:29:13 -0800 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id iAM6Srb6011303 for ; Mon, 22 Nov 2004 01:28:53 -0500 (EST) Date: Mon, 22 Nov 2004 01:28:53 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: xfs badblocks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4489 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 225 Lines: 12 Hi, Is there a possibility to - either use mkfs.xfs with a "-c = check for bad blocks" flag, OR - feed in the output of the standard "badblocks" program in mkfs.xfs? root # rpm -q xfsprogs xfsprogs-2.5.6-1 Cheers, Gaspar From owner-linux-xfs Mon Nov 22 03:49:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 03:49:20 -0800 (PST) Received: from out.smtp.cz (ender.smtp.cz [81.95.97.119]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAMBnFIY014533 for ; Mon, 22 Nov 2004 03:49:16 -0800 Received: (qmail 25283 invoked from network); 22 Nov 2004 11:48:48 -0000 Received: from unknown (HELO 81.95.104.158) (ondrej@sury.org@81.95.104.158) by ender.smtp.cz with RC4-MD5 encrypted SMTP; 22 Nov 2004 11:48:48 -0000 Subject: Re: nfsd: non-standard errno: -990 From: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= To: linux-xfs@oss.sgi.com In-Reply-To: <419E71CC.7010406@sgi.com> References: <1100776614.4833.22.camel@localhost.localdomain> <419CAC5E.6070806@sgi.com> <1100787175.4833.35.camel@localhost.localdomain> <419D063A.4010809@sgi.com> <1100852618.25135.18.camel@localhost.localdomain> <419DFE30.5050202@sgi.com> <1100874902.13322.7.camel@localhost.localdomain> <419E71CC.7010406@sgi.com> Content-Type: text/plain; charset=UTF-8 Date: Mon, 22 Nov 2004 12:48:01 +0100 Message-Id: <1101124081.25807.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 8bit X-archive-position: 4490 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ondrej@sury.org Precedence: bulk X-list: linux-xfs Content-Length: 819 Lines: 26 Hi Eric, thanks for tip on newer xfs tools. We were able to repair filesystem and it's working ok again. Best regards, Ondrej Sury. On Fri, 2004-11-19 at 16:21 -0600, Eric Sandeen wrote: > OndÅ™ej Surý wrote: > > > Ok, we will try to use 2.6.25 version and I will report result > > afterwards. Is there something you are particulary interested if it > > crashes again more then full log of activity? > > > > I will try to use xfs_repair -n as first step and if it finishes, then > > use it for real. Any other suggestions? > > That sounds good. Also, have you made sure that there are no other > errors in the logs (or dmesg) about general IO problems? 990 errors can > come after the filesystem has shut down due to errors, including > underlying disk problems... -- OndÅ™ej Surý From owner-linux-xfs Mon Nov 22 06:28:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 06:28:50 -0800 (PST) Received: from precious.kicks-ass.org (IDENT:f35c25e1a6a0abffa319ee446dae52c7@dialpool1-74.dial.tijd.com [62.112.10.74]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAMESirN025884 for ; Mon, 22 Nov 2004 06:28:45 -0800 Received: from precious.kicks-ass.org ([127.0.0.1] ident=d26bd8e83fe8116b815337e3f7e6a3ff) by precious.kicks-ass.org with esmtp (Exim 4.34) id 1CWFB8-0003zW-Py; Mon, 22 Nov 2004 15:28:30 +0100 From: Jan De Luyck To: lkml@vger.kernel.org Subject: [2.6.10-rc2] XFS filesystem corruption Date: Mon, 22 Nov 2004 15:28:20 +0100 User-Agent: KMail/1.7.1 Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1369222.pFeMQG6vyx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411221528.25281.lkml@kcore.org> X-archive-position: 4491 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lkml@kcore.org Precedence: bulk X-list: linux-xfs Content-Length: 7840 Lines: 176 --nextPart1369222.pFeMQG6vyx Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello lists, [Please CC all answers from linux-xfs to me, since I'm not subscribed on th= at list] Yesterday I encountered an on-the-fly corruption of my /home filesystem. It= worked perfectly one second, the next I hit these nice errors: Nov 21 16:37:22 precious kernel: 0x0: 31 9e ce 63 cf ff 9c cf ff 31 61 63 f= f ff ff ff=20 Nov 21 16:37:23 precious kernel: Filesystem "hda5": XFS internal error xfs_= da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xc01fb908 Nov 21 16:37:23 precious kernel: [xfs_da_do_buf+905/2160] xfs_da_do_buf+0x= 389/0x870 Nov 21 16:37:23 precious kernel: [xfs_da_read_buf+88/96] xfs_da_read_buf+0= x58/0x60 Nov 21 16:37:23 precious last message repeated 2 times Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_lookup_int+386/720] xfs_di= r2_leaf_lookup_int+0x182/0x2d0 Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_lookup_int+386/720] xfs_di= r2_leaf_lookup_int+0x182/0x2d0 Nov 21 16:37:23 precious kernel: [__wake_up_common+65/112] __wake_up_commo= n+0x41/0x70 Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_lookup+55/224] xfs_dir2_le= af_lookup+0x37/0xe0 Nov 21 16:37:23 precious kernel: [xfs_dir2_lookup+298/352] xfs_dir2_lookup= +0x12a/0x160 Nov 21 16:37:23 precious kernel: [xfs_dir_lookup_int+76/304] xfs_dir_looku= p_int+0x4c/0x130 Nov 21 16:37:23 precious kernel: [xfs_lookup+80/144] xfs_lookup+0x50/0x90 Nov 21 16:37:23 precious kernel: [linvfs_lookup+82/144] linvfs_lookup+0x52= /0x90 Nov 21 16:37:23 precious kernel: [real_lookup+193/240] real_lookup+0xc1/0x= f0 Nov 21 16:37:23 precious kernel: [do_lookup+150/176] do_lookup+0x96/0xb0 Nov 21 16:37:23 precious kernel: [link_path_walk+1732/3424] link_path_walk= +0x6c4/0xd60 Nov 21 16:37:23 precious kernel: [link_path_walk+2603/3424] link_path_walk= +0xa2b/0xd60 Nov 21 16:37:23 precious kernel: [cp_new_stat64+248/272] cp_new_stat64+0xf= 8/0x110 Nov 21 16:37:23 precious kernel: [path_lookup+124/320] path_lookup+0x7c/0x= 140 Nov 21 16:37:23 precious kernel: [__user_walk+51/96] __user_walk+0x33/0x60 Nov 21 16:37:23 precious kernel: [dput+51/544] dput+0x33/0x220 Nov 21 16:37:23 precious kernel: [sys_access+133/336] sys_access+0x85/0x150 Nov 21 16:37:23 precious kernel: [path_release+21/80] path_release+0x15/0x= 50 Nov 21 16:37:23 precious kernel: [syscall_call+7/11] syscall_call+0x7/0xb Nov 21 16:37:23 precious kernel: 0x0: 31 9e ce 63 cf ff 9c cf ff 31 61 63 f= f ff ff ff=20 Nov 21 16:37:23 precious kernel: Filesystem "hda5": XFS internal error xfs_= da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xc01fb908 Nov 21 16:37:23 precious kernel: [xfs_da_do_buf+905/2160] xfs_da_do_buf+0x= 389/0x870 Nov 21 16:37:23 precious kernel: [xfs_da_read_buf+88/96] xfs_da_read_buf+0= x58/0x60 Nov 21 16:37:23 precious last message repeated 2 times Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_lookup_int+386/720] xfs_di= r2_leaf_lookup_int+0x182/0x2d0 Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_lookup_int+386/720] xfs_di= r2_leaf_lookup_int+0x182/0x2d0 Nov 21 16:37:23 precious kernel: [__wake_up_common+65/112] __wake_up_commo= n+0x41/0x70 Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_lookup+55/224] xfs_dir2_le= af_lookup+0x37/0xe0 Nov 21 16:37:23 precious kernel: [xfs_dir2_lookup+298/352] xfs_dir2_lookup= +0x12a/0x160 Nov 21 16:37:23 precious kernel: [xfs_dir_lookup_int+76/304] xfs_dir_looku= p_int+0x4c/0x130 Nov 21 16:37:23 precious kernel: [xfs_lookup+80/144] xfs_lookup+0x50/0x90 Nov 21 16:37:23 precious kernel: [linvfs_lookup+82/144] linvfs_lookup+0x52= /0x90 Nov 21 16:37:23 precious kernel: [real_lookup+193/240] real_lookup+0xc1/0x= f0 Nov 21 16:37:23 precious kernel: [do_lookup+150/176] do_lookup+0x96/0xb0 Nov 21 16:37:23 precious kernel: [link_path_walk+1732/3424] link_path_walk= +0x6c4/0xd60 Nov 21 16:37:23 precious kernel: [link_path_walk+2603/3424] link_path_walk= +0xa2b/0xd60 Nov 21 16:37:23 precious kernel: [cp_new_stat64+248/272] cp_new_stat64+0xf= 8/0x110 Nov 21 16:37:23 precious kernel: [path_lookup+124/320] path_lookup+0x7c/0x= 140 Nov 21 16:37:23 precious kernel: [__user_walk+51/96] __user_walk+0x33/0x60 Nov 21 16:37:23 precious kernel: [sys_access+133/336] sys_access+0x85/0x150 Nov 21 16:37:23 precious kernel: [path_release+21/80] path_release+0x15/0x= 50 Nov 21 16:37:23 precious kernel: [syscall_call+7/11] syscall_call+0x7/0xb Nov 21 16:37:23 precious kernel: 0x0: 10 10 10 10 10 10 00 00 21 10 10 10 1= 0 10 10 10=20 Nov 21 16:37:23 precious kernel: Filesystem "hda5": XFS internal error xfs_= da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xc01fb908 Nov 21 16:37:23 precious kernel: [xfs_da_do_buf+905/2160] xfs_da_do_buf+0x= 389/0x870 Nov 21 16:37:23 precious kernel: [xfs_da_read_buf+88/96] xfs_da_read_buf+0= x58/0x60 Nov 21 16:37:23 precious kernel: [xfs_da_read_buf+88/96] xfs_da_read_buf+0= x58/0x60 Nov 21 16:37:23 precious kernel: [xfs_initialize_vnode+780/800] xfs_initia= lize_vnode+0x30c/0x320 Nov 21 16:37:23 precious kernel: [xfs_da_read_buf+88/96] xfs_da_read_buf+0= x58/0x60 Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_addname+875/2688] xfs_dir2= _leaf_addname+0x36b/0xa80 Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_addname+875/2688] xfs_dir2= _leaf_addname+0x36b/0xa80 Nov 21 16:37:23 precious kernel: [xfs_bmap_last_offset+197/304] xfs_bmap_l= ast_offset+0xc5/0x130 Nov 21 16:37:23 precious kernel: [xfs_dir2_isleaf+44/112] xfs_dir2_isleaf+= 0x2c/0x70 Nov 21 16:37:23 precious kernel: [xfs_dir2_createname+341/384] xfs_dir2_cr= eatename+0x155/0x180 Nov 21 16:37:23 precious kernel: [xfs_dir_ialloc+145/736] xfs_dir_ialloc+0= x91/0x2e0 Nov 21 16:37:23 precious kernel: [xfs_trans_ijoin+53/144] xfs_trans_ijoin+= 0x35/0x90 Nov 21 16:37:23 precious kernel: [xfs_create+1115/1888] xfs_create+0x45b/0= x760 Nov 21 16:37:23 precious kernel: [linvfs_mknod+475/576] linvfs_mknod+0x1db= /0x240 Nov 21 16:37:23 precious kernel: [xfs_dir2_lookup+298/352] xfs_dir2_lookup= +0x12a/0x160 Nov 21 16:37:23 precious kernel: [real_lookup+193/240] real_lookup+0xc1/0x= f0 Nov 21 16:37:23 precious kernel: [dput+51/544] dput+0x33/0x220 Nov 21 16:37:23 precious kernel: [xfs_dir_lookup_int+76/304] xfs_dir_looku= p_int+0x4c/0x130 Nov 21 16:37:23 precious kernel: [permission+53/96] permission+0x35/0x60 Nov 21 16:37:23 precious kernel: [vfs_create+121/224] vfs_create+0x79/0xe0 Nov 21 16:37:23 precious kernel: [open_namei+1462/1552] open_namei+0x5b6/0= x610 Nov 21 16:37:23 precious kernel: [filp_open+62/112] filp_open+0x3e/0x70 Nov 21 16:37:23 precious kernel: [get_unused_fd+57/224] get_unused_fd+0x39= /0xe0 Nov 21 16:37:23 precious kernel: [sys_open+73/144] sys_open+0x49/0x90 Nov 21 16:37:23 precious kernel: [syscall_call+7/11] syscall_call+0x7/0xb Nov 21 16:37:23 precious kernel: xfs_force_shutdown(hda5,0x8) called from l= ine 1091 of file fs/xfs/xfs_trans.c. Return address =3D 0xc0244e4b Nov 21 16:37:23 precious kernel: Filesystem "hda5": Corruption of in-memory= data detected. Shutting down filesystem: hda5 Nov 21 16:37:23 precious kernel: Please umount the filesystem, and rectify = the problem(s) Doing an unmount/remount didn't solve it, i had to run xfs_repair on the fi= lesystem to get it back to 'work', which caused me to lose=20 a lot of stuff. (thank for backups.)=20 Any idea what can cause this? Thanks, Jan --=20 What's the MATTER Sid? ... Is your BEVERAGE unsatisfactory? --nextPart1369222.pFeMQG6vyx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBofeJUQQOfidJUwQRAnUtAJ9QwKXtbOr8rlrt3v/cO8VctJICQQCfYrrf fGekh/m6cpCoE2ovZRGA4Zo= =PGOu -----END PGP SIGNATURE----- --nextPart1369222.pFeMQG6vyx-- From owner-linux-xfs Mon Nov 22 06:30:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 06:30:53 -0800 (PST) Received: from precious.kicks-ass.org (IDENT:e886652c6d7c938f64a4ff61277e0bf5@dialpool1-74.dial.tijd.com [62.112.10.74]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAMEUlgn026241 for ; Mon, 22 Nov 2004 06:30:49 -0800 Received: from precious.kicks-ass.org ([127.0.0.1] ident=629c231c7cc671404217d5d67bd55181) by precious.kicks-ass.org with esmtp (Exim 4.34) id 1CWFD9-00041c-5B; Mon, 22 Nov 2004 15:30:35 +0100 From: Jan De Luyck To: linux-kernel@vger.kernel.org Subject: [2.6.10-rc2] XFS filesystem corruption User-Agent: KMail/1.7.1 Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Date: Mon, 22 Nov 2004 15:30:29 +0100 Content-Type: multipart/signed; boundary="nextPart1804421.FSafbFRWjE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411221530.30325.lkml@kcore.org> X-archive-position: 4492 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lkml@kcore.org Precedence: bulk X-list: linux-xfs Content-Length: 7886 Lines: 178 --nextPart1804421.FSafbFRWjE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello lists, [resend with correct email address for LKML] [Please CC all answers from linux-xfs to me, since I'm not subscribed on th= at list] Yesterday I encountered an on-the-fly corruption of my /home filesystem. It= worked perfectly one second, the next I hit these nice errors: Nov 21 16:37:22 precious kernel: 0x0: 31 9e ce 63 cf ff 9c cf ff 31 61 63 f= f ff ff ff=20 Nov 21 16:37:23 precious kernel: Filesystem "hda5": XFS internal error xfs_= da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xc01fb908 Nov 21 16:37:23 precious kernel: [xfs_da_do_buf+905/2160] xfs_da_do_buf+0x= 389/0x870 Nov 21 16:37:23 precious kernel: [xfs_da_read_buf+88/96] xfs_da_read_buf+0= x58/0x60 Nov 21 16:37:23 precious last message repeated 2 times Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_lookup_int+386/720] xfs_di= r2_leaf_lookup_int+0x182/0x2d0 Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_lookup_int+386/720] xfs_di= r2_leaf_lookup_int+0x182/0x2d0 Nov 21 16:37:23 precious kernel: [__wake_up_common+65/112] __wake_up_commo= n+0x41/0x70 Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_lookup+55/224] xfs_dir2_le= af_lookup+0x37/0xe0 Nov 21 16:37:23 precious kernel: [xfs_dir2_lookup+298/352] xfs_dir2_lookup= +0x12a/0x160 Nov 21 16:37:23 precious kernel: [xfs_dir_lookup_int+76/304] xfs_dir_looku= p_int+0x4c/0x130 Nov 21 16:37:23 precious kernel: [xfs_lookup+80/144] xfs_lookup+0x50/0x90 Nov 21 16:37:23 precious kernel: [linvfs_lookup+82/144] linvfs_lookup+0x52= /0x90 Nov 21 16:37:23 precious kernel: [real_lookup+193/240] real_lookup+0xc1/0x= f0 Nov 21 16:37:23 precious kernel: [do_lookup+150/176] do_lookup+0x96/0xb0 Nov 21 16:37:23 precious kernel: [link_path_walk+1732/3424] link_path_walk= +0x6c4/0xd60 Nov 21 16:37:23 precious kernel: [link_path_walk+2603/3424] link_path_walk= +0xa2b/0xd60 Nov 21 16:37:23 precious kernel: [cp_new_stat64+248/272] cp_new_stat64+0xf= 8/0x110 Nov 21 16:37:23 precious kernel: [path_lookup+124/320] path_lookup+0x7c/0x= 140 Nov 21 16:37:23 precious kernel: [__user_walk+51/96] __user_walk+0x33/0x60 Nov 21 16:37:23 precious kernel: [dput+51/544] dput+0x33/0x220 Nov 21 16:37:23 precious kernel: [sys_access+133/336] sys_access+0x85/0x150 Nov 21 16:37:23 precious kernel: [path_release+21/80] path_release+0x15/0x= 50 Nov 21 16:37:23 precious kernel: [syscall_call+7/11] syscall_call+0x7/0xb Nov 21 16:37:23 precious kernel: 0x0: 31 9e ce 63 cf ff 9c cf ff 31 61 63 f= f ff ff ff=20 Nov 21 16:37:23 precious kernel: Filesystem "hda5": XFS internal error xfs_= da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xc01fb908 Nov 21 16:37:23 precious kernel: [xfs_da_do_buf+905/2160] xfs_da_do_buf+0x= 389/0x870 Nov 21 16:37:23 precious kernel: [xfs_da_read_buf+88/96] xfs_da_read_buf+0= x58/0x60 Nov 21 16:37:23 precious last message repeated 2 times Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_lookup_int+386/720] xfs_di= r2_leaf_lookup_int+0x182/0x2d0 Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_lookup_int+386/720] xfs_di= r2_leaf_lookup_int+0x182/0x2d0 Nov 21 16:37:23 precious kernel: [__wake_up_common+65/112] __wake_up_commo= n+0x41/0x70 Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_lookup+55/224] xfs_dir2_le= af_lookup+0x37/0xe0 Nov 21 16:37:23 precious kernel: [xfs_dir2_lookup+298/352] xfs_dir2_lookup= +0x12a/0x160 Nov 21 16:37:23 precious kernel: [xfs_dir_lookup_int+76/304] xfs_dir_looku= p_int+0x4c/0x130 Nov 21 16:37:23 precious kernel: [xfs_lookup+80/144] xfs_lookup+0x50/0x90 Nov 21 16:37:23 precious kernel: [linvfs_lookup+82/144] linvfs_lookup+0x52= /0x90 Nov 21 16:37:23 precious kernel: [real_lookup+193/240] real_lookup+0xc1/0x= f0 Nov 21 16:37:23 precious kernel: [do_lookup+150/176] do_lookup+0x96/0xb0 Nov 21 16:37:23 precious kernel: [link_path_walk+1732/3424] link_path_walk= +0x6c4/0xd60 Nov 21 16:37:23 precious kernel: [link_path_walk+2603/3424] link_path_walk= +0xa2b/0xd60 Nov 21 16:37:23 precious kernel: [cp_new_stat64+248/272] cp_new_stat64+0xf= 8/0x110 Nov 21 16:37:23 precious kernel: [path_lookup+124/320] path_lookup+0x7c/0x= 140 Nov 21 16:37:23 precious kernel: [__user_walk+51/96] __user_walk+0x33/0x60 Nov 21 16:37:23 precious kernel: [sys_access+133/336] sys_access+0x85/0x150 Nov 21 16:37:23 precious kernel: [path_release+21/80] path_release+0x15/0x= 50 Nov 21 16:37:23 precious kernel: [syscall_call+7/11] syscall_call+0x7/0xb Nov 21 16:37:23 precious kernel: 0x0: 10 10 10 10 10 10 00 00 21 10 10 10 1= 0 10 10 10=20 Nov 21 16:37:23 precious kernel: Filesystem "hda5": XFS internal error xfs_= da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xc01fb908 Nov 21 16:37:23 precious kernel: [xfs_da_do_buf+905/2160] xfs_da_do_buf+0x= 389/0x870 Nov 21 16:37:23 precious kernel: [xfs_da_read_buf+88/96] xfs_da_read_buf+0= x58/0x60 Nov 21 16:37:23 precious kernel: [xfs_da_read_buf+88/96] xfs_da_read_buf+0= x58/0x60 Nov 21 16:37:23 precious kernel: [xfs_initialize_vnode+780/800] xfs_initia= lize_vnode+0x30c/0x320 Nov 21 16:37:23 precious kernel: [xfs_da_read_buf+88/96] xfs_da_read_buf+0= x58/0x60 Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_addname+875/2688] xfs_dir2= _leaf_addname+0x36b/0xa80 Nov 21 16:37:23 precious kernel: [xfs_dir2_leaf_addname+875/2688] xfs_dir2= _leaf_addname+0x36b/0xa80 Nov 21 16:37:23 precious kernel: [xfs_bmap_last_offset+197/304] xfs_bmap_l= ast_offset+0xc5/0x130 Nov 21 16:37:23 precious kernel: [xfs_dir2_isleaf+44/112] xfs_dir2_isleaf+= 0x2c/0x70 Nov 21 16:37:23 precious kernel: [xfs_dir2_createname+341/384] xfs_dir2_cr= eatename+0x155/0x180 Nov 21 16:37:23 precious kernel: [xfs_dir_ialloc+145/736] xfs_dir_ialloc+0= x91/0x2e0 Nov 21 16:37:23 precious kernel: [xfs_trans_ijoin+53/144] xfs_trans_ijoin+= 0x35/0x90 Nov 21 16:37:23 precious kernel: [xfs_create+1115/1888] xfs_create+0x45b/0= x760 Nov 21 16:37:23 precious kernel: [linvfs_mknod+475/576] linvfs_mknod+0x1db= /0x240 Nov 21 16:37:23 precious kernel: [xfs_dir2_lookup+298/352] xfs_dir2_lookup= +0x12a/0x160 Nov 21 16:37:23 precious kernel: [real_lookup+193/240] real_lookup+0xc1/0x= f0 Nov 21 16:37:23 precious kernel: [dput+51/544] dput+0x33/0x220 Nov 21 16:37:23 precious kernel: [xfs_dir_lookup_int+76/304] xfs_dir_looku= p_int+0x4c/0x130 Nov 21 16:37:23 precious kernel: [permission+53/96] permission+0x35/0x60 Nov 21 16:37:23 precious kernel: [vfs_create+121/224] vfs_create+0x79/0xe0 Nov 21 16:37:23 precious kernel: [open_namei+1462/1552] open_namei+0x5b6/0= x610 Nov 21 16:37:23 precious kernel: [filp_open+62/112] filp_open+0x3e/0x70 Nov 21 16:37:23 precious kernel: [get_unused_fd+57/224] get_unused_fd+0x39= /0xe0 Nov 21 16:37:23 precious kernel: [sys_open+73/144] sys_open+0x49/0x90 Nov 21 16:37:23 precious kernel: [syscall_call+7/11] syscall_call+0x7/0xb Nov 21 16:37:23 precious kernel: xfs_force_shutdown(hda5,0x8) called from l= ine 1091 of file fs/xfs/xfs_trans.c. Return address =3D 0xc0244e4b Nov 21 16:37:23 precious kernel: Filesystem "hda5": Corruption of in-memory= data detected. Shutting down filesystem: hda5 Nov 21 16:37:23 precious kernel: Please umount the filesystem, and rectify = the problem(s) Doing an unmount/remount didn't solve it, i had to run xfs_repair on the fi= lesystem to get it back to 'work', which caused me to lose=20 a lot of stuff. (thank for backups.)=20 Any idea what can cause this? Thanks, Jan --=20 What's the MATTER Sid? ... Is your BEVERAGE unsatisfactory? --nextPart1804421.FSafbFRWjE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBofgGUQQOfidJUwQRAnYBAJ9xOG7UpqqV+EpWvKdhsJ5tyAf3awCfemAL ccy405zgbhzS6nQJD67uX5A= =lRFH -----END PGP SIGNATURE----- --nextPart1804421.FSafbFRWjE-- From owner-linux-xfs Mon Nov 22 07:51:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 07:51:35 -0800 (PST) Received: from holomorphy.com (mail@holomorphy.com [207.189.100.168]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAMFpXgE031700 for ; Mon, 22 Nov 2004 07:51:33 -0800 Received: from wli by holomorphy.com with local (Exim 3.36 #1 (Debian)) id 1CWGT4-0001NC-00; Mon, 22 Nov 2004 07:51:06 -0800 Date: Mon, 22 Nov 2004 07:51:06 -0800 From: William Lee Irwin III To: Jan De Luyck Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [2.6.10-rc2] XFS filesystem corruption Message-ID: <20041122155106.GG2714@holomorphy.com> References: <200411221530.30325.lkml@kcore.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411221530.30325.lkml@kcore.org> Organization: The Domain of Holomorphy User-Agent: Mutt/1.5.6+20040722i X-archive-position: 4493 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wli@holomorphy.com Precedence: bulk X-list: linux-xfs Content-Length: 818 Lines: 14 On Mon, Nov 22, 2004 at 03:30:29PM +0100, Jan De Luyck wrote: > [resend with correct email address for LKML] > [Please CC all answers from linux-xfs to me, since I'm not subscribed on that list] > Yesterday I encountered an on-the-fly corruption of my /home filesystem. It worked perfectly one second, the next I hit these nice errors: > Nov 21 16:37:22 precious kernel: 0x0: 31 9e ce 63 cf ff 9c cf ff 31 61 63 ff ff ff ff > Nov 21 16:37:23 precious kernel: Filesystem "hda5": XFS internal error xfs_da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xc01fb908 > Nov 21 16:37:23 precious kernel: [xfs_da_do_buf+905/2160] xfs_da_do_buf+0x389/0x870 I don't have any ideas at the moment, but please cc: me also. I'd like to watch for issues I do understand as this bug's nature is clarified. -- wli From owner-linux-xfs Mon Nov 22 15:05:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 15:06:00 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAMN5xQd025592 for ; Mon, 22 Nov 2004 15:05:59 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAN0O4Jm027349 for ; Mon, 22 Nov 2004 16:24:04 -0800 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAMN4cad3034356; Mon, 22 Nov 2004 15:04:38 -0800 (PST) Message-ID: <41A27085.8030800@sgi.com> Date: Mon, 22 Nov 2004 17:04:37 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gbakos@cfa.harvard.edu CC: linux-xfs@oss.sgi.com Subject: Re: xfs badblocks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4494 X-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: 453 Lines: 20 No such feature exists. If you see bad blocks, your drive can no longer remap bad blocks internally. It will only get worse. Your drive is dying, and you need a new one. -Eric Gaspar Bakos wrote: > Hi, > > Is there a possibility to > - either use mkfs.xfs with a "-c = check for bad blocks" flag, OR > - feed in the output of the standard "badblocks" program in mkfs.xfs? > > root # rpm -q xfsprogs > xfsprogs-2.5.6-1 > > Cheers, > Gaspar > From owner-linux-xfs Mon Nov 22 15:34:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 15:34:52 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAMNYoG3003186 for ; Mon, 22 Nov 2004 15:34:50 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAN0qtEA032436 for ; Mon, 22 Nov 2004 16:52:55 -0800 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAMNYTad3035487; Mon, 22 Nov 2004 15:34:29 -0800 (PST) Message-ID: <41A27784.70505@sgi.com> Date: Mon, 22 Nov 2004 17:34:28 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jan De Luyck CC: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [2.6.10-rc2] XFS filesystem corruption References: <200411221530.30325.lkml@kcore.org> In-Reply-To: <200411221530.30325.lkml@kcore.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4495 X-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: 197 Lines: 8 The trigger was a bad magic number related to directories... hard to say what happened in the first place. Can you send the output from xfs_repair, that might offer some hints. Thanks, -Eric From owner-linux-xfs Mon Nov 22 16:26:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 16:26:24 -0800 (PST) Received: from erc-server.ercwc.org (mail.ercwc.org [198.85.167.1]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAN0QKkA012655 for ; Mon, 22 Nov 2004 16:26:21 -0800 Received: from ercwc.org ([70.144.65.215]) by erc-server.ercwc.org with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Nov 2004 19:25:55 -0500 Message-ID: <41A2837C.4080203@ercwc.org> Date: Mon, 22 Nov 2004 19:25:32 -0500 From: "Frank J. Buchholz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: bad superblock after lvextend Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Nov 2004 00:25:56.0062 (UTC) FILETIME=[FF8277E0:01C4D0F2] X-archive-position: 4496 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frankb@ercwc.org Precedence: bulk X-list: linux-xfs Content-Length: 1338 Lines: 38 Hello, I recently attempted to extend my logical volume. First I added an additional physical volume to an existing volume group. This worked fine. vgextend Volume00 /dev/sba However when it came time to run the lvextend command I received a number of device-mapper errors. lvm> lvextend -L+1G /dev/Volume00/LogVol00 Extending logical volume LogVol00 to 2.93 TB device-mapper ioctl cmd 9 failed: Invalid argument Couldn't load device 'Volume00-LogVol00'. Problem reactivating LogVol00 While I was trying to determine what the errors were I noticed that the filesystem that sits on the logical volume being extended was no longer available. I attempted to umount the filesystem however the command froze. I then rebooted the system without mounting the filesystem in question and manually mounted the filesystem. XFS reported back that it could not locate the superblock. I then ran xfs_repair... # xfs_repair /dev/Volume00/LogVol00 Phase 1 - find and verify superblock... superblock read failed, offset 0, size 524288, ag 0, rval 0 fatal error -- Invalid argument Is it possible to repair this problem either through LVM or XFS? I noticed there are a number of achieved .vg files in /etc/lvm/archive, is it possible to restore LVM from one of these? Or is it possible to rebuild the superblock? Thanks, Frank From owner-linux-xfs Mon Nov 22 17:25:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 17:25:23 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAN1PBCf015120 for ; Mon, 22 Nov 2004 17:25:19 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA05692; Tue, 23 Nov 2004 12:24:43 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAN1Ofln6184442; Tue, 23 Nov 2004 12:24:42 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iAN0MQQf001342; Tue, 23 Nov 2004 11:22:26 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iAN0MOPt001340; Tue, 23 Nov 2004 11:22:24 +1100 Date: Tue, 23 Nov 2004 11:22:24 +1100 From: Nathan Scott To: "Frank J. Buchholz" Cc: linux-xfs@oss.sgi.com Subject: Re: bad superblock after lvextend Message-ID: <20041123002224.GC695@frodo> References: <41A2837C.4080203@ercwc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41A2837C.4080203@ercwc.org> User-Agent: Mutt/1.5.3i X-archive-position: 4497 X-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: 1818 Lines: 56 On Mon, Nov 22, 2004 at 07:25:32PM -0500, Frank J. Buchholz wrote: > Hello, > > I recently attempted to extend my logical volume. First I added an > additional physical volume to an existing volume group. This worked fine. > > vgextend Volume00 /dev/sba > > However when it came time to run the lvextend command I received a > number of device-mapper errors. > > lvm> lvextend -L+1G /dev/Volume00/LogVol00 > Extending logical volume LogVol00 to 2.93 TB > device-mapper ioctl cmd 9 failed: Invalid argument > Couldn't load device 'Volume00-LogVol00'. > Problem reactivating LogVol00 > > While I was trying to determine what the errors were I noticed that the > filesystem that sits on the logical volume being extended was no longer > available. I attempted to umount the filesystem however the command > froze. I then rebooted the system without mounting the filesystem in > question and manually mounted the filesystem. XFS reported back that it > could not locate the superblock. > > I then ran xfs_repair... > # xfs_repair /dev/Volume00/LogVol00 > Phase 1 - find and verify superblock... > superblock read failed, offset 0, size 524288, ag 0, rval 0 > > fatal error -- Invalid argument > > Is it possible to repair this problem either through LVM or XFS? I Does od report "XFSB" at the start of the device? # od -c /dev/Volume00/LogVol00 -N 4 0000000 X F S B 0000004 # If not, your logical volume is seriously messed up and you'll need to fix things up inside LVM before you go anywhere near the device with xfs_repair. > noticed there are a number of achieved .vg files in /etc/lvm/archive, is > it possible to restore LVM from one of these? Or is it possible to > rebuild the superblock? Sounds like either user error, or something went wrong inside LVM? cheers. -- Nathan From owner-linux-xfs Mon Nov 22 18:01:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 18:01:45 -0800 (PST) Received: from erc-server.ercwc.org (www.ercwc.org [198.85.167.1]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAN21fH6016661 for ; Mon, 22 Nov 2004 18:01:42 -0800 Received: from ercwc.org ([70.144.65.215]) by erc-server.ercwc.org with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Nov 2004 21:01:16 -0500 Message-ID: <41A299E5.4030604@ercwc.org> Date: Mon, 22 Nov 2004 21:01:09 -0500 From: "Frank J. Buchholz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: bad superblock after lvextend References: <41A2837C.4080203@ercwc.org> <20041123002224.GC695@frodo> In-Reply-To: <20041123002224.GC695@frodo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Nov 2004 02:01:16.0859 (UTC) FILETIME=[515ED0B0:01C4D100] X-archive-position: 4498 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frankb@ercwc.org Precedence: bulk X-list: linux-xfs Content-Length: 2620 Lines: 89 Nathan Scott wrote: >On Mon, Nov 22, 2004 at 07:25:32PM -0500, Frank J. Buchholz wrote: > > >>Hello, >> >>I recently attempted to extend my logical volume. First I added an >>additional physical volume to an existing volume group. This worked fine. >> >>vgextend Volume00 /dev/sba >> >>However when it came time to run the lvextend command I received a >>number of device-mapper errors. >> >>lvm> lvextend -L+1G /dev/Volume00/LogVol00 >> Extending logical volume LogVol00 to 2.93 TB >> device-mapper ioctl cmd 9 failed: Invalid argument >> Couldn't load device 'Volume00-LogVol00'. >> Problem reactivating LogVol00 >> >>While I was trying to determine what the errors were I noticed that the >>filesystem that sits on the logical volume being extended was no longer >>available. I attempted to umount the filesystem however the command >>froze. I then rebooted the system without mounting the filesystem in >>question and manually mounted the filesystem. XFS reported back that it >>could not locate the superblock. >> >>I then ran xfs_repair... >># xfs_repair /dev/Volume00/LogVol00 >>Phase 1 - find and verify superblock... >>superblock read failed, offset 0, size 524288, ag 0, rval 0 >> >>fatal error -- Invalid argument >> >>Is it possible to repair this problem either through LVM or XFS? I >> >> > >Does od report "XFSB" at the start of the device? > ># od -c /dev/Volume00/LogVol00 -N 4 >0000000 X F S B >0000004 ># > >If not, your logical volume is seriously messed up and >you'll need to fix things up inside LVM before you go >anywhere near the device with xfs_repair. > > > >>noticed there are a number of achieved .vg files in /etc/lvm/archive, is >>it possible to restore LVM from one of these? Or is it possible to >>rebuild the superblock? >> >> > >Sounds like either user error, or something went wrong >inside LVM? > >cheers. > > > Hi Nathan, Running the command produces the following result. # od -c /dev/Volume00/LogVol00 -N 4 0000000 # Looks like I'm in bad shape. I now realize how I created this problem, I just don't know how to fix it. I mistakingly added /dev/sba as the physical volume to a volume group that contained /dev/sba1, the one partition on sba. These are essentially one in the same. So when I executed the lvextend command device-mapper had an error. I'm honestly surprised it did anything, especially write over the superblock. Any direction on how I can recover from within LVM? I never was able to execute the xfs_grow so I'm hoping the data in the filesystem still exists. Thanks, Frank Hmm, I knew I shouldn't have left SGI. From owner-linux-xfs Mon Nov 22 20:49:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 20:49:52 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAN4nlUd024724 for ; Mon, 22 Nov 2004 20:49:48 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA09709; Tue, 23 Nov 2004 15:49:19 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAN4nHln6218235; Tue, 23 Nov 2004 15:49:17 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iAN3l2Qf001833; Tue, 23 Nov 2004 14:47:02 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iAN3l0wg001831; Tue, 23 Nov 2004 14:47:00 +1100 Date: Tue, 23 Nov 2004 14:47:00 +1100 From: Nathan Scott To: esr@thyrsus.com Cc: linux-xfs@oss.sgi.com Subject: Re: problems in xfs_bmap.8, xfs_check.8 Message-ID: <20041123034700.GD695@frodo> References: <200411210400.iAL40jcA014232@snark.thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411210400.iAL40jcA014232@snark.thyrsus.com> User-Agent: Mutt/1.5.3i X-archive-position: 4499 X-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: 439 Lines: 16 On Sat, Nov 20, 2004 at 11:00:45PM -0500, esr@thyrsus.com wrote: > ... > My records indicate that you have accepted this patch, so this is just > a reminder. Please try to get a release with the patch incorporated > to the Fedora folks in time for Fedora Core 4. > ... Hmm, shouldn't this mail be directed toward the Fedora/Redhat people? The versions of packages that they ship is something they control, not us. cheers. -- Nathan From owner-linux-xfs Mon Nov 22 21:30:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 21:30:56 -0800 (PST) Received: from snark.thyrsus.com (dsl092-053-140.phl1.dsl.speakeasy.net [66.92.53.140]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAN5UrOS026013 for ; Mon, 22 Nov 2004 21:30:53 -0800 Received: from snark.thyrsus.com (localhost [127.0.0.1]) by snark.thyrsus.com (8.13.1/8.13.1) with ESMTP id iAN5S4Dk014480; Tue, 23 Nov 2004 00:28:04 -0500 Received: (from esr@localhost) by snark.thyrsus.com (8.13.1/8.13.1/Submit) id iAN5S4Qj014479; Tue, 23 Nov 2004 00:28:04 -0500 Date: Tue, 23 Nov 2004 00:28:04 -0500 From: "Eric S. Raymond" To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: problems in xfs_bmap.8, xfs_check.8 Message-ID: <20041123052804.GA14473@thyrsus.com> Reply-To: esr@thyrsus.com References: <200411210400.iAL40jcA014232@snark.thyrsus.com> <20041123034700.GD695@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041123034700.GD695@frodo> User-Agent: Mutt/1.4.1i Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy X-archive-position: 4500 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: esr@thyrsus.com Precedence: bulk X-list: linux-xfs Content-Length: 609 Lines: 17 Nathan Scott : > On Sat, Nov 20, 2004 at 11:00:45PM -0500, esr@thyrsus.com wrote: > > ... > > My records indicate that you have accepted this patch, so this is just > > a reminder. Please try to get a release with the patch incorporated > > to the Fedora folks in time for Fedora Core 4. > > ... > > Hmm, shouldn't this mail be directed toward the Fedora/Redhat > people? The versions of packages that they ship is something > they control, not us. Yeah. But I don't know how to figure out who to bug at Red Hat. You might. -- Eric S. Raymond From owner-linux-xfs Mon Nov 22 21:43:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 21:43:10 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAN5h31e026551 for ; Mon, 22 Nov 2004 21:43:08 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA10639; Tue, 23 Nov 2004 16:42:37 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAN5gZln6221407; Tue, 23 Nov 2004 16:42:35 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iAN4eKQf001999; Tue, 23 Nov 2004 15:40:20 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iAN4eIVo001997; Tue, 23 Nov 2004 15:40:18 +1100 Date: Tue, 23 Nov 2004 15:40:18 +1100 From: Nathan Scott To: "Eric S. Raymond" Cc: linux-xfs@oss.sgi.com Subject: Re: problems in xfs_bmap.8, xfs_check.8 Message-ID: <20041123044018.GE695@frodo> References: <200411210400.iAL40jcA014232@snark.thyrsus.com> <20041123034700.GD695@frodo> <20041123052804.GA14473@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041123052804.GA14473@thyrsus.com> User-Agent: Mutt/1.5.3i X-archive-position: 4501 X-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: 780 Lines: 24 On Tue, Nov 23, 2004 at 12:28:04AM -0500, Eric S. Raymond wrote: > Nathan Scott : > > On Sat, Nov 20, 2004 at 11:00:45PM -0500, esr@thyrsus.com wrote: > > > ... > > > My records indicate that you have accepted this patch, so this is just > > > a reminder. Please try to get a release with the patch incorporated > > > to the Fedora folks in time for Fedora Core 4. > > > ... > > > > Hmm, shouldn't this mail be directed toward the Fedora/Redhat > > people? The versions of packages that they ship is something > > they control, not us. > > Yeah. But I don't know how to figure out who to bug at Red Hat. > You might. No, I dunno either. I guess they probably have a Bugzilla database though, if so thats probably the right way to go. cheers. -- Nathan From owner-linux-xfs Mon Nov 22 21:52:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 21:52:33 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAN5qQLA027105 for ; Mon, 22 Nov 2004 21:52:31 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA10845; Tue, 23 Nov 2004 16:51:59 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAN5puln6220248; Tue, 23 Nov 2004 16:51:57 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iAN4neQf002021; Tue, 23 Nov 2004 15:49:41 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iAN4ndaG002019; Tue, 23 Nov 2004 15:49:39 +1100 Date: Tue, 23 Nov 2004 15:49:39 +1100 From: Nathan Scott To: "Frank J. Buchholz" Cc: linux-xfs@oss.sgi.com Subject: Re: bad superblock after lvextend Message-ID: <20041123044939.GF695@frodo> References: <41A2837C.4080203@ercwc.org> <20041123002224.GC695@frodo> <41A299E5.4030604@ercwc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41A299E5.4030604@ercwc.org> User-Agent: Mutt/1.5.3i X-archive-position: 4502 X-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: 793 Lines: 27 On Mon, Nov 22, 2004 at 09:01:09PM -0500, Frank J. Buchholz wrote: > > Running the command produces the following result. > # od -c /dev/Volume00/LogVol00 -N 4 > 0000000 > # Mmmm, not healthy. > Looks like I'm in bad shape. > I now realize how I created this problem, I just don't know how to fix it. > > I mistakingly added /dev/sba as the physical volume to a volume group > that contained /dev/sba1, the one partition on sba. These are > essentially one in the same. So when I executed the lvextend command > device-mapper had an error. I'm honestly surprised it did anything, > especially write over the superblock. > > Any direction on how I can recover from within LVM? I never was able to I don't know how to drive LVM... ask on the linux-lvm list? cheers. -- Nathan From owner-linux-xfs Mon Nov 22 22:37:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 22 Nov 2004 22:37:05 -0800 (PST) Received: from precious.kicks-ass.org (IDENT:ed85147ba2fe6342a000ec90a4f626b1@dialpool1-94.dial.tijd.com [62.112.10.94]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAN6b2Rb029559 for ; Mon, 22 Nov 2004 22:37:03 -0800 Received: from precious.kicks-ass.org ([127.0.0.1] ident=4984142a1e9d7114a9c444fd142c65e8) by precious.kicks-ass.org with esmtp (Exim 4.34) id 1CWUI7-0001jA-FM; Tue, 23 Nov 2004 07:36:43 +0100 From: Jan De Luyck To: linux-kernel@vger.kernel.org Subject: Re: [2.6.10-rc2] XFS filesystem corruption Date: Tue, 23 Nov 2004 07:36:32 +0100 User-Agent: KMail/1.7.1 Cc: Eric Sandeen , linux-xfs@oss.sgi.com References: <200411221530.30325.lkml@kcore.org> <41A27784.70505@sgi.com> In-Reply-To: <41A27784.70505@sgi.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart18057779.UHHbBsppzQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200411230736.36106.lkml@kcore.org> X-archive-position: 4503 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lkml@kcore.org Precedence: bulk X-list: linux-xfs Content-Length: 905 Lines: 34 --nextPart18057779.UHHbBsppzQ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 23 November 2004 00:34, Eric Sandeen wrote: > The trigger was a bad magic number related to directories... hard to say > what happened in the first place. Can you send the output from > xfs_repair, that might offer some hints. Sorry, but as a repair was very urgent, I didn't really think of saving the= =20 xfs_repair output.. My bad I guess. Jan --=20 The seven year itch comes from fooling around during the fourth, fifth, and sixth years. --nextPart18057779.UHHbBsppzQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBBotp0UQQOfidJUwQRAroHAJ9PVu61ukGBeK9fC1jAo1I+7/4qlACfWH1M FETWXeiD2T0YLezrEKE4HLs= =46YF -----END PGP SIGNATURE----- --nextPart18057779.UHHbBsppzQ-- From owner-linux-xfs Tue Nov 23 02:14:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Nov 2004 02:14:05 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iANAE0RQ012809 for ; Tue, 23 Nov 2004 02:14:01 -0800 Received: (qmail 32241 invoked by uid 65534); 23 Nov 2004 10:13:35 -0000 Received: from p508DD8F8.dip0.t-ipconnect.de (EHLO [192.168.0.1]) (80.141.216.248) by mail.gmx.net (mp027) with SMTP; 23 Nov 2004 11:13:35 +0100 X-Authenticated: #4512188 Message-ID: <41A30D3E.9090506@gmx.de> Date: Tue, 23 Nov 2004 11:13:18 +0100 From: "Prakash K. Cheemplavam" User-Agent: Mozilla Thunderbird 0.9 (X11/20041114) X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Lee Irwin III CC: Jan De Luyck , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [2.6.10-rc2] XFS filesystem corruption References: <200411221530.30325.lkml@kcore.org> <20041122155106.GG2714@holomorphy.com> In-Reply-To: <20041122155106.GG2714@holomorphy.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9FABCCCCF0C7D5396BCF1C01" X-archive-position: 4504 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: prakashkc@gmx.de Precedence: bulk X-list: linux-xfs Content-Length: 2901 Lines: 62 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9FABCCCCF0C7D5396BCF1C01 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit William Lee Irwin III wrote: > On Mon, Nov 22, 2004 at 03:30:29PM +0100, Jan De Luyck wrote: > >>[resend with correct email address for LKML] >>[Please CC all answers from linux-xfs to me, since I'm not subscribed on that list] >>Yesterday I encountered an on-the-fly corruption of my /home filesystem. It worked perfectly one second, the next I hit these nice errors: >>Nov 21 16:37:22 precious kernel: 0x0: 31 9e ce 63 cf ff 9c cf ff 31 61 63 ff ff ff ff >>Nov 21 16:37:23 precious kernel: Filesystem "hda5": XFS internal error xfs_da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xc01fb908 >>Nov 21 16:37:23 precious kernel: [xfs_da_do_buf+905/2160] xfs_da_do_buf+0x389/0x870 > > > I don't have any ideas at the moment, but please cc: me also. I'd like > to watch for issues I do understand as this bug's nature is clarified. While we are at it: Is xfs known to be broken while preempt is on? (Esp using ck's preemp big kernel lock?) I got following using a raid0 setup with xfs. I thought it would be a driver issue, but reformatting to ext3 the stripe array runs now w/o probs for a few days. (xfs crapped out after a few hours on heavy disk activity.) Nov 21 10:10:15 tachyon ata2: command 0x25 timeout, stat 0xd0 host_stat 0x61 Nov 21 10:10:15 tachyon ata2: status=0xd0 { Busy } Nov 21 10:10:15 tachyon SCSI error : <1 0 0 0> return code = 0x8000002 Nov 21 10:10:15 tachyon Current sdb: sense = 70 10 Nov 21 10:10:15 tachyon end_request: I/O error, dev sdb, sector 10480847 Nov 21 10:10:15 tachyon ATA: abnormal status 0xD0 on port 0xF08060C7 Nov 21 10:10:15 tachyon ATA: abnormal status 0xD0 on port 0xF08060C7 Nov 21 10:10:15 tachyon ATA: abnormal status 0xD0 on port 0xF08060C7 Nov 21 10:10:45 tachyon ata2: command 0x25 timeout, stat 0xd0 host_stat 0x61 Nov 21 10:10:45 tachyon ata2: status=0xd0 { Busy } Nov 21 10:10:45 tachyon SCSI error : <1 0 0 0> return code = 0x8000002 Nov 21 10:10:45 tachyon Current sdb: sense = 70 10 Nov 21 10:10:45 tachyon end_request: I/O error, dev sdb, sector 10480855 Nov 21 10:10:45 tachyon I/O error in filesystem ("md0") meta-data dev md0 block 0x13fd990 ("xfs_trans_read_buf") error 5 buf count 8192 etc... If you need more infos (dmesg, .config, etc) let me know. Prakash --------------enig9FABCCCCF0C7D5396BCF1C01 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBow1CxU2n/+9+t5gRAlxSAKCrkxPRzSkwXgpNOxx9W/qRWXZoVgCgpzmP rVsMuFAZQ0QY7BlCWDlE4fo= =XRsr -----END PGP SIGNATURE----- --------------enig9FABCCCCF0C7D5396BCF1C01-- From owner-linux-xfs Tue Nov 23 03:12:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Nov 2004 03:12:42 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [195.134.129.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iANBCWDH016434 for ; Tue, 23 Nov 2004 03:12:38 -0800 Received: (qmail 24702 invoked from network); 23 Nov 2004 11:12:13 -0000 Received: from unknown (HELO stinky.trash.net) ([195.134.144.50]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 23 Nov 2004 11:12:13 -0000 Received: from [192.168.1.33] (line-zh-122-185.adsl.econophone.ch [212.53.122.185]) by stinky.trash.net (Postfix) with ESMTP id 1076E948B7 for ; Tue, 23 Nov 2004 12:12:11 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v619) To: linux-xfs@oss.sgi.com Message-Id: <81DB11CE-3D40-11D9-B9BB-000A95BCCB96@iam.unibe.ch> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-494557117; protocol="application/pkcs7-signature" From: Michael Locher Subject: Is xfsdump operation atomic? Date: Tue, 23 Nov 2004 12:12:04 +0100 X-Mailer: Apple Mail (2.619) X-archive-position: 4505 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: locher@iam.unibe.ch Precedence: bulk X-list: linux-xfs Content-Length: 3890 Lines: 81 --Apple-Mail-2-494557117 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi I wonder if xfsdump is an atomic operation and thus can be savely used on a live filesystem? If not, what is the recommended way to backup a live XFS filesystem? I guess this information would also be interessting to others, so why not include it in the paragraph about xfsdump on the XFS homepage? Cheers Michael --Apple-Mail-2-494557117 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIGNTCCAu4wggJXoAMCAQICAw1GfTANBgkqhkiG9w0BAQQFADBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDQxMDIxMTg0NTQyWhcNMDUxMDIxMTg0NTQyWjBgMQ8wDQYD VQQEEwZMb2NoZXIxEDAOBgNVBCoTB01pY2hhZWwxFzAVBgNVBAMTDk1pY2hh ZWwgTG9jaGVyMSIwIAYJKoZIhvcNAQkBFhNsb2NoZXJAaWFtLnVuaWJlLmNo MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt+bngjR6SnT1CxfN V2dCYfudUAr26Mqhn2kuFFpt8IXWhi/n4nZJN2N7lPTYyq9yG0eNego91FYP bwvmrOmmvvHJDvQRzeIGIKrueJPveRED+Tlwaku/ZHHS3PNkoYxf727L5wZN cwbrPLBAbemWz9WqgCETZ9puy5qJ3DnpuBFIKSP4dTHFjSioI6J1KoJn8NsQ Ai38X6vZw5b/gD0mH+KqGzASpU3Hq5eYryg0MHevLWiy3ePFpa+ZuBmleS1J UWGceGEdph6/4rcadifo8KoZ8DWrB5gHhsAOpDTI5wnzQm90S0Wq24+qR8C0 BwKWfI/aSfTgKhWuIgEz/9PfeQIDAQABozAwLjAeBgNVHREEFzAVgRNsb2No ZXJAaWFtLnVuaWJlLmNoMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQAD gYEAMnqE4jxZpS/FBwRHfNycdr+Hmi/7AoK2nmfxgVl09W/Ti8juf6vXR+B1 t4o4081V3oroRYvpe2PbXRglqjG1xOeRDlhDKi+3QCVXoM95657D2yH2nYcT VzEmb9u4zh9Fz9+RNUb8KI1sjvCbro9PKtooH9y3nEDdZy3UpXT/lRIwggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVt YWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5 WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVz VftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJj WiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/ QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEw EgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVM YWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+v rL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDF GguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVN d+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIC5zCCAuMCAQEwaTBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EC Aw1GfTAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNDExMjMxMTEyMDVaMCMGCSqGSIb3DQEJBDEW BBS433ZQlytNtFxcLSB63PokgYz/3jB4BgkrBgEEAYI3EAQxazBpMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDDUZ9MHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw1GfTAN BgkqhkiG9w0BAQEFAASCAQAddyGOa/2/bu1eHUEXS55MfB1WcOhatJilhVXU IyEAsbwKPRadzHJ5gh6ZNg0tgoZjWqGKKzmffvybIDrUY+in+xml6MO+xJYu CLvoNWIiUrUlUyctWNzOvoAo+VCWi1IUriBwXs9hRQCRBvR1/Je8XBmnlP/5 RudmyKT0aXFvBB38DCLVWT5tSWfEabhcd941oQeUBMXdQCEi5DluO/Sek9xP DL5A5lr1K5qe1b33seufCNbXJkOr8HJLN2ZLA9C4OIi1VZxjWTVg9o7HGO1o kbamxiArpj0rrv+Nj2V6DkrDFCLdW8Hve3A0YTipscdYli4nJK19GovbnXp0 orYVAAAAAAAA --Apple-Mail-2-494557117-- From owner-linux-xfs Tue Nov 23 03:17:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Nov 2004 03:18:02 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:eN9e6KGwL/2z71UwE0GrK1o/fXh/jbxX@burgers.bubbanfriends.org [69.212.163.241]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iANBHrrO016840 for ; Tue, 23 Nov 2004 03:17:58 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id D58E41804DEB; Tue, 23 Nov 2004 06:17:33 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11582-06; Tue, 23 Nov 2004 06:17:33 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 410CE1803655; Tue, 23 Nov 2004 06:17:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 357731C0BACF; Tue, 23 Nov 2004 06:17:33 -0500 (EST) Date: Tue, 23 Nov 2004 06:17:33 -0500 (EST) From: Mike Burger To: Michael Locher Cc: linux-xfs@oss.sgi.com Subject: Re: Is xfsdump operation atomic? In-Reply-To: <81DB11CE-3D40-11D9-B9BB-000A95BCCB96@iam.unibe.ch> Message-ID: References: <81DB11CE-3D40-11D9-B9BB-000A95BCCB96@iam.unibe.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-archive-position: 4506 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 800 Lines: 30 On Tue, 23 Nov 2004, Michael Locher wrote: > Hi > > I wonder if xfsdump is an atomic operation and thus can be savely used > on a live filesystem? > If not, what is the recommended way to backup a live XFS filesystem? > > I guess this information would also be interessting to others, so why > not include it in the paragraph about xfsdump on the XFS homepage? Personally, I'm using a RAID card, on which I mirror my XFS filesystem on multiple drives. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs Tue Nov 23 04:30:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Nov 2004 04:30:08 -0800 (PST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iANCU55o022571 for ; Tue, 23 Nov 2004 04:30:06 -0800 Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id iANCTgdE013601 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 23 Nov 2004 13:29:42 +0100 (CET) Received: from corbeau.imag.fr ([129.88.43.162]) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1CWZni-0007zq-00 for ; Tue, 23 Nov 2004 13:29:42 +0100 Date: Tue, 23 Nov 2004 13:27:37 +0100 From: Nicolas.Kowalski@imag.fr To: linux-xfs@oss.sgi.com Subject: Re: Is xfsdump operation atomic? In-Reply-To: <81DB11CE-3D40-11D9-B9BB-000A95BCCB96@iam.unibe.ch> Message-ID: References: <81DB11CE-3D40-11D9-B9BB-000A95BCCB96@iam.unibe.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (imag.imag.fr [129.88.30.1]); Tue, 23 Nov 2004 13:29:42 +0100 (CET) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 4508 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 578 Lines: 34 On Tue, 23 Nov 2004, Michael Locher wrote: > Hi Hello. > I wonder if xfsdump is an atomic operation and thus can be savely used on a > live filesystem? It is not atomic AFAIK. > If not, what is the recommended way to backup a live XFS filesystem? You may use LVM snapshots (untested): - freeze the filesystem - snapshot it - unfreeze the filesystem - xfsdump on the snapshot - remove the snapshot At work, we do not use LVM, but rsync to create a almost-snapshot on a backup-dedicated server. Once done, we backup this server with xfsdump. Regards. -- Nicolas From owner-linux-xfs Tue Nov 23 04:29:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Nov 2004 04:29:59 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [195.134.129.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iANCTlHg022509 for ; Tue, 23 Nov 2004 04:29:52 -0800 Received: (qmail 29937 invoked from network); 23 Nov 2004 12:29:28 -0000 Received: from unknown (HELO stinky.trash.net) ([195.134.144.50]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 23 Nov 2004 12:29:28 -0000 Received: from [192.168.1.33] (line-zh-122-185.adsl.econophone.ch [212.53.122.185]) by stinky.trash.net (Postfix) with ESMTP id B1761948C1; Tue, 23 Nov 2004 13:29:25 +0100 (MET) In-Reply-To: References: <81DB11CE-3D40-11D9-B9BB-000A95BCCB96@iam.unibe.ch> <3F3ABBEB-3D42-11D9-B9BB-000A95BCCB96@iam.unibe.ch> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4C4CCA48-3D4B-11D9-B9BB-000A95BCCB96@iam.unibe.ch> Content-Transfer-Encoding: 7bit Cc: linux-xfs@oss.sgi.com From: Michael Locher Subject: Re: Is xfsdump operation atomic? Date: Tue, 23 Nov 2004 13:29:19 +0100 To: Mike Burger X-Mailer: Apple Mail (2.619) X-archive-position: 4507 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: locher@iam.unibe.ch Precedence: bulk X-list: linux-xfs Content-Length: 1538 Lines: 43 Am 23.11.2004 um 13:15 schrieb Mike Burger: > On Tue, 23 Nov 2004, Michael Locher wrote: > >> Am 23.11.2004 um 12:17 schrieb Mike Burger: >>> On Tue, 23 Nov 2004, Michael Locher wrote: >>>> I wonder if xfsdump is an atomic operation and thus can be savely >>>> used >>>> on a live filesystem? >>>> If not, what is the recommended way to backup a live XFS filesystem? >>>> >>>> I guess this information would also be interessting to others, so >>>> why >>>> not include it in the paragraph about xfsdump on the XFS homepage? >>> >>> Personally, I'm using a RAID card, on which I mirror my XFS >>> filesystem >>> on >>> multiple drives. >> How do you recover that file that a user deleted accidentally? ;-) > > I guess, in that case, you don't. > > However, you can use any of the normal methods...tar, rsync, cpio... the methods you listed are certainly not *atomic*. i need a consistent snapshot of the filesystem. one option is to use LVM or DeviceMapper an create a snapshot. my original question was, if xfsdump also gives assurances for atomicity. > The problem with dump is that, if you have multiple filesystems, you > have > to specify them, individually...the same applies to xfsdump. this is not actually a problem for me. snapshoting vith LVM would also be on FS level. > Using tar or somesuch would probably suit your needs better. those tools also miss the ACLs, extended attributes and quota of XFS. i am actually happy with xfsdump, i just wanted to know if it is save to use on a busy server. cheers Michael From owner-linux-xfs Tue Nov 23 09:30:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Nov 2004 09:30:33 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iANHUTWN004169 for ; Tue, 23 Nov 2004 09:30:30 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id iANHU4904023 for ; Tue, 23 Nov 2004 09:30:04 -0800 Date: Tue, 23 Nov 2004 09:29:51 -0800 From: Andrew Morton To: linux-xfs@oss.sgi.com Subject: Fw: Re: oops with dual xeon 2.8ghz 4gb ram +smp, software raid, lvm, and xfs Message-Id: <20041123092951.4c5f2097.akpm@osdl.org> 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: 4509 X-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: 1562 Lines: 50 This person's stack overrun can be seen at: http://www.icglink.com/cluster-debug-info.html (search for dm_table_unplug_all+0x41/0x43) It seems mainly to be due to XFS. Is there anything we can do about that? Begin forwarded message: Date: Tue, 23 Nov 2004 09:37:44 -0600 From: Phil Dier To: linux-kernel@vger.kernel.org Cc: Scott Holdren , ziggy , Jack Massari Subject: Re: oops with dual xeon 2.8ghz 4gb ram +smp, software raid, lvm, and xfs On Mon, 22 Nov 2004 16:17:25 -0800 Andrew Morton wrote: > yow. The dread combination of XFS, LVM, software RAID and bloaty scsi > drivers. Looks like a stack overrun. > > Can you rebuild the kernel with CONFIG_4KSTACKS=n? > Thanks for the suggestion.. I'm doing a burn-in right now with 8k stacks, and so far, so good. I'm building this system with stability and flexibility foremost in mind. Am I foolish in using all of these technologies with a new-ish version of 2.6? Is there a particular version that would be better suited for my application? Any other suggestions you (or anyone else on the list) could give regarding stability would be greatly appreciated. Thanks, -- Phil Dier (ICGLink.com -- 615 370-1530 x733) /* vim:set noai nocindent ts=8 sw=8: */ - 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 Tue Nov 23 11:14:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Nov 2004 11:14:08 -0800 (PST) Received: from mustang.oldcity.dca.net (mustang.oldcity.dca.net [216.158.38.3]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iANJE4wn007632 for ; Tue, 23 Nov 2004 11:14:05 -0800 Received: (qmail 5036 invoked from network); 23 Nov 2004 19:13:44 -0000 Received: from unknown (HELO debian) (207.245.115.154) by mustang with SMTP; 23 Nov 2004 19:13:44 -0000 Subject: Re: [2.6.10-rc2] XFS filesystem corruption From: Lee Revell To: "Prakash K. Cheemplavam" Cc: William Lee Irwin III , Jan De Luyck , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com In-Reply-To: <41A30D3E.9090506@gmx.de> References: <200411221530.30325.lkml@kcore.org> <20041122155106.GG2714@holomorphy.com> <41A30D3E.9090506@gmx.de> Content-Type: text/plain Date: Tue, 23 Nov 2004 14:13:43 -0500 Message-Id: <1101237223.6358.10.camel@krustophenia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-archive-position: 4510 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rlrevell@joe-job.com Precedence: bulk X-list: linux-xfs Content-Length: 223 Lines: 8 On Tue, 2004-11-23 at 11:13 +0100, Prakash K. Cheemplavam wrote: > Is xfs known to be broken while preempt is on? (Esp > using ck's preemp big kernel lock?) Minor nitpick: Ingo wrote the preempt BKL code, not Con. Lee From owner-linux-xfs Tue Nov 23 11:19:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Nov 2004 11:19:06 -0800 (PST) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iANJJ2Ui008022 for ; Tue, 23 Nov 2004 11:19:03 -0800 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Nov 2004 11:18:38 -0800 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Nov 2004 11:18:34 -0800 Message-ID: <41A38BF9.1090600@xfs.org> Date: Tue, 23 Nov 2004 13:14:01 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: linux-xfs@oss.sgi.com Subject: Re: Fw: Re: oops with dual xeon 2.8ghz 4gb ram +smp, software raid, lvm, and xfs References: <20041123092951.4c5f2097.akpm@osdl.org> In-Reply-To: <20041123092951.4c5f2097.akpm@osdl.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Nov 2004 19:18:34.0963 (UTC) FILETIME=[3A2BD230:01C4D191] X-archive-position: 4511 X-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: 1586 Lines: 49 Andrew Morton wrote: > This person's stack overrun can be seen at: > > http://www.icglink.com/cluster-debug-info.html > > (search for dm_table_unplug_all+0x41/0x43) > > It seems mainly to be due to XFS. Is there anything we can do about that? His summary suggests it is not just XFS he sees it on: Kernel oops during heavy I/O on Software RAID device with LVM and XFS (or JFS or reiser) I have always thought 4K stacks were going to bring things like this out of the woodwork, he could have been doing his I/O though NFS on top of this too. Once you start building complex I/O systems with layers of drivers and filesystems, 4K starts to look very small. In general, if you give people lego bricks they will eventually build something very tall out of them. Try NFS -> journalled filesystem -> LVM/MD -> Fiber Channel (throw in multiple paths to the devices here as well). And yes I know the standard argument about interrupts could kill you anyway in the 2.4 kernel. A quick summary of what is happening in that stack is: Write call wants to allocate pages pages get flushed into xfs xfs needs to allocate an extent for the pages In order to allocate the extent, xfs needs to read some metadata Boom I am sure there is some dieting which could be done in some xfs functions to prune a few bytes here or there, which will stave off the inevitable until someone else decides to insert an encryption layer into the stack somewhere. Moving the actual flushing of the dirty pages off to another thread so there is more stack to play with is another option. Steve From owner-linux-xfs Tue Nov 23 11:22:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Nov 2004 11:22:33 -0800 (PST) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iANJMN1u008414 for ; Tue, 23 Nov 2004 11:22:28 -0800 Received: (qmail 18693 invoked by uid 65534); 23 Nov 2004 19:21:58 -0000 Received: from p508DD8F8.dip0.t-ipconnect.de (EHLO [192.168.0.1]) (80.141.216.248) by mail.gmx.net (mp010) with SMTP; 23 Nov 2004 20:21:58 +0100 X-Authenticated: #4512188 Message-ID: <41A38DF8.40907@gmx.de> Date: Tue, 23 Nov 2004 20:22:32 +0100 From: "Prakash K. Cheemplavam" User-Agent: Mozilla Thunderbird 0.9 (X11/20041114) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Lee Revell CC: William Lee Irwin III , Jan De Luyck , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [2.6.10-rc2] XFS filesystem corruption References: <200411221530.30325.lkml@kcore.org> <20041122155106.GG2714@holomorphy.com> <41A30D3E.9090506@gmx.de> <1101237223.6358.10.camel@krustophenia.net> In-Reply-To: <1101237223.6358.10.camel@krustophenia.net> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDD8C33BBD5079D789DF4012A" X-archive-position: 4512 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: prakashkc@gmx.de Precedence: bulk X-list: linux-xfs Content-Length: 1034 Lines: 34 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDD8C33BBD5079D789DF4012A Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lee Revell schrieb: > On Tue, 2004-11-23 at 11:13 +0100, Prakash K. Cheemplavam wrote: > >>Is xfs known to be broken while preempt is on? (Esp >>using ck's preemp big kernel lock?) > > > Minor nitpick: Ingo wrote the preempt BKL code, not Con. Oh yes, I know, but it is in Con's kernel, and IIRC he merged nto all of his patches, so I thought this would be more precise. ;-) Prakash --------------enigDD8C33BBD5079D789DF4012A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBo434xU2n/+9+t5gRAua8AJ4u9qPkE47iOiWY7KYxjv7EvUVqFACgx5Yk ee1pA0+PNT1cdb0Hl38d1gw= =ygcz -----END PGP SIGNATURE----- --------------enigDD8C33BBD5079D789DF4012A-- From owner-linux-xfs Tue Nov 23 13:28:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Nov 2004 13:28:19 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iANLSBOZ016382 for ; Tue, 23 Nov 2004 13:28:16 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA28637; Wed, 24 Nov 2004 08:27:43 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iANLReln6233479; Wed, 24 Nov 2004 08:27:40 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id iANLRaRZ6236640; Wed, 24 Nov 2004 08:27:36 +1100 (EST) Date: Wed, 24 Nov 2004 08:27:36 +1100 From: Nathan Scott To: "Prakash K. Cheemplavam" Cc: William Lee Irwin III , Jan De Luyck , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [2.6.10-rc2] XFS filesystem corruption Message-ID: <20041124082736.E6205230@wobbly.melbourne.sgi.com> References: <200411221530.30325.lkml@kcore.org> <20041122155106.GG2714@holomorphy.com> <41A30D3E.9090506@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <41A30D3E.9090506@gmx.de>; from prakashkc@gmx.de on Tue, Nov 23, 2004 at 11:13:18AM +0100 X-archive-position: 4513 X-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: 964 Lines: 26 On Tue, Nov 23, 2004 at 11:13:18AM +0100, Prakash K. Cheemplavam wrote: > > While we are at it: Is xfs known to be broken while preempt is on? (Esp Nope. > using ck's preemp big kernel lock?) I got following using a raid0 setup > with xfs. I thought it would be a driver issue, but reformatting to ext3 > the stripe array runs now w/o probs for a few days. (xfs crapped out > after a few hours on heavy disk activity.) > ... > Nov 21 10:10:45 tachyon end_request: I/O error, dev sdb, sector 10480855 > Nov 21 10:10:45 tachyon I/O error in filesystem ("md0") meta-data dev > md0 block 0x13fd990 ("xfs_trans_read_buf") error 5 buf count 8192 This looks like your driver passed an error back up to the filesystem while it was doing metadata IO and XFS chose to shut it down to prevent further damage. It's unlikely to be a preempt/xfs problem. Possibly hardware. Did you see any of those device errors since switching to ext3? cheers. -- Nathan From owner-linux-xfs Tue Nov 23 14:09:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Nov 2004 14:09:48 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iANM9e0Q019265 for ; Tue, 23 Nov 2004 14:09:44 -0800 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id iANM92912420; Tue, 23 Nov 2004 14:09:02 -0800 Date: Tue, 23 Nov 2004 14:08:48 -0800 From: Andrew Morton To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Fw: Re: oops with dual xeon 2.8ghz 4gb ram +smp, software raid, lvm, and xfs Message-Id: <20041123140848.092ded67.akpm@osdl.org> In-Reply-To: <41A38BF9.1090600@xfs.org> References: <20041123092951.4c5f2097.akpm@osdl.org> <41A38BF9.1090600@xfs.org> 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: 4514 X-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: 630 Lines: 21 Steve Lord wrote: > > Andrew Morton wrote: > > This person's stack overrun can be seen at: > > > > http://www.icglink.com/cluster-debug-info.html > > > > (search for dm_table_unplug_all+0x41/0x43) > > > > It seems mainly to be due to XFS. Is there anything we can do about that? > > His summary suggests it is not just XFS he sees it on: > > Kernel oops during heavy I/O on Software RAID device with LVM and XFS (or JFS or > reiser) Well yes. But looking at the trace starting with "dm_table_unplug_all+0x41/0x43", it's all XFS. Has anyone run that stack-space measurement tool across it all? From owner-linux-xfs Tue Nov 23 15:08:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 23 Nov 2004 15:08:57 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iANN8rrh022051 for ; Tue, 23 Nov 2004 15:08:54 -0800 Received: from melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA01463 for ; Wed, 24 Nov 2004 10:08:27 +1100 Date: Wed, 24 Nov 2004 10:08:27 +1100 From: Ivan Rayner To: linux-xfs@oss.sgi.com Subject: Re: Is xfsdump operation atomic? Message-Id: <20041124100827.227abd72.ivanr@sgi.com> In-Reply-To: <81DB11CE-3D40-11D9-B9BB-000A95BCCB96@iam.unibe.ch> References: <81DB11CE-3D40-11D9-B9BB-000A95BCCB96@iam.unibe.ch> Organization: SGI X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; mips-sgi-irix6.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4515 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ivanr@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1599 Lines: 40 On Tue, 23 Nov 2004 12:12:04 +0100, Michael Locher wrote: > I wonder if xfsdump is an atomic operation No it isn't. > and thus can be savely used on a live filesystem? Yes it can. In fact it can _only_ be run on a live filesystem. > If not, what is the recommended way to backup a live XFS filesystem? Whatever you like that suits your needs. xfsdump is suitable for many but there are many options from commercial backup programs like Legato Networker to things like tar & cpio. > I guess this information would also be interessting to others, so why > not include it in the paragraph about xfsdump on the XFS homepage? I'm sure the man page states that it should be run on a mounted filesystem. You seem to be of the opinion that you can't create a backup of a live filesystem. My guess is that you assume a backup is a strict snapshot in time of the filesystem -- it isn't. If a file is removed or created while a xfsdump is running, then it may or may not be included in the dump. This is OK, because in tomorrow night's incremental backup the file will then be included or removed as appropriate. If you have a 24hr schedule then you should assume that the cycle starts when xfsdump starts. Anything that happens while xfsdump is running will be guaranteed to be on the following dump, but if you're lucky then it will make it in the current dump. If you really want to create a full dump, then just make sure filesystem is not in use, by un-exporting it via nfs or mounting it on another mount point, or stop users logging in, or scheduling it for 3am, or whatever... Ivan From owner-linux-xfs Wed Nov 24 02:28:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Nov 2004 02:28:30 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAOASH1T024436 for ; Wed, 24 Nov 2004 02:28:17 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAO58UxT019334 for ; Tue, 23 Nov 2004 23:08:30 -0600 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAO58Sad3228302; Tue, 23 Nov 2004 21:08:28 -0800 (PST) Message-ID: <41A4174B.1050402@sandeen.net> Date: Tue, 23 Nov 2004 23:08:27 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Andrew Morton , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Fw: Re: oops with dual xeon 2.8ghz 4gb ram +smp, software raid, lvm, and xfs References: <20041123092951.4c5f2097.akpm@osdl.org> <41A38BF9.1090600@xfs.org> <20041123140848.092ded67.akpm@osdl.org> <41A41425.6080000@sgi.com> In-Reply-To: <41A41425.6080000@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4517 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: linux-xfs Content-Length: 647 Lines: 28 Eric Sandeen wrote: > Here's some output from Keith's stackcheck script. Oh, and just to show we're not the only ones ;-) checking fs/reiserfs/reiserfs.ko 104 search_by_key 114 reiserfs_breada 118 reiserfs_file_write 130 reiserfs_add_entry 150 __xattr_readdir 158 reiserfs_readdir 174 reiserfs_allocate_blocks_for_region 1d4 reiserfs_insert_item 1d8 reiserfs_parse_options 1d8 reiserfs_paste_into_item 20c reiserfs_cut_from_item 218 reiserfs_delete_item 21c reiserfs_get_block 240 reiserfs_delete_solid_item 29c reiserfs_rename but for the sake of semi-completeness, ext3 shows no users > 0x100 (Hm, and who pushes for 4k stacks?) :) -Eric From owner-linux-xfs Wed Nov 24 02:28:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Nov 2004 02:28:28 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAOASHcg024443 for ; Wed, 24 Nov 2004 02:28:18 -0800 Received: from omx2.sgi.com ([198.149.32.25]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAO3JNxT003857 for ; Tue, 23 Nov 2004 21:19:23 -0600 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 iAO4bumJ014025 for ; Tue, 23 Nov 2004 20:37:57 -0800 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id iAO3I9E05612; Wed, 24 Nov 2004 14:18:09 +1100 Date: Wed, 24 Nov 2004 14:18:09 +1100 From: Nathan Scott Message-Id: <200411240318.iAO3I9E05612@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@cthulhu.engr.sgi.com Subject: PARTIAL TAKE 925766 - fix direct IO deadlock X-archive-position: 4516 X-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: 924 Lines: 24 Fix i_sem and XFS IO lock locking-order-reversal on direct IO reads. Date: Wed Nov 24 14:16:26 AEDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: felixb,cattelan,hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:20286a fs/xfs/linux-2.6/xfs_lrw.c - 1.218 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.218&r2=text&tr2=1.217&f=h Modid: 2.6.x-xfs-melb:linux:20286b split-patches/direct-io-locking - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/direct-io-locking fs/direct-io.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/direct-io.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h split-patches/series - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/series.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h From owner-linux-xfs Wed Nov 24 02:38:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Nov 2004 02:38:27 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [195.134.129.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAOAc4Ef026990 for ; Wed, 24 Nov 2004 02:38:25 -0800 Received: (qmail 383 invoked from network); 24 Nov 2004 08:51:04 -0000 Received: from unknown (HELO stinky.trash.net) ([195.134.144.50]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 24 Nov 2004 08:51:04 -0000 Received: from [192.168.1.33] (unknown [212.53.109.43]) by stinky.trash.net (Postfix) with ESMTP id CF520948C0 for ; Wed, 24 Nov 2004 09:51:02 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <38A5E378-3DF4-11D9-9800-000A95BCCB96@iam.unibe.ch> References: <38A5E378-3DF4-11D9-9800-000A95BCCB96@iam.unibe.ch> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Locher Subject: Re: Is xfsdump operation atomic? Date: Wed, 24 Nov 2004 09:50:56 +0100 To: linux-xfs@oss.sgi.com X-Mailer: Apple Mail (2.619) X-archive-position: 4518 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: locher@iam.unibe.ch Precedence: bulk X-list: linux-xfs Content-Length: 1076 Lines: 30 Ivan, thanks for commenting on this. Am 23.11.2004 um 13:12 schrieb Ivan Rayner: > You seem to be of the opinion that you can't create a backup of a live > filesystem. My guess is that you assume a backup is a strict snapshot > in > time of the filesystem -- it isn't. But it could be... it would be a nice feature to have, tough i am sure it is not trivial to implement. > If a file is removed or created while a xfsdump is running, then it > may or > may not be included in the dump. This is OK, because in tomorrow > night's > incremental backup the file will then be included or removed as > appropriate. If you have a 24hr schedule then you should assume that > the > cycle starts when xfsdump starts. Anything that happens while xfsdump > is > running will be guaranteed to be on the following dump, but if you're > lucky then it will make it in the current dump. What happens if a large file (eg a multi GB database file) is modified during the dump. Will it be consistent? i.e are write operations allowed on a file when its data is dumped? Michael From owner-linux-xfs Wed Nov 24 02:51:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Nov 2004 02:51:17 -0800 (PST) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAOApDt8032295 for ; Wed, 24 Nov 2004 02:51:14 -0800 Received: (qmail 16224 invoked by uid 65534); 24 Nov 2004 08:04:07 -0000 Received: from p508DC743.dip0.t-ipconnect.de (EHLO [192.168.0.1]) (80.141.199.67) by mail.gmx.net (mp027) with SMTP; 24 Nov 2004 09:04:07 +0100 X-Authenticated: #4512188 Message-ID: <41A44071.9040101@gmx.de> Date: Wed, 24 Nov 2004 09:04:01 +0100 From: "Prakash K. Cheemplavam" User-Agent: Mozilla Thunderbird 0.9 (X11/20041114) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Nathan Scott CC: William Lee Irwin III , Jan De Luyck , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [2.6.10-rc2] XFS filesystem corruption References: <200411221530.30325.lkml@kcore.org> <20041122155106.GG2714@holomorphy.com> <41A30D3E.9090506@gmx.de> <20041124082736.E6205230@wobbly.melbourne.sgi.com> In-Reply-To: <20041124082736.E6205230@wobbly.melbourne.sgi.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7FC9CFB6AB2257070C9636CC" X-archive-position: 4519 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: prakashkc@gmx.de Precedence: bulk X-list: linux-xfs Content-Length: 1853 Lines: 48 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7FC9CFB6AB2257070C9636CC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nathan Scott schrieb: > On Tue, Nov 23, 2004 at 11:13:18AM +0100, Prakash K. Cheemplavam wrote: >>using ck's preemp big kernel lock?) I got following using a raid0 setup >>with xfs. I thought it would be a driver issue, but reformatting to ext3 >>the stripe array runs now w/o probs for a few days. (xfs crapped out >>after a few hours on heavy disk activity.) >>... >>Nov 21 10:10:45 tachyon end_request: I/O error, dev sdb, sector 10480855 >>Nov 21 10:10:45 tachyon I/O error in filesystem ("md0") meta-data dev >>md0 block 0x13fd990 ("xfs_trans_read_buf") error 5 buf count 8192 > > > This looks like your driver passed an error back up to the > filesystem while it was doing metadata IO and XFS chose to > shut it down to prevent further damage. It's unlikely to > be a preempt/xfs problem. Possibly hardware. Did you see > any of those device errors since switching to ext3? No. That's why I am wondering. I read about such errors like I got before in lkml and usually they were not fs related but libata siimage driver related. It could be just a coincidence that it came up with xfs, but till now (I guess 5 days now, though not 24/7 running) ext3 is behaving nicely. bye, Prakash --------------enig7FC9CFB6AB2257070C9636CC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBpEB2xU2n/+9+t5gRAi1gAKCZLobZpb3aMGDJYpUOfHMNvqm6uACgtOIq +Zu7qGCu65ya/DFiwMFrdbo= =kpOx -----END PGP SIGNATURE----- --------------enig7FC9CFB6AB2257070C9636CC-- From owner-linux-xfs Wed Nov 24 02:59:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Nov 2004 02:59:45 -0800 (PST) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [193.151.36.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAOAxhmE001565 for ; Wed, 24 Nov 2004 02:59:43 -0800 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 6466D18D38F; Wed, 24 Nov 2004 09:49:56 +0100 (CET) Received: from localhost.localdomain (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id 92F6818D370; Wed, 24 Nov 2004 09:49:50 +0100 (CET) Received: from [127.0.0.1] (venus [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id iAO8nl6P002551; Wed, 24 Nov 2004 09:49:47 +0100 Subject: Re: Is xfsdump operation atomic? From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Ivan Rayner Cc: linux-xfs@oss.sgi.com In-Reply-To: <20041124100827.227abd72.ivanr@sgi.com> References: <81DB11CE-3D40-11D9-B9BB-000A95BCCB96@iam.unibe.ch> <20041124100827.227abd72.ivanr@sgi.com> Content-Type: text/plain Message-Id: <1101286187.2482.7.camel@venus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 24 Nov 2004 09:49:47 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 4520 X-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: 984 Lines: 25 On Wed, 2004-11-24 at 00:08, Ivan Rayner wrote: > I'm sure the man page states that it should be run on a mounted > filesystem. > > You seem to be of the opinion that you can't create a backup of a live > filesystem. My guess is that you assume a backup is a strict snapshot in > time of the filesystem -- it isn't. > > If a file is removed or created while a xfsdump is running, then it may or > may not be included in the dump. This is OK, because in tomorrow night's > incremental backup the file will then be included or removed as > appropriate. If you have a 24hr schedule then you should assume that the It is not always OK. If the files are independent then it is OK. If they are not you have big troubles. Eg. if you have an IMAP server and you have: 1 File containing messages index 2-9999999 files containing messages You dump the index, next the user deletes some messages, next you dump the messages... After restoring the backup you have problem. Regards, Olaf From owner-linux-xfs Wed Nov 24 04:51:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Nov 2004 04:51:53 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAOCppJi011968 for ; Wed, 24 Nov 2004 04:51:51 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAOEAAfQ001439 for ; Wed, 24 Nov 2004 06:10:10 -0800 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAOCoUad3273816; Wed, 24 Nov 2004 04:50:30 -0800 (PST) Message-ID: <41A48395.60100@sgi.com> Date: Wed, 24 Nov 2004 06:50:29 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Prakash K. Cheemplavam" CC: Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [2.6.10-rc2] XFS filesystem corruption References: <200411221530.30325.lkml@kcore.org> <20041122155106.GG2714@holomorphy.com> <41A30D3E.9090506@gmx.de> <20041124082736.E6205230@wobbly.melbourne.sgi.com> <41A44071.9040101@gmx.de> In-Reply-To: <41A44071.9040101@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4522 X-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: 694 Lines: 20 Prakash K. Cheemplavam wrote: > Nathan Scott schrieb: > >> Did you see >> any of those device errors since switching to ext3? > > > No. That's why I am wondering. I read about such errors like I got > before in lkml and usually they were not fs related but libata siimage > driver related. It could be just a coincidence that it came up with xfs, > but till now (I guess 5 days now, though not 24/7 running) ext3 is > behaving nicely. It's almost certainly not a filesystem problem, but an IO layer problem. Maybe you only see it with xfs due to different disk IO patterns with xfs vs. ext3... the two will certainly be allocating & writing to the disk in different ways. -Eric From owner-linux-xfs Wed Nov 24 09:12:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Nov 2004 09:12:43 -0800 (PST) Received: from mail.cohaesio.net (penguin.cohaesio.net [212.97.129.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAOHCd8c024777 for ; Wed, 24 Nov 2004 09:12:39 -0800 Received: from cohsrv1.cohaesio.com (cohsrv1.cohaesio.com [212.97.128.131]) by mail.cohaesio.net (Postfix) with ESMTP id 70570FB476; Wed, 24 Nov 2004 18:12:18 +0100 (CET) Received: from homer.cohaesio.com ([212.97.128.136]) by cohsrv1.cohaesio.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Nov 2004 18:12:18 +0100 From: Anders Saaby Organization: Cohaesio A/S To: linux-kernel@vger.kernel.org Subject: 2.6.9 Oops: Major problems with XFS and ext3 (VFS related?) Date: Wed, 24 Nov 2004 18:12:33 +0100 User-Agent: KMail/1.7.1 Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200411241812.33529.as@cohaesio.com> X-OriginalArrivalTime: 24 Nov 2004 17:12:18.0365 (UTC) FILETIME=[C09476D0:01C4D248] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id iAOHCe8c024779 X-archive-position: 4525 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs Content-Length: 3048 Lines: 81 Hi Lists, (XFS list CC'ed) We are encountering what looks like a race on both ext3 and XFS on a high-load mailserver. Here is the cituation: We have a high-load mailserver serving IMAP from Maildirs. We originally had the maildirs on ext3 but the kernel eventually Oopsed every ~20 hours (Oops - included) - we then moved the Maildirs to XFS thinking the problems where history, but now we get a somewhat similar error from XFS (inluded). They both look like a race to me but I am not able to get more out of it. System: IBM Dual Xeon P4 - IBM ips raidcontroller (raid 0+1) ~150G. Kernel: Linux 2.6.9 SMP So buttomline both ext3 and XFS causes crashes. Comments anyone? ...We are desperate. Here is what XFS says: Filesystem "sdb1": xfs_trans_delete_ail: attempting to delete a log item that is not in the AIL xfs_force_shutdown(sdb1,0x8) called from line 382 of file fs/xfs/xfs_trans_ail.c. Return address = 0xc0216a56 @Linux version 2.6.9 (root@mail1.domain.tld) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)) #1 SMP Tue Oct 19 16:04:55 CEST 2004 Here is what ext3 says: Unable to handle kernel NULL pointer dereference at virtual address 0000000c printing eip: c018b2f5 *pde = 00000000 Oops: 0002 [#1] SMP Modules linked in: nfs e1000 iptable_nat rtc CPU:    2 EIP:    0060:[]    Not tainted VLI EFLAGS: 00010286   (2.6.9) EIP is at journal_commit_transaction+0x545/0x11b0 eax: d971826c   ebx: 00000000   ecx: e489eefc   edx: 00000014 esi: d971826c   edi: f7406000   ebp: ea0a6f80   esp: f7407d8c ds: 007b   es: 007b   ss: 0068 Process kjournald (pid: 177, threadinfo=f7406000 task=f7df63b0) Stack: 03afe6b2 c2157478 f7407e40 f7406000 c2157414 00000000 00000000 00000000        00000000 00000000 e489ebfc cd61056c 000010e8 01c2bf60 c040e020 00000000        f7406000 0000001e f7407e1c c0412f80 00000008 f7407e5c c01134e3 f7407e1c Call Trace:  [] find_busiest_group+0xf3/0x300  [] find_busiest_queue+0xa9/0xd0  [] autoremove_wake_function+0x0/0x40  [] autoremove_wake_function+0x0/0x40  [] kjournald+0xc1/0x230  [] autoremove_wake_function+0x0/0x40  [] finish_task_switch+0x33/0x70  [] autoremove_wake_function+0x0/0x40  [] ret_from_fork+0x6/0x14  [] commit_timeout+0x0/0x10  [] kjournald+0x0/0x230  [] kernel_thread_helper+0x5/0x18 Code: 00 89 f0 e8 5e e1 17 00 83 c4 14 8b 45 18 85 c0 0f 84 49 01 00 00 bf 00 e0 ff ff 21 e7 89 f6 8d bc 27 00 00 00 00 8b 70 20 8b 1e ff 43 0c 8b 03 83 e0 04 74 4e 8b 94 24  e8 01 00 00 8d 82 c0 I will be happy to supply any info and do some testing - if anyone catches interest! :-) -- Med venlig hilsen - Best regards - Meilleures salutations Anders Saaby Systems Engineer ------------------------------------------------ Cohaesio A/S - Maglebjergvej 5D - DK-2800 Lyngby Phone: +45 45 880 888 - Fax: +45 45 880 777 Mail: as@cohaesio.com - http://www.cohaesio.com ------------------------------------------------ From owner-linux-xfs Wed Nov 24 10:46:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Nov 2004 10:46:41 -0800 (PST) Received: from mx2.tippett.com (mx2.tippett.com [64.81.248.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAOIkcV3028191 for ; Wed, 24 Nov 2004 10:46:39 -0800 Received: from relay3.tippett.com (relay3.tippett.com [192.168.3.179]) by mx2.tippett.com (8.12.8/8.12.8) with ESMTP id iAOIgNn7025329; Wed, 24 Nov 2004 10:42:23 -0800 Received: from tippett.com (gangsta.tippett.com [192.168.3.62]) by relay3.tippett.com (8.12.8/8.12.8) with ESMTP id iAOIjtUw007087; Wed, 24 Nov 2004 10:45:56 -0800 Message-ID: <41A4D658.5050609@tippett.com> Date: Wed, 24 Nov 2004 10:43:36 -0800 From: Christian Rice Reply-To: xian@tippett.com Organization: Tippett Studio User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Locher CC: linux-xfs@oss.sgi.com Subject: Re: Is xfsdump operation atomic? References: <38A5E378-3DF4-11D9-9800-000A95BCCB96@iam.unibe.ch> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.45 X-archive-position: 4526 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xian@tippett.com Precedence: bulk X-list: linux-xfs Content-Length: 1181 Lines: 35 This is why snapshots were invented. Michael Locher wrote: > Ivan, thanks for commenting on this. > > Am 23.11.2004 um 13:12 schrieb Ivan Rayner: > >> You seem to be of the opinion that you can't create a backup of a live >> filesystem. My guess is that you assume a backup is a strict snapshot in >> time of the filesystem -- it isn't. > > > But it could be... it would be a nice feature to have, tough i am sure > it is not trivial to implement. > >> If a file is removed or created while a xfsdump is running, then it >> may or >> may not be included in the dump. This is OK, because in tomorrow night's >> incremental backup the file will then be included or removed as >> appropriate. If you have a 24hr schedule then you should assume that the >> cycle starts when xfsdump starts. Anything that happens while xfsdump is >> running will be guaranteed to be on the following dump, but if you're >> lucky then it will make it in the current dump. > > > What happens if a large file (eg a multi GB database file) is modified > during the dump. > Will it be consistent? i.e are write operations allowed on a file when > its data is dumped? > > Michael > > > From owner-linux-xfs Wed Nov 24 11:19:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 24 Nov 2004 11:19:17 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [195.134.129.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAOJJC5g029783 for ; Wed, 24 Nov 2004 11:19:13 -0800 Received: (qmail 47052 invoked from network); 24 Nov 2004 19:18:52 -0000 Received: from unknown (HELO stinky.trash.net) ([195.134.144.50]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 24 Nov 2004 19:18:52 -0000 Received: from coxa.bones (stinky.trash.net [3ffe:202c:ffff:10::1]) by stinky.trash.net (Postfix) with ESMTP id 68BA0948F2; Wed, 24 Nov 2004 20:18:51 +0100 (MET) Subject: Re: Is xfsdump operation atomic? From: Michael Locher To: xian@tippett.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <41A4D658.5050609@tippett.com> References: <38A5E378-3DF4-11D9-9800-000A95BCCB96@iam.unibe.ch> <41A4D658.5050609@tippett.com> Content-Type: text/plain Date: Wed, 24 Nov 2004 20:18:51 +0100 Message-Id: <1101323932.8509.17.camel@coxa.bones> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-archive-position: 4527 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: locher@iam.unibe.ch Precedence: bulk X-list: linux-xfs Content-Length: 896 Lines: 25 On Wed, 2004-11-24 at 10:43 -0800, Christian Rice wrote: > This is why snapshots were invented. Christian, I am well aware that this problem can be solved properly with snapshots. My point is, that the exact behavior of xfsdump is "underdocumented". I surprised a few colleagues when I told them that xfsdump was not atomic... the following information should IMHO be included into the man pages and/or the FAQ: * What happens to files created/deleted (ie. directory modifications) during a dump. (-> thanks to Ivan this has been resolved) * What happens to existing files if they are modified (or their metadata eg. atime) is updated *exactly* when xfsdump is working on that file? (-> this is not yet cleared up. Maybe xfsdump could lock the file during dump?) I would appreciate it a lot if a developer could clarify this. Another question: Can a frozen filesystem be dumped? Michael From owner-linux-xfs Thu Nov 25 00:29:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Nov 2004 00:29:21 -0800 (PST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAP8TA88029760 for ; Thu, 25 Nov 2004 00:29:12 -0800 Received: (qmail 12174 invoked by uid 65534); 25 Nov 2004 07:28:43 -0000 Received: from p508DC7C4.dip0.t-ipconnect.de (EHLO [192.168.0.1]) (80.141.199.196) by mail.gmx.net (mp005) with SMTP; 25 Nov 2004 08:28:43 +0100 X-Authenticated: #4512188 Message-ID: <41A589A6.6020406@gmx.de> Date: Thu, 25 Nov 2004 08:28:38 +0100 From: "Prakash K. Cheemplavam" User-Agent: Mozilla Thunderbird 0.9 (X11/20041114) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [2.6.10-rc2] XFS filesystem corruption References: <200411221530.30325.lkml@kcore.org> <20041122155106.GG2714@holomorphy.com> <41A30D3E.9090506@gmx.de> <20041124082736.E6205230@wobbly.melbourne.sgi.com> <41A44071.9040101@gmx.de> <41A48395.60100@sgi.com> In-Reply-To: <41A48395.60100@sgi.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC0352BB9DF78E0E8E6555B72" X-archive-position: 4528 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: prakashkc@gmx.de Precedence: bulk X-list: linux-xfs Content-Length: 1518 Lines: 49 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC0352BB9DF78E0E8E6555B72 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Sandeen schrieb: > Prakash K. Cheemplavam wrote: > >> Nathan Scott schrieb: >> >>> Did you see >>> any of those device errors since switching to ext3? >> >> >> >> No. That's why I am wondering. I read about such errors like I got >> before in lkml and usually they were not fs related but libata siimage >> driver related. It could be just a coincidence that it came up with >> xfs, but till now (I guess 5 days now, though not 24/7 running) ext3 >> is behaving nicely. > > > It's almost certainly not a filesystem problem, but an IO layer problem. > Maybe you only see it with xfs due to different disk IO patterns with > xfs vs. ext3... the two will certainly be allocating & writing to the > disk in different ways. Hmm, OK. When I have some hd space again. I might try to reproduce this error. Whom should I bug then if it reappears? Cheers, Prakash --------------enigC0352BB9DF78E0E8E6555B72 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBpYmqxU2n/+9+t5gRAgODAKC3zjwhU5k4rEv97iPfTUh+EtVYlwCgv6n1 K82DDtufau9KK4KXDBYkN5s= =cBUq -----END PGP SIGNATURE----- --------------enigC0352BB9DF78E0E8E6555B72-- From owner-linux-xfs Thu Nov 25 04:35:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Nov 2004 04:35:37 -0800 (PST) Received: from smtp.cistron-office.nl (mail@10fwd.cistron-office.nl [62.216.29.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAPCZXiN011930 for ; Thu, 25 Nov 2004 04:35:34 -0800 Received: from traveler.cistron-office.nl ([62.216.29.67] helo=traveler) by smtp.cistron-office.nl with esmtp (Exim 3.35 #1 (Debian)) id 1CXIq5-0005l9-00; Thu, 25 Nov 2004 13:35:09 +0100 Date: Thu, 25 Nov 2004 12:35:06 +0000 From: Miquel van Smoorenburg Subject: Re: [REPOST] [PATCH] fs/xfs/linux-2.6/kmem.c To: Nathan Scott Cc: Miquel van Smoorenburg , linux-xfs@oss.sgi.com References: <20041115103130.GA7971@cistron.nl> <20041117232247.GA9834@frodo> In-Reply-To: <20041117232247.GA9834@frodo> (from nathans@sgi.com on Thu Nov 18 00:22:47 2004) X-Mailer: Balsa 2.2.4 Message-Id: <1101386106l.15668l.0l@traveler> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-Bt0VjDla2nBKLwk/ntlz" X-archive-position: 4531 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: miquels@cistron.net Precedence: bulk X-list: linux-xfs Content-Length: 5753 Lines: 173 --=-Bt0VjDla2nBKLwk/ntlz Content-Type: text/plain; charset=ISO-8859-1; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004.11.18 00:22, Nathan Scott wrote: > On Mon, Nov 15, 2004 at 11:31:32AM +0100, Miquel van Smoorenburg wrote: > > I've sent this to the list a month ago, but I think it was overlooked. >=20 > Sorry about that. >=20 > > I think this (actually, the second patch) should go as a bugfix > > into 2.6.10 .. So I'm reposting it, if I'm completely wrong about > > this tell me and I'll shut up. Thanks! >=20 > Yep, I agree we can certainly improve things, and your patches are > a move in the right direction. A couple of things: > - I'd prefer to keep the loop, we've been bitten before by "nofail" > allocations, uhm, failing, and ultimately causing corruption. > - should also consider printk_ratelimit, but not clear if that'd be > better "in addition to" or "in place of" the approaches you've taken > so far here. > - it'd be better to keep the manipulation of "retries", esp. the > modulo part till after the first allocation attempt, since the usual > case is for the allocation to succeed, so the fewer instructions we > add in beforehand the better. > - theres a similar spot in xfs_buf.c where we need to retry page > cache allocations when initial attempts don't work out - maybe the > block_congestion check would be useful there too? Not clear to me > yet though, we may get ourselves in a bind adding that there, but > probably not. OK, did that. This time I kept as much of the code intact as possible. Things I changed: - in linux-2.6/kmem.c: o add __GFP_NOWARN to gfp flags so that kmalloc/vmalloc don't spew warnings when we're in a loop o added call to blk_congestion_wait() at the end of the loop o made error printk a bit clearer - in linux-2.6/xfs_buf.c o add __GFP_NOWARN to gfp flags so that alloc_pages() doesn't spew warnings when we're in a loop o added call to blk_congestion_wait() at the end of the loop o made error printk a bit clearer o since there was already a 10 ms delay in there, if blk_congestion_wait() waited for less than 10 ms make sure we wait for the remaining amount of time (which is 20 ms now). I'm not sure if we actually need the sleep-at-least-10-ms code, but I'm not sure what it does and at least this way, actual behaviour isn't changed much. Patch has been tested on a busy usenet newsserver. Mike. --=-Bt0VjDla2nBKLwk/ntlz Content-Type: text/x-patch; charset=us-ascii; name=xfs-shutup-kmem.patch3 Content-Disposition: attachment; filename=xfs-shutup-kmem.patch3 Content-Transfer-Encoding: quoted-printable diff -ruN linux-2.6.9/fs/xfs/linux-2.6/kmem.c linux-2.6.9-xfs/fs/xfs/linux-= 2.6/kmem.c --- linux-2.6.9/fs/xfs/linux-2.6/kmem.c 2004-10-18 23:54:31.000000000 +0200 +++ linux-2.6.9-xfs/fs/xfs/linux-2.6/kmem.c 2004-11-25 13:24:47.000000000 += 0100 @@ -35,6 +35,7 @@ #include #include #include +#include =20 #include "time.h" #include "kmem.h" @@ -46,7 +47,8 @@ void * kmem_alloc(size_t size, int flags) { - int retries =3D 0, lflags =3D kmem_flags_convert(flags); + int retries =3D 0; + int lflags =3D kmem_flags_convert(flags) | __GFP_NOWARN; void *ptr; =20 do { @@ -57,8 +59,10 @@ if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; if (!(++retries % 100)) - printk(KERN_ERR "possible deadlock in %s (mode:0x%x)\n", + printk(KERN_ERR "xfs: possible memory allocation " + "deadlock in %s (mode:0x%x)\n", __FUNCTION__, lflags); + blk_congestion_wait(WRITE, HZ/50); } while (1); } =20 @@ -102,7 +106,8 @@ void * kmem_zone_alloc(kmem_zone_t *zone, int flags) { - int retries =3D 0, lflags =3D kmem_flags_convert(flags); + int retries =3D 0; + int lflags =3D kmem_flags_convert(flags) | __GFP_NOWARN; void *ptr; =20 do { @@ -110,8 +115,10 @@ if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; if (!(++retries % 100)) - printk(KERN_ERR "possible deadlock in %s (mode:0x%x)\n", + printk(KERN_ERR "xfs: possible memory allocation " + "deadlock in %s (mode:0x%x)\n", __FUNCTION__, lflags); + blk_congestion_wait(WRITE, HZ/50); } while (1); } =20 diff -ruN linux-2.6.9/fs/xfs/linux-2.6/xfs_buf.c linux-2.6.9-xfs/fs/xfs/lin= ux-2.6/xfs_buf.c --- linux-2.6.9/fs/xfs/linux-2.6/xfs_buf.c 2004-10-18 23:53:07.000000000 +0= 200 +++ linux-2.6.9-xfs/fs/xfs/linux-2.6/xfs_buf.c 2004-11-25 13:24:43.00000000= 0 +0100 @@ -53,6 +53,7 @@ #include #include #include +#include =20 #include "xfs_linux.h" =20 @@ -348,11 +349,12 @@ size_t blocksize =3D bp->pb_target->pbr_bsize; size_t size =3D bp->pb_count_desired; size_t nbytes, offset; - int gfp_mask =3D pb_to_gfp(flags); + int gfp_mask =3D pb_to_gfp(flags) | __GFP_NOWARN; unsigned short page_count, i; pgoff_t first; loff_t end; int error; + long timeout; =20 end =3D bp->pb_file_offset + bp->pb_buffer_length; page_count =3D page_buf_btoc(end) - page_buf_btoct(bp->pb_file_offset); @@ -387,13 +389,17 @@ */ if (!(++retries % 100)) printk(KERN_ERR - "possible deadlock in %s (mode:0x%x)\n", + "xfs: possible memory allocation " + "deadlock in %s (mode:0x%x)\n", __FUNCTION__, gfp_mask); =20 XFS_STATS_INC(pb_page_retries); pagebuf_daemon_wakeup(0, gfp_mask); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(10); + timeout =3D blk_congestion_wait(WRITE, HZ/50); + if (timeout > HZ/100) { + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(timeout); + } goto retry; } =20 --=-Bt0VjDla2nBKLwk/ntlz-- From owner-linux-xfs Thu Nov 25 08:11:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Nov 2004 08:27:39 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAPGBV6Q006614 for ; Thu, 25 Nov 2004 08:11:31 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAPGBVPZ006611 for linux-xfs@oss.sgi.com; Thu, 25 Nov 2004 08:11:31 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAPGBU62006587 for ; Thu, 25 Nov 2004 08:11:30 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAPFlgiG024729; Thu, 25 Nov 2004 07:47:42 -0800 Date: Thu, 25 Nov 2004 07:47:42 -0800 Message-Id: <200411251547.iAPFlgiG024729@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 389] New: Untarring an archive corrupts XFS file system X-Bugzilla-Reason: AssignedTo X-archive-position: 4532 X-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: 3122 Lines: 104 http://oss.sgi.com/bugzilla/show_bug.cgi?id=389 Summary: Untarring an archive corrupts XFS file system Product: Linux XFS Version: 1.3.x Platform: All OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: james-p@moving-picture.com I have a tar archive that when I extract the files, it results in a corrupt directory inode. This is repeatable on _every_ XFS file system I've tried (kernels 2.4.20, 2.4.22 with XFS 1.3.X and what ever version comes with 2.4.26) It also happens on IRIX (6.5.19m) !! The tar archive contains one directory with about 500 files. If extract the files, then move the extracted directory to somewhere else on the file system, I get an xfs_shutdown. When I do an xfs_repair I get: Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 bad directory leaf magic # 0x9a62 for directory inode 801 block 8388609 - agno = 1 - agno = 2 ... Phase 6 - check inode connectivity... - traversing filesystem starting at / ... unknown magic number 0x9a62 for block 8388609 in directory inode 801 - traversal finished ... ... I think it has something to do with the order and 'nature' (name, size, whatever) of the files being added to the directory - as shown by the following tests: untar all but the last file in the archive umount xfs_repair - no problem mount untar just the last file in the archive umount xfs_repair - unknown magic number 0x9a62 ... However, if I do: untar just the last file in the archive umount xfs_repair - no problem mount untar all but the last file in the archive umount xfs_repair - no problem Or even: untar all but the last file in the archive umount xfs_repair - no problem mount create any new file in problem directory umount xfs_repair - no problem untar just the last file in the archive umount xfs_repair - no problem This tar archive was made from a repaired corrupted directory on another XFS file system - the corruption was exactly the same. I thought it strange that the tar archive 'kept' the corruption - very strange as a tar archive doesn't contain anything XFS specific ... but it's not the tar archive, it's the file creation nature and order that triggers the bug. I believe tar creates archives with files in the 'directory' order i.e. the same order that the files were created. Unfortunately, the tar archive is 1.1Gb, so it is a bit difficult to make it available - it also contains production data, so I don't want to make it widely available - however I will make it available to the XFS developers (how??) James Pearson ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Nov 25 12:15:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Nov 2004 12:31:55 -0800 (PST) Received: from smtp.cistron-office.nl (mail@10fwd.cistron-office.nl [62.216.29.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAPKFnSU026505 for ; Thu, 25 Nov 2004 12:15:50 -0800 Received: from a80-126-193-215.adsl.xs4all.nl ([80.126.193.215] helo=stargazer.cistron.net) by smtp.cistron-office.nl with asmtp (Exim 3.35 #1 (Debian)) id 1CXQ1Y-0008AH-00 for ; Thu, 25 Nov 2004 21:15:28 +0100 Date: Thu, 25 Nov 2004 20:15:26 +0000 From: Miquel van Smoorenburg Subject: xfs corruption with XFS_IOC_RESVSP To: linux-xfs@oss.sgi.com X-Mailer: Balsa 2.2.3 Message-Id: <1101413726l.13697l.0l@stargazer.cistron.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id iAPKFoSU026521 X-archive-position: 4534 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: miquels@cistron.net Precedence: bulk X-list: linux-xfs Content-Length: 2528 Lines: 68 Let me start off by saying that this isn't easily reproducable - I haven't been able to reproduce it at will just yet. Anyway. I have an application that appends slowly and randomly to tens of thousands of database file, which are later read sequentially. Because the files are opened, written to (a few hundred bytes) and closed, all randomly, fragmentation is enormous. I've been using ioctl(filefd, XFS_IOC_RESVSP, (xfs_flock64_t *)&req) to preallocate space for these files in 256Kbyte chunks. As soon as a write to a file would cross a 256K chunk boundary, another 256K is allocated. Ofcourse this is also done at offset 0. So we have: preallocate 256K (0 .. 256K-1) write 700 bytes (file size 700) write 800 bytes (file size 1500) ... write 900 bytes (file size 256K - 300) preallocate 256K (256K .. 512K-1) write 800 bytes (file size 256K + 500) ... This actually works as expected and has been running on several machines for quite some time with a 2.6.9 Linux kernel. Now I installed this on a Dual Xeon with 4GB memory that has a really high load (hundreds of simultaneous database connections, 6-disk RAID5 for 100% loaded all of the time). Suddenly, after a week or so of running, the database files got corrupt - NULs and random binary junk in the middle of the files. I wrote a small app to recreate the I/O patterns and sure enough, the same damage to the files: lockf(fd, LOCK); pos = lseek(fd, 0, SEEK_END); if (pos + num_bytes_to_write_would_cross_modulo_256K_boundary) prealloc(another 256K at boundary) write(buf, num_bytes_to_write, fd); lockf(fd, UNLOCK); I ran this in 4 processes on the same file and corruption would show up- usually a bunch of NULs were detected in the file. On a non-XFS partition (ext3) I didn't see any problems, but ofcourse, ext3 has no EXT3_IOC_RESVSP ioctl. After a few days of testing, the server locked up - I rebooted it, and I haven't been able to repeat the corruption. Probably because it took a week of running this code in the main database application for the problem to manifest itself in the first place, and I took the preallocation code out of the main database application ... So, I'm not able to reproduce this yet, but I decided to post this here anyway to see if anyone has an "aha" moment when reading this, and to have it in the archives in case anyone hits the same problem. (BTW - the database application I'm talking about is Diablo dreaderd, and the database is the header database in /news/spool/group/ ). Mike. From owner-linux-xfs Thu Nov 25 15:11:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Nov 2004 15:27:43 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAPNBXgQ005664 for ; Thu, 25 Nov 2004 15:11:33 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAPNBXQQ005662 for linux-xfs@oss.sgi.com; Thu, 25 Nov 2004 15:11:33 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAPNBWC9005635 for ; Thu, 25 Nov 2004 15:11:32 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAPN4bh6001661; Thu, 25 Nov 2004 15:04:37 -0800 Date: Thu, 25 Nov 2004 15:04:37 -0800 Message-Id: <200411252304.iAPN4bh6001661@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 389] Untarring an archive corrupts XFS file system X-Bugzilla-Reason: AssignedTo X-archive-position: 4535 X-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: 3515 Lines: 104 http://oss.sgi.com/bugzilla/show_bug.cgi?id=389 ------- Additional Comments From james-p@moving-picture.com 2004-25-11 08:15 PDT ------- Created an attachment (id=148) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=148&action=view) List of filename that corrupt file system Just realized that I can reproduce the problem by just touching empty files - so the following works without need for the tar archive: cd /some/tmp/xfs/file/system mkdir shd for i in `cat corrupt.list`; do touch $i; done ------- Additional Comments From nathans@sgi.com 2004-25-11 15:04 PDT ------- Hi James, Wow, a reproducible test case! I'm not having any luck reproducing it though - I'm following your second (touch) recipe but not seeing the problem yet. I also tried touching all but the last file in the list, then umount/mount, and then touch the last file (which kind of matches your earlier description I think) but that didn't cause any problem either. Could you try my recipe below and see if it fails for you? If not, is there a modified set of steps I can take to reproduce it? thanks! bruce /home/fsgqa# mkfs.xfs -f /dev/sdb7 meta-data=/dev/sdb7 isize=256 agcount=8, agsize=8031 blks = sectsz=512 data = bsize=4096 blocks=64248, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 bruce /home/fsgqa# mount /dev/sdb7 /scratch/xfs1 bruce /home/fsgqa# cd !$ cd /scratch/xfs1 bruce /scratch/xfs1# mkdir shd bruce /scratch/xfs1# sh sh-2.05b# for i in `cat /tmp/corrupt.list`; do touch $i; done sh-2.05b# exit bruce /scratch/xfs1# cd bruce /root# umount /scratch/xfs1 bruce /root# ls /scratch/xfs bruce /root# umount /scratch/xfs1 bruce /root# xfs_repair /dev/sdb7 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 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 bruce /root# ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Nov 25 15:38:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Nov 2004 15:54:07 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAPNbxZZ021811 for ; Thu, 25 Nov 2004 15:38:00 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA23982; Fri, 26 Nov 2004 10:37:31 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAPNbSln6275749; Fri, 26 Nov 2004 10:37:28 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iAPMZ779001007; Fri, 26 Nov 2004 09:35:07 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iAPMZ4Gc001005; Fri, 26 Nov 2004 09:35:04 +1100 Date: Fri, 26 Nov 2004 09:35:04 +1100 From: Nathan Scott To: Anders Saaby Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.9 Oops: Major problems with XFS and ext3 (VFS related?) Message-ID: <20041125223504.GA953@frodo> References: <200411241812.33529.as@cohaesio.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411241812.33529.as@cohaesio.com> User-Agent: Mutt/1.5.3i X-archive-position: 4536 X-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: 1480 Lines: 38 On Wed, Nov 24, 2004 at 06:12:33PM +0100, Anders Saaby wrote: > Hi Lists, (XFS list CC'ed) Hi there, > Here is the cituation: > We have a high-load mailserver serving IMAP from Maildirs. We originally had > the maildirs on ext3 but the kernel eventually Oopsed every ~20 hours (Oops - > included) - we then moved the Maildirs to XFS thinking the problems where > history, but now we get a somewhat similar error from XFS (inluded). They > both look like a race to me but I am not able to get more out of it. > ... > Here is what XFS says: > > Filesystem "sdb1": xfs_trans_delete_ail: attempting to delete a log item that > is not in the AIL > xfs_force_shutdown(sdb1,0x8) called from line 382 of file > fs/xfs/xfs_trans_ail.c. Return address = 0xc0216a56 > @Linux version 2.6.9 (root@mail1.domain.tld) (gcc version 2.96 20000731 (Red > Hat Linux 7.3 2.96-113)) #1 SMP Tue Oct 19 16:04:55 CEST 2004 > ... > I will be happy to supply any info and do some testing - if anyone catches > interest! :-) Yep, very interested. So, "serving IMAP from Maildirs" - from the filesystems perspective, can you describe that in detail for me? I would guess that means a shallow directory tree, with quite large directories (how large?) and many (how many?) small files? (how small on average?) How frequently are files added/removed? Is this easily reproducible for you? If so, can you send me enough details that I can try to reproduce it locally? thanks. -- Nathan From owner-linux-xfs Thu Nov 25 17:09:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Nov 2004 17:25:15 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAQ197hd014626 for ; Thu, 25 Nov 2004 17:09:08 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA25746; Fri, 26 Nov 2004 12:08:39 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAQ18aln6279713; Fri, 26 Nov 2004 12:08:37 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iAQ06F79001267; Fri, 26 Nov 2004 11:06:15 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iAQ06BqZ001265; Fri, 26 Nov 2004 11:06:12 +1100 Date: Fri, 26 Nov 2004 11:06:11 +1100 From: Nathan Scott To: Miquel van Smoorenburg Cc: linux-xfs@oss.sgi.com Subject: Re: xfs corruption with XFS_IOC_RESVSP Message-ID: <20041126000611.GB953@frodo> References: <1101413726l.13697l.0l@stargazer.cistron.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1101413726l.13697l.0l@stargazer.cistron.net> User-Agent: Mutt/1.5.3i X-archive-position: 4537 X-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: 3916 Lines: 99 Hi Mike, On Thu, Nov 25, 2004 at 08:15:26PM +0000, Miquel van Smoorenburg wrote: > ... > I have an application that appends slowly and randomly to tens of > thousands of database file, which are later read sequentially. Because > the files are opened, written to (a few hundred bytes) and closed, > all randomly, fragmentation is enormous. > ... > This actually works as expected and has been running on several machines > for quite some time with a 2.6.9 Linux kernel. > > Now I installed this on a Dual Xeon with 4GB memory that has a really > high load (hundreds of simultaneous database connections, 6-disk RAID5 > for 100% loaded all of the time). Suddenly, after a week or so of > running, the database files got corrupt - NULs and random binary junk > in the middle of the files. Is this also on a 2.6.9 kernel or could it be an older one? I fixed a problem like this some time ago. The reason for the NULLs on read is likely to be as follows... > I wrote a small app to recreate the I/O patterns and sure enough, the > same damage to the files: > > lockf(fd, LOCK); > pos = lseek(fd, 0, SEEK_END); > if (pos + num_bytes_to_write_would_cross_modulo_256K_boundary) > prealloc(another 256K at boundary) > write(buf, num_bytes_to_write, fd); > lockf(fd, UNLOCK); > > I ran this in 4 processes on the same file and corruption would show up- > usually a bunch of NULs were detected in the file. When we do the space reservation, we create unwritten extents. A read into those are defined to return zeroes (just like reads into a hole would), and writes cause the extent to be adjusted so that the written part is now marked as a regular extent, and any remaining unwritten parts continue to be marked as unwritten. So, in your case a reader after the write must be still seeing an extent marked as unwritten. This could be either a bug in your program :) with the read happening before the write, or an XFS problem, or a VM-behaving-badly problem. The particular issue I fixed awhile ago is codified in test 084 (xfs-cmds/xfstests/{084,src/resvtest.c) and matches yours pretty well, hence my question about kernel version. The trigger there was VM pressure to reclaim dirty pages, where those pages are backed by unwritten extents. > After a few days of testing, the server locked up - I rebooted it, Hmm, kdb is your friend. :) (for a backtrace on the lockup) But, backing up to your original problem. XFS actually does some preallocation for writes beyond EOF already (in "biosize" chunks). When the file is closed, we go down the xfs_release path, and any excess is trimmed off the end (trimmed back to a filesystem block - xfs_inactive_free_eofblocks). But, if you are writing to those files append-only, you could mark them as such (i.e. chattr +a) -- this will skip the trim-back step and reduce fragmentation for you. "biosize" is an XFS mount option. It current maxes out at the default, which is 64K. I have had a patch kicking around for ages which bumps up the allowed maximum value (see below) - a combination of this patch, biosize=18 (i.e. 256K), and use of the append-only inode attribute, should get you just what you want without any application changes (I think) and in a way that isn't susceptible to your earlier problems. cheers. -- Nathan Index: xfs-linux/xfs_mount.h =================================================================== --- xfs-linux.orig/xfs_mount.h 2004-06-16 10:35:26.000000000 +1000 +++ xfs-linux/xfs_mount.h 2004-08-13 09:40:19.637846024 +1000 @@ -426,10 +426,10 @@ #define XFS_WRITEIO_LOG_LARGE 16 /* - * Max and min values for UIO and mount-option defined I/O sizes; - * min value can't be less than a page. Currently unused. + * Max and min values for mount-option defined I/O + * preallocation sizes. */ -#define XFS_MAX_IO_LOG 16 /* 64K */ +#define XFS_MAX_IO_LOG 26 /* 64M */ #define XFS_MIN_IO_LOG PAGE_SHIFT /* From owner-linux-xfs Thu Nov 25 17:11:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Nov 2004 17:27:41 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQ1BY3h016189 for ; Thu, 25 Nov 2004 17:11:34 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAQ1BYPU016186 for linux-xfs@oss.sgi.com; Thu, 25 Nov 2004 17:11:34 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQ1BW0r016143 for ; Thu, 25 Nov 2004 17:11:32 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAQ0KBVi017978; Thu, 25 Nov 2004 16:20:11 -0800 Date: Thu, 25 Nov 2004 16:20:11 -0800 Message-Id: <200411260020.iAQ0KBVi017978@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 389] Untarring an archive corrupts XFS file system X-Bugzilla-Reason: AssignedTo X-archive-position: 4539 X-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: 908 Lines: 30 http://oss.sgi.com/bugzilla/show_bug.cgi?id=389 ------- Additional Comments From tes@sgi.com 2004-25-11 16:20 PDT ------- Sorry for missing any text when marking resolved - I'm used to a different bug tracking system. I created the files with your list of names and sure enough on 6.5.19 I got: 10:50 tes@boing 28# ./bug148 Cannot access /mnt/test/shd/bake3_read_0001.topShape3.shd.0017.tex: Filesystem is corrupted However, I then tried on top-of-tree 6.5.27 and it worked fine. It appears that his bug has been fixed. And looking at the SGI database, it is likely to be fixed by pv#901151 - corruption in xfs dir2 "node" format directories which was checked into IRIX in October 2003, 6.5.23. It was also checked into the Linux/XFS tree in October 2003 as well. --Tim ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Nov 25 17:11:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Nov 2004 17:27:40 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQ1BX7I016182 for ; Thu, 25 Nov 2004 17:11:33 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAQ1BXU4016181 for linux-xfs@oss.sgi.com; Thu, 25 Nov 2004 17:11:33 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQ1BW0n016143 for ; Thu, 25 Nov 2004 17:11:32 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAQ0BXIV009676; Thu, 25 Nov 2004 16:11:33 -0800 Date: Thu, 25 Nov 2004 16:11:33 -0800 Message-Id: <200411260011.iAQ0BXIV009676@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 389] Untarring an archive corrupts XFS file system X-Bugzilla-Reason: AssignedTo X-archive-position: 4538 X-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: 441 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=389 tes@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Nov 25 18:16:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Nov 2004 18:20:11 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAQ2GSia023247 for ; Thu, 25 Nov 2004 18:16:29 -0800 Received: from melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA26876 for ; Fri, 26 Nov 2004 13:16:02 +1100 Date: Fri, 26 Nov 2004 13:16:01 +1100 From: Ivan Rayner To: linux-xfs@oss.sgi.com Subject: Re: Is xfsdump operation atomic? Message-Id: <20041126131601.355c0172.ivanr@sgi.com> In-Reply-To: <1101323932.8509.17.camel@coxa.bones> References: <38A5E378-3DF4-11D9-9800-000A95BCCB96@iam.unibe.ch> <41A4D658.5050609@tippett.com> <1101323932.8509.17.camel@coxa.bones> Organization: SGI X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; mips-sgi-irix6.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4540 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ivanr@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1386 Lines: 30 On Wed, 24 Nov 2004 20:18:51 +0100, Michael Locher wrote: > * What happens to existing files if they are modified (or their metadata > eg. atime) is updated *exactly* when xfsdump is working on that file? > (-> this is not yet cleared up. Maybe xfsdump could lock the file during > dump?) In that case your file may be inconsistent on tape. However, because it has been updated since xfsdump started (ie. its mtime > xfsdump time) it will be included in tomorrow night's incremental dump. If when you restore you find the file in an inconsistent state, you can try restoring the file from a previous dump. I don't think you'd want xfsdump to block for an unknown amount of time on a locked file. If a file has a mandatory lock, xfsdump will skip it. There are many ways to shoot yourself in the foot in Unix. Sometimes it's up to the user/admin to aim at something else. > Another question: Can a frozen filesystem be dumped? This may have changed in recent years, however back when I had something to do with xfsdump, if you had quotas xfsdump created a quotas file in the root of the dumped filesystem that would then be included in the dump. This means that xfsdump will sometimes want to write to the filesystem. If it can't write, xfsdump will probably just issue an error and continue. I can't think of any other reason why you couldn't dump a frozen filesystem. Ivan From owner-linux-xfs Thu Nov 25 21:14:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 25 Nov 2004 21:18:22 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAQ5ESQE002838 for ; Thu, 25 Nov 2004 21:14:29 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA29855; Fri, 26 Nov 2004 16:13:59 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAQ5Duln6300042; Fri, 26 Nov 2004 16:13:58 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id iAQ4BZ79001973; Fri, 26 Nov 2004 15:11:35 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id iAQ4BWcG001971; Fri, 26 Nov 2004 15:11:32 +1100 Date: Fri, 26 Nov 2004 15:11:32 +1100 From: Nathan Scott To: Miquel van Smoorenburg Cc: linux-xfs@oss.sgi.com Subject: Re: [REPOST] [PATCH] fs/xfs/linux-2.6/kmem.c Message-ID: <20041126041132.GA1426@frodo> References: <20041115103130.GA7971@cistron.nl> <20041117232247.GA9834@frodo> <1101386106l.15668l.0l@traveler> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1101386106l.15668l.0l@traveler> User-Agent: Mutt/1.5.3i X-archive-position: 4541 X-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: 4887 Lines: 170 Hi Mike, On Thu, Nov 25, 2004 at 12:35:06PM +0000, Miquel van Smoorenburg wrote: > > OK, did that. This time I kept as much of the code intact as possible. Thanks. > Things I changed: > > - in linux-2.6/kmem.c: > o add __GFP_NOWARN to gfp flags so that kmalloc/vmalloc don't > spew warnings when we're in a loop > o added call to blk_congestion_wait() at the end of the loop > o made error printk a bit clearer Looks good. > - in linux-2.6/xfs_buf.c > o add __GFP_NOWARN to gfp flags so that alloc_pages() doesn't > spew warnings when we're in a loop > o added call to blk_congestion_wait() at the end of the loop > o made error printk a bit clearer > o since there was already a 10 ms delay in there, if > blk_congestion_wait() waited for less than 10 ms make sure > we wait for the remaining amount of time (which is 20 ms now). Looks good. > I'm not sure if we actually need the sleep-at-least-10-ms code, > but I'm not sure what it does and at least this way, actual > behaviour isn't changed much. That was there to give the daemon a bit of time to wakeup and start writeout on delwrite buffers (which will clean pages, and help with subsequent page allocation attempts) -- it looks safe to now drop that timeout piece altogether; we'll quickly initiate I/O and then be held off inside blk_congestion_wait, either right away or after the next failed find_or_create_page. > Patch has been tested on a busy usenet newsserver. I tweaked a couple of things, esp. keeping the uses of GFP flags together in kmem.h and xfs_buf.c and dropped the timeout. How does the following patch fare for you? (could you also send me a Signed-off-by: line for when the final patch is merged in?) thanks! -- Nathan Index: xfs-linux/linux-2.6/xfs_buf.c =================================================================== --- xfs-linux.orig/linux-2.6/xfs_buf.c +++ xfs-linux/linux-2.6/xfs_buf.c @@ -53,13 +53,10 @@ #include #include #include +#include #include "xfs_linux.h" -#ifndef GFP_READAHEAD -#define GFP_READAHEAD (__GFP_NOWARN|__GFP_NORETRY) -#endif - /* * File wide globals */ @@ -118,8 +115,8 @@ */ #define pb_to_gfp(flags) \ - (((flags) & PBF_READ_AHEAD) ? GFP_READAHEAD : \ - ((flags) & PBF_DONT_BLOCK) ? GFP_NOFS : GFP_KERNEL) + ((((flags) & PBF_READ_AHEAD) ? __GFP_NORETRY : \ + ((flags) & PBF_DONT_BLOCK) ? GFP_NOFS : GFP_KERNEL) | __GFP_NOWARN) #define pb_to_km(flags) \ (((flags) & PBF_DONT_BLOCK) ? KM_NOFS : KM_SLEEP) @@ -388,13 +385,13 @@ */ if (!(++retries % 100)) printk(KERN_ERR - "possible deadlock in %s (mode:0x%x)\n", + "XFS: possible memory allocation " + "deadlock in %s (mode:0x%x)\n", __FUNCTION__, gfp_mask); XFS_STATS_INC(pb_page_retries); pagebuf_daemon_wakeup(0, gfp_mask); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(10); + blk_congestion_wait(WRITE, HZ/50); goto retry; } Index: xfs-linux/linux-2.6/kmem.c =================================================================== --- xfs-linux.orig/linux-2.6/kmem.c +++ xfs-linux/linux-2.6/kmem.c @@ -35,6 +35,7 @@ #include #include #include +#include #include "time.h" #include "kmem.h" @@ -46,7 +47,8 @@ void * kmem_alloc(size_t size, int flags) { - int retries = 0, lflags = kmem_flags_convert(flags); + int retries = 0; + int lflags = kmem_flags_convert(flags); void *ptr; do { @@ -57,8 +59,10 @@ if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; if (!(++retries % 100)) - printk(KERN_ERR "possible deadlock in %s (mode:0x%x)\n", + printk(KERN_ERR "XFS: possible memory allocation " + "deadlock in %s (mode:0x%x)\n", __FUNCTION__, lflags); + blk_congestion_wait(WRITE, HZ/50); } while (1); } @@ -102,7 +106,8 @@ void * kmem_zone_alloc(kmem_zone_t *zone, int flags) { - int retries = 0, lflags = kmem_flags_convert(flags); + int retries = 0; + int lflags = kmem_flags_convert(flags); void *ptr; do { @@ -110,8 +115,10 @@ if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; if (!(++retries % 100)) - printk(KERN_ERR "possible deadlock in %s (mode:0x%x)\n", + printk(KERN_ERR "XFS: possible memory allocation " + "deadlock in %s (mode:0x%x)\n", __FUNCTION__, lflags); + blk_congestion_wait(WRITE, HZ/50); } while (1); } Index: xfs-linux/linux-2.6/kmem.h =================================================================== --- xfs-linux.orig/linux-2.6/kmem.h +++ xfs-linux/linux-2.6/kmem.h @@ -83,7 +83,7 @@ static __inline unsigned int kmem_flags_convert(int flags) { - int lflags; + int lflags = __GFP_NOWARN; /* we'll report deadlocks, if needed */ #ifdef DEBUG if (unlikely(flags & ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS|KM_MAYFAIL))) { From owner-linux-xfs Fri Nov 26 01:11:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Nov 2004 01:15:21 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQ9BaYx026206 for ; Fri, 26 Nov 2004 01:11:36 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAQ9BaGV026204 for linux-xfs@oss.sgi.com; Fri, 26 Nov 2004 01:11:36 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQ9BYMh026159 for ; Fri, 26 Nov 2004 01:11:34 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAQ8QnPX031456; Fri, 26 Nov 2004 00:26:49 -0800 Date: Fri, 26 Nov 2004 00:26:49 -0800 Message-Id: <200411260826.iAQ8QnPX031456@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 376] xfs_force_shutdown called from line 1088 of file fs/xfs/xfs_trans.c X-Bugzilla-Reason: AssignedTo X-archive-position: 4542 X-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: 660 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=376 dbatchovski@technologica.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From dbatchovski@technologica.com 2004-26-11 00:26 PDT ------- Sorry XFS Team, broken MB caused this bugreport. *** This bug has been marked as a duplicate of 350 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Nov 26 01:11:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Nov 2004 01:15:21 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQ9Baet026205 for ; Fri, 26 Nov 2004 01:11:36 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAQ9BaHk026201 for linux-xfs@oss.sgi.com; Fri, 26 Nov 2004 01:11:36 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQ9BYMd026159 for ; Fri, 26 Nov 2004 01:11:34 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAQ8Qokq031473; Fri, 26 Nov 2004 00:26:50 -0800 Date: Fri, 26 Nov 2004 00:26:50 -0800 Message-Id: <200411260826.iAQ8Qokq031473@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 350] Starting XFS recovery never complete X-Bugzilla-Reason: AssignedTo X-archive-position: 4543 X-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: 326 Lines: 14 http://oss.sgi.com/bugzilla/show_bug.cgi?id=350 ------- Additional Comments From dbatchovski@technologica.com 2004-26-11 00:26 PDT ------- *** Bug 376 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 Fri Nov 26 01:22:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Nov 2004 01:26:02 -0800 (PST) Received: from harrier.cohaesio.com (harrier.cohaesio.com [212.97.128.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQ9MM3V000535 for ; Fri, 26 Nov 2004 01:22:22 -0800 Received: by harrier.cohaesio.com (Postfix, from userid 88) id 8498C44; Fri, 26 Nov 2004 10:22:01 +0100 (CET) X-Original-To: news2mail@news.cohaesio.com Delivered-To: news2mail@news.cohaesio.com From: Anders Saaby Subject: Re: 2.6.9 Oops: Major problems with XFS and ext3 (VFS related?) Followup-To: cohaesio.lists.linux.kernel Date: Fri, 26 Nov 2004 10:22:18 +0100 Organization: Cohaesio A/S Message-ID: References: <200411241812.33529.as@cohaesio.com> <20041125223504.GA953@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: harrier.cohaesio.com 1101460920 15761 212.97.128.136 (26 Nov 2004 09:22:00 GMT) X-Complaints-To: newsmaster@news.cohaesio.com To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com X-archive-position: 4544 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs Content-Length: 2832 Lines: 75 Nathan Scott wrote: > On Wed, Nov 24, 2004 at 06:12:33PM +0100, Anders Saaby wrote: >> Hi Lists, (XFS list CC'ed) > > Hi there, > Hi Nathan, > > Yep, very interested. So, "serving IMAP from Maildirs" - from > the filesystems perspective, can you describe that in detail for > me? I would guess that means a shallow directory tree, with quite > large directories (how large?) and many (how many?) small files? > (how small on average?) How frequently are files added/removed? > OK - Here's the deal: /hsphere/local/var/vpopmail/domains is holding the Maildirs /var/qmail/queue is holding the mail queue for qmail. Filesystem Size Used Avail Use% Mounted on /dev/sda2 29G 11G 17G 39% / /dev/sda1 45M 30M 13M 70% /boot /dev/sdb1 137G 71G 66G 52% /hsphere/local/var/vpopmail/domains /dev/sda6 2.0G 40M 1.9G 2% /var/qmail/queue Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda2 3908128 170504 3737624 5% / /dev/sda1 12048 62 11986 1% /boot /dev/sdb1 143372224 2891398 140480826 3% /hsphere/local/var/vpopmail/domains /dev/sda6 2096192 1556 2094636 1% /var/qmail/queue Actually I think that it is the mailqueue mount which causes the errors. Because we originally changed the Maildir mount from ext3 to XFS. But again after ~17 hours it Oops'ed but still on kjournald (as all earlier incidents). After this I changed the mailqueue mount from ext3 to XFS, again the server failed but this time on XFS. So it seems that it is the fairly small mailqueue mount who is responsible for the errors. Here are some statistics for the mailserver: ~50-80 mails pr. minute delivered locally. ~150 mails pr. minute forwarded. ~80.000 Mailboxes (Maildirs) - So these are relatively small directories. There are usually around 30-50 qmail-queue processes running (which is the process writing to /var/qmail/queue) > Is this easily reproducible for you? If so, can you send me > enough details that I can try to reproduce it locally? Well, This is as you can imagine a production server, and it has been crashing quite consistently every 17-18 hours the last couple of weeks. I haven't tried to set up a test environment yet, but will do this very soon. - The server is now runnig a 2.4.28 kernel which now has been running for 37 hours without failure (Wohoo!). But as the 2.4 kernel lags some of 2.6's performance, the server is under a fairly high pressure now - and we have to get it back to 2.6 as soon as possible. - Do you have some ideas for a test setup? - Im not really sure I am able to reproduce the environment which the production mailserver is in. There is just too many factors to account for. > > thanks. > -- /Saaby From owner-linux-xfs Fri Nov 26 01:24:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Nov 2004 01:28:25 -0800 (PST) Received: from harrier.cohaesio.com (harrier.cohaesio.com [212.97.128.50]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQ9OkaO002015 for ; Fri, 26 Nov 2004 01:24:46 -0800 Received: by harrier.cohaesio.com (Postfix, from userid 88) id B044745; Fri, 26 Nov 2004 10:24:25 +0100 (CET) X-Original-To: news2mail@news.cohaesio.com Delivered-To: news2mail@news.cohaesio.com From: Anders Saaby Subject: Re: 2.6.9 Oops: Major problems with XFS and ext3 (VFS related?) Followup-To: cohaesio.lists.linux.kernel Date: Fri, 26 Nov 2004 10:24:42 +0100 Organization: Cohaesio A/S Message-ID: References: <200411241812.33529.as@cohaesio.com> <20041125223504.GA953@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: harrier.cohaesio.com 1101461065 15761 212.97.128.136 (26 Nov 2004 09:24:25 GMT) X-Complaints-To: newsmaster@news.cohaesio.com To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com X-archive-position: 4545 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: as@cohaesio.com Precedence: bulk X-list: linux-xfs Content-Length: 2832 Lines: 75 Nathan Scott wrote: > On Wed, Nov 24, 2004 at 06:12:33PM +0100, Anders Saaby wrote: >> Hi Lists, (XFS list CC'ed) > > Hi there, > Hi Nathan, > > Yep, very interested. So, "serving IMAP from Maildirs" - from > the filesystems perspective, can you describe that in detail for > me? I would guess that means a shallow directory tree, with quite > large directories (how large?) and many (how many?) small files? > (how small on average?) How frequently are files added/removed? > OK - Here's the deal: /hsphere/local/var/vpopmail/domains is holding the Maildirs /var/qmail/queue is holding the mail queue for qmail. Filesystem Size Used Avail Use% Mounted on /dev/sda2 29G 11G 17G 39% / /dev/sda1 45M 30M 13M 70% /boot /dev/sdb1 137G 71G 66G 52% /hsphere/local/var/vpopmail/domains /dev/sda6 2.0G 40M 1.9G 2% /var/qmail/queue Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda2 3908128 170504 3737624 5% / /dev/sda1 12048 62 11986 1% /boot /dev/sdb1 143372224 2891398 140480826 3% /hsphere/local/var/vpopmail/domains /dev/sda6 2096192 1556 2094636 1% /var/qmail/queue Actually I think that it is the mailqueue mount which causes the errors. Because we originally changed the Maildir mount from ext3 to XFS. But again after ~17 hours it Oops'ed but still on kjournald (as all earlier incidents). After this I changed the mailqueue mount from ext3 to XFS, again the server failed but this time on XFS. So it seems that it is the fairly small mailqueue mount who is responsible for the errors. Here are some statistics for the mailserver: ~50-80 mails pr. minute delivered locally. ~150 mails pr. minute forwarded. ~80.000 Mailboxes (Maildirs) - So these are relatively small directories. There are usually around 30-50 qmail-queue processes running (which is the process writing to /var/qmail/queue) > Is this easily reproducible for you? If so, can you send me > enough details that I can try to reproduce it locally? Well, This is as you can imagine a production server, and it has been crashing quite consistently every 17-18 hours the last couple of weeks. I haven't tried to set up a test environment yet, but will do this very soon. - The server is now runnig a 2.4.28 kernel which now has been running for 37 hours without failure (Wohoo!). But as the 2.4 kernel lags some of 2.6's performance, the server is under a fairly high pressure now - and we have to get it back to 2.6 as soon as possible. - Do you have some ideas for a test setup? - Im not really sure I am able to reproduce the environment which the production mailserver is in. There is just too many factors to account for. > > thanks. > -- /Saaby From owner-linux-xfs Fri Nov 26 05:58:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Nov 2004 06:02:20 -0800 (PST) Received: from smtp.cistron-office.nl (mail@10fwd.cistron-office.nl [62.216.29.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQDwbMH019291 for ; Fri, 26 Nov 2004 05:58:38 -0800 Received: from traveler.cistron-office.nl ([62.216.29.67] helo=traveler) by smtp.cistron-office.nl with esmtp (Exim 3.35 #1 (Debian)) id 1CXgc1-0002py-00; Fri, 26 Nov 2004 14:58:13 +0100 Date: Fri, 26 Nov 2004 13:58:10 +0000 From: Miquel van Smoorenburg Subject: Re: xfs corruption with XFS_IOC_RESVSP To: Nathan Scott Cc: Miquel van Smoorenburg , linux-xfs@oss.sgi.com References: <1101413726l.13697l.0l@stargazer.cistron.net> <20041126000611.GB953@frodo> In-Reply-To: <20041126000611.GB953@frodo> (from nathans@sgi.com on Fri Nov 26 01:06:11 2004) X-Mailer: Balsa 2.2.4 Message-Id: <1101477490l.15668l.2l@traveler> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-YSfENVvUqwVY6rUPWKOh" X-archive-position: 4548 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: miquels@cistron.net Precedence: bulk X-list: linux-xfs Content-Length: 6821 Lines: 177 --=-YSfENVvUqwVY6rUPWKOh Content-Type: text/plain; charset=ISO-8859-1; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004.11.26 01:06, Nathan Scott wrote: > Hi Mike, >=20 > On Thu, Nov 25, 2004 at 08:15:26PM +0000, Miquel van Smoorenburg wrote: > > > Now I installed this on a Dual Xeon with 4GB memory that has a really > > high load (hundreds of simultaneous database connections, 6-disk RAID5 > > for 100% loaded all of the time). Suddenly, after a week or so of > > running, the database files got corrupt - NULs and random binary junk > > in the middle of the files. >=20 > Is this also on a 2.6.9 kernel or could it be an older one? It's a 2.6.9 kernel, the only patch it has is the xfs-shutup-kmem one. > I fixed a problem like this some time ago. The reason for the > NULLs on read is likely to be as follows... > > When we do the space reservation, we create unwritten extents. > A read into those are defined to return zeroes (just like reads > into a hole would), and writes cause the extent to be adjusted so > that the written part is now marked as a regular extent, and any > remaining unwritten parts continue to be marked as unwritten. >=20 > So, in your case a reader after the write must be still seeing an > extent marked as unwritten. This could be either a bug in your > program :) with the read happening before the write Well actually, I let the 4 processes write the file in parallel, each adding 500-1200 bytes at the end, until the file has grown to 10 M after which I stop the write process and read the file to check for inconsistencies.=20 > The particular issue I fixed awhile ago is codified in test 084 > (xfs-cmds/xfstests/{084,src/resvtest.c) and matches yours pretty > well, hence my question about kernel version. The trigger there > was VM pressure to reclaim dirty pages, where those pages are > backed by unwritten extents. I ran that (with -l $((512*1024*1024)) on a 512M RAM machine) a few times, but I still can't reproduce the problem .. alas. > But, backing up to your original problem. XFS actually does > some preallocation for writes beyond EOF already (in "biosize" > chunks). When the file is closed, we go down the xfs_release > path, and any excess is trimmed off the end (trimmed back to a > filesystem block - xfs_inactive_free_eofblocks). But, if you > are writing to those files append-only, you could mark them as > such (i.e. chattr +a) -- this will skip the trim-back step and > reduce fragmentation for you. Yes, but only root can do that - also, chattr +a has al kinds of other side effect I don't want. Couldn't this be made a mount option, or an ioctl ? I understand that ext3 also has preallocation support nowadays, perhaps a unified mount option or ioctl would be a good idea. Attached is a first cut at a patch for a mount option - I understand that functional changes like this might not be added (right away, at least) to stable filesystems like XFS, and perhaps it's the wrong approach but it might be useful to other people. Right now I have my filesystem mounted with -o rw,noatime,biosize=3D18,pkeep and it appears to do what I want without application changes. Thanks, Mike. --=-YSfENVvUqwVY6rUPWKOh Content-Type: text/x-patch; charset=us-ascii; name=linux-2.6.9-xfs-pkeep.patch Content-Disposition: attachment; filename=linux-2.6.9-xfs-pkeep.patch Content-Transfer-Encoding: quoted-printable diff -ruN linux-2.6.9/fs/xfs/xfs_clnt.h linux-2.6.9-pkeep/fs/xfs/xfs_clnt.h --- linux-2.6.9/fs/xfs/xfs_clnt.h 2004-10-18 23:54:38.000000000 +0200 +++ linux-2.6.9-pkeep/fs/xfs/xfs_clnt.h 2004-11-26 14:07:52.000000000 +0100 @@ -102,5 +102,7 @@ #define XFSMNT_IDELETE 0x08000000 /* inode cluster delete */ #define XFSMNT_SWALLOC 0x10000000 /* turn on stripe width * allocation */ +#define XFSMNT_PKEEP 0x20000000 /* keep preallocated blocks + after close() */ =20 #endif /* __XFS_CLNT_H__ */ diff -ruN linux-2.6.9/fs/xfs/xfs_mount.h linux-2.6.9-pkeep/fs/xfs/xfs_mount= .h --- linux-2.6.9/fs/xfs/xfs_mount.h 2004-10-18 23:53:05.000000000 +0200 +++ linux-2.6.9-pkeep/fs/xfs/xfs_mount.h 2004-11-26 14:13:47.000000000 +0100 @@ -418,6 +418,8 @@ #define XFS_MOUNT_IDELETE 0x00040000 /* delete empty inode clusters*/ #define XFS_MOUNT_SWALLOC 0x00080000 /* turn on stripe width * allocation */ +#define XFS_MOUNT_PKEEP 0x00080000 /* keep preallocated blocks + * after close() */ =20 /* * Default minimum read and write sizes. @@ -429,7 +431,7 @@ * Max and min values for UIO and mount-option defined I/O sizes; * min value can't be less than a page. Currently unused. */ -#define XFS_MAX_IO_LOG 16 /* 64K */ +#define XFS_MAX_IO_LOG 26 /* 64M */ #define XFS_MIN_IO_LOG PAGE_SHIFT =20 /* diff -ruN linux-2.6.9/fs/xfs/xfs_vfsops.c linux-2.6.9-pkeep/fs/xfs/xfs_vfso= ps.c --- linux-2.6.9/fs/xfs/xfs_vfsops.c 2004-10-18 23:53:43.000000000 +0200 +++ linux-2.6.9-pkeep/fs/xfs/xfs_vfsops.c 2004-11-26 14:10:13.000000000 +01= 00 @@ -320,6 +320,8 @@ mp->m_flags |=3D XFS_MOUNT_NOUUID; if (ap->flags & XFSMNT_NOLOGFLUSH) mp->m_flags |=3D XFS_MOUNT_NOLOGFLUSH; + if (ap->flags & XFSMNT_PKEEP) + mp->m_flags |=3D XFS_MOUNT_PKEEP; =20 return 0; } @@ -1652,6 +1654,7 @@ #define MNTOPT_64BITINODE "inode64" /* inodes can be allocated anywhere = */ #define MNTOPT_IKEEP "ikeep" /* do not free empty inode clusters */ #define MNTOPT_NOIKEEP "noikeep" /* free empty inode clusters */ +#define MNTOPT_PKEEP "pkeep" /* do not free preallocs on close */ =20 =20 int @@ -1776,6 +1779,8 @@ args->flags |=3D XFSMNT_NOUUID; } else if (!strcmp(this_char, MNTOPT_NOLOGFLUSH)) { args->flags |=3D XFSMNT_NOLOGFLUSH; + } else if (!strcmp(this_char, MNTOPT_PKEEP)) { + args->flags |=3D XFSMNT_PKEEP; } else if (!strcmp(this_char, MNTOPT_IKEEP)) { args->flags &=3D ~XFSMNT_IDELETE; } else if (!strcmp(this_char, MNTOPT_NOIKEEP)) { @@ -1851,6 +1856,7 @@ { XFS_MOUNT_OSYNCISOSYNC, "," MNTOPT_OSYNCISOSYNC }, { XFS_MOUNT_NOLOGFLUSH, "," MNTOPT_NOLOGFLUSH }, { XFS_MOUNT_IDELETE, "," MNTOPT_NOIKEEP }, + { XFS_MOUNT_PKEEP, "," MNTOPT_PKEEP }, { 0, NULL } }; struct proc_xfs_info *xfs_infop; diff -ruN linux-2.6.9/fs/xfs/xfs_vnodeops.c linux-2.6.9-pkeep/fs/xfs/xfs_vn= odeops.c --- linux-2.6.9/fs/xfs/xfs_vnodeops.c 2004-10-18 23:55:36.000000000 +0200 +++ linux-2.6.9-pkeep/fs/xfs/xfs_vnodeops.c 2004-11-26 14:12:53.000000000 += 0100 @@ -1214,6 +1214,13 @@ xfs_bmbt_irec_t imap; =20 /* + * If mounted with the "pkeep" option, do not remove any + * preallocated blocks at the end of the file at close(). + */ + if (mp->m_flags & XFS_MOUNT_PKEEP) + return (0); + + /* * Figure out if there are any blocks beyond the end * of the file. If not, then there is nothing to do. */ --=-YSfENVvUqwVY6rUPWKOh-- From owner-linux-xfs Fri Nov 26 08:23:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Nov 2004 08:27:13 -0800 (PST) Received: from smtp.cistron-office.nl (mail@10fwd.cistron-office.nl [62.216.29.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQGNWsm013699 for ; Fri, 26 Nov 2004 08:23:33 -0800 Received: from traveler.cistron-office.nl ([62.216.29.67] helo=traveler) by smtp.cistron-office.nl with esmtp (Exim 3.35 #1 (Debian)) id 1CXisH-0006AV-00; Fri, 26 Nov 2004 17:23:09 +0100 Date: Fri, 26 Nov 2004 16:23:06 +0000 From: Miquel van Smoorenburg Subject: Re: [REPOST] [PATCH] fs/xfs/linux-2.6/kmem.c To: Nathan Scott Cc: Miquel van Smoorenburg , linux-xfs@oss.sgi.com References: <20041115103130.GA7971@cistron.nl> <20041117232247.GA9834@frodo> <1101386106l.15668l.0l@traveler> <20041126041132.GA1426@frodo> In-Reply-To: <20041126041132.GA1426@frodo> (from nathans@sgi.com on Fri Nov 26 05:11:32 2004) X-Mailer: Balsa 2.2.4 Message-Id: <1101486186l.15668l.4l@traveler> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id iAQGNYsm013717 X-archive-position: 4549 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: miquels@cistron.net Precedence: bulk X-list: linux-xfs Content-Length: 733 Lines: 23 On 2004.11.26 05:11, Nathan Scott wrote: > I tweaked a couple of things, esp. keeping the uses of GFP flags > together in kmem.h and xfs_buf.c and dropped the timeout. How > does the following patch fare for you? (could you also send me > a Signed-off-by: line for when the final patch is merged in?) Applied, compiled, module reloaded - looking good so far (half a day). > Index: xfs-linux/linux-2.6/xfs_buf.c > =================================================================== > --- xfs-linux.orig/linux-2.6/xfs_buf.c > +++ xfs-linux/linux-2.6/xfs_buf.c The patch is reasonably trivial and you changed most lines, but feel free to add my Signed-off-by: line to it: Signed-off-by: Miquel van Smoorenburg Thanks, Mike. From owner-linux-xfs Fri Nov 26 09:11:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 26 Nov 2004 09:15:19 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQHBbMg010608 for ; Fri, 26 Nov 2004 09:11:37 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAQHBbia010606 for linux-xfs@oss.sgi.com; Fri, 26 Nov 2004 09:11:37 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAQHBZ5K010579 for ; Fri, 26 Nov 2004 09:11:35 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAQGTVLl017659; Fri, 26 Nov 2004 08:29:31 -0800 Date: Fri, 26 Nov 2004 08:29:31 -0800 Message-Id: <200411261629.iAQGTVLl017659@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 389] Untarring an archive corrupts XFS file system X-Bugzilla-Reason: AssignedTo X-archive-position: 4550 X-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: 582 Lines: 28 http://oss.sgi.com/bugzilla/show_bug.cgi?id=389 ------- Additional Comments From james-p@moving-picture.com 2004-26-11 08:29 PDT ------- Thanks for the info. Just for completeness, looks like the fix appeared in kernel 2.4.27 (I only tested up to 2.4.26 ...). This looks like the problem: http://marc.theaimsgroup.com/?l=linux-xfs&m=108213125827763&w=2 and the fix: http://marc.theaimsgroup.com/?l=bk-commits-24&m=108514191810699&w=2 James Pearson ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Nov 28 08:47:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 28 Nov 2004 08:47:09 -0800 (PST) Received: from erc-server.ercwc.org (www.ercwc.org [198.85.167.1]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iASGl5fC001796 for ; Sun, 28 Nov 2004 08:47:05 -0800 Received: from [192.168.2.101] ([70.144.65.19]) by erc-server.ercwc.org with Microsoft SMTPSVC(5.0.2195.6713); Sun, 28 Nov 2004 11:46:39 -0500 Message-ID: <41AA001A.5070304@ercwc.org> Date: Sun, 28 Nov 2004 11:43:06 -0500 From: "Frank J. Buchholz" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: bad superblock after lvextend References: <41A35FAA.5000404@ercwc.org> In-Reply-To: <41A35FAA.5000404@ercwc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2004 16:46:39.0710 (UTC) FILETIME=[D51F57E0:01C4D569] X-archive-position: 4556 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frankb@ercwc.org Precedence: bulk X-list: linux-xfs Content-Length: 2557 Lines: 82 I was able to activate the filesystem using lvm however now when I run xfs_repair on the file system it complains about the superblock not being found and then continues to generate the following errors about secondary superblocks. # xfs_repair -o assume_xfs -v /dev/mapper/Volume00-LogVol00 Phase 1 - find and verify superblock... error reading superblock 31 -- seek to offset 2129889329152 failed couldn't verify primary superblock - bad magic number !!! attempting to find secondary superblock... ........................................... ....found candidate secondary superblock... error reading superblock 31 -- seek to offset 2129889329152 failed unable to verify superblock, continuing... This message repeats every hour or so on a 2TB filesystem. Is there anything I can do with xfs_db to help resolve this problem? Thanks, Frank Frank J. Buchholz wrote: > > > ------------------------------------------------------------------------ > > Subject: > bad superblock after lvextend > From: > "Frank J. Buchholz" > Date: > Mon, 22 Nov 2004 19:25:32 -0500 > To: > linux-xfs@oss.sgi.com > > To: > linux-xfs@oss.sgi.com > > > Hello, > > I recently attempted to extend my logical volume. First I added an > additional physical volume to an existing volume group. This worked fine. > > vgextend Volume00 /dev/sba > > However when it came time to run the lvextend command I received a > number of device-mapper errors. > > lvm> lvextend -L+1G /dev/Volume00/LogVol00 > Extending logical volume LogVol00 to 2.93 TB > device-mapper ioctl cmd 9 failed: Invalid argument > Couldn't load device 'Volume00-LogVol00'. > Problem reactivating LogVol00 > > While I was trying to determine what the errors were I noticed that > the filesystem that sits on the logical volume being extended was no > longer available. I attempted to umount the filesystem however the > command froze. I then rebooted the system without mounting the > filesystem in question and manually mounted the filesystem. XFS > reported back that it could not locate the superblock. > > I then ran xfs_repair... > # xfs_repair /dev/Volume00/LogVol00 > Phase 1 - find and verify superblock... > superblock read failed, offset 0, size 524288, ag 0, rval 0 > > fatal error -- Invalid argument > > Is it possible to repair this problem either through LVM or XFS? I > noticed there are a number of achieved .vg files in /etc/lvm/archive, > is it possible to restore LVM from one of these? Or is it possible to > rebuild the superblock? > > Thanks, > Frank > From owner-linux-xfs Sun Nov 28 19:00:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 28 Nov 2004 19:00:07 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAT3049g019977 for ; Sun, 28 Nov 2004 19:00:04 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAT4J3EN007661 for ; Sun, 28 Nov 2004 20:19:03 -0800 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAT2xgad4019820; Sun, 28 Nov 2004 18:59:42 -0800 (PST) Message-ID: <41AA90A2.7030007@sgi.com> Date: Sun, 28 Nov 2004 20:59:46 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Frank J. Buchholz" CC: linux-xfs@oss.sgi.com Subject: Re: bad superblock after lvextend References: <41A35FAA.5000404@ercwc.org> <41AA001A.5070304@ercwc.org> In-Reply-To: <41AA001A.5070304@ercwc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4557 X-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: 912 Lines: 20 Frank J. Buchholz wrote: >> Is it possible to repair this problem either through LVM or XFS? I >> noticed there are a number of achieved .vg files in /etc/lvm/archive, >> is it possible to restore LVM from one of these? Or is it possible to >> rebuild the superblock? Are you sure your lvm volume is reassembled properly... after repair finds the first superblock, it checks to be sure it looks fairly sane, then compares it against a number of other superblocks, checking for consistency. Here it looks like it's trying to check a superblock that should be towards the end of the disk - looks like still a bit under 2T - and it's failing because it can't seek out to that location (not an xfs problem per se, this is a seek() system call that fails). what does xfs_info on the filesystem say - I'd double check the geometry /size it reports and compare it with the size of your volume.... -Eric From owner-linux-xfs Mon Nov 29 15:10:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Nov 2004 15:10:04 -0800 (PST) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iATNA1Ex031614 for ; Mon, 29 Nov 2004 15:10:02 -0800 Received: (qmail 19708 invoked by uid 65534); 29 Nov 2004 23:09:35 -0000 Received: from p508840F5.dip0.t-ipconnect.de (EHLO bifroest.homelinux.org) (80.136.64.245) by mail.gmx.net (mp005) with SMTP; 30 Nov 2004 00:09:34 +0100 X-Authenticated: #530305 Received: from localhost (localhost.our-home.net [127.0.0.1]) by bifroest.homelinux.org (Postfix) with ESMTP id 495785C6 for ; Tue, 30 Nov 2004 00:09:16 +0100 (CET) Received: from bifroest.homelinux.org ([127.0.0.1]) by localhost (bifroest [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08386-02 for ; Tue, 30 Nov 2004 00:09:14 +0100 (CET) Received: from frodo (frodo.our-home.net [192.168.0.32]) by bifroest.homelinux.org (Postfix) with ESMTP id B899F3BC for ; Tue, 30 Nov 2004 00:09:13 +0100 (CET) From: Henning Rohde Reply-To: Rohde.Henning@gmx.net To: linux-xfs@oss.sgi.com Subject: xfs_copy gets killed after announcing success Date: Tue, 30 Nov 2004 00:09:10 +0100 User-Agent: KMail/1.7.1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411300009.14164.hr@our-home.net> X-Virus-Scanned: by amavisd-new at our-home.net X-archive-position: 4561 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Rohde.Henning@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 4577 Lines: 118 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everybody, today I've stumbled over some very astonishing problem: When trying to copy a clean xfs-filesystem with xfs_copy, everything seems fine until 100% - even until "All copies completed." is announced... But then I get the following line: "Killed". $? is 137. /var/tmp/xfs_copy.log.* is empty. There ist no difference if the destination is another partition or a file, as long as the filesystem in question is small enough, the copy is even readable, there's no special line in the logs: > XFS mounting filesystem $part > Ending clean XFS mount for filesystem: $part But one of my filesystems to backup was about 17GB in size, filled at about the halve: same phenomenon, but mount failed afterwards, xfs_repair reported severe corruptions. (Logs of xfs_repair are to be reproduced, I'll send them once requested.) Problem is reproducable with following Distros: SuSEv9.1: - - kernel-default-2.6.5-7.111.i586 - - xfsprogs-2.6.3-29.i586 Gentoo: - - kernel: 2.6.9-gentoo-r6 - - xfsprogs-2.6.13 Debian-SID: - - kernel-source-2.6.8_2.6.8-8 - - xfsprogs_2.6.20-1_i386 Is this murder on purpose, or is xfs_copy incompatible with Linux2.6? Can anybody imagine, why the imaging of the 17G-filesystem went wrong? Thanks for your help in advance, I'll provide further information as soon as requested, Henning Rohde PS: strace'ing on Gentoo: strace -o $file -ff /bin/xfs_copy # tail -20 /tmp/xfs_copy.strace > read(4, "XFSB\0\0\20\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 > _llseek(5, 201326592, [201326592], SEEK_SET) = 0 > write(5, "XFSB\0\0\20\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 > _llseek(4, 134217728, [134217728], SEEK_SET) = 0 > read(4, "XFSB\0\0\20\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 > _llseek(5, 134217728, [134217728], SEEK_SET) = 0 > write(5, "XFSB\0\0\20\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 > _llseek(4, 67108864, [67108864], SEEK_SET) = 0 > read(4, "XFSB\0\0\20\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 > _llseek(5, 67108864, [67108864], SEEK_SET) = 0 > write(5, "XFSB\0\0\20\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 > _llseek(4, 0, [0], SEEK_SET) = 0 > read(4, "XFSB\0\0\20\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 > _llseek(5, 0, [0], SEEK_SET) = 0 > write(5, "XFSB\0\0\20\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 > write(1, " ... 100%\n\n", 11) = 11 > write(1, "All copies completed.\n", 22) = 22 > tgkill(10588, 10589, SIGKILL) = 0 > futex(0x808a024, FUTEX_WAKE, 1) = 0 > +++ killed by SIGKILL +++ # tail -25 /tmp/xfs_copy.strace.10589 > futex(0x808a024, FUTEX_WAIT, 2, NULL) = 0 > write(5, "IN\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 299008) = 299008 > futex(0x8088764, FUTEX_WAKE, 1) = 0 > futex(0x808a024, FUTEX_WAIT, 2, NULL) = 0 > _llseek(5, 469762048, [469762048], SEEK_SET) = 0 > write(5, "XFSB\0\0\20\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 > futex(0x808a024, FUTEX_WAIT, 2, NULL) = 0 > write(5, "ABTB\0\0\0\1\377\377\377\377\377\377\377\377\0\0\27X\0"..., 4096000) = 4096000 > futex(0x808a024, FUTEX_WAIT, 2, NULL) = 0 > write(5, "t termios *sg;\nint sysv;\n{\n i"..., 4096000) = 4096000 > futex(0x8088764, FUTEX_WAKE, 1) = 1 > futex(0x808a024, FUTEX_WAIT, 2, NULL) = 0 > write(5, " system_bus_clock() / 1000 + 1, "..., 4096000) = 4096000 > futex(0x8088764, FUTEX_WAKE, 1) = 1 > futex(0x808a024, FUTEX_WAIT, 2, NULL) = 0 > write(5, "set\n# CONFIG_SOUND_MAESTRO3 is n"..., 4096000) = 4096000 > futex(0x8088764, FUTEX_WAKE, 1) = 1 > futex(0x808a024, FUTEX_WAIT, 2, NULL) = 0 > write(5, "#ifndef _ASM_M32R_POLL_H\n#define"..., 4096000) = 4096000 > futex(0x8088764, FUTEX_WAKE, 1) = 1 > futex(0x808a024, FUTEX_WAIT, 2, NULL) = 0 > write(5, ";\n\nstatic int patch_ad1888_speci"..., 3993600) = 3993600 > futex(0x8088764, FUTEX_WAKE, 1) = 1 > futex(0x808a024, FUTEX_WAIT, 2, NULL) = -1 EINTR (Interrupted system call) > +++ killed by SIGKILL +++ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBq6wauI8iUC+SACIRAucZAJ9fiN9Egk2/8GZsREqerIuRmEMsbACgl+zF AstvtB5vQn12u4C3ru0QYhE= =SOOp -----END PGP SIGNATURE----- From owner-linux-xfs Mon Nov 29 18:54:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Nov 2004 18:54:55 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAU2sn3G019374 for ; Mon, 29 Nov 2004 18:54:49 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iAU4Dubk004238 for ; Mon, 29 Nov 2004 20:13:56 -0800 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id iAU2rMad4209304; Mon, 29 Nov 2004 18:53:25 -0800 (PST) Message-ID: <41ABE0A0.4060607@sgi.com> Date: Mon, 29 Nov 2004 20:53:20 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohde.Henning@gmx.net CC: linux-xfs@oss.sgi.com Subject: Re: xfs_copy gets killed after announcing success References: <200411300009.14164.hr@our-home.net> In-Reply-To: <200411300009.14164.hr@our-home.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4562 X-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: 1077 Lines: 40 Henning Rohde wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi everybody, > > today I've stumbled over some very astonishing problem: > > When trying to copy a clean xfs-filesystem with xfs_copy, everything seems > fine until 100% - even until "All copies completed." is announced... > > But then I get the following line: "Killed". This is normal; at the end of xfs_copy main() it does: check_errors(); killall(); pthread_exit(NULL); /*NOTREACHED*/ return 0; (I'm not quite sure why, perhaps Russell can chime in on this...) > $? is 137. > /var/tmp/xfs_copy.log.* is empty. Hm, not sure about that. > > But one of my filesystems to backup was about 17GB in size, filled at about > the halve: > same phenomenon, but mount failed afterwards, xfs_repair reported severe > corruptions. > (Logs of xfs_repair are to be reproduced, I'll send them once requested.) This is more troublesome; if you can post the logs somewhere (http://oss.sgi.com/bugzilla would be a fine place) we can take a look. -Eric From owner-linux-xfs Mon Nov 29 21:35:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 29 Nov 2004 21:35:48 -0800 (PST) Received: from snort.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAU5ZhvA027758 for ; Mon, 29 Nov 2004 21:35:44 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id iAU5ZFtA1132534; Tue, 30 Nov 2004 16:35:15 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id iAU5ZD1H1131214; Tue, 30 Nov 2004 16:35:13 +1100 (EST) Date: Tue, 30 Nov 2004 16:35:13 +1100 (EST) From: Nathan Scott Message-Id: <200411300535.iAU5ZD1H1131214@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE 907752 - acl/attr X-archive-position: 4563 X-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: 10949 Lines: 168 License and email address updates from Andreas. Date: Tue Nov 30 16:34:10 AEDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/slinx/xfs-cmds-melb Modid: xfs-cmds-melb:slinx:20368a acl/VERSION - 1.68 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/VERSION.diff?r1=text&tr1=1.68&r2=text&tr2=1.67&f=h acl/doc/CHANGES - 1.75 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/CHANGES.diff?r1=text&tr1=1.75&r2=text&tr2=1.74&f=h acl/doc/Makefile - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/Makefile.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h acl/doc/COPYING - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/COPYING.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/debian/changelog - 1.62 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/debian/changelog.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h acl/setfacl/setfacl.c - 1.14 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/setfacl.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h acl/setfacl/sequence.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/sequence.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/setfacl/parse.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/parse.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h acl/setfacl/do_set.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/do_set.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h acl/libacl/acl_valid.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_valid.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h acl/libacl/acl_to_text.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_to_text.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h acl/libacl/acl_to_any_text.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_to_any_text.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h acl/libacl/acl_size.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_size.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_set_tag_type.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_set_tag_type.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_set_qualifier.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_set_qualifier.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_set_permset.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_set_permset.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_set_file.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_set_file.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_set_fd.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_set_fd.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_init.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_init.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h acl/libacl/acl_get_tag_type.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_get_tag_type.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_get_qualifier.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_get_qualifier.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_get_permset.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_get_permset.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_get_perm.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_get_perm.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_get_file.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_get_file.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h acl/libacl/acl_get_fd.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_get_fd.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h acl/libacl/acl_get_entry.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_get_entry.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_from_text.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_from_text.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h acl/libacl/acl_from_mode.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_from_mode.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_free.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_free.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_extended_file.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_extended_file.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_extended_fd.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_extended_fd.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_error.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_error.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h acl/libacl/acl_equiv_mode.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_equiv_mode.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_entries.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_entries.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_dup.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_dup.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_delete_perm.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_delete_perm.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_delete_entry.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_delete_entry.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_delete_def_file.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_delete_def_file.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h acl/libacl/acl_create_entry.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_create_entry.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h acl/libacl/acl_copy_int.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_copy_int.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_copy_ext.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_copy_ext.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_copy_entry.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_copy_entry.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_cmp.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_cmp.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_clear_perms.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_clear_perms.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_check.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_check.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/acl_calc_mask.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_calc_mask.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/acl_add_perm.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/acl_add_perm.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/__libobj.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/__libobj.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/__acl_to_xattr.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/__acl_to_xattr.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/__acl_reorder_obj_p.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/__acl_reorder_obj_p.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/__acl_from_xattr.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/__acl_from_xattr.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/getfacl/getfacl.c - 1.15 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/getfacl/getfacl.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h acl/getfacl/user_group.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/getfacl/user_group.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h acl/doc/LICENSE - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/LICENSE.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h acl/libacl/__acl_to_any_text.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/__acl_to_any_text.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/libacl/__apply_mask_to_mode.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/__apply_mask_to_mode.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h acl/libacl/perm_copy_fd.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/perm_copy_fd.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libacl/perm_copy_file.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libacl/perm_copy_file.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/libmisc/unquote.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libmisc/unquote.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h acl/libmisc/high_water_alloc.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libmisc/high_water_alloc.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Subject: TAKE 907752 - License and email address updates from Andreas. Date: Tue Nov 30 16:34:33 AEDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/slinx/xfs-cmds-melb Modid: xfs-cmds-melb:slinx:20369a attr/VERSION - 1.50 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/VERSION.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h attr/doc/CHANGES - 1.58 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h attr/debian/changelog - 1.51 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/debian/changelog.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h attr/setfattr/setfattr.c - 1.17 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/setfattr/setfattr.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h attr/getfattr/getfattr.c - 1.24 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/getfattr/getfattr.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h attr/libattr/attr_copy_fd.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libattr/attr_copy_fd.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h attr/libattr/attr_copy_file.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libattr/attr_copy_file.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h attr/libattr/attr_copy_check.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libattr/attr_copy_check.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h attr/libmisc/unquote.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libmisc/unquote.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h attr/libmisc/quote.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libmisc/quote.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h attr/libmisc/high_water_alloc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libmisc/high_water_alloc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs Tue Nov 30 04:42:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Nov 2004 04:42:56 -0800 (PST) Received: from erc-server.ercwc.org (www.ercwc.org [198.85.167.1]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iAUCgrPl028463 for ; Tue, 30 Nov 2004 04:42:53 -0800 Received: from [192.168.2.102] ([70.144.69.179]) by erc-server.ercwc.org with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Nov 2004 07:42:26 -0500 Message-ID: <41AC6A74.2070005@ercwc.org> Date: Tue, 30 Nov 2004 07:41:24 -0500 From: "Frank J. Buchholz" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: bad superblock after lvextend References: <41A35FAA.5000404@ercwc.org> <41AA001A.5070304@ercwc.org> <41AA90A2.7030007@sgi.com> In-Reply-To: <41AA90A2.7030007@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2004 12:42:26.0519 (UTC) FILETIME=[0BF75670:01C4D6DA] X-archive-position: 4564 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frankb@ercwc.org Precedence: bulk X-list: linux-xfs Content-Length: 1209 Lines: 32 Thanks Eric. That was it. When I had taken the LVM back to it's original size I inadvertantly subtracted too many extents. Once I made the LVM the corrent number of extents, I was able to read the filesystem. Phew. Big thanks! Frank Eric Sandeen wrote: > Frank J. Buchholz wrote: > >>> Is it possible to repair this problem either through LVM or XFS? I >>> noticed there are a number of achieved .vg files in >>> /etc/lvm/archive, is it possible to restore LVM from one of these? >>> Or is it possible to rebuild the superblock? >> > > Are you sure your lvm volume is reassembled properly... after repair > finds the first superblock, it checks to be sure it looks fairly sane, > then compares it against a number of other superblocks, checking for > consistency. Here it looks like it's trying to check a superblock > that should be towards the end of the disk - looks like still a bit > under 2T - and it's failing because it can't seek out to that location > (not an xfs problem per se, this is a seek() system call that fails). > > what does xfs_info on the filesystem say - I'd double check the > geometry /size it reports and compare it with the size of your volume.... > > -Eric From owner-linux-xfs Tue Nov 30 14:11:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Nov 2004 14:12:00 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAUMBuoG011386 for ; Tue, 30 Nov 2004 14:11:56 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAUMBuRZ011384 for linux-xfs@oss.sgi.com; Tue, 30 Nov 2004 14:11:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAUMBseD011344 for ; Tue, 30 Nov 2004 14:11:55 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAUM5v6p010598; Tue, 30 Nov 2004 14:05:57 -0800 Date: Tue, 30 Nov 2004 14:05:57 -0800 Message-Id: <200411302205.iAUM5v6p010598@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 384] Missing compat ioctls X-Bugzilla-Reason: AssignedTo X-archive-position: 4567 X-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: 654 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=384 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From hch@xfs.org 2004-30-11 14:05 PDT ------- Unfortunately adding them is non-trivial because they involve passing around user pointers. There's not plans to add them short-term. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Nov 30 14:11:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Nov 2004 14:11:58 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAUMBuTe011385 for ; Tue, 30 Nov 2004 14:11:56 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAUMBuIx011383 for linux-xfs@oss.sgi.com; Tue, 30 Nov 2004 14:11:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAUMBse9011344 for ; Tue, 30 Nov 2004 14:11:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAUM6YlP010609; Tue, 30 Nov 2004 14:06:34 -0800 Date: Tue, 30 Nov 2004 14:06:34 -0800 Message-Id: <200411302206.iAUM6YlP010609@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 380] CVS Linux 2.4 link failed w/ undefined reference to _pagebuf_find X-Bugzilla-Reason: AssignedTo X-archive-position: 4565 X-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: 546 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=380 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From hch@xfs.org 2004-30-11 14:06 PDT ------- This has been fixed long ago ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Nov 30 14:11:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Nov 2004 14:11:58 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAUMBvi9011404 for ; Tue, 30 Nov 2004 14:11:57 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAUMBv8e011402 for linux-xfs@oss.sgi.com; Tue, 30 Nov 2004 14:11:57 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAUMBseH011344 for ; Tue, 30 Nov 2004 14:11:55 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAUM7a6e010719; Tue, 30 Nov 2004 14:07:36 -0800 Date: Tue, 30 Nov 2004 14:07:36 -0800 Message-Id: <200411302207.iAUM7a6e010719@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 381] Segmentation fault while loading xfs module X-Bugzilla-Reason: AssignedTo X-archive-position: 4566 X-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: 648 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=381 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From hch@xfs.org 2004-30-11 14:07 PDT ------- This was a bug in the kernel module loader that happened to trigger when loading XFS. But it has been fixed for a while anyway. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Nov 30 15:11:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Nov 2004 15:12:00 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAUNBxsg013594 for ; Tue, 30 Nov 2004 15:11:59 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAUNBxOI013592 for linux-xfs@oss.sgi.com; Tue, 30 Nov 2004 15:11:59 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAUNBss1013530 for ; Tue, 30 Nov 2004 15:11:58 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAUMabTV012683; Tue, 30 Nov 2004 14:36:37 -0800 Date: Tue, 30 Nov 2004 14:36:37 -0800 Message-Id: <200411302236.iAUMabTV012683@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 343] still xfs/nfs oopses with 2.6.7-bk17 X-Bugzilla-Reason: AssignedTo X-archive-position: 4569 X-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: 623 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=343 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From hch@xfs.org 2004-30-11 14:36 PDT ------- This is not an OOPS but a warning from the memory allocator. And here it was't called from XFS either. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Nov 30 15:11:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Nov 2004 15:11:57 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAUNBtoM013545 for ; Tue, 30 Nov 2004 15:11:55 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAUNBtlb013544 for linux-xfs@oss.sgi.com; Tue, 30 Nov 2004 15:11:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iAUNBsrh013530 for ; Tue, 30 Nov 2004 15:11:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id iAUMQ5IB012485; Tue, 30 Nov 2004 14:26:05 -0800 Date: Tue, 30 Nov 2004 14:26:05 -0800 Message-Id: <200411302226.iAUMQ5IB012485@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 346] Fix for xfs_fsr crash on DEC Alpha X-Bugzilla-Reason: AssignedTo X-archive-position: 4568 X-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: 550 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=346 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From hch@xfs.org 2004-30-11 14:26 PDT ------- This was fixed in xfsdump 2.2.23 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Tue Nov 30 17:46:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 30 Nov 2004 17:46:49 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iB11kjIX022603 for ; Tue, 30 Nov 2004 17:46:45 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id iB1361m3028410 for ; Tue, 30 Nov 2004 19:06:01 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id iB11jDam3199941; Tue, 30 Nov 2004 19:45:14 -0600 (CST) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id iB11jBq526529042; Tue, 30 Nov 2004 19:45:12 -0600 (CST) Subject: Re: xfs_copy gets killed after announcing success From: Russell Cattelan To: Eric Sandeen Cc: Rohde.Henning@gmx.net, linux-xfs@oss.sgi.com In-Reply-To: <41ABE0A0.4060607@sgi.com> References: <200411300009.14164.hr@our-home.net> <41ABE0A0.4060607@sgi.com> Content-Type: text/plain Date: Tue, 30 Nov 2004 19:45:10 -0600 Message-Id: <1101865510.13235.160.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.0 Content-Transfer-Encoding: 7bit X-archive-position: 4570 X-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@thebarn.com Precedence: bulk X-list: linux-xfs Content-Length: 1420 Lines: 49 On Mon, 2004-11-29 at 20:53 -0600, Eric Sandeen wrote: > Henning Rohde wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi everybody, > > > > today I've stumbled over some very astonishing problem: > > > > When trying to copy a clean xfs-filesystem with xfs_copy, everything seems > > fine until 100% - even until "All copies completed." is announced... > > > > But then I get the following line: "Killed". > > This is normal; at the end of xfs_copy main() it does: > > check_errors(); > killall(); > pthread_exit(NULL); > /*NOTREACHED*/ > return 0; > > (I'm not quite sure why, perhaps Russell can chime in on this...) This is how the original irix code was cleaning up it's children, by sending a kill signal. I suppose it would be better to create a exit var and have the children break their loop and then pthread_exit. > > > $? is 137. > > /var/tmp/xfs_copy.log.* is empty. > > Hm, not sure about that. > > > > > But one of my filesystems to backup was about 17GB in size, filled at about > > the halve: > > same phenomenon, but mount failed afterwards, xfs_repair reported severe > > corruptions. > > (Logs of xfs_repair are to be reproduced, I'll send them once requested.) > > This is more troublesome; if you can post the logs somewhere > (http://oss.sgi.com/bugzilla would be a fine place) we can take a look. > > -Eric >