From owner-xfs@oss.sgi.com Tue Aug 1 04:31:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Aug 2006 04:31:35 -0700 (PDT) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k71BVJDW010050 for ; Tue, 1 Aug 2006 04:31:21 -0700 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1G7sSV-0005q0-4x for xfs@oss.sgi.com; Tue, 01 Aug 2006 04:30:47 -0700 Message-ID: <5592702.post@talk.nabble.com> Date: Tue, 1 Aug 2006 04:30:47 -0700 (PDT) From: calembour To: xfs@oss.sgi.com Subject: Re: write back cache and barriers In-Reply-To: <44CC2D1A.3060805@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: mrcekets@gmail.com X-Nabble-From: calembour References: <5545990.post@talk.nabble.com> <44CC2D1A.3060805@sandeen.net> X-archive-position: 8529 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mrcekets@gmail.com Precedence: bulk X-list: xfs Thanks a lot for your hints Marco -- View this message in context: http://www.nabble.com/write-back-cache-and-barriers-tf2017234.html#a5592702 Sent from the Xfs - General forum at Nabble.com. From owner-xfs@oss.sgi.com Tue Aug 1 05:57:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Aug 2006 05:57:23 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k71CvADW027534 for ; Tue, 1 Aug 2006 05:57:12 -0700 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 0E1A4D92FEA for ; Tue, 1 Aug 2006 07:55:17 -0400 (EDT) Received: from web2.messagingengine.com ([10.202.2.211]) by frontend3.internal (MEProxy); Tue, 01 Aug 2006 07:55:20 -0400 Received: by web2.messagingengine.com (Postfix, from userid 99) id 769CAE126; Tue, 1 Aug 2006 07:55:20 -0400 (EDT) Message-Id: <1154433320.2160.267361956@webmail.messagingengine.com> X-Sasl-Enc: MtsYUaFj0wcJJ/qNPX3JOPBMhHVpcOr2fvKvkAYFmrcG 1154433320 From: "CN" To: xfs@oss.sgi.com Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="GB2312" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface Subject: xfs_check refuses to work on readonly fs Date: Tue, 01 Aug 2006 19:55:20 +0800 X-archive-position: 8530 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cnliou9@fastmail.fm Precedence: bulk X-list: xfs Hi! # init 1 # mount -o ro,remount / # mount /dev/hda1 on / type xfs (rw) # xfs_check /dev/hda1 xfs_check: /dev/hda1 contains a mounted and writable filesystem xfs_check/xfs_repair are willing to work only when I boot from a disk and check/repair the other unmounted disk. Why "mount" shows (rw) instead of (ro) even "mount -o ro,remount /" is issued? fsck.ext3 works fine given the same sequence of commands for ext3 mounted file system. Did I miss anything with XFS? Thank you in advance! CN -- http://www.fastmail.fm - mmm... Fastmail... From owner-xfs@oss.sgi.com Tue Aug 1 10:35:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Aug 2006 10:36:09 -0700 (PDT) Received: from woody.linuxathome.me (host81-151-221-214.range81-151.btcentralplus.com [81.151.221.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k71HZtDW019535 for ; Tue, 1 Aug 2006 10:35:59 -0700 Received: from jessie.linuxathome.me (jessie.linuxathome.me [10.0.0.2]) by woody.linuxathome.me (Postfix) with ESMTP id 7D6AE53D64; Tue, 1 Aug 2006 16:38:06 +0100 (BST) Received: from hedi by jessie.linuxathome.me with local (Exim 4.62) (envelope-from ) id 1G7wLX-0001BI-G9; Tue, 01 Aug 2006 16:39:51 +0100 Date: Tue, 1 Aug 2006 16:39:51 +0100 From: Hedi Berriche To: CN Cc: xfs@oss.sgi.com Subject: Re: xfs_check refuses to work on readonly fs Message-ID: <20060801153951.GB17036@linuxathome.me> References: <1154433320.2160.267361956@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FFoLq8A0u+X9iRU8" Content-Disposition: inline In-Reply-To: <1154433320.2160.267361956@webmail.messagingengine.com> User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 8531 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hedi@berriche.co.uk Precedence: bulk X-list: xfs --FFoLq8A0u+X9iRU8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Based on the info you provided I infer that you're running Linux. On Tue, Aug 01, 2006 at 14:00 CN wrote: | Hi! | | # init 1 | # mount -o ro,remount / | # mount | /dev/hda1 on / type xfs (rw) | # xfs_check /dev/hda1 | xfs_check: /dev/hda1 contains a mounted and writable filesystem | | xfs_check/xfs_repair are willing to work only when I boot from a disk | and check/repair the other unmounted disk. | | Why "mount" shows (rw) instead of (ro) even "mount -o ro,remount /" is | issued? Because mount is relying on /etc/mtab which couldn't be updated precisely because / was remounted ro. You'll need a recent xfsprogs version, at least 2.7.17 IIRC, one that uses that uses /proc/mounts instead of /etc/mtab to check filesystem status. Or you can use a dirty and quick hack - prior to remounting ro, edit /etc/mtab and change the root fs entry from rw to ro. - remount ro - run your xfs_check/xfs_repair in dangerous mode. FWIW the safe thing to do after a repair on a mounted root FS is to reboot. Cheers, Hedi. --FFoLq8A0u+X9iRU8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEz3XHzLYXAd7ekr0RAmccAJ9qSDms78A5zFs6KZcEU1v00jiGXwCfZr4A 20UbpNSSHtDpmN8JGEGZFDM= =it3F -----END PGP SIGNATURE----- --FFoLq8A0u+X9iRU8-- From owner-xfs@oss.sgi.com Tue Aug 1 14:53:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Aug 2006 14:53:57 -0700 (PDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k71LrYDW002059 for ; Tue, 1 Aug 2006 14:53:37 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G829A-0002sY-E5 for linux-xfs@oss.sgi.com; Tue, 01 Aug 2006 23:51:29 +0200 Received: from 1303ds1-by.0.fullrate.dk ([89.150.142.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Aug 2006 23:51:28 +0200 Received: from asjo by 1303ds1-by.0.fullrate.dk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Aug 2006 23:51:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: asjo@koldfront.dk (Adam =?iso-8859-1?Q?Sj=F8gren?=) Subject: Re: Review: xfs_repair fixes for dir2 corruption Date: Tue, 01 Aug 2006 23:50:14 +0200 Organization: koldfront - analysis & revolution, Copenhagen, Denmark Lines: 21 Message-ID: <87ac6oruqx.fsf@topper.koldfront.dk> References: <20060728091735.B2196410@wobbly.melbourne.sgi.com> <200607280155.LAA12814@larry.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1303ds1-by.0.fullrate.dk X-Face: )qY&CseJ?.:=8F#^~GcSA?F=9eu'{KAFfL1C3/A&:nE?PW\i65"ba0NS)97,Q(^@xk}n4Ou rPuR#V8I(J_@~H($[ym:`K_+]*kjvW>xH5jbgLBVFGXY:(#4P>zVBklLbdL&XxL\M)%T}3S/IS9lMJ ^St'=VZBR For those that are keen to fix the 16777216 problem, give this patch > a go. I thought that I'd just report that the patch worked flawlessly when I applied it to xfsprogs from cvs and ran the the resulting xfs_repair on my bad filesystem (see <87veqhfmo4.fsf@topper.koldfront.dk>, <87fyhd1ek7.fsf@topper.koldfront.dk>). I have another box (Intel P4) which had the problem, the patched xfs_repair fixed its three bad filesystems as well. Thanks! Adam -- "Subdued flamboyance" Adam Sjøgren asjo@koldfront.dk From owner-xfs@oss.sgi.com Tue Aug 1 17:25:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Aug 2006 17:25:44 -0700 (PDT) Received: from rrzmta2.rz.uni-regensburg.de (rrzmta2.rz.uni-regensburg.de [132.199.1.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k720PVDW020994 for ; Tue, 1 Aug 2006 17:25:34 -0700 Received: from rrzmta2.rz.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3B7BC4319C; Wed, 2 Aug 2006 01:06:59 +0200 (CEST) Received: from pc51072.physik.uni-regensburg.de (pc51072.physik.uni-regensburg.de [132.199.98.129]) by rrzmta2.rz.uni-regensburg.de (Postfix) with ESMTP id 3564E430F7; Wed, 2 Aug 2006 01:06:59 +0200 (CEST) Received: by pc51072.physik.uni-regensburg.de (Postfix, from userid 28561) id D9A255030E1; Wed, 2 Aug 2006 01:06:48 +0200 (CEST) Date: Wed, 2 Aug 2006 01:06:48 +0200 From: Christian Guggenberger To: Adam =?iso-8859-1?Q?Sj=F8gren?= Cc: linux-xfs@oss.sgi.com Subject: Re: Review: xfs_repair fixes for dir2 corruption Message-ID: <20060801230648.GA2736@pc51072.physik.uni-regensburg.de> Reply-To: christian.guggenberger@physik.uni-regensburg.de References: <20060728091735.B2196410@wobbly.melbourne.sgi.com> <200607280155.LAA12814@larry.melbourne.sgi.com> <87ac6oruqx.fsf@topper.koldfront.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87ac6oruqx.fsf@topper.koldfront.dk> User-Agent: Mutt/1.5.9i X-archive-position: 8533 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: xfs On Tue, Aug 01, 2006 at 11:50:14PM +0200, Adam Sjøgren wrote: > On Fri, 28 Jul 2006 11:58:52 +1000, Barry wrote: > > > For those that are keen to fix the 16777216 problem, give this patch > > a go. > > I thought that I'd just report that the patch worked flawlessly when I > applied it to xfsprogs from cvs and ran the the resulting xfs_repair > on my bad filesystem (see <87veqhfmo4.fsf@topper.koldfront.dk>, > <87fyhd1ek7.fsf@topper.koldfront.dk>). > I'd like to report a "me too". No problems arised while repairing a corrupted filesystem on powerpc with the method mentioned above. thanks. - Christian From owner-xfs@oss.sgi.com Tue Aug 1 17:49:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Aug 2006 17:50:07 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k720nVDW029582 for ; Tue, 1 Aug 2006 17:49:42 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26942; Wed, 2 Aug 2006 10:48:50 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 9695D58C6F55; Wed, 2 Aug 2006 10:48:50 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 954896 - xfsprogs Message-Id: <20060802004850.9695D58C6F55@chook.melbourne.sgi.com> Date: Wed, 2 Aug 2006 10:48:50 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8534 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Fix buffer sizing issue for large pagesize systems, affecting mkfs auto-device-type-detection heuristics. Date: Wed Aug 2 10:48:16 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: Arthur Corliss The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26662a xfsprogs/doc/CHANGES - 1.214 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.214&r2=text&tr2=1.213&f=h xfsprogs/libdisk/fstype.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libdisk/fstype.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h From owner-xfs@oss.sgi.com Tue Aug 1 18:19:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Aug 2006 18:19:15 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k721IjDW009774 for ; Tue, 1 Aug 2006 18:18:58 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA27637 for ; Wed, 2 Aug 2006 11:18:09 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 4A69958C6F55; Wed, 2 Aug 2006 11:18:09 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfsprogs Message-Id: <20060802011809.4A69958C6F55@chook.melbourne.sgi.com> Date: Wed, 2 Aug 2006 11:18:09 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8535 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Bump xfsprogs version number. Date: Wed Aug 2 11:17:59 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26665a xfsprogs/VERSION - 1.160 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.160&r2=text&tr2=1.159&f=h xfsprogs/doc/CHANGES - 1.215 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.215&r2=text&tr2=1.214&f=h xfsprogs/debian/changelog - 1.145 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.145&r2=text&tr2=1.144&f=h From owner-xfs@oss.sgi.com Tue Aug 1 18:27:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Aug 2006 18:28:16 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k721RMDW013054 for ; Tue, 1 Aug 2006 18:27:36 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA27746; Wed, 2 Aug 2006 11:26:42 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k721Qbgw2350973; Wed, 2 Aug 2006 11:26:37 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k721QUAd2349420; Wed, 2 Aug 2006 11:26:30 +1000 (EST) Date: Wed, 2 Aug 2006 11:26:30 +1000 From: Nathan Scott To: Jan Dittmer , Joe Jin , kernel Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS Bug null pointer dereference in xfs_free_ag_extent Message-ID: <20060802112629.A2341636@wobbly.melbourne.sgi.com> References: <44CB0BF7.6030204@idccenter.cn> <44CB1303.7010303@l4x.org> <20060731094424.E2280998@wobbly.melbourne.sgi.com> <44CDA156.6000105@idccenter.cn> <20060731165522.K2280998@wobbly.melbourne.sgi.com> <44CDB135.8080401@idccenter.cn> <20060731194310.A2301615@wobbly.melbourne.sgi.com> <44CDD5B9.8020608@idccenter.cn> <215036450607311849o43b1555br13ea2f3f20fb3b82@mail.gmail.com> <44CF0CDE.2080500@l4x.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44CF0CDE.2080500@l4x.org>; from jdi@l4x.org on Tue, Aug 01, 2006 at 10:12:14AM +0200 X-archive-position: 8536 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs On Tue, Aug 01, 2006 at 10:12:14AM +0200, Jan Dittmer wrote: > Joe Jin schrieb: > > From the information, I think it caused by (args.agbp == NULL). > > get rid of, we'll find the call trace should panic: > > xfs_free_extent > > |_ xfs_free_ag_extent => here args.agbp= NULL; > > |_ xfs_btree_init_cursor() > > |_ agf = XFS_BUF_TO_AGF(agbp); => (xfs_agf_t > > *)XFS_BUF_PTR(arbp) > > |_ (xfs_caddr_t)((agbp)->b_addr) : but > > here, agbp is NULL > > so it caused the oops. > > Non debug option, and the oops occured at xfs_btree_init_cursor(). > > > > Probably caused by this part of the diff from Nathan's earlier mail: *nod* - that is my suspicion, be great if you guys with the reproducible case could confirm/deny.. (assuming this is the case we're hitting, you can also try changing the assignment to NULL there to instead be "agbp", and see if that corrects things for you once more). > --- fs/xfs/xfs_alloc.c > +++ fs/xfs/xfs_alloc.c > > @@ -1951,8 +1951,14 @@ xfs_alloc_fix_freelist( > * the restrictions correctly. Can happen for free calls > * on a completely full ag. > */ > - if (targs.agbno == NULLAGBLOCK) > + if (targs.agbno == NULLAGBLOCK) { > + if (!(flags & XFS_ALLOC_FLAG_FREEING)) { > + xfs_trans_brelse(tp, agflbp); > + args->agbp = NULL; > + return 0; > + } > break; > + } cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Aug 1 19:22:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Aug 2006 19:23:00 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k722MMDW030182 for ; Tue, 1 Aug 2006 19:22:34 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA27429; Wed, 2 Aug 2006 11:12:30 +1000 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 k721BxEo43284547; Wed, 2 Aug 2006 11:12:00 +1000 (AEST) Received: (from bnaujok@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k721BwC142764969; Wed, 2 Aug 2006 11:11:58 +1000 (AEST) Date: Wed, 2 Aug 2006 11:11:58 +1000 (AEST) From: Barry Naujok Message-Id: <200608020111.k721BwC142764969@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 954405 - X-archive-position: 8537 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Fix dirv2 rebuild in phase6 Date: Wed Aug 2 11:12:00 AEST 2006 Workarea: snort.melbourne.sgi.com:/home/bnaujok/isms/repair Inspected by: mvalluri@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26664a xfsprogs/include/libxfs.h - 1.52 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxfs.h.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h - pv:954405 Added flush operation for buffer cache and exported a couple more libxfs bmap functions xfsprogs/repair/phase6.c - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase6.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h - Fixed dirv2 rebuild and duplicate name checking xfsprogs/libxfs/rdwr.c - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/rdwr.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h - pv:954405 Added flush operation for the buffer cache xfsprogs/libxfs/xfs.h - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs.h.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h - pv:954405 Exported a couple more libxfs bmap functions xfsprogs/include/cache.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/cache.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h xfsprogs/libxfs/cache.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/cache.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h - pv:954405 Added flush operation for the buffer cache From owner-xfs@oss.sgi.com Tue Aug 1 21:33:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Aug 2006 21:34:07 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k724XMDW018139 for ; Tue, 1 Aug 2006 21:33:34 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01670; Wed, 2 Aug 2006 14:32:38 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k724WZgw2348381; Wed, 2 Aug 2006 14:32:35 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k724WVXY2354593; Wed, 2 Aug 2006 14:32:31 +1000 (EST) Date: Wed, 2 Aug 2006 14:32:31 +1000 From: Nathan Scott To: Jan Kasprzak Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: FAQ updated (was Re: XFS breakage...) Message-ID: <20060802143231.D2341636@wobbly.melbourne.sgi.com> References: <20060718222941.GA3801@stargate.galaxy> <20060719085731.C1935136@wobbly.melbourne.sgi.com> <1153304468.3706.4.camel@localhost> <20060720171310.B1970528@wobbly.melbourne.sgi.com> <20060731162535.GA15555@fi.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060731162535.GA15555@fi.muni.cz>; from kas@fi.muni.cz on Mon, Jul 31, 2006 at 06:25:35PM +0200 X-archive-position: 8538 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs On Mon, Jul 31, 2006 at 06:25:35PM +0200, Jan Kasprzak wrote: > Nathan Scott wrote: > : I've captured the state of this issue here, with options and ways > : to correct the problem: > : http://oss.sgi.com/projects/xfs/faq.html#dir2 > : > : Hope this helps. > > I have been hit with this bug as well - I tried to clear the > two corrupted directory inodes with xfs_db (as the FAQ entry says), then ran > xfs_repair (lots of files ended up in lost+found), but apparently > the volume is still not OK - when I tried to use it (this volume > is a public FTP archive), I got the following traces: There is now a fixed version of xfs_repair available - its in xfsprogs-2.8.10, source is on oss.sgi.com in the XFS ftp area. A number of people have reported success with Barry's earlier patch, noone's reported anything bad, so 2.8.10 is out now with the fix merged. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Aug 2 00:05:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Aug 2006 00:05:51 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7275CDW009273 for ; Wed, 2 Aug 2006 00:05:23 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04592 for ; Wed, 2 Aug 2006 17:04:35 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7274Xgw2357635 for ; Wed, 2 Aug 2006 17:04:33 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7274WlA2321057 for xfs@oss.sgi.com; Wed, 2 Aug 2006 17:04:32 +1000 (EST) Date: Wed, 2 Aug 2006 17:04:31 +1000 From: Nathan Scott To: xfs@oss.sgi.com Subject: review: catch large memory allocations Message-ID: <20060802170431.A2356368@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8540 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 7948 Lines: 226 As discussed the other day, this is primarily a debugging patch to catch allocations that are unexpectedly large or dipping into vmalloc space. cheers. -- Nathan Index: xfs-linux/linux-2.4/kmem.c =================================================================== --- xfs-linux.orig/linux-2.4/kmem.c 2006-08-02 13:54:44.183452250 +1000 +++ xfs-linux/linux-2.4/kmem.c 2006-08-02 13:59:38.934868500 +1000 @@ -53,6 +53,19 @@ kmem_alloc(size_t size, int flags) int retries = 0, lflags = kmem_flags_convert(flags); void *ptr; +#ifdef DEBUG + if (unlikely(!(flags & KM_LARGE) && (size > PAGE_SIZE))) { + printk(KERN_WARNING "Large %s attempt, size=%ld\n", + __FUNCTION__, (long)size); + dump_stack(); + } + if (unlikely(size >= MAX_SLAB_SIZE)) { + printk(KERN_WARNING "%s using vmalloc, size=%ld\n", + __FUNCTION__, (long)size); + dump_stack(); + } +#endif + do { if (size < MAX_SLAB_SIZE || retries > MAX_VMALLOCS) ptr = kmalloc(size, lflags); Index: xfs-linux/linux-2.6/kmem.c =================================================================== --- xfs-linux.orig/linux-2.6/kmem.c 2006-08-02 13:54:44.311460250 +1000 +++ xfs-linux/linux-2.6/kmem.c 2006-08-02 13:59:47.419398750 +1000 @@ -34,6 +34,19 @@ kmem_alloc(size_t size, unsigned int __n gfp_t lflags = kmem_flags_convert(flags); void *ptr; +#ifdef DEBUG + if (unlikely(!(flags & KM_LARGE) && (size > PAGE_SIZE))) { + printk(KERN_WARNING "Large %s attempt, size=%ld\n", + __FUNCTION__, (long)size); + dump_stack(); + } + if (unlikely(size >= MAX_SLAB_SIZE)) { + printk(KERN_WARNING "%s using vmalloc, size=%ld\n", + __FUNCTION__, (long)size); + dump_stack(); + } +#endif + do { if (size < MAX_SLAB_SIZE || retries > MAX_VMALLOCS) ptr = kmalloc(size, lflags); Index: xfs-linux/linux-2.4/xfs_lrw.h =================================================================== --- xfs-linux.orig/linux-2.4/xfs_lrw.h 2006-08-02 13:54:44.215454250 +1000 +++ xfs-linux/linux-2.4/xfs_lrw.h 2006-08-02 13:54:48.087696250 +1000 @@ -31,7 +31,7 @@ struct xfs_iomap; /* * Defines for the trace mechanisms in xfs_lrw.c. */ -#define XFS_RW_KTRACE_SIZE 128 +#define XFS_RW_KTRACE_SIZE 64 #define XFS_READ_ENTER 1 #define XFS_WRITE_ENTER 2 Index: xfs-linux/linux-2.6/xfs_lrw.h =================================================================== --- xfs-linux.orig/linux-2.6/xfs_lrw.h 2006-08-02 13:54:44.343462250 +1000 +++ xfs-linux/linux-2.6/xfs_lrw.h 2006-08-02 13:54:48.131699000 +1000 @@ -31,7 +31,7 @@ struct xfs_iomap; /* * Defines for the trace mechanisms in xfs_lrw.c. */ -#define XFS_RW_KTRACE_SIZE 128 +#define XFS_RW_KTRACE_SIZE 64 #define XFS_READ_ENTER 1 #define XFS_WRITE_ENTER 2 Index: xfs-linux/linux-2.6/kmem.h =================================================================== --- xfs-linux.orig/linux-2.6/kmem.h 2006-08-02 13:54:44.375464250 +1000 +++ xfs-linux/linux-2.6/kmem.h 2006-08-02 13:54:48.187702500 +1000 @@ -30,6 +30,7 @@ #define KM_NOSLEEP 0x0002u #define KM_NOFS 0x0004u #define KM_MAYFAIL 0x0008u +#define KM_LARGE 0x0010u /* * We use a special process flag to avoid recursive callbacks into @@ -41,7 +42,7 @@ kmem_flags_convert(unsigned int __nocast { gfp_t lflags; - BUG_ON(flags & ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS|KM_MAYFAIL)); + BUG_ON(flags & ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS|KM_MAYFAIL|KM_LARGE)); if (flags & KM_NOSLEEP) { lflags = GFP_ATOMIC | __GFP_NOWARN; Index: xfs-linux/linux-2.4/kmem.h =================================================================== --- xfs-linux.orig/linux-2.4/kmem.h 2006-08-02 13:54:44.247456250 +1000 +++ xfs-linux/linux-2.4/kmem.h 2006-08-02 13:54:48.211704000 +1000 @@ -29,6 +29,7 @@ #define KM_NOSLEEP 0x0002 #define KM_NOFS 0x0004 #define KM_MAYFAIL 0x0008 +#define KM_LARGE 0x0010 /* * We use a special process flag to avoid recursive callbacks into @@ -40,7 +41,7 @@ kmem_flags_convert(int flags) { int lflags; - BUG_ON(flags & ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS|KM_MAYFAIL)); + BUG_ON(flags & ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS|KM_MAYFAIL|KM_LARGE)); if (flags & KM_NOSLEEP) { lflags = GFP_ATOMIC; Index: xfs-linux/support/ktrace.c =================================================================== --- xfs-linux.orig/support/ktrace.c 2006-08-02 13:54:44.447468750 +1000 +++ xfs-linux/support/ktrace.c 2006-08-02 13:54:48.231705250 +1000 @@ -75,7 +75,7 @@ ktrace_alloc(int nentries, unsigned int sleep); } else { ktep = (ktrace_entry_t*)kmem_zalloc((nentries * sizeof(*ktep)), - sleep); + sleep | KM_LARGE); } if (ktep == NULL) { Index: xfs-linux/linux-2.6/xfs_buf.c =================================================================== --- xfs-linux.orig/linux-2.6/xfs_buf.c 2006-08-02 13:54:44.411466500 +1000 +++ xfs-linux/linux-2.6/xfs_buf.c 2006-08-02 13:54:48.259707000 +1000 @@ -773,7 +773,7 @@ xfs_buf_get_noaddr( _xfs_buf_initialize(bp, target, 0, len, 0); try_again: - data = kmem_alloc(malloc_len, KM_SLEEP | KM_MAYFAIL); + data = kmem_alloc(malloc_len, KM_SLEEP | KM_MAYFAIL | KM_LARGE); if (unlikely(data == NULL)) goto fail_free_buf; Index: xfs-linux/linux-2.4/xfs_buf.c =================================================================== --- xfs-linux.orig/linux-2.4/xfs_buf.c 2006-08-02 13:54:44.283458500 +1000 +++ xfs-linux/linux-2.4/xfs_buf.c 2006-08-02 13:54:48.283708500 +1000 @@ -875,7 +875,7 @@ xfs_buf_get_noaddr( _xfs_buf_initialize(bp, target, 0, len, XBF_FORCEIO); try_again: - data = kmem_alloc(malloc_len, KM_SLEEP | KM_MAYFAIL); + data = kmem_alloc(malloc_len, KM_SLEEP | KM_MAYFAIL | KM_LARGE); if (unlikely(data == NULL)) goto fail_free_buf; Index: xfs-linux/xfs_log.c =================================================================== --- xfs-linux.orig/xfs_log.c 2006-08-02 13:54:44.475470500 +1000 +++ xfs-linux/xfs_log.c 2006-08-02 13:54:48.367713750 +1000 @@ -1226,7 +1226,7 @@ xlog_alloc_log(xfs_mount_t *mp, kmem_zalloc(sizeof(xlog_in_core_t), KM_SLEEP); iclog = *iclogp; iclog->hic_data = (xlog_in_core_2_t *) - kmem_zalloc(iclogsize, KM_SLEEP); + kmem_zalloc(iclogsize, KM_SLEEP | KM_LARGE); iclog->ic_prev = prev_iclog; prev_iclog = iclog; Index: xfs-linux/xfs_iget.c =================================================================== --- xfs-linux.orig/xfs_iget.c 2006-08-02 13:54:44.507472500 +1000 +++ xfs-linux/xfs_iget.c 2006-08-02 13:54:48.387715000 +1000 @@ -50,7 +50,7 @@ void xfs_ihash_init(xfs_mount_t *mp) { __uint64_t icount; - uint i, flags = KM_SLEEP | KM_MAYFAIL; + uint i, flags = KM_SLEEP | KM_MAYFAIL | KM_LARGE; if (!mp->m_ihsize) { icount = mp->m_maxicount ? mp->m_maxicount : @@ -95,7 +95,7 @@ xfs_chash_init(xfs_mount_t *mp) mp->m_chsize = min_t(uint, mp->m_chsize, mp->m_ihsize); mp->m_chash = (xfs_chash_t *)kmem_zalloc(mp->m_chsize * sizeof(xfs_chash_t), - KM_SLEEP); + KM_SLEEP | KM_LARGE); for (i = 0; i < mp->m_chsize; i++) { spinlock_init(&mp->m_chash[i].ch_lock,"xfshash"); } Index: xfs-linux/quota/xfs_qm.c =================================================================== --- xfs-linux.orig/quota/xfs_qm.c 2006-08-02 13:54:44.551475250 +1000 +++ xfs-linux/quota/xfs_qm.c 2006-08-02 13:54:48.431717750 +1000 @@ -112,17 +112,17 @@ xfs_Gqm_init(void) { xfs_dqhash_t *udqhash, *gdqhash; xfs_qm_t *xqm; - uint i, hsize, flags = KM_SLEEP | KM_MAYFAIL; + uint i, hsize, flags = KM_SLEEP | KM_MAYFAIL | KM_LARGE; /* * Initialize the dquot hash tables. */ hsize = XFS_QM_HASHSIZE_HIGH; - while (!(udqhash = kmem_zalloc(hsize * sizeof(xfs_dqhash_t), flags))) { + while (!(udqhash = kmem_zalloc(hsize * sizeof(*udqhash), flags))) { if ((hsize >>= 1) <= XFS_QM_HASHSIZE_LOW) flags = KM_SLEEP; } - gdqhash = kmem_zalloc(hsize * sizeof(xfs_dqhash_t), KM_SLEEP); + gdqhash = kmem_zalloc(hsize * sizeof(*gdqhash), KM_SLEEP | KM_LARGE); ndquot = hsize << 8; xqm = kmem_zalloc(sizeof(xfs_qm_t), KM_SLEEP); From owner-xfs@oss.sgi.com Wed Aug 2 00:07:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Aug 2006 00:07:57 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7277GDW010082 for ; Wed, 2 Aug 2006 00:07:27 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04623 for ; Wed, 2 Aug 2006 17:06:39 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7276bgw2327111 for ; Wed, 2 Aug 2006 17:06:38 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7276aCO2355087 for xfs@oss.sgi.com; Wed, 2 Aug 2006 17:06:36 +1000 (EST) Date: Wed, 2 Aug 2006 17:06:36 +1000 From: Nathan Scott To: xfs@oss.sgi.com Subject: review: greedy allocation interface Message-ID: <20060802170636.B2356368@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8541 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 6788 Lines: 198 As discussed. Slightly different interface, it was a bit simpler to have both min/max passed in separately to the passed out size. cheers. -- Nathan Index: xfs-linux/linux-2.4/kmem.c =================================================================== --- xfs-linux.orig/linux-2.4/kmem.c 2006-08-02 13:59:38.934868500 +1000 +++ xfs-linux/linux-2.4/kmem.c 2006-08-02 14:06:16.163693750 +1000 @@ -90,6 +90,19 @@ kmem_zalloc(size_t size, int flags) return ptr; } +void * +kmem_zalloc_greedy(size_t *size, size_t minsize, size_t maxsize, int flags) +{ + void *ptr; + + while (!(ptr = kmem_zalloc(maxsize, flags))) { + if ((maxsize >>= 1) <= minsize) + flags = KM_SLEEP; + } + *size = maxsize; + return ptr; +} + void kmem_free(void *ptr, size_t size) { Index: xfs-linux/linux-2.4/kmem.h =================================================================== --- xfs-linux.orig/linux-2.4/kmem.h 2006-08-02 13:54:48.211704000 +1000 +++ xfs-linux/linux-2.4/kmem.h 2006-08-02 14:06:16.183695000 +1000 @@ -54,8 +54,9 @@ kmem_flags_convert(int flags) } extern void *kmem_alloc(size_t, int); -extern void *kmem_realloc(void *, size_t, size_t, int); extern void *kmem_zalloc(size_t, int); +extern void *kmem_zalloc_greedy(size_t *, size_t, size_t, int); +extern void *kmem_realloc(void *, size_t, size_t, int); extern void kmem_free(void *, size_t); /* Index: xfs-linux/linux-2.6/kmem.c =================================================================== --- xfs-linux.orig/linux-2.6/kmem.c 2006-08-02 13:59:47.419398750 +1000 +++ xfs-linux/linux-2.6/kmem.c 2006-08-02 14:06:16.207696500 +1000 @@ -73,6 +73,20 @@ kmem_zalloc(size_t size, unsigned int __ return ptr; } +void * +kmem_zalloc_greedy(size_t *size, size_t minsize, size_t maxsize, + unsigned int __nocast flags) +{ + void *ptr; + + while (!(ptr = kmem_zalloc(maxsize, flags))) { + if ((maxsize >>= 1) <= minsize) + flags = KM_SLEEP; + } + *size = maxsize; + return ptr; +} + void kmem_free(void *ptr, size_t size) { Index: xfs-linux/linux-2.6/kmem.h =================================================================== --- xfs-linux.orig/linux-2.6/kmem.h 2006-08-02 13:54:48.187702500 +1000 +++ xfs-linux/linux-2.6/kmem.h 2006-08-02 14:06:16.231698000 +1000 @@ -55,8 +55,9 @@ kmem_flags_convert(unsigned int __nocast } extern void *kmem_alloc(size_t, unsigned int __nocast); -extern void *kmem_realloc(void *, size_t, size_t, unsigned int __nocast); extern void *kmem_zalloc(size_t, unsigned int __nocast); +extern void *kmem_zalloc_greedy(size_t *, size_t, size_t, unsigned int __nocast); +extern void *kmem_realloc(void *, size_t, size_t, unsigned int __nocast); extern void kmem_free(void *, size_t); /* Index: xfs-linux/quota/xfs_qm.c =================================================================== --- xfs-linux.orig/quota/xfs_qm.c 2006-08-02 13:54:48.431717750 +1000 +++ xfs-linux/quota/xfs_qm.c 2006-08-02 14:06:16.251699250 +1000 @@ -112,17 +112,16 @@ xfs_Gqm_init(void) { xfs_dqhash_t *udqhash, *gdqhash; xfs_qm_t *xqm; - uint i, hsize, flags = KM_SLEEP | KM_MAYFAIL | KM_LARGE; + uint i, hsize; /* * Initialize the dquot hash tables. */ - hsize = XFS_QM_HASHSIZE_HIGH; - while (!(udqhash = kmem_zalloc(hsize * sizeof(*udqhash), flags))) { - if ((hsize >>= 1) <= XFS_QM_HASHSIZE_LOW) - flags = KM_SLEEP; - } - gdqhash = kmem_zalloc(hsize * sizeof(*gdqhash), KM_SLEEP | KM_LARGE); + udqhash = kmem_zalloc_greedy(&hsize, + XFS_QM_HASHSIZE_LOW, XFS_QM_HASHSIZE_HIGH, + KM_SLEEP | KM_MAYFAIL | KM_LARGE); + gdqhash = kmem_zalloc(hsize, KM_SLEEP | KM_LARGE); + hsize /= sizeof(xfs_dqhash_t); ndquot = hsize << 8; xqm = kmem_zalloc(sizeof(xfs_qm_t), KM_SLEEP); Index: xfs-linux/quota/xfs_qm.h =================================================================== --- xfs-linux.orig/quota/xfs_qm.h 2006-08-02 13:54:34.842868500 +1000 +++ xfs-linux/quota/xfs_qm.h 2006-08-02 14:06:16.263700000 +1000 @@ -52,8 +52,8 @@ extern kmem_zone_t *qm_dqtrxzone; /* * Dquot hashtable constants/threshold values. */ -#define XFS_QM_HASHSIZE_LOW (NBPP / sizeof(xfs_dqhash_t)) -#define XFS_QM_HASHSIZE_HIGH ((NBPP * 4) / sizeof(xfs_dqhash_t)) +#define XFS_QM_HASHSIZE_LOW (NBPP) +#define XFS_QM_HASHSIZE_HIGH (NBPP * 4) /* * We output a cmn_err when quotachecking a quota file with more than Index: xfs-linux/xfs_iget.c =================================================================== --- xfs-linux.orig/xfs_iget.c 2006-08-02 13:54:48.387715000 +1000 +++ xfs-linux/xfs_iget.c 2006-08-02 14:10:27.901694500 +1000 @@ -61,14 +61,11 @@ xfs_ihash_init(xfs_mount_t *mp) (64 * NBPP) / sizeof(xfs_ihash_t)); } - while (!(mp->m_ihash = (xfs_ihash_t *)kmem_zalloc(mp->m_ihsize * - sizeof(xfs_ihash_t), flags))) { - if ((mp->m_ihsize >>= 1) <= NBPP) - flags = KM_SLEEP; - } - for (i = 0; i < mp->m_ihsize; i++) { + mp->m_ihash = kmem_zalloc_greedy(&mp->m_ihsize, NBPC, + mp->m_ihsize * sizeof(xfs_ihash_t), + KM_SLEEP | KM_MAYFAIL | KM_LARGE); + for (i = 0; i < mp->m_ihsize; i++) rwlock_init(&(mp->m_ihash[i].ih_lock)); - } } /* @@ -77,7 +74,7 @@ xfs_ihash_init(xfs_mount_t *mp) void xfs_ihash_free(xfs_mount_t *mp) { - kmem_free(mp->m_ihash, mp->m_ihsize*sizeof(xfs_ihash_t)); + kmem_free(mp->m_ihash, mp->m_ihsize * sizeof(xfs_ihash_t)); mp->m_ihash = NULL; } Index: xfs-linux/xfs_itable.c =================================================================== --- xfs-linux.orig/xfs_itable.c 2006-08-02 13:54:38.735111750 +1000 +++ xfs-linux/xfs_itable.c 2006-08-02 14:11:38.405330500 +1000 @@ -326,7 +326,6 @@ xfs_bulkstat( int i; /* loop index */ int icount; /* count of inodes good in irbuf */ int irbsize; /* size of irec buffer in bytes */ - unsigned int kmflags; /* flags for allocating irec buffer */ xfs_ino_t ino; /* inode number (filesystem) */ xfs_inobt_rec_incore_t *irbp; /* current irec buffer pointer */ xfs_inobt_rec_incore_t *irbuf; /* start of irec buffer */ @@ -371,19 +370,8 @@ xfs_bulkstat( (XFS_INODE_CLUSTER_SIZE(mp) >> mp->m_sb.sb_inodelog); nimask = ~(nicluster - 1); nbcluster = nicluster >> mp->m_sb.sb_inopblog; - /* - * Allocate a local buffer for inode cluster btree records. - * This caps our maximum readahead window (so don't be stingy) - * but we must handle the case where we can't get a contiguous - * multi-page buffer, so we drop back toward pagesize; the end - * case we ensure succeeds, via appropriate allocation flags. - */ - irbsize = NBPP * 4; - kmflags = KM_SLEEP | KM_MAYFAIL; - while (!(irbuf = kmem_alloc(irbsize, kmflags))) { - if ((irbsize >>= 1) <= NBPP) - kmflags = KM_SLEEP; - } + irbuf = kmem_zalloc_greedy(&irbsize, NBPC, NBPC * 4, + KM_SLEEP | KM_MAYFAIL | KM_LARGE); nirbuf = irbsize / sizeof(*irbuf); /* From owner-xfs@oss.sgi.com Wed Aug 2 07:23:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Aug 2006 07:23:21 -0700 (PDT) Received: from apple.cjx.com (37.233.187.81.in-addr.arpa [81.187.233.37]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k72EN5DW010265 for ; Wed, 2 Aug 2006 07:23:10 -0700 Received: from [10.0.1.8] (mac.cjx.com [10.0.1.8]) (authenticated bits=0) by apple.cjx.com (8.12.11/8.12.11) with ESMTP id k72D3Hmf024295 for ; Wed, 2 Aug 2006 14:03:17 +0100 Message-ID: <44D0A296.9020307@cjx.com> Date: Wed, 02 Aug 2006 14:03:18 +0100 From: Chris Allen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS stack space crashes - current status? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8542 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chris@cjx.com Precedence: bulk X-list: xfs Content-Length: 1484 Lines: 49 I have a box running XFS over md (raid5) over Fedora core5 2.6.17-1 kernel. The box contains 16x750GB SATA drives combined into a single 11TB raid5 partition using md, and this partition contains a single XFS filesystem. I can consistently crash the box within about ten minutes with a simple perl script that spawns 25 processes each of which loop writing random files to the filesystem. The only message I get on the console is something like this: do_IRQ: stack overflow: 492 Once crashed, the box requires a hard reboot to rescue it (and needs to resync the RAID array). As the box is to be used for a production upload fileserver receiving several hundred simultaneous uploads, I would most likely be seeing this problem lots. So..... questions: 1. How much is known about this problem? Seeing as it is 100% reproducible, is there any active development underway to fix it? 2. I have seen postings that say compiling a kernel with 8K stacks will fix the problem. Is this the case? Or will I be able to trigger it again by running 100 or 200 simultaneous writes? 3. Any suggestions as to what I should try? At present it looks like I am stuck between finding a fix for XFS and splitting the box into 2 or 3 EXT3 partitions (which I really don't want to do). I have tried ReiserFS (max FS size is 8TB even though the FAQ says 16), and JFS (jfs_fsck segfaults which doesn't fill me with confidence). Many thanks for any suggestions, Chris Allen. From owner-xfs@oss.sgi.com Wed Aug 2 07:36:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Aug 2006 07:36:42 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k72EaNDW015466 for ; Wed, 2 Aug 2006 07:36:29 -0700 Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 4B8A9D93487 for ; Wed, 2 Aug 2006 10:35:57 -0400 (EDT) Received: from web2.messagingengine.com ([10.202.2.211]) by frontend3.internal (MEProxy); Wed, 02 Aug 2006 10:36:01 -0400 Received: by web2.messagingengine.com (Postfix, from userid 99) id E1450F4CD; Wed, 2 Aug 2006 10:36:00 -0400 (EDT) Message-Id: <1154529360.12604.267468790@webmail.messagingengine.com> X-Sasl-Enc: hxHBq6blxlqCRP3JomGCujI71eFmwd0ycGJ61EQku7fr 1154529360 From: "CN" To: xfs@oss.sgi.com Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="GB2312" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface References: <1154433320.2160.267361956@webmail.messagingengine.com> <20060801153951.GB17036@linuxathome.me> Subject: Re: xfs_check refuses to work on readonly fs In-Reply-To: <20060801153951.GB17036@linuxathome.me> Date: Wed, 02 Aug 2006 22:36:00 +0800 X-archive-position: 8543 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cnliou9@fastmail.fm Precedence: bulk X-list: xfs Content-Length: 1348 Lines: 48 Hi! Hedi, > Based on the info you provided I infer that you're running Linux. Yes. I forgot to mention this. > | # init 1 > | # mount -o ro,remount / > | # mount > | /dev/hda1 on / type xfs (rw) > | # xfs_check /dev/hda1 > | xfs_check: /dev/hda1 contains a mounted and writable filesystem > | > | xfs_check/xfs_repair are willing to work only when I boot from a disk > | and check/repair the other unmounted disk. > | > | Why "mount" shows (rw) instead of (ro) even "mount -o ro,remount /" is > | issued? > > Because mount is relying on /etc/mtab which couldn't be updated > precisely because / was remounted ro. > > You'll need a recent xfsprogs version, at least 2.7.17 IIRC, one > that uses that uses /proc/mounts instead of /etc/mtab to check > filesystem status. > > Or you can use a dirty and quick hack > > - prior to remounting ro, edit /etc/mtab and change the root fs entry > from > rw to ro. > - remount ro > - run your xfs_check/xfs_repair in dangerous mode. > > FWIW the safe thing to do after a repair on a mounted root FS is to > reboot. I upgraded xfsprogs to 2.8.4 and have tried both approaches you provided but still have no luck. Only one thing is different: "mount" now reports "ro" if I edit /etc/mtab as you instructed. Regards, CN -- http://www.fastmail.fm - The professional email service From owner-xfs@oss.sgi.com Wed Aug 2 13:20:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Aug 2006 13:21:01 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k72KKoDW014481 for ; Wed, 2 Aug 2006 13:20:50 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k72IxeU4024759; Wed, 2 Aug 2006 14:59:40 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k72IxeQp026500; Wed, 2 Aug 2006 14:59:40 -0400 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k72IxdA1025777; Wed, 2 Aug 2006 14:59:40 -0400 Message-ID: <44D0F61A.5070200@sandeen.net> Date: Wed, 02 Aug 2006 13:59:38 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Chris Allen CC: linux-xfs@oss.sgi.com Subject: Re: XFS stack space crashes - current status? References: <44D0A296.9020307@cjx.com> In-Reply-To: <44D0A296.9020307@cjx.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8545 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1310 Lines: 44 Chris Allen wrote: > So..... questions: > > 1. How much is known about this problem? Seeing as it is 100% reproducible, > is there any active development underway to fix it? XFS is a lot less stack-heavy than it used to be, but if you put enough IO code between sys_write and your disks, it can all add up to a problem. > 2. I have seen postings that say compiling a kernel with 8K stacks will > fix the > problem. Is this the case? Or will I be able to trigger it again by > running 100 or > 200 simultaneous writes? More threads probably won't matter. > 3. Any suggestions as to what I should try? At present it looks like I > am stuck between > finding a fix for XFS and splitting the box into 2 or 3 EXT3 partitions > (which I really don't > want to do). I have tried ReiserFS (max FS size is 8TB even though the > FAQ says 16), and > JFS (jfs_fsck segfaults which doesn't fill me with confidence). If you can run w/ 8k stacks you will probably be in better shape. If you want to do a bit of testing, go into do_IRQ() and change the warning threshold (STACK_WARN) to something slightly bigger, so that you'll get the warning message earlier, and you should also get a backtrace that tells you how you got there. -Eric > > Many thanks for any suggestions, > > Chris Allen. > > > > From owner-xfs@oss.sgi.com Wed Aug 2 14:59:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Aug 2006 14:59:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k72LxCDW000574 for ; Wed, 2 Aug 2006 14:59:14 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k72LW3MB015620; Wed, 2 Aug 2006 17:32:03 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k72LW3Ri010818; Wed, 2 Aug 2006 17:32:03 -0400 Received: from [10.15.80.54] (xenon.msp.redhat.com [10.15.80.54]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k72LW0uQ032670; Wed, 2 Aug 2006 17:32:02 -0400 Message-ID: <44D119E5.3070504@thebarn.com> Date: Wed, 02 Aug 2006 16:32:21 -0500 From: Russell Cattelan User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Chris Allen CC: xfs@oss.sgi.com Subject: Re: XFS stack space crashes - current status? References: <44D0A296.9020307@cjx.com> In-Reply-To: <44D0A296.9020307@cjx.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8546 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 2003 Lines: 67 Chris Allen wrote: > I have a box running XFS over md (raid5) over Fedora core5 2.6.17-1 > kernel. > > The box contains 16x750GB SATA drives combined into a single 11TB raid5 > partition using md, and this partition contains a single XFS filesystem. > > I can consistently crash the box within about ten minutes with a simple > perl script that spawns 25 processes each of which loop writing random > files to the filesystem. Ya md with raid5 and XFS is not real happy with 4k stacks. I never bothered to spend the time to track down who might be the worst offenders. It's not really XFS that is a problem here but the combination of all the drivers you have stacked up. You might try turning on 8k stacks and all the stack debugging routines that will dump stack when you over a preset thread hold. Which scsi driver are you using? > > The only message I get on the console is something like this: > > do_IRQ: stack overflow: 492 > > > Once crashed, the box requires a hard reboot to rescue it (and needs > to resync > the RAID array). > > > As the box is to be used for a production upload fileserver receiving > several hundred > simultaneous uploads, I would most likely be seeing this problem lots. > > So..... questions: > > 1. How much is known about this problem? Seeing as it is 100% > reproducible, > is there any active development underway to fix it? > > 2. I have seen postings that say compiling a kernel with 8K stacks > will fix the > problem. Is this the case? Or will I be able to trigger it again by > running 100 or > 200 simultaneous writes? > > 3. Any suggestions as to what I should try? At present it looks like I > am stuck between > finding a fix for XFS and splitting the box into 2 or 3 EXT3 > partitions (which I really don't > want to do). I have tried ReiserFS (max FS size is 8TB even though the > FAQ says 16), and > JFS (jfs_fsck segfaults which doesn't fill me with confidence). > > > Many thanks for any suggestions, > > Chris Allen. > > > From owner-xfs@oss.sgi.com Wed Aug 2 15:05:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Aug 2006 15:05:59 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k72M5iDW001616 for ; Wed, 2 Aug 2006 15:05:44 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k72KmDZq000765 for ; Wed, 2 Aug 2006 16:48:13 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k72Km8Bf027493 for ; Wed, 2 Aug 2006 16:48:08 -0400 Received: from [10.15.80.54] (xenon.msp.redhat.com [10.15.80.54]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k72Km60l030925 for ; Wed, 2 Aug 2006 16:48:07 -0400 Message-ID: <44D10F9B.8090904@thebarn.com> Date: Wed, 02 Aug 2006 15:48:27 -0500 From: Russell Cattelan User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: review: Simple patch to remove the dmapi support from xfsdump Content-Type: multipart/mixed; boundary="------------090007050401070301000808" X-archive-position: 8547 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 7331 Lines: 288 This is a multi-part message in MIME format. --------------090007050401070301000808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Since very few people run xfs with dmapi enabled it seem kind of silly to force the install of the dmapi utils/libraries just for xfs dump/restore. This patch stubs out the Hsm functions and adjusts the autoconf to not fail in the case of missing dmapi headers/libs. If somebody does trie to do a dump with the -a option a ERROR message is issued, the dump does continue? this might not be the desired behavior. --------------090007050401070301000808 Content-Type: text/plain; name="no_dmapi" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="no_dmapi" Index: xfs-cmds/xfsdump/aclocal.m4 =================================================================== --- xfs-cmds.orig/xfsdump/aclocal.m4 2006-08-02 14:51:34.000000000 -0500 +++ xfs-cmds/xfsdump/aclocal.m4 2006-08-02 14:58:11.250605250 -0500 @@ -161,27 +161,31 @@ AC_DEFUN([AC_PACKAGE_NEED_XFS_DMAPI_H], [ AC_CHECK_HEADERS([xfs/dmapi.h]) if test "$ac_cv_header_xfs_dmapi_h" != yes; then echo - echo 'FATAL ERROR: could not find a valid DMAPI library header.' - echo 'Install the data migration API (dmapi) development package.' + echo 'WARNING: could not find a valid DMAPI library header.' + echo 'xfsdump / xfsrestore will not support dmapi file systems.' echo 'Alternatively, run "make install-dev" from the dmapi source.' - exit 1 fi ]) AC_DEFUN([AC_PACKAGE_NEED_MAKEHANDLE_LIBDM], - [ AC_CHECK_LIB(dm, dm_make_handle,, [ + [ AC_CHECK_LIB(dm, dm_make_handle, + [have_dmapi=true + libdm="-ldm" + test -f `pwd`/../dmapi/libdm/libdm.la && \ + libdm="`pwd`/../dmapi/libdm/libdm.la" + test -f ${libexecdir}${libdirsuffix}/libdm.la && \ + libdm="${libexecdir}${libdirsuffix}/libdm.la" + ], + [ echo - echo 'FATAL ERROR: could not find a valid DMAPI base library.' - echo 'Install the data migration API (dmapi) library package.' + echo 'WARNING: could not find a valid DMAPI base library.' + echo 'xfsdump / xfsrestore will not support dmapi file systems.' echo 'Alternatively, run "make install" from the dmapi source.' - exit 1 + have_dmapi=false + libdm = "" ]) - libdm="-ldm" - test -f `pwd`/../dmapi/libdm/libdm.la && \ - libdm="`pwd`/../dmapi/libdm/libdm.la" - test -f ${libexecdir}${libdirsuffix}/libdm.la && \ - libdm="${libexecdir}${libdirsuffix}/libdm.la" AC_SUBST(libdm) + AC_SUBST(have_dmapi) ]) # Index: xfs-cmds/xfsdump/common/hsmapi_noop.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ xfs-cmds/xfsdump/common/hsmapi_noop.c 2006-08-02 15:38:39.046333000 -0500 @@ -0,0 +1,147 @@ +/* + * Copyright (c) 2000-2004 Silicon Graphics, Inc. + * All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include + +#include "hsmapi.h" +#include "mlog.h" +#include "exit.h" + +typedef struct { +} dmf_fs_ctxt_t; + +extern hsm_fs_ctxt_t * +HsmInitFsysContext( +const char *mountpoint, + int dumpversion) +{ + mlog( MLOG_NORMAL | MLOG_ERROR, _( + "-%c Dumping of DMF dualstate file not supported in this version\n")); + return NULL; +} + +extern void +HsmDeleteFsysContext( + hsm_fs_ctxt_t *contextp) +{ +} + +extern int +HsmEstimateFileSpace( + hsm_fs_ctxt_t *contextp, +const xfs_bstat_t *statp, + off64_t *bytes) +{ + return 0; +} + +extern int +HsmEstimateFileOffset( + hsm_fs_ctxt_t *contextp, +const xfs_bstat_t *statp, + off64_t bytecount, + off64_t *byteoffset) +{ + return 0; +} + +extern hsm_f_ctxt_t * +HsmAllocateFileContext( + hsm_fs_ctxt_t *contextp) +{ + return NULL; +} + +extern void +HsmDeleteFileContext( + hsm_f_ctxt_t *contextp) +{ +} + +extern int +HsmInitFileContext( + hsm_f_ctxt_t *contextp, +const xfs_bstat_t *statp) +{ + return 0; +} + +extern int +HsmModifyInode( + hsm_f_ctxt_t *contextp, + xfs_bstat_t *statp) +{ + return 0; +} + +extern int +HsmModifyExtentMap( + hsm_f_ctxt_t *contextp, + struct getbmapx *bmap) +{ + return 0; +} + +extern int +HsmFilterExistingAttribute( + hsm_f_ctxt_t *hsm_f_ctxtp, +const char *namep, /* attribute name */ + u_int32_t valuesz, /* value size */ + int flag, + int *skip_entry) +{ + return 0; +} + +extern int +HsmAddNewAttribute( + hsm_f_ctxt_t *hsm_f_ctxtp, + int cursor, + int flag, + char **namepp, /* pointer to new attribute name */ + char **valuepp, /* pointer to its value */ + u_int32_t *valueszp) /* pointer to the value size */ +{ + return 0; +} + +extern void +HsmBeginRestoreFile( + bstat_t *bstatp, + int fd, + int *hsm_flagp) +{ +} + +extern void +HsmRestoreAttribute( + int flag, /* ext attr flags */ + char *namep, /* pointer to new attribute name */ + int *hsm_flagp) +{ +} + +extern void +HsmEndRestoreFile( + char *path, + int fd, + int *hsm_flagp) +{ +} Index: xfs-cmds/xfsdump/dump/Makefile =================================================================== --- xfs-cmds.orig/xfsdump/dump/Makefile 2006-08-02 14:51:34.000000000 -0500 +++ xfs-cmds/xfsdump/dump/Makefile 2006-08-02 14:52:15.076345750 -0500 @@ -57,7 +57,6 @@ COMMON = \ fs.c \ getdents.c \ global.c \ - hsmapi.c \ lock.c \ main.c \ mlog.c \ @@ -69,6 +68,12 @@ COMMON = \ util.c \ sproc.c +ifeq ($(HAVE_DMAPI), true) + COMMON += hsmapi.c +else + COMMON += hsmapi_noop.c +endif + LOCALS = \ content.c \ inomap.c \ Index: xfs-cmds/xfsdump/include/builddefs.in =================================================================== --- xfs-cmds.orig/xfsdump/include/builddefs.in 2006-08-02 14:51:34.000000000 -0500 +++ xfs-cmds/xfsdump/include/builddefs.in 2006-08-02 14:52:15.080346000 -0500 @@ -66,6 +66,8 @@ ENABLE_GETTEXT = @enable_gettext@ HAVE_ZIPPED_MANPAGES = @have_zipped_manpages@ +HAVE_DMAPI = @have_dmapi@ + LCFLAGS += -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 ifeq ($(PKG_PLATFORM),linux) Index: xfs-cmds/xfsdump/restore/Makefile =================================================================== --- xfs-cmds.orig/xfsdump/restore/Makefile 2006-08-02 14:51:34.000000000 -0500 +++ xfs-cmds/xfsdump/restore/Makefile 2006-08-02 14:52:15.080346000 -0500 @@ -55,7 +55,6 @@ COMMON = \ fs.c \ getdents.c \ global.c \ - hsmapi.c \ lock.c \ main.c \ mlog.c \ @@ -67,6 +66,12 @@ COMMON = \ stream.c \ util.c +ifeq ($(HAVE_DMAPI), true) + COMMON += hsmapi.c +else + COMMON += hsmapi_noop.c +endif + LOCALS = \ bag.c \ content.c \ --------------090007050401070301000808-- From owner-xfs@oss.sgi.com Thu Aug 3 04:29:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Aug 2006 04:29:46 -0700 (PDT) Received: from otto.lonx.net (work.lonx.net [195.243.240.241]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k73BTXDW024685 for ; Thu, 3 Aug 2006 04:29:33 -0700 Received: from localhost (localhost [127.0.0.1]) by otto.lonx.net (Postfix) with ESMTP id 052FF261C for ; Thu, 3 Aug 2006 12:26:59 +0200 (CEST) Received: from otto.lonx.net ([127.0.0.1]) by localhost (otto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23806-05 for ; Thu, 3 Aug 2006 12:26:56 +0200 (CEST) Received: from otto.lonx.net (localhost [127.0.0.1]) by otto.lonx.net (Postfix) with ESMTP id 4ABC2261B for ; Thu, 3 Aug 2006 12:26:56 +0200 (CEST) Received: from 62.159.242.114 (SquirrelMail authenticated user danam) by otto.lonx.net with HTTP; Thu, 3 Aug 2006 12:26:56 +0200 (CEST) Message-ID: <28749.62.159.242.114.1154600816.squirrel@otto.lonx.net> Date: Thu, 3 Aug 2006 12:26:56 +0200 (CEST) Subject: "xfs_io -c chattr +i " on a symlink From: "Dan Am" To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-archive-position: 8548 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xfs@lonx.net Precedence: bulk X-list: xfs Content-Length: 673 Lines: 32 (resend, since I used the wrong account to send the initial mail, sorry) Dear list, I am trying to make a symlink immutable with chattr, however the command seems to follow the link, which point to a NFS Mount. Setting xattr works on symlink btw, which is useful. More data below Any ideas ? Best Regards Dan Heres the situation from my machine's view: /data > ls -l bin lrwxrwxrwx 1 root root 48 Aug 2 15:53 bin -> /archive/l01abnfs07/bin /data> xfs_io -c "chattr +i" bin xfs_io: specified file ["bin"] is not on an XFS filesystem ~ > xfs_io -V xfs_io version 2.8.4 ~ > cat /etc/SuSE-release SUSE LINUX Enterprise Server 9 (i586) VERSION = 9 PATCHLEVEL = 3 From owner-xfs@oss.sgi.com Thu Aug 3 05:19:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Aug 2006 05:19:48 -0700 (PDT) Received: from otto.lonx.net (work.lonx.net [195.243.240.241]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k73CJXDW001640 for ; Thu, 3 Aug 2006 05:19:34 -0700 Received: from localhost (localhost [127.0.0.1]) by otto.lonx.net (Postfix) with ESMTP id 61DE0261D for ; Thu, 3 Aug 2006 12:18:42 +0200 (CEST) Received: from otto.lonx.net ([127.0.0.1]) by localhost (otto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23913-04 for ; Thu, 3 Aug 2006 12:18:40 +0200 (CEST) Received: from otto.lonx.net (localhost [127.0.0.1]) by otto.lonx.net (Postfix) with ESMTP id A73F8261C for ; Thu, 3 Aug 2006 12:18:40 +0200 (CEST) Received: from 62.159.242.114 (SquirrelMail authenticated user danam) by otto.lonx.net with HTTP; Thu, 3 Aug 2006 12:18:40 +0200 (CEST) Message-ID: <15447.62.159.242.114.1154600320.squirrel@otto.lonx.net> Date: Thu, 3 Aug 2006 12:18:40 +0200 (CEST) Subject: "xfs_io -c chattr +i " on a symlink From: "Daniel Amthor" To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal References: In-Reply-To: X-archive-position: 8549 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: da@lonx.net Precedence: bulk X-list: xfs Content-Length: 597 Lines: 28 Dear list, I am trying to make a symlink immutable with chattr, however the command seems to follow the link, which point to a NFS Mount. Setting xattr works on symlink btw, which is useful. More data below Any ideas ? Best Regards Dan Heres the situation from my machine's view: /data > ls -l bin lrwxrwxrwx 1 root root 48 Aug 2 15:53 bin -> /archive/l01abnfs07/bin /data> xfs_io -c "chattr +i" bin xfs_io: specified file ["bin"] is not on an XFS filesystem ~ > xfs_io -V xfs_io version 2.8.4 ~ > cat /etc/SuSE-release SUSE LINUX Enterprise Server 9 (i586) VERSION = 9 PATCHLEVEL = 3 From owner-xfs@oss.sgi.com Thu Aug 3 07:13:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Aug 2006 07:13:56 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k73EDgDW021718 for ; Thu, 3 Aug 2006 07:13:42 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 6C59218234E88; Thu, 3 Aug 2006 09:13:07 -0500 (CDT) Message-ID: <44D20473.3010304@sandeen.net> Date: Thu, 03 Aug 2006 09:13:07 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Dan Am Cc: xfs@oss.sgi.com Subject: Re: "xfs_io -c chattr +i " on a symlink References: <28749.62.159.242.114.1154600816.squirrel@otto.lonx.net> In-Reply-To: <28749.62.159.242.114.1154600816.squirrel@otto.lonx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8550 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1401 Lines: 47 Dan Am wrote: > (resend, since I used the wrong account to send the initial mail, sorry) > > Dear list, > > I am trying to make a symlink immutable with chattr, however the command > seems to follow the link, which point to a NFS Mount. > Setting xattr works on symlink btw, which is useful. > More data below > Any ideas ? > > Best Regards > Dan > > Heres the situation from my machine's view: > /data > ls -l bin > lrwxrwxrwx 1 root root 48 Aug 2 15:53 bin -> /archive/l01abnfs07/bin > > /data> xfs_io -c "chattr +i" bin > xfs_io: specified file ["bin"] is not on an XFS filesystem > > ~ > xfs_io -V > xfs_io version 2.8.4 Try just using chattr. [sandeen@sandeen ~]$ ln -s /tmp tmplink [sandeen@sandeen ~]$ ls -l tmplink lrwxrwxrwx 1 sandeen sandeen 4 Aug 3 09:05 tmplink -> /tmp [sandeen@sandeen ~]$ su Password: [root@sandeen sandeen]# chattr +i tmplink [root@sandeen sandeen]# stat -f tmplink File: "tmplink" ID: 802 Namelen: 255 Type: XFS (0x58465342) Blocks: Total: 23377204 Free: 8557099 Available: 8557099 Size: 4096 Inodes: Total: 93554496 Free: 93202008 [root@sandeen sandeen]# [root@sandeen sandeen]# lsattr tmplink ----i-------- tmplink xfs_io also has an option to try to do operations even on non-xfs filesystems, if that helps... if it follows the link & sets the attr on the link target, that may not be behaving as expected though. -Eric From owner-xfs@oss.sgi.com Thu Aug 3 07:33:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Aug 2006 07:33:44 -0700 (PDT) Received: from web31704.mail.mud.yahoo.com (web31704.mail.mud.yahoo.com [68.142.201.184]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k73EXTDW025740 for ; Thu, 3 Aug 2006 07:33:30 -0700 Received: (qmail 51759 invoked by uid 60001); 3 Aug 2006 14:33:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pqjv0y5M2szs422Qv/buAYc5/Ni4/qXHJaX4iFuDj5qFySeMr+bpbpAZ+CJk4sy6HQbbxtMOpK2s0E96Qbfv29GyqMibVnWwUJbVhWqPFNmbT3zKCvhxPqeKV8PtMXCVLLq40nMZXAf4s3Vsq/fm+q7WeTuHJInDwgcwLdIBX24= ; Message-ID: <20060803143301.51757.qmail@web31704.mail.mud.yahoo.com> Received: from [212.150.66.71] by web31704.mail.mud.yahoo.com via HTTP; Thu, 03 Aug 2006 07:33:01 PDT Date: Thu, 3 Aug 2006 07:33:01 -0700 (PDT) From: Heilige Gheist Subject: Concurrent mount of XFS over SAN To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 8551 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hgheist@yahoo.com Precedence: bulk X-list: xfs Content-Length: 436 Lines: 14 Is there a way to prevent and/or detect concurrent mount of same XFS SAN-based partition from several nodes? I had to fsck a filesystem losing some data after two nodes happily mounted a filesystem from same SAN-based partition at the same time and wrote into it. Thanks! --alan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-xfs@oss.sgi.com Thu Aug 3 14:40:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Aug 2006 14:40:58 -0700 (PDT) Received: from service.eng.exegy.net (68-191-203-42.static.stls.mo.charter.com [68.191.203.42]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k73LehDW014918 for ; Thu, 3 Aug 2006 14:40:43 -0700 Received: from HANAFORD.eng.exegy.net (hanaford.eng.exegy.net [10.19.1.4]) by service.eng.exegy.net (8.13.1/8.13.1) with ESMTP id k73LeC99026432; Thu, 3 Aug 2006 16:40:12 -0500 Received: from [10.19.4.98] ([10.19.4.98]) by HANAFORD.eng.exegy.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 16:40:15 -0500 Message-ID: <44D26D3E.5010708@exegy.com> Date: Thu, 03 Aug 2006 16:40:14 -0500 From: Dave Lloyd User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Heilige Gheist CC: xfs@oss.sgi.com Subject: Re: Concurrent mount of XFS over SAN References: <20060803143301.51757.qmail@web31704.mail.mud.yahoo.com> In-Reply-To: <20060803143301.51757.qmail@web31704.mail.mud.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2006 21:40:15.0005 (UTC) FILETIME=[67E0CCD0:01C6B745] X-archive-position: 8552 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dlloyd@exegy.com Precedence: bulk X-list: xfs Content-Length: 660 Lines: 26 Heilige Gheist wrote: > Is there a way to prevent and/or detect concurrent mount of same XFS > SAN-based partition from several nodes? > I had to fsck a filesystem losing some data after two nodes happily > mounted a filesystem from same SAN-based partition at the same time and > wrote into it. > Thanks! > > --alan > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > I think that the generally accepted way is to zone at the switch or the storage array. -- Dave Lloyd Test Engineer, Exegy, Inc. 314.450.5342 dlloyd@exegy.com From owner-xfs@oss.sgi.com Thu Aug 3 17:30:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Aug 2006 17:31:18 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k740UdDW012082 for ; Thu, 3 Aug 2006 17:30:51 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26507; Fri, 4 Aug 2006 10:29:56 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k740Trgw2404484; Fri, 4 Aug 2006 10:29:53 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k740To1M2403640; Fri, 4 Aug 2006 10:29:50 +1000 (EST) Date: Fri, 4 Aug 2006 10:29:50 +1000 From: Nathan Scott To: Eric Sandeen Cc: Dan Am , xfs@oss.sgi.com Subject: Re: "xfs_io -c chattr +i " on a symlink Message-ID: <20060804102949.B2401829@wobbly.melbourne.sgi.com> References: <28749.62.159.242.114.1154600816.squirrel@otto.lonx.net> <44D20473.3010304@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44D20473.3010304@sandeen.net>; from sandeen@sandeen.net on Thu, Aug 03, 2006 at 09:13:07AM -0500 X-archive-position: 8554 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 798 Lines: 28 On Thu, Aug 03, 2006 at 09:13:07AM -0500, Eric Sandeen wrote: > Try just using chattr. Or not. :) > [sandeen@sandeen ~]$ ln -s /tmp tmplink > [sandeen@sandeen ~]$ ls -l tmplink > lrwxrwxrwx 1 sandeen sandeen 4 Aug 3 09:05 tmplink -> /tmp > [sandeen@sandeen ~]$ su > Password: > [root@sandeen sandeen]# chattr +i tmplink > [root@sandeen sandeen]# stat -f tmplink > File: "tmplink" > ID: 802 Namelen: 255 Type: XFS (0x58465342) > Blocks: Total: 23377204 Free: 8557099 Available: 8557099 Size: 4096 > Inodes: Total: 93554496 Free: 93202008 > [root@sandeen sandeen]# > [root@sandeen sandeen]# lsattr tmplink > ----i-------- tmplink ... I think you just set immutable on /tmp. Try a broken symlink, instead of one that points to an existing inode. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Aug 3 17:29:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Aug 2006 17:29:46 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k740T5DW011773 for ; Thu, 3 Aug 2006 17:29:17 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26481; Fri, 4 Aug 2006 10:28:19 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k740SHgw2388876; Fri, 4 Aug 2006 10:28:17 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k740SEt92404818; Fri, 4 Aug 2006 10:28:14 +1000 (EST) Date: Fri, 4 Aug 2006 10:28:14 +1000 From: Nathan Scott To: Dan Am Cc: xfs@oss.sgi.com Subject: Re: "xfs_io -c chattr +i " on a symlink Message-ID: <20060804102814.A2401829@wobbly.melbourne.sgi.com> References: <28749.62.159.242.114.1154600816.squirrel@otto.lonx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <28749.62.159.242.114.1154600816.squirrel@otto.lonx.net>; from xfs@lonx.net on Thu, Aug 03, 2006 at 12:26:56PM +0200 X-archive-position: 8553 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 668 Lines: 21 On Thu, Aug 03, 2006 at 12:26:56PM +0200, Dan Am wrote: > (resend, since I used the wrong account to send the initial mail, sorry) > > Dear list, > > I am trying to make a symlink immutable with chattr, however the command > seems to follow the link, which point to a NFS Mount. > Setting xattr works on symlink btw, which is useful. > More data below > Any ideas ? Its not possible to open(2) a symbolic link (see fs/namei.c::may_open), which means you cannot get a file descriptor for a symlink, which means you cannot issue an ioctl(2) to a symlink (which is how the inode flags are set), which means you're out of luck on this one, sorry. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Aug 3 19:38:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Aug 2006 19:39:15 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k742coDW001243 for ; Thu, 3 Aug 2006 19:38:50 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id DC5FE18068C57; Thu, 3 Aug 2006 21:38:21 -0500 (CDT) Message-ID: <44D2B31D.80804@sandeen.net> Date: Thu, 03 Aug 2006 21:38:21 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Nathan Scott Cc: Dan Am , xfs@oss.sgi.com Subject: Re: "xfs_io -c chattr +i " on a symlink References: <28749.62.159.242.114.1154600816.squirrel@otto.lonx.net> <44D20473.3010304@sandeen.net> <20060804102949.B2401829@wobbly.melbourne.sgi.com> In-Reply-To: <20060804102949.B2401829@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8556 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 196 Lines: 10 Nathan Scott wrote: > On Thu, Aug 03, 2006 at 09:13:07AM -0500, Eric Sandeen wrote: >> Try just using chattr. > > Or not. :) Whoops, oh well. Shoulda investigated a bit more I guess :) -Eric From owner-xfs@oss.sgi.com Thu Aug 3 21:20:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Aug 2006 21:21:01 -0700 (PDT) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k744KZDW019952 for ; Thu, 3 Aug 2006 21:20:39 -0700 Received: (qmail 88917 invoked from network); 4 Aug 2006 04:20:05 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 4 Aug 2006 04:20:04 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 61245182727F; Thu, 3 Aug 2006 21:20:03 -0700 (PDT) Date: Thu, 3 Aug 2006 21:20:03 -0700 From: Chris Wedgwood To: Nathan Scott Cc: Dan Am , xfs@oss.sgi.com Subject: Re: "xfs_io -c chattr +i " on a symlink Message-ID: <20060804042003.GA9271@tuatara.stupidest.org> References: <28749.62.159.242.114.1154600816.squirrel@otto.lonx.net> <20060804102814.A2401829@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060804102814.A2401829@wobbly.melbourne.sgi.com> X-archive-position: 8558 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 489 Lines: 11 On Fri, Aug 04, 2006 at 10:28:14AM +1000, Nathan Scott wrote: > Its not possible to open(2) a symbolic link (see > fs/namei.c::may_open), which means you cannot get a file descriptor > for a symlink, which means you cannot issue an ioctl(2) to a symlink > (which is how the inode flags are set), which means you're out of > luck on this one, sorry. I always disliked open/ioctl for this. I think we should actually have a separate syscall for chattr, etc. (FreeBSD does this I think?) From owner-xfs@oss.sgi.com Thu Aug 3 22:22:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Aug 2006 22:23:01 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k745MMDW025643 for ; Thu, 3 Aug 2006 22:22:34 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01291; Fri, 4 Aug 2006 14:17:20 +1000 Message-ID: <44D2CA85.3040208@sgi.com> Date: Fri, 04 Aug 2006 14:18:13 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Russell Cattelan CC: xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump References: <44D10F9B.8090904@thebarn.com> In-Reply-To: <44D10F9B.8090904@thebarn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8559 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 7906 Lines: 291 Hi Russel, I don't understand in details the build changes but they seam to be fine. In summary if the build system can find the DMAPI lib installed it will use hsmapi_noop.c otherwise hsmapi.c. The return code of HsmInitFileContext() stub probably should be non zero. It is looking good. Regards, Vlad Russell Cattelan wrote: > Since very few people run xfs with dmapi enabled it seem kind of silly > to force the install of the dmapi utils/libraries just for xfs > dump/restore. > > This patch stubs out the Hsm functions and adjusts the autoconf > to not fail in the case of missing dmapi headers/libs. > > If somebody does trie to do a dump with the -a option a ERROR message > is issued, the dump does continue? this might not be the desired > behavior. > > ------------------------------------------------------------------------ > > Index: xfs-cmds/xfsdump/aclocal.m4 > =================================================================== > --- xfs-cmds.orig/xfsdump/aclocal.m4 2006-08-02 14:51:34.000000000 -0500 > +++ xfs-cmds/xfsdump/aclocal.m4 2006-08-02 14:58:11.250605250 -0500 > @@ -161,27 +161,31 @@ AC_DEFUN([AC_PACKAGE_NEED_XFS_DMAPI_H], > [ AC_CHECK_HEADERS([xfs/dmapi.h]) > if test "$ac_cv_header_xfs_dmapi_h" != yes; then > echo > - echo 'FATAL ERROR: could not find a valid DMAPI library header.' > - echo 'Install the data migration API (dmapi) development package.' > + echo 'WARNING: could not find a valid DMAPI library header.' > + echo 'xfsdump / xfsrestore will not support dmapi file systems.' > echo 'Alternatively, run "make install-dev" from the dmapi source.' > - exit 1 > fi > ]) > > AC_DEFUN([AC_PACKAGE_NEED_MAKEHANDLE_LIBDM], > - [ AC_CHECK_LIB(dm, dm_make_handle,, [ > + [ AC_CHECK_LIB(dm, dm_make_handle, > + [have_dmapi=true > + libdm="-ldm" > + test -f `pwd`/../dmapi/libdm/libdm.la && \ > + libdm="`pwd`/../dmapi/libdm/libdm.la" > + test -f ${libexecdir}${libdirsuffix}/libdm.la && \ > + libdm="${libexecdir}${libdirsuffix}/libdm.la" > + ], > + [ > echo > - echo 'FATAL ERROR: could not find a valid DMAPI base library.' > - echo 'Install the data migration API (dmapi) library package.' > + echo 'WARNING: could not find a valid DMAPI base library.' > + echo 'xfsdump / xfsrestore will not support dmapi file systems.' > echo 'Alternatively, run "make install" from the dmapi source.' > - exit 1 > + have_dmapi=false > + libdm = "" > ]) > - libdm="-ldm" > - test -f `pwd`/../dmapi/libdm/libdm.la && \ > - libdm="`pwd`/../dmapi/libdm/libdm.la" > - test -f ${libexecdir}${libdirsuffix}/libdm.la && \ > - libdm="${libexecdir}${libdirsuffix}/libdm.la" > AC_SUBST(libdm) > + AC_SUBST(have_dmapi) > ]) > > # > Index: xfs-cmds/xfsdump/common/hsmapi_noop.c > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ xfs-cmds/xfsdump/common/hsmapi_noop.c 2006-08-02 15:38:39.046333000 -0500 > @@ -0,0 +1,147 @@ > +/* > + * Copyright (c) 2000-2004 Silicon Graphics, Inc. > + * All Rights Reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it would be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > +#include > +#include > +#include > + > +#include "hsmapi.h" > +#include "mlog.h" > +#include "exit.h" > + > +typedef struct { > +} dmf_fs_ctxt_t; > + > +extern hsm_fs_ctxt_t * > +HsmInitFsysContext( > +const char *mountpoint, > + int dumpversion) > +{ > + mlog( MLOG_NORMAL | MLOG_ERROR, _( > + "-%c Dumping of DMF dualstate file not supported in this version\n")); > + return NULL; > +} > + > +extern void > +HsmDeleteFsysContext( > + hsm_fs_ctxt_t *contextp) > +{ > +} > + > +extern int > +HsmEstimateFileSpace( > + hsm_fs_ctxt_t *contextp, > +const xfs_bstat_t *statp, > + off64_t *bytes) > +{ > + return 0; > +} > + > +extern int > +HsmEstimateFileOffset( > + hsm_fs_ctxt_t *contextp, > +const xfs_bstat_t *statp, > + off64_t bytecount, > + off64_t *byteoffset) > +{ > + return 0; > +} > + > +extern hsm_f_ctxt_t * > +HsmAllocateFileContext( > + hsm_fs_ctxt_t *contextp) > +{ > + return NULL; > +} > + > +extern void > +HsmDeleteFileContext( > + hsm_f_ctxt_t *contextp) > +{ > +} > + > +extern int > +HsmInitFileContext( > + hsm_f_ctxt_t *contextp, > +const xfs_bstat_t *statp) > +{ > + return 0; > +} > + > +extern int > +HsmModifyInode( > + hsm_f_ctxt_t *contextp, > + xfs_bstat_t *statp) > +{ > + return 0; > +} > + > +extern int > +HsmModifyExtentMap( > + hsm_f_ctxt_t *contextp, > + struct getbmapx *bmap) > +{ > + return 0; > +} > + > +extern int > +HsmFilterExistingAttribute( > + hsm_f_ctxt_t *hsm_f_ctxtp, > +const char *namep, /* attribute name */ > + u_int32_t valuesz, /* value size */ > + int flag, > + int *skip_entry) > +{ > + return 0; > +} > + > +extern int > +HsmAddNewAttribute( > + hsm_f_ctxt_t *hsm_f_ctxtp, > + int cursor, > + int flag, > + char **namepp, /* pointer to new attribute name */ > + char **valuepp, /* pointer to its value */ > + u_int32_t *valueszp) /* pointer to the value size */ > +{ > + return 0; > +} > + > +extern void > +HsmBeginRestoreFile( > + bstat_t *bstatp, > + int fd, > + int *hsm_flagp) > +{ > +} > + > +extern void > +HsmRestoreAttribute( > + int flag, /* ext attr flags */ > + char *namep, /* pointer to new attribute name */ > + int *hsm_flagp) > +{ > +} > + > +extern void > +HsmEndRestoreFile( > + char *path, > + int fd, > + int *hsm_flagp) > +{ > +} > Index: xfs-cmds/xfsdump/dump/Makefile > =================================================================== > --- xfs-cmds.orig/xfsdump/dump/Makefile 2006-08-02 14:51:34.000000000 -0500 > +++ xfs-cmds/xfsdump/dump/Makefile 2006-08-02 14:52:15.076345750 -0500 > @@ -57,7 +57,6 @@ COMMON = \ > fs.c \ > getdents.c \ > global.c \ > - hsmapi.c \ > lock.c \ > main.c \ > mlog.c \ > @@ -69,6 +68,12 @@ COMMON = \ > util.c \ > sproc.c > > +ifeq ($(HAVE_DMAPI), true) > + COMMON += hsmapi.c > +else > + COMMON += hsmapi_noop.c > +endif > + > LOCALS = \ > content.c \ > inomap.c \ > Index: xfs-cmds/xfsdump/include/builddefs.in > =================================================================== > --- xfs-cmds.orig/xfsdump/include/builddefs.in 2006-08-02 14:51:34.000000000 -0500 > +++ xfs-cmds/xfsdump/include/builddefs.in 2006-08-02 14:52:15.080346000 -0500 > @@ -66,6 +66,8 @@ ENABLE_GETTEXT = @enable_gettext@ > > HAVE_ZIPPED_MANPAGES = @have_zipped_manpages@ > > +HAVE_DMAPI = @have_dmapi@ > + > LCFLAGS += -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 > > ifeq ($(PKG_PLATFORM),linux) > Index: xfs-cmds/xfsdump/restore/Makefile > =================================================================== > --- xfs-cmds.orig/xfsdump/restore/Makefile 2006-08-02 14:51:34.000000000 -0500 > +++ xfs-cmds/xfsdump/restore/Makefile 2006-08-02 14:52:15.080346000 -0500 > @@ -55,7 +55,6 @@ COMMON = \ > fs.c \ > getdents.c \ > global.c \ > - hsmapi.c \ > lock.c \ > main.c \ > mlog.c \ > @@ -67,6 +66,12 @@ COMMON = \ > stream.c \ > util.c > > +ifeq ($(HAVE_DMAPI), true) > + COMMON += hsmapi.c > +else > + COMMON += hsmapi_noop.c > +endif > + > LOCALS = \ > bag.c \ > content.c \ > From owner-xfs@oss.sgi.com Fri Aug 4 01:15:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 01:16:05 -0700 (PDT) Received: from otto.lonx.net (work.lonx.net [195.243.240.241]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k748FpDW016266 for ; Fri, 4 Aug 2006 01:15:52 -0700 Received: from localhost (localhost [127.0.0.1]) by otto.lonx.net (Postfix) with ESMTP id A79A12621 for ; Fri, 4 Aug 2006 10:15:23 +0200 (CEST) Received: from otto.lonx.net ([127.0.0.1]) by localhost (otto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28698-07 for ; Fri, 4 Aug 2006 10:15:19 +0200 (CEST) Received: from otto.lonx.net (localhost [127.0.0.1]) by otto.lonx.net (Postfix) with ESMTP id 6A5FD2619 for ; Fri, 4 Aug 2006 10:15:19 +0200 (CEST) Received: from 62.159.242.114 (SquirrelMail authenticated user danam) by otto.lonx.net with HTTP; Fri, 4 Aug 2006 10:15:19 +0200 (CEST) Message-ID: <39340.62.159.242.114.1154679319.squirrel@otto.lonx.net> Date: Fri, 4 Aug 2006 10:15:19 +0200 (CEST) Subject: Re: "xfs_io -c chattr +i " on a symlink From: "Dan Am" To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-archive-position: 8560 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xfs@lonx.net Precedence: bulk X-list: xfs Content-Length: 330 Lines: 13 On Fri, August 4, 2006 6:20 am, Chris Wedgwood wrote: > I always disliked open/ioctl for this. I think we should actually have a separate syscall for chattr, etc. (FreeBSD does this I think?) So how does "attr -s someAttribute symlink" work ? This does the job very well, distinguishing it from other filesystems. Best Dan From owner-xfs@oss.sgi.com Fri Aug 4 02:16:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 02:16:25 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k749FwDW023218 for ; Fri, 4 Aug 2006 02:16:10 -0700 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA06739; Fri, 4 Aug 2006 19:15:15 +1000 Message-ID: <44D30FAD.5070704@sgi.com> Date: Fri, 04 Aug 2006 19:13:17 +1000 From: Timothy Shimmin User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Am CC: xfs@oss.sgi.com Subject: Re: "xfs_io -c chattr +i " on a symlink References: <39340.62.159.242.114.1154679319.squirrel@otto.lonx.net> In-Reply-To: <39340.62.159.242.114.1154679319.squirrel@otto.lonx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8561 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 685 Lines: 19 Dan Am wrote: > On Fri, August 4, 2006 6:20 am, Chris Wedgwood wrote: >> I always disliked open/ioctl for this. I think we should actually have >> a separate syscall for chattr, etc. (FreeBSD does this I think?) > > So how does "attr -s someAttribute symlink" work ? This does the job very > well, distinguishing it from other filesystems. > attr(1) sets the extended attribute and they are set by system calls. It looks like you would need the -L option to attr(1) which ends up calling the lsetxattr() syscall via the libattr library. (Inode attributes shouldn't be confused with extended attributes, EAs, - a cause of much confusion for me and others in the past :) --Tim From owner-xfs@oss.sgi.com Fri Aug 4 03:06:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 03:07:23 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k74A6fDW029596 for ; Fri, 4 Aug 2006 03:06:52 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA07719; Fri, 4 Aug 2006 20:05:57 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k74A5rgw2415315; Fri, 4 Aug 2006 20:05:54 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k74A5oIf2414840; Fri, 4 Aug 2006 20:05:50 +1000 (EST) Date: Fri, 4 Aug 2006 20:05:50 +1000 From: Nathan Scott To: jesper.juhl@gmail.com Cc: Linux Kernel Mailing List , xfs@oss.sgi.com Subject: Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078 Message-ID: <20060804200549.A2414667@wobbly.melbourne.sgi.com> References: <9a8748490608040122l69ff139dtaae27e8981022dae@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9a8748490608040122l69ff139dtaae27e8981022dae@mail.gmail.com>; from jesper.juhl@gmail.com on Fri, Aug 04, 2006 at 10:22:21AM +0200 X-archive-position: 8562 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 963 Lines: 36 On Fri, Aug 04, 2006 at 10:22:21AM +0200, Jesper Juhl wrote: > I just hit a BUG that looks XFS related. > > The machine is running 2.6.18-rc3-git3 > > (more info below the BUG messages) > Thanks for reporting, Jesper - is it reproducible? Could you try this patch for me? We had a couple of other reports of this, but the earlier reporters have vanished ... could you let me know if this helps? cheers. -- Nathan --- fs/xfs/xfs_alloc.c.orig 2006-08-04 20:00:34.333456250 +1000 +++ fs/xfs/xfs_alloc.c 2006-08-04 20:00:50.586472000 +1000 @@ -1949,14 +1949,8 @@ xfs_alloc_fix_freelist( * the restrictions correctly. Can happen for free calls * on a completely full ag. */ - if (targs.agbno == NULLAGBLOCK) { - if (!(flags & XFS_ALLOC_FLAG_FREEING)) { - xfs_trans_brelse(tp, agflbp); - args->agbp = NULL; - return 0; - } + if (targs.agbno == NULLAGBLOCK) break; - } /* * Put each allocated block on the list. */ From owner-xfs@oss.sgi.com Fri Aug 4 03:44:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 03:44:44 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k74AiMDW003405 for ; Fri, 4 Aug 2006 03:44:23 -0700 Received: by nf-out-0910.google.com with SMTP id k26so611891nfc for ; Fri, 04 Aug 2006 03:43:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TE8tMUKj1+8qOQCHAIljcyE9KSh6zVj1z4GjT5Yebaz+GnnXCCaFsYl5RkgwsImviq9sDtbL1sVYESY+XHQXCX/xI+RNrMdjH6Ko1Hrs4VFpiuRLlZ1hWUwtbkPuaaake+uV3C+BNHiPBiZgSR6BYwXAKeW4WmoEjhabADF/ZPU= Received: by 10.78.122.11 with SMTP id u11mr777936huc; Fri, 04 Aug 2006 03:43:55 -0700 (PDT) Received: by 10.78.160.13 with HTTP; Fri, 4 Aug 2006 03:43:54 -0700 (PDT) Message-ID: <9a8748490608040343p472591b8n9856f4afd78c9dfa@mail.gmail.com> Date: Fri, 4 Aug 2006 12:43:54 +0200 From: "Jesper Juhl" To: "Nathan Scott" Subject: Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078 Cc: "Linux Kernel Mailing List" , xfs@oss.sgi.com In-Reply-To: <20060804200549.A2414667@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9a8748490608040122l69ff139dtaae27e8981022dae@mail.gmail.com> <20060804200549.A2414667@wobbly.melbourne.sgi.com> X-archive-position: 8563 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jesper.juhl@gmail.com Precedence: bulk X-list: xfs Content-Length: 1429 Lines: 44 On 04/08/06, Nathan Scott wrote: > On Fri, Aug 04, 2006 at 10:22:21AM +0200, Jesper Juhl wrote: > > I just hit a BUG that looks XFS related. > > > > The machine is running 2.6.18-rc3-git3 > > > > (more info below the BUG messages) > > > > Thanks for reporting, Jesper - is it reproducible? I don't know. I only tried that kernel once and when it broke on me went back to the previous 2.6.11 kernel it was running before. > Could you try this > patch for me? Sure. The machine is semi-production, so there are limits to how much and when I can test on it. roughly wednesday and thursday each week I should be able to run experimental kernels on it, the rest of the week the box needs to be stable. > We had a couple of other reports of this, but the earlier > reporters have vanished ... could you let me know if this helps? > What I'll do is apply that patch to the 2.6.18-rc3-git3 kernel that BUG'ed on me, then wednesday next week I'll boot the machine with the patched kernel and it should be able to run for ~24hrs, then I can report back to you if it crashed or not. Or is there some other way you'd rather have me do it (subject to the constraint that I can only do experiments one and a half to two days a week) ? -- Jesper Juhl Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html From owner-xfs@oss.sgi.com Fri Aug 4 04:38:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 04:38:23 -0700 (PDT) Received: from otto.lonx.net (work.lonx.net [195.243.240.241]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k74Bc6DW013390 for ; Fri, 4 Aug 2006 04:38:07 -0700 Received: from localhost (localhost [127.0.0.1]) by otto.lonx.net (Postfix) with ESMTP id 19826261F for ; Fri, 4 Aug 2006 13:37:34 +0200 (CEST) Received: from otto.lonx.net ([127.0.0.1]) by localhost (otto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30432-08 for ; Fri, 4 Aug 2006 13:37:32 +0200 (CEST) Received: from otto.lonx.net (localhost [127.0.0.1]) by otto.lonx.net (Postfix) with ESMTP id B57112619 for ; Fri, 4 Aug 2006 13:37:32 +0200 (CEST) Received: from 62.159.242.114 (SquirrelMail authenticated user danam) by otto.lonx.net with HTTP; Fri, 4 Aug 2006 13:37:32 +0200 (CEST) Message-ID: <48367.62.159.242.114.1154691452.squirrel@otto.lonx.net> In-Reply-To: <20060804102949.B2401829@wobbly.melbourne.sgi.com> References: <28749.62.159.242.114.1154600816.squirrel@otto.lonx.net> <44D20473.3010304@sandeen.net> <20060804102949.B2401829@wobbly.melbourne.sgi.com> Date: Fri, 4 Aug 2006 13:37:32 +0200 (CEST) Subject: Re: "xfs_io -c chattr +i " on a symlink From: "Dan Am" To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-archive-position: 8564 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xfs@lonx.net Precedence: bulk X-list: xfs Content-Length: 378 Lines: 17 On Fri, August 4, 2006 2:29 am, Nathan Scott wrote: > ... I think you just set immutable on /tmp. Try a broken symlink, > instead of one that points to an existing inode. Nope: /data/tara-test > ls -l test lrwxr-xr-x 1 root root 13 Aug 4 13:33 test -> /archive/no-such-file /data/tara-test > xfs_io -c "chattr +i" test test: No such file or directory Best Regards Dan From owner-xfs@oss.sgi.com Fri Aug 4 07:10:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 07:12:13 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k74EAgDW029242 for ; Fri, 4 Aug 2006 07:10:42 -0700 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k74EADoI018171 for ; Fri, 4 Aug 2006 08:10:13 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k74E6e72018470 for ; Fri, 4 Aug 2006 08:06:40 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3) with ESMTP id k74EACe6000041; Fri, 4 Aug 2006 09:10:12 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3/Submit) id k74EACFn000040; Fri, 4 Aug 2006 09:10:12 -0500 (CDT) Date: Fri, 4 Aug 2006 09:10:12 -0500 From: Dean Roehrich To: Vlad Apostolov Cc: Russell Cattelan , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump Message-ID: <20060804141012.GA26@kickball-mn.Central.Sun.COM> References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D2CA85.3040208@sgi.com> User-Agent: Mutt/1.5.9i X-archive-position: 8565 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dean.roehrich@sun.com Precedence: bulk X-list: xfs Content-Length: 864 Lines: 24 On Fri, Aug 04, 2006 at 02:18:13PM +1000, Vlad Apostolov wrote: > Hi Russel, > > I don't understand in details the build changes but they seam to be fine. Vlad, why do they seem fine? > In summary if the build system can find the DMAPI lib installed it will > use hsmapi_noop.c otherwise hsmapi.c. > The return code of HsmInitFileContext() stub probably should be non zero. > > It is looking good. So this is determined at build time...so when you're using a version of xfsdump/xfsrestore how do you know you're _not_ using one that is DMAPI-aware _before_ you get into trouble with an invalid dump? Assuming that issue is addressed, here's another: The libdm is a shared object, so why not take advantage of that and load it with dlopen? Then the issue is determined at runtime rather than build time. This is easy, and even DMF does it this way. Dean From owner-xfs@oss.sgi.com Fri Aug 4 07:25:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 07:25:44 -0700 (PDT) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k74EPHDW030500 for ; Fri, 4 Aug 2006 07:25:29 -0700 Received: from [192.168.0.13] (cf-vpn-sw-corp-64-61.corp.sgi.com [134.15.64.61]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k74EVkDu44432002; Fri, 4 Aug 2006 07:31:46 -0700 (PDT) Message-ID: <44D35885.8070507@sgi.com> Date: Fri, 04 Aug 2006 09:24:05 -0500 From: Bill Kendall User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russell Cattelan CC: xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump References: <44D10F9B.8090904@thebarn.com> In-Reply-To: <44D10F9B.8090904@thebarn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8566 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 8351 Lines: 295 I'm concerned about distributions inadvertently turning off dmapi support in their xfsdump builds. An explicit ./configure switch to disable dmapi support would be better, IMHO. But either way it would be a build-time decision rather than a run-time decision. xfsdump only uses one DMAPI call (dm_make_handle), so this could easily be done with dlopen/dlsym, and this would eliminate the dmapi requirement for those not using -a. dmapi would still be a build requirement for xfsdump. Ideally, hsmapi.c wouldn't even exist in xfsdump -- the current implementation belongs in DMF. There should be a plugin mechanism added to xfsdump to allow the loading libraries that implement the API in hsmapi.c (though that interface needs some work first). Bill Russell Cattelan wrote: > Since very few people run xfs with dmapi enabled it seem kind of silly > to force the install of the dmapi utils/libraries just for xfs > dump/restore. > > This patch stubs out the Hsm functions and adjusts the autoconf > to not fail in the case of missing dmapi headers/libs. > > If somebody does trie to do a dump with the -a option a ERROR message > is issued, the dump does continue? this might not be the desired behavior. > > > ------------------------------------------------------------------------ > > Index: xfs-cmds/xfsdump/aclocal.m4 > =================================================================== > --- xfs-cmds.orig/xfsdump/aclocal.m4 2006-08-02 14:51:34.000000000 -0500 > +++ xfs-cmds/xfsdump/aclocal.m4 2006-08-02 14:58:11.250605250 -0500 > @@ -161,27 +161,31 @@ AC_DEFUN([AC_PACKAGE_NEED_XFS_DMAPI_H], > [ AC_CHECK_HEADERS([xfs/dmapi.h]) > if test "$ac_cv_header_xfs_dmapi_h" != yes; then > echo > - echo 'FATAL ERROR: could not find a valid DMAPI library header.' > - echo 'Install the data migration API (dmapi) development package.' > + echo 'WARNING: could not find a valid DMAPI library header.' > + echo 'xfsdump / xfsrestore will not support dmapi file systems.' > echo 'Alternatively, run "make install-dev" from the dmapi source.' > - exit 1 > fi > ]) > > AC_DEFUN([AC_PACKAGE_NEED_MAKEHANDLE_LIBDM], > - [ AC_CHECK_LIB(dm, dm_make_handle,, [ > + [ AC_CHECK_LIB(dm, dm_make_handle, > + [have_dmapi=true > + libdm="-ldm" > + test -f `pwd`/../dmapi/libdm/libdm.la && \ > + libdm="`pwd`/../dmapi/libdm/libdm.la" > + test -f ${libexecdir}${libdirsuffix}/libdm.la && \ > + libdm="${libexecdir}${libdirsuffix}/libdm.la" > + ], > + [ > echo > - echo 'FATAL ERROR: could not find a valid DMAPI base library.' > - echo 'Install the data migration API (dmapi) library package.' > + echo 'WARNING: could not find a valid DMAPI base library.' > + echo 'xfsdump / xfsrestore will not support dmapi file systems.' > echo 'Alternatively, run "make install" from the dmapi source.' > - exit 1 > + have_dmapi=false > + libdm = "" > ]) > - libdm="-ldm" > - test -f `pwd`/../dmapi/libdm/libdm.la && \ > - libdm="`pwd`/../dmapi/libdm/libdm.la" > - test -f ${libexecdir}${libdirsuffix}/libdm.la && \ > - libdm="${libexecdir}${libdirsuffix}/libdm.la" > AC_SUBST(libdm) > + AC_SUBST(have_dmapi) > ]) > > # > Index: xfs-cmds/xfsdump/common/hsmapi_noop.c > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ xfs-cmds/xfsdump/common/hsmapi_noop.c 2006-08-02 15:38:39.046333000 -0500 > @@ -0,0 +1,147 @@ > +/* > + * Copyright (c) 2000-2004 Silicon Graphics, Inc. > + * All Rights Reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it would be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > +#include > +#include > +#include > + > +#include "hsmapi.h" > +#include "mlog.h" > +#include "exit.h" > + > +typedef struct { > +} dmf_fs_ctxt_t; > + > +extern hsm_fs_ctxt_t * > +HsmInitFsysContext( > +const char *mountpoint, > + int dumpversion) > +{ > + mlog( MLOG_NORMAL | MLOG_ERROR, _( > + "-%c Dumping of DMF dualstate file not supported in this version\n")); > + return NULL; > +} > + > +extern void > +HsmDeleteFsysContext( > + hsm_fs_ctxt_t *contextp) > +{ > +} > + > +extern int > +HsmEstimateFileSpace( > + hsm_fs_ctxt_t *contextp, > +const xfs_bstat_t *statp, > + off64_t *bytes) > +{ > + return 0; > +} > + > +extern int > +HsmEstimateFileOffset( > + hsm_fs_ctxt_t *contextp, > +const xfs_bstat_t *statp, > + off64_t bytecount, > + off64_t *byteoffset) > +{ > + return 0; > +} > + > +extern hsm_f_ctxt_t * > +HsmAllocateFileContext( > + hsm_fs_ctxt_t *contextp) > +{ > + return NULL; > +} > + > +extern void > +HsmDeleteFileContext( > + hsm_f_ctxt_t *contextp) > +{ > +} > + > +extern int > +HsmInitFileContext( > + hsm_f_ctxt_t *contextp, > +const xfs_bstat_t *statp) > +{ > + return 0; > +} > + > +extern int > +HsmModifyInode( > + hsm_f_ctxt_t *contextp, > + xfs_bstat_t *statp) > +{ > + return 0; > +} > + > +extern int > +HsmModifyExtentMap( > + hsm_f_ctxt_t *contextp, > + struct getbmapx *bmap) > +{ > + return 0; > +} > + > +extern int > +HsmFilterExistingAttribute( > + hsm_f_ctxt_t *hsm_f_ctxtp, > +const char *namep, /* attribute name */ > + u_int32_t valuesz, /* value size */ > + int flag, > + int *skip_entry) > +{ > + return 0; > +} > + > +extern int > +HsmAddNewAttribute( > + hsm_f_ctxt_t *hsm_f_ctxtp, > + int cursor, > + int flag, > + char **namepp, /* pointer to new attribute name */ > + char **valuepp, /* pointer to its value */ > + u_int32_t *valueszp) /* pointer to the value size */ > +{ > + return 0; > +} > + > +extern void > +HsmBeginRestoreFile( > + bstat_t *bstatp, > + int fd, > + int *hsm_flagp) > +{ > +} > + > +extern void > +HsmRestoreAttribute( > + int flag, /* ext attr flags */ > + char *namep, /* pointer to new attribute name */ > + int *hsm_flagp) > +{ > +} > + > +extern void > +HsmEndRestoreFile( > + char *path, > + int fd, > + int *hsm_flagp) > +{ > +} > Index: xfs-cmds/xfsdump/dump/Makefile > =================================================================== > --- xfs-cmds.orig/xfsdump/dump/Makefile 2006-08-02 14:51:34.000000000 -0500 > +++ xfs-cmds/xfsdump/dump/Makefile 2006-08-02 14:52:15.076345750 -0500 > @@ -57,7 +57,6 @@ COMMON = \ > fs.c \ > getdents.c \ > global.c \ > - hsmapi.c \ > lock.c \ > main.c \ > mlog.c \ > @@ -69,6 +68,12 @@ COMMON = \ > util.c \ > sproc.c > > +ifeq ($(HAVE_DMAPI), true) > + COMMON += hsmapi.c > +else > + COMMON += hsmapi_noop.c > +endif > + > LOCALS = \ > content.c \ > inomap.c \ > Index: xfs-cmds/xfsdump/include/builddefs.in > =================================================================== > --- xfs-cmds.orig/xfsdump/include/builddefs.in 2006-08-02 14:51:34.000000000 -0500 > +++ xfs-cmds/xfsdump/include/builddefs.in 2006-08-02 14:52:15.080346000 -0500 > @@ -66,6 +66,8 @@ ENABLE_GETTEXT = @enable_gettext@ > > HAVE_ZIPPED_MANPAGES = @have_zipped_manpages@ > > +HAVE_DMAPI = @have_dmapi@ > + > LCFLAGS += -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 > > ifeq ($(PKG_PLATFORM),linux) > Index: xfs-cmds/xfsdump/restore/Makefile > =================================================================== > --- xfs-cmds.orig/xfsdump/restore/Makefile 2006-08-02 14:51:34.000000000 -0500 > +++ xfs-cmds/xfsdump/restore/Makefile 2006-08-02 14:52:15.080346000 -0500 > @@ -55,7 +55,6 @@ COMMON = \ > fs.c \ > getdents.c \ > global.c \ > - hsmapi.c \ > lock.c \ > main.c \ > mlog.c \ > @@ -67,6 +66,12 @@ COMMON = \ > stream.c \ > util.c > > +ifeq ($(HAVE_DMAPI), true) > + COMMON += hsmapi.c > +else > + COMMON += hsmapi_noop.c > +endif > + > LOCALS = \ > bag.c \ > content.c \ From owner-xfs@oss.sgi.com Fri Aug 4 08:36:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 08:37:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k74FafDW010589 for ; Fri, 4 Aug 2006 08:36:41 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k74Fa8IM003442; Fri, 4 Aug 2006 11:36:08 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k74Fa8LS012584; Fri, 4 Aug 2006 11:36:08 -0400 Received: from [10.15.80.54] (xenon.msp.redhat.com [10.15.80.54]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k74Fa7Yv031563; Fri, 4 Aug 2006 11:36:08 -0400 Message-ID: <44D36985.1090006@thebarn.com> Date: Fri, 04 Aug 2006 10:36:37 -0500 From: Russell Cattelan User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Dean Roehrich CC: Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> In-Reply-To: <20060804141012.GA26@kickball-mn.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8567 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 1885 Lines: 53 Dean Roehrich wrote: > On Fri, Aug 04, 2006 at 02:18:13PM +1000, Vlad Apostolov wrote: > >> Hi Russel, >> >> I don't understand in details the build changes but they seam to be fine. >> > > Vlad, why do they seem fine? > > >> In summary if the build system can find the DMAPI lib installed it will >> use hsmapi_noop.c otherwise hsmapi.c. >> The return code of HsmInitFileContext() stub probably should be non zero. >> >> It is looking good. >> > > So this is determined at build time...so when you're using a version of > xfsdump/xfsrestore how do you know you're _not_ using one that is DMAPI-aware > _before_ you get into trouble with an invalid dump? > I appears as if the Hsm routines are only used if the -a flag is given to xfsdump. (dump DMF dualstate files as offline) From what I can tell the only users that will need the HSM routines would be Suse based installs or somebody doing a custom kernel with the xfs-tree from oss. Anybody running with a kernel.org kernel would have no need for dmapi support in xfs dump/restore. (This includes the Fedora kernel with currently does does build the xfsdump package) Under the current scheme in order to get xfsdump at all you need to build and install the dmapi and dmapi-devel packages, which seemed kinda silly to me on system that don't have the kernel support for dmapi. So basically I just stubbed out the Hsm functions is the case of no dmapi libraries The dlopen is a good idea but still requires that build machine has the dmapi libraries installed which seems like extra work if they are never going to be used. > Assuming that issue is addressed, here's another: The libdm is a shared > object, so why not take advantage of that and load it with dlopen? Then the > issue is determined at runtime rather than build time. This is easy, and even > DMF does it this way. > > Dean > > From owner-xfs@oss.sgi.com Fri Aug 4 08:59:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 08:59:40 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k74FxGDW015825 for ; Fri, 4 Aug 2006 08:59:17 -0700 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k74FwonQ029503 for ; Fri, 4 Aug 2006 09:58:50 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k74FtHP9002832 for ; Fri, 4 Aug 2006 09:55:17 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3) with ESMTP id k74FwoWk003344; Fri, 4 Aug 2006 10:58:50 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3/Submit) id k74FwoOQ003343; Fri, 4 Aug 2006 10:58:50 -0500 (CDT) Date: Fri, 4 Aug 2006 10:58:50 -0500 From: Dean Roehrich To: Russell Cattelan Cc: Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump Message-ID: <20060804155850.GA3338@kickball-mn.Central.Sun.COM> References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D36985.1090006@thebarn.com> User-Agent: Mutt/1.5.9i X-archive-position: 8568 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dean.roehrich@sun.com Precedence: bulk X-list: xfs Content-Length: 350 Lines: 15 On Fri, Aug 04, 2006 at 10:36:37AM -0500, Russell Cattelan wrote: > I appears as if the Hsm routines are only used if the -a flag is given > to xfsdump. > (dump DMF dualstate files as offline) If use of -a causes xfsdump to fail then that may be sufficient. Also, use of -D should cause xfsrestore to fail. That might cover my concerns. Dean From owner-xfs@oss.sgi.com Fri Aug 4 09:46:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 09:46:31 -0700 (PDT) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k74Gk5DW030249 for ; Fri, 4 Aug 2006 09:46:16 -0700 Received: from [192.168.0.13] (cf-vpn-sw-corp-64-61.corp.sgi.com [134.15.64.61]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k74GqXDu44457460; Fri, 4 Aug 2006 09:52:34 -0700 (PDT) Message-ID: <44D379A6.9040200@sgi.com> Date: Fri, 04 Aug 2006 11:45:26 -0500 From: Bill Kendall User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Roehrich CC: Russell Cattelan , Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> In-Reply-To: <20060804155850.GA3338@kickball-mn.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8569 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 1599 Lines: 44 Dean Roehrich wrote: > On Fri, Aug 04, 2006 at 10:36:37AM -0500, Russell Cattelan wrote: > > >>I appears as if the Hsm routines are only used if the -a flag is given >>to xfsdump. >>(dump DMF dualstate files as offline) > > > If use of -a causes xfsdump to fail then that may be sufficient. Then what? Each user (admittedly, this is a small number) has to rebuild xfsdump locally, and then do so every time their package manager grabs an updated xfsdump? That sounds like more of an inconvenience than installing a couple packages on a build machine, especially considering the xfsdump and libdm source are bundled together with all the other xfs user space tools. (And isn't there logic in the xfs makefiles to use the locally built libraries if the required libraries aren't installed?) > > Also, use of -D should cause xfsrestore to fail. That's not necessary - there are no libdm calls in xfsrestore, regardless of whether or not the image being restore came from xfsdump -a. There are several solutions here: 1) Russell's proposal -- noop hsm routines if libdm doesn't exist on build machine. 2) Require libdm on build machine, change xfsdump to dlopen libdm so that libdm is optional at run-time. 3) Add make_handle() routine to libhandle. xfsdump's only dependencies from libdm are dm_make_handle() and dm_handle_to_fsid() (the latter of which is in libhandle as handle_to_fshandle(), I think). 4) Noop the existing hsm routines, and allow xfsdump to dlopen a specified .so to override the default (noop) behavior. DMF could then ship a .so implementing those functions. Bill From owner-xfs@oss.sgi.com Fri Aug 4 10:09:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 10:09:46 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k74H9ODW004772 for ; Fri, 4 Aug 2006 10:09:25 -0700 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k74H8uAE017554 for ; Fri, 4 Aug 2006 11:08:56 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k74H8uQw010738 for ; Fri, 4 Aug 2006 11:08:56 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3) with ESMTP id k74H8uQt003732; Fri, 4 Aug 2006 12:08:56 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3/Submit) id k74H8uwd003731; Fri, 4 Aug 2006 12:08:56 -0500 (CDT) Date: Fri, 4 Aug 2006 12:08:56 -0500 From: Dean Roehrich To: Bill Kendall Cc: Russell Cattelan , Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump Message-ID: <20060804170856.GA3652@kickball-mn.Central.Sun.COM> References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> <44D379A6.9040200@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D379A6.9040200@sgi.com> User-Agent: Mutt/1.5.9i X-archive-position: 8570 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dean.roehrich@sun.com Precedence: bulk X-list: xfs Content-Length: 475 Lines: 15 On Fri, Aug 04, 2006 at 11:45:26AM -0500, Bill Kendall wrote: > 3) Add make_handle() routine to libhandle. xfsdump's only dependencies > from libdm are dm_make_handle() and dm_handle_to_fsid() (the latter > of which is in libhandle as handle_to_fshandle(), I think). If libhandle can satisfy everything then that would be a suitable solution. If Russell wants this changed bad enough then I'm sure he'll get around to submitting another patch for it someday... :) Dean From owner-xfs@oss.sgi.com Fri Aug 4 10:33:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 10:34:15 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k74HXpDW010186 for ; Fri, 4 Aug 2006 10:33:51 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 1BBCA18068C57; Fri, 4 Aug 2006 12:33:23 -0500 (CDT) Message-ID: <44D384E2.5080702@sandeen.net> Date: Fri, 04 Aug 2006 12:33:22 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Bill Kendall Cc: Dean Roehrich , Russell Cattelan , Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> <44D379A6.9040200@sgi.com> In-Reply-To: <44D379A6.9040200@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8571 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1123 Lines: 29 Bill Kendall wrote: > Dean Roehrich wrote: >> On Fri, Aug 04, 2006 at 10:36:37AM -0500, Russell Cattelan wrote: >> >> >>> I appears as if the Hsm routines are only used if the -a flag is >>> given to xfsdump. >>> (dump DMF dualstate files as offline) >> >> >> If use of -a causes xfsdump to fail then that may be sufficient. > > Then what? Each user (admittedly, this is a small number) has to rebuild > xfsdump locally, and then do so every time their package manager grabs > an updated xfsdump? Well... if you're using SLES or ProPack or whatever, -a will work fine, when you get updates from your dmapi-supporting distro it will continue to work fine... But if you're using fedora or whatnot, -a will return a (hopefully helpful) error message and quit, and if you -really- want to use dmapi, you'll have to build a custom kernel and dmapi userspace anyway. Rebuilding xfsprogs to go with it doesn't seem like too big a deal... In such a scenario you'd tell your package manager to exclude both kernel & xfsprogs. Anyway, other proposals also seem reasonable, so I won't push this point too much :) -Eric From owner-xfs@oss.sgi.com Fri Aug 4 11:09:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 11:09:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k74I90DW017761 for ; Fri, 4 Aug 2006 11:09:03 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k74I8S6Z022986; Fri, 4 Aug 2006 14:08:28 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k74I8NAm020811; Fri, 4 Aug 2006 14:08:23 -0400 Received: from [10.15.80.54] (xenon.msp.redhat.com [10.15.80.54]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k74I8MaP006410; Fri, 4 Aug 2006 14:08:22 -0400 Message-ID: <44D38D34.1010503@thebarn.com> Date: Fri, 04 Aug 2006 13:08:52 -0500 From: Russell Cattelan User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Bill Kendall CC: Dean Roehrich , Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> <44D379A6.9040200@sgi.com> In-Reply-To: <44D379A6.9040200@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8572 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 1092 Lines: 30 Bill Kendall wrote: [snip] > > 3) Add make_handle() routine to libhandle. xfsdump's only dependencies > from libdm are dm_make_handle() and dm_handle_to_fsid() (the latter > of which is in libhandle as handle_to_fshandle(), I think). Hmm looking at dm_handle_to_fsid: it calls parse_handle which appears be quite dmapi specific and would require much of dm_handle.c? I suppose we could move dm_handle.c into libhandle ? But that seems to be going in the wrong direction in terms of correct code compartmentalization. Since dmapi is only available on Suse , Propack and somebody doing a custom kernel, I'm not convinced that xfs dump/restore should support dmapi no matter what. The only time a problem might arise is somebody not using the shipped version of xfs dump/restore on a Suse or propack system, in which case they should either know what they are doing or get what they deserve. > > 4) Noop the existing hsm routines, and allow xfsdump to dlopen a > specified .so to override the default (noop) behavior. DMF could > then ship a .so implementing those functions. > > Bill > From owner-xfs@oss.sgi.com Fri Aug 4 15:01:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 15:02:00 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k74M1YDW011917 for ; Fri, 4 Aug 2006 15:01:44 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k74M0vnx022982 for ; Fri, 4 Aug 2006 17:00:57 -0500 Received: from [192.168.0.13] (cf-vpn-sw-corp-64-61.corp.sgi.com [134.15.64.61]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k74M0Y8s27505469; Fri, 4 Aug 2006 15:00:34 -0700 (PDT) Message-ID: <44D3C351.7060109@sgi.com> Date: Fri, 04 Aug 2006 16:59:45 -0500 From: Bill Kendall User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russell Cattelan CC: Dean Roehrich , Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> <44D379A6.9040200@sgi.com> <44D38D34.1010503@thebarn.com> In-Reply-To: <44D38D34.1010503@thebarn.com> Content-Type: multipart/mixed; boundary="------------080707030407020401070109" X-archive-position: 8574 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 12460 Lines: 353 This is a multi-part message in MIME format. --------------080707030407020401070109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here's a patch that accomplishes #3. Turns out no libhandle changes were required. Built debian and rpm packages and verified that dmapi/libdm were not mentioned in the dependencies, and for debian that libdm was not mentioned in the build-deps either. I'd still like to move the current hsmapi.c out of xfsdump, but it's just not much of a priority right now. Bill Russell Cattelan wrote: > Bill Kendall wrote: > > [snip] > >> >> 3) Add make_handle() routine to libhandle. xfsdump's only dependencies >> from libdm are dm_make_handle() and dm_handle_to_fsid() (the latter >> of which is in libhandle as handle_to_fshandle(), I think). > > Hmm looking at dm_handle_to_fsid: it calls parse_handle which appears > be quite dmapi specific and would require much of dm_handle.c? > > I suppose we could move dm_handle.c into libhandle ? > But that seems to be going in the wrong direction in terms of > correct code compartmentalization. > > Since dmapi is only available on Suse , Propack and somebody doing > a custom kernel, I'm not convinced that xfs dump/restore should > support dmapi no matter what. > The only time a problem might arise is somebody not using the shipped > version > of xfs dump/restore on a Suse or propack system, in which case they > should either know what they are doing or get what they deserve. > >> >> 4) Noop the existing hsm routines, and allow xfsdump to dlopen a >> specified .so to override the default (noop) behavior. DMF could >> then ship a .so implementing those functions. >> >> Bill >> --------------080707030407020401070109 Content-Type: text/plain; name="no_dmapi" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="no_dmapi" Index: xfs/xfsdump/common/hsmapi.c =================================================================== --- xfs.orig/xfsdump/common/hsmapi.c 2006-08-04 13:39:36.088684549 -0500 +++ xfs/xfsdump/common/hsmapi.c 2006-08-04 15:34:42.512343704 -0500 @@ -18,8 +18,7 @@ #include #include -#include -#include +#include #include "hsmapi.h" #include "mlog.h" @@ -86,13 +85,12 @@ #define DMF_ST_NOMIGR 5 /* file should not be migrated */ #define DMF_ST_PARTIAL 6 /* file has backups plus parts online */ -/* Interesting bit combinations within the bs_dmevmask field of xfs_bstat_t: +/* Create mask containing read, write, trunc and destroy dmapi event bits. + * Hardcode the values since xfsdump should not depend on dmapi being installed. + * Interesting bit combinations within the bs_dmevmask field of xfs_bstat_t: * OFL, UNM, and PAR files have exactly these bits set. * DUL and MIG files have all but the DM_EVENT_READ bit set */ -#define DMF_EV_BITS ( (1<dumpversion = dumpversion; - dmf_fs_ctxtp->fsid = fsid; + + /* Get the filesystem's handle for later use in building file + handles in HsmInitFileContext. + */ + dmf_fs_ctxtp->fshanp = jdm_getfshandle((char *)mountpoint); + if (dmf_fs_ctxtp->fshanp == NULL) { + free(dmf_fs_ctxtp); + return NULL; + } return (hsm_fs_ctxt_t *)dmf_fs_ctxtp; } @@ -411,10 +398,6 @@ { dmf_f_ctxt_t *dmf_f_ctxtp = (dmf_f_ctxt_t *)contextp; XFSattrvalue0_t *dmfattrp; - void *hanp; - size_t hlen = 0; - dm_ino_t ino; - dm_igen_t igen; int state; int error; attr_multiop_t attr_op; @@ -437,13 +420,6 @@ for the DMF attribute. (It could be in a disk block separate from the inode.) */ - - ino = (dm_ino_t)statp->bs_ino; - igen = (dm_igen_t)statp->bs_gen; - if (dm_make_handle(&dmf_f_ctxtp->fsys.fsid, &ino, &igen, &hanp, &hlen) != 0) { - return 0; /* can't make a proper handle */ - } - attr_op.am_opcode = ATTR_OP_GET; attr_op.am_error = 0; attr_op.am_attrname = DMF_ATTR_NAME; @@ -451,8 +427,11 @@ attr_op.am_length = sizeof(dmf_f_ctxtp->attrval); attr_op.am_flags = ATTR_ROOT; - error = attr_multi_by_handle(hanp, hlen, &attr_op, 1, 0); - free_handle(hanp, hlen); + error = jdm_attr_multi(dmf_f_ctxtp->fsys.fshanp, + (xfs_bstat_t *)statp, + (char *)&attr_op, + 1, + 0); if (error || attr_op.am_error) return 0; /* no DMF attribute */ Index: xfs/xfsdump/aclocal.m4 =================================================================== --- xfs.orig/xfsdump/aclocal.m4 2006-08-04 15:36:45.207573713 -0500 +++ xfs/xfsdump/aclocal.m4 2006-08-04 15:39:03.904854078 -0500 @@ -157,33 +157,6 @@ exit 1 ]) ]) -AC_DEFUN([AC_PACKAGE_NEED_XFS_DMAPI_H], - [ AC_CHECK_HEADERS([xfs/dmapi.h]) - if test "$ac_cv_header_xfs_dmapi_h" != yes; then - echo - echo 'FATAL ERROR: could not find a valid DMAPI library header.' - echo 'Install the data migration API (dmapi) development package.' - echo 'Alternatively, run "make install-dev" from the dmapi source.' - exit 1 - fi - ]) - -AC_DEFUN([AC_PACKAGE_NEED_MAKEHANDLE_LIBDM], - [ AC_CHECK_LIB(dm, dm_make_handle,, [ - echo - echo 'FATAL ERROR: could not find a valid DMAPI base library.' - echo 'Install the data migration API (dmapi) library package.' - echo 'Alternatively, run "make install" from the dmapi source.' - exit 1 - ]) - libdm="-ldm" - test -f `pwd`/../dmapi/libdm/libdm.la && \ - libdm="`pwd`/../dmapi/libdm/libdm.la" - test -f ${libexecdir}${libdirsuffix}/libdm.la && \ - libdm="${libexecdir}${libdirsuffix}/libdm.la" - AC_SUBST(libdm) - ]) - # # Generic macro, sets up all of the global packaging variables. # The following environment variables may be set to override defaults: Index: xfs/xfsdump/dump/Makefile =================================================================== --- xfs.orig/xfsdump/dump/Makefile 2006-08-04 15:43:59.901686947 -0500 +++ xfs/xfsdump/dump/Makefile 2006-08-04 15:44:09.206843880 -0500 @@ -85,7 +85,7 @@ HFILES = $(LOCALINCL) $(COMMINCL) $(INVINCL) LINKS = $(COMMINCL) $(COMMON) $(INVINCL) $(INVCOMMON) LDIRT = $(LINKS) -LLDLIBS = $(LIBUUID) $(LIBHANDLE) $(LIBATTR) $(LIBDM) $(LIBRMT) +LLDLIBS = $(LIBUUID) $(LIBHANDLE) $(LIBATTR) $(LIBRMT) LTDEPENDENCIES = $(LIBRMT) LCFLAGS = -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX Index: xfs/xfsdump/include/builddefs.in =================================================================== --- xfs.orig/xfsdump/include/builddefs.in 2006-08-04 15:41:12.564871559 -0500 +++ xfs/xfsdump/include/builddefs.in 2006-08-04 15:41:54.018029788 -0500 @@ -13,7 +13,6 @@ LOADERFLAGS = @LDFLAGS@ LIBRMT = $(TOPDIR)/librmt/librmt.la -LIBDM = @libdm@ LIBXFS = @libxfs@ LIBATTR = @libattr@ LIBUUID = @libuuid@ Index: xfs/xfsdump/debian/control =================================================================== --- xfs.orig/xfsdump/debian/control 2006-08-04 15:44:59.345076705 -0500 +++ xfs/xfsdump/debian/control 2006-08-04 15:45:06.637983169 -0500 @@ -2,7 +2,7 @@ Section: admin Priority: optional Maintainer: Nathan Scott -Build-Depends: xfslibs-dev (>= 2.6.4), uuid-dev, libdm0-dev, libattr1-dev (>= 2.4.14), libncurses-dev, autoconf, debhelper (>= 5), gettext, libtool +Build-Depends: xfslibs-dev (>= 2.6.4), uuid-dev, libattr1-dev (>= 2.4.14), libncurses-dev, autoconf, debhelper (>= 5), gettext, libtool Standards-Version: 3.5.9 Package: xfsdump Index: xfs/xfsdump/m4/package_dmapidev.m4 =================================================================== --- xfs.orig/xfsdump/m4/package_dmapidev.m4 2006-08-04 15:46:39.293496665 -0500 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,26 +0,0 @@ -AC_DEFUN([AC_PACKAGE_NEED_XFS_DMAPI_H], - [ AC_CHECK_HEADERS([xfs/dmapi.h]) - if test "$ac_cv_header_xfs_dmapi_h" != yes; then - echo - echo 'FATAL ERROR: could not find a valid DMAPI library header.' - echo 'Install the data migration API (dmapi) development package.' - echo 'Alternatively, run "make install-dev" from the dmapi source.' - exit 1 - fi - ]) - -AC_DEFUN([AC_PACKAGE_NEED_MAKEHANDLE_LIBDM], - [ AC_CHECK_LIB(dm, dm_make_handle,, [ - echo - echo 'FATAL ERROR: could not find a valid DMAPI base library.' - echo 'Install the data migration API (dmapi) library package.' - echo 'Alternatively, run "make install" from the dmapi source.' - exit 1 - ]) - libdm="-ldm" - test -f `pwd`/../dmapi/libdm/libdm.la && \ - libdm="`pwd`/../dmapi/libdm/libdm.la" - test -f ${libexecdir}${libdirsuffix}/libdm.la && \ - libdm="${libexecdir}${libdirsuffix}/libdm.la" - AC_SUBST(libdm) - ]) Index: xfs/xfsdump/debian/shlibs.local =================================================================== --- xfs.orig/xfsdump/debian/shlibs.local 2006-08-04 15:47:45.321698050 -0500 +++ xfs/xfsdump/debian/shlibs.local 2006-08-04 15:47:50.806379180 -0500 @@ -1,3 +1,2 @@ -libdm 0 libdm0 (>= 2.1.0) libattr 1 libattr1 (>= 2.0.0) libhandle 1 xfsprogs (>= 2.6.30) Index: xfs/xfsdump/restore/Makefile =================================================================== --- xfs.orig/xfsdump/restore/Makefile 2006-08-04 15:48:11.880996211 -0500 +++ xfs/xfsdump/restore/Makefile 2006-08-04 15:48:21.402178453 -0500 @@ -95,7 +95,7 @@ HFILES = $(LOCALINCL) $(COMMINCL) $(INVINCL) LINKS = $(COMMINCL) $(COMMON) $(INVINCL) $(INVCOMMON) LDIRT = $(LINKS) -LLDLIBS = $(LIBUUID) $(LIBHANDLE) $(LIBATTR) $(LIBDM) $(LIBRMT) +LLDLIBS = $(LIBUUID) $(LIBHANDLE) $(LIBATTR) $(LIBRMT) LTDEPENDENCIES = $(LIBRMT) LCFLAGS = -DRESTORE -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DPIPEINVFIX \ Index: xfs/xfsdump/build/rpm/xfsdump.spec.in =================================================================== --- xfs.orig/xfsdump/build/rpm/xfsdump.spec.in 2006-08-04 16:02:28.743149991 -0500 +++ xfs/xfsdump/build/rpm/xfsdump.spec.in 2006-08-04 16:02:36.688132300 -0500 @@ -5,7 +5,7 @@ Distribution: @pkg_distribution@ Packager: Silicon Graphics, Inc. BuildRoot: @build_root@ -Requires: xfsprogs >= 2.6.30, dmapi >= 2.0.0, attr >= 2.0.0 +Requires: xfsprogs >= 2.6.30, attr >= 2.0.0 Source: @pkg_name@-@pkg_version@.src.tar.gz License: GPL Vendor: Silicon Graphics, Inc. Index: xfs/xfsdump/configure.in =================================================================== --- xfs.orig/xfsdump/configure.in 2006-08-04 15:49:23.473884494 -0500 +++ xfs/xfsdump/configure.in 2006-08-04 15:49:37.967683519 -0500 @@ -31,9 +31,6 @@ AC_PACKAGE_NEED_XFS_HANDLE_H AC_PACKAGE_NEED_OPEN_BY_FSHANDLE -AC_PACKAGE_NEED_XFS_DMAPI_H -AC_PACKAGE_NEED_MAKEHANDLE_LIBDM - AC_PACKAGE_NEED_ATTRIBUTES_H AC_PACKAGE_NEED_ATTRIBUTES_MACROS AC_PACKAGE_NEED_ATTRGET_LIBATTR Index: xfs/xfsdump/m4/Makefile =================================================================== --- xfs.orig/xfsdump/m4/Makefile 2006-08-04 16:03:15.648948927 -0500 +++ xfs/xfsdump/m4/Makefile 2006-08-04 16:03:21.013612090 -0500 @@ -8,7 +8,6 @@ LSRCFILES = \ manual_format.m4 \ package_attrdev.m4 \ - package_dmapidev.m4 \ package_globals.m4 \ package_ncurses.m4 \ package_utilies.m4 \ --------------080707030407020401070109-- From owner-xfs@oss.sgi.com Fri Aug 4 21:13:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Aug 2006 21:13:29 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k754D0DW012359 for ; Fri, 4 Aug 2006 21:13:06 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 40FA218068C57 for ; Fri, 4 Aug 2006 23:12:32 -0500 (CDT) Message-ID: <44D41AB0.3050808@sandeen.net> Date: Fri, 04 Aug 2006 23:12:32 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] kill iop_abort item_op Content-Type: multipart/mixed; boundary="------------040504040207000401090700" X-archive-position: 8575 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 10761 Lines: 314 This is a multi-part message in MIME format. --------------040504040207000401090700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It doesn't look like this is ever used for anything...? quota/xfs_dquot_item.c | 26 ------------------ xfs_buf_item.c | 20 -------------- xfs_extfree_item.c | 69 +------------------------------------------------ xfs_inode_item.c | 16 ----------- xfs_trans.h | 2 - 5 files changed, 2 insertions(+), 131 deletions(-) -Eric --------------040504040207000401090700 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="kill-iop_abort" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kill-iop_abort" Signed-off-by: Eric Sandeen Index: xfs-linux/quota/xfs_dquot_item.c =================================================================== --- xfs-linux.orig/quota/xfs_dquot_item.c +++ xfs-linux/quota/xfs_dquot_item.c @@ -382,18 +382,6 @@ xfs_qm_dquot_logitem_unlock( /* - * The transaction with the dquot locked has aborted. The dquot - * must not be dirty within the transaction. We simply unlock just - * as if the transaction had been cancelled. - */ -STATIC void -xfs_qm_dquot_logitem_abort( - xfs_dq_logitem_t *ql) -{ - xfs_qm_dquot_logitem_unlock(ql); -} - -/* * this needs to stamp an lsn into the dquot, I think. * rpc's that look at user dquot's would then have to * push on the dependency recorded in the dquot @@ -426,7 +414,6 @@ STATIC struct xfs_item_ops xfs_dquot_ite .iop_committed = (xfs_lsn_t(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_qm_dquot_logitem_committed, .iop_push = (void(*)(xfs_log_item_t*))xfs_qm_dquot_logitem_push, - .iop_abort = (void(*)(xfs_log_item_t*))xfs_qm_dquot_logitem_abort, .iop_pushbuf = (void(*)(xfs_log_item_t*)) xfs_qm_dquot_logitem_pushbuf, .iop_committing = (void(*)(xfs_log_item_t*, xfs_lsn_t)) @@ -559,17 +546,6 @@ xfs_qm_qoff_logitem_committed(xfs_qoff_l } /* - * The transaction of which this QUOTAOFF is a part has been aborted. - * Just clean up after ourselves. - * Shouldn't this never happen in the case of qoffend logitems? XXX - */ -STATIC void -xfs_qm_qoff_logitem_abort(xfs_qoff_logitem_t *qf) -{ - kmem_free(qf, sizeof(xfs_qoff_logitem_t)); -} - -/* * There isn't much you can do to push on an quotaoff item. It is simply * stuck waiting for the log to be flushed to disk. */ @@ -644,7 +620,6 @@ STATIC struct xfs_item_ops xfs_qm_qoffen .iop_committed = (xfs_lsn_t(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_qm_qoffend_logitem_committed, .iop_push = (void(*)(xfs_log_item_t*))xfs_qm_qoff_logitem_push, - .iop_abort = (void(*)(xfs_log_item_t*))xfs_qm_qoff_logitem_abort, .iop_pushbuf = NULL, .iop_committing = (void(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_qm_qoffend_logitem_committing @@ -667,7 +642,6 @@ STATIC struct xfs_item_ops xfs_qm_qoff_l .iop_committed = (xfs_lsn_t(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_qm_qoff_logitem_committed, .iop_push = (void(*)(xfs_log_item_t*))xfs_qm_qoff_logitem_push, - .iop_abort = (void(*)(xfs_log_item_t*))xfs_qm_qoff_logitem_abort, .iop_pushbuf = NULL, .iop_committing = (void(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_qm_qoff_logitem_committing Index: xfs-linux/xfs_buf_item.c =================================================================== --- xfs-linux.orig/xfs_buf_item.c +++ xfs-linux/xfs_buf_item.c @@ -628,25 +628,6 @@ xfs_buf_item_committed( } /* - * This is called when the transaction holding the buffer is aborted. - * Just behave as if the transaction had been cancelled. If we're shutting down - * and have aborted this transaction, we'll trap this buffer when it tries to - * get written out. - */ -STATIC void -xfs_buf_item_abort( - xfs_buf_log_item_t *bip) -{ - xfs_buf_t *bp; - - bp = bip->bli_buf; - xfs_buftrace("XFS_ABORT", bp); - XFS_BUF_SUPER_STALE(bp); - xfs_buf_item_unlock(bip); - return; -} - -/* * This is called to asynchronously write the buffer associated with this * buf log item out to disk. The buffer will already have been locked by * a successful call to xfs_buf_item_trylock(). If the buffer still has @@ -693,7 +674,6 @@ STATIC struct xfs_item_ops xfs_buf_item_ .iop_committed = (xfs_lsn_t(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_buf_item_committed, .iop_push = (void(*)(xfs_log_item_t*))xfs_buf_item_push, - .iop_abort = (void(*)(xfs_log_item_t*))xfs_buf_item_abort, .iop_pushbuf = NULL, .iop_committing = (void(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_buf_item_committing Index: xfs-linux/xfs_extfree_item.c =================================================================== --- xfs-linux.orig/xfs_extfree_item.c +++ xfs-linux/xfs_extfree_item.c @@ -33,9 +33,6 @@ kmem_zone_t *xfs_efi_zone; kmem_zone_t *xfs_efd_zone; STATIC void xfs_efi_item_unlock(xfs_efi_log_item_t *); -STATIC void xfs_efi_item_abort(xfs_efi_log_item_t *); -STATIC void xfs_efd_item_abort(xfs_efd_log_item_t *); - void xfs_efi_item_free(xfs_efi_log_item_t *efip) @@ -184,7 +181,7 @@ STATIC void xfs_efi_item_unlock(xfs_efi_log_item_t *efip) { if (efip->efi_item.li_flags & XFS_LI_ABORTED) - xfs_efi_item_abort(efip); + xfs_efi_item_free(efip); return; } @@ -202,18 +199,6 @@ xfs_efi_item_committed(xfs_efi_log_item_ } /* - * This is called when the transaction logging the EFI is aborted. - * Free up the EFI and return. No need to clean up the slot for - * the item in the transaction. That was done by the unpin code - * which is called prior to this routine in the abort/fs-shutdown path. - */ -STATIC void -xfs_efi_item_abort(xfs_efi_log_item_t *efip) -{ - xfs_efi_item_free(efip); -} - -/* * There isn't much you can do to push on an efi item. It is simply * stuck waiting for all of its corresponding efd items to be * committed to disk. @@ -255,7 +240,6 @@ STATIC struct xfs_item_ops xfs_efi_item_ .iop_committed = (xfs_lsn_t(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_efi_item_committed, .iop_push = (void(*)(xfs_log_item_t*))xfs_efi_item_push, - .iop_abort = (void(*)(xfs_log_item_t*))xfs_efi_item_abort, .iop_pushbuf = NULL, .iop_committing = (void(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_efi_item_committing @@ -386,33 +370,6 @@ xfs_efi_release(xfs_efi_log_item_t *efip } } -/* - * This is called when the transaction that should be committing the - * EFD corresponding to the given EFI is aborted. The committed and - * canceled flags are used to coordinate the freeing of the EFI and - * the references by the transaction that committed it. - */ -STATIC void -xfs_efi_cancel( - xfs_efi_log_item_t *efip) -{ - xfs_mount_t *mp; - SPLDECL(s); - - mp = efip->efi_item.li_mountp; - AIL_LOCK(mp, s); - if (efip->efi_flags & XFS_EFI_COMMITTED) { - /* - * xfs_trans_delete_ail() drops the AIL lock. - */ - xfs_trans_delete_ail(mp, (xfs_log_item_t *)efip, s); - xfs_efi_item_free(efip); - } else { - efip->efi_flags |= XFS_EFI_CANCELED; - AIL_UNLOCK(mp, s); - } -} - STATIC void xfs_efd_item_free(xfs_efd_log_item_t *efdp) { @@ -514,7 +471,7 @@ STATIC void xfs_efd_item_unlock(xfs_efd_log_item_t *efdp) { if (efdp->efd_item.li_flags & XFS_LI_ABORTED) - xfs_efd_item_abort(efdp); + xfs_efd_item_free(efdp); return; } @@ -541,27 +498,6 @@ xfs_efd_item_committed(xfs_efd_log_item_ } /* - * The transaction of which this EFD is a part has been aborted. - * Inform its companion EFI of this fact and then clean up after - * ourselves. No need to clean up the slot for the item in the - * transaction. That was done by the unpin code which is called - * prior to this routine in the abort/fs-shutdown path. - */ -STATIC void -xfs_efd_item_abort(xfs_efd_log_item_t *efdp) -{ - /* - * If we got a log I/O error, it's always the case that the LR with the - * EFI got unpinned and freed before the EFD got aborted. So don't - * reference the EFI at all in that case. - */ - if ((efdp->efd_item.li_flags & XFS_LI_ABORTED) == 0) - xfs_efi_cancel(efdp->efd_efip); - - xfs_efd_item_free(efdp); -} - -/* * There isn't much you can do to push on an efd item. It is simply * stuck waiting for the log to be flushed to disk. */ @@ -602,7 +538,6 @@ STATIC struct xfs_item_ops xfs_efd_item_ .iop_committed = (xfs_lsn_t(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_efd_item_committed, .iop_push = (void(*)(xfs_log_item_t*))xfs_efd_item_push, - .iop_abort = (void(*)(xfs_log_item_t*))xfs_efd_item_abort, .iop_pushbuf = NULL, .iop_committing = (void(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_efd_item_committing Index: xfs-linux/xfs_inode_item.c =================================================================== --- xfs-linux.orig/xfs_inode_item.c +++ xfs-linux/xfs_inode_item.c @@ -743,21 +743,6 @@ xfs_inode_item_committed( } /* - * The transaction with the inode locked has aborted. The inode - * must not be dirty within the transaction (unless we're forcibly - * shutting down). We simply unlock just as if the transaction - * had been cancelled. - */ -STATIC void -xfs_inode_item_abort( - xfs_inode_log_item_t *iip) -{ - xfs_inode_item_unlock(iip); - return; -} - - -/* * This gets called by xfs_trans_push_ail(), when IOP_TRYLOCK * failed to get the inode flush lock but did get the inode locked SHARED. * Here we're trying to see if the inode buffer is incore, and if so whether it's @@ -915,7 +900,6 @@ STATIC struct xfs_item_ops xfs_inode_ite .iop_committed = (xfs_lsn_t(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_inode_item_committed, .iop_push = (void(*)(xfs_log_item_t*))xfs_inode_item_push, - .iop_abort = (void(*)(xfs_log_item_t*))xfs_inode_item_abort, .iop_pushbuf = (void(*)(xfs_log_item_t*))xfs_inode_item_pushbuf, .iop_committing = (void(*)(xfs_log_item_t*, xfs_lsn_t)) xfs_inode_item_committing Index: xfs-linux/xfs_trans.h =================================================================== --- xfs-linux.orig/xfs_trans.h +++ xfs-linux/xfs_trans.h @@ -149,7 +149,6 @@ typedef struct xfs_item_ops { void (*iop_unlock)(xfs_log_item_t *); xfs_lsn_t (*iop_committed)(xfs_log_item_t *, xfs_lsn_t); void (*iop_push)(xfs_log_item_t *); - void (*iop_abort)(xfs_log_item_t *); void (*iop_pushbuf)(xfs_log_item_t *); void (*iop_committing)(xfs_log_item_t *, xfs_lsn_t); } xfs_item_ops_t; @@ -163,7 +162,6 @@ typedef struct xfs_item_ops { #define IOP_UNLOCK(ip) (*(ip)->li_ops->iop_unlock)(ip) #define IOP_COMMITTED(ip, lsn) (*(ip)->li_ops->iop_committed)(ip, lsn) #define IOP_PUSH(ip) (*(ip)->li_ops->iop_push)(ip) -#define IOP_ABORT(ip) (*(ip)->li_ops->iop_abort)(ip) #define IOP_PUSHBUF(ip) (*(ip)->li_ops->iop_pushbuf)(ip) #define IOP_COMMITTING(ip, lsn) (*(ip)->li_ops->iop_committing)(ip, lsn) --------------040504040207000401090700-- From owner-xfs@oss.sgi.com Sun Aug 6 02:01:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Aug 2006 02:01:36 -0700 (PDT) Received: from mondschein.lichtvoll.de (mondschein.lichtschiff.de [194.150.191.238] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7691HDW009265 for ; Sun, 6 Aug 2006 02:01:22 -0700 Received: from localhost (dslb-084-056-104-201.pools.arcor-ip.net [84.56.104.201]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 08D49FA68A for ; Sun, 6 Aug 2006 10:59:18 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: write back cache and barriers Date: Sun, 6 Aug 2006 11:00:35 +0200 User-Agent: KMail/1.9.3 References: <5545990.post@talk.nabble.com> <44CC2D1A.3060805@sandeen.net> In-Reply-To: <44CC2D1A.3060805@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608061100.36508.Martin@lichtvoll.de> X-archive-position: 8576 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1733 Lines: 43 Am Sonntag 30 Juli 2006 05:52 schrieb Eric Sandeen: > > If I try mounting a xfs filesystem I get a message like "barriers are > > not supported by this device" but if I mount a ext3 or a reiserfs > > filesystem respectively with options barrier=1 and barrier=flush they > > don't complain. If I mount the reiserfs I explicity get a message > > like "using barriers". So who tells the truth ?? > > I don't see ext3 or reiser actually checking whether the underlying > device supports barriers. xfs does, in xfs_mountfs_check_barriers(). Hello Eric, for my article I looked at the source code of those. It seems that journal block device tests wether barriers work commit.c: if (ret == -EOPNOTSUPP && barrier_done) { commit.c: "JBD: barrier-based sync failed on %s - " commit.c: "disabling barriers\n", Also reiserfs 3 seems to deactivate barriers if not avaible (journal.c) if (reiserfs_barrier_flush(p_s_sb)) { int ret; lock_buffer(journal->j_header_bh); ret = submit_barrier_buffer(journal->j_header_bh); if (ret == -EOPNOTSUPP) { set_buffer_uptodate(journal->j_header_bh); disable_barrier(p_s_sb); goto sync; } wait_on_buffer(journal->j_header_bh); check_barrier_completion(p_s_sb, journal->j_header_bh); } else { (both sources from kernel 2.6.17.7) Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Sun Aug 6 02:46:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Aug 2006 02:46:26 -0700 (PDT) Received: from mondschein.lichtvoll.de (mondschein.lichtschiff.de [194.150.191.238] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k769kFDW016444 for ; Sun, 6 Aug 2006 02:46:15 -0700 Received: from localhost (dslb-084-056-104-201.pools.arcor-ip.net [84.56.104.201]) by mondschein.lichtvoll.de (Postfix) with ESMTP id B0170FA68A for ; Sun, 6 Aug 2006 11:44:26 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] kill leftover WANT_FUNCS macro indirection Date: Sun, 6 Aug 2006 11:45:45 +0200 User-Agent: KMail/1.9.3 References: <44CAE247.6020608@sandeen.net> <44CBDFC9.3040202@sandeen.net> <20060731085454.A2280998@wobbly.melbourne.sgi.com> In-Reply-To: <20060731085454.A2280998@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608061145.45997.Martin@lichtvoll.de> X-archive-position: 8577 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 719 Lines: 19 Am Montag 31 Juli 2006 00:54 schrieb Nathan Scott: > Right, its more that we don't have a great track record at the moment > of not introducing regressions with these cleanups (including myself), > so I'm becoming more reluctant to do sweeping changes across the whole > codebase. Smaller, specific, and obviously-correct things are less > likely to introduce issues, so if we can achieve basically the same > thing while churning the code less, I'm all for it. Hello Nathan, I fully agree with that - especially as XFS is a file system and regressions can easily have desastrous results. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Sun Aug 6 13:46:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Aug 2006 13:47:05 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k76KkoDW031390 for ; Sun, 6 Aug 2006 13:46:51 -0700 Received: by py-out-1112.google.com with SMTP id c39so384270pyd for ; Sun, 06 Aug 2006 13:46:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=jB2qwgT0Ic4I7qqL8PIHckIo3oFhqxLJZD9/V4B8sRtUK/+Vlr2Fgko892aajOZc60db/POnnz2R5fuE2YKtXUFIN4W9yXn6gFdMIiN92WKDrcuDcI5x37zN+eN8FNJajraPHsbIj7SY17FxfLriUpV9yjKTgZSoChZP+oXpyxI= Received: by 10.35.22.17 with SMTP id z17mr10362182pyi; Sun, 06 Aug 2006 12:32:49 -0700 (PDT) Received: by 10.35.73.13 with HTTP; Sun, 6 Aug 2006 12:32:49 -0700 (PDT) Message-ID: <83d59530608061232r21feab01j456c7d1fec742958@mail.gmail.com> Date: Sun, 6 Aug 2006 20:32:49 +0100 From: "Jeff Briggs" To: xfs@oss.sgi.com Subject: XFS null files MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 8578 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ephemeral.elusive@gmail.com Precedence: bulk X-list: xfs Content-Length: 366 Lines: 13 Hello. I've just lost data to XFS, with the files full of nulls. I've found posts dating back over two years about such data losses. I'm using linux 2.6.17 with xfsprogs 2.8.10. emacs claims to fsync on write, yet still I lost data, the faq suggests I should not have if this is so? Is this likely to be fixed soon, or should I switch file system? Many thanks. From owner-xfs@oss.sgi.com Sun Aug 6 15:26:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Aug 2006 15:26:17 -0700 (PDT) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k76MQ3DW014627 for ; Sun, 6 Aug 2006 15:26:03 -0700 Received: from teal.hq.k1024.org (84-74-89-231.dclient.hispeed.ch [84.74.89.231]) by astra.simleu.ro (Postfix) with ESMTP id E424A50; Mon, 7 Aug 2006 00:22:25 +0300 (EEST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 145D640ACC0; Sun, 6 Aug 2006 23:22:11 +0200 (CEST) Date: Sun, 6 Aug 2006 23:22:11 +0200 From: Iustin Pop To: Jeff Briggs Cc: xfs@oss.sgi.com Subject: Re: XFS null files Message-ID: <20060806212211.GA2154@teal.hq.k1024.org> Mail-Followup-To: Jeff Briggs , xfs@oss.sgi.com References: <83d59530608061232r21feab01j456c7d1fec742958@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83d59530608061232r21feab01j456c7d1fec742958@mail.gmail.com> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.12-2006-07-14 X-archive-position: 8579 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs Content-Length: 527 Lines: 15 On Sun, Aug 06, 2006 at 08:32:49PM +0100, Jeff Briggs wrote: > Hello. > > I've just lost data to XFS, with the files full of nulls. I've found > posts dating back over two years about such data losses. I'm using > linux 2.6.17 with xfsprogs 2.8.10. FWIW, I've never lost files since disabling write cache on disks. > > emacs claims to fsync on write, yet still I lost data, the faq > suggests I should not have if this is so? Have you disabled the write cache of your storage, or is your storage battery-backed? Iustin Pop From owner-xfs@oss.sgi.com Sun Aug 6 16:21:31 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Aug 2006 16:21:42 -0700 (PDT) Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k76NLVDW027619 for ; Sun, 6 Aug 2006 16:21:31 -0700 Received: from [10.0.0.12] (ease.thebarn.com [10.0.0.12]) (authenticated bits=0) by slurp.thebarn.com (8.13.5/8.13.5) with ESMTP id k76MMt56030789; Sun, 6 Aug 2006 17:22:56 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <44D66BBF.8010107@thebarn.com> Date: Sun, 06 Aug 2006 17:22:55 -0500 From: Russell Cattelan User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Briggs , xfs@oss.sgi.com Subject: Re: XFS null files References: <83d59530608061232r21feab01j456c7d1fec742958@mail.gmail.com> In-Reply-To: <83d59530608061232r21feab01j456c7d1fec742958@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8580 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 1010 Lines: 30 Jeff Briggs wrote: > Hello. > > I've just lost data to XFS, with the files full of nulls. I've found > posts dating back over two years about such data losses. I'm using > linux 2.6.17 with xfsprogs 2.8.10. Check to see if you have this change http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=1.675;r2=1.676;f=h I helps reduce the null file problem. > > emacs claims to fsync on write, yet still I lost data, the faq > suggests I should not have if this is so? > > Is this likely to be fixed soon, or should I switch file system? Any caching file system could potentially loose data, XFS just happens to get the file size correct so you end up with a file that is nothing but a hole. Other file system would probably just give you an empty file. Either way data in cache always has the potential for being lost. Running xfs in full sync mode would be safest but you loose many performance advantages... so it always a trade off of performance vs data integrity. > > Many thanks. > From owner-xfs@oss.sgi.com Sun Aug 6 17:00:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Aug 2006 17:00:38 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7700BDW001133 for ; Sun, 6 Aug 2006 17:00:22 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07556; Mon, 7 Aug 2006 09:59:24 +1000 Message-ID: <44D68290.6020703@sgi.com> Date: Mon, 07 Aug 2006 10:00:16 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Dean Roehrich CC: Russell Cattelan , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> In-Reply-To: <20060804141012.GA26@kickball-mn.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8581 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 1391 Lines: 39 Dean Roehrich wrote: > On Fri, Aug 04, 2006 at 02:18:13PM +1000, Vlad Apostolov wrote: > >> Hi Russel, >> >> I don't understand in details the build changes but they seam to be fine. >> > > Vlad, why do they seem fine? > Well, I patiently waited with the hope that someone more knowledgeable on the topic would do the review. No one responded in time and I thought that either no one cares about the change or no one fully understands it. As I am supposed to support DMAPI, I had to take the review and after consulting locally with xfs developers I did the review. Now I see that there are people interested and knowing better than me what needs to be done. >> In summary if the build system can find the DMAPI lib installed it will >> use hsmapi_noop.c otherwise hsmapi.c. >> The return code of HsmInitFileContext() stub probably should be non zero. >> >> It is looking good. >> > > So this is determined at build time...so when you're using a version of > xfsdump/xfsrestore how do you know you're _not_ using one that is DMAPI-aware > _before_ you get into trouble with an invalid dump? > > Assuming that issue is addressed, here's another: The libdm is a shared > object, so why not take advantage of that and load it with dlopen? Then the > issue is determined at runtime rather than build time. This is easy, and even > DMF does it this way. > > Dean > From owner-xfs@oss.sgi.com Sun Aug 6 21:30:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Aug 2006 21:30:58 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k774UkDW012275 for ; Sun, 6 Aug 2006 21:30:46 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 02E87180100AA; Sun, 6 Aug 2006 21:31:54 -0500 (CDT) Message-ID: <44D6A61A.5090900@sandeen.net> Date: Sun, 06 Aug 2006 21:31:54 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Martin Steigerwald Cc: linux-xfs@oss.sgi.com Subject: Re: write back cache and barriers References: <5545990.post@talk.nabble.com> <44CC2D1A.3060805@sandeen.net> <200608061100.36508.Martin@lichtvoll.de> In-Reply-To: <200608061100.36508.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8582 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1221 Lines: 35 Martin Steigerwald wrote: > Hello Eric, > > for my article I looked at the source code of those. It seems that journal > block device tests wether barriers work > > commit.c: if (ret == -EOPNOTSUPP && barrier_done) { > commit.c: "JBD: barrier-based sync failed on %s - " > commit.c: "disabling barriers\n", > > Also reiserfs 3 seems to deactivate barriers if not avaible (journal.c) > > if (reiserfs_barrier_flush(p_s_sb)) { > int ret; > lock_buffer(journal->j_header_bh); > ret = submit_barrier_buffer(journal->j_header_bh); > if (ret == -EOPNOTSUPP) { > set_buffer_uptodate(journal->j_header_bh); > disable_barrier(p_s_sb); > goto sync; > } > wait_on_buffer(journal->j_header_bh); > check_barrier_completion(p_s_sb, > journal->j_header_bh); > } else { > > (both sources from kernel 2.6.17.7) Yep, you're right, not quite sure how I missed that... Thanks, -Eric From owner-xfs@oss.sgi.com Sun Aug 6 21:55:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Aug 2006 21:56:11 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k774tYDW015848 for ; Sun, 6 Aug 2006 21:55:45 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA13061; Mon, 7 Aug 2006 14:54:49 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k774skgw2500375; Mon, 7 Aug 2006 14:54:47 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k774shE32501624; Mon, 7 Aug 2006 14:54:43 +1000 (EST) Date: Mon, 7 Aug 2006 14:54:43 +1000 From: Nathan Scott To: Dan Am Cc: xfs@oss.sgi.com Subject: Re: "xfs_io -c chattr +i " on a symlink Message-ID: <20060807145443.C2501392@wobbly.melbourne.sgi.com> References: <28749.62.159.242.114.1154600816.squirrel@otto.lonx.net> <44D20473.3010304@sandeen.net> <20060804102949.B2401829@wobbly.melbourne.sgi.com> <48367.62.159.242.114.1154691452.squirrel@otto.lonx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <48367.62.159.242.114.1154691452.squirrel@otto.lonx.net>; from xfs@lonx.net on Fri, Aug 04, 2006 at 01:37:32PM +0200 X-archive-position: 8584 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 567 Lines: 23 On Fri, Aug 04, 2006 at 01:37:32PM +0200, Dan Am wrote: > On Fri, August 4, 2006 2:29 am, Nathan Scott wrote: > > > ... I think you just set immutable on /tmp. Try a broken symlink, > > instead of one that points to an existing inode. > Nope: Eh? > /data/tara-test > ls -l test > lrwxr-xr-x 1 root root 13 Aug 4 13:33 test -> /archive/no-such-file > > /data/tara-test > xfs_io -c "chattr +i" test > test: No such file or directory Right, that was my point. As I said, you're out of luck - there is currently no way to do what you want. cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Aug 7 01:49:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Aug 2006 01:49:18 -0700 (PDT) Received: from web31713.mail.mud.yahoo.com (web31713.mail.mud.yahoo.com [68.142.201.193]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k778mwDW024819 for ; Mon, 7 Aug 2006 01:49:02 -0700 Received: (qmail 58135 invoked by uid 60001); 7 Aug 2006 08:48:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MEYtgCenfGetXsntrF0xdXSR5V5x7H8yEerS4f+H/+axE+oL2jfJ94WfP2TJZngdglh77FOW9/45gNOEuL69uZpzZM7Qm+r6+VhskgBOpUKhyuXoXhL+fkzHXSUkikJH1Ukd8DV15X+EBBCbc6zV/auO0KMC3qyKywncRIjf59c= ; Message-ID: <20060807084830.58133.qmail@web31713.mail.mud.yahoo.com> Received: from [212.150.66.71] by web31713.mail.mud.yahoo.com via HTTP; Mon, 07 Aug 2006 01:48:30 PDT Date: Mon, 7 Aug 2006 01:48:30 -0700 (PDT) From: Heilige Gheist Subject: Re: Concurrent mount of XFS over SAN To: Dave Lloyd Cc: xfs@oss.sgi.com In-Reply-To: <44D26D3E.5010708@exegy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 8585 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hgheist@yahoo.com Precedence: bulk X-list: xfs Content-Length: 1300 Lines: 53 Dave, That's 100% correct assuming you prohibit a shared access between the nodes. I didn't point out that we're dealing with filesystem failover setup. It's obvious that I can always fall back to the inter-node heart-beat to ensure that only one node is mounting the filesystem. I'm just wondering if there's any facility or accepted practice to enforce it. Thanks, Alan --- Dave Lloyd wrote: > Heilige Gheist wrote: > > Is there a way to prevent and/or detect concurrent mount of same > XFS > > SAN-based partition from several nodes? > > I had to fsck a filesystem losing some data after two nodes > happily > > mounted a filesystem from same SAN-based partition at the same > time and > > wrote into it. > > Thanks! > > > > --alan > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > > > I think that the generally accepted way is to zone at the switch or > the > storage array. > > -- > Dave Lloyd > Test Engineer, Exegy, Inc. > 314.450.5342 > dlloyd@exegy.com > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-xfs@oss.sgi.com Mon Aug 7 03:35:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Aug 2006 03:36:05 -0700 (PDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k77AZfDW030972 for ; Mon, 7 Aug 2006 03:35:43 -0700 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GA2Rq-0005aY-Ap for linux-xfs@oss.sgi.com; Mon, 07 Aug 2006 12:35:02 +0200 Received: from blueice4n1.de.ibm.com ([195.212.29.187]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Aug 2006 12:35:02 +0200 Received: from mykleb by blueice4n1.de.ibm.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 07 Aug 2006 12:35:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: Jan-Frode Myklebust Subject: Re: Concurrent mount of XFS over SAN Date: Mon, 7 Aug 2006 12:13:10 +0200 Message-ID: References: <44D26D3E.5010708@exegy.com> <20060807084830.58133.qmail@web31713.mail.mud.yahoo.com> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: blueice4n1.de.ibm.com User-Agent: slrn/0.9.8.1pl1 (Linux) X-archive-position: 8587 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mykleb@no.ibm.com Precedence: bulk X-list: xfs Content-Length: 932 Lines: 22 On 2006-08-07, Heilige Gheist wrote: > It's obvious that I can always fall back to the inter-node heart-beat > to ensure that only one node is mounting the filesystem. > I'm just wondering if there's any facility or accepted practice to > enforce it. STONITH (Shoot The Other Node In The Head) trough smart power switches or management adapters in the node. SCSI reserve/release ... No idea how reliable this is on a SAN, but the ServeRAID-version works great. http://www.linux-ha.org/ServeRAID Export the volume group, or scsi device on the first node, before importing/attaching it on the second .. Probably best to use together with STONITH, in case the first node fails on unmounting/exporting. BTW: I think XFS on IRIX had the owning node name in the file system header, and only would allow this node to mount the fs. But I can't find this now... Maybe it's gone, or maybe it was in xlv.. ? -jf From owner-xfs@oss.sgi.com Mon Aug 7 05:56:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Aug 2006 05:56:17 -0700 (PDT) Received: from outfbmx008.isp.belgacom.be (outfbmx008.isp.belgacom.be [195.238.5.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k77Cu1DW026545 for ; Mon, 7 Aug 2006 05:56:02 -0700 Received: from outmx009.isp.belgacom.be (outmx009.isp.belgacom.be [195.238.5.4]) by outfbmx008.isp.belgacom.be (Postfix) with ESMTP id 72FC639937 for ; Mon, 7 Aug 2006 13:02:19 +0200 (CEST) Received: from outmx009.isp.belgacom.be (localhost [127.0.0.1]) by outmx009.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k77B1ndr024944 for ; Mon, 7 Aug 2006 13:01:49 +0200 (envelope-from ) Received: from [10.0.1.101] (84.59-136-217.adsl.skynet.be [217.136.59.84]) by outmx009.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k77B1eru024842; Mon, 7 Aug 2006 13:01:41 +0200 (envelope-from ) Message-ID: <44D71DA2.2020409@skynet.be> Date: Mon, 07 Aug 2006 13:01:54 +0200 From: kris buggenhout User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Jan-Frode Myklebust Cc: linux-xfs@oss.sgi.com Subject: Re: Concurrent mount of XFS over SAN References: <44D26D3E.5010708@exegy.com> <20060807084830.58133.qmail@web31713.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8588 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kris.buggenhout@skynet.be Precedence: bulk X-list: xfs Content-Length: 1391 Lines: 41 afaik, the node was stored in xlv, which was an extra option in IRIX, ( extra license) but this could later be used in CXFS which allows multiple machines to mount the same FS read write from a SAN, made for clusters, HA and HPC... knowledge of the node "owning" the device was in there for protection. but can be overridden with an xlv command. kind regards, Kris Jan-Frode Myklebust wrote: > On 2006-08-07, Heilige Gheist wrote: > >> It's obvious that I can always fall back to the inter-node heart-beat >> to ensure that only one node is mounting the filesystem. >> I'm just wondering if there's any facility or accepted practice to >> enforce it. >> > > STONITH (Shoot The Other Node In The Head) trough smart power switches > or management adapters in the node. > > SCSI reserve/release ... No idea how reliable this is on a SAN, but the > ServeRAID-version works great. http://www.linux-ha.org/ServeRAID > > Export the volume group, or scsi device on the first node, before > importing/attaching it on the second .. Probably best to use together > with STONITH, in case the first node fails on unmounting/exporting. > > BTW: I think XFS on IRIX had the owning node name in the file system header, > and only would allow this node to mount the fs. But I can't find this now... > Maybe it's gone, or maybe it was in xlv.. ? > > > -jf > > > > > From owner-xfs@oss.sgi.com Mon Aug 7 07:53:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Aug 2006 07:53:36 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k77ErJDW011973 for ; Mon, 7 Aug 2006 07:53:22 -0700 Received: from [212.227.126.202] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1GA4uB-0002sd-00; Mon, 07 Aug 2006 15:12:27 +0200 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1GA4uB-0006Uz-00; Mon, 07 Aug 2006 15:12:27 +0200 Received: from mapibe17.exchange.xchg ([172.23.1.54]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Aug 2006 15:12:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Concurrent mount of XFS over SAN Date: Mon, 7 Aug 2006 15:12:23 +0200 Message-ID: <55EF1E5D5804A542A6CA37E446DDC206393335@mapibe17.exchange.xchg> In-Reply-To: <44D71DA2.2020409@skynet.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Concurrent mount of XFS over SAN thread-index: Aca6IPbxJsp25gsURhGf/CC01+qUwgAAUCHg From: "Sebastian Brings" To: "kris buggenhout" , "Jan-Frode Myklebust" Cc: X-OriginalArrivalTime: 07 Aug 2006 13:12:26.0828 (UTC) FILETIME=[2114F0C0:01C6BA23] X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.1.26 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k77ErMDW011985 X-archive-position: 8589 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sebas@silexmedia.com Precedence: bulk X-list: xfs Content-Length: 2277 Lines: 73 Maybe off topic meanwhile, but both Irix volume managers xlv and xvm have the owner stored in the header. Xvm also has an understanding of a cluster owning the volume, which is required for cxfs. In a failover environment you absolutely have to make sure the failed machine really has no more access to the volume, preferably by fencing the FC switch ports, before you mount it on the standby system. STONITH implementations also work, but still two machines have to agree on the ownership when the failed machine comes up again. Cheers Sebastian > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] On Behalf Of > kris buggenhout > Sent: Montag, 7. August 2006 13:02 > To: Jan-Frode Myklebust > Cc: linux-xfs@oss.sgi.com > Subject: Re: Concurrent mount of XFS over SAN > > afaik, the node was stored in xlv, which was an extra option in IRIX, ( > extra license) but this could later be used in CXFS which allows > multiple machines to mount the same FS read write from a SAN, made for > clusters, HA and HPC... > > knowledge of the node "owning" the device was in there for protection. > but can be overridden with an xlv command. > > kind regards, Kris > > Jan-Frode Myklebust wrote: > > On 2006-08-07, Heilige Gheist wrote: > > > >> It's obvious that I can always fall back to the inter-node heart-beat > >> to ensure that only one node is mounting the filesystem. > >> I'm just wondering if there's any facility or accepted practice to > >> enforce it. > >> > > > > STONITH (Shoot The Other Node In The Head) trough smart power switches > > or management adapters in the node. > > > > SCSI reserve/release ... No idea how reliable this is on a SAN, but the > > ServeRAID-version works great. http://www.linux-ha.org/ServeRAID > > > > Export the volume group, or scsi device on the first node, before > > importing/attaching it on the second .. Probably best to use together > > with STONITH, in case the first node fails on unmounting/exporting. > > > > BTW: I think XFS on IRIX had the owning node name in the file system > header, > > and only would allow this node to mount the fs. But I can't find this > now... > > Maybe it's gone, or maybe it was in xlv.. ? > > > > > > -jf > > > > > > > > > > > From owner-xfs@oss.sgi.com Mon Aug 7 08:03:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Aug 2006 08:04:23 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k77F3uDW014588 for ; Mon, 7 Aug 2006 08:03:57 -0700 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k77F3POc001724 for ; Mon, 7 Aug 2006 09:03:25 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k77F3PQu008428 for ; Mon, 7 Aug 2006 09:03:25 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3) with ESMTP id k77F3Ov3008489; Mon, 7 Aug 2006 10:03:24 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3/Submit) id k77F3OUp008488; Mon, 7 Aug 2006 10:03:24 -0500 (CDT) Date: Mon, 7 Aug 2006 10:03:24 -0500 From: Dean Roehrich To: Bill Kendall Cc: Russell Cattelan , Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump Message-ID: <20060807150324.GA8421@kickball-mn.Central.Sun.COM> References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> <44D379A6.9040200@sgi.com> <44D38D34.1010503@thebarn.com> <44D3C351.7060109@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D3C351.7060109@sgi.com> User-Agent: Mutt/1.5.9i X-archive-position: 8590 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dean.roehrich@sun.com Precedence: bulk X-list: xfs Content-Length: 586 Lines: 19 On Fri, Aug 04, 2006 at 04:59:45PM -0500, Bill Kendall wrote: > -#define DMF_EV_BITS ( (1< - (1< - (1< - (1< +#define DMF_EV_BITS ( (1<<16) | (1<<17) | (1<<18) | (1<<20) ) Don't do that. Granted, those bits can never be changed else all of your customers will start a lynch mob and come after you. At the very least, don't allow those bits to be anonymous--copy that whole enum from the dmapi header. Even that I object to, but at least the bits will _be_ something. Dean From owner-xfs@oss.sgi.com Mon Aug 7 08:30:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Aug 2006 08:30:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k77FUPDW024590 for ; Mon, 7 Aug 2006 08:30:27 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k77FTp1v002664; Mon, 7 Aug 2006 11:29:51 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k77FTpta001506; Mon, 7 Aug 2006 11:29:51 -0400 Received: from [10.15.80.54] (xenon.msp.redhat.com [10.15.80.54]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k77FTm7N032524; Mon, 7 Aug 2006 11:29:50 -0400 Message-ID: <44D75C87.8050402@thebarn.com> Date: Mon, 07 Aug 2006 10:30:15 -0500 From: Russell Cattelan User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Dean Roehrich CC: Bill Kendall , Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> <44D379A6.9040200@sgi.com> <44D38D34.1010503@thebarn.com> <44D3C351.7060109@sgi.com> <20060807150324.GA8421@kickball-mn.Central.Sun.COM> In-Reply-To: <20060807150324.GA8421@kickball-mn.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8591 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 1011 Lines: 34 Dean Roehrich wrote: > On Fri, Aug 04, 2006 at 04:59:45PM -0500, Bill Kendall wrote: > > >> -#define DMF_EV_BITS ( (1<> - (1<> - (1<> - (1<> +#define DMF_EV_BITS ( (1<<16) | (1<<17) | (1<<18) | (1<<20) ) >> > > Don't do that. > > Granted, those bits can never be changed else all of your customers will start > a lynch mob and come after you. > > At the very least, don't allow those bits to be anonymous--copy that whole > enum from the dmapi header. Even that I object to, but at least the bits will > _be_ something. > I'll second that. It seems rather dangerous to have a #define floating around that could potentially get out of sync with the original, especially if you transport the number and not the enum table. (It make it really hard for cscope to find :-) Other than that the rest of the patch seem reasonable, it satisfies the goal of not requiring libdmapi. > Dean > > From owner-xfs@oss.sgi.com Mon Aug 7 08:53:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Aug 2006 08:53:44 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k77FrJDW029528 for ; Mon, 7 Aug 2006 08:53:19 -0700 Received: (qmail 65763 invoked from network); 7 Aug 2006 15:52:50 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 7 Aug 2006 15:52:49 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id B83D6183B7EA; Mon, 7 Aug 2006 08:52:48 -0700 (PDT) Date: Mon, 7 Aug 2006 08:52:48 -0700 From: Chris Wedgwood To: Russell Cattelan Cc: Dean Roehrich , Bill Kendall , Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump Message-ID: <20060807155248.GA22411@tuatara.stupidest.org> References: <44D10F9B.8090904@thebarn.com> <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> <44D379A6.9040200@sgi.com> <44D38D34.1010503@thebarn.com> <44D3C351.7060109@sgi.com> <20060807150324.GA8421@kickball-mn.Central.Sun.COM> <44D75C87.8050402@thebarn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D75C87.8050402@thebarn.com> X-archive-position: 8592 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 456 Lines: 11 On Mon, Aug 07, 2006 at 10:30:15AM -0500, Russell Cattelan wrote: > It seems rather dangerous to have a #define floating around that > could potentially get out of sync with the original, especially if > you transport the number and not the enum table. (It make it really > hard for cscope to find :-) If it saves a header I don't see any harm in the original approach with a comment preceding it explain what the bits are and why not to screw them up. From owner-xfs@oss.sgi.com Mon Aug 7 09:52:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Aug 2006 09:53:12 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k77GqRDW009663 for ; Mon, 7 Aug 2006 09:52:50 -0700 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k77Gq1Da028806 for ; Mon, 7 Aug 2006 10:52:01 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k77Gq0d6001063 for ; Mon, 7 Aug 2006 10:52:00 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3) with ESMTP id k77Gq0J2010529; Mon, 7 Aug 2006 11:52:00 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3/Submit) id k77GpxU9010528; Mon, 7 Aug 2006 11:51:59 -0500 (CDT) Date: Mon, 7 Aug 2006 11:51:59 -0500 From: Dean Roehrich To: Chris Wedgwood Cc: Russell Cattelan , Bill Kendall , Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump Message-ID: <20060807165159.GA10521@kickball-mn.Central.Sun.COM> References: <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> <44D379A6.9040200@sgi.com> <44D38D34.1010503@thebarn.com> <44D3C351.7060109@sgi.com> <20060807150324.GA8421@kickball-mn.Central.Sun.COM> <44D75C87.8050402@thebarn.com> <20060807155248.GA22411@tuatara.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060807155248.GA22411@tuatara.stupidest.org> User-Agent: Mutt/1.5.9i X-archive-position: 8593 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dean.roehrich@sun.com Precedence: bulk X-list: xfs Content-Length: 760 Lines: 18 On Mon, Aug 07, 2006 at 08:52:48AM -0700, Chris Wedgwood wrote: > On Mon, Aug 07, 2006 at 10:30:15AM -0500, Russell Cattelan wrote: > > > It seems rather dangerous to have a #define floating around that > > could potentially get out of sync with the original, especially if > > you transport the number and not the enum table. (It make it really > > hard for cscope to find :-) > > If it saves a header I don't see any harm in the original approach > with a comment preceding it explain what the bits are and why not to > screw them up. I agree with Russell that you want cscope to tell you about every place those bits are being used, so you want those defines or at least those symbols to show up here. Having them in a comment won't help cscope. Dean From owner-xfs@oss.sgi.com Mon Aug 7 12:14:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Aug 2006 12:15:09 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k77JEcDW032413 for ; Mon, 7 Aug 2006 12:14:48 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k77JE1nx020038 for ; Mon, 7 Aug 2006 14:14:01 -0500 Received: from [128.162.233.24] (fsgi275.americas.sgi.com [128.162.233.24]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k77JDd8s28131003; Mon, 7 Aug 2006 12:13:39 -0700 (PDT) Message-ID: <44D790E2.8030000@sgi.com> Date: Mon, 07 Aug 2006 14:13:38 -0500 From: Bill Kendall User-Agent: Mail/News 1.5 (X11/20060228) MIME-Version: 1.0 To: Dean Roehrich CC: Chris Wedgwood , Russell Cattelan , Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump References: <44D2CA85.3040208@sgi.com> <20060804141012.GA26@kickball-mn.Central.Sun.COM> <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> <44D379A6.9040200@sgi.com> <44D38D34.1010503@thebarn.com> <44D3C351.7060109@sgi.com> <20060807150324.GA8421@kickball-mn.Central.Sun.COM> <44D75C87.8050402@thebarn.com> <20060807155248.GA22411@tuatara.stupidest.org> <20060807165159.GA10521@kickball-mn.Central.Sun.COM> In-Reply-To: <20060807165159.GA10521@kickball-mn.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8594 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 1210 Lines: 32 On 08/07/06 11:51, Dean Roehrich wrote: > On Mon, Aug 07, 2006 at 08:52:48AM -0700, Chris Wedgwood wrote: >> On Mon, Aug 07, 2006 at 10:30:15AM -0500, Russell Cattelan wrote: >> >>> It seems rather dangerous to have a #define floating around that >>> could potentially get out of sync with the original, especially if >>> you transport the number and not the enum table. (It make it really >>> hard for cscope to find :-) >> If it saves a header I don't see any harm in the original approach >> with a comment preceding it explain what the bits are and why not to >> screw them up. > > I agree with Russell that you want cscope to tell you about every place those > bits are being used, so you want those defines or at least those symbols to > show up here. Having them in a comment won't help cscope. > > Dean I'll put these defines in hsmapi.c, and revert DMF_EV_BITS back to using these symbols: /* DM_EVENT_* are defined in . Trying to avoid a dmapi dependency * in xfsdump since dmapi is not commonly used, yet this code needs to know some * of the event bits. */ #define DM_EVENT_READ 16 #define DM_EVENT_WRITE 17 #define DM_EVENT_TRUNCATE 18 #define DM_EVENT_DESTROY 20 Bill From owner-xfs@oss.sgi.com Mon Aug 7 12:25:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Aug 2006 12:26:04 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k77JPcDW006220 for ; Mon, 7 Aug 2006 12:25:38 -0700 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k77JPB6S021128 for ; Mon, 7 Aug 2006 13:25:11 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (kickball-mn.Central.Sun.COM [10.1.170.217]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k77JLV8v020623 for ; Mon, 7 Aug 2006 13:21:31 -0600 (MDT) Received: from kickball-mn.Central.Sun.COM (localhost [127.0.0.1]) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3) with ESMTP id k77JPBdC017257; Mon, 7 Aug 2006 14:25:11 -0500 (CDT) Received: (from roehrich@localhost) by kickball-mn.Central.Sun.COM (8.13.4+Sun/8.13.3/Submit) id k77JPA7w017256; Mon, 7 Aug 2006 14:25:10 -0500 (CDT) Date: Mon, 7 Aug 2006 14:25:10 -0500 From: Dean Roehrich To: Bill Kendall Cc: Chris Wedgwood , Russell Cattelan , Vlad Apostolov , xfs@oss.sgi.com Subject: Re: review: Simple patch to remove the dmapi support from xfsdump Message-ID: <20060807192510.GA17251@kickball-mn.Central.Sun.COM> References: <44D36985.1090006@thebarn.com> <20060804155850.GA3338@kickball-mn.Central.Sun.COM> <44D379A6.9040200@sgi.com> <44D38D34.1010503@thebarn.com> <44D3C351.7060109@sgi.com> <20060807150324.GA8421@kickball-mn.Central.Sun.COM> <44D75C87.8050402@thebarn.com> <20060807155248.GA22411@tuatara.stupidest.org> <20060807165159.GA10521@kickball-mn.Central.Sun.COM> <44D790E2.8030000@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D790E2.8030000@sgi.com> User-Agent: Mutt/1.5.9i X-archive-position: 8595 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dean.roehrich@sun.com Precedence: bulk X-list: xfs Content-Length: 287 Lines: 10 On Mon, Aug 07, 2006 at 02:13:38PM -0500, Bill Kendall wrote: > I'll put these defines in hsmapi.c, and revert DMF_EV_BITS back to using > these symbols: I guess I'd favor copying in the whole enum. But I'm a bit more concerned about losing parts of a story than other people. Dean From owner-xfs@oss.sgi.com Mon Aug 7 20:31:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Aug 2006 20:32:02 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k783VADW005009 for ; Mon, 7 Aug 2006 20:31:21 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA10828; Tue, 8 Aug 2006 13:30:19 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k783UEgw2527542; Tue, 8 Aug 2006 13:30:14 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k783U60V2492166; Tue, 8 Aug 2006 13:30:06 +1000 (EST) Date: Tue, 8 Aug 2006 13:30:05 +1000 From: Nathan Scott To: Joe Jin , "Tony.Ho" , jdi@l4x.org, Chris Seufert Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: XFS Bug null pointer dereference in xfs_free_ag_extent Message-ID: <20060808133005.C2526901@wobbly.melbourne.sgi.com> References: <44BF29CD.1000809@l4x.org> <44CB0BF7.6030204@idccenter.cn> <44CB1303.7010303@l4x.org> <20060731094424.E2280998@wobbly.melbourne.sgi.com> <44CDA156.6000105@idccenter.cn> <20060731165522.K2280998@wobbly.melbourne.sgi.com> <44CDB135.8080401@idccenter.cn> <20060731194310.A2301615@wobbly.melbourne.sgi.com> <44CDD5B9.8020608@idccenter.cn> <215036450607311849o43b1555br13ea2f3f20fb3b82@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <215036450607311849o43b1555br13ea2f3f20fb3b82@mail.gmail.com>; from lkmaillist@gmail.com on Tue, Aug 01, 2006 at 09:49:12AM +0800 X-archive-position: 8596 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 825 Lines: 25 On Tue, Aug 01, 2006 at 09:49:12AM +0800, Joe Jin wrote: > >From the information, I think it caused by (args.agbp == NULL). > get rid of, we'll find the call trace should panic: > xfs_free_extent > |_ xfs_free_ag_extent => here args.agbp= NULL; > |_ xfs_btree_init_cursor() > |_ agf = XFS_BUF_TO_AGF(agbp); => (xfs_agf_t > *)XFS_BUF_PTR(arbp) > |_ (xfs_caddr_t)((agbp)->b_addr) : but here, > agbp is NULL > so it caused the oops. You've all reported this same issue - could any/all of you try the patch here... http://oss.sgi.com/archives/xfs/2006-08/msg00054.html Let me know if that fixes it. In particular, if you were able to easily reproduce this before, I'd like to hear whether this resolves things, as I've still not hit the bug myself. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Aug 8 00:09:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Aug 2006 00:09:48 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7879LDW005690 for ; Tue, 8 Aug 2006 00:09:32 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA14762 for ; Tue, 8 Aug 2006 17:08:43 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 39DA558C6F7C; Tue, 8 Aug 2006 17:08:43 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 952342 - xfsprogs Message-Id: <20060808070843.39DA558C6F7C@chook.melbourne.sgi.com> Date: Tue, 8 Aug 2006 17:08:43 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8597 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 4190 Lines: 72 Allow tools to use direct IO on Linux when reading from the device, if the device supports it, and if the tools is OK with that (most are). Mainly for xfs_repair speedups, now that libxfs caches metadata buffers internally. Date: Tue Aug 8 16:56:28 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: madan,sjv The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26728a xfsprogs/mkfs/xfs_mkfs.c - 1.75 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.75&r2=text&tr2=1.74&f=h xfsprogs/include/libxfs.h - 1.53 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxfs.h.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h xfsprogs/repair/sb.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/sb.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfsprogs/repair/init.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/init.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/repair/protos.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/protos.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/repair/globals.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/globals.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/repair/Makefile - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/Makefile.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/repair/phase1.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase1.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/repair/xfs_repair.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/xfs_repair.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h xfsprogs/repair/io.c - 1.12 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/io.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/libxfs/rdwr.c - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/rdwr.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h xfsprogs/libxfs/init.c - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/init.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h xfsprogs/libxfs/init.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/init.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/libxfs/linux.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/linux.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/po/Makefile - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/po/Makefile.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/libxfs/darwin.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/darwin.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/libxfs/irix.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/irix.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/libxfs/freebsd.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/freebsd.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/copy/xfs_copy.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/copy/xfs_copy.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h Bump xfsprogs version number after recent changes. Date: Tue Aug 8 17:07:53 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26733a xfsprogs/VERSION - 1.161 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.161&r2=text&tr2=1.160&f=h xfsprogs/doc/CHANGES - 1.216 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.216&r2=text&tr2=1.215&f=h xfsprogs/debian/changelog - 1.146 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.146&r2=text&tr2=1.145&f=h From owner-xfs@oss.sgi.com Tue Aug 8 07:11:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Aug 2006 07:12:05 -0700 (PDT) Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k78EBbDW005996 for ; Tue, 8 Aug 2006 07:11:44 -0700 Received: from tyo201.gate.nec.co.jp ([10.7.69.201]) by tyo200.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k78BwuMQ029889 for ; Tue, 8 Aug 2006 20:58:56 +0900 (JST) Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k78Bwul2001627; Tue, 8 Aug 2006 20:58:56 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id k78BwuS28861; Tue, 8 Aug 2006 20:58:56 +0900 (JST) Received: from anesfw.anes.nec.co.jp (fuji.anes.nec.co.jp [10.2.168.3]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id k78BwtW17254; Tue, 8 Aug 2006 20:58:55 +0900 (JST) Received: from tnesg9212 (tnesg9212) by anesfw.anes.nec.co.jp (8.13.5/8.13.5) with SMTP id k78BwsMG017657; Tue, 8 Aug 2006 20:58:54 +0900 To: Nathan Scott , David Chinner Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [PATCH 1/2] Add new spin_lock for i_flags of xfs_inode Message-Id: <20060808205855m-saito@mail.aom.tnes.nec.co.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Masayuki Saito Date: Tue, 8 Aug 2006 20:58:55 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 8600 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: m-saito@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 6405 Lines: 186 Masayuki Saito wrote: >>Worse, the i_flags field does not use atomic bitops and >>there is no consistent locking protecting i_flags so updates >>and reads of this filed can race or even get lost.... > >I agree it, too. I think that we should add new spin_lock for >i_flags. > > >>I think a fix is going to be much more invasive than just adding >>reference as my fixes appear to have only narrowed the race window >>and not solved it. The addition of the lock in the original patch >>solves the atomic xfs_iunpin()/xfs_reclaim() execution problem, >>but it does not solve the problems with the i_flags field. Adding >>a new lock may be our only option here. > >I'm considering the solution which fixes two problems([a] i_state of >the inode is changed while the inode is freed in xfs filesystem and >[b] the above i_flags problem) > >the solution: >(1)Add new spin_lock(i_flags_lock) for all refernece and change > places of all i_flags. >(2)Add igrab()/iput() for xfs_iunpin(). > >It makes sure that mark_inode_dirty_sync() is never called if >xfs_iunpin() runs after I_CLEAR is set. Because XFS_IRECLAIM >or XFS_IRECLAIMABLE is set/checked within the spin_lock. It is the problem that i_flags of xfs_inode has no consistent locking protection. For the reason, I define a new spin_lock(i_flags_lock) for i_flags of xfs_inode. And I add this spin_lock for appropriate places. I divided into two patches. A summary of patches is as follows. [1/2] add a new lock for i_flags of xfs_inode [2/2] fix i_state of the inode is changed after the inode is freed I have tested the two patches and confirmed with these patches that the inode of i_state is not changed after the inode is freed. Appreciate any comments and feedbacks. Signed-off-by: Masayuki Saito --- --- linux-2.6.17.7/fs/xfs/xfs_inode.h.orig 2006-07-29 15:41:28.570341641 +0900 +++ linux-2.6.17.7/fs/xfs/xfs_inode.h 2006-08-01 02:51:53.598587423 +0900 @@ -267,6 +267,7 @@ typedef struct xfs_inode { sema_t i_flock; /* inode flush lock */ atomic_t i_pincount; /* inode pin count */ wait_queue_head_t i_ipin_wait; /* inode pinning wait queue */ + spinlock_t i_flags_lock; /* inode i_flags lock */ #ifdef HAVE_REFCACHE struct xfs_inode **i_refcache; /* ptr to entry in ref cache */ struct xfs_inode *i_release; /* inode to unref */ --- linux-2.6.17.7/fs/xfs/xfs_inode.c.orig 2006-07-29 15:41:39.050936181 +0900 +++ linux-2.6.17.7/fs/xfs/xfs_inode.c 2006-08-01 14:13:51.615782806 +0900 @@ -861,6 +861,7 @@ xfs_iread( ip = kmem_zone_zalloc(xfs_inode_zone, KM_SLEEP); ip->i_ino = ino; ip->i_mount = mp; + spin_lock_init(&ip->i_flags_lock); /* * Get pointer's to the on-disk inode and the buffer containing it. @@ -2204,7 +2205,9 @@ xfs_ifree_cluster( if (ip == free_ip) { if (xfs_iflock_nowait(ip)) { + spin_lock(&ip->i_flags_lock); ip->i_flags |= XFS_ISTALE; + spin_unlock(&ip->i_flags_lock); if (xfs_inode_clean(ip)) { xfs_ifunlock(ip); @@ -2218,7 +2221,9 @@ xfs_ifree_cluster( if (xfs_ilock_nowait(ip, XFS_ILOCK_EXCL)) { if (xfs_iflock_nowait(ip)) { + spin_lock(&ip->i_flags_lock); ip->i_flags |= XFS_ISTALE; + spin_unlock(&ip->i_flags_lock); if (xfs_inode_clean(ip)) { xfs_ifunlock(ip); @@ -2248,7 +2253,9 @@ xfs_ifree_cluster( AIL_LOCK(mp,s); iip->ili_flush_lsn = iip->ili_item.li_lsn; AIL_UNLOCK(mp, s); + spin_lock(&iip->ili_inode->i_flags_lock); iip->ili_inode->i_flags |= XFS_ISTALE; + spin_unlock(&iip->ili_inode->i_flags_lock); pre_flushed++; } lip = lip->li_bio_list; --- linux-2.6.17.7/fs/xfs/xfs_itable.c.orig 2006-07-29 15:41:52.071674818 +0900 +++ linux-2.6.17.7/fs/xfs/xfs_itable.c 2006-08-01 02:51:53.698593096 +0900 @@ -559,6 +559,7 @@ xfs_bulkstat( KM_SLEEP); ip->i_ino = ino; ip->i_mount = mp; + spin_lock_init(&ip->i_flags_lock); if (bp) xfs_buf_relse(bp); error = xfs_itobp(mp, NULL, ip, --- linux-2.6.17.7/fs/xfs/xfs_iget.c.orig 2006-07-29 15:42:03.992351051 +0900 +++ linux-2.6.17.7/fs/xfs/xfs_iget.c 2006-08-01 21:17:58.173213088 +0900 @@ -246,7 +246,9 @@ again: XFS_STATS_INC(xs_ig_found); + spin_lock(&ip->i_flags_lock); ip->i_flags &= ~XFS_IRECLAIMABLE; + spin_unlock(&ip->i_flags_lock); version = ih->ih_version; read_unlock(&ih->ih_lock); xfs_ihash_promote(ih, ip, version); @@ -300,7 +302,9 @@ finish_inode: if (lock_flags != 0) xfs_ilock(ip, lock_flags); + spin_lock(&ip->i_flags_lock); ip->i_flags &= ~XFS_ISTALE; + spin_unlock(&ip->i_flags_lock); vn_trace_exit(vp, "xfs_iget.found", (inst_t *)__return_address); @@ -371,7 +375,9 @@ finish_inode: ih->ih_next = ip; ip->i_udquot = ip->i_gdquot = NULL; ih->ih_version++; + spin_lock(&ip->i_flags_lock); ip->i_flags |= XFS_INEW; + spin_unlock(&ip->i_flags_lock); write_unlock(&ih->ih_lock); --- linux-2.6.17.7/fs/xfs/xfs_vnodeops.c.orig 2006-07-29 15:42:40.182404031 +0900 +++ linux-2.6.17.7/fs/xfs/xfs_vnodeops.c 2006-08-02 03:43:12.163597123 +0900 @@ -3836,7 +3836,9 @@ xfs_reclaim( XFS_MOUNT_ILOCK(mp); vn_bhv_remove(VN_BHV_HEAD(vp), XFS_ITOBHV(ip)); list_add_tail(&ip->i_reclaim, &mp->m_del_inodes); + spin_lock(&ip->i_flags_lock); ip->i_flags |= XFS_IRECLAIMABLE; + spin_unlock(&ip->i_flags_lock); XFS_MOUNT_IUNLOCK(mp); } return 0; @@ -3861,8 +3863,10 @@ xfs_finish_reclaim( * us. */ write_lock(&ih->ih_lock); + spin_lock(&ip->i_flags_lock); if ((ip->i_flags & XFS_IRECLAIM) || (!(ip->i_flags & XFS_IRECLAIMABLE) && vp == NULL)) { + spin_unlock(&ip->i_flags_lock); write_unlock(&ih->ih_lock); if (locked) { xfs_ifunlock(ip); @@ -3871,6 +3875,7 @@ xfs_finish_reclaim( return 1; } ip->i_flags |= XFS_IRECLAIM; + spin_unlock(&ip->i_flags_lock); write_unlock(&ih->ih_lock); /* --- linux-2.6.17.7/fs/xfs/linux-2.6/xfs_super.c.orig 2006-07-29 15:43:17.768536207 +0900 +++ linux-2.6.17.7/fs/xfs/linux-2.6/xfs_super.c 2006-08-01 13:23:09.934740893 +0900 @@ -230,7 +230,9 @@ xfs_initialize_vnode( xfs_revalidate_inode(XFS_BHVTOM(bdp), vp, ip); xfs_set_inodeops(inode); + spin_lock(&ip->i_flags_lock); ip->i_flags &= ~XFS_INEW; + spin_unlock(&ip->i_flags_lock); barrier(); unlock_new_inode(inode); $B!!!!(B From owner-xfs@oss.sgi.com Tue Aug 8 15:55:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Aug 2006 15:55:51 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k78Mt8DW016183 for ; Tue, 8 Aug 2006 15:55:20 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA07562; Wed, 9 Aug 2006 08:54:18 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k78MsFgw2553366; Wed, 9 Aug 2006 08:54:15 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k78MsBqG2553561; Wed, 9 Aug 2006 08:54:11 +1000 (EST) Date: Wed, 9 Aug 2006 08:54:11 +1000 From: Nathan Scott To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH] kill iop_abort item_op Message-ID: <20060809085411.N2526901@wobbly.melbourne.sgi.com> References: <44D41AB0.3050808@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44D41AB0.3050808@sandeen.net>; from sandeen@sandeen.net on Fri, Aug 04, 2006 at 11:12:32PM -0500 X-archive-position: 8602 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 198 Lines: 10 On Fri, Aug 04, 2006 at 11:12:32PM -0500, Eric Sandeen wrote: > It doesn't look like this is ever used for anything...? Nice catch, will get that merged shortly, thanks Eric. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Aug 8 16:35:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Aug 2006 16:36:25 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k78NZhDW026095 for ; Tue, 8 Aug 2006 16:35:56 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA08569; Wed, 9 Aug 2006 09:34:59 +1000 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 k78NYQEo49006990; Wed, 9 Aug 2006 09:34:27 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k78NYPxb49195151; Wed, 9 Aug 2006 09:34:25 +1000 (AEST) Date: Wed, 9 Aug 2006 09:34:25 +1000 From: David Chinner To: Cosmo Nova Cc: linux-xfs@oss.sgi.com Subject: Re: file system defragmentation Message-ID: <20060808233425.GQ2114946@melbourne.sgi.com> References: <4f52331f050826001612f8e323@mail.gmail.com> <20050826101131.GA24544@ii.uib.no> <4f52331f0508260848782f240a@mail.gmail.com> <43112C5D.8090202@sgi.com> <20050828034108.73921.qmail@web34103.mail.mud.yahoo.com> <5408752.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5408752.post@talk.nabble.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8603 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 556 Lines: 18 On Wed, Jul 19, 2006 at 09:23:42PM -0700, Cosmo Nova wrote: > > what is the maximum tolerance for the delayed allocations pls? I guess it's > not possible to buf a GB size file and delay its allocation? Sure it is. The limit on how much is buffered before writeback (and therefore allocation) is determined by how much memory you have and your /proc/sys/vm/dirty* tunable settings. This can range from a few MB to a few TB of data depending on how big your machine is ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Aug 8 18:08:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Aug 2006 18:09:08 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7918GDW005323 for ; Tue, 8 Aug 2006 18:08:27 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10432; Wed, 9 Aug 2006 11:07:28 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7917Ogw2557319; Wed, 9 Aug 2006 11:07:25 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7917I6I2554467; Wed, 9 Aug 2006 11:07:18 +1000 (EST) Date: Wed, 9 Aug 2006 11:07:18 +1000 From: Nathan Scott To: Masayuki Saito Cc: David Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] Add new spin_lock for i_flags of xfs_inode Message-ID: <20060809110718.B2508736@wobbly.melbourne.sgi.com> References: <20060808205855m-saito@mail.aom.tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060808205855m-saito@mail.aom.tnes.nec.co.jp>; from m-saito@tnes.nec.co.jp on Tue, Aug 08, 2006 at 08:58:55PM +0900 X-archive-position: 8604 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 509 Lines: 17 On Tue, Aug 08, 2006 at 08:58:55PM +0900, Masayuki Saito wrote: > It is the problem that i_flags of xfs_inode has no consistent > locking protection. > > For the reason, I define a new spin_lock(i_flags_lock) for i_flags > of xfs_inode. And I add this spin_lock for appropriate places. Thanks Masayuki. I've queued these two patches in my test kernels, and if Dave has no more comments, I will get this merged soon (probably 2.6.19 material, as its not had much exposure yet afaik). cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Aug 8 18:26:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Aug 2006 18:26:37 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k791PxDW008008 for ; Tue, 8 Aug 2006 18:26:10 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10791; Wed, 9 Aug 2006 11:25:18 +1000 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 k791OkEo47742600; Wed, 9 Aug 2006 11:24:46 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k791OiUV49433769; Wed, 9 Aug 2006 11:24:44 +1000 (AEST) Date: Wed, 9 Aug 2006 11:24:44 +1000 From: David Chinner To: Nathan Scott Cc: Eric Sandeen , dgc@sgi.com, xfs@oss.sgi.com Subject: Re: [PATCH] kill no-op buf macros Message-ID: <20060809012444.GS2114946@melbourne.sgi.com> References: <44CC2A55.6030207@sandeen.net> <20060731090815.B2280998@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060731090815.B2280998@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8605 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2229 Lines: 64 On Mon, Jul 31, 2006 at 09:08:15AM +1000, Nathan Scott wrote: > On Sat, Jul 29, 2006 at 10:41:09PM -0500, Eric Sandeen wrote: > > It looks like these macros are not particularly interesting... this patch kills > > them. > > Hmm, I'm not sure about some of these.. > > > #define XFS_BUF_BUSY(bp) do { } while (0) > > #define XFS_BUF_ISBUSY(bp) (1) > > This ones used on 2.4, I'd like to get Daves thoughts on whether > we do the right thing here based on his buffer cache fu. XFS_BUF_ISBUSY() is only ever used in ASSERT() statements, so I think that can go. On 2.4: #define XFS_BUF_BUSY(bp) ((bp)->b_flags |= XBF_FORCEIO) The XBF_FORCEIO affects how we do partial page I/O on 2.4, but is unused on 2.6. On 2.4, if the flag is set, we ignore the buffer_uptodate() status of the buffers on the page and re-read all the buffers in the range specified. For writes, we always write all the buffers on the page. The flag is set when we issue direct I/O or in xfs_buf_get_noaddr() which is used to allocate log buffers and buffers for block zeroing. This seems sane to me given the way we use bufferheads in 2.4.... > > #define XFS_BUF_SHUT(bp) do { } while (0) > > #define XFS_BUF_UNSHUT(bp) do { } while (0) > > #define XFS_BUF_ISSHUT(bp) (0) > > Ditto (not used on 2.4 though, but still maybe we should be doing > something here). IIRC, these were used to indicate that the buffers we're throwing away on filesystem shutdown during I/O completion. This is the irix mechanism for throwing away delwri buffers on shutdown - we don't use this on linux so I think we can kill these. > > #define XFS_BUF_SET_START(bp) do { } while (0) > > Not sure what this used to do - Dave? On Irix, that writes the current kernel time in to the buffer so that the delwri flush code can tell when it is old enough to flush. Wwe do that differently in linux, so this can be removed, methinks. > > #define XFS_BUF_SET_VTYPE_REF(bp, type, ref) do { } while (0) > > #define XFS_BUF_SET_VTYPE(bp, type) do { } while (0) > > #define XFS_BUF_SET_REF(bp, ref) do { } while (0) > > These ones should probably be implemented properly, not removed. *nod* Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Aug 8 19:44:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Aug 2006 19:44:47 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k792iJDW016766 for ; Tue, 8 Aug 2006 19:44:20 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 616851809E742; Tue, 8 Aug 2006 21:43:50 -0500 (CDT) Message-ID: <44D94BE5.7020503@sandeen.net> Date: Tue, 08 Aug 2006 21:43:49 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: David Chinner Cc: Nathan Scott , xfs@oss.sgi.com Subject: Re: [PATCH] kill no-op buf macros References: <44CC2A55.6030207@sandeen.net> <20060731090815.B2280998@wobbly.melbourne.sgi.com> <20060809012444.GS2114946@melbourne.sgi.com> In-Reply-To: <20060809012444.GS2114946@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8606 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1153 Lines: 31 David Chinner wrote: > On Mon, Jul 31, 2006 at 09:08:15AM +1000, Nathan Scott wrote: >> On Sat, Jul 29, 2006 at 10:41:09PM -0500, Eric Sandeen wrote: >>> It looks like these macros are not particularly interesting... this patch kills >>> them. >> Hmm, I'm not sure about some of these.. >> >>> #define XFS_BUF_BUSY(bp) do { } while (0) >>> #define XFS_BUF_ISBUSY(bp) (1) >> This ones used on 2.4, I'd like to get Daves thoughts on whether >> we do the right thing here based on his buffer cache fu. > > XFS_BUF_ISBUSY() is only ever used in ASSERT() statements, so I > think that can go. On 2.4: > > #define XFS_BUF_BUSY(bp) ((bp)->b_flags |= XBF_FORCEIO) > > The XBF_FORCEIO affects how we do partial page I/O on 2.4, but is > unused on 2.6. On 2.4, if the flag is set, we ignore the > buffer_uptodate() status of the buffers on the page and re-read all > the buffers in the range specified. For writes, we always write all > the buffers on the page. Hm, 2.4 just seemed so old by now I forgot all about it :) Sorry about that, thanks for the comments, I'll re-jigger taking this (and the rest of your comments) into account. Thanks, -Eric From owner-xfs@oss.sgi.com Tue Aug 8 20:15:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Aug 2006 20:15:22 -0700 (PDT) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k793EwDW019988 for ; Tue, 8 Aug 2006 20:15:08 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k793KUDu45262058; Tue, 8 Aug 2006 20:20:30 -0700 (PDT) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id k793EKSQ20555814; Tue, 8 Aug 2006 22:14:20 -0500 (CDT) Received: by attica.americas.sgi.com (Postfix, from userid 2022) id EC1B71DD718; Tue, 8 Aug 2006 22:14:19 -0500 (CDT) To: xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: TAKE 955273 - Message-Id: <20060809031419.EC1B71DD718@attica.americas.sgi.com> Date: Tue, 8 Aug 2006 22:14:19 -0500 (CDT) From: wkendall@sgi.com (Bill Kendall) X-archive-position: 8607 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 2409 Lines: 40 Remove xfsdump's dependency on libdm by substituting libdm calls with existing routines in libhandle. Date: Tue Aug 8 20:12:52 PDT 2006 Workarea: attica.americas.sgi.com:/data/lwork/attica2/wkendall/stout/work/pl_root/xfs Inspected by: dean.roehrich@sun.com,cattelan@thebarn.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:213628a xfsdump/configure.in - 1.41 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/configure.in.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h xfsdump/VERSION - 1.83 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/VERSION.diff?r1=text&tr1=1.83&r2=text&tr2=1.82&f=h xfsdump/doc/CHANGES - 1.95 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/doc/CHANGES.diff?r1=text&tr1=1.95&r2=text&tr2=1.94&f=h xfsdump/dump/Makefile - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/dump/Makefile.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsdump/build/rpm/xfsdump.spec.in - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/build/rpm/xfsdump.spec.in.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsdump/include/builddefs.in - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/include/builddefs.in.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h xfsdump/restore/Makefile - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/Makefile.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsdump/debian/control - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/debian/control.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h xfsdump/debian/shlibs.local - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/debian/shlibs.local.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/aclocal.m4 - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/aclocal.m4.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfsdump/m4/package_dmapidev.m4 - 1.3 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/m4/package_dmapidev.m4.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfsdump/m4/Makefile - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/m4/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h xfsdump/common/hsmapi.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/hsmapi.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h From owner-xfs@oss.sgi.com Wed Aug 9 21:29:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Aug 2006 21:29:47 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7A4TCDW024597 for ; Wed, 9 Aug 2006 21:29:21 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA17369; Thu, 10 Aug 2006 14:28:29 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 15F8F58C6F7C; Thu, 10 Aug 2006 14:28:29 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 955303 - fix xfs_free_extent NULL dereference Message-Id: <20060810042829.15F8F58C6F7C@chook.melbourne.sgi.com> Date: Thu, 10 Aug 2006 14:28:29 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8613 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1154 Lines: 28 Fix xfs_free_extent related NULL pointer dereference. We recently fixed an out-of-space deadlock in XFS, and part of that fix involved the addition of the XFS_ALLOC_FLAG_FREEING flag to some of the space allocator calls to indicate they're freeing space, not allocating it. There was a missed xfs_alloc_fix_freelist condition test that did not correctly test "flags". The same test would also test an uninitialised structure field (args->userdata) and depending on its value either would or would not return early with a critical buffer pointer set to NULL. This fixes that up, adds asserts to several places to catch future botches of this nature, and skips sections of xfs_alloc_fix_freelist that are irrelevent for the space-freeing case. Date: Thu Aug 10 14:27:43 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26743a xfs_alloc.c - 1.183 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.183&r2=text&tr2=1.182&f=h From owner-xfs@oss.sgi.com Wed Aug 9 21:19:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Aug 2006 21:19:39 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7A4J0DW022608 for ; Wed, 9 Aug 2006 21:19:11 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA17227 for ; Thu, 10 Aug 2006 14:18:21 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7A4IJgw2588049 for ; Thu, 10 Aug 2006 14:18:20 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7A4III32587767 for xfs@oss.sgi.com; Thu, 10 Aug 2006 14:18:18 +1000 (EST) Date: Thu, 10 Aug 2006 14:18:17 +1000 From: Nathan Scott To: xfs@oss.sgi.com Subject: Re: review: catch large memory allocations Message-ID: <20060810141817.B2585102@wobbly.melbourne.sgi.com> References: <20060802170431.A2356368@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060802170431.A2356368@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Aug 02, 2006 at 05:04:31PM +1000 X-archive-position: 8612 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 6942 Lines: 195 On Wed, Aug 02, 2006 at 05:04:31PM +1000, Nathan Scott wrote: > As discussed the other day, this is primarily a debugging patch > to catch allocations that are unexpectedly large or dipping into > vmalloc space. Turns out that log recovery at least still needs to dip into vmalloc space, so here's an updated version of the patch with that warning no longer there. cheers. -- Nathan Index: xfs-linux/linux-2.4/kmem.c =================================================================== --- xfs-linux.orig/linux-2.4/kmem.c 2006-08-09 14:14:50.362431250 +1000 +++ xfs-linux/linux-2.4/kmem.c 2006-08-10 11:53:39.103452500 +1000 @@ -53,6 +53,14 @@ kmem_alloc(size_t size, int flags) int retries = 0, lflags = kmem_flags_convert(flags); void *ptr; +#ifdef DEBUG + if (unlikely(!(flags & KM_LARGE) && (size > PAGE_SIZE))) { + printk(KERN_WARNING "Large %s attempt, size=%ld\n", + __FUNCTION__, (long)size); + dump_stack(); + } +#endif + do { if (size < MAX_SLAB_SIZE || retries > MAX_VMALLOCS) ptr = kmalloc(size, lflags); Index: xfs-linux/linux-2.6/kmem.c =================================================================== --- xfs-linux.orig/linux-2.6/kmem.c 2006-08-09 14:14:50.502370000 +1000 +++ xfs-linux/linux-2.6/kmem.c 2006-08-10 11:53:39.167488500 +1000 @@ -34,6 +34,14 @@ kmem_alloc(size_t size, unsigned int __n gfp_t lflags = kmem_flags_convert(flags); void *ptr; +#ifdef DEBUG + if (unlikely(!(flags & KM_LARGE) && (size > PAGE_SIZE))) { + printk(KERN_WARNING "Large %s attempt, size=%ld\n", + __FUNCTION__, (long)size); + dump_stack(); + } +#endif + do { if (size < MAX_SLAB_SIZE || retries > MAX_VMALLOCS) ptr = kmalloc(size, lflags); Index: xfs-linux/linux-2.6/kmem.h =================================================================== --- xfs-linux.orig/linux-2.6/kmem.h 2006-08-09 14:14:50.578336750 +1000 +++ xfs-linux/linux-2.6/kmem.h 2006-08-10 11:53:39.203508750 +1000 @@ -30,6 +30,7 @@ #define KM_NOSLEEP 0x0002u #define KM_NOFS 0x0004u #define KM_MAYFAIL 0x0008u +#define KM_LARGE 0x0010u /* * We use a special process flag to avoid recursive callbacks into @@ -41,7 +42,7 @@ kmem_flags_convert(unsigned int __nocast { gfp_t lflags; - BUG_ON(flags & ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS|KM_MAYFAIL)); + BUG_ON(flags & ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS|KM_MAYFAIL|KM_LARGE)); if (flags & KM_NOSLEEP) { lflags = GFP_ATOMIC | __GFP_NOWARN; Index: xfs-linux/linux-2.4/kmem.h =================================================================== --- xfs-linux.orig/linux-2.4/kmem.h 2006-08-09 14:14:50.430401500 +1000 +++ xfs-linux/linux-2.4/kmem.h 2006-08-10 11:53:39.135470500 +1000 @@ -29,6 +29,7 @@ #define KM_NOSLEEP 0x0002 #define KM_NOFS 0x0004 #define KM_MAYFAIL 0x0008 +#define KM_LARGE 0x0010 /* * We use a special process flag to avoid recursive callbacks into @@ -40,7 +41,7 @@ kmem_flags_convert(int flags) { int lflags; - BUG_ON(flags & ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS|KM_MAYFAIL)); + BUG_ON(flags & ~(KM_SLEEP|KM_NOSLEEP|KM_NOFS|KM_MAYFAIL|KM_LARGE)); if (flags & KM_NOSLEEP) { lflags = GFP_ATOMIC; Index: xfs-linux/support/ktrace.c =================================================================== --- xfs-linux.orig/support/ktrace.c 2006-08-09 14:14:50.654303500 +1000 +++ xfs-linux/support/ktrace.c 2006-08-10 11:49:57.882810000 +1000 @@ -75,7 +75,7 @@ ktrace_alloc(int nentries, unsigned int sleep); } else { ktep = (ktrace_entry_t*)kmem_zalloc((nentries * sizeof(*ktep)), - sleep); + sleep | KM_LARGE); } if (ktep == NULL) { Index: xfs-linux/linux-2.6/xfs_buf.c =================================================================== --- xfs-linux.orig/linux-2.6/xfs_buf.c 2006-08-09 14:15:34.155263500 +1000 +++ xfs-linux/linux-2.6/xfs_buf.c 2006-08-10 11:54:06.572962750 +1000 @@ -773,7 +773,7 @@ xfs_buf_get_noaddr( _xfs_buf_initialize(bp, target, 0, len, 0); try_again: - data = kmem_alloc(malloc_len, KM_SLEEP | KM_MAYFAIL); + data = kmem_alloc(malloc_len, KM_SLEEP | KM_MAYFAIL | KM_LARGE); if (unlikely(data == NULL)) goto fail_free_buf; Index: xfs-linux/linux-2.4/xfs_buf.c =================================================================== --- xfs-linux.orig/linux-2.4/xfs_buf.c 2006-08-09 14:14:50.466385750 +1000 +++ xfs-linux/linux-2.4/xfs_buf.c 2006-08-10 11:54:31.058493000 +1000 @@ -875,7 +875,7 @@ xfs_buf_get_noaddr( _xfs_buf_initialize(bp, target, 0, len, XBF_FORCEIO); try_again: - data = kmem_alloc(malloc_len, KM_SLEEP | KM_MAYFAIL); + data = kmem_alloc(malloc_len, KM_SLEEP | KM_MAYFAIL | KM_LARGE); if (unlikely(data == NULL)) goto fail_free_buf; Index: xfs-linux/xfs_log.c =================================================================== --- xfs-linux.orig/xfs_log.c 2006-08-09 14:15:34.103286250 +1000 +++ xfs-linux/xfs_log.c 2006-08-09 14:15:34.503111250 +1000 @@ -1226,7 +1226,7 @@ xlog_alloc_log(xfs_mount_t *mp, kmem_zalloc(sizeof(xlog_in_core_t), KM_SLEEP); iclog = *iclogp; iclog->hic_data = (xlog_in_core_2_t *) - kmem_zalloc(iclogsize, KM_SLEEP); + kmem_zalloc(iclogsize, KM_SLEEP | KM_LARGE); iclog->ic_prev = prev_iclog; prev_iclog = iclog; Index: xfs-linux/xfs_iget.c =================================================================== --- xfs-linux.orig/xfs_iget.c 2006-08-09 14:14:50.722273750 +1000 +++ xfs-linux/xfs_iget.c 2006-08-10 11:53:39.267544750 +1000 @@ -50,7 +50,7 @@ void xfs_ihash_init(xfs_mount_t *mp) { __uint64_t icount; - uint i, flags = KM_SLEEP | KM_MAYFAIL; + uint i, flags = KM_SLEEP | KM_MAYFAIL | KM_LARGE; if (!mp->m_ihsize) { icount = mp->m_maxicount ? mp->m_maxicount : @@ -95,7 +95,7 @@ xfs_chash_init(xfs_mount_t *mp) mp->m_chsize = min_t(uint, mp->m_chsize, mp->m_ihsize); mp->m_chash = (xfs_chash_t *)kmem_zalloc(mp->m_chsize * sizeof(xfs_chash_t), - KM_SLEEP); + KM_SLEEP | KM_LARGE); for (i = 0; i < mp->m_chsize; i++) { spinlock_init(&mp->m_chash[i].ch_lock,"xfshash"); } Index: xfs-linux/quota/xfs_qm.c =================================================================== --- xfs-linux.orig/quota/xfs_qm.c 2006-08-09 14:15:33.359611750 +1000 +++ xfs-linux/quota/xfs_qm.c 2006-08-10 11:53:39.235526750 +1000 @@ -112,17 +112,17 @@ xfs_Gqm_init(void) { xfs_dqhash_t *udqhash, *gdqhash; xfs_qm_t *xqm; - uint i, hsize, flags = KM_SLEEP | KM_MAYFAIL; + uint i, hsize, flags = KM_SLEEP | KM_MAYFAIL | KM_LARGE; /* * Initialize the dquot hash tables. */ hsize = XFS_QM_HASHSIZE_HIGH; - while (!(udqhash = kmem_zalloc(hsize * sizeof(xfs_dqhash_t), flags))) { + while (!(udqhash = kmem_zalloc(hsize * sizeof(*udqhash), flags))) { if ((hsize >>= 1) <= XFS_QM_HASHSIZE_LOW) flags = KM_SLEEP; } - gdqhash = kmem_zalloc(hsize * sizeof(xfs_dqhash_t), KM_SLEEP); + gdqhash = kmem_zalloc(hsize * sizeof(*gdqhash), KM_SLEEP | KM_LARGE); ndquot = hsize << 8; xqm = kmem_zalloc(sizeof(xfs_qm_t), KM_SLEEP); From owner-xfs@oss.sgi.com Wed Aug 9 22:49:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Aug 2006 22:49:58 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7A5nBDW002906 for ; Wed, 9 Aug 2006 22:49:23 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA19037; Thu, 10 Aug 2006 15:48:24 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7A5mLgw2563794; Thu, 10 Aug 2006 15:48:21 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7A5mIwo2590278; Thu, 10 Aug 2006 15:48:18 +1000 (EST) Date: Thu, 10 Aug 2006 15:48:18 +1000 From: Nathan Scott To: Greg KH Cc: Linus Torvalds , Andrew Morton , xfs@oss.sgi.com Subject: XFS fix for 2.6.18-rc5 Message-ID: <20060810154817.A2591606@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8614 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1336 Lines: 39 Hi Greg, Please pull from: git://oss.sgi.com:8090/nathans/xfs-rc-2.6 This will update the following files: fs/xfs/xfs_alloc.c | 103 +++++++++++++++++++++++++++------------------------- 1 files changed, 54 insertions(+), 49 deletions(-) through these commits: commit 0e1edbd99994270023cea5afe593f972eb09a778 Author: Nathan Scott Date: Thu Aug 10 14:40:41 2006 +1000 [XFS] Fix xfs_free_extent related NULL pointer dereference. We recently fixed an out-of-space deadlock in XFS, and part of that fix involved the addition of the XFS_ALLOC_FLAG_FREEING flag to some of the space allocator calls to indicate they're freeing space, not allocating it. There was a missed xfs_alloc_fix_freelist condition test that did not correctly test "flags". The same test would also test an uninitialised structure field (args->userdata) and depending on its value either would or would not return early with a critical buffer pointer set to NULL. This fixes that up, adds asserts to several places to catch future botches of this nature, and skips sections of xfs_alloc_fix_freelist that are irrelevent for the space-freeing case. SGI-PV: 955303 SGI-Modid: xfs-linux-melb:xfs-kern:26743a Signed-off-by: Nathan Scott -- Nathan From owner-xfs@oss.sgi.com Wed Aug 9 22:53:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Aug 2006 22:53:53 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7A5rBDW003612 for ; Wed, 9 Aug 2006 22:53:25 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA19071 for ; Thu, 10 Aug 2006 15:52:32 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7A5qVgw2591511 for ; Thu, 10 Aug 2006 15:52:31 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7A5qTPU2590997 for xfs@oss.sgi.com; Thu, 10 Aug 2006 15:52:29 +1000 (EST) Date: Thu, 10 Aug 2006 15:52:29 +1000 From: Nathan Scott To: xfs@oss.sgi.com Subject: Re: review: greedy allocation interface Message-ID: <20060810155229.B2591606@wobbly.melbourne.sgi.com> References: <20060802170636.B2356368@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060802170636.B2356368@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Aug 02, 2006 at 05:06:36PM +1000 X-archive-position: 8615 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 6633 Lines: 197 On Wed, Aug 02, 2006 at 05:06:36PM +1000, Nathan Scott wrote: > As discussed. Slightly different interface, it was a bit simpler > to have both min/max passed in separately to the passed out size. There was a buglet in handling the maximum sizing of a couple of the hash table caches earlier, here is a fixed version. cheers. -- Nathan Index: xfs-linux/linux-2.4/kmem.c =================================================================== --- xfs-linux.orig/linux-2.4/kmem.c 2006-08-09 13:51:42.888636500 +1000 +++ xfs-linux/linux-2.4/kmem.c 2006-08-09 13:59:05.117873750 +1000 @@ -85,6 +85,19 @@ kmem_zalloc(size_t size, int flags) return ptr; } +void * +kmem_zalloc_greedy(size_t *size, size_t minsize, size_t maxsize, int flags) +{ + void *ptr; + + while (!(ptr = kmem_zalloc(maxsize, flags))) { + if ((maxsize >>= 1) <= minsize) + flags = KM_SLEEP; + } + *size = maxsize; + return ptr; +} + void kmem_free(void *ptr, size_t size) { Index: xfs-linux/linux-2.4/kmem.h =================================================================== --- xfs-linux.orig/linux-2.4/kmem.h 2006-08-09 13:51:04.753328000 +1000 +++ xfs-linux/linux-2.4/kmem.h 2006-08-09 13:59:05.149875750 +1000 @@ -54,8 +54,9 @@ kmem_flags_convert(int flags) } extern void *kmem_alloc(size_t, int); -extern void *kmem_realloc(void *, size_t, size_t, int); extern void *kmem_zalloc(size_t, int); +extern void *kmem_zalloc_greedy(size_t *, size_t, size_t, int); +extern void *kmem_realloc(void *, size_t, size_t, int); extern void kmem_free(void *, size_t); /* Index: xfs-linux/linux-2.6/kmem.c =================================================================== --- xfs-linux.orig/linux-2.6/kmem.c 2006-08-09 13:51:49.849589750 +1000 +++ xfs-linux/linux-2.6/kmem.c 2006-08-09 13:59:05.237881250 +1000 @@ -68,6 +68,20 @@ kmem_zalloc(size_t size, unsigned int __ return ptr; } +void * +kmem_zalloc_greedy(size_t *size, size_t minsize, size_t maxsize, + unsigned int __nocast flags) +{ + void *ptr; + + while (!(ptr = kmem_zalloc(maxsize, flags))) { + if ((maxsize >>= 1) <= minsize) + flags = KM_SLEEP; + } + *size = maxsize; + return ptr; +} + void kmem_free(void *ptr, size_t size) { Index: xfs-linux/linux-2.6/kmem.h =================================================================== --- xfs-linux.orig/linux-2.6/kmem.h 2006-08-09 13:51:04.889268500 +1000 +++ xfs-linux/linux-2.6/kmem.h 2006-08-09 13:59:05.273883500 +1000 @@ -55,8 +55,9 @@ kmem_flags_convert(unsigned int __nocast } extern void *kmem_alloc(size_t, unsigned int __nocast); -extern void *kmem_realloc(void *, size_t, size_t, unsigned int __nocast); extern void *kmem_zalloc(size_t, unsigned int __nocast); +extern void *kmem_zalloc_greedy(size_t *, size_t, size_t, unsigned int __nocast); +extern void *kmem_realloc(void *, size_t, size_t, unsigned int __nocast); extern void kmem_free(void *, size_t); /* Index: xfs-linux/quota/xfs_qm.c =================================================================== --- xfs-linux.orig/quota/xfs_qm.c 2006-08-09 13:51:04.969233500 +1000 +++ xfs-linux/quota/xfs_qm.c 2006-08-09 13:59:05.365889250 +1000 @@ -112,17 +112,16 @@ xfs_Gqm_init(void) { xfs_dqhash_t *udqhash, *gdqhash; xfs_qm_t *xqm; - uint i, hsize, flags = KM_SLEEP | KM_MAYFAIL | KM_LARGE; + uint i, hsize; /* * Initialize the dquot hash tables. */ - hsize = XFS_QM_HASHSIZE_HIGH; - while (!(udqhash = kmem_zalloc(hsize * sizeof(*udqhash), flags))) { - if ((hsize >>= 1) <= XFS_QM_HASHSIZE_LOW) - flags = KM_SLEEP; - } - gdqhash = kmem_zalloc(hsize * sizeof(*gdqhash), KM_SLEEP | KM_LARGE); + udqhash = kmem_zalloc_greedy(&hsize, + XFS_QM_HASHSIZE_LOW, XFS_QM_HASHSIZE_HIGH, + KM_SLEEP | KM_MAYFAIL | KM_LARGE); + gdqhash = kmem_zalloc(hsize, KM_SLEEP | KM_LARGE); + hsize /= sizeof(xfs_dqhash_t); ndquot = hsize << 8; xqm = kmem_zalloc(sizeof(xfs_qm_t), KM_SLEEP); Index: xfs-linux/xfs_iget.c =================================================================== --- xfs-linux.orig/xfs_iget.c 2006-08-09 13:51:05.049198500 +1000 +++ xfs-linux/xfs_iget.c 2006-08-09 14:03:31.392278750 +1000 @@ -50,7 +50,7 @@ void xfs_ihash_init(xfs_mount_t *mp) { __uint64_t icount; - uint i, flags = KM_SLEEP | KM_MAYFAIL | KM_LARGE; + uint i; if (!mp->m_ihsize) { icount = mp->m_maxicount ? mp->m_maxicount : @@ -61,14 +61,13 @@ xfs_ihash_init(xfs_mount_t *mp) (64 * NBPP) / sizeof(xfs_ihash_t)); } - while (!(mp->m_ihash = (xfs_ihash_t *)kmem_zalloc(mp->m_ihsize * - sizeof(xfs_ihash_t), flags))) { - if ((mp->m_ihsize >>= 1) <= NBPP) - flags = KM_SLEEP; - } - for (i = 0; i < mp->m_ihsize; i++) { + mp->m_ihash = kmem_zalloc_greedy(&mp->m_ihsize, + NBPC * sizeof(xfs_ihash_t), + mp->m_ihsize * sizeof(xfs_ihash_t), + KM_SLEEP | KM_MAYFAIL | KM_LARGE); + mp->m_ihsize /= sizeof(xfs_ihash_t); + for (i = 0; i < mp->m_ihsize; i++) rwlock_init(&(mp->m_ihash[i].ih_lock)); - } } /* @@ -77,7 +76,7 @@ xfs_ihash_init(xfs_mount_t *mp) void xfs_ihash_free(xfs_mount_t *mp) { - kmem_free(mp->m_ihash, mp->m_ihsize*sizeof(xfs_ihash_t)); + kmem_free(mp->m_ihash, mp->m_ihsize * sizeof(xfs_ihash_t)); mp->m_ihash = NULL; } Index: xfs-linux/xfs_itable.c =================================================================== --- xfs-linux.orig/xfs_itable.c 2006-08-09 13:51:05.081184500 +1000 +++ xfs-linux/xfs_itable.c 2006-08-09 13:59:05.537900000 +1000 @@ -326,7 +326,6 @@ xfs_bulkstat( int i; /* loop index */ int icount; /* count of inodes good in irbuf */ int irbsize; /* size of irec buffer in bytes */ - unsigned int kmflags; /* flags for allocating irec buffer */ xfs_ino_t ino; /* inode number (filesystem) */ xfs_inobt_rec_incore_t *irbp; /* current irec buffer pointer */ xfs_inobt_rec_incore_t *irbuf; /* start of irec buffer */ @@ -371,19 +370,8 @@ xfs_bulkstat( (XFS_INODE_CLUSTER_SIZE(mp) >> mp->m_sb.sb_inodelog); nimask = ~(nicluster - 1); nbcluster = nicluster >> mp->m_sb.sb_inopblog; - /* - * Allocate a local buffer for inode cluster btree records. - * This caps our maximum readahead window (so don't be stingy) - * but we must handle the case where we can't get a contiguous - * multi-page buffer, so we drop back toward pagesize; the end - * case we ensure succeeds, via appropriate allocation flags. - */ - irbsize = NBPP * 4; - kmflags = KM_SLEEP | KM_MAYFAIL; - while (!(irbuf = kmem_alloc(irbsize, kmflags))) { - if ((irbsize >>= 1) <= NBPP) - kmflags = KM_SLEEP; - } + irbuf = kmem_zalloc_greedy(&irbsize, NBPC, NBPC * 4, + KM_SLEEP | KM_MAYFAIL | KM_LARGE); nirbuf = irbsize / sizeof(*irbuf); /* From owner-xfs@oss.sgi.com Wed Aug 9 22:59:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Aug 2006 23:00:16 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7A5xYDW004894 for ; Wed, 9 Aug 2006 22:59:48 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA19214 for ; Thu, 10 Aug 2006 15:58:55 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7A5wrgw2592802 for ; Thu, 10 Aug 2006 15:58:53 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7A5wqYm2585092 for xfs@oss.sgi.com; Thu, 10 Aug 2006 15:58:52 +1000 (EST) Date: Thu, 10 Aug 2006 15:58:51 +1000 From: Nathan Scott To: xfs@oss.sgi.com Subject: review: fsblock zero - don't panic Message-ID: <20060810155851.C2591606@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8616 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 7117 Lines: 203 As part of attempting to understand what happened in a corruption problem awhile back, and generally be a bit more defensive of our precious primary superblock, some code was added to XFS to detect (and panic) on any inode extents that start at block zero. This has happened once or twice now, and when it does, we panic the kernel. This is not at all nice, as it means we take out the whole system due to ondisk corruption. This patch makes that code issue a warning now, and fail whatever operation was in progress. cheers. -- Nathan Index: xfs-linux/xfs_bmap.c =================================================================== --- xfs-linux.orig/xfs_bmap.c 2006-08-08 15:59:14.396022750 +1000 +++ xfs-linux/xfs_bmap.c 2006-08-08 16:08:34.790988750 +1000 @@ -3722,16 +3722,19 @@ xfs_bmap_search_extents( rt = (whichfork == XFS_DATA_FORK) && XFS_IS_REALTIME_INODE(ip); if (unlikely(!rt && !gotp->br_startblock && (*lastxp != NULLEXTNUM))) { - cmn_err(CE_PANIC,"Access to block zero: fs: <%s> inode: %lld " - "start_block : %llx start_off : %llx blkcnt : %llx " - "extent-state : %x \n", - (ip->i_mount)->m_fsname, (long long)ip->i_ino, + cmn_err(CE_WARN, "Access to block zero: fs: <%s> inode: %lld " + "start_block : %llx start_off : %llx " + "blkcnt : %llx extent-state : %x lastx : %x\n", + ip->i_mount->m_fsname, (long long)ip->i_ino, (unsigned long long)gotp->br_startblock, (unsigned long long)gotp->br_startoff, (unsigned long long)gotp->br_blockcount, - gotp->br_state); - } - return ep; + gotp->br_state, *lastxp); + ASSERT(0); + *eofp = 1; + return NULL; + } + return ep; } Index: xfs-linux/xfs_iomap.c =================================================================== --- xfs-linux.orig/xfs_iomap.c 2006-08-08 15:59:14.428024750 +1000 +++ xfs-linux/xfs_iomap.c 2006-08-08 16:18:40.116068500 +1000 @@ -536,23 +536,28 @@ xfs_iomap_write_direct( * Copy any maps to caller's array and return any error. */ if (nimaps == 0) { - error = (ENOSPC); + error = ENOSPC; goto error_out; } - *ret_imap = imap; - *nmaps = 1; - if ( !(io->io_flags & XFS_IOCORE_RT) && !ret_imap->br_startblock) { - cmn_err(CE_PANIC,"Access to block zero: fs <%s> inode: %lld " - "start_block : %llx start_off : %llx blkcnt : %llx " - "extent-state : %x \n", - (ip->i_mount)->m_fsname, - (long long)ip->i_ino, - (unsigned long long)ret_imap->br_startblock, + if (unlikely( + !(io->io_flags & XFS_IOCORE_RT) && !ret_imap->br_startblock)) { + cmn_err(CE_WARN, "Access to block zero: fs <%s> inode: %lld " + "start_block : %llx start_off : %llx " + "blkcnt : %llx extent-state : %x\n", + ip->i_mount->m_fsname, + (long long)ip->i_ino, + (unsigned long long)ret_imap->br_startblock, (unsigned long long)ret_imap->br_startoff, - (unsigned long long)ret_imap->br_blockcount, + (unsigned long long)ret_imap->br_blockcount, ret_imap->br_state); - } + ASSERT(0); + error = EFSCORRUPTED; + goto error_out; + } + + *ret_imap = imap; + *nmaps = 1; return 0; error0: /* Cancel bmap, unlock inode, unreserve quota blocks, cancel trans */ @@ -715,16 +720,19 @@ retry: goto retry; } - if (!(io->io_flags & XFS_IOCORE_RT) && !ret_imap->br_startblock) { - cmn_err(CE_PANIC,"Access to block zero: fs <%s> inode: %lld " - "start_block : %llx start_off : %llx blkcnt : %llx " - "extent-state : %x \n", - (ip->i_mount)->m_fsname, - (long long)ip->i_ino, - (unsigned long long)ret_imap->br_startblock, - (unsigned long long)ret_imap->br_startoff, - (unsigned long long)ret_imap->br_blockcount, - ret_imap->br_state); + if (unlikely( + !(io->io_flags & XFS_IOCORE_RT) && !ret_imap->br_startblock)) { + cmn_err(CE_WARN, "Access to block zero: fs <%s> inode: %lld " + "start_block : %llx start_off : %llx " + "blkcnt : %llx extent-state : %x\n", + ip->i_mount->m_fsname, + (long long)ip->i_ino, + (unsigned long long)ret_imap->br_startblock, + (unsigned long long)ret_imap->br_startoff, + (unsigned long long)ret_imap->br_blockcount, + ret_imap->br_state); + ASSERT(0); + return XFS_ERROR(EFSCORRUPTED); } *ret_imap = imap[0]; @@ -855,15 +863,15 @@ xfs_iomap_write_allocate( * See if we were able to allocate an extent that * covers at least part of the callers request */ - for (i = 0; i < nimaps; i++) { - if (!(io->io_flags & XFS_IOCORE_RT) && - !imap[i].br_startblock) { - cmn_err(CE_PANIC,"Access to block zero: " - "fs <%s> inode: %lld " - "start_block : %llx start_off : %llx " - "blkcnt : %llx extent-state : %x \n", - (ip->i_mount)->m_fsname, + if (unlikely(!(io->io_flags & XFS_IOCORE_RT) && + !imap[i].br_startblock)) { + cmn_err(CE_WARN, + "Access to block zero: fs <%s> " + "inode: %lld start_block : %llx " + "start_off : %llx blkcnt : %llx " + "extent-state : %x\n", + ip->i_mount->m_fsname, (long long)ip->i_ino, (unsigned long long) imap[i].br_startblock, @@ -872,7 +880,9 @@ xfs_iomap_write_allocate( (unsigned long long) imap[i].br_blockcount, imap[i].br_state); - } + ASSERT(0); + return XFS_ERROR(EFSCORRUPTED); + } if ((offset_fsb >= imap[i].br_startoff) && (offset_fsb < (imap[i].br_startoff + imap[i].br_blockcount))) { @@ -951,7 +961,7 @@ xfs_iomap_write_unwritten( } if (error) { xfs_trans_cancel(tp, 0); - goto error0; + return XFS_ERROR(error); } xfs_ilock(ip, XFS_ILOCK_EXCL); @@ -977,18 +987,22 @@ xfs_iomap_write_unwritten( error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); xfs_iunlock(ip, XFS_ILOCK_EXCL); if (error) - goto error0; + return XFS_ERROR(error); - if ( !(io->io_flags & XFS_IOCORE_RT) && !imap.br_startblock) { - cmn_err(CE_PANIC,"Access to block zero: fs <%s> " - "inode: %lld start_block : %llx start_off : " - "%llx blkcnt : %llx extent-state : %x \n", - (ip->i_mount)->m_fsname, + if (unlikely( + !(io->io_flags & XFS_IOCORE_RT) && !imap.br_startblock)) { + cmn_err(CE_WARN, "Access to block zero: fs <%s> " + "inode: %lld start_block : %llx " + "start_off : %llx blkcnt : %llx " + "extent-state : %x\n", + ip->i_mount->m_fsname, (long long)ip->i_ino, (unsigned long long)imap.br_startblock, (unsigned long long)imap.br_startoff, (unsigned long long)imap.br_blockcount, imap.br_state); + ASSERT(0); + return XFS_ERROR(EFSCORRUPTED); } if ((numblks_fsb = imap.br_blockcount) == 0) { @@ -1009,6 +1023,5 @@ error_on_bmapi_transaction: xfs_bmap_cancel(&free_list); xfs_trans_cancel(tp, (XFS_TRANS_RELEASE_LOG_RES | XFS_TRANS_ABORT)); xfs_iunlock(ip, XFS_ILOCK_EXCL); -error0: return XFS_ERROR(error); } From owner-xfs@oss.sgi.com Wed Aug 9 23:14:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Aug 2006 23:14:24 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7A6DlDW007136 for ; Wed, 9 Aug 2006 23:13:59 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA19616; Thu, 10 Aug 2006 16:13:03 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 75B3A58C6F7C; Thu, 10 Aug 2006 16:13:03 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 955302 - cleanup Message-Id: <20060810061303.75B3A58C6F7C@chook.melbourne.sgi.com> Date: Thu, 10 Aug 2006 16:13:03 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8617 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 4082 Lines: 91 Remove a couple of unused BUF macros Signed-off-by: Eric Sandeen Date: Thu Aug 10 16:04:22 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26746a xfs_buf_item.c - 1.159 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_buf_item.c.diff?r1=text&tr1=1.159&r2=text&tr2=1.158&f=h linux-2.6/xfs_buf.h - 1.115 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.115&r2=text&tr2=1.114&f=h linux-2.4/xfs_buf.h - 1.116 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.h.diff?r1=text&tr1=1.116&r2=text&tr2=1.115&f=h - Remove a couple of unused BUF macros Remove unused iop_abort log item operation Signed-off-by: Eric Sandeen Date: Thu Aug 10 16:09:47 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26747a xfs_extfree_item.c - 1.65 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.c.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h xfs_buf_item.c - 1.160 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_buf_item.c.diff?r1=text&tr1=1.160&r2=text&tr2=1.159&f=h xfs_inode_item.c - 1.129 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.c.diff?r1=text&tr1=1.129&r2=text&tr2=1.128&f=h xfs_trans.h - 1.141 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.h.diff?r1=text&tr1=1.141&r2=text&tr2=1.140&f=h quota/xfs_dquot_item.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot_item.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h - Remove unused iop_abort log item operation Remove several macros that are no longer used anywhere Signed-off-by: Eric Sandeen Date: Thu Aug 10 16:12:32 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26749a xfs_log.h - 1.79 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.h.diff?r1=text&tr1=1.79&r2=text&tr2=1.78&f=h xfs_log_priv.h - 1.116 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.116&r2=text&tr2=1.115&f=h xfs_sb.h - 1.67 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_sb.h.diff?r1=text&tr1=1.67&r2=text&tr2=1.66&f=h xfs_fs.h - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fs.h.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h xfs_error.h - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.h.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h xfs_quota.h - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_quota.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h quota/xfs_quota_priv.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_quota_priv.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h quota/xfs_qm.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h linux-2.6/xfs_linux.h - 1.149 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.149&r2=text&tr2=1.148&f=h linux-2.4/xfs_linux.h - 1.160 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.160&r2=text&tr2=1.159&f=h linux-2.6/xfs_buf.h - 1.116 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.116&r2=text&tr2=1.115&f=h linux-2.4/xfs_buf.h - 1.117 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.h.diff?r1=text&tr1=1.117&r2=text&tr2=1.116&f=h - Remove several macros that are no longer used anywhere From owner-xfs@oss.sgi.com Thu Aug 10 01:19:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Aug 2006 01:19:24 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7A8IxDW030899 for ; Thu, 10 Aug 2006 01:19:01 -0700 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 7EDAB1FDD0; Thu, 10 Aug 2006 08:58:49 +0200 (CEST) Date: Wed, 9 Aug 2006 23:58:36 -0700 From: Greg KH To: Nathan Scott Cc: Linus Torvalds , Andrew Morton , xfs@oss.sgi.com Subject: Re: XFS fix for 2.6.18-rc5 Message-ID: <20060810065836.GA27205@kroah.com> References: <20060810154817.A2591606@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060810154817.A2591606@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.5.12-2006-07-14 X-archive-position: 8618 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: xfs Content-Length: 373 Lines: 17 On Thu, Aug 10, 2006 at 03:48:18PM +1000, Nathan Scott wrote: > Hi Greg, > > Please pull from: > git://oss.sgi.com:8090/nathans/xfs-rc-2.6 > > This will update the following files: > > fs/xfs/xfs_alloc.c | 103 +++++++++++++++++++++++++++------------------------- > 1 files changed, 54 insertions(+), 49 deletions(-) Pulled from, and pushed out. thanks, greg k-h From owner-xfs@oss.sgi.com Thu Aug 10 09:20:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Aug 2006 09:20:46 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.231]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7AGKMDW005578 for ; Thu, 10 Aug 2006 09:20:23 -0700 Received: by qb-out-0506.google.com with SMTP id a16so171013qbd for ; Thu, 10 Aug 2006 09:19:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=YPT4+zr08nWLXYKkWBKXUTzYJa9wDW6uQGIswpvRf9aWae93sGew2KoGRzvIGm81tjQ240QJAcaGiWY/Eh725RKivRv6eHpO0kaiQGgFBMPijmw7f4i+Q1w7DmXi2kzNSZ83++/1X273R7sTKg6L8kwCzD2ESioNKBXYAT9x0Mc= Received: by 10.35.126.7 with SMTP id d7mr4037106pyn; Thu, 10 Aug 2006 08:05:35 -0700 (PDT) Received: by 10.35.116.15 with HTTP; Thu, 10 Aug 2006 08:05:35 -0700 (PDT) Message-ID: <6bffcb0e0608100805k42357f5bxa73189c38fb926df@mail.gmail.com> Date: Thu, 10 Aug 2006 17:05:35 +0200 From: "Michal Piotrowski" To: xfs-masters@oss.sgi.com Subject: 2.6.18-rc4+ext4 oops while mounting xfs Cc: nathans@sgi.com, xfs@oss.sgi.com, LKML MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 8620 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: michal.k.k.piotrowski@gmail.com Precedence: bulk X-list: xfs Content-Length: 8962 Lines: 182 Hi, This script is awesome :) #! /bin/bash m_fs() { # sudo mount -o loop -t ext2 /home/fs-farm/ext2.img /mnt/fs-farm/ext2/ # sudo mount -o loop -t ext3 /home/fs-farm/ext3.img /mnt/fs-farm/ext3/ # sudo mount -o loop -t ext3dev /home/fs-farm/ext4.img /mnt/fs-farm/ext4/ # sudo mount -o loop -t reiserfs /home/fs-farm/reiser3.img /mnt/fs-farm/reiser3/ sudo mount -o loop -t xfs /home/fs-farm/xfs.img /mnt/fs-farm/xfs/ # sudo mount -o loop -t jfs /home/fs-farm/jfs.img /mnt/fs-farm/jfs/ } u_fs() { # sudo umount /mnt/fs-farm/ext2/ # sudo umount /mnt/fs-farm/ext3/ # sudo umount /mnt/fs-farm/ext4/ # sudo umount /mnt/fs-farm/reiser3/ sudo umount /mnt/fs-farm/xfs/ # sudo umount /mnt/fs-farm/jfs/ } while true do m_fs u_fs done Aug 10 16:50:53 ltg01-fedora kernel: BUG: unable to handle kernel paging request at virtual address 6b6b6c07 Aug 10 16:50:53 ltg01-fedora kernel: printing eip: Aug 10 16:50:53 ltg01-fedora kernel: c013551a Aug 10 16:50:53 ltg01-fedora kernel: *pde = 00000000 Aug 10 16:50:53 ltg01-fedora kernel: Oops: 0002 [#1] Aug 10 16:50:53 ltg01-fedora kernel: PREEMPT SMP Aug 10 16:50:53 ltg01-fedora kernel: Modules linked in: xfs ext3dev jbd2 loop ipv6 w83627hf hwmon_vid hwmon i2c_isa af_packe t ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_use rspace p4_clockmod speedstep_lib binfmt_misc thermal processor fan container evdev snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm sk98lin snd_timer snd ide_cd soundcore skge snd_page_alloc cdrom i2c_i801 intel_agp agpgart rtc unix Aug 10 16:50:53 ltg01-fedora kernel: CPU: 0 Aug 10 16:50:53 ltg01-fedora kernel: EIP: 0060:[] Not tainted VLI Aug 10 16:50:53 ltg01-fedora kernel: EFLAGS: 00010002 (2.6.18-rc4 #119) Aug 10 16:50:53 ltg01-fedora kernel: EIP is at __lock_acquire+0x2ca/0x9b6 Aug 10 16:50:53 ltg01-fedora kernel: eax: d9c53d4c ebx: 6b6b6b6b ecx: 00000000 edx: 00000000 Aug 10 16:50:53 ltg01-fedora kernel: esi: 00000002 edi: df966d20 ebp: e44a8e7c esp: e44a8e4c Aug 10 16:50:53 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068 Aug 10 16:50:53 ltg01-fedora kernel: Process umount (pid: 16133, ti=e44a8000 task=df966d20 task.ti=e44a8000) Aug 10 16:50:53 ltg01-fedora kernel: Stack: 00000000 00000000 d9c53d4c df966d20 00000000 00000378 00000008 df9672f8 Aug 10 16:50:53 ltg01-fedora kernel: df966d20 df9672a8 00000002 df966d20 e44a8eb0 c0135ccb 00000000 00000002 Aug 10 16:50:53 ltg01-fedora kernel: 00000000 fe5778b7 c02d580c 00000003 df967280 00000004 df966d20 f4202a00 Aug 10 16:50:53 ltg01-fedora kernel: Call Trace: Aug 10 16:50:53 ltg01-fedora kernel: [] lock_release_non_nested+0xc5/0x11d Aug 10 16:50:53 ltg01-fedora kernel: [] lock_release+0x12f/0x159 Aug 10 16:50:53 ltg01-fedora kernel: [] __mutex_unlock_slowpath+0x99/0xff Aug 10 16:50:53 ltg01-fedora kernel: [] mutex_unlock+0x8/0xa Aug 10 16:50:53 ltg01-fedora kernel: [] generic_shutdown_super+0xbb/0x113 Aug 10 16:50:53 ltg01-fedora kernel: [] kill_block_super+0x20/0x32 Aug 10 16:50:53 ltg01-fedora kernel: [] deactivate_super+0x5d/0x6f Aug 10 16:50:53 ltg01-fedora kernel: [] mntput_no_expire+0x42/0x72 Aug 10 16:50:53 ltg01-fedora kernel: [] path_release_on_umount+0x15/0x18 Aug 10 16:50:53 ltg01-fedora kernel: [] sys_umount+0x1e7/0x21b Aug 10 16:50:53 ltg01-fedora kernel: [] sys_oldumount+0xd/0xf Aug 10 16:50:53 ltg01-fedora kernel: [] sysenter_past_esp+0x56/0x8d Aug 10 16:50:53 ltg01-fedora kernel: DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d Aug 10 16:50:53 ltg01-fedora kernel: Leftover inexact backtrace: Aug 10 16:50:53 ltg01-fedora kernel: [] show_stack_log_lvl+0x8c/0x97 Aug 10 16:50:53 ltg01-fedora kernel: [] show_registers+0x151/0x1c6 Aug 10 16:50:53 ltg01-fedora kernel: [] die+0x17c/0x281 Aug 10 16:50:53 ltg01-fedora kernel: [] do_page_fault+0x3b3/0x480 Aug 10 16:50:53 ltg01-fedora kernel: [] error_code+0x39/0x40 Aug 10 16:50:53 ltg01-fedora kernel: [] lock_release_non_nested+0xc5/0x11d Aug 10 16:50:53 ltg01-fedora kernel: [] lock_release+0x12f/0x159 Aug 10 16:50:53 ltg01-fedora kernel: [] __mutex_unlock_slowpath+0x99/0xff Aug 10 16:50:53 ltg01-fedora kernel: [] mutex_unlock+0x8/0xa Aug 10 16:50:53 ltg01-fedora kernel: [] generic_shutdown_super+0xbb/0x113 Aug 10 16:50:53 ltg01-fedora kernel: [] kill_block_super+0x20/0x32 Aug 10 16:50:53 ltg01-fedora kernel: [] deactivate_super+0x5d/0x6f Aug 10 16:50:53 ltg01-fedora kernel: [] mntput_no_expire+0x42/0x72 Aug 10 16:50:53 ltg01-fedora kernel: [] path_release_on_umount+0x15/0x18 Aug 10 16:50:53 ltg01-fedora kernel: [] sys_umount+0x1e7/0x21b Aug 10 16:50:53 ltg01-fedora kernel: [] sys_oldumount+0xd/0xf Aug 10 16:50:53 ltg01-fedora kernel: [] sysenter_past_esp+0x56/0x8d Aug 10 16:50:53 ltg01-fedora kernel: Code: 2a e8 73 94 0a 00 85 c0 74 21 68 ab a2 2d c0 68 d5 04 00 00 68 d9 37 2f c0 68 ee d0 2e c0 e8 b5 9d fe ff e8 45 f2 fc ff 83 c4 10 ff 83 9c 00 00 00 8b 55 dc 8b 92 5c 05 00 00 89 55 e4 83 fa Aug 10 16:50:53 ltg01-fedora kernel: EIP: [] __lock_acquire+0x2ca/0x9b6 SS:ESP 0068:e44a8e4c Aug 10 16:50:53 ltg01-fedora kernel: <3>BUG: sleeping function called from invalid context at /usr/src/linux-work2/mm/slab.c:2901 Aug 10 16:50:53 ltg01-fedora kernel: in_atomic():0, irqs_disabled():1 Aug 10 16:50:53 ltg01-fedora kernel: [] show_trace_log_lvl+0x58/0x152 Aug 10 16:50:53 ltg01-fedora kernel: [] show_trace+0xd/0x10 Aug 10 16:50:53 ltg01-fedora kernel: [] dump_stack+0x19/0x1b Aug 10 16:50:53 ltg01-fedora kernel: [] __might_sleep+0x8d/0x95 Aug 10 16:50:53 ltg01-fedora kernel: [] kmem_cache_zalloc+0x28/0xcc Aug 10 16:50:53 ltg01-fedora kernel: [] taskstats_exit_alloc+0x32/0x70 Aug 10 16:50:53 ltg01-fedora kernel: [] do_exit+0x111/0x7f1 Aug 10 16:50:53 ltg01-fedora kernel: [] die+0x25b/0x281 Aug 10 16:50:53 ltg01-fedora kernel: [] do_page_fault+0x3b3/0x480 Aug 10 16:50:53 ltg01-fedora kernel: [] error_code+0x39/0x40 Aug 10 16:50:53 ltg01-fedora kernel: DWARF2 unwinder stuck at error_code+0x39/0x40 Aug 10 16:50:53 ltg01-fedora kernel: Leftover inexact backtrace: Aug 10 16:50:53 ltg01-fedora kernel: [] show_trace+0xd/0x10 Aug 10 16:50:53 ltg01-fedora kernel: [] dump_stack+0x19/0x1b Aug 10 16:50:53 ltg01-fedora kernel: [] __might_sleep+0x8d/0x95 Aug 10 16:50:53 ltg01-fedora kernel: [] kmem_cache_zalloc+0x28/0xcc Aug 10 16:50:53 ltg01-fedora kernel: [] taskstats_exit_alloc+0x32/0x70 Aug 10 16:50:53 ltg01-fedora kernel: [] do_exit+0x111/0x7f1 Aug 10 16:50:53 ltg01-fedora kernel: [] die+0x25b/0x281 Aug 10 16:50:53 ltg01-fedora kernel: [] do_page_fault+0x3b3/0x480 Aug 10 16:50:53 ltg01-fedora kernel: [] error_code+0x39/0x40 Aug 10 16:50:53 ltg01-fedora kernel: [] lock_release_non_nested+0xc5/0x11d Aug 10 16:50:53 ltg01-fedora kernel: [] lock_release+0x12f/0x159 Aug 10 16:50:53 ltg01-fedora kernel: [] __mutex_unlock_slowpath+0x99/0xff Aug 10 16:50:53 ltg01-fedora kernel: [] mutex_unlock+0x8/0xa Aug 10 16:50:53 ltg01-fedora kernel: [] generic_shutdown_super+0xbb/0x113 Aug 10 16:50:53 ltg01-fedora kernel: [] kill_block_super+0x20/0x32 Aug 10 16:50:53 ltg01-fedora kernel: [] deactivate_super+0x5d/0x6f Aug 10 16:50:53 ltg01-fedora kernel: [] mntput_no_expire+0x42/0x72 Aug 10 16:50:53 ltg01-fedora kernel: [] path_release_on_umount+0x15/0x18 Aug 10 16:50:53 ltg01-fedora kernel: [] sys_umount+0x1e7/0x21b Aug 10 16:50:53 ltg01-fedora kernel: [] sys_oldumount+0xd/0xf Aug 10 16:50:53 ltg01-fedora kernel: [] sysenter_past_esp+0x56/0x8d Aug 10 16:50:53 ltg01-fedora kernel: Filesystem "loop2": Disabling barriers, not supported by the underlying device Aug 10 16:50:53 ltg01-fedora kernel: XFS mounting filesystem loop2 (gdb) list *0xc013551a 0xc013551a is in __lock_acquire (include2/asm/atomic.h:96). 91 * 92 * Atomically increments @v by 1. 93 */ 94 static __inline__ void atomic_inc(atomic_t *v) 95 { 96 __asm__ __volatile__( 97 LOCK_PREFIX "incl %0" 98 :"+m" (v->counter)); 99 } 100 Here is a config file http://www.stardust.webpages.pl/files/o_bugs/test-config Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/) From owner-xfs@oss.sgi.com Thu Aug 10 11:10:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Aug 2006 11:10:41 -0700 (PDT) Received: from mx.wurtel.net (a83-68-3-130.adsl.cistron.nl [83.68.3.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7AIAPDW020233 for ; Thu, 10 Aug 2006 11:10:26 -0700 Received: from wurtel ([192.168.1.1] helo=wurtel-ws.wurtel.net) by mx.wurtel.net with esmtp (Exim 3.36 #1 (Debian)) id 1GBDby-0007PP-00 for ; Thu, 10 Aug 2006 18:42:22 +0200 Received: from paul by wurtel-ws.wurtel.net with local (Exim 4.62) (envelope-from ) id 1GBDby-0004XF-8s for xfs@oss.sgi.com; Thu, 10 Aug 2006 18:42:22 +0200 Date: Thu, 10 Aug 2006 18:42:22 +0200 From: Paul Slootman To: xfs@oss.sgi.com Subject: cache_purge: shake on cache 0x5880a0 left 8 nodes!? Message-ID: <20060810164222.GA16332@wurtel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.12-2006-07-14 X-Scanner: exiscan *1GBDby-0007PP-00*afbVADNhl1Q*Wurtel X-archive-position: 8622 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul@wurtel.net Precedence: bulk X-list: xfs Content-Length: 1250 Lines: 37 Hi, I had problems due to the well-known endian bug. I first ran xfs_repair on it from the standard Debian package, version 2.6.20. That gave a lot of output (which can be found at http://www.xs4all.nl/~wurtel2/xfs_repair.out.4 ). While that was running, I got today's CVS version and built that (it reports version 2.8.11). I ran that version against the just-repaired filesystem, and got a number of additional errors, notably: empty data block 10 in directory inode 1343747104: junking block empty data block 11 in directory inode 1343747104: junking block empty data block 12 in directory inode 1343747104: junking block free block 16777216 entry 10 for directory ino 1343747104 bad rebuilding directory inode 1343747104 This 7 times; additionally, this was mentioned a couple of times: cache_purge: shake on cache 0x5880a0 left 8 nodes!? In fact, twice before the final "done.". The second repair output can be found at http://www.xs4all.nl/~wurtel2/xfs_repair.out.4b . Should I be worried about that? I tried a search for "shake on cache" and found zero hits... Additionally, the hash hit rates seem pretty bad. Anything to be worried about, and could anything be done about it? thanks, Paul Slootman (please CC me on responses) From owner-xfs@oss.sgi.com Thu Aug 10 16:18:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Aug 2006 16:18:39 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7ANHwDW025330 for ; Thu, 10 Aug 2006 16:18:13 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA15109; Fri, 11 Aug 2006 09:17:05 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7ANH2gw2613455; Fri, 11 Aug 2006 09:17:03 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7ANGxgr2611091; Fri, 11 Aug 2006 09:16:59 +1000 (EST) Date: Fri, 11 Aug 2006 09:16:59 +1000 From: Nathan Scott To: Michal Piotrowski Cc: xfs-masters@oss.sgi.com, xfs@oss.sgi.com, LKML Subject: Re: 2.6.18-rc4+ext4 oops while mounting xfs Message-ID: <20060811091659.E2596458@wobbly.melbourne.sgi.com> References: <6bffcb0e0608100805k42357f5bxa73189c38fb926df@mail.gmail.com> <6bffcb0e0608101608j4fc41945of65173793703a065@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6bffcb0e0608101608j4fc41945of65173793703a065@mail.gmail.com>; from michal.k.k.piotrowski@gmail.com on Fri, Aug 11, 2006 at 01:08:44AM +0200 X-archive-position: 8623 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1580 Lines: 34 On Fri, Aug 11, 2006 at 01:08:44AM +0200, Michal Piotrowski wrote: > On 10/08/06, Michal Piotrowski wrote: > > ... > > Aug 10 16:50:53 ltg01-fedora kernel: EFLAGS: 00010002 (2.6.18-rc4 #119) > > Aug 10 16:50:53 ltg01-fedora kernel: EIP is at __lock_acquire+0x2ca/0x9b6 > > Aug 10 16:50:53 ltg01-fedora kernel: Call Trace: > > Aug 10 16:50:53 ltg01-fedora kernel: [] > > lock_release_non_nested+0xc5/0x11d > > Aug 10 16:50:53 ltg01-fedora kernel: [] lock_release+0x12f/0x159 > > Aug 10 16:50:53 ltg01-fedora kernel: [] > > __mutex_unlock_slowpath+0x99/0xff > > Aug 10 16:50:53 ltg01-fedora kernel: [] mutex_unlock+0x8/0xa > > Aug 10 16:50:53 ltg01-fedora kernel: [] > > generic_shutdown_super+0xbb/0x113 > > Aug 10 16:50:53 ltg01-fedora kernel: [] kill_block_super+0x20/0x32 > > Aug 10 16:50:53 ltg01-fedora kernel: [] deactivate_super+0x5d/0x6f > > Aug 10 16:50:53 ltg01-fedora kernel: [] mntput_no_expire+0x42/0x72 > > Aug 10 16:50:53 ltg01-fedora kernel: [] > > path_release_on_umount+0x15/0x18 > > Aug 10 16:50:53 ltg01-fedora kernel: [] sys_umount+0x1e7/0x21b > ... > It's fixed in latest 2.6.18-rc4-git*. We've not changed anything mount related in current git* kernels, are you sure its fixed (did it happen every time)? I'm not sure how its XFS related too ... looks possibly lockdep related (from *non_nested back there?) and perhaps an issue with sb->s_lock in the kill_block_super unlock_super call? cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Aug 10 17:13:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Aug 2006 17:14:10 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7B0DbDW004793 for ; Thu, 10 Aug 2006 17:13:37 -0700 Received: by py-out-1112.google.com with SMTP id c39so1077608pyd for ; Thu, 10 Aug 2006 17:13:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nZz2o58y26qK0Qh2/qtVAA/QicOoMoo8RGQXoe0jndE5oLarbs7UCtA0zULV+t+putWeQs81mOKDd+oMRHVdn6NUWSRlNrQSp0/CfbpCdShfGEz44M2OT0KIbfLOnvI0E/tgQKE/R4vLqVppEfe45Z3/WaguvcggIgO+/Hxz4O4= Received: by 10.35.40.10 with SMTP id s10mr4776912pyj; Thu, 10 Aug 2006 16:46:08 -0700 (PDT) Received: by 10.35.116.15 with HTTP; Thu, 10 Aug 2006 16:46:08 -0700 (PDT) Message-ID: <6bffcb0e0608101646k4f412e7ave59bc20a038f51fe@mail.gmail.com> Date: Fri, 11 Aug 2006 01:46:08 +0200 From: "Michal Piotrowski" To: "Nathan Scott" Subject: Re: 2.6.18-rc4+ext4 oops while mounting xfs Cc: xfs-masters@oss.sgi.com, xfs@oss.sgi.com, LKML , "Arjan van de Ven" , "Ingo Molnar" In-Reply-To: <20060811091659.E2596458@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6bffcb0e0608100805k42357f5bxa73189c38fb926df@mail.gmail.com> <6bffcb0e0608101608j4fc41945of65173793703a065@mail.gmail.com> <20060811091659.E2596458@wobbly.melbourne.sgi.com> X-archive-position: 8625 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: michal.k.k.piotrowski@gmail.com Precedence: bulk X-list: xfs Content-Length: 1906 Lines: 50 Hi Nathan, On 11/08/06, Nathan Scott wrote: > On Fri, Aug 11, 2006 at 01:08:44AM +0200, Michal Piotrowski wrote: > > On 10/08/06, Michal Piotrowski wrote: > > > ... > > > Aug 10 16:50:53 ltg01-fedora kernel: EFLAGS: 00010002 (2.6.18-rc4 #119) > > > Aug 10 16:50:53 ltg01-fedora kernel: EIP is at __lock_acquire+0x2ca/0x9b6 > > > Aug 10 16:50:53 ltg01-fedora kernel: Call Trace: > > > Aug 10 16:50:53 ltg01-fedora kernel: [] > > > lock_release_non_nested+0xc5/0x11d > > > Aug 10 16:50:53 ltg01-fedora kernel: [] lock_release+0x12f/0x159 > > > Aug 10 16:50:53 ltg01-fedora kernel: [] > > > __mutex_unlock_slowpath+0x99/0xff > > > Aug 10 16:50:53 ltg01-fedora kernel: [] mutex_unlock+0x8/0xa > > > Aug 10 16:50:53 ltg01-fedora kernel: [] > > > generic_shutdown_super+0xbb/0x113 > > > Aug 10 16:50:53 ltg01-fedora kernel: [] kill_block_super+0x20/0x32 > > > Aug 10 16:50:53 ltg01-fedora kernel: [] deactivate_super+0x5d/0x6f > > > Aug 10 16:50:53 ltg01-fedora kernel: [] mntput_no_expire+0x42/0x72 > > > Aug 10 16:50:53 ltg01-fedora kernel: [] > > > path_release_on_umount+0x15/0x18 > > > Aug 10 16:50:53 ltg01-fedora kernel: [] sys_umount+0x1e7/0x21b > > ... > > It's fixed in latest 2.6.18-rc4-git*. > > We've not changed anything mount related in current git* kernels, > are you sure its fixed (did it happen every time)? I'm not sure > how its XFS related too ... looks possibly lockdep related (from > *non_nested back there?) You are absolutely right. Oops appears only with CONFIG_DEBUG_LOCKDEP enabled. > and perhaps an issue with sb->s_lock in > the kill_block_super unlock_super call? > > cheers. > > -- > Nathan > Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/) From owner-xfs@oss.sgi.com Thu Aug 10 18:26:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Aug 2006 18:27:17 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7B1QeDW014007 for ; Thu, 10 Aug 2006 18:26:54 -0700 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA18091; Fri, 11 Aug 2006 11:25:52 +1000 Message-Id: <200608110125.LAA18091@larry.melbourne.sgi.com> From: "Barry Naujok" To: "'Paul Slootman'" , Subject: RE: cache_purge: shake on cache 0x5880a0 left 8 nodes!? Date: Fri, 11 Aug 2006 11:30:08 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Aca8qGKEdh5OIlf2Tpur2ujEPs0fUgAPPlkg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <20060810164222.GA16332@wurtel.net> X-archive-position: 8626 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1860 Lines: 53 Hi Paul, What you are seeing is fine. The current libxfs cache with the directory update code is leaving some blocks referenced, and the libxfs code is printing out these blocks with outstanding references. The actual data was written to disk (prior to 2.8.10 it may not have). > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Paul Slootman > Sent: Friday, 11 August 2006 2:42 AM > To: xfs@oss.sgi.com > Subject: cache_purge: shake on cache 0x5880a0 left 8 nodes!? > > Hi, > > I had problems due to the well-known endian bug. > I first ran xfs_repair on it from the standard Debian package, > version 2.6.20. That gave a lot of output (which can be found at > http://www.xs4all.nl/~wurtel2/xfs_repair.out.4 ). > > While that was running, I got today's CVS version and built that > (it reports version 2.8.11). I ran that version against the > just-repaired filesystem, and got a number of additional errors, > notably: > > empty data block 10 in directory inode 1343747104: junking block > empty data block 11 in directory inode 1343747104: junking block > empty data block 12 in directory inode 1343747104: junking block > free block 16777216 entry 10 for directory ino 1343747104 bad > rebuilding directory inode 1343747104 > > This 7 times; additionally, this was mentioned a couple of times: > > cache_purge: shake on cache 0x5880a0 left 8 nodes!? > > In fact, twice before the final "done.". > > The second repair output can be found at > http://www.xs4all.nl/~wurtel2/xfs_repair.out.4b . > > Should I be worried about that? I tried a search for "shake on cache" > and found zero hits... > > Additionally, the hash hit rates seem pretty bad. Anything to be > worried about, and could anything be done about it? > > > thanks, > Paul Slootman (please CC me on responses) > > From owner-xfs@oss.sgi.com Thu Aug 10 19:32:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Aug 2006 19:32:20 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7B2VrDW023624 for ; Thu, 10 Aug 2006 19:32:03 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k7B2VFnx015947 for ; Thu, 10 Aug 2006 21:31:16 -0500 Received: from [134.15.0.69] (mtv-vpn-sw-corp-0-69.corp.sgi.com [134.15.0.69]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k7B2Um8s29050993 for ; Thu, 10 Aug 2006 19:30:48 -0700 (PDT) Message-ID: <44DBEBD7.7020405@sgi.com> Date: Thu, 10 Aug 2006 19:30:47 -0700 From: Madan Valluri User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Review: Repair multi-threading code Content-Type: multipart/mixed; boundary="------------020505020607020101000806" X-archive-position: 8627 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mvalluri@sgi.com Precedence: bulk X-list: xfs Content-Length: 50023 Lines: 1835 This is a multi-part message in MIME format. --------------020505020607020101000806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached is a patch which implements pthread based multi-threading in xfs_repair. For a small file system, on Irix, I observed the following run times: With no optimization: 10 minutes 21 seconds With multi-threading (only): 7 minutes 35 seconds With lio_listio pre-fetching (only): 3 minutes 59 seconds With both multi-threading and lio_listio pre-fetching: 3 minutes and 14 seconds. For a large fs: With no optimizations: ~36 hours With both multi-threading and pre-fetching: ~7 hours. Thanks. /Madan Valluri --------------020505020607020101000806 Content-Type: text/plain; name="mt.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mt.txt" =========================================================================== irix/Makefile =========================================================================== --- /usr/tmp/TmpDir.3157594-0/irix/Makefile_1.4 Wed Aug 9 12:12:44 2006 +++ irix/Makefile Sun May 14 23:26:31 2006 @@ -2,7 +2,8 @@ include $(ROOT)/usr/include/make/commondefs -SUBDIRS = include libxfs libxlog libxcmd libhandle io quota repair man +#SUBDIRS = include libxfs libxlog libxcmd libhandle io quota repair man +SUBDIRS = include libxfs libxlog repair default install $(COMMONTARGS) lint debug: $(_FORCE) $(SUBDIRS_MAKERULE) =========================================================================== irix/repair/Makefile =========================================================================== --- /usr/tmp/TmpDir.3157594-0/irix/repair/Makefile_1.3 Wed Aug 9 12:12:44 2006 +++ irix/repair/Makefile Wed Aug 9 11:30:40 2006 @@ -18,13 +18,13 @@ LHFILES = \ agheader.h attr_repair.h avl.h avl64.h bmap.h dinode.h dir.h \ dir2.h dir_stack.h globals.h incore.h protos.h scan.h rt.h \ - err_protos.h versions.h prefetch.h + err_protos.h versions.h prefetch.h threads.h LCFILES = \ agheader.c attr_repair.c avl.c avl64.c bmap.c dir.c dir2.c \ dino_chunks.c dinode.c dir_stack.c globals.c incore.c \ - incore_bmc.c incore_ext.c incore_ino.c init.c io.c \ + incore_bmc.c incore_ext.c incore_ino.c init.c \ phase1.c phase2.c phase3.c phase4.c phase5.c phase6.c phase7.c \ - prefetch.c rt.c sb.c scan.c versions.c xfs_repair.c + prefetch.c rt.c sb.c scan.c versions.c xfs_repair.c threads.c LOBJS = $(LCFILES:.c=.o) LDIRT = $(LHFILES) $(LCFILES) Makedepend $(TARGETS) =========================================================================== xfsprogs/include/libxfs.h =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/include/libxfs.h_1.55 Wed Aug 9 12:12:44 2006 +++ xfsprogs/include/libxfs.h Wed Aug 9 11:02:10 2006 @@ -577,6 +577,7 @@ #define LIBXFS_LIO_TYPE_RAW 0x3 #define LIBXFS_BBTOOFF64(bbs) (((xfs_off_t)(bbs)) << BBSHIFT) +extern int libxfs_nproc(void); #include #include =========================================================================== xfsprogs/libxfs/darwin.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/libxfs/darwin.c_1.10 Wed Aug 9 12:12:44 2006 +++ xfsprogs/libxfs/darwin.c Wed Aug 9 10:47:38 2006 @@ -118,3 +118,9 @@ { return (sizeof(void *)); } + +int +platform_nproc(void) +{ + return 1; +} =========================================================================== xfsprogs/libxfs/freebsd.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/libxfs/freebsd.c_1.13 Wed Aug 9 12:12:44 2006 +++ xfsprogs/libxfs/freebsd.c Wed Aug 9 10:49:45 2006 @@ -178,3 +178,9 @@ { return (sizeof(void *)); } + +int +platform_nproc(void) +{ + return 1; +} =========================================================================== xfsprogs/libxfs/init.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/libxfs/init.c_1.49 Wed Aug 9 12:12:44 2006 +++ xfsprogs/libxfs/init.c Wed Aug 9 10:54:35 2006 @@ -703,3 +703,9 @@ c = asctime(localtime(&t)); fprintf(fp, "%s", c); } + +int +libxfs_nproc(void) +{ + return platform_nproc(); +} =========================================================================== xfsprogs/libxfs/init.h =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/libxfs/init.h_1.10 Wed Aug 9 12:12:44 2006 +++ xfsprogs/libxfs/init.h Wed Aug 9 10:42:47 2006 @@ -33,5 +33,6 @@ extern int platform_direct_blockdev (void); extern int platform_align_blockdev (void); extern int platform_aio_init (int aio_count); +extern int platform_nproc(void); #endif /* LIBXFS_INIT_H */ =========================================================================== xfsprogs/libxfs/irix.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/libxfs/irix.c_1.11 Wed Aug 9 12:12:44 2006 +++ xfsprogs/libxfs/irix.c Wed Aug 9 10:59:27 2006 @@ -19,6 +19,7 @@ #include #include #include +#include extern char *progname; extern __int64_t findsize(char *); @@ -102,3 +103,10 @@ { return (sizeof(void *)); } + +int +platform_nproc(void) +{ + return sysmp(MP_NPROCS); +} + =========================================================================== xfsprogs/libxfs/linux.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/libxfs/linux.c_1.14 Wed Aug 9 12:12:44 2006 +++ xfsprogs/libxfs/linux.c Wed Aug 9 10:56:29 2006 @@ -207,3 +207,24 @@ return getpagesize(); return max_block_alignment; } + +int +platform_nproc(void) +{ + FILE *fp; + char buffer[256]; + int nproc; + + fp = fopen("/proc/stat", "r"); + if (fp) { + nproc = 0; + while (fgets(buffer, sizeof(buffer), fp)) { + if (strncmp(buffer, "cpu", 3) == 0) + nproc++; + } + fclose(fp); + if (nproc > 1) + return (nproc - 1); /* discard the initial aggregate cpu entry */ + } + return 1; +} =========================================================================== xfsprogs/repair/Makefile =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/Makefile_1.15 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/Makefile Wed Aug 9 11:04:02 2006 @@ -9,13 +9,13 @@ HFILES = agheader.h attr_repair.h avl.h avl64.h bmap.h dinode.h dir.h \ dir2.h dir_stack.h err_protos.h globals.h incore.h protos.h rt.h \ - scan.h versions.h prefetch.h + scan.h versions.h prefetch.h threads.h CFILES = agheader.c attr_repair.c avl.c avl64.c bmap.c dino_chunks.c \ dinode.c dir.c dir2.c dir_stack.c globals.c incore.c \ incore_bmc.c init.c incore_ext.c incore_ino.c phase1.c \ phase2.c phase3.c phase4.c phase5.c phase6.c phase7.c rt.c sb.c \ - prefetch.c scan.c versions.c xfs_repair.c + prefetch.c scan.c versions.c xfs_repair.c threads.c LLDLIBS = $(LIBXFS) $(LIBXLOG) $(LIBUUID) $(LIBPTHREAD) $(LIBRT) LTDEPENDENCIES = $(LIBXFS) $(LIBXLOG) =========================================================================== xfsprogs/repair/dino_chunks.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/dino_chunks.c_1.11 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/dino_chunks.c Wed Jul 12 16:24:50 2006 @@ -26,6 +26,7 @@ #include "dir.h" #include "dinode.h" #include "prefetch.h" +#include "threads.h" #include "versions.h" /* @@ -148,16 +149,19 @@ if (check_inode_block(mp, ino) == 0) return(0); + PREPAIR_RW_WRITE_LOCK(&per_ag_lock[agno]); switch (state = get_agbno_state(mp, agno, agbno)) { case XR_E_INO: do_warn( _("uncertain inode block %d/%d already known\n"), agno, agbno); + PREPAIR_RW_UNLOCK(&per_ag_lock[agno]); break; case XR_E_UNKNOWN: case XR_E_FREE1: case XR_E_FREE: set_agbno_state(mp, agno, agbno, XR_E_INO); + PREPAIR_RW_UNLOCK(&per_ag_lock[agno]); break; case XR_E_MULT: case XR_E_INUSE: @@ -170,6 +174,7 @@ _("inode block %d/%d multiply claimed, (state %d)\n"), agno, agbno, state); set_agbno_state(mp, agno, agbno, XR_E_MULT); + PREPAIR_RW_UNLOCK(&per_ag_lock[agno]); return(0); default: do_warn( @@ -176,6 +181,7 @@ _("inode block %d/%d bad state, (state %d)\n"), agno, agbno, state); set_agbno_state(mp, agno, agbno, XR_E_INO); + PREPAIR_RW_UNLOCK(&per_ag_lock[agno]); break; } @@ -425,6 +431,7 @@ * user data -- we're probably here as a result of a directory * entry or an iunlinked pointer */ + PREPAIR_RW_WRITE_LOCK(&per_ag_lock[agno]); for (j = 0, cur_agbno = chunk_start_agbno; cur_agbno < chunk_stop_agbno; cur_agbno++) { switch (state = get_agbno_state(mp, agno, cur_agbno)) { @@ -447,9 +454,12 @@ break; } - if (j) + if (j) { + PREPAIR_RW_UNLOCK(&per_ag_lock[agno]); return(0); + } } + PREPAIR_RW_UNLOCK(&per_ag_lock[agno]); /* * ok, chunk is good. put the record into the tree if required, @@ -472,6 +482,7 @@ set_inode_used(irec_p, agino - start_agino); + PREPAIR_RW_WRITE_LOCK(&per_ag_lock[agno]); for (cur_agbno = chunk_start_agbno; cur_agbno < chunk_stop_agbno; cur_agbno++) { switch (state = get_agbno_state(mp, agno, cur_agbno)) { @@ -501,6 +512,7 @@ break; } } + PREPAIR_RW_UNLOCK(&per_ag_lock[agno]); return(ino_cnt); } @@ -700,6 +712,7 @@ /* * mark block as an inode block in the incore bitmap */ + PREPAIR_RW_WRITE_LOCK(&per_ag_lock[agno]); switch (state = get_agbno_state(mp, agno, agbno)) { case XR_E_INO: /* already marked */ break; @@ -717,6 +730,7 @@ XFS_AGB_TO_FSB(mp, agno, agbno), state); break; } + PREPAIR_RW_UNLOCK(&per_ag_lock[agno]); while (!done) { /* @@ -869,6 +883,7 @@ ibuf_offset = 0; agbno++; + PREPAIR_RW_WRITE_LOCK(&per_ag_lock[agno]); switch (state = get_agbno_state(mp, agno, agbno)) { case XR_E_INO: /* already marked */ break; @@ -888,6 +903,7 @@ XFS_AGB_TO_FSB(mp, agno, agbno), state); break; } + PREPAIR_RW_UNLOCK(&per_ag_lock[agno]); } else if (irec_offset == XFS_INODES_PER_CHUNK) { /* =========================================================================== xfsprogs/repair/dinode.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/dinode.c_1.24 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/dinode.c Wed Jul 12 17:20:16 2006 @@ -30,6 +30,7 @@ #include "versions.h" #include "attr_repair.h" #include "bmap.h" +#include "threads.h" /* * inode clearing routines @@ -514,6 +515,29 @@ } /* + * process_bmbt_reclist_int is the most compute intensive + * function in repair. The following macros reduce the + * the large number of lock/unlock steps it would otherwise + * call. + */ +#define PROCESS_BMBT_DECL(type, var) type var + +#define PROCESS_BMBT_LOCK(agno) \ + if (do_parallel && (agno != locked_agno)) { \ + if (locked_agno != -1) /* release old ag lock */ \ + PREPAIR_RW_UNLOCK_NOTEST(&per_ag_lock[locked_agno]); \ + PREPAIR_RW_WRITE_LOCK_NOTEST(&per_ag_lock[agno]); \ + locked_agno = agno; \ + } + +#define PROCESS_BMBT_UNLOCK_RETURN(val) \ + do { \ + if (locked_agno != -1) \ + PREPAIR_RW_UNLOCK_NOTEST(&per_ag_lock[locked_agno]); \ + return (val); \ + } while (0) + +/* * return 1 if inode should be cleared, 0 otherwise * if check_dups should be set to 1, that implies that * the primary purpose of this call is to see if the @@ -552,6 +576,8 @@ xfs_dfsbno_t e; xfs_agnumber_t agno; xfs_agblock_t agbno; + PROCESS_BMBT_DECL + (xfs_agnumber_t, locked_agno=-1); if (whichfork == XFS_DATA_FORK) forkname = _("data"); @@ -574,7 +600,7 @@ _("bmap rec out of order, inode %llu entry %d " "[o s c] [%llu %llu %llu], %d [%llu %llu %llu]\n"), ino, i, o, s, c, i-1, op, sp, cp); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); } op = o; cp = c; @@ -587,7 +613,7 @@ do_warn( _("zero length extent (off = %llu, fsbno = %llu) in ino %llu\n"), o, s, ino); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); } if (type == XR_INO_RTDATA) { if (s >= mp->m_sb.sb_rblocks) { @@ -594,13 +620,13 @@ do_warn( _("inode %llu - bad rt extent start block number %llu, offset %llu\n"), ino, s, o); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); } if (s + c - 1 >= mp->m_sb.sb_rblocks) { do_warn( _("inode %llu - bad rt extent last block number %llu, offset %llu\n"), ino, s + c - 1, o); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); } if (s + c - 1 < s) { do_warn( @@ -607,7 +633,7 @@ _("inode %llu - bad rt extent overflows - start %llu, end %llu, " "offset %llu\n"), ino, s, s + c - 1, o); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); } } else { switch (verify_dfsbno_range(mp, s, c)) { @@ -617,12 +643,12 @@ do_warn( _("inode %llu - bad extent starting block number %llu, offset %llu\n"), ino, s, o); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); case XR_DFSBNORANGE_BADEND: do_warn( _("inode %llu - bad extent last block number %llu, offset %llu\n"), ino, s + c - 1, o); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); case XR_DFSBNORANGE_OVERFLOW: do_warn( @@ -629,7 +655,7 @@ _("inode %llu - bad extent overflows - start %llu, end %llu, " "offset %llu\n"), ino, s, s + c - 1, o); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); } if (o >= fs_max_file_offset) { do_warn( @@ -636,7 +662,7 @@ _("inode %llu - extent offset too large - start %llu, count %llu, " "offset %llu\n"), ino, s, c, o); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); } } @@ -654,7 +680,7 @@ do_warn( _("malformed rt inode extent [%llu %llu] (fs rtext size = %u)\n"), s, c, mp->m_sb.sb_rextsize); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); } /* @@ -676,7 +702,7 @@ _("data fork in rt ino %llu claims dup rt extent, off - %llu, " "start - %llu, count %llu\n"), ino, o, s, c); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); } continue; } @@ -714,7 +740,7 @@ do_warn( _("%s fork in rt inode %llu claims used rt block %llu\n"), forkname, ino, ext); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); case XR_E_FREE1: default: do_error( @@ -748,6 +774,7 @@ agno = XFS_FSB_TO_AGNO(mp, s); agbno = XFS_FSB_TO_AGBNO(mp, s); e = s + c; + PROCESS_BMBT_LOCK(agno); for (b = s; b < e; b++, agbno++) { if (check_dups == 1) { /* @@ -761,7 +788,7 @@ _("%s fork in ino %llu claims dup extent, off - %llu, " "start - %llu, cnt %llu\n"), forkname, ino, o, s, c); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); } continue; } @@ -772,7 +799,7 @@ */ if (type == XR_INO_RTDATA && whichfork == XFS_ATTR_FORK) { if (mp->m_sb.sb_agcount < agno) - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); } /* Process in chunks of 16 (XR_BB_UNIT/XR_BB) @@ -809,7 +836,7 @@ do_warn( _("%s fork in inode %llu claims metadata block %llu\n"), forkname, ino, (__uint64_t) b); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); case XR_E_INUSE: case XR_E_MULT: set_agbno_state(mp, agno, agbno, XR_E_MULT); @@ -816,7 +843,7 @@ do_warn( _("%s fork in %s inode %llu claims used block %llu\n"), forkname, ftype, ino, (__uint64_t) b); - return(1); + PROCESS_BMBT_UNLOCK_RETURN(1); default: do_error( _("illegal state %d in block map %llu\n"), @@ -827,7 +854,7 @@ *tot += c; } - return(0); + PROCESS_BMBT_UNLOCK_RETURN(0); } /* =========================================================================== xfsprogs/repair/dir_stack.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/dir_stack.c_1.9 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/dir_stack.c Wed Jul 12 23:44:40 2006 @@ -19,6 +19,7 @@ #include #include "dir_stack.h" #include "err_protos.h" +#include "threads.h" /* * a directory stack for holding directories while @@ -29,7 +30,10 @@ static dir_stack_t dirstack_freelist; static int dirstack_init = 0; +static pthread_mutex_t dirstack_mutex; +static pthread_mutexattr_t dirstack_mutexattr; + void dir_stack_init(dir_stack_t *stack) { @@ -38,6 +42,11 @@ if (dirstack_init == 0) { dirstack_init = 1; + PREPAIR_MTX_ATTR_INIT(&dirstack_mutexattr); +#ifdef PTHREAD_MUTEX_SPINBLOCK_NP + PREPAIR_MTX_ATTR_SET(&dirstack_mutexattr, PTHREAD_MUTEX_SPINBLOCK_NP); +#endif + PREPAIR_MTX_LOCK_INIT(&dirstack_mutex, &dirstack_mutexattr); dir_stack_init(&dirstack_freelist); } @@ -85,8 +94,10 @@ { dir_stack_elem_t *elem; + PREPAIR_MTX_LOCK(&dirstack_mutex); if (dirstack_freelist.cnt == 0) { if ((elem = malloc(sizeof(dir_stack_elem_t))) == NULL) { + PREPAIR_MTX_UNLOCK(&dirstack_mutex); do_error( _("couldn't malloc dir stack element, try more swap\n")); exit(1); @@ -94,6 +105,7 @@ } else { elem = dir_stack_pop(&dirstack_freelist); } + PREPAIR_MTX_UNLOCK(&dirstack_mutex); elem->ino = ino; @@ -116,7 +128,9 @@ ino = elem->ino; elem->ino = NULLFSINO; + PREPAIR_MTX_LOCK(&dirstack_mutex); dir_stack_push(&dirstack_freelist, elem); + PREPAIR_MTX_UNLOCK(&dirstack_mutex); return(ino); } =========================================================================== xfsprogs/repair/globals.h =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/globals.h_1.15 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/globals.h Wed Aug 9 11:05:12 2006 @@ -191,8 +191,10 @@ EXTERN __uint32_t sb_unit; EXTERN __uint32_t sb_width; -extern size_t ts_dirbuf_size; -extern size_t ts_dir_freemap_size; -extern size_t ts_attr_freemap_size; +extern size_t ts_dirbuf_size; +extern size_t ts_dir_freemap_size; +extern size_t ts_attr_freemap_size; + +EXTERN pthread_rwlock_t *per_ag_lock; #endif /* _XFS_REPAIR_GLOBAL_H */ =========================================================================== xfsprogs/repair/incore.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/incore.c_1.11 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/incore.c Wed Jul 12 16:27:08 2006 @@ -23,6 +23,7 @@ #include "agheader.h" #include "protos.h" #include "err_protos.h" +#include "threads.h" /* * push a block allocation record onto list. assumes list @@ -64,6 +65,7 @@ do_error(_("couldn't allocate block map pointers\n")); return; } + PREPAIR_RW_LOCK_ALLOC(per_ag_lock, agno); for (i = 0; i < agno; i++) { size = roundup((numblocks+(NBBY/XR_BB)-1) / (NBBY/XR_BB), sizeof(__uint64_t)); @@ -75,6 +77,7 @@ return; } bzero(ba_bmap[i], size); + PREPAIR_RW_LOCK_INIT(&per_ag_lock[i], NULL); } if (rtblocks == 0) { =========================================================================== xfsprogs/repair/incore_ext.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/incore_ext.c_1.10 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/incore_ext.c Wed Aug 9 10:11:47 2006 @@ -24,6 +24,7 @@ #include "protos.h" #include "err_protos.h" #include "avl64.h" +#include "threads.h" #define ALLOC_NUM_EXTS 100 /* @@ -92,6 +93,13 @@ static ba_rec_t *rt_ba_list; /* + * locks. + */ +static pthread_rwlock_t ext_flist_lock; +static pthread_rwlock_t rt_ext_tree_lock; +static pthread_rwlock_t rt_ext_flist_lock; + +/* * extent tree stuff is avl trees of duplicate extents, * sorted in order by block number. there is one tree per ag. */ @@ -104,6 +112,7 @@ extent_tree_node_t *new; extent_alloc_rec_t *rec; + PREPAIR_RW_WRITE_LOCK(&ext_flist_lock); if (ext_flist.cnt == 0) { ASSERT(ext_flist.list == NULL); @@ -130,6 +139,7 @@ ext_flist.list = (extent_tree_node_t *) new->avl_node.avl_nextino; ext_flist.cnt--; new->avl_node.avl_nextino = NULL; + PREPAIR_RW_UNLOCK(&ext_flist_lock); /* initialize node */ @@ -145,9 +155,11 @@ void release_extent_tree_node(extent_tree_node_t *node) { + PREPAIR_RW_WRITE_LOCK(&ext_flist_lock); node->avl_node.avl_nextino = (avlnode_t *) ext_flist.list; ext_flist.list = node; ext_flist.cnt++; + PREPAIR_RW_UNLOCK(&ext_flist_lock); return; } @@ -658,6 +670,7 @@ rt_extent_tree_node_t *new; rt_extent_alloc_rec_t *rec; + PREPAIR_RW_WRITE_LOCK(&rt_ext_flist_lock); if (rt_ext_flist.cnt == 0) { ASSERT(rt_ext_flist.list == NULL); @@ -684,6 +697,7 @@ rt_ext_flist.list = (rt_extent_tree_node_t *) new->avl_node.avl_nextino; rt_ext_flist.cnt--; new->avl_node.avl_nextino = NULL; + PREPAIR_RW_UNLOCK(&rt_ext_flist_lock); /* initialize node */ @@ -762,6 +776,7 @@ xfs_drtbno_t new_startblock; xfs_extlen_t new_blockcount; + PREPAIR_RW_WRITE_LOCK(&rt_ext_tree_lock); avl64_findranges(rt_ext_tree_ptr, startblock - 1, startblock + blockcount + 1, (avl64node_t **) &first, (avl64node_t **) &last); @@ -779,6 +794,7 @@ do_error(_("duplicate extent range\n")); } + PREPAIR_RW_UNLOCK(&rt_ext_tree_lock); return; } @@ -802,8 +818,10 @@ * just bail if the new extent is contained within an old one */ if (ext->rt_startblock <= startblock && - ext->rt_blockcount >= blockcount) + ext->rt_blockcount >= blockcount) { + PREPAIR_RW_UNLOCK(&rt_ext_tree_lock); return; + } /* * now check for overlaps and adjacent extents */ @@ -831,6 +849,7 @@ do_error(_("duplicate extent range\n")); } + PREPAIR_RW_UNLOCK(&rt_ext_tree_lock); return; } @@ -841,10 +860,15 @@ int search_rt_dup_extent(xfs_mount_t *mp, xfs_drtbno_t bno) { - if (avl64_findrange(rt_ext_tree_ptr, bno) != NULL) - return(1); + int ret; - return(0); + PREPAIR_RW_READ_LOCK(&rt_ext_tree_lock); + if (avl64_findrange(rt_ext_tree_ptr, bno) != NULL) + ret = 1; + else + ret = 0; + PREPAIR_RW_UNLOCK(&rt_ext_tree_lock); + return(ret); } static __uint64_t @@ -873,6 +897,9 @@ ba_list = NULL; rt_ba_list = NULL; + PREPAIR_RW_LOCK_INIT(&ext_flist_lock, NULL); + PREPAIR_RW_LOCK_INIT(&rt_ext_tree_lock, NULL); + PREPAIR_RW_LOCK_INIT(&rt_ext_flist_lock, NULL); if ((extent_tree_ptrs = malloc(agcount * sizeof(avltree_desc_t *))) == NULL) =========================================================================== xfsprogs/repair/incore_ino.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/incore_ino.c_1.13 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/incore_ino.c Wed Jul 12 16:47:03 2006 @@ -22,8 +22,10 @@ #include "incore.h" #include "agheader.h" #include "protos.h" +#include "threads.h" #include "err_protos.h" +static pthread_rwlock_t ino_flist_lock; extern avlnode_t *avl_firstino(avlnode_t *root); /* @@ -69,6 +71,7 @@ ino_tree_node_t *new; avlnode_t *node; + PREPAIR_RW_WRITE_LOCK(&ino_flist_lock); if (ino_flist.cnt == 0) { ASSERT(ino_flist.list == NULL); @@ -92,6 +95,7 @@ ino_flist.cnt--; node = &new->avl_node; node->avl_nextino = node->avl_forw = node->avl_back = NULL; + PREPAIR_RW_UNLOCK(&ino_flist_lock); /* initialize node */ @@ -115,6 +119,7 @@ ino_rec->avl_node.avl_forw = NULL; ino_rec->avl_node.avl_back = NULL; + PREPAIR_RW_WRITE_LOCK(&ino_flist_lock); if (ino_flist.list != NULL) { ASSERT(ino_flist.cnt > 0); ino_rec->avl_node.avl_nextino = (avlnode_t *) ino_flist.list; @@ -132,6 +137,7 @@ if (ino_rec->ino_un.plist != NULL) free(ino_rec->ino_un.plist); } + PREPAIR_RW_UNLOCK(&ino_flist_lock); return; } @@ -643,6 +649,7 @@ int i; int agcount = mp->m_sb.sb_agcount; + PREPAIR_RW_LOCK_INIT(&ino_flist_lock, NULL); if ((inode_tree_ptrs = malloc(agcount * sizeof(avltree_desc_t *))) == NULL) do_error(_("couldn't malloc inode tree descriptor table\n")); =========================================================================== xfsprogs/repair/init.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/init.c_1.18 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/init.c Wed Aug 9 11:06:22 2006 @@ -43,12 +43,17 @@ } static void -ts_init(void) +ts_create(void) { /* create thread specific keys */ pthread_key_create(&dirbuf_key, NULL); pthread_key_create(&dir_freemap_key, NULL); pthread_key_create(&attr_freemap_key, NULL); +} + +void +ts_init(void) +{ /* allocate thread specific storage */ ts_alloc(dirbuf_key, 1, ts_dirbuf_size); @@ -136,6 +141,7 @@ if (!libxfs_init(args)) do_error(_("couldn't initialize XFS library\n")); + ts_create(); ts_init(); increase_rlimit(); if (do_prefetch) { @@ -143,4 +149,5 @@ if (do_prefetch) libxfs_lio_allocate(); } + thread_init(); } =========================================================================== xfsprogs/repair/phase3.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/phase3.c_1.11 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/phase3.c Wed Aug 9 11:54:16 2006 @@ -24,6 +24,7 @@ #include "protos.h" #include "err_protos.h" #include "dinode.h" +#include "threads.h" /* * walks an unlinked list, returns 1 on an error (bogus pointer) or @@ -57,6 +58,7 @@ add_aginode_uncertain(agno, current_ino, 1); agbno = XFS_AGINO_TO_AGBNO(mp, current_ino); + PREPAIR_RW_WRITE_LOCK(&per_ag_lock[agno]); switch (state = get_agbno_state(mp, agno, agbno)) { case XR_E_UNKNOWN: @@ -64,8 +66,10 @@ case XR_E_FREE1: set_agbno_state(mp, agno, agbno, XR_E_INO); + PREPAIR_RW_UNLOCK(&per_ag_lock[agno]); break; case XR_E_BAD_STATE: + PREPAIR_RW_UNLOCK(&per_ag_lock[agno]); do_error(_( "bad state in block map %d\n"), state); @@ -84,6 +88,7 @@ */ set_agbno_state(mp, agno, agbno, XR_E_INO); + PREPAIR_RW_UNLOCK(&per_ag_lock[agno]); break; } } @@ -144,6 +149,17 @@ } void +parallel_p3_process_aginodes(xfs_mount_t *mp, xfs_agnumber_t agno) +{ + /* + * turn on directory processing (inode discovery) and + * attribute processing (extra_attr_check) + */ + do_log(_(" - agno = %d\n"), agno); + process_aginodes(mp, agno, 1, 0, 1); +} + +void phase3(xfs_mount_t *mp) { int i, j; @@ -171,13 +187,9 @@ " - process known inodes and perform inode discovery...\n")); for (i = 0; i < mp->m_sb.sb_agcount; i++) { - do_log(_(" - agno = %d\n"), i); - /* - * turn on directory processing (inode discovery) and - * attribute processing (extra_attr_check) - */ - process_aginodes(mp, i, 1, 0, 1); + queue_work(parallel_p3_process_aginodes, mp, i); } + wait_for_workers(); /* * process newly discovered inode chunks =========================================================================== xfsprogs/repair/phase4.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/phase4.c_1.17 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/phase4.c Wed Aug 9 11:55:37 2006 @@ -28,6 +28,7 @@ #include "bmap.h" #include "versions.h" #include "dir2.h" +#include "threads.h" /* ARGSUSED */ @@ -1119,6 +1120,18 @@ void +parallel_p4_process_aginodes(xfs_mount_t *mp, xfs_agnumber_t agno) +{ + do_log(_(" - agno = %d\n"), agno); + process_aginodes(mp, agno, 0, 1, 0); + + /* + * now recycle the per-AG duplicate extent records + */ + release_dup_extent_tree(agno); +} + +void phase4(xfs_mount_t *mp) { ino_tree_node_t *irec; @@ -1325,14 +1338,9 @@ * and attribute processing is turned OFF since we did that * already in phase 3. */ - do_log(_(" - agno = %d\n"), i); - process_aginodes(mp, i, 0, 1, 0); - - /* - * now recycle the per-AG duplicate extent records - */ - release_dup_extent_tree(i); + queue_work(parallel_p4_process_aginodes, mp, i); } + wait_for_workers(); /* * free up memory used to track trealtime duplicate extents =========================================================================== xfsprogs/repair/phase5.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/phase5.c_1.11 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/phase5.c Wed Aug 9 11:56:01 2006 @@ -26,6 +26,7 @@ #include "dinode.h" #include "rt.h" #include "versions.h" +#include "threads.h" /* * we maintain the current slice (path from root to leaf) @@ -72,6 +73,9 @@ bt_stat_level_t level[XFS_BTREE_MAXLEVELS]; } bt_status_t; +static __uint64_t *sb_icount_ag; /* allocated inodes per ag */ +static __uint64_t *sb_ifree_ag; /* free inodes per ag */ +static __uint64_t *sb_fdblocks_ag; /* free data blocks per ag */ int mk_incore_fstree(xfs_mount_t *mp, xfs_agnumber_t agno) @@ -1415,7 +1419,7 @@ } void -phase5(xfs_mount_t *mp) +phase5_function(xfs_mount_t *mp, xfs_agnumber_t agno) { __uint64_t num_inos; __uint64_t num_free_inos; @@ -1422,7 +1426,6 @@ bt_status_t bno_btree_curs; bt_status_t bcnt_btree_curs; bt_status_t ino_btree_curs; - xfs_agnumber_t agno; int extra_blocks = 0; uint num_freeblocks; xfs_extlen_t freeblks1; @@ -1436,35 +1439,10 @@ extern int count_bcnt_extents(xfs_agnumber_t); #endif - do_log(_("Phase 5 - rebuild AG headers and trees...\n")); - -#ifdef XR_BLD_FREE_TRACE - fprintf(stderr, "inobt level 1, maxrec = %d, minrec = %d\n", - XFS_BTREE_BLOCK_MAXRECS(mp->m_sb.sb_blocksize, xfs_inobt, 0), - XFS_BTREE_BLOCK_MINRECS(mp->m_sb.sb_blocksize, xfs_inobt, 0) - ); - fprintf(stderr, "inobt level 0 (leaf), maxrec = %d, minrec = %d\n", - XFS_BTREE_BLOCK_MAXRECS(mp->m_sb.sb_blocksize, xfs_inobt, 1), - XFS_BTREE_BLOCK_MINRECS(mp->m_sb.sb_blocksize, xfs_inobt, 1) - ); - fprintf(stderr, "xr inobt level 0 (leaf), maxrec = %d\n", - XR_INOBT_BLOCK_MAXRECS(mp, 0)); - fprintf(stderr, "xr inobt level 1 (int), maxrec = %d\n", - XR_INOBT_BLOCK_MAXRECS(mp, 1)); - fprintf(stderr, "bnobt level 1, maxrec = %d, minrec = %d\n", - XFS_BTREE_BLOCK_MAXRECS(mp->m_sb.sb_blocksize, xfs_alloc, 0), - XFS_BTREE_BLOCK_MINRECS(mp->m_sb.sb_blocksize, xfs_alloc, 0)); - fprintf(stderr, "bnobt level 0 (leaf), maxrec = %d, minrec = %d\n", - XFS_BTREE_BLOCK_MAXRECS(mp->m_sb.sb_blocksize, xfs_alloc, 1), - XFS_BTREE_BLOCK_MINRECS(mp->m_sb.sb_blocksize, xfs_alloc, 1)); -#endif - - /* - * make sure the root and realtime inodes show up allocated - */ - keep_fsinos(mp); + if (verbose) + do_log(_(" - agno = %d\n"), agno); - for (agno = 0; agno < mp->m_sb.sb_agcount; agno++) { + { /* * build up incore bno and bcnt extent btrees */ @@ -1503,8 +1481,8 @@ init_ino_cursor(mp, agno, &ino_btree_curs, &num_inos, &num_free_inos); - sb_icount += num_inos; - sb_ifree += num_free_inos; + sb_icount_ag[agno] += num_inos; + sb_ifree_ag[agno] += num_free_inos; num_extents = count_bno_extents_blocks(agno, &num_freeblocks); /* @@ -1512,7 +1490,7 @@ * are counted as allocated since the space trees * always have roots */ - sb_fdblocks += num_freeblocks - 2; + sb_fdblocks_ag[agno] += num_freeblocks - 2; if (num_extents == 0) { /* @@ -1554,7 +1532,7 @@ if (extra_blocks > 0) { do_warn(_("lost %d blocks in agno %d, sorry.\n"), extra_blocks, agno); - sb_fdblocks -= extra_blocks; + sb_fdblocks_ag[agno] -= extra_blocks; } bcnt_btree_curs = bno_btree_curs; @@ -1613,6 +1591,67 @@ release_agbno_extent_tree(agno); release_agbcnt_extent_tree(agno); } +} + +void +phase5(xfs_mount_t *mp) +{ + xfs_agnumber_t agno; + + do_log(_("Phase 5 - rebuild AG headers and trees...\n")); + +#ifdef XR_BLD_FREE_TRACE + fprintf(stderr, "inobt level 1, maxrec = %d, minrec = %d\n", + XFS_BTREE_BLOCK_MAXRECS(mp->m_sb.sb_blocksize, xfs_inobt, 0), + XFS_BTREE_BLOCK_MINRECS(mp->m_sb.sb_blocksize, xfs_inobt, 0) + ); + fprintf(stderr, "inobt level 0 (leaf), maxrec = %d, minrec = %d\n", + XFS_BTREE_BLOCK_MAXRECS(mp->m_sb.sb_blocksize, xfs_inobt, 1), + XFS_BTREE_BLOCK_MINRECS(mp->m_sb.sb_blocksize, xfs_inobt, 1) + ); + fprintf(stderr, "xr inobt level 0 (leaf), maxrec = %d\n", + XR_INOBT_BLOCK_MAXRECS(mp, 0)); + fprintf(stderr, "xr inobt level 1 (int), maxrec = %d\n", + XR_INOBT_BLOCK_MAXRECS(mp, 1)); + fprintf(stderr, "bnobt level 1, maxrec = %d, minrec = %d\n", + XFS_BTREE_BLOCK_MAXRECS(mp->m_sb.sb_blocksize, xfs_alloc, 0), + XFS_BTREE_BLOCK_MINRECS(mp->m_sb.sb_blocksize, xfs_alloc, 0)); + fprintf(stderr, "bnobt level 0 (leaf), maxrec = %d, minrec = %d\n", + XFS_BTREE_BLOCK_MAXRECS(mp->m_sb.sb_blocksize, xfs_alloc, 1), + XFS_BTREE_BLOCK_MINRECS(mp->m_sb.sb_blocksize, xfs_alloc, 1)); +#endif + /* + * make sure the root and realtime inodes show up allocated + */ + keep_fsinos(mp); + + /* allocate per ag counters */ + sb_icount_ag = calloc(mp->m_sb.sb_agcount, sizeof(__uint64_t)); + if (sb_icount_ag == NULL) + do_error(_("cannot alloc sb_icount_ag buffers\n")); + + sb_ifree_ag = calloc(mp->m_sb.sb_agcount, sizeof(__uint64_t)); + if (sb_ifree_ag == NULL) + do_error(_("cannot alloc sb_ifree_ag buffers\n")); + + sb_fdblocks_ag = calloc(mp->m_sb.sb_agcount, sizeof(__uint64_t)); + if (sb_fdblocks_ag == NULL) + do_error(_("cannot alloc sb_fdblocks_ag buffers\n")); + + for (agno = 0; agno < mp->m_sb.sb_agcount; agno++) { + queue_work(phase5_function, mp, agno); + } + wait_for_workers(); + + /* aggregate per ag counters */ + for (agno = 0; agno < mp->m_sb.sb_agcount; agno++) { + sb_icount += sb_icount_ag[agno]; + sb_ifree += sb_ifree_ag[agno]; + sb_fdblocks += sb_fdblocks_ag[agno]; + } + free(sb_icount_ag); + free(sb_ifree_ag); + free(sb_fdblocks_ag); if (mp->m_sb.sb_rblocks) { do_log( @@ -1630,4 +1669,5 @@ sync_sb(mp); bad_ino_btree = 0; + } =========================================================================== xfsprogs/repair/phase7.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/phase7.c_1.11 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/phase7.c Wed Aug 9 11:56:22 2006 @@ -26,6 +26,7 @@ #include "dinode.h" #include "versions.h" #include "prefetch.h" +#include "threads.h" /* dinoc is a pointer to the IN-CORE dinode core */ void @@ -180,8 +181,9 @@ libxfs_bcache_purge(); for (i = 0; i < glob_agcount; i++) { - phase7_alt_function(mp, i); + queue_work(phase7_alt_function, mp, i); } + wait_for_workers(); } void =========================================================================== xfsprogs/repair/protos.h =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/protos.h_1.9 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/protos.h Wed Aug 9 11:07:32 2006 @@ -44,4 +44,6 @@ extern void *ts_attr_freemap(void); extern void *ts_dir_freemap(void); extern void *ts_dirbuf(void); +extern void ts_init(void); +extern void thread_init(void); =========================================================================== xfsprogs/repair/xfs_repair.c =========================================================================== --- /usr/tmp/TmpDir.3157594-0/xfsprogs/repair/xfs_repair.c_1.25 Wed Aug 9 12:12:44 2006 +++ xfsprogs/repair/xfs_repair.c Wed Aug 9 11:11:51 2006 @@ -26,6 +26,7 @@ #include "incore.h" #include "err_protos.h" #include "prefetch.h" +#include "threads.h" #define rounddown(x, y) (((x)/(y))*(y)) @@ -63,9 +64,13 @@ "pfdir", #define PREFETCH_AIO_CNT 6 "pfaio", +#define THREAD_CNT 7 + "thread", NULL }; +static void print_runtime(unsigned); + static void usage(void) { @@ -187,7 +192,7 @@ * XXX have to add suboption processing here * attributes, quotas, nlinks, aligned_inos, sb_fbits */ - while ((c = getopt(argc, argv, "o:fl:r:LnDvVdP")) != EOF) { + while ((c = getopt(argc, argv, "o:fl:r:LnDvVdPM")) != EOF) { switch (c) { case 'D': dumpcore = 1; @@ -228,6 +233,9 @@ case PREFETCH_AIO_CNT: libxfs_lio_aio_count = (int) strtol(val, 0, 0); break; + case THREAD_CNT: + thread_count = (int) strtol(val, 0, 0); + break; default: unknown('o', val); break; @@ -255,7 +263,7 @@ dangerously = 1; break; case 'v': - verbose = 1; + verbose++; break; case 'V': printf(_("%s version %s\n"), progname, VERSION); @@ -263,6 +271,9 @@ case 'P': do_prefetch ^= 1; break; + case 'M': + do_parallel ^= 1; + break; case '?': usage(); } @@ -458,7 +469,9 @@ xfs_sb_t *sb; xfs_buf_t *sbp; xfs_mount_t xfs_m; + time_t t, start; + start = time(NULL); progname = basename(argv[0]); setlocale(LC_ALL, ""); bindtextdomain(PACKAGE, LOCALEDIR); @@ -472,6 +485,10 @@ /* do phase1 to make sure we have a superblock */ phase1(temp_mp); + if (verbose) { + t = time(NULL); + fprintf(stderr, asctime(localtime(&t))); + } if (no_modify && primary_sb_modified) { do_warn(_("Primary superblock would have been modified.\n" @@ -522,18 +539,23 @@ } /* make sure the per-ag freespace maps are ok so we can mount the fs */ - phase2(mp); + if (verbose) { + t = time(NULL); + fprintf(stderr, asctime(localtime(&t))); + } - if (verbose) - libxfs_report(stderr); phase3(mp); - if (verbose) - libxfs_report(stderr); + if (verbose) { + t = time(NULL); + fprintf(stderr, asctime(localtime(&t))); + } phase4(mp); - if (verbose) - libxfs_report(stderr); + if (verbose) { + t = time(NULL); + fprintf(stderr, asctime(localtime(&t))); + } /* XXX: nathans - something in phase4 ain't playing by */ /* the buffer cache rules.. why doesn't IRIX hit this? */ @@ -541,15 +563,26 @@ if (no_modify) printf(_("No modify flag set, skipping phase 5\n")); - else + else { phase5(mp); + if (verbose) { + t = time(NULL); + fprintf(stderr, asctime(localtime(&t))); + } + } if (!bad_ino_btree) { phase6(mp); - if (verbose) - libxfs_report(stderr); + if (verbose) { + t = time(NULL); + fprintf(stderr, asctime(localtime(&t))); + } phase7(mp); + if (verbose) { + t = time(NULL); + fprintf(stderr, asctime(localtime(&t))); + } } else { do_warn( _("Inode allocation btrees are too corrupted, skipping phases 6 and 7\n")); @@ -609,12 +642,14 @@ } } - if (verbose) + if (verbose > 1) libxfs_report(stderr); if (no_modify) { do_log( _("No modify flag set, skipping filesystem flush and exiting.\n")); + if (verbose) + print_runtime(t - start); if (fs_is_dirty) return(1); @@ -661,6 +696,33 @@ libxfs_device_close(x.ddev); do_log(_("done\n")); + if (verbose) { + print_runtime(t - start); + } + return (0); +} + +static void +print_runtime(unsigned s) +{ + unsigned h, m; - return(0); + h = s / 3600; + s %= 3600; + m = s / 60; + s %= 60; + if (h) { + fprintf(stderr, "Run time %d hour%s %d minute%s %d second%s\n", + h, h > 1 ? "s" : "", + m, m != 1 ? "s" : "", + s, s != 1 ? "s" : ""); + } else if (m) { + fprintf(stderr, "Run time %d minute%s %d second%s\n", + m, m > 1 ? "s" : "", + s, s != 1 ? "s" : ""); + } + else { + fprintf(stderr, "Run time %d second%s\n", + s, s != 1 ? "s" : ""); + } } =========================================================================== xfsprogs/repair/threads.c =========================================================================== --- /dev/null Wed Aug 9 12:12:41 2006 +++ xfsprogs/repair/threads.c Wed Aug 9 11:52:18 2006 @@ -0,0 +1,308 @@ +#include +#include "pthread.h" +#include "signal.h" +#include "threads.h" +#include "err_protos.h" +#include "protos.h" + +int do_parallel = 1; +int thread_count; + +/* A quantum of work */ +typedef struct work_s { + struct work_s *next; + disp_func_t *function; + xfs_mount_t *mp; + xfs_agnumber_t agno; +} work_t; + +typedef struct work_queue_s { + work_t *next; + work_t *last; + int active_threads; + int work_count; + pthread_cond_t mcv; /* main thread conditional variable */ + pthread_cond_t wcv; /* worker threads conditional variable */ + pthread_mutex_t mutex; +} work_queue_t; + +static work_queue_t work_queue; +static pthread_t *work_threads; + +static void *worker_thread(void *arg); + +static void +init_workers(work_queue_t *wq, int nw) +{ + int err; + pthread_mutexattr_t mtxattr; + + memset(wq, 0, sizeof(work_queue_t)); + wq->active_threads = nw; + + pthread_cond_init(&wq->mcv, NULL); + pthread_cond_init(&wq->wcv, NULL); + pthread_mutexattr_init(&mtxattr); + +#ifdef PTHREAD_MUTEX_SPINBLOCK_NP + /* NP - Non Portable - Irix */ + if ((err = pthread_mutexattr_settype(&mtxattr, + PTHREAD_MUTEX_SPINBLOCK_NP)) > 0) { + do_error(_("init_workers: thread 0x%x: pthread_mutexattr_settype error %d: %s\n"), + pthread_self(), err, strerror(err)); + } +#endif +#ifdef PTHREAD_MUTEX_FAST_NP + /* NP - Non Portable - Linux */ + if ((err = pthread_mutexattr_settype(&mtxattr, + PTHREAD_MUTEX_FAST_NP)) > 0) { + do_error(_("init_workers: thread 0x%x: pthread_mutexattr_settype error %d: %s\n"), + pthread_self(), err, strerror(err)); + } +#endif + if ((err = pthread_mutex_init(&wq->mutex, &mtxattr)) > 0) { + do_error(_("init_workers: thread 0x%x: pthread_mutex_init error %d: %s\n"), + pthread_self(), err, strerror(err)); + } +} + +static void +quiesce_workers(work_queue_t *wq) +{ + int err; + + if ((err = pthread_mutex_lock(&wq->mutex)) > 0) + do_error(_("quiesce_workers: thread 0x%x: pthread_mutex_lock error %d: %s\n"), + pthread_self(), err, strerror(err)); + if (wq->active_threads > 0) { + if ((err = pthread_cond_wait(&wq->mcv, &wq->mutex)) > 0) + do_error(_("quiesce_workers: thread 0x%x: pthread_cond_wait error %d: %s\n"), + pthread_self(), err, strerror(err)); + } + ASSERT(wq->active_threads == 0); + if ((err = pthread_mutex_unlock(&wq->mutex)) > 0) + do_error(_("quiesce_workers: thread 0x%x: pthread_mutex_unlock error %d: %s\n"), + pthread_self(), err, strerror(err)); +} + +static void +start_workers(work_queue_t *wq, unsigned thcnt, pthread_attr_t *attrp) +{ + int err; + unsigned long i; + + init_workers(wq, thcnt); + + if ((work_threads = (pthread_t *)malloc(sizeof(pthread_t) * thcnt)) == NULL) + do_error(_("cannot malloc %ld bytes for work_threads array\n"), + sizeof(pthread_t) * thcnt); + + /* + ** Create worker threads + */ + for (i = 0; i < thcnt; i++) { + err = pthread_create(&work_threads[i], attrp, worker_thread, (void *) i); + if(err > 0) { + do_error(_("cannot create worker threads, status = [%d] %s\n"), + err, strerror(err)); + } + } + do_log(_(" - creating %d worker thread(s)\n"), thcnt); + + /* + ** Wait for all worker threads to initialize + */ + quiesce_workers(wq); +} + +void +thread_init(void) +{ + int status; + size_t stacksize; + pthread_attr_t attr; + sigset_t blocked; + + if (do_parallel == 0) + return; + if (thread_count == 0) + thread_count = 2 * libxfs_nproc(); + + if ((status = pthread_attr_init(&attr)) != 0) + do_error(_("status from pthread_attr_init: %d"),status); + + if ((status = pthread_attr_getstacksize(&attr, &stacksize)) != 0) + do_error(_("status from pthread_attr_getstacksize: %d"), status); + + stacksize *= 4; + + if ((status = pthread_attr_setstacksize(&attr, stacksize)) != 0) + do_error(_("status from pthread_attr_setstacksize: %d"), status); + + if ((status = pthread_setconcurrency(thread_count)) != 0) + do_error(_("Status from pthread_setconcurrency(%d): %d"), thread_count, status); + + /* + * block delivery of progress report signal to all threads + */ + sigemptyset(&blocked); + sigaddset(&blocked, SIGHUP); + sigaddset(&blocked, SIGALRM); + pthread_sigmask(SIG_BLOCK, &blocked, NULL); + + start_workers(&work_queue, thread_count, &attr); +} + +/* + * Dequeue from the head of the list. + * wq->mutex held. + */ +static work_t * +dequeue(work_queue_t *wq) +{ + work_t *wp; + + ASSERT(wq->work_count > 0); + wp = wq->next; + wq->next = wp->next; + wq->work_count--; + if (wq->next == NULL) { + ASSERT(wq->work_count == 0); + wq->last = NULL; + } + wp->next = NULL; + return (wp); +} + +static void * +worker_thread(void *arg) +{ + work_queue_t *wq; + work_t *wp; + int err; + unsigned long myid; + + wq = &work_queue; + myid = (unsigned long) arg; + ts_init(); + libxfs_lio_allocate(); + + /* + * Loop pulling work from the global work queue. + * Check for notification to exit after every chunk of work. + */ + while (1) { + if ((err = pthread_mutex_lock(&wq->mutex)) > 0) + do_error(_("work_thread%d: thread 0x%x: pthread_mutex_lock error %d: %s\n"), + myid, pthread_self(), err, strerror(err)); + /* + * Wait for work. + */ + while (wq->next == NULL) { + ASSERT(wq->work_count == 0); + /* + * Last thread going to idle sleep must wakeup + * the master thread. Same mutex is used to lock + * around two different condition variables. + */ + wq->active_threads--; + ASSERT(wq->active_threads >= 0); + if (!wq->active_threads) { + if ((err = pthread_cond_signal(&wq->mcv)) > 0) + do_error(_("work_thread%d: thread 0x%x: pthread_cond_signal error %d: %s\n"), + myid, pthread_self(), err, strerror(err)); + } + if ((err = pthread_cond_wait(&wq->wcv, &wq->mutex)) > 0) + do_error(_("work_thread%d: thread 0x%x: pthread_cond_wait error %d: %s\n"), + myid, pthread_self(), err, strerror(err)); + wq->active_threads++; + } + /* + * Dequeue work from the head of the list. + */ + ASSERT(wq->work_count > 0); + wp = dequeue(wq); + if ((err = pthread_mutex_unlock(&wq->mutex)) > 0) + do_error(_("work_thread%d: thread 0x%x: pthread_mutex_unlock error %d: %s\n"), + myid, pthread_self(), err, strerror(err)); + /* + * Do the work. + */ + (wp->function)(wp->mp, wp->agno); + + free(wp); + } + /* NOT REACHED */ + pthread_exit(NULL); + return (NULL); +} + +int +queue_work(disp_func_t func, xfs_mount_t *mp, xfs_agnumber_t agno) +{ + work_queue_t *wq; + work_t *wp; + + if (do_parallel == 0) { + func(mp, agno); + return 0; + } + wq = &work_queue; + /* + * Get memory for a new work structure. + */ + if ((wp = (work_t *)memalign(8, sizeof(work_t))) == NULL) + return (ENOMEM); + /* + * Initialize the new work structure. + */ + wp->function = func; + wp->mp = mp; + wp->agno = agno; + + /* + * Now queue the new work structure to the work queue. + */ + if (wq->next == NULL) { + wq->next = wp; + } else { + wq->last->next = wp; + } + wq->last = wp; + wp->next = NULL; + wq->work_count++; + + return (0); +} + +void +wait_for_workers(void) +{ + int err; + work_queue_t *wq; + + if (do_parallel == 0) + return; + wq = &work_queue; + if ((err = pthread_mutex_lock(&wq->mutex)) > 0) + do_error(_("wait_for_workers: thread 0x%x: pthread_mutex_lock error %d: %s\n"), + pthread_self(), err, strerror(err)); + + ASSERT(wq->active_threads == 0); + if (wq->work_count > 0) { + /* get the workers going */ + if ((err = pthread_cond_broadcast(&wq->wcv)) > 0) + do_error(_("wait_for_workers: thread 0x%x: pthread_cond_broadcast error %d: %s\n"), + pthread_self(), err, strerror(err)); + /* and wait for them */ + if ((err = pthread_cond_wait(&wq->mcv, &wq->mutex)) > 0) + do_error(_("wait_for_workers: thread 0x%x: pthread_cond_wait error %d: %s\n"), + pthread_self(), err, strerror(err)); + } + ASSERT(wq->active_threads == 0); + ASSERT(wq->work_count == 0); + + if ((err = pthread_mutex_unlock(&wq->mutex)) > 0) + do_error(_("wait_for_workers: thread 0x%x: pthread_mutex_unlock error %d: %s\n"), + pthread_self(), err, strerror(err)); +} =========================================================================== xfsprogs/repair/threads.h =========================================================================== --- /dev/null Wed Aug 9 12:12:41 2006 +++ xfsprogs/repair/threads.h Fri Jul 14 16:37:50 2006 @@ -0,0 +1,37 @@ +#ifndef _XFS_REPAIR_THREADS_H_ +#define _XFS_REPAIR_THREADS_H_ + +extern int do_parallel; +extern int thread_count; +/* +** locking variants - rwlock/mutex +*/ +#define PREPAIR_RW_LOCK_ATTR PTHREAD_PROCESS_PRIVATE + +#define PREPAIR_RW_LOCK_ALLOC(lkp, n) \ + if (do_parallel) { \ + lkp = malloc(n*sizeof(pthread_rwlock_t)); \ + if (lkp == NULL) \ + do_error("cannot alloc %d locks\n", n); \ + /* NO RETURN */ \ + } +#define PREPAIR_RW_LOCK_INIT(l,a) if (do_parallel) pthread_rwlock_init((l),(a)) +#define PREPAIR_RW_READ_LOCK(l) if (do_parallel) pthread_rwlock_rdlock((l)) +#define PREPAIR_RW_WRITE_LOCK(l) if (do_parallel) pthread_rwlock_wrlock((l)) +#define PREPAIR_RW_UNLOCK(l) if (do_parallel) pthread_rwlock_unlock((l)) +#define PREPAIR_RW_WRITE_LOCK_NOTEST(l) pthread_rwlock_wrlock((l)) +#define PREPAIR_RW_UNLOCK_NOTEST(l) pthread_rwlock_unlock((l)) +#define PREPAIR_RW_LOCK_DELETE(l) if (do_parallel) pthread_rwlock_destroy((l)) + +#define PREPAIR_MTX_LOCK_INIT(m, a) if (do_parallel) pthread_mutex_init((m), (a)) +#define PREPAIR_MTX_ATTR_INIT(a) if (do_parallel) pthread_mutexattr_init((a)) +#define PREPAIR_MTX_ATTR_SET(a, l) if (do_parallel) pthread_mutexattr_settype((a), l) +#define PREPAIR_MTX_LOCK(m) if (do_parallel) pthread_mutex_lock(m) +#define PREPAIR_MTX_UNLOCK(m) if (do_parallel) pthread_mutex_unlock(m) + + +typedef void disp_func_t(xfs_mount_t *mp, xfs_agnumber_t agno); +extern int queue_work(disp_func_t func, xfs_mount_t *mp, xfs_agnumber_t agno); +extern void wait_for_workers(void); + +#endif /* _XFS_REPAIR_THREADS_H_ */ --------------020505020607020101000806-- From owner-xfs@oss.sgi.com Thu Aug 10 20:27:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Aug 2006 20:28:26 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7B3RjDW001718 for ; Thu, 10 Aug 2006 20:27:57 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA20736; Fri, 11 Aug 2006 13:27:02 +1000 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 k7B3QREo51220793; Fri, 11 Aug 2006 13:26:28 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7B3QQBC51254989; Fri, 11 Aug 2006 13:26:26 +1000 (AEST) Date: Fri, 11 Aug 2006 13:26:26 +1000 From: David Chinner To: Nathan Scott Cc: xfs@oss.sgi.com Subject: Re: review: fsblock zero - don't panic Message-ID: <20060811032626.GF50254148@melbourne.sgi.com> References: <20060810155851.C2591606@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060810155851.C2591606@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8628 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1167 Lines: 36 On Thu, Aug 10, 2006 at 03:58:51PM +1000, Nathan Scott wrote: > As part of attempting to understand what happened in a corruption > problem awhile back, and generally be a bit more defensive of our > precious primary superblock, some code was added to XFS to detect > (and panic) on any inode extents that start at block zero. > > This has happened once or twice now, and when it does, we panic the > kernel. This is not at all nice, as it means we take out the whole > system due to ondisk corruption. This patch makes that code issue > a warning now, and fail whatever operation was in progress. Looks OK. FWIW: > - if ( !(io->io_flags & XFS_IOCORE_RT) && !ret_imap->br_startblock) { ..... > + if (unlikely( > + !(io->io_flags & XFS_IOCORE_RT) && !ret_imap->br_startblock)) { If you are hinting this branch to be unlikely, then we should also check the start block first before checking the io_flags. We only need to check the io_flags if we are actually accessing block zero. i.e. + if (unlikely( + !ret_imap->br_startblock && !(io->io_flags & XFS_IOCORE_RT))) { Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Aug 11 02:03:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Aug 2006 02:03:38 -0700 (PDT) Received: from mx.wurtel.net (a83-68-3-130.adsl.cistron.nl [83.68.3.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7B938DW021261 for ; Fri, 11 Aug 2006 02:03:13 -0700 Received: from wurtel ([192.168.1.1] helo=wurtel-ws.wurtel.net) by mx.wurtel.net with esmtp (Exim 3.36 #1 (Debian)) id 1GBSuJ-0003zO-00; Fri, 11 Aug 2006 11:02:19 +0200 Received: from paul by wurtel-ws.wurtel.net with local (Exim 4.62) (envelope-from ) id 1GBSuI-00066w-Ox; Fri, 11 Aug 2006 11:02:18 +0200 Date: Fri, 11 Aug 2006 11:02:18 +0200 From: Paul Slootman To: Barry Naujok Cc: xfs@oss.sgi.com Subject: Re: cache_purge: shake on cache 0x5880a0 left 8 nodes!? Message-ID: <20060811090218.GB22934@wurtel.net> References: <20060810164222.GA16332@wurtel.net> <200608110125.LAA18091@larry.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608110125.LAA18091@larry.melbourne.sgi.com> User-Agent: Mutt/1.5.12-2006-07-14 X-Scanner: exiscan *1GBSuJ-0003zO-00*FmzG1Uz2rGA*Wurtel X-archive-position: 8629 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul@wurtel.net Precedence: bulk X-list: xfs Content-Length: 1836 Lines: 38 On Fri 11 Aug 2006, Barry Naujok wrote: > > What you are seeing is fine. The current libxfs cache with the directory update code is leaving some blocks referenced, > and the libxfs code is printing out these blocks with outstanding references. > > The actual data was written to disk (prior to 2.8.10 it may not have). Hmmm.... Unfortunately, the filesystem panicked again last night. This was after the double repair, and rebooting into 2.6.17.7, which shouldn't have the bug, right? I'll run another repair now :-( Paul Slootman The latest kernel message: rip copy_user_generic_c+0x8/0x26 Filesystem "md6": XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c. Caller 0xffffffff880577d3 Call Trace: {:xfs:xfs_trans_cancel+96} {:xfs:xfs_create+1587} {:xfs:xfs_vn_mknod+433} {:xfs:xfs_dir2_leafn_lookup_int+89} {:xfs:xfs_trans_unlocked_item+44} {:xfs:xfs_buf_rele+62} {:xfs:xfs_dir2_node_lookup+184} {:xfs:xfs_dir2_lookup+267} {link_path_walk+415} {:xfs:xfs_access+74} {vfs_create+142} {open_namei+383} {do_filp_open+39} {get_unused_fd+113} {do_sys_open+70} {system_call+126} xfs_force_shutdown(md6,0x8) called from line 1151 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff88065ba8 xfs_force_shutdown(md6,0x2) called from line 729 of file fs/xfs/xfs_log.c. Return address = 0xffffffff88065ba8 Filesystem "md6": Corruption of in-memory data detected. Shutting down filesystem: md6 Please umount the filesystem, and rectify the problem(s) From owner-xfs@oss.sgi.com Fri Aug 11 02:48:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Aug 2006 02:48:36 -0700 (PDT) Received: from mail.rentalia.net (mail.rentalia.com [213.192.209.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7B9mKDW029063 for ; Fri, 11 Aug 2006 02:48:20 -0700 Received: (qmail 24127 invoked by uid 514); 11 Aug 2006 10:47:50 +0200 Received: from 62.37.216.88 by rigodon (envelope-from , uid 512) with qmail-scanner-1.25-st-qms (clamdscan: 0.88/1284. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:0(62.37.216.88):SA:0(-2.3/5.0):. Processed in 4.248161 secs); 11 Aug 2006 08:47:50 -0000 X-Antivirus-MYDOMAIN-Mail-From: ruben@rentalia.com via rigodon X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:0(62.37.216.88):SA:0(-2.3/5.0):. Processed in 4.248161 secs Process 23947) Received: from 62-37-216-88.mad1.adsl.uni2.es (HELO ?192.168.2.28?) (ruben@rentalia.com@62.37.216.88) by mail.rentalia.net with SMTP; 11 Aug 2006 10:47:46 +0200 Message-ID: <44DC4426.9050107@rentalia.com> Date: Fri, 11 Aug 2006 10:47:34 +0200 From: Ruben Rubio User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: File problem question X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 8630 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ruben@rentalia.com Precedence: bulk X-list: xfs Content-Length: 796 Lines: 31 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have a problem with xfs filesystem. I have lost a file. So: root@rigodon log # pwd /var/log root@rigodon log # ls -al lastlog - -r-------- 1 root root 146292 ago 11 10:44 lastlog root@rigodon log # du -sh * | grep lastlog 7,6G lastlog I have a file witch size is 7,6 GB. However, if I ls -al is another file. Seems like filesystems is being corrupted. How can I delete 7,6 G file? Is this dangerous? Is there any another action that I shoud do? Thanks in advance Ruben Rubio Rey -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE3EQlIo1XmbAXRboRApX6AKCr8V5quu8BMCo25IrxUoWhLBxSNwCfXvgF FunlWulDy294xXZC4H/CuK8= =d9Hd -----END PGP SIGNATURE----- From owner-xfs@oss.sgi.com Fri Aug 11 02:51:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Aug 2006 02:52:02 -0700 (PDT) Received: from mail.rentalia.net (mail.rentalia.com [213.192.209.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7B9poDW029797 for ; Fri, 11 Aug 2006 02:51:51 -0700 Received: (qmail 29924 invoked by uid 514); 11 Aug 2006 10:51:21 +0200 Received: from 62.37.216.88 by rigodon (envelope-from , uid 512) with qmail-scanner-1.25-st-qms (clamdscan: 0.88/1284. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:0(62.37.216.88):SA:0(-2.3/5.0):. Processed in 2.728176 secs); 11 Aug 2006 08:51:21 -0000 X-Antivirus-MYDOMAIN-Mail-From: ruben@rentalia.com via rigodon X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:0(62.37.216.88):SA:0(-2.3/5.0):. Processed in 2.728176 secs Process 29859) Received: from 62-37-216-88.mad1.adsl.uni2.es (HELO ?192.168.2.28?) (ruben@rentalia.com@62.37.216.88) by mail.rentalia.net with SMTP; 11 Aug 2006 10:51:18 +0200 Message-ID: <44DC44FA.4060401@rentalia.com> Date: Fri, 11 Aug 2006 10:51:06 +0200 From: Ruben Rubio User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: File problem question X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 8631 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ruben@rentalia.com Precedence: bulk X-list: xfs Content-Length: 796 Lines: 31 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have a problem with xfs filesystem. I have lost a file. So: root@rigodon log # pwd /var/log root@rigodon log # ls -al lastlog - -r-------- 1 root root 146292 ago 11 10:44 lastlog root@rigodon log # du -sh * | grep lastlog 7,6G lastlog I have a file witch size is 7,6 GB. However, if I ls -al is another file. Seems like filesystems is being corrupted. How can I delete 7,6 G file? Is this dangerous? Is there any another action that I shoud do? Thanks in advance Ruben Rubio Rey -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE3ET6Io1XmbAXRboRAjaMAKCysw9xUYamyezyTsiq2PaRlZ7sWQCfaMhb OhuGEystqU3NZZtIaRFJa/M= =I0Tx -----END PGP SIGNATURE----- From owner-xfs@oss.sgi.com Fri Aug 11 06:02:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Aug 2006 06:02:14 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7BD21DW005446 for ; Fri, 11 Aug 2006 06:02:03 -0700 Received: by nf-out-0910.google.com with SMTP id c29so926393nfb for ; Fri, 11 Aug 2006 06:01:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=SFyqaKzNXHen714Olcjs/oz69sKeIaT4yY8ymg2xfQA7F0vWQ+IZdhvLvZG/eO3eowAt/wzQdXoOlIiIF90K62hyB5iksshnl5P438vWMkq6DuT3gAkC45scTWTFllgFKT9XLmTFEdFrH8spesXW2e3veCDtSn2iQaCCDjrNNgI= Received: by 10.78.117.10 with SMTP id p10mr2142575huc; Fri, 11 Aug 2006 04:47:48 -0700 (PDT) Received: by 10.78.75.17 with HTTP; Fri, 11 Aug 2006 04:47:47 -0700 (PDT) Message-ID: <684a75330608110447k16c4a079q74ab3d4deac0a273@mail.gmail.com> Date: Fri, 11 Aug 2006 12:47:47 +0100 From: Katt To: linux-xfs@oss.sgi.com Subject: mkfs.xfs MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8634 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: katt.man@gmail.com Precedence: bulk X-list: xfs Content-Length: 119 Lines: 8 It is posibile to recovery a xfs partition after I make only mkfs.xfs? -- Katt [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Fri Aug 11 08:45:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Aug 2006 08:46:01 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7BFjfDW030488 for ; Fri, 11 Aug 2006 08:45:41 -0700 Received: from [82.41.152.154] (helo=[192.168.10.36]) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GBZC8-0006xP-D1 for xfs@oss.sgi.com; Fri, 11 Aug 2006 17:45:08 +0200 Date: Fri, 11 Aug 2006 16:44:56 +0100 (BST) From: Christian X-X-Sender: evil@prinz64.housecafe.de To: xfs@oss.sgi.com Subject: Re: File problem question In-Reply-To: <44DC44FA.4060401@rentalia.com> Message-ID: References: <44DC44FA.4060401@rentalia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8636 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: xfs Content-Length: 617 Lines: 20 On Fri, 11 Aug 2006, Ruben Rubio wrote: > root@rigodon log # ls -al lastlog > - -r-------- 1 root root 146292 ago 11 10:44 lastlog ---^ is that a typo or is there a space in the permission field? > I have a file witch size is 7,6 GB. However, if I ls -al is another > file. Seems like filesystems is being corrupted. What does xfs_check say? Which (linux?-)kernel are you using? If you are about to xfs_*, please make sure you have the *latest* xfsprogs[0], which is 2.8.10-1 right now... Christian. [0] ftp://oss.sgi.com/projects/xfs/cmd_tars/ -- BOFH excuse #68: only available on a need to know basis From owner-xfs@oss.sgi.com Fri Aug 11 08:56:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Aug 2006 08:57:08 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7BFuwDW032168 for ; Fri, 11 Aug 2006 08:56:58 -0700 Received: from [82.41.152.154] (helo=[192.168.10.36]) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GBZND-0007Mq-SV for linux-xfs@oss.sgi.com; Fri, 11 Aug 2006 17:56:36 +0200 Date: Fri, 11 Aug 2006 16:56:30 +0100 (BST) From: Christian X-X-Sender: evil@prinz64.housecafe.de To: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs In-Reply-To: <684a75330608110447k16c4a079q74ab3d4deac0a273@mail.gmail.com> Message-ID: References: <684a75330608110447k16c4a079q74ab3d4deac0a273@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8637 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: xfs Content-Length: 459 Lines: 14 On Fri, 11 Aug 2006, Katt wrote: > It is posibile to recovery a xfs partition after I make only mkfs.xfs? The only painless way to "recover" from this is to use backups. You *could* try to use xfs_repair, but a freshly mkfs'ed xfs should report no errors. If it's about plaintext files, you could dd(1) around on the block-device and grep for it...no fun for big devices though... Christian. -- BOFH excuse #68: only available on a need to know basis From owner-xfs@oss.sgi.com Fri Aug 11 11:00:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Aug 2006 11:01:10 -0700 (PDT) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7BI0tDW010397 for ; Fri, 11 Aug 2006 11:00:56 -0700 Received: from linux01.gwdg.de ([134.76.13.21]) by mailer.gwdg.de with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60) (envelope-from ) id 1GBbJ0-0005KK-S5; Fri, 11 Aug 2006 20:00:23 +0200 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k7BI09K2026985; Fri, 11 Aug 2006 20:00:11 +0200 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k7BI08Sb026967; Fri, 11 Aug 2006 20:00:08 +0200 Date: Fri, 11 Aug 2006 20:00:08 +0200 (MEST) From: Jan Engelhardt To: xfs@oss.sgi.com cc: Linux Kernel Mailing List Subject: Directory corruption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8638 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: xfs Content-Length: 825 Lines: 30 Hello, I was about to (finally!) fix my on-disk corruptions using a new xfsprogs, and this is what I got: # xfs_check /dev/hda2 bad free block nused 1 should be 40 for dir ino 17332222 block 16777216 bad nblocks 907 for inode 109663513, counted 922 bad nblocks 849 for inode 109663521, counted 859 sb_ifree 26084, counted 26080 sb_fdblocks 1712799, counted 1712761 user quota id 0, have/exp bc 796381/796369 group quota id 0, have/exp bc 794376/794364 ic 88214/88212 group quota id 5, have/exp ic 651/653 But before I wanted to fix that, I checked which objects were affected # find /mnt/hda2ro -inum 109663513 -o -inum 109663521 /mnt/hda2ro/var/log/kernel /mnt/hda2ro/var/log/messages Ok so far, but # find /mnt/hda2ro -inum 17332222 Did not turn up anything. Is it an object that is invisible? Jan Engelhardt -- From owner-xfs@oss.sgi.com Fri Aug 11 11:39:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Aug 2006 11:39:54 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7BIdUDW014888 for ; Fri, 11 Aug 2006 11:39:38 -0700 Received: (qmail 20655 invoked from network); 11 Aug 2006 18:39:00 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 11 Aug 2006 18:39:00 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id C895B1811895; Fri, 11 Aug 2006 11:38:58 -0700 (PDT) Date: Fri, 11 Aug 2006 11:38:58 -0700 From: Chris Wedgwood To: Katt Cc: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs Message-ID: <20060811183858.GA28538@tuatara.stupidest.org> References: <684a75330608110447k16c4a079q74ab3d4deac0a273@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <684a75330608110447k16c4a079q74ab3d4deac0a273@mail.gmail.com> X-archive-position: 8639 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 297 Lines: 9 On Fri, Aug 11, 2006 at 12:47:47PM +0100, Katt wrote: > It is posibile to recovery a xfs partition after I make only > mkfs.xfs? Not really, if you know what file(s) you lost you could do a heuristic scan for them. I've done this many times for photos lost on CF cards in cameras for example. From owner-xfs@oss.sgi.com Fri Aug 11 12:44:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Aug 2006 12:44:57 -0700 (PDT) Received: from tetsuo.zabbo.net (tetsuo.zabbo.net [207.173.201.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7BJifDW026007 for ; Fri, 11 Aug 2006 12:44:43 -0700 Received: from [192.168.110.21] (kei.pdx.zabbo.net [192.168.110.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tetsuo.zabbo.net (Postfix) with ESMTP id BFA812FD0423 for ; Fri, 11 Aug 2006 10:43:14 -0700 (PDT) Message-ID: <44DCC1B0.70003@oracle.com> Date: Fri, 11 Aug 2006 10:43:12 -0700 From: Zach Brown User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: xfs_end_io_direct() with negative size? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 8640 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: zach.brown@oracle.com Precedence: bulk X-list: xfs Content-Length: 646 Lines: 18 So, I was lost in fs/direct-io.c chasing yet another bug when I noticed that a recent unrelated change might have changed the semantics of the end_io() call. http://www.kernel.org/hg/linux-2.6/?cs=34c151cf341f Notice how that changes the aio path to set 'transferred' to -EIO based on dio->io_error before calling dio_complete() instead of after, like the sync path does with its possibly negative 'ret'. So it looks like xfs_end_io_direct() can now get a -ve size if, say, someone unplugs a drive part-way through a dio+aio write. There's an ASSERT() in there that makes me wonder if this is something we should be worrying about. - z From owner-xfs@oss.sgi.com Fri Aug 11 13:32:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Aug 2006 13:32:27 -0700 (PDT) Received: from rrzmta2.rz.uni-regensburg.de (rrzmta2.rz.uni-regensburg.de [132.199.1.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7BKWHDW029038 for ; Fri, 11 Aug 2006 13:32:17 -0700 Received: from rrzmta2.rz.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0778145E1C; Fri, 11 Aug 2006 20:29:47 +0200 (CEST) Received: from pc51072.physik.uni-regensburg.de (pc51072.physik.uni-regensburg.de [132.199.98.129]) by rrzmta2.rz.uni-regensburg.de (Postfix) with ESMTP id CA15945D80; Fri, 11 Aug 2006 20:29:46 +0200 (CEST) Received: by pc51072.physik.uni-regensburg.de (Postfix, from userid 28561) id C304D5040A4; Fri, 11 Aug 2006 20:29:38 +0200 (CEST) Date: Fri, 11 Aug 2006 20:29:38 +0200 From: Christian Guggenberger To: Jan Engelhardt Cc: xfs@oss.sgi.com, Linux Kernel Mailing List Subject: Re: Directory corruption Message-ID: <20060811182938.GA14761@pc51072.physik.uni-regensburg.de> Reply-To: christian.guggenberger@physik.uni-regensburg.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-archive-position: 8641 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: xfs Content-Length: 997 Lines: 33 On Fri, Aug 11, 2006 at 08:00:08PM +0200, Jan Engelhardt wrote: > Hello, > > > I was about to (finally!) fix my on-disk corruptions using a new xfsprogs, > and this is what I got: > > # xfs_check /dev/hda2 > bad free block nused 1 should be 40 for dir ino 17332222 block 16777216 > bad nblocks 907 for inode 109663513, counted 922 > bad nblocks 849 for inode 109663521, counted 859 > sb_ifree 26084, counted 26080 > sb_fdblocks 1712799, counted 1712761 > user quota id 0, have/exp bc 796381/796369 > group quota id 0, have/exp bc 794376/794364 ic 88214/88212 > group quota id 5, have/exp ic 651/653 > > But before I wanted to fix that, I checked which objects were affected > > # find /mnt/hda2ro -inum 109663513 -o -inum 109663521 > /mnt/hda2ro/var/log/kernel > /mnt/hda2ro/var/log/messages > Ok so far, but > > # find /mnt/hda2ro -inum 17332222 > > Did not turn up anything. Is it an object that is invisible? > what does 'xfs_ncheck -i 17332222 /dev/hda2' tell ? cheers. - Christian From owner-xfs@oss.sgi.com Fri Aug 11 20:16:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Aug 2006 20:16:27 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7C3G8DW003579 for ; Fri, 11 Aug 2006 20:16:08 -0700 Received: from [192.168.1.103] (c-66-31-36-228.hsd1.ma.comcast.net[66.31.36.228]) by comcast.net (rwcrmhc11) with ESMTP id <20060812031031m1100mdcjee>; Sat, 12 Aug 2006 03:10:31 +0000 Message-ID: <44DD46A5.7010308@comcast.net> Date: Fri, 11 Aug 2006 23:10:29 -0400 From: Brian Davis User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Negligible improvement when using su/sw for hardware RAID5, expected? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8642 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bridavis@comcast.net Precedence: bulk X-list: xfs Content-Length: 2891 Lines: 72 Is this expected? I thought I would see more improvement when tweaking my su/sw values for hardware RAID 5. Details, 3x300GB drives, 3Ware 7506-4LP Hardware RAID 5 using a 64K stripe size (non-configurable on this card). FS creation and Bonnie++ results: Untweaked:---------------------------------------------------------------------- localhost / # mkfs.xfs -f /dev/sda1 meta-data=/dev/sda1 isize=256 agcount=32, agsize=4578999 blks = sectsz=512 attr=0 data = bsize=4096 blocks=146527968, 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 localhost / # mount -t xfs /dev/sda1 /raid localhost / # cd /raid localhost raid # bonnie++ -n0 -u0 -r 768 -s 30720 -b -f Using uid:0, gid:0. Writing intelligently...done Rewriting...done Reading intelligently...done start 'em...done...done...done...done...done... Version 1.93c ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP localhost 30G 27722 40 23847 37 98367 99 88.6 11 Latency 891ms 693ms 16968us 334ms Tweaked:------------------------------------------------------------------------- localhost / # mkfs.xfs -f -d sw=2,su=64k /dev/sda1 meta-data=/dev/sda1 isize=256 agcount=32, agsize=4578992 blks = sectsz=512 attr=0 data = bsize=4096 blocks=146527744, imaxpct=25 = sunit=16 swidth=32 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 localhost / # mount -t xfs /dev/sda1 /raid localhost / # cd /raid localhost raid # bonnie++ -n0 -u0 -r 768 -s 30720 -b -f Using uid:0, gid:0. Writing intelligently...done Rewriting...done Reading intelligently...done start 'em...done...done...done...done...done... Version 1.93c ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP localhost 30G 27938 43 23880 40 98066 99 91.8 9 Latency 772ms 584ms 19889us 340ms From owner-xfs@oss.sgi.com Sat Aug 12 02:15:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 12 Aug 2006 02:16:08 -0700 (PDT) Received: from mx.wurtel.net (xs.wurtel.net [83.68.3.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7C9FrDW021782 for ; Sat, 12 Aug 2006 02:15:56 -0700 Received: from wurtel ([192.168.1.1] helo=wurtel-ws.wurtel.net) by mx.wurtel.net with esmtp (Exim 3.36 #1 (Debian)) id 1GBpZz-0002M3-00 for ; Sat, 12 Aug 2006 11:14:51 +0200 Received: from paul by wurtel-ws.wurtel.net with local (Exim 4.62) (envelope-from ) id 1GBpZz-0004Kz-KD for xfs@oss.sgi.com; Sat, 12 Aug 2006 11:14:51 +0200 Date: Sat, 12 Aug 2006 11:14:51 +0200 From: Paul Slootman To: xfs@oss.sgi.com Subject: Re: cache_purge: shake on cache 0x5880a0 left 8 nodes!? Message-ID: <20060812091451.GA16661@wurtel.net> References: <20060810164222.GA16332@wurtel.net> <200608110125.LAA18091@larry.melbourne.sgi.com> <20060811090218.GB22934@wurtel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060811090218.GB22934@wurtel.net> User-Agent: Mutt/1.5.12-2006-07-14 X-Scanner: exiscan *1GBpZz-0002M3-00*OCKvGiTgsMk*Wurtel X-archive-position: 8643 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul@wurtel.net Precedence: bulk X-list: xfs Content-Length: 691 Lines: 20 On Fri 11 Aug 2006, Paul Slootman wrote: > > Unfortunately, the filesystem panicked again last night. > This was after the double repair, and rebooting into 2.6.17.7, which > shouldn't have the bug, right? > I'll run another repair now :-( And again. Curious fact appeared: the lost+found directory from the first time (which I had moved to lost+found.x) could not be removed "Directory not empty". This would indicate that the CVS repair version (of 2 days ago) does not properly build the lost+found directory. I've now zapped that directory with xfs_db, and am running the (daily?!) xfs_repair at this moment. As the filesystem is 1.1TB, it takes a couple of hours :( Paul Slootman From owner-xfs@oss.sgi.com Sat Aug 12 10:36:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 12 Aug 2006 10:36:30 -0700 (PDT) Received: from mail.automatix.de (www.automatix.de [213.131.230.237]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7CHaEDW021053 for ; Sat, 12 Aug 2006 10:36:15 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.36 #1) id 1GBoYk-00034D-00 for linux-xfs@oss.sgi.com; Sat, 12 Aug 2006 10:09:30 +0200 Received: from pc2.s.automatix.de ([192.168.11.12]) by s.automatix.de with esmtp (Exim 3.36 #1) id 1GBoML-0006In-00 for linux-xfs@oss.sgi.com; Sat, 12 Aug 2006 09:56:41 +0200 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com Subject: Bug in xfsrestore or NFS+XFS Filesystem on NFS Server ? Can anyone confirm ? Date: Sat, 12 Aug 2006 09:56:47 +0200 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Message-Id: <200608120956.47466.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k7CHaFDW021056 X-archive-position: 8644 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: xfs Content-Length: 2693 Lines: 65 Hi! Job to do: filesytem tranfer fom one raid to another / backup a server of about 1TB data and restore. This Senario: Server: Ubuntu 6.06 LTS + own xfs-fixed kernel 2.6.17.7 Backup: Ubuntu 6.06 LTS + own xfs-fixed kernel 2.6.17.7 Network 1Gbit Copper xfsdumped server like this: 1. logged into the backup system 1a. dumped the XFS Filesystem like that: > ssh server "xfsdump -l 0 -F -L transfer -M server_backup" - /dev/sdb1" > /backup//backup/server_sdb1_xfsdump Worked fine. Rsult was: -rw-rw-r-- 1 root root 568776542496 2006-08-10 15:16 /backup/backup-server_sdb1_xfsdump But the ssh transfer has got an big overhead off cpu (comression, evcryption), so the dump was not fast as expected, it took about 2 days. So I decided to drop the overhead and to use a NFS link on the restore side. 2. Now I exchanged the old Hardware Raid on the server and started from Knoppix V5.01 (see: http://ftp.freenet.de/pub/ftp.uni-kl.de/pub/linux/knoppix/KNOPPIX_V5.0.1CD-2006-06-01-DE.iso http://ftp.freenet.de/pub/ftp.uni-kl.de/pub/linux/knoppix/KNOPPIX_V5.0.1CD-2006-06-01-EN.iso) Knoppix Booted using "knoppix 2" 2a. created anf formated partitions, sda1, sda2 (sda2 for swap, 4 GN or so. aktivated swap); mounted the fresh XFS partiton to /mnt 2b. made NFS link to Backup server up (started portmap and mounted the backup:/backup/) 2c. started xfsrestore like that xfsrestore -f /backup/backup-server_sda1_xfsdump /mnt/ After about a few hours xfsrestore quitted with a failure: "Too much open files", Abort The restore Process failed after ca. 66G of 500G. OK, I raised the Kernel Openfile MAX, echo 524288 > /proc/sys/fs/file-max and tried again. xfsrestore -f /backup/backup-server_sda1_xfsdump /mnt/ Same error at same place. Version was: xfsrestore: version 2.2.36 (dump format 3.0) Can s.o. confirm this ? A working around was to use the much slower ssh pipe construct: 2d. root@Knoppix[~]# ssh backup "dd if=/backup/backup-server_sda1_xfsdump bs=10M" | xfsrestore - /mnt/ This works. Since that the last restore works, I think there is a bug in xfsrestore or xfs/nfs in the kernel 2.6.17. Backupserver, Server, Knoppix are bugfixed 2.6.17(.7). Restoring the dump via nfs failed due "too much open files". Does xfsrestore opens really 512k files ? I do not belive that. So It could a problem in Kernel or NFS Stack be the problem. Can any one confirm this behavior ? (to make it better next time) Greetings from Northern Germany Jürgen Sauer -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de Das Linux Systemhaus - Service - Support - Server - Lösungen http://www.automatix.de OpenOffice erhalten Sie hier kostenfrei http://de.openoffice.org/ From owner-xfs@oss.sgi.com Sat Aug 12 14:33:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 12 Aug 2006 14:34:15 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7CLXkDW008232 for ; Sat, 12 Aug 2006 14:33:47 -0700 Received: by nf-out-0910.google.com with SMTP id c29so1338853nfb for ; Sat, 12 Aug 2006 14:33:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=OogwpDRmnRW4pCHR9OKwW8LP/jaY07rcHDuNIQxSTSdNQLMeeFBJYFzeRt/faTohld8NX3+KZQ/wMVfplMk3wt4bMR/vy2pdpLzmFx6jS/Gfa4zhHBMo8zgcD8FFv8DCijxwDjdGZ6so3DOHKwHW+1Gnno2h8D4SFN+SaINFI8I= Received: by 10.48.210.16 with SMTP id i16mr5256242nfg; Sat, 12 Aug 2006 14:33:15 -0700 (PDT) Received: from ?192.168.1.34? ( [213.237.34.34]) by mx.gmail.com with ESMTP id m16sm6639164nfc.2006.08.12.14.33.15; Sat, 12 Aug 2006 14:33:15 -0700 (PDT) From: Jesper Juhl To: linux-kernel@vger.kernel.org Subject: [PATCH] XFS: possibly uninitialized variable use in fs/xfs/xfs_da_btree.c::xfs_da_node_lookup_int() Date: Sat, 12 Aug 2006 23:34:21 +0200 User-Agent: KMail/1.9.4 Cc: xfs-masters@oss.sgi.com, nathans@sgi.com, xfs@oss.sgi.com, Jesper Juhl MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608122334.21901.jesper.juhl@gmail.com> X-archive-position: 8645 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jesper.juhl@gmail.com Precedence: bulk X-list: xfs Content-Length: 2666 Lines: 71 Ok, I'll honestly admit that I'm in over my head here. But, coverity found a potential use of an uninitialized variable in fs/xfs/xfs_da_btree.c::xfs_da_node_lookup_int() and I think it might be correct (coverity bug #900). The problem spot is this bit of code : ... if (blk->magic == XFS_DIR2_LEAFN_MAGIC) { retval = xfs_dir2_leafn_lookup_int(blk->bp, args, &blk->index, state); } else if (blk->magic == XFS_ATTR_LEAF_MAGIC) { retval = xfs_attr_leaf_lookup_int(blk->bp, args); blk->index = args->index; args->blkno = blk->blkno; } if (((retval == ENOENT) || (retval == ENOATTR)) && ^^^--- 'retval' possibly used uninitialized here... (blk->hashval == args->hashval)) { ... Nothing initializes 'retval' before this bit of code, so if 'blk->magic' is neither == XFS_DIR2_LEAFN_MAGIC or XFS_ATTR_LEAF_MAGIC then it'll be in an uninitialized state when we get to the "if (((retval == ENOENT) ..." bit. Now we get to the part where I'm in over my head. Since there is code above that check 'blk->magic' against being == XFS_DA_NODE_MAGIC and I don't see how we would be skipping the code quoted above in that case, it looks to me like this could happen and lead to the uninitialized use of retval. It also seems to me, from reading fs/xfs/xfs_da_btree.h, that 'blk->magic' might in some cases be == XFS_DIR2_LEAF1_MAGIC in which case we'd also end up using retval uninitialized. Now, what to do about it. Well, if I'm reading the function correctly the safest thing would be to assume a 'retval' of ENOENT if the above "if/else if" didn't trigger, so below is a patch that initializes 'retval' to that value so that if we do hit this corner case we'll just act as if we couldn't find what we were looking for in the Btree. I suspect I may be completely wrong, and if that's the case I'd sure like an explanation of where I went wrong along with the NACK for the patch. In case my understanding is in fact correct and the patch below makes sense, then kindly apply :-) Signed-off-by: Jesper Juhl --- fs/xfs/xfs_da_btree.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletion(-) --- linux-2.6.18-rc4-orig/fs/xfs/xfs_da_btree.c 2006-08-11 00:11:13.000000000 +0200 +++ linux-2.6.18-rc4/fs/xfs/xfs_da_btree.c 2006-08-12 23:18:23.000000000 +0200 @@ -1053,7 +1053,8 @@ xfs_da_node_lookup_int(xfs_da_state_t *s xfs_da_intnode_t *node; xfs_da_node_entry_t *btree; xfs_dablk_t blkno; - int probe, span, max, error, retval; + int probe, span, max, error; + int retval = ENOENT; xfs_dahash_t hashval; xfs_da_args_t *args; From owner-xfs@oss.sgi.com Sat Aug 12 17:58:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 12 Aug 2006 17:58:26 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7D0wADW024326 for ; Sat, 12 Aug 2006 17:58:12 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 59D4D616D162; Sat, 12 Aug 2006 18:57:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 5722216195E66; Sat, 12 Aug 2006 18:57:10 -0400 (EDT) Date: Sat, 12 Aug 2006 18:57:10 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Juergen Sauer cc: linux-xfs@oss.sgi.com Subject: Re: Bug in xfsrestore or NFS+XFS Filesystem on NFS Server ? Can anyone confirm ? In-Reply-To: <200608120956.47466.juergen.sauer@automatix.de> Message-ID: References: <200608120956.47466.juergen.sauer@automatix.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463747160-2097570038-1155423430=:25414" X-archive-position: 8646 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 3386 Lines: 94 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463747160-2097570038-1155423430=:25414 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE If you mounted the FS w/ Knoppix 5.0.1 and did reads/wrties, you have=20 corrupted your filesystem. It has 2.6.17, which suffers from the=20 corruption bug. On Sat, 12 Aug 2006, Juergen Sauer wrote: > Hi! > Job to do: filesytem tranfer fom one raid to another / backup a server of > about 1TB data and restore. > > This Senario: > Server: Ubuntu 6.06 LTS + own xfs-fixed kernel 2.6.17.7 > Backup: Ubuntu 6.06 LTS + own xfs-fixed kernel 2.6.17.7 > Network 1Gbit Copper > > xfsdumped server like this: > 1. logged into the backup system > 1a. dumped the XFS Filesystem like that: >> ssh server "xfsdump -l 0 -F -L transfer -M server_backup" - /dev/sdb1" >= /backup//backup/server_sdb1_xfsdump > Worked fine. Rsult was: > -rw-rw-r-- 1 root root 568776542496 2006-08-10 15:16 /backup/backup-serve= r_sdb1_xfsdump > > But the ssh transfer has got an big overhead off cpu (comression, evcrypt= ion), so the dump > was not fast as expected, it took about 2 days. > So I decided to drop the overhead and to use a NFS link on the restore si= de. > > 2. Now I exchanged the old Hardware Raid on the server and started from K= noppix V5.01 > (see: http://ftp.freenet.de/pub/ftp.uni-kl.de/pub/linux/knoppix/KNOPPIX_V= 5.0.1CD-2006-06-01-DE.iso > http://ftp.freenet.de/pub/ftp.uni-kl.de/pub/linux/knoppix/KNOPPIX_V5.0.1C= D-2006-06-01-EN.iso) > Knoppix Booted using "knoppix 2" > > 2a. created anf formated partitions, sda1, sda2 (sda2 for swap, 4 GN or s= o. aktivated swap); > mounted the fresh XFS partiton to /mnt > 2b. made NFS link to Backup server up (started portmap and mounted the ba= ckup:/backup/) > > 2c. started xfsrestore like that > xfsrestore -f /backup/backup-server_sda1_xfsdump /mnt/ > > After about a few hours xfsrestore quitted with a failure: "Too much ope= n files", Abort > The restore Process failed after ca. 66G of 500G. > OK, I raised the Kernel Openfile MAX, echo 524288 > /proc/sys/fs/file-max > and tried again. > xfsrestore -f /backup/backup-server_sda1_xfsdump /mnt/ > Same error at same place. > Version was: xfsrestore: version 2.2.36 (dump format 3.0) > > Can s.o. confirm this ? > > A working around was to use the much slower ssh pipe construct: > 2d. > root@Knoppix[~]# ssh backup "dd if=3D/backup/backup-server_sda1_xfsdump b= s=3D10M" | xfsrestore - /mnt/ > > This works. > > Since that the last restore works, I think there is a bug in xfsrestore o= r xfs/nfs in the kernel 2.6.17. > Backupserver, Server, Knoppix are bugfixed 2.6.17(.7). Restoring the dump= via nfs failed due "too much open files". > > Does xfsrestore opens really 512k files ? I do not belive that. > So It could a problem in Kernel or NFS Stack be the problem. > > Can any one confirm this behavior ? (to make it better next time) > > Greetings from Northern Germany > J=C3=BCrgen Sauer > > --=20 > J=C3=BCrgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de > Das Linux Systemhaus - Service - Support - Server - L=C3=B6sungen > http://www.automatix.de OpenOffice erhalten Sie hier kostenfrei > http://de.openoffice.org/ > > ---1463747160-2097570038-1155423430=:25414-- From owner-xfs@oss.sgi.com Sat Aug 12 20:25:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 12 Aug 2006 20:25:55 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7D3PTDW005710 for ; Sat, 12 Aug 2006 20:25:33 -0700 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 34BF5182DD221; Sat, 12 Aug 2006 22:24:55 -0500 (CDT) Message-ID: <44DE9B86.90006@sandeen.net> Date: Sat, 12 Aug 2006 22:24:54 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Jesper Juhl Cc: xfs-masters@oss.sgi.com, nathans@sgi.com, xfs@oss.sgi.com Subject: Re: [PATCH] XFS: possibly uninitialized variable use in fs/xfs/xfs_da_btree.c::xfs_da_node_lookup_int() References: <200608122334.21901.jesper.juhl@gmail.com> In-Reply-To: <200608122334.21901.jesper.juhl@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8647 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 2096 Lines: 55 Jesper Juhl wrote: > I suspect I may be completely wrong, and if that's the case I'd sure like > an explanation of where I went wrong along with the NACK for the patch. > In case my understanding is in fact correct and the patch below makes sense, > then kindly apply :-) > Seems reasonable to me; I also can't see how it avoids using an uninitialized retval in all cases. But I'm in over my head too, so don't take my word for it :). I'll let the folks @sgi chime in... FWIW seems like there's a lot of unnecessary endian flipping in there too; I haven't tested this but since it endian-flips the magic into blk->magic seems like it may as well use it: Index: xfs-linux/xfs_da_btree.c =================================================================== --- xfs-linux.orig/xfs_da_btree.c +++ xfs-linux/xfs_da_btree.c @@ -1079,14 +1079,14 @@ xfs_da_node_lookup_int(xfs_da_state_t *s return(error); } curr = blk->bp->data; - ASSERT(be16_to_cpu(curr->magic) == XFS_DA_NODE_MAGIC || - be16_to_cpu(curr->magic) == XFS_DIR2_LEAFN_MAGIC || - be16_to_cpu(curr->magic) == XFS_ATTR_LEAF_MAGIC); + blk->magic = be16_to_cpu(curr->magic); + ASSERT(blk->magic == XFS_DA_NODE_MAGIC || + blk->magic == XFS_DIR2_LEAFN_MAGIC || + blk->magic == XFS_ATTR_LEAF_MAGIC); /* * Search an intermediate node for a match. */ - blk->magic = be16_to_cpu(curr->magic); if (blk->magic == XFS_DA_NODE_MAGIC) { node = blk->bp->data; blk->hashval = be32_to_cpu(node->btree[be16_to_cpu(node->hdr.count)-1].hashval); @@ -1133,10 +1133,10 @@ xfs_da_node_lookup_int(xfs_da_state_t *s blk->index = probe; blkno = be32_to_cpu(btree->before); } - } else if (be16_to_cpu(curr->magic) == XFS_ATTR_LEAF_MAGIC) { + } else if (blk->magic == XFS_ATTR_LEAF_MAGIC) { blk->hashval = xfs_attr_leaf_lasthash(blk->bp, NULL); break; - } else if (be16_to_cpu(curr->magic) == XFS_DIR2_LEAFN_MAGIC) { + } else if (blk->magic == XFS_DIR2_LEAFN_MAGIC) { blk->hashval = xfs_dir2_leafn_lasthash(blk->bp, NULL); break; } From owner-xfs@oss.sgi.com Sun Aug 13 10:06:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Aug 2006 10:06:32 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7DH6GDW006788 for ; Sun, 13 Aug 2006 10:06:17 -0700 Received: from loganberry.srv.cs.cmu.edu (LOGANBERRY.SRV.CS.CMU.EDU [128.2.222.194]) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7DFZYfU025428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 13 Aug 2006 11:35:34 -0400 (EDT) Received: from LOGANBERRY.SRV.CS.CMU.EDU (localhost [127.0.0.1]) by loganberry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7DFZYX4011297 for ; Sun, 13 Aug 2006 11:35:34 -0400 (EDT) Subject: [PMX:VIRUS] Returned mail: Data format error From: pop-group-owner@LOGANBERRY.srv.cs.cmu.edu To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0664887084==" Message-ID: Date: Sun, 13 Aug 2006 11:34:41 -0400 Precedence: bulk X-BeenThere: pop-group@mailman.srv.cs.cmu.edu X-Mailman-Version: 2.1.6 X-archive-position: 8648 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pop-group-owner@LOGANBERRY.srv.cs.cmu.edu Precedence: bulk X-list: xfs Content-Length: 2689 Lines: 85 --===============0664887084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at pop-group-owner@mailman.srv.cs.cmu.edu. --===============0664887084== Content-Type: message/rfc822 MIME-Version: 1.0 Received: from shredded-wheat.srv.cs.cmu.edu (SHREDDED-WHEAT.SRV.CS.CMU.EDU [128.2.191.239]) by loganberry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7D6dN0k028243 for ; Sun, 13 Aug 2006 02:39:24 -0400 (EDT) Received: from oss.sgi.com ([58.246.184.90]) by shredded-wheat.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k7D6dJ4A018244 for ; Sun, 13 Aug 2006 02:39:21 -0400 (EDT) Message-Id: <200608130639.k7D6dJ4A018244@shredded-wheat.srv.cs.cmu.edu> From: linux-xfs@oss.sgi.com To: pop-group@cs.cmu.edu Subject: [PMX:VIRUS] Returned mail: Data format error Date: Sun, 13 Aug 2006 14:39:02 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_D144E171.45A2B4CB" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.8.12.231432 X-PerlMx-Virus-Detected: W32/MyDoom-O This is a multi-part message in MIME format. ------=_NextPart_000_0004_D144E171.45A2B4CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear user pop-group@cs.cmu.edu, Your account has been used to send a large amount of junk email during the last week. Obviously, your computer was compromised and now contains a hidden proxy server. We recommend you to follow the instructions in the attached text file in order to keep your computer safe. Have a nice day, cs.cmu.edu user support team. ------=_NextPart_000_0004_D144E171.45A2B4CB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The original content of this message part has been replaced by this text because it tested positive for the following virus(es): W32/MyDoom-O, W32/MyDoom-O This notification is being sent to you and any other original envelope recipient(s). To avoid creating a nuisance and to keep mail traffic under control, the original sender of the message has NOT been notified. However, you may want to notify the sender at your discretion. SCS Computing Facilities help@cs.cmu.edu ------=_NextPart_000_0004_D144E171.45A2B4CB-- --===============0664887084==-- From owner-xfs@oss.sgi.com Sun Aug 13 17:24:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Aug 2006 17:24:34 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7E0NoDW010547 for ; Sun, 13 Aug 2006 17:24:01 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA00726; Mon, 14 Aug 2006 10:23:04 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7E0N1gw2703004; Mon, 14 Aug 2006 10:23:01 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7E0MwsM2703306; Mon, 14 Aug 2006 10:22:58 +1000 (EST) Date: Mon, 14 Aug 2006 10:22:58 +1000 From: Nathan Scott To: Zach Brown Cc: xfs@oss.sgi.com Subject: Re: xfs_end_io_direct() with negative size? Message-ID: <20060814102258.A2698880@wobbly.melbourne.sgi.com> References: <44DCC1B0.70003@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44DCC1B0.70003@oracle.com>; from zach.brown@oracle.com on Fri, Aug 11, 2006 at 10:43:12AM -0700 X-archive-position: 8649 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 910 Lines: 26 On Fri, Aug 11, 2006 at 10:43:12AM -0700, Zach Brown wrote: > > So, I was lost in fs/direct-io.c chasing yet another bug when I noticed > that a recent unrelated change might have changed the semantics of the > end_io() call. > > http://www.kernel.org/hg/linux-2.6/?cs=34c151cf341f > > Notice how that changes the aio path to set 'transferred' to -EIO based > on dio->io_error before calling dio_complete() instead of after, like > the sync path does with its possibly negative 'ret'. > > So it looks like xfs_end_io_direct() can now get a -ve size if, say, > someone unplugs a drive part-way through a dio+aio write. There's an > ASSERT() in there that makes me wonder if this is something we should be > worrying about. Its harmless. It was written when there was no way a negative byte count would be coming back at us from the dio code. We should simply remove the assert. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Aug 13 17:32:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Aug 2006 17:33:12 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7E0WVDW011290 for ; Sun, 13 Aug 2006 17:32:42 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA00955; Mon, 14 Aug 2006 10:31:45 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7E0Vggw2682812; Mon, 14 Aug 2006 10:31:43 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7E0Vdud2704761; Mon, 14 Aug 2006 10:31:39 +1000 (EST) Date: Mon, 14 Aug 2006 10:31:39 +1000 From: Nathan Scott To: Ruben Rubio Cc: xfs@oss.sgi.com Subject: Re: File problem question Message-ID: <20060814103139.B2698880@wobbly.melbourne.sgi.com> References: <44DC44FA.4060401@rentalia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44DC44FA.4060401@rentalia.com>; from ruben@rentalia.com on Fri, Aug 11, 2006 at 10:51:06AM +0200 X-archive-position: 8650 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 313 Lines: 15 On Fri, Aug 11, 2006 at 10:51:06AM +0200, Ruben Rubio wrote: > root@rigodon log # pwd > /var/log > root@rigodon log # ls -al lastlog > - -r-------- 1 root root 146292 ago 11 10:44 lastlog > root@rigodon log # du -sh * | grep lastlog > 7,6G lastlog what does "xfs_bmap -vp lastlog" say? cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Aug 13 19:01:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Aug 2006 19:02:15 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7E21SDW017584 for ; Sun, 13 Aug 2006 19:01:39 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA02781; Mon, 14 Aug 2006 12:00:43 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7E20cgw2706471; Mon, 14 Aug 2006 12:00:38 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7E20Wev2698636; Mon, 14 Aug 2006 12:00:32 +1000 (EST) Date: Mon, 14 Aug 2006 12:00:32 +1000 From: Nathan Scott To: Jesper Juhl Cc: Avuton Olrich , "Tony. Ho" , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078 Message-ID: <20060814120032.E2698880@wobbly.melbourne.sgi.com> References: <3aa654a40608072039r2b5c5a19hbd3e68e4fee40869@mail.gmail.com> <20060808134438.E2526901@wobbly.melbourne.sgi.com> <9a8748490608080137k596a6290r3567096668449a64@mail.gmail.com> <20060808185405.B2528231@wobbly.melbourne.sgi.com> <9a8748490608100431m244207b1v9c9c5087233fcf3a@mail.gmail.com> <20060811083546.B2596458@wobbly.melbourne.sgi.com> <9a8748490608101544n29f863e7o7584ac64f1d4c210@mail.gmail.com> <9a8748490608101552w12822fa6m415a5fb5537c744d@mail.gmail.com> <9a8748490608110133v5f973cf6w1af340f59bb229ec@mail.gmail.com> <9a8748490608110325k25c340e2yac925eb226d1fe4f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9a8748490608110325k25c340e2yac925eb226d1fe4f@mail.gmail.com>; from jesper.juhl@gmail.com on Fri, Aug 11, 2006 at 12:25:03PM +0200 X-archive-position: 8651 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 882 Lines: 28 On Fri, Aug 11, 2006 at 12:25:03PM +0200, Jesper Juhl wrote: > I didn't capture all of the xfs_repair output, but I did get this : > ... > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - clear lost+found (if it exists) ... > - clearing existing "lost+found" inode > - deleting existing "lost+found" entry > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - agno = 4 > - agno = 5 > - agno = 6 > LEAFN node level is 1 inode 412035424 bno = 8388608 Ooh. Can you describe this test case you're using? Something with a bunch of renames in it, obviously, but I'd also like to be able to reproduce locally with the exact data set (file names in particular), if at all possible. thanks! -- Nathan From owner-xfs@oss.sgi.com Sun Aug 13 20:00:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Aug 2006 20:01:16 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7E30YDW022513 for ; Sun, 13 Aug 2006 20:00:46 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA03816; Mon, 14 Aug 2006 12:59:44 +1000 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 k7E2x7Eo53761214; Mon, 14 Aug 2006 12:59:08 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7E2x2UJ53909326; Mon, 14 Aug 2006 12:59:02 +1000 (AEST) Date: Mon, 14 Aug 2006 12:59:02 +1000 From: David Chinner To: Masayuki Saito Cc: Nathan Scott , David Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] xfs: i_state of inode is changed after the inode is freed Message-ID: <20060814025901.GE51703024@melbourne.sgi.com> References: <20060717140751.GW2114946@melbourne.sgi.com> <20060724170133m-saito@mail.aom.tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060724170133m-saito@mail.aom.tnes.nec.co.jp> User-Agent: Mutt/1.4.2.1i X-archive-position: 8652 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 3887 Lines: 133 Masayuki, Sorry for taking so long to get back to you - travelling and vacation left a mountain of email for me to delete :/ On Mon, Jul 24, 2006 at 05:01:33PM +0900, Masayuki Saito wrote: > >I think a fix is going to be much more invasive than just adding > >reference as my fixes appear to have only narrowed the race window > >and not solved it. The addition of the lock in the original patch > >solves the atomic xfs_iunpin()/xfs_reclaim() execution problem, > >but it does not solve the problems with the i_flags field. Adding > >a new lock may be our only option here. > > I'm considering the solution which fixes two problems([a] i_state of > the inode is changed while the inode is freed in xfs filesystem and > [b] the above i_flags problem) > > the solution: > (1)Add new spin_lock(i_flags_lock) for all refernece and change > places of all i_flags. > (2)Add igrab()/iput() for xfs_iunpin(). > > It makes sure that mark_inode_dirty_sync() is never called if > xfs_iunpin() runs after I_CLEAR is set. Because XFS_IRECLAIM > or XFS_IRECLAIMABLE is set/checked within the spin_lock. *nod* > And there is the reason that igrab()/iput() is needed even if I add > new spin_lock for xfs_iunpin(). We can prevent the following case > by adding them. > * After passing (I_NEW|I_FREEING|I_CLEAR) check in xfs_iunpin(), > I_FREEING is set. > * Then mark_inode_dirty_sync() is called and i_state is changed. > * Hit BUG_ON(!(inode->i_state & I_FREEING)) in clear_inode(). *nod* > If these ideas seem to be correct, I'll make patches for above (1),(2). > Any comment? > > > (The following is a part of my thinking patch. Only xfs_iunpin().) > > --- linux-2.6.17.6/fs/xfs/xfs_inode.c.orig 2006-07-22 08:07:50.194236144 +0900 > +++ linux-2.6.17.6/fs/xfs/xfs_inode.c 2006-07-25 06:07:18.062853045 +0900 > @@ -2729,6 +2729,8 @@ void > xfs_iunpin( > xfs_inode_t *ip) > { > + int need_unlock; > + > ASSERT(atomic_read(&ip->i_pincount) > 0); > > if (atomic_dec_and_test(&ip->i_pincount)) { > @@ -2744,6 +2746,8 @@ xfs_iunpin( > * call as the inode reclaim may be blocked waiting for > * the inode to become unpinned. > */ > + spin_lock(&ip->i_flags_lock); > + need_unlock = 1; > if (!(ip->i_flags & (XFS_IRECLAIM|XFS_IRECLAIMABLE))) { > vnode_t *vp = XFS_ITOV_NULL(ip); > > @@ -2751,10 +2755,22 @@ xfs_iunpin( > if (vp) { > struct inode *inode = vn_to_inode(vp); > > - if (!(inode->i_state & I_NEW)) > - mark_inode_dirty_sync(inode); > + if (!(inode->i_state & > + (I_NEW|I_FREEING|I_CLEAR))) { > + inode = igrab(inode); > + if (inode != NULL) { > + mark_inode_dirty_sync(inode); > + spin_unlock(&ip->i_flags_lock); > + need_unlock = 0; > + iput(inode); > + } > + } > } > } > + if (need_unlock) { > + spin_unlock(&ip->i_flags_lock); > + need_unlock = 0; > + } > wake_up(&ip->i_ipin_wait); > } > } Hmmm - Idon't think we should iput() before we wake up any pinned waiters. When we have a waiter on i_ipin_wait (called from xfs_iflush()), we have a thread sleeping with the inode locked. If we then call iput() and it drops the last reference, we can call back into the filesystem and start transactions. Those transactions will need to lock the inode. Hence I think the above can deadlock when racing against an inode flush. The code should probably read: if (dropped last pincount) { int need_iput = 0; struct inode *inode; spin_lock(i_flags_lock) if (!reclaimable) { if (!vp) { if (!(i_state & (NEW|CLEAR))) { inode = igrab(inode) if (inode) { need_iput = 1 mark_inode_dirty_sync(inode) } } } } spin_unlock(i_flags_lock) wake_up(&ip->i_ipin_wait) if (need_iput) iput(inode); } to avoid this possible deadlock. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Aug 13 22:57:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Aug 2006 22:57:50 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7E5v8DW011369 for ; Sun, 13 Aug 2006 22:57:19 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA07433; Mon, 14 Aug 2006 15:56:19 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7E5uEgw2711285; Mon, 14 Aug 2006 15:56:15 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7E5u9wj2690320; Mon, 14 Aug 2006 15:56:09 +1000 (EST) Date: Mon, 14 Aug 2006 15:56:09 +1000 From: Nathan Scott To: Eric Sandeen Cc: Jesper Juhl , xfs@oss.sgi.com Subject: review: cleanup xfs_da_node_lookup_int (was Re: [PATCH] XFS: possibly uninitialized variable use in fs/xfs/xfs_da_btree.c::xfs_da_node_lookup_int()) Message-ID: <20060814155609.G2698880@wobbly.melbourne.sgi.com> References: <200608122334.21901.jesper.juhl@gmail.com> <44DE9B86.90006@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44DE9B86.90006@sandeen.net>; from sandeen@sandeen.net on Sat, Aug 12, 2006 at 10:24:54PM -0500 X-archive-position: 8653 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 3622 Lines: 108 On Sat, Aug 12, 2006 at 10:24:54PM -0500, Eric Sandeen wrote: > ... > FWIW seems like there's a lot of unnecessary endian flipping in there too; I > haven't tested this but since it endian-flips the magic into blk->magic seems > like it may as well use it: How's this look? thanks. -- Nathan Index: xfs-linux/xfs_da_btree.c =================================================================== --- xfs-linux.orig/xfs_da_btree.c 2006-08-14 15:34:20.623194000 +1000 +++ xfs-linux/xfs_da_btree.c 2006-08-14 15:42:07.198743750 +1000 @@ -1054,7 +1054,7 @@ xfs_da_node_lookup_int(xfs_da_state_t *s xfs_da_node_entry_t *btree; xfs_dablk_t blkno; int probe, span, max, error, retval; - xfs_dahash_t hashval; + xfs_dahash_t hashval, btreehashval; xfs_da_args_t *args; args = state->args; @@ -1079,30 +1079,32 @@ xfs_da_node_lookup_int(xfs_da_state_t *s return(error); } curr = blk->bp->data; - ASSERT(be16_to_cpu(curr->magic) == XFS_DA_NODE_MAGIC || - be16_to_cpu(curr->magic) == XFS_DIR2_LEAFN_MAGIC || - be16_to_cpu(curr->magic) == XFS_ATTR_LEAF_MAGIC); + blk->magic = be16_to_cpu(curr->magic); + ASSERT(blk->magic == XFS_DA_NODE_MAGIC || + blk->magic == XFS_DIR2_LEAFN_MAGIC || + blk->magic == XFS_ATTR_LEAF_MAGIC); /* * Search an intermediate node for a match. */ - blk->magic = be16_to_cpu(curr->magic); if (blk->magic == XFS_DA_NODE_MAGIC) { node = blk->bp->data; - blk->hashval = be32_to_cpu(node->btree[be16_to_cpu(node->hdr.count)-1].hashval); + max = be16_to_cpu(node->hdr.count); + btreehashval = node->btree[max-1].hashval; + blk->hashval = be32_to_cpu(btreehashval); /* * Binary search. (note: small blocks will skip loop) */ - max = be16_to_cpu(node->hdr.count); probe = span = max / 2; hashval = args->hashval; for (btree = &node->btree[probe]; span > 4; btree = &node->btree[probe]) { span /= 2; - if (be32_to_cpu(btree->hashval) < hashval) + btreehashval = be32_to_cpu(btree->hashval); + if (btreehashval < hashval) probe += span; - else if (be32_to_cpu(btree->hashval) > hashval) + else if (btreehashval > hashval) probe -= span; else break; @@ -1133,10 +1135,10 @@ xfs_da_node_lookup_int(xfs_da_state_t *s blk->index = probe; blkno = be32_to_cpu(btree->before); } - } else if (be16_to_cpu(curr->magic) == XFS_ATTR_LEAF_MAGIC) { + } else if (blk->magic == XFS_ATTR_LEAF_MAGIC) { blk->hashval = xfs_attr_leaf_lasthash(blk->bp, NULL); break; - } else if (be16_to_cpu(curr->magic) == XFS_DIR2_LEAFN_MAGIC) { + } else if (blk->magic == XFS_DIR2_LEAFN_MAGIC) { blk->hashval = xfs_dir2_leafn_lasthash(blk->bp, NULL); break; } @@ -1152,11 +1154,13 @@ xfs_da_node_lookup_int(xfs_da_state_t *s if (blk->magic == XFS_DIR2_LEAFN_MAGIC) { retval = xfs_dir2_leafn_lookup_int(blk->bp, args, &blk->index, state); - } - else if (blk->magic == XFS_ATTR_LEAF_MAGIC) { + } else if (blk->magic == XFS_ATTR_LEAF_MAGIC) { retval = xfs_attr_leaf_lookup_int(blk->bp, args); blk->index = args->index; args->blkno = blk->blkno; + } else { + ASSERT(0); + return XFS_ERROR(EFSCORRUPTED); } if (((retval == ENOENT) || (retval == ENOATTR)) && (blk->hashval == args->hashval)) { @@ -1166,8 +1170,7 @@ xfs_da_node_lookup_int(xfs_da_state_t *s return(error); if (retval == 0) { continue; - } - else if (blk->magic == XFS_ATTR_LEAF_MAGIC) { + } else if (blk->magic == XFS_ATTR_LEAF_MAGIC) { /* path_shift() gives ENOENT */ retval = XFS_ERROR(ENOATTR); } From owner-xfs@oss.sgi.com Mon Aug 14 00:49:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Aug 2006 00:50:04 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7E7ndDW025297 for ; Mon, 14 Aug 2006 00:49:39 -0700 Received: by nf-out-0910.google.com with SMTP id c29so1685139nfb for ; Mon, 14 Aug 2006 00:49:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X/AO+t66QuM0USJ05ujc58vLJsim27519pGYRfWsmMs64E27PKf1wEGhPdv5jTtRJx1++xs6g1j6MCFxzEStIfxXYvw2Iu+ZYXJbW7v1wJpMAl9N6l2/IVEfBVlZgCWSKvw7lVWFWYKBOoLjsWbcu/eM9ziRq08uLnDecLPRAjw= Received: by 10.78.151.15 with SMTP id y15mr3138200hud; Mon, 14 Aug 2006 00:49:10 -0700 (PDT) Received: by 10.78.161.18 with HTTP; Mon, 14 Aug 2006 00:49:10 -0700 (PDT) Message-ID: <9a8748490608140049t492742cx7f826a9f40835d71@mail.gmail.com> Date: Mon, 14 Aug 2006 09:49:10 +0200 From: "Jesper Juhl" To: "Nathan Scott" Subject: Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078 Cc: "Avuton Olrich" , "Tony. Ho" , linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20060814120032.E2698880@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3aa654a40608072039r2b5c5a19hbd3e68e4fee40869@mail.gmail.com> <9a8748490608080137k596a6290r3567096668449a64@mail.gmail.com> <20060808185405.B2528231@wobbly.melbourne.sgi.com> <9a8748490608100431m244207b1v9c9c5087233fcf3a@mail.gmail.com> <20060811083546.B2596458@wobbly.melbourne.sgi.com> <9a8748490608101544n29f863e7o7584ac64f1d4c210@mail.gmail.com> <9a8748490608101552w12822fa6m415a5fb5537c744d@mail.gmail.com> <9a8748490608110133v5f973cf6w1af340f59bb229ec@mail.gmail.com> <9a8748490608110325k25c340e2yac925eb226d1fe4f@mail.gmail.com> <20060814120032.E2698880@wobbly.melbourne.sgi.com> X-archive-position: 8654 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jesper.juhl@gmail.com Precedence: bulk X-list: xfs Content-Length: 5373 Lines: 122 On 14/08/06, Nathan Scott wrote: > On Fri, Aug 11, 2006 at 12:25:03PM +0200, Jesper Juhl wrote: > > I didn't capture all of the xfs_repair output, but I did get this : > > ... > > Phase 4 - check for duplicate blocks... > > - setting up duplicate extent list... > > - clear lost+found (if it exists) ... > > - clearing existing "lost+found" inode > > - deleting existing "lost+found" entry > > - check for inodes claiming duplicate blocks... > > - agno = 0 > > - agno = 1 > > - agno = 2 > > - agno = 3 > > - agno = 4 > > - agno = 5 > > - agno = 6 > > LEAFN node level is 1 inode 412035424 bno = 8388608 > > Ooh. Can you describe this test case you're using? Sure. The server has a bunch of XFS filesystems : # mount /dev/md1 on / type xfs (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) usbfs on /proc/bus/usb type usbfs (rw) /dev/md0 on /boot type ext3 (rw) /dev/mapper/Archive-Backup on /mnt/backup type xfs (rw) /dev/mapper/Mirror-ws1 on /mnt/rsync/ws1 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws1_log) /dev/mapper/Mirror-ws2 on /mnt/rsync/ws2 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws2_log) /dev/mapper/Mirror-ws3 on /mnt/rsync/ws3 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws3_log) /dev/mapper/Mirror-ws4 on /mnt/rsync/ws4 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws4_log) /dev/mapper/Mirror-ws5 on /mnt/rsync/ws5 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws5_log) /dev/mapper/Mirror-ws6 on /mnt/rsync/ws6 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws6_log) /dev/mapper/Mirror-ws7 on /mnt/rsync/ws7 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws7_log) /dev/mapper/Mirror-ws8 on /mnt/rsync/ws8 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws8_log) /dev/mapper/Mirror-ws9 on /mnt/rsync/ws9 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws9_log) /dev/mapper/Mirror-ws10 on /mnt/rsync/ws10 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws10_log) /dev/mapper/Mirror-ws11 on /mnt/rsync/ws11 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws11_log) /dev/mapper/Mirror-ws12 on /mnt/rsync/ws12 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws12_log) /dev/mapper/Mirror-ws13 on /mnt/rsync/ws13 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws13_log) /dev/mapper/Mirror-ws14 on /mnt/rsync/ws14 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws14_log) /dev/mapper/Mirror-ws15 on /mnt/rsync/ws15 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws15_log) /dev/mapper/Mirror-ws16 on /mnt/rsync/ws16 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws16_log) /dev/mapper/Mirror-ws17 on /mnt/rsync/ws17 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws17_log) /dev/mapper/Mirror-ws18 on /mnt/rsync/ws18 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws18_log) /dev/mapper/Mirror-ws19 on /mnt/rsync/ws19 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws19_log) /dev/mapper/Mirror-ws20 on /mnt/rsync/ws20 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws20_log) /dev/mapper/Mirror-ws21 on /mnt/rsync/ws21 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/ws21_log) /dev/mapper/Mirror-wsb1 on /mnt/rsync/wsb1 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/wsb1_log) /dev/mapper/Mirror-wsb2 on /mnt/rsync/wsb2 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/wsb2_log) /dev/mapper/Mirror-wsb3 on /mnt/rsync/wsb3 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/wsb3_log) /dev/mapper/Mirror-wsb4 on /mnt/rsync/wsb4 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/wsb4_log) /dev/mapper/Mirror-wsp1 on /mnt/rsync/wsp1 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/wsp1_log) /dev/mapper/Mirror-wsp2 on /mnt/rsync/wsp2 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/wsp2_log) /dev/mapper/Mirror-wsp3 on /mnt/rsync/wsp3 type xfs (rw,noatime,ihashsize=64433,logdev=/dev/Log/wsp3_log) /dev/mapper/Mirror-obr1 on /mnt/ob/obr1 type xfs (rw,noatime,ihashsize=64433) tmpfs on /dev type tmpfs (rw,size=10M,mode=0755) These filesystems vary in size from 50G to 3.5T The XFS filesystems contain rsync copies of filesystems on as many servers. The workload that triggers the problem is when all the servers start updating their copy via rsync - Then within a few hours the problem triggers. So to recreate the same scenario you'll want 28 servers doing rsync of filesystems of various sizes between 50G & 3.5T to a central server running 2.6.18-rc4 with 28 XFS filesystems. The XFS filesystems are on LVM and each physical volume is made up of two disks in a RAID1. > Something with > a bunch of renames in it, obviously, but I'd also like to be able to > reproduce locally with the exact data set (file names in particular), > if at all possible. > There are millions of files. The data the server recievs is copies of websites. Each server that sends data to the server with the 28 XFS filesystems hosts between 1800 and 2600 websites, so there are lots of files and every concievable strange filename. -- Jesper Juhl Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html From owner-xfs@oss.sgi.com Mon Aug 14 02:56:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Aug 2006 02:56:42 -0700 (PDT) Received: from dmz.tecosim.de (dmz.tecosim.com [195.135.152.162]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7E9uRDW005996 for ; Mon, 14 Aug 2006 02:56:27 -0700 Subject: Re: Negligible improvement when using su/sw for hardware RAID5, expected? From: utz lehmann To: Brian Davis Cc: xfs@oss.sgi.com In-Reply-To: <44DD46A5.7010308@comcast.net> References: <44DD46A5.7010308@comcast.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fuAbNIqoNHd6p7/e6F08" Organization: TECOSIM GmbH Date: Mon, 14 Aug 2006 10:51:34 +0200 Message-Id: <1155545494.1238.11.camel@donner.tecosim.de> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) X-Scanned-By: MIMEDefang 2.42 X-archive-position: 8656 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: u.lehmann@de.tecosim.com Precedence: bulk X-list: xfs Content-Length: 4321 Lines: 129 --=-fuAbNIqoNHd6p7/e6F08 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi You are using a partition. Is it correctly aligned? Usually the first partition starts at sector 63. Which is in the middle of your stripe. Use the whole disk (/dev/sda) or align the start of the partition to a multiple of the stripe size. But i doubt you will see a performance improvement with such a simple test (single threaded sequential read/ write). utz=20 On Fri, 2006-08-11 at 23:10 -0400, Brian Davis wrote: > Is this expected? I thought I would see more improvement when tweaking=20 > my su/sw values for hardware RAID 5. >=20 > Details, 3x300GB drives, 3Ware 7506-4LP Hardware RAID 5 using a 64K=20 > stripe size (non-configurable on this card). >=20 > FS creation and Bonnie++ results: >=20 > Untweaked:---------------------------------------------------------------= -------=20 >=20 >=20 > localhost / # mkfs.xfs -f /dev/sda1 > meta-data=3D/dev/sda1 isize=3D256 agcount=3D32, agsize=3D= 4578999=20 > blks > =3D sectsz=3D512 attr=3D0 > data =3D bsize=3D4096 blocks=3D146527968, ima= xpct=3D25 > =3D sunit=3D0 swidth=3D0 blks, unwritt= en=3D1 > naming =3Dversion 2 bsize=3D4096 > log =3Dinternal log bsize=3D4096 blocks=3D32768, version= =3D1 > =3D sectsz=3D512 sunit=3D0 blks > realtime =3Dnone extsz=3D65536 blocks=3D0, rtextents= =3D0 > localhost / # mount -t xfs /dev/sda1 /raid > localhost / # cd /raid > localhost raid # bonnie++ -n0 -u0 -r 768 -s 30720 -b -f > Using uid:0, gid:0. > Writing intelligently...done > Rewriting...done > Reading intelligently...done > start 'em...done...done...done...done...done... > Version 1.93c ------Sequential Output------ --Sequential Input-=20 > --Random- > Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--=20 > --Seeks-- > Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP=20= =20 > /sec %CP > localhost 30G 27722 40 23847 37 98367 99=20= =20 > 88.6 11 > Latency 891ms 693ms 16968us=20=20= =20=20=20 > 334ms >=20 > Tweaked:-----------------------------------------------------------------= --------=20 >=20 >=20 > localhost / # mkfs.xfs -f -d sw=3D2,su=3D64k /dev/sda1 > meta-data=3D/dev/sda1 isize=3D256 agcount=3D32, agsize=3D= 4578992=20 > blks > =3D sectsz=3D512 attr=3D0 > data =3D bsize=3D4096 blocks=3D146527744, ima= xpct=3D25 > =3D sunit=3D16 swidth=3D32 blks, unwrit= ten=3D1 > naming =3Dversion 2 bsize=3D4096 > log =3Dinternal log bsize=3D4096 blocks=3D32768, version= =3D1 > =3D sectsz=3D512 sunit=3D0 blks > realtime =3Dnone extsz=3D65536 blocks=3D0, rtextents= =3D0 > localhost / # mount -t xfs /dev/sda1 /raid > localhost / # cd /raid > localhost raid # bonnie++ -n0 -u0 -r 768 -s 30720 -b -f > Using uid:0, gid:0. > Writing intelligently...done > Rewriting...done > Reading intelligently...done > start 'em...done...done...done...done...done... > Version 1.93c ------Sequential Output------ --Sequential Input-=20 > --Random- > Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--=20 > --Seeks-- > Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP=20= =20 > /sec %CP > localhost 30G 27938 43 23880 40 98066 99=20= =20 > 91.8 9 > Latency 772ms 584ms 19889us=20=20= =20=20=20 > 340ms >=20 --=20 <> utz lehmann <> <> u.lehmann@de.tecosim.com <> <> <> TECOSIM GmbH / IT <> <> +49(0)-6142-82720 <> http://www.tecosim.com/ --=-fuAbNIqoNHd6p7/e6F08 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBE4DmW7OmPIkYy5+4RAsUpAKCAhrRtilHrKspv9qaSKCvKL6SwcQCfUig2 TGU7L3/8iIytRMflps/Ukoc= =txA+ -----END PGP SIGNATURE----- --=-fuAbNIqoNHd6p7/e6F08-- From owner-xfs@oss.sgi.com Mon Aug 14 07:18:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Aug 2006 07:18:37 -0700 (PDT) Received: from mx.wurtel.net (xs.wurtel.net [83.68.3.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7EEIODW007628 for ; Mon, 14 Aug 2006 07:18:26 -0700 Received: from wurtel ([192.168.1.1] helo=wurtel-ws.wurtel.net) by mx.wurtel.net with esmtp (Exim 3.36 #1 (Debian)) id 1GCdFz-0004w0-00 for ; Mon, 14 Aug 2006 16:17:31 +0200 Received: from paul by wurtel-ws.wurtel.net with local (Exim 4.62) (envelope-from ) id 1GCdFz-0008Uv-AR for xfs@oss.sgi.com; Mon, 14 Aug 2006 16:17:31 +0200 Date: Mon, 14 Aug 2006 16:17:31 +0200 From: Paul Slootman To: xfs@oss.sgi.com Subject: XFS internal error XFS_WANT_CORRUPTED_GOTO Message-ID: <20060814141731.GA9098@wurtel.net> References: <20060810164222.GA16332@wurtel.net> <200608110125.LAA18091@larry.melbourne.sgi.com> <20060811090218.GB22934@wurtel.net> <20060812091451.GA16661@wurtel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060812091451.GA16661@wurtel.net> User-Agent: Mutt/1.5.12-2006-07-14 X-Scanner: exiscan *1GCdFz-0004w0-00*w4oX4tFrbpg*Wurtel X-archive-position: 8657 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul@wurtel.net Precedence: bulk X-list: xfs Content-Length: 13514 Lines: 194 On Sat 12 Aug 2006, Paul Slootman wrote: > > I've now zapped that directory with xfs_db, and am running the (daily?!) > xfs_repair at this moment. As the filesystem is 1.1TB, it takes a couple > of hours :( That showed the following message in phase 3 because of the xfs_db action: imap claims a free inode 261 is in use, correcting imap and clearing inode and then in phase 4: entry "lost+found.x" at block 0 offset 584 in directory inode 256 references free inode 261 clearing inode number in entry at offset 584... and in phase 6: rebuilding directory inode 256 and phase 7: resetting inode 256 nlinks from 17 to 16 but nothing beyond that. However, that night: Aug 13 08:28:00 boes kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 874 of file fs/xfs/xfs_ialloc.c. Caller 0xffffffff8803be2f Aug 13 08:28:00 boes kernel: Aug 13 08:28:00 boes kernel: Call Trace: {:xfs:xfs_dialloc+1958} Aug 13 08:28:00 boes kernel: {:xfs:_xfs_buf_lookup_pages+711} {:xfs:xlog_state_get_iclog_space+56} Aug 13 08:28:00 boes kernel: {:xfs:xfs_ialloc+95} {:xfs:kmem_zone_alloc+91} Aug 13 08:28:00 boes kernel: {:xfs:xfs_dir_ialloc+134} {:xfs:xfs_log_reserve+195} Aug 13 08:28:00 boes kernel: {:xfs:xfs_mkdir+923} {:xfs:xfs_acl_get_attr+91} Aug 13 08:28:00 boes kernel: {:xfs:xfs_vn_mknod+465} {d_rehash+112} Aug 13 08:28:00 boes kernel: {__mutex_unlock_slowpath+415} {real_lookup+157} Aug 13 08:28:00 boes kernel: {_atomic_dec_and_lock+65} {mntput_no_expire+36} Aug 13 08:28:00 boes kernel: {__link_path_walk+3576} {__up_read+33} Aug 13 08:28:00 boes kernel: {:xfs:xfs_iunlock+102} {:xfs:xfs_access+74} Aug 13 08:28:00 boes kernel: {:xfs:xfs_vn_permission+20} {permission+104} Aug 13 08:28:00 boes kernel: {__link_path_walk+170} {:xfs:xfs_access+74} Aug 13 08:28:00 boes kernel: {vfs_mkdir+130} {sys_mkdirat+165} Aug 13 08:28:00 boes kernel: {system_call+126} Aug 13 08:28:00 boes kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 874 of file fs/xfs/xfs_ialloc.c. Caller 0xffffffff8803be2f Aug 13 08:28:00 boes kernel: Aug 13 08:28:00 boes kernel: Call Trace: {:xfs:xfs_dialloc+1958} Aug 13 08:28:00 boes kernel: {__generic_unplug_device+33} {kobject_release+0} Aug 13 08:28:00 boes kernel: {:xfs:xlog_state_get_iclog_space+56} Aug 13 08:28:00 boes kernel: {:xfs:xfs_ialloc+95} {:xfs:kmem_zone_alloc+91} Aug 13 08:28:00 boes kernel: {:xfs:xfs_dir_ialloc+134} {:xfs:xfs_log_reserve+195} Aug 13 08:28:00 boes kernel: {:xfs:xfs_mkdir+923} {:xfs:xfs_acl_get_attr+91} Aug 13 08:28:00 boes kernel: {:xfs:xfs_vn_mknod+465} {d_rehash+112} Aug 13 08:28:00 boes kernel: {__mutex_unlock_slowpath+415} {real_lookup+157} Aug 13 08:28:00 boes kernel: {_atomic_dec_and_lock+65} {mntput_no_expire+36} Aug 13 08:28:00 boes kernel: {__link_path_walk+3576} {__up_read+33} Aug 13 08:28:00 boes kernel: {:xfs:xfs_iunlock+102} {:xfs:xfs_access+74} Aug 13 08:28:00 boes kernel: {:xfs:xfs_vn_permission+20} {permission+104} Aug 13 08:28:00 boes kernel: {__link_path_walk+170} {:xfs:xfs_access+74} Aug 13 08:28:00 boes kernel: {vfs_mkdir+130} {sys_mkdirat+165} Aug 13 08:28:00 boes kernel: {system_call+126} Variations of this trace repeat a number of times, and then: Aug 13 08:31:09 boes kernel: xfs_force_shutdown(md6,0x8) called from line 1151 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff88065ba8 Aug 13 08:31:09 boes kernel: Filesystem "md6": Corruption of in-memory data detected. Shutting down filesystem: md6 Aug 13 08:31:09 boes kernel: Please umount the filesystem, and rectify the problem(s) The repair after this gave the following messages: Phase 3: correcting nblocks for inode 3080162495, was 2034 - counted 4 Phase 7: resetting inode 256 nlinks from 17 to 16 resetting inode 3080162495 nlinks from 1 to 10 That's all. Needless to say, the night after that repair it all went pear-shaped again: Aug 14 01:00:03 boes kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 874 of file fs/xfs/xfs_ialloc.c. Caller 0xffffffff8803be2f Aug 14 01:00:03 boes kernel: Aug 14 01:00:03 boes kernel: Call Trace: {:xfs:xfs_dialloc+1958} Aug 14 01:00:03 boes kernel: {:xfs:_xfs_buf_lookup_pages+711} {:xfs:xlog_state_get_iclog_space+56} Aug 14 01:00:03 boes kernel: {:xfs:xfs_ialloc+95} {:xfs:kmem_zone_alloc+91} Aug 14 01:00:03 boes kernel: {:xfs:xfs_dir_ialloc+134} {:xfs:xfs_log_reserve+195} Aug 14 01:00:03 boes kernel: {:xfs:xfs_mkdir+923} {:xfs:xfs_acl_get_attr+91} Aug 14 01:00:03 boes kernel: {:xfs:xfs_vn_mknod+465} {d_rehash+112} Aug 14 01:00:03 boes kernel: {__mutex_unlock_slowpath+415} {real_lookup+157} Aug 14 01:00:03 boes kernel: {_atomic_dec_and_lock+65} {mntput_no_expire+36} Aug 14 01:00:03 boes kernel: {__link_path_walk+3576} {__up_read+33} Aug 14 01:00:03 boes kernel: {:xfs:xfs_iunlock+102} {:xfs:xfs_access+74} Aug 14 01:00:03 boes kernel: {:xfs:xfs_vn_permission+20} {permission+104} Aug 14 01:00:03 boes kernel: {__link_path_walk+170} {:xfs:xfs_access+74} Aug 14 01:00:03 boes kernel: {vfs_mkdir+130} {sys_mkdirat+165} Aug 14 01:00:03 boes kernel: {system_call+126} Aug 14 01:00:03 boes kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 874 of file fs/xfs/xfs_ialloc.c. Caller 0xffffffff8803be2f Aug 14 01:00:03 boes kernel: Aug 14 01:00:03 boes kernel: Call Trace: {:xfs:xfs_dialloc+1958} Aug 14 01:00:03 boes kernel: {:xfs:xfs_ialloc+95} {:xfs:kmem_zone_alloc+91} Aug 14 01:00:03 boes kernel: {:xfs:xfs_dir_ialloc+134} {:xfs:xfs_log_reserve+195} Aug 14 01:00:03 boes kernel: {:xfs:xfs_mkdir+923} {:xfs:xfs_acl_get_attr+91} Aug 14 01:00:04 boes kernel: {:xfs:xfs_vn_mknod+465} {d_rehash+112} Aug 14 01:00:04 boes kernel: {__mutex_unlock_slowpath+415} {real_lookup+157} Aug 14 01:00:04 boes kernel: {_atomic_dec_and_lock+65} {mntput_no_expire+36} Aug 14 01:00:04 boes kernel: {__link_path_walk+3576} {__up_read+33} Aug 14 01:00:04 boes kernel: {:xfs:xfs_trans_unlocked_item+44} Aug 14 01:00:04 boes kernel: {:xfs:xfs_access+74} {:xfs:xfs_vn_permission+20} Aug 14 01:00:04 boes kernel: {permission+104} {__link_path_walk+170} Aug 14 01:00:04 boes kernel: {:xfs:xfs_access+74} {vfs_mkdir+130} Aug 14 01:00:04 boes kernel: {sys_mkdirat+165} {system_call+126} etc. I had umounted and mounted the filesystem after that. I tried removing a couple of junk directories at this point (probably a bad idea in retrospect) and when I tried to umount the directory again in preparation of the repair, the system stopped responding. The kernel was spewing these messages: Aug 14 12:23:45 boes kernel: BUG: soft lockup detected on CPU#0! Aug 14 12:23:45 boes kernel: Aug 14 12:23:45 boes kernel: Call Trace: {softlockup_tick+233} Aug 14 12:23:45 boes kernel: {update_process_times+80} {smp_local_timer_interrupt+35} Aug 14 12:23:45 boes kernel: {smp_apic_timer_interrupt+65} {apic_timer_interrupt+98} Aug 14 12:23:45 boes kernel: {:xfs:xfs_iextract+264} {debug_mutex_add_waiter+161} Aug 14 12:23:45 boes kernel: {:xfs:xfs_iflush_all+22} {__mutex_lock_slowpath+767} Aug 14 12:23:45 boes kernel: {__mutex_lock_slowpath+724} {:xfs:xfs_iflush_all+22} Aug 14 12:23:45 boes kernel: {:xfs:xfs_unmountfs+19} {:xfs:xfs_unmount+301} Aug 14 12:23:45 boes kernel: {:xfs:vfs_unmount+40} {:xfs:xfs_fs_put_super+50} Aug 14 12:23:45 boes kernel: {generic_shutdown_super+159} {kill_block_super+45} Aug 14 12:23:45 boes kernel: {deactivate_super+79} {sys_umount+137} Aug 14 12:23:45 boes kernel: {__up_write+34} {error_exit+0} Aug 14 12:23:45 boes kernel: {system_call+126} Aug 14 12:23:55 boes kernel: BUG: soft lockup detected on CPU#0! Aug 14 12:23:55 boes kernel: Aug 14 12:23:55 boes kernel: Call Trace: {softlockup_tick+233} Aug 14 12:23:55 boes kernel: {update_process_times+80} {smp_local_timer_interrupt+35} Aug 14 12:23:55 boes kernel: {smp_apic_timer_interrupt+65} {apic_timer_interrupt+98} Aug 14 12:23:56 boes kernel: {:xfs:xfs_iflush_all+22} {debug_mutex_add_waiter+161} Aug 14 12:23:56 boes kernel: {__mutex_lock_slowpath+767} {:xfs:xfs_iflush_all+81} Aug 14 12:23:56 boes kernel: {__mutex_unlock_slowpath+488} {:xfs:xfs_iflush_all+81} Aug 14 12:23:56 boes kernel: {:xfs:xfs_unmountfs+19} {:xfs:xfs_unmount+301} Aug 14 12:23:56 boes kernel: {:xfs:vfs_unmount+40} {:xfs:xfs_fs_put_super+50} Aug 14 12:23:56 boes kernel: {generic_shutdown_super+159} {kill_block_super+45} Aug 14 12:23:56 boes kernel: {deactivate_super+79} {sys_umount+137} Aug 14 12:23:56 boes kernel: {__up_write+34} {error_exit+0} Aug 14 12:23:56 boes kernel: {system_call+126} Dumping the locks held via magic-sysreq showed: Aug 14 12:26:46 boes kernel: #009: [ffff81013020d488] {alloc_super} Aug 14 12:26:46 boes kernel: .. held by: umount:18733 [ffff810154498340, 117] Aug 14 12:26:46 boes kernel: ... acquired at: generic_shutdown_super+0x63/0x150 kernel: 2.6.17.7 x86_64 xfstools: 2.8.11 from CVS last week I'm now running the "standard" debian xfs_repair (version 2.6.20) for kicks, as the 2.8.11 version didn't really seem to help much. I'm now getting plenty of these errors: entry "img-050806-090_onlin_81895f.jpg" at block 4 offset 2752 in directory inode 1343503044 references free inode 2511243327 clearing inode number in entry at offset 2752... entry "img-050806-090_onlin_81895f.jpg" at block 4 offset 2704 in directory inode 2160247870 references free inode 2511243327 clearing inode number in entry at offset 2704... entry "xbase-clients" at block 1 offset 1248 in directory inode 2457926717 references free inode 2511243327 clearing inode number in entry at offset 1248... entry "img-050806-090_onlin_81895f.jpg" at block 5 offset 592 in directory inode 2508332587 references free inode 2511243327 clearing inode number in entry at offset 592... Phase 6: rebuilding directory inode 256 rebuilding directory inode 1343503044 rebuilding directory inode 2508332587 rebuilding directory inode 2160247870 rebuilding directory inode 2457926717 Phase 7: resetting inode 256 nlinks from 17 to 16 resetting inode 2457926717 nlinks from 12 to 2 resetting inode 3080162495 nlinks from 1 to 10 Note the recurring them of "resetting inode 256 nlinks from 17 to 16". It seems like xfs_repair 2.8.11 doesn't, in fact, reset the nlinks. (Or it's the deletion and recreation of lost+found as 256 is the root dir, but that doesn't explain the other two inode nlinks.) Help! :-( Paul Slootman From owner-xfs@oss.sgi.com Mon Aug 14 07:31:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Aug 2006 07:31:40 -0700 (PDT) Received: from alnrmhc11.comcast.net (alnrmhc14.comcast.net [206.18.177.54]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7EEVUDW009282 for ; Mon, 14 Aug 2006 07:31:30 -0700 Received: from [10.86.242.184] (bxb-natpool-121.cisco.com[12.159.148.121]) by comcast.net (alnrmhc14) with ESMTP id <20060814132943b14006k93te>; Mon, 14 Aug 2006 13:29:43 +0000 Message-ID: <44E07AC6.6000104@comcast.net> Date: Mon, 14 Aug 2006 09:29:42 -0400 From: Brian Davis User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: utz lehmann CC: xfs@oss.sgi.com Subject: Re: Negligible improvement when using su/sw for hardware RAID5, expected? References: <44DD46A5.7010308@comcast.net> <1155545494.1238.11.camel@donner.tecosim.de> In-Reply-To: <1155545494.1238.11.camel@donner.tecosim.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8658 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bridavis@comcast.net Precedence: bulk X-list: xfs Content-Length: 3774 Lines: 96 I'll admit to being ignorant here....all I did was created the Linux partition with fdisk and then created the fs on top of that. Was there something else that needed to be done? Thanks, Brian utz lehmann wrote: > Hi > > You are using a partition. Is it correctly aligned? Usually the first > partition starts at sector 63. Which is in the middle of your stripe. > Use the whole disk (/dev/sda) or align the start of the partition to a > multiple of the stripe size. > But i doubt you will see a performance improvement with such a simple > test (single threaded sequential read/ write). > > > utz > > On Fri, 2006-08-11 at 23:10 -0400, Brian Davis wrote: > >> Is this expected? I thought I would see more improvement when tweaking >> my su/sw values for hardware RAID 5. >> >> Details, 3x300GB drives, 3Ware 7506-4LP Hardware RAID 5 using a 64K >> stripe size (non-configurable on this card). >> >> FS creation and Bonnie++ results: >> >> Untweaked:---------------------------------------------------------------------- >> >> >> localhost / # mkfs.xfs -f /dev/sda1 >> meta-data=/dev/sda1 isize=256 agcount=32, agsize=4578999 >> blks >> = sectsz=512 attr=0 >> data = bsize=4096 blocks=146527968, 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 >> localhost / # mount -t xfs /dev/sda1 /raid >> localhost / # cd /raid >> localhost raid # bonnie++ -n0 -u0 -r 768 -s 30720 -b -f >> Using uid:0, gid:0. >> Writing intelligently...done >> Rewriting...done >> Reading intelligently...done >> start 'em...done...done...done...done...done... >> Version 1.93c ------Sequential Output------ --Sequential Input- >> --Random- >> Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- >> --Seeks-- >> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP >> /sec %CP >> localhost 30G 27722 40 23847 37 98367 99 >> 88.6 11 >> Latency 891ms 693ms 16968us >> 334ms >> >> Tweaked:------------------------------------------------------------------------- >> >> >> localhost / # mkfs.xfs -f -d sw=2,su=64k /dev/sda1 >> meta-data=/dev/sda1 isize=256 agcount=32, agsize=4578992 >> blks >> = sectsz=512 attr=0 >> data = bsize=4096 blocks=146527744, imaxpct=25 >> = sunit=16 swidth=32 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 >> localhost / # mount -t xfs /dev/sda1 /raid >> localhost / # cd /raid >> localhost raid # bonnie++ -n0 -u0 -r 768 -s 30720 -b -f >> Using uid:0, gid:0. >> Writing intelligently...done >> Rewriting...done >> Reading intelligently...done >> start 'em...done...done...done...done...done... >> Version 1.93c ------Sequential Output------ --Sequential Input- >> --Random- >> Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- >> --Seeks-- >> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP >> /sec %CP >> localhost 30G 27938 43 23880 40 98066 99 >> 91.8 9 >> Latency 772ms 584ms 19889us >> 340ms >> >> From owner-xfs@oss.sgi.com Mon Aug 14 08:00:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Aug 2006 08:00:20 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7EExxDW011823 for ; Mon, 14 Aug 2006 08:00:05 -0700 Received: (qmail 81345 invoked from network); 14 Aug 2006 14:59:29 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 14 Aug 2006 14:59:29 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id E1062181DF3C; Mon, 14 Aug 2006 07:59:27 -0700 (PDT) Date: Mon, 14 Aug 2006 07:59:27 -0700 From: Chris Wedgwood To: Paul Slootman Cc: xfs@oss.sgi.com Subject: Re: cache_purge: shake on cache 0x5880a0 left 8 nodes!? Message-ID: <20060814145927.GA28940@tuatara.stupidest.org> References: <20060810164222.GA16332@wurtel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060810164222.GA16332@wurtel.net> X-archive-position: 8659 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 559 Lines: 12 On Thu, Aug 10, 2006 at 06:42:22PM +0200, Paul Slootman wrote: > empty data block 10 in directory inode 1343747104: junking block > empty data block 11 in directory inode 1343747104: junking block > empty data block 12 in directory inode 1343747104: junking block > free block 16777216 entry 10 for directory ino 1343747104 bad > rebuilding directory inode 1343747104 do subsequent xfs_repair runs go silent? if not then you've probably hit a case where it's leaving something icky behind and you have to manually poke it using xfs_db (i had this myself) From owner-xfs@oss.sgi.com Mon Aug 14 08:09:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Aug 2006 08:09:16 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7EF90DW013142 for ; Mon, 14 Aug 2006 08:09:03 -0700 Received: from [212.227.126.202] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1GCe3I-00022j-00; Mon, 14 Aug 2006 17:08:28 +0200 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1GCe3I-0006mP-01; Mon, 14 Aug 2006 17:08:28 +0200 Received: from mapibe17.exchange.xchg ([172.23.1.54]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Aug 2006 17:08:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Negligible improvement when using su/sw for hardware RAID5, expected? Date: Mon, 14 Aug 2006 17:08:24 +0200 Message-ID: <55EF1E5D5804A542A6CA37E446DDC206471F3D@mapibe17.exchange.xchg> In-Reply-To: <44E07AC6.6000104@comcast.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Negligible improvement when using su/sw for hardware RAID5, expected? thread-index: Aca/rllnheStVYHOR9yBQEMpY0h39wAAko4A From: "Sebastian Brings" To: "Brian Davis" , "utz lehmann" Cc: X-OriginalArrivalTime: 14 Aug 2006 15:08:27.0631 (UTC) FILETIME=[7EEF6FF0:01C6BFB3] X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.1.26 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k7EF93DW013152 X-archive-position: 8660 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sebas@silexmedia.com Precedence: bulk X-list: xfs Content-Length: 5228 Lines: 156 Unfortunately, yes. When you create a standard dos partition table on a disk, this takes some space. This shifts the beginning of your sda1 partition away from the very beginning of your harddisk by roughly 32k. When you now write the first 64K to you Raid, the first 32k go to disk1 (your first 64K stripe unit, which already holds the partition table), the next 32k go to disk 2 (your second stripe unit, which now is half "full"). Now your Raid controller needs to update the parity disk. It has half the data it would need from disk1, and half the data it would need from disk 2. An ugly situation. When using hardware raids, you should treat them as one single disk when calculating the sunit/swidth. Sunit matches the 2x64K = 128K of your Raid5, swidth then is 128K by . Together with a proper alignement as Utz mentioned, this allows the system to write a complete stripe at once, and hopefully makes it easier for the raidcontroller to calculate parity. > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] On Behalf Of > Brian Davis > Sent: Montag, 14. August 2006 15:30 > To: utz lehmann > Cc: xfs@oss.sgi.com > Subject: Re: Negligible improvement when using su/sw for hardware RAID5, > expected? > > I'll admit to being ignorant here....all I did was created the Linux > partition with fdisk and then created the fs on top of that. Was there > something else that needed to be done? > > Thanks, > Brian > > utz lehmann wrote: > > Hi > > > > You are using a partition. Is it correctly aligned? Usually the first > > partition starts at sector 63. Which is in the middle of your stripe. > > Use the whole disk (/dev/sda) or align the start of the partition to a > > multiple of the stripe size. > > But i doubt you will see a performance improvement with such a simple > > test (single threaded sequential read/ write). > > > > > > utz > > > > On Fri, 2006-08-11 at 23:10 -0400, Brian Davis wrote: > > > >> Is this expected? I thought I would see more improvement when tweaking > >> my su/sw values for hardware RAID 5. > >> > >> Details, 3x300GB drives, 3Ware 7506-4LP Hardware RAID 5 using a 64K > >> stripe size (non-configurable on this card). > >> > >> FS creation and Bonnie++ results: > >> > >> Untweaked:------------------------------------------------------------- > --------- > >> > >> > >> localhost / # mkfs.xfs -f /dev/sda1 > >> meta-data=/dev/sda1 isize=256 agcount=32, > agsize=4578999 > >> blks > >> = sectsz=512 attr=0 > >> data = bsize=4096 blocks=146527968, > 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 > >> localhost / # mount -t xfs /dev/sda1 /raid > >> localhost / # cd /raid > >> localhost raid # bonnie++ -n0 -u0 -r 768 -s 30720 -b -f > >> Using uid:0, gid:0. > >> Writing intelligently...done > >> Rewriting...done > >> Reading intelligently...done > >> start 'em...done...done...done...done...done... > >> Version 1.93c ------Sequential Output------ --Sequential Input- > >> --Random- > >> Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- > >> --Seeks-- > >> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP > >> /sec %CP > >> localhost 30G 27722 40 23847 37 98367 99 > >> 88.6 11 > >> Latency 891ms 693ms 16968us > >> 334ms > >> > >> Tweaked:--------------------------------------------------------------- > ---------- > >> > >> > >> localhost / # mkfs.xfs -f -d sw=2,su=64k /dev/sda1 > >> meta-data=/dev/sda1 isize=256 agcount=32, > agsize=4578992 > >> blks > >> = sectsz=512 attr=0 > >> data = bsize=4096 blocks=146527744, > imaxpct=25 > >> = sunit=16 swidth=32 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 > >> localhost / # mount -t xfs /dev/sda1 /raid > >> localhost / # cd /raid > >> localhost raid # bonnie++ -n0 -u0 -r 768 -s 30720 -b -f > >> Using uid:0, gid:0. > >> Writing intelligently...done > >> Rewriting...done > >> Reading intelligently...done > >> start 'em...done...done...done...done...done... > >> Version 1.93c ------Sequential Output------ --Sequential Input- > >> --Random- > >> Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- > >> --Seeks-- > >> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP > >> /sec %CP > >> localhost 30G 27938 43 23880 40 98066 99 > >> 91.8 9 > >> Latency 772ms 584ms 19889us > >> 340ms > >> > >> > From owner-xfs@oss.sgi.com Mon Aug 14 08:56:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Aug 2006 08:56:26 -0700 (PDT) Received: from mx.wurtel.net (xs.wurtel.net [83.68.3.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7EFuEDW032764 for ; Mon, 14 Aug 2006 08:56:14 -0700 Received: from wurtel ([192.168.1.1] helo=wurtel-ws.wurtel.net) by mx.wurtel.net with esmtp (Exim 3.36 #1 (Debian)) id 1GCemm-00079Z-00 for ; Mon, 14 Aug 2006 17:55:28 +0200 Received: from paul by wurtel-ws.wurtel.net with local (Exim 4.62) (envelope-from ) id 1GCeml-0002oi-Q7 for xfs@oss.sgi.com; Mon, 14 Aug 2006 17:55:27 +0200 Date: Mon, 14 Aug 2006 17:55:27 +0200 From: Paul Slootman To: xfs@oss.sgi.com Subject: Re: cache_purge: shake on cache 0x5880a0 left 8 nodes!? Message-ID: <20060814155527.GA10314@wurtel.net> References: <20060810164222.GA16332@wurtel.net> <20060814145927.GA28940@tuatara.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060814145927.GA28940@tuatara.stupidest.org> User-Agent: Mutt/1.5.12-2006-07-14 X-Scanner: exiscan *1GCemm-00079Z-00*.Pd9pu5VdK.*Wurtel X-archive-position: 8661 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul@wurtel.net Precedence: bulk X-list: xfs Content-Length: 780 Lines: 19 On Mon 14 Aug 2006, Chris Wedgwood wrote: > On Thu, Aug 10, 2006 at 06:42:22PM +0200, Paul Slootman wrote: > > > empty data block 10 in directory inode 1343747104: junking block > > empty data block 11 in directory inode 1343747104: junking block > > empty data block 12 in directory inode 1343747104: junking block > > free block 16777216 entry 10 for directory ino 1343747104 bad > > rebuilding directory inode 1343747104 > > do subsequent xfs_repair runs go silent? if not then you've probably > hit a case where it's leaving something icky behind and you have to > manually poke it using xfs_db (i had this myself) No, these particular messages didn't reoccur, although I've been having a lot of trouble with that filesystem (see my other message today). Paul Slootman From owner-xfs@oss.sgi.com Mon Aug 14 09:59:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Aug 2006 09:59:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7EGxIDW015781 for ; Mon, 14 Aug 2006 09:59:20 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7EG07Bm030031; Mon, 14 Aug 2006 12:00:07 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7EG07hf018172; Mon, 14 Aug 2006 12:00:07 -0400 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k7EG06KF023978; Mon, 14 Aug 2006 12:00:07 -0400 Message-ID: <44E09E06.9020400@sandeen.net> Date: Mon, 14 Aug 2006 11:00:06 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Nathan Scott CC: Jesper Juhl , xfs@oss.sgi.com Subject: Re: review: cleanup xfs_da_node_lookup_int (was Re: [PATCH] XFS: possibly uninitialized variable use in fs/xfs/xfs_da_btree.c::xfs_da_node_lookup_int()) References: <200608122334.21901.jesper.juhl@gmail.com> <44DE9B86.90006@sandeen.net> <20060814155609.G2698880@wobbly.melbourne.sgi.com> In-Reply-To: <20060814155609.G2698880@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8662 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 452 Lines: 16 Nathan Scott wrote: > On Sat, Aug 12, 2006 at 10:24:54PM -0500, Eric Sandeen wrote: >> ... >> FWIW seems like there's a lot of unnecessary endian flipping in there too; I >> haven't tested this but since it endian-flips the magic into blk->magic seems >> like it may as well use it: > > How's this look? Looks good to me. (now that I look closer & grok that there are 2 loops in that function and the break is in the nested one... oops!) -Eric From owner-xfs@oss.sgi.com Mon Aug 14 18:46:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Aug 2006 18:46:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7F1jmDW007048 for ; Mon, 14 Aug 2006 18:46:00 -0700 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA07105; Tue, 15 Aug 2006 11:45:01 +1000 Message-Id: <200608150145.LAA07105@larry.melbourne.sgi.com> From: "Barry Naujok" To: "'Paul Slootman'" , Subject: RE: cache_purge: shake on cache 0x5880a0 left 8 nodes!? Date: Tue, 15 Aug 2006 11:49:13 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Aca98CIvbHKSn6oeQtaTMATKxqusLACG7BAg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <20060812091451.GA16661@wurtel.net> X-archive-position: 8663 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1629 Lines: 62 Paul, Do you still have the filesystem with the undeletable directory? If so, can you run xfs_db and email me the contents of that directory? The commands would be: xfs_db> blockget -n xfs_db> ncheck lost+found.x lost+found.x/. xfs_db> inode xfs_db> p # if not a shortform directory, ie. the above does not output "u.sfdir2.etc", do the following sequence for all the blocks in the extent map, or at least offset 0 and 8388608 if they exist: xfs_db> dblock xfs_db> p With this output, I should be able to recreate a similar directory and test xfs_repair for problems. Thanks, Barry. > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Paul Slootman > Sent: Saturday, 12 August 2006 7:15 PM > To: xfs@oss.sgi.com > Subject: Re: cache_purge: shake on cache 0x5880a0 left 8 nodes!? > > On Fri 11 Aug 2006, Paul Slootman wrote: > > > > Unfortunately, the filesystem panicked again last night. > > This was after the double repair, and rebooting into 2.6.17.7, which > > shouldn't have the bug, right? > > I'll run another repair now :-( > > And again. > Curious fact appeared: the lost+found directory from the first time > (which I had moved to lost+found.x) could not be removed > "Directory not > empty". This would indicate that the CVS repair version (of 2 > days ago) > does not properly build the lost+found directory. > > I've now zapped that directory with xfs_db, and am running > the (daily?!) > xfs_repair at this moment. As the filesystem is 1.1TB, it > takes a couple > of hours :( > > > Paul Slootman > > From owner-xfs@oss.sgi.com Tue Aug 15 00:26:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 00:26:29 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7F7PuDW016510 for ; Tue, 15 Aug 2006 00:26:08 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA13903 for ; Tue, 15 Aug 2006 17:25:16 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id EEDC758C8A40; Tue, 15 Aug 2006 17:25:15 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.4.33. Message-Id: <20060815072515.EEDC758C8A40@chook.melbourne.sgi.com> Date: Tue, 15 Aug 2006 17:25:15 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8664 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 26458 Lines: 342 Date: Tue Aug 15 17:24:28 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: tes,chatz,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:26774a include/asm-sparc64/sfafsr.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/sfafsr.h include/asm-sparc64/const.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/const.h drivers/net/wireless/airo.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/airo.h CREDITS - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/CREDITS.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h Documentation/Changes - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Documentation/Changes.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h Documentation/Configure.help - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Documentation/Configure.help.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h Makefile - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/Makefile.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h README - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/README.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/alpha/kernel/pci_iommu.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/alpha/kernel/pci_iommu.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/i386/config.in - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/config.in.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/i386/kernel/dmi_scan.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/dmi_scan.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/i386/kernel/i387.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/i387.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/i386/kernel/io_apic.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/i386/kernel/io_apic.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/ia64/ia32/sys_ia32.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ia64/ia32/sys_ia32.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/parisc/kernel/ioctl32.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/parisc/kernel/ioctl32.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/parisc/kernel/sys_parisc32.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/parisc/kernel/sys_parisc32.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ppc64/kernel/ioctl32.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc64/kernel/ioctl32.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ppc64/kernel/signal.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc64/kernel/signal.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ppc64/kernel/sys_ppc32.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc64/kernel/sys_ppc32.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ppc64/lib/memcpy.S - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/ppc64/lib/memcpy.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/s390x/kernel/linux32.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/s390x/kernel/linux32.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/sparc/math-emu/math.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc/math-emu/math.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/entry.S - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/entry.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/irq.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/irq.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/pci_iommu.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/pci_iommu.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc64/kernel/process.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/process.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sparc64/kernel/sbus.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/sbus.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc64/kernel/smp.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/smp.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sparc64/kernel/sys_sparc32.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/sys_sparc32.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/sparc64/kernel/traps.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/traps.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/ttable.S - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/ttable.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/unaligned.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/unaligned.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc64/kernel/winfixup.S - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/kernel/winfixup.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/lib/debuglocks.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/sparc64/lib/debuglocks.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/x86_64/ia32/socket32.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/ia32/socket32.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/x86_64/kernel/process.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/kernel/process.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/x86_64/kernel/signal.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/arch/x86_64/kernel/signal.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/acpi/system.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/acpi/system.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/block/ll_rw_blk.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/block/ll_rw_blk.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/cdrom/cdrom.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/cdrom/cdrom.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/cdrom/sbpcd.c - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/cdrom/sbpcd.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/drm/drm_stub.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/drm/drm_stub.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/drm/radeon_mem.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/drm/radeon_mem.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/dummy_keyb.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/char/dummy_keyb.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/i2c/scx200_acb.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/i2c/scx200_acb.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ide/ide-dma.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/ide-dma.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ide/ide-io.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/ide-io.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ide/setup-pci.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/setup-pci.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/input/Config.in - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/input/Config.in.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/mtd/chips/amd_flash.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/mtd/chips/amd_flash.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/mtd/chips/cfi_cmdset_0001.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/mtd/chips/cfi_cmdset_0001.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/mtd/chips/cfi_cmdset_0002.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/mtd/chips/cfi_cmdset_0002.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/mtd/chips/cfi_cmdset_0020.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/mtd/chips/cfi_cmdset_0020.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/3c59x.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/3c59x.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/au1000_eth.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/au1000_eth.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/b44.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/b44.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/bonding/bond_alb.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/bonding/bond_alb.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/e1000/e1000_hw.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/e1000/e1000_hw.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/net/e1000/e1000_main.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/e1000/e1000_main.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/net/sis900.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/sis900.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/via-rhine.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/via-rhine.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/wan/sdla.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wan/sdla.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/wireless/airo.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/airo.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/wireless/airo_cs.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/airo_cs.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/wireless/hermes.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/hermes.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/wireless/hermes.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/hermes.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/wireless/orinoco.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/wireless/orinoco.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/aic7xxx/aic7xxx_osm.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/dpt_i2o.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/dpt_i2o.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/scsi_scan.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/scsi_scan.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/host/ehci-hcd.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/host/ehci-hcd.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/host/ehci-q.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/host/ehci-q.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/usb/host/usb-uhci.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/host/usb-uhci.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/usb/serial/usbserial.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/serial/usbserial.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/binfmt_elf.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/binfmt_elf.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h fs/dcache.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/dcache.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/ext2/namei.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/ext2/namei.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ext3/inode.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/ext3/inode.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/inode.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/inode.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/jbd/recovery.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/jbd/recovery.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/locks.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/locks.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/namei.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/namei.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h fs/nfs/inode.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/nfs/inode.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/nfsd/nfsctl.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/nfsd/nfsctl.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/partitions/msdos.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/partitions/msdos.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/proc/base.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/proc/base.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/quota_v2.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/quota_v2.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/smbfs/dir.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/smbfs/dir.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/smbfs/proc.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/fs/smbfs/proc.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-sparc64/atomic.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/atomic.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-sparc64/bitops.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/bitops.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-sparc64/softirq.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/softirq.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-sparc64/spinlock.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/spinlock.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-sparc64/system.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-sparc64/system.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-x86_64/i387.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/asm-x86_64/i387.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/i2c.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/i2c.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/linux/ide.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/ide.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/linux/nfs_fs_i.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/nfs_fs_i.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/pci_ids.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/pci_ids.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/linux/proc_fs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/proc_fs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/linux/sysctl.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/sysctl.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/net/sctp/sctp.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/net/sctp/sctp.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/scsi/scsi.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/scsi/scsi.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h init/main.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/init/main.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h ipc/shm.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/ipc/shm.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h kernel/kmod.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/kernel/kmod.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h kernel/panic.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/kernel/panic.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h kernel/ptrace.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/kernel/ptrace.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h kernel/sysctl.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/kernel/sysctl.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/8021q/vlan.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/8021q/vlan.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/core/ethtool.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/core/ethtool.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/core/neighbour.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/core/neighbour.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/ipv4/af_inet.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/af_inet.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv4/igmp.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/igmp.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/ipv4/netfilter/arp_tables.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/arp_tables.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv4/netfilter/ip_conntrack_core.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/ip_conntrack_core.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.3 - changed 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.3&r2=text&tr2=1.2&f=h net/ipv4/netfilter/ip_queue.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/ip_queue.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv4/netfilter/ip_tables.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/ip_tables.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/ipv4/netfilter/ipt_recent.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/netfilter/ipt_recent.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv4/route.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv4/route.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv6/ip6_flowlabel.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/ip6_flowlabel.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv6/mcast.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/mcast.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/ipv6/netfilter/ip6_queue.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/netfilter/ip6_queue.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv6/netfilter/ip6_tables.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/ipv6/netfilter/ip6_tables.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/sctp/sm_statefuns.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/sm_statefuns.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/sctp/sm_statetable.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/sm_statetable.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/sctp/ulpqueue.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/net/sctp/ulpqueue.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h scripts/ver_linux - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/scripts/ver_linux.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/forcedeth.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/net/forcedeth.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/ide/pci/atiixp.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/ide/pci/atiixp.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/xfs-modules - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/xfs-modules.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/series - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/series.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h split-patches/rwsem-backport - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/rwsem-backport.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h split-patches/kdb-i386 - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/kdb-i386.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h split-patches/kdb-common - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/kdb-common.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h split-patches/dmapi-enable - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/dmapi-enable.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h split-patches/acl-backport - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/acl-backport.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h split-patches/wait-call_usermodehelper - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/wait-call_usermodehelper.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/cache_defs - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/cache_defs.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h split-patches/docs-update2 - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/docs-update2.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h split-patches/downgrade_write-backport - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/downgrade_write-backport.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/sata_promise.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_promise.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/sata_promise.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_promise.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/sata_sil.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_sil.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/sata_sis.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_sis.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/sata_svw.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_svw.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/sata_sx4.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_sx4.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/libata.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/libata.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/libata-scsi.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/libata-scsi.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/libata-core.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/libata-core.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/sata_via.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_via.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/sata_vsc.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_vsc.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/usb/gadget/rndis.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/usb/gadget/rndis.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/linux/ata.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/ata.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/linux/libata.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/libata.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/sata_uli.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_uli.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/ata_piix.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/ata_piix.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/sata_nv.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_nv.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h split-patches/hash-backport - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/hash-backport.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/libata-compat.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/include/linux/libata-compat.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/ahci.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/ahci.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/sata_qstor.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/drivers/scsi/sata_qstor.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/pquota-enable - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/pquota-enable.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/quota-delalloc - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/quota-delalloc.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/xattr-backport - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/split-patches/xattr-backport.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-xfs@oss.sgi.com Tue Aug 15 02:04:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 02:05:12 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7F94ZDW031447 for ; Tue, 15 Aug 2006 02:04:46 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA15912; Tue, 15 Aug 2006 19:03:50 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7F93lgw2743649; Tue, 15 Aug 2006 19:03:47 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7F93h392742219; Tue, 15 Aug 2006 19:03:43 +1000 (EST) Date: Tue, 15 Aug 2006 19:03:43 +1000 From: Nathan Scott To: Jesper Juhl Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078 Message-ID: <20060815190343.A2743401@wobbly.melbourne.sgi.com> References: <9a8748490608080137k596a6290r3567096668449a64@mail.gmail.com> <20060808185405.B2528231@wobbly.melbourne.sgi.com> <9a8748490608100431m244207b1v9c9c5087233fcf3a@mail.gmail.com> <20060811083546.B2596458@wobbly.melbourne.sgi.com> <9a8748490608101544n29f863e7o7584ac64f1d4c210@mail.gmail.com> <9a8748490608101552w12822fa6m415a5fb5537c744d@mail.gmail.com> <9a8748490608110133v5f973cf6w1af340f59bb229ec@mail.gmail.com> <9a8748490608110325k25c340e2yac925eb226d1fe4f@mail.gmail.com> <20060814120032.E2698880@wobbly.melbourne.sgi.com> <9a8748490608140049t492742cx7f826a9f40835d71@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9a8748490608140049t492742cx7f826a9f40835d71@mail.gmail.com>; from jesper.juhl@gmail.com on Mon, Aug 14, 2006 at 09:49:10AM +0200 X-archive-position: 8666 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1775 Lines: 43 On Mon, Aug 14, 2006 at 09:49:10AM +0200, Jesper Juhl wrote: > On 14/08/06, Nathan Scott wrote: > > > LEAFN node level is 1 inode 412035424 bno = 8388608 > > > > Ooh. Can you describe this test case you're using? > ... > These filesystems vary in size from 50G to 3.5T > > The XFS filesystems contain rsync copies of filesystems on as many servers. > The workload that triggers the problem is when all the servers start > updating their copy via rsync - Then within a few hours the problem > triggers. > > So to recreate the same scenario you'll want 28 servers doing rsync of > filesystems of various sizes between 50G & 3.5T to a central server > running 2.6.18-rc4 with 28 XFS filesystems. > ... > There are millions of files. The data the server recievs is copies of > websites. Each server that sends data to the server with the 28 XFS > filesystems hosts between 1800 and 2600 websites, so there are lots of > files and every concievable strange filename. Wow, a special kind of hell for a filesystem developer...! ;-) Its not clear to me where the rename operation happens in all of this - does rsync create a local, temporary copy of the file and then rename it? Is it that central server going down or one of those 28 other server machines? (I assume it is, I can't see an opportunity for renaming out there...). When you hit it again, could you grab the contents of the inode (you'll get that from xfs_repair -n, e.g. 412035424 above) with xfs_db (see last entry in the XFS FAQ which describes how to do that), then mail that to me please? If you can get the source and target names in the rename that'll help alot too... I can explain how to use KDB to get that, but maybe you have another debugger handy already? thanks! -- Nathan From owner-xfs@oss.sgi.com Tue Aug 15 04:43:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 04:43:23 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7FBgwDW004119 for ; Tue, 15 Aug 2006 04:43:00 -0700 Received: by nf-out-0910.google.com with SMTP id p46so301611nfa for ; Tue, 15 Aug 2006 04:42:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KdjBohtkCs50dRtlHHkx4xnI2+Znc5UNRohDQfNFu7sQxol/ju2W4yX8fHhSDNDJXidNqRnYiaGQx0KFpcf3fALHaM+aNyArNM+/+GP2OvJVr63G8woUankKW5BH+1nRFmgKIxLbs4v98tTbvvjU1cWcTtwPWiDID6pvVIjxyjA= Received: by 10.49.41.12 with SMTP id t12mr1174521nfj; Tue, 15 Aug 2006 04:42:27 -0700 (PDT) Received: by 10.78.161.18 with HTTP; Tue, 15 Aug 2006 04:42:27 -0700 (PDT) Message-ID: <9a8748490608150442q4ad7a835r53400e9880da3175@mail.gmail.com> Date: Tue, 15 Aug 2006 13:42:27 +0200 From: "Jesper Juhl" To: "Nathan Scott" Subject: Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078 Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20060815190343.A2743401@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9a8748490608080137k596a6290r3567096668449a64@mail.gmail.com> <9a8748490608100431m244207b1v9c9c5087233fcf3a@mail.gmail.com> <20060811083546.B2596458@wobbly.melbourne.sgi.com> <9a8748490608101544n29f863e7o7584ac64f1d4c210@mail.gmail.com> <9a8748490608101552w12822fa6m415a5fb5537c744d@mail.gmail.com> <9a8748490608110133v5f973cf6w1af340f59bb229ec@mail.gmail.com> <9a8748490608110325k25c340e2yac925eb226d1fe4f@mail.gmail.com> <20060814120032.E2698880@wobbly.melbourne.sgi.com> <9a8748490608140049t492742cx7f826a9f40835d71@mail.gmail.com> <20060815190343.A2743401@wobbly.melbourne.sgi.com> X-archive-position: 8667 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jesper.juhl@gmail.com Precedence: bulk X-list: xfs Content-Length: 2390 Lines: 60 On 15/08/06, Nathan Scott wrote: > On Mon, Aug 14, 2006 at 09:49:10AM +0200, Jesper Juhl wrote: > > On 14/08/06, Nathan Scott wrote: > > > > LEAFN node level is 1 inode 412035424 bno = 8388608 > > > > > > Ooh. Can you describe this test case you're using? > > ... > > These filesystems vary in size from 50G to 3.5T > > > > The XFS filesystems contain rsync copies of filesystems on as many servers. > > The workload that triggers the problem is when all the servers start > > updating their copy via rsync - Then within a few hours the problem > > triggers. > > > > So to recreate the same scenario you'll want 28 servers doing rsync of > > filesystems of various sizes between 50G & 3.5T to a central server > > running 2.6.18-rc4 with 28 XFS filesystems. > > ... > > There are millions of files. The data the server recievs is copies of > > websites. Each server that sends data to the server with the 28 XFS > > filesystems hosts between 1800 and 2600 websites, so there are lots of > > files and every concievable strange filename. > > Wow, a special kind of hell for a filesystem developer...! ;-) > > Its not clear to me where the rename operation happens in all of > this - does rsync create a local, temporary copy of the file and > then rename it? I'm not sure. I'll investigate and see if I can work out what exactely rsync does. > Is it that central server going down or one of > those 28 other server machines? (I assume it is, I can't see an > opportunity for renaming out there...). > It's the central server with all the xfs filesystems that dies. The one recieving all the rsync data. > When you hit it again, could you grab the contents of the inode > (you'll get that from xfs_repair -n, e.g. 412035424 above) with > xfs_db (see last entry in the XFS FAQ which describes how to do > that), then mail that to me please? Sure, I'll read up on that and make sure to grab that info next time. > If you can get the source > and target names in the rename that'll help alot too... I can > explain how to use KDB to get that, but maybe you have another > debugger handy already? > An explanation of how exactely to do that would be greatly appreciated. -- Jesper Juhl Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html From owner-xfs@oss.sgi.com Tue Aug 15 04:55:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 04:55:49 -0700 (PDT) Received: from mx.wurtel.net (xs.wurtel.net [83.68.3.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7FBtYDW006683 for ; Tue, 15 Aug 2006 04:55:39 -0700 Received: from wurtel ([192.168.1.1] helo=wurtel-ws.wurtel.net) by mx.wurtel.net with esmtp (Exim 3.36 #1 (Debian)) id 1GCxVK-00086K-00 for ; Tue, 15 Aug 2006 13:54:42 +0200 Received: from paul by wurtel-ws.wurtel.net with local (Exim 4.62) (envelope-from ) id 1GCxVK-0002PP-FZ for xfs@oss.sgi.com; Tue, 15 Aug 2006 13:54:42 +0200 Date: Tue, 15 Aug 2006 13:54:42 +0200 From: Paul Slootman To: xfs@oss.sgi.com Subject: Re: XFS internal error XFS_WANT_CORRUPTED_GOTO Message-ID: <20060815115442.GA9248@wurtel.net> References: <20060810164222.GA16332@wurtel.net> <200608110125.LAA18091@larry.melbourne.sgi.com> <20060811090218.GB22934@wurtel.net> <20060812091451.GA16661@wurtel.net> <20060814141731.GA9098@wurtel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060814141731.GA9098@wurtel.net> User-Agent: Mutt/1.5.12-2006-07-14 X-Scanner: exiscan *1GCxVK-00086K-00*Tm5JJTlhLgc*Wurtel X-archive-position: 8668 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul@wurtel.net Precedence: bulk X-list: xfs Content-Length: 2153 Lines: 37 On Mon 14 Aug 2006, Paul Slootman wrote: > > kernel: 2.6.17.7 x86_64 > xfstools: 2.8.11 from CVS last week > > I'm now running the "standard" debian xfs_repair (version 2.6.20) for kicks, > as the 2.8.11 version didn't really seem to help much. I'm now getting > plenty of these errors: [snip] After all that, again, tonight: Aug 15 01:11:57 boes kernel: Filesystem "md6": XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c. Caller 0xffffffff880577d3 Aug 15 01:11:57 boes kernel: Aug 15 01:11:57 boes kernel: Call Trace: {:xfs:xfs_trans_cancel+96} Aug 15 01:11:57 boes kernel: {:xfs:xfs_create+1587} {:xfs:xfs_vn_mknod+433} Aug 15 01:11:57 boes kernel: {:xfs:xfs_trans_unlocked_item+44} Aug 15 01:11:57 boes kernel: {:xfs:xfs_buf_rele+62} {:xfs:xfs_da_brelse+129} Aug 15 01:11:57 boes kernel: {:xfs:xfs_dir2_leaf_lookup_int+555} Aug 15 01:11:57 boes kernel: {:xfs:xfs_dir2_leaf_lookup+35} {:xfs:xfs_dir2_isleaf+31} Aug 15 01:11:57 boes kernel: {:xfs:xfs_dir2_lookup+255} {link_path_walk+415} Aug 15 01:11:57 boes kernel: {:xfs:xfs_access+74} {vfs_create+142} Aug 15 01:11:57 boes kernel: {open_namei+383} {do_filp_open+39} Aug 15 01:11:57 boes kernel: {get_unused_fd+113} {do_sys_open+70} Aug 15 01:11:57 boes kernel: {system_call+126} Aug 15 01:11:57 boes kernel: xfs_force_shutdown(md6,0x8) called from line 1151 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff88065ba8 Aug 15 01:11:57 boes kernel: Filesystem "md6": Corruption of in-memory data detected. Shutting down filesystem: md6 Aug 15 01:11:57 boes kernel: Please umount the filesystem, and rectify the problem(s) The only thing the (2.8.11) xfs_repair reported was, in phase 3: data fork in ino 2995825682 claims free block 251664817 Paul Slootman From owner-xfs@oss.sgi.com Tue Aug 15 04:56:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 04:57:12 -0700 (PDT) Received: from mx.wurtel.net (xs.wurtel.net [83.68.3.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7FBuoDW007003 for ; Tue, 15 Aug 2006 04:56:52 -0700 Received: from wurtel ([192.168.1.1] helo=wurtel-ws.wurtel.net) by mx.wurtel.net with esmtp (Exim 3.36 #1 (Debian)) id 1GCxWO-0008Cu-00; Tue, 15 Aug 2006 13:55:48 +0200 Received: from paul by wurtel-ws.wurtel.net with local (Exim 4.62) (envelope-from ) id 1GCxWN-0002Xn-Lf; Tue, 15 Aug 2006 13:55:47 +0200 Date: Tue, 15 Aug 2006 13:55:47 +0200 From: Paul Slootman To: Barry Naujok Cc: xfs@oss.sgi.com Subject: Re: cache_purge: shake on cache 0x5880a0 left 8 nodes!? Message-ID: <20060815115547.GB9248@wurtel.net> References: <20060812091451.GA16661@wurtel.net> <200608150145.LAA07105@larry.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608150145.LAA07105@larry.melbourne.sgi.com> User-Agent: Mutt/1.5.12-2006-07-14 X-Scanner: exiscan *1GCxWO-0008Cu-00*BLx.HIapdVg*Wurtel X-archive-position: 8669 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul@wurtel.net Precedence: bulk X-list: xfs Content-Length: 247 Lines: 12 On Tue 15 Aug 2006, Barry Naujok wrote: > > Do you still have the filesystem with the undeletable directory? No, as I wrote, I zapped it with xfs_db and the subsequent xfs_repair cleaned it up. Thanks for your concern however. Paul Slootman From owner-xfs@oss.sgi.com Tue Aug 15 07:20:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 07:20:29 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7FEK1DW006505 for ; Tue, 15 Aug 2006 07:20:14 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k7FDL4nx020589 for ; Tue, 15 Aug 2006 08:21:04 -0500 Received: from [128.162.233.24] (fsgi275.americas.sgi.com [128.162.233.24]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k7FDKg8s29995159; Tue, 15 Aug 2006 06:20:42 -0700 (PDT) Message-ID: <44E1CA29.7080406@sgi.com> Date: Tue, 15 Aug 2006 08:20:41 -0500 From: Bill Kendall User-Agent: Mail/News 1.5 (X11/20060228) MIME-Version: 1.0 To: juergen.sauer@automatix.de CC: linux-xfs@oss.sgi.com Subject: Re: Bug in xfsrestore or NFS+XFS Filesystem on NFS Server ? Can anyone confirm ? References: <200608120956.47466.juergen.sauer@automatix.de> In-Reply-To: <200608120956.47466.juergen.sauer@automatix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8670 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 714 Lines: 15 On 08/12/06 02:56, Juergen Sauer wrote: > Since that the last restore works, I think there is a bug in xfsrestore or xfs/nfs in the kernel 2.6.17. > Backupserver, Server, Knoppix are bugfixed 2.6.17(.7). Restoring the dump via nfs failed due "too much open files". > > Does xfsrestore opens really 512k files ? I do not belive that. > So It could a problem in Kernel or NFS Stack be the problem. Not intentionally, but there could be a file descriptor leak somewhere in xfsrestore or one of the libraries it uses. Take a look at /proc//fd while the restore is going on and see if the file descriptor list is growing. If so, it should indicate what files are being opened but not closed. Bill From owner-xfs@oss.sgi.com Tue Aug 15 07:37:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 07:38:07 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7FEbeDW011399 for ; Tue, 15 Aug 2006 07:37:40 -0700 Received: (qmail 76397 invoked from network); 15 Aug 2006 14:37:11 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 15 Aug 2006 14:37:11 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 5A103181DF3C; Tue, 15 Aug 2006 07:37:09 -0700 (PDT) Date: Tue, 15 Aug 2006 07:37:09 -0700 From: Chris Wedgwood To: Nathan Scott Cc: Jesper Juhl , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078 Message-ID: <20060815143709.GA21591@tuatara.stupidest.org> References: <20060808185405.B2528231@wobbly.melbourne.sgi.com> <9a8748490608100431m244207b1v9c9c5087233fcf3a@mail.gmail.com> <20060811083546.B2596458@wobbly.melbourne.sgi.com> <9a8748490608101544n29f863e7o7584ac64f1d4c210@mail.gmail.com> <9a8748490608101552w12822fa6m415a5fb5537c744d@mail.gmail.com> <9a8748490608110133v5f973cf6w1af340f59bb229ec@mail.gmail.com> <9a8748490608110325k25c340e2yac925eb226d1fe4f@mail.gmail.com> <20060814120032.E2698880@wobbly.melbourne.sgi.com> <9a8748490608140049t492742cx7f826a9f40835d71@mail.gmail.com> <20060815190343.A2743401@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060815190343.A2743401@wobbly.melbourne.sgi.com> X-archive-position: 8671 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 258 Lines: 8 On Tue, Aug 15, 2006 at 07:03:43PM +1000, Nathan Scott wrote: > Its not clear to me where the rename operation happens in all of > this - does rsync create a local, temporary copy of the file and > then rename it? Yes, this is normally how rsync does it. From owner-xfs@oss.sgi.com Tue Aug 15 07:51:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 07:52:11 -0700 (PDT) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7FEpfDW015101 for ; Tue, 15 Aug 2006 07:51:42 -0700 Received: from linux01.gwdg.de ([134.76.13.21]) by mailer.gwdg.de with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60) (envelope-from ) id 1GD0FP-00046s-Q1; Tue, 15 Aug 2006 16:50:29 +0200 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k7FElvv8019999; Tue, 15 Aug 2006 16:47:59 +0200 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k7FElulm019888; Tue, 15 Aug 2006 16:47:57 +0200 Date: Tue, 15 Aug 2006 16:47:56 +0200 (MEST) From: Jan Engelhardt To: Chris Wedgwood cc: Nathan Scott , Jesper Juhl , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078 In-Reply-To: <20060815143709.GA21591@tuatara.stupidest.org> Message-ID: References: <20060808185405.B2528231@wobbly.melbourne.sgi.com> <9a8748490608100431m244207b1v9c9c5087233fcf3a@mail.gmail.com> <20060811083546.B2596458@wobbly.melbourne.sgi.com> <9a8748490608101544n29f863e7o7584ac64f1d4c210@mail.gmail.com> <9a8748490608101552w12822fa6m415a5fb5537c744d@mail.gmail.com> <9a8748490608110133v5f973cf6w1af340f59bb229ec@mail.gmail.com> <9a8748490608110325k25c340e2yac925eb226d1fe4f@mail.gmail.com> <20060814120032.E2698880@wobbly.melbourne.sgi.com> <9a8748490608140049t492742cx7f826a9f40835d71@mail.gmail.com> <20060815190343.A2743401@wobbly.melbourne.sgi.com> <20060815143709.GA21591@tuatara.stupidest.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 8672 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: xfs Content-Length: 461 Lines: 25 >> Its not clear to me where the rename operation happens in all of >> this - does rsync create a local, temporary copy of the file and >> then rename it? > >Yes, this is normally how rsync does it. If file already exists { foreach block { copy block either from disk or from the source operand, whichever is never, to temp file } } When rsync catches a signal { move the tempfile to the original name } Jan Engelhardt -- From owner-xfs@oss.sgi.com Tue Aug 15 15:14:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 15:15:08 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7FMEtDW004688 for ; Tue, 15 Aug 2006 15:14:55 -0700 Received: by py-out-1112.google.com with SMTP id c39so1947965pyd for ; Tue, 15 Aug 2006 15:14:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JdzSAoWuO4etMgwGkFECtaDVHZ97oDO9+mEHS7Wcxkq/8k4VN0Xw4LoQRW3mvxyrDI2iv/MLatknFY9adDB4WvZiziDUrOho94P3O1cATWwsvP0JXgxhLmWfvzafn+/Ag1QsA6EU+lbMVXxoX/tXXsD2hq4ztlNwAOMFLCAj8eU= Received: by 10.35.127.7 with SMTP id e7mr16391939pyn; Tue, 15 Aug 2006 15:14:24 -0700 (PDT) Received: by 10.35.73.13 with HTTP; Tue, 15 Aug 2006 15:14:23 -0700 (PDT) Message-ID: <83d59530608151514m288edcf1te3268b413b94dd2a@mail.gmail.com> Date: Tue, 15 Aug 2006 23:14:23 +0100 From: "Jeff Briggs" To: "Russell Cattelan" Subject: Re: XFS null files Cc: xfs@oss.sgi.com In-Reply-To: <44D66BBF.8010107@thebarn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <83d59530608061232r21feab01j456c7d1fec742958@mail.gmail.com> <44D66BBF.8010107@thebarn.com> X-archive-position: 8673 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ephemeral.elusive@gmail.com Precedence: bulk X-list: xfs Content-Length: 1006 Lines: 25 On 06/08/06, Russell Cattelan wrote: > Check to see if you have this change > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=1.675;r2=1.676;f=h > > I helps reduce the null file problem. i do not. > > emacs claims to fsync on write, yet still I lost data, the faq > > suggests I should not have if this is so? > > > > Is this likely to be fixed soon, or should I switch file system? > > Any caching file system could potentially loose data, XFS just happens to > get the file size correct so you end up with a file that is nothing but a > hole. Other file system would probably just give you an empty file. > Either way data in cache always has the potential for being lost. > Running xfs in full sync mode would be safest but you loose many performance > advantages... so it always a trade off of performance vs data integrity. it's really ugly how the default is not safe. i didn't have my write cache disabled, but it is now. thanks for the responses. From owner-xfs@oss.sgi.com Tue Aug 15 17:12:31 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 17:13:02 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7G0CIDW026231 for ; Tue, 15 Aug 2006 17:12:30 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06633; Wed, 16 Aug 2006 10:11:29 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7G0BPgw2751355; Wed, 16 Aug 2006 10:11:26 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7G0BMTp2761774; Wed, 16 Aug 2006 10:11:22 +1000 (EST) Date: Wed, 16 Aug 2006 10:11:22 +1000 From: Nathan Scott To: Martin Braun Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: kernel BUG at :50307! Message-ID: <20060816101122.E2740551@wobbly.melbourne.sgi.com> References: <44E1D9CA.30805@uni-hd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44E1D9CA.30805@uni-hd.de>; from mbraun@uni-hd.de on Tue, Aug 15, 2006 at 04:27:22PM +0200 X-archive-position: 8674 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 971 Lines: 29 Hi Martin, On Tue, Aug 15, 2006 at 04:27:22PM +0200, Martin Braun wrote: > ... > What does this bug mean? > ... > Aug 15 15:01:02 pers109 kernel: Access to block zero: fs: inode: > 254474718 start_block : 0 start_off : c0a0b0e8a099 > 0 blkcnt : 90000 extent-state : 0 > Aug 15 15:01:02 pers109 kernel: ------------[ cut here ]------------ > Aug 15 15:01:02 pers109 kernel: kernel BUG at :50307! It means XFS detected ondisk corruption in inode# 254474718, and paniced your system (stupidly; a fix for this is around, will be merged with the next mainline update). For me, a more interesting question is how that inode got into this state... have you had any crashes recently (i.e. has the filesystem journal needed to be replayed recently?) Can you send the output of: # xfs_db -c 'inode 254474718' -c print /dev/sdc1 You'll need to run xfs_repair on that filesystem to fix this up, but please send us that output first. thanks. -- Nathan From owner-xfs@oss.sgi.com Tue Aug 15 17:23:46 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 17:24:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7G0NXDW028372 for ; Tue, 15 Aug 2006 17:23:44 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06941; Wed, 16 Aug 2006 10:22:39 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7G0MWgw2761497; Wed, 16 Aug 2006 10:22:34 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7G0MO8x2755707; Wed, 16 Aug 2006 10:22:24 +1000 (EST) Date: Wed, 16 Aug 2006 10:22:24 +1000 From: Nathan Scott To: David Howells Cc: torvalds@osdl.org, akpm@osdl.org, trond.myklebust@fys.uio.no, aviro@redhat.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, nfsv4@linux-nfs.org, xfs@oss.sgi.com Subject: Re: [PATCH 0/2] Use 64-bit inode numbers internally in the kernel [try #2] Message-ID: <20060816102224.F2740551@wobbly.melbourne.sgi.com> References: <20060815152627.29222.71414.stgit@warthog.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060815152627.29222.71414.stgit@warthog.cambridge.redhat.com>; from dhowells@redhat.com on Tue, Aug 15, 2006 at 04:26:27PM +0100 X-archive-position: 8675 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 779 Lines: 19 On Tue, Aug 15, 2006 at 04:26:27PM +0100, David Howells wrote: > > These patches make the kernel pass 64-bit inode numbers internally when > communicating to userspace, even on a 32-bit system. They are required > because some filesystems have intrinsic 64-bit inode numbers: NFS3+ and XFS > for example. The 64-bit inode numbers are then propagated to userspace > automatically where the arch supports it. Thanks for doing this, David. FWIW, for XFS its not directly a problem today, we simply block attempts to mount filesystems on 32 bit systems where the inums could get into the problematic ranges. With several XFS changes (main change will be switching to use iget5_locked) we will be able to allow those mounts to go ahead - so, thanks again! cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Aug 15 18:27:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 18:28:01 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7G1RODW003384 for ; Tue, 15 Aug 2006 18:27:35 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08524; Wed, 16 Aug 2006 11:26:37 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7G1QYgw2741470; Wed, 16 Aug 2006 11:26:35 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7G1QVRW2763337; Wed, 16 Aug 2006 11:26:31 +1000 (EST) Date: Wed, 16 Aug 2006 11:26:30 +1000 From: Nathan Scott To: Jesper Juhl Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078 Message-ID: <20060816112630.C2756824@wobbly.melbourne.sgi.com> References: <9a8748490608100431m244207b1v9c9c5087233fcf3a@mail.gmail.com> <20060811083546.B2596458@wobbly.melbourne.sgi.com> <9a8748490608101544n29f863e7o7584ac64f1d4c210@mail.gmail.com> <9a8748490608101552w12822fa6m415a5fb5537c744d@mail.gmail.com> <9a8748490608110133v5f973cf6w1af340f59bb229ec@mail.gmail.com> <9a8748490608110325k25c340e2yac925eb226d1fe4f@mail.gmail.com> <20060814120032.E2698880@wobbly.melbourne.sgi.com> <9a8748490608140049t492742cx7f826a9f40835d71@mail.gmail.com> <20060815190343.A2743401@wobbly.melbourne.sgi.com> <9a8748490608150442q4ad7a835r53400e9880da3175@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9a8748490608150442q4ad7a835r53400e9880da3175@mail.gmail.com>; from jesper.juhl@gmail.com on Tue, Aug 15, 2006 at 01:42:27PM +0200 X-archive-position: 8676 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 631 Lines: 22 On Tue, Aug 15, 2006 at 01:42:27PM +0200, Jesper Juhl wrote: > On 15/08/06, Nathan Scott wrote: > > If you can get the source > > and target names in the rename that'll help alot too... I can > > explain how to use KDB to get that, but maybe you have another > > debugger handy already? > > > An explanation of how exactely to do that would be greatly appreciated. - patch in KDB - echo 127 > /proc/sys/fs/xfs/panic_mask [ filesystem shutdown now == panic ] - kdb> bt [ pick out parameters to rename from the backtrace ] - kdb> md 0xXXX [ gives a memory dump of the pointers to pathnames ] cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Aug 15 21:30:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 21:30:39 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7G4TpDW007339 for ; Tue, 15 Aug 2006 21:30:03 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12626; Wed, 16 Aug 2006 14:28:05 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7G4S3gw2763373; Wed, 16 Aug 2006 14:28:03 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7G4S1DE2764072; Wed, 16 Aug 2006 14:28:01 +1000 (EST) Date: Wed, 16 Aug 2006 14:28:01 +1000 From: Nathan Scott To: David Chinner Cc: xfs@oss.sgi.com Subject: Re: review: fsblock zero - don't panic Message-ID: <20060816142800.D2762042@wobbly.melbourne.sgi.com> References: <20060810155851.C2591606@wobbly.melbourne.sgi.com> <20060811032626.GF50254148@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060811032626.GF50254148@melbourne.sgi.com>; from dgc@sgi.com on Fri, Aug 11, 2006 at 01:26:26PM +1000 X-archive-position: 8677 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 9859 Lines: 266 On Fri, Aug 11, 2006 at 01:26:26PM +1000, David Chinner wrote: > ... > Looks OK. Thanks mate. > ... > If you are hinting this branch to be unlikely, then we should also > check the start block first before checking the io_flags. We only > need to check the io_flags if we are actually accessing block zero. I've rolled this into a new version. I also got prodded to still provide an option to panic on detecting this, for debugging - so I rewrote this to report through the panic_mask mechanism, which now gives us the option to optionally panic if need be... could you do a second pass over this for me? cheers. -- Nathan Index: xfs-linux/xfs_bmap.c =================================================================== --- xfs-linux.orig/xfs_bmap.c 2006-08-15 15:22:53.198187750 +1000 +++ xfs-linux/xfs_bmap.c 2006-08-16 12:40:49.669518000 +1000 @@ -3705,7 +3705,7 @@ STATIC xfs_bmbt_rec_t * xfs_bmap_search_extents( xfs_inode_t *ip, /* incore inode pointer */ xfs_fileoff_t bno, /* block number searched for */ - int whichfork, /* data or attr fork */ + int fork, /* data or attr fork */ int *eofp, /* out: end of file found */ xfs_extnum_t *lastxp, /* out: last extent index */ xfs_bmbt_irec_t *gotp, /* out: extent entry found */ @@ -3713,25 +3713,28 @@ xfs_bmap_search_extents( { xfs_ifork_t *ifp; /* inode fork pointer */ xfs_bmbt_rec_t *ep; /* extent record pointer */ - int rt; /* realtime flag */ XFS_STATS_INC(xs_look_exlist); - ifp = XFS_IFORK_PTR(ip, whichfork); + ifp = XFS_IFORK_PTR(ip, fork); ep = xfs_bmap_search_multi_extents(ifp, bno, eofp, lastxp, gotp, prevp); - rt = (whichfork == XFS_DATA_FORK) && XFS_IS_REALTIME_INODE(ip); - if (unlikely(!rt && !gotp->br_startblock && (*lastxp != NULLEXTNUM))) { - cmn_err(CE_PANIC,"Access to block zero: fs: <%s> inode: %lld " - "start_block : %llx start_off : %llx blkcnt : %llx " - "extent-state : %x \n", - (ip->i_mount)->m_fsname, (long long)ip->i_ino, + if (unlikely(!(gotp->br_startblock) && (*lastxp != NULLEXTNUM) && + !(XFS_IS_REALTIME_INODE(ip) && fork == XFS_DATA_FORK))) { + xfs_cmn_err(XFS_PTAG_FSBLOCK_ZERO, CE_ALERT, ip->i_mount, + "Access to block zero in inode %llu " + "start_block: %llx start_off: %llx " + "blkcnt: %llx extent-state: %x lastx: %x\n", + (unsigned long long)ip->i_ino, (unsigned long long)gotp->br_startblock, (unsigned long long)gotp->br_startoff, (unsigned long long)gotp->br_blockcount, - gotp->br_state); - } - return ep; + gotp->br_state, *lastxp); + *lastxp = NULLEXTNUM; + *eofp = 1; + return NULL; + } + return ep; } Index: xfs-linux/xfs_iomap.c =================================================================== --- xfs-linux.orig/xfs_iomap.c 2006-08-15 15:22:53.238190250 +1000 +++ xfs-linux/xfs_iomap.c 2006-08-16 12:40:41.385000250 +1000 @@ -536,23 +536,27 @@ xfs_iomap_write_direct( * Copy any maps to caller's array and return any error. */ if (nimaps == 0) { - error = (ENOSPC); + error = ENOSPC; goto error_out; } - *ret_imap = imap; - *nmaps = 1; - if ( !(io->io_flags & XFS_IOCORE_RT) && !ret_imap->br_startblock) { - cmn_err(CE_PANIC,"Access to block zero: fs <%s> inode: %lld " - "start_block : %llx start_off : %llx blkcnt : %llx " - "extent-state : %x \n", - (ip->i_mount)->m_fsname, - (long long)ip->i_ino, - (unsigned long long)ret_imap->br_startblock, + if (unlikely(!ret_imap->br_startblock && + !(io->io_flags & XFS_IOCORE_RT))) { + xfs_cmn_err(XFS_PTAG_FSBLOCK_ZERO, CE_ALERT, ip->i_mount, + "Access to block zero in inode %llu " + "start_block: %llx start_off: %llx " + "blkcnt: %llx extent-state: %x\n", + (unsigned long long)ip->i_ino, + (unsigned long long)ret_imap->br_startblock, (unsigned long long)ret_imap->br_startoff, - (unsigned long long)ret_imap->br_blockcount, + (unsigned long long)ret_imap->br_blockcount, ret_imap->br_state); - } + error = EFSCORRUPTED; + goto error_out; + } + + *ret_imap = imap; + *nmaps = 1; return 0; error0: /* Cancel bmap, unlock inode, unreserve quota blocks, cancel trans */ @@ -715,16 +719,18 @@ retry: goto retry; } - if (!(io->io_flags & XFS_IOCORE_RT) && !ret_imap->br_startblock) { - cmn_err(CE_PANIC,"Access to block zero: fs <%s> inode: %lld " - "start_block : %llx start_off : %llx blkcnt : %llx " - "extent-state : %x \n", - (ip->i_mount)->m_fsname, - (long long)ip->i_ino, - (unsigned long long)ret_imap->br_startblock, + if (unlikely(!ret_imap->br_startblock && + !(io->io_flags & XFS_IOCORE_RT))) { + xfs_cmn_err(XFS_PTAG_FSBLOCK_ZERO, CE_ALERT, ip->i_mount, + "Access to block zero in inode %llu " + "start_block: %llx start_off: %llx " + "blkcnt: %llx extent-state: %x\n", + (unsigned long long)ip->i_ino, + (unsigned long long)ret_imap->br_startblock, (unsigned long long)ret_imap->br_startoff, - (unsigned long long)ret_imap->br_blockcount, + (unsigned long long)ret_imap->br_blockcount, ret_imap->br_state); + return XFS_ERROR(EFSCORRUPTED); } *ret_imap = imap[0]; @@ -855,16 +861,14 @@ xfs_iomap_write_allocate( * See if we were able to allocate an extent that * covers at least part of the callers request */ - for (i = 0; i < nimaps; i++) { - if (!(io->io_flags & XFS_IOCORE_RT) && - !imap[i].br_startblock) { - cmn_err(CE_PANIC,"Access to block zero: " - "fs <%s> inode: %lld " - "start_block : %llx start_off : %llx " - "blkcnt : %llx extent-state : %x \n", - (ip->i_mount)->m_fsname, - (long long)ip->i_ino, + if (unlikely(!imap[i].br_startblock && + !(io->io_flags & XFS_IOCORE_RT))) { + xfs_cmn_err(XFS_PTAG_FSBLOCK_ZERO, CE_ALERT, mp, + "Access to block zero in inode %llu " + "start_block: %llx start_off: %llx " + "blkcnt: %llx extent-state: %x\n", + (unsigned long long)ip->i_ino, (unsigned long long) imap[i].br_startblock, (unsigned long long) @@ -872,7 +876,8 @@ xfs_iomap_write_allocate( (unsigned long long) imap[i].br_blockcount, imap[i].br_state); - } + return XFS_ERROR(EFSCORRUPTED); + } if ((offset_fsb >= imap[i].br_startoff) && (offset_fsb < (imap[i].br_startoff + imap[i].br_blockcount))) { @@ -951,7 +956,7 @@ xfs_iomap_write_unwritten( } if (error) { xfs_trans_cancel(tp, 0); - goto error0; + return XFS_ERROR(error); } xfs_ilock(ip, XFS_ILOCK_EXCL); @@ -977,19 +982,21 @@ xfs_iomap_write_unwritten( error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); xfs_iunlock(ip, XFS_ILOCK_EXCL); if (error) - goto error0; + return XFS_ERROR(error); - if ( !(io->io_flags & XFS_IOCORE_RT) && !imap.br_startblock) { - cmn_err(CE_PANIC,"Access to block zero: fs <%s> " - "inode: %lld start_block : %llx start_off : " - "%llx blkcnt : %llx extent-state : %x \n", - (ip->i_mount)->m_fsname, - (long long)ip->i_ino, + if (unlikely(!imap.br_startblock && + !(io->io_flags & XFS_IOCORE_RT))) { + xfs_cmn_err(XFS_PTAG_FSBLOCK_ZERO, CE_ALERT, mp, + "Access to block zero in inode %llu " + "start_block: %llx start_off: %llx " + "blkcnt: %llx extent-state: %x\n", + (unsigned long long)ip->i_ino, (unsigned long long)imap.br_startblock, (unsigned long long)imap.br_startoff, (unsigned long long)imap.br_blockcount, imap.br_state); - } + return XFS_ERROR(EFSCORRUPTED); + } if ((numblks_fsb = imap.br_blockcount) == 0) { /* @@ -1009,6 +1016,5 @@ error_on_bmapi_transaction: xfs_bmap_cancel(&free_list); xfs_trans_cancel(tp, (XFS_TRANS_RELEASE_LOG_RES | XFS_TRANS_ABORT)); xfs_iunlock(ip, XFS_ILOCK_EXCL); -error0: return XFS_ERROR(error); } Index: xfs-linux/linux-2.4/xfs_globals.c =================================================================== --- xfs-linux.orig/linux-2.4/xfs_globals.c 2006-08-16 11:35:46.090456000 +1000 +++ xfs-linux/linux-2.4/xfs_globals.c 2006-08-16 11:35:51.546797000 +1000 @@ -37,7 +37,7 @@ xfs_param_t xfs_params = { .restrict_chown = { 0, 1, 1 }, .sgid_inherit = { 0, 0, 1 }, .symlink_mode = { 0, 0, 1 }, - .panic_mask = { 0, 0, 127 }, + .panic_mask = { 0, 0, 255 }, .error_level = { 0, 3, 11 }, .syncd_timer = { 1*100, 30*100, 60*100 }, .probe_dmapi = { 0, 0, 1 }, Index: xfs-linux/linux-2.6/xfs_globals.c =================================================================== --- xfs-linux.orig/linux-2.6/xfs_globals.c 2006-08-16 11:35:46.182461750 +1000 +++ xfs-linux/linux-2.6/xfs_globals.c 2006-08-16 11:36:59.859066250 +1000 @@ -34,7 +34,7 @@ xfs_param_t xfs_params = { .restrict_chown = { 0, 1, 1 }, .sgid_inherit = { 0, 0, 1 }, .symlink_mode = { 0, 0, 1 }, - .panic_mask = { 0, 0, 127 }, + .panic_mask = { 0, 0, 255 }, .error_level = { 0, 3, 11 }, .syncd_timer = { 1*100, 30*100, 7200*100}, .probe_dmapi = { 0, 0, 1 }, Index: xfs-linux/xfs_error.h =================================================================== --- xfs-linux.orig/xfs_error.h 2006-08-16 11:35:03.599800500 +1000 +++ xfs-linux/xfs_error.h 2006-08-16 12:40:15.755398500 +1000 @@ -167,6 +167,7 @@ extern int xfs_errortag_clearall_umount( #define XFS_PTAG_SHUTDOWN_CORRUPT 0x00000010 #define XFS_PTAG_SHUTDOWN_IOERROR 0x00000020 #define XFS_PTAG_SHUTDOWN_LOGERROR 0x00000040 +#define XFS_PTAG_FSBLOCK_ZERO 0x00000080 struct xfs_mount; /* PRINTFLIKE4 */ From owner-xfs@oss.sgi.com Tue Aug 15 23:20:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 23:20:30 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7G6JoDW029011 for ; Tue, 15 Aug 2006 23:20:04 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15234; Wed, 16 Aug 2006 16:19:10 +1000 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 k7G6IZEo55786660; Wed, 16 Aug 2006 16:18:35 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7G6IXpS55854289; Wed, 16 Aug 2006 16:18:33 +1000 (AEST) Date: Wed, 16 Aug 2006 16:18:33 +1000 From: David Chinner To: xfs-masters@oss.sgi.com Cc: nathans@sgi.com, xfs@oss.sgi.com Subject: Re: [xfs-masters] [BUG]: soft lock detected Message-ID: <20060816061833.GH51703024@melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 8678 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2078 Lines: 62 On Tue, Aug 15, 2006 at 06:04:21PM +0800, Yi CDL Yang wrote: > > Hi, > > When I stress XFS filesystem, I find a bug, I can regenerate it on > 2.6.18-rc3 and 2.6.18-rc4, my steps is: > # mount /dev/sda5 /mnt/sda5 > #su oneuser > $ mkdir /mnt/sda5/xfstest > $ cd /mnt/sda5 > $ bonnie++ -d xfstest -s 2048 -r 512 Is that single threaded? > After a while, kernel will output the following debug information: > > BUG: soft lockup detected on CPU#0! > Call Trace: > [C0000001C7E5EEA0] [D000000000973018] .xfs_icsb_disable_counter+0x90/0x1ac > [xfs] > [C0000001C7E5EF60] [D000000000973274] .xfs_icsb_balance_counter+0x70/0x294 > [xfs] > [C0000001C7E5F010] [D000000000973870] > .xfs_icsb_modify_counters_int+0x188/0x1f4 [xfs] We take spinlocks in these functions - but unless you've got lots of CPUs they aren't taken for very long. We haven't seen these reports on large CPU count machines, so I'm not sure off the top of my head what would cause this. FWIW, what type of machine and how many CPUs do you have? > ///////////////////// > BUG: soft lockup detected on CPU#2! > Call Trace: > --- Exception: 901 at .xfs_alloc_fix_freelist+0x7c/0x4c4 [xfs] > LR = .xfs_alloc_vextent+0x2f0/0x494 [xfs] > [C0000001C10CAF00] [0000000000000000] 0x0 (unreliable) > [C0000001C10CB040] [D000000000933298] .xfs_alloc_vextent+0x2f0/0x494 [xfs] > [C0000001C10CB110] [D000000000942F9C] .xfs_bmapi+0xd18/0x1834 [xfs] > [C0000001C10CB390] [D0000000009688F8] .xfs_iomap_write_allocate+0x264/0x470 And we don't even hold spinlocks in that function. We do nothing that would hold off interrupts or the scheduler in these functions.... > According to these information, I can't find the reason of the problem, for > soft lockup, I think > only preemption disabling or interrupt disabling can result in this, but > the above functions don't > run such an operation, I don't know what is your idea? Spinlocks disable preemption so that could cause it, but I cannot see how that second trace is at all valid.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Aug 15 23:48:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 23:49:24 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7G6mjDW002274 for ; Tue, 15 Aug 2006 23:48:57 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15978; Wed, 16 Aug 2006 16:48:02 +1000 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 k7G6lQEo55864982; Wed, 16 Aug 2006 16:47:27 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7G6lPsY55861068; Wed, 16 Aug 2006 16:47:25 +1000 (AEST) Date: Wed, 16 Aug 2006 16:47:25 +1000 From: David Chinner To: Nathan Scott Cc: xfs@oss.sgi.com Subject: Re: review: fsblock zero - don't panic Message-ID: <20060816064725.GK51703024@melbourne.sgi.com> References: <20060810155851.C2591606@wobbly.melbourne.sgi.com> <20060811032626.GF50254148@melbourne.sgi.com> <20060816142800.D2762042@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060816142800.D2762042@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8679 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 3251 Lines: 99 On Wed, Aug 16, 2006 at 02:28:01PM +1000, Nathan Scott wrote: > On Fri, Aug 11, 2006 at 01:26:26PM +1000, David Chinner wrote: > > ... > > Looks OK. > > Thanks mate. > > > ... > > If you are hinting this branch to be unlikely, then we should also > > check the start block first before checking the io_flags. We only > > need to check the io_flags if we are actually accessing block zero. > > I've rolled this into a new version. I also got prodded to still > provide an option to panic on detecting this, for debugging - so I > rewrote this to report through the panic_mask mechanism, which now > gives us the option to optionally panic if need be... could you do > a second pass over this for me? Couple of things: > Index: xfs-linux/xfs_iomap.c > =================================================================== > --- xfs-linux.orig/xfs_iomap.c 2006-08-15 15:22:53.238190250 +1000 > +++ xfs-linux/xfs_iomap.c 2006-08-16 12:40:41.385000250 +1000 > @@ -536,23 +536,27 @@ xfs_iomap_write_direct( > * Copy any maps to caller's array and return any error. > */ > if (nimaps == 0) { > - error = (ENOSPC); > + error = ENOSPC; > goto error_out; > } > > - *ret_imap = imap; > - *nmaps = 1; > - if ( !(io->io_flags & XFS_IOCORE_RT) && !ret_imap->br_startblock) { Here we check imap for block zero access.... > - cmn_err(CE_PANIC,"Access to block zero: fs <%s> inode: %lld " > - "start_block : %llx start_off : %llx blkcnt : %llx " > - "extent-state : %x \n", > - (ip->i_mount)->m_fsname, > - (long long)ip->i_ino, > - (unsigned long long)ret_imap->br_startblock, > + if (unlikely(!ret_imap->br_startblock && and now you're checking ret_imap for zero block access. Shouldn't that be checking imap? > + !(io->io_flags & XFS_IOCORE_RT))) { > + xfs_cmn_err(XFS_PTAG_FSBLOCK_ZERO, CE_ALERT, ip->i_mount, > + "Access to block zero in inode %llu " > + "start_block: %llx start_off: %llx " > + "blkcnt: %llx extent-state: %x\n", > + (unsigned long long)ip->i_ino, > + (unsigned long long)ret_imap->br_startblock, > (unsigned long long)ret_imap->br_startoff, > - (unsigned long long)ret_imap->br_blockcount, > + (unsigned long long)ret_imap->br_blockcount, > ret_imap->br_state); FWIW, given the number of times this exact same code is given, a wrapper function for it would clean up the code quite a bit. i.e. xfs_cmn_err_fsblock_zero(ip, ret_imap); would replace the above mess.... > - } > + error = EFSCORRUPTED; > + goto error_out; > + } > + > + *ret_imap = imap; > + *nmaps = 1; > return 0; > > error0: /* Cancel bmap, unlock inode, unreserve quota blocks, cancel trans */ > @@ -715,16 +719,18 @@ retry: > goto retry; > } > > - if (!(io->io_flags & XFS_IOCORE_RT) && !ret_imap->br_startblock) { And this one checks ret_imap for block zero, not imap[0]. One of these original checks was buggy - which one should we be checking, ret_imap that is being passed into the function or imap that is what was returned by the XFS_BMAPI call? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Aug 15 23:58:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Aug 2006 23:59:20 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7G6whDW004638 for ; Tue, 15 Aug 2006 23:58:54 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA16148; Wed, 16 Aug 2006 16:58:00 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7G6vwgw2771234; Wed, 16 Aug 2006 16:57:58 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7G6vuAD2767959; Wed, 16 Aug 2006 16:57:56 +1000 (EST) Date: Wed, 16 Aug 2006 16:57:56 +1000 From: Nathan Scott To: David Chinner Cc: xfs@oss.sgi.com Subject: Re: review: fsblock zero - don't panic Message-ID: <20060816165756.C2770659@wobbly.melbourne.sgi.com> References: <20060810155851.C2591606@wobbly.melbourne.sgi.com> <20060811032626.GF50254148@melbourne.sgi.com> <20060816142800.D2762042@wobbly.melbourne.sgi.com> <20060816064725.GK51703024@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060816064725.GK51703024@melbourne.sgi.com>; from dgc@sgi.com on Wed, Aug 16, 2006 at 04:47:25PM +1000 X-archive-position: 8680 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 646 Lines: 24 On Wed, Aug 16, 2006 at 04:47:25PM +1000, David Chinner wrote: > On Wed, Aug 16, 2006 at 02:28:01PM +1000, Nathan Scott wrote: > ... > xfs_cmn_err_fsblock_zero(ip, ret_imap); > > would replace the above mess.... Will do. > > - if (!(io->io_flags & XFS_IOCORE_RT) && !ret_imap->br_startblock) { > > And this one checks ret_imap for block zero, not imap[0]. > > One of these original checks was buggy - which one should we be checking, > ret_imap that is being passed into the function or imap that is what was > returned by the XFS_BMAPI call? The latter I think - I'll look more closely tomorrow, and fix that up. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Aug 16 01:32:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 01:32:53 -0700 (PDT) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7G8WIDW029162 for ; Wed, 16 Aug 2006 01:32:22 -0700 Received: from saturn.flamingspork.com (ppp163-199.static.internode.on.net [150.101.163.199]) by smtp3.adl2.internode.on.net (8.13.6/8.13.5) with ESMTP id k7G7Nr0O068152; Wed, 16 Aug 2006 16:53:54 +0930 (CST) (envelope-from stewart@flamingspork.com) Received: from localhost.localdomain (saturn.flamingspork.com [127.0.0.1]) by saturn.flamingspork.com (Postfix) with ESMTP id A0F63C00250; Wed, 16 Aug 2006 17:23:47 +1000 (EST) Received: by localhost.localdomain (Postfix, from userid 1000) id E6642140F874; Wed, 16 Aug 2006 15:23:37 +0800 (CST) Subject: Re: review: fsblock zero - don't panic From: Stewart Smith To: Nathan Scott Cc: David Chinner , xfs@oss.sgi.com In-Reply-To: <20060816142800.D2762042@wobbly.melbourne.sgi.com> References: <20060810155851.C2591606@wobbly.melbourne.sgi.com> <20060811032626.GF50254148@melbourne.sgi.com> <20060816142800.D2762042@wobbly.melbourne.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-x5YZkhxpKDkuvfYjaknR" Date: Wed, 16 Aug 2006 15:23:33 +0800 Message-Id: <1155713014.7103.345.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-archive-position: 8681 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stewart@flamingspork.com Precedence: bulk X-list: xfs Content-Length: 5618 Lines: 154 --=-x5YZkhxpKDkuvfYjaknR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2006-08-16 at 14:28 +1000, Nathan Scott wrote: > On Fri, Aug 11, 2006 at 01:26:26PM +1000, David Chinner wrote: > > ... > > Looks OK. >=20 > Thanks mate. >=20 > > ... > > If you are hinting this branch to be unlikely, then we should also > > check the start block first before checking the io_flags. We only > > need to check the io_flags if we are actually accessing block zero. >=20 > I've rolled this into a new version. I also got prodded to still > provide an option to panic on detecting this, for debugging - so I > rewrote this to report through the panic_mask mechanism, which now > gives us the option to optionally panic if need be... could you do > a second pass over this for me? >=20 > cheers. >=20 > --=20 > Nathan >=20 >=20 > Index: xfs-linux/xfs_bmap.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- xfs-linux.orig/xfs_bmap.c 2006-08-15 15:22:53.198187750 +1000 > +++ xfs-linux/xfs_bmap.c 2006-08-16 12:40:49.669518000 +1000 > @@ -3705,7 +3705,7 @@ STATIC xfs_bmbt_rec_t *=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > xfs_bmap_search_extents( > xfs_inode_t *ip, /* incore inode pointer */ > xfs_fileoff_t bno, /* block number searched for */ > - int whichfork, /* data or attr fork */ > + int fork, /* data or attr fork */ > int *eofp, /* out: end of file found */ > xfs_extnum_t *lastxp, /* out: last extent index */ > xfs_bmbt_irec_t *gotp, /* out: extent entry found */ > @@ -3713,25 +3713,28 @@ xfs_bmap_search_extents( > { > xfs_ifork_t *ifp; /* inode fork pointer */ > xfs_bmbt_rec_t *ep; /* extent record pointer */ > - int rt; /* realtime flag */ >=20=20 > XFS_STATS_INC(xs_look_exlist); > - ifp =3D XFS_IFORK_PTR(ip, whichfork); > + ifp =3D XFS_IFORK_PTR(ip, fork); >=20=20 > ep =3D xfs_bmap_search_multi_extents(ifp, bno, eofp, lastxp, gotp, prev= p); >=20=20 > - rt =3D (whichfork =3D=3D XFS_DATA_FORK) && XFS_IS_REALTIME_INODE(ip); > - if (unlikely(!rt && !gotp->br_startblock && (*lastxp !=3D NULLEXTNUM)))= { > - cmn_err(CE_PANIC,"Access to block zero: fs: <%s> inode: = %lld " > - "start_block : %llx start_off : %llx blkcnt : %llx " > - "extent-state : %x \n", > - (ip->i_mount)->m_fsname, (long long)ip->i_ino, > + if (unlikely(!(gotp->br_startblock) && (*lastxp !=3D NULLEXTNUM) && > + !(XFS_IS_REALTIME_INODE(ip) && fork =3D=3D XFS_DATA_FORK))) { > + xfs_cmn_err(XFS_PTAG_FSBLOCK_ZERO, CE_ALERT, ip->i_mount, > + "Access to block zero in inode %llu " > + "start_block: %llx start_off: %llx " > + "blkcnt: %llx extent-state: %x lastx: %x\n", > + (unsigned long long)ip->i_ino, > (unsigned long long)gotp->br_startblock, > (unsigned long long)gotp->br_startoff, > (unsigned long long)gotp->br_blockcount, > - gotp->br_state); > - } > - return ep; > + gotp->br_state, *lastxp); > + *lastxp =3D NULLEXTNUM; > + *eofp =3D 1; > + return NULL; > + } > + return ep; > } >=20=20 >=20 > Index: xfs-linux/xfs_iomap.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- xfs-linux.orig/xfs_iomap.c 2006-08-15 15:22:53.238190250 +1000 > +++ xfs-linux/xfs_iomap.c 2006-08-16 12:40:41.385000250 +1000 > @@ -536,23 +536,27 @@ xfs_iomap_write_direct( > * Copy any maps to caller's array and return any error. > */ > if (nimaps =3D=3D 0) { > - error =3D (ENOSPC); > + error =3D ENOSPC; > goto error_out; > } >=20=20 > - *ret_imap =3D imap; > - *nmaps =3D 1; > - if ( !(io->io_flags & XFS_IOCORE_RT) && !ret_imap->br_startblock) { > - cmn_err(CE_PANIC,"Access to block zero: fs <%s> inode: = %lld " > - "start_block : %llx start_off : %llx blkcnt : %l= lx " > - "extent-state : %x \n", > - (ip->i_mount)->m_fsname, > - (long long)ip->i_ino, > - (unsigned long long)ret_imap->br_startblock, > + if (unlikely(!ret_imap->br_startblock && > + !(io->io_flags & XFS_IOCORE_RT))) { > + xfs_cmn_err(XFS_PTAG_FSBLOCK_ZERO, CE_ALERT, ip->i_mount, > + "Access to block zero in inode %llu " > + "start_block: %llx start_off: %llx " > + "blkcnt: %llx extent-state: %x\n", > + (unsigned long long)ip->i_ino, > + (unsigned long long)ret_imap->br_startblock, > (unsigned long long)ret_imap->br_startoff, > - (unsigned long long)ret_imap->br_blockcount, > + (unsigned long long)ret_imap->br_blockcount, > ret_imap->br_state); > - } > + error =3D EFSCORRUPTED; should this be XFS_ERROR(EFSCORRUPTED) ? perhaps change to use it for consistency if the conversion is done in error_out? > + goto error_out; --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-x5YZkhxpKDkuvfYjaknR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBE4sf1KglWCUL+FDoRApckAKCwCMnUW9PrdewglII6gxG2Uw5rxACgxk19 n0kdK0AVSOJ+ybuIhwKBcg4= =OZFW -----END PGP SIGNATURE----- --=-x5YZkhxpKDkuvfYjaknR-- From owner-xfs@oss.sgi.com Wed Aug 16 07:17:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 07:17:21 -0700 (PDT) Received: from mail.interline.it (mail.interline.it [195.182.241.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7GEH6DW004385 for ; Wed, 16 Aug 2006 07:17:07 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.interline.it (Postfix) with ESMTP id C5D23B12 for ; Wed, 16 Aug 2006 15:08:51 +0200 (CEST) Received: from mail.interline.it ([127.0.0.1]) by localhost (pin [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01259-03 for ; Wed, 16 Aug 2006 15:08:50 +0200 (CEST) Received: from [192.168.1.98] (unknown [88.36.237.170]) by mail.interline.it (Postfix) with ESMTP id CAFC4B0C for ; Wed, 16 Aug 2006 15:08:49 +0200 (CEST) From: "Daniele P." Organization: Interline To: xfs@oss.sgi.com Subject: xfsdump -s unacceptable performances Date: Wed, 16 Aug 2006 15:15:00 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608161515.00543.daniele@interline.it> X-archive-position: 8682 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: daniele@interline.it Precedence: bulk X-list: xfs Content-Length: 2306 Lines: 66 Hi all, I'm new to the list. I have a problem with xfsdump using the -s option. I'm aware that the latest version (2.2.38) skip the scan and prune of the entire filesystem (see the test below), but there are other places where xfsdump performs an entire scan of the filesystem, slowing down the backup process. For example in: * dump/inomap.c after "phase 3" there is a function call to bigstat_iter that scan the entire filesystem * dump/content.c the function dump_dirs again scan the entire filesystem Are all there scan really necessary? Could we expect a performance fix? Is there a workaround? I have done some test, and with quite large filesystem the performances where unacceptable. Dumping one directory with 4 file using 4KB of space takes hours (or days, it hasn't finished yet) if the underlying filesystem contains around 10.000.000 inodes. On request I could provide more information and the output of some test. Let's start with a simple comparison between 2.2.27 and 2.2.38 using a small filesystem (40.000 inodes). time xfsdump -p 60 -v drive=debug,media=debug \ -s etc/20060401-0030 - /media/xfs-test | dd of=/dev/null xfsdump: using file dump (drive_simple) strategy xfsdump: version 2.2.27 (dump format 3.0) - Running single-threaded [...] xfsdump: media file size 17780576 bytes xfsdump: dump size (non-dir files) : 16477472 bytes xfsdump: dump complete: 219459 seconds elapsed xfsdump: Dump Status: SUCCESS 34727+1 records in 34727+1 records out 17780576 bytes transferred in 219459.047053 seconds (81 bytes/sec) real 3657m39.120s user 0m2.361s sys 0m9.238s time /usr/lib/bin/xfsdump -p 60 -v drive=debug,media=debug \ -s etc/20060401-0030 - /media/xfs-test | dd of=/dev/null /usr/lib/bin/xfsdump: using file dump (drive_simple) strategy /usr/lib/bin/xfsdump: version 2.2.38 (dump format 3.0) - Running single-threaded [...] /usr/lib/bin/xfsdump: media file size 17780576 bytes /usr/lib/bin/xfsdump: dump size (non-dir files) : 16477472 bytes /usr/lib/bin/xfsdump: dump complete: 18 seconds elapsed /usr/lib/bin/xfsdump: Dump Status: SUCCESS 34727+1 records in 34727+1 records out 17780576 bytes transferred in 17.451939 seconds (1018831 bytes/sec) real 0m17.575s user 0m0.132s sys 0m1.035s Thanks in advance for your suggestions. Daniele P. From owner-xfs@oss.sgi.com Wed Aug 16 08:44:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 08:44:20 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7GFi6DW022226 for ; Wed, 16 Aug 2006 08:44:06 -0700 Received: from [194.173.12.131] (helo=[172.25.16.7]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1GDMVa1m3f-0004Y9; Wed, 16 Aug 2006 16:36:38 +0200 Message-ID: <44E32DE6.9090602@gmx.net> Date: Wed, 16 Aug 2006 16:38:30 +0200 From: Klaus Strebel User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: xfsdump -s unacceptable performances References: <200608161515.00543.daniele@interline.it> In-Reply-To: <200608161515.00543.daniele@interline.it> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:8a7df7300d3d15a4f701302fdde7adf9 X-archive-position: 8683 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@gmx.net Precedence: bulk X-list: xfs Content-Length: 2876 Lines: 86 Daniele P. schrieb: > Hi all, > I'm new to the list. I have a problem with xfsdump using the -s option. > I'm aware that the latest version (2.2.38) skip the scan and prune of > the entire filesystem (see the test below), but there are other places > where xfsdump performs an entire scan of the filesystem, slowing down > the backup process. > > For example in: > * dump/inomap.c after "phase 3" there is a function call to > bigstat_iter that scan the entire filesystem > * dump/content.c the function dump_dirs again scan the entire > filesystem > > Are all there scan really necessary? > Could we expect a performance fix? > Is there a workaround? > > I have done some test, and with quite large filesystem the performances > where unacceptable. Dumping one directory with 4 file using 4KB of space > takes hours (or days, it hasn't finished yet) if the underlying filesystem > contains around 10.000.000 inodes. > > On request I could provide more information and the output of some test. > > Let's start with a simple comparison between 2.2.27 and 2.2.38 > using a small filesystem (40.000 inodes). > > time xfsdump -p 60 -v drive=debug,media=debug \ > -s etc/20060401-0030 - /media/xfs-test | dd of=/dev/null > xfsdump: using file dump (drive_simple) strategy > xfsdump: version 2.2.27 (dump format 3.0) - Running single-threaded > [...] > xfsdump: media file size 17780576 bytes > xfsdump: dump size (non-dir files) : 16477472 bytes > xfsdump: dump complete: 219459 seconds elapsed > xfsdump: Dump Status: SUCCESS > 34727+1 records in > 34727+1 records out > 17780576 bytes transferred in 219459.047053 seconds (81 bytes/sec) > > real 3657m39.120s > user 0m2.361s > sys 0m9.238s > > > time /usr/lib/bin/xfsdump -p 60 -v drive=debug,media=debug \ > -s etc/20060401-0030 - /media/xfs-test | dd of=/dev/null > /usr/lib/bin/xfsdump: using file dump (drive_simple) strategy > /usr/lib/bin/xfsdump: version 2.2.38 (dump format 3.0) - Running single-threaded > [...] > /usr/lib/bin/xfsdump: media file size 17780576 bytes > /usr/lib/bin/xfsdump: dump size (non-dir files) : 16477472 bytes > /usr/lib/bin/xfsdump: dump complete: 18 seconds elapsed > /usr/lib/bin/xfsdump: Dump Status: SUCCESS > 34727+1 records in > 34727+1 records out > 17780576 bytes transferred in 17.451939 seconds (1018831 bytes/sec) > > real 0m17.575s > user 0m0.132s > sys 0m1.035s > > Thanks in advance for your suggestions. > > Daniele P. Hi Daniele, hum, so the 2.2.27 was running 3657m39.120s and the 2.2.38 is running the same (?) in 0m17.575s. Where is your performance problem running now 10000 times faster than the old 2.2.27 version??? Or did i miss something? Ciao Klaus -- Mit freundlichen Grüssen / best regards Klaus Strebel, Dipl.-Inform. (FH), mailto:klaus.strebel@gmx.net /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \ From owner-xfs@oss.sgi.com Wed Aug 16 09:39:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 09:39:36 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7GGdADW029863 for ; Wed, 16 Aug 2006 09:39:20 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k7GGcUnx024727 for ; Wed, 16 Aug 2006 11:38:31 -0500 Received: from [128.162.233.24] (fsgi275.americas.sgi.com [128.162.233.24]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k7GGc78s30304780; Wed, 16 Aug 2006 09:38:07 -0700 (PDT) Message-ID: <44E349EE.6080905@sgi.com> Date: Wed, 16 Aug 2006 11:38:06 -0500 From: Bill Kendall User-Agent: Mail/News 1.5 (X11/20060228) MIME-Version: 1.0 To: "Daniele P." CC: xfs@oss.sgi.com Subject: Re: xfsdump -s unacceptable performances References: <200608161515.00543.daniele@interline.it> In-Reply-To: <200608161515.00543.daniele@interline.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8684 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 1475 Lines: 42 On 08/16/06 08:15, Daniele P. wrote: > Hi all, > I'm new to the list. I have a problem with xfsdump using the -s option. > I'm aware that the latest version (2.2.38) skip the scan and prune of > the entire filesystem (see the test below), but there are other places > where xfsdump performs an entire scan of the filesystem, slowing down > the backup process. > > For example in: > * dump/inomap.c after "phase 3" there is a function call to > bigstat_iter that scan the entire filesystem This scan stops after determining start points for all streams. On Linux there's always one dump stream, so it returns after reading one buffer full of inodes. > * dump/content.c the function dump_dirs again scan the entire > filesystem And of course there's another scan for dumping the non-dir inodes. Keep in mind these are inode scans, which are substantially faster than recursing through the directories doing individual stat(2) calls. Nonetheless, these scans could be optimized by seeking the scan to the next inode of interest, which could be found using xfsdump's inomap (created in the first scan). This would be beneficial to -s and incremental dumps. > > Are all there scan really necessary? A lot of this stuff could be done in a single scan in a disk-to-disk backup approach. But in the current scheme, they are necessary. > Could we expect a performance fix? > Is there a workaround? Nothing is planned, but patches are always welcome. Regards, Bill From owner-xfs@oss.sgi.com Wed Aug 16 12:02:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 12:02:29 -0700 (PDT) Received: from 217-133-29-81.b2b.tiscali.it (217-133-29-81.b2b.tiscali.it [217.133.29.81]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7GJ2HDW017942 for ; Wed, 16 Aug 2006 12:02:17 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by 217-133-29-81.b2b.tiscali.it (Postfix) with ESMTP id D4C868012D for ; Wed, 16 Aug 2006 20:01:54 +0200 (CEST) Received: from 217-133-29-81.b2b.tiscali.it ([127.0.0.1]) by localhost (solstizio.toel.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18308-08 for ; Wed, 16 Aug 2006 20:01:39 +0200 (CEST) Received: from [10.0.11.232] (unknown [10.0.2.114]) by 217-133-29-81.b2b.tiscali.it (Postfix) with ESMTP id 4E7E18012C for ; Wed, 16 Aug 2006 20:01:39 +0200 (CEST) From: "Daniele P." Organization: Interline To: xfs@oss.sgi.com Subject: Re: xfsdump -s unacceptable performances User-Agent: KMail/1.9.4 References: <200608161515.00543.daniele@interline.it> <44E32DE6.9090602@gmx.net> In-Reply-To: <44E32DE6.9090602@gmx.net> MIME-Version: 1.0 Content-Disposition: inline Date: Wed, 16 Aug 2006 20:01:10 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200608162001.10342.daniele@interline.it> X-archive-position: 8686 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: daniele@interline.it Precedence: bulk X-list: xfs Content-Length: 3254 Lines: 80 On Wednesday 16 August 2006 16:38, you wrote: > Daniele P. schrieb: > Hi Daniele, > > hum, so the 2.2.27 was running 3657m39.120s and the 2.2.38 is running > the same (?) in 0m17.575s. Where is your performance problem running now > 10000 times faster than the old 2.2.27 version??? > Or did i miss something? Hi Klaus, Yes, there was a huge performance improvement for /small/ filesystem, (40.000 inodes, in my test case). But xfsdump still doesn't scale down well with a small subtree on a large filesystem. Now the test on the /large/ (11.000.000 inodes) filesystem has ended. ori:~# find /media/xfs-large/backup/pin/ -type f | wc -l 2 ori:~# find /media/xfs-large/backup/pin/ -type d | wc -l 2 ori:~# find /media/xfs-large/backup/pin/ | wc -l 4 ori:~# du -s /media/xfs-large/backup/pin/ 8 /media/xfs-large/backup/pin/ I stopped the test with 2.2.27 after 5 days of "phase 3". Here is the test with 2.2.38, which is still too slow: time /usr/local/bin/xfsdump -p 60 -v drive=debug,media=debug \ -s backup/pin - /media/xfs-large | dd of=/dev/null /usr/local/bin/xfsdump: using file dump (drive_simple) strategy /usr/local/bin/xfsdump: version 2.2.38 (dump format 3.0) - Running single-threaded /usr/local/bin/xfsdump: level 0 dump of ori:/media/xfs-large /usr/local/bin/xfsdump: dump date: Wed Aug 16 12:56:57 2006 /usr/local/bin/xfsdump: session id: a293b79a-a5ac-4e49-be3e-55fbc5f8fba2 /usr/local/bin/xfsdump: session label: "" /usr/local/bin/xfsdump: ino map phase 1: constructing initial dump list /usr/local/bin/xfsdump: status at 12:58:12: 75 seconds elapsed /usr/local/bin/xfsdump: ino map phase 2: skipping (no pruning necessary) /usr/local/bin/xfsdump: ino map phase 3: skipping (only one dump stream) /usr/local/bin/xfsdump: status at 12:58:57: inomap phase 3 79568/11017767 inos scanned, 120 seconds elaps ed [...] /usr/local/bin/xfsdump: status at 13:10:58: inomap phase 3 1890564/11017767 inos scanned, 841 seconds elapsed /usr/local/bin/xfsdump: ino map construction complete /usr/local/bin/xfsdump: estimated dump size: 5617536 bytes /usr/local/bin/xfsdump: Media op: begin media file /usr/local/bin/xfsdump: creating dump session media file 0 (media 0, file 0) /usr/local/bin/xfsdump: dumping ino map /usr/local/bin/xfsdump: flushing write buf addr 0xb7e58000 size 0x40000 [...] /usr/local/bin/xfsdump: flushing write buf addr 0xb7e58000 size 0x40000 /usr/local/bin/xfsdump: dumping directories /usr/local/bin/xfsdump: dumping non-directory files /usr/local/bin/xfsdump: status at 13:44:48: 1/2 files dumped, 31.6% data dumped, 2871 seconds elapsed [...] /usr/local/bin/xfsdump: status at 14:02:57: 2/2 files dumped, 44.5% data dumped, 3960 seconds elapsed /usr/local/bin/xfsdump: ending media file /usr/local/bin/xfsdump: Media op: end media file /usr/local/bin/xfsdump: flushing write buf addr 0xb7e58000 size 0x1a6b8 /usr/local/bin/xfsdump: media file size 5613240 bytes /usr/local/bin/xfsdump: dump size (non-dir files) : 3648 bytes /usr/local/bin/xfsdump: dump complete: 3999 seconds elapsed /usr/local/bin/xfsdump: Dump Status: SUCCESS 10963+1 records in 10963+1 records out 5613240 bytes transferred in 3998.904421 seconds (1404 bytes/sec) real 66m38.933s user 0m2.882s sys 0m36.289s Regards, Daniele From owner-xfs@oss.sgi.com Wed Aug 16 12:02:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 12:02:29 -0700 (PDT) Received: from 217-133-29-81.b2b.tiscali.it (217-133-29-81.b2b.tiscali.it [217.133.29.81]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7GJ2HDW017941 for ; Wed, 16 Aug 2006 12:02:17 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by 217-133-29-81.b2b.tiscali.it (Postfix) with ESMTP id 398318012F for ; Wed, 16 Aug 2006 20:06:11 +0200 (CEST) Received: from 217-133-29-81.b2b.tiscali.it ([127.0.0.1]) by localhost (solstizio.toel.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18308-09 for ; Wed, 16 Aug 2006 20:06:08 +0200 (CEST) Received: from [10.0.11.232] (unknown [10.0.2.114]) by 217-133-29-81.b2b.tiscali.it (Postfix) with ESMTP id 42AA08012E for ; Wed, 16 Aug 2006 20:06:08 +0200 (CEST) From: "Daniele P." Organization: Interline To: xfs@oss.sgi.com Subject: Re: xfsdump -s unacceptable performances Date: Wed, 16 Aug 2006 20:05:39 +0200 User-Agent: KMail/1.9.4 References: <200608161515.00543.daniele@interline.it> <44E349EE.6080905@sgi.com> In-Reply-To: <44E349EE.6080905@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608162005.40112.daniele@interline.it> X-archive-position: 8685 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: daniele@interline.it Precedence: bulk X-list: xfs Content-Length: 1285 Lines: 38 On Wednesday 16 August 2006 18:38, Bill Kendall wrote: Hi Bill, Thanks for the explanations. I only have had a glimpse into the sources. > And of course there's another scan for dumping the non-dir inodes. > Keep in mind these are inode scans, which are substantially faster > than recursing through the directories doing individual stat(2) calls. Yes, but scanning 10.000.000 inodes when you really need to scan only 4 it's really a waste of resource. This is a corner case. But usually I want to backup only 10% of the entire filesystem. At this point I have to redesign my backup strategy taking care of xfsdump strength and weakness. > Nonetheless, these scans could be optimized by seeking the scan to > the next inode of interest, which could be found using xfsdump's inomap > (created in the first scan). This would be beneficial to -s and > incremental dumps. That's interesting. > > Are all there scan really necessary? > > A lot of this stuff could be done in a single scan in a disk-to-disk > backup approach. But in the current scheme, they are necessary. > > > Could we expect a performance fix? > > Is there a workaround? > > Nothing is planned, but patches are always welcome. This too, but for me the xfs filesystem it's a big black box. Thanks again, Daniele From owner-xfs@oss.sgi.com Wed Aug 16 14:06:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 14:06:53 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7GL6TDW009715 for ; Wed, 16 Aug 2006 14:06:30 -0700 Received: by nf-out-0910.google.com with SMTP id a25so845756nfc for ; Wed, 16 Aug 2006 14:05:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rxxYU/+VbKyv9LpOX0R4rLHJS2wsXz4IEGtYAXvT67Tn7BRCPWf5HYnlwXwvtijae352Sht9AxZD6ujBSY7Q/sXKSDyxuEcGypZ84OAXs1nMRzV+FxRQuukfBg15fHgdK6+xpcPqGsjwnRmUf6pjWWuttLaXUbhWAevLIISkSoc= Received: by 10.48.254.10 with SMTP id b10mr1253519nfi; Wed, 16 Aug 2006 14:05:59 -0700 (PDT) Received: by 10.78.161.18 with HTTP; Wed, 16 Aug 2006 14:05:59 -0700 (PDT) Message-ID: <9a8748490608161405s4c4ad5f5l405c6d5a7d56396@mail.gmail.com> Date: Wed, 16 Aug 2006 23:05:59 +0200 From: "Jesper Juhl" To: "Nathan Scott" Subject: Re: review: cleanup xfs_da_node_lookup_int (was Re: [PATCH] XFS: possibly uninitialized variable use in fs/xfs/xfs_da_btree.c::xfs_da_node_lookup_int()) Cc: "Eric Sandeen" , xfs@oss.sgi.com In-Reply-To: <20060814155609.G2698880@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200608122334.21901.jesper.juhl@gmail.com> <44DE9B86.90006@sandeen.net> <20060814155609.G2698880@wobbly.melbourne.sgi.com> X-archive-position: 8687 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jesper.juhl@gmail.com Precedence: bulk X-list: xfs Content-Length: 640 Lines: 17 On 14/08/06, Nathan Scott wrote: > On Sat, Aug 12, 2006 at 10:24:54PM -0500, Eric Sandeen wrote: > > ... > > FWIW seems like there's a lot of unnecessary endian flipping in there too; I > > haven't tested this but since it endian-flips the magic into blk->magic seems > > like it may as well use it: > > How's this look? > As far as I can see it looks good, but I'm still just starting to read the XFS code, so I'm far from reliable yet ;-) -- Jesper Juhl Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html From owner-xfs@oss.sgi.com Wed Aug 16 16:28:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 16:28:32 -0700 (PDT) Received: from lomwsm04.mwlo.mailwatch.com (lomwsm04.mwlo.mailwatch.com [216.157.241.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7GNSIDW031616 for ; Wed, 16 Aug 2006 16:28:18 -0700 Received: from lomwsc36.mwlo.mailwatch.com (lomw-scanner-vip [216.157.241.105]) by lomwsm04.mwlo.mailwatch.com (8.13.5.20060308/8.13.5) with ESMTP id k7GMEcTI010037 for ; Wed, 16 Aug 2006 18:14:38 -0400 (EDT) Received: from mail pickup service by lomwsc36.mwlo.mailwatch.com with Microsoft SMTPSVC; Wed, 16 Aug 2006 18:14:38 -0400 Received: from 216.157.241.100 ([216.157.241.100]) by LOMWSC36.mwlo.mailwatch.com with SMTP id 000300249f9645c9-032e-48db-bcbf-2cf2510f95a0; Wed, 16 Aug 2006 18:14:38 -0400 Received: from QMAIL.corp.questar.com ([152.137.71.222]) by lomwsm18.mwlo.mailwatch.com (8.13.5.20060308/8.13.5) with SMTP id k7GMOKSZ021873 for ; Wed, 16 Aug 2006 18:24:20 -0400 X-MW-PTR-RESULT: FAIL [152.137.71.222] X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Subject: xfs for Oracle Date: Wed, 16 Aug 2006 16:14:37 -0600 Message-ID: <91EDB00F83BAD443A9D05FA67623955A0154C169@QMAIL.corp.questar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: xfs for Oracle Thread-Index: AcbBgVyJShuld8KGSMCJj63IfJ8hQA== From: "Jeffrey Bryson" To: X-MW-BTID: 093425000020062288066000003 X-MW-CTIME: 1155767060 X-MW-SENDING-MTA: 152.137.71.222 HOP-COUNT: 1 X-MAILWATCH-INSTANCEID: 010300249f9645c9-032e-48db-bcbf-2cf2510f95a0 X-OriginalArrivalTime: 16 Aug 2006 22:14:38.0274 (UTC) FILETIME=[5D0D6A20:01C6C181] Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8688 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Jeffrey.Bryson@questar.com Precedence: bulk X-list: xfs Content-Length: 575 Lines: 18 We are debating which filesystem to use with Oracle on Suse9 or Suse10. We are not using RAC. We found this statement in Metalink: Please refer to the link below that indicates that the recommended file systems are Oracle Automatic Storage Management (ASM), ext3 (with O_SYNC), NFS, OCFS, ReiserFS, and raw. XFS is not supported. We were going with XFS until we found the above statement by Oracle. Why is XFS not supported by Oracle and will XFS be supported any time soon? Thanks for your time and input to our question. Jeff [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Wed Aug 16 16:43:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 16:43:42 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7GNh5DW001189 for ; Wed, 16 Aug 2006 16:43:16 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA11195; Thu, 17 Aug 2006 09:42:19 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7GNgHgw2789265; Thu, 17 Aug 2006 09:42:18 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7GNgFqA2791753; Thu, 17 Aug 2006 09:42:15 +1000 (EST) Date: Thu, 17 Aug 2006 09:42:15 +1000 From: Nathan Scott To: Jeffrey Bryson Cc: xfs@oss.sgi.com Subject: Re: xfs for Oracle Message-ID: <20060817094215.C2787212@wobbly.melbourne.sgi.com> References: <91EDB00F83BAD443A9D05FA67623955A0154C169@QMAIL.corp.questar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <91EDB00F83BAD443A9D05FA67623955A0154C169@QMAIL.corp.questar.com>; from Jeffrey.Bryson@questar.com on Wed, Aug 16, 2006 at 04:14:37PM -0600 X-archive-position: 8689 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 700 Lines: 20 On Wed, Aug 16, 2006 at 04:14:37PM -0600, Jeffrey Bryson wrote: > We are debating which filesystem to use with Oracle on Suse9 or Suse10. > We are not using RAC. We found this statement in Metalink: > > Please refer to the link below that indicates that the recommended file > systems are Oracle Automatic Storage Management (ASM), ext3 (with > O_SYNC), NFS, OCFS, ReiserFS, and raw. XFS is not supported. > > We were going with XFS until we found the above statement by Oracle. > Why is XFS not supported by Oracle and > will XFS be supported any time soon? You're asking the wrong people. Let us know what their reason is though, if you manage to find out from them... cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Aug 16 16:46:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 16:47:16 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7GNkbDW001877 for ; Wed, 16 Aug 2006 16:46:50 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA11424; Thu, 17 Aug 2006 09:45:48 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7GNjjgw2789893; Thu, 17 Aug 2006 09:45:46 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7GNjg9b2790310; Thu, 17 Aug 2006 09:45:42 +1000 (EST) Date: Thu, 17 Aug 2006 09:45:42 +1000 From: Nathan Scott To: Stewart Smith Cc: David Chinner , xfs@oss.sgi.com Subject: Re: review: fsblock zero - don't panic Message-ID: <20060817094542.D2787212@wobbly.melbourne.sgi.com> References: <20060810155851.C2591606@wobbly.melbourne.sgi.com> <20060811032626.GF50254148@melbourne.sgi.com> <20060816142800.D2762042@wobbly.melbourne.sgi.com> <1155713014.7103.345.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1155713014.7103.345.camel@localhost.localdomain>; from stewart@flamingspork.com on Wed, Aug 16, 2006 at 03:23:33PM +0800 X-archive-position: 8690 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 242 Lines: 13 On Wed, Aug 16, 2006 at 03:23:33PM +0800, Stewart Smith wrote: > On Wed, 2006-08-16 at 14:28 +1000, Nathan Scott wrote: > > + error = EFSCORRUPTED; > > should this be XFS_ERROR(EFSCORRUPTED) ? *nod*, will do, thanks. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Aug 16 18:34:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 18:34:43 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7H1YFDW018676 for ; Wed, 16 Aug 2006 18:34:28 -0700 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA13653; Thu, 17 Aug 2006 11:33:25 +1000 Message-ID: <44E3C6D5.2080704@sgi.com> Date: Thu, 17 Aug 2006 11:31:01 +1000 From: Timothy Shimmin User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniele P." CC: xfs@oss.sgi.com Subject: Re: xfsdump -s unacceptable performances References: <200608161515.00543.daniele@interline.it> <44E32DE6.9090602@gmx.net> <200608162001.10342.daniele@interline.it> In-Reply-To: <200608162001.10342.daniele@interline.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8691 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 700 Lines: 19 Daniele P. wrote: > But xfsdump still doesn't scale down well with a small subtree on a > large filesystem. That is very true. It is really designed for dumping whole filesystems (or at least, large parts of them). For dumping small subtrees, I'd be looking at using something else. That was one of the 1st things I noticed when looking at the xfsdump code on IRIX a while back, was all the scans it does and how for a subtree it will do another scan and prune the data - i.e. implemented like an afterthought :) It is built around bulkstat which walks all the inodes which is great for dumping them all out. But if you want a small directory walk then you need something else IMHO. Cheers, --Tim From owner-xfs@oss.sgi.com Wed Aug 16 23:36:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 23:36:59 -0700 (PDT) Received: from mail.rentalia.net (mail.rentalia.com [213.192.209.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7H6acDW004070 for ; Wed, 16 Aug 2006 23:36:38 -0700 Received: (qmail 23318 invoked by uid 514); 17 Aug 2006 08:36:08 +0200 Received: from 62.37.216.165 by rigodon (envelope-from , uid 512) with qmail-scanner-1.25-st-qms (clamdscan: 0.88/1284. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:0(62.37.216.165):SA:0(-2.3/5.0):. Processed in 2.359032 secs); 17 Aug 2006 06:36:08 -0000 X-Antivirus-MYDOMAIN-Mail-From: ruben@rentalia.com via rigodon X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:0(62.37.216.165):SA:0(-2.3/5.0):. Processed in 2.359032 secs Process 23307) Received: from 62-37-216-165.mad1.adsl.uni2.es (HELO ?192.168.2.28?) (ruben@rentalia.com@62.37.216.165) by mail.rentalia.net with SMTP; 17 Aug 2006 08:36:06 +0200 Message-ID: <44E40E50.3070708@rentalia.com> Date: Thu, 17 Aug 2006 08:36:00 +0200 From: Ruben Rubio User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Nathan Scott CC: xfs@oss.sgi.com Subject: Re: File problem question References: <44DC44FA.4060401@rentalia.com> <20060814103139.B2698880@wobbly.melbourne.sgi.com> In-Reply-To: <20060814103139.B2698880@wobbly.melbourne.sgi.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 8693 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ruben@rentalia.com Precedence: bulk X-list: xfs Content-Length: 898 Lines: 34 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nathan Scott wrote: > On Fri, Aug 11, 2006 at 10:51:06AM +0200, Ruben Rubio wrote: >> root@rigodon log # pwd >> /var/log >> root@rigodon log # ls -al lastlog >> - -r-------- 1 root root 146292 ago 11 10:44 lastlog >> root@rigodon log # du -sh * | grep lastlog >> 7,6G lastlog > > what does "xfs_bmap -vp lastlog" say? root@rigodon log # xfs_bmap -vp lastlog lastlog: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..279]: hole 280 1: [280..287]: 64537592..64537599 15 (17552..17559) 8 > > cheers. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE5A5QIo1XmbAXRboRApuuAKCEaMWm17e2YWJwbD/sL/aq88+S+wCgpHJi yFtYxP3wzm+7WS7H/Ci94tk= =k8IT -----END PGP SIGNATURE----- From owner-xfs@oss.sgi.com Wed Aug 16 23:36:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 23:36:22 -0700 (PDT) Received: from mail.rentalia.net (mail.rentalia.com [213.192.209.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7H6a5DW003952 for ; Wed, 16 Aug 2006 23:36:06 -0700 Received: (qmail 22348 invoked by uid 514); 17 Aug 2006 08:35:30 +0200 Received: from 62.37.216.165 by rigodon (envelope-from , uid 512) with qmail-scanner-1.25-st-qms (clamdscan: 0.88/1284. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:0(62.37.216.165):SA:0(-2.3/5.0):. Processed in 6.777199 secs); 17 Aug 2006 06:35:30 -0000 X-Antivirus-MYDOMAIN-Mail-From: ruben@rentalia.com via rigodon X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:0(62.37.216.165):SA:0(-2.3/5.0):. Processed in 6.777199 secs Process 22287) Received: from 62-37-216-165.mad1.adsl.uni2.es (HELO ?192.168.2.28?) (ruben@rentalia.com@62.37.216.165) by mail.rentalia.net with SMTP; 17 Aug 2006 08:35:23 +0200 Message-ID: <44E40E25.2090101@rentalia.com> Date: Thu, 17 Aug 2006 08:35:17 +0200 From: Ruben Rubio User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Christian , xfs@oss.sgi.com Subject: Re: File problem question References: <44DC44FA.4060401@rentalia.com> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 8692 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ruben@rentalia.com Precedence: bulk X-list: xfs Content-Length: 1200 Lines: 41 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian wrote: > On Fri, 11 Aug 2006, Ruben Rubio wrote: >> root@rigodon log # ls -al lastlog >> - -r-------- 1 root root 146292 ago 11 10:44 lastlog > ---^ > is that a typo or is there a space in the permission field? This is an error when I did copy/paste > >> I have a file witch size is 7,6 GB. However, if I ls -al is another >> file. Seems like filesystems is being corrupted. > > What does xfs_check say? Which (linux?-)kernel are you using? If you are I did't run xfs_check yet. I have to disconnect the server because I have to unmount the filesystem in orden to run the program (I ll do it after holidays if there is not risk). xfsprogs version: 2.6.13-2 Kernel: 2.6.9-1.667smp Distro: Fedora Core release 3 > about to xfs_*, please make sure you have the *latest* xfsprogs[0], > which is 2.8.10-1 right now... > > Christian. > [0] ftp://oss.sgi.com/projects/xfs/cmd_tars/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE5A4lIo1XmbAXRboRAv6zAJ0TUw3nJZEH+1yyJQROwVduFnkoXwCgsRaU kXjPxH4aFKStRAOWvRaGGw4= =4JFf -----END PGP SIGNATURE----- From owner-xfs@oss.sgi.com Wed Aug 16 23:58:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Aug 2006 23:59:05 -0700 (PDT) Received: from mail.interline.it (mail.interline.it [195.182.241.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7H6wnDW007897 for ; Wed, 16 Aug 2006 23:58:50 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.interline.it (Postfix) with ESMTP id ACC618D8 for ; Thu, 17 Aug 2006 08:52:04 +0200 (CEST) Received: from mail.interline.it ([127.0.0.1]) by localhost (pin [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22051-23 for ; Thu, 17 Aug 2006 08:52:03 +0200 (CEST) Received: from [192.168.1.98] (unknown [88.36.237.170]) by mail.interline.it (Postfix) with ESMTP id EF8408C9 for ; Thu, 17 Aug 2006 08:52:02 +0200 (CEST) From: "Daniele P." Organization: Interline To: xfs@oss.sgi.com Subject: Re: xfsdump -s unacceptable performances Date: Thu, 17 Aug 2006 08:58:11 +0200 User-Agent: KMail/1.9.1 References: <200608161515.00543.daniele@interline.it> <200608162001.10342.daniele@interline.it> <44E3C6D5.2080704@sgi.com> In-Reply-To: <44E3C6D5.2080704@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608170858.11697.daniele@interline.it> X-archive-position: 8694 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: daniele@interline.it Precedence: bulk X-list: xfs Content-Length: 875 Lines: 24 On Thursday 17 August 2006 03:31, you wrote: > Daniele P. wrote: > > But xfsdump still doesn't scale down well with a small subtree on a > > large filesystem. > > That is very true. > It is really designed for dumping whole filesystems (or at least, > large parts of them). > For dumping small subtrees, I'd be looking at using something else. Hi Timothy, Yes, you are right, but there is another problem on my side. The /small/ subtree of the filesystem usually contains a lot of hard links (our backup software uses hard links to save disk space, so expect one hard link per file per day) and using a generic tool like tar/star or rsync that uses "stat" to scan the filesysem should be significant slower (no test done) than a native tool like xfsdump, as Bill in a previous email pointed out. It seems that there isn't a right tool for this job. Regards, Daniele From owner-xfs@oss.sgi.com Thu Aug 17 00:45:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Aug 2006 00:46:13 -0700 (PDT) Received: from mail.rentalia.net (mail.rentalia.com [213.192.209.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7H7jwDW021302 for ; Thu, 17 Aug 2006 00:45:59 -0700 Received: (qmail 30517 invoked by uid 514); 17 Aug 2006 09:45:28 +0200 Received: from 62.37.216.165 by rigodon (envelope-from , uid 512) with qmail-scanner-1.25-st-qms (clamdscan: 0.88/1284. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:0(62.37.216.165):SA:0(-2.3/5.0):. Processed in 5.408183 secs); 17 Aug 2006 07:45:28 -0000 X-Antivirus-MYDOMAIN-Mail-From: ruben@rentalia.com via rigodon X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:0(62.37.216.165):SA:0(-2.3/5.0):. Processed in 5.408183 secs Process 30496) Received: from 62-37-216-165.mad1.adsl.uni2.es (HELO ?192.168.2.28?) (ruben@rentalia.com@62.37.216.165) by mail.rentalia.net with SMTP; 17 Aug 2006 09:45:23 +0200 Message-ID: <44E41E8D.6030105@rentalia.com> Date: Thu, 17 Aug 2006 09:45:17 +0200 From: Ruben Rubio User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: File problem question References: <44DC44FA.4060401@rentalia.com> <20060814103139.B2698880@wobbly.melbourne.sgi.com> <44E40E50.3070708@rentalia.com> In-Reply-To: <44E40E50.3070708@rentalia.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 8695 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ruben@rentalia.com Precedence: bulk X-list: xfs Content-Length: 522 Lines: 22 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think I have found the response. lastlog is a special "sparse file". When du -sh command is executed, the space that shows is unreal. ls -al shows the good one disk usage. Then, all seems is normal. Thanks anyway! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE5B6NIo1XmbAXRboRAv0SAJ4heBkyh4yavO6Wd4S+H8pAXgR9cQCeJY+0 2W9+TU3/Mf6HQAuwVFNpJ+w= =d3Cp -----END PGP SIGNATURE----- From owner-xfs@oss.sgi.com Thu Aug 17 01:47:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Aug 2006 01:48:01 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7H8lcDW030841 for ; Thu, 17 Aug 2006 01:47:39 -0700 Received: by nf-out-0910.google.com with SMTP id a25so1008931nfc for ; Thu, 17 Aug 2006 01:47:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O4DcHuARUY0tsLtHVKYXiT2bp5g7nLNNoc14xUA+3vRJW9234R0uca54cXyuRl72d6Qg9hq/324kZjAnbMjy2KosmJif23gx0FhKQnGDISduOYTyxvzAy21yP5qrkGU7hWMO16IRHqIv79pMUwEyfgKvvuGY1jD2Os7vTZxl4e4= Received: by 10.49.55.13 with SMTP id h13mr1940389nfk; Thu, 17 Aug 2006 01:47:07 -0700 (PDT) Received: by 10.78.161.18 with HTTP; Thu, 17 Aug 2006 01:47:07 -0700 (PDT) Message-ID: <9a8748490608170147o7bc9a457ud3e0a6729444c27e@mail.gmail.com> Date: Thu, 17 Aug 2006 10:47:07 +0200 From: "Jesper Juhl" To: "Nathan Scott" Subject: Re: 'fbno' possibly used uninitialized in xfs_alloc_ag_vextent_small() Cc: linux-kernel@vger.kernel.org, xfs-masters@oss.sgi.com, xfs@oss.sgi.com In-Reply-To: <20060817084111.A2787212@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200608162327.34420.jesper.juhl@gmail.com> <20060817084111.A2787212@wobbly.melbourne.sgi.com> X-archive-position: 8696 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jesper.juhl@gmail.com Precedence: bulk X-list: xfs Content-Length: 1362 Lines: 33 On 17/08/06, Nathan Scott wrote: > Hi Jesper, > > On Wed, Aug 16, 2006 at 11:27:34PM +0200, Jesper Juhl wrote: > > (Please keep me on Cc since I'm not subscribed to the XFS lists) > > > > The coverity checker found what looks to me like a valid case of > > potentially uninitialized variable use (see below). > > It looks invalid, but its not, once again. To understand why this > isn't a problem requires looking at the xfs_alloc_ag_vextent_small > call sites (there's only two). If (*flen==0) is passed back out, > then the value in *fbno is discarded, always. > > > So basically, if we hit the 'else' branch, then 'fbno' has not been > > initialized and line 1490 will then use that uninitialized variable. > > > > What would prevent that from happening at some time?? > > Nothing. But its not a problem in practice. However, that final > else branch is very much unlikely, so theres no real cost to just > initialising the local fbno to NULLAGBLOCK in that branch, and we > future proof ourselves a bit that way I guess (in case the callers > ever change - pretty unlikely, but we may as well). How does the > patch below look to you? > Looks good to me. -- Jesper Juhl Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html From owner-xfs@oss.sgi.com Thu Aug 17 07:16:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Aug 2006 07:16:57 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7HEGgDW019547 for ; Thu, 17 Aug 2006 07:16:43 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1GDh0V-0000om-Re for ; Thu, 17 Aug 2006 13:29:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17636.24895.74010.977829@base.ty.sabi.co.UK> Date: Thu, 17 Aug 2006 13:29:51 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: xfsdump -s unacceptable performances In-Reply-To: <200608170858.11697.daniele@interline.it> References: <200608161515.00543.daniele@interline.it> <200608162001.10342.daniele@interline.it> <44E3C6D5.2080704@sgi.com> <200608170858.11697.daniele@interline.it> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 8697 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 2064 Lines: 57 >>> On Thu, 17 Aug 2006 08:58:11 +0200, "Daniele P." >>> said: [ ... ] daniele> Hi Timothy, Yes, you are right, but there is another daniele> problem on my side. The /small/ subtree of the daniele> filesystem usually contains a lot of hard links (our daniele> backup software Given the context, I would imagine that this backup filesystem is stored on a RAID5 device... Is it? It can be an important part of the strategy. daniele> uses hard links to save disk space, so expect one hard daniele> link per file per day) and using a generic tool like daniele> tar/star or rsync that uses "stat" to scan the daniele> filesysem should be significant slower (no test done) daniele> than a native tool like xfsdump, as Bill in a previous daniele> email pointed out. Depends a lot, for example on whether the system has enough RAM to cache the inodes affected, and anyhow on the ratio between inodes in the subtree and inodes in the whole filesystem. As to this case: deniale> Dumping one directory with 4 file using 4KB of deniale> space takes hours (or days, it hasn't finished yet) deniale> if the underlying filesystem contains around deniale> 10.000.000 inodes. probably using 'tar'/'star' may be a bit faster... daniele> It seems that there isn't a right tool for this job. Or perhaps it is not the right job :-). Anyhow sequential scans of large filesystems are not an awesome idea in general. I wonder how long and how much RAM your 10m inode filesystem will take to 'fsck' for example :-), perhaps you don't want to read this older entry in this mailing list: http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00045.html The basic problem is that the bottleneck is the ''pickup'' and its speed has not grown as fast as disc capacity, so one has to do RAID to work around that, but RAID delivers only for parallel, not sequential, scans of the filesystem. A significant issue that nobody seems in a hurry to address. As a recent ''contributor'' to this list wrote: > hope i never need to run repair, :-) From owner-xfs@oss.sgi.com Thu Aug 17 14:24:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Aug 2006 14:24:38 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7HLOBDW004579 for ; Thu, 17 Aug 2006 14:24:13 -0700 Received: by nf-out-0910.google.com with SMTP id a25so1194015nfc for ; Thu, 17 Aug 2006 14:23:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Henuhd8bEfBM5fohFEUqsDiHq8N7AGxDvbILUz6lKpLJRZ0ptcjlwQBaU8O6iVLxCa+84dVU559qPR0ai6CwE0UH7b1tO488vAYafF3OPtDZyrLiQ6LHjRfBW9F5tED3by0dZgN+aFJ1eyw62/b67B02i/hEN4hBDYAK/6e2tfY= Received: by 10.49.20.5 with SMTP id x5mr2834319nfi; Thu, 17 Aug 2006 14:23:39 -0700 (PDT) Received: by 10.78.161.18 with HTTP; Thu, 17 Aug 2006 14:23:39 -0700 (PDT) Message-ID: <9a8748490608171423w3e5f7007nf92fad74637f0dd3@mail.gmail.com> Date: Thu, 17 Aug 2006 23:23:39 +0200 From: "Jesper Juhl" To: "Nathan Scott" Subject: Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078 Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20060816112630.C2756824@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9a8748490608100431m244207b1v9c9c5087233fcf3a@mail.gmail.com> <9a8748490608101544n29f863e7o7584ac64f1d4c210@mail.gmail.com> <9a8748490608101552w12822fa6m415a5fb5537c744d@mail.gmail.com> <9a8748490608110133v5f973cf6w1af340f59bb229ec@mail.gmail.com> <9a8748490608110325k25c340e2yac925eb226d1fe4f@mail.gmail.com> <20060814120032.E2698880@wobbly.melbourne.sgi.com> <9a8748490608140049t492742cx7f826a9f40835d71@mail.gmail.com> <20060815190343.A2743401@wobbly.melbourne.sgi.com> <9a8748490608150442q4ad7a835r53400e9880da3175@mail.gmail.com> <20060816112630.C2756824@wobbly.melbourne.sgi.com> X-archive-position: 8698 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jesper.juhl@gmail.com Precedence: bulk X-list: xfs Content-Length: 1566 Lines: 39 On 16/08/06, Nathan Scott wrote: > On Tue, Aug 15, 2006 at 01:42:27PM +0200, Jesper Juhl wrote: > > On 15/08/06, Nathan Scott wrote: > > > If you can get the source > > > and target names in the rename that'll help alot too... I can > > > explain how to use KDB to get that, but maybe you have another > > > debugger handy already? > > > > > An explanation of how exactely to do that would be greatly appreciated. > > - patch in KDB > - echo 127 > /proc/sys/fs/xfs/panic_mask > [ filesystem shutdown now == panic ] > - kdb> bt > [ pick out parameters to rename from the backtrace ] > - kdb> md 0xXXX > [ gives a memory dump of the pointers to pathnames ] > Thanks a lot for the explanation. Unfortunately I didn't get a chance to run new tests on the server this week (always the big problem when it's a production machine). I'm also going on a short vacation, so I won't have the oppotunity to try and recreate a simpler test case at home for the next few days. When I get back (in some 4 days time) I'll try to build a more simple test case and in about a week or so I hopefully will get a new chance to run new tests on the server that has so far shown the problem. If there are additional tests you want me to run or data you want me to collect, then let me know and I'll do so the first chance I get. I'll be back in touch in ~1 weeks time. -- Jesper Juhl Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html From owner-xfs@oss.sgi.com Thu Aug 17 17:10:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Aug 2006 17:10:59 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7I0AADW026171 for ; Thu, 17 Aug 2006 17:10:24 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14855; Fri, 18 Aug 2006 10:09:26 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 57EF958C8A48; Fri, 18 Aug 2006 10:09:26 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 955515 - realtime growfs Message-Id: <20060818000926.57EF958C8A48@chook.melbourne.sgi.com> Date: Fri, 18 Aug 2006 10:09:26 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8700 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 770 Lines: 18 Fix a porting botch on the realtime subvol growfs code path. Date: Fri Aug 18 10:08:56 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26806a xfs_rtalloc.c - 1.103 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.c.diff?r1=text&tr1=1.103&r2=text&tr2=1.102&f=h linux-2.6/xfs_linux.h - 1.150 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.150&r2=text&tr2=1.149&f=h linux-2.4/xfs_linux.h - 1.161 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.161&r2=text&tr2=1.160&f=h From owner-xfs@oss.sgi.com Thu Aug 17 17:05:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Aug 2006 17:06:00 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7I05MDW025665 for ; Thu, 17 Aug 2006 17:05:34 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14763; Fri, 18 Aug 2006 10:04:36 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 2DEEA58C8A48; Fri, 18 Aug 2006 10:04:36 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 955302 - misc cleanup Message-Id: <20060818000436.2DEEA58C8A48@chook.melbourne.sgi.com> Date: Fri, 18 Aug 2006 10:04:36 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8699 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 5390 Lines: 116 Add a debug flag for allocations which are known to be larger than one page. Date: Fri Aug 18 09:41:40 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26800a xfs_log.c - 1.326 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.326&r2=text&tr2=1.325&f=h xfs_iget.c - 1.218 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.218&r2=text&tr2=1.217&f=h support/ktrace.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/ktrace.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h quota/xfs_qm.c - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h linux-2.6/xfs_buf.c - 1.225 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.225&r2=text&tr2=1.224&f=h linux-2.6/kmem.h - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/kmem.h.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h linux-2.4/xfs_buf.c - 1.217 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.c.diff?r1=text&tr1=1.217&r2=text&tr2=1.216&f=h linux-2.4/kmem.h - 1.33 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/kmem.h.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h linux-2.4/kmem.c - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/kmem.c.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h linux-2.6/kmem.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/kmem.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h Improve error handling for the zero-fsblock extent detection code. Date: Fri Aug 18 09:51:19 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: dgc,gwehrman,nb The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26802a xfs_error.h - 1.45 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h xfs_bmap.c - 1.357 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.357&r2=text&tr2=1.356&f=h xfs_iomap.c - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h linux-2.6/xfs_globals.c - 1.69 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_globals.c.diff?r1=text&tr1=1.69&r2=text&tr2=1.68&f=h linux-2.4/xfs_globals.c - 1.77 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_globals.c.diff?r1=text&tr1=1.77&r2=text&tr2=1.76&f=h Add a greedy allocation interface, allocating within a min/max size range. Date: Fri Aug 18 09:53:31 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch,cw The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26803a xfs_itable.c - 1.145 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.145&r2=text&tr2=1.144&f=h xfs_iget.c - 1.219 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.219&r2=text&tr2=1.218&f=h quota/xfs_qm.c - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h linux-2.6/kmem.h - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/kmem.h.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h linux-2.4/kmem.h - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/kmem.h.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h linux-2.4/kmem.c - 1.37 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/kmem.c.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h linux-2.6/kmem.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/kmem.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h Remove a no-longer-correct debug assert from dio completion handling. Date: Fri Aug 18 09:58:13 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: zach.brown@oracle.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26804a linux-2.6/xfs_aops.c - 1.133 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.133&r2=text&tr2=1.132&f=h Minor code rearranging and cleanup to prevent some coverity false positives. Date: Fri Aug 18 10:02:34 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen,jesper.juhl@gmail.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26805a xfs_da_btree.c - 1.172 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.172&r2=text&tr2=1.171&f=h xfs_rtalloc.c - 1.102 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.c.diff?r1=text&tr1=1.102&r2=text&tr2=1.101&f=h xfs_alloc.c - 1.184 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.184&r2=text&tr2=1.183&f=h From owner-xfs@oss.sgi.com Thu Aug 17 17:13:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Aug 2006 17:14:15 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7I0DdDW026794 for ; Thu, 17 Aug 2006 17:13:50 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14920; Fri, 18 Aug 2006 10:12:40 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 215B958C8A48; Fri, 18 Aug 2006 10:12:40 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 954580 - sparse checks for AIL locking Message-Id: <20060818001240.215B958C8A48@chook.melbourne.sgi.com> Date: Fri, 18 Aug 2006 10:12:40 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8701 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1216 Lines: 29 Add lock annotations to xfs_trans_update_ail and xfs_trans_delete_ail xfs_trans_update_ail and xfs_trans_delete_ail get called with the AIL lock held, and release it. Add lock annotations to these two functions so that sparse can check callers for lock pairing, and so that sparse will not complain about these functions since they intentionally use locks in this manner. Signed-off-by: Josh Triplett Date: Fri Aug 18 10:12:23 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: josh@freedesktop.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26807a xfs_trans_priv.h - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_priv.h.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfs_trans_ail.c - 1.79 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_ail.c.diff?r1=text&tr1=1.79&r2=text&tr2=1.78&f=h linux-2.4/xfs_linux.h - 1.162 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.162&r2=text&tr2=1.161&f=h - Add lock annotations to xfs_trans_update_ail and xfs_trans_delete_ail From owner-xfs@oss.sgi.com Thu Aug 17 18:09:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Aug 2006 18:09:34 -0700 (PDT) Received: from gateway-1237.mvista.com (gateway-1237.mvista.com [63.81.120.158]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7I19HDW032474 for ; Thu, 17 Aug 2006 18:09:19 -0700 Received: from mvista.local (svexch01.mvista.com [10.0.0.82]) by hermes.mvista.com (Postfix) with ESMTP id A18A91B9CE for ; Thu, 17 Aug 2006 17:07:25 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6C25A.4932E3DD" Subject: ltp filesystem ftests failing under xfs partition Date: Thu, 17 Aug 2006 17:07:24 -0700 Message-ID: <517DC3FCCF3D8D42BEF1F83F7A633FA85D84D5@svexch01.mvista.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ltp filesystem ftests failing under xfs partition Thread-Index: AcbCWkhh7xt6gFV6Soe7Gu7yi4yPUA== From: "Henry Yei" To: X-archive-position: 8702 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hyei@mvista.com Precedence: bulk X-list: xfs Content-Length: 29601 Lines: 622 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C25A.4932E3DD Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6C25A.4932E3DD" ------_=_NextPart_002_01C6C25A.4932E3DD Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello all, =20 I am seeing sporadic failures of ftest01, ftest03, ftest05, and ftest07 under the xfs filesystem with kernel 2.6.10. I've seen this across many architectures including x86_586. Have there been any reports of this? The tests seem to fail very often when run with the entire ltp filesystem test suite, but also fails when the individual test is run by itself in a loop. =20 This test has seen no failures, in ext2, ext3, jfs, tmpfs, ramfs partitions. =20 [Example of output] ftest05 1 FAIL : Test[4]: fsync error 5. ftest05 1 FAIL : Test{3882} failed, expected 0 exit. ftest05 2 FAIL : Test failed. =20 My test setup is a 100MB xfs filesystem on a loopback device which is situated on a NFS root filesystem. The ftests also fail on a physical xfs partition. =20 The test attached was run 51 times, and 6 failures were observed when calling fsync. =20 I've attached the source to ftest01. =20 =20 =20 Henry Yei MontaVista Software, Inc. hyei@mvista.com =20 =20 =20 ------_=_NextPart_002_01C6C25A.4932E3DD Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I am seeing sporadic failures of ftest01, ftest03, ftest= 05, and ftest07 under the xfs filesystem with kernel 2.6.10. I’ve seen th= is across many architectures including x86_586. Have there been any reports of this?  The tests seem to fail very often when run with the entire ltp filesystem test suite, but also fails when the individual test is run by it= self in a loop.

 

This test has seen no failures, in ext2, ext3, jfs, tmpf= s, ramfs partitions.

 

[Example of output]

ftest05     1  FAIL  :&nbs= p;       Test[4]: fsync error 5.

ftest05     1  FAIL  :&nbs= p;       Test{3882} failed, expected 0 exit.

ftest05     2  FAIL  :&nbs= p;       Test failed.

 

My test setup is a 100MB xfs filesystem on a loopback de= vice which is situated on a NFS root filesystem.

The ftests also fail on a physical xfs partition.

 

The test attached was run 51 times, and 6 failures were observed when calling fsync.

 

I’ve attached the source to ftest01.

 

 

 

Henry Yei

MontaVista Software, Inc.

hyei@mvista.com

 

 

 

------_=_NextPart_002_01C6C25A.4932E3DD-- ------_=_NextPart_001_01C6C25A.4932E3DD Content-Type: application/octet-stream; name="ftest01-081506.c" Content-Transfer-Encoding: base64 Content-Description: ftest01-081506.c Content-Disposition: attachment; filename="ftest01-081506.c" LyoNCiAqDQogKiAgIENvcHlyaWdodCAoYykgSW50ZXJuYXRpb25hbCBCdXNp bmVzcyBNYWNoaW5lcyAgQ29ycC4sIDIwMDINCiAqDQogKiAgIFRoaXMgcHJv Z3JhbSBpcyBmcmVlIHNvZnR3YXJlOyAgeW91IGNhbiByZWRpc3RyaWJ1dGUg aXQgYW5kL29yIG1vZGlmeQ0KICogICBpdCB1bmRlciB0aGUgdGVybXMgb2Yg dGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBi eQ0KICogICB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIg dmVyc2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcg0KICogICAoYXQgeW91ciBv cHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KICoNCiAqICAgVGhpcyBwcm9n cmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBi ZSB1c2VmdWwsDQogKiAgIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgIHdp dGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KICogICBNRVJD SEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBP U0UuICBTZWUNCiAqICAgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl IGZvciBtb3JlIGRldGFpbHMuDQogKg0KICogICBZb3Ugc2hvdWxkIGhhdmUg cmVjZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj ZW5zZQ0KICogICBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgIGlmIG5vdCwg d3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUNCiAqICAgRm91bmRhdGlvbiwg SW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEg MDIxMTEtMTMwNyBVU0ENCiAqLw0KDQovKg0KICogTkFNRQ0KICoJZnRlc3Qw MS5jIC0tIHRlc3QgZmlsZSBJL08gKHBvcnRlZCBmcm9tIFNQSUUgc2VjdGlv bjIsIGZpbGVzdWl0ZSwgYnkgQWlyb25nIFpoYW5nKQ0KICoNCiAqIENBTExT DQogKglsc2VlaywgcmVhZCwgd3JpdGUNCiAqCXRydW5jYXRlLCBmdHJ1bmNh dGUsIGZzeW5jLCBzeW5jLCBmc3RhdA0KICoNCiAqIEFMR09SSVRITQ0KICoJ QSBiaXRtYXAgaXMgdXNlZCB0byBtYXAgcGllY2VzIG9mIGEgZmlsZS4NCiAq ICAgICAgTG9vcDogcGljayBhIHJhbmRvbSBwaWVjZSBvZiB0aGUgZmlsZQ0K ICogICAgICAgICAgICBpZiB3ZSBoYXZlbid0IHNlZW4gaXQgYmVmb3JlIG1h a2Ugc3VyZSBpdCBpcyB6ZXJvLA0KICogICAgICAgICAgICB3cml0ZSBwYXR0 ZXJuDQogKiAgICAgICAgICAgIGlmIHdlIGhhdmUgc2VlbiBpdCBiZWZvcmUg bWFrZSBzdXJlIGNvcnJlY3QgcGF0dGVybi4NCiAqDQogKiAgICAgIFRoaXMg d2FzIG9yaWdpbmFsbHkgd3JpdHRlbiBieSByYmsgLSB3YXMgcHJvZ3JhbSB0 ZmlvLmMNCiAqCU1vZGlmaWVkIGJ5IGRhbGUgdG8gaW50ZWdyYXRlIHdpdGgg dGVzdCBzdWl0ZXMuDQogKg0KICogUkVTVFJJQ1RJT05TDQogKglSdW5zIGEg bG9uZyB0aW1lIHdpdGggZGVmYXVsdCBhcmdzIC0gY2FuIHRha2Ugb3RoZXJz IG9uIGlucHV0DQogKglsaW5lLiAgVXNlIHdpdGggInRlcm0gbW9kZSIuDQog KglJZiBydW4gb24gdmF4IHRoZSBmdHJ1bmNhdGUgd2lsbCBub3QgYmUgcmFu ZG9tIC0gd2lsbCBhbHdheXMgZ28gdG8NCiAqCXN0YXJ0IG9mIGZpbGUuICBO T1RFOiBwcm9kdWNlcyBhIHZlcnkgaGlnaCBsb2FkIGF2ZXJhZ2UhIQ0KICoN CiAqIENBVVRJT04hIQ0KICoJSWYgYSBmaWxlIGlzIHN1cHBsaWVkIHRvIHRo aXMgcHJvZ3JhbSB3aXRoIHRoZSAiLWYiIG9wdGlvbg0KICoJaXQgd2lsbCBi ZSByZW1vdmVkIHdpdGggYSBzeXN0ZW0oInJtIC1yZiBmaWxlbmFtZSIpIGNh bGwuDQogKgkNCiAqLw0KI2RlZmluZSBfR05VX1NPVVJDRSAxDQojaW5jbHVk ZSA8c3RkaW8uaD4JCS8qIG5lZWRlZCBieSB0ZXN0aGVhZC5oCQkqLw0KI2lu Y2x1ZGUgPHN5cy90eXBlcy5oPg0KI2luY2x1ZGUgPHN5cy93YWl0Lmg+DQoj aW5jbHVkZSA8c3lzL3N0YXQuaD4NCiNpbmNsdWRlIDxlcnJuby5oPg0KI2lu Y2x1ZGUgPGZjbnRsLmg+DQojaW5jbHVkZSA8c2lnbmFsLmg+CQkvKiBERU0g LSBhZGRlZCBTSUdURVJNIHN1cHBvcnQgKi8NCiNpbmNsdWRlIDx1bmlzdGQu aD4NCiNpbmNsdWRlICJ0ZXN0LmgiDQojaW5jbHVkZSAidXNjdGVzdC5oIg0K DQpjaGFyICpUQ0lEID0gImZ0ZXN0MDEiOw0KaW50IFRTVF9UT1RBTCA9IDE7 DQpleHRlcm4gaW50IFRzdF9jb3VudDsNCg0Kdm9pZCBzZXR1cCh2b2lkKTsN CmludCBydW50ZXN0KCk7DQppbnQgZG90ZXN0KGludCwgaW50LCBpbnQpOw0K aW50IGRvbWlzYyhpbnQsIGludCwgY2hhciopOw0KaW50IGJmaWxsKGNoYXIq LCBjaGFyLCBpbnQpOw0KaW50IGR1bXBidWYoY2hhciopOw0KaW50IGR1bXBi aXRzKGNoYXIqLCBpbnQpOw0KaW50IG9yYml0cyhjaGFyKiwgY2hhciosIGlu dCk7DQp2b2lkIHRlcm0oKTsNCnZvaWQgY2xlYW51cCh2b2lkKTsNCg0KI2Rl ZmluZSBQQVNTRUQgMQ0KI2RlZmluZSBGQUlMRUQgMA0KDQojZGVmaW5lIE1B WENISUxECTI1CS8qIG1heCBudW1iZXIgb2YgY2hpbGRyZW4gdG8gYWxsb3cg Ki8NCiNkZWZpbmUgS18xCQkxMDI0DQojZGVmaW5lIEtfMgkJMjA0OA0KI2Rl ZmluZSBLXzQJCTQwOTYNCg0KY2hhciBwcm9nbmFtZVtdPSAiZnRlc3QxKCki OwkvKiByZXBsYWNlICsrIHdpdGggdGVzdCBuYW1lCSovDQoNCmludAljc2l6 ZTsJCQkJLyogY2h1bmsgc2l6ZSAqLw0KaW50CWl0ZXJhdGlvbnM7CQkJLyog IyB0b3RhbCBpdGVyYXRpb25zICovDQppbnQJbWF4X3NpemU7CQkJLyogbWF4 IGZpbGUgc2l6ZSAqLw0KaW50CW1pc2NfaW50dmw7CQkJLyogZm9yIGRvaW5n IG1pc2MgdGhpbmdzOyAwID09PiBubyAqLw0KaW50CW5jaGlsZDsJCQkJLyog aG93IG1hbnkgY2hpbGRyZW4gKi8NCmludAlud2FpdDsNCmludAlmZDsJCQkJ LyogZmlsZSBkZXNjcmlwdG9yIHVzZWQgYnkgY2hpbGQgKi8NCmludAlwYXJl bnRfcGlkOw0KaW50CXBpZGxpc3RbTUFYQ0hJTERdOw0KY2hhcgl0ZXN0X25h bWVbMl07CQkJLyogY2hpbGRzIHRlc3QgZGlyZWN0b3J5IG5hbWUgKi8NCmNo YXIJKnByb2c7DQoNCmNoYXIJZnVzc1s0MF0gPSAiIjsJCS8qIGRpcmVjdG9y eSB0byBkbyB0aGlzIGluICovDQpjaGFyCWhvbWVkaXJbMjAwXT0gIiI7CS8q IHdoZXJlIHdlIHN0YXJ0ZWQgKi8NCg0KaW50IAlsb2NhbF9mbGFnOw0KDQov Ki0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKi8NCmludCBtYWluIChhYywgYXYpDQoJaW50 ICBhYzsNCgljaGFyICphdltdOw0Kew0KCWludCBsYzsgICAgICAgICAgICAg ICAgIC8qIGxvb3AgY291bnRlciAqLw0KICAgICAgICBjaGFyICptc2c7ICAg ICAgICAgICAgICAvKiBtZXNzYWdlIHJldHVybmVkIGZyb20gcGFyc2Vfb3B0 cyAqLw0KDQogICAgICAgIC8qDQogICAgICAgICAqIHBhcnNlIHN0YW5kYXJk IG9wdGlvbnMNCiAgICAgICAgICovDQogICAgICAgIGlmICgobXNnID0gcGFy c2Vfb3B0cyhhYywgYXYsIChvcHRpb25fdCAqKU5VTEwsIE5VTEwpKSAhPSAo Y2hhciAqKU5VTEwpew0KICAgICAgICAgICAgICAgIHRzdF9icmttKFRCUk9L LCBjbGVhbnVwLCAiT1BUSU9OIFBBUlNJTkcgRVJST1IgLSAlcyIsIG1zZyk7 DQoJICAgICAgICAgICAgICAgIC8qTk9UUkVBQ0hFRCovDQogICAgICAgIH0N Cg0KCXNldHVwKCk7DQoNCglmb3IgKGxjID0gMDsgVEVTVF9MT09QSU5HKGxj KTsgbGMrKykgew0KDQoJCXJ1bnRlc3QoKTsNCg0KCQlpZiAobG9jYWxfZmxh ZyA9PSBQQVNTRUQpIHsNCgkJCXRzdF9yZXNtKFRQQVNTLCAiVGVzdCBwYXNz ZWQuIik7DQoJCX0gZWxzZSB7DQoJCQl0c3RfcmVzbShURkFJTCwgIlRlc3Qg ZmFpbGVkLiIpOw0KCQl9DQoJfSAvKiBlbmQgb2YgZm9yICovDQoJY2xlYW51 cCgpOw0KCXJldHVybigwKTsNCn0NCi8qLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0qLw0K DQoNCnZvaWQNCnNldHVwKCkNCnsNCg0KCS8qDQoJICogTWFrZSBhIGRpcmVj dG9yeSB0byBkbyB0aGlzIGluOyBpZ25vcmUgZXJyb3IgaWYgYWxyZWFkeSBl eGlzdHMuDQoJICogU2F2ZSBzdGFydGluZyBkaXJlY3RvcnkuDQoJICovDQoJ dHN0X3RtcGRpcigpOw0KCWdldGN3ZChob21lZGlyLCBzaXplb2YoIGhvbWVk aXIpKTsNCglwYXJlbnRfcGlkID0gZ2V0cGlkKCk7DQoNCglpZiAoIWZ1c3Nb MF0pDQoJCXNwcmludGYoZnVzcywgIi4vZnRlc3QxLiVkIiwgZ2V0cGlkKCkp Ow0KDQoJbWtkaXIoZnVzcywgMDc1NSk7DQoNCglpZiAoY2hkaXIoZnVzcykg PCAwKSB7DQoJCXRzdF9icmttKFRCUk9LLDAsIkNhbid0IGNoZGlyKCVzKTog JXMiLCBmdXNzLCBzdHJlcnJvcihlcnJubykpOw0KCX0NCg0KCSAvKg0KCSAg KiBEZWZhdWx0IHZhbHVlcyBmb3IgcnVuIGNvbmRpdGlvbnMuDQoJICAqLw0K DQoJaXRlcmF0aW9ucyA9IDEwOw0KCW5jaGlsZCA9IDU7DQoJY3NpemUgPSBL XzI7ICAgICAgICAgICAgLyogc2hvdWxkIHJ1biB3aXRoIDEsIDIsIGFuZCA0 IEsgc2l6ZXMgKi8NCgltYXhfc2l6ZSA9IEtfMSAqIEtfMTsNCgltaXNjX2lu dHZsID0gMTA7DQoNCglpZiAoKHNpZ3NldChTSUdURVJNLCAodm9pZCAoKiko KSl0ZXJtKSkgPT0gU0lHX0VSUikgew0KCQl0c3RfcmVzbShUQlJPSywic2ln c2V0IGZhaWxlZDogJXMiLCBzdHJlcnJvcihlcnJubykpOw0KCSAgICAgICAg dHN0X2V4aXQoKTsNCgl9DQoNCglsb2NhbF9mbGFnID0gUEFTU0VEOw0KfQ0K DQoNCmludCBydW50ZXN0KCkNCnsNCglyZWdpc3RlciBpbnQgaTsNCglpbnQJ cGlkOw0KCWludAljaGlsZDsNCglpbnQJc3RhdHVzOw0KCWludAljb3VudDsN Cg0KDQoNCglmb3IoaSA9IDA7IGkgPCBuY2hpbGQ7IGkrKykgew0KCQl0ZXN0 X25hbWVbMF0gPSAnYScgKyBpOw0KCQl0ZXN0X25hbWVbMV0gPSAnXDAnOw0K CQlmZCA9IG9wZW4odGVzdF9uYW1lLCBPX1JEV1J8T19DUkVBVHxPX1RSVU5D LCAwNjY2KTsNCgkJaWYgKGZkIDwgMCkgew0KCQkJdHN0X2Jya20oVEJST0ss MCwgIkNhbid0IGNyZWF0aW5nICVzLyVzOiAlcyIsIGZ1c3MsIHRlc3RfbmFt ZSwgc3RyZXJyb3IoZXJybm8pKTsNCgkJfQ0KCQlpZiAoKGNoaWxkID0gZm9y aygpKSA9PSAwKSB7CQkvKiBjaGlsZCAqLw0KCQkJZG90ZXN0KG5jaGlsZCwg aSwgZmQpOwkJLyogZG8gaXQhICovDQoJCQlleGl0KDApOwkJCS8qIHdoZW4g ZG9uZSwgZXhpdCAqLw0KCQl9DQoJCWNsb3NlKGZkKTsNCgkJaWYgKGNoaWxk IDwgMCkgew0KCQkJIHRzdF9yZXNtKFRJTkZPLCAiU3lzdGVtIHJlc291cmNl IG1heSBiZSB0b28gbG93LCBmb3JrKCkgbWFsbG9jKCkiDQoJCQkJICAiIGV0 YyBhcmUgbGlrZWx5IHRvIGZhaWwuIik7DQoJCQkgdHN0X3Jlc20oVEJST0ss ICJUZXN0IGJyb2tlbiBkdWUgdG8gaW5hYmlsaXR5IG9mIGZvcmsuIik7DQoJ CQkgdHN0X2V4aXQoKTsNCgkJfSBlbHNlIHsNCgkJCXBpZGxpc3RbaV0gPSBj aGlsZDsNCgkJCW53YWl0Kys7DQoJCX0NCgl9DQoNCgkvKg0KCSAqIFdhaXQg Zm9yIGNoaWxkcmVuIHRvIGZpbmlzaC4NCgkgKi8NCg0KCWNvdW50ID0gMDsN Cgl3aGlsZSgxKQ0KCXsNCgkJaWYgKChjaGlsZCA9IHdhaXQoJnN0YXR1cykp ID49IDApIHsNCgkJCWlmIChXSUZFWElURUQoc3RhdHVzKSkgew0KICAgICAg ICAgICAgICAgICAgICAgICAgCWlmIChXRVhJVFNUQVRVUyhzdGF0dXMpKSB7 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAl0c3RfcmVzbShU RkFJTCwgIlRlc3RbJWRdIGZhaWxlZCwgZXhwZWN0ZWQgMCBleGl0LCBleGl0 ZWQgd2l0aCAlZCIsIGNoaWxkLCBXRVhJVFNUQVRVUyhzdGF0dXMpKTsNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCWxvY2FsX2ZsYWcgPSBG QUlMRUQ7DQoJCQkJfQ0KCQkJfQ0KCQkJZWxzZSB7DQoJCQkJdHN0X3Jlc20o VEZBSUwsICJUZXN0WyVkXSBmYWlsZWQsIGNoaWxkIGV4aXRlZCBhYm5vcm1h bGx5IiwgY2hpbGQpOw0KCQkJCWxvY2FsX2ZsYWcgPSBGQUlMRUQ7DQoJCQl9 DQoJCQkrK2NvdW50Ow0KCQl9DQoJCWVsc2UNCgkJew0KCQkJaWYgKGVycm5v ICE9IEVJTlRSKQ0KCQkJCWJyZWFrOw0KCQl9DQoJfQ0KDQoJLyoNCgkgKiBT aG91bGQgaGF2ZSBjb2xsZWN0ZWQgYWxsIGNoaWxkcmVuLg0KCSAqLw0KDQoJ aWYgKGNvdW50ICE9IG53YWl0KSB7DQoJCXRzdF9yZXNtKFRGQUlMLCAiV3Jv bmcgIyBjaGlsZHJlbiB3YWl0ZWQgb24sIGNvdW50ID0gJWQiLCBjb3VudCk7 DQoJCWxvY2FsX2ZsYWcgPSBGQUlMRUQ7DQoJfQ0KDQoJaWYgKGxvY2FsX2Zs YWcgPT0gUEFTU0VEKSB7DQoJCXRzdF9yZXNtKFRQQVNTLCAiVGVzdCBwYXNz ZWQgaW4gZm9yayBhbmQgd2FpdC4iKTsNCgl9IGVsc2Ugew0KCQl0c3RfcmVz bShURkFJTCwgIlRlc3QgZmFpbGVkIGluIGZvcmsgYW5kIHdhaXQuIik7DQoJ fQ0KDQoJY2hkaXIoaG9tZWRpcik7DQoJcGlkID0gZm9yaygpOw0KCWlmIChw aWQgPCAwKSB7DQoNCgkJdHN0X3Jlc20oVElORk8sICJTeXN0ZW0gcmVzb3Vy Y2UgbWF5IGJlIHRvbyBsb3csIGZvcmsoKSBtYWxsb2MoKSINCgkJICAgICAg ICAgICIgZXRjIGFyZSBsaWtlbHkgdG8gZmFpbC4iKTsNCg0KCQl0c3RfcmVz bShUQlJPSywgIkNhbiBub3QgcmVtb3ZlICclcycgZHVlIHRvIGluYWJpbGl0 eSBvZiBmb3JrLiIsZnVzcyk7DQoJCXN5bmMoKTsNCgkJdHN0X2V4aXQoKTsN Cgl9DQoJaWYgKHBpZCA9PSAwKSB7DQoJCWV4ZWNsKCIvYmluL3JtIiwgInJt IiwgIi1yZiIsIGZ1c3MsIE5VTEwpOw0KCQl0c3RfZXhpdCgpOw0KCX0NCg0K CXdhaXQoJnN0YXR1cyk7DQoJaWYgKHN0YXR1cykgew0KCQl0c3RfcmVzbShU SU5GTywgIkNBVVRJT04gLSBmdGVzdDEsICclcycgbWF5IG5vdCBiZSByZW1v dmVkIiwgZnVzcyk7DQoJfQ0KDQoJc3luYygpOwkJCQkvKiBzYWZlbmVzcyAq Lw0KCXJldHVybigwKTsNCn0NCg0KLyoNCiAqIGRvdGVzdCgpDQogKglDaGls ZHJlbiBleGVjdXRlIHRoaXMuDQogKg0KICogUmFuZG9tbHkgcmVhZC9tb2Qv d3JpdGUgY2h1bmtzIHdpdGgga25vd24gcGF0dGVybiBhbmQgY2hlY2suDQog KiBXaGVuIGZpbGwgc2VjdG9ycywgaXRlcmF0ZS4NCiAqLw0KDQojZGVmaW5l CU5NSVNDCTQNCmVudW0JbV90eXBlIHsgbV9mc3luYywgbV90cnVuYywgbV9z eW5jLCBtX2ZzdGF0IH07DQpjaGFyCSptX3N0cltdID0gew0KCQkiZnN5bmMi LCAgICJ0cnVuYyIsICJzeW5jIiwgImZzdGF0Ig0KfTsNCg0KaW50CW1pc2Nf Y250W05NSVNDXTsJCS8qIGNvdW50cyAjIG9mIGVhY2gga2luZCBvZiBtaXNj ICovDQppbnQJZmlsZV9tYXg7CQkJLyogZmlsZS1tYXggc2l6ZSAqLw0KaW50 CW5jaHVua3M7DQppbnQJbGFzdF90cnVuYyA9IC0xOw0KaW50CXRyX2ZsYWc7 DQplbnVtCW1fdHlwZSB0eXBlID0gbV9mc3luYzsNCg0KI2RlZmluZQlDSFVO SyhpKQkoKGkpICogY3NpemUpDQojZGVmaW5lCU5FWFRNSVNDCSgocmFuZCgp ICUgbWlzY19pbnR2bCkgKyA1KQ0KDQppbnQgZG90ZXN0KHRlc3RlcnMsIG1l LCBmZCkNCglpbnQJdGVzdGVyczsNCglpbnQJbWU7DQoJaW50CWZkOw0Kew0K CXJlZ2lzdGVyIGludAlpOw0KCWNoYXIJKmJpdHM7DQoJY2hhcgkqaG9sZF9i aXRzOw0KCWNoYXIJKmJ1ZjsNCgljaGFyCSp2YWxfYnVmOw0KCWNoYXIJKnpl cm9fYnVmOw0KCWludAljb3VudDsNCglpbnQJY29sbGlkZTsNCgljaGFyCXZh bDsNCglpbnQJY2h1bms7DQoJaW50CXdoZW5taXNjOw0KCWludAl4ZnI7DQoN CgluY2h1bmtzID0gbWF4X3NpemUgLyBjc2l6ZTsNCglpZiggKGJpdHMgPSAo Y2hhciopY2FsbG9jKChuY2h1bmtzKzcpLzgsIDEpKSA9PSAwKSB7DQoJCXRz dF9yZXNtKFRCUk9LLCAiVGVzdCBicm9rZW4gZHVlIHRvIGluYWJpbGl0eSBv ZiBtYWxsb2MoYml0cykuIik7DQoJCXRzdF9leGl0KCk7DQoJfQ0KCWlmKCAo aG9sZF9iaXRzID0gKGNoYXIqKWNhbGxvYygobmNodW5rcys3KS84LCAxKSkg PT0gMCkgew0KCQl0c3RfcmVzbShUQlJPSywgIlRlc3QgYnJva2VuIGR1ZSB0 byBpbmFiaWxpdHkgb2YgbWFsbG9jKGhvbGRfYml0cykuIik7DQoJCXRzdF9l eGl0KCk7DQoJfQ0KCWlmKCAoYnVmID0gKGNoYXIqKShjYWxsb2MoY3NpemUs IDEpKSkgPT0gMCkgew0KCQl0c3RfcmVzbShUQlJPSywgIlRlc3QgYnJva2Vu IGR1ZSB0byBpbmFiaWxpdHkgb2YgbWFsbG9jKGJ1ZikuIik7DQoJCXRzdF9l eGl0KCk7DQoJfQ0KCWlmKCAodmFsX2J1ZiA9IChjaGFyKikoY2FsbG9jKGNz aXplLCAxKSkpID09IDApIHsNCgkJdHN0X3Jlc20oVEJST0ssICJUZXN0IGJy b2tlbiBkdWUgdG8gaW5hYmlsaXR5IG9mIG1hbGxvYyh2YWxfYnVmKS4iKTsN CgkJdHN0X2V4aXQoKTsNCgl9DQoJaWYoICh6ZXJvX2J1ZiA9IChjaGFyKiko Y2FsbG9jKGNzaXplLCAxKSkpID09IDApIHsNCgkJdHN0X3Jlc20oVEJST0ss ICJUZXN0IGJyb2tlbiBkdWUgdG8gaW5hYmlsaXR5IG9mIG1hbGxvYyh6ZXJv X2J1ZikoemVyb19idWYpKHplcm9fYnVmKSh6ZXJvX2J1ZikoemVyb19idWYp KHplcm9fYnVmKSh6ZXJvX2J1ZikoemVyb19idWYpKHplcm9fYnVmKS4iKTsN CgkJdHN0X2V4aXQoKTsNCgl9DQoNCgkvKg0KCSAqIE5vIGluaXQgc2VjdG9y czsgYWxsb3cgZmlsZSB0byBiZSBzcGFyc2UuDQoJICovDQoNCgl2YWwgPSAo NjQvdGVzdGVycykgKiBtZSArIDE7DQoNCgkvKg0KCSAqIEZvciBlYWNoIGl0 ZXJhdGlvbjoNCgkgKgl6YXAgYml0cyBhcnJheQ0KCSAqCWxvb3A6DQoJICoJ CXBpY2sgcmFuZG9tIGNodW5rLCByZWFkIGl0Lg0KCSAqCQlpZiBjb3JyZXNw b25kaW5nIGJpdCBvZmYgew0KCSAqCQkJdmVyaWZ5ID09IDAuIChzcGFyc2Ug ZmlsZSkNCgkgKgkJCSsrY291bnQ7DQoJICoJCX0gZWxzZQ0KCSAqCQkJdmVy aWZ5ID09IHZhbC4NCgkgKgkJd3JpdGUgInZhbCIgb24gaXQuDQoJICoJCXJl cGVhdCB1bnRpbCBjb3VudCA9IG5jaHVua3MuDQoJICoJKyt2YWwuDQoJICov DQoNCglzcmFuZChnZXRwaWQoKSk7DQoJaWYgKG1pc2NfaW50dmwpIHdoZW5t aXNjID0gTkVYVE1JU0M7DQoJd2hpbGUoaXRlcmF0aW9ucy0tID4gMCkgew0K CQlmb3IoaSA9IDA7IGkgPCBOTUlTQzsgaSsrKQ0KCQkJbWlzY19jbnRbaV0g PSAwOw0KCQlmdHJ1bmNhdGUoZmQsIDApOw0KCQlmaWxlX21heCA9IDA7DQoJ CWJmaWxsKGJpdHMsIDAsIChuY2h1bmtzKzcpLzgpOw0KCQliZmlsbChob2xk X2JpdHMsIDAsIChuY2h1bmtzKzcpLzgpOw0KCQliZmlsbCh2YWxfYnVmLCB2 YWwsIGNzaXplKTsNCgkJYmZpbGwoemVyb19idWYsIDAsIGNzaXplKTsNCgkJ Y291bnQgPSAwOw0KCQljb2xsaWRlID0gMDsNCgkJd2hpbGUoY291bnQgPCBu Y2h1bmtzKSB7DQoJCQljaHVuayA9IHJhbmQoKSAlIG5jaHVua3M7DQoJCQkv Kg0KCQkJICogUmVhZCBpdC4NCgkJCSAqLw0KCQkJaWYgKGxzZWVrKGZkLCAo bG9uZylDSFVOSyhjaHVuayksIDApIDwgMCkgew0KCQkJCXRzdF9yZXNtKFRG QUlMLCAiVGVzdFslZF06IGxzZWVrKDApIGZhaWwgYXQgJXgsIGVycm5vID0g JWQuIiwNCgkJCQkgICAgICAgICBtZSwgQ0hVTksoY2h1bmspLCBlcnJubyk7 DQoNCgkJCQl0c3RfZXhpdCgpOw0KCQkJfQ0KCQkJaWYgKCh4ZnIgPSByZWFk KGZkLCBidWYsIGNzaXplKSkgPCAwKSB7DQoJCQkJdHN0X3Jlc20oVEZBSUws ICJUZXN0WyVkXTogcmVhZCBmYWlsIGF0ICV4LCBlcnJubyA9ICVkLiIsDQoJ CQkJCW1lLCBDSFVOSyhjaHVuayksIGVycm5vKTsNCgkJCQl0c3RfZXhpdCgp Ow0KCQkJfQ0KCQkJLyoNCgkJCSAqIElmIGNodW5rIGJleW9uZCBFT0YganVz dCB3cml0ZSBvbiBpdC4NCgkJCSAqIEVsc2UgaWYgYml0IG9mZiwgaGF2ZW4n dCBzZWVuIGl0IHlldC4NCgkJCSAqIEVsc2UsIGhhdmUuICBWZXJpZnkgdmFs dWVzLg0KCQkJICovDQoJCQlpZiAoQ0hVTksoY2h1bmspID49IGZpbGVfbWF4 KSB7DQoJCQkJYml0c1tjaHVuay84XSB8PSAoMTw8KGNodW5rJTgpKTsNCgkJ CQkrK2NvdW50Ow0KCQkJfSBlbHNlIGlmICgoYml0c1tjaHVuay84XSAmICgx PDwoY2h1bmslOCkpKSA9PSAwKSB7DQoJCQkJaWYgKHhmciAhPSBjc2l6ZSkg ew0KCQkJCQl0c3RfcmVzbShURkFJTCwgIlRlc3RbJWRdOiB4ZnI9JWQgIT0g JWQsIHplcm8gcmVhZC4iLA0KCQkJCQkJbWUsIHhmciwgY3NpemUpOw0KCQkJ CQl0c3RfZXhpdCgpOw0KCQkJCX0NCgkJCQlpZiAobWVtY21wKGJ1ZiwgemVy b19idWYsIGNzaXplKSkgew0KCQkJCQl0c3RfcmVzbShURkFJTCwgIlRlc3Rb JWRdIGJhZCB2ZXJpZnkgQCAweCV4IGZvciB2YWwgJWQgIiANCgkJCQkJCSJj b3VudCAlZCB4ZnIgJWQgZmlsZV9tYXggMHgleCwgc2hvdWxkIGJlICVkLiIs DQoJCQkJCQltZSwgQ0hVTksoY2h1bmspLCB2YWwsIGNvdW50LCB4ZnIsIGZp bGVfbWF4LCANCgkJCQkJCXplcm9fYnVmWzBdKTsNCgkJCQkJdHN0X3Jlc20o VEZBSUwsICJUZXN0WyVkXTogbGFzdF90cnVuYyA9IDB4JXguIiwNCgkJCQkJ CW1lLCBsYXN0X3RydW5jKTsNCgkJCQkJc3luYygpOw0KCQkJCQlkdW1wYnVm KGJ1Zik7DQoJCQkJCWR1bXBiaXRzKGJpdHMsIChuY2h1bmtzKzcpLzgpOw0K CQkJCQlvcmJpdHMoaG9sZF9iaXRzLCBiaXRzLCAobmNodW5rcys3KS84KTsN CgkJCQkJdHN0X3Jlc20oVElORk8sICJIb2xkICIpOyANCgkJCQkJZHVtcGJp dHMoaG9sZF9iaXRzLCAobmNodW5rcys3KS84KTsNCgkJCQkJdHN0X2V4aXQo KTsNCgkJCQl9DQoJCQkJYml0c1tjaHVuay84XSB8PSAoMTw8KGNodW5rJTgp KTsNCgkJCQkrK2NvdW50Ow0KCQkJfSBlbHNlIHsNCgkJCQlpZiAoeGZyICE9 IGNzaXplKSB7DQoJCQkJCXRzdF9yZXNtKFRGQUlMLCAiXHRUZXN0WyVkXTog eGZyPSVkICE9ICVkLCB2YWwgcmVhZC4iLA0KCQkJCQkJbWUsIHhmciwgY3Np emUpOw0KCQkJCQl0c3RfZXhpdCgpOw0KCQkJCX0NCgkJCQkrK2NvbGxpZGU7 DQoJCQkJaWYgKG1lbWNtcChidWYsIHZhbF9idWYsIGNzaXplKSkgew0KCQkJ CQl0c3RfcmVzbShURkFJTCwgIlRlc3RbJWRdIGJhZCB2ZXJpZnkgQCAweCV4 IGZvciB2YWwgJWQgIg0KCQkJCQkJCSJjb3VudCAlZCB4ZnIgJWQgZmlsZV9t YXggMHgleC4iLA0KCQkJCQkJbWUsIENIVU5LKGNodW5rKSwgdmFsLCBjb3Vu dCwgeGZyLCBmaWxlX21heCk7DQoJCQkJCXRzdF9yZXNtKFRGQUlMLCAiVGVz dFslZF06IGxhc3RfdHJ1bmMgPSAweCV4LiIsDQoJCQkJCQltZSwgbGFzdF90 cnVuYyk7DQoJCQkJCXN5bmMoKTsNCgkJCQkJZHVtcGJ1ZihidWYpOw0KCQkJ CQlkdW1wYml0cyhiaXRzLCAobmNodW5rcys3KS84KTsNCgkJCQkJb3JiaXRz KGhvbGRfYml0cywgYml0cywgKG5jaHVua3MrNykvOCk7DQoJCQkJCXRzdF9y ZXNtKFRJTkZPLCAiSG9sZCAiKTsgDQoJCQkJCWR1bXBiaXRzKGhvbGRfYml0 cywgKG5jaHVua3MrNykvOCk7DQoJCQkJCXRzdF9leGl0KCk7DQoJCQkJfQ0K CQkJfQ0KCQkJLyoNCgkJCSAqIFdyaXRlIGl0Lg0KCQkJICovDQoJCQlpZiAo bHNlZWsoZmQsIC0oKGxvbmcpeGZyKSwgMSkgPCAgMCkgew0KCQkJCXRzdF9y ZXNtKFRGQUlMLCAiVGVzdFslZF06IGxzZWVrKDEpIGZhaWwgYXQgJXgsIGVy cm5vID0gJWQuIiwNCgkJCQkJbWUsIENIVU5LKGNodW5rKSwgZXJybm8pOw0K CQkJCXRzdF9leGl0KCk7DQoJCQl9DQoJCQlpZiAoKHhmciA9IHdyaXRlKGZk LCB2YWxfYnVmLCBjc2l6ZSkpIDwgY3NpemUpIHsNCgkJCQlpZiAoZXJybm8g PT0gRU5PU1BDKSB7DQoJCQkJCXRzdF9yZXNtKFRGQUlMLCAiVGVzdFslZF06 IG5vIHNwYWNlLCBleGl0aW5nLiIsIG1lKTsNCgkJCQkJZnN5bmMoZmQpOw0K CQkJCQl0c3RfZXhpdCgpOw0KCQkJCX0NCgkJCQl0c3RfcmVzbShURkFJTCwg IlRlc3RbJWRdOiB3cml0ZSBmYWlsIGF0ICV4IHhmciAlZCwgZXJybm8gPSAl ZC4iLA0KCQkJCQltZSwgQ0hVTksoY2h1bmspLCB4ZnIsIGVycm5vKTsNCgkJ CQl0c3RfZXhpdCgpOw0KCQkJfQ0KCQkJaWYgKENIVU5LKGNodW5rKSArIGNz aXplID4gZmlsZV9tYXgpDQoJCQkJZmlsZV9tYXggPSBDSFVOSyhjaHVuaykg KyBjc2l6ZTsNCgkJCS8qDQoJCQkgKiBJZiBoaXQgIm1pc2MiIGludGVydmFs LCBkbyBpdC4NCgkJCSAqLw0KCQkJaWYgKG1pc2NfaW50dmwgJiYgLS13aGVu bWlzYyA8PSAwKSB7DQoJCQkJb3JiaXRzKGhvbGRfYml0cywgYml0cywgKG5j aHVua3MrNykvOCk7DQoJCQkJZG9taXNjKG1lLCBmZCwgYml0cyk7DQoJCQkJ d2hlbm1pc2MgPSBORVhUTUlTQzsNCgkJCX0NCgkJCWlmIChjb3VudCArIGNv bGxpZGUgPiAyICogbmNodW5rcykNCgkJCQlicmVhazsNCgkJfQ0KDQoJCS8q DQoJCSAqIEVuZCBvZiBpdGVyYXRpb24sIG1heWJlIGJlZm9yZSBkb2luZyBh bGwgY2h1bmtzLg0KCQkgKi8NCg0KCQlmc3luYyhmZCk7DQoJCSsrbWlzY19j bnRbKGludCltX2ZzeW5jXTsNCgkJLy90c3RfcmVzbShUSU5GTywgIlRlc3R7 JWR9IHZhbCAlZCBkb25lLCBjb3VudCA9ICVkLCBjb2xsaWRlID0geyVkfSIs DQoJCS8vCQltZSwgdmFsLCBjb3VudCwgY29sbGlkZSk7DQoJCS8vZm9yKGkg PSAwOyBpIDwgTk1JU0M7IGkrKykNCgkJLy8JdHN0X3Jlc20oVElORk8sICJU ZXN0eyVkfTogeyVkfSAlcydzLiIsIG1lLCBtaXNjX2NudFtpXSwgbV9zdHJb aV0pOw0KCQkrK3ZhbDsNCgl9DQoJcmV0dXJuKDApOw0KfQ0KDQovKg0KICog ZG9taXNjKCkNCiAqCUluamVjdCBtaXNjIHN5c2NhbGxzIGludG8gdGhlIHRo aW5nLg0KICovDQoNCmludCBkb21pc2MobWUsIGZkLCBiaXRzKQ0KCWludAlt ZTsNCglpbnQJZmQ7DQoJY2hhcgkqYml0czsNCnsNCglyZWdpc3RlciBpbnQJ Y2h1bms7DQoJc3RydWN0CXN0YXQgc2I7DQoNCglpZiAoKGludCkgdHlwZSA+ IChpbnQpIG1fZnN0YXQpDQoJCXR5cGUgPSBtX2ZzeW5jOw0KCXN3aXRjaCh0 eXBlKSB7DQoJY2FzZSBtX2ZzeW5jOg0KCQlpZiAoZnN5bmMoZmQpIDwgMCkg ew0KCQkJdHN0X3Jlc20oVEZBSUwsICJUZXN0WyVkXTogZnN5bmMgZXJyb3Ig JWQuIiwgbWUsIGVycm5vKTsNCgkJCXRzdF9leGl0KCk7DQoJCX0NCgkJYnJl YWs7DQoJY2FzZSBtX3RydW5jOg0KCQljaHVuayA9IHJhbmQoKSAlIChmaWxl X21heCAvIGNzaXplKTsNCgkJZmlsZV9tYXggPSBDSFVOSyhjaHVuayk7DQoJ CWxhc3RfdHJ1bmMgPSBmaWxlX21heDsNCgkJaWYgKHRyX2ZsYWcpIHsNCgkJ CWlmIChmdHJ1bmNhdGUoZmQsIGZpbGVfbWF4KSA8IDApIHsNCgkJCQl0c3Rf cmVzbShURkFJTCwgIlRlc3RbJWRdOiBmdHJ1bmNhdGUgZXJyb3IgJWQgQCAw eCV4LiIsIA0KCQkJCQkJbWUsIGVycm5vLCBmaWxlX21heCk7DQoJCQkJdHN0 X2V4aXQoKTsNCgkJCX0NCgkJCXRyX2ZsYWcgPSAwOw0KCQl9IGVsc2Ugew0K CQkJaWYgKHRydW5jYXRlKHRlc3RfbmFtZSwgZmlsZV9tYXgpIDwgMCkgew0K CQkJCXRzdF9yZXNtKFRGQUlMLCAiVGVzdFslZF06IHRydW5jYXRlIGVycm9y ICVkIEAgMHgleC4iLCANCgkJCQkJCW1lLCBlcnJubywgZmlsZV9tYXgpOw0K CQkJCXRzdF9leGl0KCk7DQoJCQl9DQoJCQl0cl9mbGFnID0gMTsNCgkJfQ0K CQlmb3IoOyBjaHVuayU4ICE9IDA7IGNodW5rKyspDQoJCQliaXRzW2NodW5r LzhdICY9IH4oMTw8KGNodW5rJTgpKTsNCgkJZm9yKDsgY2h1bmsgPCBuY2h1 bmtzOyBjaHVuayArPSA4KQ0KCQkJYml0c1tjaHVuay84XSA9IDA7DQoJCWJy ZWFrOw0KCWNhc2UgbV9zeW5jOg0KCQlzeW5jKCk7DQoJCWJyZWFrOw0KCWNh c2UgbV9mc3RhdDoNCgkJaWYgKGZzdGF0KGZkLCAmc2IpIDwgMCkgew0KCQkJ dHN0X3Jlc20oVEZBSUwsICJUZXN0WyVkXTogZnN0YXQoKSBlcnJvciAlZC4i LCBtZSwgZXJybm8pOw0KCQkJdHN0X2V4aXQoKTsNCgkJfQ0KCQlpZiAoc2Iu c3Rfc2l6ZSAhPSBmaWxlX21heCkgew0KCQkJdHN0X3Jlc20oVEZBSUwsICJc dFRlc3RbJWRdOiBmc3RhdCgpIG1pc21hdGNoOyBzdF9zaXplPSV4LGZpbGVf bWF4PSV4LiIsDQoJCQkJbWUsIHNiLnN0X3NpemUsIGZpbGVfbWF4KTsNCgkJ CXRzdF9leGl0KCk7DQoJCX0NCgkJYnJlYWs7DQoJfQ0KCSsrbWlzY19jbnRb KGludCl0eXBlXTsNCgl0eXBlID0gKGVudW0gbV90eXBlKSAoKGludCkgdHlw ZSArIDEpOw0KCXJldHVybigwKTsNCn0NCg0KaW50IGJmaWxsKGJ1ZiwgdmFs LCBzaXplKQ0KCXJlZ2lzdGVyIGNoYXIgKmJ1ZjsNCgljaGFyCXZhbDsNCgly ZWdpc3RlciBpbnQgc2l6ZTsNCnsNCglyZWdpc3RlciBpbnQgaTsNCg0KCWZv cihpID0gMDsgaSA8IHNpemU7IGkrKykNCgkJYnVmW2ldID0gdmFsOw0KCXJl dHVybigwKTsNCn0NCg0KLyoNCiAqIGR1bXBidWYNCiAqCUR1bXAgdGhlIGJ1 ZmZlci4NCiAqLw0KDQppbnQgZHVtcGJ1ZihidWYpDQoJcmVnaXN0ZXIgY2hh ciAqYnVmOw0Kew0KCXJlZ2lzdGVyIGludCBpOw0KCWNoYXIJdmFsOw0KCWlu dAlpZHg7DQoJaW50CW5vdXQ7DQoNCgl0c3RfcmVzbShUSU5GTywgIlx0QnVm OiIpOw0KCW5vdXQgPSAwOw0KCWlkeCA9IDA7DQoJdmFsID0gYnVmWzBdOw0K CWZvcihpID0gMDsgaSA8IGNzaXplOyBpKyspIHsNCgkJaWYgKGJ1ZltpXSAh PSB2YWwpIHsNCgkJCWlmIChpID09IGlkeCsxKQ0KCQkJCXRzdF9yZXNtKFRJ TkZPLCAiXHQleCwgIiwgYnVmW2lkeF0gJiAweGZmKTsNCgkJCWVsc2UNCgkJ CQl0c3RfcmVzbShUSU5GTywgIlx0JWQqJXgsICIsIGktaWR4LCBidWZbaWR4 XSAmIDB4ZmYpOw0KCQkJaWR4ID0gaTsNCgkJCSsrbm91dDsNCgkJfQ0KCQlp ZiAobm91dCA+IDEwKSB7DQoJCQl0c3RfcmVzbShUSU5GTywgIlx0IC4uLiBt b3JlIik7DQoJCQlyZXR1cm4oMCk7DQoJCX0NCgl9DQoJaWYgKGkgPT0gaWR4 KzEpDQoJCXRzdF9yZXNtKFRJTkZPLCAiXHQleCIsIGJ1ZltpZHhdICYgMHhm Zik7DQoJZWxzZQ0KCQl0c3RfcmVzbShUSU5GTywgIlx0JWQqJXgiLCBpLWlk eCwgYnVmW2lkeF0pOw0KCXJldHVybigwKTsNCn0NCg0KLyoNCiAqIGR1bXBi aXRzDQogKglEdW1wIHRoZSBiaXQtbWFwLg0KICovDQoNCmludCBkdW1wYml0 cyhiaXRzLCBzaXplKQ0KCWNoYXIJKmJpdHM7DQoJcmVnaXN0ZXIgaW50IHNp emU7DQp7DQoJcmVnaXN0ZXIgY2hhciAqYnVmOw0KDQoJdHN0X3Jlc20oVElO Rk8sICJcdEJpdHMgYXJyYXk6Iik7DQoJZm9yKGJ1ZiA9IGJpdHM7IHNpemUg PiAwOyAtLXNpemUsICsrYnVmKSB7DQoJCWlmICgoYnVmLWJpdHMpICUgMTYg PT0gMCkNCgkJCXRzdF9yZXNtKFRJTkZPLCAiXHQlMDR4Olx0IiwgOCooYnVm LWJpdHMpKTsNCgkJdHN0X3Jlc20oVElORk8sICJcdCUwMnggIiwgKGludCkq YnVmICYgMHhmZik7DQoJfQ0KCXRzdF9yZXNtKFRJTkZPLCAiXHQiKTsNCgly ZXR1cm4oMCk7DQp9DQoNCmludCBvcmJpdHMoaG9sZCwgYml0cywgY291bnQp DQoJcmVnaXN0ZXIgY2hhciAqaG9sZDsNCglyZWdpc3RlciBjaGFyICpiaXRz Ow0KCXJlZ2lzdGVyIGludCBjb3VudDsNCnsNCgl3aGlsZShjb3VudC0tID4g MCkNCgkJKmhvbGQrKyB8PSAqYml0cysrOw0KCXJldHVybigwKTsNCn0NCg0K LyogdGVybSgpDQogKg0KICoJVGhpcyBpcyBjYWxsZWQgd2hlbiBhIFNJR1RF Uk0gc2lnbmFsIGFycml2ZXMuDQogKi8NCg0Kdm9pZCB0ZXJtKCkNCnsNCgly ZWdpc3RlciBpbnQgaTsNCg0KCXRzdF9yZXNtKFRJTkZPLCAiXHR0ZXJtIC1b JWRdLSBnb3Qgc2lnIHRlcm0uIiwgZ2V0cGlkKCkpOw0KDQoJLyoNCgkgKiBJ ZiBydW4gYnkgaGFuZCB3ZSBsaWtlIHRvIGhhdmUgdGhlIHBhcmVudCBzZW5k IHRoZSBzaWduYWwgdG8NCgkgKiB0aGUgY2hpbGQgcHJvY2Vzc2VzLiAgVGhp cyBtYWtlcyBsaWZlIGVhc3kuDQoJICovDQoNCglpZiAocGFyZW50X3BpZCA9 PSBnZXRwaWQoKSkgew0KCQlmb3IgKGk9MDsgaSA8IG5jaGlsZDsgaSsrKQ0K CQkJaWYgKHBpZGxpc3RbaV0pCQkvKiBhdm9pZCBlbWJhcmFzc21lbnQgKi8N CgkJCQlraWxsKHBpZGxpc3RbaV0sIFNJR1RFUk0pOw0KCQl0c3RfZXhpdCgp Ow0KCX0NCg0KCXRzdF9yZXNtKFRJTkZPLCAiXHR1bmxpbmtpbmcgJyVzJyIs IHRlc3RfbmFtZSk7DQoNCgljbG9zZShmZCk7DQoJaWYgKHVubGluayh0ZXN0 X25hbWUpKQ0KCQl0c3RfcmVzbShUQlJPSywgIlVubGluayBvZiAnJXMnIGZh aWxlZCwgZXJybm8gPSAlZC4iLA0KCQkgIHRlc3RfbmFtZSwgZXJybm8pOw0K CWVsc2UNCgkJdHN0X3Jlc20oVElORk8sICJVbmxpbmsgb2YgJyVzJyBzdWNj ZXNzZnVsLiIsIHRlc3RfbmFtZSk7DQoJdHN0X2V4aXQoKTsNCn0NCg0KDQp2 b2lkDQpjbGVhbnVwKCkNCnsNCgkvKg0KICAgICAgICAgKiBwcmludCB0aW1p bmcgc3RhdHMgaWYgdGhhdCBvcHRpb24gd2FzIHNwZWNpZmllZC4NCiAgICAg ICAgICogcHJpbnQgZXJybm8gbG9nIGlmIHRoYXQgb3B0aW9uIHdhcyBzcGVj aWZpZWQuDQogICAgICAgICAqLw0KICAgICAgICBURVNUX0NMRUFOVVA7DQoN Cgl0c3Rfcm1kaXIoKTsNCiAgICAgICAgdHN0X2V4aXQoKTsNCn0NCg0K ------_=_NextPart_001_01C6C25A.4932E3DD-- From owner-xfs@oss.sgi.com Thu Aug 17 18:23:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Aug 2006 18:23:35 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7I1MvDW002385 for ; Thu, 17 Aug 2006 18:23:08 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16531; Fri, 18 Aug 2006 11:22:10 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7I1M8gw2817810; Fri, 18 Aug 2006 11:22:08 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7I1M6r92819950; Fri, 18 Aug 2006 11:22:06 +1000 (EST) Date: Fri, 18 Aug 2006 11:22:06 +1000 From: Nathan Scott To: Henry Yei Cc: xfs@oss.sgi.com Subject: Re: ltp filesystem ftests failing under xfs partition Message-ID: <20060818112206.A2820495@wobbly.melbourne.sgi.com> References: <517DC3FCCF3D8D42BEF1F83F7A633FA85D84D5@svexch01.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <517DC3FCCF3D8D42BEF1F83F7A633FA85D84D5@svexch01.mvista.com>; from hyei@mvista.com on Thu, Aug 17, 2006 at 05:07:24PM -0700 X-archive-position: 8703 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 312 Lines: 13 On Thu, Aug 17, 2006 at 05:07:24PM -0700, Henry Yei wrote: > Hello all, > > I am seeing sporadic failures of ftest01, ftest03, ftest05, and ftest07 > under the xfs filesystem with kernel 2.6.10. I've seen this across many Do these problems exist with a current kernel? (e.g. 2.6.18-rcX) cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Aug 17 23:42:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Aug 2006 23:43:12 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7I6gYDW016627 for ; Thu, 17 Aug 2006 23:42:45 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA22602; Fri, 18 Aug 2006 16:41:47 +1000 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 k7I6fCEo57735532; Fri, 18 Aug 2006 16:41:12 +1000 (AEST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7I6f9Iq57761523; Fri, 18 Aug 2006 16:41:09 +1000 (AEST) Date: Fri, 18 Aug 2006 16:41:09 +1000 (AEST) From: Timothy Shimmin Message-Id: <200608180641.k7I6f9Iq57761523@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 942533 - xfs_freeze hung on ticket sema in xlog_grant_log_space X-archive-position: 8704 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 873 Lines: 23 Fixes the leak in reservation space because we weren't ungranting space for the unmount record - which becomes a problem in the freeze/thaw scenario. --Tim Date: Fri Aug 18 16:39:22 AEST 2006 Inspected by: dgc@sgi.com Modid: xfs-linux-melb:xfs-kern:26815a xfsidbg.c - 1.306 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.306&r2=text&tr2=1.305&f=h - Add some missing transaction types to be printed. xfs_log.c - 1.327 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.327&r2=text&tr2=1.326&f=h - remember to ungrant space for the unmount record. xfs_log_priv.h - 1.117 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.117&r2=text&tr2=1.116&f=h - create a type for XLOG_UNMOUNT_REC_TYPE so that we can see this in kdb transaction printing. From owner-xfs@oss.sgi.com Fri Aug 18 02:55:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 18 Aug 2006 02:55:55 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7I9teDW016951 for ; Fri, 18 Aug 2006 02:55:41 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id C5403616D16C; Fri, 18 Aug 2006 05:55:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id BC5BA16195E69; Fri, 18 Aug 2006 05:55:06 -0400 (EDT) Date: Fri, 18 Aug 2006 05:55:06 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: =?GB2312?B?yubQxw==?= cc: linux-raid@vger.kernel.org, xfs@oss.sgi.com Subject: Re: raid5 grow problem In-Reply-To: <7de068fd0608170730s75afb310g58e6c5fd07202ef@mail.gmail.com> Message-ID: References: <7de068fd0608161815yc34ec6bl886fa637691ee5f8@mail.gmail.com> <7de068fd0608170223g2009962chc222233c70ee9317@mail.gmail.com> <7de068fd0608170730s75afb310g58e6c5fd07202ef@mail.gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463747160-1292466206-1155894906=:16805" X-archive-position: 8705 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 5249 Lines: 170 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463747160-1292466206-1155894906=:16805 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Adding XFS mailing list to this e-mail to show that the grow for xfs=20 worked. On Thu, 17 Aug 2006, =CA=E6=D0=C7 wrote: >> I've only tried growing a RAID5, which was the only RAID that I remember >> being supported (to grow) in the kernel, I am not sure if its posible to > i know this,but how you grow your raid5,what's your mdadm version? > need anyother configure before creat md & use mdadm -G ..to grow? >> grow other types of RAID arrays. > - > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > 0) Compile your kernel with experimental raid5 re-sizing support. 1) Add a spare to the RAID5. 2) Grow the array. Like this: p34:~# mdadm --create /dev/md3 /dev/hda1 /dev/hde1 /dev/sdc1 --level=3D5=20 --raid-disks=3D3 mdadm: array /dev/md3 started. p34:~# mdadm -D /dev/md3 /dev/md3: Version : 00.90.03 Creation Time : Fri Jul 7 15:44:24 2006 Raid Level : raid5 Array Size : 781417472 (745.22 GiB 800.17 GB) Device Size : 390708736 (372.61 GiB 400.09 GB) Raid Devices : 3 Total Devices : 3 Preferred Minor : 3 Persistence : Superblock is persistent Update Time : Fri Jul 7 15:44:24 2006 State : clean, degraded, recovering Active Devices : 2 Working Devices : 3 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 64K Rebuild Status : 0% complete UUID : cf7a7488:64c04921:b8dfe47c:6c785fa1 Events : 0.1 Number Major Minor RaidDevice State 0 3 1 0 active sync /dev/hda1 1 33 1 1 active sync /dev/hde1 3 8 33 2 spare rebuilding /dev/sdc1 p34:~# p34:~# df -h | grep /raid5 /dev/md3 746G 80M 746G 1% /raid5 p34:~# umount /dev/md3 p34:~# mdadm -D /dev/md3 /dev/md3: Version : 00.90.03 Creation Time : Fri Jul 7 15:44:24 2006 Raid Level : raid5 Array Size : 781417472 (745.22 GiB 800.17 GB) Device Size : 390708736 (372.61 GiB 400.09 GB) Raid Devices : 3 Total Devices : 4 Preferred Minor : 3 Persistence : Superblock is persistent Update Time : Fri Jul 7 18:25:29 2006 State : clean Active Devices : 3 Working Devices : 4 Failed Devices : 0 Spare Devices : 1 Layout : left-symmetric Chunk Size : 64K UUID : cf7a7488:64c04921:b8dfe47c:6c785fa1 Events : 0.26 Number Major Minor RaidDevice State 0 3 1 0 active sync /dev/hda1 1 33 1 1 active sync /dev/hde1 2 8 33 2 active sync /dev/sdc1 3 22 1 - spare /dev/hdc1 p34:~# mdadm /dev/md3 --grow --raid-disks=3D4 mdadm: Need to backup 384K of critical section.. mdadm: ... critical section passed. p34:~# cat /proc/mdstat Personalities : [raid1] [raid5] [raid4] md1 : active raid1 sdb2[1] sda2[0] 136448 blocks [2/2] [UU] md2 : active raid1 sdb3[1] sda3[0] 70268224 blocks [2/2] [UU] md3 : active raid5 hdc1[3] sdc1[2] hde1[1] hda1[0] 781417472 blocks super 0.91 level 5, 64k chunk, algorithm 2 [4/4]=20 [UUUU] [>....................] reshape =3D 0.0% (85120/390708736)=20 finish=3D840.5min speed=3D7738K/sec md0 : active raid1 sdb1[1] sda1[0] 2200768 blocks [2/2] [UU] unused devices: p34:~# cat /proc/mdstat Personalities : [raid1] [raid5] [raid4] md1 : active raid1 sdb2[1] sda2[0] 136448 blocks [2/2] [UU] md2 : active raid1 sdb3[1] sda3[0] 70268224 blocks [2/2] [UU] md3 : active raid5 hdc1[3] sdc1[2] hde1[1] hda1[0] 781417472 blocks super 0.91 level 5, 64k chunk, algorithm 2 [4/4]=20 [UUUU] [>....................] reshape =3D 0.0% (286284/390708736)=20 finish=3D779.8min speed=3D8342K/sec md0 : active raid1 sdb1[1] sda1[0] 2200768 blocks [2/2] [UU] unused devices: p34:~# p34:~# mount /raid5 p34:~# xfs_growfs /raid5 meta-data=3D/dev/md3 isize=3D256 agcount=3D32, agsize=3D61= 04816=20 blks =3D sectsz=3D4096 attr=3D0 data =3D bsize=3D4096 blocks=3D195354112, imaxp= ct=3D25 =3D sunit=3D16 swidth=3D48 blks, unwrit= ten=3D1 naming =3Dversion 2 bsize=3D4096 log =3Dinternal bsize=3D4096 blocks=3D32768, version= =3D2 =3D sectsz=3D4096 sunit=3D1 blks realtime =3Dnone extsz=3D196608 blocks=3D0, rtextents=3D0 data blocks changed from 195354112 to 195354368 p34:~# p34:~# umount /raid5 p34:~# mount /raid5 p34:~# df -h /dev/md3 746G 80M 746G 1% /raid5 p34:~# ---1463747160-1292466206-1155894906=:16805-- From owner-xfs@oss.sgi.com Sun Aug 20 18:56:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 20 Aug 2006 18:56:40 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.192.81]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7L1uNDW020391 for ; Sun, 20 Aug 2006 18:56:24 -0700 Received: from rmailcenter16.comcast.net ([204.127.197.126]) by comcast.net (rwcrmhc11) with SMTP id <20060821015549m1100dvf95e>; Mon, 21 Aug 2006 01:55:49 +0000 Received: from [66.31.36.228] by rmailcenter16.comcast.net; Mon, 21 Aug 2006 01:55:48 +0000 From: bridavis@comcast.net To: xfs@oss.sgi.com Subject: Differences in su/sw values for hw vs. sw RAID 5? Date: Mon, 21 Aug 2006 01:55:48 +0000 Message-Id: <082120060155.2003.44E912A400010D0F000007D322058864429C07900E0B079D0D@comcast.net> X-Mailer: AT&T Message Center Version 1 (Apr 11 2006) X-Authenticated-Sender: YnJpZGF2aXNAY29tY2FzdC5uZXQ= MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8707 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bridavis@comcast.net Precedence: bulk X-list: xfs Content-Length: 518 Lines: 14 I getting conflicting reports as to how I should generate my sunit/swidth vaules for hardware RAID 5. Setup: hardware RAID 5, 3 disks at 300 GBs each, 64k stripe size. Originally, following the man page and the mailing list archives, I came up sw=2,su=64k. However, I read a reply to an earlier question I sent to the list, and it indicated that the hardward RAID should be treated as a single disk, so I came up with sw=1,su=128k. Which one is correct for my setup? Thanks! [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sun Aug 20 22:10:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 20 Aug 2006 22:10:29 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7L59pDW013591 for ; Sun, 20 Aug 2006 22:10:03 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA09284; Mon, 21 Aug 2006 15:09:06 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 5F2ED58C4C00; Mon, 21 Aug 2006 15:09:06 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 955558 - userspace Makefiles Message-Id: <20060821050906.5F2ED58C4C00@chook.melbourne.sgi.com> Date: Mon, 21 Aug 2006 15:09:06 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8708 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1856 Lines: 40 Fix symlink detection in userspace Makefiles Date: Mon Aug 21 15:06:46 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26823a xfsprogs/doc/CHANGES - 1.217 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.217&r2=text&tr2=1.216&f=h xfsdump/doc/CHANGES - 1.96 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/doc/CHANGES.diff?r1=text&tr1=1.96&r2=text&tr2=1.95&f=h xfsprogs/include/buildmacros - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/buildmacros.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsdump/include/buildmacros - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/include/buildmacros.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h Fix symlink detection in userspace Makefiles Date: Mon Aug 21 15:08:50 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26825a dmapi/include/buildmacros - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/include/buildmacros.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h acl/include/buildmacros - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/include/buildmacros.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h attr/include/buildmacros - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/include/buildmacros.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfstests/include/buildmacros - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/include/buildmacros.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h From owner-xfs@oss.sgi.com Sun Aug 20 23:16:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 20 Aug 2006 23:16:42 -0700 (PDT) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7L6GMDW021190 for ; Sun, 20 Aug 2006 23:16:26 -0700 Received: from agami.com ([192.168.168.133]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id k7L6FjwI024137 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 20 Aug 2006 23:15:50 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id k7L6FeNv021152 for ; Sun, 20 Aug 2006 23:15:40 -0700 Received: from [10.12.12.141] ([10.12.12.141]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 23:17:23 -0700 Message-ID: <44E94F90.1010606@agami.com> Date: Mon, 21 Aug 2006 11:45:44 +0530 From: Shailendra Tripathi User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bridavis@comcast.net, xfs@oss.sgi.com Subject: Re: Differences in su/sw values for hw vs. sw RAID 5? References: <082120060155.2003.44E912A400010D0F000007D322058864429C07900E0B079D0D@comcast.net> In-Reply-To: <082120060155.2003.44E912A400010D0F000007D322058864429C07900E0B079D0D@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2006 06:17:23.0703 (UTC) FILETIME=[77722070:01C6C4E9] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 8709 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stripathi@agami.com Precedence: bulk X-list: xfs Content-Length: 2360 Lines: 56 For RAID-5 device, for any write, the parity as well has to be calculated before writing. In absence of any column of RAID, it is read from disk and then re-written. When you choose writes such as all columns are already there, parity can be directly calculated and written (without incurring any extra read I/O) and that's why, declaring in that form is desirable. Someone correct me if I am wrong. # mdadm --create /dev/md15 --level=5 --raid-devices=3 -c 64 /dev/sd[hvi]1 mdadm: array /dev/md15 started. When forced choice of sw=1,su=128k # cat /proc/mdstat | more ... md15 : active raid5 sdv1[2] sdi1[1] sdh1[0] 78139904 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU] # mkfs.xfs -f -d sw=1,su=128k /dev/md15 mkfs.xfs: Specified data stripe unit 256 is not the same as the volume stripe unit 128 meta-data=/dev/md15 isize=256 agcount=16, agsize=1220928 blks = sectsz=512 data = bsize=4096 blocks=19534848, imaxpct=25 = sunit=32 swidth=32 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=9568, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=131072 blocks=0, rtextents=0 Though by default, it detects the former one. # mkfs.xfs -f /dev/md15 meta-data=/dev/md15 isize=256 agcount=16, agsize=1220944 blks = sectsz=512 data = bsize=4096 blocks=19534976, imaxpct=25 = sunit=16 swidth=32 blks, unwritten=1 naming =version 2 bsize=4096 Please note that default created here is: sunit=16, swidth=3 bridavis@comcast.net wrote: > I getting conflicting reports as to how I should generate my sunit/swidth vaules for hardware RAID 5. > > Setup: hardware RAID 5, 3 disks at 300 GBs each, 64k stripe size. > > Originally, following the man page and the mailing list archives, I came up sw=2,su=64k. > > However, I read a reply to an earlier question I sent to the list, and it indicated that the hardward RAID should be treated as a single disk, so I came up with sw=1,su=128k. > > Which one is correct for my setup? > > Thanks! > > [[HTML alternate version deleted]] > > From owner-xfs@oss.sgi.com Mon Aug 21 07:22:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 21 Aug 2006 07:23:04 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [63.240.77.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7LEMoDW027117 for ; Mon, 21 Aug 2006 07:22:50 -0700 Received: from [10.86.240.204] (bxb-natpool-121.cisco.com[12.159.148.121]) by comcast.net (sccrmhc12) with ESMTP id <20060821122730012003s4rce>; Mon, 21 Aug 2006 12:27:31 +0000 Message-ID: <44E9A6B3.8000607@comcast.net> Date: Mon, 21 Aug 2006 08:27:31 -0400 From: Brian Davis User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Shailendra Tripathi CC: xfs@oss.sgi.com Subject: Re: Differences in su/sw values for hw vs. sw RAID 5? References: <082120060155.2003.44E912A400010D0F000007D322058864429C07900E0B079D0D@comcast.net> <44E94F90.1010606@agami.com> In-Reply-To: <44E94F90.1010606@agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8711 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bridavis@comcast.net Precedence: bulk X-list: xfs Content-Length: 2706 Lines: 69 Maybe I'm missing something, but I'm not sure how the information below maps to setting the values on Hardware RAID. A nice feature of xfs is that it's intelligent enough to figure out the proper values for SW RAID. Thanks! Shailendra Tripathi wrote: > For RAID-5 device, for any write, the parity as well has to be > calculated before writing. In absence of any column of RAID, it is > read from disk and then re-written. When you choose writes such as all > columns are already there, parity can be directly calculated and > written (without incurring any extra read I/O) and that's why, > declaring in that form is desirable. Someone correct me if I am wrong. > > # mdadm --create /dev/md15 --level=5 --raid-devices=3 -c 64 /dev/sd[hvi]1 > mdadm: array /dev/md15 started. > > When forced choice of sw=1,su=128k > # cat /proc/mdstat | more > ... > md15 : active raid5 sdv1[2] sdi1[1] sdh1[0] > 78139904 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU] > # mkfs.xfs -f -d sw=1,su=128k /dev/md15 > mkfs.xfs: Specified data stripe unit 256 is not the same as the volume > stripe unit 128 > meta-data=/dev/md15 isize=256 agcount=16, > agsize=1220928 blks > = sectsz=512 > data = bsize=4096 blocks=19534848, imaxpct=25 > = sunit=32 swidth=32 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=9568, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=131072 blocks=0, rtextents=0 > > Though by default, it detects the former one. > > # mkfs.xfs -f /dev/md15 > meta-data=/dev/md15 isize=256 agcount=16, > agsize=1220944 blks > = sectsz=512 > data = bsize=4096 blocks=19534976, imaxpct=25 > = sunit=16 swidth=32 blks, unwritten=1 > naming =version 2 bsize=4096 > > Please note that default created here is: sunit=16, swidth=3 > bridavis@comcast.net wrote: >> I getting conflicting reports as to how I should generate my >> sunit/swidth vaules for hardware RAID 5. >> >> Setup: hardware RAID 5, 3 disks at 300 GBs each, 64k stripe size. >> >> Originally, following the man page and the mailing list archives, I >> came up sw=2,su=64k. >> However, I read a reply to an earlier question I sent to the list, >> and it indicated that the hardward RAID should be treated as a single >> disk, so I came up with sw=1,su=128k. >> >> Which one is correct for my setup? >> >> Thanks! >> >> [[HTML alternate version deleted]] >> >> > From owner-xfs@oss.sgi.com Mon Aug 21 19:58:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 21 Aug 2006 19:58:12 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7M2vtDW013355 for ; Mon, 21 Aug 2006 19:58:00 -0700 Received: by sandeen.net (Postfix, from userid 500) id ED1A318DE2F38; Mon, 21 Aug 2006 21:57:19 -0500 (CDT) To: xfs@oss.sgi.com Subject: [PATCH] reduce endian flipping in xfs_alloc_btree.c Message-Id: <20060822025719.ED1A318DE2F38@sandeen.net> Date: Mon, 21 Aug 2006 21:57:19 -0500 (CDT) From: sandeen@sandeen.net X-archive-position: 8713 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 11771 Lines: 327 (Note: I've done some sanity-check testing, but this should probably live in a patch stack for a while before checkin...) Reduce endian flipping activity in this file; compare to xfs_ialloc_btree.c for a sanity-check. Signed-off-by: Eric Sandeen k Index: xfs-linux-killwantfuncs/xfs_alloc_btree.c =================================================================== --- xfs-linux-killwantfuncs.orig/xfs_alloc_btree.c +++ xfs-linux-killwantfuncs/xfs_alloc_btree.c @@ -92,6 +92,7 @@ xfs_alloc_delrec( xfs_alloc_key_t *rkp; /* right block key pointer */ xfs_alloc_ptr_t *rpp; /* right block address pointer */ int rrecs=0; /* number of records in right block */ + int numrecs; xfs_alloc_rec_t *rrp; /* right block record pointer */ xfs_btree_cur_t *tcur; /* temporary btree cursor */ @@ -115,7 +116,8 @@ xfs_alloc_delrec( /* * Fail if we're off the end of the block. */ - if (ptr > be16_to_cpu(block->bb_numrecs)) { + numrecs = be16_to_cpu(block->bb_numrecs); + if (ptr > numrecs) { *stat = 0; return 0; } @@ -129,18 +131,18 @@ xfs_alloc_delrec( lkp = XFS_ALLOC_KEY_ADDR(block, 1, cur); lpp = XFS_ALLOC_PTR_ADDR(block, 1, cur); #ifdef DEBUG - for (i = ptr; i < be16_to_cpu(block->bb_numrecs); i++) { + for (i = ptr; i < numrecs; i++) { if ((error = xfs_btree_check_sptr(cur, be32_to_cpu(lpp[i]), level))) return error; } #endif - if (ptr < be16_to_cpu(block->bb_numrecs)) { + if (ptr < numrecs) { memmove(&lkp[ptr - 1], &lkp[ptr], - (be16_to_cpu(block->bb_numrecs) - ptr) * sizeof(*lkp)); + (numrecs - ptr) * sizeof(*lkp)); memmove(&lpp[ptr - 1], &lpp[ptr], - (be16_to_cpu(block->bb_numrecs) - ptr) * sizeof(*lpp)); - xfs_alloc_log_ptrs(cur, bp, ptr, be16_to_cpu(block->bb_numrecs) - 1); - xfs_alloc_log_keys(cur, bp, ptr, be16_to_cpu(block->bb_numrecs) - 1); + (numrecs - ptr) * sizeof(*lpp)); + xfs_alloc_log_ptrs(cur, bp, ptr, numrecs - 1); + xfs_alloc_log_keys(cur, bp, ptr, numrecs - 1); } } /* @@ -149,10 +151,10 @@ xfs_alloc_delrec( */ else { lrp = XFS_ALLOC_REC_ADDR(block, 1, cur); - if (ptr < be16_to_cpu(block->bb_numrecs)) { + if (ptr < numrecs) { memmove(&lrp[ptr - 1], &lrp[ptr], - (be16_to_cpu(block->bb_numrecs) - ptr) * sizeof(*lrp)); - xfs_alloc_log_recs(cur, bp, ptr, be16_to_cpu(block->bb_numrecs) - 1); + (numrecs - ptr) * sizeof(*lrp)); + xfs_alloc_log_recs(cur, bp, ptr, numrecs - 1); } /* * If it's the first record in the block, we'll need a key @@ -167,7 +169,8 @@ xfs_alloc_delrec( /* * Decrement and log the number of entries in the block. */ - be16_add(&block->bb_numrecs, -1); + numrecs--; + block->bb_numrecs = cpu_to_be16(numrecs); xfs_alloc_log_block(cur->bc_tp, bp, XFS_BB_NUMRECS); /* * See if the longest free extent in the allocation group was @@ -181,14 +184,14 @@ xfs_alloc_delrec( if (level == 0 && cur->bc_btnum == XFS_BTNUM_CNT && be32_to_cpu(block->bb_rightsib) == NULLAGBLOCK && - ptr > be16_to_cpu(block->bb_numrecs)) { - ASSERT(ptr == be16_to_cpu(block->bb_numrecs) + 1); + ptr > numrecs) { + ASSERT(ptr == numrecs + 1); /* * There are still records in the block. Grab the size * from the last one. */ - if (be16_to_cpu(block->bb_numrecs)) { - rrp = XFS_ALLOC_REC_ADDR(block, be16_to_cpu(block->bb_numrecs), cur); + if (numrecs) { + rrp = XFS_ALLOC_REC_ADDR(block, numrecs, cur); agf->agf_longest = rrp->ar_blockcount; } /* @@ -211,7 +214,7 @@ xfs_alloc_delrec( * and it's NOT the leaf level, * then we can get rid of this level. */ - if (be16_to_cpu(block->bb_numrecs) == 1 && level > 0) { + if (numrecs == 1 && level > 0) { /* * lpp is still set to the first pointer in the block. * Make it the new root of the btree. @@ -267,7 +270,7 @@ xfs_alloc_delrec( * If the number of records remaining in the block is at least * the minimum, we're done. */ - if (be16_to_cpu(block->bb_numrecs) >= XFS_ALLOC_BLOCK_MINRECS(level, cur)) { + if (numrecs >= XFS_ALLOC_BLOCK_MINRECS(level, cur)) { if (level > 0 && (error = xfs_alloc_decrement(cur, level, &i))) return error; *stat = 1; @@ -419,19 +422,21 @@ xfs_alloc_delrec( * See if we can join with the left neighbor block. */ if (lbno != NULLAGBLOCK && - lrecs + be16_to_cpu(block->bb_numrecs) <= XFS_ALLOC_BLOCK_MAXRECS(level, cur)) { + lrecs + numrecs <= XFS_ALLOC_BLOCK_MAXRECS(level, cur)) { /* * Set "right" to be the starting block, * "left" to be the left neighbor. */ rbno = bno; right = block; + rrecs = be16_to_cpu(right->bb_numrecs); rbp = bp; if ((error = xfs_btree_read_bufs(mp, cur->bc_tp, cur->bc_private.a.agno, lbno, 0, &lbp, XFS_ALLOC_BTREE_REF))) return error; left = XFS_BUF_TO_ALLOC_BLOCK(lbp); + lrecs = be16_to_cpu(left->bb_numrecs); if ((error = xfs_btree_check_sblock(cur, left, level, lbp))) return error; } @@ -439,20 +444,21 @@ xfs_alloc_delrec( * If that won't work, see if we can join with the right neighbor block. */ else if (rbno != NULLAGBLOCK && - rrecs + be16_to_cpu(block->bb_numrecs) <= - XFS_ALLOC_BLOCK_MAXRECS(level, cur)) { + rrecs + numrecs <= XFS_ALLOC_BLOCK_MAXRECS(level, cur)) { /* * Set "left" to be the starting block, * "right" to be the right neighbor. */ lbno = bno; left = block; + lrecs = be16_to_cpu(left->bb_numrecs); lbp = bp; if ((error = xfs_btree_read_bufs(mp, cur->bc_tp, cur->bc_private.a.agno, rbno, 0, &rbp, XFS_ALLOC_BTREE_REF))) return error; right = XFS_BUF_TO_ALLOC_BLOCK(rbp); + rrecs = be16_to_cpu(right->bb_numrecs); if ((error = xfs_btree_check_sblock(cur, right, level, rbp))) return error; } @@ -474,34 +480,28 @@ xfs_alloc_delrec( /* * It's a non-leaf. Move keys and pointers. */ - lkp = XFS_ALLOC_KEY_ADDR(left, be16_to_cpu(left->bb_numrecs) + 1, cur); - lpp = XFS_ALLOC_PTR_ADDR(left, be16_to_cpu(left->bb_numrecs) + 1, cur); + lkp = XFS_ALLOC_KEY_ADDR(left, lrecs + 1, cur); + lpp = XFS_ALLOC_PTR_ADDR(left, lrecs + 1, cur); rkp = XFS_ALLOC_KEY_ADDR(right, 1, cur); rpp = XFS_ALLOC_PTR_ADDR(right, 1, cur); #ifdef DEBUG - for (i = 0; i < be16_to_cpu(right->bb_numrecs); i++) { + for (i = 0; i < rrecs; i++) { if ((error = xfs_btree_check_sptr(cur, be32_to_cpu(rpp[i]), level))) return error; } #endif - memcpy(lkp, rkp, be16_to_cpu(right->bb_numrecs) * sizeof(*lkp)); - memcpy(lpp, rpp, be16_to_cpu(right->bb_numrecs) * sizeof(*lpp)); - xfs_alloc_log_keys(cur, lbp, be16_to_cpu(left->bb_numrecs) + 1, - be16_to_cpu(left->bb_numrecs) + - be16_to_cpu(right->bb_numrecs)); - xfs_alloc_log_ptrs(cur, lbp, be16_to_cpu(left->bb_numrecs) + 1, - be16_to_cpu(left->bb_numrecs) + - be16_to_cpu(right->bb_numrecs)); + memcpy(lkp, rkp, rrecs * sizeof(*lkp)); + memcpy(lpp, rpp, rrecs * sizeof(*lpp)); + xfs_alloc_log_keys(cur, lbp, lrecs + 1, lrecs + rrecs); + xfs_alloc_log_ptrs(cur, lbp, lrecs + 1, lrecs + rrecs); } else { /* * It's a leaf. Move records. */ - lrp = XFS_ALLOC_REC_ADDR(left, be16_to_cpu(left->bb_numrecs) + 1, cur); + lrp = XFS_ALLOC_REC_ADDR(left, lrecs + 1, cur); rrp = XFS_ALLOC_REC_ADDR(right, 1, cur); - memcpy(lrp, rrp, be16_to_cpu(right->bb_numrecs) * sizeof(*lrp)); - xfs_alloc_log_recs(cur, lbp, be16_to_cpu(left->bb_numrecs) + 1, - be16_to_cpu(left->bb_numrecs) + - be16_to_cpu(right->bb_numrecs)); + memcpy(lrp, rrp, rrecs * sizeof(*lrp)); + xfs_alloc_log_recs(cur, lbp, lrecs + 1, lrecs + rrecs); } /* * If we joined with the left neighbor, set the buffer in the @@ -509,7 +509,7 @@ xfs_alloc_delrec( */ if (bp != lbp) { xfs_btree_setbuf(cur, level, lbp); - cur->bc_ptrs[level] += be16_to_cpu(left->bb_numrecs); + cur->bc_ptrs[level] += lrecs; } /* * If we joined with the right neighbor and there's a level above @@ -521,7 +521,8 @@ xfs_alloc_delrec( /* * Fix up the number of records in the surviving block. */ - be16_add(&left->bb_numrecs, be16_to_cpu(right->bb_numrecs)); + lrecs += rrecs; + left->bb_numrecs = cpu_to_be16(lrecs); /* * Fix up the right block pointer in the surviving block, and log it. */ @@ -608,6 +609,7 @@ xfs_alloc_insrec( xfs_btree_cur_t *ncur; /* new cursor to be used at next lvl */ xfs_alloc_key_t nkey; /* new key value, from split */ xfs_alloc_rec_t nrec; /* new record value, for caller */ + int numrecs; int optr; /* old ptr value */ xfs_alloc_ptr_t *pp; /* pointer to btree addresses */ int ptr; /* index in btree block for this rec */ @@ -653,13 +655,14 @@ xfs_alloc_insrec( */ bp = cur->bc_bufs[level]; block = XFS_BUF_TO_ALLOC_BLOCK(bp); + numrecs = be16_to_cpu(block->bb_numrecs); #ifdef DEBUG if ((error = xfs_btree_check_sblock(cur, block, level, bp))) return error; /* * Check that the new entry is being inserted in the right place. */ - if (ptr <= be16_to_cpu(block->bb_numrecs)) { + if (ptr <= numrecs) { if (level == 0) { rp = XFS_ALLOC_REC_ADDR(block, ptr, cur); xfs_btree_check_rec(cur->bc_btnum, recp, rp); @@ -675,7 +678,7 @@ xfs_alloc_insrec( * If the block is full, we can't insert the new entry until we * make the block un-full. */ - if (be16_to_cpu(block->bb_numrecs) == XFS_ALLOC_BLOCK_MAXRECS(level, cur)) { + if (numrecs == XFS_ALLOC_BLOCK_MAXRECS(level, cur)) { /* * First, try shifting an entry to the right neighbor. */ @@ -729,6 +732,7 @@ xfs_alloc_insrec( * At this point we know there's room for our new entry in the block * we're pointing at. */ + numrecs = be16_to_cpu(block->bb_numrecs); if (level > 0) { /* * It's a non-leaf entry. Make a hole for the new data @@ -737,15 +741,15 @@ xfs_alloc_insrec( kp = XFS_ALLOC_KEY_ADDR(block, 1, cur); pp = XFS_ALLOC_PTR_ADDR(block, 1, cur); #ifdef DEBUG - for (i = be16_to_cpu(block->bb_numrecs); i >= ptr; i--) { + for (i = numrecs; i >= ptr; i--) { if ((error = xfs_btree_check_sptr(cur, be32_to_cpu(pp[i - 1]), level))) return error; } #endif memmove(&kp[ptr], &kp[ptr - 1], - (be16_to_cpu(block->bb_numrecs) - ptr + 1) * sizeof(*kp)); + (numrecs - ptr + 1) * sizeof(*kp)); memmove(&pp[ptr], &pp[ptr - 1], - (be16_to_cpu(block->bb_numrecs) - ptr + 1) * sizeof(*pp)); + (numrecs - ptr + 1) * sizeof(*pp)); #ifdef DEBUG if ((error = xfs_btree_check_sptr(cur, *bnop, level))) return error; @@ -755,11 +759,12 @@ xfs_alloc_insrec( */ kp[ptr - 1] = key; pp[ptr - 1] = cpu_to_be32(*bnop); - be16_add(&block->bb_numrecs, 1); - xfs_alloc_log_keys(cur, bp, ptr, be16_to_cpu(block->bb_numrecs)); - xfs_alloc_log_ptrs(cur, bp, ptr, be16_to_cpu(block->bb_numrecs)); + numrecs++; + block->bb_numrecs = cpu_to_be16(numrecs); + xfs_alloc_log_keys(cur, bp, ptr, numrecs); + xfs_alloc_log_ptrs(cur, bp, ptr, numrecs); #ifdef DEBUG - if (ptr < be16_to_cpu(block->bb_numrecs)) + if (ptr < numrecs) xfs_btree_check_key(cur->bc_btnum, kp + ptr - 1, kp + ptr); #endif @@ -769,16 +774,17 @@ xfs_alloc_insrec( */ rp = XFS_ALLOC_REC_ADDR(block, 1, cur); memmove(&rp[ptr], &rp[ptr - 1], - (be16_to_cpu(block->bb_numrecs) - ptr + 1) * sizeof(*rp)); + (numrecs - ptr + 1) * sizeof(*rp)); /* * Now stuff the new record in, bump numrecs * and log the new data. */ rp[ptr - 1] = *recp; - be16_add(&block->bb_numrecs, 1); - xfs_alloc_log_recs(cur, bp, ptr, be16_to_cpu(block->bb_numrecs)); + numrecs++; + block->bb_numrecs = cpu_to_be16(numrecs); + xfs_alloc_log_recs(cur, bp, ptr, numrecs); #ifdef DEBUG - if (ptr < be16_to_cpu(block->bb_numrecs)) + if (ptr < numrecs) xfs_btree_check_rec(cur->bc_btnum, rp + ptr - 1, rp + ptr); #endif From owner-xfs@oss.sgi.com Tue Aug 22 00:58:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 22 Aug 2006 00:59:29 -0700 (PDT) Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7M7wrDW019663 for ; Tue, 22 Aug 2006 00:58:58 -0700 Received: from tyo202.gate.nec.co.jp ([10.7.69.202]) by tyo200.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k7M7w0JH014398 for ; Tue, 22 Aug 2006 16:58:08 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.161] (may be forged)) by tyo202.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k7M7mmHw018813; Tue, 22 Aug 2006 16:48:48 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id k7M7mm103027; Tue, 22 Aug 2006 16:48:48 +0900 (JST) Received: from anesfw.anes.nec.co.jp (fuji.anes.nec.co.jp [10.2.168.3]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id k7M7mmi01061; Tue, 22 Aug 2006 16:48:48 +0900 (JST) Received: from tnesg9212 (tnesg9212) by anesfw.anes.nec.co.jp (8.13.5/8.13.5) with SMTP id k7M7ml8I009479; Tue, 22 Aug 2006 16:48:47 +0900 To: David Chinner Cc: Nathan Scott , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] xfs: i_state of inode is changed after the inode is freed In-reply-to: <20060814025901.GE51703024@melbourne.sgi.com> Message-Id: <20060822164847m-saito@mail.aom.tnes.nec.co.jp> References: <20060814025901.GE51703024@melbourne.sgi.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Masayuki Saito Date: Tue, 22 Aug 2006 16:48:47 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8716 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: m-saito@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 1193 Lines: 45 Hi Nathan, David, I had the vacation too. David Chinner wrote: >Hmmm - Idon't think we should iput() before we wake up any pinned waiters. >When we have a waiter on i_ipin_wait (called from xfs_iflush()), we have >a thread sleeping with the inode locked. > >If we then call iput() and it drops the last reference, we can call back >into the filesystem and start transactions. Those transactions will need >to lock the inode. Hence I think the above can deadlock when racing against >an inode flush. > >The code should probably read: > > if (dropped last pincount) { > int need_iput = 0; > struct inode *inode; > > spin_lock(i_flags_lock) > if (!reclaimable) { > if (!vp) { > if (!(i_state & (NEW|CLEAR))) { > inode = igrab(inode) > if (inode) { > need_iput = 1 > mark_inode_dirty_sync(inode) > } > } > } > } > spin_unlock(i_flags_lock) > wake_up(&ip->i_ipin_wait) > if (need_iput) > iput(inode); > } > >to avoid this possible deadlock. OK, I see your point. There is wait_event(in xfs_iunpin_wait) that should be wake_up'ed(in xfs_iunpin), so deadlock can occur. I'll update my patch and test it. Please wait for a few moments. From owner-xfs@oss.sgi.com Tue Aug 22 14:55:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 22 Aug 2006 14:55:39 -0700 (PDT) Received: from mail.max-t.com (h216-18-124-229.gtcust.grouptelecom.net [216.18.124.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7MLtSDW000529 for ; Tue, 22 Aug 2006 14:55:29 -0700 Received: from madrid.max-t.internal ([192.168.1.189] ident=[U2FsdGVkX1+1JSQuQaWCtjqik/U9bLVPQ8fpQFKw9yA=]) by mail.max-t.com with esmtp (Exim 4.43) id 1GFcRd-0005J2-W1 for linux-xfs@oss.sgi.com; Tue, 22 Aug 2006 16:01:56 -0400 Date: Tue, 22 Aug 2006 16:01:10 -0400 (EDT) From: Stephane Doyon X-X-Sender: sdoyon@madrid.max-t.internal To: linux-xfs@oss.sgi.com Message-ID: MIME-Version: 1.0 Content-ID: X-SA-Exim-Connect-IP: 192.168.1.189 X-SA-Exim-Mail-From: sdoyon@max-t.com Subject: Infinite loop in xfssyncd on full file system Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed X-SA-Exim-Version: 4.1 (built Thu, 08 Sep 2005 14:17:48 -0500) X-SA-Exim-Scanned: Yes (on mail.max-t.com) X-archive-position: 8720 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sdoyon@max-t.com Precedence: bulk X-list: xfs Content-Length: 3389 Lines: 85 I'm seeing what appears to be an infinite loop in xfssyncd. It is triggered when writing to a file system that is full or nearly full. I have pinpointed the change that introduced this problem: it's "TAKE 947395 - Fixing potential deadlock in space allocation and freeing due to ENOSPC" git commit d210a28cd851082cec9b282443f8cc0e6fc09830. I first saw the problem with a 2.6.17 kernel patched to add the 2.6.18-rc* XFS changes. I later confirmed that 2.6.17 does not exhibit this behavior, while addding just that one commit brings the problem back. In the simplest case, I had a 7.5GB test file system, created with no mkfs.xfs option and mounted with no option. I filled it up, leaving half a GB free, simply using dd (single-threaded). Then I did while [ 1 ]; do dd if=/dev/zero of=f bs=1M; done or i=1; while [ 1 ]; do echo $i; dd if=/dev/zero of=f$i bs=1M; \ i=$(($i+1)); done and after very few iterations, my dd got stuck in uninterruptible sleep and I soon got: "BUG: soft lockup detected on CPU#1!" with xfssyncd at the bottom of the backtrace. I took a few backtraces using KDB, letting it run a bit between taking each backtrace. All backtraces I saw had xfssyncd doing: xfssyncd xfs_flush_inode_work filemap_flush __filemap_fdatawrite_range do_writepages xfs_vm_writepage xfs_page_state_convert xfs_map_blocks xfs_bmap xfs_iomap ... then I've seen either: xfs_iomap_write_allocate xfs_trans_reserve xfs_mod_incore_sb xfs_icsb_modify_counters xfs_icsb_modify_counters_int or xfs_iomap_write_allocate xfs_bmapi xfs_bmap_alloc xfs_bmap_btalloc xfs_alloc_vextent xfs_alloc_fix_freelist or xfs_icsb_balance_counter xfs_icsb_disable_counter or xfs_iomap_write_allocate xfs_trans_alloc _xfs_trans_alloc kmem_zone_zalloc dd is doing: sys_write vfs_write do_sync_write xfs_file_aio_write xfs_write generic_file_buffered_write xfs_get_blocks __xfs_get_blocks xfs_bmap xfs_iomap xfs_iomap_write_delay xfs_flush_space xfs_flush_device _xfs_log_force xlog_state_sync_all schedule_timeout. From then on, other processes start piling up because of the held locks, and if I'm patient enough, something on my machine eventually eats away all the memory... A similar problem was discussed here: http://oss.sgi.com/archives/xfs/2006-08/msg00144.html For some reason I can't seem to find the original bug submission either in the list archives or in your bugzilla... I would comment that I have preemption disabled. AFAICT this is not a matter of spinlocks being held for too long. The "soft lockup" should trigger if a CPU doesn't reschedule for more than 10secs. I saw the problem on two different machines, one has 8 pseudo CPUs (counting hyper-threading) and one has 4. Most of my tests were done using a fast external storage array. But I also tried it on a 1GB file system that I made in a file on an ordinary disk and mounted using the loopback device. The lockup did not happen with dd as before, but then I umount'ed the file system and umount hung, and I got the same soft lockup for xfssyncd as before. I hope you XFS experts see what might be wrong with that bug fix. It's ironic but for me, this (apparent) infinite loop seems much easier to hit than the out-of-order locking problem that the commit in question was supposed to fix. Let me know if I can get you any more info. Thanks From owner-xfs@oss.sgi.com Tue Aug 22 20:48:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 22 Aug 2006 20:48:16 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7N3lxDW023445 for ; Tue, 22 Aug 2006 20:48:05 -0700 Received: by sandeen.net (Postfix, from userid 500) id AD5B418DAFEC7; Tue, 22 Aug 2006 22:47:19 -0500 (CDT) To: xfs@oss.sgi.com Subject: [PATCH] standardize on one sema init macro Message-Id: <20060823034719.AD5B418DAFEC7@sandeen.net> Date: Tue, 22 Aug 2006 22:47:19 -0500 (CDT) From: sandeen@sandeen.net X-archive-position: 8721 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1620 Lines: 52 One sema to rule them all, one sema to find them... how many sema init routines does one really need after all? Signed-off-by: Eric Sandeen linux-2.4/sema.h | 2 -- linux-2.6/sema.h | 2 -- xfs_iget.c | 2 +- 3 files changed, 1 insertion(+), 5 deletions(-) Index: xfs-linux/linux-2.4/sema.h =================================================================== --- xfs-linux.orig/linux-2.4/sema.h +++ xfs-linux/linux-2.4/sema.h @@ -29,8 +29,6 @@ typedef struct semaphore sema_t; -#define init_sema(sp, val, c, d) sema_init(sp, val) -#define initsema(sp, val) sema_init(sp, val) #define initnsema(sp, val, name) sema_init(sp, val) #define psema(sp, b) down(sp) #define vsema(sp) up(sp) Index: xfs-linux/linux-2.6/sema.h =================================================================== --- xfs-linux.orig/linux-2.6/sema.h +++ xfs-linux/linux-2.6/sema.h @@ -29,8 +29,6 @@ typedef struct semaphore sema_t; -#define init_sema(sp, val, c, d) sema_init(sp, val) -#define initsema(sp, val) sema_init(sp, val) #define initnsema(sp, val, name) sema_init(sp, val) #define psema(sp, b) down(sp) #define vsema(sp) up(sp) Index: xfs-linux/xfs_iget.c =================================================================== --- xfs-linux.orig/xfs_iget.c +++ xfs-linux/xfs_iget.c @@ -546,7 +546,7 @@ xfs_inode_lock_init( mrlock_init(&ip->i_iolock, MRLOCK_BARRIER, "xfsio", vp->v_number); init_waitqueue_head(&ip->i_ipin_wait); atomic_set(&ip->i_pincount, 0); - init_sema(&ip->i_flock, 1, "xfsfino", vp->v_number); + initnsema(&ip->i_flock, 1, "xfsfino"); } /* From owner-xfs@oss.sgi.com Tue Aug 22 21:03:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 22 Aug 2006 21:03:51 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7N43EDW026902 for ; Tue, 22 Aug 2006 21:03:25 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA09727; Wed, 23 Aug 2006 14:02:24 +1000 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 k7N42LeQ821121; Wed, 23 Aug 2006 14:02:22 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7N42ILn821201; Wed, 23 Aug 2006 14:02:18 +1000 (AEST) Date: Wed, 23 Aug 2006 14:02:18 +1000 From: David Chinner To: Stephane Doyon Cc: linux-xfs@oss.sgi.com, lnx1138@us.ibm.com Subject: Re: Infinite loop in xfssyncd on full file system Message-ID: <20060823040218.GC807872@melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 8722 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1080 Lines: 31 On Tue, Aug 22, 2006 at 04:01:10PM -0400, Stephane Doyon wrote: > I'm seeing what appears to be an infinite loop in xfssyncd. It is > triggered when writing to a file system that is full or nearly full. I > have pinpointed the change that introduced this problem: it's > > "TAKE 947395 - Fixing potential deadlock in space allocation and > freeing due to ENOSPC" > > git commit d210a28cd851082cec9b282443f8cc0e6fc09830. Thanks for tracking that down - I've been trying to isolate a test case for another report of this looping in xfssyncd. [Luciano - this is the same problem we've been trying to track down.] > I hope you XFS experts see what might be wrong with that bug fix. It's > ironic but for me, this (apparent) infinite loop seems much easier to hit > than the out-of-order locking problem that the commit in question was > supposed to fix. Let me know if I can get you any more info. Now we know what patch introduces the problem, we know where to look. Stay tuned... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Aug 22 21:49:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 22 Aug 2006 21:50:08 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7N4nODW001957 for ; Tue, 22 Aug 2006 21:49:38 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10599; Wed, 23 Aug 2006 14:48:35 +1000 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 k7N4mWeQ830343; Wed, 23 Aug 2006 14:48:33 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7N4mUHa830543; Wed, 23 Aug 2006 14:48:30 +1000 (AEST) Date: Wed, 23 Aug 2006 14:48:30 +1000 From: David Chinner To: Stephane Doyon Cc: linux-xfs@oss.sgi.com, lnx1138@us.ibm.com Subject: Re: Infinite loop in xfssyncd on full file system Message-ID: <20060823044829.GD807872@melbourne.sgi.com> References: <20060823040218.GC807872@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060823040218.GC807872@melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8725 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2313 Lines: 64 On Wed, Aug 23, 2006 at 02:02:18PM +1000, David Chinner wrote: > On Tue, Aug 22, 2006 at 04:01:10PM -0400, Stephane Doyon wrote: > > I'm seeing what appears to be an infinite loop in xfssyncd. It is > > triggered when writing to a file system that is full or nearly full. I > > have pinpointed the change that introduced this problem: it's > > > > "TAKE 947395 - Fixing potential deadlock in space allocation and > > freeing due to ENOSPC" > > > > git commit d210a28cd851082cec9b282443f8cc0e6fc09830. > > Thanks for tracking that down - I've been trying to isolate a test case > for another report of this looping in xfssyncd. > > [Luciano - this is the same problem we've been trying to track down.] > > > I hope you XFS experts see what might be wrong with that bug fix. It's > > ironic but for me, this (apparent) infinite loop seems much easier to hit > > than the out-of-order locking problem that the commit in question was > > supposed to fix. Let me know if I can get you any more info. > > Now we know what patch introduces the problem, we know where to look. > Stay tuned... I've had a quick look at the above commit. I'm not yet certain that everything is correct in terms of the semantics laid down in the change or that enough blocks are reserved for btree splits , but I can see a hole in the implementation on multiprocessor machines. Stephane/Luciano - can you test the following patch (note: compile tested only) and see if it fixes the problem? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_mount.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c 2006-08-18 15:29:28.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c 2006-08-23 14:28:18.059385018 +1000 @@ -2108,11 +2108,11 @@ again: case XFS_SBS_FDBLOCKS: BUG_ON((mp->m_resblks - mp->m_resblks_avail) != 0); - lcounter = icsbp->icsb_fdblocks; + lcounter = icsbp->icsb_fdblocks - SET_ASIDE_BLOCKS; lcounter += delta; if (unlikely(lcounter < 0)) goto slow_path; - icsbp->icsb_fdblocks = lcounter; + icsbp->icsb_fdblocks = lcounter + SET_ASIDE_BLOCKS; break; default: BUG(); From owner-xfs@oss.sgi.com Wed Aug 23 04:23:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 23 Aug 2006 04:24:06 -0700 (PDT) Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7NBNdDW023910 for ; Wed, 23 Aug 2006 04:23:40 -0700 Received: from tyo201.gate.nec.co.jp ([10.7.69.201]) by tyo200.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k7NBN0If015780 for ; Wed, 23 Aug 2006 20:23:03 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.162] (may be forged)) by tyo201.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k7NBCdDF027404; Wed, 23 Aug 2006 20:12:39 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id k7NBCdb04378; Wed, 23 Aug 2006 20:12:39 +0900 (JST) Received: from anesfw.anes.nec.co.jp (fuji.anes.nec.co.jp [10.2.168.3]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id k7NBCdg12110; Wed, 23 Aug 2006 20:12:39 +0900 (JST) Received: from tnesg9212 (tnesg9212) by anesfw.anes.nec.co.jp (8.13.5/8.13.5) with SMTP id k7NBCcZR001282; Wed, 23 Aug 2006 20:12:38 +0900 To: Nathan Scott , David Chinner Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [PATCH 1/2] Add new spin_lock for i_flags of xfs_inode [try #2] Message-Id: <20060823201251m-saito@mail.aom.tnes.nec.co.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Masayuki Saito Date: Wed, 23 Aug 2006 20:12:51 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8726 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: m-saito@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 5336 Lines: 160 It is the problem that i_flags of xfs_inode has no consistent locking protection. For the reason, I define a new spin_lock(i_flags_lock) for i_flags of xfs_inode. And I add this spin_lock for appropriate places. I divided into two patches. A summary of patches is as follows. [1/2] add a new lock for i_flags of xfs_inode [2/2] fix i_state of the inode is changed after the inode is freed The following changes were made in [try #2]: [1/2] Nothing [2/2] wake_up() is done before iput() in xfs_iunpin(). I have tested the two patches and confirmed with these patches that the inode of i_state is not changed after the inode is freed. Appreciate any comments and feedbacks. Signed-off-by: Masayuki Saito Signed-off-by: ASANO Masahiro --- --- linux-2.6.17.7/fs/xfs/xfs_inode.h.orig 2006-07-29 15:41:28.570341641 +0900 +++ linux-2.6.17.7/fs/xfs/xfs_inode.h 2006-08-01 02:51:53.598587423 +0900 @@ -267,6 +267,7 @@ typedef struct xfs_inode { sema_t i_flock; /* inode flush lock */ atomic_t i_pincount; /* inode pin count */ wait_queue_head_t i_ipin_wait; /* inode pinning wait queue */ + spinlock_t i_flags_lock; /* inode i_flags lock */ #ifdef HAVE_REFCACHE struct xfs_inode **i_refcache; /* ptr to entry in ref cache */ struct xfs_inode *i_release; /* inode to unref */ --- linux-2.6.17.7/fs/xfs/xfs_inode.c.orig 2006-07-29 15:41:39.050936181 +0900 +++ linux-2.6.17.7/fs/xfs/xfs_inode.c 2006-08-01 14:13:51.615782806 +0900 @@ -861,6 +861,7 @@ xfs_iread( ip = kmem_zone_zalloc(xfs_inode_zone, KM_SLEEP); ip->i_ino = ino; ip->i_mount = mp; + spin_lock_init(&ip->i_flags_lock); /* * Get pointer's to the on-disk inode and the buffer containing it. @@ -2204,7 +2205,9 @@ xfs_ifree_cluster( if (ip == free_ip) { if (xfs_iflock_nowait(ip)) { + spin_lock(&ip->i_flags_lock); ip->i_flags |= XFS_ISTALE; + spin_unlock(&ip->i_flags_lock); if (xfs_inode_clean(ip)) { xfs_ifunlock(ip); @@ -2218,7 +2221,9 @@ xfs_ifree_cluster( if (xfs_ilock_nowait(ip, XFS_ILOCK_EXCL)) { if (xfs_iflock_nowait(ip)) { + spin_lock(&ip->i_flags_lock); ip->i_flags |= XFS_ISTALE; + spin_unlock(&ip->i_flags_lock); if (xfs_inode_clean(ip)) { xfs_ifunlock(ip); @@ -2248,7 +2253,9 @@ xfs_ifree_cluster( AIL_LOCK(mp,s); iip->ili_flush_lsn = iip->ili_item.li_lsn; AIL_UNLOCK(mp, s); + spin_lock(&iip->ili_inode->i_flags_lock); iip->ili_inode->i_flags |= XFS_ISTALE; + spin_unlock(&iip->ili_inode->i_flags_lock); pre_flushed++; } lip = lip->li_bio_list; --- linux-2.6.17.7/fs/xfs/xfs_itable.c.orig 2006-07-29 15:41:52.071674818 +0900 +++ linux-2.6.17.7/fs/xfs/xfs_itable.c 2006-08-01 02:51:53.698593096 +0900 @@ -559,6 +559,7 @@ xfs_bulkstat( KM_SLEEP); ip->i_ino = ino; ip->i_mount = mp; + spin_lock_init(&ip->i_flags_lock); if (bp) xfs_buf_relse(bp); error = xfs_itobp(mp, NULL, ip, --- linux-2.6.17.7/fs/xfs/xfs_iget.c.orig 2006-07-29 15:42:03.992351051 +0900 +++ linux-2.6.17.7/fs/xfs/xfs_iget.c 2006-08-01 21:17:58.173213088 +0900 @@ -246,7 +246,9 @@ again: XFS_STATS_INC(xs_ig_found); + spin_lock(&ip->i_flags_lock); ip->i_flags &= ~XFS_IRECLAIMABLE; + spin_unlock(&ip->i_flags_lock); version = ih->ih_version; read_unlock(&ih->ih_lock); xfs_ihash_promote(ih, ip, version); @@ -300,7 +302,9 @@ finish_inode: if (lock_flags != 0) xfs_ilock(ip, lock_flags); + spin_lock(&ip->i_flags_lock); ip->i_flags &= ~XFS_ISTALE; + spin_unlock(&ip->i_flags_lock); vn_trace_exit(vp, "xfs_iget.found", (inst_t *)__return_address); @@ -371,7 +375,9 @@ finish_inode: ih->ih_next = ip; ip->i_udquot = ip->i_gdquot = NULL; ih->ih_version++; + spin_lock(&ip->i_flags_lock); ip->i_flags |= XFS_INEW; + spin_unlock(&ip->i_flags_lock); write_unlock(&ih->ih_lock); --- linux-2.6.17.7/fs/xfs/xfs_vnodeops.c.orig 2006-07-29 15:42:40.182404031 +0900 +++ linux-2.6.17.7/fs/xfs/xfs_vnodeops.c 2006-08-02 03:43:12.163597123 +0900 @@ -3836,7 +3836,9 @@ xfs_reclaim( XFS_MOUNT_ILOCK(mp); vn_bhv_remove(VN_BHV_HEAD(vp), XFS_ITOBHV(ip)); list_add_tail(&ip->i_reclaim, &mp->m_del_inodes); + spin_lock(&ip->i_flags_lock); ip->i_flags |= XFS_IRECLAIMABLE; + spin_unlock(&ip->i_flags_lock); XFS_MOUNT_IUNLOCK(mp); } return 0; @@ -3861,8 +3863,10 @@ xfs_finish_reclaim( * us. */ write_lock(&ih->ih_lock); + spin_lock(&ip->i_flags_lock); if ((ip->i_flags & XFS_IRECLAIM) || (!(ip->i_flags & XFS_IRECLAIMABLE) && vp == NULL)) { + spin_unlock(&ip->i_flags_lock); write_unlock(&ih->ih_lock); if (locked) { xfs_ifunlock(ip); @@ -3871,6 +3875,7 @@ xfs_finish_reclaim( return 1; } ip->i_flags |= XFS_IRECLAIM; + spin_unlock(&ip->i_flags_lock); write_unlock(&ih->ih_lock); /* --- linux-2.6.17.7/fs/xfs/linux-2.6/xfs_super.c.orig 2006-07-29 15:43:17.768536207 +0900 +++ linux-2.6.17.7/fs/xfs/linux-2.6/xfs_super.c 2006-08-01 13:23:09.934740893 +0900 @@ -230,7 +230,9 @@ xfs_initialize_vnode( xfs_revalidate_inode(XFS_BHVTOM(bdp), vp, ip); xfs_set_inodeops(inode); + spin_lock(&ip->i_flags_lock); ip->i_flags &= ~XFS_INEW; + spin_unlock(&ip->i_flags_lock); barrier(); unlock_new_inode(inode); From owner-xfs@oss.sgi.com Wed Aug 23 04:23:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 23 Aug 2006 04:24:13 -0700 (PDT) Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7NBNdDW023907 for ; Wed, 23 Aug 2006 04:23:40 -0700 Received: from tyo201.gate.nec.co.jp ([10.7.69.201]) by tyo200.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k7NBN0Id015780 for ; Wed, 23 Aug 2006 20:23:03 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.162] (may be forged)) by tyo201.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k7NBEah7028574; Wed, 23 Aug 2006 20:14:36 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id k7NBEaH06462; Wed, 23 Aug 2006 20:14:36 +0900 (JST) Received: from anesfw.anes.nec.co.jp (fuji.anes.nec.co.jp [10.2.168.3]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id k7NBEYg13792; Wed, 23 Aug 2006 20:14:35 +0900 (JST) Received: from tnesg9212 (tnesg9212) by anesfw.anes.nec.co.jp (8.13.5/8.13.5) with SMTP id k7NBEWqx001333; Wed, 23 Aug 2006 20:14:32 +0900 To: Nathan Scott , David Chinner Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] Fix i_state of inode is changed after the inode is freed [try #2] Message-Id: <20060823201445m-saito@mail.aom.tnes.nec.co.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Masayuki Saito Date: Wed, 23 Aug 2006 20:14:45 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8727 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: m-saito@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 1163 Lines: 42 Fix i_state of the inode is changed after the inode is freed. Signed-off-by: Masayuki Saito Signed-off-by: ASANO Masahiro --- --- linux-2.6.17.7/fs/xfs/xfs_inode.c.orig 2006-08-21 20:15:58.385211286 +0900 +++ linux-2.6.17.7/fs/xfs/xfs_inode.c 2006-08-21 21:21:22.277033371 +0900 @@ -2751,18 +2751,30 @@ xfs_iunpin( * call as the inode reclaim may be blocked waiting for * the inode to become unpinned. */ + int need_iput = 0; + struct inode *inode; + spin_lock(&ip->i_flags_lock); if (!(ip->i_flags & (XFS_IRECLAIM|XFS_IRECLAIMABLE))) { vnode_t *vp = XFS_ITOV_NULL(ip); /* make sync come back and flush this inode */ if (vp) { - struct inode *inode = vn_to_inode(vp); + inode = vn_to_inode(vp); - if (!(inode->i_state & I_NEW)) - mark_inode_dirty_sync(inode); + if (!(inode->i_state & + (I_NEW|I_FREEING|I_CLEAR))) { + inode = igrab(inode); + if (inode) { + need_iput = 1; + mark_inode_dirty_sync(inode); + } + } } } + spin_unlock(&ip->i_flags_lock); wake_up(&ip->i_ipin_wait); + if (need_iput) + iput(inode); } } From owner-xfs@oss.sgi.com Wed Aug 23 11:39:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 23 Aug 2006 11:39:50 -0700 (PDT) Received: from aaru9.neoplus.adsl.tpnet.pl (aarj103.neoplus.adsl.tpnet.pl [83.5.195.103]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7NIdWDW015020 for ; Wed, 23 Aug 2006 11:39:36 -0700 Received: from satan.blackhosts (localhost [127.0.0.1]) by aaru9.neoplus.adsl.tpnet.pl (8.13.8/8.13.8) with ESMTP id k7NHg2lL021618 for ; Wed, 23 Aug 2006 19:42:03 +0200 Received: (from qboosh@localhost) by satan.blackhosts (8.13.8/8.13.8/Submit) id k7NHg2WC021615 for linux-xfs@oss.sgi.com; Wed, 23 Aug 2006 19:42:02 +0200 Date: Wed, 23 Aug 2006 19:42:01 +0200 From: Jakub Bogusz To: linux-xfs@oss.sgi.com Subject: Polish translation update for xfsprogs 2.8.11 Message-ID: <20060823174201.GA21590@fngna.oyu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Black Hosts X-Disclaimer: speaking only for myself User-Agent: Mutt/1.5.9i X-archive-position: 8732 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: qboosh@pld-linux.org Precedence: bulk X-list: xfs Content-Length: 184 Lines: 11 Hello, I updated Polish translation for xfsprogs. New pl.po file is available at: http://qboosh.cs.net.pl/pl.po/xfsprogs-2.8.11.pl.po -- Jakub Bogusz http://qboosh.cs.net.pl/ From owner-xfs@oss.sgi.com Wed Aug 23 11:56:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 23 Aug 2006 11:56:31 -0700 (PDT) Received: from mail.max-t.com (h216-18-124-229.gtcust.grouptelecom.net [216.18.124.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7NIu5DW020946 for ; Wed, 23 Aug 2006 11:56:06 -0700 Received: from madrid.max-t.internal ([192.168.1.189] ident=[U2FsdGVkX18aoZVhunNO6PEKvoU0ekPgxoFeGJZzAN8=]) by mail.max-t.com with esmtp (Exim 4.43) id 1GFuEU-000079-2R; Wed, 23 Aug 2006 11:01:30 -0400 Date: Wed, 23 Aug 2006 11:00:43 -0400 (EDT) From: Stephane Doyon X-X-Sender: sdoyon@madrid.max-t.internal To: David Chinner cc: linux-xfs@oss.sgi.com, lnx1138@us.ibm.com In-Reply-To: <20060823044829.GD807872@melbourne.sgi.com> Message-ID: References: <20060823040218.GC807872@melbourne.sgi.com> <20060823044829.GD807872@melbourne.sgi.com> MIME-Version: 1.0 X-SA-Exim-Connect-IP: 192.168.1.189 X-SA-Exim-Mail-From: sdoyon@max-t.com Subject: Re: Infinite loop in xfssyncd on full file system Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Version: 4.1 (built Thu, 08 Sep 2005 14:17:48 -0500) X-SA-Exim-Scanned: Yes (on mail.max-t.com) X-archive-position: 8737 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sdoyon@max-t.com Precedence: bulk X-list: xfs Content-Length: 1885 Lines: 45 On Wed, 23 Aug 2006, David Chinner wrote: > On Wed, Aug 23, 2006 at 02:02:18PM +1000, David Chinner wrote: >> On Tue, Aug 22, 2006 at 04:01:10PM -0400, Stephane Doyon wrote: >>> I'm seeing what appears to be an infinite loop in xfssyncd. It is >>> triggered when writing to a file system that is full or nearly full. I >>> have pinpointed the change that introduced this problem: it's >>> >>> "TAKE 947395 - Fixing potential deadlock in space allocation and >>> freeing due to ENOSPC" >>> >>> git commit d210a28cd851082cec9b282443f8cc0e6fc09830. >> >> Thanks for tracking that down - I've been trying to isolate a test case >> for another report of this looping in xfssyncd. >> >> [Luciano - this is the same problem we've been trying to track down.] >> >>> I hope you XFS experts see what might be wrong with that bug fix. It's >>> ironic but for me, this (apparent) infinite loop seems much easier to hit >>> than the out-of-order locking problem that the commit in question was >>> supposed to fix. Let me know if I can get you any more info. >> >> Now we know what patch introduces the problem, we know where to look. >> Stay tuned... > > I've had a quick look at the above commit. I'm not yet certain that > everything is correct in terms of the semantics laid down in the > change or that enough blocks are reserved for btree splits , but I I actually tried, naively, to bump up SET_ASIDE_BLOCKS from 8 to 32. I won't claim to understand half of what's going on but I wondered whether that might make the problem noticeably harder to reproduce at least, but it had no effect ;-). > can see a hole in the implementation on multiprocessor machines. > > Stephane/Luciano - can you test the following patch (note: compile > tested only) and see if it fixes the problem? I just tried it, unfortunately no effect. Stil went into a loop, on the second attempt. Thanks From owner-xfs@oss.sgi.com Wed Aug 23 14:18:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 23 Aug 2006 14:18:49 -0700 (PDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.150]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7NLIWDW024689 for ; Wed, 23 Aug 2006 14:18:33 -0700 Received: from e3.ny.us.ibm.com ([192.168.1.103]) by pokfb.esmtp.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7NJAdkg006818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Aug 2006 15:10:52 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e3.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7NJAJtt003942 for ; Wed, 23 Aug 2006 15:10:19 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7NJ9YHP250018 for ; Wed, 23 Aug 2006 13:09:34 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7NJ9Ypn008122 for ; Wed, 23 Aug 2006 13:09:34 -0600 Received: from sig-9-65-81-251.mts.ibm.com (sig-9-65-81-251.mts.ibm.com [9.65.81.251]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7NJ9WPG007927; Wed, 23 Aug 2006 13:09:32 -0600 Subject: Re: Infinite loop in xfssyncd on full file system From: Luciano Chavez To: Stephane Doyon Cc: David Chinner , linux-xfs@oss.sgi.com In-Reply-To: References: <20060823040218.GC807872@melbourne.sgi.com> <20060823044829.GD807872@melbourne.sgi.com> Content-Type: text/plain Organization: IBM Date: Wed, 23 Aug 2006 14:10:59 -0500 Message-Id: <1156360259.5368.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-archive-position: 8741 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lnx1138@us.ibm.com Precedence: bulk X-list: xfs Content-Length: 2127 Lines: 53 On Wed, 2006-08-23 at 11:00 -0400, Stephane Doyon wrote: > On Wed, 23 Aug 2006, David Chinner wrote: > > > On Wed, Aug 23, 2006 at 02:02:18PM +1000, David Chinner wrote: > >> On Tue, Aug 22, 2006 at 04:01:10PM -0400, Stephane Doyon wrote: > >>> I'm seeing what appears to be an infinite loop in xfssyncd. It is > >>> triggered when writing to a file system that is full or nearly full. I > >>> have pinpointed the change that introduced this problem: it's > >>> > >>> "TAKE 947395 - Fixing potential deadlock in space allocation and > >>> freeing due to ENOSPC" > >>> > >>> git commit d210a28cd851082cec9b282443f8cc0e6fc09830. > >> > >> Thanks for tracking that down - I've been trying to isolate a test case > >> for another report of this looping in xfssyncd. > >> > >> [Luciano - this is the same problem we've been trying to track down.] > >> > >>> I hope you XFS experts see what might be wrong with that bug fix. It's > >>> ironic but for me, this (apparent) infinite loop seems much easier to hit > >>> than the out-of-order locking problem that the commit in question was > >>> supposed to fix. Let me know if I can get you any more info. > >> > >> Now we know what patch introduces the problem, we know where to look. > >> Stay tuned... > > > > I've had a quick look at the above commit. I'm not yet certain that > > everything is correct in terms of the semantics laid down in the > > change or that enough blocks are reserved for btree splits , but I > > I actually tried, naively, to bump up SET_ASIDE_BLOCKS from 8 to 32. I > won't claim to understand half of what's going on but I wondered whether > that might make the problem noticeably harder to reproduce at least, but > it had no effect ;-). > > > can see a hole in the implementation on multiprocessor machines. > > > > Stephane/Luciano - can you test the following patch (note: compile > > tested only) and see if it fixes the problem? > > I just tried it, unfortunately no effect. Stil went into a loop, on the > second attempt. > Yes, unfortunetly it had no effect here either. > Thanks > -- Luciano Chavez IBM From owner-xfs@oss.sgi.com Wed Aug 23 16:15:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 23 Aug 2006 16:16:05 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7NNFNDW014352 for ; Wed, 23 Aug 2006 16:15:34 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA05279; Thu, 24 Aug 2006 09:14:34 +1000 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 k7NNEVeQ1576054; Thu, 24 Aug 2006 09:14:32 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7NNETJT1575961; Thu, 24 Aug 2006 09:14:29 +1000 (AEST) Date: Thu, 24 Aug 2006 09:14:29 +1000 From: David Chinner To: Stephane Doyon , Luciano Chavez Cc: linux-xfs@oss.sgi.com Subject: Re: Infinite loop in xfssyncd on full file system Message-ID: <20060823231429.GF807872@melbourne.sgi.com> References: <20060823040218.GC807872@melbourne.sgi.com> <20060823044829.GD807872@melbourne.sgi.com> <1156360259.5368.7.camel@localhost> <20060823040218.GC807872@melbourne.sgi.com> <20060823044829.GD807872@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1156360259.5368.7.camel@localhost> User-Agent: Mutt/1.4.2.1i X-archive-position: 8742 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1920 Lines: 55 On Wed, Aug 23, 2006 at 11:00:43AM -0400, Stephane Doyon wrote: > On Wed, 23 Aug 2006, David Chinner wrote: > > >On Wed, Aug 23, 2006 at 02:02:18PM +1000, David Chinner wrote: > >>On Tue, Aug 22, 2006 at 04:01:10PM -0400, Stephane Doyon wrote: > >>>I'm seeing what appears to be an infinite loop in xfssyncd. It is > >>>triggered when writing to a file system that is full or nearly full. I > >>>have pinpointed the change that introduced this problem: it's > >>> > >>> "TAKE 947395 - Fixing potential deadlock in space allocation and > >>> freeing due to ENOSPC" > >>> > >>>git commit d210a28cd851082cec9b282443f8cc0e6fc09830. ..... > >>Now we know what patch introduces the problem, we know where to look. > >>Stay tuned... > > > >I've had a quick look at the above commit. I'm not yet certain that > >everything is correct in terms of the semantics laid down in the > >change or that enough blocks are reserved for btree splits , but I > > I actually tried, naively, to bump up SET_ASIDE_BLOCKS from 8 to 32. I > won't claim to understand half of what's going on but I wondered whether > that might make the problem noticeably harder to reproduce at least, but > it had no effect ;-). That was going to be my next question. ;) At least that rules out a small error in the block reservation decision, so I'm going to have analyse all the code paths the mod introduced and work out what is going wrong. > >Stephane/Luciano - can you test the following patch (note: compile > >tested only) and see if it fixes the problem? > > I just tried it, unfortunately no effect. Stil went into a loop, on the > second attempt. On Wed, Aug 23, 2006 at 02:10:59PM -0500, Luciano Chavez wrote: > > Yes, unfortunetly it had no effect here either. Thanks for trying. I'll get back to you both when I have something new to report. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Aug 23 22:47:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 23 Aug 2006 22:47:48 -0700 (PDT) Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7O5lWDW025919 for ; Wed, 23 Aug 2006 22:47:32 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id k7O4cJnW017069 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Aug 2006 21:38:19 -0700 Received: from box (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id k7O4cHvA021140; Wed, 23 Aug 2006 21:38:18 -0700 Date: Wed, 23 Aug 2006 21:38:17 -0700 From: Andrew Morton To: Masayuki Saito Cc: Nathan Scott , David Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] Add new spin_lock for i_flags of xfs_inode [try #2] Message-Id: <20060823213817.16cdfe8a.akpm@osdl.org> In-Reply-To: <20060823201251m-saito@mail.aom.tnes.nec.co.jp> References: <20060823201251m-saito@mail.aom.tnes.nec.co.jp> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.142 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 8745 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: xfs Content-Length: 480 Lines: 13 On Wed, 23 Aug 2006 20:12:51 +0900 Masayuki Saito wrote: > It is the problem that i_flags of xfs_inode has no consistent > locking protection. > > For the reason, I define a new spin_lock(i_flags_lock) for i_flags > of xfs_inode. And I add this spin_lock for appropriate places. You could simply use inode.i_lock for this. i_lock is a general-purpose per-inode lock. Its mandate is "use it for whatever you like, but it must always be `innermost'" From owner-xfs@oss.sgi.com Wed Aug 23 22:47:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 23 Aug 2006 22:47:42 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7O5lEDW025875 for ; Wed, 23 Aug 2006 22:47:25 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA14294; Thu, 24 Aug 2006 15:46:26 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7O5kMgw3004320; Thu, 24 Aug 2006 15:46:23 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7O5kIoD3007348; Thu, 24 Aug 2006 15:46:18 +1000 (EST) Date: Thu, 24 Aug 2006 15:46:18 +1000 From: Nathan Scott To: Masayuki Saito , Andrew Morton Cc: David Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] Add new spin_lock for i_flags of xfs_inode [try #2] Message-ID: <20060824154618.E3001216@wobbly.melbourne.sgi.com> References: <20060823201251m-saito@mail.aom.tnes.nec.co.jp> <20060823213817.16cdfe8a.akpm@osdl.org> <20060824154245.D3001216@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060824154245.D3001216@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Thu, Aug 24, 2006 at 03:42:45PM +1000 X-archive-position: 8744 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1114 Lines: 29 On Thu, Aug 24, 2006 at 03:42:45PM +1000, Nathan Scott wrote: > On Wed, Aug 23, 2006 at 09:38:17PM -0700, Andrew Morton wrote: > > On Wed, 23 Aug 2006 20:12:51 +0900 > > Masayuki Saito wrote: > > > > > It is the problem that i_flags of xfs_inode has no consistent > > > locking protection. > > > > > > For the reason, I define a new spin_lock(i_flags_lock) for i_flags > > > of xfs_inode. And I add this spin_lock for appropriate places. > > > > You could simply use inode.i_lock for this. i_lock is a general-purpose > > per-inode lock. Its mandate is "use it for whatever you like, but it must > > always be `innermost'" > > Sounds spot on for our needs here, and has the added benefit of > not increasing the size of the inode (as well as not adding to > our locking complexity). Thanks! Oh, except that the generic inode has a different lifecycle to the xfs_inode_t, which is going to prevent using this. Doh. I had also looked at the other xfs_inode locks before, but not seen an easy way to piggyback on those... perhaps a way could be found though. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Aug 23 22:44:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 23 Aug 2006 22:44:32 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7O5hlDW025191 for ; Wed, 23 Aug 2006 22:44:01 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA14078; Thu, 24 Aug 2006 15:42:56 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7O5gqgw3002224; Thu, 24 Aug 2006 15:42:53 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7O5gjUr2974976; Thu, 24 Aug 2006 15:42:45 +1000 (EST) Date: Thu, 24 Aug 2006 15:42:45 +1000 From: Nathan Scott To: Masayuki Saito , Andrew Morton Cc: David Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] Add new spin_lock for i_flags of xfs_inode [try #2] Message-ID: <20060824154245.D3001216@wobbly.melbourne.sgi.com> References: <20060823201251m-saito@mail.aom.tnes.nec.co.jp> <20060823213817.16cdfe8a.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060823213817.16cdfe8a.akpm@osdl.org>; from akpm@osdl.org on Wed, Aug 23, 2006 at 09:38:17PM -0700 X-archive-position: 8743 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 750 Lines: 23 On Wed, Aug 23, 2006 at 09:38:17PM -0700, Andrew Morton wrote: > On Wed, 23 Aug 2006 20:12:51 +0900 > Masayuki Saito wrote: > > > It is the problem that i_flags of xfs_inode has no consistent > > locking protection. > > > > For the reason, I define a new spin_lock(i_flags_lock) for i_flags > > of xfs_inode. And I add this spin_lock for appropriate places. > > You could simply use inode.i_lock for this. i_lock is a general-purpose > per-inode lock. Its mandate is "use it for whatever you like, but it must > always be `innermost'" Sounds spot on for our needs here, and has the added benefit of not increasing the size of the inode (as well as not adding to our locking complexity). Thanks! cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Aug 24 00:18:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 00:18:20 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7O7HpDW012897 for ; Thu, 24 Aug 2006 00:18:03 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA16171; Thu, 24 Aug 2006 17:17:01 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7O7Gwgw2980400; Thu, 24 Aug 2006 17:16:59 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7O7GrBw3005293; Thu, 24 Aug 2006 17:16:53 +1000 (EST) Date: Thu, 24 Aug 2006 17:16:53 +1000 From: Nathan Scott To: Masayuki Saito , David Chinner Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] Fix i_state of inode is changed after the inode is freed [try #2] Message-ID: <20060824171653.C3003989@wobbly.melbourne.sgi.com> References: <20060823201445m-saito@mail.aom.tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060823201445m-saito@mail.aom.tnes.nec.co.jp>; from m-saito@tnes.nec.co.jp on Wed, Aug 23, 2006 at 08:14:45PM +0900 X-archive-position: 8748 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1758 Lines: 64 On Wed, Aug 23, 2006 at 08:14:45PM +0900, Masayuki Saito wrote: > Fix i_state of the inode is changed after the inode is freed. > > Signed-off-by: Masayuki Saito > Signed-off-by: ASANO Masahiro This version is producing a gcc warning... fs/xfs/xfs_inode.c: In function 'xfs_iunpin': fs/xfs/xfs_inode.c:2765: warning: 'inode' may be used uninitialized in this function Which doesn't look correct due to your need_iput guard, but perhaps we should do this instead... cheers. -- Nathan Fix i_state of the inode is changed after the inode is freed. Signed-off-by: Masayuki Saito Signed-off-by: ASANO Masahiro --- Index: xfs-linux/xfs_inode.c =================================================================== --- xfs-linux.orig/xfs_inode.c 2006-08-24 17:02:36.896740000 +1000 +++ xfs-linux/xfs_inode.c 2006-08-24 17:09:29.430521750 +1000 @@ -2761,19 +2761,29 @@ xfs_iunpin( * call as the inode reclaim may be blocked waiting for * the inode to become unpinned. */ + struct inode *inode = NULL; + + spin_lock(&ip->i_flags_lock); if (!(ip->i_flags & (XFS_IRECLAIM|XFS_IRECLAIMABLE))) { bhv_vnode_t *vp = XFS_ITOV_NULL(ip); /* make sync come back and flush this inode */ if (vp) { - struct inode *inode = vn_to_inode(vp); + inode = vn_to_inode(vp); if (!(inode->i_state & - (I_NEW|I_FREEING|I_CLEAR))) - mark_inode_dirty_sync(inode); + (I_NEW|I_FREEING|I_CLEAR))) { + inode = igrab(inode); + if (inode) + mark_inode_dirty_sync(inode); + } else + inode = NULL; } } + spin_unlock(&ip->i_flags_lock); wake_up(&ip->i_ipin_wait); + if (inode) + iput(inode); } } From owner-xfs@oss.sgi.com Thu Aug 24 03:48:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 03:48:51 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7OAmZDW024664 for ; Thu, 24 Aug 2006 03:48:35 -0700 Received: by wx-out-0506.google.com with SMTP id h29so410004wxd for ; Thu, 24 Aug 2006 03:48:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=Wff8WleJTi00rRxj8R4OgUnuywtV0SUJOrXT2/dMTnWNBHKryGyZcx2XoPQX3saiWm9kwWuFWNbVd5yZpQdhXddDFEZI6eehjSRR1RlX4Op4+ab4sBVWuANmtrJEjiWjOgAijmvFV/cNf4I/LzVHiX9CNonZg8Gpp4/elZAD8LY= Received: by 10.90.25.9 with SMTP id 9mr346663agy; Thu, 24 Aug 2006 02:45:27 -0700 (PDT) Received: by 10.90.115.2 with HTTP; Thu, 24 Aug 2006 02:45:27 -0700 (PDT) Message-ID: <92b7ea0a0608240245v700f19dex6ecb688efcab657b@mail.gmail.com> Date: Thu, 24 Aug 2006 11:45:27 +0200 From: "Stian Jordet" Reply-To: liste@jordet.nu To: xfs@oss.sgi.com Subject: xfs bug in 2.6.17.9? MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8753 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sjordet@gmail.com Precedence: bulk X-list: xfs Content-Length: 3011 Lines: 67 I got this on my server today, while it was not doing anything in particular... Aug 24 09:22:09 buick kernel: xfs_da_do_buf: bno 16777216 Aug 24 09:22:09 buick kernel: dir: inode 14715927 Aug 24 09:22:09 buick kernel: Filesystem "rd/c0d0p1": XFS internal error xfs_da_do_buf(1) at line 2119 of file fs/xfs/xfs_da_btree.c. Caller 0xc029d81c Aug 24 09:22:09 buick kernel: xfs_da_do_buf+0x4ff/0x980 xfs_da_read_buf+0x3c/0x40 Aug 24 09:22:09 buick kernel: xfs_dir2_leafn_lookup_int+0x2e8/0x520 xfs_dir2_leafn_lookup_int+0x2e8/0x520 Aug 24 09:22:09 buick kernel: xfs_dir2_data_log_unused+0x6d/0x90 xfs_da_read_buf+0x3c/0x40 Aug 24 09:22:09 buick kernel: xfs_dir2_node_removename+0x368/0x5b0 xfs_dir2_node_removename+0x368/0x5b0 Aug 24 09:22:09 buick kernel: xfs_dir2_removename+0x129/0x130 xfs_icsb_modify_counters_int+0x73/0x1d0 Aug 24 09:22:09 buick kernel: xfs_trans_ijoin+0x3b/0x90 xfs_remove+0x314/0x510 Aug 24 09:22:09 buick kernel: vfs_permission+0x20/0x30 xfs_vn_unlink+0x3a/0x70 Aug 24 09:22:09 buick kernel: xfs_access+0x4f/0x60 xfs_vn_permission+0x26/0x30 Aug 24 09:22:09 buick kernel: permission+0x73/0x110 may_delete+0x43/0x130 Aug 24 09:22:09 buick kernel: vfs_unlink+0xc1/0x120 do_unlinkat+0xe1/0x170 Aug 24 09:22:09 buick kernel: syscall_call+0x7/0xb Aug 24 09:22:09 buick kernel: Filesystem "rd/c0d0p1": XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c. Caller 0xc02de475 Aug 24 09:22:09 buick kernel: xfs_trans_cancel+0x10b/0x140 xfs_remove+0x385/0x510 Aug 24 09:22:09 buick kernel: xfs_remove+0x385/0x510 vfs_permission+0x20/0x30 Aug 24 09:22:09 buick kernel: xfs_vn_unlink+0x3a/0x70 xfs_access+0x4f/0x60 Aug 24 09:22:09 buick kernel: xfs_vn_permission+0x26/0x30 permission+0x73/0x110 Aug 24 09:22:09 buick kernel: may_delete+0x43/0x130 vfs_unlink+0xc1/0x120 Aug 24 09:22:09 buick kernel: do_unlinkat+0xe1/0x170 syscall_call+0x7/0xb Aug 24 09:22:09 buick kernel: Filesystem "rd/c0d0p1": Corruption of in-memory data detected. Shutting down filesystem: rd/c0d0p1 Aug 24 09:22:09 buick kernel: Please umount the filesystem, and rectify the problem(s) I'll update to latest 2.6.17.11 tonight, but I wonder if this is a known bug? I did upgrade the memory on this server from 2GB to 4GB about a week ago, there is a slight chance there's faulty ram in there, but I don't think that's the problem. And please, if this is the wrong place for problems like this, I'm really sorry. And after I went home in my lunch to restart it, it came up fine, but now it's dead again. Need to investigate more tonight... Any thoughts? Best regards, Stian [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Aug 24 03:39:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 03:39:44 -0700 (PDT) Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7OAdODW023233 for ; Thu, 24 Aug 2006 03:39:24 -0700 Received: from tyo201.gate.nec.co.jp ([10.7.69.201]) by tyo200.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k7OAEE7Z000295 for ; Thu, 24 Aug 2006 19:14:14 +0900 (JST) Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k7OAED2f003152; Thu, 24 Aug 2006 19:14:13 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id k7OAEDO03592; Thu, 24 Aug 2006 19:14:13 +0900 (JST) Received: from anesfw.anes.nec.co.jp (fuji.anes.nec.co.jp [10.2.168.3]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id k7OAE8E00928; Thu, 24 Aug 2006 19:14:08 +0900 (JST) Received: from tnesg9212 (tnesg9212) by anesfw.anes.nec.co.jp (8.13.5/8.13.5) with SMTP id k7OAE7P9012325; Thu, 24 Aug 2006 19:14:07 +0900 To: Nathan Scott Cc: David Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] Fix i_state of inode is changed after the inode is freed [try #2] In-reply-to: <20060824171653.C3003989@wobbly.melbourne.sgi.com> Message-Id: <20060824191341m-saito@mail.aom.tnes.nec.co.jp> References: <20060824171653.C3003989@wobbly.melbourne.sgi.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Masayuki Saito Date: Thu, 24 Aug 2006 19:13:41 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8752 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: m-saito@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 173 Lines: 10 Hi, Nathan >Which doesn't look correct due to your need_iput guard, but perhaps >we should do this instead... I think that your fix is simpler, so I agree it. Masayuki From owner-xfs@oss.sgi.com Thu Aug 24 06:43:31 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 06:43:45 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7ODhTDW005115 for ; Thu, 24 Aug 2006 06:43:31 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 97E5060BEA4F; Thu, 24 Aug 2006 09:42:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 6AE4F160A9259; Thu, 24 Aug 2006 09:42:53 -0400 (EDT) Date: Thu, 24 Aug 2006 09:42:53 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: liste@jordet.nu cc: xfs@oss.sgi.com Subject: Re: xfs bug in 2.6.17.9? In-Reply-To: <92b7ea0a0608240245v700f19dex6ecb688efcab657b@mail.gmail.com> Message-ID: References: <92b7ea0a0608240245v700f19dex6ecb688efcab657b@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8754 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 3476 Lines: 81 Aug 24 09:22:09 buick kernel: xfs_da_do_buf: bno 16777216 That is the bug from 2.6.17 -> 2.6.17.6. It was patched in 2.6.17.7, but I assume(?) if you never fixed your FS to begin with, you will still have the problem. Read the XFS FAQ, and backup your data before you do that :) Justin. On Thu, 24 Aug 2006, Stian Jordet wrote: > I got this on my server today, while it was not doing anything in > particular... > > Aug 24 09:22:09 buick kernel: xfs_da_do_buf: bno 16777216 > Aug 24 09:22:09 buick kernel: dir: inode 14715927 > Aug 24 09:22:09 buick kernel: Filesystem "rd/c0d0p1": XFS internal error > xfs_da_do_buf(1) at line 2119 of file fs/xfs/xfs_da_btree.c. Caller > 0xc029d81c > Aug 24 09:22:09 buick kernel: xfs_da_do_buf+0x4ff/0x980 > xfs_da_read_buf+0x3c/0x40 > Aug 24 09:22:09 buick kernel: > xfs_dir2_leafn_lookup_int+0x2e8/0x520 > xfs_dir2_leafn_lookup_int+0x2e8/0x520 > Aug 24 09:22:09 buick kernel: > xfs_dir2_data_log_unused+0x6d/0x90 xfs_da_read_buf+0x3c/0x40 > Aug 24 09:22:09 buick kernel: > xfs_dir2_node_removename+0x368/0x5b0 > xfs_dir2_node_removename+0x368/0x5b0 > Aug 24 09:22:09 buick kernel: xfs_dir2_removename+0x129/0x130 > xfs_icsb_modify_counters_int+0x73/0x1d0 > Aug 24 09:22:09 buick kernel: xfs_trans_ijoin+0x3b/0x90 > xfs_remove+0x314/0x510 > Aug 24 09:22:09 buick kernel: vfs_permission+0x20/0x30 > xfs_vn_unlink+0x3a/0x70 > Aug 24 09:22:09 buick kernel: xfs_access+0x4f/0x60 > xfs_vn_permission+0x26/0x30 > Aug 24 09:22:09 buick kernel: permission+0x73/0x110 > may_delete+0x43/0x130 > Aug 24 09:22:09 buick kernel: vfs_unlink+0xc1/0x120 > do_unlinkat+0xe1/0x170 > Aug 24 09:22:09 buick kernel: syscall_call+0x7/0xb > Aug 24 09:22:09 buick kernel: Filesystem "rd/c0d0p1": XFS internal error > xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c. Caller 0xc02de475 > Aug 24 09:22:09 buick kernel: xfs_trans_cancel+0x10b/0x140 > xfs_remove+0x385/0x510 > Aug 24 09:22:09 buick kernel: xfs_remove+0x385/0x510 > vfs_permission+0x20/0x30 > Aug 24 09:22:09 buick kernel: xfs_vn_unlink+0x3a/0x70 > xfs_access+0x4f/0x60 > Aug 24 09:22:09 buick kernel: xfs_vn_permission+0x26/0x30 > permission+0x73/0x110 > Aug 24 09:22:09 buick kernel: may_delete+0x43/0x130 > vfs_unlink+0xc1/0x120 > Aug 24 09:22:09 buick kernel: do_unlinkat+0xe1/0x170 > syscall_call+0x7/0xb > Aug 24 09:22:09 buick kernel: Filesystem "rd/c0d0p1": Corruption of > in-memory data detected. Shutting down filesystem: rd/c0d0p1 > Aug 24 09:22:09 buick kernel: Please umount the filesystem, and rectify the > problem(s) > > I'll update to latest 2.6.17.11 tonight, but I wonder if this is a known > bug? I did upgrade the memory on this server from 2GB to 4GB about a week > ago, there is a slight chance there's faulty ram in there, but I don't think > that's the problem. And please, if this is the wrong place for problems like > this, I'm really sorry. > > And after I went home in my lunch to restart it, it came up fine, but now > it's dead again. Need to investigate more tonight... > > Any thoughts? > > Best regards, > Stian > > > [[HTML alternate version deleted]] > > From owner-xfs@oss.sgi.com Thu Aug 24 06:53:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 06:53:37 -0700 (PDT) Received: from mondschein.lichtvoll.de (mondschein.lichtschiff.de [194.150.191.238] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7ODrRDW007238 for ; Thu, 24 Aug 2006 06:53:28 -0700 Received: from localhost (dslb-084-056-097-182.pools.arcor-ip.net [84.56.97.182]) by mondschein.lichtvoll.de (Postfix) with ESMTP id D4083FA8BF; Thu, 24 Aug 2006 14:25:28 +0200 (CEST) From: Martin Steigerwald To: liste@jordet.nu Subject: Re: xfs bug in 2.6.17.9? Date: Thu, 24 Aug 2006 14:29:13 +0200 User-Agent: KMail/1.9.3 References: <92b7ea0a0608240245v700f19dex6ecb688efcab657b@mail.gmail.com> In-Reply-To: <92b7ea0a0608240245v700f19dex6ecb688efcab657b@mail.gmail.com> Cc: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608241429.14277.Martin@lichtvoll.de> X-archive-position: 8755 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 825 Lines: 28 Am Donnerstag 24 August 2006 11:45 schrieb Stian Jordet: > I got this on my server today, while it was not doing anything in > particular... > > Aug 24 09:22:09 buick kernel: xfs_da_do_buf: bno 16777216 Hello Stian, It looks to me that the directory corruption bug in kernel 2.6.17 upto 2.6.17.6 hit you: Did you use a 2.6.17 kernel < 2.6.17.7 before? See http://oss.sgi.com/projects/xfs/faq.html#dir2 http://bugzilla.kernel.org/show_bug.cgi?id=6757 Try xfs_check and if it finds errors xfs_repair. If xfs_repair cannot fix it, you will have to look out a version that contains some fixes related to handling this kind of corruption: http://oss.sgi.com/archives/xfs/2006-07/msg00374.html Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Thu Aug 24 13:12:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 13:12:36 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7OKCSDW003524 for ; Thu, 24 Aug 2006 13:12:28 -0700 Received: from [192.168.11.226] (pool-72-74-202-229.bstnma.east.verizon.net [72.74.202.229]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k7OKBoLH007320 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 24 Aug 2006 16:11:51 -0400 Subject: how to understand allocsp From: Ming Zhang Reply-To: mingz@ele.uri.edu To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Thu, 24 Aug 2006 16:11:50 -0400 Message-Id: <1156450310.2700.85.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8756 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 1494 Lines: 52 Hi All Play with xfs_io and feel confused about this allocsp. Starting with a empty file. xfs_io> bmap /t/x: no extents I assumed this will allocate space from 0 with 1048576 bytes. but seems this is wrong. xfs_io> allocsp 0 1048576 xfs_io> bmap /t/x: no extents Do this from a non-zero start, found file filled with 0. xfs_io> allocsp 1048576 0 xfs_io> bmap /t/x: 0: [0..2047]: 2147745792..2147747839 XFS_IOC_ALLOCSP64 Alter storage space associated with a section of the ordinary file specified. The section ~~~~no idea what this "alter" mean here. is specified by a variable of type xfs_flock64_t, pointed to by the final argument. The data type xfs_flock64_t contains the following members: l_whence is 0, 1, or 2 to indicate that the relative offset l_start will be measured from the start of the file, the current position, or the end of the file, respectively. l_start is the offset from the position specified in l_whence. l_len is the size of the section. An l_len value of zero frees up to the end of the file; in this case, the end of file (i.e., file size) is set to the beginning of the section freed. Any data previously written into this section is no longer accessible. If the section specified is beyond the current end of file, the file is grown and filled with zeroes. The l_len field is currently ignored, and should be set to zero. this "currently ignored" is ONLY when "section is beyond the current end of file" or for any l_start? Thanks! Ming From owner-xfs@oss.sgi.com Thu Aug 24 13:53:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 13:53:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7OKroDW014630 for ; Thu, 24 Aug 2006 13:53:51 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7OKr67s014724; Thu, 24 Aug 2006 16:53:06 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7OKr60Z027374; Thu, 24 Aug 2006 16:53:06 -0400 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k7OKr5OW028323; Thu, 24 Aug 2006 16:53:05 -0400 Message-ID: <44EE11B0.7010208@sandeen.net> Date: Thu, 24 Aug 2006 15:53:04 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (X11/20060808) MIME-Version: 1.0 To: mingz@ele.uri.edu CC: linux-xfs@oss.sgi.com Subject: Re: how to understand allocsp References: <1156450310.2700.85.camel@localhost.localdomain> In-Reply-To: <1156450310.2700.85.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8757 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 820 Lines: 28 Ming Zhang wrote: > Hi All > > Play with xfs_io and feel confused about this allocsp. > > Starting with a empty file. > I honestly never keep this all straight without going back to the code, but I'd start by looking at the comments for, and code in, xfs_change_file_space and xfs_alloc_file_space. /* * XFS_IOC_RESVSP and XFS_IOC_UNRESVSP will reserve or unreserve * file space. * These calls do NOT zero the data space allocated to the file, * nor do they change the file size. * * XFS_IOC_ALLOCSP and XFS_IOC_FREESP will allocate and free file * space. * These calls cause the new file data to be zeroed and the file * size to be changed. */ The semantics of all this could be clearer, IMHO. -Eric From owner-xfs@oss.sgi.com Thu Aug 24 14:02:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 14:02:29 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7OL2MDW016781 for ; Thu, 24 Aug 2006 14:02:22 -0700 Received: from [192.168.11.226] (pool-72-74-202-229.bstnma.east.verizon.net [72.74.202.229]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k7OL1nwV031925 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 24 Aug 2006 17:01:50 -0400 Subject: Re: how to understand allocsp From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <44EE11B0.7010208@sandeen.net> References: <1156450310.2700.85.camel@localhost.localdomain> <44EE11B0.7010208@sandeen.net> Content-Type: text/plain Date: Thu, 24 Aug 2006 17:01:49 -0400 Message-Id: <1156453309.2700.94.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8758 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 1844 Lines: 64 see the code for this XFS_IOC_ALLOCSP if (startoffset > fsize) { error = xfs_alloc_file_space(ip, fsize, startoffset - fsize, 0, attr_flags); if (error) break; } va.va_mask = XFS_AT_SIZE; va.va_size = startoffset; error = xfs_setattr(bdp, &va, attr_flags, credp); if (error) return error; clrprealloc = 1; break; so if offset is larger than current file size, it will allocate the space and fill with zero. this is exactly what i met with "allocsp 1048576 0". i would say this this pretty misleading. since "allocsp 0 1048576" can be easily thought as "allocate 1048576 space start from 0" but now seems only an ATTR is set. Ming On Thu, 2006-08-24 at 15:53 -0500, Eric Sandeen wrote: > Ming Zhang wrote: > > Hi All > > > > Play with xfs_io and feel confused about this allocsp. > > > > Starting with a empty file. > > > > I honestly never keep this all straight without going back to the code, > but I'd start by looking at the comments for, and code in, > xfs_change_file_space and xfs_alloc_file_space. > > /* > * XFS_IOC_RESVSP and XFS_IOC_UNRESVSP will reserve or unreserve > * file space. > * These calls do NOT zero the data space allocated to the file, > * nor do they change the file size. > * > * XFS_IOC_ALLOCSP and XFS_IOC_FREESP will allocate and free file > * space. > * These calls cause the new file data to be zeroed and the file > * size to be changed. > */ > > The semantics of all this could be clearer, IMHO. > > -Eric From owner-xfs@oss.sgi.com Thu Aug 24 18:00:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 18:00:41 -0700 (PDT) Received: from buick.jordet.net (buick.jordet.net [217.8.143.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7P10RDW012338 for ; Thu, 24 Aug 2006 18:00:27 -0700 Received: from chevrolet.jordet ([192.168.1.2]:47253) by buick.jordet.net with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.63) (envelope-from ) id 1GGOtE-0002GI-H7; Fri, 25 Aug 2006 01:45:36 +0200 Subject: Re: xfs bug in 2.6.17.9? From: Stian Jordet To: Martin Steigerwald Cc: xfs@oss.sgi.com In-Reply-To: <200608241429.14277.Martin@lichtvoll.de> References: <92b7ea0a0608240245v700f19dex6ecb688efcab657b@mail.gmail.com> <200608241429.14277.Martin@lichtvoll.de> Content-Type: text/plain Date: Fri, 25 Aug 2006 01:45:33 +0200 Message-Id: <1156463133.19666.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-archive-position: 8759 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: liste@jordet.net Precedence: bulk X-list: xfs Content-Length: 1355 Lines: 36 tor, 24,.08.2006 kl. 14.29 +0200, skrev Martin Steigerwald: > It looks to me that the directory corruption bug in kernel 2.6.17 upto > 2.6.17.6 hit you: Did you use a 2.6.17 kernel < 2.6.17.7 before? > > See > > http://oss.sgi.com/projects/xfs/faq.html#dir2 > http://bugzilla.kernel.org/show_bug.cgi?id=6757 > > Try xfs_check and if it finds errors xfs_repair. > > If xfs_repair cannot fix it, you will have to look out a version that > contains some fixes related to handling this kind of corruption: > > http://oss.sgi.com/archives/xfs/2006-07/msg00374.html Martin, thanks for your help. I did use both 2.6.17.1 and 2.6.17.3 before 2.6.17.9... So I guess (hope) that's the problem, and not my memory... I have run xfs_repair 2.8.11 on two filesystems with errors (luckily, neither my /home nor my backup partition seems to be hit), and it find some errors, but if I run it again, I finds the same errors over and over again... I seem to have it up and running again now, but I really don't like that xfs_repair shows a lot of errors on each run. Don't like that at all... It says it has fixed the errors, but I just never get rid of them. Is that normal? Guess not. And is it something that can happen with the directory corruption bug? I read that I needed to have xfsprogs >2.8.10, but that didn't help neither... Best regards, Stian From owner-xfs@oss.sgi.com Thu Aug 24 18:00:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 18:00:42 -0700 (PDT) Received: from buick.jordet.net (buick.jordet.net [217.8.143.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7P10PDW012332 for ; Thu, 24 Aug 2006 18:00:26 -0700 Received: from chevrolet.jordet ([192.168.1.2]:47254) by buick.jordet.net with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.63) (envelope-from ) id 1GGOvH-0002GT-GG; Fri, 25 Aug 2006 01:47:43 +0200 Subject: Re: xfs bug in 2.6.17.9? From: Stian Jordet To: Justin Piszcz Cc: xfs@oss.sgi.com In-Reply-To: References: <92b7ea0a0608240245v700f19dex6ecb688efcab657b@mail.gmail.com> Content-Type: text/plain Date: Fri, 25 Aug 2006 01:47:43 +0200 Message-Id: <1156463263.19666.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-archive-position: 8760 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: liste@jordet.net Precedence: bulk X-list: xfs Content-Length: 540 Lines: 16 tor, 24,.08.2006 kl. 09.42 -0400, skrev Justin Piszcz: > Aug 24 09:22:09 buick kernel: xfs_da_do_buf: bno 16777216 > > That is the bug from 2.6.17 -> 2.6.17.6. > > It was patched in 2.6.17.7, but I assume(?) if you never fixed your FS to > begin with, you will still have the problem. Read the XFS FAQ, and backup > your data before you do that :) As I just wrote to Martin, I did run a couple of those kernels. But even with updated xfsprogs I can't fix the errors... Is that "normal", or am I in deep trouble? Best regards, Stian From owner-xfs@oss.sgi.com Thu Aug 24 19:00:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 19:00:36 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7P200DW001342 for ; Thu, 24 Aug 2006 19:00:16 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11721; Fri, 25 Aug 2006 11:59:08 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7P1x4gw3031591; Fri, 25 Aug 2006 11:59:04 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7P1wwGK3031357; Fri, 25 Aug 2006 11:58:58 +1000 (EST) Date: Fri, 25 Aug 2006 11:58:58 +1000 From: Nathan Scott To: Stian Jordet Cc: Justin Piszcz , xfs@oss.sgi.com Subject: Re: xfs bug in 2.6.17.9? Message-ID: <20060825115858.A3029472@wobbly.melbourne.sgi.com> References: <92b7ea0a0608240245v700f19dex6ecb688efcab657b@mail.gmail.com> <1156463263.19666.7.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1156463263.19666.7.camel@localhost.localdomain>; from liste@jordet.net on Fri, Aug 25, 2006 at 01:47:43AM +0200 X-archive-position: 8761 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 807 Lines: 23 On Fri, Aug 25, 2006 at 01:47:43AM +0200, Stian Jordet wrote: > tor, 24,.08.2006 kl. 09.42 -0400, skrev Justin Piszcz: > > Aug 24 09:22:09 buick kernel: xfs_da_do_buf: bno 16777216 > > > > That is the bug from 2.6.17 -> 2.6.17.6. > > > > It was patched in 2.6.17.7, but I assume(?) if you never fixed your FS to > > begin with, you will still have the problem. Read the XFS FAQ, and backup > > your data before you do that :) > > As I just wrote to Martin, I did run a couple of those kernels. But even > with updated xfsprogs I can't fix the errors... Is that "normal", or am > I in deep trouble? This is likely to be lost+found being recreated each time, its normal if you don't do something about the lost+found files - once those are renamed/removed, it should run cleanly. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Aug 24 19:24:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 19:24:34 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7P2OPDW010653 for ; Thu, 24 Aug 2006 19:24:26 -0700 Received: by sandeen.net (Postfix, from userid 500) id 7E22C18DAFEC7; Thu, 24 Aug 2006 21:23:52 -0500 (CDT) To: xfs@oss.sgi.com Subject: [PATCH] collapse sv_init, init_sv on linux Message-Id: <20060825022352.7E22C18DAFEC7@sandeen.net> Date: Thu, 24 Aug 2006 21:23:52 -0500 (CDT) From: sandeen@sandeen.net X-archive-position: 8762 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1639 Lines: 52 Change the one caller of init_sv on linux2.4 to sv_init, since there is no difference between sv_init & init_sv on linux anyway. Then get rid of now unused init_sv. Signed-off-by: Eric Sandeen linux-2.4/sv.h | 2 -- linux-2.4/xfs_vnode.c | 2 +- linux-2.6/sv.h | 2 -- 3 files changed, 1 insertion(+), 5 deletions(-) Index: xfs-linux/linux-2.4/sv.h =================================================================== --- xfs-linux.orig/linux-2.4/sv.h +++ xfs-linux/linux-2.4/sv.h @@ -53,8 +53,6 @@ static inline void _sv_wait(sv_t *sv, sp remove_wait_queue(&sv->waiters, &wait); } -#define init_sv(sv,type,name,flag) \ - init_waitqueue_head(&(sv)->waiters) #define sv_init(sv,flag,name) \ init_waitqueue_head(&(sv)->waiters) #define sv_destroy(sv) \ Index: xfs-linux/linux-2.4/xfs_vnode.c =================================================================== --- xfs-linux.orig/linux-2.4/xfs_vnode.c +++ xfs-linux/linux-2.4/xfs_vnode.c @@ -35,7 +35,7 @@ vn_init(void) register int i; for (svp = vsync, i = 0; i < NVSYNC; i++, svp++) - init_sv(svp, SV_DEFAULT, "vsy", i); + sv_init(svp, SV_DEFAULT, "vsy"); } struct bhv_vnode * Index: xfs-linux/linux-2.6/sv.h =================================================================== --- xfs-linux.orig/linux-2.6/sv.h +++ xfs-linux/linux-2.6/sv.h @@ -53,8 +53,6 @@ static inline void _sv_wait(sv_t *sv, sp remove_wait_queue(&sv->waiters, &wait); } -#define init_sv(sv,type,name,flag) \ - init_waitqueue_head(&(sv)->waiters) #define sv_init(sv,flag,name) \ init_waitqueue_head(&(sv)->waiters) #define sv_destroy(sv) \ From owner-xfs@oss.sgi.com Thu Aug 24 19:35:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 19:35:24 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7P2YuDW013990 for ; Thu, 24 Aug 2006 19:35:08 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12456; Fri, 25 Aug 2006 12:34:08 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7P2Y6gw3029765; Fri, 25 Aug 2006 12:34:06 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7P2Y3eq3032257; Fri, 25 Aug 2006 12:34:03 +1000 (EST) Date: Fri, 25 Aug 2006 12:34:03 +1000 From: Nathan Scott To: sandeen@sandeen.net Cc: xfs@oss.sgi.com Subject: Re: [PATCH] collapse sv_init, init_sv on linux Message-ID: <20060825123403.A3026918@wobbly.melbourne.sgi.com> References: <20060825022352.7E22C18DAFEC7@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060825022352.7E22C18DAFEC7@sandeen.net>; from sandeen@sandeen.net on Thu, Aug 24, 2006 at 09:23:52PM -0500 X-archive-position: 8763 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 341 Lines: 14 On Thu, Aug 24, 2006 at 09:23:52PM -0500, sandeen@sandeen.net wrote: > Change the one caller of init_sv on linux2.4 to sv_init, since there > is no difference between sv_init & init_sv on linux anyway. > > Then get rid of now unused init_sv. Taa, queued up (along with one or two earlier ones I didn't reply to yet). thanks. -- Nathan From owner-xfs@oss.sgi.com Thu Aug 24 22:36:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 22:36:11 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7P5ZxDW011187 for ; Thu, 24 Aug 2006 22:35:59 -0700 Received: (qmail 28717 invoked from network); 25 Aug 2006 05:35:26 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 25 Aug 2006 05:35:26 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id F1AAE1813717; Thu, 24 Aug 2006 22:08:38 -0700 (PDT) Date: Thu, 24 Aug 2006 22:08:38 -0700 From: Chris Wedgwood To: Stian Jordet Cc: Justin Piszcz , xfs@oss.sgi.com Subject: Re: xfs bug in 2.6.17.9? Message-ID: <20060825050838.GA1322@tuatara.stupidest.org> References: <92b7ea0a0608240245v700f19dex6ecb688efcab657b@mail.gmail.com> <1156463263.19666.7.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1156463263.19666.7.camel@localhost.localdomain> X-archive-position: 8764 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 467 Lines: 11 On Fri, Aug 25, 2006 at 01:47:43AM +0200, Stian Jordet wrote: > As I just wrote to Martin, I did run a couple of those kernels. But > even with updated xfsprogs I can't fix the errors... Is that > "normal", or am I in deep trouble? More recent xfs_repair will deal better with it, I think it's in CVS now, I'm not entirely sure though. Search for the XFS faq, at the end there is a section on directory corruption and details on how to fix it by hand if need be. From owner-xfs@oss.sgi.com Thu Aug 24 23:16:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 23:16:31 -0700 (PDT) Received: from buick.jordet.net (buick.jordet.net [217.8.143.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7P6GEDW024637 for ; Thu, 24 Aug 2006 23:16:15 -0700 Received: from chevrolet.jordet ([192.168.1.2]:38783) by buick.jordet.net with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.63) (envelope-from ) id 1GGUyg-0001XM-KH; Fri, 25 Aug 2006 08:15:38 +0200 Subject: Re: xfs bug in 2.6.17.9? From: Stian Jordet To: Nathan Scott Cc: Justin Piszcz , xfs@oss.sgi.com In-Reply-To: <20060825115858.A3029472@wobbly.melbourne.sgi.com> References: <92b7ea0a0608240245v700f19dex6ecb688efcab657b@mail.gmail.com> <1156463263.19666.7.camel@localhost.localdomain> <20060825115858.A3029472@wobbly.melbourne.sgi.com> Content-Type: text/plain Date: Fri, 25 Aug 2006 08:15:38 +0200 Message-Id: <1156486538.6854.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-archive-position: 8765 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: liste@jordet.net Precedence: bulk X-list: xfs Content-Length: 2071 Lines: 53 fre, 25,.08.2006 kl. 11.58 +1000, skrev Nathan Scott: > On Fri, Aug 25, 2006 at 01:47:43AM +0200, Stian Jordet wrote: > > tor, 24,.08.2006 kl. 09.42 -0400, skrev Justin Piszcz: > > > Aug 24 09:22:09 buick kernel: xfs_da_do_buf: bno 16777216 > > > > > > That is the bug from 2.6.17 -> 2.6.17.6. > > > > > > It was patched in 2.6.17.7, but I assume(?) if you never fixed your FS to > > > begin with, you will still have the problem. Read the XFS FAQ, and backup > > > your data before you do that :) > > > > As I just wrote to Martin, I did run a couple of those kernels. But even > > with updated xfsprogs I can't fix the errors... Is that "normal", or am > > I in deep trouble? > > This is likely to be lost+found being recreated each time, its > normal if you don't do something about the lost+found files - > once those are renamed/removed, it should run cleanly. You seem to be right about that :) But when I wake up this morning, I had my logs full of this: 0x0: 24 73 74 61 74 73 20 3d 20 7b 0a 20 20 27 73 68 Filesystem "rd/c0d1p1": XFS internal error xfs_da_do_buf(2) at line 2212 of file fs/xfs/xfs_da_btree.c. Caller 0xc029d81c xfs_corruption_error+0x10b/0x140 xfs_da_read_buf +0x3c/0x40 kmem_zone_alloc+0x61/0xe0 xfs_da_buf_make +0xfa/0x150 xfs_da_do_buf+0x929/0x980 xfs_da_read_buf +0x3c/0x40 xfs_da_read_buf+0x3c/0x40 xfs_da_node_lookup_int +0xcd/0x3b0 xfs_da_node_lookup_int+0xcd/0x3b0 xfs_dir2_node_lookup+0x3f/0xc0 xfs_dir2_lookup+0x12a/0x130 xfs_vn_permission +0x26/0x30 vfs_permission+0x20/0x30 __link_path_walk +0x8a/0xfa0 xfs_dir_lookup_int+0x4c/0x130 xfs_lookup +0x7e/0xa0 xfs_vn_lookup+0x4e/0x90 __lookup_hash+0xe9/0x120 do_unlinkat+0xa8/0x170 sys_stat64+0x27/0x30 syscall_call+0x7/0xb Don't know how many times, but many! Is that related to anything...? Thanks! Best regards, Stian From owner-xfs@oss.sgi.com Thu Aug 24 23:44:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 24 Aug 2006 23:44:59 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7P6iSDW004201 for ; Thu, 24 Aug 2006 23:44:40 -0700 Received: from soarer.melbourne.sgi.com (soarer.melbourne.sgi.com [134.14.55.89]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k7P6hknx021419 for ; Fri, 25 Aug 2006 01:43:47 -0500 Received: by soarer.melbourne.sgi.com (Postfix, from userid 16344) id 5DA52627C5; Fri, 25 Aug 2006 16:44:05 +1000 (EST) To: sgi.bugs.xfs@engr.melbourne.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 955006 - Message-Id: <20060825064405.5DA52627C5@soarer.melbourne.sgi.com> Date: Fri, 25 Aug 2006 16:44:05 +1000 (EST) From: vapo@soarer.melbourne.sgi.com (Vlad Apostolov) X-archive-position: 8766 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@soarer.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 580 Lines: 17 955006: DMAPI set/get/remove attribute returns EINVAL instead of EFAULT:bad &dm_attrname Date: Fri Aug 25 16:41:56 AEST 2006 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs-dmapi Inspected by: bnaujok The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:26864a fs/xfs/dmapi/xfs_dm.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h - pv 955006, rv bnaujok - check access_ok() for user dm_attrname_t buffer From owner-xfs@oss.sgi.com Fri Aug 25 00:53:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 25 Aug 2006 00:53:24 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7P7qjDa002499 for ; Fri, 25 Aug 2006 00:53:03 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA17186; Fri, 25 Aug 2006 16:50:50 +1000 Message-ID: <44EE9DF7.1080904@sgi.com> Date: Fri, 25 Aug 2006 16:51:35 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 955006: DMAPI set/get/remove attribute returns EINVAL instead of EFAULT:bad &dm_attrname References: <44CE9F23.7000605@sgi.com> In-Reply-To: <44CE9F23.7000605@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8769 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 511 Lines: 16 Date: Fri Aug 25 16:41:56 AEST 2006 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs-dmapi Inspected by: bnaujok Author: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:26864a fs/xfs/dmapi/xfs_dm.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h - pv 955006, rv bnaujok - check access_ok() for user dm_attrname_t buffer From owner-xfs@oss.sgi.com Fri Aug 25 00:52:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 25 Aug 2006 00:53:18 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7P7qjDW002499 for ; Fri, 25 Aug 2006 00:52:56 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA17553; Fri, 25 Aug 2006 17:12:39 +1000 Message-ID: <44EEA313.80101@sgi.com> Date: Fri, 25 Aug 2006 17:13:23 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 955157: Deadlock in xfs_bulkstat() when an invalid user buffer pointer is passed References: <44CE9F23.7000605@sgi.com> <44EE9DF7.1080904@sgi.com> <44EEA07E.9070207@sgi.com> In-Reply-To: <44EEA07E.9070207@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8767 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 496 Lines: 14 Date: Fri Aug 25 17:11:04 AEST 2006 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs-dmapi Inspected by: bnaujok Author: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:26866a fs/xfs/xfs_itable.c - 1.146 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.146&r2=text&tr2=1.145&f=h - pv 955157, rv bnaujok - break the loop on formatter() error From owner-xfs@oss.sgi.com Fri Aug 25 00:53:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 25 Aug 2006 00:53:21 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7P7qjDY002499 for ; Fri, 25 Aug 2006 00:53:00 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA17434; Fri, 25 Aug 2006 17:01:37 +1000 Message-ID: <44EEA07E.9070207@sgi.com> Date: Fri, 25 Aug 2006 17:02:22 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 CC: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 955271: [SUSE#197643] dm_set_fileattr does not update atime References: <44CE9F23.7000605@sgi.com> <44EE9DF7.1080904@sgi.com> In-Reply-To: <44EE9DF7.1080904@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8768 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 490 Lines: 14 Date: Fri Aug 25 16:59:14 AEST 2006 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs-dmapi Inspected by: bnaujok Author: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:26865a fs/xfs/dmapi/xfs_dm.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h - pv 955271, rv bnaujok - update inode->i_atime.tv_sec From owner-xfs@oss.sgi.com Fri Aug 25 01:39:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 25 Aug 2006 01:39:55 -0700 (PDT) Received: from buick.jordet.net (buick.jordet.net [217.8.143.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7P8dODW017739 for ; Fri, 25 Aug 2006 01:39:34 -0700 Received: from ti112210a080-11545.bb.online.no ([80.212.157.27]:1078 helo=[127.0.0.1]) by buick.jordet.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1GGXDD-0003ft-PI; Fri, 25 Aug 2006 10:38:48 +0200 Message-ID: <44EEB718.4060805@jordet.net> Date: Fri, 25 Aug 2006 10:38:48 +0200 From: Stian Jordet User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Nathan Scott CC: Justin Piszcz , xfs@oss.sgi.com Subject: Re: xfs bug in 2.6.17.9? References: <92b7ea0a0608240245v700f19dex6ecb688efcab657b@mail.gmail.com> <1156463263.19666.7.camel@localhost.localdomain> <20060825115858.A3029472@wobbly.melbourne.sgi.com> <1156486538.6854.1.camel@localhost.localdomain> In-Reply-To: <1156486538.6854.1.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8770 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: liste@jordet.net Precedence: bulk X-list: xfs Content-Length: 1992 Lines: 51 Stian Jordet wrote: > fre, 25,.08.2006 kl. 11.58 +1000, skrev Nathan Scott: > >> This is likely to be lost+found being recreated each time, its >> normal if you don't do something about the lost+found files - >> once those are renamed/removed, it should run cleanly. >> > > You seem to be right about that :) > > But when I wake up this morning, I had my logs full of this: > > 0x0: 24 73 74 61 74 73 20 3d 20 7b 0a 20 20 27 73 68 > Filesystem "rd/c0d1p1": XFS internal error xfs_da_do_buf(2) at line 2212 > of file fs/xfs/xfs_da_btree.c. Caller 0xc029d81c > xfs_corruption_error+0x10b/0x140 xfs_da_read_buf > +0x3c/0x40 > kmem_zone_alloc+0x61/0xe0 xfs_da_buf_make > +0xfa/0x150 > xfs_da_do_buf+0x929/0x980 xfs_da_read_buf > +0x3c/0x40 > xfs_da_read_buf+0x3c/0x40 xfs_da_node_lookup_int > +0xcd/0x3b0 > xfs_da_node_lookup_int+0xcd/0x3b0 > xfs_dir2_node_lookup+0x3f/0xc0 > xfs_dir2_lookup+0x12a/0x130 xfs_vn_permission > +0x26/0x30 > vfs_permission+0x20/0x30 __link_path_walk > +0x8a/0xfa0 > xfs_dir_lookup_int+0x4c/0x130 xfs_lookup > +0x7e/0xa0 > xfs_vn_lookup+0x4e/0x90 __lookup_hash+0xe9/0x120 > do_unlinkat+0xa8/0x170 sys_stat64+0x27/0x30 > syscall_call+0x7/0xb > > Don't know how many times, but many! Is that related to anything...? > It seems I just hadn't used a recent enough xfs_repair with that filesystem. Seems good now. Just one last question, are you 99,5% sure that this is the symptoms of that corruption bug in 2.6.17? So I can assume that my memory wasn't the problem? I'm now running with only 512MB (which I'm sure is good), and I don't want to use the new memory if I get this problem again (even though I have good backups, it's a hell of a job fixing it again...) Thank you. Best regards, Stian From owner-xfs@oss.sgi.com Fri Aug 25 11:42:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 25 Aug 2006 11:43:06 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.207]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7PIgvDW006673 for ; Fri, 25 Aug 2006 11:42:58 -0700 Received: by nz-out-0102.google.com with SMTP id 40so697608nzk for ; Fri, 25 Aug 2006 11:42:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SbFspJFr3zC2EnKZfPdfTDBpxZPnd5qO8lRe9Vzme5tTvIgnzXIaObVWM3y+mP9ouzV1FzqGp5iJPCGB/MD/TMCyJD6jR1KVLQTVjckXhm3aC9OBIJW59U+mC3byMxnQdMlemE8vP35TPHohS96NUbmbR1lAeV1VBwovL1qHmQk= Received: by 10.64.7.20 with SMTP id 20mr4078376qbg; Fri, 25 Aug 2006 10:24:50 -0700 (PDT) Received: by 10.65.122.18 with HTTP; Fri, 25 Aug 2006 10:24:50 -0700 (PDT) Message-ID: <3022c03a0608251024l5766b9cwa8884fdba881883e@mail.gmail.com> Date: Fri, 25 Aug 2006 17:24:50 +0000 From: Luzbel To: xfs@oss.sgi.com Subject: Aborting XFS copy - reason: Cannot allocate memory MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 8773 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: putabetis@gmail.com Precedence: bulk X-list: xfs Content-Length: 771 Lines: 20 I made a copy of my / partition with xfs_copy -d to a file on a XFS filesystem. It worked without complains. Now, when I try to copy back the data from the file to the partition I get: root@slax:/mnt/hda3/luzbel/backup# xfs_copy -d archlinux.partition /dev/hda2 Error initializing wbuf 0 Aborting XFS copy - reason: Cannot allocate memory Check logfile "/var/tmp/xfs_copy.log.pn0zp0" for more details root@slax:/mnt/hda3/luzbel/backup# cat /var/tmp/xfs_copy.log.pn0zp0 Error initializing wbuf 0 Aborting XFS copy - reason: Cannot allocate memory root@slax:/mnt/hda3/luzbel/backup# Partition /dev/hda2 is unmount and /dev/hda3 is mounted, of course. You got any idea on why this is happening? If you need me to provide extra info, instruct me. Thank you very much. From owner-xfs@oss.sgi.com Fri Aug 25 12:41:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 25 Aug 2006 12:41:18 -0700 (PDT) Received: from uwast.astro.wisc.edu (uwast.astro.wisc.edu [144.92.110.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7PJf7DW025851 for ; Fri, 25 Aug 2006 12:41:08 -0700 Received: from [192.168.1.101] (ppp-70-226-167-16.dsl.mdsnwi.ameritech.net [70.226.167.16]) (authenticated bits=0) by uwast.astro.wisc.edu (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id k7PIfgls007290 for ; Fri, 25 Aug 2006 13:41:45 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: linux-xfs@oss.sgi.com Message-Id: <9754D30D-C670-4D71-AB60-BD6152120B63@astro.wisc.edu> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10--17039959; protocol="application/pkcs7-signature" References: <9E7A5312-6215-4BF8-9FBC-1F688AC366BB@astro.wisc.edu> From: Stephan Jansen Subject: Files greater than 2TB on 32 bit SLES9 SP3? Date: Fri, 25 Aug 2006 13:41:42 -0500 X-Mailer: Apple Mail (2.752.2) X-UW-Astronomy-MailScanner-Information: Please contact the ISP for more information X-UW-Astronomy-MailScanner: Found to be clean X-UW-Astronomy-MailScanner-From: jansen@astro.wisc.edu X-archive-position: 8774 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jansen@astro.wisc.edu Precedence: bulk X-list: xfs Content-Length: 3819 Lines: 83 --Apple-Mail-10--17039959 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, Can we create file systems of 3TB and individual files larger than 2TB on a 32 bit version of SLES9 SP3 using XFS? If I read the XFS project page correctly then this should work but I thought I'd ask the list before I try it. Thanks. -- ----- Stephan --Apple-Mail-10--17039959 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIGLzCCAvQwggJdoAMCAQICAkRNMA0GCSqGSIb3DQEBBQUAMFMxCzAJ BgNVBAYTAlVTMRwwGgYDVQQKExNFcXVpZmF4IFNlY3VyZSBJbmMuMSYwJAYD VQQDEx1FcXVpZmF4IFNlY3VyZSBlQnVzaW5lc3MgQ0EtMTAeFw0wNTA4Mjkx NjA3MjBaFw0xNTA4MjkxNjA3MjBaMIGJMQswCQYDVQQGEwJVUzErMCkGA1UE ChMiRGl2aXNpb24gb2YgSW5mb3JtYXRpb24gVGVjaG5vbG9neTEjMCEGA1UE CxMaRmFjdWx0eSAtIFN0YWZmIC0gU3R1ZGVudHMxKDAmBgNVBAMTH1VuaXZl cnNpdHkgb2YgV2lzY29uc2luLU1hZGlzb24wgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAOhIUdwld8sfAAlrdOv5Tt8PTX1Wku/ItsIjHrkus1MbKoul SXxSsSUPAPYzgT8HfhuRY+tHHzohFSu3xJWgx0wk8q2pqwo4KZ2evy7GMDFx THyXSYa/1m0Wsg5c11u8J6/tR8yqu7RWIJPr+edlPjx8r/cYP7AK5nA7msMF FZqDAgMBAAGjgZ8wgZwwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBQcnlJS GwRiRyxrLAG4afGpNywjJDAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EUNkBq R3xMoTAPBgNVHRMBAf8EBTADAQH/MDkGA1UdHwQyMDAwLqAsoCqGKGh0dHA6 Ly9jcmwuZ2VvdHJ1c3QuY29tL2NybHMvZWJpemNhMS5jcmwwDQYJKoZIhvcN AQEFBQADgYEAJfFEWDN3f+cS1o3XqrcgmDdr5h3e37WxerB/YxVfHpsr5UzT GVBwR09zyRA+AtmBrNBE07HcLSsri/x9o1qJPwtko8GB+ScW9lTvoSoWKf93 fkeymKj4T7X2rFV+umJTSmgs850RTh+oRx0eVGHfc1zHRNjpUiPqZRoaYqjF Z5AwggMzMIICnKADAgECAgIAqzANBgkqhkiG9w0BAQUFADCBiTELMAkGA1UE BhMCVVMxKzApBgNVBAoTIkRpdmlzaW9uIG9mIEluZm9ybWF0aW9uIFRlY2hu b2xvZ3kxIzAhBgNVBAsTGkZhY3VsdHkgLSBTdGFmZiAtIFN0dWRlbnRzMSgw JgYDVQQDEx9Vbml2ZXJzaXR5IG9mIFdpc2NvbnNpbi1NYWRpc29uMB4XDTA1 MTEwODE5NDg0NloXDTA2MTEwODE5NDg0NlowgcExCzAJBgNVBAYTAlVTMRIw EAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xKDAmBgNVBAoT H1VuaXZlcnNpdHkgb2YgV2lzY29uc2luLU1hZGlzb24xIzAhBgNVBAsTGkZh Y3VsdHkgLSBTdGFmZiAtIFN0dWRlbnRzMRcwFQYDVQQDEw5TdGVwaGVuIEph bnNlbjEkMCIGCSqGSIb3DQEJARYVamFuc2VuQGFzdHJvLndpc2MuZWR1MIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDYmSqLM5WAgcBhd+EtQ3lxnq2H u6TA+EN1lzR/ZKyEjg/cFhajrs+Py5qrADFp62Chsq1BcqI8l3j3oQMiQgni AGxVrBkg/Al5nlUuzm3G/zpgoxbOXdBPv1xv7b52ylcKkaW4byOswQdZqSLt H7aNPHdyDLFKEG9nw4TuGPm9sQIDAQABo3AwbjAOBgNVHQ8BAf8EBAMCBeAw OwYDVR0fBDQwMjAwoC6gLIYqaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Js cy93aXNjb25zaW4uY3JsMB8GA1UdIwQYMBaAFByeUlIbBGJHLGssAbhp8ak3 LCMkMA0GCSqGSIb3DQEBBQUAA4GBAHslg5nIvKIHNbz6jAwLHx4JK++gdHUA GJxm8NCog0S58/nJXNJZpiCV3YY1feC3s+8eM0LusZXJJ5O8SgRBLmBP1TMp pIbX0WSZz40xn+IqBbSDboK2s6694y0aS8f1O/1I0+r6AEXhnBtPxK8U9UYN quW4bAAme3t0sHAoaFANMYIC4jCCAt4CAQEwgZAwgYkxCzAJBgNVBAYTAlVT MSswKQYDVQQKEyJEaXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5 MSMwIQYDVQQLExpGYWN1bHR5IC0gU3RhZmYgLSBTdHVkZW50czEoMCYGA1UE AxMfVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4tTWFkaXNvbgICAKswCQYFKw4D AhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDYwODI1MTg0MTQzWjAjBgkqhkiG9w0BCQQxFgQUKcxY7bHMQtlN 7hRVRQbr1b+d0wkwgaEGCSsGAQQBgjcQBDGBkzCBkDCBiTELMAkGA1UEBhMC VVMxKzApBgNVBAoTIkRpdmlzaW9uIG9mIEluZm9ybWF0aW9uIFRlY2hub2xv Z3kxIzAhBgNVBAsTGkZhY3VsdHkgLSBTdGFmZiAtIFN0dWRlbnRzMSgwJgYD VQQDEx9Vbml2ZXJzaXR5IG9mIFdpc2NvbnNpbi1NYWRpc29uAgIAqzCBowYL KoZIhvcNAQkQAgsxgZOggZAwgYkxCzAJBgNVBAYTAlVTMSswKQYDVQQKEyJE aXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MSMwIQYDVQQLExpG YWN1bHR5IC0gU3RhZmYgLSBTdHVkZW50czEoMCYGA1UEAxMfVW5pdmVyc2l0 eSBvZiBXaXNjb25zaW4tTWFkaXNvbgICAKswDQYJKoZIhvcNAQEBBQAEgYA9 vJJwS+52j5Bj34eRHyLGhHlhCHrKyd9yZ/nH1tbWCXOZ0/itGSOUQqZIvdyq 4mN2EKx2K13iU9Vy6VaBdtUyfCPoGkKwHL8xc7gA8dz+eVr+G5/8jkHt4+OC f8hu9MLJymWZ7WvJimEs95LB0daNM+OPsyNklJYpo8YumwVIYAAAAAAAAA== --Apple-Mail-10--17039959-- From owner-xfs@oss.sgi.com Fri Aug 25 12:46:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 25 Aug 2006 12:46:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7PJkRDW027504 for ; Fri, 25 Aug 2006 12:46:30 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7PJjjoK028656; Fri, 25 Aug 2006 15:45:45 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7PJjjCq025463; Fri, 25 Aug 2006 15:45:45 -0400 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k7PJji2T028970; Fri, 25 Aug 2006 15:45:45 -0400 Message-ID: <44EF5368.8000007@sandeen.net> Date: Fri, 25 Aug 2006 14:45:44 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (X11/20060808) MIME-Version: 1.0 To: Stephan Jansen CC: linux-xfs@oss.sgi.com Subject: Re: Files greater than 2TB on 32 bit SLES9 SP3? References: <9E7A5312-6215-4BF8-9FBC-1F688AC366BB@astro.wisc.edu> <9754D30D-C670-4D71-AB60-BD6152120B63@astro.wisc.edu> In-Reply-To: <9754D30D-C670-4D71-AB60-BD6152120B63@astro.wisc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8775 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 516 Lines: 22 Stephan Jansen wrote: > > Hi, > > Can we create file systems of 3TB and individual files larger than > 2TB on a 32 bit version of SLES9 SP3 using XFS? If I read the XFS > project page correctly then this should work but I thought I'd ask > the list before I try it. Thanks. > Yes, this should work. Block device sizes that large will also require that your IO stack is clean with CONFIG_LBD, but I'd expect that it is. XFS itself should not have any problems with this. -Eric > -- > > ----- Stephan > From owner-xfs@oss.sgi.com Fri Aug 25 14:22:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 25 Aug 2006 14:22:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7PLMlDW018574 for ; Fri, 25 Aug 2006 14:22:48 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7PLM9d3027098; Fri, 25 Aug 2006 17:22:09 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7PLM8AO018687; Fri, 25 Aug 2006 17:22:08 -0400 Received: from [10.15.80.54] (xenon.msp.redhat.com [10.15.80.54]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k7PLM77O002235; Fri, 25 Aug 2006 17:22:08 -0400 Message-ID: <44EF6A08.8000200@thebarn.com> Date: Fri, 25 Aug 2006 16:22:16 -0500 From: Russell Cattelan User-Agent: Thunderbird 1.5.0.5 (X11/20060808) MIME-Version: 1.0 To: Luzbel , xfs@oss.sgi.com Subject: Re: Aborting XFS copy - reason: Cannot allocate memory References: <3022c03a0608251024l5766b9cwa8884fdba881883e@mail.gmail.com> In-Reply-To: <3022c03a0608251024l5766b9cwa8884fdba881883e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8778 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 1011 Lines: 28 Luzbel wrote: > I made a copy of my / partition with xfs_copy -d to a file on a XFS > filesystem. It worked without complains. Now, when I try to copy back > the data from the file to the partition I get: > > root@slax:/mnt/hda3/luzbel/backup# xfs_copy -d archlinux.partition > /dev/hda2 > Error initializing wbuf 0 > Aborting XFS copy - reason: Cannot allocate memory > Check logfile "/var/tmp/xfs_copy.log.pn0zp0" for more details > root@slax:/mnt/hda3/luzbel/backup# cat /var/tmp/xfs_copy.log.pn0zp0 > Error initializing wbuf 0 > Aborting XFS copy - reason: Cannot allocate memory > root@slax:/mnt/hda3/luzbel/backup# > > Partition /dev/hda2 is unmount and /dev/hda3 is mounted, of course. > > You got any idea on why this is happening? If you need me to provide > extra info, instruct me. > > Thank you very much. > run xfs_check or xfs_repair -n on your copy just to make sure the file is good. maybe run strace or gdb on xfs_copy and figure out exactly how much space xfs_copy is trying to allocate. From owner-xfs@oss.sgi.com Sat Aug 26 10:07:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 26 Aug 2006 10:07:45 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7QH7RDW005103 for ; Sat, 26 Aug 2006 10:07:27 -0700 Received: (qmail 23166 invoked from network); 26 Aug 2006 15:06:54 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 26 Aug 2006 15:06:54 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 092F3114330; Sat, 26 Aug 2006 17:06:55 +0200 (CEST) Date: Sat, 26 Aug 2006 17:06:55 +0200 From: Adrian Bunk To: Nathan Scott Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] fs/xfs/xfs_bmap.c:xfs_bmapi(): fix a bug Message-ID: <20060826150654.GE4765@stusta.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.12-2006-07-14 X-archive-position: 8781 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: xfs Content-Length: 738 Lines: 23 This patch fixes the following bug introduced by commit 39269e29d4aad04252e0debec4c9b01bac16a257: Since bma.conv is a char and XFS_BMAPI_CONVERT is 0x1000, bma.conv was always assigned zero. Spotted by the GNU C compiler (SVN version). Signed-off-by: Adrian Bunk --- linux-2.6.18-rc4-mm2/fs/xfs/xfs_bmap.c.old 2006-08-26 03:31:23.000000000 +0200 +++ linux-2.6.18-rc4-mm2/fs/xfs/xfs_bmap.c 2006-08-26 03:31:28.000000000 +0200 @@ -4993,7 +4993,7 @@ xfs_bmapi( bma.firstblock = *firstblock; bma.alen = alen; bma.off = aoff; - bma.conv = (flags & XFS_BMAPI_CONVERT); + bma.conv = !!(flags & XFS_BMAPI_CONVERT); bma.wasdel = wasdelay; bma.minlen = minlen; bma.low = flist->xbf_low; From owner-xfs@oss.sgi.com Sat Aug 26 18:07:46 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 26 Aug 2006 18:07:56 -0700 (PDT) Received: from vega.opentrend.net (vega.opentrend.net [65.39.131.100]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7R17kDW005637 for ; Sat, 26 Aug 2006 18:07:46 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by vega.opentrend.net (Postfix) with ESMTP id 4C938580153D for ; Sat, 26 Aug 2006 19:08:35 -0400 (EDT) Received: from vega.opentrend.net ([127.0.0.1]) by localhost (vega [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26463-03 for ; Sat, 26 Aug 2006 19:08:34 -0400 (EDT) Received: from mimosa.opentrend.net (mimosa.opentrend.net [192.168.120.11]) by vega.opentrend.net (Postfix) with ESMTP id ED6A158014F7 for ; Sat, 26 Aug 2006 19:08:33 -0400 (EDT) Received: by mimosa.opentrend.net (Postfix, from userid 1000) id 8F9731C00B82; Sat, 26 Aug 2006 19:08:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mimosa.opentrend.net (Postfix) with ESMTP id 74E461C00B62 for ; Sat, 26 Aug 2006 19:08:27 -0400 (EDT) Date: Sat, 26 Aug 2006 19:08:27 -0400 (EDT) From: Robert Brockway To: xfs@oss.sgi.com Subject: Thanks! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 8782 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rbrockway@opentrend.net Precedence: bulk X-list: xfs Content-Length: 849 Lines: 22 Hi guys. I think the poor hard working developers get a lot more negative messages than positive (it's broken, there's a bug, etc) so I just wanted to send a positive message. I've been a happy xfs user for many years and I've never had a problem with the filesystem. Today I managed to powerdown a firewire drive with an XFS filesystem on it while it was mounted (oops). Anyway there was FS corruption and after a vanilla xfs_repair failed I had to resort to xfs_repair -L. The filesystem was fully repaired and is now fine. Thanks a bunch to the xfs developers. Cheers, Rob -- Robert Brockway B.Sc. Phone: +1-905-821-2327 Senior Technical Consultant Urgent Support: +1-416-669-3073 OpenTrend Solutions Ltd Email: support@opentrend.net Web: www.opentrend.net From owner-xfs@oss.sgi.com Sun Aug 27 02:00:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 27 Aug 2006 02:00:13 -0700 (PDT) Received: from zenon.apartia.fr (zenon.apartia.fr [82.66.93.83]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7R901DW012155 for ; Sun, 27 Aug 2006 02:00:03 -0700 Received: from styx.apartia.fr (styx.apartia.fr [10.0.3.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "styx.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by zenon.apartia.fr (Postfix) with ESMTP id 408CBF5176A06 for ; Sun, 27 Aug 2006 09:28:11 +0200 (CEST) Received: by styx.apartia.fr (Postfix, from userid 1000) id 07182B2AE877; Sun, 27 Aug 2006 09:28:10 +0200 (CEST) Date: Sun, 27 Aug 2006 09:28:10 +0200 From: Louis-David Mitterrand To: xfs@oss.sgi.com Subject: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory Message-ID: <20060827072810.GA4098@apartia.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 8784 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs Content-Length: 1289 Lines: 49 Package: xfsprogs Version: 2.8.11-1 Followup-For: Bug #382935 Hello, Using xfs_repair on a 2TB partition I get: 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 - agno = 8 - agno = 9 - agno = 10 xfs_repair: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-6-debian-styx Locale: LANG=en_CA, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15) Versions of packages xfsprogs depends on: ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libreadline5 5.1-7 GNU readline and history libraries ii libuuid1 1.39-1 universally unique id library xfsprogs recommends no packages. -- no debconf information From owner-xfs@oss.sgi.com Sun Aug 27 02:00:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 27 Aug 2006 02:00:12 -0700 (PDT) Received: from zenon.apartia.fr (zenon.apartia.fr [82.66.93.83]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7R901DW012154 for ; Sun, 27 Aug 2006 02:00:03 -0700 Received: from styx.apartia.fr (styx.apartia.fr [10.0.3.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "styx.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by zenon.apartia.fr (Postfix) with ESMTP id 3CBACF02F333E for ; Sun, 27 Aug 2006 09:21:24 +0200 (CEST) Received: by styx.apartia.fr (Postfix, from userid 1000) id EFF03B2AE877; Sun, 27 Aug 2006 09:21:23 +0200 (CEST) Date: Sun, 27 Aug 2006 09:21:23 +0200 From: Louis-David Mitterrand To: xfs@oss.sgi.com Subject: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory Message-ID: <20060827072123.GA3875@apartia.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 8783 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ldm@apartia.org Precedence: bulk X-list: xfs Content-Length: 1289 Lines: 49 Package: xfsprogs Version: 2.8.11-1 Followup-For: Bug #382935 Hello, Using xfs_repair on a 2TB partition I get: 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 - agno = 8 - agno = 9 - agno = 10 xfs_repair: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-6-debian-styx Locale: LANG=en_CA, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15) Versions of packages xfsprogs depends on: ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libreadline5 5.1-7 GNU readline and history libraries ii libuuid1 1.39-1 universally unique id library xfsprogs recommends no packages. -- no debconf information From owner-xfs@oss.sgi.com Sun Aug 27 04:36:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 27 Aug 2006 04:37:10 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7RBalDW010882 for ; Sun, 27 Aug 2006 04:36:59 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1GHIvu-0003sQ-8r for ; Sun, 27 Aug 2006 12:36:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17649.33701.520393.118416@base.ty.sabi.co.UK> Date: Sun, 27 Aug 2006 12:36:05 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory In-Reply-To: <20060827072810.GA4098@apartia.fr> References: <20060827072810.GA4098@apartia.fr> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 8785 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 455 Lines: 15 >>> On Sun, 27 Aug 2006 09:28:10 +0200, Louis-David Mitterrand >>> said: [ ... ] > xfs_repair: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory Most probably this is not a bug. The system probably does not have enough memory. "Cannot allocate memory" is probably what is happening. This has been discussed many times previously... http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00045.html [ ... ] From owner-xfs@oss.sgi.com Sun Aug 27 13:43:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 27 Aug 2006 13:43:17 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7RKh1DW028222 for ; Sun, 27 Aug 2006 13:43:05 -0700 Received: (qmail 3856 invoked from network); 27 Aug 2006 20:42:24 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 27 Aug 2006 20:42:23 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 06C90181370F; Sun, 27 Aug 2006 13:42:22 -0700 (PDT) Date: Sun, 27 Aug 2006 13:42:22 -0700 From: Chris Wedgwood To: Louis-David Mitterrand Cc: xfs@oss.sgi.com Subject: Re: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory Message-ID: <20060827204222.GB12065@tuatara.stupidest.org> References: <20060827072810.GA4098@apartia.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060827072810.GA4098@apartia.fr> X-archive-position: 8787 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 266 Lines: 7 On Sun, Aug 27, 2006 at 09:28:10AM +0200, Louis-David Mitterrand wrote: > xfs_repair: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory Not enough memory, try adding swap space if that's possible? (BTW, how much memory do you have in this case?) From owner-xfs@oss.sgi.com Sun Aug 27 13:51:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 27 Aug 2006 13:51:59 -0700 (PDT) Received: from zenon.apartia.fr (zenon.apartia.fr [82.66.93.83]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7RKppDW030674 for ; Sun, 27 Aug 2006 13:51:52 -0700 Received: from styx.apartia.fr (styx.apartia.fr [10.0.3.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "styx.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by zenon.apartia.fr (Postfix) with ESMTP id 42FB0F332BA03 for ; Sun, 27 Aug 2006 22:51:20 +0200 (CEST) Received: by styx.apartia.fr (Postfix, from userid 1000) id 5B74DB2AE7C9; Sun, 27 Aug 2006 22:51:20 +0200 (CEST) Date: Sun, 27 Aug 2006 22:51:19 +0200 From: Louis-David Mitterrand To: xfs@oss.sgi.com Subject: Re: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory Message-ID: <20060827205119.GA10325@apartia.fr> References: <20060827072810.GA4098@apartia.fr> <20060827204222.GB12065@tuatara.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060827204222.GB12065@tuatara.stupidest.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 8788 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs Content-Length: 647 Lines: 15 On Sun, Aug 27, 2006 at 01:42:22PM -0700, Chris Wedgwood wrote: > On Sun, Aug 27, 2006 at 09:28:10AM +0200, Louis-David Mitterrand wrote: > > > xfs_repair: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory > > Not enough memory, try adding swap space if that's possible? (BTW, > how much memory do you have in this case?) I had 2GB RAM and a 300GB swap partition and was monitoring memory consumption with "top": it never went over 3BG before failing. With the 2.7.x version of xfs_repair found on a live CD distro, memory consumption never exceeds 1GB on the same filesystem. Why has the 2.8.11 version become so greedy? From owner-xfs@oss.sgi.com Sun Aug 27 17:07:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 27 Aug 2006 17:07:33 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7S06xDW018590; Sun, 27 Aug 2006 17:07:13 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25885; Mon, 28 Aug 2006 10:06:10 +1000 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 k7S068eQ4850234; Mon, 28 Aug 2006 10:06:08 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7S066ut4752196; Mon, 28 Aug 2006 10:06:06 +1000 (AEST) Date: Mon, 28 Aug 2006 10:06:06 +1000 From: David Chinner To: Louis-David Mitterrand Cc: xfs@oss.sgi.com, Linux XFS Subject: Re: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory Message-ID: <20060828000606.GF807830@melbourne.sgi.com> References: <20060827072810.GA4098@apartia.fr> <20060827204222.GB12065@tuatara.stupidest.org> <20060827205119.GA10325@apartia.fr> <20060827072810.GA4098@apartia.fr> <20060827204222.GB12065@tuatara.stupidest.org> <20060827072810.GA4098@apartia.fr> <17649.33701.520393.118416@base.ty.sabi.co.UK> <20060827072810.GA4098@apartia.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060827205119.GA10325@apartia.fr> <20060827204222.GB12065@tuatara.stupidest.org> <17649.33701.520393.118416@base.ty.sabi.co.UK> <20060827072810.GA4098@apartia.fr> User-Agent: Mutt/1.4.2.1i X-archive-position: 8789 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2033 Lines: 61 On Sun, Aug 27, 2006 at 09:28:10AM +0200, Louis-David Mitterrand wrote: > Package: xfsprogs > Version: 2.8.11-1 > Followup-For: Bug #382935 > > Hello, > > Using xfs_repair on a 2TB partition I get: ..... > xfs_repair: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory > > > > -- System Information: > Debian Release: testing/unstable > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (499, 'experimental') > Architecture: i386 (i686) ia32, multi-terabyte filesystem, so as Peter pointed out: On Sun, Aug 27, 2006 at 12:36:05PM +0100, Peter Grandi wrote: > Most probably this is not a bug. The system probably does not > have enough memory. "Cannot allocate memory" is probably what > is happening. This has been discussed many times previously... > > http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00045.html This will be the problem. On Sun, Aug 27, 2006 at 10:51:19PM +0200, Louis-David Mitterrand wrote: > On Sun, Aug 27, 2006 at 01:42:22PM -0700, Chris Wedgwood wrote: > > On Sun, Aug 27, 2006 at 09:28:10AM +0200, Louis-David Mitterrand wrote: > > > > > xfs_repair: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory > > > > Not enough memory, try adding swap space if that's possible? (BTW, > > how much memory do you have in this case?) > > I had 2GB RAM and a 300GB swap partition and was monitoring memory > consumption with "top": it never went over 3BG before failing. It' won't matter how much swap you add - ia32 has a per-process memory limit of 1-4GB RAM depending on kernel build options. > With the 2.7.x version of xfs_repair found on a live CD distro, memory > consumption never exceeds 1GB on the same filesystem. Why has the 2.8.11 > version become so greedy? xfs_repair is undergoing a lot of change at the moment and so memory usage may have blown out under some circumstances. Do you have figures on how much more memory xfs_repair is using? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Aug 27 17:32:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 27 Aug 2006 17:32:53 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7S0WGDW025596 for ; Sun, 27 Aug 2006 17:32:31 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26458; Mon, 28 Aug 2006 10:31:22 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7S0VIgw3120734; Mon, 28 Aug 2006 10:31:19 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7S0VDjQ3109506; Mon, 28 Aug 2006 10:31:13 +1000 (EST) Date: Mon, 28 Aug 2006 10:31:13 +1000 From: Nathan Scott To: Adrian Bunk Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] fs/xfs/xfs_bmap.c:xfs_bmapi(): fix a bug Message-ID: <20060828103113.A3119251@wobbly.melbourne.sgi.com> References: <20060826150654.GE4765@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060826150654.GE4765@stusta.de>; from bunk@stusta.de on Sat, Aug 26, 2006 at 05:06:55PM +0200 X-archive-position: 8790 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 220 Lines: 12 On Sat, Aug 26, 2006 at 05:06:55PM +0200, Adrian Bunk wrote: > ... > Since bma.conv is a char and XFS_BMAPI_CONVERT is 0x1000, bma.conv was > always assigned zero. Yep, looks good, thanks Adrian. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Aug 27 18:31:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 27 Aug 2006 18:31:56 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7S1VRDW009028 for ; Sun, 27 Aug 2006 18:31:38 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA27724; Mon, 28 Aug 2006 11:30:40 +1000 Message-ID: <44F2476C.1010101@sgi.com> Date: Mon, 28 Aug 2006 11:31:24 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 955157: Deadlock in xfs_bulkstat() when an invalid user buffer pointer is passed References: <44CE9F23.7000605@sgi.com> <44EE9DF7.1080904@sgi.com> <44EEA07E.9070207@sgi.com> <44EEA313.80101@sgi.com> In-Reply-To: <44EEA313.80101@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8791 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 504 Lines: 15 Date: Mon Aug 28 11:29:07 AEST 2006 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs-dmapi Inspected by: bnaujok Author: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:26869a fs/xfs/xfs_itable.c - 1.147 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.147&r2=text&tr2=1.146&f=h - pv 955157, rv bnaujok - break the loop on EFAULT formatter() error From owner-xfs@oss.sgi.com Sun Aug 27 18:43:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 27 Aug 2006 18:43:29 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7S1hHDW013396 for ; Sun, 27 Aug 2006 18:43:17 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1GHW49-0008Lr-Qw for ; Mon, 28 Aug 2006 02:37:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <17650.18647.754049.828428@base.ty.sabi.co.UK> Date: Mon, 28 Aug 2006 02:37:27 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory In-Reply-To: <20060827205119.GA10325@apartia.fr> References: <20060827072810.GA4098@apartia.fr> <20060827204222.GB12065@tuatara.stupidest.org> <20060827205119.GA10325@apartia.fr> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k7S1hIDW013402 X-archive-position: 8792 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 1513 Lines: 42 >>> On Sun, 27 Aug 2006 22:51:19 +0200, Louis-David Mitterrand >>> said: >> [ ... ] xfs_repair: libxfs_initbuf can't memalign 4096 bytes: >> Cannot allocate memory [ ... ] > I had 2GB RAM and a 300GB swap partition and was monitoring > memory consumption with "top": it never went over 3BG before > failing. The default 3GiB address space limit per process on a 32 bit system is rather well documented, for a summary: http://WWW.sabi.co.UK/Notes/#060821c Let's mention this classic entry again: http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00045.html «> > Your filesystem (8TiB) may simply bee too large for your > > system to be able to repair. Try mounting it on a 64bit > > system with more RAM in it and repairing it from there. Now that linux supports larger than 2TiB filesystems on 32 bit systems, this is true for Linux as well.» A previous entry in the same thread might help too: http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00037.html «> I try xfs_check and xfs_ncheck (and more progs) with > +200GB swap, but no different! less than 1 second and get > out of memory. Swap won't help if you're running an ia32 (32bit) kernel - you have a per-process memory limit of 1-4GiB (depending on kernel and config). The amount of physical memory and swap does not change this limitation.» Trying hard to avoid looking at what «has been discussed many times previously» is a great time saving strategy! :-) From owner-xfs@oss.sgi.com Sun Aug 27 18:49:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 27 Aug 2006 18:49:42 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7S1nCDW015010 for ; Sun, 27 Aug 2006 18:49:23 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA28178; Mon, 28 Aug 2006 11:48:25 +1000 Message-ID: <44F24B95.3040504@sgi.com> Date: Mon, 28 Aug 2006 11:49:09 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 955274: DMAPI qa test fixes References: <44CE9F23.7000605@sgi.com> <44EE9DF7.1080904@sgi.com> <44EEA07E.9070207@sgi.com> <44EEA313.80101@sgi.com> In-Reply-To: <44EEA313.80101@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8793 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 712 Lines: 18 Date: Mon Aug 28 11:44:36 AEST 2006 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/xfs-cmds Inspected by: bnaujok Author: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26870a xfstests/dmapi/src/suite2/src/test_dmattr.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/dmapi/src/suite2/src/test_dmattr.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h - pv 955274, rv bnaujok - add 1sec delay between file creation and changing its attribute via dm_set_dmattr(). If the machine is too fast the ctime doesn't change between create and dm_set_dmattr() and the test fails. From owner-xfs@oss.sgi.com Sun Aug 27 20:32:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 27 Aug 2006 20:32:53 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7S3WKDW019197 for ; Sun, 27 Aug 2006 20:32:32 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA00464 for ; Mon, 28 Aug 2006 13:31:36 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7S3VYgw3119471 for ; Mon, 28 Aug 2006 13:31:34 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7S3VW2u3127520 for xfs@oss.sgi.com; Mon, 28 Aug 2006 13:31:32 +1000 (EST) Date: Mon, 28 Aug 2006 13:31:32 +1000 From: Nathan Scott To: xfs@oss.sgi.com Subject: review: change default realtime extsize Message-ID: <20060828133132.A3124842@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8794 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1422 Lines: 37 Hi, While testing something else recently, I noticed we were always creating a large number of unwritten extents during page cache writout to the realtime subvolume. It turned out to be because of the way we are typically called with page sized allocation requests, but we always allocate much more than a page. Back when realtime subvols could only use direct I/O this was fine (apps typically used larger IO sizes) but now its not so good. These larger allocations are ending up meaning we need to do many additional unwritten extent conversions (i.e. more transactions, and more log traffic), which we can easily avoid. Since we have a default 4K filesystem blocksize on the data device, there would seem to be no harm in matching that on the realtime subvolume, by default. This simple mkfs tweak does just that... cheers. -- Nathan Index: xfsprogs/include/xfs_rtalloc.h =================================================================== --- xfsprogs.orig/include/xfs_rtalloc.h 2006-08-18 11:50:35.916857000 +1000 +++ xfsprogs/include/xfs_rtalloc.h 2006-08-18 11:55:44.820162250 +1000 @@ -25,7 +25,7 @@ struct xfs_trans; /* Min and max rt extent sizes, specified in bytes */ #define XFS_MAX_RTEXTSIZE (1024 * 1024 * 1024) /* 1GB */ -#define XFS_DFL_RTEXTSIZE (64 * 1024) /* 64KB */ +#define XFS_DFL_RTEXTSIZE (4 * 1024) /* 4KB */ #define XFS_MIN_RTEXTSIZE (4 * 1024) /* 4KB */ /* From owner-xfs@oss.sgi.com Mon Aug 28 00:00:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 28 Aug 2006 00:00:55 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7S70VDW011859 for ; Mon, 28 Aug 2006 00:00:42 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA04763; Mon, 28 Aug 2006 16:59:44 +1000 Message-ID: <44F2948C.4070005@sgi.com> Date: Mon, 28 Aug 2006 17:00:28 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Nathan Scott CC: xfs@oss.sgi.com Subject: Re: review: greedy allocator vs kmflags References: <20060828163004.B3100886@wobbly.melbourne.sgi.com> In-Reply-To: <20060828163004.B3100886@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8800 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 692 Lines: 23 Nathan Scott wrote: > Hi Vlad, > > This is the last iteration on updating the greedy alloc routine to > be more generic and properly handle the passed in flags wrt sleep or > nosleep (following up on Dave's suggestion, and someone else to me > privately, offlist). Could you give it a final review for me? > > thanks. > > It is looking good Nathan. One thing I noticed today when I was building the modules was that kmem_zalloc_greedy() is already in use in several places. There were a few warnings about type mismatch of the first argument "size_t *size" and missing kmem_zalloc_greedy symbol at the end. Not sure if this is important but just thought to mention it. Regards, Vlad From owner-xfs@oss.sgi.com Mon Aug 28 00:24:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 28 Aug 2006 00:25:09 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7S7OcDW023927 for ; Mon, 28 Aug 2006 00:24:50 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA05299; Mon, 28 Aug 2006 17:23:50 +1000 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 k7S7NleQ4964871; Mon, 28 Aug 2006 17:23:47 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7S7Nh674962752; Mon, 28 Aug 2006 17:23:43 +1000 (AEST) Date: Mon, 28 Aug 2006 17:23:43 +1000 From: David Chinner To: David Chinner Cc: Stephane Doyon , Luciano Chavez , linux-xfs@oss.sgi.com Subject: Re: Infinite loop in xfssyncd on full file system Message-ID: <20060828072343.GJ807872@melbourne.sgi.com> References: <20060823040218.GC807872@melbourne.sgi.com> <20060823044829.GD807872@melbourne.sgi.com> <1156360259.5368.7.camel@localhost> <20060823040218.GC807872@melbourne.sgi.com> <20060823044829.GD807872@melbourne.sgi.com> <20060823231429.GF807872@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20060823231429.GF807872@melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8801 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 4695 Lines: 120 On Thu, Aug 24, 2006 at 09:14:29AM +1000, David Chinner wrote: > On Wed, Aug 23, 2006 at 11:00:43AM -0400, Stephane Doyon wrote: > > On Wed, 23 Aug 2006, David Chinner wrote: > > > > >On Wed, Aug 23, 2006 at 02:02:18PM +1000, David Chinner wrote: > > >>On Tue, Aug 22, 2006 at 04:01:10PM -0400, Stephane Doyon wrote: > > >>>I'm seeing what appears to be an infinite loop in xfssyncd. It is > > >>>triggered when writing to a file system that is full or nearly full. I > > >>>have pinpointed the change that introduced this problem: it's > > >>> > > >>> "TAKE 947395 - Fixing potential deadlock in space allocation and > > >>> freeing due to ENOSPC" > > >>> > > >>>git commit d210a28cd851082cec9b282443f8cc0e6fc09830. > > ..... > > > >>Now we know what patch introduces the problem, we know where to look. > > >>Stay tuned... > > > > > >I've had a quick look at the above commit. I'm not yet certain that > > >everything is correct in terms of the semantics laid down in the > > >change or that enough blocks are reserved for btree splits , but I > > > > I actually tried, naively, to bump up SET_ASIDE_BLOCKS from 8 to 32. I > > won't claim to understand half of what's going on but I wondered whether > > that might make the problem noticeably harder to reproduce at least, but > > it had no effect ;-). > > That was going to be my next question. ;) > > At least that rules out a small error in the block reservation decision, > so I'm going to have analyse all the code paths the mod introduced > and work out what is going wrong. You know, if you had of buumped it up just a bit higher, the problem might have gone away. With a fielsystem that only has 8 AGs in it, if you bumped it to 33, then problem would have disappeared.... What we have here is a small error in the block reservation code. Basically, all the logic is correct except for one critical detail - while we need to reserve 4 blocks for the AG freelist so a minimum allocation can succeed, we need to reserve 4 blocks in _every AG_ so that when every AG is empty we will fail with ENOSPC instead of trying to allocate a block when we have an AG with less thaan 4 free blocks in it. So, it's not 4 blocks filesystem wide we need to reserve, it's 4 blocks per AG we need to reserve. Stephane and Luciano, can you try the patch attæched below - it fixes the 100% repeatable test case (while [ 1 ]; dd to enospc; done) on my test machine. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_mount.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c 2006-08-18 15:29:28.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c 2006-08-28 17:11:18.496258662 +1000 @@ -1257,10 +1257,11 @@ xfs_mod_sb(xfs_trans_t *tp, __int64_t fi * all delayed extents need to be actually allocated. To get around * this, we explicitly set aside a few blocks which will not be * reserved in delayed allocation. Considering the minimum number of - * needed freelist blocks is 4 fsbs, a potential split of file's bmap - * btree requires 1 fsb, so we set the number of set-aside blocks to 8. -*/ -#define SET_ASIDE_BLOCKS 8 + * needed freelist blocks is 4 fsbs _per AG_, a potential split of file's bmap + * btree requires 1 fsb, so we set the number of set-aside blocks + * to 4 + 4*agcount. + */ +#define XFS_SET_ASIDE_BLOCKS(mp) (4 + ((mp)->m_sb.sb_agcount * 4)) /* * xfs_mod_incore_sb_unlocked() is a utility routine common used to apply @@ -1306,7 +1307,8 @@ xfs_mod_incore_sb_unlocked(xfs_mount_t * return 0; case XFS_SBS_FDBLOCKS: - lcounter = (long long)mp->m_sb.sb_fdblocks - SET_ASIDE_BLOCKS; + lcounter = (long long) + mp->m_sb.sb_fdblocks - XFS_SET_ASIDE_BLOCKS(mp); res_used = (long long)(mp->m_resblks - mp->m_resblks_avail); if (delta > 0) { /* Putting blocks back */ @@ -1340,7 +1342,7 @@ xfs_mod_incore_sb_unlocked(xfs_mount_t * } } - mp->m_sb.sb_fdblocks = lcounter + SET_ASIDE_BLOCKS; + mp->m_sb.sb_fdblocks = lcounter + XFS_SET_ASIDE_BLOCKS(mp); return 0; case XFS_SBS_FREXTENTS: lcounter = (long long)mp->m_sb.sb_frextents; @@ -2108,11 +2110,11 @@ again: case XFS_SBS_FDBLOCKS: BUG_ON((mp->m_resblks - mp->m_resblks_avail) != 0); - lcounter = icsbp->icsb_fdblocks; + lcounter = icsbp->icsb_fdblocks - XFS_SET_ASIDE_BLOCKS(mp); lcounter += delta; if (unlikely(lcounter < 0)) goto slow_path; - icsbp->icsb_fdblocks = lcounter; + icsbp->icsb_fdblocks = lcounter + XFS_SET_ASIDE_BLOCKS(mp); break; default: BUG(); From owner-xfs@oss.sgi.com Mon Aug 28 08:05:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 28 Aug 2006 08:06:01 -0700 (PDT) Received: from zenon.apartia.fr (zenon.apartia.fr [82.66.93.83]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7SF5tDW028087 for ; Mon, 28 Aug 2006 08:05:56 -0700 Received: from trajan.apartia.fr (trajan.apartia.fr [10.0.3.121]) by zenon.apartia.fr (Postfix) with ESMTP id 51308F08B4401 for ; Mon, 28 Aug 2006 17:05:20 +0200 (CEST) Received: by trajan.apartia.fr (Postfix, from userid 1000) id E81F72588124; Mon, 28 Aug 2006 17:04:56 +0200 (CEST) Date: Mon, 28 Aug 2006 17:04:56 +0200 From: Louis-David Mitterrand To: xfs@oss.sgi.com Subject: Re: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory Message-ID: <20060828150456.GA8242@apartia.fr> Mail-Followup-To: xfs@oss.sgi.com References: <20060827072123.GA3875@apartia.fr> <200608280555.PAA03288@larry.melbourne.sgi.com> <20060828145751.GA7993@apartia.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060828145751.GA7993@apartia.fr> User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 8805 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs Content-Length: 1151 Lines: 30 On Mon, Aug 28, 2006 at 04:57:51PM +0200, Louis-David Mitterrand wrote: > On Mon, Aug 28, 2006 at 03:57:02PM +1000, Barry Naujok wrote: > > > > > > Hello, > > > > > > Using xfs_repair on a 2TB partition I get: > > [snip] > > > xfs_repair: libxfs_initbuf can't memalign 4096 bytes: > > > Cannot allocate memory > > > > Can you tell me how many inodes you have on your filesystem? > > > sylla:~# xfs_info /dev/md1 > meta-data=/dev/root isize=256 agcount=32, agsize=15252656 blks > = sectsz=4096 attr=0 > data = bsize=4096 blocks=488084704, imaxpct=25 > = sunit=16 swidth=80 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=32768, version=2 > = sectsz=4096 sunit=1 blks > realtime =none extsz=327680 blocks=0, rtextents=0 > > Hmmm, no inode info here... How do I find it? Ok, got it: sylla:~# df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/md1 895571792 7921236 887650556 1% / From owner-xfs@oss.sgi.com Mon Aug 28 07:58:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 28 Aug 2006 07:59:06 -0700 (PDT) Received: from zenon.apartia.fr (zenon.apartia.fr [82.66.93.83]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7SEwuDW026315 for ; Mon, 28 Aug 2006 07:58:57 -0700 Received: from trajan.apartia.fr (trajan.apartia.fr [10.0.3.121]) by zenon.apartia.fr (Postfix) with ESMTP id 02773F08B4401 for ; Mon, 28 Aug 2006 16:58:15 +0200 (CEST) Received: by trajan.apartia.fr (Postfix, from userid 1000) id 872AE2588124; Mon, 28 Aug 2006 16:57:51 +0200 (CEST) Date: Mon, 28 Aug 2006 16:57:51 +0200 From: Louis-David Mitterrand To: xfs@oss.sgi.com Subject: Re: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory Message-ID: <20060828145751.GA7993@apartia.fr> Mail-Followup-To: xfs@oss.sgi.com References: <20060827072123.GA3875@apartia.fr> <200608280555.PAA03288@larry.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608280555.PAA03288@larry.melbourne.sgi.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 8804 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs Content-Length: 888 Lines: 24 On Mon, Aug 28, 2006 at 03:57:02PM +1000, Barry Naujok wrote: > > > > Hello, > > > > Using xfs_repair on a 2TB partition I get: > [snip] > > xfs_repair: libxfs_initbuf can't memalign 4096 bytes: > > Cannot allocate memory > > Can you tell me how many inodes you have on your filesystem? > sylla:~# xfs_info /dev/md1 meta-data=/dev/root isize=256 agcount=32, agsize=15252656 blks = sectsz=4096 attr=0 data = bsize=4096 blocks=488084704, imaxpct=25 = sunit=16 swidth=80 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks realtime =none extsz=327680 blocks=0, rtextents=0 Hmmm, no inode info here... How do I find it? From owner-xfs@oss.sgi.com Mon Aug 28 13:03:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 28 Aug 2006 13:04:00 -0700 (PDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.150]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7SK3eDW021934 for ; Mon, 28 Aug 2006 13:03:41 -0700 Received: from e31.co.us.ibm.com ([9.17.249.41]) by pokfb.esmtp.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7SJd40L001230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Aug 2006 15:39:05 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id k7SJcuJ0006472 for ; Mon, 28 Aug 2006 15:38:56 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7SJcuRs273120 for ; Mon, 28 Aug 2006 13:38:56 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7SJctNq001695 for ; Mon, 28 Aug 2006 13:38:55 -0600 Received: from [9.53.41.228] ([9.53.41.228]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7SJctW0001679; Mon, 28 Aug 2006 13:38:55 -0600 Subject: Re: Infinite loop in xfssyncd on full file system From: Luciano Chavez To: David Chinner Cc: Stephane Doyon , linux-xfs@oss.sgi.com In-Reply-To: <20060828072343.GJ807872@melbourne.sgi.com> References: <20060823040218.GC807872@melbourne.sgi.com> <20060823044829.GD807872@melbourne.sgi.com> <1156360259.5368.7.camel@localhost> <20060823040218.GC807872@melbourne.sgi.com> <20060823044829.GD807872@melbourne.sgi.com> <20060823231429.GF807872@melbourne.sgi.com> <20060828072343.GJ807872@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: IBM Date: Mon, 28 Aug 2006 14:40:30 -0500 Message-Id: <1156794030.5848.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 8bit X-archive-position: 8808 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lnx1138@us.ibm.com Precedence: bulk X-list: xfs Content-Length: 5338 Lines: 134 On Mon, 2006-08-28 at 17:23 +1000, David Chinner wrote: > On Thu, Aug 24, 2006 at 09:14:29AM +1000, David Chinner wrote: > > On Wed, Aug 23, 2006 at 11:00:43AM -0400, Stephane Doyon wrote: > > > On Wed, 23 Aug 2006, David Chinner wrote: > > > > > > >On Wed, Aug 23, 2006 at 02:02:18PM +1000, David Chinner wrote: > > > >>On Tue, Aug 22, 2006 at 04:01:10PM -0400, Stephane Doyon wrote: > > > >>>I'm seeing what appears to be an infinite loop in xfssyncd. It is > > > >>>triggered when writing to a file system that is full or nearly full. I > > > >>>have pinpointed the change that introduced this problem: it's > > > >>> > > > >>> "TAKE 947395 - Fixing potential deadlock in space allocation and > > > >>> freeing due to ENOSPC" > > > >>> > > > >>>git commit d210a28cd851082cec9b282443f8cc0e6fc09830. > > > > ..... > > > > > >>Now we know what patch introduces the problem, we know where to look. > > > >>Stay tuned... > > > > > > > >I've had a quick look at the above commit. I'm not yet certain that > > > >everything is correct in terms of the semantics laid down in the > > > >change or that enough blocks are reserved for btree splits , but I > > > > > > I actually tried, naively, to bump up SET_ASIDE_BLOCKS from 8 to 32. I > > > won't claim to understand half of what's going on but I wondered whether > > > that might make the problem noticeably harder to reproduce at least, but > > > it had no effect ;-). > > > > That was going to be my next question. ;) > > > > At least that rules out a small error in the block reservation decision, > > so I'm going to have analyse all the code paths the mod introduced > > and work out what is going wrong. > > You know, if you had of buumped it up just a bit higher, the problem might > have gone away. With a fielsystem that only has 8 AGs in it, if you bumped > it to 33, then problem would have disappeared.... > > What we have here is a small error in the block reservation code. Basically, > all the logic is correct except for one critical detail - while we need to > reserve 4 blocks for the AG freelist so a minimum allocation can succeed, > we need to reserve 4 blocks in _every AG_ so that when every AG is empty > we will fail with ENOSPC instead of trying to allocate a block when we > have an AG with less thaan 4 free blocks in it. > > So, it's not 4 blocks filesystem wide we need to reserve, it's 4 blocks per AG > we need to reserve. > > Stephane and Luciano, can you try the patch attæched below - it fixes the > 100% repeatable test case (while [ 1 ]; dd to enospc; done) on my test > machine. > Dave, The latest patch seems to work for me running bonnie++ on a small 2GB XFS filesystem. bonnie++ gets an ENOSPC on a write() and ends plus I don't see the softwatchdog timer dump the kernel stack or xfssyncd looping. Thanks! Can you keep me posted when your patch is included in your CVS please? > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > > --- > fs/xfs/xfs_mount.c | 18 ++++++++++-------- > 1 file changed, 10 insertions(+), 8 deletions(-) > > Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c 2006-08-18 15:29:28.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c 2006-08-28 17:11:18.496258662 +1000 > @@ -1257,10 +1257,11 @@ xfs_mod_sb(xfs_trans_t *tp, __int64_t fi > * all delayed extents need to be actually allocated. To get around > * this, we explicitly set aside a few blocks which will not be > * reserved in delayed allocation. Considering the minimum number of > - * needed freelist blocks is 4 fsbs, a potential split of file's bmap > - * btree requires 1 fsb, so we set the number of set-aside blocks to 8. > -*/ > -#define SET_ASIDE_BLOCKS 8 > + * needed freelist blocks is 4 fsbs _per AG_, a potential split of file's bmap > + * btree requires 1 fsb, so we set the number of set-aside blocks > + * to 4 + 4*agcount. > + */ > +#define XFS_SET_ASIDE_BLOCKS(mp) (4 + ((mp)->m_sb.sb_agcount * 4)) > > /* > * xfs_mod_incore_sb_unlocked() is a utility routine common used to apply > @@ -1306,7 +1307,8 @@ xfs_mod_incore_sb_unlocked(xfs_mount_t * > return 0; > case XFS_SBS_FDBLOCKS: > > - lcounter = (long long)mp->m_sb.sb_fdblocks - SET_ASIDE_BLOCKS; > + lcounter = (long long) > + mp->m_sb.sb_fdblocks - XFS_SET_ASIDE_BLOCKS(mp); > res_used = (long long)(mp->m_resblks - mp->m_resblks_avail); > > if (delta > 0) { /* Putting blocks back */ > @@ -1340,7 +1342,7 @@ xfs_mod_incore_sb_unlocked(xfs_mount_t * > } > } > > - mp->m_sb.sb_fdblocks = lcounter + SET_ASIDE_BLOCKS; > + mp->m_sb.sb_fdblocks = lcounter + XFS_SET_ASIDE_BLOCKS(mp); > return 0; > case XFS_SBS_FREXTENTS: > lcounter = (long long)mp->m_sb.sb_frextents; > @@ -2108,11 +2110,11 @@ again: > case XFS_SBS_FDBLOCKS: > BUG_ON((mp->m_resblks - mp->m_resblks_avail) != 0); > > - lcounter = icsbp->icsb_fdblocks; > + lcounter = icsbp->icsb_fdblocks - XFS_SET_ASIDE_BLOCKS(mp); > lcounter += delta; > if (unlikely(lcounter < 0)) > goto slow_path; > - icsbp->icsb_fdblocks = lcounter; > + icsbp->icsb_fdblocks = lcounter + XFS_SET_ASIDE_BLOCKS(mp); > break; > default: > BUG(); -- Luciano Chavez IBM From owner-xfs@oss.sgi.com Mon Aug 28 14:39:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 28 Aug 2006 14:40:17 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7SLdrDW004636 for ; Mon, 28 Aug 2006 14:39:54 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1GHnsV-0001fY-Kq; Mon, 28 Aug 2006 21:38:39 +0100 Date: Mon, 28 Aug 2006 21:38:39 +0100 From: Christoph Hellwig To: Nathan Scott Cc: xfs@oss.sgi.com Subject: Re: review: change default realtime extsize Message-ID: <20060828203839.GA719@infradead.org> References: <20060828133132.A3124842@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060828133132.A3124842@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8809 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 1021 Lines: 21 On Mon, Aug 28, 2006 at 01:31:32PM +1000, Nathan Scott wrote: > Hi, > > While testing something else recently, I noticed we were always > creating a large number of unwritten extents during page cache > writout to the realtime subvolume. It turned out to be because > of the way we are typically called with page sized allocation > requests, but we always allocate much more than a page. Back > when realtime subvols could only use direct I/O this was fine > (apps typically used larger IO sizes) but now its not so good. > > These larger allocations are ending up meaning we need to do many > additional unwritten extent conversions (i.e. more transactions, > and more log traffic), which we can easily avoid. Since we have > a default 4K filesystem blocksize on the data device, there would > seem to be no harm in matching that on the realtime subvolume, by > default. This simple mkfs tweak does just that... That description makes sense, and given that the one-liner diff is obviously correct. ACK from me. From owner-xfs@oss.sgi.com Mon Aug 28 18:09:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 28 Aug 2006 18:10:02 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7T19lDW002930 for ; Mon, 28 Aug 2006 18:09:48 -0700 Received: by py-out-1112.google.com with SMTP id x31so2420182pye for ; Mon, 28 Aug 2006 18:09:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:sender:message-id; b=NwJRPWpmaoeNFJeVzbAFVS1hPpeHsDHDGVuRRHuBhQAvts1TpAwbFG82XMaOIhxkygPeQTS8bNdzYKAWoJzDfWDsQ5Aa1nB3amzBAHsTxuJfRqof6p13iBFu75WqPSmGpIDKR5A9cpVd3yC2wEUmiswbkWxQkz5EIb5MB+Gzcrc= Received: by 10.35.49.1 with SMTP id b1mr13511388pyk; Mon, 28 Aug 2006 17:05:25 -0700 (PDT) Received: from atlas ( [128.120.136.206]) by mx.gmail.com with ESMTP id y78sm7693851pyg.2006.08.28.17.05.24; Mon, 28 Aug 2006 17:05:25 -0700 (PDT) From: "gert wohlgemuth" To: Subject: accidently deleted files from directory Date: Mon, 28 Aug 2006 17:05:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbK/tdJaWQIAlyYQUyqRjuFz1oExw== Message-ID: <44f384c5.270c085b.5896.ffff9b29@mx.gmail.com> X-archive-position: 8810 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wohlgemuth@ucdavis.edu Precedence: bulk X-list: xfs Content-Length: 1227 Lines: 32 Hi and thx for your help, I'm running a gentoo box and using xfs as file system. On the weekend it happens that I accidentally deleted 1 TB of data (rm -rdf /mnt/lcq). We have no backup of the data (internal reasons of the university...) and it would be nice to get the data somehow back. After the delete the first step was to unmount the partion and this are the info's from the xfs_check program. meta-data=/mnt/lcq isize=256 agcount=32, agsize=9154978 blks = sectsz=512 data = bsize=4096 blocks=292959296, 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 after I did a cat /dev/sda1 | less I could see that some data are still exist and are not overwritten. So I think "all" what I have todo is some how get the journal back. Is there anyway or is all hope lost? Thx gert p.s. pleace CC me (wohlgemuth@ucdavis.edu) because I'm not a member of this mailing list. From owner-xfs@oss.sgi.com Mon Aug 28 22:39:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 28 Aug 2006 22:39:31 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7T5dEDW005171 for ; Mon, 28 Aug 2006 22:39:20 -0700 Received: by py-out-1112.google.com with SMTP id x31so2492119pye for ; Mon, 28 Aug 2006 22:38:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:cc:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to:sender:message-id; b=uVVDcTdkwaq76yB5kOZMn2FCwlPuFYjx3x2Qx2jFx7vJsN/S9D1WnKKYfKOo6gpDigIkquHORzBovXkj4TlKcC79laAq1+0fGy2HDoqjE2KSMLoowCKzjDZNkz7lusC5jpPJO9mO6oQr71OSlHT87Pnp9k5NyjDGWMAlKwarMmo= Received: by 10.35.77.1 with SMTP id e1mr13952320pyl; Mon, 28 Aug 2006 21:28:41 -0700 (PDT) Received: from atlas ( [128.120.136.206]) by mx.gmail.com with ESMTP id a75sm7969156pyf.2006.08.28.21.28.40; Mon, 28 Aug 2006 21:28:40 -0700 (PDT) From: "gert wohlgemuth" To: "'Chris Wedgwood'" Cc: Subject: RE: accidently deleted files from directory Date: Mon, 28 Aug 2006 21:28:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbLIe3DrNyTSi7NRe28HbOqV7liOQAAWnOg In-Reply-To: <20060829041635.GA3166@tuatara.stupidest.org> Message-ID: <44f3c278.059fc255.3075.3597@mx.gmail.com> X-archive-position: 8815 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wohlgemuth@ucdavis.edu Precedence: bulk X-list: xfs Content-Length: 1126 Lines: 42 Thx, I thought so that the data are gone and it's to much to glue it, cause all binary data. So time to step back to ext2, here at least I can restore the data in the worst case. ...not that it ever happens again... g. -----Original Message----- From: Chris Wedgwood [mailto:cw@f00f.org] Sent: Monday, August 28, 2006 9:17 PM To: gert wohlgemuth Cc: xfs@oss.sgi.com Subject: Re: accidently deleted files from directory On Mon, Aug 28, 2006 at 05:05:30PM -0700, gert wohlgemuth wrote: > On the weekend it happens that I accidentally deleted 1 TB of data > (rm -rdf /mnt/lcq). We have no backup of the data (internal reasons > of the university...) and it would be nice to get the data somehow > back. ouch > after I did a cat /dev/sda1 | less I could see that some data are still > exist and are not overwritten. So I think "all" what I have todo is some how > get the journal back. that won't suffice, the metadata showing where all the files are is likely gone > Is there anyway or is all hope lost? if you know what the data looks like heuristically scan for it and try to glue the fragments back together... From owner-xfs@oss.sgi.com Mon Aug 28 22:33:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 28 Aug 2006 22:33:39 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7T5WuDW004367 for ; Mon, 28 Aug 2006 22:33:24 -0700 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA06043; Tue, 29 Aug 2006 15:32:07 +1000 Message-ID: <44F3D0AD.5060706@sgi.com> Date: Tue, 29 Aug 2006 15:29:17 +1000 From: Timothy Shimmin User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060411) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gert wohlgemuth CC: xfs@oss.sgi.com Subject: Re: accidently deleted files from directory References: <44f384c5.270c085b.5896.ffff9b29@mx.gmail.com> In-Reply-To: <44f384c5.270c085b.5896.ffff9b29@mx.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8814 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 1583 Lines: 38 gert wohlgemuth wrote: > Hi and thx for your help, > > I'm running a gentoo box and using xfs as file system. > > On the weekend it happens that I accidentally deleted 1 TB of data (rm -rdf > /mnt/lcq). We have no backup of the data (internal reasons of the > university...) and it would be nice to get the data somehow back. > > After the delete the first step was to unmount the partion and this are the > info's from the xfs_check program. > > meta-data=/mnt/lcq isize=256 agcount=32, agsize=9154978 > blks > = sectsz=512 > data = bsize=4096 blocks=292959296, 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 > > after I did a cat /dev/sda1 | less I could see that some data are still > exist and are not overwritten. So I think "all" what I have todo is some how > get the journal back. > What journal would that be? If you are referring to the xfs journal or log, then that won't help you. It is just logging metadata. It is also only designed for replay for metadata which didn't make it to disk. > Is there anyway or is all hope lost? We don't support undelete as the FAQ says :) I suggest you go thru the mailing list archive and see if anyone has suggestions for scanning the device. Good luck :) --Tim From owner-xfs@oss.sgi.com Tue Aug 29 01:20:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 29 Aug 2006 01:20:24 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7T8K4DW006001 for ; Tue, 29 Aug 2006 01:20:04 -0700 Received: by py-out-1112.google.com with SMTP id x31so2535888pye for ; Tue, 29 Aug 2006 01:19:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:cc:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to:sender:message-id; b=HE+S5GGrxWTYK9EDxFjWGwXxmFeCNHplQOq5kfXmW0UJg2flkbiuz7EpJytb/B0rw/Tiq/RCIVwtgNRi2NLHn9RLQMrCsp57QhfSt21jdHF3tl0is/PzvoZkcf0LpJiQWMU69OMdG1rAdVW8X5gXGak2lTZIZzmFI9WiXX/6OwU= Received: by 10.35.8.1 with SMTP id l1mr14438635pyi; Tue, 29 Aug 2006 01:19:27 -0700 (PDT) Received: from atlas ( [128.120.136.206]) by mx.gmail.com with ESMTP id z80sm8189695pyg.2006.08.29.01.19.26; Tue, 29 Aug 2006 01:19:27 -0700 (PDT) From: "gert wohlgemuth" To: "=?iso-8859-2?Q?'Olaf_Fr=B1czyk'?=" , "'Timothy Shimmin'" Cc: Subject: RE: accidently deleted files from directory Date: Tue, 29 Aug 2006 01:19:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbLQa6lL8SL7qFOQtqgJAZGrtqNwQAAc4Og In-Reply-To: <1156838616.10176.13.camel@venus.local.navi.pl> Message-ID: <44f3f88f.067ad1b6.2efd.ffff8b76@mx.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k7T8K5DW006005 X-archive-position: 8816 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wohlgemuth@ucdavis.edu Precedence: bulk X-list: xfs Content-Length: 3136 Lines: 83 Yeah like always (it would be boring afterwards) 1. our file size is between 100k - 20 GB 2. we have tons of these files... 3. we have all kind of files from xls,xml,bz2 to special files from scientific machines. In short we gave up and considering it a loss and a lesson for the future. At least I get now the money for a backup server with some space... Thx for all your help! gert -----Original Message----- From: Olaf Fr±czyk [mailto:olaf@cbk.poznan.pl] Sent: Tuesday, August 29, 2006 1:04 AM To: Timothy Shimmin Cc: gert wohlgemuth; xfs@oss.sgi.com Subject: Re: accidently deleted files from directory On Tue, 2006-08-29 at 15:29 +1000, Timothy Shimmin wrote: > gert wohlgemuth wrote: > > Hi and thx for your help, > > > > I'm running a gentoo box and using xfs as file system. > > > > On the weekend it happens that I accidentally deleted 1 TB of data (rm -rdf > > /mnt/lcq). We have no backup of the data (internal reasons of the > > university...) and it would be nice to get the data somehow back. > > > > After the delete the first step was to unmount the partion and this are the > > info's from the xfs_check program. > > > > meta-data=/mnt/lcq isize=256 agcount=32, agsize=9154978 > > blks > > = sectsz=512 > > data = bsize=4096 blocks=292959296, 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 > > > > after I did a cat /dev/sda1 | less I could see that some data are still > > exist and are not overwritten. So I think "all" what I have todo is some how > > get the journal back. > > > What journal would that be? > If you are referring to the xfs journal or log, then that won't help you. > It is just logging metadata. > It is also only designed for replay for metadata which didn't make it to disk. > > > Is there anyway or is all hope lost? > We don't support undelete as the FAQ says :) > I suggest you go thru the mailing list archive and see if anyone has suggestions > for scanning the device. Good luck :) It won't be easy. All depends on what data did you have on that disk. I remember that some time ago a friend of mine has deleted a lot of jpegs from one partition. I was able to recover most of the data just reading the disk, looking for something that looked like the beginning of jpeg file and then copying till the end marker or < 6 MB. If you know what data were on the device and what to do find them out, the filesystem is not too fragmented and single files are not big then you should be able to relativelly easy recover the data. Just find somebody at your university that knows a little C programming and you should be fine. In other case - if the data are woth it - I would look for a company specialized in data recovery, but that will be pricey :( Regards, Olaf -- Olaf Fr±czyk From owner-xfs@oss.sgi.com Tue Aug 29 01:50:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 29 Aug 2006 01:50:32 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7T8oODW011425 for ; Tue, 29 Aug 2006 01:50:24 -0700 Received: from [194.173.12.131] (helo=[172.25.16.7]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GHyEf07Jt-0008Tp; Tue, 29 Aug 2006 09:42:14 +0200 Message-ID: <44F3F056.6040503@gmx.net> Date: Tue, 29 Aug 2006 09:44:22 +0200 From: Klaus Strebel User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: gert wohlgemuth CC: xfs@oss.sgi.com Subject: Re: accidently deleted files from directory References: <44f3c278.059fc255.3075.3597@mx.gmail.com> In-Reply-To: <44f3c278.059fc255.3075.3597@mx.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:8a7df7300d3d15a4f701302fdde7adf9 X-archive-position: 8817 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@gmx.net Precedence: bulk X-list: xfs Content-Length: 1415 Lines: 41 gert wohlgemuth schrieb: > Thx, > > I thought so that the data are gone and it's to much to glue it, cause all > binary data. > > So time to step back to ext2, here at least I can restore the data in the > worst case. Just out of curiosity, could you write an info to the list, how long your 'some-terrabyte-ext2'-filesystem needs to mount and - every 20th-or -so mount, how long a fsck is running on when if it's well filled ;-). I once tried to restore deleted files on a webserver using ext2, i can tell you, thats no fun. Many programs make copies of the files they are working on, write there changes, delete the old file and rename the new. So expect to get lots and lots of versions of files where you have to decide which is the latest you want to use, and sometimes, its not the latest by accesstime ... > > ...not that it ever happens again... >> after I did a cat /dev/sda1 | less I could see that some data are still >> exist and are not overwritten. So I think "all" what I have todo is some > how >> get the journal back. > > that won't suffice, the metadata showing where all the files are is > likely gone > Well, getting a consistent state ( in this case all metadata removed ) is why we use filesystems like XFS. -- Mit freundlichen Grüssen / best regards Klaus Strebel, Dipl.-Inform. (FH), mailto:klaus.strebel@gmx.net /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \ From owner-xfs@oss.sgi.com Tue Aug 29 03:06:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 29 Aug 2006 03:06:30 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [193.151.36.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7TA6DDW025384 for ; Tue, 29 Aug 2006 03:06:14 -0700 Received: from localhost (localhost [127.0.0.1]) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id B131818D073; Tue, 29 Aug 2006 10:03:48 +0200 (CEST) Received: from goliath.sylaba.poznan.pl ([127.0.0.1]) by localhost (goliath.sylaba.poznan.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7kSohbtEuMQZ; Tue, 29 Aug 2006 10:03:48 +0200 (CEST) Received: from venus.local.navi.pl (ip-83-238-212-180.netia.com.pl [83.238.212.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id 0BC9B18D04F; Tue, 29 Aug 2006 10:03:37 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.13.1/8.13.1) with ESMTP id k7T83aRW010843; Tue, 29 Aug 2006 10:03:36 +0200 Subject: Re: accidently deleted files from directory From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Timothy Shimmin Cc: gert wohlgemuth , xfs@oss.sgi.com In-Reply-To: <44F3D0AD.5060706@sgi.com> References: <44f384c5.270c085b.5896.ffff9b29@mx.gmail.com> <44F3D0AD.5060706@sgi.com> Content-Type: text/plain; charset=UTF-8 Date: Tue, 29 Aug 2006 10:03:36 +0200 Message-Id: <1156838616.10176.13.camel@venus.local.navi.pl> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 8bit X-archive-position: 8818 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: xfs Content-Length: 2520 Lines: 54 On Tue, 2006-08-29 at 15:29 +1000, Timothy Shimmin wrote: > gert wohlgemuth wrote: > > Hi and thx for your help, > > > > I'm running a gentoo box and using xfs as file system. > > > > On the weekend it happens that I accidentally deleted 1 TB of data (rm -rdf > > /mnt/lcq). We have no backup of the data (internal reasons of the > > university...) and it would be nice to get the data somehow back. > > > > After the delete the first step was to unmount the partion and this are the > > info's from the xfs_check program. > > > > meta-data=/mnt/lcq isize=256 agcount=32, agsize=9154978 > > blks > > = sectsz=512 > > data = bsize=4096 blocks=292959296, 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 > > > > after I did a cat /dev/sda1 | less I could see that some data are still > > exist and are not overwritten. So I think "all" what I have todo is some how > > get the journal back. > > > What journal would that be? > If you are referring to the xfs journal or log, then that won't help you. > It is just logging metadata. > It is also only designed for replay for metadata which didn't make it to disk. > > > Is there anyway or is all hope lost? > We don't support undelete as the FAQ says :) > I suggest you go thru the mailing list archive and see if anyone has suggestions > for scanning the device. Good luck :) It won't be easy. All depends on what data did you have on that disk. I remember that some time ago a friend of mine has deleted a lot of jpegs from one partition. I was able to recover most of the data just reading the disk, looking for something that looked like the beginning of jpeg file and then copying till the end marker or < 6 MB. If you know what data were on the device and what to do find them out, the filesystem is not too fragmented and single files are not big then you should be able to relativelly easy recover the data. Just find somebody at your university that knows a little C programming and you should be fine. In other case - if the data are woth it - I would look for a company specialized in data recovery, but that will be pricey :( Regards, Olaf -- Olaf FrÄ…czyk From owner-xfs@oss.sgi.com Tue Aug 29 06:27:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 29 Aug 2006 06:27:45 -0700 (PDT) Received: from mail.max-t.com (h216-18-124-229.gtcust.grouptelecom.net [216.18.124.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7TDRLDW003720 for ; Tue, 29 Aug 2006 06:27:22 -0700 Received: from madrid.max-t.internal ([192.168.1.189] ident=[U2FsdGVkX19wVwTC1/RqPnnDW03Nu76fHx5hGXSKmos=]) by mail.max-t.com with esmtp (Exim 4.43) id 1GI3bz-0006L2-4c; Tue, 29 Aug 2006 09:26:39 -0400 Date: Tue, 29 Aug 2006 09:25:47 -0400 (EDT) From: Stephane Doyon X-X-Sender: sdoyon@madrid.max-t.internal To: David Chinner , Luciano Chavez cc: linux-xfs@oss.sgi.com In-Reply-To: <1156794030.5848.3.camel@localhost> Message-ID: References: <20060823040218.GC807872@melbourne.sgi.com> <20060823044829.GD807872@melbourne.sgi.com> <1156360259.5368.7.camel@localhost> <20060823040218.GC807872@melbourne.sgi.com> <20060823044829.GD807872@melbourne.sgi.com> <20060823231429.GF807872@melbourne.sgi.com> <20060828072343.GJ807872@melbourne.sgi.com> <1156794030.5848.3.camel@localhost> MIME-Version: 1.0 X-SA-Exim-Connect-IP: 192.168.1.189 X-SA-Exim-Mail-From: sdoyon@max-t.com Subject: Re: Infinite loop in xfssyncd on full file system Content-Type: MULTIPART/MIXED; BOUNDARY="-1463763711-925634831-1156857947=:5262" X-SA-Exim-Version: 4.1 (built Thu, 08 Sep 2005 14:17:48 -0500) X-SA-Exim-Scanned: Yes (on mail.max-t.com) X-archive-position: 8821 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sdoyon@max-t.com Precedence: bulk X-list: xfs Content-Length: 3546 Lines: 92 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463763711-925634831-1156857947=:5262 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 28 Aug 2006, Luciano Chavez wrote: > On Mon, 2006-08-28 at 17:23 +1000, David Chinner wrote: >> On Thu, Aug 24, 2006 at 09:14:29AM +1000, David Chinner wrote: >>> On Wed, Aug 23, 2006 at 11:00:43AM -0400, Stephane Doyon wrote: >>>> On Wed, 23 Aug 2006, David Chinner wrote: >>>> >>>>> On Wed, Aug 23, 2006 at 02:02:18PM +1000, David Chinner wrote: >>>>>> On Tue, Aug 22, 2006 at 04:01:10PM -0400, Stephane Doyon wrote: >>>>>>> I'm seeing what appears to be an infinite loop in xfssyncd. It is >>>>>>> triggered when writing to a file system that is full or nearly full= . I >>>>>>> have pinpointed the change that introduced this problem: it's >>>>>>> >>>>>>> "TAKE 947395 - Fixing potential deadlock in space allocation and >>>>>>> freeing due to ENOSPC" >>>>>>> >>>>>>> git commit d210a28cd851082cec9b282443f8cc0e6fc09830. >>> >>> ..... >>> >>>>>> Now we know what patch introduces the problem, we know where to look. >>>>>> Stay tuned... >>>>> >>>>> I've had a quick look at the above commit. I'm not yet certain that >>>>> everything is correct in terms of the semantics laid down in the >>>>> change or that enough blocks are reserved for btree splits , but I >>>> >>>> I actually tried, naively, to bump up SET_ASIDE_BLOCKS from 8 to 32. I >>>> won't claim to understand half of what's going on but I wondered wheth= er >>>> that might make the problem noticeably harder to reproduce at least, b= ut >>>> it had no effect ;-). >>> >>> That was going to be my next question. ;) >>> >>> At least that rules out a small error in the block reservation decision, >>> so I'm going to have analyse all the code paths the mod introduced >>> and work out what is going wrong. >> >> You know, if you had of buumped it up just a bit higher, the problem mig= ht >> have gone away. With a fielsystem that only has 8 AGs in it, if you bump= ed >> it to 33, then problem would have disappeared.... >> >> What we have here is a small error in the block reservation code. Basica= lly, >> all the logic is correct except for one critical detail - while we need = to >> reserve 4 blocks for the AG freelist so a minimum allocation can succeed, >> we need to reserve 4 blocks in _every AG_ so that when every AG is empty >> we will fail with ENOSPC instead of trying to allocate a block when we >> have an AG with less thaan 4 free blocks in it. >> >> So, it's not 4 blocks filesystem wide we need to reserve, it's 4 blocks = per AG >> we need to reserve. >> >> Stephane and Luciano, can you try the patch att=C3=A6ched below - it fix= es the >> 100% repeatable test case (while [ 1 ]; dd to enospc; done) on my test >> machine. >> > > Dave, > > The latest patch seems to work for me running bonnie++ on a small 2GB > XFS filesystem. bonnie++ gets an ENOSPC on a write() and ends plus I > don't see the softwatchdog timer dump the kernel stack or xfssyncd > looping. Thanks! Works here too. Tried on three different file system configurations (sizes= =20 and numbers of AGs). I ran only simple tests though, but at least it fixes= =20 the obvious test case. Ideally I'd like to run some stress test involving= =20 NFS service, but I won't be able to make time for that in the very near=20 future. Thanks! ---1463763711-925634831-1156857947=:5262-- From owner-xfs@oss.sgi.com Tue Aug 29 16:09:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 29 Aug 2006 16:09:25 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7TN8sDW010310 for ; Tue, 29 Aug 2006 16:09:06 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00194; Wed, 30 Aug 2006 09:08:05 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 864C458CF7C2; Wed, 30 Aug 2006 09:08:05 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 947312 - fix bma.conv assignment Message-Id: <20060829230805.864C458CF7C2@chook.melbourne.sgi.com> Date: Wed, 30 Aug 2006 09:08:05 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8825 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 825 Lines: 23 Fix char size overflow in bmap_alloc call for unwritten extent conversion. Since bma.conv is a char and XFS_BMAPI_CONVERT is 0x1000, bma.conv was always assigned zero. Spotted by the GNU C compiler (SVN version). Signed-off-by: Adrian Bunk Date: Wed Aug 30 09:06:53 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: Adrian Bunk The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26887a xfs_bmap.c - 1.358 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.358&r2=text&tr2=1.357&f=h - Since bma.conv is a char and XFS_BMAPI_CONVERT is 0x1000, bma.conv was always assigned zero. Spotted by the GNU C compiler (SVN version). From owner-xfs@oss.sgi.com Tue Aug 29 21:15:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 29 Aug 2006 21:16:15 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7U4FJDW020766 for ; Tue, 29 Aug 2006 21:15:32 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA06696; Wed, 30 Aug 2006 14:14:18 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7U4EAgw3180391; Wed, 30 Aug 2006 14:14:11 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7U4E4IN3182810; Wed, 30 Aug 2006 14:14:04 +1000 (EST) Date: Wed, 30 Aug 2006 14:14:04 +1000 From: Nathan Scott To: Linus Torvalds , Andrew Morton , xfs@oss.sgi.com Cc: Christoph Hellwig , Andreas Gruenbacher , Jan Kara , Greg KH Subject: Change of XFS maintainers Message-ID: <20060830141404.A3180820@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8827 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1096 Lines: 25 Hi Linus, Andrew, all, I've decided to move on from SGI, and go try my hand at something new. I'll be here for two more weeks, then away from email for at least two more (nathans@debian.org should always reach me, however). I am in the process of handing off my XFS responsibilities to other guys here; Tim Shimmin (tes@sgi.com) and David Chatterton (chatz@sgi.com) will be taking over merges with the mainline kernel, with the usual excellent help from David Chinner (dgc@sgi.com) and the rest of the XFS team. My new job is only peripherally related to filesystems and kernel hacking, but I would expect to still be occassionally hacking on Linux related odds and ends. Well, I hope so anyway, its been great fun! XFS is far from a "complete work", of course ... I know there are many interesting performance/scaling improvements, and several new features in progress, as well as the usual set of bug fixes being worked on. I am now very much looking forward to watching from outside SGI as these pieces are slotted into place, and I wish the XFS team all the best! cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Aug 29 21:24:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 29 Aug 2006 21:24:46 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7U4OHDW022402 for ; Tue, 29 Aug 2006 21:24:29 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA06950; Wed, 30 Aug 2006 14:23:30 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7U4NRgw3177959; Wed, 30 Aug 2006 14:23:28 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7U4NPZ83177857; Wed, 30 Aug 2006 14:23:25 +1000 (EST) Date: Wed, 30 Aug 2006 14:23:25 +1000 From: Nathan Scott To: Linus Torvalds Cc: Andrew Morton , xfs@oss.sgi.com Subject: XFS update for 2.6.18-rc5 Message-ID: <20060830142325.A3184982@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 8828 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1032 Lines: 42 Hi Linus, Please pull from: git://oss.sgi.com:8090/xfs/xfs-2.6.git This will update the following files: MAINTAINERS | 3 ++- fs/xfs/xfs_bmap.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) through these commits: commit 1ad8f401b6e16e3ba8a70dcda466e7a0986f7e5e Author: Nathan Scott Date: Wed Aug 30 13:41:23 2006 +1000 [XFS] Update the MAINTAINERS file entry for XFS. Signed-off-by: Nathan Scott commit 7288026b8671061aff7663b1766037b3f2573627 Author: Adrian Bunk Date: Wed Aug 30 13:41:58 2006 +1000 [XFS] Fix char size overflow in bmap_alloc call for unwritten extent conversion. Since bma.conv is a char and XFS_BMAPI_CONVERT is 0x1000, bma.conv was always assigned zero. Spotted by the GNU C compiler (SVN version). SGI-PV: 947312 SGI-Modid: xfs-linux-melb:xfs-kern:26887a Signed-off-by: Adrian Bunk Signed-off-by: Nathan Scott -- Nathan From owner-xfs@oss.sgi.com Wed Aug 30 03:29:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 30 Aug 2006 03:29:36 -0700 (PDT) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7UATODW015833 for ; Wed, 30 Aug 2006 03:29:27 -0700 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id EDD0A895D84 for ; Wed, 30 Aug 2006 10:24:05 +0200 (CEST) Received: from albatross.madduck.net ([127.0.0.1]) by localhost (albatross.madduck.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11859-02-10 for ; Wed, 30 Aug 2006 10:24:05 +0200 (CEST) Received: from lapse.madduck.net (84-72-16-26.dclient.hispeed.ch [84.72.16.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lapse.madduck.net", Issuer "CAcert Class 3 Root" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id A11AA895D7A for ; Wed, 30 Aug 2006 10:24:05 +0200 (CEST) Received: by lapse.madduck.net (Postfix, from userid 1000) id CE0532A8FA; Wed, 30 Aug 2006 09:24:11 +0100 (IST) Date: Wed, 30 Aug 2006 09:24:11 +0100 From: martin f krafft To: xfs mailing list Subject: catch22: xfs_repair fails, tells me to mount, which fails Message-ID: <20060830082411.GA9986@lapse.madduck.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline X-OS: Debian GNU/Linux testing/unstable kernel 2.6.17-2-686 i686 X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 8829 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: xfs Content-Length: 3959 Lines: 106 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, this morning I woke up to a system without /home, the reason being: piper:~# mount /dev/mapper/vg0-home = [308] mount: Unknown error 990 piper:~# dmesg | tail -20 [3= 2,309] Starting XFS recovery on filesystem: dm-0 (logdev: internal) Filesystem "dm-0": xfs_inode_recover: Bad inode magic number, dino ptr = =3D 0xffff810028a6bd00, dino bp =3D 0xffff81002851d140, ino =3D 33629 Filesystem "dm-0": XFS internal error xlog_recover_do_inode_trans(1) at l= ine 2352 of file fs/xfs/xfs_log_recover.c. Caller 0xffffffff88307729 Call Trace: {:xfs:xlog_recover_commit_trans+4198} {submit_bio+184} {:xfs:xlog_rec= over_process_data+466} {:xfs:xlog_do_recovery_pass+585} {:xfs:xlog_recover+243} {:xfs:xfs_log_mount+1310} {:xfs= :xfs_mountfs+2116} {:libata:ata_exec_command+0} {_= atomic_dec_and_lock+57} {:xfs:xfs_mount+1900} {:xfs:xfs= _fs_fill_super+126} {get_filesystem+18} {sget+850} {set_bdev_super+0} {test_bdev_s= uper+0} {bd_claim+24} {get_sb_bdev+239} {:xfs:xfs_fs_fill_super+0} {do_= kern_mount+157} {do_mount+1676} {mntput_no_expi= re+25} {find_get_page+33} {filemap_nop= age+387} {__handle_mm_fault+1276} {do_pa= ge_fault+1151} {sys_mount+138} {system_call+12= 6} XFS: log mount/recovery failed: error 990 XFS: log mount failed When I try to run xfs_repair, I get: piper:~# xfs_repair /dev/mapper/vg0-home = [310] Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs = to be replayed. Mount the filesystem to replay the log, and unmount it befo= re re-running xfs_repair. If you are unable to mount the filesystem, then u= se the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mou= nt of the filesystem before doing this. I have already tried the xfs_db method of the "dir2" faq entry, trying to delete that offending inode, but setting core.mode =3D 0 for that inode did not do anything. I do not have enough space around to xfsdump those 250Gb, nor would I know how, given that I cannot mount the filesystem and xfsdump works on mounted filesystems only. I've had really bad experiences with XFS lately [0], but I am not giving up just yet. This time around, I guess I can wait a bit and try to get things fixed. 0. http://blog.madduck.net/geek/2006.08.09-through-with-xfs Would you have any idea what I should do? --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 spamtraps: madduck.bogus@madduck.net =20 "... (ethik und =E4sthetik sind eins.)" -- wittgenstein --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature (GPG/PGP) Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE9UsrIgvIgzMMSnURAoHeAJ9i9+W6L6nSpfjbOJZ13DYOp5Mr2gCgu9ue 0jKJ+Gdmu23TpA78OamrkdQ= =agwG -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-xfs@oss.sgi.com Wed Aug 30 04:41:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 30 Aug 2006 04:41:55 -0700 (PDT) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7UBfiDW000676 for ; Wed, 30 Aug 2006 04:41:47 -0700 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id 7F642895D84 for ; Wed, 30 Aug 2006 13:41:03 +0200 (CEST) Received: from albatross.madduck.net ([127.0.0.1]) by localhost (albatross.madduck.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24347-01-7 for ; Wed, 30 Aug 2006 13:41:03 +0200 (CEST) Received: from lapse.madduck.net (84-72-16-26.dclient.hispeed.ch [84.72.16.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lapse.madduck.net", Issuer "CAcert Class 3 Root" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id 523AE895D82 for ; Wed, 30 Aug 2006 13:41:03 +0200 (CEST) Received: by lapse.madduck.net (Postfix, from userid 1000) id 5097D2ABA9; Wed, 30 Aug 2006 12:41:09 +0100 (IST) Date: Wed, 30 Aug 2006 13:41:09 +0200 From: martin f krafft To: xfs mailing list Subject: Re: catch22: xfs_repair fails, tells me to mount, which fails Message-ID: <20060830114109.GA22450@lapse.madduck.net> References: <20060830082411.GA9986@lapse.madduck.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <20060830082411.GA9986@lapse.madduck.net> X-OS: Debian GNU/Linux testing/unstable kernel 2.6.17-2-686 i686 X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 8830 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: xfs Content-Length: 1129 Lines: 39 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FYI, here is how I fixed it, using LVM snapshots to ensure that xfs_repair -L would produce acceptable results: http://blog.madduck.net/geek/2006.08.30-lvm-for-filesystem-recovery I'd still be interested to know how I could have gone about fixing it in case I could not have afforded to purge the journal. --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 spamtraps: madduck.bogus@madduck.net =20 the reason that every major university maintains a department of mathematics is that it's cheaper than institutionalizing all those people. --17pEHd4RhPHOinZp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature (GPG/PGP) Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE9XlVIgvIgzMMSnURAlcJAKCXHREzx25C2GVUJgpHE2VOb1AB8QCeL30g ViVUAGCa6pMJYLWq1dZynV4= =ViPg -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-xfs@oss.sgi.com Wed Aug 30 06:52:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 30 Aug 2006 06:52:36 -0700 (PDT) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7UDqMDW021376 for ; Wed, 30 Aug 2006 06:52:26 -0700 Received: from agami.com ([192.168.168.133]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id k7UDpluu019345 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 30 Aug 2006 06:51:48 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id k7UDpgPm012894 for ; Wed, 30 Aug 2006 06:51:42 -0700 Received: from [10.12.12.141] ([10.12.12.141]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Aug 2006 06:54:23 -0700 Message-ID: <44F597F9.6020803@agami.com> Date: Wed, 30 Aug 2006 19:21:53 +0530 From: Shailendra Tripathi User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: martin f krafft CC: xfs mailing list Subject: Re: catch22: xfs_repair fails, tells me to mount, which fails References: <20060830082411.GA9986@lapse.madduck.net> In-Reply-To: <20060830082411.GA9986@lapse.madduck.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2006 13:54:23.0296 (UTC) FILETIME=[CC83BC00:01C6CC3B] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 8831 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stripathi@agami.com Precedence: bulk X-list: xfs Content-Length: 4153 Lines: 83 Hi Martin, In this particular case, the log written is corrupted. That's why, forcing to make the inode going corrupt would not help. The real issue is why log content is not valid. By any chance, did you saw any disk I/O error ? If there is no disk I/O error scenario, following information would be more useful. 1. /usr/sbin/xfs_logprint -s 0 -D 2. /usr/sbin/xfs_logprint -d You can try mounting with -L option but the risk is: " ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. " martin f krafft wrote: > Hi, > > this morning I woke up to a system without /home, the reason being: > > piper:~# mount /dev/mapper/vg0-home [308] > mount: Unknown error 990 > piper:~# dmesg | tail -20 [32,309] > Starting XFS recovery on filesystem: dm-0 (logdev: internal) > Filesystem "dm-0": xfs_inode_recover: Bad inode magic number, dino ptr = 0xffff810028a6bd00, dino bp = 0xffff81002851d140, ino = 33629 > Filesystem "dm-0": XFS internal error xlog_recover_do_inode_trans(1) at line 2352 of file fs/xfs/xfs_log_recover.c. Caller 0xffffffff88307729 > > Call Trace: {:xfs:xlog_recover_commit_trans+4198} > {submit_bio+184} {:xfs:xlog_recover_process_data+466} > {:xfs:xlog_do_recovery_pass+585} {:xfs:xlog_recover+243} > {:xfs:xfs_log_mount+1310} {:xfs:xfs_mountfs+2116} > {:libata:ata_exec_command+0} {_atomic_dec_and_lock+57} > {:xfs:xfs_mount+1900} {:xfs:xfs_fs_fill_super+126} > {get_filesystem+18} {sget+850} > {set_bdev_super+0} {test_bdev_super+0} > {bd_claim+24} {get_sb_bdev+239} > {:xfs:xfs_fs_fill_super+0} {do_kern_mount+157} > {do_mount+1676} {mntput_no_expire+25} > {find_get_page+33} {filemap_nopage+387} > {__handle_mm_fault+1276} {do_page_fault+1151} > {sys_mount+138} {system_call+126} > XFS: log mount/recovery failed: error 990 > XFS: log mount failed > > When I try to run xfs_repair, I get: > > piper:~# xfs_repair /dev/mapper/vg0-home [310] > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > ERROR: The filesystem has valuable metadata changes in a log which needs to > be replayed. Mount the filesystem to replay the log, and unmount it before > re-running xfs_repair. If you are unable to mount the filesystem, then use > the -L option to destroy the log and attempt a repair. > Note that destroying the log may cause corruption -- please attempt a mount > of the filesystem before doing this. > > I have already tried the xfs_db method of the "dir2" faq entry, > trying to delete that offending inode, but setting core.mode = 0 for > that inode did not do anything. > > I do not have enough space around to xfsdump those 250Gb, nor would > I know how, given that I cannot mount the filesystem and xfsdump > works on mounted filesystems only. > > I've had really bad experiences with XFS lately [0], but I am not > giving up just yet. This time around, I guess I can wait a bit and > try to get things fixed. > > 0. http://blog.madduck.net/geek/2006.08.09-through-with-xfs > > Would you have any idea what I should do? > From owner-xfs@oss.sgi.com Wed Aug 30 09:19:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 30 Aug 2006 09:19:47 -0700 (PDT) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7UGJPDW016697 for ; Wed, 30 Aug 2006 09:19:32 -0700 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id 85433895D7C for ; Wed, 30 Aug 2006 16:15:45 +0200 (CEST) Received: from albatross.madduck.net ([127.0.0.1]) by localhost (albatross.madduck.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31864-01-7 for ; Wed, 30 Aug 2006 16:15:45 +0200 (CEST) Received: from wall.oerlikon.madduck.net (84-72-16-26.dclient.hispeed.ch [84.72.16.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "wall.oerlikon.madduck.net", Issuer "CAcert Class 3 Root" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id 4902D895D7A for ; Wed, 30 Aug 2006 16:15:45 +0200 (CEST) Received: from piper.oerlikon.madduck.net (piper.oerlikon.madduck.net [192.168.14.3]) by wall.oerlikon.madduck.net (Postfix) with ESMTP id 2F58E18044B8 for ; Wed, 30 Aug 2006 16:15:49 +0200 (CEST) Received: by piper.oerlikon.madduck.net (Postfix, from userid 1000) id 2FAB91240E02; Wed, 30 Aug 2006 16:15:48 +0200 (CEST) Date: Wed, 30 Aug 2006 16:15:48 +0200 From: martin f krafft To: xfs mailing list Subject: Re: catch22: xfs_repair fails, tells me to mount, which fails Message-ID: <20060830141548.GA21325@piper.madduck.net> References: <20060830082411.GA9986@lapse.madduck.net> <44F597F9.6020803@agami.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <44F597F9.6020803@agami.com> X-OS: Debian GNU/Linux testing/unstable kernel 2.6.17-2-amd64 x86_64 X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 8833 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: xfs Content-Length: 1524 Lines: 51 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable also sprach Shailendra Tripathi [2006.08.30.1551 +020= 0]: > By any chance, did you saw any disk I/O error ? No, definitely not. > If there is no disk I/O error scenario, following information > would be more useful. >=20 > 1. /usr/sbin/xfs_logprint -s 0 -D > 2. /usr/sbin/xfs_logprint -d Thanks for the info. I managed to restore the filesystem with xfs_repair -L in the mean time (see followup post), but this is what I'll keep in mind for the next time. Btw: there's the xfs and linux-xfs mailing list, and I am confused about whether they're separate or merged, and which one I should be using. If you have any input, I'd love to hear it. --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 spamtraps: madduck.bogus@madduck.net =20 no micro$oft components were used in the creation or posting of this email. therefore, it is 100% virus free and does not use html by default (yuck!). --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature (GPG/PGP) Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE9Z2UIgvIgzMMSnURAgW9AJ9Fc+exuzdYd5IDlb85qLVQPb0zoQCfQe9r u+BB7YT8QsxzPXlRHYCL5k0= =X5g3 -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-xfs@oss.sgi.com Wed Aug 30 12:16:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 30 Aug 2006 12:16:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7UJGVDW021789 for ; Wed, 30 Aug 2006 12:16:34 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7UJFf9K021461; Wed, 30 Aug 2006 15:15:41 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7UJFfTB005416; Wed, 30 Aug 2006 15:15:41 -0400 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k7UJFd1O012401; Wed, 30 Aug 2006 15:15:40 -0400 Message-ID: <44F5E3DB.70802@sandeen.net> Date: Wed, 30 Aug 2006 14:15:39 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (X11/20060808) MIME-Version: 1.0 To: martin f krafft CC: xfs mailing list Subject: Re: catch22: xfs_repair fails, tells me to mount, which fails References: <20060830082411.GA9986@lapse.madduck.net> <44F597F9.6020803@agami.com> <20060830141548.GA21325@piper.madduck.net> In-Reply-To: <20060830141548.GA21325@piper.madduck.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8834 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 363 Lines: 11 martin f krafft wrote: > Btw: there's the xfs and linux-xfs mailing list, and I am confused > about whether they're separate or merged, and which one I should be > using. If you have any input, I'd love to hear it. xfs@ is the current one, linux-xfs@ is the old one, and is aliased to xfs@ (there was probably a post about this when xfs@ was created). -Eric From owner-xfs@oss.sgi.com Wed Aug 30 20:22:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 30 Aug 2006 20:22:47 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7V3MIDW010218 for ; Wed, 30 Aug 2006 20:22:30 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA09970; Thu, 31 Aug 2006 13:21:16 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7V3LDgw3212212; Thu, 31 Aug 2006 13:21:13 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7V3L7A03214537; Thu, 31 Aug 2006 13:21:07 +1000 (EST) Date: Thu, 31 Aug 2006 13:21:07 +1000 From: Nathan Scott To: David Chinner Cc: xfs-dev@sgi.com, xfs@oss.sgi.com, Stephane Doyon , Luciano Chavez Subject: Re: Review: Prevent free space oversubscription Message-ID: <20060831132107.I3208450@wobbly.melbourne.sgi.com> References: <20060830021532.GF5737019@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060830021532.GF5737019@melbourne.sgi.com>; from dgc@sgi.com on Wed, Aug 30, 2006 at 12:15:32PM +1000 X-archive-position: 8838 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 464 Lines: 15 On Wed, Aug 30, 2006 at 12:15:32PM +1000, David Chinner wrote: > ... > The following patch reserves space for the free lists in all AGs > plus the inode bmap btree which prevents oversubscription. It also > prevents those blocks from being reported as free space (as they can > never be used) and makes the SMP in-core superblock accounting code and > the reserved block ioctl respect this requirement. Makes sense to me & patch looks good. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Aug 30 20:06:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 30 Aug 2006 20:06:35 -0700 (PDT) Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7V35uDW001535 for ; Wed, 30 Aug 2006 20:06:19 -0700 Received: from tyo201.gate.nec.co.jp ([10.7.69.201]) by tyo200.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k7V2r1lW020001 for ; Thu, 31 Aug 2006 11:53:03 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.197]) by tyo201.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k7V2iNXA026022; Thu, 31 Aug 2006 11:44:23 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id k7V2iNY16770; Thu, 31 Aug 2006 11:44:23 +0900 (JST) Received: from anesfw.anes.nec.co.jp (fuji.anes.nec.co.jp [10.2.168.3]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id k7V2iMQ22410; Thu, 31 Aug 2006 11:44:22 +0900 (JST) Received: from tnesg9212 (tnesg9212) by anesfw.anes.nec.co.jp (8.13.5/8.13.5) with SMTP id k7V2iLhF022662; Thu, 31 Aug 2006 11:44:21 +0900 To: Nathan Scott Cc: David Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] Fix i_state of inode is changed after the inode is freed [try #2] In-reply-to: <20060824171653.C3003989@wobbly.melbourne.sgi.com> Message-Id: <20060831114423m-saito@mail.aom.tnes.nec.co.jp> References: <20060824171653.C3003989@wobbly.melbourne.sgi.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Masayuki Saito Date: Thu, 31 Aug 2006 11:44:23 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8836 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: m-saito@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 1317 Lines: 50 Hi, Nathan >Fix i_state of the inode is changed after the inode is freed. > >Signed-off-by: Masayuki Saito >Signed-off-by: ASANO Masahiro >--- > >Index: xfs-linux/xfs_inode.c >=================================================================== >--- xfs-linux.orig/xfs_inode.c 2006-08-24 17:02:36.896740000 +1000 >+++ xfs-linux/xfs_inode.c 2006-08-24 17:09:29.430521750 +1000 >@@ -2761,19 +2761,29 @@ xfs_iunpin( > * call as the inode reclaim may be blocked waiting for > * the inode to become unpinned. > */ >+ struct inode *inode = NULL; >+ >+ spin_lock(&ip->i_flags_lock); > if (!(ip->i_flags & (XFS_IRECLAIM|XFS_IRECLAIMABLE))) { > bhv_vnode_t *vp = XFS_ITOV_NULL(ip); > > /* make sync come back and flush this inode */ > if (vp) { >- struct inode *inode = vn_to_inode(vp); >+ inode = vn_to_inode(vp); > > if (!(inode->i_state & >- (I_NEW|I_FREEING|I_CLEAR))) >- mark_inode_dirty_sync(inode); >+ (I_NEW|I_FREEING|I_CLEAR))) { >+ inode = igrab(inode); >+ if (inode) >+ mark_inode_dirty_sync(inode); >+ } else >+ inode = NULL; > } > } >+ spin_unlock(&ip->i_flags_lock); > wake_up(&ip->i_ipin_wait); >+ if (inode) >+ iput(inode); > } > } Are the patches going to be merged? Masayuki From owner-xfs@oss.sgi.com Wed Aug 30 20:20:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 30 Aug 2006 20:20:39 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7V3KADW009025 for ; Wed, 30 Aug 2006 20:20:22 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA09922; Thu, 31 Aug 2006 13:19:10 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7V3J7gw3215101; Thu, 31 Aug 2006 13:19:08 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7V3J27V3212423; Thu, 31 Aug 2006 13:19:02 +1000 (EST) Date: Thu, 31 Aug 2006 13:19:02 +1000 From: Nathan Scott To: Masayuki Saito Cc: David Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] Fix i_state of inode is changed after the inode is freed [try #2] Message-ID: <20060831131902.H3208450@wobbly.melbourne.sgi.com> References: <20060824171653.C3003989@wobbly.melbourne.sgi.com> <20060831114423m-saito@mail.aom.tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060831114423m-saito@mail.aom.tnes.nec.co.jp>; from m-saito@tnes.nec.co.jp on Thu, Aug 31, 2006 at 11:44:23AM +0900 X-archive-position: 8837 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 446 Lines: 16 On Thu, Aug 31, 2006 at 11:44:23AM +0900, Masayuki Saito wrote: > Hi, Nathan > > Are the patches going to be merged? Yep, they're queued up for 2.6.19. Since it was a race found only on testing with a ramdisk (iirc) it didn't really seem to me like they needed to be rushed through for a 2.6.18-rc. The race has also been there for the entire lifetime of the Linux XFS port... so, not urgent (and not risk free either). cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Aug 30 21:59:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 30 Aug 2006 21:59:50 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7V4xIDW024860 for ; Wed, 30 Aug 2006 21:59:32 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA11771; Thu, 31 Aug 2006 14:58:30 +1000 Message-ID: <44F66CA0.4080008@sgi.com> Date: Thu, 31 Aug 2006 14:59:12 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 955006: DMAPI set/get/remove attribute returns EINVAL instead of EFAULT:bad &dm_attrname References: <44CE9F23.7000605@sgi.com> <44EE9DF7.1080904@sgi.com> In-Reply-To: <44EE9DF7.1080904@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8839 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 590 Lines: 17 Date: Thu Aug 31 14:55:04 AEST 2006 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs-dmapi Inspected by: bnaujok Author: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:26892a fs/xfs/dmapi/xfs_dm.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h - pv 955006, rv bnaujok - Better (and proper) way to fix the problem. strnlen_user returns strlen+1 not strlen as documented in the ia64 code. From owner-xfs@oss.sgi.com Wed Aug 30 22:07:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 30 Aug 2006 22:07:21 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7V574DW026402 for ; Wed, 30 Aug 2006 22:07:05 -0700 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.162] (may be forged)) by tyo202.gate.nec.co.jp (8.13.7/8.13.4) with ESMTP id k7V56V85020432; Thu, 31 Aug 2006 14:06:31 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id k7V56VQ09944; Thu, 31 Aug 2006 14:06:31 +0900 (JST) Received: from anesfw.anes.nec.co.jp (fuji.anes.nec.co.jp [10.2.168.3]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id k7V56UQ23340; Thu, 31 Aug 2006 14:06:30 +0900 (JST) Received: from tnesg9212 (tnesg9212) by anesfw.anes.nec.co.jp (8.13.5/8.13.5) with SMTP id k7V56UU6028722; Thu, 31 Aug 2006 14:06:30 +0900 To: Nathan Scott Cc: David Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] Fix i_state of inode is changed after the inode is freed [try #2] In-reply-to: <20060831131902.H3208450@wobbly.melbourne.sgi.com> Message-Id: <20060831140643m-saito@mail.aom.tnes.nec.co.jp> References: <20060831131902.H3208450@wobbly.melbourne.sgi.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Masayuki Saito Date: Thu, 31 Aug 2006 14:06:43 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 8840 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: m-saito@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 504 Lines: 16 >> Are the patches going to be merged? > >Yep, they're queued up for 2.6.19. Since it was a race found >only on testing with a ramdisk (iirc) it didn't really seem to >me like they needed to be rushed through for a 2.6.18-rc. The >race has also been there for the entire lifetime of the Linux >XFS port... so, not urgent (and not risk free either). Thanks, I agree it. I'm looking forward to receiving the TAKE. So far thank you, Nathan. I wish to be glorious in your future. cheers. -- Masayuki From owner-xfs@oss.sgi.com Wed Aug 30 22:32:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 30 Aug 2006 22:32:49 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7V5WJDW031883 for ; Wed, 30 Aug 2006 22:32:30 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA12830; Thu, 31 Aug 2006 15:31:29 +1000 Message-ID: <44F6745C.20501@sgi.com> Date: Thu, 31 Aug 2006 15:32:12 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 955854: [SUSE#196895] Undefined behavior calling dm_path_to_hdl if path longer than 2000 References: <44CE9F23.7000605@sgi.com> <44EE9DF7.1080904@sgi.com> <44F66CA0.4080008@sgi.com> In-Reply-To: <44F66CA0.4080008@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8841 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 597 Lines: 16 Date: Thu Aug 31 15:23:16 AEST 2006 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs-dmapi Inspected by: vapo Author: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: linux-melb:dmapi:26893a fs/dmapi/dmapi_register.c - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/dmapi/dmapi_register.c.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h - pv 955854, author: Paul Hinchman, rv: vapo - use PATH_MAX instead hardcoded value of 2000 for limitting the user string length calculation. From owner-xfs@oss.sgi.com Thu Aug 31 00:08:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 00:08:52 -0700 (PDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.150]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7V78fDW016976 for ; Thu, 31 Aug 2006 00:08:42 -0700 Received: from e5.ny.us.ibm.com ([192.168.1.105]) by pokfb.esmtp.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7V5n9OJ032011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 31 Aug 2006 01:49:09 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k7V5n6kU027807 for ; Thu, 31 Aug 2006 01:49:06 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7V5n6aC250392 for ; Thu, 31 Aug 2006 01:49:06 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7V5n67W015956 for ; Thu, 31 Aug 2006 01:49:06 -0400 Received: from [127.0.0.1] ([9.181.134.115]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7V5mu3n015465; Thu, 31 Aug 2006 01:49:02 -0400 Message-ID: <44F67847.6030307@cn.ibm.com> Date: Thu, 31 Aug 2006 13:48:55 +0800 From: Yao Fei Zhu Reply-To: walkinair@cn.ibm.com Organization: IBM User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org CC: haveblue@us.ibm.com, xfs@oss.sgi.com Subject: kernel BUG in __xfs_get_blocks at fs/xfs/linux-2.6/xfs_aops.c:1293! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8842 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: walkinair@cn.ibm.com Precedence: bulk X-list: xfs Content-Length: 5065 Lines: 122 Problem description: Run fsstress on xfs file system with -n 1000 and -p 1000, after about 3 hours, test box will fall into xmon, and get kernel BUG in __xfs_get_blocks at fs/xfs/linux-2.6/xfs_aops.c:1293! Hardware Environment Machine type (p650, x235, SF2, etc.): B70+ Cpu type (Power4, Power5, IA-64, etc.): POWER5+ Software Environmnet Base OS: SLES10 GM Kernel: 2.6.18-rc5 Additional information: 3:mon> e cpu 0x3: Vector: 700 (Program Check) at [c0000001e16632d0] pc: d0000000006daa88: .__xfs_get_blocks+0x1a0/0x2a0 [xfs] lr: d0000000006da984: .__xfs_get_blocks+0x9c/0x2a0 [xfs] sp: c0000001e1663550 msr: 8000000000029032 current = 0xc0000001dde71310 paca = 0xc0000000004c4900 pid = 9217, comm = fsstress kernel BUG in __xfs_get_blocks at fs/xfs/linux-2.6/xfs_aops.c:1293! 3:mon> t [c0000001e1663640] c000000000108344 .__blockdev_direct_IO+0x560/0xcfc [c0000001e1663760] d0000000006dc43c .xfs_vm_direct_IO+0xec/0x13c [xfs] [c0000001e1663860] c0000000000a1474 .generic_file_direct_IO+0xe8/0x15c [c0000001e1663910] c0000000000a1748 .__generic_file_aio_read+0xf4/0x22c [c0000001e16639e0] d0000000006e4b94 .xfs_read+0x288/0x368 [xfs] [c0000001e1663ae0] d0000000006e0750 .xfs_file_aio_read+0x88/0x9c [xfs] [c0000001e1663b70] c0000000000d4df0 .do_sync_read+0xd4/0x130 [c0000001e1663cf0] c0000000000d5c44 .vfs_read+0x118/0x200 [c0000001e1663d90] c0000000000d6128 .sys_read+0x4c/0x8c [c0000001e1663e30] c00000000000871c syscall_exit+0x0/0x40 --- Exception: c01 (System Call) at 000000000ff4ddf8 SP (fc38ec90) is in userspace 3:mon> r R00 = 0000000000000004 R16 = 0000000000000003 R01 = c0000001e1663550 R17 = 0000000000020000 R02 = d000000000727dc0 R18 = c0000001adf18e90 R03 = 0000000000000000 R19 = 000000000000000c R04 = 0000000000000001 R20 = c0000001e1663b50 R05 = c0000001e1663610 R21 = 0000000000000000 R06 = c0000001e1663620 R22 = c0000001d99cfe88 R07 = ffffffffffffffff R23 = 000000000000000c R08 = 0000000000000000 R24 = 0000000000000000 R09 = 0000000000000001 R25 = 0000000000000001 R10 = c00000003173f630 R26 = 000000000010c000 R11 = 0000000000000000 R27 = c0000001adf18e90 R12 = d0000000006e8a78 R28 = 0000000000044000 R13 = c0000000004c4900 R29 = c0000001e16635c8 R14 = c0000001e1663be0 R30 = c000000000517378 R15 = 0000000000000000 R31 = c0000001d99cfbf0 pc = d0000000006daa88 .__xfs_get_blocks+0x1a0/0x2a0 [xfs] lr = d0000000006da984 .__xfs_get_blocks+0x9c/0x2a0 [xfs] msr = 8000000000029032 cr = 42000422 ctr = c00000000007d12c xer = 0000000020000001 trap = 700 3:mon> di d0000000006daa88 d0000000006daa88 0b190000 tdnei r25,0 d0000000006daa8c 2fb80000 cmpdi cr7,r24,0 d0000000006daa90 419e004c beq cr7,d0000000006daadc # .__xfs_get_blocks+0x1f4/0x2a0 [xfs] d0000000006daa94 38000001 li r0,1 d0000000006daa98 7d20f8a8 ldarx r9,r0,r31 d0000000006daa9c 7d290378 or r9,r9,r0 d0000000006daaa0 7d20f9ad stdcx. r9,r0,r31 d0000000006daaa4 40a2fff4 bne d0000000006daa98 # .__xfs_get_blocks+0x1b0/0x2a0 [xfs] d0000000006daaa8 38000020 li r0,32 d0000000006daaac 60000000 nop d0000000006daab0 7d20f8a8 ldarx r9,r0,r31 d0000000006daab4 7d290378 or r9,r9,r0 d0000000006daab8 7d20f9ad stdcx. r9,r0,r31 d0000000006daabc 40a2fff4 bne d0000000006daab0 # .__xfs_get_blocks+0x1c8/0x2a0 [xfs] d0000000006daac0 38000200 li r0,512 d0000000006daac4 60000000 nop 3:mon> mi Mem-info: Node 0 DMA per-cpu: cpu 0 hot: high 6, batch 1 used:5 cpu 0 cold: high 2, batch 1 used:0 cpu 1 hot: high 6, batch 1 used:5 cpu 1 cold: high 2, batch 1 used:0 cpu 2 hot: high 6, batch 1 used:0 cpu 2 cold: high 2, batch 1 used:0 cpu 3 hot: high 6, batch 1 used:0 cpu 3 cold: high 2, batch 1 used:0 Node 0 DMA32 per-cpu: empty Node 0 Normal per-cpu: empty Node 0 HighMem per-cpu: empty Free pages: 36288kB (0kB HighMem) Active:25944 inactive:88655 dirty:13 writeback:11 unstable:0 free:567 slab:9664 mapped:468 pagetables:3094 Node 0 DMA free:36288kB min:11584kB low:14464kB high:17344kB active:1660416kB inactive:5673920kB present:8388608kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 HighMem free:0kB min:2048kB low:2048kB high:2048kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 DMA: 73*64kB 109*128kB 15*256kB 3*512kB 0*1024kB 2*2048kB 0*4096kB 1*8192kB 0*16384kB = 36288kB Node 0 DMA32: empty Node 0 Normal: empty Node 0 HighMem: empty Swap cache: add 3054, delete 29, find 2/4, race 0+0 Free swap = 3932928kB Total swap = 4127296kB Free swap: 3932928kB 131072 pages of RAM 601 reserved pages 107626 pages shared 3025 pages swap cached 3:mon> From owner-xfs@oss.sgi.com Thu Aug 31 00:21:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 00:22:07 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7V7LVDW023833 for ; Thu, 31 Aug 2006 00:21:42 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA13560; Thu, 31 Aug 2006 16:16:38 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 0F83058CF851; Thu, 31 Aug 2006 16:16:37 +1000 (EST) To: slinx-xfs@engr.sgi.com Cc: linux-xfs@oss.sgi.com, sdoyon@max-t.com, lnx1138@us.ibm.com Subject: TAKE 955674 - xfssyncd lock up when filesystem full Message-Id: <20060831061638.0F83058CF851@chook.melbourne.sgi.com> Date: Thu, 31 Aug 2006 16:16:37 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 8843 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2135 Lines: 47 Prevent free space oversubscription and xfssyncd looping. The fix for recent ENOSPC deadlocks introduced certain limitations on allocations. The fix could cause xfssyncd to loop endlessly if we did not leave some space free for the allocator to work correctly. Basically, we needed to ensure that we had at least 4 blocks free for an AG free list and a block for the inode bmap btree at all times. However, this did not take into account the fact that each AG has a free list that needs 4 blocks. Hence any filesystem with more than one AG could cause oversubscription of free space and make xfssyncd spin forever trying to allocate space needed for AG freelists that was not available in the AG. The following patch reserves space for the free lists in all AGs plus the inode bmap btree which prevents oversubscription. It also prevents those blocks from being reported as free space (as they can never be used) and makes the SMP in-core superblock accounting code and the reserved block ioctl respect this requirement. Date: Thu Aug 31 16:14:16 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs-new Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:26894a fs/xfs/xfs_vfsops.c - 1.510 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.510&r2=text&tr2=1.509&f=h - Don't report the space needed by the AG freelists as usable space. fs/xfs/xfs_mount.c - 1.385 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.385&r2=text&tr2=1.384&f=h - Ensure we don't allocate the space we need for the AG freelists. fs/xfs/xfs_alloc.h - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.h.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h - Move definition of free space needed for AG free lists here. fs/xfs/xfs_fsops.c - 1.119 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.119&r2=text&tr2=1.118&f=h - Prevent reserve space from using the space we need for AG freelists. From owner-xfs@oss.sgi.com Thu Aug 31 00:48:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 00:49:14 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7V7mkDW029324 for ; Thu, 31 Aug 2006 00:48:58 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15398; Thu, 31 Aug 2006 17:47:54 +1000 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 k7V7lneQ7698806; Thu, 31 Aug 2006 17:47:51 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7V7lgG97701039; Thu, 31 Aug 2006 17:47:42 +1000 (AEST) Date: Thu, 31 Aug 2006 17:47:42 +1000 From: David Chinner To: Yao Fei Zhu Cc: linux-kernel@vger.kernel.org, haveblue@us.ibm.com, xfs@oss.sgi.com Subject: Re: kernel BUG in __xfs_get_blocks at fs/xfs/linux-2.6/xfs_aops.c:1293! Message-ID: <20060831074742.GD807830@melbourne.sgi.com> References: <44F67847.6030307@cn.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F67847.6030307@cn.ibm.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8844 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2206 Lines: 55 On Thu, Aug 31, 2006 at 01:48:55PM +0800, Yao Fei Zhu wrote: > Problem description: > Run fsstress on xfs file system with -n 1000 and -p 1000, after about 3 > hours, > test box will fall into xmon, and get > kernel BUG in __xfs_get_blocks at fs/xfs/linux-2.6/xfs_aops.c:1293! > > Hardware Environment > Machine type (p650, x235, SF2, etc.): B70+ > Cpu type (Power4, Power5, IA-64, etc.): POWER5+ > Software Environmnet > Base OS: SLES10 GM > Kernel: 2.6.18-rc5 > > Additional information: > 3:mon> e > cpu 0x3: Vector: 700 (Program Check) at [c0000001e16632d0] > pc: d0000000006daa88: .__xfs_get_blocks+0x1a0/0x2a0 [xfs] > lr: d0000000006da984: .__xfs_get_blocks+0x9c/0x2a0 [xfs] > sp: c0000001e1663550 > msr: 8000000000029032 > current = 0xc0000001dde71310 > paca = 0xc0000000004c4900 > pid = 9217, comm = fsstress > kernel BUG in __xfs_get_blocks at fs/xfs/linux-2.6/xfs_aops.c:1293! > 3:mon> t > [c0000001e1663640] c000000000108344 .__blockdev_direct_IO+0x560/0xcfc > [c0000001e1663760] d0000000006dc43c .xfs_vm_direct_IO+0xec/0x13c [xfs] > [c0000001e1663860] c0000000000a1474 .generic_file_direct_IO+0xe8/0x15c > [c0000001e1663910] c0000000000a1748 .__generic_file_aio_read+0xf4/0x22c > [c0000001e16639e0] d0000000006e4b94 .xfs_read+0x288/0x368 [xfs] > [c0000001e1663ae0] d0000000006e0750 .xfs_file_aio_read+0x88/0x9c [xfs] > [c0000001e1663b70] c0000000000d4df0 .do_sync_read+0xd4/0x130 > [c0000001e1663cf0] c0000000000d5c44 .vfs_read+0x118/0x200 > [c0000001e1663d90] c0000000000d6128 .sys_read+0x4c/0x8c > [c0000001e1663e30] c00000000000871c syscall_exit+0x0/0x40 Hmmmm. We've mapped a range that has been reserved for a delayed allocate extent during a direct I/O. That should not happen as XFS flushes delalloc extents before executing a direct read and holds the I/O lock which will prevent any new writes from mapping new delalloc extents. Something went astray, though. :( Can you give me some more detail on the machine you're running? e.g. How many CPUs, RAM and what type of disk subsystem you are using? That will make it easier for us to try to reproduce this problem. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Aug 31 01:03:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 01:03:46 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7V83SDW003004 for ; Thu, 31 Aug 2006 01:03:28 -0700 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k7V82tSJ025235 for ; Thu, 31 Aug 2006 04:02:55 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7V82tj5013894 for ; Thu, 31 Aug 2006 04:02:55 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7V82spG013394 for ; Thu, 31 Aug 2006 04:02:54 -0400 Received: from [127.0.0.1] ([9.181.134.115]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7V82kjj012966; Thu, 31 Aug 2006 04:02:51 -0400 Message-ID: <44F6979C.4070309@cn.ibm.com> Date: Thu, 31 Aug 2006 16:02:36 +0800 From: Yao Fei Zhu Reply-To: walkinair@cn.ibm.com Organization: IBM User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner CC: linux-kernel@vger.kernel.org, haveblue@us.ibm.com, xfs@oss.sgi.com Subject: Re: kernel BUG in __xfs_get_blocks at fs/xfs/linux-2.6/xfs_aops.c:1293! References: <44F67847.6030307@cn.ibm.com> <20060831074742.GD807830@melbourne.sgi.com> In-Reply-To: <20060831074742.GD807830@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8845 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: walkinair@cn.ibm.com Precedence: bulk X-list: xfs Content-Length: 813 Lines: 26 David Chinner wrote: > >Hmmmm. We've mapped a range that has been reserved for a delayed >allocate extent during a direct I/O. That should not happen as XFS >flushes delalloc extents before executing a direct read and holds >the I/O lock which will prevent any new writes from mapping new >delalloc extents. Something went astray, though. :( > >Can you give me some more detail on the machine you're running? >e.g. How many CPUs, RAM and what type of disk subsystem you are using? >That will make it easier for us to try to reproduce this problem. > >Cheers, > >Dave. > > The test box is an IBM System p5 Linux partition, allocated with 0.8 physical POWER5+ cpu processing unit/ 2 virtual processors and 8GB memory. The disk is exported by AIX Virtual IO Server. BTW, I have CONFIG_PPC_64K_PAGES enabled. From owner-xfs@oss.sgi.com Thu Aug 31 01:18:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 01:19:22 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7V8IaDW006711 for ; Thu, 31 Aug 2006 01:18:49 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA16074; Thu, 31 Aug 2006 18:17:41 +1000 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 k7V8HYeQ7702178; Thu, 31 Aug 2006 18:17:37 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7V8HQa17701199; Thu, 31 Aug 2006 18:17:26 +1000 (AEST) Date: Thu, 31 Aug 2006 18:17:26 +1000 From: David Chinner To: Yao Fei Zhu Cc: David Chinner , linux-kernel@vger.kernel.org, haveblue@us.ibm.com, xfs@oss.sgi.com Subject: Re: kernel BUG in __xfs_get_blocks at fs/xfs/linux-2.6/xfs_aops.c:1293! Message-ID: <20060831081726.GV5737019@melbourne.sgi.com> References: <44F67847.6030307@cn.ibm.com> <20060831074742.GD807830@melbourne.sgi.com> <44F6979C.4070309@cn.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F6979C.4070309@cn.ibm.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 8846 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1104 Lines: 32 On Thu, Aug 31, 2006 at 04:02:36PM +0800, Yao Fei Zhu wrote: > David Chinner wrote: > >Hmmmm. We've mapped a range that has been reserved for a delayed > >allocate extent during a direct I/O. That should not happen as XFS > >flushes delalloc extents before executing a direct read and holds > >the I/O lock which will prevent any new writes from mapping new > >delalloc extents. Something went astray, though. :( > > > >Can you give me some more detail on the machine you're running? > >e.g. How many CPUs, RAM and what type of disk subsystem you are using? > >That will make it easier for us to try to reproduce this problem. > > The test box is an IBM System p5 Linux partition, allocated with > 0.8 physical POWER5+ cpu processing unit/ 2 virtual processors and 8GB > memory. > The disk is exported by AIX Virtual IO Server. Nothing too unusual there. > BTW, I have CONFIG_PPC_64K_PAGES enabled. But that might be a good place to start. Can you see if you can reproduce the problem without this config option set? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Aug 31 04:25:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 04:25:45 -0700 (PDT) Received: from kernel.dk (brick.kernel.dk [62.242.22.158]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7VBPKDW007792 for ; Thu, 31 Aug 2006 04:25:22 -0700 Received: from nelson.home.kernel.dk (nelson.home.kernel.dk [192.168.0.33]) by kernel.dk (Postfix) with ESMTP id 4556463CE1; Thu, 31 Aug 2006 11:21:46 +0200 (CEST) Received: by nelson.home.kernel.dk (Postfix, from userid 1000) id 3D7EE48953; Thu, 31 Aug 2006 11:24:41 +0200 (CEST) Date: Thu, 31 Aug 2006 11:24:41 +0200 From: Jens Axboe To: "Jeffrey E. Hundstad" Cc: xfs@oss.sgi.com, nathans@sgi.com Subject: Re: vmsplice can't work well Message-ID: <20060831092440.GC5528@kernel.dk> References: <44F4440F.1090300@gmail.com> <20060829140542.GN12257@kernel.dk> <44F5CC08.8010205@mnsu.edu> <20060830174815.GF7331@kernel.dk> <44F5D3C6.1010108@mnsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F5D3C6.1010108@mnsu.edu> X-archive-position: 8849 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: axboe@kernel.dk Precedence: bulk X-list: xfs Content-Length: 942 Lines: 34 XFS list, On Wed, Aug 30 2006, Jeffrey E. Hundstad wrote: > Jens Axboe wrote: > >On Wed, Aug 30 2006, Jeffrey E. Hundstad wrote: > > > >>I tried your splie-git...tar.gz file and tried the splice-cp. It > >>produced files that are the right length... but the files only contain > >>nulls. Here's the straces: > >> > > > >Works for me as well. Could be an fs issue, how large was the README and > >what filesystem did you use? > > > > > The file was 1130 bytes (it was the README in that directory.) The > filesystem is XFS. > I can reproduce this quite easily, doing: nelson:~ # splice-cp sda.blktrace.0 foo nelson:~ # md5sum sda.blktrace.0 foo 4754070ae77091468c830ea23b125d68 sda.blktrace.0 efdc7b9d00692fdfe91a691277209267 foo 'foo' contains only zeroes. Doing the same on ext3 yields the correct results, foo contains the right data. I'm testing on 2.16.18-rc5-current, Jeffrey used 2.6.17.x latest. -- Jens Axboe From owner-xfs@oss.sgi.com Thu Aug 31 11:56:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 11:56:26 -0700 (PDT) Received: from mail.itsolut.com (mail.itsolut.com [64.182.153.89]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7VIuCDW013517 for ; Thu, 31 Aug 2006 11:56:17 -0700 Received: by mail.itsolut.com (Postfix, from userid 5004) id 4740A59360; Thu, 31 Aug 2006 11:57:23 -0500 (EST) Received: from [192.168.0.197] (host-69-95-111-118.cwon.choiceone.net [69.95.111.118]) by mail.itsolut.com (Postfix) with ESMTP id 3635C59240 for ; Thu, 31 Aug 2006 11:57:22 -0500 (EST) Message-ID: <44F714F2.7050502@gmail.com> Date: Thu, 31 Aug 2006 12:57:22 -0400 From: Chris Hane User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: XFS and 3.2TB Partition Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8851 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chrishane@gmail.com Precedence: bulk X-list: xfs Content-Length: 1509 Lines: 53 I am trying to create a 3.2TB partition on my Raid 5. Is there a document that could help? I have a 3ware 9500 controller and 8 *500GB sata drives configured into a single RAID 5 array. I am running linux 2.6.16 with the 3ware drivers compiled into the kernel. I've tried a couple of different means to create the partition and format the file system with xfs without success (or confidence that I haven't done something wrong). 1. FDISK I've tried fdisk on the array to create the partition; but it forces me enter the number of cylinders before letting me create the partition. I enter the largest number of cylinders since I'm not sure how to calculate the correct cylinder number across an 8 disk RAID 5 array. I then create the partition starting at 0 (or whatever the default was) and ending at 3500GB. Once the partition is created this way, I can mkfs.xfs; but I'm a little hesitant to use this since I input and arbitrary cylinder number. Thoughts on what to use for the correct cylinder count with fdisk? 2. PARTED I've tried to use parted without any success. Here is what I've tried and the errors I get. > parted parted> mklabel gpt parted> mkpart primary 0 3500GB parted> quit ok - the partition now exists. If I use ext2 everything works ok. however, when I run > mkfs.xfs /dev/sda1 the file system is formated but is truncated to to 2TB. Any advice/pointers on how to partition and format a 3.2TB raid 5 array would be much appreciated. Thanks, Chris.... From owner-xfs@oss.sgi.com Thu Aug 31 12:38:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 12:38:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7VJc1DW026967 for ; Thu, 31 Aug 2006 12:38:04 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7VJbGGA007914; Thu, 31 Aug 2006 15:37:16 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k7VJbBen012944; Thu, 31 Aug 2006 15:37:11 -0400 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k7VJbAoZ011847; Thu, 31 Aug 2006 15:37:10 -0400 Message-ID: <44F73A65.8050105@sandeen.net> Date: Thu, 31 Aug 2006 14:37:09 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.5 (X11/20060808) MIME-Version: 1.0 To: Chris Hane CC: xfs@oss.sgi.com Subject: Re: XFS and 3.2TB Partition References: <44F714F2.7050502@gmail.com> In-Reply-To: <44F714F2.7050502@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8852 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 729 Lines: 28 Chris Hane wrote: > 2. PARTED > > I've tried to use parted without any success. Here is what I've tried > and the errors I get. > > > parted > parted> mklabel gpt > parted> mkpart primary 0 3500GB > parted> quit > > ok - the partition now exists. If I use ext2 everything works ok. > > however, when I run > > > mkfs.xfs /dev/sda1 > > the file system is formated but is truncated to to 2TB. I'd think parted should be able to handle large devices... mkfs.xfs uses the BLKGETSIZE64 and BLKGETSIZE ioctls to determine device size; you might either instrument xfsprogs/libxfs/linux.c and re-run, or strace your mkfs command looking for those ioctl calls, to see what size it's getting back from the kernel. -Eric From owner-xfs@oss.sgi.com Thu Aug 31 13:46:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 13:46:43 -0700 (PDT) Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7VKkZDW004419 for ; Thu, 31 Aug 2006 13:46:35 -0700 Received: from [127.0.0.1] (lupo.thebarn.com [10.0.0.10]) (authenticated bits=0) by slurp.thebarn.com (8.13.5/8.13.5) with ESMTP id k7VKjXsj031565; Thu, 31 Aug 2006 15:45:55 -0500 (CDT) (envelope-from cattelan@thebarn.com) Subject: Re: XFS and 3.2TB Partition From: Russell Cattelan To: Chris Hane Cc: xfs@oss.sgi.com In-Reply-To: <44F714F2.7050502@gmail.com> References: <44F714F2.7050502@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-E01V+o9OPg1jdlx1Z/nV" Date: Thu, 31 Aug 2006 15:45:33 -0500 Message-Id: <1157057133.8077.1.camel@xenon.msp.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.7.92-1mdv2007.0 X-archive-position: 8854 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 725 Lines: 30 --=-E01V+o9OPg1jdlx1Z/nV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2006-08-31 at 12:57 -0400, Chris Hane wrote: >=20 > I have a 3ware 9500 controller and 8 *500GB sata drives configured > into=20 > a single RAID 5 array. >=20 You might want to google around a bit and verify that your controller supports lun's over 2TB. --=-E01V+o9OPg1jdlx1Z/nV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBE90ptNRmM+OaGhBgRAq1ZAJ90Qpu5IqCl8hcJE8yEOa/ZM9aqOQCgg3ha QCdg9MCdtmkBenxA5k8WtrU= =a0Rk -----END PGP SIGNATURE----- --=-E01V+o9OPg1jdlx1Z/nV-- From owner-xfs@oss.sgi.com Thu Aug 31 13:42:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 13:43:01 -0700 (PDT) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k7VKgmDW003634 for ; Thu, 31 Aug 2006 13:42:54 -0700 Received: from agami.com ([192.168.168.133]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id k7VKgBuu004832 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 31 Aug 2006 13:42:11 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id k7VKg6lA002944 for ; Thu, 31 Aug 2006 13:42:06 -0700 Received: from [10.125.200.166] ([10.125.200.166]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 13:44:42 -0700 Message-ID: <44F74996.8000209@agami.com> Date: Fri, 01 Sep 2006 02:11:58 +0530 From: Shailendra Tripathi User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Hane CC: xfs@oss.sgi.com Subject: Re: XFS and 3.2TB Partition References: <44F714F2.7050502@gmail.com> In-Reply-To: <44F714F2.7050502@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2006 20:44:42.0734 (UTC) FILETIME=[494198E0:01C6CD3E] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 8853 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stripathi@agami.com Precedence: bulk X-list: xfs Content-Length: 2417 Lines: 70 Hi Chris, > > I am trying to create a 3.2TB partition on my Raid 5. Is there a > document that could help? You can get generic information on partitions and how to create them at http://www.faqs.org/docs/Linux-mini/Partition.html > I have a 3ware 9500 controller and 8 *500GB sata drives configured > into a single RAID 5 array. > I am running linux 2.6.16 with the 3ware drivers compiled into the > kernel. > > I've tried a couple of different means to create the partition and > format the file system with xfs without success (or confidence that I > haven't done something wrong). > > 1. FDISK > > I've tried fdisk on the array to create the partition; but it forces > me enter the number of cylinders before letting me create the > partition. I enter the largest number of cylinders since I'm not sure > how to calculate the correct cylinder number across an 8 disk RAID 5 > array. > > I then create the partition starting at 0 (or whatever the default > was) and ending at 3500GB. > > Once the partition is created this way, I can mkfs.xfs; but I'm a > little hesitant to use this since I input and arbitrary cylinder number. > > Thoughts on what to use for the correct cylinder count with fdisk? > It is not actually arbitrary. There are various options to create a partition - can specify the size, sectors or cylinders. fdisk -l /dev/ can hopefully give you details about the size of the disk, cylinders etc. Now, it is upto to you as to how many partiotions you want to create and use. > 2. PARTED > > I've tried to use parted without any success. Here is what I've tried > and the errors I get. > > > parted > parted> mklabel gpt > parted> mkpart primary 0 3500GB > parted> quit > > ok - the partition now exists. If I use ext2 everything works ok. > > however, when I run > > > mkfs.xfs /dev/sda1 > > the file system is formated but is truncated to to 2TB. XFS can limit the FS size this way when AG count is just 2. xfs_info will list the details about the number of AG count. XFS can support about 1 TB in one AG. By default, it calculates the agcount automatically unless you force them. Your command line option does not suggest this. The 2 TB limit might be coming, perhaps, because parted uses 4 byte addresses data structures. This way, it can support maximum of 2^32 sectors of 512 size ~ 41 bits ~ 2TB. It is my guess, though. -shailendra From owner-xfs@oss.sgi.com Thu Aug 31 16:18:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 16:18:42 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7VNI6DW021937 for ; Thu, 31 Aug 2006 16:18:18 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA05838; Fri, 1 Sep 2006 09:17:10 +1000 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 k7VNH7eQ8381792; Fri, 1 Sep 2006 09:17:08 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7VNH2df8492362; Fri, 1 Sep 2006 09:17:02 +1000 (AEST) Date: Fri, 1 Sep 2006 09:17:02 +1000 From: David Chinner To: Jens Axboe Cc: "Jeffrey E. Hundstad" , xfs@oss.sgi.com, nathans@sgi.com Subject: Re: vmsplice can't work well Message-ID: <20060831231702.GW5737019@melbourne.sgi.com> References: <44F4440F.1090300@gmail.com> <20060829140542.GN12257@kernel.dk> <44F5CC08.8010205@mnsu.edu> <20060830174815.GF7331@kernel.dk> <44F5D3C6.1010108@mnsu.edu> <20060831092440.GC5528@kernel.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060831092440.GC5528@kernel.dk> User-Agent: Mutt/1.4.2.1i X-archive-position: 8855 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1270 Lines: 43 On Thu, Aug 31, 2006 at 11:24:41AM +0200, Jens Axboe wrote: > On Wed, Aug 30 2006, Jeffrey E. Hundstad wrote: > > Jens Axboe wrote: > > >On Wed, Aug 30 2006, Jeffrey E. Hundstad wrote: > > > > > >>I tried your splie-git...tar.gz file and tried the splice-cp. It > > >>produced files that are the right length... but the files only contain > > >>nulls. Here's the straces: > > >> > > > > > >Works for me as well. Could be an fs issue, how large was the README and > > >what filesystem did you use? > > > > > > > > The file was 1130 bytes (it was the README in that directory.) The > > filesystem is XFS. > > > > I can reproduce this quite easily, doing: > > nelson:~ # splice-cp sda.blktrace.0 foo > > nelson:~ # md5sum sda.blktrace.0 foo 4754070ae77091468c830ea23b125d68 > sda.blktrace.0 efdc7b9d00692fdfe91a691277209267 foo Not good. > 'foo' contains only zeroes. Doing the same on ext3 yields the correct > results, foo contains the right data. I'm testing on 2.16.18-rc5-current, > Jeffrey used 2.6.17.x latest. I had a quick look at the code and I can't see anything obviously wrong in the XFS code. Where can I find the splice userspace application source, Jens? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Aug 31 16:19:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 16:20:02 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k7VNJWDW026432 for ; Thu, 31 Aug 2006 16:19:43 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA05887; Fri, 1 Sep 2006 09:18:47 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k7VNIhgw3234368; Fri, 1 Sep 2006 09:18:44 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k7VNIejJ3238636; Fri, 1 Sep 2006 09:18:40 +1000 (EST) Date: Fri, 1 Sep 2006 09:18:40 +1000 From: Nathan Scott To: David Chinner Cc: Jens Axboe , "Jeffrey E. Hundstad" , xfs@oss.sgi.com Subject: Re: vmsplice can't work well Message-ID: <20060901091839.M3186664@wobbly.melbourne.sgi.com> References: <44F4440F.1090300@gmail.com> <20060829140542.GN12257@kernel.dk> <44F5CC08.8010205@mnsu.edu> <20060830174815.GF7331@kernel.dk> <44F5D3C6.1010108@mnsu.edu> <20060831092440.GC5528@kernel.dk> <20060831231702.GW5737019@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060831231702.GW5737019@melbourne.sgi.com>; from dgc@sgi.com on Fri, Sep 01, 2006 at 09:17:02AM +1000 X-archive-position: 8856 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 337 Lines: 13 On Fri, Sep 01, 2006 at 09:17:02AM +1000, David Chinner wrote: > On Thu, Aug 31, 2006 at 11:24:41AM +0200, Jens Axboe wrote: > I had a quick look at the code and I can't see anything obviously wrong > in the XFS code. Where can I find the splice userspace application source, > Jens? http://brick.kernel.dk/snaps/ cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Aug 31 21:11:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 21:12:18 -0700 (PDT) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.150]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k814BrDW002022 for ; Thu, 31 Aug 2006 21:11:56 -0700 Received: from e33.co.us.ibm.com ([9.17.249.43]) by pokfb.esmtp.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k813hmoW010094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 31 Aug 2006 23:43:49 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id k813hhdm020930 for ; Thu, 31 Aug 2006 23:43:43 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k813hhjt290610 for ; Thu, 31 Aug 2006 21:43:43 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k813hgee019628 for ; Thu, 31 Aug 2006 21:43:42 -0600 Received: from [127.0.0.1] ([9.181.134.115]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k813hXMZ019372; Thu, 31 Aug 2006 21:43:39 -0600 Message-ID: <44F7AC65.5050502@cn.ibm.com> Date: Fri, 01 Sep 2006 11:43:33 +0800 From: Yao Fei Zhu Reply-To: walkinair@cn.ibm.com Organization: IBM User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: David Chinner , linux-kernel@vger.kernel.org, haveblue@us.ibm.com, xfs@oss.sgi.com Subject: Re: kernel BUG in __xfs_get_blocks at fs/xfs/linux-2.6/xfs_aops.c:1293! References: <44F67847.6030307@cn.ibm.com> <20060831074742.GD807830@melbourne.sgi.com> <44F6979C.4070309@cn.ibm.com> <20060831081726.GV5737019@melbourne.sgi.com> <20060831015430.6df0d8ba.akpm@osdl.org> In-Reply-To: <20060831015430.6df0d8ba.akpm@osdl.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 8857 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: walkinair@cn.ibm.com Precedence: bulk X-list: xfs Content-Length: 4097 Lines: 112 Andrew Morton wrote: >On Thu, 31 Aug 2006 18:17:26 +1000 >David Chinner wrote: > > > >>>BTW, I have CONFIG_PPC_64K_PAGES enabled. >>> >>> >>But that might be a good place to start. Can you see if you can >>reproduce the problem without this config option set? >> >> > >It would be useful to compare the compiler warning output for 64k pages >versus that for smaller-pages. > >Several quite worrisome-looking warnings are emitted from various parts of >the kernel with 64k pages. Related to arithmetic on short types. > > 1. the config diff blade10:/boot # diff config-2.6.18-rc5-ppc64 config-2.6.18-rc5-ppc64.64kp 4c4 < # Thu Aug 31 18:25:42 2006 --- > # Thu Aug 31 21:18:52 2006 51c51 < CONFIG_LOCALVERSION="-ppc64" --- > CONFIG_LOCALVERSION="-ppc64.64kp" 173c173 < CONFIG_FORCE_MAX_ZONEORDER=13 --- > CONFIG_FORCE_MAX_ZONEORDER=9 204c204 < # CONFIG_PPC_64K_PAGES is not set --- > CONFIG_PPC_64K_PAGES=y 2. the compiler warning diff ltctest:~ # diff 4k.warning 64k.warning 0a1,5 > kernel/power/pm.c:205: warning: ‘pm_register’ is deprecated (declared at kernel/power/pm.c:64) > kernel/power/pm.c:205: warning: ‘pm_register’ is deprecated (declared at kernel/power/pm.c:64) > kernel/power/pm.c:206: warning: ‘pm_send_all’ is deprecated (declared at kernel/power/pm.c:180) > kernel/power/pm.c:206: warning: ‘pm_send_all’ is deprecated (declared at kernel/power/pm.c:180) > fs/bio.c:169: warning: ‘idx’ may be used uninitialized in this function 8,13d12 < fs/bio.c:169: warning: ‘idx’ may be used uninitialized in this function < kernel/power/pm.c:205: warning: ‘pm_register’ is deprecated (declared at kernel/power/pm.c:64) < kernel/power/pm.c:205: warning: ‘pm_register’ is deprecated (declared at kernel/power/pm.c:64) < kernel/power/pm.c:206: warning: ‘pm_send_all’ is deprecated (declared at kernel/power/pm.c:180) < kernel/power/pm.c:206: warning: ‘pm_send_all’ is deprecated (declared at kernel/power/pm.c:180) < fs/eventpoll.c:500: warning: ‘fd’ may be used uninitialized in this function 17a17,27 > fs/eventpoll.c:500: warning: ‘fd’ may be used uninitialized in this function > fs/fat/inode.c:1227: warning: comparison is always false due to limited range of data type > fs/hfs/btree.c:243: warning: comparison is always false due to limited range of data type > fs/hfsplus/btree.c:235: warning: comparison is always false due to limited range of data type > fs/ocfs2/vote.c:774: warning: ‘response’ may be used uninitialized in this function > fs/ocfs2/dlm/dlmdomain.c:70: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 7 has type ‘int’ > fs/ocfs2/dlm/dlmdomain.c:70: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 7 has type ‘int’ > fs/ocfs2/dlm/dlmdomain.c:70: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 7 has type ‘int’ > fs/ocfs2/dlm/dlmdomain.c:918: warning: ‘response’ may be used uninitialized in this function > fs/udf/balloc.c:751: warning: ‘goal_eloc.logicalBlockNum’ may be used uninitialized in this function > fs/udf/super.c:1364: warning: ‘ino.partitionReferenceNum’ may be used uninitialized in this function 56a67,68 > drivers/usb/core/devio.c:620: warning: comparison is always false due to limited range of data type > drivers/net/r8169.c:2131: warning: ‘txd’ may be used uninitialized in this function 59d70 < drivers/net/r8169.c:2131: warning: ‘txd’ may be used uninitialized in this function 70,73c81 < fs/ocfs2/vote.c:774: warning: ‘response’ may be used uninitialized in this function < fs/ocfs2/dlm/dlmdomain.c:918: warning: ‘response’ may be used uninitialized in this function < fs/udf/balloc.c:751: warning: ‘goal_eloc.logicalBlockNum’ may be used uninitialized in this function < fs/udf/super.c:1364: warning: ‘ino.partitionReferenceNum’ may be used uninitialized in this function --- > net/key/af_key.c:403: warning: comparison is always false due to limited range of data type From owner-xfs@oss.sgi.com Thu Aug 31 23:35:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 31 Aug 2006 23:35:43 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k816ZODW019835 for ; Thu, 31 Aug 2006 23:35:25 -0700 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k816YnTh016318 for ; Fri, 1 Sep 2006 02:34:49 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k816YlCZ273914 for ; Fri, 1 Sep 2006 02:34:49 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k816Ylhp025402 for ; Fri, 1 Sep 2006 02:34:47 -0400 Received: from [127.0.0.1] ([9.181.134.115]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k816YcSJ025262; Fri, 1 Sep 2006 02:34:43 -0400 Message-ID: <44F7D47E.7020906@cn.ibm.com> Date: Fri, 01 Sep 2006 14:34:38 +0800 From: Yao Fei Zhu Reply-To: walkinair@cn.ibm.com Organization: IBM User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner CC: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: kernel BUG in __xfs_get_blocks at fs/xfs/linux-2.6/xfs_aops.c:1293! References: <44F67847.6030307@cn.ibm.com> <20060831074742.GD807830@melbourne.sgi.com> <44F6979C.4070309@cn.ibm.com> <20060831081726.GV5737019@melbourne.sgi.com> In-Reply-To: <20060831081726.GV5737019@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8858 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: walkinair@cn.ibm.com Precedence: bulk X-list: xfs Content-Length: 271 Lines: 10 David Chinner wrote: >But that might be a good place to start. Can you see if you can >reproduce the problem without this config option set? > > No, I can't reproduce this prlblem without the CONFIG_PPC_64K_PAGES config option set, the fsstress testcase works fine.