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