From owner-xfs@oss.sgi.com Sat Sep 1 17:09:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 01 Sep 2007 17:09:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8209R4p000640 for ; Sat, 1 Sep 2007 17:09:28 -0700 Received: from [89.49.172.106] (helo=[192.168.178.20]) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IRaAk-0006dw-20 for xfs@oss.sgi.com; Sat, 01 Sep 2007 23:06:26 +0200 Date: Sat, 1 Sep 2007 23:06:25 +0200 (CEST) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: xfs@oss.sgi.com Subject: lockdep annotations? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-archive-position: 12742 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs Hi, I try to follow -rc kernels and just upgraded to 2.6.23-rc5 and I still see: "INFO: possible circular locking dependency detected". Out of curiosity: (when) will these warnings be addressed? I mean, suits me for enabling CONFIG_LOCKDEP in the first place, but the only warnings I get is still xfs :) FWIW, full log is here: http://nerdbynature.de/bits/2.6.23-rc5/messages_2.6.23-rc5 Thanks, Christian. -- BOFH excuse #156: Zombie processes haunting the computer From owner-xfs@oss.sgi.com Sun Sep 2 04:43:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 04:43:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.8 required=5.0 tests=BAYES_99,MSGID_FROM_MTA_HEADER autolearn=no version=3.2.0-pre1-r499012 Received: from mx05.syd.iprimus.net.au (mx05.syd.iprimus.net.au [210.50.30.235]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l82Bgw4p017475 for ; Sun, 2 Sep 2007 04:43:03 -0700 Message-Id: <68bfp5$1t8kpt@smtp05.syd.iprimus.net.au> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFs72kY6s3Ob/2dsb2JhbAAMphA X-IronPort-AV: E=Sophos;i="4.20,199,1186322400"; d="scan'208";a="64246589" Received: from unknown (HELO [192.168.1.102]) ([58.179.115.155]) by smtp05.syd.iprimus.net.au with ESMTP; 02 Sep 2007 21:30:56 +1000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Description: Mail message body Subject: Start Sending Video Emails In Minutes To: Recipients X-IMBH: Yes From: mwpoz@iprimus.com.au Date: Sun, 02 Sep 2007 21:30:47 +1000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l82Bh34p017496 X-archive-position: 12743 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mwpoz@iprimus.com.au Precedence: bulk X-list: xfs TALK FUSION - The newest development in email technology Businesses and Talk Fusion make a great pair! From family-owned to Fortune 500, Talk Fusion is your answer. We have a perfect fit! Video email will build brand loyalty, increase customer relations and retention, reduce advertising costs, qualify sales leads and increase response rates. • Home Tours • Sale Announcements • Product Demos • Training • Promotions • Events • Advertising • Prospecting • New Lead Capture • Motivational Messages • Corporate News • Fundraising • Presentations • Customer Follow-Ups • Appointment Reminders • Special Instructions • Customer Appreciation • Qualify Leads • Invitations • Trackable Marketing Talk Fusion is even smart enough to notify you when your video message is being watched! With our real-time tracking technology, you will be able to see who has viewed your video email, when, and if they forwarded it to a friend or clicked through to your web site! Capture new leads and know exactly who’s interested. Learn more. Talk Fusion combines the power of television with the ease of email, allowing you to be in two places at once, share special moments and even build greater brand loyalty among customers. All without annoying downloads, pop-up windows, software to install or attachments to open. If you are one of the 700 million email users sending over 30 billion emails every day, you can point, click and send vibrant video emails to anyone, anywhere in the world, anytime. It is so simple, anyone can use it. No Internet experience necessary. Visit Talk Fusion http://www.jbdmarketing.com Sample Video Email http://www.talkfusion.com/samples/vistaprint_flv.htm Jeremy B Dwyer JBD Marketing ========================================================================================================= This is a once only mailing to an optin commercial mailing list supplied by a marketing company. If this email is considered SPAM, we apologies for any inconvenience. Should you receive further unwanted emails, please contact us at talkfusion@iprimus.com.au. ========================================================================================================= From owner-xfs@oss.sgi.com Sun Sep 2 07:44:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 07:44:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,BAYES_50, DATE_IN_PAST_12_24 autolearn=no version=3.2.0-pre1-r499012 Received: from amanpulo.fs3.ph (amanpulo.fs3.ph [72.51.42.241]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l82Eih4p012910 for ; Sun, 2 Sep 2007 07:44:45 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.fs3.ph (Postfix) with ESMTP id 8E7E61E0D5953 for ; Sun, 2 Sep 2007 21:46:50 +0800 (PHT) X-Virus-Scanned: Debian amavisd-new at fs3.ph Received: from amanpulo.fs3.ph ([127.0.0.1]) by localhost (amanpulo.fs3.ph [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dCbeMq+GSUE3 for ; Sun, 2 Sep 2007 21:46:41 +0800 (PHT) Received: from auctoritas.local (unknown [222.127.47.132]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by amanpulo.fs3.ph (Postfix) with ESMTP id D832D1E0E08B5 for ; Sun, 2 Sep 2007 21:46:40 +0800 (PHT) Subject: Re: ZFS, XFS, and EXT4 compared From: Federico Sevilla III To: xfs@oss.sgi.com In-Reply-To: <1188513751.24970.109.camel@edge.yarra.acx> References: <1188454611.23311.13.camel@toonses.gghcwest.com> <1188457666.24970.94.camel@edge.yarra.acx> <20070830132002.GA4086@infradead.org> <1188513751.24970.109.camel@edge.yarra.acx> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WuH1W4y6xpJyStAd+cd0" Organization: F S 3 Consulting Inc. Date: Sat, 01 Sep 2007 23:07:23 +0800 Message-Id: <1188659243.4430.8.camel@auctoritas.fs3.ph> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-archive-position: 12744 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jijo@fs3.ph Precedence: bulk X-list: xfs --=-WuH1W4y6xpJyStAd+cd0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2007-08-31 at 08:42 +1000, Nathan Scott wrote: > Possibly. Far more importantly for XFS, there really needs to be some > way for RAID drivers to say "even though I support write barriers, its > not a good idea for filesystems to enable write barriers by default on > me". Enabling write barriers everywhere, by default, seems to have a > far worse impact than any mkfs/mount option tweaking. On all my systems with software RAID or dm-crypt (or both), mounting XFS gives me a message about barriers being disabled because the underlying device doesn't support it. For good measure I disable write caching on all my systems with either software RAID or dm-crypt (or both). Am I reading the thread correctly that even with this message showing up, I still need to mount with nobarrier explicitly to improve performance? I also think it would be nice to add something like a modern-day tuning FAQ for XFS. I know there's a bit on the FAQ already but perhaps it needs an update? Thanks. --=20 Federico Sevilla III F S 3 Consulting Inc. http://www.fs3.ph --=-WuH1W4y6xpJyStAd+cd0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBG2YAr5rCBSJO3Rr4RAkH6AJ9sUGdQkS8qnaoY/Cb6i51vRtVTvgCZATVY l9LKoNVPbMi16yxXZ7Nx8uI= =Ymg2 -----END PGP SIGNATURE----- --=-WuH1W4y6xpJyStAd+cd0-- From owner-xfs@oss.sgi.com Sun Sep 2 13:17:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 13:17:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l82KHS4p029282 for ; Sun, 2 Sep 2007 13:17:29 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l82KHRA5029867 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 2 Sep 2007 22:17:27 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l82KHRqV029864 for xfs@oss.sgi.com; Sun, 2 Sep 2007 22:17:27 +0200 Date: Sun, 2 Sep 2007 22:17:27 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] kill probe_* sysctl leftovers Message-ID: <20070902201727.GA29823@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12745 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs After my recent changes the probe_* sysctls are unused because we do a proper request_module now if we actually know that we need the quota or dmapi module. Kill the leftovers that have no function anymore. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_globals.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_globals.c 2007-09-02 21:48:26.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_globals.c 2007-09-02 22:02:29.000000000 +0200 @@ -32,9 +32,6 @@ xfs_param_t xfs_params = { .panic_mask = { 0, 0, 255 }, .error_level = { 0, 3, 11 }, .syncd_timer = { 1*100, 30*100, 7200*100}, - .probe_dmapi = { 0, 0, 1 }, - .probe_ioops = { 0, 0, 1 }, - .probe_quota = { 0, 1, 1 }, .stats_clear = { 0, 0, 1 }, .inherit_sync = { 0, 1, 1 }, .inherit_nodump = { 0, 1, 1 }, Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_linux.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_linux.h 2007-09-02 21:48:26.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_linux.h 2007-09-02 22:02:29.000000000 +0200 @@ -119,9 +119,6 @@ #define xfs_panic_mask xfs_params.panic_mask.val #define xfs_error_level xfs_params.error_level.val #define xfs_syncd_centisecs xfs_params.syncd_timer.val -#define xfs_probe_dmapi xfs_params.probe_dmapi.val -#define xfs_probe_ioops xfs_params.probe_ioops.val -#define xfs_probe_quota xfs_params.probe_quota.val #define xfs_stats_clear xfs_params.stats_clear.val #define xfs_inherit_sync xfs_params.inherit_sync.val #define xfs_inherit_nodump xfs_params.inherit_nodump.val Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_sysctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_sysctl.c 2007-09-02 21:48:26.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_sysctl.c 2007-09-02 22:02:29.000000000 +0200 @@ -123,39 +123,6 @@ static ctl_table xfs_table[] = { .extra2 = &xfs_params.syncd_timer.max }, { - .ctl_name = XFS_PROBE_DMAPI, - .procname = "probe_dmapi", - .data = &xfs_params.probe_dmapi.val, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec_minmax, - .strategy = &sysctl_intvec, - .extra1 = &xfs_params.probe_dmapi.min, - .extra2 = &xfs_params.probe_dmapi.max - }, - { - .ctl_name = XFS_PROBE_IOOPS, - .procname = "probe_ioops", - .data = &xfs_params.probe_ioops.val, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec_minmax, - .strategy = &sysctl_intvec, - .extra1 = &xfs_params.probe_ioops.min, - .extra2 = &xfs_params.probe_ioops.max - }, - { - .ctl_name = XFS_PROBE_QUOTA, - .procname = "probe_quota", - .data = &xfs_params.probe_quota.val, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec_minmax, - .strategy = &sysctl_intvec, - .extra1 = &xfs_params.probe_quota.min, - .extra2 = &xfs_params.probe_quota.max - }, - { .ctl_name = XFS_INHERIT_SYNC, .procname = "inherit_sync", .data = &xfs_params.inherit_sync.val, Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_sysctl.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_sysctl.h 2007-09-02 21:48:26.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_sysctl.h 2007-09-02 22:02:29.000000000 +0200 @@ -39,9 +39,6 @@ typedef struct xfs_param { xfs_sysctl_val_t error_level; /* Degree of reporting for problems */ xfs_sysctl_val_t syncd_timer; /* Interval between xfssyncd wakeups */ xfs_sysctl_val_t stats_clear; /* Reset all XFS statistics to zero. */ - xfs_sysctl_val_t probe_dmapi; /* probe for DMAPI module on mount. */ - xfs_sysctl_val_t probe_ioops; /* probe for an IO module on mount. */ - xfs_sysctl_val_t probe_quota; /* probe for quota module on mount. */ xfs_sysctl_val_t inherit_sync; /* Inherit the "sync" inode flag. */ xfs_sysctl_val_t inherit_nodump;/* Inherit the "nodump" inode flag. */ xfs_sysctl_val_t inherit_noatim;/* Inherit the "noatime" inode flag. */ @@ -77,9 +74,9 @@ enum { XFS_PANIC_MASK = 6, XFS_ERRLEVEL = 7, XFS_SYNCD_TIMER = 8, - XFS_PROBE_DMAPI = 9, - XFS_PROBE_IOOPS = 10, - XFS_PROBE_QUOTA = 11, + /* XFS_PROBE_DMAPI = 9, */ + /* XFS_PROBE_IOOPS = 10, */ + /* XFS_PROBE_QUOTA = 11, */ XFS_STATS_CLEAR = 12, XFS_INHERIT_SYNC = 13, XFS_INHERIT_NODUMP = 14, From owner-xfs@oss.sgi.com Sun Sep 2 15:49:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 15:49:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l82Mn24p018419 for ; Sun, 2 Sep 2007 15:49:03 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA18993; Mon, 3 Sep 2007 08:48:57 +1000 Message-ID: <46DB3E4B.3030106@sgi.com> Date: Mon, 03 Sep 2007 08:50:51 +1000 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: David Chinner CC: Mark Goodwin , Lachlan McIlroy , Timothy Shimmin , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes References: <46D6279F.40601@sgi.com> <46D6480F.4040307@sgi.com> <46D64CAD.6050705@sgi.com> <46D67FE6.20205@sgi.com> <46D68510.1020404@sgi.com> <46D77B79.3040104@sgi.com> <46D792A1.7030308@sgi.com> <20070831154822.GD734179@sgi.com> In-Reply-To: <20070831154822.GD734179@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12746 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 David Chinner wrote: > An unlinked inode is only detectable by the mode parameter being zero. > The rest of the inode will look valid. What about the nlink count? Can't we detect unlinked inode by nlink == 0? Regards, Vlad From owner-xfs@oss.sgi.com Sun Sep 2 15:59:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 15:59:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l82MxG4p019923 for ; Sun, 2 Sep 2007 15:59:18 -0700 Received: from edge.yarra.acx (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 5911092C390; Mon, 3 Sep 2007 08:59:16 +1000 (EST) Subject: Re: ZFS, XFS, and EXT4 compared From: Nathan Scott Reply-To: nscott@aconex.com To: Federico Sevilla III Cc: xfs@oss.sgi.com In-Reply-To: <1188659243.4430.8.camel@auctoritas.fs3.ph> References: <1188454611.23311.13.camel@toonses.gghcwest.com> <1188457666.24970.94.camel@edge.yarra.acx> <20070830132002.GA4086@infradead.org> <1188513751.24970.109.camel@edge.yarra.acx> <1188659243.4430.8.camel@auctoritas.fs3.ph> Content-Type: text/plain Organization: Aconex Date: Mon, 03 Sep 2007 09:00:33 +1000 Message-Id: <1188774034.24970.123.camel@edge.yarra.acx> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 12747 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Sat, 2007-09-01 at 23:07 +0800, Federico Sevilla III wrote: > > > Am I reading the thread correctly that even with this message showing > up, I still need to mount with nobarrier explicitly to improve > performance? > No, thats not needed if XFS explicitly says its not using barriers. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Sep 2 19:44:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 19:44:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l832iA4p030748 for ; Sun, 2 Sep 2007 19:44:15 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA28800; Mon, 3 Sep 2007 12:44:04 +1000 Message-ID: <46DB7586.7040309@sgi.com> Date: Mon, 03 Sep 2007 12:46:30 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Christian Kujau CC: xfs@oss.sgi.com Subject: Re: lockdep annotations? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12748 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a locking inversion between the iolock and iprune_mutex. I hadn't seen this one before. Was your system running low on memory at the time? We can't drop the iolock in the write path so we'll have to avoid acquiring the iolock in xfs_ireclaim() which means we'll need another way to synchronise with xfs_sync_inodes(). Thanks for pointing this one out. Lachlan Christian Kujau wrote: > Hi, > > I try to follow -rc kernels and just upgraded to 2.6.23-rc5 and I still > see: "INFO: possible circular locking dependency detected". Out of > curiosity: (when) will these warnings be addressed? I mean, suits me for > enabling CONFIG_LOCKDEP in the first place, but the only warnings I get > is still xfs :) > > FWIW, full log is here: > http://nerdbynature.de/bits/2.6.23-rc5/messages_2.6.23-rc5 > > Thanks, > Christian. From owner-xfs@oss.sgi.com Sun Sep 2 20:04:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 20:04:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.2.0-pre1-r499012 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 l8334n4p002820 for ; Sun, 2 Sep 2007 20:04:52 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA29727; Mon, 3 Sep 2007 13:04:46 +1000 Message-ID: <46DB7A60.4050203@sgi.com> Date: Mon, 03 Sep 2007 13:07:12 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: xfs-dev CC: xfs-oss Subject: [PATCH] ensure file size is logged on synchronous writes Content-Type: multipart/mixed; boundary="------------060907010105080008020904" X-archive-position: 12749 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------060907010105080008020904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Synchronous writes currently log inode changes before syncing pages to disk. Since the file size is updated on I/O completion we wont be writing out the updated file size and if we crash the file will have the wrong size. This change moves the logging after the syncing of the pages to ensure we log the correct file size. Lachlan --------------060907010105080008020904 Content-Type: text/x-patch; name="xfs_write.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_write.diff" --- fs/xfs/linux-2.6/xfs_lrw.c_1.266 2007-08-30 17:38:53.000000000 +1000 +++ fs/xfs/linux-2.6/xfs_lrw.c 2007-08-31 15:38:49.000000000 +1000 @@ -895,20 +895,19 @@ retry: /* Handle various SYNC-type writes */ if ((file->f_flags & O_SYNC) || IS_SYNC(inode)) { - error = xfs_write_sync_logforce(mp, xip); - if (error) - goto out_unlock_internal; - + int error2; xfs_rwunlock(xip, locktype); if (need_i_mutex) mutex_unlock(&inode->i_mutex); - - error = sync_page_range(inode, mapping, pos, ret); + error2 = sync_page_range(inode, mapping, pos, ret); if (!error) - error = -ret; + error = error2; if (need_i_mutex) mutex_lock(&inode->i_mutex); xfs_rwlock(xip, locktype); + error2 = xfs_write_sync_logforce(mp, xip); + if (!error) + error = error2; } out_unlock_internal: --------------060907010105080008020904-- From owner-xfs@oss.sgi.com Sun Sep 2 23:33:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 23:33:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l836Xe4p005069 for ; Sun, 2 Sep 2007 23:33:43 -0700 Received: from [89.54.161.50] (helo=[192.168.178.25]) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IS5VC-00060q-G0; Mon, 03 Sep 2007 08:33:38 +0200 Date: Mon, 3 Sep 2007 08:33:36 +0200 (CEST) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: Lachlan McIlroy cc: xfs@oss.sgi.com Subject: Re: lockdep annotations? In-Reply-To: <46DB7586.7040309@sgi.com> Message-ID: References: <46DB7586.7040309@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed X-archive-position: 12750 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Mon, 3 Sep 2007, Lachlan McIlroy wrote: > This is a locking inversion between the iolock and iprune_mutex. I > hadn't seen this one before. Was your system running low on memory > at the time? Usually, this might be the case, as lockdep reports only once and when it does it's usually the morning after the last reboot, when a script runs the backups (so the box is under load, probably memory pressure involved). However, this time I don't remember memory consuming tasks running. Unfortunately, I cannot reproduce this yet... thanks for your explanations, Christian. -- BOFH excuse #321: Scheduled global CPU outage From owner-xfs@oss.sgi.com Mon Sep 3 01:49:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 01:49:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l838nJ4p004199 for ; Mon, 3 Sep 2007 01:49:22 -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 SAA14150; Mon, 3 Sep 2007 18:49:18 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l838nHdD4050522; Mon, 3 Sep 2007 18:49:18 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l838nGbV4050449; Mon, 3 Sep 2007 18:49:16 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 3 Sep 2007 18:49:16 +1000 From: David Chinner To: Vlad Apostolov Cc: David Chinner , Mark Goodwin , Lachlan McIlroy , Timothy Shimmin , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes Message-ID: <20070903084916.GG995458@sgi.com> References: <46D6279F.40601@sgi.com> <46D6480F.4040307@sgi.com> <46D64CAD.6050705@sgi.com> <46D67FE6.20205@sgi.com> <46D68510.1020404@sgi.com> <46D77B79.3040104@sgi.com> <46D792A1.7030308@sgi.com> <20070831154822.GD734179@sgi.com> <46DB3E4B.3030106@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DB3E4B.3030106@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12751 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Sep 03, 2007 at 08:50:51AM +1000, Vlad Apostolov wrote: > David Chinner wrote: > >An unlinked inode is only detectable by the mode parameter being zero. > >The rest of the inode will look valid. > What about the nlink count? Can't we detect unlinked inode by nlink == 0? A file that is open but unlinked must still remain valid on disk until the last reference goes away. This inode will have a link count of zero, but it is still a valid, referenced inode. Hence detection of an inode with a link count of zero does not mean it has been fully removed yet - a zero link count and a non-zero mode indicates the inode should be onthe unlinked inode list. See xfs_ifree() - the mode is zeroed only after the inode has been pulled from the AGI unlinked list and marked free in the AGI btree. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Sep 3 02:01:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 02:01:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8391C4p007258 for ; Mon, 3 Sep 2007 02:01:14 -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 TAA14675; Mon, 3 Sep 2007 19:01:05 +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 l83914dD4027517; Mon, 3 Sep 2007 19:01:05 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l83913HY4059549; Mon, 3 Sep 2007 19:01:03 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 3 Sep 2007 19:01:03 +1000 From: David Chinner To: Lachlan McIlroy Cc: Christian Kujau , xfs@oss.sgi.com Subject: Re: lockdep annotations? Message-ID: <20070903090103.GG734179@sgi.com> References: <46DB7586.7040309@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DB7586.7040309@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12752 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Sep 03, 2007 at 12:46:30PM +1000, Lachlan McIlroy wrote: > This is a locking inversion between the iolock and iprune_mutex. I > hadn't seen this one before. Was your system running low on memory > at the time? > > We can't drop the iolock in the write path so we'll have to avoid > acquiring the iolock in xfs_ireclaim() which means we'll need another > way to synchronise with xfs_sync_inodes(). I don't think a deadlock exists here - we have to be going through memory reclaim to hit this inversion, so the only place that we can deadlock is if we are holding the iprune_mutex across a memory allocation. I don't think we do that.... Not to mention that the inode we hold the iolock on won't be on the inode free list so we won't ever try to lock it during reclaim, either. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Sep 3 02:20:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 02:20:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.pawisda.de (mail.pawisda.de [213.157.4.156]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l839Ko4p011542 for ; Mon, 3 Sep 2007 02:20:51 -0700 Received: from localhost (localhost.intra.frontsite.de [127.0.0.1]) by mail.pawisda.de (Postfix) with ESMTP id 96955E7BD for ; Mon, 3 Sep 2007 11:20:51 +0200 (CEST) Received: from mail.pawisda.de ([127.0.0.1]) by localhost (ndb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24959-04 for ; Mon, 3 Sep 2007 11:20:40 +0200 (CEST) Received: from [192.168.51.2] (lw-pc002.intra.frontsite.de [192.168.51.2]) by mail.pawisda.de (Postfix) with ESMTP id 29277BE7E for ; Mon, 3 Sep 2007 11:20:40 +0200 (CEST) Message-ID: <46DBD1E7.4030701@linworks.de> Date: Mon, 03 Sep 2007 11:20:39 +0200 From: Ruben Porras User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: [PATCH] Implement ioctl to mark AGs as "don't use/use" References: <1182939325.5313.12.camel@localhost> <20070628045049.GF989688@sgi.com> <46838CAE.9030808@linworks.de> <20070629005417.GF31489@sgi.com> In-Reply-To: <20070629005417.GF31489@sgi.com> Content-Type: multipart/mixed; boundary="------------020905060609070803010108" X-Virus-Scanned: by amavisd-new at pawisda.de X-archive-position: 12753 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ruben.porras@linworks.de Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------020905060609070803010108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit David Chinner wrote: > OOC, do you have any test code for this? xfs_io would be the tool to > teach this ioctl to.... > I've implemented this on xfs_io, and tested, and it works :) Attached are the modifications needed to the xfsprogs source tree in form of a diff against the CVS tree. In a short time all the patches that I submitted will be available together under an url, so that they are not scattered across the mailing list. -- Rubén Porras LinWorks GmbH --------------020905060609070803010108 Content-Type: text/x-patch; name="xfsprogs.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfsprogs.diff" diff -rNu xfs-cmds/xfsprogs/include/xfs_ag.h /home/ldap/campo/xfs-cmds/xfsprogs/include/xfs_ag.h --- xfs-cmds/xfsprogs/include/xfs_ag.h 2007-05-22 17:59:41.000000000 +0200 +++ /home/ldap/campo/xfs-cmds/xfsprogs/include/xfs_ag.h 2007-08-31 14:08:51.975160695 +0200 @@ -69,6 +69,7 @@ __be32 agf_freeblks; /* total free blocks */ __be32 agf_longest; /* longest free space */ __be32 agf_btreeblks; /* # of blocks held in AGF btrees */ + __be32 agf_flags; /* persistent AG state flags */ } xfs_agf_t; #define XFS_AGF_MAGICNUM 0x00000001 @@ -83,7 +84,8 @@ #define XFS_AGF_FREEBLKS 0x00000200 #define XFS_AGF_LONGEST 0x00000400 #define XFS_AGF_BTREEBLKS 0x00000800 -#define XFS_AGF_NUM_BITS 12 +#define XFS_AGF_FLAGS 0x00001000 +#define XFS_AGF_NUM_BITS 13 #define XFS_AGF_ALL_BITS ((1 << XFS_AGF_NUM_BITS) - 1) /* disk block (xfs_daddr_t) in the AG */ @@ -196,8 +198,17 @@ lock_t pagb_lock; /* lock for pagb_list */ #endif xfs_perag_busy_t *pagb_list; /* unstable blocks */ + __u32 pagf_flags; /* persistent AG state flags */ } xfs_perag_t; +typedef struct xfs_ioc_agflags +{ + xfs_agnumber_t ag; + __u32 flags; +} xfs_ioc_agflags_t; + +#define XFS_AGF_FLAGS_ALLOC_DENY (1<<0) + #define XFS_AG_MAXLEVELS(mp) ((mp)->m_ag_maxlevels) #define XFS_MIN_FREELIST_RAW(bl,cl,mp) \ (MIN(bl + 1, XFS_AG_MAXLEVELS(mp)) + MIN(cl + 1, XFS_AG_MAXLEVELS(mp))) diff -rNu xfs-cmds/xfsprogs/include/xfs_fs.h /home/ldap/campo/xfs-cmds/xfsprogs/include/xfs_fs.h --- xfs-cmds/xfsprogs/include/xfs_fs.h 2007-06-28 18:00:13.000000000 +0200 +++ /home/ldap/campo/xfs-cmds/xfsprogs/include/xfs_fs.h 2007-08-31 15:19:21.107148402 +0200 @@ -499,6 +499,8 @@ #define XFS_IOC_ATTRMULTI_BY_HANDLE _IOW ('X', 123, struct xfs_fsop_attrmulti_handlereq) #define XFS_IOC_FSGEOMETRY _IOR ('X', 124, struct xfs_fsop_geom) #define XFS_IOC_GOINGDOWN _IOR ('X', 125, __uint32_t) +#define XFS_IOC_GET_AGF_FLAGS _IOWR('X', 126, struct xfs_ioc_agflags) +#define XFS_IOC_SET_AGF_FLAGS _IOW ('X', 127, struct xfs_ioc_agflags) /* XFS_IOC_GETFSUUID ---------- deprecated 140 */ diff -rNu xfs-cmds/xfsprogs/io/agflags.c /home/ldap/campo/xfs-cmds/xfsprogs/io/agflags.c --- xfs-cmds/xfsprogs/io/agflags.c 1970-01-01 01:00:00.000000000 +0100 +++ /home/ldap/campo/xfs-cmds/xfsprogs/io/agflags.c 2007-08-31 13:56:48.861921728 +0200 @@ -0,0 +1,126 @@ + /* + * Copyright (c) 2007 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 +#include +#include +#include "init.h" +#include "io.h" + +static cmdinfo_t agflags_cmd; + +static void +agflags_help(void) +{ + printf(_( +"\n" +" get or set the diferent flags of a given AG\n" +"\n" +" Example:\n" +" 'agflags -d 0 -a 10' - unset the flag XFS_AGF_FLAGS_ALLOC_DENY from the AG\n" +" number 10\n" +"\n")); +} + +int +agflags_valid_ag( + int ag) +{ + xfs_fsop_geom_t fsgeo; + + if (ag < 0) + return 0; + + if (xfsctl(file->name, file->fd, XFS_IOC_FSGEOMETRY, &fsgeo) < 0) { + fprintf(stderr, _("%s: cannot get geometry of fs: %s\n"), + progname, strerror(errno)); + exitcode = 1; + return 0; + } + + return (ag <= fsgeo.agcount); +} + +int +agflags_f( + int argc, + char **argv) +{ + xfs_ioc_agflags_t ioc_flags; + unsigned int dflag; + int opt; + int set = 0; + + while ((opt = getopt(argc, argv, "d:a:")) != -1) { + switch (opt) { + case 'a': /* AG number. */ + ioc_flags.ag = atoi(optarg); + break; + case 'd': /* (Un)set XFS_AGF_FLAGS_ALLOC_DENY */ + dflag = atoi(optarg); + if (dflag != 0 && dflag != 1) + return command_usage(&agflags_cmd); + set = 1; + break; + default: /* ? */ + return command_usage(&agflags_cmd); + } + } + + if (! agflags_valid_ag(ioc_flags.ag)) { + fprintf(stderr, _("%s: AG number %d is not valid\n"), + progname, ioc_flags.ag); + return 0; + } + + if (set) + ioc_flags.flags = dflag; + + int ioctl; + ioctl = set ? XFS_IOC_SET_AGF_FLAGS : XFS_IOC_GET_AGF_FLAGS; + + if (xfsctl(file->name, file->fd, ioctl, &ioc_flags) < 0) { + fprintf(stderr, + _("%s: cannot %s flags %d on ag %d at %s: %s\n"), + progname, set ? "get" : "set", ioc_flags.flags, + ioc_flags.ag, file->name, strerror(errno)); + exitcode = 1; + return 0; + } + + return 0; +} + +void +agflags_init(void) +{ + agflags_cmd.name = _("agflags"); + agflags_cmd.cfunc = agflags_f; + agflags_cmd.argmin = 2; + agflags_cmd.argmax = 4; + agflags_cmd.flags = CMD_NOMAP_OK; + agflags_cmd.args = _("[-d 0|1] -a agno"); + agflags_cmd.oneline = _("Get or set the flags of an AG"); + agflags_cmd.help = agflags_help; + + if (expert) + add_command(&agflags_cmd); +} diff -rNu xfs-cmds/xfsprogs/io/init.c /home/ldap/campo/xfs-cmds/xfsprogs/io/init.c --- xfs-cmds/xfsprogs/io/init.c 2007-07-24 18:07:17.000000000 +0200 +++ /home/ldap/campo/xfs-cmds/xfsprogs/io/init.c 2007-08-31 14:10:19.697443490 +0200 @@ -54,6 +54,7 @@ static void init_commands(void) { + agflags_init(); attr_init(); bmap_init(); fadvise_init(); diff -rNu xfs-cmds/xfsprogs/io/Makefile /home/ldap/campo/xfs-cmds/xfsprogs/io/Makefile --- xfs-cmds/xfsprogs/io/Makefile 2006-06-17 08:12:23.000000000 +0200 +++ /home/ldap/campo/xfs-cmds/xfsprogs/io/Makefile 2007-08-13 10:42:08.536364577 +0200 @@ -10,7 +10,8 @@ HFILES = init.h io.h CFILES = init.c \ attr.c bmap.c file.c freeze.c fsync.c getrusage.c imap.c mmap.c \ - open.c parent.c pread.c prealloc.c pwrite.c shutdown.c truncate.c + open.c parent.c pread.c prealloc.c pwrite.c shutdown.c truncate.c \ + agflags.c LLDLIBS = $(LIBXCMD) $(LIBHANDLE) LTDEPENDENCIES = $(LIBXCMD) $(LIBHANDLE) diff -rNu xfs-cmds/xfsprogs/man/man8/xfs_io.8 /home/ldap/campo/xfs-cmds/xfsprogs/man/man8/xfs_io.8 --- xfs-cmds/xfsprogs/man/man8/xfs_io.8 2007-07-27 17:49:00.000000000 +0200 +++ /home/ldap/campo/xfs-cmds/xfsprogs/man/man8/xfs_io.8 2007-08-31 14:05:51.175595207 +0200 @@ -524,6 +524,15 @@ .IP .B [NOTE: Not currently operational on Linux.] .PD +.TP +.BR agflags " [ \-d " 0|1 " ] \-a " agno +This command get or set the different flags of the given AG. In moment the +only modifiable flag is XFS_AGF_FLAGS_ALLOC_DENY. +.RS 1.0i +.PD 0 +.TP 0.4i +.B \-d +0 or 1 to (un)set XFS_AGF_FLAGS_ALLOC_DENY. .SH SEE ALSO .BR mkfs.xfs (8), --------------020905060609070803010108-- From owner-xfs@oss.sgi.com Mon Sep 3 07:24:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 07:24:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l83EOL4p026025 for ; Mon, 3 Sep 2007 07:24:22 -0700 Received: by wa-out-1112.google.com with SMTP id k22so2006145waf for ; Mon, 03 Sep 2007 07:24:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aTi30IJKh0YgT+ExNbBZoaMsVt9qejvbMeGj8m9YhicBJinRnUwfhOUfKLr71GSdJY/qJDGMOzPWEARlJZtvWXwZUNMSWK/pngB4VntwIol7yYhP8LlllaiCNAdw4GvH/yWxkMMO4JgOlJv7/cyGtjclqBRahDm9wZH4muPad80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MKjkRmTzyAV7qIuNyZ6qGyAdazdIkEUvDo+5UFB+2g8lvSzLgGDNgOmOfPSccM5lA3gQvgRtSjClxEiZo3Rc4UoCeLVFvJcfpke8QSMvi8XG+uv6L6cf78Sb4rJPDRjctcWSojNqT+0HndKeUZ5/9+C27sXsCCo35cAUmCqmCrU= Received: by 10.115.90.1 with SMTP id s1mr3138733wal.1188829461758; Mon, 03 Sep 2007 07:24:21 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Mon, 3 Sep 2007 07:24:21 -0700 (PDT) Message-ID: <5d96567b0709030724w3098395bnbd511fa3819e5b22@mail.gmail.com> Date: Mon, 3 Sep 2007 17:24:21 +0300 From: Raz To: "David Chinner" Subject: Re: raid50 and 9TB volumes Cc: linux-xfs@oss.sgi.com In-Reply-To: <5d96567b0708070220u23c895ffk54849fca947b5100@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5d96567b0707160542t2144c382mbfe3da92f0990694@mail.gmail.com> <5d96567b0707160653m5951fac9v5a56bb4c92174d63@mail.gmail.com> <20070716221831.GE31489@sgi.com> <18076.1449.138328.66699@notabene.brown> <20070717001205.GI31489@sgi.com> <18076.4940.845633.149160@notabene.brown> <20070717005854.GL31489@sgi.com> <5d96567b0707222309y61480271xa8220a0b179764e0@mail.gmail.com> <20070724010105.GN31489@sgi.com> <5d96567b0708070220u23c895ffk54849fca947b5100@mail.gmail.com> X-archive-position: 12754 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: xfs Dave hello. What is the curret status of this problem ? If you recall , xfs in 32bit over 10 TB md device ( raid50 in this case) sees only 8TB ( and no more). The disks I am using are 750GB hitachi. kernel is 2.6.17. thank you raz On 8/7/07, Raz wrote: > On 7/24/07, David Chinner wrote: > > On Mon, Jul 23, 2007 at 09:09:03AM +0300, Raz wrote: > > > My QA to re-installed the system. same kernel, different results. now, > > > /proc/paritions > > > reports : > > > 9 1 5114281984 md1 > > > 9 2 5128001536 md2 > > > 9 3 10242281472 md3 > > > > > > blockdev --getsize64 /dev/md3 > > > 10488096227328 > > > > > > but xfs keeps on crashing. when formatting it ot 6.3 TB we're OK. when > > > letting xfs's mkfs choose the > > > > So at 6.3TB everything is ok. At what point does it start having > > problems? 6.4TB, 6.8TB, 8TB, 9TB? > over 8 TB. we checked several times. in 8.5 it crashes. > > I know Neil pointed out that you shouldn't have 10TB but closer to > > 7TB - is this true? > the drives are of 750 GB each. > > Cheers, > > > > Dave. > > -- > > Dave Chinner > > Principal Engineer > > SGI Australian Software Group > > > > > -- > Raz > -- Raz From owner-xfs@oss.sgi.com Mon Sep 3 12:28:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 12:28:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l83JSI4p009335 for ; Mon, 3 Sep 2007 12:28:20 -0700 Received: from [89.54.161.50] (helo=[192.168.178.25]) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ISH52-0003S2-DN for linux-xfs@oss.sgi.com; Mon, 03 Sep 2007 20:55:25 +0200 Date: Mon, 3 Sep 2007 20:55:19 +0200 (CEST) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: linux-xfs@oss.sgi.com Subject: Re: raid50 and 9TB volumes In-Reply-To: <5d96567b0709030724w3098395bnbd511fa3819e5b22@mail.gmail.com> Message-ID: References: <5d96567b0707160542t2144c382mbfe3da92f0990694@mail.gmail.com> <5d96567b0707160653m5951fac9v5a56bb4c92174d63@mail.gmail.com> <20070716221831.GE31489@sgi.com> <18076.1449.138328.66699@notabene.brown> <20070717001205.GI31489@sgi.com> <18076.4940.845633.149160@notabene.brown> <20070717005854.GL31489@sgi.com> <5d96567b0707222309y61480271xa8220a0b179764e0@mail.gmail.com> <20070724010105.GN31489@sgi.com> <5d96567b0708070220u23c895ffk54849fca947b5100@mail.gmail.com> <5d96567b0709030724w3098395bnbd511fa3819e5b22@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-archive-position: 12755 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Mon, 3 Sep 2007, Raz wrote: > What is the curret status of this problem ? If you recall , xfs in 32bit > over 10 TB md device ( raid50 in this case) sees only 8TB ( and no more). > The disks I am using are 750GB hitachi. > kernel is 2.6.17. dunno about this particular issue, but you meant "kernel 2.6.17.7 or higher", right? If not: http://oss.sgi.com/projects/xfs/faq.html#dir2 -- BOFH excuse #374: It's the InterNIC's fault. From owner-xfs@oss.sgi.com Mon Sep 3 17:49:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 17:49:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l840nO4p024507 for ; Mon, 3 Sep 2007 17:49:26 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22719; Tue, 4 Sep 2007 10:49:16 +1000 Message-ID: <46DCAC20.9080002@sgi.com> Date: Tue, 04 Sep 2007 10:51:44 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Chinner CC: Christian Kujau , xfs@oss.sgi.com Subject: Re: lockdep annotations? References: <46DB7586.7040309@sgi.com> <20070903090103.GG734179@sgi.com> In-Reply-To: <20070903090103.GG734179@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12756 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Mon, Sep 03, 2007 at 12:46:30PM +1000, Lachlan McIlroy wrote: >> This is a locking inversion between the iolock and iprune_mutex. I >> hadn't seen this one before. Was your system running low on memory >> at the time? >> >> We can't drop the iolock in the write path so we'll have to avoid >> acquiring the iolock in xfs_ireclaim() which means we'll need another >> way to synchronise with xfs_sync_inodes(). > > I don't think a deadlock exists here - we have to be going through > memory reclaim to hit this inversion, so the only place that we > can deadlock is if we are holding the iprune_mutex across a memory > allocation. I don't think we do that.... > > Not to mention that the inode we hold the iolock on won't be on the > inode free list so we won't ever try to lock it during reclaim, either. > Yep. This is just another case where we've confused lockdep. From owner-xfs@oss.sgi.com Mon Sep 3 19:50:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 19:50:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l842ot4p010319 for ; Mon, 3 Sep 2007 19:50:56 -0700 Received: from Liberator.local (sandeen.net [209.173.210.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id ED14518009C3F; Mon, 3 Sep 2007 21:50:55 -0500 (CDT) Message-ID: <46DCC80F.8030000@sandeen.net> Date: Mon, 03 Sep 2007 21:50:55 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christian Kujau CC: linux-xfs@oss.sgi.com Subject: Re: raid50 and 9TB volumes References: <5d96567b0707160542t2144c382mbfe3da92f0990694@mail.gmail.com> <5d96567b0707160653m5951fac9v5a56bb4c92174d63@mail.gmail.com> <20070716221831.GE31489@sgi.com> <18076.1449.138328.66699@notabene.brown> <20070717001205.GI31489@sgi.com> <18076.4940.845633.149160@notabene.brown> <20070717005854.GL31489@sgi.com> <5d96567b0707222309y61480271xa8220a0b179764e0@mail.gmail.com> <20070724010105.GN31489@sgi.com> <5d96567b0708070220u23c895ffk54849fca947b5100@mail.gmail.com> <5d96567b0709030724w3098395bnbd511fa3819e5b22@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12757 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 Christian Kujau wrote: > On Mon, 3 Sep 2007, Raz wrote: >> What is the curret status of this problem ? If you recall , xfs in 32bit >> over 10 TB md device ( raid50 in this case) sees only 8TB ( and no more). >> The disks I am using are 750GB hitachi. >> kernel is 2.6.17. > > dunno about this particular issue, but you meant "kernel 2.6.17.7 or > higher", right? If not: http://oss.sgi.com/projects/xfs/faq.html#dir2 That shouldn't be affected by volume size. Raz, are you certain that the MD volume is in good shape at this point, after Neil's questions? If it's something you can test on, I'd suggest getting lmdd and writing a pattern directly to the block device, spanning the 8T point, then go read it back & double check that all is well. XFS certainly has been tested at 8T and above; if I had to bet on it, I'd bet at a problem in another layer, or the configuration. -Eric From owner-xfs@oss.sgi.com Tue Sep 4 05:23:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 05:23:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_33, J_CHICKENPOX_62 autolearn=no version=3.2.0-pre1-r499012 Received: from bay0-omc2-s5.bay0.hotmail.com (bay0-omc2-s5.bay0.hotmail.com [65.54.246.141]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l84CNU4p020724 for ; Tue, 4 Sep 2007 05:23:31 -0700 Received: from hotmail.com ([65.54.174.78]) by bay0-omc2-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 4 Sep 2007 05:23:31 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Sep 2007 05:23:30 -0700 Message-ID: Received: from 85.36.106.214 by BAY103-DAV6.phx.gbl with DAV; Tue, 04 Sep 2007 12:23:27 +0000 X-Originating-IP: [85.36.106.214] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: "Christoph Lameter" Cc: , "David Chinner" , , "Marco Berizzi" References: Subject: Re: kernel BUG at mm/slab.c:2980 (was Re: [] xfs_bmap_search_multi_extents+0x6f/0xe0) Date: Tue, 4 Sep 2007 14:22:04 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 04 Sep 2007 12:23:30.0884 (UTC) FILETIME=[67773040:01C7EEEE] X-archive-position: 12758 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs Christoph Lameter wrote: > Could you try this with the SLUB allocator and then boot with > "slub_debug"? Hi Christoph, I have upgraded to 2.6.22.5 and I have selected the SLUB. I have also added append=slub_debug to lilo.conf After a week uptime I got this error. I hope it will be useful for you. Linux version 2.6.22.5 (root@Mimosa) (gcc version 3.3.5) #1 Mon Aug 27 16:57:18 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000dc000 - 00000000000e0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000a000000 (usable) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 160MB LOWMEM available. Entering add_active_range(0, 0, 40960) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 40960 early_node_map[1] active PFN ranges 0: 0 -> 40960 On node 0 totalpages: 40960 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 288 pages used for memmap Normal zone: 36576 pages, LIFO batch:7 DMI 2.1 present. Allocating PCI resources starting at 10000000 (gap: 0a000000:f5ff0000) Built 1 zonelists. Total pages: 40640 Kernel command line: auto BOOT_IMAGE=Linux ro root=301 slub_debug Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to ffffd000 (01141000) Enabling fast FPU save and restore... done. Initializing CPU#0 PID hash table entries: 1024 (order: 10, 4096 bytes) Detected 267.281 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 158956k/163840k available (1975k kernel code, 4452k reserved, 628k data, 160k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb7000 - 0xfffff000 ( 288 kB) vmalloc : 0xca800000 - 0xfffb5000 ( 855 MB) lowmem : 0xc0000000 - 0xca000000 ( 160 MB) .init : 0xc038e000 - 0xc03b6000 ( 160 kB) .data : 0xc02edd86 - 0xc038afa0 ( 628 kB) .text : 0xc0100000 - 0xc02edd86 (1975 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine.. 535.19 BogoMIPS (lpj=1070387) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0183f9ff 00000000 00000000 00000000 00000000 00000000 00000000 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: After all inits, caps: 0183f9ff 00000000 00000000 00000040 00000000 00000000 00000000 Compat vDSO mapped to ffffe000. CPU: Intel Celeron (Covington) stepping 00 Checking 'hlt' instruction... OK. ACPI: Core revision 20070126 ACPI Exception (tbxface-0618): AE_NO_ACPI_TABLES, While loading namespace from ACPI tables [20070126] ACPI: Unable to load the System Description Tables NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfda61, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) * Found PM-Timer Bug on the chipset. Due to workarounds for a bug, * this clock source is slow. Consider trying other clock sources PCI quirk: region 6100-613f claimed by PIIX4 ACPI PCI quirk: region 5f00-5f0f claimed by PIIX4 SMB PCI: Using IRQ router PIIX/ICH [8086/7110] at 0000:00:07.0 Time: tsc clocksource has been installed. PCI: Bridge: 0000:00:01.0 IO window: b000-bfff MEM window: efe00000-efefffff PREFETCH window: e5c00000-e7cfffff NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered SGI XFS with no debug enabled io scheduler noop registered io scheduler deadline registered (default) Limiting direct PCI/PCI transfers. Boot video device is 0000:01:00.0 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller at PCI slot 0000:00:07.1 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: QUANTUM FIREBALL EX3.2A, ATA DISK drive hda: selected mode 0x42 ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: CRD-8160B, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 6306048 sectors (3228 MB) w/418KiB Cache, CHS=6256/16/63, UDMA(33) hda: cache flushes not supported hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 > PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice nf_conntrack version 0.5.0 (1280 buckets, 10240 max) ip_tables: (C) 2000-2006 Netfilter Core Team TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Using IPI Shortcut mode input: AT Translated Set 2 keyboard as /class/input/input0 Filesystem "hda1": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda1 Ending clean XFS mount for filesystem: hda1 VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 160k freed Adding 330584k swap on /dev/hda9. Priority:-1 extents:1 across:330584k Filesystem "hda1": Disabling barriers, not supported by the underlying device Filesystem "hda1": Disabling barriers, not supported by the underlying device PCI: setting IRQ 10 as level-triggered PCI: Found IRQ 10 for device 0000:00:09.0 3c59x: Donald Becker and others. 0000:00:09.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001dc00. PCI: setting IRQ 11 as level-triggered PCI: Found IRQ 11 for device 0000:00:0a.0 0000:00:0a.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001da00. PCI: setting IRQ 9 as level-triggered PCI: Found IRQ 9 for device 0000:00:0b.0 PCI: Sharing IRQ 9 with 0000:00:07.2 0000:00:0b.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001d800. Filesystem "hda5": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda5 Ending clean XFS mount for filesystem: hda5 Filesystem "hda6": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda6 Ending clean XFS mount for filesystem: hda6 Filesystem "hda7": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda7 Ending clean XFS mount for filesystem: hda7 Filesystem "hda8": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda8 Ending clean XFS mount for filesystem: hda8 eth0: setting full-duplex. eth1: setting full-duplex. eth2: setting full-duplex. swapper: page allocation failure. order:2, mode:0x4020 [] __alloc_pages+0x1ed/0x2e0 [] allocate_slab+0x4b/0x90 [] new_slab+0x32/0x150 [] __slab_alloc+0xcb/0x120 [] __slab_alloc+0x79/0x120 [] tcp_collapse+0x113/0x3b0 [] __kmalloc_track_caller+0x75/0x80 [] tcp_collapse+0x113/0x3b0 [] __alloc_skb+0x4e/0x100 [] tcp_collapse+0x113/0x3b0 [] tcp_prune_queue+0x7d/0x180 [] tcp_data_queue+0x2b9/0x710 [] ipt_do_table+0x271/0x360 [] tcp_rcv_established+0x1cb/0x630 [] tcp_v4_do_rcv+0xe3/0xf0 [] tcp_v4_rcv+0x67f/0x800 [] ip_local_deliver_finish+0x0/0x1a0 [] nf_hook_slow+0x66/0xe0 [] ip_local_deliver+0x11c/0x230 [] ip_local_deliver_finish+0x0/0x1a0 [] ip_rcv+0x232/0x4d0 [] ip_rcv_finish+0x0/0x2a0 [] do_IRQ+0x3e/0x80 [] netif_receive_skb+0x207/0x290 [] process_backlog+0x77/0xf0 [] net_rx_action+0x6c/0xf0 [] __do_softirq+0x74/0x90 [] do_softirq+0x26/0x30 [] do_IRQ+0x3e/0x80 [] common_interrupt+0x23/0x28 [] default_idle+0x0/0x40 [] default_idle+0x27/0x40 [] cpu_idle+0x5c/0x70 [] start_kernel+0x17c/0x1c0 [] unknown_bootoption+0x0/0x1a0 ======================= Mem-info: DMA per-cpu: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Normal per-cpu: CPU 0: Hot: hi: 42, btch: 7 usd: 4 Cold: hi: 14, btch: 3 usd: 11 Active:29564 inactive:4492 dirty:418 writeback:0 unstable:0 free:845 slab:4194 mapped:901 pagetables:210 bounce:0 DMA free:632kB min:160kB low:200kB high:240kB active:9136kB inactive:1888kB present:16256kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 142 Normal free:2748kB min:1448kB low:1808kB high:2172kB active:109120kB inactive:16080kB present:146304kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 DMA: 48*4kB 3*8kB 0*16kB 1*32kB 0*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 632kB Normal: 571*4kB 40*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2748kB Swap cache: add 0, delete 0, find 0/0, race 0+0 Free swap = 330584kB Total swap = 330584kB Free swap: 330584kB 40960 pages of RAM 0 pages of HIGHMEM 1170 reserved pages 18768 pages shared 0 pages swap cached 418 pages dirty 0 pages writeback 901 pages mapped 4194 pages slab 210 pages pagetables From owner-xfs@oss.sgi.com Tue Sep 4 10:23:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 10:23:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l84HN34p009016 for ; Tue, 4 Sep 2007 10:23:03 -0700 Received: from schroedinger.engr.sgi.com (schroedinger.engr.sgi.com [150.166.1.51]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 8D5D59088B for ; Tue, 4 Sep 2007 10:23:01 -0700 (PDT) Received: from clameter (helo=localhost) by schroedinger.engr.sgi.com with local-esmtp (Exim 3.36 #1 (Debian)) id 1ISbjW-0001Vr-00; Tue, 04 Sep 2007 09:58:34 -0700 Date: Tue, 4 Sep 2007 09:58:34 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Marco Berizzi cc: linux-kernel@vger.kernel.org, David Chinner , xfs@oss.sgi.com, mel@skynet.ie Subject: Re: kernel BUG at mm/slab.c:2980 (was Re: [] xfs_bmap_search_multi_extents+0x6f/0xe0) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 12759 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: clameter@sgi.com Precedence: bulk X-list: xfs On Tue, 4 Sep 2007, Marco Berizzi wrote: > After a week uptime I got this error. I hope it > will be useful for you. Yes indeed but this is a different type of failure. Looks like a higher allocation failure in the networking code. Someone created objects that required an order 2 allocations that failed. > SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Slub is restricted to order 0 and 1 allocs. > PREFETCH window: e5c00000-e7cfffff > NET: Registered protocol family 2 > IP route cache hash table entries: 2048 (order: 1, 8192 bytes) > TCP established hash table entries: 8192 (order: 4, 65536 bytes) > TCP bind hash table entries: 8192 (order: 3, 32768 bytes) Hmmmm. > eth2: setting full-duplex. > swapper: page allocation failure. order:2, mode:0x4020 > [] __alloc_pages+0x1ed/0x2e0 > [] allocate_slab+0x4b/0x90 > [] new_slab+0x32/0x150 > [] __slab_alloc+0xcb/0x120 > [] __slab_alloc+0x79/0x120 > [] tcp_collapse+0x113/0x3b0 tcp_collapse? This is due to a network configuration that required an order 2 kmalloc block. Jumbo frames? From owner-xfs@oss.sgi.com Tue Sep 4 16:49:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 16:49:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l84NnX4p002713 for ; Tue, 4 Sep 2007 16:49:36 -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 JAA18793; Wed, 5 Sep 2007 09:49:32 +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 l84NnTdD6314321; Wed, 5 Sep 2007 09:49:32 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l84NnQQc6315667; Wed, 5 Sep 2007 09:49:26 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 5 Sep 2007 09:49:26 +1000 From: David Chinner To: Shailendra Tripathi Cc: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes Message-ID: <20070904234926.GI734179@sgi.com> References: <46D6279F.40601@sgi.com> <46DDE4A2.1070204@agami.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DDE4A2.1070204@agami.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12760 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Sep 04, 2007 at 04:05:06PM -0700, Shailendra Tripathi wrote: > Hi, > Can someone explain how not checking the flushiter can losse > filesize updates. > Let me the take the case mentioned here in the fix statement: > > a. Clustered inode create - flush iter - X( 0) > b. size update --> flush iter --> Y > > X and Y will always hold as: X <= Y, that is, it is not possible to have > X >Y (unless size update is non -transactional. As far as I know, size > update is always transactional.) Size updates are not transactional. They are accidentally logged in other transactions (e.g. truncates) but size updates due to data writes are never logged. When we write an inode, we take the latest in memory size and write it to disk without logging that change so we can't rely on log recovery to get it right simply by replaying transactions. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Sep 4 16:51:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 16:51:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l84Npf4p003072 for ; Tue, 4 Sep 2007 16:51:44 -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 JAA18881; Wed, 5 Sep 2007 09:51:41 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l84NpedD6315321; Wed, 5 Sep 2007 09:51:40 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l84NpdPE6315910; Wed, 5 Sep 2007 09:51:39 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 5 Sep 2007 09:51:39 +1000 From: David Chinner To: David Chinner Cc: Shailendra Tripathi , Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes Message-ID: <20070904235139.GJ734179@sgi.com> References: <46D6279F.40601@sgi.com> <46DDE4A2.1070204@agami.com> <20070904234926.GI734179@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070904234926.GI734179@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12761 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Sep 05, 2007 at 09:49:26AM +1000, David Chinner wrote: > On Tue, Sep 04, 2007 at 04:05:06PM -0700, Shailendra Tripathi wrote: > > Hi, > > Can someone explain how not checking the flushiter can losse > > filesize updates. > > Let me the take the case mentioned here in the fix statement: > > > > a. Clustered inode create - flush iter - X( 0) > > b. size update --> flush iter --> Y > > > > X and Y will always hold as: X <= Y, that is, it is not possible to have > > X >Y (unless size update is non -transactional. As far as I know, size > > update is always transactional.) > > Size updates are not transactional. They are accidentally logged in s/accidentally/intentionally/ > other transactions (e.g. truncates) but size updates due to data > writes are never logged. When we write an inode, we take the latest > in memory size and write it to disk without logging that change > so we can't rely on log recovery to get it right simply by replaying > transactions. > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Sep 4 17:14:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 17:14:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_20,RDNS_DYNAMIC autolearn=no version=3.2.0-pre1-r499012 Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l850Ej4p006337 for ; Tue, 4 Sep 2007 17:14:48 -0700 Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id l84N4ldm017111; Tue, 4 Sep 2007 16:04:50 -0700 Received: from [10.123.1.84] (timf-64.agami.com [10.123.1.84]) (authenticated bits=0) by agami.com (8.12.11/8.12.11) with ESMTP id l84N4iVQ027598; Tue, 4 Sep 2007 16:04:44 -0700 Message-ID: <46DDE4A2.1070204@agami.com> Date: Tue, 04 Sep 2007 16:05:06 -0700 From: Shailendra Tripathi User-Agent: Thunderbird 1.5.0.13 (X11/20070809) MIME-Version: 1.0 To: Lachlan McIlroy CC: xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes References: <46D6279F.40601@sgi.com> In-Reply-To: <46D6279F.40601@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 192.168.168.13 X-archive-position: 12762 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stripathi@agami.com Precedence: bulk X-list: xfs Hi, Can someone explain how not checking the flushiter can losse filesize updates. Let me the take the case mentioned here in the fix statement: a. Clustered inode create - flush iter - X( 0) b. size update --> flush iter --> Y X and Y will always hold as: X <= Y, that is, it is not possible to have X >Y (unless size update is non -transactional. As far as I know, size update is always transactional.) There are 2 cases here: a) log of Y reached to the disk --> 1) inode with flush iter was reached 2) inode didn't make. b) log of Y didn't reach the disk --> flush_iter Y should have never reached disk In none of cases, I can see the possibility that size update can be lost becuase of replaying of the logs in the sequential order. If Log of Y didn't reach, does it not make sense to have the flush_iter and size correctly set to the last known transaction on the disk. To me, it appears unsafe to do as the inode state will not match the state of the last known transaction after recovery. Regards, Shailendra Lachlan McIlroy wrote: > Log replay of clustered inodes currently ignores the flushiter > field in the inode that is used to determine if the on-disk inode > is more up to date than the copy in the log. As a result during > log replay the newer inode is being overwritten with an older > version and file size updates are being lost. > > I haven't handled the case of the flushiter counter overflowing > but that shouldn't be a problem in this case. The log buffer > contains newly created inodes so their flushiter values will be 0 > and the on-disk inodes should not be much greater. > > Lachlan > ------------------------------------------------------------------------ > > --- fs/xfs/xfs_log_recover.c_1.322 2007-08-27 17:45:45.000000000 +1000 > +++ fs/xfs/xfs_log_recover.c 2007-08-30 11:50:44.000000000 +1000 > @@ -1866,6 +1866,27 @@ xlog_recover_do_inode_buffer( > } > > /* > + * Check if we need to recover an inode from a buffer > + */ > +int > +xfs_recover_inode( > + char *dest, > + char *src) > +{ > + xfs_dinode_t *dip = (xfs_dinode_t *)dest; > + xfs_dinode_t *dilp = (xfs_dinode_t*)src; > + > + if ((be16_to_cpu(dip->di_core.di_magic) == XFS_DINODE_MAGIC) && > + (be16_to_cpu(dilp->di_core.di_magic) == XFS_DINODE_MAGIC) && > + (be16_to_cpu(dilp->di_core.di_flushiter) < > + be16_to_cpu(dip->di_core.di_flushiter))) { > + return 1; > + } > + > + return 0; > +} > + > +/* > * Perform a 'normal' buffer recovery. Each logged region of the > * buffer should be copied over the corresponding region in the > * given buffer. The bitmap in the buf log format structure indicates > @@ -1917,6 +1938,13 @@ xlog_recover_do_reg_buffer( > -1, 0, XFS_QMOPT_DOWARN, > "dquot_buf_recover"); > } > + /* > + * Sanity check if this is an inode buffer. > + */ > + if (!error) > + error = xfs_recover_inode(xfs_buf_offset(bp, > + (uint)bit << XFS_BLI_SHIFT), > + item->ri_buf[i].i_addr); > if (!error) > memcpy(xfs_buf_offset(bp, > (uint)bit << XFS_BLI_SHIFT), /* dest */ > From owner-xfs@oss.sgi.com Tue Sep 4 18:19:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 18:19:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_40 autolearn=ham version=3.2.0-pre1-r499012 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 l851Jn4p015559 for ; Tue, 4 Sep 2007 18:19:50 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22501; Wed, 5 Sep 2007 11:19:41 +1000 Message-ID: <46DE042D.8060103@sgi.com> Date: Wed, 05 Sep 2007 11:19:41 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Shailendra Tripathi CC: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes References: <46D6279F.40601@sgi.com> <46DDE4A2.1070204@agami.com> In-Reply-To: <46DDE4A2.1070204@agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12763 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 Shailendra Tripathi wrote: > Hi, > Can someone explain how not checking the flushiter can losse > filesize updates. > Let me the take the case mentioned here in the fix statement: > > a. Clustered inode create - flush iter - X( 0) > b. size update --> flush iter --> Y > > X and Y will always hold as: X <= Y, that is, it is not possible to have > X >Y (unless size update is non -transactional. As far as I know, size > update is always transactional.) > > There are 2 cases here: > a) log of Y reached to the disk --> 1) inode with flush iter was > reached 2) inode didn't make. > b) log of Y didn't reach the disk --> flush_iter Y should have never > reached disk > > In none of cases, I can see the possibility that size update can be lost > becuase of replaying of the logs in the sequential order. If Log of Y > didn't reach, does it not make sense to have the flush_iter and size > correctly set to the last known transaction on the disk. To me, it > appears unsafe to do as the inode state will not match the state of the > last known transaction after recovery. > > Regards, > Shailendra Dave answered this but yes this is a case where we are breaking the transaction model IMO. And my understanding is that we are doing this for performance reasons. One of Lachlan's proposals (IIRC) was to log the size change before the ondisk size change in xfs_aops.c/xfs_setfilesize() and thus follow the model but questions were raised about introducing performance overhead of log traffic in the write path. --Tim From owner-xfs@oss.sgi.com Tue Sep 4 18:38:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 18:38:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l851bw4p017927 for ; Tue, 4 Sep 2007 18:38:01 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23204; Wed, 5 Sep 2007 11:37:50 +1000 Message-ID: <46DE0906.2040602@sgi.com> Date: Wed, 05 Sep 2007 11:40:22 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Timothy Shimmin CC: Shailendra Tripathi , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes References: <46D6279F.40601@sgi.com> <46DDE4A2.1070204@agami.com> <46DE042D.8060103@sgi.com> In-Reply-To: <46DE042D.8060103@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12764 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Timothy Shimmin wrote: > Shailendra Tripathi wrote: >> Hi, >> Can someone explain how not checking the flushiter can losse >> filesize updates. >> Let me the take the case mentioned here in the fix statement: >> >> a. Clustered inode create - flush iter - X( 0) >> b. size update --> flush iter --> Y >> >> X and Y will always hold as: X <= Y, that is, it is not possible to >> have X >Y (unless size update is non -transactional. As far as I know, >> size update is always transactional.) >> >> There are 2 cases here: >> a) log of Y reached to the disk --> 1) inode with flush iter was >> reached 2) inode didn't make. >> b) log of Y didn't reach the disk --> flush_iter Y should have never >> reached disk >> >> In none of cases, I can see the possibility that size update can be >> lost becuase of replaying of the logs in the sequential order. If Log >> of Y didn't reach, does it not make sense to have the flush_iter and >> size correctly set to the last known transaction on the disk. To me, >> it appears unsafe to do as the inode state will not match the state of >> the last known transaction after recovery. >> >> Regards, >> Shailendra > > Dave answered this but yes this is a case where we are breaking > the transaction model IMO. And my understanding is that we are doing > this for performance reasons. > One of Lachlan's proposals (IIRC) was to log the size change before the > ondisk size change in xfs_aops.c/xfs_setfilesize() > and thus follow the model but questions were raised about introducing > performance overhead of log traffic in the write path. > It would make life easier to do it that way - we wouldn't have to check the flushiter field of the ondisk inode because we know we will end up with the same thing by just replaying the log. But since the addition of the flushiter stuff pre-dates the NULL files changes there must be another reason we need it. Previously the size change would get logged with an extent allocation transaction but extending a file within the same last block would not send the new file size to the log. I think that may have been the reason for needing the flushiter stuff. If we log the file size change in xfs_setfilesize() we may not need the flushiter stuff at all, hmmm maybe for timestamp updates? From owner-xfs@oss.sgi.com Tue Sep 4 23:54:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 23:54:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l856sF4p029545 for ; Tue, 4 Sep 2007 23:54:18 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA05612; Wed, 5 Sep 2007 16:54:14 +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 l856sCdD6572929; Wed, 5 Sep 2007 16:54:13 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l856s7aa6574796; Wed, 5 Sep 2007 16:54:07 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 5 Sep 2007 16:54:07 +1000 From: David Chinner To: Lachlan McIlroy Cc: Timothy Shimmin , Shailendra Tripathi , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes Message-ID: <20070905065407.GO734179@sgi.com> References: <46D6279F.40601@sgi.com> <46DDE4A2.1070204@agami.com> <46DE042D.8060103@sgi.com> <46DE0906.2040602@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DE0906.2040602@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12765 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Sep 05, 2007 at 11:40:22AM +1000, Lachlan McIlroy wrote: > >Dave answered this but yes this is a case where we are breaking > >the transaction model IMO. And my understanding is that we are doing > >this for performance reasons. > >One of Lachlan's proposals (IIRC) was to log the size change before the > >ondisk size change in xfs_aops.c/xfs_setfilesize() > >and thus follow the model but questions were raised about introducing > >performance overhead of log traffic in the write path. > > It would make life easier to do it that way - we wouldn't have to check > the flushiter field of the ondisk inode because we know we will end up > with the same thing by just replaying the log. But since the addition > of the flushiter stuff pre-dates the NULL files changes there must be > another reason we need it. Previously the size change would get logged > with an extent allocation transaction but extending a file within the > same last block would not send the new file size to the log. I think > that may have been the reason for needing the flushiter stuff. If we > log the file size change in xfs_setfilesize() we may not need the > flushiter stuff at all, hmmm maybe for timestamp updates? atime, size updates and inode version format conversion may be written without a transaction first logging the change. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Sep 5 01:14:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Sep 2007 01:14:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from bay0-omc1-s17.bay0.hotmail.com (bay0-omc1-s17.bay0.hotmail.com [65.54.246.89]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l858EQ4p015973 for ; Wed, 5 Sep 2007 01:14:29 -0700 Received: from hotmail.com ([65.54.174.84]) by bay0-omc1-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Sep 2007 01:14:26 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Sep 2007 01:14:26 -0700 Message-ID: Received: from 85.36.106.198 by BAY103-DAV12.phx.gbl with DAV; Wed, 05 Sep 2007 08:14:21 +0000 X-Originating-IP: [85.36.106.198] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: "Christoph Lameter" Cc: , "David Chinner" , , , "Marco Berizzi" References: Subject: Re: kernel BUG at mm/slab.c:2980 (was Re: [] xfs_bmap_search_multi_extents+0x6f/0xe0) Date: Wed, 5 Sep 2007 10:12:56 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 05 Sep 2007 08:14:26.0404 (UTC) FILETIME=[C6464240:01C7EF94] X-archive-position: 12766 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs "Christoph Lameter" wrote: > On Tue, 4 Sep 2007, Marco Berizzi wrote: > > > After a week uptime I got this error. I hope it > > will be useful for you. > > Yes indeed but this is a different type of failure. Looks like a higher > allocation failure in the networking code. Someone created objects that > required an order 2 allocations that failed. > > > SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 > > Slub is restricted to order 0 and 1 allocs. > > > PREFETCH window: e5c00000-e7cfffff > > NET: Registered protocol family 2 > > IP route cache hash table entries: 2048 (order: 1, 8192 bytes) > > TCP established hash table entries: 8192 (order: 4, 65536 bytes) > > TCP bind hash table entries: 8192 (order: 3, 32768 bytes) > > Hmmmm. > > > eth2: setting full-duplex. > > swapper: page allocation failure. order:2, mode:0x4020 > > [] __alloc_pages+0x1ed/0x2e0 > > [] allocate_slab+0x4b/0x90 > > [] new_slab+0x32/0x150 > > [] __slab_alloc+0xcb/0x120 > > [] __slab_alloc+0x79/0x120 > > [] tcp_collapse+0x113/0x3b0 > > tcp_collapse? This is due to a network configuration that required an > order 2 kmalloc block. Jumbo frames? I don't use jumbo frames. Hardware is very old (celeron with 3com 3c905). From owner-xfs@oss.sgi.com Wed Sep 5 02:15:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Sep 2007 02:15:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.2.0-pre1-r499012 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 l859FU4p024958 for ; Wed, 5 Sep 2007 02:15:32 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11186; Wed, 5 Sep 2007 19:15:23 +1000 Message-ID: <46DE73AA.1090706@sgi.com> Date: Wed, 05 Sep 2007 19:15:22 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Linus Torvalds CC: Andrew Morton , xfs-oss , Linux Kernel Mailing List Subject: some XFS fixes for 2.6.23 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12767 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 Hi Linus, We have a few XFS fixes for 2.6.23 (meant to do this earlier). They have been in sgi dev tree and mm tree for a while. Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus With shortlog: ------------------------- Christoph Hellwig (4): [XFS] Fix sparse NULL vs 0 warnings [XFS] Fix sparse warning in kmem_shake_allow [XFS] fix ASSERT and ASSERT_ALWAYS [XFS] fix sparse shadowed variable warnings David Chinner (1): [XFS] Set filestreams object timeout to something sane. Eric Sandeen (1): [XFS] fix nasty quota hashtable allocation bug ------------------------- This will update the following files: fs/xfs/linux-2.6/kmem.h | 2 +- fs/xfs/linux-2.6/xfs_aops.c | 8 ++++---- fs/xfs/linux-2.6/xfs_globals.c | 2 +- fs/xfs/quota/xfs_qm.c | 3 ++- fs/xfs/support/debug.h | 10 ++++++---- fs/xfs/xfs_da_btree.c | 1 - fs/xfs/xfs_log.c | 12 ++++++------ fs/xfs/xfs_log_recover.c | 12 ++++++------ 8 files changed, 26 insertions(+), 24 deletions(-) through these commits: commit 5995cb7d805496362e5af73235145667096fbc6f Author: Eric Sandeen Date: Thu Aug 16 16:49:11 2007 +1000 [XFS] fix nasty quota hashtable allocation bug This git mod: 77e4635ae191774526ed695482a151ac986f3806 converted to a "greedy" allocation interface, but for the quota hashtables it switched from allocating XFS_QM_HASHSIZE (nr of elements) xfs_dqhash_t's to allocating only XFS_QM_HASHSIZE *bytes* - quite a lot smaller! Then when we converted hsize "back" to nr of elements (the division line) hsize went to 0. This was leading to oopses when running any quota tests on the Fedora 8 test kernel, but the problem has been there for almost a year. SGI-PV: 968837 SGI-Modid: xfs-linux-melb:xfs-kern:29354a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 265c1fac38e37e828df09965406e9cc20bfa3588 Author: Christoph Hellwig Date: Thu Aug 16 15:38:19 2007 +1000 [XFS] fix sparse shadowed variable warnings - in xfs_probe_cluster rename the inner len to pg_len. There's no harm here because the outer len isn't used after the inner len comes into existence but it keeps the code clean. - in xfs_da_do_buf remove the inner i because they don't overlap and they are both the same type. SGI-PV: 968555 SGI-Modid: xfs-linux-melb:xfs-kern:29311a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit ee5c80239d5f152d99f69165afbd115518353563 Author: Christoph Hellwig Date: Thu Aug 16 15:38:08 2007 +1000 [XFS] fix ASSERT and ASSERT_ALWAYS - remove the != 0 inside the unlikely in ASSERT_ALWAYS because sparse now complains about comparisons between pointers and 0 - add a standalone ASSERT implementation because defining it to ASSERT_ALWAYS means the string is expanded before the token passing stringification. This way we get the actual content of the assertion in the assfail message and don't overflow sparse's stringification buffer leading to sparse error messages. SGI-PV: 968555 SGI-Modid: xfs-linux-melb:xfs-kern:29310a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 34521c5e4971d01f6ef650fdee59e07be6c2c5e3 Author: Christoph Hellwig Date: Thu Aug 16 15:37:57 2007 +1000 [XFS] Fix sparse warning in kmem_shake_allow We can't return a masked result of a __bitwise type. Compare it to 0 first to keep the behaviour without the warning. SGI-PV: 968555 SGI-Modid: xfs-linux-melb:xfs-kern:29309a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 4b80916b29170744632356dd2e801f7c374676eb Author: Christoph Hellwig Date: Thu Aug 16 15:37:36 2007 +1000 [XFS] Fix sparse NULL vs 0 warnings Sparse now warns about comparing pointers to 0, so change all instance where that happens to NULL instead. SGI-PV: 968555 SGI-Modid: xfs-linux-melb:xfs-kern:29308a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 8da22d7a3690818f6d340baa0ea585e71f0c506f Author: David Chinner Date: Thu Aug 16 15:20:56 2007 +1000 [XFS] Set filestreams object timeout to something sane. SGI-PV: 968554 SGI-Modid: xfs-linux-melb:xfs-kern:29303a Signed-off-by: David Chinner Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin From owner-xfs@oss.sgi.com Wed Sep 5 04:08:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Sep 2007 04:08:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l85B834p008955 for ; Wed, 5 Sep 2007 04:08:04 -0700 Received: from schroedinger.engr.sgi.com (schroedinger.engr.sgi.com [150.166.1.51]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id D3F9F90893 for ; Wed, 5 Sep 2007 04:08:01 -0700 (PDT) Received: from clameter (helo=localhost) by schroedinger.engr.sgi.com with local-esmtp (Exim 3.36 #1 (Debian)) id 1ISsBS-000276-00; Wed, 05 Sep 2007 03:32:30 -0700 Date: Wed, 5 Sep 2007 03:32:30 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Marco Berizzi cc: linux-kernel@vger.kernel.org, David Chinner , xfs@oss.sgi.com, mel@skynet.ie Subject: Re: kernel BUG at mm/slab.c:2980 (was Re: [] xfs_bmap_search_multi_extents+0x6f/0xe0) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 12768 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: clameter@sgi.com Precedence: bulk X-list: xfs On Wed, 5 Sep 2007, Marco Berizzi wrote: > > tcp_collapse? This is due to a network configuration that required an > > order 2 kmalloc block. Jumbo frames? > > I don't use jumbo frames. Hardware is > very old (celeron with 3com 3c905). Something must be doing allocations that requires between 8k and 16k that SLUB cannot satisfy from order 0 or order 1 allocations. From owner-xfs@oss.sgi.com Wed Sep 5 06:35:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Sep 2007 06:35:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_33, J_CHICKENPOX_62 autolearn=no version=3.2.0-pre1-r499012 Received: from bay0-omc1-s22.bay0.hotmail.com (bay0-omc1-s22.bay0.hotmail.com [65.54.246.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l85DZQ4p001433 for ; Wed, 5 Sep 2007 06:35:28 -0700 Received: from hotmail.com ([65.54.174.78]) by bay0-omc1-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Sep 2007 06:35:28 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Sep 2007 06:35:28 -0700 Message-ID: Received: from 85.36.106.198 by BAY103-DAV6.phx.gbl with DAV; Wed, 05 Sep 2007 13:35:27 +0000 X-Originating-IP: [85.36.106.198] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: "Christoph Lameter" Cc: , "David Chinner" , , , "Marco Berizzi" References: Subject: Re: kernel BUG at mm/slab.c:2980 (was Re: [] xfs_bmap_search_multi_extents+0x6f/0xe0) Date: Wed, 5 Sep 2007 15:34:02 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 05 Sep 2007 13:35:28.0036 (UTC) FILETIME=[9F1A0E40:01C7EFC1] X-archive-position: 12769 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs Christoph Lameter wrote: > On Wed, 5 Sep 2007, Marco Berizzi wrote: > > > > tcp_collapse? This is due to a network configuration that required an > > > order 2 kmalloc block. Jumbo frames? > > > > I don't use jumbo frames. Hardware is > > very old (celeron with 3com 3c905). > > Something must be doing allocations that requires between 8k and 16k that > SLUB cannot satisfy from order 0 or order 1 allocations. Me again. Another report from another machine. Linux version 2.6.22.5 (root@Gemini) (gcc version 3.3.6) #1 Mon Aug 27 17:20:33 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000a000000 (usable) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 160MB LOWMEM available. Entering add_active_range(0, 0, 40960) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 40960 early_node_map[1] active PFN ranges 0: 0 - 40960 On node 0 totalpages: 40960 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 288 pages used for memmap Normal zone: 36576 pages, LIFO batch:7 DMI 2.1 present. Allocating PCI resources starting at 10000000 (gap: 0a000000:f5ff0000) Built 1 zonelists. Total pages: 40640 Kernel command line: auto BOOT_IMAGE=Linux ro root=301 slub_debug Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to ffffd000 (01141000) Enabling fast FPU save and restore... done. Initializing CPU#0 PID hash table entries: 1024 (order: 10, 4096 bytes) Detected 267.302 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 158956k/163840k available (1975k kernel code, 4452k reserved, 628k data, 160k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb7000 - 0xfffff000 ( 288 kB) vmalloc : 0xca800000 - 0xfffb5000 ( 855 MB) lowmem : 0xc0000000 - 0xca000000 ( 160 MB) .init : 0xc038e000 - 0xc03b6000 ( 160 kB) .data : 0xc02edc46 - 0xc038afa0 ( 628 kB) .text : 0xc0100000 - 0xc02edc46 (1975 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine.. 535.24 BogoMIPS (lpj=1070484) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0183f9ff 00000000 00000000 00000000 00000000 00000000 00000000 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: After all inits, caps: 0183f9ff 00000000 00000000 00000040 00000000 00000000 00000000 Compat vDSO mapped to ffffe000. CPU: Intel Celeron (Covington) stepping 00 Checking 'hlt' instruction... OK. ACPI: Core revision 20070126 ACPI Exception (tbxface-0618): AE_NO_ACPI_TABLES, While loading namespace from ACPI tables [20070126] ACPI: Unable to load the System Description Tables NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfda61, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) * Found PM-Timer Bug on the chipset. Due to workarounds for a bug, * this clock source is slow. Consider trying other clock sources PCI quirk: region 6100-613f claimed by PIIX4 ACPI PCI quirk: region 5f00-5f0f claimed by PIIX4 SMB PCI: Using IRQ router PIIX/ICH [8086/7110] at 0000:00:07.0 PCI: setting IRQ 11 as level-triggered PCI: Found IRQ 11 for device 0000:00:07.2 PCI: Sharing IRQ 11 with 0000:00:0b.0 Time: tsc clocksource has been installed. PCI: Bridge: 0000:00:01.0 IO window: b000-bfff MEM window: efe00000-efefffff PREFETCH window: e5c00000-e7cfffff NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered SGI XFS with no debug enabled io scheduler noop registered io scheduler deadline registered (default) Limiting direct PCI/PCI transfers. Boot video device is 0000:01:00.0 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller at PCI slot 0000:00:07.1 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... hda: QUANTUM FIREBALL EX3.2A, ATA DISK drive hda: selected mode 0x42 ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hda: max request size: 128KiB hda: 6306048 sectors (3228 MB) w/418KiB Cache, CHS=6256/16/63, UDMA(33) hda: cache flushes not supported hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 > PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice nf_conntrack version 0.5.0 (1280 buckets, 10240 max) ip_tables: (C) 2000-2006 Netfilter Core Team TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Using IPI Shortcut mode Filesystem "hda1": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda1 Starting XFS recovery on filesystem: hda1 (logdev: internal) Ending XFS recovery on filesystem: hda1 (logdev: internal) VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 160k freed Adding 209624k swap on /dev/hda9. Priority:-1 extents:1 across:209624k Filesystem "hda1": Disabling barriers, not supported by the underlying device Filesystem "hda1": Disabling barriers, not supported by the underlying device PCI: setting IRQ 9 as level-triggered PCI: Found IRQ 9 for device 0000:00:09.0 3c59x: Donald Becker and others. 0000:00:09.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001de00. PCI: setting IRQ 10 as level-triggered PCI: Found IRQ 10 for device 0000:00:0a.0 0000:00:0a.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001dc00. PCI: Found IRQ 11 for device 0000:00:0b.0 PCI: Sharing IRQ 11 with 0000:00:07.2 0000:00:0b.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001da00. Filesystem "hda5": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda5 Starting XFS recovery on filesystem: hda5 (logdev: internal) Ending XFS recovery on filesystem: hda5 (logdev: internal) Filesystem "hda6": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda6 Starting XFS recovery on filesystem: hda6 (logdev: internal) Ending XFS recovery on filesystem: hda6 (logdev: internal) Filesystem "hda7": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda7 Ending clean XFS mount for filesystem: hda7 Filesystem "hda8": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda8 Starting XFS recovery on filesystem: hda8 (logdev: internal) Ending XFS recovery on filesystem: hda8 (logdev: internal) eth0: setting full-duplex. eth1: setting full-duplex. eth2: setting full-duplex. input: AT Raw Set 2 keyboard as /class/input/input0 input: AT Translated Set 2 keyboard as /class/input/input1 Aug 31 12:32:04 Gemini kernel: swapper: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:04 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:04 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:04 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:04 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:04 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:04 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:04 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:04 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:04 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:04 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:04 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:04 Gemini kernel: [] tcp_data_queue+0x2b9/0x710 Aug 31 12:32:04 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:04 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:04 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:04 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:04 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:04 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:04 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:04 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:04 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:04 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:04 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:04 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:04 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:04 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:04 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:04 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:04 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:04 Gemini kernel: [] default_idle+0x0/0x40 Aug 31 12:32:04 Gemini kernel: [] default_idle+0x27/0x40 Aug 31 12:32:04 Gemini kernel: [] cpu_idle+0x5c/0x70 Aug 31 12:32:04 Gemini kernel: [] start_kernel+0x17c/0x1c0 Aug 31 12:32:04 Gemini kernel: [] unknown_bootoption+0x0/0x1a0 Aug 31 12:32:04 Gemini kernel: ======================= Aug 31 12:32:04 Gemini kernel: DMA per-cpu: Aug 31 12:32:04 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:04 Gemini kernel: Normal per-cpu: Aug 31 12:32:04 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 41 Cold: hi: 14, btch: 3 usd: 12 Aug 31 12:32:04 Gemini kernel: Active:26797 inactive:4519 dirty:0 writeback:0 unstable:0 Aug 31 12:32:04 Gemini kernel: free:1544 slab:6392 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:04 Gemini kernel: DMA free:1388kB min:160kB low:200kB high:240kB active:7740kB inactive:1068kB present:16256kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:04 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:04 Gemini kernel: Normal free:4788kB min:1448kB low:1808kB high:2172kB active:99448kB inactive:17008kB present:146304kB pages_scanned:34 all_unreclaimable? no Aug 31 12:32:04 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:04 Gemini kernel: DMA: 315*4kB 14*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1388kB Aug 31 12:32:04 Gemini kernel: Normal: 995*4kB 83*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4788kB Aug 31 12:32:04 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:05 Gemini kernel: swapper: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x2b9/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] default_idle+0x0/0x40 Aug 31 12:32:05 Gemini kernel: [] default_idle+0x27/0x40 Aug 31 12:32:05 Gemini kernel: [] cpu_idle+0x5c/0x70 Aug 31 12:32:05 Gemini kernel: [] start_kernel+0x17c/0x1c0 Aug 31 12:32:05 Gemini kernel: [] unknown_bootoption+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: ======================= Aug 31 12:32:05 Gemini kernel: DMA per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:05 Gemini kernel: Normal per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 35 Cold: hi: 14, btch: 3 usd: 13 Aug 31 12:32:05 Gemini kernel: Active:26727 inactive:4495 dirty:3 writeback:0 unstable:0 Aug 31 12:32:05 Gemini kernel: free:1690 slab:6345 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:05 Gemini kernel: DMA free:1552kB min:160kB low:200kB high:240kB active:7740kB inactive:940kB present:16256kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:05 Gemini kernel: Normal free:5208kB min:1448kB low:1808kB high:2172kB active:99168kB inactive:17040kB present:146304kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:05 Gemini kernel: DMA: 364*4kB 10*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1552kB Aug 31 12:32:05 Gemini kernel: Normal: 1090*4kB 88*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 5208kB Aug 31 12:32:05 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:05 Gemini kernel: swapper: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x2b9/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] default_idle+0x0/0x40 Aug 31 12:32:05 Gemini kernel: [] default_idle+0x27/0x40 Aug 31 12:32:05 Gemini kernel: [] cpu_idle+0x5c/0x70 Aug 31 12:32:05 Gemini kernel: [] start_kernel+0x17c/0x1c0 Aug 31 12:32:05 Gemini kernel: [] unknown_bootoption+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: ======================= Aug 31 12:32:05 Gemini kernel: DMA per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:05 Gemini kernel: Normal per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 36 Cold: hi: 14, btch: 3 usd: 12 Aug 31 12:32:05 Gemini kernel: Active:26569 inactive:4526 dirty:4 writeback:0 unstable:0 Aug 31 12:32:05 Gemini kernel: free:1910 slab:6252 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:05 Gemini kernel: DMA free:1552kB min:160kB low:200kB high:240kB active:7720kB inactive:960kB present:16256kB pages_scanned:34 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:05 Gemini kernel: Normal free:6088kB min:1448kB low:1808kB high:2172kB active:98556kB inactive:17144kB present:146304kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:05 Gemini kernel: DMA: 364*4kB 10*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1552kB Aug 31 12:32:05 Gemini kernel: Normal: 1298*4kB 94*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6088kB Aug 31 12:32:05 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:05 Gemini kernel: swapper: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x5ab/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] default_idle+0x0/0x40 Aug 31 12:32:05 Gemini kernel: [] default_id Aug 31 12:32:05 Gemini kernel: klogd: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x5ab/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] autoremove_wake_function+0x0/0x50 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] __sched_text_start+0x30d/0x5c0 Aug 31 12:32:05 Gemini kernel: [] work_resched+0x5/0x16 Aug 31 12:32:05 Gemini kernel: [] build_expire+0x100/0x140 Aug 31 12:32:05 Gemini kernel: ======================= Aug 31 12:32:05 Gemini kernel: DMA per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:05 Gemini kernel: Normal per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 36 Cold: hi: 14, btch: 3 usd: 12 Aug 31 12:32:05 Gemini kernel: Active:26569 inactive:4526 dirty:4 writeback:0 unstable:0 Aug 31 12:32:05 Gemini kernel: free:1910 slab:6252 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:05 Gemini kernel: DMA free:1552kB min:160kB low:200kB high:240kB active:7720kB inactive:960kB present:16256kB pages_scanned:34 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:05 Gemini kernel: Normal free:6088kB min:1448kB low:1808kB high:2172kB active:98556kB inactive:17144kB present:146304kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:05 Gemini kernel: DMA: 364*4kB 10*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1552kB Aug 31 12:32:05 Gemini kernel: Normal: 1298*4kB 94*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6088kB Aug 31 12:32:05 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:05 Gemini kernel: klogd: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x5ab/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] autoremove_wake_function+0x0/0x50 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] __sched_text_start+0x30d/0x5c0 Aug 31 12:32:05 Gemini kernel: [] work_resched+0x5/0x16 Aug 31 12:32:05 Gemini kernel: [] build_expire+0x100/0x140 Aug 31 12:32:05 Gemini kernel: ======================= Aug 31 12:32:05 Gemini kernel: DMA per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:05 Gemini kernel: Normal per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 36 Cold: hi: 14, btch: 3 usd: 12 Aug 31 12:32:05 Gemini kernel: Active:26569 inactive:4526 dirty:4 writeback:0 unstable:0 Aug 31 12:32:05 Gemini kernel: free:1910 slab:6252 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:05 Gemini kernel: DMA free:1552kB min:160kB low:200kB high:240kB active:7720kB inactive:960kB present:16256kB pages_scanned:34 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:05 Gemini kernel: Normal free:6088kB min:1448kB low:1808kB high:2172kB active:98556kB inactive:17144kB present:146304kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:05 Gemini kernel: DMA: 364*4kB 10*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1552kB Aug 31 12:32:05 Gemini kernel: Normal: 1298*4kB 94*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6088kB Aug 31 12:32:05 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:05 Gemini kernel: klogd: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x5ab/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] autoremove_wake_function+0x0/0x50 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] __sched_text_start+0x30d/0x5c0 Aug 31 12:32:05 Gemini kernel: [] work_resched+0x5/0x16 Aug 31 12:32:05 Gemini kernel: [] build_expire+0x100/0x140 Aug 31 12:32:05 Gemini kernel: ======================= Aug 31 12:32:05 Gemini kernel: DMA per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:05 Gemini kernel: Normal per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 36 Cold: hi: 14, btch: 3 usd: 12 Aug 31 12:32:05 Gemini kernel: Active:26569 inactive:4526 dirty:4 writeback:0 unstable:0 Aug 31 12:32:05 Gemini kernel: free:1910 slab:6252 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:05 Gemini kernel: DMA free:1552kB min:160kB low:200kB high:240kB active:7720kB inactive:960kB present:16256kB pages_scanned:34 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:05 Gemini kernel: Normal free:6088kB min:1448kB low:1808kB high:2172kB active:98556kB inactive:17144kB present:146304kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:05 Gemini kernel: DMA: 364*4kB 10*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1552kB Aug 31 12:32:05 Gemini kernel: Normal: 1298*4kB 94*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6088kB Aug 31 12:32:05 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:05 Gemini kernel: klogd: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x5ab/0x710 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] autoremove_wake_function+0x0/0x50 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] __sched_text_start+0x30d/0x5c0 Aug 31 12:32:05 Gemini kernel: [] work_resched+0x5/0x16 Aug 31 12:32:05 Gemini kernel: [] build_expire+0x100/0x140 Aug 31 12:32:05 Gemini kernel: ======================= Aug 31 12:32:05 Gemini kernel: DMA per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:05 Gemini kernel: Normal per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 36 Cold: hi: 14, btch: 3 usd: 12 Aug 31 12:32:05 Gemini kernel: Active:26569 inactive:4526 dirty:4 writeback:0 unstable:0 Aug 31 12:32:05 Gemini kernel: free:1910 slab:6252 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:05 Gemini kernel: DMA free:1552kB min:160kB low:200kB high:240kB active:7720kB inactive:960kB present:16256kB pages_scanned:34 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:05 Gemini kernel: Normal free:6088kB min:1448kB low:1808kB high:2172kB active:98556kB inactive:17144kB present:146304kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:05 Gemini kernel: DMA: 364*4kB 10*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1552kB Aug 31 12:32:05 Gemini kernel: Normal: 1298*4kB 94*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6088kB Aug 31 12:32:05 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:05 Gemini kernel: klogd: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x5ab/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] autoremove_wake_function+0x0/0x50 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] __sched_text_start+0x30d/0x5c0 Aug 31 12:32:05 Gemini kernel: [] work_resched+0x5/0x16 Aug 31 12:32:05 Gemini kernel: [] build_expire+0x100/0x140 Aug 31 12:32:05 Gemini kernel: ======================= Aug 31 12:32:05 Gemini kernel: DMA per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:05 Gemini kernel: Normal per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 36 Cold: hi: 14, btch: 3 usd: 12 Aug 31 12:32:05 Gemini kernel: Active:26569 inactive:4526 dirty:4 writeback:0 unstable:0 Aug 31 12:32:05 Gemini kernel: free:1910 slab:6252 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:05 Gemini kernel: DMA free:1552kB min:160kB low:200kB high:240kB active:7720kB inactive:960kB present:16256kB pages_scanned:34 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:05 Gemini kernel: Normal free:6088kB min:1448kB low:1808kB high:2172kB active:98556kB inactive:17144kB present:146304kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:05 Gemini kernel: DMA: 364*4kB 10*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1552kB Aug 31 12:32:05 Gemini kernel: Normal: 1298*4kB 94*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6088kB Aug 31 12:32:05 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:05 Gemini kernel: klogd: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x5ab/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] autoremove_wake_function+0x0/0x50 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] __sched_text_start+0x30d/0x5c0 Aug 31 12:32:05 Gemini kernel: [] work_resched+0x5/0x16 Aug 31 12:32:05 Gemini kernel: [] build_expire+0x100/0x140 Aug 31 12:32:05 Gemini kernel: ======================= Aug 31 12:32:05 Gemini kernel: DMA per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:05 Gemini kernel: Normal per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 36 Cold: hi: 14, btch: 3 usd: 12 Aug 31 12:32:05 Gemini kernel: Active:26569 inactive:4526 dirty:4 writeback:0 unstable:0 Aug 31 12:32:05 Gemini kernel: free:1910 slab:6252 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:05 Gemini kernel: DMA free:1552kB min:160kB low:200kB high:240kB active:7720kB inactive:960kB present:16256kB pages_scanned:34 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:05 Gemini kernel: Normal free:6088kB min:1448kB low:1808kB high:2172kB active:98556kB inactive:17144kB present:146304kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:05 Gemini kernel: DMA: 364*4kB 10*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1552kB Aug 31 12:32:05 Gemini kernel: Normal: 1298*4kB 94*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6088kB Aug 31 12:32:05 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:10 Gemini kernel: printk: 30 messages suppressed. Aug 31 12:32:10 Gemini kernel: swapper: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:10 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:10 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:10 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:10 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:10 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:10 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:10 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:10 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:10 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:10 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:10 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:10 Gemini kernel: [] tcp_data_queue+0x2b9/0x710 Aug 31 12:32:10 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:10 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:10 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:10 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:10 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:10 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:10 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:10 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:10 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:10 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:10 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:10 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:10 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:10 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:10 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:10 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:10 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:10 Gemini kernel: [] default_idle+0x0/0x40 Aug 31 12:32:10 Gemini kernel: [] default_idle+0x27/0x40 Aug 31 12:32:10 Gemini kernel: [] cpu_idle+0x5c/0x70 Aug 31 12:32:10 Gemini kernel: [] start_kernel+0x17c/0x1c0 Aug 31 12:32:10 Gemini kernel: [] unknown_bootoption+0x0/0x1a0 Aug 31 12:32:10 Gemini kernel: ======================= Aug 31 12:32:10 Gemini kernel: DMA per-cpu: Aug 31 12:32:10 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:10 Gemini kernel: Normal per-cpu: Aug 31 12:32:10 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 39 Cold: hi: 14, btch: 3 usd: 11 Aug 31 12:32:10 Gemini kernel: Active:22747 inactive:5150 dirty:12 writeback:0 unstable:0 Aug 31 12:32:10 Gemini kernel: free:6426 slab:4932 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:10 Gemini kernel: DMA free:3268kB min:160kB low:200kB high:240kB active:6424kB inactive:1104kB present:16256kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:10 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:10 Gemini kernel: Normal free:22436kB min:1448kB low:1808kB high:2172kB active:84564kB inactive:19496kB present:146304kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:10 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:10 Gemini kernel: DMA: 609*4kB 102*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3268kB Aug 31 12:32:10 Gemini kernel: Normal: 4487*4kB 543*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 22436kB Aug 31 12:32:10 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:10 Gemini kernel: Free swap = 209624kB Aug 31 12:32:10 Gemini kernel: Total swap = 209624kB From owner-xfs@oss.sgi.com Wed Sep 5 15:47:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Sep 2007 15:47:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.2 required=5.0 tests=BAYES_99,J_CHICKENPOX_42, RDNS_DYNAMIC autolearn=no version=3.2.0-pre1-r499012 Received: from fctnnbsc14w-142166022069.pppoe-dynamic.nb.aliant.net (fctnnbsc14w-142166022069.pppoe-dynamic.nb.aliant.net [142.166.22.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l85Mlb4p020258 for ; Wed, 5 Sep 2007 15:47:39 -0700 Received: from ggigw ([213.66.220.138]) by fctnnbsc14w-142166022069.pppoe-dynamic.nb.aliant.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Sep 2007 19:47:37 -0300 Message-ID: <46DF3209.8020403@alliance-mortgage.com> Date: Wed, 5 Sep 2007 19:47:37 -0300 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Market Update Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12770 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sueswitzer@turpin.ca Precedence: bulk X-list: xfs Big Numbers Roll As Volume Rises On VGPM Vega Promotional Sys VGPM.PK $0.07 Big News for VGPM has caused huge trading waves. Tomorrow will be even bigger. Get ahead of the wave and reap the benefits first thing on Thursday morning. From owner-xfs@oss.sgi.com Thu Sep 6 09:10:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Sep 2007 09:10:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l86GA94p026102 for ; Thu, 6 Sep 2007 09:10:12 -0700 Received: from filer.fsl.cs.sunysb.edu (localhost.localdomain [127.0.0.1]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id l86GA6SK025308; Thu, 6 Sep 2007 12:10:06 -0400 Received: (from jsipek@localhost) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1/Submit) id l86GA64s025306; Thu, 6 Sep 2007 12:10:06 -0400 X-Authentication-Warning: filer.fsl.cs.sunysb.edu: jsipek set sender to jsipek@fsl.cs.sunysb.edu using -f Date: Thu, 6 Sep 2007 12:10:06 -0400 From: Josef Sipek To: Christoph Hellwig Cc: nick.couchman@seakr.com, xfs@oss.sgi.com Subject: Re: [xfs-masters] [Bug 768] New: Move restrict_chown to mount-time option Message-ID: <20070906161006.GA25035@filer.fsl.cs.sunysb.edu> References: <200709051831.l85IVsTR016106@oss.sgi.com> <20070906153529.GA3062@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070906153529.GA3062@lst.de> User-Agent: Mutt/1.5.16 (2007-07-16) X-archive-position: 12772 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jsipek@fsl.cs.sunysb.edu Precedence: bulk X-list: xfs On Thu, Sep 06, 2007 at 05:35:29PM +0200, Christoph Hellwig wrote: > On Wed, Sep 05, 2007 at 11:31:54AM -0700, bugzilla-daemon@oss.sgi.com wrote: > > We've run into a situation where it would be extremely advantageous to be able > > to restrict_chown on certain volumes on a server but not on others. I'm not > > real familiar with kernel internals, programming, etc., but I'd like to suggest > > that restrict_chown be made a mount option for an XFS filesystem instead of a > > system-wide, sysctl/proc option. This would allow finer control over which > > filesystems restrict giving away files and which don't. > > It's quite easily doable. I don't have time for that right now, but if > anyone wants to do it's just adding the option to the mount option > parser and adding a flag to the mount structure. Wouldn't making this a generic mount-option make sense? Or is it far too low-level of a concept? Josef 'Jeff' Sipek. -- I already backed up the [server] once, I can do it again. From owner-xfs@oss.sgi.com Thu Sep 6 11:03:41 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Sep 2007 11:03:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.180]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l86I3d4p010763 for ; Thu, 6 Sep 2007 11:03:41 -0700 Received: by el-out-1112.google.com with SMTP id y26so53772ele for ; Thu, 06 Sep 2007 11:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=KNx22cvrRcjqGiQ8lPAiMNLWzOrgSPJ1dUeyGyu+LHY=; b=itr7tXPjzSujXtfPONbS/FSvNE9VR2I+ZN6yMQIWYd0T7cUR59TkeRhCZKdYeSREa1/g8wuzFe6VJ7SLVKpwTdZlaTJytctIpRPtuCIjG4Gaq92gOpiRrgn9sgcQdm1GcPfWcLtjkN7Gt38THcgQqSEyx3qBBPXiQQrLsVPTRsk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=lo7B4RCDpYZV2By9ZFhOS94BKRERDcbblA2VytB1bjgCPFTg4QJPTeYYOdbDj53ulPIBgmPcXqwbR2l6932tAlODdyi8YI8P7nvFhTW1MgV2gIcjqG5QcU+tz8x/ynGOpxMbwse/+6iXxO8RSgnmzl7C2xihu7i4ZikdSoSY5wM= Received: by 10.142.212.19 with SMTP id k19mr42760wfg.1189098329964; Thu, 06 Sep 2007 10:05:29 -0700 (PDT) Received: by 10.142.12.10 with HTTP; Thu, 6 Sep 2007 10:05:28 -0700 (PDT) Message-ID: <170b1bd40709061005t787494b6lca283320cace6c31@mail.gmail.com> Date: Thu, 6 Sep 2007 18:05:29 +0100 From: "Mark Goodall" To: xfs@oss.sgi.com Subject: Bug Report MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 993 X-archive-position: 12773 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mark.goodall@gmail.com Precedence: bulk X-list: xfs Not sure what caused this bug, how much more information do you need? - 18:01:15: check for inodes claiming duplicate blocks - 198528 of 198528 inodes done No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... corrupt dinode 25809974, extent total = 16, nblocks = 0. This is a bug. Please report it to xfs@oss.sgi.com. cache_node_purge: refcount was 1, not zero (node=0x8d65fd0) couldn't map inode 25809974, err = 117 entry "gobo_3.3-6_i386.deb" in shortform directory inode 1770978822 points to free inode 1770978825 would junk entry "gobo_3.3-6_i386.deb" - 18:01:48: traversing filesystem - 32 of 32 allocation groups done - traversal finished ... - traversing all unattached subtrees ... Segmentation fault (core dumped) OS: Ubuntu Linux mserve 2.6.20-16-386 #2 Fri Aug 31 00:51:58 UTC 2007 i686 GNU/Linux fully patched from official repositories [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Sep 6 17:18:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Sep 2007 17:18:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 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 l870I04p005569 for ; Thu, 6 Sep 2007 17:18:05 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA19649; Fri, 7 Sep 2007 10:17:56 +1000 Date: Fri, 07 Sep 2007 10:23:37 +1000 To: "Mark Goodall" Subject: Re: Bug Report From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <170b1bd40709061005t787494b6lca283320cace6c31@mail.gmail.com> Message-ID: In-Reply-To: <170b1bd40709061005t787494b6lca283320cace6c31@mail.gmail.com> User-Agent: Opera Mail/9.10 (Win32) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id l870I74p005575 X-archive-position: 12774 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Fri, 07 Sep 2007 03:05:29 +1000, Mark Goodall wrote: > Not sure what caused this bug, how much more information do you need? Version number of xfs_repair. Also, if possible, a zipped metadump image (need xfsprogs 2.9.0 or later) to fix any xfs_repair bugs. Regards, Barry. > - 18:01:15: check for inodes claiming duplicate blocks - 198528 > of > 198528 inodes done > No modify flag set, skipping phase 5 > Phase 6 - check inode connectivity... > - traversing filesystem starting at / ... > corrupt dinode 25809974, extent total = 16, nblocks = 0. This is a bug. > Please report it to xfs@oss.sgi.com. > cache_node_purge: refcount was 1, not zero (node=0x8d65fd0) > couldn't map inode 25809974, err = 117 > entry "gobo_3.3-6_i386.deb" in shortform directory inode 1770978822 > points > to free inode 1770978825 > would junk entry "gobo_3.3-6_i386.deb" > - 18:01:48: traversing filesystem - 32 of 32 allocation groups > done > - traversal finished ... > - traversing all unattached subtrees ... > Segmentation fault (core dumped) > > OS: Ubuntu Linux mserve 2.6.20-16-386 #2 Fri Aug 31 00:51:58 UTC 2007 > i686 > GNU/Linux > fully patched from official repositories > > > [[HTML alternate version deleted]] > > From owner-xfs@oss.sgi.com Thu Sep 6 19:00:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Sep 2007 19:00:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8720Q4p020041 for ; Thu, 6 Sep 2007 19:00:29 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA23808; Fri, 7 Sep 2007 12:00:21 +1000 Message-ID: <46E0B154.1000805@sgi.com> Date: Fri, 07 Sep 2007 12:03:00 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Chinner CC: Mark Goodwin , Timothy Shimmin , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes References: <46D6279F.40601@sgi.com> <46D6480F.4040307@sgi.com> <46D64CAD.6050705@sgi.com> <46D67FE6.20205@sgi.com> <46D68510.1020404@sgi.com> <46D77B79.3040104@sgi.com> <46D792A1.7030308@sgi.com> <20070831154822.GD734179@sgi.com> In-Reply-To: <20070831154822.GD734179@sgi.com> Content-Type: multipart/mixed; boundary="------------020202030406060709080005" X-archive-position: 12775 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------020202030406060709080005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Chinner wrote: > On Fri, Aug 31, 2007 at 02:01:37PM +1000, Mark Goodwin wrote: >> Lachlan McIlroy wrote: >>> Timothy Shimmin wrote: >>>> Timothy Shimmin wrote: >>>>>>> But I'm not sure this is an error... >>>>>>> Hmmmm...I'm a bit confused. >>>>>>> So you are _almost_ combining an error check with a flushiter check? >>>>>>> If one buffer is an inode magic# and the other isn't then we >>>>>>> have an error right - and could report it - but we are not doing >>>>>>> that here. >>>>>> Not exactly. If what's on disk is not an inode but the log item is >>>>>> then that could be because we haven't written the inode to disk yet >>>>>> and we need to perform recovery. >>>>> Yeah, I was thinking about that afterward. >>>>> The item's format which gives the blk# for the buf to read could >>>>> be a block which hasn't been used for an inode yet. >>>>> >>>> Well, if what's on disk is not an inode but some other data >>>> and it happens to have the inode magic# which is remotely possible, >>>> then we are making a bad assumption. >>>> i.e. if we're not sure what the block/buffer should be, then testing the >>>> MAGIC# isn't a guarantee it's an inode then. >>>> Well not for the freeing of inode clusters case I would assume. >>>> Or am I missing something? >>> I don't think you're missing anything! >>> >>> You're right though - a magic number check is no guarantee. On the same >>> vein, adding a generation number check isn't much better. >> unlink will have to invalidate the on-disk inode magic number? Or only >> when the whole cluster is free'd? > > An unlinked inode is only detectable by the mode parameter being zero. > The rest of the inode will look valid. > > To detect the difference between a newly allocated inode *chunk* > that has been written to and a stale inode chunk that we have > just allocated and not written to yet, you need to walk every inode > in the chunk and determine if the mode parameter is zero in every > inode. > > If the mode is zero for all inodes and there are generation numbers > that are not zero, then you've detected a stale buffer and you should > replay the inode cluster buffer initialisation. > Thanks for this info Dave. I looked into it and came up with a solution that looks at the ondisk inode buffer and determines if it has been written to since being logged. It iterates through all the inodes and checks each one with: - if the magic number is wrong the buffer is stale - if the mode is non-zero then the buffer is newer than the log - if the mode is zero and the generation count is non-zero then the buffer is stale If the end result is a stale buffer then the buffer is replayed otherwise it is skipped. I added a new flag that gets logged with a new inode cluster so that we can identify a buffer of inodes from something else. This fix is passing all the tests we have. Is this a better approach than the last fix? Lachlan --------------020202030406060709080005 Content-Type: text/x-patch; name="xfs_log_recover.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_log_recover.diff" --- fs/xfs/xfs_buf_item.h_1.44 2007-09-04 13:38:24.000000000 +1000 +++ fs/xfs/xfs_buf_item.h 2007-09-06 12:06:39.000000000 +1000 @@ -52,6 +52,11 @@ typedef struct xfs_buf_log_format_t { #define XFS_BLI_UDQUOT_BUF 0x4 #define XFS_BLI_PDQUOT_BUF 0x8 #define XFS_BLI_GDQUOT_BUF 0x10 +/* + * This flag indicates that the buffer contains newly allocated + * inodes. + */ +#define XFS_BLI_INODE_NEW_BUF 0x20 #define XFS_BLI_CHUNK 128 #define XFS_BLI_SHIFT 7 --- fs/xfs/xfs_log_recover.c_1.322 2007-08-27 17:45:45.000000000 +1000 +++ fs/xfs/xfs_log_recover.c 2007-09-07 10:41:38.000000000 +1000 @@ -1874,6 +1874,7 @@ xlog_recover_do_inode_buffer( /*ARGSUSED*/ STATIC void xlog_recover_do_reg_buffer( + xfs_mount_t *mp, xlog_recover_item_t *item, xfs_buf_t *bp, xfs_buf_log_format_t *buf_f) @@ -1884,6 +1885,30 @@ xlog_recover_do_reg_buffer( unsigned int *data_map = NULL; unsigned int map_size = 0; int error; + int stale_buf = 1; + + if (buf_f->blf_flags & XFS_BLI_INODE_NEW_BUF) { + xfs_dinode_t *dip; + int inodes_per_buf; + + stale_buf = 0; + inodes_per_buf = XFS_BUF_COUNT(bp) >> mp->m_sb.sb_inodelog; + for (i = 0; i < inodes_per_buf; i++) { + dip = (xfs_dinode_t *)xfs_buf_offset(bp, + i * mp->m_sb.sb_inodesize); + if (be16_to_cpu(dip->di_core.di_magic) != + XFS_DINODE_MAGIC) { + stale_buf = 1; + break; + } + if (be16_to_cpu(dip->di_core.di_mode)) + break; + if (be16_to_cpu(dip->di_core.di_gen)) { + stale_buf = 1; + break; + } + } + } switch (buf_f->blf_type) { case XFS_LI_BUF: @@ -1917,7 +1942,7 @@ xlog_recover_do_reg_buffer( -1, 0, XFS_QMOPT_DOWARN, "dquot_buf_recover"); } - if (!error) + if (!error && stale_buf) memcpy(xfs_buf_offset(bp, (uint)bit << XFS_BLI_SHIFT), /* dest */ item->ri_buf[i].i_addr, /* source */ @@ -2089,7 +2114,7 @@ xlog_recover_do_dquot_buffer( if (log->l_quotaoffs_flag & type) return; - xlog_recover_do_reg_buffer(item, bp, buf_f); + xlog_recover_do_reg_buffer(mp, item, bp, buf_f); } /* @@ -2190,7 +2215,7 @@ xlog_recover_do_buffer_trans( (XFS_BLI_UDQUOT_BUF|XFS_BLI_PDQUOT_BUF|XFS_BLI_GDQUOT_BUF)) { xlog_recover_do_dquot_buffer(mp, log, item, bp, buf_f); } else { - xlog_recover_do_reg_buffer(item, bp, buf_f); + xlog_recover_do_reg_buffer(mp, item, bp, buf_f); } if (error) return XFS_ERROR(error); --- fs/xfs/xfs_trans_buf.c_1.126 2007-09-04 13:38:27.000000000 +1000 +++ fs/xfs/xfs_trans_buf.c 2007-09-05 17:37:31.000000000 +1000 @@ -966,6 +966,7 @@ xfs_trans_inode_alloc_buf( ASSERT(atomic_read(&bip->bli_refcount) > 0); bip->bli_flags |= XFS_BLI_INODE_ALLOC_BUF; + bip->bli_format.blf_flags |= XFS_BLI_INODE_NEW_BUF; } --------------020202030406060709080005-- From owner-xfs@oss.sgi.com Thu Sep 6 21:59:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Sep 2007 21:59:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l874x04p013996 for ; Thu, 6 Sep 2007 21:59:02 -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 OAA27826; Fri, 7 Sep 2007 14:58:57 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id DC64D58C4C09; Fri, 7 Sep 2007 14:58:57 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 969188 - xfs_metadump doesn't do enough validation of bad offsets Message-Id: <20070907045857.DC64D58C4C09@chook.melbourne.sgi.com> Date: Fri, 7 Sep 2007 14:58:57 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-archive-position: 12776 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Make xfs_metadump more robust against bad data Date: Fri Sep 7 14:58:32 AEST 2007 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:29620a xfsprogs/db/metadump.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/metadump.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h - Make xfs_metadump more robust against bad data xfsprogs/db/xfs_metadump.sh - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/xfs_metadump.sh.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h - Add -m command line option From owner-xfs@oss.sgi.com Thu Sep 6 22:33:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Sep 2007 22:33:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l875XV4p018644 for ; Thu, 6 Sep 2007 22:33:33 -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 PAA28640; Fri, 7 Sep 2007 15:33:28 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id E228258C4C09; Fri, 7 Sep 2007 15:33:27 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 970180 - Link xfsprogs utils to libpthread when linking to libxfs Message-Id: <20070907053327.E228258C4C09@chook.melbourne.sgi.com> Date: Fri, 7 Sep 2007 15:33:27 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-archive-position: 12777 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Link xfsprogs utils to libpthread when linking to libxfs Date: Fri Sep 7 15:32:31 AEST 2007 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: vapier@gentoo.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:29621a xfsprogs/VERSION - 1.176 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.176&r2=text&tr2=1.175&f=h xfsprogs/doc/CHANGES - 1.246 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.246&r2=text&tr2=1.245&f=h - Bump version number to 2.9.4 xfsprogs/db/Makefile - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/Makefile.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsprogs/mkfs/Makefile - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/Makefile.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsprogs/logprint/Makefile - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/logprint/Makefile.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/growfs/Makefile - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/growfs/Makefile.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/repair/Makefile - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/Makefile.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfsprogs/mdrestore/Makefile - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mdrestore/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h - Link to libpthread From owner-xfs@oss.sgi.com Thu Sep 6 23:10:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Sep 2007 23:10:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.235]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l876Ad4p023911 for ; Thu, 6 Sep 2007 23:10:42 -0700 Received: by wx-out-0506.google.com with SMTP id s9so365385wxc for ; Thu, 06 Sep 2007 23:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=um0UxphUdVv6auAIIXi4DuF1hxGed51kK7G7gq354jY=; b=MmYxcUTbKhbKcUaI4Ir5DjpXwnaW4ehdowEdxQ7qDzjdvN7aMjEwhtSWRWUh3WsNr4uxenWtO9asYIaOMHwn+GMMbkCuAdIjfwXEGH9Az73u0TYC7FSBQkH3nT2UQfKJAjGNk8h3bNK7ia6pxdSR1a3uG5aRZHIOqKVol784PK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jAqInUC8E0zLQToOgf7uzAtT4NoT7jIDcPaQVD3h8YrZGdmL5fjhWmDGqbUF/FlwGP85Svm0Z8HM0kUnahhdZSXWYyS0MOFUnhpKurda5nRMMQOnZA38yMMr8+bP5RQmaPlnO/wUOt6cVu9RcFxdG5mXCjyKW+0y0RKzbvYi2RU= Received: by 10.90.51.17 with SMTP id y17mr2895672agy.1189143807208; Thu, 06 Sep 2007 22:43:27 -0700 (PDT) Received: by 10.90.52.4 with HTTP; Thu, 6 Sep 2007 22:43:27 -0700 (PDT) Message-ID: <9ee2fe770709062243u67956d26o7222435956213f0@mail.gmail.com> Date: Fri, 7 Sep 2007 11:28:27 +0545 From: "kanishk rastogi" To: "David Chinner" Subject: Re: Need of inode->i_mutex in xfs_write() Cc: xfs@oss.sgi.com In-Reply-To: <20070823225111.GW72985246@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9ee2fe770708210826n5952e727od0df16a5a7b267f0@mail.gmail.com> <20070823225111.GW72985246@sgi.com> X-archive-position: 12778 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kanishk.85@gmail.com Precedence: bulk X-list: xfs On 8/24/07, David Chinner wrote: > On Tue, Aug 21, 2007 at 09:11:56PM +0545, kanishk rastogi wrote: > > I was looking at the xfs_write code path in kernel 2.6.20 ....... > > I saw it acquiring inode->i_mutex . > > Whats the need ? > > What are we safegaurding inode for. > > See Documentation/filesystems/Locking and other files in that > directory for what i_mutex is supposed to protect. > > XFS is different as it has it's own inodes and inode locks, but > it still mostly uses i_mutex inteh accepted way. > xfs_write comes in file_operations->aio_write() and the documentation doesnt say anything for it to acquire i_mutex in that path. I still fail to understand its usage. Where i am going wrong. regards kanishk > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > From owner-xfs@oss.sgi.com Thu Sep 6 23:29:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Sep 2007 23:29:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l876T94p026688 for ; Thu, 6 Sep 2007 23:29:11 -0700 Received: by wx-out-0506.google.com with SMTP id s9so368490wxc for ; Thu, 06 Sep 2007 23:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=fOM2PKyQXQaUxNSpAejNo2vYzsuPMn/aVPetom0AQLY=; b=VEE2TgHdFJeT1I4rexmFTMKX2ZMC1YQtU98Zg7i+CPF5o6M0sFJ8K8togPX43UXmJHmnItz3/GEQTr+DWZzjTT3A1SzAKxNLq/UcUykL0MELCaIjJ5GgbXnI2ARtZcD5Upn8ItopSAj+ojM0MFhU8I4xd/+Oat5Z85p71SD2bY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SWix7jWh04VviaUWPGQr+IbsSzDBQFhrD5Nd3XzhCx7qVRyTbhOykyKbwPBESOWBdmBsXucb/J54IMUB4dF140Bl0XIiGCfkyjj7JOBz8lW9gIEnFldAmmLj3M5cT/boWxsqruuOrXn0durZwviaCOPSGl4l9CXTQkRxuq08q7k= Received: by 10.90.118.12 with SMTP id q12mr2938870agc.1189146550036; Thu, 06 Sep 2007 23:29:10 -0700 (PDT) Received: by 10.90.52.4 with HTTP; Thu, 6 Sep 2007 23:29:09 -0700 (PDT) Message-ID: <9ee2fe770709062329i47e6b813s3f051d726d0ae755@mail.gmail.com> Date: Fri, 7 Sep 2007 12:14:09 +0545 From: "kanishk rastogi" To: xfs@oss.sgi.com Subject: Not able to register. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 12779 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kanishk.85@gmail.com Precedence: bulk X-list: xfs I am not able to register to xfs mailing list through ecartis. I am doing what is said on the webpage http://oss.sgi.com/projects/xfs/mail.html is there a problem with the xfs-mailing list ? regards kanishk From owner-xfs@oss.sgi.com Fri Sep 7 01:46:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Sep 2007 01:46:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.2.0-pre1-r499012 Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l878ke4p018260 for ; Fri, 7 Sep 2007 01:46:43 -0700 Received: by wx-out-0506.google.com with SMTP id s9so391681wxc for ; Fri, 07 Sep 2007 01:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=05rIdldjZLsgEpRGa4eN+FOir/vnstIbPOgJIllPliQ=; b=WNwcpDZ8lp+LCVhJALIwKOQOPwVoYVEWnWmAFva7vG9ugJp+37buARaOplDn79YFbj21FHoATi1WdsjMvjcd6yxsWmxEmUj5pHMwwW5rqAMCrbeTbkQdAzzWn3vC67f3mMu/j/fS1d8pP00fU8Vq3ddjr4a4Y/cn3WutyX37IUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JlIYhiSag67rqqW+UF/fm/5RVh5CnK/7Xv1z4leylC8WbWwLzt90Q9sJ/CU5J54DiHLGYqMMbPfC9cSSe/J5IgjBHPp+hMvJZ6g4aMZ/8akuIT1dubexiUQ5/R2Kt7IwMK/0AYBKzET0SRId+/hZiK5CQRI+GybcaVHlZHrqxok= Received: by 10.90.119.15 with SMTP id r15mr3291522agc.1189154801683; Fri, 07 Sep 2007 01:46:41 -0700 (PDT) Received: by 10.90.52.4 with HTTP; Fri, 7 Sep 2007 01:46:41 -0700 (PDT) Message-ID: <9ee2fe770709070146p17b669b8v7bab29bc5d25acdc@mail.gmail.com> Date: Fri, 7 Sep 2007 14:31:41 +0545 From: "kanishk rastogi" To: "Justin Piszcz" Subject: Re: Not able to register. Cc: xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9ee2fe770709062329i47e6b813s3f051d726d0ae755@mail.gmail.com> X-archive-position: 12780 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kanishk.85@gmail.com Precedence: bulk X-list: xfs On 9/7/07, Justin Piszcz wrote: > > > On Fri, 7 Sep 2007, kanishk rastogi wrote: > > > I am not able to register to xfs mailing list through ecartis. > > I am doing what is said on the webpage > > > > http://oss.sgi.com/projects/xfs/mail.html > > > > is there a problem with the xfs-mailing list ? > > > > regards > > kanishk > > > > > > Sometimes it takes 6-12 hours I have noticed in the past. But I have not > checked recently. > I had tried to register some weeks back.... But till now there is no response. It seems ecartis detects some lousy chaps like me .... :) regards kanishk From owner-xfs@oss.sgi.com Fri Sep 7 01:55:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Sep 2007 01:55:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.2.0-pre1-r499012 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l878t94p019675 for ; Fri, 7 Sep 2007 01:55:10 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 604A21C000265; Fri, 7 Sep 2007 04:39:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 4C825410885B; Fri, 7 Sep 2007 04:39:30 -0400 (EDT) Date: Fri, 7 Sep 2007 04:39:30 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: kanishk rastogi cc: xfs@oss.sgi.com Subject: Re: Not able to register. In-Reply-To: <9ee2fe770709062329i47e6b813s3f051d726d0ae755@mail.gmail.com> Message-ID: References: <9ee2fe770709062329i47e6b813s3f051d726d0ae755@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 12781 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Fri, 7 Sep 2007, kanishk rastogi wrote: > I am not able to register to xfs mailing list through ecartis. > I am doing what is said on the webpage > > http://oss.sgi.com/projects/xfs/mail.html > > is there a problem with the xfs-mailing list ? > > regards > kanishk > > Sometimes it takes 6-12 hours I have noticed in the past. But I have not checked recently. From owner-xfs@oss.sgi.com Fri Sep 7 01:55:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Sep 2007 01:55:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l878t94p019676 for ; Fri, 7 Sep 2007 01:55:10 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 05B851C15D769; Fri, 7 Sep 2007 04:47:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 017A0410885B; Fri, 7 Sep 2007 04:47:47 -0400 (EDT) Date: Fri, 7 Sep 2007 04:47:47 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: kanishk rastogi cc: xfs@oss.sgi.com Subject: Re: Not able to register. In-Reply-To: <9ee2fe770709070146p17b669b8v7bab29bc5d25acdc@mail.gmail.com> Message-ID: References: <9ee2fe770709062329i47e6b813s3f051d726d0ae755@mail.gmail.com> <9ee2fe770709070146p17b669b8v7bab29bc5d25acdc@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 12782 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Fri, 7 Sep 2007, kanishk rastogi wrote: > On 9/7/07, Justin Piszcz wrote: >> >> >> On Fri, 7 Sep 2007, kanishk rastogi wrote: >> >>> I am not able to register to xfs mailing list through ecartis. >>> I am doing what is said on the webpage >>> >>> http://oss.sgi.com/projects/xfs/mail.html >>> >>> is there a problem with the xfs-mailing list ? >>> >>> regards >>> kanishk >>> >>> >> >> Sometimes it takes 6-12 hours I have noticed in the past. But I have not >> checked recently. >> > I had tried to register some weeks back.... > But till now there is no response. > > It seems ecartis detects some lousy chaps like me .... :) > > regards > kanishk > Try again (now) maybe there were some issues a few weeks back. Justin. From owner-xfs@oss.sgi.com Fri Sep 7 02:09:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Sep 2007 02:09:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8799P4p022823 for ; Fri, 7 Sep 2007 02:09:28 -0700 Received: by wx-out-0506.google.com with SMTP id s9so395472wxc for ; Fri, 07 Sep 2007 02:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=m6RuROritg2Gxo4rw7FMFgsDrb5xgUMcbSgoL1OwAdE=; b=d5CSWdGHVC8pivtE1E7EcLvaY+C5FZVoQXKudsjpHQwlOWZJGJ5FzwjrLy2BrPCSYlCsTsiD9UPPBdm+KBc0dCLyzZQE0kL4ifbJqCZQif4SomLOilnBAb7o+EZqoYabiv+wcw7i8j/rdBcNC9yp4beon8sh40OWQlHsmOAEHps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KlgwqZKsX9oQ4psCt2rXX3RfhgiuXim2TuiPuueMN+pLXyzpTviOhFAs86NTpUtCoqAzOjY2HmgLuDVijmPX7wYzxmASVI5h2BW8aSRBX/6UReJXsXN1ncqmbLt+59G94UTUqw66rQ8ZNKfafJBGT3l2YwGuIw9E8dnFREVGyVA= Received: by 10.90.27.13 with SMTP id a13mr3355423aga.1189156166870; Fri, 07 Sep 2007 02:09:26 -0700 (PDT) Received: by 10.90.52.4 with HTTP; Fri, 7 Sep 2007 02:09:26 -0700 (PDT) Message-ID: <9ee2fe770709070209k5bf34fdahbc103de95b1b3aa9@mail.gmail.com> Date: Fri, 7 Sep 2007 14:54:26 +0545 From: "kanishk rastogi" To: "Justin Piszcz" Subject: Re: Not able to register. Cc: xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9ee2fe770709062329i47e6b813s3f051d726d0ae755@mail.gmail.com> <9ee2fe770709070146p17b669b8v7bab29bc5d25acdc@mail.gmail.com> X-archive-position: 12783 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kanishk.85@gmail.com Precedence: bulk X-list: xfs On 9/7/07, Justin Piszcz wrote: > > > On Fri, 7 Sep 2007, kanishk rastogi wrote: > > > On 9/7/07, Justin Piszcz wrote: > >> > >> > >> On Fri, 7 Sep 2007, kanishk rastogi wrote: > >> > >>> I am not able to register to xfs mailing list through ecartis. > >>> I am doing what is said on the webpage > >>> > >>> http://oss.sgi.com/projects/xfs/mail.html > >>> > >>> is there a problem with the xfs-mailing list ? > >>> > >>> regards > >>> kanishk > >>> > >>> > >> > >> Sometimes it takes 6-12 hours I have noticed in the past. But I have not > >> checked recently. > >> > > I had tried to register some weeks back.... > > But till now there is no response. > > > > It seems ecartis detects some lousy chaps like me .... :) > > > > regards > > kanishk > > > > Try again (now) maybe there were some issues a few weeks back. Thankx will let u know the result > > Justin. > From owner-xfs@oss.sgi.com Fri Sep 7 05:15:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Sep 2007 05:15:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l87CFF4p023224 for ; Fri, 7 Sep 2007 05:15:16 -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 WAA05958; Fri, 7 Sep 2007 22:15:09 +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 l87CF7dD9461924; Fri, 7 Sep 2007 22:15:08 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l87CF5ps9427311; Fri, 7 Sep 2007 22:15:05 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 7 Sep 2007 22:15:05 +1000 From: David Chinner To: kanishk rastogi Cc: David Chinner , xfs@oss.sgi.com Subject: Re: Need of inode->i_mutex in xfs_write() Message-ID: <20070907121505.GX734179@sgi.com> References: <9ee2fe770708210826n5952e727od0df16a5a7b267f0@mail.gmail.com> <20070823225111.GW72985246@sgi.com> <9ee2fe770709062243u67956d26o7222435956213f0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ee2fe770709062243u67956d26o7222435956213f0@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12784 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Sep 07, 2007 at 11:28:27AM +0545, kanishk rastogi wrote: > On 8/24/07, David Chinner wrote: > > On Tue, Aug 21, 2007 at 09:11:56PM +0545, kanishk rastogi wrote: > > > I was looking at the xfs_write code path in kernel 2.6.20 ....... > > > I saw it acquiring inode->i_mutex . > > > Whats the need ? > > > What are we safegaurding inode for. > > > > See Documentation/filesystems/Locking and other files in that > > directory for what i_mutex is supposed to protect. > > > > XFS is different as it has it's own inodes and inode locks, but > > it still mostly uses i_mutex inteh accepted way. > > > > xfs_write comes in file_operations->aio_write() > and the documentation doesnt say anything for it to acquire i_mutex in > that path. The i_mutex is supposed to be held across various calls into generic code. See generic_file_aio_write() for the common implementation of ->aio_write(). The entire write path is supposed to be protected by the i_mutex. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Sep 7 06:53:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Sep 2007 06:53:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.9 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l87DrA4p003737 for ; Fri, 7 Sep 2007 06:53:12 -0700 Received: by wa-out-1112.google.com with SMTP id k22so617120waf for ; Fri, 07 Sep 2007 06:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=HPuyNZFO/oJBDkx08Z+4O244F0TyqUXqqdP4gUnmDJg=; b=O544rrTeeTwMuRH0JKoT+DQljsGEWKABRBJ8FnDbXKTXttMY/TylhH+wSUByWNGYBXv7O3tZBbi8DqKNcGYH9TIc1CQVQrCOETZFxCaVil+XUynP9VxbHfd310Yl7R9Ql2cAfv8umdqMIUt3vNaoARi8rSr/d3JiJn8ESEBhOj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=qHmNVKx8ZNwrTL6DlRFfYIpWVHrMxAxt2ReaaRmq87TUXc8wzpB/TPqY6V4muqAYDAiYGZl06Y0yA+jx3EqITZpBQ2vdx9BrcNZw+U+zejN93viwrHv+CVu/d74GXNTVv/NKMW4zKmvt7+krWB5eT+JPpyQOtC+QNq5rF0EUi3Q= Received: by 10.114.169.2 with SMTP id r2mr1637467wae.1189169645780; Fri, 07 Sep 2007 05:54:05 -0700 (PDT) Received: by 10.114.168.18 with HTTP; Fri, 7 Sep 2007 05:54:05 -0700 (PDT) Message-ID: <27f5402a0709070554x49c43e95h99f6a48522845826@mail.gmail.com> Date: Fri, 7 Sep 2007 18:24:05 +0530 From: "Sujata Vadrevu" To: xfs@oss.sgi.com Subject: Not able to register MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 244 X-archive-position: 12785 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ssujata@gmail.com Precedence: bulk X-list: xfs I am not able to register to xfs mailing list through ecartis. I am doing what is said on the webpage http://oss.sgi.com/projects/xfs/mail.html is there a problem with the xfs-mailing list ? -- sujata [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Fri Sep 7 07:05:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Sep 2007 07:05:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l87E5h4p005531 for ; Fri, 7 Sep 2007 07:05:48 -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 AAA08586; Sat, 8 Sep 2007 00:05:44 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l87E5hdD9625199; Sat, 8 Sep 2007 00:05:43 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l87E5gOI9651833; Sat, 8 Sep 2007 00:05:42 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Sat, 8 Sep 2007 00:05:41 +1000 From: David Chinner To: Lachlan McIlroy Cc: Mark Goodwin , Timothy Shimmin , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes Message-ID: <20070907140541.GA734179@sgi.com> References: <46D6279F.40601@sgi.com> <46D6480F.4040307@sgi.com> <46D64CAD.6050705@sgi.com> <46D67FE6.20205@sgi.com> <46D68510.1020404@sgi.com> <46D77B79.3040104@sgi.com> <46D792A1.7030308@sgi.com> <20070831154822.GD734179@sgi.com> <46E0B154.1000805@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E0B154.1000805@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12786 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Sep 07, 2007 at 12:03:00PM +1000, Lachlan McIlroy wrote: > David Chinner wrote: > >An unlinked inode is only detectable by the mode parameter being zero. > >The rest of the inode will look valid. > > > >To detect the difference between a newly allocated inode *chunk* > >that has been written to and a stale inode chunk that we have > >just allocated and not written to yet, you need to walk every inode > >in the chunk and determine if the mode parameter is zero in every > >inode. > > > >If the mode is zero for all inodes and there are generation numbers > >that are not zero, then you've detected a stale buffer and you should > >replay the inode cluster buffer initialisation. > > > > Thanks for this info Dave. I looked into it and came up with a solution > that looks at the ondisk inode buffer and determines if it has been > written to since being logged. It iterates through all the inodes and > checks each one with: > > - if the magic number is wrong the buffer is stale *nod* > - if the mode is non-zero then the buffer is newer than the log *nod* > - if the mode is zero and the generation count is non-zero then the > buffer is stale On second thoughts, this might be more complex - the buffer is stale only if all inodes in the *chunk* have this pattern. We may have multiple buffers to a chunk. e.g. allocate 55 inodes, they span two 8k cluster buffers. Both meet the second criteria. Now remove the first 32 inodes, and we have one buffer with zero allocated inodes but non-zero generation numbers (i.e. thrid state) and one that meets the second criteria. However, both buffers are more recent than the buffer being replayed. We could lose generation count changes if we overwrite the buffer with no inodes in it.... So I think the stale buffer criteria must be that all the inodes in the entire inode chunk (i.e. across all buffers) must have a zero mode and at least one of the inodes has a non-zero generation count. Does that make sense? > If the end result is a stale buffer then the buffer is replayed otherwise > it is skipped. I added a new flag that gets logged with a new inode > cluster so that we can identify a buffer of inodes from something else. > This fix is passing all the tests we have. Is this a better approach > than the last fix? Definitely, but I think our "stale buffer" detection needs more work. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Sep 7 12:04:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Sep 2007 12:04:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l87J4V4p011560 for ; Fri, 7 Sep 2007 12:04:36 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l87J4SA5008191 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 7 Sep 2007 21:04:29 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l87J4SXe008189; Fri, 7 Sep 2007 21:04:28 +0200 Date: Fri, 7 Sep 2007 21:04:27 +0200 From: Christoph Hellwig To: Josef Sipek Cc: Christoph Hellwig , nick.couchman@seakr.com, xfs@oss.sgi.com Subject: Re: [xfs-masters] [Bug 768] New: Move restrict_chown to mount-time option Message-ID: <20070907190427.GA8062@lst.de> References: <200709051831.l85IVsTR016106@oss.sgi.com> <20070906153529.GA3062@lst.de> <20070906161006.GA25035@filer.fsl.cs.sunysb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070906161006.GA25035@filer.fsl.cs.sunysb.edu> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12787 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Thu, Sep 06, 2007 at 12:10:06PM -0400, Josef Sipek wrote: > > It's quite easily doable. I don't have time for that right now, but if > > anyone wants to do it's just adding the option to the mount option > > parser and adding a flag to the mount structure. > > Wouldn't making this a generic mount-option make sense? Or is it far too > low-level of a concept? Basically it's a simple boolean flag that's checked in the inode allocator when we decide about the permission of the newly created inode. Because of that the implementation will be inherently filesystem-specific. We could still add a binary mount flag for it in common code, but my stance is to only add these when we actually need to check the flag in general code. From owner-xfs@oss.sgi.com Fri Sep 7 12:15:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Sep 2007 12:15:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l87JFX4p013249 for ; Fri, 7 Sep 2007 12:15:35 -0700 Received: from filer.fsl.cs.sunysb.edu (localhost.localdomain [127.0.0.1]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id l87JFV4B029016; Fri, 7 Sep 2007 15:15:31 -0400 Received: (from jsipek@localhost) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1/Submit) id l87JFVKD029014; Fri, 7 Sep 2007 15:15:31 -0400 X-Authentication-Warning: filer.fsl.cs.sunysb.edu: jsipek set sender to jsipek@fsl.cs.sunysb.edu using -f Date: Fri, 7 Sep 2007 15:15:31 -0400 From: Josef Sipek To: Christoph Hellwig Cc: nick.couchman@seakr.com, xfs@oss.sgi.com Subject: Re: [xfs-masters] [Bug 768] New: Move restrict_chown to mount-time option Message-ID: <20070907191531.GA22883@filer.fsl.cs.sunysb.edu> References: <200709051831.l85IVsTR016106@oss.sgi.com> <20070906153529.GA3062@lst.de> <20070906161006.GA25035@filer.fsl.cs.sunysb.edu> <20070907190427.GA8062@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070907190427.GA8062@lst.de> User-Agent: Mutt/1.5.16 (2007-07-16) X-archive-position: 12788 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jsipek@fsl.cs.sunysb.edu Precedence: bulk X-list: xfs On Fri, Sep 07, 2007 at 09:04:27PM +0200, Christoph Hellwig wrote: > On Thu, Sep 06, 2007 at 12:10:06PM -0400, Josef Sipek wrote: > > > It's quite easily doable. I don't have time for that right now, but if > > > anyone wants to do it's just adding the option to the mount option > > > parser and adding a flag to the mount structure. > > > > Wouldn't making this a generic mount-option make sense? Or is it far too > > low-level of a concept? > > Basically it's a simple boolean flag that's checked in the inode > allocator when we decide about the permission of the newly created > inode. Because of that the implementation will be inherently > filesystem-specific. Couldn't that be done just before the call to ->create as a mask on the mode? > We could still add a binary mount flag for it in common code, but my > stance is to only add these when we actually need to check the flag in > general code. Or if the feature is so useful that all fs should support it. Is it useful? If not, then I agree, not cluttering the VFS is a Good Thing. Josef 'Jeff' Sipek. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan From owner-xfs@oss.sgi.com Fri Sep 7 18:33:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Sep 2007 18:33:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.2 required=5.0 tests=BAYES_99,J_CHICKENPOX_54, J_CHICKENPOX_71 autolearn=no version=3.2.0-pre1-r499012 Received: from gala.securewebs.net (gala.securewebs.net [213.218.161.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l881XT4p014836 for ; Fri, 7 Sep 2007 18:33:33 -0700 X-ClientAddr: 127.0.0.1 Received: from gala.securewebs.net (localhost.localdomain [127.0.0.1]) by gala.securewebs.net (8.12.11.20060308/8.12.11) with ESMTP id l880HbAs020304 for ; Sat, 8 Sep 2007 02:17:37 +0200 Received: (from apache@localhost) by gala.securewebs.net (8.12.11.20060308/8.12.10/Submit) id l880HYdt020291; Sat, 8 Sep 2007 02:17:34 +0200 Date: Sat, 8 Sep 2007 02:17:34 +0200 Message-Id: <200709080017.l880HYdt020291@gala.securewebs.net> To: xfs@oss.sgi.com Subject: Hello. From: Michael Anthony Reply-To: michaelcoanthony@yahoo.co.uk MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-WebControl-MailScanner-Information: Please contact the ISP for more information X-WebControl-MailScanner: Found to be clean X-MailScanner-From: apache@gala.securewebs.net X-archive-position: 12789 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: michaelcoanthony@yahoo.co.uk Precedence: bulk X-list: xfs Hello, I am Michael Anthony,i have an Estate Agent Company Registered in United Kingdom and currently need a Partner in USA and Canada. Please Contact me back for more info. Best Regards, Michael Anthony. MICHAEL ANTHONY PROPERTIES. FLAT 21 FRANCIS COURTH MACATHUR CLOSE ERITH,KENT LONDON DA8 1DQ UK Tel:+447045748757 447940990728 442071797777 Fax:+447006-032-197 Email: michaelcoanthony@yahoo.co.uk Website: http://www.michaelanthony.co.uk/ From owner-xfs@oss.sgi.com Fri Sep 7 23:31:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Sep 2007 23:31:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.4 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l886VC4p025306 for ; Fri, 7 Sep 2007 23:31:17 -0700 Received: by wa-out-1112.google.com with SMTP id k22so877890waf for ; Fri, 07 Sep 2007 23:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=YKr7V+aKO8PJ6Q25UCGrnJlYsBYCrGY9MmCwIUD5k6Q=; b=CM+fEiQvsULJUSkVxt5KxMixeZnNw2fhO81wZry/o1MtPgiR5hckrSMS20ijcvZOL8y68PTJua5G4tembi9FCNUdoOwilbR+DyW6e6NRwnXqSBKSi254bbiq6YOG8hTXwuzC3pl4MubTiJPY6/BiCT9VbwW0DvOX1ydibKSJkvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=gMZOauqfWtdoTDkUvyDdN6WRyDNzDx1+uWCuMRiXkFgrWbRew0YxHSm2qDbj8atuF6MPdr9B1Y+BX8CNQeHomUJiQuU6Q8VyOC8HKiYoK6l+twdqTLU9lCtToett0yh/IX/UAp3V4woMNNljjhFdm1m1ulBr70ktpYtSRk1EetE= Received: by 10.115.77.1 with SMTP id e1mr2332837wal.1189231407954; Fri, 07 Sep 2007 23:03:27 -0700 (PDT) Received: by 10.114.171.20 with HTTP; Fri, 7 Sep 2007 23:03:27 -0700 (PDT) Message-ID: Date: Sat, 8 Sep 2007 11:33:27 +0530 From: "Bhagi rathi" To: xfs@oss.sgi.com Subject: Not able to register MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 269 X-archive-position: 12790 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs I am not able to register to xfs mailing list through ecartis. I am doing what is said on the webpage http://oss.sgi.com/projects/xfs/mail.html is there a problem with the xfs-mailing list ? Can someone look into this? -- Jahnu. [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sat Sep 8 06:18:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Sep 2007 06:18:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l88DIg4p025772 for ; Sat, 8 Sep 2007 06:18:45 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l88DIfA5019261 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 8 Sep 2007 15:18:41 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l88DIejd019258; Sat, 8 Sep 2007 15:18:40 +0200 Date: Sat, 8 Sep 2007 15:18:40 +0200 From: Christoph Hellwig To: Josef Sipek Cc: Christoph Hellwig , nick.couchman@seakr.com, xfs@oss.sgi.com Subject: Re: [xfs-masters] [Bug 768] New: Move restrict_chown to mount-time option Message-ID: <20070908131840.GA18653@lst.de> References: <200709051831.l85IVsTR016106@oss.sgi.com> <20070906153529.GA3062@lst.de> <20070906161006.GA25035@filer.fsl.cs.sunysb.edu> <20070907190427.GA8062@lst.de> <20070907191531.GA22883@filer.fsl.cs.sunysb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070907191531.GA22883@filer.fsl.cs.sunysb.edu> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12791 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, Sep 07, 2007 at 03:15:31PM -0400, Josef Sipek wrote: > On Fri, Sep 07, 2007 at 09:04:27PM +0200, Christoph Hellwig wrote: > > On Thu, Sep 06, 2007 at 12:10:06PM -0400, Josef Sipek wrote: > > > > It's quite easily doable. I don't have time for that right now, but if > > > > anyone wants to do it's just adding the option to the mount option > > > > parser and adding a flag to the mount structure. > > > > > > Wouldn't making this a generic mount-option make sense? Or is it far too > > > low-level of a concept? > > > > Basically it's a simple boolean flag that's checked in the inode > > allocator when we decide about the permission of the newly created > > inode. Because of that the implementation will be inherently > > filesystem-specific. > > Couldn't that be done just before the call to ->create as a mask on the > mode? Sorry, my post above was talking about the bsd group semantics for which we had a similar discussion before. For restricted_chown the method handling it is ->setattr and given how it's defined to be filesystem specific I can't see how to do it generically. > > We could still add a binary mount flag for it in common code, but my > > stance is to only add these when we actually need to check the flag in > > general code. > > Or if the feature is so useful that all fs should support it. Is it useful? > If not, then I agree, not cluttering the VFS is a Good Thing. It's not really a feature, more a workaround for legacy behaviour in other Unix variants. It basically disallows chown in some cases where it's normally allowed. From owner-xfs@oss.sgi.com Sat Sep 8 18:06:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Sep 2007 18:06:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.2.0-pre1-r499012 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 l8916Y4p028348 for ; Sat, 8 Sep 2007 18:06:37 -0700 Received: from Liberator.local (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 074DE180000F2; Sat, 8 Sep 2007 20:06:36 -0500 (CDT) Message-ID: <46E3471D.7020408@sandeen.net> Date: Sat, 08 Sep 2007 20:06:37 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Bhagi rathi CC: xfs@oss.sgi.com, trev@sgi.com, "'Russell Cattelan'" , ralf@linux-mips.org Subject: Re: Not able to register References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12792 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 Bhagi rathi wrote: > I am not able to register to xfs mailing list through ecartis. > I am doing what is said on the webpage > > http://oss.sgi.com/projects/xfs/mail.html > > is there a problem with the xfs-mailing list ? > Can someone look into this? Trev, Russell, Ralf... this is about the 3rd complaint about ecartis, any of you know what might be up? -Eric From owner-xfs@oss.sgi.com Sat Sep 8 19:36:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Sep 2007 19:36:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l892aL4p005406 for ; Sat, 8 Sep 2007 19:36:22 -0700 Received: from Liberator.local (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 DAF3D18234CBE; Sat, 8 Sep 2007 21:36:22 -0500 (CDT) Message-ID: <46E35C28.4060301@sandeen.net> Date: Sat, 08 Sep 2007 21:36:24 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Bhagi rathi CC: xfs@oss.sgi.com, trev@sgi.com, "'Russell Cattelan'" , ralf@linux-mips.org Subject: Re: Not able to register References: <46E3471D.7020408@sandeen.net> In-Reply-To: <46E3471D.7020408@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12793 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 Eric Sandeen wrote: > Bhagi rathi wrote: >> I am not able to register to xfs mailing list through ecartis. >> I am doing what is said on the webpage >> >> http://oss.sgi.com/projects/xfs/mail.html >> >> is there a problem with the xfs-mailing list ? >> Can someone look into this? > > Trev, Russell, Ralf... this is about the 3rd complaint about ecartis, > any of you know what might be up? > > -Eric > > Ok, for what it's worth, I just successfully subscribed my redhat.com email. For those having trouble... details please. -Eric From owner-xfs@oss.sgi.com Sat Sep 8 23:51:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Sep 2007 23:51:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l896pn4p002895 for ; Sat, 8 Sep 2007 23:51:51 -0700 Received: from filer.fsl.cs.sunysb.edu (localhost.localdomain [127.0.0.1]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id l896piG9024691; Sun, 9 Sep 2007 02:51:44 -0400 Received: (from jsipek@localhost) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1/Submit) id l896ph2w024689; Sun, 9 Sep 2007 02:51:43 -0400 X-Authentication-Warning: filer.fsl.cs.sunysb.edu: jsipek set sender to jsipek@fsl.cs.sunysb.edu using -f Date: Sun, 9 Sep 2007 02:51:43 -0400 From: Josef Sipek To: Eric Sandeen Cc: Bhagi rathi , xfs@oss.sgi.com, trev@sgi.com, "'Russell Cattelan'" , ralf@linux-mips.org Subject: Re: Not able to register Message-ID: <20070909065143.GA6787@filer.fsl.cs.sunysb.edu> References: <46E3471D.7020408@sandeen.net> <46E35C28.4060301@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E35C28.4060301@sandeen.net> User-Agent: Mutt/1.5.16 (2007-07-16) X-archive-position: 12794 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jsipek@fsl.cs.sunysb.edu Precedence: bulk X-list: xfs On Sat, Sep 08, 2007 at 09:36:24PM -0500, Eric Sandeen wrote: > Eric Sandeen wrote: > > Bhagi rathi wrote: > >> I am not able to register to xfs mailing list through ecartis. > >> I am doing what is said on the webpage > >> > >> http://oss.sgi.com/projects/xfs/mail.html > >> > >> is there a problem with the xfs-mailing list ? > >> Can someone look into this? > > > > Trev, Russell, Ralf... this is about the 3rd complaint about ecartis, > > any of you know what might be up? > > > > -Eric > > > > > > Ok, for what it's worth, I just successfully subscribed my redhat.com > email. For those having trouble... details please. Interesting observation: all 3 complaints were from @gmail.com users. Josef 'Jeff' Sipek. -- NT is to UNIX what a doughnut is to a particle accelerator. From owner-xfs@oss.sgi.com Sun Sep 9 00:01:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 00:01:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.9 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8971R4p006837 for ; Sun, 9 Sep 2007 00:01:28 -0700 Received: by wa-out-1112.google.com with SMTP id k22so1232945waf for ; Sun, 09 Sep 2007 00:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=KpqtrEP6wC7qL8DQXPHhb5rRFAmlSZSqGbySmlJJPdk=; b=RVV/vHe47W5bEqMV+2/emWPjfhU1E6PeTYESLqbIEngqZyG2zCn1NtFOahshlu4Wqki/vHcqme72Gj+P5JOdY14YhuiTxJ+r/yNj3czN+VpPZJWFySKHny8i0fJ70tCoS/qiakG5USrC870CNac4mtaEH1csf76zXhL5tt7VlDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Vdu9QnXZeyy7XMJIWECDp0PtAQOcxUdcGDXmuw1el/lmEn1ALNeJznV6Owp7ULZDZ5BRe95MAx4EHw7yaGRHQwYbKIjp3dQohdOejaWVt+raGrznbLnoRKfeFRigr24XqB5CqLXFwwtlt5jM4JPlN156nMKGYjZoCM5hQEVYhCA= Received: by 10.114.209.1 with SMTP id h1mr2234877wag.1189321287875; Sun, 09 Sep 2007 00:01:27 -0700 (PDT) Received: by 10.114.171.20 with HTTP; Sun, 9 Sep 2007 00:01:22 -0700 (PDT) Message-ID: Date: Sun, 9 Sep 2007 12:31:22 +0530 From: "Bhagi rathi" To: "Josef Sipek" Subject: Re: Not able to register Cc: "Eric Sandeen" , xfs@oss.sgi.com, trev@sgi.com, "Russell Cattelan" , ralf@linux-mips.org In-Reply-To: <20070909065143.GA6787@filer.fsl.cs.sunysb.edu> MIME-Version: 1.0 References: <46E3471D.7020408@sandeen.net> <46E35C28.4060301@sandeen.net> <20070909065143.GA6787@filer.fsl.cs.sunysb.edu> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1245 X-archive-position: 12795 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs It allows some email ids and doesn't allow some other email ids from gmail. I believe it is something to do with filters at ecartis. I tried to register uvsaradhi@gmail.com and it didn't worked. Finally I was able to register by creating this id. I believe it is more to do with filters at ecartis. -Saradhi. On 9/9/07, Josef Sipek wrote: > > On Sat, Sep 08, 2007 at 09:36:24PM -0500, Eric Sandeen wrote: > > Eric Sandeen wrote: > > > Bhagi rathi wrote: > > >> I am not able to register to xfs mailing list through ecartis. > > >> I am doing what is said on the webpage > > >> > > >> http://oss.sgi.com/projects/xfs/mail.html > > >> > > >> is there a problem with the xfs-mailing list ? > > >> Can someone look into this? > > > > > > Trev, Russell, Ralf... this is about the 3rd complaint about ecartis, > > > any of you know what might be up? > > > > > > -Eric > > > > > > > > > > Ok, for what it's worth, I just successfully subscribed my redhat.com > > email. For those having trouble... details please. > > Interesting observation: all 3 complaints were from @gmail.com users. > > Josef 'Jeff' Sipek. > > -- > NT is to UNIX what a doughnut is to a particle accelerator. > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sun Sep 9 07:58:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 07:58:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.6 required=5.0 tests=AWL,BAYES_50,RDNS_DYNAMIC autolearn=no version=3.2.0-pre1-r499012 Received: from ventoso.org (61.pool85-52-226.static.orange.es [85.52.226.61]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l89EwD4p005771 for ; Sun, 9 Sep 2007 07:58:15 -0700 Received: from [192.168.10.30] (unknown [192.168.10.30]) by ventoso.org (Postfix) with ESMTP id 0EE16C34FB3 for ; Sun, 9 Sep 2007 16:38:05 +0200 (CEST) Message-ID: <46E40553.2010804@ventoso.org> Date: Sun, 09 Sep 2007 16:38:11 +0200 From: Luca Olivetti User-Agent: Thunderbird 2.0.0.4 (X11/20070620) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: Not able to register References: <46E3471D.7020408@sandeen.net> <46E35C28.4060301@sandeen.net> In-Reply-To: <46E35C28.4060301@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12796 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: luca@ventoso.org Precedence: bulk X-list: xfs En/na Eric Sandeen ha escrit: > > Ok, for what it's worth, I just successfully subscribed my redhat.com > email. For those having trouble... details please. Well, it's the 4st time in the last couple of weeks that I try to subscribe and my subscribe message is silently ignored (I cannot see in my logs any sgi server trying to send me mail). Bye -- Luca From owner-xfs@oss.sgi.com Sun Sep 9 08:39:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 08:39:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l89Fdl4p015134 for ; Sun, 9 Sep 2007 08:39:48 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l89FdlA5020024 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 9 Sep 2007 17:39:47 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l89Fdlwr020022 for xfs@oss.sgi.com; Sun, 9 Sep 2007 17:39:47 +0200 Date: Sun, 9 Sep 2007 17:39:47 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] kill BMAPI_DEVICE Message-ID: <20070909153947.GA19986@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12797 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs There is no reason to go into the iomap machinery just to get the right block device for an inode. Instead look at the realtime flag in the inode and grab the right device from the mount structure. I created a new helper, xfs_find_bdev_for_inode instead of opencoding it because I plan to use it in other places in the future. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2007-08-23 14:54:01.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c 2007-08-23 14:59:55.000000000 +0200 @@ -107,6 +107,18 @@ xfs_page_trace( #define xfs_page_trace(tag, inode, page, pgoff) #endif +STATIC struct block_device * +xfs_find_bdev_for_inode( + struct xfs_inode *ip) +{ + struct xfs_mount *mp = ip->i_mount; + + if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) + return mp->m_rtdev_targp->bt_bdev; + else + return mp->m_ddev_targp->bt_bdev; +} + /* * Schedule IO completion handling on a xfsdatad if this was * the final hold on this ioend. If we are asked to wait, @@ -1476,28 +1488,21 @@ xfs_vm_direct_IO( { struct file *file = iocb->ki_filp; struct inode *inode = file->f_mapping->host; - xfs_iomap_t iomap; - int maps = 1; - int error; + struct block_device *bdev; ssize_t ret; - error = xfs_bmap(XFS_I(inode), offset, 0, - BMAPI_DEVICE, &iomap, &maps); - if (error) - return -error; + bdev = xfs_find_bdev_for_inode(XFS_I(inode)); if (rw == WRITE) { iocb->private = xfs_alloc_ioend(inode, IOMAP_UNWRITTEN); ret = blockdev_direct_IO_own_locking(rw, iocb, inode, - iomap.iomap_target->bt_bdev, - iov, offset, nr_segs, + bdev, iov, offset, nr_segs, xfs_get_blocks_direct, xfs_end_io_direct); } else { iocb->private = xfs_alloc_ioend(inode, IOMAP_READ); ret = blockdev_direct_IO_no_locking(rw, iocb, inode, - iomap.iomap_target->bt_bdev, - iov, offset, nr_segs, + bdev, iov, offset, nr_segs, xfs_get_blocks_direct, xfs_end_io_direct); } Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c 2007-08-23 14:39:45.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c 2007-08-23 14:59:55.000000000 +0200 @@ -193,7 +193,7 @@ xfs_iomap( switch (flags & (BMAPI_READ | BMAPI_WRITE | BMAPI_ALLOCATE | - BMAPI_UNWRITTEN | BMAPI_DEVICE)) { + BMAPI_UNWRITTEN)) { case BMAPI_READ: xfs_iomap_enter_trace(XFS_IOMAP_READ_ENTER, io, offset, count); lockmode = XFS_LCK_MAP_SHARED(mp, io); @@ -220,13 +220,6 @@ xfs_iomap( break; case BMAPI_UNWRITTEN: goto phase2; - case BMAPI_DEVICE: - lockmode = XFS_LCK_MAP_SHARED(mp, io); - iomapp->iomap_target = io->io_flags & XFS_IOCORE_RT ? - mp->m_rtdev_targp : mp->m_ddev_targp; - error = 0; - *niomaps = 1; - goto out; default: BUG(); } Index: linux-2.6-xfs/fs/xfs/xfs_iomap.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.h 2007-08-23 14:39:45.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.h 2007-08-23 14:59:55.000000000 +0200 @@ -43,7 +43,6 @@ typedef enum { BMAPI_MMAP = (1 << 6), /* allocate for mmap write */ BMAPI_SYNC = (1 << 7), /* sync write to flush delalloc space */ BMAPI_TRYLOCK = (1 << 8), /* non-blocking request */ - BMAPI_DEVICE = (1 << 9), /* we only want to know the device */ } bmapi_flags_t; From owner-xfs@oss.sgi.com Sun Sep 9 08:41:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 08:41:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l89Ff34p015515 for ; Sun, 9 Sep 2007 08:41:05 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l89Ff3A5020062 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 9 Sep 2007 17:41:03 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l89Ff3Qm020060 for xfs@oss.sgi.com; Sun, 9 Sep 2007 17:41:03 +0200 Date: Sun, 9 Sep 2007 17:41:03 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] kill BMAPI_UNWRITTEN Message-ID: <20070909154103.GB19986@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12798 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs There is no reason to go through xfs_iomap for the BMAPI_UNWRITTEN because it has nothing in common with the other cases. Instead check for the shutdown filesystem in xfs_end_bio_unwritten and perform a direct call to xfs_iomap_write_unwritten (which should be renamed to something more sensible one day) Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2007-09-06 10:18:05.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c 2007-09-06 10:18:05.000000000 +0200 @@ -237,12 +237,13 @@ xfs_end_bio_unwritten( { xfs_ioend_t *ioend = container_of(work, xfs_ioend_t, io_work); + struct xfs_inode *ip = XFS_I(ioend->io_inode); xfs_off_t offset = ioend->io_offset; size_t size = ioend->io_size; if (likely(!ioend->io_error)) { - xfs_bmap(XFS_I(ioend->io_inode), offset, size, - BMAPI_UNWRITTEN, NULL, NULL); + if (!XFS_FORCED_SHUTDOWN(ip->i_mount)) + xfs_iomap_write_unwritten(ip, offset, size); xfs_setfilesize(ioend); } xfs_destroy_ioend(ioend); Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c 2007-09-06 10:18:05.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c 2007-09-06 10:18:05.000000000 +0200 @@ -191,9 +191,7 @@ xfs_iomap( if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); - switch (flags & - (BMAPI_READ | BMAPI_WRITE | BMAPI_ALLOCATE | - BMAPI_UNWRITTEN)) { + switch (flags & (BMAPI_READ | BMAPI_WRITE | BMAPI_ALLOCATE)) { case BMAPI_READ: xfs_iomap_enter_trace(XFS_IOMAP_READ_ENTER, io, offset, count); lockmode = XFS_LCK_MAP_SHARED(mp, io); @@ -218,8 +216,6 @@ xfs_iomap( XFS_ILOCK(mp, io, lockmode); } break; - case BMAPI_UNWRITTEN: - goto phase2; default: BUG(); } @@ -238,8 +234,7 @@ xfs_iomap( if (error) goto out; -phase2: - switch (flags & (BMAPI_WRITE|BMAPI_ALLOCATE|BMAPI_UNWRITTEN)) { + switch (flags & (BMAPI_WRITE|BMAPI_ALLOCATE)) { case BMAPI_WRITE: /* If we found an extent, return it */ if (nimaps && @@ -277,11 +272,6 @@ phase2: error = XFS_IOMAP_WRITE_ALLOCATE(mp, io, offset, count, &imap, &nimaps); break; - case BMAPI_UNWRITTEN: - lockmode = 0; - error = XFS_IOMAP_WRITE_UNWRITTEN(mp, io, offset, count); - nimaps = 0; - break; } if (nimaps) { Index: linux-2.6-xfs/fs/xfs/xfs_iomap.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.h 2007-09-06 10:18:05.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.h 2007-09-06 10:18:05.000000000 +0200 @@ -36,7 +36,6 @@ typedef enum { BMAPI_READ = (1 << 0), /* read extents */ BMAPI_WRITE = (1 << 1), /* create extents */ BMAPI_ALLOCATE = (1 << 2), /* delayed allocate to real extents */ - BMAPI_UNWRITTEN = (1 << 3), /* unwritten extents to real extents */ /* modifiers */ BMAPI_IGNSTATE = (1 << 4), /* ignore unwritten state on read */ BMAPI_DIRECT = (1 << 5), /* direct instead of buffered write */ From owner-xfs@oss.sgi.com Sun Sep 9 08:42:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 08:42:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l89FgK4p016041 for ; Sun, 9 Sep 2007 08:42:21 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l89FgKA5020109 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 9 Sep 2007 17:42:21 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l89FgK93020107 for xfs@oss.sgi.com; Sun, 9 Sep 2007 17:42:20 +0200 Date: Sun, 9 Sep 2007 17:42:20 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] remove dead SYNC_BDFLUSH case in xfs_sync_inodes Message-ID: <20070909154220.GC19986@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12799 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs A large part of xfs_sync_inodes is conditional on the SYNC_BDFLUSH which is never passed to it. This patch removes it and adds an assert that triggers in case some new code tries to pass SYNC_BDFLUSH to it. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-09-08 17:43:39.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-09-08 19:06:31.000000000 +0200 @@ -981,8 +981,6 @@ xfs_sync_inodes( int *bypassed) { xfs_inode_t *ip = NULL; - xfs_inode_t *ip_next; - xfs_buf_t *bp; bhv_vnode_t *vp = NULL; int error; int last_error; @@ -992,7 +990,6 @@ xfs_sync_inodes( boolean_t mount_locked; boolean_t vnode_refed; int preempt; - xfs_dinode_t *dip; xfs_iptr_t *ipointer; #ifdef DEBUG boolean_t ipointer_in = B_FALSE; @@ -1045,6 +1042,8 @@ xfs_sync_inodes( #define XFS_PREEMPT_MASK 0x7f + ASSERT(!(flags & SYNC_BDFLUSH)); + if (bypassed) *bypassed = 0; if (mp->m_flags & XFS_MOUNT_RDONLY) @@ -1057,7 +1056,7 @@ xfs_sync_inodes( ipointer = (xfs_iptr_t *)kmem_zalloc(sizeof(xfs_iptr_t), KM_SLEEP); fflag = XFS_B_ASYNC; /* default is don't wait */ - if (flags & (SYNC_BDFLUSH | SYNC_DELWRI)) + if (flags & SYNC_DELWRI) fflag = XFS_B_DELWRI; if (flags & SYNC_WAIT) fflag = 0; /* synchronous overrides all */ @@ -1147,24 +1146,6 @@ xfs_sync_inodes( } /* - * If this is just vfs_sync() or pflushd() calling - * then we can skip inodes for which it looks like - * there is nothing to do. Since we don't have the - * inode locked this is racy, but these are periodic - * calls so it doesn't matter. For the others we want - * to know for sure, so we at least try to lock them. - */ - if (flags & SYNC_BDFLUSH) { - if (((ip->i_itemp == NULL) || - !(ip->i_itemp->ili_format.ilf_fields & - XFS_ILOG_ALL)) && - (ip->i_update_core == 0)) { - ip = ip->i_mnext; - continue; - } - } - - /* * Try to lock without sleeping. We're out of order with * the inode list lock here, so if we fail we need to drop * the mount lock and try again. If we're called from @@ -1181,7 +1162,7 @@ xfs_sync_inodes( * it. */ if (xfs_ilock_nowait(ip, lock_flags) == 0) { - if ((flags & SYNC_BDFLUSH) || (vp == NULL)) { + if (vp == NULL) { ip = ip->i_mnext; continue; } @@ -1242,160 +1223,27 @@ xfs_sync_inodes( xfs_ilock(ip, XFS_ILOCK_SHARED); } - if (flags & SYNC_BDFLUSH) { - if ((flags & SYNC_ATTR) && - ((ip->i_update_core) || - ((ip->i_itemp != NULL) && - (ip->i_itemp->ili_format.ilf_fields != 0)))) { - - /* Insert marker and drop lock if not already - * done. - */ - if (mount_locked) { - IPOINTER_INSERT(ip, mp); - } - - /* - * We don't want the periodic flushing of the - * inodes by vfs_sync() to interfere with - * I/O to the file, especially read I/O - * where it is only the access time stamp - * that is being flushed out. To prevent - * long periods where we have both inode - * locks held shared here while reading the - * inode's buffer in from disk, we drop the - * inode lock while reading in the inode - * buffer. We have to release the buffer - * and reacquire the inode lock so that they - * are acquired in the proper order (inode - * locks first). The buffer will go at the - * end of the lru chain, though, so we can - * expect it to still be there when we go - * for it again in xfs_iflush(). - */ - if ((xfs_ipincount(ip) == 0) && - xfs_iflock_nowait(ip)) { - - xfs_ifunlock(ip); - xfs_iunlock(ip, XFS_ILOCK_SHARED); - - error = xfs_itobp(mp, NULL, ip, - &dip, &bp, 0, 0); - if (!error) { - xfs_buf_relse(bp); - } else { - /* Bailing out, remove the - * marker and free it. - */ - XFS_MOUNT_ILOCK(mp); - IPOINTER_REMOVE(ip, mp); - XFS_MOUNT_IUNLOCK(mp); - - ASSERT(!(lock_flags & - XFS_IOLOCK_SHARED)); - - kmem_free(ipointer, - sizeof(xfs_iptr_t)); - return (0); - } - - /* - * Since we dropped the inode lock, - * the inode may have been reclaimed. - * Therefore, we reacquire the mount - * lock and check to see if we were the - * inode reclaimed. If this happened - * then the ipointer marker will no - * longer point back at us. In this - * case, move ip along to the inode - * after the marker, remove the marker - * and continue. - */ - XFS_MOUNT_ILOCK(mp); - mount_locked = B_TRUE; - - if (ip != ipointer->ip_mprev) { - IPOINTER_REMOVE(ip, mp); - - ASSERT(!vnode_refed); - ASSERT(!(lock_flags & - XFS_IOLOCK_SHARED)); - continue; - } - - ASSERT(ip->i_mount == mp); - - if (xfs_ilock_nowait(ip, - XFS_ILOCK_SHARED) == 0) { - ASSERT(ip->i_mount == mp); - /* - * We failed to reacquire - * the inode lock without - * sleeping, so just skip - * the inode for now. We - * clear the ILOCK bit from - * the lock_flags so that we - * won't try to drop a lock - * we don't hold below. - */ - lock_flags &= ~XFS_ILOCK_SHARED; - IPOINTER_REMOVE(ip_next, mp); - } else if ((xfs_ipincount(ip) == 0) && - xfs_iflock_nowait(ip)) { - ASSERT(ip->i_mount == mp); - /* - * Since this is vfs_sync() - * calling we only flush the - * inode out if we can lock - * it without sleeping and - * it is not pinned. Drop - * the mount lock here so - * that we don't hold it for - * too long. We already have - * a marker in the list here. - */ - XFS_MOUNT_IUNLOCK(mp); - mount_locked = B_FALSE; - error = xfs_iflush(ip, - XFS_IFLUSH_DELWRI); - } else { - ASSERT(ip->i_mount == mp); - IPOINTER_REMOVE(ip_next, mp); - } - } - - } + if ((flags & SYNC_ATTR) && + (ip->i_update_core || + (ip->i_itemp && ip->i_itemp->ili_format.ilf_fields))) { + if (mount_locked) + IPOINTER_INSERT(ip, mp); - } else { - if ((flags & SYNC_ATTR) && - ((ip->i_update_core) || - ((ip->i_itemp != NULL) && - (ip->i_itemp->ili_format.ilf_fields != 0)))) { - if (mount_locked) { - IPOINTER_INSERT(ip, mp); - } + if (flags & SYNC_WAIT) { + xfs_iflock(ip); + error = xfs_iflush(ip, XFS_IFLUSH_SYNC); - if (flags & SYNC_WAIT) { - xfs_iflock(ip); - error = xfs_iflush(ip, - XFS_IFLUSH_SYNC); - } else { - /* - * If we can't acquire the flush - * lock, then the inode is already - * being flushed so don't bother - * waiting. If we can lock it then - * do a delwri flush so we can - * combine multiple inode flushes - * in each disk write. - */ - if (xfs_iflock_nowait(ip)) { - error = xfs_iflush(ip, - XFS_IFLUSH_DELWRI); - } - else if (bypassed) - (*bypassed)++; - } + /* + * If we can't acquire the flush lock, then the inode + * is already being flushed so don't bother waiting. + * + * If we can lock it then do a delwri flush so we can + * combine multiple inode flushes in each disk write. + */ + } else if (xfs_iflock_nowait(ip)) { + error = xfs_iflush(ip, XFS_IFLUSH_DELWRI); + } else if (bypassed) { + (*bypassed)++; } } From owner-xfs@oss.sgi.com Sun Sep 9 09:03:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 09:03:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_20,RDNS_DYNAMIC autolearn=no version=3.2.0-pre1-r499012 Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l89G3V4p019016 for ; Sun, 9 Sep 2007 09:03:35 -0700 Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id l89EvNxw014406 for ; Sun, 9 Sep 2007 07:57:24 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id l89EvMcF021414 for ; Sun, 9 Sep 2007 07:57:23 -0700 Received: from [127.0.0.1] ([10.123.0.56]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 07:57:30 -0700 Message-ID: <46E409F1.4090001@agami.com> Date: Sun, 09 Sep 2007 07:57:53 -0700 From: Michael Nishimoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josef Sipek CC: Eric Sandeen , Bhagi rathi , xfs@oss.sgi.com, trev@sgi.com, Russell Cattelan , ralf@linux-mips.org Subject: Re: Not able to register References: <46E3471D.7020408@sandeen.net> <46E35C28.4060301@sandeen.net> <20070909065143.GA6787@filer.fsl.cs.sunysb.edu> In-Reply-To: <20070909065143.GA6787@filer.fsl.cs.sunysb.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Sep 2007 14:57:30.0568 (UTC) FILETIME=[BECFD480:01C7F2F1] X-Scanned-By: MIMEDefang 2.58 on 192.168.168.13 X-archive-position: 12800 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: miken@agami.com Precedence: bulk X-list: xfs Josef Sipek wrote: > On Sat, Sep 08, 2007 at 09:36:24PM -0500, Eric Sandeen wrote: > > Eric Sandeen wrote: > > > Bhagi rathi wrote: > > >> I am not able to register to xfs mailing list through ecartis. > > >> I am doing what is said on the webpage > > >> > > >> http://oss.sgi.com/projects/xfs/mail.html > > >> > > >> is there a problem with the xfs-mailing list ? > > >> Can someone look into this? > > > > > > Trev, Russell, Ralf... this is about the 3rd complaint about ecartis, > > > any of you know what might be up? > > > > > > -Eric > > > > > > > > > > Ok, for what it's worth, I just successfully subscribed my redhat.com > > email. For those having trouble... details please. > > Interesting observation: all 3 complaints were from @gmail.com users. > > Josef 'Jeff' Sipek. > > -- > NT is to UNIX what a doughnut is to a particle accelerator. > > In the past when I spoke with Russell, gmail subscribes look like spam to the ecartis server. Mike From owner-xfs@oss.sgi.com Sun Sep 9 09:10:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 09:10:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_50,MIME_8BIT_HEADER autolearn=no version=3.2.0-pre1-r499012 Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l89GAs4p020296 for ; Sun, 9 Sep 2007 09:10:56 -0700 Received: by rv-out-0910.google.com with SMTP id k20so788484rvb for ; Sun, 09 Sep 2007 09:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=k4bI2FGK7h2JsLAWb/3WEz3TzFIbGk1n5SIDQEtXYwc=; b=YEgMpGTLzy2EvYWDF4LYQfcERclmJYm4BBGAnd6E8MW1p0lj+ES1riuDWXyrckW58h8OolfFlJ/ZRuihKSKpLgQ2kH3g1g/ErUltAUuBJCtov4JjFCbkLARKk2geCm9yrERGXbMuS/wPe5lXEMuQKTRlxgifEXUzXTLRhSSXCTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=FUFKUl4Hs9+IjKrR1D03c8j/wyQwcpyk5BcwHw8UkqemxEVOPGfOETGN6uaYjkO8Al2gW6vF+F5wVMGg5GS1wk8CiU5bYhFX13saBmZoBNM0n/CaJTmOwSKf1gZ13HcDaD/TOVzanVbpG9lgfuNtR2uyGVsUBmdgrKwJOtAfAXk= Received: by 10.141.83.15 with SMTP id k15mr1531050rvl.1189354255704; Sun, 09 Sep 2007 09:10:55 -0700 (PDT) Received: by 10.141.201.19 with HTTP; Sun, 9 Sep 2007 09:10:55 -0700 (PDT) Message-ID: <68c491a60709090910t3bd37e7bxfec773f58a55224d@mail.gmail.com> Date: Sun, 9 Sep 2007 18:10:55 +0200 From: "=?ISO-8859-1?Q?Martin_Schr=F6der?=" To: xfs@oss.sgi.com Subject: Re: Not able to register In-Reply-To: <46E409F1.4090001@agami.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46E3471D.7020408@sandeen.net> <46E35C28.4060301@sandeen.net> <20070909065143.GA6787@filer.fsl.cs.sunysb.edu> <46E409F1.4090001@agami.com> X-Google-Sender-Auth: b436bb0bbbcd8f7a X-archive-position: 12801 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: martin@oneiros.de Precedence: bulk X-list: xfs 2007/9/9, Michael Nishimoto : > In the past when I spoke with Russell, gmail subscribes > look like spam to the ecartis server. Then ecartis is broken. Since it seems very stale (last released version is from 2000, since then only snapshots), maybe you should switch to something more vital? Mailman comes to mind... Best Martin From owner-xfs@oss.sgi.com Sun Sep 9 12:32:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 12:32:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l89JW74p016495 for ; Sun, 9 Sep 2007 12:32:09 -0700 Received: by wa-out-1112.google.com with SMTP id k22so1416136waf for ; Sun, 09 Sep 2007 12:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=lKELXtSTe277uPCKiEjgJdVsJ3yxgeQxXNdRHAR/DeU=; b=B+OaMokuy0kgcFqUNbFkQrWDygK5aZNqVw2DrNPzeQE0KSfLP7w8De1qbo01R4jaLGRA6wK48X/MtoygdI3vmQzLi6/BqftkuvIKSu3ZZzaM4KDCr72Bt8Y7u4uGefLTzt2FG5eOIKOLGc8Un4tJW/QFWIFfekqkHQhENLEJecY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lQRJCAvf6hMIXe0t8oFhRbAtjJPy9tIfSYzWqiBm+lH4wwc+A3hH65Whz2CvTMIspaZvnmCdzIbg8epWQ8cuVs3BqfH/po/2bKzAZyyRNLBP3ghVLa98JkMTOrKiA1a/PdwNWl5/tE2ugE1dxICCh9PKwqeUT0ZRA3tiF/B7SYI= Received: by 10.114.173.15 with SMTP id v15mr3181878wae.1189366328008; Sun, 09 Sep 2007 12:32:08 -0700 (PDT) Received: by 10.114.171.20 with HTTP; Sun, 9 Sep 2007 12:32:07 -0700 (PDT) Message-ID: Date: Mon, 10 Sep 2007 01:02:07 +0530 From: "Bhagi rathi" To: "Christoph Hellwig" Subject: Re: [PATCH] kill BMAPI_DEVICE Cc: xfs@oss.sgi.com In-Reply-To: <20070909153947.GA19986@lst.de> MIME-Version: 1.0 References: <20070909153947.GA19986@lst.de> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 5167 X-archive-position: 12802 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs XFS_IOCORE_RT | XFS_DIFLAG_REALTIME can be set from an ioctl (xfs_setattr). A directIO without holding ILOCK in shared in mode can read a wrong value of di_flag for real time decision. As a result, we may pass in-correct device during directIO as the proposed xfs_find_bdev_for_inode doesn't hold any lock in reading the flags. It is not based on iocore flags as well. On a secondary note, XFS_IOCORE_RT was set without holding iolock which seems to an issue. I tend to leave xfs_bmapi to decide BMAPI_DEVICE to xfs_iomap. What is the reason why this has to be seperated? Thanks, -Saradhi. On 9/9/07, Christoph Hellwig wrote: > > There is no reason to go into the iomap machinery just to get the > right block device for an inode. Instead look at the realtime flag > in the inode and grab the right device from the mount structure. > > I created a new helper, xfs_find_bdev_for_inode instead of opencoding > it because I plan to use it in other places in the future. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2007-08-23 14:54: > 01.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c 2007-08-23 14:59: > 55.000000000 +0200 > @@ -107,6 +107,18 @@ xfs_page_trace( > #define xfs_page_trace(tag, inode, page, pgoff) > #endif > > +STATIC struct block_device * > +xfs_find_bdev_for_inode( > + struct xfs_inode *ip) > +{ > + struct xfs_mount *mp = ip->i_mount; > + > + if (ip->i_d.di_flags & XFS_DIFLAG_REALTIME) > + return mp->m_rtdev_targp->bt_bdev; > + else > + return mp->m_ddev_targp->bt_bdev; > +} > + > /* > * Schedule IO completion handling on a xfsdatad if this was > * the final hold on this ioend. If we are asked to wait, > @@ -1476,28 +1488,21 @@ xfs_vm_direct_IO( > { > struct file *file = iocb->ki_filp; > struct inode *inode = file->f_mapping->host; > - xfs_iomap_t iomap; > - int maps = 1; > - int error; > + struct block_device *bdev; > ssize_t ret; > > - error = xfs_bmap(XFS_I(inode), offset, 0, > - BMAPI_DEVICE, &iomap, &maps); > - if (error) > - return -error; > + bdev = xfs_find_bdev_for_inode(XFS_I(inode)); > > if (rw == WRITE) { > iocb->private = xfs_alloc_ioend(inode, IOMAP_UNWRITTEN); > ret = blockdev_direct_IO_own_locking(rw, iocb, inode, > - iomap.iomap_target->bt_bdev, > - iov, offset, nr_segs, > + bdev, iov, offset, nr_segs, > xfs_get_blocks_direct, > xfs_end_io_direct); > } else { > iocb->private = xfs_alloc_ioend(inode, IOMAP_READ); > ret = blockdev_direct_IO_no_locking(rw, iocb, inode, > - iomap.iomap_target->bt_bdev, > - iov, offset, nr_segs, > + bdev, iov, offset, nr_segs, > xfs_get_blocks_direct, > xfs_end_io_direct); > } > Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c 2007-08-23 14:39: > 45.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c 2007-08-23 14:59:55.000000000+0200 > @@ -193,7 +193,7 @@ xfs_iomap( > > switch (flags & > (BMAPI_READ | BMAPI_WRITE | BMAPI_ALLOCATE | > - BMAPI_UNWRITTEN | BMAPI_DEVICE)) { > + BMAPI_UNWRITTEN)) { > case BMAPI_READ: > xfs_iomap_enter_trace(XFS_IOMAP_READ_ENTER, io, offset, > count); > lockmode = XFS_LCK_MAP_SHARED(mp, io); > @@ -220,13 +220,6 @@ xfs_iomap( > break; > case BMAPI_UNWRITTEN: > goto phase2; > - case BMAPI_DEVICE: > - lockmode = XFS_LCK_MAP_SHARED(mp, io); > - iomapp->iomap_target = io->io_flags & XFS_IOCORE_RT ? > - mp->m_rtdev_targp : mp->m_ddev_targp; > - error = 0; > - *niomaps = 1; > - goto out; > default: > BUG(); > } > Index: linux-2.6-xfs/fs/xfs/xfs_iomap.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.h 2007-08-23 14:39: > 45.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_iomap.h 2007-08-23 14:59:55.000000000+0200 > @@ -43,7 +43,6 @@ typedef enum { > BMAPI_MMAP = (1 << 6), /* allocate for mmap write */ > BMAPI_SYNC = (1 << 7), /* sync write to flush delalloc > space */ > BMAPI_TRYLOCK = (1 << 8), /* non-blocking request */ > - BMAPI_DEVICE = (1 << 9), /* we only want to know the device > */ > } bmapi_flags_t; > > > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sun Sep 9 12:34:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 12:34:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l89JYs4p017058 for ; Sun, 9 Sep 2007 12:34:55 -0700 Received: by wa-out-1112.google.com with SMTP id k22so1416783waf for ; Sun, 09 Sep 2007 12:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=rLzUbQfaoSZH7QAJQwJUh78qiYuow6TlhJal1Goyobc=; b=SHoAj0xqCJ7MneiFp8qAR2MdLnxPL3RP/ZXbjvJq/bw9qHN0mb0tnbsAYURroXyUzjhKyBcxqh0sFOxr22c6e1DMkHaQRk0ZqnmMFNfTetye1dFacJUVnPl6MZIh9ePTdHlgPcRYwVlNFm8lvLtgKs5XfBzfozVRTCAc7+SWLGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=VDFSMerX3OYRpZtgswiw91fg0fZITtYuIwC4zBWR3E2vsdnMfqbx+JcfQK5S+18lQp4wndT7Knlt+rJ5u0v6Re48VI2323OEg1v8GKogtZ2RQbQK3R4ttUr1lQeefST8LEpbRWt5iyxE3qIOkFcLOeZEhYqd5iE1M1eWN3358PE= Received: by 10.114.12.9 with SMTP id 9mr3158693wal.1189366495683; Sun, 09 Sep 2007 12:34:55 -0700 (PDT) Received: by 10.114.171.20 with HTTP; Sun, 9 Sep 2007 12:34:55 -0700 (PDT) Message-ID: Date: Mon, 10 Sep 2007 01:04:55 +0530 From: "Bhagi rathi" To: "Christoph Hellwig" Subject: Re: [PATCH] kill BMAPI_UNWRITTEN Cc: xfs@oss.sgi.com In-Reply-To: <20070909154103.GB19986@lst.de> MIME-Version: 1.0 References: <20070909154103.GB19986@lst.de> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 4274 X-archive-position: 12803 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs The reason for eliminating BMAPI_UNWRITTEN is not clear. It is ideal to keep all the block map interfaces and information to go through xfs_iomap, xfs_bmapi functionality. Thanks, -Saradhi. On 9/9/07, Christoph Hellwig wrote: > > There is no reason to go through xfs_iomap for the BMAPI_UNWRITTEN > because it has nothing in common with the other cases. Instead > check for the shutdown filesystem in xfs_end_bio_unwritten and perform > a direct call to xfs_iomap_write_unwritten (which should be renamed > to something more sensible one day) > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2007-09-06 10:18: > 05.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c 2007-09-06 10:18: > 05.000000000 +0200 > @@ -237,12 +237,13 @@ xfs_end_bio_unwritten( > { > xfs_ioend_t *ioend = > container_of(work, xfs_ioend_t, io_work); > + struct xfs_inode *ip = XFS_I(ioend->io_inode); > xfs_off_t offset = ioend->io_offset; > size_t size = ioend->io_size; > > if (likely(!ioend->io_error)) { > - xfs_bmap(XFS_I(ioend->io_inode), offset, size, > - BMAPI_UNWRITTEN, NULL, NULL); > + if (!XFS_FORCED_SHUTDOWN(ip->i_mount)) > + xfs_iomap_write_unwritten(ip, offset, size); > xfs_setfilesize(ioend); > } > xfs_destroy_ioend(ioend); > Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c 2007-09-06 10:18: > 05.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c 2007-09-06 10:18:05.000000000+0200 > @@ -191,9 +191,7 @@ xfs_iomap( > if (XFS_FORCED_SHUTDOWN(mp)) > return XFS_ERROR(EIO); > > - switch (flags & > - (BMAPI_READ | BMAPI_WRITE | BMAPI_ALLOCATE | > - BMAPI_UNWRITTEN)) { > + switch (flags & (BMAPI_READ | BMAPI_WRITE | BMAPI_ALLOCATE)) { > case BMAPI_READ: > xfs_iomap_enter_trace(XFS_IOMAP_READ_ENTER, io, offset, > count); > lockmode = XFS_LCK_MAP_SHARED(mp, io); > @@ -218,8 +216,6 @@ xfs_iomap( > XFS_ILOCK(mp, io, lockmode); > } > break; > - case BMAPI_UNWRITTEN: > - goto phase2; > default: > BUG(); > } > @@ -238,8 +234,7 @@ xfs_iomap( > if (error) > goto out; > > -phase2: > - switch (flags & (BMAPI_WRITE|BMAPI_ALLOCATE|BMAPI_UNWRITTEN)) { > + switch (flags & (BMAPI_WRITE|BMAPI_ALLOCATE)) { > case BMAPI_WRITE: > /* If we found an extent, return it */ > if (nimaps && > @@ -277,11 +272,6 @@ phase2: > error = XFS_IOMAP_WRITE_ALLOCATE(mp, io, offset, count, > &imap, &nimaps); > break; > - case BMAPI_UNWRITTEN: > - lockmode = 0; > - error = XFS_IOMAP_WRITE_UNWRITTEN(mp, io, offset, count); > - nimaps = 0; > - break; > } > > if (nimaps) { > Index: linux-2.6-xfs/fs/xfs/xfs_iomap.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.h 2007-09-06 10:18: > 05.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_iomap.h 2007-09-06 10:18:05.000000000+0200 > @@ -36,7 +36,6 @@ typedef enum { > BMAPI_READ = (1 << 0), /* read extents */ > BMAPI_WRITE = (1 << 1), /* create extents */ > BMAPI_ALLOCATE = (1 << 2), /* delayed allocate to real > extents */ > - BMAPI_UNWRITTEN = (1 << 3), /* unwritten extents to real > extents */ > /* modifiers */ > BMAPI_IGNSTATE = (1 << 4), /* ignore unwritten state on read > */ > BMAPI_DIRECT = (1 << 5), /* direct instead of buffered > write */ > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sun Sep 9 12:43:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 12:43:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l89Jh04p018195 for ; Sun, 9 Sep 2007 12:43:01 -0700 Received: by wa-out-1112.google.com with SMTP id k22so1418612waf for ; Sun, 09 Sep 2007 12:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=M0VUdZxhLeTEZNgRLz7e+Y5+fWbOjKcK4jI4qI818n8=; b=p/BuOu0wGzYNRYZUp3bx53jvTJDoSRYSbsmZp7Eo782h8FqJbck2nKiTvzcItYdKGcmgvbTDW5fiV56wor5quZba8QhS4h5nsalW2okZeF7zL6O9u0DCwXNEysQXg0bkrtichDJW3X/Fit1kVAPxqbf+VqTO51giOiIf1ArF9+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Gs3NQqd+Hp0zHu6gAnDqYv04+oKwNRMMEeFfxtkFl9i8t/0kzhb/M3ZB1FMuteSMNQLbr4us1adzTtE82Av0S+JdtjSb9ON0b6sZQHl3lw1Ml57EE5YUKEHOIYbb1+syPqe79c+dCjkxVWBVpgFN8c8SE+KezCmUjVtDcWVo/WI= Received: by 10.114.209.1 with SMTP id h1mr8627wag.1189366981442; Sun, 09 Sep 2007 12:43:01 -0700 (PDT) Received: by 10.114.171.20 with HTTP; Sun, 9 Sep 2007 12:43:01 -0700 (PDT) Message-ID: Date: Mon, 10 Sep 2007 01:13:01 +0530 From: "Bhagi rathi" To: "Christoph Hellwig" Subject: Re: [PATCH] remove dead SYNC_BDFLUSH case in xfs_sync_inodes Cc: xfs@oss.sgi.com In-Reply-To: <20070909154220.GC19986@lst.de> MIME-Version: 1.0 References: <20070909154220.GC19986@lst.de> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 14261 X-archive-position: 12804 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs vfs_sync_worker calls with SYNC_BDFLUSH. xfssyncd can call this. I might be missing something if this is not used. Thanks, -Saradhi. On 9/9/07, Christoph Hellwig wrote: > > A large part of xfs_sync_inodes is conditional on the SYNC_BDFLUSH which > is never passed to it. This patch removes it and adds an assert that > triggers in case some new code tries to pass SYNC_BDFLUSH to it. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-09-08 17:43: > 39.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-09-08 19:06:31.000000000+0200 > @@ -981,8 +981,6 @@ xfs_sync_inodes( > int *bypassed) > { > xfs_inode_t *ip = NULL; > - xfs_inode_t *ip_next; > - xfs_buf_t *bp; > bhv_vnode_t *vp = NULL; > int error; > int last_error; > @@ -992,7 +990,6 @@ xfs_sync_inodes( > boolean_t mount_locked; > boolean_t vnode_refed; > int preempt; > - xfs_dinode_t *dip; > xfs_iptr_t *ipointer; > #ifdef DEBUG > boolean_t ipointer_in = B_FALSE; > @@ -1045,6 +1042,8 @@ xfs_sync_inodes( > > #define XFS_PREEMPT_MASK 0x7f > > + ASSERT(!(flags & SYNC_BDFLUSH)); > + > if (bypassed) > *bypassed = 0; > if (mp->m_flags & XFS_MOUNT_RDONLY) > @@ -1057,7 +1056,7 @@ xfs_sync_inodes( > ipointer = (xfs_iptr_t *)kmem_zalloc(sizeof(xfs_iptr_t), > KM_SLEEP); > > fflag = XFS_B_ASYNC; /* default is don't wait */ > - if (flags & (SYNC_BDFLUSH | SYNC_DELWRI)) > + if (flags & SYNC_DELWRI) > fflag = XFS_B_DELWRI; > if (flags & SYNC_WAIT) > fflag = 0; /* synchronous overrides all */ > @@ -1147,24 +1146,6 @@ xfs_sync_inodes( > } > > /* > - * If this is just vfs_sync() or pflushd() calling > - * then we can skip inodes for which it looks like > - * there is nothing to do. Since we don't have the > - * inode locked this is racy, but these are periodic > - * calls so it doesn't matter. For the others we want > - * to know for sure, so we at least try to lock them. > - */ > - if (flags & SYNC_BDFLUSH) { > - if (((ip->i_itemp == NULL) || > - !(ip->i_itemp->ili_format.ilf_fields & > - XFS_ILOG_ALL)) && > - (ip->i_update_core == 0)) { > - ip = ip->i_mnext; > - continue; > - } > - } > - > - /* > * Try to lock without sleeping. We're out of order with > * the inode list lock here, so if we fail we need to drop > * the mount lock and try again. If we're called from > @@ -1181,7 +1162,7 @@ xfs_sync_inodes( > * it. > */ > if (xfs_ilock_nowait(ip, lock_flags) == 0) { > - if ((flags & SYNC_BDFLUSH) || (vp == NULL)) { > + if (vp == NULL) { > ip = ip->i_mnext; > continue; > } > @@ -1242,160 +1223,27 @@ xfs_sync_inodes( > xfs_ilock(ip, XFS_ILOCK_SHARED); > } > > - if (flags & SYNC_BDFLUSH) { > - if ((flags & SYNC_ATTR) && > - ((ip->i_update_core) || > - ((ip->i_itemp != NULL) && > - (ip->i_itemp->ili_format.ilf_fields != 0)))) > { > - > - /* Insert marker and drop lock if not > already > - * done. > - */ > - if (mount_locked) { > - IPOINTER_INSERT(ip, mp); > - } > - > - /* > - * We don't want the periodic flushing of > the > - * inodes by vfs_sync() to interfere with > - * I/O to the file, especially read I/O > - * where it is only the access time stamp > - * that is being flushed out. To prevent > - * long periods where we have both inode > - * locks held shared here while reading > the > - * inode's buffer in from disk, we drop > the > - * inode lock while reading in the inode > - * buffer. We have to release the buffer > - * and reacquire the inode lock so that > they > - * are acquired in the proper order (inode > - * locks first). The buffer will go at > the > - * end of the lru chain, though, so we can > - * expect it to still be there when we go > - * for it again in xfs_iflush(). > - */ > - if ((xfs_ipincount(ip) == 0) && > - xfs_iflock_nowait(ip)) { > - > - xfs_ifunlock(ip); > - xfs_iunlock(ip, XFS_ILOCK_SHARED); > - > - error = xfs_itobp(mp, NULL, ip, > - &dip, &bp, 0, > 0); > - if (!error) { > - xfs_buf_relse(bp); > - } else { > - /* Bailing out, remove the > - * marker and free it. > - */ > - XFS_MOUNT_ILOCK(mp); > - IPOINTER_REMOVE(ip, mp); > - XFS_MOUNT_IUNLOCK(mp); > - > - ASSERT(!(lock_flags & > - > XFS_IOLOCK_SHARED)); > - > - kmem_free(ipointer, > - > sizeof(xfs_iptr_t)); > - return (0); > - } > - > - /* > - * Since we dropped the inode > lock, > - * the inode may have been > reclaimed. > - * Therefore, we reacquire the > mount > - * lock and check to see if we > were the > - * inode reclaimed. If this > happened > - * then the ipointer marker will > no > - * longer point back at us. In > this > - * case, move ip along to the > inode > - * after the marker, remove the > marker > - * and continue. > - */ > - XFS_MOUNT_ILOCK(mp); > - mount_locked = B_TRUE; > - > - if (ip != ipointer->ip_mprev) { > - IPOINTER_REMOVE(ip, mp); > - > - ASSERT(!vnode_refed); > - ASSERT(!(lock_flags & > - > XFS_IOLOCK_SHARED)); > - continue; > - } > - > - ASSERT(ip->i_mount == mp); > - > - if (xfs_ilock_nowait(ip, > - XFS_ILOCK_SHARED) == > 0) { > - ASSERT(ip->i_mount == mp); > - /* > - * We failed to reacquire > - * the inode lock without > - * sleeping, so just skip > - * the inode for now. We > - * clear the ILOCK bit > from > - * the lock_flags so that > we > - * won't try to drop a > lock > - * we don't hold below. > - */ > - lock_flags &= > ~XFS_ILOCK_SHARED; > - IPOINTER_REMOVE(ip_next, > mp); > - } else if ((xfs_ipincount(ip) == > 0) && > - xfs_iflock_nowait(ip)) > { > - ASSERT(ip->i_mount == mp); > - /* > - * Since this is > vfs_sync() > - * calling we only flush > the > - * inode out if we can > lock > - * it without sleeping and > - * it is not pinned. Drop > - * the mount lock here so > - * that we don't hold it > for > - * too long. We already > have > - * a marker in the list > here. > - */ > - XFS_MOUNT_IUNLOCK(mp); > - mount_locked = B_FALSE; > - error = xfs_iflush(ip, > > - XFS_IFLUSH_DELWRI); > - } else { > - ASSERT(ip->i_mount == mp); > - IPOINTER_REMOVE(ip_next, > mp); > - } > - } > - > - } > + if ((flags & SYNC_ATTR) && > + (ip->i_update_core || > + (ip->i_itemp && ip->i_itemp->ili_format.ilf_fields))) > { > + if (mount_locked) > + IPOINTER_INSERT(ip, mp); > > - } else { > - if ((flags & SYNC_ATTR) && > - ((ip->i_update_core) || > - ((ip->i_itemp != NULL) && > - (ip->i_itemp->ili_format.ilf_fields != 0)))) > { > - if (mount_locked) { > - IPOINTER_INSERT(ip, mp); > - } > + if (flags & SYNC_WAIT) { > + xfs_iflock(ip); > + error = xfs_iflush(ip, XFS_IFLUSH_SYNC); > > - if (flags & SYNC_WAIT) { > - xfs_iflock(ip); > - error = xfs_iflush(ip, > > - XFS_IFLUSH_SYNC); > - } else { > - /* > - * If we can't acquire the flush > - * lock, then the inode is already > - * being flushed so don't bother > - * waiting. If we can lock it > then > - * do a delwri flush so we can > - * combine multiple inode flushes > - * in each disk write. > - */ > - if (xfs_iflock_nowait(ip)) { > - error = xfs_iflush(ip, > > - XFS_IFLUSH_DELWRI); > - } > - else if (bypassed) > - (*bypassed)++; > - } > + /* > + * If we can't acquire the flush lock, then the > inode > + * is already being flushed so don't bother > waiting. > + * > + * If we can lock it then do a delwri flush so we > can > + * combine multiple inode flushes in each disk > write. > + */ > + } else if (xfs_iflock_nowait(ip)) { > + error = xfs_iflush(ip, XFS_IFLUSH_DELWRI); > + } else if (bypassed) { > + (*bypassed)++; > } > } > > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sun Sep 9 14:37:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 14:37:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l89LbY4p032297 for ; Sun, 9 Sep 2007 14:37:37 -0700 Received: from Liberator.local (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 828FA180000B2; Sun, 9 Sep 2007 16:37:36 -0500 (CDT) Message-ID: <46E467A1.7030400@sandeen.net> Date: Sun, 09 Sep 2007 16:37:37 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Bhagi rathi CC: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] remove dead SYNC_BDFLUSH case in xfs_sync_inodes References: <20070909154220.GC19986@lst.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12805 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 Bhagi rathi wrote: > vfs_sync_worker calls with SYNC_BDFLUSH. xfssyncd can call this. I might be > missing something > if this is not used. > > Thanks, > -Saradhi. My eyes glazed over it too, but in xfs_syncsub as hch pointed out to me: if (flags & (SYNC_ATTR|SYNC_DELWRI)) { if (flags & SYNC_BDFLUSH) xfs_finish_reclaim_all(mp, 1); else error = xfs_sync_inodes(mp, flags, bypassed); } so it won't be called with that flag. -Eric From owner-xfs@oss.sgi.com Sun Sep 9 19:16:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 19:16:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50,MIME_8BIT_HEADER autolearn=no version=3.2.0-pre1-r499012 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 l8A2Gq4p001364 for ; Sun, 9 Sep 2007 19:16:53 -0700 Received: from Liberator.local (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 DFD48180000B0; Sun, 9 Sep 2007 21:16:53 -0500 (CDT) Message-ID: <46E4A916.1010602@sandeen.net> Date: Sun, 09 Sep 2007 21:16:54 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Martin_Schr=F6der?= CC: xfs@oss.sgi.com Subject: Re: Not able to register References: <46E3471D.7020408@sandeen.net> <46E35C28.4060301@sandeen.net> <20070909065143.GA6787@filer.fsl.cs.sunysb.edu> <46E409F1.4090001@agami.com> <68c491a60709090910t3bd37e7bxfec773f58a55224d@mail.gmail.com> In-Reply-To: <68c491a60709090910t3bd37e7bxfec773f58a55224d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 12806 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 Martin Schröder wrote: > 2007/9/9, Michael Nishimoto : >> In the past when I spoke with Russell, gmail subscribes >> look like spam to the ecartis server. > > Then ecartis is broken. Since it seems very stale (last released > version is from 2000, since then only snapshots), maybe you should > switch to something more vital? Mailman comes to mind... > > Best > Martin > > Ok, in Luca's case at least, it was spamassassin intercepting it... thought his subscribe request looked like spam. :( Looks like something to sort out, eh. Hm, Luca and about 130 others, from grepping the logs. grumble... -Eric From owner-xfs@oss.sgi.com Sun Sep 9 20:02:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 20:02:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW autolearn=ham version=3.2.0-pre1-r499012 Received: from ipmail02.adl2.internode.on.net (ipmail02.adl2.internode.on.net [203.16.214.141]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8A3294p008510 for ; Sun, 9 Sep 2007 20:02:13 -0700 X-IronPort-AV: E=Sophos;i="4.20,228,1186324200"; d="scan'208";a="184757250" Received: from ppp59-167-137-68.lns3.mel6.internode.on.net (HELO jdc.jasonjgw.net) ([59.167.137.68]) by ipmail02.adl2.internode.on.net with ESMTP; 10 Sep 2007 12:12:52 +0930 Received: by jdc.jasonjgw.net (Postfix, from userid 1000) id 97E041001329E; Mon, 10 Sep 2007 12:42:50 +1000 (EST) Date: Mon, 10 Sep 2007 12:42:50 +1000 From: Jason White To: xfs@oss.sgi.com Subject: Re: Not able to register Message-ID: <20070910024250.GA27711@jdc.jasonjgw.net> Mail-Followup-To: xfs@oss.sgi.com References: <46E3471D.7020408@sandeen.net> <46E35C28.4060301@sandeen.net> <20070909065143.GA6787@filer.fsl.cs.sunysb.edu> <46E409F1.4090001@agami.com> <68c491a60709090910t3bd37e7bxfec773f58a55224d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <68c491a60709090910t3bd37e7bxfec773f58a55224d@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-11) X-archive-position: 12807 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jason@jasonjgw.net Precedence: bulk X-list: xfs On Sun, Sep 09, 2007 at 06:10:55PM +0200, Martin Schröder wrote: > Then ecartis is broken. Since it seems very stale (last released > version is from 2000, since then only snapshots), maybe you should > switch to something more vital? Mailman comes to mind... Mailman and Sympa appear to be the top contenders at the moment. From owner-xfs@oss.sgi.com Sun Sep 9 21:41:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 21:41:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8A4fC4p025551 for ; Sun, 9 Sep 2007 21:41:15 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10207; Mon, 10 Sep 2007 14:41:08 +1000 Message-ID: <46E4CB8D.6010301@sgi.com> Date: Mon, 10 Sep 2007 14:43:57 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Chinner CC: Mark Goodwin , Timothy Shimmin , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes References: <46D6279F.40601@sgi.com> <46D6480F.4040307@sgi.com> <46D64CAD.6050705@sgi.com> <46D67FE6.20205@sgi.com> <46D68510.1020404@sgi.com> <46D77B79.3040104@sgi.com> <46D792A1.7030308@sgi.com> <20070831154822.GD734179@sgi.com> <46E0B154.1000805@sgi.com> <20070907140541.GA734179@sgi.com> In-Reply-To: <20070907140541.GA734179@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12808 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Fri, Sep 07, 2007 at 12:03:00PM +1000, Lachlan McIlroy wrote: >> David Chinner wrote: >>> An unlinked inode is only detectable by the mode parameter being zero. >>> The rest of the inode will look valid. >>> >>> To detect the difference between a newly allocated inode *chunk* >>> that has been written to and a stale inode chunk that we have >>> just allocated and not written to yet, you need to walk every inode >>> in the chunk and determine if the mode parameter is zero in every >>> inode. >>> >>> If the mode is zero for all inodes and there are generation numbers >>> that are not zero, then you've detected a stale buffer and you should >>> replay the inode cluster buffer initialisation. >>> >> Thanks for this info Dave. I looked into it and came up with a solution >> that looks at the ondisk inode buffer and determines if it has been >> written to since being logged. It iterates through all the inodes and >> checks each one with: >> >> - if the magic number is wrong the buffer is stale > > *nod* > >> - if the mode is non-zero then the buffer is newer than the log > > *nod* > >> - if the mode is zero and the generation count is non-zero then the >> buffer is stale > > On second thoughts, this might be more complex - the buffer is stale > only if all inodes in the *chunk* have this pattern. We may have multiple > buffers to a chunk. e.g. allocate 55 inodes, they span two 8k cluster > buffers. Both meet the second criteria. Now remove the first 32 inodes, > and we have one buffer with zero allocated inodes but non-zero generation > numbers (i.e. thrid state) and one that meets the second criteria. > > However, both buffers are more recent than the buffer being replayed. > We could lose generation count changes if we overwrite the buffer with > no inodes in it.... > > So I think the stale buffer criteria must be that all the inodes in the entire > inode chunk (i.e. across all buffers) must have a zero mode and at least one > of the inodes has a non-zero generation count. Does that make sense? Yeah, that makes sense. Is inode cluster I/O done in size of chunks then? So we are trying to determine if a chunk has been written since any of the buffers were logged. Is it possible that only some of the buffers are logged before the chunk is written to disk and the rest of the buffers are logged after? > >> If the end result is a stale buffer then the buffer is replayed otherwise >> it is skipped. I added a new flag that gets logged with a new inode >> cluster so that we can identify a buffer of inodes from something else. >> This fix is passing all the tests we have. Is this a better approach >> than the last fix? > > Definitely, but I think our "stale buffer" detection needs more work. > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Sun Sep 9 21:54:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 21:55:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.4 required=5.0 tests=AWL,BAYES_40,HTML_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8A4sw4p027163 for ; Sun, 9 Sep 2007 21:54:59 -0700 Received: by wa-out-1112.google.com with SMTP id k22so1554037waf for ; Sun, 09 Sep 2007 21:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=I1bPf+HzlL5UNJbTCfWdB+ysdb8SXj4jhBpohbjC7zg=; b=hWX5x4kpcgJcvBeL74UXD+iEIpPTapL39N2WzW1KOAVzv4OM/QkQBM4zbKWDou5pwK7qk7iZtZ5zpmORuBhow7th8eSWSd0Q9Y/zVHUOFSho8HVkpC/rQXVQByHnfNtCHnjlphQx3qVNI/fbnlDhqXS/dS/Hh7aasl/AwvpBqdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=abL5qvBFHGrtDtKBCP8CgSH1we47tRNXMroKyVNv1LDm4hk3DKIuvZ9Cj8dwxM5SIO9BBHb/j+esWKTibhoUqOSaBgvACegge2ozuhG7ZzR57VniGIwlk7jDiIfJwvQI2mvdadvazEj/ivLA72oE1X+Cr5z9wIK6FeD8BtfF+O0= Received: by 10.114.77.1 with SMTP id z1mr3483946waa.1189400099616; Sun, 09 Sep 2007 21:54:59 -0700 (PDT) Received: by 10.114.171.20 with HTTP; Sun, 9 Sep 2007 21:54:59 -0700 (PDT) Message-ID: Date: Mon, 10 Sep 2007 10:24:59 +0530 From: "Bhagi rathi" To: "Eric Sandeen" Subject: Re: [PATCH] remove dead SYNC_BDFLUSH case in xfs_sync_inodes Cc: "Christoph Hellwig" , xfs@oss.sgi.com In-Reply-To: <46E467A1.7030400@sandeen.net> MIME-Version: 1.0 References: <20070909154220.GC19986@lst.de> <46E467A1.7030400@sandeen.net> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 939 X-archive-position: 12809 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs Ah, I see. It looks we don't use SYNC_BDFLUSH in xfs_sync_inodes. I believe we don't want to flush inodes from xfssync as inodes will be flushed by pdflush, memory cleaner threads. It looks like this code may be valid to other operating systems, not for linux? -Saradhi. On 9/10/07, Eric Sandeen wrote: > > Bhagi rathi wrote: > > vfs_sync_worker calls with SYNC_BDFLUSH. xfssyncd can call this. I might > be > > missing something > > if this is not used. > > > > Thanks, > > -Saradhi. > > > My eyes glazed over it too, but in xfs_syncsub as hch pointed out to me: > > if (flags & (SYNC_ATTR|SYNC_DELWRI)) { > if (flags & SYNC_BDFLUSH) > xfs_finish_reclaim_all(mp, 1); > else > error = xfs_sync_inodes(mp, flags, bypassed); > } > > so it won't be called with that flag. > > -Eric > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sun Sep 9 23:26:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Sep 2007 23:26:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from redback.melbourne.sgi.com (redback.melbourne.sgi.com [134.14.55.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8A6Qf4p007077 for ; Sun, 9 Sep 2007 23:26:45 -0700 Received: from redback.melbourne.sgi.com (localhost [127.0.0.1]) by redback.melbourne.sgi.com (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id l8A5qVbi014116; Mon, 10 Sep 2007 15:52:33 +1000 Received: (from lachlan@localhost) by redback.melbourne.sgi.com (8.13.8/8.13.8/Submit) id l8A5qUQu014115; Mon, 10 Sep 2007 15:52:30 +1000 Date: Mon, 10 Sep 2007 15:52:30 +1000 From: Lachlan McIlroy Message-Id: <200709100552.l8A5qUQu014115@redback.melbourne.sgi.com> To: xfs-dev@sgi.com, xfs@oss.sgi.com Subject: TAKE 970242 - remove dead SYNC_BDFLUSH case in xfs_sync_inodes X-archive-position: 12810 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@redback.melbourne.sgi.com Precedence: bulk X-list: xfs remove dead SYNC_BDFLUSH case in xfs_sync_inodes A large part of xfs_sync_inodes is conditional on the SYNC_BDFLUSH which is never passed to it. This patch removes it and adds an assert that triggers in case some new code tries to pass SYNC_BDFLUSH to it. Date: Mon Sep 10 15:49:14 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-fixes Inspected by: Christoph Hellwig The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29630a fs/xfs/xfs_vfsops.c - 1.537 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.537&r2=text&tr2=1.536&f=h - remove dead SYNC_BDFLUSH case in xfs_sync_inodes From owner-xfs@oss.sgi.com Mon Sep 10 02:05:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 02:05:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.9 required=5.0 tests=AWL,BAYES_50,RDNS_DYNAMIC, SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r499012 Received: from ventoso.org (61.pool85-52-226.static.orange.es [85.52.226.61]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8A95Y4p012045 for ; Mon, 10 Sep 2007 02:05:36 -0700 Received: from [192.168.10.30] (unknown [192.168.10.30]) by ventoso.org (Postfix) with ESMTP id 28477C34F04 for ; Mon, 10 Sep 2007 11:05:36 +0200 (CEST) Message-ID: <46E508E6.7010908@ventoso.org> Date: Mon, 10 Sep 2007 11:05:42 +0200 From: Luca Olivetti User-Agent: Thunderbird 2.0.0.4 (X11/20070620) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: Not able to register References: <46E3471D.7020408@sandeen.net> <46E35C28.4060301@sandeen.net> <20070909065143.GA6787@filer.fsl.cs.sunysb.edu> <46E409F1.4090001@agami.com> <68c491a60709090910t3bd37e7bxfec773f58a55224d@mail.gmail.com> <46E4A916.1010602@sandeen.net> In-Reply-To: <46E4A916.1010602@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 12811 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: luca@ventoso.org Precedence: bulk X-list: xfs En/na Eric Sandeen ha escrit: > Martin Schröder wrote: >> 2007/9/9, Michael Nishimoto : >>> In the past when I spoke with Russell, gmail subscribes >>> look like spam to the ecartis server. >> Then ecartis is broken. Since it seems very stale (last released >> version is from 2000, since then only snapshots), maybe you should >> switch to something more vital? Mailman comes to mind... >> >> Best >> Martin >> >> > > Ok, in Luca's case at least, it was spamassassin intercepting it... > thought his subscribe request looked like spam. :( Looks like > something to sort out, eh. Well, using bogus black lists (aren't they all bogus?) leads to that (hint: my ip address isn't dynamic, though I strongly disagree to use that as a criterion to decide what I'm allowed to do or not with my connection). Though I find it funny that in a misguided attempt to block spam I cannot subscribe to the list, still I can post to it :-D > Hm, Luca and about 130 others, from grepping the logs. qed Bye -- Luca From owner-xfs@oss.sgi.com Mon Sep 10 02:56:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 02:56:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r499012 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8A9up4p018574 for ; Mon, 10 Sep 2007 02:56:53 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IUfcD-0008KI-Vl for xfs@oss.sgi.com; Mon, 10 Sep 2007 10:31:33 +0100 Date: Mon, 10 Sep 2007 10:31:33 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: Re: Not able to register Message-ID: <20070910093133.GA31592@infradead.org> References: <46E3471D.7020408@sandeen.net> <46E35C28.4060301@sandeen.net> <20070909065143.GA6787@filer.fsl.cs.sunysb.edu> <46E409F1.4090001@agami.com> <68c491a60709090910t3bd37e7bxfec773f58a55224d@mail.gmail.com> <20070910024250.GA27711@jdc.jasonjgw.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070910024250.GA27711@jdc.jasonjgw.net> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 12812 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Sep 10, 2007 at 12:42:50PM +1000, Jason White wrote: > On Sun, Sep 09, 2007 at 06:10:55PM +0200, Martin Schr?der wrote: > > > Then ecartis is broken. Since it seems very stale (last released > > version is from 2000, since then only snapshots), maybe you should > > switch to something more vital? Mailman comes to mind... > > Mailman and Sympa appear to be the top contenders at the moment. Eek, mailman is a complete pain in the ass for subscribers and also software I don't really trust. I'd much prefer to just move over the list to vger.kernel.org where things work nicely at a larger scale. From owner-xfs@oss.sgi.com Mon Sep 10 05:01:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 05:01:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8AC144p006927 for ; Mon, 10 Sep 2007 05:01:07 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l8AC13A5003865 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Sep 2007 14:01:03 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8AC13Pc003863; Mon, 10 Sep 2007 14:01:03 +0200 Date: Mon, 10 Sep 2007 14:01:03 +0200 From: Christoph Hellwig To: Bhagi rathi Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] kill BMAPI_DEVICE Message-ID: <20070910120103.GA3666@lst.de> References: <20070909153947.GA19986@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12813 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Mon, Sep 10, 2007 at 01:02:07AM +0530, Bhagi rathi wrote: > XFS_IOCORE_RT | XFS_DIFLAG_REALTIME can be set from an ioctl (xfs_setattr). > A directIO without holding ILOCK > in shared in mode can read a wrong value of di_flag for real time decision. > As a result, we may pass in-correct device > during directIO as the proposed xfs_find_bdev_for_inode doesn't hold any > lock in reading the flags. It is not based > on iocore flags as well. > > On a secondary note, XFS_IOCORE_RT was set without holding iolock which > seems to an issue. I tend to leave > xfs_bmapi to decide BMAPI_DEVICE to xfs_iomap. The previous locking doesn't help anything - if the value changes during the direct I/O process we are in trouble anyway. Fortunately we always hold the iolock in shared mode over any direct I/O, so taking this lock in ->setattr will fix this pre-existing issue. > What is the reason why this has to be seperated? Because it does not belong into xfs_iomap. While there is at least some common code between BMAPI_READ, BMAPI_WRITE and BMAPI_ALLOCATE calls so sharing that makes some sense it does not at all for the other two which this patch separates out in preparation of bigger changes in this area. From owner-xfs@oss.sgi.com Mon Sep 10 05:02:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 05:02:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_MED, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8AC2q4p007341 for ; Mon, 10 Sep 2007 05:02:53 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l8ABolHU015454 for ; Mon, 10 Sep 2007 07:50:47 -0400 Received: from pobox.stuttgart.redhat.com (pobox.stuttgart.redhat.com [172.16.2.10]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l8ABok0k012917 for ; Mon, 10 Sep 2007 07:50:46 -0400 Received: from dhcp-lab-203.englab.brq.redhat.com (dhcp-lab-203.englab.brq.redhat.com [10.34.33.203]) by pobox.stuttgart.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l8ABojZB026014 for ; Mon, 10 Sep 2007 13:50:46 +0200 Message-ID: <46E52F95.3070307@redhat.com> Date: Mon, 10 Sep 2007 13:50:45 +0200 From: Zdenek Prikryl User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: getfattr and symlinks Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12815 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: zprikryl@redhat.com Precedence: bulk X-list: xfs Hello, I have one question, what is right behavior of getfattr in a recursive mode? Should getfattr follow symlinks in this mode (without [PLh] parameters)? Example: $HOME/file.txt $HOME/symlink -> / ... getfattr -Rd $HOME So what is the right result? Follow "$HOME/symlink" or not? Thank you Zdenek Prikryl From owner-xfs@oss.sgi.com Mon Sep 10 05:02:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 05:02:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8AC274p007110 for ; Mon, 10 Sep 2007 05:02:08 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l8AC27A5003919 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Sep 2007 14:02:07 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8AC27Ft003917; Mon, 10 Sep 2007 14:02:07 +0200 Date: Mon, 10 Sep 2007 14:02:07 +0200 From: Christoph Hellwig To: Bhagi rathi Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] kill BMAPI_UNWRITTEN Message-ID: <20070910120206.GB3666@lst.de> References: <20070909154103.GB19986@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12814 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Mon, Sep 10, 2007 at 01:04:55AM +0530, Bhagi rathi wrote: > The reason for eliminating BMAPI_UNWRITTEN is not clear. It is ideal to keep > all the block map > interfaces and information to go through xfs_iomap, xfs_bmapi functionality. Despit it's name xfs_iomap_write_unwritten is not a block map interface. Just take a look at the code, it does not use the block allocator data structures at all, and it does not do the central xfs_bmapi call (it uses xfs_bmapi later on but in very different ways). From owner-xfs@oss.sgi.com Mon Sep 10 05:41:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 05:41:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8ACfX4p013644 for ; Mon, 10 Sep 2007 05:41:33 -0700 Received: from Liberator.local (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 839F0180000B0; Mon, 10 Sep 2007 07:41:34 -0500 (CDT) Message-ID: <46E53B7D.8070301@sandeen.net> Date: Mon, 10 Sep 2007 07:41:33 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Luca Olivetti CC: xfs@oss.sgi.com Subject: Re: Not able to register References: <46E3471D.7020408@sandeen.net> <46E35C28.4060301@sandeen.net> <20070909065143.GA6787@filer.fsl.cs.sunysb.edu> <46E409F1.4090001@agami.com> <68c491a60709090910t3bd37e7bxfec773f58a55224d@mail.gmail.com> <46E4A916.1010602@sandeen.net> <46E508E6.7010908@ventoso.org> In-Reply-To: <46E508E6.7010908@ventoso.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 12816 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 Luca Olivetti wrote: > En/na Eric Sandeen ha escrit: >> Martin Schröder wrote: >>> 2007/9/9, Michael Nishimoto : >>>> In the past when I spoke with Russell, gmail subscribes >>>> look like spam to the ecartis server. >>> Then ecartis is broken. Since it seems very stale (last released >>> version is from 2000, since then only snapshots), maybe you should >>> switch to something more vital? Mailman comes to mind... >>> >>> Best >>> Martin >>> >>> >> Ok, in Luca's case at least, it was spamassassin intercepting it... >> thought his subscribe request looked like spam. :( Looks like >> something to sort out, eh. > > Well, using bogus black lists (aren't they all bogus?) leads to that > (hint: my ip address isn't dynamic, though I strongly disagree to use > that as a criterion to decide what I'm allowed to do or not with my > connection). it wasn't a blacklist, it was about 4 other tests that tripped. > Though I find it funny that in a misguided attempt to block spam I > cannot subscribe to the list, still I can post to it :-D > >> Hm, Luca and about 130 others, from grepping the logs. > > qed no argument. I'm sure this is fixable... sorry about the problems. -Eric > Bye > From owner-xfs@oss.sgi.com Mon Sep 10 06:20:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 06:20:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.5 required=5.0 tests=AWL,BAYES_05,HEADER_ESQ, HTML_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8ADK64p019600 for ; Mon, 10 Sep 2007 06:20:07 -0700 Received: by wa-out-1112.google.com with SMTP id k22so1702051waf for ; Mon, 10 Sep 2007 06:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=j/DAbcgEewlw9gnbFLnUKJXs4YNlvG3ykPswa1FjH8E=; b=lc9DYqbPLMPIlhjM44puDtys2pvMilLcq5/vN3FKqRkAVux7KFGiRP4YB+GmBq7X5Najt8qJNK27EZH1MCQzmgCCpHBDe6/i47TsvpgTi8zNMDfbqJibG8p8NQER4Mya5/jZvwFG4NnBhgm1Jufp+coQ8+pDh9hJjU6onwqFia4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=A7psbJllhWqjiUe209bDesqSosjXjzqtw90aZaQEPO6yzN2UZ1r2HeYIlmRVyOfXPLm1RpgAgeUddWI0Re1Gry93CA4nxTFJC47gqM9Tl4rU/m/B8BIkkQTpvnSrAinPY5zjU/uq0rHYD00/HLBp3+7TCQtVX7rbaMHrj1GQSYA= Received: by 10.114.209.1 with SMTP id h1mr39453wag.1189430407756; Mon, 10 Sep 2007 06:20:07 -0700 (PDT) Received: by 10.114.171.20 with HTTP; Mon, 10 Sep 2007 06:20:07 -0700 (PDT) Message-ID: Date: Mon, 10 Sep 2007 18:50:07 +0530 From: "Bhagi rathi" To: "Christoph Hellwig" Subject: Re: [PATCH] kill BMAPI_DEVICE Cc: xfs@oss.sgi.com In-Reply-To: <20070910120103.GA3666@lst.de> MIME-Version: 1.0 References: <20070909153947.GA19986@lst.de> <20070910120103.GA3666@lst.de> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1490 X-archive-position: 12817 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs On 9/10/07, Christoph Hellwig wrote: > > On Mon, Sep 10, 2007 at 01:02:07AM +0530, Bhagi rathi wrote: > > XFS_IOCORE_RT | XFS_DIFLAG_REALTIME can be set from an ioctl > (xfs_setattr). > > A directIO without holding ILOCK > > in shared in mode can read a wrong value of di_flag for real time > decision. > > As a result, we may pass in-correct device > > during directIO as the proposed xfs_find_bdev_for_inode doesn't hold any > > lock in reading the flags. It is not based > > on iocore flags as well. > > > > On a secondary note, XFS_IOCORE_RT was set without holding iolock which > > seems to an issue. I tend to leave > > xfs_bmapi to decide BMAPI_DEVICE to xfs_iomap. > > The previous locking doesn't help anything - if the value changes during > the direct I/O process we are in trouble anyway. Fortunately we always > hold the iolock in shared mode over any direct I/O, so taking this lock > in ->setattr will fix this pre-existing issue. Yes. I believe the proposed change can succeed after the fix you mentioned. > What is the reason why this has to be seperated? > > Because it does not belong into xfs_iomap. While there is at least some > common code between BMAPI_READ, BMAPI_WRITE and BMAPI_ALLOCATE calls so > sharing that makes some sense it does not at all for the other two which > this patch separates out in preparation of bigger changes in this area. What is the goal of the bigger changes planned? -Saradhi. [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Mon Sep 10 07:24:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 07:24:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r499012 Received: from amanpulo.fs3.ph (amanpulo.fs3.ph [72.51.42.241]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8AEOg4p028860 for ; Mon, 10 Sep 2007 07:24:44 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.fs3.ph (Postfix) with ESMTP id 3A4A51E0D5943 for ; Mon, 10 Sep 2007 21:59:17 +0800 (PHT) X-Virus-Scanned: Debian amavisd-new at fs3.ph Received: from amanpulo.fs3.ph ([127.0.0.1]) by localhost (amanpulo.fs3.ph [127.0.0.1]) (amavisd-new, port 10024) with LMTP id elU5YCPiMMhS; Mon, 10 Sep 2007 21:59:11 +0800 (PHT) Received: from auctoritas.local (unknown [222.127.47.132]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by amanpulo.fs3.ph (Postfix) with ESMTP id 8D93B1E0D5960; Mon, 10 Sep 2007 21:59:10 +0800 (PHT) Subject: Attempt to Access Beyond End of Device From: Federico Sevilla III To: linux-xfs@oss.sgi.com Cc: Alec Joseph Rivera Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-YTB1Gy6CzAmVb4PSWUII" Organization: F S 3 Consulting Inc. Date: Mon, 10 Sep 2007 21:59:07 +0800 Message-Id: <1189432747.4385.27.camel@auctoritas.fs3.ph> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-archive-position: 12818 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jijo@fs3.ph Precedence: bulk X-list: xfs --=-YTB1Gy6CzAmVb4PSWUII Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, We've set up Debian GNU/Linux 4.0 "Etch" on an IBM x3400 machine with two 73.4GB SAS hard drives in hardware RAID 1 with a battery-backed cache. We are using the stock Debian 2.6.18-4-686 kernel. The filesystems were created using the following optimization: -l size=3D32768b,version=3D2 -n 64k The filesystems are mounted using the following optimization: logbufs=3D8,logbsize=3D256k Today, we were unable to mount the "large" (not really at < 70GB) /var (/dev/sda8), getting the following error: Attempt to access beyond end of device sda: rw=3D0, want=3D143139140, limit=3D143134720 I/O error in filesystem ("sda8") meta-data dev sda8 block 0x75cd27f ("xf:read_buf") errors buf count 512 XFS: size check 2 failed Mount: /dev/sda8: can't read superblock An attempted repair also fails: # xfs_repair /dev/sda8 Phase 1 - find and verify superblock... Attempt to access beyond end of device Sda: rw=3D0, want=3D143139140, limit=3D143134720 Xfs_repair: read failed. Input/output error The partition table looks okay: #Partition table of /dev/sda /dev/sda1 : start=3D 63,size 9637, Id=3D83, bootable /dev/sda2 : start=3D 96390,size 143042760, Id=3D5 /dev/sda3 : start=3D 0,size 0, Id=3D0 /dev/sda4 : start=3D 0,size 0, Id=3D0=20=20=20 /dev/sda5 : start=3D 96453,size 3903732, Id=3D82 /dev/sda6 : start=3D 4000248,size 7807527, Id=3D83 /dev/sda7 : start=3D 11807838,size 7807527, Id=3D83 /dev/sda8 : start=3D 19615428,size 123523722, Id=3D83 The machine doesn't have valuable data, yet, so a simple reinstall should help get it back up. However I'm more concerned about what could cause this. It's the first time for me to use a version 2 log, 64k directories (?) and 256k in-memory log buffers. Are any of these to blame? We're also looking for generic filesystem tweaks for a PostgreSQL + Apache server, which this will be (with more load direct to PostgreSQL than to/through Apache). Are the above choices for mkfs.xfs and mount well-made? Please advise. Thank you very much. --=20 Federico Sevilla III F S 3 Consulting Inc. http://www.fs3.ph --=-YTB1Gy6CzAmVb4PSWUII Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBG5U2r5rCBSJO3Rr4RAr7hAJ4pMAPg6LWMxGAHLPRDZgdnwQLUQwCeN/rp YNOBh0CR4nlUB8jn5PgNJ/o= =jDsu -----END PGP SIGNATURE----- --=-YTB1Gy6CzAmVb4PSWUII-- From owner-xfs@oss.sgi.com Mon Sep 10 08:00:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 08:00:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from amanpulo.fs3.ph (amanpulo.fs3.ph [72.51.42.241]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8AF034p001590 for ; Mon, 10 Sep 2007 08:00:05 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.fs3.ph (Postfix) with ESMTP id 5BB2B1E0D5960 for ; Mon, 10 Sep 2007 23:00:05 +0800 (PHT) X-Virus-Scanned: Debian amavisd-new at fs3.ph Received: from amanpulo.fs3.ph ([127.0.0.1]) by localhost (amanpulo.fs3.ph [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qJRiVGbGATiZ; Mon, 10 Sep 2007 23:00:02 +0800 (PHT) Received: from auctoritas.local (unknown [222.127.47.132]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by amanpulo.fs3.ph (Postfix) with ESMTP id 18E521E0D5945; Mon, 10 Sep 2007 23:00:00 +0800 (PHT) Subject: Re: Attempt to Access Beyond End of Device From: Federico Sevilla III To: linux-xfs@oss.sgi.com Cc: Alec Joseph Rivera In-Reply-To: References: <1189432747.4385.27.camel@auctoritas.fs3.ph> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-yLm0c2VKZRrvdy/ghcrt" Organization: F S 3 Consulting Inc. Date: Mon, 10 Sep 2007 22:59:56 +0800 Message-Id: <1189436396.4385.49.camel@auctoritas.fs3.ph> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-archive-position: 12819 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jijo@fs3.ph Precedence: bulk X-list: xfs --=-yLm0c2VKZRrvdy/ghcrt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-09-10 at 10:44 -0400, Justin Piszcz wrote: > I believe the logbsize should be in bytes, so 262144, it may also take > 256k though I have not tried it. It accepts 256k. The initial mount succeeded, and the problem did not surface until after some reboot (ie: not the first reboot, either, that went fine). > That looks mighty strange, what kind of raid card? This is the built-in Adaptec AACRAID of the IBM x3400, doing a pretty simplistic RAID 1. --=20 Federico Sevilla III F S 3 Consulting Inc. http://www.fs3.ph --=-yLm0c2VKZRrvdy/ghcrt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQBG5Vvs5rCBSJO3Rr4RAozoAJd5hwk49g1kt1xX5T2jjb0B4Gv4AJ4nXGgL JMO0gYk6VadF2d3VasR1IA== =6TmE -----END PGP SIGNATURE----- --=-yLm0c2VKZRrvdy/ghcrt-- From owner-xfs@oss.sgi.com Mon Sep 10 08:04:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 08:04:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_43, SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r499012 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8AF4H4p002528 for ; Mon, 10 Sep 2007 08:04:19 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 920A21C00022D; Mon, 10 Sep 2007 10:44:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 8FB104019F6F; Mon, 10 Sep 2007 10:44:24 -0400 (EDT) Date: Mon, 10 Sep 2007 10:44:24 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Federico Sevilla III cc: linux-xfs@oss.sgi.com, Alec Joseph Rivera Subject: Re: Attempt to Access Beyond End of Device In-Reply-To: <1189432747.4385.27.camel@auctoritas.fs3.ph> Message-ID: References: <1189432747.4385.27.camel@auctoritas.fs3.ph> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 12820 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Mon, 10 Sep 2007, Federico Sevilla III wrote: > Hi, > > We've set up Debian GNU/Linux 4.0 "Etch" on an IBM x3400 machine with > two 73.4GB SAS hard drives in hardware RAID 1 with a battery-backed > cache. We are using the stock Debian 2.6.18-4-686 kernel. > > The filesystems were created using the following optimization: > > -l size=32768b,version=2 -n 64k > > The filesystems are mounted using the following optimization: > > logbufs=8,logbsize=256k > > Today, we were unable to mount the "large" (not really at < 70GB) /var > (/dev/sda8), getting the following error: > > Attempt to access beyond end of device > sda: rw=0, want=143139140, limit=143134720 > I/O error in filesystem ("sda8") meta-data dev sda8 block > 0x75cd27f > ("xf:read_buf") errors buf count 512 > XFS: size check 2 failed > Mount: /dev/sda8: can't read superblock > > An attempted repair also fails: > > # xfs_repair /dev/sda8 > Phase 1 - find and verify superblock... > Attempt to access beyond end of device > Sda: rw=0, want=143139140, limit=143134720 > Xfs_repair: read failed. Input/output error > > The partition table looks okay: > > #Partition table of /dev/sda > /dev/sda1 : start= 63,size 9637, Id=83, bootable > /dev/sda2 : start= 96390,size 143042760, Id=5 > /dev/sda3 : start= 0,size 0, Id=0 > /dev/sda4 : start= 0,size 0, Id=0 > /dev/sda5 : start= 96453,size 3903732, Id=82 > /dev/sda6 : start= 4000248,size 7807527, Id=83 > /dev/sda7 : start= 11807838,size 7807527, Id=83 > /dev/sda8 : start= 19615428,size 123523722, Id=83 > > The machine doesn't have valuable data, yet, so a simple reinstall > should help get it back up. However I'm more concerned about what could > cause this. It's the first time for me to use a version 2 log, 64k > directories (?) and 256k in-memory log buffers. Are any of these to > blame? > > We're also looking for generic filesystem tweaks for a PostgreSQL + > Apache server, which this will be (with more load direct to PostgreSQL > than to/through Apache). Are the above choices for mkfs.xfs and mount > well-made? > > Please advise. > > Thank you very much. > > -- > Federico Sevilla III > F S 3 Consulting Inc. > http://www.fs3.ph > I believe the logbsize should be in bytes, so 262144, it may also take 256k though I have not tried it. As far as the creation, that's a good question, I use SW raid so XFS auto-tunes it for my hardware. That looks mighty strange, what kind of raid card? Justin. From owner-xfs@oss.sgi.com Mon Sep 10 08:07:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 08:07:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8AF7h4p003296 for ; Mon, 10 Sep 2007 08:07:48 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IUkrZ-0004KU-Ex; Mon, 10 Sep 2007 16:07:45 +0100 Date: Mon, 10 Sep 2007 16:07:45 +0100 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss Subject: Re: [PATCH] ensure file size is logged on synchronous writes Message-ID: <20070910150745.GA16595@infradead.org> References: <46DB7A60.4050203@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DB7A60.4050203@sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 12821 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Sep 03, 2007 at 01:07:12PM +1000, Lachlan McIlroy wrote: > Synchronous writes currently log inode changes before syncing > pages to disk. Since the file size is updated on I/O completion > we wont be writing out the updated file size and if we crash the > file will have the wrong size. This change moves the logging > after the syncing of the pages to ensure we log the correct file > size. Looks good to me. From owner-xfs@oss.sgi.com Mon Sep 10 08:09:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 08:09:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8AF9X4p003888 for ; Mon, 10 Sep 2007 08:09:34 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IUktL-0004Ms-6i; Mon, 10 Sep 2007 16:09:35 +0100 Date: Mon, 10 Sep 2007 16:09:35 +0100 From: Christoph Hellwig To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH] cleanup fid types mess Message-ID: <20070910150935.GB16595@infradead.org> References: <20070829134612.GA504@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070829134612.GA504@lst.de> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 12822 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Aug 29, 2007 at 03:46:12PM +0200, Christoph Hellwig wrote: > Currently XFs has three different fid types: struct fid, struct xfs_fid > and struct xfs_fid2 with hte latter two beeing identicaly and the first > one beeing the same size but an unstructured array with the same size. > > This patch consolidates all this to alway uuse struct xfs_fid. > > This patch is required for an upcoming patch series from me that revamps > the nfs exporting code and introduces a Linux-wide struct fid. > > > Note: the patch is ontop of Eric's inode/vnode tracing cleanup. Any chance review of this one (and Eric's patch) could be sped up a little as I have things in the queue relying on this one? From owner-xfs@oss.sgi.com Mon Sep 10 08:45:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 08:45:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8AFjg4p012971 for ; Mon, 10 Sep 2007 08:45:44 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 48CAB1C00022D; Mon, 10 Sep 2007 11:45:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 45C514019F6F; Mon, 10 Sep 2007 11:45:44 -0400 (EDT) Date: Mon, 10 Sep 2007 11:45:44 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Federico Sevilla III cc: linux-xfs@oss.sgi.com, Alec Joseph Rivera Subject: Re: Attempt to Access Beyond End of Device In-Reply-To: <1189436396.4385.49.camel@auctoritas.fs3.ph> Message-ID: References: <1189432747.4385.27.camel@auctoritas.fs3.ph> <1189436396.4385.49.camel@auctoritas.fs3.ph> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 12823 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Mon, 10 Sep 2007, Federico Sevilla III wrote: > On Mon, 2007-09-10 at 10:44 -0400, Justin Piszcz wrote: >> I believe the logbsize should be in bytes, so 262144, it may also take >> 256k though I have not tried it. > > It accepts 256k. The initial mount succeeded, and the problem did not > surface until after some reboot (ie: not the first reboot, either, that > went fine). > >> That looks mighty strange, what kind of raid card? > > This is the built-in Adaptec AACRAID of the IBM x3400, doing a pretty > simplistic RAID 1. > > -- > Federico Sevilla III > F S 3 Consulting Inc. > http://www.fs3.ph > Have you checked the following page? http://linuxmafia.com/faq/Hardware/sata.html Does the error occur if you use a different filesystem? Justin. From owner-xfs@oss.sgi.com Mon Sep 10 08:52:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 08:52:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from amanpulo.fs3.ph (amanpulo.fs3.ph [72.51.42.241]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8AFq54p013983 for ; Mon, 10 Sep 2007 08:52:07 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.fs3.ph (Postfix) with ESMTP id 2F9521E0D5960 for ; Mon, 10 Sep 2007 23:52:07 +0800 (PHT) X-Virus-Scanned: Debian amavisd-new at fs3.ph Received: from amanpulo.fs3.ph ([127.0.0.1]) by localhost (amanpulo.fs3.ph [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7FkdeKtWW9cD; Mon, 10 Sep 2007 23:52:00 +0800 (PHT) Received: from auctoritas.local (unknown [222.127.47.132]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by amanpulo.fs3.ph (Postfix) with ESMTP id 269D11E0D5943; Mon, 10 Sep 2007 23:51:58 +0800 (PHT) Subject: Re: Attempt to Access Beyond End of Device From: Federico Sevilla III To: linux-xfs@oss.sgi.com Cc: Alec Joseph Rivera In-Reply-To: References: <1189432747.4385.27.camel@auctoritas.fs3.ph> <1189436396.4385.49.camel@auctoritas.fs3.ph> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-v7mpCcQKLTEw58Sg5en4" Organization: F S 3 Consulting Inc. Date: Mon, 10 Sep 2007 23:51:54 +0800 Message-Id: <1189439514.18040.14.camel@auctoritas.fs3.ph> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-archive-position: 12824 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jijo@fs3.ph Precedence: bulk X-list: xfs --=-v7mpCcQKLTEw58Sg5en4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 2007-09-10 at 11:45 -0400, Justin Piszcz wrote: > Have you checked the following page? >=20 > http://linuxmafia.com/faq/Hardware/sata.html I checked it now (thanks!) and I believe this is what we've got (or similar) as we use AACRAID: Adaptec AAR 2400, 2410, 2410SA, 2120S, 2200S, 2810SA (8-port), 21610SA (16-port) series PCI cards =E2=80=94 real hardware RAID, us= ing the slightly anemic Intel IOP302/303 I/O co-processor chips. Use "aacraid" driver. (Should not be confused with the Adaptec 2400A ATA RAID host adapter, for which one uses the dpt_i2o driver, that card being a legacy of Adaptec's buying DPT =E2=80=94 nor with= the low-end Adaptec AAR 12x0 series, which please see.) Faster at random I/O than the 3Ware cards. Optional battery is available for the card's cache, for more reliable operation in the event of power loss, etc. (Card disables the drive's write cache.) We also have the optional battery mentioned. > Does the error occur if you use a different filesystem? I haven't tried any other filesystem, yet. I'm looking for clues as to what this could be pointing to, first... and emails like yours are definitely helping, thank you very much. Cheers! --=20 Federico Sevilla III F S 3 Consulting Inc. http://www.fs3.ph --=-v7mpCcQKLTEw58Sg5en4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBG5Wga5rCBSJO3Rr4RAoYOAJ0XGQZtzVviK8rl3ovWVLAYp46IXwCfTWK7 s6vKtooj64QKV7QkAzo5PwQ= =Smnf -----END PGP SIGNATURE----- --=-v7mpCcQKLTEw58Sg5en4-- From owner-xfs@oss.sgi.com Mon Sep 10 08:54:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 08:55:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from amanpulo.fs3.ph (amanpulo.fs3.ph [72.51.42.241]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8AFst4p014594 for ; Mon, 10 Sep 2007 08:54:57 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.fs3.ph (Postfix) with ESMTP id CB8C91E0D5976 for ; Mon, 10 Sep 2007 23:54:57 +0800 (PHT) X-Virus-Scanned: Debian amavisd-new at fs3.ph Received: from amanpulo.fs3.ph ([127.0.0.1]) by localhost (amanpulo.fs3.ph [127.0.0.1]) (amavisd-new, port 10024) with LMTP id th3BAvndeRWa; Mon, 10 Sep 2007 23:54:52 +0800 (PHT) Received: from auctoritas.local (unknown [222.127.47.132]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by amanpulo.fs3.ph (Postfix) with ESMTP id CFDEF1E0D5971; Mon, 10 Sep 2007 23:54:51 +0800 (PHT) Subject: Re: Attempt to Access Beyond End of Device From: Federico Sevilla III To: linux-xfs@oss.sgi.com Cc: Alec Joseph Rivera In-Reply-To: <46E5670E.9000703@sandeen.net> References: <1189432747.4385.27.camel@auctoritas.fs3.ph> <46E5670E.9000703@sandeen.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8wE5xQWAx1sfYkeJWp2V" Organization: F S 3 Consulting Inc. Date: Mon, 10 Sep 2007 23:54:49 +0800 Message-Id: <1189439689.18040.17.camel@auctoritas.fs3.ph> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-archive-position: 12825 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jijo@fs3.ph Precedence: bulk X-list: xfs --=-8wE5xQWAx1sfYkeJWp2V Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-09-10 at 10:47 -0500, Eric Sandeen wrote: > can you send along the results of: >=20 > # xfs_db -r -c "sb 0" -c "print" /dev/sda8? Will do first thing tomorrow when I get back access to the machine, and will revert to the list. > and > # cat /proc/partitions >=20 > ... and does the hardware raid have a funky sector size? Please advise as to how best to usually find this out. For whatever it's worth, it doesn't allow us to pick a stripe width for RAID 1 (as we probably shouldn't be able to specify one, anyway). So whatever we're using is our only choice as far as the hardware RAID 1 goes. (We could probably use software RAID 1, though, if push comes to shove.) Thank you very much for your time. --=20 Federico Sevilla III F S 3 Consulting Inc. http://www.fs3.ph --=-8wE5xQWAx1sfYkeJWp2V Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBG5WjJ5rCBSJO3Rr4RAiFRAJ4+Dxw+Y7Eu0c+Sfgw/PVbSu3RiqgCeNgZk 0CQhWIv9UX0UXwKmbvQyQY0= =O5Y1 -----END PGP SIGNATURE----- --=-8wE5xQWAx1sfYkeJWp2V-- From owner-xfs@oss.sgi.com Mon Sep 10 09:28:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 09:29:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8AGSv4p019333 for ; Mon, 10 Sep 2007 09:28:59 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l8AGSrdN021639; Mon, 10 Sep 2007 12:28:53 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l8AGSrA1027789; Mon, 10 Sep 2007 12:28:53 -0400 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id l8AGSqMf031949; Mon, 10 Sep 2007 12:28:53 -0400 Message-ID: <46E570C4.6080303@sandeen.net> Date: Mon, 10 Sep 2007 11:28:52 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Federico Sevilla III CC: linux-xfs@oss.sgi.com, Alec Joseph Rivera Subject: Re: Attempt to Access Beyond End of Device References: <1189432747.4385.27.camel@auctoritas.fs3.ph> <46E5670E.9000703@sandeen.net> <1189439689.18040.17.camel@auctoritas.fs3.ph> In-Reply-To: <1189439689.18040.17.camel@auctoritas.fs3.ph> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12826 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 Federico Sevilla III wrote: > On Mon, 2007-09-10 at 10:47 -0500, Eric Sandeen wrote: >> can you send along the results of: >> >> # xfs_db -r -c "sb 0" -c "print" /dev/sda8? > > Will do first thing tomorrow when I get back access to the machine, and > will revert to the list. > >> and >> # cat /proc/partitions >> >> ... and does the hardware raid have a funky sector size? > > Please advise as to how best to usually find this out. Dunno :) FWIW, the size check that is failing is simply looking at the fs geometry and trying to go out and read the last sector. -Eric From owner-xfs@oss.sgi.com Mon Sep 10 11:30:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 11:30:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8AIUq4p000971 for ; Mon, 10 Sep 2007 11:30:53 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l8AFlS46028752; Mon, 10 Sep 2007 11:47:28 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l8AFlSvw004203; Mon, 10 Sep 2007 11:47:28 -0400 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id l8AFlRKg021128; Mon, 10 Sep 2007 11:47:27 -0400 Message-ID: <46E5670E.9000703@sandeen.net> Date: Mon, 10 Sep 2007 10:47:26 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Federico Sevilla III CC: linux-xfs@oss.sgi.com, Alec Joseph Rivera Subject: Re: Attempt to Access Beyond End of Device References: <1189432747.4385.27.camel@auctoritas.fs3.ph> In-Reply-To: <1189432747.4385.27.camel@auctoritas.fs3.ph> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12827 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 Federico Sevilla III wrote: > Hi, > > We've set up Debian GNU/Linux 4.0 "Etch" on an IBM x3400 machine with > two 73.4GB SAS hard drives in hardware RAID 1 with a battery-backed > cache. We are using the stock Debian 2.6.18-4-686 kernel. can you send along the results of: # xfs_db -r -c "sb 0" -c "print" /dev/sda8? and # cat /proc/partitions ... and does the hardware raid have a funky sector size? -Eric From owner-xfs@oss.sgi.com Mon Sep 10 18:18:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 18:18:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8B1Hv4p022434 for ; Mon, 10 Sep 2007 18:18:12 -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 LAA10928; Tue, 11 Sep 2007 11:17:53 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 0B45C58C4C09; Tue, 11 Sep 2007 11:17:52 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 970324 - Fix symlink handling in getfattr, getfacl and setfacl Message-Id: <20070911011753.0B45C58C4C09@chook.melbourne.sgi.com> Date: Tue, 11 Sep 2007 11:17:52 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-archive-position: 12828 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Fix symlink handling in getfattr, getfacl and setfacl Date: Tue Sep 11 11:17:08 AEST 2007 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: Utako Kusaka The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:29637a attr/getfattr/getfattr.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/getfattr/getfattr.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h - Fix symlink handling in getfattr acl/setfacl/setfacl.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/setfacl.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h - Fix symlink handling in setfacl acl/getfacl/getfacl.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/getfacl/getfacl.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h - Fix symlink handling in getfacl From owner-xfs@oss.sgi.com Mon Sep 10 19:07:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 19:07:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from fed1rmpop112.cox.net (fed1rmpop112.cox.net [68.230.241.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8B27e4p027066; Mon, 10 Sep 2007 19:07:42 -0700 Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070911013217.QAME20657.fed1rmmtao106.cox.net@fed1rmimpo01.cox.net>; Mon, 10 Sep 2007 21:32:17 -0400 Received: from fed1wml04.mgt.cox.net ([172.18.180.10]) by fed1rmimpo01.cox.net with bizsmtp id mpYG1X00i0DrMWL0000000; Mon, 10 Sep 2007 21:32:17 -0400 Received: from 64.202.161.130 by webmail.west.cox.net; Mon, 10 Sep 2007 21:32:16 -0400 Message-ID: <13771157.1189474338099.JavaMail.root@fed1wml04.mgt.cox.net> Date: Mon, 10 Sep 2007 18:32:17 -0700 From: Catherine Nola Reply-To: catherinenola3@jmail.co.za Subject: Claims: Ref: UK/9420X2/70 ......cx MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Priority: 3 (Normal) Sensitivity: Normal To: undisclosed-recipients:; Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l8B27g4p027073 X-archive-position: 12829 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: achambless1@cox.net Precedence: bulk X-list: xfs Greeting from the UK lottery and this notification come as a result of your winnings. You have won the sum of £4,000.000.00(Four Million Pounds Sterling). To file for your claims, do contact our agent Mrs. Catherine Nola E-mail: catherinenola3@jmail.co.za From owner-xfs@oss.sgi.com Mon Sep 10 19:07:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 19:07:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from fed1rmpop112.cox.net (fed1rmpop112.cox.net [68.230.241.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8B27e4t027066; Mon, 10 Sep 2007 19:07:47 -0700 Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070911013156.KAOR5837.fed1rmmtao105.cox.net@fed1rmimpo02.cox.net>; Mon, 10 Sep 2007 21:31:56 -0400 Received: from fed1wml04.mgt.cox.net ([172.18.180.10]) by fed1rmimpo02.cox.net with bizsmtp id mpXv1X0040DrMWL0000000; Mon, 10 Sep 2007 21:31:55 -0400 Received: from 64.202.161.130 by webmail.west.cox.net; Mon, 10 Sep 2007 21:31:53 -0400 Message-ID: <844833.1189474315157.JavaMail.root@fed1wml04.mgt.cox.net> Date: Mon, 10 Sep 2007 18:31:54 -0700 From: Catherine Nola Reply-To: catherinenola3@jmail.co.za Subject: Claims: Ref: UK/9420X2/70 ......cx MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Priority: 3 (Normal) Sensitivity: Normal To: undisclosed-recipients:; Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l8B27m4p027107 X-archive-position: 12831 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: achambless1@cox.net Precedence: bulk X-list: xfs Greeting from the UK lottery and this notification come as a result of your winnings. You have won the sum of £4,000.000.00(Four Million Pounds Sterling). To file for your claims, do contact our agent Mrs. Catherine Nola E-mail: catherinenola3@jmail.co.za From owner-xfs@oss.sgi.com Mon Sep 10 19:07:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 19:07:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from fed1rmpop112.cox.net (fed1rmpop112.cox.net [68.230.241.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8B27e4r027066; Mon, 10 Sep 2007 19:07:44 -0700 Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070911013414.EBIS11280.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>; Mon, 10 Sep 2007 21:34:14 -0400 Received: from fed1wml04.mgt.cox.net ([172.18.180.10]) by fed1rmimpo01.cox.net with bizsmtp id mpaC1X00n0DrMWL0000000; Mon, 10 Sep 2007 21:34:13 -0400 Received: from 64.202.161.130 by webmail.west.cox.net; Mon, 10 Sep 2007 21:34:11 -0400 Message-ID: <14065899.1189474453289.JavaMail.root@fed1wml04.mgt.cox.net> Date: Mon, 10 Sep 2007 18:34:13 -0700 From: Catherine Nola Reply-To: catherinenola3@jmail.co.za Subject: Claims: Ref: UK/9420X2/70 ......cx MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Priority: 3 (Normal) Sensitivity: Normal To: undisclosed-recipients:; Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l8B27j4p027088 X-archive-position: 12830 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: achambless1@cox.net Precedence: bulk X-list: xfs Greeting from the UK lottery and this notification come as a result of your winnings. You have won the sum of £4,000.000.00(Four Million Pounds Sterling). To file for your claims, do contact our agent Mrs. Catherine Nola E-mail: catherinenola3@jmail.co.za From owner-xfs@oss.sgi.com Mon Sep 10 19:30:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 19:30:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.2.0-pre1-r499012 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 l8B2Uo4p030231 for ; Mon, 10 Sep 2007 19:30:52 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA13069 for ; Tue, 11 Sep 2007 12:30:51 +1000 Date: Tue, 11 Sep 2007 12:36:32 +1000 To: "xfs@oss.sgi.com" Subject: Latest xfs-cmds source tarballs available on ftp From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-archive-position: 12832 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Updated tarballs: acl_2.2.45-1.tar.gz attr_2.4.39-1.tar.gz xfsdump_2.2.46-1.tar.gz xfsprogs_2.9.4-1.tar.gz From owner-xfs@oss.sgi.com Mon Sep 10 21:32:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 21:33:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from redback.melbourne.sgi.com (redback.melbourne.sgi.com [134.14.55.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8B4Wu4p015119 for ; Mon, 10 Sep 2007 21:32:58 -0700 Received: from redback.melbourne.sgi.com (localhost [127.0.0.1]) by redback.melbourne.sgi.com (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id l8B4ZcOR012122; Tue, 11 Sep 2007 14:35:42 +1000 Received: (from lachlan@localhost) by redback.melbourne.sgi.com (8.13.8/8.13.8/Submit) id l8B4Zcv2012121; Tue, 11 Sep 2007 14:35:38 +1000 Date: Tue, 11 Sep 2007 14:35:38 +1000 From: Lachlan McIlroy Message-Id: <200709110435.l8B4Zcv2012121@redback.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 970334 - ensure file size is logged on synchronous writes X-archive-position: 12833 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@redback.melbourne.sgi.com Precedence: bulk X-list: xfs ensure file size is logged on synchronous writes Synchronous writes currently log inode changes before syncing pages to disk. Since the file size is updated on I/O completion we wont be writing out the updated file size and if we crash the file will have the wrong size. This change moves the logging after the syncing of the pages to ensure we log the correct file size. Date: Tue Sep 11 14:31:23 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-xfs Inspected by: Christoph Hellwig The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29649a fs/xfs/linux-2.6/xfs_lrw.c - 1.267 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.267&r2=text&tr2=1.266&f=h - ensure file size is logged on synchronous writes From owner-xfs@oss.sgi.com Mon Sep 10 21:40:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 21:40:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from redback.melbourne.sgi.com (redback.melbourne.sgi.com [134.14.55.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8B4eU4p016093 for ; Mon, 10 Sep 2007 21:40:32 -0700 Received: from redback.melbourne.sgi.com (localhost [127.0.0.1]) by redback.melbourne.sgi.com (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id l8B4hFTi012234; Tue, 11 Sep 2007 14:43:17 +1000 Received: (from lachlan@localhost) by redback.melbourne.sgi.com (8.13.8/8.13.8/Submit) id l8B4hEFF012233; Tue, 11 Sep 2007 14:43:14 +1000 Date: Tue, 11 Sep 2007 14:43:14 +1000 From: Lachlan McIlroy Message-Id: <200709110443.l8B4hEFF012233@redback.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 970335 - clean up vnode/inode tracing X-archive-position: 12834 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@redback.melbourne.sgi.com Precedence: bulk X-list: xfs clean up vnode/inode tracing Simplify vnode tracing calls by embedding function name & return addr in the calling macro. Also do a lot of vnode->inode renaming for consistency, while we're at it. Signed-off-by: Eric Sandeen Date: Tue Sep 11 14:40:02 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-fixes Inspected by: Eric Sandeen The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29650a fs/xfs/xfsidbg.c - 1.332 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.332&r2=text&tr2=1.331&f=h - clean up vnode/inode tracing fs/xfs/xfs.h - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs.h.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h - clean up vnode/inode tracing fs/xfs/xfs_vnodeops.c - 1.717 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.717&r2=text&tr2=1.716&f=h - clean up vnode/inode tracing fs/xfs/xfs_iget.c - 1.233 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.233&r2=text&tr2=1.232&f=h - clean up vnode/inode tracing fs/xfs/xfs_inode.c - 1.479 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.479&r2=text&tr2=1.478&f=h - clean up vnode/inode tracing fs/xfs/xfs_inode.h - 1.233 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.233&r2=text&tr2=1.232&f=h - clean up vnode/inode tracing fs/xfs/xfs_utils.c - 1.77 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.c.diff?r1=text&tr1=1.77&r2=text&tr2=1.76&f=h - clean up vnode/inode tracing fs/xfs/xfs_utils.h - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.h.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h - clean up vnode/inode tracing fs/xfs/xfs_rename.c - 1.76 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rename.c.diff?r1=text&tr1=1.76&r2=text&tr2=1.75&f=h - clean up vnode/inode tracing fs/xfs/xfs_dir2.c - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h - clean up vnode/inode tracing fs/xfs/linux-2.6/xfs_ioctl.c - 1.152 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.152&r2=text&tr2=1.151&f=h - clean up vnode/inode tracing fs/xfs/linux-2.6/xfs_vnode.c - 1.151 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.c.diff?r1=text&tr1=1.151&r2=text&tr2=1.150&f=h - clean up vnode/inode tracing fs/xfs/linux-2.6/xfs_vnode.h - 1.139 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.139&r2=text&tr2=1.138&f=h - clean up vnode/inode tracing fs/xfs/linux-2.6/xfs_super.c - 1.396 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.396&r2=text&tr2=1.395&f=h - clean up vnode/inode tracing fs/xfs/linux-2.6/xfs_aops.c - 1.152 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.152&r2=text&tr2=1.151&f=h - clean up vnode/inode tracing fs/xfs/linux-2.6/xfs_ksyms.c - 1.71 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.71&r2=text&tr2=1.70&f=h - clean up vnode/inode tracing From owner-xfs@oss.sgi.com Mon Sep 10 21:45:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 21:45:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from redback.melbourne.sgi.com (redback.melbourne.sgi.com [134.14.55.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8B4jZ4p016838 for ; Mon, 10 Sep 2007 21:45:37 -0700 Received: from redback.melbourne.sgi.com (localhost [127.0.0.1]) by redback.melbourne.sgi.com (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id l8B4mJN9013479; Tue, 11 Sep 2007 14:48:21 +1000 Received: (from lachlan@localhost) by redback.melbourne.sgi.com (8.13.8/8.13.8/Submit) id l8B4mJ5o013478; Tue, 11 Sep 2007 14:48:19 +1000 Date: Tue, 11 Sep 2007 14:48:19 +1000 From: Lachlan McIlroy Message-Id: <200709110448.l8B4mJ5o013478@redback.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 970336 - cleanup fid types mess X-archive-position: 12835 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@redback.melbourne.sgi.com Precedence: bulk X-list: xfs cleanup fid types mess Currently XFs has three different fid types: struct fid, struct xfs_fid and struct xfs_fid2 with hte latter two beeing identicaly and the first one beeing the same size but an unstructured array with the same size. This patch consolidates all this to alway uuse struct xfs_fid. This patch is required for an upcoming patch series from me that revamps the nfs exporting code and introduces a Linux-wide struct fid. Note: the patch is ontop of Eric's inode/vnode tracing cleanup. Signed-off-by: Christoph Hellwig Date: Tue Sep 11 14:45:10 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-fixes Inspected by: Christoph Hellwig The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29651a fs/xfs/xfs_vnodeops.c - 1.718 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.718&r2=text&tr2=1.717&f=h - cleanup fid types mess fs/xfs/xfs_fs.h - 1.35 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fs.h.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h - cleanup fid types mess fs/xfs/xfs_vfsops.c - 1.538 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.538&r2=text&tr2=1.537&f=h - cleanup fid types mess fs/xfs/linux-2.6/xfs_ioctl.c - 1.153 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.153&r2=text&tr2=1.152&f=h - cleanup fid types mess fs/xfs/linux-2.6/xfs_export.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_export.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h - cleanup fid types mess fs/xfs/linux-2.6/xfs_export.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_export.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h - cleanup fid types mess fs/xfs/dmapi/xfs_dm_fsops.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm_fsops.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - cleanup fid types mess fs/xfs/dmapi/xfs_dm.c - 1.53 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h - cleanup fid types mess fs/xfs/xfs_vnodeops.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h - cleanup fid types mess fs/xfs/xfs_vfsops.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h - cleanup fid types mess From owner-xfs@oss.sgi.com Mon Sep 10 22:05:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Sep 2007 22:05:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_20,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8B55X4p018807 for ; Mon, 10 Sep 2007 22:05:34 -0700 Received: from Liberator.local (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 4570C187B8C1D for ; Tue, 11 Sep 2007 00:05:36 -0500 (CDT) Message-ID: <46E6221E.803@sandeen.net> Date: Tue, 11 Sep 2007 00:05:34 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: xfs-oss Subject: [PATCH SERIES] untangle spinlock macros Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12836 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 I have a series of patches at http://sandeen.net/xfs-patches/patches-spinlock-unobfuscate.tar.bz2 to get rid of the macros upon macros hiding xfs' use of spinlocks, via for example AIL_LOCK->mutex_spinlock->spin_lock. This also gets rid of the unused "cookie" variables declared via SPLDECL(s) and other open-coded unsigned long s; declarations. patches in the tarball, broken out by lock as requested a while ago by dgc: unwrap_AIL_LOCK unwrap_LOG_LOCK unwrap_GRANT_LOCK unwrap_XFS_DQ_PINUNLOCK unwrap_pagb_lock unwrap_xfs_dabuf_global_lock unwrap_mru_lock unwrap_XFS_SB_LOCK no_kt_lock cleanup_lock_goop Patches have comments/descriptions/signed-off lines in them. By the end of the series, spin.h is almost empty, only spin_lock_init / spinlock_destroy are left, and could maybe even be pulled out.... wasn't sure how far to go. Since the kernel has a mutex_destroy, I wonder if spinlocks will ever get similar treatment... anyway.... I can post them to the list individually if preferred... though it's fairly mechanical and not terribly interesting... Thanks, -Eric From owner-xfs@oss.sgi.com Tue Sep 11 11:02:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 11:02:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8BI2e4p023113 for ; Tue, 11 Sep 2007 11:02:43 -0700 Received: by ug-out-1314.google.com with SMTP id m3so118186ugc for ; Tue, 11 Sep 2007 11:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=0ayUC33L6vWMzgllSwd/Rs8SgizgxQxNDgx53CLOM60=; b=LyFSx503O9wdRfVGEMwUA5CW7MAmzNQ2jtdCfxG0UaeC5CZlNQ2lTPpHwt4CFHTYKVTYyyg1B5zjel+z8wvCxNVpNKwblUdd3qGKYGgWrLbqmMo+wZXUTUSQCndPgMBmKB1IeCvFJEqSMaFC97qLQRiVCET8XtQHnt6JvKNNSHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=V+Pm8cyKf5kzhSrZ9VOiZw9GjoRjyAxsZOxMjf/CwDDOj1eAjGh7oHYaNqLTMXREyOFNhmnF81/cC1sQqHr0zSGRCBHRirSxo/P0h2HoOipf6J/Kg2FMppBdHvSL5RxEu0G7OqKx6/0q9edKLZEeeBEqYSzLzHtXdfwPxX0fGSk= Received: by 10.66.250.9 with SMTP id x9mr885919ugh.1189532021962; Tue, 11 Sep 2007 10:33:41 -0700 (PDT) Received: by 10.66.222.18 with HTTP; Tue, 11 Sep 2007 10:33:41 -0700 (PDT) Message-ID: Date: Tue, 11 Sep 2007 23:03:41 +0530 From: "Bhagi rathi" To: "Zdenek Prikryl" Subject: Re: getfattr and symlinks Cc: linux-xfs@oss.sgi.com In-Reply-To: <46E52F95.3070307@redhat.com> MIME-Version: 1.0 References: <46E52F95.3070307@redhat.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 703 X-archive-position: 12837 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs My understanding on man pages says that it doesn't follow the symlink. Note that a symlink file itself can also have extended attributes. Unless specified, getfattr should just try to extract extended attributes of the symbolic link file itself. -Saradhi. On 9/10/07, Zdenek Prikryl wrote: > > Hello, > I have one question, what is right behavior of getfattr in a recursive > mode? Should getfattr follow symlinks in this mode (without [PLh] > parameters)? > > Example: > > $HOME/file.txt > $HOME/symlink -> / > ... > > getfattr -Rd $HOME > > So what is the right result? Follow "$HOME/symlink" or not? > > Thank you > > Zdenek Prikryl > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Sep 11 18:04:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 18:04:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8C1414p025169 for ; Tue, 11 Sep 2007 18:04:04 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20689; Wed, 12 Sep 2007 11:03:58 +1000 Message-ID: <46E73BAD.4000906@sgi.com> Date: Wed, 12 Sep 2007 11:06:53 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Eric Sandeen CC: xfs-oss Subject: Re: [PATCH SERIES] untangle spinlock macros References: <46E6221E.803@sandeen.net> In-Reply-To: <46E6221E.803@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12838 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs They look good to me. There's still a few unused variables left over but nothing we can't fix up. Eric Sandeen wrote: > I have a series of patches at > http://sandeen.net/xfs-patches/patches-spinlock-unobfuscate.tar.bz2 > > to get rid of the macros upon macros hiding xfs' use of spinlocks, via > for example AIL_LOCK->mutex_spinlock->spin_lock. This also gets rid of > the unused "cookie" variables declared via SPLDECL(s) and other > open-coded unsigned long s; declarations. > > patches in the tarball, broken out by lock as requested a while > ago by dgc: > > unwrap_AIL_LOCK > unwrap_LOG_LOCK > unwrap_GRANT_LOCK > unwrap_XFS_DQ_PINUNLOCK > unwrap_pagb_lock > unwrap_xfs_dabuf_global_lock > unwrap_mru_lock > unwrap_XFS_SB_LOCK > no_kt_lock > cleanup_lock_goop > > Patches have comments/descriptions/signed-off lines in them. > > By the end of the series, spin.h is almost empty, only spin_lock_init / > spinlock_destroy are left, and could maybe even be pulled out.... wasn't > sure how far to go. Since the kernel has a mutex_destroy, I wonder if > spinlocks will ever get similar treatment... anyway.... > > I can post them to the list individually if preferred... though it's > fairly mechanical and not terribly interesting... > > Thanks, > -Eric > > > From owner-xfs@oss.sgi.com Tue Sep 11 18:31:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 18:31:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.5 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8C1VI4p029775 for ; Tue, 11 Sep 2007 18:31:19 -0700 Received: by rv-out-0910.google.com with SMTP id k20so44028rvb for ; Tue, 11 Sep 2007 18:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=ef/O+zzjt4INxAYB66bLpoXt4XaR8lILn+rvkVRwZVU=; b=TuQ+J9JPI01rMsW0OvJA+PVmsPmkYkRtt9BGVOd/h0ktbLGf2iDl5duAkxj02iF0f5Y77pCf6+bG3NwZo1y9DcrVS1mqsXeYusufpTWHpHyT0JP2AcpJlL95lVCjkT4pW/Hef4Eul+N9WSdDOZqjxoIpiHK1wR1pUFXLRsLZsx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=gTHDmGHPxtpTkUTEWL5t5k8savKe+z1OrGQXWSL+8sPYCLr3gqhkE5zcCVLvCcYpZtQXHf+rx6xxO7CGoTrsXfBLMJ44XdC94YEyoVCYYpIIQZe0E0XL2mjg7uEK1lJeJDC9dm/5MzKzbECXXvMfd7Vh00sSwZ0UxN/+DoCxuSY= Received: by 10.141.23.7 with SMTP id a7mr2668287rvj.1189554200416; Tue, 11 Sep 2007 16:43:20 -0700 (PDT) Received: by 10.141.159.19 with HTTP; Tue, 11 Sep 2007 16:43:20 -0700 (PDT) Message-ID: <654e62180709111643k4700c2bdibec2a16eb5446e76@mail.gmail.com> Date: Tue, 11 Sep 2007 16:43:20 -0700 From: "Jordan Mendler" To: xfs@oss.sgi.com Subject: compression MIME-Version: 1.0 X-Google-Sender-Auth: 9a5b59e8472c4c95 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 565 X-archive-position: 12839 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jmendler@ucla.edu Precedence: bulk X-list: xfs Hi all, I searched the mailing list archive and could not find an answer. We are currently using XFS on Linux for a 17TB Volume used for backups. We are running out of space, so rather than order another array, I would like to try to implement filesystem-level compression. Does XFS support any type of compression? If not, are there any other ways to optimize for more space storage? We are doing extensive rsyncs as our method of backups, so gzipping on top of the filesystem is not really an option. Thanks so much, Jordan [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Sep 11 18:35:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 18:35:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8C1ZB4p030686 for ; Tue, 11 Sep 2007 18:35:12 -0700 Received: from Liberator.local (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 E5BFC185FC7D7; Tue, 11 Sep 2007 20:35:13 -0500 (CDT) Message-ID: <46E7424F.6030104@sandeen.net> Date: Tue, 11 Sep 2007 20:35:11 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Lachlan McIlroy CC: xfs-oss Subject: Re: [PATCH SERIES] untangle spinlock macros References: <46E6221E.803@sandeen.net> <46E73BAD.4000906@sgi.com> In-Reply-To: <46E73BAD.4000906@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12840 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 Lachlan McIlroy wrote: > They look good to me. There's still a few unused variables left over > but nothing we can't fix up. Great - and, weird - I don't see them in my tree... maybe I missed a quilt refresh, but I don't think so... odd. -Eric From owner-xfs@oss.sgi.com Tue Sep 11 18:39:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 18:39:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_40,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8C1dq4p031472 for ; Tue, 11 Sep 2007 18:39:53 -0700 Received: from Liberator.local (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 C3940185FC7D7; Tue, 11 Sep 2007 20:39:55 -0500 (CDT) Message-ID: <46E74368.5090503@sandeen.net> Date: Tue, 11 Sep 2007 20:39:52 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jordan Mendler CC: xfs@oss.sgi.com Subject: Re: compression References: <654e62180709111643k4700c2bdibec2a16eb5446e76@mail.gmail.com> In-Reply-To: <654e62180709111643k4700c2bdibec2a16eb5446e76@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12841 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 Jordan Mendler wrote: > Hi all, > > I searched the mailing list archive and could not find an answer. We are > currently using XFS on Linux for a 17TB Volume used for backups. We are > running out of space, so rather than order another array, I would like to > try to implement filesystem-level compression. Does XFS support any type of > compression? If not, are there any other ways to optimize for more space > storage? We are doing extensive rsyncs as our method of backups, so gzipping > on top of the filesystem is not really an option. > > Thanks so much, > Jordan > No native compression in xfs... and it's not got a lot of space overhead, to start with. If you're keeping multiple copies of things via complete nightly rsync backups, there are mechanisms that just symlink files which haven't changed... Or, have you looked into incremental backups via xfsdump? Dunno if any of that helps, or if you've already thought of such things. :) -Eric From owner-xfs@oss.sgi.com Tue Sep 11 18:51:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 18:51:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8C1pD4p000545 for ; Tue, 11 Sep 2007 18:51:15 -0700 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22197; Wed, 12 Sep 2007 11:51:10 +1000 Message-ID: <46E7460D.3000502@sgi.com> Date: Wed, 12 Sep 2007 11:51:09 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Eric Sandeen CC: xfs-oss Subject: Re: [PATCH SERIES] untangle spinlock macros References: <46E6221E.803@sandeen.net> In-Reply-To: <46E6221E.803@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12842 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > I have a series of patches at > http://sandeen.net/xfs-patches/patches-spinlock-unobfuscate.tar.bz2 > > to get rid of the macros upon macros hiding xfs' use of spinlocks, via > for example AIL_LOCK->mutex_spinlock->spin_lock. This also gets rid of > the unused "cookie" variables declared via SPLDECL(s) and other > open-coded unsigned long s; declarations. > Hi Eric, > unwrap_AIL_LOCK Here you change the comment to use the descriptive name - * We must not be holding the AIL_LOCK at this point. Calling incore() to - * search the buffer cache can be a time consuming thing, and AIL_LOCK is a + * We must not be holding the AIL lock at this point. Calling incore() to + * search the buffer cache can be a time consuming thing, and AIL lock is a * spinlock. */ > unwrap_LOG_LOCK > unwrap_GRANT_LOCK > unwrap_XFS_DQ_PINUNLOCK > unwrap_pagb_lock > unwrap_xfs_dabuf_global_lock > unwrap_mru_lock > unwrap_XFS_SB_LOCK But here you use the name of the lock variable. /* - * We actually don't have to acquire the SB_LOCK at all. + * We actually don't have to acquire the m_sb_lock at all. * This can only be called from mount, and that's single threaded. XXX */ > no_kt_lock > cleanup_lock_goop > > Patches have comments/descriptions/signed-off lines in them. > > By the end of the series, spin.h is almost empty, only spin_lock_init / > spinlock_destroy are left, and could maybe even be pulled out.... wasn't > sure how far to go. Since the kernel has a mutex_destroy, I wonder if > spinlocks will ever get similar treatment... anyway.... So the only things left in spin.h are the spinlock headers and #define spinlock_init(lock, name) spin_lock_init(lock) #define spinlock_destroy(lock) I cant se why we need these abstractions. Should we nuke the whole file and add the spinlock headers elsewhere? Don From owner-xfs@oss.sgi.com Tue Sep 11 18:55:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 18:55:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8C1tS4p001307 for ; Tue, 11 Sep 2007 18:55:29 -0700 Received: from Liberator.local (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 EEB6C180000AF; Tue, 11 Sep 2007 20:55:31 -0500 (CDT) Message-ID: <46E74711.5050108@sandeen.net> Date: Tue, 11 Sep 2007 20:55:29 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Donald Douwsma CC: xfs-oss Subject: Re: [PATCH SERIES] untangle spinlock macros References: <46E6221E.803@sandeen.net> <46E7460D.3000502@sgi.com> In-Reply-To: <46E7460D.3000502@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12843 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 Donald Douwsma wrote: > Hi Eric, > >> unwrap_AIL_LOCK > Here you change the comment to use the descriptive name > > - * We must not be holding the AIL_LOCK at this point. Calling incore() to > - * search the buffer cache can be a time consuming thing, and AIL_LOCK is a > + * We must not be holding the AIL lock at this point. Calling incore() to > + * search the buffer cache can be a time consuming thing, and AIL lock is a > * spinlock. > */ > >> unwrap_LOG_LOCK >> unwrap_GRANT_LOCK >> unwrap_XFS_DQ_PINUNLOCK >> unwrap_pagb_lock >> unwrap_xfs_dabuf_global_lock >> unwrap_mru_lock >> unwrap_XFS_SB_LOCK > But here you use the name of the lock variable. > > /* > - * We actually don't have to acquire the SB_LOCK at all. > + * We actually don't have to acquire the m_sb_lock at all. > * This can only be called from mount, and that's single threaded. XXX > */ Hm yup. 2 different evenings, oops. ;-) Have a preference? >> no_kt_lock >> cleanup_lock_goop >> >> Patches have comments/descriptions/signed-off lines in them. >> >> By the end of the series, spin.h is almost empty, only spin_lock_init / >> spinlock_destroy are left, and could maybe even be pulled out.... wasn't >> sure how far to go. Since the kernel has a mutex_destroy, I wonder if >> spinlocks will ever get similar treatment... anyway.... > So the only things left in spin.h are the spinlock headers and > > #define spinlock_init(lock, name) spin_lock_init(lock) > #define spinlock_destroy(lock) > > I cant se why we need these abstractions. Should we nuke the whole file and > add the spinlock headers elsewhere? We don't, really. It'd be easy to nuke the file and add them to xfs_linux.h. I'll send a patch to do so if you like. -Eric From owner-xfs@oss.sgi.com Tue Sep 11 19:07:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 19:07:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8C27O4p002953 for ; Tue, 11 Sep 2007 19:07:25 -0700 Received: from Liberator.local (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 29727182E10E8; Tue, 11 Sep 2007 21:07:28 -0500 (CDT) Message-ID: <46E749DD.8010200@sandeen.net> Date: Tue, 11 Sep 2007 21:07:25 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Donald Douwsma CC: xfs-oss Subject: Re: [PATCH SERIES] untangle spinlock macros References: <46E6221E.803@sandeen.net> <46E7460D.3000502@sgi.com> In-Reply-To: <46E7460D.3000502@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12844 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 Donald Douwsma wrote: > > So the only things left in spin.h are the spinlock headers and > > #define spinlock_init(lock, name) spin_lock_init(lock) > #define spinlock_destroy(lock) > > I cant se why we need these abstractions. Should we nuke the whole file and > add the spinlock headers elsewhere? > > Don > > Ok, if you want it :) ------------------------- remove abstraction macros in spin.h, remove the callers, and remove the file. Signed-off-by: Eric Sandeen Index: linux-2.6-xfs/fs/xfs/linux-2.6/spin.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/spin.h +++ /dev/null @@ -1,27 +0,0 @@ -/* - * Copyright (c) 2000-2002,2005 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 - */ -#ifndef __XFS_SUPPORT_SPIN_H__ -#define __XFS_SUPPORT_SPIN_H__ - -#include /* preempt needs this */ -#include - -#define spinlock_init(lock, name) spin_lock_init(lock) -#define spinlock_destroy(lock) - -#endif /* __XFS_SUPPORT_SPIN_H__ */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_buf.c +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c @@ -1568,7 +1568,7 @@ xfs_alloc_delwrite_queue( INIT_LIST_HEAD(&btp->bt_list); INIT_LIST_HEAD(&btp->bt_delwrite_queue); - spinlock_init(&btp->bt_delwrite_lock, "delwri_lock"); + spin_lock_init(&btp->bt_delwrite_lock); btp->bt_flags = 0; btp->bt_task = kthread_run(xfsbufd, btp, "xfsbufd"); if (IS_ERR(btp->bt_task)) { Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_linux.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_linux.h +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_linux.h @@ -43,7 +43,6 @@ #include #include -#include #include #include #include @@ -75,6 +74,7 @@ #include #include #include +#include #include #include Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm.c +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm.c @@ -1131,7 +1131,7 @@ xfs_qm_init_quotainfo( return error; } - spinlock_init(&qinf->qi_pinlock, "xfs_qinf_pin"); + spin_lock_init(&qinf->qi_pinlock); xfs_qm_list_init(&qinf->qi_dqlist, "mpdqlist", 0); qinf->qi_dqreclaims = 0; @@ -1228,7 +1228,6 @@ xfs_qm_destroy_quotainfo( */ xfs_qm_rele_quotafs_ref(mp); - spinlock_destroy(&qi->qi_pinlock); xfs_qm_list_destroy(&qi->qi_dqlist); if (qi->qi_uquotaip) { Index: linux-2.6-xfs/fs/xfs/support/debug.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/support/debug.c +++ linux-2.6-xfs/fs/xfs/support/debug.c @@ -17,7 +17,6 @@ */ #include #include "debug.h" -#include "spin.h" static char message[1024]; /* keep it off the stack */ static DEFINE_SPINLOCK(xfs_err_lock); Index: linux-2.6-xfs/fs/xfs/support/ktrace.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/support/ktrace.h +++ linux-2.6-xfs/fs/xfs/support/ktrace.h @@ -18,8 +18,6 @@ #ifndef __XFS_SUPPORT_KTRACE_H__ #define __XFS_SUPPORT_KTRACE_H__ -#include - /* * Trace buffer entry structure. */ Index: linux-2.6-xfs/fs/xfs/xfs_alloc.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_alloc.c +++ linux-2.6-xfs/fs/xfs/xfs_alloc.c @@ -2206,7 +2206,7 @@ xfs_alloc_read_agf( be32_to_cpu(agf->agf_levels[XFS_BTNUM_BNOi]); pag->pagf_levels[XFS_BTNUM_CNTi] = be32_to_cpu(agf->agf_levels[XFS_BTNUM_CNTi]); - spinlock_init(&pag->pagb_lock, "xfspagb"); + spin_lock_init(&pag->pagb_lock); pag->pagb_list = kmem_zalloc(XFS_PAGB_NUM_SLOTS * sizeof(xfs_perag_busy_t), KM_SLEEP); pag->pagf_init = 1; Index: linux-2.6-xfs/fs/xfs/xfs_log.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log.c +++ linux-2.6-xfs/fs/xfs/xfs_log.c @@ -1189,8 +1189,8 @@ xlog_alloc_log(xfs_mount_t *mp, ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); log->l_xbuf = bp; - spinlock_init(&log->l_icloglock, "iclog"); - spinlock_init(&log->l_grant_lock, "grhead_iclog"); + spin_lock_init(&log->l_icloglock); + spin_lock_init(&log->l_grant_lock); initnsema(&log->l_flushsema, 0, "ic-flush"); xlog_state_ticket_alloc(log); /* wait until after icloglock inited */ @@ -1543,8 +1543,6 @@ xlog_dealloc_log(xlog_t *log) iclog = next_iclog; } freesema(&log->l_flushsema); - spinlock_destroy(&log->l_icloglock); - spinlock_destroy(&log->l_grant_lock); /* XXXsup take a look at this again. */ if ((log->l_ticket_cnt != log->l_ticket_tcnt) && Index: linux-2.6-xfs/fs/xfs/xfs_mount.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c +++ linux-2.6-xfs/fs/xfs/xfs_mount.c @@ -136,8 +136,8 @@ xfs_mount_init(void) mp->m_flags |= XFS_MOUNT_NO_PERCPU_SB; } - spinlock_init(&mp->m_ail_lock, "xfs_ail"); - spinlock_init(&mp->m_sb_lock, "xfs_sb"); + spin_lock_init(&mp->m_ail_lock); + spin_lock_init(&mp->m_sb_lock); mutex_init(&mp->m_ilock); mutex_init(&mp->m_growlock); /* @@ -171,8 +171,6 @@ xfs_mount_free( sizeof(xfs_perag_t) * mp->m_sb.sb_agcount); } - spinlock_destroy(&mp->m_ail_lock); - spinlock_destroy(&mp->m_sb_lock); mutex_destroy(&mp->m_ilock); mutex_destroy(&mp->m_growlock); if (mp->m_quotainfo) @@ -616,7 +614,7 @@ xfs_mount_common(xfs_mount_t *mp, xfs_sb int i; mp->m_agfrotor = mp->m_agirotor = 0; - spinlock_init(&mp->m_agirotor_lock, "m_agirotor_lock"); + spin_lock_init(&mp->m_agirotor_lock); mp->m_maxagi = mp->m_sb.sb_agcount; mp->m_blkbit_log = sbp->sb_blocklog + XFS_NBBYLOG; mp->m_blkbb_log = sbp->sb_blocklog - BBSHIFT; Index: linux-2.6-xfs/fs/xfs/xfs_mru_cache.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mru_cache.c +++ linux-2.6-xfs/fs/xfs/xfs_mru_cache.c @@ -368,7 +368,7 @@ xfs_mru_cache_create( */ INIT_RADIX_TREE(&mru->store, GFP_ATOMIC); INIT_LIST_HEAD(&mru->reap_list); - spinlock_init(&mru->lock, "xfs_mru_cache"); + spin_lock_init(&mru->lock); INIT_DELAYED_WORK(&mru->work, _xfs_mru_cache_reap); mru->grp_time = grp_time; Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c @@ -68,7 +68,7 @@ xfs_init(void) extern kmem_zone_t *xfs_dabuf_zone; #ifdef XFS_DABUF_DEBUG extern spinlock_t xfs_dabuf_global_lock; - spinlock_init(&xfs_dabuf_global_lock, "xfsda"); + spin_lock_init(&xfs_dabuf_global_lock); #endif /* From owner-xfs@oss.sgi.com Tue Sep 11 20:05:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 20:05:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.5 required=5.0 tests=AWL,BAYES_40,HTML_MESSAGE autolearn=no version=3.2.0-pre1-r499012 Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8C35k4p009925 for ; Tue, 11 Sep 2007 20:05:47 -0700 Received: by rv-out-0910.google.com with SMTP id k20so61152rvb for ; Tue, 11 Sep 2007 20:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=2/L2DdfX1jYXcMLtyiAAh6fwt2aX/8RH0BeTICBz0TA=; b=W9KLtZOnZvzbS8dD7f73Xlr30wcmPddgRwF44Dx9GN8mw+MIL+sIX29yrO8COVAR9eLvLhKfS/lrGTs5fbI90eIGKkGoWxO7MpUDwIVsoj5mwZv7686k1IxOJ9dyJoJ4g3tfll68/PaFMQjC/ZOPudakqnnru+zvCG7TQOJSk10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=p9wUQSPWxjvQvVSpsLRd7Rg/549OPQukkduNA7qcvKpR5BgDhm1Wi6fsuGw0fACThCpin/ppLh9f9809y9005B3I9ubhL/oOAq6NheoQNzOVF/HaE5/B6tLxlzjlu13Kj+DpZLNFGHSoesDiDXs2BRwGdB7NoW6fVnxJwwSJHjg= Received: by 10.141.88.3 with SMTP id q3mr3324rvl.1189566348412; Tue, 11 Sep 2007 20:05:48 -0700 (PDT) Received: by 10.141.159.19 with HTTP; Tue, 11 Sep 2007 20:05:48 -0700 (PDT) Message-ID: <654e62180709112005l6b70b0f2s423bda10a950fcfd@mail.gmail.com> Date: Tue, 11 Sep 2007 20:05:48 -0700 From: "Jordan Mendler" To: "Eric Sandeen" Subject: Re: compression Cc: xfs@oss.sgi.com In-Reply-To: <46E74368.5090503@sandeen.net> MIME-Version: 1.0 References: <654e62180709111643k4700c2bdibec2a16eb5446e76@mail.gmail.com> <46E74368.5090503@sandeen.net> X-Google-Sender-Auth: f9f2118a8e568623 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1216 X-archive-position: 12845 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jmendler@ucla.edu Precedence: bulk X-list: xfs Do you know if there any plans to implement compression any time in the somewhat near future? Thanks, Jordan On 9/11/07, Eric Sandeen wrote: > > Jordan Mendler wrote: > > Hi all, > > > > I searched the mailing list archive and could not find an answer. We are > > currently using XFS on Linux for a 17TB Volume used for backups. We are > > running out of space, so rather than order another array, I would like > to > > try to implement filesystem-level compression. Does XFS support any type > of > > compression? If not, are there any other ways to optimize for more space > > storage? We are doing extensive rsyncs as our method of backups, so > gzipping > > on top of the filesystem is not really an option. > > > > Thanks so much, > > Jordan > > > > No native compression in xfs... and it's not got a lot of space > overhead, to start with. > > If you're keeping multiple copies of things via complete nightly rsync > backups, there are mechanisms that just symlink files which haven't > changed... Or, have you looked into incremental backups via xfsdump? > Dunno if any of that helps, or if you've already thought of such > things. :) > > -Eric > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Sep 11 21:07:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 21:07:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8C4724p021539 for ; Tue, 11 Sep 2007 21:07:04 -0700 Received: from Liberator.local (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 252AD18003EF0; Tue, 11 Sep 2007 23:07:05 -0500 (CDT) Message-ID: <46E765E6.4080904@sandeen.net> Date: Tue, 11 Sep 2007 23:07:02 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jordan Mendler CC: xfs@oss.sgi.com Subject: Re: compression References: <654e62180709111643k4700c2bdibec2a16eb5446e76@mail.gmail.com> <46E74368.5090503@sandeen.net> <654e62180709112005l6b70b0f2s423bda10a950fcfd@mail.gmail.com> In-Reply-To: <654e62180709112005l6b70b0f2s423bda10a950fcfd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12846 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 Jordan Mendler wrote: > Do you know if there any plans to implement compression any time in the > somewhat near future? I don't think so. Certainly not before your 17T fills up ;-) -Eric > Thanks, Jordan From owner-xfs@oss.sgi.com Tue Sep 11 22:17:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 22:17:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from amanpulo.fs3.ph (amanpulo.fs3.ph [72.51.42.241]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8C5HJ4p032031 for ; Tue, 11 Sep 2007 22:17:21 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.fs3.ph (Postfix) with ESMTP id 826321E0D5976 for ; Wed, 12 Sep 2007 13:17:20 +0800 (PHT) X-Virus-Scanned: Debian amavisd-new at fs3.ph Received: from amanpulo.fs3.ph ([127.0.0.1]) by localhost (amanpulo.fs3.ph [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g9ts5uBO-Zwp; Wed, 12 Sep 2007 13:17:11 +0800 (PHT) Received: by amanpulo.fs3.ph (Postfix, from userid 33) id CD3F51E0D5943; Wed, 12 Sep 2007 13:17:11 +0800 (PHT) Received: from 161.126.62.20 ([161.126.62.20]) by mail.fs3.ph (Horde MIME library) with HTTP; Wed, 12 Sep 2007 13:17:11 +0800 Message-ID: <20070912131711.t31p9zm3y8ssoks0@mail.fs3.ph> Date: Wed, 12 Sep 2007 13:17:11 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Cc: Alec Joseph Rivera Subject: Re: Attempt to Access Beyond End of Device References: <1189432747.4385.27.camel@auctoritas.fs3.ph> <46E5670E.9000703@sandeen.net> <1189439689.18040.17.camel@auctoritas.fs3.ph> <46E570C4.6080303@sandeen.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l8C5HM4p032037 X-archive-position: 12847 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jijo@fs3.ph Precedence: bulk X-list: xfs Hi, Quoting Bhagi rathi : > I hope your problem with xfs_repair is resolved. It wasn't an XFS-centric problem, after all. Running cfdisk on the system would likewise fail because the partition had been set beyond the disk boundary. I'm not sure about how this happened. Either the controller reported a large size to Debian during installation, or Debian mis-read the reported size on installation. At any rate, redoing the entire installation (including RAID setup) with the same procedure resulted in the correct (ie: smaller) disk boundaries, so the server is back up with the new size. > Please set your incore log buffer size as a sub-multiple of your log size, > log size % in core buffer size should be zero (modulo is the operator). This > is advisable, though not mandatory. Having huge incore buffer size is of no > help if your on disk log size isn't big. This might solve your problem with > repair and recovery after some reboots. Make sure that total incore buffer > size is less than on disk logsize. Previously, we were using version=1 logs with size=32768b, and then mounted using logbufs=8,logbsize=32768. Now, we are using version=2 logs with size=32768b, and then mounted using logbufs=8,logbsize=256k. If I understand your advise correctly, I should not mount with logbsize > 32k, or I should create the filesystem using version=2 logs with size=256k. Is this understanding correct? Are there generic optimization suggestions for I/O-intensive servers in general, as far as on-disk and in-memory log buffer sizes are concerned? Please advise. Thank you very much. -- Federico Sevilla III F S 3 Consulting Inc. http://www.fs3.ph From owner-xfs@oss.sgi.com Tue Sep 11 22:47:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 22:47:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8C5lm4p003691 for ; Tue, 11 Sep 2007 22:47:51 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA27527; Wed, 12 Sep 2007 15:47:45 +1000 Message-ID: <46E77E30.4000302@sgi.com> Date: Wed, 12 Sep 2007 15:50:40 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Eric Sandeen CC: xfs-oss Subject: Re: [PATCH SERIES] untangle spinlock macros References: <46E6221E.803@sandeen.net> <46E73BAD.4000906@sgi.com> <46E7424F.6030104@sandeen.net> In-Reply-To: <46E7424F.6030104@sandeen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 12848 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Just these ones... not a problem. fs/xfs/xfs_mount.c: In function ‘xfs_icsb_cpu_notify’: fs/xfs/xfs_mount.c:1920: warning: unused variable ‘s’ fs/xfs/xfs_mount.c: In function ‘xfs_icsb_sync_counters_flags’: fs/xfs/xfs_mount.c:2191: warning: unused variable ‘s’ fs/xfs/xfs_mount.c: In function ‘xfs_icsb_balance_counter’: fs/xfs/xfs_mount.c:2249: warning: unused variable ‘s’ fs/xfs/xfs_mount.c: In function ‘xfs_icsb_modify_counters’: fs/xfs/xfs_mount.c:2299: warning: unused variable ‘s’ Eric Sandeen wrote: > Lachlan McIlroy wrote: >> They look good to me. There's still a few unused variables left over >> but nothing we can't fix up. > > Great - and, weird - I don't see them in my tree... maybe I missed a > quilt refresh, but I don't think so... odd. > > -Eric > > > From owner-xfs@oss.sgi.com Tue Sep 11 23:02:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Sep 2007 23:02:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8C6264p005896 for ; Tue, 11 Sep 2007 23:02:10 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA27861; Wed, 12 Sep 2007 16:01:58 +1000 Message-ID: <46E78185.5040201@sgi.com> Date: Wed, 12 Sep 2007 16:04:53 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Eric Sandeen CC: Donald Douwsma , xfs-oss Subject: Re: [PATCH SERIES] untangle spinlock macros References: <46E6221E.803@sandeen.net> <46E7460D.3000502@sgi.com> <46E749DD.8010200@sandeen.net> In-Reply-To: <46E749DD.8010200@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12849 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs These changes look good Eric. I'm in two minds about losing the spinlock_destroy() macros though. If Linux ever implements a spinlock teardown routine it would be nice to still have all the placeholders still there. Although I can't imagine it would do any more than assert that the lock is not currently held. If someone else wants to lose the macros then I'm not going to argue. Eric Sandeen wrote: > Donald Douwsma wrote: > >> >> So the only things left in spin.h are the spinlock headers and >> >> #define spinlock_init(lock, name) spin_lock_init(lock) >> #define spinlock_destroy(lock) >> >> I cant se why we need these abstractions. Should we nuke the whole file and >> add the spinlock headers elsewhere? >> >> Don >> >> > Ok, if you want it :) > > ------------------------- > > remove abstraction macros in spin.h, remove the callers, and > remove the file. > > Signed-off-by: Eric Sandeen > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/spin.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/spin.h > +++ /dev/null > @@ -1,27 +0,0 @@ > -/* > - * Copyright (c) 2000-2002,2005 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 > - */ > -#ifndef __XFS_SUPPORT_SPIN_H__ > -#define __XFS_SUPPORT_SPIN_H__ > - > -#include /* preempt needs this */ > -#include > - > -#define spinlock_init(lock, name) spin_lock_init(lock) > -#define spinlock_destroy(lock) > - > -#endif /* __XFS_SUPPORT_SPIN_H__ */ > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_buf.c > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c > @@ -1568,7 +1568,7 @@ xfs_alloc_delwrite_queue( > > INIT_LIST_HEAD(&btp->bt_list); > INIT_LIST_HEAD(&btp->bt_delwrite_queue); > - spinlock_init(&btp->bt_delwrite_lock, "delwri_lock"); > + spin_lock_init(&btp->bt_delwrite_lock); > btp->bt_flags = 0; > btp->bt_task = kthread_run(xfsbufd, btp, "xfsbufd"); > if (IS_ERR(btp->bt_task)) { > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_linux.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_linux.h > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_linux.h > @@ -43,7 +43,6 @@ > > #include > #include > -#include > #include > #include > #include > @@ -75,6 +74,7 @@ > #include > #include > #include > +#include > > #include > #include > Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm.c > +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm.c > @@ -1131,7 +1131,7 @@ xfs_qm_init_quotainfo( > return error; > } > > - spinlock_init(&qinf->qi_pinlock, "xfs_qinf_pin"); > + spin_lock_init(&qinf->qi_pinlock); > xfs_qm_list_init(&qinf->qi_dqlist, "mpdqlist", 0); > qinf->qi_dqreclaims = 0; > > @@ -1228,7 +1228,6 @@ xfs_qm_destroy_quotainfo( > */ > xfs_qm_rele_quotafs_ref(mp); > > - spinlock_destroy(&qi->qi_pinlock); > xfs_qm_list_destroy(&qi->qi_dqlist); > > if (qi->qi_uquotaip) { > Index: linux-2.6-xfs/fs/xfs/support/debug.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/support/debug.c > +++ linux-2.6-xfs/fs/xfs/support/debug.c > @@ -17,7 +17,6 @@ > */ > #include > #include "debug.h" > -#include "spin.h" > > static char message[1024]; /* keep it off the stack */ > static DEFINE_SPINLOCK(xfs_err_lock); > Index: linux-2.6-xfs/fs/xfs/support/ktrace.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/support/ktrace.h > +++ linux-2.6-xfs/fs/xfs/support/ktrace.h > @@ -18,8 +18,6 @@ > #ifndef __XFS_SUPPORT_KTRACE_H__ > #define __XFS_SUPPORT_KTRACE_H__ > > -#include > - > /* > * Trace buffer entry structure. > */ > Index: linux-2.6-xfs/fs/xfs/xfs_alloc.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_alloc.c > +++ linux-2.6-xfs/fs/xfs/xfs_alloc.c > @@ -2206,7 +2206,7 @@ xfs_alloc_read_agf( > be32_to_cpu(agf->agf_levels[XFS_BTNUM_BNOi]); > pag->pagf_levels[XFS_BTNUM_CNTi] = > be32_to_cpu(agf->agf_levels[XFS_BTNUM_CNTi]); > - spinlock_init(&pag->pagb_lock, "xfspagb"); > + spin_lock_init(&pag->pagb_lock); > pag->pagb_list = kmem_zalloc(XFS_PAGB_NUM_SLOTS * > sizeof(xfs_perag_busy_t), KM_SLEEP); > pag->pagf_init = 1; > Index: linux-2.6-xfs/fs/xfs/xfs_log.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_log.c > +++ linux-2.6-xfs/fs/xfs/xfs_log.c > @@ -1189,8 +1189,8 @@ xlog_alloc_log(xfs_mount_t *mp, > ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); > log->l_xbuf = bp; > > - spinlock_init(&log->l_icloglock, "iclog"); > - spinlock_init(&log->l_grant_lock, "grhead_iclog"); > + spin_lock_init(&log->l_icloglock); > + spin_lock_init(&log->l_grant_lock); > initnsema(&log->l_flushsema, 0, "ic-flush"); > xlog_state_ticket_alloc(log); /* wait until after icloglock inited */ > > @@ -1543,8 +1543,6 @@ xlog_dealloc_log(xlog_t *log) > iclog = next_iclog; > } > freesema(&log->l_flushsema); > - spinlock_destroy(&log->l_icloglock); > - spinlock_destroy(&log->l_grant_lock); > > /* XXXsup take a look at this again. */ > if ((log->l_ticket_cnt != log->l_ticket_tcnt) && > Index: linux-2.6-xfs/fs/xfs/xfs_mount.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c > +++ linux-2.6-xfs/fs/xfs/xfs_mount.c > @@ -136,8 +136,8 @@ xfs_mount_init(void) > mp->m_flags |= XFS_MOUNT_NO_PERCPU_SB; > } > > - spinlock_init(&mp->m_ail_lock, "xfs_ail"); > - spinlock_init(&mp->m_sb_lock, "xfs_sb"); > + spin_lock_init(&mp->m_ail_lock); > + spin_lock_init(&mp->m_sb_lock); > mutex_init(&mp->m_ilock); > mutex_init(&mp->m_growlock); > /* > @@ -171,8 +171,6 @@ xfs_mount_free( > sizeof(xfs_perag_t) * mp->m_sb.sb_agcount); > } > > - spinlock_destroy(&mp->m_ail_lock); > - spinlock_destroy(&mp->m_sb_lock); > mutex_destroy(&mp->m_ilock); > mutex_destroy(&mp->m_growlock); > if (mp->m_quotainfo) > @@ -616,7 +614,7 @@ xfs_mount_common(xfs_mount_t *mp, xfs_sb > int i; > > mp->m_agfrotor = mp->m_agirotor = 0; > - spinlock_init(&mp->m_agirotor_lock, "m_agirotor_lock"); > + spin_lock_init(&mp->m_agirotor_lock); > mp->m_maxagi = mp->m_sb.sb_agcount; > mp->m_blkbit_log = sbp->sb_blocklog + XFS_NBBYLOG; > mp->m_blkbb_log = sbp->sb_blocklog - BBSHIFT; > Index: linux-2.6-xfs/fs/xfs/xfs_mru_cache.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_mru_cache.c > +++ linux-2.6-xfs/fs/xfs/xfs_mru_cache.c > @@ -368,7 +368,7 @@ xfs_mru_cache_create( > */ > INIT_RADIX_TREE(&mru->store, GFP_ATOMIC); > INIT_LIST_HEAD(&mru->reap_list); > - spinlock_init(&mru->lock, "xfs_mru_cache"); > + spin_lock_init(&mru->lock); > INIT_DELAYED_WORK(&mru->work, _xfs_mru_cache_reap); > > mru->grp_time = grp_time; > Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c > +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c > @@ -68,7 +68,7 @@ xfs_init(void) > extern kmem_zone_t *xfs_dabuf_zone; > #ifdef XFS_DABUF_DEBUG > extern spinlock_t xfs_dabuf_global_lock; > - spinlock_init(&xfs_dabuf_global_lock, "xfsda"); > + spin_lock_init(&xfs_dabuf_global_lock); > #endif > > /* > > > > From owner-xfs@oss.sgi.com Wed Sep 12 01:56:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 01:57:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8C8uq4p003409 for ; Wed, 12 Sep 2007 01:56:55 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IVNbR-0006lG-47; Wed, 12 Sep 2007 09:29:41 +0100 Date: Wed, 12 Sep 2007 09:29:41 +0100 From: Christoph Hellwig To: Lachlan McIlroy Cc: Eric Sandeen , Donald Douwsma , xfs-oss Subject: Re: [PATCH SERIES] untangle spinlock macros Message-ID: <20070912082940.GA25373@infradead.org> References: <46E6221E.803@sandeen.net> <46E7460D.3000502@sgi.com> <46E749DD.8010200@sandeen.net> <46E78185.5040201@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E78185.5040201@sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 12850 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Sep 12, 2007 at 04:04:53PM +1000, Lachlan McIlroy wrote: > These changes look good Eric. > > I'm in two minds about losing the spinlock_destroy() macros though. If > Linux > ever implements a spinlock teardown routine it would be nice to still have > all > the placeholders still there. Although I can't imagine it would do any more > than assert that the lock is not currently held. If someone else wants to > lose > the macros then I'm not going to argue. I'd say keep them for now. We don't need the spin.h header for them anyway, as single macro can simply move to xfs_linux.h From owner-xfs@oss.sgi.com Wed Sep 12 05:56:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 05:56:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8CCtw4p006566 for ; Wed, 12 Sep 2007 05:56:02 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l8CCJdA5016929 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 12 Sep 2007 14:19:39 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8CCJdRZ016927 for xfs@oss.sgi.com; Wed, 12 Sep 2007 14:19:39 +0200 Date: Wed, 12 Sep 2007 14:19:39 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: state of the cvs tree Message-ID: <20070912121938.GA16870@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12851 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs looks like the cvs tree is broken currently - fs/xfs/ is merged up to 2.6.23-rc, but everything else is still at 2.6.22-rc state leading to various compile failures. From owner-xfs@oss.sgi.com Wed Sep 12 07:32:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 07:32:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8CEWi4p024402 for ; Wed, 12 Sep 2007 07:32:47 -0700 Received: from Liberator.local (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 9216E18003EF0; Wed, 12 Sep 2007 09:32:47 -0500 (CDT) Message-ID: <46E7F88B.4020805@sandeen.net> Date: Wed, 12 Sep 2007 09:32:43 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Lachlan McIlroy CC: xfs-oss Subject: Re: [PATCH SERIES] untangle spinlock macros References: <46E6221E.803@sandeen.net> <46E73BAD.4000906@sgi.com> <46E7424F.6030104@sandeen.net> <46E77E30.4000302@sgi.com> In-Reply-To: <46E77E30.4000302@sgi.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-archive-position: 12852 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 Lachlan McIlroy wrote: > Just these ones... not a problem. > > fs/xfs/xfs_mount.c: In function ‘xfs_icsb_cpu_notify’: > fs/xfs/xfs_mount.c:1920: warning: unused variable ‘s’ > fs/xfs/xfs_mount.c: In function ‘xfs_icsb_sync_counters_flags’: > fs/xfs/xfs_mount.c:2191: warning: unused variable ‘s’ > fs/xfs/xfs_mount.c: In function ‘xfs_icsb_balance_counter’: > fs/xfs/xfs_mount.c:2249: warning: unused variable ‘s’ > fs/xfs/xfs_mount.c: In function ‘xfs_icsb_modify_counters’: > fs/xfs/xfs_mount.c:2299: warning: unused variable ‘s’ Ah, I didn't build with CONFIG_HOTPLUG_CPU, whoops! Ok, I'll let you tidy that up ;-) and add it to my default config I guess! -Eric From owner-xfs@oss.sgi.com Wed Sep 12 10:42:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 10:42:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8CHgG4p024914 for ; Wed, 12 Sep 2007 10:42:19 -0700 Received: from filer.fsl.cs.sunysb.edu (localhost.localdomain [127.0.0.1]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id l8CHgGW1006690; Wed, 12 Sep 2007 13:42:16 -0400 Received: (from jsipek@localhost) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1/Submit) id l8CHgGC9006688; Wed, 12 Sep 2007 13:42:16 -0400 X-Authentication-Warning: filer.fsl.cs.sunysb.edu: jsipek set sender to jsipek@fsl.cs.sunysb.edu using -f Date: Wed, 12 Sep 2007 13:42:16 -0400 From: Josef Sipek To: Jordan Mendler Cc: xfs@oss.sgi.com Subject: Re: compression Message-ID: <20070912174216.GA5521@filer.fsl.cs.sunysb.edu> References: <654e62180709111643k4700c2bdibec2a16eb5446e76@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <654e62180709111643k4700c2bdibec2a16eb5446e76@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-07-16) X-archive-position: 12853 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jsipek@fsl.cs.sunysb.edu Precedence: bulk X-list: xfs On Tue, Sep 11, 2007 at 04:43:20PM -0700, Jordan Mendler wrote: > Hi all, > > I searched the mailing list archive and could not find an answer. We are > currently using XFS on Linux for a 17TB Volume used for backups. We are > running out of space, so rather than order another array, I would like to > try to implement filesystem-level compression. Does XFS support any type of > compression? If not, are there any other ways to optimize for more space > storage? We are doing extensive rsyncs as our method of backups, so gzipping > on top of the filesystem is not really an option. Implementation-wise, one major thing to keep in mind is that offsets into the uncompressed copies of files in memory need to be mapped to the compressed ones. This is rather painful if you want to do things right (supporting writing as well as reading from files). As Eric mentioned, you may want to try to eliminate copies of identical files with symlinks or even hardlinks (just make sure your backup sw is smart enough to break links when necessary). Josef 'Jeff' Sipek. -- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw From owner-xfs@oss.sgi.com Wed Sep 12 16:05:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 16:05:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 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 l8CN5R4p002517 for ; Wed, 12 Sep 2007 16:05:30 -0700 Received: from [134.15.251.6] (melb-sw-corp-251-6.corp.sgi.com [134.15.251.6]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA23231; Thu, 13 Sep 2007 09:05:19 +1000 Message-ID: <46E870AB.30906@sgi.com> Date: Thu, 13 Sep 2007 09:05:15 +1000 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: state of the cvs tree References: <20070912121938.GA16870@lst.de> In-Reply-To: <20070912121938.GA16870@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12854 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > looks like the cvs tree is broken currently - fs/xfs/ is merged up to > 2.6.23-rc, but everything else is still at 2.6.22-rc state leading to > various compile failures. I think Tim is in the middle of the .23 update and still has some more to push in. Tim? What else do you (or anyone for that matter) have in the pipeline for XFS? Whilst we're taking huge patches and cleanups, let's get them all in asap. Thanks -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Wed Sep 12 17:10:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 17:10:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8D0Ac4p014896 for ; Wed, 12 Sep 2007 17:10:40 -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 KAA24968; Thu, 13 Sep 2007 10:10:29 +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 l8D0ARdD15310101; Thu, 13 Sep 2007 10:10:28 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l8D0AP2516844278; Thu, 13 Sep 2007 10:10:25 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 13 Sep 2007 10:10:25 +1000 From: David Chinner To: Mark Goodwin Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: state of the cvs tree Message-ID: <20070913001025.GR995458@sgi.com> References: <20070912121938.GA16870@lst.de> <46E870AB.30906@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E870AB.30906@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12855 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Sep 13, 2007 at 09:05:15AM +1000, Mark Goodwin wrote: > > > Christoph Hellwig wrote: > >looks like the cvs tree is broken currently - fs/xfs/ is merged up to > >2.6.23-rc, but everything else is still at 2.6.22-rc state leading to > >various compile failures. > > I think Tim is in the middle of the .23 update and still has some more > to push in. Tim? > > What else do you (or anyone for that matter) have in the pipeline for XFS? > Whilst we're taking huge patches and cleanups, let's get them all in asap. Let's plan this a little better than "ASAP". We've already got a full queue for .24 - I'm uncomfortable with pushing anything more given the nature of the changes we've made in this cycle and we really want some testing time on that code before the .24 merge window opens. Given that we are at .23-rc6 already, it won't be long before .24-rc1 merge window is open, so lets stop pushing large changes into the tree until after the .24-rc1 merge is done. IOWs, I consider stuff like Eric's spin lock clean to be .25 material at this point, not .24, and we should only be taking bug fixes and small, contained features (e.g. fallocate support) for .24. Everything else can wait until .25.... Thoughts? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Sep 12 17:48:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 17:48:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8D0mA4p020652 for ; Wed, 12 Sep 2007 17:48:13 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA25944; Thu, 13 Sep 2007 10:48:02 +1000 Message-ID: <46E88974.2040809@sgi.com> Date: Thu, 13 Sep 2007 10:51:00 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Chinner CC: Mark Goodwin , Christoph Hellwig , xfs@oss.sgi.com Subject: Re: state of the cvs tree References: <20070912121938.GA16870@lst.de> <46E870AB.30906@sgi.com> <20070913001025.GR995458@sgi.com> In-Reply-To: <20070913001025.GR995458@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12856 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Thu, Sep 13, 2007 at 09:05:15AM +1000, Mark Goodwin wrote: >> >> Christoph Hellwig wrote: >>> looks like the cvs tree is broken currently - fs/xfs/ is merged up to >>> 2.6.23-rc, but everything else is still at 2.6.22-rc state leading to >>> various compile failures. >> I think Tim is in the middle of the .23 update and still has some more >> to push in. Tim? >> >> What else do you (or anyone for that matter) have in the pipeline for XFS? >> Whilst we're taking huge patches and cleanups, let's get them all in asap. > > Let's plan this a little better than "ASAP". We've already got a > full queue for .24 - I'm uncomfortable with pushing anything more > given the nature of the changes we've made in this cycle and we > really want some testing time on that code before the .24 merge > window opens. Given that we are at .23-rc6 already, it won't be long > before .24-rc1 merge window is open, so lets stop pushing large > changes into the tree until after the .24-rc1 merge is done. > > IOWs, I consider stuff like Eric's spin lock clean to be .25 material > at this point, not .24, and we should only be taking bug fixes and small, > contained features (e.g. fallocate support) for .24. Everything else > can wait until .25.... > > Thoughts? > Sounds fair to me, Dave. From owner-xfs@oss.sgi.com Wed Sep 12 18:05:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 18:05:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r499012 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 l8D15S4p023475 for ; Wed, 12 Sep 2007 18:05:29 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA26370; Thu, 13 Sep 2007 11:05:20 +1000 Message-ID: <46E88CD0.2050309@sgi.com> Date: Thu, 13 Sep 2007 11:05:20 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: markgw@sgi.com, Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: state of the cvs tree References: <20070912121938.GA16870@lst.de> <46E870AB.30906@sgi.com> In-Reply-To: <46E870AB.30906@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12857 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 Mark Goodwin wrote: > > > Christoph Hellwig wrote: >> looks like the cvs tree is broken currently - fs/xfs/ is merged up to >> 2.6.23-rc, but everything else is still at 2.6.22-rc state leading to >> various compile failures. > > I think Tim is in the middle of the .23 update and still has some more > to push in. Tim? > No I don't :-) I did have some followup dmapi fixes but they got added yesterday. The sgi ptools 2.6.x-xfs tree seems just fine for me, is building and does have the 23-rc4 (only rc4 b/c only had kdb for that at the time) AFAICS. I guess there must be something wrong then with the cvs sync. It must be sync'ing the embedded xfs-linux tree okay but not the 2.6.x-xfs kernel tree. I'll see what I can find out. BTW, sorry for not mentioning the update on oss. I will do that next time. --Tim From owner-xfs@oss.sgi.com Wed Sep 12 18:26:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 18:26:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.234]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8D1Qn4p027176 for ; Wed, 12 Sep 2007 18:26:51 -0700 Received: by nz-out-0506.google.com with SMTP id x3so254352nzd for ; Wed, 12 Sep 2007 18:26:52 -0700 (PDT) Received: by 10.143.10.15 with SMTP id n15mr21292wfi.1189640296167; Wed, 12 Sep 2007 16:38:16 -0700 (PDT) Received: by 10.141.129.6 with HTTP; Wed, 12 Sep 2007 16:38:16 -0700 (PDT) Message-ID: <64de4d610709121638s6a8a92c4qec2c4b70de9d955e@mail.gmail.com> Date: Wed, 12 Sep 2007 16:38:16 -0700 From: "Kevin Mullican" To: xfs@oss.sgi.com Subject: compile fails MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 7c05086ed3e375f8 X-archive-position: 12858 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kevin@mullican.com Precedence: bulk X-list: xfs Greetings, I am attempting to build the XFS kernel, but the compile is failing. I downloaded the source from the CVS repository today, and I generated a relatively generic .config. I am using gcc-3.2.3-52, libgcc-3.2.3-52, and glibc-2.3.2-95.33. During the kernel compile, I am getting the following errors: make -C xfs make[2]: Entering directory `/usr/src/linux-2.4-xfs/fs/xfs' make -C linux-2.4 make[3]: Entering directory `/usr/src/linux-2.4-xfs/fs/xfs/linux-2.4' make all_targets make[4]: Entering directory `/usr/src/linux-2.4-xfs/fs/xfs/linux-2.4' gcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -I.. -I. -funsigned-char -nostdinc -iwithprefix include -DKBUILD_BASENAME=xfs_stats -c -o xfs_stats.o xfs_stats.c In file included from ../xfs.h:48, from xfs_stats.c:19: ../linux-2.4/xfs_linux.h:35:18: warning: extra tokens at end of #undef directive../linux-2.4/xfs_linux.h:96:24: linux/log2.h: No such file or directory In file included from ../linux-2.4/xfs_linux.h:110, from ../xfs.h:48, from xfs_stats.c:19: xfs_vfs.h:46: syntax error before "bhv_head_t" xfs_vfs.h:46: warning: no semicolon at end of struct or union xfs_vfs.h:55: syntax error before '}' token xfs_vfs.h:55: warning: type defaults to `int' in declaration of `bhv_vfs_t' xfs_vfs.h:55: warning: data definition has no type or storage class xfs_vfs.h:109: syntax error before '*' token xfs_vfs.h:110: warning: function declaration isn't a prototype xfs_vfs.h:111: syntax error before '*' token xfs_vfs.h:112: warning: function declaration isn't a prototype xfs_vfs.h:113: syntax error before '*' token xfs_vfs.h:113: warning: function declaration isn't a prototype xfs_vfs.h:114: syntax error before '*' token xfs_vfs.h:114: warning: function declaration isn't a prototype xfs_vfs.h:115: syntax error before '*' token xfs_vfs.h:116: warning: function declaration isn't a prototype xfs_vfs.h:117: syntax error before '*' token xfs_vfs.h:117: warning: function declaration isn't a prototype xfs_vfs.h:118: syntax error before '*' token xfs_vfs.h:119: warning: function declaration isn't a prototype xfs_vfs.h:120: syntax error before '*' token xfs_vfs.h:120: warning: function declaration isn't a prototype xfs_vfs.h:121: syntax error before '*' token xfs_vfs.h:121: warning: function declaration isn't a prototype xfs_vfs.h:122: syntax error before '*' token xfs_vfs.h:122: warning: function declaration isn't a prototype xfs_vfs.h:123: syntax error before '*' token xfs_vfs.h:123: warning: function declaration isn't a prototype xfs_vfs.h:124: syntax error before '*' token xfs_vfs.h:125: warning: function declaration isn't a prototype xfs_vfs.h:126: syntax error before '*' token xfs_vfs.h:126: warning: function declaration isn't a prototype xfs_vfs.h:127: syntax error before '*' token xfs_vfs.h:127: warning: function declaration isn't a prototype xfs_vfs.h:128: syntax error before '*' token xfs_vfs.h:128: warning: function declaration isn't a prototype xfs_vfs.h:131: syntax error before "bhv_position_t" xfs_vfs.h:131: warning: no semicolon at end of struct or union xfs_vfs.h:147: syntax error before '}' token xfs_vfs.h:147: warning: type defaults to `int' in declaration of `bhv_vfsops_t' xfs_vfs.h:147: warning: data definition has no type or storage class xfs_vfs.h:188: syntax error before '*' token xfs_vfs.h:188: warning: function declaration isn't a prototype xfs_vfs.h:188: `vfs_mount' redeclared as different kind of symbol xfs_vfs.h:132: previous declaration of `vfs_mount' xfs_vfs.h:189: syntax error before '*' token xfs_vfs.h:189: warning: function declaration isn't a prototype xfs_vfs.h:189: `vfs_parseargs' redeclared as different kind of symbol xfs_vfs.h:133: previous declaration of `vfs_parseargs' xfs_vfs.h:190: syntax error before '*' token xfs_vfs.h:190: warning: function declaration isn't a prototype xfs_vfs.h:190: `vfs_showargs' redeclared as different kind of symbol xfs_vfs.h:134: previous declaration of `vfs_showargs' xfs_vfs.h:191: syntax error before '*' token xfs_vfs.h:191: warning: function declaration isn't a prototype xfs_vfs.h:191: `vfs_unmount' redeclared as different kind of symbol xfs_vfs.h:135: previous declaration of `vfs_unmount' xfs_vfs.h:192: syntax error before '*' token xfs_vfs.h:192: warning: function declaration isn't a prototype xfs_vfs.h:192: `vfs_mntupdate' redeclared as different kind of symbol xfs_vfs.h:136: previous declaration of `vfs_mntupdate' xfs_vfs.h:193: syntax error before '*' token xfs_vfs.h:193: warning: function declaration isn't a prototype xfs_vfs.h:193: `vfs_root' redeclared as different kind of symbol xfs_vfs.h:137: previous declaration of `vfs_root' xfs_vfs.h:194: syntax error before '*' token xfs_vfs.h:194: warning: function declaration isn't a prototype xfs_vfs.h:194: `vfs_statvfs' redeclared as different kind of symbol xfs_vfs.h:138: previous declaration of `vfs_statvfs' xfs_vfs.h:195: syntax error before '*' token xfs_vfs.h:195: warning: function declaration isn't a prototype xfs_vfs.h:195: `vfs_sync' redeclared as different kind of symbol xfs_vfs.h:139: previous declaration of `vfs_sync' xfs_vfs.h:196: syntax error before '*' token xfs_vfs.h:196: warning: function declaration isn't a prototype xfs_vfs.h:196: `vfs_vget' redeclared as different kind of symbol xfs_vfs.h:140: previous declaration of `vfs_vget' xfs_vfs.h:197: syntax error before '*' token xfs_vfs.h:197: warning: function declaration isn't a prototype xfs_vfs.h:197: `vfs_dmapiops' redeclared as different kind of symbol xfs_vfs.h:141: previous declaration of `vfs_dmapiops' xfs_vfs.h:198: syntax error before '*' token xfs_vfs.h:198: warning: function declaration isn't a prototype xfs_vfs.h:198: `vfs_quotactl' redeclared as different kind of symbol xfs_vfs.h:142: previous declaration of `vfs_quotactl' xfs_vfs.h:199: syntax error before '*' token xfs_vfs.h:199: warning: function declaration isn't a prototype xfs_vfs.h:199: `vfs_get_inode' redeclared as different kind of symbol xfs_vfs.h:143: previous declaration of `vfs_get_inode' xfs_vfs.h:200: syntax error before '*' token xfs_vfs.h:200: warning: function declaration isn't a prototype xfs_vfs.h:200: `vfs_init_vnode' redeclared as different kind of symbol xfs_vfs.h:144: previous declaration of `vfs_init_vnode' xfs_vfs.h:201: syntax error before '*' token xfs_vfs.h:201: warning: function declaration isn't a prototype xfs_vfs.h:201: `vfs_force_shutdown' redeclared as different kind of symbol xfs_vfs.h:145: previous declaration of `vfs_force_shutdown' xfs_vfs.h:202: syntax error before '*' token xfs_vfs.h:202: warning: function declaration isn't a prototype xfs_vfs.h:202: `vfs_freeze' redeclared as different kind of symbol xfs_vfs.h:146: previous declaration of `vfs_freeze' xfs_vfs.h:216: syntax error before "bhv_vfsops_t" xfs_vfs.h:216: warning: no semicolon at end of struct or union xfs_vfs.h:218: syntax error before '}' token xfs_vfs.h:218: warning: type defaults to `int' in declaration of `bhv_module_vfsops_t' xfs_vfs.h:218: warning: data definition has no type or storage class xfs_vfs.h:221: syntax error before "bhv_desc_t" xfs_vfs.h:221: warning: no semicolon at end of struct or union xfs_vfs.h:223: syntax error before '*' token xfs_vfs.h:223: warning: type defaults to `int' in declaration of `bm_ops' xfs_vfs.h:223: warning: data definition has no type or storage class xfs_vfs.h:224: syntax error before '}' token xfs_vfs.h:224: warning: type defaults to `int' in declaration of `bhv_module_t' xfs_vfs.h:224: warning: data definition has no type or storage class xfs_vfs.h:231: syntax error before '*' token xfs_vfs.h:231: warning: type defaults to `int' in declaration of `vfs_allocate' xfs_vfs.h:231: warning: data definition has no type or storage class xfs_vfs.h:232: syntax error before '*' token xfs_vfs.h:232: warning: type defaults to `int' in declaration of `vfs_from_sb' xfs_vfs.h:232: warning: data definition has no type or storage class xfs_vfs.h:233: syntax error before '*' token xfs_vfs.h:233: warning: function declaration isn't a prototype xfs_vfs.h:234: syntax error before '*' token xfs_vfs.h:234: warning: function declaration isn't a prototype In file included from ../linux-2.4/xfs_linux.h:112, from ../xfs.h:48, from xfs_stats.c:19: xfs_vnode.h:43: syntax error before "bhv_vfs_t" xfs_vnode.h:43: warning: no semicolon at end of struct or union xfs_vnode.h:45: syntax error before "v_bh" xfs_vnode.h:45: warning: type defaults to `int' in declaration of `v_bh' xfs_vnode.h:45: warning: data definition has no type or storage class xfs_vnode.h:52: syntax error before '}' token xfs_vnode.h:52: warning: type defaults to `int' in declaration of `bhv_vnode_t' xfs_vnode.h:52: warning: data definition has no type or storage class xfs_vnode.h: In function `vn_from_inode': xfs_vnode.h:92: syntax error before ')' token xfs_vnode.h:92: syntax error before ')' token xfs_vnode.h:92: syntax error before ')' token xfs_vnode.h: In function `vn_to_inode': xfs_vnode.h:96: dereferencing pointer to incomplete type xfs_vnode.h: At top level: xfs_vnode.h:132: syntax error before '*' token xfs_vnode.h:132: warning: function declaration isn't a prototype xfs_vnode.h:133: syntax error before '*' token xfs_vnode.h:133: warning: function declaration isn't a prototype xfs_vnode.h:134: syntax error before '*' token xfs_vnode.h:135: warning: function declaration isn't a prototype xfs_vnode.h:136: syntax error before '*' token xfs_vnode.h:137: warning: function declaration isn't a prototype xfs_vnode.h:138: syntax error before '*' token xfs_vnode.h:139: warning: function declaration isn't a prototype xfs_vnode.h:140: syntax error before '*' token xfs_vnode.h:141: warning: function declaration isn't a prototype xfs_vnode.h:142: syntax error before '*' token xfs_vnode.h:143: warning: function declaration isn't a prototype xfs_vnode.h:144: syntax error before '*' token xfs_vnode.h:144: warning: function declaration isn't a prototype xfs_vnode.h:145: syntax error before '*' token xfs_vnode.h:146: warning: function declaration isn't a prototype xfs_vnode.h:147: syntax error before '*' token xfs_vnode.h:148: warning: function declaration isn't a prototype xfs_vnode.h:149: syntax error before '*' token xfs_vnode.h:149: warning: function declaration isn't a prototype xfs_vnode.h:150: syntax error before '*' token xfs_vnode.h:151: warning: function declaration isn't a prototype xfs_vnode.h:152: syntax error before '*' token xfs_vnode.h:153: warning: function declaration isn't a prototype xfs_vnode.h:154: syntax error before '*' token xfs_vnode.h:155: warning: function declaration isn't a prototype xfs_vnode.h:156: syntax error before '*' token xfs_vnode.h:156: warning: function declaration isn't a prototype xfs_vnode.h:157: syntax error before '*' token xfs_vnode.h:158: warning: function declaration isn't a prototype xfs_vnode.h:159: syntax error before '*' token xfs_vnode.h:160: warning: function declaration isn't a prototype xfs_vnode.h:161: syntax error before '*' token xfs_vnode.h:162: warning: function declaration isn't a prototype xfs_vnode.h:163: syntax error before '*' token xfs_vnode.h:164: warning: function declaration isn't a prototype xfs_vnode.h:165: syntax error before '*' token xfs_vnode.h:165: warning: function declaration isn't a prototype xfs_vnode.h:166: syntax error before '*' token xfs_vnode.h:166: warning: function declaration isn't a prototype xfs_vnode.h:167: syntax error before '*' token xfs_vnode.h:167: warning: function declaration isn't a prototype xfs_vnode.h:168: syntax error before '*' token xfs_vnode.h:168: warning: function declaration isn't a prototype xfs_vnode.h:169: syntax error before '*' token xfs_vnode.h:169: warning: function declaration isn't a prototype xfs_vnode.h:170: syntax error before '*' token xfs_vnode.h:171: warning: function declaration isn't a prototype xfs_vnode.h:172: syntax error before '*' token xfs_vnode.h:173: warning: function declaration isn't a prototype xfs_vnode.h:174: syntax error before '*' token xfs_vnode.h:174: warning: function declaration isn't a prototype xfs_vnode.h:175: syntax error before '*' token xfs_vnode.h:176: warning: function declaration isn't a prototype xfs_vnode.h:177: syntax error before '*' token xfs_vnode.h:178: warning: function declaration isn't a prototype xfs_vnode.h:179: syntax error before '*' token xfs_vnode.h:180: warning: function declaration isn't a prototype xfs_vnode.h:181: syntax error before '*' token xfs_vnode.h:182: warning: function declaration isn't a prototype xfs_vnode.h:183: syntax error before '*' token xfs_vnode.h:183: warning: function declaration isn't a prototype xfs_vnode.h:184: syntax error before '*' token xfs_vnode.h:184: warning: function declaration isn't a prototype xfs_vnode.h:185: syntax error before '*' token xfs_vnode.h:185: warning: function declaration isn't a prototype xfs_vnode.h:186: syntax error before '*' token xfs_vnode.h:186: warning: function declaration isn't a prototype xfs_vnode.h:187: syntax error before '*' token xfs_vnode.h:188: warning: function declaration isn't a prototype xfs_vnode.h:189: syntax error before '*' token xfs_vnode.h:189: warning: function declaration isn't a prototype xfs_vnode.h:192: syntax error before "bhv_position_t" xfs_vnode.h:192: warning: no semicolon at end of struct or union xfs_vnode.h:230: syntax error before '}' token xfs_vnode.h:230: warning: type defaults to `int' in declaration of `bhv_vnodeops_t' xfs_vnode.h:230: warning: data definition has no type or storage class xfs_vnode.h:421: syntax error before '*' token xfs_vnode.h:421: warning: type defaults to `int' in declaration of `vn_initialize' xfs_vnode.h:421: warning: data definition has no type or storage class xfs_vnode.h:438: syntax error before '*' token xfs_vnode.h:438: warning: type defaults to `int' in declaration of `vn_hold' xfs_vnode.h:438: warning: data definition has no type or storage class xfs_vnode.h: In function `vn_flagset': xfs_vnode.h:473: dereferencing pointer to incomplete type xfs_vnode.h:474: dereferencing pointer to incomplete type xfs_vnode.h:475: dereferencing pointer to incomplete type xfs_vnode.h: In function `vn_flagclr': xfs_vnode.h:482: dereferencing pointer to incomplete type xfs_vnode.h:483: dereferencing pointer to incomplete type xfs_vnode.h:484: dereferencing pointer to incomplete type xfs_vnode.h:485: dereferencing pointer to incomplete type xfs_vnode.h: In function `vn_atime_to_bstime': xfs_vnode.h:515: dereferencing pointer to incomplete type xfs_vnode.h: In function `vn_atime_to_timespec': xfs_vnode.h:521: dereferencing pointer to incomplete type xfs_vnode.h: In function `vn_atime_to_time_t': xfs_vnode.h:527: dereferencing pointer to incomplete type In file included from ../linux-2.4/xfs_linux.h:115, from ../xfs.h:48, from xfs_stats.c:19: xfs_iops.h: At top level: xfs_iops.h:35: warning: `struct bhv_desc' declared inside parameter list xfs_iops.h:35: warning: its scope is only this definition or declaration, which is probably not what you want In file included from ../linux-2.4/xfs_linux.h:116, from ../xfs.h:48, from xfs_stats.c:19: xfs_super.h:79: syntax error before '*' token xfs_super.h:79: warning: function declaration isn't a prototype xfs_super.h:80: syntax error before '*' token xfs_super.h:80: warning: function declaration isn't a prototype In file included from ../linux-2.4/xfs_linux.h:118, from ../xfs.h:48, from xfs_stats.c:19: xfs_fs_subr.h:25: syntax error before '*' token xfs_fs_subr.h:25: warning: function declaration isn't a prototype xfs_fs_subr.h:26: syntax error before '*' token xfs_fs_subr.h:26: warning: function declaration isn't a prototype xfs_fs_subr.h:27: syntax error before '*' token xfs_fs_subr.h:27: warning: function declaration isn't a prototype xfs_stats.c:24: syntax error before "int" make[4]: *** [xfs_stats.o] Error 1 make[4]: Leaving directory `/usr/src/linux-2.4-xfs/fs/xfs/linux-2.4' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4-xfs/fs/xfs/linux-2.4' make[2]: *** [_subdir_linux-2.4] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4-xfs/fs/xfs' make[1]: *** [_subdir_xfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/fs' make: *** [_dir_fs] Error 2 I hope you can help, Kevin From owner-xfs@oss.sgi.com Wed Sep 12 18:41:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 18:41:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8D1fR4p030053 for ; Wed, 12 Sep 2007 18:41:31 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA27125; Thu, 13 Sep 2007 11:41:22 +1000 Message-ID: <46E89542.5040202@sgi.com> Date: Thu, 13 Sep 2007 11:41:22 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: state of the cvs tree References: <20070912121938.GA16870@lst.de> In-Reply-To: <20070912121938.GA16870@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12859 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 Hi Christoph, Christoph Hellwig wrote: > looks like the cvs tree is broken currently - fs/xfs/ is merged up to > 2.6.23-rc, but everything else is still at 2.6.22-rc state leading to > various compile failures. > Looking at cvs web it looks like the 2.6.x-xfs was updated 8 hours ago. So I am guessing that you saw a state of the tree whilst it was doing its sync up. Let me know if things are not fine for you still? --Tim From owner-xfs@oss.sgi.com Wed Sep 12 18:47:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 18:47:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8D1lY4p031074 for ; Wed, 12 Sep 2007 18:47:49 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA27369; Thu, 13 Sep 2007 11:47:30 +1000 Message-ID: <46E89763.6050201@sgi.com> Date: Thu, 13 Sep 2007 11:50:27 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Kevin Mullican CC: xfs@oss.sgi.com Subject: Re: compile fails References: <64de4d610709121638s6a8a92c4qec2c4b70de9d955e@mail.gmail.com> In-Reply-To: <64de4d610709121638s6a8a92c4qec2c4b70de9d955e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12860 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Kevin, The xfs code base for the 2.4 kernel is out of date and does not compile. You should check out the linux-2.6-xfs tree and build from that instead. Lachlan Kevin Mullican wrote: > Greetings, > > I am attempting to build the XFS kernel, but the compile is failing. I > downloaded the source from the CVS repository today, and I generated a > relatively generic .config. I am using gcc-3.2.3-52, libgcc-3.2.3-52, > and glibc-2.3.2-95.33. During the kernel compile, I am getting the > following errors: > > make -C xfs > make[2]: Entering directory `/usr/src/linux-2.4-xfs/fs/xfs' > make -C linux-2.4 > make[3]: Entering directory `/usr/src/linux-2.4-xfs/fs/xfs/linux-2.4' > make all_targets > make[4]: Entering directory `/usr/src/linux-2.4-xfs/fs/xfs/linux-2.4' > gcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing > -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 > -march=i686 -I.. -I. -funsigned-char -nostdinc -iwithprefix include > -DKBUILD_BASENAME=xfs_stats -c -o xfs_stats.o xfs_stats.c > In file included from ../xfs.h:48, > from xfs_stats.c:19: > ../linux-2.4/xfs_linux.h:35:18: warning: extra tokens at end of #undef > directive../linux-2.4/xfs_linux.h:96:24: linux/log2.h: No such file or > directory > In file included from ../linux-2.4/xfs_linux.h:110, > from ../xfs.h:48, > from xfs_stats.c:19: > xfs_vfs.h:46: syntax error before "bhv_head_t" > xfs_vfs.h:46: warning: no semicolon at end of struct or union > xfs_vfs.h:55: syntax error before '}' token > xfs_vfs.h:55: warning: type defaults to `int' in declaration of `bhv_vfs_t' > xfs_vfs.h:55: warning: data definition has no type or storage class > xfs_vfs.h:109: syntax error before '*' token > xfs_vfs.h:110: warning: function declaration isn't a prototype > xfs_vfs.h:111: syntax error before '*' token > xfs_vfs.h:112: warning: function declaration isn't a prototype > xfs_vfs.h:113: syntax error before '*' token > xfs_vfs.h:113: warning: function declaration isn't a prototype > xfs_vfs.h:114: syntax error before '*' token > xfs_vfs.h:114: warning: function declaration isn't a prototype > xfs_vfs.h:115: syntax error before '*' token > xfs_vfs.h:116: warning: function declaration isn't a prototype > xfs_vfs.h:117: syntax error before '*' token > xfs_vfs.h:117: warning: function declaration isn't a prototype > xfs_vfs.h:118: syntax error before '*' token > xfs_vfs.h:119: warning: function declaration isn't a prototype > xfs_vfs.h:120: syntax error before '*' token > xfs_vfs.h:120: warning: function declaration isn't a prototype > xfs_vfs.h:121: syntax error before '*' token > xfs_vfs.h:121: warning: function declaration isn't a prototype > xfs_vfs.h:122: syntax error before '*' token > xfs_vfs.h:122: warning: function declaration isn't a prototype > xfs_vfs.h:123: syntax error before '*' token > xfs_vfs.h:123: warning: function declaration isn't a prototype > xfs_vfs.h:124: syntax error before '*' token > xfs_vfs.h:125: warning: function declaration isn't a prototype > xfs_vfs.h:126: syntax error before '*' token > xfs_vfs.h:126: warning: function declaration isn't a prototype > xfs_vfs.h:127: syntax error before '*' token > xfs_vfs.h:127: warning: function declaration isn't a prototype > xfs_vfs.h:128: syntax error before '*' token > xfs_vfs.h:128: warning: function declaration isn't a prototype > xfs_vfs.h:131: syntax error before "bhv_position_t" > xfs_vfs.h:131: warning: no semicolon at end of struct or union > xfs_vfs.h:147: syntax error before '}' token > xfs_vfs.h:147: warning: type defaults to `int' in declaration of `bhv_vfsops_t' > xfs_vfs.h:147: warning: data definition has no type or storage class > xfs_vfs.h:188: syntax error before '*' token > xfs_vfs.h:188: warning: function declaration isn't a prototype > xfs_vfs.h:188: `vfs_mount' redeclared as different kind of symbol > xfs_vfs.h:132: previous declaration of `vfs_mount' > xfs_vfs.h:189: syntax error before '*' token > xfs_vfs.h:189: warning: function declaration isn't a prototype > xfs_vfs.h:189: `vfs_parseargs' redeclared as different kind of symbol > xfs_vfs.h:133: previous declaration of `vfs_parseargs' > xfs_vfs.h:190: syntax error before '*' token > xfs_vfs.h:190: warning: function declaration isn't a prototype > xfs_vfs.h:190: `vfs_showargs' redeclared as different kind of symbol > xfs_vfs.h:134: previous declaration of `vfs_showargs' > xfs_vfs.h:191: syntax error before '*' token > xfs_vfs.h:191: warning: function declaration isn't a prototype > xfs_vfs.h:191: `vfs_unmount' redeclared as different kind of symbol > xfs_vfs.h:135: previous declaration of `vfs_unmount' > xfs_vfs.h:192: syntax error before '*' token > xfs_vfs.h:192: warning: function declaration isn't a prototype > xfs_vfs.h:192: `vfs_mntupdate' redeclared as different kind of symbol > xfs_vfs.h:136: previous declaration of `vfs_mntupdate' > xfs_vfs.h:193: syntax error before '*' token > xfs_vfs.h:193: warning: function declaration isn't a prototype > xfs_vfs.h:193: `vfs_root' redeclared as different kind of symbol > xfs_vfs.h:137: previous declaration of `vfs_root' > xfs_vfs.h:194: syntax error before '*' token > xfs_vfs.h:194: warning: function declaration isn't a prototype > xfs_vfs.h:194: `vfs_statvfs' redeclared as different kind of symbol > xfs_vfs.h:138: previous declaration of `vfs_statvfs' > xfs_vfs.h:195: syntax error before '*' token > xfs_vfs.h:195: warning: function declaration isn't a prototype > xfs_vfs.h:195: `vfs_sync' redeclared as different kind of symbol > xfs_vfs.h:139: previous declaration of `vfs_sync' > xfs_vfs.h:196: syntax error before '*' token > xfs_vfs.h:196: warning: function declaration isn't a prototype > xfs_vfs.h:196: `vfs_vget' redeclared as different kind of symbol > xfs_vfs.h:140: previous declaration of `vfs_vget' > xfs_vfs.h:197: syntax error before '*' token > xfs_vfs.h:197: warning: function declaration isn't a prototype > xfs_vfs.h:197: `vfs_dmapiops' redeclared as different kind of symbol > xfs_vfs.h:141: previous declaration of `vfs_dmapiops' > xfs_vfs.h:198: syntax error before '*' token > xfs_vfs.h:198: warning: function declaration isn't a prototype > xfs_vfs.h:198: `vfs_quotactl' redeclared as different kind of symbol > xfs_vfs.h:142: previous declaration of `vfs_quotactl' > xfs_vfs.h:199: syntax error before '*' token > xfs_vfs.h:199: warning: function declaration isn't a prototype > xfs_vfs.h:199: `vfs_get_inode' redeclared as different kind of symbol > xfs_vfs.h:143: previous declaration of `vfs_get_inode' > xfs_vfs.h:200: syntax error before '*' token > xfs_vfs.h:200: warning: function declaration isn't a prototype > xfs_vfs.h:200: `vfs_init_vnode' redeclared as different kind of symbol > xfs_vfs.h:144: previous declaration of `vfs_init_vnode' > xfs_vfs.h:201: syntax error before '*' token > xfs_vfs.h:201: warning: function declaration isn't a prototype > xfs_vfs.h:201: `vfs_force_shutdown' redeclared as different kind of symbol > xfs_vfs.h:145: previous declaration of `vfs_force_shutdown' > xfs_vfs.h:202: syntax error before '*' token > xfs_vfs.h:202: warning: function declaration isn't a prototype > xfs_vfs.h:202: `vfs_freeze' redeclared as different kind of symbol > xfs_vfs.h:146: previous declaration of `vfs_freeze' > xfs_vfs.h:216: syntax error before "bhv_vfsops_t" > xfs_vfs.h:216: warning: no semicolon at end of struct or union > xfs_vfs.h:218: syntax error before '}' token > xfs_vfs.h:218: warning: type defaults to `int' in declaration of > `bhv_module_vfsops_t' > xfs_vfs.h:218: warning: data definition has no type or storage class > xfs_vfs.h:221: syntax error before "bhv_desc_t" > xfs_vfs.h:221: warning: no semicolon at end of struct or union > xfs_vfs.h:223: syntax error before '*' token > xfs_vfs.h:223: warning: type defaults to `int' in declaration of `bm_ops' > xfs_vfs.h:223: warning: data definition has no type or storage class > xfs_vfs.h:224: syntax error before '}' token > xfs_vfs.h:224: warning: type defaults to `int' in declaration of `bhv_module_t' > xfs_vfs.h:224: warning: data definition has no type or storage class > xfs_vfs.h:231: syntax error before '*' token > xfs_vfs.h:231: warning: type defaults to `int' in declaration of `vfs_allocate' > xfs_vfs.h:231: warning: data definition has no type or storage class > xfs_vfs.h:232: syntax error before '*' token > xfs_vfs.h:232: warning: type defaults to `int' in declaration of `vfs_from_sb' > xfs_vfs.h:232: warning: data definition has no type or storage class > xfs_vfs.h:233: syntax error before '*' token > xfs_vfs.h:233: warning: function declaration isn't a prototype > xfs_vfs.h:234: syntax error before '*' token > xfs_vfs.h:234: warning: function declaration isn't a prototype > In file included from ../linux-2.4/xfs_linux.h:112, > from ../xfs.h:48, > from xfs_stats.c:19: > xfs_vnode.h:43: syntax error before "bhv_vfs_t" > xfs_vnode.h:43: warning: no semicolon at end of struct or union > xfs_vnode.h:45: syntax error before "v_bh" > xfs_vnode.h:45: warning: type defaults to `int' in declaration of `v_bh' > xfs_vnode.h:45: warning: data definition has no type or storage class > xfs_vnode.h:52: syntax error before '}' token > xfs_vnode.h:52: warning: type defaults to `int' in declaration of `bhv_vnode_t' > xfs_vnode.h:52: warning: data definition has no type or storage class > xfs_vnode.h: In function `vn_from_inode': > xfs_vnode.h:92: syntax error before ')' token > xfs_vnode.h:92: syntax error before ')' token > xfs_vnode.h:92: syntax error before ')' token > xfs_vnode.h: In function `vn_to_inode': > xfs_vnode.h:96: dereferencing pointer to incomplete type > xfs_vnode.h: At top level: > xfs_vnode.h:132: syntax error before '*' token > xfs_vnode.h:132: warning: function declaration isn't a prototype > xfs_vnode.h:133: syntax error before '*' token > xfs_vnode.h:133: warning: function declaration isn't a prototype > xfs_vnode.h:134: syntax error before '*' token > xfs_vnode.h:135: warning: function declaration isn't a prototype > xfs_vnode.h:136: syntax error before '*' token > xfs_vnode.h:137: warning: function declaration isn't a prototype > xfs_vnode.h:138: syntax error before '*' token > xfs_vnode.h:139: warning: function declaration isn't a prototype > xfs_vnode.h:140: syntax error before '*' token > xfs_vnode.h:141: warning: function declaration isn't a prototype > xfs_vnode.h:142: syntax error before '*' token > xfs_vnode.h:143: warning: function declaration isn't a prototype > xfs_vnode.h:144: syntax error before '*' token > xfs_vnode.h:144: warning: function declaration isn't a prototype > xfs_vnode.h:145: syntax error before '*' token > xfs_vnode.h:146: warning: function declaration isn't a prototype > xfs_vnode.h:147: syntax error before '*' token > xfs_vnode.h:148: warning: function declaration isn't a prototype > xfs_vnode.h:149: syntax error before '*' token > xfs_vnode.h:149: warning: function declaration isn't a prototype > xfs_vnode.h:150: syntax error before '*' token > xfs_vnode.h:151: warning: function declaration isn't a prototype > xfs_vnode.h:152: syntax error before '*' token > xfs_vnode.h:153: warning: function declaration isn't a prototype > xfs_vnode.h:154: syntax error before '*' token > xfs_vnode.h:155: warning: function declaration isn't a prototype > xfs_vnode.h:156: syntax error before '*' token > xfs_vnode.h:156: warning: function declaration isn't a prototype > xfs_vnode.h:157: syntax error before '*' token > xfs_vnode.h:158: warning: function declaration isn't a prototype > xfs_vnode.h:159: syntax error before '*' token > xfs_vnode.h:160: warning: function declaration isn't a prototype > xfs_vnode.h:161: syntax error before '*' token > xfs_vnode.h:162: warning: function declaration isn't a prototype > xfs_vnode.h:163: syntax error before '*' token > xfs_vnode.h:164: warning: function declaration isn't a prototype > xfs_vnode.h:165: syntax error before '*' token > xfs_vnode.h:165: warning: function declaration isn't a prototype > xfs_vnode.h:166: syntax error before '*' token > xfs_vnode.h:166: warning: function declaration isn't a prototype > xfs_vnode.h:167: syntax error before '*' token > xfs_vnode.h:167: warning: function declaration isn't a prototype > xfs_vnode.h:168: syntax error before '*' token > xfs_vnode.h:168: warning: function declaration isn't a prototype > xfs_vnode.h:169: syntax error before '*' token > xfs_vnode.h:169: warning: function declaration isn't a prototype > xfs_vnode.h:170: syntax error before '*' token > xfs_vnode.h:171: warning: function declaration isn't a prototype > xfs_vnode.h:172: syntax error before '*' token > xfs_vnode.h:173: warning: function declaration isn't a prototype > xfs_vnode.h:174: syntax error before '*' token > xfs_vnode.h:174: warning: function declaration isn't a prototype > xfs_vnode.h:175: syntax error before '*' token > xfs_vnode.h:176: warning: function declaration isn't a prototype > xfs_vnode.h:177: syntax error before '*' token > xfs_vnode.h:178: warning: function declaration isn't a prototype > xfs_vnode.h:179: syntax error before '*' token > xfs_vnode.h:180: warning: function declaration isn't a prototype > xfs_vnode.h:181: syntax error before '*' token > xfs_vnode.h:182: warning: function declaration isn't a prototype > xfs_vnode.h:183: syntax error before '*' token > xfs_vnode.h:183: warning: function declaration isn't a prototype > xfs_vnode.h:184: syntax error before '*' token > xfs_vnode.h:184: warning: function declaration isn't a prototype > xfs_vnode.h:185: syntax error before '*' token > xfs_vnode.h:185: warning: function declaration isn't a prototype > xfs_vnode.h:186: syntax error before '*' token > xfs_vnode.h:186: warning: function declaration isn't a prototype > xfs_vnode.h:187: syntax error before '*' token > xfs_vnode.h:188: warning: function declaration isn't a prototype > xfs_vnode.h:189: syntax error before '*' token > xfs_vnode.h:189: warning: function declaration isn't a prototype > xfs_vnode.h:192: syntax error before "bhv_position_t" > xfs_vnode.h:192: warning: no semicolon at end of struct or union > xfs_vnode.h:230: syntax error before '}' token > xfs_vnode.h:230: warning: type defaults to `int' in declaration of > `bhv_vnodeops_t' > xfs_vnode.h:230: warning: data definition has no type or storage class > xfs_vnode.h:421: syntax error before '*' token > xfs_vnode.h:421: warning: type defaults to `int' in declaration of > `vn_initialize' > xfs_vnode.h:421: warning: data definition has no type or storage class > xfs_vnode.h:438: syntax error before '*' token > xfs_vnode.h:438: warning: type defaults to `int' in declaration of `vn_hold' > xfs_vnode.h:438: warning: data definition has no type or storage class > xfs_vnode.h: In function `vn_flagset': > xfs_vnode.h:473: dereferencing pointer to incomplete type > xfs_vnode.h:474: dereferencing pointer to incomplete type > xfs_vnode.h:475: dereferencing pointer to incomplete type > xfs_vnode.h: In function `vn_flagclr': > xfs_vnode.h:482: dereferencing pointer to incomplete type > xfs_vnode.h:483: dereferencing pointer to incomplete type > xfs_vnode.h:484: dereferencing pointer to incomplete type > xfs_vnode.h:485: dereferencing pointer to incomplete type > xfs_vnode.h: In function `vn_atime_to_bstime': > xfs_vnode.h:515: dereferencing pointer to incomplete type > xfs_vnode.h: In function `vn_atime_to_timespec': > xfs_vnode.h:521: dereferencing pointer to incomplete type > xfs_vnode.h: In function `vn_atime_to_time_t': > xfs_vnode.h:527: dereferencing pointer to incomplete type > In file included from ../linux-2.4/xfs_linux.h:115, > from ../xfs.h:48, > from xfs_stats.c:19: > xfs_iops.h: At top level: > xfs_iops.h:35: warning: `struct bhv_desc' declared inside parameter list > xfs_iops.h:35: warning: its scope is only this definition or > declaration, which is probably not what you want > In file included from ../linux-2.4/xfs_linux.h:116, > from ../xfs.h:48, > from xfs_stats.c:19: > xfs_super.h:79: syntax error before '*' token > xfs_super.h:79: warning: function declaration isn't a prototype > xfs_super.h:80: syntax error before '*' token > xfs_super.h:80: warning: function declaration isn't a prototype > In file included from ../linux-2.4/xfs_linux.h:118, > from ../xfs.h:48, > from xfs_stats.c:19: > xfs_fs_subr.h:25: syntax error before '*' token > xfs_fs_subr.h:25: warning: function declaration isn't a prototype > xfs_fs_subr.h:26: syntax error before '*' token > xfs_fs_subr.h:26: warning: function declaration isn't a prototype > xfs_fs_subr.h:27: syntax error before '*' token > xfs_fs_subr.h:27: warning: function declaration isn't a prototype > xfs_stats.c:24: syntax error before "int" > make[4]: *** [xfs_stats.o] Error 1 > make[4]: Leaving directory `/usr/src/linux-2.4-xfs/fs/xfs/linux-2.4' > make[3]: *** [first_rule] Error 2 > make[3]: Leaving directory `/usr/src/linux-2.4-xfs/fs/xfs/linux-2.4' > make[2]: *** [_subdir_linux-2.4] Error 2 > make[2]: Leaving directory `/usr/src/linux-2.4-xfs/fs/xfs' > make[1]: *** [_subdir_xfs] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/fs' > make: *** [_dir_fs] Error 2 > > I hope you can help, > Kevin > > > From owner-xfs@oss.sgi.com Wed Sep 12 19:01:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 19:01:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8D2164p000523 for ; Wed, 12 Sep 2007 19:01:08 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA27844 for ; Thu, 13 Sep 2007 12:01:07 +1000 Message-ID: <46E899E3.2010808@sgi.com> Date: Thu, 13 Sep 2007 12:01:07 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: state of the cvs tree References: <20070912121938.GA16870@lst.de> <46E89542.5040202@sgi.com> In-Reply-To: <46E89542.5040202@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12861 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 Timothy Shimmin wrote: > Hi Christoph, > > Christoph Hellwig wrote: >> looks like the cvs tree is broken currently - fs/xfs/ is merged up to >> 2.6.23-rc, but everything else is still at 2.6.22-rc state leading to >> various compile failures. >> > Looking at cvs web it looks like the 2.6.x-xfs was updated 8 hours > ago. So I am guessing that you saw a state of the tree whilst it > was doing its sync up. > Let me know if things are not fine for you still? > > --Tim > Looking at the oss scripts briefly it reminded me of all the trees involved: $s[0]->{"fromdir"} = "$pushroot/p_src/slinx_2.4.x-xfs"; $s[0]->{"todir"} = "$pushroot/CVSROOT/slinx_2.4.x-xfs"; $s[1]->{"fromdir"} = "$pushroot/p_src/slinx_2.6.x-xfs"; $s[1]->{"todir"} = "$pushroot/CVSROOT/slinx_2.6.x-xfs"; $s[2]->{"fromdir"} = "$pushroot/p_src/xfs-cmds"; $s[2]->{"todir"} = "$pushroot/tmp/CVSROOT/xfs-cmds"; $s[3]->{"fromdir"} = "$pushroot/p_src/xfs-linux"; $s[3]->{"todir"} = "$pushroot/tmp/CVSROOT/xfs-linux"; $s[4]->{"fromdir"} = "$pushroot/p_src/dmapi-linux"; $s[4]->{"todir"} = "$pushroot/CVSROOT/dmapi"; $s[5]->{"fromdir"} = "$pushroot/p_src/xfs-website"; $s[5]->{"todir"} = "$pushroot/CVSROOT/xfs-website"; The xfs-linux and xfs-dmapi trees are needed for 2.6.x-xfs and 2.4.x-xfs. I modified xfs-linux, xfs-dmapi, and 2.6.x-xfs as part of the update. BTW, Donald, we'll have to do something about the 2.4 ptools tree and cvs sync up if/when 2.4 support is dropped. --Tim From owner-xfs@oss.sgi.com Wed Sep 12 19:02:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 19:02:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8D22Y4p000964 for ; Wed, 12 Sep 2007 19:02:36 -0700 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA27880; Thu, 13 Sep 2007 12:02:32 +1000 Message-ID: <46E89A38.4000300@sgi.com> Date: Thu, 13 Sep 2007 12:02:32 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kevin Mullican CC: xfs@oss.sgi.com Subject: Re: compile fails References: <64de4d610709121638s6a8a92c4qec2c4b70de9d955e@mail.gmail.com> In-Reply-To: <64de4d610709121638s6a8a92c4qec2c4b70de9d955e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12862 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Kevin Mullican wrote: > Greetings, > > I am attempting to build the XFS kernel, but the compile is failing. I > downloaded the source from the CVS repository today, and I generated a > relatively generic .config. I am using gcc-3.2.3-52, libgcc-3.2.3-52, > and glibc-2.3.2-95.33. During the kernel compile, I am getting the > following errors: > > make -C xfs > make[2]: Entering directory `/usr/src/linux-2.4-xfs/fs/xfs' Hi Kevin, The linux-2.4 build hasn't been actively maintained in a while. We have been talking about removing it from cvs because of this. > xfs_vfs.h:46: syntax error before "bhv_head_t" > xfs_vfs.h:46: warning: no semicolon at end of struct or union > xfs_vfs.h:55: syntax error before '}' token > xfs_vfs.h:55: warning: type defaults to `int' in declaration of `bhv_vfs_t' These are due to changes made fairly recently. You may have more luck updating a tree from around the 2007/08/20. But even without the recent chagnes I'd be suprised if it was building. Don From owner-xfs@oss.sgi.com Wed Sep 12 20:02:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 20:02:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8D32W4p012700 for ; Wed, 12 Sep 2007 20:02:33 -0700 Received: from Liberator.local (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 9302618003EF4; Wed, 12 Sep 2007 22:02:36 -0500 (CDT) Message-ID: <46E8A848.8010601@sandeen.net> Date: Wed, 12 Sep 2007 22:02:32 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christoph Hellwig CC: Lachlan McIlroy , Donald Douwsma , xfs-oss Subject: Re: [PATCH SERIES] untangle spinlock macros References: <46E6221E.803@sandeen.net> <46E7460D.3000502@sgi.com> <46E749DD.8010200@sandeen.net> <46E78185.5040201@sgi.com> <20070912082940.GA25373@infradead.org> In-Reply-To: <20070912082940.GA25373@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12863 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 Christoph Hellwig wrote: > On Wed, Sep 12, 2007 at 04:04:53PM +1000, Lachlan McIlroy wrote: > >> These changes look good Eric. >> >> I'm in two minds about losing the spinlock_destroy() macros though. If >> Linux >> ever implements a spinlock teardown routine it would be nice to still have >> all >> the placeholders still there. Although I can't imagine it would do any more >> than assert that the lock is not currently held. If someone else wants to >> lose >> the macros then I'm not going to argue. >> > > I'd say keep them for now. We don't need the spin.h header for them anyway, > as single macro can simply move to xfs_linux.h > > > Try this on for size..... ====================== remove spinlock init abstraction macro in spin.h, remove the callers, and remove the file. Move no-op spinlock_destroy to xfs_linux.h Signed-off-by: Eric Sandeen Index: linux-2.6-xfs/fs/xfs/linux-2.6/spin.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/spin.h +++ /dev/null @@ -1,27 +0,0 @@ -/* - * Copyright (c) 2000-2002,2005 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 - */ -#ifndef __XFS_SUPPORT_SPIN_H__ -#define __XFS_SUPPORT_SPIN_H__ - -#include /* preempt needs this */ -#include - -#define spinlock_init(lock, name) spin_lock_init(lock) -#define spinlock_destroy(lock) - -#endif /* __XFS_SUPPORT_SPIN_H__ */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_buf.c +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c @@ -1568,7 +1568,7 @@ xfs_alloc_delwrite_queue( INIT_LIST_HEAD(&btp->bt_list); INIT_LIST_HEAD(&btp->bt_delwrite_queue); - spinlock_init(&btp->bt_delwrite_lock, "delwri_lock"); + spin_lock_init(&btp->bt_delwrite_lock); btp->bt_flags = 0; btp->bt_task = kthread_run(xfsbufd, btp, "xfsbufd"); if (IS_ERR(btp->bt_task)) { Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_linux.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_linux.h +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_linux.h @@ -43,7 +43,6 @@ #include #include -#include #include #include #include @@ -75,6 +74,7 @@ #include #include #include +#include #include #include @@ -145,6 +145,8 @@ #define current_restore_flags_nested(sp, f) \ (current->flags = ((current->flags & ~(f)) | (*(sp) & (f)))) +#define spinlock_destroy(lock) + #define NBPP PAGE_SIZE #define NDPP (1 << (PAGE_SHIFT - 9)) Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm.c +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm.c @@ -1131,7 +1131,7 @@ xfs_qm_init_quotainfo( return error; } - spinlock_init(&qinf->qi_pinlock, "xfs_qinf_pin"); + spin_lock_init(&qinf->qi_pinlock); xfs_qm_list_init(&qinf->qi_dqlist, "mpdqlist", 0); qinf->qi_dqreclaims = 0; Index: linux-2.6-xfs/fs/xfs/support/debug.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/support/debug.c +++ linux-2.6-xfs/fs/xfs/support/debug.c @@ -17,7 +17,6 @@ */ #include #include "debug.h" -#include "spin.h" static char message[1024]; /* keep it off the stack */ static DEFINE_SPINLOCK(xfs_err_lock); Index: linux-2.6-xfs/fs/xfs/support/ktrace.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/support/ktrace.h +++ linux-2.6-xfs/fs/xfs/support/ktrace.h @@ -18,8 +18,6 @@ #ifndef __XFS_SUPPORT_KTRACE_H__ #define __XFS_SUPPORT_KTRACE_H__ -#include - /* * Trace buffer entry structure. */ Index: linux-2.6-xfs/fs/xfs/xfs_alloc.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_alloc.c +++ linux-2.6-xfs/fs/xfs/xfs_alloc.c @@ -2206,7 +2206,7 @@ xfs_alloc_read_agf( be32_to_cpu(agf->agf_levels[XFS_BTNUM_BNOi]); pag->pagf_levels[XFS_BTNUM_CNTi] = be32_to_cpu(agf->agf_levels[XFS_BTNUM_CNTi]); - spinlock_init(&pag->pagb_lock, "xfspagb"); + spin_lock_init(&pag->pagb_lock); pag->pagb_list = kmem_zalloc(XFS_PAGB_NUM_SLOTS * sizeof(xfs_perag_busy_t), KM_SLEEP); pag->pagf_init = 1; Index: linux-2.6-xfs/fs/xfs/xfs_log.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log.c +++ linux-2.6-xfs/fs/xfs/xfs_log.c @@ -1189,8 +1189,8 @@ xlog_alloc_log(xfs_mount_t *mp, ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); log->l_xbuf = bp; - spinlock_init(&log->l_icloglock, "iclog"); - spinlock_init(&log->l_grant_lock, "grhead_iclog"); + spin_lock_init(&log->l_icloglock); + spin_lock_init(&log->l_grant_lock); initnsema(&log->l_flushsema, 0, "ic-flush"); xlog_state_ticket_alloc(log); /* wait until after icloglock inited */ Index: linux-2.6-xfs/fs/xfs/xfs_mount.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c +++ linux-2.6-xfs/fs/xfs/xfs_mount.c @@ -136,8 +136,8 @@ xfs_mount_init(void) mp->m_flags |= XFS_MOUNT_NO_PERCPU_SB; } - spinlock_init(&mp->m_ail_lock, "xfs_ail"); - spinlock_init(&mp->m_sb_lock, "xfs_sb"); + spin_lock_init(&mp->m_ail_lock); + spin_lock_init(&mp->m_sb_lock); mutex_init(&mp->m_ilock); mutex_init(&mp->m_growlock); /* @@ -616,7 +616,7 @@ xfs_mount_common(xfs_mount_t *mp, xfs_sb int i; mp->m_agfrotor = mp->m_agirotor = 0; - spinlock_init(&mp->m_agirotor_lock, "m_agirotor_lock"); + spin_lock_init(&mp->m_agirotor_lock); mp->m_maxagi = mp->m_sb.sb_agcount; mp->m_blkbit_log = sbp->sb_blocklog + XFS_NBBYLOG; mp->m_blkbb_log = sbp->sb_blocklog - BBSHIFT; Index: linux-2.6-xfs/fs/xfs/xfs_mru_cache.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mru_cache.c +++ linux-2.6-xfs/fs/xfs/xfs_mru_cache.c @@ -368,7 +368,7 @@ xfs_mru_cache_create( */ INIT_RADIX_TREE(&mru->store, GFP_ATOMIC); INIT_LIST_HEAD(&mru->reap_list); - spinlock_init(&mru->lock, "xfs_mru_cache"); + spin_lock_init(&mru->lock); INIT_DELAYED_WORK(&mru->work, _xfs_mru_cache_reap); mru->grp_time = grp_time; Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c @@ -68,7 +68,7 @@ xfs_init(void) extern kmem_zone_t *xfs_dabuf_zone; #ifdef XFS_DABUF_DEBUG extern spinlock_t xfs_dabuf_global_lock; - spinlock_init(&xfs_dabuf_global_lock, "xfsda"); + spin_lock_init(&xfs_dabuf_global_lock); #endif /* From owner-xfs@oss.sgi.com Wed Sep 12 20:04:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 20:04:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r499012 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 l8D34T4p013103 for ; Wed, 12 Sep 2007 20:04:31 -0700 Received: from Liberator.local (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 BBE2218003EF4; Wed, 12 Sep 2007 22:04:33 -0500 (CDT) Message-ID: <46E8A8BD.5050600@sandeen.net> Date: Wed, 12 Sep 2007 22:04:29 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Donald Douwsma CC: xfs-oss Subject: Re: [PATCH SERIES] untangle spinlock macros References: <46E6221E.803@sandeen.net> <46E7460D.3000502@sgi.com> In-Reply-To: <46E7460D.3000502@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12864 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 Donald Douwsma wrote: > But here you use the name of the lock variable. > > /* > - * We actually don't have to acquire the SB_LOCK at all. > + * We actually don't have to acquire the m_sb_lock at all. > * This can only be called from mount, and that's single threaded. XXX > */ I was going to change this, but "sb lock" sounds way too generic to me... -Eric From owner-xfs@oss.sgi.com Wed Sep 12 20:27:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 20:27:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from redback.melbourne.sgi.com (redback.melbourne.sgi.com [134.14.55.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8D3RS4p020270 for ; Wed, 12 Sep 2007 20:27:30 -0700 Received: from redback.melbourne.sgi.com (localhost [127.0.0.1]) by redback.melbourne.sgi.com (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id l8D3UHxR004199; Thu, 13 Sep 2007 13:30:20 +1000 Received: (from lachlan@localhost) by redback.melbourne.sgi.com (8.13.8/8.13.8/Submit) id l8D3UGu9004196; Thu, 13 Sep 2007 13:30:16 +1000 Date: Thu, 13 Sep 2007 13:30:16 +1000 From: Lachlan McIlroy Message-Id: <200709130330.l8D3UGu9004196@redback.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 968767 - Ensure file size updates have been completed before writing inode to disk. X-archive-position: 12865 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@redback.melbourne.sgi.com Precedence: bulk X-list: xfs Ensure file size updates have been completed before writing inode to disk. Date: Thu Sep 13 13:27:00 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-xfs Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29675a fs/xfs/xfs_vnodeops.c - 1.720 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.720&r2=text&tr2=1.719&f=h - Ensure file size updates have been completed before writing inode to disk. fs/xfs/linux-2.6/xfs_super.c - 1.398 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.398&r2=text&tr2=1.397&f=h - Ensure file size updates have been completed before writing inode to disk. fs/xfs/linux-2.6/xfs_aops.c - 1.153 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.153&r2=text&tr2=1.152&f=h - Ensure file size updates have been completed before writing inode to disk. From owner-xfs@oss.sgi.com Wed Sep 12 20:35:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 20:35:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from redback.melbourne.sgi.com (redback.melbourne.sgi.com [134.14.55.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8D3ZP4p021475 for ; Wed, 12 Sep 2007 20:35:29 -0700 Received: from redback.melbourne.sgi.com (localhost [127.0.0.1]) by redback.melbourne.sgi.com (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id l8D3cGlj006215; Thu, 13 Sep 2007 13:38:19 +1000 Received: (from lachlan@localhost) by redback.melbourne.sgi.com (8.13.8/8.13.8/Submit) id l8D3cGMi006214; Thu, 13 Sep 2007 13:38:16 +1000 Date: Thu, 13 Sep 2007 13:38:16 +1000 From: Lachlan McIlroy Message-Id: <200709130338.l8D3cGMi006214@redback.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 969656 - Avoid replaying inode buffer initialisation log items if on-disk version is newer. X-archive-position: 12866 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@redback.melbourne.sgi.com Precedence: bulk X-list: xfs Avoid replaying inode buffer initialisation log items if on-disk version is newer. Date: Thu Sep 13 13:34:58 AEST 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-xfs Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29676a fs/xfs/xfs_buf_item.h - 1.45 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_buf_item.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h - Avoid replaying inode buffer initialisation log items if on-disk version is newer. fs/xfs/xfs_log_recover.c - 1.323 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.323&r2=text&tr2=1.322&f=h - Avoid replaying inode buffer initialisation log items if on-disk version is newer. fs/xfs/xfs_trans_buf.c - 1.127 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_buf.c.diff?r1=text&tr1=1.127&r2=text&tr2=1.126&f=h - Avoid replaying inode buffer initialisation log items if on-disk version is newer. From owner-xfs@oss.sgi.com Wed Sep 12 21:34:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 21:34:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8D4YJ4p030868 for ; Wed, 12 Sep 2007 21:34:23 -0700 Received: from linuxbuild.melbourne.sgi.com (linuxbuild.melbourne.sgi.com [134.14.54.115]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01232; Thu, 13 Sep 2007 14:34:17 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id CCFAC2F9EBDB; Thu, 13 Sep 2007 14:34:16 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 970240 - kill BMAPI_DEVICE Message-Id: <20070913043416.CCFAC2F9EBDB@linuxbuild.melbourne.sgi.com> Date: Thu, 13 Sep 2007 14:34:16 +1000 (EST) X-archive-position: 12867 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs kill BMAPI_DEVICE There is no reason to go into the iomap machinery just to get the right block device for an inode. Instead look at the realtime flag in the inode and grab the right device from the mount structure. I created a new helper, xfs_find_bdev_for_inode instead of opencoding it because I plan to use it in other places in the future. Signed-off-by: Christoph Hellwig Date: Thu Sep 13 14:33:42 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29680a fs/xfs/xfs_iomap.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h - kill BMAPI_DEVICE fs/xfs/xfs_iomap.c - 1.55 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h - kill BMAPI_DEVICE fs/xfs/linux-2.6/xfs_aops.c - 1.154 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.154&r2=text&tr2=1.153&f=h - kill BMAPI_DEVICE From owner-xfs@oss.sgi.com Wed Sep 12 21:45:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Sep 2007 21:45:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8D4jX4p001045 for ; Wed, 12 Sep 2007 21:45:35 -0700 Received: from linuxbuild.melbourne.sgi.com (linuxbuild.melbourne.sgi.com [134.14.54.115]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01510; Thu, 13 Sep 2007 14:45:30 +1000 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 8021B219E49F; Thu, 13 Sep 2007 14:45:30 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 970241 - kill BMAPI_UNWRITTEN Message-Id: <20070913044530.8021B219E49F@linuxbuild.melbourne.sgi.com> Date: Thu, 13 Sep 2007 14:45:30 +1000 (EST) X-archive-position: 12868 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs kill BMAPI_UNWRITTEN There is no reason to go through xfs_iomap for the BMAPI_UNWRITTEN because it has nothing in common with the other cases. Instead check for the shutdown filesystem in xfs_end_bio_unwritten and perform a direct call to xfs_iomap_write_unwritten (which should be renamed to something more sensible one day) Signed-off-by: Christoph Hellwig Date: Thu Sep 13 14:44:43 AEST 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29681a fs/xfs/xfs_iomap.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h - kill BMAPI_UNWRITTEN fs/xfs/xfs_iomap.c - 1.56 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.56&r2=text&tr2=1.55&f=h - kill BMAPI_UNWRITTEN fs/xfs/linux-2.6/xfs_aops.c - 1.155 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.155&r2=text&tr2=1.154&f=h - kill BMAPI_UNWRITTEN From owner-xfs@oss.sgi.com Thu Sep 13 00:16:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 00:16:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 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 l8D7Gm4p023355 for ; Thu, 13 Sep 2007 00:16:52 -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 RAA04976; Thu, 13 Sep 2007 17:16:46 +1000 Message-ID: <46E8E44C.8080802@sgi.com> Date: Thu, 13 Sep 2007 17:18:36 +1000 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com CC: linux-xfs@oss.sgi.com Subject: TAKE 970451: "dmapi" mount option not overwriting the default "noikeep" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12869 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 Fix for a regression caused by a recent patch that moved the DMAPI mount option processing inside xfs_parseargs(). The DMAPI mount option used to be processed in the DMAPI module loaded before xfs_parseargs() was invoked. Date: Thu Sep 13 17:13:23 AEST 2007 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs Inspected by: dgc Author: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29683a fs/xfs/xfs_vfsops.c - 1.539 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.539&r2=text&tr2=1.538&f=h - pv 970451, rv dgc - Fix for a regression caused by a recent patch that moved the DMAPI mount option processing inside xfs_parseargs(). The DMAPI mount option used to be processed in the DMAPI module loaded before xfs_parseargs() was invoked. From owner-xfs@oss.sgi.com Thu Sep 13 01:42:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 01:42:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_60,RCVD_IN_DNSWL_MED, URI_NOVOWEL autolearn=no version=3.2.0-pre1-r499012 Received: from oplss0036.barcap.com (oplss0036.barclayscapital.com [141.228.156.166]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8D8gS4p006755 for ; Thu, 13 Sep 2007 01:42:31 -0700 Received: from oplss0036.barcap.com (localhost [127.0.0.1]) by oplss0036.barcap.com (8.13.7/8.11.4) with ESMTP id l8D82bwH029559 for ; Thu, 13 Sep 2007 09:02:38 +0100 (BST) Received: from ldnpsmeg312.INTRANET.BARCAPINT.COM (ldnpsmeg312.nat.barcapint.com [172.23.3.7]) by oplss0036.barcap.com (8.13.7/8.11.4) with ESMTP id l8D82b35029554 for ; Thu, 13 Sep 2007 09:02:37 +0100 (BST) Received: from sgppsmeh002.INTRANET.BARCAPINT.COM (Not Verified[10.197.2.2]) by ldnpsmeg312.INTRANET.BARCAPINT.COM with Barclays Capital Filter ESMTP id ; Thu, 13 Sep 2007 09:20:49 +0100 Received: from SGPPCMEU302VEUA.INTRANET.BARCAPINT.COM ([10.196.48.77]) by sgppsmeh002.INTRANET.BARCAPINT.COM with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 Sep 2007 16:20:48 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Disposition-Notification-To: Subject: Configuring XFS on Redhat Linux Date: Thu, 13 Sep 2007 16:20:47 +0800 Message-ID: <53F49A183F99D94D9C84E062566A97E3037C6E1E@SGPPCMEU302VEUA.INTRANET.BARCAPINT.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Configuring XFS on Redhat Linux Thread-Index: Acf13vyPltqsWhR4QzypF/iLISJSIg== X-Priority: 1 Priority: Urgent Importance: high From: To: X-OriginalArrivalTime: 13 Sep 2007 08:20:48.0031 (UTC) FILETIME=[FD0BEAF0:01C7F5DE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l8D8gV4p006761 X-archive-position: 12870 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Kumaraswamy.Namburu@barclayscapital.com Precedence: bulk X-list: xfs Hello All, Following is the configuration of the server Linux version 2.6.9-22.ELsmp (root@yort.fnal.gov) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)) #1 SMP Thu Oct 6 10:29:1 Linux engpsrcn01.intranetdev.barcapdev.com 2.6.9-22.ELsmp #1 SMP Thu Oct 6 10:29:17 CDT 2005 x86_64 x86_64 x86_64 GNU/Linux From Inside our compant, I am unable to connect to cvs server at port 2041. Could you please let me know the alternative ways to get the source code. kumaraswamy Namburu > Development Tools Team > http://devtoolswiki > * developmenttools > * General Team Hotline : 87731250 > * Direct : +65 68284827 > * Mobile : +65 91137662 Barclays Capital, Singapore. ------------------------------------------------------------------------ For important statutory and regulatory disclosures and more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ------------------------------------------------------------------------ From owner-xfs@oss.sgi.com Thu Sep 13 03:36:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 03:36:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8DAaA4p024084 for ; Thu, 13 Sep 2007 03:36:14 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l8DAaBA5003375 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 13 Sep 2007 12:36:12 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8DAaBuL003373; Thu, 13 Sep 2007 12:36:11 +0200 Date: Thu, 13 Sep 2007 12:36:11 +0200 From: Christoph Hellwig To: Timothy Shimmin Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: state of the cvs tree Message-ID: <20070913103611.GA3351@lst.de> References: <20070912121938.GA16870@lst.de> <46E89542.5040202@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E89542.5040202@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12871 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Thu, Sep 13, 2007 at 11:41:22AM +1000, Timothy Shimmin wrote: > Looking at cvs web it looks like the 2.6.x-xfs was updated 8 hours > ago. So I am guessing that you saw a state of the tree whilst it > was doing its sync up. > Let me know if things are not fine for you still? Everything is fine now, thanks a lot! From owner-xfs@oss.sgi.com Thu Sep 13 03:40:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 03:40:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8DAdx4p024791 for ; Thu, 13 Sep 2007 03:40:00 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l8DAe0A5003525 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 13 Sep 2007 12:40:00 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8DAe0gA003523; Thu, 13 Sep 2007 12:40:00 +0200 Date: Thu, 13 Sep 2007 12:40:00 +0200 From: Christoph Hellwig To: Mark Goodwin Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: state of the cvs tree Message-ID: <20070913104000.GB3351@lst.de> References: <20070912121938.GA16870@lst.de> <46E870AB.30906@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E870AB.30906@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12872 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Thu, Sep 13, 2007 at 09:05:15AM +1000, Mark Goodwin wrote: > > > Christoph Hellwig wrote: > >looks like the cvs tree is broken currently - fs/xfs/ is merged up to > >2.6.23-rc, but everything else is still at 2.6.22-rc state leading to > >various compile failures. > > I think Tim is in the middle of the .23 update and still has some more > to push in. Tim? > > What else do you (or anyone for that matter) have in the pipeline for XFS? > Whilst we're taking huge patches and cleanups, let's get them all in asap. I have a long pipeline waiting, but as Dave said most of that really shouldn't go into 2.6.24. There's one patch from me that I sent a long time ago that's a trivial cleanup and should probably go into 2.6.24 still, that's "[PATCH] kill unused IOMAP_EOF flag" One thing that is in my alreayd submitted queue that should go into CVS ASAP after a small review is: "[PATCH] kill probe_* sysctl leftovers" this is stuff that never was in mainline, so putting it in seems fine. Then I have a patch from Eric sitting in the front of my queue, "[PATCH V2] refactor xfs_mountfs for clarity & stack savings" which might be a little too big for 2.6.24, but should at least go into CVS ASAP. I think Eric would be really happy to see it in 2.6.24 aswell because that means FC8 could actually mount xfs out of the box without running out of stack or something. From owner-xfs@oss.sgi.com Thu Sep 13 03:41:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 03:41:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8DAfT4p025235 for ; Thu, 13 Sep 2007 03:41:33 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l8DAfTA5003643 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 13 Sep 2007 12:41:29 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l8DAfTVE003641; Thu, 13 Sep 2007 12:41:29 +0200 Date: Thu, 13 Sep 2007 12:41:29 +0200 From: Christoph Hellwig To: Mark Goodwin Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: state of the cvs tree Message-ID: <20070913104129.GA3548@lst.de> References: <20070912121938.GA16870@lst.de> <46E870AB.30906@sgi.com> <20070913104000.GB3351@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070913104000.GB3351@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12873 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs And there's another patch I still have in my already sent out queue for dmapi that needs applying: "[PATCH] xfs_dmapi: add MODULE_ tags" of course dmapi doesn't go to mainline so no 2.6.24 considerations here, but getting rid of that no license specified warning would be nice. From owner-xfs@oss.sgi.com Thu Sep 13 04:41:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Sep 2007 04:41:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8DBfq4p006238 for ; Thu, 13 Sep 2007 04:41:56 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1IVmkY-0006fm-5Z; Thu, 13 Sep 2007 12:20:46 +0100 Date: Thu, 13 Sep 2007 12:20:46 +0100 From: Christoph Hellwig To: Lachlan McIlroy Cc: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: Re: TAKE 968767 - Ensure file size updates have been completed before writing inode to disk. Message-ID: <20070913112046.GA25515@infradead.org> References: <200709130330.l8D3UGu9004196@redback.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709130330.l8D3UGu9004196@redback.melbourne.sgi.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 12874 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs This has never been out for review, has it? On Thu, Sep 13, 2007 at 01:30:16PM +1000, Lachlan McIlroy wrote: > fs/xfs/xfs_vnodeops.c - 1.720 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> xfs_vnodeops.c.diff?r1=text&tr1=1.720&r2=text&tr2=1.719&f=h > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.720&r2=text&tr2=1.719&f=h > - Ensure file size updates have been completed before writing inode to disk. I think you want to at least add a comment above the filemap_fdatawait call why we have it that early compared to where the generic code calls it (again). But hopefully I'll push changes to the core code soon to move the filemap_datawrite/wait into fs domain completely. I also don't like idioms like vn_to_inode(XFS_ITOV(ip)) at all. Just doing a direct ip->i_vnode deference sounds perfectly fine. Why is removing the ipincount check in xfs_inode_